Vibe编程的定义

首先，我们先定义一下vibe编程。我这里的定义是这样的：

不对具体的代码进行编辑。

但我仍然需要进行的操作有：

  1. 构造项目的目录结构
  2. 人工编写、审核设计文档
  3. 用conda / pip建立项目所需要的运行环境，安装各种必要的库
  4. 运行pytest
  5. 复制粘贴代码到指定的文件
  6. 使用git提交代码，必要时进行撤销操作
  7. 人工审核code review意见

对于操作3-7，完全没有编程经验的人可能不知道应该如何做，因此并不是“零基础无经验”可以完成的。但3-6的操作只需要短时间的学习即可，人工审核的部分更多要求的是阅读理解的能力。
另外，由于要撰写复杂的设计文档，也不是充斥各种视频、文章的一句话编程。

这是一个非常严肃认真的vibe编程实践。

AI工具选择

推荐：

  • 同时使用两种不同来源的AI，比如ChatGPT o3和Gemini 2.5 Pro，均应当使用最新最强版本。
  • 需要长上下文支持，越长越好。

如果没有ChatGPT的付费账户，仅仅使用Google AI studio上的gemini 2.5 pro也是非常好的。但交叉使用不同来源的AI，特别是做检查的操作，会让人更放心。
个人不喜欢Claude，它的上下文太短，代码补全或者写一两个短函数可以，但我们接下来的操作粒度是基于模块或者文件的，gemini非常合适。

至于其他：

  • 是否需要继承AI的编辑器或者插件，例如cursor：不需要。
  • 是否需要本地运行的AI：不需要。

方法论模型

因为AI是根据人类的行为训练出来的，所以在现阶段，能够提升人类能力的方法，很可能也可以提高AI的能力。管理学中的方法，不妨可以分成两类，一类是对事不对人，一类是对人不对事。前者抹杀人的主观能动性、消解人性、异化人性……比如流水线；后者则是提供各种情感支持、利益分配、责权分配等。

我们需要的是前者。

我们主要使用两个方法论模型，一个是公理设计，一个是测试驱动开发（TDD)。特别是面对中等规模以上的问题，公理设计和测试驱动开发是两个很好的模型，可以一步一个脚印踩实，又不至于反复返工。这两个模型非常简单：

  • 公理设计
    • 独立性公理：各个模块之间要解耦合，不能纠缠在一起
    • 信息量公理：不能假定用户/输入一定遵守规则
  • TDD
    • 程序要测试，只有测试通过了才是好程序。

更详细的内容，不妨请教AI。

主操作流程

  • 和AI们聊需求，可以用语音聊天，完成后出需求报告，然后人工修订。
    • 此时如果有多个AI讨论会更有效
    • 有些程序是需要满足特定的文档格式要求的，比如要输出特定格式的二进制文件或者json/ yaml等，一定要反复核对，此时可以交给多个不同来源的AI进行交叉核对。
    • AI的理解常有偏差，需要逐条批准或者修订。
  • 令AI根据需求报告，撰写公理设计文档。
    • 如果FR-DP矩阵没有呈现出下三角矩阵（具体啥意思您可以问AI），则表明不能充分解耦合，需要重新设计。必要时要人工干预。
    • 这个文档是最重要的，推荐使用ChatGPT o3 deep research来撰写。
    • 交给多个AI交叉讨论可以进一步提高效果。
    • 可以令AI估计各个模块的复杂度或者完成难度，对于太困难的，应当进一步拆分。7-10个可能还是不错的。
  • 将定稿的公理设计文档交给AI，撰写函数架构文档。这一步基本不需要人工审核，但交给AI交叉讨论效果更佳。
  • 将定稿的函数架构文档交给AI，撰写测试需求文档。这一步基本不需要人工审核，但交给AI交叉讨论效果更佳。
  • 根据公理设计文档，函数架构文档，测试需求文档，一对一对写模块和对应测试。反复进行直到测试完全通过，再写下一对。
    • 此处稍后展开讨论

