工作流原型的交付边界在赔付工单中模型若未参考企业的“例外情况处理 SOP”可能将包装破损等索赔误分类。人工纠偏经验若只留在口头沟通或 Excel 中也无法成为后续处理的规则。1. 为什么纯 Prompt 无法沉淀业务规则很多工程团队在落地 AI 业务流时习惯把规则写在 System Prompt 里。当业务场景越来越多Prompt 膨胀到了数千字。试着用简单的测试脚本模拟 500 次不同场景的工单分类python3 benchmark_tickets.py --prompt-version v3 --dataset test_tickets_500.json评测中应重点观察 Prompt 长度对指令遵循和边界条件的影响具体下降幅度须以本业务数据为准。若赔付标准变化还需要修改代码中的 Prompt 并重新发布规则维护成本会快速累积。人工纠偏的经验没法自动变成规则修改规则又极容易引发其他场景的回归故障。把 AI 当成一个不可靠的决定者不如把它设计成受控的状态机执行者。2. 状态机与经验反哺回路设计要把人工复盘的经验持续转化为系统规则必须把工作流解耦成三个独立模块结构化输入提取、确定性规则引擎校验、以及人工纠偏日志收集器。当工单进来时LLM 只负责从非结构化文本中提取结构化字段如损坏类型、货值、保险状态。提取出的数据交由确定性的规则引擎判断。一旦规则引擎无法决策或人工触发了重审人工修改的结果会被记录为一条 ADR架构与业务决策记录经过校验后自动合流进入规则库。这套设计确保了系统的下限由规则引擎保底而上限则通过人工纠偏不断把经验转化为具体规则。3. Python / FastAPI 业务工单与审计组件实现下面是在 Python/FastAPI 环境中实现的生产级服务代码。包含了 JSON Schema 强校验、规则引擎断言、以及人工纠偏日志的结构化落盘。import json import logging from typing import Dict, Any, Optional from pydantic import BaseModel, Field, ValidationError from fastapi import FastAPI, HTTPException, BackgroundTasks logging.basicConfig(levellogging.INFO) logger logging.getLogger(TicketAuditSystem) app FastAPI(titleTicket Audit and Rule Generator) # 1. 提取结果的强类型定义 class TicketExtraction(BaseModel): ticket_id: str Field(..., description工单唯一ID) damage_type: str Field(..., description损坏类型PACKAGING/PRODUCT/LOSS/FORCE_MAJEURE) declared_value: float Field(..., ge0, description申报金额) has_insurance: bool Field(..., description是否有保险) raw_reason: str Field(..., description用户原始诉求描述) class RuleDecision(BaseModel): action: str Field(..., description决策动作APPROVE / REJECT / ESCALATE) matched_rule_id: Optional[str] Field(None, description命中的规则ID) confidence: float Field(..., description置信度) class HumanCorrectionPayload(BaseModel): ticket_id: str corrected_action: str correction_reason: str operator_id: str # 2. 模拟动态规则库 class DynamicRuleEngine: def __init__(self): self.rules [ { rule_id: R001, damage_type: PACKAGING, max_value: 500.0, has_insurance: True, action: APPROVE }, { rule_id: R002, damage_type: FORCE_MAJEURE, action: REJECT } ] def evaluate(self, data: TicketExtraction) - RuleDecision: for rule in self.rules: if rule.get(damage_type) data.damage_type: if has_insurance in rule and rule[has_insurance] ! data.has_insurance: continue if max_value in rule and data.declared_value rule[max_value]: continue return RuleDecision(actionrule[action], matched_rule_idrule[rule_id], confidence1.0) # 未命中任何规则提升至人工处理 return RuleDecision(actionESCALATE, matched_rule_idNone, confidence0.0) def append_rule_from_correction(self, data: TicketExtraction, correction: HumanCorrectionPayload): new_rule_id fR_AUTO_{len(self.rules) 1} new_rule { rule_id: new_rule_id, damage_type: data.damage_type, has_insurance: data.has_insurance, action: correction.corrected_action, created_by: fCORRECTION_{correction.operator_id} } self.rules.append(new_rule) logger.info(f动态成功追加新规则: {json.dumps(new_rule, ensure_asciiFalse)}) rule_engine DynamicRuleEngine() # 本地内存缓存模拟持久化存储 ticket_db: Dict[str, TicketExtraction] {} app.post(/api/v1/tickets/process) async def process_ticket(extraction: TicketExtraction): try: # 校验数据并持久化存入 ticket_db[extraction.ticket_id] extraction # 确定性规则引擎评判 decision rule_engine.evaluate(extraction) return { status: SUCCESS, data: extraction, decision: decision } except ValidationError as e: logger.error(f字段校验失败: {e.json()}) raise HTTPException(status_code422, detailf结构化数据不符合业务规范: {e.errors()}) except Exception as e: logger.error(f处理工单异常: {str(e)}) raise HTTPException(status_code500, detail工单处理服务内部错误) app.post(/api/v1/tickets/correct) async def correct_ticket(payload: HumanCorrectionPayload, background_tasks: BackgroundTasks): ticket_data ticket_db.get(payload.ticket_id) if not ticket_data: raise HTTPException(status_code404, detail未找到指定的原始工单) logger.warning(f触发人工纠偏工单ID {payload.ticket_id}, 人工操作动作 {payload.corrected_action}) # 异步落盘并反哺规则库 background_tasks.add_task( rule_engine.append_rule_from_correction, ticket_data, payload ) return { status: CORRECTION_RECORDED, message: 人工纠偏经验已记录规则库反哺中, ticket_id: payload.ticket_id }4. 落地后的改变在某供应链客户的物流系统中这套规则反哺机制上线运行了一个月。数据是最直接的体现人工介入率按周统计并结合工单复杂度解释变化规则库中由人工纠偏自动提炼生成的确定性规则增加了 47 条覆盖了包装损毁、第三方快递转运延迟等绝大部分复杂边界业务团队再也不用频繁找开发调整 Prompt只需要在后台确认人工审理的结论系统就会自动闭环。技术赋能传统业务关键从来不是展示模型的聊天能力而是把技术做成低调的基建把业务团队的经验真正沉淀下来。