Vibe Coding：我越来越少逐行看 AI 写的代码——但也靠文档读懂

最近这段时间，我越来越习惯用 AI 做开发。

从编辑器里的代码补全，到命令行里的 Coding Agent，再到各家云端模型和本地部署的开源模型，基本上都折腾过。

刚开始的时候，我对 AI 生成的代码还是比较谨慎的。

AI 写完以后，总觉得应该认真 Review 一遍。

后来慢慢发现，这个想法越来越不现实。

现在让 AI 完成一个稍微复杂一点的任务，经常就是一批文件一起修改。代码一下子可能就是几百行，甚至上千行。

我这边同时推进着好几个项目，Python、Go、Rust、Node、Java 都有。如果每个项目每次都把改动全部打开、一行一行看过去，那 AI 带来的效率提升，很快就被自己人工 Review 掉了。

所以我现在的做法已经发生了很大的变化。

我不再把「看 AI 写了什么代码」当成主要的验证方式。

---

代码越来越多，根本看不完

以前自己写代码的时候，代码量其实和自己的理解能力基本匹配。

一个功能自己写下来，里面每个变量、每个函数，大概都知道为什么这么处理。

现在不一样。

AI 可以非常快地把一个想法变成实际代码。

一个需求下去，可能同时修改前端、后端、数据库、配置文件，甚至测试代码。

代码量很容易一下子膨胀起来。

这个时候如果还坚持：

AI 写完以后，我必须把所有代码看懂。

那其实又回到了传统开发模式。

而且很可能比自己写还累。

所以现在我一般只做一个大概的 Review。

看看有没有明显不合理的地方。

看看是不是突然出现了一个特别长的文件。

看看一个简单功能是不是被搞得特别复杂。

如果发现代码结构开始失控，我会让 AI 自己拆分、重构。

但如果整体结构没有明显问题，我不会再花大量时间去逐行检查。

因为我有另外一种更直接的验证方式。

直接用。

---

UI 对我来说，现在更像测试工具

这里的 UI，和传统产品开发里的 UI 不太一样。

我现在做工具类项目的时候，第一版 UI 通常并不会特别在意好不好看。

甚至可以说：

UI 只是一个让我能够真正操作系统的入口。

我真正关心的是整个全栈系统能不能跑通。

数据模型是不是合理。

API 是不是合理。

前后端怎么协作。

Agent 怎么调用 Tool。

任务怎么执行。

状态怎么流转。

异常情况怎么处理。

这些东西如果只看代码，其实很难一下子感受到。

但是把它们串起来，做一个能操作的界面以后，问题很快就暴露出来了。

点一下就知道。

跑一次就知道。

换一个参数就知道。

故意操作一个异常流程，也很快就知道。

所以现在对我来说：

UI 首先是功能验证工具，其次才是视觉设计。

---

先把底子打实，UI 以后再做好

这也是我现在做项目和以前最大的区别之一。

我现在做工具类项目，几乎都是先写成命令行。

而且会刻意把它切成一段一段：构建、草稿、发布、记录、校验。

每一段都能单独重跑，跑完把结果落到文件里，下一段再读这个文件。

这样做的好处不是优雅，是可定位：出问题的时候，我能立刻知道是哪一段出的，然后从那一段单独重来，不用整条链推倒。

等这条链我自己用了几个月、确认它确实每天都在干活，才考虑在上面加一层界面。

加界面这件事，晚一点做反而更准。

因为这时候已经知道：

哪些功能真的需要。

哪些操作根本没人用。

哪些步骤可以合并。

哪些东西应该隐藏。

哪些功能值得继续做。

所以我的习惯慢慢变成了：

先能用，再好用，最后再好看。

---

很多设计，是用出来的

这可能是 Vibe Coding 给我最大的一个变化。

以前做项目，总觉得应该先把设计想清楚。

实际上很多东西根本不可能一开始就想清楚。

尤其是自己做工具。

你只有真正用起来，才知道哪里不舒服。

比如原来觉得两个操作应该分开。

