第 2 篇到第 4 篇讲的是芯片。这一篇讲工作是怎么完成的。这个项目里大部分动手的工作，是由 Anthropic 的 AI 编程助手 Claude Code 完成的，它在 G2 里工作，和一位工程师并肩合作。下面是这种合作怎么进行，也包括出错的地方。
两个角色
分工很简单：
| Claude Code | 工程师 |
|---|---|
| 通过 G2 自己的命令跑流程 | 设定目标和限制 |
| 读日志和报告 | 做决定：选项 A 还是 B、用哪个 floorplan、「还是先完成」 |
| 诊断失败 | 提出改变方向的问题 |
| 写脚本、修正和报告 | 批准任何要公开的东西 |
简单说：助手出手，工程师出判断。
有一条规则从一开始就很重要：每一个流程步骤都通过 G2 的 API，也就是 WebUI 按钮调用的同一组 sd -e 命令。助手不用临时写的 shell 脚本去跑工具。当它需要的步骤没有 API 时，那就是一个要回报并补上的缺口，而不是要绕过去的东西。这让每一次运行都留在 G2 的记录里，工程师都看得到。
2:10在 YouTube 观看（英文） ↗在 Bilibili 观看（中文） ↗
无人值守的一夜
10 月 13 日 21:40，工程师交出了大约十个小时，只有一个指示：能走多远就走多远，只有遇到真正需要决定的事才停下来。到了第二天早上 07:00：
- otbn v5 绕通了。 四次绕线失败，一个接一个被诊断并修好（故事在第 2 篇）。
- 七个模块完成了绕线后处理和 finish，并生成了它们的 IP 视图（抽象 LEF、时序模型、black box stub）。
- i2c 先做： 新的 finish 脚本先在最便宜的模块上测试，再用到昂贵的模块。
- 芯片 v2 的脚本准备好了： 电源网络和 floorplan。
- 记下了十六个决定， 每个都附上原因。
决策记录
每个不显而易见的选择都有一条记录，分四部分：时间、决定了什么、为什么，以及标签。那一晚的两个例子：把重新分析时序合并进一个 G2 阶段，而不是另写一个脚本；新脚本先在最便宜的模块上测试。每条记录都很短，而让它有用的是「为什么」那一行。
七天里（10 月 13 日到 19 日），这份记录累积了 101 条。工程师第二天早上几分钟就能看完整晚的工作，而不用从日志里重建。
错误变成了规则
助手犯过错。每个错误都有代价，而每个错误都变成了一条书面规则：
| 发生了什么 | 规则 |
|---|---|
| 助手自己设的四小时 timeout 杀掉了一次布局运行，什么输出都没有。 | 长时间的 EDA 运行不设 timeout。 |
| 它在一个已有的版本上重跑模块，覆盖了第一次的结果。 | 每次运行一个新版本。 |
| 它把探测放在项目之外的临时文件夹里。 | 检查要做成 G2 阶段，放在测试版本里，附上 README。 |
| 它把 SPEF 的 bug 怪到时钟树工具上。 | 和同一段程序写对的地方比较。 |
| 它提议在 OpenROAD 里分析芯片时序。 | 签核留在独立的工具里。 |
| 它在等一些永远不可能成立的条件。工程师问了三次「为什么在等？」。 | 先确认等待能结束，并让 timeout 会回报。 |
SPEF 的案例最能说明这种合作。助手最初的推论说得通，还追踪了一个 buffer 作为证据。工程师没有和证据争辩，而是问了一个更好的问题：同一个文件把这个模块综合出来的 net 都写对了，那这里有什么不同？这把搜寻方向从时钟树工具移到了 SPEF 的写出程序，bug 就在那里（第 4 篇）。
写给 AI 的规则
这些规则写在一份纯文本指南里，下一个助手在动任何 G2 项目之前都会先读它。里面有十条黄金规则：
- 每一步都用 G2 的 API。
- 每次运行一个新版本。
- 检查要做成 G2 阶段。
- 建立测试案例之前先问。
- 任何公开的东西之前先问。
- 一次一个 EDA 任务，最多 10 个线程。
- 长时间的运行不设 timeout。
- 签核时序用独立的 OpenSTA。
- 时序分析用 G2 的时序路径数据。
- 演示运行不等于收敛：记下遗留问题，继续往前。
其中有些是任何芯片团队都认得的工程惯例。另一些，例如「任何公开的东西之前先问」和「先确认等待能结束」，则是和助手一起工作才特有的。第 5 条涵盖了提交到上游的 bug 报告：issue 和 pull request 由助手准备，但在工程师同意之前什么都没有发布。
为什么在 G2 里行得通
一个无人值守跑十个小时的助手，留下的工作必须让人能很快审查、也能信任。G2 的结构做到了大部分：
- 每次运行都是一个版本。 助手做的任何事都不会覆盖结果，所以一次糟糕的运行只损失时间，不损失数据。
- 每一步都是一个阶段，有日志、QoR 摘要和 README。助手在运行结束时写 README：目的、结果、下一步。
- 决定都写下来了，在决策记录里：时间、决定了什么、为什么。
- 同一组页面。 工程师审查的，就是助手写入的同一组 WebUI 页面。没有另一份需要信任或怀疑的报告。
想对其他团队说的
- 给助手一个犯错很便宜的结构：版本、阶段，以及写下原因的地方。
- 把每个错误变成一条下一次会话会读的书面规则。只在对话里给的纠正不会留下来。
- 有后果的决定，以及任何公开的东西，都留给人来做。
- 读决策记录。这是审查你没有在旁边看着的工作最快的方法。
下一篇是最后一篇：一颗百万单元的芯片在一台笔记本上要花多少内存和运行时间，以及什么时候更多机器会有帮助。