捅破 AI 代码膨胀那层窗户纸
AI 写代码时最大的危险不是写错，而是写多。
Code-Slim 是一套让 AI 写代码时"本能地选择更少路径"的约束规则。
它不是 Linter，不是代码风格指南。它只干两件事：
- 🔪 砍掉深层膨胀 —— 那些为了"未来可能需要"而提前设计的抽象层、接口、配置项
- 🔪 修复结构侵蚀 —— 那些长错了位置的代码（业务逻辑泄漏到 Controller，展示逻辑入侵 Service）
AI 默认的价值排序——每一项都在鼓励"多写一点"：
安全 > 简洁
完整 > 必要
可扩展 > 可理解
Code-Slim 翻转这个排序：
| 优先级 | 规则 |
|---|---|
| 1 | 📍 代码在正确的位置 > 代码行数少 |
| 2 | 📏 代码行数少 > 抽象层级多 |
| 3 | 📦 一个文件搞定 > 关注点分离 |
| 4 | ⚙️ 先硬编码 > 先配置化 |
| 5 | 🌊 让异常传播 > 吞掉异常 |
| 6 | 📝 代码自解释 > 写注释解释 |
| 7 | ❓ 追问确认需求 > 直接开始编码 |
| 8 | ➕ 增量追加到已有文件 > 创建新文件 |
| 9 | 🚀 50行能跑的代码 > 200行"更优雅"的代码 |
| 10 | ✂️ 不改变行为的前提下删减 > 保留膨胀代码 |
| 11 | 🚫 改变行为的删减 = 错误，必须回退 |
| 12 | ✅ 测试友好度 > 行数最少 |
🚀 需求模糊时：AI 默认追问确认。如果你明确选择"先实现"，AI 会在代码顶部标记
// [HYPOTHESIS]记录假设前提，后续验证或回退。
| 场景 | 核心动作 |
|---|---|
| 🆕 新功能开发 | 需求确认 → 模板填充 → 结构校验 |
| 🔄 代码重构 | 现状诊断 → 瘦身方案 → 执行校验 |
| 🔍 代码审查 | 定位问题 → 输出可执行的具体建议 |
| 🏗️ 架构优化 | 识别深层膨胀，给出删减方案 |
| 📉 减少抽象层级 | 删除不必要的接口、抽象类、配置项 |
| 🧹 修复结构侵蚀 | 将跨界代码迁移到正确位置 |
| 代码块 | 行数上限 | 职责边界 |
|---|---|---|
| Controller | ≤ 10 行 | 接收请求 → 调用 Service → 返回响应 |
| Service | ≤ 30 行 | 业务编排 + 数据转换 |
| DTO | ≤ 5 行 | 纯数据载体，禁止任何逻辑 |
⚠️ 超过上限 = 功能定义太模糊，要求拆分需求，而不是 AI 自行发挥。
💡 Service超过30行时，按业务步骤拆（校验→计算→持久化→通知），禁止无意义拆分为step1/step2。如果拆分后需共享超过3个局部变量，说明拆错了，应保持原方法。
| 规则 | 说明 |
|---|---|
| 测试代码不计入行数约束 | Controller、Service、DTO的行数上限仅针对生产代码 |
| 可测试性优先 | private方法因测试需要可提升为package-private，允许突破行数上限（标注 // [TEST] 说明理由） |
| 禁止牺牲可测试性 | 行数精简不能以牺牲可测试性为代价 |
任何支持自定义指令/技能的 AI 平台都可以使用，只需要：
- 将 SKILL.md 中的规则告诉 AI
- 让 AI 在写代码时遵循这些规则
将 code-slim 目录复制到 Trae 的 skills 目录：
# macOS/Linux
cp -r code-slim ~/.trae-cn/skills/
# Windows
xcopy /E code-slim %USERPROFILE%\.trae-cn\skills\直接将 SKILL.md 作为自定义指令添加到你的 AI 工具中。
同一个功能，人类写 40 行，AI 写 200 行——多出来的 160 行不是 bug，是 AI 的"善意膨胀"：
- 3 层抽象"方便未来扩展"
- 5 个文件"关注点分离"
- 8 个 try-catch"保证健壮性"
- 12 条注释"提升可读性"
每一行都有理由，但加在一起就是一坨搬不动的屎山。
核心洞察：模板约束 > 禁令约束。 告诉 AI "别过度抽象"没用——它会找 100 种理由绕过去。解法不是纠正，而是不给选择权：
- 🚧 模板约束 > 禁令约束
- 📏 行数硬约束 > 软性建议
- 📍 位置硬约束 > 职责模糊
每一行都删不掉，每一层都减不了，每个文件都合并不了。
如果一段代码可以通过删减而不改变行为，那这段代码现在就是错的——不是未来可能错，是现在就已经错了。
| 项目 | 内容 |
|---|---|
| 作者 | 艺杯羹 |
| 3057454077 | |
| CSDN | 艺杯羹 |
MIT © 艺杯羹