11.2 业务现场：先照顾情绪，再证明价值

概念

第一个场景最花时间的不是写 Prompt，也不是接接口，是和企业财务的业务侧把目标谈拢。他们已经被沟通成本、规则频繁变化、技术适配弱、上线周期长消耗了很久，FDE 得先接住这些情绪，再用一个不增加风险的 POC 证明事情能成。

现场痛点	FDE 的动作	得到的结果
沟通成本太高	把业务口径、材料样貌、拒单理由、补件要求翻成统一的字段、规则和样例	评审围绕样本和证据讨论，不用反复口头解释同一类问题
规则变化太快	规则从大段 Prompt 里拆出来，进规则中心和 Skill 版本，改动后用冻结样本回放	规则改动有版本、有影响面、有回归结果
技术适配能力弱	不动业务线上流程，先用 POC 串起材料采集、OCR / 全要素抽取、审核 Workflow 和结果对比	业务在自己熟悉的单据上看到 Agent 的边界，信任慢慢建立
项目上线周期长	先跑最小闭环，再补生产边界、质量指标、token 消耗和 ROI	从一次性大交付，变成可验证的小步放权

**💡 提示：**审核能力不足往往不是唯一痛点。业务还会暴露说明写得差、补件要求说不清、风险解释不统一——这些都能延展出生成、解释、辅助沟通的新需求。

步骤	做什么
01 痛点沟通	问对问题，明确业务目标、风险边界、证据条件和人工门禁
02 数据与 Ontology	搭业务骨架，汇总业务输入、附件、人工结论与 Agent 运行轨迹
03 冷启动 POC	切最小闭环，组合 Context、规则、Skill 与 Workflow
04 完整交付	守住生产边界，补齐接入、追踪、超时、回调和人工门禁
05 迭代闭环	反馈回流，用评测验证每次迭代是不是真的变好了
06 复用能力	留下方法论和通用模块，下一个场景能直接拿来用

**💡 提示：**把业务老师的经验"问出来"只是开始，要把它变成能运行、能评测、能回放、能回滚的东西。没有真实样本和发布门禁，Prompt 写得再漂亮也不算交付。