# 第 5 章 放弃幻想：大模型是"超级实习生"，不是资深程序员

## 本章目标

- **O1** 能够追踪“生成候选”“工程审查”“证据放行”之间的前向与反馈路径（产物：监督闭环记录）
  - 证据: 监督闭环记录画出“生成候选”“工程审查”“证据放行”的前向路径和返回路径
- **O2** 能够构造监督闭环记录，注明每轮输入、判断和回写证据（产物：监督闭环记录）
  - 证据: 监督闭环记录为每一环写明输入、判断、输出和负责人
- **O3** 能够把一次模型生成转化为含审查与放行证据的监督闭环（产物：监督闭环记录）
  - 证据: 产物记录一轮候选、审查发现、修正和放行依据

## 学习路径

- **初学者**: 本章迁移任务是：能够把一次模型生成转化为含审查与放行证据的监督闭环。先按图中的“反馈闭环”关系完成监督闭环记录的第一项证据，再逐项核对责任人与判断标准。
- **有经验者**: 先用当前项目完成这一任务：能够把一次模型生成转化为含审查与放行证据的监督闭环。提交监督闭环记录后，再对照正文复核关系类型、缺失证据和授权边界。

## 教学图解

- **必交产物**: 监督闭环记录
- **图解类型**: supervision-loop
- **关系语义**: 三环先沿前向路径产生结果，再由返回路径把观察写回；没有回写就不构成闭环。
- **核心概念**: 生成候选 · 工程审查 · 证据放行

![第 5 章监督闭环记录教学图](/learning/diagrams/zh/chapter-05.svg)

沿前向与返回两条路径检查监督闭环记录，确认结果确实改变下一轮输入。

图先从“生成候选”前向经过“工程审查”到“证据放行”，再以虚线返回起点。前向箭头产生结果，返回箭头承载观察和修正；若结果没有回写到下一轮输入，流程只是单程而不是闭环。

> **公开课程改编版。**正文依据内部教材整理，保留概念、流程与示范。案例规模、用时、提升比例及目标阈值均用于教学，不是本站交付成果或通用标准。工具、平台与技能描述需在实际环境核验。提示词不能授予权限；重试次数不自动触发恢复；恢复须先保护工作并确认目标、共享状态和外部数据影响。

## 课程讲解

### 5.1 超级实习生的三大特征：知识渊博但毫无经验、执行力爆表但毫无责任心、逻辑自洽但极易确认偏误

我们之所以在与 AI 的协作中陷入困境，根源在于一个普遍的误解：我们试图与大模型"拟人化"相处，把它想象成一位经验丰富的资深程序员。我们期望它能理解上下文、预见风险、权衡利弊，并对最终的代码质量负责。

这是一个致命的错误。

大模型不是程序员，它更像一个"超级实习生"。这个比喻或许有些冒犯，但它能极其精准地揭示 AI 编程的本质。让我们来详细解剖这位"超级实习生"的三大特征：

特征一：知识渊博，但毫无经验。

这位实习生堪称"行走的维基百科"——他记住了几乎所有主流框架的 API 文档、背下了开源社区的海量代码、通读了问答网站的全部精华。你问他如何用 Go 语言实现一个 gRPC 服务，他能立刻给你一套完整的代码骨架。在"知识广度"和"记忆力"上，他秒杀任何人类程序员。

然而，他毫无"经验"。经验不是"知道"一个东西，而是"踩过"一个坑。经验是知道那个看似平坦的业务场景下藏着一个性能陷阱；是知道某个看似无害的第三方库在特定操作系统下会引发内存泄漏；是知道产品经理口中的"只是一个小改动"背后可能牵涉三个模块的联动重构。

一个典型的差距：你让 AI 给 Web 应用添加"记住我"功能。AI 的"知识"让它立刻生成把认证令牌存在 localStorage 的方案；而人类工程师的"经验"看到 localStorage 就会警铃大作——它存在跨站脚本攻击（XSS）风险，一个有经验的开发者会选择安全性更高的 HttpOnly Cookie。AI 提供了"能用"的方案，经验让你选择了"安全可用"的方案。

