AI 不会替你弥补工程判断，只会把你的习惯放大：用清晰契约约束任务，用独立验证拦住幻觉，再用减法清理上下文噪音，让好习惯成为默认动作。
你大概经历过这样一个下午。给 AI 派了个不小的活，它跑得飞快，一屏一屏代码刷过去，你瞄一眼没毛病，敲个"继续"。它说好的，接着干。你再敲"继续下一个"。半小时后回头一看，界面能打开，代码规范、注释齐全、命名也讲究，可你仔细一用，一小半功能是空的，两三个页面根本没接上。
返工的成本没有消失。它只是被你亲手推迟到了此刻，攒成一坨，一次性砸下来。
大多数人这时的第一反应是"这模型不行"。但你换个更强的模型再来一遍，八成还是这个结局。因为坑不在模型那头，在你这头：你把一件事交给了一台放大器，而你喂进去的，是一个坏习惯。
这就是我想说的第一件、也是最要紧的一件事——AI 是台放大器，它放大的不是你的能力，是你的工程判断。好习惯它替你放大，坏习惯它也照样替你放大，一视同仁。
Simon Willison 早把这句话的一半说破了：同样的工具，资深的人用它更快地做出可靠系统，新手用它更快地攒下技术债。工具本身是中性的，它只负责把你已经有的东西，乘上一个系数。
放大器最阴的地方，是它给坏判断穿了件"专业"的外衣
AI 写出来的代码，几乎永远是格式规范、注释齐全、命名讲究、测试看着覆盖率还挺高的样子。问题在于，模型优化的目标是"长得像它见过的好代码"，这跟"逻辑真的对"是两回事，早就脱钩了。
有人扒了 470 个开源库的数据：AI 代码的 bug 数量是人写的 1.7 倍，逻辑正确性问题多出四分之三。更扎心的一个发现是，人类 reviewer 面对 AI 提交的 PR，挑刺反而更少、更心软。那层"看起来很专业"的皮，系统性地麻痹了本该警惕的眼睛。
所以你被放大的坏习惯，你还看不见。它藏在漂亮的外表底下。工具越强、你用得越顺手，这笔账欠得越隐蔽，利息也越贵。
那怎么办？不是去学更花哨的提示词技巧，也不是再装十个插件。是把三个最容易被放大的坏习惯，换成三个值得被放大的好习惯。就三件事：把话说清楚、把结果验掉、把噪音删掉。
一、契约：先把话说清楚
排头兵的坏习惯，是"21 个字的提示打天下"。“继续”“确认”“执行”“ok”。你把意图几乎全押在了一个赌注上：AI 能从上下文里猜对我想要什么。
这个赌注有两个漏洞。
第一，上下文会腐烂。会话越长，你越依赖的那个"它应该还记得"的隐含约定，恰恰越不可靠。聊到第四十轮，第五轮定下的规矩，早在一堆新消息里被冲淡了。第二个漏洞更致命：你没给验收标准，等于把"这活到底做完没有"的裁判权，交给了 AI 自己。而 AI 给自己打分时有稳定的乐观偏差。Anthropic 的原话是，让 agent 评估自己的产出，它往往会自信地夸赞，哪怕在人看来质量已经明显平庸。
处方很土，就三段，每段一两句：
【目标】给 timeline 的 clip 加音频波形缓存，避免每次渲染重算。
【边界】只动 timeline/ 下的代码；不许改 WaveformRenderer 的公共接口；
别顺手重构无关的地方。
【验收】1. 分离音频后 clip 不再显示波形，保存重进也不显示；
2. 相关测试全绿；
3. 二十条 clip 的项目，波形首渲后滚动不再触发重算（贴出你怎么验的）。
三段各挡一类事故：目标挡"AI 拿它自认为更好的方案替换你的意图"，边界挡"顺手改了不该改的"，验收挡"乐观自评拍脑袋收工"。有意思的是，OpenAI 给 Codex 的官方指南给的是几乎一模一样的四要素：目标、上下文、输出、边界。两个对手收敛到同一个答案，说明这不是谁的风格，是任务本身长这样。
那"继续"是不是从此不能说了？能说，看时机。刚定完计划、AI 复述了下一步、前后五轮之内，说"继续"很安全，意图还在焦点上。会话过了二三十轮、或者刚压缩过一次上下文，再甩"继续"就危险了。跨模块的长任务，每一片都该有自己的验收，这时候"继续"约等于提前放弃裁判权。
二、验证：再把结果验掉
第二个被放大的坏习惯，是盲信。AI 说"完成了"，你就信了。
2026 年官方最佳实践的第一条，已经从"先探索代码库"换成了另一句话：给 AI 一个它能自己跑的检查：测试、构建，或者一张用来对比的截图。原话说得挺好："这是一个你得盯着看的会话，和一个你可以走开去干别的会话之间的区别。"你给它配的验证手段有多硬，你能放手的程度就有多大。
但这里有条铁律：验证不能外包给做事的那个 agent。它自评乐观是结构性的，靠"提醒它诚实"治不好。真正管用的是把生产和评判拆成两个人：让一个全新的、没参与写代码的 reviewer，只拿着 diff 和验收标准去挑错。它不会被"我这么推理所以这么写"的思路带偏。这就是 /code-review 这类工具的原理。记得给它划个边界：“只报影响正确性和需求的问题，其余当可选建议”，不然一个被要求挑刺的 reviewer 总能挑出点什么，你照单全收就会滑向过度设计。
还有两件事，值得写进肌肉记忆。
一是别一视同仁。对着核心引擎、计费鉴权、对外接口这种出错代价大的地方，逐行看 diff、独立 review、测试全绿，一样都不能少；对一次性脚本、原型、个人网站，能跑就行，放飞合法。但放飞出来的代码不许晋升进生产仓库。无非是把有限的注意力，留给出错代价最大的地方。
二是别攒。开头那个"继续到天亮"的翻车，机制就在这里：连续推进、从不设检查点，缺陷跨着一片片累积，最后叠成一个你连源头都定位不了的烂摊子。处方就一句——每完成一片，让 AI 交出"验收清单加怎么验的"，你花两分钟核一下再放行。缺陷在它产生的那一片里被当场逮住，成本最低。
一句可以贴在显示器上的底线，还是 Willison 说的：如果你没亲眼看到代码跑起来，那它就还不是一个能跑的系统。
三、减法：把噪音删掉
第三个坏习惯最反直觉：囤。
新手收集工具，资深者删工具。CLAUDE.md、一堆 rules、几十上百个 skill、全量装上的插件，它们全都不是免费的。每次会话一开场，这些定义在你说第一句话之前，就先吃掉几千甚至上万 token。而放大器对噪音一样尽职：上下文里塞得越多，模型从里头准确拎出关键信息的能力越差。这是 transformer 架构的固有代价，不是"等模型更强就好了"能解决的。
更隐蔽的是规则会腐烂。从模板搬来的几百行"完美规则"，里头相当一部分你从没验证过它真有用，还有一部分正在悄悄过期。你规则里那句"用某某模型"，可能早换过两代了。它们不但占地方，还会在关键时刻把 AI 往错的方向带。
减法有三个动作。第一，两百行法则：CLAUDE.md 超过这个数，遵从度就开始往下掉，臃肿的规则文件反而会让 AI 忽略你真正在乎的那几条指令。第二，删除测试：对每一行自问"删了它，AI 会不会因此犯错"，不会就删；“写干净代码”“保持简单"这种自证正确的口号，模型本来就懂，纯占地方。第三，踩坑驱动：规则不该是空想出来的，该是每次 AI 真做错了一件事，你把这次的教训补进去一条。Mitchell Hashimoto 那个被逐行审查的开源项目，规则文件里"每一行都来自 agent 的一次实际不良行为”。
配一个月度动作就够了：每月做一次规则垃圾回收，删掉一个月没发挥作用的，更新过期的事实，核一遍配置和规则有没有互相打脸。
让好习惯值得被放大
说到底，契约、验证、减法这三件事，没有一件是技巧，全是纪律。技巧会过时：你两年前学的那些"think hard"咒语，现在就是普通文字了；纪律不会。
放大器不会等你准备好才开始放大。它每一天都在把你当天的判断力乘出去，你有多少它放多少。所以真正的功夫不在于再学一个新招，而在一件很朴素的事：让好习惯变成默认动作，让它值得被放大。
如果这三段你只想先动一段，就从最便宜的开始。下一个稍微像样点的任务，别急着敲回车，逼自己把【验收】那一句先写出来：你打算怎么确认这活真的做完了。就这一句话的功夫，多半就够你躲开那个"继续到天亮"的下午了。