20 - 团队三层指令治理
三层模型
| 层级 | 适合承载 | 不应承载 |
|---|---|---|
| 组织层 | 保密、审批、工具许可、对外动作、审计和法定/职业伦理底线 | 单个案件事实、个人文风 |
| 项目层 | 项目代号、范围、阶段、时限、事实入口、文件和交付工作流 | 组织通用政策副本、成员私人偏好 |
| 个人层 | 表达详略、批注方式、语言、非强制工具偏好 | 弱化组织安全边界、修改团队事实 |
同一事实只维护一个权威来源，下层通过引用衔接，不复制组织政策或案件事实正文。
优先级与冲突
- 法律、职业伦理和组织强制安全政策不可被下层弱化。
- 项目规则在本项目内覆盖组织默认工作流，但不能突破上一条。
- 个人偏好仅在不冲突时生效。
- 同层规则矛盾或“覆盖”是否属于弱化无法判断时，停止相关动作，请求项目负责人确认，并写入项目现有决策载体。
“越具体越优先”只适用于同等强制等级；不能用更具体的项目指令绕过组织保密、审批或外发限制。
team 模式引导问题
组织层
- 哪些动作永远需要人工批准？
- 哪些材料不得进入外部服务、Git 或日志？
- 允许使用哪些工具、知识库和传输渠道？
- 审批、审计和事故响应的权威载体是什么？
项目层
- 项目代号、类型、阶段和关键时点是什么？
- 受控事实入口在哪里，访问条件是什么？
- 证据、期限、决策和交付各以哪个现有载体为准？
- 谁是项目负责人和最终复核人？
个人层
- 输出详略、格式和语言偏好是什么？
- 哪些偏好只是建议，不能影响团队流程？
更新流程
- 先确认变更所属层级和负责人。
- 只更新对应层的稳定受管区块。
- 展示 diff，检查是否削弱上层政策。
- 在新会话中分别测试上层红线和本项目工作流。
- 组织政策变化由组织维护者发布；项目或个人层不得复制后自行漂移。