用几次以后发现，其实完全可以合并。

原来觉得一个功能应该放在这里。

真正使用以后，才发现放到另外一个地方更自然。

我有个自己每天在用的联系人助手，每个联系人下面挂着几个操作：AI 草稿、AI 画像、本地备注、导出。

这四个东西的排列顺序、去重逻辑、清空要不要二次确认、时间戳和滚动条怎么统一，没有一条是我一开始设计出来的。

全是装上手机点过之后，一次一次改出来的。

坐在电脑前想，想不出「这个按钮该排在第二个」。

甚至使用过程中会突然产生新的想法：

这个东西是不是可以抽象成 Skill？

这个流程是不是应该变成一个任务？

这个操作是不是可以让 Agent 自动完成？

然后继续改。

改完继续用。

再发现问题。

再继续改。

所以现在我的开发过程已经不太像传统的：

设计 → 开发 → 测试 → 发布

而更像：

设计、实现、使用、测试不断交叉进行。

很多设计不是一开始就确定的，而是在真正使用以后慢慢长出来的。

---

边界不是靠读代码守住的

有一类问题，跑起来才能发现，读代码反而容易自我安慰。

还是那个联系人助手。它是本地优先的，AI 功能只拿得到三样东西：姓名、由手机号段推导出的归属城市、你自己的意图。

手机号、邮箱、整本通讯录，一个字节都不出设备。

这条边界写在代码里，但成立的那一刻不是写下的那一刻，是功能真正跑起来、你确认它从设备里取走的确实只有这三样的那一刻。

光读代码，很容易以为自己守住了。

所以我现在的习惯是：改完先跑一遍校验，再决定下一步。

能自动校验的，就别靠人眼。

跑了再说，比读完再说便宜得多。

这个思路甚至被我反过来用在了 AI 自己身上——我在工作台里加了一个 PSE 三角色闭环：Planner 拆任务、Specialist 干活、Evaluator 独立验收（这套模式我在 《AutoGen PSE 架构解析》 里展开写过）。Evaluator 的约束非常有意思：

它没有写文件的权限，也不跟 Planner 「讨论」，只基于自己跑出来的证据下判决——PASS / PARTIAL / FAIL / BLOCKED。

而它的铁律是：不信任 Planner 的陈述，自己动手验证才是证据。 我读它的角色定义时差点笑出声——「Planner 说完成了不算证据」「看起来没问题，PASS 被禁止」。这不就是把「别光读代码，跑起来才算数」这句话，写进了给 AI 的指令里么。

还有一个更朴素的例子。那个每周投资回顾的技能，第一步是数据体检：跑一遍计算管线，扫出「年化收益 1e19%」这类失真值再往下走。以前这种数字失真，靠人读代码是发现不了的——那是一堆 CSV 和计算脚本搅在一起的结果，眼睛根本盯不住。但让校验脚本先跑一遍，问题立刻现形。把「该由谁判断」想清楚，比把代码读完，重要得多。

---

跑，不代替读懂——但读懂也可以靠机制

说到这一步，有个很自然的反问：那你是不读代码了吗？短期了解不了项目，团队分享怎么办？

我得诚实说：跑系统验证，确实不等于掌握全貌。

靠「跑」来判断系统对不对，和靠「读」在脑子里建立一个能复述的心智地图，是两件事。前者验证的是结果和边界，后者负责的是「能不能把一件事讲明白」——而后者恰恰是团队协作、带人、分享需要的。

我的选择不是假装读得过来，而是承认它，然后用一套轻量机制去补「能讲明白」这块。

每次让 AI 干完一摊活，我会让它顺手产出三样东西：

• 架构文档：它不是一行行代码，而是决策摘要——这块为什么这么拆、为什么选这个方案。
• README 更新：让项目随时有一个「现在是什么、怎么用、怎么跑」的自描述入口。
• TODO 留痕：记下「下周可能就变」的方向，让演进路径有迹可循。

这三样东西合在一起，正好对应三个问题：为什么（架构文档）、是什么（README）、要去哪（TODO）。

