3.5 KiB
3.5 KiB
规则形成生命周期
1. 定位
规则不是凭空写出来的。
它应来自：
- 制度文档。
- 历史审批。
- 风险案例。
- OCR 识别结果。
- MCP 验真结果。
- 用户反馈。
- Hermes 分析。
2. 总体闭环
制度文档 / 历史审批 / 风险案例 / 用户反馈
↓
Hermes 分析
↓
规则候选
↓
人工审核
↓
规则 .md
↓
测试样例
↓
版本发布
↓
规则执行
↓
命中反馈
↓
规则优化
3. 规则候选结构
{
"candidate_id": "",
"source_type": "policy_document",
"domain": "reimbursement",
"scenario": "invoice_validation",
"risk_signal": "duplicate_invoice",
"suggested_rule_name": "重复报销识别规则",
"rule_markdown_draft": "",
"evidence": [],
"confidence": 0.86,
"created_by": "hermes"
}
补充约束：
rule_markdown_draft不能是任意自由文本，必须符合固定模板。- 规则候选应同时携带机器可读 JSON 草稿，例如
runtime_rule。 - JSON 草稿只能从受控模板族中选择，不允许 Hermes 自创字段结构后直接进入规则中心。
4. 规则 Markdown 推荐结构
# 规则名称
## 目标
## 适用范围
## 输入字段
## 判断规则
## 输出
## 测试样例
## 管理员备注
推荐再补一段模板元信息：
## 模板信息
- 模板键：`travel_standard_v1`
- 来源文档：公司支出管理办法（2024）
- Hermes 置信度：0.86
- 审核人：张三
4.1 规则 JSON 推荐结构
规则中心不应只有 Markdown。
应同时提供可执行 JSON 编辑区，至少支持：
{
"kind": "policy_rule_draft",
"version": 1,
"template_key": "travel_standard_v1",
"rule_name": "差旅住宿标准草稿规则",
"scenario": "travel_reimbursement",
"review_required": true,
"conditions": {},
"actions": {},
"source_document_name": "公司支出管理办法（2024）"
}
治理要求：
- Markdown 负责给人看。
- JSON 负责给运行时和规则引擎看。
- 两者必须成对维护，不能只改其中一份。
- JSON 变更也必须走版本和审核。
4.2 模板族约束
Hermes 只能从白名单模板中选，不允许自由生成任意规则结构。
第一版建议模板：
travel_standard_v1
expense_amount_limit_v1
attachment_requirement_v1
general_policy_v1
如果制度条款不适合自动规则化：
- 允许只生成
knowledge_candidate - 或只生成
general_policy_v1草稿并要求人工补齐 - 不能为了“有结果”而编造可执行规则
5. 审核要求
规则上线必须满足：
- 有审核人。
- 有版本。
- 有测试样例。
- 有来源依据。
- 有回滚方案。
补充：
- Hermes 生成规则默认只能是
draft。 - Hermes 不能直接覆盖当前
active线上规则。 - Hermes 如发现制度更新，应优先生成新的候选或草稿版本，仍需人工审核后再上线。
6. 规则执行反馈
每次规则运行应记录：
rule_id
rule_version
input_snapshot
hit_result
risk_level
operator_feedback
false_positive
false_negative
7. 规则优化来源
误报反馈
漏报反馈
审批人修改意见
Hermes 每日复盘
制度文档更新
MCP 新字段可用
8. 开发阶段建议
Step 1: 规则 .md 编辑和版本
Step 2: 规则审核上线
Step 3: 规则运行日志
Step 4: 人工反馈误报/漏报
Step 5: Hermes 生成规则候选
Step 6: 规则候选审核
Step 7: 规则测试样例管理
Step 8: 规则质量看板