提示词工程完全指南：如何高效编写 Prompt 与 Skill

我还不赖
4 阅读25分钟

一、引言

1.1 什么是提示词工程

提示词 工程（ Prompt Engineering ） 是指通过精心设计和优化输入给大语言模型（LLM）的指令文本，使模型输出更准确、更符合预期的系统方法论。简单来说，你给模型的每一段文字——无论是一句提问、一段上下文、还是一整套结构化指令——都是"提示词"（Prompt）。提示词工程则是让这些文字更高效地"驱动"模型完成任务的技术与实践。

大语言模型的输出具有非确定性，同一个问题在不同措辞下可能得到截然不同的结果。提示词工程的核心价值就在于：将这种不确定性降到最低，让模型的行为可控、可预测、可复现。

1.2 什么是 Skill

Skill（技能） 是对一组 Prompt 指令的模块化封装。如果说单条 Prompt 是「即兴发挥的一次提问」，那么 Skill 就是「可复用、可调用、可分享的标准化指令包」。Skill 通常包含：

  • 明确的触发条件和使用场景描述
  • 结构化的执行步骤
  • 输入参数和输出格式的约定
  • 可选的工具权限和运行环境配置

Skill 的设计思想来自软件工程中的函数封装——将复杂的任务抽象为可重复调用的模块，从而降低使用门槛，提升工作效率。

1.3 适用场景与价值

提示词工程和 Skill 设计适用于所有需要与大模型交互的场景，包括但不限于：

场景典型需求提示词工程的价值
内容写作文档生成、邮件撰写、报告输出控制风格、格式、篇幅
代码开发代码生成、重构、Code Review约束语言/框架、明确规范
数据分析数据清洗、趋势分析、报告解读结构化输出、保证分析逻辑
产品策划需求梳理、竞品分析、PRD 撰写引导思维框架、确保完整性
知识问答技术咨询、政策查询、概念解释限定回答范围、减少幻觉
工作流自动化CI/CD 辅助、定时任务、批量处理将 Skill 串联成自动化流水线

核心认知：模型并不"理解"你的意图，它是在根据统计概率生成回复。提示词工程的本质，是用精确的语言最大化传达你的意图，让概率向你期望的方向倾斜。

二、基础概念

在深入最佳实践之前，需要理清几个核心术语。

2.1 Prompt（提示词）

你发送给模型的全部输入信息。它可以是一句话、一段对话、也可以是包含多个角色消息的复杂结构。

2.2 System Prompt / Instruction（系统提示 / 指令）

在 API 层面，大多数模型支持区分不同优先级的消息角色。以 OpenAI 的 API 为例，消息分为三种角色：

角色说明类比
developer（开发者/系统）应用层面的规则和约束，优先级最高相当于函数定义
user（用户）终端用户的具体请求相当于函数参数
assistant（助手）模型生成的回复相当于函数返回值

System Prompt 通常包含身份设定、行为规则、输出格式约束等全局性指令，它决定了模型在整个对话中的「基调」。

2.3 Skill（技能）

一个封装好的、可复用的指令模块。在 Claude Code 等工具中，Skill 以 SKILL.md 文件形式存在，通过 YAML frontmatter 定义元信息，通过 Markdown 内容定义执行逻辑。用户可以通过 /skill-name 斜杠命令调用，模型也可以在适当时机自动加载[Extend Claude with skills]。

2.4 Tool / Function（工具 / 函数调用）

模型在生成文本的同时，可以「调用」外部工具来完成特定任务——比如搜索网页、查询数据库、执行代码等。工具调用是模型从「纯文本生成器」进化为「智能代理（Agent）」的关键能力。

2.5 Context Window（上下文窗口）

模型在单次生成时能处理的最大信息量，以 token 为单位。不同模型的上下文窗口差异很大（从 128K 到 1M+ token 不等）。超出窗口的内容会被截断，因此合理管理上下文是提示词工程的重要环节。

2.6 Few-shot / Zero-shot（少样本 / 零样本）

  • Zero-shot：不给示例，直接让模型完成任务。
  • Few-shot：在提示词中给出若干输入-输出示例，让模型「照着学」。

