Seven | 小柒的 RSS 预览

PARA 方法论完全解读:按可行动性组织你的第二大脑

2026-11-07 11:57:10

<blockquote>想要用好 AI 离不开上下文管理,上下文管理引出了 AI 知识库。想着把写了好多年的笔记整理一下方便 AI 了解我,于是有了这篇文章。</blockquote><h1 id="出处与背景"><a href="#出处与背景" class="headerlink" title="出处与背景"></a>出处与背景</h1>PARA 由生产力专家 Tiago Forte(Forte Labs 创始人)提出,2016 年起在其《Building a Second Brain》(BASB)课程中讲授,2022 年出版成书《打造第二大脑》(中译本同名),2023 年又推出了小册子《The PARA Method》作浓缩版。PARA 不是一套完整的笔记方法论,而是 BASB 体系中 CODE 工作流里 “O”(Organize)的具体落地方案:<figure class="highlight text"><table><tr><td class="gutter"><pre>1 2 3 4 5 </pre></td><td class="code"><pre>CODE(工作流:信息怎么流动) PARA(结构:信息住在哪) C - Capture 捕获:记下有共鸣的 O - Organize 组织:按用途存放 ← PARA 在这里 D - Distill 蒸馏:层层提炼精华 E - Express 表达:产出成果 </pre></td></tr></table></figure>核心命题:你的”第二大脑”是一个外部系统,负责记住你不必记住的东西,从而释放第一大脑去做创造性工作。而组织这个系统的钥匙,就是 PARA。<hr><h1 id="核心哲学-按可行动性组织-而非按主题组织"><a href="#核心哲学-按可行动性组织-而非按主题组织" class="headerlink" title="核心哲学:按可行动性组织,而非按主题组织"></a>核心哲学:按可行动性组织,而非按主题组织</h1>这是理解 PARA 的钥匙,其余全是推论。传统组织方式是”图书馆式”的:按主题/学科分类——技术、健康、理财、读书笔记……它问的问题是:<blockquote>“这条信息属于什么主题?”——答案有无穷多个,每次都要做艰难的归类决策,且分类本身不产生任何行动力。</blockquote>PARA 问的是另一个问题:<blockquote>“这条信息能帮我推进什么?”——答案有限且具体,决策快,且直接连接行动。</blockquote>由此得到 PARA 的排序原则:P → A → R → Archive 是可行动性(actionability)的降序排列。这个顺序不是随机命名,而是检索优先级:当你需要找东西时,永远从最可能”马上有用”的地方找起。书中借用了柯维的影响圈/关注圈概念:Projects 在你的影响圈内(你能直接改变结果),Resources 在关注圈(你只是感兴趣)。组织系统的重心应该压在影响圈上。另一个思想来源是 GTD(David Allen):PARA 的 Areas 大致对应 GTD 的”职责范围/高视野”,Projects 对应 GTD 的”项目”,但 PARA 简化了 GTD 的层级,把它压缩到人人可维护的四类。<hr><h1 id="四个类别详解"><a href="#四个类别详解" class="headerlink" title="四个类别详解"></a>四个类别详解</h1><table><thead><tr><th></th><th>Projects</th><th>Areas</th><th>Resources</th><th>Archives</th></tr></thead><tbody><tr><td>一句话</td><td>有终点的工作</td><td>无终点的责任</td><td>无责任的兴趣</td><td>其他三类的休眠区</td></tr><tr><td>判定测试</td><td>有明确成果 + 截止日期?</td><td>长期需维持某标准?</td><td>只是感兴趣?</td><td>还活跃吗?</td></tr><tr><td>例子</td><td>“完成 2026 报税”</td><td>财务</td><td>税务知识收集</td><td>已报完的 2025 报税项目</td></tr></tbody></table><h2 id="Projects-项目-——-一系列通向明确成果、有截止日期的任务"><a href="#Projects-项目-——-一系列通向明确成果、有截止日期的任务" class="headerlink" title="Projects(项目)—— 一系列通向明确成果、有截止日期的任务"></a>Projects(项目)—— 一系列通向明确成果、有截止日期的任务</h2><ul><li>定义要点:成果可判定(done / not done 二值)+ 时间有限</li><li>例子:”完成年度体检并跟进异常指标”、”做完日本旅行攻略”、”给房子重新贷款”</li><li>PARA 要求每个项目有:一句清晰的目标陈述、时间线、以及相关的笔记/材料</li><li>Projects 是行动发生的地方,也是你日常打开频率最高的地方</li></ul><h2 id="Areas-领域-——-需要长期维持标准的责任范围"><a href="#Areas-领域-——-需要长期维持标准的责任范围" class="headerlink" title="Areas(领域)—— 需要长期维持标准的责任范围"></a>Areas(领域)—— 需要长期维持标准的责任范围</h2><ul><li>定义要点:没有终点,只有”要维持的标准”;长期疏于维护会产生真实代价</li><li>例子:健康、财务、职业发展、家庭、住房、团队管理</li><li>判定技巧:”如果我放任不管 6 个月,生活会不会变糟?”会 → 是 Area</li><li>Area 本身不产出行动,它是生成 Project 的母体(见下节)</li></ul><h2 id="Resources-资源-——-持续感兴趣的主题"><a href="#Resources-资源-——-持续感兴趣的主题" class="headerlink" title="Resources(资源)—— 持续感兴趣的主题"></a>Resources(资源)—— 持续感兴趣的主题</h2><ul><li>定义要点:有兴趣、无责任——收集的动力是”可能有用/我喜欢”,而非”我必须维持什么”</li><li>例子:摄影笔记、行业文章剪藏、读书摘录、未来可能做的点子</li><li>它是 PARA 的”缓冲层”:不确定归哪的信息,默认落这里,而不是纠结</li></ul><h2 id="Archives-归档-——-其他三类的一切非活跃项"><a href="#Archives-归档-——-其他三类的一切非活跃项" class="headerlink" title="Archives(归档)—— 其他三类的一切非活跃项"></a>Archives(归档)—— 其他三类的一切非活跃项</h2><ul><li>项目完成 → 整个项目移入 Archives</li><li>兴趣冷却 → 资源移入</li><li>责任终结(如卖掉车、离开团队)→ 整个 Area 移入</li><li>注意官方结构:Archives 是一个顶层类别,内部镜像 P/A/R(<code>Archives/Projects/...</code>、<code>Archives/Areas/...</code>),而不是散布在各处的子目录</li><li>Archives 不是垃圾桶——它是回收站/素材库。旧项目的中间产物经常被未来的新项目复用(书中称”没有死胡同,只有弯路”)</li></ul><hr><h1 id="两道最难的分界线"><a href="#两道最难的分界线" class="headerlink" title="两道最难的分界线"></a>两道最难的分界线</h1><h2 id="Projects-vs-Areas-90-的人会混"><a href="#Projects-vs-Areas-90-的人会混" class="headerlink" title="Projects vs Areas(90% 的人会混)"></a>Projects vs Areas(90% 的人会混)</h2><table><thead><tr><th></th><th>Project</th><th>Area</th></tr></thead><tbody><tr><td>时间</td><td>有限,有终点</td><td>无限,持续</td></tr><tr><td>度量</td><td>成果(做完了吗)</td><td>标准(维持在水平线上了吗)</td></tr><tr><td>语法</td><td>“完成/交付 X”</td><td>“保持/维持 X”</td></tr></tbody></table>关键关系:Projects 是 Areas 的推进手段。每个项目理想上都应挂靠一个领域——领域提供方向,项目提供脚步:<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 2 3 4 </pre></td><td class="code"><pre>Area: 健康 ├── Project: 完成本年度体检并跟进异常指标 ├── Project: 12 周减重 4kg └── Project: 制定并验证营养补充方案(已完成 → 归档) </pre></td></tr></table></figure>反过来说:如果一个”领域”永远不产生项目,它其实是个 Resource(你只是感兴趣,并没有在承担责任)。<h2 id="Areas-vs-Resources"><a href="#Areas-vs-Resources" class="headerlink" title="Areas vs Resources"></a>Areas vs Resources</h2>一句话:Area 是承诺,Resource 是兴趣。”摄影”是 Resource;一旦你开始接单、对客户负有交付责任,它变成 Area。二者可以互相转化,转化点是你是否承担了”不作为就有代价”的责任。<hr><h1 id="流动性-PARA-是循环-不是仓库"><a href="#流动性-PARA-是循环-不是仓库" class="headerlink" title="流动性:PARA 是循环,不是仓库"></a>流动性:PARA 是循环,不是仓库</h1>这是很多实现失败的地方——把它当静态文件柜。PARA 设计上要求条目持续流动:<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 2 3 4 </pre></td><td class="code"><pre> ┌────────────── 完成项目/兴趣冷却/责任终结 ──────────────┐ ↓ │ Inbox → [Projects / Areas / Resources] [Archives] ↑ 兴趣决定行动(Resource→Project) 旧素材被新项目复活 ↑ </pre></td></tr></table></figure>典型流动:<ul><li>Inbox 条目分流到 P/A/R(捕获后快速决策,不纠结)</li><li>Project 完成 → Archives</li><li>Resource 上的兴趣升级行动 → 升格为 Project</li><li>Archives 里的东西被再次需要 → 拉回活跃层</li></ul>驱动流动的是定期回顾(weekly/monthly review):每周扫一眼 Projects,完成的归档、停滞的判断是否还值得留着。<hr><h1 id="设计纪律-PARA-有效的真正原因"><a href="#设计纪律-PARA-有效的真正原因" class="headerlink" title="设计纪律:PARA 有效的真正原因"></a>设计纪律:PARA 有效的真正原因</h1>官方反复强调四条,违反任何一条都会让系统腐化:<ol><li>极致扁平:只允许两层(类别/项目),禁止深层嵌套目录。深层结构 = 每次存取的高决策成本</li><li>跨平台统一:笔记、网盘、邮件用同一套四文件夹,减少心智切换</li><li>自下而上生长:先只建 Projects,Areas/Resources 让需求自己涌现,不要预先设计宏大骨架。PARA 是长出来的,不是画出来的</li><li>允许不完美:归错类的代价趋近于零(全库搜索总能找到),花十分钟纠结分类的代价是确定的。快速决策 > 正确决策</li></ol><hr><h1 id="配套概念-知道即可"><a href="#配套概念-知道即可" class="headerlink" title="配套概念(知道即可)"></a>配套概念(知道即可)</h1><ul><li>渐进式总结(Progressive Summarization):笔记内部的处理法——第一层加粗关键句,第二层高亮加粗中最好的,第三层写摘要。多层”蒸馏”,将来只需读最上层</li><li>中间产物(Intermediate Packets):把工作拆成可独立交付的小单元(一份分析、一张表格、一个大纲),它们天然可复用</li><li>汇聚-发散循环:创造 = 发散收集(进 Resources)+ 汇聚产出(从 Projects 出)</li></ul><hr><h1 id="常见误区与批评-诚实版"><a href="#常见误区与批评-诚实版" class="headerlink" title="常见误区与批评(诚实版)"></a>常见误区与批评(诚实版)</h1><ol><li>“项目”写成”领域”:最常见错误。”健身”不是项目,”12 周减重 4kg”才是</li><li>Resources 变垃圾抽屉:只进不出。解法是定期清理 + 接受它是低价值区</li><li>Inbox 堆积:捕获不分流,系统从入口处腐烂</li><li>PARA 对时间序列内容是弱项:日记、周报、快照类”按时间增长、内容横跨领域”的文档,PARA 原文几乎没有覆盖(见下节)</li><li>与 Zettelkasten 之争:链接派批评 PARA 按目录组织割裂知识网络。实际上两者正交:PARA 管”住址”,链接管”关系”,可以叠加</li><li>维护成本:归档、回顾、流动都要人工纪律,懒人系统会退化成”四个垃圾抽屉”</li></ol><hr><h1 id="PARA-的留白-快照类内容怎么办"><a href="#PARA-的留白-快照类内容怎么办" class="headerlink" title="PARA 的留白:快照类内容怎么办"></a>PARA 的留白:快照类内容怎么办</h1>这是原文没讲清楚、但实践中必然遇到的问题:体检报告分析、财务年度盘点、绩效回顾……这类快照(snapshot)文档有两个特征:<ol><li>带时间戳(某个时间节点的状态评估)</li><li>服务于某个领域的持续维护(衡量”标准是否被维持”)</li></ol>因为带日期,它们容易被误当成日记流水账;因为属于领域,又是典型的 Area 内容。区分标准:<table><thead><tr><th></th><th>Daily 流水账</th><th>领域快照分析</th></tr></thead><tbody><tr><td>组织方式</td><td>按时间,记完即弃</td><td>属于领域,服务持续维护</td></tr><tr><td>内容</td><td>记录”发生了什么”</td><td>状态评估 + 结论 + 行动项</td></tr><tr><td>未来用途</td><td>几乎不回顾</td><td>会被下一次快照对比引用</td></tr></tbody></table>结论:流水账(journal)独立于 PARA 树之外,快照分析归入对应 Area 本体。快照的两种演进模式(决定文件会不会堆积):<table><thead><tr><th>模式</th><th>适用场景</th><th>文件增长</th></tr></thead><tbody><tr><td>追加式:一份 living doc 每期加一节/一列</td><td>快照间核心是趋势对比</td><td>根目录零增长,永远一份文件</td></tr><tr><td>替代式:每期新写一份,旧版移入 Archive</td><td>每次都是全景重算</td><td>活跃层恒定 1 份,归档每期 +1</td></tr></tbody></table>配套的归档规则:快照被新版本替代、且其中行动项已闭环,才进 Archives;归档采用顶层集中式(唯一一个 Archive 类目,内部镜像来源路径),而不是在每个目录下散布 <code>_archive</code>——前者让”全局排除冷层”只需一个路径,也让每个领域目录保持”只有活文档”的绝对不变式。<hr><h1 id="相邻体系-GTD、Zettelkasten、Johnny-Decimal"><a href="#相邻体系-GTD、Zettelkasten、Johnny-Decimal" class="headerlink" title="相邻体系:GTD、Zettelkasten、Johnny Decimal"></a>相邻体系:GTD、Zettelkasten、Johnny Decimal</h1><h2 id="与-GTD"><a href="#与-GTD" class="headerlink" title="与 GTD"></a>与 GTD</h2>PARA 的 Areas ≈ GTD 的”职责范围”,Projects ≈ GTD 的”项目”。GTD 是行动管理系统(下一步行动是什么),PARA 是信息组织系统(材料放在哪)。二者天然互补:GTD 里的行动,其支持材料就住在 PARA 的对应位置。<h2 id="与-Zettelkasten-卡片盒笔记法"><a href="#与-Zettelkasten-卡片盒笔记法" class="headerlink" title="与 Zettelkasten(卡片盒笔记法)"></a>与 Zettelkasten(卡片盒笔记法)</h2>Zettelkasten(及《卡片笔记写作法》)主张原子化卡片 + 双向链接,按”知识网络”而非”目录树”组织。链接派与 PARA 之争是个伪命题:PARA 管住址(它在哪),链接管关系(它和谁有关),目录与链接是正交的两层,主流实践是叠加使用。<h2 id="与-Johnny-Decimal"><a href="#与-Johnny-Decimal" class="headerlink" title="与 Johnny Decimal"></a>与 Johnny Decimal</h2>Johnny Decimal(简称 JD,johnnydecimal.com)是一套编号寻址体系,与 PARA 解决的问题不同:PARA 定义顶层文件夹的语义(放什么),JD 定义信息的地址(怎么编号)。JD 的结构:<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 2 3 </pre></td><td class="code"><pre>Areas(十位组) 10-19 财务 / 20-29 健康 ... └─ Categories 11 银行 / 12 税务 ... └─ Items 11.01 对账单 / 11.02 信用卡 ... </pre></td></tr></table></figure><ul><li>目标:给所有信息一个唯一编号,任何东西几秒内定位,不用记路径只记编号(“30.02”)</li><li>硬约束:每个层面最多 10 个,第 11 个出现时必须分裂或归档——用强制约束防止结构无限膨胀</li><li>惯例:00-09 留给系统元信息(索引、收件箱),90-99 留给归档/遗留</li><li>纪律:目录最多两层 + 小数层、编号不复用</li></ul>与 PARA 叠加:JD 编号 + PARA 语义是常见组合,例如 <code>10-projects / 20-areas / 30-resources / 90-archive</code>——编号提供排序与寻址,PARA 定义每个顶层是什么。⚠️ 术语冲突警告:JD 的 “Area”(十位分组,如 20-29)与 PARA 的 “Area”(责任领域)是两个不同概念,同时研究两套体系时这是最容易混淆的点。本文所有 “Area” 均指 PARA 语义。<hr><h1 id="延伸阅读与研究路线"><a href="#延伸阅读与研究路线" class="headerlink" title="延伸阅读与研究路线"></a>延伸阅读与研究路线</h1>书<ul><li>《打造第二大脑》Tiago Forte,2022(体系全貌:CODE + PARA + 渐进式总结)</li><li>《The PARA Method》Tiago Forte,2023(纯 PARA 的浓缩小册子)</li><li>《搞定》(GTD)David Allen(对照 Areas/Projects 的源头)</li><li>《卡片笔记写作法》Sönke Ahrens(对照链接派路线)</li></ul>网<ul><li>fortelabs.com/blog — PARA 原始文章 The PARA Method: A Universal System for Organizing Digital Files 及系列</li><li>johnnydecimal.com — 官方入门指南(001–007 编号体系)</li></ul>建议研究顺序<ol><li>CODE 工作流(理解 PARA 在全局中的位置)</li><li>PARA 四类 + 两道分界线(本文第三、四节)</li><li>流动性与回顾机制(第五节,决定系统会不会腐化)</li><li>Johnny Decimal(独立的编号体系,最后叠加)</li></ol><hr><h1 id="附录-CODE-工作流全貌"><a href="#附录-CODE-工作流全貌" class="headerlink" title="附录:CODE 工作流全貌"></a>附录:CODE 工作流全貌</h1>PARA 只负责信息入住的“住址”,而 CODE 是包裹整个第二大脑的完整工作流——从信息进入系统到最终产出成果的四步循环。理解 CODE,才能理解 PARA 为什么长这样。<h2 id="四步总览"><a href="#四步总览" class="headerlink" title="四步总览"></a>四步总览</h2><figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 2 3 4 5 6 7 8 9 10 11 </pre></td><td class="code"><pre>┌──────────────────────────────────────────────────────┐ │ 创造性工作 │ │ │ │ C apture O rganize D istill E xpress │ │ 捕获 → 组织 → 蒸馏 → 表达 │ │ │ │ 记下有共鸣的按可行动性层层提炼用成果 │ │ 外部信息存入 PARA 去芜存菁回馈世界 │ │ │ └──────────────────────────────────────────────────────┘ ↑______________ 产出反哺新的捕获 _______________| </pre></td></tr></table></figure><h2 id="C-Capture-捕获-记下有共鸣的内容"><a href="#C-Capture-捕获-记下有共鸣的内容" class="headerlink" title="C - Capture(捕获):记下有共鸣的内容"></a>C - Capture(捕获):记下有共鸣的内容</h2>做什么:遇到打动你的外部信息——文章、书摘、谈话、灵感——及时记下来,而不是任其流走。核心标准是“共鸣”(resonance)”:不是“这个信息重要吗”,而是“它打动我了吗”。你此刻被触动,说明它与你正在关心的事存在连接;按共鸣捕获,天然过滤掉了 99% 的“听起来很有道理”。<ul><li>三个实用来源清单:它有用(改变你的行动)、有启发(改变你的视角)、有个性(与你产生个人共鸣)</li><li>关键动作:像图书馆员一样收敛——只收藏“为自己以后的读者(自己)服务”的东西,而非什么都囤</li></ul><h2 id="O-Organize-组织-按用途存放-←-PARA-在这里"><a href="#O-Organize-组织-按用途存放-←-PARA-在这里" class="headerlink" title="O - Organize(组织):按用途存放 ← PARA 在这里"></a>O - Organize(组织):按用途存放 ← PARA 在这里</h2>做什么:把捕获的笔记放进 PARA 的对应位置。核心原则:按可行动性组织,而非按主题。同一条信息,放在哪个项目里,取决于它能推进哪个项目——而不是它“属于什么话题”。主题会变,项目是具体的。<ul><li>这是四步中最容易过度设计的地方:PARA 的四分类就是官方给出的极简答案,不要发明第五类</li><li>组织的目的是将来的检索,不是现在的整齐</li></ul><h2 id="D-Distill-蒸馏-层层提炼精华"><a href="#D-Distill-蒸馏-层层提炼精华" class="headerlink" title="D - Distill(蒸馏):层层提炼精华"></a>D - Distill(蒸馏):层层提炼精华</h2>做什么:对已存笔记做渐进式总结(Progressive Summarization)——不重写,只层层加标记:<figure class="highlight text"><table><tr><td class="gutter"><pre>1 2 3 4 </pre></td><td class="code"><pre>第一遍阅读 → 原文(完整保留) 第二遍 → 加粗关键句 ▓▓▓▓ 第三遍 → 高亮加粗中最好的 ███ 第四遍 → 在顶部写执行摘要 📋 </pre></td></tr></table></figure><ul><li>每一层都基于上一层,工作量递减、含金量递增;将来回看时,只读最上层即可决定是否下潜</li><li>核心是“为未来的自己设计”:现在的你觉得重要的,未必是将来的你需要的——层层标记相当于给每层未来的自己留不同的入口</li><li>蒸馏不追求一次完成,而是在每次碰巧重新打开这份笔记时顺手多做一层(机会主义式加工)</li></ul><h2 id="E-Express-表达-产出成果"><a href="#E-Express-表达-产出成果" class="headerlink" title="E - Express(表达):产出成果"></a>E - Express(表达):产出成果</h2>做什么:用第二大脑里的素材,产出面向世界的成果——文章、方案、决策、作品。核心理念:创造即组合。创新很少是无中生有,多数是把已有素材用新方式重新组合;第二大脑的价值最终要在表达中兑现,否则只是囤积。<ul><li>中间产物(Intermediate Packets):把产出拆成可独立交付的小单元(一份分析、一张表格、一个大纲)——既降低启动门槛,又天然可复用到未来场景</li><li>表达的成果会再次进入捕获,形成飞轮</li></ul><h2 id="四步之间的关系"><a href="#四步之间的关系" class="headerlink" title="四步之间的关系"></a>四步之间的关系</h2><table><thead><tr><th>步骤</th><th>关键词</th><th>反模式</th></tr></thead><tbody><tr><td>Capture</td><td>共鸣</td><td>什么都收藏 → 收藏夹腐烂</td></tr><tr><td>Organize</td><td>可行动性</td><td>按主题完美分类 → 整洁但无用</td></tr><tr><td>Distill</td><td>渐进提炼</td><td>一次整理到底 → 累到弃坑</td></tr><tr><td>Express</td><td>组合复用</td><td>只囤不产 → 数字仓鼠</td></tr></tbody></table><ul><li>四步是循环而非流水线:Express 的产出反哺新的 Capture;Distill 贯穿笔记生命周期,而非一次性动作</li><li>常见失败模式:卡在 C/O(不停整理却从不表达)——CODE 的检验标准是 E:一个第二大脑好不好,看你产出了什么,不看你整理得多漂亮</li></ul><h2 id="与-PARA-的关系"><a href="#与-PARA-的关系" class="headerlink" title="与 PARA 的关系"></a>与 PARA 的关系</h2><figure class="highlight text"><table><tr><td class="gutter"><pre>1 2 3 4 5 6 </pre></td><td class="code"><pre>BASB 体系全景 ├── CODE — 工作流(信息怎么流动):捕获→组织→蒸馏→表达 └── PARA — 存储结构(信息住在哪):Projects/Areas/Resources/Archives ↑ └── 只解决 CODE 的 "O" 步骤,但它是全系统的地基: 没有稳定的住址,C/D/E 的产物无处安放 </pre></td></tr></table></figure>

