90 天落地计划

目标

把隐性的工程习惯推进到明确、可执行的人的闭环系统。第一目标是人能闭环；Agent 接入放到后续阶段。

落地由三角色共同推进：技术负责人守住工程质量和项目级闭环，产品负责人守住用户问题和验收反馈，平台 / 资深工程师把命令、模板、CI、运行和排障做成可执行能力。

第 0-30 天：先让人类工作闭环

交付物：

  1. 选 1 个真实项目做试点，执行 71-试点落地手册-pilot-rollout-playbook.md。
  2. 建立唯一工作入口，可以是 Linear、Jira、GitHub Issues、飞书表格或轻量任务表。
  3. 增加最小任务模板：目标、Driver、Approver、scope、验收标准、风险。
  4. 增加 PR 或 patch 模板：改了什么、怎么验证、风险和回滚。
  5. 定义 Driver 和 Approver：谁推进，谁拍板。
  6. 所有活跃工作必须能链接到任务、PR/patch 或关闭记录。
  7. 对草台团队，先不要求完整 PRD，只要求任务能关闭。

成功信号：

每个活跃工作都有 Driver、Approver、scope、验收标准和关闭结果。

第 31-60 天：让交付和发布闭环

交付物：

  1. 在试点项目里定义一个 repo-level check command，并说明它覆盖哪些门禁语义。
  2. CI 失败时阻止合并，至少覆盖 lint/typecheck/test/build 中的核心项。
  3. 发布前必须列 release scope、Driver、Approver、Operator、rollback。
  4. 建立一个核心 smoke，验证主路径不是只验证服务启动。
  5. 发布后记录 commit、smoke、dashboard 或观察结果。
  6. 高频故障补最小 runbook。
  7. 如果试点通过，再复制到第 2-3 个项目；如果不通过，继续修试点项目 L0。

成功信号：

团队可以重复发布小变更，并能说清失败后怎么回滚或 retry。

第 61-90 天：巩固人的闭环，准备 Agent 边界

交付物：

  1. 对前 60 天的任务、PR、发布记录做一次抽样审计。
  2. 把无 Driver / Approver、无验证证据、无 rollback 的问题降到可接受范围。
  3. 核心项目补齐 ARCHITECTURE.md、TECH_STACK.md、DEPENDENCIES.md 的 L0 一页纸版本。
  4. 高频故障补最小 runbook。
  5. 对安全、生产部署、数据库 migration 等高风险动作保留人工 gate。
  6. 用 templates/试点验收-pilot-acceptance.md 对试点项目做最终验收。
  7. 选择一个低风险候选 Agent workflow，但只做 readiness 评估，不急着上线。

成功信号：

人类任务已经能稳定被审查、重试、关闭和复盘；团队能说清哪些环节以后可以交给 Agent。

下一步阅读

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