编程 Agent 会分析/解决问题，但不会积累经验。它们有印象，但没有笔记。RadioHeader 给 Claude Code 补上了这一层。
我用 Claude Code 做 iOS 的时候，遇到过一次 app 启动白屏几十秒的问题。Claude 一路查日志、翻文件、试各种排查，折腾了很久都没定位到。最后还是我想起来，另一个项目以前也出过差不多的事，让它去翻那个项目的旧记录，才找到根因——Xcode 的 scheme 设置问题。
那一刻我就很确定一件事：像 Claude Code 这样的编程 Agent ，分析问题、写代码都很强，但它们不会共享项目经验。后来 Claude Code 虽然也加了 memory ，但本质问题没变——它记得方向，记不住关键细节，更别说跨项目复用了。
项目之间的记忆完全隔离，就意味着项目 A 踩过的坑，项目 B 根本不知道。如果我自己记得”我好像遇到过这个问题”，还能手动指路，要是我也忘了呢？
现有的工具几乎都是在做"规则"层面的事。规则当然有用，但规则无很难达到“这个坑我真的踩过，而且已经知道怎么修"这种程度。做硬件产品的时候我也经常遇到这类"认知型经验"——不是文档里写了你就会的，得自己撞上、解决了，才真正印象深刻。
在没找到做编程 agent”经验"层面的工具的情况下，我自己做了一个。
RadioHeader 不是一开始设计好的，是被真实问题一步步逼出来的。
起点是单项目内的记忆缺失。Claude Code 在一个项目里工作久了，早期的经验就开始模糊。它记得"之前遇到过类似问题"，但记不住具体怎么解决的。
换句话说：Agent 需要的是笔记，不是印象。 自带的 memory 记的是大致印象，而能被精确搜索到的结构化笔记才有复用价值。
我的想法很朴素：让 Claude 每次解决完问题后，主动把经验记下来。具体分两种：一种是经验条目，写进 memory/ 目录——根因、修法、注意事项，按主题组织，方便以后检索；另一种是任务日志，写进 logs/ 目录——以一个问题的解决为单位，记录背景、过程、结论，保留完整上下文。日志的文件名经过设计：日期-主题-撰写者，Agent 和人类都要署名，标清楚方便追溯。起初我会在关键节点手动提醒 Claude"同步一下项目信息"，后来逐渐做成了自动化。
我把这个机制叫经验回流——完成一个任务后，经验自动流回记忆系统。每次修完 bug 、做了架构决策、踩了非直觉的坑，Claude 都把经验写回去。用 Claude Code 的 hook 机制让这个过程自动：PostToolUse hook 在写入 memory 时触发检查，Stop hook 在会话结束时提醒有没有新经验遗漏。
同一个项目里，以前要重新排查的问题，现在翻笔记就能解决。
但很快就遇到了开头那个场景：项目 A 的笔记，项目 B 搜不到。
于是我在所有项目之上建了一个全局经验中枢：~/.claude/radioheader/。
名字的由来——我喜欢 Radiohead 这个乐队，而这个全局中枢又像一个信号塔，各个项目需要的时候就从里面接收信息。RadioHeader ，就这么出现了。
架构变成了三层：
┌─────────────────────────────────┐
│ RadioHeader （全局经验中枢） │ ← 所有项目共享
├─────────────────────────────────┤
│ 项目 memory/（项目专属记忆） │ ← 当前项目
├─────────────────────────────────┤
│ 会话上下文（临时） │ ← 当前对话
└─────────────────────────────────┘
每次经验回流时，Claude 会顺手判断一下：这条经验是不是跨项目通用的？如果是，写入全局层，标注来源项目。之后任何项目遇到类似问题，先搜这里。有了 RadioHeader 这个信号塔的隐喻之后，我把经验回流叫做 Echo（回波）——经验像信号的回波一样，从项目返回信号塔。
装了之后再遇到白屏问题：
你：App 启动白屏 10 秒以上
Claude：RadioHeader 中有来自 ProjectA 的经验：
"Xcode scheme 的 Launch 配置导致 iOS app 启动白屏，
检查 scheme 设置中的相关选项……"
验证一下是否适用…… ✓ 同样的模式。正在应用修复。
不用我手动指路了。同一类问题从第二次开始，解决时间从分钟级掉到秒级。不是 AI 变聪明了，是答案已经在那里了。
跨项目共享之后冒出一个新问题：经验一旦放到全局以后，原始条目里保留的项目上下文太多，搜索噪音和 token 消耗都上来了。比如一条经验写着 [来源:DarkWriting] iCloud I/O 阻塞主线程，另一个项目用的是 CoreData 不是 iCloud——但根因相同。项目名和具体技术细节反而成了搜索障碍。
于是我加了一层精炼：短波（ Shortwave ）——去掉项目名、文件路径、框架细节，只保留通用知识。这不光是为了降噪，也是为了保护隐私——经验条目在精炼之前可能包含项目路径、内部命名甚至 API key ，短波会把这些全部剥离。
这样三层就接上了：经验先通过 Echo 回到 RadioHeader，再由 Shortwave 去掉项目噪音，变成可广播的通用知识。
---
id: sw-ios-task-inherits-mainactor
domain: iOS, SwiftUI, Concurrency
tags: 白屏 | 启动慢 | white screen | slow launch | 10s+ | Main Actor | Task
---
### Task {} 在 @MainActor 上下文中继承主线程，I/O 阻塞导致白屏
symptoms: 应用启动后 10s+ 白屏，首次加载卡死
cause: Task {} 在 @MainActor 标记的上下文中创建时继承主线程
fix: 使用 Task.detached(priority:) 将 I/O 操作移出主线程
注意 tags 里的"白屏"、"启动慢"、"slow launch"——这些是开发者实际会搜的词。如果只保留 "Task.detached" 这种解法关键词，这条经验就搜不到了。症状关键词比解法关键词重要得多。 经验条目删掉了症状词就等于不存在。
到这里遇到了另一个让人头疼的问题：Claude 搜到了经验，但不用。
早期我在 CLAUDE.md 里写："遇到技术问题时先搜索 RadioHeader"。Claude 确实搜了，也找到了相关结果——然后完全忽略，直接跳进独立分析。就像你给新同事一本 wiki ，他打开看了一眼，还是选择自己摸索。
后来搞明白了：行为指令比知识描述有效得多。 在 CLAUDE.md 里写"这里有个东西可以查"没用，得写"你必须搜，搜到必须引用，禁止搜到不用"才行。这两种写法在 Agent 系统中效果差很远。
最终方案是"搜→用→追"三步强制规则：
外加一句禁令："禁止搜到相关经验却不引用、不应用，直接跳过去做独立分析"——这句话比前面三条都管用。
前两步解决了自己不重复踩坑的问题，但我的经验仍然是一座孤岛。我遇到的问题，世界上某个人在开发中一定早就有经验了；反过来，我踩过的坑可能也正好能帮到别人。
能不能把精炼好的短波共享出去？难题不在技术，在质量治理——不能什么都往池子里丢，但我一个人也做不了人工审核。
当时我想到试试从生物学里找找灵感，结果还真找到了一个概念——Stigmergy （痕迹协作）。这是蚁群行为学里的东西：蚂蚁在路径上留信息素，走的越多越浓，没蚂蚁走的自然蒸发。不需要谁来管理，好路径自己就显现出来了。
用这个思路做知识共享的质量治理：
verified，低分归档发布也有门槛——质量评分（≥6/8 ）、隐私扫描（确保没泄露路径和密钥）、去重检查。不需要管理员，好经验自己浮上来，差经验自己沉下去。
我不是做完一个 demo 就拿出来讲故事，这套东西已经在我自己手里滚了几个月。13 个项目，覆盖 iOS/SwiftUI 、Rust 、后端部署、网络代理、AI API 、Claude Code 、硬件产品 7 个技术领域。205 条原始经验，120 条精炼短波，114 条发布到社区池。（截止发稿时）
不用先研究完整设计，找一个你最近最常重复踩坑的项目，装上跑一周就知道它有没有用。
git clone https://github.com/ZaptainZ/radioheader.git
cd radioheader
./install.sh
之后在任何项目中启动 Claude Code 就生效了。
# 开启社区共享
radioheader community on
radioheader sync
GitHub：ZaptainZ/radioheader
RadioHeader 还在继续打磨，但它已经在我自己的真实项目里跑出价值了，所以我把它公开出来。开源社区帮了我很多，这次也算把自己真用出来的一套东西拿出来回馈。
MIT 协议。你要是也受不了重复踩坑，直接装上试试。有用欢迎 star ，没用也欢迎来 issue 吐槽。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。