AI 编程实践：上下文、验证与成本AI 编程实践：上下文、验证与成本

本文面向已完成基础接入、希望改进 AI 编程流程的读者。工具参数可参照 Omnigate 的 Claude Code 进阶 文档；首次使用可以从快速开始入手。

这些记录来自日常编码与问题排查，主要关注信息准备、任务拆分和验证。具体做法可以根据项目规模、模型和工具配置调整。

关于 Claude 生成代码、Codex 独立审查的配合方式，见AI 编程工作流：实现、审查与决策。

一、先准备与任务相关的上下文

模型选择和上下文质量都会影响编码结果。项目约定、错误信息和相关文件越清楚，模型就越容易围绕实际问题工作。

调整配置时，可以先检查 CLAUDE.md 是否包含必要的项目约定，再判断是否需要更换模型或增加插件。

例如，修复 bug 前先整理复现步骤、报错全文和相关文件路径。这些信息有助于减少试探性搜索；能节省多少时间和 token，需要结合实际任务观察。

二、根据任务连续性选择 /clear 或 /compact

对话长度不能单独说明费用。历史输入能否命中缓存、缓存输入如何计费，都会影响成本。频繁 /clear 可能让模型重新读取项目结构和任务背景。

切换到完全无关的任务时，可以用 /clear 清理旧上下文。同一件任务积累了较长历史时，可以考虑 /compact，保留要点并压缩过程。

我通常结合状态栏观察上下文占用，在 70% 左右考虑压缩。这个比例是操作习惯，实际时机仍取决于任务需要保留的信息。

三、按任务选择模型

可以把任务是否清晰、结果是否容易验证，以及返工成本作为选择模型的依据。一种分配方式是：

• 改一两行、写测试、格式化、写 commit message 或翻译文档：任务明确时，可以先尝试小模型（Haiku 一类），再检查结果。
• 日常开发：可以从中档模型（Sonnet 一类）开始，结合完成质量和费用判断是否合适。
• 架构决策、复杂重构、难以定位的 bug 或性能问题：可以考虑能力更强的模型，同时评估返工成本是否抵消了价格差异。

容易验证的任务便于尝试成本较低的方案；涉及复杂判断的任务，则需要同时考虑模型能力和审查投入。

使用相关配置时，也可以检查 ANTHROPIC_DEFAULT_HAIKU_MODEL。生成会话标题、做摘要等后台任务所用的模型，也是观察用量的一部分。

四、把任务拆成可以验证的改动

同时处理多个不相关的需求，容易让改动范围和验收标准变得模糊。审查时也更难判断每处修改对应哪个需求。

可以把这些需求拆开，每部分完成后验证一次。这样更方便定位问题，也便于决定哪些改动需要继续调整。

五、把验证纳入执行流程

让模型在改完代码后运行测试和类型检查，可以为结果提供直接依据。把对应命令写进 CLAUDE.md，在 settings.json 的 allow 列表中配置所需权限，并明确要求改完运行检查、根据失败结果继续修复。

测试输出能帮助模型定位和修改问题，但验证范围仍要与任务对应。

自动格式化这类需要每次执行的步骤，可以通过 hook 固定下来。

六、用计划模式确认较大的改动

改动超过三个文件时，我通常先用 plan 模式确认方案。文件数只是一个提示，更需要关注的是双方是否理解改动范围和处理方式。

可以先让模型提出方案，再针对具体步骤补充或纠正。实现之前澄清分歧，有助于减少后续修改大段 diff 的工作。

七、把重复提示整理成自定义命令

反复使用的 prompt 可以保存成文件，逐步补充边界条件、输出格式和执行范围，方便复用与维护。

常见用途包括审查当前 diff、修复失败测试、为模块补充测试，以及解释代码的实现原因。

八、按需要接入工具

接入 MCP 服务、插件或 agent 集合时，可以先确认它解决哪个具体问题。工具定义会占用上下文，过多选项也可能增加选择工具的难度；第三方 hook 和脚本的执行权限则需要单独检查。

这里使用的配置是 context7，用于查阅文档；做前端时再启用 playwright 或 chrome-devtools。

对于第三方 agent 集合，可以先阅读相关文件，再选择需要的部分接入。

九、按任务特点安排人工审查

样板代码、补测试、跨文件的机械性重构、解释陌生代码库或报错，以及一次性脚本，都是可以交给 AI 尝试的任务。

业务决策、资料不足的问题、依赖隐含约定的老系统改造，以及缺少 profile 数据的性能排查，则需要补充背景并投入更多人工判断。

一种需要特别检查的情况是：代码看起来合理，但依据了错误的前提。例如，模型可能假设某个函数是幂等的。审查关键路径时，需要核对这些假设是否成立。

阅读资料时也需要核对回答是否得到原文支持。Conuo 的阅读问答与笔记流程用一份带公式和图像的资料，说明怎样查引用、检查解释，再整理为可复查的学习内容。

十、用实际记录检查成本

除了模型单价，还可以检查以下用量来源：

• 上下文不完整导致的反复返工
• 同一对话混合多个无关任务
• 简单任务使用了超出需要的模型档位
• 没有设置合适的 max_tokens，输出长度超出实际需要

这些因素各占多少，需要查看实际记录。可以定期打开 Omnigate 用量日志，检查 token 数异常的请求，以及是否存在反复传入完整文件的情况。

持续调整流程

工具和任务会变化，配置也需要结合实际结果调整。可以从一个常见任务入手，观察上下文是否充分、检查是否有效，以及费用主要花在哪里。

有问题欢迎联系我。

本文原载于 Omnigate。