最佳实践
不同场景下的推荐工作流与配置组合
Yoda 的能力是积木，这页给出几种验证过的搭法。按你的场景对号入座，再按口味调整。
单人快速迭代（vibe coding）
适合：独立开发者、早期项目、开着 dev server 边看边改。
| 配置 | 选择 |
|---|---|
| 工作区策略 | 主分支直跑（no-worktree） |
| 运行模式 | normal |
| Express Mode | 开——侧边栏 "+" 一键开任务 |
| 归档前 Skill | 挂一个 git commit skill，归档即提交 |
流程：开任务 → AI 干活、你在预览里看效果 → 满意点归档，agent 把自己改过的文件带着像样的 commit message 提交好。全程不碰分支。
这套玩法是单线的：同时开多个主分支任务可能改到同一文件。要并行，换下一套。
并行多任务
适合：同时推进多个需求、不想互相踩脚。
| 配置 | 选择 |
|---|---|
| 工作区策略 | 分支隔离（worktree） |
.yoda.json | 配好 preservePatterns（.env 等）+ scripts.setup（装依赖），新 worktree 开箱即用 |
| 收尾 | Changes 视图逐个审查 diff，合并或丢弃 |
评测哪个 Runtime 更强
适合：选型、对新模型好奇。
用 compare 模式：同一个需求发给多个 Runtime（默认 Claude Code vs Codex），各自在独立 worktree 里干活，diff 摆在一起比。结论自己得。
重要改动多一道防线
适合：核心模块、不敢直接信 AI 的场景。
- 轻量：review 模式——一个 Runtime 干活，另一个做 reviewer
- 更稳：reviewer 挂一个专职 自定义 Agent，System Prompt 写死「只报告高置信度问题，引用具体行号」
沉淀你的 Agent 资产
- 同样的开场指令写第三遍时，就该沉淀成 自定义 Agent
- 窄角色优于全能：「只做 code review」比「全栈大神」稳定
- 提示词里写禁区（别动迁移文件、别改 CI）比只写要做什么更有效
- Agent 不绑 Runtime——换 CLI 不用重写资产
定期体检你的 harness
agent 行为漂移时，先别改提示词，打开 Harness 观测 看三样东西：
- Memory —— 有没有过期的 CLAUDE.md / AGENTS.md 在误导它
- Hooks —— 有没有遗忘的全局 hook 在偷偷干预
- Skills —— 该启用的没启用、不该启用的还开着
多数"agent 变笨了"的问题出在这层，而不是模型。