技能进阶与Claude Design初体验
先汇报一下进度
感觉越来越像4399小游戏了……
本周新增功能：
✅ 背包系统：包括原始中药、中药饮片、方剂、书籍。其中原始中药部分已提供AI生图素材。
✅ 辨证游戏壳子：舌诊 → 脉诊 → 问诊 → 辨证 → 选方
（哈哈没看错, 我又又又重构了，把分散的小游戏整合成了一整个辨证游戏）
✅ 煎药游戏壳子：选方结束触发配伍煎药游戏，学习方剂配伍。
✅ Hermes Agent backend：AI对话层跑通，但未接入游戏。
第一部分：聊聊开发流程
【refactor】开发不是线性的，而是螺旋上升的
当你反复多次修复相似的问题时，或许说明你该定义标准或者重新抽象了。
举个例子：做游戏会有很多弹窗——游戏引导要弹窗，每个小游戏有弹窗。
当我反复看到不同弹窗出现相同的问题时：
- 弹窗大小不一，花里胡哨，毫无统一配色和风格
- 文字溢出现象在多个弹窗反复出现
- 多个弹窗只能打开没有退出按钮，或退出按钮无法点击
这个时候就该重构、抽象了。
我的做法还是superpowers的技能串联
- Explore：先让AI分析当前现状，找出问题
- brainstorming：给出重构和抽象设计
- writing-plans：提供测试验收方案
- subagent：进行重构开发
但是！反过来，并不推荐AI一上来写代码就进行高度抽象。
相反，上来的代码应该以简洁为主。
这里推荐 andrej-karpathy-skills:simplicity-first 原则：
先让代码跑起来，再让代码优雅起来。
【PROGRESS.md】长线任务，进度跟踪是核心
最初看到有人单独使用 TODO.md、PROGRESS.md，我当时觉得纯属多此一举：
"又又又用产品经理管开发的方式来管AI了。直接把进度写到 CLAUDE.md 中，每次重启对话直接重新加载不行吗？？"
再一次证明，纸上谈兵终是浅。
这里面最核心的一个问题，其实是我之前在"渐进式加载"这个技术本身一直没想明白的点：
如果这个信息模型需要完全阅读，那还需要渐进式加载吗？
我原本以为是不需要的。
但这里遗漏了一个问题：
模型在使用 read 工具读取文件时，默认一般会读取100行（不同Agent架构和工具会存在差异），核心是工具设计为了避免无用信息充斥模型上文，这样可以视获取信息决定是否继续读取。
这就导致：当你提供给模型的文件过于庞大、又杂糅了太多信息时，模型会出现因为部分读取文件而带来信息遗漏。
体现在：我把项目架构、已完成状态、进行中状态全部写入 CLAUDE.md 中。
结果发现模型在update项目状态时：
- 只更新了已完成
- 但没有及时更新进行中状态
- 导致反反复复围着一个任务来来回回地搞
还有一次，在 CLAUDE.md 中写了好多遍进度跟踪，结果：
- 有的位置显示该任务已完成
- 有的显示进行中
- 最后连AI自己也搞不明白究竟做完了没有
所以我做了调整：
PROGRESS.md：当前正在做的任务细分进度TODO.md：记录已完成信息- 大幅缩减 CLAUDE.md 的篇幅，只保留最新项目架构、进度摘要
初步试验，这个组合效果最好。
等我再确认下这两个文件的颗粒度，感觉就可以搞到 precompact 的hook里面自动更新了——感觉比 compact 要好用，不做总结和摘要，只是单纯描述当前状态 + 下一步该做啥，类似条件马尔可夫的特性。
【一切皆版本控制】AI作为顶尖牛马工作更要留痕
事实证明不论是人在工作中，还是AI在工作中留痕都是最重要的
不论是 Git worktree，还是 branch 管理，其实都是为了：
- 一切行动皆被记录
- 一切状态都可回滚
这一点对于AI来说尤其重要。尤其对于一些测试性功能：
- A、B、C三个方案，不知道哪个好？
- 让AI都开发一遍，直接用效果作为唯一对比标准
但是！需要注意版本控制，绝对不要让测试性功能直接在主分支上哐哐造。
因为上下文有限，所以你不要天真地以为可以根据上下文进行回滚——不可能的。
只有Git提交记录是唯一真相源。
所以不论是：测试性代码、设计文档、多版本对比、各种临时feature
请一切皆留痕，一切皆用分支或 git worktree 进行管理。
确认无误再合入主分支，如果效果不及预期直接废弃。
这其实不是AI编程规范，人类编程规范也是如此。
第二部分：技能进阶——创建、测试与引用
【skill-creator】请把开发中每一次重复都变成技能
请务必在开发中无数次想到该使用/skill-creator了
上一章末尾就提到，需要批量制作素材。
比如背包中，我需要批量生产中药素材，所以就顺带手做了个中药素材生成技能。
于是我用 /skill-creator 这个meta技能来制作技能，支持：
- “先通过豆包同时生成4个或9个不同的中药组图“