文旅行业FDE交付指南（完整件 v2.0）

> 文旅行业 Skill 完整件 v2.0。核心引擎 scripts/engine.py（纯标准库）已通过 36 项验收自检（含文件级发布纪律检查）。
> 版权与署名：见 NOTICE.md；产出物末尾自动附带 IP 印章。

定位

FDE（Forward Deployment Engineer，交付工程师）不是"懂大模型的售前"，而是对场景诊断、代码交付、评测、上线运营、客户采纳和能力复用共同负责的人。 本 Skill 把这条能力链落到文化创意与文旅行业（景区 / 文博场馆 / 旅行社 / 酒店 / 文创公司 / 文旅局），提供一套可执行的七步交付流程与配套模板：输入一家文旅客户的真实痛点，输出从问题合同到复用资产的完整交付方案。

核心洞察：文旅 AI 项目失败，很少因为模型不行，大多死在"三通一留"上——

1. 流程通：能力没有嵌进游客/员工的真实工作流（买了系统没人用）；
2. 数据通：票务、OTA、闸机、CRM 接口封闭、数据标准不一，AI 拿不到真数据；
3. 人工通：数字化基础弱的客户不会用、不敢用、不愿改旧流程；
4. 经验留：每个客户都从零写 Prompt、接接口、做评测，项目结束经验清零。

FDE 的职责就是逐个打通这四关，并把第四关的沉淀变成下一个客户的起点。

行业背景（为什么文旅需要 FDE）

• 2026 年中国智慧文旅市场规模突破 14.5 万亿元，AI 大模型从"辅助工具"升级为行业"核心引擎"，行业逻辑从"建系统"走向"建生态"。
• 真实落地已验证价值：AI 游西江（智能导览 / AI 证件核验 / 多语言，投诉响应 48h→4h，满意度 98%，智能体用户 25 万+）；腾讯文旅智能导游承接 80% 标准化咨询；客流预测提前 72 小时预判峰值，覆盖 200+ 5A 景区；"黄小西"已服务 1700+ 酒店、60 家景区。
• 同时存在真实的结构性痛点，正是 FDE 的用武之地：
• 中小文旅企业定制化 AI 成本高、易掉队 → 需要模板化、可复用的交付；
• 票务/OTA/酒店等接口封闭、数据标准不一 → 需要适配层与连接器工程；
• 跨景区、跨业态数据共享机制缺失 → 需要能力复用与标准化沉淀；
• 旅游淡旺季与节假日峰值流量 → 需要可灰度、可回滚的生产纪律。

适用对象

• 面向文旅客户的 AI 交付工程师（FDE / 解决方案工程师 / 行业顾问）
• 文旅行业数字化服务商、智慧文旅方案团队的交付负责人
• 文旅企业（景区/文博/酒店/旅行社/文创）内部 AI 落地负责人
• 希望把文旅行业 AI 项目做"流程化、可复制"的团队

七步交付闭环（FDE 核心流程）

本 Skill 将 FDE 的六大能力板块组织为一条可执行的交付链：

> 方法论出处：《FDE 工程能力框架》——AI FDE 对"场景诊断、代码交付、评测、上线运营、客户采纳、能力复用"共同负责；行业演进从"能跑的 Demo"走向"可验收、可回滚、可运营、可交接的企业 AI 部署"。

文旅五大主体 × 核心 AI 场景

场景选择铁律（对应 FDE 的"懂 Agent 更要懂边界"）：优先选高频、低错误成本、可量化的场景起步；涉及资金（退票退款）、合规（票价政策/实名制/未成年人保护）、不可逆操作（核销/发放补贴）的环节，必须保留人工批准、复核与最终责任。

文旅 FDE 六板斧（交付要点）

1. 场景诊断：先签"问题合同"，再写代码

文旅客户常把抱怨说成"游客嫌讲解干巴巴""投诉处理慢""文案写不过来"。FDE 要追问并落到合同：

• 谁、在什么条件下、完成什么任务？（游客/员工/管理者视角分别列）
• 输入输出是什么？错误代价多大？（讲错史实 = 致命；推荐错餐厅 = 可容忍）
• 哪些步骤允许自动执行？哪些节点必须人批？（涉及钱/证/不可逆操作一律留人）
• 旺季峰值流量约束是什么？（节假日并发、闸机吞吐）
• 上线后用什么指标证明有效？
• 明确不做清单：超出范围的需求写进合同，避免无限定制。

