9.3 提示工程即"氛围设定"

提示工程不是为了"骗"AI

很多人对提示工程有一种误解：认为提示工程是"怎么编话术来骗 AI 给出更好的回答"。比如"扮演一个资深专家""你是一个有 20 年经验的……"——听起来像是在演戏。

我自己一开始也有这种感觉——用"角色扮演"来让 AI 给出更好的回答，总觉得有点怪。为什么 AI 在被设定为"资深开发者"时给出的代码，比没有被设定角色时更好？它难道不应该在所有情况下都给出最好的代码吗？

但理解了两阶段训练（9.1 节）后，这个现象就说得通了。

在预训练阶段，模型学习了互联网上所有类型的文本——有些是专家写的专业文档（代码规范、API 文档、技术博客），有些是新手写的论坛提问和初级代码。模型知道什么样的文本应该对应什么样的"角色"——当输入看起来像"专家在讨论"时，它更倾向于生成专家风格的输出。当输入看起来像"新手在提问"时，它可能生成更基础、更简单的回答。

"角色设定"不是演技——它是在激活模型在预训练阶段学习到的"专家模式"的语料分布。

当你对 AI 说"你是一个资深 Python 开发者"时，你的输入文本的"风格信号"与预训练数据中"资深开发者讨论技术问题"的文本风格更接近。模型在数万亿 Token 中学会了：当输入看起来像"专家对话"时，输出也应该像"专家对话"——于是它生成了更高质量的代码。

反过来，如果你直接说"帮我写个函数"——这句话的风格接近于论坛上的"求代码"帖子。模型的学习经验告诉它：这种输入对应的输出，应该是一段"能让新手看懂的基础代码"——而不是一个经过精心架构的工业级实现。

所以，提示工程不是"骗"AI——它是在对 AI 说："现在请用你学过的那个特定领域的知识来回答我。"

角色设定的作用：激活特定的知识空间

AI 在训练中学到的知识不是"一个均匀的大仓库"，而更像一个有很多"房间"的知识空间。每个"房间"对应一种特定的写作风格、领域知识或表达方式。

角色设定的本质是：帮 AI "推开门"，进入正确的那个房间。

如果你设定了"你是一个资深 Python 开发者"——AI 进入了"Python 专家"的房间。这个房间里的知识包括：PEP8 代码规范、设计模式、性能优化技巧、常见陷阱和最佳实践。AI 在这个房间里"思考"和"说话"，它的输出会自然地带有这些特征。

如果你没有设定角色——AI 进入了"默认"的房间。这个房间里的知识更广泛但更浅：基本的编程概念、常见的语法、通用的实现方式。它也能工作，但不如"专家房间"里的输出那么深入。

不同角色设定下，AI 指数的差异：

以"帮我实现一个用户认证功能"为例：

无角色设定：

• 生成代码：基本的 username/password 验证
• 安全考虑：基础（可能没有考虑加密存储）
• 错误处理：有限
• 代码组织：一个函数包含所有逻辑

设定为"资深安全工程师"：

• 生成代码：使用 bcrypt 加密密码、考虑 CSRF 保护、Session 管理
• 安全考虑：完善（密码强度校验、登录频率限制）
• 错误处理：完整（多种错误类型区分）
• 代码组织：模块化设计（认证层、存储层、校验层分离）

设定为"专做 MVPs 的全栈开发者"：

• 生成代码：快速可用的实现，使用现有的认证库
• 安全考虑：基础但足够了（MVP 阶段不需要企业级安全）
• 错误处理：必要的错误提示
• 代码组织：简洁、集成方便

设定为"架构师"：

• 生成代码：先给方案，再给代码——"我建议用 JWT + Refresh Token 的方案，理由如下：……"
• 安全考虑：全面的安全架构分析
• 错误处理：完整的错误码体系
• 代码组织：可扩展的架构设计，考虑未来需求

同一个问题，四个不同的角色设定，给出了四个不同维度的答案。你需要的不是"最好的"那个——而是"最适合你当前阶段"的那个。

系统提示词中常见技巧

除了角色设定，系统提示词中还有一些常见的"技巧"——其实更准确地说，是经验法则。这些经验法则是基于大量实践总结出来的，在对齐训练中也通过了验证。

技巧一：具体化而不是抽象化。

与其说"请写出高质量的代码"，不如说"请遵循 PEP8 规范，使用类型注解，添加完整的异常处理"。

前者依赖 AI 对"高质量"的理解——不同模型的"高质量"标准不同。后者给出了三条具体的、可验证的标准——AI 可以直接按标准执行。

技巧二：描述你想看到的输出格式。

与其期待 AI "猜"你想要的输出格式，不如直接告诉它。

例如：

• "输出一个完整的 React 组件文件，包含 TypeScript 类型定义。"
• "用 Markdown 格式回答，代码块标注语言。"
• "先给出方案概述，再给出完整的代码实现，最后列出需要考虑的边界情况。"

技巧三：设定约束条件。

告诉 AI 什么能做、什么不能做。这比只告诉它"要做什么"更有效，因为约束排除了 AI 的"默认选择"。

例如：

• "只使用标准库，不要引入第三方依赖。"
• "不要修改已有的数据库表结构。"
• "所有样式使用 Tailwind，不要写自定义 CSS。"

