1个人，3个月，500亿Token：我的 AI Native 产品开发实践

自今年 4 月中旬，我开始尝试 1 个人用 AI 来做一款企业级产品，到今天已经有 3 个月的时间。期间我使用 Codex 烧了 500 亿 Token，生成了 100 多份 Spec 文件和 60 多万行代码。最终完成了这款产品初始版本开发与上线。

它的定位是面向企业的 AI 编程治理平台，目的是让企业 AI 编程从使用可见，到风险可控，再到价值可衡量和经验可沉淀。

产品技术栈包含了 Golang, React, Rust, PGSQL, ClickHouse, Redis，也算得上是一个复杂的企业级软件系统。

这 3 个月，从市场调研、产品设计、竞品分析，到架构设计、需求梳理、软件开发，再到测试验证、上线维护、内部试点，还包括产品和方案的介绍材料，几乎都是我 1 人使用 Codex 完成，甚至还抽空提报了软著和专利，这也是为什么最近 2 个月我没有再更新博客和公众号的原因，实在是忙到飞起。

目前，产品已进入内部测试阶段，我才有时间喘口气，把这段时间的经历、经验做一些总结。当然，文章中也不免有一些主观观点以及错漏，所以仅供读者朋友们参考。

1. AI 编程的核心问题：对抗不确定

去年 2 月， Karpathy 提出 Vibe Coding 这一概念后，AI 在软件编程领域的成熟度已经达到了较高的水平。期间也伴随着 AI Coding Agent 和大模型的发展，以及 Context Engineering、Harness Engineering、Loop Engineering 等概念的提出。

但在实践中，还是会有不少开发者反馈 AI 编程的效果并不好，有困惑、有质疑甚至也有贬低。我不想争论孰对孰错，我想说的是 AI 编程目前客观存在的问题就是不确定性。

AI 编程这一实践，包含了大模型、Agent 工具以及开发者自身，它的不确定性受以下多方面因素叠加影响：

• 模型随机性： 大模型的底层原理和实现机制，就决定了模型的输出本身具有随机性，这一特性不可改变。
• 上下文限制： 上下文的长度限制影响了 AI 执行任务的连续性，上下文的干扰、记忆的衰减以及上下文压缩后产生的信息丢失，都会影响任务的确定性和正确性。
• 语义不清晰： 用语言传递需求，语言本身就存在二义性，这个与是否使用 AI 没有关系。在传统软件开发过程中，也会经常出现这类问题，也就诞生了程序员买西瓜那个经典笑话。
• 需求不全面： 一个新需求或者需求变更，其实现和影响范围在需求分析阶段往往是容易遗漏的，很多问题都是在开发过程中才能被识别、发现和解决。
• 业务不理解： 预训练的大模型没有当前项目业务的专业知识，导致无法理解业务流程和相关技术。即便是常见的 OA、CRM 系统，也会因具体业务场景的特殊性，从而产生不确定性。
• 偏差传递与累积： 各个环节的不确定性累积，导致最终出现更大的不确定性，环节越多，流程越长，不确定性越大。

所以 AI 编程要解决的核心问题就是要对抗不确定。其实 Prompt Engineering、Context Engineering、Harness Engineering、Loop Engineering 这些概念也都是为了解决这一核心问题而诞生的。

2. Loop Engineering 实践：Token 还是要烧

在上文中，我不止一次提到各类 Engineering，但在社区里有不少反对声音，批判 AI 圈造名词，说这些 Engineering 归根到底都是 Prompt，不过是博眼球、蹭热度之类的伎俩。

而从我个人的实践经历来看，这些词叫什么意义不大，因为当你真的使用 AI 来开发软件，自然而然就会遇到一些问题，当你尝试解决这些问题时，你就已经在使用这些概念提到的方式方法。它们只是在用一些形象的名词解释、总结这些方法。

2.1 Loop Engineering 的本质

