数字员工

​

方案架构

本方案以 GitHub 为唯一研发事实源产生事件，GitHub Actions 完成事件过滤与安全转发，QoderWake API 自动任务唤醒职责独立的 Waker，Waker 再将代码、Review、Bug、测试证据和 Release 回写 GitHub。角色行为由 BIBLE 长期约束，任务以 isolated 模式运行并通过 GitHub marker 延续业务状态。

​

方案优势

​

优势 01：事件触发，降低空转与竞态

需求状态变化、PR revision 更新和代码合并都有明确事件。只有发生有效变化时才唤醒 Waker，避免定时任务扫描带来的空转和“扫描到一半事实又变化”的竞态。

​

优势 02：一个角色，一个责任边界

开发、评审、测试、发布使用独立 Waker、独立 BIBLE 和独立 API 自动任务。Developer 无权给自己 PASS，Reviewer 不修改代码，Tester 不伪造交付，Release 不替用户合并。

​

优势 03：AI 输出回写业务系统

代码、测试、评论、Bug、Tag 和 Release 都回写 GitHub。聊天记录用于观察执行过程，GitHub 才是下一个角色能够读取、用户能够审计的事实。

​

优势 04：机器执行与人工决策分层

Waker 自动完成分析、编码、测试和材料准备，但代码合并与正式发布仍由用户确认。AI 提升执行效率，人保留风险责任。

​

优势 05：技术幂等与业务幂等同时存在

调用层的 wakeSessionUniqueId 防止同一次投递重复执行；业务层以 head SHA、merge SHA 和 GitHub marker 判断工作是否已经完成。即使平台重试或重复事件到达，Waker 也会重新核验并安全 NOOP。

​

优势 06：凭据只存在于 Secret 边界

PAT 和 API 地址只存储在 GitHub Actions Secrets。启动器隐藏输入和加密写入，Workflow 只在运行时注入，错误日志不会输出响应正文或凭据。

​

业务场景

​

场景 01：Release Waker 创建迭代与发布边界

创建迭代后自动切出迭代分支，测试通过后准备发布 PR，用户合并后完成 Tag 与 Release。

• 客户问题：迭代边界和发布材料常依赖人工准备，容易遗漏或延迟。
• 触发条件：创建迭代，或 Tester 完成复测。
• Agent 动作：从 main 创建 iteration/* 分支；汇总需求、Bug、PR 和 CI 证据创建发布 PR；用户合并后创建 Tag、GitHub Release 并关闭 Milestone。
• 交付结果：独立迭代分支、发布 PR、Tag、Release 和关闭的 Milestone。
• 完成定义：迭代有清晰边界，发布材料完整且可审计。
• 人工闸口：用户确认合并发布 PR。

​

场景 02：Developer Waker 从需求事实出发完成工程交付

被需求进入待开发或 Bug 回流事件唤醒，读取事实后完成代码、测试并创建代码 PR。

• 客户问题：AI 只在被主动唤起时才工作，上下文需要人工反复解释。
• 触发条件：需求进入待开发，或 Bug 回流。
• Agent 动作：重新读取需求、验收标准、评论和现有 PR；从 iteration 分支创建 demo/feature/* 或 demo/bugfix/*；补充测试、完成最小实现，运行 npm test 与 npm run lint；创建或更新代码 PR，写入测试证据、关联 Issue 和交付 marker。
• 交付结果：包含实现代码、测试、关联 Issue 和交付 marker 的代码 PR。
• 完成定义：代码 PR 通过本地测试并与需求关联。
• 人工闸口：用户查看差异后合并代码 PR。

​

场景 03：Reviewer Waker 对确定 revision 独立评审

只监听 PR 创建和新提交事件，以 head SHA 为单位完成独立评审并回写结论。

• 客户问题：人工评审容量有限，AI 评审结论如果停留在聊天窗口则无法审计。
• 触发条件：PR 创建，或源分支产生新提交。
• Agent 动作：以 head SHA 为评审单位，读取完整 diff、关联需求和 CI，在独立工作区执行测试；存在阻断问题时写入 CHANGES_REQUESTED；通过时留下 [QW-REVIEW][sha][PASS]。
• 交付结果：回写到 PR 的评审结论，包含测试、Lint、CI、验收标准和 Diff 范围。
• 完成定义：Reviewer PASS 且 CI 通过，等待用户合并。
• 人工闸口：用户确认合并代码 PR。

​

场景 04：Tester Waker 验收失败自动回流开发

代码合入迭代分支后独立验收，发现问题时创建 Bug 并自动唤醒 Developer 修复。

• 客户问题：测试发现问题后往往只在聊天中通知，证据不完整，修复后难以追踪复测。
• 触发条件：代码合入 iteration 分支。
• Agent 动作：独立验收；测试失败时创建包含复现步骤、期望、实际、日志和父需求的 Bug，并唤醒 Developer 进入修复链路；复测通过后 Bug 和 Requirement 进入验证完成状态。
• 交付结果：Bug Issue 或复测通过状态。
• 完成定义：缺陷回到同一条 Developer → Reviewer → Merge → Tester 链路并完成复测。
• 人工闸口：用户确认合并修复后的代码 PR。

​

参考实践

​

实践名称

QoderWake × GitHub：事件驱动研发协作参考实践

​

实践背景

• 客户或行业：面向使用 GitHub 作为研发事实源的研发团队。
• 原有流程：状态同步依赖人工提醒，上下文需要反复复制，AI 生成结果停留在聊天窗口。
• 核心问题：事件无法自动触发 AI 执行，单一 Agent 缺乏职责分离，自动化过程缺乏可审计性。
• 试点范围：开源参考实现仓库覆盖 Release、Developer、Reviewer、Tester 四个角色和一条完整迭代。

​

实践方案

• 事件如何进入：GitHub 中 Milestone、Issue、PR、CI 等状态变化产生事件，例如需求进入待开发、PR 创建或更新、代码合入 iteration 分支、复测通过等。
• 控制层如何路由：GitHub Actions 监听事件、过滤噪声、准备最小上下文，并把事件安全转发给 QoderWake API 自动任务；PAT 从 GitHub Secrets 注入请求头。
• Agent 如何执行：QoderWake API 自动任务以 isolated 模式运行，唤醒职责独立的 Waker；Waker 每次执行都重新读取 GitHub 事实，由 BIBLE 约束可用工具、标准工作流和禁止动作。
• 结果如何回写：Waker 把代码、Review 结论、Bug、测试证据、Tag 和 Release 回写 GitHub，形成下一个角色可读取、用户可审计的事实。
• 失败如何回流：Reviewer 发现阻断问题时写入 CHANGES_REQUESTED 并把工作交还 Developer；Tester 验收失败时创建带复现证据的 Bug，自动唤醒 Developer 重新进入修复链路。
• 人工在哪些节点决策：代码 PR 合并与发布 PR 合并由用户确认；Release Waker 不替用户合并，只准备发布材料。

​

实践流程

​

实践结果

• 完成的闭环：从需求进入迭代到版本发布的完整接力，包含开发、评审、测试、发布和 Bug 回流。
• 已验证能力：事件驱动唤醒、四角色职责分离、事实回写 GitHub、人工 Merge 门禁、幂等执行。
• 数据或证据：示例运行截图及运行记录可参考，每次重新启动会生成新的唯一 Iteration 与编号。
• 后续演进方向：通过替换事件适配层和事实读取工具，迁移到企业自有的 DevOps 平台。

​

推荐产品组合