Appearance
用 AI 分析 MSBuild Binary Log（V10）
Binary Log 是构建问题的专项证据，不是每次编译失败都要生成的固定步骤。
V10 推荐：
text
普通编译错误能直接定位？
├─ 能 → 修对应代码 / 配置
└─ 不能
↓
构建流程、target、条件属性、生成文件、依赖关系不清？
├─ 是 → Binlog
└─ 否 → 使用更便宜的证据1. 什么时候值得升级到 binlog
适合：
- 同一仓库在一台机器能构建、另一台不能；
- Debug 正常、Release/Publish 异常；
- XAML/resource/generated source 错误来源不清；
- 条件属性、TargetFramework、RuntimeIdentifier、Platform 造成差异；
- 多项目依赖失败，控制台最后几十行只是连锁错误；
- E-SafeNet/DLP/生成目录异常，需要看哪个 target 首先读到了污染文件；
- 近期构建回归，需要比较 known-good 与当前执行路径。
通常不需要：
- 明确的
CSxxxx普通源码错误； - 已经知道缺哪个 using/类型/文件；
- UI 文案等 V0 任务；
- 当前失败已经明确是同 fingerprint 的已知环境阻断。
2. 先保留原始构建命令
SDK 风格项目示例：
powershell
dotnet build YourProject.csproj -c Debug -bl:artifacts/build-debug.binlog重点不是命令必须长这样，而是保留同一构建入口：
text
Command
Configuration
Platform
SDK / MSBuild version
WorkingDirectory
Environment variables（必要项）
ExitCode
FirstFailureTime分析前不要同时“清 bin/obj、换 SDK、升级包、改代码、换配置”，否则新的成功/失败无法归因。
3. 先找 first build failure，不要盯最后一个错误
构建日志也有时间线。
推荐追：
text
Project
→ Target
→ Task
→ Input / Property
→ First Failure
→ Downstream Errors最后一个 Build FAILED 没有诊断价值；后续十几个错误也可能只是第一个 target 失败后的连锁反应。
这和现场日志的 first anomaly 思路一致。
4. Regression：能比较 known-good binlog 更有价值
如果用户说“昨天还可以构建”：
text
known-good command + binlog
vs
current command + binlog优先比较：
- SDK / MSBuild / workload；
- 项目导入；
- 条件属性；
- Package/Reference；
- target 是否新增/跳过；
- generated inputs；
- 输出/中间目录；
- 第一个失败 target/task。
不要因为当前 binlog 里某个旧 target 很复杂，就直接认定它是本次回归根因。
5. E-SafeNet / DLP 要先区分环境证据与代码证据
已知保护环境可能出现：
text
MSB3541
Null character in path
CS2015
生成文件乱码/异常内容
FileListAbsolute 污染binlog 可以帮助确认污染第一次在哪里进入构建链，但不要据此改业务代码。
如果同一代码 fingerprint 已经有充分证据表明是保护软件/权限/构建环境造成：
text
VerificationState: EnvironmentBlocked优先复用已知处理路径，而不是每个 UI 小改都重新生成大 binlog。
6. 隐私与敏感信息
binlog 可能包含：
- 本机绝对路径、用户名；
- 内部项目名和包名；
- NuGet 源；
- 环境属性；
- 服务器/目录信息；
- generated file 路径和任务输入。
外发前必须按项目规则确认。
不能外发时优先：
- 本地 Binlog 工具；
- 公司允许的内部 Agent；
- 脱敏最小复现项目；
- 提取 first failure 周围必要信息，而不是上传完整日志。
7. AI 分析输出应区分 Evidence / Inference / Unknown
可以要求：
text
请分析这份 MSBuild binlog。
目标：解释当前构建为什么失败，不要先建议重装环境。
请输出：
1. first failing project / target / task；
2. 直接导致失败的输入/属性/依赖；
3. Evidence；
4. Inference；
5. Unknown；
6. 一个最小可证伪实验。只说“缓存问题”“依赖问题”“环境有问题”不够。
8. 常见上位机场景
| 现象 | 先看 |
|---|---|
| WPF XAML 编译失败 | MarkupCompile、generated XAML/code、重复 include |
| 原生 DLL 找不到 | Platform、RID、Copy/Resolve target、x86/x64 |
| Debug/Release 不同 | Condition、DefineConstants、Reference、Publish target |
| E-SafeNet 异常 | first polluted generated input / FileList / obj target |
| CI 与本机不同 | SDK/workload、env、path、restore source |
| 厂商 SDK 构建失败 | target framework、native assets、platform、copy/deploy |
9. 修复后先重复“同一个构建信号”
推荐：
text
失败命令 + old binlog
→ 最小修改
→ 同一命令
→ new binlog
→ first failure 是否消失不要修改后换一条更宽松的命令来证明“已经好了”。
10. Build 绿了以后，不自动升级成全套测试
构建问题修复后的下一步取决于这次实际改了什么：
| 实际修改 | 后续 |
|---|---|
| 纯 build 配置 / 项目文件且行为不变 | V1/V2 对应 affected verification |
| 依赖升级可能改变业务行为 | focused tests / Replay |
| 协议/数据/设备语义变化 | V2 |
| lifecycle / state / stop/recovery | V3 |
| 主框架/发布/广泛兼容 | V4 checkpoint |
不是：
text
binlog 修好
→ 自动全 solution test
→ 自动真机回归需要真机/HITL 但当前未执行时记录 HardwarePending。
11. 结果状态
构建专项可以使用：
text
Build: Verified
Build: Unverified
Build: EnvironmentBlocked如果软件侧构建已经通过，但后续现场设备验证仍待执行：
text
Build: Verified
Hardware: HardwarePending不要把“构建已恢复”写成“功能/设备已经全部验收”。
12. 和其它流程怎么衔接
- 普通源码 Bug / 回归：C# 报错与 Bug 定位
- 多源运行日志：日志与时间线诊断
- E-SafeNet：加密软件环境注意事项
- 测试范围：AI 辅助测试与回归
- 旧 .NET 迁移：旧项目现代化
一句话原则
Binlog 用来解释构建链为什么失败；先找 first failure，再用同一构建信号验证修复，之后是否继续测试由实际 Task Delta 决定。