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

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

这个观察最早是 Karpathy 提出来的。有意思的地方在于：模型架构和模拟芯片的内部构造，居然能对上。芯片主流还在往集成走，BMS、AFE、SoC，包括 DSP，并且把很多模拟功能数字化。从另外一个角度看，两边是在殊途同归。

为什么说它像？可以分几层看。

第一层：AI 公司确实很像 Fabless

大模型公司掌握的是：

• 模型架构
• 数据与训练配方
• Post-training
• Eval
• 推理系统
• Agent Harness
• 产品定义

但大量底层算力由 NVIDIA、AMD、Cerebras 及云计算平台提供。这和 Fabless 设计芯片、晶圆厂负责制造非常相似。

甚至可以把一次大规模训练理解成「软件世界的 Tape-out」：成本非常高，训练完成后再通过后训练、蒸馏和推理优化，做成不同产品版本。

第二层：模型正在经历「从单功能芯片到 SoC」的过程

这有点像 MoE。MoE 模型内部包含大量 Expert 子网络，通过 Router 对每个 Token 进行动态路由，只稀疏激活其中少数 Expert 参与计算。

早期 LLM 更像一颗单功能模拟芯片：

输入文本 → Transformer → 输出文本

现在的模型系统则越来越像 SoC：

语言理解
+ Reasoning
+ Vision / Audio
+ Tool Calling
+ Computer Use
+ Memory
+ Retrieval
+ Code Execution
+ Verifier
+ Safety Policy
+ Multi-Agent Routing

这很像模拟芯片的发展：

运放
→ 仪表放大器
→ PGA / ADC / DAC
→ AFE
→ 集成诊断、校准与数字接口
→ 面向 BMS、数字电源、汽车传感器的系统级芯片

以前客户需要运放、ADC、基准源、Mux、保护电路、MCU 分别搭建；后来原厂把高频组合封装成 AFE 或专用 SoC。

AI 模型也会发生这种能力内收。很多能力一开始依赖外部脚手架，比如单独的 Planner、Router、Reflection 模块以及 Sub-agent 调度器。但随着模型能力增强，尤其是通过 agentic post-training 和 reinforcement learning，越来越多原本在外围的能力开始成为模型的原生能力。模型可以自己做任务分解和规划，自主决定何时调用工具，甚至生成和调度 Sub-agents，再通过并行执行完成复杂任务。

现在 OpenAI 和 Anthropic 逐渐把这些能力集成进模型及其 Runtime，形成越来越完整的「Agent SoC」。

第三层：MoE 很像内部异构模块，但不能简单等同于多个芯片

MoE 可以类比成一颗芯片内部存在多个专用模块，由 Router 根据输入选择性激活：

输入任务
  ↓
Router
  ├─ 代码 Expert
  ├─ 数学 Expert
  ├─ 语言 Expert
  ├─ 视觉 Expert
  └─ 工具使用 Expert

它更接近：

• 异构 SoC
• 条件激活的功能模块
• Power Gating
• 共享平台上的多个专用计算单元

不是每次都让全部参数参与计算，就像芯片不会让所有外设和处理单元同时满功率运行。

但是，模型里的 Expert 不一定能明确解释成「代码模块」「数学模块」。它通常是训练过程中自动形成的参数分工，边界没有模拟芯片模块那么确定。

更深的一层：Agent Harness 特别像「数字辅助模拟」

现在大家都在推数字电源一类的方向：把很多模拟功能，内化成数字校准、补偿和控制。

模拟芯片的趋势并不是模拟部分消失，而是：

用数字校准、补偿、控制、诊断和通信，把一个存在偏差、噪声和工艺波动的模拟核心，变成更稳定、更可量产的系统。

LLM 也是概率系统。它存在：

• 幻觉
• 输出不确定
• 长任务漂移
• 工具调用失败
• 上下文丢失
• 结果难以验证

因此，Agent 系统开始在模型外围加入确定性的工程结构：

概率模型
+ 权限控制
+ 状态机
+ Tool Schema
+ Sandbox
+ Checkpoint
+ Memory
+ Build / Test
+ Verifier
+ Eval
+ Human-in-the-loop

这非常像：

模拟核心
+ 数字校准
+ 状态机
+ 保护电路
+ 故障诊断
+ 数字接口
+ Production Test

Agent Harness 之于大模型，类似数字辅助电路、校准和保护系统之于模拟芯片。模型提供概率性的智能核心，Harness 负责把它约束成可验证、可恢复、可量产的工程系统。

模型也会像芯片一样形成产品矩阵

未来不会只有一个「最强模型」覆盖所有任务，就像模拟芯片公司不会只生产一颗万能芯片。

就像 OpenAI 的 Codex Spark：它之所以在更强的模型之后仍然存在，就和一家公司推出高性能 SoC 以后，仍然保留高速运放或低功耗产品一样。

它不是能力最强，但它在延迟、成本和具体负载上具有更好的 PPA。

模型也开始出现自己的「PPA」：

• Performance：任务完成质量
• Price：训练与推理成本
• Agility：响应速度和交互延迟

但是又不能完全等同

毕竟一边是软件，一边是硬件。主要有三个区别：

1. 芯片 Tape-out 后物理结构基本固定；模型还能通过后训练、上下文、工具和 Harness 持续改变行为。
2. 芯片有明确的电气指标和 Sign-off；模型输出具有概率性，Eval 很难做到绝对完备。
3. 很多 Agent 能力并没有集成在模型权重里，而是部署在模型外围的 Runtime、工具和产品层。

所以简单来讲：

大模型不是一颗芯片，而是「模型核心 + 推理芯片 + Agent Harness + 工具生态」共同组成的系统。

这也是为什么我们更关心 芯片行业 Agent 如何从“能回答”走向“能完成工作”，以及一家模拟芯片公司要不要因此重建自己的工程学习系统。

这也带来了一个新问题：

当通用 Coding Agent 已经越来越强，MCU/DSP 原厂为什么还需要自己的 Coding Agent？

先看几家原厂现在怎么走。

TI：把 Claude Code / Codex 接进 CCStudio

TI 在 2026 年发布的 CCStudio 21 里已经明确支持 Codex，并持续增强 AI Agent / Skill 相关能力。CCStudio 本身覆盖 C2000、DSP、Sitara、SimpleLink 等嵌入式产品，所以这不是单纯「代码聊天」，而是把 AI Agent 接到真实 IDE、工程、Build / Debug 环境里。TI 官方文档甚至专门提供了 CCStudio + AI / Code Assistants 的配置体系。(Texas Instruments)

我们也把 Coding Agent 接到了这套生态里。TI 这边仍以 CCS Studio 为主，原厂的开发者习惯已经在 IDE 里，Agent 必须走进这个现场，而不是另开一个窗口。

Microchip：直接做自己的 MPLAB AI Coding Assistant

Microchip 这条路线更明确：基于开源 Coding 工具做二次开发，持续注入原厂上下文，目标之一就是减少幻觉。

它推出了 MPLAB AI Coding Assistant，基于 Continue 做 Microchip 专用版本，直接面向自家产品开发，支持：

• Autocomplete
• Generate / Edit Code
• Review / Explain Code
• Microchip-specific Chat
• 在编辑器里直接访问 Datasheet