Few-shot 是最常用的提示词工程技术之一，适合定义输出格式、教模型处理特定领域任务。

三、高质量 Prompt 的基本原则

以下六条原则是所有主流模型厂商在其官方文档中反复强调的共性要求。

原则一：清晰明确

不要假设模型能猜到你想要什么。 模棱两可的指令是低质量输出的首要原因。

做法较差示例优化示例
明确任务类型"帮我处理一下这段代码""重构以下 Python 函数，将嵌套 if 改为 guard clause 模式，保留原有功能"
明确输出对象"写一篇文章""为面向技术管理者的内部 wiki，撰写一篇关于微服务拆分策略的文档"

原则二：具体可量化

给模型明确的约束，而非开放式的模糊期望。

  • 指定字数范围（如"300-500 字"）
  • 指定输出格式（如"用 JSON 返回，包含 title、summary、tags 三个字段"）
  • 指定评判标准（如"确保每个建议都附带具体的代码示例"）

原则三：结构化组织

对于复杂 Prompt，使用 Markdown 标题、列表、XML 标签等方式划分逻辑区域。OpenAI 官方推荐的标准结构为[Prompt engineering]：

  1. Identity（身份） ：模型的角色定位和目标
  2. Instructions（指令） ：具体的行为规则
  3. Examples（示例） ：输入-输出样本
  4. Context（上下文） ：额外的参考资料或数据

这种分层结构让模型更容易识别每部分的作用，也便于你后续迭代优化。

原则四：渐进式约束

先定义「做什么」，再定义「怎么做」，最后定义「不能做什么」。约束条件应从宽到严，让模型有明确的行为边界。

# 指令
1. 分析用户提供的代码，找出潜在的性能问题
2. 为每个问题给出优化建议和代码示例
3. 使用中文输出，技术术语保留英文

# 约束
- 不要修改原有的业务逻辑
- 不要引入新的第三方依赖
- 输出不超过 2000 字

原则五：提供评估锚点

告诉模型什么是「好的」输出。可以通过示例、评分标准、检查清单等方式建立评判基准。OpenAI 对 GPT-5 的提示指南中特别强调——对于高级模型，甚至建议让模型先生成评估标准（evaluation rubric），再基于标准执行任务。

原则六：迭代优化

没有一次就完美的 Prompt。提示词工程是一个"写→测→改"的循环过程。建议：

  • 从最简单的 Prompt 开始
  • 观察输出，定位问题
  • 每次只调整一个变量
  • 记录每次修改和效果变化

四、Prompt 设计常见模式

4.1 角色设定（Role Prompting）

通过赋予模型一个特定角色，引导其以该角色的知识背景和沟通风格回答问题。

你是一名资深的 Kubernetes 运维工程师，拥有 10 年集群管理经验。
用户会向你咨询 K8s 相关的运维问题。请用简洁、技术性的语言回答，
必要时给出 kubectl 命令示例。

注意要点：

  • 角色描述要具体（"资深 K8s 运维工程师"优于"技术专家"）
  • 角色设定放在 System Prompt / developer message 中，优先级更高
  • 不要给模型无法胜任的角色（如"你是法官，请做出有法律效力的裁决"）

4.2 思维链与逐步推理（Chain-of-Thought / Step-by-step）

要求模型展示推理过程，而非直接给出结论。这在复杂分析、数学运算、逻辑推理等场景下尤为有效。

请逐步分析以下问题，在给出最终答案前，先列出你的推理过程：

问题：一家公司去年利润 1200 万，今年上半年利润同比增长 20%，
下半年同比增长 30%。假设去年上下半年利润相等，今年全年利润是多少？

适用场景：数学计算、逻辑推理、多因素决策、代码调试。

关键区别：

  • 对于 GPT 等标准模型，需要你在 Prompt 中主动要求"逐步推理"
  • 对于 o1/o3 等推理模型（Reasoning Models），模型内置了思维链机制，你只需给出高层目标，无需要求"step by step"——反而过度细化指令可能干扰其推理过程

