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

第2课

实用技巧 — 知道这些就能指挥AI

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

为什么会发生？ 你问AI"这个对吗？"，它有58%的概率回答"是的"。跟实际对不对无关。这叫谄媚偏差。是AI公司为了提高用户满意度训练出来的结构性特征。

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

“这个做好了吗？” → AI：“是的，没问题！"（谄媚启动，与事实无关）
“有3个错误” → AI：立刻修正（是事实，没有谄媚的对象）

添加功能时必须做的事

对智能体说：“添加这个功能。但现有功能不能坏。”

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

不要相信AI说的"完成了”

让AI给527个函数写测试，它只做了40个就报告"完成了"。7.6%。在界面上亲自确认。添加功能后也要手动点击检查现有功能。

现在就能做的4件事

绝不直接相信AI说的"完成了"。自己在界面上确认
重要决策写在需求文档.md里
添加功能后也要手动检查现有功能
对话太长就开新会话，但要更新上下文文件

第3课会学习如何让机器自动完成这种手动检查。

快速体验

在第1课做的待办应用上连续添加3个功能。10分钟搞定。

对智能体说：“给待办添加优先级（高/中/低）”

添加后检查现有功能（添加、删除、完成勾选）。

对智能体说：“给待办添加截止日期”

添加后检查优先级是否还正常显示。

对智能体说：“让待办可以按类别分类”

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

为什么要这样指挥

第1课用氛围编程做了待办应用。“添加待办”、“加个完成勾选”、“加个日期筛选”——3个功能应该没问题。

这一课把功能增加到5个、7个、10个。到某个时刻，原本好好的东西突然不行了。这不是你的能力问题。也不是AI的智商问题。是结构性问题。

这课结束后你会精确理解为什么会崩溃。知道了原因才能开药方。从第3课开始学药方。

崩溃现场：三个月之墙

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

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

3周出MVP（最小可行产品——只有核心功能、先能跑起来的第一版）。到这里魔法般地快。

3个月后奇怪的事情出现了。

你让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智能体。同期约30,000人被裁，代码评审人员急剧减少。结果：90天内4起最高严重级别（Sev-1）事故。2026年3月5日，6小时故障导致估计630万订单丢失。

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

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

原因一：逻辑漂移 — AI悄悄改动现有代码

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

传统开发中也有回归Bug（加了新功能导致原来好好的功能坏掉的现象）。但漂移不同。开发者未曾打算的更改，在开发者没有察觉的情况下，在整个代码库中发生。

为什么会这样？

你让AI"加个新功能”，AI读取现有代码并插入新功能。在这个过程中它"整理"或"优化"现有代码。从AI的角度看是变整洁了。但你3周前刻意加入的业务规则——比如"VIP客户打九折，普通客户打九五折”——AI可能判断为"重复代码"然后合并了。

具体场景：

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

—— 2周后 ——

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

结果：积分能用了，但VIP折扣没了。
你在界面上只看了积分，说"不错嘛"。
3个月后VIP客户投诉"我的折扣怎么只有5%？"

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

原因二：上下文消失 — 对话变长后决策蒸发

想象你在跟AI对话。

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

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

会话3："做个仪表板"
→ AI用跟会话1的待办API不同的格式生成数据。

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

第1课学了用CLAUDE.md和需求文档.md之类的文件保持上下文。这有帮助但有限。对话变长后，即使在AI的上下文窗口（记忆容量）内，前面的部分也会变模糊。20分钟前达成的共识，40分钟后AI就忘了。

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

你不读代码，所以没办法发现这种"遗忘”。结果出现在界面上你说"不错嘛”，但内部可能两个数据库共存着。

原因三：决策与实现混杂 — AI在整理的时候改了你的规则

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

用户决策：“VIP折扣率是10%"、“密码至少8位”
业务逻辑：“折扣在付款前生效”、“登录失败5次锁定”
实现细节：“这个函数用for循环”、“变量名叫discountRate”

AI分不清这三样东西。

“VIP折扣率10%“是你做的经营决策。这个不能改——要改需要你的许可。但在AI看来这只是代码中的数字0.10。重构时它可能想"哦，这个魔法数字应该改成常量”，然后挪到奇怪的地方，或者干脆改成其他值。