比如 Loop Engineering，吴恩达老师给出了一个经典的 3 循环图来说明它在产品开发中的应用。

其实这个图所表达的意思，与传统软件开发也能进行对照。就以软件工程中提到的 SDLC 6个关键阶段为例，在 AI 时代，只不过是把需求、设计、开发、测试放到了 Agent 中来做，Agent 完成产品的初步开发与验证，然后开发者或产品经理来做自测或验收测试，最后交付客户做 Beta 测，A/B 测或生产上线。

所以这些概念不是什么新鲜事物，但却足够形象。那 Loop Engineering 如何解决 AI 编程的不确定问题？实际项目中，它该如何运作？我们逐个来做拆解和分析。

2.2 Agentic Coding Loop

2.2.1 实践1：选择 Loop 框架

AI Coding Agent 的 Loop 框架有很多，比如 Superpowers、OpenSpec、GStack、GSD 等。或许它们也可以叫 AI 编程框架、Harness 框架。但用户该如何选择？

我在之前的文章《30天烧150亿Token，我总结了6条AI编程经验》中提到了一个原则：**Less is More！ 应该从简、从小用起，在没有熟悉一个框架前，不要引入更多框架。**另外，如果只是平时写一些工具、脚本，完全没必要安装这些框架，可以直接使用 Codex 原生的 Plan 和 Goal 模式即可。

目前，我个人主要是用 Superpowers ，它通过以下几个阶段初步形成了 Agentic Coding Loop 的基础内循环。

这些阶段和循环在一定程度上解决了 AI 编程的不确定性，比如：

• 使用 Brainstorming 来收集项目相关信息，和用户讨论后形成 Spec 并确认。降低语义和业务不确定问题。
• 使用 Writing Plans 和 Subagents 来分解任务，分而治之。降低上下文限制导致的不确定问题。
• 使用 CodeReview 和 TDD 来测试检查任务。降低模型自身随机性。
• 多个 Skills 结合，降低偏差的传递与累积。

但这些还远远不够。

2.2.2 实践2：自定义 Loop 框架

由于模型自身的随机性，在使用 Superpowers 生成 Spec 和代码评审时，AI 不会每一次都能发现问题，或者说 AI 每一次发现的问题也是随机的。这就导致了我在使用 Superpowers 时，经常会问它：“你自己想想还有没有没考虑到的问题或潜在的风险？还有其他问题吗？” 有时，一个问题还要问多次。所以能不能让 Superpowers 的各阶段也 Loop 起来？

于是我对 Superpowers 内置的 Skills 进行了一轮改造。以创建 code-review-loop Skill 为例，参考提示词如下：

基于 superpowers:requesting-code-review，创建 code-review-loop，在它的基础之上:
1. 进行多轮审查，直到不存在 Critical（严重）或 Important（重要）级别的问题。
2. 检查代码设计是否符合 Spec 和 Plan 要求，确保没有遗漏需求或非预期偏差。将 Spec 和 Plan  文件按时间从新到旧排序，以最新的适用文件为准。
3. 针对每项需求，检查相关的存储、API、服务逻辑、前端状态、测试和文档。确保一致性。
6. 对每个新增功能或状态，检查其端到端测试是否覆盖完全，包括原有行为、新增行为，以及至少一个模式切换的边界场景。
7. 最终回复应说明审查轮次、Critical 和 Important 问题的处理情况、剩余问题，以及验证命令和执行结果。

另外我还创建了 brainstorming-loop 代替 brainstorming ，创建了 dev-loop 代替 Subagent-Driven Development。

在这些自定义 Skill 中，除了加入了一些自我循环检查，还加入了一些开发过程中总结的经验和要求。比如：

• brainstorming-loop 中要求 Spec 要包含 HTML 设计稿。这个在前端开发中尤为重要，否则你很难预判它最终会做出什么样的界面。
• dev-loop 和 code-review-loop 中要求开发和评审需参考对应 Spec 和 Plan 中的需求，确认这些功能全部实现，没有遗漏。这样才能尽可能让代码实现匹配产品需求。

