试点激活、项目交付、移交与产品回流

四类采用证据与稳定行为

上线说明系统可以访问；激活说明目标用户至少在关键任务中完成一次有效使用；稳定行为说明他们在一段时间内重复使用，并愿意把结果带入后续工作。

培训出席率、账号开通率和登录次数不能代替关键任务完成证据。

至少追踪目标用户激活率、关键任务使用深度、重复使用和绕行行为。使用深度看用户是否完成关键步骤，而不是只打开页面。

绕行包括回到旧表格、重复手工核对、私下使用其他工具或只在汇报时打开系统。绕行常常暴露质量、流程、入口、责任或信任问题。

支持者网络与 30/60/90 证据板

项目需要业务 Owner、日常维护者、非正式影响者、高层支持者和受影响人员。只有一个高层 Sponsor，无法替代一线的日常采用和纠错。

组织观察从情绪地图扩展为四张图：情绪说明人怎样感受，利益说明得失，权力说明谁能决定，能力说明谁能使用、维护和教会别人。

前 30 天关注首次激活、入口、主要错误和支持响应；60 天关注重复使用、关键任务深度、绕行与知识维护；90 天再判断业务结果、角色变化、内部接管和扩展条件。

不同场景的周期可以调整，但不能在第一周用短期热情代替持续结果。

试点期间将日志、用户反馈和现场观察汇总，按对真实使用的影响排序。先解决阻止关键任务完成的障碍，再处理外观和低频偏好。

模型问题、知识问题、流程问题和组织问题需要交给不同负责人，不能全部归入产品待办。

管理者关心价值、资源与风险，业务 Owner 关心任务和采用，IT 关心运行和维护，用户关心负担与责任。表达方式可以不同，但事实、范围、风险和承诺必须一致。

复盘给出扩大、修改或停止，并写明证据、所需决策、下一步和责任人。

移交包与接管演练

客户或内部团队能够更新知识、运行评估、处理常见问题、升级故障和发现下一场景，才具备接管条件。退出不是突然离场，而是逐步减少代操作并移交责任、权限和判断。

客户依赖下降不等于合作价值下降。外部 FDE 可以转向更难的场景，而不是长期替客户维护日常工作。

移交包包含场景与价值、流程与责任、上下文与知识、Agent 与 Skill、评估与错误、安全与运行、培训、支持边界和 90 天安排。

代码只是其中一部分。没有业务解释、评估集、版本和维护 SOP，内部人员无法判断改动是否安全。

参加培训不等于能够维护。内部维护者至少独立完成一次知识更新、评估运行、版本发布或故障处理，并知道何时升级。

演练记录保留操作结果、问题、补充培训和最终责任人，作为退出评审证据。

产品回流备忘录与三层复用

每个项目结束都要区分客户独有问题、同类客户会重复的问题、可做成模板或 Skill 的内容，以及需要平台解决的系统能力。

备忘录还要记录哪些现场证据推翻了原有产品假设、临时修补为何出现，以及不建议产品化的原因。

第一层复用方法、检查表和作业模板；第二层复用 Skill、连接器和评估组件；第三层才进入平台能力。越接近平台，越需要跨客户证据和维护责任。

不是所有客户需求都应该产品化。过早把专属规则写进平台，会把一次性交付问题长期带给所有客户。

双向回流的退出评审

退出评审同时检查客户是否能够运行、产品团队是否收到可评审输入、外部支持边界是否清楚。两边都要有 Owner、版本和下一步。

一次项目结束后，客户能独立推进下一个场景，交付方的重复定制量也能够下降，才说明双方都获得了长期价值。