Microchip 自己强调，这套工具持续注入 Microchip-specific information，相比公共 AI 工具要减少幻觉。(Microchip)

更进一步，它已经加入 Agent Mode + MCP Server。MCP 可以让 Agent 直接查询 Datasheet、Evaluation Board User Guide、Compiler Guide、Example Projects、Training Videos 等官方资料。(Microchip Developer Help)

Microchip 还在 2025 年发布了独立的官方 MCP Server，让兼容的 AI / LLM 获取经过验证的产品规格、Datasheet、库存、价格和交期等结构化信息。(Microchip)

所以 Microchip 的路线已经很接近：

Coding Agent + 原厂知识接口。

ST：先解决「资料太多、找不到正确答案」

ST 当前更偏知识入口，路线和 TI 有相似之处：IDE 已经很成熟，用户习惯已经在那边。接下来要决定的是：做一个全新的 AI 入口，让开发者更快用起来；还是站在现有使用路径上，让原来的工作做得更好。

它推出的 STM32 Sidekick 主要基于 STM32 官方资料回答开发者问题，包括产品文档、产品信息和官方内容，给开发者一个自然语言入口去找技术答案。ST 公开说明其底层采用 RAG，把官方资料作为回答依据。(STMicroelectronics)

所以 ST 目前更像：

STM32 官方可信知识助手。

再结合原有 STM32CubeMX、CubeIDE、HAL / LL 等开发工具，实际上也是在逐步降低开发者找资料、配置工程和上手 STM32 的成本。

乐鑫：开始把 Agent 往 Build / Flash 方向推

乐鑫通过 ESP-IDF，让 AI 更好地理解代码和文档，并进一步进入项目配置、Build、Flash 等真实开发动作。

乐鑫已经开始通过 ESP-IDF 的 Agent / MCP 能力，让 AI 不只理解代码和文档，而是进入真实开发执行。

它代表了另一个方向：

从 AI Coding 继续往 AI Development Execution 走。

把四家放在一起看，趋势其实很明显

它们路线不同，但共同点非常清楚：

原厂正在把过去给「人」使用的 SDK、文档、IDE、Example 和工具链，逐渐变成 Agent 也可以理解和调用的基础设施。

这里会分出两条路：一家 AI 公司去做 MCU 场景下的 Coding Agent，还是一家 MCU 公司自己去适配 AI Agent。角度不同，做出来的东西也不一样。

我们认为下一步不是再做一个通用 Coding Agent，而是帮助 MCU/DSP 原厂把自己的 Developer Ecosystem 重新组织成 Agent-native 的 Developer Infrastructure。

上一篇我们也写过：芯片公司对 AI 的认可度，决定了它接下来的产品形态，是围绕 AI 重建，还是只在原有基础设施上加一层 AI。差别很大。

下面按具体场景说清楚：为什么 DSP、MCU 这个场景特别需要 AI。

MCU/DSP 原厂最大的成本之一，是让客户把芯片真正用起来

这不是拷一个 hello_world 就结束。下面是一些真实会卡住项目的环节。

从 Demo / EVM 到客户自研板的 Bring-up

NXP 官方的 Custom Board 流程就要求重新处理 board.c/h、Clock、PinMux、CMake / Kconfig、启动配置、Flash runner、Debug runner；Flash / Debug 又涉及 LinkServer、J-Link、Flash Address。客户第一次从原厂开发板迁到自己的 PCB，本身就是一整条工程链。

外设初始化和系统资源配置

GPIO、Clock Tree、PinMux、ADC、PWM、DMA、Interrupt、Middleware 之间有大量约束。STM32CubeMX 之所以专门提供 Pinout 冲突处理、Clock Tree 校验、Peripheral 配置和初始化代码生成，就是因为这部分本身就是 MCU 开发的主要上手成本。ST 官方甚至直接把「降低开发时间」和「减少配置错误」作为 CubeMX 的核心价值。

复杂外设和实时控制功能的二次开发

TI 的 C2000 CLB 可以做自定义 PWM、修改 ePWM、编码器接口、自定义串行协议，甚至替代部分 FPGA / CPLD 功能。官方支持里就有客户问「外部触发的一次性 PWM 怎么实现」，FAE 会定位到具体 CLB Example，再告诉客户怎么把示例迁到自己的器件和 SysConfig 配置。

DSP / 实时控制并不是「写几个寄存器」

以 C2000 MotorControl SDK 为例，原厂需要支持 FOC、无感 / 有感控制、Resolver / 增量 / 绝对编码器、电流采样、MTPA、Field Weakening、启动失败恢复、失相保护、振动补偿、CAN / FSI / EtherCAT；CLA 又涉及 CPU 与协处理器之间的内存、消息 RAM、触发和实时任务。客户经常要的不是 API 解释，而是一段能进入真实控制系统的应用方案。

SDK 版本、器件迁移和平台迁移

一个 Example 在旧芯片能跑，不代表换一颗料还能直接跑。TI 专门做了 C2000 SysConfig migration；NXP、Infineon 都有 BSP / SDK version、custom BSP 和迁移体系。Infineon 就明确要求自定义硬件时重新处理 clocks、pins、peripherals、BSP 和 library versions。

Build / Flash / Debug / 现场故障定位

这是通用 Coding Agent 最容易低估的一块。代码能编译，不等于板子能跑：Boot Mode、Flash 地址、Debugger、UART、时钟、供电、Pin 配置，都可能导致「烧进去了但是没反应」。NXP 的官方 Bring-up 文档就明确涉及 Flash boot mode、debug probe、terminal 设置；Infineon 的真实支持案例里，遇到客户系统异常，官方会要求进一步查看 schematic + software code，才能由 FAE 协助定位。

培训、Example、FAQ、Debug Tips 本身就是 FAE 的巨大重复劳动

TI 的 CLA 官方学习路径非常典型：Workshop → Examples → FAQ / Debugging Tips → System Use Cases。ST 对自己的 FAE 描述也包括 firmware development、customer support、training。原厂今天本来就在花大量人力，把「芯片怎么用」不断解释、演示、迁移、Debug 给客户。

我们的答案是：

因为 MCU/DSP 行业真正的竞争，并不只是「谁能生成更多代码」，而是谁能够帮助开发者更快、更低成本地把芯片真正用起来。

对于 MCU/DSP 原厂来说，最大的壁垒之一，并不是芯片设计本身，而是围绕芯片建立起来的 Developer Ecosystem。

MCU/DSP 最大的成本：让客户真正把芯片跑起来

一颗 MCU 进入客户项目之后，难点才刚开始。真正难的是一整套开发者生态：选型、开发环境搭建、SDK 和 Example 学习、Clock 与 PinMux 配置、外设初始化、自研板迁移、Build、Flash、Debug，以及后续的性能优化和量产问题。任何一个环节出错，都可能让项目卡上几小时、几天，甚至更久。现在很多场景仍然是原厂 AE 驻场，帮客户调试、帮客户快速上手。

一个工程师从拿到芯片，到最终产品运行，中间通常需要经历：

选型
↓
安装工具链
↓
学习 SDK
↓
理解 Example
↓
配置 Clock
↓
配置 PinMux
↓
初始化外设
↓
迁移到自研板
↓
Build
↓
Flash
↓
Debug
↓
性能优化
↓
量产问题处理

