老实说，感觉这可能是我一直缺失的拼图 https://t.co/imW1SpuDGe

---

Grok-Wiki - 由本地智能体驱动的代码仓库维基

来源：https://grok-wiki.com/ 第01集 / 桌面应用

什么是 Grok-Wiki？

一段关于桌面闭环的简短产品影片：基于源码的代码仓库上下文、本地 CLI 智能体，以及随行的模型访问权限。

本地 CLI 优先的桌面应用

维基、问答、文档和任务，由你的本地智能体驱动。

将 Grok-Wiki 指向一个代码仓库或文件夹。它会准备上下文、流式传输基于源码的进度，并将每个模型调用转交给你已登录的 CLI。

项目 开始。维基 理解。问答 质询。文档 参考。任务 运行。

命令 1 到 5。包含终端。

桌面应用约定本地优先

你的资料库存储在你的机器上

维基、问答、文档和任务运行结果保存到本地资料库。发布到公共资料库是一个有意为之的点击操作，而非默认行为。

存储在磁盘

模型访问权限由 CLI 持有

Grok CLI、Codex CLI、Claude Code、Pi 和 Antigravity 通过其自身工具进行身份验证。Grok-Wiki 从不持有密钥。

由 CLI 持有

遥测数据具有有效载荷边界

可选的使用信号不包含提示、答案、代码、路径、密钥和运行日志。

无有效载荷

任务 捕获工作，然后使用本地智能体运行它

任务

捕获工作，然后在终端中使用本地智能体运行它。

待办2 史诗级任务1/3 优化认证流程stablyai/orca 来自问答

为 v2 配置编写迁移指南twentyhq/twenty

就绪1 为文档阅读器添加错误状态timescale/tigerfs

进行中1 记录工作树的生命周期stablyai/orca

运行中

完成1 绘制 GraphQL 模式图twentyhq/twenty

3个文件，+120-14

项目

你指向 Grok-Wiki 的所有代码仓库和文件夹，集中展示。

共3个

Orca 开发者参考手册2天前 工作树如何清理？3小时前

Twenty CRM 开发者参考手册5天前 模式引擎位于何处？1天前

生成代码仓库维基。

添加一个或多个 GitHub 仓库、URL 或本地路径。生成的页面和源码证据将显示在下方的资料库中。

描述你想要的维基。例如：聚焦认证流程并分解技术栈。

stablyai/orcamain添加另一个仓库或路径

Grok CLI

搜索维基

3个已保存的维基

跨代码仓库问答。

添加一个或多个 GitHub 仓库、URL 或本地路径。在运行开始后，来源和活动将显示。

同步引擎如何解决冲突？

twentyhq/twentymain添加 GitHub 仓库、URL 或本地路径

Grok CLI开始提问

第1个问题，共3个

答案应该深入到哪里？

提示·输入 / 选择复合工程视角或附加维基上下文。

生成代码仓库文档。

将一个 GitHub 仓库、URL 或本地文件夹转换为包含快速入门、指南、参考、示例和源码证据的文档网站结构。

代码仓库 URL 或本地文件夹

格式文档指南·参考·故障排除Grok CLI

终端

项目、工作树和本地智能体外壳集中在一个轨道中。

记录工作树生命周期 - 工作中

工作中·记录工作树生命周期stablyai/orca

✓ 已从 stablyai/orca (main) 准备好工作区
✓ 读取 src/worktrees 下的 14 个文件
● 正在撰写 docs/worktree-lifecycle.md
● 添加生命周期图

项目轨道将每个外壳和智能体会话保持在其所属的代码仓库下。

选择持有模型访问权限的 CLI。

桌面应用是本地 CLI 优先的。每个智能体通过其自身工具登录并拥有模型访问权限。

桌面应用的可交互迷你模型。点击侧边栏浏览。

代码仓库记忆

上下文紧贴工作。

Grok-Wiki 将过去的运行、源码轨迹和生成的文档转化为你的智能体可以实际读取的本地工作区。

源码轨迹本地运行文档归档

工作流

生成、问答和索引代码仓库。

启动一个维基、问一个问题或添加一个 GitHub 仓库。Grok-Wiki 保持运行、来源和选定的本地 CLI 可见。

维基运行选定的本地智能体

运行中AsyncFuncAI/grok-wiki

本地优先

01 读取代码仓库解析文件和源码范围

完成

02 草拟大纲根据证据构建页面树

进行中

03 撰写页面仅修补活动运行监控器

进行中

04 附加来源链接确切的文件和行

下一步

无需移动桌面即可生成维基。

运行监控器原地推进，同时侧边栏、阅读器、撰写器和选定的本地智能体保持稳定。

问答附加了代码仓库上下文

AsyncFuncAI/grok-wiki

主要入口点是什么？

