硅谷顶级PM的方法论免费开源!附Skill和32m资源包下载 ✍ 向阳乔木🕐 2026-03-22📦 24.2 KB 🟢 已读 𝕏 文章列表 文章分享了Lenny(Airbnb前增长负责人)开源的产品管理资源包(32M文件及配套Skill)。作者结合自身使用演示,详细解读了其中关于客户痴迷(JTBD理论、PMF测试)、战略优先级(逆向工作法、战略金字塔)、执行匠心(MLP替代MVP、原型替代PRD)以及增长指标(留存率、赛车框架)的核心方法论,旨在帮助产品经理建立清晰、靠谱的工作习惯。 产品管理LennyPMF逆向工作法JTBD职场效率Skill开源资源增长黑客执行力 # 硅谷顶级PM的方法论免费开源!附Skill和32m资源包下载 **作者**: 向阳乔木 **日期**: 2026-03-22T02:30:19.000Z **来源**: [https://x.com/vista8/status/2035544573876023605](https://x.com/vista8/status/2035544573876023605) ---  Lenny 曾是 Airbnb 增长团队的产品负责人,离开后创办了硅谷最受欢迎的产品管理类内容品牌。他的内容之所以好,是因为他不讲"正确的废话"。 而且他去年提供了最全的AI工具产品大礼包,相当超值。 前段时间他开源了他的所有Newsletter和几年的Podcast访谈文本,总共32M,640个文件。 https://xiangyangqiaomu.feishu.cn/wiki/S97awc7EeiyjNdkJsM4czn71nxb  包含了两个格式的文件和我写的Skill,方便Notebooklm和Claude Code中使用。 下面是我的使用演示案例,比如我提问:“产品经理如何做好产品?”,获取答案后扩写成一篇文章。 我仔细读了,都是产品经理领域,很有共性的问题和方法论,分享给大家。 ## 一、痴迷于客户与问题 > 大多数产品失败,不是因为解决方案不够好,而是因为从一开始就在解决一个不存在的问题。 1.1 爱上问题,不是方案 Waze 创始人反复讲一句话: Fall in love with the problem, not the solution。 这句话之所以值得反复讲,是因为几乎所有创始人和PM都在犯相反的错误 > 他们爱上了自己写的代码、画的原型、想出的那个"绝妙点子"。 真正的产品高手,是问题领域的专家。 他们能用三句话讲清楚:这个问题影响谁、有多痛、现在的替代方案为什么不够好。 如果你做不到这一点,你还没有资格开始画原型。 一个检验方法: 你能不能做一场关于这个问题的30分钟演讲? 如果不能,你对问题的理解还不够深。 1.2 "40%极度失望"测试 Sean Ellis 提出的这个测试极其简洁: 问你的用户一个问题 "如果明天不能再用这个产品,你会有多失望?" 给三个选项:非常失望、有点失望、不失望。 如果选"非常失望"的比例超过40%,你才找到了PMF(Product-Market Fit)。 低于40%,你还需要继续摸索。 这个测试的精妙之处在于它测量的不是满意度,而是 依赖度 。 用户说"挺好的"没有意义,用户说"没了它我不行"才有意义。 Superhuman 的 CEO Rahul Vohra 把这个测试变成了一套完整的操作方法。 他不仅用它来判断PMF,还用它来指导迭代方向: 去看那些选了"非常失望"的用户,他们为什么离不开你?然后把这个价值放大。 再去看那些选了"有点失望"的用户,他们差什么才能变成"非常失望"?然后补上那块短板。 1.3 找到25个基准客户 这个概念对所有产品都适用。 你的前25个客户,不应该只是"在用你的产品",而应该是愿意站出来说"我用了这个产品,它改变了我的工作方式"的人。 为什么是25个? 因为这个数字足够大,能证明你的价值不是偶然。 这个数字又足够小,让你可以逐一深入了解每一个客户的使用场景。 这25个客户是你的产品信仰的根基。 当你在董事会上被质疑、当竞争对手发布了一个看起来更酷的功能、当团队士气低落的时候,你可以回到这25个人身边,重新确认你在做的事情是真实的、有价值的。 更实际地说: 如果你连25个这样的客户都找不到,你的产品大概率还没有真正的PMF。 1.4 JTBD框架 克莱顿·克里斯滕森的 Jobs To Be Done 理论,是我见过的最被低估的产品思维框架。 它的核心洞察是: 用户不是在"购买产品",而是在"雇佣产品"来完成生活中的某个任务。 经典案例:人们买电钻,不是因为想要一把电钻,而是因为想要墙上有个洞。 更深一层:他们想要墙上有个洞,可能是因为想挂一幅全家福。 再深一层:他们想挂全家福,是因为想让家里有温馨的感觉。 你在哪一层理解用户的任务,决定了你能做出什么级别的产品。 麦当劳奶昔的故事是JTBD最经典的案例: 早晨买奶昔的人,不是在"买饮料",而是在"雇佣"一个能让无聊通勤变得不那么难熬、同时单手可持、不会弄脏车、能撑到午饭的东西。 当你理解了这个需求,你的竞争对手就不是其他奶茶店,而是香蕉、面包和无聊本身。 ## 二、战略与优先级 > 没有战略的执行是盲目的勤奋。 1.2 产品战略金字塔 > Mission → Vision → Strategy → Goals → Roadmap → Task 这个金字塔从上到下是:  大多数团队的问题是:他们从Mission(使命)直接跳到了Roadmap(路线图)。 中间的Strategy(策略)那一层是空的。 这导致Roadmap变成了一堆互不关联的功能列表,看起来很忙,实际上没有方向。 Strategy是什么? Strategy是一组有意识的选择: > 我们选择服务谁、不服务谁;我们选择在哪里竞争、不在哪里竞争;我们选择什么能力是我们的核心壁垒。 理查德·鲁梅尔特在《Good Strategy Bad Strategy》中说得好: > 好战略的核心是一个连贯的行动逻辑,包括诊断、指导方针和连贯的行动。 如果你的团队里每个人对"我们的战略是什么"给出不同的答案,你就没有战略。 2.2 逆向工作法 (PR/FAQ) 这是亚马逊内部最著名的工作方法之一。 在写一行代码之前,先写一篇假想的产品发布新闻稿和一份常见问题文档(FAQ)。 新闻稿的格式很简单: - 标题(用客户能理解的语言) - 副标题(一句话说清楚这个产品对客户的价值) - 第一段(总结问题和解决方案) - 客户引言(一个虚构但真实的客户会怎么评价这个产品) - 产品如何工作 - 创始人/负责人引言 - 行动号召 这个方法的天才之处在于:它强迫你从终点开始思考。 如果你写不出一篇让人兴奋的新闻稿,说明这个产品本身就不够让人兴奋。 如果你写不清楚客户引言,说明你不理解客户的真实感受。 FAQ分为两类: 客户会问的问题(这说明你在思考用户体验)和内部利益相关者会问的问题(这说明你在思考可行性和风险)。 我见过太多团队花三个月写PRD,最后做出来的东西没人要。 先写新闻稿,可以在一天之内暴露80%的问题。 2.3 对大量需求说"不" 产品管理的本质不是决定做什么,而是决定 不做什么 。 巴菲特有一个著名的"25-5法则"(虽然他本人可能没说过,但道理是对的): > 列出你最想做的25件事,圈出最重要的5件,剩下的20件是你的"绝对不做"清单。 因为正是那些"还不错但不是最重要"的事情,会偷走你做最重要的事情的时间和精力。 对产品团队来说,最危险的需求不是明显不靠谱的需求,而是"听起来挺有道理"的需求。 它们会悄悄塞满你的Roadmap,让你觉得自己在进步,实际上你在原地打转。 说"不"需要勇气,也需要依据。 依据从哪里来?从战略金字塔的上层来。 每一个需求,都应该能追溯到一个明确的战略选择。 如果追溯不上去,不管它听起来多合理,都应该说"不"。 2.4 做减法 这是我最喜欢的一条原则,来自多个顶尖产品人的共同智慧。 当你不知道该怎么办的时候,试试砍掉一半。 功能太多?砍一半。 设置选项太多?砍一半。 试图同时服务三个市场?选一个。 37signals(Basecamp的母公司)的Jason Fried说过: 如果一个功能不是绝对必要的,它就是有害的。 因为每一个功能都有维护成本、认知负担、和机会成本。 苹果的设计哲学也是如此。 乔布斯回归苹果后做的第一件事,就是把产品线从几十个砍到四个(一个2×2矩阵:普通消费者/专业用户 × 台式/便携)。 这个减法拯救了苹果。 做减法不是懒惰,是纪律。 它要求你对什么是真正重要的有极其清晰的判断。 ## 三、执行与匠心 > 战略再好,执行不到位也是零。但执行不是蛮干,是带着品味和纪律的行动。 3.1 从MVP到MLP MVP(最小可行产品)这个概念被严重滥用了。 太多团队把MVP当成了"做一个烂东西先扔出去看看"的借口。 MLP(最小可爱产品)是一个更好的标准。 意思是:你发布的第一个版本,功能可以少,但它所包含的功能必须让人感到愉悦。 Spotify的第一个版本功能很少,但它做到了一件事: 你点一首歌,几乎瞬间开始播放。 在那个年代,这种体验是令人惊叹的。 这就是MLP:不是什么都做,但做到的那一件事,让人"哇"出声来。 区别在于品味。 MVP问的是"这个能用吗?",MLP问的是 "这个会让人想告诉朋友吗?" 3.2 速度与质量不矛盾 这是一个被广泛误解的话题。 很多人认为"快"和"好"是矛盾的,你只能选一个。 事实恰恰相反:最好的团队同时也是最快的团队。 他们快,不是因为跳过了测试、忽略了边界情况、或者写了一堆技术债。 他们快,是因为: - 他们做的决策更少但更准确 — 因为他们对问题的理解更深,不需要反复试错 - 他们的沟通成本更低 — 因为团队默契好,不需要无休止的对齐会议 - 他们砍掉了不必要的流程 — 不是没有流程,而是每一个流程都有明确的存在理由 - 他们的技术能力更强 — 写出好代码本身就比写烂代码然后修bug更快 Shopify的CEO Tobi Lütke说过一句话: "速度不是一个策略,速度是一种文化。" 当整个团队都相信速度的价值,并且有能力支撑这种速度时,快就是自然的结果。 如果你的团队在"快"和"好"之间挣扎,问题不在于取舍,而在于团队能力。 3.3 用原型替代长篇PRD 传统的产品需求文档(PRD)正在变得越来越过时。 一份20页的PRD,写的人痛苦,读的人更痛苦,而且几乎没有人会完整地读完它。 一个可交互的原型 胜过一千页文档。 原型的价值在于它消除了歧义。 当所有人都在看同一个可以点击的东西时,"我以为你说的是那个意思"这种对话就消失了。 在AI时代,这一点变得更加明显。 用Figma、Framer、甚至直接用Cursor、Claude Code或Replit、v0、lovable,你可以在几个小时内做出一个高保真原型。 过去需要一个前端工程师花一周才能搭出来的交互Demo。 现在一个产品经理自己就能完成。 PM的核心能力正在发生位移:从"写清楚需求"到"直接把想法变成可体验的东西"。 你不再需要用文字描述一个按钮点击后会发生什么,你直接做一个按钮,让所有人自己点。 当然,原型不能替代所有文档。 技术方案、数据模型、边界条件的定义,这些仍然需要文字。 但产品的"是什么"和"为什么"这两个问题,原型比文档回答得更好、更快、更准确。 一个建议:下次开需求评审会的时候,直接打开一个原型。你会发现会议时间缩短一半,产出质量提高一倍。 ## 四、增长与指标 > 增长不是玄学,是工程学,但前提是你测量的东西是对的。 4.1 留存为王 如果你只能看一个指标,看留存率。 新增用户是水龙头,留存率是水桶底部的洞。 如果桶底有个大洞,你把水龙头开得再大也没用。 反过来,如果桶是密封的,哪怕水龙头只有涓涓细流,桶也终将满溢。 具体的基准线:  NDR(Net Dollar Retention)超过100%意味着什么? 意味着即使你一个新客户都不签,你的收入仍然在增长。 因为现有客户在扩大使用量、升级套餐。 这是SaaS商业模式中最美妙的事情。 Lenny反复强调一个观点: 大多数增长问题,本质上都是留存问题。 你觉得增长停滞了?先看留存曲线。 如果留存曲线在某个时间点后趋于平坦(哪怕是在一个较低的水平),说明你有一群核心用户,你的产品有价值,你的问题是如何扩大这群人。 如果留存曲线一路向下趋近于零,你没有增长问题——你有产品问题。 回到第一章,重新审视你对客户和问题的理解。 4.2 赛车增长框架 这是Lenny提出的一个非常直觉化的增长思维模型,把增长比作一辆赛车: 引擎(Engine)— 你的核心增长循环 每个成功的产品都有一个或几个核心增长引擎。常见的引擎类型: - 口碑/裂变循环 — 用户用了觉得好,推荐给朋友(WhatsApp、Notion) - SEO/内容循环 — 用户创造内容,内容被搜索引擎收录,带来新用户(Pinterest、Quora) - 付费获客循环 — 花钱买用户,用户付费,利润再投入买更多用户(大多数电商) - 销售驱动循环 — 销售签单,客户成功续约扩展(企业级SaaS) 你不需要所有引擎都有,但你至少需要一个转得起来的。 很多早期产品的问题是:它们有一堆"半成品"引擎,没有一个真正转起来。 润滑剂(Lubricant)— 转化率优化 引擎在转,但转得顺不顺滑? 每一个环节的转化率就是润滑剂。 注册流程的转化率、激活率、付费转化率、邀请转化率……每一个百分点的提升,都是在给引擎加润滑剂。 润滑剂的特点是: 单独看每一个优化都不性感,但它们的效果是乘法关系。 注册转化率提升10%、激活率提升10%、付费转化率提升10%,最终效果不是30%的提升,而是 33.1%的提升。 燃料(Fuel)— 获客投入 引擎和润滑剂就绪后,你需要燃料来驱动增长。 燃料可以是资金(广告预算)、内容(博客、视频)、BD资源(合作伙伴关系)等。 燃料的关键原则:在引擎没调好之前,不要猛加燃料。 这就像往一台漏油的发动机里猛灌汽油——钱烧了,车没动。 太多创业公司在产品留存还没稳定的时候就开始大规模投放,结果是CAC(获客成本)飙升,LTV(用户终身价值)跟不上,现金流迅速恶化。 涡轮(Turbo)— 非线性加速器 涡轮是那些能带来阶跃式增长的东西: > 一次病毒式传播事件、一个关键的平台合作、一个改变游戏规则的功能发布、或者一次成功的品牌营销战役。 涡轮不可预测,也不可依赖。 但你可以创造让涡轮更容易发生的条件。 比如:让你的产品天然具有可分享性(Spotify Wrapped)、让你的品牌有话题性、在关键时刻准备好承接流量。 4.3 北极星指标 + 护栏指标 北极星指标(North Star Metric)是一个团队最核心的衡量标准,它应该同时满足三个条件: 反映用户获得的核心价值 — 不是虚荣指标 与商业成功正相关 — 它涨,收入最终也会涨 可被团队行动影响 — 不是一个纯外部因素决定的数字  但北极星指标有一个危险: 它可能被短期手段"刷"上去。 比如,如果你的北极星是DAU,你可以通过疯狂发推送通知来短期拉高DAU,但这会伤害用户体验,长期来看DAU反而会下降。 这就是护栏指标(Guardrail Metrics)存在的意义。 护栏指标是你在追求北极星的过程中,不允许恶化的指标。比如: - 北极星是DAU → 护栏是推送通知的退订率 - 北极星是交易额 → 护栏是退款率和客诉率 - 北极星是内容发布量 → 护栏是内容质量评分 北极星告诉你往哪里跑,护栏告诉你哪里是悬崖。 两者缺一不可。 ## 五、顶尖PM的习惯 > 方法论是公开的,工具是共享的,最终拉开差距的,是人的习惯和心性。 5.1 将模糊转化为清晰 这是我观察到的顶尖PM最核心的能力,没有之一。 产品经理的工作环境天然是模糊的。 市场在变、用户需求在变、技术能力在变、老板的想法在变、竞争对手在变。 在这种混沌中,PM的价值就是把模糊变成清晰、把发散变成收敛、把"我们好像应该做点什么"变成"我们要在这个时间点、为这群人、解决这个问题、用这种方式、衡量这些指标"。 具体怎么做? - 命名 — 给模糊的感觉一个精确的名字。当团队说"用户体验不太好"的时候,你要能说"具体来说,是新用户在注册后第三步的流失率从15%上升到了28%,主要原因是……" - 框架化 — 把散乱的信息放进一个结构里。用2×2矩阵、用优先级排序、用决策树,什么都行,关键是让所有人看到同一个结构 - 写下来 — 口头讨论容易跑偏,写下来的东西才是真正的共识。一页纸的决策文档,胜过三小时的会议 模糊是PM的原材料,清晰是PM的产品。 5.2 永远比别人准备得更充分 Shreyas Doshi(前Stripe、Twitter PM负责人)提出了一个概念叫 "LNO框架" 。 把你的任务分为Leverage(高杠杆)、Neutral(中性)和Overhead(开销)三类。 高杠杆的任务要做到120分,中性的任务做到80分就够了,开销类的任务能自动化就自动化。 但在所有任务之上,有一种更底层的东西: 可靠性。 当老板把一个模糊的、困难的、跨部门的项目交给你,他心里想的是什么? 他想的是"交给这个人,我就不用操心了"。 这种信任,是PM最宝贵的资产。 怎么建立这种信任? - 永远比别人准备得更充分 — 开会之前,把所有人可能问的问题都想过一遍,准备好答案 - 永远比承诺的早一点交付 — 说周五交,周四就交。这个习惯看起来简单,但能坚持做到的人极少 - 主动同步进展 — 不要等别人来问"那个事情怎么样了",在别人问之前就主动更新 - 出了问题第一时间说 — 坏消息不会因为你藏着就变成好消息。越早暴露风险,越早解决 靠谱不是天赋,是习惯。而习惯是可以训练的。 5.3 非职权影响力 PM是一个很奇怪的角色: 你对结果负责,但你没有任何人的直接管理权。 工程师不向你汇报,设计师不向你汇报,数据分析师不向你汇报。 你不能命令任何人做任何事。 那你怎么让事情发生?靠 非职权影响力。 非职权影响力的来源有三个: 1. 数据洞察 — 当你能拿出别人没看到的数据、揭示一个反直觉的洞察时,你自然会赢得话语权。"我分析了过去三个月的数据,发现我们60%的付费转化来自一个我们从来没有重视过的渠道",这种话一说出来,所有人都会听你的。 2. 用户理解 — 当你是团队里最了解用户的人时,你的判断自然会被信任。这需要你真的花时间和用户在一起。不是看报告,是亲自做用户访谈、亲自看用户录屏、亲自回复客服工单。 最好的PM,每周至少和两个真实用户对话。 3. 逻辑与表达 — 你能把复杂的问题讲清楚,能把不同的观点整合成一个连贯的叙事,能在白板上画出一个让所有人恍然大悟的框架。这是一种可以练习的技能。 权力让人服从,影响力让人追随。PM需要的是后者。 5.4 铁三角(PM + EM + DM)领导团队 产品经理(PM)、工程经理(EM/Engineering Manager)、设计负责人(DM/Design Manager)——这三个角色构成了产品团队的领导核心,即"铁三角"。 铁三角的核心原则是: 对外一个声音,对内充分辩论。 在铁三角内部,三个人应该激烈地讨论、挑战彼此的假设、从不同角度审视每一个决策。 PM带来用户和商业视角,EM带来技术可行性和工程效率视角,DM带来用户体验和设计品质视角。 这三个视角的碰撞,是好决策的来源。 但一旦走出会议室,三个人必须是一个声音。 不能出现PM跟工程师说"这个功能很重要我们必须做",而EM私下跟工程师说"这个需求不合理但我们先应付一下"的情况。 这种不一致会迅速瓦解团队的信任和执行力。 铁三角健康运作的几个信号: - 三个人能互相替对方开会 — 如果PM不在,EM能准确传达产品决策的背景和逻辑;如果EM不在,PM能解释技术方案的取舍 - 分歧在小房间里解决 — 团队永远看不到铁三角之间的争吵,只看到统一的决定 - 没有"这是PM的锅"或"这是工程的锅" — 铁三角共同为结果负责,不存在甩锅的空间 - 三个人定期1:1 — 不只是开项目会,而是定期坐下来聊"我们的合作方式有什么可以改进的" 一个不健康的铁三角,比没有铁三角更糟糕。 如果三个人互相不信任、各怀心思、表面和气背后拆台,团队会陷入政治内耗,执行效率断崖式下降。 怎么建立健康的铁三角关系? 第一,建立私人信任。 不要只聊工作。了解对方的职业目标、工作风格、压力来源。当你理解EM为什么对技术债这么焦虑、DM为什么对某个交互细节这么执着时,你们的合作会顺畅十倍。 第二,明确决策权。 不是所有事情都需要三个人共同决策。提前约定好:哪些决策PM说了算、哪些EM说了算、哪些DM说了算、哪些必须三人共识。模糊的决策权是冲突的温床。 第三,共同面对用户。 不要让PM成为唯一接触用户的人。让EM一起听用户访谈,让DM一起做可用性测试。当三个人都亲耳听到用户说"这个功能救了我的命"或者"这个体验让我想砸电脑"时,你们会自然地对齐优先级。 ## 写在最后 回头看这五个模块,它们其实构成了一个完整的闭环: 理解问题->制定战略->精益执行->衡量增长->持续精进 - 理解问题 告诉你"做什么"。 - 制定战略 告诉你"为什么做这个而不做那个"。 - 精益执行 告诉你"怎么做到位"。 - 衡量增长 告诉你"做得怎么样"。 - 持续精进 告诉你"怎么做得更好"。 但我想特别强调一点: 这些方法论本身不会让你成为一个好的产品经理。 知道"留存为王"和真的把留存做起来之间,隔着一万个具体的、琐碎的、没有标准答案的决策。 知道"爱上问题"和真的花三个月泡在用户现场之间,隔着巨大的执行鸿沟。 Lenny 的内容之所以持续有价值,不因为他发明了什么新理论,而是因为他不断地用真实案例、真实数据、真实的人的故事,把这些道理从"知道"推向"做到"。 最后分享一个判断标准: 一个好的产品经理,应该同时具备望远镜和显微镜。 望远镜让你看到三年后的方向,不被眼前的噪音干扰; 显微镜让你看到一个按钮的圆角半径是4px还是8px的区别,并且在乎这个区别。 只有望远镜,你是一个空想家。只有显微镜,你是一个执行者。 两者兼备,你才是一个真正的产品人。 共勉。 > 本文方法论主要提炼自 Lenny's Newsletter & Podcast,涉及的嘉宾和思想来源包括但不限于:Shreyas Doshi、Rahul Vohra(Superhuman)、Uri Levine(Waze)、Gibson Biddle(前Netflix VP Product)、Reforge、Casey Winters、Elena Verna、Marty Cagan 等。建议直接订阅 Lenny's Newsletter 获取原始内容,每一期都值得细读。 ## 相关链接 - [向阳乔木](https://x.com/vista8) - [@vista8](https://x.com/vista8) - [14K](https://x.com/vista8/status/2035544573876023605/analytics) - [https://xiangyangqiaomu.feishu.cn/wiki/S97awc7EeiyjNdkJsM4czn71nxb](https://xiangyangqiaomu.feishu.cn/wiki/S97awc7EeiyjNdkJsM4czn71nxb) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [10:30 AM · Mar 22, 2026](https://x.com/vista8/status/2035544573876023605) - [14.8K Views](https://x.com/vista8/status/2035544573876023605/analytics) - [View quotes](https://x.com/vista8/status/2035544573876023605/quotes) --- *导出时间: 2026/3/22 22:51:06*
硅 硅谷顶级PM方法论:Lenny核心思想与实战指南 本文解析了前Airbnb增长PM Lenny的产品管理方法论,涵盖从PMF验证、战略制定、匠心执行到数据驱动增长的完整闭环。核心观点包括“爱问题而非方案”、逆向工作法(PR/FAQ)、从MVP进化到MLP以及留存为王的增长模型。文章还总结了顶尖PM将模糊转化为清晰、建立非职权影响力等关键习惯。 职场 › 职业发展 ✍ 向阳乔木🕐 2026-03-23 Lenny产品管理PMF增长黑客战略职场技能方法论Airbnb职业发展执行力
J JTBD市场画布:快速定位产品 本文介绍了基于“待办任务”的市场画布方法,帮助产品经理利用现有研究重新定义市场。通过识别执行者、核心功能及竞品,避免被传统类别束缚,确保产品定位与客户实际需求一致。该方法也可应用于单一功能,并强调了在AI PM OS中的实际应用。 职场 › 管理 ✍ George from prodmgmt.world🕐 2026-07-24 JTBD产品定位市场分析产品管理AI PM OS
每 每位创始人意外学到的 13 条法则 本文是针对早期初创公司创始人的实战指南,核心围绕“构建、发布、增长”三个阶段展开。文章批判了常见的模糊目标与虚假忙碌,提出了“为学习而构建”、“最小化测试”、“持续发布”等 13 条具体原则。重点强调内容创作能增加运气表面积,以及在 PMF 之前留存比流量增长更重要,旨在帮助创始人建立清晰的反馈闭环,避免在伪进步中浪费资金与时间。 职场 › 管理 ✍ Founders Inc🕐 2026-04-22 创业方法论初创公司增长黑客产品管理商业思维个人成长内容营销
B BestBlogs 早报|实现周期骤缩后,创业者如何重选问题 本期早报探讨了 AI 智能体缩短实现周期后,创业者的机遇与挑战。文章涵盖 Sam Altman 对创业窗口的判断、GPT-5.6 的效率工程实践,以及如何通过 Skill Harness 将模型能力封装为可维护的产品功能。 技术 › Skill ✍ ginobefun🕐 2026-07-30 GPT-5.6Agent创业效率工程ProductHarnessSkillLLMOpenAI
装 装完 Codex 不知道干什么?这 6 个 GitHub Skills 让你做视频搞钱 文章介绍了 6 个适用于 Codex 的 GitHub Skills,涵盖动效生成、视频剪辑、批量制作、AI 生成及中文剪辑等工具,帮助用户构建自动化视频工作流以提升效率。 技术 › Codex ✍ Kay🕐 2026-07-30 Codex视频制作AgentSkill自动化HyperFramesRemotionAI剪辑工作流
大 大部分人用 skill还停留在下载别人写好的 文章指出当前大部分人对 Skill 的使用仅停留在下载现成工具层面,而更先进的项目已开始将方法论、思维方式及商业经验转化为可运行、可复用的 Skill。文中列举了女娲、dbskill、ljg-skills 等典型案例,并分析了中英文社区在 Skill 生态上的不同侧重,强调“造 Skill 的 Skill”才是生产力杠杆。 技术 › Skill ✍ Jason Zhu🕐 2026-07-29 SkillAgent方法论生产力开源女娲dbskill生态中文社区
C Codex 10大中文创作者必装Skills 文章介绍了Codex平台上10款专为中文创作者设计的必装Skills,涵盖内容写作、去AI味、多平台发布、配图生成等功能。推荐优先安装Humanizer-zh、dbskill等工具,以优化文字质量并提升创作效率。 技术 › Skill ✍ 启航🕐 2026-07-29 CodexSkill内容创作AI工具效率提升去AI味小红书公众号X平台
W Why LinkedIn is the Biggest Opportunity in B2B History 文章指出LinkedIn目前拥有13亿用户和6500万决策者,是B2B领域仅存的高效低成本获客渠道。与其他渠道相比,Google Ads点击成本高昂,Meta受iOS隐私政策影响,冷邮件回复率极低,而LinkedIn算法仍扶持个人内容,且用户处于购买心智。作者将其比作2004-2008年的SEO红利期,强调建立系统性内容运营而非依赖AI生成或单次投放,是实现复利增长的关键。 职场 › 职业发展 ✍ Paolo Trivellato🕐 2026-07-29 LinkedInB2B营销获客内容策略SEO社交媒体增长黑客职场创业
我 我把 TikTok 运营塞进了 Codex:选品、拆账号、找达人,一句话跑完整个流程 作者将 TikTok 运营工作流封装成 Codex Agent Skill,结合达人精灵 MCP 数据,实现选品、账号诊断、类目研究和增长规划的自动化。文章详细介绍了四个核心技能的安装、配置及具体 Prompt 使用方法,解决了 AI 运营中的幻觉与流程混乱问题。 技术 › Agent ✍ Aron厚玉🕐 2026-07-28 TikTok运营CodexSkillMCP自动化选品达人营销Agent技能工作流数据分析
一 一个暑假,我侄子用两个 Skill 搞明白了 Agent 最难的部分 作者讲述侄子利用暑假开发两个健康类 Agent Skill 的经历。从“养生谣言粉碎机”到“体检行动助手”,解决了大模型幻觉、信息检索权威性及流程设计等难点。文章重点介绍了如何利用豆包搜索 API 的结构化数据与权威过滤功能来增强 Agent 能力,并分享了 Skill 开发优于独立 Agent 的实践经验和建议。 技术 › Agent ✍ 宝玉🕐 2026-07-28 AgentSkill豆包搜索AI开发大模型实战经验信息检索健康类目工作流开源
利 利用麦肯锡问题树解决复杂问题 文章介绍了麦肯锡问题树方法,通过Why(找原因)、What(拆解工作)和How(列路径)三种结构化思维模型来解决产品与业务难题。该方法遵循MECE原则,利用AI辅助检查重复和遗漏,帮助团队理清思路,并提升决策质量。 职场 › 方法论 ✍ George from prodmgmt.world🕐 2026-07-27 问题树麦肯锡方法论思维模型MECE产品管理问题解决AI
我 我是如何用 Codex 做自己的个人IP生图工作流的 作者分享了如何利用 Codex 构建个人 IP 生图工作流的经验。通过借鉴优秀项目,将思路从拼图改为拼提示词,开发了封面图和段落图两个 Skill。文章详细介绍了风格确定、人物特征锚定、内容总结及安全区适配等优化过程,强调了 AI、代码与人在工作流中的职责分工。 技术 › Codex ✍ naiyue777🕐 2026-07-26 CodexAI绘图个人IP工作流Skill自动化设计开源项目