我是谁，以及我遇到了什么问题
我是公司的开发工程师，负责维护一套内部自动分析系统。它每天会接收一批数据文件，跑我们自研的处理引擎，自动给出结构化结论，我再人工复核这些结论是否准确，并整理成日报。
这套系统上线几个月了，但最近我连续发现几个"不对劲"：
- 同一个数据文件，这两天被重复处理、重复出结果（换个文件名重新上传而已）；
- 某条记录显示"连续触发 301 次"，我人工数了下原始数据，实际独立事件只有约 11 轮——计数虚高；
- 一类"可修正、不影响主流程"的异常，被一律标成高优先级、混进重点清单；
- 手机上打开系统导出的 HTML 报告，折叠的条目点不开。
单看都不大，但叠加起来会误导处理优先级。修哪一个、动哪一行，我心里没底——这是一套我接手不久、结构很重、几乎没注释的旧代码。
3. 我是怎么用 TraeCode 解决这件事的
我主要用的是 SOLO 模式（批量跑批、终端脚本、并发回归这些环节），中间穿插 IDE 模式看代码。大致四步：
第一步：让 TraeCode 先理解项目和需求。 我先说清楚"这是内部数据分析系统，我每天都做结果复核，先别改代码，帮我把最近一周的结论重新核一遍"。它先读取项目里的交接文档和状态文件，再对 7 天里每条记录逐条回看原始证据。
第二步：让它定位问题、给出修复方案。 核对完它列出一份问题清单：重复处理、计数虚高、分级不明确、报告缺历史标记、手机端折叠失效。我让它出一份书面修复方案，并另找一个"专业人士"视角去审这份方案（相当于双人复核），验证口径定了才动手。
第三步：分区实施修复，再批量验证。 修完我没有只拿几条数据验证，而是让 TraeCode 写了个批量回归脚本，从历史样本库里按类型分层抽 300 条、7 进程并发重跑，逐项统计改动是否生效。
第四步：整理变更、发布上线并归档。 把修复后的核心文件通过接口更新到线上，逐个核对文件校验值一致；最后生成一份给领导看的 HTML 演进报告和一个新版源码包。
4. 成果展示
- 7 天结果全部重新核对，核心结论均确认无误，同时揪出 3 处数字/表述偏差和 1 个流程问题；
- 6 个问题全部修复落地：数据去重、计数去重、分级逻辑、历史标记、误报拦截、手机端折叠；
- 300 条真实数据回归：296 成功（4 条是源文件本身损坏，与修复无关），关键字段 100% 生效；
- 核心文件更新到线上并逐一校验，配置热加载后立即生效，服务运行正常；
- 交付了 HTML 演进报告 + 158 个文件的新版源码包，直接发给领导汇报；交接记录和状态文档也都更新好，同事接手时扫一眼就能进入上下文。
5. 效率对比
以前的做法：发现问题 → 自己翻引擎代码、对着逻辑抠 → 自己写临时脚本验证 → 靠直觉判断有没有引入新问题。"计数虚高"这类点，过去至少要大半天，而且只敢修一个看一个。
现在的做法：把"核对结论 → 定位代码 → 出方案 → 批量验证 → 上线核验 → 归档"整条链路交给 TraeCode：
| 环节 | 以前 | 现在 |
|---|---|---|
| 7 天结果旁证 | 手动逐条核对，约 2 天 | 一次性回读核对，半天内 |
| 定位 + 出方案 | 逐个功能翻代码，约 1 天 | 问题清单 + 方案 + 双人评审，约 2 小时 |
| 回归验证 | 挑 5~10 条人工对照 | 300 条自动并发跑，约 30 分钟 |
| 文档/汇报 | 手工整理多次返工 | 记录、版本、演进报告一次性生成 |
整体上，这轮工作从预估的 3~4 天，压缩到了 1 天内闭环。
6. 经验和技巧总结
- 先给上下文再让它动手，效果远好于直接下命令。 让它先读交接文档和状态文件，它就能沿用项目既有规则、不乱改，也能在历史脉络里发现"重复处理"这类流程问题。
- 批量回归务必走独立脚本 + 断点续跑。 长时间跑批按条增量落盘、中断可续，比一次性跑完可靠得多，跑完再聚合统计。
- 描述需求时把"验收口径"写进提示词。 直接告诉它"计数按秒去重、历史事件带时间字段、某类要降级"，一句话省掉一整轮返工。