AI Coding 的底层框架:一切优化都是在对抗熵增

让模型随手生成一段 React 表单组件，看起来一切正常：组件能渲染、字段可控、接口对得上。但只要把这个组件扔进三个月后再回来打开，会大概率看到这样的现场：

// 第一版：清爽
function OrderForm({ onSubmit }: { onSubmit: (v: Order) => void }) {
  const [form] = useForm();
  return <Form form={form} onFinish={onSubmit}>...</Form>;
}

// 三个月后：被 7 个需求揉过
function OrderForm(props: any) {
  const [form] = useForm();
  const [temp, setTemp] = useState<any>({});
  const [a, setA] = useState(null);
  const [b, setB] = useState([]);
  const [legacyFlag, setLegacyFlag] = useState(false);
  // ...
  function handleX(v: any) { /* 120 行 */ }
  function legacySubmit(v: any) { /* 兜底逻辑 */ }
  return <Form form={form} onFinish={(v) => { if (legacyFlag) legacySubmit(v); else onSubmit(v); }}>...</Form>;
}

这不是个别现象，而是 AI Coding 时代的结构性问题：单点看起来每一步都很合理，组合起来却越来越乱。薛定谔说过一句很物理的话：自然万物都趋向从有序走向无序，生命体靠持续输入负熵维持稳定。代码世界也一样，AI Coding 的每一次"不管它"，都是一次加速熵增的动作。

带着这个视角重读过去两年关于 Harness、Spec、Agent 评测、三层约束的所有工程实践，会发现它们表面上是不同招式，底层只干了一件事——对抗熵增。

二、AI Coding 时代，熵增有三个不一样的特征

传统软件工程里熵增靠人不写注释、不重构来推动，速度慢、可见。AI Coding 里熵增被这三件事同时放大，每一项都值得单独警惕：

特征一：生成速度从"人手一份"变成"一天上千次"

在百度电商搜索团队的统计里，80% 的代码已经由 AI 生成，单月增删改的代码行数是过去纯人写的十倍以上。一个有 5 个 RD 的小组，现在每天通过 PR 的代码量相当于 3 年前的 50 人/月。这意味着熵增的功率被直接放大了一个数量级，传统的"靠人盯"防线必然失效。

一个具体例子：某团队上线两个月后发现，utils/ 目录下出现了 14 个几乎重复却互相不引用的时间格式化函数。每一个单看都合理，凑在一起就是典型的"AI 重复造轮子"——因为模型每次对话都不知道别人已经实现过了。

特征二：错误模式是"看起来对，跑起来崩"

模型生成的代码在语法、命名、风格上几乎无可挑剔，但接口契约、状态边界、并发语义上经常出 bug。这种熵增很难被肉眼 review 发现，传统 CR 越来越难兜底。一个典型的反例：模型写出的"乐观锁"代码看起来有版本号判断，但实际跑在并发场景下会重复提交；看起来有 try/catch 的异步代码，实际上没有 await 关键副作用；命名清晰的 cache util，缓存键忘了带租户 id，命中隔壁租户的数据。

这种熵增最危险的地方是：它不会立刻暴露，而是等流量上来后才以线上故障的形式集中爆发。

特征三：组织形态错位

为了应对前两个特征，很多团队堆了大量 prompt 模板或规则，但 prompt 是输入侧的局部约束，没法约束生成过程和输出。约束缺位的组织，本身就是一个正在熵增的结构：加了 3 个规则，就有 4 个新例外；加了 SOP，就有 5 个绕过 SOP 的捷径；引入 2 个新工具，就有 3 个新术语需要培训。本质上是局部优化越多，全局越乱。

一个真实场景：某团队同时上线了 5 份 prompt 模板、3 份 AGENTS.md、1 份 SOP 文档。半年后新同学入职，面对 9 份互相冲突的指引，反而选择一条都不读。组织熵增到了一定规模，连"读规则"这种动作本身都被熵增消耗掉了。

三、底层公式：质量 = 输入约束 × 生成约束 × 输出约束

把"对抗熵增"翻译成工程语言，就是把不可信的 LLM 套进一套可重复运行的约束系统里。这套系统的最小完整形态，恰好是一个三层的乘积关系：

质量 = 输入约束 × 生成约束 × 输出约束
Agent = Harness + LLM

缺少任何一层，质量都会被剩下的两层拖垮。这是过去一年反复被验证的硬规律：

• • 只有 prompt 模板（输入约束），没有生成过程约束（harness），模型跑长链路任务会跑飞；
• • 只有 harness，没有输出约束（评测/审计/CR），生成的代码进了主干后没人复核；
• • 只有输出约束，没有输入约束（Spec），RD 写什么全凭感觉，QA 永远在救火。

