从提示词到可复核的交付：给 AI 编码助手立一份最小工作规约

很多人把 AI 编码助手当成更快的打字员，提示词写得越长越好，结果却常常是：代码看起来能跑，边界条件没人说得清，改一处又冒出两处问题。问题不在模型，而在缺少一份最小工作规约：你没有先把目标、约束和验收标准讲清楚，助手只能凭猜测补全空白，而猜测正是返工的来源。

一份可用的规约不需要写成制度文档，四条就够。第一是任务边界：这次只改什么、不改什么，涉及哪些模块和接口，哪些行为明确不在范围内。第二是输入与约束：数据从哪里来、格式是什么、性能和兼容性有没有硬性要求、不能引入哪些依赖。第三是输出形式：要函数还是接口、错误怎么返回、日志和注释要到什么程度。第四是验收方式：用哪些用例验证、什么算通过、什么算失败。把这四条写在提示词前面，助手的工作就从自由发挥变成了按图施工。

举一个常见的例子。假如你要让助手给一个订单列表加筛选功能，模糊的说法是“加个筛选，好用一点”。更好的说法是：只在列表查询层加状态和时间两个筛选条件，不改分页逻辑；状态取值为待支付、已支付、已取消，时间按创建时间区间过滤；接口返回保持原有字段不变，异常时返回统一错误码；验收时覆盖无条件、单条件、组合条件和空结果四种情况。同样是几句话，第二种说法把容易扯皮的地方提前钉死了，审查代码时也有据可依。

规约的价值还体现在复核环节。收到代码后，不要只看它能不能跑，要按规约逐条核对：边界有没有越界、约束有没有被绕过、输出格式有没有走样、验收用例有没有真的跑通。更重要的是看那些没有写进代码的假设：助手默认了什么输入一定合法？默认了什么异常不会发生？这些假设一旦与真实业务不符，就是线上故障的候选。把假设找出来，要么补到规约里，要么补到测试里，不要留在脑子里。

还有一条容易被忽略的原则：一次只做一件事。把重构、加功能、修样式混在一个提示词里，助手很难同时保证三件事都对，出了问题也难以定位。正确的做法是拆成小步：先让助手实现最小可用版本并通过验收，再谈优化和扩展。每一步都保留可回滚的改动，这样即使某一步走偏，也只需要回退一步，而不是重写整个功能。

最后，规约不是写给助手一个人的，也是写给未来的自己和同事的。下周再看这段代码时，如果能从提示词和注释里还原当初的取舍，就说明这份规约是合格的。工具会不断变强，但把需求讲清楚、把结果验明白，始终是开发者的基本功。先花五分钟立规约，往往能省下半小时返工。