用上下文工程把AI编程从随机生成变为可控交付

引言：Vibe Coding 的真实面貌

“Vibe Coding” 这个词最近在开发者社区里被反复提起。有人将其描述为一种“跟着感觉走”的编程方式——把想法丢给智能编程工具，然后坐等成品；也有人对此嗤之以鼻，认为让 AI 写代码无异于埋雷，最终还要自己返工。

两种观点我都经历过。早期我属于前者，试图用一句“帮我写一个带用户管理的后台系统”来完成工作，结果得到的代码架构混乱、逻辑残缺，连最基本的异常处理都漏洞百出。随后我转向另一个极端，全面否定 AI 在开发中的价值，觉得所有代码还是自己亲手写才放心。

但经过一段时间的实践，我逐渐意识到：这两种理解都错失了一个关键点。真正有价值的“Vibe Coding”并非“靠氛围写代码”，而是一套严谨的协作流程——人负责定义目标、划定边界、给出约束、设定验收标准；AI 负责在约束范围内完成调研、设计、编码与验证。

换句话说，Vibe Coding 的本质不是“让 AI 自由发挥”，而是通过构建高质量的上下文，让 AI 的输出从“随机生成”变成“可控交付”。这其中的核心能力，不叫 Prompt Engineering（提示词工程），而叫 Context Engineering（上下文工程）。

一、为什么“上下文工程”是 Vibe Coding 的真正核心

1.1 AI 缺少的不是能力，而是背景信息

智能编程工具本身没有“常识”。它不知道你的业务目标是什么，不知道目标用户是谁，不知道“第一版能用”在你心里意味着什么。当你不提供这些信息时，它只能依据训练数据中统计学上的“最大概率”来猜测。

这种猜测带来的后果是：

• 需求漂移：AI 每生成一段代码，都会基于自己“臆想”的需求做设计决策，导致不同模块的功能假设不一致；
• 文件结构失控：AI 倾向于不断创建新文件来避免修改已有代码，最终项目目录膨胀、依赖关系混乱；
• Bug 修复越修越深：AI 在修复一个问题时，往往只做局部修补，不检查对全局的影响，导致修复一个Bug引发两个新Bug；
• 代码风格无序：不同模块的命名风格、函数粒度、错误处理方式不一，维护成本急剧上升。

1.2 上下文工程：把隐性知识显性化

上下文工程，指的是系统性地构建、组织和持续更新那些 AI 完成编程任务所需的一切背景信息。它包含以下几个层次：

上下文层级	包含内容	作用
目标层	项目要解决的问题、目标用户画像、核心价值主张	让 AI 理解“为什么做”
约束层	技术栈选型、架构风格、性能指标、安全要求	让 AI 知道“不能怎么做”
规范层	代码风格、命名规则、目录结构、设计模式	让 AI 确保“代码长什么样”
契约层	接口定义、数据结构、Error 处理方式	让 AI 保证“模块之间怎么协作”
验收层	测试用例、评审清单、功能标准	让 AI 判断“做到什么程度才算完”

当一个项目的上下文工程做得足够好，AI 的行为就会从“失控的生成器”变为“可控的执行者”。

二、Vibe Coding 的第一步：需求定义是地基，不是点缀

2.1 任何代码生成都始于需求澄清

与其说 Vibe Coding 是“写代码”，不如说它是“写需求 + 写约束 + 写测试”的过程。实践中我总结出一个稳定的工作流：

第一步：用自然语言写出完整的业务需求文档

这份文档不需要 50 页，但必须包含以下核心信息：

• 背景：这个项目产生的根源是什么？解决什么问题？
• 目标用户：谁会使用这个系统？他们的技术素养和核心诉求是什么？
• 功能范围：明确哪些功能是第一版必须的（MVP），哪些是后续迭代的。
• 非功能需求：性能预期（如响应时间）、并发量估算、数据安全性要求。
• 明确不做的事情：即边界条件，告诉 AI “这些是当前阶段不应该考虑的”，防止它自作主张。

2.2 技术选型：提前定义标准答案

AI 在执行技术选型时有一个特点：它倾向于选择“最常见的技术组合”，而不是“最适合当前场景的技术组合”。因此，这一决策必须由人来定。

例如，你需要明确以下建议：

• 语言与框架：选定主要开发语言，以及对应的 Web 框架、ORM 库、前端技术栈；
• 数据库：选择关系型/非关系型，选型原因（如事务一致性要求、数据量预估）；
• 部署方式：容器化、Serverless、传统虚拟机——决定后续架构设计；
• 第三方服务：对象存储、消息队列、日志系统等通用云服务能力的接入方案。

把这些提前写清楚，AI 就不会在面对多种可能性时随机选择一个。

2.3 上下文喂食：让 AI 在正确信息中工作

在开始编码之前，你需要把以上信息结构化地传给 AI。实践中，我通常会创建一个专门存放项目上下文的目录，包括以下文件：

project/
├── docs/
│   ├── requirements.md      # 业务需求文档
│   ├── tech-stack.md        # 技术选型与理由
│   ├── architecture.md      # 系统架构描述与图表
│   ├── api-contract.md      # 接口契约示例
│   └── acceptance-criteria.md # 验收标准清单
├── rules.md                 # AI 编码必读：代码风格、命名约定、文件组织逻辑
└── plan.md                  # 具体的任务拆解与实施步骤

在后续与 AI 的每次交互中，我都会要求它“先读取这些文档，再回答问题”。这确保了它在任何代码操作之前，就已掌握了完整的项目背景。

