提示词模板与框架 入门教程

写好提示词，你的 AI 产出质量就直接取决于你输入的信息质量。提示词模板与框架并非限制创造力的模板，而是一套经过验证的信息组织方法，能帮助你在几十字到几百字的输入中，稳定地让模型理解你的意图，减少反复试错。

本教程将从核心认知入手，为你提供一套可以直接套用的框架、一个完整的工作示例、一份常见错误的检查清单，最后回答几个最常被问的问题。读完你会发现，多数“AI 不听话”的情况，其实是提示词的结构缺少了关键零件。

下一步：claude 角色扮演提示词怎么写、claude 提示词模板

核心认知：框架的本质是“为模型搭建脚手架”

大语言模型（如 Claude、GPT 等）的能力下限取决于你的提示词。一个模糊的“写篇文章”和结构清晰的“写一篇针对初级工程师的 800 字 Markdown 教程，包含定义、步骤、示例、关键注意点”相比，后者能让模型直接命中你想要的目标区域。

模板与框架旨在解决以下常见问题：

• 意图模糊：只说“分析数据”，未明确分析维度或输出格式。
• 上下文缺失：模型不了解目标用户、场景限制或现有已知信息。
• 结构松散：用一整段自然语言说明需求，模型容易遗漏中间的关键约束。

一个通用的提示词框架可以抽象为以下 5 个要素：

要素	对应问题	简单示例
角色	你希望模型以什么身份回答？	你是一位资深数据分析师
任务	核心动作是什么？	请分析这组销售数据
上下文	任务的前提条件或已知事实？	这是 2024 年 Q3 的区域销售额
格式	输出长什么样？	返回一个表格，列名为「月份」「销售额」
约束	有什么明确不能做或必须遵守的？	不要使用专业术语，用 500 字以内

新手最容易跳过上下文和约束，导致输出虽看似合理，但实际应用效果不佳。

开始前的准备工作

动手写之前，请确认已具备以下信息，否则即使套用框架也效果有限：

• 明确的目标输出：你要一篇文档、一段对话、一段代码，还是一份分析？目标决定框架的侧重点。
• 示例或参考（非必需，但极为有效）：即使只有一个类似的输出样例，将其复制进去供模型参考，产出贴合度会显著提升。
• 版本和模型信息：Claude Sonnet 3.5 与 Claude Opus 4.5 对提示词长度的敏感度不同。若提示词超过 300 字，可考虑拆分为多轮对话，或在第一轮明确说明“分两步完成：第一步理解我的需求，第二步给出结构”。
• 浏览器或 API 状态正常：在网页端操作时，刷新页面可能导致部分编辑中的上下文丢失。长提示词建议先复制到记事本再粘贴。

操作步骤：从零构建一个有效的提示词框架

以下是一个可复现的操作流程，按顺序执行，你会看到输出质量明显提升。

第一步：先写「任务」一句话

这是提示词的核心。明确写出“动词 + 对象 + 目的”。例如：

“请将以下会议记录整理为一封发给全公司的一页周报邮件。”

这一步不宜过长，10-15 字即可。写到这里先停下来，自问：模型是否清楚输出格式、语气和受众？通常答案是否定的。

第二步：补充「角色」与「上下文」

角色帮助锁定专业语气，上下文帮助模型排除无关信息。直接将其加在任务后面，通过换行或短分段来区分。

你是一位负责内部沟通的行政主管。这封周报的读者是公司 300 名员工，需要简洁、信息明确。

以下是今天下午的会议记录（原始内容）：[粘贴内容]

注意：若上下文过长（超过 100 字），应将其放在任务的前面，因为模型对提示词的开头和结尾权重更高。

第三步：添加「格式」模板

这是最多新手遗漏的环节。你可以直接贴出想要的输出结构。

请严格按照以下格式输出：

• 标题： [一句话总结]
• 本周要点： 3-5 条要点，每条不超过 50 字
• 下周待办： 用表格列出「部门」「事项」「截止日」