所以「短期不了解项目」是真实的，但它是短期的，而且被这套机制补上了。跑负责兜住质量，文档三件套负责兜住「能讲清楚」——两件事我用不同的方法各做了一半，而不是靠硬读硬背去撑。

需要面对面讲的时候，我通常让 AI 基于这三样东西，再生成一份讲述提纲：这周改了什么、为什么改、下一步动什么、踩过什么坑。有骨架在，分享就不至于卡在「细节想不起来」上。

---

我好像越来越像一个测试工程师

这也是一个挺有意思的变化。

以前：

程序员写代码，然后自己测试。

现在：

AI 写代码，然后我测试。

而且我测试的并不只是单元测试。

更多时候，我就是把自己当成一个真实用户。

从头走一遍流程。

点一下。

再点一下。

换一种操作。

故意输入错误。

看看系统会发生什么。

如果不符合预期，就告诉 AI：

这里不对。

这个状态应该这样处理。

这个交互不太合理。

这里应该再加一个操作。

然后 AI 再去改。

所以现在很多时候，我甚至不需要先去研究代码到底哪里出了问题。

先把问题描述清楚，让 AI 去定位和处理。

有个前提：描述的是现象，不是猜测的原因。

「点了导出没反应」是现象，比「我觉得是文件路径错了」有用得多——后者会让 AI 直接去改那个它其实没坏的地方。

如果它修得不对，再继续反馈。

这其实已经很接近一个持续循环的开发过程。

---

AI 写代码，已经不是最难的事情

AI 写代码现在已经足够快了。

真正麻烦的是，怎么判断它做出来的东西是不是自己真正想要的。

Vibe Coding 并不是「不需要懂代码」，而是「不需要把理解代码的时间全部花在逐行阅读上」。真正需要掌握的，反而是系统结构、边界、验证和判断。

但这个「验证」也不一定意味着人工逐行 Review。

至少对我现在这种开发方式来说，更多是：

把东西跑起来，然后真正使用。

代码是实现。

运行起来的系统才是结果。

所以我现在对代码 Review 的要求也变了。

不是要求自己确认每一行都没有问题。

而是看整体结构有没有失控。

一个文件是不是越来越长。

一个模块是不是越来越复杂。

有没有明显重复。

有没有为了一个简单需求引入大量没有必要的东西。

这些问题发现以后，再让 AI 去处理。

剩下的事情，交给运行结果和实际使用来验证。

---

我在攒一个工作台

这些事情重复得多了，我最近开始把它们往一个地方收拢。

一个自己用的工作台（就是我最近在折腾的 resolve-studio）：LLM 后端、工具集、Agent 循环、技能包、MCP Server、审批流、沙箱，都做成可插拔的部件。

底层用的是 Cordis 的依赖注入容器。核心是一个念头：一切皆插件。LLM 后端是插件，工具是插件，Agent 循环是插件，审批是插件，连前端 CLI/Web 都是插件——由一份 YAML 配置把它们组合起来。

所以真的做到了「换一份配置，就组装出另外一个运行时」：

同一批部件，换套配置就从 Web 变成命令行，从在线模型变成离线 mock。

运行时不改代码，能力却完全两样。有个很直观的体现是 Fast Path——纯算术这种确定性输入（3+4 → 7），根本不用碰模型，前置一个纯规则的预处理器直接短路秒回。那一刻我意识到：能确定算出来的，就别让 AI 用猜测去兜。 这和「能自动校验的就别靠人眼」是同一个道理，只不过这次应用到了 AI 自己身上——它连模型调用都能省。

但更有意思的，是这些机制都不是我「设计」出来的，而是边做边想，慢慢自己长出来的：一开始我也没想造什么「快路径系统」，只是觉得「能确定算出来的，就别让 AI 猜」，顺手写了 Fast Path；用着用着，发现内置匹配盖不住长尾，就顺手让模型自己写检测器（codegen）去复用；再往后，好用的小插件不该只躺在数据目录里，于是又顺其自然加了「晋升」让它们转正进源码。这条 开发 → 持久化 → 复用 → 转正 的链，是一路用、一路想，慢慢浮现出来的。第一次问「2024 是闰年吗」，模型当场写了检测器；之后再问同类问题，连模型都不调用。

