第七章：Composer：跨文件改动与任务拆分

7.1 Composer 的正确用法：做“跨文件、可审阅”的变更集

跨文件改动最容易失控：一旦范围扩散，你很难确认每个文件都改对了。

使用 Composer 的核心目标应该是：

• 把跨文件任务拆成可审阅的小步
• 每一步都有明确验收
• 先通过测试，再扩大改动范围

7.2 跨文件任务的三段式流程

建议你让 Cursor 按三段式交付：

1. 调查与设计（不改代码）
   输出：入口、调用链、风险点、最小方案。

2. 实施最小改动（可回滚）
   输出：变更摘要 + diff。

3. 验证与收尾
   输出：测试/lint/build 结果 + 回滚方式。

你可以直接复制这段给 Cursor：

请按三段式输出：
1) 先调查与设计：不改代码，给出入口/调用链/最小方案与风险点
2) 再实施最小改动：输出变更摘要与 diff
3) 最后验证：按顺序跑 tests/lint/build，总结结果与回滚方式

7.3 控制范围：明确“允许改动的目录”

跨文件任务建议你把范围写死，例如：

只允许修改：src/、tests/
禁止修改：.github/、infra/、deployment/、terraform/、docs/

范围控制做得好，审阅成本会显著下降。

7.4 拆分策略：按“验收边界”拆，而不是按“文件数”拆

一个好的拆分方式是按验收边界拆：

• 先只改实现，让现有测试通过
• 再补测试覆盖新增行为
• 最后才做重构与清理

这样每一步都有明确的“是否正确”判断标准。

7.5 本章小结

你已经掌握了用 Composer 做跨文件任务的稳定套路：

• 三段式交付：调查→实施→验证
• 目录边界写死，控制改动范围
• 按验收边界拆分，保证每一步可验证

下一章我们把“验证”体系化：让 Cursor 帮你稳定地跑测试/lint/build，把正确性变成默认路径。