交付流程

目的

定义从想法到生产环境的默认路径。

交付闭环

问题简报
-> discovery
-> 必要时做技术设计
-> 任务拆分
-> 实现
-> PR review
-> CI gate
-> staging / preview 验证
-> production release
-> 观测检查
-> 反馈或事故 action

三角色交付关口

阶段 产品负责人看什么 技术负责人看什么 平台 / 资深工程师看什么
Discovery 用户问题、成功信号、优先级 技术风险、系统边界 是否能定位项目、依赖、数据
Implementation scope 是否漂移 设计和代码是否可维护 本地命令、测试、CI 是否可执行
Review 用户可见行为是否符合预期 质量、风险、回滚 证据、模板、自动检查是否完整
Release 用户影响、沟通、验收 发布风险、rollback 发布入口、监控、smoke 是否可用
Feedback 指标和用户反馈 技术债和事故 action runbook、告警、排障文档是否要更新

探索阶段

当方案不确定时，必须先做 discovery。

产出：

  1. 问题说明。
  2. 受影响用户或系统。
  3. 当前行为。
  4. 期望行为。
  5. 非目标。
  6. 风险。
  7. 验收标准。

技术设计

以下变化需要 RFC 或 ADR：

  1. 模块边界变化。
  2. 数据库 schema 变化。
  3. 外部 API 变化。
  4. 安全或权限变化。
  5. Runtime 架构变化。
  6. 成本或可靠性影响。

实现

实现应遵循小批量原则：

  1. 从 main 创建分支。
  2. 每个 PR 聚焦一个工作项。
  3. 添加或更新测试。
  4. 本地运行相关检查。
  5. 带证据打开 PR。

合并前至少要覆盖这些检查语义。具体命令按语言和仓库替换：

检查语义 目的 JS/TS 示例 Go 示例 Python 示例 Rust 示例
静态检查 格式、lint、类型或编译期错误 pnpm check 或 pnpm lint && pnpm typecheck gofmt -l . && go vet ./... ruff check . && mypy . cargo fmt --check && cargo clippy -- -D warnings
测试 验证相关单元和集成行为 pnpm test go test ./... pytest cargo test
构建 确认可交付 artifact 能生成 pnpm build go build ./... python -m build 或 Docker build cargo build --release
Migration 验证 schema 变化可执行 pnpm db:migrate 项目 migration CLI Alembic/Django migration SQLx/Diesel migration
Smoke 验证关键业务闭环 pnpm smoke:m1 项目 smoke 脚本 项目 smoke 脚本 项目 smoke 脚本

迭代时可以跑更小的 focused command，但最终证据应覆盖相关门禁。

完成定义

  1. PR 已合并，或明确记录 no-code 结果。
  2. CI 通过。
  3. 测试或手动验证证据已附上。
  4. Migration 状态已确认。
  5. 必要的监控或日志已补齐。
  6. 发布和回滚路径明确。
  7. Owner 接受结果。

后续 Agent 就绪要求

这一节在人类交付闭环稳定后再看。当前阶段先保证人类能按同一条路径交付、验证和关闭。

Agent 只能插入明确的工作槽位：

阶段 适合 Agent 的任务
Discovery 总结代码路径、识别受影响模块
Design 起草 RFC 方案
Implementation 有 scope 的代码修改
Review 风险评审、测试缺口评审
Release 检查 checklist 和证据

不要让 Agent 拥有最终验收权。

下一步阅读

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