新学期第一天刷到这个活动，正好把最近这段「把 TraeCode 用顺」的过程写下来。我不是学生，是一个在维护老系统的后端，但「上手」这件事对老开发同样成立——工具会用，和用得顺，是两回事。
一、我这次想解决什么
我负责的是一套企业内网的运维监控系统，其中一块是 SNMP Trap 告警接入：设备和中间件把 Trap 报文发过来，系统按配置表判断「这条 Trap 属于哪台机器、该转成哪条告警」。
原来的实现只支持逐条登记离散 IP。机房一个网段几十台机器，就得手工敲几十行配置，漏一台就少一路告警。这次要做的事很具体：
- 让告警源 IP 支持网段（CIDR）匹配，例如
10.0.28.0/24一行覆盖整段； - 已有的离散 IP 配置支持一键复制，减少重复录入；
- 顺手修掉一个老问题：报文字段映射规则里某个字段为空时，解析会直接抛异常，把整批 Trap 拖死。
二、我是谁，为什么这件事对我重要
我是后端开发，日常维护的是一套跨了好几年的 Java 系统：Spring 3.2.5、Struts2、Ant 构建，前端还是 JSP + DataTables。它的调用链是 JSP → Struts2 的 *.do → 内部 SDK → 后端服务，四层，并且积累了大量「没写在文档里、但全组都默认遵守」的约定。
这种系统最怕两件事：改错位置，和文档骗人。所以我对 AI 编程工具的期待，不是「帮我写新代码」，而是「帮我在别人写的旧代码里少踩坑」。
三、我是怎么把 TraeCode 慢慢用顺的
说实话最开始用得很糙，就是整段报错丢进去。它确实能把异常翻译成人话，这一步对看不懂堆栈的人非常值；但对我不够——它给的修改建议常常落在「看起来对、实际不是入口」的那个文件上，老项目里同名方法能有三四处。
第二步我改了提问方式：先不让它改代码，只让它讲链路。我会说「先别给补丁，把这个配置页从前端提交到最终落库，经过哪些文件、哪些方法列出来，带文件路径和行号，我来确认」。确认完再让它动手。定位准确率立刻不一样了——因为我把「猜」这一步，换成了「对账」。
第三步是被坑出来的。当时按内部文档写枚举值，文档上某个参数类型字段写的是 0/1/2，实际库里存的是 1/2/3。我把文档喂给它，它就顺着文档一起错。后来我加了一条固定动作：让它先核对真实数据、以及实际读取该字段的代码，再决定实现，别信任何一份「说明」。从那以后这类返工基本没再出现——顺便说一句，返工才是最烧积分的事，一次改对，比来回试五次便宜得多。
到这里我的用法基本定型，就三句话：
- 先讲链路，别先给补丁；
- 每个结论都要给文件 + 行号，我能点开核对；
- 涉及配置、枚举、表结构，先查真实数据，文档只当线索。
四、最后做成了什么，给后来的人一句建议
上面三件事都落地了：网段匹配上线后，一个 /24 网段一行配置搞定，录入量从几十行降到一行；离散 IP 配置支持复制；空字段解析加了保护，不会再因为一条脏报文拖垮整批 Trap。下一步在评估的是：不动 Struts2 主干，并行引入 Spring MVC，给外部系统开一组只读查询接口。
如果让我给下一个人一句建议：在你不熟的代码库里，先让它「讲」，别让它「改」。 让 AI 输出可核对的东西（路径、行号、调用顺序、真实数据），你的活儿就从「验证它写得对不对」变成「确认它找得准不准」——后者你一眼能判断，前者要花一下午。工具顺不顺手的分界线，其实就在这里。