这些经验和要求，通用的部分就沉淀在 Skill 中，项目特有的就沉淀在 Agents.md 中。来进一步对抗模型自身的随机性和偏差累积。但这种做法无疑加剧了 Token 的消耗，这个问题我会在 实践7 中展开来说。

但一定要记住，**千万不要认为安装一个或几个通用的 skill 或框架就能解决你的实际开发问题，你的问题只有你能解决。**所以需要对框架进行自定义。

2.2.3 实践3：会话隔离和语音输入

上文提到，Spec / Plan 任务分解与 Subagents 执行在一定程度上降低了上下文限制产生的不确定性。可一旦任务累积太多，还是会遇到瞻前不顾后的情况。

所以在实践中，我推荐每个需求任务一个 Session 会话，这个会话中所有的上下文都只与这个任务相关，避免与其他任务的上下文干扰。

在我的 Codex 中，会话列表大致如下：

- Project A
  ｜- Task 1
  ｜- Task 2
  ｜- Task ...
  ｜- Issue
  ｜- 发版
  ｜- 部署
  ｜- 文档
- Project B
  ｜- Task 1

一个需求任务开发完成后就归档。当后续遇到这个需求任务相关的问题，可以在 Codex 的已归档任务中搜索并找到这个会话，恢复后继续询问。

某些专用的会话，比如我这里的 Issue 用于创建或查询 GitLab Issue，发版用于打 Tag 、运行流水线、创建 Release 并触发 IM 通知。部署用于在测试、生产环境部署。这些会话会常驻在项目会话列表中。

需要说明的是，会话隔离也不能解决上下文限制的问题，但它尽可能让这个会话的上下文聚焦，减少干扰。另外一些专用的会话，随着上下文的积累，就可以让 AI 基于会话记录，生成相应的 Skill，所以可以说它提供了一个 Skill 孵化的场所。

最后，我还想专门提一下 AI 时代不能只用传统的打字工具，它的效率实在是太低了。当你需要给数百行 Spec 提出评审意见，需要给漏洞百出的设计稿提出修改意见，还是需要一款高效的输入工具。可以尝试豆包输入法或者 Typeless 这类语音输入法，它们可以让我看着 Spec ，边想边说。唯一的缺点是办公室里可能有点社死。另外不推荐 Codex 自带的语音输入工具，它和专门的语音输入法完全不是一个级别。

2.2.4 实践4：对 Spec 评审和版本控制

在《30天烧150亿Token，我总结了6条AI编程经验》这篇文章中，我也一再强调 Spec > Code . 不要妄图一句话让 AI 开发复杂业务系统。

AI 时代，写代码这件事已经不是主要工作，人的价值就是去做业务设计和技术管理工作。

由于 AI 对业务知识不了解，所以用户需要作为业务和领域专家，去做业务建模、领域设计、流程梳理，要把这些信息输入给 AI ，并与 AI 进行讨论和确认。这是业务设计。

由于 AI 的偏差累积以及内部的黑盒机制，所以用户需要作为技术专家，识别和发现 Spec 中的关键问题，让 AI 思考和完善。这是技术管理。

此外，Spec 作为 AI 时代的产品设计说明书和需求文档，应该要随代码进行版本控制，在代码评审、文档编写和后期维护中都有重要价值。

2.2.5 实践5：代码评审和自动化测试

代码评审和自动化测试也是降低 AI 不确定性的主要方法，也是 Agentic Coding Loop 中自闭环的最后一步，更是 Harness Engineering 中的重要措施。

Superpowers 自带的 CodeReview 和 TDD Skill 可以缓解偏差累积。结合实践2 和实践4 ，Spec 和 Plan 作为代码评审依据，可以更大程度上降低不确定性。需要注意的是，Spec 包含了业务和技术目标，结合 Spec 的代码评审才有实际意义，否则只检查代码自身或者参考内容不全的需求任务做评审，都存在风险和隐患。

