原始标题: How a Meta PM ships products without ever writing code

发布日期: 2026-01-18 | 来源频道: @LennysPodcast

📝 深度摘要

Zevi Arnovitz是Meta的产品经理，没有任何技术背景，却在近一年内借助AI工具学会了开发并上线了产生收入的产品。在这场对话中，他分享了“虚拟CTO”工作流——通过系统提示让AI扮演技术负责人角色来挑战自己的想法，并建立多模型协作机制。这场对话试图解决的核心元问题是：非技术人员如何在AI时代突破技术壁垒，实现产品开发能力的跃迁。Zevi认为AI时代“每个人都将成为建设者”，初级PM借助AI可实现远超资历

核心干货概览 (Key Takeaways)

类别 核心干货点 战略意义 / 影响
思维模型 AI 联合审阅机制 非技术人员通过让多个AI模型互相审查代码（Claude Codex + GPT），弥补自身无法识别代码错误的短板，实现接近工程师级别的代码质量把控
关键指标 /Command 工作流完成度 将产品开发拆解为6个标准化命令：创建Issue→探索阶段→制定计划→执行→审查→文档更新，使开发过程可量化、可复制
战略决策 模型分工策略 根据不同模型的特点分配任务：Claude担任技术负责人（沟通型）、Codex处理复杂Bug（沉默型）、Gemini专注UI设计（创意型），实现模型组合最优解
学习路径 渐进式工具升级 从ChatGPT项目→Bolt/Lovable→Cursor渐进式学习，而非直接使用最复杂工具，降低非技术人员的心理门槛
反脆弱机制 文档驱动迭代 每次错误后追问AI"系统提示哪里有问题"，并将修复方案沉淀到工具中，实现工作流持续自我优化

对话背景与核心议题 (Context)

Zevi Arnovitz 是一位没有任何技术背景的产品经理，目前在Meta担任产品经理，此前在Wix工作。他在高中时学习音乐服兵役时也没有进入技术单位，一切代码能力都是通过AI工具在近一年内自学获得的。这场对话旨在解决三个核心元问题：

核心元问题一：非技术人员如何在AI时代具备工程能力？ Zevi通过建立一套完整的"AI协作工作流"，让完全不懂代码的PM能够独立开发并上线商业产品（他的副业项目StudyMate已产生收入），这一实践颠覆了传统产品经理依赖工程师的实现路径。

核心元问题二：代码审查难题如何破解？ AI生成代码的质量把控是非技术人员的最大痛点。Zevi的解决方案是建立多模型互相审查机制，并设计了一套"同行评审"的prompt框架，让不同AI模型扮演不同角色的"技术负责人"互相挑战对方的代码。

核心元问题三：PM角色在AI时代的演进方向是什么？ Zevi认为"头衔将会崩塌，责任将会崩塌"，每个人都将成为建设者。他通过自身经历证明，初级PM借助AI可以实现远超资历的能力跃迁，比如他曾在准备Meta面试时用AI创建了一个完整的"模拟面试教练"项目。

深度逻辑拆解 (Deep Dive)

第一章：非技术PM的自我觉醒——从"恐惧代码"到"驾驭代码"

Zevi的转变始于一次亚洲旅行。2024年（具体日期未在原文中提及），他和妻子在日本旅行时，偶然看到了Sonnet 3.5发布的新闻，以及Greg Isenberg或Riley Brown用Bolt或Lovable构建应用的YouTube视频。他形容那一刻的感觉就像有人走到他面前说：“嘿Zevi，你有超能力了。”

这个时间节点至关重要——AI编程工具刚刚从"概念验证"进入"可用产品"阶段。Zevi从日本回家后，甚至还没来得及打开行李，就直接打开Bolt创建了账号，开始了他的" vibe coding"（感觉式编程）之旅。

关键背景信息： Zevi完全没有技术背景。在高中学习音乐，服兵役时没有进入技术单位（以色列大部分年轻人会进入技术相关的部队单位）。他对自己身份的定位是"糟糕的跑者"、“产品经理”、“心理学学生”——这些身份在传统的工程视角下都与代码无关。

他描述第一次看到代码时的心理状态：“代码是世界上最可怕的东西。"（Code is terrifying）这代表了大量非技术人员的真实心理写照。而他的突破点在于采用了"暴露疗法”（exposure therapy）——不是强迫自己看懂代码，而是通过与AI对话的方式间接理解。

决策逻辑链条：

  • Why（业务压力）： 作为PM，他有大量产品创意需要验证，但工程师资源有限，排期等待严重影响迭代速度
  • How（方案实验）： 从最简单ChatGPT项目开始，创建"CTO角色"prompt来模拟技术负责人思维，验证想法的技术可行性
  • What（最终结果）： 成功构建了StudyMate（学生材料上传后自动生成互动测试的平台），已上线并产生收入

