AI 编程提示词怎么写？10 个实用技巧
同样的 AI 工具，有人能让它写出好用的代码，有人却总得到跑不通的结果，差别常常在提示词上。我带过不少刚上手 AI 编程的人，发现大家踩的坑高度重复：要么一上来就甩一句”帮我写个登录功能”，要么把报错截图往对话框一扔说”这是什么情况”。AI 不是不会写代码，是你没把它当成一个需要交底的新同事对待。下面 10 个技巧，都是我自己天天在用、也反复跟徒弟念叨的，能明显提升 AI 写代码的质量。
10 个实用技巧
-
先给上下文：说明项目用什么技术栈、要解决什么问题。AI 不了解背景就只能猜，给足背景才贴合实际。具体到什么程度算够？至少要包含框架版本（比如 React 18 还是 19、有没有用 App Router）、状态管理方案、这段代码要放在哪个文件、以及项目里已有的相关约定（比如接口统一走
services/下的封装，不能直接fetch）。我见过最典型的翻车案例：项目用的是 Vue 3 组合式 API，AI 却按 Vue 2 选项式写了一堆data()、methods，改起来比重写还费劲。一句”这是 Vue 3 +<script setup>项目”就能避免。 -
一次只说一件事：把大需求拆成小步，逐步推进。任务越聚焦，出错越少，也方便定位问题。比如”做一个用户中心页面”就太大了，拆成”先写获取用户信息的接口调用”→“再写信息展示的组件”→“最后加编辑保存的逻辑”，每一步都能单独验证。拆分的粒度大致是：一次改动能在 5 分钟内跑起来看到结果，就算合适；如果需要改 5 个文件才能看到效果，说明步子迈大了。
-
给输入输出示例：贴一个”给它什么、应该返回什么”的例子。示例比文字描述更能消除歧义。比如要写一个解析日志的函数，与其说”提取时间和错误信息”，不如直接给一行示例日志，再给出你期望的解析结果 JSON。字段名、数组还是对象、时间要不要转成时间戳，全都在示例里讲清楚了，AI 不用猜你脑子里的格式长什么样。这一条对处理边界情况（空值、异常格式）尤其有效，多给 1-2 个”畸形输入”的例子，能省掉后面好几轮返工。
-
明确约束条件：写清不能用什么库、要兼容什么环境、性能要求等。约束讲在前面，省得返工。常见的约束包括：浏览器兼容到哪个版本（比如不能用可选链或者要兼容 IE11，这年头少见但企业内网项目仍存在）、包体积是否敏感（不能引入整个 lodash）、是否要支持服务端渲染（不能用只在浏览器才有的 API）。我吃过的亏是没提前说”这段代码要跑在 Cloudflare Workers 上”，AI 用了 Node 专属的
fs模块，结果部署直接报错，白改了一版。 -
让它先说方案再写代码：要求 AI 先讲思路、列步骤，你确认后再实现。这样能在动手前发现方向错误。具体做法是加一句”先不要写代码，列出你的实现思路和涉及的文件改动，我确认后再继续”。这一步特别适合改动范围不确定的任务，比如”给项目加一套权限校验”，AI 给的方案可能是在中间件层拦截，也可能是在每个接口里手动判断，两种思路成本差很多，提前对齐能少走弯路。
-
要求可运行的完整片段：明确说要能直接跑的完整代码，而不是省略号占位。减少自己拼接出错。AI 有时候图省事，会写”// 其余代码保持不变”或者用
...省略中间部分，看着简洁，实际粘贴回去经常缺了个括号或者漏了个 import。加一句”给出完整文件内容，不要用省略号或注释代替代码”，尤其在改动集中在文件某一小段、但你打算整体替换的时候特别管用。 -
附上报错原文：调试时把完整错误信息贴给它，而不是只说”报错了”。错误原文是定位问题的关键线索。理想情况下要贴三样东西：完整的报错堆栈（不要截断）、触发报错的那段代码、以及你做了什么操作触发的。我见过效率最低的调试方式就是只说”页面白屏了”——AI 只能瞎猜是渲染问题还是接口问题还是路由问题，而一段完整的控制台报错往往一眼能看出是哪个依赖版本不兼容。
-
指定代码风格与命名：说明命名习惯、注释要求、是否要类型标注。统一风格让代码更易维护。比如团队约定组件用 PascalCase、函数用 camelCase、常量全大写加下划线，这些讲清楚了 AI 生成的代码才不用你再手动改名字。TypeScript 项目建议直接说”所有函数参数和返回值都要有类型标注，不要用
any”，不然默认生成的代码类型往往偷懒写得很宽松。 -
让它解释生成的代码：看不懂的地方让 AI 逐段讲清。理解结构后你才改得动、用得放心。这一条不是走过场，是给自己上保险——如果你连 AI 写的正则表达式什么意思都说不清楚，那这段代码上线出了问题你根本没法排查。养成习惯，复杂逻辑生成完直接追问”这一段的边界情况是怎么处理的，有没有可能漏掉的场景”，往往能顺带发现潜在 bug。
-
不满意就具体反馈再迭代：指出”哪一行、想要什么效果”，而不是笼统说”不对”。反馈越具体，迭代越快收敛。比如”第 15 行的循环改成用
map而不是forEach，因为我需要返回新数组”，比”这段代码写得不好，重写一下”要精准得多。模糊反馈换来的往往是另一版同样不对的代码，具体反馈才能真正收敛到你要的结果。
一个组合示例
把多个技巧叠起来效果更好，比如：
我用 Cursor 做一个待办应用（上下文）。请先讲实现思路再写代码（先说方案）。功能：新增一条待办并显示在列表（单一任务）。输入是一段文字，输出是更新后的列表（示例约束）。给我能直接运行的完整代码（可运行）。
再补一个更接近真实场景的组合示例，调试场景下常用这种结构：
项目是 Next.js 14 App Router + TypeScript（上下文）。
app/api/user/route.ts里调用数据库查询时报错，完整堆栈如下：[粘贴报错]（报错原文）。这是相关代码：[粘贴代码]。请先分析可能的原因，列出 2-3 种排查方向，不要直接改代码（先说方案）。
这种”先诊断、后动手”的结构，能避免 AI 一上来就瞎改一通、结果治标不治本。
常见误区
有几个雷区值得单独说一下。第一是提示词写得太长、信息密度却很低，堆了一堆”请帮我认真思考、仔细检查”这类没有信息量的客套话，不如省下篇幅多给一个具体示例。第二是一次性塞进多个不相关的需求，AI 会顾此失彼，某个细节被忽略是常态，不是它偷懒。第三是改代码时不说清”哪些地方不能动”，结果 AI 顺手把你别处写好的逻辑也一起”优化”掉了，这种情况加一句”除了提到的部分，其他代码不要改动”基本能杜绝。
在哪练习
这些技巧在 Cursor、Claude Code 里都能直接用。不同工具的提示词侧重点略有差异：Cursor 里 Chat 模式适合先对齐方案，Composer/Agent 模式适合确认思路后直接批量改文件；Claude Code 更偏命令行工作流，适合把上下文和约束写进项目根目录的配置文件里，让它在整个会话中都记得住，不用每次重复。多练几次”描述—生成—反馈”的循环，手感会越来越好。
想系统掌握提示词与 AI 编程工程方法，欢迎到我们的 AI 编程课 跟着实战练习。