AI编程时提示词咋写？

提示词的核心不是“写得像咒语”，而是**把上下文、约束和验收标准一次性说清**。你给 AI 的每一条信息，都是在帮它缩小“猜测空间”——写提示词的本质是“写需求文档”，不是“写命令”。下面这套方法，是我在 Cursor、Copilot、通义灵码 等工具上反复试错后沉淀下来的，分场景、带模板、可直接抄。

一、先搞懂：AI 编程工具到底“吃”什么

目前主流的 AI 编程助手（如 Cursor、GitHub Copilot、通义灵码、JetBrains AI）本质上是一个“**超强 autocomplete + 代码解释器**”。它们不是真的“理解”业务，而是根据你给的上下文（当前文件、选中代码、对话历史）去预测最可能的下一段代码。因此，提示词要解决三个问题：

• 它知道你在哪吗？——需要你主动贴出相关文件路径、函数名、报错堆栈。
• 它知道你要什么吗？——需要明确输入、输出、边界条件。
• 它知道“好”的标准吗？——需要你定义风格、性能、兼容性要求。

很多人失败是因为把 AI 当成了“搜索引擎”，问“怎么写一个登录功能”，但 AI 只能给你一个泛泛的示例——因为它不知道你的框架是 Vue 还是 React，不知道你的用户表结构，不知道你要不要验证码。所以，第一条铁律是：把 AI 当成一个刚入职、能力强但完全不了解项目的实习生。

二、通用公式：四层结构 + 三个必填项

我总结的万能提示词模板（适用于任何 AI 编程工具）：

【角色】你是一个精通 [语言/框架] 的资深工程师。
【任务】我需要你 [具体功能描述]，例如“实现一个带防抖的搜索框”。
【约束】要求：[技术栈] / [不允许用什么] / [性能要求] / [兼容性]。
【验收】请输出 [完整代码 / diff / 解释]，并说明 [关键逻辑]。

但仅有框架不够，下面三个“必填项”才是信息增量所在：

1. 上下文锚点：直接粘贴相关代码片段（而不是说“看我的代码”），并标注文件路径。比如：“在 src/utils/format.ts 中，我已有 formatDate 函数，如下…”。
2. 反例或边界：告诉它“不要做什么”。例如：“不要使用 any 类型”、“不要修改原有的错误处理逻辑”、“如果输入为空字符串，返回 null 而不是抛异常”。
3. 可验证的完成标准：说清“怎么算写完”。例如：“请给出单测用例，覆盖空值、超长字符串、emoji 三种情况”或“代码需要能通过 eslint 严格模式”。

三、分场景实战模板（直接复制改）

场景 1：写一个新函数/组件

❌ 错误：“帮我写个防抖函数”

✅ 正确：

请用 TypeScript 实现一个防抖函数 debounce。
要求：
1. 泛型支持，保留原函数 this 上下文。
2. 提供 cancel 方法取消未执行的调用。
3. 默认等待时间 300ms，支持 immediate 参数（立即执行一次）。
4. 禁止使用 lodash 等库。
5. 附带 3 个单元测试用例（用 vitest 语法）。
我的现有代码风格：使用 const 箭头函数，注释用中文。

这里的关键是：给出了“泛型”、“this 上下文”、“cancel 方法”、“immediate”这些专业约束，AI 就不会给你一个 5 行的玩具版，而会给出工程化实现。

场景 2：修改/重构现有代码

❌ 错误：“这段代码太乱了，帮我优化”

✅ 正确：

下面这段函数（粘贴代码）存在两个问题：1. 嵌套过深；2. 重复的 try-catch。
请重构为：使用 early return 降低复杂度；提取公共错误处理逻辑。
要求：保持对外行为完全一致，不要改变函数签名。
重构后请用 diff 格式输出，并简述每处改动的原因。

“保持对外行为一致”是重构类提示词的生命线。否则 AI 会“好心”帮你改掉 bug，但你的测试用例会挂。

