降本增效为什么成了AI产品落地的第一站

看过很多公司的AI岗位的招聘JD，公司的内部提效讲的最多，今天就聊一聊为什么降本增效成了AI产品落地的第一选择。

先做内部，不是因为内部容易

法律场景：把审核拆成六步

公司内部最常见的法律场景是合同审核。这个场景的痛点很具体：小微企业养不起常年法务，律师费动辄数十万；普通法务覆盖不了所有领域，跨行业合同尤其吃力；法条和判例持续更新，人力很难实时跟进；人工审核一份合同通常要数小时到数天。

大模型在这里的匹配度来自四点：法律工作本身就是结构化推理；法条、司法解释、判例需要大量检索；审核意见和修改建议有固定格式；模型不疲劳、速度快，可批量处理。

落到产品设计上，合同审阅智能体被拆成六个流程串联：读取文件、常规审核、法律引用条款审核、公司信息审核、汇总输出、上传协作工具。

读取环节支持 Word、PDF、TXT，解析结构化内容。常规审核用专业提示词，按「问题-分析-修改建议」三段式输出，覆盖违约责任、支付条款、保密条款、知识产权归属。

第三个流程值得单独说。它检测合同是否引用《担保法》《合同法》《经济合同法》《物权法》《侵权责任法》《民法总则》等法律。这里有个必须处理的问题：这些法律已于 2021 年 1 月 1 日被《中华人民共和国民法典》整合取代。提示词里如果还留着旧法名，审核结论就是错的。法律时效性维护，是这类产品的长期成本，不是一次性工作。

第四个流程从合同里提取甲方乙方名称，调用天眼查、企查查 API 查询公司是否存在、经营异常、失信记录、股权冻结、法律诉讼，生成企业风险总结报告。

最后两步是汇总和分发。汇总建议用代码拼接，而不是让大模型重新生成，这样能省 Output Token。结果自动上传飞书、钉钉、企业微信，方便团队协作。

面试场景：问题数量本身就是设计

HR 场景的切口是面试。常规岗位找对标 JD 模仿即可，问题不大。难的是两类：新型岗位缺少对标，用人 TL 和 HR 经验不足；跨领域岗位是非标品，比如「有技术背景做过内容的市场总监」，很难直接描述。

面试助理智能体的设计，先从问题结构入手。4-3-1 结构：4 个基础问题引入话题、了解候选人基础、确认基础条件、快速过滤不符合的人；3 个深入问题逐层递进，事实到判断再到迁移，第一问确认做过什么，第二问确认理解深度，第三问确认能否迁移到新场景；1 个终极问题考察长期动机和文化匹配，判断候选人是否来得了、留得住、长得好。

深入问题用行为面试法，按 STAR 展开：情境是当时面临什么情况，任务是你需要完成什么，行动是你具体做了什么、为什么选这些方式，结果是最终效果如何、有什么量化指标、你如何评价自己的表现。

这套结构解决的是无效提问。「你最大的缺点是什么」与岗位能力无关，「你还有什么问题吗」太敷衍，都没有考察有效信息。

输入侧还有三块内容要接：岗位 JD 和候选人简历是必须项，来自文件或内部系统；岗位内部需求和企业文化不是必须，但重要度分别偏高和中。这些内容通过 RAG 整理进企业知识库，让岗位要求更贴合企业自身特质。

财务场景：为什么它最适合第一个上

如果只能选一个先做，选财务发票审批。理由是四条：频率最高、ROI 最可量化、规则为主降低风险、成功后可以快速复制到其他场景。

发票审批的判断要素有优先级。发票完整性（是否可识别）、购买方验证（公司名称、识别号是否正确）、公司政策（单科目报销总计是否符合规定、政策是否允许）是高风险项。发票时间是否在报销时效内、科目是否符合规定并与提交人匹配、金额是否合理、提交人岗位是否符合报销条件，是中风险项。

输出结果对应四种动作：通过，自动进入支付队列；驳回，返回错误原因；人工复核，标记风险等级并路由给特定审批人；挂起，等待预算释放。

这里有两个机制值得展开。一是预算冻结：提交报销时先冻结对应金额、标记为使用中，但不在财务系统做实际扣减，打款完成后才扣减并释放冻结标记。它防的是并发超支，逻辑类似酒店预订时的信用卡预授权。

二是内部信用评分：基于员工历史报销记录、违规记录量化信任度。与金融信用评分逻辑相同，维度不同——它关注报销合规性，不关注还款能力。高信用走快速通道，低信用加强审核。评分模型不能替代规则引擎，规则处理确定性问题，评分处理模糊地带。

确定性的交给代码，模糊的交给模型

三个场景放在一起看，有一条共同的边界划分原则：确定性用代码，模糊性用 AI。代码是 100% 正确的，但只能处理已知规则；AI 能处理未知模式，但有概率出错。

正则表达式就是这条原则的例子。从合同里提取公司名称、日期、金额，大模型也能做，但正则的确定性是 100%、成本几乎为零。能用规则解决的，不要用模型。

由此延伸出渐进式智能化的三步走：第一步硬编码，确定性高、先跑通流程；第二步表达式引擎，让运营人员通过界面配置规则，比如金额大于 5000 且科目为餐饮，不需要开发介入；第三步机器学习，自适应优化。模型只在规则覆盖不到的模糊地带引入。

这条路径的另一个好处是可测试。每个子环节单独测试，通过后再串联，而不是直接端到端测试。端到端测试一旦出问题，无法定位是读取错了、提示词偏了，还是 API 返回异常。

做出来只是 20%

内部产品有个容易被低估的环节：推广。做出来只是 20%，用起来才是 80%。

合同审核的结果上传到飞书，不只是为了存档。把文档整合进协作工具，团队才能协同，后续的 AI 化和数字化才有落点。这一步在很多项目里被当成收尾，实际上它决定了产品有没有人用。

推广的思路也不复杂：不卖 AI，卖省时间；不做培训，做帮忙。同事不关心你用了什么模型，关心的是这份合同审核从几小时变成几分钟。

对个人而言，这套东西的价值是双向的。公司内推动成功，得到的是经验、口碑、发展机会和简历背书；没有推动机会，把产品细节和逻辑搞明白，同样能在简历上加分。进可攻，退可守。