盘了 4986 篇生财文章后，我把 28 个已验证项目画成了一棵决策树

2026-10-23 14:20:00

<blockquote>前言：这篇文章是 <a href="https://blog.diqigan.cn/posts/coding/ai/build-llm-wiki-with-scys-mcp.html">使用生财 MCP 构建 LLM-WIKI</a> 的续篇——当 4,986 篇文章被结构化进 wiki 之后，下一步自然就是：能不能让这些知识直接回答”我该做什么项目”这个问题。于是有了这棵决策树。</blockquote><hr><h2 id="项目宇宙全景（28-个已验证项目）"><a href="#项目宇宙全景（28-个已验证项目）" class="headerlink" title="项目宇宙全景（28 个已验证项目）"></a>项目宇宙全景（28 个已验证项目）</h2><h3 id="内容-流量型（12-个）"><a href="#内容-流量型（12-个）" class="headerlink" title="内容/流量型（12 个）"></a>内容/流量型（12 个）</h3><table><thead><tr><th>#</th><th>项目</th><th>门槛</th><th>时间</th><th>成本</th><th>变现</th><th>收益🟡</th><th>风险</th><th>出处</th></tr></thead><tbody><tr><td>P01</td><td>公众号垂直小号</td><td>低</td><td>30-60min/天</td><td>0</td><td>流量主→商单→私域</td><td>高价值垂类 60-80 元/千阅；中位 3-6 月近零收入</td><td>E1、E4</td><td>公众号调研</td></tr><tr><td>P02</td><td>公众号贴图号</td><td>低</td><td>30min/天</td><td>0</td><td>流量主</td><td>单价 0.68 元/千阅，靠量（日 380 万阅≈2586 元）</td><td>单价低</td><td>manual_10373</td></tr><tr><td>P03</td><td>中老年垂直内容</td><td>低</td><td>30-60min/天</td><td>0</td><td>流量主+赞赏</td><td>5-8 元/千阅；优质号日 200-300 元</td><td>E5 煽情反噬</td><td><code>elderly-content-vertical</code></td></tr><tr><td>P04</td><td>小红书虚拟产品</td><td>低</td><td>碎片</td><td>~30 元</td><td>店铺直成交</td><td>9.9-99 元/品；21 天 SOP</td><td>类目违规（可恢复）</td><td>manual_9623</td></tr><tr><td>P05</td><td>小红书垂直小店</td><td>中</td><td>整块</td><td>数百元</td><td>内容→店铺</td><td>月 5 千-2 万</td><td>F5 竞烈、退货</td><td><code>vertical-niche-store</code></td></tr><tr><td>P06</td><td>抖音自然流 CPS</td><td>中</td><td>日 1-2h</td><td>0</td><td>挂链佣金</td><td>月几千-几万（20 条测试法）</td><td>E4 衰减快</td><td>manual_10372</td></tr><tr><td>P07</td><td>B站好物带货</td><td>中</td><td>2-4h/视频</td><td>0</td><td>CPS+商单</td><td>中尾稳定佣金；头部单条广告 3.5 万</td><td>D2 窗口即逝</td><td>superb_07</td></tr><tr><td>P08</td><td>YouTube AI 视频</td><td>中</td><td>整块</td><td>≤200 元/月</td><td>YPP 分成</td><td>普通人月 $100-1000</td><td>版权、YPP 门槛</td><td>superb_02</td></tr><tr><td>P09</td><td>YouTube 直播</td><td>中</td><td>固定档期</td><td>低</td><td>YPP+打赏</td><td>起量快</td><td>账号脆弱</td><td><code>youtube-live-ypp-playbook</code></td></tr><tr><td>P10</td><td>AI 自媒体接商单</td><td>中</td><td>日更</td><td>0</td><td>商单（粉数万→单条 8000）</td><td>月 1-10 万（头部）</td><td>E8 AIGC 限流</td><td>superb_01</td></tr><tr><td>P11</td><td>AI 图片号（GPT-4o）</td><td>低-中</td><td>可切块</td><td>API 费</td><td>广告/商单/服务</td><td>单月数万美金案例</td><td>D3 一次性窗口</td><td>superb_06</td></tr><tr><td>P12</td><td>X 涨粉+App 拉新</td><td>中</td><td>日 1h</td><td>0</td><td>拉新奖励</td><td>低粉即可启动；月几百-几千美金</td><td>结算规则变</td><td><code>x-tg-community-funnel</code></td></tr></tbody></table><h3 id="服务-交付型（8-个）"><a href="#服务-交付型（8-个）" class="headerlink" title="服务/交付型（8 个）"></a>服务/交付型（8 个）</h3><table><thead><tr><th>#</th><th>项目</th><th>门槛</th><th>时间</th><th>成本</th><th>变现</th><th>收益🟡</th><th>风险</th><th>出处</th></tr></thead><tbody><tr><td>P13</td><td>AI 服务接单（闲鱼/Fiverr）</td><td>低</td><td>碎片</td><td>0</td><td>接单即收钱，链路最短</td><td>单笔几十-几百，高频年入数万+</td><td>F4 吃人力</td><td>superb_05</td></tr><tr><td>P14</td><td>AI PPT/文档生产</td><td>低-中</td><td>碎片</td><td>0</td><td>接单/模板</td><td>中</td><td>同上</td><td><code>ppt-ai-production-pipeline</code></td></tr><tr><td>P15</td><td>论文数据分析</td><td>中</td><td>整块</td><td>0</td><td>按单交付</td><td>清风累计 20W+</td><td>学术合规灰区</td><td><code>paper-data-analysis-side-hustle</code></td></tr><tr><td>P16</td><td>AI 工作流定制（99 元样品→B 端）</td><td>中</td><td>整块</td><td>0</td><td>定制</td><td>几千-几十万/单（李香君 2000→十几万）</td><td>F4 人力密集</td><td>superb_12</td></tr><tr><td>P17</td><td>企业 AI 服务/FDE</td><td>高</td><td>全职型</td><td>0</td><td>首单靠熟人/公开输出</td><td>单笔 1-50 万</td><td>销售周期长</td><td><code>enterprise-ai-individual-entry-paths</code></td></tr><tr><td>P18</td><td>GEO 服务（按结果收费）</td><td>高</td><td>整块</td><td>0</td><td>B2B</td><td>新兴溢价高</td><td>未标准化</td><td><code>geo</code></td></tr><tr><td>P19</td><td>知识付费社群/训练营</td><td>中</td><td>日程化</td><td>0</td><td>低价→阶梯升级</td><td>月 5 位数（需强信任）</td><td>口碑反噬</td><td><code>training-camp-seven-step-delivery</code></td></tr><tr><td>P20</td><td>专家 IP+私域高客单</td><td>中</td><td>日更+私域</td><td>0</td><td>客单 4980-7980</td><td>礼飞 1.1 万粉变现 200 万</td><td>起号慢</td><td><code>expert-ip-niche-positioning</code></td></tr></tbody></table><h3 id="产品-资产型（8-个）"><a href="#产品-资产型（8-个）" class="headerlink" title="产品/资产型（8 个）"></a>产品/资产型（8 个）</h3><table><thead><tr><th>#</th><th>项目</th><th>门槛</th><th>时间</th><th>成本</th><th>变现</th><th>收益🟡</th><th>风险</th><th>出处</th></tr></thead><tbody><tr><td>P21</td><td>iOS/海外订阅 App</td><td>高（AI 编程 240h 达标）</td><td>副业可</td><td>开发者账号</td><td>订阅</td><td>月 $1000/App=PMF，两 App≈1W</td><td>审核、获客</td><td>superb_03/04</td></tr><tr><td>P22</td><td>AI SaaS 工具站出海</td><td>高</td><td>副业可</td><td>域名+服务器</td><td>订阅</td><td>亿豪 3 月首批订单</td><td>SEO 慢</td><td><code>seo-tdh</code></td></tr><tr><td>P23</td><td>微信工具小程序矩阵</td><td>中</td><td>副业可</td><td>~30 元/个</td><td>流量主广告</td><td>曦哥 15 个中 7 个月入 2 万+</td><td>单个天花板低</td><td>航海 10105</td></tr><tr><td>P24</td><td>出海游戏热词站</td><td>中</td><td>可批量</td><td>域名</td><td>Adsterra→AdSense</td><td>几毛/天（练兵场）</td><td>纯练手</td><td>manual_10092</td></tr><tr><td>P25</td><td>垂直导航站</td><td>中</td><td>副业可</td><td>低</td><td>首页卡位广告</td><td>卡位费被动收入</td><td>流量获取</td><td><code>navigation-site-ad-slot-monetization</code></td></tr><tr><td>P26</td><td>AI API 中转站生态</td><td>高</td><td>整块</td><td>服务器</td><td>差价/广告</td><td>生态位机会</td><td>合规灰区</td><td><code>ai-api-relay-station-ecosystem</code></td></tr><tr><td>P27</td><td>付费 MCP/数据订阅</td><td>高</td><td>副业可</td><td>数据成本</td><td>订阅/调用</td><td>Refero $17/月起</td><td>需四阶段验证</td><td>superb_17</td></tr><tr><td>P28</td><td>一件代发</td><td>低-中</td><td>碎片+客服</td><td>首单货款</td><td>差价</td><td>练兵场（验证选品与成交）</td><td>客服/退货</td><td><code>dropshipping-first-order</code></td></tr></tbody></table><h3 id="高危-受限（不设叶子）"><a href="#高危-受限（不设叶子）" class="headerlink" title="高危/受限（不设叶子）"></a>高危/受限（不设叶子）</h3><ul><li>AI 矩阵批量起号：2026-03-27 微信”非真人自动化创作”红线后，全自动托管=封号；官方上限 3-6 号真人运营，仅允许此扩容形态（F6）。</li><li>洗稿、标题党、批量 RPA 代发：Q0 门直接排除。</li></ul><h3 id="跨项目规律"><a href="#跨项目规律" class="headerlink" title="跨项目规律"></a>跨项目规律</h3><ol><li>技能三档定分支：无背景→内容/轻服务（P01-P06, P13, P28）；有行业知识→专家服务（P16-P20）；有技术→产品型（P21-P27）。</li><li>快慢二分：服务/虚拟产品=现金快但吃人力；订阅/数据=3-6 月零收入但自动化。</li><li>国内/海外二分：海外（P08/09/12/21/22/24/27）单价高、结算稳、需英文；国内链路短、规则多变。</li><li>人群画像 > 赛道名：中老年/财经/家长垂类单价差 10-100 倍。</li><li>平台窗口易逝：P07、P11 属窗口型”错过不再”；产品型以年计。</li></ol><hr><h2 id="决策树"><a href="#决策树" class="headerlink" title="决策树"></a>决策树</h2><pre><code class="mermaid">flowchart TD START([开始选项目]) --> Q0{"Q0 合规门 依赖全自动托管/批量矩阵/洗稿？(E1) AI声明/版权/税务有硬伤？(E2)"} Q0 -->|是| X0[❌ 排除。换玩法不换能力] Q0 -->|否| Q1{"Q1 技能存量(A1) 能编程/熟练用AI编程？"} Q1 -->|能| QTECH{"全职还是副业？(A4)"} Q1 -->|不能但有行业知识| QEXP Q1 -->|两者皆无| QZERO %% 技术分支 QTECH -->|副业·可接受3-6月零收入| QTP{"国内还是海外？(B4·C3)"} QTP -->|海外·订阅产品| L21["P21 iOS订阅App·月$1000=PMF"] QTP -->|海外·工具站| L22["P22 AI SaaS出海·SEO 3月首单"] QTP -->|海外·数据资产| L27["P27 付费MCP/数据订阅·四阶段验证"] QTP -->|国内·广告分成| L23["P23 小程序矩阵·30元验证单品"] QTP -->|国内·练手| L24["P24 游戏热词站·先跑流程"] QTECH -->|全职/需快现金| QTS{"快现金还是高客单？"} QTS -->|快现金·海外| L16a["P13+ n8n/AI海外接单·吃人力"] QTS -->|高客单·B端| L16["P16 B端工作流定制→P17 FDE"] QTS -->|建站生态| L26["P26 AI API中转站·合规自查先行"] %% 专家分支 QEXP{"强IP慢资产还是快交付？(C3·C7)"} QEXP -->|慢·强IP+私域| L20["P20 专家IP·客单4980-7980"] QEXP -->|快·垂直交付| QE2{"C端还是B端？(B5)"} QE2 -->|C端| L19["P19 训练营·低价起步阶梯升级"] QE2 -->|B端| QE3{"技术交付还是咨询？"} QE3 -->|能搭工作流| L16 QE3 -->|懂行懂沟通| L17["P17 企业AI服务/FDE·首单靠熟人+公开输出"] QE3 -->|懂搜索技术| L18["P18 GEO·按结果收费"] %% 零基础分支 QZERO{"Q2 时间结构 碎片(<1h)还是整块？(A3)"} QZERO -->|碎片| Q2a{"愿做内容还是纯交付？"} Q2a -->|内容·手机可操作| L02["P02 贴图号 / P03 中老年号·每天30分钟"] Q2a -->|纯交付·不露面| L04["P04 小红书虚拟产品·30元+2天验证"] QZERO -->|整块| Q3{"全职还是副业？(A4)"} Q3 -->|副业| Q3a{"要快现金流吗？(C3)"} Q3a -->|要快| L13["P13 AI接单·0门槛0成本"] Q3a -->|可慢| Q3b{"内容流量还是电商？(B4)"} Q3b -->|内容| L01["P01 垂直小号·高价值画像·90篇止损线"] Q3b -->|电商| L28["P28 一件代发→P05 垂直小店"] Q3 -->|全职| Q4{"目标量级？(C2)"} Q4 -->|月5千-2万| Q4b{"国内还是海外？"} Q4b -->|国内| L05["P05 小红书深耕·21天SOP"] Q4b -->|海外·愿做视频| L08["P08 YouTube AI视频"] Q4 -->|年入几十万+| Q4a{"愿真人出镜/主导？(A6)"} Q4a -->|愿意| Q4c{"视频还是图文？"} Q4c -->|视频| L067["P06 抖音CPS→P07 B站好物"] Q4c -->|图文| L10["P10 AI自媒体商单·单条8000"] Q4a -->|不愿·愿直播| L09["P09 YT直播快开YPP"] Q4a -->|不愿·纯线上英文| L12["P12 X拉新·TG三段式"] Q4 -->|有学术/统计背景| L15["P15 论文数据分析·清风20W+"] %% 汇聚门 L21 & L22 & L27 & L23 & L24 & L16a & L16 & L26 & L20 & L19 & L17 & L18 & L02 & L04 & L13 & L01 & L28 & L05 & L08 & L067 & L10 & L09 & L12 & L15 --> Q5 Q5{"Q5 时机门 有赚钱案例吗？白热化了吗？(D1)"} Q5 -->|无案例| X5[⏸ 等案例或30元小注试探] Q5 -->|案例现+未白热化| Q6{"Q6 有SOP/可复盘案例吗？(F1)"} Q5 -->|红海| X5b[🔄 换极致垂直细分或降维打法] Q6 -->|无| X6[⏸ 补齐SOP再启动·禁止推陈出新] Q6 -->|有| Q7{"Q7 与主业/已有项目冲突？(F7)"} Q7 -->|冲突| X7[⚠ 双账号区隔/砍旧/错峰] Q7 -->|兼容| GO(["✅ 启动：90篇/3月止损线(F2) →≤30元≤2天最小闭环(F3)→单变量迭代"]) classDef leaf fill:#e8f5e9,stroke:#4caf50 classDef dead fill:#ffebee,stroke:#f44336 classDef wait fill:#fff3e0,stroke:#ff9800 class L21,L22,L27,L23,L24,L16a,L16,L26,L20,L19,L17,L18,L02,L04,L13,L01,L28,L05,L08,L067,L10,L09,L12,L15 leaf class X0,X5,X5b dead class X6,X7 wait</code></pre><h2 id="快速路径表（不想读图直接查表）"><a href="#快速路径表（不想读图直接查表）" class="headerlink" title="快速路径表（不想读图直接查表）"></a>快速路径表（不想读图直接查表）</h2>下表是 §二决策树同一逻辑的速查版：按你的情况直接查推荐项目和首个验证动作。<table><thead><tr><th>你的情况</th><th>推荐</th><th>首个验证动作</th></tr></thead><tbody><tr><td>会编程·副业·要自动化</td><td>P21 / P22</td><td>2 周 MVP 看转化</td></tr><tr><td>会编程·全职·要快钱</td><td>P13 海外接单</td><td>挂样品 48h 接首单</td></tr><tr><td>会编程·长期 B 端</td><td>P16→P17</td><td>免费帮身边老板做一套工作流</td></tr><tr><td>懂行业·愿做 IP</td><td>P20</td><td>30 天日更+1 个免费咨询案例</td></tr><tr><td>懂行业·只想交付</td><td>P19 / P16</td><td>99 元样品卖 10 份</td></tr><tr><td>零基础·碎片·愿做内容</td><td>P02 / P03</td><td>7 天 7 篇看推荐量</td></tr><tr><td>零基础·碎片·不露面</td><td>P04</td><td>30 元+2 天上架 1 个已验证品</td></tr><tr><td>零基础·整块·副业快钱</td><td>P13 闲鱼</td><td>挂 3 个 AI 服务链接</td></tr><tr><td>零基础·整块·副业可慢</td><td>P01</td><td>高价值赛道+90 篇止损线</td></tr><tr><td>零基础·整块·偏电商</td><td>P28→P05</td><td>首单跑通发货链路</td></tr><tr><td>零基础·全职·月入过万档</td><td>P05 / P08</td><td>21 天 SOP 走一轮</td></tr><tr><td>零基础·全职·出镜·冲大</td><td>P06→P07</td><td>20 条视频测试法</td></tr><tr><td>零基础·全职·不出镜英文</td><td>P12 / P09</td><td>0 粉 30 天日更</td></tr></tbody></table><h2 id="树节点的因子溯源（审计用）"><a href="#树节点的因子溯源（审计用）" class="headerlink" title="树节点的因子溯源（审计用）"></a>树节点的因子溯源（审计用）</h2>决策树不是拍脑袋画的：每个节点对应附录中的一个选型因子，每个因子有库内依据。本表供审计与后续改树时回溯；普通读者可跳过。<table><thead><tr><th>节点</th><th>因子</th><th>依据</th></tr></thead><tbody><tr><td>Q0</td><td>E1/E2</td><td>公众号调研 §8</td></tr><tr><td>Q1</td><td>A1（240h 门槛）</td><td>superb_03</td></tr><tr><td>Q1t/Q3</td><td>A4</td><td>exploration</td></tr><tr><td>Q1p</td><td>B4</td><td><code>overseas-product-strategy</code></td></tr><tr><td>Q1s/Q3a</td><td>C2/C3</td><td><code>low-ticket-sample-to-enterprise-funnel</code></td></tr><tr><td>Q1e</td><td>C3/C7</td><td><code>expert-ip-niche-positioning</code></td></tr><tr><td>Q1e2</td><td>B5</td><td>superb_12</td></tr><tr><td>Q2</td><td>A3</td><td><code>life-embedded-project-selection</code></td></tr><tr><td>Q2a</td><td>A5/A6</td><td>§8.2 真人含量</td></tr><tr><td>Q4a</td><td>A6</td><td>公众号调研 §8.2</td></tr><tr><td>Q5</td><td>D1（+D2/D3）</td><td><code>second-wave-entry-timing</code></td></tr><tr><td>Q6</td><td>F1</td><td>manual_9623</td></tr><tr><td>Q7</td><td>F7</td><td><code>dual-account-positioning</code>、3-6 号上限</td></tr><tr><td>GO</td><td>F2/F3</td><td>§9.2、<code>virtual-product-low-cost-mvp</code></td></tr></tbody></table>未入树因子：B1/B2（启动成本 ≤ 数百元，仅标注全景表）；B3/B5（进入升级路径）；C4-C8、D2-D6、E3-E6、F4-F6（进入 §六执行前清单，即下方流程）。<hr>以下三章是选定叶子后的操作流程：§五升级路径（0→1 跑通后怎么放大）→ §六执行前清单（启动前逐项过一遍）→ §七试验与复盘门（启动后 4 周一循环）。<h2 id="叶子升级路径（0→1-之后）"><a href="#叶子升级路径（0→1-之后）" class="headerlink" title="叶子升级路径（0→1 之后）"></a>叶子升级路径（0→1 之后）</h2><figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 2 3 4 5 6 7 8 </pre></td><td class="code"><pre>P01/P02/P03 ─500粉→流量主→商单→私域高客单(接P20) P04 ─单店跑通→多SKU复制→时间窗产品组合 P05/P28 ─单品验证→垂直店矩阵→付费投流放大 P06/P07/P08 ─单号跑通→3-6号真人矩阵→1强IP+后端产品 P13 ─99元样品→B端定制(P16→P17)→工作室 P23 ─单品验证→矩阵复制→订阅/数据资产(接P27) P21/P22 ─月$1000(PMF)→复制第二产品→P27 P12 ─低粉跑通→多平台拉新→X→私域漏斗 </pre></td></tr></table></figure><blockquote>每次升级=新增项目，须重过 Q7。</blockquote><h2 id="执行前校验清单（叶子选定后、启动前过一遍）"><a href="#执行前校验清单（叶子选定后、启动前过一遍）" class="headerlink" title="执行前校验清单（叶子选定后、启动前过一遍）"></a>执行前校验清单（叶子选定后、启动前过一遍）</h2><ul><li><input disabled="" type="checkbox"> C4 变现模式：现成模式优先，需自己发明商业化的降权</li><li><input disabled="" type="checkbox"> C5 单位经济：按保守单价算所需流量（公众号基准 1-5 元/千阅🟡）</li><li><input disabled="" type="checkbox"> C7 资产沉淀：纯易耗号降权</li><li><input disabled="" type="checkbox"> C8 可复制性：有榜单/SOP/可复盘案例吗</li><li><input disabled="" type="checkbox"> D2/D3/D5 窗口：平台容忍期？成本剧变？季节节点 <30 天降预期</li><li><input disabled="" type="checkbox"> E3/E4/E6：单账号依赖？玩法寿命（洗稿~3 月/内容 3-6 月/产品以年计）？</li><li><input disabled="" type="checkbox"> E5 幸存者偏差：用底层样本锚定下界（星河 11 次航海、40 天 33 元）</li><li><input disabled="" type="checkbox"> F4 人力密度：不接受靠人力赚钱只选产品型</li><li><input disabled="" type="checkbox"> F5 竞争烈度：能否切到品类×人群×场景极致垂直</li><li><input disabled="" type="checkbox"> F6 扩容上限：受平台规则约束吗（3-6 号上限）</li><li><input disabled="" type="checkbox"> F2 止损线：”第 X 篇/月未达 Y 即停”，日历化</li><li><input disabled="" type="checkbox"> F3 最小闭环：≤30 元+≤2 天</li><li><input disabled="" type="checkbox"> 两问：①最该验证的假设是什么？②停止条件是什么？（失败案例共同点=没设停止条件）</li><li><input disabled="" type="checkbox"> 时薪核算：全部工时计入（抖音 CPS、直播、知识付费是时间账陷阱高发区）</li><li><input disabled="" type="checkbox"> 现金缺口：垫资/回款 >30 天的项目按月测算，不动生活资金</li></ul><h2 id="试验设计与复盘门（启动后-4-周一循环）"><a href="#试验设计与复盘门（启动后-4-周一循环）" class="headerlink" title="试验设计与复盘门（启动后 4 周一循环）"></a>试验设计与复盘门（启动后 4 周一循环）</h2>每项目用 4 周有限试验，事前写下：验证目标=真实付款（非点赞阅读）；上限=月可支配收入 10% + 每周 10 小时；量化成功标准；复查日期日历化。E5 幸存者偏差三条硬规则：<ol><li>收益预期取中位数而非头部案例，以底层样本（星河 11 次航海、40 天 33 元）为下界锚点。</li><li>4 周试验的成功标准须用自己实测数据校准一次（如实际千阅单价），不得全程沿用宣传案例数字。</li><li>见”月入 X 万”案例必问：中位数参与者 3 个月时赚多少？答不出→按近零收入做规划。</li></ol>Q5 时机回访：每次 4 周复盘顺带重答 Q5（案例变多？竞争白热化？）；窗口型项目（P07/P11/P24）缩至每月；平台新规/头部撤退新闻出现时立即重评（E1/E6）。结束后三选一（三笔账：现金账=垫资与现金缺口、时间账=全部工时折时薪、机会账=主业/其他叶子的机会成本）：<table><thead><tr><th>结果</th><th>动作</th></tr></thead><tbody><tr><td>达标 → 继续</td><td>加投入前重算三笔账</td></tr><tr><td>有客户但定价/效率有问题 → 调整</td><td>只改一个变量再测</td></tr><tr><td>不达标 → 停止</td><td>沉没成本不算理由，换叶子重过 Q5-Q7</td></tr></tbody></table><h2 id="树的边界"><a href="#树的边界" class="headerlink" title="树的边界"></a>树的边界</h2><ol><li>只覆盖复制型决策；库内无先例的发明型项目需另过需求验证门。</li><li>时机为快照：Q5 判定 3-6 个月回访；平台规则执行前核对。</li><li>单人视角；有团队时 B5、F6 重新加权。</li><li>高危玩法不设叶子（§1.4）。</li></ol><hr><h1 id="附录：项目选型影响因素（6-大类-25-项）"><a href="#附录：项目选型影响因素（6-大类-25-项）" class="headerlink" title="附录：项目选型影响因素（6 大类 25 项）"></a>附录：项目选型影响因素（6 大类 25 项）</h1><blockquote>决策树的本质=用最少问题收敛到唯一解。每类按树中位置标注：根／中间／叶子。</blockquote><figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 2 </pre></td><td class="code"><pre>A. 个人禀赋（我是谁） B. 资源约束（我有什么） C. 收益结构（能赚多少） D. 时机窗口（现在能不能做） E. 风险合规（会不会死） F. 执行匹配（做不做得下去） </pre></td></tr></table></figure><h2 id="A-个人禀赋（根节点，区分度最大）"><a href="#A-个人禀赋（根节点，区分度最大）" class="headerlink" title="A. 个人禀赋（根节点，区分度最大）"></a>A. 个人禀赋（根节点，区分度最大）</h2><table><thead><tr><th>#</th><th>因素</th><th>关键问题</th><th>依据</th></tr></thead><tbody><tr><td>A1</td><td>技能存量</td><td>有无可复用技能（编程/设计/写作/行业知识）？技术→产品型；行业专业→专家IP；无→内容/服务</td><td>exploration、<code>project-pivot-from-strengths</code></td></tr><tr><td>A2</td><td>优势连续性</td><td>能否从老业务长出新项目？盲目换赛道=高失败路径</td><td><code>skill-chain</code></td></tr><tr><td>A3</td><td>时间结构</td><td>碎片还是整块？碎片→可切块轻链路（贴图号 vs 长文），连续投入型对在职者不可持续</td><td><code>life-embedded-project-selection</code></td></tr><tr><td>A4</td><td>全职/副业</td><td>副业→现金流过渡型；主业→长期资产型</td><td><code>low-cost-entrepreneurship</code></td></tr><tr><td>A5</td><td>兴趣驱动</td><td>能对赛道乐此不疲吗？</td><td><code>interest-driven-monetization</code></td></tr><tr><td>A6</td><td>真人含量</td><td>愿真人出镜/主导吗？（红线后全自动=封号）</td><td>公众号调研 §8.2</td></tr></tbody></table><h2 id="B-资源约束（第二层）"><a href="#B-资源约束（第二层）" class="headerlink" title="B. 资源约束（第二层）"></a>B. 资源约束（第二层）</h2><table><thead><tr><th>#</th><th>因子</th><th>关键问题</th><th>依据</th></tr></thead><tbody><tr><td>B1</td><td>启动资金</td><td>试错预算多少？低成本=多次试错空间</td><td><code>low-cost-entrepreneurship</code></td></tr><tr><td>B2</td><td>试错次数</td><td>预算撑几次失败？高投入一次失败即出局</td><td>同上</td></tr><tr><td>B3</td><td>现有流量/私域</td><td>有粉/社群/客户名单→直接做高客单后端</td><td>礼飞案例</td></tr><tr><td>B4</td><td>AI 工具能力</td><td>会 AI 编程→成本 1/10；单项 AI 技能→接单</td><td><code>ai-three-layer-capability</code></td></tr><tr><td>B5</td><td>渠道/供应链</td><td>有行业资源→B 端高客单路径</td><td><code>ai-last-mile-delivery</code></td></tr></tbody></table><h2 id="C-收益结构（中间节点）"><a href="#C-收益结构（中间节点）" class="headerlink" title="C. 收益结构（中间节点）"></a>C. 收益结构（中间节点）</h2><table><thead><tr><th>#</th><th>因子</th><th>关键问题</th><th>依据</th></tr></thead><tbody><tr><td>C1</td><td>市场空间</td><td>能容纳几百上千人？</td><td><code>project-selection-criteria</code></td></tr><tr><td>C2</td><td>赚钱上限</td><td>头部量级决定值不值得 All-in</td><td>同上</td></tr><tr><td>C3</td><td>变现链路</td><td>服务快现金吃人力；产品自动化但 3-6 月起量。“服务 vs 产品”核心分叉</td><td>exploration</td></tr><tr><td>C4</td><td>变现模式复杂度</td><td>需自己设计商业化→降权</td><td>同上</td></tr><tr><td>C5</td><td>单位经济</td><td>高价值垂类 5-80 元/千阅；画像比赛道名重要 10-20 倍</td><td>公众号调研 §2.1</td></tr><tr><td>C6</td><td>收益曲线</td><td>内容型=冷启动零收入→爆文 10-100x 跃迁→衰减；产品型=爬坡复利</td><td>§3、<code>website-growth-five-stages</code></td></tr><tr><td>C7</td><td>资产沉淀</td><td>做完能留下什么？纯流量号是易耗品</td><td><code>account-as-consumable-mindset</code></td></tr><tr><td>C8</td><td>可复制性</td><td>有公开 SOP、240h 内达商用？</td><td><code>project-selection-criteria</code></td></tr></tbody></table><h2 id="D-时机与窗口（中间节点）"><a href="#D-时机与窗口（中间节点）" class="headerlink" title="D. 时机与窗口（中间节点）"></a>D. 时机与窗口（中间节点）</h2><table><thead><tr><th>#</th><th>因子</th><th>关键问题</th><th>依据</th></tr></thead><tbody><tr><td>D1</td><td>验证-竞争象限</td><td>蛮荒期=案例现+可复盘+机构未入场，第二批入场风险最低收益最大</td><td><code>second-wave-entry-timing</code></td></tr><tr><td>D2</td><td>平台商业化窗口</td><td>导流容忍期结束即窗口关闭（B站好物）</td><td><code>platform-commercialization-window</code></td></tr><tr><td>D3</td><td>成本剧变</td><td>成本压到 1/10~1/100=价值链重写（AI 生图）</td><td><code>ai-image-cost-revolution</code></td></tr><tr><td>D4</td><td>趋势叠加</td><td>多趋势叠加>单一红利</td><td><code>overseas-product-strategy</code></td></tr><tr><td>D5</td><td>季节节点</td><td>错过节点=等一年</td><td><code>time-window-product-strategy</code></td></tr><tr><td>D6</td><td>范式迁移</td><td>老机会在新平台重现（知乎好物 2020→B站 2025）</td><td><code>project-selection-criteria</code></td></tr></tbody></table><h2 id="E-风险与合规（一票否决门）"><a href="#E-风险与合规（一票否决门）" class="headerlink" title="E. 风险与合规（一票否决门）"></a>E. 风险与合规（一票否决门）</h2><table><thead><tr><th>#</th><th>因子</th><th>关键问题</th><th>依据</th></tr></thead><tbody><tr><td>E1</td><td>平台红线</td><td>依赖将被封杀的玩法？（2026-03-27 微信非真人红线；爆了么 AI 5000+ 号被清退）</td><td>§8.2</td></tr><tr><td>E2</td><td>法律义务</td><td>AI 标识/版权/税务硬伤？</td><td>§8.1/8.4</td></tr><tr><td>E3</td><td>账号脆弱性</td><td>收入系于单一可回收账号？处罚梯级：限流→删文→限权→封号</td><td>§4.3</td></tr><tr><td>E4</td><td>生命周期</td><td>洗稿 ~3 月；不做衰减预警=最大死因</td><td>§9.1</td></tr><tr><td>E5</td><td>幸存者偏差</td><td>“月入 5 位数”中位=3-6 月近零收入</td><td>§2.3</td></tr><tr><td>E6</td><td>平台依赖</td><td>单平台规则一变即归零（老布两年 30 万后流量归零退场）</td><td>§9.1</td></tr></tbody></table><h2 id="F-执行与匹配（叶子节点）"><a href="#F-执行与匹配（叶子节点）" class="headerlink" title="F. 执行与匹配（叶子节点）"></a>F. 执行与匹配（叶子节点）</h2><table><thead><tr><th>#</th><th>因子</th><th>关键问题</th><th>依据</th></tr></thead><tbody><tr><td>F1</td><td>SOP 可得性</td><td>有手册照抄吗？禁止推陈出新</td><td>manual_9623</td></tr><tr><td>F2</td><td>止损线</td><td>能否预定义”何时放弃”？（如 90 篇/3 个月）</td><td>§9.2</td></tr><tr><td>F3</td><td>验证成本</td><td>最小闭环 ≤30 元+2 天？</td><td><code>virtual-product-low-cost-mvp</code></td></tr><tr><td>F4</td><td>人力密度</td><td>靠产品杠杆还是人力交付？</td><td><code>low-ticket-sample-to-enterprise-funnel</code></td></tr><tr><td>F5</td><td>竞争烈度</td><td>蓝海/蛮荒/红海？极致垂直=差异化（切袜子/圣诞场景即可）</td><td><code>vertical-niche-store</code></td></tr><tr><td>F6</td><td>可扩容性</td><td>3-6 号上限；再往上做 1 强 IP+后端</td><td>manual_10374</td></tr><tr><td>F7</td><td>组合兼容性</td><td>与主业/已有项目冲突？双账号区隔</td><td><code>dual-account-positioning</code></td></tr></tbody></table><h2 id="G-类复核结论（审计记录）"><a href="#G-类复核结论（审计记录）" class="headerlink" title="G 类复核结论（审计记录）"></a>G 类复核结论（审计记录）</h2>外部框架补充的 G 类 8 项经逐项审判：仅 G7 组合兼容性保留（归入 F7）；G2 并入 C3、G4 降为 C3 注脚；G1/G3/G5/G6/G8 删除——因生财范式是”复制已验证业务”，需求真伪、护城河、可逆性已被先行者回答或由低成本哲学（B1/B2）覆盖。这正是复制型决策树与发明型决策树的差异：合规门→我是谁→选已验证赛道→时机→执行，而非需求验证→分发→护城河。<h2 id="硬规则（可直接编码为树边）"><a href="#硬规则（可直接编码为树边）" class="headerlink" title="硬规则（可直接编码为树边）"></a>硬规则（可直接编码为树边）</h2><ol><li>服务/产品二分：0 基础+要快钱→AI 接单（闲鱼/Fiverr）；有技术+要自动化→产品型（订阅 App/SaaS）。</li><li>时间规则：碎片化→只选可切块+留资产的轻链路，与收益上限无关。</li><li>第二批入场：无案例→等或小注试探；案例现+未白热化→加投入。</li><li>画像>赛道名：选高广告价值人群，单价差 10-20 倍。</li><li>垂直深耕：有行业认知→垂直场景+最后一公里，客单差百倍。</li><li>优势生长：优先从老业务长出新项目。</li><li>变现简化：需自己发明商业化→降权。</li></ol><h2 id="建树规则（已定案）"><a href="#建树规则（已定案）" class="headerlink" title="建树规则（已定案）"></a>建树规则（已定案）</h2><ol><li>节点分叉：互斥分叉为主（通常二分），允许 Q1/Q5 式互斥多叉；禁止高/中/低式模糊中间档。</li><li>权重：A 类作根节点；超级标四维不做初筛——C1 并入 Q5 隐含条件（蛮荒期即隐含空间存在），C2 保留为 Q4 量级门（个人目标—赛道匹配校验，非赛道筛选）。</li></ol><hr><h1 id="后记"><a href="#后记" class="headerlink" title="后记"></a>后记</h1>从 <a href="https://blog.diqigan.cn/posts/coding/ai/build-llm-wiki-with-scys-mcp.html">把生财文章库建成 LLM wiki</a>，到这棵 28 项目的决策树，中间隔的其实是同一个问题的两步：先让知识”可检索”，再让知识”可决策”。wiki 负责第一步——4,986 篇 summaries、331 个 concepts、223 期航海手册被压缩成可引用的因子库；决策树负责第二步——把 25 个因子编排成 7 道门，从”我是谁”走到”启动或放弃”。树是快照，wiki 是活水。后续库内新案例入池时，Q5 时机门和收益中位数都应重算——这也是把它建在 wiki 之上，而不是写成一篇静态文章的原因。

