如何用 Codex 打造一人公司：真实案例与学习路线

你可能也想过：如果 AI 能帮我写代码、做页面、整理资料，我是不是可以一个人经营一门生意？

可以朝这个方向尝试。但第一步，是把“能做出东西”和“能靠它持续经营”分开。

Codex 能缩短制作和修改产品的过程；客户为什么付钱、结果是否可靠、出了问题谁负责，仍然需要你回答。

这篇文章先看四个真实案例，再用一个贯穿全程的小项目，说明普通人应该怎么学、怎么练，以及什么时候适合开始商业验证。

一、一人公司需要哪些能力？

这里的“一人公司”，指由一个人负责主要经营决策，借助软件、AI 和必要的外部服务完成交付的业务。它不是某一种工商登记形式，也不意味着永远不能请人帮忙。

想让这门生意运转，至少要接上五个环节：

找需求：明确谁遇到了什么问题，现在如何解决。
做交付：做出客户能使用的工具、内容或服务。
查质量：确认结果正确、数据安全、使用过程顺畅。
找客户：让目标用户看见你，并愿意尝试。
算经营账：记录收入、成本、售后时间和客户是否继续使用。

Codex 在其中能承担一部分具体执行。以官方的 Codex CLI 为例，它可以在项目中查看文件、修改代码、运行命令；CLI 就是通过终端文字命令操作工具的方式。官方文档

因此，学习目标应该是：让 Codex 帮你完成一条可检查的交付流程，并让真实用户验证这条流程有没有价值。

二、目前有哪些值得参考的真实案例？

读创业故事时，先问“成功到哪一步”：是做出了作品，有了用户，还是已经形成可持续的生意？这几个阶段不能互相替代。

下面既有个人实践，也有从个人起步的业务和小团队案例。它们的适用范围不同。

1. freddy.coach：从销售背景出发，先独自做产品

OpenAI Academy 在 2026 年 8 月 28 日报道了 Tom Tomaszewski 的 freddy.coach。他过去主要带领销售团队，后来用 Codex 开发产品，将可穿戴设备的健康和运动数据连接到 AI。

报道引用他的自述：业务已收支平衡、服务超过 5,000 名用户。他独自工作到当年 8 月，随后引入一位有数据架构经验的合伙人；报道时已经是两人团队。案例原文

这说明，非程序员背景的人可以借助 Codex 进入产品开发，也可能在业务复杂后需要专业协作。用户数不等于付费人数；“收支平衡”是受访者陈述，本文没有获得其财务审计资料。

**可借鉴的做法：从自己长期经历的问题入手，把行业理解变成产品。**新手练习时，可以先选低风险的办公任务，不必从健康数据这类敏感场景开始。

2. Tony Lee：把个人工作方法变成可展示的作品

Tony Lee 在 2026 年 6 月 25 日的个人文章中，分享了面向非开发者的 Codex 演讲材料。他说明，演讲介绍了自己作为一人团队使用的七种工作流程，整套幻灯片由 Codex 制作。作者原文

这个案例支持的是个人交付能力和公开展示。原文没有提供可核验的公司营收，不能据此写成“靠 Codex 年入百万”。

**可借鉴的做法：把你已经熟悉的工作，整理成一个别人看得懂、可以试用的成果。**对于内容创作者、培训者和咨询者，先做出一套可演示的流程，往往比先开发一个庞大平台更容易获得反馈。

3. AgentLoop：一个人做出工具，自己仍负责产品判断

Edward Yi 在 Devpost 的 AgentLoop 项目页中，说明这是个人构建的作品：他负责架构、产品体验和范围判断，使用 Codex CLI 分段实现、审查代码。工具用于组织编码任务，并让另一轮检查指出问题。项目原文

这里能确认的是作者公开展示了项目，并描述了开发过程。项目页不构成盈利证明；作者本身也有 AI 工程背景，不能把他的实践当作零基础学习速度的标准。

**可借鉴的做法：一次做一个小部分，每个部分都检查。**不要把“生成了很多代码”当作进度，应该看一个完整任务是否已经可用。

4. Goliath Data：需求来自客户，才有商业价值

OpenAI Academy 在 2026 年 8 月 14 日报道，Goliath Data 使用 Codex 和 ChatGPT Work 将客户请求转成产品改进。一位潜在客户需要按公立学校招生区域筛选房产，团队完成了该功能，演示后对方要求发送每月 10,000 美元的合同。案例原文

