前言

最近一段时间，我集中用 GPT-5.5 和 Codex 处理了几个真实工程问题。

用下来最大的感受是：

AI 编程工具真正有价值的地方，不是帮你写几行代码，而是能参与完整的工程流程。

比如：

读项目；
理解架构；
分析 Bug；
设计方案；
生成代码；
补测试；
做代码审计；
整理文档；
辅助重构。

以前我用 AI 写代码，更多是让它生成一个函数、一个脚本、一个接口。

现在更像是把它放进开发流程里，让它参与某个阶段的工作。

但这里也有一个很重要的前提：

AI 不是替你负责项目的人。
它可以帮你提高效率，但最终的方案判断、代码 Review、安全兜底和上线验证，仍然要由开发者来做。

这篇文章就结合几个实战场景，聊聊 GPT-5.5 + Codex 到底适合怎么用。

---

一、GPT-5.5 的定位：更适合做复杂问题的判断和拆解

我对 GPT-5.5 的定位比较明确：

它适合处理复杂问题、做方案判断、理解上下文、分析工程边界。

而不是只拿来生成一段孤立代码。

在真实项目里，很多问题不是“这段代码怎么写”这么简单，而是：

这个需求该不该做？
应该改哪一层？
会不会影响现有功能？
数据库结构要不要调整？
安全风险在哪里？
有没有兼容性问题？
测试应该怎么补？
后续维护成本高不高？

这类问题需要的不只是代码生成能力，而是工程判断能力。

GPT-5.5 在这类任务上，相比普通模型更稳一点。

尤其是当你给它足够的上下文，比如项目结构、报错日志、配置文件、数据库设计、旧实现逻辑，它能沿着问题链路往下拆。

这也是我现在更常用它的方式：

让 GPT-5.5 做方案，让其他模型或 Codex 去执行具体任务。

---

二、实战一：高能力模型出方案，低成本模型做实现

第一个项目是一个多智能体股票分析工具。

这个项目之前已经能跑，但有一段时间没维护了。再次打开时，我没有太多思路，于是先让 GPT-5.5 读项目，再给优化建议。

我没有直接说：

帮我优化一下这个项目。

而是让它先做分析：

请先阅读当前项目结构，结合类似的 AI 股票分析工具，给出下一阶段可以优化的方向。暂时不要修改代码，只输出建议和优先级。

它给出的方向比较清楚，其中一个优先级比较高的点是：

完善股票预警功能。

项目里原本已经有一些预警相关的代码雏形，但主要还是内存态数据结构，重启后会丢失，也缺少完整的 API、Controller 和前端入口。

这时我没有直接让 GPT-5.5 一口气把所有代码写完，而是采用了一个比较实用的策略：

GPT-5.5 负责出方案，低成本模型负责实现。

为什么这么做？

因为方案设计和具体实现对模型要求不同。

方案阶段更需要准确判断边界；
实现阶段更看重批量生成和迭代修改；
如果全部交给高成本模型，成本会比较高；
如果全部交给低成本模型，复杂设计又容易跑偏。

所以我让 GPT-5.5 先输出实现方案，包括：

需要新增哪些表；
哪些接口要补；
哪些页面要加；
消息通知怎么触发；
任务调度怎么设计；
预警条件如何存储；
失败重试和日志怎么处理。

方案定下来之后，再交给低成本模型做初版实现。

这个流程跑下来，效果比单模型一把梭更稳。

低成本模型第一次实现不一定完美，但你把报错和差异再喂回去，它通常能继续修。

最终的体验是：

高能力模型把方向定准；
低成本模型负责堆代码；
开发者负责 Review 和测试；
Codex 负责在项目里推进具体修改。

这套方式很适合预算有限但任务量比较大的开发者。

---

三、实战二：低成本模型扫问题，GPT-5.5 复核修复

第二个场景是代码审计。

同样是那个股票分析项目，功能已经跑通了，但因为之前开发节奏比较快，代码质量和安全细节肯定有遗漏。

这时我没有直接让 GPT-5.5 全项目扫描。

而是把任务拆成两段：

低成本模型负责大范围扫描，GPT-5.5 负责复核和修复。

