几个月 vibe coding 实践——少用羸弱模型

不要用羸弱 AI

这个全文最重要的一点。目前真正能干好活的只有 Codex 和 Claude。

使用羸弱 AI 的代价就是------一次又一次的返工，不断消耗自己时间和精力 。极强的负反馈，会让你极其疲惫而进度始终没有推进。而且国产普遍没多模态无法识图，token 输出速度极慢，甚至还要排队。

之前 8、9 月的时候 qwen-coder 免费每天 2000 次调用，当时用的是真红温，调用 Edit 工具都能连续失败 10 几次。不过免费的也就不要求太多了。不太清楚现在 qwen 写代码能力怎么样（现在 qwen-coder 的免费额度也被砍掉了）。

minimax、glm、kimi、deepseek、mimo 等国产模型都用过，只能说这些国产模型治好了我 vibe coding 瘾。矮子拔高个的话 deepseek-v4 还不错，价格在里边是最便宜的，直接买官方 API 就行。简单写些功能足够了。

我的主力是 codex，吃遍了各种国产 AI 的答辩后，使用 codex 打开了新世界的大门------指哪打哪。每次写下一个 prompt 就跟许愿一样，codex 一定能帮我完成梦想。

我把 tauri 项目迁移到 electron，而这期间只说了一句"帮我从 tauri 迁移到 electron，功能和原来保持一致"，完全无需任何 prompt 工程，不需要任何高端的技巧，也不需要整乱七八糟的 skills。1 小时后我来验收，上万行代码修改一次性跑通，功能几乎和原来保持一致。一次性直接启动，没有任何 bug。

codex 给了我极强的正反馈，使用 codex 进行 vibe coding 的感觉比玩任何游戏都有意思，绝对开放世界游戏，限制它的上限的只有我的想象力。

写前端代码模型一定要支持多模态

codex 和 claude 都是多模态模型，而国产基本都没多模态的 AI ，UI 问题几乎没法改，你只能口述你看到的画面，然后一次又一次返工，一次又一次红温。

国内多模态只有 Kimi 和 Qwen。其他文本模型虽然提供了视觉 MCP，本质还是靠别人描述图片，比如 MiniMax 的视觉 MCP 就是通过 Gemini-flash 看图。一个是自己亲眼所见，一个是听别人口述画面，信息密度完全不一样。

不过现在文本大模型只是中间的过渡态，之后大模型方向肯定都会往多模态的方向走。比如 deepseek 最近在灰度视觉模式。观察到 deepseek 这次的 v4 版本叫做"预览版"而不是"正式版"，我猜测 deepseek"正式版"就是多模态版本的 deepseek。

coding plan

之前使用 glm 的时候，速度真的慢的离谱，也不知道现在改善没有。minimax 优势是量大管饱，但其他怎么样你别问。我感觉模型能力 2.1>2.5>2.7，一代不如一代。

云厂商也有卖 coding plan，不过几乎都是严重的超卖 ，速度非常慢。之前用火山云，10 分钟就吐出 100tokens，就运行了一行启动命令，而且居然启动失败了！?

如果真要买订阅 coding plan，一定不要买年费，现在模型一个月一个样。买年费 coding plan 绝对是最亏本的买卖。

现在各个国内厂商 coding plan 很多要抢，额度不够用、政策经常变来变去、非透明的隐藏限制。deepseek 按量付费的方式其实反而划算------缓存命中率极高，速度快，价格低。也不需要搞什么订阅，官网直充，按量计费足够便宜。不过很明显能力和 codex 差距还是比较大的（这价格要啥自行车）

使用什么 Agent？

IDE: trae、cursor、qoder
插件：copilot
CLI: codex、claude code、opencode、openclaw

哪怕是同一个模型，不同的 Agent 效果差距也很大。我个人推荐的话：

有购买官方 codex，直接用 codex 就好
claude 模型，使用 claude code
其他模型，使用 claude code 或者 opencode

现在感觉 IDE 作用不是很大，AI 写完后功能测试跑起来没问题，review 下没啥问题就能提交了。IDE 随便选一个自己顺手的，甚至不用都行

