这是一个创建于 73 天前的主题，其中的信息可能已经有所发展或是发生改变。
主波最近才开始用 cursor 的 Agent 模式,发现现在的 ai 编程已经和以前的 chatGPT 时代完全不一样了. 代码百分之 80 都可以给 agent 管理了.但是主波涉猎的还是不广,现在都是在记事本编辑一段 Prompt. 感觉这种方式很 low,效率也不是很高.特别不优雅 听说有的直接可以让 ai 自己工作半个小时,请问这样是怎么做到的.?
v 站大佬多,特意来请教
主波现在都是这样写一段提示然后再给 cursor 帮主波实现. 
14 条回复 2025-08-04 15:53:20 +08:00
 | 1 binggg 73 天前  3 最近刚好在实践这块 推荐你 采用 Spec 驱动的研发方式，可以提升 vibe coding 的质量和效率 我写了一篇文章可以看看 一文复刻 Kiro Spec 工作流到 Cursor/ClaudeCode 等各种 AI IDE https://mp.weixin.qq.com/s/3j6lG50isbuSH4p64TsNag 今天看到一本十几年前的书，刚好解释了我们 AI 编程领域里为啥类似 Kiro 的 Spec 模式也是有效的 书名叫做 Specification by Example, SBE 我来简单总结下，后面打算写一个长文来输出下 Specification by Example, SBE 是一种软件开发方法，旨在通过具体的实例来澄清、验证和沟通需求 为啥在 AI 编程里也有效呢？ 1 需求得到澄清，并且可执行和可验证 2 短迭代，持续反馈： 每次聚焦一小块 3 共享上下文：需求设计、技术方案设计、测试验收，不同工种相互校验，避免出现偏差 4 本质上也是一种测试驱动开发 总结下来就是通过这样一套流程来规范了需求信息，划定了需求的明确范围，减少了偏差，同时可测试验证，加上持续迭代和共享上下文，最终需求的交付质量得到了提升，减少了返工 |
 | 2 sk217 72 天前 没有，transformer 说到底还是概率模型，概率模型最大的问题就是容易出错，很多人说 AI 幻觉，懂的人都懂，这讲到底就是概率模型，上下文一多，出问题的概率就大，你没法保证你的上下文全部是干净明确的，搞不好 AI 就从哪里读了一堆模糊的上下文过去，而且生成式 AI 的目标是生成，它并不会思考背后是否合理，推理模型也是看着样子在推理罢了，实际上根本没有思考，很多时候也是胡说八道，这个 apple 的工程师已经调研过，有相关论文可以了解一下 其实我觉得现阶段更好的办法是 让前后端代码都在文件夹里面，代码的组织方式要更加配合 AI 的上下文，让整个模块的前后端代码都组织在一起，模块越小越好，代码风格明确，需求越明确，代码生成越是可控，不会出现 AI 给你改了一大堆代码，然后你在那里给它擦屁股的情况，而且小规模上下文，生成的代码接受比例更高 |
| 3 sk217 72 天前 总结一句话，AI 适合小步快跑，适合小模块作战，不适合大规模上下文 |
 | 4 webcape233 72 天前 via iPhone 感觉最近 vibe 反而上班更累了 |
 | 6 xujia1998 OP @webcape233 还是比手写轻松不少的,完全解放了,只需要 review |
 | 7 terryso 72 天前 可以试试 BMAD-METHOD: t/1145165#reply8 |
 | 8 huifer 72 天前 我用 vibe code 处理了整个 IOS APP 和 官网 https://wellally.novareviewhub.com/ 我不知这个操作链路是否合适。 合适的话 后续我做 安卓的时候写写文章 |
 | 14 iaiuse 68 天前 “氛围编程”的本质，就是以 AI 的速度疯狂堆积技术债。 AI 编程是把双刃剑：做原型是神器，但用于长期维护的核心项目，就是灾难的开始。 让不懂技术的人用 AI 开发核心产品，就像给孩子一张无限额度的信用卡 一时的风光，换来的是日后无尽的债务。 驾驭 AI 的关键，不是放弃思考，而是提升“理论构建”能力。人必须是缰绳的掌控者，而不是被 AI 牵着鼻子走。 作者: Richardson 链接: https://www.iaiuse.com/posts/5fca1c2e 来源: AIMeticulously 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 |
Select Language