软件开发中的提示词工程模式

提示词工程已成为现代软件开发中最有价值的技能之一。能产生可工作、可维护代码的提示词与产生混乱故障内容的提示词之间的差别往往很微妙——几句话的上下文、一个提前声明的约束、或者一个正确框定问题的示例。本文收集了那些能持续产生良好结果的模式，按你所要解决的任务类型进行组织。

这些模式并非理论。它们是从数千次与 AI 编程助手在生产级代码库中的真实交互中提炼出来的。每个模式都包含具体示例和解释，以便你根据自己的工具和工作流程进行调整。

模式 1：上下文三明治

开发者在向 AI 提问时最常见的错误是提供的上下文太少。他们要求一个函数，却没有描述周围的系统、约束条件或期望的约定。AI 于是做出合理的假设，但这些假设对于他们的特定代码库来说是错误的，结果需要大量修改。

上下文三明治模式通过将每个提示词结构化为三个层次来解决这个问题：你在构建什么、有哪些约束、以及怎样才算成功。

• 上层——目标：用一句清晰的话描述你想要什么。这是大多数开发者唯一包含的部分。
• 中层——约束：列出不可妥协的条件。库版本、代码风格约定、性能要求、必须处理的边界情况。
• 底层——验证：描述你如何知道结果是正确的。一个测试用例、期望的输出格式、或需要确认的具体行为。

// 弱提示词
const result = await ai.generate("Write a function that sorts an array of users by name");

// 上下文三明治提示词
const result = await ai.generate([
  "Create a compare function for sorting an array of user objects by lastName, then firstName.",
  "Constraints: case-insensitive, handles missing names, TypeScript, no external libraries.",
  "Verify: users.sort(compare).map(u => u.lastName) should return ['Adams', 'adams', 'Brown'].",
].join("\n\n"));

上下文三明治之所以有效，是因为它在每个层面都减少了歧义。AI 知道你想要什么、你不会接受什么、以及你将如何评估结果。这一模式就消除了 AI 辅助开发中大部分浪费时间的来回沟通。

模式 2：负面约束

AI 模型通常擅长理解你想要什么。它们更不擅长理解你不想要什么。像「写一个登录表单」这样的提示词会产生合理的结果，但它可能包含你的设计中没有用到的密码复杂度规则，或者你的产品经理在上个 sprint 已经移除的「记住我」复选框。

负面约束模式明确说明 AI 应该避免什么。这比指望模型能猜对你的排除项要有效得多。

// 没有负面约束
"Build a user settings page with tabs for profile, security, and notifications."

// 有负面约束
"Build a user settings page with tabs for profile, security, and notifications.
DO NOT include: email verification flows, password strength meters, or social login buttons."

负面约束在放在提示词末尾、正面描述之后时效果最好。这模仿了人类处理指令的方式——我们需要先理解了要求什么，才能理解排除了什么。AI 遵循同样的模式：它先根据正面描述构建心智模型，然后将排除条件作为过滤器应用在上面。

模式 3：示例模板

当你在多次 AI 交互中需要一致的输出时——生成文档、编写测试用例或格式化 API 响应——告诉 AI 做什么不如展示给它看有效。示例模板模式提供一个或两个完整的期望输出示例，然后要求以相同格式生成更多内容。

这是通过聊天界面所能实现的最接近少样本学习的方式。一个精心选择的示例能够传达格式、语气、详细程度以及需要大段文字才能明确描述的隐含约定。

// 生成错误消息的示例模板
const example = {
  code: "ERR_AUTH_TOKEN_EXPIRED",
  message: "Your session has expired. Please log in again.",
  severity: "warning",
  action: "redirect:/login",
};

const result = await ai.generate([
  "Generate 5 more error objects in the same format as this example:",
  JSON.stringify(example, null, 2),
  "Cover: rate limiting, permission denied, not found, validation error, server error.",
].join("\n\n"));

这个模式的关键是选择合适的示例。它应该具有代表性但不能过于侧重边界情况——你希望 AI 从你的示例中泛化，而不是复制它的特例。当输出格式有多种变体时，两个示例优于一个，但超过三个示例很少增加价值，反而会开始消耗你的上下文窗口。

模式 4：迭代优化循环

期望 AI 在一次提示中就给出最终完美结果，就像让一个初级开发者不经任何迭代就直接发布生产代码。有时确实能行，但通常会产生需要大量返工的内容。迭代优化循环将 AI 交互视为一次对话，从宽泛开始，逐步收窄。

• 第一轮——生成一个宽泛的解决方案或骨架。暂时不要要求细节。
• 第二轮——审查输出并给出具体方向。这部分很好，修改那部分，添加这种情况。
• 第三轮——打磨细节。错误处理、边界情况、命名、文档。