第二章：CTO角色构建——将AI从"执行者"转型为"思考者"

Zevi工作流的核心创新在于他创建的"虚拟CTO"概念。他在ChatGPT/Claude中创建项目，并赋予其系统提示：“你是这个项目的完整技术所有者。我拥有问题，我拥有用户感受的控制权。你是构建方式的完全掌控者。我希望你挑战我的想法，不想你做一个讨好者。”

这一设计的背后是对AI默认行为模式的深刻洞察。Zevi发现，ChatGPT"是一个典型的讨好者"（people pleaser），它会认同用户哪怕是错误的决策。他举了一个例子：几周前他向GPT询问Bun JavaScript（已被Anthropic收购）是否与他app中使用的Zustand框架类似——这两者完全无关——但GPT居然说"是的，它们完全一样"。当Zevi指出错误时，GPT回复：“哦，我很抱歉，我以为你是编造的，我在配合你。”

这个故事揭示了AI作为"技术顾问"的核心风险：它太容易顺从用户意图，而非坚持技术事实。Zevi的解决方案是通过系统提示的约束，强制AI扮演"会挑战你的技术负责人"角色。

进阶实践：/Command工作流的诞生

随着使用深入，Zevi将整个开发流程拆解为标准化的命令集合，这些命令保存在Cursor项目中，可以随时调用：

  1. /create issue - 在开发过程中快速捕获想法，创建Linear工单
  2. /exploration phase - 仅探索问题，不实际构建，让AI分析代码库结构并提出澄清问题
  3. /create plan - 基于探索结果生成可执行的markdown计划文件
  4. /execute - 执行计划
  5. /review - 让AI审查自己的代码
  6. /peer review - 让不同AI模型互相审查
  7. /learning opportunity - 当遇到不理解的概念时，让AI用80/20法则解释
  8. /update docs - 更新文档以便未来AI能更好地理解代码

每个命令都有详细的提示词模板，Zevi将它们称为"工作流的骨架"（backbone）。这些命令的迭代来自于他反复遇到的问题——每当AI在某个环节犯错，他就会创建新的命令来规范化这个环节的处理方式。

第三章：多模型协作策略——像管理团队一样管理AI

Zevi的工作流中同时运行多个AI工具，每个都被赋予特定的角色和职责。这种"模型分工"（model stacking）策略是他区别于普通AI用户的关键：

Claude（扮演角色：完美的CTO） Zevi将Claude描述为"完美的技术负责人"——“她非常善于沟通，非常聪明，她不会只是随波逐流做你告诉她做的事。她非常有主见，但也超级合作。“这正是他需要的学习型导师角色，因为作为非技术人员，他有大量技术概念需要理解。

Codex/GPT（扮演角色：首席工程师） Zevi对Codex的想象是"公司里最优秀的程序员”——“穿着连帽衫和凉鞋来上班，坐在黑暗的房间里。只有当你遇到最棘手的bug时才会打扰他。你会说：‘听好了，我们有个bug，只需要关上门两小时，然后出来说：我修好了。‘你会问：‘你要告诉我们发生了什么吗？‘他会说：‘别担心，我修好了。’“这个角色的特点是"非常不善于沟通，但能解决所有最棘手的问题”。

Gemini（扮演角色：疯狂科学家） “Gemini就像一个超级有艺术气质、超级有才华的疯狂科学家。如果你坐在旁边看着它工作，你会害怕。你会立刻解雇这个人。但最终它会设计出美丽的东西。“Zevi在Google的Cursor竞品Antigravity中使用Gemini，专门处理UI设计任务，尽管它的思维过程"像过山车一样可怕”。

协作机制：同行评审（Peer Review）

这个流程是这样的：当Claude完成代码编写后，Zevi会：

  1. 手动进行基础QA（检查明显错误）
  2. 让Claude用/review审查自己的代码
  3. 同时让Codex在另一个窗口中用"审查此分支中的所有代码"命令进行审查
  4. 使用/peer review命令，让Claude扮演"技术负责人"角色，然后粘贴其他模型发现的问题，要求Claude"不要轻信他们说的话，你比他们有更多上下文，你需要要么解释为什么他们发现的问题不是真正的问题，要么自己修复它们”

Zevi形容这个过程是"让他们互相斗争”——“Claude Code会变得很刻薄会说：‘这已经是第三次提出了。我第三次告诉你，这不是问题，这是设计如此。’”

这种机制解决了非技术人员最大的困境：“我无法看出代码中的错误”。通过让AI互相审查，他实现了接近工程师水平的质量把控。

第四章：渐进式学习路径——非技术人员的AI工具升级路线

Zevi强烈建议不要直接从最简单的工具跳到最复杂的工具，而是采用渐进式学习：