我做了一个浏览器扩展：把网页生词一键收进「不背单词」

2026-10-14 10:00:00

<h2 id="起因：一个很小的烦恼"><a href="#起因：一个很小的烦恼" class="headerlink" title="起因：一个很小的烦恼"></a>起因：一个很小的烦恼</h2>我平时看技术文档、英文博客、Wikipedia，经常会卡在一些不认识的单词上。频率不高，但足够烦人——每次遇到，都得中断阅读，切到词典查一下，再想想「这词要不要记下来」。真要记的话，路径更长：打开背单词 App，手动搜索，手动加进生词本。一个词点五六下，读一篇文档遇到十个生词，光录入就十几分钟过去了。也试过现成的单词本，但它们和「我当下正在读的这篇网页」是脱节的。词书按主题或考试划分，而我读的是 Github Readme、某个库的 RFC、英文论文——这些页面里的词汇分布，任何一本预制词书都覆盖不好。我真正想要的其实很简单：看到一篇英文文章，把它里面的生词一次性收集出来，直接进我正在用的背单词 App 的生词本。 这样背的词就是我这周真实读到的词，针对性拉满。背单词 App 我用的是「不背单词」（bbdc.cn），所以就围绕它做。工具的名字叫「单词雷达 WordRadar」——雷达扫一遍页面，生词就现形了。<h2 id="功能介绍：极致简约"><a href="#功能介绍：极致简约" class="headerlink" title="功能介绍：极致简约"></a>功能介绍：极致简约</h2><ul><li>一键添加网页单词到「不背单词」 最近高频接触各种各样的开源项目和 SKILLs，每天都要直面开源项目文档和 SKILL 介绍等各种英文单词。屡屡查词不如一次背词，索性直接全部添加到生词本，背完便能无障碍阅读原文。 点一下扩展图标、再点一下「采集当前页」，扩展就把正文里的英文单词全部提取出来，和本地词库对比，弹窗告诉你：本次采集了 N 个单词，其中 M 个是新词。如果不想添加整页单词到生词本，也可以只处理选中文本。</li><li>词形还原与去重 采集不是把页面上所有英文词都抓下来完事：先做归一化（所有格剥离，<code>dog's</code> 算 <code>dog</code>；大小写折叠，全大写的 <code>THE</code> 归到 <code>the</code>），再做词形还原（<code>cameras</code> 归到 <code>camera</code>，<code>went</code> 归到 <code>go</code>），按词元去重，过滤缩略词和缩合形式。所以 <code>lived</code>、<code>living</code>、<code>lives</code> 不会以三个词条的面目重复出现在你面前。</li><li>本地上传 硬盘里的英文笔记、字幕文件，直接在扩展里上传 <code>.txt</code> / <code>.md</code> 采集，走同一个推送流程。</li><li>安装便捷 Chrome / Edge 商店直接装，随版本发布自动更新，不用自己下载源码编译。装好之后打开 bbdc.cn 登录一次，就能开始用。</li></ul><img data-src="https://static.diqigan.cn/seven/2026/c0d5abb24ec4ec385fd470433922b18a.png" alt="采集确认页面"><h2 id="开发历程：从「能不能打通」到「敢不敢上架」"><a href="#开发历程：从「能不能打通」到「敢不敢上架」" class="headerlink" title="开发历程：从「能不能打通」到「敢不敢上架」"></a>开发历程：从「能不能打通」到「敢不敢上架」</h2><h3 id="第一步：先解决「最后一公里」"><a href="#第一步：先解决「最后一公里」" class="headerlink" title="第一步：先解决「最后一公里」"></a>第一步：先解决「最后一公里」</h3>这个项目最大的不确定性不在前端，而在最后一环——能不能把一个词程序化地写进不背单词的生词本。如果这条路走不通，前面采集做得再漂亮也没有意义。「不背单词」没有公开的加词 API。我逆向了它的官方查词插件，摸清了网页端逐词加生词本的接口，再用真实账号实测打通，整个项目从「想法」变成「可行」。<h3 id="第二步：跑通最小闭环"><a href="#第二步：跑通最小闭环" class="headerlink" title="第二步：跑通最小闭环"></a>第二步：跑通最小闭环</h3>第一个版本（0.1.0）目标很克制：网页采集 → 本地词库（IndexedDB）→ 确认后推送。架构上做了扩展 + CLI 双形态，共享同一份 TypeScript 核心包。这个阶段解决的都是「让它真的能用」的问题：<ul><li>MV3 的 service worker 会在纯网络请求循环中被浏览器杀掉，导致长词表推到一半静默停滞。解法是在推送循环里定期穿插扩展 API 调用作心跳保活。</li><li>采集和入库之间有竞态，弹窗的计数偶尔恒为 0，需要把消息链路改成完整的应答式。</li><li>词形还原引入了 compromise 这个 NLP 库，配上不规则动词表和保守的后缀回退。</li></ul><h3 id="第三步：把它变成「别人也能装」的产品"><a href="#第三步：把它变成「别人也能装」的产品" class="headerlink" title="第三步：把它变成「别人也能装」的产品"></a>第三步：把它变成「别人也能装」的产品</h3>1.0.0 是第一个上架 Chrome Web Store 的版本，主题是从「自己能用」到「敢给别人用」：<ul><li>加了确认闸门：采集结果先集中展示，确认后才入库推送——把「人在回路」从习惯固化成机制。</li><li>推送进度实时可见：从轮询改成事件驱动，工具栏图标上还有 badge 回执，推送到第几个词、成没成功，一眼可见。</li><li>加了错误日志的环形缓冲和一键导出：真出了问题，用户能把日志发给我。</li><li>支持上传文件采集，补上了三语界面（简体、繁体、英文），弹窗视觉整体重做成了一套统一的 man-page 风格设计。</li></ul>商店上架本身也是一次学习：Chrome Web Store 后台的表单结构、审核流程、隐私声明口径，都整理成了文档沉淀在仓库里。后来又上架了 Edge 商店。<h3 id="第四步：和「词」的边角料长期作战"><a href="#第四步：和「词」的边角料长期作战" class="headerlink" title="第四步：和「词」的边角料长期作战"></a>第四步：和「词」的边角料长期作战</h3>最有意思也最耗时间的，是那些听起来不像问题的问题。1.1.0 这一大版本几乎都在打磨「什么算一个该收录的词」：<ul><li>缩略词要不要收？ 像 <code>docs</code>、<code>app</code>、<code>stat</code> 这类词，在技术页面里满天飞，但背它们没什么意义。我做了一条构建管线，从 Wiktionary 的缩略词类目生成黑名单，再用词频表做守卫防止误杀。即便如此还是翻过车：<code>fox</code> 这种常用词曾因为词条数据污染被静默过滤掉，<code>the fox's den</code> 里的 fox 都不放过。修这类问题的过程让我把「缩略词的判定标准」从直觉提炼成了明确规则：看词源，不看常用度。</li><li>词形还原会制造不存在的词。 <code>pyjamas</code> 被还原成 <code>pyjamave</code>，<code>active</code> 被改写成 <code>actife</code>——这类畸形词元一旦入库，去重和黑名单匹配全部失效。解法是给还原管线加词典守门：还原结果得是真实存在的词，否则回退原词形。</li><li>并发与时序的暗坑：推送进行中用户又确认了一批新词怎么办？弹窗关了又开、驻留的待确认批次怎么处理？这些用户永远不该感知到的问题，靠一轮一轮的 e2e 测试和重构去堵。</li></ul>到这个阶段，仓库里已经有了单元测试、Playwright 端到端测试、构建期数据自检，词形还原的行为漂移会在两三个小时的构建管线一开始就被哨兵断言拦下来，而不是跑完才悄悄产出不一致的结果。<h2 id="设计原则：几条刻意保持的克制"><a href="#设计原则：几条刻意保持的克制" class="headerlink" title="设计原则：几条刻意保持的克制"></a>设计原则：几条刻意保持的克制</h2>回看整个过程，有几条原则一直在约束这个工具，我觉得也是它能保持简单的原因：<ol><li>人在回路：确认即推送是唯一入库路径，永不后台自动推送。工具可以帮你省事，但不能替你做决定。</li><li>拾取做轻，背诵外包：不解释词义，不安排复习，「背」这件事全部交给成熟的不背单词。重复造轮子没有价值。</li><li>极简数据：本地词库一行一个词、一个位掩码，能不存的字段就不存——没有时间戳，没有来源，也没有释义。</li><li>最小权限：只申请 <code>storage</code> / <code>activeTab</code> / <code>scripting</code> 三个权限，网络访问只限 bbdc.cn 和 langeasy.com.cn，不读 cookie，不采集页面内容以外的任何数据。</li><li>先跑通自用闭环再扩张：多端同步、更多背单词 App 渠道、宣传官网，都在后置清单上。第一个用户（我自己）的日常体验是一切判断的锚。</li></ol><h2 id="写在最后"><a href="#写在最后" class="headerlink" title="写在最后"></a>写在最后</h2>单词雷达不是一个宏大的项目。它只是把「读英文网页 → 收集生词 → 针对性记忆」这条原本断成三截、每截都靠手动衔接的路径，焊成了一条点了两次鼠标就能走完的流水线。如果你也读英文技术文档、也用不背单词，欢迎试试：<a href="https://chromewebstore.google.com/detail/wordradar/klbhhofbdklddefpnkbfdgecoheelpip">Chrome 商店</a> | <a href="https://microsoftedge.microsoft.com/addons/detail/%E5%8D%95%E8%AF%8D%E9%9B%B7%E8%BE%BE/bpgidbkjoehbpgkkkmobefiajgbgmmdo">Edge 商店</a>如果你也有一些小痛点，试一试 AI 开发，打开新世界的大门！