当然，我这里说的代码评审都是 AI 来做，因为这属于 Agentic Coding Loop。那么由于模型自身随机性，就需要像实践2 那样多跑几轮评审，或者使用其他 AI Agent 来做交叉评审。但不论怎么做，随机性问题依然存在，这就需要自动化测试来补充。

仅使用 Superpowers 内置的 TDD 显然是不够的，实践中一定要补充 E2E 测试。让 AI 根据项目技术栈，参考真实业务场景，模拟用户真实操作，跑通主要流程并覆盖边界条件，且不允许 Mock 数据或直接操作底层数据。并在合并分支前，一定要通过 Unit Test 和 E2E Test 。这些你都可以自定义到自己的框架和 Skill 中。

相较于代码评审，自动化测试是用固化的程序和流程来做验证，它的可靠性、稳定性更高，能更好的对抗不确定性。此外由于是固化的程序，一次编写，多次运行，也能节省 Token。

最后你需要把代码评审和自动化测试设计成工作流，比如我自己是：

• Brainstorming Loop ——> Plan Loop ——> Dev Loop ——> Code Review Loop ——> Finish with MR
• Dev Loop 中做 Unit Test 和 E2E Test
• Code Review Loop 中结合 Spec 检查 Unit Test 和 E2E Test 是否覆盖完全
• Finish with MR 要求必须通过 Unit Test 和 E2E Test 否则不允许合并
• CI 流水线中运行 Unit Test
• E2E Test 做成工具，在本地和真实环境中做测试验证，不运行在 CI 中

2.2.6 实践6：并行开发与冲突处理

AI 和 AI Coding Agent 的爆火还带动了另一项技术，Git WorkTree。它是 2015 年在 Git 2.5 版本中引入的特性，为了解决并行开发与工作目录隔离。目前几乎所有的 AI Coding Agent 都会使用 Git WorkTree ，但它只解决工作目录隔离，不解决逻辑代码冲突。

如果你在一个项目里，分多个 WorkTree 同时跑多个开发任务，那在合并分支的时候一定会遇到无休无止的冲突问题。再加上 AI 的随机性和内部黑盒特性，我是非常担心处理冲突的过程中产生更多问题。

所以在实践中，如果要并行开发多个任务，尽可能不要涉及相同逻辑的代码。比如你可以一个任务做文档，一个任务做后台，一个任务做前端。但不要多个任务同时改后台逻辑，或数据库表结构。

合并前先做 Pull 或 Rebase，跑完 Unit Test 和 E2E Test 再合并。

2.2.7 实践7：Token 消耗与成本管控

在 Agentic Coding Loop 的最后一节，我想来聊聊 Token 相关问题。

曾几何时，圈子里转发着各类 “AI 时代要多烧 Token” 的文章。没过多久，又变成 “烧 Token 的时代已经过去了” 云云。

AI 时代用户不烧 Token，就跟学霸不用刷题，车手不用练车，厨子不用切墩，都是屁话！

Loop 这个词本身看上去就不省 Token。为了降低 AI 的不确定性，为了提高代码质量，为了获得更好的生成效果，为了学习更多的经验，就是靠更好的模型、更高级的思考模式、多轮的检查、多轮的执行。每一项都会消耗 Token。

Token 一定要烧，但用户和企业关心的是账要算明白。不要无意义的浪费，以及要有明确的产出。这也是我去开发这个产品的初衷。防止企业敏感数据外泄，管理企业 AI 成本，度量 AI 代码贡献并将好的 AI 实践沉淀成企业知识。

2.3 Developer Feedback Loop

2.3.1 实践8：人工验收测试

在 Agentic Coding Loop 中，借助 Loop 框架、代码评审和自动化测试，让 AI 可以产出初步符合要求的代码和软件产品。可这不是终点，不确定性依然存在。这时候还是需要依靠人。

