我在抖音上看到一段关于 AI 协作的视频。里面提到：开发之前，先让 AI 整理产品需求文档，写清楚要解决的问题、成功标准、开发范围、限制条件和计划。有疑问先问，正式开发前获得明确许可。
这个建议打动我的地方，是它能避免一种很浪费时间的情况：我只说了一个大概的想法，AI 就开始写代码。半小时、一小时后，东西做出来了，我才发现它理解的方向和我想的完全不同。
但当我让 GPT 帮忙把这套方法整理成提示词时，又遇到了另一个问题：它写得太详细了。
提示词越完整，沟通就越好吗？#
GPT 很容易把一段协作想法扩展成执行规章：先做什么、后做什么，哪些能改、哪些不能碰，最后要检查哪些项目。每一条单独看都有道理，放在一起却越来越像一份工作清单。
我担心，这会提前把 Claude 的思路框住。我找 AI 帮忙，也希望它能发现我没想到的可能性。如果连实现路径都被我预先安排好了，它还能发挥多少判断？
开发前值得明确的是问题和期待的结果。具体怎么解决，可以在交流中逐渐形成。
我更倾向于先用语音把想法讲出来#
比起花很长时间打磨一段结构严谨的提示词，我更愿意先用语音输入，把脑子里的想法说出来。
我遇到了什么问题，为什么想做这件事，现在的做法哪里不顺手，希望最后用起来是什么感觉。想到例子就举例，有犹豫也直接说。
表达可以零散，可以前后补充，不必一开始就像一份整理好的需求文档。AI 可以帮我从这些话里提炼重点，再把它理解到的内容反馈给我。
当然，语音转写也会有误差。碰到不合上下文的人名、术语或句子，应该结合上下文核对，必要时问一句。不能因为文字里出现了一个名字，就顺手把它写成文章的来源。
语音只是输入方式，关键是充分表达自己的处境和意图。 如果只说一句“帮我做个好用的工具”，换成语音也不会让需求自动变清楚。
让 PRD 从对话里长出来#
我认同开发前先形成需求共识，但不想把“先写 PRD”变成一套固定的填表流程。
我更希望这样开始：我先讲想法，AI 帮我整理；它有疑问就问，觉得方向有问题就提出来。如果存在更好的办法，也可以先拿出来讨论。
聊清楚以后，再把双方确认的内容整理成一份简洁的需求文档。任务复杂，就多展开一些；事情很小，几段话也可以说明白。
这份文档要让我看出：它是否理解了我要解决的问题，我们是否对预期结果有了共识，还有什么需要决定。至于具体技术方案，可以在这个基础上继续探索，不用在最初的提示词里全部规定好。
我仍然希望保留的几件事#
给 AI 发挥空间，也需要有可靠的协作习惯。
我希望它能主动质疑。当我的想法有技术问题、偏离原本目标，或者和之前的决定冲突时，直接指出原因，也提醒我没有考虑到的代价。
我希望重要决定有所记录。为什么选这个方向、后来改了什么、下一步还有什么没解决，应该留在项目里，方便下一次继续。记录围绕关键事实展开，不必把每段聊天原样归档。
我也希望在正式开发前，先确认双方理解一致。涉及删除数据、覆盖重要内容或其他难以撤回的操作时，再针对具体动作确认。
至于常规检查，我倾向于交给 AI 的工程判断和项目已有规范，不在每次开工的提示词里重复列一遍。但这是一种协作期待，不能据此认定它每次都检查充分。遇到我特别在意的要求，仍然应该明确说出来。
一段可以直接使用的开场提示词#
下面这段话适合放在具体需求之前。后面直接接语音输入的想法即可。
接下来我会用语音描述想法，可能比较零散，也可能有转写错误。你先帮我理解和整理，暂时不要开始写代码。
有不清楚的地方就问，觉得我的思路有问题也请直接指出。如果你想到更好的方向，也一起提出来，不必局限于我已经想到的做法。
等我们聊清楚后，再整理成一份简洁的需求文档，我确认后开工。过程中把关键决定记下来；遇到难以撤回的操作，先和我确认。我希望花在开工前的时间，主要用来把问题讲透、把分歧聊清楚。提示词可以短，需求交流可以充分；实现的方法，则留出空间一起探索。