Posts for: #Startup

目前对停更星球的风控机制太生硬了，不少星主反馈过这个问题。

现状是：无论星主因为什么原因停更，一段时间不更新，我们就把星球标记为高风险。等星主想回来继续更新，要走一套很复杂的重新激活流程。这个流程的初衷是保护付费用户，但一刀切的代价是——把那些只是暂停了、并没有坑人的星主也拦住了。

一个星主收了钱跑路，和一个星主忙了半年没更新，性质完全不同。前者有投诉、有退款、有纠纷；后者可能安安静静，客服那边什么动静都没有。我们应该区分这两种情况。

改造思路：

“必须加入才能分销”，就是用门槛换信任。

为什么这么设计

分销最怕变成纯流量生意。如果任何人都能拿到分销链接，会出现大量没看过内容的人纯粹为佣金推广，推荐质量不可控。要求先加入，等于把"体验过产品"作为分销资格的前置条件。推荐者说"这个星球值得加入"，至少他自己付过费、看过内容，这句话有基本的可信度。

还是转 Lenny 的邮件列表——时不时这么转一下，看起来他的订阅不能退——要不然不厚道了，文章是：

https://r.slax.com/s/dBX213420d

这个访谈的原文在 YouTube 上也有，可以参考：

https://www.youtube.com/watch?v=k-H4nsOTuxU

虽然……虽然对面是 Claude，但应该也还是有可以学的地方，我有感触的几个小点是：

1. AI 显著提升工程效率：一个 5 人工程团队可以完成过去 15–20 人的产出。但产品经理（PM）与设计效率没有同步提升，导致单个 PM 需要管理更大的工程产出规模.应对方式：增加 PM 人数、让工程师承担部分产品职能（“轻量 PM”）。
2. Anthropic 使用内部系统 CASH（Claude Accelerates Sustainable Hypergrowth）来自动执行增长实验，覆盖：机会发现、功能构建、测试、结果分析。当前能力类似一名初级 PM，主要处理文案和小规模界面优化，并在快速提升。增长实验正在被 AI 自动化。核心流程是：

• AI 发现增长机会
• 人类筛选
• AI/团队执行实验
• 自动分析结果
• 继续迭代

3. 工作方式：少文档、快迭代。Anthropic 的增长团队中，60%–80% 的项目没有正式 PRD：小项目直接在 Slack 推进、大项目通过简短 kickoff 对齐。整体偏好：快速原型 → 持续迭代，而非前期重文档。
4. 战略重心：大机会优先。传统增长模式以小优化为主，而 Anthropic 的策略是：约 70% 投入“大赌注”。原因在于：AI 产品价值随模型能力呈指数增长，小优化的重要性相对下降。

此前想要了解一个开源项目，需要下载代码，阅读文档，运行测试，如果确实有兴趣，再尝试理解每个文件是干嘛的，找出自己最感兴趣的部分……

最近仍然保持了看新东西的兴趣，流程也基本不变，只是效率变高了——因为有了 AI。我现在通常是 clone 代码之后：

• 进入代码目录，运行 Claude code，让 ai 先帮我理解这个项目。
• 让 ai 告诉我如何把项目运行起来测试，甚至直接让它配置。
• 让它写一个 readme，把目录结构和每个文件的作用写出来

我看到这个第一感受是：这个项目可能对知识星球、Slax Reader 和 Slax Note 都会有思路启发。

原文发布于 2026 年 4 月 2 日（X/Twitter 推文），随后于 4 月 4 日发布了配套的 GitHub Gist「idea file」。以下为推文全文及 Gist 完整翻译。

一、推文正文

LLM 知识库

我最近发现一种非常有用的做法：用大语言模型来构建个人知识库，服务于各类研究课题。

这样一来，我最近消耗的 token 中，越来越大的比例不再用于操控代码，而是用于操控知识——以 Markdown 和图片的形式存储。最新一代的大模型在这方面表现相当出色。

具体是这样的：

数据摄入（Data Ingest）： 我把各类源文档（文章、论文、代码仓库、数据集、图片等）索引到一个 raw/ 目录下，然后用大模型增量「编译」出一套 Wiki。这套 Wiki 就是一组按目录结构组织的 .md 文件，包含对 raw/ 中所有数据的摘要、反向链接，还会把数据归类为不同概念、为每个概念撰写文章，并将它们相互关联。

