以后想让多个 AI 一起做

这页先收藏，不需要现在就学。普通改字、改样式和明确的小功能，继续让一个 AI 完成会更快；只有任务明显复杂，或者你想在推送前多一道检查时，才值得拉第二个 Agent。

你决定方向、取舍和最终验收 └── Codex 主负责人接手项目、规划、实现、整合和提交 └── Claude Agent 讨论方案、独立实现或审查

什么情况值得使用

当前事情	建议	原因
改文字、颜色或明确的小 bug	不用多 Agent	沟通成本可能比修改本身还高。
复杂功能有几种实现方向	让 Claude 参与方案讨论	多一个独立视角，能更早发现遗漏和错误假设。
代码已写完，准备提交或上线	让 Claude 做 check	这是最稳、最适合日常使用的方式。
PRD 和设计已确认，任务较大	可以让 Claude implement	Codex 仍负责监督范围、复查和最终提交。
能拆成互不重叠的模块	可以并行	每个 Agent 负责不同文件或模块，避免互相覆盖。
两个 Agent 都要改相同文件	不要并行	容易产生冲突，也很难判断谁的改动才是最终版本。

最推荐：让 Claude 做第二次检查

这是以后第一次尝试多 Agent 时应该使用的方式。

使用 $trellis-channel，拉一个 Claude check agent 审查当前改动。

请把当前 Trellis 任务、PRD、设计、实施计划、相关项目规范和未提交差异提供给它。
Claude 负责检查需求是否完整实现、代码质量、跨层遗漏和测试风险；
可以修复明确且机械的小问题，但不得提交、推送或改变已经确认的产品方向。

Claude 完成后，由当前 Codex 汇总发现、重新运行检查并向我汇报。
最终提交和推送仍由当前 Codex 在我确认后完成。

想听另一个 AI 的方案意见

适合方案有明显取舍、或者你担心 Codex 一开始就走错方向时。一次回答不算真正讨论，主 Agent 应继续追问边界、风险和反对意见。

使用 $trellis-channel，拉一个 Claude agent 参与当前方案讨论。

先把现有代码、Trellis PRD、已确认的领域术语和约束提供给它。
请它独立判断：
1. 当前方向是否复用了项目已有机制；
2. MVP 范围是否过大或遗漏关键部分；
3. 数据、接口和用户体验可能在哪里出问题；
4. 哪些测试必须在发布前通过；
5. 请它主动反对当前方案，指出最可能失败的地方。

当前 Codex 负责与 Claude 进行多轮追问，最后只向我汇报明确分歧、推荐结论和需要我决定的事项。
不要在我确认方案前开始实现。

任务很大时让 Claude 实现

只有 PRD、设计和实施计划已经确认时再用。Claude 负责执行，Codex 负责监督和验收。

使用 $trellis-channel，拉一个 Claude implement agent 执行当前 Trellis 任务。

先向它提供已经确认的 PRD、设计、实施计划、implement.jsonl 和相关项目规范。
Claude 只能实现确认范围内的内容，不得自行扩大需求，不得提交、推送或合并。
遇到需要产品判断的地方必须停下来汇报，不能自行猜测。

Claude 完成后，由当前 Codex 检查全部差异、运行项目测试并进行真实页面或真机验收。

“临时拉 Claude”和“给项目增加 Claude”不是一回事

想做什么	实际含义	是否需要改项目配置
临时让 Claude 审查或实现一次	Trellis channel 启动一个 Claude worker，完成后结束	不需要生成 `.claude/`；只要本机 Claude Code 已安装并登录。
以后直接从 Claude Code 打开并接手整个项目	给该项目补充 Claude 的 Trellis commands、hooks 等配置	需要在项目中增量初始化 Claude。

需要第二种方式时，不用自己切目录，直接对 AI 说：

请保留当前项目已有的 Codex 和 Trellis 配置，先检查 Git 状态和现有平台，
再使用 trellis init --claude --skip-existing -u macdu 增量补充 Claude Code 支持。

不要覆盖用户修改过的 Trellis、Codex 或项目文件。
完成后运行 trellis platforms，汇报新增内容和仍需我确认的 Claude hooks。

它在背后大概怎么工作

你不需要运行下面这些步骤，主 Agent 会通过 $trellis-channel 处理：

为这次协作创建一个项目级 channel。
按 check 或 implement 角色启动 Claude worker。
把 PRD、设计、项目规范和本次需要的文件明确交给它。
向 Claude 发送任务并等待 done 或错误事件。
读取 Claude 的最终答复，由主 Codex 重新检查和整合。
worker 空闲或超时后结束，不会永久占着一位 Agent。

暂时不要自动化

Trellis 还提供 channel-driven-subagent-dispatch 工作流，可以让实现和检查更频繁地自动交给 worker。但现在保持默认工作流更适合你：需要时手动点名 $trellis-channel，过程更容易理解，也能控制额度和文件冲突。

以后确实频繁使用多 Agent 时，先让 AI 只评估，不要直接切换：

请检查我最近的 Trellis 任务和多 Agent 使用频率，
评估是否值得从当前工作流切换到 channel-driven-subagent-dispatch。

先说明它会改变哪些步骤、额度消耗、失败恢复方式和文件冲突风险，
给出保持现状与切换后的对比；在我明确确认前不要修改工作流。