Claude + Codex + Grok，就是王炸

三个 AI 的协作机制

我不懂编程，但一直在用 AI 做网站、做工具、整理资料。现在比较顺手的用法是：我和 Claude Code 沟通，让它调用 Codex 作图，干执行的活、功能检查。如果需要做视频或者遇到重要的事情，可以多拉一个模型讨论时，再叫 Grok。或者 codex 额度不够的时候，grok 顶上去。

这里的原理其实很简单：接通插件和 CLI 后，Claude Code 可以把任务交给 Codex 或 Grok，拿到结果后再检查、继续安排。全程不需要复制粘贴，claude 可以自己拉起 codex 或者 grok。

安装三件套：Claude Code、Codex CLI、Grok Build CLI

需要安装的是：

• Claude Code。
• Codex CLI，以及装在 Claude Code 里的 OpenAI 官方 Codex 插件。
• Grok Build CLI。我平时说的 Grok CLI，就是这个，不用装两遍。

Grok 可以后面再加。先让 Claude 和 Codex 配合起来，也够做很多事了。

如果不会安装，打开你已经能用的 Codex，或者 WorkBuddy，把下面这段发给它：

我想搭建 Claude Code + Codex + Grok 的协作环境。

先检查我的操作系统，以及电脑上已经安装的工具。
已有的直接复用。

按官方文档帮我安装和配置：
1. Claude Code。
2. Codex CLI。
3. Claude Code 的 OpenAI 官方 Codex 插件：
https://github.com/openai/codex-plugin-cc
4. xAI 官方 Grok Build CLI：
https://docs.x.ai/build/overview

需要我登录时，打开对应入口，告诉我怎么做。

完成后，用一个简单的只读任务验证：
Claude Code 能实际调用 Codex 和 Grok，并拿到结果。

把已经接通的工具、还缺的条件，以及调用方法告诉我。

注意，Codex 插件装在 Claude Code 里面。你让 WorkBuddy 帮忙安装，最后也是去 Claude Code 里使用它。

推荐使用 EGO 浏览器隔离操作

这里强烈推荐一下 EGO 浏览器。我之前在知识星球提过，用得很爽。

它可以给 AI 单独开窗口，我继续用自己的浏览器，两边不会抢来抢去。

按我的使用感受，AI 控制起来也比较顺，断连这类问题少一些。所以很多自动化、后台操作，我现在都交给它。

安装也可以让 AI 帮忙：

请根据官网 https://lite.ego.app/，
帮我安装并接通 EGO Lite 和 ego-browser 技能。

先检查当前电脑是否支持，已有安装直接复用。
需要我完成初次设置或登录时，告诉我具体步骤。

接通后，打开一个普通网页，
验证读取、点击和截图是否正常。

验证成功后，把浏览器调用方法记录到当前项目规则里。

之后，你在 EGO 里登录好公众号、飞书或者其他后台，就可以让 AI 去操作了。

比如：

我已经在 EGO 浏览器里登录了【平台】。

请进入【具体页面】，帮我完成【具体任务】。
先读取实际页面，再操作。
完成后重新查看结果，告诉我最终状态。

先梳理想法再写代码

我现在经常用微信输入法的语音输入，把想法一口气说出来。说得乱一点也没关系，先让 AI 整理。尤其是你也不懂编程的时候，别一开始就纠结技术名词。先讲清楚，你希望谁用这个东西，用来干什么。

比如在 Claude Code 里发：

先不要写代码。

我的想法是：【把想法写在这里】

请和 Codex 一起讨论：
这个东西给谁用，解决什么问题？
用户从哪里开始，经过哪些步骤，最后得到什么？
第一版先做什么，哪些可以以后再做？
如果失败、返回或者中途退出，应该怎么办？
怎样才算做成了？

如果已有项目，先读现有实现。

把需要我决定的问题集中列出来，
确认后整理成一份简洁的需求文档。

如果方案看起来很复杂，我还会补一句：

有没有成熟的现成方案？
有没有更简单、以后更容易维护的做法？
先把不同做法的成本和麻烦讲清楚，再推荐。