4.3 示例驱动（Few-shot）

在 Prompt 中给出几组输入-输出示例，让模型学习期望的模式。这是最实用的技术之一，尤其适合需要特定输出格式或分类标准的场景[Prompt engineering]。

# 任务：判断客户评价的情感倾向

# 示例

<review id="1">
音质非常棒，佩戴也很舒服，强烈推荐！
</review>
<label id="1">正面</label>

<review id="2">
电池续航还行，但耳垫质量一般。
</review>
<label id="2">中性</label>

<review id="3">
客服态度极差，再也不会购买。
</review>
<label id="3">负面</label>

# 请分析以下评价

<review id="input">
产品功能齐全，但说明书写得太差，折腾了半天才搞清楚怎么连接。
</review>

设计要点：

  • 示例应覆盖不同类型的情况（正面/负面/边界情况）
  • 保持示例格式一致
  • 3-5 个示例通常足够；更多示例可能导致 token 浪费
  • 使用 XML 标签包裹示例，有助于模型区分示例内容和指令内容

4.4 模板化 Prompt

将 Prompt 设计为带有占位符的模板，便于在不同场景下复用。

# 代码审查模板

## 角色
你是一名高级软件工程师，负责审查团队成员的代码提交。

## 审查对象
- 编程语言：{{language}}
- 代码片段：
{{code}}

## 审查要求
1. 检查是否存在安全漏洞（如 SQL 注入、XSS）
2. 评估代码可读性和命名规范
3. 检查边界条件和错误处理
4. 提出性能优化建议

## 输出格式
按严重程度从高到低排列，每个问题包含：
- 严重程度标记（高/中/低）
- 问题描述
- 具体代码行
- 改进建议和示例代码

这种模板方式在 OpenAI 的 Responses API 中已被产品化——通过 Dashboard 创建可复用的 Prompt 模板，在 API 调用时通过变量注入动态内容。

4.5 约束与边界

明确规定模型应该和不应该做的事情。

# 必须遵守的规则
- 所有日期格式使用 YYYY-MM-DD
- 引用数据时必须标明来源
- 不确定的内容标注 [待确认]

# 禁止事项
- 不要编造不存在的 API 或参数名
- 不要在回答中包含个人观点或主观评价
- 不要输出任何 Markdown 代码块之外的代码

五、Skill 设计与使用

5.1 Skill 与普通 Prompt 的本质区别

维度普通 PromptSkill
生命周期一次性使用持久化存储、反复调用
复用性需手动复制粘贴通过命令名直接调用
参数化每次手动修改输入通过变量占位符自动替换
作用域仅当次对话可个人/项目/组织级别共享
运行环境在当前上下文执行可配置工具权限、独立子代理
可维护性分散在各个对话中版本化管理、可迭代升级

5.2 将复杂任务拆解为可复用的 Skill

好的 Skill 设计遵循「单一职责原则」——每个 Skill 只做一件明确的事。以下是拆解思路：

识别重复模式：如果你发现自己经常向模型发送类似结构的提示词，那就是封装 Skill 的信号。

按职责拆分：

一个 Skill 做所有事（不推荐）：
/process-pr → 审查代码 + 运行测试 + 生成变更日志 + 合并分支

拆分为多个 Skill（推荐）：
/review-code → 审查代码质量
/run-tests → 执行测试套件
/changelog → 生成变更日志
/merge-pr → 合并并清理分支

考虑组合性：设计的 Skill 应能相互配合，像积木一样组合使用。

5.3 Skill 的输入/输出约定与参数化

一个标准的 Skill 结构包含以下部分（以 Claude Code 的 SKILL.md 格式为例）[Extend Claude with skills]：

---
name: skill-name             # Skill 名称，用于 /slash 命令调用
description: >               # 描述：模型据此判断何时自动加载
  一句话说明 Skill 做什么，以及在什么场景下使用。
disable-model-invocation: false  # 是否禁止模型自动调用
allowed-tools: Read, Grep, Bash  # 允许使用的工具列表
context: fork                    # 是否在独立子代理中运行
---

# 正文：具体的执行指令

