Good Example【免费下载链接】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// Recommended approach code example hereBad Example// Avoid this pattern code example here### 4. 验证与校验可选但推荐 - 用于验证代码的构建命令 - Linting 与格式化工具 - 测试要求 - 验证步骤。 例如一份 Rust 指令可以要求提交前运行 cargo fmt --check 与 cargo clippy -- -D warnings把质量门槛写进指令本身。 ## 写作风格让指令可扫描、可执行、不模糊 ### 语言与语气 - 使用清晰、简洁的语言 - 使用祈使句Use、Implement、Avoid - 具体、可行动避免 should、might、possibly 等含糊词 - 多用项目符号与列表提升可读性 - 保持小节聚焦、便于快速扫描。 ### 六条最佳实践 1. **Be Specific具体**给出具体示例而非抽象概念 2. **Show Why说明理由**当解释背后的原因有价值时务必解释 3. **Use Tables善用表格**适合对比选项、罗列规则、展示模式 4. **Include Examples包含示例**真实代码片段远比描述有效 5. **Stay Current保持更新**引用当前版本与最新最佳实践 6. **Link Resources链接资源**附带官方文档与权威来源。 ### 指令海拔Instruction Altitude金发姑娘地带 编写指令最核心的取舍是**规则密度**。原则是 - 从能完整定义预期结果的最小规则集出发 - 只有观察到失败后才增加约束而不是预先堆砌假设性边界情况 - 优先使用高信号示例而非穷举式决策表。 三种海拔的对比 | 海拔 | 失败模式 | 结果 | | --- | --- | --- | | 过度指定Over-specified | 脆弱的 if-else 散文 | 遇到未列举的情况即失效 | | 指定不足Under-specified | 假设共享上下文 | 输出泛化、千篇一律 | | 恰到好处Right altitude | 启发式 示例 | 稳定、可泛化的质量 | 这一节是全文最值得反复揣摩的方法论**指令是守门员而非剧本**——它约束边界、提供参照但不试图穷举所有可能性。 ### 常见模式清单 一份内容完整的指令通常覆盖以下六类模式 1. **命名约定**变量、函数、类、文件如何命名 2. **代码组织**文件结构、模块划分、导入顺序 3. **错误处理**偏好的错误处理模式 4. **依赖管理**如何管理与记录依赖 5. **注释与文档**何时写、如何写 6. **版本信息**目标语言/框架版本。 ## 行文范式可直接复用的四种 Markdown 结构 ### 1. 项目符号与列表Bullet Points 适用于逐条规则例如安全最佳实践 markdown ## Security Best Practices - Always validate user input before processing - Use parameterized queries to prevent SQL injection - Store secrets in environment variables, never in code - Implement proper authentication and authorization - Enable HTTPS for all production endpoints2. 表格承载结构化信息Tables适合问题 → 方案 → 示例的对照## Common Issues | Issue | Solution | Example | | ---------------- | ------------------- | ----------------------------- | | Magic numbers | Use named constants | const MAX_RETRIES 3 | | Deep nesting | Extract functions | Refactor nested if statements | | Hardcoded values | Use configuration | Store API URLs in config |3. 代码对比Code Comparison好/坏示例并排让 Copilot 明确边界。以下 TypeScript 示例展示类型安全优先interface User { id: string; name: string; email: string; } function getUser(id: string): User { // Implementation }function getUser(id: any): any { // Loses type safety }4. 条件式指导Conditional Guidance当规则因场景而异时使用为不同规模/场景分别给出建议的写法## Framework Selection - **For small projects**: Use Minimal API approach - **For large projects**: Use controller-based architecture with clear separation - **For microservices**: Consider domain-driven design patterns必须避开的七个反模式过度冗长的解释保持简洁、可扫描过时信息始终引用当前版本与最新实践含糊的指导明确告诉 Copilot 该做什么或不该做什么缺少示例只有抽象规则而没有具体代码自相矛盾的建议保证全文件一致性从文档照搬不要复制粘贴官方文档应通过提炼与语境化增加价值假设性规则膨胀不要为尚未发生的失败添加规则——这与前文最小规则集原则一脉相承。测试你的指令发布前验收三步走在把指令文件提交到仓库之前务必用 Copilot 实测在 VS Code 中用真实 prompt 尝试这些指令验证示例确保代码示例正确、可运行无报错检查 glob 模式确认applyTo模式确实匹配到预期文件。在 awesome-copilot 仓库内提交还有一道工程化关卡npm run build会调用 eng/update-readme.mjs 与 eng/generate-marketplace.mjs 重新生成 README 与市场索引eng/generate-website-data.mjs 则负责解析每条指令的description与applyTo并写入站点数据。因此新指令文件若 frontmatter 不规范会直接反映在构建产物中。此外 AGENTS.md 的 Code Review Checklist 明确要求指令文件必须有 frontmatter、description非空且单引号包裹、applyTo提供文件模式、文件名小写连字符——这四项也是评审阶段的硬性检查项。最小可用模板直接开写的起点综合前述结构一份新指令文件的最小骨架如下--- description: Brief description of purpose applyTo: **/*.ext --- # Technology Name Development Brief introduction and context. ## General Instructions - High-level guideline 1 - High-level guideline 2 ## Best Practices - Specific practice 1 - Specific practice 2 ## Code Standards ### Naming Conventions - Rule 1 - Rule 2 ### File Organization - Structure 1 - Structure 2 ## Common Patterns ### Pattern 1 Description and example language code examplePattern 2Description and exampleValidationBuild command:command to verifyLinting:command to lintTesting:command to test【免费下载链接】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），仅供参考