--- title: DaC-Workflow description: 文本抽取：AI研讨会/DaC-Workflow updated: 2026-11-04 tags: [原始文档, 抽取, AI研讨会] source: AI研讨会/DaC-Workflow source_type: txt source_hash: 2966b4b92887 extracted_at: 2026-11-04 quality: ok --- --- source: AI研讨会/DaC-Workflow.md type: md size_kb: 12 category: AI研讨会 quality: ok --- # DaC Workflow 自动化方案 > **Document as Code（文档即代码）**：把 PRD 当作代码一样管理。PM 在独立 Git 项目 `product-docs` 中维护 Markdown PRD，后续任务拆解、研发协作、代码评审、测试和上线逐步自动衔接。 --- ## 1. 方案目标 建设一条从 **PRD → 研发任务 → 代码变更 → 测试验证 → 上线回流** 的可追溯链路。 这套方案不追求一开始全自动，而是分阶段推进： ```text 先标准化 PRD 再让 AI 辅助拆任务 再规范 GitLab MR 流程 最后逐步增强自动化和门禁能力 ``` 核心原则： - **先试点，不全量铺开**； - **先辅助，不直接替代人工判断**； - **先告警，不马上强阻断发布**； - **先跑通小闭环，再逐步扩大范围**。 核心变化： - PM 只维护一份 Markdown PRD； - PRD 统一进入独立 Git 项目 `product-docs`； - AI 根据 PRD、openwiki、codegraph 生成研发任务草稿； - 试点阶段 Teambition 仍作为任务管理主入口； - GitLab 先承接代码协作、MR、CI、Review； - AI Code Review 做预审建议，CODEOWNERS / 模块负责人做最终审核； - E2E 初期做告警和质量观察，稳定后再升级为门禁。 --- ## 2. 当前问题 | 问题 | 当前表现 | 影响 | |------|----------|------| | PRD 分散 | 需求分散在语雀、腾讯文档、本地文档和聊天记录中 | 版本难追踪，开发容易拿到二手信息 | | 任务拆解靠人 | PM 或开发手动拆任务 | 容易漏场景、漏依赖，估时不稳定 | | 任务和代码割裂 | 任务主要在 Teambition，代码和 MR 在 GitLab | 任务进度、代码变更、评审和上线记录难关联 | | 测试滞后 | 上线前集中回归 | 问题发现晚，修复成本高 | | 知识难沉淀 | 需求做完后，文档、代码和测试脱节 | 下一次需求仍要重新理解 | --- ## 3. 目标流程 目标流程分为“试点阶段”和“成熟阶段”。 ### 3.1 试点阶段流程 试点阶段先保守推进，不直接改变现有任务管理习惯。 ```text PM 写 Markdown PRD ↓ PRD 提交到 product-docs Git 仓库 ↓ CI 校验 PRD 结构 ↓ AI 生成研发任务草稿 ↓ PM / 技术负责人审核任务草稿 ↓ 确认后同步到 Teambition，必要时创建 GitLab Issue ↓ 开发按现有流程开发并提 MR ↓ AI Code Review 给出预审建议 ↓ CODEOWNERS / 模块负责人终审 ↓ CI 验证，E2E 初期只告警 ↓ 合入、发布、记录问题和经验 ``` ### 3.2 成熟阶段流程 当试点稳定后，再逐步增强自动化能力： ```text PRD 进 Git ↓ AI 拆任务 ↓ 自动创建或同步研发任务 ↓ Issue / MR / CI / Review 自动关联 ↓ 核心 E2E 稳定后升级为 tag 门禁 ↓ 上线后知识回流到 openwiki / codegraph ``` 主流程保留两个关键人工把关点： 1. **PM / 技术负责人审任务**：确认 AI 拆出来的任务是否符合需求； 2. **负责人审代码**：确认业务逻辑、架构设计和实现质量。 --- ## 4. 核心设计 ### 4.1 PRD 统一进 Git 新建独立 Git 项目 `product-docs`，专门管理 Markdown PRD。 建议目录结构： ```text product-docs/ ├── README.md # 仓库说明：PRD 编写规范、提交流程 ├── templates/ # PRD 模板 │ └── prd-template.md ├── prds/ # 正式 PRD │ ├── 2026/ │ │ ├── ECX-1001-coupon.md │ │ └── ECX-1002-order.md │ └── archived/ # 已归档 PRD ├── assets/ # PRD 引用的图片、流程图、附件 ├── scripts/ # 第一阶段只放轻量脚本 │ ├── validate-prd.js # PRD 结构校验 │ └── ai-task-draft.js # AI 生成任务草稿 ├── .gitlab-ci.yml # PRD 校验流程 └── docs/ # PRD 编写说明、字段规范、流程说明 ├── prd-guide.md └── section-id-guide.md ``` 第一阶段只要求 PRD 标准化，不强制 PM 熟练使用复杂 Git 操作。可以通过模板、脚手架或技术同事协助提交。 PRD 按统一模板编写，并要求： - 每个功能点有唯一编号，例如 `F-001`； - 有明确验收标准； - 有边界场景； - 有依赖说明。 ### 4.2 AI 辅助拆任务 AI 拆任务时结合三类信息： ```text PRD：描述需求 openwiki：理解业务概念和模块 codegraph：定位代码文件、类和方法 ``` AI 第一阶段只生成任务草稿，不直接创建正式任务。 任务草稿包括： - 任务标题； - 建议所属仓库； - 相关模块和文件； - 工作量预估； - 依赖关系； - 对应 PRD 功能编号； - 建议测试场景。 所有任务草稿必须由 PM / 技术负责人审核。确认后，再决定同步到 Teambition 或创建 GitLab Issue。 ### 4.3 Teambition 和 GitLab 的定位 为了贴合现状，试点阶段不强行切换任务管理工具。 | 工具 | 试点阶段定位 | 后续可能演进 | |------|--------------|--------------| | Teambition | 任务管理主入口，继续用于项目排期、工时、看板 | 如果 API 稳定，可接入自动同步 | | GitLab | 代码协作主入口，承接分支、MR、CI、Review | 成熟后可逐步承接研发 Issue 闭环 | 也就是说，第一阶段重点不是马上把所有任务迁到 GitLab Issue，而是先把 PRD、任务草稿、代码 MR 之间的关系建立起来。 ### 4.4 多方案 Code Review 代码评审不绑定单一工具，先验证一种成本最低、效果最稳定的方案。 | 方案 | 作用 | 试点建议 | | ------------------------ | ----------------------------------------------------------------------- | -------------------------------- | | Open Code Review（阿里 OCR） | 检查团队规则，例如金额计算、SQL 访问规范 | 可优先验证 | | Qodo PR-Agent | 开源 AI PR Review 工具，可接入 GitLab MR，自动生成 MR 描述、行内评论、改进建议，也支持在 MR 中通过命令触发分析 | 适合作为自托管方案验证，需确认部署成本和 GitLab 评论效果 | | CodeRabbit | SaaS 型 AI Code Review 工具，自动审查 PR / MR，给出代码问题、风险点和改进建议 | 体验完整，但需重点评估代码出内网、费用和 GitLab 支持情况 | | 自定义 CI Review 脚本 | 检查确定性强的团队硬规则 | 适合沉淀成熟规则 | | 大模型辅助 Review | 结合 PRD、Issue、diff 做上下文审查 | 不建议第一阶段强依赖 | | CODEOWNERS / 模块负责人 | 做最终人工审核 | 必须保留 | 初期 AI Review 只做建议，不阻断合并。等规则稳定、误报可控后，再把部分高置信规则升级为硬门禁。 最终合入条件建议保持保守： ```text 负责人审核通过 + GitLab CI 自动化检查通过 ``` ### 4.5 测试左移和 E2E 测试分层推进，但不一开始就强行要求完整覆盖。 | 层级 | 触发时机 | 试点阶段做法 | |------|----------|--------------| | push 检查 | 开发每次 push | 先跑 lint / 基础检查 | | MR 门禁 | 提 MR 后 | 先跑已有测试和构建 | | E2E | 预发布环境 | 初期只告警，不阻断发布 | | 人工回归 | 预发布验收 | 继续保留人工验证 | E2E 优先做 API 层核心链路，例如： ```text 登录 → 商品 → 下单 → 支付 mock → 订单状态 → 优惠券 / 库存校验 ``` E2E 分两阶段： 1. **观察阶段**：失败只通知和建 Bug，不阻断 tag； 2. **门禁阶段**：核心链路稳定运行一段时间后，再升级为阻断 tag。 --- ## 5. 落地阶段 ### 阶段 0：前置验证 目标：先确认关键能力是否可用。 验证项： - PM 是否能接受 Markdown PRD 模板； - GitLab API 是否可用； - Teambition Open API 是否支持任务创建 / 状态同步； - Open Code Review / PR-Agent 哪个更适合当前项目； - openwiki + codegraph 是否能支撑任务定位； ### 阶段 1：PRD 标准化 交付： - `product-docs` 仓库； - PRD 模板； - PRD section ID 规范； - PRD 结构校验。 目标：一个真实需求可以按模板写成 Markdown PRD，并通过校验。 ### 阶段 2：AI 生成任务草稿 交付： - AI 任务草稿生成脚本； - PM / 技术负责人审核流程； - 任务草稿到 Teambition 或 GitLab Issue 的手动 / 半自动同步方式。 目标：一个真实需求可以从 PRD 生成可审核的任务草稿。 ### 阶段 3：GitLab MR 规范化 交付： - 分支规范； - MR 模板； - CODEOWNERS； - 基础 CI； - 一个 AI Code Review 试点工具。 目标：开发 MR 能完成基础检查、AI 预审建议和负责人终审。 ### 阶段 4：核心 E2E 观察 交付： - `ecshopx-e2e` 最小骨架； - API client； - 种子数据； - 支付 mock； - 第一条下单主链 E2E； - 失败通知和产物归档。 目标：E2E 能稳定运行并提供质量反馈。初期不阻断发布。 ### 阶段 5：成熟后增强自动化 在前面阶段稳定后，再考虑： - 自动创建 GitLab Issue； - Teambition 自动同步； - E2E 升级为 tag 门禁； - AI Review 部分规则升级为硬门禁； - openwiki / codegraph 自动回流。 --- ## 6. 预期收益 | 维度 | 改造前 | 试点后收益 | |------|--------|------------| | PRD 管理 | 多处存放，版本混乱 | PRD 统一模板和版本管理 | | 任务拆解 | 人工拆，粒度不稳定 | AI 生成草稿，人审核，减少遗漏 | | 研发协作 | Teambition 任务和 GitLab 代码割裂 | PRD、任务、MR 开始建立关联 | | 代码评审 | 人工从零开始看 | AI 先给建议，负责人看重点 | | 测试节奏 | 上线前集中测 | 核心链路开始有自动化观察 | | 知识沉淀 | 做完后信息散落 | PRD、任务、代码、测试逐步可追溯 | --- ## 7. 风险点与应对 | 风险 | 具体表现 | 应对 | |------|----------|------| | PM 使用成本高 | Markdown + Git 对 PM 有门槛 | 第一阶段提供模板和脚手架，可由技术协助提交 | | PRD 模板执行不稳定 | PM 可能漏写验收标准、边界场景 | CI 先做结构校验，不做复杂语义判断 | | AI 拆任务不准 | 漏任务、错估时、判断错仓库 | AI 只生成草稿，必须人工审核 | | openwiki / codegraph 覆盖不足 | AI 无法定位模块或文件 | 无法定位时标记人工确认，不强行自动创建任务 | | Teambition API 不确定 | 自动同步可能失败或能力不足 | 第一阶段不依赖自动同步，保留人工同步 | | GitLab Issue 推进阻力 | 团队当前主要用 Teambition 管任务 | 试点阶段不强制迁移任务管理入口 | | AI Review 误报 | 影响开发体验或造成争议 | 初期只 advisory，不阻断合并 | | CI / 测试基础薄弱 | 当前测试不足，门禁容易空转 | 先跑已有检查，再逐步补核心测试 | | E2E 不稳定 | 环境、数据、支付 mock 导致失败 | 先观察告警，不直接阻断发布 | | 维护责任不清 | PRD、脚本、E2E 没人维护 | 每个模块指定 owner，试点阶段明确责任人 | | 推广过快 | 模板和流程未稳定就全量铺开 | 只选 1 个试点需求，复盘后再推广 | --- ## 8. 下一步建议 建议先做一个最小试点，不一次性推进全部能力。 优先事项： 1. 选择一个试点需求； 2. 建 `product-docs` 仓库和 PRD 模板； 3. 让一个真实 PRD 通过结构校验； 4. 用 AI 生成任务草稿，但不自动创建正式任务； 5. 人工确认任务后，同步到 Teambition 或 GitLab Issue； 6. 选一个 AI Code Review 工具做 MR 预审试点； 7. 搭 `ecshopx-e2e` 最小骨架，先只做告警观察。 第一阶段成功标准： ```text 一个真实需求可以做到： PRD 进 Git → AI 生成任务草稿 → 人工审核 → 任务进入现有流程 → MR 有基础检查和预审建议 ``` --- ## 9. 总结 DaC Workflow 的重点不是马上实现全自动，而是先把需求、任务、代码、测试和上线之间的链路建立起来。 推荐落地方式： ```text PRD 标准化 → AI 辅助拆任务 → MR 流程规范化 → E2E 质量观察 → 成熟后再自动化门禁 ``` 这样既能看到改进效果，又不会一开始就改变太多现有流程，落地风险更低。