整个操作中，最主要的部分是在设计架构。抽象层级从编写代码提高到了对整体流程的分解。更像是一个产品经理，而不是一个程序员。同时，由于从具体的代码编写中脱离，也就是意味着可以使用自己不熟悉的语言，或者不熟悉的架构。比如我一直非常反感写GUI界面，我个人难以理解各种“callback”，我也一直没学会如何写javascript以及各种衍生出的各种js。但在这个流程下，用python还是js来编写代码并不重要。甚至可以先写python，再转换成同目的的js，只要有对应的库即可。

同时，你也可以理解为什么有很多视频、公众号文章里渲染的“一句话编程”为什么是可行的，因为这些程序往往是写个俄罗斯方块，或者是小球弹跳的动画，最复杂也就是编写个笔记软件之类。这些程序的模块已经被分析过多次，拆分好了，甚至有很多开源的样例。但如果你要写的是一个光学模拟→镜片设计或者镜片设计→车床加工结合之类的东西，就无法使用一句话让AI来写程序了。

代码撰写部分

以下用Google AIStudio为例说明。以python为例，这里需要用的是pytest。假定你配置好了本地的运行环境之类，并且已经编写好了pytest.ini，将结果导出至一个xml文件，比如放在src\tests\unit_test_result.xml。（具体怎么写问gemini）

准备工作

  1. 系统prompt：

你精通公理设计思想和函数式编程。
你用中文回答问题
你总是给出完整优雅的解决。
当前项目的目录结构：
project_root
├───docs
└───src
├───package_name
├───tests
...

这个目录结构可以问问AI，它会给出一个不错的建议。要生成这样的字符目录树，在powershell命令行里可以用tree命令来产生。

  1. 上传各种文档

将刚才撰写的公理设计文档，函数架构文档，测试需求文档，均上传至AI studio，用alt+enter可以达成只上传，不执行的作用。

如果你已经写好了多个模块，新写好的模块需要用到之前的内容，那么将已经写好的模块程序也上传给gemini。但总的token使用量最好不要超过80k。（这里有个技巧，稍后讲解）

编写模块/测试对

prompt:

根据上述文档，撰写DP1模块的程序和对应的pytest测试。

就这样简单说就行了。然后等着gemini写出完整的代码。到你的编辑器中指定的位置，各自新建好文件例如src\package_name\DP1.py和src\tests\test_DP1.py，贴进去。提交git。

测试/debug

这里才是重头戏。如果你只要求程序能运行，那么很可能上面写的模块代码就够用了。但如果有很多模块，需要每个模块都能运行，最后组合在一起的大程序也可以良好运行，甚至未来扩展功能的时候还能正确运行。这个概率是极低的。所以要每写一个模块就要同步进行测试，保证每个模块都通过了测试。

在python，测试的操作只需要运行pytest，如果你之前已经设定好了pytest.ini的配置文件，那么pytest会把测试的结果保存在指定的xml文件之中。如果所有测试都pass，那么就进行下一个模块好了。

如果测试没通过。进行如下步骤：

  • 新开一个AI studio页面复制上面的system prompt和参考文档们（公理设计文档，函数架构文档，测试需求文档）
  • 写prompt：“根据上述文档，分析pytest结果，对以下程序进行修改，输出完整的程序代码”。
    • 进阶prompt：根据上述文档，先对以下程序进行code review，然后分析pytest结果，对程序进行修改，输出完整的程序代码。
  • 写完Prompt以后用alt+enter。
  • 用资源管理器拖动刚才的模块程序文件、对应的测试程序文件和单元测试结果文件（src\package_name\DP1.py，src\tests\test_DP1.py，src\tests\unit_test_result.xml）投放到AI studio对话框中。
  • 然后在ctrl+enter运行

得到结果后，继续复制粘贴到对应文件，再次进行pytest测试，如果又出错。

方案A:

  • 将新的单元测试结果文件拖入对话框中，ctrl+enter。