把这三层拆开看，就成了今天的 AI Coding 实战地图。

四、第一层：输入约束——把"做正确的事"固化进 Spec

输入约束的核心，是在让模型动手之前，把要做的边界全部锁死。这一层做不扎实，后面所有 Harness、CR、QA 都会变成"在沙地上盖楼"。

抓手 1：写标准化 Spec，而不是 PRD

传统 PRD 写"做什么"，标准 Spec 必须补齐"怎么做、约束是什么、边界在哪里"：

# 订单提交接口 Spec 片段

## 字段约束
- amount: integer, 范围 [1, 999999], 单位 分
- userId: string, 长度 32, 必须通过 token 校验, 不接受请求体传入

## 状态流转
idle -> submitting -> (success | failed | timeout)
- submitting 状态最长 5s, 超时强制回到 idle 且抛 BusinessError

## 必须覆盖的边界场景
- 同一 userId 5 秒内重复提交, 第二次返回 IDEMPOTENT_ERROR
- amount=0 或负数, 拒绝并返回 FIELD_INVALID

这种 Spec 不只是为了人 review，它的存在本身就是输入约束——直接喂给模型，模型照着写出来的代码一致性会显著提升。百度电商搜索在三个项目的实践中验证过：Spec 写得越完整，AI CR 一次通过率越高，返工轮次越少。

写 Spec 时有一个反直觉的细节：边界场景要比正常路径多花两倍篇幅。正常路径模型自己会写，边界场景才是真正暴露熵增的地方。amount=0、userId 缺失、网络超时、时钟回拨……这些场景每个一两句，凑到一起会直接决定上线后的稳定性。

抓手 2：把团队规范沉淀进 AGENTS.md

Claude 团队在长上下文代码库工程实践里推荐的做法：在仓库根目录维护 AGENTS.md，把所有"约定优于配置"的死规矩写清楚。例如：

# AGENTS.md 片段
- 所有新建组件必须放在 src/components/<领域>/<组件名>/ 下, 不允许平铺
- 任何引入新依赖必须先开 RFC, 不允许私自 npm install
- 错误处理统一使用 src/lib/errors.ts 的业务错误类, 不允许直接 throw new Error
- 所有新增 API 必须有相应的接口测试, 测试覆盖率不低于 80%

模型每次进入仓库，都会先读这份文件。比让它每次重学一遍规矩效率高 10 倍，熵增速度慢 10 倍。AGENTS.md 还有两个常被忽略的细节：第一，只写死规矩，不写建议。"建议"会被模型自动降权，"死规矩"不会；第二，每条都要可验证。"代码要清晰"没法验证，"函数不超过 50 行"可以——后者才有约束力。

五、第二层：生成约束——Harness 工程基础设施

输入约束决定了"做什么"，生成约束决定"怎么做"。这一层就是过去半年行业里反复提到的 Harness。

Harness 不是新框架，而是一个抽象：给模型套上一副缰绳、马鞍、马蹄铁，让它能持续跑、跑长链路还能不掉链子。它的最小形态由两部分组成：

Guides（前馈控制）：模型行动前，先把路铺好

# harness/guides.py 简化示例
def before_agent_step(state):
    # 1. 加载项目规范
    state['rules'] = load_agents_md()
    # 2. 加载当前任务的 Spec
    state['spec'] = load_spec(state['task_id'])
    # 3. 加载相关历史上下文 (500 行以内)
    state['context'] = retrieve_relevant_files(state['spec'])
    return state

Guides 干的事非常朴素：保证模型每次动手前，看到的是同一份"地基"。否则地基一直在变，模型出来的代码就像在沙滩上盖楼。

Sensors（反馈控制）：模型行动后，立刻纠偏

# harness/sensors.py 简化示例
def after_agent_step(state, output):
    issues = []
    # 1. 静态检查
    issues += run_ruff(output['files'])
    issues += run_mypy(output['files'])
    # 2. 单元测试
    issues += run_pytest(output['files'])
    # 3. 自定义业务规则 (例如不允许在 OrderForm 引入新依赖)
    issues += business_linter(output['files'])
    if issues:
        state['retry_prompt'] = format_issues(issues)
        state['should_retry'] = True
    return state

Sensors 的价值不在一次跑通，而在每一次失败都让下一次更聪明——这是经典的控制论闭环，也是对抗熵增最有效的方式。

关键判断：什么时候该自己造 Harness？

把模型当千里马、把 Harness 当缰绳，听起来很美，但不是每个团队都要自己造一套：

• • 调用 GPT/Claude 的标准 API 做一次性任务 → 用好 prompt + 输出检查就够；
• • 在自有代码库里跑长链路任务、多 Agent 协同 → 必须有 Harness；
• • 对输出稳定性要求高（生产环境、医疗/金融）→ Harness 是非做不可。

