FDE 落地手记 · 06
AI 项目最容易被展示出来的成果，是一段流畅回答、一张漂亮页面，或者一次顺利完成的演示。
进入实际工作以后，还需要回答另外一些问题：结果是否被接受，使用者是否愿意继续用，维护成本是否可控，以及业务是否因此发生了可以解释的变化。
我希望用一套分层验收办法，把这些问题放进交付过程。它既适用于经营分析，也适用于知识助手、内容生产和内部工作流。
一、把验收分成四层
| 层次 | 核心问题 | 可以检查的证据 |
|---|---|---|
| 技术可运行 | 在约定环境中能否完成任务？ | 输入校验、结果生成、失败与恢复记录 |
| 业务可接受 | 交付物是否满足业务要求？ | 样本核对、复核意见、退回与修改原因 |
| 持续被采用 | 使用者是否在真实任务中继续使用？ | 适用任务中的使用记录、替代流程变化 |
| 价值可验证 | 效率、质量或风险是否改善？ | 基线、可比任务、复核耗时和维护投入 |
某一层通过，不能自动推导出下一层。技术验收完成后，可以进入业务试用；业务接受了一个样本，也仍需要观察真实使用。
这种分层让项目更容易讨论阶段成果，也能避免把尚未发生的收益提前写成结论。
二、在上线前记录原来的工作方式
没有基线，很难知道工具带来了什么改变。
可以先选择一类边界清楚的任务，记录正常、复杂和异常样本：任务规模、原始输入、完成时间、人工核对步骤、错误类型、返工次数和最终接受情况。
例如经营复盘，需要把找数据、核对口径、计算、解释异常和整理结果的时间分开；详情页策划则需要区分资料整理、策略修改、线稿修改和最终视觉制作。
数据应尽量来自实际任务记录。让使用者回忆“以前大概花多久”可以作为访谈信息，但不能直接等同于可靠测量。
三、同时衡量完成质量与全部投入
可以采用几个容易解释的指标：
一次验收通过率
= 无需实质性返工的已接受任务数 / 已完成验收的任务数
任务完成率
= 达到业务完成标准的任务数 / 纳入试用的适用任务数
每份合格产物的人力投入
= 输入准备、运行协助、复核、修改和人工恢复的总时间
/ 最终被接受的产物数
这些定义需要与业务一起确认。例如，拼写修正是否算实质性返工，任务取消是否应排除，跨天等待应如何记录。
还要单独统计模型与服务成本、维护时间，以及无法接受的高风险错误。整体通过率较高，不能掩盖关键业务错误。
平均值之外，也应观察复杂任务和耗时较长的尾部样本。一个流程在常规样本上很快，却让异常任务更难处理，可能只是把负担转移了位置。
四、采用率的分母应当是适用机会
登录人数和调用次数能够描述活动量，却不容易解释真实采用。
月度结算一个月只运行一次，可能已经覆盖全部任务；一个聊天助手每天被问很多次，也可能因为回答始终没有解决问题。
更有用的做法是定义适用机会。例如：本月需要生成的渠道复盘中，有多少使用了新流程；已生成的策划中，有多少进入后续制作；可由知识助手处理的问题中，有多少得到接受并结束。
同时访谈未使用者，区分不会用、权限受限、结果不合适、习惯未迁移和任务本身不适用。不同原因需要培训、产品调整或重新选择场景。
五、设计能够比较的试用，而不急着归因
如果样本和条件允许，可以对相近任务进行交替使用或分组试用，保持任务复杂度、输入质量和验收标准尽量一致。
只适合小规模试用时，也可以记录同类任务的前后变化，但应说明期间是否更换了人员、资料、商品或业务规则。新品、大促和组织调整，都可能影响结果。
对于内容生产，出图更快与销售提升之间还隔着选品、创意、投放和流量等因素。可以先验证制作效率、采用率和修改负担，再设计业务效果评估。
不能仅凭一次成功案例，把全部业务变化归因于 AI。项目记录应保留样本范围、观察周期和影响解释的其他因素。
六、让异常从提示走到处理完成
经营看板出现红色提示，只完成了识别的一步。后续流程可以是：
发现异常 → 核实数据 → 分派负责人 → 记录处理动作
→ 观察后续变化 → 关闭、继续跟进或重新开启
一条异常记录可以包含指标、时间、范围、来源、原因判断、负责人、处理期限和关闭依据。
如果后来发现异常来自数据缺失，应修正数据和告警规则；如果来自真实业务变化，应保留处理动作与后续结果。二者需要不同的关闭理由。
这类记录能帮助 FDE 发现流程里真正卡住的位置：是系统没找到问题，还是业务没有人接，或者采取动作后没有重新观察。
七、AI 评分案例说明了证据与自述的区别
绩效场景中，如果模型主要依据员工填写的完成说明判断，夸大描述或“已获认可”一类文字，就可能影响结果。
更合理的设计是把材料分成三类：
- 可核验事实：任务状态、交付物、经营数据和正式审批记录；
- 规则计算结果：按照已确认考核规则计算的部分；
- 待判断材料：工作说明、上下文、困难和主观评价。
AI 可以整理证据、指出缺项、检查说明与事实的矛盾，并提出供复核的建议。不能把员工在说明中声称的“主管认可”，直接当成实际审批；提交材料中的文字也不能获得修改评分规则的权力。
最终责任应由明确的授权人员承担，并保留复核和更正路径。这样的设计才能讨论质量与效率，避免用一个漂亮分数掩盖证据缺失。
八、完成交付，还要完成独立运行的演练
可以让非原开发者实际完成以下工作：运行一次正常任务、识别一次缺数、恢复一次采集失败、查到当前规则版本、定位维护人，以及执行一次受控回退。
只有演练，才能发现那些维护者以为“大家都知道”的步骤。后续还应记录人工干预频率，检查系统是否持续依赖某个人救火。
九、为每个项目保留一张验收记录
这张记录可以包含：业务问题、负责人、适用范围、输入与输出、基线、样本集合、通过标准、关键错误、试用结果、维护负担、未解决事项和下一次复查时间。
一个阶段未通过时，可以缩小范围、增加人工检查点、修改规则，或者停止不合适的功能。每一种决定都应能对应到实际证据。
对 FDE 而言，这样的验收记录能够把交付价值说明得更清楚：解决了哪项具体工作，哪些人已经采用，减少了什么负担，仍有哪些限制，以及下一次交付可以复用哪些经验。
