技能列表为什么要有刷新按钮？外部新增 skill 如何立即被 GoWork 发现

如果你刚把一个新 skill 放进目录，却发现 GoWork 里还是没有，先看结论：刷新按钮的价值，不是“让系统多做一件神奇的事”，而是让用户能立刻请求技能索引重建。 没有它，用户只能猜现在看到的是不是旧缓存；有了它，就能把“等一会儿再看看”的不确定，变成“我刚改过，请现在重扫”的明确动作。

这也是执行型 AI 助理和普通聊天工具在产品设计上的一个关键差别。聊天机器人可以只回答“可能是缓存问题”，但像 OmniGoAI 的 GoWork 这类真正负责执行任务的助手，必须把入口状态做成可验证、可重建、可恢复。技能列表看起来只是一个 UI 面板，实际上它决定了系统下一步能不能选对技能、读对路径、执行对流程。

如果你已经读过 新技能为什么装好了却还看不到？GoWork 的技能发现缓存、刷新与重扫、多步任务为什么不能只在当轮写计划 和 失败后别重来：让 AI 助理从上次进度继续，这篇文章继续回答更具体的一层：既然系统已经有缓存 TTL，为什么还需要一个手动刷新按钮？

刷新按钮解决的，不是“发现能力”，而是“发现时机”

很多人直觉上会觉得，只要技能发现器最终能扫到新目录，是否有刷新按钮都无所谓。但对真实用户来说，差别非常大。

• 没有刷新按钮：用户只能等待缓存自然失效；
• 有刷新按钮：用户可以在刚完成文件改动后立即请求重扫；
• 有全局重扫：当目录根路径、挂接方式或扫描范围变化时，还能做更彻底的修复。

也就是说，TTL 解决的是系统效率，刷新按钮解决的是用户控制感。 两者不是替代关系，而是分工关系。

为什么“等缓存过期”在体验上很差？

因为它要求用户在一个看不见内部状态的系统前面盲等。

当新 skill 没出现时，用户通常会连续冒出这些问题：

1. 我是不是放错目录了？
2. 系统是不是还没刷新？
3. 现在看到的是旧缓存还是实时结果？
4. 要不要重启应用？
5. 还是其实 skill 本身写坏了？

这些问题里，真正只有少数和 skill 内容有关，大部分都属于“我不知道系统此刻是否看见了我的变更”。刷新按钮的价值，就是把这种不透明状态压缩成一个可执行动作：我不猜了，我现在主动要求重新发现。

为什么执行型助手比普通应用更需要这个按钮？

因为它的错误成本更高。

在普通内容应用里，列表少一个插件，最多只是功能暂时不可用；但在执行型助手里，技能是否被发现，可能直接影响：

• 当前请求会不会匹配到正确 skill；
• 助手是否会沿着正确流程执行；
• 某个任务是复用既有 procedure，还是退回从零摸索；
• 共享状态文件会不会被读到错误副本。

换句话说，技能列表不是装饰性的“可选功能入口”，而是执行链路的路由层。只要路由层还有旧索引，后面的计划、执行、记忆和状态都可能走偏。

刷新按钮为什么不是“给高级用户的隐藏开关”？

因为新增 skill 本身就是高频动作。

尤其在本地 AI 助理场景里，用户会不断做这些事：

• 新增一个 skill 目录；
• 修改 SKILL.md 的名字、描述和适用场景；
• 从另一个仓库复制一份 skill 过来；
• 把 skill 从副本迁回统一目录；
• 调试技能发现逻辑是否已经吃到最新文件。

如果每次改动后都只能等 TTL 自然过期，用户对系统的主观感受就会变成：“我已经改好了，但系统什么时候认出来要靠运气。”

而刷新按钮把这个体验改写成：“我刚改好了，现在就验证系统是否认出来。” 对调试和迭代速度来说，这是质变，不是小优化。

从产品角度看，刷新按钮其实是在补“因果反馈”

一个好用的系统，不只是功能完整，还要让用户理解“我做了什么，系统因此发生了什么”。

新增 skill 是一个明确动作，用户自然期待一个明确反馈：

• 我把目录放进去了；
• 我点了刷新；
• 系统重新扫描；
• 新 skill 出现在列表里，或者明确告诉我哪里还有问题。

如果中间缺了“点刷新”这一步，因果链就断了。用户虽然做了变更，却没有一个对应的确认动作，只能靠等待、猜测和反复重启来逼近真相。这种体验的根本问题不在缓存，而在缺少一个让用户介入索引重建的显式入口。

刷新按钮还能降低什么误判？

最大的误判，是把“还没发现”当成“已经失败”。

现实里经常出现这种情况：

• skill 文件其实没问题；
• 路径也没错；
• 只是界面还停留在旧索引；
• 用户于是误以为 skill 写坏了，开始回头改内容。

结果越改越乱，真正的问题却只是“系统还没重扫”。

有了刷新按钮，排查顺序会更清晰：

