夜雨聆风在国内大模型差距不大的前提下可能更依赖于提示词和一定的工程规范，另外本次探索纯纯是以口述的方式让几个不同智能体进行了转换本人是没有改动任何代码的也没有打开Android Studio或Visual Studio（腾讯的WorkBuddy、DeepSeek的Reasonix还有OpenCode），其中WorkBuddy开的自动大模型。后面两个都是接的DeepSeekV4的api，测下来WorkBuddy 相对比较好，其次OpenCode，三个里面表现最差的是Reasonix（毕竟是新出的，无论是迭代次数还是研发投入都没法比）。
一、打头阵的WorkBuddy
最近每天签到送150积分不知不觉积累了几千积分，一个月有效期那必须抓紧使用。
1、初始化
先创建一个大文件夹qingqiu_batai，然后把安卓项目放里面，再新建一个空的C#项目文件夹，最后在WorkBuddy里面打开qingqiu_batai后就可以开始干活了。召唤了一个专家 高级工程师（吴八哥）全程聊天执行开发指令，也可能也是影响最终效果的重要因素！
工作目录下qingqiuapp是一个安卓项目，后面计划将其功能使用C#实现（C#项目存放在qingqiuCsharp文件夹下），先了解安卓项目并形成相关方案文档，综合考虑架构、布局、硬件外设、api接口及业务逻辑操作等方面，如何按步骤实施以便迁移成C#，有哪些难点或需要特殊处理的地方？迁移后的项目是在windows上运行的，而且也需要兼容双屏windows或单屏windows。
2、开始干活
前面生成文档后就可以直接让它开始工作了，也是让这个专家继续干活，全程聊天交流你不需要关注任何代码细节。
请帮我进行项目迁移 在qingqiuCsharp文件夹下生成C#项目代码，去除里面用到IC卡读写器相关的内容，迁移后的项目不需要IC卡读写器
整个过程十来分钟，开发完成后自己调用donet相关指令进行exe程序编译无需打开Visual Studio。后面需要做的就是打开exe程序进行测试，重头戏就是你要不断地测试，不断地让他去修改，必要是你要告诉它当前业务大概的操作流程和逻辑是什么，以及提醒下它参考安卓项目代码进行深度理解后来进行修复！总之，硬性条件是你一定要了解透原本安卓项目的所有功能！不要指望AI能完全1:1完成。
这个就是不断循环：提需求→发指令修改→验证→再发指令修改…… 下面贴一些沟通图大家感受下就行（忽略后面的 ardot-design-assistant 这个是我开工前搞错了点了 WorkBuddy的创意设计）
3、必做工作
后面需要复刻补正的逻辑太多，而且有些问题反复修改还是修不好，然后就想到让它把api请求日志还有程序日志都记录下来，还有就是程序捕获到的异常让它弹窗提示出来同时也写日志，这样后面遇到问题可以让自己去看日志，这极大提高了开发、修改效率。
因为接口返回字段类型换个序列化问题好像已经出现多起，浪费了大量时间反复排查！ 我建议形成经验另外 本项目所有捕获到的异常我希望能以错误弹窗的形式提示出来！不要静默。项目下的所有md文档请你看下是否需要更新，把你的记忆、经验 等也可以根据需要更新到项目下合适的md文档中很多业务接口返回错误code需要展示出错误信息，现在code不是200的情况好像没有任何反应，实际接口错误msg需要提示，{"code":-110,"msg":"不允许重复提交，请稍后再试","total":0}，请帮我定位及处理所有接口，另外还有个特殊的错误code=401时需要清除登录信息跳转登录页面，这个表示鉴权失效是需要全局触发的，任何接口出现这个都要跳转登录{"code":401,"msg":"请求访问：/api/error，认证失败，无法访问系统资源","total":0}增加程序日志功能：1、所有api请求 及接口响应都增加专门的txt日志记录，每天一个日志记录文件，记录请求url、请求方式、请求body，响应code、响应body等信息。 2、所有捕获到的异常需要写入专门的log日志，这个日志方法可以进行统一封装，后面可能会在其他业务环节增加日志打印也是写入这log日志。 不同类型的日志希望可以在appsettings.json进行配置，可以控制开关日志功能 以及 控制写入日志的等级（比如只写入错误日志或全部日志都写入），日志功能是为了便于排查及复盘程序问题 后面甚至可以打印机程序业务步骤及参数信息以便排查问题上面工作做完遇到问题可以直接让AI看日志文件，一般我是测单个功能前先把日志内容清空，这样AI直接读取也行，token消耗不会太大也不影响注意力。
遇到的相对比较大的坑就是接口返回字段类型的问题，就是比如后端返回整型，安卓按字符串接收，转Ｃ＃后也是按字符串接收，但是安卓的json序列化没那么严格可以自己把int转为string，但C#这里不行必须一致才行所以导致接口处理遇到很多问题（当然根源还是 安卓项目做的时候没有严格对齐api接口），这也是为什么必要要把api请求详情记录日志的原因之一。
4、改造C#后的效果
最后就是WorkBuddy改造效果了，这次没有全部改造，框架完成后就复刻验证了部分功能，只要测试足够无非就是时间花费问题，整个改造消耗了2000+积分。
菜单框架、业务弹窗嵌套、支付下单逻辑全部复刻成功（菜单全部是根据后台接口返回的数据动态加载渲染的）。
查询及一级操作功能更没有问题（支持滚动动态加载数据）,因为改了UI框架，很多页面控件被遮挡显示不全了，为了保住仅剩的300积分，我还是忍住了没继续修改。
5、关于硬件
硬件这块本次并没有测试，windows下调用打印机、usb、串口理论上都有很成熟的方案无需担心。 扫码支付是改成带输入框的弹窗了可以手动输入或扫码枪模拟键盘直接输入也没什么问题。
二、第二登场的Reasonix
因为是DeepSeek开源出品的就想着也测试下看看，效果一般吧整个测试花费7.22元（1.97亿Token，缓存命中率确实高）比我预想的开销低。开发过程跟WorkBuddy差不多只是没有"专家"也没有装技能，直接看效果吧。
这个是开发测试最累的，到最后放弃了实现支付业务，因为有个场次预约功能怎么都弄不上去，而且对安卓业务的逻辑理解十分堪忧，需要你讲解的更细提示词更有逻辑。除非是新开发项目，老项目改造、bug修复暂时不建议使用这个新出的Reasonix
三、最后登场的OpenCode Desktop
OpenCode对接的是DeepSeekV4 消费8元，后面感觉效果不太行就使用了OpenCode提供的MimMo V2.5 Free后改的还算顺利，最终把免费额度给用完了。这个也没有专家或安装技能，是直接让它开干的。有时候会直接输出英文结果，需要你复制到在线翻译工具里面翻译下再回复操作。
沟通过程、记录日志等操作都基本一样，过程就忽略直接看下效果。
OpenCode的UI有点"不堪入目"可能是没有让它使用UI组件的问题，基本都是原生绘制的。这次主要目的还是复刻业务功能，一开始大模型接的是DeepSeek V4 测试的很艰难，后面换了小米的MiMo模型后开始好转功能基本几轮对话就能复刻实现，甚至活动功能也给复刻了（WorkBuddy上面我没有专门提这个功能点它也就没做）。
由于之前对接DeepSeek 且都是用的原生功能绘制的UI 基本所有页面看着都很简陋（当然我也没有明确告诉它使用UI组件库），在实现核心销售功能后免费额度没有了就没再继续，好歹证明它是能完成任务的。
以上就是全部，如果有积分建议还是用WorkBuddy来完成功能（本次测试因为额度等问题没有选Qoder、Trae参与，一般我都是习惯这3个轮着用，各有特色吧，国内出品的东西中文肯定是优化过的）。
相关阅读：
