摘要：一篇关于博世工程师开源项目的文章收获15万+曝光，但真正Fork动手的只有50多人。这种"围观多、动手少"的现象背后，是AI工具落地的结构性错位——真正需要AI工具的人不会用GitHub，会用GitHub的人不需要通用工具。AI工具的上限取决于注入者的领域深度，而非AI本身的能力。
这篇文章发出后，评论区出现了这样一条留言：
图 1
“车企一线大头兵，现在真的压力山大，看到这种项目出来真是五味杂陈，被时代浪潮卷死应该快要进入倒计时了…”
那篇文章在公众号和LinkedIn两个平台加起来，超过15万人看了——公众号近3万阅读、2000多次转发，LinkedIn近13万曝光、1400多个赞。
然而，打开GitHub一看——真正Fork下来用的人，只有50多个。
15万人围观。50人动手。转化率不到万分之三。
我一开始以为是技术门槛的问题——可能大家不会用GitHub、不用Claude Code。
后来发现，事情没这么简单。
一、真正的障碍不是技术，是一种结构性错位
最近一段时间，和团队内外部同事朋友等各类人聊了这个话题——OEM、Tier1的工程师、做AI Agent的创业者、高校老师、咨询公司。聊完之后我得出了一个让自己也挺意外的结论：
真正需要这些AI工具的人，不会用GitHub。会用GitHub的人，根本不需要这些通用开源工具。
这不是段子，是一个结构性的错位。展开说说。
AI-native公司怎么看这个项目
我紧密协作的团队，几乎每个人都在用Claude、Cursor做日常工作，每个人都在琢磨怎么把自己的活儿用AI自动化。他们对这类通用开源项目的反应是什么？
不太感兴趣。
不是因为不好，是因为自己已经在做了——针对自己公司的流程、自己团队的know-how、自己产品的需求，搞定制化的AI工具。一个通用的"功能安全Agent"，远不如他们自己那个塞满了内部案例和模板的版本好使。
传统车企怎么看这个项目
另一边，有咨询公司的朋友找我聊，说有车企客户想做"AI提效"——同时给底盘域、车身域、智驾域等多个域开发AI Agent，让AI读需求文档、自动提测试用例。
图 2
需求是真实的、强烈的。 但这些一线工程师平时用的是Excel和飞书，不是GitHub和Terminal。你让他Fork一个项目、配置Claude Code、写.claude目录——他做不到，也没时间学。
两个案例，一个对比
案例A： 一位咨询机构的朋友接了车企项目，要给多个域同时开发AI Agent。问题是：他对这几个域缺乏深刻的工程经验，只能从企业收集文档做"黑盒"训练——把文档丢进去，让AI硬提取。我的判断：有一些价值，但很难做深。
案例B： 一位在德国做了20多年座舱研发的创业者，公司本身就做座舱产品，作为Tier1给国内外车企供货。他现在也在做座舱领域的AI Agent。不同的是，他有二十多年的座舱开发经验和现成的产品积累——他知道哪些know-how最值得喂给AI。我的判断：有可能做成。
差距在哪？
不是AI能力的差距。同一个Agent 或 Skill，两个人用，输出天差地别。
差距在注入者的领域深度。
图 3
AI工具的上限 = 注入者的领域深度 × AI的能力。
AI的能力大家都一样。决胜的是你往里面灌了什么——你在这个行业踩过的坑、见过的失败模式、积累的判断标准。这些才是AI真正缺的原料。
最近a16z的一篇文章（Institutional AI vs Individual AI）把类似的现象总结得很到位：
针对特定任务构建的领域专用方案，相比通用大模型始终保持能力优势——而且这个优势会持续累积。
翻译成汽车行业的话就是：
通用AI Agent谁都能生成，但领域know-how注入后的AI才是武器——而且这个武器会越用越锋利。
二、说来惭愧，我自己也没用过
坦诚地说：我的那个GitHub Fork，加上那篇公众号文章，前前后后花了大概2个小时，就是周日早上用Claude Code高度自动化完成的。
我没有亲自在Claude Code里跑过一次HARA分析，也没有用它生成过一份SOTIF触发条件报告。
原因很简单——这些具体的分析工作是团队的工程师在做，他们才是每天和工具、标准、真实项目打交道的人。我的日常更多是定方向、定方法、审输出。我协作的团队刚拿了中国汽车功能安全标准化促进中心的卓越贡献奖——这个奖靠的不是某一个人，而是一线工程师的实战积累和团队的协作。我没有亲自操作这个工具，但这恰恰说明了一件事：** **
AI工具要真正好用，既需要一线工程师的实战经验，也需要有人把这些经验结构化地注入进去——这是两种不同的价值，缺一不可。
前几天，雷诺集团的一位开源项目负责人在LinkedIn评论区直接说：
这个项目就是"AI slop"——AI生成的泡沫，LLM自带的知识就能生成这些。** **
他说对了一半。 通用Agent确实随手就能生成——让Claude写一个"功能安全工程师Agent"，5秒钟的事。但这种Agent，和一个做了15年HARA的老工程师把自己踩过的坑、审过的案例、建立的判断框架全都注入之后搞出来的Agent，完全不是一回事。前者是AI slop，后者是武器。
LinkedIn上还有一位同行说得更实在：** **
工具的价值是帮你更快地出第一版草稿，让你把精力花在判断和修改上，而不是从零开始写。但最终签字负责的，还是你。
这才是该有的预期：AI出初稿，专家做判断。 AI不会替代功能安全工程师，但会让好的功能安全工程师效率翻倍。
三、一个意外的好消息——版权没你想的那么严重
LinkedIn评论区还有一场国内完全没出现过的讨论：** **
用AI提取ISO 26262等标准的know-how，算不算侵权？
这个话题由一位做安全关键软件的公司CEO发起，引来了12个赞和15条深度回复，是整个帖子下面最热的一个讨论串。
最后一位行业专家翻了ISO的版权政策，给出了关键结论：
标准的原文受版权保护。但基于标准衍生出来的know-how、工作流、方法论——可以自由使用和分享。
这个结论在国内几乎没人讨论过，但对想做AI工具（尤其要出海）的团队来说太重要了——它扫清了"把标准知识灌进AI是不是违法"这个最大的心理障碍。
当然，前提是你别把标准原文一字不改地塞进去。提炼要点、总结方法、设计工作流——这些衍生产出没问题。具体边界还是建议问问知识产权律师。
四、那个项目为什么变Private了？
不少读者在评论区追问：博世工程师为什么把原始项目仓库设为了私有？
我的理解是：LinkedIn上十几万人的曝光，这种关注度可能让他所在的组织有了顾虑。一个个人的业余开源项目突然火了，企业IP团队介入，可以理解。
但故事没有结束。
我和这位博世工程师已经在讨论其他潜在的共创方案——把更多有价值的AI工具以更合理的方式开源出来。大公司和个人创新、企业利益和开源精神之间的张力，值得单独写一篇。
后续有进展再聊。
五、回到那位"大头兵"
回到开头那条让我停下来想了很久的留言。
这位一线工程师的焦虑是真实的。但我想告诉他：
你每天做的数据分析、写的安全需求、在评审会上指出的问题、在实车测试中踩过的坑——这些know-how，才是AI工具真正缺的东西。
AI可以5秒钟生成一个看起来完美的HARA表格。但判断那个表格对不对、漏没漏、够不够——得靠你。
未来赢家不是会用AI的人——未来每个人都会用AI，就像现在每个人都会用智能手机——而是能把领域know-how结构化注入AI的人。
你不是被AI替代的人。你是让AI真正能用的人。
📌** 你所在的公司，是自己在开发AI工具，还是在找外部方案？**
欢迎在评论区分享你的观察——下一篇文章可能会引用你的洞察。