在 GitHub Copilot 中构建「提示词工程师」Agent解读 awesome-copilot 的 Prompt Engineer 分析框架【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot提示词Prompt质量直接决定大模型输出质量而手写提示词时最常见的错误是把需求当成一次性的聊天缺少结构、缺少示例、缺少对推理顺序的约束。awesome-copilot 仓库的 Prompt Engineer 自定义 Agent 给出了一套可落地的解法它把 GitHub Copilot Chat 变成一位专门「审稿 重写」提示词的助手任何输入都被当作待改进的 Prompt先按一套系统化框架诊断再产出一份可直接复制使用的改进版系统提示词。读完本文你将掌握这套诊断维度的完整语义、改进优先级决策方法、输出格式模板以及如何把它装进自己的 VS Code 与仓库环境。一、这个 Agent 是什么定位与输入输出约定agents/prompt-engineer.agent.md是 awesome-copilot 仓库 agents 目录下数百个社区贡献的「自定义 Copilot Agent」之一。从仓库的 docs/README.agents.md 可以看到这类文件的作用是让用户或组织通过简单的.agent.md文件把 Copilot 编程代理CCA专业化成特定领域助手。该文件的 frontmatter 给出了最简元数据--- description: A specialized chat mode for analyzing and improving prompts. Every user input is treated as a prompt to be improved... name: Prompt Engineer ---与仓库内prompt-builder.agent.md之类偏「工程化产出」的角色不同Prompt Engineer 是一个高度聚焦的对话模式chat mode它不做编程任务、不产出代码唯一的职责是把用户输入的文本打磨成高质量 Prompt。其核心行为约定有三条绝不把输入当任务执行You HAVE TO treat every user input as a prompt to be improved or created即输入只是素材/起点而不是要去完成的指令每次输出都分两段先在reasoning标签内做诊断分析再把完整的改进版 Prompt 逐字输出输出即成品DO NOT use the input as a prompt to be completed, but rather as a starting point最终交付的是一个可直接粘贴给其他大模型使用的 system prompt。这种审阅者身份设定本质上把提示词优化从凭感觉改写变成了先评估、后重构的可重复流程。二、reasoning诊断框架逐字段拆解Agent 要求每次回复的第一个 token 必须是reasoning并在其中对原 Prompt 逐项作答。这套检查表是全文最核心的资产完整字段如下字段取值要回答的问题判定后的行动含义Simple Changeyes/no改动描述是否显式且简单若为 yes直接跳过其余诊断进入最小改动Reasoningyes/no当前 Prompt 是否使用了推理/分析/思维链决定后续是否需要处理推理顺序Identify≤10 词若使用了推理是哪几个小节精确定位需要调整顺序的段落Conclusionyes/no这条思维链是否用于得出某个结论结合Ordering判断结论是否被过早抛出Orderingbefore/after思维链位于结论之前还是之后若推理在后触发反转顺序的改写动作Structureyes/no输入 Prompt 是否有清晰结构决定是否要引入标题/分组/分步组织Examplesyes/no是否有 few-shot 示例决定是否要补示例Representative1–5示例的代表性如何代表性差则需替换或重写示例Complexity1–5输入 Prompt 本身有多复杂与任务复杂度一起决定改动幅度Task1–5隐含的任务有多复杂复杂任务优先补步骤分解与边界Necessity()原字段留空判断每个部件是否必要Specificity1–5提示词有多具体与长度无关过笼统则补约束与格式Prioritizationlist最该优先处理的 1–3 个类别把有限的改写精力聚焦到高杠杆处Conclusion≤30 词综合以上极简、命令式地说明要改什么、怎么改作为输出 Prompt 的处方这套清单的本质是先分类后处置Simple Change是一种短路机制避免对微小改动过度工程化而对复杂 Prompt则通过Complexity/Task/Specificity三个 1–5 评分、Ordering的 before/after 二值判断把改哪里、先改什么变得可操作。值得注意Prioritization是决策枢纽——所有诊断最终收敛为最多 1–3 个最重要的改进类别防止一次大而全的返工。三、Guidelines改进提示词的八条操作规范在reasoning之后、产出成稿之前Agent 还遵循一组写作规范即原文# Guidelines逐条拆解如下理解任务Understand the Task先抓住目标、需求、约束与预期输出评估不是从第一行开始就改最小改动Minimal Changes简单 Prompt 只做必要的精炼复杂 Prompt 则以增强清晰度、补齐缺失要素为纲不重排原有结构先推理后结论Reasoning Before Conclusions这是全文的硬约束且规定了反直觉的处置——如果用户示例里的推理发生在结论之后必须反转顺序绝不允许以结论开头。结论、分类、评分等结果永远放在最后Conclusions, classifications, or results should ALWAYS appear last示例Examples在有用时才加入高质量示例对复杂要素用[占位符]表示同时要自问需要哪类示例、几个、是否需要占位符清晰与简洁Clarity and Conciseness用具体语言去掉冗余指令与空话格式化Formatting用 Markdown 提升可读性且除非明确要求不得使用代码块保留用户内容Preserve User Content若输入中包含大量指南或示例应完整或尽可能接近地保留内容含糊时才考虑拆分子步骤用户提供的细节、变量、占位符不得丢弃常量Constants主动把指南、评分表rubrics、示例这类常量写进 Prompt——因为它们不会受提示注入影响输出格式Output Format显式规定输出格式与语法短句、段落、JSON 等输出结构化数据分类、JSON时偏向 JSON且除非明确要求 JSON 不得包裹在代码块内。其中第 3、第 8 条是最具方法论价值的两点前者呼应了让模型先思考再作答的工程经验后者则揭示了把评分表/示例作为不可注入常量写死在提示词中、而不是依赖对话中用户临时输入的做法用于提高稳定性和抗操纵性。四、输出结构模板可直接复用的 Prompt 骨架Agent 的最终产出必须严格遵循以下结构且不允许添加任何开场白/结尾注释连---分隔线都不允许[用一句话命令式描述任务——必须放在第一行不要小节标题] [按需补充的附加细节] [可选带标题或项目符号的详细步骤小节] # Steps [可选] [对完成任务所需步骤的详细拆解] # Output Format [明确输出格式长度、结构如 JSON、markdown 等] # Examples [可选] [1–3 个结构清晰的示例必要时用占位符明确标出示例起止以及输入/输出] [若示例短于真实用例用 () 说明真实示例应更长/更短/有何不同。务必使用占位符] # Notes [可选] [边界情况、细节以及需要重点重复强调的注意事项] [注意必须以 reasoning 开头你产出的下一个 token 就应是 reasoning]这个模板有几个刻意设计的点任务指令被强制放在首行且不带标题头确保模型第一眼读到做什么# Output Format独立成节把内容与形式解耦# Examples中的[输入]→[输出]对齐约定与占位符规则避免示例与真实场景脱节最后的# Notes充当边界情况回收站。模板末尾还内嵌了一条元指令——即使输出的是一份 PromptAgent 自身也必须以reasoning起手。五、在仓库工程中的位置与验证从工程侧看prompt-engineer.agent.md的身份由仓库的文档与脚本共同确认frontmatter 约定仓库的 CONTRIBUTING.md 规定.agent.md应包含description、可选model、tools、name等元数据本 Agent 只声明了description与name说明它是一款不依赖额外工具/ MCP 服务器的纯对话模式 Agent。自动收录机制仓库的 eng/generate-website-data.mjs 会扫描所有*.agent.md文件并从 frontmatter 提取name、description、model、tools、mcp-servers等字段生成站点数据eng/update-readme.mjs 也会据此重建 README 中的 Agent 索引表。这意味着本文件是仓库生成式目录体系中的一个正式条目。使用方式按 docs/README.agents.md 的说明可以直接点击 VS Code / VS Code Insiders 的安装按钮或下载*.agent.md文件加入自己的仓库之后通过 VS Code Chat 界面或 CCA 中指派启用。六、与相邻 Prompt 资产的协同关系在 awesome-copilot 中围绕提示词还有一组定位互补的资产理解它们有助于判断 Prompt Engineer 的适用边界Prompt Builderagents/prompt-builder.agent.md由 microsoft/edge-ai 提供走Builder Tester双角色协作路线会使用read_file、githubRepo、context7等工具做外部调研与强制验证适合需要结合代码库/文档产出的场景Prompt Optimizerskills/prompt-optimizer/SKILL.md一个面向聊天界面Chat/Codex/Copilot的技能产出单条可直接粘贴的最终 Prompt强调不发散、不用模板占位Prompt 文件编写指南instructions/prompt.instructions.md面向维护者规定可复用.prompt.md文件的 frontmatter 与写作规范关注可移植性与权限最小化。相比之下Prompt Engineer 的最大差异在于自带的reasoning诊断清单它不依赖外部工具检索而是依靠一套固定的评估维度简单性、推理顺序、结构、示例、复杂度、具体性、优先级进行结构化评审。因此它最适用于已有草稿 Prompt 需要被审出问题、复杂任务的提示词需要重新组织推理与结论顺序、以及希望把评审过程透明化以便人工核对改写的场景。使用时需注意其约束前提——由于 Agent 本身是纯文本指令实际推理质量仍取决于底层模型对 结构的遵循程度。若要在自己的仓库里直接启用最简单的方式就是把 agents/prompt-engineer.agent.md 下载到仓库根目录或按 VS Code 安装入口添加然后在 Copilot Chat 中选中该 Agent粘贴任意草稿 Prompt即可观察其先输出reasoning诊断、再输出成品系统提示词的完整流程。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考