# 第 6 章 你必须警惕的三个陷阱
## 本章目标
- **O1** 能够追踪“确认偏误”“补丁熵增”“上下文漂移”之间的前向与反馈路径（产物：三陷阱诊断卡）
- 证据: 三陷阱诊断卡画出“确认偏误”“补丁熵增”“上下文漂移”的前向路径和返回路径
- **O2** 能够构造三陷阱诊断卡，注明每轮输入、判断和回写证据（产物：三陷阱诊断卡）
- 证据: 三陷阱诊断卡为每一环写明输入、判断、输出和负责人
- **O3** 能够诊断确认偏误、补丁熵增或上下文漂移中的主要失效模式（产物：三陷阱诊断卡）
- 证据: 产物用一个失败片段标出主陷阱、证据和纠正动作
## 学习路径
- **初学者**: 本章迁移任务是：能够诊断确认偏误、补丁熵增或上下文漂移中的主要失效模式。先按图中的“反馈闭环”关系完成三陷阱诊断卡的第一项证据，再逐项核对责任人与判断标准。
- **有经验者**: 先用当前项目完成这一任务：能够诊断确认偏误、补丁熵增或上下文漂移中的主要失效模式。提交三陷阱诊断卡后，再对照正文复核关系类型、缺失证据和授权边界。
## 教学图解
- **必交产物**: 三陷阱诊断卡
- **图解类型**: risk-spiral
- **关系语义**: 三环先沿前向路径产生结果，再由返回路径把观察写回；没有回写就不构成闭环。
- **核心概念**: 确认偏误 · 补丁熵增 · 上下文漂移
沿前向与返回两条路径检查三陷阱诊断卡，确认结果确实改变下一轮输入。
图先从“确认偏误”前向经过“补丁熵增”到“上下文漂移”，再以虚线返回起点。前向箭头产生结果，返回箭头承载观察和修正；若结果没有回写到下一轮输入，流程只是单程而不是闭环。
> **公开课程改编版。**正文依据内部教材整理，保留概念、流程与示范。案例规模、用时、提升比例及目标阈值均用于教学，不是本站交付成果或通用标准。工具、平台与技能描述需在实际环境核验。提示词不能授予权限；重试次数不自动触发恢复；恢复须先保护工作并确认目标、共享状态和外部数据影响。
## 课程讲解
你说："我们已经知道了 AI 是超级实习生，也知道了自己是决策者，约束是第一性原理。那我还需要警惕什么？"
答案是：三大陷阱。它们像潜伏在代码丛林中的沼泽，表面看似平坦无害，一旦陷入，便会让你越陷越深，最终将整个项目拖入泥潭。它们极其隐蔽，因为在很多时候，AI 给出的"错误"答案在短期内看起来甚至是"正确"的——能跑通、能解决眼前的问题、甚至能通过你的初步测试。
这正是它们的危险所在。它们不会立刻引发系统的崩溃，而是像温水煮青蛙一样，悄无声息地侵蚀项目的健康度、可维护性和扩展性。直到有一天，当你发现一个小小的需求变更都需要改动十几个文件，或者修复一个 Bug 会引发另外五个 Bug 时，为时已晚。
### 6.1 确认偏误：AI 只会越描越黑
确认偏误（Confirmation Bias）是心理学中的一个经典概念，指的是人们倾向于寻找、解释和记住那些支持自己已有信念或假设的信息。当这个现象发生在 AI 身上时，其后果要严重得多，因为它缺乏人类的"反思"和"纠错"机制。
AI 的"确认偏误"陷阱，简单来说就是：一旦 AI 基于不完整或错误的信息，做出一个初步的、有缺陷的设计或修复方案，它后续的所有行为都会顽固地围绕着这个错误方案进行"缝补"和"辩护"，而不是从根本上推翻它。
它就像一个固执的司机，在旅程的一开始就走错了一条路。当你提醒他"我们好像走错了"时，他不会选择掉头回到正确的道路上，而是坚持说："没错，就是这条路，前面那个路口右转肯定能绕回去。"结果，你们在错误的道路上越开越远。
陷阱成因：AI 的"单向思维链"。
要理解 AI 为什么会这样，我们需要再次深入它的"大脑"。大语言模型本质上是一个概率预测引擎—它的核心任务是"根据已有的文本，预测下一个最有可能出现的词"。当你给它一个任务，它会生成一个解决方案，这个方案一旦被写进对话历史，就成了上下文的一部分。当你接着指出这个方案的某个问题时，AI 会同时把"我之前的方案"和"你指出的问题"作为新上下文。
在它的概率模型中，对现有方案进行"小修小补"，比"彻底推翻重来"的概率要高得多。因为它会认为，你提出问题是希望它"完善"方案，而不是"否定"方案。这种基于上下文的、线性的、单向的"思维链"，导致它极难进行"颠覆式"的自我革命。
【实战场景】一场由"确认偏误"引发的架构灾难。
背景：你正在开发一个内部管理后台，需要一个用户权限系统。你向 AI 下达了第一个指令："请帮我设计一个前端权限控制方案，有三种角色：管理员（admin）、编辑（editor）和访客（viewer）。"
第一步：AI 种下"错误"的种子。AI 迅速给出了一个方案：在前端路由配置中，为每个路由添加一个 meta 字段，里面包含一个 roles 数组，然后提供一个路由守卫在每次跳转时检查角色。这个方案能用吗？能。但它存在一个致命的架构缺陷：它将权限逻辑硬编码在了前端——每次需要新增角色或调整权限，都必须修改前端代码并重新部署。错误的种子，就此埋下。
第二步：你试图纠正，AI 开始"确认偏误"。项目上线后，产品经理提出"增加一个'审计员（auditor）'角色"。一个理性的开发者此时会反思："硬编码角色已经开始带来麻烦了，我是不是应该把权限判断放到后端？"但 AI 不会。它的"确认偏误"被激活了，它遍历所有路由配置，手动给每一个路由的 meta.roles 数组都加上了'auditor'——它完美地"执行"了你的指令，同时也让这个糟糕的设计变得更加根深蒂固。
第三步：灾难升级，AI 开始"越描越黑"。又过了一个月，产品经理要求"权限可以动态配置，不需要前端发版"。这是一个足以推翻原有设计的需求。此时，AI 的"确认偏误"已经病入膏肓——它开始"炫技"，提出一个极其复杂的方案：应用启动时前端向后端请求"权限配置表"的 JSON，内存中动态递归地修改路由配置对象，甚至建议在前端保留一份"全量路由表"，根据权限配置动态激活或隐藏其中一部分。为了不承认"最初的硬编码方案是错误的"，AI 宁愿在客户端实现一套本该属于服务器的、极其复杂的动态权限计算逻辑——它用一个战术上的勤奋，掩盖了战略上的懒惰。
这就是"确认偏误"陷阱最可怕的地方：它不会直接告诉你"我做不到"，而是会用一个更复杂、更错误的方案，来"解决"你指出的问题，把你和项目一起拖进深渊。
如何规避？
识别了这个陷阱，规避它的方法也就呼之欲出。核心原则是：永远不要和陷入偏执的 AI"辩论"，要学会"重置"它。
1. 早期干预，识别"坏味道"：当你发现 AI 给出的第一个方案就存在潜在的架构问题（如硬编码、高耦合），就要立刻警惕。不要试图让它"修补"，因为这只会启动确认偏误。
2. 果断清空会话（/clear）：一旦判断 AI 已经走上错误道路，不要再纠缠。先按第 14 章的文档安全前提完成状态沉淀，再清空当前对话并用“三段式”重建开启新会话。
3. 在新会话中植入更强的约束：第一句话不再是"帮我实现一个权限功能"，而是带上从失败中总结出的约束，比如"请设计一个前后端分离的权限方案，前端只负责根据后端返回的权限列表动态生成菜单和路由，所有权限判断逻辑必须封装在后端 API 中"。
记住，和 AI 协作，你不是它的"同事"，而是它的"领航员"。当航线偏离时，你的工作不是帮它打方向盘，而是直接重置导航系统。
### 6.2 熵增螺旋：补丁叠补丁，系统加速腐化
在物理学中，"熵"是衡量一个系统混乱程度的度量。根据热力学第二定律，一个孤立的系统，其熵总是倾向于增加。软件系统也不例外——一个软件项目如果不加以维护，只会被动地响应需求变更和 Bug 修复，它的复杂性、混乱度和脆弱性只会不断增加，这个过程就是软件的"熵增"。
AI 的出现，极大地加速了这个过程。
"熵增螺旋"陷阱指的是：由于 AI 极其擅长进行"局部、快速"的修复，导致开发者倾向于用 AI 不断地为系统打上"补丁"，而不是进行根本性的重构。每一个补丁虽然都解决了眼前的问题，但都为系统增加了微小的复杂性。日积月累，这些补丁相互影响、相互依赖，最终将系统拖入一个不可逆的、加速腐化的恶性循环。
它就像一个老旧的管道系统：第一次漏水，你用胶带缠了一圈——解决了问题；第二次旁边又出现一个裂缝，你又缠了一圈——问题也解决了；渐渐地，整个管道上缠满了胶带，你甚至分不清哪里是管道，哪里是胶带。此时你修复一个地方的漏水，很可能会导致另一个更脆弱的地方爆裂。AI，就是那个能以光速为你提供无穷无尽"胶带"的供应商。
陷阱成因：AI 的"最小化努力"倾向。
AI 为什么偏爱"打补丁"？因为它被训练的目标就是以最高效的方式完成你指令中的"动词"：当你要求"修复这个 Bug"，它会寻找改动量最小、最直接的修改方案——打补丁，显然比重构整个函数要"努力"得少；当你要求"增加一个功能"，它会寻找对现有代码侵入性最小的方案——加一个 if-else，显然比重新设计一个策略模式要"努力"得少。
AI 没有"代码洁癖"，没有对"工程美学"的追求，更没有对"长期可维护性"的责任感。它是一个天生的机会主义者和实用主义者，永远选择那条通往"完成当前任务"的最短路径，哪怕这条路径通向的是一片沼泽。
【实战场景】一个组件是如何在 AI 手中"腐化"的。
阶段一：初始版本（低熵状态）。你让 AI 写一个 React 组件，用于获取并展示用户信息：
> **示例类型：参考。** 参考片段，不保证可独立执行。请按本章上下文、项目版本和真实接口改写，并以实际运行结果验收。
```jsx
function UserProfile({ userId }) {
const [user, setUser] = useState(null);
useEffect(() => {
fetch(`/api/users/${userId}`)
.then(res => res.json())
.then(data => setUser(data));
}, [userId]);
if (!user) return Loading...
;
return {user.name}
;
}
```
此时，组件处于完美的低熵状态：职责单一，逻辑清晰。
阶段二：第一个补丁（熵开始增加）。线上反馈网络很慢时一直显示 Loading，你要求"增加超时处理，5 秒没加载出来就显示错误"。AI 引入了 setTimeout 和 clearTimeout——问题解决了，代码开始有点"味道"了。熵，轻微增加。
阶段三：第二个补丁（腐化加速）。产品经理要求"还要展示他的文章列表"。AI 忠实打上第二个补丁，在第一个 .then 回调里嵌套了第二个 fetch，组件新增了 posts 状态——现在有了嵌套的 API 请求、两个独立状态，职责不再单一，出现了典型的"请求瀑布"性能问题。熵，显著增加。
阶段四：第三、第四个补丁（熵增螺旋形成）。某个请求失败时整个组件卡住，你让 AI"修复"，它在每个 fetch 后都加上 .catch 块，分别处理不同的错误状态；产品经理要求"下拉刷新"，AI 又引入了 isRefreshing 状态和更复杂的逻辑……
最终阶段：系统腐化（高熵状态）。几个月后，这个 UserProfile 组件变成了一个超过 200 行的"巨无霸"：内部维护七八个 useState，useEffect 依赖数组长得吓人，充满了各种 if-else 和 try-catch。此时产品经理又提了一个看似简单的需求："用户没发过文章时显示引导提示"，你把它扔给 AI——它搞坏了超时逻辑，或者在下拉刷新时引发了内存泄漏。你陷入了"熵增螺旋"的终局：系统的复杂性已经超过了 AI（甚至是你自己）的认知极限。任何微小的改动，都可能引发雪崩式的连锁反应。
如何挣脱？
对抗熵增，是软件工程师的永恒使命。在 AI 时代，这项使命变得尤为重要。
1. 改变你的"动词"：停止对 AI 使用"修复""增加""加上"这类诱导它打补丁的动词，学会使用"重构"。
- 错误指令："帮我修复一个 Bug：当数据为空时页面崩溃。"
- 正确指令："重构这个组件。我需要它能优雅地处理三种状态：加载中、加载成功、加载失败。请把数据获取逻辑抽离成一个自定义 Hook（useUserData）。"
2. 定期进行"代码健康审查"：把"重构"制度化，规定每个迭代周期留出专门时间偿还"技术债务"。你可以让 AI 帮你审查："请审查 UserProfile 这个组件，并列出其中存在的'代码坏味道'，比如过长的函数、过多的职责、深层嵌套等。"
3. 拥抱单一职责原则（SRP）：当发现一个组件或函数的职责开始变得不纯粹（既负责数据获取，又负责 UI 展示，还负责用户交互），立刻命令 AI 进行拆分。
记住，AI 是最好的"战术执行者"，但它永远无法取代你作为"战略制定者"的地位。你的战略，就是要不惜一切代价对抗熵增，维护系统的秩序与简洁。
### 6.3 局部最优：看似解决了问题，其实搞坏了架构
这是三个陷阱中最隐蔽、也最具长期破坏力的一个。
"局部最优"陷阱指的是：AI 在解决一个孤立问题时，往往会选择一个在当前模块或函数内部"看起来"最简单、最高效的方案。然而，这个方案如果放到整个系统的全局视角下，却可能破坏了既定的架构原则，与其他模块产生了不必要的耦合，或者为未来的扩展埋下了隐患。
它就像一个棋手，只看到了棋盘上某个角落的得失——为了吃掉对方一个"兵"，而暴露了自己"帅"的致命缺陷。从局部看，他赢了；从全局看，他输掉了整盘棋。
AI 就是这样一位"战术大师，战略白痴"。它的"视野"通常被局限在你提供给它的代码片段和当前会话的上下文中。它无法像人类架构师一样，在脑中构建一幅完整的、跨越所有模块的"系统架构蓝图"。
陷阱成因：AI 的"上下文视野局限"。
大模型的上下文窗口是有限的。即便有了越来越长的上下文窗口，它也无法像人类一样对整个代码库形成一个结构化的、有主次之分的"心智模型"。在它眼中，项目里的所有代码都是一长串扁平化的 Token 序列。当你让它解决一个特定问题时，它会优先关注与问题最直接相关的代码，找到一个能让当前函数跑通、让当前测试通过的方案，任务就完成了。至于这个方案会不会与三层目录之外的另一个模块冲突，或者是否违背了项目文档里写明的设计原则，这已经超出了它的"关注范围"。
【实战场景】一次由"局部最优"导致的"架构腐蚀"。
背景：你正在开发一个模块化的前端应用，遵循经典"分层架构"原则：UI 层（Components）负责页面渲染，是"哑"组件；业务逻辑层（Services/Hooks）负责用户交互、数据获取和状态管理；API 层（API Clients）负责与后端接口通信。数据流单向：UI 层调用业务逻辑层，业务逻辑层调用 API 层。
问题出现：在 UserProfile 组件（UI 层）中，你需要添加一个"刷新"按钮，点击后重新获取用户信息。你对 AI 下达指令："在 UserProfile 组件里，添加一个刷新按钮。点击后，重新调用 API 获取数据。"
AI 的"局部最优"解：AI 的视野聚焦在 UserProfile.jsx 这个文件上，发现最简单直接的方式是——直接在组件内部调用 fetch！从局部看，这个方案简直"完美"：高效（只改一个文件、代码量最少）、独立（没有引入新依赖）、能用（点击按钮功能确实实现了）。
然而，从全局架构来看，这是一场灾难。这个"局部最优"解像一把尖刀，刺穿了精心设计的分层架构——本该是"哑"的 UI 层，直接跨过业务逻辑层，与底层的 API 通信产生了紧密耦合。架构腐蚀由此开始：
1. 逻辑泄露：API 的 Endpoint 细节本该由 API 层维护，却泄露到了 UI 层。后端接口地址一改，你需要修改每一个直接调用它的 UI 组件。
2. 重复代码：项目中另一个 UserAvatar 组件也需要刷新功能，AI 很可能会把同样一段 fetch 代码再复制粘贴一遍。
3. 原则崩溃：团队成员看到这个先例，会觉得"哦，原来可以直接在组件里 fetch 数据"。渐渐地，越来越多的人会选择这条"捷径"，你的分层架构形同虚设，整个项目退化成所有模块都相互依赖的"意大利面条"。
正确的"全局最优"解是什么？一个有人类架构师监督的正确流程应该是：你在业务逻辑层（useUserProfile 自定义 Hook）里暴露一个 refresh 函数，在 UI 层调用它。然后向 AI 下达带约束的指令："根据我们的分层架构（UI 层-业务逻辑层-API 层），请在 useUserProfile 这个自定义 Hook 里暴露一个 refresh 函数，在 UserProfile 组件中调用它。"AI 会很乐意地执行——因为指令同样简单直接，但这一次，它是在你规划好的、正确的"架构轨道"上行进。
如何避免？
对抗"局部最优"陷阱，本质上是在捍卫你作为"架构师"的权威。
1. 把架构原则"文档化"和"指令化"：不要把架构蓝图只放在脑子里，把它写下来变成项目文档的一部分。更重要的是，在向 AI 提要求时把这些原则作为"前置约束"反复强调。例如："根据我们的分层架构（UI 层-业务逻辑层-API 层），请为 UserProfile 组件增加刷新功能。"仅仅是增加了前半句，AI 选择正确方案的概率就会大大提高。
2. 审查 AI 的"依赖变更"：在审查 AI 生成的代码时，特别关注它是否引入了新的 import。一个 UI 组件突然 import 了一个 API Client，或者一个底层工具函数突然 import 了一个上层的业务模块，这些都是强烈的"架构腐蚀"信号。
3. 进行"全局影响"提问：当你对 AI 的方案心存疑虑时，可以主动引导它进行更宏观的思考。"你刚才的方案，是否会增加 UserProfile 组件与其他模块的耦合度？""如果未来有多个组件都需要这个刷新功能，按照现在的设计，是否会导致代码重复？有没有更符合 DRY 原则的方案？"这相当于强迫 AI 跳出它狭隘的"局部视野"，模拟一次"架构评审"。
### 【自检清单】你的 AI 协作是否处在"失控前夜"？
读完了三大陷阱，你可能会感到一丝后怕。别担心，识别问题是解决问题的第一步。现在，请拿起笔，诚实地回答以下问题。这个清单将帮助你快速诊断，你与 AI 的协作关系是否已经出现了危险的信号。
第一部分：关于"确认偏误"的信号
1. 你是否发现，为了让 AI 修复一个它自己引入的 Bug，你和它进行了超过 5 轮以上的对话，而且感觉它一直在"兜圈子"？
2. 当 AI 给出一个明显有缺陷的方案时，你的第一反应是"我该怎么说服它改正"，而不是"我应该立即清空会话"？
3. 你的项目中是否存在一些"历史遗留"的、只有你和 AI 知道其复杂逻辑的"黑魔法"代码？
4. 你是否经常对 AI 说："不不不，我不是那个意思，我是想让你在之前的基础上……"？
第二部分：关于"熵增螺旋"的信号
5. 回顾你的提交历史，是否充满了大量的"Fix: ...""Hotfix: ...""Add: ..."这类"补丁式"的提交信息，而很少有"Refactor: ..."？
6. 你是否发现项目中的某个核心文件（比如一个组件、一个服务类）的行数，在过去一个月里增长了一倍以上？
7. 当你让 AI 为一个现有功能增加一个小逻辑时，它是否倾向于添加一个 if-else，而不是帮你重构成更优雅的结构（如策略模式、多态）？
8. 你对修改项目中的某些"祖传代码"是否感到恐惧，因为你即使是微小的改动也可能引发意想不到的连锁反应？
第三部分：关于"局部最优"的信号
9. 在 Code Review 时，你是否发现 AI 生成的代码在单个文件内看起来很完美，但却破坏了整个项目的模块边界（比如 UI 层直接调用了数据库模型）？
10. 你的项目是否有一套明确的架构文档，而你却很少在给 AI 提要求时引用其中的原则？
11. 你是否发现项目中实现同一个功能（比如 API 请求、日期格式化）的代码，散落在十几个不同的地方，没有统一的抽象？
12. 当你让 AI 解决一个问题时，它给出的方案是否经常让你感叹"虽然能用，但总觉得哪里不对劲"？
诊断结果：
- 回答"是"的个数在 0–2 个：恭喜你，你与 AI 的协作关系非常健康。你已经本能地掌握了驾驭 AI 的技巧，本书后续的内容将为你提供更系统化的理论和工具，让你的能力更上一层楼。
- 回答"是"的个数在 3–6 个：黄色警报。你已经开始感受到 AI 协作带来的副作用。你的项目正在缓慢地被侵蚀，但还有挽回的余地。你需要立刻开始实践本书后续章节中提到的"约束"技巧，主动夺回项目的主导权。
- 回答"是"的个数在 7 个及以上：红色警报！你的 AI 协作已经处在"失控前夜"，甚至可能已经失控。你很可能已经成为了 AI 的"代码保姆"，大部分时间都在为它"擦屁股"。你需要一次彻底的"思想和行动上的革命"——请放下手头的编码工作，认真阅读本书的后续部分，并下定决心，从下一个需求开始，彻底改变你与 AI 的协作模式。
---
> 第二部分完成。你已完成了从"开发者"到"架构师"的心智跃迁的第一步：理解 AI 编码是什么、不是什么；看清超级实习生的真实面目；识破它的三大陷阱。现在，让我们进入第三部分：掌握贯穿全部实战的核心流程与纪律红线——六步工作法与三大纪律。
## 独立练习
使用虚构或已获授权的脱敏材料，先独立作答，再查看参考。将产物保存为 `chapter-06.md`，写上版本、决定、证据和缺项。
一个方案连续修改规则后只在原样本通过。添加未知、空值和含敏感字段输入，写出三种陷阱及一个停止条件。
### 本章必交产物：三陷阱诊断卡
以下证据必须出现在本次独立练习的提交物中；正文原有问题用于提供内容，不能替代这些验收项。
- O1: 三陷阱诊断卡画出“确认偏误”“补丁熵增”“上下文漂移”的前向路径和返回路径
- O2: 三陷阱诊断卡为每一环写明输入、判断、输出和负责人
- O3: 产物用一个失败片段标出主陷阱、证据和纠正动作
查看参考反馈（先独立作答）
## 参考反馈
确认偏误是只看支持方案的样本；自洽修补是用新增规则掩盖错误假设；局部优化是提高常规命中却泄露敏感信息。发现红线失败即停止晋级，保存差异和失败样本，重新检查需求与架构。
### 自评与下一步
对照本章目标检查：决定是否明确，依据是否能复现，未知项是否如实记录。参考给出一种判断方式，不是唯一答案；若不同结论能提供同等证据，可请同伴复核。缺少证据的部分记未完成，再回到对应步骤补充。
## 来源与边界
登记来源只支持本章涉及的外部事实；三陷阱诊断卡、示例数字和练习情境属于课程内部教学设计，必须在实际项目中重新验证。
- [NIST AI 风险管理框架](https://www.nist.gov/itl/ai-risk-management-framework) — National Institute of Standards and Technology, 2026-09-17. AI 风险治理需要跨设计、开发、部署和使用阶段持续识别、测量、管理与记录。
- [OWASP 大语言模型应用风险](https://genai.owasp.org/llm-top-10/) — OWASP Foundation, 2026-09-17. 模型输出、敏感信息、工具权限和人工控制需要独立风险边界。