跳到主要内容

Codex 实践记录

这篇记录主要围绕一次 Codex 实战展开：尝试复刻一个最近很火的 Web App，但目标并不是 1:1 临摹，而是验证几个更实际的问题：

  • Codex 是否适合从 0 到 1 搭一个前端页面
  • 它在任务拆分、多 agent 协作、视觉方向探索上到底能做到什么程度
  • 人在流程里应该扮演“下命令的人”，还是“做决策的人”

结论先写在前面：Codex 更像一个可以分工的工程代理，不只是代码补全工具。
如果目标明确、约束清楚，它推进速度很快；如果需求本身含糊，它会持续产出“看起来在前进”的结果，但方向可能并不对。

一、起点：先给明确参考​

最近突然爆火的 Web App，先拿 Codex 尝试做个仿品：

在第一轮操作里，并没有直接让 Codex“随便做一个差不多的”，而是先给参考、给方向、给预期。
原因很直接：Codex 在执行层很强，但在审美和产品判断上不应该被默认信任。

给出方向后的效果如下：

二、为什么不能直接“照着抄”​

做到这一步以后，一个明显问题马上出现了：如果继续沿着参考图往下生成，最终产物很容易落到“高相似复刻”。

考虑到侵权和同质化风险，后续规划必须做完整调整：

这里比较关键的一点是，不要把“仿品”理解成最终目标。
更合理的做法是：

  • 先用现成热门产品验证信息架构和视觉节奏
  • 再让 Codex 基于这个参考做“风格偏移”
  • 最后把页面、文案、配色、插图和交互都替换成自己的表达

也就是说，参考物更像是“结构样板”，不是“交付标准”。

三、先规划，再执行​

这里使用了 /plan 进入规划模式，让它先做任务拆分和需求理解，而不是一上来就开始改代码：

这一点很重要。

如果你直接说“把这个页面做出来”，Codex 往往会立刻进入实现态，开始创建组件、写样式、铺页面。
问题在于，一旦没有先把需求边界讲清楚，后面的返工成本会很高。

更稳妥的流程通常是：

  1. 先让它总结目标和限制条件
  2. 再让它拆分出页面结构、技术任务、素材任务、风险点
  3. 最后才进入实际编码

这样你看到的不是“它写了什么”，而是“它准备怎么做”。

四、让 Codex 使用多 agent 模式​

在任务边界比较完整以后，再要求 Codex 使用多 agent 模式执行任务：

多 agent 的价值，不在于“同时开很多窗口”，而在于它能把一个复杂任务拆成几类不同职责：

  • 有的 agent 负责只读探索，梳理代码结构和可落地方向
  • 有的 agent 负责具体实现
  • 有的 agent 负责视觉素材、文案、页面结构等侧向任务

如果任务本身天然可以并行，这种方式效率会明显高于单线程对话。

五、怎么看 /agents​

使用 /agents 可以看到当前子 agent 的分工。
这里一个很重要的细节是：中括号里的 [explorer] 本质上属于 只读规划任务。

比如第四个视觉资产 agent，它的原始职责大概是这样：

只读规划任务，不要编辑文件。
目标：为 WBTI 新页面规划视觉风格和图片资产生产方案。

这说明一件事：并不是所有 agent 都应该直接写代码。

很多时候，让某个 agent 只做下面这类事情，反而更有效：

  • 评估现有页面结构是否合理
  • 规划视觉风格路线
  • 提炼素材需求清单
  • 找出实现前应该确认的风险

如果一开始就让所有 agent 全部进入“写文件”状态，结果往往会失控。

六、主 agent 负责收口​

即使已经拆了多个子 agent，真正负责把事情做完的，仍然应该是主 agent。

如果某个任务没有实施完成，或者某个子 agent 给出的结果不够准确，仍然可以继续通过主 agent 对话来补充和纠偏。

这一层非常像项目里的负责人：

  • 子 agent 负责局部产出
  • 主 agent 负责汇总、排序、决策和继续推进

所以在实际使用里，不要把多 agent 理解成“自动完成一切”。
更准确地说，它是在帮你搭一个临时项目组，而你仍然要承担产品经理和技术负责人角色。

七、这次实践的几个判断​

1. Codex 很适合做“有方向的实现”​

如果你已经知道：

  • 页面大概要长什么样
  • 技术栈是什么
  • 哪些部分可以参考，哪些必须避开
  • 当前阶段是规划、实现还是重构

那么 Codex 的效率会很高。

2. 它不适合代替你做产品判断​

