FDE 落地手记 · 05
一个 AI 工具在自己的电脑上顺利运行，只是交付的开始。
交给同事之后，环境、账号、数据权限和操作习惯都会变化。有人修改了 Skill，有人更新了依赖，有人的登录状态失效，还有人需要一个原来没有考虑过的异常处理入口。
在这些情况下，FDE 需要把维护和恢复能力一起交付。下面围绕流程包、数据采集和企业数据访问，整理一套可以逐步采用的工程办法。
一、区分个人配置、业务规则与服务端约束
把全部逻辑放在一份可随意编辑的提示词里，很难保证多人使用时结果一致。
可以建立三个边界：
| 层次 | 内容 | 变更方式 |
|---|---|---|
| 个人配置 | 常用范围、表达风格、显示偏好 | 使用者在允许范围内调整 |
| 业务规则 | 指标定义、分摊公式、流程检查点 | 指定负责人确认，保留版本 |
| 服务端约束 | 身份、数据范围、敏感字段、操作权限 | 在接口及数据访问层执行 |
用户可以偏好简短报告，但不能通过修改提示词改变财务计算；可以指定自己的渠道，但不能仅凭自然语言获得其他部门的数据。
Skill 负责描述和组织任务，服务端负责执行不可绕过的约束。二者需要相互配合。
二、MCP 接通以后，仍然需要设计授权
MCP 提供工具发现和调用方式，具体身份与访问控制需要在实现中落实。
比较稳妥的一条调用链可以是：
确认当前用户身份
↓
解析用户可访问的业务范围
↓
校验工具、参数、字段和查询规模
↓
执行受控查询
↓
过滤结果并记录调用日志
对于经营查询，优先提供明确用途的只读能力，例如查询指定范围的日销售、读取已确认指标、查看数据新鲜度。数据库账号也应当具备对应的只读和范围限制，避免工具层与底层权限脱节。
限制返回行数有助于控制负载，却不能替代数据权限。审计还应当能回答谁在什么时候、通过哪个工具、访问了什么范围。
三、把流程版本与接口版本一起管理
一个流程包可以记录以下内容：
package: channel_review
version: 1.2.0
compatible_tool_api: '>=2.0,<3.0'
metric_contract: channel_contribution_v2
configuration:
editable: [preferred_channel, report_style]
protected: [metric_definition, permission_policy]
release:
sample_set: review-cases-202610
rollback_to: 1.1.3
这是一种管理结构示例。实际发布前，应验证目标客户端是否能识别这些配置，以及服务端是否真正实施受保护规则。
更新时可以先在小范围验证正常、边界和异常样本，再逐步推广。保留旧版本与对应配置，有助于出现问题后回退，也能解释不同时间生成的结果为何不同。
不建议让每台电脑各自维护一份无法追踪的“最新版”。允许本地试验时，也应标注它是试验版本，避免进入共同核算结果。
四、采集任务要设计状态，而不是只写一个定时器
一项采集任务至少需要区分：等待、运行中、成功、可重试失败、需要人工介入、停止。
登录过期、平台临时不可用、文件结构变化、数据校验失败，对应不同处理方式。认证失效通常需要重新授权；文件结构变化需要检查解析规则；网络暂时失败才可能适合有限次数的退避重试。
可以为每次执行记录：
任务标识、业务日期范围、尝试次数
开始与结束时间、来源文件、采集记录数
校验结果、入库批次、最后成功时间
失败类型、错误摘要、下一步处理人
技术上执行成功，并不意味着业务数据已完整取得。下载了一个空文件，或者只下载到部分店铺，也应被识别出来。
五、用幂等与补采保证恢复后不重复计算
同一文件被重复上传、任务失败后重跑、平台回补旧数据，都是常见情况。
可以用来源系统、来源业务键和事件版本识别记录，再根据具体来源选择更新或保留修订。对于日报快照，应避免把每天的存量重复当成新增事件。
任务执行层也可以使用锁或租约，减少两个相同任务同时运行；失败后从已确认的检查点恢复。数据更新完成后再切换可见批次，避免用户读到只写入一半的结果。
恢复操作应针对明确的业务日期和来源范围，而不是简单“再跑一次全部任务”。补采之后还要重新检查关联、汇总和受影响的历史指标。
六、监控要直接说明业务受到什么影响
一条“程序异常”的通知，只能说明有人需要排查。更有用的通知还包括：哪个渠道、什么日期的数据未更新、最后成功时间、当前看板是否仍在使用旧数据，以及下一步应由谁处理。
建议把以下状态放进统一运行视图：
- 数据新鲜度与来源覆盖情况；
- 任务成功率、失败类型和积压数量；
- 未匹配商品、未知渠道与重复记录；
- 查询耗时、模型调用失败和复核退回原因；
- 当前版本、维护人及最近一次恢复结果。
告警阈值应依据业务决策频率制定。月度结算与短周期投放，不需要完全相同的时效标准。重复告警还需要合并和升级，避免通知很多却无人处理。
七、给使用者一份能够实际执行的维护交接
交接材料至少应说明：正常结果在哪里看、缺数如何识别、什么情况可以重试、什么情况需要停下，以及联系谁。
同时演练几次恢复：登录失效、数据源中断、重复导入、规则升级和回退。演练时最好由非原开发者按说明操作，记录说明中缺失的步骤。
备份也需要验证恢复能力。文件存在、服务器有定时任务，都不能单独证明服务可以恢复。对关键数据和规则，应说明可接受的丢失范围以及预期恢复时间，并定期核实是否达到。
八、选择技术方案时，把维护成本一起算进去
接口、脚本和浏览器自动化，各有适用条件。可以优先使用稳定、授权明确的数据接口；只有导出页面可用时，也可以采用相应自动化，并配套监控与人工恢复入口。
选择依据应包括来源覆盖、成功率、变化频率、维护时间和失败后的业务影响。对一个已经稳定运行的环节，替换技术并不天然产生价值。
我对交付完成的要求，是让使用者可以识别结果是否可信，让维护者可以定位问题，让替代人员能够按说明恢复服务。持续做到这些，工具才能逐步承担日常业务责任。
