很多人写 Prompt 的方式，本质上是在许愿：
帮我写一个方案。
帮我优化一下。
帮我分析这个问题。
这些话不是完全不能用，但它们给模型的信息太少。模型不知道你要解决什么问题、给谁看、受什么限制、什么结果才算好，所以只能按概率补全一个“看起来像答案”的东西。
写好 Prompt 的关键不是掌握某种神秘咒语，而是把任务讲清楚。更准确地说，Prompt 不是一句命令，而是一份迷你任务说明书。
一、Prompt 到底解决什么问题
大模型不是传统软件函数。你不能只给它一个函数名，就期待它稳定输出你想要的结果。传统函数的输入输出通常是明确的：
输入：两个数字
处理：相加
输出：一个数字
但大模型任务往往不是这样。比如“帮我写方案”，里面至少包含这些隐藏问题：
- 写给谁看？
- 方案是为了汇报、执行、融资，还是内部讨论？
- 需要多长？
- 是要发散想法，还是要落地执行？
- 能不能编造没有给出的信息？
- 输出是 Markdown、表格、邮件，还是 PPT 大纲？
- 什么叫“好方案”？
如果这些条件不写出来，模型就会自己猜。它可能猜对，也可能猜偏。所以 Prompt 的核心作用，不是“控制模型听话”，而是减少模型需要自行猜测的空间。一个好 Prompt 至少要解决三件事：
1. 让模型知道要完成什么任务
2. 让模型知道应该基于什么信息完成任务
3. 让模型知道什么样的答案才算合格
这也是为什么同一个模型，在不同人手里效果差距很大。差距不只来自模型能力，也来自任务说明是否清楚。
二、好 Prompt 的通用公式
一个实用的 Prompt 可以拆成七个部分：
好 Prompt = 目标 + 背景 + 输入材料 + 约束 + 输出格式 + 判断标准 + 迭代方式
对应到实际写法，可以用下面这个模板：
你是【角色/专家身份】。
我的目标是：【我想达成什么】。
背景信息：
【业务背景、受众、场景、限制条件】
输入材料：
"""
【粘贴资料、文档、代码、需求、问题】
"""
请完成：
1. 【具体任务 1】
2. 【具体任务 2】
3. 【具体任务 3】
要求：
- 【语气/风格】
- 【长度/深度】
- 【不要做什么】
- 【必须考虑什么】
- 如信息不足，请先列出关键假设，再继续完成，不要编造事实。
输出格式：
【表格 / JSON / Markdown / 分步骤 / 邮件 / 方案大纲】
质量标准：
- 结论要可执行
- 不要空泛
- 每条建议都说明原因
- 给出优先级或下一步行动
这个模板看起来比一句话长，但它不是为了“显得专业”。它的作用是把模型最容易猜错的地方提前写清楚。实际使用时，不需要每次都把七项写满。简单任务可以简化，复杂任务就要写完整。
三、日常最推荐的万能骨架
如果只记一个模板，可以记这个版本：
你是【某领域专家】。
请基于以下信息，帮我完成【具体任务】。
背景：
【为什么要做这件事、给谁看、当前问题是什么】
资料：
"""
【粘贴材料】
"""
请按以下步骤处理：
1. 先概括核心问题
2. 再指出关键矛盾或机会
3. 给出具体建议
4. 最后给出可执行的下一步
要求：
- 用中文
- 直接、实用，不要套话
- 每个建议都说明原因
- 如果有不确定信息，请标注“不确定”并说明需要补充什么
输出格式：
## 核心结论
## 关键分析
## 行动建议
## 风险与补充信息
这个骨架适合很多常见任务：
- 写方案
- 分析文档
- 做商业判断
- 复盘项目
- 写邮件
- 改简历
- 做学习计划
- 分析代码
- 整理会议纪要
它背后的逻辑很简单：先限制身份和任务，再给背景和资料，最后明确处理步骤、输出格式和质量标准。
四、坏 Prompt 和好 Prompt 的差别
看一个具体例子。
如果你写：
帮我写一个营销方案。
模型并不知道产品是什么、用户是谁、预算多少、目标是什么、可用渠道有哪些，也不知道你要的是战略思路还是执行计划。更好的写法是：
你是一个擅长 B2B SaaS 增长的营销顾问。
我的产品是一个面向中小企业的 AI 客服工具，目标用户是 20-200 人规模的电商公司。我们的目标是在 3 个月内获得 300 个试用客户，预算 10 万元人民币。
请帮我设计一份营销方案。
要求：
- 按“获客渠道 / 执行动作 / 预算 / 预期效果 / 风险”输出
- 重点考虑低成本、高转化渠道
- 不要写泛泛的品牌宣传，要能落地执行
- 给出前 30 天的行动计划
输出格式：
1. 总体策略
2. 渠道组合表
3. 30 天执行计划
4. 风险与备选方案
这两个 Prompt 的区别不在于第二个更长，而在于第二个告诉模型：
要解决什么问题
目标用户是谁
资源限制是什么
输出应该长什么样
哪些内容不要写
方案如何判断是否可用
很多 Prompt 效果不好，不是因为模型不会，而是因为你把任务交代得像一句临时聊天。
五、写好 Prompt 的 7 个关键点
1. 任务要具体，不要只说“优化”
“优化”这个词很危险，因为它没有标准。不要这样写：
帮我优化这段文案。
改成：
请把下面这段文案改得更适合小红书风格，要求：
- 开头有吸引力
- 语言口语化
- 保留原意
- 字数控制在 300 字以内
- 结尾加一个引导评论的问题
当你说“优化”时，模型不知道要优化转化率、表达清晰度、语气、结构，还是长度。把“优化方向”写出来，结果才会更接近你的目标。
2. 告诉模型受众是谁
同一个内容，写给老板、客户、程序员、新手、投资人看，表达方式完全不同。比如：
请把这段技术说明改写成给非技术老板看的版本，要求通俗、简短、突出业务影响。
这比“解释一下这段技术”更清楚。受众决定信息密度、术语使用、例子选择和表达重点。不给受众，模型只能用默认读者来写。
3. 给输出格式
不要让模型“随便写”。如果你需要可复制、可执行、可汇报的结果，就要提前规定结构。例如：
请用 Markdown 表格输出，列包括：
- 问题
- 原因
- 影响
- 解决建议
- 优先级
输出格式越明确，后续整理成本越低。
4. 给例子，也就是 Few-shot
当你对风格、分类、格式要求很高时，给 1-3 个示例通常很有效。
请模仿下面的风格改写文案。
示例：
原文：我们的产品可以提升企业效率。
改写：别再让团队把时间浪费在重复劳动上了，把杂事交给工具，把精力留给增长。
现在请改写：
原文：【你的原文】
示例的价值在于，它比抽象描述更具体。你说“自然一点”“专业一点”，模型可能理解不一致；你给一个例子，边界就清楚很多。
5. 把资料和指令分开
当你粘贴长文、合同、代码、会议纪要时，最好用分隔符把资料包起来。
任务：请总结下面文档中的风险点。
文档：
"""
这里粘贴正文
"""
请只基于文档内容回答，不要补充外部信息。
这样可以降低模型把“资料内容”和“你的任务要求”混在一起的概率。对于 Claude，也可以使用 XML 风格标签：
<task>
请审阅合同，找出对乙方不利的条款。
</task>
<contract>
【粘贴合同】
</contract>
<output_format>
1. 高风险条款
2. 中风险条款
3. 建议修改文本
4. 需要律师进一步确认的问题
</output_format>
标签本身不是魔法，关键是它让结构更清楚。
6. 给判断标准，不要只给任务
比如你让模型写方案，要告诉它什么叫好方案。
一个好答案应满足：
- 有明确优先级
- 每条建议能在 2 周内开始执行
- 避免大而空的战略口号
- 尽量给出具体工具、步骤或示例
判断标准会影响模型的取舍。没有标准时，模型容易写出“完整但不可用”的答案；有标准时，它更容易往可执行结果收敛。
7. 复杂任务不要一次问完
不要这样：
帮我分析市场、设计产品、写商业计划书、做融资 PPT、顺便写销售话术。
这种 Prompt 把多个不同阶段的任务塞在一起，模型很容易每一部分都写一点，但都不够深入。更好的方式是分轮：
第一步：请先帮我分析目标用户和核心痛点，不要写完整方案。
输出：
1. 目标用户画像
2. 主要痛点
3. 现有替代方案
4. 我们可能的切入点
等模型完成后，再继续：
基于上面的用户画像，请继续设计产品 MVP 功能。
复杂任务应该被拆成“理解问题、生成初稿、审查改进、形成交付物”几个阶段，而不是一次性塞给模型。
六、不同模型的提示差异
Prompt 的底层原则相同，但不同模型有一些使用偏好。
GPT / ChatGPT
GPT 类模型通常适合明确任务、结构化输出、代码、分析、写作和工具调用。对这类模型来说，清晰的角色、具体步骤、输出格式和示例都很重要。
可以这样写：
你是一个资深产品经理。
请根据以下用户反馈，提炼产品问题，并按严重程度排序。
输出格式：
| 问题 | 证据 | 影响 | 建议 | 优先级 |
对于推理型模型，不一定要要求它展示完整思考过程。更好的要求是让它给出结论、依据和检查标准。
Claude
Claude 适合长文档阅读、深度分析、写作、代码和结构化推理。Claude 官方 Prompting 文档中，经常强调清晰指令、示例、结构化标签和 agentic system 的设计。如果输入内容很长，使用 XML 标签分块通常会更清楚：
<role>
你是一个资深法律助理。
</role>
<task>
请审阅合同，找出对乙方不利的条款。
</task>
<contract>
【粘贴合同】
</contract>
<output_format>
1. 高风险条款
2. 中风险条款
3. 建议修改文本
4. 需要律师进一步确认的问题
</output_format>
如果你希望 Claude 直接改写或直接生成，不要只问“你觉得怎么改”。可以明确写：
请直接重写这段内容，并在后面列出你做了哪些修改。
Gemini
Gemini 适合多模态、长上下文、资料整合、Google 生态相关任务，以及图像、视频、文档理解。Gemini 官方文档强调清晰、具体的指令；对于新一代模型，也更建议使用直接、简洁的提示，不要把 Prompt 写得过度复杂。处理长资料时，可以把材料放在前面，再在后面用“基于以上信息”锚定回答：
以下是项目资料：
"""
【粘贴长资料】
"""
基于以上信息，请回答：
1. 这个项目当前最大的 3 个风险是什么？
2. 哪些信息还不完整？
3. 如果下周要推进，最应该先做哪 5 件事？
请用表格输出。
这里需要注意：模型差异会随着版本更新变化。不要把某个模型的使用经验当成永久规则，最好在自己的任务上保留一套可复用测试样例。
七、几个高频任务模板
写作 / 改写
你是一个资深中文编辑。
请把下面内容改写成【风格】，用于【场景】，目标读者是【受众】。
原文：
"""
【粘贴原文】
"""
要求：
- 保留原意，不新增事实
- 语气：【专业 / 口语 / 犀利 / 温柔 / 商务】
- 字数：【范围】
- 结构更清晰
- 开头更吸引人
输出：
1. 改写版本
2. 修改思路
3. 可选标题 3 个
分析决策
你是一个商业分析顾问。
我现在要在以下几个方案中做选择：
A：【方案 A】
B：【方案 B】
C：【方案 C】
背景：
【业务背景、预算、目标、时间限制】
请从以下维度分析：
- 成本
- 收益
- 风险
- 执行难度
- 短期效果
- 长期价值
输出格式：
1. 对比表格
2. 推荐方案
3. 为什么不推荐其他方案
4. 未来 7 天行动计划
会议纪要
请把下面会议记录整理成高质量会议纪要。
会议记录：
"""
【粘贴内容】
"""
输出格式：
## 会议主题
## 核心结论
## 决策事项
## 待办事项
| 事项 | 负责人 | 截止时间 | 优先级 |
## 风险与未解决问题
要求：
- 不要编造没有出现的信息
- 如果负责人或时间未提及，写“未明确”
代码任务
你是一个资深【语言/框架】工程师。
目标：
【要实现什么功能 / 修复什么 bug】
当前代码：
【粘贴代码或文件路径】
请完成：
1. 找出问题原因
2. 给出修改后的代码
3. 解释关键改动
4. 给出测试用例
5. 指出潜在边界情况
要求：
- 不要只讲思路，要给可运行代码
- 如果信息不足，请列出你做的假设
学习辅导
你是一个擅长把复杂知识讲简单的老师。
我想学习：【主题】
我的水平：【零基础 / 有一点基础 / 中级】
目标：【考试 / 工作应用 / 面试 / 系统理解】
时间：【比如 14 天】
请输出：
1. 学习路线
2. 每天学什么
3. 每个阶段的练习题
4. 常见误区
5. 如何检验自己是否学会
要求：
- 不要堆概念
- 多举例
- 每天任务控制在【时间】以内
调研任务
你是一个行业研究员。
请帮我调研：【主题】
我关心：
- 市场规模
- 主要玩家
- 用户痛点
- 商业模式
- 风险
- 未来趋势
要求：
- 区分事实、推测和观点
- 对不确定信息明确标注
- 最后给出我的可行动建议
输出格式：
## 结论摘要
## 关键事实
## 趋势判断
## 机会点
## 风险
## 下一步建议
如果涉及最新信息、法规、价格、公司动态、模型能力、产品版本，最好明确要求模型联网检索并引用来源。模型自身知识可能过期，不能把它的回答默认当成实时事实。
八、让模型先复述任务
当任务复杂时，可以先让模型确认理解：
在正式回答前，请先用 5 条以内复述你对任务的理解，并列出你需要做出的关键假设。然后再给出正式答案。
这一步的价值不是增加仪式感，而是提前暴露歧义。如果模型复述出来的任务已经偏了，你可以在它正式输出前纠正。否则等它写完一大段，再让它重来，成本更高。
九、让模型用自检清单改进答案
很多任务不应该只生成一次。你可以让模型先产出，再按标准自检，最后生成改进版。
请先生成第一版答案。
然后用以下标准自检：
1. 是否具体？
2. 是否可执行？
3. 是否遗漏关键风险？
4. 是否有空话？
5. 是否符合输出格式？
最后给出改进后的最终版本。
这个方法适合方案、文案、代码解释、商业分析和学习计划。需要注意的是，自检清单最好来自你的真实判断标准。比如你做项目方案，检查项应该包括资源、成本、时间、风险、负责人、验收方式；你写代码，检查项应该包括边界条件、异常处理、测试和兼容性。
十、不建议滥用的写法
1. 过度要求展示完整思考过程
不建议写：
请一步一步展示你的全部思考过程。
更好的写法是：
请给出简洁的推理依据和结论，不需要展开冗长思考过程。
对大多数实际任务来说，你需要的是结论、依据、检查标准和可执行步骤，而不是一长串不可复用的思维流水账。
2. 同时塞太多互相冲突的要求
比如：
写得非常详细，但不要超过 100 字；要专业严谨，但要像小红书；要有数据，但不要联网。
这类 Prompt 会让模型左右为难。如果确实有多个要求，要明确优先级：
优先级：
1. 准确性
2. 可执行性
3. 简洁性
4. 文风
3. 只要求“更好”，不给标准
不要只写：
让这个方案更好。
改成：
请从以下角度改进这个方案：
- 是否能落地
- 成本是否过高
- 是否有明确负责人
- 是否有时间计划
- 是否能衡量效果
“更好”不是标准。可落地、成本合理、责任明确、能衡量，才是标准。
十一、推荐的三轮工作流
实际使用大模型时，可以按三轮推进。
第一轮，让模型理解和拆解：
请先分析这个任务应该怎么做，列出步骤和需要补充的信息。
第二轮，让模型产出初稿：
基于上面的分析，请生成第一版完整结果。
第三轮，让模型审查和优化：
请站在【老板/客户/用户/评审专家】角度审查这份结果，指出问题并给出改进版。
这个工作流适合复杂任务。它的价值是把“直接要答案”变成“先对齐问题，再生成答案，再检查答案”。
十二、一个终极通用 Prompt
最后给一个可以直接复制改造的版本：
你是一个经验丰富的【领域】专家。
我的目标是：
【写清楚你想达成什么】
背景：
【写清楚场景、受众、限制、已有信息】
输入：
"""
【粘贴资料】
"""
请你完成：
1. 先判断这个任务的核心问题是什么
2. 再给出结构化分析
3. 最后给出可执行方案
要求：
- 不要空泛
- 不要编造事实
- 对不确定内容明确标注
- 优先给出可落地建议
- 必要时用表格
- 如果有多个方案，请给出推荐优先级
输出格式：
## 核心结论
## 分析过程
## 推荐方案
## 执行步骤
## 风险与注意事项
## 需要补充的信息
写 Prompt 的能力，本质上是描述任务的能力。你越能把目标、背景、输入、约束、格式和标准讲清楚，模型越容易给出可用结果。
一句话总结：
写好 Prompt 的关键不是“会不会咒语”，而是能不能把任务、背景、标准和交付物讲清楚。
原文链接见：mp.weixin.qq.com/s/Jb5NBUJOY…
参考来源
- OpenAI Help Center: Best practices for prompt engineering with the OpenAI API: help.openai.com/en/articles…
- OpenAI Developers: Prompt engineering guide: developers.openai.com/api/docs/gu…
- Anthropic Docs: Claude prompt engineering: docs.anthropic.com/en/docs/bui…
- Google AI for Developers: Gemini prompting strategies: ai.google.dev/gemini-api/…
- Google AI for Developers: Gemini 3 documentation: ai.google.dev/gemini-api/…
