Vibe Coding 不是“把需求丢给 AI 然后等结果”而是把 AI 当成一个能读仓库、能跑命令、能改代码、能做验证的结对工程师。真正高效的关键不是提示词写得多花而是让 Codex 快速理解你的代码上下文、个人偏好、风险边界和交付标准。本文面向日常写业务代码的程序员尤其是 Java/Spring、MyBatis、前后端联调、日志排查、SQL 修复、老系统维护这类场景。重点讲三件事如何把 Codex 无缝接进自己的开发流程。如何让 Codex 按你的代码风格写出更贴合项目的代码。如何减少无效上下文节省 token同时提升产出质量。一、先换个视角Codex 不是聊天机器人而是代码协作者很多人一开始会这样用 AI帮我写一个接口 帮我优化这段代码 帮我看一下这个报错这种方式能用但效率不稳定。因为 AI 缺少真实上下文不知道项目结构、不知道已有工具类、不知道团队代码风格也不知道你最在意的是“最小改动”还是“彻底重构”。更适合 Codex 的方式是先读这个方法的调用链和 mapper不要直接改代码先定位根因。 只改 service不动 controller 入参复用现有 mapper。 按当前项目风格改改完跑相关测试最后说明风险点。这类指令把三个关键边界说清楚了先做什么读代码、定位、改动、验证。不做什么不改接口、不大范围重构、不引入新框架。交付什么代码、测试结果、风险点、回归场景。二、推荐的协作流程让 Codex 先读代码再写代码高效 Vibe Coding 的核心流程可以抽象成下面这张图。否是提出任务让 Codex 读取相关文件定位入口、调用链、SQL、配置是否明确根因或方案补充日志、截图、需求文档或运行结果限定改动范围实施最小可用改动运行测试或静态校验输出变更说明、风险点、补测建议这套流程适合大多数企业项目因为企业代码的难点通常不是“语法怎么写”而是入口在哪个 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 更容易产出这种风格的代码publicvoidhandleApproveCallback(ApproveCallbackDTOcallback){ContractcontractcontractRepository.selectById(callback.getBusinessId());if(contractnull){return;}if(shouldTriggerFlag(contract)!Objects.equals(contract.getTriggerFlag(),YES)){contractRepository.updateTriggerFlag(contract.getContractId(),YES);}continueOriginalProcess(callback,contract);}Mapper 也尽量保持小而明确updateidupdateTriggerFlagupdate 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 条件直接最小改动涉及审批流、回调、批处理、跨模块数据先梳理方案和风险生产问题、偶发问题、日志链路问题只定位根因先不改大范围重构、接口协议变化先写设计说明和测试矩阵前后端对接先确认入口、权限、字段、展示条件简单任务过度设计会浪费 token也会拖慢开发复杂任务直接开改则容易漏掉历史逻辑。九、最终心法把 Codex 当成会执行的同事而不是许愿池高效使用 Codex 的关键不是“提示词玄学”而是工程协作基本功给它明确目标。给它真实代码入口。告诉它你的代码偏好。限定它不能乱动的边界。让它验证结果。让它说清风险和测试点。当 Codex 真正理解你的项目结构、编码风格和风险偏好后它就不只是帮你补代码而是能帮你完成从“定位问题 - 设计改法 - 实施修改 - 验证 - 输出交付说明”的完整闭环。这才是程序员真正可落地的 Vibe Coding。