• 请不要在回答技术问题时复制粘贴 AI 生成的内容
yuyue001
V2EX  ›  程序员

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

  •  
  •   yuyue001 · 1 day ago · 2772 views
    提示词中应该如何表达?似乎 AI 总是忽略我的提示词。

    ```
    避免过度抽象: 不要创建一次性 helper 、utils 、wrapper 或局部小框架,除非能明确提升复用、测试、复杂度隔离或语义稳定性。不要做辅助函数小王子。
    ```

    不喜欢过度抽象,尤其是重复的大量小辅助函数。
    24 replies    2026-07-19 14:29:14 +08:00
    jacketma
        1
    jacketma  
       1 day ago
    模型个别地方不听话,就把那段函数单独摘出来,让它重构。一个模型有惯性,就换另外一个模型重写,一般都会换一种思路的。
    yuyue001
        2
    yuyue001  
    OP
       1 day ago
    @jacketma 这是一个思路。我现在 codex 规范方案/执行; deepseek 做方案评审和代码审查。 综合效果感觉比完全依赖 codex 好一点。
    molvqingtai
        3
    molvqingtai  
       23h 57m ago
    装作看不见🙈
    netnr
        4
    netnr  
       23h 0m ago
    “减少子方法嵌套,优先本地函数单线路实现”
    noqwerty
        5
    noqwerty  
       22h 5m ago via iPhone
    试过挺多方式都没法保证,codex 就是很喜欢加那种一两行且只用一次的辅助函数,最终的解决方案是放弃自己的代码洁癖,又不是不能用.jpg

    另一个角度想,随着现在 AI 开发代码逐渐变成主流,这种代码可能才是更“干净”、更好维护的。
    VeryZero
        6
    VeryZero  
       19h 54m ago
    把那段辅助函数的代码贴到提示词里,告诉他不要写类似这样的辅助函数。

    这样效果可能好一点,因为他不一定能理解你所谓的辅助函数是什么,所以需要举例子说明。
    Lightbright
        7
    Lightbright  
       19h 50m ago   ❤️ 7
    试试这个
    以暗猜接口为耻,以认真查阅为荣。
    以模糊执行为耻,以寻求确认为荣。
    以盲想业务为耻,以人类确认为荣。
    以创造接口为耻,以复用现有为荣。
    以跳过验证为耻,以主动测试为荣。
    以破坏架构为耻,以遵循规范为荣。
    以假装理解为耻,以诚实无知为荣。
    以盲目修改为耻,以谨慎重构为荣。
    laminux29
        8
    laminux29  
       18h 21m ago   ❤️ 2
    典型的外行指导内行行为。

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

    你自己学不来这一套,还嫌弃 AI 这样做,倒反天罡了。
    netlous
        9
    netlous  
       16h 3m ago   ❤️ 1
    有没有试过 ponytail ?
    https://github.com/DietrichGebert/ponytail
    Tyanboot
        10
    Tyanboot  
    PRO
       11h 32m ago   ❤️ 1
    @laminux29 等你遇到明明是同一个功能或者同一个用途的代码,AI 产出了四五个名字不一样、位置也不一样的,只有一两行的这种 normalizeXXX 、isXXX 辅助函数你就知道谁是外行谁是内行了,这种东西你可以说他方便调试,但是对于改动和团队协作纯纯的负面作用,甚至如果真的集中注意力了那也不至于一样的辅助函数写四五个出来
    FloatingLeaves
        11
    FloatingLeaves  
       10h 30m ago
    @laminux29 要看需求啊,我自己写一个小项目都不要考虑这么多,只能说是过度设计
    netizen
        12
    netizen  
       10h 4m ago via iPhone   ❤️ 2
    @laminux29 典型的张嘴就来,还信誓旦旦。
    gogozs
        13
    gogozs  
       9h 44m ago via iPhone
    关心这种细节没必要啊,架构上大的方向不要偏就没事了。要不然你根本 review 不完
    laminux29
        14
    laminux29  
       9h 37m ago
    @Tyanboot

    如果你确定 AI 产出了功能相同的函数,你完全可以把这些函数去重后进行落地,然后把接口告诉 AI 就行。这样仍然实现了我在前面说的优点。
    webfamer
        15
    webfamer  
       9h 29m ago
    写 python 也是,老是写很多自定义函数,看都是过滤数组,校验这些小功能
    yidinghe
        16
    yidinghe  
    PRO
       9h 21m ago via Android
    先让大模型全盘看下代码,理解应该将工具函数集中放在什么地方。工具函数是项目上了规模之后必然会有的,因为人类都这么做。
    loading
        17
    loading  
       8h 46m ago
    我觉得挺好的,我每次都要求用这一类工具函数,但我要求在调用时,都在调用处用中文注释写一下,这样只要 review 时就省事了。
    对于工具函数,要求写全测试代码。
    jacketma
        18
    jacketma  
       8h 40m ago
    一个简单的函数也喜欢搞几层 wrapper,感觉 AI 就是要主导项目未来的控制权,让人类难以阅读,无法接手😮😮😮
    shawnsh
        19
    shawnsh  
       8h 36m ago via Android
    模型学的就是这种垃圾代码,你让它无中生有创造代码,有点难,哈哈😄
    qgswzmz
        20
    qgswzmz  
       8h 27m ago via Android
    确实很烦啊,Log.Write GPT 能再包一层 WriteLog ,搞得现在都很讨厌用 gpt 了,幸好 grok-4.5 也能干
    apkapb
        21
    apkapb  
       8h 22m ago
    尽量多重构吧,对一个新功能,AI 会参考以前的写法,它发现其它组件/功能模块使用了一个公用的方法,那么在新功能上,它也会使用这个方法,而不是再写一个类似的
    supuwoerc
        22
    supuwoerc  
       7h 56m ago
    skill 里面要求使用官方库,第三方已有方案,最佳实践,避免重复造轮子
    lozzow
        23
    lozzow  
       4h 54m ago
    我一边是先写伪代码,再抽象 interface,最后要求禁止做任何提前优化,(5.6-medium 及其之上的模型,都非常喜欢提前优化,我甚至跑过 24 消失的提前优化,加了 2w 多行代码....)
    fds
        24
    fds  
       4h 40m ago
    @Tyanboot #10 claude 以前有个 /simplify 的 skill ,现在合并入 /code-review 了,就是为了应对这种重复定义函数的情况。
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   2727 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 110ms · UTC 11:09 · PVG 19:09 · LAX 04:09 · JFK 07:09
    ♥ Do have faith in what you're doing.