AI 编程工作流最佳实践：把 Token 额度花在刀刃上

1. 核心判断

AI 编程里的额度消耗，通常不只是模型价格或调用次数的问题，而是工作流失控后的连锁成本。主要浪费集中在几类：任务没有边界、对话没有结构、上下文压缩没有校验、代码改坏后没有 checkpoint 可以回滚。

换句话说，真正昂贵的不是"让 AI 写代码"，而是让 AI 在需求不清、范围不明、上下文混乱的状态下反复试错。

这套方法可以压缩成一句话：

用软件工程流程管理 AI，而不是把整个功能一次性丢给 AI。

2. 三个基本原则

2.1 拆分：大功能要拆成小工程

大功能在产品描述里可能只是一句话，但在工程上往往包含数据库、接口、状态、页面、测试、兼容性等多个部分。如果直接要求 AI "做完整功能"，模型会在一轮里同时猜需求、猜架构、猜技术选型，后续偏差会非常贵。

更合适的方式是先让 AI 做拆解，而不是直接写代码：

列出涉及的模块、接口、状态和风险点。
把关键技术判断交给开发者确认。
前后端分阶段推进。
能 mock 的地方先 mock，减少互相等待。
每个阶段结束后做 commit，形成可回滚节点。

2.2 节制：主动管理上下文窗口

上下文不是无限缓存。对话越长，模型越容易出现遗忘约束、重复试错、推翻已确认方案、改 A 误伤 B 等现象。

不要等上下文快满才压缩，而是在阶段性节点主动压缩：

一个模块完成时。
从阅读代码切换到修改代码时。
从定位问题切换到修复问题时。
读完一批文件后，只保留结论。
模型开始反复、跑题、遗忘限制时。

节制的重点不是少用 AI，而是让 AI 始终在足够清晰的上下文里工作。

2.3 校准：关键判断不能完全交给模型

AI 更适合执行、起草和辅助分析，不适合独自承担最终决策。

关键节点要进行校准：

开始前，让 AI 复述任务目标和限制条件。
压缩后，让 AI 复述当前任务状态，确认摘要没有漏掉关键内容。
Bug 修复后，验证当前功能和可能受影响的旧功能。
方案选择时，由人确认取舍，而不是让模型默认选择。

校准的价值在于防止错误方向被继续放大。

3. 大功能的推荐拆法

以"登录注册功能"为例，不要直接一句话开工，而是拆成四个阶段。

阶段 0：需求梳理，不写代码

先让 AI 输出需求文档，内容包括：

数据库表和字段。
接口和请求 / 响应结构。
前端页面和组件。
技术选型的备选项。
风险点和边界情况。

这一阶段的目标不是生成代码，而是把关键判断暴露出来，便于审阅和修正。

阶段 1：后端接口先行

在需求文档确认后，再推进后端：

数据库迁移。
注册、登录、token 校验接口。
中间件。
单元测试。

阶段结束后做 checkpoint commit，例如：

bash 复制代码

git commit -m "checkpoint: backend api done"

阶段 2：前端 mock 联调

前端先基于 mock 数据独立开发：

登录页和注册页。
表单校验。
状态管理。
路由守卫。

阶段结束后继续 commit，例如：

bash 复制代码

git commit -m "checkpoint: frontend with mock"

阶段 3：真接口接入与回归验证

最后切到真实接口，跑通完整流程，并回归验证可能被中间件、鉴权状态影响的旧功能。

这种拆法的价值是：每个阶段的上下文更小，AI 注意力更集中；每个阶段都能回滚；关键决策也不会被模型默认带走。

4. 上下文压缩的正确理解

对 /compact 的核心理解是：压缩不是"清屏续命"，而是生成一份可靠的任务交接文档。

错误理解：

把压缩当成聊天记录折叠。
以为压缩后模型自然会保留所有重要细节。
直接裸用 /compact，不指定摘要结构。

正确理解：

压缩要保留任务目标、约束、已读文件、已改文件、已排除方案、未解决问题和下一步计划。
压缩不是无损操作，摘要质量决定后续能否接上。
压缩后必须校验，确认模型没有漏掉关键限制。

5. Claude Code 与 Codex CLI 的差异

不同工具的上下文管理能力不完全一样，几个实践点尤其重要：

Claude Code 支持 /compact [instructions]，可以直接把结构化压缩要求放进命令。
Codex CLI 的 /compact 不支持参数，因此需要先用普通消息告诉 Codex "接下来压缩时必须保留哪些内容"，再执行 /compact。
Claude Code 可用 CLAUDE.md 中的 Compact Instructions 承载持久压缩规则。
Codex CLI 可通过配置项调整上下文窗口和自动压缩阈值，但没有等价的压缩指令区。

团队使用不同工具时，不能把一个工具的命令习惯直接套到另一个工具上。更稳妥的做法是为所选工具写内部 SOP。

