代码不再是瓶颈之后：我们怎么读 Anthropic 的 AI-native SDLC

Anthropic 最近公开了一份 AI-Native SDLC playbook。核心判断很硬：

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

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

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

我们真正想问的是：

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

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

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

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

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

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

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

这和我们在 模拟芯片公司要不要成为一家 AI 公司 里说的三件事，其实是同一套东西：

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

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

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

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

产品定义
↓
拓扑 / 架构选择
↓
仿真与 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 原厂这条路上 写过：通用 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 很像数字辅助模拟 的原因：模型提供概率性的智能核心，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 也能理解和调用的基础设施。

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

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

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

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

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

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

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

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

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

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

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