⚠️ 源单薄性声明 本条目素材主要来自陈彬自己订的协议和 skill 文件（AI 学者 agent 协议、kb-compile skill），不是陈彬对”为什么要这么做”的反思文本。 已讲清楚：流程长什么样、每个字段为什么存在 还没听到：陈彬策展时的心路（看到候选时他判断什么）、拒绝的典型模式、策展效率的真实数据 本条目是”流程规范级”，哲学层等陈彬亲笔。
一句话
陈彬不亲自写 wiki 条目——AI 学者产候选，陈彬逐条打 approved / rejected / needs-edit 三选一，approved 的才搬到正本。
不是审校，是守门。
为什么这套流程长这样
来源：~/AIBuilder/.claude/agents/ai-xueze.md 的触发流程、~/AIBuilder/wiki/_candidates/ 的实际产出、~/AIBuilder/CLAUDE.md 的绝对约束。
分工的底层逻辑
AI 学者（ai-xueze.md）被明确定义只能写两个地方：
wiki/_candidates/（候选，等策展）wiki/_health_report.md（lint 报告）
正式的 wiki/*.md AI 学者不能直接写。只有陈彬说”把 approved 的搬到 wiki/“后，AI 学者才能搬。
这是一道硬门。防止 AI 自己给自己盖章。
为什么不让 AI 全自动？
如果全自动，会发生：
- AI 把”听起来合理的”当成”正确的”
- 素材单薄的条目和厚实的条目被混在一起无法区分
- 陈彬视角没法注入（AI 没法代替陈彬判断”这条算不算陈彬主张”）
策展这个环节就是保留人类价值判断的点。
为什么不让陈彬全亲笔？
如果全亲笔：
- 陈彬一周写不出几条
- 社群里好朋友问的问题，陈彬不一定都见过（AI 学者从 raw/ 里拣比他全）
- 陈彬自己就累成狗了，没时间做更重要的事
折中：AI 做”聚类 + 起草”这件慢活，陈彬做”判断 + 定调”这件快活。时间上陈彬每周 10-15 分钟。
陈彬实际怎么策展（可观察的部分）
从候选文件的 frontmatter 字段推——每条候选必有：
human_review_status: approved | rejected | needs-edit | 占位
human_review_notes: "（陈彬写一两句为什么）"approved：直接搬到正本 rejected：不搬，候选留档，附原因（如”社群 0 实战，等实操再说”） needs-edit：陈彬亲手改或指示 AI 学者改后再审 占位：陈彬主笔级——AI 学者留个壳，等陈彬本人亲笔（本条就是这个状态的一个例子早期版本）
实际案例（从 _index.md 的更新历史看得到）
- P1 批：8 条入库，主动撤回 2 条（Computer Use、Ultraplan/Ultrareview）。理由写在
_index.md：“社群跑不起来，等实操”。 - P0.2 批：11 条入库，撤回 2 条（Cursor、Codex）。
- 累计撤回 4 条等补源。
策展不只是”approve 好的”——还包括主动枪毙”不够格的”。撤回的决定会写入 _index.md 的”主动撤回”段，透明记录。
一条候选长什么样（流程图）
好朋友在 widget 里问问题
↓
cron sync/pull-raw.sh 每天拉到 raw/YYYY-MM-DD/
↓
陈彬周一说"启动 AI 学者"
↓
AI 学者调 kb-compile skill：
- 读 raw/ 新增文件
- 聚类（频次 ≥ 2 且答案稳定才进候选）
- 去重（查 wiki/ 已有）
- 起草 draft，附 source_density 标注
- 输出到 wiki/_candidates/proposal_YYYY-MM-DD.md
↓
陈彬用 Obsidian 打开 proposal，逐条看：
- 一句话结论对不对？
- 论据厚不厚（source_density）？
- 和已有 wiki 冲突还是互补？
- 是"陈彬观点"还是"AI 推断"？
- 打 approved / rejected / needs-edit
- 填 human_review_notes
↓
陈彬说"搬 approved"
↓
AI 学者 cp approved 条目到 wiki/，补 source_raw，git commit
↓
AI 学者调 kb-lint，产 _health_report.md
总耗时：陈彬端 10-15 分钟/周。AI 学者端几分钟。
策展的几条明示原则（从 AI 学者协议和 _index.md 反推）
1. 频次 ≥ 2 才进候选
一个问题被问过一次——可能是偶然。被问过两次+——社群级模式。
AI 学者 kb-compile 协议里明写：“频次 ≥ 2 且答案稳定的才进候选”。
2. source_density 分三级且明示
每条都标：
- thick：≥ 2 个独立来源交叉验证（骨干）
- medium：1-2 个来源，同作者多份也算 medium
- thin：单源，明确占位等补源
thin 条目上必须顶着 callout 警示”源单薄性声明”——不装厚实。
3. 多观点并存 > 单一推荐
遇到架构级分歧（如 RAG vs Markdown-first），并存两个观点而不是强推一个倾向。
来源：陈彬本人 2026-04-18 反馈：“我们不追求唯一答案，wiki 允许多观点并存。”
落地：
- RAG 入门 和 Obsidian-AI 的反 RAG 观点 并排存在，互相交叉引用
- 每条讲清”什么场景该用这条 / 什么场景不该用”
4. 主动撤回比 approved 更重要
撤回要显形。_index.md 有专门的”主动撤回”段，记录：
- 撤回条目名
- 撤回原因
- 下次什么条件满足才重新入
比”approved 一直加”更能体现策展质量——拒绝得好看，才是策展人。
5. 策展轨迹入 git，留痕
每次 approved 搬到正本都跟一次 git commit。陈彬的 human_review_notes 变成条目 frontmatter 的一部分，永久留痕。
半年后回来查：“这条为什么是这样写的？当初陈彬在 notes 里写的理由是什么？“——全在 git log 里。
和其他知识管理方法的差别
| 方法 | 谁写 | 谁审 | 谁定调 |
|---|---|---|---|
| 传统 wiki（Wikipedia） | 社群共写 | 社群共审 | 共识 |
| 博客/newsletter | 作者 | 作者 | 作者 |
| 陈彬式 | AI 聚类起草 | 人类（陈彬）逐条守门 | 陈彬 |
核心差异：作者和编辑分离——AI 是作者，人是编辑。
这和写作行业”作者亲笔 + 编辑校”不一样——这里作者不是人，编辑才是人。
什么时候这套不适合
- 知识需要绝对权威（比如法律条文、医疗指南）——AI 聚类可能漏掉关键先例，不能只靠人策展把关
- 社群规模小（< 20 人）——频次 ≥ 2 这条门槛过不去，大部分问题只会被问一次
- 你没时间每周策展——没人策展，候选就沉积，系统失效
给想学的人
如果你要抄这套：
- 先设独占写权限的 agent——AI 学者是唯一能写正本的角色
- 建
_candidates/候选层——所有 AI 产出先进候选，不直接发布 - 定 frontmatter 强制字段：
human_review_status/human_review_notes/source_density - 定撤回机制——不是只有 approved 一种命运；撤回也要显形
- 节律：每周一次策展，不要天天审——会让策展变成苦役
陈彬视角（占位——等亲笔扩）
- “为什么我不自己写 wiki”——陈彬到底在保留什么给自己？
- 策展时的常见”踩雷”模式：AI 最容易写错/飘的是哪一类？
- 策展效率的真实数据：10 条候选平均几条 approved？
- 这套和陈彬在 PK 里自己手写 wiki 的差别——为什么 AIBuilder 要分离作者/编辑，而 PK 不需要？
关联
- 紧邻：raw → wiki 知识沉淀机制（策展是这个机制的第 4 步）
- 紧邻：Gaia Knowledge System 是什么（策展是 Gaia 规则 3 “独立验证”的落地）
- 紧邻：多 Agent 协作实战_陈彬式（分工哲学的延伸）
- 对照：Obsidian-AI 的反 RAG 观点（个人 Obsidian 用户不需要策展；社群规模需要）
needs_sources（明确待补）
- 陈彬的实际策展心路（亲笔）
- 策展效率数据（15 分钟能审多少条）
- 典型 “rejected” 模式（哪类候选最容易被枪毙）
- 和 PK 自写 wiki 的工作流对比