name: 构建 description: 智能 .NET 构建，支持模糊项目匹配和可选的 --fix 参数用于 MCP 驱动的错误解决 argument-hint: “[–project <name>] [–solution <name>] [–fix] [–configuration <config>]” allowed-tools: Bash, Read, Glob, Grep, Task, AskUserQuestion

/dotnet:build

智能构建命令，支持模糊项目/解决方案匹配和通过 MCP 研究的可选自动错误修复。

参数

从 $ARGUMENTS 解析参数：

标志	描述	默认值
`--solution <路径>`	目标解决方案（支持模糊/部分匹配）	自动检测
`--project <路径>`	目标项目（支持模糊/部分匹配）	无
`--configuration <配置>`	构建配置	Debug
`--fix`	使用构建修复代理自动修复错误	false
`--verbosity <级别>`	MSBuild 详细程度 (q, m, n, d, diag)	minimal
`--no-restore`	跳过恢复步骤	false

工作流程

步骤 1: 定位目标

如果指定了 --project：

使用 Glob 查找匹配的 .csproj 文件
如果是部分名称（例如，“Api”），匹配 *Api*.csproj
如果有多个匹配项，使用 AskUserQuestion 来澄清
如果是自然语言（例如，“the API project”），使用 Grep 搜索项目文件以获取上下文

如果指定了 --solution：

使用 Glob 查找匹配的 .sln 文件
与项目相同的模糊匹配逻辑

如果都没有指定：

在当前目录或父目录中查找 .sln 文件
如果找到多个解决方案，使用 AskUserQuestion 选择
如果没有解决方案，查找单个 .csproj

步骤 2: 运行构建

构造并执行构建命令：

dotnet build "<target>" --configuration <config> --verbosity <verbosity> [--no-restore]

捕获 stdout 和 stderr 以进行错误分析。

步骤 3: 分析结果

如果构建成功：

报告成功，包括构建时间和输出位置
列出任何警告（如果多，按类别分组）

如果构建失败且未指定 --fix：

清晰报告错误
按类型分组错误（CS*, MSB*, NU*）
建议运行带有 --fix 标志的命令

如果构建失败且指定了 --fix：

从输出中解析错误代码
提取相关上下文（文件、行号、错误消息）
生成 build-fixer 代理，带有错误上下文：

Task(dotnet:build-fixer, "修复以下构建错误：

错误：
<paste 解析的错误，包含文件路径和行号>

项目/解决方案：<target>
配置：<config>

通过 MCP 研究每个错误，应用修复，并报告所做的更改。")

步骤 4: 修复后重试（如果指定了 --fix）

在构建修复代理完成后：

再次运行构建
如果仍有错误，总共重试最多 3 次
报告最终状态，包括应用的修复列表

输出格式

成功：

构建成功，目标：<target>
  配置：<config>
  时间：<duration>
  输出：<path>
  警告：<count>（使用 --verbosity detailed 查看）

失败（无 --fix）：

构建失败，目标：<target>

错误（按类型分组）：
  CS1061: 3 个错误 - 成员不存在
  CS0103: 2 个错误 - 名称在上下文中不存在

运行带有 --fix 的参数以尝试自动解决。

失败（有 --fix）：

构建失败，目标：<target>

尝试自动修复...
  - 在 Foo.cs:42 修复了 CS1061（添加了缺失的 using）
  - 在 Bar.cs:15 修复了 CS0103（更正了拼写错误）

重试构建...
在 2 次修复迭代后构建成功。

示例

# 构建当前目录中的解决方案
/dotnet:build

# 构建特定项目，支持模糊匹配
/dotnet:build --project Api

# 构建并自动修复错误
/dotnet:build --fix

# 构建 Release 配置，详细输出
/dotnet:build --configuration Release --verbosity detailed

# 构建特定解决方案
/dotnet:build --solution MyApp.sln