上个月一个做 AI 工具的朋友问我你们汽车电子的 ASPICE 到底是在做什么。我说你等等我找一份项目文档给你看。翻了五分钟找到一份五十页的过程评估报告发过去。他看了十分钟回了一句这不就是 Harness Engineering 吗。我说什么是 Harness Engineering。他发来一张图上面写着Agent Model Harness。他说Harness 就是模型外面那层壳——系统提示词、约束规则、反馈循环、权限控制。没有它模型再强也跑不稳。我盯着这句话看了很久。我们天天骂的 ASPICE——那些又长又臭的流程文档、阶段评审、需求追溯矩阵——不就是给”人”套上的那层壳你是不是也觉得 ASPICE 是负担。我刚进汽车行业时最不适应的就是它。一个功能以前自己画个流程图就写代码了现在要先写系统需求再拆软件需求每条要编号、量化、写验证方法。设计要评审代码要测试每条需求必须在测试报告里找到验证记录。一个简单的事拉成三个月。我当时觉得这东西就是用来折磨工程师的。但我最近不这么想了。不是因为 ASPICE 变好了是因为我看到了没有这层约束的人在面对 AI 时是什么状态。团队里有个小伙子用 AI 写 CAN 通信模块特别快半小时搭完框架一周联调通过。所有测试用例都过了。然后装车车停一晚第二天早上打不着火。排查了三天AI 生成的驱动里CAN 收发器在总线休眠后没进入低功耗模式。总线上一个常规周期报文每次都把收发器从休眠唤醒——ECU 反复上电→休眠→上电一晚上静态电流跑了几十毫安。正常应该是 0.1mA。他没写需求所以没有”休眠模式静态电流 ≤ 0.1mA”。他没做 FMEA所以没有”总线误唤醒导致蓄电池亏电”。他没做集成测试所以没有”12 小时静置后电池电压”这个场景。问题出来后他也不知道从哪查起——因为通信完全正常他从没想过”通信正常时系统在不该工作的时候是不是也在工作”。ASPICE 逼你做的事——写需求、做 FMEA、设计验证——就是你的 Harness。我做了张表发给我那朋友他说你做汽车电子的可惜了应该来写 Harness。ASPICEHarness约束对象工程师团队AI AgentV 模型左侧定义 → 右侧验证Guides前馈→ Sensors反馈需求管理每条编号、量化、验证方法每个指令有目标、边界、验收标准FMEA失效模式写进规则库防止重犯每次 Agent 犯错修进环境永久防止评审门禁每个阶段有质量关卡每次工具调用前有权限校验可追溯性需求到代码到测试双向绑定指令到生成到验证全链路追踪持续改进过程评估 → 改进计划 → 下一周期每次失败 → 规则加固 → 环境进化他说了一句你们跑了二十年的 ASPICE就是给 AI 圈准备的参考答案。我半开玩笑半认真地回了句所以你承认汽车电子比互联网先进二十年他说只在这一件事上。我以前是骂 ASPICE 骂得最凶的那批人。做过一个项目文档比代码多评审会开了八轮每一轮都在改措辞没一轮在讨论技术。但现在回头看ASPICE 里真正有价值的东西——需求要量化、要可验证、失效分析做在前头——不是 ASPICE 的问题是我们把它做成了形式主义。而 Harness Engineering 恰恰给了我们一个机会把这些规则从”写在纸上的流程”变成”跑在代码里的约束”。以前 ASPICE 的规则是人读的你写了五十页文档工程师看不看全靠自觉。现在 Harness 的规则是 Agent 读的你写到 AGENTS.md 里Agent 每次行动前都必须遵守。ASPICE 教你”要做什么”Harness 让 AI”不得不做什么”。我那个朋友后来说了一句话我到现在还在想你们做了二十年 ASPICE已经把”怎么让人可靠地写代码”想透了。现在 AI 来了要做的不是抛弃它——是把那些规则从给人看的流程翻译成给 AI 看的配置。ASPICE 是给人戴的缰绳Harness 是给 AI 戴的——缰绳不一样但驯服的逻辑从来没变过。所有核心的工程规范说到底都是一种驯服术。驯服人驯服 AI目的都一样把不可靠的天才变成可靠的系统。你还在骂 ASPICE 吗