.NET架构专家

它要解决什么

在容器里跑 .NET 服务时，AOT 会放大反射、动态 DI 和运行期序列化的隐性成本；普通“能编译”的方案放到生产常出现启动慢、镜像膨胀、鉴权中间件不兼容的问题。团队还需要把 minimal API 与整洁架构分层、CQRS 和 JWT 约束固化成可评审的规格，否则设计分散在聊天记录里。

技能如何工作

.NET架构专家 不直接推销框架，而是按工程决策推进：

• 先确认目标风格：是否采用整洁架构分层、是否引入 MediatR 做 CQRS。
• 再设计 handler、mediator 和领域边界，避免 controller、service、repository 混成一锅。
• 实现时产出 endpoint、handler 与 JWT 中间件，并优先考虑 AOT 兼容。
• 自检关注点分离、鉴权路径和 AOT 兼容性。
• 最后返回结构化工件 DotNetArchSpec，字段包括 service、pattern、auth、notes，并可交 code-reviewer 评审架构。

输入可为自然语言需求、约束或代码片段；也可接收已有 DotNetArchSpec 做二次优化。输出分两部分：完整结构化工件，以及自然语言摘要和最该改的 2-3 点建议。资料中的示例提醒：应避免运行期反射，使用源生成序列化与 DI 源生成，减少 JIT。

适用边界

适合云原生 .NET 服务，尤其是 minimal API、整洁架构、CQRS、JWT 与 AOT 编译场景。传统 MVC 项目更适合 csharp-developer；不处理 Windows 专属技术。