管理大型项目

大型任务最常见的问题不是模型不会写代码，而是范围不断扩大、上下文逐渐混乱，最后无法证明哪些部分真正完成。

先建立项目地图

开始修改前，让 Agent 找到：

• 用户入口和核心数据流；
• 相关模块及其所有者；
• 协议、配置或数据库边界；
• 最小测试与全量门禁；
• 当前工作区已有改动。

要求引用关键文件，但不要一开始扫描每个文件。可以直接跟做理解一个现有项目。

把目标拆成里程碑

一个可靠的顺序通常是：

1. 契约或行为定义；
2. 核心实现；
3. 界面或集成；
4. 测试；
5. 文档与发布检查。

每个里程碑应有可独立核对的输出。完成一段后，让 Agent 用当前文件和测试重新总结，而不是只沿用早期计划。

决定串行还是并行

使用 Multi-Agent 前问三个问题：

• 子任务是否能在没有另一路结果的情况下推进？
• 是否能给每一路明确交付物？
• 根 Agent 是否有办法交叉核对？

如果答案都是“是”，可以并行调查或审查。共享同一文件的大量实现通常更适合由一个 Agent 串行完成，避免互相覆盖。

控制变更表面

• 明确允许修改的目录和不应触碰的区域；
• 在开始前记录已有未提交改动，不能把它们当作 Agent 的产出；
• 先运行最小相关测试，再决定是否全量验证；
• 每个阶段检查 diff，尽早发现无关格式化或生成文件；
• 重要改动用版本控制形成可恢复节点。

管理上下文

长对话会压缩旧历史。关键事实不要只留在聊天中：把稳定规范写进项目文档，把可复用工作法做成 Skill，把阶段结论写成明确的交付文件。

对话接近一个自然里程碑时，可以让 Agent 输出“已确认事实、已完成、未完成、风险、下一步”，然后为下一阶段开启更聚焦的新对话。新对话不会自动拥有旧对话的全部细节，必要材料应通过项目文件或清晰摘要提供。

建立证据账本

最终收口时按三列检查：

不要把“Agent 说它运行过”当证据；应保留真实命令结果或可重现步骤。

何时应该停止并重规划

• 方案需要显著扩大权限或范围；
• 关键前提与代码不符；
• 外部副作用进入结果未知；
• 上下文已经无法区分本轮与历史改动；
• 测试基础本身不稳定，无法判断回归。

停止不是失败。先保存事实和差异，再用更清晰的边界开始下一阶段，通常比继续堆叠修补更快。