Cursor 的 YOLO 模式你们敢开吗?
YOLO 模式就是不加确认直接跑命令、直接改文件,听起来很爽,我开过一次差点把 .env 推上去,吓得我秒关。 不过看群里好多人天天开着用,说效率翻倍,还说"出问题 git reset 就完事"。我是怂人,总觉得哪天它跑个 rm rf 我就毕业了。 到底该怎么安全地用 YOLO?
Posts
像论坛一样发起讨论,适合问题、观点、工具推荐和经验交流。
YOLO 模式就是不加确认直接跑命令、直接改文件,听起来很爽,我开过一次差点把 .env 推上去,吓得我秒关。 不过看群里好多人天天开着用,说效率翻倍,还说"出问题 git reset 就完事"。我是怂人,总觉得哪天它跑个 rm rf 我就毕业了。 到底该怎么安全地用 YOLO?
周末试了 Copilot Workspace,给它一个 issue 让它从规划到改代码一条龙。体验下来:简单 bug 还行,能定位能改;稍微复杂点的需求就开始跑偏,规划阶段写得头头是道,一动手就碎。 最有意思的是它会自己列 TODO,但执行到一半经常"忘"了后面几项。 感觉离"扔
不吹不黑,聊聊三个月下来的体感。好的方面:side project 从想法到上线快了至少三倍,以前卡在"懒得写样板"的活现在都顺手做了。坏的方面:debug 别人 AI 写的代码比自己写的还累,命名和结构没有一致性可言。 最大的变化是我花在"想清楚要什么"上的时间变多了,因为需求
我工作里大量依赖长任务:让工具自己改十几个文件、跑测试、修报错循环。Claude Code 用得最多,稳定性我大概能打个 8 分,偶尔会断。 想换 Codex 试试,但搜了一圈横向对比不多,大部分评测都停留在"写个函数"这种短任务。 有没有两个都用过一阵子的朋友,从长任务稳定性、
团队里吵了一轮。一方认为 AI 写的代码更要注释,因为它实现的"为什么"经常不直观,不注释两个月后人看不懂;另一方觉得好代码自解释,注释还会过时,不如把精力放命名和测试上。 我倾向折中:业务意图(为什么这么做)必须注释,实现细节(怎么做)不注释。AI 写的代码经常缺的就是"为什么
最近从 Chat 切到 Agent 模式,确实猛,能自己跑命令、看报错、迭代修复。但坑也不少,列几个我踩过的: 一是它会"自信地"跑你不想跑的命令,比如 npm install 装一堆奇怪依赖;二是改完不告诉你改了啥,得自己 diff;三是 token 消耗爆炸,一个任务烧的量顶
用了一个月,账单看得我血压上来。同样是改个小功能,它比别的工具烧的 token 多出好几倍,感觉它每次都要把整个上下文重新读一遍。 试过用 subagent 隔离上下文,确实省了点,但还是不便宜。最离谱的是让它"读下这个文件",它把文件全文塞进去好几次。 有没有什么省 token
这个问题我被问了好几次,说说我的判断标准。 如果是内部工具、运营后台、生命周期短的营销页,Vibe Coding 放开用,快速验证比啥都重要。如果是核心交易链路、支付、权限这种,我建议 AI 辅助但人来主导,关键路径必须人写或者至少逐行 review。 判断就一句话:出了 bug
被 AI"顺手重构"折磨久了,我总结了个 prompt 模板,效果立竿见影,分享给大家。 核心是三段式:任务、约束、禁止项。 加上"禁止"那段之后,乱改的情况少了一大半。你们有啥让 AI 收敛的绝招?
Cursor 一开就疯狂吃 CPU 和内存做索引,大点的项目风扇直接起飞。关了吧,@codebase 又不太灵;开吧,电脑变暖气。 我现在妥协方案是只在开始干活前手动触发一次索引,平时关掉。但感觉这样代码库一变它就过时了。 大家的索引都怎么开的?有没有什么设置能让它温柔点?或者这
subagent 本意是隔离上下文省 token,我用下来发现用不好反而更费。原因是主 agent 经常把大段上下文重新塞给 subagent,等于读了两遍。 摸出来两条经验:一是 subagent 的任务要尽量"窄",比如"只在这个文件里找所有 TODO",别让它再做需要大上下
把一个 800 多行的"上帝组件"拆成 6 个小模块,本来预算三天,借助 AI 一天搞定了,记录下流程备忘。 第一步让它只读不写,输出拆分方案和依赖关系图;第二步我手动确认边界,写成 todo list;第三步一个模块一个模块地迁移,每个模块配测试;最后跑全量测试 + 手测关键路