接收参数 $ARGUMENTS，按以下步骤执行：

1. 第一步...
2. 第二步...
3. 输出结果，格式为...

参数传递方式：

  • $ARGUMENTS：获取全部参数文本
  • $ARGUMENTS[0]、$ARGUMENTS[1] 或简写 $0、$1：按位置获取参数
  • 通过 !command 语法注入动态上下文（如 Git diff、系统信息等）

5.4 Skill 的调用模式

手动调用：用户通过 /skill-name [参数] 命令显式触发。

自动调用：模型根据 Skill 的 description 判断当前对话是否匹配，自动加载并执行。

子代理模式：设置 context: fork 后，Skill 在独立的上下文中运行，不受当前对话历史影响，适合需要隔离执行的任务（如深度研究、大规模代码变更）。

权限控制表：

配置用户可调用模型可调用适用场景
默认（无特殊配置）是是通用知识、常规任务
disable-model-invocation: true是否部署、发布等有副作用的操作
user-invocable: false否是后台知识库、上下文补充

5.5 Skill 的存储与分享

级别路径适用范围
个人级~/.claude/skills/<name>/SKILL.md你的所有项目
项目级.claude/skills/<name>/SKILL.md仅当前项目
组织级通过企业管理配置下发组织内所有用户
插件级<plugin>/skills/<name>/SKILL.md启用该插件的环境

六、高效使用模型的实战策略

6.1 迭代优化 Prompt 的方法

第一步：从粗到细

先写一个简单的 Prompt，观察输出，再逐步加约束。

V1: "帮我写个 Python 爬虫"
V2: "用 Python requests 库写一个爬虫，抓取某新闻网站的标题和发布时间"
V3: "用 Python requests + BeautifulSoup 写一个爬虫，抓取 example.com 
     的新闻列表页，提取每条新闻的标题、URL、发布时间，输出为 CSV 格式。
     需要处理分页（共 5 页），添加请求间隔避免被封，包含异常处理。"

第二步：从结果逆推约束

如果模型输出不符合预期，分析具体哪里不对，针对性地加约束：

  • 输出太长？→ 加字数限制
  • 格式不对？→ 加格式模板
  • 信息不准？→ 加参考资料和"不确定时请标注"的要求
  • 风格不对？→ 加角色设定和语气要求

第三步：用评估驱动迭代

为你的 Prompt 建立简单的评估标准，而非凭感觉判断好坏。例如对于一个文档生成 Prompt，评估项可以包括：

  • 是否涵盖了所有要求的章节？（完整性）
  • 每个章节是否包含具体示例？（具体性）
  • 输出长度是否在指定范围内？（格式遵循）
  • 是否存在明显的事实错误？（准确性）

6.2 如何给模型提供上下文

直接嵌入：将参考资料、代码片段、文档内容直接放入 Prompt。适合内容较短（几千 token 以内）的场景。使用 XML 标签标记边界：

<reference_document>
这里是参考文档的完整内容...
</reference_document>

基于上述参考文档，请回答以下问题：...

检索增强（RAG） ：先通过搜索、数据库查询等方式获取相关内容，再将结果注入 Prompt。适合大规模知识库场景。

文件上传：多数模型平台支持上传文件（PDF、代码文件等），模型可以直接读取并引用。

关键原则：

  • 将最重要的上下文放在 Prompt 的开头或结尾——模型对首尾内容的注意力更强
  • 重复使用的固定内容放在开头，有助于触发缓存机制（Prompt Caching）降低成本[Prompt engineering]
  • 明确告诉模型上下文的用途（"以下是产品文档，请仅基于此文档回答"）

6.3 多轮交互工作流设计

对于复杂任务，与其一次塞入所有需求，不如设计分阶段的工作流：

阶段 1：规划
"我需要重构 UserService 类，请先分析当前代码结构，
列出你认为需要改进的 3-5 个方面。"

阶段 2：确认
"你列出的第 2 和第 4 点很关键，请针对这两点给出详细的重构方案。"

阶段 3：执行
"方案 LGTM，请开始执行重构，先从解耦数据库访问层开始。"