其中任何一个环节出现问题，都可能导致项目延期。

很多时候，客户遇到的问题并不是：

「我不会写这段 C 代码。」

而是：

「这个功能应该从哪个 Example 开始？」

「这个 SDK 版本应该用哪个 API？」

「为什么开发板可以运行，换成自己的 PCB 就不工作？」

「这个问题到底是软件问题，还是 Clock、Pin、硬件配置问题？」

这也是为什么 MCU/DSP 原厂需要大量 FAE 和应用工程师支持。

原厂最宝贵的资产，其实是 Developer Enablement 能力

原厂最宝贵的资产，其实是一颗 MCU 从出生到客户量产的全生命周期经验。同类客户可以复用，持续沉淀，形成团队资产。

一个优秀的 MCU/DSP FAE，价值并不只是熟悉 Datasheet。

更重要的是，他知道：客户提出一个需求以后，应该参考哪个 Example，应该使用哪个外设模块，应该修改哪些配置，当前 SDK 版本有哪些坑，哪个问题优先检查硬件，哪个问题优先检查软件。

例如，一个客户想实现特殊 PWM、编码器接口或者可配置逻辑功能。

对于普通开发者来说，需要搜索 User Guide、Application Note、Example、SDK 文件和 Forum。

但一个经验丰富的 FAE，可能几分钟就能判断：

• 是否适合使用 CLB
• 哪个 C2000 Example 最接近
• SysConfig 如何配置
• 哪些寄存器需要注意
• 如何迁移到客户工程

这类能力非常宝贵。但问题是，它长期存在于 FAE 个人经验、客户邮件、历史工单、培训材料、示例代码和工程师记忆里，很难规模化复制。

所以我们认为：

MCU/DSP 原厂真正需要解决的问题，不只是代码生成，而是如何把 Developer Enablement 能力产品化。

我们正在做的：原厂定制 Coding Agent

我们的思路不是先做一个 Coding Agent，而是先从评测开始。

我们先把 TI、Microchip 这类原厂公开问题，以及真实 MCU/DSP 开发支持场景中的历史问题，整理成 Eval 数据集，先定义什么叫「回答正确」、什么叫「工程上可用」。在这个基础上，再构建自己的 LLM Wiki / Code Wiki，把 Datasheet、Manual、SDK、Example、版本关系和真实问题，逐步组织成一套可持续迭代的知识基座。

这个知识基座同时服务两个入口：

• 问答：FAE、AE 日常大量问题，其实通过高质量 Chatbot 就能解决；问答本身也是持续收集真实问题、发现 Wiki 缺口、推动知识回写的入口。
• Coding Agent：当任务从「告诉我怎么做」进入「帮我改代码、迁移工程、Build、Flash、Debug」时，再进入真正的生产执行。

我们之所以自己搭 Harness，而不是完全依赖 Claude Code 这类现成 Agent，是因为我们需要看到和控制完整的检索、工具调用、执行轨迹、失败原因和中间状态，才能把这些 Trace 持续回流到 Eval、Wiki 和 Agent 策略里做迭代。

简单说，我们真正做的是一条闭环：

Eval
↓
Wiki
↓
问答 / Coding Agent
↓
Trace
↓
回写
↓
再 Eval

Coding Agent 只是其中的执行层。真正长期积累的，是知识基座、评测体系和可观测的 Agent Harness。

这也是我们正在探索的方向：帮助 MCU、DSP 原厂构建属于自己的 AI-native Developer Ecosystem。

相关产品见 Coding Agent 和 MCU / DSP 场景说明。如果原厂希望把 SDK、文档和工具链做成 Agent-native 的开发者基础设施，欢迎 预约沟通。

AI 到底会怎么改变一家模拟芯片公司？

不是给工程师装一个 Coding Agent，不是做一个企业知识库，也不是做一个 FAE 问答机器人。

我想讨论一个更激进的问题：

一家模拟芯片公司，在 AI 时代，是不是也应该成为一家 AI 公司？

这句话听起来很像废话。

因为今天几乎所有公司都可以说自己是一家 AI 公司。

银行可以说自己是 AI 公司，制造业可以说自己是 AI 公司，软件公司当然更可以。

所以真正的问题不是：

“你有没有用 AI？”

而是：

AI 会不会改变你的生产函数、组织方式、数据资产，以及这家公司的第二条增长曲线？

如果不会，那你只是一个 AI 用户。

如果会，那才叫 AI-native。

一、首先是一个最简单、但可能也是最重要的问题：你到底信不信 AI？

我越来越觉得，今天企业面对 AI，很多问题最后并不是技术问题。

而是一个非常简单的问题：

老板到底信不信？

不是嘴上说“我们很重视 AI”。

而是你是不是真的相信：

未来三年到五年，AI 会重构大量知识工作和工程工作。

如果你不相信，那其实非常简单。

买几个 Copilot。

做个企业知识库。

给员工接个大模型。

成立个 AI 兴趣小组。

每年汇报一下“AI 提效成果”。

完全没问题。

因为你的基本假设仍然是：

公司原来的生产方式没有发生变化，AI 只是多了一个效率工具。

但如果你真的相信 AI 是一次类似互联网、移动互联网，甚至可能更大的生产力变化，那逻辑就完全不一样了。

这时候应该问的是：

如果今天重新设计一家模拟芯片公司，它的组织、研发流程、数据系统、产品定义方式，还应该和十年前一样吗？

我觉得这是两个完全不同的世界。

二、模拟芯片公司过去的商业逻辑其实非常清楚

传统模拟芯片公司的商业模型很好理解。

做一颗芯片。

定义产品。

设计。

验证。

流片。

量产。

卖出去。

最后公司的价值可以相对清晰地落到：

有多少产品 × 每个产品卖多少颗 × ASP × 毛利率。

再进一步，就是：

产品组合多不多？

客户多不多？

Design-in 多不多？

研发投入多少？

每年能推出多少新品？

制造成本怎么样？

生命周期有多长？

这些东西最终都能够映射成收入、利润和现金流。

这是一家非常典型的硬件公司逻辑。

而且这个商业模式过去几十年已经被证明非常成功。

问题是：

AI 时代会不会在这个模型上面，长出第二层东西？

三、我的第一个暴论：模拟芯片公司未来可能同时是一家“工程数据公司”

注意，我这里说的不是：

把芯片数据卖出去。

这很危险，也不现实。

我说的是另外一种东西。

一家模拟芯片公司每天都在产生极其高价值的数据。

但是今天，我们通常根本没有把它当成“资产”。

比如：

为什么这个产品当初定义成这个参数？

为什么最终选择这个拓扑，而没有选另外一个？

一个模拟工程师做了 30 次仿真，前面 29 次为什么失败？

哪个 Corner 出现了问题？

为什么这里最后改了这个参数？

为什么第一次 Tape-out 回来之后，Simulation 和 Silicon 对不上？

FA 最终是怎么找到 Root Cause 的？

客户在一个非常特殊的应用场景下为什么出现问题？

最后怎么解决？

这个经验有没有回到下一代产品？

这些东西是什么？

其实就是：

Problem
↓
Context
↓
Decision
↓
Action
↓
Tool Result
↓
Failure
↓
Correction
↓
Final Result