我不太信「盯着目标硬想、靠应激逼自己」能出好点子——那往往挤出来的都是套路。反而是手里有件自己真心在做的事，人放松、放得开的时候，好点子会自己冒出来。Vibe Coding 把「推翻重来的成本」降到很低之后，我更有余地去慢慢做、慢慢长，而不是急着把眼前一摊应付过去。

得承认，这套节奏有个前提：你手里得有件自己说了算的事。做成自己用的工具、自己的作品，节奏才由你掌控；要是被外部指标、deadline 死盯着，人也很难放松下来让点子长出来——那种处境下，我大概也只能退回更高效、但也更紧的做事方式。它是给「能自己做主那部分工作」的人的一种不同节奏，不是放之四海皆准。

这套「一切皆插件、一切可变点推到配置层」的架构，我单独写过一篇 《Cordis 插件化 Agent 运行时》 展开讲。

这个工作台还远没定型，很多地方下周可能就变了。

但有一点是确定的：它不是先画完图纸再开工的。

而是我按上面这套方式用着用着，慢慢长出来的。比如那个「每周投资回顾」的技能，就是我先用着自己手动跑数据体检，跑了一阵觉得该把它自动化了，才让 AI 搭建起来——结果又顺带长出了 PSE 三角色来兜质量。

---

我现在的 Vibe Coding

如果一定让我总结一下现在的开发方式，大概就是：

先想一个方向。

让 AI 快速实现一个能运行的版本。

自己直接使用。

遇到问题，让 AI 处理。

使用过程中产生新的设计想法。

继续实现。

继续测试。

继续调整。

等整体架构和功能逐渐稳定以后，再重新把 UI/UX 做漂亮。

我不再「先花很长时间把所有东西设计完」，也不再「把 AI 生成的每一行代码全部看完」。

不过有一点，其实一直没变——我从来都是一块一块做。

以前手写代码的时候就是这样：一个功能写完，自己验证通过，再写下一块。数学解题也好、工程开发也好，归根到底都是「按步骤走，每步验过再进下一步」，问题始终可控。

Vibe Coding 延续了这条底线，只是把每一块的实现换成了 AI：我把任务切成一块一块交给它，做完一块、我确认没问题，再让它继续下一块——而不是一次性把整个需求丢给 AI 让它一口气写完。

写代码的活交给 AI，但「做完一块、验过再进下一块」这个节奏，是我从一开始就有的，不是被 AI 改变出来的。

边设计，边开发，边测试，边迭代。

AI 负责把想法快速变成现实。

而我负责不断判断：

这个东西到底是不是我真正想要的。

这可能才是 Vibe Coding 给我最大的改变。

不是让我写代码更快。

而是让我可以用非常低的成本，把一个想法快速变成一个可以运行、可以操作、可以测试的东西。

然后再通过真实使用，让这个想法继续成长。

---

最后

所以现在再让我解释 Vibe Coding，我不会简单地说：

「就是让 AI 帮你写代码。」

因为 AI 真正改变的，不是打字速度，而是推翻重来的成本。

不好用，就改。

设计不合理，就调整。

方向错了，就重新来。

我最近攒的那个工作台，本质上也是这个过程的产物。

它不是一份写完了才动手的设计文档，而是一路用、一路改出来的东西。

先让想法跑起来，再让它变得越来越好。

这就是我现在的 Vibe Coding。

---

相关阅读

• Cordis 插件化 Agent 运行时：用 DI 容器把 LLM 后端、工具、审批流全部变成配置 — resolve-studio 工作台背后的架构：一切皆插件、一切可变点推到配置层。
• AutoGen PSE 架构解析：用 Planner/Specialist/Evaluator 模式构建可靠的多智能体协作系统 — PSE 三角色闭环的完整实现：职责分离、最小权限、step_buffer 防 Token 爆炸。