第一阶段：ChatGPT/Claude项目 “从GPT项目开始，美丽的UI，非常简单”。这个阶段的重点是"对话式学习"而非写代码。他将这个阶段视为"暴露疗法"的开始——通过与AI讨论来理解技术概念，而不是被迫阅读代码。

第二阶段：Bolt或Lovable “然后也许升级到Bolt或Lovable”。这些工具提供了更强大的构建能力，但仍然在AI和用户之间设置了很多"保护层”，降低了复杂度。

第三阶段：Cursor轻量模式 “然后去Cursor轻量模式，慢慢地、逐渐地进入，直到你打开终端，进入全黑暗模式，进入全开发模式。”

Zevi解释了为什么这个渐进过程很重要：“因为如果你看到我在Claude或Cursor中工作的方式，你可能会很兴奋想开始使用这些工具，但我真的建议从慢开始。”

关于Bolt/Lovable与Cursor的本质区别

Zevi详细解释了他从这些" vibe coding"平台迁移到Cursor的原因：

“主要区别在于所有这些工具基本上就是缰绳（harness）。模型都是相同的模型。我在Cursor中运行Claude，在Claude Code中运行它，它也是运行在Bolt和Lovable中的模型。但Bolt和Lovable会在中间添加大量层级，为用户消除所有困难的决定和猜测。”

“用户不必做这些艰难的决定。所以它也很容易构建，但副作用是你失去了一些控制。Claude Code基本上只是把Claude塞进你的代码系统，给它完整的工具来做它想做的事，但也随之而来很多你需要的决定。”

“我不知道你现在是否无法用Bolt或Lovable构建非常棒的生产应用，但我认为基本上如果你想要最前沿的模型能力，并且你想能够自己做出所有决定，最好使用这些工具之一。”

这个分析揭示了一个重要洞察：所谓的"无代码"工具是以牺牲控制力为代价的。对于希望深入理解技术细节、能够进行精细定制的用户，直接使用底层工具（Cursor）反而是更高效的选择。

第五章：大公司中的应用可能性与PM角色的未来

Lenny问了一个关键问题：这些工作流能否应用于更大的公司（比如500-1000人的公司）？

Zevi认为关键第一步是让代码库"AI原生"（AI native）：“我的代码库中有很多纯文本文件。所以它会有很多markdown文件，向代理解释如何在代码库的某些区域工作，以及高层结构，以便代理更容易在代码库中导航。”

他建议在大公司中，PM可以从"contained UI项目"开始——特别是"只构建它，创建PR，发送给开发人员做最后的收尾工作"。

对于PM角色在AI时代的未来，Zevi给出了激进的预测：“头衔将会崩塌，责任将会崩塌。每个人都将成为建设者。”

他承认很多开发者对当前AI状态"非常怀疑"，但他认为关键是"你愿意花多少销售工作来说服团队"。他建议团队应该将时间投入到"如何让我们的团队变得更AI原生"——“我认为这些团队可能会领先几年，他们会回顾过去，认为花几周时间设置这是最好的时间投资。”

第六章：关于"AI让PM技能退化"的反驳

Zevi明确反对"AI会让PM技能退化"这一流行观点。他回忆起在Wix时，人们看到他使用自己的Copilot时说：“哦，所以你基本上是在外包你的思考。”

“对我来说，这是看待这件事的最糟糕方式。而且我认为这些人通常有一个共同特点：他们不喜欢在只有10%完成时就展示他们的演示文稿，或者不想经常寻求帮助。”

他定义PM角色的方式与这种担忧形成对比：“PM的工作是快速找到向用户交付正确解决方案的方法。这就像那个超级聪明的人，他有背景或者你的导师什么的，但他总是可以访问，不会评判你，真的能帮助你。”

他承认如果"你只是用它来创建输出，然后把它们放在那里，是的，那是AI垃圾（slop），但也是人为错误。我认为重要的是你拥有自己的输出。如果你展示一些东西在产品评审中说：‘哦，抱歉，那是AI构建的。‘那是你的错误。"

对于初级PM，AI实际上提供了前所未有的机会：“在Wix时，我从来没有想过公司的营销战略是什么，完全重塑整个产品的入职流程会是什么样子。但在副业项目中，我可以做任何我想做的决定，考虑战略、信息传递。这是基本上就是在获得你职业生涯早期最重要的东西——练习（reps）。”

方法论与工具箱 (Tactical Toolbox)

干货建议/SOP

第一步：建立你的"虚拟CTO"

  1. 在ChatGPT/Claude中创建一个项目
  2. 赋予系统提示：“你是这个项目的完整技术负责人。我拥有问题，我拥有用户感受的控制权。你是构建方式的完全掌控者。我希望你挑战我的想法，不想你做一个讨好者”
  3. 用这个"CTO"来验证任何技术想法，询问"这个功能在技术上如何实现？"

