V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
livin2
V2EX  ›  程序员

AI 产出代码的可靠性与测试的讨论

  •  
  •   livin2 · 12 天前 · 1255 次点击
    在不考虑可维护性/新项目创建的情况下,Cursor Agent 确实很快。但相对地,使用下来的感想是其对人为修改维护的操作是“闭合”的。

    即使是 Prompt 中直接要求可维护性乃至具体明确地要求其遵循特定的设计模式,在后续的“需求实现”的对话中也很容易破坏已有结构。Prompt 要求太多还容易过度抽象或产生幻觉,Code Review 起来非常累,反而感觉比自己实施消耗了更多的心力。

    上述也许可以归因为个人 Prompt 姿势不对,但之所以觉得其“闭合”,还有一个原因是大模型的上下文限制:对于一个解耦且不同人负责不同模块的项目,Cursor 无法很好将别人的变更同步到上下文中,在新代码里容易根据已有上下文在犄角旮旯里去用 @deprecated 的东西。(除非你把相关的 commit/文件都找出来显式地 @给它)

    总体而言还是所有修改都通过 Cursor ,让代码变更按顺序在同一个上下文中被 LLM 嵌入/索引,避免 LLM 上下文与实际变更情况有出入,能获得最好的体验,即人为直接修改的“闭合”。

    我想当前 AI 辅助编程的体感分化就是来自于此,非技术背景的人在放弃自己碰代码通过人肉 E2E 测试来追求 UX ,肯定比技术背景追求实施过程中更好的 DX ,体感好得多。然而用人肉 E2E 测试维护的项目,过于噩梦了...

    基于以上情况,是否参照训练模型思路,将项目管理的重心放在测试的可靠性维护上,对于项目代码本身则完全放弃对设计模式/可维护性/可靠性的要求。即测试对模型“闭合”的同时,放飞模型。(甚至 git 只 commit 测试)

    那么问题就在于“测试集”的构建和维护流程了。TDD 感觉其实并不适合 LLM ,TDD 其实要求测试设计比开发更加懂架构/设计模式,本质 Driven 的还是 develop ,而不是 generate 。

    我们需要的也许是某种倒置的 TDG 流程。测试管理的对象应该是 UX 层面的,Test 本身易构建易管理,而不是 generate 则是一个复杂度黑洞,generate 产物可以随时交给别的模型别的 Agent ,可以上下文无关(generate 产物本身就是上下文),只要能通过 Test 就行。
    11 条回复    2025-03-26 14:06:41 +08:00
    tool2dx
        1
    tool2dx  
       12 天前
    这就和去年职业漫画用 SD 来辅助作画一样,生成了 100 张,最终挑出几张备选做参考图,确实心累。

    随机性太强,不太好把控质量。

    不过 AI 进化真是快得惊人,也许到下半年,生成的代码就会完全可控吧。
    ychost
        2
    ychost  
       12 天前   ❤️ 1
    现在生成代码质量还可以,等 GPT5 出来估计一般程序员真被干没了
    musi
        3
    musi  
       12 天前 via iPhone
    @ychost #2 GPT5 吹了这么久还没出来你没发现有什么问题吗?
    gr112
        4
    gr112  
       12 天前
    未来需要人来指导 AI 写代码,一点不懂的人是无法用好 AI 写代码的。
    joyhub2140
        5
    joyhub2140  
       12 天前
    如果未来的 AI Agent 能把本地编译的工作也做了,那单元测试,系统测试,性能测试也不在话下了,那说真的程序员这工作真的彻底低端化了。
    sampeng
        6
    sampeng  
       12 天前
    nonono 。。cursor 的问题在于上下文剪切的问题。。你给了他都不一定给大模型。
    ychost
        7
    ychost  
       12 天前
    @musi 虽然还没出来,但是目前工程侧代码生成只有 Claude 和 GPT 还能用用,国产的基本不太靠谱
    livin2
        8
    livin2  
    OP
       12 天前
    @sampeng 对,上下文剪切很严重,所以 Cursor 即便是 Agent 模式,定位也还是个 dev 工具。
    shellus
        9
    shellus  
       12 天前
    “上述也许可以归因为个人 Prompt 姿势不对,但之所以觉得其“闭合”,还有一个原因是大模型的上下文限制:对于一个解耦且不同人负责不同模块的项目,Cursor 无法很好将别人的变更同步到上下文中,在新代码里容易根据已有上下文在犄角旮旯里去用 @deprecated 的东西。(除非你把相关的 commit/文件都找出来显式地 @给它)

    针对这一点,给出一点心得,当你手动改完代码后,告诉它:
    “我已修改 XXX ,在后续工作时,请先检查已有代码”
    “我已修改 XXX ,使用 git diff 查看我的修改,然后继续做 XXX”
    laminux29
        10
    laminux29  
       10 天前
    根源在于你对 AI 还不太理解。AI 的工作模式更像是人。你用 AI 写代码时,你应该理解为,你是组长,AI 是程序员,除了要实现的功能之外,你要尽量把代码风格、额外注意事项,讲清楚。

    我用 AI 写代码,首要要列出 Goal ,至少五六条,指明需求与大概的方法与方向。然后 Colding style ,十几条,确保 AI 按照自己的风格来;然后是 Rule ,用于控制变量风格,增加 debug 开关、接入日志等方便运维的功能;接着是一些工程方面的特性,比如参数检查规则、异常处理规则、测试与部署问题,等等。你要自己先做一个这样的风格与规则的模板,有了新需求后,就只需要改 Goal 部分就行。

    最后再强调一次,AI 是人,你要把与人沟通的方法,来和 AI 沟通,不要偷懒,妄想着写几句简单的话,就想让 AI 按照你的思路去做。
    livin2
        11
    livin2  
    OP
       6 天前
    @laminux29 这里想讨论的是大型项目在流程上管控目前其短板对项目整体造成的风险,而非做 MVP 时的 Vibe Coding 。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5588 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 03:24 · PVG 11:24 · LAX 20:24 · JFK 23:24
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.