提示词工程 -VB Coding- 标准化探索

文 | 三七 （转载请注明出处）公众号：三七-编程实战

一、三天与十天：一个项目引发的思考

故事的开始

上个月接到一个客户的 VB Coding 项目。说实话，刚开始的时候我心里是有点虚的——对客户的业务需求不了解，对他们的代码仓库更是一无所知。按照传统的开发模式，光是熟悉项目就得花个三五天。

但结果让所有人都意外：三天，我完成了客户团队预计需要十天才能搞定的需求。

客户的技术负责人看着交付的代码，脸上的表情很复杂。他沉默了一会儿，问了一个让我至今记忆深刻的问题：

"这个效率提升，有多少是因为你个人的能力，有多少是因为你的 SOP 和 AI 工具？"

这个问题，直击要害。

灵魂拷问背后的本质

换个角度想：如果这种 3 倍的效率提升完全依赖于我个人的经验、直觉和与 AI"聊天"的技巧，那对客户来说，这个能力是不可复制、不可规模化、不可持续的。他们买到的是"一次性服务"，而不是"可以规模化的能力"。

这让我想起了所有成熟商业模式的共同特征：

• 麦当劳的成功，不是因为某个大厨的手艺，而是因为标准化的操作流程

• 丰田的生产效率，不是因为工人的个人天赋，而是因为精益生产体系

从依赖个人到依赖流程和工具，这是一切可规模化商业的必经之路。

客户真正关心的问题是：

• 如果我离开了，他们的团队能否保持这种效率？

• 如果要培养 10 个、100 个开发人员，能否快速复制这种能力？

• 如果新人加入，能否快速上手，至少保证一个质量下限？

这就引出了我们今天要探讨的核心话题：如何将个人的 AI 编程能力，转化为组织的标准化能力？

二、从主观沟通到标准流程：范式的转变

Vibe Coding：氛围编程的局限

在当前的 AI 辅助编程实践中，大多数人使用的是我称之为"VB Coding"（氛围编程）的模式：

Vibe Coding 的典型特征：

• 松散的交互：没有固定流程，全靠开发者的"感觉"

• 隐性的知识：依赖个人经验，无法显性化传递

• 高度个性化：每个人的提示词风格完全不同

• 不可预测：输出质量严重依赖当时的"状态"

• 难以复制：新人看老手操作就像看魔术表演

这种模式下，AI 更像是一个"对话伙伴"，你需要：

• 有足够的技术功底来判断 AI 的输出是否正确

• 有丰富的经验来引导 AI 的思路

• 有良好的表达能力来描述你的需求

• 有足够的耐心来反复调整和优化

结果就是：会用的人效率翻倍，不会用的人浪费时间。

VB Coding：标准化编程的突破

我为 VB Coding 制定了一套 SOP 和提示词：

这套 SOP 的核心特征：

• 固化的流程：7 个标准化步骤，每步都有明确输入输出

• 显性的知识：通过提示词和模板将经验外化

• 工具化支撑：RAG（明确人需要协助 AI 组装的上下文）+ HIL（明确需要人发挥主观的场景）

• 可预测的质量：多重验证机制保证质量下限

• 可快速复制：新人按照 SOP 操作，三天上手

这不是 AI 技术的进步，这是软件工程借助 AI 的变革。

两个核心引擎

VB Coding 的标准化依赖两个核心技术引擎：

1. RAG（Retrieval-Augmented Generation）：知识库增强

传统AI对话：你 → "帮我实现用户注册功能"AI → 基于通用知识生成代码（可能与项目规范不符）
RAG增强后：你 → "帮我实现用户注册功能"    + 需求文档（业务规则）    + 项目Wiki（现有能力）    + 编码规范（技术约束）    + 设计模板（结构引导）AI → 基于项目上下文生成符合规范的代码

RAG 的作用：

• 补充隐式知识：澄清需求中的模糊概念

• 避免重复造轮子：知道项目已有哪些能力可以复用

• 确保一致性：生成的代码符合项目规范

• 降低沟通成本：不需要反复解释项目背景