这是一整条真实的 Engineering Trace。

今天互联网大模型能够看到很多 Datasheet。

能够看到论文。

能够看到教材。

也能够看到很多公开代码。

但它看不到一家真实芯片公司过去十年：

到底是怎么把一颗颗芯片做出来的。

尤其看不到那些失败。

而恰恰是：

失败 → 修改 → 再验证 → 最终成功

这类数据，可能才是未来 Engineering Agent 最值钱的东西。

所以未来一家模拟芯片公司，除了拥有：

IP、产品、客户、供应链、人才

之外，可能还会多一个非常重要的资产：

Machine-readable Engineering Experience。

机器可以理解、检索、执行和学习的工程经验。

四、为什么现在这个东西突然开始有价值？

因为以前这些数据其实也存在。

2015 年一样有仿真 Log。

一样有 FA Report。

一样有项目复盘。

一样有工程师改代码。

但是那时候，机器没有足够强的能力去“消费”这些东西。

今天开始不一样了。

LLM Agent 可以：

理解自然语言；

理解代码；

查找文档；

调用工具；

运行编译器；

运行仿真；

读取 Log；

根据结果继续修改；

再执行下一步。

于是第一次出现了一种可能：

企业过去散落的工程经验，可以被组织成机器能够使用的工作记忆。

这也是为什么最近 EDA 行业已经明显从“AI 辅助设计”往 Agentic Engineering 走。

Cadence 的 ViraStack 已经明确进入 Custom/Analog 场景，包括 schematic creation、testbench development、circuit optimization 和 layout migration；Synopsys 也正在推动 AgentEngineer，让 Agent 跨多个 EDA workflow 执行任务，而工程师继续保留关键决策和 signoff。(Cadence)

这说明一件事情：

Agent 已经开始从“回答工程问题”，进入“执行工程流程”。

这是性质上的变化。

五、第二个暴论：如果一直按照巨头的经营方式和巨头竞争，你大概率永远在他后面

模拟芯片行业有一个特别现实的问题。

你的竞争对手可能是谁？

TI。

ADI。

Infineon。

ST。

这些公司有什么？

更长的历史。

更多的研发人员。

更大的研发投入。

更多的客户。

更多的产品。

甚至还有 IDM 制造优势。

TI 在 2025 年依然拥有超过 80,000 个产品，单 Analog 业务收入就达到约 140 亿美元。(SEC)

那问题来了：

如果你的打法仍然完全是：

多招工程师
↓
多开产品
↓
多做 SKU
↓
多找客户
↓
慢慢积累 20 年

那你凭什么超过一家已经积累几十年的公司？

对方比你：

高。

壮。

老。

钱多。

人多。

SKU 多。

渠道多。

然后你跟他采用完全一样的经营模型。

那很可能你的最好结果就是：

一直在追。

所以真正值得问的问题不是：

AI 能不能让我少招几个工程师？

而是：

AI 有没有可能改变后来者和巨头之间的竞争函数？

六、真正应该追求的，不是“减少多少人”，而是“一个人能做多少事情”

这是我觉得 AI 对 Fabless 最有意思的地方。

一个公司的研发人数永远是有限的。

尤其模拟芯片又特别依赖资深工程师。

所以未来真正应该观察的指标可能是：

Products / Engineer

或者更广义一点：

Engineering Throughput / Engineer

以前一个资深工程师同时监督几个实验。

未来有没有可能：

一个工程师下面有十几个 Agent 帮他：

查历史设计；

生成 Testbench；

跑 Regression；

分析 Log；

检查规格；

修改代码；

调用编译器；

做竞争产品分析；

整理 FA 数据。

工程师自己从：

执行大量步骤的人

变成：

管理大量 Engineering Agent 的人。

这才是生产函数真正发生变化。

Synopsys 最近对 AgentEngineer 的描述其实非常直接：有些公司会用新增的生产力缩短周期，有些会用同样人数处理更高复杂度，还有一些会用同样的工程师做更多产品。(Synopsys)

我觉得最后这一点尤其适合模拟芯片公司。

七、这时候，公司的第二曲线就开始变得有意思了

传统芯片公司的第一曲线很好理解：

产品
×
销量
×
ASP
×
毛利

但 AI 时代是不是可能出现第二曲线？

比如：

产品越多
↓
工程任务越多
↓
真实 Engineering Trace 越多
↓
Agent 对企业越了解
↓
研发效率越高
↓
可以支持更多产品
↓
产生更多客户和工程数据

这是一个飞轮。

它和传统硬件业务有一个很大的不同。

过去：

卖出第 100 万颗芯片，并不会自动让第 100 万零一颗芯片“更聪明”。

但是如果每一个研发项目都在不断产生：

Task → Action → Result → Feedback

那理论上：

做完第 100 个产品之后，公司做第 101 个产品的 Agent 应该比做第一个的时候更聪明。

这就是我所谓的：

Engineering Learning Rate。

一家企业学习的速度。

长期来看，这可能是一种以前财务报表里很难看到的新资产。

八、但这里有一个非常大的误区：AI 落地 ≠ RAG + 问答 + Agent 助手

我自己做企业 AI 越来越强烈的一个感受是：

传统企业 IT 和今天真正意义上的 AI Engineering，并不是完全同一类工作。

当然 IT 很重要。

账号。

网络。

数据库。

ERP。

权限。

部署。

安全。

这些都必须有。

但如果一家公司所谓的 AI 转型最后只是：

接一个模型
+
做个 RAG
+
搭个知识库
+
做几个工作流

我觉得远远不够。

因为真正的问题是：

今天 Agent 每执行一次任务，公司有没有因此获得一条未来可以利用的新数据？

比如一个 Coding Agent：

用户提出任务
↓
Agent 查 SDK
↓
修改代码
↓
调用 Keil
↓
编译失败
↓
读取 Error
↓
修改代码
↓
重新编译
↓
Build Pass
↓
硬件 Bring-up
↓
工程师确认

这整条东西才有价值。

而不仅仅是最后那段代码。

九、未来 AI 基础设施真正核心的可能是三个东西：Trace、Eval、Feedback

现在大家特别喜欢讨论模型。

GPT 还是 Claude？

DeepSeek 还是 Gemini？

其实我越来越觉得，对企业来说模型反而可能是最容易替换的部分之一。

真正难的是：

第一，Trace

Agent 到底干了什么？

调用过什么工具？

查了什么资料？

失败了几次？

工程师改了什么？

最后成功了吗？

第二，Eval

你怎么知道它真的变好了？

不是：

“感觉挺聪明。”

而是：

Build Pass Rate 有没有提高？

Debug 时间有没有下降？

FAE 接受率是多少？

错误推荐率是多少？

Regression 是否真正跑通？

客户问题到底有没有解决？

第三，Feedback

工程师：

接受了什么？

拒绝了什么？

为什么修改？

最终 Silicon 怎么样？

客户最后有没有认可？

只有这三件事情建立起来以后：

Agent
↓
Trace
↓
Outcome
↓
Evaluation
↓
Human Feedback
↓
更好的 Context / Skill / Model
↓
更好的 Agent

这个系统才真正开始转。

否则所谓 AI 转型，很可能永远停留在 Demo。

