对于 Vibe Coding 的一点思考

AI 编程越来越普及之后，一个很自然的问题开始浮现：

当我们用 AI 写代码时，到底是在“描述需求”，还是在“传递等量的信息”？

更具体一点说：

如果我要做的是一个复杂项目，我是否必须给出非常细致的需求描述，甚至把实现步骤、异常分支、边界条件都写清楚？

如果 prompt 已经细到这种程度，那么它和写代码相比，到底还省不省脑力？

甚至在某些情况下，直接写代码会不会比写 prompt 更快？

这个问题不能简单回答成“AI 能提高效率”或者“prompt 越详细越好”。

从信息论和算法复杂度的角度看，Vibe Coding 的主线可以概括为：

Vibe Coding 的本质，是用 prompt、上下文和反馈，不断降低模型生成代码时的条件熵；
当条件熵足够低时，模型可以利用自身压缩过的程序知识展开大量低熵代码；
但业务规则、历史兼容和工程判断中的高熵部分，仍然需要人提供信息。

而真正值得讨论的是：哪些不确定性可以交给模型消化，哪些不确定性仍然必须由人来消除。

一、一个直觉误区：把 prompt 当成代码的完整规格

在讨论 AI 编程时，一个常见的隐含假设是：

只要 prompt 足够完整，AI 就能生成正确代码。

这个说法看起来没问题，但它很容易滑向另一个误区：

把 prompt 当成代码的完整信息来源，或者把 prompt 当成必须一次性写清楚的完整规格。

一旦这样理解，复杂项目里的 AI 编程就会变得很尴尬。

因为 prompt 会被迫承担多重角色：它既要表达业务目标，又要描述实现细节，还要排除所有错误理解。

这时，prompt 就不再只是人和模型之间的协作接口，而会逐渐变成一份不可执行的详细设计。

问题不在于 prompt 该不该详细，而在于我们不应该把 prompt 理解成代码的唯一信息来源。

在 AI 编程里，真正参与生成的输入并不只有 prompt。至少还包括：

  • 模型参数中压缩过的大量代码模式和工程经验
  • 当前项目的上下文，例如已有代码、接口、日志、测试和文档
  • 用户通过 prompt 提供的目标、约束和差异信息
  • 生成过程中的采样、反馈和多轮修正

所以，把 AI 生成代码理解成：

Code = Prompt

是不准确的。

更接近真实情况的表达是：

Generated Code = f(Model, Context, Prompt, Feedback)

也就是说，prompt 并不是代码的全部来源。它更像是在调用一个已经包含大量程序知识的系统，并对这个系统施加约束。

二、模型不是空白系统

Vibe Coding 和传统从零写代码最大的区别在于：

AI 模型本身已经“预加载”了大量信息。

现代大模型在训练中已经学习了大量常见模式，例如：

  • Spring、React、Vue、Django 等框架结构
  • MVC、DDD、分层架构、前后端分离等工程模式
  • CRUD、分页、鉴权、表单校验、异常处理等常见代码模板
  • 日志、事务、单元测试、接口设计等工程经验

因此，当你输入一句：

给这个后台系统补一个用户导入功能，支持 Excel 上传、参数校验和失败明细返回。

模型并不是从零开始发明“什么是 Controller”“什么是 Service”“Excel 如何解析”“失败明细如何组织”。

这些低熵、模式化、可推导的部分，很多已经存在于模型的先验知识和项目上下文中。

你真正提供的是：

在这个巨大程序空间中的方向、约束和差异。

这也是为什么一句看似很短的 prompt，有时可以生成大量代码。

三、香农信息熵（Shannon Entropy）视角：prompt 是在降低不确定性

如果引入香农信息熵（Shannon Entropy），这件事会更清楚。

香农熵衡量的是一个随机变量的不确定性。对于 AI 编程来说，我们可以把“模型可能生成的代码”看成一个巨大的候选空间。

