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

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

课程讲解

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

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

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

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

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

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

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

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

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

4.2 三个必须澄清的误解

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

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

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

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

现实是：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，写上版本、决定、证据和缺项。

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

本章必交产物：AI 编码能力边界表

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

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

查看参考反馈（先独立作答）

参考反馈

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

自评与下一步

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