使用什么编程语言

不走跨平台：原生语言，比如 macos 使用 swift，安卓 kotlin/java
需要支持多个平台
- 有足够的资源、有精力、有团队：每个平台各自写原生
- 独立开发资源有限：electron 和 flutter。他们都是经过大量环境生产环境验证过，并且能在不同平台能保持渲染一致性。tauri wails 这种小众框架还是慎用，具体可以看：。kotlin 也支持跨平台，安卓肯定使用没问题，但其他平台兼容性和生态不详。

前端技术选型

使用 Electron 浏览器套壳的另一个关键原因，在于能够充分利用前端领域蓬勃发展的生态系统------这些成熟的工具和库不仅能极大地提升开发效率，还在许多情况下直接免去了重复造轮子的必要：

Vite 8：高性能打包。
React：相比于 Vue 等其他框架，AI 在 React 场景训练数据更多。
TypeScript：JavaScript 语法过于灵活，虽然任何写法都能"跑起来"，但代码的可维护性和最终运行结果是否符合预期往往无法保证。TypeScript 可以通过引入静态类型检查并启用严格模式，让开发者在编码阶段就能捕捉到类型不一致等问题，从根源上提升了代码的健壮性。
shadcn/ui：一套现代化的 UI 组件库。与 Element-UI、Ant Design 等传统组件库不同，shadcn/ui 并非作为 npm 依赖包安装，而是以可复制、可修改的源代码形式直接下载到项目中，方便进行深度的定制和二次开发。其开箱即用的样式也足够简洁美观，这也是选择 React 的原因之一------Vue 生态中目前尚未出现类似机制和风格的组件库。
Tailwind CSS：一款原子化的 CSS 框架。
oxfmt / oxlint：基于 Rust 构建的前端工具链中的格式化工具与代码检查工具。oxfmt 相比 Prettier 的格式化速度提升约 45 倍，oxlint 相比 ESLint 的检查速度提升 50--100 倍，在大规模项目和 CI/CD 流程中能显著缩短等待时间。
vitest：专为 Vite 项目设计的测试框架。
zustand：一个轻量且高效的状态管理库，采用简洁的 hooks 风格的 API，并且无需 Provider 即可直接在 React 组件中使用，避免了繁琐的样板代码。
drizzle（可选）：一款 TypeScript 优先的 ORM。当然也可以直接编写原生 SQL------反正都是 AI 在写，用 ORM 还是纯 SQL 差别其实不大。

其他值得一提的工具还包括：

chrome-devtools-mcp：为 AI 助手提供的 MCP 工具，使其能够控制浏览器和 Electron 应用进行调试与自动化交互。chrome-devtools-mcp 会优先利用浏览器的无障碍树来获取界面选项并执行点击，而不是直接读取整个 DOM 结构。
Rspress：基于 Rust 工具链 Rspack 构建的静态站点生成器，在启动速度和构建效率上都表现出色。与 VitePress 在功能定位上类似，具体选择哪一个更多取决于个人偏好和项目需求。
GitHub Actions：用于实现云端自动打包，并在代码打标签时自动发布到 GitHub Release，同时支持 macOS、Windows 和 Linux 等主流操作系统。一套配置便能同时在 macOS、Windows 和 Linux 三个平台上完成打包，配合 electron-builder 生成不同平台的安装包并一键发布。

UI 怎么做

可以使用 shadcn+ui-pro-max skills，效果还行。当然还有先用 figma-mcp 和 pencil-mcp 先画产品原型，再做前端。不过如果是做自己的项目的话，不如直接让 ai 改前端来的快

Codex 最大的问题是：卡片套卡片、前端写文字注释、分割线......

不过稍微加点约束，codex 还是勉强能做的。图 1 是纯让 codex 自己发挥，图 2 是 ui-pro-max skills+约束"不要使用卡片、不要在前端写注释、尽可能避免分割线"

有必要使用 superpower？

superpower 提供 brainstorming、writing-plans、TDD、systematic-debugging、code-review 等一套完整的 AI 编码工作流。不过有以下问题：

