第 16 章 核心与辅助执行技能

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

课程讲解

本章定位：Coach 是日常交付的流程支撑技能；Workflow 和 Inspector 属于核心执行层；Advisor 是辅助决策技能。这个分类说明它们在工作流中的角色，不等同于导入时的投资优先级：Advisor 可以因常见的决策阻塞而尽早投入，但不接管需求、实施或验收。

16.1 流程教练（Coach）：培养习惯的引导者

设计原理：Coach 是”引导式”的——它不替用户做决策，而是引导用户自己做决策。它的核心价值是培养习惯，而不是完成任务。

为什么它对新手最重要：作为新手，你最需要的是”正确的习惯”。流程教练就是帮你养成习惯的——它引导你走完六步工作法，每一步都提醒你该做什么。你不必记住流程，它会在你旁边一步步引导。用得多了，六步工作法就变成了你的”肌肉记忆”。

如何使用：

开始实现笔记编辑功能。需求：用户可以在编辑页面修改笔记的标题和内容，保存后返回列表页。

AI 会引导你走完六步工作法——帮你拆解里程碑、确认方案、验收代码。

进阶用法：

• 习惯养成：每次开始前提醒你检查蓝图；每次完成后提醒你验收；每次验收不通过时引导你判断是修复还是重建。
• 渐进式放手：随着你对流程的熟悉，Coach 可以逐步减少引导——第一次详细解释每一步；第五次只提示关键节点；第十次只在检测到异常时提醒。

最佳实践：Coach 适合新手和复杂场景，不适合已经熟悉流程的开发者。当你说”开始开发”时触发 Coach，但当你说”完整实现”时应该触发 Workflow。

16.2 自动工作流（Workflow）：从手动引导到自动执行

设计原理：Workflow 的核心不是”自动编码”，而是”自动化的流程管控”。它把六步工作法中需要人工判断的环节替换为规则判断，实现了从需求描述到代码交付的全自动闭环。

想一想六步流程中你需要做什么：拆解时要确认方案、下发指令时要写 Prompt、验收时要审查代码、分支判断时要决定提交还是重建、固化后还要更新蓝图。每一步都在消耗你的注意力。Workflow 的思路很简单：把”需要你判断”的步骤，变成”用规则判断”——验收标准是明确的，所以分支判断可以用规则代替人工；下发指令是模板化的（从蓝图读取技术约束），所以不需要你每次手写。

核心机制：三步迭代循环：

示例类型：伪代码。 伪代码，不可直接执行。它只表达判断顺序，实施时必须补齐真实接口、权限与错误处理。

下发指令 → 里程碑验收 → 分支判断
                             │
              ┌──────────────┼──────────────┐
              ▼              ▼              ▼
           PASS           NEEDS_FIX       REBUILD
       进入下一个里程碑   修复后重新验收    回滚重建

• 第一步：下发指令——Workflow 根据蓝图和需求描述自动生成针对当前里程碑的指令，包含要做什么、技术约束（从蓝图读取）、验收标准；
• 第二步：里程碑验收——AI 完成编码后自动调用验收机制检查：功能是否实现？是否偏离蓝图？代码质量是否达标？边界情况是否处理？
• 分支判断依据验收证据；重复失败时停止并重新诊断。恢复前保护工作并确认目标与授权，不按次数自动重建。

三种模式：

模式	行为	什么时候用
normal	每个里程碑展示计划后等待确认，验收发现问题时等待决策	不确定 AI 是否理解正确，需要人工把关
auto	里程碑计划确认后直接执行，验收自动做分支判断	功能需求明确，信任 AI 的能力
silent	全部自动，静默执行，仅记录日志	批量执行，或者 CI/CD 流程中

上下文重置管理：一个包含多个里程碑的功能，在实现过程中对话会不断增长。当对话变长后，AI 的表现会下降。Workflow 通过上下文重置解决这个问题：每个里程碑完成后，记录当前状态 → 重置上下文，清空对话历史 → 在新的上下文中重新加载蓝图和当前里程碑的指令 → 继续执行。这就像工地上的交接班：每个班次开始前，先看图纸和进度记录，然后开始工作。而不是靠上一个班次的人口头交代。