提供格式时，关键是给模型一个可模仿的骨架，而不是开放式的“写得好一点”。

第四步：加入约束

约束用于抵消模型的默认行为。例如，模型喜欢使用“首先、其次、最后”，若不需要，则明确禁止。

约束：不要使用“首先/其次/最后”这类过渡词。不要输出任何导语或总结，直接输出正文。全文总字数控制在 300-400 字之间。

第五步：输出前检查

写完后，用以下检查清单过一遍：

• 任务动词是否唯一？“分析一下、写一下、总结一下”等模糊词，可替换为“列出前三个问题”、“逐条对比”或“改写成三段式”。
• 是否预设了输出样本？ 即使是“参考下面这个已有的周报格式”，也请复制进去。
• 是否有隐性遗漏？ 例如，你要求表格但未说明表头，模型会自行猜测。
• 是否有矛盾指令？ 同时出现“详细说明”和“控制在 200 字内”时，模型会优先满足后者。

完整工作示例：从混乱到清晰

以下是一个完整的工作示例，场景是用 Claude 分析用户反馈邮件。这里展示“修改前”和“修改后”两组提示词，以及对应的预期产出差异。

示例背景

你需要从 6 条用户反馈中提取核心问题，用表格输出给产品经理。

修改前提示词（常见新手写法）：

分析下面的用户反馈，告诉我主要有哪些问题。

反馈内容：

1. 我想改密码，但找不到在哪里改。
2. 手机端老是闪退，iOS 17 系统。
3. 能不能加个搜索功能？
4. 客服回复太慢了，等了 2 天。
5. 昨晚系统维护没提前公告，我东西没保存。
6. 发票金额弄错了，想重开。

模型可能输出： 一段自然语言描述，如“用户反馈的问题主要有：找密码困难、闪退、缺少搜索功能、客服慢、没有提前通知维护、发票问题。”——虽然看似有用，但无法直接投入工作。

修改后提示词（基于框架）：

你是一位用户研究分析师。请基于以下 6 条用户反馈，输出一份面向产品经理的《反馈归类表》。

上下文： 这些反馈来自最近一周的 app 内提交通道。所有反馈均来自已登录用户。

格式要求：

问题类别	具体描述	影响范围评估（L/M/H）	建议优先级
[类别]	[描述]	[L/M/H]	[P0/P1/P2]

• 表格不要改列名，只填写数据。
• “影响范围评估”参考“是否影响核心功能”及“是否多人反馈”。例如，闪退影响登录后的核心使用，评为 H。
• 若一条反馈属于多个类别，只归入主类别，在描述中注明副类别。

约束：

• 不要输出任何表格以外的内容（不要导语、不要分析段落）。
• 若反馈信息不足以判断优先级，写“数据不足”而非猜测。

预期产出（表格形式）：

问题类别	具体描述	影响范围评估	建议优先级
帐号安全	用户找不到密码修改入口	M	P1
客户端稳定性	iOS 17 下频繁闪退	H	P0
功能缺失	用户需要内容搜索能力	L	P2
客服流程	客服响应延迟至 2 天	M	P1
沟通通知	维护未提前公告，用户数据丢失风险	H	P0
计费差错	发票金额错误，用户申请重开	M	P1

对比两版输出：第二版可直接粘贴到产品看板中，无需手动整理。

边缘情况示例

当输入数据明显不足时： 如果只有 1 条反馈（“我用不了”），约束中的“若反馈信息不足以判断优先级，写‘数据不足’”会发挥作用。模型不会强行给出 M 或 H，而是填写“数据不足”，这对生产环境而言是更安全的做法。写提示词时，务必为这类边缘情况预留处理策略。

常见错误与排查

很多时候，问题并非出在模型“笨”，而是提示词本身存在缺陷。以下是三个最常见的问题板块。

错误 1：省略了操作环境/版本信息

模型的训练数据有截止日期。如果你问“当前 Mac