# 第 4 章 AI 编码是什么，不是什么

## 本章目标

- **O1** 能够区分“概率生成”与“确定性软件”的范围、责任和交接点（产物：AI 编码能力边界表）
  - 证据: AI 编码能力边界表中标明“概率生成”和“确定性软件”各自的范围与负责人
- **O2** 能够构造AI 编码能力边界表，明确纳入、排除与人工验收条件（产物：AI 编码能力边界表）
  - 证据: AI 编码能力边界表中列出至少一项排除项、一个交接点和一个验收条件
- **O3** 能够为一项 AI 编码任务划出可生成、须验证和须人工批准的边界（产物：AI 编码能力边界表）
  - 证据: 产物把一个任务拆成生成、验证和人工批准三个区域

## 学习路径

- **初学者**: 本章迁移任务是：能够为一项 AI 编码任务划出可生成、须验证和须人工批准的边界。先按图中的“边界”关系完成AI 编码能力边界表的第一项证据，再逐项核对责任人与判断标准。
- **有经验者**: 先用当前项目完成这一任务：能够为一项 AI 编码任务划出可生成、须验证和须人工批准的边界。提交AI 编码能力边界表后，再对照正文复核关系类型、缺失证据和授权边界。

## 教学图解

- **必交产物**: AI 编码能力边界表
- **图解类型**: capability-boundary
- **关系语义**: 虚线框表示责任边界，框内三项通过交接点相连，越界或证据不足时必须停止。
- **核心概念**: 概率生成 · 确定性软件 · 人工验收

![第 4 章AI 编码能力边界表教学图](/learning/diagrams/zh/chapter-04.svg)

用边界、交接点和验收条件检验AI 编码能力边界表，而不是把三项误当成同一责任。

图用虚线外框标出AI 编码能力边界表的责任范围，三个卡片分别表示“概率生成”“确定性软件”“人工验收”。箭头只表示已定义的交接，不表示三者可以互相替代；越过外框或缺少验收证据时应停止并升级。

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

## 课程讲解

### 4.1 一个典型场景（计算示例）：四十分钟完成三天的工作

周三下午，你接到一个任务：给团队做一个内部工具，用来登记和查询设备借用记录。需求很明确——一个简单的 Web 页面，能添加借用记录、查看列表、搜索历史。

你估算了一下：前端页面、后端接口、数据库设计、部署上线……至少需要三天。

但是你用 AI 编码工具，只花了四十分钟就做出了一个可用的版本。前端页面能添加记录、能搜索、能分页；后端接口能存储、能查询；数据库表结构已经自动创建好了。

这不是夸张，而是今天 AI 编码工具可以做到的（示例中的工期为演示量级的计算示例，具体数字因项目与工具版本而异）。当然，前提是你要懂得如何正确使用它。

但请把目光放远一点。这个场景的背后，隐藏着 AI 编码时代最核心的张力——效率飞升与质量失控并存。如本书前言所述，许多团队的 AI 之旅是一条"先扬后抑"的抛物线：

- 一开始，AI 展现出惊人的生产力。你只需输入几句自然语言，几百行代码瞬间生成，进度突飞猛进。
- 转折点很快到来：你发现修改一个 Bug，AI 会连带制造出三个新 Bug；为了实现一个边缘功能，AI 悄悄改掉了底层核心数据结构；对话越来越长，AI 开始忘记最初的设定，逻辑变得像一团乱麻。
- 最终，你不得不停下开发新功能的脚步，花比自己手写还要多几倍的时间，去逐行阅读 AI 生成的、晦涩冗长的代码——原本提升效率的工具，反而变成了消耗精力的技术负债。

为什么同样的工具，有人四十分钟交付一个可用版本，有人却陷入"修补烂尾楼"的泥潭？

答案是：他们是否真正理解了 AI 编码是什么，不是什么。

### 4.2 三个必须澄清的误解

在开始之前，我们先消除三个最常见的误解。这些误解如果不澄清，后续的学习就会走弯路。

误解一：AI 编码等同于自动生成整个项目。

你给它一句话，它就输出一个完整的、可直接上线的商业级应用。这是宣传片里的场景，不是现实。

