Codex agentic loop 会导致代码严重膨胀，有人遇到吗？有没有系统性的解法？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

For Existing Member Sign In

/div>

请不要在回答技术问题时复制粘贴 AI 生成的内容

具体案例：V2EX Safe Reading Helper 5.3.0，一个油猴脚本，核心逻辑不复杂，但 530 行里能清楚看到几层叠加痕迹：

topic 来源从 API 一路加到 /recent、节点页、ID 逐个扫描每次拿不到帖子就加一个 fallback ，互相没有合并
两套 refill 防重入并存（isRefilling flag + refillPromise 互斥）
legacy key 迁移代码永远留在运行时，跑一次之后就是死代码
hasGMStorage() 每次读写都检测，而不是初始化时确定一次
对一个翻页脚本加了完整的白屏 watchdog + 自动刷新恢复机制

模型每次报错就往上堆，不回头清理，不合并逻辑。

有没有系统性的解法？还是说这就是现阶段 agentic coding 的固有缺陷？

膨胀

代码

解法

15 replies 2026-04-27 11:11:14 +08:00

vexjoe

1 day ago

模型问题自身问题，现阶段看到的似乎都是通过 prompt 等后手"打补丁"的方式解决的

xiri

1 day ago

你跟它说让它清理、精简、合并代码不行吗？把你上面列的这些点丢给它让它自己处理

liuchenx

1 day ago

gpt 的问题，它的性格是尽量让减少你的改动对其他部分的影响，其实就是打补丁的方式解决问题，就算你叫他轻量化实现，精简化实现还是一样，5.5 有一定的改善，所以每次改动一定要 review ，这也是我感觉它不如 claude 的点之一，不过这个性格对于历史业务修改挺好的(不容易改出锅)，新的独立模块就不太行，多了又成屎山了

teaguexiao

1 day ago

每隔几个 task 手动跟他说一次“现在整理一下逗逻辑，删掉死代码和重复逻辑”会好很多；另外 CLAUDE.md 或 AGENTS.md 里加一条“no legacy fallback”的约束，能弥补一些模型自身的不良习惯。

sunlin1234

1 day ago

你可以每隔段时间,进行一轮重构, 让 codex 梳理目前的代码, 拆分,以及各种优化. codex 是比较保守的, 默认会进行补丁小于重构. 需要琢磨使用的技巧

gorvey

1 day ago

对话了几次，需要 commit 的时候，加一个 hook 自动化，或者做一个指令/clean-code ，将暂存的代码输入输出不变，精简实现

doraemonki

1 day ago

全局约束加上下面的话：

**No Backward Compatibility**: Pre-v1.0 with no external consumers to protect. Prioritize first-principles domain modeling and logical orthogonality; favor refactoring core structures to capture native semantics over adding additive flags or 'patch' parameters.