提示词工程 - 复杂项目 -VB Coding
VB Coding 实战：从四象限交流模型到提示词工程优化
文 | 三七 （转载请注明出处）
公众号：三七-编程实战
不积跬步无以至千里，欢迎来到 AI 时代的编码实战课
一、场景引入：一次客户现场的 VB Coding 实验
1.1 实验目标与背景
2025 年 10 月，我在客户现场进行了一次 VB Coding 项目实验。实验的核心目标：
证明 VB Coding 可以达到 100%采样率：所有代码都由 AI 生成，不是 20～30%的采纳率
验证效率的显著提升：用 3-4 天完成传统模式下需要更长时间的需求，实现翻倍级的效率提升
探索工程化落地路径：从实验室到生产环境，需要什么样的工具和方法论
实验的背景是一个真实的客户项目，具有典型的复杂性：
业务规则复杂：多层嵌套的业务规则，各种边界条件和异常场景
需求频繁变化：产品经理 &前端在实验期间就提出了 3 个小变更需求
同时，这个项目还有客户特有的复杂性：
规则逻辑拆分在代码和数据库：一张大的规则表，不同规则取不同字段做不同分支判断，代码和数据高耦合
技术风格多样：多种设计模式和编码风格并存，缺少统一规范
文档不完备：存在大量隐含知识和二义性描述，很多设计决策只在口头交流中
1.2 实践步骤全记录
第一天：环境搭建
申请开发环境：申请仓库、CICD 工具、jar 包仓库、业务系统等等权限
熟悉项目结构：理解模块划分、分层架构、包命名规范
调试开发环境：拉 jar 包、起服务
第二天：需求盘点
这一天是整个实验中最关键的认知建立阶段：
步骤 1：复制需求文档
将产品需求文档完整复制到工作目录
步骤 2：让 AI 帮助解读需求（学习型场景）
将需求文档输入 AI，要求解读业务逻辑
让 AI 将自然语言描述转换成逻辑流程图
让 AI 分析核心执行链路，以及每个链路做哪些规则
步骤 3：发现需求文档的典型问题
在这个过程中，我发现了需求文档的 5 个典型问题：
同一句话存在二义性：可以解释成不同的两个逻辑分支
专业术语与背后逻辑难以关联：术语本身没问题，但不知道术语背后要做什么逻辑
缺少部分隐含逻辑：这部分逻辑可能是产品经理私下和开发的交流，也可能是开发原有的认知
规则逻辑拆分在代码和数据库：现有实现把规则拆成代码逻辑和数据库配置，两块逻辑高耦合且有很多定制逻辑（一张大的规则表，不同规则要取不同字段去做不同的分支判断）
步骤 4：询问开发同学补充隐含知识
针对二义性问题，询问原开发同学确认真实意图
记录文档外的隐含知识
整合到 AI 的上下文中（训练型场景）
这一天的产出是：
一份结构化的需求解读文档
多张业务逻辑流程图
第三天：方案设计
这一天是与 AI 深度协作的探索型场景：
步骤 1：与 AI 协作生成实现设计文档
基于需求解读和现有代码结构，设计实现方案
定义核心编排逻辑：哪些角色、如何协作、数据如何流转
设计关键抽象：接口定义、领域对象、职责划分
规划代码生成步骤：按依赖关系排序，明确生成顺序
步骤 2：反复讨论优化方案
AI 提出初版方案
我基于方案了解项目和需求
我基于自己的经验和理解提出调整意见
AI 根据反馈优化方案
循环迭代直到方案清晰可执行
步骤 3：拆解实现设计文档
发现实现设计文档达到 6-7k 行
生成代码生成步骤
这一天的产出是：
1 份主实现设计文档（约 7k 行）
清晰的代码生成步骤指南
第四天：代码生成与迭代
这一天是代工型场景的集中体现：
步骤 1：基于实现设计文档分步生成代码
第 1 批：枚举类和常量类（7 个文件）
第 2 批：参数对象和 DTO（5 个文件）
第 3 批：计算器和工具类（8 个文件）
第 4 批：服务层和编排逻辑（6 个文件）
第 5 批：接入层和配置类（4 个文件）...
步骤 2：补充小变更需求
产品经理 &前端在这两天又提出了 3 个小变更
直接几句话让 AI 局部代码变更完成需求
小变更从提出到完成，平均耗时不到 10 分钟
步骤 3：与原开发同学一起 CR
逐个类进行代码审查
原开发同学确认：代码符合预期
发现亮点：AI 实现了一些原开发同学没考虑到的小细节（如边界条件处理、业务过滤逻辑）
代码质量超过生产标准
步骤 4：代码定稿
根据 CR 意见微调
最终提交代码仓库
1.3 实验成果
定量数据：
30 个类：涵盖枚举、常量、参数对象、计算器、服务层、接入层
7000 行代码：完整的业务逻辑实现，包含注释、异常处理、日志记录
一次性生成成功：分 16 批生成，每批都是完整可运行的代码
小变更即时完成：平均 1 小时内完成从需求到代码的全流程
定性评价：
原开发同学确认符合预期
代码质量达到生产标准
部分细节实现超出预期
最震撼的时刻：
产品经理提出需求后，听到的答复是"已经完成"。这不是未来的愿景，而是当下的现实。
1.4 引出核心问题
在这次实践中，有一个关键的中间产物是我以往实现中所不需要的-实现设计文档：
为什么多了"实现设计文档"这个东西？
这个中间产物是多余的吗？还是必要的？
带着这个问题，我们来深入思考 VB Coding 中人的核心价值。
二、VB Coding 中的三方协作与人的价值
2.1 三方关系拆解
在 VB Coding 的实践中，实际上存在三个关键角色：
让我们逐一拆解当前项目这三方的特殊性：
角色 1：业务需求（What to build）
特点：
定义要实现什么功能
描述业务逻辑和数据流向
描述业务规则和约束
明确输入输出和边界条件
问题：
❌ 不完备：缺少分隔、二义性、隐含逻辑
❌ 不精确：专业术语与背后逻辑难以关联
❌ 不一致：规则逻辑拆分在文档和口头交流中
角色 2：项目代码仓（How to build）
特点：
定义怎么实现（编码风格、设计模式、技术栈）
体现团队的工程化实践
问题：
❌ 风格多样：多种设计模式和编码风格并存
❌ 缺少文档：很多设计决策只存在于代码中
角色 3：cursor（Tool）
特点：
强大的代码生成能力
丰富的编程知识储备
强大的代码定位和召回能力(RAG)
问题：
❌ 无法自主决策：在当前场景该用哪种风格？
❌ 上下文有限：窗口大小限制，无法一次性理解所有信息
❌ 容易产生幻觉：在信息不足时会"猜测"或"简化"
2.2 人的核心价值：链接三方的桥梁
在这个三方协作模型中，人的核心价值不是写代码，而是链接三方。
具体来说，人需要做三件事：
价值 1：信息链接（通过 RAG）
任务：将业务需求和项目代码仓的信息输入 AI 的上下文
工具：
代码索引：让 AI 能够检索项目代码
需求文档：结构化的需求描述
隐含知识：补充文档外的信息
挑战：
上下文窗口有限（通常 8k-128k tokens）
信息过多会被压缩或丢失
信息过少会导致幻觉
价值 2：规则制定（通过提示词工程）
任务：定义 AI 与人的协作规则
内容：
怎么设计：优先设计核心编排逻辑，再补充细节
怎么拆解：按模块、按层次、按阶段拆分任务
怎么执行：分步生成、渐进式完善、禁止简化
怎么验证：代码审查、一致性检查、质量把控
挑战：
规则太少：AI 容易偏离预期
规则太多：AI 难以理解和执行
规则冲突：不同原则之间可能矛盾
价值 3：质量把控（通过人工验证）
任务：验证 AI 生成的代码是否符合预期
方法：
CR：逐个类检查实现逻辑
一致性检查：对比实现设计文档和代码
业务验证：确认业务规则正确实现
原则：
AI 只是工具，人才是能担责的载体。可以借助 AI 验证，但不能只靠 AI 验证。
2.3 为什么需要实现设计文档？
回到开头的问题：为什么多了"实现设计文档"这个中间产物？
现在我们可以给出答案了。实现设计文档的存在，是由三方协作的特点决定的：
原因 1：代码仓层面（解决风格决策问题）
问题：
Cursor 的代码定位和召回很强，能很好地找到代码并识别出模式
但项目多种风格并存，AI 无法自主决策"在当前场景该用哪种风格"
解决：
实现设计文档明确定义：这次要用哪种风格、为什么用这种风格
相当于给 AI 明确一个"设计决策书"，而不是让 AI 自己猜
原因 2：用户层面（降低认知负载）
问题：
我不熟悉业务和项目
如果只是简单的执行计划，我无法判断实现方案的对错
来回生成的成本和时间浪费很高
解决：
有详细的实现设计文档，我就能学习并给出意见
在代码生成前就发现问题，而不是生成后才发现
降低返工成本
原因 3：需求层面（防止上下文压缩）
问题：
需求未被很好拆解，单个太大
拉起所有规则分析后，上下文太大被压缩
进而出现幻觉，导致需求和实现不一致
解决：
实现设计文档有意识地制定拆分规则
逐步实现的模式，防止 AI 压缩上下文或简化实现
每个子任务的上下文控制在合理范围内
总结
实现设计文档不是多余的翻译，而是必要的认知台阶。它是需求、代码仓、AI 三方对话的场地。而用户是协调他们对话的会议主持
三、概念科普：AI 辅助编程的四象限交流模型
3.1 四象限模型
太极生两仪，两仪生四象，我们试试用二维四象的结构，来描述人与 AI 的协作场景，并盘点每种场景一些现有的实践，以及我们所面对的挑战和机遇。
横轴：用户知道 ↔ 用户不知道
纵轴：模型知道 ↔ 模型不知道
根据这两个维度，我们可以将 AI 辅助编程的场景分为四类：
3.2 四象限详解
象限 1：代工型交流（都知道）
定义：用户和 AI 都清楚要做什么，AI 负责执行繁琐的工作
典型场景：
代码翻译：Java 转 Python、SQL 转 NoSQL
代码重构：提取方法、重命名变量、优化结构
批量生成：根据模板生成大量相似代码
格式转换：JSON 转 XML、CSV 转 Excel
类比：
就像请翻译官，你说中文他翻英文，大家都懂只是你懒得做。
特点：
✅ 效率最高：AI 可以快速完成
✅ 质量稳定：规则明确，不容易出错
✅ 适合自动化：可以批量处理
在本次实践中的应用：
第四天的代码生成就是典型的代工型场景
基于明确的实现设计文档，AI 按步骤生成代码
30 个类、7000 行代码，分 5 批生成完成
象限 2：学习型交流（AI 知道，用户不知道）
定义：AI 拥有知识，用户需要学习
典型场景：
学习新框架：Spring Boot、React、TensorFlow
理解 API 文档：如何使用某个库的 API
学习设计模式：单例、工厂、观察者
理解算法原理：排序、搜索、动态规划
类比：
就像请老师，他懂 Spring 你不懂，他教你。
特点：
✅ 学习效率高：AI 可以定制化讲解
✅ 互动性强：可以随时提问和澄清
⚠️ 需要验证：AI 可能给出过时或错误的信息
在本次实践中的应用：
第二天让 AI 解读需求文档
将自然语言描述转换成逻辑流程图
帮助我快速理解复杂的业务规则
象限 3：训练型交流（用户知道，AI 不知道）
定义：用户拥有知识，需要"教"给 AI
典型场景：
公司内部流程：审批流程、发布流程、代码规范
业务规则说明：特定行业的业务逻辑
项目特定知识：这个项目为什么这么设计
隐含知识补充：文档外的口头约定
类比：
就像教徒弟，你懂公司流程 AI 不懂，你教他。
特点：
⚠️ 需要明确表达：用户要清晰地描述知识
⚠️ 需要反复确认：确保 AI 理解正确
✅ 可以沉淀：通过提示词/知识库固化知识
在本次实践中的应用：
第二天询问开发同学获取隐含知识
将文档外的信息整合到 AI 的上下文中
补充产品经理私下交流的业务规则
象限 4：探索型交流（都不知道）
定义：用户和 AI 都没有现成答案，需要一起探索
典型场景：
创新架构设计：没有先例的系统设计
探索最佳实践：在新场景下找到最优解
问题诊断：复杂 bug 的根因分析
方案对比：多个方案的优劣权衡
类比：
就像两个人一起解谜，谁都没答案，一起试错。
特点：
⚠️ 不确定性高：可能需要多次尝试
✅ 创造性强：可能产生意想不到的方案
⚠️ 需要验证：必须通过实践检验结果
在本次实践中的应用：
第三天与 AI 协作生成实现设计文档
我不确定最优方案，AI 也没有现成答案
通过反复讨论和迭代，最终形成可行方案
实践总结：工作如果落在代工模式，效率是最高的。但通过本次实践不难看出，在代工模式可能就花了 2-3 小时，大部分实践开销是在探索模式和学习模式。训练模式因为 RAG 中检索这个动作是人为去搜集信息的，所以时间成本也大。所以我们的提效方式核心还是降低代工模式外其他模式在工作中的时间占比。
3.3 挑战和机遇
理解了四象限模型后，我们再来看看认知边界扩展后的挑战和机遇：
两条轴线的拖动：
轴线 1：向下扩展 AI 的认知边界（让 AI 知道更多）
目标：让学习型和代工型场景占比更大，AI 带来的价值提升
工具：
微调（Fine-tuning）：在特定领域的数据上训练模型
RAG（Retrieval-Augmented Generation）：检索相关信息增强生成
提示词工程（Prompt Engineering）：设计更好的提示词
效果：
AI 可以更好地帮助我们学习
AI 可以更稳定更快速地帮我们完成繁琐工作
轴线 2：向左扩展用户的认知边界（让我们知道更多）
目标：让训练型和代工型场景占比更大，个人的价值提升
工具：
提示词工程（提问的艺术）：让 AI 更清晰地理解我们的意图
结构化输出：让 AI 返回结构化、图形化的知识
逻辑化表达：从现象到原理到举一反三
效果：
让我们能够发现更多 AI 可以发挥价值的场景
让我们可以更好的冲到链接者和提问者的角色
需要特别强调的是：AI 的轴线不是固定的，而是在高速变化的。
变化的维度：
模型能力提升：GPT-3.5 → GPT-4 → GPT-4 Turbo → Claude 3.5 Sonnet
上下文窗口扩大：4k → 8k → 32k → 128k → 200k
多模态能力增强：文本 → 文本+图片 → 文本+图片+语音
应对策略：
关注资讯：知道不同模型适合什么，模型新版本升级了什么
大量实践：探索和证实模型的特性
持续调整：根据模型能力调整提示词策略
重要提醒：
模型的表象不是固定的规则，所以升级文档和介绍本身只能作为大方向的参考。实际上能做什么、做到什么样，还需要大量的实践去探索和验证。
总结
VB Coding 的本质，是在有限窗口内构建完备上下文，让 AI 从'可能胡说'变成'稳定输出'。设定机制，让 AI 可以从单体变成分布式，借助任务拆解+多次会话完成大功能
四、实践展开：提示词工程的 5 大优化策略
在理解了三方协作模型和四象限交流模型后，我们来看看在这次实践中，提示词工程做了哪些优化来提高 AI 在代工型场景的协作效果。
4.1 策略 A：角色定义 + 目标制定 + 约束设计
理论依据
为什么需要角色定义？
想象一下，如果你问"如何理解量子纠缠"，物理学家和哲学家的回答会完全不同：
物理学家：从波函数、测量坍缩、贝尔不等式讲起
哲学家：从因果关系、决定论、自由意志讲起
同样的问题，不同角色的解法是不一样的。
角色定义的作用：
圈定细分方向：让 AI 的神经网络聚焦在特定领域
降低胡说八道：减少无关知识的干扰
提供设计依据：站在对应角色立场给出理由
实践案例
在我的提示词中，角色定义部分是这样设计的：
效果验证
对比实验：
不使用角色定义时：
AI 可能给出面向过程的实现
设计决策缺少理由说明
代码风格不统一
使用角色定义后：
AI 自动使用面向对象和 DDD 思维
主动识别领域对象和职责分配
提供设计决策的理由（基于 SOLID 原则）
代码可读性、可扩展性、可测试性显著提升
总结
"给 AI 一个角色，就是给它一个思考的立场。物理学家和哲学家对同一问题的解法不同，Java 架构专家和前端工程师的代码风格也不同。"
4.2 策略 B：TOT（Tree of Thought）多场景协作
理论依据
什么是 TOT？
TOT (Tree of Thought) 是一种网状结构的决策和执行流程。与传统的线性流程不同，TOT 允许：
场景之间相互转换
某些步骤可以复用
根据实际情况动态调整流程
为什么需要 TOT？
在 VB Coding 中，用户的需求是多样的：
有时是从零开始的原始需求
有时是基于已有方案的实现
有时是对现有代码的修改
有时是方案的讨论和优化
如果只有一个固定的流程，无法适应这些不同的场景。
TOT 的核心价值：
保障问答质量下限：任何人使用该提示词都能有兜底的质量
降低个体差异：减少因个体问答经验带来的差距
提供协作规范：让 AI 学会与人协作的方式
实践案例
在我的提示词中，设计了 5 种协作场景：
每个场景都有明确的工作流程（COT）：
以场景 2：基于实现方案的代码实现为例：
TOT 的网状结构：
关键转换路径：
场景 1 → 场景 3 → 场景 2：
用户提出原始需求
AI 生成实现设计文档
进入场景 3 讨论优化方案
用户确认后转到场景 2 生成代码
场景 2 → 场景 3 → 场景 2：
生成代码后发现需要修改
回到场景 3 讨论方案调整
方案确认后继续场景 2 生成代码
场景 3 内部循环：
讨论方案 → 用户提出意见 → 优化方案 → 再次讨论
直到用户满意为止
效果验证
在本次实践中的应用：
第二天：场景 1（原始需求） → 生成需求解读文档
第三天：场景 3（方案讨论） → 反复优化实现设计文档
第四天：场景 2（代码实现） → 分 5 批生成代码
小变更：场景 4（局部变更） → 快速调整代码
质量保障：
每个场景都有明确的检查点
关键步骤强制执行（如项目理解、用户授权）
场景转换时重新识别，确保流程正确
总结
"TOT 不是线性的流程图，而是网状的决策树。每次场景转换都是一次认知对齐，确保 AI 和人始终在同一频道上。"
4.3 策略 C：HIL（Human-in-the-Loop）人机协作断点
理论依据
什么是 HIL？
Human-in-the-Loop（人在回路中）是指在 AI 执行过程中，在关键节点设置断点，强制要求人工介入确认。
为什么需要 HIL？
AI 虽然强大，但并非万能：
可能误解需求
可能选择错误的技术方案
可能做出破坏性的操作
在高成本、高风险的操作前，必须有人工确认的机会。
HIL 的两种类型：
静态断点：预先定义的强制确认点
代码生成前：展示实现计划，等待用户同意
文件删除前：明确说明影响范围，等待确认
架构调整前：说明变更理由，等待批准
动态断点：AI 识别到不确定性时主动询问
信息不足：缺少必要的上下文信息
多种选择：存在多个可行方案，无法自主决策
风险识别：发现潜在的问题或冲突
实践案例
在我的提示词中，HIL 机制是这样设计的：
效果验证
真实场景 1：静态断点
在第四天生成代码时：
AI 展示了完整的实现计划（30 个类的生成顺序）
我发现其中 2 个类的包路径不对
在代码生成前就纠正了，避免了返工
真实场景 2：动态断点
在设计实现方案时：
AI 发现 API 包和 Server 包都有 VO 和 DTO 目录
主动询问："应该把新的 DTO 放在哪个包下？"
我查看了现有代码的规律，给出了明确的指示
成本对比：
不使用 HIL：
生成错误代码 → 发现问题 → 重新生成 → 浪费时间
使用 HIL：
展示计划 → 发现问题 → 调整计划 → 正确生成 → 节省时间
总结
"HIL 不是对 AI 的不信任，而是对质量的负责。在高成本操作前暂停一下，是工程化思维的体现。"
4.4 策略 D：Reflexion 反思机制（自升级能力）
理论依据
什么是 Reflexion？
Reflexion（反思）是指让 AI 系统能够从过去的经验中学习，不断优化自己的行为。在提示词工程中，Reflexion 体现为：
记录每次协作的过程和结果
分析成功和失败的模式
提取可复用的经验和规则
将经验融入提示词，形成长期记忆
为什么需要 Reflexion？
传统的提示词是静态的：
依赖人在实践前盘点所有风格、规则和工具
无法适应项目的演进和变化
个体经验难以沉淀和传承
而 Reflexion 让提示词成为"活的"：
在日常协作中自动积累经验
碰到问题解决问题，自动补充规则
AI 自己提取的规则可能比人定义的更好理解
双记忆系统架构：
实践案例
在我的提示词中，Reflexion 机制包含两个核心系统：
1. 短期记忆系统（会话记录）
2. 洞察提取引擎
3. 智能升级流程
效果验证
假设的升级场景（基于 30 天的协作数据）：
发现的模式：
在 10 次协作中，有 7 次用户要求"不要过度抽象"
在 5 次协作中，AI 把简单的参数校验也抽成了对象
用户满意度在这些场景下明显下降
洞察提取：
参数校验不应该抽象成对象，直接在方法中处理即可
只有当逻辑复杂到一定程度时，才考虑抽象
升级提案：
用户确认后：
将新规则融入提示词的"面向对象设计"章节
清空短期记忆，开始新一轮学习
下次协作时，AI 会自动应用这个规则
总结
"提示词不是一次性设计完的说明书，而是在实践中不断进化的生命体。Reflexion 让 AI 从'执行规则'变成'创造规则'。"
4.5 策略 E：防简化机制（最高优先级铁律）
问题发现
在实践中，我发现了 AI 代码生成的 3 个关键问题：
问题 1：单次生成超过 500 行容易触发简化
表现：
方法实现变成 TODO 注释
复杂逻辑简化为简单的 if-else
必要的注释被删减
实现逻辑与计划不一样
问题 2：上下文超过 2k 行容易丢失
表现：
AI 提示"定位到实现方案第 X-Y 行的逻辑块"
生成的代码与实现设计文档不一致
问题 3：实现设计 6-7k 行直接生成不稳定
表现：
每次生成都不一样
肆意简化大量逻辑
根本无法使用
猜测原因：
Cursor 企业版按交互次数计费，单次 token 越少赚差价越多，所以可能有压缩和简化的倾向（个人猜测，未经证实）。
解决方案
在提示词中，我设计了"禁止简化实现"作为最高优先级铁律：
具体策略：
策略 1：先生成"代码生成步骤"，再逐步生成
策略 2：控制单次生成的代码量
策略 3：文档大小管理
策略 1 效果验证
实践前：
实现设计 6-7k 行，直接生成
结果：每次都不一样，大量简化，无法使用
实践后：
制定明确的生成步骤
步骤首先按业务分，但也会评估生成行数，超过 500 就拆成多个部分
按步骤逐步生成，每次控制在 500 行以内
结果：生成稳定，质量高，幻觉问题显著减少
总结
"多次生成只是多花时间，简化实现会产生缺陷。Quality over Speed - 质量优先于速度。"
五、实践中的其他发现
5.1 OOP 与工程化思维的冲突
问题描述
在这次实践中，我遇到了一个有趣的现象：
"就像同时加热水和冷水想得到温水，结果热水是热水，冷水是冷水，放到一起却各自独立。"
具体表现：
现象 1：过度 OOP
简单的参数校验也抽成了一个 Validator 对象
一个只有一个方法的类（除了 getter/setter）
为了 OOP 而 OOP，增加了理解成本
现象 2：该 OOP 的地方没 OOP
部分计算策略以面向过程实现
大段的 if-else 逻辑，没有使用策略模式
应该抽象的地方却写成了硬编码
现象 3：决策随机性
什么时候该面向对象、什么时候该面向过程，有点随机
同样的场景，有时抽象有时不抽象
缺少统一的判断标准
可能原因
原因 1：上下文断裂
网络不好，经常要"继续"
导致 AI 丢失了前面的设计决策
后续生成时无法保持一致性
原因 2：规则冲突
提示词中同时强调"面向对象设计"和"贴合现有项目风格"
两种思维规则同时存在，AI 无法自主权衡折中
缺少明确的优先级和决策规则
原因 3：缺少决策标准
没有明确定义"什么时候该抽象"
没有明确定义"抽象的粒度"
AI 只能根据模糊的原则自行判断
待探索的方向
方向 1：更明确的决策规则
可以在提示词中补充：
方向 2：分场景定义设计原则
可以区分：
新功能开发：优先 OOP，设计清晰的角色和职责
现有代码修改：优先保持风格一致，除非有明显问题
快速原型：优先简单直接，先跑通再优化
方向 3：增加一致性检查
可以在生成完成后：
检查同类逻辑的实现方式是否一致
检查抽象粒度是否合理
发现不一致时提示用户确认
5.2 文档大小管理的临界点
实践发现
在这次实践中，我发现了几个关键的临界点：
临界点 1：实现设计文档 2k 行
超过 2k 行：需要拆分为主方案和子方案
原因：单个文档太大，AI 难以把握整体结构
效果：拆分后，AI 能更好地理解和执行
临界点 2：单次生成 500 行
超过 500 行：容易触发代码简化
原因：可能是 token 成本控制机制
效果：控制在 500 行以内，生成质量稳定
解决方案
方案 1：主方案+子方案架构
方案 2：分步生成策略
总结
"AI 的上下文窗口虽然在扩大，但认知负载是有临界点的。文档超过 2k 行、单次生成超过 500 行，质量就会明显下降。解决思路不该是丢弃和简化内容，而是拆分和逐步生成。"
六、总结回顾：从实践到方法论
6.1 如果今天你只记得一句话
"VB Coding 的成功，不在于 AI 有多强，而在于我们如何用提示词工程，在有限窗口内构建完备上下文，让 AI 从'可能胡说'变成'稳定输出'。人的价值，是链接需求、代码仓、AI 三方的桥梁。"
6.2 延伸思考：内容之外的洞见
思考 1：纯需求直接迭代产品的可能性
当前实践结果证明：
纯需求直接迭代产品目前还不现实，但实现个 50%是没问题的
这次实践，我自己也不懂需求，可能还不如产品经理，但生成出来的代码是对的。
为什么不现实？
需求文档通常不完备（缺少分隔、二义性、隐含逻辑）
AI 无法自主决策技术方案（多种风格并存时）
缺少业务上下文（为什么要这么设计）
未来的可能性：
随着模型能力提升（更大的上下文窗口、更强的推理能力）
随着需求文档的结构化（更清晰的描述、更完整的信息）
随着提示词工程的优化（更好的协作机制、更精准的规则）
也许有机会达到 70%、80%，甚至更高
但即使达到 80%：
剩下的 20%可能是最难的 20%（边界条件、异常处理、性能优化）
仍然需要人的介入和把控
AI 是助手，不是替代
思考 2：生成结果的有效性验证
可以借助 AI 进行验证：
让 AI 对比实现设计文档和生成的代码
让 AI 检查代码的一致性和完整性
让 AI 运行静态代码分析工具
但不能只靠 AI 验证：
AI 可能会"自圆其说"（生成的代码和验证的逻辑都是 AI 产生的）
AI 无法判断业务逻辑的正确性（只能判断代码的语法正确性）
AI 无法承担责任（出了问题谁来负责？）
人才是能担责的载体：
最终的质量把控仍需人工确认
关键的业务逻辑需要人工审查
代码上线前需要人工测试
合理的验证流程：
AI 生成代码
AI 自动检查（语法、规范、一致性）
人工审查（业务逻辑、边界条件、性能）
自动化测试（单元测试、集成测试）
人工测试（端到端测试、用户验收测试）
上线发布
作者后记：
这次客户现场的 VB Coding 实验，让我深刻体会到 AI 辅助编程的巨大潜力。30 个类、7000 行代码，从需求到上线，只用了 3-4 天。这不是科幻，而是现实。
但更重要的是，我意识到：AI 不是来替代我们的，而是来升级我们的。我们的角色从"编码者"变成了"架构师+审查员+桥梁"，从写代码变成了设计系统、把控质量、链接三方。
提示词工程不是简单的"写提示词"，而是一套完整的方法论：角色定义、TOT 场景、HIL 断点、Reflexion 反思、防简化机制。这些策略的背后，是对 AI 能力边界的深刻理解，是对人机协作模式的不断探索。
未来已来，只是分布不均。希望这篇文章能给你一些启发，让你也能用好 VB Coding 这个强大的工具。
不积跬步无以至千里，让我们一起在 AI 时代的编码实战中不断前行。
版权声明: 本文为 InfoQ 作者【Jxin】的原创文章。
原文链接:【http://xie.infoq.cn/article/f89d5fdbe08ff5f517664c219】。
本文遵守【CC-BY 4.0】协议，转载请保留原文出处及本版权声明。
极限编程小🐎农 2018-09-22 加入
你的每一行代码，都是你的名片。
评论