/pilot — 有边界的试点准备与证据复盘

仅在需要有限的真实用户/现场暴露才能回答关键问题时使用；可逆的桌面验证不必升级成 Pilot。帮助项目团队决定是否、在哪里、如何开展有限试点。适用于客户交付、内部产品验证及软硬件组合场景。此 Skill 生成可审查的计划，不会部署软件、不代表任何参与方批准数据处理，也不宣告生产就绪。

1. 从现场结果开始

• 有 /probe 简报、契约、原型反馈和客户决策时复用它们；不要求先跑完整 SpecFlow 流程。
• 明确客户/用户任务、当前基线、试点对象与环境、业务赞助人、日常操作人、技术负责人和验收决策人。
• 将事实、假设和未解决阻断项分开。只追问会改变安全、范围、验收或回滚的决策。
• 验收通过、部署完成、账号可用或客户访问权限，不代表数据处理/模型调用/现场运行已获授权；逐项依据对应授权记录确认，缺少证据就标 Unknown 并作为启动前置条件。
• 目标用户激活偏低时，按场景调查访问、任务匹配、信任、培训、工作量、性能和支持等可能原因；岗位/工作方式影响也作为待验证假设，不直接归因。
• 在接触真实用户/设备/客户数据前，预先写清成功证据、失败/停止条件、暴露范围和决策人；不要试点结束后再改成功标准。

2. 限定试点边界

按场景记录实际需要的事项：

• 用户、工作流、系统、地点、时间范围及明确排除项；
• 数据分类、获批的处理位置/模型供应商、访问方式、数据留存/删除负责人和事件联系人；
• 集成与部署前置条件、客户需完成的动作、支持时段和依赖负责人；
• 若是硬件产品，写明设备/固件版本、部署地点与环境、供电/网络限制、传感器/执行器配置，以及当前验证证据属于仿真、台架、实机受控测试还是现场运行；
• 若涉及运动、加热、强光、声音、夹持或其他物理影响，记录安全负责人确认、设备保护机制、停止/急停条件和现场监督安排；具体检查项按产品风险和适用流程确定；
• 按场景确认人工接管/停止权限及必要的场地、保险或运营审批，不把口头意愿当批准；不要求每个项目都机械列出全部项。
• 低质量、歧义、延迟或失败时的人审/人工兜底；
• 停止/回滚步骤、触发条件、负责人、预期恢复时间和验证证据。

实体设备/公共现场试点的人员配比、速度/隔离限制、到场响应时间、数值型停止阈值、恢复时间和启动日期只能来自既有方案/政策/合同，或由有权安全/场地负责人确认。没有依据时不提供示例数字、日历日期或“每台至少一人”等配比，只列待决项和需确认角色；不得把它们放进有条件开跑路径。未完成安全确认时，只提供仿真、台架、封闭区 dry-run 等非公众运行替代方案；不得设计“条件满足即可按原周末试跑”的路径。

若试点会影响真实用户、客户数据、现场配置、生产邻近系统或实体设备，应把启动前的恢复验证证据列为前置条件。按风险选择可行方式，例如等价环境演练、Feature Flag 关断验证、备份恢复抽查或受控 dry-run，并记录环境、结果、负责人和恢复成功判据。若无法安全或等价地演练，将其列为启动阻断项；仅当适用流程允许接受该类剩余风险时，才交由有权决策人书面决定并记录依据。在获得所需批准前不得启动，强制安全控制不可被文档豁免。计划文档本身不算演练证据。纯隔离、无外部副作用的沙盒验证可标记为不适用并说明原因。

若数据授权、身份/安全责任或安全停止路径未知，将其列为试点启动阻断项。若是否采集/存储/传输传感器数据未知，先确认数据流；只有有证据确认“不采集、不存储、不传输”时才标为不适用，不能默认没有数据风险。不得把 Demo 或契约文本当作客户批准。

3. 定义可测的验收方式