2. HIL（Human-in-the-Loop）：人机协作

纯AI自动化：需求 → AI生成代码 → 直接部署（风险高）
HIL机制：需求 → AI提问澄清 → [人确认 & 调整] → 生成设计文档 → [人确认 & 调整] → 生成代码 → [人验证<借助AI验证>] → 部署

HIL 的关键节点：

• 需求拆解后：确认拆分的故事卡符合预期

• 设计方案生成后：确认技术方案是否符合预期

• 代码生成前：确认实现计划

• 测试失败时：甄别是功能问题还是测试问题（AI 可以协助判断，但还是得靠人做最终决策）

HIL 不是为了"控制"AI，而是为了在关键节点引入人的判断力，确保方向正确。

三、VB Coding 的七步标准化流程

让我们深入到具体的操作层面，看看这套标准化流程是如何运作的。

步骤 1：需求梳理 - 从模糊到清晰

目标：将业务需求拆解为可独立执行的用户故事卡

核心价值：

• 降低单次执行风险：大需求拆小，每个故事卡 1-5 天工作量

• 澄清隐式逻辑：通过 RAG 发现需求中的模糊点和遗漏点

• 强制确认：HIL 机制确保理解一致

工作流：

输入的上下文：

• 业务需求文档

• 产品原型图

• 业务规则说明

HIL 介入点：

1. AI 提问澄清（数据录入方式、字段关联、状态流转等）

2. 逐卡审核确认

3. 发现问题时沟通修改

固化提示词：产品经理标准故事卡生成提示词.mdc

实战要点：

• ✅ 前后端强制分离：规避多语言带来的技术栈上下文增多

• ✅ 零猜测原则：不确定的地方 AI 会主动提问，绝不臆造

• ✅ 避免 scope 扩散：严格按照原始需求，不擅自扩展

输出物：.po/story/ 目录下的标准化故事卡文件

步骤 2：补充项目信息 - 构建知识地图

目标：

• 为 AI 生成项目能力说明书（Repo Wiki），明确可复用的能力

• 梳理应用架构关系（多项目/微服务场景），明确代码应该写在哪里

核心价值：

• 避免重复造轮子：知道哪些功能已经实现

• 保证技术一致性：生成的代码符合现有架构

• 明确职责边界：清楚代码应该写在哪个项目的哪个模块

• 加速新人理解：快速了解项目全貌和架构关系

工作流：

生成的知识库结构：

1. 应用架构文档（多项目/微服务场景）：

.cursor/rules/└── PROJECT_ARCHITECTURE.mdc     # 应用架构说明    ├─ 应用全景图（Mermaid）    ├─ 项目清单和类型定义    └─ 依赖关系图

2. 项目能力 Wiki（单个项目详细说明）：

gientech/wiki/├── README.md                    # 知识库索引├── 00-项目概述.md               # 项目全局概览│   ├─ 对外接口能力清单│   ├─ 数据模型和关系│   ├─ 业务/领域模块│   └─ 中间件依赖├── 01-业务模块-用户管理.md      # 具体模块详解├── 01-业务模块-订单管理.md└── 99-项目规范.md               # 编码规范

输入的上下文：

• 项目源代码

• 项目依赖文件（pom.xml/package.json 等）

• 现有架构文档（如有）

关键特性：

• 可追溯性：每个类、方法都标注文件路径和行号

  来源：UserService.createUser() (src/main/java/.../UserService.java:45-60)
  

• 使用示例：每个能力都有调用场景说明

• 预估复杂度：标注每个模块的代码行数

固化提示词：

• 应用架构梳理提示词.mdc - 用于多项目/微服务架构梳理

• repo_wiki_生成提示词.mdc - 用于单个项目能力说明书生成

实战要点：

• ✅ 先梳理架构再生成 Wiki：多项目场景下，先明确整体关系

• ✅ 在 main 分支执行：确保文档与代码版本一致

• ✅ 定期更新：重构后重新生成 Wiki

• ✅ 作为上下文引用：实现方案设计时需要引用这些知识库

步骤 3：生成实现设计文档 - 设计先行

