12 个真正好用的提示词把要求写成验收标准先说清楚为什么复制过来的提示词经常不好用提示词这个品类有个很别扭的地方它在别人手里好用粘到你这边就变成一串客气的废话。原因通常不在模型而在那段话本身——它写的是帮我看看而不是按什么标准看、看到什么程度算看完、不许做什么。我们把站内提示词库现在的 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查数据对应 PostgresExcel 对应读表的 MCPPDF 摘要那条直接挂了 PDF 处理的 Skill 和文档转换的 MCP复杂推理对应 sequential-thinking设计评审对应 Figma 的 MCP。MCP 解决连得上提示词解决按什么标准做两者配起来才是一条完整链路。想了解分层可以看MCP 核心抽象剖析prompts本身就是 MCP 协议里的三类原语之一可以直接被工具化下发。按场景找入口比按名字翻更省事场景目录、Skill 总入口、MCP 目录都是可筛选的。如果你连选型依据都不想接受那就先看这份可检索的工具目录与评测指南。七、把这些提示词当资产管理起来三条实用建议第一改过的地方要记。一旦你开始改这些模板三个月后你会忘记为什么删掉某句。团队里用 Git 管提示词、发布前跑回归的做法我们写过提示词版本管理与 GitOps。个人用也成立一个prompts/目录每个模板一个文件改动写 commit message。第二注意成本。这类长模板会把上下文撑大量大的时候缓存与分流的影响很实在见降低企业 LLM 调用成本 70%。个人使用更简单的判断是别把整份日志塞进根因分析那条先给关键片段。第三警惕间接注入。提示词里凡是粘贴外部内容的位置日志、邮件、PDF、转写都是攻击面——外部文档里写一段忽略以上指令就可能改变模型行为。防御性写法见提示词工程中的防御性设计。这也是为什么这 12 条里有几条要求只读查询“不要执行破坏性操作”。八、一句话版本开发三条管改之前先说清楚写作三条管结论要能验收数据文档三条管结果可复核评审决策自动化三条管把取舍摆出来。12 条正文都在站内提示词库里复制即用但真正值得你花时间的不是复制而是把每条里的输出结构和禁令改成你自己团队的标准——那部分一改它才从别人的模板变成你的工具。本文由 AgentHub 首发myagenthub.cn —— MCP Servers 与 Agent Skills 资源库。阅读原文https://myagenthub.cn/blog/twelve-useful-ai-prompts更多垂类 MCP 选型与安装教程MCP 工具库 · 安装配置教程 · 场景专区