Zaptain

@Corrots 感谢建议，我研究一下哈

@XTTX 转述 cc 的回复：“他的理解部分对，但忽略了 RadioHeader 架构中几个关键设计选择的原因。

他说对的部分

- Skills 确实轻量：只有 name + description 常驻上下文，正文按需加载
- 对于离散的操作动作（比如 radioheader search 、radioheader
publish ），写成 skill 是合理的

他忽略的核心问题

1. Skills 是按需触发的，Hooks 是自动触发的

RadioHeader 的 PostToolUse hook 在 memory/ 被写入时自动触发 Echo
检查，不需要任何人记得调用。这用 skill 做不到skill 必须由 agent
或用户主动调用。

2. RadioHeader 最大的教训恰恰是"可选 = 不用"

你文章里写得很清楚：早期版本告诉 Claude "可以搜
RadioHeader"，结果搜了也不用。修复方案是强制行为规则写在 CLAUDE.md
里，每个会话都加载，不可跳过。

如果把"搜→用→追"做成 skill ，它就从 MUST 降级成了 CAN 。Agent
需要先判断"我要不要调用这个 skill"而你已经验证过，给它选择权 =
它选择跳过。

3. PostToolUse 的 additionalContext 是系统级注入

Hook 的 additionalContext 被 Agent
视为系统级指令，优先级高于普通对话内容。Skill 的内容是作为 prompt
注入的，权重不同。这是你在 projectBasicInfo 里记录过的关键经验。

总结

┌──────────────────────────┬──────────────┬──────────────────────────┐
│ 机制 │ 适合做 skill │ 必须用 hook/CLAUDE.md │
├──────────────────────────┼──────────────┼──────────────────────────┤
│ 搜→用→追规则 │ │ 强制行为，不可降为可选 │
├──────────────────────────┼──────────────┼──────────────────────────┤
│ Echo 自动触发 │ │ PostToolUse 自动 fire │
├──────────────────────────┼──────────────┼──────────────────────────┤
│ Stop 提醒 │ │ 会话结束自动 fire │
├──────────────────────────┼──────────────┼──────────────────────────┤
│ radioheader search 操作 │ │ │
├──────────────────────────┼──────────────┼──────────────────────────┤
│ radioheader publish 操作 │ │ │
├──────────────────────────┼──────────────┼──────────────────────────┤
│ 新项目初始化引导 │ │ │
└──────────────────────────┴──────────────┴──────────────────────────┘

他的建议不是错的，但适用于操作层而非行为规则层。RadioHeader
的核心价值恰恰在后者如果行为规则变成可选
skill ，就回到了你已经踩过的坑。

可以回复他：具体操作确实可以做成 skill ，但 RadioHeader
的核心是强制行为规则 + 自动触发的 hooks ，这两个必须常驻而非按需加载这正
是踩了"搜到但没用"这个坑之后的设计决策。”

@akatquas 之前想过 rag ，但体积会大很多，不太值得，所以初期就先放弃了

@bytesfold 总结得好

@buried 可以的呦！

@jasonkxs 不好意思哈，暂时不需要

请感兴趣的、愿意普及 AR 技术的伙伴来聊啊！！！！还缺人手

@winnerczwx 目前在做 demo 的阶段是用 unity 做的

@ripperdev 因为那位老哥用 python 和 go 有搞机器学习的能力，我们可以用到，纯后端目前是有一位的