我怎样把 Claude Code 和 Codex
放进日常开发？

“帮我优化一下这段代码”通常不是一个好任务。

它没有说明慢在哪里、哪些行为不能变、怎样算优化完成。AI 很可能给出一段看起来更整洁的代码，但同时改变事务边界、异常语义或缓存行为。

我现在更习惯先把任务写成一份很短的工程说明：

目标：修复重复提交导致的两次扣减
现象：同一业务请求在 500ms 内可能进入两次
边界：不改变现有接口和数据库结构
验收：先复现，再补失败测试，最后让测试通过
禁止：不提交代码，不修改无关文件

这几行不是提示词技巧。它只是把原本应该对同事说清楚的事情，也对 AI 说清楚。

AI 写代码的速度很快，所以更要先确定它应该往哪里走。

01 / CONTEXT

上下文不是文件越多越好

真正有用的上下文通常只有四类：任务目标、现有约束、相关代码和可以验证的现象。把整个仓库都塞进去，反而容易让注意力散掉。

我会先让工具阅读最小的一组文件，再根据调用关系逐步扩大范围。这样更容易发现它在哪一步做了假设，也能避免一次改动覆盖太多区域。

02 / PLAN

先让它解释，再让它修改

遇到跨模块任务，我不会直接要求“实现”。第一步通常是让 Claude Code 或 Codex 复述现状、指出风险，并给出可以逐项验证的计划。

先不要修改代码。

请回答：
1. 请求从入口到数据库经过哪些关键步骤？
2. 最可能出现重复处理的位置在哪里？
3. 哪些现有行为必须通过测试锁定？
4. 给出最小改动方案和验证顺序。

计划的价值不是让 AI 显得严谨，而是提前暴露理解偏差。它如果连调用链都说不清楚，后面的实现越快，返工越多。

确认方向后，我会把任务切成能单独验证的小步：复现、加测试、最小实现、回归、整理文档。每一步都能停下来检查，而不是等一个巨大补丁生成完才开始猜哪里有问题。

03 / TEST

让测试成为共同的完成定义

“代码写好了”不是完成，“用户看到的行为被验证了”才是。修问题时，我会尽量先得到一个会失败的测试；做新功能时，先把关键路径和边界条件写清楚。

// Arrange: 准备同一业务键的两次请求
// Act:     并发触发处理
// Assert:  只产生一次状态变更和一次扣减

@Test
void should_process_same_business_key_once() {
    // 测试用户能观察到的结果，不锁死内部实现
}

测试还有一个额外价值：它把我和 AI 对“完成”的理解放在同一处。工具可以换、对话可以中断，只要测试保留下来，约束就不会随着上下文一起消失。

04 / DEBUG

调试时，证据比猜测更值钱

AI 很擅长列出“可能原因”，但生产问题通常不缺可能性，缺的是缩小范围的证据。我会把它的任务改成：根据现有日志给出假设，并为每个假设设计一次成本最低的验证。

已知证据：
- 异常只出现在流式请求
- 数据库记录已经创建
- 客户端没有收到 Completed 事件

请按可能性排序给出 3 个假设。
每个假设只提供一个验证动作；不要先修改代码。

验证后再更新判断。这样可以把 AI 从“生成一个听起来合理的答案”拉回真实的排查过程：假设、证据、排除、再假设。

05 / REVIEW

实现者和审查者最好不是同一视角

Claude Code 和 Codex 对我来说没有固定的主次。我更看重分工：一个负责在当前上下文里实现，另一个从更窄的审查任务重新阅读变更。角色可以交换。

第二轮不会问“代码怎么样”，而会给出明确检查面：

只审查这次变更，不修改代码。

重点检查：
- 是否改变了原有事务和异常语义
- 并发、空值、超时与重试边界
- 是否泄露密钥、日志敏感信息
- 测试是否只验证实现细节
- 是否出现超出需求范围的改动

这一步不是为了得到两份同样的答案，而是让实现上下文之外再出现一次质疑。最后的判断仍然由我完成：哪些意见成立、哪些是误报、哪些风险需要在上线前处理。

06 / BOUNDARY

有些动作必须留在人手里

AI 可以读代码、运行测试和整理文档，但涉及真实外部影响的动作，我会保留更清楚的边界。

• 生产数据、密钥和用户隐私，只提供解决问题所需的最小范围。
• 提交、推送、发布、数据库迁移和外部通知，先确认目标与影响。
• 删除、覆盖和批量修改前，先确定精确范围并准备恢复方式。
• 工具给出的依赖版本、接口行为和安全结论，需要回到官方资料或运行结果验证。

这不是不信任工具，而是工程责任不能随着任务一起外包。谁决定上线，谁就要理解变更为什么正确，也要知道失败后怎么退回来。

07 / LOOP

最后形成的是一个循环

AI 没有替代这套工程流程。相反，它让流程中的薄弱部分更快暴露：目标说不清、测试缺失、边界模糊、审查只看风格。把这些环节补起来之后，Claude Code 和 Codex 才不只是“写得更快”，而是成为可以反复使用的工程协作方式。

— 老毕，写于杭州