在没有明确任务约束时，模型面对的是一个高熵的候选代码分布：

$$H(Code)$$

也就是说，可能生成的代码太多了：

  • 可能是 Java，也可能是 Python
  • 可能是 Spring Boot，也可能是 NestJS
  • 可能使用 MySQL，也可能使用 PostgreSQL
  • 可能做成单体，也可能拆成微服务
  • 可能使用 JWT，也可能使用 Session

当我们给出 prompt 后，生成空间被条件化：

$$H(Code \mid Model, Prompt)$$

如果再加入当前项目的代码、接口定义、数据库结构、错误日志、测试用例和开发规范，不确定性会进一步下降：

$$H(Code \mid Model, Prompt, Context)$$

如果再经过运行、测试、报错和人工修正，反馈也会成为新的条件，让后续生成继续收敛：

$$H(Code \mid Model, Prompt, Context, Feedback)$$

所以，prompt 的核心价值不是逐字包含目标代码，而是降低模型生成代码时的不确定性。

可以粗略理解成：

H(Code)
> H(Code | 使用 Spring Boot)
> H(Code | Spring Boot + MySQL + JWT)
> H(Code | Spring Boot + MySQL + JWT + 当前项目结构)
> H(Code | Spring Boot + MySQL + JWT + 当前项目结构 + 具体业务规则)

这个视角能解释一个很常见的现象：

粗略 prompt 可以生成代码，但生成结果容易发散。

因为粗略 prompt 只降低了一部分熵。模型仍然面对大量可能实现，所以它只能根据概率去猜。

如果我们继续补充业务规则、接口契约、异常分支和验收标准，本质上就是在继续降低条件熵。

但关键问题也在这里：

降低不确定性本身是有成本的。

复杂项目中，开发者真正消耗脑力的地方，往往不是敲代码，而是消除不确定性。

四、复杂项目里，prompt 为什么会变长？

在简单任务里，prompt 可以很短。

比如：

写一个登录页面，包含用户名、密码、记住我和提交按钮。

这类需求的业务不确定性很低。页面结构、交互模式、错误提示、按钮状态，大部分都可以由模型根据常见模式补全。

但复杂项目不是这样。

复杂项目中的真正难点通常是：

  • 字段到底代表什么业务含义
  • 哪些旧逻辑不能破坏
  • 哪些数据状态是历史包袱
  • 失败时应该回滚、跳过、重试，还是进入人工处理
  • 某个空值是非法、默认值，还是兼容旧版本
  • 接口返回字段是否已经被其他前端页面依赖
  • 这个功能应该同步执行，还是异步入队

这些信息不是通用代码模式。它们来自具体业务、历史系统和工程判断。

模型无法凭空知道这些东西。

所以复杂项目里的 prompt 变长，并不是因为 AI 编程失效了，而是因为任务本身的条件熵太高。

如果这些约束不写清楚，AI 就只能猜。

而一旦让 AI 猜，复杂项目里最容易出现的问题不是代码写不出来，而是代码“看起来能跑，但语义不对”。

五、当 prompt 细到像代码时，还省力吗？

这就回到了最开始的问题。

如果为了让 AI 正确实现一个功能，我们必须写出非常细的 prompt：

遍历 Excel 的每一行。
从第二行开始读取。
手机号为空时跳过并记录 warning。
手机号格式错误时记录失败明细。
如果手机号已存在，则更新姓名和部门。
如果用户状态是 DISABLED，则不允许覆盖。
如果部门不存在，则自动创建部门。
如果失败数量超过 20%，整批回滚。
如果超过 1000 行，则改成异步任务。

这时 prompt 已经不再是一个简单需求，而接近详细设计，甚至接近伪代码。

那么它和直接写代码相比，还剩多少优势？

答案是：要分情况。

