你让 AI 实现订单取消功能它写了取消接口、更新状态、调用退款、发送通知代码完成测试通过。但上线后你才发现没检查是否已发货、没处理积分回滚、没做批量限流、没记录取消原因。本文拆解 AI 只看到动作不理解业务意图的根因以及用意图导向编程三步法把隐含规则显式化。需求实现订单取消功能。你把这句话丢给 AI它很快给你交了活接收 orderId → 查询订单 → 更新状态为 CANCELLED → 调用退款接口 → 发送取消通知。代码完成测试通过。看起来很完整。但实际上呢● ● ● AI不理解业务意图的陷阱$ 需求实现订单取消功能→ AI说我先写取消接口...→ 更新订单状态 → 退款 → 发通知→ 代码完成 ✓ 测试通过 ✓⚠ 缺少业务约束已发货/积分/限流/取消原因$ 问题只实现动作没理解业务约束AI 只实现了取消这个动作没有理解取消背后的业务约束。AI 实现的 vs 缺失的AI 实现的 cancelOrder接收 orderId查询订单更新状态为 CANCELLED调用退款接口发送取消通知→ 看起来很完整❌ 缺失的业务规则✗ 未检查订单是否已发货✗ 未处理会员积分回滚✗ 未做批量取消限流✗ 未记录取消原因→ 只看动作不看约束四条规则全部缺失每一条都是真实业务中会碰到的硬问题。AI 只看到了取消这个动作没有理解取消在不同场景下意味着什么。根因代码模式 ≠ 业务领域AI 按代码模式思考写完 CRUD 完成任务隐含规则不可见谁能操作什么时候能操作操作后有什么连锁反应→ 边界模糊→ 修复成本极高按业务领域思考每行代码背后有隐含规则在老员工脑子里在历史 bug 记录里在用户抱怨里→ AI 看不到这些→ 只能看到明确说出的部分你没说已发货不能取消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开发