例如：

  • 这个页面是不是和原产品太像
  • 这个视觉风格是不是有品牌辨识度
  • 这个信息层级是不是适合你的用户

这些问题，不能指望它自己判断到位。
它会给方案，但“是否值得做”仍然要靠人来判断。

3. /plan 和多 agent 配合起来很有价值​

先规划再执行，和“边做边想”相比，明显更稳。
特别是在下面这些场景里：

  • 新项目起步
  • 页面较多、模块较多
  • 需要视觉、交互、文案一起配合
  • 你希望它先调研再落地

4. 参考图可以有，但必须尽快去同质化​

一开始拿热门产品做参考，确实能帮助 AI 快速进入状态。
但后面如果不主动要求它进行风格转译、结构改写和内容替换，产物会越来越像“套壳”。

这不是模型的问题，而是提示方式的问题。

八、后续可复用的提示思路​

如果后续还要做类似项目，更推荐用下面这种指令方式：

先不要直接写代码。

请先基于参考页面，完成以下工作：
1. 提炼这个产品的页面结构、视觉节奏和核心交互
2. 区分哪些是可以借鉴的通用模式，哪些是需要避开的高相似部分
3. 给出一个“保留信息架构但重做视觉表达”的改造方案
4. 把任务拆成：页面结构、组件实现、样式系统、文案替换、插图/配图方案
5. 再决定哪些任务适合交给子 agent 并行处理

如果要继续推进实现，可以继续补充类似这样的限制：

视觉上不要高相似复刻，优先做风格偏移：
- 改配色体系
- 改字体气质
- 改插图风格
- 改文案语气
- 保留功能结构，不保留原始品牌表达

这样生成出来的结果通常会更可控。

九、补充：子 agent 提示词位置​

子 agent 的提示词存放地址也可以单独查看：

这一点的意义在于，你不只是“看到 agent 在工作”，而是能进一步理解：

  • 它拿到了什么上下文
  • 它被赋予了什么职责
  • 为什么它只读，或者为什么它可以直接编辑

这会帮助你后续更精准地设计 agent 分工。

十、从规划走到自动化落地​

前面的流程主要解决的是规划、拆分和并行执行问题，但在实际推进中，还会遇到一个更具体的缺口：
任务拆完了，视觉素材怎么真正落地。

新补充的这组截图，正好把这一段链路补完整了。

一开始，Codex 并没有自动生成可直接复用的 prompt 提示词文件，因此需要额外补一轮要求，让它把图像资产相关的提示词沉淀为文件：

仅仅生成提示词还不够。如果目标是稳定产出视觉素材，还需要继续约束 prompt 的结构、风格和可执行性：

这一步的意义在于，把“让 AI 画图”从一次性对话，提升成可迭代、可维护的资产生产流程。
一旦提示词被文件化，后面不管是自己手工调整，还是继续交给 agent 迭代，成本都会低很多。

再往后推进，就不只是“生成提示词”，而是把整个流程自动化：
直接调用本地代理的文生图接口生成图片，并切换到本地资源。

这一步很关键，因为它意味着流程发生了变化：

  • 不是停留在“给出建议”
  • 不是停留在“输出 prompt”
  • 而是进入“直接产出资产并接入项目”

到了这里，Codex 的角色就不只是编码助手，而更像一个把设计素材生产也纳入流水线的执行代理。

最终产出的效果如下：

这组截图对应的经验可以总结为：

  • 只让 Codex 做页面实现，效率提升有限
  • 让 Codex 同时接管 prompt 生成、图像生产和本地资源切换，效率提升才会明显
  • 一旦素材生成链路打通，多 agent 的价值会进一步放大，因为视觉资产不再只是“待办事项”，而是可以直接进入交付流程

换句话说，真正高价值的不是“它会不会写页面”，而是它能不能把页面、素材、接口调用和本地接入串成一个连续动作。

十一、总结​

这次实践最大的收获不是“Codex 帮我写了一个页面”，而是我开始更清楚地理解它的正确打开方式：

  • 先定方向，不要直接开写
  • 先规划，再并行
  • 把 agent 当成团队成员，不当成魔法按钮
  • 把参考当脚手架，不当最终答案
  • 人始终负责判断相似度、产品价值和最终取舍

如果只是把 Codex 当成“高级补全”，会低估它。
如果把它当成“全自动项目经理 + 设计师 + 工程师”，又会高估它。
比较合适的位置，是把它当成一个执行力很强、但需要持续校准方向的协作代理。