如果 prompt 只是描述业务规则、边界条件和验收标准，那么它仍然有价值。因为 AI 可以继续承担大量低熵工作：

  • 生成 Controller、Service、DTO、Mapper
  • 补参数校验
  • 写异常处理
  • 整理失败明细结构
  • 生成单元测试
  • 按项目风格补日志和事务

开发者节省的是编码成本、样板组织成本和重复劳动。

但如果 prompt 进一步细化到逐行描述控制流、变量命名和每个 if 分支，它就开始退化成一种弱类型、不可执行、不可验证的伪代码。

这时直接写代码可能更快。

因为代码拥有 prompt 没有的东西：

  • 类型系统
  • IDE 补全
  • 编译器检查
  • 静态分析
  • 单元测试
  • 可运行反馈

所以，Vibe Coding 的收益并不来自“无论多复杂，都可以用一句话完成”。

它真正的收益来自：

人在高抽象层级描述目标和约束，AI 补全低抽象层级的结构和实现。

一旦人被迫在自然语言里精确描述所有低层实现细节，收益就会明显下降。

六、柯尔莫哥洛夫复杂度（Kolmogorov Complexity）视角：真正的信息在哪里？

香农信息熵（Shannon Entropy）解释的是：在生成之前，模型面对多少不确定性。

柯尔莫哥洛夫复杂度（Kolmogorov Complexity）解释的是：对于一个已经确定的对象，生成它所需的最短描述可以有多短。

柯尔莫哥洛夫复杂度通常可以理解为：

生成某个对象的最短程序长度。

记作：

$$K(x) = \text{生成 x 的最短程序长度}$$

对于一段代码来说，如果脱离模型和上下文，直接描述它可能很复杂：

$$K(Code)$$

但在 AI 编程中，我们不是在空白系统里描述代码。我们有模型，有当前项目，有框架，有已有文件，有错误日志，有测试反馈，还有开发者通过 prompt 提供的剩余差异信息。

所以更准确的表达是：

$$K(Code \mid Model, Context, Prompt) \ll K(Code)$$

也就是说：

在已有模型知识、项目上下文和 prompt 约束的条件下，生成代码所需的额外描述长度，远小于代码本身的完整描述长度。

这就是为什么 AI 可以用较短 prompt 生成较长代码。

这里的 prompt 可以理解为开发者提供的剩余描述：那些不能从模型和上下文中自动推出的业务差异、边界条件和验收标准。

但这里有一个边界：

只有那些能被模型和上下文推导出来的部分，才会被压缩。

业务特异性越强，历史包袱越多，规则越反直觉，需要人补充的信息就越多。

换句话说：

AI 可以压缩通用程序结构，但不能自动压缩它不知道的业务事实。

七、Vibe Coding 的本质：在程序空间中导航

从这个角度看，Vibe Coding 并不是“用自然语言替代代码”这么简单。

它更像是：

在一个巨大的程序空间中，通过自然语言、上下文和反馈进行导航。

prompt 的作用不是从零描述整个系统，而是不断给模型增加约束：

  • 选择技术栈
  • 限定架构风格
  • 指定业务规则
  • 排除错误方案
  • 贴合现有代码
  • 定义验收标准

模型的作用也不是凭空创造信息，而是在已有的程序知识分布中，寻找满足这些约束的实现。

因此，Vibe Coding 的效率取决于一个关键比例：

一个任务里，有多少复杂度是可压缩的模式化复杂度，又有多少复杂度是不可跳过的业务不确定性。

如果一个任务的大部分复杂度来自样板代码、框架结构和常见模式，AI 的收益会非常高。

如果一个任务的大部分复杂度来自业务规则、历史兼容、异常语义和工程取舍，AI 仍然有用，但它不能替代人的判断。

八、长输出不等于高信息量

这也解释了另一个常见误解：

AI 输出很长，所以它一定创造了很多信息。

其实不一定。

一个很长的系统，可能包含大量低信息密度内容：

  • 重复的 CRUD 结构
  • 固定的分层模板
  • 相似的 DTO 转换
  • 统一的接口包装
  • 机械的测试样例

