我给 AI 加了一条死规则：说错一个字，结论就作废
我做了十年 Java 后端，主要在外包。然后我用 AI 做了个桌面产品，叫 ClauseEye（契眼）。
它干的事：你把劳动合同、租房合同、Offer、离职证明丢进去，它把里面的坑一条条挑出来。
但技术选型不是我想说的。我想说的是中间那个坎，以及我最后怎么绕过去的。
项目差点死在一句话上
第一版我写得很爽：合同文本丢给大模型，让它输出风险点。半天就能跑通，效果看起来相当好。
然后它给了我这么一条：
本合同第 8 条约定试用期 6 个月，超过法定上限。
我打开原文去找第 8 条。
没有第 8 条。这条风险是它编的。
它不是随口胡说，它写得很像真的：有条款编号、有具体月数、有法条口径。你如果不懂法律，你根本分辨不出来。而这就是最危险的地方——我的用户恰恰就是不懂法律的那批人，他们要拿着这个结论去跟 HR 谈、去跟房东谈。
一个编造出来的"风险点"，比漏掉一个真实风险点危害大得多。漏掉，用户损失的是一个机会；编造，用户损失的是谈判的底气，以及对你这个工具的信任。
所以我改了一个决定：不让模型做主
原来我默认"大模型能做合同审查"。改完之后我换了个假设：
模型不可以做最终判断，它只能提建议。
产品被拆成两层。
底层是本地规则引擎。完全离线，纯关键词和数值判定，一次模型都不调用。这一层负责所有能定死的判断。
上层才是大模型，而且降级成了"可选增强"——用户想用，填自己的 API Key。
这个顺序非常关键：先有规则兜底，再谈模型增强。反过来做，你永远不知道某一条结论到底是规则给的还是模型编的。
把法条翻译成代码，比调模型难得多
规则引擎听起来很土，写起来一点也不。
举一条最简单不过的规则："试用期超上限"。
听起来一句话就完了。实际写起来不是——试用期的法定上限不是一个固定数字，它按合同期限分级，不同期限对应不同的上限。你必须把法条原文读懂，拆成分档的判定条件，再翻译成代码。
这种翻译，我做了 186 条，覆盖劳动合同、租房、Offer、离职证明、工伤鉴定、装修、二手房、驾培等 11 个场景。
一多半时间花在这里。没有人会为这件事鼓掌，因为"把法条翻译成分支逻辑"写出来一点都不性感。但它才是这个产品真正的地基。
不是所有判断都能交给模型
有个决定，我从头到尾没让 AI 参与。
第一版架构是标准的 Web 方案：后端 Spring Boot，前端 React，文档上传到服务器分析。这套我闭着眼都能搭。
要处理的东西是：劳动合同、Offer、离职证明、工伤鉴定。
你愿意把工伤鉴定报告上传到某个不知名公司的服务器上吗？
不愿意。这跟"我们在意隐私"的营销话术无关，是产品能不能成立的问题。所以架构改成了没有服务端——文档全部留在本机。深度分析要用大模型，用户自己填 Key，我不做任何中转。
这个判断来自我做过政企项目的经验。我让 AI 把所有技术方案的优劣列出来过，列得很全，但"工伤鉴定报告不能上云"这件事，它不知道。它不认识我的用户，不知道他们怕什么，更不知道他们愿意为什么掏钱。
最后一道防线，只有一句话
回到最开头那个坑。怎么防止模型再编条款？
做法简单到有点土：
模型返回的每一条风险，都必须能在原文里逐字定位。定位不到，直接丢弃。
不管它说得多有道理、编号多具体、法条引用多像真的。找不到原文，就是幻觉，扔掉。
这条规则换来了整个产品最值钱的一个特性：每一条结论你都能自己核对。它说第几条有问题，你点开原文就能看到那句话，你自己的眼睛就是最终裁判。
这是我把大模型放进来之后唯一敢承诺的事。它不会替你判断，它只是帮你把值得看的地方圈出来——圈错了，你一眼能发现；漏了，规则引擎还在兜底。
三条我真正学到的东西
如果你也在做 AI 产品，我把这次的体会压成三句：
别让模型做它做不到的事。 我一开始的错不是技术错，是定位错——我把一个天生不可靠的东西放到了做决策的位置上。把它挪到"提建议"的位置，产品立刻就立住了。
AI 写代码很快，判断要靠自己。 它帮我写规则、写测试、写打包脚本，非常快。但"模型编造条款对这个产品是致命的"这个判断，是我看到那句假话之后才下的。它不会自己意识到自己不可靠。
最难的部分通常不性感。 186 条法条翻译、逐字定位的校验——这些没有任何热度，也讲不出漂亮的故事。但你的产品能不能上架、用户敢不敢信，分界线就在这里。
项目开源，代码全在：github.com/1576584678/…
有在做类似东西的，或者正在纠结"该不该让模型直接出结果"的，评论区聊。
