让 AI 帮你写代码？先学会跟它说话

最近半年，我的日常开发里有一个越来越明显的变化：写代码的时间在缩短，写提示词的时间在变长。

不是因为我变懒了。而是我发现，给 AI 一个好的提示词，它能在 30 秒内交付一个我需要花 20 分钟才能写完的模块；但如果提示词写得含糊，AI 给你的代码就像实习生第一天的作品------能跑，但你不敢用。

所以这篇文章不聊"AI 会不会取代程序员"这种大话题，就聊一个具体的事：怎么写提示词，才能让 AI 写出你真正能用的代码。

一、先搞清楚一件事：提示词不是"聊天"

很多人用 AI 写代码的姿势是这样的：

"帮我写一个登录页面"

然后 AI 给你一坨 HTML + CSS + JS，样式是 2018 年的，逻辑是"直接把密码明文发给后端"那种。你看了一眼就关掉了。

问题出在哪？不是 AI 不行，是你给的信息太少。

你想想，如果你跟一个新来的同事说"帮我写个登录页面"，他大概率也会问你一堆问题：用什么框架？有设计稿吗？要不要记住密码？后端接口长什么样？

AI 不会问你。它只会"猜"。

所以第一条原则是：提示词不是聊天，它是一份简洁但完整的需求文档。

二、一个好提示词的五根骨头

根据我自己踩坑和反复调试的经验，一个靠谱的提示词，骨架上需要五样东西：

1. 角色（Task/Role）

告诉 AI 它是谁。这不是玩 cosplay，而是帮它锁定"用什么知识库来回答你"。

比较：

弱："帮我写个网络请求封装"
强："你是一个有 5 年 iOS 开发经验的工程师，熟悉 Swift Concurrency 和 URLSession，请帮我封装一个网络请求层"

加了角色之后，AI 的输出会明显"对味"------它知道该用 async/await 还是回调，该不该引入第三方库。

2. 上下文（Context/Content）

把 AI 需要的原始数据喂给它。代码片段、API 文档、错误日志、数据结构定义......你给得越精确，它猜得越少。

我的习惯是：直接把相关代码贴进去，而不是用自然语言描述代码。

"我有一个 User 模型，里面有 name、email、avatar 字段"------不如直接把 struct 贴过去。AI 读代码比读你的描述准确得多。

3. 指令（Instructions）

分步骤告诉它你要什么。这里有个反直觉的经验：你写得越像步骤说明书，AI 的输出质量越高。

比如：

请按以下步骤实现：

定义一个 NetworkError 枚举，包含 timeout、unauthorized、serverError 三种 case

封装一个泛型请求方法，入参是 URL 和请求体，返回值是 Result<T, NetworkError>

在请求方法内部处理 HTTP 状态码映射

加上请求超时 15 秒的配置

这比"帮我封装一个网络请求"好十倍。

4. 示例（Examples）

这是很多人会忽略的杀手锏。给 AI 一个输入输出的例子，效果堪比手动调参。

如果你希望 AI 生成的代码风格跟你项目一致，最好的办法就是贴一段你项目里已有的代码，告诉它："请参考这个风格来写。"

Few-shot learning 听起来是个学术名词，其实就是"别光说，给它看"。

5. 约束（Constraints）

告诉 AI 什么不能做、什么格式必须遵守。这是控制输出质量的最后一道闸门。

常见的约束包括：

"不要使用任何第三方库"
"所有方法必须加上注释"
"返回的 JSON 必须符合以下 schema"
"不要省略 error handling"
"代码中不要包含中文注释"

我个人最常用的一条："不要省略任何实现细节，不要用 // ... 占位"。因为 AI 特别喜欢在关键逻辑处偷懒。

三、进阶：十个维度把提示词武装到牙齿

如果上面五根骨头是"能用"，下面这十个维度就是"好用"。这是我从实践中总结出来的一套全景清单，写复杂提示词的时候我会逐项过一遍。