要把网页文章转成 .md 文件，我喜欢用 Obsidian Web Clipper 扩展。我还设了一个快捷键来下载文章中的所有相关图片到本地，这样大模型就能方便地引用它们。

问答（Q&A）： 真正有趣的是，当你的 Wiki 积累到一定规模后（比如我某个近期研究课题的 Wiki 已经有大约 100 篇文章、约 40 万字），你可以向大模型代理提出各种复杂问题，它会自己去 Wiki 里查找、研究，然后给出答案。

我本以为需要用到花哨的 RAG 技术，但事实证明，大模型自己维护索引文件和各文档的简要摘要就已经做得很好了——在这个不算太大的规模下，它能相当轻松地读取所有重要的相关数据。

输出： 相比在终端里获取纯文本回答，我更喜欢让大模型生成 Markdown 文件、幻灯片（Marp 格式）或 matplotlib 图表，然后在 Obsidian 里查看。你可以想象，根据不同的查询需求，还可以有很多其他可视化输出格式。很多时候，我会把这些输出结果「归档」回 Wiki 里，以此增强知识库，为后续查询服务。这样，我自己的每一次探索和提问都会在知识库中「累积」下来。

质检（Linting）： 我会让大模型对 Wiki 进行「健康检查」——比如发现不一致的数据、补全缺失的数据（借助网页搜索）、发现值得撰写新文章的有趣关联等等，以此逐步清理 Wiki 并提升其整体数据质量。大模型非常擅长提出进一步值得追问和研究的问题。

额外工具： 我发现自己还会开发一些小工具来处理数据。比如我用 vibe coding 快速搭了一个针对 Wiki 的小型朴素搜索引擎，既可以直接通过 Web UI 使用，但更多时候是让大模型通过命令行当作工具来调用，用于处理更大规模的查询。

进一步探索： 随着仓库不断增长，自然会开始考虑合成数据生成和微调，让大模型把这些数据「内化」到权重里，而不仅仅依赖上下文窗口。

总结（TLDR）： 从若干来源收集原始数据，然后由大模型编译成 .md Wiki，再由大模型通过各种命令行工具对其进行问答和增量增强。

你几乎永远不需要手动编写或编辑 Wiki——那是大模型的领地。我认为，这里完全有空间诞生一款了不起的新产品，而不只是一堆拼凑的脚本。

二、推文评论区补充（Karpathy 本人回复摘录）

关于增量编译的问题： 目前这并不是一个完全自动化的过程。我一次手动添加一个来源，特别是在早期阶段会深度参与。等到积累了一定量之后，大模型就「理解」了这个模式，每添加一篇新文档就轻松多了——我只需要说「把这篇新文档归档到我们的 Wiki 里：（路径）」。

关于目录结构： 目前没有复杂结构，因为我刻意保持极简和扁平——就是嵌套目录下的 .md 文件、.png 文件，加上少量 .csv 和 .py，schema 在 AGENTS.md 里维护。大模型非常容易理解这种结构。任何自定义功能都可以轻松地用 vibe coding 做出工具来。

三、Gist 完整版：LLM Wiki

以下翻译自 Karpathy 于 4 月 4 日发布的 GitHub Gist「idea file」（原文链接）。这是一份「理念文档」，旨在传达整体思路，你可以直接把它复制粘贴给自己的大模型代理（如 OpenAI Codex、Claude Code、OpenCode / Pi 等），由代理与你协作完成具体搭建。

核心理念

大多数人使用大模型处理文档的方式都像 RAG：你上传一批文件，大模型在查询时检索相关片段，然后生成回答。这能用，但大模型每次提问都在从零开始重新发现知识，没有任何积累。如果你问一个需要综合五篇文档才能回答的细致问题，大模型每次都得重新找到并拼凑相关的碎片。什么都没有沉淀下来。NotebookLM、ChatGPT 的文件上传，以及大多数 RAG 系统，都是这个模式。

这里的思路截然不同。与其在查询时才从原始文档中检索，不如让大模型增量构建并维护一套持久化的 Wiki——一组结构化的、相互链接的 Markdown 文件，位于你和原始资料之间。当你添加一个新来源时，大模型不是仅仅把它索引起来留待后用，而是读取它，提炼关键信息，然后整合到现有 Wiki 中——更新实体页面，修订主题摘要，标注新数据与旧说法的矛盾，强化或挑战正在演进的综合分析。知识被编译一次，然后持续更新，而非每次查询时重新推导。