六、第三层：输出约束——把对抗熵增变成 SOP

输入和生成约束做完了，输出侧还得有人兜底。AI Coding 时代最大的组织变化，是 RD 和 QA 的协作模式从"线性交接"升级为"闭环共建"。

目标对齐变了：以前 RD 想快交付、QA 想抓 bug，两边天然有张力；现在两边共同对齐到一句话——让 AI 生成的代码安全上线。目标一致，对抗熵增就有了合力。

分工变了：QA 必须左移到 Spec 阶段、RD 必须右移到验收复盘。具体动作：

贴吧团队 10 周落地的 AI CR（小码哥）实践，给出过一组很直观的数字：

• • 评审覆盖率：33% → 84%
• • bug 密度：下降 66.87%
• • 三层闭环：反馈群（日级）+ iCafe（周级）+ 周会（迭代级）

AI CR 之所以能量化收益，本质是输出约束被系统化了——以前靠人凭经验，今天靠数据驱动的反馈循环。这套机制一旦稳定，每一次输出都让下一次更好。

百度电商搜索的"品牌卡"项目还有一组值得复用的数据：整体周期从 10 人/天压缩到 4 人/天（-60%），测试任务从原计划 3 天压到 1.5 天完成（-50%），边界 Case 测试效率提升 ~60%。这些数字共同的来源，都是输出侧的 SOP 化、约束化。

值得一提的是，AI Coding 时代对 QA 的要求其实更高而不是更低：以前 QA 拼经验覆盖用例，今天 QA 要懂 Spec、懂 AI、懂业务规则，还要能设计自动校验脚本。本质上是从"测功能"转向"测数据正确性和链路可靠性"，从"接口写完后测试"前移到"接口定义时就参与"。QA 不再是兜底角色，而是负熵流的源头之一。

七、实操清单——你今天就能开始做的 5 件事

对抗熵增不需要一次到位，从最小可用闭环开始跑就行。下面这 5 件事，按难度递增排列，建议两周内跑完一遍：

1. 为下一个新需求写一份标准化 Spec

哪怕只有 30 行，也比什么都没有强。Spec 不必完美，关键是强制自己把"边界 + 异常 + 状态"三个维度写清楚。写完 Spec 后直接喂给模型，让它产出第一版代码，再对比手动写的版本——你会直观看到 Spec 的价值。

2. 在仓库根目录建 AGENTS.md

先记 5 条最强的死规矩。一个月后再补 5 条。让模型进入仓库的第一秒就站在你们的规矩上。注意只写死规矩不写建议，每条可验证。

3. 引入一次 Sensors 自动检查

把 ruff/mypy/eslint 任意一个接进 Agent 跑完之后的自动校验。不需要复杂的 harness，能拦住一次低级 bug 就已经值回票价。最简单的写法是：在 Agent 工具调用结束后，跑一次 shell 命令，失败就把错误回灌给模型重试。

4. 把"AI 评审结果"接到 PR 评论里

不用造轮子，GitLab/GitHub 的 Code Review Bot 都有现成插件。让模型先评审、人再复核。对抗熵增靠的是节奏感，不是单次完美。即使 AI 评审只能发现 30% 的问题，也比让人盯 100% 的代码省力得多。

5. 每周留 30 分钟做"熵增复盘"

挑一个被改烂的文件，问团队三个问题：

• • 它是怎么一步步变烂的？
• • 哪一步本来可以拦下来？
• • 下一次怎么把它写进 Spec 或 AGENTS.md？

复盘本身就是负熵流——把个人经验沉淀成组织资产。坚持两个月会发现：团队的规矩数量没有变多，但每个规矩都更有约束力——这就是负熵复利的形状。

八、回头看：所有优化都在干同一件事

把过去两年关于 AI Coding 的所有优化放在一起看：

• • 写 Spec → 输入侧的负熵
• • Harness → 生成侧的负熵
• • AI CR → 输出侧的负熵
• • AGENTS.md → 跨周期的负熵
• • 团队复盘 SOP → 组织级的负熵

招式各不相同，底层全部指向同一个目标——让 AI Coding 的系统从"自发熵增"切换成"受控熵减"。模型会变、框架会变、工具会变，但熵增这个母题不会变。

下次再看到有人推荐新的 AI Coding 工具或方法时，不必急着切换，可以先问一句：它在对抗哪一层的熵增？覆盖了输入、生成、输出里的哪一环？跟现有的机制是不是重复？

能回答这三个问题的优化，才是真正在帮你做熵减；回答不了的，多数只是新一轮熵增的引线。