配图里是我 Codex 的用量：250 亿 Token。
再加上 DeepSeek、Claude Code 以及一些中转 API，从去年 9 月到今天，我已经消耗了 300 亿 Token 用于 vibe coding。
恰好今天 Token 额度用完了，所以想和大家分享一下这段时间重度使用 AI 后的经验。
这些经验主要来自编程和软件领域，不过也有一定的泛化性。
重要提示： 文中没有任何技巧。 不存在任何一个 skill 或 prompt，可以让你用了以后，vibe coding 的代码更好、bug 更少。
1. 把自己当成 CEO
如果你开始把 AI 当成生产力，第一件要做的事就是调整自己的心态。
你要告诉自己——你是 CEO。
否则，你只是在消耗自己，并眼看着被那些你认为不如你的人反超。
Cursor 刚开始流行的时候，我的推特时间线还有两个派系：
- 一类是嘲笑 vibe coding 的质量，并且严重质疑 AI 写出来的代码是否能用；
- 另一类，是迫不及待开始尝试的人。
而如今，我想所有人的时间线应该和我差不多，几乎看不到前者了，但还是有一些。
对 vibe coding 持反对态度的几乎都是工程师，并且往往越专业就越反对。我不清楚他们的反对里是否有危机意识的因素，但我能够肯定，他们之所以反对，是因为太专业了。
他们总是忍不住去 review AI 写错的代码，然后亲手修改。
这样的情况其实不只发生在编程领域。我相信其他领域也一样：越是专业、严谨、认真的人，越容易在使用 AI 的过程中产生不信任感，从而放弃或反对。
文字工作者觉得，等 AI 写出东西后，还要一次次修改，很浪费时间；设计师觉得，一遍遍等 AI 出图像是在抽奖……
而拥抱 vibe coding 的人大部分，甚至可以说几乎全部，都是非工程师，或资历较浅的工程师。某种程度上，可以用“不知者无畏”来形容他们。
以往要通过数月、数年的学习，再以数周的工作才能获得的成果，现在只需要一两句话和一点耐心等待——
BANG！
一个应用就诞生了！
这很难不让人上瘾。
于是，奇怪的景象就发生了，非工程师们纷纷开始写软件，而工程师却一直在观望——另一种形态的能力陷阱。
不过还好，随着 AI 能力变强，接受的工程师也越来越多。但他们的专业能力，也还是在阻碍他们更快速的生产。
1.1 不要过度在乎过程和细节
对于 vibe coding 的人，专业工程师常常会认为：他们并不知道 AI 到底在做什么，因此对未来的软件质量感到忧虑。
但如果正在阅读的你就是工程师，请你换个角度想想——
你的老板理解你的工作吗？
或者，你的老板曾经也是工程师，但他现在对具体代码也一点都不关心了，不是吗？他或许会讨论讨论架构，但是他根本不关心代码。
是的，所有原本不是某领域专业人士，却通过 AI 做出某个领域成果的人，和你老板的心态是一样的。
大部分人其实没有那么在乎细节。一个像素的偏移、一句话的措辞、一个微小的性能问题，大多数用户都感受不到——因为专业而沉迷在细节中的你，只是在消耗自己。
我知道自己说的像是一个暴论。因为社会主流的成功价值观，是专注细节、精心打磨，以及那句经典的只有偏执狂才能成功。
但是，故事总得这么说，书才卖得出去，不是吗？
要求员工做到 100 分，他才会给你 80 分的成果，不是吗？
当然，我希望读者也不要过于二元化：
- 要么对 AI 的产物反复审视拿捏；
- 要么直接放手不管。
我觉得应该根据自己的实际情况动态调整。
如果是一个人写软件，那就不要以专业工程师的标准去审查 AI 写的代码，能跑就行；如果是一个小团队，并且已经有了一定用户，那么是该关心一下架构的事情了。
你要清楚自己在做什么，有多少资源与精力，再去决定你对 AI 的要求。
代码质量要和用户阶段匹配。如果从用户视角看上去已经不错，就没有必要让 AI 继续修改了。
克制对于细节的关注，让自己和 CEO 一样，只关注整体才能让你的效率更高。 结果才是最重要的，过程就让 AI 去掌控吧。
很多时候，你引以为傲的专业性只是职场分工给你的幻觉。离开那个办公室，它未必还有你想象得那么值钱。
这一节的最后，我想说：
一个人在某些领域，通过数十年的学习、工作积累了大量专业知识和经验，转过头却看到旁边的实习生用 AI 花 5 分钟做出了一个“小玩意”——虽然不好，但勉强能用时，心里难免五味杂陈。
这种心情，是一种无奈。
这样的心情，我也有过。但很可惜，如果只是无奈，改变不了任何事情。
2. 生产力不等于致富
如果你没有稳定的现金流，就别着急创业。AI 不是财富密码，它只是廉价又高效的生产力。
当下，一个人维护 10 个 App 不是问题，甚至其中可能还有 1、2 个大型项目；一个人可以做漫画故事，甚至动画；一个人也可以每天发 100 篇文章到各种社交媒体。
生产力再一次爆炸了，社交媒体上也充满了各种 AI 暴富故事。继科技新贵之后，或许马上就要有“AI 新贵”这种说法了。
因为 AI 的使用门槛只是会说话、会打字，再加上社交媒体的狂轰乱炸，会让人产生一种幻觉——
我做我也行。
是的，AI 时代不仅 LLM 的幻觉很难消除，人的幻觉也很难消除。
但是。
一个短片的成功，靠的不是视频本身。Seedance 能解决的，只是给你一堆精美的、会动的画面。
一个成功的软件，也不是代码本身。或许有些读者会觉得，关键是创意，是创新——也不是。
创意并不值钱。至少在没有执行之前，创意只值 2 元。生产力也不值钱，它只是资源。
任何一个项目的成功，都需要多个方面做对，然后还需要再加上一点运气。是的，有时候你什么都做对了，也不能成功，你差一点运气。
代码不是写出来、在本地能运行就结束了。
你需要：
- 部署；
- 上架；
- 推广；
- 持续迭代、维护；
- 关注竞品的功能动向。
你很可能都做对了，但是竞品突然免费了，用户一夜之间就会抛弃你。
你可以把代码写得像诗一样，但是一个月曝光只有 100，用户根本发现不了你。
2.1 别陷在你的领域
AI 是认知的放大器，它能够放大你的长板，也能放大你的短板。它太容易让你在熟悉的领域里持续工作了。
一方面，是因为它永远积极的发言方式；另一方面，是因为有你的专业能力加持，它更容易交付快速的阶段成果。
AI 写出不好的代码 → 你快速决策修复方向 → AI 再次执行 → 成功 → 多巴胺分泌 → 下一个功能……
要小心这种源源不断的生产力带来的陷阱。
不是有越来越多的人把 vibe coding 比作毒品了吗？我也曾一写就停不下来，我可以从早晨 7 点写到凌晨。
你真正需要大量投入时间的，是你最不擅长的领域。你应该在那些地方多与 AI 打交道。
靠把一件事做到极致然后获得成功的天才太少了。大部分人成为达芬奇、乔布斯的概率太低，别赌自己是那个天选之人。
如果你是程序员，接下来打算做一款软件，先去做市场调查和竞品分析，不要先打开 IDE。
同时，在竞品分析过程中，不要把注意力放在功能清单上。相信我，你甚至都不需要下载它们。他们能做的，AI 大概率都能做，除非你想写一个全新的操作系统。
你真正需要关注的，是你不擅长的部分：
- 他们是如何引流的；
- 他们是如何定价的；
- 他们主要活跃在哪些地区；
- 他们主要活跃在哪些社交媒体。
3. 不要沉迷 AI 小技巧
几乎一夜之间，我所有的时间线都只有一个话题——AI。当然，除了那些美丽的女孩们，我的世界线上唯一不变的、从不跟风的就是福利姬了。
不要沉迷收集 AI 技巧，也不要相信任何 AI 致富神话。
通过 AI 突然改变命运的人，是有的。但我看到的大多数，原本就在自己的领域里有积累、有见识。我只见过很少的个例，是在毫无积累的情况下，通过 AI 改变命运。
我也曾经有 100 多个书签，用来保存各种 AI 技巧。不过很快我就想明白了：
我很傻。
有几个原因。
3.1 没有人会真的分享秘密
很早我就想明白一个道理：
如果一个技巧有价值，那么它大概率不会被分享出来，除非它产生的价值不如流量收益高。
你发现了一个金矿，你做的第一件事一定是左顾右盼，看看身边有没有其他人对吗？
3.2 大部分媒体工作者不太在乎内容的真伪与价值
充满你时间线的作者，大部分是专业自媒体工作者。
他们的工作目标并不是生产有价值的内容，而是不停地出现在你的时间线里。
尽量生产有价值的内容，只是达成这个目标的手段，甚至不需要真的有价值，只需要看上去有价值。
当然，这个世界上还是有分享有价值内容的人，只是不多。
所以在这个目标之下，你完全可以过滤掉社交媒体上 99% 的内容，尤其是那些排版精美、标题诱人、封面图好看的内容。
没有人有精力找一个 skill 下载下来，用一下午，然后再写一篇文章、精细排版发出来。如果他这么做了，他就来不及完成发布任务。
很多技巧根本毫无价值。
大部分看起来不错的技巧，只是另一种过度营销，只是它不需要让你付费，但你的精力也很宝贵，不是吗？
3.3 你的优化技巧无法提高模型上限
Prompt、skill、各种上下文管理技巧，本质上是在弥补 LLM 本身的一些能力缺陷，但突破不了模型上限。
不过，好消息是模型本身的智力水平仍然发展很快。
所以你会发现，随着模型更新，你以前很多 prompt 和 skill 已经用不上了，甚至会变成负优化。
从我的经验来看，没有必要在使用 AI 的技巧上花太多时间。
研究技巧的时间，不如做点其他事情，等 OpenAI / Anthropic 的下一代模型。
Anthropic 最近不就有技术人员说，自己已经不太花时间写 prompt 了吗？但就在两三个月前，推特上一个好的 prompt 能被转发数十万、数百万次。
我最近的一个例子是：无论是 Claude Code 还是 Codex，在移动 App 的界面上都很难让我满意。
我也试过 Claude Design、Open Design 和一些 prompt，但都没有达到我的要求。
这些方法在 Web UI 上表现不错，但实际上，这是因为模型本身就在 Web 上表现不错。
如果你好奇我打算怎么解决，我的回答就是——等下一代模型，当前能做到什么样就做到什么样。
非 vibe coding 的读者，到这里就可以停了。 后面都是 vibe coding 的心得分享。
4. Codex 比 Claude Code 更让人放心
我是从 GPT-5 开始，主力编程工具就只用 Codex 了。在工作中，我也会随机用一下 Claude Code，但不知道是不是运气问题，九成情况下，Claude Code 的表现都很差。
我对 coding agent 的要求只有一个：
我给一个 prompt，coding agent 改完后，需要能够一次跑通。 可以有点小问题，但是整体要可以跑通。
在这点上，Claude 最新的模型还是很难做到。
之前的 Claude，也就是 Sonnet 3.7 之前，太容易自作主张：
- 修改一些不相关的文件；
- 绕过一些测试；
- 尤其是绕过测试，这让我非常讨厌。
从 Sonnet 3.7 到近期 Opus 4.8，情况稍微好了一点，但是仍然很容易产生 bug。一个 PR 往往需要反复修改。
而最近一次测试，Claude Opus 4.8 又产生了自作主张以及偏离 prompt 的行为，并且比之前还要严重。
同时，让我觉得很奇怪的是，它似乎很难理解我的意图，也不太理解项目。
而我的项目一直都是 AGENTS.md 与 CLAUDE.md 同步更新的。说到 CLAUDE.md，它甚至出现了不遵守文档的情况。
所以，目前我日常的 vibe coding、coding review、安全审计，用的都是 Codex 系列。
我认为 Claude Code 目前处于被过誉的状态。我想原因有以下几个：
工作流迁移的成本。Claude code 的先发优势太大了，不少人已经围绕其搭建了完善的工作流；或者对该模型有较高的熟悉度，知道什么样的任务它可以，什么样的任务大概率会出错。
自媒体上的惯性。我觉得自媒体是有惯性的，当一个流量密码被验证后，大家会不断重复这个话题，直到这个流量密码完全失效。而就像前面说的，大部分自媒体工作者不太关心自己的内容，可能都不关心 vibe coding。只要发布与 Claude code 的内容持续有流量，那么它们会继续吹捧。
OPENAI 近期的负面舆论。这一点，不点评。
什么？你问我 Gemini？我感觉好像 Google 不太在意 vibe coding 这件事，至少目前是这样。
5. 记录、测试更重要
Prompt 确实越来越不重要了。
以前我让 agent 帮我写一个功能，往往是描述越丰富，执行结果越好。通常要包含：
- 业务逻辑；
- 数据流；
- UI 描述。
但是，从目前 Codex 5.5 来看，写一句话和写一段丰富的指令，两者差不多。
这导致我迭代功能的速度更快了，但测试难度也变大了。
所以，我近期几乎没有做任何新功能，而是耐心地把项目里的所有 bug 和安全问题都修掉，然后开始写各种测试脚本，直到整个项目都可以通过自动化 E2E 测试。
我认为，在项目已经成型的中后期，停一下功能迭代进度，花时间维护好各种测试脚本，比让 AI 不断写功能更重要。
当然，传统 coding 也该这样。
我想说的是，代码可以少 review，甚至不 review，但编写自动化测试这一步需要耐心。
因为你的代码会随着迭代不断变化，所以要防止两种情况：
- LLM 因为旧测试脚本而反向修改代码；
- LLM 在没有更新测试脚本的情况下就开始写集成测试，导致代码不过测，又被它反向修改。
LLM 永远只关心当前看到的东西。它们没有历史记忆，而你也很难有，因为迭代量太大了，代码也不是你写的。
所以我通常会这么做。
5.1 维护好 AGENTS.md
AGENTS.md 的重要性应该被低估了，我认为它比任何 skills、插件、技巧都重要，它是 repo 中最重要的文件。
这是非常值得花心思维护的文档，也是我在所有 repo 中唯一花心思维护的文件。
我会设置一个自动任务，让 AI 根据 commit 更新文档，间隔由项目迭代频率决定。
而我基本每 3 天到一周，会循环 review 一下所有项目的 AGENTS.md。
5.2 给 agent 一个法则
当代码不通过测试，立刻比对业务代码与测试文件的提交记录，按照“谁更新，谁更可能准确”的原则分析，然后向我汇报，不得自行修改。
可能你会问：
代码更新了，测试脚本没更新，这很好理解； 但是测试脚本更新了，代码没更新，这种情况怎么会发生？
如果你会同时开 10 个 worktree，并且其中一些功能有重叠，那么某些 agent 在工作中会顺手更新测试，某些不会。
最终合并的时候，就可能出现这种情况。
这种时候不能让 AI 自动处理，需要人工接入，所以要让它们先根据 commit 顺序给出判断，然后交由你来判断。最终一定要让你来裁定处理行为。
当你发现项目已经可以稳定通过自动化 E2E 测试，并且最后连人工回归测试都显得多余时，你就可以开一个 coding plan 订阅，然后开多个 worktree，开始并行开发功能。
给非开发人员的建议： 虽然测试很重要，但不要在早期阶段编写过多测试脚本。 这会让 AI 工作的 scope 变大，因为无论 Codex 还是 Claude Code，都开始倾向于在完成工作后跑一下测试，或者更新测试文件。 但是，早期产品变化太大，测试脚本的意义很低，有时候还会把特性变更判断为 bug。
通常在早期，我完全不让 AI 写任何测试脚本。
只有当我认为某些功能不会有大改动时，才会开始写一些单元测试。
复杂的集成测试会等到产品定型后再写；E2E 则要等到 UI 设计体系也基本稳定之后。
6. MVP 阶段不要跨平台
我的第一个项目，是用 Flutter 做了 iOS、Android 与 Mini app 的多平台版本。
这是我的惨痛经历，我已经不再这么做了。
之前在公司上班的惯性经验，让我觉得跨平台意味着更多用户。但是自己小团队作战时，我发现跨平台简直是灾难。
即便 Flutter、React Native 这类方案已经很好，但还是灾难。
实际情况是，你第一版的 MVP，大概率和 6 个月后的产品不是同一个东西。
产品的迭代过程就是忒修斯之船。
跨平台在早期阶段，除了拖慢你的速度，没有任何意义。兼容的平台越多，意味着每次变更你需要确认的次数越多。
你可以选择跨平台技术栈，但在第一阶段，只关注并发布一个平台，会让你更快一些。
我还建议：如果 Web 可以跑通你的产品，Web 仍然是验证 MVP 最好的平台，而不是移动端。
无论 Codex 或者 Claude code 在 Web 领域的开发已经做得很强了，这里主要不是编码能力的强，而是 UI 的美观度，自动化测试的便利程度，以及流量获取的快速程度——APP 引流很难。
这一节的最后一个分享：
过去 Flutter 总是我的客户端技术栈，但我现在开始怀疑 Flutter、React Native 是否还是好的选择。
Flutter 这样跨平台技术栈诞生就是一份代码到处运行，可以放大生产力。但现在生产力不是问题了，大家都在写 SaaS、APP 的时代，体验更重要。
所以当我的某个 Flutter 项目，始终无法交付满意的 Liquid Glass 效果。我动过用 swift 单独写 iOS 客户端的念头。
我想我的下一个 APP，可能会考虑每个端都用原生方式写。
但我还没想好怎么做跨端交互一致性。目前来看，design.md 的约束还不够强，或许要等模型对 UI 有更好的理解。
一致性的解决方案，可能像我前面说的一样，等下一代模型。
7. Monorepo 是更适合 AI 的项目组织方式
一开始，由于 LLM 的上下文窗口都很有限，所以我最早的项目通常都是前后端 repo 拆分。
但是如今，我都采用 monorepo 的方式。
一方面是 Token 窗口没有那么局促了，另一方面是可以让 agent 在改动时看到全景。
前后端分离 repo 经常需要花时间对接接口。
而现在，我只需要输出需求，不用专门花时间在两个 repo 的 agent 之间来回调试接口。
所以，即便是早期前后端分离 repo 的项目，我现在也会把它们放进一个大文件夹里，然后把 coding agent 的项目根目录直接设成那个大文件夹。
8. 交互设计是 LLM 最大的短板
传统编程在移动 App 领域，仍然有一个优势：
可以做出动人的交互体验。
注意，我这里说的不是 UI，而是 UX / UE。
目前的 LLM 在 UI 方面仍然很差。无论什么 skill、prompt、插件都不行。核心原因还是底层能力没有跟上。
虽然目前在 Web 上有一些突破，但是仍然需要花时间与 agent 反复多轮沟通。
而移动 App 这种更吃交互的产品形态，LLM 仍然很不行。
所以，如果你正在尝试用 vibe coding 写 App，我建议不要在这方面花太多时间。
把交互做得朴素、符合逻辑，就可以了。
不同于 UI 可以截图，UX / UE 连描述起来都很困难。
9. 最后一些话
这些不是我近期 vibe coding 的经验，是我过去常常和团队说的，也想分享给大家。
“锤子在你的手里可以敲钉子，但是在米开朗基罗手里可以雕刻大卫。有差异的不是锤子。”
在现在 AI 的时代，我觉得要改一改。
“锤子在你的手里可以敲钉子，但是在米开朗基罗手里可以雕刻大卫。有些人与 AI 谈心，有些人用它写 APP，有些人用它做视频，有差距的不是 AI。”
评论
💬 评论功能即将开放