专家评审清单

目的

这份文档用于从外部咨询和交付专家视角评审整套文档。评审重点不是“文档是否完整”，而是团队能不能靠这些文档完成真实工作闭环：

新人能理解项目
-> 组员能协作开发
-> 负责人能评审风险
-> 产品能验收结果
-> 平台能支撑运行和排障
-> 任务能关闭并反馈回流

总体判断

当前文档体系已经覆盖主要闭环：工作入口、三角色治理、项目级文档、本地开发、PR、测试、发布、事故和后续 Agent 边界。

专家评审的核心结论：

1. 方向正确：文档把“人先闭环”放在 Agent 之前，这是正确顺序。
2. 结构基本完整：组织级原则、项目级落地、模板三层都有。
3. 主要风险不是缺文档，而是落地时每个项目没有把模板填成真实命令、真实 owner、真实链接。
4. 需要用试点项目验证，而不是继续扩写组织级文档。

评审原则

分层评审

高风险缺口

试点项目评审步骤

不要先推广到所有项目。先选一个真实项目做 2 周试点。

先用 72-试点讨论清单-stakeholder-discussion-guide.md 确认参与人、讨论点和工具入口，再按 71-试点落地手册-pilot-rollout-playbook.md 执行。试点证据使用 templates/试点验收-pilot-acceptance.md 记录。

通过标准

一个项目通过专家评审，不是因为文档写得多，而是因为能证明这些事已经发生：

1. 新人或非核心成员能在半天内跑起项目。
2. 一个小任务能从需求进入到任务关闭，全链路有链接。
3. PR 里能看到验证证据、风险和回滚方式。
4. 产品负责人能在 preview、staging 或截图中完成验收。
5. 平台 / 资深工程师能根据文档定位 CI、发布、日志、监控和常见故障。
6. 文档和代码不一致时，有任务或 PR 修正文档。

不建议继续做什么

1. 不建议继续扩写更多组织级原则，先拿一个项目验证。
2. 不建议让新人读 30 多份文档，按角色路径读。
3. 不建议把 Agent 文档提前推给团队执行，它现在只负责定义未来边界。
4. 不建议用会议替代事实记录，结论必须回写任务、PR、发布记录或文档。
5. 不建议追求一次性 L3 成熟度，草台团队先做到 L0 / L1。

下一步

最有价值的下一步是选一个真实项目，按 71-试点落地手册-pilot-rollout-playbook.md 执行，用 templates/项目入口-project-index.md 生成项目级 docs/PROJECT.md，再让一个不熟悉项目的人按文档跑一遍。

如果这一步跑不通，优先修项目级文档和开发环境，而不是继续完善组织级规范。

下一步阅读

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

• 73-试点确定方案-pilot-decision.md：先看结合 70/71/72 后的确定版。
• 72-试点讨论清单-stakeholder-discussion-guide.md：再确认哪些人参与、讨论什么和工具入口。
• 71-试点落地手册-pilot-rollout-playbook.md：讨论清楚后，用试点手册验证。