三角色治理和评审

目的

这套文档不应该由单一角色制定。单一角色会天然偏科：

只有技术负责人 -> 容易变成工程自洽，但产品价值不闭环
只有产品负责人 -> 容易变成流程要求，但工程不可执行
只有平台 / 资深工程师 -> 容易变成工具和模板齐全，但缺少业务拍板

推荐用 3 个角色共同制定、评审和维护：

1. 技术负责人。
2. 产品负责人。
3. 平台 / 资深工程师。

小团队可以一人多职，但评审时必须按这 3 个视角分别过一遍。

三角色和组员在具体工具里的协作步骤见 16-三角色协作流程-three-role-collaboration-flow.md。本文件定义责任边界，16 文件定义执行流程。

角色 1：技术负责人

核心职责

技术负责人是这套工程闭环的总 owner，负责判断规范是否能支撑长期交付。

负责拍板：

1. 工程质量底线。
2. PR、测试、CI、发布、回滚要求。
3. 架构文档和项目级文档要求。
4. 高风险变更的技术门禁。
5. 技术债、重构、平台化投入的优先级建议。

不应该单独拍板：

1. 产品优先级。
2. 用户验收结论。
3. 业务是否接受风险。
4. 对外沟通节奏。

技术负责人评审问题

评审文档时问：

1. 新人能不能按文档跑起项目？
2. 每个项目是否有 docs/PROJECT.md？
3. 每类变更要跑什么检查是否清楚？
4. 发布失败后是否知道怎么回滚？
5. 架构、依赖、运行方式是否能被接手？
6. 高风险变更是否有明确 approval？
7. 文档是否能在 PR review 中被维护，而不是靠专项运动？

技术负责人主要维护文档

角色 2：产品负责人

核心职责

产品负责人负责保证团队做的是正确的事，而不只是把事情做完。

负责拍板：

1. 用户问题是否成立。
2. 需求优先级和取舍。
3. Scope 和非目标。
4. 用户可见功能的验收标准。
5. 上线后反馈回流。
6. 是否需要灰度、用户通知、客服话术、销售同步。

不应该单独拍板：

1. 绕过工程质量门禁。
2. 绕过安全、权限、数据、支付 review。
3. 要求无回滚方案直接上线。
4. 要求工程在 scope 不清时开工。

产品负责人评审问题

评审文档时问：

1. 需求入口是否要求写清用户、问题、目标？
2. 是否要求记录优先级理由？
3. 用户可见功能是否有 Business Approver？
4. 验收标准是否能被产品和工程共同判断？
5. 发布前是否检查用户影响和沟通对象？
6. 上线后是否有反馈入口和观察时间？
7. Done 是否包含业务验收或关闭结论？

产品负责人主要维护文档

角色 3：平台 / 资深工程师

核心职责

平台 / 资深工程师负责把规范做成可执行的东西：命令、模板、CI、脚本、项目入口、默认配置和排障路径。

负责拍板或主导：

1. 本地开发环境怎么标准化。
2. CI 检查如何落地。
3. 模板怎么写得具体可用。
4. 发布、监控、日志、排障入口怎么统一。
5. 新人第一个 PR 如何走通。
6. 哪些重复人工动作应该工具化。

不应该单独拍板：

1. 产品优先级。
2. 架构方向的最终取舍。
3. 业务风险接受。
4. 安全例外。

平台 / 资深工程师评审问题

评审文档时问：

1. 文档里的命令能不能复制执行？
2. pnpm check 这类命令是否写清楚验证语义？
3. 不同语言是否有等价命令？
4. 新人环境验收是否能半天内完成？
5. 项目入口模板是否能让人找到 owner、代码地图、运行方式？
6. PR 模板是否能让 reviewer 判断风险？
7. 哪些文档字段可以被 CI 或脚本检查？

平台 / 资深工程师主要维护文档

三角色分工矩阵

三角色共同评审节奏

不要为文档开大量会议。建议固定一个轻量节奏：

评审不是为了证明谁没做好，而是找出闭环断在哪里。

冲突处理

产品想快，技术认为风险高

处理方式：

1. 产品负责人说明用户影响和业务期限。
2. 技术负责人说明风险和最低保护措施。
3. 平台 / 资深工程师给出可执行选项：灰度、feature flag、只发部分 scope、补监控、延后 migration。
4. 记录最终选择、风险接受人、回滚方式。

不能只用“老板要”或“技术不让”作为结论。

技术想重构，产品认为没价值

处理方式：

1. 技术负责人说明不做的风险：故障、交付慢、安全、成本。
2. 产品负责人判断是否影响当前目标。
3. 平台 / 资深工程师拆成可验证的小任务。
4. 如果不做，记录接受的技术债和复查时间。

平台想标准化，团队嫌麻烦

处理方式：

1. 平台 / 资深工程师证明能减少哪类重复问题。
2. 技术负责人判断是否成为门禁。
3. 产品负责人确认是否影响交付节奏。
4. 先在一个项目试点，验证有效再推广。

草台团队最小版

如果团队只有 3-8 人，不要建立复杂委员会。直接这样分：

每周只抽样看：

1. 一个新需求。
2. 一个已合并 PR。
3. 一个发布记录。
4. 一个新人或接手项目时遇到的问题。

只要这 4 个样本能闭环，团队就在变好。

评审结论格式

三角色评审结束后，只输出这几项：

本次评审对象：
技术负责人结论：
产品负责人结论：
平台 / 资深工程师结论：
必须修改：
可以延后：
Owner：
截止时间：

不要输出大段会议纪要。评审必须落成任务、模板修改或明确接受风险。

下一步阅读

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

• 16-三角色协作流程-three-role-collaboration-flow.md：角色边界明确后，继续看三角色如何在工具里协作。