最开始可用的 AI 主要是对话式工具。当时一些代码补全类和对话式 AI 工具已经能够协助处理一些局部工作比如转换一些代码片段或者处理行数较少的文件。即便能力还比较有限也已经和早期“刀耕火种”的方式有了明显区别。一个很直接的感受就是用起来确实爽而且效率和正确率都有了明显提升。这个阶段的重点主要还是调提示词尽量提高转换的准确率。但对我来说更重要的收获其实是建立了信心AI 的确有能力把“转代码”这件事做好。这也为后面的多轮优化打下了基础。从 Prompt 到 SkillAI 开始具备承接完整任务的能力真正的转折点出现在具备代码仓库读取、命令执行和任务承接能力的 AI 开发工具开始可用之后。一方面不再需要手动把代码片段贴给 AI这类工具可以在 CLI 环境中自动读取代码、执行 Git 命令并识别需要转换的范围。另一方面基于 CLI 的这些能力也为自动化带来了可能。最初的版本就是把之前总结好的提示词封装成一个 Slash Command用起来就更顺手了只需要打开 CLI 并执行/code-converter commit 信息到这里AI 的角色已经不再只是“帮忙转换代码片段”而是开始具备了承接整段转换流程的能力。但我自己用着顺手还不够关键是要让团队也能顺手用起来。代码转换是每位开发者都会遇到的事情在验证出一定效果之后我开始尝试推广。问题也随之出现由于 Slash Command 没有纳入代码仓库管理如何让大家始终使用同一份提示词成了一个实际的落地障碍。工具形态探索如何普及代码转换工具在这个阶段主要探索的是怎么让所有人都能顺畅地把这套流程用起来。最早的一版自动化方案是这样的这版方案主要依赖 Git 的pre-pushhook通过执行一些脚本来启动 CLI完成自动化流程。但这个方案在推广时并不理想。首先它需要额外配置 hook而且 hook 一旦设置所有push都会触发。在某些场景下比如只是做原型设计时其实并不希望执行代码转换开发者如果想跳过还需要额外指定 Git 参数使用成本较高。其次我们项目共有 6 个仓库逐个配置也很麻烦。再者skill 文件需要放在代码仓库中如果有更新还得再同步到用户目录并执行额外操作维护起来也不方便。简而言之这个流程不够顺手因此最终并没有真正推广开。为了解决这些问题让工具真正可用第二版引入了一个可手动操作的 UI流程如下这一版大幅降低了使用门槛双击 bat 即可启动skill 直接放在工具仓库里由工具统一管理使用者只需要关注 UI 上要填写的参数即可。真正的瓶颈大任务为什么开始不稳定到了这个阶段工具在功能上已经基本可用团队里的其他同事也开始把它真正用到代码转换场景中。随着使用次数增加真正的问题才开始集中暴露出来。小任务的效果通常不错但一旦进入大批量代码转换稳定性就会明显下降。结合实际使用情况回看核心瓶颈主要有三个。第一个问题是上下文增长过快。举个很典型的例子某些存量代码里C# 的属性定义可能是这样的public CalcType CalcType { get; set; }Java 侧可能是这样的public CalcType CalcType CalcType.Single;从抽象规则上看在 Java 侧更合理的对应形式通常应该是 getter/setter命名也应该转成小驼峰。但现实问题在于存量代码本身未必完全规范。某些已有 Java 实现可能已经偏离了“标准映射”比如直接保留为公开字段甚至还带有特殊命名方式。这就引出了第一个难点为了确保转换准确AI 往往需要多次到目标仓库里查代码。这个要求本身很合理但它会迅速推高上下文成本。一旦开始大量读取代码仓库AI 的上下文就会快速膨胀。根据我的实际观察任务规模一旦上到 1000 行左右就很容易出现上下文耗尽即使没有彻底耗尽稳定性也往往会明显下降。第二个问题是大 diff 会让整个转换过程变得不流畅甚至失控。理想情况下AI 会尝试自己拆分任务、逐步完成。但由于前面提到的“必须结合存量代码”这一点即使任务被拆开执行成本仍然很高。更糟的是AI 有时会偏离当前目标不再专注于完成转换而是“另起炉灶”试图再生成一个工具来解决问题。到了这个阶段最大的风险已经不只是单次转换失败而是整个流程开始失去稳定性和可预期性。第三个问题是AI 也会犯错。从测试结果看能够顺利完成的代码转换任务正确率已经很高基本能达到 95% 以上但仍然无法完全避免零散错误。增强工具为了解决这些问题我重新设计了一版流程新流程主要有以下几个亮点MCP Server原来那种“直接读取源码来判断如何转换”的方式是一个很大的瓶颈。为了减少“读代码”带来的不确定性我设计了一个 MCP Server它会从 Jenkins 获取产品最新的非混淆包再通过反射和遍历的方式构建出一份完整的类型信息集合。这份集合包含目标产物中的所有类型以及每个类型下的方法、字段、属性等结构化信息。这样一来AI 就不再需要直接查找源码而是通过 MCP 查询目标平台实际暴露的 API 信息。当然中间也有一些失败的尝试。之前我试过用knowledge.md记录差异但效果并不好。第一项目太大某次转换过程中记录下来的差异下次未必真的能复用第二每次转换前还要额外读取这份
