1. 从能用到好用之间隔着28天的距离如果你最近在开发者圈子里混大概率会频繁听到一个词——Codex。不是那个已经消失在历史里的模型代号而是现在被集成进各种开发工具链里的代码智能体。我身边不少朋友已经把它接进了日常开发流里有人用它写单元测试有人用它做代码审查还有人直接让它根据注释生成整个模块的骨架。但有意思的是大家聊得最多的不是它能不能用而是它到底好不好用。这两个字的差别恰恰是过去一个月里我花时间最多的地方。我给自己定了一个28天的周期把Codex深度嵌入到三个不同类型的项目里——一个后端服务、一个数据处理脚本集、一个前端组件库——每天记录它的表现、我的调整、以及那些让我拍桌子或者拍大腿的瞬间。这篇文章就是这28天的完整复盘。我会讲清楚Codex在真实项目里到底能做什么、哪些场景下它表现惊艳、哪些地方它会让你抓狂、以及最重要的——怎么通过配置和流程设计把它从一个偶尔帮倒忙的实习生变成靠谱的结对伙伴。如果你正在考虑引入Codex或者已经用了但觉得效果一般这篇内容应该能帮你省下不少试错时间。2. 第一个七天新鲜感掩盖下的真实能力边界2.1 初始配置决定了后面27天的体验上限很多人拿到Codex的第一反应是直接开对话框扔一段需求进去然后期待它吐出完美代码。我第一天也是这么干的结果就是浪费了大半天时间在反复调整提示词上。后来我意识到一个问题Codex不是一个通用的聊天机器人它的表现高度依赖于你给它的上下文环境。我做的第一件事是建立了一个项目级的配置文件。这个文件里我定义了四样东西项目的技术栈版本、代码风格规范、目录结构说明、以及常用工具库的清单。听起来很简单对吧但就是这四样东西让Codex的输出质量在第二天就有了肉眼可见的提升。具体来说技术栈版本我精确到了小版本号比如Python 3.11.4、Node 20.9.0。为什么这么细因为Codex在生成代码时会根据版本推断可用的语法特性和标准库API。你告诉它Python 3.8和3.11它给出的代码可能完全不同——前者可能用typing.List后者直接用list[int]。代码风格规范我直接贴了一份精简版的PEP 8加上项目特有的命名约定比如所有异步函数必须以async_开头。目录结构说明让Codex知道新文件应该放在哪里而不是一股脑全扔在根目录。工具库清单则避免了它重复造轮子——我明确告诉它项目里已经装了httpx、pydantic、loguru它就不会再建议我用requests或者自己写日志模块。提示这个配置文件不需要多复杂一页Markdown就够了。但一定要在每次新会话开始时让Codex先读一遍。我试过偷懒跳过这一步结果就是它开始用我已经废弃的旧API改起来比自己写还累。2.2 代码补全和代码生成是两件完全不同的事前三天我主要测试的是代码补全——就是在编辑器里写一半让Codex接着往下写。这个场景下它的表现相当不错尤其是写那些模式化的代码时比如数据类的定义、API路由的注册、测试用例的骨架。我统计了一下在写CRUD接口的时候Codex的补全接受率大概在70%左右也就是说它给出的建议里有七成我直接按Tab采纳了。但到了代码生成——也就是我给一段自然语言描述让它从零生成一个完整函数或模块——接受率直接掉到了30%以下。问题出在哪儿我仔细对比了那些被拒绝的生成结果发现主要原因是Codex倾向于过度实现。比如我让它写一个读取配置文件并返回字典的函数它给我生成了一个带缓存、带环境变量覆盖、带类型校验、带异常重试的完整模块。功能上没错但这不是我想要的——我只需要一个简单的读取函数其他的逻辑我自己会加。这个发现让我调整了策略对于代码生成我开始用约束式提示。不是简单地说写一个读取配置的函数而是明确告诉它只做三件事打开文件、解析YAML、返回字典。不要加缓存不要加校验不要加日志。异常处理只捕获文件不存在的情况。这样约束之后生成结果的可用性明显提升。2.3 那些让我意外的聪明时刻当然这七天里也有不少让我惊喜的瞬间。有一次我在写一个数据清洗脚本需要处理一个嵌套很深的JSON结构。我写了个注释描述需求Codex生成的代码不仅正确处理了嵌套还自动加了一个我没想到的边界情况——当某个中间层级的键不存在时它用.get()方法做了安全访问而不是直接索引。这个细节我后来检查时才发现如果直接索引遇到脏数据就会抛异常。还有一次更绝。我在写一个前端组件需要根据不同的状态显示不同的图标。我本来准备写一个长长的if-else链Codex直接给我生成了一个映射对象然后用状态值作为键去查找。代码简洁了很多而且扩展性更好——以后加新状态只需要在映射对象里加一行。这种它比我更懂设计模式的时刻确实让人对它的能力边界有了新的认识。但我也要泼一盆冷水这些聪明时刻的出现频率并不稳定。同样的提示词换个时间、换个会话可能就得不到同样质量的结果。所以我的建议是不要依赖单次生成的结果而是把Codex当成一个快速原型工具——让它先给你一个可运行的版本然后你再基于这个版本去打磨。这样即使它某次发挥失常你损失的也只是几分钟的生成时间而不是一整天的工作量。3. 中间十四天把Codex嵌入工作流的正确姿势3.1 代码审查场景下的第二双眼睛效应第二个七天开始我尝试把Codex用在代码审查上。具体做法是每次我写完一个功能分支在提交PR之前先把diff贴给Codex让它从五个维度给出反馈——潜在bug、性能问题、安全漏洞、可读性改进、测试覆盖建议。这个做法带来的价值超出我的预期。有一次我写了一个批量更新数据库的操作逻辑上没问题但Codex指出我没有考虑事务边界——如果批量操作中途失败前面的更新不会回滚。这个问题我自己review了三遍都没发现因为我的注意力全在业务逻辑上。还有一次它提醒我某个正则表达式存在灾难性回溯的风险建议我改用更精确的字符类。虽然那个输入场景下实际不会触发问题但这个提醒让我意识到自己对正则的性能特性理解还不够深。不过Codex的代码审查也有明显的短板。它特别容易过度报警——比如它会建议我给每个函数都加类型注解即使是在一个内部使用的脚本里它会指出某些变量命名不够描述性但那些变量只在一个三行的lambda里用了一次。所以我后来调整了策略把它的反馈分成必须处理和可以考虑两类。必须处理的是那些涉及正确性、安全性、性能的问题可以考虑的是风格和可读性建议我根据自己的判断决定是否采纳。审查维度Codex表现我的采纳率典型误报潜在bug优秀约60%对业务逻辑的误判性能问题良好约40%对数据规模的过度假设安全漏洞优秀约70%对内部工具的过度要求可读性一般约20%风格偏好差异测试覆盖良好约50%对测试粒度的不同理解3.2 测试生成从不想写到不得不改写测试大概是每个开发者又爱又恨的事情。爱的是它带来的安全感恨的是写起来确实枯燥。Codex在这个场景下帮了大忙但也给我挖了不少坑。先说好的部分。对于纯函数——输入确定、输出确定、没有副作用的函数——Codex生成的测试用例质量相当高。它不仅会覆盖正常路径还会自动生成边界用例比如空输入、极值、类型错误等。我统计了一下对于这类函数它生成的测试用例能覆盖我手动编写时80%以上的场景而且经常能发现我没想到的边界情况。但问题出在有副作用的函数上。比如一个需要读写数据库的函数Codex生成的测试要么是mock了整个数据库层导致测试实际上没验证任何真实逻辑要么是直接连接真实数据库导致测试不可重复、依赖环境。我试过给它更详细的指令比如使用内存数据库或者mock掉repository层但效果不稳定。后来我的做法是让Codex生成测试的骨架和纯逻辑部分的用例涉及IO的部分我自己来写。这样分工之后效率和质量都上去了。还有一个坑是测试的维护成本。Codex生成的测试往往比较脆——它们过度依赖具体的实现细节比如某个函数内部调用了哪些方法、调用的顺序是什么。一旦我重构了实现这些测试就会大面积失败即使功能行为没有变化。所以我后来加了一条规则让Codex生成的测试只验证输入输出行为不验证内部调用。具体做法是在提示词里明确说不要mock内部依赖只测试公开接口的行为。3.3 重构辅助它比你更不怕动刀子重构是另一个Codex表现亮眼的场景。我有一块遗留代码是一个大概三百行的数据处理函数里面嵌套了五层循环和一堆条件判断。我早就想重构它但一直下不了决心——因为逻辑太绕了改一处可能影响另一处。我把这个函数贴给Codex让它先解释这段代码在做什么。它给出的解释比我预期的准确得多甚至指出了其中两个条件分支实际上是等价的——也就是说有一段代码永远不会被执行。这个发现让我对重构的信心大增。然后我让它提出重构方案它给了三个选项提取子函数、用策略模式替换条件分支、用数据驱动的方式重写。我选了第一个方案因为改动最小、风险最低。Codex执行重构的过程也很流畅。它把三百行拆成了六个小函数每个函数只做一件事命名也清晰。重构后的代码我跑了一遍测试全部通过。然后我又让它对比重构前后的行为差异它逐条列出了每个函数的输入输出映射确认没有逻辑遗漏。整个过程大概花了四十分钟如果我自己手动做可能得花半天而且还不一定敢保证行为完全一致。但这里有一个重要的注意事项Codex重构后的代码你一定要自己再过一遍。我后来发现它在提取子函数时把一个闭包变量不小心变成了参数传递虽然功能上没问题但改变了函数的调用签名。如果这个函数被其他地方引用就会出问题。所以重构之后除了跑测试还要检查所有调用点。4. 最后七天那些只有长期使用才会暴露的问题4.1 上下文窗口的记忆衰减现象用到第三周的时候我开始注意到一个现象在同一个会话里随着对话轮次增加Codex对早期信息的记忆会逐渐模糊。比如我在会话开始时告诉它这个项目使用pydantic v2聊了二十轮之后它生成的代码里又开始出现pydantic v1的语法。这个问题在长会话里特别明显。我试过几种应对方式。第一种是定期重置——每完成一个独立任务就开新会话把必要的上下文重新贴一遍。这种方式效果最好但比较繁琐。第二种是在关键节点重复强调重要约束比如在让Codex生成代码之前先加一句记住pydantic v2用model_validate而不是parse_obj。这种方式有一定效果但需要你时刻保持警惕。第三种是接受这个现实把Codex的输出当成初稿自己负责最终的版本一致性检查。我现在的做法是混合使用对于短任务直接在当前会话里完成对于长任务拆成多个子任务每个子任务开新会话并且把项目配置文件作为第一条消息发进去。这样虽然多了一些复制粘贴的操作但换来了更稳定的输出质量。4.2 当Codex开始自信地犯错这是我在28天里遇到的最危险的情况。Codex有时候会生成看起来完全合理、但实际上有微妙错误的代码。这种错误比明显的语法错误更可怕因为它能通过编译、能通过简单的测试但在特定条件下会出问题。我印象最深的一次是它帮我写了一个日期处理的函数。逻辑看起来没问题测试也通过了。但后来在生产环境跑了一周之后发现每个月的最后一天会出现数据偏差。排查了半天才发现Codex在处理月份加减时用了简单的天数加减而没有考虑不同月份天数不同的情况。比如从1月31日加一个月它算出来是3月3日3128而不是2月28日。这个问题的根源在于Codex的训练数据里可能包含了大量简化版的日期处理代码这些代码在大多数情况下能工作但在边界条件下会出错。而它生成代码时并不会主动提醒你这里有个边界情况需要注意。所以我现在养成了一个习惯对于Codex生成的任何涉及日期、金额、权限、并发、编码的代码我都会额外花时间审查边界条件。具体做法是问它三个问题这个函数在输入为极值时会发生什么如果依赖的外部服务返回异常这段代码会怎么表现有没有什么隐含的假设如果假设不成立会怎样这三个问题能帮我发现大部分隐藏的坑。4.3 从替代到增强的心态转变28天下来我最大的收获不是学会了怎么用Codex而是调整了对它的预期。一开始我潜意识里希望它能替代我完成一部分工作让我可以少写点代码。但实际用下来我发现它的真正价值在于增强——它让我写代码的速度更快、审查代码的视角更全、重构代码的胆子更大但它不能替代我对业务逻辑的理解、对边界条件的判断、对代码质量的最终责任。这个心态转变之后我的工作流也变了。以前是我写代码、Codex补全现在是我描述意图、Codex生成初稿、我审查和修改、Codex再根据我的修改生成测试。整个过程更像是一个循环而不是单向的指令-执行。还有一个具体的改变是我开始把Codex用在那些我以前会拖延的任务上。比如写文档、写注释、写提交信息。这些事情不难但很烦。Codex做这些事情的效率很高而且质量也过得去。我把省下来的时间用在真正需要思考的地方——架构设计、性能优化、业务逻辑梳理。这种分工让我觉得28天的时间投入是值得的。5. 28天之后我留下的配置和习惯5.1 一份可复用的项目配置文件模板经过多次迭代我最终稳定下来的项目配置文件大概长这样。它不是给Codex看的唯一文件但每次新会话开始时我会把它作为第一条消息发进去。# 项目上下文 ## 技术栈 - Python 3.11.4 - FastAPI 0.104.1 - Pydantic 2.5.2 - SQLAlchemy 2.0.23 - PostgreSQL 15 ## 代码风格 - 使用ruff进行格式化和lint - 行宽120字符 - 异步函数以async_开头 - 类型注解必须完整 ## 目录结构 - src/api/ - 路由层 - src/services/ - 业务逻辑层 - src/repositories/ - 数据访问层 - src/models/ - 数据模型 - tests/ - 测试文件 ## 约束 - 不要使用requests用httpx - 不要使用print用loguru - 不要生成mock测试只测试公开接口行为 - 日期处理必须考虑月份天数差异这份配置看起来简单但它解决了我80%的Codex不听话问题。剩下的20%属于模型本身的局限性只能靠人工审查来兜底。5.2 三个我坚持下来的使用习惯第一个习惯是先解释再生成。在让Codex写任何非平凡代码之前我先让它用自己的话解释一遍需求。这个步骤看起来多余但实际上能帮我发现需求描述里的歧义。有好几次Codex的解释和我脑子里的想法不一致这就说明我的提示词有问题需要先澄清再生成。第二个习惯是小步验证。我不再让Codex一次性生成一个大模块而是拆成多个小步骤每步生成后立即验证。比如写一个API接口我先让它生成路由定义验证通过后再生成业务逻辑再验证最后生成测试。这样即使某一步出了问题影响范围也有限。第三个习惯是保留人工审查的强制节点。我在工作流里设了三个必须人工审查的节点涉及数据库操作的代码、涉及外部服务调用的代码、涉及权限判断的代码。这三类代码即使Codex生成得再好我也要逐行看过才提交。这不是对Codex的不信任而是对生产环境负责。5.3 关于更好用的一些个人体会回到标题里的那句话——有用之后还得更好用。28天下来我对更好用的理解具体化了。它不是说Codex能写出更复杂的代码而是说它能在我的工作流里更顺畅地协作。这种顺畅来自于几个方面配置的完善程度、提示词的精确程度、以及我对它能力边界的认知清晰程度。我现在的感受是Codex已经从一个需要我照顾的新手变成了一个可以分担任务的伙伴。它仍然会犯错仍然需要我审查但它的错误越来越可预测它的贡献越来越稳定。这种变化不是因为它自己升级了而是因为我学会了怎么用它。如果你也在用Codex或者准备开始用我的建议是给自己设定一个类似的周期——不用28天两周也行——在这段时间里刻意记录它的表现、你的调整、以及那些让你惊喜或失望的瞬间。然后基于这些记录形成你自己的使用规范。别人的经验只能参考真正好用的配置和习惯一定是在你自己的项目里长出来的。最后分享一个小技巧我建了一个Codex错题本每次它生成有问题的代码我就把场景、提示词、错误表现、修正方式记下来。一个月下来这个错题本帮我识别出了自己的几个提示词盲区比如我总是忘记说明异常处理策略、总是假设输入数据是干净的。修正了这些盲区之后Codex的输出质量又上了一个台阶。这个习惯我打算继续保持下去毕竟工具在进化使用工具的方法也得跟着进化。 
长河君 · 2026/10/10 9:10:29 · 阅读 1.2k 28天Codex深度实践：从代码补全到重构的工程化指南
1. 从能用到好用之间隔着28天的距离如果你最近在开发者圈子里混大概率会频繁听到一个词——Codex。不是那个已经消失在历史里的模型代号而是现在被集成进各种开发工具链里的代码智能体。我身边不少朋友已经把它接进了日常开发流里有人用它写单元测试有人用它做代码审查还有人直接让它根据注释生成整个模块的骨架。但有意思的是大家聊得最多的不是它能不能用而是它到底好不好用。这两个字的差别恰恰是过去一个月里我花时间最多的地方。我给自己定了一个28天的周期把Codex深度嵌入到三个不同类型的项目里——一个后端服务、一个数据处理脚本集、一个前端组件库——每天记录它的表现、我的调整、以及那些让我拍桌子或者拍大腿的瞬间。这篇文章就是这28天的完整复盘。我会讲清楚Codex在真实项目里到底能做什么、哪些场景下它表现惊艳、哪些地方它会让你抓狂、以及最重要的——怎么通过配置和流程设计把它从一个偶尔帮倒忙的实习生变成靠谱的结对伙伴。如果你正在考虑引入Codex或者已经用了但觉得效果一般这篇内容应该能帮你省下不少试错时间。2. 第一个七天新鲜感掩盖下的真实能力边界2.1 初始配置决定了后面27天的体验上限很多人拿到Codex的第一反应是直接开对话框扔一段需求进去然后期待它吐出完美代码。我第一天也是这么干的结果就是浪费了大半天时间在反复调整提示词上。后来我意识到一个问题Codex不是一个通用的聊天机器人它的表现高度依赖于你给它的上下文环境。我做的第一件事是建立了一个项目级的配置文件。这个文件里我定义了四样东西项目的技术栈版本、代码风格规范、目录结构说明、以及常用工具库的清单。听起来很简单对吧但就是这四样东西让Codex的输出质量在第二天就有了肉眼可见的提升。具体来说技术栈版本我精确到了小版本号比如Python 3.11.4、Node 20.9.0。为什么这么细因为Codex在生成代码时会根据版本推断可用的语法特性和标准库API。你告诉它Python 3.8和3.11它给出的代码可能完全不同——前者可能用typing.List后者直接用list[int]。代码风格规范我直接贴了一份精简版的PEP 8加上项目特有的命名约定比如所有异步函数必须以async_开头。目录结构说明让Codex知道新文件应该放在哪里而不是一股脑全扔在根目录。工具库清单则避免了它重复造轮子——我明确告诉它项目里已经装了httpx、pydantic、loguru它就不会再建议我用requests或者自己写日志模块。提示这个配置文件不需要多复杂一页Markdown就够了。但一定要在每次新会话开始时让Codex先读一遍。我试过偷懒跳过这一步结果就是它开始用我已经废弃的旧API改起来比自己写还累。2.2 代码补全和代码生成是两件完全不同的事前三天我主要测试的是代码补全——就是在编辑器里写一半让Codex接着往下写。这个场景下它的表现相当不错尤其是写那些模式化的代码时比如数据类的定义、API路由的注册、测试用例的骨架。我统计了一下在写CRUD接口的时候Codex的补全接受率大概在70%左右也就是说它给出的建议里有七成我直接按Tab采纳了。但到了代码生成——也就是我给一段自然语言描述让它从零生成一个完整函数或模块——接受率直接掉到了30%以下。问题出在哪儿我仔细对比了那些被拒绝的生成结果发现主要原因是Codex倾向于过度实现。比如我让它写一个读取配置文件并返回字典的函数它给我生成了一个带缓存、带环境变量覆盖、带类型校验、带异常重试的完整模块。功能上没错但这不是我想要的——我只需要一个简单的读取函数其他的逻辑我自己会加。这个发现让我调整了策略对于代码生成我开始用约束式提示。不是简单地说写一个读取配置的函数而是明确告诉它只做三件事打开文件、解析YAML、返回字典。不要加缓存不要加校验不要加日志。异常处理只捕获文件不存在的情况。这样约束之后生成结果的可用性明显提升。2.3 那些让我意外的聪明时刻当然这七天里也有不少让我惊喜的瞬间。有一次我在写一个数据清洗脚本需要处理一个嵌套很深的JSON结构。我写了个注释描述需求Codex生成的代码不仅正确处理了嵌套还自动加了一个我没想到的边界情况——当某个中间层级的键不存在时它用.get()方法做了安全访问而不是直接索引。这个细节我后来检查时才发现如果直接索引遇到脏数据就会抛异常。还有一次更绝。我在写一个前端组件需要根据不同的状态显示不同的图标。我本来准备写一个长长的if-else链Codex直接给我生成了一个映射对象然后用状态值作为键去查找。代码简洁了很多而且扩展性更好——以后加新状态只需要在映射对象里加一行。这种它比我更懂设计模式的时刻确实让人对它的能力边界有了新的认识。但我也要泼一盆冷水这些聪明时刻的出现频率并不稳定。同样的提示词换个时间、换个会话可能就得不到同样质量的结果。所以我的建议是不要依赖单次生成的结果而是把Codex当成一个快速原型工具——让它先给你一个可运行的版本然后你再基于这个版本去打磨。这样即使它某次发挥失常你损失的也只是几分钟的生成时间而不是一整天的工作量。3. 中间十四天把Codex嵌入工作流的正确姿势3.1 代码审查场景下的第二双眼睛效应第二个七天开始我尝试把Codex用在代码审查上。具体做法是每次我写完一个功能分支在提交PR之前先把diff贴给Codex让它从五个维度给出反馈——潜在bug、性能问题、安全漏洞、可读性改进、测试覆盖建议。这个做法带来的价值超出我的预期。有一次我写了一个批量更新数据库的操作逻辑上没问题但Codex指出我没有考虑事务边界——如果批量操作中途失败前面的更新不会回滚。这个问题我自己review了三遍都没发现因为我的注意力全在业务逻辑上。还有一次它提醒我某个正则表达式存在灾难性回溯的风险建议我改用更精确的字符类。虽然那个输入场景下实际不会触发问题但这个提醒让我意识到自己对正则的性能特性理解还不够深。不过Codex的代码审查也有明显的短板。它特别容易过度报警——比如它会建议我给每个函数都加类型注解即使是在一个内部使用的脚本里它会指出某些变量命名不够描述性但那些变量只在一个三行的lambda里用了一次。所以我后来调整了策略把它的反馈分成必须处理和可以考虑两类。必须处理的是那些涉及正确性、安全性、性能的问题可以考虑的是风格和可读性建议我根据自己的判断决定是否采纳。审查维度Codex表现我的采纳率典型误报潜在bug优秀约60%对业务逻辑的误判性能问题良好约40%对数据规模的过度假设安全漏洞优秀约70%对内部工具的过度要求可读性一般约20%风格偏好差异测试覆盖良好约50%对测试粒度的不同理解3.2 测试生成从不想写到不得不改写测试大概是每个开发者又爱又恨的事情。爱的是它带来的安全感恨的是写起来确实枯燥。Codex在这个场景下帮了大忙但也给我挖了不少坑。先说好的部分。对于纯函数——输入确定、输出确定、没有副作用的函数——Codex生成的测试用例质量相当高。它不仅会覆盖正常路径还会自动生成边界用例比如空输入、极值、类型错误等。我统计了一下对于这类函数它生成的测试用例能覆盖我手动编写时80%以上的场景而且经常能发现我没想到的边界情况。但问题出在有副作用的函数上。比如一个需要读写数据库的函数Codex生成的测试要么是mock了整个数据库层导致测试实际上没验证任何真实逻辑要么是直接连接真实数据库导致测试不可重复、依赖环境。我试过给它更详细的指令比如使用内存数据库或者mock掉repository层但效果不稳定。后来我的做法是让Codex生成测试的骨架和纯逻辑部分的用例涉及IO的部分我自己来写。这样分工之后效率和质量都上去了。还有一个坑是测试的维护成本。Codex生成的测试往往比较脆——它们过度依赖具体的实现细节比如某个函数内部调用了哪些方法、调用的顺序是什么。一旦我重构了实现这些测试就会大面积失败即使功能行为没有变化。所以我后来加了一条规则让Codex生成的测试只验证输入输出行为不验证内部调用。具体做法是在提示词里明确说不要mock内部依赖只测试公开接口的行为。3.3 重构辅助它比你更不怕动刀子重构是另一个Codex表现亮眼的场景。我有一块遗留代码是一个大概三百行的数据处理函数里面嵌套了五层循环和一堆条件判断。我早就想重构它但一直下不了决心——因为逻辑太绕了改一处可能影响另一处。我把这个函数贴给Codex让它先解释这段代码在做什么。它给出的解释比我预期的准确得多甚至指出了其中两个条件分支实际上是等价的——也就是说有一段代码永远不会被执行。这个发现让我对重构的信心大增。然后我让它提出重构方案它给了三个选项提取子函数、用策略模式替换条件分支、用数据驱动的方式重写。我选了第一个方案因为改动最小、风险最低。Codex执行重构的过程也很流畅。它把三百行拆成了六个小函数每个函数只做一件事命名也清晰。重构后的代码我跑了一遍测试全部通过。然后我又让它对比重构前后的行为差异它逐条列出了每个函数的输入输出映射确认没有逻辑遗漏。整个过程大概花了四十分钟如果我自己手动做可能得花半天而且还不一定敢保证行为完全一致。但这里有一个重要的注意事项Codex重构后的代码你一定要自己再过一遍。我后来发现它在提取子函数时把一个闭包变量不小心变成了参数传递虽然功能上没问题但改变了函数的调用签名。如果这个函数被其他地方引用就会出问题。所以重构之后除了跑测试还要检查所有调用点。4. 最后七天那些只有长期使用才会暴露的问题4.1 上下文窗口的记忆衰减现象用到第三周的时候我开始注意到一个现象在同一个会话里随着对话轮次增加Codex对早期信息的记忆会逐渐模糊。比如我在会话开始时告诉它这个项目使用pydantic v2聊了二十轮之后它生成的代码里又开始出现pydantic v1的语法。这个问题在长会话里特别明显。我试过几种应对方式。第一种是定期重置——每完成一个独立任务就开新会话把必要的上下文重新贴一遍。这种方式效果最好但比较繁琐。第二种是在关键节点重复强调重要约束比如在让Codex生成代码之前先加一句记住pydantic v2用model_validate而不是parse_obj。这种方式有一定效果但需要你时刻保持警惕。第三种是接受这个现实把Codex的输出当成初稿自己负责最终的版本一致性检查。我现在的做法是混合使用对于短任务直接在当前会话里完成对于长任务拆成多个子任务每个子任务开新会话并且把项目配置文件作为第一条消息发进去。这样虽然多了一些复制粘贴的操作但换来了更稳定的输出质量。4.2 当Codex开始自信地犯错这是我在28天里遇到的最危险的情况。Codex有时候会生成看起来完全合理、但实际上有微妙错误的代码。这种错误比明显的语法错误更可怕因为它能通过编译、能通过简单的测试但在特定条件下会出问题。我印象最深的一次是它帮我写了一个日期处理的函数。逻辑看起来没问题测试也通过了。但后来在生产环境跑了一周之后发现每个月的最后一天会出现数据偏差。排查了半天才发现Codex在处理月份加减时用了简单的天数加减而没有考虑不同月份天数不同的情况。比如从1月31日加一个月它算出来是3月3日3128而不是2月28日。这个问题的根源在于Codex的训练数据里可能包含了大量简化版的日期处理代码这些代码在大多数情况下能工作但在边界条件下会出错。而它生成代码时并不会主动提醒你这里有个边界情况需要注意。所以我现在养成了一个习惯对于Codex生成的任何涉及日期、金额、权限、并发、编码的代码我都会额外花时间审查边界条件。具体做法是问它三个问题这个函数在输入为极值时会发生什么如果依赖的外部服务返回异常这段代码会怎么表现有没有什么隐含的假设如果假设不成立会怎样这三个问题能帮我发现大部分隐藏的坑。4.3 从替代到增强的心态转变28天下来我最大的收获不是学会了怎么用Codex而是调整了对它的预期。一开始我潜意识里希望它能替代我完成一部分工作让我可以少写点代码。但实际用下来我发现它的真正价值在于增强——它让我写代码的速度更快、审查代码的视角更全、重构代码的胆子更大但它不能替代我对业务逻辑的理解、对边界条件的判断、对代码质量的最终责任。这个心态转变之后我的工作流也变了。以前是我写代码、Codex补全现在是我描述意图、Codex生成初稿、我审查和修改、Codex再根据我的修改生成测试。整个过程更像是一个循环而不是单向的指令-执行。还有一个具体的改变是我开始把Codex用在那些我以前会拖延的任务上。比如写文档、写注释、写提交信息。这些事情不难但很烦。Codex做这些事情的效率很高而且质量也过得去。我把省下来的时间用在真正需要思考的地方——架构设计、性能优化、业务逻辑梳理。这种分工让我觉得28天的时间投入是值得的。5. 28天之后我留下的配置和习惯5.1 一份可复用的项目配置文件模板经过多次迭代我最终稳定下来的项目配置文件大概长这样。它不是给Codex看的唯一文件但每次新会话开始时我会把它作为第一条消息发进去。# 项目上下文 ## 技术栈 - Python 3.11.4 - FastAPI 0.104.1 - Pydantic 2.5.2 - SQLAlchemy 2.0.23 - PostgreSQL 15 ## 代码风格 - 使用ruff进行格式化和lint - 行宽120字符 - 异步函数以async_开头 - 类型注解必须完整 ## 目录结构 - src/api/ - 路由层 - src/services/ - 业务逻辑层 - src/repositories/ - 数据访问层 - src/models/ - 数据模型 - tests/ - 测试文件 ## 约束 - 不要使用requests用httpx - 不要使用print用loguru - 不要生成mock测试只测试公开接口行为 - 日期处理必须考虑月份天数差异这份配置看起来简单但它解决了我80%的Codex不听话问题。剩下的20%属于模型本身的局限性只能靠人工审查来兜底。5.2 三个我坚持下来的使用习惯第一个习惯是先解释再生成。在让Codex写任何非平凡代码之前我先让它用自己的话解释一遍需求。这个步骤看起来多余但实际上能帮我发现需求描述里的歧义。有好几次Codex的解释和我脑子里的想法不一致这就说明我的提示词有问题需要先澄清再生成。第二个习惯是小步验证。我不再让Codex一次性生成一个大模块而是拆成多个小步骤每步生成后立即验证。比如写一个API接口我先让它生成路由定义验证通过后再生成业务逻辑再验证最后生成测试。这样即使某一步出了问题影响范围也有限。第三个习惯是保留人工审查的强制节点。我在工作流里设了三个必须人工审查的节点涉及数据库操作的代码、涉及外部服务调用的代码、涉及权限判断的代码。这三类代码即使Codex生成得再好我也要逐行看过才提交。这不是对Codex的不信任而是对生产环境负责。5.3 关于更好用的一些个人体会回到标题里的那句话——有用之后还得更好用。28天下来我对更好用的理解具体化了。它不是说Codex能写出更复杂的代码而是说它能在我的工作流里更顺畅地协作。这种顺畅来自于几个方面配置的完善程度、提示词的精确程度、以及我对它能力边界的认知清晰程度。我现在的感受是Codex已经从一个需要我照顾的新手变成了一个可以分担任务的伙伴。它仍然会犯错仍然需要我审查但它的错误越来越可预测它的贡献越来越稳定。这种变化不是因为它自己升级了而是因为我学会了怎么用它。如果你也在用Codex或者准备开始用我的建议是给自己设定一个类似的周期——不用28天两周也行——在这段时间里刻意记录它的表现、你的调整、以及那些让你惊喜或失望的瞬间。然后基于这些记录形成你自己的使用规范。别人的经验只能参考真正好用的配置和习惯一定是在你自己的项目里长出来的。最后分享一个小技巧我建了一个Codex错题本每次它生成有问题的代码我就把场景、提示词、错误表现、修正方式记下来。一个月下来这个错题本帮我识别出了自己的几个提示词盲区比如我总是忘记说明异常处理策略、总是假设输入数据是干净的。修正了这些盲区之后Codex的输出质量又上了一个台阶。这个习惯我打算继续保持下去毕竟工具在进化使用工具的方法也得跟着进化。