使用生财 MCP 构建 LLM-WIKI

2026-09-23 00:00:00

<h2 id="什么是-LLM-WIKI"><a href="#什么是-LLM-WIKI" class="headerlink" title="什么是 LLM-WIKI"></a>什么是 LLM-WIKI</h2>LLM-WIKI 是 Andrej Karpathy 大神 2026 年 4 月提出来的一个理念，核心是让大语言模型把阅读、理解、综合、交叉引用、矛盾发现和问答，持续沉淀为一个持久、结构化、互链、带引用的 Markdown 知识库。<blockquote>Agent owns the wiki; human owns the judgment.</blockquote>它可以：<ul><li>把离散的信息沉淀成结构化的知识库：通过理解、提炼、总结，把生财有术海量优质内容转换成清洗、糅合过的知识库。从文档中提取概念/实体/总结等多层结构，帮助我们更好地理解信息。</li><li>把文档集合转化为概念图谱：通过 wikilink 在文档和文档之间建立关联，关系脉络一目了然。</li><li>把问答的过程转换成知识维护过程：有价值的问答沉淀进知识库，问答本身也可以是知识。</li><li>把 LLM 的阅读工作从一次性消耗变成复利资产：LLM-WIKI 的每次摄入都会沉淀知识，告别传统一次性消耗。</li><li>维护知识：知识库不是死物，通过定期的 lint 检查和维护知识库，检查断链、修正引用关系、处理冲突、更新陈旧事实，防止知识库腐化。</li></ul>一张图看懂 LLM-WIKI：<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 2 3 4 5 6 7 8 9 10 11 </pre></td><td class="code"><pre>flowchart TD A[Raw Sources 网页 / PDF / 代码 / issue / transcript] --> B[Ingest 读取、理解、拆解] B --> C[Wiki Knowledge Layer Markdown 页面 + wikilinks + citations] C --> D[Query 基于 wiki 回答问题] D --> E{答案有长期价值吗?} E -- 是 --> C E -- 否 --> F[只返回答案] C --> G[Lint / Maintain 查断链、无引用、冲突、陈旧事实] G --> C C --> H[Derived Indexes 全文搜索 / 向量 / 图索引 / backlinks] H --> D </pre></td></tr></table></figure>通过 “资料进入 → 知识编译 → 问答复用 → 好答案回写 → 定期维护 → 知识继续变好” 的核心循环打造知识复利。<hr>OpenKB 是 LLM-WIKI 理念的开源实现。借助 OpenKB，我们可以方便快捷地搭建知识库，而不是从零搞基建。<img data-src="https://static.diqigan.cn/2026/45bef3bf53121aca0ce8fc3aecc11219.webp" alt="OpenKB 架构图"><h2 id="生财有术-LLM-WIKI-可以实现什么效果？"><a href="#生财有术-LLM-WIKI-可以实现什么效果？" class="headerlink" title="生财有术 LLM-WIKI 可以实现什么效果？"></a>生财有术 LLM-WIKI 可以实现什么效果？</h2><h3 id="构建知识图谱"><a href="#构建知识图谱" class="headerlink" title="构建知识图谱"></a>构建知识图谱</h3><ul><li>OpenKB 知识图谱： <img data-src="https://static.diqigan.cn/seven/2026/fd77b198795bd967f23e5a8d5864c498.png" alt="OpenKB 知识图谱"></li><li>Obsidian 关系图谱： <img data-src="https://static.diqigan.cn/seven/2026/4a1e34b622e5fb8a08e3f65bb412b6ba.png" alt="Obsidian 关系图谱"></li><li>Obsidian 关系图谱-亦仁： <img data-src="https://static.diqigan.cn/seven/2026/20b09088b9d655c22629a3fa0d343495.png" alt="Obsidian 关系图谱-亦仁"></li><li>Obsidian 关系图谱-垂直小号： <img data-src="https://static.diqigan.cn/seven/2026/79bb09ee82354ca2eb93f37f073af2e1.png" alt="Obsidian 关系图谱-垂直小号"></li></ul><h3 id="问答"><a href="#问答" class="headerlink" title="问答"></a>问答</h3><ul><li>问：“帮我梳理汇总公众号垂直小号的所有资料，告诉我相关的操作指引、工具、经验心得。” <img data-src="https://static.diqigan.cn/2026/78199b7898ca8229d5729484941cafb2.webp" alt="openkb-chat-vertical-small-account"></li></ul><h2 id="怎么用生财有术-MCP-构建-LLM-WIKI？"><a href="#怎么用生财有术-MCP-构建-LLM-WIKI？" class="headerlink" title="怎么用生财有术 MCP 构建 LLM-WIKI？"></a>怎么用生财有术 MCP 构建 LLM-WIKI？</h2>我们需要用到：<ul><li>scys-mcp：获取数据</li><li>openkb：加工数据</li><li>LLM API：openkb 大脑</li><li>AI Agent Client：执行助理</li></ul><figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 2 3 4 5 6 7 </pre></td><td class="code"><pre>flowchart LR H["我 出目标、做验收"] --> A["AI Agent Client ZCode / Claude Code"] A -- "MCP 协议 只读拉取" --> S["scys-mcp 生财数据源"] A -- "CLI 命令 驱动编译与 lint" --> O["openkb 知识编译器与问答"] O -- "API 调用 理解 / 综合 / 问答" --> L["LLM API openkb 大脑"] O --> W["wiki Markdown 知识库"] W --> V["Obsidian 图谱"] </pre></td></tr></table></figure><hr>构建过程极其简单，只需要创建一个 wiki 文件夹、使用你喜欢的 AI Agent 打开这个文件夹，全程只需要跟 AI Agent 对话： 有了 AI，很多操作都可以变得非常简单。<ol><li>参考 生财有术 MCP 上手指南 安装测试 scys-mcp。</li><li>初始化 OpenKB：<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 </pre></td><td class="code"><pre>使用 https://github.com/VectifyAI/OpenKB 初始化当前 wiki, LLM API 的配置信息可以让我协助配置。 </pre></td></tr></table></figure></li><li>初始化项目上下文：<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 2 </pre></td><td class="code"><pre>初始化项目，写入 AGENTS.md 上下文。 当前项目的目的是使用 scys-mcp 读取生财有术最近半年所有精华帖、超级标、航海手册，并且写入 openkb wiki。 </pre></td></tr></table></figure></li><li>执行数据采集与 WIKI 构建：<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 </pre></td><td class="code"><pre>使用 scys-mcp 读取生财有术最近半年所有精华帖、超级标、航海手册，并且写入 openkb wiki。 </pre></td></tr></table></figure></li></ol>就是这么简单。<hr>一些可能让你体验更舒服的优化项：<ol><li>把数据采集过程持久化为 SKILL：<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 </pre></td><td class="code"><pre>结合项目上下文，分析最近几次 scys-mcp 数据采集过程和 openkb 知识入库过程，帮我把数据采集和知识沉淀过程生成 scys-ingest skill。 </pre></td></tr></table></figure></li><li>优化/修正知识库内容：<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 2 </pre></td><td class="code"><pre>根据已经爬取的信息，优化 openkb metadata, openkb wiki 文件命名规则等，并持久化规则指引后续数据更新。 （这里按照自己的需求定制就好） </pre></td></tr></table></figure></li><li>日常的 wiki lint 检查和维护：<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 </pre></td><td class="code"><pre>使用 openkb lint 检查知识库并修正发现的问题。 </pre></td></tr></table></figure></li><li>从 WIKI 中提炼可复用的 Skills：<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 2 3 </pre></td><td class="code"><pre>使用 openkb skill new 指令帮我提炼 skill: - skill-name: <skill 名称> - intent: <意图：你想要提炼什么样的 skill> </pre></td></tr></table></figure></li><li>有能力的话，数据采集和入库过程可以做成定时任务。我们只管维护就好了。</li></ol>相关阅读：<a href="/posts/geek/llm-wiki-visual-guide.html" title="LLM-Wiki：让知识像花园一样持续生长">《LLM-Wiki：让知识像花园一样持续生长》</a><h2 id="后记"><a href="#后记" class="headerlink" title="后记"></a>后记</h2><ul><li>AI 赋予我们远超以往的能力，常使我们自觉“无所不能”。我们应该是 AI 的主人，而非奴隶。腾云驾雾的间隙，别忘了巩固自身。多看一些官方文档，知其然、知其所以然，知应如何进、知从何处退。</li><li>尽最快的速度，用上你知道的能最快上手的 AI；尽最大的努力，用上你能用上的最厉害的 AI。</li><li>只懂皮毛技术，业务常感生疏。行文略显生硬，各位看官见谅。技术只是躯壳，业务注入灵魂。是强是弱，还得辛苦各位定制和调教。</li><li>生财有术是少有的开放、互利共赢社群，祝大家早日大发！数据采集尽可能晚上跑吧，不要给生财服务器增加太多压力</li><li>数据采集不要贪心，大而全未必更好。小而精更显专注。</li></ul>