十、再往后，才轮得到模型后训练

这个顺序我觉得特别重要。

很多企业一上来会说：

“我们有很多私有数据，要不要训练一个自己的模型？”

我觉得未必。

第一步甚至根本不应该是训练模型。

应该先搞清楚：

什么东西应该 RAG？

什么东西应该变成 Tool？

什么东西应该做 Skill？

什么东西应该进入 Knowledge Graph？

哪些 Agent Trace 才值得训练？

因为大部分企业数据其实不是 Training Data。

比如 Datasheet。

直接检索就好了。

Keil Compiler。

直接调用就好了。

Spectre。

直接调用。

真正可能适合后训练的，是那些：

经过验证、有人类反馈、并且有明确 Outcome 的高质量 Engineering Episode。

所以：

先生产好数据，再谈训练。

而不是反过来。

十一、那模拟芯片公司自己能不能做这件事？

这是一个很难的问题。

我的答案是：

可以，但不能按照传统 IT 项目的方式做。

因为这个事情横跨：

AI；

芯片研发；

数据；

软件工程；

EDA；

业务流程；

安全；

组织变革。

真正做的时候，你会发现 AI 团队根本不可能自己闭门完成。

因为 AI 团队不知道：

哪个 Corner 重要；

什么叫真正的 Bring-up 成功；

哪个版本能用；

什么结果可以 Signoff。

但是传统工程团队通常又不懂：

Agent Runtime；

Trace；

Eval；

Context Engineering；

模型后训练；

Tool Use。

所以真正的组织结构一定是：

AI Platform + Domain Expert。

而不是：

“成立一个 AI 部门，所有需求都扔过去。”

十二、大模型公司或者大厂能不能帮你做？

当然可以。

但我认为这里有一个现实问题：

他愿不愿意投入足够深的资源？

因为真正有价值的工作不是给你部署一个模型。

而是有人真正进入你的研发现场：

理解流程；

理解数据；

接你的工具；

设计 Eval；

收集 Trace；

不断迭代。

甚至几年后：

把高质量数据真正用到后训练。

这需要非常重的投入。

OpenAI 现在甚至专门设置了 Semiconductor Technical Deployment Lead，由 FDE 深入客户的 RTL、Verification、EDA 和 Physical Implementation workflow，并负责把客户现场的模式、Eval 和 ROI 做成可重复能力。(OpenAI)

这个岗位本身就说明：

最难的不是模型 API，而是 deployment。

但是问题仍然存在。

一家模型公司有那么多行业。

为什么它要把最核心的人持续几年投入一家模拟芯片公司？

而且真正核心的：

设计数据；

失败数据；

客户数据；

Silicon 数据；

最后到底属于谁？

这就是企业必须提前思考的问题。

十三、所以我越来越觉得：模型可以买，但“公司的学习系统”最好掌握在自己手里

未来底层模型一定会不断变。

今年 DeepSeek。

明年可能又有新的模型。

Cadence 会有 Agent。

Synopsys 会有 Agent。

各种开源 Harness 也会越来越成熟。

这些东西都可以买、可以换。

但以下东西最好属于公司自己：

Engineering Trace

Evaluation Benchmark

Domain Skill

Tool Connector

Engineering Memory

Human Feedback

Outcome Data

原因很简单：

模型是别人的能力，企业自己的 Engineering Learning Loop 才是自己的能力。

模型换掉以后，这些东西仍然可以继续使用。

十四、最后又绕回到了最开始的问题：老板到底信不信？

我现在越来越觉得，这件事情最终是一个 CEO / Founder Level 的选择。

因为你有两个完全合理的战略。

路线一：稳健型

观察。

采购成熟工具。

等 Cadence 做。

等 Synopsys 做。

等大模型公司把行业方案做成熟。

然后跟进。

这条路线没有错。

风险最低。

路线二：激进型

假设 AI 真的是一次巨大的生产力革命。

那么从今天开始：

重构数据；

记录 Trace；

建设 Eval；

把 Agent 放进真实 Workflow；

允许失败；

重新设计工程流程。

用未来三五年来赌：

能不能把一家传统 Fabless，变成一家 AI-native Fabless。

这条路线风险当然更大。

但是它有一个完全不同的潜在回报：

你不是在追赶上一代公司的经营模式。

你是在赌：

下一代模拟芯片公司应该怎么经营。

十五、我真正想问的不是“AI 能不能帮助芯片设计”

这个问题其实已经没有那么有意思了。

Cadence、Synopsys 等 EDA 巨头已经在往 Agentic Engineering 推进，甚至开始进入 Analog/Custom Design、Verification、Debug 等工作流。(Cadence)

真正值得问的是三个问题：

第一个问题：

如果 AI 最终可以让一个工程师管理十倍于今天的工程实验，一家模拟芯片公司的组织应该怎么变化？

第二个问题：

如果每一次产品设计、每一次失败、每一次流片和每一次客户问题，都可以成为下一代 Agent 的训练和评测数据，那么一家芯片公司的数据到底应该怎么管理？

第三个问题：

如果你的竞争对手比你历史长、资金多、SKU 多、研发投入也更高，那么你到底是继续用他的游戏规则追赶他，还是趁 AI 出现的时候，尝试换一套游戏规则？

写在最后

我现在对模拟芯片 + AI 的判断其实越来越简单。

AI 不是给模拟芯片公司增加一个新工具，而可能是在重新定义一家模拟芯片公司的生产方式。

过去公司的复利来自：

产品。

IP。

客户。

工程师经验。

未来可能再加一个：

Engineering Intelligence。

每一个项目都让公司的 Agent 更聪明。

每一个失败都变成下一次设计的先验。

每一个客户问题都反过来改善产品定义。

最终：

更多产品
↓
更多工程经验
↓
更强的 Agent
↓
更高的研发效率
↓
更多产品

如果这个飞轮真的存在，那么模拟芯片公司未来真正值得积累的，可能不仅仅是下一颗芯片。

而是：

一家能够持续学习的工程系统。

所以最后还是那个最简单的问题。

你信不信 AI？

如果不信，一切都不用讨论。

如果真的信——

那可能就不能只做一点点。

接下来我们写了 MCU/DSP 原厂这条路怎么跑通：从 SDK 到 AI-native Development Agent。

这不是再接一个聊天插件。它是我们把 LLM Wiki 接到真实网站上的最佳实践：知识先编好，再让访客在官网当场追问，并且看得见结论是怎么来的。

为什么官网客服也要接知识底座

芯片官网最常见的客服，是「留下联系方式，我们回头找你」，或者接一个只读过网页文案的机器人。前者慢，后者一问到型号、参数、装车案例就空转。

客户真正想确认的，往往是：

• 这个应用场景该往哪类器件上看
• 两家原厂方案差在哪里
• 某个料号的关键参数以哪份资料为准
• 有没有真实装车或拆解依据

这些问题答不好，销售和 FAE 还是要晚上补位。官网客服要有用，前提不是话术更圆，而是后面有一份可追溯的知识。

这份最佳实践具体长什么样

打开 chatbarbot.com 右下角就能看到。当前助手接的是刚上线的 Barbot Selection Library，所以它能聊汽车与工业模拟选型，也能把访客带到完整工作台。

