| 你让 AI 实现订单取消功能，它写了取消接口、更新状态、调用退款、发送通知，代码完成测试通过。但上线后你才发现：没检查是否已发货、没处理积分回滚、没做批量限流、没记录取消原因。本文拆解 AI "只看到动作不理解业务意图"的根因，以及用意图导向编程三步法把隐含规则显式化。 |
需求：实现订单取消功能。
你把这句话丢给 AI，它很快给你交了活：接收 orderId → 查询订单 → 更新状态为 CANCELLED → 调用退款接口 → 发送取消通知。代码完成，测试通过。
看起来很完整。但实际上呢？
| ● ● ● AI不理解业务意图的陷阱 |
| $ 需求：实现订单取消功能 → AI说：我先写取消接口... → 更新订单状态 → 退款 → 发通知 → 代码完成 ✓ 测试通过 ✓ ⚠ 缺少业务约束：已发货/积分/限流/取消原因 $ 问题：只实现动作，没理解业务约束 |
AI 只实现了"取消"这个动作，没有理解"取消"背后的业务约束。
AI 实现的 vs 缺失的
AI 实现的 cancelOrder 接收 orderId | ❌ 缺失的业务规则 ✗ 未检查订单是否已发货 |
四条规则全部缺失，每一条都是真实业务中会碰到的硬问题。AI 只看到了"取消"这个动作，没有理解"取消"在不同场景下意味着什么。
根因：代码模式 ≠ 业务领域
AI 按代码模式思考 写完 CRUD = 完成任务 | 按业务领域思考 每行代码背后有隐含规则 |
你没说"已发货不能取消"，AI 就不知道有这条规则。你没说"要扣回积分"，AI 就假设不需要处理。AI 不是故意忽略这些规则，而是它根本不知道这些规则存在。
正确做法：意图导向编程三步
同样的订单取消需求，换成意图导向编程的思路，操作完全不同。
| ● ● ● 正确做法：意图导向编程三步 |
| $ 第一步：RED — 业务规则测试 测试1：取消未发货订单 → 成功并退款 ✓ 测试2：取消已发货订单 → 拒绝并提示退货 ✓ 现在还一行生产代码 → 测试先红 ✓ $ 第二步：GREEN — 确认意图后实现 和业务方确认：哪些状态能取消 取消后积分怎么处理 要不要记录原因、要不要限流 $ 第三步：REFACTOR — 规则写成断言 把业务规则写成断言或注释 让AI生成代码时必须遵守 ✓ 每一步都先明确业务意图，再生成代码 |
RED | 业务规则测试 不是先写"取消"的代码，而是先把业务规则写成测试：取消未发货订单 → 成功并退款；取消已发货订单 → 拒绝并提示退货。在写代码之前，先把"取消到底意味着什么"定义清楚。 |
GREEN | 确认意图后实现 在实现之前，先和业务方确认三个关键问题：哪些状态的订单能取消？取消后积分怎么处理？要不要记录原因、要不要限流？确认清楚后再写实现，AI 就知道边界在哪。 |
REFACTOR | 规则写成断言 把确认过的业务规则写成代码中的断言或注释，让 AI 在后续生成代码时必须遵守。规则写进代码，就不会被 AI 遗忘或忽略。 |
AI 不会替你思考业务，只会执行你明确的意图
很多人以为 AI 能"理解"你的业务。但实际上，AI 只能理解你用代码或文字明确表达出来的意图。
那些"大家都知道"的隐含规则——已发货不能取消、积分要回滚、批量操作要限流——AI 不知道，因为它不在训练数据里，不在你的提示词里，不在代码模式里。
你必须把隐含规则变成显式规则。用 RED 测试把业务规则写成可验证的断言，用 GREEN 实现之前先确认意图，用 REFACTOR 把规则固化到代码中。
| AI 不会替你思考业务 只会执行你明确的意图 |
你明确的越多，它漏的越少。
12 集实战课程，第 3 集专门讲需求澄清如何把隐含规则显式化，前两集免费。CSDN 搜索「AI 编程实战 Superpowers gstack MattPocockSkills」即可找到。
AI编程 代码质量 TDD 业务建模 程序员效率 开发方法论 Codex AI开发