这篇指南用一条发布公告 Issue 演示完整流程。任何需要明确负责人、状态和评审人的 任务,都可以采用同样做法。

完成后应该看到什么

最后的 Issue 应该能让人轻松找到原始请求、负责人、Agent 运行、产物、评审评论 和后续工作。

开始前

准备好:
  • 一个能清楚描述的结果
  • 一份简短的验收条件
  • 一个负责执行的人或 Agent
  • 只有需要独立判断时才添加评审人

推进任务

  1. **创建 Issue。**使用“起草发布公告”这样的具体标题,写明读者、必需内容、 输出格式和判断标准。
  2. **还有决定没做完时,留在“待整理”。**不要为了让看板显得忙碌而分配模糊任务。
  3. **移到“待办”,并指定一个负责人。**准备好的 Issue 分配给 Agent 后可以自动 开始,不要再手动启动一份重复运行。
  4. **跟进执行。**负责人工作时,Issue 会进入“进行中”。打开 Agent 运行查看进度、 错误或产物。
  5. **附上结果。**从 Issue 链接 Markdown 文件、预览、截图、测试结果或其他交付物。
  6. **移到“评审中”。**只有其他人已经可以判断真实结果时,才进入评审。
  7. **记录结论。**评审人接受结果、要求具体修改,或说明阻塞原因。接受后可以完成 Issue;要求修改会把下一步交回负责人。
普通评论只会保存上下文。需要某个 Agent 处理评论时,直接提及它。提及会唤醒 Agent,但不会更换 Issue 负责人。

检查结果

假装自己从没见过这项任务,重新打开已完成 Issue。你应该能回答:
  • 当时要求什么?
  • 谁完成了工作?
  • 结果在哪里?
  • 做过哪些检查?
  • 为什么被接受?
  • 还有后续任务吗?

任务没有顺利结束怎么办

  • **运行失败:**保持 Issue 打开,关联失败运行,理解错误后再重试。
  • **必须等待其他人或依赖:**移到“阻塞”,并写明怎样才能解除。
  • **结果不完整:**要求修改,不要接受。
  • **评审一直没有发生:**保持“评审中”,交回已指定评审人。
  • **完成后又发现新工作:**用评论说明原因后重新打开,或创建单独的后续 Issue。
状态速查见Issue 状态