运维笔记：NetworkManager shared 模式给共享客户端固定 IP

2026-08-07 14:16:25

Manjaro Linux 用 WiFi（<code>wlp7s0</code>）上网，把网线口（<code>enp8s0</code>）共享给一台下游设备。共享用的不是独立 dnsmasq，而是 NetworkManager 自带的 <code>shared</code> 模式。下游设备能正常上网，但 IP 是 DHCP 动态分的，今天 <code>.108</code>，下次可能 <code>.109</code>。想把那台设备固定成 <code>10.42.0.2</code>，方便后面做端口转发和固定访问。<h2 id="现场"><a href="#现场" class="headerlink" title="现场"></a>现场</h2>笔记本同时连着两张网卡：<figure class="highlight text"><table><tr><td class="gutter"><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 </pre></td><td class="code"><pre> 上游 WiFi（出口） wlp7s0 192.168.1.x/24 gw 192.168.1.1 （示例网段） │ ┌────┴─────┐ │ 笔记本 │ Manjaro 26.1 / Kernel 7.1.4 │ │ NetworkManager 1.58（nmcli）/ dnsmasq 2.93 │ │ ipv4.method=shared（共享连接） └────┬─────┘ │ enp8s0 10.42.0.1/24 │ └─ NM 内置 dnsmasq：DHCP 池 10.42.0.10–254，租约 3600s ▼ 下游设备（share client） MAC aa:bb:cc:dd:ee:01 （示例）当前拿到 10.42.0.108 </pre></td></tr></table></figure>NM 用 <code>shared</code> 模式把 <code>enp8s0</code> 当 LAN 口，自动开了：<ul><li>本机 <code>enp8s0 = 10.42.0.1/24</code>（shared 模式固定用 <code>.1</code>，改不了）</li><li>一个内置 dnsmasq 提供 DHCP，动态池 <code>10.42.0.10 – 10.42.0.254</code></li><li><code>net.ipv4.ip_forward=1</code> + 自动加 iptables NAT，把流量从 <code>enp8s0</code> 转到 <code>wlp7s0</code> 上网</li></ul>确认连接是 shared 模式（下面命令里的 <code><共享连接名></code> 换成你自己的，比如我的叫 <code>ETH_SHARE</code>）：<figure class="highlight bash"><table><tr><td class="gutter"><pre>1 2 </pre></td><td class="code"><pre>$ nmcli connection show ETH_SHARE | grep ipv4.method ipv4.method: shared </pre></td></tr></table></figure>下游那台设备（MAC <code>aa:bb:cc:dd:ee:01</code>，示例）当前租约：<figure class="highlight bash"><table><tr><td class="gutter"><pre>1 2 </pre></td><td class="code"><pre>$ sudo cat /var/lib/NetworkManager/dnsmasq-enp8s0.leases 1700000000 aa:bb:cc:dd:ee:01 10.42.0.108 mydevice 01:aa:bb:cc:dd:ee:01 </pre></td></tr></table></figure><h2 id="定位：DHCP-实际由谁发出"><a href="#定位：DHCP-实际由谁发出" class="headerlink" title="定位：DHCP 实际由谁发出"></a>定位：DHCP 实际由谁发出</h2>shared 模式的 DHCP 不是系统级的 <code>dnsmasq.service</code> 发的——它是 <code>inactive</code> 的：<figure class="highlight bash"><table><tr><td class="gutter"><pre>1 2 </pre></td><td class="code"><pre>$ systemctl status dnsmasq ○ dnsmasq.service ... ; Active: inactive (dead) </pre></td></tr></table></figure>真正发 DHCP 的是 NM 拉起的另一个 dnsmasq 实例，看进程就能定位到它和它的配置入口：<figure class="highlight bash"><table><tr><td class="gutter"><pre>1 2 3 4 5 6 7 8 </pre></td><td class="code"><pre>$ ps aux | grep dnsmasq | grep -v grep nobody 1234 /usr/bin/dnsmasq --conf-file=/dev/null --no-hosts --keep-in-foreground \ --bind-interfaces --except-interface=lo --clear-on-reload --strict-order \ --listen-address=10.42.0.1 \ --dhcp-range=10.42.0.10,10.42.0.254,3600 \ --dhcp-leasefile=/var/lib/NetworkManager/dnsmasq-enp8s0.leases \ --pid-file=/run/nm-dnsmasq-enp8s0.pid \ --conf-dir=/etc/NetworkManager/dnsmasq-shared.d </pre></td></tr></table></figure>这条启动参数里有三个关键点：<ul><li><code>--conf-file=/dev/null</code> —— 这个实例显式忽略 <code>/etc/dnsmasq.conf</code>，所以 DHCP 的定制入口不在那里。</li><li><code>--conf-dir=/etc/NetworkManager/dnsmasq-shared.d</code> —— 真正的配置目录，NM 给 shared 模式专用，默认是空目录。这就是塞 <code>dhcp-host</code> 的地方。</li><li>它的生命周期挂在那个共享连接上——NM 激活连接时拉起、停用时杀掉，不归 <code>dnsmasq.service</code> 管。所以重载配置要靠重连，而不是 <code>systemctl restart dnsmasq</code>。</li></ul><blockquote>保持 NM 全托管即可，不要去启用 <code>dnsmasq.service</code>。它和这个内置实例会抢 53/67 端口，造成 DHCP 双重应答、DNS 冲突。</blockquote><h2 id="修复：往-conf-dir-放-dhcp-host-静态绑定"><a href="#修复：往-conf-dir-放-dhcp-host-静态绑定" class="headerlink" title="修复：往 conf-dir 放 dhcp-host 静态绑定"></a>修复：往 conf-dir 放 dhcp-host 静态绑定</h2>目标：把下游设备（MAC <code>aa:bb:cc:dd:ee:01</code>，示例）固定成 <code>10.42.0.2</code>。<figure class="highlight bash"><table><tr><td class="gutter"><pre>1 2 3 4 5 6 7 </pre></td><td class="code"><pre>$ sudo mkdir -p /etc/NetworkManager/dnsmasq-shared.d $ sudo tee /etc/NetworkManager/dnsmasq-shared.d/static-leases.conf >/dev/null <<'EOF' # 共享连接 (enp8s0) 客户端固定 IP 绑定 # 10.42.0.2 在默认动态池 10.42.0.10–254 之外，dnsmasq 不会动态发出，无冲突 dhcp-host=aa:bb:cc:dd:ee:01,10.42.0.2,mydevice,infinite EOF </pre></td></tr></table></figure><code>dhcp-host</code> 的格式：<code><MAC>,<IP>,<hostname>[,infinite]</code>。<code>infinite</code> 是永久租约，IP 永远属于这台设备。写完先做语法自检，别等重连了才发现 dnsmasq 起不来：<figure class="highlight bash"><table><tr><td class="gutter"><pre>1 2 </pre></td><td class="code"><pre>$ sudo dnsmasq --test --conf-file=/dev/null --conf-dir=/etc/NetworkManager/dnsmasq-shared.d dnsmasq: syntax check OK. </pre></td></tr></table></figure>然后让 NM 重启它的 dnsmasq。最干净的方式是重连那个共享连接（下文记作 <code>ETH_SHARE</code>，换成你自己的连接名），NM 会自动杀掉旧 dnsmasq、起新的并加载 conf-dir：<figure class="highlight bash"><table><tr><td class="gutter"><pre>1 </pre></td><td class="code"><pre>$ sudo nmcli connection down ETH_SHARE && sudo nmcli connection up ETH_SHARE </pre></td></tr></table></figure><blockquote>为什么不直接 <code>kill -HUP</code> 那个 dnsmasq？也能用，<code>sudo kill -SIGHUP $(cat /run/nm-dnsmasq-enp8s0.pid)</code> 会让它重读配置、不中断现有连接。但重连更彻底——尤其当配置改了 DHCP 池范围时，<code>HUP</code> 不一定全量重载。这次只加 dhcp-host，两者都行，我选了重连。</blockquote>验证新 dnsmasq 起来了、且带上了 conf-dir：<figure class="highlight bash"><table><tr><td class="gutter"><pre>1 2 3 4 5 </pre></td><td class="code"><pre>$ cat /run/nm-dnsmasq-enp8s0.pid 5678 # PID 变了（重启前是另一个值），确认实例重启 $ ps -o args= -p $(cat /run/nm-dnsmasq-enp8s0.pid) | tr ' ' '\n' | grep conf-dir --conf-dir=/etc/NetworkManager/dnsmasq-shared.d </pre></td></tr></table></figure>到这一步服务端就配完了。<h2 id="客户端必须重拿一次-DHCP"><a href="#客户端必须重拿一次-DHCP" class="headerlink" title="客户端必须重拿一次 DHCP"></a>客户端必须重拿一次 DHCP</h2>配完绑定，下游设备的 IP 不会自动从 <code>.108</code> 变成 <code>.2</code>。静态绑定只在客户端下次续约/重连时生效——这是最容易漏的一步。<ul><li>Linux 客户端：<code>sudo dhclient -r && sudo dhclient</code></li><li>嵌入式/摄像头/手机：拔插网线或重启设备即可</li></ul>重连后回笔记本看租约：<figure class="highlight bash"><table><tr><td class="gutter"><pre>1 2 3 4 5 6 </pre></td><td class="code"><pre>$ sudo cat /var/lib/NetworkManager/dnsmasq-enp8s0.leases # 期望：aa:bb:cc:dd:ee:01 10.42.0.2 mydevice ... $ ping -c2 10.42.0.2 $ ip neigh show dev enp8s0 # 期望：10.42.0.2 lladdr aa:bb:cc:dd:ee:01 REACHABLE </pre></td></tr></table></figure><h2 id="小结"><a href="#小结" class="headerlink" title="小结"></a>小结</h2>NetworkManager 的 <code>shared</code> 模式是个黑盒：表面上是 NM 一个连接配置，背后它替你拉起了一整套 dnsmasq + iptables + ip_forward。好处是开箱即用，代价是 DHCP 的定制入口藏得很深——不是 <code>/etc/dnsmasq.conf</code>，而是 <code>/etc/NetworkManager/dnsmasq-shared.d/</code>。记住这个映射关系就够了：改 shared 模式的 DHCP 行为，找 NM 内置 dnsmasq 的 conf-dir，别找系统的 dnsmasq.service。