页面上我们刻意做成三件事，而不是只吐一段流利回答：

1. 流式输出：先看到思考，再看到正文，而不是等整篇生成完才跳出
2. 思考链可展开：模型在查什么、在权衡什么，不藏起来
3. 检索轨迹和出处：ROUND、工具调用、以及 wiki/overview.md:12 这类证据路径会留下来

访客要的是「这个结论站不站得住」。企业要建设自己的官网客服时，也应该按这个标准验收，而不是只看回复速度。

官网助手和完整 LLM Wiki 怎么分工

两者用同一份知识，入口不同：

• 官网智能客服：嵌在产品站里，适合快速体验、当场问一句、把 LLM Wiki 的工作方式展示给客户
• 完整工作台：ask.chatbarbot.com 上的 Selection Library，适合继续翻资料、看工具细节、做多轮选型追问

一个是网站上的最佳实践演示，一个是知识工作台。先在官网看懂它怎么答，再进工作台看知识是怎么被组织起来的。

企业可以照着做成什么

原厂、代理商和方案公司如果要把智能客服接到自己的官网，不该从「选一个聊天组件」开始，而该从知识底座开始：

1. 把手册、笔记、FAQ、项目结论编进 LLM Wiki
2. 规定回答必须带条件、出处和不确定时的升级路径
3. 再把助手嵌到官网、企业微信或支持工作台
4. 证据不足时交给 AI FAE 或人工，而不是硬答

Barbot 官网现在做的，就是第 3 步的公开样例：知识已经在 Selection Library 里，助手只负责把追问接到访客面前。

直接打开 官网 右下角试一句。要看完整库，去 Barbot Selection Library。要在自己的网站上复制这套做法，预约会议。

卡点很少是“找不到候选料”，而是评估太慢——手册对不齐、跨部门口径不一致、验证项写不清。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 场景

分不清这两种替代，芯片替代分析 会从工程问题变成会议问题。

Pin-to-Pin 要同时满足什么

Pin-to-Pin 不是“引脚数量一样”。通常至少要核对：

• 封装外形、焊盘和高度是否兼容现有 PCB
• 电源、地、复位、时钟、使能等关键脚位置一致
• NC、复用脚、开漏/推挽差异会不会破坏原电路
• 推荐工作条件和绝对最大额定值覆盖原设计窗口
• 启动、时序和保护行为不会让后级误动作

只要有一条不满足，就应降级为“条件可替”或功能替代，并写明要改板还是改软件。

功能替代解决的是另一类问题

功能替代常见于：

• 原厂停产，市场上没有同封装后继料
• 国产化 时优先保证系统功能，允许改板
• VAVE 用不同架构实现同一指标，换取成本

这时要对比的是功能覆盖、性能余量、软件迁移成本和验证周期，而不是只看引脚图是否“看起来像”。

为什么不能用文本相似度做判断

两份手册都写 “ADC 16-bit”，测试条件、输入范围、参考源和建立时间可能完全不同。引脚名都叫 INT，一个是开漏低有效，一个是推挽高有效。这正是 Datasheet 对比 必须结构化对齐的原因。

P2P Agent 会分别给出 Pin-to-Pin 判断和功能替代判断，并标出风险，避免把“功能接近”写成“可以直接贴”。

沟通时建议用的三句话

1. 这是 Pin-to-Pin，还是功能替代？
2. 要不要改 PCB / 原理图 / 软件？
3. 证据在哪一页，验证项是什么？

采购、FAE 和硬件用同一套语言，第二供应商导入 才会快。

免费试用 P2P Agent · 了解产品

Coding Agent 要解决的，是让原厂全部技术资料进入 VS Code 里的真实工程，而不是再开一个与项目脱节的聊天窗。

它真正能帮忙的工作

• 外设 bring-up：时钟树、引脚复用、中断和 DMA 初始化
• 按手册改配置：对照寄存器与推荐顺序，而不是只抄例程
• SDK / 工程迁移：版本变化后定位 API 和行为差异
• 编译、链接、启动失败：结合工程和原厂限制缩小范围
• 引用证据：指出手册、头文件或示例里的依据，方便复核

这些都依赖“先识别工程、芯片和 SDK”，再检索资料。顺序反了，代码越流畅越危险。

它不该被当成什么

• 不替代示波器和逻辑分析仪
• 不保证生成代码一次上板成功
• 不在缺少芯片上下文时充当通用 Copilot 的替代品

对 国产 MCU 替代 项目，Coding Agent 的价值是把两套 SDK 的差异变成可检查的修改，而不是宣称“已经兼容”。

和 FAE、P2P 如何配合

选型与手册对比仍由 P2P Agent 和 AI FAE 处理。开发阶段的问题进入 Coding Agent。企业知识仍在 LLM Wiki。三者共用同一底座，口径才不会在“能不能替”和“代码怎么写”之间分裂。

适合谁

MCU / DSP 原厂的应用与生态团队，以及长期维护同一系列芯片工程的开发者。通用团队如果没有芯片资料治理，应先补知识底座。

查看 Coding Agent · 预约原厂定制

高效对比的方法是：先建立共同对象，再判断差异对当前电路是否可接受。这也是 P2P Agent 的工作方式。

建议的对比顺序

不要一上来比功能宣传页。按这个顺序更稳：

1. 身份：完整料号、温度等级、封装后缀、手册版本
2. 封装：外形、焊盘、高度、热焊盘
3. 引脚：电源/地、复位、时钟、中断、NC、复用
4. 推荐工作条件与绝对最大额定值
5. 关键电气参数（带测试条件）
6. 时序、启动、保护
7. 应用电路与认证

这个顺序能尽早发现“根本不能落板”，避免在 ADC 精度上纠结半天。它也直接服务 Pin-to-Pin 判断。

参数对比必须带测试条件

把这些列进同一张表：

• 参数名（双方原文）
• 最小值 / 典型值 / 最大值
• 单位
• 测试条件：电压、温度、负载、模式
• 是否落入原设计窗口
• 证据页码

只比典型值，是 VAVE 和 国产化 项目里最常见的误判来源。

引脚对比不要只看名称

同名引脚可能：

• 有效电平相反
• 开漏与推挽不同
• 上电默认状态不同
• 复用功能集不同
• 内部上拉/下拉不同

NC 尤其危险：一边是空脚，一边其实是测试脚或必须按手册处理的脚。

人工与 Agent 如何分工

人工擅长判断“这个差异在我这块板上能不能忍”。Agent 擅长把 80 页手册变成对齐后的表。Barbot 的试用入口支持 2 至 5 份 PDF，输出完整报告或快速结论，格式可选 Markdown / JSON / Excel。

如果你正在做 第二供应商导入，把这次对比报告存成标准附件，而不是截图发到群里。

上传 Datasheet 开始对比 · 产品说明

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 · 查看产品介绍

芯片知识的难点不是“有没有文字”，而是对象、版本和约束。这正是 LLM Wiki 要编译的东西。

向量检索擅长什么

• 快速从大量非结构化文本里找到相关段落
• 给通用问答提供上下文
• 作为编译后知识的检索通道之一

它是工具，不是知识模型。

芯片场景里它不够用的原因