太慢 --- "6 小时还没跑完小任务"、"写一份计划来回审查快一小时"、"每次对话都要走 skills，小功能点也走完整流程" 。AI 发散性思维，一直可以给你找出新的问题。比如你要让 AI 跳出你方案和代码的毛病，那 AI 永远可以在各个角度去找出各种毛病出来
流程过重 --- spec 和 plan 分离没必要，模型已经够强的话，spec 写完直接写代码就行
子代理体验差 --- 现在多 Agent 技术其实没这么成熟，混着用问题可能不如一个 AI 来干。一个 AI 搞不定的换多个相同的 AI 还是搞不定。

这个工具想法确实很好，最大问题还是太重，容易把简单问题复杂化。

其实自己简单写个 skills 也能达到类似的目的。而且很多时候，限制模型能不能写出让你满意的代码，还是看 AI 模型能力本身 ，而不是各种 skills。skills 只是锦上添花。比如你要是使用某些比较弱的模型来干活的话，计划写得再详细，它一样不遵循命令乱写代码。

mattpocock/skills 这个 github 仓库介绍的也挺不错，也可以参考下。下面分享我自己的使用经验：

明确需求

与其用多 Agent 让 AI 与 AI 之间去对齐，不如让 AI 与你对齐，你究竟想做什么功能？可以这样问模型：

我要完成 xx 功能，你觉得需要反问我什么问题，确保更好完成这个功能？先探索代码，不要开始写代码。

多跟 AI 讨论细节 ，再让它写代码。如果功能比较复杂，就让 AI 输出个 md 技术文档，新开个窗口引用这个文档来干活，避免上下文污染。如果有了文档，AI 还没法做好，说明 AI 能力不行，得换个 AI。

反问和文档是约束 AI 的行为，避免 AI 无限制的发散。用 AI 做执行，人做决策。不要试图用流程约束 AI，而是把你的意图说清楚，让它快速交付，你来验收。流程越短，token 越省，出错越少。

还可以搞个术语文档 CONTEXT.md，来与 AI 对齐。尤其在公司内部，有很多自创的名词和工具的时候额外有效。

AI review

我目前的做法：Codex 主力写代码，调用 claude code 无头模式，通过 DeepSeek 负责 Review。最好不要同一个 AI 自己 review 自己，就像自己当裁判又当球员。

codex 需要告诉 claude code，当前修改代码的业务背景和目的（而不是具体的代码细节），而且要求 claude code 只关注本次 git diff 的代码，不要关注其他未修改过的代码。DeepSeek 确实能发现不少问题，而且很多建议质量很高，Codex 采纳率也挺高的。

在 AI 没出现之前，程序员也经常需要互相 review 才能提交代码，换其他人来 review 自己代码经常能发现不少问题。现在 AI review 也是同理。不过我感觉 review 一次就足够了，review 修改完代码继续 review，AI 永远能挑出各种毛病，进入死循环了

single Agent > multi Agent

至少在我的场景中，codex 在不使用多 Agent 的情况下，已经能很好完成我所有想做的事情。限制我无法完成功能的还是 5h 限额和周限额。

现在多 Agent 问题还挺多。比如：

subagent 返回给主 agent 的信息缺失了很多信息，所以主 agent 还要自己重新整理和读取做 subagent 一样的事情
多 agent 互相讨论，反应链不断扩大，聊几个小时都不一定停的下来
几个比较笨的模型互相讨论，只会将错误进一步放大
token 消耗更快，完成速度不一定更快
在写场景中，Agent 与 Agent 之间互相打架，代码会乱套

在某些场景还是比较有用：

避免上下文腐化。在探索项目和网上深度搜索内容的时候，绝大部分内容其实可以丢掉，这个时候让 subagent 总结好交给主 Agent，能避免占用主 Agent 上下文
并行开发不同功能。比如 Agent A 开发功能 A，Agent B 开发功能 B。可以单独开两个不同的分支，这样就避免在同一个分支互相干扰。不过他们可能尽可能不要有太多交集。比如一个开发登录一个开发注册，否则很容易把重叠的部分重复开发，又要互相处理冲突以及带来很多冗余的代码

