Devin 现在会自动为你的代码库建立索引，并生成包含架构图、源码链接和代码库摘要的 Wiki 文档。
使用它来快速上手你在代码库中尚不熟悉的部分——可在侧边栏中查看。
Ask Devin 会使用 Wiki 中的信息，更好地理解并定位你代码库中的相关上下文。
在入门流程中接入代码仓库时，DeepWiki 会自动生成。
.devin/wiki.json 文件允许你控制 Devin 的默认 wiki 生成行为，这对可能达到内置限制的大型代码库尤为重要。
在生成 wiki 时，如果在代码库的根目录中发现 .devin/wiki.json 文件，我们会使用其中提供的 repo_notes 和 pages 来引导 wiki 的生成。如果提供了 pages，我们会跳过默认的基于聚类的规划，严格按照你指定的页面进行创建。这样一来，即使自动系统原本会跳过某些内容，你的代码库中重要的部分也能有相应的文档记录。
在仓库根目录中创建一个 .devin/wiki.json 文件，结构如下：
{
"repo_notes": [
{
"content": "此代码仓库的 cui/ 文件夹包含主要 UI 组件,在编写文档时应优先处理",
"author": "Team Lead"
}
],
"pages": [
{
"title": "CUI 组件概览",
"purpose": "记录 cui/ 文件夹结构和主要 UI 组件",
"parent": null
},
{
"title": "身份验证系统",
"purpose": "记录身份验证流程和相关组件",
"parent": null
},
{
"title": "登录组件",
"purpose": "登录相关 UI 组件的详细文档",
"parent": "身份验证系统"
}
]
}
repo_notes (数组)
为文档系统提供上下文和指引，帮助其更好地理解你的代码仓库。
- content (字符串，必填)：笔记内容（最多 10,000 个字符）
- author (字符串，可选)：笔记作者
指定在你的 wiki 中应创建的具体页面。
此字段为可选项。即使你只提供 repo_notes，系统仍会生成 wiki，并使用你的备注来引导结构与侧重点，而无需你逐一列出每个页面。
当你提供 pages 时，它们会被视为明确指令。系统只会生成你在 JSON 中定义的那些页面，不多也不少。
- title（字符串，必填）：页面标题（必须唯一且非空）
- purpose（字符串，必填）：该页面应当记录/说明的内容
- parent（字符串，可选）：用于层级组织的父页面标题
- page_notes（数组，可选）：该页面特有的补充备注
- 最多 30 个页面（企业版为 80 个）
- 笔记总数最多 100 条（repo_notes 与所有 page_notes 之和）
- 每条笔记最多 10,000 个字符
- 页面标题必须唯一且不能为空
示例 1：使用 Repo Notes 引导 Wiki 生成
{
"repo_notes": [
{
"content": "该代码仓库包含三个主要部分:frontend/ 目录存放 React 组件,backend/ 目录存放 API 服务,infra/ 目录存放部署脚本。文档应着重说明这些部分之间的交互方式,并将后端 API 层作为最高优先级进行重点阐述。"
}
]
}
{
"repo_notes": [
{
"content": "cui/ 文件夹包含需要编写文档的关键 UI 组件。backend/ 文件夹包含主要的 API 逻辑。utils/ 文件夹包含在整个代码库中使用的共享工具函数。"
}
]
}
{
"repo_notes": [
{
"content": "testing/ 目录包含开发人员需要掌握的重要测试工具和模式。scripts/ 目录包含对运维操作至关重要的部署和维护脚本。"
}
]
}
{
"repo_notes": [
{
"content": "这是一个全栈应用程序,包含独立的前端、后端和共享组件,应分别编写文档但需明确各部分之间的关联关系。"
}
],
"pages": [
{
"title": "架构概览",
"purpose": "应用程序架构及组件交互方式的高层概述"
},
{
"title": "前端",
"purpose": "前端应用程序结构和组件",
"parent": "架构概览"
},
{
"title": "React 组件",
"purpose": "React 组件的详细文档,包括其 props 和使用方法",
"parent": "前端"
},
{
"title": "状态管理",
"purpose": "应用程序状态的管理方式,包括 store 和数据流",
"parent": "前端"
},
{
"title": "后端",
"purpose": "后端服务、API 和数据层",
"parent": "架构概览"
},
{
"title": "API 端点",
"purpose": "REST API 文档,包括端点、请求/响应格式",
"parent": "后端"
}
]
}
- 提供代码库中哪些部分最重要的背景信息
- 指出需要优先关注的特定文件夹或组件
- 说明系统各个部分之间的关系
- 从概览性页面入手
- 使用父子页面关系构建清晰的层级结构
- 将相关功能分组放在一起
- 清晰说明每个页面应当说明的内容
- 指明需要重点关注的具体目录、文件或概念
- 提供足够的细节，以便系统理解你的意图
- 如果你知道代码库中的某些部分被遗漏了，请明确地将它们包含进去
- 使用清晰且具有描述性的标题，让需要覆盖的内容一目了然
”只有部分文件夹被收录进文档中”
这是典型的大型代码仓库问题。
解决方案： 使用 .devin/wiki.json 明确指定代码库中哪些部分需要生成文档。
先只更新 repo_notes，并基于这些新增的上下文重新生成 wiki，查看更新后的 wiki 是否包含之前遗漏的文件夹。仅在必要时再添加 pages 数组。
“Wiki 中缺少重要组件”
为这些组件添加独立页面，并使用 repo_notes 强调它们的重要性。
请记住：DeepWiki 只会生成此数组中包含的页面，因此要确保该数组中包含所有页面，而不仅仅是缺失的那个页面。
{
"repo_notes": [
{
"content": "[missing-component] 目录对应用程序至关重要，必须详细记录文档。"
}
],
"pages": [
{
"title": "关键组件名称",
"purpose": "记录 [missing-component] 目录及其功能"
}
]
}
- 在代码库根目录创建
.devin/wiki.json
- 添加 repo_notes，说明代码库结构和优先级
- 如有必要，明确列出你希望创建的所有页面，并为其提供清晰的标题和用途说明
- 提交该文件并重新生成你的 wiki
系统现在会根据你的明确指示，而不是完全依赖自动分析来创建文档，从而为大型代码仓库提供更全面、更准确的文档覆盖。 