很多人学习 Prompt 时，第一反应是找模板：

• “帮我写一个万能提示词”
• “给我 10 个写作 Prompt”
• “有没有适合产品经理、程序员、运营的模板”

模板有用，但如果只背模板，很容易遇到三个问题：

• 换一个任务就不会改
• 输出看起来完整，但细节不可用
• 模型回答很顺，但没有验证机制

更稳的方式，是把 Prompt 当成一个小型任务说明书：目标是什么、上下文是什么、约束是什么、输出怎么验收。

我把 Prompt 相关内容整理在 AI全书里，包含 Prompt 工程分类、写作方法、上下文使用和实际场景示例：

• Prompt 工程分类
• Prompt 写作入门

下面是我对 Prompt 方法的一个实践拆解。

1. 先写清楚任务目标

一个模糊 Prompt 通常长这样：

帮我优化这段文案。

这个请求的问题是：模型不知道你想优化什么。

更好的写法是：

请把下面这段产品介绍改成面向 B 端采购决策人的版本，语气保持专业克制，重点突出部署成本、数据安全和可维护性，不要使用夸张营销词。

两者差别不在于后者更长，而在于它明确了：

• 读者是谁
• 目标是什么
• 语气是什么
• 重点是什么
• 不要做什么

Prompt 的第一步不是“加魔法词”，而是定义任务。

2. 补足上下文

模型没有读心能力。你不给上下文，它就只能按通用经验补全。

上下文可以包括：

• 业务背景
• 目标用户
• 当前版本
• 已知问题
• 输入数据来源
• 不能违反的规则
• 期望输出格式

在 AI 编程、RAG、运营文案、产品设计里，上下文质量往往比提示词模板更重要。

AI全书里也整理了一篇上下文使用相关内容：

Prompt 上下文使用方法

3. 明确约束和边界

很多 Prompt 输出不稳定，不是模型“不聪明”，而是边界没写。

例如让模型写代码时，可以明确：

• 不要新增第三方依赖
• 不要改 public API
• 只修改指定目录
• 保留现有测试
• 输出前说明影响范围

让模型写内容时，可以明确：

• 不编造数据
• 不使用绝对化表达
• 不写没有证据的结论
• 不要改变事实顺序
• 保留专业术语

边界越清楚，输出越容易检查。

4. 给出输出格式

如果你希望模型输出结构化结果，就不要只说“整理一下”。

可以直接给格式：

请按以下结构输出：

1. 问题摘要
2. 可能原因
3. 验证步骤
4. 推荐处理方案
5. 需要人工确认的风险点

这类格式约束很适合：

• 故障排查
• 代码审查
• 需求拆解
• 竞品分析
• 文案改写
• 知识库问答

格式不是为了好看，而是为了让结果可比较、可复用、可检查。

5. 加入验证机制

Prompt 工程最容易被忽视的一步是验证。

例如你可以要求模型：

• 列出不确定信息
• 标注哪些结论来自输入材料
• 给出反例或风险点
• 输出人工检查清单
• 对关键结论给出依据

对于技术任务，还可以要求：

• 说明修改了哪些文件
• 说明需要运行哪些测试
• 说明可能影响哪些模块
• 说明哪些地方没有验证

真正可用的 Prompt，不只是让模型“生成答案”，还要让答案可审查。

6. 常用结构

我自己更常用这个结构：

你要完成的任务：

背景：

输入材料：

约束条件：

输出格式：

验收标准：

不确定时怎么处理：

这个结构不复杂，但足够覆盖大多数场景。

7. Prompt 和工作流结合

当任务变复杂时，不要试图用一个超长 Prompt 解决所有问题。

可以拆成多步：

1. 先让模型复述任务，确认理解。
2. 再让模型列方案和风险。
3. 人工选择方案。
4. 再让模型执行。
5. 最后让模型自检和给出验证步骤。

这比“直接生成最终答案”更稳。

8. 小结

Prompt 工程不是背模板，而是把任务讲清楚：

• 目标明确
• 上下文充分
• 约束清楚
• 格式稳定
• 能够验证

如果要系统学习，可以从 AI全书的 Prompt 分类开始：

AI全书 Prompt 工程分类

后续我也会继续整理 Prompt、RAG、AI 编程、Agent 和 MCP 相关的系统学习资料。

---

说明：本文为 AI 辅助整理，基于 AI全书已发布的 Prompt 学习资料和公开实践经验。