阶段 4：校对
"请检查重构后的代码是否通过所有现有测试，
并列出可能影响的下游模块。"

这种方式的优势在于：

  • 每一步都可以人工审核和纠偏
  • 模型的每次输出都有明确的焦点
  • 降低了单次交互的复杂度

6.4 不同任务类型的专用技巧

写作类任务：

  • 先让模型输出大纲，确认后再展开
  • 提供目标读者画像（"面向无技术背景的产品经理"）
  • 给出风格参考（"类似 Stripe 的技术博客风格"）
  • 分章节生成，避免一次输出过长导致质量下降

代码类任务：

  • 指定编程语言、框架版本、代码规范
  • 要求包含注释和错误处理
  • 提供现有代码上下文（相关函数签名、数据模型）
  • 要求模型生成测试用例来验证正确性

分析类任务：

  • 提供原始数据，而非让模型猜测
  • 明确分析维度和输出格式
  • 要求模型区分"事实"和"推测"
  • 对数值计算要求模型展示计算过程

产品策划类任务：

  • 提供业务背景和目标用户画像
  • 使用结构化框架（如 MECE、用户故事模板）
  • 要求同时给出方案的优缺点和风险

七、常见误区与反例

误区一：模糊指令，目标不明确

较差："帮我优化一下这个项目"

优化："对以下 Node.js 项目的 API 路由层进行性能优化，
重点关注数据库查询的 N+1 问题和未使用的中间件。
请逐个文件分析，给出优化前后的代码对比。"

模糊指令让模型不知道"优化"的标准是什么——性能？可读性？安全性？代码量？

误区二：一次性塞入过多需求

较差："帮我写一个电商网站，包括用户注册登录、商品列表、购物车、
支付、订单管理、评价系统、后台管理、数据统计，
要用 React + Node.js + PostgreSQL，支持响应式..."

优化：将需求拆分为多轮交互：
轮次 1：确定技术栈和整体架构
轮次 2：设计数据模型
轮次 3：逐模块实现

误区三：没有给出输出格式

不指定格式，模型每次输出的结构可能不同，后续处理困难。

较差："分析这份销售数据"

优化："分析这份销售数据，输出为以下 JSON 格式：
{
  'summary': '一句话总结',
  'top_products': ['产品名', ...],
  'trend': 'up|down|stable',
  'recommendations': ['建议 1', '建议 2', ...]
}"

误区四：过度依赖模型推断

较差："按之前说的那种格式整理一下"
（模型可能已经不记得"之前"的上下文）

优化：每次交互都提供完整的格式要求，或引用具体的示例。

误区五：忽视模型的局限性

大语言模型可能会：

  • 产生幻觉（Hallucination） ：自信地编造不存在的事实、API、论文
  • 数学计算不可靠：复杂运算应使用代码执行而非让模型心算
  • 知识有截止日期：关于最新事件和数据需要通过工具搜索
  • 对长上下文注意力不均：中间位置的信息更容易被忽略

正确做法是：信任但验证。将模型作为高效的初稿生成器和思维辅助工具，但关键信息始终需要人工校对。

八、实用示例

示例一：技术文档生成

需求：为一个内部 SDK 的新功能编写技术文档。

较差的 Prompt：

帮我写个 SDK 文档。

问题分析：没有指定是哪个 SDK、什么功能；没有明确文档的目标读者；没有给出结构和格式要求；没有提供 SDK 的实际接口信息。

优化后的 Prompt：

# 任务
为我们的内部 Python SDK 的新增「文件批量上传」功能编写技术文档。

# 目标读者
后端开发工程师，熟悉 Python，对 SDK 有基本了解。

# 功能接口
class FileUploader:
    def batch_upload(
        self, 
        files: List[str],          # 文件路径列表
        bucket: str,               # 目标存储桶
        max_concurrency: int = 5,  # 最大并发数
        on_progress: Callable = None  # 进度回调
    ) -> BatchUploadResult

