20. 对SKILL进行一次全新尝试，改为框架+细节方式的实践及验证：Android 代码调试实录
前言
用 AI 工具做全栈项目，最怕两件事：一是 AI 生成的代码后期自己都看不懂，二是没有一个稳定的流程约束，每次开发都像开盲盒。为了治这个病，我把自己的 SKILL 做了一次大改造：从原来「generate / daily 两份 SKILL」的模型，改成「框架 + 细节」的单技能模型——SKILL.md 只做大纲，细则全部下沉到细节文件，平时只加载框架，用到哪块细则再查哪块。
理论归理论，这套改造到底好不好用，得拿真实项目来验证。这次我拿 jet-wms 项目的 Android 端开刀，完整走了一遍：从保证 Android 能跑起来，到 v16/v17 两轮完整测试，再到问题集回归和源码审视。整个过程都严格按新 SKILL 的流程走，本文就是这次实践与验证的完整实录，包括踩过的坑和最终的思考。
一、保证 Android 可以运行
1.1 修改bug，保证Android能运行
Android 端第一次接入整体流程，第一步先把环境跑通。之前 gradle 已经调整过，现在要保证 Android 代码能正常运行，任务如下：
jet-wms-android
1、gradle 已调整
2、保证Android代码可以运行。
1.2 按项目文档进行测试
环境跑通之后，接着处理项目名、接口地址这些基础配置，并按原型、SKILL 和开发文档对 Android 做功能测试，同时编写测试脚本：
1、android目录，nesc是我以前的项目名称，应该改为当前项目wms
2、app.api.host=http://api.wms.wayhua.vip
hosts
192.168.55.140 api.wms.wayhua.vip
3、参照原型，SKILL和开发文档，对Android进行功能测试，并同样编写测试脚本 Android测试脚本功能 名称叫从v15版本吧，同时修改wms全流程测试脚本-文档说明，增加android功能。修改完成后，还要进行测试和按文档说明进行文档编写。
1.3 配置好虚拟机，进一步测试
虚拟机配置好之后，结合 Android 测试脚本功能 v16、wms 全流程测试脚本-文档说明 v16、SKILL、铁律等进行测试：
虚拟机已配置好，
结合 Android测试脚本功能v16 wms全流程测试脚本-文档说明v16 SKILL 铁律等
进行测试，前面测试实操的图片是不正确的。
1.4 接口问题，没按文档开发
测试过程中看源码，发现接口设计有问题：接口增加了 app 前缀，这是不对的。微服务前后端最好共用一套接口，api 是前端 vue 端用的，而 Android 端应该直接针对网关 api.wms.wayhua.vip：
我看源码后发现 接口增加了 app，这是不对的，
微服务，前后端最好共用一套接口，而 增加 api这是指前端 vue端
而android端，是针对 网关的 api.wms.wayhua.vip->192.168.55.140
@POST("app/operation/submit") 这种接口直接到网关， wms sys都是要添加的。
针对接口文档，先将android功能丰满
1.5 按UI原型重新调试代码
这就问题太多了，android完全没有按UI原型来开发。前面可能是有的步骤我取消了，我当时说过我要专门进行android的操作。也就是现在进行操作的。
查看测试实操后，发现完全没有按原型设计啊。
先做竖屏的。
源码在 当前目录下：jet-wms\jet-wms-android
原型在：jet-wms\ui-prototype\android
现在对比开发文档（因为前期我改过不少，原型都可能会少），如果要改原型，先修改原型再改代码。
要保证android源码与原型一致，功能在开发文档。还要严格按SKILL来操作
接着操作
二、v16 完整测试
2.1 第一轮完整回归测试
环境与接口都理顺之后，进入第一轮完整回归测试。这次只测 Android，全部通过界面操作：
这次是完整的回归测试，项目我已部署，你是专业测试以及文档编写者，只能通过界面操作。
CLAUDE.md和铁律都要严格执行(不要以以前memory中的记录为准)
结合 Android测试脚本功能v16 wms全流程测试脚本-文档说明v16 SKILL 铁律等
进行测试，今天第2次，总第3次
就测试android不用管其他， api对应如下
API: http://api.wms.wayhua.vip/
hosts: api.wms.wayhua.vip->192.168.55.140
mysql，redis都是在192.168.55.140上
通过界面操作，不可直接使用接口 android进行测试。
不行就直接配置 192.168.55.140 修改一下源码，赶紧测试吧
oss.wayhua.vip 我重启了，马上就好，接着赶紧测试
android 有一个大功能没做，就是登录界面切换服务器地址，还有就是不要经常打包编译，oss.wayhua.vip 启动会占内存。
2.2 缺少配置服务器地址功能
这里有个很容易踩的坑：Android 没有做「登录界面切换服务器地址」这个大功能，导致每次换环境都要重新编译打包，而 oss.wayhua.vip 一启动就占内存。其实 UI 原型里登录页面就有的：
ui原型中登录页面就有的，可以切换服务器地址的
代码修改了吗
先编译apk，准备下一轮测试
2.3 再次回归测试
登录界面切换服务器地址改好后，第 4 次测试直接通过界面配置，不用再编译源码：
这次是完整的回归测试，项目我已部署，你是专业测试以及文档编写者，只能通过界面操作。
CLAUDE.md和铁律都要严格执行(不要以以前memory中的记录为准)
当前目录\jet-wms\doc\10测试脚本
结合 Android测试脚本功能v16 wms全流程测试脚本-文档说明v16 SKILL 铁律等
进行测试，今天第1次，总第4次
就测试android不用管其他， api对应如下
API: http://api.wms.wayhua.vip/
hosts: api.wms.wayhua.vip->192.168.55.140
mysql，redis都是在192.168.55.140上
通过界面操作，不可直接使用接口 android进行测试。
如果遇到要配置服务器地下，直接在登录界面直接配置，不用编译源码
三、查看测试实操与问题集
3.1 查看测试实操
测试跑完，先查看测试实操记录，确认每一步操作和截图是否与测试脚本对照：
实操看完，接下来处理测试产生的问题集：
3.2 解决掉问题集中的问题
解决掉问题集中的问题
3.3 先本地验证
问题没改完还不能完整测试，先本地验证：
先测试代码，我要发布后才能完整测试。
修改代码，只能本地测试。
接着操作
测试脚本也要跟着升级，把 v16 的两个脚本统一升到与 Android 测试脚本功能 v17 一致的版本：
将 wms全流程测试脚本v16 和 wms全流程测试脚本-文档说明v16
升级到同 Android测试脚本功能v17 一样的v17版本
四、V17 再来完整测试
4.1 再来一轮完整测试
脚本统一到 v17 后，再来一轮完整测试，这次要求边测试边记录：
这次是完整的回归测试，项目我已部署，你是专业测试以及文档编写者，只能通过界面操作。
CLAUDE.md和铁律都要严格执行(不要以以前memory中的记录为准)
结合 Android测试脚本功能v17 wms全流程测试脚本-文档说明v17 SKILL 铁律等
进行测试，今天第2次，总第5次
就测试android不用管其他， api对应如下
API: http://api.wms.wayhua.vip/
hosts: api.wms.wayhua.vip->192.168.55.140
mysql，redis都是在192.168.55.140上
通过界面操作，不可直接使用接口 android进行测试。一定要边测试边记录
前面任务结束了吗？没有就继续
4.2 先解决问题集中问题
问题集的修改走「先本地按接口测试，没问题再发布」的流程，最后生成 apk 准备回归：
修改问题集中问题，先本地按接口测试，
没问题后我再发布，最后生成apk，准备后一轮回归。
这里有个容易混淆的点：改 Android 和改后端是两个环境。改 Android 用 192.168.55.140，改后台则通过接口，别搞混：
不是叫你修改源码吗，肯定没有运行8100，8110，8120 啊
如果是改android，则使用140，如果是后台则是通过接口，先改完。
4.3 只改android端，git提交
这轮只改了 Android，后端没动，提交推送后后端也不用重新发布：
git 已好了，提交push吧，不是说后端没改吗？
不是没改后端吗？那后端就不用发布了吧
五、v17 再次回归
5.1 v17回归
问题修完，打包做回归。这次要求先打包一次，然后直接测试打包的文件，测试完成形成问题集，不可边测边修改：
这次是完整的回归测试，项目我已部署，你是专业测试以及文档编写者，只能通过界面操作。
CLAUDE.md和铁律都要严格执行(不要以以前memory中的记录为准)
结合 Android测试脚本功能v17 wms全流程测试脚本-文档说明v17 SKILL 铁律等
进行测试，今天第1次，总第6次
就测试android不用管其他， api对应如下
API: http://api.wms.wayhua.vip/
hosts: api.wms.wayhua.vip->192.168.55.140
mysql，redis都是在192.168.55.140上
通过界面操作，不可直接使用接口 android进行测试。一定要边测试边记录
oss.wayhua.vip 是好的，你先打包一次，然后测试打包的文件。 直接测试，测试完成形成问题集。不可边测边修改。
5.2 解决问题集问题
大哥代码有问题，先解决吧。
打包时卡在 gradle 下载上，内网环境直接走私有仓库分发：
https://admin:Ivy%402024@oss.wayhua.vip/repository/gradle-distributions-group/gradle-8.11.1-all.zip
5.3 按apk进行测试
gradle 问题解决后，重新按前面打包的 apk 进行测试，还是同一套回归流程：
重新按前面打包的apk进行测试，按前面说的进行测试。
这次是完整的回归测试，项目我已部署，你是专业测试以及文档编写者，只能通过界面操作。
CLAUDE.md和铁律都要严格执行(不要以以前memory中的记录为准)
结合 Android测试脚本功能v17 wms全流程测试脚本-文档说明v17 SKILL 铁律等
进行测试，今天第1次，总第6次
就测试android不用管其他， api对应如下
API: http://api.wms.wayhua.vip/
hosts: api.wms.wayhua.vip->192.168.55.140
mysql，redis都是在192.168.55.140上
通过界面操作，不可直接使用接口 android进行测试。一定要边测试边记录
oss.wayhua.vip 是好的，你先打包一次，然后测试打包的文件。 直接测试，测试完成形成问题集。不可边测边修改。
为什么一直卡死了没有反应了
六、源码分析：AI 生成代码的架构反思
测试告一段落，回头审视 AI 生成的 Android 源码：
总的来说，代码编写还是相当规范的，注释也清晰，使用AI生成代码最好还是有自己的架构，不能完全随ai自己编写，不然后面自己就看不懂了。程序的职责是船长，把好舵。
七、小结
这次用 Android 代码调试完整验证了「框架 + 细节」的新 SKILL 模式，整体走下来收获不少：
- SKILL 框架 + 细节改造可行：SKILL.md 只做大纲、细则下沉细节文件，平时加载轻、需要时再查细则，整个调试流程没有被冗长细则拖慢，验证了「框架 + 细节」模式的合理性。
- 流程化测试是保质量的根基：从保证运行、v16/v17 完整测试、问题集回归到源码审视，每一轮都有测试脚本、实操记录、问题集三件套，问题能追踪、回归有依据，这比凭感觉改代码靠谱得多。
- 接口设计要前后端共用一套：Android 直接走网关
api.wms.wayhua.vip，而不是为移动端单独加app前缀接口，微服务场景下接口统一能省掉大量重复工作。 - AI 生成代码必须有自己的架构：AI 生成的代码规范和注释都不错，但完全放任 AI 自己写，后期自己都看不懂。程序的职责是船长，把好舵——架构和方向必须自己定，AI 只是执行者。
用真实项目验证新流程，比空谈理论有用得多。这套「框架 + 细节」的 SKILL 模式我会继续用下去，后续文章会继续记录它在其他模块上的实践效果。
