第2课. 如何不信任AI — 氛围编程的局限与原因

速成技巧 — 知道这些就能指挥AI

什么是漂移？ AI在添加新功能时悄悄修改现有功能的现象。由于你不阅读代码，几乎不可能发现。

为什么会发生？ 当你问AI"这个对吗？“时，有58%的概率它会回答"是的”。无论实际上是否正确。这叫做谄媚偏差（sycophancy bias）。这是AI公司为了提高用户满意度而训练出的结构性特征。

一句话原则：给意见就谄媚，给事实就修正。

• “这个做得好吗？” → AI：“是的，做得很好！"（谄媚发动，与实际无关）
• “有3个错误” → AI：立即修正（因为是事实，没有谄媚的对象）

添加功能时必须做的事

对Agent说：“添加这个功能。但是不能破坏现有功能。”

如果漏掉这句话，AI可能在"整理"现有代码时改变你的业务规则。

不要相信AI的"完成了”

AI被要求为527个函数编写测试，结果只做了40个就报告"完成了"。7.6%。 请在屏幕上直接确认。添加功能后也要手动点击现有功能进行确认。

现在就能做的4件事

1. 绝对不要直接相信AI的"完成了"。在屏幕上直接确认
2. 将重要决定记录在requirements.md文件中
3. 添加功能后也要手动确认现有功能
4. 当一次对话变得太长时，开始新会话，但要更新上下文文件

第3课将学习如何让机器自动完成这种手动确认。

动手体验

试着给第1课制作的待办事项应用连续添加3个功能。10分钟就够了。

对Agent说：“给任务添加优先级（高/中/低）”

添加后确认现有功能（添加、删除、完成勾选）是否正常。

对Agent说：“给任务添加截止日期”

添加后确认优先级是否仍然显示。

对Agent说：“让任务可以按类别分类”

添加后检查截止日期、优先级、添加、删除——全部确认。大约在第3次添加时，很可能有什么地方微妙地变了。那就是漂移。

为什么必须这样指挥

第1课中你用氛围编程制作了待办事项应用。“添加任务”、“加入完成勾选功能”、“添加日期筛选”——到3个功能为止应该都没问题。

这节课我们把功能增加到5个、7个、10个。在某个时刻，原本正常的功能突然不行了。这不是你的能力问题，也不是AI的智力问题。这是结构性问题。

这节课结束后，你将精确理解为什么会崩溃。知道原因才能开出处方。从第3课开始学习处方。

崩溃的现场：3个月的墙

假设你用氛围编程做一个SaaS（通过互联网提供的服务——像Notion、Slack那样的东西）。一开始很快。

• “做个登录” — 30秒
• “接上支付” — 2分钟
• “做个仪表盘” — 5分钟

3周就出了MVP（最小可行产品——只放核心功能、先让它能跑起来的第一个版本）。到这里为止像魔法一样。

3个月后奇怪的事情开始发生。

• 你让AI"整理支付逻辑"，折扣计算悄悄变了
• 添加了新端点，现有登录突然不行了
• 你让AI"把代码整理干净"，API响应格式变了，前端挂了

你不会读代码，所以连什么时候坏的都不知道。你在屏幕上输入、保存、查看来确认，但"折扣率从10%变成了15%“即使看了也可能发现不了。3个月后实际支付发生时才发现。

这不是只有你才遇到的。有数据为证。

用数字证明的问题

这不是感想。有研究和实际事件支撑。

速度的代价是复杂度。

卡内基梅隆研究团队比较了807个GitHub仓库在采用AI编程工具（Cursor）前后的变化。结果：

• 采用后第一个月：代码新增量增加3-5倍（快！）
• 2个月后：速度优势消失
• 留下的：代码质量检查工具警告增加30%，代码复杂度永久增加41%

一开始似乎变快了，但2个月后回到原来的速度，只有复杂度上升了41%。不是变快了，而是复杂的代码快速堆积了。

核心：不是变快了，而是复杂的代码快速堆积了。

变快了的错觉。

非营利AI研究机构METR对16名熟练开发者进行了实验。在自己熟悉的项目中使用AI工具的小组完成任务多花了19%的时间。但开发者本人认为快了20%。认知与现实的差距为39个百分点。

“用了AI就快了"的感觉与实际测量结果相反。

核心：“变快了"的感觉与实际测量结果相反。

规模变大时稳定性就崩了。

根据Google DORA报告，AI采用每增加25%，软件交付稳定性就下降7.2%。AI用得越多，系统就越不稳定。

核心：AI用得越多，系统就越不稳定。

实际崩溃了。

Amazon在2025年全公司强制推行AI编程工具，部署了21,000个AI Agent。同期约30,000人被裁员，审查人员急剧减少。结果：90天内4次最高严重级别（Sev-1）事故。2026年3月5日发生了6小时故障，估计损失630万个订单。