# 文档结构要求
1. 功能概述（2-3 句话）
2. 快速开始（最简单的调用示例）
3. 参数说明（表格形式，含类型、默认值、说明）
4. 完整示例（含错误处理和进度回调）
5. 注意事项（并发限制、文件大小限制等）
6. 常见问题 FAQ（3 条）

# 格式约束
- 使用 Markdown 格式
- 代码示例使用 Python，附带注释
- 总长度 800-1200 字

优化点：提供了完整的接口定义作为上下文，明确了读者画像、文档结构、格式约束，模型可以直接产出可用的文档。

示例二：代码重构

需求：重构一段存在性能问题的数据库查询代码。

较差的 Prompt：

这段代码太慢了，帮我优化。

问题分析："太慢"没有量化——是查询耗时？还是 CPU 占用？没有提供性能基准和目标，没有说明技术栈和约束条件。

优化后的 Prompt：

# 任务
重构以下 Django ORM 查询代码，解决 N+1 查询问题。

# 当前问题
此视图函数在返回 100 条订单时，触发了约 300 次 SQL 查询（
通过 Django Debug Toolbar 确认），页面加载时间 > 3 秒。

# 当前代码
def get_orders(request):
    orders = Order.objects.filter(status='active')
    result = []
    for order in orders:
        result.append({
            'id': order.id,
            'customer': order.customer.name,
            'items': [item.product.name for item in order.items.all()],
            'total': sum(item.price for item in order.items.all()),
        })
    return JsonResponse(result, safe=False)

# 优化目标
- SQL 查询次数降至 5 次以内
- 保持返回数据结构不变
- 使用 Django ORM（不要写原生 SQL）

# 输出要求
1. 优化后的完整代码
2. 每处修改的简要说明
3. 预期的查询次数和性能改善

示例三：数据分析

需求：对季度销售数据进行趋势分析。

较差的 Prompt：

看看这些数据有什么趋势。

优化后的 Prompt：

# 任务
分析以下 2025 年 Q1 各产品线月度销售数据，输出趋势分析报告。

# 数据（单位：万元）
| 产品线 | 1 月 | 2 月 | 3 月 |
|--------|------|------|------|
| A 产品 | 320  | 285  | 410  |
| B 产品 | 150  | 180  | 175  |
| C 产品 | 520  | 490  | 480  |

# 分析要求
1. 计算每个产品线的季度环比增长率
2. 识别增长最快和下滑最快的产品线
3. 基于数据给出 Q2 的初步预判（标注为 [推测]）
4. 给出 2-3 条可操作的业务建议

# 输出格式
## 数据概览 （表格形式，含汇总计算）
## 趋势分析 （分产品线逐个分析）
## Q2 预判 [推测]
## 行动建议

示例四：产品需求梳理

需求：将一个模糊的产品想法梳理为结构化需求。

较差的 Prompt：

我想做一个任务管理工具，帮我写个需求文档。

优化后的 Prompt：

# 任务
帮我将以下产品想法梳理为结构化的需求文档（PRD 初稿）。

# 产品想法
我们团队（15 人研发团队）需要一个轻量级任务管理工具，
替代目前用 Excel 跟踪项目进度的方式。核心痛点：
- 任务状态更新不及时
- 缺少跨项目的全局视图
- 没有提醒和到期追踪

# 约束条件
- 第一版 MVP，2 人前端 + 1 人后端，4 周内上线
- 必须支持移动端访问（H5 优先）
- 需与现有飞书系统集成通知

# 要求的输出结构
1. 产品概述（目标用户、核心价值）
2. 用户故事列表（按优先级 P0/P1/P2 分级）
3. 核心功能清单（表格形式：功能名称/描述/优先级/预估工作量）
4. 非功能需求（性能、安全、兼容性）
5. MVP 范围建议（哪些功能纳入第一版，哪些延后）
6. 已知风险和待决事项

示例五：Skill 设计完整示例——长文档总结

以下是一个用于「长文档总结」的 Skill 完整设计：

文件路径：~/.claude/skills/summarize-doc/SKILL.md

---
name: summarize-doc
description: >
  总结长文档的核心内容。当用户要求总结、概括、提炼文档要点时使用。
  支持技术文档、会议纪要、研究报告等多种文档类型。