为什么 AI 做不到"一句话生成整个项目"？因为 AI 的"大脑"（大语言模型）有一个根本性的限制：上下文窗口是有限的。它一次能"看到"的信息量有限，对话越长，它越容易"忘记"前面的内容。上下文容量按具体模型的 token 预算计，文件数与代码行数没有通用的超限界线；系统指令、工具结果、历史消息和输出也会占预算。即使材料放得下，冗余与隐含依赖仍可能妨碍有效利用，所以应按任务选择相关材料，并验证模型是否掌握关键约束（参见 [Claude 上下文文档](https://platform.claude.com/docs/en/build-with-claude/context-windows)）。

现实是：AI 擅长完成明确定义的任务单元。你需要把一个大项目拆解成一个个小任务，逐一交给 AI 完成。就像盖房子，你不能对施工队说"给我盖一栋楼"然后就去喝茶了——你需要告诉他们先打地基、再砌墙、再封顶。

误解二：AI 生成的代码可以直接使用。

AI 生成的代码质量参差不齐。它可能语法正确但逻辑错误，可能能跑通但有安全隐患，可能满足当前需求但难以扩展。

为什么 AI 会写出"能用但不安全"的代码？因为 AI 的训练数据中包含了大量"看起来对"的代码——这些代码来自开源项目、技术博客、问答社区，其中很多是"快速实现"而不是"安全实现"。AI 学会了"怎么写代码"，但没学会"怎么写安全的代码"。验收（Inspection）是不可省略的步骤——就像你不会不检查就签收快递。

误解三：AI 编码会让程序员失业。

这是一个被反复讨论但从未实现过的预言。AI 编码改变的是工作的方式，而不是工作的价值。

一个更准确的类比是：计算器的出现没有让数学家失业，而是让数学家从繁琐的手工计算中解放出来，专注于更高层次的数学问题。同样，AI 编码让开发者从"写每一行代码"中解放出来，转向"定义任务、审核产出、整合系统"——职责在升级，而非消失。开发者的核心价值不再是"能写多少代码"，而是"能做出多少正确的决策"。

### 4.3 AI 编码的本质：人定义意图，AI 执行编码

澄清了误解，我们来直面本质。

AI 编码的本质是：人定义意图，AI 执行编码。

你不再需要亲自写每一行代码，但你需要：

- 定义需求（Define Requirements）：清晰地描述你要做什么；
- 设计架构（Design Architecture）：决定系统的结构和模块划分；
- 验收产出（Inspect Output）：检查 AI 生成的代码是否符合预期；
- 整合系统（Integrate System）：把各个模块连接成完整的系统。

这就像从"亲自砌砖"变成"担任包工头"。你不一定比砌砖工人更会砌砖，但你知道整栋楼应该建成什么样。

《基于蓝图规划的 AI 辅助编程实战》把这一转变讲得更透彻：你必须将"写代码"和"做工程"彻底剥离，强力收回两项不可替代的权利，实现身份的升维。

第一，收回"蓝图规划权"。不要把系统的架构设计交给 AI 去猜。你要像真正的首席架构师一样，在 AI 写下第一行代码之前，把庞大的系统降维拆解——精准定义数据库的表结构、核心接口的输入输出、模块之间的依赖关系。你提供的是清晰、无歧义的"实施图纸"，AI 只负责按照图纸把代码这块"砖"填进去。

第二，收回"工程监理权"。永远不要盲目信任 AI 生成的任何未经检验的代码。你要制定极其严格的验收标准，像一个谨慎客观的工程监理一样审核 AI 的每一次输出。一旦发现代码存在逻辑偏移、过度设计或破坏了底层约束，绝不姑息，绝不在歪斜的地基上继续盖楼，而是果断叫停，甚至直接推倒重来。

在 AI 辅助编程的时代，代码本身不再是核心资产，生成代码的动作也不再创造核心价值。只有清晰的系统蓝图和严苛的工程标准，才是保障项目不走向"烂尾"的基石。放弃对"单行代码"的执念，掌控全局的工程交付——这就是从"写代码的人"到"做决策的人"的必然跨越。

### 4.4 AI 编码的高效场景与慎用场景

基于实际的工程实践，AI 编码在以下场景表现最好，也需要注意慎重使用。这两张表值得收藏——它是你决定"这件事要不要交给 AI"的第一判断依据。

高效场景

| 场景 | 说明 | 示例 |
|------|------|------|
| CRUD 接口 | 标准的数据增删改查 | 用户管理、文章管理 |
| 表单页面 | 数据输入和提交 | 注册表单、订单录入 |
| 数据列表 | 查询、筛选、分页 | 订单列表、报表 |
| 单元测试 | 为已有代码编写测试 | 测试一个函数的所有分支 |
| 代码迁移 | 将代码从一种技术栈迁移到另一种 | jQuery 迁移到 React |
| 类型定义 | TypeScript 类型、API 契约 | 接口类型、数据库模型 |

需要注意的场景

| 场景 | 说明 | 建议 |
|------|------|------|
| 复杂业务逻辑 | 需要深度领域知识 | 提供详细的需求描述和示例 |
| 安全敏感代码 | 涉及认证、加密、支付 | 必须进行安全审查 |
| 系统架构决策 | 技术选型、模块划分 | 由人决策，AI 提供参考 |
| 遗留系统改造 | 大型已有系统的修改 | 需要先理解现有架构 |

### 4.5 三个核心概念：蓝图（Blueprint）、里程碑（Milestone）、验收（Inspection）

在进入下一章之前，你需要先熟悉三个贯穿全书的核心概念。它们是这门方法论的三块基石，后续所有章节都围绕它们展开。

蓝图（Blueprint）

蓝图是项目开始前的架构设计文档。它回答三个问题：

1. 我们要做什么？（功能列表）
2. 我们怎么做？（技术方案）
3. 先做什么，后做什么？（开发顺序）

没有蓝图不开工——这是第一条纪律。蓝图在项目中的标准文件名是 CONTEXT.md，它充当 AI 编码工具的工作上下文，包含所有需要了解的架构决策和领域术语。关于蓝图的完整方法论，我们在第 12 章深入展开。

里程碑（Milestone）

里程碑是一个可独立验收的功能单元。把一个大功能拆解成若干个小里程碑，每个里程碑都可以单独测试和验收。

好的里程碑划分就像切蛋糕：每一块大小适中，边界清晰，单独拿出来也能吃。更准确地说，AI 时代的里程碑应该是结构里程碑——一个可独立运行、可测试、逻辑完全自闭环的工程节点（详见第 10 章）。

验收（Inspection）

验收是对 AI 生成的代码进行系统性检查。标准不是"能跑就行"，而是"是否符合蓝图预期"。

验收后的三种结论：

- PASS：符合要求，可以提交；
- NEEDS_FIX：有小问题，需要修复；
- REBUILD：偏离蓝图太多，回滚重做。

三者构成一个闭环：先有蓝图，才有方向；拆成里程碑，才能小步前进；每步验收，才能保证不偏航。

### 【练习】用一句话概括 AI 编码的边界

题目：请用一句话概括 AI 编码的边界——它擅长什么、不擅长什么，人在哪里必须介入。

引导：可以从三个维度思考——① AI 擅长的是"明确定义的小任务"还是"模糊宏大的目标"？② AI 生成代码后，哪一步是绝对不能省略的？③ 从"写代码的人"到"做决策的人"，你多出来的核心职责是什么？

参考答案（供讲师参考）：AI 编码擅长执行"人已定义清晰的、边界明确的任务单元"，不擅长在模糊需求和全局架构中自主决策；因此人必须始终掌握"蓝图规划权"与"工程监理权"——在编码前定义意图与约束，在编码后验收质量，任何未经验收的 AI 代码都不得直接使用。可用一句话概括为："AI 负责把正确的图纸砌成墙，人负责绘制图纸、划定边界并验收每一面墙。"

---

## 独立练习

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

将‘帮我做智能工单系统’改写为单个分类任务。写输入、输出、排除项、三条验收标准与失败处理。

<!-- chapter-artifact-requirement -->
### 本章必交产物：AI 编码能力边界表

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

- O1: AI 编码能力边界表中标明“概率生成”和“确定性软件”各自的范围与负责人
- O2: AI 编码能力边界表中列出至少一项排除项、一个交接点和一个验收条件
- O3: 产物把一个任务拆成生成、验证和人工批准三个区域

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

## 参考反馈

输入是脱敏标题，输出为power、mechanical或unknown。排除自动派单与真实账号接入。验收覆盖正常类别、未知输入拒猜、空输入拒绝；失败保留人工处理入口。确定性练习不是实际模型评估。

### 自评与下一步

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

</details>

## 来源与边界

登记来源只支持本章涉及的外部事实；AI 编码能力边界表、示例数字和练习情境属于课程内部教学设计，必须在实际项目中重新验证。

- [Transformers 文本生成策略](https://huggingface.co/docs/transformers/generation_strategies) — Hugging Face, 2026-09-17. 贪心、采样和束搜索使用不同的下一 token 选择策略，解码选择会影响输出。
- [Claude 上下文窗口](https://platform.claude.com/docs/en/build-with-claude/context-windows) — Anthropic, 2026-09-17. 上下文容量按 token 预算计，系统指令、工具结果、历史和输出都会占用预算。