AI 编程的分水岭：业务知识决定交付质量

“做一个订单取消功能。”

Agent 生成按钮、接口、数据库修改和测试。页面显示“取消成功”，功能展示结束。业务负责人提出一个问题：这笔订单的退款在哪里？

这是一个示意场景。按钮表达一个动作，订单取消涉及一组业务决定。代码生成解决实现问题，业务知识决定实现的目标。

AI 编程的能力差距包含这种区别：有人提供一句功能名称，有人提供状态边界、异常处理和验收条件。两者使用相同工具，交付面对不同的不确定性。

提示词表达需求，领域知识决定需求包含什么。

一个功能名称，遗漏一组决定

订单取消的第一个问题是状态。待付款、付款完成、仓库备货和发货完成，代表不同的处理条件。每种状态的取消权限需要业务确认。“取消”这个词缺少这些答案。

第二个问题是权责。订单的购买者、客服和商家承担不同角色。系统需要区分操作者身份与操作权限。按钮的显示规则、接口的权限检查与审计记录属于不同检查对象。

第三个问题是结果。取消涉及库存占用、优惠权益和款项。订单状态的修改与款项退回属于不同事件。退款请求提交成功、退款处理中与退款完成，需要各自的状态和用户提示。

第四个问题是冲突。用户提交取消请求，仓库提交发货请求，两个动作争夺同一订单的状态。业务规则需要规定状态转换的有效条件，系统实现需要保护这个条件。

这些问题构成需求的内容。技术术语与业务决定属于不同内容。提示词包含“事务、幂等、补偿、可观测性”，具体实现需要回答它们保护哪条业务承诺。

图：订单取消的决策示意，非通用业务规则。权限和状态边界需要项目负责人确认。

“重复取消”提供一个例子。相同业务动作的重复请求需要识别机制，库存释放、权益返还和退款需要各自的去重约束。网络重试与业务重做具有不同含义。

“退款超时”提供另一个例子。超时表示调用方缺少结果，退款的实际状态需要查询或事件确认。一次新的退款请求涉及重复处理风险。错误日志、业务状态和恢复动作需要对应关系。

本地数据库事务保护本地写入。远程退款服务执行独立操作。本地回滚与远程退款撤销属于两种能力。跨系统流程需要明确的状态记录、结果核对和恢复策略。

这些细节体现业务知识的价值。它让功能名称变成一组可审查的决定，缩小规则的猜测空间。

提示词清楚，取决于答案的清楚

“资深架构师”“最佳实践”“高质量代码”，表达的是质量愿望。愿望缺少裁决标准。

一份有用的需求包含具体答案：谁有权限，哪些状态接受操作，哪些结果属于成功，哪些失败需要人工处理。它包含明确的范围：本次功能包含什么，范围之外的能力是什么。

表达方式具有价值。清晰的结构帮助模型读取规则，示例帮助模型理解边界，仓库中的文档保存团队约定。表达方式与业务知识承担不同工作。

一个条件完整、措辞普通的需求，提供了实现方向。一个措辞漂亮、边界缺失的需求，留下了判断空白。模型生成的代码填充这个空白，填入的是模型的解释。

提示词长度缺少质量担保。重复背景增加阅读成本，冲突要求增加选择成本。需求的价值包含有效信息密度，以及团队对这些信息的确认。

“退款完成”是一个词，“用户的退款状态是什么、状态改变需要哪份证据、查询失败需要什么处理结果”是一组问题。领域知识帮助人发现问题，沟通帮助人确定答案。

原型展示与生产交付，面对不同的验收

原型需要验证核心想法：界面、流程和用户反馈。局部模拟降低展示成本，帮助团队讨论产品方向。

生产系统承担真实的状态变化。重复请求、错误输入、外部服务中断和权限越界，构成交付的检查范围。用户损失与恢复成本决定审查力度。

这一区分影响 AI 编程的评价。页面展示成功，说明展示路径成立。真实业务交付需要检查数据与用户结果。订单页面显示取消，退款记录的状态是待处理，这两个结果需要解释。

模型能力、仓库质量和工具环境影响交付质量。领域知识缺失是一个风险因素，故障归因需要具体证据。“结果差说明使用者水平低”缺少判断依据。权限配置错误、依赖变化和模型理解错误，具有各自的修复方向。

有经验的人擅长识别省略项。他们检查成功页面的关联记录，收集失败请求的证据。AI 接管部分实现工作，这种检查能力成为交付的一部分。

陌生领域需要一份学习清单

领域知识与职业标签属于两个维度。产品人员熟悉用户流程，运营人员熟悉结算口径，客服熟悉异常处理。他们掌握的业务经验具有实现价值。

陌生领域的工作需要明确知识缺口。一个退款功能涉及金额口径、状态、权限和失败恢复；一个内容编辑器涉及输入、保存、撤销与数据兼容。功能名称之外的概念需要学习。

AI 适合承担解释与问题展开。学习请求包含“概念是什么”“哪些状态具有混淆风险”“哪些约束需要业务确认”“什么例子说明规则”。模型的回答构成候选知识，官方文档、可运行示例与领域负责人的确认提供核对依据。

模型的解释包含误差风险。一个逻辑连贯、缺少真实接口或业务规则支持的流程，是一份待核查方案。学习过程需要证据，执行过程需要验收，两者共享这项要求。

图：学习与交付的流程建议，效果需要项目实践验证。失败结果触发规则与实现的复核。

1. 列出知识缺口。模型解释概念、典型失败和隐藏约束，任务负责人记录理解空白。

2. 确认业务决定。相关负责人确认状态边界、权限、成功条件与功能范围。存在争议的规则保留待决标记。

3. 实现小范围路径。一个可检查的用户流程承担验证任务，候选方案接受代码、文档和运行结果的核对。

4. 检查用户结果。验收记录包含输入、输出、数据变化与失败表现。偏差触发业务理解或实现方案的修改。

这套方法的目标是减少认知偏差造成的返工。它需要实际例子和反馈，篇幅庞大的计划缺少替代作用。

一份交付，需要有人解释每个结果

订单取消的验收有一组具体问题：允许取消的订单发生预期变化，受限状态保留原状；重复请求保持结果一致；退款失败保存真实状态；操作者权限受到检查。

这些问题生成测试用例，测试用例保存业务承诺。Agent 负责测试代码的编写与执行，业务负责人确认预期值。测试结果全绿意味着受测行为符合断言，断言的判断依据需要审查。

交付质量的判断需要用户结果。生成代码行数、工具调用次数与消耗量，描述执行规模。需求完成、故障处理与结果可解释性，描述交付质量。两类指标具有不同用途。

一份可靠的交付要求负责人解释成功与失败：成功对应哪条需求，失败留下哪份记录，修复保护哪种行为。业务知识承担这些解释的基础。

AI 生成实现，人的责任包含定义与确认规则。代码的生产成本下降，需求中的每个空白需要一个有依据的答案。