交流会上，一位刚取得破产管理人资质的同行分享了他的项目：债权申报计算器。
想法很实际。债权申报要算天数、算利息、算截止日，各地规则还不一样——深圳出的指引用 360 天，换一个地区又是另一个口径。他让 AI 教着他做，十几稿改下来，界面像样了，卡在了计算上。卡到什么程度？这位律师朋友现在开始自学编程了。
他的困境一句话就能说清：他把一个“算”的问题，交给了只会“猜”的东西。
问题出在一个分工错误上
我这几年用 AI 处理法律工作，最重要的一个分工原则：判断归模型，计算归脚本。
大语言模型是概率预测的逻辑，不是算的逻辑。它生成每一个字，都是在算“下一个字最可能是什么”。这套逻辑做归纳、做推理、做表达，强得惊人；但让它做四则运算，就像一个特别有才华但从不带计算器的助理——智力过剩，算术不稳。
脚本是另一个物种。你用 Python 写一段代码做日期推算，它和你计算器里按出 1+1=2 是同一回事：电路级的确定性，跑一万次，一万次同一个结果。
法律场景里，“大概对”就是错
别的行业容错率高，写文案、做摘要，AI 算出九成对就够用了。法律工作不行。
诉讼时效差一天，案子没了。迟延履行利息的起算日错一天，金额全错。债权申报的截止日错一天，管理人面对的是一堆债权人的质问。这些场景里不存在“大概对”——对就是对，错就是错，没有中间态。
所以凡是“有标准答案”的环节，都要从模型手里拿出来，交给脚本。
三条操作经验：下单、参数化、拒答
第一，脚本不需要你写，只需要你下单。那位破产管理人同行最后去自学编程，其实不必。现在你跟 AI 说“写一个脚本，把这个文件夹里的 PDF 全部转成 Markdown，不要联网”，它写得出来。你要掌握的不是语法，是提需求的能力：输入是什么、输出是什么、边界是什么。
第二，规则要参数化，别焊死在代码里。深圳的 360 天就是最好的教训：地区差异不该写死在计算逻辑里，而应该做成一张参数表——浙江一套参数，江苏一套参数，脚本运行时先读表再计算。规则变了改表，不用改代码。那位同行卡住，一半卡在这。
第三，脚本的副产品是诚实的拒答。我自己的工作区里，任何文件进来先过转换脚本。脚本同时承担一个职责：识别这个文件当前处理得了还是处理不了。处理不了的，明确输出“这个文件我没办法完整读取，请提供更健全的信息”，把前提缺陷摆在明面上。这种“以答的方式拒答”，比任何自信满满的回答都可信。
最常踩的三个坑
把计算当判断交给模型，是最常见的错误。让大模型直接算利息、算期间，它对九次错一次，而你不知道是哪一次。
反过来也错：把判断强行脚本化。流程怎么分步、措辞怎么拿捏，这些没有标准答案，写成死规则反而把 AI 的灵活性捆死了。
还有一个隐蔽的：脚本没有异常出口。正常路径跑得通，异常输入直接崩溃或者静默出错。好脚本的标志不是它对的时候多对，是它错的时候肯说话。
这条规律的边界
分工律只适用于“有标准答案”的环节。法律适用的涵摄判断——这个事实构不构成违约、这个条款有没有效力——本身就是概率性的智力活动，脚本帮不了，也别强求。
分工律也不意味着模型不可信。恰恰相反，把它不擅长的确定性环节拿走以后，它在判断环节的表现反而更可信了。
最后：先问数字是谁算出来的
确定性不是模型的义务，是架构的责任。
下次再看到 AI 给出的一个日期、一个金额，别问“它算得对不对”，先问“这个数字是谁算出来的”。如果答案是模型本身，你就多了一个要人工复核的点；如果答案是脚本，你可以直接采信。
这个区分不费什么事，但它决定了你的 AI 工作流是“看起来专业”，还是“经得起追问”。
作者简介： 陈石律师，浙江海泰律师事务所副主任、高级合伙人、房地产与建设工程部主任，宁波市律师协会副秘书长、第七届宁波仲裁委员会仲裁员，聚焦建筑房地产、投融资、并购重组及商事争议解决。曾获多家法律媒体与专业机构认可，荣登 LegalOne 2025 中国区建工及房地产实务先锋 45 强、律新社 2025 年度管理合伙人 20 佳（华东），入选《商法》The A-List 法律精英，获评 ALB China 区域市场十五佳长三角地区律师新星，并获律新社 2024 年度并购领域品牌之星。长期为万科、华润置地、信达地产、保利置业、招商蛇口、中海地产等企业提供法律服务，承办“首宗百亿地王”“长春第一高楼”“台州第一高楼”等代表性项目，累计服务项目投资额超千亿。近年来持续推动 AI 与法律实务融合，强调以结构化方法打通技术逻辑、法律判断与商业场景；著有《赋能法律人：AI 底层思维与应用范式》，并在多地开展相关主题讲座与分享。四明山法师 AI 夜校（legalAGI.cn）发起人。