已工作6秒

扫描代码仓库结构 发现桌面、公共和 API 入口表面。

读取 package 脚本 匹配了本地 web 和 desktop 命令。

检查源码证据 准备基于文件的答案引用。

正在深入代码仓库思考…活动步骤流式传输，无需重新挂载撰写器。

向代码仓库提问并保持来源可见。

答案与证据图谱并列流式传输，因此主张与文件保持关联，而非脱节的聊天记录。

github.com/AsyncFuncAI/AsyncReview 从 GitHub 索引

按下代码仓库上的快捷键开始索引。

Cmd + Shift + Space 将活动的 GitHub 仓库或本地文件夹转化为源码上下文，而不更改提供者所有权。

代码图谱

生产级代码仓库上下文。

随着代码库增长，每次问答、维基和文档运行都应保持简单。代码图谱是缺失的一层，它将重新发现排除在关键路径之外。

智能体非常擅长对代码进行推理。困难之处在于让它们停止重新学习所有东西的位置。代码图谱为每次新运行提供可复用的结构和源码证据图谱，因此你已选择的模型将精力用于综合，而非寻宝。

没有代码图谱维基运行重新发现无地图

慢路径

01 列出目录树遍历目录以获取项目形态

进行中

02 猜测入口点README、清单文件、主文件

下一步

03 重建关系逐文件追踪导入

排队中

04 规划大纲在昂贵的发现之后构建结构

排队中

模型预算花费在寻找架构上。

有代码图谱维基运行代码图谱就绪。图谱已附加

快路径

01 附加图谱模块和热点随运行一起到达

进行中

02 从结构规划一次遍历真实的入口点

下一步

03 撰写页面每个页面从更接近系统的地方开始

排队中

模型预算花费在解释架构上。

数据有什么变化。

并列展示人们实际感受到的成本：发现轮次、模型预算花费在何处、多少个表面共享上下文，以及索引的首次运行成本。

说明性·中等规模单体仓库

指标没有代码图谱有代码图谱

每次运行的发现轮次用于定位文件和重建形态的智能体步骤

8-14每次问答、维基或文档运行都进行冷遍历

1-3附加图谱，然后规划和撰写

用于导航的模型预算运行中用于搜索与综合的比例

*~65%*大部分花费用于搜索、打开、重新追踪

*~15%*大部分花费用于解释和文档

共享上下文的表面首次索引后的问答、维基和文档

0 / 3每个表面单独重新发现

3 / 3一个图谱在多个工作流中复用

首次运行设置成本首次获得有用答案前的额外工作

0无索引。立即开始探索。

*1×*每个代码仓库进行一次简短索引

后续运行的重新发现成本代码仓库已知后的重复成本

每次运行从头重建结构

接近零复用图谱；仅在需要时重新索引

没有代码图谱·权衡取舍

• 零设置。小型代码仓库和一次性问题保持轻量。
• 每次严肃的运行都需再次发现，包括需要相同图谱的第三个表面。
• 证据到达较晚，因此在智能体仍在搜索时，主张较难验证。

有代码图谱·权衡取舍

• 代码仓库的首次使用需要一次简短的索引过程，然后图谱才就绪。
• 后续的问答、维基和文档运行在导航上花费更少，在有用输出上花费更多。
• 设计上可选。关闭它，Grok-Wiki 将返回本地探索，而不会删除你的工作。

当理解代码仓库是任务时启用它。

代码图谱是可选的代码仓库智能，而非另一个模型。对于小型或一次性问题保持关闭。当重新发现成为问答、维基和文档中昂贵的部分时启用它。

设置 › 代码图谱 › 启用

公共资料库

共享文档、维基和 Obsidian 压缩包。

浏览生成的文档和公共维基，或下载适用于 Obsidian 的 Markdown 压缩包。

文档阅读器生成的页面可以浏览、共享或导出为 Markdown 知识库。

/public/docs/:id

本地 CLI 设置

安装一个本地智能体，通过其 CLI 进行身份验证，并在生成前重新检查就绪状态。

卡片链接生成的页面。

代码组显示引用的示例。

步骤保留设置流程。

更新跟踪操作手册变更。

路线图已发布的 HTML、智能体 Markdown 和知识库导出保持分离。