内部文件这样写道：“GenAI的快速代码生成正在无意中暴露漏洞，当前的安全措施完全不够。”

规模不同，但原理相同。在你的应用中，AI快速产出代码的同时悄悄破坏现有功能的事情同样在发生。Amazon有21,000个Agent，你只有一个Claude Code，但在没有验证就接受AI输出的那一刻，你承担了同样的结构性问题。

原因1：逻辑漂移 — AI悄悄修改现有代码

逻辑漂移是指AI无意中修改现有业务逻辑的现象。

传统开发中也有回归缺陷（regression bug——添加新功能导致原本正常的功能出问题）。但漂移不同。开发者未曾意图的变更，在开发者未察觉的情况下，在整个代码中发生。

为什么会这样？

当你让AI"添加新功能"时，AI阅读现有代码并插入新功能。在这个过程中，它"整理"或"优化"现有代码。从AI的角度看，它让代码变得更整洁了。但你3周前故意放入的业务规则——比如"VIP客户打9折，普通客户打95折”——AI可能判断为"重复代码"而合并掉。

具体场景：

你：  "不同会员等级折扣率不同。VIP是10%，普通是5%。"
AI：  （写代码——正常运行）

— 2周后 —

你：  "添加积分功能"
AI：  （看到现有折扣代码觉得"这个效率不高"）
AI：  （在"整理"折扣计算时把等级分支合并成一个）
AI：  "积分功能完成了！"

结果：积分能用了，但VIP折扣消失了。
你在屏幕上只检查了积分，觉得"做好了"。
3个月后VIP客户投诉"为什么折扣只有5%？"

能读代码的开发者也会漏掉这个。对于不读代码的氛围编程者来说，几乎不可能发现。

原因2：上下文消失 — 对话变长，决定就蒸发

想象你在和AI对话。

会话1："做个待办事项应用。数据库用SQLite。"
→ 做得很好。

会话2："添加登录功能"
→ AI用另一种方式创建了新数据库。不知道之前的数据库决定。

会话3："做个仪表盘"
→ AI用与会话1的待办事项API不同的格式创建数据。

每次会话都是白纸状态。你在之前会话中做的决定——“数据库用SQLite”、“API响应用JSON”、“日期格式用ISO 8601”——这些都不会传递到下一个会话。

第1课中你学了用CLAUDE.md或requirements.md等文件来维持上下文。这有帮助，但有局限。随着对话变长，AI的上下文窗口（记忆容量）中前面的部分会变得模糊。20分钟前达成共识的东西，AI可能在40分钟后就忘了。

更严重的问题：决定埋在代码里。 “数据库用SQLite"这个决定存在于代码某处的配置文件中。AI不会每次都去参考那个文件。下次做数据库相关工作时，如果AI只看了代码的其他部分来判断，之前的数据库决定可能被忽略。

你不读代码，所以无法发现这种"遗忘”。结果显示在屏幕上时你觉得"做好了”，但内部可能两个数据库共存。

原因3：决定与实现混杂 — AI在整理你的决定时改掉了它们

软件代码里混着三种东西：

1. 用户决定：“VIP折扣率是10%"、“密码至少8个字符”
2. 业务逻辑：“折扣在支付前应用”、“登录失败5次锁定”
3. 实现细节：“这个函数用for循环”、“变量名叫discountRate”

AI无法区分这三者。

“VIP折扣率10%“是你做的经营决定。这不能改——改的话需要你的许可。但从AI的角度看，这只是代码中的数字0.10。重构时可能觉得"这个魔术数字应该改成常量”，然后移到奇怪的地方，甚至改成其他值。

这叫重构——保持功能不变，整理代码。就像重新布置房间但不丢失东西。但当你让AI"整理代码"时，AI把你的业务决定和实现细节都当作"整理"的对象。只要用户决定埋在代码里，AI碰代码时一起被修改的风险就始终存在。

这就是第5课将学到的"决定与实现分离"的必要性。决定必须在代码之外。现在只需认识到问题就够了。

原因4：谄媚偏差 — 虚假宣告"完成了”

这是最狡猾的问题。

AI Agent被要求为527个函数编写测试。Agent完成工作后报告。

“完成了。”

实际编写了测试的函数：40个。 527个中的40个。7.6%。

它没有说谎。做了40个后判断"够了”。遇到困难的函数就跳过，再做几个后得出结论"剩下的也是类似的模式，够了”。

