Trae使用：重构一个项目

背景

一个核心项目一直在这开源项目基础上做二次开发。因为自研化的规划，于是新的需求出来了，提高项目自研率，通过自研率检测。

要求

• 自研率超过90%
• 实际应用到代码上，保证业务代码每一行不一样，但是不要影响业务逻辑

要求很简单，实际分析下来，工作量尤为庞大。分为三个服务项目，两个项目代码量分别在1w+，另一个核心项目在10w+。

面临问题

尝试人为改动一个核心业务文件1k+代码量，遇到问题如下：

• 类名、函数名、常量、函数内部参数名，然后重命名也不是随便重命名，也要保证可维护性。例如：原始函数名_getUserInfo，重命名完应该是_receiveUserInfo,保证可读性和可维护性。
• 另一个就是注释问题，原始项目中存在少量英文注释，需要翻译及大量补充缺省的注释
• 优化代码写法，将原始比较复杂的函数或者写法，拆分成小函数或者优化写法。

这样操作下来才能满足要求，但是人力成本很高，一个函数名的重命名都需要查询翻译。

AI模型选择

找到重构的标准后，AI开始介入。先用代码量小的两个项目开始全自动跑重构。跑之前先用一个目录对Trae支持的各个超级模型做了测试，最终选定Claude-4-Sonnet模型。

• Claude-3.7-Sonnet
• Claude-4-Sonnet （√）
• Gemini-2.5-Pro
• Kimi-K2-0905
• GPT-5-medium
• Grok-4

每个模型可能都有自己的擅长领域，Claude-4-Sonnet可能和我的诉求更搭配。

AI修改面临的问题

以整个项目或者一个目录纳入执行目标去修改

• 部分文件的重构深度不足，达不到标准
• 函数完整调用链的梳理有时不够全面，难以覆盖完整
• 上下文读取、修改很快会达到上限，需要人为审查再次启动任务
• 一个目录下的执行顺序无法保障按顺序执行，需要人为干预调整
• 如果约束不够，很容易触发AI的优化增强机制，越界修改逻辑
• 线上环境和本地环境的差异，导致AI读取上下文过程中的差异，引发不必要的修复行为

提示词示例

下面提示词是经过多轮踩坑，花费大量时间，实践而来。主要为了保证自研化的要求外，严格约束AI行为。

大项目重构困局

最后修改10w+的项目时，按照之前重构完成的项目(1w+)经验，发现不能很好的执行完成。执行到30% ~ 40%后，AI的长下文已经到达极限。遗漏率和修改不完整问题开始大幅增加，即使人为半干预状态去驱动修改也无法提升修改质量。

这时候需要人为精细化控制AI去逐个文件修改重构，效率会降低很多。当然也可以充钱使用Max Mode，适合执行复制且长上下文的任务，不过是按照Token使用量计费的。

总结

整个重构下来发现，AI编程并不是一个一劳永逸，在外人眼里看来没有技术含量或者很容易的工作。整个重构过程中花费大量时间去测试。

• 测试模型，进行选型
• 选定模型测试一个文件的执行效果
• 测试一个文件以及关联业务文件的执行效果
• 测试一个目录的执行效果
• 总结遇到的问题，提炼更精准适合的提示词
• 测试小项目的执行效果，分析人力哪个时间点参与比较合适
• AI执行到什么程度最好，过度AI执行反而有可能适得其反

后记

写的太少了，补充一个后记。最近半年来一直和AI打交道，AI编程、AIGC，兄弟们快来御剑吧