跳转到主要内容

Documentation Index

Fetch the complete documentation index at: https://docs.smew.ai/llms.txt

Use this file to discover all available pages before exploring further.

​
Codex 协同开发指南

这篇文档介绍一种更适合 SmewAI 当前能力边界的工作方式：一个主会话负责规划，另一个 Codex 会话负责执行与复核。

​
1. 为什么推荐双会话协同

当任务稍复杂时，把“想清楚”和“动手改”拆开，通常更稳：
  • 主会话负责理解需求：拆任务、定范围、识别风险
  • 执行会话负责落地：改代码、跑测试、修报错
  • 复核会话负责审查：独立检查改动是否遗漏问题
这种方式的核心价值是：上下文更清晰、每个会话目标更单一、回滚和追踪也更方便。

​
2. 基本工作流

​
步骤一：先在主会话写清任务

建议至少写明这四件事：
  1. 目标是什么
  2. 改哪些文件
  3. 不要动哪些地方
  4. 如何验证完成

​
步骤二：把实现任务交给执行会话

适合交出去的任务包括：
  • 修一个明确的 bug
  • 补一组测试
  • 做一个边界清晰的小功能
  • 清理一个局部模块

​
步骤三：完成后做一次独立复核

复核时重点看：
  • 是否真的满足最初目标
  • 是否改出了不该碰的文件
  • 是否漏跑测试或构建
  • 是否引入新的配置风险

​
3. 推荐提示词模板

​
让执行会话接手实现

请在当前仓库中完成下面这个任务：
1. 目标：...
2. 允许修改的文件：...
3. 不要修改的内容：...
4. 验证方式：...
完成后请总结改动，并说明你实际运行了哪些验证。

​
让复核会话做审查

请审查当前改动，重点关注：行为回归、边界条件、遗漏测试、配置错误。
如果发现问题，请按严重程度列出，并给出文件位置。

​
4. 什么时候适合这样做

  • 你想减少一个会话里塞太多上下文
  • 你需要把规划、实现、审查分开
  • 你要并行处理多个相互独立的小任务

​
5. 什么时候不适合

  • 只是改一两行字
  • 问题非常依赖长期对话上下文
  • 需求还没有收敛，连目标都不清楚

​
6. 实战建议

  • 任务描述要具体，避免“帮我优化一下”这种宽泛表述
  • 执行会话结束后，先看 diff，再看总结
  • 复杂任务先拆成 2 到 4 个子任务，不要一口气全丢出去
  • 同一轮里最好明确谁负责实现、谁负责复核

​
7. 常见问题

​
一个会话能不能同时规划又执行？

可以，但任务越复杂，混在一起越容易丢上下文。只要你发现自己在来回切换“想方案”和“修细节”，就值得拆会话。

​
复核会话应该看什么？

优先看高风险点：接口变更、共享配置、测试覆盖、用户可见行为。

​
会不会更耗时？

简单任务会稍微增加一点切换成本；中等以上任务通常更省心，因为返工更少。