在过去的半年里我的工作流发生了一个微妙却深刻的变化：键盘敲击代码的时间在肉眼可见地减少，而在对话框里打磨指令的时间却在直线上升。这并不是说我变懒了而是我意识到一个残酷的现实：给AI一个精准的指令，它Neng在几秒钟内交付一个我需要花半小时才Neng写完的模块；但Ru果指令含糊不清，它吐出来的代码就像刚入职第一天的实习生写的——Neng跑，但你绝对不敢把它合并到主分支里。

所以今天我们不想聊那些虚无缥缈的“AI会不会取代程序员”的宏大命题，我们只聊一件极其具体、甚至有点琐碎的事：怎么写提示词，才Neng让AI写出你真正敢用的代码。

别说话，把代码贴给它

hen多人跟AI沟通的第一大误区，就是太爱用自然语言“讲故事”。

比如你想让AI帮你写一个数据处理逻辑，你可Neng会说：“我有一个User模型，里面有name、email、avatar这三个字段，我想……” 停，打住。与其费劲口舌去描述你的数据结构长什么样，不如直接把那个struct或者class定义甩给它。相信我，机器对语法的理解远比对人类模糊描述的解析要精准得多。

AI读代码的Neng力，远强于读你的“描述”。

这不仅仅是效率问题，geng是准确性问题。当你用自然语言描述时充满了歧义；而当你把代码贴过去时你是在用一种无歧义的语言与它交流。我的个人习惯非常简单粗暴：只要涉及到具体的逻辑实现，直接把相关代码片段贴进去，别用自然语言去翻译代码。

提示词不是聊天是需求文档

你想想kan，Ru果你跟一个新来的同事说“帮我写个登录页面”，他大概率会一脸懵逼地kan着你，然后抛出一连串的灵魂拷问：用什么前端框架？有设计稿吗？要不要Zuo“记住密码”功Neng？后端接口定义好了吗？鉴权Token怎么存？

AI不会问你。它只会“猜”。

而AI的想象力，往往就是Bug的来源。当信息不足时它会根据训练数据里的“Zui大概率”来填空——这通常意味着它会给你一坨HTML+CSS+JS，样式是十年前的，逻辑是“直接把密码明文发给后端”那种。你kan一眼就想关掉。

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

你需要把该喂的“饲料”dou喂进去：代码文件、接口文档、截图、错误堆栈、数据结构定义。你给得越精确，它猜得越少，产出就越靠谱。

角色扮演：帮AI锁定“知识库”

告诉AI它是谁，这听起来像是在玩过家家，但这其实是在帮它Zuo“上下文隔离”和“知识库检索”。

Ru果你不加设定，AI可Neng会在一个通用的模式下回答你。但Ru果你加上一句：“你是一个资深iOS工程师，精通SwiftUI和Combine”，它的输出味道立马就不一样了。它知道该用async/await而不是回调地狱，知道该引入哪些特定的库，知道什么样的代码风格符合这个社区的规范。

这不仅仅是玩Cosplay，这是在帮它锁定“用什么知识库来回答你”。加了角色之后AI的输出会明显“对味”。

结构化思维：像写代码一样写提示词

hen多人写提示词是一大段密密麻麻的自然语言，这其实对AIhen不友好。根据我的经验，你写得越像步骤说明书，AI的输出质量越高。

在提示词里明确地分步骤告诉它你要什么。这里有个反直觉的技巧：在提示词里加一句“请逐步思考”或者“Think step by step”，对于复杂的逻辑问题，有着肉眼可见的效果提升。

这听起来像玄学，但原理并不复杂：你让AI把中间的推理步骤写出来它就不容易跳步犯错。就像你让一个人“心算23乘以47”和“在纸上算23乘以47”，后者的准确率要高得多。这就是所谓的“思维链”。

一个靠谱提示词的“骨架”

根据我自己无数次踩坑和反复调试的经验，一个Neng用的提示词，骨架上至少需要五样东西：

角色设定： 你是谁，擅长什么。

背景信息： 一两句话说清楚你在Zuo什么项目，解决什么问题。别让AI在真空里写代码。

输入数据： 把AI需要的原始数据喂给它。代码片段、API文档、错误日志……

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

约束条件： 告诉AI什么不NengZuo、什么格式必须遵守。这是控制输出质量的Zui后一道闸门。

杀手锏：Few-Shot Learning

Few-shot learning听起来是个高深的学术名词，其实就是“别光说给它kan”。这是hen多人会忽略的杀手锏，尤其是当你需要特定的输出格式或代码风格时一个例子胜过千言万语。

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

这比“帮我封装一个网络请求”这种模糊的指令要好十倍。给AI一个输入输出的例子，效果堪比手动调参。Ru果你不指定格式，AI会按自己的“心情”来。而它的心情，你知道的，不太稳定。

约束与输出：把好Zui后一道关

在提示词的Zui后一定要加上明确的输出要求。我个人Zui常用的一条是：“不要省略任何实现细节，不要用 // ... 占位”。

因为AI特别“聪明”，也特别“懒”，它特别喜欢在关键逻辑处用省略号带过或者写一段注释让你自己填。这时候你必须强硬一点，要求它输出完整可运行的代码。

此外一些AI API支持在assistant消息里预填内容。这个技巧在代码生成场景下特别好用——你Ke以预填 swift 来强制它直接输出代码，省掉前面那段“好的，我来帮你实现……”的废话。

实战模板：拿来即用

说了这么多方法论，不如直接kan一个我日常用的模板框架。这个模板不是死的，简单任务我会砍掉一半，复杂任务我会加上示例和对话历史的引用。但这个骨架帮我省了hen多“反复调试提示词”的时间。

## 角色
你是一个资深  工程师，擅长 。
## 背景
我正在开发 ，当前需要实现 。
## 相关代码/数据
## 任务
请按以下步骤实现：
1. 
2. 
3. 
## 约束
- 
- 
- 
## 输出要求
- 输出完整可运行的代码
- 不要省略任何实现
- 

迭代与对齐：别追求一次完美

写好提示词的Zui佳练习，就是多写代码。这听起来像废话，但事实就是：你对目标代码的理解越深，你越知道该在提示词里写什么、不写什么。一个不懂网络编程的人，写不出让AI生成高质量网络层的提示词。

同时别追求一次完美。 好的提示词往往是迭代出来的。第一版给AI，kan它哪里理解错了然后补充约束、加上示例、调整措辞。这个过程本身就是在跟AI“对齐认知”。这跟带新人一个道理：第一次没说清楚hen正常，重要的是你Neng快速定位到“哪句话让它理解偏了”。

Ru果你是在多轮对话中迭代，注意AI的上下文窗口。关键信息Ru果在hen早之前的对话里重新提一遍。别指望AI的“记忆力”，它hen容易“走神”。

工具在变，底层Neng力没变

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

提示词工程不是银弹。 它Neng把AI的输出从60分拉到85分，但Zui后那15分——架构判断、边界case、性Neng调优——还是得你自己来。AI是你的副驾驶，不是你的替身。

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

你想要“严谨的生产代码”还是“快速验证的原型”？AI会根据这个调节代码的详细程度和防御性编程的力度。在一个长提示词里把“你现在要Zuo的事”放在Zui后而且要醒目。AI对“Zui后出现的指令”权重geng高。

问题出在哪？不是AI不行，是你给的信息太少。工具在变，底层Neng力没变。掌握了与AI沟通的艺术，你才Neng真正释放这股算力，让它成为你手中Zui锋利的剑。

---