特征二：执行力爆表，但毫无责任心。

这位实习生精力无限，从不抱怨 996。你让他写 100 个单元测试，他眼都不眨一下；你让他把项目里所有 var 换成 let 和 const，他瞬间就能完成。他是一个完美的"执行机器"。

然而，他毫无"责任心"。一个有责任心的程序员提交代码前会反复思考："我的修改会不会影响其他模块？边界条件都考虑了吗？日志打得够不够清晰？"AI 没有这种顾虑。它依据上下文预测下一个 token 的分布；贪心解码每步取最高概率项，采样会按分布选择，不等于总取最大值（见 [Transformers 生成策略](https://huggingface.co/docs/transformers/generation_strategies)）。这种生成机制本身不构成对项目工程可靠性的承诺。

一个典型的差距：你的项目有个紧急 Bug，某个关键函数在输入为 null 时会崩溃。你把错误日志和代码扔给 AI 要求"紧急修复"。AI 的"执行力"让它立刻在函数入口加了一句 `if (input === null) { return; }`——程序不崩了，问题"解决"了。而人类工程师的"责任心"会追问：为什么 input 会是 null？是上游哪个环节出的问题？提前 return 会不会让下游产生更隐蔽的 Bug？应该简单返回，还是抛异常让问题在源头暴露？AI 用一个"补丁"掩盖了症状，责任心驱使你去寻找"病根"。

特征三：逻辑自洽，但极易产生确认偏误。

AI 的逻辑推理能力在很多时侯令人惊叹，它能理解复杂的代码依赖并在此基础上修改。然而，它极易陷入确认偏误（Confirmation Bias）——一旦 AI 在一个错误的认知或假设上开始了工作，它后续的所有行为都会倾向于去"证实"和"维护"这个最初的错误，而不是推翻它。这在人类身上也很常见，但在 AI 这里被无限放大，因为它没有"自我反思"的元认知能力。

一个典型的差距：你让 AI 修复一个它自己引入的 Bug——它不会想"我最初的思路可能错了"，它会想"我最初的思路没错，一定是某个细节没处理好"。于是它在错误的地基上不断添砖加瓦，试图把一栋已经倾斜的危楼"扶正"，结果只能越修越乱，最终轰然倒塌。第 6 章我们会看到这个陷阱的完整演进。

小结：将 AI 视为"超级实习生"，意味着我们要从内心深处接受它的不完美。我们要像对待一个真实世界里的实习生那样，充分利用他的优势（速度快、知识广），同时也要用一套行之有效的管理机制，去规避他的劣势（缺经验、无责任、易偏执）。放弃"AI 是完美伙伴"的幻想，是我们迈向有效驾驭的第一步，也是最关键的一步。

### 5.2 你的真实角色：Tech Lead / 架构师 / 产品经理 / 最终决策者

既然 AI 是"超级实习生"，那么我们——人类开发者——的角色是什么？

答案是：Tech Lead（技术主管）、架构师、产品经理，以及最终的"决策者"。

在 AI 原生时代，软件开发的价值链正在发生深刻的重构。过去，一个程序员 80% 的时间可能花在"实现"上——查阅 API、编写业务逻辑、调试语法错误。现在，这些"实现"层面的工作正在被 AI 以极高的效率接管。这并不意味着人类程序员要失业了，而是意味着我们的价值核心，正在从"动手敲代码"，向上游的"动脑做决策"迁移。

我们的工作，不再是把砖头一块块砌成墙，而是成为那个"画出图纸、规定材质、验收质量"的人。具体来说，你作为"决策者"的角色，体现在以下四个关键层面。

### 5.3 四个决策职责：定义边界与约束、拆解需求与任务、验证结果与质量、做出权衡与取舍

决策一：定义边界与约束（The Architect）。

这是你最重要的职责。在项目启动之初，甚至在让 AI 写下第一行代码之前，你就必须像一位城市规划师一样，为整个项目划定清晰的边界。

- 技术选型决策：这个项目用 React 还是 Vue？数据库是 MySQL 还是 PostgreSQL？你不能指望 AI 为你做出最优选择，它只会给你最"流行"或最"常见"的选择。你需要基于团队技术栈、业务场景、性能要求、运维成本做出权衡。
- 架构模式决策：项目采用微服务还是单体？前后端完全分离还是耦合？这些高阶决策定义了代码组织的"骨架"，AI 将在这个骨架内填充血肉。骨架搭错了，血肉再丰满也是畸形的。
- 环境与兼容性决策：需要支持哪些操作系统？最低兼容到哪个浏览器版本？是否有离线的、内网的、信创的特殊运行环境？这些约束必须第一时间以极其明确的语言告诉 AI，否则它会默认在最理想、最现代的环境下生成代码，导致交付时出现灾难性的兼容问题。

决策二：拆解需求与任务（The Product Manager）。

AI 无法理解模糊的、充满人性的商业需求。你不能直接把产品经理的原话"我想要一个更酷的用户登录体验"扔给 AI。你需要扮演翻译官和项目经理的角色，将一个宏大的商业目标，拆解成一系列清晰、明确、无歧义的"技术任务卡"。

- 从"What"到"How"的翻译："更酷的登录体验"意味着什么？是增加社交账号登录？是实现无密码登录（手机验证码、邮箱链接）？还是加入一个动态背景动画？你需要将这些可能性转化为具体的技术需求。
- 任务的优先级与依赖关系排序：是先做 UI 界面，还是先写后端 API？用户注册功能是否依赖邮件发送服务？你需要为 AI 规划出一条逻辑清晰的"工作流"，而不是让它像无头苍蝇一样想到哪写到哪。

决策三：验证结果与质量（The QA & Auditor）。

AI 提交了它的"作业"，你的工作才刚刚开始。你不再是代码的"生产者"，而是代码的"第一质检员"。

- 功能性验证：代码是否实现了预期功能？所有正常业务流程是否都能跑通？
- 边界与异常验证：输入为空、超长字符串、恶意脚本时，程序是否会崩溃？网络断开、服务器 500 时，前端是否给出友好提示？这些都是 AI 极易忽略的"角落"。
- 非功能性验证：性能如何？日志是否规范、足以支撑未来排查？是否遵循团队编码规范？是否存在明显安全漏洞？
- 代码审查（Code Review）：你依然需要做 Code Review，但审查的重点变了——不再逐行检查语法拼写，而是把精力放在更高维度：架构是否合理？模块划分是否清晰？命名是否表达了业务意图？是否存在潜在的逻辑炸弹？

决策四：做出权衡与取舍（The Pragmatist）。

软件工程的本质是"权衡的艺术"。在资源有限、时间紧迫的真实商业世界里，不存在"完美"的方案，只有"合适"的方案。

- "快与脏"vs"慢与美"：这个紧急的线上 Bug，是先用临时的补丁快速止血，等下个版本再彻底重构？还是宁愿让用户多等一天，也要一步到位做最优雅的修复？这个决策，AI 给不了你答案。
- 技术债务的取舍：为了赶项目上线，我们引入了一个临时的技术方案，这会形成一笔"技术债务"。这笔债务是否可以接受？我们计划何时、用什么方式偿还它？你需要像一个精明的财务官一样，管理项目的"技术负债表"。
- 放弃与砍掉：开发过程中，你发现某个功能（比如兼容 IE8）的实现成本远超其带来的价值。此时，你需要有魄力做出"砍掉这个功能"的决策，说服产品经理和老板，而不是让 AI 和你一起在无底洞里浪费生命。

从"写代码的人"到"做决策的人"，这不仅是工作内容的变化，更是一次深刻的思维模式升级。它要求我们跳出代码的细节，从系统、商业和工程的全局视角去思考问题。我们的价值，不再由"写了多少行代码"来衡量，而由"做出了多少个高质量的决策"来定义。

### 5.4 约束是第一性原理：用限制换取确定性

现在我们明确了：AI 是超级实习生，我们是决策者。那么，我们该如何将自己的"决策"有效地传递给这位实习生，并确保它能准确无误地执行呢？

答案就是"约束"（Constraint）。

在 AI 编程的实践中，有效约束是连接人类智慧与 AI 算力的唯一桥梁，是我们将不确定的概率世界，转化为确定的工程产品的核心法则，是整个方法论的"第一性原理"。

很多人对"约束"有天然的反感，认为它代表着限制、不自由。但在工程领域，尤其是在与一个充满不确定性的系统（如大模型）协作时，约束恰恰是通往自由和创造力的唯一途径。

约束的本质：用"限制"换取"确定性"。

想象一下，AI 的潜在能力是一个无限广阔的"可能性空间"。当你给它一个模糊的指令"写一个登录页面"，它可以在这个空间里随机选择一个点——可能是 React 写的、可能是 Vue 写的、可能是用最古老的 jQuery 写的。每一次的结果都可能不同，充满了不确定性。

而"约束"的作用，就是在这个无限空间里画出一个个"围栏"，急剧地缩小 AI 的选择范围：

- 你增加一条约束："使用 React 18 和 TypeScript"——可能性空间被大大缩小；
- 你再增加一条约束："UI 组件库必须使用 Ant Design 5.0"——空间进一步缩小；
- 你继续增加约束："状态管理必须用 Zustand，不能用 Redux"；
- 你最后增加一条约束："不允许使用任何 useEffect 来发起 API 请求，必须封装在自定义 Hook 中"。

当你施加了足够多、足够精确的约束后，AI 的"可能性空间"被压缩到一个很小的候选区域。此时，它生成的结果就从一个不确定的、随机的"猜测"，变成了一个高度确定的、符合你预期的"工程制品"——当然，候选区域仍需你的验收来最终把关。

用限制换取确定性，这就是约束的魔力所在。你放弃了让 AI"自由发挥"的虚幻权力，换来了对最终产出实实在在的掌控力。

约束的价值：降低认知负荷，聚焦高维决策。

当没有约束时，你需要审查 AI 生成的每一行代码，去理解它的实现逻辑、评估它的优劣，这是一个极其耗费心力的过程。而当有了清晰的约束后，你的审查模式发生了根本性的改变——你不再需要问"这段代码写得好不好？"，你只需要问一个更简单的问题："这段代码是否遵守了我设定的所有约束？"它用的是 React 18 吗？用的是 Ant Design 吗？用 Zustand 了吗？有没有在 useEffect 里写 fetch？

你的认知负荷从"理解一个复杂的开放性问题"降低到了"检查一个封闭性的清单"。这让你能把宝贵的脑力资源，从繁琐的代码细节中解放出来，投入到更重要的"高维决策"中去。

约束的类型：构建一个全方位的"护城河"。

这套约束体系就像围绕着你的项目挖掘的一条条"护城河"，确保 AI 这头巨兽永远在你规划好的安全航道内行进：

- 架构约束：最内层的护城河，通过文档和项目结构，定义技术栈、模块边界和设计模式（本书第四部分）；
- 流程约束：控制航行节奏的船闸，通过会话管理和提问技巧，引导 AI 的思考路径，防止它"狂奔"或"兜圈子"（本书第六部分）；
- 环境约束：应对外部环境的堤坝，当 AI 面对它看不见的真实运行环境时，通过日志遥测等手段为它建立有效的感知（本书第六部分）；
- 质量约束：最终的质量检验关卡，通过自动化测试和持续集成，建立一条不可逾越的"电网"，任何不符合质量标准的代码都无法通过（本书第八部分）。

掌握"有效约束"的艺术，就是掌握了在 AI 时代进行复杂软件开发的核心竞争力。它要求我们从一个追求"加法"（不断实现新功能）的开发者，转变为一个精通"减法"（不断排除错误可能）的架构师。

### 【拿来就用】人机协作角色分工卡

请将这张卡片打印出来，或者放在你的桌面背景上。在每一次与 AI 交互前，快速浏览一遍，提醒自己和"搭档"各自的角色与职责。

| 开发阶段 | AI（超级实习生）角色 | 你（技术决策者）角色 |
|---------|---------------------|---------------------|
| 需求分析 | 信息检索员 & 方案生成器：根据关键词快速查找相关技术资料；基于明确指令生成多个初步技术方案草案 | 翻译官 & 过滤器：将模糊的业务需求翻译成清晰、可执行的技术任务；基于经验和项目背景，筛选出可行性高的选项 |
| 架构设计 | 绘图员 & 填充者：根据指定的架构模式生成代码骨架和目录结构；填充你已定义好的模块接口和数据结构 | 总设计师 & 决策者：做最终的技术选型、架构模式和核心模块划分决策；定义所有关键的约束条件（技术栈、版本、兼容性、安全红线） |
| 编码实现 | 代码生成器 & 体力劳动者：编写具体的业务逻辑、工具函数、UI 组件和单元测试；执行重复性、模式化的编码任务 | 指挥官 & 质检员：下达清晰、分步骤的编码指令；审查 AI 生成的代码，重点关注逻辑、边界、性能和可维护性；确认代码是否遵守了所有既定约束 |
| 调试排错 | 日志分析师 & 猜想提供者：根据错误日志和代码分析可能的原因；按需生成调试用的日志打印代码；提出多种可能的修复方案 | 侦探 & 主刀医生：复现问题，收集关键证据；从 AI 的猜想中结合经验判断出最可能的"根因"；做出最终修复策略决策并指挥 AI 执行 |
| 测试验证 | 测试用例生成器：根据函数签名和业务逻辑生成单元/集成测试样板代码；快速生成各种边界情况和异常输入的测试数据 | 质量保证负责人：设计整体测试策略（单元、集成、端到端）；编写核心的、最关键的测试用例；建立并维护自动化测试"电网"，设定不可逾越的质量红线 |
| 重构优化 | 模式匹配执行者：执行明确的、模式化的重构任务；扫描并报告潜在的"坏味道" | 系统健康守护者：识别系统中的"技术债务"和架构瓶颈；做出重构决策、权衡成本收益；确保重构没有破坏现有功能 |

---

## 独立练习

使用虚构或已获授权的脱敏材料，先独立作答，再查看参考。将产物保存为 `chapter-05.md`，写上版本、决定、证据和缺项。

为分类模块写一份委派卡：已知事实、未知项、允许修改文件、禁止操作、输出格式、检查命令。找出一句无法验证的要求并替换。

<!-- chapter-artifact-requirement -->
### 本章必交产物：监督闭环记录

以下证据必须出现在本次独立练习的提交物中；正文原有问题用于提供内容，不能替代这些验收项。

- O1: 监督闭环记录画出“生成候选”“工程审查”“证据放行”的前向路径和返回路径
- O2: 监督闭环记录为每一环写明输入、判断、输出和负责人
- O3: 产物记录一轮候选、审查发现、修正和放行依据

<details>
<summary>查看参考反馈（先独立作答）</summary>

## 参考反馈

将‘像资深工程师一样保证正确’替换为‘只改分类函数，不改样本和期望；给出差异和运行结果’。模型资历是比喻，不能据此信任输出。未知规则应显式列出并请求业务确认。若检查尚未运行，明确写未验证；让执行者列出需要补充的上下文，而不是凭空选择业务规则。

### 自评与下一步

对照本章目标检查：决定是否明确，依据是否能复现，未知项是否如实记录。参考给出一种判断方式，不是唯一答案；若不同结论能提供同等证据，可请同伴复核。缺少证据的部分记未完成，再回到对应步骤补充。

</details>

## 来源与边界

登记来源只支持本章涉及的外部事实；监督闭环记录、示例数字和练习情境属于课程内部教学设计，必须在实际项目中重新验证。

- [Transformers 文本生成策略](https://huggingface.co/docs/transformers/generation_strategies) — Hugging Face, 2026-09-17. 贪心、采样和束搜索使用不同的下一 token 选择策略，解码选择会影响输出。
- [NIST AI 风险管理框架](https://www.nist.gov/itl/ai-risk-management-framework) — National Institute of Standards and Technology, 2026-09-17. AI 风险治理需要跨设计、开发、部署和使用阶段持续识别、测量、管理与记录。