起因

最近不少人问：通用 coding agent（比如 Claude Code）能不能直接干 BSW 配置？

口头争论没意义，我们拿一个真实工程测了一把。

测试环境：ISOLAR-B 工程，Com 里 500+ 信号。两道题，一边是 AutoC，一边是 Claude Code，题目完全一样。

问题 1：Com 模块一共有多少个信号？

这是个查询题。正确答案是532：

Claude Code

读文件、在上下文里翻 ARXML，再自己统计。答对了，但 token 烧得快，时间也拖得长。

AutoC

不把整份配置当长文本塞进模型。意图交给 AI，查数走结构化工具层。结果也对，时间和 token 成本都明显更低。

两边对比

	Claude Code	AutoC
结果	正确	正确
方式	读 ARXML 文本再统计	结构化工具层直接查询
时间 / token	偏高	大幅更低

查询这种事，两边都能交差。真正拉开差距的是下一题。

问题 2：按 DBC 变更，增加 2 个信号

这次要动一整条链路：Ecuc、PduR、Com、CanIf、Can。

不是改一个参数，是跨模块串起来加信号。

Claude Code

最终它也“做完”了——文件改了，信号看着也加进去了。

但问题出在后面：拉到 ISOLAR 里校验，CanIf 报错，Com 信息也确实有缺失——比如信号加进去了，关键字段却是空的。

Claude Code 主要靠 edit file 直接改 ARXML。ARXML 标签深、引用多，模型一旦幻觉——漏一个引用、写错一个路径、CanIf 和上层对不上——表面看改完了，工具链一校验就露馅。

再加上跨 5 个模块，来回读改，耗时很长。改完还不能直接信，还得人工对着校验结果修。

AutoC

同样的 DBC 变更需求，AutoC 走模块语义和工具链操作，而不是拿文本编辑器硬改 ARXML。

该动 Ecuc、PduR、Com、CanIf、Can 的地方按引用关系写，写完接工具链校验，减少“改完了但校验不过”的情况。

两边对比

	Claude Code	AutoC
结果	文件改完了，ISOLAR 校验 CanIf 报错，Com 信息缺失	按模块链路完成变更，校验可闭环
方式	edit file 直接改 ARXML，易幻觉写错	结构化操作，不靠通读/手改巨型 ARXML
耗时	很长	明显更省
后续成本	人工对着校验结果排雷	校验反馈可闭环

如果是 5000 个信号呢？

这次测的是 500+。量产项目里，Com 到几千个信号很常见。不妨把规模放大十倍想一下。

对 Claude Code 这类靠读文件、edit file 干活的通用 agent，规模几乎是线性放大成本：

• 查询：500 个信号时尚且 token 和时间已经明显偏高；5000 个信号意味着 ARXML 更大、引用更深，上下文塞不下就得分段读，分段读又容易统计漏项。
• 变更：500 个信号时跨模块加 2 个信号已经耗时长，还出现 CanIf 校验失败；5000 个信号时，误改相邻信号、写错引用路径、漏改某一层的概率只会更高。改完靠人工对校验结果排雷，工作量也跟着涨。

对 AutoC 来说，信号从 500 到 5000，模型侧负担变化不大。它本来就不靠把整份 Com 配置读进上下文，查询和写入走结构化工具层，规模主要压在执行层，而不是压在 token 账单上。

所以 500 信号工程里已经能看出趋势：查询两边都能做，变更通用 agent 开始吃力。到 5000 信号，这个趋势只会更陡——通用 agent 更贵、更慢、更容易改错；专用 agent（AutoC）的优势更明显。

写在最后

两句话总结：

1. 会查，不等于会配。 查询两边都能过；跨模块变更才是分水岭。
2. BSW 配置不能当普通代码文件改。 用 edit file 改 ARXML，慢、贵，还容易改到校验不过。

选 Claude Code 写代码没问题。做 AUTOSAR BSW 配置，更需要懂模块结构和引用关系的专用 agent。

选 AutoC 做 BSW，就像选 Claude Code 写代码。

想自己试？

1. 下载最新版 AutoC
2. 打开你的 ISOLAR / EB / DaVinci 工程
3. 先问一句：「Com 模块一共有多少个信号？」再丢一个真实的 DBC 变更需求