**“要求发送合同”不等于已经签约、到账或形成利润。**报道还说明团队从三人扩大到约 20 名全职员工，它是团队案例，不是一人公司案例。

**可借鉴的做法：先确定客户需要什么，再制作解决方案。**一个能解决具体业务问题的小功能，可能比一套无人需要的大系统更值得做。

这些案例放在一起，能得出什么结论？

案例	资料支持的进展	不能据此断言
freddy.coach	从个人开发起步；创始人称业务收支平衡	一直由一人经营、5,000 人全部付费
Tony Lee	用 Codex 完成并分享个人工作成果	已形成特定规模的公司收入
AgentLoop	作者展示个人工具与分段开发过程	零基础可复制同样速度、已经盈利
Goliath Data	围绕客户需求开发，获得发送合同的请求	合同已到账、属于一人公司

这些公开材料支持“个人和小团队可以借助 Codex 提高交付能力”，但不足以推出“学会 Codex 就能稳定赚钱”。部分来源由工具厂商发布，部分是作者自述，阅读时要保留这层证据边界。

三、适合普通人的起步方向是什么？

结合以上案例，我建议先找客户明确、输入清楚、结果容易检查的任务。下面是可练习的方向，不是已经验证成功的商业案例。

方向	一个足够小的起步项目	你必须承担的检查
内容服务	将客户资料整理成文章初稿与来源清单	事实、版权、语气和最终发布
数据整理	将脱敏订单表生成可核对的周报	金额、统计口径和漏行重复行
办公自动化	批量归类文件、生成项目目录	备份、误分类和恢复办法
小工具交付	为特定用户做一个报价或排期工具	计算规则、异常输入和售后

如果你已经服务某类客户，优先从他们反复抱怨的问题里找题目。如果暂时没有客户，就从自己每周重复做、做错后损失较小的一件事开始。

先手动完成一次，把步骤和检查方式弄清楚，再交给 Codex。否则，你很容易自动化一套自己都没理解的流程。

四、学习路线：用一个项目贯穿六个阶段

我们用“脱敏销售表 → 可核对的每周报告”作为练习。它能连接文件处理、计算、页面、测试和交付；起步时只用虚构数据，避免接触真实客户隐私。

可以按六周安排，但每一阶段以验收结果为准。如果还不会检查，就多练一轮；六周是练习节奏，不是创业期限。

第一阶段：学会给任务，也学会看结果

选一个你能正常使用的 Codex 入口，按官方说明完成设置。先只练三个动作：让它解释文件、提出方案、完成一个小修改。终端用户可以从 Codex CLI 官方文档开始。

第一份任务可以直接这样写：

我是非专业开发者。请先查看我提供的虚构销售表，
用简单中文解释每列的含义，以及哪些字段会影响统计。

先给出生成周报的方案和验收方法，不修改文件。
遇到缺失信息先列出，不要自行补造数据。

**通过标准：**你能说清输入是什么、结果应该是什么，并能指出 AI 有没有误解。

第二阶段：补足最少的技术常识

不必先学完一整套开发课程，但要理解几个会影响判断的词：

CSV：用行和列保存数据的文本表格。
脚本：按规则自动完成一串操作的小程序。
Git：记录文件修改历史，帮助你查看变化和恢复版本。
测试：用已知输入检查程序是否产生预期结果。
API：软件之间交换请求和结果的接口。

练习识别空值、重复记录、日期范围和金额单位。让 Codex 解释运行方式，再由你用小样本手工核对。

**通过标准：**拿到五行虚构数据，你能独立算出正确总额；改坏文件后，你知道如何恢复。学 Git 时先在独立练习目录操作。

第三阶段：做出第一版能完成任务的小工具

MVP 是“最小可用产品”，意思是先保留完成核心任务所需的功能。

这份周报工具的第一版只需：

读取固定格式的虚构 CSV。
按约定日期范围计算销售额和订单数。
输出本地报告，并列出无法处理的记录。
保留原始文件，方便复查。

暂时不做登录、支付、复杂图表和自动外发。缺少退款口径时，不让程序擅自把退款排除或计入。

请先实现一个可运行的小版本。
只处理约定格式的 CSV，生成本地周报。
金额按最小货币单位的整数计算，不覆盖原文件。
空值、重复订单、无效日期和异常金额都要明确报告。
请说明修改了哪些文件，并提供可以手工核对的样例。

**通过标准：**样例结果与手工计算一致；错误输入有清楚提示；再次运行不会损坏原文件。

第四阶段：把要求写成规则，建立检查习惯

