template-comparison

模板比较

此技能可帮助 Agent 并排比较 2 个或更多 dotnet new 模板，以便用户选择合适的模板。它会检查每个模板的参数和功能支持情况，并生成比较表。

适用场景

• 用户正在相似的模板之间做选择（例如，webapi 与 webapp、blazor 与 blazorwasm）
• 用户询问“我应该用哪个模板来实现 X？”
• 用户想在创建项目之前了解两个或更多模板之间的差异

不适用场景

• 用户想创建项目 — 转到 template-instantiation
• 用户想编写或验证自定义模板 — 转到 template-authoring 或 template-validation
• 用户只需要查找或检查单个模板 — 转到 template-discovery

输入

输入	必填	说明
模板短名称	是	要比较的两个或更多模板短名称（例如，webapi、webapp）
比较重点	否	可选的重点方面（身份验证、AOT、框架、交互性）

工作流

证据约定： 只有当每项选项声明都以当前已安装的模板为依据时，并排比较表才有用。按顺序运行每个 --help 命令，针对每个模板收集相同的所需维度，并将不可用的选项标记为 Not exposed，而不是猜测或借用其他模板的标志。

决策约定： 根据用户说明的决策需求优化比较，而非追求表格大小。涵盖所有请求的维度，省略无关的选项行，给出针对具体场景的理由，并在能让建议付诸行动时，为推荐的起点提供一条安全的 --dry-run 命令。

步骤 1：检查每个模板

对正在比较的每个模板运行 dotnet new <template> --help，收集其参数（名称、类型、默认值、可选值）和支持的框架：

dotnet new webapi --help
dotnet new webapp --help

如果某个模板未安装，请查找其提供程序并报告缺少的前置条件。只有在用户要求你修改环境或批准安装时，才安装它。

按顺序运行 --help 调用。 模板引擎使用全局互斥锁，因此并发运行多个 dotnet new <template> --help 命令可能会失败，并出现暂时性的“mutex”/“persistence”错误和空输出。一次检查一个模板；如果调用失败，在继续之前重试一次，并仍根据已有的参数信息生成比较，不要以无答案告终。

步骤 2：生成比较表

生成并排比较表，涵盖：

• 参数 — 名称、类型、默认值、可选值
• 功能支持 — 身份验证、AOT、Docker、控制器、交互性
• 可用框架 — 例如，net8.0、net9.0、net10.0
• 分类 — 模板声明的类别（Web、API、Blazor 等）

每个请求的决策维度使用一行，并在单元格中注明观察到的选项名称。如果某一行具体询问模板生成或公开的内容，不要用通用框架知识来填写。

当用户询问生成的依赖项，但不允许创建项目时，请检查已安装模板包的源 .csproj 文件。--help 和 --dry-run 不会显示包引用。不要为了检查而创建临时项目，也不要猜测当前的包 ID 或测试平台默认值。

示例格式：

方面	webapi	webapp
身份验证（--auth）	None、Individual、SingleOrg、Windows	None、Individual、SingleOrg、……
AOT（--aot 标志）	如果 dotnet new webapi --help 列出 --aot，则表示支持	如果 dotnet new webapp --help 列出 --aot，则表示支持
控制器（--use-controllers）	是	不适用
交互性	不适用	不适用
框架	net8.0 / net9.0 / net10.0	net8.0 / net9.0 / net10.0
分类	Web、WebAPI	Web、Razor Pages

第 3 步：推荐

最后用一行明确的 推荐 收尾——不要只给用户一张表。格式如下：

推荐：<template> — 用一句话说明该选择如何契合用户描述的场景。（如果满足 <condition>，则选择另一个。）

然后链接到 template-instantiation 来创建它。如果比较以未明确胜出者（或未清晰说明“取决于 X”）的方式结束，就不完整——这种犹豫会让此技能与普通回答相比毫无优势。

常见选项对的决策捷径

仅将这些捷径用于推荐，不要把它们当作当前参数支持情况的证据。填写比较表前仍须使用 --help 检查：

选项对	默认选择	原因
webapi 与 webapp	JSON/REST 后端选 webapi；服务端渲染 HTML/Razor Pages 选 webapp	webapi 提供控制器/最小 API 和 OpenAPI，不含 UI
blazor 与 blazorwasm	无需服务器或需要离线运行时选 blazorwasm；需要灵活的服务端与客户端交互时选 blazor（Web App）	独立 WASM 完全在客户端运行，支持离线
worker 与 console	长期运行/队列/后台处理选 worker	Generic Host 提供 DI、日志记录、配置、正常关闭和 IHostedService 生命周期
mvc 与 webapp	面向页面的应用选 webapp（Razor Pages）；需要大规模控制器/视图分离时选 mvc	对 CRUD 风格的页面而言，Razor Pages 更轻量

以下约束优先于上述简要建议：

• 如果用户明确预计应用规模较大，或需要共享控制器逻辑，即使最初的页面以 CRUD 为主，也应选择 mvc。
• 如果丰富的交互式表单是核心需求，同时又需要在首次响应中返回可用的 HTML，则应选择 启用 Server 交互性的 blazor，而不是 webapp。说明初始渲染由服务器生成，交互式组件使用 Blazor 表单/组件模型，而非 Razor Pages PageModel。
• 如需 离线支持，请选择 blazorwasm，并说明 PWA/service-worker 要求、首次加载后缓存的行为，以及执行时不需要实时服务器。
• 如需 持久化队列处理器，请选择 worker，并将这一决定与 Generic Host 生命周期、依赖注入、配置、日志记录、正常关闭以及真正持久化的队列（而非内存循环）联系起来。

验证

• 已通过 dotnet new <template> --help 检查所有请求的模板
• 比较涵盖参数、功能支持、框架和分类
• 明确指出与用户场景相关的差异
• 给出推荐（或明确的权衡说明）
• 对不受支持或不存在的选项进行标注，而非猜测
• 最终推荐以一行明确的 Recommendation: 开头

常见陷阱

陷阱	解决方案
凭记忆比较未安装的模板	安装并检查每个模板，确保比较反映实际参数和选项。
假设功能一致	参数名称和功能支持因模板而异——使用 --help 逐一确认。
比较本质上不同的模板类型	仅比较解决相近问题的模板；若它们面向不同场景，则应注明。

更多信息

• dotnet new 模板 — 内置模板参考
• dotnet new — CLI 参考