与传统软件开发一样，需要有产品负责人去对 AI 开发出来的产品进行验证测试。而这个产品负责人在 AI 时代可能就是用户，也就是开发者自己。

即便我们和 AI 讨论并形成了 Spec，还对 Spec 进行了评审确认，甚至在 Spec 中加入了设计稿。即便我们做了代码评审和自动化测试。但这个产品是不是符合用户的最终要求？语言的二义性、需求的不完整性需要在 Developer Feedback Loop 中做校验。

用户需要实际使用和操作产品：

• 检查交互逻辑，UI 风格与样式是否符合预期
• 检查业务逻辑，操作流程是否符合预期
• 检查边界条件，消息提醒与异常报错是否符合预期

发现的问题再重新流转回 Agentic Coding Loop 去处理，并且要让 AI 补充 Unit Test 或 E2E Test 覆盖。

2.3.2 实践9：真实环境测试

因为上文提到，AI时代的产品负责人很可能就是开发者自己，所以人工验收测试大部分都是在开发环境本地直接编译运行源代码来测试。

这就会产生另一个问题，本地开发环境的产品和交付到客户部署环境的产品是完全一致的吗？

我在实践中吃过这个问题的亏。本地 E2E Test 没有问题，人工验收测试也没有问题。但产品以容器镜像打包并部署到测试环境后，就遇到了一些 Nginx 设置、变量读取的问题导致运行出错。

所以务必要在真实部署环境进行一轮完整测试。 部署和测试都可以由 AI Coding Agent 来完成。

2.4 External Feedback Loop

2.4.1 实践10：搭建智能助手

3 个循环的最后一环就是 External Feedback Loop，在实践中，一般是以内部测试、小范围试点、A/B 测展开的，或者就是交付到客户生产环境，接受来自真实用户的反馈。

这个环节与传统软件开发也没有什么不同，但 AI 时代，我们还是希望做一些提高效率和用户体验的事。

比如我用 Hermes Agent 搭建了产品的智能助手，让它：

• 对接 IM 工具作为用户使用入口
• 读取产品代码和文档解答用户问题
• 根据用户反馈的问题整理成标准需求任务并创建 GitLab Issue
• 定时获取产品 Release Notes 并通知
• 定时查看生产环境负载并通知

这样一来，公司内部同事要获取产品信息就可以直接找这个智能助手，我就可以省下时间和精力去做更有价值的事。

2.5 Loop Engineering 的代偿机制

在这个章节中，我们按 3 个 Loop， 10 个实践分析了 Loop Engineering 的实践方式，并分析它如何对抗 AI 不确定性。不过，不论怎样努力，不确定的问题只能被降低，无法被彻底解决。

比如 AI 做了 5 轮评审，没有发现严重问题，然后 Loop 停止了。当你手动执行第 6 轮评审，又会因为模型随机性发现一些新问题。这里就有遗漏。

再比如开发者去做人工验收测试，人的能力水平有差异，能测试和发现的问题也有差异。这里也有遗漏。

但 Loop Engineering 的一个特点是它具备代偿机制。也就是说我们只能尽量去做好每个 Loop 以及 Loop 中的各个阶段。当某个阶段和某个 Loop 有遗漏时，就可以交给下一个 Loop 来发现和解决不确定问题。但处理问题的时间和成本就变高了。你看，这与传统软件开发的 SDLC 也完全一样。

3. AI 时代的产研团队形态：产品“主理人”

3.1 人的价值和时间投入比例

本文开篇就提到 AI 编程是 AI 模型、AI Agent 和 开发者之间协作的一个实践过程。开发者也就是人在里面扮演了非常重要的角色。

虽然我们一直在说 AI 要替代程序员，但至少在这个替代的过程中，人依然有他的独特性和重要性。在我来看，总有一些东西是 AI 无法替代的，那么人就要去往这个方向去学习、进化。

