程序员如何无缝衔接 Codex 做高效 Vibe Coding：更懂你的代码，也更省 token

努力努力在努力！

366人浏览 · 2026-06-29 13:22:40

努力努力在努力！ · 2026-06-29 13:22:40 发布

Vibe Coding 不是“把需求丢给 AI 然后等结果”，而是把 AI 当成一个能读仓库、能跑命令、能改代码、能做验证的结对工程师。真正高效的关键，不是提示词写得多花，而是让 Codex 快速理解你的代码上下文、个人偏好、风险边界和交付标准。

本文面向日常写业务代码的程序员，尤其是 Java/Spring、MyBatis、前后端联调、日志排查、SQL 修复、老系统维护这类场景。重点讲三件事：

如何把 Codex 无缝接进自己的开发流程。
如何让 Codex 按你的代码风格写出更贴合项目的代码。
如何减少无效上下文，节省 token，同时提升产出质量。

一、先换个视角：Codex 不是聊天机器人，而是代码协作者

很多人一开始会这样用 AI：

帮我写一个接口
帮我优化这段代码
帮我看一下这个报错

这种方式能用，但效率不稳定。因为 AI 缺少真实上下文：不知道项目结构、不知道已有工具类、不知道团队代码风格，也不知道你最在意的是“最小改动”还是“彻底重构”。

更适合 Codex 的方式是：

先读这个方法的调用链和 mapper，不要直接改代码，先定位根因。

只改 service，不动 controller 入参，复用现有 mapper。

按当前项目风格改，改完跑相关测试，最后说明风险点。

这类指令把三个关键边界说清楚了：

先做什么：读代码、定位、改动、验证。
不做什么：不改接口、不大范围重构、不引入新框架。
交付什么：代码、测试结果、风险点、回归场景。

二、推荐的协作流程：让 Codex 先读代码，再写代码

高效 Vibe Coding 的核心流程可以抽象成下面这张图。

这套流程适合大多数企业项目，因为企业代码的难点通常不是“语法怎么写”，而是：

入口在哪个 controller / job / listener。
数据从哪个 mapper 或 Feign 调用来。
哪个配置覆盖了源码默认值。
哪些老逻辑不能破坏。
这次改动会不会影响历史单据、审批流、批处理、定时任务。

所以不要急着让 Codex “直接写”。更推荐先让它完成一次仓库级理解：

先帮我找这个功能的入口、核心 service、mapper SQL 和配置项。
不要改代码，先说清楚当前逻辑和可能风险。

等它把链路说清楚，再进入实现阶段：

按你刚才定位的链路改，改动范围控制在 service + mapper。
不要动 controller 入参，不新增无关工具类。

三、让 Codex 更懂你的代码风格

想让 Codex 写出来的代码像你自己写的，最有效的方法不是让它“写得优雅”，而是明确你的工程偏好。

1. 明确你的默认编码偏好

比如在 Java/Spring 项目里，可以提前告诉 Codex：

我的默认偏好：
- 依赖注入优先用 @RequiredArgsConstructor + private final。
- 小改动不要过度抽 helper。
- 业务判断尽量复用当前流程里已有对象，避免重复查询。
- SQL 优先复用现有 mapper 风格。
- 不要为了风格统一改无关代码。

这比一句“按项目风格写”更有效。

如果当前类本身是老风格，也可以明确：

这个类保持现有写法，不做注入方式重构，只补这次需求需要的逻辑。

这样 Codex 就不会为了“看起来更现代”把一堆无关代码顺手重构掉。

2. 让 Codex 复用项目已有结构

很多 AI 生成代码的问题，不是不能跑，而是“不像这个项目里的代码”。

更好的提示方式：

先搜索项目里类似的审批回调、定时任务、mapper 查询写法。
新逻辑按已有模式实现，不要发明新的抽象。

适合 Codex 先看的信息包括：

同类 service 的实现方式。
现有 mapper XML 的动态 SQL 写法。
枚举、常量、错误码的定义位置。
统一返回对象、异常处理方式。
测试类或已有验证脚本。

3. 用“反例”约束它

如果你不想要某类方案，直接说出来：

不要新增数据库表。
不要改接口入参。
不要把逻辑拆成很多 helper。
不要为了这个小需求引入新依赖。
不要重新查询数据库，当前对象里已有字段够用。

这些约束能显著减少返工。

四、一个更贴近日常业务代码的例子

假设你要改一个合同审批完成后的状态回写逻辑。不要直接说：

帮我加个审批完成后更新字段的逻辑

可以这样说：

