📚 本文核心观点来源：Claude Code 之父的访谈式开发理念 + 个人迭代实践
大多数人用AI写代码，上来就说”帮我写一个xx功能”。
AI 立刻开干，噼里啪啦输出一大段代码。你一看，不对，不是我想要的。改需求，再来一遍。反复几轮，时间全浪费在返工上了。
我以前也是这样。有一次我让AI帮我写一个用户登录模块，说了一句”写个登录功能”，它给我生成了一套用户名密码的传统方案。但我实际想要的是第三方OAuth登录。改了三轮才对上，花了一个多小时。
直到看了 Claude Code 之父（CC之父）的一段分享，他说了一句话让我茅塞顿开：
“先让AI采访你，再让它动手。”
这个理念彻底改变了我用AI的方式。今天分享一下我基于这个理念，从零搭建的提示词体系，以及三个版本的迭代过程。
CC之父的核心提示词
先看原文，非常简短：
“Read this SPEC.md and interview me in detail about literally anything: technical implementation, UI and UX, concerns, tradeoffs, etc. But make sure the questions are not obvious. Be very in-depth and continue interviewing me continually until it is complete, then write the spec to the file.”
翻译过来就是：读一下项目说明书，然后深入采访我，什么都可以问，技术实现、用户体验、顾虑、权衡取舍，但问题不要太直白。要非常深入，持续采访直到信息充足，然后把结果写进文件。
这里面有三个关键洞察：
第一，AI先问，你先想。 不是你告诉AI做什么，而是AI通过提问帮你想清楚到底要做什么。很多时候你自己都没想明白需求，AI帮你挖出来。
第二，问题要有深度。 “你想做什么功能”这种问题太肤浅。好的问题应该是这样的：”如果这个功能上线后用户增长了10倍，你现在的数据库设计还扛得住吗？””你说要做权限管理，那如果将来部门结构调整了，权限体系能不能动态适配？”这种级别的问题才能帮你发现盲点。
第三，结果要沉淀。 访谈完不是聊完就完了，要写成SPEC.md（项目说明书），后续所有开发都基于这份文档。这样即使换了一个对话窗口，新的AI读一遍SPEC就能接着干。
我的迭代过程：从粗糙到系统
受到启发后，我开始在自己的项目里实践这个理念。经过三个版本的迭代，最终形成了一套完整的提示词体系。
V0：最初的尝试
最开始我照搬了CC之父的提示词，直接用在Antigravity里做CrewAI项目。效果立竿见影，AI不再瞎猜我的需求了。
举个真实的例子。我想做一个”自动化新闻摘要推送”的工作流，以前我会直接说”帮我写个新闻摘要推送功能”。用了访谈式提示词之后，AI问了我这些问题：
- “你希望摘要是每天推送还是实时推送？”
- “新闻源是RSS还是爬虫抓取？”
- “推送渠道是邮件、Telegram还是微信？”
- “如果某个新闻源宕机了，你希望怎么处理？”
- “摘要的长度你有没有偏好，100字还是300字？”
五个问题问完，我自己都惊了——原来我对这个需求的理解这么模糊。AI帮我一步步厘清了，最终输出的方案一次到位，几乎没有返工。
但问题也来了：AI只会采访，不会干活。 采访完就停了，我还得手动告诉它”现在开始写代码”。而且没有日志记录，过了几天再回来看，完全不记得上次聊到哪了。
这个版本让我意识到：光有访谈不够，还需要角色分工和过程记录。
V1：加入角色系统和日志
第二个版本，我做了三个关键升级。
升级一：三角色系统。 给AI设定了三个模式：
- 🎯 教练模式（
/coach）：负责访谈引导，帮你厘清需求 - ⚡ 执行模式（
/do）：专注实现，高效产出代码 - 📝 记录模式（
/log）：负责日志记录，过程可追溯
这三个角色的关系就像一个项目团队：产品经理先搞清楚需求（教练），开发工程师负责实现（执行），项目助理负责记录会议纪要（记录）。只不过这三个角色都是同一个AI在扮演。
升级二：日志协议。 引入了 project_journal.md 文件，每次完成重要节点，AI自动记录时间戳、变更类型、变更内容、以及为什么这么做。比如：
“2025-01-18 15:30，功能：完成了新闻摘要模块的RSS解析器，选用feedparser库因为社区成熟度最高”
这样即使隔了一周再回来，也能快速恢复上下文。
升级三：SPEC.md 规范。 把访谈结果标准化，每个项目都有一份说明书，包含目标、范围、技术栈、关键决策、待定事项。AI 每次开始工作前先读这份文档，确保方向一致。
这个版本的核心理念是六个字：先理解，后执行。
V2：专家模式和自动切换
第三个版本针对具体项目场景做了优化。
最大的变化是角色自动切换。 不再需要每次手动输入指令，AI会根据上下文自动判断应该进入哪个模式。你描述一个模糊的需求，AI自动切换到教练模式开始提问；你说”开始做”或者”OK”，AI自动切换到执行模式开始干活；完成一个重要节点，AI自动切换到记录模式写日志。
这个体验的提升是巨大的。以前像在指挥一个机器人，每一步都要手动操控。现在像在和一个有经验的同事协作，他知道什么时候该问、什么时候该做、什么时候该记。
第二个变化是专家模式替代了通用执行模式。 针对CrewAI Flow这个特定领域，AI的执行能力被具体化了，它知道要设计Agent角色、编排Task流程、配置Flow状态机、选择Tool集成方案。这比泛泛地说”帮我写代码”精准得多。
第三个变化是访谈有了明确的结束机制。 要么用户说”可以了”、”开始吧”，要么AI自己判断信息已经足够。不会无限问下去，也不会问到一半就跑去写代码。
为什么这套方法有效
用了这套提示词体系几个月，我总结出几个核心原因。
第一，减少返工。 以前AI直接写代码，大量时间在返工。现在先访谈再动手，返工率大幅下降。省下来的时间远远超过访谈花的时间。一个15分钟的访谈，可能省掉2小时的反复修改。
第二，AI变成了思维伙伴。 很多时候你觉得自己想清楚了，其实没有。AI的提问会逼你面对那些你没想到的边界情况。”如果用户断网了怎么办？””如果两个Agent同时修改同一个文件会冲突吗？””你的API密钥泄露了有没有回滚机制？”这些问题你自己想不到，但AI能帮你挖出来。
第三，过程可追溯。 有了日志和SPEC文档，项目不怕中断。我有一个项目中间放了两周没碰，回来之后读了一遍 project_journal.md，五分钟就想起来所有上下文，无缝继续。如果没有日志，可能要花一个小时翻聊天记录。
第四，适用范围广。 这套方法不限于写代码。我用它写过公众号文章（AI先访谈我想表达什么观点、目标读者是谁、语气偏好），做过产品需求文档，甚至规划过学习路线。任何需要”先想清楚再动手”的事情，都可以用这套方法。
你可以直接用的核心思路
如果你不想从零搭建完整体系，至少记住这三点：
第一，永远先让AI问你问题。 不管你要做什么，第一句话不要是”帮我做xx”，而是”我想做xx，请先深入了解我的需求，问我一些有深度的问题”。光是这一个改变，效果就能提升一倍。
第二，给AI分角色。 告诉它什么时候该问、什么时候该做、什么时候该记录。不要让一个模糊的AI身份贯穿整个对话。角色越清晰，AI的输出越精准。
第三，让成果沉淀成文档。 不管是访谈结果、项目日志还是技术决策，都让AI写成文件保存下来。你未来的自己会感谢现在的自己。
一点感悟
CC之父的这个理念看起来很简单，但背后是一个深刻的认知转变：AI最大的价值不是替你干活，是帮你想清楚。
大多数人把AI当打字机，告诉它写什么就写什么。但真正高效的用法是把AI当教练，让它用好问题逼你深度思考。
就像健身房里的私教，他最大的价值不是替你举铁，而是告诉你”你的姿势不对，这样练会受伤”。AI也是一样，它最大的价值不是替你写代码，而是问你”你确定这个架构能支撑你的业务增长吗”。
写代码是这样，做决策是这样，甚至人生规划也是这样。
先问清楚，再动手。这个顺序很重要。
💬 需要帮助？
想用 Antigravity 来实践这套方法？ 我这边可以提供反重力账户，帮你快速上手AI辅助开发。
Antigravity 登录遇到问题？ 登录报错、无法验证等问题我都能帮你解决。
联系方式
微信号：h314896654
添加时请备注：反重力，方便快速通过验证
📅 本文基于CC之父的访谈式开发理念，结合个人实践经验总结。
提示词原文和迭代版本均来自真实项目。