内部审批文件自动生成草稿:使用Dify练习结构化输出和提示设计
简介
在日本企业中,审批文件是构成决策过程的核心文件。实施新工具、申请预算、与外部供应商签订合同——所有重要决策都必须通过通告批准。然而,创建批准文件需要相当长的时间。一份审批文件耗时几个小时到一整天的情况并不少见,包括整理背景、计算成本效益、识别风险、写下与相关部门协调的事项。
在本文中,我们将解释一个系统的设计,该系统使用 Dify 以结构化格式自动生成审批文件草稿,然后由人工检查和修改,然后放入审批流程。重点不是“写得好”,而是始终如一地生成与组织批准的格式一致且没有间隙的结构化输出。
背景和问题
创建ringi文档的实际问题
| 作业 | 详情 |
|---|---|
| 准备工作所需的工时量 | 事业部经理日常工作中写审批文件 |
| 格式不一致 | 各部门格式不同,增加审稿人负担 |
| 缺少必需的物品 | 提交的意见书通常是在没有预算基础或风险评估的情况下发送的 |
| 缺乏定量信息 | 投资回报率和投资回收期不明确进入审批流程 |
| 审批文件拥堵 | 审批文件准备拖延,项目开工延误 |
为什么是“自动草稿”而不是“自动生成”?
批准文件是组织内部的正式决策文件,最终责任由申请人和批准人承担。由于以下原因,原样提交人工智能生成的内容是不合适的。
- 数字准确性:人工智能不应猜测预算金额、投资回报率或投资回收期。
- 特定于组织的背景:人工智能无法确定过去的情况或内部政治考虑
- 责任:申请人对批准文件的内容负责。
因此,人工智能的作用将仅限于“安排结构、生成草稿、澄清缺失的项目”,最终的设计将由人类完成。
整体架构
flowchart TD
A[申請者: 要件を入力] --> B[入力情報の構造化ノード]
B --> C[稟議タイプ判定]
C --> D[テンプレート選択]
D --> E[LLM ドラフト生成]
E --> F[不足項目チェック]
F --> G{不足項目あり?}
G -->|Yes| H[不足項目リスト提示<br>+ 暫定ドラフト出力]
G -->|No| I[完全ドラフト出力]
H --> J[Human-in-the-Loop:<br>申請者が確認・補完]
I --> J
J --> K[最終稟議書出力]
K --> L[承認ワークフロー連携<br>API / メール / Slack]
审批文件结构化格式设计
标准字段定义
生成审批文件草稿最重要的是输出格式的稳定性。它基于固定字段的结构化输出而不是长的自然句子。
{
"ringi_title": "Dify Enterprise 版 導入に関する稟議",
"applicant": {
"name": "",
"department": "",
"position": "",
"date": "2026-04-12"
},
"background": {
"current_situation": "現状の課題を記述",
"trigger": "稟議提出のきっかけ"
},
"purpose": "本稟議の目的を1-2文で記述",
"proposal": {
"overview": "提案の概要",
"scope": "適用範囲・対象部門",
"timeline": "想定スケジュール"
},
"cost": {
"initial_cost": "初期費用(税込)",
"running_cost": "月額/年額ランニングコスト",
"total_budget": "稟議申請金額",
"budget_source": "予算科目",
"payment_terms": "支払条件"
},
"expected_benefits": {
"quantitative": "定量的な効果(工数削減○時間/月 等)",
"qualitative": "定性的な効果"
},
"roi": {
"payback_period": "投資回収期間",
"calculation_basis": "算出根拠"
},
"risks": [
{
"risk": "リスク項目",
"probability": "高/中/低",
"impact": "高/中/低",
"mitigation": "対策"
}
],
"alternatives": [
{
"option": "代替案",
"pros": "メリット",
"cons": "デメリット",
"reason_not_selected": "不採用理由"
}
],
"approval_items": "承認を求める事項を明確に記述",
"attachments": ["見積書", "製品資料", "PoC報告書"],
"compliance_check": {
"personal_data": "個人情報の取扱い有無",
"security_review": "セキュリティ審査の要否",
"legal_review": "法務確認の要否"
},
"missing_fields": ["未入力または情報不足のフィールド一覧"]
}
按审批类型进行字段调整
| 审批类型 | 附加字段 | 可选字段 |
|---|---|---|
| SaaS/工具介绍 | 安全检查表、数据存储位置 | - |
| 外包/外包 | 承包商信息、合同形式、验收条件 | 投资回报率(如果难以计算) |
| 人才招聘 | 职位类型、职级、期望年薪范围 | 替代品比较 |
| 资本投资 | 折旧期、租赁与购买比较 | - |
| 活动/商务旅行 | 目的、参与者、预期结果 | 投资回收期 |
提示设计:按版本比较
###版本1:自由生成类型
System Prompt:
あなたは社内稟議書の作成をサポートするアシスタントです。
ユーザーの入力に基づいて稟議書のドラフトを作成してください。
结果趋势:
- 文本易于阅读,但字段不稳定
- 必需的项目(预算、风险等)可能会被遗漏。
- 它往往采用无法直接导入审批系统或表格的格式。
版本 2:模板绑定类型
System Prompt:
あなたは社内稟議書の作成支援アシスタントです。
以下のフィールドに従って、構造化された稟議書ドラフトを JSON 形式で出力してください。
必須フィールド:
- ringi_title: 稟議件名
- background: 背景・現状の課題
- purpose: 目的
- proposal: 提案概要
- cost: コスト(初期費用、ランニングコスト、合計)
- expected_benefits: 期待効果(定量・定性)
- risks: リスクと対策
- approval_items: 承認を求める事項
すべてのフィールドを必ず出力してください。
情報が不足している場合は、そのフィールドに "【要入力】" と記載してください。
结果趋势:
- 显着改善现场覆盖范围
- 但是,如果“[需要输入]”过多,草案的实用性就会降低。
- 如果输入信息较少,有时会通过猜测来填写信息。
###版本3:结构化+漏检+安全约束型(推荐)
System Prompt:
あなたは社内稟議書の整理・構造化アシスタントです。
以下のルールに厳密に従ってください。
【役割の定義】
- あなたは稟議書の「整理者」であり、「意思決定者」ではありません
- 入力情報に基づいてドラフトを構造化する役割のみを担います
【出力ルール】
1. 指定された JSON フォーマットで出力すること
2. 入力情報に含まれない数値(予算額、ROI、期間等)は絶対に推測・捏造しないこと
3. 情報が不足しているフィールドは "【要確認】" と明記すること
4. missing_fields に不足項目を一覧として出力すること
5. 金額には必ず税込/税抜を明記すること
6. 根拠のない効果の誇張は行わないこと
【フォーマット】
{上記の JSON フォーマットを挿入}
【重要な禁止事項】
- 予算額の推測禁止
- ROI の捏造禁止
- 投資回収期間の推測禁止
- 存在しない比較データの生成禁止
结果趋势:
- 现场覆盖范围和准确性之间的最佳平衡
- 缺失的项目被清楚地标明,因此申请人需要填写的内容一目了然。
- 显着降低制造风险
设计输入信息
为什么自由文本输入不够
如果您只是输入自由文本,例如“我想介绍 Dify”。如果创建批准文件,草稿的质量就会很低。通过需要最少量的结构化输入,可以显着提高输出质量。
推荐的输入形式
在 Dify Workflow 的起始节点中定义以下输入变量。
| 变量名 | 类型 | 必填 | 描述 |
|---|---|---|---|
request_summary | 文字 | 是的 | 您想申请什么(自由文本) |
department | 选择 | 是的 | 应用部 |
budget_range | 选择 | 没有 | 大致预算范围(~500,000/~2,000,000/~5,000,000/超过 5,000,000) |
urgency | 选择 | 没有 | 紧急程度(正常/紧急/紧急) |
target_start_date | 日期 | 没有 | 期望的开始日期 |
related_documents | 文件 | 没有 | 估算、建议等的附件 |
additional_context | 文字 | 没有 | 其他信息(过去的历史、相关批准等) |
从附件中提取信息
当附加报价或提案时,Dify的VLM/参数提取节点用于自动提取金额、供应商名称、合同条款等,并将其反映在草稿审批文件中。
flowchart LR
A[見積書PDF] --> B[VLM / テキスト抽出]
B --> C[パラメータ抽出ノード]
C --> D["金額: ¥3,600,000<br>ベンダー: ○○株式会社<br>期間: 12ヶ月"]
D --> E[稟議書ドラフトに反映]
人在环设计
需要人工确认的情况
| 触发条件 | 原因 |
|---|---|
| 预算字段未填写 | 无金额的审批文件无法提交审批流程 |
| 风险评估为空白 | 不审查风险就审批是组织控制的问题 |
| 个人信息、法律事务、安全涉入旗帜 | 需要专门部门事先确认 |
| 高价值案例(超出阈值) | 根据审批机关要求升级 |
| 效果描述被AI判定“证据不足” | 防止高估预期效果 |
确认流程设计
Dify Human-in-the-Loop ノードの表示例:
━━━━━━━━━━━━━━━━━━━━━━
稟議書ドラフト: 確認をお願いします
━━━━━━━━━━━━━━━━━━━━━━
■ 件名: Dify Enterprise 版 導入に関する稟議
■ 不足項目:
⚠ 初期費用が未入力です
⚠ 投資回収期間の算出根拠がありません
⚠ セキュリティ審査の要否が未回答です
■ ドラフト内容:
[JSON / Markdown 形式のドラフトを表示]
■ アクション:
[承認して次へ] [修正して再生成]
━━━━━━━━━━━━━━━━━━━━━━
与下游系统的合作
连接到审批工作流程
审批文件草案最终确定后,使用 Dify Workflow 中的 HTTP 请求节点 将其链接到公司的审批系统。
| 合作伙伴 | 方法 | 笔记 |
|---|---|---|
| 工作流程审批系统(ServiceNow等) | 休息 API | 按原样发布 JSON |
| 谷歌表单 | 通过 Google Apps 脚本 | 映射到表单字段 |
| 松弛 | 网络钩子 | 发送批准请求通知 |
| 电子邮件 | SMTP/SendGrid API | 将包含草稿的电子邮件发送给审批者 |
| 通通 | 休息 API | 在应用程序中注册为记录 |
API调用示例(kintone联动)
curl -X POST 'https://{subdomain}.cybozu.com/k/v1/record.json' \
-H 'X-Cybozu-API-Token: {api_token}' \
-H 'Content-Type: application/json' \
-d '{
"app": 123,
"record": {
"稟議件名": {"value": "Dify Enterprise 版 導入"},
"申請部門": {"value": "情報システム部"},
"申請金額": {"value": "3600000"},
"ステータス": {"value": "ドラフト確認済み"}
}
}'
实施最佳实践
要做的事情
- 首先确定输出格式 — 在提示之前定义需要哪些 JSON 字段
- 显式输出缺失项 — 定义
missing_fields为必填字段 - 按审批类型切换提示 — SaaS实施和人员招聘所需项目不同
- 在金额字段插入安全约束 — 在提示中明确声明不允许猜测。
- 必须包括人机交互 — 不允许完全自动化提交
不该做的事情
- 只需“写审批文件”即可自由文本输入操作 — 输入的结构决定输出的质量
- 让人工智能估算预算金额和投资回报率 — 会破坏审批者的信任并破坏对整个系统的信任。
- 对所有审批类型应用相同的模板 — 需要按类型进行优化
- 以长自然句子输出 — 无法连接到下游系统
实施步骤
| 相 | 期间 | 内容 |
|---|---|---|
| 第一阶段 | 1-2 周 | PoC 仅限于 SaaS 实施批准。使用固定模板生成草稿。 |
| 第二阶段 | 2-4 周 | 扩大审批类型(外包/资本投资)。添加了从附件中自动提取的功能。 |
| 第三阶段 | 1-2个月 | API与审批系统集成。人在环的全面运作。 |
| 第四阶段 | 继续 | 根据使用历史改进提示。在知识库中积累过去批准的批准,以提高文本的质量。 |
总结
自动生成内部审批文件草稿最重要的不是“写得好”,而是按照组织批准的格式可靠地生成结构化输出并澄清缺失的信息。
通过使用Dify的Workflow,您可以无需代码构建一系列流程,包括输入结构化→类型确定→模板选择→草稿生成→缺陷检测→人工确认→系统联动。特别是,通过采用第3版(结构化+缺陷检测+安全约束式)的提示设计,可以大幅减少申请人的准备时间,同时降低AI造数的风险。
审批文件是日本企业决策的“界面”,其质量直接关系到组织决策的速度。使用人工智能生成结构化草稿是标准化和加速该界面的有效方法。