在上文的 10 个实践中，也有很多环节需要依靠人的能力，比如：业务建模、领域设计、技术管理、测试验收等等。

再提炼一下核心内容，就是懂业务，懂技术。你需要能一针见血的指出关键问题，比如：

• 有大量数据处理的场景，你就应该让 AI 多关注并发
• 有特殊业务逻辑的场景，你就应该主动提出一些关键和边界业务流程让 AI 了解

这些能力的建立和提升，只能靠长期的积累。

与传统软件开发中人去写代码不同，现在我的时间分配大致如下：

• 50%：业务与产品设计。包括调研分析、建模设计、需求梳理、Spec 讨论与评审等。后续还涉及对接客户。
• 10%：技术架构与代码评审。对于一些关键技术点，输入自己的建议或问题。
• 30%：测试验证。通过大量人工测试验证产品的正确性并把自动化测试建立完善。
• 10%：其他杂事。包括软著、专利、文档、方案材料等。

3.2 产品 “主理人” 的协作模式

随着 AI 的快速发展，目前可以看到完全靠人去写代码这件事已经受到挑战。虽然纯粹的软件开发岗位还会存在，但人员比例会被逐步压缩，比如：

• 专家类：前端专家、测试专家、运维专家、DBA、UX 等。他们仅会保留极少部分，一般是身兼多个项目，用来解决疑难杂症。
• 专业领域类：如军工、航天、芯片等。
• 技术创造者：创造新的技术。

对于编写普通业务系统代码的开发者来说，如果开发者希望产品经理能给出完善的 Spec 和设计稿，自己来实现。那产品经理完全可以把 Spec 扔给 AI 来做。

传统意义上的产品经理岗位也会受到挑战。如果产品经理只会画原型外加开写轮眼 Copy 竞品，那他会被 AI 骗的团团转，也可能被专业的 UX 代替。

所以我的个人设想是，未来需要有面向客户的，懂业务且懂技术的人，作为产品的负责人来实现整个产品的设计与开发。姑且称这个岗位为产品 “主理人”（Product Owner）。 管杀也要管埋。

产品 “主理人” 需要自己完成产品 MVP 的设计与落地，跑通 PMF 闭环。随着产品功能的增加，他可以变成产品创始人（Product Founder），关注产品的顶层设计，并带领多个 “主理人” 分管不同的模块。没错，按模块去拆分产品。每个 “主理人” 完全为自己的软件模块端到端负责。

最后，由一些跨产品、跨项目的专家合作，比如UX 专家来设计产品整体风格样式，测试专家来补充产品整体测试。

3.3 产品 “主理人” 的成长路径

懂业务且懂技术，这个条件看起来就很苛刻。以我自己为例，我做了 10 年的软件开发与架构设计工作，让我熟悉技术，做了 5 年的解决方案工作，让我了解业务。但对于刚入行的新人，这个路径显然行不通。

所以我们还是抛开各种新奇的概念，回归软件工程本质。我记得我刚毕业那会，在一家做 MES 的公司做开发。第一年我的工作是给一个客户做 MES 的 LED 展示大屏。我需要自己负责这个功能需求收集、方案设计、代码开发，交付后需要收集客户反馈来改进。这不就是 “主理人” 的工作么！一个独立功能模块的端到端实现。当然，这个模块很简单就是了。

那么未来，依然可以有新人，用新的什么 Engineering 去负责一个简单的产品功能模块。然后再积累经验，负责更复杂的产品模块。这就是产品 “主理人” 的成长路径。

AI 编程真正改变的，不只是代码由谁来写，而是软件开发的模式。未来更重要的能力，可能是把业务、产品、技术串联起来。

工具、模型和框架还会继续变化，但人既要懂业务，也要懂技术，才能真正驾驭 AI，把想法变成可交付、可验证、可持续演进的产品。这件事不会变。