Qoder 组织大型项目的核心优势
核心问题
Growth 产品横跨两个仓库（Client + Components）、57 个 .NET 项目、168 个前端 package、桌面端和 Web 端混合架构——面对这种规模的代码库，Qoder 怎么帮你理清楚？
在进入具体的开发流程之前，这一章先展示 Qoder 组织大型项目的几个核心能力。这些能力贯穿整个第三部分，是后续所有章节的基础。
能力一：多工作区拆分——工程太大，一个工作区放不下
使用篇
传统 IDE 的做法是一个工程一个窗口。但 Growth AIOS 的代码量太大了——两个仓库、57 个 .NET 项目、168 个前端 package，再加一堆外部参考框架。
如果全部塞到一个工作区里，文件数量太多，RepoWiki 都无法正常生成知识摘要。所以实际的配置是拆成两个工作区：
工作区一：COMPONENTS（组件库）
├── AiAgent/ ← AI Agent 管道
├── AiAgent.Integration/ ← 多 Agent 流水线
├── CLI/ ← PowerShell 执行引擎
├── CodeRunner/ ← 代码运行器
├── Workflow/ ← 工作流引擎（72 节点）
├── Framework/ ← 基础框架
├── LLM/ ← LLM 集成
├── MCP/ ← MCP 协议集成
├── Plugin/ ← 插件系统
├── Runtimes/ ← 运行时
├── VarVault/ ← 变量存储
├── Video/ ← 视频处理
├── Trigger/ ← 触发器
├── Endpoints/ ← 端点服务
├── Diagnostics/ ← 诊断工具
├── Documents/ ← 文档
├── ... ← 以及外部参考框架（见能力二）工作区二：CLIENT（桌面端 + Web）
├── Desktop/ ← WPF 桌面端
├── Desktop.Auth/ ← 桌面端认证
├── Desktop.Components/ ← 桌面端组件
├── Desktop.Server/ ← 桌面端服务器
├── Desktop.UIControls/ ← 桌面端 UI 控件
├── Desktop.Test/ ← 桌面端测试
├── Web/ ← React 前端（Rush monorepo）
├── Web.Server/ ← Web 服务器
├── Documents/ ← 文档
├── publish/ ← 发布目录
├── ...两个工作区独立存在，各自有各自的 RepoWiki、Rule、Memory。
当需要跨工作区协作时（比如 Client 依赖 Components 的更新），在对话中告诉 AI "去参考 Components 的某某模块"即可。
为什么这么拆
一个工作区文件太多，RepoWiki 就没法用了。RepoWiki 需要为每个模块生成知识摘要，如果文件数量超过一定阈值，生成的摘要会变得冗长且不精确。
所以拆分的核心原则是：按业务边界拆，使每个工作区的 RepoWiki 保持可维护。
| 工作区 | 定位 | 包含 | RepoWiki 覆盖范围 |
|---|---|---|---|
| COMPONENTS | 底层组件库 | CLI 引擎、工作流引擎、AI Agent、节点系统 | 所有组件模块 |
| CLIENT | 面向用户的产品 | 桌面端、Web 前端、认证、UI 控件 | 桌面端 + Web |
贯穿案例中的应用
回到贯穿案例——"从零到部署一个新工作流节点"。因为节点开发在 Components 中，你打开的是 COMPONENTS 工作区。所有节点相关的代码（CLI 引擎、Workflow 节点系统、Rule 规范）都在这里，RepoWiki 也已经覆盖了这些模块的摘要。
当你需要查看节点发布后在 Client 桌面端中的表现时，切换到 CLIENT 工作区。
能力二：外部参考框架——让 AI 参考第三方开源库
使用篇
大型项目不可避免要引用第三方开源库。但 AI 默认不认识这些库的内部实现——它只能凭训练数据的记忆去猜。
Growth 项目中会参考大量 AI Agent 领域的开源框架来设计自己的架构。这些框架的代码需要让 AI 能够直接阅读。
做法是：把参考框架的代码目录直接放在工作区中。
以 COMPONENTS 工作区为例，它的目录下除了自有代码，还有：
COMPONENTS (工作区)
├── Components/ ← 自有组件代码
├── cli/ ← 自有 CLI
├── agent-framework/ ← 参考：Agent 框架
├── deer-flow/ ← 参考：基于 LangGraph 的 Agent 系统
├── OpenViking/ ← 参考：其他 Agent 框架
├── hermes-agent/ ← 参考：Hermes Agent
├── dotnet-extensions/ ← 参考：.NET 扩展库
├── ahk-mcp/ ← 参考：AHK MCP 集成
├── new-api/ ← 参考：API 设计
└── ...使用方法：
# 在 COMPONENTS 工作区中，直接让 AI 阅读参考框架的代码：
"看 deer-flow 的 Agent 管道设计，跟我们现有的 AiAgent.Integration 做个对比"
# 或者参考具体实现：
"参考 hermes-agent 的 tool 注册机制，看看我们能不能借鉴"实践篇
三个核心价值：
- AI 不需要「猜」开源库的实现——它可以直接读源码
- 参考框架的代码时，能精确到文件和函数级别——不是模糊的"这个功能大概是这样"
- 避免了「AI 生成了一个开源库里已有的功能，但我们不知道」的问题——重复造轮子的最大原因不是 AI 不会，而是 AI 不知道
一个真实场景：我们在设计 Agent 管道架构时，需要参考 deer-flow（一个基于 LangGraph 的 Agent 系统）和 hermes-agent 的设计。有了参考代码目录，我们可以直接让 AI：
"对比 deer-flow 的 Middleware 链和 hermes-agent 的 tool 分发机制，
分析它们的优缺点，给出适合我们 AiAgent.Integration 的方案"AI 会同时读取两个框架的源码，输出对比分析——不需要我们提前理解这些框架，AI 边读边分析。
知识篇
外部参考框架的本质是扩展 AI 的知识边界。
大模型的训练数据是固定的——它知道的知识截止于某个时间点。但开源框架在不断更新，而且你参考的可能是小众框架。把参考代码放在工作区中，AI 就能"临时学习"这些不在训练数据中的知识。
这和人类开发者的工作方式一致：遇到不熟悉的库，我们也会去看它的源码。外部参考框架就是让 AI 也拥有这个能力。
能力三：快速定位文件——路径即定位
使用篇
大型项目最常见的问题：同名文件太多。
Growth 产品矩阵中，LoggerConfig.cs 出现在 10+ 个项目中，CLIModule.cs 也有多个重复。如果不指定路径，AI 经常读错文件。
Qoder 的解决方案很简单：路径即定位。
❌ 模糊描述："帮我看看 LoggerConfig 的配置"
→ AI 可能读错文件
✅ 精确描述："帮我看看 Desktop\Desktop.Server\LoggerConfig.cs 的配置"
→ AI 精确定位编辑器内的可视化目录树是天然的优势——你可以直接复制文件路径给 AI，或者在提示词中指定目录范围：
# 限定修改范围
"只修改 Workflow/ 目录下的文件，不要碰其他地方"
# 限定参考范围
"参考 deer-flow 的 Middleware 链设计，不要参考 hermes-agent 的"实践篇
这对于多工作区 + 大量参考框架尤其重要——不指定路径，AI 根本不知道你要读的是自有代码还是参考框架。
举个例子：
❌ "分析一下 Agent 的 tool 注册机制"
→ AI 可能分析的是 hermes-agent 的，而不是你们自有 AiAgent 的
✅ "分析 AiAgent.Integration/Tools/ 下的 tool 注册机制"
→ AI 精确定位到自有代码路径即定位不仅解决了"改哪个文件"的问题，还解决了"不能改哪个文件"的问题——参考框架的代码是只读的，通过路径限定可以避免 AI 意外修改参考代码。
知识篇
路径即定位的背后是目录结构即信息结构的编程思想。
一个好的项目目录结构本身就是代码的"地图"。当你告诉 AI "去 Components/CLI/Engine/ 看看"时，这个路径已经传达了多层信息：
Components/→ 是自有代码，不是参考框架CLI/→ 命令行执行引擎模块Engine/→ 核心引擎代码，不是接口定义
路径本身就在帮助 AI 理解代码的上下文层级。这就是为什么 Qoder 强调"路径即定位"——不只是为了找文件，更是为了让 AI 理解文件在项目中的位置和角色。
本章小结
| 能力 | 解决什么问题 | 实际配置 |
|---|---|---|
| 多工作区拆分 | 工程太大，一个工作区 RepoWiki 不可用 | Components + Client 两个工作区 |
| 外部参考框架 | AI 不认识第三方开源库 | 参考框架代码直接放在工作区目录下 |
| 路径即定位 | 同名文件太多，AI 容易读错 | 精确到文件级别的定位 |
关联：第一部分 02（工作区管理与 RepoWiki）。