公共资料库 (https://grok-wiki.com/public/wikis)

公共资料库/public/wikis

文档画廊/public/docs

维基阅读器/public/wiki/:id

文档阅读器/public/docs/:id

Obsidian 压缩包/api/wiki/export.zip?id=:wiki

智能体 Markdown/:surface/:id/llms.txt

剧集/episodes

更新日志/changelog

公共维基交接

一键将公共维基转化为智能体上下文。

在公共 Grok-Wiki 页面上使用“添加智能体”，将你选定的本地智能体指向维基的源码支持上下文。当你想将知识放入本地知识库时，将相同的页面导出为 Obsidian 压缩包。

添加智能体智能体 Markdown Obsidian 压缩包

发布的页面对人类、本地智能体和知识库导出都有用，同时无需将模型访问权限从你拥有的 CLI 帐户移开。

用户评价

Grok-Wiki 用户如是说。

开发者们正在使用 Grok-Wiki 来理解代码仓库、共享基于源码的文档，并将本地智能体运行转化为其他人实际可读的内容。

在 X 上查看 (https://x.com/search?q=Grok-Wiki&src=typed_query)

“Sheing 真棒，绝对值得关注/关注。现在试用 Grok-Wiki。” Kevin Rose 的一位创始人信号，Digg.com 被突出显示为现实世界的 Grok-Wiki 用例。(https://x.com/kevinrose/status/2055846360000418110) Neil Parker @nwparker_ / Orca

X

“现在我们得重写整个东西来让你保持警觉！”

Orca 在看到 Grok-Wiki 实际运行后的实用开发者反应。

Gabe Perez LinkedIn

LinkedIn

“结构映射实际上捕捉到了我忘记存在的依赖关系。”

在一个 5 万行代码的仓库上尝试了 Grok-Wiki，并深入探讨了智能体如何处理竞争的重要性信号。

Matt Van Horn @mvanhorn

X

“喜欢你的工作”

一位注重产品的开发者的简洁 X 认可。

“太棒了，继续发布”

来自 Grok-Wiki 发布线程的简短公开信号。

“太疯狂了，Sheing 和 Grok-Wiki 火了”

合并到一个卡片中，包含两个公开帖子，包括 Warp 仓库备注。

“这可能是我新喜欢的工具。”

在一个曾经半坏并被废弃的喜欢的工具上第二次使用了 Grok-Wiki。

常见问题解答

常见问题解答

关于使用 Grok-Wiki 的一切。还有问题？联系我们。(https://calendly.com/asyncfunc/grok-wiki-onboarding)

为什么使用 Grok-Wiki 而不是直接使用 Codex、Claude Code、Grok 或 ChatGPT？Grok-Wiki 并非试图取代你的智能体。它准备代码仓库上下文，运行你已使用的本地 CLI 智能体，然后将调查转化为基于源码的维基、文档、问答会话和公共交接页面。智能体负责执行工作；Grok-Wiki 为其提供持久的结构、引用，以及其他智能体稍后可以读取的工作区。

我的数据存储在哪里？桌面应用运行一个本地回环服务器，并将数据存储在应用数据目录下。你的本地智能体凭据保留在其自身的 CLI 工具中。公共维基页面是单独的只读副本，仅在你发布时存在。

Grok-Wiki 如何保持维基基于源码？每次运行都从代码仓库本身开始，根据其读取的文件构建结构，并将源码轨迹附加到生成的页面和问答答案上。结果比聊天记录更易于检查，因为有用的主张被打包回可导航的文档中。

Grok-Wiki 除了生成维基还能做什么？是的。它可以生成代码仓库维基和文档，基于源码证据回答问题，保留运行历史，发布只读页面，暴露智能体可读的 Markdown，并导出 Obsidian 就绪的压缩包。目的是将一次调查转化为可复用的代码仓库记忆，而非另一次用完即弃的聊天。

Grok-Wiki 能否用于私有仓库、本地文件夹或我自己的云？桌面和 CLI 流程专为本地优先工作设计，你的认证工具和文件系统拥有访问权限。对于托管部署，该架构保持存储和提供者凭据可配置，以便团队在产品扩展时可以使用自己的认证、数据库和基础设施选择。

当我发布维基时会发生什么？发布会创建一个单独的只读页面，你可以与队友、用户或其他智能体共享。它不会将原始工作区转变为公共编辑界面；重新生成、问答和应用控件仍保留在你本地或已认证的工作区中。

在维基生成后，其他智能体能否使用 Grok-Wiki 页面？是的。发布的维基通过公共页面和 Markdown 界面暴露智能体可读的上下文，因此智能体可以从生成的结构开始，而不是从头开始重新读取代码仓库。

哪些类型的代码仓库适合使用？当代码库的表面积足够大，README 不够用时，Grok-Wiki 最有用：架构交接、新人入门、遗留系统、SDK、CLI、内部工具，以及基于源码的解释比简短摘要更重要的项目。

Diogo Almeida (@CompleteSkeptic)： 在共同发明 ChatGPT 之后，我不断问自己：为什么超人的聊天模型没有导致通用人工智能？

我过去两年一直在秘密研发一种新的模型训练方式（RLCD），以及一种新型的前沿 AI 模型，我们今天发布：Jev

• 20-200倍更快 • 40-400倍