--- author: 课代表立正 date: '2026-05-28' guest: '' layout: post.njk source: https://www.youtube.com/watch?v=HTxtDxEo3kQ speaker: 课代表立正 tags: - career-transition - ai-education - agentic-coding - product-management - game-development title: AI时代下的职业转型与子女教育：一位技术专家的深度思考 summary: 前谷歌工程师刘希元（Zero）分享了他在AI浪潮下从前端技术领导转型为产品经理的职业路径，以及如何利用AI工具与儿子共同创作游戏，实践前沿AI教育。访谈深入探讨了AI对个人职业发展、生产力提升及下一代教育模式的深远影响，并反思了PM转型中的挑战与机遇。 insight: '' draft: true series: '' category: ai-application area: tech-engineering project: [] people: - 刘希元 - Logan - Dr. K - Nathan - Evan companies_orgs: - GREE - Google - Firework - Lumos - Anthropic - OpenAI - 腾讯 products_models: - YouTube - Obsidian Copilot - ChatGPT - GitHub Copilot - Cursor - Claude Code - Linear - Asana - Nano Banana - Suno - Steam - Baba Is You - Scratch - Devin media_books: [] status: evergreen --- ### 从资深工程师到产品经理的转型之路 大家好，我叫**刘希元**，大家通常叫我**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**上获得了他最高的关注度。反响热烈的原因有二： 1. **反差感**：一个Web工程师在**Agent**帮助下做出**机器学习**（Machine Learning）App，给人一种“我上我也行”的感觉。 2. **故事性**：他特意在截图上保留了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%是错误的，所以只能在构建过程中不断地获取信号。