提示词实践笔记：系统提示词和用户提示词

写在前面

用了一段时间的 LLM 之后，我越来越觉得，跟 AI 协作这件事，远不是”把问题丢过去”那么简单。模型的能力摆在那里，但能不能发挥出来，很大程度上取决于你怎么跟它说话——也就是提示词的质量。

提示词工程（Prompt Engineering）这个概念，现在已经不新鲜了。但说实话，很多人（包括我自己早期）对它的理解还停留在”怎么问问题”这个层面。真正深入之后才发现，它其实是一门关于”怎么构建对话”和”怎么设计 AI 行为”的学问。

这篇文章，我想从两个维度来聊聊这个话题：

系统提示词：定义 AI “是什么”，相当于给它立一个人设
用户提示词：引导 AI “做什么”，相当于在对话中导演它的表演

搞清楚这两者的区别和配合方式，是用好 LLM 的第一步。

系统提示词 vs 用户提示词：到底有什么区别？

刚开始用 LLM 的时候，我一度觉得”提示词就是提示词”，没什么区别。后来踩了不少坑才明白，这两种提示词的功能定位完全不同。

系统提示词：给 AI 立一个”人设”

系统提示词是一个持久性的框架，在整个会话期间为 AI 定义它的身份、能力和行为边界。你可以把它理解成 AI 的”核心程序”——在你开始问问题之前，它就已经被设定好了。

打个比方：如果 AI 是一个演员，那系统提示词就是他上台之前拿到的角色说明书。它规定了这个演员的性格、专长、说话方式，以及哪些事情绝对不能做。这是静态的、底层的框架，后面所有的表演都基于这个设定展开。

在技术实现上，它对应 API 请求中的 system 角色。模型会把这条消息当作高优先级指令，用来影响它对后续所有对话的理解。

用户提示词：在对话中指挥 AI 干活

用户提示词就是你在对话过程中给出的具体任务指令。它是动态的，随着对话的推进不断变化。

继续用演员的比喻：用户提示词就是导演在片场的即时指导——“这个场景你往左走两步”、”表情再自然一点”、”这条过了，下一场”。

在 API 层面，它对应 user 角色。每一条用户提示词和 AI 的回复，都会被追加到对话历史里，成为下一轮的上下文。

我自己早期犯过一个典型错误：花大量时间打磨系统提示词，觉得”人设立住了，后面就顺了”。但实际上，如果用户提示词本身含糊不清或者前后矛盾，再好的系统提示词也救不了。这两者是相辅相成的，缺一不可。

怎么写好系统提示词？

写系统提示词，本质上就是在给 AI 塑造一个”灵魂”。经过大量实践，我总结了几个对我帮助很大的原则。

用第一人称来定义角色

这一点是我踩坑最多的地方。早期我习惯写”你是一个 Python 专家”，后来发现效果远不如”我是一个 Python 专家”。

原因很简单：“你是一个……”在模型看来是一道外部命令，它处于被动接受的状态。而”我是一个……”会被内化为自我认同，执行起来更自然、更一致。

# 效果一般
你是一个 DevOps 工程师，负责 CI/CD 流水线。

# 效果更好
我是一名 DevOps 工程师，在 Kubernetes 集群运维和 GitOps 工作流方面有深入实践，
擅长用 ArgoCD 和 Helm 构建自动化的持续交付流水线。

别小看这个人称的差别，实际使用中效果差距很明显。第二种写法不仅换了人称，还顺带把能力边界说清楚了，AI 后续的输出会更精准。

给它一个”精英人设”

不要只说 AI “能干”，要把它塑造成行业顶尖的专家。这听起来有点玄，但背后的逻辑是：AI 的自我认知会影响它输出质量的上限。你给它一个高水平的人设，它的回应就会锚定在训练数据中与该角色对应的高标准上。

# 效果一般
我是一个熟练的数据库优化专家。

# 效果更好
我是 PostgreSQL 全球开发组的核心贡献者，在高并发 OLTP 场景下的查询优化和
索引策略设计方面有超过八年的实战经验，曾为多个日活千万级的系统做过性能调优。

我在实际使用中发现，与其堆砌形容词（”熟练的”、”精通的”），不如直接把它和具体的项目经历或技术社区挂钩——这些概念本身就带着一整套行为模式和质量标准。AI 会从训练数据中调取与该角色关联的高质量知识。

用”原型化身”代替性格罗列