这就是关键区别：Wiki 是一个持久化的、不断累积的产物。 交叉引用已经建好了，矛盾已经被标记了，综合分析已经反映了你读过的全部内容。每添加一个来源、每提出一个问题，Wiki 都变得更加丰富。

你几乎永远不需要自己动手写 Wiki——大模型负责全部的编写和维护。你负责的是策划来源、探索方向、提出好的问题。大模型做所有的苦力活——摘要、交叉引用、归档、簿记——这些才是让一个知识库真正长期有用的关键。在实际操作中，我一边开着大模型代理，一边开着 Obsidian。大模型根据我们的对话进行编辑，我则实时浏览结果——跟踪链接、查看图谱视图、阅读更新后的页面。Obsidian 是 IDE；大模型是程序员；Wiki 是代码库。

这个模式可以应用于很多场景，举几个例子：

• 个人成长： 跟踪你的目标、健康、心理状态、自我提升——将日记条目、文章、播客笔记归档，逐步构建出关于自己的结构化全景。
• 学术研究： 在数周或数月内深入钻研一个课题——阅读论文、文章、报告，增量构建一套全面的 Wiki，逐步形成不断演进的论点。
• 读书： 逐章归档，为角色、主题、情节线索以及它们之间的联系建立页面。读完之后你会拥有一套丰富的伴读 Wiki。想想像 Tolkien Gateway 那样的粉丝 Wiki——数千个相互链接的页面，覆盖角色、地点、事件、语言，由一个社区的志愿者花费数年建成。你可以在阅读过程中自己搭建类似的东西，而大模型负责所有的交叉引用和维护工作。
• 商业/团队： 由大模型维护的内部 Wiki，喂入 Slack 对话、会议记录、项目文档、客户电话。可以让人类审核更新。Wiki 能保持时效性，因为大模型完成了团队中没人愿意做的那些维护工作。
• 竞品分析、尽职调查、旅行规划、课程笔记、兴趣爱好深挖——任何随着时间推移不断积累知识、且需要将知识组织起来而非散落各处的场景。

架构

共分三层：

原始素材（Raw Sources） ——你精选的源文档集合。文章、论文、图片、数据文件。这些是不可变的——大模型只读不改。这是你的事实之源。

Wiki ——一个由大模型生成的 Markdown 文件目录。包括摘要、实体页面、概念页面、对比分析、概览、综合分析。大模型完全拥有这一层。它创建页面，在新来源到达时更新它们，维护交叉引用，保持一切一致。你来读；大模型来写。

Schema（配置层） ——一份文档（例如为 Claude Code 准备的 CLAUDE.md，或为 Codex 准备的 AGENTS.md），告诉大模型 Wiki 的结构是什么样的、有哪些约定、以及在摄入来源、回答问题或维护 Wiki 时应遵循什么工作流程。这是核心配置文件——它让大模型成为一个训练有素的 Wiki 管理员，而不是一个泛泛的聊天机器人。你和大模型会随着时间推移共同演进这份文档，逐步摸索出适合你的领域的最佳实践。

操作

摄入（Ingest）。 你把一个新来源放入原始素材集合，然后让大模型处理它。一个典型的流程是：大模型读取来源，与你讨论关键要点，在 Wiki 中写一页摘要，更新索引，更新 Wiki 中所有相关的实体和概念页面，并在日志中追加一条记录。单一来源可能会触及 10-15 个 Wiki 页面。就我个人而言，我更喜欢一次摄入一个来源并保持参与——我会读摘要、检查更新、引导大模型该强调什么。但你也可以一次批量摄入多个来源、减少人工监督。你需要自己摸索出适合自己风格的工作流，并将其记录在 Schema 中，供未来的会话参考。

查询（Query）。 你针对 Wiki 提问。大模型搜索相关页面，读取它们，然后综合出一个附有引用的答案。答案可以有不同的形式——一页 Markdown、一张对比表、一套幻灯片（Marp）、一张图表（matplotlib）、一块画布。重要的洞察是：好的答案可以作为新页面归档回 Wiki。 你提出的对比、分析、发现的关联——这些都很有价值，不应该消失在聊天记录里。这样，你的每一次探索都和摄入的来源一样，在知识库中不断累积。