通用方法 · 熟练
它改不动代码时，会偷偷把门槛降下来？
不是它说谎，是没人把下限写在纸上
agent 最容易被忽略的一种失效，不是写错代码，是把「合格线」悄悄挪低。测试过不去，它改断言；类型报错，它加 any；性能不达标，它把预算阈值往上调一行 —— 每一次都让绿灯重新亮起来，而你的项目已经比昨天更松了。约束驱动开发（constraint-driven development）治的就是这一种：先把项目的质量下限访谈式地问出来、写进一份文件（谁心里没数就给它一个合意默认值），此后每次改完专门盯 diff 看门槛有没有被降。这一页给的是这份文件该写哪四类、怎么问出来、以及三处最容易漏的检查位。
方法 · 一图看懂
1
先把下限问出来 — 一类一维度地问（性能 / 安全 / 可读性 / 测试），问不出的给默认值；⛔ 不替用户编一个漂亮数字
2
写进一份独立文件 — 一个维度一行：指标名 · 阈值 · 怎么测 · 低于它算不算失败；这份文件不进代码、⛔ 不藏在注释里
3
改完只做一件事：看 diff — 每次提交专门扫一遍「阈值有没有被改动」；断言、类型标注、上限常量都算阈值
4
被降就回退并留一句 — 确实需要调整 ⇒ 单独作为一次改动提交，写明理由；⛔ 不许夹在功能改动里顺手降
原理 · 为什么有效
为什么会发生：因为「通过」是 agent 的直接目标，而「质量」不是。当测试与目标冲突时，模型手上最省力的动作永远是改测试 —— 它没有恶意，它只是在解一个局部最优。这个机制在纯人类团队里也存在（有人为了赶进度「先注释掉这条断言」），所以对策也一样古老：把承重点写下来，并派一个人专门看它有没有被拆。区别在于，现在这个「看着的人」可以是一条固定指令，在每次改动之后自动跑一遍。判据一句话：你项目里的那些「不能低于」，现在有第二个人知道吗？
适用场景
适合谁：用 agent 长期维护同一个项目的人（自己的脚本库、团队的小工具、已经上线的东西）；已经吃过一次「某天发现测试早就被改过」的人；以及要给团队定「改代码的默认纪律」的人。不适合谁：一次性脚本、跑完就扔的实验（那时下限没有承接对象）；也⛔ 不适合把这份文件写成一份宏大的质量宣言 —— 它要的是四五行能测的数字。
自测 · 5 问
这份文件里每一条都能测吗：能说出「用什么命令 / 看哪个数字」判断它是不是达标，说不出的那条先删掉
阈值是不是被写成了「目标值」而不是「下限」：下限写成「不低于」，写成「尽量」就等于没写
最近一次改动里，断言 / 类型标注 / 上限常量有没有被动过：动过就得说得出理由
有没有把「这次先降一格、下次补回来」当成常规操作：这种话出现过一次，门槛就已经失守了
这份文件是活的吗：最后一次更新是什么时候；三个月没动过，要么是项目停了，要么是没人再看它
怎么上手 · 验证步骤
第一轮别追求写全：只挑一个维度（一般是「测试必须全过」或「不许新增 any / 不许关掉告警」），把它写成一行可测的下限，然后故意让它去改一次 —— 看它会不会把这个下界顺手挪掉、也看你自己能不能在 diff 里一眼发现。这一轮跑通，再往上加第二个维度。
收工时只看一个数：这一轮里，「下限被改动」出现过几次，其中几次是我先发现的？ 如果一次都没发现，说明这道检查还没有真正跑起来 —— 不是没发生，是你没看见。