LEXNUS

嗨，Product Hunt，

我花了近十年时间担任 CPTO，按照本应被构建的方式来打造合同生命周期管理平台。在那段时间里，我阅读了数百笔交易的赢单和丢单记录，这些丢单都有其共性。法务团队会购买一套系统，花四个月时间进行配置，最终得到一种更快的文档流转方式，而同样几个问题每个季度都会反复出现——责任上限超出了批准范围，一项赔偿条款八个月前被销售部门的某人修改过，直到续约时才被发现。

我们并非在构建糟糕的产品。我们围绕合同这个值得管理的对象来构建产品，因此所有自动化的环节都围绕着文档展开。而判断一份合同是否可接受的标准藏在别处，通常藏在 Word 模板里，藏在团队中任职时间最久的那个人脑子里。模板可以描述什么是合格，但它无法阻止错误的内容被签署出去。

这就是为什么企业法务人员至今仍在逐一阅读送到他们桌上的每一份文件。他们所使用的工具栈里，没有任何东西真正理解这些规则。

Lexnus 从另一个方向入手。你导入你已经在使用的条款文档，Lexnus 会将其拆分为单独的条款，由你审核哪些可以纳入你的条款库。然后你针对这些条款编写规则——责任上限的可接受区间、你所认可的管辖法律。这一整套规则就是你的"作战手册"。当对方的文件进来时，系统会依据作战手册进行比对，每条规则都会返回"通过"或"违规"的标记，你的政策所要求但文件中缺失的任何内容都会以缺口的形式呈现出来。

这种分工的意义比听起来更重大。AI 阅读合同并推断每条条款的含义，但它不决定该条款是否可接受。你的规则来做判断，而且每次执行的结果完全一致。如果超过五百万欧元的上限需要你的签字，那么三月需要你签字，到了十一月同一交易对手带着相同的文件再次出现时，仍然需要你签字。

更棘手的版本其实已经在发生——你的商务团队正使用他们手边打开的任何 AI 助手来起草合同。在我所见过的任何公司里，禁止这种做法从来都不奏效。通过 MCP 连接 Lexnus 之后，助手会基于你已批准的条款语言进行工作，并在任何产出发送出去之前，先经过你的作战手册审核。销售团队保留了速度，而你依然能弄清楚最终产出的是不是你本来就会签署的内容。

目前已上线的就是这整个闭环：从条款导入，到对传入合同的评分分析，再到组装功能，使业务部门能够基于你已批准的语言自行生成合同。我们提供两周试用，包含 200 次分析额度。

如果你在一家 50 到 1000 人规模的公司负责法务工作，我想了解你们的政策目前写在哪里，以及是什么在阻碍人们遵守它。如果你也在这一领域进行构建，请告诉我你认为确定性规则层会在哪里失效。我今天一整天都会在这里。