这些代码行数很多，但模式很强。

从压缩角度看，它们可能由很短的规则展开。

所以，长输出不等于高信息量。

这种差异在数学发现这类更高抽象层级的问题中，会表现得更明显。

OpenAI 在 2026 年 5 月发布了一项研究进展：其内部模型推翻了离散几何中关于平面单位距离问题的一个长期猜想，并给出了一系列新的构造。这个问题可以追溯到 Erdős 在 1946 年提出的单位距离问题。OpenAI 官方文章称，该证明已经过外部数学家团队审阅，并附有配套评述。

这个例子很容易让人产生一种直觉：AI 是不是凭空创造了新的数学信息？

但从本文的视角看，更稳妥的理解是：模型在巨大的数学搜索空间中，找到了一条人类此前没有充分注意到的结构路径。真正重要的不是证明文本有多长，而是其中那个能够显著排除错误方向、连接不同数学结构的关键构造。

这和代码生成其实有相似之处。长篇输出本身并不等于高信息量；真正有价值的是那些能改变搜索空间、降低不确定性、排除大量错误方案的结构性信息。

真正高信息量的部分，往往不是那几百行样板代码，而是某个不起眼的业务规则：

当用户处于 DISABLED 状态时，导入流程不得覆盖其部门和角色，但需要记录一条失败明细。

这一句话可能比几十行模板代码更重要。

因为它排除了大量错误实现，显著降低了生成空间的不确定性。

九、AI 编程改变的是表达成本，不是工程判断

所以，回到最初的问题：

如果复杂项目里必须写非常细的 prompt，那 AI 编程还省力吗？

我的理解是：

AI 编程省掉的不是全部思考成本。

它主要省掉的是：

  • 低熵代码的书写成本
  • 常见模式的组织成本
  • 重复结构的展开成本
  • 样板测试和胶水代码的生成成本

但它省不掉：

  • 业务规则的判断
  • 需求边界的澄清
  • 历史兼容的取舍
  • 数据语义的确认
  • 质量标准的验收

这些东西本来就不是“敲代码”的问题，而是“降低不确定性”的问题。

无论你写代码、写设计文档，还是写 prompt，只要任务本身的不确定性很高，这部分脑力成本都绕不过去。

因此，好的 Vibe Coding 不是把所有细节都塞进 prompt。

更合理的方式是：

让 prompt 描述高价值约束，让上下文提供已有事实，让测试和反馈不断收窄生成空间。

也就是说，人不应该把自己变成“自然语言编译器”，逐行指挥 AI 写代码。

人更应该做的是：

  • 给出目标
  • 补充关键业务事实
  • 明确不能破坏的边界
  • 提供可验证的验收条件
  • 通过运行结果继续修正方向

结语

回到最开始的问题：

如果复杂项目里必须写很细的 prompt，那 AI 编程到底还省不省力？

我的理解是，Vibe Coding 并不是让复杂性消失，而是改变了复杂性的分布方式。

从香农信息熵（Shannon Entropy）的角度看，prompt、上下文和反馈是在不断降低模型生成代码时的不确定性：

$$H(Code \mid Model, Context, Prompt, Feedback) \ll H(Code)$$

从柯尔莫哥洛夫复杂度（Kolmogorov Complexity）的角度看，在模型、上下文和 prompt 约束存在的条件下，代码的最短描述长度可以远小于代码本身：

$$K(Code \mid Model, Context, Prompt) \ll K(Code)$$

所以，AI 可以帮助我们展开大量低熵的、模式化的、可推导的代码。

Vibe Coding 的真正价值，不在于让人完全不用描述复杂性，而在于：

把可压缩的复杂性交给模型，把不可压缩的不确定性交还给人。

也就是把开发者从低熵的代码书写中释放出来，把注意力集中到高熵的业务约束和工程判断上。

参考资料