AI 写代码的时候总是使用大量的辅助函数，应该如何处理？

模型个别地方不听话，就把那段函数单独摘出来，让它重构。一个模型有惯性，就换另外一个模型重写，一般都会换一种思路的。

@jacketma 这是一个思路。我现在 codex 规范方案/执行； deepseek 做方案评审和代码审查。 综合效果感觉比完全依赖 codex 好一点。

装作看不见🙈

“减少子方法嵌套，优先本地函数单线路实现”

试过挺多方式都没法保证，codex 就是很喜欢加那种一两行且只用一次的辅助函数，最终的解决方案是放弃自己的代码洁癖，又不是不能用.jpg

另一个角度想，随着现在 AI 开发代码逐渐变成主流，这种代码可能才是更“干净”、更好维护的。

把那段辅助函数的代码贴到提示词里，告诉他不要写类似这样的辅助函数。

这样效果可能好一点，因为他不一定能理解你所谓的辅助函数是什么，所以需要举例子说明。

试试这个
以暗猜接口为耻，以认真查阅为荣。
以模糊执行为耻，以寻求确认为荣。
以盲想业务为耻，以人类确认为荣。
以创造接口为耻，以复用现有为荣。
以跳过验证为耻，以主动测试为荣。
以破坏架构为耻，以遵循规范为荣。
以假装理解为耻，以诚实无知为荣。
以盲目修改为耻，以谨慎重构为荣。

典型的外行指导内行行为。

AI 之所以喜欢抽象，喜欢写辅助函数，是因为这是软件工程已经验证过的正确的开发方法。就算不能增益复用，对于调试、改动、团队协作、让 AI 集中注意力且节约 tokens 等都是大有作用的。

你自己学不来这一套，还嫌弃 AI 这样做，倒反天罡了。

有没有试过 ponytail ？
https://github.com/DietrichGebert/ponytail

@laminux29 等你遇到明明是同一个功能或者同一个用途的代码，AI 产出了四五个名字不一样、位置也不一样的，只有一两行的这种 normalizeXXX 、isXXX 辅助函数你就知道谁是外行谁是内行了，这种东西你可以说他方便调试，但是对于改动和团队协作纯纯的负面作用，甚至如果真的集中注意力了那也不至于一样的辅助函数写四五个出来

@laminux29 要看需求啊，我自己写一个小项目都不要考虑这么多，只能说是过度设计

@laminux29 典型的张嘴就来，还信誓旦旦。

关心这种细节没必要啊，架构上大的方向不要偏就没事了。要不然你根本 review 不完

@Tyanboot

如果你确定 AI 产出了功能相同的函数，你完全可以把这些函数去重后进行落地，然后把接口告诉 AI 就行。这样仍然实现了我在前面说的优点。

写 python 也是，老是写很多自定义函数，看都是过滤数组，校验这些小功能

先让大模型全盘看下代码，理解应该将工具函数集中放在什么地方。工具函数是项目上了规模之后必然会有的，因为人类都这么做。

我觉得挺好的，我每次都要求用这一类工具函数，但我要求在调用时，都在调用处用中文注释写一下，这样只要 review 时就省事了。
对于工具函数，要求写全测试代码。

一个简单的函数也喜欢搞几层 wrapper，感觉 AI 就是要主导项目未来的控制权，让人类难以阅读，无法接手😮😮😮

模型学的就是这种垃圾代码，你让它无中生有创造代码，有点难，哈哈😄

确实很烦啊，Log.Write GPT 能再包一层 WriteLog ，搞得现在都很讨厌用 gpt 了，幸好 grok-4.5 也能干

尽量多重构吧，对一个新功能，AI 会参考以前的写法，它发现其它组件/功能模块使用了一个公用的方法，那么在新功能上，它也会使用这个方法，而不是再写一个类似的

skill 里面要求使用官方库，第三方已有方案，最佳实践，避免重复造轮子

我一边是先写伪代码,再抽象 interface,最后要求禁止做任何提前优化,(5.6-medium 及其之上的模型,都非常喜欢提前优化,我甚至跑过 24 消失的提前优化,加了 2w 多行代码....)

@Tyanboot #10 claude 以前有个 /simplify 的 skill ，现在合并入 /code-review 了，就是为了应对这种重复定义函数的情况。