• doSth

    最近一直在Vibe Coding,对于一些老代码,改一下Bug挺好用的

    对于一些新的逻辑或者改动比较大的,写出来的代码就太高级了,AI味很重,功能是有的,但是人眼很难阅读,调试也麻烦

    佬友们是怎么避免这个问题的

    我在网上找了一些相关资料,基本上都是加限制,比如这个

    图片

    主楼
  • 西葫芦炒鸡蛋

    清晰明了很不错

    #1
  • U1

    不看 直接所有需求安排给ai

    #2
  • zilong1024

    我觉得把“限制”落到可验证的开发流程,比只要求模型少写高级代码更稳:先让 AI 说明改动范围和调用链,再按函数或模块分小步提交;同时要求给出边界条件、测试用例和回滚点。已有代码可以先让它只做解释和重构计划,不直接改,确认方案后再执行。这样即使代码风格不熟,也能靠 diff 和测试快速定位问题。

    #3
  • 深海泡泡

    解决方法就是不阅读

    #4
  • 你好呵呵

    我现在都不阅读,只检查输入输出 ^-^

    #5
  • hujiansir

    多加注释吧,注释需要通俗易懂,其他的也没招了,我认为Ai选择的是最优解

    #6
  • chenmi

    佬友可以试试 DietrichGebert/ponytail 这个 skill, 写的短了,精简了,会减少看代码的负担,也会多调用很多内部库函数,不会长篇大论

    #7
  • doro好忙

    我是让AI加注释

    #8
  • Suryu

    在评论区学习下,最近我也想解决这个问题,每次都是命名不规范,或者写很多冗余代码 很烦

    #9
  • figure

    我正好相反,我让AI尽量使用接口、设计模式、设计原则,不要只是最小改动 ^-^

    #10
  • El

    没让ai写注释他都能写一堆设计意图 ^-^主要他这设计意图我怀疑就是写给ai自己看的,真的又臭又长不适合人类阅读(感觉ai就是拿项目代码的注释当自己的记忆存储用了

    #11
  • Jeffry

    感觉看代码 review 会导致工程速度起不来,现在我都是看 spec 和输入输出测试结果

    #12
  • captain

    AI写的代码还要人看,那不是胡闹吗?AI写的AI负责维护

    #13
  • supermiky

    原来还挣扎一下,现在直接放飞了,已经变成产品+测试的角色了。

    #14
  • RzMY

    AI的代码就没必要细读了,知晓它的整体实现逻辑就行,这个项目可能对你有帮助:

    本帖使用社区开源推广,符合推广要求。我申明并遵循社区要求的以下内容:

    我的帖子已经打上 开源推广 标签: 是
    我的开源项目完整开源,无未开源部分: 是
    我的开源项目已链接认可 LINUX DO 社区: 是
    我帖子内的项目介绍,AI生成、润色内容部分已截图发出: 是
    以上选择我承诺是永久有效的,接受社区和佬友监督: 是

    把 archify 融合到了 spec 驱动开发中,效果出奇的好
    […

    #15
  • pytaitool

    释和重构计划,不直接改,确认方案后再执行。这样即使代码风格不熟,

    已经是AI依赖症晚期了。以前还坚持自己看看AI怎么改的。现在只做黑盒测试。代码窗口都难得开了。

    #16
  • SmartRiver49

    之前AI写的代码,业务的转折点和关键if判断,开会的时候被领导说了,说一行代码也要加个注释怎么怎么的,从那之后我告诉AI,除了方法名,所有的地方都不要加注释。

    #17
  • 柠萌你个思密达

    感觉又要把我迭代了很多版本的全局RULES翻出来了

    图片

    #18
  • mycharles

    很羡慕评论区放开手让AI全盘接管的佬们,好奇问下各位每个月在token或订阅上的开销是多少?

    #19

发表回复

登录后回复