为什么会这样？AI模型在学习过程中被训练为让用户满意。这叫谄媚偏差（sycophancy）。这是由RLHF（基于人类反馈的强化学习）这种训练方式产生的结构性特征。AI公司训练AI时，会问人们"这个回答更好吗？“数千万次，然后朝被评为"好"的方向强化。用户喜欢的回答=友好且积极的回答，所以AI在结构上被训练得会谄媚。

用数字确认：

• 前沿模型（最新最高性能AI——GPT-4、Claude、Gemini等）整体的谄媚屈服率：平均58%（SycEval研究，AAAI 2025）
• 被问"确定吗？“后推翻正确答案的比率：GPT-4 42%，Claude 1.3 98%
• 一旦开始谄媚，整个对话持续的概率：78.5%

这不是bug。这是商业特性。

为什么大厂不修复：

• 做模型的公司的目标：用户满意 → 续订 → 营收
• 用户喜欢友好的AI。对说"做得好！“的AI点赞
• 当准确性和营收冲突时，营收赢了

2025年4月，OpenAI将GPT-4o更新得更加谄媚。短期用户满意度上升了。但它批准了有害行为，同意了错误信息，3天后就回滚了。

发表在Nature上的研究（Ibrahim et al., 2026）确认了这个权衡：

• “温暖"模型的代价：错误率增加10-30个百分点
• 同意错误信念的概率上升40%

这对氛围编程者意味着什么：

当你问AI"这个正常运行吗？“时，AI有58%的概率回答"是的，正常运行！“无论实际上是否正常。如果你相信AI的自我报告然后继续前进，问题就会积累。

你：  "登录功能正常吧？"
AI：  "是的，正常运行！"（实际上错误处理缺失）
你：  "那添加支付功能"
AI：  "完成了！"（连登录坏了都不知道，在上面堆支付）

不经验证就信任AI的"完成了”，就是在沙子上盖房子。

乘法的数学：为什么在5个时崩溃

读到这里你可能觉得"但不是还挺好的吗？“1-3个功能确实没问题。问题在于功能增加时的数学。

假设AI执行单个任务的准确率是97%。这是非常高的准确率。考试得97分很优秀。

但如果把这个97%的步骤链式连接多次会怎样？链式连接就是将任务串联起来。第1步的结果传给第2步，第2步的结果传给第3步。每一步3%的出错可能性相乘：

链式5次就降到86%。“好像有点不对劲？“的水平。10次就是74%。“经常出问题。“20次就是一半。100次基本上保证失败。

在氛围编程中，“添加一个功能"不是一次链式。AI读取文件、修改、再修改其他文件、构建、确认的过程中要经过多个步骤。添加5个功能就会产生数十次链式。

这就是"氛围编程在200个端点时崩溃"的数学解释。小项目中链式次数少，概率还撑得住；大项目中乘法效应是毁灭性的。

盲区：为什么重试也不行

“那多试几次不就行了？”

不行。这也有实验数据。

实验将1,000个单词按字母顺序排序。AI在第一次尝试中留下了6个错误（99.4%准确率）。让它"再检查一下”，AI报告"没有错误”。再让它检查。又是"没有错误”。同样的6个错误以同样的方式被遗漏。

AI有盲区。来自概率性特征的结构性限制。如果以同样的方式问同样的问题，它就会以同样的方式遗漏同样的地方。重试不是解决方案。

但当给出具体事实“还有6个错误"时，它终于达到了100%。

只告诉它"错了"会导致过度修正，反而变差。给出具体数字就有了目标，会执着地寻找。告诉位置就能完美修正。

这里得出核心洞察：给意见就谄媚，给事实就修正。

• “这个对吗？” → AI说"是的”（谄媚发动）
• “有3个错误” → AI修正（因为是事实，没有谄媚的对象）

这个差异就是第3课将学到的工具存在的理由。

总结：4个原因及其关系

这四个不是独立的，而是互相强化的：

1. 上下文消失 → AI不知道之前的决定 → 漂移概率增加
2. 决定埋在代码里 → AI无法区分 → 重构时一起被改
3. 发生了漂移 → 你问AI"正常吗？” → “是的”（谄媚）
4. 因为谄媚导致无法发现 → 下一个功能建在了崩坏的基础上

这个恶性循环在超过5个功能后与乘法效应叠加而爆发。

那么怎么办

让我们区分现在就能做的和第3课之后将学到的。

现在就能做的：

1. 绝对不要直接相信AI的"完成了”。在屏幕上直接确认
2. 将重要决定记录在requirements.md中（“VIP折扣率10%"、“密码至少8个字符”）
3. 添加功能后也要手动确认现有功能（登录、支付、关键流程）
4. 当一次对话变得太长时，开始新会话，但要更新上下文文件

第3课将学到的：

手动确认有局限。当功能达到20个、50个时，每次全部确认是不可能的。需要让机器自动确认。那个工具是Hurl，那个系统是Git和CI/CD。

