对话式编程：意图-约束-验收三元组

一句话定义

对话式编程的可靠表达结构是三元组——意图（做什么、为什么）、约束（技术栈、风格、禁区）、验收（怎样算完成），三要素齐全才能稳定获得可用产出。

为什么重要

对话层的产出质量主要取决于你给的结构化程度。新手最常见的失败不是模型能力不足，而是任务表达残缺：只说「优化这段代码」或「帮我做个导出」，把本应人给的信息留给模型去猜，再花数轮纠正。三元组把「需求表达」变成可检查的清单，一次说全，把往返成本压到最低——这是所有对话式工作流（kp-011 spec 驱动是它的完整形态）的基础结构。

前置知识

kp-001（AI 辅助编程的版图与核心术语）。

核心概念

• 意图（Intent）：要达成的用户可见结果与背后的动机。「让管理员能导出上个月订单为 CSV，供财务对账」——动机决定无数隐含决策（字段、格式、权限）。
• 约束（Constraint）：硬性边界。技术栈与版本、代码风格、不许改动的模块、性能预算、依赖政策。约束缺失时模型会用「通用最佳实践」填空，常与你的项目冲突。
• 验收（Acceptance）：可判定的完成标准。测试通过、指定输入得到指定输出、性能指标、手工验证路径。「可判定」是关键：「写得干净点」不可判定，「通过 test_export.py 全部用例」可判定。

三者缺一时的典型症状：缺意图 → 实现方向漂移；缺约束 → 风格冲突与越界改动；缺验收 → 「看起来对」但不敢合并。

原理与机制

模型是条件生成器：输出是对「已给信息」的条件补全。三元组本质是把「人类工程师会问你的问题」前置回答掉——一个资深同事接到任务也会问「为谁做、有什么限制、怎么验收」。信息前置把模型的不确定性空间压缩到任务本身，往返轮次从「试错式」降为「澄清式」。这也是 kp-004 注意力预算的应用：三元组占用的 token 很少，换取的确定性极高，性价比最好。

实例或案例

Before（残缺表达）：

帮我优化一下这个导出功能。

After（三元组齐全）：

意图：管理员导出上月订单 CSV，供财务对账。
约束：Python 3.11 + FastAPI 现有结构；复用 services/export.py 的流式写出；
     不改数据库模型；禁止引入新依赖。
验收：新增 test_export_monthly.py 覆盖：空月、10 万行、含退款单三种情况，
     全部通过；接口响应时间 P95 < 2s。

操作步骤：

1. 发任务前用三元组自检：三句各能说清吗？说不清的先自己想清楚或查代码。
2. 把约束中「不许动的部分」显式写出——这是模型最需要而人最常省略的。
3. 验收尽量给测试名或可运行命令，而不是形容词。

排错清单（回答跑偏时的纠偏顺序）：

1. 是方向错了 → 补意图，重述用户可见结果。
2. 是越界了 → 补约束，点名禁区文件/模块。
3. 是「差不多但不对」 → 补验收，给出反例输入与期望输出。
4. 连续两轮没纠回来 → 停止追问，拆小任务（见 kp-010）。
5. 已有长对话 → 考虑重开会话并带摘要（见 kp-009）。

公式或模型

本节不适用：三元组是表达结构不是量化模型。

图示

意图（为什么） ──┐
约束（不许什么）─┼──→ 模型 ──→ 产出 ──→ 验收（怎么算对）──→ 迭代
               ┘
缺任一角 → 三角形立不住：方向漂移 / 风格冲突 / 不敢合并

直观类比

三元组像点菜的三要素：吃什么（意图）、忌口与做法（约束）、怎么算上对了（验收）。只说「来点好吃的」，厨师只能碰运气。

常见误区

• 一次对话塞多个独立需求：模型会混淆优先级，逐个任务发起。
• 把「验收」写成态度词（优雅、健壮）：必须翻译成测试或可运行检查。
• 只在结果不满意时才补信息：先给全比后补救便宜得多。

与其他知识点的关系

kp-007 把三元组固化为三类场景模板；kp-011 的 spec 驱动开发是三元组的完整工程化形态。

自测题

要点：模型用通用最佳实践填空，产出与项目技术栈/风格冲突，或改动了不该动的模块。

要点：不可判定的标准无法驱动迭代收敛，也无法在合并前给出客观通过信号。

1. 三元组缺「约束」时的典型症状是什么？
2. 为什么验收必须「可判定」？

延伸阅读

《Thinking- Fast and Slow》Daniel Kahneman——「先定义问题再求解」的认知学依据（本节不适用为：其内容非编程技法，仅作思维背景）。