先看审批回调入口、合同 service 和 mapper。
需求：审批完成后，如果当前合同满足某个业务条件，更新一个标识字段。
要求：
1. 不改 controller 入参。
2. 尽量复用回调里已经查出来的合同对象。
3. 只在满足条件时更新，值一样不要重复更新。
4. 改完说明影响哪些流程，并给测试场景。

Codex 更容易产出这种风格的代码：

public void handleApproveCallback(ApproveCallbackDTO callback) {
    Contract contract = contractRepository.selectById(callback.getBusinessId());
    if (contract == null) {
        return;
    }

    if (shouldTriggerFlag(contract)
            && !Objects.equals(contract.getTriggerFlag(), YES)) {
        contractRepository.updateTriggerFlag(contract.getContractId(), YES);
    }

    continueOriginalProcess(callback, contract);
}

Mapper 也尽量保持小而明确：

<update id="updateTriggerFlag">
    update contract
    set trigger_flag = #{triggerFlag},
        last_update_date = now()
    where contract_id = #{contractId}
</update>

这类代码的重点不是“多高级”，而是：

改动点少。
逻辑位置清晰。
不破坏原流程。
不重复查询。
容易给测试同学说明回归范围。

五、怎么节省 token：少塞无效上下文，多给关键线索

很多人觉得 AI token 消耗大，本质原因是上下文给得太散。与其一次性贴一堆无关文件，不如让 Codex 自己在仓库里按目标搜索。

1. 不要一上来贴完整文件

低效方式：

我把 controller、service、mapper、日志全贴给你，你看下。

更省 token 的方式：

需求关键词是“合同审批完成回写标识”。
你先在仓库里搜索相关 controller、service、mapper。
只读取必要文件，先告诉我调用链。

Codex 可以通过 rg、git diff、mvn test、日志文件搜索等方式自己收集上下文。你只需要给它：

需求关键词。
报错关键字。
业务单号或链路 ID。
你希望限制的改动范围。
哪些文件或模块一定要看。

2. 用“任务边界”替代“长篇背景”

高效提示词通常长这样：

目标：修复导入后列表只展示第一页的问题。
范围：先只定位原因，不改代码。
线索：后端返回的是 List，前端分页默认 pageSize 可能截断。
输出：入口文件、根因、最小改法、测试点。

这比几百字背景更有价值。

3. 让 Codex 先总结再继续

当任务变长时，可以让 Codex 在关键节点压缩上下文：

先总结目前已确认事实、未确认假设、下一步要看的文件。

这样后续继续改代码时，不需要把所有历史再重复一遍。

六、不同场景下的提示词模板

1. 改业务代码

先读相关 controller / service / mapper，确认现有逻辑。
按最小改动实现，不做无关重构。
优先复用已有对象和 mapper。
改完给我：
1. 改了哪些文件
2. 核心逻辑
3. 风险点
4. 建议测试场景

2. 只定位原因，不改代码

不要改代码，只定位根因。
结合日志、调用链和配置说明：
1. 具体失败点
2. 为什么会失败
3. 哪些证据能证明
4. 最小修复方向

3. 看今天提交有没有问题

按 code review 的方式看今天提交。
优先找行为风险、回归风险、漏测点。
不要只总结改了什么。
输出按严重程度排序，并标出文件和方法。

4. 前后端联调

先确认入口可见性、权限、展示条件和接口字段。
不要扩大 API 字段。
如果后端已有字段能复用，优先复用。
最后给前端对接说明和测试点。

七、我的实践建议：把个人偏好沉淀成一份 Codex 规则

如果你经常用 Codex，建议维护一份个人规则，例如：

我的 Codex 协作规则：
1. 默认中文回复。
2. Java 改动保持最小范围。
3. 不确定时先定位，不直接改。
4. 代码事实、推测、环境阻塞要分开说。
5. SQL / MyBatis 改动要给测试 SQL 或回归场景。
6. 日志问题优先按 TID / requestId 串联上下游。
7. 不要暴露公司内部地址、密钥、真实日志和生产数据。

这份规则越贴近你的真实工作，Codex 越容易写出“像你自己会写”的代码。

八、什么时候该让 Codex 多想，什么时候该让它快改

不是所有任务都需要复杂流程。

任务类型	推荐方式
一行判空、小字段映射、简单 SQL 条件	直接最小改动
涉及审批流、回调、批处理、跨模块数据	先梳理方案和风险
生产问题、偶发问题、日志链路问题	只定位根因，先不改
大范围重构、接口协议变化	先写设计说明和测试矩阵
前后端对接	先确认入口、权限、字段、展示条件