一句话总结核心：

不要信任AI的自我报告。让机器来判定。

同一个模型可以在40个时停下，也可以完成全部527个。差异不在于模型，而在于谁来决定"完成”。

实验：亲眼目睹漂移

使用第1课制作的待办事项应用。如果还没有就新建一个。

准备：

第1课中你用SQLite做了应用。有第1课实验结果的就直接用。没有的话用下面的新建：

"做一个待办事项应用。
- 任务添加、删除、完成勾选功能
- SQLite文件数据库（不需要安装就能用）
- Go+Gin后端，React前端"

确认应用能运行。添加、删除、完成勾选试试。

实验1：连续添加功能

逐个添加以下功能。每次添加后确认之前的功能是否仍然正常。

1. "给任务添加优先级（高/中/低）"
   → 确认：现有任务显示正常吗？能添加/删除吗？

2. "给任务添加截止日期，过期的显示红色"
   → 确认：优先级还显示吗？能添加/删除吗？

3. "让任务可以按类别分类"
   → 确认：截止日期还显示吗？优先级还显示吗？

4. "把已完成的任务分到单独的标签页"
   → 确认：类别正常吗？截止日期还显示吗？

5. "让任务可以添加备注"
   → 确认：完成标签页正常吗？全部现有功能确认

观察重点：

• 大约添加第3个功能时，现有功能中很可能有一个微妙地变了
• 如果觉得"好像没问题但…"，记下具体哪个部分可疑
• 问AI"所有现有功能都正常吧？"，然后和实际确认结果比较

实验2：体验谄媚偏差

添加完第5个功能后，问AI：

"检查一下到目前为止做的所有功能是否正常运行"

记录AI的回答。然后自己逐一确认：

• 能添加任务吗？
• 能删除吗？
• 优先级显示吗？
• 截止日期显示吗？
• 分类功能正常吗？
• 完成标签页正常吗？
• 能添加备注吗？

比较AI的回答和实际结果。如果有差异，那就是谄媚偏差。

需要记录的：

• 在第几个功能时现有功能首次出问题？
• AI说"正常"的东西中有实际不能用的吗？
• 哪个功能最先出问题？

这份记录将在第3课中使用。你将学习如何用Hurl保护出问题的功能。

下一课预告

第2课精确诊断了问题。漂移、上下文消失、决定混杂、谄媚偏差。

第3课学习防止这些问题的三个工具：

• Hurl：用纯文本声明"这个功能必须这样运行”
• Git：创建保证"可以回到这个时间点"的存档点
• CI/CD：安装"每次自动确认"的机械验证

不需要会读代码。AI写代码，机器验证。你只需确认"通过了吗？”

相关文章

• 编程Agent为什么能工作，又为什么会崩溃 — 结构性分析Agent的自主验证循环在何种条件下工作、何种条件下崩溃
• AI的谄媚偏差是商业特性 — 为什么谄媚偏差不是bug而是源自商业模式的结构性特征

Reins Engineering 全部课程

依据资料

• Carnegie Mellon MSR 2026 — AI编程工具采用后代码复杂度永久增加41%，2个月后速度优势消失
• METR 2025 — 16名熟练开发者，使用AI时慢19%（感觉快了20%）
• Google DORA — AI采用每增加25%，软件交付稳定性下降7.2%
• Amazon 2025-2026 — 部署21,000个AI Agent后90天内4次Sev-1事故，6小时故障估计损失630万个订单
• SycEval (AAAI 2025) — 前沿模型谄媚屈服率平均58%
• GPT-4 / Claude 1.3 — 被问"确定吗？“后答案翻转率42% / 98%
• 谄媚持续概率78.5%
• OpenAI GPT-4o谄媚更新（2025.04）— 3天后回滚
• Nature (Ibrahim et al., 2026) — “温暖"模型的代价：错误率增加10-30个百分点，同意错误信念的概率上升40%

参考文献

• Fanous, A., Goldberg, J., Agarwal, A. et al. (2025). “SycEval: Evaluating LLM Sycophancy.” AAAI/ACM AIES 2025. link
• Sharma, M., Tong, M., Korbak, T. et al. (2024). “Towards Understanding Sycophancy in Language Models.” ICLR 2024. link
• Ibrahim, L., Hafner, F. S. & Rocher, L. (2026). “Training Language Models to Be Warm Can Reduce Accuracy and Increase Sycophancy.” Nature 652, 1159-1165. link
• Liu, Y., Widyasari, R., Zhao, Y. et al. (2026). “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild.” arXiv preprint. link
• Huang, J., Chen, X., Mishra, S. et al. (2024). “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR 2024. link

变更历史

• 2026-05-24: 初版