PO-01 · 批复条件落实核查

① 场景引入

一、这件事现在是什么样

放款与贷后管理 · 真实业务触发

批复已下发、客户催放款，放款中心要在放款前逐项核凭证。支行会问「能不能先放、他项权证下周就下来」——这句话怎么答，是放款岗每天都面临的考验。

二、痛点 · 每条都有来源

1. 「只办抵押受理登记未取得他项权证就放款」「保证人未面签」是实务中公认的变通操作，「批复条件悬空」是大量不良复盘的共同起点
   依据：某农商行《企业贷款操作规程》：受理2个工作日、调查评价5个工作日、A/B角客户经理制且报告须签字盖章、审查双人制、贷审会5个工作日
2. 核查一户要逐条对照批复原文、逐项索要实质凭证（他项权证、面签影像、股东会决议），单户以小时计，而放款有业绩期限
   依据：某农商行抵押贷款流程：抵押登记以不动产登记部门办结时间为准、登记成功后1个工作日放款——登记时长不受银行控制
3. 监管罚单里「贷款实际用途与合同约定不符」「信贷资金被挪用」高频出现，某农商行因此被罚 120 万并问责三人
   依据：某农商行2025年罚单：贷后管理不到位、贷款实际用途与合同约定不符，罚款120万元、副行长等三人被问责
4. 条件核对的现状是清单打勾——勾是打了，凭证在不在档案里没人逐份翻
   依据：一线吐槽台账形式主义：「花90%精力做台账，10%精力做业务风控」「同一套数据按不同格式反复填报五六遍」

三、换个做法之后

变化不在「快」，在「参与的角色」和「覆盖的范围」

✕ 现在的做法

• 「只办抵押受理登记未取得他项权证就放款」「保证人未面签」是实务中公认的变通操作，「批复条件悬空」是大量不良复盘的共同起点
• 核查一户要逐条对照批复原文、逐项索要实质凭证（他项权证、面签影像、股东会决议），单户以小时计，而放款有业绩期限
• 监管罚单里「贷款实际用途与合同约定不符」「信贷资金被挪用」高频出现，某农商行因此被罚 120 万并问责三人
• 条件核对的现状是清单打勾——勾是打了，凭证在不在档案里没人逐份翻✓ 交给 Agent 之后多来源文件一次读入，先做口径与完整性校验，再开始算每条结论绑定来源文件、字段或条号，可以被审产出是企业真会流转的正式件（带签批栏），不是一张展示用的表该拦的地方给出「现在还不能提交」，并给不用干等的替代方案

四、场景闭环

5 步 · 每一步的产出都是下一步的输入

1. 条款拆解 · 批复文本变成凭证清单每项条件拆出「要什么凭证、谁出具、办结标志是什么」
2. 凭证归位 ·档案逐份挂接受理件/办结件/影像件分类登记，与凭证清单对齐
3. 实质核验 · 受理不等于办结他项权证与受理凭证的区分、面签双录的时点核对、决议的有效期
4. 关联核对 · 受托支付对象是谁支付对象与借款人、担保人的关联关系比对
5. 三色结论 · 核查单生成绿=已落实 黄=形式资料在但实质缺 红=缺实质证据；红项列处置选项供人决策

要准备什么：批复文书（含前提条件清单）条款逐条拆解成可核对的凭证项放款中心档案（抵押登记受理凭证、保证合同、面签影像）逐份比对用的原始件不动产登记状态查询结果受理与办结的时间差是关键受托支付对象清单与购销合同支付对象与交易背景的关联核对

为什么这个场景值得做

优先级评分：痛感 5 × AI 适配 4 ÷ 落地难度 2.5 = 8.0

最大差异点：与信贷系统里「条件打勾」字段的区别：勾选记录的是人的确认，这里核的是凭证本体——受理凭证和他项权证是两种东西，影像件逐份比对后给出三色结论，红色项必须人工处置。

评分口径：痛感看「这事没做好谁会生气、生气到什么程度」；

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」；

落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。

五、会产出什么

判断标准只有一个：这份东西能不能直接进企业的流程

• 正式件本体：批复条件落实核查单.xlsx 三色结论 · 红项含处置选项与金额影响 · 放款岗签字栏
• 可派发清单：凭证索引与缺口清单.xlsx 逐份凭证的档案位置与缺失项
• 可派发清单：关联方比对底稿.xlsx 受托支付对象/担保人与借款人的股权关系这套东西不承诺什么核查结果只呈现事实（凭证在/不在/是受理件还是办结件），放不放款的指令永远是人下。不自动放行、不自动拦截系统流程，只生成核查单供放款岗签字。

② Live Demo（演示逐步）

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」，用的是真实业务格式的脱敏构造数据， 不宣称已接入客户生产系统，也不承诺任何效率提升百分比。