方案B:

  • 在刚才写好prompt的位置，点文本框右上的三个点...，然后选择Branch from here，你将得到一个保留了参考文件、prompt，但清除了其余文件和输出的状态。
  • 用资源管理器拖动新更改的模块程序文件、对应的测试程序文件和单元测试结果文件（src\package_name\DP1.py，src\tests\test_DP1.py，src\tests\unit_test_result.xml）投放到AI studio对话框中。
  • 然后在ctrl+enter运行

何时使用方案A/ 方案B：

  • 如果出错的问题很少，比如1-2个，或者这是首轮进行的debug。那么使用方案A。
  • 如果gemini已经力不从心开始智力下降，那么使用方案B，以下是gemini智力下降的指标：
    • 观察侧面边栏的token使用量，如果已经超过100k，
    • 或者，pytest出错只有1个，但表述为import错误或者一些简单的类型错误（是的，你还是得会编程才能看得懂），
    • 或者，你要求了中文输出，但结果中不但有大量英文，还出现了其他语言，比如德语、印地语、俄语、韩语，
    • 这些都说明gemini干不动了。需要清理上下文。大致上20k上下文相当于人类开会1小时，到100k的时候已经开了5小时会了，正常人类都脑子不清楚了。

如果你反复N次都不能通过测试（比如，N=5或7）。那么说明这个模块太大了，请回到公理设计的阶段，跟AI说，这个模块太大了，请帮忙拆分，然后更新公理设计文档，函数架构文档，测试需求文档。

已写程序的压缩摘要

很多AI会将上下文长度作为宣传点。但是上下文长度其实是不同的。我认为上下文长度有几种：

  • 输入不报错的长度，或者不截断的长度。以Gemini 2.5 pro为例，可以到1M。
  • 能够大海捞针的长度。你在长文本里埋入一句话，让AI找出来。这个大概是最大长度的60%~80%。
  • 能够正常思维正常推理的长度。2025Q2，Gemini 2.5 pro，大约是100k~300k，从100k开始就会出现能力下降，到300k就已经脑子里一团浆糊了。

前面说过，以目前gemini的水平。20k token相当于人类开会1小时。上下文长度在20-60k的效果最佳，此时所有需要的背景资料交代得清清楚楚，AI动力十足，处于智力的最佳状态。但随着项目的进展，越来越多的模块写好，需要AI提前掌握的信息越来越多，很可能这些资料就累计了有一两百k，AI把前因后果弄明白就已经头晕脑胀，很难再写出好代码了。

这时候需要对已经写好的程序进行压缩摘要。

新开一个AI studio页面，把已经写好的程序依次上传，到大约80k停止，然后要求AI对上述程序进行摘要，什么方案你可以和AI探讨。我一般会要求要输出所有的常量，所有的函数签名（输入参数和输出参数的名称与类型），并且对每个函数进行一句话摘要，复杂的函数应当用伪代码进行描述，结果输出成一个文档。

然后把这个摘要文档也保存到docs里，每次写新模块的时候，也需要将此摘要文档提交给AI。这样大概能把你的程序压缩到原来的1/8左右。

以上就是一个“严肃氛围编程”的过程。在写好各种文档后，很多是重复无脑的操作，不用深入到代码中进行编辑。虽然正经程序员们会觉得这种重复手工操作一定要写代码自动化才行，但野生程序员此刻可能在玩游戏刷剧切菜做饭打扫屋子，所以并未处于心流状态，也觉得无所谓。

你也可以不使用AI studio的网页版本，而是自行用cursor、trae或者cline插件调用API来完成。操作上更简单一些，特别是在debug的时候，用上下键可以提取出之前的prompt，让AI反复修改即可。但我个人实测trae，成功率更低。我不确定trae是否做了什么劣化的操作，比如限制长度或者内置了太长的系统prompt之类。或者是由于没有新开对话，导致实际的上下文长度过长，进入了降智区间。

个人推荐在debug的时候，要对代码进行code review。个人感觉代码成功率有了很大的提升。带上公理设计文稿的上下文之后，code review时具有一定的全局观念，如果你用的库比较生僻又复杂（比如函数调用必出错的pythonocc），还应该打开搜索，强制要求AI对每个函数的正确写法进行检索。