将目标用户激活与部署/验收状态分开判断：按场景说明什么可观察证据表明目标用户已用系统完成有价值的真实任务，并与本节已有的用户/业务指标对齐，不另设默认指标或阈值。若观察窗口内没有相关使用证据，记录原因，并按预先约定的判断规则决定补充观察、调整范围或停止；不能仅凭系统上线或验收通过称为成功。低风险、短期、无外部副作用的验证可用一句话带过，不必单独测量。

对每个结果写明基线、目标/判断规则、测量来源、样本门槛、复核时间/窗口和负责人。选择与场景相关的指标，不强制全选：

• 用户/业务结果：任务完成率、耗时、采纳、升级人工；
• 输出质量：人工修正、纠错、引用核查发现；
• 运营质量：延迟、失败、成本、支持负担；
• 安全合规：未授权动作、数据处理、事故和审计证据。

不得编造阈值，也不能在样本不足时宣称统计置信。如果基线或样本量未知，把“建立测量基线”作为试点首要目标，并明确暂时不能做出的结论。

4. 试点简报与复盘

默认在对话中给出决策简报和阻断项；只有用户明确要文件，或简报需要交接/留档时，才创建 pilot-brief.md。沿用项目已有格式；没有时，按需读取 templates/pilot-brief.template.md：

1. 用户问题、假设、范围、基线、成功证据和判断规则；
2. 启动阻断项清单（无阻断项时明确写“无”）；
3. 客户环境、数据、集成依赖和审批；
4. 支持安排、人工兜底和事件处理路径；
5. 停止、恢复和回滚条件、负责人及验证方式；
6. 复核窗口、决策、证据限制和后续负责人。

写入文件前先完成所有章节内容，再一次性写入；阻断项条目必须出现在文件正文的阻断清单中，不能只放在对话回复、附件摘要或预览旁栏。清单应有实际编号条目及事项、证据/待确认内容、责任角色和状态；仅有章节标题、文字说明或 B01–B02 范围不算清单。调用平台的文件/Artifact 创建功能时，把包含完整阻断表的整篇 Markdown 作为一次写入内容；随后读取该 Artifact 本身，而不是草稿变量或聊天摘要。若读回后缺少阻断表，先替换 Artifact 正文并再次读回；无法验证时标为“文档未完成”，不要声称文件已交付或校验通过。无阻断项时在文件中明确写“无”。引用阻断项编号或范围时，核对其与清单一致。若此 Skill 安装副本中包含 scripts/validate_pilot_brief.py 且当前环境能运行 Python，必须从 Skill 安装目录解析脚本路径，并对刚回读的同一文件路径运行；只有实际命令输出为 PASS 才能报告“机械校验通过”，并原样附上完整输出（绝对文件路径与完整 SHA-256，不用省略号）。计划了命令、看到运行状态、只在聊天回复中出现的表格或被缩写的校验摘要都不是校验结果。若脚本返回读取/调用错误，先修正路径或可读编码并重试；无法运行则标明“未机械校验”。若产物不在可由脚本读取的本地路径、脚本/运行环境不可用，标明“未机械校验”。若脚本返回 UNSUPPORTED，保留原格式并逐项人工复核，标明“不支持该格式，未机械校验”；不得为了通过脚本改写用户已有格式。脚本返回 FAIL 时先修复实际文件并重新读取/运行；无法修复就标为“文档未完成”。校验只覆盖结构与编号，不验证事实、授权或风险是否获批，也不代表启动条件已满足。

复盘时对照基线和判断规则，记录限制与意外影响，并指定下一步负责人和日期。若试点后转入常态运营或撤场，交接写明客户内部接手人（日常操作与决策分别由谁负责）、已移交的运行责任，以及仍需供应商或项目组提供的支持。当复盘涉及多个客户或复用意图时，用一句话区分哪些是本客户的特例、哪些值得回流为可复用的产品或交付学习。试点通过不等于生产批准；生产就绪仍需独立的安全、可靠性、容量和运营评审。