1. 先确认 skill 在当前版本会扫描的目录里；
2. 立刻点一次刷新；
3. 若仍未出现，再考虑是否需要全局重扫；
4. 最后才回头看 SKILL.md 或元数据本身。

这会把大量本来会落到“误改 skill 文件”的故障，提前截停在发现层。

为什么它还关系到路径一致性，而不只是 UI 可见性？

因为技能发现一旦混入旧副本、错路径或旧缓存，后果不只是“列表里少一项”，还可能是“系统看起来认得这个 skill，但实际跑的是另一份来源”。

content-pipeline skill 有一个很重要的约束：共享状态必须始终读写 D:/omnigoai/.claude/skills/content-pipeline/ 下那一份，而不是某个副本里的同名文件。原因很简单：说明文档可以有副本，状态真相只能有一份。

技能发现也是一样。刷新按钮的意义之一，就是让用户在完成目录迁移、复制或修正入口路径后，能立即要求系统重新建立“技能名 → 实际目录 → 状态文件”的对应关系。

所以，刷新按钮解决的不只是“看不看得到”，而是“系统现在引用的是不是最新且正确的那一份”。

为什么仅有 TTL 不够，仅有刷新也不够？

一个更完整的技能发现系统，最好同时有三层：

• TTL：保证常规浏览时速度稳定；
• 刷新按钮：保证用户刚改动后可以立即触发重建；
• 全局重扫：保证目录结构变化、映射方式变化时还有更彻底的修复手段。

少了任何一层，体验都会明显变差：

• 只有 TTL：用户一直等，不知道系统有没有看见变更；
• 只有刷新：每次都全量重扫，界面成本和抖动会增加；
• 没有全局重扫：某些根路径级别的问题，普通刷新永远修不好。

这就是为什么“缓存 TTL、刷新按钮、全局重扫”应该被看成同一个发现系统里的三件套，而不是互相替代的开关。

一个更实际的使用建议：什么时候该先刷新，什么时候该重扫？

场景 1：刚新增一个 skill 目录

先点刷新。大多数正常新增都属于这个级别，不需要直接上更重的全局重扫。

场景 2：你改了 skill 名称、描述或匹配范围

也先点刷新，因为这是索引元数据的更新，通常一次刷新就能生效。

场景 3：你改了技能根目录、复制/挂接方式或统一目录结构

直接考虑全局重扫。因为问题可能不是旧缓存，而是扫描范围本身发生了变化。

场景 4：刷新后仍看不到，而且文件管理器里明明有

再去检查路径语义，例如当前版本是否支持跟随 junction 或 symlink。文件存在只能证明磁盘上有它，不能证明发现器已经走到它。

为什么“刷新按钮”这个小功能会影响用户对整个助手系统的信任？

因为用户真正想确认的不是“按钮能不能点”，而是：这个系统是不是按我刚才的改动来工作的。

只要新增 skill 后列表迟迟没变，用户就会自然怀疑整个系统的状态一致性：

• 它读到的是不是旧缓存？
• 它执行的是不是旧 skill？
• 它记住的路径是不是旧目录？

而一个清晰、即时的刷新入口，会把这种怀疑缩小为一个可验证流程：改动、刷新、看结果、继续排查。对执行型 AI 助理来说，这种确定性比“后台其实迟早会扫到”重要得多。

常见问题

FAQ 1：新 skill 刚放进去，第一步应该做什么？

先别重写 skill，也别先重启应用。先确认目录放对了，然后手动点一次刷新，看系统是否重新发现它。

FAQ 2：刷新按钮和等缓存 TTL 到期，有什么本质区别？

TTL 到期是系统被动更新；刷新按钮是用户主动要求立即重建索引。前者解决性能平衡，后者解决操作确定性。

FAQ 3：为什么我在文件管理器里能看到 skill，GoWork 里却看不到？

因为“文件存在”只能说明磁盘上有这份文件，不说明技能发现器已经扫描并索引了它。常见原因是旧缓存仍有效，或当前版本的扫描器没有走到真实目录。

FAQ 4：刷新一次没用，就说明 skill 写坏了吗？

不一定。刷新失败后，下一步应检查是否需要全局重扫，以及目录入口、复制/挂接方式是否正确；只有这些都排除后，才值得怀疑 SKILL.md 本身。

如果你把刷新按钮当成一个“无关紧要的小功能”，很容易低估它在执行型产品里的真实价值。它不是给界面增加一个图标，而是在技能发现这条链路里补上明确的因果反馈与用户控制权。这也是为什么 GoWork 这类常驻 AI 助理，不只需要会思考的模型，还需要一套让索引、路径和执行入口保持一致的产品机制。想继续看 GoWork 怎样把技能、计划和执行状态串成一个系统，可以再看 新技能为什么装好了却还看不到？GoWork 的技能发现缓存、刷新与重扫、多步任务为什么不能只在当轮写计划 和 GoWork 下载页。