场景 3：调试报错

❌ 错误：“报错了，帮我看看”

✅ 正确：

我在运行 Next.js 项目时遇到以下报错（粘贴完整堆栈）。
我的页面组件是（粘贴关键代码），数据获取逻辑是（粘贴代码）。
我怀疑是 [SSR 时 window 未定义] 导致的，但不确定。
请帮我定位根因，并给出两种修复方案：一种快速 hack，一种符合最佳实践。
请先解释报错原因，再给代码。

注意：先贴报错，再贴代码，最后给猜测。AI 会优先基于你的猜测去验证，而不是漫无目的地扫描。

场景 4：生成测试用例

❌ 错误：“给这个函数写测试”

✅ 正确：

针对下面这个函数（粘贴代码），请用 Jest 编写单元测试。
需要覆盖：
- 正常输入（包含边界值：0、负数、极大数）
- 错误输入（null、undefined、NaN）
- 异步场景（如果函数返回 Promise）
- 每个用例命名用“should_xxx_when_xxx”格式。
请输出测试文件完整代码，并在注释中标注每个用例覆盖的分支。

这里的高价值点是：让 AI 标注“覆盖的分支”，你能一眼看出漏测了哪些逻辑。

四、进阶技巧：让 AI 更“懂”你的项目

如果你用 Cursor 或 Copilot Chat，不要每次对话都从零开始。建议在项目根目录建一个 AGENTS.md 或 CLAUDE.md 文件（Cursor 会自动读取），里面写清楚：

• 项目技术栈（Next.js 14 + TypeScript + Tailwind）
• 目录结构说明（src/components 放 UI，src/lib 放工具函数）
• 代码风格（函数组件、Hooks 优先、避免使用 any）
• 常用命令（npm run dev / lint / test）

这样，你每次提问时，AI 会自动参考这些全局规则，你就不用重复写了。实测：有全局规则文件后，生成代码的风格一致性提升 70% 以上。

五、关于工具选择的补充

不同的工具对提示词的敏感度略有不同：

另外提一句：如果你是在 ChatGPT 或 Claude 这类通用对话模型里问代码，一定要明确“请用 Python 3.10 + type hints”或“请用 Node.js 18 + ESM”，否则它会给你 2018 年的老写法。

六、最后一条“反直觉”建议

不要试图一次写一个“完美提示词”。AI 编程是迭代对话，不是一次性问答。我通常的做法是：第一轮给 60% 的信息，拿到初版代码后，第二轮直接说“这里改成 xxx，那里加个 yyy 参数”。这比花 10 分钟憋一个 500 字提示词更高效。因为 AI 在对话中会记住上文，你后续的短指令（“把那个 for 循环改成 map”）反而比长提示词更精准。

如果遇到 AI 反复给出错误代码，别急着改提示词——先检查是不是你的“验收标准”没说清。比如你没说“禁止使用全局变量”，它就会给你一个污染作用域的版本。绝大多数“AI 不听话”的案例，都是因为人类少给了一个“不”字。

相关问题

• AI 编程工具会取代程序员吗？——短期内不会，但会取代“只会搬砖”的程序员。掌握提示词的人效率提升 3 倍以上，反而更难被替代。
• 为什么 AI 生成的代码有时候有安全漏洞？——因为训练数据里包含大量旧代码。建议在提示词里加一句“使用 OWASP 最新标准”，并让 AI 解释它的安全假设。
• 如何让 AI 理解我的私有 API 或内部组件？——把接口文档或类型定义粘贴进对话，或者用 Cursor 的“Codebase”功能让它索引整个仓库。
• 提示词写多长合适？——没有固定标准。但建议单次不超过 200 字，超过就拆成多轮对话。长提示词容易让 AI 忽略关键约束。
• 有没有必要学习 Prompt Engineering 课程？——没必要专门学，但值得花一小时读 Cursor 官方文档。编程提示词的核心只有“上下文 + 约束 + 验收”，其他都是包装。