主题
常用提示词模板
前面几篇讲了提示词的概念、结构和技巧。但你可能发现一个问题：就算知道了「角色-任务-背景-格式」这套框架，真正遇到复杂工作时，还是不知道怎么写出有深度的提示词。
原因很简单：填空谁都会，但「填什么」取决于你懂不懂背后的方法论。
举个例子。同样让 AI 做代码审查，普通提示词是「帮我 review 这段代码」——AI 只能看个大概，给你的反馈全是「变量名可以更好」「建议加注释」这类表面建议。而如果你知道代码审查有正确性、可读性、性能、安全性、可测试性五个维度，你就能写出一个引导 AI 逐维度深度审查的提示词，得到的反馈质量完全不同。
这篇文章的思路是：先讲方法论，再给结构化模板。每个模板不是一堆空要填的格式，而是把一套思考方法「编码」进了提示词里，让 AI 按照专家的思路帮你分析。
以下场景按角色分组：开发（重点）→ 运营 → 职场办公。找到你的角色直接跳过去看。
开发篇
痛点一：需求分析和任务规划
痛点描述
产品经理给了一段需求描述，或者你自己有个想法，但不知道怎么把它变成可执行的开发任务。常见症状：需求看起来懂了，一动手才发现到处是坑——边界条件没说、异常情况没考虑、优先级搞不清。
方法论：需求拆解五步法
- 理解意图：区分「用户要的」和「用户说的」。用户说「我要一个导出功能」，背后可能是「我需要把数据拿到 Excel 里做分析」。理解意图才能找到更好的方案。
- 拆分用户故事：把大需求拆成独立的小故事，格式：「作为 [角色]，我想要 [功能]，以便 [价值]」。每个故事应该能在一个迭代内完成。
- 定义验收标准：每个故事必须有「完成定义」（Definition of Done）——什么状态算做完了？正常路径、异常路径、边界条件分别怎么处理？
- 识别不确定项：标出所有「我不确定」的地方。这些是风险点，必须提前和 PM 或业务方确认，不能靠猜。
- 评估优先级和依赖：用「价值 × 紧迫度」排优先级。标出任务之间的依赖关系——哪个必须先做，哪个可以并行。
结构化提示词模板
text
## 角色
你是一个有 10 年经验的技术负责人，擅长需求分析和项目拆解。
## 背景
我是 [前端/后端/全栈] 开发，技术栈是 [______]。
以下是需求描述：
[粘贴需求原文]
## 请按以下步骤分析
### 第一步：需求理解
- 这段需求的核心目标是什么？用一句话概括。
- 需求中没有明说、但隐含的期望有哪些？
### 第二步：任务拆分
- 拆成可独立执行的开发任务，每个任务不超过 2 天工作量。
- 每个任务用一句话描述：做什么、产出什么。
### 第三步：验收标准
- 每个任务给出 3-5 条验收条件。
- 必须包含：正常路径、异常路径（至少 2 种）、边界条件。
### 第四步：风险标记
- 用 🔴 标记「需求不明确，必须确认」。
- 用 🟡 标记「有技术风险，需要评估」。
- 用 🟢 标记「清楚，可直接开发」。
### 第五步：依赖和优先级
- 标出任务之间的依赖关系。
- 建议开发顺序。
## 输出格式
按上述五步输出，每步用 ## 分隔。风险项单独汇总在最后。为什么这样写
这个模板把「需求拆解五步法」编码进了提示词。AI 不只是「帮你整理需求」，而是按照专业的方法论逐步分析。关键设计：
- 区分「说的」和「要的」：让 AI 主动发现隐含需求，而不是只做表面整理。
- 验收标准必须包含异常路径：这是新手最容易漏掉的部分。
- 风险标记用颜色分级：一眼看到哪些需要确认，哪些可以直接干。
- 依赖关系和开发顺序：把任务从「列表」变成「路线图」。
使用提示
- 需求描述越完整，AI 分析越准。如果需求本身就是一句话（如「做一个用户管理模块」），先让 AI 反问你 5 个关键问题，你补充后再让它拆解。
- 拆完任务后，追问：「这些任务有没有我遗漏的边界条件？」——AI 经常能发现你没想到的情况。
痛点二：性能优化
痛点描述
页面慢了、接口卡了、数据库扛不住了——但不知道从哪里开始排查。常见错误：看到慢就加缓存、看到卡就换数据库，结果问题没解决还引入新 bug。
方法论：性能诊断四步法
- 定义问题：「慢」是多慢？当前值 vs 目标值 vs 历史基线。没有数据就没有优化方向。
- 度量基线：用数据说话——P50/P95/P99 延迟、吞吐量、错误率。没有度量就没有对比。
- 定位瓶颈：先缩小范围，再深入分析。常用诊断框架：
- USE 方法（基础设施层）：对每个资源检查 利用率（Utilization）、饱和度（Saturation）、错误（Errors）。
- RED 方法（服务层）：对每个接口检查 请求速率（Rate）、每次请求耗时（Duration）、错误数（Errors）。
- 修复 + 验证：每次只改一个变量，改完用相同条件验证。避免同时改多处导致无法判断哪个有效。
结构化提示词模板
text
## 角色
你是一个性能优化专家，擅长系统化诊断和解决性能问题。
## 背景
项目技术栈：[______]
问题描述：[______]
已知数据：[______]（如 P99 延迟、QPS、数据库慢查询日志等）
## 请按以下框架分析
### 1. 问题定义
- 当前的具体性能数据是什么？（P50/P95/P99 延迟、QPS、错误率）
- 目标指标是什么？（例如 P99 < 200ms）
- 什么时候开始出现的？是突发还是逐渐恶化？
### 2. 瓶颈定位
请从以下维度排查，每个维度给出：可能的瓶颈点、排查方法、判断标准。
**应用层**：
- 是否有慢查询？N+1 查询？不必要的序列化？
- 是否有锁竞争？线程池耗尽？内存泄漏？
**数据层**：
- 数据库：慢查询日志、索引覆盖率、连接池使用情况。
- 缓存：命中率、过期策略、热 key 问题。
**基础设施层**：
- CPU / 内存 / 磁盘 IO / 网络带宽的使用率和饱和度。
### 3. 优化建议
每个建议必须包含：
- 预期收益（量化，如「P99 延迟从 2s 降到 500ms」）
- 实施成本（高 / 中 / 低）
- 风险点（可能引入什么问题）
- 验证方法（怎么确认优化生效了）
### 4. 优先级排序
按「收益 / 成本」比值从高到低排序。先做性价比最高的。
## 输出要求
- 不要泛泛而谈，每个建议必须针对我描述的具体场景。
- 如果我的信息不足以判断，明确告诉我还需要补充哪些数据。
- 不要一次性建议太多优化项，先聚焦 top 3。为什么这样写
普通性能优化提示词：「我的接口很慢，怎么优化？」——AI 只能给你一堆通用建议（加缓存、加索引、用 CDN），对你实际情况帮助不大。
这个模板的设计关键：
- 强制要求数据：让 AI 先问你「当前性能数据是什么」，没有数据就给方向而不是给结论。
- 分层排查：应用层 → 数据层 → 基础设施层，从顶到底排查，不遗漏也不跳步。
- 每个建议必须量化：避免「可以优化一下」这种废话，要求 AI 给出预期收益和实施成本。
- 限制 top 3：避免 AI 一次甩出 10 条建议让你无所适从。
痛点三：架构评估和决策
痛点描述
面临技术选型或架构调整——微服务还是单体？选 Kafka 还是 RabbitMQ？数据库要不要拆分？每个选择都有道理，但不知道哪个更适合当前阶段。常见错误：跟风选「先进」的方案，结果团队 hold 不住。
方法论：架构决策四步法（ATAM 简化版）
- 明确驱动因素：哪些质量属性最重要？可扩展性、可维护性、性能、成本、团队能力——不同阶段优先级不同。
- 分析约束：团队规模和技术能力、时间线、预算、现有基础设施——这些限制决定了你能选什么。
- 评估方案：每个方案在质量属性、约束满足度、风险、成本上的表现。没有「最好」的方案，只有「最适合当前约束」的方案。
- 识别可逆性：哪些决策可逆（选错能改）？哪些不可逆（改起来代价极大）？优先决定不可逆的，可逆的可以先试。
结构化提示词模板
text
## 角色
你是一个有 10 年经验的系统架构师，擅长在约束条件下做技术决策。
## 背景
[描述当前系统状况和面临的技术决策]
业务背景：
- 产品类型：[______]
- 当前用户量：[______]，预期增长：[______]
- 团队规模：[______] 人，技术能力：[______]
技术现状：
- 当前架构：[______]
- 当前痛点：[______]
- 基础设施：[______]
约束条件：
- 时间：[______]
- 预算：[______]
- 必须满足的要求：[______]
## 请按以下框架分析
### 1. 候选方案
列出 2-3 个可行方案。每个方案包含：
- 架构概述（一句话 + 关键组件图）
- 优势（不超过 3 条）
- 劣势（不超过 3 条）
### 2. 多维度对比
请用表格对比，维度包括：
- 可扩展性（用户量增长 10 倍时能否支撑？）
- 可维护性（新人上手难度、日常运维复杂度）
- 开发效率（从当前状态到目标状态的迁移成本）
- 成本（基础设施费用 + 人力成本）
- 团队匹配度（以当前团队能力，能否 hold 住？）
### 3. 风险和权衡
- 每个方案最大的风险是什么？
- 哪些维度之间存在不可兼得的 trade-off？
- 哪些决策是可逆的（选错能改）？哪些是不可逆的？
### 4. 建议
- 给出你的推荐方案和推荐理由。
- 说明推荐成立的前提条件。
- 如果前提条件不满足，备选方案是什么？为什么这样写
架构决策最容易犯的错误是「抛开约束谈方案」。这个模板的关键设计：
- 强制先说约束：团队能力、时间、预算放在最前面。没有约束的架构讨论都是空谈。
- 团队匹配度作为独立维度：很多架构方案技术上好，但团队 hold 不住就是最差的方案。
- 可逆性分析：帮你看清哪些决策需要谨慎（不可逆），哪些可以先试（可逆）。
- 推荐必须说前提：避免 AI 给你一个「看起来很确定」的答案。所有建议都有前提条件。
痛点四：代码审查
痛点描述
写完代码让 AI 帮你 review，结果收到的全是「变量名可以更好」「建议加个注释」这种表面建议。真正的问题——逻辑漏洞、安全隐患、性能陷阱——一个都没抓到。
方法论：多维度代码审查
专业代码审查不是「看看有没有问题」，而是按维度系统检查：
- 正确性：代码是否实现了预期逻辑？边界条件处理了吗？并发场景考虑了吗？
- 可读性：命名是否自解释？函数职责是否单一？是否有不必要的复杂度？
- 性能：有没有 O(n²) 循环？有没有 N+1 查询？有没有不必要的内存分配？
- 安全性：输入是否校验了？有没有注入风险？敏感数据是否暴露了？
- 可测试性：是否方便写单元测试？依赖是否可注入？边界是否可构造？
结构化提示词模板
text
## 角色
你是一个资深代码审查专家，以严谨、深入、不留情面著称。
## 任务
请从以下 5 个维度，逐维度审查下面的代码。
不要给出泛泛的建议（如「可以优化命名」），每个发现必须指向具体代码行和具体问题。
## 审查维度
### 1. 正确性 🔴
- 逻辑是否正确？边界条件是否处理？
- 是否有竞态条件、死锁风险？
- 异常处理是否完整？是否有未捕获的异常路径？
### 2. 可读性 🟡
- 函数是否过长（>50 行）？是否应该拆分？
- 命名是否清晰反映意图？
- 是否有「聪明但难懂」的写法？
### 3. 性能 🟠
- 是否有不必要的嵌套循环（O(n²) 或以上）？
- 数据库访问是否有 N+1 问题？
- 是否有内存泄漏风险（未关闭的连接、未释放的资源）？
### 4. 安全性 🔴
- 外部输入是否全部校验和转义？
- 是否有 SQL 注入、XSS、路径遍历等风险？
- 敏感信息（密码、token、密钥）是否暴露在日志或响应中？
### 5. 可测试性 🟢
- 是否有难以 mock 的硬依赖（如直接 new 对象、静态方法调用）？
- 函数是否有副作用导致测试困难？
## 输出格式
每个发现按以下格式：
- **维度**：[正确性/可读性/性能/安全性/可测试性]
- **严重度**：[🔴 必须修复 / 🟡 建议修改 / 🟢 可选优化]
- **位置**：第 XX 行 / XX 函数
- **问题**：具体描述
- **建议**：给出修改后的代码片段
最后，按严重度排序汇总，并给出整体评价（通过 / 有条件通过 / 需要重写）。
## 代码
[粘贴代码]为什么这样写
普通 review 提示词（「帮我 review 这段代码」）的问题：AI 不知道你关心什么，只能给你通用建议。
这个模板的设计关键：
- 五个维度逐一检查：不遗漏。正确性和安全性标 🔴，因为这两个出问题是事故。
- 每个发现必须指向具体代码行：避免 AI 说「建议优化性能」但不告诉你哪里需要优化。
- 严重度分级：帮你区分「必须改的」和「可以以后再说的」，不要在 review 里纠结命名风格。
- 要求给出修改后的代码：不只是指出问题，还要给出解决方案。
运营篇
痛点五：活动复盘
痛点描述
活动结束了，老板要看复盘。打开文档不知道怎么写——数据摆在那里，但不知道怎么分析出有价值的洞察。常见错误：复盘变成「报数据」或「找借口」，没有真正提炼出下次能用的经验。
方法论：结构化复盘五步法
- 回顾目标：当初定目标时的预期是什么？为什么定这个目标？
- 对比结果：实际数据 vs 目标数据，差距量化。
- 分析归因：哪些是可控因素（策略、执行），哪些是不可控因素（市场、政策）？成功的因素能复用吗？失败的因素能避免吗？
- 提炼经验：把具体事件抽象成方法论——下次遇到类似场景，应该怎么做？
- 行动计划：明确的改进项，分配到具体的人和时间。
结构化提示词模板
text
## 角色
你是一个资深运营专家，擅长数据分析和活动复盘。
## 背景
活动名称：[______]
活动周期：[______]
活动目标：[______]
实际数据：[粘贴关键数据]
## 请按以下结构输出复盘报告
### 1. 目标 vs 结果
用表格对比，每个指标列出：目标值、实际值、完成率、差距原因（一句话）。
### 2. 亮点分析
- 做得好的 top 3 是什么？
- 每个亮点背后的原因是什么？（是策略对了，还是执行到位，还是有运气成分？）
- 哪些亮点可以复用到下次活动？怎么复用？
### 3. 问题归因
- 表现最差的 top 3 是什么？
- 用「5 个为什么」追问根因：从表面问题连问 5 次「为什么」，找到根本原因。
- 区分可控因素（下次可以改）和不可控因素（下次需要预案）。
### 4. 经验提炼
- 这次活动中，验证了什么假设？推翻了什么假设？
- 如果重新做一次，你会在哪些环节做不同的决策？
### 5. 行动计划
用表格列出改进项，包含：具体动作、负责人、截止时间、预期效果。为什么这样写
关键设计：
- 5 个为什么：逼 AI 不停留在表面原因，一路追问到根因。
- 区分可控 vs 不可控：避免复盘变成「找借口大会」或「自我批评大会」。
- 经验提炼：从「这次做了什么」上升到「以后遇到类似场景该怎么做」。
痛点六：内容创作
痛点描述
要写一篇公众号文章 / 小红书笔记 / 产品推广文案，对着空白页面发懵。不知道该写什么、怎么写、写给谁。
方法论：用户驱动内容法
- 用户画像：写给谁？他们关心什么、害怕什么、渴望什么？
- 痛点/兴趣：他们面临什么问题？对什么话题感兴趣？
- 钩子设计：用什么开头能让他们停下来看？（提问、数字、反直觉的观点、场景代入）
- 内容结构：核心信息是什么？用什么结构组织？（问题→方案、故事→教训、清单→行动）
- 行动引导：看完之后你希望读者做什么？
结构化提示词模板
text
## 角色
你是一个资深内容运营，擅长写出用户愿意看完、看完会行动的内容。
## 背景
内容主题：[______]
发布平台：[______]（公众号 / 小红书 / 朋友圈 / 知乎 / …）
目标：[______]（品牌曝光 / 引流 / 转化 / 用户教育）
## 请按以下步骤创作
### 第一步：用户画像
- 目标读者是谁？（年龄、职业、场景）
- 他们最关心什么？最害怕什么？
- 他们在这个话题上常见的误解是什么？
### 第二步：钩子设计
- 给出 3 个不同的开头方案，每个用不同的钩子类型：
- 方案 A：用提问开头
- 方案 B：用具体数字/案例开头
- 方案 C：用反直觉观点开头
### 第三步：内容大纲
- 选定一个钩子方案后，给出完整大纲。
- 每个段落说明：这段要传递什么信息？用什么方式（故事 / 数据 / 类比）？
### 第四步：初稿
- 按照大纲写初稿。
- 语气风格：[______]（口语化 / 专业 / 轻松 / 紧迫）
- 长度：[______] 字以内
### 第五步：行动引导
- 文章最后，明确告诉读者下一步该做什么。
- 行动引导要具体（不是「关注我们」，而是「在评论区告诉我你的 XX」）。为什么这样写
关键设计：
- 先画像后创作：没有用户画像的内容一定是自嗨。让 AI 先分析读者再动笔。
- 3 个钩子方案：给你选择空间，不同钩子适合不同场景。
- 先大纲后初稿：大纲不对改大纲，别等写完 2000 字才发现方向错了。
职场办公篇
痛点七：周报总结
痛点描述
每周最头疼的事——写周报。感觉一周做了很多事，但写出来就变成了流水账。老板看了没感觉，自己写着也没成就感。
方法论：价值导向周报法
好的周报不是「我这周做了什么」，而是「我这周创造了什么价值、下周要创造什么价值」。
- 成果：本周最重要的 1-3 个成果（不是任务，是成果——任务是你做了什么，成果是你交付了什么价值）。
- 进展：进行中任务的进度百分比和下一步。
- 阻塞：卡住你的问题，需要谁协助。
- 计划：下周最重要的 1-3 个目标。
结构化提示词模板
text
## 角色
你是一个善于提炼工作价值的项目经理。
## 背景
我的岗位：[______]
本周做的事（流水账式罗列，不需要你整理格式）：
[列出本周所有做的事情，不用管格式]
## 请帮我按以下结构整理成周报
### 本周成果
- 提炼 top 3 成果。
- 每个成果用「完成了 [什么] → 带来了 [什么价值/影响]」的句式。
- 不要流水账，要体现价值。
### 进行中
- 列出未完成的任务，标明进度百分比。
- 每个任务说明：下一步是什么、预计什么时候完成。
### 阻塞项
- 如果有卡住的问题，列出来并说明：需要什么帮助、找谁能解决。
- 如果没有阻塞项，写「当前无阻塞项」。
### 下周计划
- 提炼 top 3 目标，用可量化的方式描述。
- 说明优先级排序的理由。为什么这样写
关键设计：
- 允许输入流水账：你只需要把本周做的事随便列出来，AI 帮你提炼成有价值的周报。输入门槛极低。
- 成果 ≠ 任务：「写了 5 个页面」是任务，「完成了首页改版，预计提升转化率 15%」是成果。模板强制用成果句式。
- 阻塞项单独列出：周报是向上管理最重要的工具——让老板知道你在哪里需要帮助。
痛点八：跨部门协作推进
痛点描述
需要推动其他部门配合你的工作，但发了消息没人回、开了会没有结论、邮件来回踢皮球。事情不是你做不了，是推不动别人。
方法论：协作推进四要素
每次推进协作，你的沟通必须包含四件事：
- 目标：我需要你做什么？（具体动作，不是「配合一下」）
- 原因：为什么需要你？不做会怎样？（让对方理解紧迫性）
- 时间：什么时候需要？（有 deadline 才有行动力）
- 减少摩擦：你需要我提供什么？（降低对方配合的门槛）
结构化提示词模板
text
## 角色
你是一个擅长跨部门沟通和项目推进的资深项目经理。
## 背景
我要推进的事情：[______]
需要协作的部门/人：[______]
当前状态：[______]（已沟通过但没有进展 / 还没开始沟通 / 对方有顾虑）
deadline：[______]
## 请帮我完成以下分析和输出
### 1. 协作分析
- 对方的核心诉求可能是什么？（他们关心什么、担心什么？）
- 他们可能拒绝或拖延的理由是什么？
- 我能给对方带来的价值是什么？（不是「我需要你帮」，而是「这对你也有好处」）
### 2. 沟通方案
根据分析，帮我拟一份沟通消息，必须包含：
- 具体需要对方做什么（一个明确的动作，不是模糊的「配合」）
- 为什么这件事重要（对双方的价值）
- 明确的 deadline
- 我这边能提供的支持（减少对方配合的摩擦）
- 如果对方犹豫，我的备选方案是什么
### 3. 输出格式
- 给一封正式的邮件版本（适合不太熟的跨部门同事）
- 给一条微信消息版本（适合比较熟的同事）
- 给一个如果对方拒绝/拖延的跟进策略为什么这样写
关键设计：
- 先分析再写话术：不了解对方的诉求，写什么话术都没用。让 AI 先帮你做「换位思考」。
- 双版本输出：正式邮件 + 微信消息，适合不同亲疏关系。
- 跟进策略：考虑对方可能拒绝或拖延的情况，提前准备好应对方案。
模板组合：真实工作流
真实工作往往不是单一任务。看看这些模板怎么组合使用：
场景 A：接到一个新需求 → 痛点一（需求分析）拆出任务 → 痛点三（架构评估）决定技术方案 → 开发中用痛点四（代码审查）review → 上线后用痛点五（活动复盘）做数据回顾
场景 B：写一份推广方案 → 痛点六（内容创作）产出内容 → 痛点五（活动复盘）框架设计效果度量方案 → 痛点七（周报）向上级汇报进展
场景 C：推动跨部门项目 → 痛点八（协作推进）发起沟通 → 痛点七（周报）同步进度 → 痛点二（性能优化）解决技术瓶颈
使用原则
原则一：先理解方法论，再用模板
模板背后的方法论是可以迁移的。即使你的场景不在上面列出的 8 个里，只要理解了方法论，你就能写出自己的结构化提示词。比如你不在做「代码审查」但在做「方案评审」，多维评估的方法论同样适用。
原则二：让 AI 按步骤走，不要一步到位
复杂任务不要指望一个提示词搞定。先让 AI 做分析（「帮我分析这个需求」），确认分析对了，再让它出方案（「根据分析给出方案」），方案确认了再出细节（「给出详细的实施计划」）。每一步都能纠偏，比一步到位靠谱得多。
原则三：好的提示词是迭代出来的
第一次用模板效果不理想很正常。追问「分析还不够深入，请再想想边界条件」「方案没有考虑我们团队只有 2 个人的约束，请重新评估」。每次追问都是在优化提示词，用几次之后你就知道哪些地方必须提前说清楚。
一句话总结
模板的价值不在于格式，在于背后的方法论。理解了方法论，你能写出任何场景的结构化提示词；不理解方法论，再好的模板也只是填空游戏。
行动建议
- 找到你的第一个痛点：从上面 8 个场景中，选一个你本周就会遇到的。
- 复制模板，填入你的真实信息：不要改模板的结构，只替换
[______]中的内容。 - 对比体验：先用你平时的方式问 AI 同一个问题，再用结构化模板问一次——感受差距。
- 保存你的模板：效果好的模板存到备忘录，下次直接复用，只改背景信息。