7 天试点怎么设计：范围、人员、数据、人工门禁与验收

短周期试点的价值，不是承诺七天完成所有系统，而是强迫项目把范围说清：只解决一个工作问题，只使用一组受控样本，只让一组明确用户测试，只验证一套提前写好的条件。

Palantir 的公开材料介绍了短周期共同动手、识别业务并开发初始用例的交付模式；OpenAI 的 FDE 岗位说明强调从发现到生产和评测反馈的端到端责任。二者都不证明任何企业能在固定天数上线。本文的“7 天”是和铭用于范围管理的建议周期。

进入试点前必须齐备

• 一个流程负责人和一组真实操作人。
• 一句话能说清的流程边界，不以“全公司知识库”作为第一期范围。
• 经授权、脱敏并完成分级的代表性样本。
• 当前人工结果或操作记录，作为比较基线。
• 明确不能自动执行的动作和人工复核位置。
• 一名能决定继续、调整或停止的业务责任人。

缺少数据授权、人工基线或责任人时，应先补准备，不应把七天倒计时当作进度压力。

最小范围

一个可控试点可以写成：一家企业、一个流程、一个规则版本、一组受控样本、一个输入入口、一个输出去向、一名复核人。

不在第一期同时加入多个部门、多个模型、多个系统和自动对外动作。新增范围必须说明它解决什么问题，以及会增加哪些依赖和风险。

七天工作节奏

第 0 天：准备与准入

核对授权、样本、责任人、环境和禁止动作。记录当前流程基线，并把无法确认的事实列为缺口。准备不齐，不进入试点。

第 1 天：现场发现

观察实际操作人怎样收到任务、寻找材料、判断例外和交付结果。管理流程图与真实操作不一致时，以可复核的现场证据为准。

第 2 天：流程映射与边界

画出触发、输入、规则、系统、交接、人工判断和完成证据。标记数据分级、账号权限、保留周期和外部接口。

第 3 天：受控原型

只实现最小任务，例如提取、比对、分类或起草。所有正式提交、发送、付款、删除、权限变更和高影响结论仍由人确认。

第 4 天：评测与失败注入

用正常、异常、缺件和禁止样本重复测试。记录输入版本、输出、人工修改、失败类型和是否触发正确门禁。

第 5 天：真实用户试用

由实际操作人完成任务，工程人员观察而不代替。检查说明是否看得懂、异常是否能处理、日志是否能回读。

第 6 天：修复与回退演练

只修复影响验收的关键问题；演练停止、降级、恢复和人工接管。不能回退的系统不进入下一阶段。

第 7 天：证据验收与交接

逐项回读测试记录、人工门禁、权限、日志、恢复和使用说明。业务价值指标另行持续观察，不把七天样本写成长期 ROI。

两类验收必须分开

交付验收

• 样本来源、版本和处理记录可追溯。
• 正常、异常和禁止样本均有结果。
• 高影响动作没有绕过人工门禁。
• 标准用户能独立完成操作和回退。
• 重启、依赖失败或模型不可用时有受控降级路径。

商业与采用证据

• 工作流是否被重复使用。
• 人工覆盖是否下降且风险可接受。
• 返工、等待、遗漏或支持成本是否真实变化。
• 用户是否愿意继续使用，责任人是否愿意继续投入。

第二类通常需要更长时间和更大样本，不能用第七天的演示替代。

停止条件

• 数据来源或使用授权无法确认。
• 流程负责人无法参加，测试只剩工程师自演示。
• 关键错误无法在外部影响发生前被拦截。
• 系统变更无法回退，或日志无法说明发生了什么。
• 试点目标不断扩张，已无法用原验收条件判断。

交付物

• 当前流程图与目标流程图。
• 数据、权限、接口和人工门禁清单。
• 代表性评测集、测试记录和失败分类。
• 版本化配置、操作手册、回退步骤和责任人。
• 继续、调整、扩大或停止的书面建议。

可下载模板

使用《7 天企业 AI 受控试点清单》约束范围、人员、证据和停止条件。模板不是固定周期承诺，也不能替代专项安全与合规评审。