这是啥
AIBuilder 项目最大的方法论创新:把好朋友的提问 → 原始对话记录 → 结构化 wiki 的全自动 + 半人工流水线，用两个本地 agent 跑起来。
这条目讲的是机制本身——你可以抄这套机制用到自己的场景（教学、客户支持、团队知识库等）。
为什么需要”机制”，不是”写文档”
传统社群知识库的失败模式:
- 管理员一个人写——写不过来，而且只反映他自己的视角
- 社群成员贡献——激励不足、格式混乱、零散
- “我有空再整理”——永远没空
核心困境:提问 → 回答这个动作已经自然发生了（每天有人问有人答），但答完之后知识就消散了。下一个人问同一问题，还要重来一遍。
本项目的三环流水线
┌─────────────────────────────────────────────┐
│ 环 1：提问发生（自然） │
│ 好朋友 → chat widget → 提问 │
│ → 原始对话存 raw/YYYY-MM-DD/ │
└─────────────────┬───────────────────────────┘
↓
┌─────────────────────────────────────────────┐
│ 环 2：深度探索（AI 学习者 + 陈彬） │
│ 发现"这题值得深入" │
│ → 陈彬 + AI 学习者对话探索 │
│ → 产出"素材项目"（wiki/_素材项目/探_*/） │
│ → 写入 ai-xueze_pending.md 通知 AI 学者 │
└─────────────────┬───────────────────────────┘
↓
┌─────────────────────────────────────────────┐
│ 环 3：编译+策展（AI 学者 + 陈彬） │
│ AI 学者读 raw + 素材项目 │
│ → 双源合并、聚类、评估、抗迎合护栏 │
│ → 产出 wiki/_candidates/proposal_*.md │
│ → 陈彬策展（approve/reject/edit） │
│ → 批准的搬 wiki/ │
│ → 下一个人问类似问题，RAG 直接命中 │
└─────────────────────────────────────────────┘
来源:CLAUDE.md + 蓝图 v1.7 附录 A/B + ai-xueze.md 协议 + ai-xuexizhe.md 协议。
关键设计选择（每个都有权衡）
选择 1:双 agent 完全独立，不互相调用
两个 agent（AI 学习者、AI 学者）只通过一个共享文件通信:wiki/ai-xueze_pending.md。AI 学习者追加写 → AI 学者读后标已处理。
为啥这样设计:上下文隔离。一个 agent 的对话累积不污染另一个。
选择 2:AI 学者不能直接写 wiki
AI 学者只能写 wiki/_candidates/。搬到 wiki/ 正本必须陈彬明确授权。
为啥这样设计:人工策展是抗幻觉 / 抗迎合的最后一道门槛。小规模知识库不 scale，但质量可控。
选择 3:抗迎合四条护栏强制执行
单源条目必须有:
- 源单薄性声明 callout
- 写法克制（不用”最佳实践”/“业界标准”）
needs_sourcesfrontmattersource_density: thin|medium|thick
为啥这样设计:AI 天然倾向”给出漂亮归纳”。单源素材归纳不出”共识”，但 AI 会装作能。护栏是强制它诚实的机制。
选择 4:每周一次编译节律，不追实时
不是每次 raw/ 有新对话就跑编译。而是每周一次（T17 节律）。
为啥这样设计:频次 ≥ 2 才进候选——单次问答不是知识，是对话。累积到”多个人问类似”再编译才有意义。
与 Boris 的”Compounding Engineering”的对比
来源:boris-cherny/how-boris-uses-cc.md tip 4+5。
Boris 的做法:代码 review 时 @claude，规则直接加进 CLAUDE.md。每次踩坑 = 规则增长一条。
本机制做法:好朋友提问 → 答案 → 编译进 wiki。每次问答 = 知识增长一条。
两者本质一样——把”一次性”事件转化为”持续性”资产。区别:
| 维度 | Boris 的 Compounding Engineering | 本项目的 raw → wiki |
|---|---|---|
| 触发点 | PR review 时 | 好朋友 chat 时 |
| 沉淀载体 | CLAUDE.md（代码库内） | wiki（独立站） |
| 处理 | Claude 自动加 | AI 学者编译 + 陈彬策展 |
| 目的 | 团队代码质量 | 社群方法论扩散 |
实际效果（Obj 2 KPI）
蓝图 v1.7 的 Obj 2 目标:Day 1 起 1 周内 ≥ 5 次”后来者受益于先来者”事例。
“一次事例”定义:
- A 先问过问题 X，被记入 raw
- X 被编译进 wiki
- B 后来问了类似 X’ 问题
- chat widget RAG 从 wiki 命中相关条目作答
- B 的反馈证实”这答案有用”
这五步闭环 = 一次事例。5 次 = 机制跑通。
能抄这机制的场景
不只是 AI 社群知识库:
- 课程答疑（学生问过的编译成 FAQ 库）
- 客户支持（support ticket 编译成 knowledge base）
- 团队内训（新人问题编译成 onboarding wiki）
- 写作社群（作者问题编译成方法论库）
关键要素都一样:
- 提问自然发生（不用专门组织）
- 自动记录（不要求人主动整理）
- 定期编译（频次 ≥ 2 才进候选）
- 人工策展（AI 产候选，人决定正本）
陈彬视角
这套机制的核心不是”AI 自动写 wiki”，是”人的审美+AI 的体力”的分工。
- AI 负责:读大量 raw、聚类、起草、标源、检查链接（体力活）
- 人负责:判断哪条值得写、哪段该改、哪里装懂、哪个词不合味（审美活）
最容易搞砸的设计:让 AI 直接写正本 wiki。规模一大、幻觉就来、迎合就来、“一本正经胡说八道”就来。
最笨但有效的设计:永远让人做最后一关。即使我（陈彬）每周只花 10-15 分钟策展，这 10-15 分钟就是知识库质量的保险。