AI 编程助手接管了越来越多的代码输入工作，但工程师并没有因此卸下责任。新的核心任务是管理模型的注意力：让每次调用只读取必要上下文，选择与任务匹配的模型，并在自动化越界前及时止损。
Token 消耗并不只是账单问题。上下文膨胀会增加延迟，稀释关键指令，还可能让模型遗忘约束或产生幻觉。真正有效的优化，不是把提示词压缩到难以理解，而是建立一条短、清晰、可验证的反馈链路。
把模型能力当成可逐级扩容的资源
面对一个新任务，可以从速度、成本和推理能力较均衡的默认模型开始，例如来源中建议的 Gemini 3.5 Flash 与 Medium reasoning。执行过程中再根据迹象升级，而不是一开始就调用最昂贵的模型。
适合升级模型或提高推理等级的信号包括：
- 同一问题连续失败，修复开始原地打转；
- 任务需要跨多个模块设计接口或迁移数据；
- 助手需要经过很多轮搜索才能形成可执行方案；
- 现有约束互相冲突，需要做系统级权衡。
这是一种分层调度策略：小模型处理代码搜索、格式化和局部修复，大模型处理架构设计、复杂调试与最终审查。Token 优化的重点不是永远使用小模型，而是避免把高推理预算浪费在机械工作上。
把 11 条原则组织成四个工程动作
1. 复用规则：Skill、脚本与项目说明
不要在每次对话里重复工作流、测试命令和目录约定。可以把稳定规则写入 AGENTS.md，把特定任务封装成带有 SKILL.md 和脚本的可复用 Skill。这样，助手不必反复搜索文档、检查环境或等待你重新解释团队惯例。
如果你经常纠正同一种行为，例如“修改 API 后必须运行契约测试”，应该修改持久规则，而不是继续追加纠正提示。反复发生的偏差，通常意味着指令系统需要修复。
2. 先调查再写入，并把重复劳动交给工具
代码修改前先运行只读命令，能显著减少试错。例如先定位入口、读取测试脚本，再决定修改范围：
# 在仓库根目录运行；按项目语言调整文件类型和测试命令
rg --files | sed -n '1,120p'
rg -n "TODO|FIXME|deprecated" src tests
rg -n '"(test|lint|build)"' package.json
git status --short
git diff --stat
格式化、日志提取和批量检查应交给脚本或官方 CLI。一个命令能稳定完成的工作，不值得让模型在多轮对话中逐文件操作。
3. 拆分规划与执行，隔离高输出任务
复杂任务可以采用“长上下文规划、干净会话执行”的方式：让高推理会话分析系统并产出详细计划，再让低 Token 会话按计划逐项实现。每完成一个里程碑，就通过提交、测试报告或计划文件保存状态。上下文变得拥挤时，可以从最近的稳定检查点重新开始。
深度调研、日志归纳，以及前后端相互独立的工作，也适合委派给子代理。主会话只接收结论、变更和风险，不必吞下每个子任务的完整轨迹。
这里的边界很重要：拆分任务必须同时定义输入、交付物和验收命令。否则，子代理只是把上下文成本从一个窗口搬到了另一个窗口。
4. 提前验证，并为自治循环安装刹车
测试应尽早自动化。先运行构建、单元测试和功能测试，再把昂贵的浏览器冒烟测试留到里程碑交付前。这样，大多数低成本错误能在启动浏览器和视觉检查之前被发现。
自治循环必须设置最大轮数、时间预算和明确停止条件。不要让代理持续轮询状态；能使用 CI 回调、文件事件或任务完成通知时，应采用事件驱动唤醒。
一个可改造的低 Token 工作流
下面是一个假设使用 Node.js 的最小项目示例。它把项目规则、验证入口和循环预算写进仓库。使用其他语言时，只需替换命令。
AGENTS.md：
# Repository Instructions
## Scope
- Read the target file and its nearest tests before editing.
- Do not modify generated files or lockfiles unless required.
- Keep changes within the requested module.
## Verification
- During implementation: npm run lint && npm test
- Before handoff: npm run build && npm run test:e2e
## Stop Conditions
- Stop after two failed attempts at the same fix.
- Report the failing command and the smallest relevant error excerpt.
- Do not poll CI status; wait for an event or ask for a manual check.
scripts/verify.sh：
#!/usr/bin/env bash
set -euo pipefail
mode="${1:-fast}"
npm run lint
npm test
if [[ "$mode" == "full" ]]; then
npm run build
npm run test:e2e
fi
运行方式：
chmod +x scripts/verify.sh
# 每次局部修改后执行低成本验证
./scripts/verify.sh fast
# 里程碑交付前执行完整验证
./scripts/verify.sh full
还可以给代理一个明确、范围受控的任务说明：
修复 src/auth/session.ts 中 refreshSession 的过期时间计算。
上下文：tests/auth/session.test.ts 的 “refresh keeps absolute expiry” 用例失败。
期望：刷新访问令牌不能延长 absoluteExpiresAt。
范围：只修改 src/auth/session.ts 和直接相关测试。
验证：运行 ./scripts/verify.sh fast。
停止条件：如果同一用例修复两次后仍失败，停止并报告根因假设。
这类提示没有逐行指挥模型，却给出了目标文件、失败用例、正确行为、修改边界、验证命令与停止条件。即使有少量拼写错误，也通常比“检查一下认证为什么有问题”更有效。
偏航时不要继续堆提示词
当代理已经建立了错误假设，连续追加“再试一次”“注意不要改这里”等提示，往往会让错误轨迹继续占据上下文。如果你知道最近一步是错的，应使用撤销功能或恢复到明确的文件检查点，再从干净状态提供正确约束。
需要注意，回退前必须确认工作区中没有其他人的未提交变更。实践中可以先检查：
git status --short
git diff -- src/auth/session.ts tests/auth/session.test.ts
不要把粗暴回退当作默认动作。检查差异、保存有价值的人工修改，再撤销确定错误的部分。
新话题使用新会话
同一问题的后续修复可以留在原会话中，因为现有上下文可能包含有用的决策和测试结果。一旦任务从“修复会话过期”切换成“设计计费系统”，就应该创建新会话。让模型只加载当前任务需要的信息，通常能得到更短、更准确的回答。
判断是否应该换会话，可以问三个问题：
- 新任务是否依赖当前会话中的核心决策？
- 当前上下文是否已有大量无关日志、失败尝试或旧代码？
- 能否用一份短交接文档完整描述新任务？
如果后两个答案为“是”，新会话通常更合适。
落地检查表
采用这些原则时，可以从以下几项开始：
- 默认使用均衡模型，遇到明确复杂度信号再升级；
- 把重复规则写入
AGENTS.md或 Skill； - 修改前运行只读调查命令；
- 用脚本和官方 CLI 处理可重复工作；
- 将规划、执行和高输出研究拆成边界清楚的任务；
- 在开发阶段运行快速测试，交付前再做昂贵验证；
- 同一修复连续失败时停止、回退并重新建立上下文；
- 给自治循环设置轮数、时间和成本上限；
- 话题改变时开启新会话。
Token 经济学归根结底是注意力工程。节省 Token 不是让模型少说几个字，而是减少无效搜索、错误轨迹、重复说明和无边界自治，把计算资源与人的审查精力留给真正影响软件质量的决策。