6. 什么时候该压缩，什么时候不该压缩

适合主动压缩的时刻

一个阶段自然完成时。
即将进入下一阶段时。
读完一批文件，只需要保留结论时。
模型开始重复、跑题、遗忘限制时。
上下文接近工具阈值前。
准备切换会话或交接任务时。

不适合压缩的时刻

任务刚开始，还没有形成有效结论。
需求仍然模糊。
多个技术方案还没有定论。
刚补充关键限制，还没有被吸收到执行计划里。
当前代码状态已经混乱，应该先回到干净状态。
刚贴出错误堆栈，还没有完成排查。

压缩本身也消耗 token，并且有丢信息风险，所以它应该发生在工程边界上，而不是随手发生。

7. 压缩三步法

压缩动作可以拆成三步：整理、执行、校验。

Step 1：整理

压缩前，先让 AI 列出当前任务状态：

当前目标。
明确限制和禁止项。
已读关键文件。
已改关键文件。
已排除方案。
未解决问题。
下一步计划。
必须回归验证的功能。

这一步只做状态复述，不改代码。

Step 2：执行

基于整理出的状态进行结构化压缩。

Claude Code 可以直接使用带结构要求的 /compact；Codex CLI 需要先发普通消息声明压缩结构，再执行 /compact。

Step 3：校验

压缩后不要立刻继续改代码。先让 AI 基于摘要复述：

当前目标。
已完成工作。
已修改文件。
禁止修改内容。
未解决问题。
下一步计划。
必须验证的功能。

复述准确后再继续；如果有偏差，先纠正。

8. 三类压缩模板

下面三类模板适合沉淀成团队标准。

8.1 任务交接版

适用于功能开发、需求实现、模块改造等阶段性交接场景。

应包含：

当前任务目标。
明确需求。
明确约束与禁止项。
项目背景。
已读文件。
已改文件。
当前技术方案。
已排除方向。
未解决问题。
下一步计划。
回归验证清单。

8.2 Bug 修复版

适用于问题定位、线上问题、回归问题、循环依赖等场景。

应包含：

问题现象。
复现路径。
影响范围。
相关文件。
已排查内容。
已排除原因。
当前判断。
已修改内容。
禁止修改内容。
必须保持不变的功能。
下一步计划。

8.3 代码生成版

适用于新功能、模块改造、大段 HTML / CSS / JS / 配置 / 文档生成。

应包含：

项目背景。
当前需求。
需求边界。
关键约束。
已读文件。
已改文件。
核心实现方案。
兼容性要求。
风险点。
未完成内容。
下一步计划。
回归验证清单。

这三类模板本质上不是格式差异，而是三种工程动作：交接、排障、继续生成。

9. Git 安全网

压缩管理的是上下文，Git 管理的是代码。两者必须配合。

9.1 Checkpoint 提交

每完成一个阶段，在继续下一阶段或压缩前提交一次。

推荐流程：

bash 复制代码

git status
git diff
git add .
git commit -m "checkpoint: before fixing order pagination"

checkpoint 的意义是让回滚成为一条命令，而不是让 AI 再花大量上下文"修回去"。

9.2 分支隔离

长任务使用独立 feature 分支，不要直接在主干分支上让 AI 连续修改。

推荐流程：

bash 复制代码

git switch -c feature/ai-auth-module
# 阶段性 checkpoint commit
git switch main
git merge --squash feature/ai-auth-module
git commit -m "feat(auth): add login/register module"

9.3 多任务并行 worktree

多个任务并行时，使用 git worktree 为每个任务创建独立目录，避免频繁切分支破坏上下文。

bash 复制代码

git worktree add ../my-app-ai feature/ai-refactor
git worktree remove ../my-app-ai

10. 团队落地清单

可沉淀到 onboarding 或 Code Review 检查清单：

禁止一句话让 AI 完成整个大功能。
大功能先产出需求文档，确认后再进入实现。
每个阶段独立 commit，commit message 可使用 checkpoint: 前缀。
长任务开独立分支，不在主干直接推进。
禁止裸用 /compact，必须配结构化模板。
压缩前先复述当前状态。
压缩后先校验摘要内容。
修 Bug 时记录已排除方向。
代码改动后做当前功能和相关旧功能的回归验证。
关键限制写进项目级配置文件，例如 CLAUDE.md 或 AGENTS.md。

11. 结论

AI 编程不是把需求交给模型后等待代码产出，而是用工程流程驾驭模型能力。

拆分任务，能避免 AI 在模糊目标中试错；节制上下文，能减少遗忘和反复；校准摘要，能防止压缩后丢失关键限制；Git 安全网，能让错误快速回滚；团队 SOP，能让个人经验变成可复制流程。

这就是"把 Token 额度花在刀刃上"的真正含义：不是少用 AI，而是让每一次上下文消耗都服务于明确、可验证、可回滚的工程动作。