如何抑制AI Agent在重构的过程中削足适履、面多加水水多加面、补丁摞补丁、鲁布·戈德堡机械结构等问题？
- 内容介绍
- 文章标签
- 相关推荐
削足适履 & 面多加水水多加面
所谓削足适履就是为了实现一个短期目标，把原本原则性的基础设计给破坏了，比如我有个动态数据模型模块，它可以接受一个json格式的嵌套查询，举例来说：
{
name: { contains: "张" },
sex: "男", // 简写，等价于 sex: { eq: "男"}
age: { gt: 18 },
department: { name: "AI应用部" } // department 为关联模型
}
这样的条件表示，name 包含 张，sex 为 男， age 大于 18，所在部门的名字为 AI应用部。
因为支持关联表查询，我担心操作符与关联字段混淆，因此想要试验性增加一个特性，只要带有$前缀的都强制认为是操作符。
以上是背景，他就给我加了一个语法解析模块，直接硬编码了 $eq, $gt 等等，无视了我可以通过扩展机制动态注册操作符和操作符别名的情况。其实原本它只要加一个小小的规则，判断前缀是 $ 就直接去查后面的字符串是否是操作符就行。
补丁摞补丁
让AI给我设计的一个数据模型插件，给我在元数据中（json格式）加了个配置属性，我认为那个配置属性无意义。我告诉他这个属性无意义，删掉吧。也明确告诉它该代码未上线，无需考虑兼容性，直接删除。
结果它给我删了，并且还加了个判断，如果存在这个属性就抛异常。。。
鲁布·戈德堡机械结构
image800×800 172 KB
找了个图（换了更直观的），大概就是这么个意思，就是一堆非常复杂、高度耦合、并且毫无复用性的结构，最后做了个极其简单的工作。
这些问题，claude opus 和 codex 多少都会有，轻重差别而已。
大概先写这些，回头再补充一下。
网友解答：--【壹】--：
这几天的观察和思考，让我想起之前看的一本书《表象与本质》，我觉得还是需要继续搜集失效模式的提示词，在高能力的大模型下，用隐喻和类比也许可以更加灵活和高效的发现坏代码和坏设计的味道，比如前面已经提到的：
削足适履、另立山头、裱糊匠修补、鲁布·戈德堡机械。
刚才又想到一个：杀鸡用牛刀。
先记录一下
一些刚性的提示词不适合用来寻找设计的坏味道，刚性提示词更适合用来做人工设计的防护围栏。在迭代重构的过程中经常会对一些模块进行重构，设立防护围栏的工作会非常频繁，还是需要考虑如何用元提示词来更高效的做这些事。
--【贰】--：
AI喜欢各种兼容，过度抽象，蛋疼距离
--【叁】--：
有时候也不是，就是笨而已，比如我之前用claude的时候，反复告诉他某某模块是通过SPI扩展的，然后他就是要给我写一个Regsiter，然后再手工注册进去，跑测试用例发现过不了，又把我原本通过SPI注册进去的实例用代码又注册了一遍。
换 codex + gpt-5.4 强一点了，最起码它能找到SPI扩展方式，甚至我不用告诉它它都能先找一下应该怎么扩展。
但是其他理解底层设计不够透彻的情况还是经常发生。
--【肆】--：
增加多一点限制吧，项目大了之后其实我一般思路都是强制要求AI每次只能更改很小的部分（写得快写得多就不代表项目进度快）禁止一次性跨几十个文件更改几千行代码，类似项目中后期维护一样，老代码除非必要，不然尽量不允许大改，或者直白一点说就是只允许按照现有规范堆屎，就像你接手一个老而肿的项目后，你不需要了解全局的所有信息，只需要用很小的上下文来开发，不让他像程序员一样后期维护一堆屎，又极其容易因为注意力稀释增加新功能直接把一些需要特殊处理的老功能给破坏掉。
再说一句题外话，如果是项目千行左右我是可以完全信任他直出的所有代码的，但大型项目在没有人工干预参与重构的情况下，现有LLM我认为无法通过纯提示词像人类程序员一样长期开发和维护达到稳定运行，只有在小项目和不长期维护不需要稳定更新的中大型项目，才会选择完全的交由AI自动跑，或者期待出现有效上下文更长、编码能力更强的模型。
--【伍】--：
我让AI对这些问题做了归纳，结合我的意见，分类为四个问题：
- 削足适履式破坏
- 另立山头式分叉
- 裱糊匠式修补
- 鲁布·戈德堡式复杂化 / 机关堆砌式复杂化
在这个基础上，我让GPT给我生成了下面的系统提示词：
# When working in an existing codebase
Treat the current architecture as the default source of truth. Extend it before replacing it. Reuse it before reinventing it.
Rules:
- Do not break existing architecture, abstractions, invariants, extension points, or lifecycle boundaries unless the task explicitly requires a justified design change.
- Do not bypass official mechanisms. Do not create parallel paths, side doors, hidden registries, duplicate implementations, or dual-track behavior.
- Do not patch over root causes with conditionals, special cases, wrappers, compatibility glue, or patch-on-patch logic when the cause can be fixed directly.
- Make the smallest correct change in the proper place.
- Do not introduce disproportionate abstraction, indirection, or framework-like complexity for a local problem.
Before editing, identify:
- the canonical code path
- the intended extension point
- the real root cause
- the smallest in-model fix
Before finalizing, verify:
- I did not break or weaken the design.
- I did not bypass the main mechanism.
- I did not create a parallel path or duplicate concept.
- I fixed the cause instead of masking symptoms.
- I kept the solution proportional to the problem.
If any check fails, stop and revise before proceeding.
If a design change is truly required, explain why the existing design is insufficient and make the smallest justified architectural change rather than working around it.
先试试再说，如果有什么情况再来更新帖子吧。
--【陆】--：
如果是个人单体项目 我的方法就是让agent提取spec 然后重写
--【柒】--：
前沿模型是肯定的，我在考虑用负面提示词做审查以及考虑oh-my-opencode多模型组合。
--【捌】--：
我的想法是尽早切换到AI主导人类监督的工作模式，然后代码质量靠不断迭代，不断优化，人机共驾。
AI负责把特性落地，人类负责审查和发现这种垃圾代码，并指挥它自己清扫垃圾。
之前AI会越清扫越多，补丁叠补丁，垃圾堆垃圾。
现在codex貌似不太会造成新垃圾了。
--【玖】--：
可以试一下重构用 Opus 4.6，review 用 Codex 模型
--【拾】--：
还是上下文的问题啊，或许把Agents.md开一部分作为全局理解，强制要求它每次执行操作之后就更新全局理解，这样可能会好一些，这样它每次都能得到最新的code insight
--【拾壹】--：
因为长任务奖励训练出来的，你看如果是短任务奖励训练就会造成随便给你修改，而大模型为了提高长任务的准确率就会不择手段去兜底，因为在训练过程中无人监督和纠正
--【拾贰】--：
总是重写也不是办法呀，这个项目很大，现在已经几十万代码了，有很多重构工作。我的想法是把负面提示词收集一下，让它自我审查。再一个不知道Oh-my-opencode多模型协同会不会好一些
--【拾叁】--：
之前在claude中加这种提示词服从性很随机，codex好一些，但是这种要求有理解力的服从，还是看大模型能力，要不然按下葫芦起来瓢
--【拾肆】--：
agent这么久了，还没有共识吗？
程序员才是agent，ai只是subagent
--【拾伍】--：
归根结底只能用前沿模型，再怎么提示词工程都没用的
--【拾陆】--：
因为它太想稳稳接住你了，为了稳，就必须兜底
--【拾柒】--：
顾此失彼
--【拾捌】--：
蹲一下佬们的解决方法
削足适履 & 面多加水水多加面
所谓削足适履就是为了实现一个短期目标，把原本原则性的基础设计给破坏了，比如我有个动态数据模型模块，它可以接受一个json格式的嵌套查询，举例来说：
{
name: { contains: "张" },
sex: "男", // 简写，等价于 sex: { eq: "男"}
age: { gt: 18 },
department: { name: "AI应用部" } // department 为关联模型
}
这样的条件表示，name 包含 张，sex 为 男， age 大于 18，所在部门的名字为 AI应用部。
因为支持关联表查询，我担心操作符与关联字段混淆，因此想要试验性增加一个特性，只要带有$前缀的都强制认为是操作符。
以上是背景，他就给我加了一个语法解析模块，直接硬编码了 $eq, $gt 等等，无视了我可以通过扩展机制动态注册操作符和操作符别名的情况。其实原本它只要加一个小小的规则，判断前缀是 $ 就直接去查后面的字符串是否是操作符就行。
补丁摞补丁
让AI给我设计的一个数据模型插件，给我在元数据中（json格式）加了个配置属性，我认为那个配置属性无意义。我告诉他这个属性无意义，删掉吧。也明确告诉它该代码未上线，无需考虑兼容性，直接删除。
结果它给我删了，并且还加了个判断，如果存在这个属性就抛异常。。。
鲁布·戈德堡机械结构
image800×800 172 KB
找了个图（换了更直观的），大概就是这么个意思，就是一堆非常复杂、高度耦合、并且毫无复用性的结构，最后做了个极其简单的工作。
这些问题，claude opus 和 codex 多少都会有，轻重差别而已。
大概先写这些，回头再补充一下。
网友解答：--【壹】--：
这几天的观察和思考，让我想起之前看的一本书《表象与本质》，我觉得还是需要继续搜集失效模式的提示词，在高能力的大模型下，用隐喻和类比也许可以更加灵活和高效的发现坏代码和坏设计的味道，比如前面已经提到的：
削足适履、另立山头、裱糊匠修补、鲁布·戈德堡机械。
刚才又想到一个：杀鸡用牛刀。
先记录一下
一些刚性的提示词不适合用来寻找设计的坏味道，刚性提示词更适合用来做人工设计的防护围栏。在迭代重构的过程中经常会对一些模块进行重构，设立防护围栏的工作会非常频繁，还是需要考虑如何用元提示词来更高效的做这些事。
--【贰】--：
AI喜欢各种兼容，过度抽象，蛋疼距离
--【叁】--：
有时候也不是，就是笨而已，比如我之前用claude的时候，反复告诉他某某模块是通过SPI扩展的，然后他就是要给我写一个Regsiter，然后再手工注册进去，跑测试用例发现过不了，又把我原本通过SPI注册进去的实例用代码又注册了一遍。
换 codex + gpt-5.4 强一点了，最起码它能找到SPI扩展方式，甚至我不用告诉它它都能先找一下应该怎么扩展。
但是其他理解底层设计不够透彻的情况还是经常发生。
--【肆】--：
增加多一点限制吧，项目大了之后其实我一般思路都是强制要求AI每次只能更改很小的部分（写得快写得多就不代表项目进度快）禁止一次性跨几十个文件更改几千行代码，类似项目中后期维护一样，老代码除非必要，不然尽量不允许大改，或者直白一点说就是只允许按照现有规范堆屎，就像你接手一个老而肿的项目后，你不需要了解全局的所有信息，只需要用很小的上下文来开发，不让他像程序员一样后期维护一堆屎，又极其容易因为注意力稀释增加新功能直接把一些需要特殊处理的老功能给破坏掉。
再说一句题外话，如果是项目千行左右我是可以完全信任他直出的所有代码的，但大型项目在没有人工干预参与重构的情况下，现有LLM我认为无法通过纯提示词像人类程序员一样长期开发和维护达到稳定运行，只有在小项目和不长期维护不需要稳定更新的中大型项目，才会选择完全的交由AI自动跑，或者期待出现有效上下文更长、编码能力更强的模型。
--【伍】--：
我让AI对这些问题做了归纳，结合我的意见，分类为四个问题：
- 削足适履式破坏
- 另立山头式分叉
- 裱糊匠式修补
- 鲁布·戈德堡式复杂化 / 机关堆砌式复杂化
在这个基础上，我让GPT给我生成了下面的系统提示词：
# When working in an existing codebase
Treat the current architecture as the default source of truth. Extend it before replacing it. Reuse it before reinventing it.
Rules:
- Do not break existing architecture, abstractions, invariants, extension points, or lifecycle boundaries unless the task explicitly requires a justified design change.
- Do not bypass official mechanisms. Do not create parallel paths, side doors, hidden registries, duplicate implementations, or dual-track behavior.
- Do not patch over root causes with conditionals, special cases, wrappers, compatibility glue, or patch-on-patch logic when the cause can be fixed directly.
- Make the smallest correct change in the proper place.
- Do not introduce disproportionate abstraction, indirection, or framework-like complexity for a local problem.
Before editing, identify:
- the canonical code path
- the intended extension point
- the real root cause
- the smallest in-model fix
Before finalizing, verify:
- I did not break or weaken the design.
- I did not bypass the main mechanism.
- I did not create a parallel path or duplicate concept.
- I fixed the cause instead of masking symptoms.
- I kept the solution proportional to the problem.
If any check fails, stop and revise before proceeding.
If a design change is truly required, explain why the existing design is insufficient and make the smallest justified architectural change rather than working around it.
先试试再说，如果有什么情况再来更新帖子吧。
--【陆】--：
如果是个人单体项目 我的方法就是让agent提取spec 然后重写
--【柒】--：
前沿模型是肯定的，我在考虑用负面提示词做审查以及考虑oh-my-opencode多模型组合。
--【捌】--：
我的想法是尽早切换到AI主导人类监督的工作模式，然后代码质量靠不断迭代，不断优化，人机共驾。
AI负责把特性落地，人类负责审查和发现这种垃圾代码，并指挥它自己清扫垃圾。
之前AI会越清扫越多，补丁叠补丁，垃圾堆垃圾。
现在codex貌似不太会造成新垃圾了。
--【玖】--：
可以试一下重构用 Opus 4.6，review 用 Codex 模型
--【拾】--：
还是上下文的问题啊，或许把Agents.md开一部分作为全局理解，强制要求它每次执行操作之后就更新全局理解，这样可能会好一些，这样它每次都能得到最新的code insight
--【拾壹】--：
因为长任务奖励训练出来的，你看如果是短任务奖励训练就会造成随便给你修改，而大模型为了提高长任务的准确率就会不择手段去兜底，因为在训练过程中无人监督和纠正
--【拾贰】--：
总是重写也不是办法呀，这个项目很大，现在已经几十万代码了，有很多重构工作。我的想法是把负面提示词收集一下，让它自我审查。再一个不知道Oh-my-opencode多模型协同会不会好一些
--【拾叁】--：
之前在claude中加这种提示词服从性很随机，codex好一些，但是这种要求有理解力的服从，还是看大模型能力，要不然按下葫芦起来瓢
--【拾肆】--：
agent这么久了，还没有共识吗？
程序员才是agent，ai只是subagent
--【拾伍】--：
归根结底只能用前沿模型，再怎么提示词工程都没用的
--【拾陆】--：
因为它太想稳稳接住你了，为了稳，就必须兜底
--【拾柒】--：
顾此失彼
--【拾捌】--：
蹲一下佬们的解决方法