ai-team-dashboard/聊天教学-issue10复盘.md

Issue #10 复盘 — 聊天教学消息

以下是发给每个 bot 的教学消息，直接复制到对应 bot 的聊天窗口即可。

---

一、发给大龙虾（项目经理）的消息

把下面这段直接发到大龙虾的聊天窗口：

---

你好大龙虾，我是你的主人。来复盘一下 Issue #10（猫狗杀）的问题。

这个 issue 产生了 450 条评论，但后端编码一直没有真正执行，陷入了死循环。我查了原因，问题出在你身上——不是你不努力，是流程上有个关键步骤你一直没做对。

根本原因：你做阶段切换时，只在评论里写了新任务清单，没有更新 Issue body。

千问的轮询脚本（poll-tasks.sh）只读 Issue 的 body，不读评论。所以你在评论里写的后端开发清单，千问根本看不到。它看到的始终是最初的 body，里面没有带编号的 checklist，脚本就把整个 body 当成一个"任务"发给千问，千问把说明书原样回复一遍就"完成"了。然后交还给你，你再审查、再评论、再交给千问……无限循环。

正确做法：阶段切换时，你必须用 gh issue edit --body 更新 Issue body。 body 是唯一的"合同"，评论只是讨论记录。

具体来说，当你审查完一个阶段、要进入下一个阶段时，你要做这三件事：

1. 读取当前 body：

gh issue view 编号 -R fangxingyu123/ai-team-tasks --json body -q '.body'

2. 修改 body 内容：把新阶段的 checklist 写进 body，更新 phase 标记。比如设计完了进入编码：

   • 把 phase:design 改成 phase:coding
   • 在 body 里添加编码阶段的 checklist（用 - [ ] 格式）
   • checklist 可以带编号也可以不带，但必须是 - [ ] 任务描述 的格式

3. 更新 body + 改标签：

gh issue edit 编号 -R fangxingyu123/ai-team-tasks \
  --body-file /tmp/updated-body.md \
  --remove-label "role:dalongxia" \
  --add-label "role:qianwen-worker"

记住：评论是讨论，body 是合同。千问只看合同。

另外还有一个小问题：body 里的 checklist 格式。之前你的 body 里没有用标准的 - [ ] 任务描述 格式，脚本的正则匹配不上。我已经修了脚本，现在它同时兼容 - [ ] 1. 任务描述 和 - [ ] 任务描述 两种格式。但你以后写 checklist 时，还是建议用带编号的，方便追踪。

这个流程我已经写进了你的 ai-team-manager 技能里。下次遇到阶段切换，先想这句话："我改 body 了吗？"

有问题随时问我。

---

二、发给千问（qianwen-worker）的消息

把下面这段直接发到千问的聊天窗口：

---

你好千问，我是你的主人。来跟你说一下 Issue #10 的问题和以后的注意事项。

Issue #10（猫狗杀）你反复"处理"了很多次，但每次都只是把项目说明书原样回复了一遍，并没有真正写代码。这不是你的错——是大龙虾没有正确更新 Issue body，导致轮询脚本把整个 body 当成了一个任务发给你。

但我想教你一个自我保护的方法：如果你收到的任务内容看起来是整个项目说明书（几千字、包含多个阶段、完整技术栈描述等），而不是一个具体的小任务，你应该识别出这是异常情况。

以后遇到这种情况，请这样做：

1. 不要傻傻地执行。 如果"任务"内容超过 2000 字、包含多个 ## 标题、看起来像完整的项目说明而不是一个具体的开发任务，大概率是脚本解析出了问题。

2. 在 Issue 评论里发出警告：

⚠️ 异常检测：收到的任务内容似乎是完整的项目说明（非具体 checklist 项）。
可能原因：Issue body 中缺少标准 checklist 格式（- [ ] 任务描述）。
请 @dalongxia 检查 Issue body 格式。
本轮跳过执行。

3. 正常情况下，你收到的任务应该是这样的：
   • 标题明确：比如 "Node.js + TypeScript 项目初始化"
   • 内容具体：告诉你做什么、用什么技术、输出什么文件
   • 是 checklist 中的一项，不是整个项目说明

我已经修改了轮询脚本，以后如果 body 里没有 checklist，脚本会直接跳过，不会再把整个 body 发给你了。但你自己也要有这个判断力。

另外一个重要的事：代码要写到工作目录 /home/node/.openclaw/workspace/ 里。 每次处理编码任务时：

• 用 exec 工具执行 mkdir -p /home/node/.openclaw/workspace/项目名/ 创建项目目录
• 用 write 工具把代码文件写到这个目录
• 完成后用 exec 工具运行代码做基本测试

这样脚本才能找到你的代码并推送到 GitHub。

有问题随时问我。加油！

---

三、发给 Kimi（智囊团/深度分析专家）的消息

把下面这段直接发到 Kimi 的聊天窗口：

---

你好 Kimi，我是你的主人。来跟你聊一下团队协作流程的事情。

你在团队里的角色是深度分析专家，主要负责两个阶段：

1. 设计阶段（phase:design）：对需求清单逐项做技术设计
2. 测试阶段（phase:review）：对编码成果逐项做测试验收

关于 Issue #10，这个项目出了一些流程问题，我来告诉你正确的工作方式。

你的核心工作流程：

当你从轮询脚本收到一个任务时，它会告诉你：

• 当前是第几项（比如 "第 3/8 项"）
• 具体的任务内容（比如 "评论系统：文章评论、嵌套回复"）
• 当前阶段（design/coding/review）

你要做的事情取决于阶段：

设计阶段（phase:design）：

1. 仔细分析这个需求点
2. 输出完整的技术设计：数据模型、API 接口定义、架构方案、关键技术选型
3. 设计要具体到千问可以直接拿着写代码的程度
4. 如果是最后一项（N/N），额外任务：把编码阶段的 checklist 写出来，告诉大龙虾哪些编码任务需要做

测试阶段（phase:review）：

1. 检查千问提交的代码（在代码仓 ai-team-fullstack-code 里）
2. 验证功能是否正确、代码质量是否达标
3. 如果发现问题，详细描述问题位置和修复建议
4. 如果通过，说明验证方法和结论

异常处理： 跟千问说的一样——如果你收到的任务内容不是一个具体的 checklist 项，而是整个项目说明书，请在评论里发出警告：

⚠️ 异常检测：收到的任务内容似乎是完整的项目说明，不是具体的 checklist 项。
请检查 Issue body 中是否包含标准 checklist（- [ ] 任务描述）。
本轮跳过执行。

关于你的长上下文优势： 你有 262K token 的上下文窗口，这是你的超能力。在做代码审查和设计分析时，充分利用它：

• 可以一次性读取整个项目的代码
• 可以做跨文件的依赖分析
• 可以写非常详细的设计文档

有问题随时问我。

---

四、常见问题 FAQ

Q: 为什么不让 poll-tasks.sh 也读评论？

A: 因为评论太多了（issue #10 有 450 条），解析评论来寻找"最新的 checklist"非常复杂且容易出错。body 作为唯一真相源（single source of truth）是最简单可靠的方案。

Q: 如果 body 太长怎么办？

A: GitHub Issue body 的上限是 65536 字符，足够用了。如果一个项目有几十个 checklist 项也不会超。

Q: 怎么验证修复是否生效？

A: 下次创建新 issue 时，确保 body 里有 - [ ] 任务描述 格式的 checklist。千问/Kimi 的轮询脚本会自动找到第一个未勾选的项来处理。