Stigmergy 这类 Karpathy 风格的 LLM wiki最值得关注的不是“又多了一个 AI 笔记工具”而是它把 wiki 的维护者从一个人换成了一整个团队。Karpathy 提出的 LLM wiki 思路核心是用大模型持续生成、更新和修正 wiki 页面让知识库像代码仓库一样可以不断迭代。而 Stigmergy 这个名字来自生物学里的“间接协作”机制放到这个项目里意思很明确不是你一个人写也不是某个 AI 单独写而是团队里的每个人和 LLM 一起通过同一个知识库间接协作。这篇文章会拆解它解决什么问题、团队部署时要准备什么、以及从“能跑”到“真的有用”中间要处理哪些细节。我在第一次看到这个项目标题时的反应是这类工具终于有人做了。个人 AI 笔记已经很多但团队协作场景下生成内容的质量、权限、并发、审核问题都没有被真正解决。Stigmergy 想做的不是“让 AI 帮你写 wiki”而是“让一个团队通过 AI 维护的 wiki 协作”。这个定位本身就是它和个人工具最大的分界线。1. Stigmergy 到底是做什么的团队版 LLM wiki 的核心思路1.1 Karpathy 式 LLM wiki 到底是一种什么范式Andrej Karpathy 在很多场合表达过一个判断wiki 是 LLM 特别适合的场景。传统 wiki 最大的问题是维护成本高。写的时候费劲过几个月内容就过期没人愿意更新。LLM 的特性恰恰能补上这个短板它可以做增量更新、自动补充、语义关联、格式统一甚至能在发现矛盾时主动修正。这个思路本身并不复杂但落地到一个人身上和落地到团队身上完全是两套逻辑。个人版 LLM wiki本质上是“AI 帮你整理第二大脑”团队版则是“AI 帮整个团队维护公共知识库”。后者要考虑的问题包括谁来审核生成内容、多人同时编辑怎么处理、不同角色有什么权限、知识库里的敏感信息怎么隔离。Stigmergy 的定位从项目标题就能看出来Karpathy-style说明它继承了 LLM wiki 的内容范式——以 Markdown 或纯文本为底层通过 LLM 生成和更新页面页面之间用语义关联或双向链接组织。但它的落点不是“for one person”而是“for a team”。这一句话就把场景切换了。1.2 “Stigmergy”这个名字点出了团队协作的本质Stigmergy 这个词很多人第一次看到会觉得很陌生。它来自生物学指的是一种通过环境改变来完成的间接协作机制。最经典的例子是蚂蚁蚂蚁不直接交流而是通过信息素在环境中留下痕迹其他蚂蚁根据痕迹调整行动方向。把“stigmergy”这个概念映射到团队 wiki 上大概可以这样理解每个团队成员不一定需要直接和所有人沟通大家通过更新同一份知识库来影响其他人的后续工作。有人补充了一个 API 的调用示例另一个人在做集成时就会少踩坑有人修正了一个页面里的错误后来查询的人就不会被误导。而 LLM 在这里面的角色不只是查询入口更像是一个“读环境并整理环境”的参与者。它读团队留下的各种片段生成摘要、补充缺失项、建立页面关联再把这些内容放回知识库形成下一轮协作的基础。这个循环一旦转起来知识库本身就是团队的“信息素”。这里需要说清楚它不是把每个人写的文档自动合并成一个知识库而是让 LLM 在这个协作循环里承担整理、补齐和结构化的职责。团队越用它知识库的关联越丰富后续查询和生成的质量也会更好。2. 同一个名字两套逻辑个人 LLM wiki 和团队 LLM wiki 差在哪里2.1 个人场景一个人用一个人负责一个人受益个人使用 LLM wiki通常只需要满足几个条件能导入自己的笔记或文档、能通过 LLM 生成和润色页面、能搜索和问答。对权限、并发、内容评审基本没有要求。这是因为整个循环是闭环的你是唯一使用者也是唯一责任人。页面写错了你自己知道内容过时了你随时改上下文窗口不够你可以把文档拆小检索不准你可以换 embedding 或调整提示词。所有调整不需要跟任何人对齐。个人场景下“内容可信度”也没有那么尖锐。你写给自己看本来就会带着批判性。就算 LLM 生成的内容有瑕疵你在阅读时通常能用自己的判断兜底。2.2 团队场景权限、并发、审核和信任问题团队场景完全不同。一个团队用同一个 wiki至少要考虑这几类问题第一是权限。谁可以创建页面谁可以修改谁只能查看。如果所有人都有全部权限很快会有人误改重要页面或者把不成熟的内容直接发布出去。第二是并发。两个人同时编辑一个页面以谁的修改为准如果工具没有版本历史和冲突对比机制后保存的人可能直接覆盖前一个人的内容。第三是审核。LLM 生成的页面再流畅也只是“生成的草稿”不是“已确认的事实”。如果团队直接采用而没有审核错误内容会通过 wiki 快速扩散。第四是信任。wiki 里的内容一旦多起来团队会默认“写在上面的应该是真的”。如果 LLM 生成的内容里混着看似合理但实际错误的代码示例、命令参数或配置项新人照做一遍问题会非常大。2.3 一张表看清个人版和团队版的差异维度个人 LLM wiki团队 LLM wiki使用者1 人5 人到上百人不等权限管理基本不需要必须区分创建、编辑、只读并发控制很少出现经常出现需要版本历史和冲突处理内容审核自己判断至少要有页面状态或负责人机制错误影响只影响自己会影响整个团队甚至新成员的信任检索需求个人习惯优先命名规范和标签体系更重要模型通道可以随时更换需要考虑统一配置和成本控制很多人把个人 AI 工具直接搬进团队用结果几天就乱了页面冲突没人处理生成内容没人审核最后 wiki 变成一个“看起来很高科技”的文件堆。Stigmergy 这类面向团队的 LLM wiki真正的价值不在生成能力而在于它把生成能力和协作流程绑定在一个系统里。3. 部署之前先把模型、存储和权限这三件事想清楚3.1 模型通道本地模型、API 服务还是混合模式团队使用 LLM wiki第一件事不是急着找部署命令而是确定模型通道。这一步决定了后面几乎所有配置。如果你所在的环境要求数据必须在内部处理那基本只能选择本地模型。这种方式的优势是可管控但代价是显存、内存和部署运维成本都更高。需要确认团队里有谁会维护模型服务模型更新时怎么迭代以及推理速度能不能承载团队使用量。如果允许使用外部 API成本和延迟就是核心变量。搜索、摘要、页面生成、问答调用每次都会消耗 token。wiki 内容越多调用量越大。建议先列出主要场景比如页面生成、上下文检索、语义查询再评估每个场景的 token 消耗量。我见过不少团队卡在启动前是很可惜的工具装好了模型 API 没申请或者申请了但没配好。先确认模型通道能正常返回结果再规划 wiki 本身的部署顺序会顺很多。3.2 存储与索引Markdown 文件、数据库、向量索引团队 LLM wiki 的数据层通常分成三块原始内容存储、结构化索引、向量检索索引。原始内容如果以 Markdown 文件存储好处是透明、易备份、可以纳入 Git 管理缺点是并发写入需要额外处理。如果使用数据库并发和查询更方便但备份和迁移要单独考虑。向量索引负责检索相似片段供 LLM 查询和生成时使用。无论用哪种组合都要提前确认存储目录、输出目录和备份策略。我遇到过团队 wiki 跑了两周一次误操作把存储目录整个删掉结果所有页面和生成记录都丢了。如果当时有 Git 版本库或者定时备份损失会小很多。3.3 权限设计先区分“谁能看”和“谁能改”小团队初期不需要做复杂的角色体系但至少要区分“谁能看”和“谁能改”。只读用户通常是业务人员或外部协作成员他们需要搜索、查看页面内容、使用问答功能。编辑用户负责创建和更新页面。管理员负责目录结构、权限配置和模型参数调整。权限设计还有一个容易被忽略的点谁有权限批量导入文档。批量导入是一个高风险操作因为导入的内容往往没有经过审核格式也不统一。如果所有编辑者都能批量导入知识库质量会很快失序。我的建议是无论团队多小都设置一个“管理员”角色至少保证有人对知识库的整体结构负责。4. 从启动服务到多用户协作团队 wiki 的落地流程4.1 最小可运行版本启动、创建页面、多用户访问我建议把第一次测试拆成三步启动服务、创建第一个页面、多用户访问。第一步是启动服务。确认它能正常加载配置、连接模型、访问存储目录。先不急着灌数据和配置复杂权限只看“能不能跑起来”。第二步是创建第一个页面。输入一个与团队业务相关的主题让 LLM 生成页面内容检查格式是否正确、输出是否完整。这一步能暴露模型通道问题、上下文长度问题和提示词问题。第三步是多用户访问。至少开两个浏览器窗口或两个账号同时访问观察并发行为两个人同时编辑会不会冲突只读用户能不能正常浏览一条错误提示能不能让普通用户看懂不要一上来就把所有历史文档导入。导入过程会暴露大量格式问题也容易因为上下文过长导致生成质量下降。更稳妥的做法是先手工创建几个页面跑通流程再逐步导入存量文档。4.2 目录、命名和负责人让 wiki 内容有结构很多团队知识库项目失败不是因为技术问题而是因为内容本身没有规则。团队 LLM wiki 上线之前最好先把这几件事约定好页面命名规范。比如 API 文档统一叫API-xxx运维手册统一叫运维-xxx项目记录统一叫项目-xxx。这样不但方便人检索也能让向量索引更准确。很多检索错误根源不是模型不好而是页面标题本身含糊。每个知识域至少有一个负责人。负责人不一定亲手编辑所有内容但要对这个领域的页面质量负责。当页面内容过期、冲突、出现明显错误时负责人需要介入处理。页面状态标记。我建议至少保留三种状态草稿、已审核、已过期。LLM 生成的新页面默认进入草稿状态只有负责人确认后才算已审核。已过期的页面不删除但要在顶部标记出来避免误导查询者。这些规则不复杂但不提前说好等内容多起来再补成本会高很多。4.3 页面审核与可信度标记别让 LLM 的“流畅”误导团队LLM 生成的 wiki 内容和人写的文档有一个本质区别它很容易生成“看起来合理但未经确认”的内容。代码示例可能缺少某个前置步骤命令参数可能写错配置项可能在不同版本之间有差异。团队 wiki 必须建立可信度机制。如果页面涉及代码、命令或配置要标注“是否经过验证”最好指明确认过的版本。如果只是知识性内容至少要有来源页面的链接或者写清楚“来自哪次讨论、哪份设计文档”。有条件的话可以设置审核流程LLM 先写草稿负责人审阅后发布。这一步不能省尤其是新成员较多的团队。新人默认 wiki 是可信的一旦里面有错误问题会被迅速放大。5. 多人共同维护时最容易出问题的四个环节5.1 并发写入和版本冲突个人工具不存在并发问题团队 wiki 几乎必然遇到。两个同事同时修改一个页面后保存的人可能覆盖前一个人的内容。选型时就要先确认工具底层有没有版本管理。如果基于 Git出现冲突时通常能看到差异并手动合并如果只是文件存储或普通数据库就要靠系统自己处理冲突。我在实测中比较看重三点是否保留历史版本、是否能看到冲突差异、是否支持恢复。没有版本历史的话一次误操作就可能把整段内容覆盖掉连恢复的机会都没有。注意如果系统不支持版本历史至少要保证每天定时备份存储目录并且让团队成员知道“误删后找谁恢复”。5.2 上下文窗口与长文档处理团队 wiki 的内容会越积累越多页面越来越长。LLM 读取一个超长页面时上下文窗口可能不够用。常见处理思路有两个。一个是写入前切片按标题拆分成小块每块只包含一个完整主题。另一个是检索式读取把相关内容抽出来再送给模型而不是整页塞进去。这两种方式不是切换一个概念而是工程上的取舍。切片会破坏上下文关联检索依赖索引质量。所以很多团队会同时用两种方式短页面直接处理长页面先检索再处理。如果你的 wiki 页面经常有几万字建议先明确工具对页面长度的边界。实测时可以用一个超长页面准备测试看它在什么长度下开始截断、失真或报错。这样比上线后再踩坑好。5.3 检索索引更新滞后团队 wiki 的搜索质量高度依赖索引是否及时更新。新增页面或修改页面后如果索引没有重建用户搜索时就会找不到内容或返回旧版本。这个问题很容易被误判成“模型不行”或“工具坏了”。实际排查时先确认索引状态新增内容有没有触发更新索引更新有没有延迟查询时用的是哪个时间点的索引数据如果团队内容迭代很快建议关注工具的索引更新方式。是全量重建还是增量更新是否需要手动触发这直接影响 wiki 的实时性和维护成本。5.4 内容安全和敏感信息不同团队对同一个 wiki 的权限应该不同但无论权限怎么设都不要把敏感信息直接写进 wiki。如果 wiki 的存储内容会进入 LLM 调用的输入链路那么任何被纳入检索的文本都可能被发送给模型。涉及密钥、密码、内部账号和未公开数据时要提前清理或脱敏。我建议团队内部做一个简单约定wiki 里只写“处理后的信息”也就是去掉敏感字段后的通用方案。确实需要记录敏感参数时放链接或密文不直接贴原文。这个问题等出事后处理会非常麻烦提前约定成本反而很低。6. 判断 wiki 是否真的有用指标、边界和排查顺序6.1 先给 wiki 定边界别让它变成“全知垃圾桶”团队 wiki 最容易出现的情况是“什么都往里放”。代码文档、会议纪要、需求说明、运维日志、个人备忘、行业资料全部堆在一起很快就无法检索了。我建议初期限制主题范围。比如只放技术方案、接口文档和常见问题其他内容先不进 wiki。等检索质量稳定了再逐步扩展开放。这样做有几个好处目录清晰、索引容易建立、LLM 生成内容时不容易被无关信息干扰。边界还包括页面长度。不要让一个页面承载所有内容。如果页面已经很长考虑拆分成“总览页”和“细节页”。总览页用 LLM 生成摘要和链接细节页单独维护。这会让 wiki 的整体结构更接近真实的知识库而不是一堆长文堆叠。6.2 用四个指标判断 wiki 是否真的有用很多人不知道如何判断 wiki 有没有价值。我常用四个指标搜索命中率。团队成员用 wiki 搜索问题时能否一次找到正确页面。搜索命中率低先看命名规范再看索引更新是否及时。内容过期率。多少页面超过 30 天没有被更新或标记过期。如果过高说明缺少负责人和更新提醒不是模型能力问题。新成员上手时间。新同事能否通过 wiki 独立完成基础问题查询而不需要反复问老同事。这个指标很直观也很能说明 wiki 的整理质量。编辑参与度。除了负责人之外有多少人在实际贡献内容。如果只有一个人维护说明 wiki 还没有形成团队协作的循环。这些指标不需要专门做系统定期手动统计也能看出趋势。我一般建议每两周快速看一眼。6.3 常见问题排查顺序如果 wiki 出现“内容找不到、生成质量差、多人编辑冲突、页面空白”等问题我建议按这个顺序排查不要一上来就怀疑工具本身。第一步看输入。查询关键词、页面标题、导入的文件格式是否合规。很多搜索不到的问题源头是命名太随意。第二步看索引。新增内容有没有触发索引更新检索用的是哪个版本的数据。第三步看模型通道。API key 是否有效、额度是否够用、模型版本是否支持预期功能、上下文长度是否够用、超时时间是否合理。第四步看存储。数据库或文件目录是否完整历史版本是否保留备份任务是否正常运行。第五步看权限和并发。是不是用户没有修改权限是不是多人同时编辑导致内容被覆盖错误日志里有没有明确记录。注意很多所谓“工具出 bug”的情况最后查出来都是模型配置、权限或数据格式问题。尤其是导入的 Markdown 文件编码不统一、存储目录无写权限、模型 API 超时最容易被误判成功能损坏。踩过几次之后我发现Stigmergy 这类面向团队的 LLM wiki真正难的不是模型调用也不是 wiki 本身而是让团队形成一种“通过知识库间接协作”的习惯。Karpathy 提出的 LLM wiki 范式把内容维护成本降到可以接受的范围但一个团队要真正受益还需要有人制定命名规范、有人审核生成结果、有人定期处理过期内容。LLM 能生成页面、能整理结构、能回答问题但谁来审核、谁来更新、什么内容值得留仍然需要人决定。如果你正打算在团队里引入这类工具我个人的建议是先把单用户跑稳再小范围放给 3 到 5 人试用最后再全员推开。这个节奏虽然慢一点但会省掉后面大量返工也能让你更早看清它到底适不适合你们团队。