写出高质量Copilot提示词的5个技巧：从copilot-prompts实战样本中提炼的提示词设计方法论

copilot-prompts 是社区共建的 Microsoft Copilot 提示词样本库，目前收录118 个提示词样本、31 份 Agent 指令和10 个技能文件。比起背诵"提示词工程"理论，直接拆解这些经过实战检验的样本更快——本文从中提炼出 5 个写高质量 Copilot 提示词的技巧，每条都配真实案例，读完就能上手。

仓库里有什么：先认识三类提示词样本

每个样本都是同一套结构：一份说明用的readme.md+assets/sample.json元数据，打开对应文件夹、照 Instructions 操作即可。

技巧1：先给Copilot一个"角色"，再给任务 🎭

角色不是装饰，它决定了模型用什么专业水平和语气回答。样本里最典型的写法：

• m365-define-todays-actions 开头就是"You are a skilled personal assistant tasked to optimize my work"，一句话锁定"高效私人助理"人设；
• critical-thinking 则用"You are a consultant whose reputation depends on providing information that stands the test of time"——"声誉取决于答案经得起时间检验的顾问"，直接压住了 AI 爱附和的毛病。

看这个真实演示：问它"在家门口开柠檬水摊"的想法，Critical Thinking Agent 没有夸你，而是直接指出法律和营收问题：

写法要点：角色 = 专业领域 + 立场/动机。"你是重视已验证事实胜过猜测的数据分析师"远比"你是乐于助人的助手"有效。

技巧2：一句话讲清目标，再补关键上下文 🎯

prompt-context-engineer 这个技能的核心观点值得记住：提示词不是某一句巧妙句子，而是模型看到的一切。上下文要"刚好够用"——少了模型发挥不出来，塞多了质量下降、成本上升。

它给出了上下文组件清单：任务定义、角色、背景数据、受众、示例、约束、输出格式、状态、成功标准。不是每条提示词都要全，缺了会影响输出的才补——硬加无关内容本身就是上下文工程的失败。

两个样本对比着看：

• m365-communication-balance-analyzer-prompt 只有一句话："Look at my recent work context and tell me one thing I'm over-communicating and one thing I'm under-communicating. Be specific and constructive."目标具体（一多一少）、范围明确（recent work context）、质量有约束（specific and constructive）。

• m365-define-todays-actions 则用占位符补上下文："You determine the priority by analyzing my work patterns and collaborations over the past [number of days] days"——把变量部分显式标出来，复用时只需替换数字。

写法要点：先写目标动词（summarize / analyze / build），再给数据范围和时间窗口，可变部分用[占位符]标出。

技巧3：把输出格式"钉死"在提示词里 📐

Copilot 最让人头大的不是"答不出"，而是"每次答得都不一样"。样本库的共识是：格式要求要具体到字段级别。

specific-research-agent 的用户提示词把格式钉得很死：分享 5 条新闻，每条必须包含标题、一句话概要、发布日期、作者（如有）、发布网站、简短描述、"Read the article" 链接，条目之间加分隔符。看结果——Copilot 逐字段照做，没有自由发挥：

m365-top-5-tasks-of-the-day 也是同样思路："Build a dashboard summarizing the top 5 tasks of the day, their status, and any blockers preventing completion. Include upcoming deadlines for the week."数量（5）、字段（状态、阻塞项）、范围（本周截止日期）一次说清。

写法要点：格式描述放在提示词末尾，用字段清单或编号模板；能直接给模板就绝不描述。

技巧4：一个示例胜过三个形容词 🧪

prompt-context-engineer 的设计原则里有一条特别狠："Examples over adjectives——一个具体的输入→输出示例，胜过三句描述。"

它的 references/templates.md 为 6 类任务（生成、转换、提取、分类、对话、多步 Agent）各配了一套骨架，每套骨架都预留了示例区块：

• 转换类任务（摘要/改写/翻译）：给一个"短小的真实输入 + 理想输出"；
• 分类任务：每个类别 1 个示例，再加 1 个边界案例，演示模糊情况怎么判。

为什么有效？模型对"长这样的成品"的记忆，远比对"专业、清晰、简洁"这类形容词敏感。你纠结半天描述不清楚的风格，贴一个范例就解决了。

技巧5：复杂任务拆步骤，并给出可检查的成功标准 🪜

任务一旦跨多步（研究 → 分析 → 起草 → 成文），一条提示词硬扛往往质量下降。Prompt Coach SUPREME 的指令把流程拆成 8 个明确步骤（理解需求 → 选执行模式 → 选体验 → 选模型 → 估成本 → 写提示词 → 清晰呈现），每步都有判定条件，例如：

• 简单任务优先非计量（免费）体验，"明显更强时才升级"；
• 把 Credit 花在高价值推理步骤上，研究和起草尽量放在免费环节。

同时，好的指令会给出可检查的行为标准。critical-thinking 要求模型"当你不确定时，明说，而不是把猜测当事实"，并主动告诉用户哪些部分需要独立核实——这就是可验证的成功标准，让输出质量从玄学变成检查项。

写法要点：步骤用编号列表 + 每步的停止/升级条件；再给 1–2 条"什么算做对了"的验收标准。

交付前自检：5 问清单 ✅

prompt-context-engineer 还附了一份自检清单，任何提示词交付前都值得过一遍：

1. 只凭这条提示词（不靠额外上下文），模型能产出想要的结果吗？
2. 每一句是否都"承重"？删掉某句输出不变，就删掉；
3. 指令和数据是否清晰分开？
4. 输出格式是否无歧义、可检查？
5. 压缩过了吗？高密度短句 > 长篇稀释。

不想手工自检？仓库里就有现成的"提示词教练"：prompt-assistance 的 Promptly 会指出你提示词的优缺点并给出改进版，m365-prompt-architect 也能帮你从零搭建。

三步上手练习 🚀

1. 抄：到 samples/prompts/ 按场景挑一个提示词样本，原样粘贴到 Copilot 跑一遍；
2. 改：按本文 5 个技巧改写它——加角色、钉格式、补 1 个示例；
3. 比：跑前后两版对比输出稳定性；想贡献新样本，先读 CONTRIBUTING.md 了解提交规范。

提示词设计没有银弹，但"角色 + 目标 + 上下文 + 格式 + 示例 + 步骤"这套组合拳，在 118 个实战样本里反复出现——照着抄，就已经赢过 80% 的即兴提问。