跳转至

Karpathy LLM Wiki 操作系统

这套东西到底是什么

Karpathy LLM Wiki 不是一个提示词，也不是一个 AGENTS.md。

它是一套把团队讨论、原始资料和 Agent 输出持续编译成知识库的操作系统：

raw materials
  -> Agent ingest
  -> compiled wiki
  -> index / log
  -> human review
  -> publish
  -> next discussion

AGENTS.md 只是规则入口。真正起作用的是目录结构、原始资料、编译页、索引、日志、检查脚本和团队持续使用。

自试用：开发项目就是运行项目

OrgReOrg / Harness 的开发过程本身要按这套方法运转。团队成员给 Agent 丢资料、分享观点、质疑方案、要求实验或指出流程问题时，不只是临时聊天上下文，也是知识库输入、产品验证样例和下一轮迭代素材。

因此每轮有价值输入都应进入同一条链路：

用户资料/观点/问题
  -> Evidence inbox/raw
  -> Knowledge wiki/project/ADR
  -> Site 或实验代码
  -> 测试与复盘
  -> 产品改进项

如果这条链路在实际使用中暴露了找不到资料、重复记录、口径冲突、人工整理成本高、发布不及时或 review 堵塞等问题，这些问题本身就应该进入 Harness 的开发计划。也就是说，我们不是先把产品做完再使用，而是在使用中持续暴露问题、沉淀知识、修正产品。

当前仓库已经实现了什么

workspaces/variai/evidence/inbox/
  临时想法、群聊摘要、会议纪要、Agent 初稿

workspaces/variai/evidence/raw/
  原始资料和参考文献，尽量不改写

workspaces/variai/knowledge/wiki/
  Agent 编译后的稳定知识页

workspaces/variai/knowledge/projects/
  项目、场景、客户、方案工作区

workspaces/variai/knowledge/decisions/
  关键判断和 ADR

workspaces/variai/site/
  MkDocs 发布站点源码

workspaces/variai/outputs/
  实验报告、demo 输出和群内分享文案

workspaces/variai/knowledge/system/
  Agent 规则、索引、日志、模板

scripts/vault_lint.py
  结构健康检查

mkdocs.yml
  Site 导航和构建配置

第一批 seed 已经进入工作空间

这不是空架子。第一批 seed 已经形成：

  • workspaces/variai/evidence/inbox/2026-06-10-team-collaboration-seed.md
  • workspaces/variai/evidence/raw/2026-06-10-karpathy-llm-wiki-reference.md
  • workspaces/variai/knowledge/wiki/Karpathy-LLM-Wiki-团队知识库方法.md
  • workspaces/variai/knowledge/wiki/Agent-原生团队协作模式.md
  • workspaces/variai/knowledge/decisions/ADR-001-采用-Karpathy-LLM-Wiki-作为团队知识库方法.md
  • workspaces/variai/evidence/inbox/团队成员首条分享消息.md

它们展示了完整链路：

讨论 seed
  -> raw reference
  -> wiki 页面
  -> ADR
  -> 对外/对群分享输出

四个核心动作

1. Capture

把有价值的讨论、链接、会议纪要和 Agent 输出放入 workspaces/variai/evidence/inbox/。

短期可以人工复制。长期应该通过飞书群/企业微信群 Agent bot 自动完成。

2. Ingest / Compile

Agent 把 inbox/raw 编译成：

  • workspaces/variai/knowledge/wiki/：稳定知识页。
  • workspaces/variai/knowledge/projects/：项目和场景页。
  • workspaces/variai/knowledge/decisions/：关键决策。

3. Lint

运行：

python scripts/vault_lint.py

检查：

  • 目录结构是否完整。
  • 是否有潜在密钥。
  • wiki 页是否有基本结构。
  • ADR 是否有背景、决策、理由、影响。
  • inbox 是否堆积过多。

4. Publish

成熟内容发布到 workspaces/variai/site/，然后 Cloudflare 自动更新网站。

本地站点局部快查：

uv run mkdocs build --strict

提交 PR 前跑 bash scripts/ci_check.sh（与 CI 同一套门禁），全绿即就绪；uv run mkdocs build --strict 只是站点局部快查，不能替代完整门禁。

ChatOps 是下一步关键

如果继续靠人工截图微信群，知识库会很快变成新负担。

长期应该迁移到：

  • 飞书群，或
  • 企业微信群。

然后通过 Agent bot 自动整理讨论过程：

群聊消息
  -> bot 摘要、聚类、提取待办和决策
  -> 写入 workspaces/variai/evidence/inbox
  -> 自动 PR
  -> 人工 review

这会让团队知识库真正变成“组织记忆系统”，而不是手工文档库。

团队成员怎么用

  1. clone 仓库。
  2. 用 Obsidian 打开 workspaces/variai/knowledge/。
  3. 用 Codex 或 Claude Code 打开仓库根目录。
  4. 让 Agent 读取：
AGENTS.md
workspaces/variai/knowledge/system/AGENTS.md
  1. 对 Agent 发任务：
把 workspaces/variai/evidence/inbox 里的新内容编译成 Knowledge wiki 和 ADR。

或：

检查 Evidence / Knowledge 健康度，修复缺少索引和来源的问题。

或：

把成熟的 wiki 页面发布到 Site，并跑构建验证。

成功标准

这套系统跑起来后，应该看到：

  • 群聊里的关键讨论不再丢失。
  • 每周都有 inbox 被编译成 wiki。
  • 重要判断都能追溯到 ADR。
  • 新成员可以通过网站和 vault 快速理解团队共识。
  • Agent 能独立完成大部分整理、索引、发布和检查工作。
  • 团队知识不是散落在聊天记录里，而是沉淀成可复用资产。

当前边界

第一阶段不强求：

  • 实时多人编辑。
  • Obsidian Sync。
  • 完整 MCP。
  • 自动读取微信群。
  • 完全无人审查自动发布。

第一阶段先跑通：

GitHub + Obsidian vault + Agent + MkDocs/Cloudflare

等流程稳定后，再开发 skills、MCP、群聊 bot 和自动 PR。