这是一个创建于 225 天前的主题，其中的信息可能已经有所发展或是发生改变。
在不考虑可维护性/新项目创建的情况下，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 就行。
即使是 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 就行。
 |
1
tool2dx 225 天前
这就和去年职业漫画用 SD 来辅助作画一样，生成了 100 张，最终挑出几张备选做参考图，确实心累。
随机性太强，不太好把控质量。 不过 AI 进化真是快得惊人，也许到下半年，生成的代码就会完全可控吧。 |
 |
2
ychost 225 天前  1
现在生成代码质量还可以，等 GPT5 出来估计一般程序员真被干没了
|
 |
4
gr112 225 天前
未来需要人来指导 AI 写代码，一点不懂的人是无法用好 AI 写代码的。
|
 |
5
nxforce 225 天前
如果未来的 AI Agent 能把本地编译的工作也做了，那单元测试，系统测试，性能测试也不在话下了，那说真的程序员这工作真的彻底低端化了。
|
 |
6
sampeng 225 天前
nonono 。。cursor 的问题在于上下文剪切的问题。。你给了他都不一定给大模型。
|
 |
9
shellus 224 天前
“上述也许可以归因为个人 Prompt 姿势不对，但之所以觉得其“闭合”，还有一个原因是大模型的上下文限制：对于一个解耦且不同人负责不同模块的项目，Cursor 无法很好将别人的变更同步到上下文中，在新代码里容易根据已有上下文在犄角旮旯里去用 @deprecated 的东西。（除非你把相关的 commit/文件都找出来显式地 @给它）
” 针对这一点，给出一点心得，当你手动改完代码后，告诉它： “我已修改 XXX ，在后续工作时，请先检查已有代码” “我已修改 XXX ，使用 git diff 查看我的修改，然后继续做 XXX” |
 |
10
laminux29 222 天前
根源在于你对 AI 还不太理解。AI 的工作模式更像是人。你用 AI 写代码时，你应该理解为，你是组长，AI 是程序员，除了要实现的功能之外，你要尽量把代码风格、额外注意事项，讲清楚。
我用 AI 写代码，首要要列出 Goal ，至少五六条，指明需求与大概的方法与方向。然后 Colding style ，十几条，确保 AI 按照自己的风格来；然后是 Rule ，用于控制变量风格，增加 debug 开关、接入日志等方便运维的功能；接着是一些工程方面的特性，比如参数检查规则、异常处理规则、测试与部署问题，等等。你要自己先做一个这样的风格与规则的模板，有了新需求后，就只需要改 Goal 部分就行。 最后再强调一次，AI 是人，你要把与人沟通的方法，来和 AI 沟通，不要偷懒，妄想着写几句简单的话，就想让 AI 按照你的思路去做。 |
Select Language