45小时6200万tokens：Codex还我一个完全符合需求、无报错可交付的中型macOS App项目

连续工作 45 小时。消耗 6200 万 tokens。Codex 从一份需求文档，给我跑出了一个可交付、可运行的完整 macOS App。

不是一行行盯着它写。不是替它改 bug。不是把需求拆成一百条小任务去喂它。我只是把完整的需求文档、功能清单、交互说明、设计规范、验收标准一次性写清楚，然后把它交给 Codex。

最后它跑了 45 小时 22 分钟。消耗了 61,938,817 个 tokens。交给我一个可以直接运行、没有报错、完全符合我原始需求的项目。

这件事让我确认了一件事。Prompt Engineering 那套玩法，确实快退环境了。未来真正值钱的，不是你怎么写 prompt，而是你能不能把自己的任务说清楚。

01 从 Prompt Engineering 到 Loop Engineering

把时间往回拨几年。

2022 年 ChatGPT 刚出来的时候。大家热衷于研究 prompt。温度怎么调。few-shot 怎么给。角色扮演怎么写。CoT 怎么引导。那时候的模型很听话。但也很笨。你得多哄着它，它才不出错。

2023 到 2024 年。开始流行 Agent。不是一次性对话。而是给模型装工具。让它能调用搜索引擎。能读文件。能写代码。但大部分 Agent 还是 prompt 的延长版。你写一个很长的 system prompt，定义它的性格、能力、工具、边界。

2025 年。Claude Code、Codex、Cursor Agent 这些产品出来后。事情变了。模型不再只是"你问一句它答一句"。它可以自己规划。自己执行。自己检查。自己修正。你给它一个目标，它会在代码库里反复循环。读文件。改代码。跑测试。看报错。再改。再跑。直到通过。

这个模式，现在有人叫它 Loop Engineering。

Claude Code 的负责人 Boris Cherny 有句话在圈子里传得很广。"I don't prompt Claude anymore. My job is to write loops." 他已经不再直接跟 Claude 一句句对话了。而是在设计能自己跑起来的循环。什么时候触发。怎么验证。什么时候停止。什么时候该叫人。

这不是一个技巧升级。而是工作方式升级。

02 我这次是怎么做的：没有技巧，只有把结果说清楚

我没有写一个很漂亮的 prompt。我也没有背什么 prompt 模板。

我做的只有一件事。把我要的结果，描述到极致清楚。

具体来说，我在项目启动前，把下面这些东西全部写进了项目文档里：

需求边界。这个 App 要解决什么问题。用户是谁。不做什么。

功能清单。每个功能点具体是什么。输入是什么。输出是什么。成功状态是什么。

交互说明。页面有几个。每个页面有什么元素。点击之后跳到哪里。异常状态怎么显示。

设计规范。UI 风格。配色。字体。间距。动效标准。

技术约束。用什么框架。支持哪些 macOS 版本。哪些 API 不能用。

验收标准。编译通过。没有报错。功能清单 100% 覆盖。关键路径能跑通。

写完之后，我把这份文档丢给 Codex。然后说了一句类似这样的话：

按上面的文档，把这个项目从 0 到 1 实现出来。有问题在文档里找答案，文档没写清楚的你按最合理的方式做。完成后跑验收标准自查，全部通过再告诉我。

然后我就去干别的了。

03 45 小时里发生了什么：Codex 自己完成了循环

Codex 不是一次性把代码写完的。它是在反复循环。

它会先读文档，理解需求。然后创建项目结构，写基础代码。再写功能模块，跑编译。报错就自己看日志，定位问题，改代码，再编译。某个功能实现了，它自己对照验收清单检查。发现漏了，就补。发现设计稿和实现不一致，就调。

这 45 小时里，它做了多少轮这样的循环，我没数。但从账单看，6200 万 tokens 里，绝大多数不是我在跟它聊天，而是它自己在跟自己工作：读文件、写代码、跑命令、看结果、再改。

最后它告诉我：项目完成，全部验收通过。

我打开工程，编译，运行，检查核心路径。没有任何报错。所有我列的功能都在。交互和我描述的一致。我当然没有一句一句审它写的代码，但我验证了结果——结果是对的。

这就是这次体验最让我震撼的地方。不是它写得有多快，而是它在我不干预的情况下，自己把闭环跑完了。

04 为什么 Prompt Engineering 会退环境

Prompt Engineering 的核心假设是：模型需要被"引导"才能输出好结果。所以你要研究怎么问、怎么设角色、怎么拆步骤、怎么加例子。

但这个假设正在失效。原因有两个。

第一，模型变强了。Claude 4 系列、GPT-5 系列、GLM-5.2、Kimi K2.7 这些新模型，理解能力、规划能力、工具调用能力、自我修正能力都远超几年前。它们不再需要你像教小孩一样一步步哄。

第二，任务变复杂了。一个真实的项目不是"帮我写个排序算法"，而是"给我做一个 macOS App"。这种任务不可能用一段 prompt 解决，它天然需要一个反复执行的循环。

Prompt Engineering 的极限，在于它仍然是"一次性输入输出"。而 Loop Engineering 承认：复杂任务必须靠循环解决。你不需要把每一步都写进 prompt，你需要告诉模型终点在哪里，让它自己找路。

05 Loop Engineering 的核心：不是会写 prompt，而是会定义任务

所以未来什么样的人占便宜？

不是 prompt 写得最花哨的人。是能把任务定义得最清楚的人。

什么叫把任务定义清楚？不是写一段很长的 prompt，而是做到这几点。

结果导向。不要告诉模型"怎么做"，告诉它"做成什么样"。不要让它猜你的成功标准。

边界清晰。什么必须做，什么不要做，哪些约束不能碰。模型最怕的不是任务难，而是不知道边界。

验收可验证。什么叫完成？是编译通过？是测试全绿？是功能清单打勾？还是用户能跑通某个流程？验收标准越具体，循环越容易收敛。

上下文完整。项目文档、设计规范、技术约束一次性给齐。不要让模型在循环中反复问你要信息。

允许自主决策。文档没覆盖的地方，让模型按最合理的方式做，不要让它每次停下来请示。

这次我的项目能跑通，不是因为我 prompt 写得好，而是因为我把上面五点做扎实了。Codex 只是执行者，真正值钱的是那份需求文档背后的思考。

06 这不是说 prompt 完全没用，而是它的位置变了

Prompt 当然不会消失。你总要开口告诉模型你想干嘛。

但 prompt 的角色从"核心技能"变成了"入口表达"。就像你写一个函数调用，重点是函数的签名清晰、参数明确，而不是调用语句写得优美。

Loop Engineering 里的 prompt，更像是触发器和边界声明。你告诉模型：这是目标，这是约束，这是验收标准，你去循环。剩下的交给 Agent 自己跑。

所以与其花大量时间研究"怎么让模型更听话"，不如花时间研究"怎么让自己想得更清楚"。

07 写在最后

我这次花了 200 美金档的 Codex Pro，跑了 45 小时，6200 万 tokens。听起来很多，但如果把它折算成一个中级 macOS App 的开发成本，其实是划算的。

更关键的是，这件事验证了一个判断。AI 编程的竞争点，已经从"会不会写 prompt"转移到"会不会定义结果"上。

未来最值钱的能力，可能是产品思维、工程判断、验收设计，以及把模糊需求翻译成清晰约束的能力。

提示词会退环境，但清晰思考不会。

关注我,及时了解更多 AI 资讯和 AI 知识。

大小项目开发和方案咨询,都可以私信。