提示词即需求文档：让 AI 编程一次通过的 7 个实战技巧

用 AI 写代码大半年，我最大的体会是：AI 编程拼的不是模型有多强，而是你的提示词有多像一份合格的需求文档。同样的模型，有人一次通过，有人改十轮还跑不起来，差距几乎全在输入端。下面 7 个技巧，是我从真实项目里总结出来的，条条都经过返工的毒打。

1. 先写“验收标准”，再写需求

人类程序员接需求时最怕什么？怕“大概、差不多、你看着办”。AI 也一样。好的提示词应该像一份迷你需求文档，开头就写清楚“做完长什么样算对”。

反例：“写个登录接口。”
正例：“写一个 POST /api/login 接口。输入 {username, password}；成功返回 {token, expiresIn}；用户名不存在返回 401 + 错误码 USER_NOT_FOUND；密码错误 5 次后锁定 15 分钟。”

验收标准越具体，AI 自由发挥的空间就越小，一次通过的概率就越高。

2. 给上下文要“最小可用”，不要“整库倾倒”

很多人为了“让 AI 看懂”，把整个仓库贴进对话框。结果上下文爆了，AI 反而抓不住重点，token 也哗哗地烧。正确姿势是最小可用上下文：只给与任务直接相关的部分。

• 改 bug：给报错堆栈 + 出问题的函数，不要给整个模块；
• 加功能：给接口定义 + 调用示例，不要给实现细节；
• 重构：给被重构函数的签名和测试用例，让 AI 自己按需索取。

大多数 AI 编程工具支持 @文件 引用和按需读取，善用它们，而不是手动复制粘贴。

3. 约束前置：先说“不要什么”

AI 的默认行为是“多做一点显得能干”：你让它修一个 bug，它顺手重构了三个文件；你让它写个工具函数，它附赠一套它自创的框架。约束必须写在需求前面，而不是事后补救。

我现在的固定约束模板是：“只修改 X 文件，不要动其他文件；不要引入新依赖；保持现有代码风格；不确定的地方先问我，不要自己假设。”

这四句话，能过滤掉 80% 的“好心办坏事”。

4. 指定输出格式：diff 优先，拒绝长篇大论

默认情况下 AI 喜欢先讲五分钟原理再给代码，解释部分经常占掉一半以上的输出 token。直接规定格式：“只输出修改部分，用 unified diff 格式；不要解释，直接给代码；如果改动超过 3 个文件，先列出改动清单等我确认。”

需要学习原理时再让它展开。输出格式是提示词里性价比最高的半句话。

5. 拆小步：一次只让 AI 做一件事

“帮我把这个单体应用拆成微服务”这种巨型任务，一次性扔给 AI 几乎注定翻车——上下文不够、中间状态丢失、错误层层放大。正确做法是拆成 AI 能一次吃完的小步：

1. 先让 AI 分析模块边界，输出拆分方案（只分析不动手）；
2. 确认方案后，一次只拆一个模块；
3. 每步结束都让 AI 跑一遍测试，绿了再走下一步。

人做架构决策，AI 做机械执行，这是目前最稳的人机分工。

6. 让 AI 先复述理解，再动手

对于复杂任务，我习惯加一句：“开始写代码之前，先用 3-5 条 bullet points 复述你对需求的理解，等我确认后再动手。”

这一步极其关键。它把“我以为你懂了”的误解提前暴露，纠正理解偏差的成本，远低于纠正写错代码的成本。实测下来，加了复述环节的任务，返工率下降一半以上。

7. 沉淀为模板：把常用约束写进项目级提示词

第 3 条的约束、第 4 条的格式要求，每个项目都大同小异。与其每次重复，不如沉淀成项目级的提示词文件（如 AGENTS.md / 项目规范文档），放在仓库根目录，让 AI 每次自动读取。

我的项目模板里固定包含：技术栈版本、代码风格（命名/注释/错误处理）、禁止事项（不引入新依赖、不改动某目录）、测试要求。写一次，永久复用——这是提示词工程里回报率最高的投资。

结语

把 AI 当成一个执行力极强、但需要你把话说清楚的初级工程师：需求越像需求文档，它交付得越好。从今天起，试试在每次提问前多花 2 分钟写清验收标准和约束，你会发现 AI 突然“变聪明了”——其实变聪明的，是你的提问方式。