不建议把主要技术文档整体搬到 GitHub Wiki。

如果你的目标是“文档经常改，而且希望 AI/本地开发都能直接读取”，更合适的做法通常是：

1. 把“会影响代码开发、排障、架构理解”的文档继续留在仓库里，比如 `docs/`。
2. 把“团队协作型、轻流程、非强耦合”的说明放到 Wiki 或外部知识库。
3. 如果嫌每次改文档都提 PR 太重，就单独降低文档变更门槛，而不是先把文档移走。

原因很直接：

- 放在仓库里，AI、本地脚本、grep、索引、RAG 都最好处理。
- 放到 GitHub Wiki 后，本质上是另一个 Git 仓库，不在当前工作区内，默认本地 AI 读不到。
- Wiki 适合“给人看”，不适合“和代码一起演进、被工具稳定消费”。

你这两个问题可以分别看。

**1. 要不要放 GitHub Wiki**

通常只建议把这类内容放 Wiki：

- 贡献流程
- 值班手册
- 团队约定
- 低耦合 FAQ
- 不要求和代码版本严格对应的知识

通常不建议放 Wiki 的内容：

- 架构设计
- API 约定
- 部署/排障手册
- MCP/Agent 配置说明
- 与当前代码强绑定的业务文档
- AI 分析时需要直接引用的知识

因为这些内容最好和代码同版本管理。否则会出现：

- 文档讲的是新逻辑，但本地 checkout 的是旧代码
- AI 在本地分析代码时拿不到 Wiki 内容
- 搜索、引用、审查链路被拆开

**更实际的方案**：保留 `docs/`，但降低文档 PR 成本。

比如：

- 文档单独目录，允许轻量 reviewer
- 文档 PR 允许 owner 之外的人直接 merge
- 对纯文档改动跳过重 CI
- 把频繁更新的运行手册拆到 `docs/runbooks/`
- 把临时知识放 `docs/notes/`，定期整理

**2. 如果放 Wiki，AI 怎么顺利在本地读到**

如果你确实想用 Wiki，最好做“镜像到本地”，不要只依赖线上 Wiki。

可行方案有 3 个，按实用性排序：

**方案 A：仓库内保留 `docs/` 作为 AI 主数据源，Wiki 只是发布副本**
最稳。

- 开发和 AI 读取都用仓库里的 `docs/`
- 对外展示或团队浏览用 Wiki
- 用脚本把 `docs/` 同步到 Wiki 仓库

优点：

- AI 本地可直接读
- 不破坏现有开发流程
- Wiki 只承担展示角色

**方案 B：把 GitHub Wiki 当成独立 Git repo，拉到工作区里**
GitHub Wiki 实际可 clone，例如：

```bash
git clone https://github.com/<org>/<repo>.wiki.git .wiki
```

然后：

- 在主仓库里加一个同步脚本
- 本地 AI 读取 `.wiki/` 目录
- 需要时 pull 最新 Wiki 内容

缺点：

- 文档和代码还是分版本
- 容易忘记同步
- CI/本地工具链要额外处理 `.wiki`

如果这样做，我建议至少加一个脚本，例如 `scripts/sync-wiki.sh`，把 wiki 拉到本地固定目录。

**方案 C：启动前自动抓取 Wiki 到本地缓存**
适合你们已经有 AI ingestion/indexing 流程。

例如：

- 启动分析前执行 `git -C .wiki pull`
- 或从 GitHub API 拉取 wiki 页面导出到 `tmp/wiki-cache/`
- 然后让 AI 只读本地缓存目录

这个方案可以用，但复杂度比 A 高。

**我的建议**

对 Investibook 这类项目，建议这样分层：

- `docs/`：保留和代码强相关、AI 必须能读到的文档
- GitHub Wiki：放轻量协作文档、FAQ、值班经验、非版本绑定知识
- 如果真的要共用内容：做 `docs/ -> wiki` 单向同步，不要反过来

一句话就是：

- **代码相关文档，以 repo 为主**
- **团队知识型文档，以 wiki 为辅**
- **AI 读取，以本地文件系统为准**

如果你愿意，我可以下一步直接帮你设计一套适合这个仓库的文档分层方案，比如：
- 哪些文档继续放 `docs/`
- 哪些迁到 Wiki
- 怎么加一个 `make sync-wiki` / `make pull-wiki` 流程
- 怎么让本地 AI 默认同时索引 `docs/` 和 `.wiki/`