AI 编程系列②：与 AI 协作的核心方法论
AI 编程系列②：与 AI 协作的核心方法论
上一篇聊了工具选型和模型选择。
这一篇讲更重要的东西——怎么和 AI 协作。
工具选对了只是起点。真正决定你产出质量的，是有没有掌握这套方法论。我自己摸索了很久才想清楚，整理出来分享给你。
一、上下文管理：被忽视的基本功
这是我认为 AI 编程里最重要、也最容易被忽视的一个课题。
大模型的对话窗口容量是有限的。上下文越多，它"脑子"里的信息越杂，回答的精准度就越低——因为它带的"包袱"太重了。
我之前就犯过这个错：一个对话窗口里塞了十几个任务，越聊越乱，AI 开始答非所问，最后只能全部推倒重来。
核心原则只有一条：一个任务，一个对话窗口。
不要把所有任务都塞到一个对话里，那样只会污染上下文。
管理上下文的几种方法：
• 新开窗口：最简单直接，也最有效 • 清理当前窗口（Clear）：重置上下文，轻装上阵 • 上下文压缩：让 AI 对当前对话做一轮总结，压缩信息量后继续
二、先计划，后执行
大模型本质上是一个预测型系统，每次执行都有不确定性。
我踩过很多次这样的坑：直接把需求扔给 AI，让它"帮我实现一下"，结果它噼里啪啦改了一堆文件，方向完全跑偏。
后来我养成了一个习惯：动手之前，先和 AI 讨论清楚计划。
它准备怎么做、分几步、每步干什么——把这些确认清楚再执行，质量会高很多。
这不是我的发明，主流工具都已经内置了这个范式：
• Cursor 里有 Plan 模式 • Claude Code 里也有 Plan 模式
更进一步，你可以把整个软件工程的标准流程引入进来，业内叫做 Spec-Driven Coding（规范驱动编程）：
- 讨论需求
- 基于需求做技术方案、产品方案
- 拆分任务
- 每个任务单独开发、测试、验收
流程会变长，但准确率和质量会高很多，更适合生产环境。
三、任务拆分：根据复杂度选策略
不同复杂度的任务，应该用不同的策略。不能一概而论。
我自己的判断框架是两个维度：复杂度 × 改动规模。
复杂度低 + 改动规模小 → 直接提交 Prompt，让 AI 执行即可
复杂度低 + 改动规模大 → 用 To-Do List 拆分任务，分批管理
复杂度高 + 改动规模小 → 用 Plan 模式，先讨论再执行
复杂度高 + 改动规模大 → 先拆分为多个简单任务，再逐个用 Plan + To-Do List 完成
背后的逻辑很简单：当改动涉及成百上千个文件时，上下文一定会被占满，任务大概率执行不下来。拆解成多个子任务，让多个 Sub-Agent 分别执行，完成度会高得多。
不要指望 AI 一口吃成一个大胖子。
现阶段，我们很难在一个对话窗口里把一个复杂的事情讲得足够清楚，让 AI 严谨地一次性完成。这不现实，接受它，然后绕过它。
四、多任务并行：用 Worktree 隔离冲突
想同时跑多个任务？有一个问题必须提前想清楚：代码冲突。
不同任务的 Agent 各自改代码，很容易改到同一个文件，然后互相打架。我就遇到过两个 Agent 同时修改同一个配置文件，最后谁的改动都没保住。
解决方案：用 Git Worktree。
把不同任务放到不同的 Worktree 里隔离，各干各的，最终再合并到主分支。目前 Cursor、Claude Code 都已经提升了对 Worktree 的支持。
当然，如果你确定不同任务修改的文件不会冲突，直接开多个窗口并行处理也完全没问题。
下一篇聊工程化落地——UI 开发技巧、CursorRules 配置、Command 快捷方式，把 AI 真正纳入你的工程体系。