起因

上周有个朋友问我，我想用AI改一个Com模块，他把Com模块的Com.arxml发给我，我打开一看，16M。

他问我AutoC能不能行，我说你先用claude code试一下。

通用coding agent，第一步就卡住了

任何人的第一反应是丢给通用coding agent处理，比如Claude Code这一类工具。但试了一下就发现根本跑不动。

这类工具的底层逻辑都是"读文件—改文件"：把文件内容塞进上下文，让模型自己看一遍找出哪些Signal没人引用。问题是16M的ARXML，按AUTOSAR这种动不动就是好几层嵌套标签的verbose程度，tokenize完轻轻松松大几百万token，没有哪个上下文窗口扛得住。

而且这个任务本身没法靠分块来绕过去。你要判断"这个Signal有没有被引用"，本质上需要一个全局视角——把全部ComIPdu的引用关系都扫一遍，才能确定某个Signal是不是孤儿。读一半文件、看一半数据，得出的结论必然是错的。

这不是上下文窗口再大一点就能解决的问题，而是这类通用工具的工作方式跟AUTOSAR配置文件的结构天生不匹配：它们把ARXML当成"一份很长的文本"在处理，而ARXML实际上是一个有严格schema、模块间层层引用的结构化数据库，根本不该用读文本的方式去理解。

为什么得是专用的BSW agent

这也是我一直坚持的判断：BSW配置这件事，靠通用coding agent是做不好的，必须有一个真正理解AUTOSAR模块结构——知道哪些是list、哪些是choice、模块之间怎么互相引用——的专用agent，把两件事分开：

• 理解这个文件长什么样
• 在这个文件上做精确操作

模型不需要、也不应该去通读整个16M文件才能干活，它只要知道这是一个什么样的结构、要执行的是什么样的操作，剩下的精确执行交给专门针对AUTOSAR结构设计的工具层去做——跟实际数据规模没关系，16M和160M对它来说没有本质区别。

实测

这次测试用的是AutoC，在那个16M的Com.arxml上。找出所有没有被任何ComIPduSignalRef引用的ComSignal

当然，你也可以问其他各种问题，欢迎挑战autoc的边界。

AutoC不会把整个文件读进AI的上下文，而是先把xdm/arxml解析成结构化数据，AI只需要描述意图。

尝试

autoc会先尝试读取数据

如果是小数据，直接就处理了。

常规的路子走不通，用脚本解决

autoc 的核心，触发了skill autoc-api

执行脚本

结果

结果跟预期一致：

精确的从23w7741行的arxml中找到了，在6w6243行。

对比

	Claude Code（通用 coding agent）	AutoC（专用 BSW agent）
处理方式	能生成 Python / 脚本来解析 ARXML，思路没问题	内置专用执行层，直接操作结构化 ECUC 数据，不需要临时脚本
16M 大型 ARXML	有风险 脚本逻辑由模型即兴生成，边界情况处理不稳定	稳定处理 执行层经过专项测试，文件规模不影响结果，所有操作可追溯，留痕
改错 ARXML 的风险	临时生成的脚本可能误判引用路径格式、漏处理编码或命名空间，悄悄写坏文件	操作前解析验证，操作后接 AUTOSAR 校验，写坏了会有明确报错
AUTOSAR schema 理解	依赖模型对 ECUC 结构的泛化理解	内置 AUTOSAR ECUC 数据模型，list、choice、引用关系有原生支持
配置正确性保障	脚本跑完没有 AUTOSAR 层面的校验，对不对只能靠编译或运行时暴露	操作后自动接 EB tresos / DaVinci 校验，引用完整性有明确反馈
适用场景	小规模探索、一次性脚本、对结果容错度高的场景	量产项目，改错了要背锅的真实配置工程

写在最后

这件事让我更确认了一点：BSW这个领域不是套一个通用agent框架、换个prompt就能做好的。文件规模、模块间的引用关系、配置正确性，这些AUTOSAR特有的复杂度，决定了它需要一个真正为这个领域定制的agent，而不是通用工具的简单复用。

选择AutoC做bsw配置，就像你选ClaudeCode 写代码一样！

如果你想复现

1. 下载autoc的最新版本
2. 下载测试用的arxml文件，导入这个arxml文件到达芬奇
3. 当然，你也可以用你自己手里的code agent看看能不能得到正确的答案：Cockpit_HVAC_Rx_RUpDownPosSet_85f2c20b_Tx