否则它很容易顺着你的话，把事情越做越大。

最难的网页设计怎么弄？

“做得高级一点”“漂亮一点”，这种话我也说过，但 AI 理解的漂亮，经常和你想的不一样。怎么快速让网页变得漂亮呢？我的做法是：找几个喜欢的网站，把网址和截图给它，再说清楚你喜欢哪里。是排版、颜色，还是按钮的位置。然后让它先做 Demo：

请用 EGO 浏览器查看这些参考网站：
【网址和截图】

我喜欢的地方是：【具体说明】

结合已经确认的需求，
整理主要页面、按钮和跳转关系，
再做一个可点击的 Demo。

内容换成我们自己的。
演示数据请标明，暂时不接真实业务数据。

检查需求和页面流程有没有矛盾，
完成后打开给我看。

我做的一个统一管理上网配置的后台，就是这么弄的。先让 Codex 整理需求，画线框图和跳转图，再生成 Demo。不满意的地方，截图发给 ai，然后直接说“这里不对”，“这一步多余”。比对着文档想象容易多了。确定好之后，再交给 Claude 开发。

demo 觉得满意了，具体要开发时可以这样说：

按确认好的需求开发，拆成可以逐项检查的小任务。

每完成一项，实际运行并验证。

如果安排多个窗口并行修改，
用独立分支和 worktree，避免互相覆盖文件。

完成后让 Codex 独立检查改动，
你再检查一次，发现问题就修正。

最后告诉我：
完成了什么，怎么查看，
哪些已经验证，还有哪些没验证。

分支和 worktree 不会弄也没关系，让它处理。你只需要知道，几个窗口同时改同一个项目，很容易互相修改文件，所以必须用上分支和 worktree ，不过现在 Claude Code 其实真的足够聪明 就算你不讲，他自己也会这么去做。

改已有功能怎么操作

新项目可以从头规划，但已有网站里加一个功能，最好先让 AI 看一下它和哪些地方连在一起。一个按钮背后可能同时连着登录、付款、会员权益和数据统计，只盯着这个按钮改，很容易漏掉其他地方。

这里可以补一句：

我要新增或修改的功能是：【说明需求】。
先读现有实现，查清这个改动涉及哪些页面、接口、数据、权限和已有功能。
说明哪些行为需要改变，哪些行为必须保持。
列出可能受影响的用户流程，尤其是登录、付款、会员权益和数据统计；不涉及的不用硬凑。
给出尽量小的实现方案和对应的验证办法。
确认影响范围后再开发，做完不仅验证新功能，也检查这些已有流程有没有被改坏。

推送前记录 log

每次改动并推送到 GitHub 前，先更新 CHANGELOG。代码要备份，做过什么、为什么这样做，也要一起留下来。有些方案，你知道它不是最完美的，但为了少一点复杂度，或者不和其他功能打架，最后还是选了它。这个背景不写下来，下次新开窗口，AI 看着觉得奇怪，顺手就给你“优化”掉了。结果可能 A 功能好了，B 功能又坏了。所以我会让它把当时的取舍、受影响的功能和没解决的事情一起记下来。规则文件里写要求，具体改动和背景放到 CHANGELOG 或项目现有的决策记录里。

推送到 GitHub 前，请先更新项目现有的 CHANGELOG。
记录这次改了什么、为什么这样改、涉及哪些功能、怎么验证，以及还有哪些没完成。
如果方案有取舍，说明限制和当时选择它的原因，避免下次优化时误改。

上线之前要尽量测试

前面开发时已经让 AI 检查过代码，上线前，我还会让它控制浏览器，把完整功能跑一遍。手机和电脑都要看，按钮点完怎么跳转、返回上一步会怎样，也要实际试。特别是付款、套餐和多语种。比如你有月付、年付和兑换码：先买月付再买年付，会怎么样？反过来呢？兑换码和付费套餐叠在一起，权益和到期时间会不会算错？只测“能付款”是不够的。分析工具也最好上线前就接好：Google Analytics、Search Console、Bing 站长工具和 Clarity。使用哪个账号、地区和币种怎么设置，记在项目内部的配置说明里，免得以后找不到。