为什么这么拆？

因为“找问题”和“改问题”不是一回事。

找问题时，需要覆盖面广。
宁可多报几个，也不能漏掉关键风险。

改问题时，需要精准。
不能为了修一个 Bug，引入三个新问题。

所以我先让低成本模型从几个方向审计：

安全风险；
功能正确性；
代码质量；
权限控制；
配置管理；
敏感信息；
测试缺口。

扫完后，它给出了一份问题清单，包括：

API Key 存储方式不安全；
管理接口权限控制不足；
缓存或序列化配置存在风险；
第三方 Key 硬编码；
部分页面功能存在路由参数问题；
测试覆盖不足。

这些问题里，有些确实需要尽快处理。

于是我把审计报告交给 GPT-5.5，让它逐条复核：

哪些问题是真风险；
哪些是误报；
哪些应该优先修；
每个问题怎么最小范围修复；
修复后需要跑哪些测试。

这个流程比直接让一个模型从头干到尾更稳定。

因为低成本模型负责“扫得广”，GPT-5.5 负责“改得准”。

我现在越来越觉得，多模型协作是 AI 编程里非常实用的方式。

不是所有任务都要用最贵的模型，也不是所有任务都适合便宜模型。

关键是把不同模型放到它擅长的位置。

---

四、实战三：多模型配置中心改造

第三个项目是一个 AI 面试辅助平台，里面包含简历分析、模拟面试、语音面试、知识库 RAG、多 Provider 模型配置等功能。

项目技术栈大概是：

后端：Spring Boot、Java、JPA、PostgreSQL、pgvector、Redis
前端：React、TypeScript、Vite、TailwindCSS
AI 能力：多模型配置、RAG 知识库、简历分析、模拟面试

项目里原本已经有模型配置页面，可以配置不同厂商的模型。

但初版设计有几个问题：

配置主要依赖 YAML 或环境变量；
重启后运行时配置不够稳定；
聊天模型和向量模型没有清晰拆分；
EmbeddingModel 在启动时就固定了；
前端没有解释 Chat Model 和 Embedding Model 的区别。

这些问题在本地测试时可能不明显，但一旦部署到真实环境，就会变得很麻烦。

比如：

YAML 不适合作为运行时动态配置来源；
Jar 包内配置不可写；
多实例部署会出现配置不一致；
Redis 不应该作为唯一事实来源；
模型配置需要数据库持久化；
API Key 不能随便明文存储。

我给 GPT-5.5 的需求大概是：

当前项目的模型配置重启后会丢失，而且 Chat Provider 和 Embedding Provider 没有拆开。请先阅读项目结构，分析问题，再给出改造方案。暂时不要直接改代码。

它没有一上来写代码，而是先定位关键文件，再给出方案。

这一点很重要。

真实项目里，最怕模型在没读懂项目之前，直接凭经验造一套架构。

---

五、配置持久化：DB 做事实来源，YAML 只做启动种子

原来的配置方式更像开发环境临时方案。

看起来能跑，但实际部署会出现问题：

配置文件不适合运行时频繁修改；
多实例部署无法保证一致；
重启后配置状态不稳定；
运行时配置和 Spring 生命周期容易冲突。

GPT-5.5 给出的方向是：

数据库作为模型配置的事实来源；
Redis 只做缓存；
YAML 只作为启动种子；
运行时配置以 DB 为准；
配置变更后刷新 Registry 缓存。

最后设计上拆出了两类数据：

Provider 配置；
全局默认配置。

可以简单理解为：

llm_provider_config
llm_global_setting

这样改完后，模型配置不再依赖临时文件，而是进入数据库管理。

这更符合真实项目的使用方式。

---

六、API Key 不能轻易明文入库

这个点我单独拿出来说。

在模型配置中心里，API Key 是绕不过去的。

有些人会觉得：

反正原来 .env 里也是明文，那数据库明文存一下问题不大。

但我不太认同这个判断。

因为 .env 明文和数据库明文不是一个风险级别。

数据库可能会被：

备份；
查询；
导出；
只读账号访问；
日志采集；
测试环境同步。

