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

[livin2]

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

[tool2dx]

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

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

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

[ychost]

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

[musi]

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

[gr112]

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

[joyhub2140]

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

[sampeng]

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

[ychost]

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

[livin2]

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

[shellus]

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