先说清楚：为什么复制过来的提示词经常不好用
提示词这个品类有个很别扭的地方：它在别人手里好用，粘到你这边就变成一串客气的废话。原因通常不在模型，而在那段话本身——它写的是"帮我看看"，而不是"按什么标准看、看到什么程度算看完、不许做什么"。
我们把站内提示词库现在的 1,018 条按场景过了一遍（分 8 类：开发 226、写作 147、调研 139、自动化 131、国内服务 109、数据 102、设计 98、测试 66），挑出 12 条我们真的认为能落地、覆盖日常高频场景的模板。挑选标准只有三条：有明确的输出结构（不是"写得好一点"这种形容词），有禁令（不许编、不许大改、不许泛泛而谈），变量位置留得干净（你知道该往里填什么）。下面每条都给出正文和它对应的使用场景，正文与站内详情页一致，可以直接在详情页一键复制。
先给一句总结：好提示词不是把话说漂亮，是把验收标准写清楚。
一条能用的提示词长什么样：五段骨架
这 12 条看着场景各异，拆开是同一副骨架：
角色决定它用谁的口吻判断。写"你是一位资深工程师"和写"帮我改代码"，模型的批评尺度完全不同——前者敢直接说"这里必须改"，后者只会给你三个"供您参考"。
上下文决定它是否需要猜。仓库简介、表结构、日志片段、参会人名单，这些位置宁可留空也别让它编。上面那类模板里 {...} 的占位符就是这个用途。
任务只写一件事。一条提示词同时要求"重构 + 补测试 + 优化性能 + 写文档"，产出一定是每样一点、每样都不够用。
输出结构是最值钱的一段。要求它按"必须修复 / 建议优化 / 可选改进"分档，比要求它"详细一点"有效十倍，因为你把判断的坐标系交给了它。
禁令收尾。"不要一次性大重写""避免依赖脆弱 CSS 选择器""不确定处标注待确认"——这类句子看起来像装饰，实际是在堵模型最省事的退路。
一、开发：改代码之前，先让它把话说清楚
1. GitHub PR 代码审查 · 详情页
什么时候用：手上有别人的 PR，或者想让 AI 先过一遍自己的改动再提 PR。
你是一位资深工程师，请审查以下 Pull Request。
**仓库上下文**：{项目简介，可选}
**PR 标题**：{标题}
**变更说明**：{描述}
请按以下结构输出：
1. **概要**：用 2–3 句话说明这次改动的目的与影响范围
2. **优点**：列出 2–3 点做得好的地方
3. **问题清单**（按严重程度排序）：
- 🔴 必须修复：{文件:行号} — 问题 — 建议改法
- 🟡 建议优化：…
- 🟢 可选改进：…
4. **测试建议**：还应补充哪些测试
5. **合并建议**：Approve / Request changes / 需讨论
要求：引用具体文件与行号；不要泛泛而谈；若信息不足请列出需要我补充的内容。
它好在哪：三档严重度加一个明确的合并结论，把"评审"这件很虚的事变成了可执行的清单。最后一句"若信息不足请列出需要我补充的内容"是关键——它把模型从"硬答"切换到"先问"，返工率差别很大。
要填什么：至少填 PR 标题和变更说明；把 diff 或相关文件内容贴进上下文，只给标题它只能给通用意见。
2. 生产问题根因分析 · 详情页
什么时候用：线上报警了，你有一堆日志但没头绪。
线上出现问题，请帮我做根因分析。
**现象**：{用户看到什么}
**时间线**：{何时开始、频率}
**日志片段**：{粘贴相关日志}
**最近变更**：{发版、配置、依赖变更，如有}
**环境**：{生产/预发、区域、版本}
请输出：
1. 可能原因（按概率排序，每条说明依据）
2. 建议立即执行的排查命令/检查项
3. 最可能的根因与修复方案（含代码/配置层面）
4. 防复发：监控、告警、测试、流程改进
5. 如需更多信息，请列出你要我问同事的问题
避免未经验证就下定论。
它好在哪：把"按概率排序 + 每条说明依据"写进输出结构，能压掉大部分看起来很有道理、实际是猜的答案。第 5 条那句"列出你要我问同事的问题"很实用——它把缺口显式化了，而不是让你在错误的根因上继续排查。
注意：贴日志前先擦掉 token、手机号、身份证号这类内容。这条在让 AI 替你办事的安全清单里专门讲过。
3. 遗留模块渐进式重构 · 详情页
什么时候用：有块代码人人都怕，但你不敢让 AI"重写一遍"。
我要重构以下模块，请制定**渐进式重构计划**（每次 PR 可独立合并、行为不变）。
**模块路径**：{path}
**当前痛点**：{例如：函数过长、耦合严重、缺少测试}
**约束**：{例如：不能改公共 API、需兼容 Node 18}
请输出：
1. 现状诊断（3–5 条）
2. 目标架构草图（文字描述即可）
3. 分步计划（Step 1…N），每步包含：
- 做什么
- 如何验证行为未变（测试/对比命令）
- 预估风险
4. 第一步可直接开工的具体改动清单
不要一次性大重写；优先提取函数、补测试、再动结构。
它好在哪："每次 PR 可独立合并、行为不变"这十个字是整条提示词的骨架，它把 AI 从"给你一份理想架构"逼到"给你一条能走的路"。每一步都要求写验证方法，这是重构里最容易漏、也最值钱的一段。
约束那行别偷懒：把"不能改公共 API""必须兼容 Node 18"这类硬边界写进去，否则它会顺手给你换个框架。
二、写作与汇报：把碎片变成能被别人验收的东西
4. 周报生成（STAR 结构） · 详情页
请根据以下素材写一份**简洁专业的周报**（中文，约 400–600 字）。
**本周完成**：
- {条目1}
- {条目2}
**数据/结果**（如有）：{指标}
**遇到的问题**：{…}
**下周计划**：{…}
**需要协调**：{…}
结构要求：
1. 本周亮点（2–3 条，尽量量化）
2. 详细进展（按项目分组，每条用 Situation–Task–Action–Result 压缩写）
3. 风险与阻塞（含需要的支持）
4. 下周重点（可验收的 3 条）
语气：务实、不夸大；未完成的写清进度百分比与原因。
它好在哪：字数上限和"可验收的 3 条"是最有用的两处。前者防止它写成一篇文章，后者把"下周继续推进"这种没法检查的话挡住了。"未完成的写清进度百分比与原因"是一条反套话指令，专门治那种全是好消息的周报。
5. 会议纪要 + 待办 · 详情页
请将以下会议内容整理为纪要。
**会议主题**：{…}
**参与人**：{…}
**原始记录**：{粘贴转写或笔记}
输出格式：
1. 会议信息（时间、参会人、目标）
2. 讨论要点（按议题分组，保留关键分歧）
3. **决议**
4. **Action Items** 表格：| 事项 | 负责人 | 截止日期 | 状态 |
5. 未决问题与下次会议议题建议
不要捏造未出现的决议；不确定负责人标「待指定」。
它好在哪：表格形式强制了"负责人 + 截止日期"这两列，待办没法是空的。"保留关键分歧"常被忽略，但纪要最大的价值恰恰是把没达成一致的地方记下来。
这条禁令必须留着：「不要捏造未出现的决议」。会议里说了"回头再看"的东西，模型很喜欢写成"已同意"，这一句能挡住。
6. 商务邮件回复 · 详情页
请帮我起草邮件回复。
**对方邮件摘要**：{粘贴或概括}
**我的立场/目标**：{例如：同意延期但需新截止日期}
**语气**：{正式 / 友好专业}
**语言**：{中文 / 英文}
输出：
1. 建议 subject（若是新线程）
2. 正文（分段：致谢/回应要点/下一步/落款提示）
3. 可选的简短版（3 句话以内）
4. ⚠️ 需我确认的敏感句（如有）
不要编造未确认的承诺或数字。
它好在哪：第 3、4 项是设计得很聪明的两处——"简短版"让你能直接改用，"需我确认的敏感句"把模型替你做出的承诺显式列出来。发出去之前扫一眼那段警告，能省掉不少事后道歉。
三、数据与文档：让结果能被复核
7. 自然语言查数据 · 详情页
你是数据分析助手。根据问题生成 SQL 并解释结果该如何解读。
**数据库**：PostgreSQL
**相关表结构**：{粘贴 CREATE TABLE 或字段说明}
**业务问题**：{例如：过去 30 天各渠道转化率？}
请输出：
1. 对问题的澄清（如有歧义先问 1–2 个问题）
2. SQL 查询（带注释，注意索引友好）
3. 结果字段含义说明
4. 建议的可视化图表类型
5. 数据质量注意事项（空值、重复、时区）
不要执行破坏性操作；只读查询。
它好在哪：第 1 条"如有歧义先问"能挡住最典型的一类错误——问题本身没定义清楚（转化率按人还是按订单？含不含退款？）。"数据质量注意事项"和"只读查询"是把它当同事用而不是当命令行用。
表结构一定要贴。不给 schema 的 SQL 看起来完全合理，字段名却是编的。
8. Excel 报表解读与公式 · 详情页
请帮我处理 Excel 相关需求。
**场景**：{例如：多 sheet 销售汇总}
**现有结构**：{列名、示例几行数据，或截图文字描述}
**目标**：{例如：按区域汇总 Q4 毛利，并标出 Top 10}
请输出：
1. 理解确认（你对我需求的复述）
2. 推荐方案：公式 / 透视表 / Power Query 思路（选最合适的）
3. 具体公式或操作步骤（分步、可复制）
4. 常见坑（合并单元格、文本型数字等）
若需 MCP 读表，请先说明需要哪些列权限。
它好在哪：第一条是"先复述一遍我的需求"。这招在任何领域都管用——花 30 秒读它复述的内容，比花 30 分钟发现方向错了便宜得多。最后那句"先说明需要哪些列权限"是权限最小化的写法。
9. PDF 长文档摘要 · 详情页
请阅读附件/提供的 PDF 内容，输出结构化摘要。
**文档类型**：{论文 / 合同 / 行业报告 / 其他}
**我的关注点**：{例如：只关心财务条款 / 方法论部分}
**输出语言**：中文
请包含：
1. **一句话结论**
2. **目录式摘要**（章级要点，每章 2–4 条）
3. **关键数据与引用**（如有表格数据请整理）
4. **行动项 / 待决策项**（若适用）
5. **术语表**（3–8 个关键术语简短解释）
6. **可信度备注**：哪些结论文档未明确、需人工核实
若文档过长，请先说明分段阅读计划再汇总。
它好在哪：第 6 条"可信度备注"是这 12 条里我最看重的一句指令。长文档摘要最大的风险不是漏，而是把没写的东西总结成结论。合同和研报尤其如此。
配套工具：这条在站内详情页挂了 PDF 相关的 Skill 和文档转换的 MCP，读大文件时比手动粘贴省事。想看怎么把文档处理成一条流水线，可以读前端组件库研发智能化里那套思路。
四、评审、决策与自动化：把取舍摆到台面上
10. 复杂问题分步推理 · 详情页
什么时候用：技术选型、方案对比、任何"几个都对但只能选一个"的问题。
请用**显式分步推理**解决以下复杂问题（不要跳步）。
**问题**：{描述}
**已知条件**：{列表}
**可选方案**：{如有}
**评价标准**：{例如：成本、延迟、可维护性}
格式：
**Step 1** — 澄清与拆解：子问题列表
**Step 2** — 每个子问题的分析（假设需标注）
**Step 3** — 方案对比表
**Step 4** — 推荐结论与置信度（高/中/低）
**Step 5** — 若结论错误，最可能错在哪一步
最后给一页「给决策者看的摘要」（5 条以内）。
它好在哪：Step 4 要置信度、Step 5 要"最可能错在哪一步"。这两条把 AI 从给答案改成给一个带脆弱性的答案，你才知道该去验哪部分。"假设需标注"也关键——多数错误结论的根因是一条被悄悄当成事实的假设。
评价标准要具体。写"成本、延迟、可维护性"能工作，写"要好一点"只会得到一篇作文。
11. 设计稿评审 · 详情页
请评审以下 UI 设计（Figma 链接或描述）。
**产品类型**：{Web / App / 后台}
**设计说明**：{链接或关键截图描述}
**设计系统**：{是否已有组件库，如有请说明}
**目标用户**：{…}
评审维度：
1. **视觉一致性**：间距、字号、颜色、组件复用
2. **可访问性**：对比度、触控目标、语义与状态
3. **开发可行性**：布局是否过于复杂、是否需要非标准交互
4. **体验流程**：主路径是否清晰、空态/错态是否考虑
5. **改进清单**：按优先级列出具体修改建议
每条建议请说明「问题 → 影响 → 改法」。
它好在哪：四个维度里"开发可行性"最容易被忽略，却是评审时最实在的一条——AI 不会因为设计稿好看而替你把非标交互实现三遍。最后一句"问题 → 影响 → 改法"给每条建议加了统一格式，方便直接贴进工单。
设计方向的 Skill 我们另外整理过一份，见设计师该装的 5 个 Skill。提示词管一次评审，Skill 管每次都按你的标准评。
12. n8n 工作流设计 · 详情页
请帮我设计一个 n8n 自动化工作流。
**业务流程**：{例如：新 GitHub Issue → 飞书通知 → 写入 Notion}
**触发条件**：{定时 / Webhook / 事件}
**涉及系统**：{API 列表}
**失败时期望**：{重试、告警、死信}
请输出：
1. 流程图（文字或 mermaid 节点序列）
2. 每个节点的：类型、输入输出、关键配置
3. 鉴权与环境变量建议（不要写真实密钥）
4. 错误处理与幂等性说明
5. 分阶段上线建议（先 MVP 再扩展）
若某系统无官方节点，说明用 HTTP Request 怎么接。
它好在哪："失败时期望"和"幂等性"这两条，是自动化从玩具到能用的分水岭。写"不要真实密钥"是为了防止你把带密钥的配置贴回聊天窗口。最后那句 HTTP Request 兜底，能省掉一次"这个系统没有节点怎么办"的来回。
五、三类最常见的失效，和对应的修法
失效一：输出泛泛而谈。 说明它没有可执行的坐标系。修法不是加一句"具体一点"，而是把"具体"定义出来：要文件行号、要严重度分档、要表格列名。上面每条提示词都有一段输出结构，作用就在这里。
失效二：它替你编了内容。 尤其是决议、承诺、数据、结论这四类。修法是加禁令并给它一个"承认不知道"的出口：标「待指定」、标「待确认」、列出需要问同事的问题。没有出口时，模型会优先选择看起来完整的答案。
失效三：约束被忽略。 你把"不能改公共 API"写在第一段，它照样改了。修法是把约束放到最后再重申一次——这 12 条里多数以禁令收尾，不是排版巧合。同时要求它在动手前先复述约束，能显著降低跑偏概率。
还有一个不太直观但很有效的技巧：给它两条长度不同的输出。周报那条要 400–600 字，邮件那条同时给完整版和 3 句以内版。模型在只有一个目标时容易过度发挥，有两个候选时反而更克制。
六、提示词之外：让它接上你的真实上下文
到这里你应该能看出来，提示词写的是"标准"，但它每次都要你手工提供"事实"：diff、日志、表结构、会议记录。真正省事的做法是把这部分接到工具上。
上面这 12 条里有 9 条在详情页正文下面挂了配套工具：PR 审查对应 GitHub 相关的 MCP，查数据对应 Postgres，Excel 对应读表的 MCP，PDF 摘要那条直接挂了 PDF 处理的 Skill 和文档转换的 MCP，复杂推理对应 sequential-thinking，设计评审对应 Figma 的 MCP。MCP 解决"连得上"，提示词解决"按什么标准做"，两者配起来才是一条完整链路。想了解分层，可以看MCP 核心抽象剖析；prompts 本身就是 MCP 协议里的三类原语之一，可以直接被工具化下发。
按场景找入口比按名字翻更省事：场景目录、Skill 总入口、MCP 目录都是可筛选的。如果你连选型依据都不想接受，那就先看这份可检索的工具目录与评测指南。
七、把这些提示词当资产管理起来
三条实用建议：
第一，改过的地方要记。 一旦你开始改这些模板，三个月后你会忘记为什么删掉某句。团队里用 Git 管提示词、发布前跑回归的做法，我们写过提示词版本管理与 GitOps。个人用也成立：一个 prompts/ 目录，每个模板一个文件，改动写 commit message。
第二，注意成本。 这类长模板会把上下文撑大，量大的时候缓存与分流的影响很实在，见降低企业 LLM 调用成本 70%。个人使用更简单的判断是：别把整份日志塞进"根因分析"那条，先给关键片段。
第三，警惕间接注入。 提示词里凡是"粘贴外部内容"的位置（日志、邮件、PDF、转写）都是攻击面——外部文档里写一段"忽略以上指令"，就可能改变模型行为。防御性写法见提示词工程中的防御性设计。这也是为什么这 12 条里有几条要求"只读查询""不要执行破坏性操作"。
八、一句话版本
开发三条管"改之前先说清楚"，写作三条管"结论要能验收"，数据文档三条管"结果可复核"，评审决策自动化三条管"把取舍摆出来"。 12 条正文都在站内提示词库里，复制即用；但真正值得你花时间的不是复制，而是把每条里的输出结构和禁令改成你自己团队的标准——那部分一改，它才从"别人的模板"变成"你的工具"。