P1
用户思维
风
闪光少女斯斯的私董会 · 内训 · 沐风
产品，工程，组织
用硅谷思维
打造 AI 系统
从比比的系统讲起 · 六个坑 · 九条主张
AI 让「做出来」变便宜了，但它没有让这三件事变便宜：判断该做什么、把东西真正做到能交给别人用、让一整个组织一起用起来。
全场九条
Product
P2
MVP
P3
衡量标准
Engineering
E1
快速迭代
E2
交付鸿沟
E3
管理 AI
Organization
O1
系统性思维
O2
流程
O3
激励
这九条没有一条是因为不够聪明，也没有一条是因为不够努力。它们都是结构性的。
讲者
我是沐风
Amazon
西雅图
Apple
加州
Amplitude
现在 · 工程经理，领导 GTM 的 AI 转型
前十年我主要在写代码和做产品，今年开始整天泡在销售和客户那一边。
所以产品、工程、组织这三件事，我都在里面待过。
“
在座各位，觉得自己的 AI 水平
比比比高的，举个手？
比比比高的，举个手？
先说清楚：这不是挑毛病
比比的神笔写作系统，整体理念非常棒，系统本身也已经相当完整。但我们一起看下来，还是踩到了不少坑——而这些坑，恰好就是今天要讲的九件事。
- 整体理念非常好，系统已经相当完整
- 我们是一起诊断，不是我给他挑毛病
- 连做得最好的人也会撞上这些
所以这些坑是结构性的，不是能力问题。
你不知道有这个坑，就一定会掉进去。今天就是把它们摊开讲一遍。
一起诊断出来的六个坑
| 当时的情况 | 对应今天 | 为什么 | |
|---|---|---|---|
| 1 | 核心问题还没验证，一上来就 build 了一个很大的系统，接着又开始上各种 feature | P1+P2 | 建造变便宜了，就跳过了「先测最要命的假设」，也没把「问题」和「解决方案」分开验证 |
| 2 | 项目越做越大，屎山越堆越高，进度反而越来越慢 | E2 | Demo 到能交付之间那条鸿沟 |
| 3 | 没有备份、没及时同步 GitHub，一次被 Codex 删库 | E3 | 权限和兜底。这一条会讲得最实 |
| 4 | 没有足够细颗粒度的自动化测试，变成 AI 自己给自己打分 | P3+E1 | 没有 measurement，AI 就没法自己迭代 |
| 5 | 所有素材堆到一块让 AI 去读，吃掉大量上下文 | E3 | 哪些该写死、哪些交给 AI，上下文怎么管 |
| 6 | 老板和工程师的主要职责没分清，各自没做最擅长的事 | O1+O2 | 瓶颈找错了，流程也没跟着变 |
这六个坑，没有一个是因为不够聪明，
也没有一个是因为不够努力。
也没有一个是因为不够努力。
它们都是结构性的——你不知道有这个坑，就一定会掉进去。今天我就把这些坑摊开讲一遍。
今天的定位：先广度
今天是我第一次做这个内训，所以主要聚焦在广度上——先把整体的理念给大家梳理一遍，让大家知道有哪些事情是存在的。
之后如果有时间，我们再挑几条做深度的展开。
今天怎么用这些内容
这不是一份让大家自己去解决的清单，是一份「知道它存在」的清单。你知道了，就可以回去问 AI「这一条我做到了吗」；不知道，就一定会踩。
AI 让「做出来」变便宜了，
但它没有让这三件事变便宜——
但它没有让这三件事变便宜——
判断该做什么 · 把东西真正做到能交给别人用 · 让一整个组织一起用起来
今天讲的就是这三件——产品思维、工程思维、组织思维。
今天讲的就是这三件——产品思维、工程思维、组织思维。
今天的九条
P1
用户思维
跟用户坐在一起，问他们撒不了谎的问题
P2
MVP
先分清问题和解决方案，再谈做什么
P3
衡量标准
Measurement 是产品的核心资产
E1
快速迭代
唯一的护城河，而且目的是错得快
E2
交付鸿沟
从 Demo 到别人真能用，中间有多远
E3
管理 AI
什么时候松、什么时候紧，以及兜底
O1
系统性思维
不花在瓶颈上的时间，都是浪费
O2
流程与系统
只给个人赋能，价值有限
O3
激励
怎么让一群人真的用起来
产品思维 8—21 MIN
工程思维 21—34 MIN
组织思维 34—44 MIN
01
产品思维
Product Thinking
8 — 21 MIN
P1
用户思维
跟用户坐在一起
P2
MVP
先分清问题和解决方案
P3
衡量标准
Measurement 成为核心资产
你在给谁做，决定了这件事有多难
几乎每家公司都强调「用户至上」。但每家企业、每个人对它的理解千差万别。先给一个难度分层，让大家知道自己在哪一层。
| 你在给谁做 | 难度 | 为什么 |
|---|---|---|
| 只给自己用 | 最简单 | 你就是用户，需求不用问，验收标准也在你自己心里 |
| 给内部小范围的人用 | 中等 | 你还能天天见到他们，反馈周期短，出错代价可控 |
| 给外面很多人用 | 指数级上升 | 你见不到他们、不知道他们怎么用、也不知道他们为什么走 |
很多人的挫败感来自：用第一层的做法，去做第三层的事。
即使是内部用户，也不简单
最简单也最有效的办法，是物理上坐过去。
我的现场
我们工程团队本来在三楼。为了能贴近用户、每天面对面地聊，我就搬到了二楼——我是公司唯一一个坐在二楼、跟 Go-to-Market 团队一起办公的工程师。
好处比我预期的大得多。我随时可以找他们聊，他们也随时可以来找我；更重要的是他们在旁边聊事情的时候，我可以随时插进去。结果是两样：一是我拿到的信息量完全不同了；二是关系变了——他们开始把我当成自己人，说话更坦诚，有什么事第一时间告诉我，而不是等到走流程。
我做的唯一一个「架构决定」，
其实是换了个工位。
其实是换了个工位。
问用户反馈，是有技巧的
用户是你的朋友、你的员工；即使是陌生人，也会因为不好意思而说好。但真相是：大部分功能你做出来，哪怕免费给别人用，别人也不会用。
错误的问题
- 你喜欢我们的产品吗？
- 如果我做了这个功能，你觉得怎么样？
得到的回答永远是：「哇这个功能太棒了，很聪明的主意，出了我一定用。」
《THE MOM TEST》
书名的意思就是：你妈妈根本不会跟你说实话。
所以你不能问你妈「你觉得我这东西做得怎么样」，你得问那种连你妈都没办法撒谎的问题。
好的问题是：你上一次遇到这个问题是什么时候？
当时你是怎么解决的？为这件事你花过多少钱？
当时你是怎么解决的？为这件事你花过多少钱？
这三个问题的共同点是：问的都是已经发生过的事实，不是对未来的猜测。事实撒不了谎，猜测全是客气话。
其实做一个好的产品，跟做一个好的销售，在很大程度上是一样的——都是先把对方真正遇到的问题问清楚，而不是急着介绍自己有什么。
其实做一个好的产品，跟做一个好的销售，在很大程度上是一样的——都是先把对方真正遇到的问题问清楚，而不是急着介绍自己有什么。
MVP 不是「小一号的产品」
它是「能以最小代价测掉最高风险假设的东西」。可以是一个落地页、一封邮件、一个人肉后台。
该做的
把最核心的那一条 workflow 先 build 出来，然后只看一件事：最核心的这个东西，到底 work 不 work。
这就是 MVP 唯一的作用——以最小的代价，测掉最高的风险。
最常见的错法
核心还没验证，就先去补边边角角的 feature、先去铺额外的分发渠道。
如果最核心的那件事本身不值得做，这些加得再多，一样不管用。
先把最核心的那条路走通，
再谈边边角角。
再谈边边角角。
核心不成立，你加再多的功能、再多的分发渠道，都是在给一个走不通的东西做装修。
把最贵的那部分直接省掉
MIDJOURNEY · 2022 年 7 月
开放测试的时候，Midjourney 根本没有做 app，也没有做网站——整个产品就是一个 Discord 机器人，你在群里打一句 /imagine 它就给你出图。创始人 David Holz 的解释是：很多人问我们为什么不直接做个 iOS app？因为人们更喜欢一起创作，而 Discord 已经有了这个社交层，我们不需要自己再建一个。
结果：开放测试两个月后 Discord 社群超过 200 万人，是当时最大的活跃社群；据他自己说，开放测试大约一个月就已经盈利，团队只有十来个人，没有拿投资。网页版一直到 2024 年 8 月才上线，晚了两年多。
最值得学的地方：他们要验证的假设是「有没有人愿意为生成图片付钱」，不是「我们能不能做出一个 app」。而 Discord 让他们几乎零成本地测掉了前一个。
老板的工作变成两件：定目标，定 measurement
对 AI 来说有一个特别关键的性质：只要你能给它一个明确的、能被衡量的标准，它就能自己想办法不断进步。而定 measurement 是非常难的一件事。
| 指标类型 | 例子 | 问题 |
|---|---|---|
| 容易衡量的 | 响应速度、每天多少用户、生成了多少内容 | 很好测，但不代表你给用户创造了多少价值。一个 app 每天一百万人用，你依然不知道你给他们带来了什么 |
| 最终价值的 | 收入 | 它才是用户愿意为你付多少钱的真实答案，但严重滞后——今天改一版，可能一个月、半年才看得到反馈 |
| 你真正要找的 | 既反映真实价值，又足够快 | 只有这种指标，AI 才能真正迭代起来。这也是老板最该花时间想清楚的一件事 |
北极星指标长什么样
LOVABLE · AI 建站
北极星指标不是注册用户数，也不是收入，而是「每天有多少个用它做出来的应用是活跃的」（Daily Active Apps）。
这个指标同时满足两个条件：反映真实价值——有人在真的用这些应用；而且每天都能看到，反馈周期是一天，不是半年。
$100M
年收入
2024 年 11 月上线 → 2025 年 7 月
2024 年 11 月上线 → 2025 年 7 月
45
人
做到这个数字时的团队规模
做到这个数字时的团队规模
你的主要工作不再是做，而是定标准。
因为只要标准定得清楚、而且能测，AI 就能自己往上爬。标准定不清楚，你给它再多算力它也在原地打转。
这一点上，管 AI 和管人其实是一样的——好的管理者，主要工作也不是自己下场做，是把目标和验收标准定清楚。
这一点上，管 AI 和管人其实是一样的——好的管理者，主要工作也不是自己下场做，是把目标和验收标准定清楚。
02
工程思维
Engineering Thinking
21 — 34 MIN
E1
快速迭代和可验证
唯一的护城河
E2
Demo 到 Production
那条巨大的鸿沟
E3
管理 AI
什么时候松，什么时候紧
现在所有公司其实都没有护城河
甚至像 Anthropic、OpenAI 这些公司，本质上都没有非常硬的护城河。唯一的护城河就是快速迭代——我的速度比你快。
ANTHROPIC 内部的数字
Claude Code 这个团队，每天对内发布 60 到 100 次，对外发布一次；平均每个工程师每天提交 5 个代码变更——一般科技公司的常态是一到两个。
这不是加班加出来的，是整个流程围绕「能不能快速验证」重新设计过。
SARAH GUO · CONVICTION · 2025 年 8 月
她在 AI 工程师大会上的一句话总结：「Execution is the moat」——执行就是护城河。
论据是：去年的模型今天就是大路货，真正的差异来自你有多懂用户的具体工作流，以及你迭代得有多快。
快速迭代不是为了跑得快，
是为了错得快。
是为了错得快。
迭代速度 = 1 / ( 协调成本 × 生产成本 × 反馈延迟 )
世界是不确定的，商业也是不确定的。你根本不知道客户到底真正想要什么。你越早知道自己错在哪，越早能做出真正符合市场的东西。
所以想快，只有三条路：降低协调成本（少开会、少交接）、降低生产成本（这是 AI 帮你的部分）、缩短反馈延迟（更早拿到真实反馈）。
所以想快，只有三条路：降低协调成本（少开会、少交接）、降低生产成本（这是 AI 帮你的部分）、缩短反馈延迟（更早拿到真实反馈）。
从「我的电脑上能用」到「过几个月还能用」
中间有非常大的距离。下面这份清单不是让大家自己去解决，是让大家知道有这些东西存在——你知道了，就可以问 AI「这一条我做到了吗」；不知道，就一定会踩。
01
在我的电脑上能用
02
别人也能打开
03
能发布到云上
04
一千个人能用
成千上万人能用
成千上万人能用
05
过几个月还能用
还能持续更新
还能持续更新
安全：八条，界面上一条都看不出来
- 01密钥不能放在前端代码里。浏览器里的任何东西用户都能看到。API key 写在前端，等于贴在门口。
- 02密钥不能明文存。放在环境变量或专门的密钥管理服务里，不要写进代码，更不要提交到 GitHub。
- 03用户密码不能明文存，也不是「加密」存，是要「哈希」存。加密可以还原，哈希不可以。用 bcrypt 或 argon2。
- 04银行卡信息尽量不要自己存。交给支付服务商。你一旦自己存了，就要承担一整套合规责任。
- 05没登录的人，能不能读到数据库里的东西？这是过去两年绝大多数 AI 建站事故的同一个根因。做完一定要自己试一次：退出登录，看还能不能拿到数据。
- 06用户输入的东西不能直接拼进数据库查询。这是最老也最常见的攻击方式。让 AI 用参数化查询。
- 07日志里不要打印密钥、密码、身份证号。很多泄露不是被黑的，是日志被人看到了。
- 08报错信息不要把技术细节直接甩给用户。那些细节是攻击者最想要的地图。
搬家、人变多、跑起来之后
第二类 · 从我的电脑搬到别人的电脑
- 01用相对路径，不要用绝对路径。你机器上那个路径，在服务器上根本不存在。
- 02时区和字符编码。中文乱码、时间差八小时，这两个坑几乎人人都踩过。
- 03依赖版本要锁定。不锁的话，别人装出来的和你装出来的不是同一个东西。
- 04开发、测试、生产三套环境要分开。尤其是数据库——这就是比比那次被删库真正的教训。
- 05改数据库表结构的时候，老数据怎么办？这一步做错，最容易一次性丢掉历史数据。
第三类 · 人多了以后
- 01两个人同时改同一条数据会怎样？一个人用永远不出问题，一千个人用天天出问题。
- 02一千条很快，一百万条会不会卡死？提前问，不要等出事。
- 03有人恶意刷你的 AI 接口怎么办？账单按调用付费。一定要加限流。
第四类 · 跑起来之后
- 01备份，而且要定期测试能不能恢复。没验证过能恢复的备份，等于没有备份。
- 02它挂了你怎么知道？监控和报警，不要靠用户来告诉你。
- 03新版本坏了，怎么退回上一版？这个要在上线之前就想好。
什么时候松，什么时候紧
跟带人一样，要看事情的复杂度和风险来决定给多少指导。
| 任务类型 | 例子 | 怎么给 |
|---|---|---|
| 低复杂度 | 挪个位置、改个名字、调个颜色 | 随便说一句就行，它都能改 |
| 高复杂度 | 新增一个完整功能、改动核心逻辑 | 先跟它 plan 一下，让它先把验收标准想清楚；可以让两个 AI 互相对抗、互相挑毛病，讨论完再动手 |
| 涉及安全／不可逆 | 权限、支付、删除、对外发送 | 要多想一层，让它逐条确认，并且必须有人在环点头 |
哪些交给 AI，哪些写死
用比比那个写作系统举例，假设要求是「文章不能超过 1500 字」。
| 做法 | 结果 | |
|---|---|---|
| 确定性 | 让 AI 写一段代码去数字数，超过 1500 就判为不合格 | 每一次都准。这里 AI 只是帮你写了那段代码，规则本身是写死的 |
| 不确定性 | 直接在提示词里写「请确保不要超过 1500 字」，让 AI 自己保证 | 它不一定每次都做得到。换个模型、上下文长一点，就可能失手 |
判断法很简单：这件事有没有唯一正确的答案？有，就写死；没有、要看情况，才交给 AI。
凡是「必须发生」的事，不要写在提示词里，
要做成一道卡子。
要做成一道卡子。
写在提示词里的，都只是建议。
03
组织思维
Organizational Thinking
34 — 44 MIN
O1
系统性思维
不花在瓶颈上的时间都是浪费
O2
流程与系统
只给个人赋能，价值有限
O3
激励
怎么让一群人真的用起来
不花在瓶颈（Bottleneck）上的时间，
都是最大的浪费。
都是最大的浪费。
营收要穿过一环又一环才出来
如果把价值创造链想成一根管道，那这根管道一定有一处最细的地方。
市场
销售
客服
设计
产品
工程
产品非常强、做出来的东西很好，但销售很弱——那你就卖不出去。这时候你再花很多精力去提高工程和产品，价值其实是不大的，因为你还是会被堵死在销售那一环。
AI 提效完全一样。每个人想的都是提高自己、自己部门的效率。但从公司的角度看，所有其他的组都应该想「我怎么帮那一环提效」，而不是「我怎么让我自己这一组更快」。
AI 提速的那一环，不一定是最堵的那一环
GOOGLE / DORA 报告 · 2025
Google 内部一位工程师的原话，被写进了 2025 年的 DORA 报告：
「审别人的代码，比自己写代码难得多。
而 AI 工具正在提高人们产出待审代码的速率。」
写代码这一环被 AI 提速了，瓶颈就整个压到了下一环。
同一份报告里：90% 的人在工作中用 AI，但 30% 说自己几乎不信任 AI 产出的代码——这两批是同一批人。
同一份报告里：90% 的人在工作中用 AI，但 30% 说自己几乎不信任 AI 产出的代码——这两批是同一批人。
AI 不会消灭瓶颈，它只会把瓶颈往下游推一格。
所以每次上 AI 之前，先问一句：我这是在给最堵的那一环松绑，还是在给已经很通畅的那一环再加水？
这件事历史上发生过一模一样的一次
即使你把每个人都提效 5 倍，大部分人的时间还是会花在开会、协作、各种扯皮上。给每个人配上 AI 是一个很好的开始，但它只是开始。
电气化的四十年 · 经济史学家 PAUL DAVID · 1990
1881 年爱迪生的中央电站就开始供电了，但美国制造业的生产率大爆发一直等到 1919 到 1929 年——整整晚了四十年。
因为工厂原来是围绕一台中央蒸汽机建的：屋顶上一根长长的传动轴，靠皮带把动力分给每台机器。为了减少长轴的功率损耗，工厂必须建成又高又窄的多层楼；机器只能按「离动力源多近」来摆，不能按生产流程来摆。第一波电气化只是把蒸汽机换成了一台大电动机，别的什么都没变，收益很有限。
真正的爆发来自后来的「一机一马达」——每台机器自己带一个电动机之后，工厂终于可以改成单层的、按工艺流程线性排列的布局，物料一路往前走，不用再折返。数据上：1899 年电动机只占工厂机械动力的 4.8%，1919 年才过半，1929 年到了 78%。
电动机不是生产率，重新排布的车间才是。
AI 也一样：模型不是生产率，重新设计的流程才是。
AI 也一样：模型不是生产率，重新设计的流程才是。
今天绝大多数公司，还停在「把蒸汽机换成电动机」那一步。
Paul David 有一句很妙的话：「1900 年，一个观察电气时代进展的人完全可以说，电动机随处可见——除了在生产率统计数据里。」经济学家 Erik Brynjolfsson 在 2025 年就明确把这个类比用在了 AI 上：企业最初只是把人换成 AI，流程一动不动；只有当管理者意识到可以重新组织生产之后，真正的收益才会出现。
Paul David 有一句很妙的话：「1900 年，一个观察电气时代进展的人完全可以说，电动机随处可见——除了在生产率统计数据里。」经济学家 Erik Brynjolfsson 在 2025 年就明确把这个类比用在了 AI 上：企业最初只是把人换成 AI，流程一动不动；只有当管理者意识到可以重新组织生产之后，真正的收益才会出现。
从沟通成本看，为什么流程必须变
| 沟通类型 | 成本 | 为什么 |
|---|---|---|
| 人 ↔ 人 | 最高 | 要约时间、要照顾情绪、要来回确认，还会有信息损耗 |
| 人 ↔ AI | 其次 | 你可以随便说、想到哪说到哪，不用担心它的情绪，也不用等它有空 |
| AI ↔ AI | 接近于零 | 光速沟通，不需要开会 |
以前一件事要三个人接力，现在可能一个人加上 AI 就全干完了——省下来的不是那两个人的工时，是他们之间来回沟通的时间，而那部分往往比干活的时间还多。
我的现场
我这个项目里，我一个人同时是产品经理、前端、后端、运维和客服。正因为整个沟通结构就是我一个人，这套系统从头到尾没有一次交接成本。
另外我还做了一个组织上的决定：我要求客户支持的同事，发现界面上的问题直接提交代码改动，而不是给我提工单。原来所有瓶颈都在我一个人身上，改完之后沟通成本大幅下降。
请注意，这是一个组织决定，不是一个工具决定——工具一直都在，是流程变了才有用。
怎么让一群人真的用起来
- 一CEO 自己得用起来。这是前提，不是加分项。如果你自己都不懂，员工一定能看出来——他们分得清你是真的想推，还是只是在装样子。我们 CEO 和几位高管都非常积极地在用，这是我这个转型能推得动的前提。
- 二初始激励：给足工具，别在这里省钱。unlimited token、排行榜都属于初始激励，目的是把人推过静摩擦那一关。这个阶段你要的是采用率，不是省钱。但从第一天就要埋点：谁在用、用在哪、产出了什么。行业里已经有公司四个月烧完一整年的 AI 预算，就是因为只做了第一步。
- 三真正的杠杆在第二步：把个人的用法变成组织的。看出谁用得多之后，最有价值的动作不是发奖，是去跟他聊：你具体在什么场景下用的？怎么摸索出来的？然后让他做一次内部分享，给他正式的认可。
- 四AI Week：一周脱产。全员脱产，用 AI 做工具、或改善自己的业务流程。即使最后只有 5% 真正有效，对整体提效也已经非常明显——而且这一周所有人都会大量使用 AI，组织的熟练度会有一次跳跃。
- 五但要接受正态分布。有人天生爱折腾，非技术岗也会自己研究；有人要等你把一切做顺手了才用。这些都是人性。AI Week 的目标不是让所有人达标，是找出前面那 20%，把他们的经验变成剩下 80% 的默认工具。
排行榜不要只排谁用得多，
要排谁做的东西被别人用了多少次。
要排谁做的东西被别人用了多少次。
前者奖励的是能者多劳，后者奖励的是让别人也能干。
带走这九句
P1
用户思维
坐过去。问已经发生过的事，不问对未来的猜测。
P2
MVP
先把最核心的那条路走通，再谈边边角角。
P3
衡量标准
你的工作是定标准。能测，AI 才能自己往上爬。
E1
快速迭代
降协调成本、降生产成本、缩短反馈延迟。
E2
交付鸿沟
那五道关，AI 一道都帮不了你。
E3
管理 AI
必须发生的事做成卡子，不要写进提示词。
O1
系统性思维
先找到最堵的那一环，再决定 AI 上在哪。
O2
流程与系统
电动机不是生产率，重新排布的车间才是。
O3
激励
排谁做的东西被别人用了多少次。
判断该做什么
做到能交给别人用
让一整个组织一起用
问答