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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

在不考虑可维护性/新项目创建的情况下，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 就行。

代码可靠性

测试

10 条回复 • 2025-03-23 04:46:23 +08:00

tool2dx

2 天前

这就和去年职业漫画用 SD 来辅助作画一样，生成了 100 张，最终挑出几张备选做参考图，确实心累。

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

不过 AI 进化真是快得惊人，也许到下半年，生成的代码就会完全可控吧。

ychost

2 天前

现在生成代码质量还可以，等 GPT5 出来估计一般程序员真被干没了

musi

2 天前 via iPhone

@ychost #2 GPT5 吹了这么久还没出来你没发现有什么问题吗？

gr112

2 天前

未来需要人来指导 AI 写代码，一点不懂的人是无法用好 AI 写代码的。

joyhub2140

2 天前

如果未来的 AI Agent 能把本地编译的工作也做了，那单元测试，系统测试，性能测试也不在话下了，那说真的程序员这工作真的彻底低端化了。

sampeng

2 天前

nonono 。。cursor 的问题在于上下文剪切的问题。。你给了他都不一定给大模型。

ychost

2 天前

@musi 虽然还没出来，但是目前工程侧代码生成只有 Claude 和 GPT 还能用用，国产的基本不太靠谱

livin2

2 天前

@sampeng 对，上下文剪切很严重，所以 Cursor 即便是 Agent 模式，定位也还是个 dev 工具。

shellus

1 天前

“上述也许可以归因为个人 Prompt 姿势不对，但之所以觉得其“闭合”，还有一个原因是大模型的上下文限制：对于一个解耦且不同人负责不同模块的项目，Cursor 无法很好将别人的变更同步到上下文中，在新代码里容易根据已有上下文在犄角旮旯里去用 @deprecated 的东西。（除非你把相关的 commit/文件都找出来显式地 @给它）
”
针对这一点，给出一点心得，当你手动改完代码后，告诉它：
“我已修改 XXX ，在后续工作时，请先检查已有代码”
“我已修改 XXX ，使用 git diff 查看我的修改，然后继续做 XXX”

laminux29

2 小时 36 分钟前

根源在于你对 AI 还不太理解。AI 的工作模式更像是人。你用 AI 写代码时，你应该理解为，你是组长，AI 是程序员，除了要实现的功能之外，你要尽量把代码风格、额外注意事项，讲清楚。

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

最后再强调一次，AI 是人，你要把与人沟通的方法，来和 AI 沟通，不要偷懒，妄想着写几句简单的话，就想让 AI 按照你的思路去做。