6 个 Prompt 心法案例演示：AI 代码审查 SaaS 产品
原文：分享 6 个平时我最常用的 Prompt 心法 - 数字生命卡兹克
作者：卡兹克 | 公众号：数字生命卡兹克
总结日期：2026-06-02
原文 6 个心法速览
作者分享了日常使用 AI 的 6 个 Prompt 心法，核心观点：Prompt 没那么高深，本质是沟通方式。让对话变成协作，让提问变成设计。AI 不怕你笨，怕的是模糊。
- 让 AI 选定角色后再回答 — 不知道设什么角色？让 AI 帮你选最合适的领域专家
- 苏格拉底式追问 — 回答前先追问，直到 95% 信心理解你的真实需求
- 与 AI 辩论 — 让 AI 当反对者，打破谄媚效应
- 预演失败 — 假设项目已失败，写一篇复盘文章
- 反向提示 — 给成品让 AI 逆向出 Prompt，拆解学习
- 双层解释法 — 初学者版 + 专业版对照学习
统一案例：「AI 代码审查 SaaS 产品」× 6 个心法
案例背景
你有个模糊想法：想做一个面向程序员的 AI Code Review 工具，做成付费 SaaS 产品。但不知道从哪下手。下面用 6 个心法，把这个想法一步步「逼」出可落地的方案。
一、让 AI 选定角色后再回答
Prompt：
我想探讨 SaaS 创业里的「从零到一的产品规划」。先别回答。请你先选一位最适合的领域顶尖名人专家来思考它。先输出：1. 你选谁，他对应的细分领域 2. 为啥选他，三句话。然后再让我描述详细的问题。
AI 回复：
我选：Lenny Rachitsky
细分领域：SaaS 产品从 0 到 1 的定位与增长策略
为什么选他：
- 他是前 Airbnb 产品负责人，亲身经历产品从 0 到 1 的全过程
- 他的 Newsletter 是 SaaS 创业者圣经，访谈过数百位创始人，提炼了大量可复用的方法论
- 他特别擅长「先验证再开发」的务实路线，而不是纸上谈兵
为什么比直接指定角色好： 你自己可能只会写「你是一个产品经理」，但 AI 给你选的是具体的人——有名字、有背景、有方法论。角色越具体越真实，效果越好。
二、苏格拉底式追问
Prompt：
我想做一个面向程序员的 AI 代码审查 SaaS 产品。请在回答前，先问我问题。一次只问一个问题，根据我的回答继续追问，直到你有 95% 信心理解我的真实需求，然后才给出方案。
追问过程（节选）：
| 轮次 | AI 的问题 | 你的回答 |
|---|---|---|
| 1 | 你自己有 code review 被阻塞的痛点，还是观察到别人的痛点？ | 观察到。开源项目和公司团队里 PR 堆好几天没人看 |
| 2 | 目标用户的付费来自个人掏腰包还是公司采购？ | 先切个人开发者，决策快，用好了带进团队 |
| 3 | 现有竞品（Copilot/Cursor）里你最不满意的是什么？ | 它们的 review 建议太「正确但没用」——全是 lint 级别 |
| … | （继续追问十几轮） | … |
AI 最终输出：
我现在 95% 确信理解了。你的真实需求是：做一个低摩擦接入 GitHub、先切个人开发者、核心卖点是「review 速度 + 真正有用的建议而非 lint」、价格在 $10-20/月的产品。以下是方案……
为什么有用： 如果不追问，你扔一句「帮我规划一个 SaaS 产品」，AI 只能给泛泛的「做市场调研、找 PMF」。追问后，AI 才真正知道你要什么。
三、与 AI 辩论
Prompt：
我的观点是：「AI 代码审查工具的护城河是审查质量，不是先发优势，所以应该花 6 个月打磨模型再上线。」
请你扮演反对者，用尽一切论据、细节和逻辑来挑战我，证明我是错的。
AI 的反驳：
你的论点是错的。原因有三：
1. 打磨 6 个月你能磨什么？
代码审查质量的瓶颈不在模型本身，而在上下文理解——你需要真实的用户场景来迭代。没有真实用户反馈的「闭门造车式打磨」，你磨出来的可能是自己臆想的「高质量」，上线后发现用户要的根本不是这个。
2. 先发优势不重要，但「使用量护城河」极其重要。
用户用你的工具越多，你积累的 review 偏好数据越多，推荐越准。你晚 6 个月上线，竞品可能已经积累了 10 万条真实 review 数据，你的模型再强也追不上这个差距。
3. 付费意愿是靠「解决痛点」验证的，不是靠「质量好」验证的。
你甚至不知道用户愿不愿意为 code review 付 10，哪怕只有 5 个用户，也比 0 付费的「完美产品」有价值 100 倍。
你还坚持你的观点吗？
为什么有用： 你觉得自己想得很清楚，但 AI 指出了三个你没意识到的致命盲区。作者说得对：「被 AI 折服」。
四、预演失败
Prompt：
我的项目：做一个 AI 代码审查 SaaS，先切个人开发者，定价 $15/月，接入 GitHub，MVP 用 4 周开发。
请假设这个项目 6 个月后失败了拉了大跨。写一篇「失败复盘文章」，回答：什么时间点出现衰退信号？最致命的决策错误？被忽视的核心风险？如果能重来第一个改什么？
AI 的失败复盘文章（节选）：
AI Code Review SaaS：一个 6 个月烧掉 2 万行代码却只有 47 个免费用户的故事
衰退信号出现在第 2 个月
MVP 上线后有 200 人注册试用，但 7 日留存只有 8%。当时团队的判断是「功能不够多」，于是拼命加功能——支持 GitLab、支持 Bitbucket、支持自定义规则、支持团队协作……功能从 5 个膨胀到 23 个。但留存纹丝不动。
最致命的决策错误
把「review 建议不够好」误判为「功能不够多」。
用户离开的真实原因不是缺少 GitLab 支持，而是 review 建议太「正确但没用」——全是命名规范、空行这种 lint 级别的意见，而用户真正想要的是「这个 SQL 查询在 100 万行数据下会慢」「这个并发逻辑有竞态条件风险」。我们没有花时间让 review「变聪明」，而是花时间让它「变多」。
被忽视的核心风险
个人开发者的付费转化率天然极低。
我们以为 $15/月够便宜，但独立开发者对工具付费极其理性。调研后才发现，目标用户里愿意付费的不超过 3%，而这 3% 里又有 80% 已经用 Copilot/Cursor 了。个人市场打不通，企业市场又没切进去，夹在中间死了。
如果能重来，第一个改的
上线前先做「假 MVP」测试。 做一个 landing page + 手动 review 的体验，看有没有人愿意付费。而不是先写 4 周代码。
为什么有用： 作者原话——「排队、盒饭、厕所、安检、动线的风险，之前完全是我的认知盲区。」预演失败帮你看到做计划时被热血掩盖的盲区。
五、反向提示
场景： 你看到一篇很棒的 SaaS 产品发布文章，想模仿那种节奏和结构来写你的产品发布文案，但说不清它好在哪。
Prompt：
这是我想要的成品范例。[粘贴一篇优秀的产品发布文章]。请你倒推一个提示词，让我用它能稳定生成同风格的内容。并说明这个提示词里每一句的作用。
AI 逆向出的 Prompt：
写一篇 SaaS 产品发布文章，长度约 1500 字，结构如下：
- 用一个程序员共有的具体痛点场景开头（不超过 3 句话），让读者立刻产生「这就是我」的共鸣
- 一句话揭示「问题根源」，用对比手法（「不是 X，而是 Y」）
- 引入解决方案，但不堆功能——只讲「解决什么」不罗列「有什么」
- 穿插一个真实使用场景的片段（对话体 or 操作体），让读者能想象自己用产品的样子
- 定价信息自然嵌入（不作为独立段落），用「算一笔账」的方式让价格显得划算
- 结尾用一句金句收束，让人想转发
各句作用解析：
| 句子 | 作用 |
|---|---|
| 第 1 句（痛点场景） | 制造「身份认同」，3 秒抓住目标读者 |
| 第 2 句（对比） | 制造认知落差，让读者觉得「原来如此」 |
| 第 3 句（解决什么） | 避免功能罗列带来的审美疲劳，聚焦价值 |
| 第 4 句（场景片段） | 全文最关键的「信任构建器」——比任何文案都有说服力 |
| 第 5 句（算账式定价） | 把价格从「成本」重新定义为「收益」，降低付费心理门槛 |
| 第 6 句（金句收束） | 给读者一个转发/保存的理由 |
为什么有用： 你可以「复刻个型但复刻不出来魂」，但反向推出来的 Prompt 帮你拆解了好内容的结构和节奏，融入自己未来的创作。
六、双层解释法
Prompt：
我想了解 AI 代码审查中的「AST 语法树」是什么，它跟 review 质量有什么关系。
请用两种方式回答：
- 初学者版本：面向洗脚城的大爷，用大爷也能听懂的话解释
- 深度专业版本：面向有经验的软件工程师
AI 回复：
初学者版（给洗脚城大爷讲）
大爷，你知道你们洗脚城有本服务手册吧？上面写着「先泡脚、再搓脚、再修指甲」，不能乱了顺序。
AST 就是电脑读代码时自己画的一份「服务流程图」。比如你写 if (脚脏了) { 洗脚() }，电脑一看，不是看那行字，而是把它拆成：「哦，这里先判断脚脏不脏，真脏了就执行洗脚，不脏就跳过」——它把代码拆成了一棵树，根是「判断」，往左是「脚脏了」，往右是「洗脚」。
有了这棵树，AI 做代码审查时就不是瞎看，而是能顺着树检查：「你这里判断了脚脏不脏，但洗完脚怎么没有擦干的步骤？漏了吧！」——没这棵树，AI 就是个看字的瞎子，有了树，它才看得懂代码的逻辑结构。
深度专业版
AST（Abstract Syntax Tree）是编译器/解析器将源代码转换为树状中间表示的结果，每个节点对应一个语法结构（IfStatement、FunctionDeclaration、BinaryExpression 等），去除了空格、注释等无关信息，保留程序的完整结构语义。
在 AI 代码审查中，AST 的作用体现在三个层面：
- 结构化理解：模型不是看 raw text，而是基于 AST 的父子/兄弟关系理解控制流和数据流，这直接决定了能否检测出「if 分支缺少 return 语句」这类结构性缺陷
- 上下文窗口效率：AST 剪枝后 token 量比 raw code 少 30-50%，同等窗口能容纳更多逻辑上下文，提升跨函数/跨文件的缺陷检测准确率
- 确定性规则引擎：ESLint/Sonar 类工具就是基于 AST 做模式匹配，AI 可以在此基础上做语义层面的增强——AST 负责「有没有」，AI 负责「对不对」
总结：没有 AST，AI 做的是文本补全；有了 AST，AI 做的是程序理解。这是 review 质量从「表面正确」到「逻辑正确」的分水岭。
为什么比「我是个六年级小学生」好： 作者说「小学生」版太幼稚。换成「洗脚城大爷」，AI 给的比喻生活化但不幼稚，同时专业版给你真正的深度。
总结
同一个出发点「想做 AI 代码审查工具」，六个方法各做了一件事：
| 方法 | 解决的问题 | 产出 |
|---|---|---|
| 选角色 | 不知道该听谁的 | Lenny Rachitsky 的思维框架 |
| 追问 | 说不清自己到底要什么 | 精准定位到个人开发者 + 低摩擦 |
| 辩论 | 想法有盲区不自知 | 暴露「闭门造车」的致命风险 |
| 预演失败 | 只看到乐观面 | 提前发现留存和付费转化陷阱 |
| 反向提示 | 知道好但说不出好在哪 | 提炼可复用的文案结构 |
| 双层解释 | 似懂非懂 | 从「大概懂了」到「真正理解了」 |
每句话都让想法更结实一点。 你不需要做 Prompt 大佬，只需要做自己问题的导演。