官方说明，Codex 会在工作前读取适用的 AGENTS.md。你可以把它理解成项目的工作规则文件，用来保存目标、边界和检查要求。官方说明

例如，在练习项目中写下：

# 项目工作规则

- 用简单中文解释改动和运行方法。
- 只使用虚构或已经脱敏的数据。
- 不覆盖输入文件，不自动上传或发送报告。
- 统计口径不明确时列出问题，不猜测。
- 修改计算逻辑后，用已知结果的样例验证。
- 报告分清已验证结果、限制和待确认事项。

然后测试正常数据、空文件、重复订单、退款记录和跨周日期。让 Codex 检查一次，你自己再检查一次。

**通过标准：**你能演示工具成功的情况，也能演示失败时如何提示和恢复。规则文件帮助约束流程，但不能代替权限设置和实际验收。

第五阶段：验证用户愿不愿意使用

找三到五位符合目标的人看演示。这是访谈练习，不代表统计意义上的市场验证。

与其问“这个工具好不好”，不如问：

你上次整理周报是什么时候？花了多久？
最容易出错的是哪一步？
现在用什么方法解决？
如果使用这个结果，你还需要补做哪些检查？
什么条件满足后，你愿意试用或讨论付费？

记录真实反馈，区分“觉得有趣”“实际使用”“愿意付费”。如果开展付费试点，先约定范围、价格、交付物和验收方式。

**通过标准：**有人愿意使用自己的合规样例尝试，并能给出具体反馈。没有这一步，先继续验证需求，不急着扩功能。

第六阶段：把验证过的流程变成可复用服务

同一个任务交付几次之后，再考虑 Skills。Skill 可以理解成“AI 可复用的工作手册”，把步骤、模板和检查要求放在一起，减少每次从头解释。官方说明

例如，把周报服务固定成：检查输入 → 确认口径 → 生成结果 → 核对样例 → 人工批准交付。

这一阶段还要写出使用说明、常见错误、费用记录和恢复步骤。每增加一个自动操作，先确认出错时是否能停下来。

**通过标准：**下一次拿到同类输入，你能沿着同一流程交付，而不必依赖上一次聊天。更换工具或换人协助时，资料仍然可读。

五、怎么判断它已经接近一门生意？

不要只看 AI 写了多少代码、生成了多少份报告。每次交付后，记录五个数字：

有多少人实际使用，而不只是看过演示。
有多少人愿意付费或再次购买。
每份结果需要你人工修正多少次。
每次交付花了多少时间和外部服务费用。
出问题后需要多少售后时间。

可以先用下面的经营记录框架：

本次交付结余 = 实际收入 - 本次模型/服务费用 - 其他直接成本
本次总工时 = 制作时间 + 核查时间 + 沟通时间 + 售后时间

这只是经营观察，不是完整会计利润。订阅、服务器、税费等长期成本也要另外记录；创始人的时间更不能当成免费。

如果客户愿意持续使用，检查和售后负担逐步可控，你才有理由扩大交付。若每次都要重做，即使制作速度很快，也需要先修正流程。

六、第一步就从一件可验收的小事开始

看完案例，可以把自己的起步计划写成一句话：

我为哪一类人，解决哪一个反复发生的问题，交付什么结果，用什么方式证明结果可靠？

把这句话写清楚，再让 Codex 帮你拆成小任务。第一份成果可以只是本地工具、一份可核对的报告，或者一次边界明确的服务。

你需要积累的是完整经历：发现需求、制作、检查、交付、收集反馈，然后根据结果决定是否继续。Codex 能帮你推进其中很多步骤；经营方向和最终责任，仍掌握在你手里。

资料来源

以下资料均于 2026 年 10 月 3 日检查。案例保留报道时点，作者自述和商业事实的证据边界已在正文标明。

OpenAI Academy：freddy.coach 创始人如何用 Codex 建立健身业务，2026 年 8 月 28 日。用户数与收支平衡为创始人自述。
Tony Lee：Codex for Non-Developers 演讲记录，2026 年 6 月 25 日。个人实践说明，不是财务证明。
Edward Yi / Devpost：AgentLoop，项目记录始于 2026 年 7 月 20 日。作者项目说明，不是收入证明。
OpenAI Academy：Goliath Data，2026 年 8 月 14 日。客户要求发送合同，不等于收入到账。
OpenAI：Codex CLI 官方文档，用于核查本地工作能力和入门方式。
OpenAI：AGENTS.md 项目规则，用于核查规则文件机制。
OpenAI：Skills 与插件，用于核查可复用工作流程的含义。