写在开始：这篇文章算是一篇skill养成记，通过使用opencode+GLM，实践了一次重构skill的构建过程，这个skill只负责move method这一种重构手法。
文中把跟AI相处的哭笑不得的过程记录了一下。把最终养成的skill和使用这个skill重构的代码PR放在了文章最后。

1. 会产生语法错误，可能是由于模型能力导致的。等我提示它的时候，它自己也能发现这个问题，但是就是一次性做不对。
   

2. 重构过程中，错误地给函数给多加了一个参数，还头头是道地给出了分析和理由。
   

3. 给带了两个分号，提示AI后，它改正了。
   

4. 缺少冒号，缺少头文件包含，不知道这些错误是如何产生的，我这么信任它，语法应该是AI最擅长的，真的搞不懂它为什么会犯这么低级的错误。（提示它后做了改正）
   

5. 头文件包含每次都做的不太好，特别是跨模块的头文件包含，总是找好久找不对。如果给它更多的软件开发视图的输入，可能一次性做对的概率能高一些。
   

6. 重构后，变量定义删除了，但是使用处没有删除完，导致编译阶段才发现问题。这个问题本应该在代码重构阶段发现的。
   

   告诉他删除无调用点的函数，它就只处理函数，变量和宏定义不管，可以看到skill中是有明确交代的，但还是改不全。
   

7. 测试代码有时候容易遗漏修改。往往要到编译阶段才能发现问题。
   

8. 重构没改全，导致函数的声明和实现不一致，编译时才发现错误。让它再次检查也能发现错误，但是就是第一没有做对。
   

9. 有时候会一本正经的胡说八道，88个字符，为什么超过120字符？
   

10. 明确告诉你public方法命名不要带internal，你还是带了internal。
    

11. 重构后莫名奇妙多出来几行代码，让它重新检查后才删除。让我对它很不放心。（可能是一次让它干的太多了，它有点晕菜了）
    

12. 模型进入了死循环，不知道什么原因。关闭重启后才恢复。
    
    

13. 连AI都把测试代码当成了二等公民，看来真是从人那里学到的。
    

14. 上述问题的，产生后，让AI自己纠正，同时让它分析错误产生的原因，把经验固化到skill中，确保下次不重犯。而后来确实犯错少了一些。(但是它把skill中改了什么，没有细究，各种grep之类的命令，也看不懂，它能看懂就好。所以skill要让它自己改)
    

    GLM5感觉经验总结的更好一些：
    
    
    

15. skill每次修改我一般重新打开窗口，重新加载skill。历史的信息存在，总感觉他会参考，乱想，并且超级慢。
    反过来，如果当前只做一半的任务，如果此时关掉cmd窗口再打开，就会导致后续的执行不准确，可能是因为之前的上下文没有了。
    这个要视情况而定。
    

16. 把类改造成单例后，忘记实现构造，析构函数，很隐晦，根据编译报错信息不好排查，AI排查出来了，点赞！
    

17. 询问一些重构是否合理，能给出一些比较中肯的建议！
    

18. AI能节省一些烦人的细节搜索（如下给函数入参增加一个state参数，很多地方要改）。给它一句话，它就能把涉及到的点都改掉。
    

总结： 总体看来，人的技能还是需要的，比如人要知道move method重构方法的步骤和精髓。每次按照你的要求，让AI做一步，他的正确率还是比较高的，效率也提升了不少。至少当前阶段，我觉得这是一种比较合理的跟AI相处方法，还不能指望一句话描述，就让AI把你脑子里面想的一整套方案搞定。因为重构本身就是一个小步迭代的过程，也是一个想法逐步浮现的过程。
另外，为了防止AI丢三落四，可以再搞一个verify skill来监督验证它。别让它自己检查自己，可能会产生自欺欺人的行为。

skill归档地址：
skills:基于AI编程助手的专业技能集合项目 - AtomGit | GitCode
使用skill最终生成的代码链接，其中人工手动参与的代码5%左右（故意使用了多次提交i，展示一下每次让AI干一件简单的事情，简单到几乎不可能出错）：
AudioVolumeManager 重构-multimedia_audio_framework-AtomGit | GitCode