产出：一份业务、技术、交付三方共同验收的问题合同（见 references/03-问题合同模板.md）。

2. 代码交付：接脏系统，是文旅 FDE 的日常

• 文旅真实系统：票务系统、OTA 渠道（携程/美团/飞猪）、闸机/门禁、CRM、公众号/小程序、支付、地图 POI、对讲/广播系统。接口封闭、字段乱、数据标准不一是常态。
• 必做工程动作：幂等（重复购票/重复预约不产生第二单）、超时重试（票务高峰 5xx 是常态）、审计日志（退款/核销全留痕）、人工接管（前端提供确认与异常兜底）、Trace（模型→工具→数据库→业务动作串起来）。
• 内容侧（讲解稿/文案/宣传）：生成后必须接合规扫描（广告法极限词、票价政策、民族宗教表述）。
• 只搭 Demo 不算交付：能解释鉴权、日志、回滚、故障归属，才算到生产门槛。

3. 评测验证：Evals 是交付基础设施，不是加分项

• 离线评测集（按场景建任务集+成功标准+评分器）：
• 讲解/导览：事实准确性（史实错误零容忍）、时长与语速、个性化程度、多语言正确性；
• 客服投诉：致歉→归因→补救→引导四段完整性、承诺不超权限（不能乱承诺赔偿）、合规；
• 文案：违禁词、平台规则、广告法、品牌一致性；
• 客流预测：准确率、提前量（如 72h）、峰值误差；
• 预约/购票流程：成功率、重复预订率、支付失败兜底。
• 线上监控：成功率、延迟、成本、人工接管率、失败分布；版本回归：一次优化不得破坏旧能力（如新增讲解风格不能破坏事实准确性）。
• 交付时能回答：用哪组任务测的、成功如何定义、波动是否显著、失败集中在哪里、新版本有没有回归。

4. 上线运营：上线不是句号，是真实数据的开始

• 核心三指标：采纳率（游客/员工是否真用）、任务成功率（业务结果是否达成）、人工干预率（离自主还有多远）。
• 文旅特有指标：游客满意度、投诉响应时长（行业案例：48h→4h）、二次消费/文创转化、旺季峰值可用性。
• 灰度纪律：先开一个场景（如仅导览）→ 再开一个景区/一个门店 → 全量；节假日前一周冻结发布，峰值日只读不更。
• 回滚方案：配置开关、版本快照、降级到人工兜底预案，上线前必须演练。

5. 客户采纳：让文旅客户"真正用起来"

• 文旅客户特征：中小景区/文创工作室数字化基础弱；决策链长（文旅局/管委会/景区运营多方）；一线员工年龄结构偏传统，怕 AI 抢饭碗。
• FDE 动作：驻场培训（把"怎么用"做成 5 分钟上手卡）、陪跑期答疑、帮客户清洗历史数据、兜底边缘 case（方言、老年游客、特殊证件）。
• 边界：对客户结果负责 ≠ 无限接定制。需求必须可验收、生产责任必须有 Owner、长期维护必须有交接、超范围工作重新评估价值与成本。

6. 能力复用：一个客户的终点，是下一个客户的起点

可复用资产不止代码，还包括：

• 场景诊断模板与问题合同（景区/文博/酒店/旅行社/文创 五套）；
• 标准连接器：票务/OTA/公众号/支付适配层；
• 文旅评测集与评分规则（讲解/投诉/文案/预测/预约）；
• 合规红线库：广告法极限词、票价政策、实名制、未成年人保护、个人信息保护；
• 上线清单、灰度计划、回滚方案、培训手册；
• 从现场问题到产品需求（Roadmap）的证据链。

复用越好，FDE 越不像"人肉接口"，越接近平台能力与组织学习系统。

工作流（命令行）

# 1) 场景诊断：输入客户主体与痛点 → 输出问题合同
python scripts/engine.py diagnose --client '{"segment":"景区","name":"某4A景区","pain":"投诉处理慢、讲解质量不稳定","seasonal":"旺季客流峰值8万人/日"}'

