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 就行。

shellus

2 天前

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

laminux29

13 小时 1 分钟前

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

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

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