比如在用 cursor 开发一个前后端项目，添加新功能时，可以先讨论后开发，所谓磨刀不误砍柴功。
不讨论的情况：

你简单的描述新功能
AI 开始编写前后端代码
AI 检查编译错误，编写测试脚本自测
AI 编写文档说明本次更新
AI 做的很正确，但没有做正确的事，最终花了大量时间，你发现一半的劳动是浪费的，因为 AI 开发的跟你想的不一样。

讨论的情况：

你简单描述新功能，让 AI 跟你讨论下需求，先不急着开发
AI 搜索代码库，简单地告诉你它将做什么
你纠正了几次 AI 的理解偏差，对齐了需求
你觉得差不多了，你让 AI 开始开发，AI 开发的基本上大差不差
虽然前期花费的讨论的时间多了，但后期没有花费大量时间反复调整

我也经常先讨论方案再让他写

学到了，后面我用 cc 这么来试试

试试麦克风 输入 ; 先唠一会嗑

然后没用几次额度就用完了，其实应该先去网页找模型讨论需求，然后自己搭一个大概的结构出来，再喂给 cursor 阅读代码实现。本质上要像一个合格的领导一样安排 AI 去开发。

我感觉近期他已经很智能了。 直接生成的就很不错了。

主要是语音输入很多识别错误，英文变量名啥的也识别不好，经常语音输入完，再手动改一遍，就很繁琐

上班的时候说话感觉会很尴尬，特别是很低级问题的时候

有一个小优化的建议，“对齐了需求” 以后可以让 AI 先落地成文档。

主要看需求的明确性，如果你说“xx 页面加个删除按钮”，那需求上基本不会理解错误；如果你说“新增一个 xx 功能”，那 AI 新增的表里有 n 个字段，你很难保证每个字段都刚好是你想要的，没有多也没有少。

github.com/steipete/agent-rules

这才是磨刀呢

很多东西其实你不需要跟 AI 说，你问问它的思路，会发现它想的基本对的。
比如你不需要告诉 AI 后端怎么对接，AI 能自己去找相关代码。
技术对 AI 没啥难度，基本都能写对，需要你来决策的，目前我发现的就是让 AI 新增一个表的时候，它经常多出几个我不需要的字段。

建议用方案用 gemini ，我觉得 gemini 写设计方案比 cursor 强一些。

一句话聊天让 AI 自己写了低版本 spine 导序列帧（因为低版本不支持批量导出），第一次图集文件裁剪错误，直接把裁剪结果的图片怼他脸上，第二次就完美工作了。感觉这次超顺利是抽卡奇迹

我都是直接给已有的文件 让他参考 然后他自己会总结新增

现在感觉需求稍为写清楚点。
然后需要用的类拉到 context 中，然后告诉增加什么方法，增加什么逻辑，

基本不太有问题了。
然后每次改完，觉得 ok 了，就 commit ，这样每次 review 代码范围小点。
基本可控。

感觉讨论的越多 细节越多 ai 越容易跑偏 是我的使用姿势不对吗

不会的，AI 本来也是那么想的，你只是让它把想法说出来

平时做需求改代码，也建议这么做，先讨论让它了解点上下文，再让它实际动手，成功率会高很多

说白了还是要对齐需求目标，只是简单丢三两句话过去，很容易跑偏

确实哦，有时候我自己都不太理清需求

我就是这样做的，计划-方案-实现三步走，我还不是两步走，因为新需求的频率不高，大部分都是细化，所以起步阶段的严谨更重要。
不过话说回来，要不是 windsurf 创始人垃圾印度人跑路，我还是更喜欢 windsurf 一些

那现在用啥作为代码提示助手

cursor+gemini 或者 cursor+got-5-high 常用搭配，偶尔 cc 作为项目初始化

费 token 啊

我是 cursor 写提示词文档，claude code 阅读文档进行开发。目前开发还没遇到返工的情况，比单独用 cursor 和 cc 的效率高得多

vscode 我是基本 cc 主要开发,然后借助 windsufe 做代码提示助手,再搞一套 cursor 就有点奢侈了

cursor 写提示词文档??? 咋个说法

＃27 就是说自己的需求，然后和 cursor 说请理解并分析需求，以合理的方式输出一个 markdown 文档，将内容写成提示词，我会交给 claude code 阅读并开发。
然后在 claude code 加载这个文件，直接说请遵守文档进行开发

＃26 嗯不是订阅 cc ，是用 api