与其写一堆期望的性格特质（”机智、有洞察力、略带犬儒主义……”），不如直接让它化身成一个已经具备这些特质的知名人物。

比如，我在写一个需要深度技术分析的场景时，试过两种写法：

# 写法一：罗列特质（效果一般）
我是一个善于深度思考的技术专家，擅长从第一性原理出发分析问题，
逻辑严密，表达清晰，能把复杂概念讲得通俗易懂。

# 写法二：原型化身（效果明显更好）
我以理查德·费曼讲解物理概念的方式——用最直觉的类比、最清晰的逻辑、
拒绝一切含糊其辞——来分析和解释技术问题。

写法二只用了一句话，但信息密度远高于写法一。”费曼”这个标签本身就打包了”善于类比”、”逻辑清晰”、”拒绝含糊”等一整套特质，AI 可以整体性地调取，效果自然更好。

正面指令，不要负面禁止

这个原则让我少走了很多弯路。以前我总喜欢写”不要做 X”、”不要做 Y”，后来发现效果很差。

原因在于：告诉 AI “不要做 X”，它仍然需要先理解”X”是什么。这就是经典的”别想那头粉色的大象”——你越禁止，它越会关注那个概念。

# 效果差（-10）
不要写 any 类型的 TypeScript。不要忽略错误处理。不要用 var 声明变量。

# 效果好（+100）
我是一名严格遵循 TypeScript 最佳实践的前端工程师。所有变量使用 const/let
声明，函数参数和返回值必须有明确的类型标注。每个异步操作都要有 try-catch
包裹，错误信息要包含上下文便于排查。

第二种写法把 AI 的注意力完全引导到了”应该怎么做”上，它根本不会去想”不该做什么”。

术语要一致，别混着用

这个看起来是小事，但影响不小。LLM 的运作基于词语间的统计关联，当你混用同义词时（比如在编程语境下交替使用”方法”、”函数”、”子程序”），就是在引入语义噪音，增加 AI 的”认知负荷”。

我现在的习惯是：在系统提示词中先定义好关键术语，后面统一使用。

保持系统提示词的”纯粹性”

系统提示词应该只定义通用人设和核心行为逻辑，不要把具体的任务示例、数据往里面塞。

我之前犯过这个错误——在系统提示词里写了一个 JSON 转换的示例，结果后面所有任务都莫名其妙地往 JSON 格式上靠。这就是”过拟合”了。具体的示例应该放在用户提示词里，它只作用于当前任务，不会污染全局上下文。

复杂任务？拆成多个智能体

对于复杂的工作流，我现在的做法是把它拆成独立的阶段，每个阶段用一个专门的 AI 智能体，每个智能体都有自己聚焦的系统提示词。

比如一个软件开发流程，我会拆成：

产品经理智能体：”我是一名专业的产品经理，负责将业务需求转化为清晰的用户故事和验收标准。”
架构师智能体：”我是一位经验丰富的系统架构师，负责设计稳健、可扩展的系统架构。”
测试工程师智能体：”我是一名一丝不苟的质量保证工程师，负责创建全面的测试计划。”

单一的通用 AI 很难在”创造性头脑风暴”和”严谨的代码生成”之间有效切换。拆开之后，每一步都由最合适的”人格”来处理，整体质量提升很明显。

另外，不同智能体的上下文要严格隔离。让”头脑风暴智能体”的发散性思维污染”代码生成智能体”的逻辑推理，是非常糟糕的事情。

怎么用好用户提示词？

如果说系统提示词是”立人设”，那用户提示词就是”当导演”。在实际对话中，用户不是被动的请求者，而是主动的引导者。以下是我在实践中觉得最有用的几个原则。

用建设性的语气引导

LLM 有一个很有意思的特性：它会模仿你的语气。如果你用负面或指责的语言（”你错了”、”这太蠢了”），它可能会进入一种”防御模式”，输出质量反而越来越差。

我现在即使对 AI 的输出不满意，也会用建设性的方式引导：

# 不推荐
你写的这个 Dockerfile 有问题，镜像太大了，构建也慢。重写。

# 推荐
Dockerfile 的整体结构没问题，多阶段构建的思路是对的！现在来优化一下：
能不能把基础镜像换成 alpine 版本，然后把 COPY 指令拆开，
先拷贝依赖文件单独构建一层，利用 Docker 的缓存机制加速后续构建？