运维踩坑：nginx 缓存上游容器旧 IP，请求转发到了错误的服务

2026-08-04 11:00:00

容器化微服务环境，前置 nginx 反代到 Spring Cloud Gateway。某次 gateway 容器重建后，所有经 nginx 的 <code>/api/**</code> 请求开始返回 500，而 gateway 自身、服务发现、各业务服务均正常。排查绕了一大圈，根因是 nginx 的一个经典行为：<code>proxy_pass</code> 写主机名时只在启动时解析一次，之后永久缓存。上游容器重建换 IP 后，nginx 仍在连旧 IP——而旧 IP 已被 Docker 分配给了另一个服务。<h2 id="现场"><a href="#现场" class="headerlink" title="现场"></a>现场</h2>前置 nginx + Spring Cloud Gateway + Nacos 架构，全部跑在同一个 Docker 自定义网络（<code>172.18.0.0/16</code>）里：<figure class="highlight text"><table><tr><td class="gutter"><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 </pre></td><td class="code"><pre> Docker 网络 172.18.0.0/16 ┌─────────┐ ┌──────────────────────────────────────────────┐ │ 客户端 │ ──8000─▶│ nginx 容器 172.18.0.10 │ └─────────┘ │ location /api/ { proxy_pass ...:8080 } │ └───────────────────┬──────────────────────────┘ │ proxy_pass http://project-gateway:8080 ▼ (nginx 在启动时把主机名解析成 IP 并缓存) ┌─────────────────────────────┴─────────────────────────────┐ ▼ ▼ ▼ ┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐ │ project-gateway │ │ project-order │ │ project-auth │ │ Spring Cloud │ │ 业务服务 │ │ 业务服务 │ │ Gateway │ │ 172.18.0.20 │ │ 172.18.0.22 │ │ 172.18.0.21 │ └───────────────────┘ └───────────────────┘ │ 订阅 Nacos 实例 │ ▲ └─────────┬─────────┘ │ │ │ nginx worker 实际连的是这个旧 IP ▼ │ —— gateway 重建前它属于 gateway， ┌───────────────────┐ │ 重建后被 Docker 重新分配给了 order │ Nacos │ │ │ 172.18.0.2 │ ─ ─ ─ ─ ─ ─ ─ ┘ └───────────────────┘ 服务发现正常，但与 nginx 转发目标无关 </pre></td></tr></table></figure>请求链路本该是 <code>客户端 → nginx → gateway → 业务服务</code>，gateway 再按 Nacos 的实例列表把请求路由到 <code>project-order</code> / <code>project-auth</code>。但出问题时 nginx 根本没把请求交给 gateway——某个经 nginx 的接口请求报错：<figure class="highlight plaintext"><table><tr><td class="gutter"><pre>1 2 </pre></td><td class="code"><pre>GET http://10.20.30.40:8000/api/xxx {"traceId":null,"code":1,"data":null,"message":"unknow.exception"} HTTP 500 </pre></td></tr></table></figure>几个看似矛盾的现象，把排查方向带偏了数次：<ul><li>服务发现正常：目标服务已注册到 Nacos，gateway 也订阅到了实例。</li><li>gateway 容器内直连正常：<code>curl gateway:8080/xxx</code> 返回 200。</li><li>但经 nginx 的请求，gateway 一条日志都没有——请求根本没到 gateway。</li><li>nginx 配置看不出问题：<code>location /api/ { proxy_pass http://project-gateway:8080/; }</code>，<code>proxy_pass</code> 带尾部 <code>/</code> 会剥前缀，没毛病。</li><li><code>docker exec nginx curl project-gateway:8080</code> 也是通的。</li></ul>配置对、直连通、<code>exec</code> 也通，唯独经 nginx 就 500 且 gateway 收不到——问题出在 nginx worker 实际把请求转发到了哪。抓 nginx worker 的真实 TCP 连接目标（<code>/proc/net/tcp</code> 解码）：<figure class="highlight text"><table><tr><td class="gutter"><pre>1 </pre></td><td class="code"><pre>38 -> 172.18.0.20:8080 ← nginx worker 在连这个 IP </pre></td></tr></table></figure>对照各容器当前 IP：<figure class="highlight text"><table><tr><td class="gutter"><pre>1 2 3 </pre></td><td class="code"><pre>project-gateway -> 172.18.0.21 project-order -> 172.18.0.20 ← nginx 连的是它，不是 gateway project-auth -> 172.18.0.22 </pre></td></tr></table></figure>nginx 把请求转发到了 <code>172.18.0.20</code>（业务服务 <code>project-order</code>），而非 gateway（<code>.21</code>）。该服务没有对应路由，抛异常被框架兜底成 500。<blockquote>为什么 <code>docker exec</code> 通、worker 却不通？<code>exec</code> 启动的新 shell 用当前 DNS（解析到 <code>.21</code>），而 nginx worker 用的是启动时缓存的旧 IP（<code>.20</code>）。同一容器、同一网络栈，DNS 解析的时机不同。</blockquote><h2 id="根因"><a href="#根因" class="headerlink" title="根因"></a>根因</h2><figure class="highlight nginx"><table><tr><td class="gutter"><pre>1 2 3 </pre></td><td class="code"><pre>location /api/ { proxy_pass http://project-gateway:8080/; # 静态主机名，全配置无 resolver } </pre></td></tr></table></figure><ul><li><code>proxy_pass</code> 写的是主机名，且全配置没有 <code>resolver</code> 指令 → nginx 在启动时解析一次并永久缓存，之后不再重新解析。</li><li>gateway 容器重建后 IP 由 <code>.20</code> 变 <code>.21</code>，旧 IP <code>.20</code> 被 Docker 重新分配给了 <code>project-order</code>。</li><li>nginx 仍在连旧 IP，于是所有 <code>/api/**</code> 请求都打到了 <code>project-order</code>。</li></ul>一句话：<code>proxy_pass</code> 写主机名 = 启动期解析一次后缓存，容器 IP 一变就连错。<h2 id="修复"><a href="#修复" class="headerlink" title="修复"></a>修复</h2><code>resolver</code> + 变量版 <code>proxy_pass</code>，让 nginx 按 TTL 动态解析：<figure class="highlight nginx"><table><tr><td class="gutter"><pre>1 2 3 4 5 6 7 8 9 10 11 12 13 14 </pre></td><td class="code"><pre>http { resolver 127.0.0.11 valid=30s ipv6=off; # Docker 内置 DNS } location /api/ { set $upstream_gateway project-gateway; # 变量触发动态解析 proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; rewrite ^/api/(.*)$ /$1 break; # 显式剥 /api/ 前缀 proxy_pass http://$upstream_gateway:8080; # 不带尾部 /，配 rewrite 用纯地址 } </pre></td></tr></table></figure>三个关键点：<ol><li><code>resolver 127.0.0.11 valid=30s</code> —— Docker 内置 DNS，解析结果 30 秒过期。</li><li><code>set $upstream</code> + 变量版 <code>proxy_pass</code> —— <code>proxy_pass</code> 一旦含变量，nginx 就不再启动期静态解析，而是运行时走 <code>resolver</code>。这是社区版 nginx 动态解析上游的唯一方式。</li><li><code>rewrite ^/api/(.*)$ /$1 break</code> —— 必须显式剥前缀（原因见下）。</li></ol><h3 id="连环坑：变量版-proxy-pass-不剥前缀"><a href="#连环坑：变量版-proxy-pass-不剥前缀" class="headerlink" title="连环坑：变量版 proxy_pass 不剥前缀"></a>连环坑：变量版 proxy_pass 不剥前缀</h3>从纯文本 <code>proxy_pass http://x:8080/;</code> 改成变量版后，原来自动剥 <code>/api/</code> 前缀的能力消失了，后端会收到错误的 path（实测 gateway 收到的是 <code>/</code>）。所以必须配 <code>rewrite ... break</code> 显式剥，并且 <code>proxy_pass</code> 去掉尾部 <code>/</code>（配 <code>rewrite break</code> 时必须是纯地址，带 URI 会二次改写）。<h3 id="别走这条路"><a href="#别走这条路" class="headerlink" title="别走这条路"></a>别走这条路</h3><code>upstream {}</code> 块里写主机名同样是启动期一次性解析，不动态刷新（只有 Nginx Plus 的 <code>resolve</code> 参数才动态）。<code>upstream</code> 块解决不了这个问题。改完 <code>nginx -t && nginx -s reload</code>，容器怎么重建、IP 怎么变，nginx 都会按 30 秒 TTL 自动跟上。

Seven | 小柒修改

Seven | 小柒的 RSS 预览

该作者的社会化媒体