← 返回 Blog BARBOT / BLOG 代码不再是瓶颈之后：我们怎么读 Anthropic 的 AI-native SDLC Anthropic 把软件流程改成工件驱动的闭环。芯片公司缺的不是同一套 intent.md，而是能进仿真、编译、上板和 FAE 的工程学习系统。 Neal 2026-08-26 09:37:15 观点 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 的数据，以及你到底是继续用巨头的规则追他，还是换一套规则。