1. 版本：同一料号存在多份手册，召回旧版会直接错
2. 条件：参数必须带着电压、温度和模式，否则数字无意义
3. 关系：芯片、封装、外设、API、参考设计是网，不是孤立段落
4. 冲突：专家经验和官网文档不一致时，检索不会自动升级给人
5. 权限：客户资料、内部勘误和公开手册不能混在一个索引里

所以 替代分析、AI FAE 和 Coding Agent 都不能只靠“最相似的 5 段”。

应该先编译，再检索

LLM Wiki 的顺序是：

1. 接入 PDF、网页、SDK、代码和表格
2. 编译成芯片、参数、引脚、API 等对象
3. 给结论挂上证据和有效期
4. 发现冲突，提交专家审核
5. 再让各场景 Agent 调用

检索发生在对象网络上，而不是发生在碎纸堆上。

判断知识库是否合格的四个问题

• 过期型号还会被推荐吗？
• 关键结论能回到手册页码吗？
• 冲突是被隐藏了，还是被标记了？
• P2P、FAE、Coding 是否共用同一底座？

如果四个问题里有两个答不上来，先不要扩大 Agent 数量。先把知识做对，Agent 才 能完成工作。

了解 LLM Wiki · 预约建设企业知识底座

这是 Barbot 的公司主张，也是产品分层的原因。

“能回答”为什么不够

• 没有证据的结论无法进入 AVL
• 没有工程上下文的代码无法上板
• 没有状态的长任务无法跨部门协作
• 没有边界的自信回答会制造质量事故

所以评测不能只看语言是否流畅，而要看准确性、可追溯、完成率和安全边界。

完成工作需要四层能力

1. 知识：LLM Wiki 把资料编译成可维护对象，而不是 只做向量检索
2. 场景 Agent：
   • P2P Agent 完成替代分析报告
   • AI FAE 完成首次有效技术支持
   • Coding Agent 在工程里改代码并引用依据
3. 工作台：Harvey Agents 把 VAVE、项目支持和方案交付拆成可审批的长任务
4. 现场闭环：先在一个高价值场景跑通，再产品化复用

用交付物定义 Agent，而不是用对话轮数

Datasheet 对比、第二供应商导入、国产化 都可以按这张表验收，而不是按“聊得像不像专家”验收。

从哪里开始

已经上线、可直接验证的是 P2P Agent：上传手册，拿到可编辑报告，新用户免费 5 次。其他产品按现场需求接入同一知识底座。

立即体验 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

缩短 首次有效响应，比缩短“首次回复”更重要。有效意味着：型号对、条件问清、结论有出处、不确定时知道该升级给人。

首次有效响应卡在哪里

• 客户没给工作电压、温度、封装或认证要求
• 答案散落在手册、应用笔记、FAQ 和历史工单
• 销售、FAE、官网客服口径不一致
• 资深工程师被重复问题占满，复杂单反而更慢

这不是多招人就能线性解决的。需要一层建立在原厂知识上的支持 Agent，也就是 AI FAE。

AI FAE 的工作顺序

1. 识别型号、场景和问题类型
2. 补全关键工作条件，而不是假设客户已经说清
3. 调用 LLM Wiki 给出建议、证据和风险等级
4. 证据不足或涉及安全/失效分析时，把完整上下文转交人工

它回答选型、参数和方案问题；它不替代实验室和现场失效分析。边界本身就是响应质量的一部分。

和通用聊天机器人的差别

通用模型可以流畅解释“什么是 LDO”。它不知道你们这颗料的勘误、哪一版手册有效、你们内部是否已经否决过某种接法。没有知识治理，加速只会放大错误口径。

所以 AI FAE 必须坐在 Wiki 之上，而 Wiki 不能只是 向量检索。

对原厂和代理商的直接价值

• 重复问答从资深 FAE 工作台移走
• 不同渠道对外口径统一
• 人工接手时不再从零了解背景
• 和 P2P Agent 配合：支持过程中需要替代判断，就进入可追溯对比

想看支持场景如何落地，可以 预约 AI FAE 演示。若要先感受“资料变成结论”，可直接 试用 P2P Agent。

P2P Agent 就是为这件事做的。它读取芯片数据手册，完成参数级差异分析、替代关系判断和证据定位，把芯片替代从个人经验，变成可审核、可追溯的工程结论。

这是 Barbot 目前已经上线、可以直接用的产品。打开 chatbarbot.com/chip/compare，上传 PDF 就能跑。

它解决什么问题

替代分析最耗时间的，不是最后写一句「能替 / 不能替」，而是中间那一长串对齐：

• 电气参数名称、单位、典型值与极限值是否在同一测试条件下
• 封装、尺寸、焊盘能否落板
• 引脚功能是否 Pin-to-Pin，有没有隐藏的电源、地、NC 差异
• 应用限制、工作温度、认证与可靠性条款会不会把方案卡死

P2P Agent 理解参数定义、封装关系、引脚功能和应用限制，而不是只做文本相似度比对。

一次分析怎么走

1. 识别型号与应用条件
2. 提取并对齐规格、封装和引脚
3. 判断替代关系，标出风险点
4. 生成附带原始证据的报告，可编辑、可导出、可人工复核

工作台支持 2 至 5 份 PDF，可选完整报告或快速结论，输出 Markdown / JSON / Excel，并支持流式边生成边看。

核心能力

• 多份数据手册结构化读取
• 参数名称、单位和测试条件对齐
• Pin-to-Pin 与功能替代判断
• 风险提示与验证建议
• 报告编辑、导出和人工审核

对采购、研发、FAE，以及负责 VAVE、BOM 风险和国产化替代的团队，它先把「读手册、做初判」这段时间压下来，并把方法统一成同一套交付物。项目里积累的判断，还可以再沉淀回 LLM Wiki。

现在就可以试

新用户有 5 次免费对比。登录后按次计费，适合把真实手册丢进去看一次完整报告长什么样。

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

芯片企业并不缺文档。缺的是一份版本清楚、冲突可管、结论找得到出处的知识。官网、共享盘、代码仓库、工单、个人笔记各写各的，Agent 如果只做切片检索，回答会流利，依据却对不上号。

我们不依赖把资料切碎后「大海捞针」。LLM Wiki 把散乱文档编译成可维护知识：结论可追溯，版本与冲突可管理，并持续适配 Agent 的工作方式。

它把资料变成什么

LLM Wiki 将芯片、参数、外设、API、SDK、方案和工程结论，组织成相互关联的知识对象。Agent 拿到的是完整上下文，而不是互不相干的检索片段。

典型流程是：

1. 资料接入与结构解析：PDF、网页、SDK、代码、表格
2. 知识编译与关系建立：型号、版本、有效期、适用条件
3. 结论与证据关联：重要判断能回到具体位置
4. 专家审核与持续更新：冲突先被发现，再由人裁定

核心能力

• 多来源资料统一管理
• 型号、版本与有效期管理
• PDF、网页、SDK、代码和表格解析
• 知识冲突发现与人工审核
• 企业权限、私有部署与数据隔离

对芯片原厂、代理商、方案公司和拥有大量技术资料的工程组织，价值很直接：回答更准、来源可查，专家经验不再只存在于某个人的聊天记录里，P2P Agent、AI FAE、Coding Agent 和 Harvey Agents 共用同一底座。

和「再接一个知识库」的差别

