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