开发环境配置
核心问题
一个新成员（或者三个月后的我自己）打开 Growth 项目，Qoder 怎么让他快速进入开发状态？
"开发环境配置"不只是装好 IDE、编译通过。更重要的是让 AI 认识你的项目——知道你的编码规范、架构决策、模块边界。这一章讲的就是怎么用 Qoder 的 Rule、Memory、AGENTS.md 来完成这件事。
使用篇：Rule 让 AI 一出手就是对的
什么是 Rule
Rule 是写在 .qoder/rules/ 目录下的规范文件。AI 在每次对话时自动加载这些规则，确保生成的代码符合项目规范。
在 Growth 项目中，我们沉淀了 14 条 Rule，覆盖了从命名规范到架构约束的全方位：
.qoder/rules/
├── early-return.md ← 必须用卫语句，避免深层嵌套
├── exception-handling.md ← 异常透明，只在最顶层 try catch
├── no-fallback.md ← 不做兼容性设计，旧逻辑直接删除
├── logger-convention.md ← 必须用 LogFormatHelper
├── naming-convention.md ← C# PascalCase，前端 camelCase
├── dependency-injection.md ← 只能通过构造函数注入依赖
├── layer-boundary.md ← 严格遵守分层架构
├── api-response-format.md ← 统一 API 响应格式
├── repository-pattern.md ← 数据库访问必须通过 Repository 层
└── ...如何配置
# 在 Components 项目的 .qoder/rules/ 目录下创建 rule 文件
# 每条 Rule 一个文件，清晰描述什么问题、应该怎么写
# 以 early-return.md 为例：
## 规范
遇到前置条件不满足时，提前返回，不要继续嵌套。
## 正确写法
if (order == null) return Result.Failure("订单不存在");
if (!order.IsActive) return Result.Failure("订单已失效");
## 错误写法
if (order != null) {
if (order.IsActive) {
// 真正的逻辑被多层 if 包裹
}
}贯穿案例中的应用
假设你要创建一个新的工作流节点。有了 Rule 之后，你不需要告诉 AI "注意日志格式、注意异常处理"——这些 Rule 已经自动加载了。AI 生成的节点代码会自然使用 LogFormatHelper、不会出现深层嵌套、异常会向上抛出而不是被吞掉。
实践篇：Memory 让 AI 知道"为什么这么设计"
什么是 Memory
Memory 是 Qoder 的跨会话知识库。你告诉 AI 一次"为什么选择这个架构"，它就会记住，下次打开新会话时不需要重新解释。
Growth 项目中值得记忆的架构决策
以下是我们在 Growth 项目中让 AI 记住的关键信息：
决策一：为什么选择 CLI 作为统一执行层
传统做法是 API-first——所有功能通过 REST API 暴露。我们选择 CLI-first，因为 PowerShell 脚本天然可编排、可组合，AI 可以直接生成和执行。API 是给人调用的，CLI 是让机器和 AI 调用的。
决策二：为什么双仓库而不是单仓库
Client 是面向用户的产品（桌面端 + Web），迭代快、发版频繁。Components 是底层组件库（CLI 引擎、工作流引擎），需要稳定、少变。分仓库部署可以让 Components 的发布节奏不受 Client 影响。
决策三：模块的组织原则
每个模块按"接口层 → 实现层 → 引擎 → 持久化"组织。接口层定义契约，实现层处理业务逻辑，引擎负责核心算法，持久化层管理数据。模块之间通过接口依赖，不直接引用实现。
实际效果
一旦这些决策写入 Memory，当你问 AI "为什么 CLI 模块放在 Components 而不是 Client"时，AI 会直接回答："这是架构决策二的内容——Components 作为底层组件库，需要独立于 Client 的发布节奏。"
你不需要重复解释，AI 已经记住了。
贯穿案例中的应用
当你开始写一个新的节点时，AI 已经通过 Memory 知道：
- 节点的标准结构是 form.json + script.ps1
- 参数定义遵循 JSON Schema 规范
- 输出格式需要包含 success 和 outputPath
- 运行时依赖需要在 form.json 中声明
这些都不是你现场告诉 AI 的——它们已经在 Memory 里了。
实践篇：AGENTS.md 预配置 SubAgent
什么是 AGENTS.md
AGENTS.md 是 Qoder 的智能体配置文件。它定义了项目中可用的 SubAgent，让 AI 知道什么时候该触发什么角色。
Growth 项目中的预配置
markdown
# AGENTS.md
## 可用 Skill
- `/code-review` — 审查代码变更
- `/create-proposal` — 创建需求分析文档
- `/test-component` — 执行组件集成测试
## SubAgent
- CodeReview Agent — 代码审查，加载审查 Checklist
- Browser Agent — 浏览器预览和端到端测试配置完成后，AI 会自动根据任务决定是否触发这些 SubAgent。你不需要手动输入命令。
知识篇：为什么开发环境配置对 AI 如此重要
传统开发的"环境配置" vs AI 时代的"环境配置"
| 维度 | 传统开发 | AI 时代 |
|---|---|---|
| 配置内容 | IDE 插件、编译工具链 | Rule + Memory + AGENTS.md |
| 配置目的 | 让人能写代码 | 让 AI 能写出对的代码 |
| 配置频率 | 一次配置，长期使用 | 随项目演进持续更新 |
| 新人上手 | 安装依赖 → 编译通过 | Rule + Memory 加载 → AI 认识项目 |
为什么 Rule 和 Memory 比文档更有效
传统项目中，我们把规范写在文档里，但新人不一定会读。即使读了，也不能保证每次写代码都记得住。
Rule + Memory 的方式完全不同：
- Rule 是强制性的——AI 每次对话都加载，不可能"忘记"
- Memory 是上下文性的——AI 会基于记忆回答问题，不需要你重复
- 两者结合——Rule 约束"怎么写"，Memory 告诉"为什么这么写"
这就是为什么我说：开发环境不只是 IDE + 编译通过，还要让 AI '认识'你的项目。
本章小结
| 配置项 | 作用 | 配置频率 | 对贯穿案例的贡献 |
|---|---|---|---|
| Rule | 约束 AI 的编码行为 | 随规范更新 | 节点代码自动符合规范 |
| Memory | 记录架构决策历史 | 大重构后更新 | AI 知道为什么节点这么设计 |
| AGENTS.md | 预配置 SubAgent | 新增时更新 | CodeReview/测试自动可用 |
关联：第一部分 05（Rule 规则系统）、第一部分 06（Memory 记忆系统）、第二部分 04（子代理分工）。