目标：基于需求、项目信息和规范，生成详细的实现设计文档

核心价值：

• 用户认知提升：设计文档比需求文档更好理解接下来要怎么实现

• 方案可讨论：一份设计文档比代码更容易调整

• 降低返工成本：在设计阶段发现问题，而非编码后

• 大需求可以分步执行：要实现的代码过多容易触发上下文压缩/简化实现，进而出现幻觉。而有一份完整的实现设计文档，就可以基于设计文档分步生成。相对于基于会话中的生成计划，这样自生成的准确度能有很大保障

工作流：

输入的上下文：

• 故事卡（步骤 1 生成）

• 应用架构文档（步骤 2 生成，如有）

• 项目 Wiki（步骤 2 生成）

• 项目编码规范（步骤 2 生成）

HIL 介入点：

1. AI 提出多个方案时，人选择最优方案

2. 生成设计文档后，人审核是否合理

3. 反复讨论直到方案满意

4. 最终明确确认"可以开始生成代码"

固化提示词：氛围编程协作提示词.mdc + 实现设计文档生成提示词.mdc

设计优先级原则：

1. 优先级 1：核心编排逻辑（主干流程）

2. 优先级 2：关键抽象（接口、领域模型）

3. 优先级 3：详细实现（具体方法）

两大铁律：

• ⚠️ 禁止简化实现：不能省略方法实现、简化业务逻辑

• ⚠️ 禁止无依据设计：所有设计必须基于现有代码或需求文档

步骤 4：生成代码 - 基于设计的实现

目标：基于实现设计文档，生成高质量、可执行的代码

核心价值：

• 有据可依：每行代码都能追溯到设计文档

• 质量保障：遵循编码规范和设计原则

• 可验证：对比设计文档检查完整性

工作流：

输入的上下文：

• 实现设计文档(步骤 3)

• 项目编码规范（步骤 2 生成）

代码生成原则：

1. 强制项目理解生成前必须 grep 确认枚举、常量等已存在的代码

2. 遵循设计模式面向对象设计（识别角色，对象协作）信息专家原则（逻辑跟着信息走）开闭原则（易扩展）高内聚低耦合

3. 代码质量保障必要的注释（@author 从 git 获取，@date 为当前日期）完善的异常处理使用卫语句减少嵌套方法遵循单一职责

HIL 介入点：

1. 制定实现计划后，等待人授权

2. 单文件超过 500 行时，拆分子任务分步执行

固化提示词：氛围编程协作提示词.mdc

步骤 5：生成单测 - 需求驱动的测试

目标：基于需求文档生成单元测试，验证功能符合需求

核心价值：

• 需求视角：站在业务需求角度设计测试用例，而非代码覆盖率

• 质量保障：不以通过测试为目的，以验证需求为目的

• BDD 风格：Given-When-Then，可读性强

工作流：

输入的上下文：

• 实现设计文档(步骤 1)

• 要生成单测的目标代码（步骤 4 生成）

测试用例设计：

基于需求文档识别：

• 正常场景：符合预期的输入和输出

• 边界条件：最小值、最大值、临界值

• 异常输入：null、空字符串、负数、超大值

• 业务规则：各种业务规则的组合

AI 会先生成测试计划，列出预计要覆盖的用例（UC - Use Case），例如：

测试计划：User.register() 方法
UC1: 正常场景 - 所有参数有效UC2: 边界条件 - 用户名最小长度（3个字符）UC3: 边界条件 - 用户名最大长度（20个字符）UC4: 异常输入 - 用户名为nullUC5: 异常输入 - 邮箱格式不正确UC6: 业务规则 - 用户名已存在UC7: 业务规则 - 邮箱已被注册...

与用户讨论确认测试计划是否完整，是否有遗漏的场景，确认后才生成具体的测试代码。

BDD 风格示例：

