试点确定方案

目的

这份文档基于 70-专家评审清单-expert-review-checklist.md、71-试点落地手册-pilot-rollout-playbook.md、72-试点讨论清单-stakeholder-discussion-guide.md 做最终收口。

结论很明确：下一步不是继续写组织级原则，而是选一个真实项目做两周试点，用真实任务验证人能不能闭环。

确定结论

确定参与人

必须参加

按条件加入

原则：小团队可以一人多职，但不能缺这些视角。试点记录里必须写具体人，不写团队名。

确定工具链

工具可以替换，但职责不能混。试点项目必须确认自己的真实入口。

明确禁止：用群聊替代任务系统，用会议纪要替代 PR，用本地命令输出替代 CI，用个人收藏夹替代发布和监控入口。

确定工具协作流程

试点必须跑通这条链路：

Linear/Jira/GitHub Issue 记录任务
-> Notion/Lark Docs 或任务描述写清用户问题和验收标准
-> docs/PROJECT.md 写清本地运行、检查、发布、监控入口
-> GitHub/GitLab 提 PR
-> CI 跑 required checks
-> Product Owner 在 preview / 截图 / staging 完成验收
-> Ops Owner 或 Operator 发布或模拟发布
-> Sentry/Grafana/Datadog 观察结果
-> Lark/Slack 通知结论
-> 任务卡关闭并记录证据和后续 action

如果其中任何一步只发生在口头或群聊里，试点不算通过。

第一场讨论会确定议程

第一场会只开 60 分钟，只解决四件事：

会后必须留下：

1. 一个试点任务卡。
2. 一份 templates/试点验收-pilot-acceptance.md。
3. 一个待补的项目级 docs/PROJECT.md。
4. 一个真实小任务或 bug。
5. 下一次检查时间。

两周执行顺序

通过 / 不通过判定

通过

同时满足：

1. 新人或非核心成员能按文档跑起项目。
2. 一个小任务完成任务卡、PR、CI、review、产品验收、关闭记录。
3. 发布或模拟发布能说清 smoke、rollback、dashboard、日志。
4. 发现的文档缺口至少修掉一部分。
5. 三角色认为流程没有明显拖慢交付。

不通过

出现任一情况即不通过：

1. 项目没有具体 owner。
2. 新人必须靠私聊才能跑起来。
3. PR 没有验证证据。
4. 产品没人验收。
5. 发布入口、回滚或监控不清。
6. 讨论只停留在会议，没有写回任务、PR、文档或验收记录。

不通过不代表失败，代表当前项目 L0 还不够。继续修同一个项目，不要推广。

最终决定

1. 先执行 72 -> 71 -> 试点验收模板，不要先推广全套文档。
2. 试点第一场会必须拉齐人、工具入口和小任务。
3. 所有输出必须落到任务、PR、docs/PROJECT.md、发布记录或试点验收记录。
4. 试点通过前，不开始 Agent 接入，不要求所有项目补全 L3 文档。

下一步阅读

读完或填完这份文档后，通常继续看：

• 72-试点讨论清单-stakeholder-discussion-guide.md：先按讨论清单开试点确认会。
• 71-试点落地手册-pilot-rollout-playbook.md：确认后按两周试点手册执行。
• templates/试点验收-pilot-acceptance.md：执行过程中用验收模板留证据。