从资深工程师到产品经理的转型之路
大家好，我叫刘希元，大家通常叫我Zero。我拥有十多年的软件工程师经验，主攻Web方向的IC（Individual Contributor），曾在GREE游戏公司制作社交游戏。这段经历让我对行业的价值观产生思考，认为这不是一个健康的产业，不希望我的孩子未来也沉迷其中。带着这份反思，我加入了Google，开启了Web开发之旅，先是参与YouTube电视端开发，后又转向Web基础架构组，负责团队Web库的开发。
在Google多年后，我逐渐意识到自己对“爬梯子、升职加薪”的兴趣有限，更渴望做自己感兴趣的事情，甚至创业。但当时我认为从Google直接创业存在差距，于是选择在四年前加入初创公司积累经验。我先后在Firework和Lumos两家初创公司担任前端技术领导，负责团队建设和前端基础设施的搭建。随着AI浪潮的兴起，我深感它对工程师领域的影响巨大。同时，我观察到初创公司的瓶颈往往不在技术，更多在产品。为了在公司内产生更大影响力，我在七个月前向老板提出转型为产品经理（Product Manager），认为这能为公司带来更大机遇，也为我未来的创业积累更丰富的经验，尤其是在销售和市场推广方面。顺便一提，我将在一个月后从公司辞职，正式开始自己的创业项目。
我目前有几个创业方向。其一，我与社区伙伴Logan（Obsidian Copilot的创始人）合作了一年多。他的项目潜力巨大，我已经在他做付费服务之前加入，并帮助他优化用户体验。我们正讨论通过收入分成协议（revenue share contract）将其发展成付费服务。辞职后，我将投入更多时间协助他开发新的Agentic功能。
AI工具赋能与长尾生产力实践
我不仅在个人职业发展中拥抱AI，还在公司内部积极推动其应用。我曾为非工程师团队进行Agent培训，利用Claude Code搭建PM工作流，展示如何快速获取客户信息、拉取Slack数据并生成报告。尽管Claude Code看起来复杂，但它的底层逻辑并不难掌握。初期，非工程师对这套系统接受度不高。我们内部也曾讨论，既然Claude Code如此强大，Obsidian Copilot的价值何在？但后来我发现，通过ACP可以将Obsidian与CLI工具连接起来，从而在Obsidian内部直接调用Claude Code的底层功能。我的目标是将其打造成一个更友好的Agent入口，让用户想到使用Agent时，自然想到打开Obsidian。
我认识到Obsidian作为一个小众软件，存在用户学习门槛的问题。但我选择聚焦于Obsidian是因为Logan已经拥有一个庞大的社区，其中不乏付费用户，这避免了从零开始获客的挑战。另一个重要原因是，许多Obsidian用户是“一人公司”或高管，他们搭建的个人知识管理（Personal Knowledge Management）系统展现出更强的付费意愿。我希望能深入了解他们的需求，开发更专用的工具，而非仅提供像19.99美元套餐那样“通用”的产品，以增强用户付费的理由。
在学习AI的旅程中，我一开始和大家一样使用ChatGPT，编程方面则依赖GitHub Copilot。2024年初，当我看到Copilot能自动完成单元测试时，产生了第一个“Aha时刻”，意识到生活将发生巨大改变。后来，公司早期接触Cursor，我转型使用后发现其自动补全功能极大地提升了前端开发效率。
然而，我对Agent的概念最初有些“过度炒作”的感觉。一方面，Agent的定义模糊，许多人认为其工作流不确定，用户需求实则可通过简单工作流解决；另一方面，早期的Agent产品如Devin，我们公司尝试后效果不佳并退订。我当时认为，以SaaS产品的发展速度，Agent要真正可用还需要很长时间。但我对自动补全（autocomplete）的理念深信不疑，认为Copilot是很好的应用场景。
后来，通过课程学习，我开始深入理解Agentic Thinking和范式转变。鸭哥（受访者提到一位老师）的演示给我留下深刻印象：从ChatGPT手动复制粘贴代码到Cursor全自动生成并测试，这展现了GUI与API的巨大差异。API是机器间的接口，Agent降低了使用API的门槛，提供了更高效的交互。这让我这个长期与UI打交道的前端工程师深感共鸣：UI为简化用户操作而生，但API提供了更多复杂功能。当我们可以用Skill、MCP和Agent打开这些入口时，那种“脑洞大开”的感觉，让我对自己的前端职业生涯产生了诸多思考。
除了这两个项目，我还在公司内部主导了一个有影响力的项目：评估和推广新的项目管理工具。公司早期使用Asana，但在团队规模扩大到约100人时，其效率问题凸显，尤其对Squad的支持不足。我们发现许多内部团队的效率问题是由工具不适应造成的，于是开始评估新的工具。我们试用了当时热门的Linear，对其“简单、好用、好看”的设计理念和高度观点化的（opinionated）方式印象深刻，认为它非常符合我们的需求，于是我开始在公司内部大力推广。
然而，在任何公司更换项目管理工具都是浩大的工程。这不仅仅是Linear比Asana好用那么简单，还涉及许多繁琐的流程。最大的障碍是公司在Asana上已建立大量工作流，必须将其复制到新工具，否则团队会因工具原因无法完成原有工作，从而抵制变革。其中一个关键场景是Asana提供的自定义Bug接收表单（custom bug intake form），它能托管一个网站，让用户直接提交Bug，并根据SOP自动归档。Linear早期以简洁为主，没有此功能。与Linear销售沟通后得知，此功能至少需要几个季度才能实现，但我们等不及。在Agentic Coding和Vibe Coding出现之前，这个项目很可能就此搁置。因为我并非专职负责，不可能投入大量时间搭建此功能。
但有了Cursor，我决定“Vibe Code”一个内部工具。Linear提供了优秀的API，可以实现所有需求。我快速编码了一个自定义的接收表单，并在原有基础上增加了新功能——利用大语言模型（Large Language Model: 基于海量文本训练的AI系统）预测器自动分配Bug给相关团队。这个工具的出现，极大地推动了Linear的顺利上线。现在，大家都很高兴地开始使用Linear了。这是一个非常有价值的实践，尽管它不是企业级（enterprise level）工具，只是一个“Vibe Code”的表单，但它节省了大量时间，帮助我成功推广了新工具。
我后来更新了课程内容，更强调Agentic Coding和Vibe Coding，即如何利用自然语言（natural language）调度算力，解锁那些“长尾生产力需求”（chronic pain）——那些日常很痛，但又不是“尖锐的痛”（sharp pain），因此一直被忽视的需求。AI让解决这些长期慢性痛成为可能。我举例我用AI做了“抓头发检测App”就是典型。这些需求太长尾，没有SaaS公司会去做。
当我问及这个工具多大程度上受课程启发时，他表示影响很大。课程具象化了“Builder Mindset”（建设者心态）的概念。之前他只知道一些心理学概念，比如幸福感与输入输出比例相关，但课程将其与“建设者心态”联系起来：你构建得越多，自信和幸福感就会随之增加。他认为，AI帮助他将突发奇想的Idea快速实现。
他还提到，这个AI驱动的App在LinkedIn上获得了他最高的关注度。反响热烈的原因有二：
- 反差感：一个Web工程师在Agent帮助下做出机器学习（Machine Learning）App，给人一种“我上我也行”的感觉。
- 故事性：他特意在截图上保留了Debug框，制造一种高级计算机视觉（Computer Vision）App的假象，这背后有精巧的设计。
AI时代下的子女教育与游戏共创
我非常关心AI对孩子未来的影响。我可以想象，一个现在学习编程的高中生，面对Agentic Coding能“Vibe Code”出所有需求时，是否还会想继续学习编程？如果不再学这个，又该学什么？我深知教育发展速度跟不上AI，学校也无法即时提供所需支持，许多学校甚至禁止使用AI。
我认为，AI之于孩子，就像游戏之于孩子。多数家长不懂游戏，不想让孩子接触，但游戏和AI一样无处不在。与其阻挡信息来源，不如早期引导，用正确的方式玩游戏、用AI。教孩子用AI最好的方式就是和他们一起用，而最佳的亲子活动就是“做游戏”。我小时候也有很强的意愿做游戏，比如在“文曲星”上用Basic语言编写RPG游戏，当看到同学玩得很高兴时，获得了强大的正向反馈。我希望我的孩子也能体验这种“正反馈”。
我的两个儿子，Nathan（9岁）和Evan（6岁），我对他们未来受AI影响深感忧虑。
我与大儿子Nathan合作的第一个游戏是2025年刚上完课后，我用Cursor制作的“陀螺打龙”游戏。我当时有个“私心”，想知道Cursor能做出怎样的游戏，并希望孩子一同参与体验。Nathan的初始想法很“天马行空”，比如“陀螺打龙”，但我没有纠正他，而是让他尝试用AI实现。AI“来者不拒”，反而给了他更少的限制，让他看到自己奇思妙想的成果。
制作过程中，我还是非常亲力亲为。挑战在于孩子很难清晰表达需求，我需要反复引导他描述游戏玩法。此外，我尝试让他使用语音转文本（voice to text）方式输入，但他面对屏幕会“僵住”。我鼓励他“AI什么都懂，不需要讲得完美”，他才慢慢适应。这些经历对孩子未来用AI或做演示都是很好的锻炼，学会不追求完美，敢于表达。
遇到Bug时，我会引导他指出问题，并尝试让AI修复。很多时候，他都能发现问题并让AI解决，形成一个完整的CER循环（Context, Error, Requirement）。AI的快速反馈让孩子保持了极大的兴趣，一旦有想法，一两分钟就能看到结果，这产生了大量多巴胺。对他来说，“做游戏比玩游戏更快乐”。这个项目并未持续很久，因为当时Cursor早期Agent能力有限，难以处理更复杂的项目。
一年后，我接触到Claude Code，并学会了“管线”（pipeline）的概念：先写规格（spec），用计划模式（plan mode）明确需求，再让Agent执行。Agent的执行能力和思考时间都更长。我又一次有了“私心”，想知道AI能把游戏做到什么程度。2025年11月，Claude Code模型已迭代到4.5版本，结合Nano Banana生成艺术资产和Suno生成音乐，游戏所需的一切元素都能通过AI生成。
这一次，我花了更多时间与Nathan深入交流游戏设计。他想制作一款塔防游戏（Tower Defense Game）。我引导他思考如何与现有游戏区分，最终确定了“学校主题”，将同学设计成防御塔，更具个性化。有趣的是，在设计防御塔技能时，他最初会提出一些随机的想法，比如将顽皮的弟弟做成带有“Naughty”技能的塔。我引导他从积极强化（positive reinforcement）角度思考朋友的优点，比如擅长篮球的同学可以设计成射程很远的塔，编程厉害的同学则可成为“疯狂科学家”（mad scientist）。这不仅让游戏设计更丰富，也促使他思考如何与朋友交流，以及如何让大家欣赏和喜欢自己做的东西，这超越了AI本身，回归到教育和人际连接。
当项目变得复杂时，Nathan并未感到沮丧或担忧。因为游戏制作并非等到最后才可玩，第一天就能玩到第一个简陋版本。每次改进，他都感到更酷、更自信。唯一可能影响他兴趣的，是Claude Code思考一个Prompt可能需要十分钟，他会趁机跑出去玩一圈再回来。
构建思维与PM心智的转变
这次项目成功的关键在于“管线”的重要性。我们首先花大量时间制作了游戏设计文档（Game Design Doc），并使用计划模式。我让Nathan担任“游戏设计师”，与Claude Code反复交流，思考塔防游戏的细节，深入理解游戏设计。从第一天起，这份游戏设计文档便作为上下文（context）被引用。例如，增加新防御塔时，AI会根据文档了解已有内容和游戏目标；修改关卡时，AI会以最初设计中的防御塔数值为基准进行调整。整个过程中，我们还不断更新这份文档。后来添加故事情节，也无需从头解释游戏，直接将设计文档扔给Agent，再由Nathan描述故事大概，AI便能根据设计生成漫画。
我反思，如果第一次做游戏时就采用这种方法，项目复杂度可以更高。当时主要缺乏Agentic Coding经验，且“文档先行”（document first）的理念可能尚未更新到课程中。对于开发者来说，保留上下文（context）是个直觉：因为AI不知道什么，所以需要将所有信息整合到Prompt中。
在这次项目中，Nathan的参与度显著提高。我主要负责引入Nano Banana（图像生成）、Suno（音乐生成）和Claude Code（代码编写）等工具的概念，并引导他思考游戏设计。更多的决策仍由他自己做出。当他遇到瓶颈时，我再协助扩展他的思维，使游戏更完善。
关于视觉效果，我们也经历了一个有趣的故事。有一次，我们花了一个小时优化游戏的艺术风格。这对他来说较难，因为他玩过的游戏不多，难以清晰描述。我将其变成一个与AI共同研究的经历，让Agent研究市面上的简单游戏，然后我们一起查看Steam上的Trailer，讨论哪种风格适合我们的游戏。我们排除了3D游戏，也排除了酷炫的霓虹风格，最终选择了蜡笔画风。Nathan甚至发现了像Baba Is You这样优秀的益智游戏，认为其字母跳动的风格非常适合我们的“ABC怪物”。我再花费心思在Prompting上，让Claude Code根据这些例子生成艺术风格规格（art style spec），再将其交给一个Coding Agent重新编写，最终实现了翻天覆地的视觉变化。整个决策和研究过程Nathan都深度参与。
游戏完成后，我让他反思最有趣的一步，他提到了在图书馆花一小时优化艺术风格的经历。他说，这种体验让游戏发生了“翻天覆地的变化”。这种“创造性表达”（creative expression）的喜悦，以及看到想法直接实现的感觉，令他感到非常棒。
我相信Nathan通过这个过程接触并学习了许多AI知识。有一次，他甚至在餐桌上绘声绘色地讲ChatGPT、Cursor和Claude Code的区别，哪个更厉害。他现在对这些工具有了切身的体会，比很多未接触AI的成年人认知更深。他理解AI的交互方式，知道如何产生好的结果，以及何时会“碰壁”，AI如何将模糊需求变成好东西，他有了切实的感知。这是一种“通过构建学习”（learning through building）的过程。
我现在的下一个项目是，暑假邀请他几个好朋友来家里，举办一个为期一周的家庭夏令营，每人制作一两款游戏。周末时，我们将这些游戏打印成QR Code，甚至可以以两美元的价格出售，再卖些柠檬水，让他们体验“创业”的感觉。
我认为Nathan在我的协助下，再做一两款游戏后，就能独立使用Claude Code。我将逐步放手（hands off），让他更多地参与。虽然他已经熟悉界面，但可能基础的电脑操作（如复制粘贴）还需要帮助。我们正在制作第三款游戏，尝试使用表格（spreadsheet）来管理。每次做新变化都会遇到新的技术困难，这方面我仍需协助。这也让我思考，或许搭建一个平台，让这种“构建体验”（building experience）更受控，减少Bug，能让孩子更方便上手。
我对孩子学习AI的期待是，确保他们每次都“正确使用”AI，用于创造性（creative）而非作弊或解答简单数学题。同时，我强制他们仔细审视AI提出的概念或结果，学会预测AI行为，而不仅仅是全盘接受。
我曾纠结于这种教育方式是否过于“捷径”，让孩子失去了练习传统“硬技能”（hard skill）的机会。例如，我的妻子教孩子用Scratch制作π值模拟器，以锻炼编程能力；我有一位校友的儿子花六年时间为父亲的游戏绘制艺术作品，锻炼了艺术技能。这两者与我孩子用AI制作游戏的经历，究竟哪种更有教育意义？
我最终认为，这三者并非相互排斥。AI将是未来的必备技能。Scratch是思维游戏，锻炼大脑；而用AI做游戏则更接近“为生产而构建”。AI工具提升了生产力，让人有更多机会探索。然而，在AI时代如何教育孩子，仍是一个开放问题，充满挑战。比如，我儿子22个月大时，我让他看电脑，虽然能换来安静，但这是一种“容易的决定”，可能带来长远后果。
PM转型：从“做出来”到“卖出去”的心智飞跃
谈及我转型PM的经历，我想主要原因是希望成为创始人（Founder），而PM的工作能提供最接近创始人的经验，持续与客户交流，回答那些“艰难的问题”（hard question）。我目前依然这么认为，并相信它将对我的未来有所帮助。我的CEO也一直支持我，为我提供锻炼机会。
另一个转型原因，是AI极大地削弱了技术壁垒，尤其对前端领域影响深远，这在B2B领域尤为明显。前端的主要挑战在于如何以更简洁的方式，堆叠更多可维护的功能。但Agent的出现解决了许多这类问题，我作为前端专家的影响力在公司内部有所下降。
在AI之前，我的前端专业知识体现在能够以更低的开发成本开发更多功能。我擅长通过引入设计系统（design system）来提升前端部门效率，让团队不再从零开始搭建组件，而是使用标准化的“乐高模块”。Agent则以另一种方式“降维打击”了这一点。首先，维护设计系统变得更容易，很多设计师现在可以直接编写代码，构建新的设计系统组件。其次，团队在构建一次性组件时更加便捷，无需等待，直接让Agent生成，后续再优化。
转型PM最大的痛点，是我之前接触的PM工作更多是后半段：完善需求，与设计师沟通。但我缺乏前端部分的工作经验：如何发展需求，如何与客户交流，探寻他们的真实想法，并将这些想法整合为可实施的产品，并自信地带领团队去执行。我一直认为这是创始人非常需要的经验——拥有信念（conviction）去从零到一地创造。这是我转型过程中最薄弱、也最需要努力的一点。
我认为这个“痛点”更多是一种“心智模式”（mental set）的转变。作为工程师，我擅长将模糊需求具体化并解决问题，目标是“把事情做完”。PM的工作则更靠前一步：我需要深入地用“开放式问题”（open question）与客户交流，而不是急于解决问题。在做PM之前，我总想“承担所有权”（take ownership），自己解决问题。但现在，我需要客户告诉我他们的真实需求，才能设计出更好的功能。
PM需要制定一个6个月到1年的愿景（vision）。而工程师可能更多关注战术计划（tactic plan）：如何在本季度高效率、高质量地完成任务。PM的目标是评估在一个项目上投入6个月到1年的时间和资源，能否带来足够好的回报，推动公司发展。PM的思维更抽象。我以前从未这样思考问题，所以当我需要引导整个团队或公司的产品方向时，会感到无所适从。我习惯性地会去思考“这个东西到底能不能做出来”，一旦在技术上遇到不顺，就不敢继续推进。工程师对技术难度的了解反而会成为一种限制。
主持人提到，他（主持人）作为一个总是有方向、有Idea的人，不理解为什么鸭哥能那么快做事，他（主持人）却能不断给出20个Backlog。他认为这是一种“穿透不确定性的能力”。多数业务都充满不确定性，而PM需要在不确定性中将其转化为确定性，或者在不确定环境中直接做决策。
我最近的体会是，承担风险（take risk）的能力有所增强。例如，我曾发现公司对外部的销售演示文稿（pitching slides）或入职演示文稿（onboarding slides）中包含我从未见过的功能，甚至不在产品路线图（roadmap）上。我曾与CEO深入讨论，认为这过度销售（oversell）会影响路线图。但CEO解释说，作为PM，销售演示文稿不是功能列表，而是需要与客户讨论的“潜在方向”。比如，公司正在探索“非人类身份”（non-human identity），虽然目前没有产品，但需要通过与客户沟通，才能知道他们是否愿意为此付费。市场营销（marketing）永远走在工程师和产品开发（EPD）路线图的前面。以前我对此非常抵触，现在我接受了这是一种正确的策略，心态更加开放，在与人交流时，更能适应不确定性。
我意识到，营销没有的东西是完全可能的。人们常低估大脑的幻觉（hallucination）。A/B测试显示，80%的假设都是错误的，无论计划多么周密，最终结果往往与假设不符。人的大脑不善于想象真实世界，所以唯一能做的就是尽快拿出脑中最好的想法去测试。因为你构建出来的东西100%是错误的，所以只能在构建过程中不断地获取信号。