18.6 调优与工程实践

面向经管学生、研究者与从业者的 AI 智能体设计教材

调优与工程实践

流程跑通后，系统可以交付。但从”能用”到”好用”还有距离。本节讨论三个改进方向：执行策略选择、Git 版本控制，以及从单模块到完整系统的迭代路径。三个方向互相独立，可按需单独采用。

串行与并行的选择

subagent-driven-development 采用串行执行——任务逐个完成，每个通过审查后才启动下一个。这是本章开发流程的默认模式，适合任务之间有依赖关系的场景。

但并非所有任务都有依赖。superpowers 另有 dispatching-parallel-agents Skill，可同时派发多个子代理。选择标准只看一条：任务之间是否真正独立。

条件	推荐策略	原因
任务间有数据或接口依赖	串行	后续任务需要前序任务的产出
任务间完全独立	可并行	如两个互不调用的前端组件
不确定是否有依赖	串行	串行多花时间，并行出冲突代价更大

实际项目中，串行是更安全的默认选项。并行带来的速度提升，不一定抵得过冲突排查的成本。

Git 版本控制

Agent 开发中，Git 不是备份工具，而是安全网。两个实践最有价值：

小步提交：每完成一个任务就提交一次。subagent-driven-development 已经内置了这个行为——每个子代理完成并通过审查后自动提交。好处是回退时能精确定位到出问题的那一步，而不是面对一个包含五个任务的大提交。

Worktree 隔离：superpowers 的 using-git-worktrees Skill 为每个功能创建独立的工作目录。开发失败了，直接丢弃整个 worktree，主分支不受影响。

分支策略

功能开发和热修复使用不同分支，互不干扰：

分支	用途	生命周期
main	稳定版本	长期
feature/search-api	搜索模块开发	1-2 天
feature/frontend-ui	前端界面	1-2 天
hotfix/parser-bug	解析器修复	几小时

功能分支从 main 拉出，开发完成后合回。如果线上发现 bug，从 main 开新的 hotfix 分支修复，不影响正在进行的功能开发。

从单模块到完整系统

本章用一个金融知识库项目走通了完整的六阶段流程。实际项目中，一次开发通常只覆盖一个模块或一组功能。系统是模块的叠加，流程是不变的。

每个新模块走同一条路：

1. 给出需求（brainstorming）
2. 调研现有代码库，明确接口边界
3. 制定更新计划（writing-plans）
4. 子代理串行执行（subagent-driven-development）
5. 验证并交付（verification-before-completion）

第一个模块最慢，因为要建立项目骨架、配置 Skill、搭建测试框架。从第二个模块开始，这些基础设施已经就位，每轮迭代只需要关注业务逻辑本身。

系统的复杂度不是一次性堆上去的，而是通过多轮迭代逐步叠加。每轮迭代都有明确的输入（设计文档）、过程（计划 + 执行 + 审查）和验收标准（验证清单）。这套流程没有与金融知识库绑定——换一个场景，从第一步重新走，路还是那条路。