实战经验总结
核心问题
200 万行代码、两年多使用 Qoder 的经验，提炼出什么可复用的心法？
前面七章分别讲了 Qoder 在开发流程每个环节的作用。这一章把这些经验提炼为五条心法——不只是在 Growth 项目中有效，在任何大型项目中都可以复用。
心法一：Rule 是投资回报率最高的配置
一条 Rule 能省多少时间
以 early-return Rule 为例。在 Growth 项目中，我们用了 10 分钟写这条 Rule（包含正确写法和错误写法的对比）。它的效果是：
- 每次 AI 生成代码时自动应用——不需要人工提醒
- 每次代码审查时不会出现嵌套问题——Rule 在源头就解决了
- 100% 的一致性——项目中所有代码都遵循同样的风格
保守估算：花 1 小时写一条 Rule，至少省 100 小时的 Code Review 和 Bug 修复时间。
三条投入产出比最高的 Rule
如果你的项目只能写三条 Rule，我建议先写这三条：
| 优先级 | Rule | 解决的问题 | 估计节省时间 |
|---|---|---|---|
| 1 | early-return | AI 喜欢写深层嵌套 | 最多出现的编码问题 |
| 2 | 异常透明 | AI 喜欢 try catch 吞异常 | 最难排查的 Bug 源 |
| 3 | 命名规范 | AI 命名风格飘忽不定 | Code Review 最常见的话题 |
为什么 Rule 比"代码审查时指出问题"更有效
传统做法是"代码写完了，审查时指出问题，改"。这种方式的问题是：
- 审查者付出了时间成本——需要指出问题
- 修改者付出了修改成本——需要重新改
- 同样的错误反复出现——因为没有从根源解决
Rule 的解决方式是：在 AI 生成代码时就约束它。不需要审查，不需要修改，生成的代码天然符合规范。
Rule 投入产出比最高，因为它把成本前置到了编写阶段，消除了后置的审查和返工成本。
心法二：Skill 封装的是流程，不是操作
好 Skill 和坏 Skill 的区别
| 坏 Skill | 好 Skill | |
|---|---|---|
| 内容 | "打开文件 A → 修改第 X 行 → 保存" | "为新表生成标准 CRUD 代码" |
| 粒度 | 具体的按键/点击操作 | 有含义的工程步骤 |
| 可复用性 | 只对当前项目当前版本有效 | 同类任务通用 |
| 稳定性 | 目录变了就失效 | 依赖的是逻辑不是路径 |
判断标准
一个好的 Skill 应该回答"做完 X 需要经过哪几步"，而不是"点哪里、输入什么"。
✅ 好的 Skill：
"创建一个新节点需要的步骤：
1. 在 Nodes/ 下创建执行器文件
2. 在 registry 中注册
3. 编译验证"
❌ 坏的 Skill：
"在 Nodes/ 文件夹右键 → 新建 → 类文件 →
输入 FileCompressNode.cs → 粘贴代码 → 保存"什么时候该封装成 Skill
一个简单判断：同样的操作重复三次以上，就值得封装成 Skill。
但注意——封装的是"流程"，不是"操作"。如果只是把一系列鼠标点击写成 Skill，它很快就会因为 UI 变化而失效。
心法三：Memory 不要频繁维护
记忆的最佳维护频率
很多人在刚接触 Memory 的时候，容易陷入"定期治理"的思维——每周检查一次、每月更新一次。
但 Growth 项目的经验是：不要频繁维护 Memory。
| 维护频率 | 问题 |
|---|---|
| 每周 | 大部分记忆没有变化，白花时间 |
| 每月 | 仍然需要检查，仍然花时间 |
| 有触发条件再维护 | 只在必要时处理，不浪费精力 |
什么时候该维护
只有三种情况需要维护 Memory：
- AI 反复给出过时信息 → 删除或更新那条记忆
- 做了重大架构重构 → 更新相关记忆
- 主动发现记忆偏差 → 让 AI 审查一次
其他时候，让它自己管理。Qoder 自己会做压缩和去重，不相关的内容被查到最多多一句废话，不会造成严重后果。
一个实用的维护技巧
如果你感觉 AI 的行为有点怪，可以主动做一次审计：
请你查看现在的记忆，是否有和我架构不匹配的地方或者过期的记忆AI 会遍历记忆库，对比当前代码，生成一张审查报告，列出每条记忆的"当前状态"和"实际情况"的差异。你扫一眼，让 AI 按建议执行就行。
心法四：CLI + Qoder > IDE + 插件
为什么 CLI 比 IDE 更适合 AI
IDE 是为人设计的——可视化菜单、按钮、弹窗、拖拽。这些交互对人类友好，但对 AI 不友好。
CLI 是为机器和 AI 设计的——参数、输出、退出码、管道。这些交互对 AI 天然友好。
| 能力 | IDE + 插件 | CLI + Qoder |
|---|---|---|
| AI 直接执行 | ❌ 需要模拟点击 | ✅ 一条命令 |
| 精确控制 | ❌ 不支持参数化 | ✅ -Step 分段控制 |
| 可组合 | ❌ 需要在不同窗口操作 | ✅ 管道拼接 |
| 可脚本化 | ❌ 必须有人操作 | ✅ 全自动 |
判断标准
如果某个流程只有 GUI 没有 CLI，Qoder 就编排不了。
所以建议是：所有需要重复执行的开发操作，都优先设计 CLI 接口，而不是 GUI 操作。 包括但不限于：
- 构建 → 不用 IDE 点按钮，用命令行
- 测试 → 不用 IDE 点运行，用命令行
- 打包 → 不用右键压缩，用脚本
- 部署 → 不用 FTP 拖拽，用 CLI 工具
CLI 不只是"另一种操作方式"
CLI 不只是 IDE 按钮的命令行等价物。CLI 意味着：
- 参数化 — 可以精确控制行为
- 可组合 — 可以通过管道串联多个操作
- 可编程 — 可以被脚本和 AI 调用
- 可追溯 — 命令本身就是执行记录
所以心法四的核心是：让你的开发操作 CLI 化，然后 Qoder 就能编排一切。
心法五：脚本负责执行，Agent 负责判断
为什么脚本和 Agent 不能相互替代
| 脚本 | Agent | |
|---|---|---|
| 优势 | 稳定、可重复、低成本 | 智能、灵活、理解语义 |
| 劣势 | 不能判断、不能理解语义 | 不稳定、高成本 |
| 适合 | 确定性操作（编译、打包、上传） | 不确定性任务（分析、判断、生成内容） |
正确的组合方式
Agent 判断"要做什么" → 脚本执行"怎么做" → Agent 分析"结果如何"
具体例子：
Agent：确认当前版本号 → 调用脚本编译 → 读取编译日志 →
判断是否成功 → 如果失败分析根因 → 如果成功继续下一步Growth 项目中的实践
在发版流程中：
脚本（build-nsi-installer.ps1）：
- 读取 DLL 版本号
- 生成 version.nsh
- 编译 NSIS 安装包
Agent（release-publisher）：
- 判断当前分支是否正确
- 编排 9 步发版流程
- 分析编译失败原因
- 生成发布日志脚本稳定执行，Agent 智能判断。两者不是替代关系，是分工关系。
如何判断该用脚本还是 Agent
一个简单的决策树：
这个操作的结果是确定性的吗？
├─ 是 → 脚本
│ 例如：编译、打包、文件复制
└─ 否 → Agent
例如：分析错误日志、生成发布日志、判断版本号全书收束
五条心法放在一起，构成了一个完整的体系：
| 心法 | 一句话 | 解决什么问题 |
|---|---|---|
| Rule 是投入产出比最高的配置 | 让 AI 一出手就是对的 | 编码质量 |
| Skill 封装流程而非操作 | 把最佳实践固化 | 效率 |
| Memory 不要频繁维护 | 只在必要时处理 | 维护成本 |
| CLI + Qoder > IDE + 插件 | 让 AI 编排一切 | 自动化 |
| 脚本负责执行，Agent 负责判断 | 各司其职 | 分工 |
Qoder 不是银弹，但用好这五条心法，大型项目的开发效率至少翻一倍。
关联：全书能力体系全景回顾。