1. 任务背景

一两句话说清楚你在做什么项目、解决什么问题。别让 AI 在真空里写代码。

2. 语气/风格

你想要"严谨的生产代码"还是"快速验证的原型"？AI 会根据这个调节代码的详细程度和防御性编程的力度。

3. 背景数据

把该喂的都喂进去：代码文件、接口文档、截图、错误堆栈。信息不够的时候，AI 只能靠想象力填空------而 AI 的想象力，就是你的 bug。

4. 详细任务描述与规则

这是提示词的"主体"。越具体越好，越结构化越好。用编号列表、用层级缩进，别写大段自然语言。

5. 示例

前面说了，这是杀手锏。尤其是当你需要特定的输出格式或代码风格时，一个例子胜过千言万语。

6. 对话历史

如果你是在多轮对话中迭代，注意 AI 的上下文窗口。关键信息如果在很早之前的对话里，重新提一遍。别指望 AI 的"记忆力"。

7. 即时任务请求

在一个长提示词里，把"你现在要做的事"放在最后，而且要醒目。AI 对"最后出现的指令"权重更高。

8. 逐步思考（Chain-of-Thought）

在提示词里加一句"请逐步思考"或者"Think step by step"，对复杂逻辑问题有肉眼可见的效果。

这听起来像玄学，但它确实有效。原理也不复杂：你让 AI 把中间推理步骤写出来，它就不容易跳步犯错。就像你让一个人"心算 347 × 28"和"在纸上算 347 × 28"，后者准确率高得多。

9. 输出格式

明确告诉 AI 你要什么格式：纯代码？Markdown？JSON？带注释还是不带？一个文件还是多个文件？

我的经验：如果你不指定格式，AI 会按自己的心情来。而它的心情，不太稳定。

10. 预填回复（Prefill）

一些 AI API（比如 Claude）支持在 assistant 消息里预填内容。这个技巧在代码生成场景下特别好用------你可以预填 \``swift\n` 来强制它直接输出代码，省掉前面那段"好的，我来帮你实现......"的废话。

四、实战模板：我自己常用的提示词结构

说了这么多方法论，不如直接看一个我日常用的模板框架：

ini 复制代码

## 角色
你是一个资深 [语言/平台] 工程师，擅长 [具体领域]。

## 背景
我正在开发 [项目简述]，当前需要实现 [功能简述]。

## 相关代码/数据
[直接贴代码、接口定义、数据结构]

## 任务
请按以下步骤实现：
1. [步骤一]
2. [步骤二]
3. [步骤三]

## 约束
- [约束一]
- [约束二]
- [约束三]

## 输出要求
- 输出完整可运行的代码
- 不要省略任何实现
- [其他格式要求]

这个模板不是死的。简单任务我会砍掉一半，复杂任务我会加上示例和对话历史的引用。但这个骨架帮我省了很多"反复调试提示词"的时间。

五、最后说两句大实话

提示词工程不是银弹。 它能把 AI 的输出从 60 分拉到 85 分，但最后那 15 分------架构判断、边界 case、性能调优------还是得你自己来。AI 是你的副驾驶，不是你的替身。
写好提示词的最佳练习，就是多写代码。 这听起来像废话，但事实就是：你对目标代码的理解越深，你越知道该在提示词里写什么、不写什么。一个不懂网络编程的人，写不出让 AI 生成高质量网络层的提示词。
别追求一次完美。 好的提示词往往是迭代出来的。第一版给 AI，看它哪里理解错了，然后补充约束、加上示例、调整措辞。这个过程本身就是在跟 AI "对齐认知"。跟带新人一个道理：第一次没说清楚很正常，重要的是你能快速定位到"哪句话让它理解偏了"。

写到这里我突然想到一个挺有意思的事：写好提示词需要的能力------清晰表达需求、结构化思维、预判边界条件------其实就是写好技术文档和写好代码需要的能力。

工具在变，底层能力没变。