这是一个创建于 34 天前的主题，其中的信息可能已经有所发展或是发生改变。
大家在使用 AI 进行开发的时候，是如何更好的进行需求描述的呢。每次在评审完，将需求翻译给 AI 是一个非常耗时的工作(不可避免这个工作是你对这个需求梳理的过程)，甚至可能因为你在打字的过程中，因为一些原因中断，导致后续可能遗漏当时的一些想法。
想和大家讨论下一般是如何解决这个问题的
 | 1 cz5424 3 月 22 日 另外一个帖子发了很多干货，可以直接看 https://v2ex.com/t/1199971 |
 | 2 sprinng 3 月 22 日  1 希望能帮助到你哦 http://v2ex.com/t/1199929 |
 | 3 aarontian 3 月 22 日 让 PM 出 prd |
 | 4 kasusa 3 月 23 日 我是用 todo 的形式 。 在外面写好 然后粘贴给 ai 。 如果我自己都看不懂我就会改。 然后每次 todo 发完了，ai 干完了，再验证一遍，每一项完成没完成，没完成复制一下继续描述哪里不对。 其次语音转文字很有用，打字的时候因为手懒会少说很多东西，但是实际上信息越多 ai 越理解你要什么，所以语音说的很嗦反而效果好一些。 最后就是 vibe 的时候，程序员本人得思路清晰。 而且 vibe ai 干活的时候可以去干点别的，比如整理房间、弹琴、刷短视频。。。 |
 | 5 byasm32 3 月 23 日 Vibe Coding 的质量大概率和使用人的能力成正比。 |
 | 6 pppwww OP @kasusa 是的，现在每天的工作就变成了花大量的时间写需求描述，然后审核方案，再就是 review code ，其实就算花了很多时间来做这个功能，仍然会有一些问题在编码/测试过程才能发现 |
| 7 pppwww OP 其实我也尝试使用 TDD 来驱动开发，然后你就会发现一个是 token 的花费会很高，另一个就是要花时间去审核 Ai 生成的测试用例，以及 Ai 生成的用例是否正确... |
| 8 kasusa 3 月 23 日 @pppwww 我还是手工测试比较多，代码的测试过了手工打开一看还是不行。。。 很常见。 花大量的时间写需求描述 其实是不必要的，我基本上是日常用这用着发现需求临时记录，然后有空了统一 vibe 出来。在真实使用的时候发现的点比坐在那里想的更实际。 |
 | 9 hailang609 3 月 24 日 描述需求这块，我踩过不少坑。 刚开始我也是写一大段，结果 Cursor 理解偏了。 现在我的套路： **第一步：先定角色** "你是个 Python 后端工程师，熟悉 FastAPI" **第二步：说人话描述** "我要做个用户登录功能，手机号+验证码" **第三步：给示例** "参考这个格式：{phone: '13800138000', code: '123456'}" **第四步：让它先写伪代码**br />确认思路对了再写详细实现 **第五步：逐行 Review** 别直接复制，AI 会犯低级错误 还有个技巧：把需求写成测试用例给 Cursor ，它理解得更准。 40 岁老程序员，最近 3 个月天天跟 AI 打交道，整理了一些 Prompt 技巧，需要的话私信我。 |
| 10 hailang609 3 月 24 日 补充一下，针对"写到一半被打断就忘了"这个问题： 说实话，我之前也这样，评审完需求写 Prompt 写到一半被同事打断，回头就忘了当时想啥。 现在我的做法： **1. 语音转文字** 评审的时候直接开录音，边说边录，比打字快多了，也不容易断思路 **2. 用飞书/Notion 边想边记** 不用组织语言，想到啥写啥，后面再整理成 Prompt **3. 做成模板** 常用的需求描述做成填空题，比如"我要做__功能，输入是__，输出是__"，每次填空就行 **4. 先草图后细化** 先快速记关键点，比如"用户登录-手机号-验证码-5 分钟过期"，后面再补细节 说白了，就是别让"写 Prompt"打断你的思路流。 40 岁老程序员，最近 3 个月天天跟 AI 打交道，整理了一些 Prompt 模板和技巧，需要的话私信我。 |
 | 11 jarryli 3 月 24 日 程序员必读的 Prompt Engineering 指南系列: https://github.com/microwind/ai-prompt |
Select Language