这不是”礼貌”的问题，而是实际效果的问题。你给了正向反馈 + 具体优化方向，AI 的后续输出会更精准。

明确标示任务状态

这个原则帮我避免了很多”上下文污染”的问题。不要假设 AI 知道一个子任务已经结束了——你得明确告诉它。

# 模糊（AI 可能还在想上一件事）
好了，现在帮我写个部署脚本。

# 明确
API 接口的代码已经 review 通过，合并到 main 了。现在开始一个全新的
独立任务：写一个 shell 脚本，把这个服务部署到 K8s 集群，
包括 apply deployment、service 和 ingress 配置。

没有明确的完成信号，AI 可能会在后续轮次中继续”优化”上一个任务的代码，污染新任务的专注度。

回去编辑，不要打补丁

这个是我学到的最重要的技巧之一。当对话因为误解偏离轨道时，不要试图用后续的修正指令来亡羊补牢——回去编辑那条导致偏差的原始提示词。

原因在于：AI 的每一次回应都取决于全部的对话历史。如果早期的某条提示词有缺陷，这个缺陷会成为上下文中永久性的污染源。后续的”补丁”只会增加更多噪音。

# 错误做法（打补丁）
用户：帮我写一个 FastAPI 的用户注册接口。
AI：（生成了用明文存储密码的版本）
用户：密码不能明文存啊，要加密。
AI：（加了 hashlib）
用户：hashlib 不行，要用 bcrypt，而且要做异步处理。
AI：（改成了 bcrypt）
用户：你忘了加输入校验...
# 对话历史越来越混乱，AI 已经开始前后矛盾了

# 正确做法（编辑原始提示词）
用户（编辑为）：帮我写一个 FastAPI 的用户注册接口。要求：
1. 用 bcrypt 异步哈希密码
2. 用 Pydantic 做输入校验，邮箱格式和密码强度都要验证
3. 注册前检查邮箱是否已存在
4. 返回统一的 JSON 响应格式
# AI 从一个干净的起点重新生成，一步到位

展示你的专业性

AI 会根据你的语言动态评估你的水平。如果你问”怎么让部署更快”，它可能给你一堆泛泛的建议。但如果你说”我们的 K8s 集群有 200 个 Pod，Helm upgrade 滚动更新耗时 8 分钟，我想通过调整 maxSurge 和 maxUnavailable 参数，结合 readinessProbe 的 initialDelaySeconds 来优化”，它就会切换到”同行协作者”模式，给出真正有针对性的建议。

你必须成为互动中的主导者。 用精确的术语，展现战略性思维，AI 才会匹配你的专业水准。

复述确认：让 AI 先说一遍它的理解

在 AI 开始一项复杂任务之前，我会要求它用自己的话复述目标、约束和计划。在它的总结和我的意图完全一致之前，我不让它动手。

这个习惯帮我避免了无数次”做了一半才发现理解错了”的尴尬。简单地告诉 AI”你理解了吗”是没用的——只有当它能自己清晰地阐述计划时，才能确认它真的理解了。

上下文污染了？开新对话

花了一个小时跟 AI 调试 Docker 网络配置，然后说”好了，帮我写个 Python 脚本处理日志”，结果它给你一个用 subprocess 调用 docker network inspect 的脚本——这就是上下文污染的典型症状。

遇到这种情况，最有效的解决方案就是：开一个新的聊天会话。试图在污染的上下文里纠正，往往是徒劳的。一次彻底的重启，比任何补丁都管用。

快速参考

最后，把上面的内容整理成一个速查表：

维度	系统提示词（立人设）	用户提示词（当导演）
身份	用第一人称，给精英人设	展示你的专业性，带动 AI
语言	精确术语，正面指令，别罗列禁令	积极引导，别指责，别发脾气
范围	只管通用行为，别塞具体示例	每次任务要明确、具体、清晰
上下文	保持纯粹，不同智能体隔离	明确标示任务完成，污染了就开新对话
纠错	—	回去编辑原始提示词，别打补丁

写在最后

提示词工程不是一劳永逸的技能，它需要在实践中不断迭代。模型在进化，具体的技巧可能会变，但清晰的身份架构、精确的指令、审慎的对话管理这些核心原则，我觉得是不会过时的。

说到底，AI 是一个力量倍增器，但倍增器的输出质量，取决于输入的质量。从一个 AI 的”操作员”变成它的”架构师”，这个转变的过程，就是提示词工程这门学问的核心价值所在。