22年chatgpt3.5 刚出来的时候，体验了一下，实现了一个PR审阅的工具，接入到代码仓库中，当时团队同学反响非常不错，但是继续往下研究的时候，发现模型的能力不太够，当时的结论是除了目标明确，耦合较少的任务(如：单元测试&类型文件转换)外，很难在研发流程上有较大的提升。

后续因为业务调整主要尝试将LLM在私域业务上的一些场景进行落地。年初组织调整到新成立的出海业务后，又有时间重新审视这个命题，尤其目前模型很多能力上都媲美研究生博士同时Agent框架与日俱进的情况，感觉研发助手这个命题应该是有一些出路的。

经过一段时间访谈在团队内找到几个场景，可以先搞以下三个，逐步验证模型

1. 出海团队的同学都是从各个团队抽调的，对原来的代码都不熟悉，看代码耗时很长
2. 国际化迁移过程中遗留了很多技术债，比如语言，货币，时间硬编码类，治理的量级非常大，耗时会很长
3. 大仓PDA设备上所有的功能目前都是Native的，这块之前一直想重构成动态化，但是因为人效的原因一直都没成行，但是这块从整体效率&质量的角度还是有必要做迁移的

场景1

可行性还比较高，社区有 https://deepwiki.org/ 这个产品已经做出来了，花了两天时间，大致把我们Native项目跑起来了，可以看下图，基本流程，关键代码等准确率很高

场景2

这个比场景一还简单一些，因为规则都相对确定，同时上下文耦合很小。所以只需要实现工程能力遍历代码仓库就可以。

执行的时候遇到唯一的麻烦是不知道规则覆盖是否全面，所以提前让AI汇总出来分成几十类的问题，同时针对不确认归属的单独标注了出来，让RD来制定方案就行。

场景3

这里遇到一些问题，采用planning-execute架构，1500行左右的Activity项目可以较为丝滑的迁移，各种功能都没问题，不过UI样式上面需要进一步调整一下

继续尝试4000左右行的项目就遇到一些问题

1. 功能存在丢失
2. 样式存在有组件上有className，没有对应的style
3. 一次通过率很低，人工介入成本高
4. 组件库使用MCP的召回不准确

1&2功能和样式的问题可以在规划时对每个任务的规模做限制进行处理来解决

3需要规划时任务的拆分合理，并且有足够好的反馈机制

4属于复杂问题中Disorder类的问题，还需要进一步做分析判断才行

Written by xi ming You should follow him on Github