每一轮都为 AI 提供了更多关于你实际想要什么的上下文，因为你的反馈是针对它刚刚生成的代码的。这比试图在第一个提示词中就预料到所有细节要高效得多。AI 也因此受益，因为它可以一次专注于问题的一个层面——先是结构，然后是细节，最后是打磨。

模式 5：角色前缀

AI 模型是在来自多个领域的文本上训练的，它们可以在提示下采用不同的角色。角色前缀模式在要求 AI 编写代码之前，明确为其分配一个角色和视角，从而使它产生的输出更适合该上下文。

// 通用
"Review this function for security issues."

// 角色前缀
"You are a security engineer reviewing a pull request. Focus on:
- Injection vulnerabilities in the SQL query construction
- Missing input validation on the user ID parameter
- Hardcoded credentials or secrets

Review this function:"

角色前缀模式在审查任务、重构和文档生成中尤其强大。当你需要符合无障碍标准的代码时，前缀用「你是一名无障碍专家」。当你优化性能时，前缀用「你是一名性能工程师」。AI 会调整它的推理和输出以匹配你要求的视角。

模式 6：输出契约

AI 编程最令人沮丧的经历之一就是得到一个看起来正确、但微妙地改变了输出格式、添加了你没要求的解释性文本、或遗漏了关键部分的响应。输出契约模式通过精确指定响应应该包含什么——同样重要的是不应该包含什么——来防止这种情况。

"Generate a React component for a file upload button.

Output contract:
- Return ONLY the component code in a single code block
- No explanation text before or after
- Include TypeScript props interface
- Include CSS module import
- Do NOT include usage examples or test files
- File name: FileUpload.tsx"

输出契约在你将 AI 输出导入另一个工具或工作流时尤其有价值。如果响应总是遵循相同的结构，你就可以可靠地解析它。这个模式是构建需要一致格式化的自动化 AI 辅助流水线的基础。

模式 7：上下文窗口预算

每个 AI 模型的上下文窗口都是有限的。当你粘贴过多的代码、文档或对话历史时，模型就会开始遗忘或产生幻觉。上下文窗口预算模式将上下文窗口视为稀缺资源，并刻意分配它。

• 将 60% 的预算分配给最相关的代码和任务描述。
• 将 20% 分配给阐明任务的示例和约束。
• 保留 20% 给 AI 的响应空间——如果窗口满了，输出将被截断。

当你的上下文超出窗口容量时，优先考虑最具体、最相关的部分。一个包含一份精心选择文件的聚焦提示词，比一个包含五份松散相关文件的宽泛提示词更有效。AI 总可以在需要时要求更多上下文——在对话早期就给它这个权限。

一个包含一份精心选择文件的聚焦提示词，始终优于一个散乱包含五份文件但 AI 几乎无法看清的提示词。

模式 8：骨架先行再填充序列

复杂功能涉及许多移动部件。让 AI 一次性全部生成会产生一个混乱的结果，状态管理、API 调用和 UI 渲染难以分离。骨架先行再填充序列将问题分为两个阶段。

首先，让 AI 生成骨架：类型定义、接口和功能的高级结构，不含实现细节。审查这个骨架并确认它符合你的心智模型。然后才让 AI 逐层填充细节——实现、错误处理、边界情况。

// 阶段 1 — 骨架
"Design the type structure for a multi-step checkout flow. List the interfaces, enums, and state machine transitions. Do not write implementation yet."

// 阶段 2 — 填充（审查骨架后）
"Implement the checkout state machine from the types we agreed on. Include transition validation and error states."

这个模式防止了最昂贵的一种返工：在实现完成后改变结构。通过先就骨架达成一致，你确保 AI 构建在一个与你架构匹配的基础上，而不是某个想象出来的基础。

综合运用这些模式

这八个模式在组合使用时效果最佳。一个典型的会话可能以上下文三明治开始来框定请求，使用负面约束排除不想要的方法，遵循迭代优化循环来收敛到正确的解决方案，最后用输出契约来获得干净、可解析的结果。

你练习这些模式越多，它们就越自然。几天之内，你就会发现自己本能地将提示词结构化为上下文三明治，并下意识地添加负面约束。那时，AI 辅助开发就会从一个有时有用的工具转变为你工作流程中始终可靠的一部分。

每次与 AI 助手的交互都是一项投资。一个结构良好的提示词多花三十秒，却能节省数小时的来回沟通。在一百次交互中，这三十秒累积成数天的节省——以及挫败感与流畅状态之间的区别。