不过个人建议，多 Agent 还是交给 codex 和 claude code 自己去调度，没必要自己为了多 Agent 而多 Agent。

功能测试

这个可以加进 CLAUDE.md 中，让 AI 每次完成功能后：

编译确保代码正常工作
写测试用例自测
使用 chrome-devtools-mcp，从用户角度使用 UI 交互进行测试
如果是 mac codex 用户，在 chrome mcp 不太好模拟操作的情况下，使用 computer-use 来模拟操作。不过这个比较耗费 token 点，也比较慢

AI 在写代码的时候我应该干啥？

是啊，要干啥？

建议在 AI 写代码的时候，不要干其他事情。主要是多个任务之间来回切换，极其耗费精力，容易让人焦躁不安 。最好还是 AI 干活的时候，发呆盯着 AI 干活，及时给 AI 纠正并反馈。

有了 AI 就不用学计算机了？

AI 不是在替代你的能力，而是在放大你的能力。

没学过乐理，可以听出音乐好不好听，但是你讲不出为什么好听，也说不出哪个部分做的不好
codex 认为的好看，就是前端给你套各种五颜六色的卡片，如果自己不积累点审美，自己也不知道什么样的页面才能称为好看
没有任何计算机基础，有了 AI 也能开发出软件，自己也能判断功能能不能跑，不过你无法判断写的代码是好是坏，也没法看出是否代码存在潜在的风险。

所以我认为在 AI 时代，学计算机还是有以下好处：

掌握一个领域的判断力 ，AI 可以非常好地替代执行层面，但最后的判断力还是得交给"人"。比如：AI 在不同的地方都定义功能完全相同的处理文件的函数，是不是可以抽成统一的 utils，避免重复造轮子；AI 为了实现简单，可能直接使用浮点数计算金额，甚至让前端来计算金额。如果没学过计算机，可以发现到这些问题吗？至少 AI 很强大，绝大部分其实问题不大。但假如 AI 不小心写出了漏洞百出的代码的时候，没学过计算机的你能判断出来吗？
更精确的表达和更丰富思考角度。
- 没学过计算机："这个页面有点卡，帮我优化下？"AI 可以给你加 Redis 缓存，虚拟列表，多线程。但你知道使用了这些，又给你项目增加什么额外的风险吗？
- 学过计算机："这个页面有点卡，帮我排查下什么原因？先不要修改代码"，"我不太希望引入多线程，因为会带来很多并发问题。我不太希望引入 Redis 缓存，因为可能存在缓存不一致问题。或许你可以再排查下网络相关的问题？比如没有使用 keep-alive，导致让每次请求都重新握手？"

如果只是做玩具 demo 的话，vibe coding 不学计算机也没啥问题。但如果要做生产级的项目，基础的计算机知识还是得有的，否则项目到一定程度迟早来个大的。不过像是什么 JVM 老年代新生代这种八股就没什么必要掌握了，大概知道有这个东西就行。

开发者专注设计模块接口，将实现细节交给 AI，降低认知负担，同时要持续投入系统设计，把控代码战略层面。AI 是战术型编程助手，开发者需承担战略设计职责，扎实的软件基础是用好 AI 编程的核心前提。AI 时代下软件基础知识依旧关键，完全依赖 AI 从规格生成代码、不查看代码的模式会导致代码质量持续变差，最终变成垃圾代码。

其他

CLAUDE.md 和 AGENTS.md：一个项目同时维护两个比较麻烦，可以只维护一个文件，然后通过软链接的方式创建另一个文件
修复 bug：如果有时候出现一个 AI 搞不定的 bug，换个 AI 来处理没准有奇效
代码维护：定期让 AI 检查代码，修复屎山
changelog：每次变更都让 AI 记录写了什么，可以作为一个 change log skills，让 AI 完成一个功能后，补充 changelog。changelog 主要写完成了什么功能，更多是面向用户角度，不要提及任何具体的代码细节

总结

选用 codex 或者 claude 能显著提高你 vibe coding 幸福感
多跟一个 Agent 梳理需求，远比开多个 Agent 更有用
学习计算机知识依旧非常重要