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 做功能测试，同时编写测试脚本：

ini 复制代码

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、铁律等进行测试：

objectivec 复制代码

虚拟机已配置好，
结合 Android测试脚本功能v16  wms全流程测试脚本-文档说明v16 SKILL 铁律等
进行测试，前面测试实操的图片是不正确的。

1.4 接口问题，没按文档开发

测试过程中看源码，发现接口设计有问题：接口增加了 app 前缀，这是不对的。微服务前后端最好共用一套接口，api 是前端 vue 端用的，而 Android 端应该直接针对网关 api.wms.wayhua.vip：

kotlin 复制代码

我看源码后发现 接口增加了 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的操作。也就是现在进行操作的。

objectivec 复制代码

查看测试实操后，发现完全没有按原型设计啊。
先做竖屏的。
源码在 当前目录下：jet-wms\jet-wms-android
   原型在：jet-wms\ui-prototype\android
现在对比开发文档（因为前期我改过不少，原型都可能会少），如果要改原型，先修改原型再改代码。
要保证android源码与原型一致，功能在开发文档。还要严格按SKILL来操作

复制代码

接着操作

二、v16 完整测试

2.1 第一轮完整回归测试

环境与接口都理顺之后，进入第一轮完整回归测试。这次只测 Android，全部通过界面操作：

objectivec 复制代码

这次是完整的回归测试，项目我已部署，你是专业测试以及文档编写者，只能通过界面操作。
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 次测试直接通过界面配置，不用再编译源码：

objectivec 复制代码

这次是完整的回归测试，项目我已部署，你是专业测试以及文档编写者，只能通过界面操作。
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 后，再来一轮完整测试，这次要求边测试边记录：

objectivec 复制代码

这次是完整的回归测试，项目我已部署，你是专业测试以及文档编写者，只能通过界面操作。
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，后端没动，提交推送后后端也不用重新发布：

perl 复制代码

git 已好了，提交push吧，不是说后端没改吗？

复制代码

不是没改后端吗？那后端就不用发布了吧

五、v17 再次回归

5.1 v17回归

问题修完，打包做回归。这次要求先打包一次，然后直接测试打包的文件，测试完成形成问题集，不可边测边修改：

objectivec 复制代码

这次是完整的回归测试，项目我已部署，你是专业测试以及文档编写者，只能通过界面操作。
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 下载上，内网环境直接走私有仓库分发：

perl 复制代码

https://admin:Ivy%402024@oss.wayhua.vip/repository/gradle-distributions-group/gradle-8.11.1-all.zip

5.3 按apk进行测试

gradle 问题解决后，重新按前面打包的 apk 进行测试，还是同一套回归流程：

objectivec 复制代码

重新按前面打包的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 模式我会继续用下去，后续文章会继续记录它在其他模块上的实践效果。