背景
一个核心项目一直在这开源项目基础上做二次开发。因为自研化的规划，于是新的需求出来了，提高项目自研率，通过自研率检测。
要求
- 自研率超过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，兄弟们快来御剑吧
