Anthropic 最近公开了一份 [AI-Native SDLC playbook](https://claude.com/blog/the-ai-native-sdlc-playbook)。核心判断很硬：

> **写代码已经不再是整条交付链上最慢的那一段。**

Claude Code 这类 Agent 把实现压到小时级以后，原来按「人写代码的速度」设计的需求会、评审会、安全门禁和发布委员会，反而成了新的堵点。安全团队如果还按人工产出配编制，要么队列堆死，要么代码没审完就发出去。

这份手册值得读。但我们读它，不是为了把 `intent.md` / `spec.md` / `plan.md` 原样搬进芯片公司。

我们真正想问的是：

> **如果软件世界已经承认「实现不再是瓶颈」，芯片公司的工程流程，瓶颈到底在哪一层？**

## 手册真正说清楚的，不是六个阶段，而是交接方式变了

传统 SDLC 是线性接力：产品写需求，架构出设计，工程师实现，QA 验收，发布团队上线，运维盯生产。每一段换人，就换一份文档、一张工单、一次签字。

Anthropic 的改法可以压成一句话：

> **每个阶段结束时，提交一份人和机器都能继续往下做的工件；下一阶段从读这份工件开始，而不是从开会开始。**

意图写成可评审的记录，规格带着组织规则生成，实现先有计划再动代码，测试织进实现而不是卡在阶段边界，治理用钩子在 Agent 动手时拦截，生产异常再写回下一轮意图。人仍然对判断负责，但注意力从「逐行看 diff」转到「在门禁上做决定」。

制度性知识不再只活在老人脑子里，而要写成 Agent 每次开工都会读的约定；真正不能破的红线，也不该只写在培训 PPT 里，而要变成执行期拦得住的约束。

这和我们在 [模拟芯片公司要不要成为一家 AI 公司](/article/analog-chip-company-ai-native) 里说的三件事，其实是同一套东西：

| Anthropic 手册里的机制 | 我们更愿意叫它 |
| --- | --- |
| 可提交、可追溯的阶段工件 | **Trace** |
| 持续评测，而不是「感觉变聪明了」 | **Eval** |
| 人在门禁上接受、拒绝、改写 | **Feedback** |

模型可以换。Claude、Codex、开源 Harness 都可以买。公司真正该留下的，是这条学习闭环。

## 芯片公司不能直接套用的原因，比「行业不同」更具体

软件仓库里，一次合并、一组测试、一次部署，常常就能定义「做完了」。芯片和嵌入式不是。

一颗料从定义到客户量产，中间至少还有：

```text
产品定义
↓
拓扑 / 架构选择
↓
仿真与 Corner
↓
版图与 Tape-out
↓
Silicon vs Simulation
↓
FA / Root Cause
↓
SDK / Example
↓
客户自研板 Bring-up
↓
量产与现场问题
```

这里有三个软件手册覆盖不到的硬约束。

**第一，闭环更长，失败更贵。**  
软件可以连续集成、快速回滚。芯片一次 Tape-out、一次客户停线、一次车上失效，代价完全不是「再开一个 PR」。所以 Agent 不能只对「生成了一段看起来对的代码」负责，必须对后续可验证的结果负责。

**第二，「做完」很少等于 Build Pass。**  
MCU / DSP 上，代码能编译，不等于板子能跑。Clock、PinMux、Flash 地址、Boot Mode、供电、Debugger，任何一环都能让「烧进去了但是没反应」。我们在 [MCU/DSP 原厂这条路上](/article/sdk-to-ai-native-development-agent) 写过：通用 Coding Agent 最容易低估的，正是 Build / Flash / Debug / 现场定位。

**第三，知识不在一个 git 仓库里。**  
芯片公司的关键上下文散落在 Datasheet、Errata、SDK 版本、Application Note、FA Report、客户邮件和资深 FAE 的记忆里。只给 Agent 一份 `CLAUDE.md`，解决不了「这个 Example 该从哪份手册的哪一页迁到客户工程」。

所以，如果一家芯片公司把 Anthropic 的手册理解成「我们也上 Claude Code，再补几个 markdown」，大概率会停在 Demo。

## 真正该借的，是四条原则，不是文件名

### 1. 用工件交接，而不是用会议交接

手册里的 `intent.md` 只是一种载体。芯片场景里，等价物更可能是：

- 这一次要解决什么应用问题，约束是电压、温度、封装还是认证
- 为什么选这个拓扑，不选另一个
- 这次仿真失败在哪个 Corner
- 客户板上的现象、原理图和当前 SDK 版本
- FA 最终怎么定位，有没有回到下一代产品

关键不是扩展名是不是 `.md`，而是：**下一个人、下一个 Agent，能不能只凭这份记录继续做，而不必把口头背景再讲一遍。**

### 2. 人审意图和风险，系统审步骤

手册把人的注意力从「看每一行」挪到「看门禁」。这一点对芯片尤其重要。

资深工程师不该被耗在：再解释一次这个 API 过时了、再帮客户找一次最接近的 Example、再看一遍能编译但上不了板的初始化。这些步骤可以交给 Agent，前提是门禁够硬：

- 编译、链接、静态检查有没有过
- 有没有引用到当前 SDK 和手册，而不是过时例程
- 高风险动作有没有被拦住，比如改错 Flash 地址、动到冻结的旧平台、在没授权时碰量产配置

人留下来做的，是 Signoff：这个规格能不能定，这个替代能不能进 AVL，这块板子能不能认为 Bring-up 成功。

### 3. 政策写成 Skill，红线写成 Hook

Anthropic 把品牌、安全、合规写成 Agent 会加载的 Skill，把「绝不能做」写成执行期 Hook。

映射到芯片公司，Skill 更像：

- 这家原厂的推荐 bring-up 路径
- 这个系列的 Clock / PinMux 约束
- 哪些勘误表必须先看
- FAE 对某类 PWM / 编码器 / CLB 问题的惯用判断

Hook 更像：

- 编译器、仿真器、烧录器必须被调用，而不是只生成代码
- 不能在证据不足时给出可以落板的结论
- 不能跳过当前器件的封装和复用限制
- 生产相关动作必须有明确授权

这也是我们说 [Agent Harness 很像数字辅助模拟](/article/llm-company-as-fabless-soc) 的原因：模型提供概率性的智能核心，Harness 负责把它收成可验证、可恢复、可量产的系统。

### 4. 先有 Eval，再谈「Agent 更强了」

手册把持续评测织进 CI：改了约定、Skill 或 Hook，就跑一组真实任务，看有没有回退；生产事故再变成回归用例。

芯片侧如果没有 Eval，最后只会剩下演示。我们自己做原厂 Coding Agent，也是先整理公开问题和历史支持单，定义什么叫「回答正确」、什么叫「工程上可用」，再去建 Wiki 和 Agent。

评测不该问「像不像专家」，而该问：

- Build Pass Rate 有没有提高
- 从开发板迁到自研板的时间有没有下降
- FAE 接受率是多少
- 错误推荐率是多少
- 客户问题到底有没有被解决

## 芯片公司的 SDLC，其实有两条，不要混成一条

软件手册默认一条链：想法到生产软件。芯片公司至少有两条，而且常常互相卡住。

**第一条是造芯片。**  
定义、设计、仿真、版图、流片、FA。这里的 Agent 如果只停留在「解释电路」，价值有限；它要进入工程轨迹：失败、修改、再验证、最终成功。

**第二条是让客户把芯片用起来。**  
选型、SDK、Example、Clock / PinMux、自研板迁移、Flash、Debug、量产问题。这才是 MCU/DSP 原厂最大的隐性成本，也是 FAE 重复劳动最多的地方。

Anthropic 的手册主要在改第一条在软件世界里的对应物。芯片原厂如果只改内部写代码的效率，不改第二条 Developer Enablement，客户照样卡在「开发板可以、自己的 PCB 不行」。

所以我们才认为：下一步不是再做一个通用 Coding Agent，而是把原厂的 SDK、文档、IDE 和工具链，重组成 Agent 也能理解和调用的基础设施。

## 一张对照表，方便直接拿去开会

| 软件 AI-native SDLC | 芯片 / 嵌入式工程里更接近的东西 |
| --- | --- |
| 意图记录 | 产品定义、应用约束、客户现场问题 |
| 规格与组织 Skill | 原厂知识、SDK 约束、勘误、推荐路径 |
| 先计划再实现 | 先认芯片、认 SDK、认板级约束，再改工程 |
| 持续 Eval | Bring-up、迁移、FAE 问答、回归任务集 |
| Hook 门禁 | 编译 / 仿真 / 烧录 / Signoff / 证据不足就升级 |
| 生产异常写回意图 | Silicon 偏差、客户失效、工单回写进 Wiki |

如果这张表对得上，手册就有用。如果对不上，只是多了一套新名词。

## 老板真正要选的，仍然是信不信

Anthropic 这份手册有一个很少被单独点破的前提：他们相信 Agent 会进入真实工作流，所以愿意重构交接、门禁和评测。

芯片公司也可以选更稳的路：等 Cadence、Synopsys、大模型公司把行业方案做成熟，再跟进。这条路风险最低。

更激进的路是：从今天开始记录工程轨迹，建设 Eval，把 Agent 放进真实 Workflow，允许失败，用三五年去赌一家 AI-native Fabless。

两条路都合理。不合理的是第三种：口头上说「我们很重视 AI」，落地却只接一个模型、做一个 RAG、搭几个工作流，然后用「感觉挺聪明」当验收。

手册最有价值的一句，其实不是任何一个文件名。而是：

> **控制目标可以保留，执法方式必须改。**

芯片公司要保留的控制目标，从来都很清楚：规格、安全、可制造、可量产、客户能用起来。要改的，是还用不用会议、邮件和资深工程师的脑子，去执法这些目标。

原文在这里：[The AI-Native SDLC playbook](https://claude.com/blog/the-ai-native-sdlc-playbook)。我们自己的判断，还是回到那三个问题：一个工程师能不能管理十倍实验，每一次失败能不能变成下一代 Agent 的数据，以及你到底是继续用巨头的规则追他，还是换一套规则。