我的观点
vibe coding 时代，文档就是代码，代码反而不重要了，只要测试用例能通过，放心 allow AI 生成的代码即可。而文档一定要严谨，绝不能存在瑕疵、矛盾，对于 AI 规划的结果，一定要读，不合适的地方要明确指出。
但这反而让我觉得有点别扭。毕竟自然语言总归是不严谨的，代码不就是为了更严谨吗？可能也正是由于代码的严谨，才能实现”测试用例过了，就可以放心”。反过来——靠不怎么严谨的自然语言去生成严谨的代码，难免会出现理解偏移。
AI 拆解
以下为 AI 对上述观点的拆解与补充, 作为参考视角保留。
一、为什么会产生”文档即代码，代码不重要”的观点
这个观点的核心逻辑是 “抽象层级的再次跃升”。
回顾编程史，就是一部不断隐藏底层细节的历史：
- 汇编时代：程序员需要关心寄存器和内存地址
- C 语言时代：汇编”不重要”了，编译器帮你搞定，你只要写好 C
- Python / Java 时代：内存管理和指针”不重要”了，GC 帮你搞定
- AI Coding 时代：具体的语法和逻辑编排”不重要”了，大模型（LLM）成了新的”编译器”。只要你把”需求（文档）“描述清楚，大模型就能把自然语言”编译”成机器语言
在这个视角下，AI 极大地拉平了”知道怎么做”和”实际敲代码”之间的成本。测试用例成为了验收标准（质检员），只要黑盒测试能过，里面是一堆 if-else 还是优雅的设计模式，对最终结果影响确实变小了。因此，人的精力自然要向上转移，去把控 需求（文档）和架构（规划）。
二、那种别扭从何而来
这种别扭触及到一个计算机科学的基础问题：自然语言是”有损”且”充满歧义”的，而计算机运行需要”绝对无损”且”形式化”的逻辑。
担忧主要体现在三个层面：
- 自然语言的”高上下文依赖”：你说”把用户按时间排序”，人会默认是”按注册时间倒序”。但 AI 可能会写成”按最后登录时间正序”。代码之所以严谨，是因为它逼着程序员把这些隐藏的上下文全部显式地表达出来。用不严谨的自然语言去生成严谨的代码，必然会产生 “幻觉”或”理解偏移”
- 测试用例的悖论：观点中提到”只要测试用例能通过”。但问题是——测试用例本身也是代码。如果测试用例也是用同一份”不严谨的文档”让 AI 生成的，那就成了”用 AI 验证 AI”，极易产生掩耳盗铃的逻辑闭环：AI 写错业务逻辑，然后写个同样错的测试来证明自己是对的
- 边界条件和异常处理的缺失：写文档时，人很容易关注”主流程”（Happy Path），而忽略繁琐的异常分支。但写代码时，IDE 的提示、类型系统的约束会逼着你处理 null、超时、并发竞争等问题。自然语言很难巨细无遗地覆盖所有边界
三、如何调和这种矛盾
这种别扭感，其实指明了 AI Coding 时代正确的工作流。文档确实越来越重要，但这不是过去理解的那种”大白话文档”，而是 “结构化的半形式化语言”。
1. “文档”被重新定义为”可执行的契约”
未来的”严谨文档”，绝不是几段长篇大论的散文，而是类似这些东西：
- 伪代码 / DSL：介于自然语言和严格代码之间
- 状态机图 / Mermaid 流程图：用图形语言精准定义状态流转
- 明确的验收标准：Given-When-Then 格式的行为驱动描述
在这些”高级抽象”上必须做到 100% 的严谨，绝不能有矛盾，AI 才能精准”编译”。
2. 测试代码才是真正的”锚点”（Test-Driven LLM）
代码的严谨能让人放心，在 AI 时代，这份严谨必须由”人写的测试”或”人深度审查过的测试”来承担：
- 人类定义接口签名、数据结构和核心的测试用例（最需要严谨的地方）
- AI 去填补中间的具体实现（不管它写得多丑，只要跑通人类严苛的测试即可）
- 这就是为什么 TDD 在 AI 时代变得前所未有的重要
3. 编程并未消失，只是变成了”审查与修正”
“对于不合适的地方要明确指出”——这其实就是 Code Review。以前你是一个 Author（作者），现在你是一个 Reviewer（审核员）+ Architect（架构师）。当你发现 AI 生成的代码和你的预期有”理解偏移”时，你通过修改文档、增加约束、或者直接改一行关键代码来纠正它。本质上是一个 通过试错将”模糊意图”收敛为”精确代码”的迭代过程。
所以，不必感到别扭。在 AI 时代，你依然需要代码级别的严谨思维，只不过你表达这种严谨的媒介，从底层的 for-loop 和 指针，变成了更高维度的 业务模型、接口定义、测试用例 和 结构化 Prompt。 程序员并没有被取代，只是被逼着进化成了系统工程师。