@Test@DisplayName("should_create_user_successfully_when_all_parameters_valid")voidshould_create_user_successfully_when_all_parameters_valid() {// Given: 有效的用户参数Stringusername="johndoe";Stringemail="john@example.com";StringrawPassword="Password123";
// When: 调用注册方法Useruser= User.register(username, email, rawPassword);
// Then: 用户创建成功，状态为待激活    assertThat(user).isNotNull();    assertThat(user.getUsername()).isEqualTo(username);    assertThat(user.getStatus()).isEqualTo(UserStatus.PENDING);}

核心原则：

• ✅ 黑盒测试立场：不关注内部实现，只验证输入输出

• ✅ 业务驱动：基于需求文档设计用例，而非代码结构

• ✅ 完整流程验证：测试期望基于完整业务流程的最终输出

HIL 介入点：

1. 测试计划生成后，人确认用例覆盖是否完整

2. 测试失败时，人判断是功能问题还是测试问题

固化提示词：单测生成提示词.mdc

步骤 6：跑测试并修复 - 质量闭环

目标：执行测试，根据结果修复代码或测试，确保质量

核心价值：

• 问题早发现在开发阶段而非测试阶段发现问题

• 根因分析区分是功能问题还是测试问题

• 持续改进循环修复直到所有测试通过

失败分析流程：

错误类型判断：

类型 A：测试错误（AI 可直接修正）

• 测试期望值设置错误

• 测试场景设计不完整

• 测试数据构造错误

类型 B：代码错误（必须与人沟通）

• 业务逻辑 bug

• 计算逻辑错误

• 过滤条件错误

关键原则：

• ⚠️ 禁止为了通过测试而修改测试用例（除非确认是测试错误）

• ⚠️ 禁止在未与用户沟通的情况下修改业务代码

HIL 介入点：

• 测试失败时，AI 分析原因并提供判断依据

• 如果是业务逻辑问题，必须与人讨论修复方案

实战案例：

测试失败信息：测试类：UserTest失败用例：should_throw_exception_when_email_invalid预期：抛出BusinessException("邮箱格式不正确")实际：没有抛出异常
AI分析：1. 理解失败现象：期望抛异常但没抛2. 定位根本原因：User.register()方法中缺少邮箱格式校验3. 判断错误类型：类型B-代码错误（业务逻辑bug）4. 与人沟通：需要确认是否需要邮箱格式校验，以及校验规则

步骤 7：嵌入现有流程 - 无缝集成

目标：将 VB Coding 的工作成果嵌入到团队现有的软件流程中

核心价值：

• 软件工程平滑过渡：目前仅是研发交付阶段的 AI 提效，其他环节尚未变化。需要平滑过渡，保证其他环节正常运作。

集成要点：

VB Coding 的优势：

传统开发流程中，代码评审和测试环节经常发现大量问题导致返工。而 VB Coding 通过前面的 6 个步骤：

• ✅ 需求理解一致（步骤 1 确保）

• ✅ 设计合理（步骤 3 确保）

• ✅ 代码质量（步骤 4 确保）

• ✅ 功能正确（步骤 5-6 确保）

到达代码评审阶段时，大部分问题已经被提前解决，评审更多是确认而非挑错。

四、从涟漪到海啸：效能提升的本质

回到文章开头的故事：三天完成十天的工作，这个 3 倍的效率提升到底来自哪里？

个人能力 vs 流程工具

回答客户的问题："这个提升有多少是因为你个人，多少是因为 SOP 和 AI 工具？"

坦白地说，个人因素至少占一半。

最终代码生成的好坏，取决于三个关键环节的人机协作质量：

1.需求拆解时的判断：

1. 如何拆分故事卡才能降低单次执行风险

   哪些隐式逻辑需要澄清

   边界条件如何定义

2.实现设计时的决策：

1. 技术方案是否合理

   架构设计是否符合项目规范

   关键抽象是否恰当

3.单测调整时的甄别：

1. 测试失败是功能问题还是测试问题

   业务逻辑的边界条件是否覆盖完整

   异常场景的处理是否合理

这些决策和判断，依旧强依赖个人的技术经验和业务理解。

但靠 SOP 和固化提示词确实也能达到一半提升：

• 上下文组装的标准化 RAG 机制明确了每个步骤需要引用哪些文档

• 关键信息的结构化生成各种固化提示词保证输出的完整性和一致性

• 协作模式的规范化 HIL 机制明确了哪些节点需要人介入决策

即便不是很懂 VB Coding 的新人，按照这套 SOP 操作，也能有不错的协作效果。

如果把这套 SOP 和工具交给客户团队的其他开发者：

• 新人可能需要 5 天完成（相比 10 天提升 50%）

• 熟练后可以稳定在 3-4 天（相比 10 天提升 60-70%）

• 团队整体丰俭由人，不同阶段有不同效果，但质量下限有保障

标准流程的其他隐性价值

除了效率提升，标准化流程还带来了一些容易被忽视的价值：

1. 降低"偷懒"风险

依靠个人的氛围编程并不稳定。人很容易偷懒——一两次生成准确了，就不细看代码了，直接提交。

这样容易把隐藏的 bug 带到生产环境。

而标准流程因为有一套检验机制（需求拆解确认 → 设计方案审核 → 单测驱动验证），能在多个节点发现问题，一定程度降低这个风险。

2. 防止代码风格碎片化

VB Coding 让代码生成飞快。如果不加约束，每个人都按照自己的理解和风格快速迭代功能，很快就会导致：

• 项目中多种风格的代码大量并立

• DDD 和传统三层架构混杂

• 命名规范不统一

• 异常处理方式各异

这会让后续的 AI 变得"愚蠢"。

因为 AI 理解项目时，一旦需要主观决策的变量变多（多种架构风格、多种命名规范、多种设计模式混杂），它就会陷入困惑，生成质量急剧下降。

标准流程通过固化的编码规范和设计模板，确保生成的代码风格一致，利于项目长期演进。

3. 知识沉淀与传承

氛围编程的经验都在个人脑子里，离职就带走了。

而 VB Coding 通过：

• 需求故事卡沉淀业务理解

• 实现设计文档沉淀技术方案

• Repo Wiki 沉淀项目能力

• 固化提示词沉淀协作模式

这些文档和提示词，成为团队的知识资产，可以持续复用和迭代。

五、总结：从个人英雄主义到工程化能力

如果今天你只记得一句话

个人的效能提升只是涟漪，组织的效能提升才是海啸。

VB Coding 的变革不该只是让少数"会聊天"的开发者成为 10 倍工程师，而是让整个团队通过标准化的流程和工具，系统性地提升交付质量和效率。

从这里开始

如果你也想在团队中推广 VB Coding，建议从以下步骤开始：

1.选择一个小需求试点：

• 工作量 3-5 天的独立功能

• 需求相对清晰

• 可以容忍试错成本

• 准备基础材料：

• 整理需求文档

• 为项目生成 Repo Wiki

• 准备编码规范文档

2.逐步引入流程：

• 第一轮：先跑通需求拆解→设计→编码→测试的闭环

• 第二轮：优化固化提示词，减少人工介入

• 第三轮：在团队内推广，收集反馈迭代

3.建立度量体系：

• 记录每个环节的时间消耗

• 统计返工率和缺陷密度

• 对比传统模式的效率差异

4.持续优化迭代：

• 根据实际问题调整 SOP

• 不断完善固化提示词

• 沉淀团队的最佳实践

记住：VB Coding 不是一蹴而就的银弹，而是需要在实践中不断打磨的工程化体系。从依赖个人到依赖流程，这是一场认知的转变，也是一场组织能力的变革。

🤔 留给你的思考题

读完这篇文章，你可能会有这些疑问：

1. 为什么要做需求拆分？都到研发环节了，产品需求不是已经明确了吗？直接生成实现设计文档不就好了吗？为什么还要花时间拆分故事卡？

2. 为什么要生成 Repo Wiki？AI 不是可以直接读代码吗？Repo Wiki 真的就比代码本身更容易被定位和召回吗？这多了一层文档，不是增加维护成本吗？生成的 Repo Wiki 和传统的白皮书有什么区别？

不积跬步无以至千里，如果这篇文章对你有所帮助，也希望你把他分享给别人！