聊聊最近的 Vibe Coding 经历

最近花了很大精力在 Vibe Coding 上，当然也做出了不少东西，时间被 token 占据着，公众号也断更了一段时间。

最近一个很大的感触是使用 AI ，思维方式得转过来。第一步是"相信它能"，不信就不会去试，不试就永远停留在浅层用法；第二步是探索，在探索中碰到"不能"；碰到不能时多问一句：是模型真不行，还是我方法不对？换个提示、拆下任务、补点上下文，很多"不能"其实是"还不会用"。如此反复。

还记得春节前我有一个功能的想法，在网页 Chat 模式下沟通几轮得到一个原型界面，还是会安排开发人员去进行最终的实现。

春节期间，我决定得要自己动手去实践，于是我找了个中转站充了 50 块，客户端使用 Claude Code，接中转站的模型，就开始了 Vibe Coding 之旅。

开发了一个研发内部使用的平台，将需求、任务、待办、缺陷管理起来，后面还陆续加入了文档中心、分享中心等功能。

研发管理类的工具有很多，为什么还要自己去重复造轮子呢？

原因很简单，要想使用 AI 给团队内部提效、要想利用 AI 给客户带来价值，就必须要对 AI 有深入的了解才行。去真正做出一些东西，才可以更好的了解。

我自认为对开发非常了解，对研发内部的管理业务也很清楚，理论上来说，应该很容易借助 AI 的能力把这个系统给开发完成，但其中还是碰到了很多的问题。

• 中转站的模型能力时好时坏，有时候还会碰到直接挂掉
• UI 一致性的问题：同样的 Tab 切换，在不同的功能模块都自成一个体系
• 有时候只是想问一下情况或者让分析一些内容，但话音刚落，AI 马上就开始改代码，就像是一个初级程序员一样，特别喜欢直接上手改代码
• 添加新功能，之前的功能给改坏了

因为要做的是一个需要持续迭代的软件系统，不是一个 Demo，所以并不是说一句话让 AI 生成一个开盲盒式的系统就完事了，需要提前做很多很多的准备。

比如，以下内容需要沉淀到文档里面：

1. 前后端都需要使用什么技术栈；
2. 数据库的设计、接口的定义；
3. 每个功能模块的描述，业务目的是什么，以及该怎么去实现。
4. 每次 AI 修改完代码，修改了什么内容？

开始的时候会先做静态页的 UI 原型，包括布局和一些交互，慢慢调到比较满意之后，再让 AI 把它转换成前端的代码。等整个系统的结构差不多构建起来之后，这个就弃用了，直接让 AI 基于现有的 UI 风格进行新功能的开发。

一种有效的方法是，当一个事情反复沟通才能达到效果，我会让 AI 对多轮对话进行总结，有些规则可以沉淀到 CLAUDE.md 、AGENTS.md 中，有些是沟通话术的问题，我后续可以进行调整。

中转站前后换了好几个，最后的结论还是买正版吧。中转站质量掺水不说，而且还极其不稳定。现在模型能力越来越强，不管是用国内的还是国外的，比如 K3、GLM 5.2、DeepSeek V4 或者 GPT 5.6 来做开发，都没有任何问题。

从 3 月 11 号开始，我的主力工具就是 codex 了。从开始的 Plus 到后来使用 Pro，目前 Pro 的额度也渐渐变得不够用了，好在 Tibo 经常会进行重置。

到现在，仅在 Codex 上的 token 消耗量已经接近 200 亿了。下面就说说这 200 亿的 token 都做了些什么。

1、AI 员工平台

起初是想将内部的一些问数场景，知识库场景，利用 AI 来提升一些效率。后来跟 ChatGPT 聊着聊着，就萌生了直接做一个平台的想法。

GPT 告诉我，AI 员工也是一个员工，企业需要给他提供相应的办公环境、知识技能培训等等。我觉得这个思路不错，所以就按照员工和企业这两个维度来构建这个平台。

1. 员工侧：关注他能够做什么。
2. 企业侧：关注能给员工提供什么。

下面是一些系统截图。

2、运维工具

这个工具是基于我自己的需求构建出来的。

不同的项目都会涉及到：

1. 使用 Postman 进行接口的测试
2. 用 Navicat 来连接各种关系型和非关系型的数据库
3. 还有 SSH 和 SFTP ，也是使用各种不同的工具