案例设定：澜川银行放款中心 2026 年 7 月 22 日（放款前 8 日）收到恒信机械 2,500 万批复，客户在催放款、支行问「能不能先放、他项权证下周就下来」，——放款岗要在 7-29 前出三色核查单，放款指令由放款岗与审批人共同签字。

输入文件 4 份 · 红项 3 条 · 影响敞口 400 万元 · 结论暂不放款

输入银行手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

• 01_批复文书_LC-2026-恒信机械.pdf 贷审会 7-10 通过、7-14 下达的批复文书（含 8 项前提条件）审批人签发 · 一次性文件
• 02_放款中心档案_放款前清点.xlsx 放款中心档案清点（脱敏）放款中心 · 当日清点
• 03_受托支付对象_辰宇贸易_关联核查.xlsx 受托支付对象辰宇贸易与借款人的关联关系核查（脱敏）放款中心 + 合规岗
• 04_保证合同与股东会决议_日期核对.docx 保证合同与股东会决议的日期顺序核对（脱敏）法务岗

注意标橙色那一份 —— 02_放款中心档案_放款前清

点.xlsx。它放款中心 · 当日清点，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

这笔贷款的批复和放款档案都在附件里，逐条核一下批复条件落实了没有。 注意区分受理凭证和办结凭证，别看到扫描件就算落实。 关联方那块重点看：受托支付的对象跟借款人、担保人有没有关系。 放不放、什么时候放，核查单给我，决定我来做。

凭证分类规则、三色判定口径、关联方比对逻辑都在能力包里。

触发事情是这么来的

7-22 放款前清点、7-29 前出核查单、支行催先放

批复已下发、客户催放款，放款中心要在 7-29 前逐项核凭证。支行会问「能不能先放、他项权证下周就下来」——这句话怎么答，是放款岗每天都面临的考验。

第 1 步 · 条款拆解 · 批复 8 项条件变成 8 张凭证

每项条件拆出：要什么凭证、谁出具、办结标志

第 2 步 · 凭证归位 · 档案逐份挂接

7 份已到，1 份仅受理件（他项权证）

这一步的看点 · 把技术动作翻译成钱支行那句「先放款、他项权证下周就下来」值不值——若按受理凭证放款、后续抵押落空，按抵押物同区处置价 2,100 万计，本笔 2,500 万将形成 400 万以上的无担保敞口；叠加受托支付对象为关联方的 600 万，敞口合计 1,000 万。核查单把这两个数摆在「催放款」那句话旁边。

第 3 步 · 实质核验 · 受理不等于办结

他项权证与受理凭证的区分是本笔的红项 #1

这一步的看点 · 从历史里想起了本行踩过的坑档案里那宗 2024 年广元贸易：当时他项权证只有受理凭证就放了款，后来抵押物被第三方先行查封，本行优先受偿权旁落。Agent 在本次核查单上给「他项权证」这项标红，并引用了那宗案例的文号。这条不靠当年放款岗还记得。

第 4 步 · 关联核对 · 受托支付对象是谁

实控人持股 40% = 关联方

这一步的看点 · 该拦的地方拦住了核查单结论：这笔贷款现在不能放——三项红色：①他项权证未取得（仅受理件，登记机关尚在办理）；②受托支付对象「辰宇贸易」是借款人关联方（实控人持股 40%）；③保证合同签订日期早于股东会担保决议 3 天。替代方案：①权证办结后放款，按登记机关时限约 5 个工作日；②先行受托支付到非关联交易对手，其余按进度。每一项的金额影响都列在单上。

第 5 步 · 三色结论 · 核查单生成

绿 5 / 黄 1 / 红 3，红项列处置选项供人决策

这一步的看点 · 排除性结论「实控人连带保证面签程序可以排除疑虑」——双录影像时点、见证人签字、决议编号三者齐全，这项从核查单上移出。

这笔贷款现在不能放三项红色：①他项权证仅有受理件（缺办结凭证，按同区处置价 2,100 万算，抵押落空将形成 400万无担保敞口）；②受托支付对象辰宇贸易是借款人关联方（实控人持股 40%，属行内禁止的受托对象，金额影响 600万）；③保证合同 7-10 早于股东会决议 7-13 共 3 天（程序瑕疵）。两个不用干等的替代方案：①方案一：他项权证办结（约 7-29）+ 受托支付对象更换为非关联对手 + 补股东会确认后重签保证合同，预计 8-5 前可放款（影响金额 1,000万敞口全部覆盖）；②方案二：先行受托支付到非关联对手（辰宇贸易 600 万切走）、其余部分按进度放 1,500 万，剩余 1,000 万等权证办结后补放（放款节奏分两次，影响金额敞口同上但放款业绩分两次入账）。

之后这一次跑完，公司多了什么

不讲省了多久：讲少了几个隐患、沉淀了什么

