还在等研发排期?不懂代码的 PM,如何用 AI 独立上线赚钱产品?

关键词：非技术PM | Cursor工作流 | AI模型互评

大家吼，我是 Silverfox 。👋

承认吧，作为产品经理，你肯定有过这样的时刻：

深夜冒出一个绝妙的点子，甚至连交互细节都在脑子里跑通了。但第二天到了公司，面对排得满满当当的Sprint，看着研发疲惫的眼神，你只能把这个点子默默塞进积灰的Backlog里，安慰自己“下个季度再说”。

这种无力感，是所有非技术背景PM的隐痛。 我们懂业务、懂用户，唯独缺了把想法直接变成现实的那双手。

Meta的产品经理Zevi Arnovitz和你我一样，零技术背景，高中学的是音乐，甚至对看代码有种天然的恐惧（Code Phobia）。但他现在利用周末时间，独立开发并上线了盈利的产品（StudyMate）。

他不是去学了Python或React，而是悟出了一套“以PM为核心的AI开发工作流”。他把AI驯化成了自己的CTO、主力开发和QA团队。

我看完了他和Lenny的深度对谈，把他这套价值连城的“零代码实战SOP”拆解出来，希望能帮你打破那层技术壁垒。

一、 别急着写代码，先搞定“数字CTO”

很多PM用AI写代码失败，是因为把AI当成了“实习生”——你让它干嘛它就干嘛。

Zevi发现，如果直接让AI写代码，它会为了讨好你（People Pleaser），哪怕你的架构设计是错的，它也会硬着头皮写，最后留下一堆修不好的Bug。

核心心法：你要构建一个敢于Challenge你的CTO。

Zevi在ChatGPT或Claude Projects里创建了一个Project，植入了一段System Prompt（系统提示词）：

“你是我的技术合伙人/CTO。我负责定义问题和用户体验，你全权负责技术实现。不要做老好人，如果你觉得我的想法在技术上不可行，或者有更好的架构方案，请直接反驳我。”

入门建议： 别一上来就用Cursor这种硬核工具。先在ChatGPT里用自然语言跟这个“数字CTO”聊。聊透了架构，再去碰代码。这就好比做需求评审，逻辑跑不通，写代码就是徒劳。

二、 Zevi的“Cursor实战SOP”

当Zevi觉得Bolt或Lovable这类“一键生成”工具已经无法满足复杂需求时，他转向了Cursor + Claude Code。但他没有盲目堆代码，而是把PM的流程感带入了开发：

他在代码库里预设了一系列 /Slash Commands（斜杠指令），把每一次开发都变成了一次标准的各种角色的协作。

1. 灵感捕捉：/create issue

不要打字。Zevi用语音输入（Whisper Flow），直接把想做的功能“说”出来。这个指令会触发Claude，把原本碎片的语音，整理成一份结构清晰的 Linear Ticket（开发工单）。它会自动补充背景、验收标准，甚至去读现有的代码库，看看这个新功能会不会和旧逻辑冲突。

2. 深度评审：/exploration

这是最关键的一步。在这个阶段，严禁写任何一行代码。输入这个指令后，AI会进入“技术负责人”模式。它会阅读相关代码，然后向你提问。比如：“你要加个‘填空题’功能，那数据库Schema要不要改？前端交互是拖拽还是输入？老数据的兼容性怎么处理？”这一步是为了消灭“想当然”。

3. 生成蓝图：/create plan

经过评审后，AI生成一份Markdown格式的实施计划（Plan.md）。这里有个巧劲：这份计划必须包含“关键决策”和“分步执行清单”。有了这个清单，你就可以把任务拆解，分发给不同的模型去执行。

4. 执行开发：/execute

这时候才真正开始写代码。Zevi通常会用Cursor的Composer功能，因为它快；或者针对前端UI调整，调用Gemini模型（因为Gemini虽然逻辑有时候疯癫，但在审美和UI代码生成上非常有灵性）。

三、 杀手锏：让模型“互掐” (Peer Review)

这是Zevi工作流里最精彩的一环。

作为非技术人员，我们要么看不懂代码，要么根本发现不了潜在的逻辑漏洞。Zevi的解决方案是：养蛊。

他把不同的LLM（大模型）拟人化，赋予它们不同的性格，让它们互相Code Review：

• Claude (Anthropic)：她是那个沟通能力极强、逻辑缜密、有点洁癖的Team Lead。

• Codex (OpenAI)：他是那个穿着卫衣、坐在角落暗房里、虽然不爱说话但技术深不可测的黑客/扫地僧。他能一眼看出最晦涩的Bug，但懒得解释为什么。

• Gemini (Google)：他是那个疯批艺术家。如果你让他改UI，他可能为了美观把你的数据库都删了（这是真事），但在创意和视觉上无人能敌。

操作步骤：

1. 写完代码后，输入 /review，让Claude先自查一遍。

2. 输入 /peer review，召唤OpenAI的模型对同一段代码进行审查。

3. 如果不一致，就把OpenAI的意见贴回给Claude：“你的同事觉得这里有安全隐患，你怎么看？”

4. 看着它们“吵架”，直到一方说服另一方，或者达成共识。

通过这种“模型互斥”，Zevi作为一个不懂代码的人，竟然能保证代码的健壮性。

四、 避坑指南：把错误变成资产

很多新手用AI写代码，遇到Bug修好了就过去了。Zevi的做法更近一步：复盘（Post-mortem）。

当AI犯了一个愚蠢的错误，或者在某个环节卡住了，不要只是重试。Zevi会问AI：

“你为什么会犯这个错误？是因为我的Prompt没写清楚，还是你的工具文档（Docs）缺失了信息？”

如果是Prompt的问题，就去优化/commands；如果是信息缺失，就让AI更新项目文档。要把每一次报错，都变成系统Prompt的一次迭代。 这样，你的“数字员工”才会越来越懂你的业务逻辑，而不是每次都要从零调教。

五、 本质升华

Zevi的故事最打动我的，不是他用了什么酷炫的工具，而是他彻底改变了“学习”的定义。

在Wix工作初期，他曾试图在产品评审会上表现得无所不知，结果惨败。后来他明白了一个道理：没人指望Junior PM是全知全能的，但大家指望你是“10倍速的学习者”。

有了AI，技术不再是护城河，好奇心和提问能力才是。

我们经常听到那句被说烂的话：“你不会被AI取代，但会被善用AI的人取代。”Zevi把它具象化了：与其担心被取代，不如现在就打开Cursor，把那个在你备忘录里躺了半年的Idea，变成现实。

未来已来，只是分布得还不够均匀。而你，完全可以是先拿到的那个人。

数据来源与参考

本文的核心干货与实战案例，深度拆解自 Lenny's Podcast 与 Meta 产品经理 Zevi Arnovitz 的精彩对谈。在此基础上，我结合了相关网络公开资料与技术文档进行了二次梳理与验证，旨在为中文读者还原这套极具落地价值的 AI 开发工作流。致敬原作者的无私分享，也强烈推荐有条件的读者去收听原版播客，感受原汁原味的思维碰撞。

如果这篇文章刺痛了你，或者启发了你，点个“在看”，我们下期继续祛魅。 ❤️