现在开发的这个工具，就是将这些都集成在一起，方便平时的运维工作。在工具中，可以以项目的维度来维护里面的内容。

在实际的运维工作中，经常会有一些常用的设备语句或命令。我把这个能力也加到了工具里面，可以维护相关的设备和命令。在使用时，可以用快捷键进行搜索，直接复制或插入。

平时用到的一些小工具，比如 XML、Json、Cron 的解析等也都集成到这个工具了。

3、待办小工具

年龄越大记性越不好，所以需要有一个记事的小工具。以前也用过 滴答清单、Microsoft To Do 等，但有些地方总是不太令人满意。

现在有了 AI，可以按照自己的使用习惯和方式去进行构建，这样构建出来的产品不会有多余的功能。

工具支持 PC 端和移动端，每天随手可以记录一些事情，也可以是一个待办，普通事项也能随时转换为待办。

待办分为四个象限：重要紧急、重要不紧急、紧急不重要、不重要不紧急。在这四个象限里面，可以随意拖拽切换记录的事项。

可以给事项打 Tag，也可以把它纳入某一个事件。比如最近用 AI 写了不少项目，关于 AI 写的这些项目，可能跟效率有关，跟运维相关，或者是跟内部管理开发相关，但它们都属于“AI 做的事情”这个分类。我只要点击这个分类，就可以将所有这些事情全部串起来。

因为涉及到 PC 端和移动端，还做了一个两端之间的同步服务。

4、博客改造

周末花了一天的时间把博客给改造了一下，之前的博客使用的是 Hexo，我一直想要的一个功能都没能很好地解决：将任意一篇博客文章纳入到一个专栏里面去。虽然 Hexo 提供了类似功能，但交互和展现一直都不太满意。

另外，Hexo 还有一个问题，因为它是 Node.js 构建，速度特别慢。所以这次我直接用 Codex 把博客迁移到了 Hugo。按照我的要求，UI 样式做了相关调整，还增加了专栏功能。专栏的功能也完全是按照我希望的样子来修改的，目前挺满意的。

有兴趣可以访问我的个站点去看一看。

https://fwhyy.com

很长一段时间都是在 Codex 中使用 GPT-5.5 ，感觉完全够用了。在 5.6 发布前夕，稍微感觉有一点点降智，当 5.6 发布之后，我其实并没有感觉到能力有质的飞跃。因为当模型的能力已经远超我们所做的事情需要能力的上限时，就没有很大的感知了。

说起对能力的感知，之前有一个很深的感受。

刚使用 Codex 的时候，Plus 账号的额度并没有那么多。为了省着点用，有些功能的修改，我就还是交给原来中转站没有使用完的额度。我做的内部系统的任务列表界面比较复杂，有各种操作按钮，还有各种数据的关联。

当时做任务列表的一个优化，在中转站的模型中反复沟通：

1. 新增功能没有达到我的预期。
2. 原本是正常的 UI 还给调整坏了。

后来切换到 Codex，一次性搞定。所以模型和工具的选择，一定要高于我们需要的能力，否则就会浪费时间。

AI 除了能带来直接的效率，还有一个很大的好处，就是可以多任务并行。以我目前的经验来看，3~5 个是比较合适的，而且中间还需要合理地安排短线任务和长线任务，再多人的精力就顾不过来了。

随着模型能力的增强，使用 AI 的方式也在发生着变化，从 Prompt Engineering、Context Engineering、Harness Engineering、Loop Engineering、到现在的 Graph Engineering 。技术在发生着快速的变化和演进，作为使用者也需要不断学习和跟进。

小龙虾的作者皮特前几天还发推提到了 Graph Engineering 。 前一段时间，我觉得 superpower 非常好用，能头脑风暴、写单元测试、写实施计划等，现在 Codex 有计划、有目标，我已经不再用 superpower 了，觉得是个累赘，反而会让速度变慢。

Bob 大叔在和别人的讨论中也说到，自己不再看 AI 编写的任何代码，但并不是不约束 AI ，只要能通过各类测试就可以。

我是很认同的，定好目标、和验收标准，剩下的交给 AI 就可以了，现在的各种高级语言终将会和汇编一样，不再被人们所关注了，但也会诞生新的“高级语言”、“工程规范”等，现阶段，这些统称为 Harness 。