158 lines
7.5 KiB
Markdown
158 lines
7.5 KiB
Markdown
|
# 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**：
|
|||
|
|
```bash
|
|||
|
|
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 + 改标签**：
|
|||
|
|
```bash
|
|||
|
|
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 的轮询脚本会自动找到第一个未勾选的项来处理。
|