1. 我是谁，以及我遇到了什么问题
我在某券商做数字化转型。前段时间同事离职，我接手了他负责的一套行情采集服务：订阅国内某金融市场的经纪最优报价和逐笔成交行情，解析后异步写入数据库。服务本身不大，主代码只有八个类，但踩坑点全在“看不见的地方”：
- 文档和代码严重对不上。README 里写的是 MySQL，我进 pom.xml 一看，实际是 OceanBase 的 Oracle 兼容模式；README 里的包名也和源码对不上。等于交接文档从第一行起就不可信。
- 协议细节没有沉淀。解析逻辑依赖一个私有行情协议的快照消息，里面有报价/成交混合分组、按某个字段值分流、空分组表示撤单这类隐晦约定，前任脑子里有，文档里没有。
- 配套交付物缺失。团队要求补齐架构图、数据流图、ER 图、配置说明和测试报告，作为后续接手人的交接材料。
一句话：不是从 0 写代码的任务，是“把一个能跑但没人说得清的存量系统变成能交接的系统”。
2. 我是怎么用 TraeCode 解决这件事的
主要用 IDE 模式，中间画架构图时用了一个专门的制图能力。整个过程分四步：
第一步：先让 AI 摸清“真实的架构”，而不是 README 里的架构
我没有直接问功能怎么改，而是先让 TraeCode 对整个工作区做探索式分析，重点交叉核对 README、pom.xml、application.yml 和源码。它很快给出结论：README 过时，以构建配置为准，并顺手列出了几处“配置自相矛盾”的点（比如配置文档里写着敏感信息应加密，配置文件里却是明文）。这一步直接决定了后面所有文档的口径：以代码为准，不信旧文档。
第二步：生成架构图和数据流图
我让它基于源码里的实际调用链（客户端登录订阅 → 监听器解析分流 → 存储服务异步落库 → 线程池 → JPA 入库）生成一张可交互的架构图，包含组件、连线和关键参数（线程池核心数、队列容量、两张目标表）。生成后我逐项和源码比对，确认图上每个组件和参数都能在代码里找到出处，才定稿。
第三步：补协议解析说明和 ER 图
针对最难的协议分流逻辑，我让 AI 从解析类的代码反推每个字段值的业务含义（哪个值代表成交、哪个代表撤单、明细怎么序列化成 JSON 存进大字段），整理成数据流图和字段级说明。数据库侧则基于建表 SQL 生成了 ER 图和历史归档表的分区说明。这部分它还发现了几个我之前没注意的设计细节，比如历史数据是靠数据库定时任务每天夜里搬迁归档，应用侧完全不参与。
第四步：生成测试用例和测试报告
最后用 AI 从配置和代码推导出测试用例清单（含数据库连通性、存储正确性、甚至一个历史遗留的日志框架冲突场景），再用脚本批量生成了测试报告文档。
3. 成果展示
最终交付了一套完整的交接材料：
- 一张与源码逐项核对过的系统架构图（HTML，可交互）
- 数据流图、数据库 ER 图、全量配置参数说明
- 协议字段级的解析逻辑说明（报价/成交分流、撤单语义）
- 测试用例清单 + 测试报告
这套材料已经作为团队内部交接文档使用，后续接手的人不需要再“考古”。另外过程中确认的几个风险点（存储失败无重试、线程池回压策略、日志框架冲突）也整理进了运维注意事项。
4. 效率对比
- 以前怎么做：接手这种“文档失真”的存量系统，靠人肉翻代码 + 追着问离任同事，摸清架构至少两三天，画图写文档再另算；而且旧文档的坑往往要在联调时才爆出来。
- 现在怎么做：AI 一次性完成交叉核对并指出文档失真点，半天内完成架构梳理 + 全套文档初稿，我只做核对和定稿。最大的收益不是快，是避免了基于错误文档做决策——这个坑以前只有踩了才知道。
5. 经验和技巧总结
- 存量项目第一步永远是“核对”而不是“开发”。先让 AI 交叉验证 README / 配置 / 代码三方一致性，把“事实基准”定下来，后续所有产出才可靠。
- AI 生成的图和文档必须逐项对源码回验。我要求每张图的组件、每个参数都要能指出代码出处，AI 偶尔会把“计划中的设计”当成“已实现的现状”，比对能拦住这类幻觉。
- 涉及金融系统的材料，发出去之前单独跑一次脱敏检查。配置里的连接串、账号、证书密码这类信息，让 AI 专门过一遍再交付。