这是一个创建于 45 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如在用 cursor 开发一个前后端项目，添加新功能时，可以先讨论后开发，所谓磨刀不误砍柴功。
不讨论的情况：
- 你简单的描述新功能
- AI 开始编写前后端代码
- AI 检查编译错误，编写测试脚本自测
- AI 编写文档说明本次更新
- AI 做的很正确，但没有做正确的事，最终花了大量时间，你发现一半的劳动是浪费的，因为 AI 开发的跟你想的不一样。
讨论的情况：
- 你简单描述新功能，让 AI 跟你讨论下需求，先不急着开发
- AI 搜索代码库，简单地告诉你它将做什么
- 你纠正了几次 AI 的理解偏差，对齐了需求
- 你觉得差不多了，你让 AI 开始开发，AI 开发的基本上大差不差
- 虽然前期花费的讨论的时间多了，但后期没有花费大量时间反复调整
 | 1 wxw752 45 天前 我也经常先讨论方案再让他写 |
 | 2 junkk 45 天前 学到了，后面我用 cc 这么来试试 |
 | 3 ixixi 45 天前 试试麦克风 输入 ; 先唠一会嗑 |
 | 4 kaf 45 天前  4 然后没用几次额度就用完了，其实应该先去网页找模型讨论需求，然后自己搭一个大概的结构出来，再喂给 cursor 阅读代码实现。本质上要像一个合格的领导一样安排 AI 去开发。 |
 | 5 kasusa 45 天前 我感觉近期他已经很智能了。 直接生成的就很不错了。 |
 | 6 kongkongye OP @ixixi 主要是语音输入很多识别错误，英文变量名啥的也识别不好，经常语音输入完，再手动改一遍，就很繁琐 |
 | 8 weixind 45 天前 有一个小优化的建议，“对齐了需求” 以后可以让 AI 先落地成文档。 |
| 9 kongkongye OP @kasusa 主要看需求的明确性，如果你说“xx 页面加个删除按钮”，那需求上基本不会理解错误；如果你说“新增一个 xx 功能”，那 AI 新增的表里有 n 个字段，你很难保证每个字段都刚好是你想要的，没有多也没有少。 |
 | 10 xz410236056 45 天前 5 |
| 11 kongkongye OP @kaf 很多东西其实你不需要跟 AI 说，你问问它的思路，会发现它想的基本对的。 比如你不需要告诉 AI 后端怎么对接，AI 能自己去找相关代码。 技术对 AI 没啥难度，基本都能写对，需要你来决策的，目前我发现的就是让 AI 新增一个表的时候，它经常多出几个我不需要的字段。 |
 | 12 coconne 45 天前 建议用方案用 gemini ，我觉得 gemini 写设计方案比 cursor 强一些。 |
 | 13 nakun233 45 天前 一句话聊天让 AI 自己写了低版本 spine 导序列帧（因为低版本不支持批量导出），第一次图集文件裁剪错误，直接把裁剪结果的图片怼他脸上，第二次就完美工作了。感觉这次超顺利是抽卡奇迹 |
 | 14 linshuizhaoying 45 天前 我都是直接给已有的文件 让他参考 然后他自己会总结新增 |
15 KING754 45 天前 现在感觉需求稍为写清楚点。 然后需要用的类拉到 context 中，然后告诉增加什么方法，增加什么逻辑， 基本不太有问题了。 然后每次改完，觉得 ok 了，就 commit ，这样每次 review 代码范围小点。 基本可控。 |
 | 16 turtle233 45 天前 感觉讨论的越多 细节越多 ai 越容易跑偏 是我的使用姿势不对吗 |
| 17 kongkongye OP @turtle233 不会的，AI 本来也是那么想的，你只是让它把想法说出来 |
 | 18 Parva 44 天前 平时做需求改代码，也建议这么做，先讨论让它了解点上下文，再让它实际动手，成功率会高很多 |
 | 19 eroneko 44 天前 说白了还是要对齐需求目标，只是简单丢三两句话过去，很容易跑偏 |
 | 20 day0 44 天前 确实哦，有时候我自己都不太理清需求 |
 | 21 xing7673 44 天前 我就是这样做的，计划-方案-实现三步走，我还不是两步走，因为新需求的频率不高，大部分都是细化，所以起步阶段的严谨更重要。 不过话说回来，要不是 windsurf 创始人垃圾印度人跑路，我还是更喜欢 windsurf 一些 |
 | 24 horizon 44 天前 费 token 啊 |
 | 25 aLazarus 44 天前 我是 cursor 写提示词文档，claude code 阅读文档进行开发。目前开发还没遇到返工的情况，比单独用 cursor 和 cc 的效率高得多 |
Select Language