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

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 的数据，以及你到底是继续用巨头的规则追他，还是换一套规则。

卡点很少是“找不到候选料”，而是评估太慢——手册对不齐、跨部门口径不一致、验证项写不清。AI 适合加速的，是评估前半段，而不是替质量签字。

VAVE 器件评估真正耗时的步骤

• 从 BOM 里找出高成本、高风险或单一来源器件
• 为每颗料准备可对比的规格、封装、引脚和应用限制
• 判断是 Pin-to-Pin 还是功能替代
• 估算改板、改软件和认证的代价
• 形成能给研发、采购、质量共同审核的报告

这些步骤高度依赖 Datasheet 和历史项目经验。如果知识只存在于个人文件夹，评估每次都从零开始。这是 企业知识库不能只做向量检索 的原因之一。

AI 可以加速什么，不能替代什么

可以加速：

• 多份手册的参数、封装、引脚抽取与对齐
• 差异表和风险清单初稿
• 把历史替代结论召回为参考，而不是当最终答案

不能替代：

• 实验室验证、可靠性试验和客户认证
• 供应稳定性和商务条款判断
• 在证据不足时强行给出“可以降本”的结论

Barbot 的原则是 从能回答走向能完成工作：先交出可审核的评估物，再在关键节点交给人。

一条可落地的 VAVE 工作流

1. 明确目标：降本幅度、是否允许改板、认证约束
2. 用 P2P Agent 对候选料做结构化对比
3. 把“条件可替”项写成验证清单
4. 复杂、跨系统的项目用 Harvey Agents 跟踪任务和证据
5. 通过的结论沉淀进 LLM Wiki

适用角色

硬件、采购、质量，以及同时背成本和交期的项目经理。想先看一次对比报告长什么样，可以从已上线的 P2P Agent 开始，免费 5 次。

立即体验 · 预约讨论 VAVE 场景

Barbot 把这件事做成了可试用的 P2P Agent。下面这条流程，既可以人工执行，也可以交给 Agent 加速。

先定义这次替代要解决什么

开始读手册之前，先写清边界：

• 是 Pin-to-Pin 落板，还是只要求功能等效？见 Pin-to-Pin 与功能替代的区别
• 应用是工业、汽车还是消费电子，温度、认证、寿命要求是什么
• 是否允许改原理图、改 PCB、改软件初始化
• 交付物是内部初判，还是给客户/质量的正式报告

边界不清，后面所有参数对比都会失去权重。

从 Datasheet 抽出必须对齐的对象

不要按页码线性阅读。先抽出这些对象，再对齐：

1. 型号、版本、有效日期和订购信息
2. 绝对最大额定值与推荐工作条件
3. 电气参数：名称、典型值、最小/最大值、单位、测试条件
4. 封装、尺寸、焊盘和热阻
5. 引脚定义、电源/地、NC、复用功能
6. 功能框图、时序、启动和复位行为
7. 应用限制、认证、可靠性和勘误

同一参数名经常对应不同测试条件。这是人工最容易漏、也是 两份 Datasheet 对比 最该自动化的一步。

判断替代关系，而不是计算相似度

对齐之后，按风险分层：

• 可直接替：封装、引脚、关键电气和应用限制都覆盖原方案
• 条件可替：要改外围、改软件或缩小工作窗口
• 不可替：引脚冲突、功能缺失、认证或可靠性不满足

国产化替代 和 VAVE 评估 往往落在“条件可替”，需要把验证项写进报告，而不是只给一个分数。

报告必须能被别人复核

一份能用的替代分析至少包含：

• 结论与适用条件
• 参数/封装/引脚差异表
• 风险与建议验证项
• 每条关键判断对应的手册位置

Barbot 的 P2P Agent 按这个结构输出 Markdown、JSON 或 Excel，支持 2 至 5 份 PDF，新用户可免费对比 5 次。

适用角色

采购、研发、FAE，以及负责 BOM 风险和第二供应商 的团队，都可以把这条流程当成标准作业。经验沉淀后再进入 LLM Wiki，下一次就不必从零读手册。

立即体验 P2P Agent · 查看产品介绍

降低风险的方法，不是多开几次选型会，而是把 替代分析流程 做成标准，并且不把“功能能跑”当成“可以量产”。

国产化最容易低估的四类风险

1. 规格窗口：典型值接近，极限值、温度或电源范围更窄
2. 引脚与封装：看起来同封装，NC、电源脚或热焊盘不同
3. 软件与生态：SDK、例程、勘误和原厂支持密度不足
4. 验证被压缩：为了赶交期，跳过边界条件和可靠性项

前两类要用结构化的 Datasheet 对比 尽早发现。后两类要在报告里单独列出，不能埋进“基本兼容”四个字。

选型阶段就该写清替代类型

先判断是 Pin-to-Pin 还是功能替代。国产化项目大量属于后者：允许改板，但必须评估软件迁移和认证周期。

如果团队对外说“国产替代、不用改板”，对内却按功能替代在做，风险会在 SMT 之后才爆发。

验证清单应和差异表绑定

每一条未覆盖的规格，都应对应一项验证，例如：

• 电源纹波与上电时序
• 高低温下的关键外设
• EMC / ESD 相关引脚行为
• SDK 版本与寄存器差异
• 供应批次和生命周期说明

P2P Agent 负责把差异和证据先对齐；Coding Agent 适合 MCU/DSP 场景里核对 SDK 与初始化差异；AI FAE 用来追问原厂资料里的限制条件。

不要用单一分数做决策

国产化需要同时看工程匹配、验证成本和供应策略。分数可以辅助排序，不能代替带证据的结论。这也是 Barbot 强调 可追溯 的原因。

试用 P2P Agent 做一次手册对比 · 预约国产化场景沟通

如果只在缺货当周临时找替代，那是应急采购，不是 BOM 风险管理。

先给 BOM 里的器件分级

不是所有料都值得做完整 dual source：

• 高风险：MCU/电源/接口等停产或交期长、改板代价高
• 中风险：有封装兼容候选，但软件或认证有成本
• 低风险：阻容和标准逻辑，可用 AVL 规则批量处理

高风险器件应按 Pin-to-Pin / 功能替代 分开建档，避免采购系统里只留一个“替代料号”。

第二供应商导入的最小闭环

1. 明确原设计窗口：电压、温度、认证、软件版本
2. 用两到多份手册做 参数、封装、引脚对比
3. 输出可审核报告：结论、差异、验证项、证据位置
4. 小批量验证通过后，写入 AVL / BOM 备注
5. 规定再订货规则：默认主料、缺货自动切、还是必须工程批准

P2P Agent 覆盖第 2、3 步，支持一次上传多份 PDF。更长的跨部门导入，适合放到 Harvey Agents 里跟踪状态和审批。

常见失败模式

• 只比典型值，不比测试条件
• 把评估报告存在个人邮箱，下一次缺货重新来
• 工程批准了样品，采购系统没有冻结替代关系
• 把 国产化候选 直接当已导入第二源

这些失败的共同点，是知识没有回到可维护的底座。评估通过后应进入 LLM Wiki。

适用角色

采购计划、硬件、质量和供应链。目标不是“多一个料号”，而是缺货时仍然知道该用哪颗、凭什么用。

免费做一次替代对比 · 查看 P2P Agent