周三下午，一位开发者在审核报告里看到两行完全矛盾的话。同一页纸上，左边写着"未检测到AI组件——欧盟AI法案：不适用"，右边却列出五条"高风险AI系统"的合规义务。被审查的对象是tRPC，一个纯粹的数据序列化工具，跟神经网络毫无关系。
这不是系统bug，是词义撞车。
事件还原：一个词的两种命运
tRPC是TypeScript生态里常用的RPC框架，它的transformer组件负责把数据转成可传输格式——比如用superjson处理日期对象，用devalue处理循环引用。这里的transformer是"数据转换器"，不是GPT背后的"注意力机制Transformer"。
问题出在第二次审核的产品描述里。开发者如实写了"transport layer"和"WebSocket transport"，描述tRPC如何处理网络通信。审核工具的EU AI Act分类器扫描到"transport"这个词，自动匹配到"关键基础设施-交通运输"领域，触发高风险标记。
更荒诞的在后面。分类器把"高风险"标签喂给LLM，LLM接到指令后开始生成对应的合规发现。于是五条AI治理建议凭空出现，针对一个没有任何机器学习代码的库。而同一报告的另一模块，静态分析工具诚实地标注：未检测到AI组件。
两个结论共存于一份文档，没人喊停。
第三次审核才破局
修正后的描述做了两件事：第一，把transformer明确定义为"数据序列化工具，非神经网络架构"；第二，逐条澄清代码库不含机器学习模型、不含LLM集成、不含AI决策组件。
结果：EU AI Act标记消失，ISO 42001标记消失，真正的代码问题浮出水面。
从第一次到第三次，同一个代码库，不同的只是描述文案。监管合规的判定权，意外落在了产品说明书的措辞上。
三个实操教训
第一，写AI审核用的产品描述时，否定句和肯定句同等重要。只说"这是什么"不够，必须主动声明"这不是什么"。技术术语与监管词汇的重叠比你想象的更隐蔽——transport可以是网络层协议，也可以是欧盟重点监管的交通运输业。
第二，别把报告内的自相矛盾当成排版错误。"未检测到AI"和"高风险AI"不可能同时为真，看到这种冲突，先查输入描述而非纠结输出结论。AI生成内容的幻觉不会自己标注，需要人眼拦截。
第三，transformer这个词的撞车正在恶化。HuggingFace的transformers库（机器学习）、tRPC的transformer插件（数据转换）、论文里的Transformer架构（注意力机制），三者在代码仓库和技术文档里混用。命名空间的冲突没有技术解决方案，只能靠上下文人工消解。
更深的问题：谁对分类负责
这次事件暴露的是自动化监管工具的核心张力。EU AI Act的合规判定本应基于实质风险，但工程实现上只能依赖关键词匹配和LLM推理的叠加。第一层分类器做字符串匹配，第二层LLM做生成式解释，两层之间没有一致性校验机制。
开发者拿到的报告是一份缝合文档：静态分析的客观结论，和LLM基于错误前提的演绎，被格式化成同等权威的条目。这种设计把核实负担完全推给了阅读者——而大多数开发者不会逐行比对矛盾陈述。
tRPC的案例是幸运的，因为它足够简单，没有AI组件是明确事实。但如果是一个 genuinely 使用机器学习、但风险等级被误判的系统呢？关键词匹配的粗糙性可能导致双向错误：无害系统被过度监管，真正的高风险系统因描述措辞巧妙而降级。
目前没有看到工具厂商针对这类失败模式的公开修复计划。开发者能做的是：在提交审核前，把产品描述当成法律文书来写，假设每个技术术语都有两种解读空间，并主动封堵更危险的那种。
毕竟，当你的TypeScript序列化库能被"transport"这个词送进高风险名单时，没人能指望算法会自己理解语境。
热门跟贴