Codex 对我最大的用处，并非简单写代码，而是让我以尽可能小的时间成本，干成、干快以前干不成或干得慢的事。
我的背景是算法，在很多人看来，程序员都是一个类型。但实际上这个岗位的细分非常多，我擅长将业务问题转化为建模问题，能够构建稳定可靠的数据pipeline和模型pipeline，但并不包括写出好看的前端和稳健的后端。后半部分工作，是 Codex 帮我加速达成的。
此外，对于像产品、市场和运营这类工作，虽然日常协作有所耳濡目染，但绝对并非我的优势。我也借助 Codex，来帮我整理用户需求、做市场调研、分析数据并制定对应的运营活动策略。
所以，你说，Codex 对于普通人有什么用？那我想是解放了生产力，能够有机会做更多之前能想到，但是没资源去验证的事情。这些事情包括开发、文案类工作，也包括数据调研、资料整合类工作。
具体展开来说。
Codex，我用来干这些事
**第一件：看清楚市场。**这也是我逐渐琢磨出来的事情。在更早期我习惯让LLM先写一版原型看看，后来发现得市场先行。可以有想法，但是千万别急着开发构建应用，不然会陷入无尽的调试细节。
做 TrakToken 之前，我想知道市面上有哪些 LLM 定价追踪工具、它们的数据源是什么。这些调研工作，交给 Codex 去做整理，我来判断和取舍。最后结合我个人的偏好，上线了 TrakToken 这个 Token 追踪应用。用户反馈也不错，每天能稳定有500左右的访问量。
第二件：SEO。 SEO这事，其实我从大学开始就知道。图书馆的SEO相关书籍，我也看过不少。上半年的灰产GEO，我还写过一篇文章来介绍原理和我的看法。SEO这事，没啥诀窍，按照搜索引擎大厂的要求来，一点一滴优化就行。这任务特别细致，现在交给 Codex，哐哐出活。
此外，还可以让 Codex 分析竞品的 meta tags、关键词布局、页面结构，拉出具体的优化建议。转化漏斗的埋点代码、Google Analytics 的事件追踪配置，这些重复性的工程工作也一并交给它。我要做的是提需求，验收并给出我对数据的解读反馈。
第三件：开发管理与加速。 PageGrok 从 1.0.1 到 1.0.8，八个版本，四个月，大量 feature 和 bug 修复，都是靠"GitHub issue 记录需求、Codex 生成代码、review 后合并"这套流程跑出来的。虽然大家都想许愿式编程，但编程的艺术在于舍而不是在来坨大的。
通过产品路线图、版本控制、issue跟踪的方式，让我的开发管理井井有条。慢即是快。issue 会写清楚当前行为、期望行为、验收标准，剩下的让 Codex 的 agent 干就完事。当然，这些 issue 也是 Codex 在我的指挥下生成的。
第四件：运营维护。项目上线后，日志采集脚本、安全配置检查清单、定时任务的 cron 表达式、数据更新的定期抓取。这些琐碎但必要的运维工作，我现在都习惯丢给 Codex。
另外，我还有一套基于 Notion + GitHub 的周报自动化流程，底层的数据采集和同步模块是大模型搭的。现在每周的工作，不再需要手动记录，流转在 Notion 甘特图和GitHub提交记录的信息，通过数据管线汇总给大模型，每周只需要花2块钱，就能让顶级模型帮你总结项目进展、风险和下周优先级。
第五件：知识整理和评测。 这个可能比较少人提到。我用 Codex 帮我做 AI 模型的质量评测：写评测脚本，跑 benchmark，整理结果对比。做 TTSI（LLM Token 支出指数）复现的时候，数据采集和加工脚本也是 Codex 写的。我负责确定分析逻辑和结论判断。
还有知识整理：把散落在各处的笔记、文档，按主题归类生成结构化的知识库。还帮我汇集整理成其他agent能够调用的skills。
从想法到迭代的完整路线
把上面五件事串起来，就是我一个人做产品的完整流程：
想法 → 上线 → 获客 → 验证 → 迭代
对应到工程层面：
Issue追踪 → 方案制定 → 交付实施 → 预期验证 → 经验文档 → 循环往复
每一步 Codex 都能介入，但每一步的方向判断都是我自己做的。我在另一篇文章里写过，vibe coding 能写代码，但帮不了做市场判断、控制需求、和人建立连接。
三个 Agent 工具各有分工
只用 Codex 是不够的。我的日常工作里，Codex、Claude、Cursor 各有分工。
Codex 负责异步交付。 适合明确的、可以用 issue 描述清楚的任务。它在后台跑，你去忙别的，回来 review 结果。
Cursor 负责实时协作。 打开 IDE，边写边改。适合需要来回调试、反复确认的工作，比如 UI 微调、复杂的 debug session。
Claude 负责思考和策略。 我用 Claude 做的事更偏"脑力活"：
- TrakToken、PageGrok 的方案设计和架构讨论
- 文章的风格化处理、SEO 优化、双语内容生成
- AI 行业热点分析、机会评估、产品路线图梳理
- NFLX 期权策略计算、持仓绩效分析、量化回测
- Skills 编写和测评、项目工作流构建
三个工具加起来，大致覆盖了产品经理、前后端工程师、内容运营、数据分析师的角色。效果不等同于真人团队，但对于一个人来说，已经大大超标了。
底层跑着两个逻辑：
一个是产品与商业化落地，从想法到产品，从 0 到 1 建立可持续的价值和收入；
一个是知识与能力复利引擎，内容沉淀与技能系统化，持续复利，长期成长。
工程闭环：Issue 驱动一切
上面说了不少场景，但真正让这套体系跑起来的，是工程习惯，不是工具本身。
我用 GitHub Issues 跟踪所有待办事项，用 Notion 制定大致的工作计划。每个 issue 就是一个最小可交付单元。方案写在本地 Markdown 文档里，配合 issue 进行。
验证方面，一方面是功能效果验证，是否符合预期。另一方面是数据验证，做了之后，对我的北极星指标，比如活跃、付费，是否有提升。现在我越来越倾向于后者，因为前者在大模型加持下太容易做到了。后者是真正难而正确的事情。
这套意图解决一个问题：个人面对选择的时候，到底什么是好？是手边的事，还是更长远的事。是突然爆发的灵感，还是长期搁置的迭代。
有了 issue 驱动的工作流，加上 Codex 的异步执行能力，可以把精力集中在最该花脑子的地方：市场需求捕捉、宣传推广以及数据驱动开发。
给普通人
回到问题本身。如果你懂编程，Codex 最实在的用法就一个：把想法先跑起来。 有个小工具的念头，不想花一周写，用 Codex 几个小时出个能用的版本，先看看有没有人需要。如果你不懂编程，但是有很多重复性工作：自动化重复工作。 写脚本、做数据处理、配置部署流程。替你节省时间。如果你都没听过 Codex，那么这个产品你并非目标受众。