• ✓ 「先放款后补手续」第一次有了逐项可查的证据链
• ✓ 受理凭证与他项权证的区别被制度化——广元贸易的教训不再重演
• ✓ 关联方受托支付在放款前而不是贷后被发现
• ✓ 放款岗的角色从「被支行催的人」变成「拿着核查单说话的人」

追问现场可能被问到的

答不上来的问题，比答得漂亮的问题更能决定这场演示的结果

• 登记机关办证要一周，客户等不了怎么办？ 核查单只给事实和选项，先放还是等证是放款岗和审批人的决定——两个选项的金额影响都列在上面。
• 保证合同早于决议三天，有这么严重吗？ 按规程决议是担保的前提，顺序颠倒的合同效力存疑——标红是因为这个缺陷历史上被监管翻出来过。
• 能不能直接在信贷系统里改勾选状态？ 不能也不会——核查单是独立证据，系统的勾选该由谁勾还是由谁勾。

③ 能力沉淀（Skill / 提示词 / 预期输出 / 人工边界）

1. Skill 能力包

导入之后，同类任务会自动按这套规则走 —— 提示词才能写得那么短

批复条件落实核查 —— 已落实/形式资料/缺实质证据，三色核到底 · Skill

SKILL.md 主本 + references（输出骨架 / 判据 / 渲染脚本）· 符合 WorkBuddy Skill 规范

版本 v1.0

condition-fulfillment-check.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

• SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
• references/output_template.md 输出骨架（sheet 名 / 分区顺序 / 列头）+ 可直接运行的渲染脚本
• references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细，不会拖慢每次对话。

2. 原始素材

这些就是银行手上真实能拿到的东西 —— 格式不统一是常态，不是问题

📁PO-01 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 4 份

• 01_批复文书_LC-2026-恒信机械.pdf 贷审会 7-10 通过、7-14 下达的批复文书（含 8 项前提条件）
• 02_放款中心档案_放款前清点.xlsx 放款中心档案清点（脱敏）
• 03_受托支付对象_辰宇贸易_关联核查.xlsx 受托支付对象辰宇贸易与借款人的关联关系核查（脱敏）
• 04_保证合同与股东会决议_日期核对.docx 保证合同与股东会决议的日期顺序核对（脱敏）

怎么用

• 把素材全部拖进 WorkBuddy 对话框（不需要整理格式、不需要改文件名）
• 粘贴下方提示词发送
• 拿到正式件初稿 —— 签批栏留空，推荐意见留空，由你填

3. 提示词卡片

这笔贷款的批复和放款档案都在附件里，逐条核一下批复条件落实了没有。 注意区分受理凭证和办结凭证，别看到扫描件就算落实。 关联方那块重点看：受托支付的对象跟借款人、担保人有没有关系。 放不放、什么时候放，核查单给我，决定我来做。

为什么这么短就够了：凭证分类规则、三色判定口径、关联方比对逻辑都在能力包里。

换成你自己的业务：把素材换成你手上的真实文件即可。导入 Skill 之后，

该走几步、什么口径、什么情况必须拦住，Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

• 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说：什么事、什么文件、什么要求。不用讲究格式。
• 调用 Skill 补齐专业规则 —— 导入本页 Skill 后，流程、口径、硬规则 Agent 自己知道。
• 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮，把随口说的话补成更完整的表述。

分工：自然语言负责「这是什么事」，Skill 负责「该怎么做」，增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 3 份

• PO-01_批复条件落实核查单.xlsx 三色结论 · 红项含处置选项与金额影响 · 放款岗签字栏
• PO-01_凭证索引与缺口清单.xlsx 逐份凭证的档案位置与缺失项
• PO-01_关联方比对底稿.xlsx 受托支付对象/担保人与借款人的股权关系

Skill 里固化了什么：从历史里想起了本行踩过的坑该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单：批复文书（含前提条件清单）条款逐条拆解成可核对的凭证项放款中心档案（抵押登记受理凭证、保证合同、面签影像）逐份比对用的原始件不动产登记状态查询结果受理与办结的时间差是关键受托支付对象清单与购销合同支付对象与交易背景的关联核对

人工边界：核查结果只呈现事实（凭证在/不在/是受理件还是办结件），放不放款的指令永远是人下。不自动放行、不自动拦截系统流程，只生成核查单供放款岗签字。

升为客户真实案例还缺什么：客户当前真实输入文件（不要整理过的）岗位现行 SOP 与审批链（金额分档、谁签字）至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径（多少天算临期、多少金额算大额）

5. 同一角色下的其他场景

放款与贷后管理 · 产出即下一步输入

• PO-02 · 基于本行台账的贷后检查报告：数据自动填充，消灭只改日期的雷同报告

上下游串起来就是完整链路。每一步的产出都是下一步的输入，不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理，演示中的企业、人物与数据均为虚构，不代表任何客户的实际成效；痛点引用的公开来源已做脱敏处理。网页版由原资料转换，部分演示表格以原文形式展示。