请用 EGO 浏览器，对当前网站做上线前的功能测试。
按实际业务走完整流程，检查主要按钮、页面跳转、返回、失败和恢复，以及手机和电脑上的表现。
如果涉及付款、会员或兑换码，测试不同套餐、购买顺序和权益叠加，核对金额、币种、权益与到期时间。
有多语种时，检查语言切换、文案、布局和关键流程。
使用已授权的测试环境、账号和测试支付方式。
需要真实付款等额外授权时，先停在产生实际后果之前。
检查分析工具是否已接通，并在内部配置说明中记录账号、地区和币种；不要在公开报告里显示账号、密码或密钥。
逐项报告通过、失败和未验证的内容。发现问题给出复现步骤和证据，不能只说“测试通过”。

用户体验优化

AI 做的网站，有时候功能是通的，但用起来很别扭。比如：下拉选项藏得很深，按钮太小，或者点完以后不知道下一步做什么，也没有文字说明。开发者知道这里应该怎么操作，第一次进来的人可不知道。这一点在我看来是非常重要的：AI 你让它做什么功能，它就会把这个功能做出来，但它从来不考虑用户体验，从而间接影响你的流量。

我会另外开一个 Codex 窗口，让它通过 EGO 去体验。这时候为什么不用claude Code，因为claude好像安全锁得比较死，什么创建账号，复制密码之类的 它总是不愿意。

请对这个网站／功能做一次用户流程体验验收，用 EGO 浏览器实际操作，并从目标用户的角度判断它是否容易理解和使用。

检查对象：[网址或功能名称]
其他背景：[可选；已有上下文就直接使用]

先理解产品：
结合已有上下文、产品资料和页面，判断它服务谁、解决什么问题、用户在什么场景下使用，以及用户最终希望获得什么结果。区分已知事实与假设；只有缺失信息会明显影响判断时才询问，不要让我先写一份完整需求文档。

根据产品选择有代表性的用户和任务。必要时分别考虑首次使用者与熟悉产品的使用者，但不要虚构一堆无关画像。任务应描述用户想完成的事情，不要预先告诉自己应该点哪个按钮。

然后实际走流程：
从用户正常会到达的入口出发，经过必要准备、操作、结果确认，一直体验到用户获得目标结果，并知道下一步。按产品特点补充重要分支，以及合理的出错、返回和恢复场景。

操作时，以用户能看到的页面、文字和反馈为判断依据。不要用源码、隐藏接口、开发者知识或直接跳转内部地址，替用户绕过找不到入口、看不懂说明的问题。需要排查根因时，可以另行使用这些信息，但要与用户体验过程分开。

每到一个关键步骤，判断：
- 用户是否知道现在要做什么，以及为什么要做？
- 是否能发现正确入口，并理解操作会带来什么结果？
- 信息、控件和选项是否看得清、点得准，符合使用场景？
- 操作后是否能知道正在处理、已经成功或发生错误？
- 是否知道下一步；选错、失败或中断后能否恢复？

结合实际渲染和截图检查视觉与交互，不能仅凭元素存在或自动化点击成功就认定体验良好。根据目标用户的设备覆盖必要场景。

不要只证明“AI 能完成”。即使你最终找到了方法，也要记录途中需要猜测、反复寻找、试错或额外学习的地方。同时区分功能故障、体验障碍和单纯的审美偏好，不要为了找问题而找问题。

输出：
1. 简述你理解的用户、目标、测试场景，以及实际完成和未完成的范围。
2. 按影响程度列出问题。每项说明：发生位置和复现路径、截图或其他证据、用户会遇到什么障碍、可能原因、最小有效改进、如何验证改进。
3. 明确区分已观察事实、用户体验推测和待验证假设。
4. 给出最值得先解决的几项，以及值得保留的设计。

以用户完成任务的影响为优先级依据，不要只给笼统评分或“优化布局、提高体验”之类建议。没有实际操作的部分明确标为未验证。

