让 AI 逐题访谈，把需求聊成开发约束

写不出一份包含技术栈、约束和边界条件的长提示词，可以先让 AI 来采访你。作者用这个办法，把一个 Android 手机文档拍摄需求，逐步整理成可执行的开发任务，并让 agent 完成应用与现有门户的连接。

这篇短文值得读的地方，是它把「一次写清需求」改成了「逐个回答问题」。但作者的经历也暴露了一个问题：AI 如果不先读代码，采访同样可能浪费时间。

不会写完整提示词，能不能先回答问题

作者需要一台文档拍摄设备：把 Android 手机架在桌面上方的三脚架上，在 PaperLedger 的浏览器页面里查看实时预览，再通过「Capture」按钮拍摄。

需求看起来很直观，但交给 agent 开发，还需要确定技术栈、架构，以及哪些决策可以由 agent 自己做。通常的做法是先写技术规格，作者却直接要求 agent：采访自己，把这些事情问清楚。

提示词可以是对话整理出来的结果，不必是开始对话的门票。

这套做法把一次性的写作任务，拆成了连续的判断题。用户不用提前知道一份完整规格该有哪些章节，只需回答眼前的问题。原本开发时也要做的决定，便在问答中留下了记录。

不过，这没有消除需求分析的工作量，只是改变了组织方式。作者花了约一小时，发送了 72 条消息，agent 回复了 71 条。它降低的是从空白文档开始的门槛，是否节省总时间，原文没有给出比较。

采访的价值，在于补出你没想到的边界

这次问答中，agent 提出了作者自己没有想到的问题，例如：同一个门户同时在多个浏览器标签页打开时，会发生什么？

这类问题容易被一个看似简单的界面需求遮住。「有预览、有拍摄按钮」描述的是正常操作路径，多标签页则涉及不同页面同时使用系统时的行为。原文没有交代最终如何处理，但这个提问已经让需求从界面功能延伸到了运行边界。

问答结束后，逐渐形成了使用场景、决策边界，以及手机与门户之间的交互约定。所谓交互约定，就是两端如何配合、各自负责什么。

作者没有再手写一份最终提示词。收到「get started」指令后，agent 构建了应用，随后进入 Python 门户项目，将两端连接起来。

但采访并非全程有效。agent 在查看 PaperLedger 代码之前，花了很长时间追问集成方式。对于已有项目，有些答案已经写在代码里，再让用户口述一遍，既费力，也可能引入偏差。

我的判断

我认同作者把需求表达变成问答的思路。对于能描述使用场景，却不熟悉规格文档写法的人，逐个回答问题，比照着长提示词模板填空更容易开始。

但这个案例支持的是「方法可行」，还不足以证明它更快、更可靠。原文没有提供与直接写规格的对照数据，也没有交代测试结果、运行稳定性或后续返工情况。完成连接，是作者报告的结果，不能直接当成质量验证。

它还有一个前提：用户能够持续参与，并对关键取舍作出判断。72 条用户消息并不是零成本。面对复杂项目，采访也可能变成冗长的确认流程。

相比直接套模板，我更倾向于把两种方式结合起来：让 agent 先读已有代码，再围绕代码无法回答的产品选择逐项提问，最后整理出一份供人检查的决策记录。这里的整理步骤是我的建议，原文没有说明作者是否做过正式验收。

能拿来做什么

• 下次让 AI 开发功能时，如果写不出完整需求，可以先要求它「一次只问一个问题」，从实际使用场景开始逐步确认技术栈、架构和决策边界。
• 给已有前端或全栈项目加功能时，先让 agent 阅读相关代码，再询问需要你决定的事项，避免重复解释项目已经确定的实现。
• 对涉及多个页面或设备协作的功能，主动要求 agent 检查遗漏的边界，例如原文提到的多标签页同时打开，并把最终选择记录下来。
• 进入开发前，让 agent 汇总问答形成的场景、职责和交互约定。检查这些内容后再发出「get started」，更容易发现双方理解是否一致。