API Key 一旦明文进库，暴露面会明显变大。

所以这次改造里，我更倾向于做应用层加密。

比如使用 AES-GCM 这类方式加密存储，读取时再解密使用。

不一定说第一版就要做到非常复杂，但至少不能把 Key 当普通字段随便存。

AI 在这里能帮你写实现，但安全边界必须由开发者自己确认。

---

七、RAG 场景必须拆分 Chat Provider 和 Embedding Provider

这个问题非常典型。

很多多模型系统一开始会设计一个默认 Provider。

比如：

default-provider -> ChatClient
default-provider -> EmbeddingModel

看起来很简单。

但一到 RAG 场景就出问题。

因为聊天模型和向量模型不是一回事。

有些模型适合聊天，但不支持 Embedding。
有些厂商提供聊天模型，也提供向量模型。
有些模型虽然接口兼容，但向量维度不同。

如果默认 Provider 切到一个不支持 Embedding 的模型，普通对话可能还能跑，但知识库向量化会直接失败。

所以更合理的设计是：

默认聊天 Provider 单独配置；
默认向量 Provider 单独配置；
ChatClient 和 EmbeddingModel 分别管理；
向量化任务每次从 Registry 获取当前默认 Embedding Provider。

核心思路类似：

@Bean
public EmbeddingModel embeddingModel(LlmProviderRegistry registry) {
    return new EmbeddingModel() {
        @Override
        public EmbeddingResponse call(EmbeddingRequest request) {
            return registry.getDefaultEmbeddingModel().call(request);
        }
    };
}

这个设计的重点不是代码本身，而是绕开固定 Bean 生命周期的问题。

VectorStore 注入的仍然是一个 EmbeddingModel，但背后会动态委托到当前配置的向量模型。

这样运行时切换默认向量模型才有意义。

---

八、Embedding 维度是 RAG 里非常容易踩的坑

在 RAG 项目里，Embedding 维度非常关键。

很多人只关注模型名能不能调用，却忽略了向量维度。

比如数据库里的 pgvector 表是 1024 维，但某个 Embedding 模型默认返回 2048 维。

这时模型名、API Key、Provider 都可能是对的，但写入数据库时仍然会报错。

这类问题非常隐蔽。

因为错误不是出在调用模型阶段，而是出在写库阶段。

所以 RAG 系统里，Embedding 配置不能只存模型名。

至少还应该考虑：

向量维度；
距离函数；
向量表结构；
旧数据是否需要重新向量化；
不同知识库是否允许不同维度；
切换模型后如何兼容旧数据。

第一版如果不想做太复杂，可以先统一维度。

比如整个系统固定 1024 维。

后续如果要支持多维度，再考虑按知识库隔离，或者设计多张向量表。

这里 GPT-5.5 的价值在于：当真实错误出现后，它能比较快把问题从“模型不能用”纠正到“向量维度不匹配”。

这比只会跟着报错改一行代码要强很多。

---

九、GPT-5.5 + Codex 怎么配合更有效？

用 Codex 时，我现在有几个比较固定的习惯。

1. 让模型先读项目，不要一上来改代码

真实项目里，不要直接说：

帮我优化一下。

更好的方式是：

请先阅读项目结构，定位和模型配置相关的文件，说明当前实现方式和可能的问题。暂时不要修改代码。

先读懂，再动手。

2. 让高能力模型做复杂判断

比如：

架构方案；
安全策略；
数据库设计；
RAG 链路；
Provider 抽象；
多模型协作方案。

这些更适合交给 GPT-5.5。

3. 让低成本模型做批量执行

比如：

生成重复代码；
补 DTO；
写简单接口；
扫代码质量；
做初步代码审计。

这些可以交给成本更低的模型。

4. 用 AGENTS.md 固化项目规则

如果项目里经常用 Codex，可以写一个 AGENTS.md。

里面放：

启动命令；
测试命令；
代码风格；
禁止修改的目录；
API 兼容规则；
数据库修改规范；
提交前检查项。

示例：

# AGENTS.md

## 项目约定