使用已授权的测试环境和账号；未获授权的真实付款、对外发送、发布或删除，在产生实际后果前停止并注明验证边界。本次交付体验报告，除非另有授权，不直接修改产品。

这一步我希望它真的打开页面、点按钮。只读代码，很难发现“这个按钮虽然能用，但根本没人找得到”。

有流量以后，定期看数据再优化

有流量之后，我会定期把 Google Analytics、Search Console、Bing 站长工具、Clarity，包括服务器的数据交给 AI，再结合实际页面看。看用户从哪里来、在哪里退出、停留多久，最后有没有完成想做的事。

请对这个产品做一次数据驱动的用户体验巡检，结合真实行为数据和实际浏览器体验，找出最值得改善的用户流程。

产品：[网址或名称]
数据来源：[可访问的分析后台、事件数据、报告或已有上下文]
复盘周期：[指定周期；未指定时自行选择并说明]

先理解产品服务的用户、核心任务和成功结果，再检查现有数据能回答什么问题。不要把增加点击次数当作默认目标，应优先考虑用户能否更顺利、更少困惑地完成有价值的任务。

先确认数据是否可信、可比：
说明时间范围、用户或事件口径、样本量，以及已知的漏记、重复记录、内部测试流量、版本或流量来源变化等影响。数据不足时明确限制，不要把没有记录当作没有使用。

根据现有数据分析：
- 用户通常从哪里进入，经过哪些步骤，最终是否完成目标？
- 哪些任务经常发生，哪些步骤出现退出、失败、重复尝试或绕路？
- 新老用户、不同角色、设备或来源是否有重要差异？
- 相比上次巡检，哪些问题改善、恶化或仍未得到验证？

点击量高不一定代表价值高，也可能是反复尝试或操作低效；点击量低不一定代表不重要，也可能是入口难找、适用人群少、只需使用一次或记录不完整。比较时尽量考虑有资格使用、实际看到入口的人数，以及使用后的任务结果。

如果只有汇总数据，只描述它能支持的群体趋势；没有连续事件或会话证据时，不声称还原了某个真实用户的完整过程。不要仅凭行为数据断言用户的动机或满意度。

从最重要的数据异常和核心任务中选择代表性流程，用 EGO 浏览器实际体验。检查入口、信息层级、说明、操作反馈和下一步引导，判断页面表现是否支持对数据的解释。必要时结合已有用户反馈或会话证据，不虚构这些材料。

提出改进时，先说明：
用户的问题是什么，证据是什么，还有哪些可能解释，怎样验证。

对于突出常用入口、折叠低频功能、调整菜单或简化流程等建议，同时考虑任务重要性、使用场景、可发现性和用户已有习惯。不要机械地按点击次数重排整个产品。

输出一份简洁、可执行的报告：
1. 本次最重要的发现，以及数据和检查范围。
2. 优先改进项：证据、受影响用户和任务、可能原因、建议、置信程度。
3. 每项建议的验证办法：预期改善什么，观察哪些指标，哪些体验不能因此变差；数据允许时采用小范围试验或 A/B 测试。
4. 与上次相比的变化、仍待验证的问题，以及最少需要补充的行为记录或用户研究。

把观察事实、原因假设和改进建议分开。没有足够证据时保留假设，不强行下结论；没有发现重要问题时如实报告，不凑数量。

保存本次报告和比较口径，供下次巡检使用。定期运行时，仅在出现重要新问题、明显变化或需要决策时重点通知，避免重复发送相同结论。除非另有授权，不直接修改页面、埋点配置或业务数据。

有些按钮点击很多，可能恰恰是因为用户点了没反应，一直在重试，只看数字，很容易改错。

多任务窗口总结收尾

我现在会同时开几个项目、每个项目同时跑很多任务。窗口一多，很多时候有点乱，所以当每个人窗口的事情都做完的时候，新开窗口，让 claude 做个收尾。

请对当前项目做一次开发收尾，重点核对最近 3 天的 Claude Code 任务，同时检查更早遗留的未完成事项、分支和 worktree。