很多团队已经有向量检索。LLM Wiki 要解决的是更前面的问题：资料有没有被编译成 Agent 用得上的对象，冲突有没有人管，过期型号会不会继续被推荐。

先把知识做对，场景 Agent 才站得住。这也是 Barbot「先现场、再产品化」里，必须先建的那一层。

对外可体验的第一份库是 Barbot Selection Library：按终端应用组织汽车与工业模拟选型知识。官网右下角的 智能客服 是把它接到真实网站上的最佳实践，完整工作台在 ask.chatbarbot.com。

查看 LLM Wiki 产品介绍 · 预约建设企业专属知识底座

Coding Agent 是 Barbot 给 MCU / DSP 原厂及其开发生态做的专属助手。它结合当前工程、目标芯片和 SDK，把原厂技术知识送进 VS Code 里的真实开发流程。

为什么通用助手不够用

嵌入式开发不是「再写一个函数」，而是资料、寄存器、示例、链接脚本和硬件约束叠在一起：

• 同一外设，不同封装的引脚复用完全不同
• 初始化顺序错一步，就是 hard fault，不是语法错
• SDK 升级后 API 还在，行为已经变了
• 原厂推荐的 bring-up 路径写在应用笔记第 17 页，不在 README

Coding Agent 的起点是：先认工程、认芯片、认 SDK，再写代码。

它怎么工作

1. 识别工程、目标芯片与 SDK 版本
2. 理解当前代码和开发目标
3. 检索原厂 API、寄存器、示例和勘误
4. 生成或修改代码，并调用工具做验证

开发者仍在 VS Code 里工作，不需要把上下文复制到另一个聊天窗口再翻译一遍。

核心能力

• VS Code 原生体验
• 外设初始化与配置辅助
• SDK 与工程迁移
• 编译、链接与 Bring-up 排查
• 引用原始资料和代码证据，方便复核

对原厂来说，这不只是内部提效，也是持续服务开发者的产品入口：技术支持覆盖面变大，从「读完手册再写工程」变成「在工程里直接用手册」。

知识底座仍是 LLM Wiki。更长、需要多人协作的交付，可以接到 Harvey Agents。

查看产品介绍 · 预约沟通原厂定制

AI FAE 是面向原厂与代理商的全天候技术支持 Agent。它先读懂问题，再调用经过治理的原厂知识作答；证据不够或问题过深时，不硬答，把完整上下文转给人工。

企业真正卡住的地方

• 同一型号，销售、FAE、官网客服给出的限制条件不一致
• 客户没说清工作电压、温度、封装或认证要求，一轮问答就要来回好几天
• 资深 FAE 被重复问题占满，复杂项目反而排不上
• 工单里有经验，却很难变成下一次可复用的知识

Barbot 的标准不是「回复更快」，而是「首次有效回应更快，且说得出来源」。

它怎么工作

1. 理解问题与应用背景：型号、场景、工作条件、问题类型
2. 补全关键条件：电压、温度、负载、封装、认证等没说清的部分
3. 调用 LLM Wiki 中的可信知识，输出建议、证据和风险等级
4. 识别不确定性，必要时连同对话上下文一起交给人工 FAE

接入可以落在官网、企业微信或内部工作台，让客户、销售和工程师走同一条支持路径。

核心能力

• 选型与参数解释
• 方案和参考设计推荐
• 多轮追问与条件补全
• 来源展示与可信度判断
• 多渠道接入，口径统一

适合芯片原厂、代理商、销售支持与 FAE 团队：减少重复问答，缩短首次有效回应，把专家时间留给真正难的单。

公开演示已上线：打开 AI FAE / Vector Chat。想建设企业专属支持 Agent，欢迎 预约演示，或从已经开放的 P2P Agent 感受 Barbot 如何把资料变成可追溯结论。

官网一句话把这件事说清楚了：把客户现场的难题，变成可复用的 Agent 能力。

我们相信什么

每个人都会拥有 Agent。真正的竞争，不是谁能制造更多 Agent，而是谁能把 Agent 做得更好。

所以 Barbot 不做「用来创建 Agent 的平台」。我们选择真实、有价值的行业工作，直接做出能交付结果的产品：专业能力要够、工具要用得上、任务要能做完、判断要有证据、风险要有边界。

真正有价值的 Agent，不在演示里定义，而在现场工作中验证。

为什么从芯片行业开始

芯片工作专业、复杂，高度依赖数据手册、应用笔记、选型资料和工程经验。同一参数名，测试条件可能完全不同；同一颗料，封装、引脚、应用限制差一个条件就不能替。这正是检验 Agent 是否真有用的地方。

我们长期处理的，是这些具体工作：

• 芯片选型与 Pin2Pin 替代
• 采购、VAVE 与器件评估
• FAE 技术支持与方案问答
• 面向 MCU / DSP 的开发辅助
• 企业知识治理与行业数据建设

Agent 的上限，来自对行业工作的理解。Barbot 把数据手册、应用笔记、汽车电子 Teardown 和嵌入式 SDK 里的工程经验，沉淀成 Agent 能用的知识、工具和评测。

我们怎么做事

先现场、再产品化。一条碎石路先铺通，再做成可复用的高速公路。

1. 发现高价值问题：走进客户现场，对齐真正影响交付的优先级。
2. 现场跑通结果：把数据、工具、权限和流程接进真实工作。
3. 沉淀为产品能力：抽出共同模式，做成可跨客户复用的组件。
4. 规模化交付价值：下一次更快、更准，并把反馈继续喂回产品。

支撑这件事的，是五层能力：自建行业数据、面向 Agent 的 LLM Wiki、岗位场景 Agent、MCU/DSP 专项评测，以及自有内容渠道（Barbot Newsletter、微信公众号「私家芯探」和小红书）。先拥有数据、理解数据，再让 Agent 在数据之上工作。

产品怎么长出来

每一款产品都来自真实的芯片行业工作：

• P2P Agent：读取数据手册，做参数级差异、Pin2Pin 判断和可追溯报告。已经上线，可免费试用 5 次。
• AI FAE：面向原厂与代理商的全天候技术支持，证据不足时把完整上下文交给人工。
• Coding Agent：理解芯片文档与 SDK，在 VS Code 里辅助 MCU/DSP 开发。
• LLM Wiki：把散乱资料编译成可维护、可追溯的企业知识，给所有 Agent 当底座。
• Harvey Agents：连接知识、数据和工具，执行需要多步骤、可协作的长任务。

完整产品介绍见 产品总览。

我们用什么标准衡量「更好」

现场结果必须经得起检验。Barbot 用统一评测体系看模型、知识和工具链的薄弱环节，让交付从「能回答」走向「能完成工作」：

• 准确：围绕真实芯片任务验证结论，不只看语言是否流畅。
• 可追溯：重要判断回到文档、版本和证据位置。
• 能完成：衡量端到端任务完成率，看交付物是否真能用。
• 有边界：识别不确定性、冲突和风险，必要时主动升级给人。

一起做一件有价值的工作

如果你正在做选型替代、技术支持、嵌入式开发或企业知识治理，欢迎从已经上线的 P2P Agent 开始，或到 关于我们 了解 Barbot，也可邮件 neal.liu@chatbarbot.com 谈合作。