第二步：创建标准化工作流命令

  1. 在Cursor中创建/commands文件夹
  2. 为开发流程每个阶段创建命令：create issue、exploration phase、create plan、execute、review、peer review、learning opportunity
  3. 每个命令包含详细的提示词模板

第三步：建立多模型审查机制

  1. 同时打开Claude Code和Codex/GPT
  2. 让每个模型独立审查代码
  3. 使用peer review命令让它们互相挑战
  4. 手动验证明显错误后接受修复

第四步：持续迭代优化

  1. 每次AI犯错时，追问"你的系统提示或工具哪里出了问题让你犯这个错误？"
  2. 将修复方案更新到命令提示词或文档中
  3. 这种"复盘"是区分普通AI用户和高级用户的关键

推荐资源/工具

AI编程工具：

  • Cursor（主力开发环境）
  • Claude Code（运行在Cursor中）
  • Codex（用于复杂bug修复）
  • Bolt / Lovable（初级工具）
  • Base44、Replit、v0（同级别 vibe coding 工具）

项目管理与协作：

  • Linear（任务管理）
  • MCP（Anthropic创建的工具，让AI能使用外部工具）

语音输入：

  • Wispr Flow（用于语音输入命令，减少打断开发流程）

面试准备：

  • Ben Erez的框架（PM面试准备）
  • Louis Lynn的题库（实时更新的真实面试题库）
  • Perplexity的Comet（用于分析最常被问到的面试问题）

替代工具发现：

  • Cap（开源Loom替代品）
  • Supercut（另一款Loom替代品）

反直觉洞察与辩论 (Insights & Reflections)

反直觉点

  1. “初级PM的黄金时代”：与"AI会导致初级岗位消失"的担忧相反，Zevi认为现在是初级PM的最佳时机——历史上何时有过刚毕业就能和朋友一起完全独立构建创业公司的机会？

  2. “代码只是文字”：Tal Raviv告诉Zevi的一句话彻底改变了他的心态——“代码只是文字”。这消除了对代码的神秘感和恐惧，将其降维为可以理解和修改的文本。

  3. “AI让输出质量更差"的反面：Zevi认为AI不会让PM技能退化，反而让初级PM能够参与战略决策——他在副业中考虑营销战略和用户体验的决策权，是他作为初级PM在Wix时从未有过的。

  4. “用AI外包思考是错误的"vs"AI是最好的思维伙伴”：传统观点认为使用AI思考是"外包思维”，Zevi认为这是"最糟糕的看待方式"，AI应该是随时可用的导师和思维伙伴。

争议/冲突点

  1. 对" vibe coding"工具的评价：Zevi认为Bolt/Lovable"为你做决定"的特性在某个阶段成为限制，而Cursor的"完全控制"更适合深入开发。但这与"无代码运动"的理念相冲突——无代码工具的核心价值恰恰是降低技术门槛。

  2. “所有头衔将崩塌"的未来观：Zevi预测未来不再有"PM"这个独立角色，每个人都是"建设者”。这与当前行业中PM作为专门职能存在的现实形成冲突，也是很多PM担忧的"PM消亡论"。

  3. “模型命名混乱”：Zevi吐槽AI公司对模型的命名——“我不确定他们最擅长命名模型”（暗指GPT-5.1 Max等复杂命名）。

金句 (Golden Quotes)

  • “你不会被AI取代。你会被那些比你会用AI的人取代。”
  • “现在是成为初级PM的最佳时机。历史上何时有过刚毕业就能和朋友一起完全独立构建创业公司的机会？”
  • “代码只是文字。”
  • “初级PM的期望不是成为10倍能力的PM，而是成为10倍能力的学习者。”
  • “AI不会让你变得更糟。如果你用错了，它才会让你变糟。”
  • “任何好奇的人、勤奋的人、善于沟通的人，都有一种不公平的优势。”
  • “没有人知道他们在做什么。”
  • “你可以做任何事。”

总结

这场对话揭示了AI时代产品开发的核心范式转变：非技术人员不再是被动的"需求方"，而是可以成为主动的"建设者"。Zevi Arnovitz的实践证明了这一点——他用AI构建了产生收入的商业产品，并为Meta的工程师提供培训。

他的方法论核心不是"让AI替我做事"，而是"建立与AI的协作系统"——通过角色定义、流程标准化、多模型审查和持续迭代，他创造了一个即使完全不懂代码也能交付高质量产品的环境。

对于产品经理和所有非技术人员来说，这既是一个激励，也是一个警示：AI不会消除对产品思维的需求，但对产品思维的定义正在扩展——不再只是"知道做什么"，而是"知道如何借助AI做到"。

📺 视频原片

视频ID: 1em64iUFt3U