我是 C#/.NET 开发，干了15年，最近被调到运维保障组，专门接历史项目的"历史债"。手上这个 OA 系统跑了8年，早期 .NET Framework 4.5 + WebForms 搭的，中间换过几拨人，代码风格五花八门，属于典型的"自己写的代码自己都不想碰"。
这次任务其实不大：报销审批要按金额分级，比如 1 万以内部门主管批，1 万以上加一道财务总监。听着简单，但落点在一个被全项目几十处调用的公共方法上。这个方法一个方法体塞了 200 多行，里面既有 SQL 拼接、又有存储过程调用、还有几个字段用字符串 DateTime 比较做判断，层层嵌套，没有任何单测。领导一句"顺便改一下就行"，懂的都懂——这玩意儿才是真正的"随碰谁死"。
我是怎么用 TraeCode 解决这件事的
我用的是 IDE 模式，关键几处交给了 Agent。老规矩，先让它摸清全局，再谈动手。
第一步：让 TraeCode 先梳理影响面，而不是直接开改 我没有一上来就让它改代码，而是先用 @Workspace 把项目喂给它：
提示词：
@Workspace 分析一下 PeiShenShenPi() 这个方法，找出它在整个解决方案里所有被调用的位置和调用链，列一份改动影响面清单，标注哪些改动风险高、哪些调用是死代码永远不会走到。
它把调用关系拉成了一张清单，还标出了几处从 2019 年就没人触达的死分支。这一步帮我确认了"改了到底影响谁"，心里有底了。
第二步：让它把改动方案做保守化 我看完清单，才让它出的方案。这里我特意加了约束，不指望它大动干戈：
提示词：
请生成一个保守的改动方案：保持原有方法签名和返回结构不变，只增加金额分级的判断逻辑，风格贴合当前老代码，不要做 Async、不要引入新的 ORM，改动面控制在影响最小的那处调用上。
它给了一个"在方法入口加分级路由、原逻辑下沉"的思路，比我自己想的还稳。
第三步：动手改 + 它辅助排查 方案定了，我让它去定位具体文件行号改，改完本地点了一遍核心流程的入口。这时候确实出事了——编译过了，但一个和 DateTime 字符串比较的分支表现不对。我直接把问题丢回去：
提示词：
现在金额>=1万 的报销单没有走到财务总监审批分支，排查一下是不是这段字符串日期/金额比较的类型问题。
它很快指出是金额判断里把值当成了字符串在比较，改成了 decimal 后再测就对了。这个坑要是自己扑能扑一上午。
成果展示
- 需求落地：分级审批逻辑上线到测试环境，经手回单走的流程正确，联调通过、当天提测。
- 交付了一份改动影响面清单 + 变更说明，直接甩给同事 review，省得我再口头讲一遍"动了哪、会不会炸"。
- 意外收获：排查中确认了两处 2019 年以来"永远不会被调用"的死代码，暂时不影响功能，但给后续清理留了依据。
效率对比
- 以前：接这种老项目，先自己翻半天调用链，理清楚"改了会炸哪些地方"就耗掉半天；真动手改还得小心翼翼，改完回滚的风险全在个人身上。整个流程没两天下不来。
- 现在：让 TraeCode 半小时内把影响面给你画清楚，方案保守可控，改完还能自己出 bug。我从"战战兢兢的手工挖掘"变成了"先审清单、再复核关键改动"，1 天内完成定位、修改、排查、提测。
经验和技巧总结
- 改屎山，先让它"考古"再让它"施工"：一定先用
@Workspace建立全局认知、输出影响面清单，确认改动边界，比直接让它改代码重要得多。改错了回滚才是最伤人的。 - 老项目要故意"反 AI"一点：明确告诉它"保持老代码风格、不引入新框架、别做 Async"，免得它给你一顿现代化重构，好看是好看，上线没人敢拍板。
- 判断类型的坑直接丢给它：老代码里字符串日期/金额比较这种鬼问题，描述清楚现象丢回去，它定位+修复比人肉排查快得多，省下的时间全是加班时间。