应对 AI 编程助手“降智”：我的临时解决方案与工作流分享

最近如果你跟我一样重度依赖 AI 辅助编程，可能也发现了一个让人头疼的问题：手边的 AI 编码助手好像突然“降智”了。

AI编程助手生成代码的示意图

以前只要指哪儿打哪儿，现在让它改个小问题，不仅半天修不好，有时候甚至会把本来运行正常的功能给改崩了。这种“倒退”不仅让人心态爆炸，严重影响开发效率，更让人怀疑是不是模型近期更新出了什么幺蛾子。

经过几天的摸索和痛苦调试，我发现单纯的“死磕”当前模型效果并不理想。既然工具在变弱，我们就得改变使用它的方式。这里分享一个我目前在用的“曲线救国”工作流，希望能帮大家渡过这个难关。

核心思路：规划与执行分离

现在的 AI 编程助手（很多基于 Codex 或类似的代码模型）最大的弱点在于长上下文下的逻辑规划能力下降。它们可能很熟悉具体的语法，但在面对复杂的项目结构和代码修改意图时，容易“脑子短路”，写出看起来像模像样，实则逻辑崩坏甚至引入新 Bug 的代码。

解决方案其实很简单：不要指望它既负责思考，又负责动手。

我们将工作流拆解为两步：

1. 战略层（使用强模型）： 利用推理能力更强的模型（比如 ChatGPT 网页版的高级 Pro 模型）来分析问题、诊断原因，并制定详细的修改方案。
2. 战术层（本地工具执行）： 回到本地环境或编码助手，只把它当作“机械臂”，严格按照上一步得出的方案执行代码修改。

具体操作步骤

第一步：让 Pro 模型当“架构师”

当你遇到一个棘手的 Bug 或者需要重构某个模块时，不要直接丢给你那个正在“降智”的编码助手。

把相关的代码片段、报错信息以及你的需求，整理好发送给推理能力更强的大模型（比如 Web 版 Pro）。在 Prompt 中明确要求它：

• 不要直接写代码，或者只写关键函数的伪代码。
• 重点分析：为什么会出现这个问题？根本原因是什么？
• 制定计划：具体需要修改哪些文件？修改哪几行代码？修改的逻辑是什么？

“规划与执行分离”工作流示意

经过这一步，你手里就有了一份详尽的“施工图纸”。

第二步：本地工具当“施工队”

带着这份“图纸”回到你的开发环境。这时候，你可以继续使用你习惯的本地 AI 插件或者 MCP（Model Context Protocol）工具。

因为具体的修改路径和逻辑已经被强模型论证过了，此时本地模型只需要理解简单的指令——比如“将 A 文件的第 10 行替换为...”，或者“在 B 类中增加这个方法”。

这样做的目的是为了规避本地模型在“理解问题”和“构思解决方案”这两个最容易出错的环节。它的任务被简化为单纯的“代码生成与替换”，出错概率大大降低。

为什么这个方法有效？

本质上，这是在扬长避短。

• Pro 模型（强模型）： 擅长逻辑推理、因果关系分析，能看懂复杂的业务逻辑，但可能并不了解你本地的具体代码库上下文，或者直接生成的代码无法直接粘贴运行。
• Codex/本地模型（弱模型）： 擅长补全代码、熟悉本地 API 和语法糖，甚至能通过 MCP 工具直接操作文件系统。但在“智能”下降时，它的逻辑判断不可靠。

通过把“想”和“做”拆开，我们用强模型的脑子弥补了弱模型的逻辑短板，又利用弱模型的工具属性实现了快速落地。

其他实用小贴士

除了上述的工作流调整，还有几个小技巧可以尝试：

1. Prompt 强化： 在给“降智”助手下指令时，尽量明确上下文。不要说“修复这个bug”，而要说“这是一个订单处理的模块，因为并发导致的数据不一致，请检查锁机制”。明确的上下文能减少它的幻觉。
2. 分步提交： 不要一次性让它修改一大坨代码。把一个大的需求拆解成 3-5 个小步骤，每做完一步验证一下再进行下一步。这能有效防止它“改好这里，坏掉那里”。
3. 回滚与比对： 既然知道它最近不稳定，在应用 AI 生成的代码前，务必备份或者使用版本控制系统的 Diff 功能，仔细检查每一处变动。

写在最后

AI 模型的波动是常态，作为开发者，我们不能把所有赌注都押在工具的稳定性上。当我们无法改变模型质量时，改变工作流就是最明智的选择。

如果你也在忍受“降智”的痛苦，不妨试试这个“Pro 规划 + 本地执行”的组合拳。希望能让你的开发效率重新支棱起来！