- 修改后端代码后，请运行相关单元测试。
- 不要在用户确认前新增生产依赖。
- API 字段变更必须保持向后兼容。
- 不要修改 generated 目录。
- 最终总结需要列出改动文件、验证结果和风险。

如果你第二次提醒 Codex 同一件事，就应该考虑把它写进 AGENTS.md。

---

十、Codex 使用时，不要一上来开最大权限

Codex 能读文件、改文件、执行命令，所以权限一定要谨慎。

新手建议：

先让它只读；
再允许小范围修改；
高风险命令必须审批；
重要项目先打 Git 检查点；
改完必须看 diff；
能跑测试就跑测试。

不要上来就让它全自动执行。

尤其是看到这些命令时要谨慎：

rm -rf
sudo
curl ... | sh
npm install unknown-package

如果看不懂，就让它解释：

请解释这条命令要做什么，为什么必要，有没有更安全或范围更小的替代方案。

AI 可以提效，但权限边界不能放松。

---

十一、我现在常用的一套 AI 编程方法

把这几个项目的经验总结下来，我现在比较常用这套流程：

1. 先让 GPT-5.5 或 Codex 阅读项目结构；
2. 要求它暂时不要修改代码；
3. 让它列出问题、风险和不确定点；
4. 对复杂问题，让 GPT-5.5 先出方案；
5. 对重复实现，让低成本模型或 Codex 执行；
6. 每次只改一个小范围；
7. 改完看 diff；
8. 能跑测试就跑测试；
9. 安全和架构相关改动必须人工 Review；
10. 最后再决定是否提交。

这套流程的核心不是“让 AI 多干活”，而是“让 AI 在可控边界内干活”。

边界越清楚，结果越靠谱。

---

十二、GPT-5.5 这次实战的优点和不足

优点

这次使用中，GPT-5.5 给我的感觉是：

能顺着工程链路继续追问题；
不会只盯着报错改一行；
对配置中心、RAG、Provider 抽象这类问题理解较好；
能根据真实日志快速修正判断；
适合做方案设计和风险复核；
和 Codex 搭配时效率比较高。

不足

但它也不是完美的。

几个点仍然需要开发者把关：

模型名称不能靠记忆，要查文档；
OpenAI-compatible 不代表所有工具调用细节都一致；
Embedding 维度问题需要真实运行才能暴露；
安全策略不能完全交给模型判断；
复杂项目里仍然要人工 Review；
生成代码仍然可能遗漏测试和边界条件。

所以我不会把 GPT-5.5 当成“自动工程师”。

它更像是一个很强的高级助手。

---

十三、性价比到底怎么看？

很多人讨论 AI 编程工具时，只看模型能力。

但真实使用里，成本也很重要。

如果所有任务都交给最强模型，效果可能不错，但成本不一定适合长期使用。

更合理的是分工：

任务	建议模型策略
架构设计	用高能力模型
安全复核	用高能力模型
项目级问题判断	用高能力模型
批量生成代码	可用低成本模型
初步代码扫描	可用低成本模型
文档整理	可用中低成本模型
最终 Review	开发者人工把关

一句话：

贵模型负责判断，便宜模型负责执行，人负责兜底。

这比单纯追求“全程最强模型”更适合真实开发。

---

总结

这次 GPT-5.5 + Codex 的实战体验，让我更加确认一点：

AI 编程工具真正的价值，不是单纯帮你写代码，而是帮助你把工程任务拆开、推进、验证和复盘。

GPT-5.5 适合：

复杂问题分析；
架构方案设计；
安全风险复核；
RAG 链路排查；
多模型配置中心改造；
关键 Bug 复核修复。

Codex 适合：

读项目；
改代码；
补测试；
跑命令；
看 diff；
推进小步任务。

低成本模型适合：

批量实现；
代码扫描；
文档整理；
重复性任务。

真正稳定的 AI 编程流程，不是让一个模型从头干到尾，而是把不同模型放到合适的位置。

官方充值地址：点此直接进入（有质保有发票）

最后一句话：

GPT-5.5 + Codex 确实很强，但最有效的用法不是“让 AI 接管项目”，而是让 AI 在清晰边界里帮你做方案、写代码、查问题、补测试，最后由开发者来把关。