射频同轴电缆衰减特性深度解析：原理、测试与选型
2026/9/12 16:56:55
GitHub Copilot 技能实战：基于 dotnet-design-pattern-review 的 .NET/C# 设计模式审查指南
【免费下载链接】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
导读
本文围绕开源仓库 awesome-copilot 中收录的dotnet-design-pattern-review技能（技能定义）展开，系统讲解如何借助 GitHub Copilot 对 C#/.NET 代码进行设计模式审查：先明确该技能要求核查的 7 类必备设计模式，再逐条展开 12 项审查清单，最后给出 5 大改进焦点与仓库内配套资源（姊妹技能、专家 Agent、插件安装方式）。读完本文，你将掌握一套可直接套用的 .NET 设计模式审查方法论，并理解其在当前仓库技能体系中的定位与组合用法。
一、技能定位：只审查、不改码的只读审查器
dotnet-design-pattern-review是仓库 skills 目录下的一个 Copilot Skill，其元数据如下（SKILL.md）：
--- name: dotnet-design-pattern-review description: 'Review the C#/.NET code for design pattern implementation and suggest improvements.' ---其核心工作方式（SKILL.md）为：
Review the C#/.NET code in ${selection} for design pattern implementation and suggest improvements for the solution/project. Do not make any changes to the code, just provide a review.
需要特别强调的约束有两点：
- 审查范围：
${selection}是用户在编辑器中选中的代码片段，或与之对应的解决方案/项目范围；技能的作用域是"当前选择"，而不是漫无目的地扫描整个解决方案。 - 只读原则：技能明确要求"不要对代码做任何修改，只提供审查意见"（Do not make any changes to the code, just provide a review）。这与本仓库中
dotnet-best-practices等审查类技能保持一致——审查类技能的产出是"建议清单"而非"补丁"。
二、七大必备设计模式：审查必须核对的骨架
原技能文档开篇即定义了解决方案/项目中"必须具备"的设计模式清单（SKILL.md）。审查的第一步，就是逐项核对这些模式是否真实落地，而不是仅仅"看起来用了某个名字"。
2.1 Command 模式（命令处理）
要求核对以下具体形态（SKILL.md）：
- 泛型基类
CommandHandler<TOptions>； - 配套接口
ICommandHandler<TOptions>； CommandHandlerOptions的继承体系；- 静态方法
SetupCommand(IHost host)用于命令注册。
配套技能 dotnet-best-practices 进一步印证了这一约定：应当"使用带泛型基类的 Command Handler 模式（例如CommandHandler<TOptions>）"。可以推断，这类命令处理器通常与 Microsoft.Extensions.Hosting / DI 容器配合，通过IHost完成命令的解析与生命周期管理。审查时应核对：基类是否承担了通用横切逻辑（校验、异常映射、日志），派生类是否只保留命令特有行为（开闭原则）。
2.2 Factory 模式（工厂）
要求核对"复杂对象创建"是否经由服务提供者集成（SKILL.md）。审查重点：
- 复杂依赖组合的对象是否封装了创建逻辑，而非散落在调用方；
- 工厂是否通过 DI 容器（
IServiceProvider/IServiceScopeFactory）解析依赖； - 工厂是否遵循与容器一致的对象生命周期（见下方 DI 一节）。
2.3 依赖注入（DI）
要求核对四项（SKILL.md），细节可结合 dotnet-best-practices 展开：
- 主构造函数语法（C# 12+）：如
public class MyClass(IDependency dependency)，避免冗长的字段赋值样板； - 空值校验：构造函数中对必填依赖使用
ArgumentNullException.ThrowIfNull(...)； - 接口抽象：面向接口编程，接口命名以
I前缀（接口隔离）； - 生命周期正确性：Singleton / Scoped / Transient 的选择要与对象真实使用范围匹配，避免 Scoped 服务被 Singleton 捕获造成"隐式作用域"问题。
2.4 Repository 模式（仓储）
要求核对"异步数据访问接口为连接提供抽象"（SKILL.md）。审查要点：
- 仓储接口是否全部为异步形态（返回
Task/Task<T>），且基于async/await（dotnet-best-practices）； - 数据访问是否使用参数化查询（防 SQL 注入，见 dotnet-best-practices）；
- 仓储层是否隔离了连接/事务管理细节，使上层只依赖领域接口。
2.5 Provider 模式（提供者）
要求核对"外部服务抽象（数据库、AI）、清晰契约、配置处理"（SKILL.md）。在当前仓库语境下，Provider 常指对 AI/ML 服务的封装——配套技能明确使用Microsoft.SemanticKernel进行 AI 操作，并实施内核配置与服务注册（dotnet-best-practices）。审查时应确认：Provider 对外暴露稳定契约，具体服务实现可替换（如测试时替换为模拟实现），敏感配置（API Key 等）不硬编码。
2.6 Resource 模式（资源本地化）
要求核对（SKILL.md）：
- 使用
ResourceManager提供本地化消息； - 独立的
.resx资源文件：日志消息（LogMessages）与错误消息（ErrorMessages）分文件管理； - 通过
_resourceManager.GetString("MessageKey")访问资源（dotnet-best-practices）。
仓库中另有专门技能 resx-source-generator-migration 讲解.resx的迁移改造（如从ResXFileCodeGenerator迁移到Microsoft.CodeAnalysis.ResxSourceGenerator），可作为 Resource 模式落地细节的延伸阅读——例如其中指出源生成器版本生成的是static partial访问器，而传统ResXFileCodeGenerator生成非静态类，审查资源相关代码时需留意这类访问方式的兼容性。
2.7 补充：未列出的模式是否缺失
清单第一项还要求判断"是否存在缺失的有益模式"（SKILL.md）。专家级 Agent expert-dotnet-software-engineer 给出的参考面更宽：Async/Await、Dependency Injection、Repository、Unit of Work、CQRS、Event Sourcing 以及 GoF 模式。审查时可根据业务复杂度提出增量建议（例如引入IUnitOfWork包装仓储事务、用IHttpClientFactory管理 HTTP 客户端等），但应避免为模式而模式。
三、十二项审查清单：逐条核对的检查表
原文档给出了完整的审查清单（SKILL.md），共 12 项。以下逐条给出审查要点：
| # | 清单项 | 审查要点 |
|---|---|---|
| 1 | 设计模式 | 已使用哪些模式？Command / Factory / Provider / Repository 是否实现正确？是否缺失有益模式？ |
| 2 | 架构 | 命名空间是否遵循{Core|Console|App|Service}.{Feature}约定？Core 与 Console 项目是否职责分离？模块化与可读性如何？（SKILL.md） |
| 3 | .NET 最佳实践 | 主构造函数、async/await与Task返回、ResourceManager使用、结构化日志、强类型配置（SKILL.md） |
| 4 | GoF 模式 | Command、Factory、Template Method、Strategy 等经典模式实现是否正确（SKILL.md） |
| 5 | SOLID 原则 | 五项逐一排查：SRP 职责单一、OCP 开闭、LSP 里氏替换、ISP 接口隔离、DIP 依赖倒置的违例点 |
| 6 | 性能 | async/await是否贯穿 I/O 链路、资源是否及时释放（IDisposable/IAsyncDisposable）、是否恰当使用ConfigureAwait(false)、是否存在可并行的处理机会 |
| 7 | 可维护性 | 关注点是否分离、错误处理是否一致、配置使用是否正确 |
| 8 | 可测试性 | 依赖是否经接口抽象、组件是否可 mock、异步是否可测、是否符合 AAA（Arrange-Act-Assert）模式 |
| 9 | 安全性 | 输入验证、凭据安全处理、参数化查询、异常信息是否避免泄露敏感细节 |
| 10 | 文档 | 公共 API 是否有 XML 注释、参数/返回值说明、资源文件组织是否合理 |
| 11 | 代码清晰度 | 命名是否体现领域概念、意图是否通过模式表达、结构是否自解释 |
| 12 | 整洁代码 | 风格统一、方法与类规模适中、复杂度最小、重复消除 |
关于第 3 项的"结构化日志"，配套技能明确要求使用Microsoft.Extensions.Logging，并通过 scope 携带有意义上下文（dotnet-best-practices）。关于第 8 项的测试栈，仓库约定为：MSTest + FluentAssertions 断言 + Moq 模拟、覆盖成功与失败场景、包含空参数校验测试（dotnet-best-practices）；但需注意仓库同时收录了 xUnit / NUnit / TUnit 等多个测试技能（见 csharp-dotnet-development 插件 的命令列表），实际审查时应以目标项目已采用的框架为准，不强求 MSTest。关于第 10 项的配置文档与强类型配置，见下文"改进焦点"中的 Configuration 一节。
四、五大改进焦点：给出可落地的行动建议
原文档在清单之外，专门圈定了 5 个"改进焦点"领域（SKILL.md），要求审查输出必须"结合项目架构与 .NET 最佳实践，给出具体、可行动的建议"。这 5 个领域是改进建议的优先级排序依据：
- Command Handlers（命令处理器）：在基类中集中做校验、统一错误处理、规范资源管理。这对应第 2.1 节中"基类承载横切逻辑"的落地检查。
- Factories（工厂）：依赖配置是否正确、是否与 DI 容器集成、销毁（disposal）模式是否完备——特别是工厂创建的对象是否由其负责释放，避免资源泄漏。
- Providers（提供者）：连接管理、异步模式、异常处理与日志记录。Provider 封装外部服务（数据库、AI），其连接生命周期与故障降级是审查重点。
- Configuration（配置）：数据注解与验证属性（如
Required、NotEmptyOrWhitespace）、强类型配置类 +IConfiguration绑定、支持appsettings.json、敏感值的安全处理（dotnet-best-practices）。审查时核对：配置类是否在启动时校验、非法配置是否快速失败、密钥是否放入用户机密/环境变量而非源码。 - AI/ML 集成：Semantic Kernel 模式、结构化输出处理、模型配置（ChatCompletion、Embedding 等）。配套技能要求"使用结构化输出模式以获得可靠的 AI 响应"（dotnet-best-practices），同时要求对 AI/ML 操作采用安全编码实践。
改进建议的产出形态应遵循原文档要求："Provide specific, actionable recommendations"——即每条建议都应指明具体文件/类型/方法、问题原因、建议改法，而不是泛泛的"建议遵守 SOLID"。
五、使用方式与仓库内配套资源
5.1 如何在 Copilot 中触发该技能
该技能位于 skills/dotnet-design-pattern-review/SKILL.md，属于仓库 skills 集合的一部分。使用方式为：在编辑器选中待审查的 C#/.NET 代码（对应${selection}），通过支持 skills 的 GitHub Copilot 环境调用该技能，随后 Copilot 会按上文骨架输出结构化审查意见。本仓库还收录了技能加载与规范类说明文档，可参考 docs/README.skills.md 与 instructions/agent-skills.instructions.md 了解 skills 的编排与约束机制。
5.2 与姊妹技能 dotnet-best-practices 的分工
仓库中的 dotnet-best-practices 与本技能同属 .NET 审查体系，二者互补：
dotnet-design-pattern-review：聚焦设计模式与架构层面（模式是否正确落地、架构是否清晰、SOLID 是否违例），是本文主体；dotnet-best-practices：聚焦代码规范与工程实践（XML 文档、async/await、测试栈、配置绑定、Semantic Kernel、日志），并提供更多实现级细节，例如主构造函数示例、ArgumentNullException校验、_resourceManager.GetString("MessageKey")访问方式等（skills/dotnet-best-practices/SKILL.md）。
实际评审流程中可先用本技能做模式层审查，再配合dotnet-best-practices做规范层审查；也可组合专家 Agent 获得更全面的判断。
5.3 配套 Agent 与插件
仓库为 .NET 审查提供了更高阶的配套：
- 专家 Agent expert-dotnet-software-engineer.agent.md：以"专家工程师模式"给出设计模式（含 GoF、CQRS、Event Sourcing）、SOLID、TDD/BDD（xUnit/NUnit/MSTest）、性能、安全五方面的指导，可作为本技能审查结论的扩展视角；
- 插件 csharp-dotnet-development：将
dotnet-best-practices等技能打包为斜杠命令，并提供expert-dotnet-software-engineerAgent。可通过如下命令安装（plugins/csharp-dotnet-development/README.md#L6-L11）：
copilot plugin install csharp-dotnet-development@awesome-copilot安装后即可在 Copilot 中通过/csharp-dotnet-development:dotnet-best-practices等命令触发对应的审查与最佳实践提示（plugins/csharp-dotnet-development/README.md#L18-L27）。
六、结语：把审查从"找茬"升级为"带证据的改进清单"
dotnet-design-pattern-review的价值在于它把一次代码评审固化为可重复执行的检查流程：先核对 7 类必备模式是否真实落地，再按 12 项清单逐条排查，最后在 5 大焦点领域给出按优先级排列的、与项目架构对齐的行动建议。配合仓库内 dotnet-best-practices、expert-dotnet-software-engineer 与 csharp-dotnet-development 插件，即可在 GitHub Copilot 中搭建一套覆盖"模式层 + 规范层 + 专家层"的完整 .NET 代码质量审查工作流。
【免费下载链接】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），仅供参考