跳转至

附录 B：30 天实践路径

读完本书后，你理解了 AI 编程系统的运行原理。但"理解"和"能用"之间还有一段距离。这个附录提供一个基于本书原理的实践计划——不是教程，而是一个帮你把认知转化为行动的路径。

第 1 周：理解你的工具

目标： 建立对你正在使用的 AI 编程工具的机制性理解。

对应章节： 第 1-3 章

Day 1-2：观察上下文窗口

做一个实验：开一个新会话，给 Agent 一个需要 10+ 步才能完成的任务（比如"重构这个模块的错误处理"）。观察：

  • [ ] 第几步开始出现"遗忘"现象？（忘记之前的决策）
  • [ ] 上下文满了之后，工具怎么处理？（截断？压缩？报错？）
  • [ ] 同一个任务，拆成 3 个小任务分别执行 vs 一次性执行，哪个效果好？

你在验证的原理： 上下文窗口有限（第 1 章）、累积偏差（第 1 章）、ReAct 循环的信息累积（第 3 章）。

Day 3-4：观察工具调用

打开你的 AI 编程工具的日志或调试面板（如果有的话），观察一次完整的任务执行：

  • [ ] Agent 调用了哪些工具？顺序是什么？
  • [ ] 每次工具调用返回了多少信息？有多少是真正有用的？
  • [ ] Agent 有没有做出"错误的工具选择"？为什么？

你在验证的原理： ReAct 循环（第 3 章）、工具描述的重要性（第 4 章）。

Day 5-7：测量非确定性

用完全相同的提示词，对同一个任务执行 3 次。对比输出：

  • [ ] 3 次输出的核心逻辑是否一致？
  • [ ] 差异出现在哪里？（变量名？代码风格？实现方案？）
  • [ ] 哪些差异是可接受的，哪些不可接受？

你在验证的原理： 温度与采样（第 1 章）、非确定性系统的本质（第 15 章）。

第 2 周：建立规范

目标： 为你的项目编写第一个可用的规范文件。

对应章节： 第 5、12 章

Day 8-9：提取隐性规范

回顾你最近一周和 AI 的交互，找出你反复纠正 AI 的地方：

  • [ ] "不要用 fmt.Errorf，用 errors.New"
  • [ ] "日志用 slog，不要用 log"
  • [ ] "函数不要超过 50 行"
  • [ ] "错误消息用英文"

把这些纠正整理成一份清单——这就是你的隐性规范。

Day 10-12：编写第一个规范文件

把隐性规范转化为你的 AI 工具能识别的格式（.cursorrules、CLAUDE.md、或其他工具的规范文件）：

# 项目编码规范

## 错误处理
- 使用 errors.New 创建错误，不使用 fmt.Errorf
- 所有错误必须 wrap context：errors.Wrap(err, "操作描述")
- 不允许忽略错误（_ = someFunc() 是禁止的）

## 日志
- 使用 slog 包，不使用标准 log 包
- 日志级别：Info 用于业务事件，Error 用于需要人工介入的问题

## 代码风格
- 单个函数不超过 50 行
- 错误消息使用英文
- 公开函数必须有文档注释
  • [ ] 规范文件是否满足"跨任务性"？（对多个任务都有效）
  • [ ] 规范条目之间是否有冲突？
  • [ ] 每条规范是否可验证？（能通过 lint 或测试检查）

Day 13-14：验证规范效果

用同一个任务，分别在"有规范"和"无规范"的条件下执行，对比输出：

  • [ ] 有规范时，AI 的输出是否符合你的编码风格？
  • [ ] 有没有规范条目被 AI 忽略了？为什么？（可能是措辞不够明确）
  • [ ] 迭代规范的措辞，直到 AI 能稳定遵守

你在验证的原理： Skill 的四要素（第 5 章）、规范的演进阶段（第 12 章）。

第 3 周：构建评估能力

目标： 建立一个最小可用的评估集，能量化 AI 的输出质量。

对应章节： 第 15 章

Day 15-17：收集评估用例

从你过去两周的 AI 交互中，挑选 10 个有代表性的任务：

  • [ ] 3 个 AI 做得好的任务（正面基准）
  • [ ] 3 个 AI 做得一般的任务（改进空间）
  • [ ] 2 个 AI 做得差的任务（失败模式）
  • [ ] 2 个边界情况（容易出错的场景）

对每个用例，记录： - 输入（你给 AI 的指令） - 期望输出的特征（不是精确匹配，而是"应该满足什么属性"） - 验证方法（编译通过？测试通过？lint 通过？人工判断？）

Day 18-19：定义质量标准

为你的评估集定义通过标准：

维度 验证方法 通过标准
语法正确性 编译器 零错误
功能正确性 单元测试 全部通过
规范遵守 Linter + 规范检查 无新增 warning
修改范围 diff 行数 只改必要部分

Day 20-21：跑一次基线评估

用你当前的配置（规范 + 工具），在 10 个评估用例上跑一遍：

  • [ ] 记录每个用例的通过/失败
  • [ ] 计算总体通过率（这是你的基线）
  • [ ] 分析失败用例的根因（是规范不够明确？是上下文不足？是任务太复杂？）

你在验证的原理： 从断言到评估的思维转变（第 15 章）、评估流水线（第 15 章）。

第 4 周：建立团队流程

目标： 建立最小可行的团队治理流程。

对应章节： 第 16 章

Day 22-23：规范入库

  • [ ] 把你的规范文件提交到项目仓库（和代码一起版本管理）
  • [ ] 写一个 commit message 说明规范的目的和适用范围
  • [ ] 通知团队成员这个规范的存在

Day 24-25：指定 Owner

明确以下职责的承担者（在小团队中可以是同一个人）：

  • [ ] 规范维护者：谁负责更新规范？（当项目技术栈变化时）
  • [ ] 评估负责人：谁负责维护评估集？（当发现新的失败模式时）
  • [ ] 模型升级决策者：谁有权决定切换模型？

Day 26-27：建立更新触发条件

定义什么时候需要更新规范和评估集：

  • [ ] 项目技术栈变化时 → 更新规范
  • [ ] 发现 AI 的新失败模式时 → 扩充评估集
  • [ ] 模型升级时 → 在评估集上跑回归
  • [ ] 每两周 → 15 分钟规范复盘（即使没有变更）

Day 28-30：复盘与迭代

回顾这 30 天的实践：

  • [ ] 你的规范从第一版到现在改了几次？改了什么？
  • [ ] 评估集的通过率从基线到现在变化了多少？
  • [ ] 团队成员对 AI 输出的满意度有没有提升？
  • [ ] 下一步最需要改进的是什么？

30 天之后

完成这个路径后，你的团队应该处于 L2 级别（有规范、有知识注入）并且正在向 L3（有评估、有可观测性）迈进。

持续迭代的节奏：

频率 动作
每天 观察 AI 输出，发现新的失败模式
每周 更新评估集（如果有新的失败模式）
每两周 15 分钟规范复盘
每月 评估集全量回归 + 质量趋势分析
模型升级时 灰度 → 评估 → 全量（或回滚）

记住： 这不是一次性的工作，而是一个持续运营的过程。AI 系统的质量不会自动保持——它需要和代码一样被持续维护。