面向开发者的提示词工程：写出更好的 AI 提示词

无论你使用 ChatGPT、Claude、Copilot 还是其他 AI 助手，提示词的质量会直接影响你得到的代码和解释的好坏。提示词工程（Prompt engineering）是编写清晰、有条理的指令，让 AI 模型产出更有用、准确、切题的结果的实践。对开发者来说，这是一项能加速编码、调试和学习的核心技能。

什么是提示词工程？

提示词工程是设计你发给 AI 的文本，让它理解你的目标并以有帮助的方式回答。对开发者而言，通常包括：生成或重构代码、解释报错、编写测试、改进正则、或起草文档。好的提示词会明确上下文、约束和期望的输出格式，这样模型就不必猜测你的意图。

写好提示词的核心原则

1. 具体明确

模糊：「写个函数。」具体：「写一个 Python 函数，接收整数列表，返回所有偶数的和。对参数和返回值使用类型注解。」你对输入、输出和行为的描述越精确，来回修改就越少。

2. 提供上下文

说明语言、框架、运行环境或编码风格。例如：「用 TypeScript 写一个 React Hook，从 /api/users 获取用户数据，并处理加载和错误状态。我们使用 fetch，不用 axios。」上下文能减少无关或过时的建议。

3. 用示例（Few-Shot）

用一两个例子说明你想要的结果。例如：「按这种格式输出日期：2026-01-15。用 JavaScript 把 '2026年1月15日' 转成该格式。」示例对统一格式、命名或结构特别有帮助。

4. 约定输出格式

明确要求 JSON、代码块、列表或分步推理。例如：「用包含 error_type、likely_cause、fix 的 JSON 对象回复。」或「用 3 条要点说明。」说明格式便于直接复用输出。

5. 小步迭代

若第一次回答不对，就收窄需求：增加约束、只改某一部分，或要求变换风格。把任务拆成多个小提示，往往比一个又长又复杂的提示更有效。

开发者常用提示模式

代码生成

写明：语言、框架、限制以及你遵循的约定。

写一个 Node.js 函数，读取 JSON 文件，用包含 "name"（字符串）和 "count"（数字）的 schema 校验，返回校验通过的对象或抛出错误。只用 Node 的 fs，不要第三方库。

调试

贴出报错信息、相关代码片段，以及你原本的预期。

在这个 React 组件里出现 "TypeError: Cannot read property 'map' of undefined"。[贴代码]。数据来自 /api/items。问题出在哪，怎么修？

正则表达式

用自然语言描述匹配规则，并给出应该匹配或不匹配的示例字符串。

写一个匹配邮箱（local@domain.tld）的正则。应匹配 user@example.com，不匹配 "user" 或 "user@"。优先用标准、可读的写法。

可以在正则测试工具里快速验证你的表达式。

文档

指定格式（JSDoc、JSDoc+示例、README 段落）和详细程度。

给这个函数加上 JSDoc 注释，包含 @param、@returns 和一个 @example，展示典型调用和返回值。

需要避免的常见问题

• 上下文过少：模型会按你没用的语言、风格或库来假设。
• 一次要太多：一个提示里要「搭好带鉴权、测试和文档的完整 API」常会得到笼统、浅显的结果。应拆成多步。
• 没有示例：对严格格式（如 JSON、CSV、SQL），哪怕一个示例也能减少无效输出。
• 忽视第一次回答：若已接近，只需在提示里修正错误部分，而不必推倒重来。

进阶技巧

Few-Shot 示例学习

在正式需求前给出 2–3 组输入/输出示例，模型会按该模式作答。适用于：格式转换、名称规范化或生成结构化数据。

链式思考（Chain-of-Thought）

要求模型分步推理：如「先找出报错原因，再解释为何发生，最后给出修复建议」或「先想清楚逻辑再写代码」。对较难问题往往能提高正确率。

系统或角色提示

在工具支持的情况下，可设置系统/角色消息，例如：「你是一位资深后端开发，偏好清晰、有测试的代码，使用 TypeScript。」这样能为整段对话定下基调与风格。

练习与工具

提示词工程会随练习提升。从小的、具体的任务开始：一个函数、一条正则、一个报错。留意哪些写法能让模型表现更好，并复用这些模式。

可查看我们的 AI 工具 和 AI 博客，获取更多在开发中使用 AI 的指南——从模型对比到实用工作流。

小结

更好的提示词带来更好的 AI 辅助：写具体、加上下文、用示例、约定输出格式，并小步迭代。把这些原则用在代码生成、调试、正则和文档上，你就能从任意 AI 编程助手中得到更实用、更可靠的结果。

浏览 AI 工具 阅读更多 AI 指南