人类工作闭环工程系统

目的

这个目录把“人类工作如何闭环”的工程系统拆成可执行的通用文档包。它不绑定任何具体产品、公司或仓库，可作为软件团队、内部研发系统，以及后续 Agent 协作平台的参考模板。

目标不是制造流程负担，而是让每个工作都能从提出、执行、验证、审查、发布到反馈回流。当前阶段先完成人的闭环，再考虑让 Agent 进入同一套任务、证据和审批链路。

人类工作闭环
-> 人类交付闭环
-> 人类审查闭环
-> 人类发布闭环
-> 人类复盘闭环
-> 后续再让 Agent 进入同一套闭环

如果人类流程本身不明确，任何自动化都会放大混乱。

推荐阅读顺序

1. 新人先读 00-先读这里-start-here.md，知道今天接任务怎么做。
2. 遇到不懂的词，查 01-术语表-glossary.md。
3. 如果团队还比较混乱，先只执行 02-L0最小闭环-l0-minimum-closure.md。
4. 刚入职工程师读 42-工程师入职-engineer-onboarding.md，按项目理解、协作、开发、PR 的顺序走。
5. 不知道怎么本地运行时，读 43-本地开发-local-development.md。
6. 再读 12-协调和交接-coordination-and-handoff.md，明确谁推进、谁拍板、谁 review。
7. 需要知道负责人和组员怎么在工具里协作时，读 16-三角色协作流程-three-role-collaboration-flow.md。
8. 产品经理或业务负责人读 20-产品闭环-product-closure.md，确认用户问题、优先级、验收和反馈回流。
9. 然后按需要读工作入口、PR、测试、发布、安全和架构文档。
10. 技术负责人或项目负责人再读 40-项目级闭环-project-level-closure.md，把原则落到具体项目。
11. 制定和维护规范的人读 10-三角色治理-three-role-governance.md，按技术、产品、平台三角色共同评审。
12. Agent 相关文档放到人类闭环稳定之后再读。

按角色怎么读

不要让所有人读完整套文档。每个角色先读自己能用来闭环的部分。

默认工具假设和替换原则

下面是通用默认工具栈。如果组织已经有成熟替代工具，可以沿用，但职责边界要保持清楚：工作、代码、CI、文档、运行时事实、审计事实不能混成一个系统。

文档中的命令、目录和服务名都是参考实现。落地到具体仓库时，应替换为实际的 package manager、CI、数据库、runtime 和 provider 集成。

文档地图

00 入门和总纲

10 协作和治理

20 产品

30 工程交付

40 项目和新人

50 运行和风险

60 落地计划

70 评审和改进

90 后续 Agent

模板在 templates 目录。常用入口：

操作原则

当前阶段先保证人类工作满足：

明确任务
-> 明确 Driver / Approver
-> 有边界的 scope
-> 明确验收标准
-> 执行
-> 留下验证证据
-> review / 业务验收
-> release / rollback / close
-> 反馈回流

如果未来接入 Agent，它也必须进入同一套闭环：有任务、有边界、有证据、有人 review、有人验收。

三角色治理

这套文档由三类角色共同维护，不能只由一个人单独制定：

具体分工和评审节奏见 10-三角色治理-three-role-governance.md。

统一角色命名：

下一步阅读

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

• 00-先读这里-start-here.md：新人、组员或临时接手的人从这里开始。
• 70-专家评审清单-expert-review-checklist.md：规范维护者先用专家清单判断整套文档是否能落地。