提示词工程 -VB Coding 的权变之道
VB Coding 的权变之道：没有银弹，只有权衡
文 | 三七 （转载请注明出处）
公众号：三七-编程实战
一、两个质疑：标准化的悖论
书接上文
问题 1：为什么要做需求拆分？
"都到研发环节了，产品需求不是已经明确了吗？直接生成实现设计文档不就好了吗？为什么还要花时间拆分故事卡？"
问题 2：为什么要生成 Repo Wiki？
"AI 不是可以直接读代码吗？Repo Wiki 真的比代码本身更容易被定位和召回吗？这多了一层文档，不是增加维护成本吗？"
这两个问题看似在挑战流程的必要性，实则触及了更深层的矛盾：
标准化流程的初衷是降低复杂度、提升效率，但如果流程本身变成了负担，那它还有价值吗？
一个更本质的问题
在回答这两个质疑之前，我想先问一个问题：
你见过哪个"标准化流程"是放之四海而皆准的？
敏捷开发适合快速迭代的互联网产品，但不适合安全关键的航天系统
Scrum 适合小团队协作，但不适合几百人的大型项目
TDD（测试驱动开发）适合逻辑复杂的业务系统，但不适合快速原型验证
所有成功的工程实践，都不是"一招鲜吃遍天"，而是基于场景的权衡和选择。
VB Coding 也不例外。
二、需求文档：敏捷开卡的 AI 时代演进
为什么需要需求文档？
在回答"为什么要拆需求"之前，先回答一个更基础的问题：为什么需要需求文档？
这让我想起敏捷实践中的一个经典动作：开卡（Story Kickoff）。
开卡的本质：开发人员跟产品经理当面讲卡，对齐理解，确保双方认知一致。
在传统开发模式下，这个过程是口头沟通+白板演示。但在 VB Coding 场景下，情况变了：
隐式逻辑的补充是人机协作的过程：
人主动补充：研发基于经验，先补充一些明显的隐式逻辑
AI 理解分析：AI 理解需求和已补充的信息，发现模糊点
AI 主动提问：对不确定的地方提问澄清
AI 自动补齐：基于上下文和项目规范，补齐剩余的隐式逻辑
举个例子：
"支持批量导入"
人补充：导入文件格式为 CSV，包含用户名、邮箱、手机号
AI 提问：单次最多导入多少条？失败了怎么处理？部分成功如何反馈？
AI 补齐：参考项目已有的导入功能，采用异步处理+进度查询的方式
这些隐式逻辑，原本是在开卡时口头确认的，现在通过人机协作显性化到文档中。
需求文档的真实作用
需求文档（或者说故事卡）在 VB Coding 中有三个核心作用：
1. 作为"签字画押"的媒介
实现设计文档偏技术，有代码片段、技术栈选择、架构设计。要求产品经理看懂这些，有点强人所难。
而需求文档更接近业务语言，产品经理能看懂，能确认。
这是双方对齐认知、划定责任边界的契约。
2. 澄清隐式逻辑的载体
AI 通过 RAG 机制分析需求时，会主动识别模糊点并提问。研发在回答这些问题的过程中，实际上是在补充隐式逻辑。
这些补充的内容，原本就应该在开卡时确认，只是现在被显性化了。
3. 控制生成粒度的工具
这就引出了下一个话题：需求要不要拆分？
何时需要生成需求文档？
结论：看情况。
需求文档不是为了"标准化"而存在，而是为了解决实际问题。
三、需求拆分：精准生成与公共抽象的两难
VB Coding 的共识：功能越小，生成越准
这背后有两个技术原因：
原因 1：上下文压缩风险
功能越大，需要的上下文越多。当上下文超过模型窗口时，AI 会自动压缩或丢弃部分信息，导致幻觉。
原因 2：主观决策变量
逻辑复杂度越高，嵌套越多，需要 AI 做的主观判断就越多。每个判断都有出错的可能，累积起来就会偏离预期。
所以，拆小需求 = 降低单次生成风险。
但拆分带来了新的问题：无法抽象公共逻辑
举个例子：
场景：做业务中台，需要支持零售、餐饮、酒店三个行业。
中台的核心思路：识别共性，抽象公共能力；保留差异，各行业定制。
但如果采用"拆小需求"的策略：
问题来了：
三个故事卡并行开发，AI 在生成每个故事卡的代码时，并不知道其他两个行业的逻辑
每个行业各实现一套，缺少公共抽象
后续要重构成中台架构，需要大批量代码改动
AI 不擅长大规模重构
你可能会说："先各自实现，后续让 AI 基于已有逻辑做重叠识别，然后重构。"
理论上可行，实践中很难。
AI 在大规模重构场景下表现不佳，原因在于：
抽象能力的局限：识别共性需要深度理解业务本质，AI 容易停留在表面相似
语法因素的连带变动：代码作用域变化、依赖关系调整，牵一发而动全身
多变数多主观决策：每个改动都需要判断影响范围，AI 很容易遗漏边界情况
大批量重构，依然是人的主场。
那该怎么办？
这就是权衡的艺术：
策略 1：需求不拆，在设计阶段拆模块
适用场景：
✅ 你对业务很熟悉，清楚如何抽象和复用
✅ 能一开始就设计好公共层和定制层
✅ 有足够的技术经验做架构设计
操作方式：
优势：设计层面做好抽象，避免重复代码。
风险：设计文档过大，容易触发上下文压缩。
策略 2：需求拆小，允许重复代码存在
适用场景：
✅ 对业务不熟悉，不清楚共性在哪里
✅ 快速交付优先，后续可以重构
✅ 团队新人较多，降低单次执行难度
操作方式：
优势：单次生成风险低，新人也能操作。
代价：会有重复代码，增加后续维护成本。
一个反直觉的洞察
传统软件工程中，"DRY 原则"（Don't Repeat Yourself）是铁律。重复代码被视为技术债务。
但在 AI 辅助编程时代，重复代码的成本被重新定义了。
以前，重复代码意味着：
修改一个地方，要改 N 个地方，容易遗漏
维护成本高，代码量膨胀
现在，有了 AI：
修改可以用 AI 批量完成（识别相似代码并统一修改）
只要逻辑清晰，生成很快，维护成本下降
重复在当下可能不是问题，盲目抽象反而可能过度设计。
这不是说重复代码就是好的，而是说：
在不确定如何抽象时，先让业务跑起来。当重复成为瓶颈时，再重构。隔离优先于复用。
四、Repo Wiki：跳表思维与代码质量的依赖
为什么要生成 Repo Wiki？
很多人误解了 Repo Wiki 的作用，认为它是"给人看的文档"。
实际上，Repo Wiki 的核心目标是：让 AI IDE 内置的 RAG 更快、更准确地定位和召回代码。
跳表思维：能力描述与能力实现分离
Repo Wiki 的设计思路类似于"跳表"数据结构：
跳表的核心：在数据层之上建立索引层，快速跳转到目标。
Repo Wiki 的核心：在代码实现之上建立能力描述层，快速定位到可复用能力。
为什么不直接读代码？
原因 1：能力的使用场景难以从代码反推
看一个真实的例子：
问题来了：createUser 和 registerUser 有什么区别？什么时候用哪个？
仅从代码实现很难判断，但如果有 Repo Wiki：
一目了然。
原因 2：相似能力的选择需要人工补充
老项目中，相似的能力可能有一大堆。仅靠 AI 自动分析，定位效果很差（太多主观决策）。
而生成 Repo Wiki 后，可以人工加工：
补充能力之间的差异说明
标注哪些能力已废弃（因为向前兼容不敢动）
提示选择时的细分逻辑
Repo Wiki 不是一次性生成完就扔着不管，而是需要持续维护的知识库。
Repo Wiki 的局限：依赖代码质量
Repo Wiki 的效果，严重依赖现有代码的设计和质量。
面向对象风格的代码：
✅ 容易识别 Domain 中的类、职责、行为
✅ 高内聚低耦合，能力边界清晰
✅ 容易生成可复用的能力清单
面向过程一把梭的代码：
❌ 函数耦合太多职责，难以拆分
❌ 一个函数做了 5 件事，想复用其中 1 件，拆不开
❌ 入口层编排勉强清晰，内部逻辑一团糟
即便生成了 Repo Wiki，暴露的"可复用能力"也很难被复用。
何时需要生成 Repo Wiki？
结论：看项目规模和代码质量。
Repo Wiki 不是银弹，它的价值取决于代码质量和项目规模。
一个延伸的洞察
Repo Wiki 的生成和维护，暴露了一个有趣的现象：
在 AI 编程时代，写一手好代码的手艺人，价值不是降低了，而是提升了。
为什么？
代码本身不值钱了（AI 可以快速生成）
但判断如何设计、如何抽象、如何解耦，越来越值钱
这些能力需要大量实践和重构经验，而在 AI 编程时代，新人锻炼这些能力的机会反而更少了
技术债务在 AI 时代依然是债务，甚至会被放大。
五、实现设计文档：认知提升与维护成本的平衡
为什么需要实现设计文档？
在 VB Coding 流程中，实现设计文档有两个关键价值：
价值 1：帮助研发理解"接下来将会怎么实现"
虽然 AI 在对话框中生成实现计划也能达到这个效果，但实现计划往往比较粗粒度，无法感知细节差异。
场景对比：
当研发不是很理解要怎么实现时，看实现计划根本判断不了对错。
但如果有详细的实现设计文档，研发能从中学习，理解将要怎么实现，认知提升后，能给出修改意见。
这是一个认知提升的过程。
价值 2：大功能的分步执行
在没有实现设计文档时，仅靠对话框来承接上下文。即便 AI 拆分了生成步骤并逐步生成，也会越往后越离谱。
原因：越后面上下文越大，触发上下文压缩和丢弃就越多。
合理的方式：
每一次生成，从实现设计文档中加载有限的相关上下文，保证每次上下文大小稳定，降低幻觉概率。
每步上下文都可控，避免雪崩式幻觉。
何时需要实现设计文档？
结论：看需求规模。
如果需求已经拆得很小，其实不需要实现设计文档。
需求变更时，要改设计文档吗？
这是一个经常遇到的场景：
"开发过程中，产品提了个小变更，需要改实现设计文档再重新生成代码吗？"
我的决策：不要。
原因：
需求变更是软件工程的常态：为每个小变更都更新文档，成本太高
小变更用 Vibe Coding 很好解决：直接对话式调整，比改文档再生成更快
文档和代码不一致怎么办？后面会讲
VB Coding SOP 的适用边界
可以理解这套 VB Coding SOP，解决的是需求 0-1 大批量代码生成的场景。
0-1 的定义：该功能的第一次生成，不是项目 0-1。
后续的小调整、Bug 修复、需求微调，用普通的 Vibe Coding 就够了。
文档和代码不一致怎么办？
这可能不是一个问题。虽然需求变更后，实现设计文档可能与代码不一致。但本来该保持一致的，也不是实现设计文档，而是 Repo Wiki。
理解方式：
实现设计文档 = 项目的增量变更记录
Repo Wiki = 项目的快照
对于理解项目和后续开发，记住最新的快照即可。
所以，Repo Wiki 需要定期更新（比如每次重大重构后），而单次的实现设计文档可以视为"一次性消耗品"。
六、研发环境：提效的天花板
被忽视的制约因素
前面讨论的都是 VB Coding 流程内部的权衡，但还有一个更根本的问题：
VB Coding 的提效成果，受研发环境的制约。
如果研发环境本身有明显的阻塞点，VB Coding 可能会放大这些问题，从而达不到预期的效益。
常见的研发环境阻塞点
阻塞点 1：测试环节的问题
场景：
测试对需求理解不正确，提出一堆"Bug"，但实际是对的
产品经理变更需求只告诉 QA 没告诉开发，测试按新需求验收
影响：
VB Coding 的一个特点是：在不完全理解业务、不完全理解项目、甚至不完全理解 AI 生成的代码全貌时，就完成了需求开发。
（通常只关注模糊的那部分逻辑生成情况，对明确的计算规则就不细看了）
结果：
提测后发现问题，不得不重新理解需求、理解 AI 生成的代码，才能判断：
是误报？
是改了需求没通知？
还是真的有 Bug？
节省的时间，可能赶不上后面排查的成本，得不偿失。
阻塞点 2：部署环境的问题
典型场景：
公司只有一个测试环境，且只能部署一个测试分支。所有开发都在这个环境做冒烟测试。
AI 提效前的情况：
一周只有 2-3 个需求并行开发
测试环境相对够用，轮流部署测试
测试分支按迭代拉取，定期合并
AI 提效后的问题：
VB Coding 把代码生成速度提升了 3 倍，一周可以并行开发 5-8 个需求。
但问题来了：
环境冲突加剧：多个需求同时完成，都要部署测试环境验证
测试环境一直在部署：开发者 A 刚部署完准备测，开发者 B 的需求又要部署，测试根本来不及验证
未验证功能堆积：为了不阻塞其他人，未验证的功能分支就合并到测试分支了
测试分支混乱：测试分支成了长期分支，堆叠了大量功能，与生产环境分支差异越来越大
回归风险失控：不知道哪些功能验证过，哪些没验证过
结果：
代码生成快了，但验证慢了
并行能力强了，但环境资源成为瓶颈
提测频率高了，但测试质量下降了
瓶颈从代码生成转移到了环境资源和测试验证。
阻塞点 3：代码评审的延迟
场景：
团队规定必须有人 Review 才能合并
但 Reviewer 总是忙，PR 堆积如山
评审标准不明确，反复要求修改
影响：
代码生成很快，但等待评审的时间变成了新的瓶颈。
系统思维：识别最短板
这让我想起了"约束理论"（Theory of Constraints）：
系统的产出速度，取决于最慢的那个环节。
VB Coding 提升了研发环节的速度，但如果其他环节跟不上，整体提效就会受限。
代码生成从 3 天降到 1 天，但总周期从 10 天只降到了 8 天。
因为瓶颈不在代码生成，而在评审、部署、测试。
如何应对？
策略 1：先优化瓶颈环节
在引入 VB Coding 之前，先识别研发流程中的瓶颈：
如果测试是瓶颈，先建立清晰的验收标准，改善需求同步机制
如果部署是瓶颈，先优化 CI/CD 流程，提升环境稳定性
如果评审是瓶颈，先建立快速评审机制，或者小步快跑减少单次变更
把木桶最短的那块板先补齐，VB Coding 的价值才能充分发挥。
策略 2：调整 VB Coding 的使用方式
如果环境短期无法改善，调整 VB Coding 的使用策略：
小步快跑：拆小需求，减少单次变更，降低评审和测试成本
增强沟通：生成代码后主动与测试和产品对齐，避免后期返工
提升质量：利用 VB Coding 的单测机制，在提测前就发现问题
适应环境，而非对抗环境。
七、权变之道：没有银弹，只有权衡
识别场景，做出选择
回到文章开头的两个质疑：
Q1: 为什么要做需求拆分？
A: 看情况。
如果你对业务熟悉，能一开始设计好架构 → 不拆，整体设计更优
如果你对业务不熟，降低风险优先 → 拆小，容忍重复代码
Q2: 为什么要生成 Repo Wiki？
A: 看情况。
如果项目大、代码质量好 → 生成 Wiki，提升复用效率
如果项目小、代码耦合严重 → 不生成，直接读代码更快
没有银弹，只有权衡
每个决策背后都是权衡：
VB Coding 的 SOP 不是教条，而是工具箱。根据场景选择合适的工具，才是高手。
SOP 的本质：固化经验，而非固化流程
很多人误解了 SOP 的作用，认为 SOP 就是"必须按这个步骤来"。
实际上，SOP 的本质是固化经验，而非固化流程。
固化提示词 = 固化"如何与 AI 协作"的经验
固化检查点 = 固化"哪些环节容易出错"的经验
固化模板 = 固化"什么样的输出是高质量"的经验
但具体怎么用，取决于你的场景。
就像厨师有菜谱，但不同的食材、不同的顾客口味、不同的厨房设备，做出来的菜肯定不一样。
菜谱是经验的沉淀，但不是死板的教条。
持续迭代，适应变化
最后要强调的是：
大模型在升级，工具在升级，项目在变化，团队在变化。
所以，VB Coding 的 SOP 和提示词也需要持续迭代：
根据新的大模型能力调整提示词
根据项目特点定制流程
根据团队反馈优化协作机制
它既具备工程化可复用的特性，也具备需要持续迭代的诉求。
八、总结：标准化探索的终极目标是适应变化
每个"看情况"背后，都是对场景的识别、对约束的理解、对代价的权衡。
VB Coding 的标准化探索，不是为了创造一个"放之四海而皆准"的银弹，而是为了：
沉淀可复用的经验：通过固化提示词和 SOP，让新人也能快速上手
提供决策的框架：面对不同场景，知道如何权衡和选择
识别真实的瓶颈：不只看代码生成，还要看研发环境的天花板在哪
建立迭代的机制：随着环境变化，持续优化流程
没有银弹，只有权变。工程化的最高境界，是拥有一套工具箱，并知道什么时候用哪个工具。
如果今天你只记得一句话
每个标准化方案都有其适用的场景。探索的重心是磨练识别场景、识别约束，然后从工具箱里选出最适合的那一个的判断力。
从这里开始
如果你也在探索 VB Coding，建议记住这几个原则：
识别你的场景：项目规模、代码质量、团队能力、研发环境
找到你的瓶颈：是代码生成？还是评审、测试、部署？
选择合适的工具：不是所有步骤都必须做，根据场景取舍
持续观察和调整：效果不好就改，没有完美的流程
沉淀你的经验：把成功的实践固化成提示词和 SOP
记住：VB Coding 标准化不是一套死板的流程，而是一种思维方式——用工程化的手段，让 AI 的能力可复制、可规模化、可持续。
📦 资源获取
文中提到的提示词已开源，可以在以下仓库中找到并用于学习：
VB Coding 提示词工具包：
GitHub 仓库：VB-Coding-Demo
包含：
需求拆解提示词（产品经理标准故事卡生成）
应用架构梳理提示词
Repo Wiki 生成提示词
实现设计文档生成提示词
单测生成提示词
氛围编程协作提示词
使用建议：
这些只是初版的提示词，不一定完全适合你的团队
建议先理解背后的设计思路，再根据实际情况调整
记住：工具箱只是起点，持续迭代才能适应你的环境
不积跬步无以至千里，如果这篇文章对你有所帮助，也希望你把它分享给需要的人！
版权声明: 本文为 InfoQ 作者【Jxin】的原创文章。
原文链接:【http://xie.infoq.cn/article/e33b9cfa3a08b4d722d927951】。
本文遵守【CC-BY 4.0】协议，转载请保留原文出处及本版权声明。
极限编程小🐎农 2018-09-22 加入
你的每一行代码，都是你的名片。
评论