# 2) 方案设计：基于问题合同 → 场景-能力映射 + 评测指标
python scripts/engine.py plan --contract '<diagnose 输出的问题合同 JSON>'

# 3) 评测集：按场景生成任务集与评分规则
python scripts/engine.py evals --scenario 客服投诉
python scripts/engine.py evals --scenario 讲解导览

# 4) 上线清单 + 灰度/回滚检查
python scripts/engine.py go-live --contract '<问题合同 JSON>'

# 5) 标杆案例库（客户说服/ROI 对标）
python scripts/engine.py case --keyword 投诉
python scripts/engine.py case

# 6) 复用资产盘点
python scripts/engine.py assets

# 7) 全流程一键（诊断→方案→评测→上线→复用）
python scripts/engine.py run --client '<客户 JSON>'

# 8) 自检与档案
python scripts/engine.py selftest
python scripts/engine.py profile

# 程序化消费：任意命令加 --json 只输出 JSON
python scripts/engine.py diagnose --client '<客户 JSON>' --json

深度感知数据沉淀

• 运行时生成 assets/tourism-profile.json（服务过的客户主体类型/常用场景/行业偏好/高频痛点），越用越懂文旅行业交付习惯。
• 档案 schema 见 assets/tourism-profile-schema.json；打包发布时排除运行时档案。

A2A 接口

• 事件：tourism.fde.delivery（version 2.0.0，payload 含 client_segment/phase/contract_id/evals_ready/go_live_ready）
• 供交付流程上下游智能体订阅：诊断完自动触发方案设计、评测集就绪通知上线编排等。

验收标准（selftest 36 项）

文件级发布纪律（9 项）：SKILL.md/README.md/NOTICE.md/schema 存在 / license 收紧为 CC BY-NC-SA / SKILL.md 声明 2.0.0 / engine banner 版权注释（第 3 行）/ NOTICE 引用印章义务 / 打包排除运行时档案（无 tourism-profile.json 残留）

功能级检查（27 项）：问题合同五要素+验收口径 / 五类主体识别 / 场景能力映射 / 人工边界红线（资金/合规/不可逆留人）/ 讲解评测含事实准确性 / 投诉评测四段完整性 / 文案评测含违禁词 / 客流预测评测含准确率 / 上线清单含灰度+回滚 / 文旅特有指标（满意度/投诉响应/二次消费）/ 采纳提升三件套 / 复用资产六类齐备 / 合规红线库含广告法+实名制 / 案例库关键词命中且全量 ≥4 / 深度感知演化 / A2A 事件常量与版本 2.0.0 / 产出物携带 A2A 事件 / 产出物可 JSON 序列化（--json 兼容）/ 印章在 rendered 末行 / 版本号统一 2.0.0

变更记录（Changelog）

• v2.0.0（2026-08-13）：新增 case 标杆案例库命令（AI游西江/腾讯文旅/黄小西/长安十二时辰，客户说服与 ROI 对标）；问题合同增加"验收口径"字段（评测前置）；上线清单增加"采纳提升三件套"；新增 --json 程序化输出（修复子命令后置传参 bug）；selftest 升级为 36 项并内建文件级发布纪律检查（修复 v1.0 中 SKILL.md 自检项数与实际不符、run 命令污染深度感知档案、A2A 恒真假检查三个缺陷）；版本号全局统一 2.0.0。
• v1.0.0（2026-08-13）：首版，FDE 七步交付闭环 + 五大主体场景映射 + 五套评测集 + 上线清单 + 复用资产。

交付成熟度自评（对应 FDE 五类作品证据）

交付完一个文旅项目，FDE 应能拿出五类可检查的证据：

1. 一份场景诊断：文旅客户流程、痛点、基线、目标、边界、不做清单；
2. 一个可运行系统：真实票务/OTA/公众号对接、权限、人工接管，不是聊天页面；
3. 一套评测证据：文旅任务集、评分规则、版本对比、失败分类；
4. 一份生产方案：日志、监控、成本、灰度、回滚、安全责任；
5. 一个复用资产：文旅连接器、模板、评测集或方法论。

五类证据串成一个闭环，交付即证明——模型能力已变成稳定业务结果。