PM主导软件组织重构
解决什么问题
text-to-app 工具普及后,谁来构建软件、软件组织怎么变、PM/设计师/工程师各自的位置在哪。
核心内容
数据基础:Bolt 用户 67% 不是开发者——是 PM、设计师、创业者。这些人一直擅长构建产品,但过去他们的想法只能"通过开发者的指尖"变成代码;现在可以直接通过 prompting 实现。Eric 的判断:这件事"没有被 price in 到任何公司的估值里,也没有反映在任何软件公司的 org chart 里"。
为什么 PM 是最佳位置: 指挥 AI developer agent 所需的技能 = rockstar PM 的技能——定义清楚 scope、把需求写到"可执行、通信无损"的程度、帮它调试卡点。给 PM 的使用建议:"像写 Linear/JIRA ticket 一样跟它说话,像对团队里的开发者一样"——关键处具体,可发挥处给 vibes("make it prettier"效果很好)。
Org chart 预测(1-5 年):
- 开发者从大部分 UI 类工作上撤下,只留最复杂的部分;
- 设计师和 PM 主导体验构建("写代码"),配 1-2 个工程师 review PR、把关代码——"更多产品设计人员 + 少量工程师"的 pod 结构;
- 工程师转向 LLM 不擅长的智力难题,且自身也被 LLM 增强(前端工程师的杠杆变得极高、人数变少);
- 过渡期新职业:Bolt Builders——按小时付费的人类专家(类似 Apple Genius Bar),在 AI 卡死的犄角旮旯帮非技术用户解卡。
工作流变化:真 prototype 取代静态设计稿。 "一图胜千言,可交互的 live demo 胜百万言"——现在用 Bolt 写出真实可用原型比在 Figma 拖 frame 更快,企业客户最大的采用场景就是高保真原型。PRD 保持极简(只写保证对齐的最小上下文 + 关键 outcome),过重的 PRD 会被开发/设计略读、雪球式失真;有时 PRD 就是"一个 Bolt 链接"。
适用边界
- 拥有工程和设计技能仍是加分项("只会更有优势");大型存量代码库仍需要传统工程师 + Cursor 类工具。
- 教育路径建议:掌握基本技术原理有益,但"为了保证找到工作而学 CS"的前提已失效——six-figure 学费需要真实热情来 justify。
关键引述 · 原话
"67% of our users are not developers, at this point." — Eric Simons
"PMs, they're going to be 'writing code', quote, unquote, instead of just writing a JIRA ticket and waiting for a developer to do it." — Eric Simons
关联卡片
- 同源卡片:model-threshold-unlocks(能力阈值是前提) - 同方向卡片:bricklayer-to-architect--scott-wu、two-week-rule-engineer-as-pm--amol-avasare(工程侧视角的同一变化)
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast(2019–2026)。本站为个人学习用途的二次创作,与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2