1. 核对完成情况
结合可读取的任务记录、实际代码、Git 提交、PR 和测试结果，找出遗漏、未提交、未推送、未合并或未验证的工作。明确区分“开发完成、已合并、已部署”；无法读取或验证的部分如实说明。

2. 合并与同步
对需求明确、审查和必要测试通过的已完成改动，按项目既有流程合并到目标分支并同步 GitHub，核对最终状态。存在冲突、测试失败或用途不明的改动，保留并说明原因，不为收尾强行合并。

3. 清理与释放空间
清理已完成、已合并且不再使用的临时分支和 worktree。删除前检查未提交改动、未跟踪及被忽略的重要文件、未保留的提交，以及是否仍有任务或服务使用该目录。
检查相关依赖、构建产物和缓存的占用，仅清理确认可重建且未被使用的内容。保留主工作目录、必要配置和开发记录，不强制删除用途不明的内容。

4. 更新记录并交接
更新项目现有 Log/CHANGELOG，按实际成果补齐改动、验证结果、提交或 PR、部署状态和剩余事项。
最后简要报告：已完成的收尾、保留内容及原因、清理前后磁盘空间，以及下一步需要处理的事项。

请实际执行符合上述条件的收尾；只有影响正确性或重要后果的信息缺失时再问我。不把部署或扩大功能修改默认包含在本次收尾中。

上面这段是多窗口收尾。如果要换电脑继续开发，再多做一步，把整个项目交接好。

如果要换电脑进行开发

因为我买的 mac mini 内存太小，多项目开发经常卡死，所以有的时候我要把某个项目从一台电脑移到另一台电脑上面。如果要换电脑继续开发，因为有些改动还在别的分支、worktree，或者根本没有提交。旧电脑先把这些查清楚，整理一份 HANDOFF.md，新电脑再接着做。

在旧电脑的 Codex 或 Claude Code 里发：

我要换电脑继续开发，请完成整个项目的迁移交接，不要只整理当前窗口。
检查各分支、worktree、未提交改动，以及能读取到的其他窗口任务状态。其他窗口通常已经审查过，不必重复全面审查，重点确认有没有未完成、未同步或遗漏的工作；无法读取的窗口上下文请明确说明。
将启动方法、环境配置要求、各任务进度、关键决定、已知问题和下一步整理到根目录的 HANDOFF.md。把应保留的代码和文档提交并推送到 GitHub，确认同步成功；未完成的工作也要妥善保存，不要为了交接强行合并或丢弃。密钥和本地专用配置不要上传，列出需要另外迁移的内容。
最后给我一段新电脑可直接使用的接续提示词，包含仓库地址、相关分支和交接文档位置。
普通细节自行处理，只有缺少必要信息时才问我。

我现在觉得，这三个工具配合起来最方便的地方，就是不用什么都自己查、自己搬、自己检查。想不清楚，让它们一起讨论；确定好了，让它们去干；做完换一个来挑问题。

JOTO 企业落地观察

• 企业若采用此类多模型协同架构，需重新定义 RAG 知识工程的边界——知识库不再仅服务于单模型推理，而需适配跨模型调用链中的上下文传递、格式转换与结果校验，这对向量检索的 schema 设计和元数据标注提出更高要求。
• 这类系统在智能体工程中天然形成「协调-执行-兜底」三层职责分离，但企业部署时必须预设明确的 fallback 策略与超时熔断机制，否则 Codex 额度耗尽或 Grok 响应延迟将导致整个工作流阻塞，而非优雅降级。
• 当 EGO 浏览器被用于自动化操作真实业务后台（如飞书、公众号），其与企业 SSO、MFA、审计日志系统的兼容性将成为 FDE 驻场共创阶段的关键验证项，不能仅依赖 UI 自动化能力。
• 多窗口并行开发模式虽提升效率，但对企业级 GitOps 流程构成挑战：分支/ worktree 的生命周期管理、CHANGELOG 的机器可读性、HANDOFF.md 的结构化程度，均需纳入 AI 工程化治理范畴，而非仅靠提示词约束。