2026-08-24 每日思考

今天 HN 上那条"欧洲如何扼杀创客和小微创业者"的帖子，得分 377，评论区一片哀嚎。我点进去看完，心里挺不是滋味的。Lectronz 创始人说得很直白：欧盟的 GPSR（通用产品安全法规）要求每一件电子产品都必须有完整的合规文档、测试报告、欧盟代表——这些成本摊到小批量硬件上，直接让单价翻倍甚至更多。一个做开源硬件模块的独立开发者，可能一个月就卖 200 块板子，合规成本却要几千欧元。

这事儿让我想到自己做 AI 代码审查工具时的一个困境。我做的这个 MVP，目标是在 CI 里自动检测安全漏洞和性能问题。技术上，我可以用最新的模型做语义理解，可以设计很精巧的 prompt 来引导模型发现深层 bug。但真正阻碍我把它推向市场的，不是模型能力，而是信任问题——不是模型不够聪明，而是用户凭什么相信一个 AI 工具的审查结果？如果它漏报了一个严重漏洞，责任算谁的？如果我建议的修复方案引入了新问题，谁来兜底？

这跟欧洲创客的处境本质上是同一件事：创新的瓶颈往往不在技术，而在基础设施和信任成本。对硬件创客来说，技术方案已经成熟，Arduino 和树莓派让原型设计变得极其便宜，但合规认证这个"软基础设施"没有跟上。对我这种做 AI 工具的人来说，模型能力已经不是瓶颈，但"AI 审查结果的责任归属"这个制度问题没解决，就永远只能在小圈子里自嗨。

今天另一条新闻让我稍微乐观了一点——seL4 在 AArch64 上的安全证明完成了。seL4 是那种"正确性被机器证明"的操作系统内核，花了十几年才做到今天这一步。它的存在证明了一件事：当你在底层把信任问题解决掉，上面的创新空间会被极大地释放。如果未来嵌入式设备都跑在 seL4 上，那么开发者就不用担心内核层面的安全漏洞，可以把精力集中在应用逻辑上。

这给了我一个启示：与其抱怨信任成本高，不如想办法把信任"工程化"。就像 seL4 用形式化证明来消除内核的不确定性，我的 AI 代码审查工具也应该引入某种"可验证性"——比如，让模型输出每个漏洞的推理路径和证据链，让用户能追溯它为什么认为这是漏洞；或者，对修复建议做静态分析验证，确保不会引入新的语法错误或类型问题。这当然会增加开发量，但可能是从"玩具"走向"工具"的必经之路。

欧洲创客的困境短期内看不到解法——大型合规体系不可能为小批量产品开绿灯。但技术人至少可以做的，是在自己的产品里尽量降低使用者的信任成本。哪怕只是多写一份清晰的文档，多提供一个可复现的 demo，都是在为整个生态的"信任基础设施"添砖加瓦。

明天，我打算给代码审查工具加一个"证据链导出"功能。不指望它能解决行业问题，但至少让用它的人知道，每个警告背后都有据可查。