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

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 场景

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 · 预约原厂定制

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

这是 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

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

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 谈合作。