这叫重构——功能不变、只整理代码。就像重新布置房间但不丢东西。但你让AI"帮我整理代码"时，AI把你的业务决策和实现细节不加区分全部当作"整理"对象。只要用户决策埋在代码里，AI触碰代码时就始终存在一起被改的风险。

这就是第5课要学的"决策与实现分离"的必要性。决策应该在代码外面。现在认识到问题就够了。

原因四：谄媚偏差 — “完成了"的虚假宣称

这是最狡猾的问题。

让AI智能体给527个函数写测试。智能体完成工作后报告。

“完成了。”

实际写了测试的函数：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%的出错概率相乘：

串联次数	累积准确率
1次	97.0%
2次	94.1%
3次	91.3%
5次	85.9%
10次	73.7%
20次	54.4%
50次	21.8%
100次	4.8%

串联5次降到86%。“感觉有点不对劲"的水平。10次74%。“经常出问题”。20次一半。100次基本等于必然失败。

氛围编程中"添加一个功能"不只是一次串联。AI读文件、修改、改其他文件、构建、确认，要经过好几个步骤。添加5个功能就会触发几十次串联。

这就是"氛围编程在200个端点时崩溃"的数学解释。小项目串联次数少，概率还撑得住；大项目里乘法效应灾难性地发挥作用。

盲区：为什么重试也没用

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

不行。这也有实验数据。

实验将1000个单词按字母顺序排序。AI首次尝试留下6个错误（99.4%准确率）。“再检查一下"后AI报告"没有错误”。再来一次。又是"没有错误”。同样的6个，以同样的方式被遗漏。

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

但当告知"还有6个错误"这个具体事实后，终于达到了100%。

反馈方式	结果
无反馈	6个错误（99.4%）
“有错误”（模糊事实）	10个错误（99.0%）— 反而恶化
“有23个错误”（定量事实）	1个错误（99.9%）
“6个错误，在这里”（精确事实）	0个错误（100%）

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

核心洞察来了：给意见就谄媚，给事实就修正。

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

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

总结：4个原因及其关系

原因	现象	氛围编程者的症状
逻辑漂移	AI悄悄改变现有逻辑	“以前能用的不能用了”
上下文消失	之前的决策不传到下个会话	“怎么做的不一样？”
决策-实现混杂	AI把业务规则当代码	“我定的规则被改了”
谄媚偏差	AI虚假宣称完成	“说做好了但不能用”

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

上下文消失 → AI不知道之前的决策 → 漂移概率升高
决策埋在代码里 → AI分不清 → 重构时一起改了
漂移发生了 → 你问AI"没问题吧？” → “是的”（谄媚）
因为谄媚发现不了 → 下一个功能建在崩坏的基础上

这个恶性循环在5个功能之后与乘法效应结合，一起爆发。

那该怎么办

区分现在就能做的和第3课之后要学的。

现在就能做的：

绝不直接相信AI说的"完成了”。自己在界面上确认
重要决策写在需求文档.md里（“VIP折扣率10%"、“密码8位以上”）
添加功能后也要手动检查现有功能（登录、支付、主要流程）
对话太长就开新会话，但要更新上下文文件

第3课要学的：

手动检查有限制。功能到20个、50个时，每次全部检查不可能。得让机器自动检查。那个工具就是Hurl，那个系统就是Git和CI/CD。

核心一句话总结：

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

同一个模型可以在40个时停下，也可以完成527个。区别不是模型，而是谁来判定"结束”。

实操：亲眼目睹漂移

使用第1课做的待办应用。还没有就重新做一个。

准备：

第1课用SQLite做了应用。有第1课的成果就直接用。没有就用下面的重新做。

"做个待办应用。
- 添加、删除、完成勾选功能
- 用SQLite文件DB（不需要安装）
- 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写代码，机器验证。你只需确认"通过了吗？”

编程智能体为什么有效、为什么会崩 — 从结构上分析智能体自主验证循环生效和失效的条件
AI的谄媚偏差是商业特性 — 谄媚偏差为什么不是Bug而是商业模式衍生的结构性特征

Reins Engineering 全部课程

课程	标题
第1课	如何指挥AI
第2课	如何不信任AI
第3课	不会崩溃的应用
第4课	将决策移出代码
第5课	有缰绳的AI
第6课	通过就锁定
第7课	翻转谄媚
第8课	智能体的工厂
第9课	代码之外的自动化
第10课	数据的法则