选择合适的 AI 编程工作流
根据任务范围、反馈速度和执行风险，选择对话、编辑器协作或 Agent 工作流。
选择 AI 编程工具时，可以先观察任务需要怎样的反馈。局部修改需要快速查看差异，跨文件任务需要持续检索和验证，尚未明确的问题则需要先讨论目标。工作流应围绕这些需求安排。
从任务形态出发
| 工作方式 | 适合的任务 | 人需要重点关注什么 |
|---|---|---|
| 对话协作 | 澄清需求、解释代码、比较方案 | 提供准确材料，确认前提与取舍 |
| 编辑器内协作 | 局部修改、重构、小范围调试 | 查看上下文与差异，及时运行验证 |
| Agent 执行 | 跨文件实现、重复操作、完整工程任务 | 定义边界与验收，检查关键决策 |
| 多 Agent 协作 | 有清晰分工的调查、实现或审查 | 分配文件职责，汇总证据并完成集成 |
这些方式可以连续使用。例如先在对话里明确搜索体验，再让 Agent 实现，最后在编辑器与浏览器中检查结果。切换时应保留任务说明与当前状态，避免丢失已经确认的约束。
判断任务是否适合交给 Agent
优先选择目标明确、入口可查、结果可验证的任务。若验收依赖模糊的审美或尚未决定的业务规则，先做一份小样，让真实结果帮助确定方向，再扩大范围。
评估工具时，可以用同一个小任务比较：它能否找到正确入口，是否尊重项目约定，出错后能否定位原因，最终说明是否与实际结果一致。只比较一次代码生成速度，很难判断长期协作成本。
并行之前先拆清依赖
多 Agent 适合处理可以独立推进的工作，例如一个负责阅读接口，一个负责审查测试。实现任务尽量分配互不重叠的文件；共享接口和配置由明确的负责人统一维护。最终仍需在同一份代码状态上完成集成验证。
先完成一次小闭环
用一个有代表性的任务跑完“说明、执行、审查、验收”。记录耗时和返工原因，再决定是否需要更多工具或更复杂的协作方式。
让工作流保持可替换
把任务模板、项目规则与验证方式保存在项目能够访问的位置，减少对单次对话的依赖。工具可以更换，清楚的目标和可重复的验收仍然有价值。