技巧四：提供少量示例（Few-shot）。

如果你给 AI 几个"输入-期望输出"的例子，它的输出会更准确。这不限于编程——任何需要特定格式的任务都适用。

例如：

"请将以下用户评论分类为正面、负面或中性。示例：

输入：'这个产品太棒了，推荐给所有人' → 输出：正面

输入：'质量很差，用了三天就坏了' → 输出：负面

现在请分类：'价格合理，但物流太慢了' → "

技巧五：分步思考（Chain-of-Thought）。

当任务需要多步骤推理时，让 AI "一步一步思考"可以显著提高准确性。这个技巧源于一篇论文的发现——让模型"先想想再回答"，它会更少犯错。

例如：

"一步一步分析这段代码的性能瓶颈，然后给出优化建议。"

氛围设定的三层粒度

提示工程在实践中可以按照"粒度"分为三个层次：

第一层：宏观设定（一次性的系统提示词）。

在你开始一个项目或一个长时间的对话前，设定好"宏观氛围"。这个设定会贯穿整个对话，影响 AI 的所有回复。

典型设置：

• "你是一个全栈开发者。"
• "技术栈：Next.js 14 + TypeScript + Tailwind + Prisma + PostgreSQL。"
• "编码风格：使用函数式组件，避免 class 组件。变量名用 camelCase。"
• "回答风格：先给出方案，再给代码。代码用 TypeScript。"

宏观设定是"地基"——它决定了 AI 在整段对话中的基本行为。设定得好，后续每轮对话都会更精准。

第二层：微观调整（每轮对话的具体控制）。

在每一轮对话中，根据当轮的特定需求微调。这就像是和同一个同事说话——你知道他的基本能力，但每个任务需要不同的具体指示。

典型调整：

• 当前轮次："我有一个已经写好的页面，需要你帮我把状态管理从 useState 改成 useReducer。"——明确了范围，聚焦在一个具体的重构任务上。
• 下一轮次："现在帮我写这个页面的单元测试，用 Vitest。"——切换到了另一个任务，AI 不会自动知道你的目标已经变了。

微观调整的价值在于：你不需要每次重复宏观设定，但你需要告诉 AI"现在我们要做什么"。

第三层：即时反馈（对 AI 输出的实时响应）。

在 AI 生成了回复后，你的反馈本身也是提示工程的一部分。反馈越具体，AI 的下一轮输出越准确。

典型反馈：

• 优秀的反馈："代码可读性不错，但第 45 行的 try-catch 范围太大了。把 fetch 操作单独放在 try 块中，其他操作不要放在里面。"
• 糟糕的反馈："这个不好，重做。"

优秀的反馈不仅告诉 AI"改什么"，还告诉它"为什么"——"范围太大了"和"把 fetch 单独放在 try 块"结合，AI 理解了你的修改意图。糟糕的反馈只给了"结果"（不好），没有给"方向"（怎么改）。

实践中常用的"氛围设定"

以下是一些经过验证的、常用的氛围设定模板。你可以根据自己的需求组合使用：

通用编程设定：

你是一个资深的前端/全栈开发者。你的回答特点：先给出方案概述，再给出完整代码。代码用 TypeScript，遵循函数式编程风格。在给出代码前，先分析需求中可能被忽略的边界情况。

调试设定：

你是一个调试专家。对于每一个 bug，按照以下流程分析：1）错误信息解读；2）可能的原因列表；3）逐一排查的方法；4）修复方案。不要跳过步骤，即使你觉得"一看就知道是哪里错了"。

学习设定：

你是一个耐心的技术导师。你的回答要同时满足两个目标：1）回答当前的问题；2）帮助提问者建立对概念的理解。在解释时优先使用类比和具体的代码示例。不主动引入尚未解释过的专业术语。

代码审查设定：

你是一个严格的代码审查者。审查标准：1）功能正确性（是否有 bug）；2）性能（是否有不必要的计算或 IO 操作）；3）可维护性（命名、结构、注释）；4）安全性（是否有常见漏洞）。按这个优先顺序给出改进建议。

你可以自由组合这些"氛围"。 比如：

"你是一个调试专家 + 耐心的技术导师。我遇到了一个 bug：[描述]。请按你的调试流程分析，同时假设我只有初级 JavaScript 水平——不要用我没有解释过的概念。"

提示工程不是魔法

说了这么多，我必须点明一个事实：提示工程有上限。

不管你多么精心设计提示词，如果模型本身不具备解决这个问题的能力，提示工程也无法弥补。提示词可以让一个中等水平的模型给出高于平均水平的输出，但不能让一个模型完成它能力之外的任务。

比如：一个只在 Python 代码上训练过的模型，你不可能通过"扮演资深 Rust 开发者"的提示词让它突然写出高质量的 Rust 代码。提示词激活的是模型已有的知识——它不能创造模型没有的知识。

所以，提示工程的重点是激活——激活模型在某个领域已经学到的知识，不是"教会"模型新东西。

这个认识帮助你避免两个极端：一是"完全不相信提示词的作用"（它确实有用），二是"把一切希望寄托在提示词上"（它有上限）。