1. 我是谁，以及我遇到了什么问题
我是一名 Java 后端开发，日常主要写 Java 服务和自动化测试脚本，对 C# 只能看懂少量代码。最近公司安排我负责一款 .NET 探针的升级工作（具体项目不便透露），任务链路很长：改 C# 源码、跑多平台打包、构建多发行版多架构（x64 / arm64）的 Docker 靶机镜像、最后在几十个容器环境里做全量漏洞检测验证。
最大的障碍是：整个构建体系（C# 工程 + bash 脚本 + PowerShell 脚本 + Dockerfile）对我来说完全是陌生的，光是把“从源码到产物”的链路看明白，按传统方式估计就要耗掉一周。
2. 我是怎么用 TraeCode 解决这件事的
我采用 SOLO 模式做整体规划 + IDE（Chat）模式做精确修改 的搭配，四个步骤推进：
- 第一步：让它先把构建链路讲给我听。
提示词：@Workspace 这个仓库是一个 .NET 探针项目，请梳理从源码到最终产物的完整构建链路：入口脚本有哪些、依赖关系是什么、产物输出到哪里，用 Java 工程的术语（如 mvn package）类比解释。
它输出了完整的链路图：哪个脚本负责编译、哪个负责打 Docker 镜像、哪个负责部署验证，我半天就有了全局认知。 （此处建议放一张链路梳理的对话截图）
- 第二步：小步修改构建脚本，支持新平台。
我不说“帮我改好”，而是每次只提一个点：我要在打包脚本里增加对某个国产发行版镜像的支持，应该改哪个文件的哪一段，给出理由。 它给出精确修改位置，我逐条核对后应用，改完立即验证。
- 第三步：运行时报错直接甩给它。
验证阶段探针在容器里抛空引用异常，我对着堆栈毫无头绪。提示词：探针启动后报 NullReferenceException，堆栈如下……结合源码定位根因并给出修复。 它定位到问题类，还顺带用 Java 概念给我解释了 C# 可空类型的差异。同类问题还包括“探针就绪时序”导致的验证误判，让它加了一段轮询等待逻辑解决。
- 第四步：整理变更、生成可提交结果。
让它基于本次全部改动生成变更说明和规范的提交信息，方便接手的同事理解。
3. 成果展示
- 交付了升级后的探针多平台打包产物，并跑通了多发行版（debian / ubuntu / centos 系等）× 双架构（x64 / arm64）的靶机镜像构建；
- 漏洞检测验证矩阵在全部环境执行完毕，通过后端校验确认检出结果完整；
- 排查并修复了 2 个升级过程中暴露的问题（空引用异常、就绪时序），全部改动已提交并投入日常使用。
4. 效率对比
- 以前怎么做：先自学 C# 和 .NET 构建体系，再逐个脚本啃构建链路，遇到运行时报错靠搜索引擎 + 猜，保守估计整条任务要 2-3 周。
- 现在怎么做：TraeCode 当“讲解员 + 执行者”，我充当架构师做关键决策和 Code Review，从上手到全量验证通过只用了约一周，其中链路梳理半天、脚本改造和排障各占一两天。
5. 经验和技巧总结
- 跨语言接手项目，先让它“讲”再让它“改”：用母语技术栈的概念类比（Java → C#）让 AI 解释项目结构，理解成本骤降，且生成的代码才符合项目既有规范。
- 小步提问优于大而全的指令：“改一个点 + 给理由”比“帮我全改好”返工率低得多，每一步自己核对过，心里才有底。
- 运行时排错优先给现场证据：堆栈 + 可疑源码一起贴，比只贴报错信息一次定位率高很多。