AI 辅助编程已经深度融入日常开发，但一个棘手的问题也随之浮现：同一个功能，人类开发者可能只需 40 行代码，AI 却能洋洋洒洒写出 200 行。多出来的每一行，单拎出来看都合情合理——遵循了开闭原则、保证了高内聚低耦合、做了防御式编程。但这些“合理”加在一起，最终交付的却是一坨难以维护的代码。
问题的根源，不在于某一次交互的质量，而在于 AI 底层推理的“价值排序”与人类维护直觉之间存在系统性偏移。简单来说，AI 默认倾向于“多做一点”：多抽一个接口、多包一层异常、多建一个文件。而每一次选择的偏差可能不超过 5%，但累积 100 次，代码量膨胀 400% 就变得顺理成章。
更令人头疼的是，传统的禁令式约束——“不要过度抽象”、“不要滥用 try-catch”——对 AI 几乎无效。它总能找到规范层面的理由绕过去：“但这里抽接口符合开闭原则啊”、“但这个方法确实需要防御异常嘛”。AI 不是在对抗你的规则，它只是在遵循它自己那套“好代码”的范式而已，而这个范式恰好倾向于膨胀。
为了解决这个问题，本文提出了一套系统化的方案——Code-Slim。它的核心思路不是每一次都去纠正 AI，而是从底层翻转它的默认价值倾向，让“少比多安全”成为 AI 的直觉。
1、背景与问题定义
1.1 现象：AI 代码的“善意膨胀”
下图展示了 AI 代码膨胀的产生机制：单次选择偏差微乎其微，但经过 100 次累积，最终的代码量可以翻 4 倍以上。
1.2 根因分析：为什么“告诉 AI 别写多”没用？
经过对多个被 AI “写崩”的真实项目进行代码审查，我们归纳出 AI 与人类开发者之间几个关键维度的价值排序差异：
| 维度 | AI 默认倾向 | 人类维护直觉 | 偏差方向 |
|---|---|---|---|
| 抽象层级 | 多一层更安全 | 少一层更清晰 | AI 偏多 |
| 异常处理 | 处处防御 | 让异常传播到边界 | AI 偏多 |
| 文件组织 | 关注点分离 | 上下文内聚 | AI 偏散 |
| 配置化 | 先抽配置类 | 先硬编码再重构 | AI 过早 |
| 注释 | 每步都解释 | 代码自解释 | AI 偏啰嗦 |
更关键的是，禁令式约束之所以无效，是因为 AI 总能找到“规范层面”的正当理由来绕开你的限制。它不是故意对抗你，而是它自己的“好代码”标准恰好与膨胀同向。
1.3 本文贡献
基于上述分析，本文提出了 Code-Slim，其核心贡献包括：
- 三种膨胀形态分类法：表层膨胀、深层膨胀、结构侵蚀——为诊断 AI 代码问题提供了统一的分类框架。
- 12 条价值序列翻转规则：从底层翻转 AI 的默认价值倾向，让“少比多安全”成为 AI 的直觉。
- 模板约束 + 行数硬约束 + 位置硬约束：用“只能做什么”替代“不要做什么”，根除 AI 的迂回空间。
- 全流程三步校验机制：需求确认 → 模板填充 → 结构校验，确保输出代码满足约束。
2、系统设计
2.1 整体架构
Code-Slim 的整体架构分为三层：问题诊断层 → 约束策略层 → 执行校验层。每一层解决一个特定的子问题。
2.2 三种膨胀形态分类
这是整个系统的诊断基础。通过代码审计，我们将 AI 代码膨胀归纳为三类：
| 类型 | 表现 | 危害级别 | 检测方式 | 示例 |
|---|---|---|---|---|
| 表层膨胀 | 废话注释、未使用导入、重复逻辑块 | ⭐ 低 | Linter 自动检测 | // get user by id 下面写 getUserById() |
| 深层膨胀 | 为“未来可能需要”提前设计的抽象层、接口、配置项 | ⭐⭐⭐ 高 | 人工审查 | 只有一个实现却抽了 IUserService 接口 |
| 结构侵蚀 | 代码长错位置——业务逻辑泄漏到 Controller | ⭐⭐⭐⭐⭐ 致命 | 按职责边界扫描 | Controller 里写参数校验、拼装返回值、try-catch 堆叠 |
Linter 只能解决表层膨胀，而 Code-Slim 的目标是后两种——它们才是真正让项目在三个月后变成屎山的罪魁祸首。深层膨胀和结构侵蚀之所以难以识别，是因为它们不是“写错了”，而是“写多了”或“写错了位置”。单独看每一行都是好代码，但合在一起，就是一个不可维护的系统。
2.3 12 条价值序列翻转规则
这是 Code-Slim 的核心策略层。12 条规则按优先级从高到低排列，每一条都指向 AI 默认倾向的反面：
- 代码在正确的位置 > 代码行数少
- 代码行数少 > 抽象层级多
- 一个文件搞定 > 关注点分离
- 先硬编码 > 先配置化
- 让异常传播 > 吞掉异常
- 代码自解释 > 写注释解释
- 追问确认需求 > 直接开始编码
- 增量追加到已有文件 > 创建新文件
- 50行能跑的代码 > 200行“更优雅”的代码
- 不改变行为删减 > 保留膨胀代码
- 改变行为的删减 = 错误，必须回退
- 测试友好度 > 行数最少
这 12 条规则的设计遵循两个原则。第一是“翻转大于纠正”：不告诉 AI “这个场景不该过度抽象”，而是告诉它“在任何场景下，少一行比多一层好”。这是从战术纠偏到战略翻转的转变。第二是“覆盖全决策链”：从需求不清晰时怎么办，到写代码时怎么组织，再到写完怎么审查，完整覆盖了 AI 编码的每个决策节点。
2.4 为什么“模板约束 > 禁令约束”？
这是整个系统最关键的策略转折。禁令约束（传统方式）的表述是“不要过度抽象”，留给 AI 巨大的迂回空间；而模板约束（Code-Slim）的表述是“Service 方法一个类内完成，不抽接口”，AI 根本没有“要不要抽接口”的选择权。核心洞察是：给 AI 一条窄道，它反而能写出好代码。当 AI 没有“先设计再填空”的自由度时，膨胀的空间就自然消失了。
2.5 硬约束规则体系
基于上述策略，我们设计了三层硬约束：
| 约束类型 | 具体规则 | 违反后果 |
|---|---|---|
| 行数硬约束 | Controller ≤ 10 行，Service ≤ 30 行，DTO ≤ 5 行 | 功能定义太模糊 → 向用户建议拆分需求 |
| 位置硬约束 | Controller 只做路由转发，Service 只做业务编排，DTO 只做数据载体 | 结构侵蚀 → 必须重写 |
| 增量约束 | 新功能必须追加到已有文件，新增文件数默认 = 0 | 每个新文件需给出必要性理由 |
对于 Service 超过 30 行的情况，建议按“业务步骤”拆分（校验 → 计算 → 持久化 → 通知），每个步骤必须有独立语义。禁止无意义拆分（如 step1/step2），如果拆分后需要共享超过 3 个局部变量，说明拆错了，应保持原方法。
3、规则有效性分析
为了验证每类约束规则对最终代码质量的独立贡献，我们设计了一组消融实验。实验场景统一使用“用户注册并发送欢迎邮件”这一典型业务需求，通过逐步去除某类约束，观察代码膨胀程度的变化。
3.1 消融实验设计
| 实验组 | 条件 | 说明 |
|---|---|---|
| 基准组 | 不使用 Code-Slim | AI 按默认价值倾向自由生成 |
| 实验组 A | 仅启用价值序列（无模板约束） | 只告诉 AI 12 条优先级规则，不设硬约束 |
| 实验组 B | 仅启用模板约束（无价值序列） | 只设行数和位置硬约束，不翻转价值观 |
| 实验组 C | 完整 Code-Slim | 价值序列 + 模板约束 + 行数硬约束 |
3.2 实验结果
| 实验组 | 代码行数 | 文件数 | 结构侵蚀 | 深层膨胀 | 综合评分 |
|---|---|---|---|---|---|
| 基准组 | 81 行 | 6 个 | 2 处 | 4 处 | ⭐ |
| 实验组 A | 52 行 | 4 个 | 1 处 | 2 处 | ⭐⭐⭐ |
| 实验组 B | 38 行 | 3 个 | 0 处 | 1 处 | ⭐⭐⭐⭐ |
| 实验组 C | 14 行 | 3 个 | 0 处 | 0 处 | ⭐⭐⭐⭐⭐ |
3.3 消融分析
从上表数据可以得出三个关键结论。
结论一：价值序列翻转能独立降低 35% 的代码量。实验组 A 相比基准组，代码从 81 行降至 52 行。价值序列翻转让 AI 在每一次选择时倾向于“更少的路径”——少写注释、少抽接口、少包异常。但仅靠价值观引导还不够，AI 仍然会找到“合理理由”进行一定程度的膨胀。
结论二：模板约束能独立消除结构侵蚀。实验组 B（无价值观引导，仅有硬约束）将结构侵蚀从 2 处降至 0 处。行数硬约束和位置硬约束对结构侵蚀有立竿见影的效果——Controller 被强制限制在 10 行，参数校验无法泄漏进去；DTO 被限制在 5 行，业务逻辑无法寄生其中。
结论三：完整组合（价值序列 + 模板约束）产生乘数效应。实验组 C 的代码量不是 A 和 B 的简单叠加（52 + 38 ≠ 14），而是产生了 1+1>2 的协同效应。价值观翻转让 AI “想写少”，模板约束让 AI “只能写少”——两者结合，AI 的输出从“被动受限”变成了“主动精简”。
3.4 单约束贡献度分析
进一步分析每条硬约束对最终结果的独立贡献（以实验组 C 为基准，逐个移除约束）：
| 移除的约束 | 代码行数变化 | 新增问题 | 贡献度 |
|---|---|---|---|
| 移除 Controller ≤ 10 行 | 14 → 23 (+64%) | 结构侵蚀 +1 | ⭐⭐⭐⭐⭐ |
| 移除 Service ≤ 30 行 | 14 → 32 (+129%) | 深层膨胀 +2 | ⭐⭐⭐⭐⭐ |
| 移除 DTO ≤ 5 行 | 14 → 18 (+29%) | 结构侵蚀 +1 | ⭐⭐⭐⭐ |
| 移除增量优先（允许新建文件） | 14 → 19 (+36%) | 文件数 +2 | ⭐⭐⭐ |
Service 行数约束的贡献度最高（129% 增幅），因为 Service 是 AI 最倾向于过度发挥的地方——多写校验、多包异常、多做数据转换，每一样“多做一点”都发生在 Service 层。
4、实战对比：用户注册功能的完整解剖
下面以“用户注册并发送欢迎邮件”为例，完整展示使用 Code-Slim 前后的代码形态差异。这个案例并不复杂，但正因为简单，才能最清晰地暴露 AI 代码膨胀的底层模式。
4.1 基准组：不使用 Code-Slim（AI 默认生成）
AI 默认生成的代码包含 6 个代码块，共 81 行，其中有 2 个冗余文件、2 处结构侵蚀、4 处深层膨胀。Controller 里塞了参数校验和 try-catch，明明只有一个实现却非要去抽一个接口，DTO 里还带了业务判断逻辑，甚至生成了一个空配置类。诊断结果触目惊心。
4.2 实验组 C：使用完整 Code-Slim
使用 Code-Slim 后，整个流程变成了三个步骤。
第 1 步：需求确认。AI 首先追问确认需求，而不是直接开始写代码。
第 2 步：按模板填充代码。Controller 只做路由转发，5 行搞定；Service 只做业务编排，8 行完成；DTO 用 record 定义，1 行即可。所有代码都增量追加到已有文件中，没有创建任何新文件。
第 3 步：结构校验。7 项硬性检查全部通过：新增文件数为 0，Controller 行数 5 行（≤10），Service 行数 8 行（≤30），DTO 行数 1 行（≤5），业务逻辑仅在 Service，异常处理让异常传播，无冗余注释。
4.3 量化对比总结
| 指标 | 基准组（无 Code-Slim） | 实验组 C（完整 Code-Slim） | 改善幅度 |
|---|---|---|---|
| 代码总行数 | 81 行 | 14 行 | ↓ 82.7% |
| 文件总数 | 6 个 | 3 个 | ↓ 50% |
| 新增文件 | 2 个 | 0 个 | ↓ 100% |
| 结构侵蚀 | 2 处 | 0 处 | ✅ 清零 |
| 深层膨胀 | 4 处 | 0 处 | ✅ 清零 |
| Controller 单方法行数 | 23 行 | 5 行 | ↓ 78.3% |
| Service 单方法行数 | 32 行 | 8 行 | ↓ 75.0% |
| DTO 行数 | 18 行 | 1 行 | ↓ 94.4% |
| 无用接口 | 1 个 | 0 个 | ✅ 消除 |
| 空配置类 | 1 个 | 0 个 | ✅ 消除 |
核心价值总结：Code-Slim 不是让代码“好看一点”，而是从根本上消除了两类最致命的代码问题（结构侵蚀和深层膨胀），同时将代码量压缩到原来的 17.3%。
5、使用指南
5.1 安装
将 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 工具的技能/自定义指令中。
5.2 适用场景与触发方式
| 场景 | 触发命令 | 执行流程 | 适用条件 |
|---|---|---|---|
| 新功能开发 | 直接提需求 | 需求确认 → 模板填充 → 结构校验 | 所有新功能 |
| 代码重构 | “重构这个模块” | 现状诊断 → 瘦身方案 → 执行校验 | 已有代码膨胀 |
| 代码审查 | “审查这段代码” | 定位问题 → 输出可执行建议 | PR Review |
| 减少抽象层级 | “减少不必要的抽象” | 识别可删接口/抽象类 → 删除 | 接口泛滥 |
| 修复结构侵蚀 | “修复结构侵蚀” | 标记跨界代码 → 迁移到正确位置 | 职责混乱 |
5.3 边界条件与注意事项
- 测试代码不计入行数约束：Controller、Service、DTO 的行数上限仅针对生产代码。
- 可测试性优先：private 方法因测试需要可提升为 package-private，允许突破行数上限（标注
// [TEST]）。 - 需求模糊处理：AI 默认追问确认；用户选择“先实现”时，代码顶部标记
// [HYPOTHESIS]记录假设前提。 - 语言无关性：约束规则是语言无关的，当前示例以 Java 为主，但同样适用于 Python、Go、TypeScript 等语言。
6、总结与展望
6.1 核心洞察回顾
本项目的核心贡献可以浓缩为三个关键洞察。
洞察一：AI 代码膨胀的本质是价值倾向问题，不是能力问题。AI 并非“不会写短代码”，而是它的默认价值排序让它在每一次决策时都选择“多做一点”。解法不是每次纠正，而是一次性翻转底层价值排序。
洞察二：模板约束 > 禁令约束。告诉 AI “别做什么”没用——它会找 100 种理由绕过去。告诉 AI “只能做什么”才有效——没有了选择权，膨胀空间自然消失。这就是 Code-Slim 从“治疗”到“免疫”的策略转折。
洞察三：代码的唯一安全状态是“删不掉”。每一行都删不掉，每一层都减不了，每个文件都合并不了——这才是代码的稳态。如果一段代码可以通过删减而不改变行为，那这段代码现在就是错的，不是未来可能错，是现在就已经错了。