三、核心方法论：从“一句话生成”到“分步引导”

3.1 把大任务拆解为可验证的小步骤

有一个常见误区是：把一个大需求整体丢给 AI，让它一口气完成。即使上下文文档再完善，AI 也无法在一个响应里完成对分层架构、业务逻辑、数据持久化和前端交互的全量设计。

正确做法是分步引导：

1. 架构设计阶段：先让 AI 基于需求文档和技术选型，输出系统架构图（用文字描述）、模块划分、数据模型设计。人类在此阶段进行审查和修正；
2. 核心模块开发阶段：从依赖最少的模块开始（如数据模型、工具函数），要求 AI 编写代码，并附带单元测试；
3. 接口整合阶段：定义好 API 契约后，让 AI 分别实现接口提供方和消费方，再利用契约测试验证匹配性；
4. 端到端联调阶段：将基于 Mock 数据的模块切换为真实实现，通过集成测试验证整个流程。

每一步都有明确输入和输出，AI 输出后人工进行快速审查，若偏离方向及时纠正，避免问题累积到后期才被发现。

3.2 用规则文件约束 AI 的“行为习惯”

很多人在使用 AI 编程时遇到的问题是：尽管需求明确，AI 生成的代码风格依然杂乱无章。

解决方式是建立一份 rules.md 文件，并在每次交互开始时提醒 AI 严格遵守。这份文件在写作时要明确、具体、像一份风格指南：

• 命名规则：变量名使用 camelCase，常量使用 UPPER_CASE，组件名使用 PascalCase；
• 目录组织：特定类型代码（如数据访问层、业务逻辑层、API 控制器）必须存放到指定目录下；
• 错误处理：所有外部调用必须捕获异常，并为用户返回统一的错误结构；
• 注释规范：仅对业务复杂的关键逻辑添加注释，不写无关紧要的琐碎注释；
• 测试要求：新增功能必须同步提供对应单元测试，测试用例要涵盖正常流程和异常分支。

当这些硬性约束被明确告知后，AI 的输出代码质量将大幅提升，代码库整体一致性会更好。

3.3 验收测试：让 AI 自己检查自己

另一个常被忽略的关键要素是验收测试。在让 AI 开发某个功能时，首先要求它编写测试用例——基于需求文档中的功能点——而不是直接写实现代码。

测试用例写好后，再次询问并确认设计逻辑，然后开始实现代码。在这个过程中，AI 会运行测试，根据失败信息自行修复。这让开发过程从“写完代码看结果”变成“先定标准再写实现”，显著提高了交付质量。

四、风险防控：Vibe Coding 的边界与护栏

4.1 你仍然需要保留代码审查环节

即使有了完善的需求文档和规则文件，AI 依然可能犯一些“语义性错误”——它会在逻辑上使用错误的数据结构、无法正确处理极端情况。因此，每一段 AI 生成的代码在合入项目前，都必须经过人的审查。这意味着，你需要理解 AI 代码的核心逻辑，而不是“提交了事”。

4.2 监控技术债

AI 编程还有一个典型的潜在问题：它倾向于生成大量结构冗余、并不必要的抽象层。如果不加以约束，项目代码量可能膨胀到业务复杂度的数倍，形成严重的技术债务。

我通常在每完成一个阶段后，会要求 AI 输出一段“技术债务总结”，列出当前代码中可以精简的部分、重复的模块和潜在的维护风险点。这能帮助你在早期发现并处理这类问题。

4.3 持续更新上下文文档

项目是持续演进的，AI 的上下文也必须同步更新。当功能调整、接口变更或技术栈更新时，第一时间同步修改相应文档。否则，你的 AI 会基于过时信息进行后续开发，导致对项目理解的偏差。

五、Vibe Coding 的实际收益与未来展望

经过一段时间的持续实践，我将这套方法论应用于几个不同的项目场景中——从内部小工具、业务管理后台到前端原型验证。整体收益清清楚楚：

• 原型阶段效率显著提升：原来是“一个需求 + 半天到一天建模”，现在可以实现在几小时内完成可交互原型；
• 更快的反馈循环：人把精力聚焦在产品逻辑和用户体验上，AI 专注于实现细节，整体迭代速度明显加快；
• 可维护性持平甚至更优：得益于严格规则和验收测试，最终交付的代码质量不亚于人工编写，且文档结构在上下文工程中保持持续更新。

从本质上看，Vibe Coding 并没有改变软件开发的逻辑——依然是需求分析、设计、编码、测试、重构的循环。它改变的是开发者处理这些环节的方式：由“亲手写全部代码”变为“明确目标，构建上下文，审查产出”。

因此，它并不仅仅是“有 AI 辅助的编程”，而是一套全新的协作方法论。当你真正把握“上下文工程”这一核心能力，Vibe Coding 就不再是飘渺的“氛围感”，而是一条可以落地、可管理、可交付的软件开发路径。

结语：AI 不是替代你的开发能力，而是放大你的决策能力

Vibe Coding 的前提，是你本身具备对需求、架构、质量的判断力。AI 不会替代这些核心能力，却是一台高效的放大器：当你的思考足够清晰，AI 的产出就会足够精准；当你的边界足够明确，AI 的执行就会足够稳定。这项工作流的核心不在于让 AI 更“聪明”，而在于让你的意图更“清晰”。当这一切被构建好，流畅的开发体验也便自然而来。