AI实用工具:OpenWiki自动生成项目Wiki,testai测试AI原生代码

2026-07-03

今天两个工具分别卡在 AI 编码工作流的入口和出口——一个在你写代码之前就让 Agent 看懂项目全貌，一个在你写完 Skill/MCP/Agent 之后验证它真的能用。文档和测试，恰好是 AI 辅助开发中最容易被跳过的两环。

OpenWiki — LangChain 官方出品，自动为代码库生成并维护一份 Agent 能读懂的 Wiki

让 AI 编码 Agent 理解一个陌生代码库，目前主流做法是让它自己读文件、跑 grep、慢慢摸索。这消耗大量 token，而且每次新会话都要重来一遍。另一种做法是人手动写 CLAUDE.md 或 AGENTS.md，但文档和代码同步是个永恒的工程难题——代码昨天改了，文档还停留在上周。

OpenWiki 的解法是把这件事变成自动化的后台任务。openwiki --init 扫描你的整个仓库，用 LLM 分析代码结构、模块职责、数据流和依赖关系，生成结构化的 Wiki 文档写入 openwiki/ 目录。然后它自动在你的 CLAUDE.md 或 AGENTS.md 末尾追加一段引用指令，告诉 AI Agent「需要了解项目上下文时，先去读 openwiki/ 目录」。Agent 以后每次需要理解项目结构时，先读 Wiki 而不是从头扫描代码——token 消耗大幅下降。

更关键的是持续更新机制。拷贝项目提供的 GitHub Action 模板（openwiki-update.yml）到 .github/workflows/，之后每天自动跑一次：拉取上次运行以来的 git diff，分析哪些代码变了，只更新受影响的 Wiki 页面，开一个 PR 等人审核合并。文档不会过时，人不需要记住去更新它。

模型选择很灵活。默认支持 OpenRouter、Fireworks、Baseten、OpenAI 和 Anthropic 五家 provider，预置了 GLM 5.2、Kimi K2.6、Sonnet 5 等模型。也可以自定义模型 ID，用内部部署的模型跑，代码不离开你的环境。LangSmith 追踪是可选的，开了就能在 LangSmith 里看到每次 Wiki 生成和更新的完整 trace。

OpenWiki 不替代 CLAUDE.md 或 AGENTS.md——它和它们是协作关系。CLAUDE.md 里放的是项目级的编码规范和上下文规则（怎么跑测试、用什么包管理器、命名约定），OpenWiki 生成的 Wiki 放的是代码库的结构性知识（模块职责、数据流、API 契约、架构决策）。Agent 先读 CLAUDE.md 了解规则，再读 Wiki 了解结构，两条路径互补。

# 一行安装
npm install -g openwiki

# 初始化——选择模型 provider、填 API key，然后自动生成文档
openwiki --init

# 手动更新
openwiki --update

# 单次非交互运行
openwiki -p "为 src/api/ 目录补充 API 契约文档"

# 保持自动更新：拷贝 openwiki-update.yml 到 .github/workflows/

同类工具对比

OpenWiki（推荐）

文档生成方式：LLM 扫描代码库生成结构化 Wiki

自动更新：GitHub Action 每日自动 PR

Agent 集成：自动注入 CLAUDE.md

自托管/本地：本地跑，支持多 provider

热度：1,129 stars

Mintlify Writer

文档生成方式：IDE 插件，AI 生成函数级文档注释

自动更新：不支持

Agent 集成：不支持

热度：2.5K stars

docsgpt

文档生成方式：RAG 问答，把代码库变成可对话的知识库

自动更新：不支持

Agent 集成：部分（MCP）

热度：较新

手写 CLAUDE.md

文档生成方式：人手动维护

自动更新：不支持

Agent 集成：支持

热度：N/A

OpenWiki 和 Mintlify、docsgpt 解决的是不同问题。Mintlify 生成的是函数级注释（JSDoc/Docstring），不涉及架构和模块关系。docsgpt 把代码库变成可对话的知识库，但没有自动更新机制。OpenWiki 是三者中唯一一个「生成 + 自动更新 + Agent 集成」全链条覆盖的方案。如果你想让 AI Agent 在每次新会话中都对你的项目有一个准确的全局认知，而不用每次都从头读代码，这是目前最短的路径。

1,129 stars · MIT License · v1.x · LangChain 官方 · github.com/langchain-ai/openwiki

testai — 测试 AI-native 代码：你的 Skill、MCP Server、Agent 真的能跑吗

传统测试框架（pytest、Jest、Vitest）测试的是确定性的输入→输出：给函数传参数，断言返回值。但 AI-native 代码完全不同——你的 Skill 文件写的是 prompt 指令而非代码逻辑，MCP Server 暴露的是工具列表而非 API 端点，Agent 的行为取决于模型推理而非程序分支。拿 pytest 测试一个 Claude Code Skill？你不知道该 assert 什么。

testai 是专门为这类场景设计的测试框架。它提供三层抽象：TestAI.createTestingEnv 创建一个隔离的测试环境，createProject 生成带真实文件结构的 fixture 项目（React、Nuxt、FastAPI 等预设模板），createMcp 创建可追踪的 MCP 桩——模拟 Slack、Datadog、Figma、Linear 等外部服务的 MCP 响应，并断言 Agent 是否调用了正确的工具、传了正确的参数。框架无关，支持 Vitest、Jest 和 Node test runner。

一个典型的使用场景：你写了一个 /review-pr Skill，它应该先读 PR diff、调用 GitHub MCP 获取文件内容、用 Context7 核查第三方 API 用法、最后生成审查报告。传统测试只能测"这个函数是否返回了正确的字符串"。testai 可以模拟一个完整的 PR 场景——注入假 diff、用 MCP stub 返回模拟的文件内容和 Context7 文档、跑 Agent、然后断言 Agent 调用了哪些 MCP 工具、调用顺序是否正确、最终输出是否包含必要的审查维度。

MCP stub 是 testai 最独特的特性。@testingai/mcp-slack、@testingai/mcp-datadog 等预设 stub 允许你模拟外部服务的工具调用，并精确断言 slack_send_message 被调用了几次、发了什么内容、发到了哪个频道。这对测试依赖外部 MCP 的 Agent 工作流至关重要——不需要真实的 Slack workspace 就能验证通知逻辑。

# 安装核心
npm install -D @testingai/testai

# 安装 MCP stubs（按需）
npm install -D @testingai/mcp-slack @testingai/mcp-datadog

# 安装预设项目模板
npm install -D @testingai/pkg-react @testingai/pkg-fastapi