allowed-tools: Read, Grep, Glob
---

Skill 正文：

# 长文档总结 Skill

## 接收参数
- $ARGUMENTS[0]：文档路径或 URL
- $ARGUMENTS[1]（可选）：总结风格，可选值为 brief / detailed / executive

## 执行步骤
1. 读取文档：打开 $0 并读取全部内容
2. 结构分析：识别文档的章节结构和主要内容块
3. 核心提取：提取每个部分的关键信息
4. 总结生成：根据指定风格生成总结

## 输出格式
文档标题：[原文标题]
文档类型：[技术文档/会议纪要/研究报告/其他]
字数：原文约 X 字 → 总结约 Y 字

核心要点（编号列表）
章节摘要（表格：章节 / 核心内容 / 关键数据）
关键结论 / 待办事项
注意事项（风险、限制或待确认事项）

## 质量要求
- 总结不超过原文的 20%
- 关键数字和结论必须准确引用，不得推测
- 如有不确定的内容，标注 [原文未明确]
- 不添加原文没有的观点或解读

调用方式：/summarize-doc docs/architecture-v2.md detailed

设计亮点：

  • 参数化设计：支持不同文档路径和总结风格
  • 结构化输出：表格 + 列表的组合，便于快速浏览
  • 质量防护：明确禁止推测，要求标注不确定内容
  • 工具权限限制：仅允许读取操作，不会误改文件

九、总结与推荐实践清单

以下 checklist 可用于快速检验你编写的 Prompt 或 Skill 是否符合最佳实践。

Prompt 编写检查清单

  • 目标明确：是否用一句话能说清楚这个 Prompt 要模型做什么？
  • 角色定义：是否指定了模型应扮演的角色或具备的专业背景？
  • 上下文充分：是否提供了模型完成任务所需的全部背景信息？
  • 指令具体：是否将模糊的描述替换为了具体的、可执行的步骤？
  • 格式约定：是否明确了输出的格式（JSON、Markdown、表格等）？
  • 约束边界：是否说明了"不要做什么"和"限制条件"？
  • 示例辅助：对于格式要求高或分类判断类任务，是否提供了 few-shot 示例？
  • 评估标准：是否定义了"什么算好的输出"的判断依据？
  • 分段合理：是否使用 Markdown 标题 / XML 标签对 Prompt 做了结构化分区？
  • 长度可控：是否在上下文窗口限制内，合理分配了指令和上下文的 token？

Skill 设计检查清单

  • 单一职责：这个 Skill 是否只做一件明确的事？
  • 描述准确：description 是否清楚说明了使用场景，让模型能准确匹配？
  • 参数设计：输入参数是否合理，是否有默认值和可选参数？
  • 输出约定：是否定义了清晰的输出格式？
  • 权限最小化：allowed-tools 是否只包含了必要的工具？
  • 调用控制：是否根据场景正确设置了 disable-model-invocation？
  • 幂等安全：多次执行同一 Skill 是否不会产生副作用？
  • 错误处理：是否考虑了输入异常或工具执行失败的情况？
  • 文档化：SKILL.md 是否清晰到让团队其他成员直接使用？

日常使用习惯清单

  • 先想再问：在发送 Prompt 前，花 30 秒想清楚你真正想要什么
  • 逐步迭代：从简单开始，逐步增加复杂度，而非一次到位
  • 验证输出：对模型的事实性陈述、数值计算、代码逻辑保持怀疑，关键内容人工核查
  • 善用工具：充分利用模型的搜索、代码执行、文件操作等工具能力，而非仅靠文本生成
  • 记录经验：将效果好的 Prompt 模板和 Skill 沉淀下来，形成团队知识库
  • 跟进更新：不同模型版本的表现可能不同，定期评估和调整你的提示词策略

提示词工程不是一次性任务，而是一项持续优化的技能。随着你对模型能力边界的理解越来越深入，你的提示词也会越写越精炼、越来越有效。将模型视为一个能力极强但需要精确指令的协作者——你给出的指令质量，直接决定了协作的成效。

avatar
文章
阅读
粉丝