许清风1. 为什么你用AI编程总在返工？问题可能不在AI身上
先说个我自己的真实经历。之前接了一个内部管理系统的数据看板需求，我用AI辅助编程，前后折腾了快一周。第一版生成出来，字段对不上；改完字段，筛选逻辑错了；筛选逻辑修好，导出格式又不对。每一次都感觉AI像个听不懂人话的实习生，你说东它做西。直到后来我停下来仔细复盘，才发现问题压根不在AI身上，而是我描述需求的方式本身就有问题——我一直在用模糊的自然语言跟AI“聊天”，而不是在“提需求”。
这个领悟让我重新审视了AI编程的工作方式。传统编程里，人跟人协作，很多模糊信息可以靠双方的经验和默契自动补全；但AI编程不一样，它没有你的项目背景，不知道你的业务潜规则，更不会主动追问。你给它的输入越模糊，它输出的不确定性就越大，返工自然就不可避免。后来我总结出一套“需求四要素”的描述方法，把每个需求都拆成四个维度去写，实测下来，AI生成代码的一次通过率明显提高，返工率降了大半。这篇文章就把这套方法完整拆开讲，从原理到实操，再到踩坑记录，一次性说清楚。
这套方法适合谁？如果你正在用Cursor、GitHub Copilot、通义灵码这类AI编程工具，或者刚接触AI编程不知道怎么描述需求，又或者你被AI生成的代码反复折磨到怀疑人生，这篇内容都值得你花十分钟看完。毕竟AI编程提示词怎么写，直接决定了你是在“驯服工具”还是在“跟AI互相折磨”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 需求描述的本质：从“聊天式需求”到“契约式需求”
2.1 AI编程与传统编程对需求的理解方式完全不同
先搞清楚一个底层问题：AI编程和传统编程，对需求的理解路径有本质区别。
传统开发中，你写需求文档给产品经理，产品经理转成PRD给开发，开发有问题会主动问你。这个链条里，每个环节都有“人”在兜底——不懂的会问，有歧义的会确认，信息缺口会被主动补上。但AI编程是另一回事。你输入一段提示词，模型基于训练数据里的模式来预测“最可能正确的代码”。它不会觉得你的需求有歧义，因为对它来说，任何输入都能生成一个“看起来合理”的输出。问题在于，这个“看起来合理”是基于它见过的通用模式，而不是你的业务场景。
举个最典型的例子：你说“帮我写一个用户列表页面”。在人的眼里，这意味着列表展示、分页、搜索、状态标识，可能还要有操作按钮。但在AI的“理解”里，它可以生成一个纯静态表格，没有任何交互，因为它觉得这就是“用户列表页面”最基础的形态。你说它错了吗？严格来说也不算错，只是这不是你想要的。这种“不算错但不对”的输出，就是返工的第一大来源。
所以，AI编程提示词的核心原则是：把AI当成一个能力很强但完全不了解背景的远程同事。你不能只告诉它“要什么”，还要告诉它“边界是什么”“规则是什么”“怎么算做完”。这就是从“聊天式需求”向“契约式需求”的转变——把模糊的意图变成可验证的条款。
2.2 返工率高的根因：信息缺口在AI这里不会被自动补全
我复盘了那段时间的所有返工案例，发现几乎每一次返工都能归因到同一个点：需求里的关键信息缺失，但AI不会主动来问。
具体来说，信息缺口主要集中在三类：
- 业务规则缺失。比如“订单金额超过一定额度需要特殊审批”，你没有说“一定额度是多少”“特殊审批是审批什么”，AI只能自己猜，猜错就是返工。
- 边界条件缺失。比如输入框允许输入什么格式？字段长度上限是多少？空值怎么处理？这些你没说，AI就按它认为的“通用做法”来，而通用做法往往跟你的实际场景不匹配。
- 验收标准缺失。你只说“实现一个导出功能”，但没说导出的字段有哪些、格式是什么、文件名怎么命名、大数