异常处理：验收反复不通过（3 次 NEEDS_FIX）→ 自动升级为 REBUILD；AI 偏离了当前里程碑 → 温和地提醒它回到当前任务；项目结构变更 → 暂停当前里程碑，先更新蓝图再重新开始。

16.3 监理验收（Inspector）：对比蓝图，找出差异

设计原理：Inspector 的核心是”对比”——对比 AI 生成的代码和蓝图，找出差异。它不评价代码”好不好”，只评价代码”是否符合蓝图”。

为什么需要独立的验收：在传统的 AI 编码实践中，“验收”往往只是开发者看一眼代码，觉得”差不多”就通过了。但问题在于：AI 生成的代码从语法上看几乎总是正确的，真正的问题藏在逻辑和架构层面——一眼看不出来，跑一下也可能正常，直到某个边界条件触发 Bug。

架构偏移的三维检测：

1. 篡改地基——意外修改核心文件（数据库连接配置、认证逻辑、全局中间件）？→ 立即 REBUILD；
2. 过度设计——新增不必要的依赖或抽象？→ 审查后移除；
3. 体积失控——单个文件超过 300 行？→ 拆分后重构。

检测方法：

1. 用 git diff 查看变更文件列表——意外出现的文件修改可能是篡改地基；
2. 检查新增文件的长度——超过 300 行可能是体积失控；
3. 检查新增的依赖——package.json 中出现未预期的依赖可能是过度设计；
4. 对比蓝图的目录结构——代码放在了蓝图未约定的位置可能是架构偏移。

安全审查的自动化：Inspector 可以集成安全审查规则——检查是否使用参数化查询（防 SQL 注入）、用户输入是否转义（防 XSS）、敏感接口是否有权限控制、是否返回了不应暴露的字段。

最佳实践：验收标准在编码开始前就明确，而不是编码完成后临时想；验收报告用结构化模板（功能/代码/架构/安全）；发现架构偏移时，优先 REBUILD 而不是 NEEDS_FIX——修复地基比在歪地基上继续盖楼风险更高。

16.4 辅助决策技能：顾问咨询（Advisor）——AI 给建议，人做决策

设计原理：Advisor 的核心是”提供选项、分析、推荐，让用户做决策”。AI 给建议，你做决定。

什么时候用：遇到技术决策困难时——“用 SQLite 还是 PostgreSQL？""用这个库还是那个库？“。顾问咨询能帮你分析选项的优劣，但记住：最终决策永远是你做的。

进阶用法：让 Advisor 模拟”魔鬼代言人”——用 AI 反驳自己的推荐，暴露方案的弱点。例如：

请分析用 A 方案 vs B 方案的优劣，给出你的推荐。然后，请扮演”魔鬼代言人”，反驳你自己的推荐，说明在什么情况下 A 方案（或 B 方案）会失败。

最佳实践：在技术讨论中，把 AI 当作”最博学的顾问”而不是”决策者”。当你发现自己开始不加分析地采纳 AI 的建议——尤其是架构选型——这就是”AI 依赖”的预警信号。

---

独立练习

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

对‘初学者不会定位unknown误判’设计教练→实施→审查交接，各写一句委派与验收产物。

本章必交产物：技能责任泳道图

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

• O1: 技能责任泳道图为“核心执行”“辅助执行”和“人工授权”分别指定责任人
• O2: 技能责任泳道图标出至少两个接口及其输入、输出和授权边界
• O3: 产物为一个工作流标出每条泳道的输入、输出和授权点

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

参考反馈

教练要求学员先运行并解释失败，不直接代写全部答案；实施只改允许范围；审查独立对照固定期望和差异。咨询给出假设与建议，由有权限的人决定操作。执行者的自评不能代替独立复核。

自评与下一步

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