产品与创业 on 方糖猫Blog

HN 招聘帖 9 月观察：帖子少了四分之一，但有几样东西在逆势变厚

Tue, 08 Sep 2026 10:30:00 +0800

HN 招聘帖 9 月观察：帖子少了四分之一，但有几样东西在逆势变厚

上一篇《从 HN 招聘帖看创业活路》分析了 2026 年 7 月（410 条）和 8 月（330 条）两期招聘帖。9 月 1 日第三期出来了，我照例抓取、统计、逐条过了一遍。这篇只讲增量：和上两个月相比，什么消失了，什么变厚了，以及一份"三期全勤"的公司名单。

先交代数据口径：和前两期一样，只统计主帖（公司发布的招聘条目），不含讨论回复。9 月主帖 242 条。

一、总量：410 → 330 → 242

帖子数量连续第二期下滑，9 月比 8 月少了 27%。暑期因素已经解释不了这个跌幅——7 月到 8 月是暑期，9 月可不是。更可能的解释是：公司在招人这件事上变得更谨慎，或者更精准——招聘需求没有消失，而是集中到了更少、更明确的方向上。下面的结构变化支持后一种解释。

词频层面（242 条主帖中的出现比例）：

AI 出现在 60% 的帖子里，agent 25%，agentic 11%——“agentic” 已经从营销词变成岗位描述的默认词汇
remote 56% vs onsite 29%——远程比例稳定，SF/NYC 的 onsite 集中在 AI 和硬件团队
founding（创始工程师类岗位）占 8%，而 7 月是 18/410 ≈ 4%——早期公司的占比翻倍。帖子少了，但新公司的诞生速度没有跟着慢下来
security 出现在 16% 的帖子里——这个比例高得反常，下面细说
技术栈排位不变：Python > TypeScript > Rust > Go

最戏剧性的变化是量子公司集体消失：8 月 quantum 出现 15 次（Atom Computing、IonQ、Unitary Foundation 等都在扩编），9 月归零——一期之内从"密集冒头"到"查无此人"。我 8 月写"招聘是领先指标"，9 月就收到了反面教材：领先指标也会回撤，单月的招聘热度不等于趋势。这也是为什么要连续读多期。

二、逆势变厚的四个方向

flowchart LR
    A["9 月 242 条帖子<br/>总量 -27%"] --> B["Agent 治理与安全<br/>security 占 16%"]
    A --> C["政府成为买家<br/>govtech 集群"]
    A --> D["能源层继续变厚<br/>energy 22 次"]
    A --> E["给模型出考题<br/>评测与环境成新铲子"]
    B --> B1["MintMCP · Greywatch<br/>Trustible · Steg.AI"]
    C --> C1["Statecraft · Aerdos<br/>GovStar · Tecuity"]
    D --> D1["Neuralwatt · Strobe Power<br/>Oklo（三期全勤）"]
    E --> E1["Mechanize · Prophet Town<br/>Artificial Analysis"]

1. Agent 治理与安全：从"有没有 Agent"到"管不管得住 Agent"

8 月的主题是公司争相部署 Agent，9 月的主题是部署之后怎么办。一批公司专门做"Agent 的管控层"：

MintMCP 给 IT 部门提供统一的 Agent 落地入口——身份、权限、可见性，帖子里直接晒了进度：6 个月拿下 40+ 付费客户（Braze、Coursera、Stability AI），6 周内团队从 6 人翻倍到 12 人
Greywatch 做 Agent 安全与治理平台，“从内核到网络看清 AI agent 在你的基础设施里干什么”
Trustible 帮企业应对正在落地的 AI 监管，同时在招 Agentic Engineer 和 Forward Deployed Engineer
Steg.AI 做不可见的 AI 水印，Hiya 识别深伪诈骗电话（覆盖 5 亿用户），InfoHawk 追踪 AI 生成的仿冒网站和欺诈广告

与之呼应的是 eval（评测）正式成为岗位职责：10% 的帖子明确提到 evals。最典型的是 Republic Services——北美第二大环保服务公司，4 万员工、几千辆卡车——在招第一位 Agentic AI 工程师，岗位描述写得像教科书：agent 编排、检索与记忆、evals 与 golden dataset、prompt 注入防护、审计日志。当"收垃圾的公司"都开始建制化地招 Agent 工程师，说明垂直 Agent 已经越过早期采用者阶段，买家从创业公司变成了老经济本身。

2. 政府成为买家

9 月有一个此前不明显的集群：把 AI 卖给政府，或者直接替政府干活。

Statecraft 的帖子火力很猛：“美国政府几乎完全由外包顾问运营，顾问人数是公务员的 3 倍，他们把低效制度化以便多收工时费”——他们做的事是用 AI workforce 自动化这些工作，招全级别的 FDE
Aerdos 定位"AI 原生情报机构"，用公开和商业数据帮美国政府回答国家安全问题
GovStar 招 5 个工程师给政府建"安全、生产级的 AI 能力"（要求美国公民身份）
更老的玩家也在：Tecuity 给州务卿办公室写了 20 多年软件，Leidos 继续在 FAA 项目招人，Valkyrie Aero 是国防部主承包商（载人反无人机飞机），Mattermost 的客户名单就是国防、情报、安全机构

这条线的逻辑和垂直 Agent 一样——替代昂贵人力——但买单方换成了财政。政府合同周期长、合规门槛高，可一旦进去就是多年期收入。在帖子总量收缩的月份里这个集群反而成形，值得记下来。

3. 能源层继续变厚

8 月我写了"淘金热的铲子从 GPU 延伸到电网"，9 月这层更厚了：

Neuralwatt：帮数据中心"从每一千瓦里榨出更多可用的 AI 算力和收入"，做 GPU 优化和能耗感知控制系统
Strobe Power：把商业楼宇里的电池和发电机聚合成分布式电厂，实时买卖和调度电力——“做一家满足 AI 数据中心需求的电力公司”
加上做能源交易的 Amplify Renewables、做电网效率的 Comity、柏林的 Frequenz（Energy-as-a-Service）、牛津的 Aurora Energy Research，以及三期全勤的 Oklo（核反应堆）

算力瓶颈往下传导到电力的路径已经完全确立，而且分工在细化：有人管"省电"，有人管"找电"，有人管"造电"。

4. 给模型"出考题"成为新铲子

9 月出现一类两个月前还不存在的岗位：为前沿实验室构建训练环境和评测基准。

Mechanize 做的事一句话：建造前沿实验室用来训练模型"做真实软件工程"的环境。“需求超过我们能跟上的量，正在快速招人”——Junior SWE 开价 30 万美元加股权加奖金
Prophet Town 9 月的在招方向包括：设计 RL benchmark、red-team 模型输出、给前沿模型的 agentic coding 能力写评分 rubric
Artificial Analysis 作为独立第三方 AI 评测公司在两地 onsite 扩张

模型能力提升之后，“怎么衡量和训练它干活"本身成了供不应求的生意。这是卖铲子逻辑的最新一环：铲子已经不只卖给用 AI 的人，还卖给造 AI 的人。

三、物理世界：词汇在升级

物理世界这条路径（7、8 月的"路径三”）9 月仍在，但措辞变了——Physical AI 和 world model 开始取代泛泛的"机器人"：

Valstad Shipworks：“建造船的机器”——面向自主造船的机器人平台，软件栈从运动规划到物理仿真全部自研
Reframe Systems 用机器人微型工厂网络批量造房（从 ADU 到中型公寓），核心软件问题是"把数月的设计开发周期压掉"
Stand 给每栋房子建数字孪生，用物理信息世界模型预测野火/飓风中的具体损失，再据此给保险定价——已承保约 100 亿美元。这是"世界模型"第一次以赚钱的形态出现在帖子里
Rerun 自称是"Physical AI 的数据层"，Springcraft 自称是"Physical AI 的平台"——连卖铲子的都开始用这个词命名自己
老牌面孔还在：MONUMENTAL 三期全勤，Brain Corp 全球部署了 5 万台机器人，Greenzie 做商用割草机自动驾驶

同期值得注意的还有"非 LLM 的基础模型"：Prior Labs 做表格数据基础模型（临床试验、金融模型背后都是表格），Xaira 做生物基础模型，Pathos 用肿瘤学基础模型配 200PB 数据，ORIGAMICS 做能推理电子原理图的模型。LLM 之外的基础模型正在按数据类型铺开。

四、薪资与求职端：哑铃型分化

9 月帖子里的薪资数字呈现出很清楚的哑铃形：

flowchart LR
    subgraph 哑铃的一端
        A1["Mechanize Junior SWE<br/>$300k + 股权"]
        A2["aiuc.com MTS<br/>$200k-400k"]
        A3["Balerion AI<br/>$250k+ base"]
    end
    subgraph 哑铃的另一端
        B1["Search Atlas<br/>$23-34/小时 合同工"]
        B2["多条 equity-only<br/>零工资帖"]
        B3["匿名 SaaS 岗<br/>$90k-110k"]
    end
    A1 --- B1
    MID["中间地带在变薄"]
    A1 -.-> MID
    B1 -.-> MID

哑铃的一端：离前沿实验室越近、或离大钱越近的岗位，薪资越离谱。Mechanize 给 junior 开 30 万；做 AI 保险承保的 aiuc.com（团队含前 Anthropic/METR/OpenAI）开到 40 万
另一端：普通全栈岗的报价继续下探，30 美元时薪区间的合同工岗位堂堂正正地贴在帖子里，equity-only 的"零工资联合创始人"帖照例出现
求职端供需：咨询公司 Prophet Town 自己披露，8 月的帖子收到 216 份申请，发了约 10 个 offer（4.6% 录取率）；做代理网络的 Proxybase 创始人在帖子里公开道歉——“申请太多，回复慢了”。雇主端的谨慎和求职端的拥挤，两个事实继续同时为真
连续第三期，有人在帖子里呼吁雇主标注 4 天工作制（4DWW）——这个诉求没有消失，但也没有更多雇主接招

五、三期全勤名单

单期的热词可能是噪音，连续三个月都在扩编的公司是更硬的信号。同时出现在 7、8、9 三期帖子里的公司：

垂直 Agent：PermitFlow（建筑许可）、Shepherd（保险承保）、Norm Ai（法律）、Anterior（医疗授权）、Vitalize（医院排班）、Oscilar（风控）、Snout（宠物医疗支付）、Apex Dental（牙科集团）
信任基础设施：Middesk（KYB）、DuckDuckGo、Enveritas（咖啡农可持续发展，非营利）
卖铲子：LiveKit（语音管道）、Railway（部署平台）、Cascade Space（地面站）
物理世界：MONUMENTAL（砌砖机器人）、Oklo（核能）
慢慢赚钱：Sudowrite、PostHog
大厂标本：Snowflake 的 Applied AI / FDE 团队三期都在招——“驻场交付"作为行业标准动作的地位彻底坐实

另外 Langfuse 8 月被 ClickHouse 收购后，9 月已经不再发帖，而是以"技能要求"的形式活在别人家的岗位描述里（Republic Services 和 AiMi 的帖子都点了它的名）——开源工具的另一种存在感。

六、小结

把 9 月这 242 条压缩成一句话：总量在退潮，但潮水退去的地方露出的不是沙滩，而是四条更深的河道——管好 Agent、卖给政府、解决电力、给模型出考题。

对创业者，这期的启示比前两期更具体：当收垃圾的公司都开始建制化地招 Agent 工程师，“帮传统行业落地 AI"的窗口正在从"教育市场"切换到"交付结果”——客户已经知道自己要什么，接下来拼的是交付能力和行业理解。这正是 8 月说的 FDE 模式的必然延伸。

至于上篇讨论过的"这套行情是否在中国重演”，9 月的数据没有改变判断，只补了一条注脚：政府作为 AI 买家这条线，美国的形态是"替代外包顾问"，国内的形态大概率是信创和政务智能化的延续——同一条河，不同的河床。

数据来源：Ask HN: Who is hiring? (September 2026)，共 242 条主帖，2026-09-08 抓取。

从 HN 招聘帖看创业活路：740 家公司教我的事

Wed, 19 Aug 2026 15:00:00 +0800

从 HN 招聘帖看创业活路：740 家公司教我的事

Hacker News 每个月都有一个 “Ask HN: Who is hiring?” 帖子。我一直觉得它是被低估的创业研究材料：能在上面花钱花人招工程师的公司，多半是活下来、而且有现金流或融资的公司——这是天然的"幸存者样本"。我把 2026 年 7 月和 8 月帖子抓下来做了词频统计，又逐条过了一遍，这篇文章聊聊我从里面看到的创业路径，以及两个月之间风向的变化。

先给不熟悉 HN 的读者补个背景：Hacker News 是硅谷最有影响力的技术社区，由著名孵化器 Y Combinator 运营。每月 1 号它会置顶一个 “Who is hiring?"（谁在招人）帖子，公司创始人或工程师在评论区按固定格式发招聘启事——公司名、岗位、远程/坐班、薪资范围、一句话介绍。每条招聘帖背后都是一家正在扩张的真实公司，所以把这个帖子当数据库来读，就能看到"什么类型的创业公司此刻活得不错”。

一、先看数据：AI 已经不是赛道，是空气

7 月的 410 条帖子里，“AI” 出现了 405 次。这个数字的意义不在于"AI 很火"，而在于：已经没有"AI 公司"这个分类了，就像今天没人说自己是"互联网公司"一样。AI 变成了所有公司的默认组件。

其他值得注意的词频：

remote 226 次 vs onsite 100 次 + hybrid 61 次——远程仍是主流，但 SF/NYC 的 onsite 明显回流，尤其是 AI 和机器人方向的早期团队
founding engineer 18 次——早期公司密度很高，说明新公司的诞生速度没有放缓
profitable 22 次、bootstrapped 9 次——盈利公司乐意把"我们赚钱"写进招聘广告当卖点
技术栈：Python（88）和 TypeScript（72）是绝对主力，Rust（63）站稳了系统层，Go（2）反而式微
上一轮的宠儿几乎消失：crypto 3 次、web3 0 次、gaming 3 次

真正有意思的是这些词背后聚成的几类公司。我归纳出五条路径，整体解构如下图：

flowchart LR
    A["HN 招聘帖<br/>两期 740 家公司"] --> B["路径一：卖铲子<br/>AI 基础设施"]
    A --> C["路径二：垂直行业 + Agent<br/>密度最高"]
    A --> D["路径三：回到物理世界<br/>机器人 / 制造 / 国防 / 能源"]
    A --> E["路径四：慢慢赚钱<br/>老牌盈利公司"]
    A --> F["路径五：合规与隐私<br/>信任基础设施"]
    B --> B1["算力与芯片<br/>Fluidstack · Fractile"]
    B --> B2["管道与平台<br/>LiveKit · Railway · Estuary"]
    C --> C1["建筑 PermitFlow<br/>保险 Shepherd<br/>医疗后台 SmarterDx"]
    C --> C2["法律 Norm Ai<br/>物流 Pango · Orbit"]
    D --> D1["机器人 MONUMENTAL<br/>制造 Freeform"]
    D --> D2["国防 Aurelius<br/>能源 Oklo"]
    E --> E1["Proton · PostHog<br/>Sudowrite · IVPN"]
    F --> F1["Middesk · Oneleet<br/>Kanary"]

下面逐条展开。

二、路径一：卖铲子——AI 基础设施

Fluidstack 给前沿实验室建超算集群
Fractile 做 AI 推理芯片，Founders Fund 背书
Syntropic 压缩 LLM 的 KV cache，号称 8 倍压缩、0.43% 质量损失
LiveKit 做语音 AI 的实时通信层，Railway 做部署平台，Estuary 做实时数据同步

这是最拥挤也最贵的一条路：资本密集、人才密集。但它的启示对独立开发者同样成立——每一轮淘金热里，活得最好的往往是卖工具的。只是 2026 年的"铲子"已经不是"再做一个 LLM 网关"，而是往更底层（算力、内存、数据流）或更具体的环节（语音管道、Agent 运行环境）钻。

结合 8 月的数据，“铲子"已经明显分成了四层，越往下越重资产，但也越稀缺：

flowchart BT
    POWER["第四层：电力与能源<br/>Joulent · Oklo · Proxima Fusion"] --> COMPUTE["第三层：算力与推理优化<br/>Fluidstack · Fractile · Syntropic"]
    COMPUTE --> INFRA["第二层：平台与管道<br/>LiveKit · Railway · Estuary"]
    INFRA --> APP["第一层：应用<br/>垂直行业 Agent（路径二）"]

值得注意的方向：上层的创业者在往下走（应用公司开始囤算力），下层的瓶颈在往上顶（电力决定了算力扩张的速度）。

三、路径二：垂直行业 + Agent，专挑"无聊但有钱"的行业

这是帖子里密度最高的一类，也是我认为普通创业者最现实的路径。共同公式是：找一个流程落后、靠 Excel 和邮件运转的传统行业，用 AI Agent 把里面的手工环节吃掉：

建筑业：PermitFlow 做施工许可，OneCrew 给沥青混凝土公司做全业务平台，Rabbet 做建筑金融，Klutch AI 做工地移动端
保险业：Shepherd 做全自动承保，Annex Risk 做自然灾害房屋保险，Oscilar 做风控决策
医疗后台：SmarterDx 管医院计费（“医院怎么拿到钱"这种没人愿意碰的系统），Vitalize 管医院排班，Anterior 做诊疗授权自动化
法律合规：Norm Ai 自称"agentic law company”，客户管着 30 万亿美元资产；Phaselaw 做 eDiscovery
物流：Pango 做电商物流的"Agentic OS”，Orbit 要替换掉欧洲货运公司的 Excel
物业：AveryIQ 直接叫板 Appfolio、Yardi 这些老软件

这类公司的特点是：客户不在乎你的模型多先进，只在乎省了多少人力、少出多少错。壁垒不在 AI，在于你比 AI 公司更懂行业，比行业公司更懂 AI。入场券是行业知识，不是算法。

四、路径三：回到物理世界

软件吃世界的上半场结束了，下半场开始吃原子：

Monumental 的机器人真的在砌砖盖楼，特意强调"机器人领域有很多 PPT 公司，我们不是"
Freeform 做 AI 原生制造，Rangeview 要"重建美国的铸造体系"
国防：Aurelius Systems 做激光反无人机系统，Air Space Intelligence 刚拿下 FAA 的合同，Sphinx Defense 做国家安全软件
能源：Oklo 造下一代核反应堆
太空：Ecosmic 做空间态势感知，Cascade Space 做地面站硬件

地缘政治（国防、供应链回流）加上 AI 控制的成熟，让"硬科技"重新变成一门好生意。这条路门槛高、周期长，但帖子里这些公司的存在本身说明：资本愿意为物理世界付钱了，这在五年前并不成立。

五、路径四：慢慢赚钱的"老家伙"们

用户看招聘帖的一个直觉是对的——能持续招人就是活下来的证据。帖子里有一批 5 到 15 年"高龄"的公司，它们的路径是另一个极端：

Proton（盈利、无 VC 控制）、DuckDuckGo、IVPN（2010 年成立，每年独立审计）
PostHog（公开手册、全远程）、Featurebase（bootstrapped、盈利）
Sudowrite 直接在帖子里打勾：√ PMF √ PROFITABLE
BitPay（2011）、MixRank（YC S11）、Rabbet（YC S17）——穿越了不止一个周期

这些公司的共同点：服务一个明确的付费人群，控制烧钱速度，把"盈利"当成竞争力而不是妥协。在 AI 叙事满天飞的帖子里，“我们是盈利公司"反而成了吸引工程师的差异化卖点——大家被裁员潮教育过，知道烧钱的故事会怎么收场。

六、路径五：合规和隐私本身成为生意

Middesk 做 KYB（企业身份核验），是银行和 fintech 的基础设施
Oneleet 做一站式安全合规（ASM、代码扫描、SOC2 全家桶）
Kanary 帮个人监控和清理网上的隐私暴露
Friendly Captcha 十年只做一件事：反机器人验证码
Sequent 做密码学安全的在线投票

监管越重、AI 生成的垃圾流量越多，这类"信任基础设施"就越值钱。它们不性感，但需求是结构性的——不会因为模型换代而消失。

七、几条路径之外的观察

“Forward Deployed Engineer” 成了热词（Antithesis、Confido、Kinxshn 等都在招）。Palantir 模式的扩散意味着：垂直 AI 公司发现，离客户不够近就落不了地。这对创业者的提示是，早期别抗拒"像咨询一样干活”，那就是产品发现的过程。
纯投机空间变小了。帖子里的骗局（假 GPU 集群、要护照照片的"招聘"）都被评论区当场拆穿。社区嗅觉很灵敏，靠信息差骗钱的窗口在关闭。
警惕"零工资+股权"的帖子。7 月那批帖子里有好几条 equity-only 的，评论区并不客气。创业可以赌，但要把赌注看清楚再上桌。
4 天工作制（4DWW）在被主动索要。有公司拿它当卖点，也有求职者在帖子里呼吁雇主标注。小公司拼不起薪资时，工作方式是最便宜的差异化。

八、一个月之后：8 月帖子的增量信息

写完上面的分析后我又抓了 8 月那一期（330 条）。帖子总量比 7 月少了约两成（有暑期因素，但也和评论区"市场不好"的抱怨互相印证），不过结构上验证了前面的判断，还多出几个新信号：

Forward Deployed Engineer 彻底出圈。这个词 7 月只出现 4 次，8 月出现 16 次，连 Snowflake 这样的大厂都组建了 Applied AI / FDE 团队。“驻场帮客户把 AI 落地"从 Palantir 的独门打法变成了行业标准动作——这进一步确认：垂直 AI 的竞争发生在客户的业务现场，不在模型里。
能源成了"卖铲子"的新一层。Joulent 做的事一句话就能说完：给 AI 数据中心送电（“multi-gigawatt power to AI data centers”）。算力紧缺的下游是电力紧缺，淘金热的铲子已经从 GPU 延伸到电网。同方向还有 Proxima Fusion 在慕尼黑造商用仿星器核聚变装置。
量子计算密集冒头。quantum 从 4 次涨到 15 次：Atom Computing（中性原子）、IonQ（离子阱，已在波士顿建全球研发中心）、Aqora、Unitary Foundation（容错量子编译）都在招人。还没到爆发期，但招聘是领先指标。
语音 AI 是一个被低估的垂直点。River 做 B2B 外呼 Agent、Phonely 做电话客服自动化、Strello Health 做医疗语音 Agent，加上做底层管道的 LiveKit——voice 出现 11 次。语音是"替人干活"最直接的形态：电话打出去，活就干完了。
垂直行业继续向更冷门的角落渗透：兽医诊所（Instinct Science、Snout）、牙科集团（Apex Dental，65 家诊所的 DSO）、农业贷款（Landjourney）、食品供应链（Choco）、餐厅收银（Vitabyte）。甚至阿森纳足球俱乐部都在招 Research Engineer 嵌入一线队——“行业 know-how + 工程"的组合没有边界。
连续两期出现的名字值得多看一眼：PermitFlow、Klutch AI、OneCrew、Shepherd、Norm Ai、Middesk、Bucket Robotics、MONUMENTAL、Freeform、DuckDuckGo、IVPN、PostHog、Sudowrite、Featurebase、Enveritas……连续两个月都在扩编，说明业务在真实增长。其中 Langfuse（LLM 可观测性）8 月帖子的抬头已经变成 “now part of ClickHouse”——开源 + 开发者工具这条路，两个月内就给出了一个退出样本。
求职端的寒意也更明显。有人在帖子里算账：加州 Petaluma 的 Chipotle 起薪 20 美元/小时，而一些初级开发岗位的报价已经逼近这条线；7 月就出现过的"假 GPU 集群"骗局 8 月原样重发，照例被评论区当场拆穿。公司端在扩张，求职端在承压，两个事实同时为真——这本身就是垂直 AI 创业有机会的原因之一：企业要的不是"更多人”，而是"更少人 + 更多自动化”。

九、这套行情会在中国重演吗？

写到这里，很多读者自然会问：这些路径放在国内适用吗？我的判断是：结构上会重演，形态上会变形。逐条对比一下（以下为个人判断，供参考）：

路径	美国的驱动逻辑	在中国是否成立
一、卖铲子	算力紧缺、语音/Agent 管道空白	部分成立。基础设施层由大厂和重资本主导，创业公司机会在细分工具（推理优化、Agent 运行环境）而非正面硬刚
二、垂直行业 + Agent	替代年薪 8 万美元的后台人力，ROI 极高	成立，但账不一样——详见下文
三、物理世界	再工业化、国防、能源	不是重演，是主场：机器人产业链、制造业场景、电力基建本来就是中国的供给端优势
四、慢慢赚钱	服务明确人群、控制烧钱	两国都成立，且在国内资本环境下几乎是默认姿势
五、合规与隐私	HIPAA、SOC2、保险监管驱动	成立，但合规的来源不同：国内是等保、数据安全法、信创——信创恰恰是中国独有的"合规生意"

路径二是最值得细说的。美国垂直 Agent 公司的核心账本是"替代昂贵人力"：医院计费员、保险承保员、施工许可专员，年薪动辄 8 到 15 万美元，Agent 收半价客户还嫌便宜。国内同样的岗位人力成本低得多，“替人干活"的定价空间天然被压缩；再加上国内 to B 软件的老问题——大客户要定制和私有化部署，小客户付费意愿弱，钉钉/企微/飞书又压掉了通用 SaaS 的空间——所以同样一个"医院计费 Agent”，在美国是标准化 SaaS 生意，在国内很可能做成项目制生意，毛利和可复制性差一截。

这不是说路径二在国内不成立，而是它的成立形态会不同。我用三个"过滤器"来总结判断过程：

flowchart TD
    US["美国已验证的模式"] --> F1{"人力替代 ROI 够高吗？"}
    F1 -- "美国：人力贵，账好算" --> OK1["国内也可复制"]
    F1 -- "国内：人力便宜，账难算" --> F2{"客户愿意为<br/>软件/Agent 付费吗？"}
    F2 -- "意愿弱" --> GO["出海：把产品卖给<br/>付费意愿强的市场"]
    F2 -- "意愿强（合规 / 刚需）" --> OK2["国内成立，但多为<br/>解决方案 + 私有化形态"]
    US --> F3{"中国有供给端优势吗？"}
    F3 -- "硬件 / 制造 / 电力" --> OK3["不但重演，而且可能领先"]

几个由此推出的具体判断：

出海是国内垂直 AI 团队最现实的选项。人力账本在美国、中东、东南亚更划算，而中国的工程成本和交付速度是供给端优势。帖子里 RevOps、物流、建筑这些赛道的玩法，完全可以由国内团队反向输出。
国内做垂直 Agent，优先选"合规/刚需驱动"的行业：医疗（医保控费）、金融（监管报送）、政务、信创替代——这些领域的付费不由"省人力"决定，由"不做不行"决定，绕开了人力成本账本。
路径三（物理世界）不用等重演。机器人、智能制造、数据中心电力这些方向，国内的供应链和场景密度本来就更厚，美国的"再工业化"叙事反而是在追赶已有的中国产能。
“行业 know-how"的稀缺性两国通用。国内建筑信息化有广联达、医疗信息化有卫宁和东软、法律科技也有一批老玩家——新机会不是再造一个行业软件，而是像 SmarterDx 那样，用 Agent 重做这些系统里仍然靠人肉运转的环节。

十、写在最后

把这两期 740 条帖子压缩成一句话：AI 让"改造一个古老行业"的单位成本骤降，于是活下来的公司分成了两拨——一拨去给这场改造造工具（从 GPU 到电力再到语音管道），一拨扎进建筑、保险、医疗、物流、农业这些"无聊"行业里吃手工流程；而那些早早就开始赚钱的老公司，在一旁验证了另一种活法：不追浪潮，也能活得很好。

如果你在想创业点子，我会建议按这个顺序问自己三个问题，决策路径如下：

flowchart TD
    Q1{"我懂哪个'无聊<br/>但有钱'的行业？"} -- "还没有" --> L1["先去行业里干活，<br/>积累 know-how"]
    Q1 -- "有" --> Q2{"里面哪个环节还在<br/>靠人肉 Excel？"}
    Q2 -- "找不到" --> L2["换个行业看，或去该行业<br/>公司做驻场工程师（FDE）"]
    Q2 -- "找到了" --> Q3{"AI 能把这个环节的成本<br/>打下一个数量级吗？"}
    Q3 -- "不能" --> L3["时机未到，保持观察"]
    Q3 -- "能" --> Q4{"目标客户在哪里<br/>付费意愿最强？"}
    Q4 -- "国内（合规/刚需）" --> GO1["国内做解决方案<br/>小步验证付费"]
    Q4 -- "海外（人力贵）" --> GO2["出海做标准化产品"]

这三个问题都有答案的时候，大概率就有一张入场券了。

GeekCast vs OpenCut：两款视频编辑项目的功能对比

Mon, 13 Jul 2026 18:00:00 +0800

GeekCast vs OpenCut：两款视频编辑项目的功能对比

我个人最近开发的GeekCast GeekCast（我开发的极客口播自动化剪辑工具）, 用AI对比了开源项目 OpenCut 的功能、架构与定位差异。GeekCast 已开源，地址：https://gitee.com/soulnew/geekcast。

一、项目定位对比

维度	OpenCut	GeekCast Engine
产品形态	通用开源非线性视频编辑器（NLE），面向普通创作者	垂直的"口播自动化剪辑工具"，面向技术博主、独立开发者、播客主
核心假设	用户在时间线上手动剪辑	视频即文本：用户像编辑文档一样删除气口、静音、语气词
目标平台	Web + Desktop + Mobile（重写版目标）	Web 管理台 + Java API + Python Worker，本地或私有部署
开源协议	MIT	已开源（Gitee）

二、功能对比

功能	OpenCut（当前重写版）	OpenCut（classic）	GeekCast
视频导入/素材管理	❌ 未实现	✅ 支持	✅ 统一 `public/assets` 目录，支持原始素材、B-roll、脱水视频
时间线编辑	❌ 无时间线模型	✅ 传统时间线	✅ 文本化 timeline：`MAIN_VOICE` / `B_ROLL` / `REMOTION_TEMPLATE`
词级删除/气口分析	❌ 无	一般 NLE 手动处理	✅ Whisper 转录 + VAD，支持词级删除与多种语义块
AI 自动化	❌ 仅 README 规划	有限	✅ 转录 → LLM 生成 Master Config → 向量匹配 B-roll → WanX 生图
B-roll 覆盖	❌ 无	基础轨道叠加	✅ KEN_BURNS、PIP、FULL_SCREEN、SLIDE_IN、ZOOM_POP、MOSAIC 等 10 种展示方式
字幕/特效	❌ 无	基础字幕	✅ Remotion 模板 + 字幕动效（打字机、渐变边框、BURST 等）
音效	❌ 无	基础音频轨道	✅ segment 级音效配置，FFmpeg `adelay+amix` 混合
渲染导出	❌ 无渲染管线	客户端/云端渲染	✅ Remotion CLI 渲染 + FFmpeg 后处理
横竖屏分辨率	❌ 未涉及	通用	✅ `outputResolution` 统一配置，支持 16:9 与 9:16
插件系统	📋 规划中 plugin-first	有限	❌ 无插件机制，特效/模板硬编码
MCP / AI Agent 接口	📋 规划中	无	❌ 无
Headless / 批量渲染	📋 规划中	无	⚠️ Worker 任务队列可批量，但无公开 API/Scripting
移动端	📋 规划中	有 Web/移动端	❌ 不支持

三、技术架构对比

维度	OpenCut（重写版）	GeekCast
前端	React 19 + TanStack Router/Start + Tailwind v4 + shadcn/ui	Vue 3 + Vite + Pinia
后端	Elysia + Cloudflare Workers	Spring Boot 3 + Java 17 + MySQL + RocketMQ
桌面端	Rust + GPUI（Zed 同款）	无
核心渲染	未开始（目标：Rust core 跨 Web/Desktop/Mobile）	Python Worker + Remotion (React/TypeScript/Node) + FFmpeg
工程化	moonrepo + proto + Bun + Rust 工具链	Maven/Gradle + Python pip + Node npm
部署	Cloudflare Pages + Workers，边缘原生	本地/私有服务器，文件系统共享

四、OpenCut 优劣势

4.1 优势

开源 + 通用：MIT 协议，目标是"人人都能用的开源 Premiere/CapCut"，生态潜力大。
跨端野心：Rust core + Web/Desktop/Mobile 一套代码，若做成可避免重复开发。
AI/Agent 原生：规划了 MCP Server、Headless 模式、Scripting Tab，未来可能天然适配 AI 工作流。
现代化工具链：moonrepo、GPUI、TanStack、Elysia 都是当前较新的技术选型。

4.2 劣势

当前几乎空白：本地仓库只有 3 个空壳应用（Web 首页 Hello World、API 3 个健康检查端点、Desktop 一个窗口壳），没有实际剪辑能力。
工程风险高：Rust core 跨 Web(WASM)/Desktop/Mobile 的共享渲染、插件 ABI/WASM、移动端适配都是高难度目标，落地周期极长。
经典版割裂：README 自己都说当前能用的是另一个仓库 opencut-classic，重写版与经典版暂不兼容。

五、GeekCast 优劣势

5.1 优势

端到端可运行：从上传口播 → Whisper 转录 → 气口分析 → 精剪 → B-roll/特效/音效 → Remotion 渲染，整条链路已实现。
文本驱动降低门槛：不需要用户懂非线性剪辑，删除气口像删文字一样。
AI 链路完整：LLM 生成剧本/时间线、CLIP 向量匹配 B-roll、WanX 生图、提示词增强，自动化程度高。
视觉能力丰富：Remotion 模板、字幕动效、B-roll 多种展示方式、竖屏适配，成片风格统一。
强契约文化：ai_work/design/ 里有大量跨层契约、边界值、问题复盘，适合长期维护。

5.2 劣势

领域狭窄：只擅长"口播 → 短视频"这一类内容，无法做通用 Vlog、剧情片、多机位等复杂剪辑。
本地/Windows 中心化：很多路径、Chrome Headless、资产目录都是本地假设，难以直接 SaaS 化或多租户。
扩展性差：没有插件系统，新增特效/模板需要改 Remotion 代码并重新部署 Worker。
AI 瓶颈明显：LLM 输出 token 限制、AAC padding、B-roll 节奏等问题都依赖后处理和 prompt 调优。

六、结论与可借鉴点

你的场景	建议
想做一个通用、开源、社区化的视频编辑器	OpenCut 的方向更匹配，但要接受它目前只是脚手架，可能需要从 classic 版或自己重新设计核心。
想快速落地"口播/播客"自动剪辑	GeekCast 的架构和契约更成熟，可直接作为参考甚至基础。
GeekCast 想补齐 AI Agent / 批量渲染 / 插件能力	可以借鉴 OpenCut 规划中的 MCP Server、Headless CLI、plugin-first 架构，把 Remotion 模板做成可插拔配置。
OpenCut 想做出口播自动化功能	可以参考 GeekCast 的"视频即文本"工作流、Whisper+VAD 气口模型、Remotion+FFmpeg 渲染管线。

简而言之：OpenCut 是"想做通用编辑器的宏大蓝图"，GeekCast 是"在口播自动剪辑这个细分领域已经跑通的工程实现"。两者目前不在同一个完成度层级上，但互相有不少可借鉴的设计理念。

如果你在视频自动化、AI 剪辑或多模态生成方面有想法，欢迎在评论区交流。

idoubi 复盘笔记：从腾讯裸辞、一年 11 款产品到 MCP 生态头部玩家

Fri, 17 Apr 2026 14:00:00 +0800

idoubi 复盘笔记：从腾讯裸辞、一年 11 款产品到 MCP 生态头部玩家

idoubi（艾逗笔），前腾讯全栈工程师，2023 年 10 月 24 日裸辞，是国内 AI 独立开发者里最有代表性的样本之一。他的三篇年终复盘——《2023，我做过的 AI 项目》《2024，我追过的 AI 风口》《2025，MCP、Agent、AI Coding》——完整记录了一个技术人如何踩着每一次 AI 风口快速试错、再从「广撒网」收敛到「深耕」。这篇文章按时间顺序整理三篇复盘的内容，并提炼出可复用的经验和避坑点。

〇、为什么值得读他的复盘

和「成功学叙事」不同，idoubi 的复盘里失败项目占大多数，而且每个项目结尾都有诚实的得失总结：哪个赚了钱、哪个被流量反噬、哪个追到了风口却没能力做大。对想入局的个人开发者来说，这些信息量比「我月入十万」的故事大得多。

先看他三年多的整体节奏：

timeline
    title idoubi 独立开发时间线（2022.12 - 2026）
    2022.12 : 注册 ChatGPT<br/>开始 AI 探索
    2023 上半年 : chatgpt-webapi SDK 开源 : GPTalk 对话产品<br/>经历高光与流失
    2023.10 : 从腾讯裸辞
    2023.11 : GPTs Works 导航站<br/>第一个出海项目 : 开通 Stripe
    2023.12 : AI Wallpaper 壁纸生成器<br/>不温不火，后变成社群教程
    2024.01 : AI Cover 红包封面<br/>赚到几千块
    2024.02 : Sora FM 蹭 Sora 热点<br/>被流量反噬
    2024.03 : ThinkAny AI 搜索<br/>ProductHunt 日榜第四
    2024.04 : Melodisco AI 音乐<br/>一个月后放弃
    2024.05-10 : HeyBeauty 试衣 : Summary Copilot 摘要插件 : Pagen 落地页 : CroSearch 跨语言搜索 : PodLM 播客生成
    2024.11 : MCP.so 导航站<br/>押注 MCP 协议
    2024.12 : ShipAny AI SaaS 脚手架<br/>预售 4 小时破 1 万美金
    2025.02 : CopyWeb 网页复刻
    2025.03 : Manus 引爆 MCP<br/>MCP.so 流量暴涨
    2025.04-06 : 全力写书<br/>几乎没写代码
    2025.08 : 《这就是 MCP》出版<br/>预售霸榜计算机新书榜
    2025.09 : MCPRouter<br/>云端 MCP 路由平台
    2025 全年 : MCP.so 11M 访问 : ShipAny Two 发布 : 知了阅读获阿里云创客松冠军
    2026 方向 : Agent Infra + Agent 工厂<br/>ShipAny 做 Coding Agent 底座

一、2023 复盘：从「注册账号」到「裸辞」

原文：《2023，我做过的 AI 项目》（掘金），2024 年 1 月发布。

1.1 起点：一个账号和两个 SDK

注册 ChatGPT（2022.12）：当时注册门槛不低——要科学上网、要境外手机号收验证码。他用俄罗斯接码平台 sms-activate 解决，开始了 AI 探索。
chatgpt-webapi SDK：当时 ChatGPT 没有官方 API，他用 Chrome 控制台研究网页接口，写了一个模拟浏览器请求的 Go SDK（最初叫 chatgpt-go），在即刻发布后累计收获 140+ star。后来 OpenAI 上了 Cloudflare 验证，风控越来越严，对抗几次后只能放弃。
openai-go SDK：OpenAI 开放 GPT-3 API 后，他把开放平台接口封装了一层。也是用这个 SDK，他第一次用 AI 画图——生成了一直用到现在的全网头像。

1.2 GPTalk：第一次尝到「风口 + 先发优势」

GPTalk 是他面向国内用户的 AI 对话产品，完整经历了从爆发到流失的全周期：

flowchart TD
    A["微信客服/公众号接入 AI 对话"] --> B["不支持流式 + 易封号"]
    B --> C["重写 H5 版本"]
    C --> D["GPT-4 发布<br/>用模拟登录率先接入 GPT-4"]
    D --> E["即刻/V2EX 发帖推广<br/>3 月日 UV 大几千的高光时刻"]
    E --> F["人工注册 8 个 Plus 账号<br/>写调度程序支撑并发"]
    F --> G["GPT-4 API 正式发布<br/>所有竞品同时升级"]
    G --> H["先发优势消失<br/>用户慢慢流失"]
    H --> I["2023.08 后只维护不更新"]

    style E fill:#dcfce7,stroke:#166534
    style H fill:#fee2e2,stroke:#991b1b

这段经历里有三个很实在的教训（原文均有提及）：

模拟登录是沙上建塔：风控一升级，整条技术路线归零；
先发优势有保质期：GPT-4 API 一发布，靠「模拟登录拿到新接口」建立的壁垒瞬间消失；
他自己归因的流失主因是「不擅长推广营销」——这个短板他后来用「开源 + 复盘文章 + 社群」补上了，这是后话。

1.3 裸辞与出海起步

2023.10.24 从腾讯裸辞，开始自由职业。
GPTs Works（2023.11）：OpenAI 发布 GPTs 后做的导航站，他的第一个出海项目，由此开始用 NextJS 写 Web 项目、积累海外推广认知；同月开通 Stripe，实现全球收款。
AI Wallpaper（2023.12）：接 DALL-E 3 的 AI 壁纸站 + Mac 菜单栏应用。产品不温不火没赚到钱——但后来他做了「1024 全栈开发社群」，把这个项目录成 3 节课、近 8 小时的从 0 到 1 教学视频，带社群里的人做出了自己的 AI 产品。没赚钱的项目变成了课程资产，这是他「不浪费任何一个项目」打法的开端。

二、2024 复盘：一年 11 款产品，追着风口跑

原文：《2024，我追过的 AI 风口》（智源社区转载），2025 年 1 月发布。2024 年他做了将近 20 个项目（含半成品），正式上线的有 11 款，基本保持每月一个新产品的节奏。

2.1 完整项目清单

时间	项目	一句话说明	结局
2024.01	AI Cover	AI 微信红包封面生成器	赚了几千块，热度两周
2024.02	Sora FM	Sora 演示视频展示站	吃到流量，也被流量反噬
2024.03	ThinkAny	AI 搜索引擎	PH 日榜第四，月访 60w+，营收平衡
2024.04	Melodisco	AI 音乐播放器	一个月后放弃，开源
2024.05	HeyBeauty	AI 虚拟试衣	详见原文
2024.06	Summary Copilot	AI 摘要浏览器插件	详见原文
2024.08	Pagen	AI 落地页生成器	详见原文
2024.09	CroSearch	跨语言搜索引擎	详见原文
2024.10	PodLM	AI 播客生成器	详见原文
2024.11	MCP So	MCP Servers 导航站	押注 MCP 生态
2024.12	ShipAny	AI SaaS 开发脚手架	「卖铲子」的收官之作

2.2 四个重点项目的得失

AI Cover：无心插柳，赚到第一笔快钱

在星巴克给朋友演示 NextJS 时随手写的 demo，一条即刻动态发现需求强烈，当晚解析域名上线。临近过年访问量很大，接支付后赚了几千块。他的复盘结论很冷静：红包封面的最大卡点在微信平台审核，仅靠 AI 生成图片没法闭环，所以这类项目价值有限、做不大。（他也提到，后来微信放开红包封面售卖，这个方向可能有新机会。）

Sora FM：蹭热点的代价

Sora 演示视频发布后，他跟风做了展示站想提前占位，tagline 写了「Sora AI Video Generator」。项目开源后冲到 GitHub sora 关键词第一，但随后：

有人拿他的开源模板在视频号「代生成 Sora 视频」割韭菜，他写文章控诉，公众号两天 7 万阅读——成为他当时阅读量最高的文章；
但也有人骂他才是始作俑者：自己先打着「Generator」旗号虚假宣传。他想了想觉得有道理，连夜改成「Showcase」并删文；
最后 sora.fm 域名因品牌保护被 ban。

他的结论：「蹭品牌热度的项目，还是不做为好。短期的流量，不能长久。」

ThinkAny：追到了风口，但认清了边界

这是他 2024 年数据最好的产品，过程值得细看：

flowchart LR
    A["一个周末写完第一版"] --> B["第三天发布 ProductHunt<br/>日榜第四"]
    B --> C["海外博主自发推荐<br/>4 月 59w 访问 / 5 月 64w"]
    C --> D["写两万字行业复盘<br/>吸引投资人关注"]
    D --> E["6/7 月聊遍国内投资机构"]
    E --> F{"认清现实"}
    F --> F1["AI 搜索是大厂战略重心<br/>个人资源做不到市场领先"]
    F --> F2["大环境差，融资走不通"]
    F1 --> G["转向小而美路线"]
    F2 --> G
    G --> H["8/9 月成本优化<br/>实现营收平衡"]

    style B fill:#dcfce7,stroke:#166534
    style F fill:#fef3c7,stroke:#92400e

他自己总结：「2024 年的 AI 搜索风口，被我追到了。但是我没有能力把 ThinkAny 做大，因为自身的资源不够，实力不足，不能借力起势，略感遗憾。」——个人开发者能做出 60 万月访的产品，但「做到市场领先」需要的资源和资本是另一个量级。

Melodisco：验证失败的正确姿势

Suno v2 发布后他做了 AI 音乐播放器，收集了 2 万多首 AI 歌曲。但模型没开放 API（用户不能自己生成歌）、AI 曲风单调、平台方自己在做歌单广场——做了一个月判断「看不到希望」，果断停掉并开源。一个月试出一个伪需求，比硬撑一年便宜得多。

2.3 收官：从「做产品」到「卖铲子」

年底两个项目的方向变化很有意思：

MCP So（2024.11）：Anthropic 在 2024.11.25 发布 MCP 协议后，他快速做了 MCP Servers 导航站。他的判断：「MCP 未来可期，提前入局，是一个明智的选择。」——当时没人想到，这个项目会在 2025 年长成他最大的爆款。
ShipAny（2024.12）：AI SaaS 开发脚手架——把两年做 NextJS 产品的积累打包成模板卖给其他开发者。圣诞节上线预售，4 小时内销售额破 1 万美元，一周的收入超过其他产品一年的收入。从自己挖金子到卖铲子，这是独立开发者很典型的成熟路径。

他在 2024 复盘结尾的自我观察也值得一记：「一年过去了，我发现我越来越 i 了，下意识拒绝很多交流和合作。每天的时间有限……实在没有精力去维护太多关系。」——一人公司的隐性成本不只是钱，还有社交收缩。而在甲子光年的「请回答 2025」采访里，他说得更直白：「享受 ship 新产品的过程，也会因为做太多产品导致精力分散、没有代表作而感到迷茫。自由是把双刃剑。」——这句话直接预告了 2025 年的转向。

三、2025 复盘：收敛深耕——MCP、Agent、AI Coding

原文：《2025，MCP、Agent、AI Coding》（公众号「艾逗笔」，AI TNT 转载），2026 年 1 月发布。开篇他就说：前两年「把能做的 AI 产品都做了一遍，大多都是浅尝辄止……喧嚣过后，留下一堆遗憾」，所以 2025 年收敛了很多，不再追求产品数量，只聚焦三个方向：MCP、Agent、AI Coding。

3.1 MCP.so：pSEO 提前占位，等风来

这是 2025 年他最成功的一仗，完整过程堪称「导航站教科书」：

flowchart TD
    A["2024.11 底上线 MCP.so<br/>定位 MCP 服务器导航站"] --> B["抓取大几千个 MCP 服务器<br/>用 AI 做结构化总结<br/>批量生成 pSEO 页面"]
    B --> C["2025.01-03 持续更新<br/>同期跟风导航站陆续停更消失"]
    C --> D["2025.03 Manus 发布<br/>引爆 MCP 讨论<br/>大厂纷纷宣布支持"]
    D --> E["MCP 关键词搜索量暴涨<br/>MCP.so 凭积累排到搜索前列"]
    E --> F["马太效应：a16z 引用做行业报告<br/>自媒体自发推荐"]
    F --> G["2025.04 月访 2.7M<br/>全年 11M 访问 / 新增用户 1.5M"]

    style D fill:#dbeafe,stroke:#1e40af
    style G fill:#dcfce7,stroke:#166534

几个关键细节：

同期追热点的导航站都死了，只有他持续迭代了三个月——风口来时，位置是提前占好的，不是风口来了再抢的。
商业化反而保守：功能简单、留存不高，主要靠品牌广告（Trae、硅基流动、PPT.ai、Skywork、AlphaVantage 等），全年广告收入 1.2 万美金。
4 月有人出价 20 万美金收购 MCP.so，他没卖——想趁热打铁继续迭代，但自认因精力分散「没有做得更好」。
到 2025 年中，MCP.so 收录超 10000 个 MCP Server，支持网页直接调用和在线 Chat，被 InfoQ 称为「全球最大 MCP 应用市场」。

启示：11M 访问量只换来 1.2 万美元广告收入——流量大不等于生意好。他自己也清楚这一点，把「品控、用户粘性、商业化尝试」列为了 2026 年的改进项。

3.2 《这就是 MCP》：第一次出书的诚实账本

2025 年 3 月底，人民邮电出版社图灵教育找他写 MCP 的书（此前 GPTs 书、AI 搜索书两次合作都没成，第三次终于成行）。4-6 月他几乎没写代码，全力写书，7 月定稿，8 月正式出版，预售霸榜计算机新书榜 TOP1。

10 月他晒出第一笔版税，账本非常诚实：

版税收入 2.3 万元（三个月累计销售 3700 余册，在纯技术书里算不错）；
但他自购 1500 本送人（1024 社群、ShipAny 天使股东群等），支出 6 万多；
净现金流约 -4 万，要卖到 1 万册才回本。

他的总结很清醒：「从经济学的角度来说，ROI 没打正，是一笔亏本的投资。从心理学的角度来说，解锁了一类新的成就感。快乐无价。」——出书是品牌资产和信任投资，不是现金流生意。

3.3 MCPRouter（2025.09）：把 MCP 的使用门槛打下来

MCP 最大的痛点是上手门槛：用户要拉代码、装依赖、配环境。他做的 MCPRouter 是一个纯云端的 MCP 路由平台：后端 K8s 集群部署常用 MCP 服务器，前端只要一个 API Key 就能调用。本质是做「基于 MCP 的原子能力平台」，让 Agent 按需挂载工具，专注业务逻辑。他明确说这是 2026 年的重点投入方向。

3.4 「MCP 会不会凉？」：一次协议级趋势判断

2025.10 Anthropic 发布 Agent Skills 后，很多人问 MCP 是不是要凉。他的判断是不会，两点理由值得记：

MCP 是连接器，对标的是 HTTP：厂商基于 MCP 开放能力，AI 应用基于 MCP 挂载工具，普通用户不需要感知 MCP——它本来就该是幕后角色。Agent Skills 解决的是上下文管理问题，两者不是替代关系。
MCP 是原子能力的包裹器：模型数量有限，能力数量无限。每个 MCP 工具的定义相当于给 API 写了一份使用文档，广播给整个 AI 互联网；Skills 是给 Agent 的流程说明书，对外部工具的调用只是流程的一部分——Skills 是 MCP 的补充。

3.5 Agent 三大件：Framework、Tools、Sandbox

2025 是 Agent 元年，Manus 被 Meta 以 20 亿美金收购成为标志性事件。他研究了市面知名 Agent 产品后，把底层构成拆成三大件：

flowchart LR
    subgraph AGENT["一个 Manus 级别的 Agent 产品"]
        F["Framework 框架<br/>Plan / Act / Memory<br/>上下文管理"]
        T["Tools 工具箱<br/>浏览器 / Shell / 文件<br/>搜索 / TTS 等原子能力"]
        S["Sandbox 沙盒<br/>隔离运行 + 步骤可视化<br/>human-in-the-loop"]
    end
    F --> T --> S

    M["MCPRouter<br/>= 他的 Tools 解法"] -.-> T
    SH["ShipAny 的经验<br/>启发 Framework 解法"] -.-> F
    Q["卡点：Sandbox 部署接入最难<br/>期待更轻量的方案"] -.-> S

他的目标很具体：2026 年做出一个 Agent 开发框架，让开发者「一天内上线一个 Manus 级别的 Agent 产品」——就像 ShipAny 让人「一小时上线 AI SaaS」一样。

3.6 AI Coding：CopyWeb 的意外与赛道观察

CopyWeb（2025.02）：截图/网址复刻网页。初版只是 Workflow 没有 Agentic，没持续迭代也没推广，全靠自然增长，2025 年 ARR 却到了 2.4 万美金——「有点意外」。
对照组是硅谷的 Same：同样做网页复刻，3 个 05 后少年，零投流四个月做到 300 万美金 ARR。
赛道格局：Claude Code（终端 Agent，6 个月 10 亿美金 ARR）vs Lovable（Web Agent），窗口期已过，后来者只能从垂类场景（CopyWeb 改造为 Coding Agent）和基于模板的增量填充（ShipAny 做 Coding Agent 底座）切入。

3.7 个人状态：与自己和解的一年

知了阅读拿了阿里云第二届创客松冠军；在 GTLC、AICon 两个大会做分享，拿了明星讲师；
遇到了很欣赏他、愿意投资他做产品的人——虽然最终没有拿钱；
去了济州岛，通关了黑神话悟空，体重从 150 瘦到 135。

结尾那段话是他三年心态的落点：「不喜欢社交就不社交，组不了团队就独立开发，拿不到投资就自己赚钱，不想专注就广泛尝试。与其求而不得，感受痛苦；不如顺其自然，享受自由。」

四、2026 展望：Agent Infra + Agent 工厂

他在 2025 复盘里立下的 2026 方向：

围绕 Framework、Tools、Sandbox 做一套好用的 Agent Infra；
Agent 工厂：把过去两年试过的产品都改造成 Agent，跑在自己的 Agent Infra 上；
MCP.so 继续投入：做好品控、筛选推荐优质 MCP 服务器、扩展 Skills 品类、提高用户粘性、做更多商业化尝试；
MCPRouter 重点投入：走精品路线，整合供应链（对接下游平台、监控余额、建立供应商合作）；
ShipAny 成为 Coding Agent 的基础底座，让 Coding Agent 的交付质量上一个台阶；
时间允许的话，写一本全栈开发的书。

截至目前（2026 年中）能观察到的外部信号：海外媒体已经把「ShipAny + MCP.so」作为中国独立开发者的代表案例进行分析，评价其护城河是「个人品牌 + MCP.so 先发流量生态 + 模板库与口碑」，同时也指出风险——买断制授权复购弱、收入天花板明显。这和《小而美》里「持续盈利能力 > 一次性爆款」的命题正好互文。

五、模式解构：idoubi 的「项目飞轮」与 2025 年的进化

把三年复盘合起来看，他跑的是一个复利循环，而不是孤立地做项目：

graph TD
    A["快速做项目<br/>每月一个的节奏"] --> B["代码开源<br/>GitHub 占位 + 口碑"]
    B --> C["写复盘文章<br/>公众号 / 即刻传播"]
    C --> D["积累影响力与信任"]
    D --> E["社群 / 课程 / 脚手架 / 出书<br/>影响力变现"]
    E --> F["新项目获得冷启动流量"]
    F --> A

    G["每个项目本身<br/>小额收入 / 验证需求"] -.补充.-> A

    style A fill:#dbeafe,stroke:#1e40af
    style D fill:#fef3c7,stroke:#92400e
    style E fill:#dcfce7,stroke:#166534

这个飞轮解释了为什么他单个项目大多「不温不火」，整体却越走越稳：项目的直接收入是小头，开源占位、复盘传播、社群、脚手架和出书这些「副产品」才是复利。

2025 年的变化是飞轮的「收敛版」：不再每月一个新项目，而是围绕一个协议级判断（MCP）做深三件套——导航站（流量）、书（信任）、路由平台（基础设施）。同一个主题下「产品 + 内容」两条腿，每一份投入都在给另外两份加杠杆。这比他 2024 年「广撒网」的玩法高了一个段位。

六、避坑清单：从他的 20+ 个项目里提炼

6.1 技术与产品

模拟登录/逆向接口不能做地基（chatgpt-webapi、GPTalk 的死法）：平台风控一升级，整条路线归零，只能当临时手段。
依赖第三方审核的业务无法闭环（AI Cover）：卡点在微信审核，AI 只解决了生成环节，生意做不大。
没有 API 的生态别急着做应用（Melodisco）：模型方不开放生成能力，应用层只能做「播放器」，核心价值被捏在上游。
先发优势按天计算（GPTalk）：官方 API 一发布，灰色壁垒瞬间清零。吃到红利时就要想好下一步。

6.2 流量与品牌

别蹭品牌词（Sora FM）：域名被 ban、被骂虚假宣传、流量反噬——短期流量不能长久，还有法律风险。
开源是把双刃剑：模板会被人拿去割韭菜，但开源也给他带来 GitHub 占位和口碑——关键是自己别越界。
「不擅长营销」可以补：他早期的短板靠「开源 + 复盘文章 + 社群」的系统化打法补上了，内容即渠道。
流量大 ≠ 生意好（MCP.so）：11M 年访问只变现 1.2 万美金广告。流量资产要趁早想清楚留存和商业化路径，否则只是好看的面板数据。
风口是等来的，不是追来的（MCP.so）：同期跟风导航站全死了，活下来的是提前三个月做 pSEO 积累、持续迭代的那一个。占位要早，更新要久。

6.3 战略与心态

风口追得到，不等于接得住（ThinkAny）：60 万月访也撑不起一个需要重投入的赛道。个人开发者要诚实区分「产品验证成功」和「有能力做大」。
快速放弃是技能不是失败（Melodisco 一个月、ThinkAny 放弃融资幻想）：每月一个项目的节奏本身就要求果断止损。
没赚钱的项目也是资产（AI Wallpaper 变教程、两年积累变 ShipAny、MCP 研究变出书）：代码可开源、经验可成文、模式可打包——前提是你每次都做了复盘。
出书是品牌投资不是现金流生意（《这就是 MCP》净现金流 -4 万）：想清楚你要的是版税还是「作者」这个 title 带来的长期信任。
做太多产品会「没有代表作」：他 2024 年最大的迷茫来自精力分散；2025 年收敛到三个方向后反而做出了爆款。广撒网是探索期的打法，不是终局打法。
收购报价是免费的市场定价（MCP.so 被出价 20 万美金）：哪怕不卖，它也告诉你资产的市场公允价值，是继续做还是放手的决策参考。
对技术趋势要有自己的判断框架（MCP vs Agent Skills）：随大流喊「凉了」或「颠覆」都容易，难的是说清楚两者各自的定位——判断对了才敢在回调期继续投入。
注意社交收缩的隐性成本：他自述「越来越 i」，一人公司需要主动维护同类连接，否则信息和情绪都会枯竭。好在他 2025 年的解法是「与自己和解」而不是硬撑。

七、给新人的三个观察

他的起点极其普通：一个接码平台注册的账号、一个 140 star 的 SDK。没有谁一开始就「准备好了」，都是边做边攒。
节奏比单点重要，但节奏会进化：2024 年「每月发布一个产品」是给自己创造「每月一次摸彩票的机会」；2025 年收敛成「一个主题做深三件套」。先广撒网找手感，再收敛做深耕——两个阶段都是对的，错的是一直停在同一个阶段。
先解决收款和闭环：Stripe 在第一个出海项目当月就开通了；AI Cover 当天就接了支付；ShipAny 用预售 4 小时破万美金验证付费意愿。能收到钱，一切验证才有意义。

参考资料

AI 产品 MVP 开发：我如何用 4 个月做出飞天猫

Mon, 23 Mar 2026 18:00:00 +0800

AI 产品 MVP 开发：我如何用 4 个月做出方糖猫

方糖猫是我从 0 到 1 主导的一个 AI 视频生成平台。从有想法到第一个版本上线，花了大约 4 个月。这篇文章会复盘整个 MVP 开发过程，包括当时做了什么对的决定、犯了什么错、以及如果重来我会怎么改进。

一、为什么要做方糖猫

1.1 观察到的痛点

2025 年前后，我身边很多朋友开始做短视频：

有人做知识科普，但剪辑太慢，一周只能出 2-3 条
有人做口播，但画面单调，自己又不会做 B-roll
有人做产品宣传，请不起专业剪辑团队

大家共同的需求是：用更短的时间、更低的成本，做出一条能看的短视频。

1.2 技术时机成熟

当时几个关键技术已经可用：

大模型：DeepSeek / GPT 能写脚本、做规划
语音识别：Whisper 能生成词级时间轴
TTS：多种中文配音模型质量可用
视频渲染：Remotion 让程序化渲染变得可行

这让我觉得，一个「文案 → 视频」的自动化平台有机会做出来。

1.3 要做的产品

一句话定义：

用户输入一段文案，系统自动匹配素材、生成配音、渲染成短视频。

二、MVP 范围定义

2.1 核心场景

我们锁定了第一批目标用户：知识类口播创作者。他们的视频结构相对固定：

开头点题
中间展开 3-5 个要点
结尾总结

这种结构最适合自动化处理。

2.2 MVP 功能边界

做：

文案输入
AI 生成故事板
自动匹配本地素材库
TTS 配音
Remotion 渲染
基础前端编辑

不做：

用户自定义复杂动画
多轨音频编辑
多人协作
付费订阅系统
移动端 APP

2.3 为什么敢砍这么多功能

MVP 的核心目标是验证：用户愿不愿意为「文案 → 视频」这个核心流程付费。

如果核心流程没人用，再多的周边功能也没用。如果核心流程有人用，周边功能可以慢慢加。

三、四个月开发节奏

第一个月：核心链路跑通

目标：让一条文案能生成一个最粗糙的视频。

工作：

搭建 Spring Boot 3 + Vue 3 基础项目
接入 DeepSeek API，让 LLM 根据文案输出故事板
用 Remotion 渲染最简单的画面：标题卡 + 说话人占位图 + 字幕
用 edge-tts 生成配音

里程碑：输入一段 100 字文案，5 分钟后拿到一个能播放的视频。

第二个月：素材库和编辑能力

目标：让视频能看，用户能微调。

工作：

搭建 RAG 素材库（ChromaDB + BGE-M3）
根据文案语义自动匹配图片/视频素材
前端增加故事板编辑：替换素材、调整文案、修改标题
接入阿里云 OSS 存储成片和素材

里程碑：生成的视频不再是「占位图」，而是有真实素材的「半成品」。

第三个月：稳定性和产品化

目标：从「能跑」到「能用」。

工作：

渲染任务接入 RocketMQ，支持多 Worker
增加 SSE 实时进度推送
用户注册登录、任务历史记录
错误处理和降级策略
横竖屏多分辨率输出

里程碑：邀请 5-10 个目标用户内测，他们能独立使用。

第四个月：上线和迭代

目标：正式对外开放，收集真实反馈。

工作：

域名备案、服务器部署
基础运营后台
用户反馈收集和快速修复
发布 1.0 版本

里程碑：ftmao.com 正式上线，有真实用户注册使用。

四、技术栈选择

层级	技术	选择理由
前端	Vue 3 + Vite + Pinia	团队熟悉，开发效率高
后端 API	Spring Boot 3 + Java 17	业务系统稳定性好
AI Worker	Python 3.11 + FastAPI	AI 生态丰富
数据库	MySQL + Redis	成熟稳定，团队熟悉
向量库	ChromaDB	部署简单，适合 MVP
消息队列	RocketMQ	负载均衡和重试机制完善
对象存储	阿里云 OSS	国内访问快
渲染	Remotion + FFmpeg	组件化渲染 + 强大后处理
LLM	DeepSeek	性价比高，中文效果好

4.1 有没有后悔的选型

暂时没有大后悔的：

Java + Python 双栈增加了复杂度，但确实是当时最优解
ChromaDB 在数据量大了以后可能会换 Milvus，但 MVP 阶段完全够用
Vue 3 + Spring Boot 是稳妥选择

唯一值得反思的是：

过早引入了 RocketMQ。其实前两个月用 HTTP 轮询也能支撑，第三个月再切队列压力更小。

五、内测与反馈

5.1 如何找到早期用户

朋友圈和抖音播客粉丝中筛选做内容创作的人
主动私聊，邀请试用
不收费，只要求反馈

5.2 收集到的关键反馈

反馈	我们的反应
「生成的视频节奏太慢」	优化故事板时长计算，增加紧凑模式
「素材匹配不够精准」	优化 RAG 召回策略，增加查询改写
「配音太机械」	测试多个 TTS 模型，增加情感参数
「希望能导出字幕文件」	增加 SRT 导出功能
「不会写文案」	增加 AI 文案扩写功能

5.3 哪些假设被推翻

原本以为用户最在意「视频质量」，实际上最在意「等待时间」。

用户可以接受视频不完美，但如果要等 10 分钟以上，很多人就直接放弃了。

这让我们把优化优先级从「画质」转向了「渲染速度」和「队列调度」。

六、犯的错误

6.1 过早做通用化

第二个月时，我想让平台支持多种视频类型：口播、科普、剧情、广告。结果为了兼容各种场景，架构变得复杂，核心口播场景反而没做好。

教训：MVP 只服务一个细分场景，做深再做广。

6.2 忽视前端体验

前三个月我主要精力放在后端和 AI 流程上，前端做得很简陋。内测用户反馈「不知道点哪里」。

教训：产品是给用户用的，不是给工程师自己看的。前端体验至少要做到「不迷路」。

6.3 没有尽早建立数据看板

上线后我不知道用户的真实使用情况：平均生成多少条、平均等待多久、失败率多少。

教训：MVP 阶段也要有基础埋点和看板，否则无法判断产品健康度。

6.4 低估了合规和成本

TTS、LLM、OSS、CDN、服务器，每一项都是按量付费。上线第一个月没注意控制，账单超出预期。

教训：MVP 阶段就要做成本预算和限额，避免烧钱不自知。

七、如果重来，我会怎么做

7.1 第一个月就用真实用户测试

不需要等 4 个月再邀请用户。第一周就可以给目标用户看原型图，第二个月就可以给粗糙版本试用。

7.2 更早砍掉非核心功能

比如「用户自定义动画」「多分辨率导出」这些，其实可以晚两个月再做。

7.3 更早做数据埋点

从第一天就记录：

用户从进入网站到生成视频的转化率
每个步骤的流失率
生成成功率和平均耗时

7.4 更克制地引入中间件

消息队列、向量库这些都可以先用简单方案顶上，等真的成为瓶颈再升级。

八、上线后的数据

（待补充真实数据）

指标	数值
上线时间	2026 年 X 月
注册用户	X
累计生成视频	X 条
平均生成耗时	X 分钟
生成成功率	X%
付费转化率	X%

九、对技术创业者的话

9.1 技术不是壁垒，产品化才是

会用 LLM、会调 Whisper 的人很多。但能把这些技术做成稳定、可用、有商业价值的产品的人很少。

9.2 不要等完美了再上线

第一个版本一定很丑、很慢、很多 Bug。但只要核心流程能跑通，就值得给用户看。

9.3 找到愿意骂你的用户

夸你的用户没价值，愿意指出问题的用户才是真用户。把他们服务好，产品会越来越好。

9.4 控制成本

AI 产品的边际成本不低，尤其是调用大模型和渲染视频。MVP 阶段就要算清楚账。

十、总结

方糖猫的 MVP 开发让我真正理解了「从 0 到 1」的含义：

范围要狠：只做一个场景，一个核心流程
速度要快：4 个月不算短，但可以更短
用户要早：从第一天就找目标用户
数据要全：用数据判断产品方向
成本要控：别让自己死在黎明前 https://gitee.com/soulnew/geekcast 如果你也在做 AI 产品的 MVP，希望我的经验能帮到你。

关于 AI 产品化、MVP 开发，如果你有问题，欢迎在评论区交流。

我从华为到 AI 创业：一个 18 年老程序员的转型复盘

Tue, 20 Jan 2026 16:00:00 +0800

从华为到 AI 创业：一个 18 年老程序员的转型复盘

我今年 39 岁，做了 18 年软件研发，其中华为 8 年、IBM 2 年。最近四年，我从传统后端架构转向 AI 工程化落地，主导了两个 AI 视频生成平台从 0 到 1。这篇文章不是成功学，是一次诚实的复盘。

一、我的职业路径

2008 - 2010：国信朗讯，Java 开发组长
2010 - 2012：IBM，欧美项目 Java 开发
2012 - 2019：华为，高级软件工程师 / 项目经理
2021 - 2025：成都**科技，研发总监
2025 - 至今：AI 创业，做方糖猫 / GeekCast Engine

前三段经历让我成为了一名「合格的后端工程师」：

会写代码，懂架构，能带队
熟悉电信、金融、企业软件等领域
经历过大型项目交付和海外客户对接

但我逐渐意识到一个危险信号：我熟悉的技能栈，正在被更快地标准化和规模化。华为和 IBM 能培养出很多像我这样的人，稀缺性在下降。

二、为什么转向 AI？

2.1 不是追风口，是被问题驱动

2023 年前后，我开始认真用大模型辅助工作。最初只是让 GPT 帮我写代码、改 Bug，后来尝试让它帮我：

分析需求文档
自动生成技术方案
做 Code Review

效果让我震惊。不是因为它每次都正确，而是因为它让我重新思考：工程师的核心价值到底是什么？

如果写代码本身可以被自动化，那我还应该继续以「写代码快」为荣吗？

2.2 我看到的机会

我观察到几个明确的变化：

内容创作门槛在降低。AI 可以写文案、画图、配音、剪视频。
但工程化落地门槛很高。把多个 AI 能力串成稳定可用的产品，需要既懂 AI 又懂工程的人。
小团队也能做大事。几个人用现代 AI 工具，能完成以前需要几十人做的事。

这让我决定：从「帮助企业做系统」转向「用 AI 做产品」。

三、转型过程中的三个认知变化

3.1 从「写代码」到「定义问题」

在华为和 IBM，我的任务通常是明确的：需求来了，分析、设计、开发、测试、上线。问题边界相对清晰。

但做 AI 产品完全不同。没人告诉你该做什么，你需要自己回答：

用户真正愿意付费的痛点是什么？
这个场景 AI 能不能解决好？
做到什么程度可以上线？

我花了大量时间在「定义问题」上，而不是「写代码」。

3.2 从「追求技术先进」到「追求产品可用」

做后端架构时，我很喜欢研究新技术：新框架、新中间件、新协议。总觉得用新东西代表能力强。

做 AI 产品后，我被迫变得更务实：

用 DeepSeek 还是 GPT，不是谁先进，而是谁够用、谁便宜、谁稳定。
用 RocketMQ 还是 RabbitMQ，不是谁新，而是团队谁熟悉、运维成本谁低。
产品能不能跑通，比用了什么模型更重要。

3.3 从「单点优化」到「系统思维」

AI 产品的链路很长：Prompt → LLM → 输出解析 → 工具调用 → 素材检索 → 渲染 → 后处理 → 交付。

任何一个环节出问题，整个产品就不可用。我需要关注的是：

端到端成功率
单次生成成本
用户等待时间
失败后的恢复体验

这比优化单个接口的 QPS 复杂得多。

四、我如何补齐 AI 能力

4.1 理论学习：快速建立地图

我没有去读大量论文，而是先做「地图式学习」：

了解 LLM 能做什么、不能做什么
了解 RAG、Agent、Fine-tuning、Prompt Engineering 各自的适用场景
了解常见的模型 API 和开源生态

推荐的学习资源：

DeepLearning.AI 的《LangChain for LLM Application Development》
《Building LLM Apps》
OpenAI、DeepSeek、Claude 的官方文档和最佳实践

4.2 动手实践：做项目而不是跑 Demo

我最大的经验是：只看教程学不会 AI 工程，必须做真实项目。

我做的第一个项目不是听课做的，而是直接基于业务需求启动：

用 DeepSeek API 做口播视频的视觉规划
用 Whisper 做字幕生成
用 Remotion 做视频渲染

每一个功能都是从真实问题出发，而不是从教程章节出发。

4.3 工具链迁移

作为 Java 后端工程师，我过去很少用 Python。但 AI 生态基本在 Python 里，所以必须迁移：

原技能	新增技能
Java / Spring Boot	Python 3.11
MyBatis / Hibernate	FastAPI / SQLAlchemy
RocketMQ / Kafka	继续用，但用 Python 客户端
Docker / K8s	继续用，部署 Python Worker
Vue 3	继续用，前端不变

这个迁移没有想象中难，大概 2-3 个月就能处理日常 AI 工程需求。

4.4 建立输出习惯

我开始写技术博客、做抖音 AI 科普账号。输出倒逼输入，让我学得更快。

输出还有一个好处：让市场验证你的能力。面试时，你写的文章、做的项目比简历上的文字更有说服力。

五、踩过的坑

5.1 技术选型追新

刚开始做 AI 产品时，我什么都想试试：LangChain、LlamaIndex、AutoGPT、CrewAI……

结果很多时间花在折腾工具上，而不是解决用户问题。

教训：先用手边最熟悉的工具把产品跑起来，再考虑要不要换。

5.2 产品自嗨，没有 early user

GeekCast Engine 早期我做了很多功能：自动加字幕、自动加 B-roll、自动配乐……

但去找用户聊的时候发现，很多人只需要「删掉气口和语气词」这一个功能。

教训：做产品前先找到愿意用的人，用最小功能验证需求。

5.3 过度工程化

因为有大厂背景，我习惯把架构设计得很完整：微服务、消息队列、分布式渲染、监控告警……

但早期用户量不大，很多设计是过度工程。

教训：MVP 阶段先单体，验证后再拆分。

5.4 低估产品化成本

AI demo 和产品之间差距很大。一个 demo 可能 2 天做完，产品化需要解决：

边界情况处理
失败恢复
用户权限
成本优化
多分辨率兼容
前端体验

这个差距，我最初低估了至少 3 倍。

六、转型后我得到了什么

6.1 新的职业定位

我不再只是一个「Java 后端工程师」或「研发总监」。我现在可以自称：

AI 工程负责人
AI 产品经理
技术创业者

这个定位在市场上更有差异化。

6.2 更强的系统能力

做 AI 产品让我不得不关注全链路：

用户体验
模型成本
渲染性能
数据闭环

这种系统能力，是大厂螺丝钉岗位很难训练出来的。

6.3 更清晰的自我认知

我知道自己不擅长什么：

我不擅长纯学术研究
我不擅长从 0 训练大模型
我不擅长做 toC 增长

我也知道自己擅长什么：

把 AI 能力工程化落地
设计可扩展的系统架构
带领小团队快速交付产品

这种认知让我在求职和创业中少走弯路。

七、给同龄工程师的建议

7.1 不要被年龄绑架

39 岁不是终点。AI 是一个新赛道，大家的起跑线差距没有那么大。关键是你愿不愿意重新学习。

7.2 不要迷信大厂光环

大厂经历是背书，但市场最终看的是你能否解决问题。光环会褪色，能力不会。

7.3 用项目证明能力

转型 AI，最有效的简历不是证书和课程，而是真实项目。哪怕是一个小工具，能跑通、能讲清楚，就胜过 100 节网课。

7.4 持续输出

写博客、做视频、开源代码，让别人看到你的思考和作品。这比投 100 份简历更有效。

7.5 找到差异化定位

AI 赛道很卷，但「懂 AI 又懂工程、有产品落地经验」的人还不够多。这是老程序员的机会。

八、我现在在哪里

我正在做两件事：

继续迭代方糖猫 AI 视频平台，把文案到成片的自动化做得更稳、更便宜。
输出更多 AI 工程实践内容，倒逼自己持续学习，也帮助更多传统工程师转型。

如果说 18 年前我进入这个行业是因为喜欢写代码，那现在我留下来，是因为我相信：AI 会让每一个有工程能力的人，都能做出以前无法想象的产品。

九、总结

从华为到 AI 创业，我的转型不是一帆风顺的，但回头看，有几个关键选择是对的：

不把自己局限在 Java 后端，主动学习 Python 和 AI 生态
不做课程收藏家，用真实项目驱动学习
不追新技术，先用熟悉工具把产品跑通
不放弃输出，用博客和项目建立个人品牌
不害怕年龄，把经验变成差异化优势

如果你也在考虑转型 AI，希望我的经历能给你一些参考。

关于职业转型、AI 工程化，如果你有问题，欢迎在评论区交流。

硬地骇客播客笔记：AI 时代，个人开发者怎么拥有自己的小生意

Wed, 17 Sep 2025 10:00:00 +0800

硬地骇客播客笔记：AI 时代，个人开发者怎么拥有自己的小生意

2023 年到现在，AI 从热点变成了基础设施。这波浪潮里确实有一批个人开发者赚到了钱，但更多的人悄悄回到了工作岗位。这篇文章整理「硬地骇客」两期播客（EP64、EP105）的内容——包括嘉宾背景、方法论和案例——配上解构图和流程图，帮刚入门的朋友建立一张「个人小生意」的完整地图。

说明：文中内容来自两期节目的官方 shownotes、硬地笔记，以及小宇宙公开的单集文稿片段。个别段落官方页面只给了话题标题没有文字展开，这类位置都标注了「需听原音频」，绝不替主播编观点。

〇、这两期播客是什么

EP64《AI 时代每个人如何拥有自己的小生意》：硬地骇客串台「十字路口 Crossing」（主播 Koji 是新世相/躺岛联创，Ronghui 供职于科技 VC、前《第一财经周刊》驻硅谷记者），对谈嘉宾是 Saito——播客「硬地骇客」与 AI 播客产品 Podwise 的联合创始人。他做播客、创业、写书，同时构建了中国最活跃的独立开发者社区之一。Podwise 据公开资料两个月做到 1.2 万美元 ARR（年度经常性收入），团队把这段经历写成了书《硬地骇客 - 两个月 $12000 ARR 实践之路》。

EP105《你的想象力和行动力，正在限制你通过 AI 创作搞钱》：硬地骇客自己的节目，主题是 AI 内容创作（文字、图片、语音、视频）的商业化——从 MiniMax Audio 的语音合成，到 AI 自媒体团队狂接商单的真实案例。按官方前言，这期想回答的是「AI 的成本、用户参与模式，以及各种 AI 内容创作的精彩案例」。

两期放在一起听正好互补：EP64 讲「怎么活下来」（方法论 + 现实数据），EP105 讲「机会在哪」（案例 + 想象力）。

一、EP64 完整笔记：小生意的方法论与现实

节目分三个部分，以下按内容板块整理。

Part 1：硬地骇客团队的故事

三个创始人从相遇到首次创业的经历，以及为什么决定做「硬地骇客」这档独立开发者故事播客。
一个有意思的心态变化：再次创业时内心平和了很多——第一次创业的焦虑很大部分来自未知，第二次知道坑在哪里。
Saito 在哪里观察独立开发者的日常状态，以及「硬地访谈」栏目的由来。

Part 2：把创业经验写成书

这是全期信息密度最高的部分，核心问题是：Podwise 如何在两个月做到 1.2 万美元 ARR？

营销与增长心得（Saito 营销总结的一段）：

去杠杆高的地方做营销：同样的内容，发在杠杆高的平台（有推荐算法、有长尾搜索的地方）效果差十倍。
去有论坛的地方：互动、回复有营养的内容，抓住长尾流量：不是发完帖就走，而是在社区里持续贡献有价值的回复，这些回复会长期被搜索到，带来稳定的长尾曝光。
内容营销三原则：好内容要同时满足——喜闻乐见、感同身受、对我有用。只做到一条的内容传播力有限。

产品与 PMF 部分：

做产品前要先懂的「关于大模型必须知道的 5 件事」（具体五件事见原音频/原书）。
Podwise 的灵感是怎么找到的，过程中放弃过哪些想法——选题的排除过程和选中过程同样重要。
为什么最终做了 Podwise：自身就是播客重度用户，痛点是真的。
找 PMF（产品市场契合）的几点关键步骤。
「Indie Hacker 是不是不需要产品经理了」——一个人更得同时扮演两个角色。
一句被反复引用的话：「做 AI 产品的这个产品，它首先得是一个产品」。AI 是能力，不是价值本身；用户为解决的问题付费，不为模型付费。

Part 3：对独立开发者人群的观察

这部分是 Saito 泡在国内最活跃的独立开发者社区里的长期观察，也是全期最「泼冷水」的内容：

收入分布：国内最赚钱的独立开发者（工作室级别）年收入千万以上，但从整个群体看，大约 0.9% 的人够温饱，0.1% 的人活得舒服，绝大部分人没赚到钱。
焦虑与自由：大部分人由于没有积蓄或固定收入支撑，会在半年到一年内回到工作岗位。如果独立开发者人人都赚钱，反而不正常——你看到的都是做得好的故事。
两个成功案例：
- 沉浸式翻译创始人欧文：浏览器翻译插件，国内独立开发者出圈的标杆案例。
- 极简时钟创始人道哥：一个极简的时钟 App，靠长期迭代和口碑做成稳定收入。
成功者的共同特点，Saito 的原话：「我接触的独立开发者什么人都有。有一些是很积极行动的，有机会立马冲上去。还有像欧文那种，做自己想做的也成了。」——这个群体不是「默不作声每天写代码」的单一画像，而是众生相；他接触到的人里面绝大部分是工程师出身。
最大挑战与给新人的建议，硬地笔记里沉淀的两条：
1. 不要为了「独立开发」而「独立开发」，不然很容易受打击；
2. 找一些 easy to target 的领域去做（你知道从哪里能接触到你的目标用户），比做「大」的事更靠谱。
做得好但还没被看到的产品和宣传做得不够好的产品的共同特点——很多产品死不是死于质量，而是死于没人知道。
自己成为 KOL 的好处：还在观望的人，先赶紧输出内容，然后 build in public（公开构建）——把开发过程本身变成内容。节目以 @levelsio（Pieter Levels） 作标杆——独立开发者精神和商业的践行者。这个方法论在硬地骇客其他期里有更完整的展开：
- EP58 里 HeyForm 创始人百顺说：「build in public 是所有独立开发者应该去尝试和使用的……它不是一个关于产品的构建方式，它是关于创始人个人 IP 的创建方式。重点是构建自己的影响力、公信力，然后带动产品的增长。」
- EP12 讨论了「public 到什么程度」：不是把底裤都扒了——build in public 的目的是构建自己的社区、和用户建立连接与信任，公开什么内容、什么时候公开，都从这个目的倒推。

graph TD
    A["EP64 核心结构"] --> P1["Part 1 团队故事<br/>再次创业，心态平和"]
    A --> P2["Part 2 方法论<br/>Podwise 两个月 $12k ARR"]
    A --> P3["Part 3 群体观察<br/>0.9% 温饱 / 0.1% 舒服"]

    P2 --> M1["营销：去杠杆高的地方"]
    P2 --> M2["营销：论坛互动抓长尾流量"]
    P2 --> M3["内容三原则：<br/>喜闻乐见 / 感同身受 / 对我有用"]
    P2 --> M4["产品：AI 产品首先得是个产品"]

    P3 --> O1["成功案例：沉浸式翻译·欧文"]
    P3 --> O2["成功案例：极简时钟·道哥"]
    P3 --> O3["共同特点：积极行动派<br/>绝大部分是工程师出身"]
    P3 --> O4["解法：输出内容<br/>build in public"]

    style A fill:#fef3c7,stroke:#92400e
    style P2 fill:#dbeafe,stroke:#1e40af
    style P3 fill:#fee2e2,stroke:#991b1b

二、EP105 完整笔记：AI 内容创作的钱在哪

这期的主线：AI 不只是工具，更是激发创造力的伙伴。按「硬地笔记」的话题板块整理：

AI 内容创作的新机会与商业化应用：AI 把内容生产的门槛和成本同时打下来，原来不成立的生意开始成立。Labubu 动态壁纸的案例就出现在这段（详见下文）。
成本与商业模式探讨：当生成成本趋近于零，商业模式的重心从「生产」转向「分发和定价」。
AI 语音生成（TTS）的成本优势与应用场景：重点讨论了 MiniMax Audio，主播评价其 TTS 效果「全球领先」。应用场景包括 AI 生成语音、小宇宙的英文播客翻译功能等。
AI 产品的用户群体与产品模式：这段实际讨论的是用户参与模式——用户在 AI 生成循环里的位置。主播区分了两种产品形态：in the loop（人深度参与生成循环，保留创作者的独特性）和 on the loop（人站在循环之上，直接享受 AI 生成的成果）。主播反思他们自己的新产品 Castwise 沿用 Podwise 的模式「其实是不太对的」——因为创作者不在循环里，「没办法加入我作为创作者的独特性」。换句话说：全自动产品省事但同质化，让人留在循环里的产品才装得下差异化。
播客平台的商业化策略与主播生态建设：平台侧怎么赚钱，主播生态怎么分层。
AI 全自动内容创作的未来与挑战：全自动流水线的想象力与现实瓶颈。

节目中提到的代表性工具/产品：MiniMax（语音克隆 + TTS）、NotebookLM（Google 的 AI 笔记工具，根据资料生成总结和分析，被作为「AI 内容创作 + 语音生成」的应用案例）。

两个值得记住的案例：

AI 自媒体团队狂接商单：有团队用 AI 批量生产内容，承接品牌商投放——「AI 内容」本身已经是乙方能交付的服务，不一定非要做产品。
拉布布（Labubu）动态壁纸：Labubu 全球爆火期间，有独立开发者做了卖拉布布动态壁纸的网站，晒出每天三四百美金的收入。主播的评价很直接：「这个就是看行动力了。赚钱的应该还是挺多的。」 同样的热点一百个人看到，一个人动手做了。

flowchart LR
    A["热点 / 需求出现<br/>Labubu 爆火"] --> B["快速上线<br/>几天做出网站"]
    B --> C["低成本获客<br/>热点自带搜索流量"]
    C --> D["小额高频变现<br/>壁纸单价低、决策快"]
    D --> E["热点退去<br/>转向下一个机会"]
    style A fill:#fef3c7,stroke:#92400e
    style D fill:#dcfce7,stroke:#166534

这期标题就是结论：限制你的不是技术，是想象力和行动力。

三、整合框架：个人小生意的三要素

把两期内容抽象出来，一个能跑通的个人小生意必须三个轮子一起转：

graph TD
    A["个人小生意"] --> B["产品<br/>解决一个具体问题"]
    A --> C["流量<br/>让目标用户看到你"]
    A --> D["变现<br/>有人愿意付钱"]

    B --> B1["AI 工具 / 套壳站"]
    B --> B2["内容 / 课程 / 社群"]
    B --> B3["服务 / 外包 / 定制开发"]

    C --> C1["自有渠道：公众号、即刻、抖音"]
    C --> C2["平台流量：ProductHunt、论坛、SEO 长尾"]
    C --> C3["build in public：开发过程即内容"]

    D --> D1["订阅 / 一次性付费"]
    D --> D2["广告 / 商单"]
    D --> D3["项目制收费"]

    style A fill:#fef3c7,stroke:#92400e
    style B fill:#dbeafe,stroke:#1e40af
    style C fill:#dcfce7,stroke:#166534
    style D fill:#fce7f3,stroke:#9d174d

三个轮子缺一个就会卡死——这正是 EP64 里「做得好但没被看到的产品」和「宣传做不好的产品的共同特点」两个话题的合流之处：

只有产品没有流量 →「做出来了，没人知道」（大多数技术人的死法）
只有流量没有产品 →「粉丝不少，不知道卖什么」（自媒体人的死法）
有产品有流量但不变现 →「叫好不叫座，用爱发电」（开源作者的常见困境）

四、从想法到第一笔收入：完整流程图

综合 Podwise 的 PMF 步骤和 build in public 方法，一个新人从 0 到第一笔收入的合理流程：

flowchart TD
    A["发现需求<br/>自己的痛点 / 热点 / 客户抱怨"] --> B{"先验证，再开发<br/>发帖子问 / 做落地页收集意向"}
    B -- "没人感兴趣" --> A
    B -- "有人想要" --> C["MVP：只做最核心的一个功能"]
    C --> D["build in public<br/>开发过程本身就是内容"]
    D --> E["发布到杠杆高的渠道<br/>ProductHunt / 论坛 / 自有账号"]
    E --> F{"有人付费吗？"}
    F -- "有" --> G["迭代 + 论坛互动抓长尾<br/>找复购与转介绍"]
    F -- "没有" --> H{"是流量问题<br/>还是产品问题？"}
    H -- "流量问题" --> E
    H -- "产品问题" --> A
    G --> I["第一笔稳定收入<br/>再考虑加大投入"]

    style B fill:#fef3c7,stroke:#92400e
    style F fill:#fef3c7,stroke:#92400e
    style I fill:#dcfce7,stroke:#166534

注意两个回环：「没人感兴趣就换想法」（Podwise 也是放弃过一堆想法才选中的）和**「区分流量问题还是产品问题」**。新人最常见的错误是在没人要的产品上持续迭代半年——那不是坚持，是逃避验证。

五、避坑技巧清单

综合两期播客的讨论，按「踩坑顺序」排列：

5.1 出发前的坑

裸辞 without 存款。EP64 里说得很直白：大部分人半年到一年内回工作岗位，是被存款耗尽逼回去的，不是被产品失败打败的。现金流是这条路的氧气。
为了「独立开发」而独立开发。这是 EP64 给新人的第一条建议——身份本身不值得追求，受打击的概率远大于成就感。
只做产品，不当生意做。先想清楚「谁付钱、为什么付钱」，再写第一行代码。「AI 产品首先得是一个产品」——AI 是能力，不是付费理由。
一上来做平台型产品。AI 搜索、通用 Agent 平台是大厂赛道。独立开发者 idoubi 的 AI 搜索产品 ThinkAny 拿到 ProductHunt 日榜第四、月 60 万访问，最终也因资源不足放弃做大——个人资源撑不起平台梦。找 easy to target 的领域，比做「大」的事靠谱。

5.2 开发中的坑

过度工程。MVP 阶段用现成服务（托管、支付、登录），把时间花在用户能看见的地方。
选题不做排除法。Podwise 是排除了一堆想法之后的幸存项。把「放弃过的想法」记录下来，比拍脑袋选一个再死磕强。
定价免费。推出即收费是检验需求真伪的唯一标准。不敢收费往往是因为心里清楚产品不行。
做 on the loop 的全自动产品却没有差异化。EP105 的反思：人不在循环里，产品就没有创作者的独特性——全自动流水线人人都能搭，凭什么买你的？

5.3 运营中的坑（EP64 重点，技术人最容易栽的地方）

只发一次声。营销要去杠杆高的地方，并且在论坛/社区里持续回复有营养的内容，抓长尾流量——发完就走等于没发。
内容三缺一。检查每一条内容：喜闻乐见吗？感同身受吗？对我有用吗？只占一条的内容没有传播力。
不 build in public。还在观望要不要做的时候，就该开始输出内容了。开发日志、复盘、踩坑记录本身就是最好的冷启动素材，等到产品做完再开始营销已经晚了。
忽视收款与合规。对公业务要发票（个体户/灵活用工平台），出海要 Stripe 类收款——别等产品有人付费了才发现钱收不进来。
一个人硬扛情绪。焦虑是常态不是信号。去社群里找同类，这个圈子的信息密度和情绪价值都在人和人之间。

六、给新人的最小行动清单

如果听完这两期播客只想记住三件事：

保证 12 个月不下牌桌：存款、低物欲、或先接外包养现金流——淘汰线是现金流，不是能力
从第一天开始输出：每周发布一次（开发日志/复盘/教程），build in public，流量是复利
30 天内收到第一笔钱：哪怕是 9.9 元。收到钱和没收到钱，你对待产品的方式会完全不同

参考资料

《关键对话》笔记：高风险对话的外科手术室——从心开始到开始行动

Mon, 08 Apr 2024 10:40:00 +0800

《关键对话》笔记：高风险对话的外科手术室——从心开始到开始行动

目标读者：每周都要开评审会、跨团队推方案、跟上级谈排期和薪资、给同事负反馈的工程师——也就是每一个工程师。参考书籍：Kerry Patterson、Joseph Grenny、Ron McMillan、Al Switzler 合著《关键对话：如何高效能沟通》（Crucial Conversations: Tools for Talking When Stakes Are High，2002 年初版）。阅读目标：不逐章复述，而是把全书按一次对话的时间轴重新组装——开口前（从心开始）、对话中（观察、修安全、驾驭情绪、陈述、倾听）、收尾（开始行动）。这套方法有明确的启用条件，是救急的重装备，不是日常语言；日常的底层语言另有姊妹篇《非暴力沟通》笔记处理，两篇可以独立阅读。

一、什么对话算"关键"，以及傻瓜式选择

1.1 三要素：高风险、观点对立、情绪激烈

这本书不是四个作者坐而论道写出来的——Patterson 等人在组织行为领域做了二十多年的跟踪研究，最初的问题是：为什么有些团队在压力最大的时刻反而能拿出最好的决定？他们发现差异不在智商、不在资历，而在关键时刻的对话能力：那些能在高风险、观点对立、情绪激烈的对话里依然让信息自由流动的团队，在绩效、执行力甚至员工健康指标上都显著更好。书里对关键对话的定义很严格，三个条件缺一不可：

高风险：对话的结果对某件事影响重大——项目上不上线、资源批不批、绩效怎么定；
观点对立：双方要的东西不一样，甚至方向相反；
情绪激烈：至少有一方已经上头了，或者随时会上头。

按这个标准，日常聊天、信息同步、纯执行指令都不算关键对话——用手术室的流程去对待它们属于过度设计。但工程师每周真正符合三要素的场景比想象中多：方案评审、跨团队扯皮、跟上级谈排期和薪资、给绩效反馈、线上事故的问责会。问题不在于我们遇不到关键对话，而在于我们遇到了却按普通对话来打。

这也是为什么这本书值得精读：它对"什么时候该上方法"给了清晰的判断条件，而不是泛泛地要求"好好说话"。整套方法论——双路监控、安全感重建、STATE、AMPP——是有明确启用条件的重装备：它像手术室，不会天天进，但一旦该进的时候你徒手操作，后果是事故级别的。

1.2 傻瓜式选择：沉默或暴力

书里最锋利的一个观察：压力之下，人会觉得只剩两个选项——要么说出真话但伤害对方（暴力），要么保住关系但咽下真话（沉默）。两个都输，所以叫"傻瓜式选择"（Fool’s Choice）。

这个"二选一"的感觉极其真实。评审会上发现资深同事的方案有洞，脑内弹出的选项就是"当众指出让他下不来台"或"闭嘴让雷带上线"。书的核心主张是：这两个选项之间的对立是虚构的，说真话和保关系可以同时成立——但前提是你要掌握后面一整套方法，而不是靠"说话委婉一点"这种模糊的自我要求。全书剩下的内容，本质上都是在拆除这个虚构的对立。

二、从心开始：开口前先回答四个问题

方法链条的第一环不在对话现场，而在开口之前。从心开始（Start with Heart） 的核心动作是：在被情绪拖走之前，逼自己回答"我真正想要的是什么"。

书里给的是一组追问，我记成四问：

我真正想为自己得到什么？
我真正想为对方得到什么？
我真正想为这段关系得到什么？
如果这些真的是我想要的，我现在应该怎么做？

这组问题的作用机制很朴素：人在激动时目标会漂移——原本想解决项目风险，吵着吵着目标就变成了"赢"和"让对方认错"。四问是把漂移的目标拽回来的锚。而回答到第三问（关系）时，傻瓜式选择往往自己就松动了：如果你真在乎这段关系，“当众羞辱他"自然就从选项里消失了；如果你真在乎项目，“闭嘴保平安"也站不住。拒绝非此即彼的方式不是喊口号，是把真正想要的目标想清楚之后，问自己"怎样才能两全”。

注意第四问的问法：“我应该怎么做"而不是"我想怎么做”——激动时想做的事（怼回去、摔门走人）很少是四问答案推导出来的事。这组问题的价值就在于把"想做的"和"该做的"分开，然后让后者接管。

flowchart TD
    T["触发点<br/>对方的话让你上头"] --> Q1["问自己<br/>我想为自己得到什么"]
    Q1 --> Q2["问自己<br/>我想为对方得到什么"]
    Q2 --> Q3["问自己<br/>我想为这段关系得到什么"]
    Q3 --> Q4["问自己<br/>那我现在应该怎么做"]
    Q4 --> R["目标归位<br/>拒绝非此即彼<br/>寻找两全路径"]
    T -.->|"不跑四问"| F["目标漂移<br/>只想赢 只想让对方认错"]
    style Q3 fill:#fff3cd
    style R fill:#e8f4e8
    style F fill:#fde8e8

三、学会观察：安全感是对话的生命体征

3.1 共享观点库

书里有一个统领全篇的模型：共享观点库（Pool of Shared Meaning）。每个人脑子里都装着自己的观点、事实、感受和猜测，对话就是把这些东西倒进一个公共池子的过程。池子里的信息越充分，决定的质量越高——哪怕池子里有彼此冲突的观点，只要它们都进了池子，冲突本身就能被讨论。对话失败不是因为有分歧，而是因为关键信息没进池子：有人把顾虑咽回去了。

3.2 双路监控

那什么决定信息敢不敢进池子？安全感。进入对话后，书里要求同时看两路信号：内容（我们在谈什么）和氛围（对话的安全感还在不在）。普通对话只需要看内容路；关键对话里氛围路才是生命体征——安全感一旦崩塌，内容说得再对也进不了对方的耳朵，因为对方此刻处理的不是信息，是威胁。

3.3 安全感崩塌的两种形态

失去安全感时，人只有两种反应方向：

沉默（往回撤），三种形态：掩饰（避重就轻、轻描淡写、嘴上答应心里不认可）、逃避（岔开话题、说"回头再说”、不置可否）、退缩（退出对话本身——不再参会、私下消极执行）；
暴力（往前冲），三种形态：控制（打断别人、夸大事实、把观点强加给对方）、贴标签（“你们后端就是这样"“产品经理都这毛病”）、攻击（从否定观点升级到否定人）。

flowchart TD
    A["观点对立 + 情绪上头"] --> B{"安全感还在吗"}
    B -->|"在"| C["观点进池子<br/>对话继续产出"]
    B -->|"崩塌"| D["沉默 往回撤"]
    B -->|"崩塌"| E["暴力 往前冲"]
    D --> D1["掩饰 避重就轻"]
    D --> D2["逃避 回头再说"]
    D --> D3["退缩 退出对话"]
    E --> E1["控制 打断与强加"]
    E --> E2["贴标签 否定一类人"]
    E --> E3["攻击 否定一个人"]
    style B fill:#fff3cd

这张表有两个读法。看自己：先搞清楚自己上头时的默认形态是沉默型还是暴力型——你不知道自己的默认形态，就没有监控的第一手数据。看对方：暴力好识别（吵起来了），沉默极易被误读成同意——“没人反对"和"达成共识"之间隔着所有没说出口的顾虑。

四、营造安全感：道歉、对比说明与 CRIB

发现安全感报警之后怎么办？书里的答案是暂停内容，跳出话题，先把安全修回来再谈事。安全感的地基是两块：

共同目的：对方要确认你和他站在同一个方向上，对话是来解决问题的，不是来分出胜负的；
互相尊重：对方要确认你尊重他这个人——尊重感一旦受损，对话立即变成自尊保卫战，内容全部失效。

围绕这两块地基，书给了三个修复工具。

4.1 道歉

当你确实越界伤害了尊重（说了过头的话、食了言），先真诚道歉。道歉修的是尊重那一块地基。注意书里强调道歉必须是真的——为讨好对方而道的歉，对方听得出来，反而加深不信任。

4.2 对比说明：否定 + 肯定

对比说明（Contrasting） 是全书最高频的工具，句式是"否定 + 肯定"两段：

“我不是想否定这个方案的整体方向（否定，消除误读），我是想把这个并发风险在上线前摆到台面上（肯定，申明真实目的）。”

它解决的是一个具体问题：对方把你的话往最坏的方向解读了（“他要推翻我的方案"“他觉得我不行”），对比说明把误读的空间提前压缩掉。否定句管的是对方不担心的，肯定句管的是共同目的。 这个句式在对方表情突然变硬的那一刻用，效果最好。

4.3 CRIB：共同目的实在找不到时

如果双方的目的真的南辕北辙（比如一个要快上线、一个要保稳定），书给了 CRIB 四步：

flowchart LR
    C["C 承诺<br/>一起寻找共同目的<br/>找到前不回到争执"] --> R["R 识别<br/>对方策略背后的真实目的"]
    R --> I["I 创造<br/>在更高层次上<br/>创造共同目的"]
    I --> B["B 头脑风暴<br/>站在新共同目的上<br/>一起想新策略"]
    style I fill:#e8f4e8

C - Commit（承诺）：承诺一起寻找一个双方都接受的目的，并承诺在找到之前不回到争执；
R - Recognize（识别）：识别对方策略背后的真实目的——“今晚必须上线"是策略，背后的目的可能是"老板要的里程碑不能延”；
I - Invent（创造）：在更高的层次上创造一个共同目的——“我们都不想里程碑延期，也都不想线上出事故”；
B - Brainstorm（头脑风暴）：站在这个新的共同目的上，一起想新策略——比如砍范围保日期、或者分阶段上线。

CRIB 的关键洞察是：僵持往往发生在策略层，而不是目的层。 把争执从"谁的策略"抬到"共同要什么"的层面，多数死锁会自己解开。

五、驾驭情绪：情绪不是别人给的

这是全书对我冲击最大的一章。我们通常说"他把我气着了”，仿佛情绪是对方制造并塞进我们身体里的。书里的行为方式模型把这个链条拆开：

flowchart LR
    A["所见所闻<br/>可录像回放的事实"] --> B["主观臆断<br/>我们讲给自己的故事"] --> C["形成感受<br/>愤怒 受伤 委屈"] --> D["展开行为<br/>沉默或暴力"]
    B -.->|"三种聪明故事"| S1["受害者<br/>这不是我的错"]
    B -.->|"三种聪明故事"| S2["大反派<br/>都是他的问题"]
    B -.->|"三种聪明故事"| S3["无助者<br/>我没办法"]
    style B fill:#fff3cd

在所见所闻和形成感受之间，隔着一层"主观臆断”——我们根据事实给自己讲的故事。 对方在会上否了你的方案（事实），你讲的故事可能是"他针对我”，也可能是"这个风险确实没覆盖"——同一个事实，故事不同，情绪完全不同，后续行为完全不同。情绪不是别人给的，是你自己的故事给的；而故事是可以重写的。

驾驭情绪的操作就两步：

区分事实和故事：事实是"他连续三次在评审时否决我的提案"；故事是"他想把我挤出这个项目"。把两者分开，情绪强度会先降一半。
警惕三种"聪明故事"：受害者（“这不是我的错”——抹掉自己的责任）、大反派（“都是他的问题”——把对方妖魔化）、无助者（“我没办法”——抹掉自己的行动空间）。这三种故事之所以"聪明"，是因为它们都能让你心里舒服：它们要么开脱你，要么丑化对方，要么赦免你的行动。检验方法是反问：一个理性、善意的人会做出这种行为吗？我在其中扮演了什么角色？如果我真正想要的是那个目标，我现在该做什么？

六、STATE 陈述与 AMPP 倾听

6.1 STATE：把有争议的话说出口

安全感修好之后，回到内容。怎么把自己持有的、对方不爱听的观点说出来？书里给了 STATE 五步：

S - Share（分享事实经过）：从事实开始。事实是争议最小的起点——“压测报告里 P99 延迟是 1.2 秒"几乎无法引发防御；
T - Tell（说出想法）：说出你的判断，并明确标注它是判断——“我的判断是缓存策略需要改”；
A - Ask（征询对方观点）：主动问对方怎么看——“你当时这么设计的考虑是什么”；
T - Talk tentatively（试探表述）：用试探的语气陈述，保留被推翻的空间——“也可能有我漏掉的约束”；
E - Encourage（鼓励尝试）：鼓励对方提出不同甚至相反的意见——“如果你认为这个风险不存在，请直接反驳我”。

五步的顺序是有讲究的：事实防御性最低所以先行，判断防御性最高所以必须标注来源；而后三步全部是向对方发出"你可以不同意我"的入场券。 STATE 的姿态不是"我说服你”，是"我把我的完整推理摊开，请你来检验"。

6.2 AMPP：把对方的真实想法挖出来

对方沉默了或者言辞闪烁时，轮到倾听侧的工具，AMPP 四步：

A - Ask（询问）：直接邀请表达——“我想听听你的真实想法”；
M - Mirror（映射）：描述你观察到的状态与言辞的矛盾——“你嘴上说可以，但表情看起来很有顾虑”；
P - Paraphrase（复述）：用自己的话复述对方的观点，确认理解——“你的意思是排期根本容不下这个改动，对吗”；
P - Prime（推测）：对方还是不说时，把你猜测的顾虑说出来抛给他——“是不是担心这个改动会影响你们组正在做的重构”。

Prime 是最后的手段，有点像猜，但它的作用不是猜中，而是给对方一个顺着台阶开口的机会——承认一个被猜中的顾虑，比主动开口说顾虑，心理成本低得多。

七、开始行动：对话的终点是明确的行动

对话的终点不是"聊完了"，是明确的行动。书里提醒两件事。

先决定怎么决定。 四种决定方式各有适用场景：

命令式：外部要求已经定了，没有讨论空间——合规要求、老板的军令状；
顾问式：拍板权在某个人手里，但先广泛征求意见——架构选型由架构师定，但全组参与；
投票式：多个都合格的方案里快速收敛，效率优先；
共识式：高风险、需要所有人真心执行的决定——上线策略、人事决定。

最常见的两种事故：把本该共识的事用命令拍了（执行时消极抵抗），把该拍板的事拖成共识（永远开不完的会）。在对话开始时先声明这次用哪种方式决定，本身就消掉一半的不满——很多人的愤怒不来自决定本身，来自"我以为我有发言权"。

然后明确执行细节：谁、在什么时间、做什么、怎么跟进。四个要素缺一，“达成一致"就是幻觉——散会时每个人都点头，两周后发现没人动手，是团队里最昂贵的幻觉。

八、工程落地：四个高频场景的具体打法

理论到此为止，下面是这套工具在我日常工作里的具体用法。

8.1 技术评审会：STATE 陈述 + AMPP 挖掘

评审会是观点对立最密集的地方。我的固定打法：自己发言走 STATE——先放压测数据和日志（Share），再说判断并标注是判断（Tell），然后问设计者的考虑（Ask），承认可能有漏看的约束（Talk tentatively），最后明确欢迎反驳（Encourage）。发现对方开始沉默或言辞闪烁时切 AMPP——先问，不问出来就映射（“你答应得很快但看起来有顾虑”），复述确认，必要时推测（“是担心影响你们组的排期吗”）。评审会的质量上限不取决于最聪明的人，取决于有多少顾虑被挖了出来。

8.2 跨团队推诿：先跑"从心开始"四问

跨团队对话天然带立场冲突，一开口就容易变成各护各的锅。开口前先在纸上写四问的答案：我要什么（项目按时交付）、对方要什么（别增加他们的工作量）、关系要什么（下次还能合作）、那我现在该怎么做。写完这四行字，开口的第一句话往往就不一样了——从"你们为什么又改需求"变成"我们都想这个项目成，现在卡在排期上，一起看看怎么解”。共同目的不是话术，是你在四问里真的想出来的。

8.3 向上沟通：安全感对上级同样适用

找上级要资源、谈排期，权力差让人默认自己是弱势方，于是要么过度攻击（列一堆 ROI 砸过去），要么过度沉默（欲言又止被婉拒）。用这本书的框架看：上级也需要安全感——他需要确认你是来共同解决问题的，不是来转嫁压力或下最后通牒的。 开口先立共同目的（“这个项目是咱们定的军令状”），用对比说明排除误读（“我不是来要更多人的，我是想把延期的风险提前暴露”），然后 STATE 摆事实讲判断。

8.4 谈薪资：一场标准的关键对话

谈薪资把三要素占全了：高风险（直接影响收入）、观点对立（你的期望和预算有差距）、情绪激烈（双方都容易觉得被冒犯）。用框架拆解：从心开始先想清楚你要的是"这次涨到位"还是"长期在这里好好干"——如果是后者，共同目的就是"我长期在这里创造价值"，而不是"不给钱我就走"；陈述走 STATE，从市场数据和你过去一年的可量化产出开始（事实先行），而不是从"我觉得我被低估了"开始（那是故事，不是事实）。最后通牒只在一种情况下有效：你真的做好了走的准备——否则它只是暴力形态的一种。

8.5 线上事故问责会：把监控开到最大

事故复盘是三要素浓度最高的会议：影响大、归因敏感、人人带情绪。用这本书的框架，主持人的职责就是盯氛围路——一旦有人开始退缩（不再发言）或攻击（“这个模块谁写的”），立刻暂停内容、修安全：重申共同目的（“复盘是为了让系统更可靠，不是为了找替罪羊”），必要时对比说明（“我不是要追责到个人，我是要把时间线上的缺口补齐”）。一场成功的复盘，唯一的验收标准是所有事实都进了共享观点库。

九、带走的清单

三要素同时满足才算关键对话：高风险、观点对立、情绪激烈。别对普通对话过度设计。
警惕傻瓜式选择：说真话和保关系不是互斥的，感觉到"只能二选一"时就是该上方法的时候。
开口前跑四问：我要什么、对方要什么、关系要什么、那该怎么做。
对话的产出看共享观点库：信息进池子才有好决定，安全感决定信息敢不敢进。
对话中双路监控：内容路和氛围路；安全感崩塌只看两个方向——沉默（掩饰、逃避、退缩）与暴力（控制、贴标签、攻击）。
修安全三工具：真诚道歉、对比说明（否定 + 肯定）、CRIB 找共同目的。
情绪不是别人给的：所见所闻和感受之间隔着你讲的故事；警惕受害者、大反派、无助者三种聪明故事。
陈述用 STATE：事实先行，判断标注，后三步全是给对方发反对的入场券。
倾听用 AMPP：问不出来就映射，映射不行就复述，复述不行就推测。
收尾必须落到：四种决定方式选哪一种先声明，然后明确谁、什么时间、做什么、怎么跟进。

参考资料

Kerry Patterson, Joseph Grenny, Ron McMillan, Al Switzler, Crucial Conversations: Tools for Talking When Stakes Are High, McGraw-Hill, 2002（中文版《关键对话：如何高效能沟通》）。

产品经理一篇通：从小白到资深 C 端产品经理的完整地图

Mon, 01 Aug 2022 10:00:00 +0800

产品经理一篇通：从小白到资深 C 端产品经理的完整地图

这不是一篇教科书，而是学习一位老产品经理十年踩过的坑、熬过的夜、吵过的架，压缩成的一篇长文。看完它，你不会立刻变成张小龙，但你会知道：资深产品经理脑子里到底在转什么。

产品经理到底是什么物种
第一性原理：用户价值是唯一的地基
人性弱点的利用：产品设计背后的"暗箱"
需求分析实战：从一句用户抱怨到一个可执行的方案
需求的权衡：价值、成本与时机的三角博弈
需求讨论与汇报：评审会通过的关键在会前
沟通：产品经理的另一半工作是"翻译"
数据驱动：别让直觉裸奔
增长：AARRR 不是口号，是流水线的每一环
三个完整的产品设计故事
思考与感悟：十年之后我才明白的事
从小白到资深的成长路线图

1. 产品经理到底是什么物种

先打破一个幻觉：产品经理不是"经理"。你没有人事权，没有预算权，开发不归你管，设计不听你号令。你唯一拥有的，是"对结果负责"这五个字。

graph TD
    U[用户<br/>抱怨与欲望] --> PM[产品经理]
    B[老板<br/>战略与营收] --> PM
    T[技术<br/>可行性与成本] --> PM
    D[设计<br/>体验与一致性] --> PM
    M[市场/运营<br/>增长与转化] --> PM
    PM --> DECISION{做不做？<br/>做什么？<br/>先做什么？}
    DECISION --> P[产品方案]

产品经理的本质，是在无限的欲望和有限的资源之间，持续做出正确取舍的人。

用户想要一切，而且免费
老板想要增长，而且明天
开发想要稳定，而且别改需求
而你只有：一个季度、三个人、一堆互相矛盾的声音

小白云：“那产品经理的核心能力是什么？”

资深答：判断力。具体到三件事：

看得准 —— 分辨真需求和伪需求
排得对 —— 在 100 件事里选出最重要的 3 件
推得动 —— 让一群不向你汇报的人把事做成

2. 第一性原理：用户价值是唯一的地基

2.1 用户要的不是产品，是更好的自己

用户说要一匹更快的马，福特给了他们汽车。这个故事被讲烂了，但多数人只记住了"别听用户的"，没记住后半句：要听用户的问题，不要听用户的方案。

用户的真实结构是这样的：

graph LR
    A[用户说出来的<br/>表面诉求] --> B[用户真正想解决的<br/>场景问题]
    B --> C[问题背后的<br/>人性动机]
    C --> D[产品机会]
    style D fill:#90EE90

举个真实的例子。某音乐 App 收到大量反馈：“请加一个’定时关闭’功能”。

小白产品经理：好，记进需求池，排期，上线，功能完成率 +1。
资深产品经理会问：谁在说？什么场景？—— 深挖后发现，说这话的几乎全是睡前听歌的用户。他们要的不是"定时关闭"，是"安心睡着"。于是方案变成了：睡眠模式 —— 音量渐弱、自动切换到白噪音、屏幕变暗。功能使用量翻了 8 倍。

感悟：需求文档里写的是"做什么"，产品经理的价值在"为什么"。同一个诉求，理解深一层，方案就好十倍。

2.2 用户价值的公式

我多年用下来的一个心算公式：

用户价值 = (新体验 - 旧体验) - 替换成本

你的产品比竞品好 20%，但用户迁移数据要折腾一晚上 —— 价值为负，没人来。
你的产品比竞品好 5%，但一键导入、微信扫码即用 —— 价值为正，增长起飞。

这就是为什么"少即是多"常常赢：不是功能少的赢，是替换成本低的赢。

3. 人性弱点的利用：产品设计背后的"暗箱"

这一章是 C 端产品经理的"内功心法"，也是最需要带着镣铐跳舞的一章。先立规矩：

利用人性弱点做用户想做的事，是产品技巧；利用人性弱点做伤害用户的事，是作恶。两者的分界线，是你的价值观。

3.1 七张底牌

mindmap
  root((人性的<br/>七张底牌))
    损失厌恶
      失去100元的痛 > 得到100元的爽
      应用：免费试用到期提醒
    锚定效应
      第一个价格决定后续判断
      应用：原价划线、高价套餐陪衬
    沉没成本
      投入越多越难离开
      应用：个人主页、等级体系、收藏夹
    社交证明
      别人都这样，那我也这样
      应用：销量数字、朋友在看
    多巴胺回路
      不确定的奖励最上瘾
      应用：下拉刷新、开宝箱、红点
    损失框架与稀缺
      仅剩3件、限时2小时
      应用：限时活动、库存提示
    目标梯度效应
      越接近终点越努力
      应用：进度条、还差1人成团

3.2 逐个拆解，配上真实案例

（1）损失厌恶 —— 拼多多与微信读书

行为经济学实验证明：失去 100 元的痛苦，约等于得到 200 元的快乐。

微信读书的"无限卡免费天数，不读就过期"，本质是每天给你一笔"会失去"的资产。你打开 App 不是因为它给了你什么，而是因为你不想失去已经到手的东西。同样，拼多多的"砍价免费拿，24 小时内有效"——倒计时的每一秒都在放大损失厌恶。

（2）锚定效应 —— 价格页的艺术

某 SaaS 产品定价页放三档：基础版 ¥99 / 专业版 ¥299 / 企业版 ¥999。企业版从来不是用来卖的，是用来让 ¥299 显得便宜的。星巴克的中杯、大杯、超大杯，同理。

（3）沉没成本 —— 为什么你离不开网易云音乐

你在网易云存了 2000 首红心、写了 50 条评论、养了 3 年的歌单。竞品曲库再全，你也走不了 —— 你离开的不是 App，是三年前的自己。所以资深产品经理在设计 C 端产品时，一定会埋一条线：让用户持续留下"带不走的东西"——笔记、装扮、等级、关系链。

（4）多巴胺回路 —— 下拉刷新的老虎机

为什么下拉刷新让人上瘾？因为它和老虎机同构：动作简单 + 奖励不确定。你不知道这一拉会出现有趣的视频还是无聊的广告，不确定性本身就是奖赏。抖音把这个机制做到了极致——每条视频都是一次拉杆。

（5）目标梯度 —— “再邀请 1 人即可提现”

拼多多的进度条永远卡在 99.9%。人在越接近目标时动力越强（心理学称为 Goal-Gradient Effect），所以进度条必须先快后慢：开头一秒冲到 90%，让你觉得"马上就到了"。

思考：这一章是双刃剑。拼多多的增长奇迹建立在人性的精密计算上，但"砍一刀永远差一刀"也让它长期背负口碑争议。资深产品经理和小白的区别在于：小白只问"能不能转化"，资深会问"三个月之后，用户想起我们时，是感激还是恶心"。短期的转化率是数字，长期的口碑是资产。

3.3 伦理边界自查清单

每当你设计一个"利用人性"的机制，问自己三个问题：

如果用户完全知道这个机制的原理，他还会愿意用吗？（信息透明测试）
这个功能一年后会让用户的生活变好还是变坏？（长期价值测试）
我敢让我爸妈用这个功能吗？（至亲测试）

4. 需求分析实战：从一句用户抱怨到一个可执行的方案

前面三章讲的是"想清楚"的地基，从这一章起讲"做出来"。需求的完整流水线，我们用三章讲透：本章讲理解、挖掘与转化，第 5 章讲权衡与取舍，第 6 章讲讨论与汇报：

flowchart LR
    A[深度理解用户<br/>泡进去，成为用户] --> B[需求挖掘<br/>从六个来源挖出真问题]
    B --> C[需求分析与转化<br/>抱怨 → 问题 → 方案 → PRD]
    C --> D[权衡与排期<br/>KANO / RICE，见第5章]
    D --> E[需求讨论与汇报<br/>评审与过会，见第6章]
    E --> F[落地与验证<br/>上线后回看数据]
    F -.->|数据回流，发现新问题| A

4.1 需求分析：先搞清楚"需求"到底是什么

大多数需求讨论的低效，源于大家对"需求"这个词的理解都不一样。先立一个可操作的定义：

需求 = 目标用户 + 具体场景 + 未被解决的问题 + 期望的结果

四个要素缺一个，就是一句牢骚，不是一个需求。“这个 App 太难用了"不是需求；“新用户（谁）在第一次发布内容时（场景）找不到入口（问题），导致放弃发布，他期望三步内完成发布（结果）“才是需求。

用户给你的东西，必须拆成三类分别处理：

graph TD
    U[用户的一句话] --> F[事实<br/>这里闪退了，有截图<br/>→ 照单全收]
    U --> O[观点<br/>你们这设计反人类<br/>→ 翻译成场景：他在哪一步卡住了？]
    U --> S[方案<br/>你们应该加个XX按钮<br/>→ 打回原形：他想解决什么问题？]

举个真实例子：有用户连写三封邮件要求"把注册流程砍到一步”。

小白产品经理：记进需求池——“简化注册流程”。
资深产品经理：回访发现，这位用户卡在的是短信验证码收不到。他不是嫌步骤多，是压根收不到码。“砍步骤"是他自己开出来的药方，真正的病灶是短信通道的到达率。最后改的是：增加语音验证码兜底 + 切换短信服务商。注册转化率提升 11%，而流程一步都没砍。

感悟：用户是最好的"问题发现者”，往往是最差的"方案设计者”。尊重他们的问题，但别照抄他们的药方。

真伪需求快速自检表（收到任何需求先过一遍）：

多少用户、在什么场景下会遇到这个问题？（覆盖面）
这个问题多久发生一次？（频次）
用户现在的替代方案是什么？他有多痛？（强度——有替代方案且不痛的，多半不着急）
如果做了，用户愿意付出什么代价——时间、学习成本，还是钱？（付不起代价的"想要"都是客气）
如果不做，三个月后会发生什么？（答案是"也不会怎样"的需求，就让它躺在需求池里）

4.2 深度理解用户：同理心是工作量，不是天赋

用户画像的误区

“25-35 岁、一二线城市、本科以上、月入 8K+"——这是投放画像，给广告平台用的，对产品决策几乎没用。产品画像要回答的是另外四个问题：

维度	投放画像（没用）	产品画像（有用）
场景	28岁男性	通勤地铁上单手刷手机的上班族
动机	喜欢音乐	想在嘈杂环境里快速平静下来
能力	本科学历	数码小白，分不清"下载"和"缓存”
现有方案	使用竞品A	现在靠刷短视频解压，但越刷越焦虑

同样一个"28 岁男性”，在"深夜睡前"和"早高峰地铁"里是两个完全不同的用户。用户不是一个人，是一组场景的集合。

用户访谈：别问出你想听的答案

访谈最大的陷阱是用户在礼貌地骗你。你问"如果有一个帮你管理衣柜的 App，你会用吗？"——他会说"会啊挺好的"，然后永远不会下载。因为他预测自己的未来行为时，毫无准确性可言。

访谈的三条军规：

不问未来，只问过去。“你会不会用"换成"上一次你遇到这个问题是什么时候？当时怎么解决的？"——事实是可靠的，承诺是廉价的。
不问态度，只问行为。“你喜欢这个功能吗"换成"给我看看你上周是怎么用的”。
不诱导。把"你不觉得这里很难用吗"换成"你刚才在这里停了一下，当时在想什么？”

数量上有个经验法则：同一类用户深访 5 个左右，就能发现 80% 的主要问题——访谈做到第 6 个人开始大量重复时，可以停了。

资深产品经理的"泡用户"清单

同理心听起来像玄学，实际上是体力活。我自己的节奏：

每周看 100 条用户反馈（应用商店评论、客服工单、社群发言），并且归类到场景，不是归类到功能
每月做 5 个深度访谈，新人和老用户都要覆盖
每季度当一天客服或陪销售跑一趟客户，亲耳听听用户骂街
潜伏在用户社群里，看他们不@你的时候在聊什么——那才是真话
用自己的产品用到吐，并且强迫自己用竞品的，体验那种"别扭"——别扭就是需求

再讲一个真实案例。某阅读 App 数据发现：夜间模式在白天的使用率也很高。产品经理的第一反应是"优化护眼体验"，访谈之后才发现真相——很多用户在地铁里开着夜间模式，是怕旁边的人看清自己在看什么。他们要的不是护眼，是防窥。后来的方案是"专注模式"：正文正常、标题和封面模糊化。这就是"泡用户"和"看报表"的差别：报表告诉你现象，只有人告诉你为什么。

4.3 需求挖掘：需求不是收集来的，是挖出来的

“收集需求"这个词本身就误导人——好像需求是摆在路边的果子，等着你去捡。真实情况是：用户很少直接把需求递到你手上，你要从六个矿脉里把它挖出来。

mindmap
  root((需求的<br/>六个来源))
    用户反馈
      渠道：评论/工单/社群/访谈
      陷阱：声音大 ≠ 人数多
    数据异常
      漏斗断崖、搜索词、停留异常
      陷阱：只看What不问Why
    竞品动态
      抄功能死，抄逻辑活
      陷阱：忘了问"它为什么这么做"
    业务诉求
      老板的战略、运营的KPI
      陷阱：把诉求直接当需求
    行业趋势
      技术拐点、政策、代际变化
      陷阱：为趋势而趋势
    泡出来的洞察
      客服轮值、用户陪访
      最深的矿，最贵的矿

逐个说挖掘方法和坑：

（1）用户反馈 —— 警惕"嗓门偏见”

反馈渠道里发声的永远是极少数：满意的大多数沉默，用脚投票的流失用户更是直接消失。所以反馈要这样处理：**一条反馈不算数，一类场景重复出现才算数。**把反馈逐条标注"场景标签"，月底看哪个场景标签堆积最多——那才是矿脉。

（2）数据 —— 用户在用行为给你写需求文档

三个最好用的挖掘点：

漏斗断崖：注册流程第三步流失 60%？断崖处必有需求没被满足。
搜索词：搜索是用户主动告诉你"我想要什么"的地方。某电商分析搜索词，发现大量"送女友 200元以内"“程序员礼物"这类带场景的长尾搜索——用户要的不是商品，是"帮我做送礼决策”。于是上线了"礼物专区"，客单价和转化双升。
异常停留：某个页面停留时长远超设计预期，要么太好用，要么用户看不懂在找东西。分不清楚就去访谈。

（3）竞品 —— 抄功能死，抄逻辑活

看到竞品上了新功能，小白问"我们什么时候跟进"，资深问三个问题：它解决的是谁的问题？这个问题我们的用户有吗？它做对了还是做错了？（竞品也会犯错，你照着抄就是照着错。）竞品的用户评论区是比竞品本身更好的需求来源——骂它的每一条，都是你的机会。

（4）业务诉求 —— 把"老板要"翻译成"可验证的假设"

老板的需求不是不能做，是不能不加验证地做。把"我觉得用户需要直播带货"翻译成假设：“假设：目标用户中有 X% 有边看边买的需求；验证：先上一个轻量直播间试水两周，看停留和转化。"——这样既尊重了战略方向，又守住了资源不被拍脑袋烧掉。

（5）行业趋势 —— 技术拐点制造需求窗口

打车、外卖、短视频，本质都是"智能手机 + 移动支付 + 4G"三个技术拐点打开的需求窗口。趋势类需求要问的是：**什么基础设施变了，让原来不成立的需求现在成立了？**想不出答案的"趋势”，是媒体的词，不是你的需求。

（6）泡出来的洞察 —— 最贵的也最深

前面 4.2 讲的那套体力活，就是这里说的第六个来源。前五个来源告诉你"发生了什么"，只有这一个告诉你"为什么"。

最后，需求池的每一条都要记全字段：来源、目标用户、场景描述、提出人、出现频次、现有替代方案、初步判断、触发条件（什么信号出现时应该重新评估它）。没有触发条件的需求池，是需求的坟场——埋进去就再也不会被翻出来。

4.4 需求分析和转化：把"用户想要的"翻译成"团队能做的"

挖出来的还是矿石，这一节讲冶炼。转化分三步：

第一步：需求描述规范化

把所有需求统一成同一个句式，强迫自己想完整：

作为 [目标用户]，在 [具体场景] 下，
我遇到 [问题/障碍]，
我希望 [期望的结果]，
这样我就能 [更深层的动机]。

对比一下两种写法：

口语版：“用户想要聊天记录导出功能。”
规范版：“作为换了新手机的老用户，在换机迁移的场景下，我发现三年的聊天记录无法带走，我希望能把重要对话导出保存，这样我就不会弄丢那些对我来说有意义的回忆。”

第二种写法让三件事自动浮出水面：这个功能的核心价值是"情感留存"而不是"数据迁移"——所以方案的重点应该是导出内容的可读性和仪式感（比如生成一本"对话书"），而不是给你一个 txt 文件。规范化的句式不是文书工作，是把需求逼到露出动机为止。

第二步：方案发散 —— 一个需求至少三个方案

拿到需求直接写 PRD，是小白最昂贵的习惯。用 HMW（How Might We，我们可以如何） 提问法先把方案空间撑开：

以"用户反馈找不到历史订单"为例：

HMW 让订单更好找？→ 方案A：订单搜索 + 筛选
HMW 让用户根本不需要找？→ 方案B：高频场景前置——“再次购买"入口放首页，90% 的找订单其实是为了复购
HMW 绕过这个问题？→ 方案C：不做了——数据显示月均有此行为的用户不到 2%，而 B 方案能覆盖其中 80%

三个方案摆在一起，讨论的对象就从"做不做功能A"变成了"我们要解决的本质问题是什么”。方案B 和 C 的存在，是方案A 质量的保证——哪怕最后选的还是 A。

第三步：落地为可验收的 PRD

PRD 的核心结构就五块：

模块	要回答的问题	常见翻车点
背景与目标	为什么现在做？解决什么问题？	只写"用户反馈很多"，没有数据
方案与边界	做什么、不做什么	边界不写，开发自由发挥，验收时扯皮
异常 case	断网、并发、极端输入怎么办	上线后才发现，变成线上事故
验收标准	什么状态算"做完了"	“体验要好"这种无法验收的描述
衡量指标	上线后看什么数、预期多少	没有指标的需求 = 无法复盘的需求

重点说两个：

“不做什么"列表是 PRD 里最值钱的部分。“本期不支持多账号切换"“暂不支持分享到第三方”——每一条明确的"不做”，都是替未来省掉的一次吵架。
每个需求必须带一个"上线后看什么数”。目标可以是"搜索成功率从 77% 提升到 90%"，也可以是"收集 100 条使用反馈验证假设”——但绝不能没有。没有指标的需求上线即失踪，你永远不会知道它做对了没有，而不复盘的需求做一百个也不会让你进步。

5. 需求的权衡：价值、成本与时机的三角博弈

挖出来、转化好的需求，先别急着排期——它们还要过权衡这一关。需求永远比资源多，这是产品经理的宿命。权衡不是"选好的"，而是**“放弃什么”**。

5.1 KANO 模型：先分清需求的种类

graph TD
    KANO[KANO 需求模型] --> A[必备型<br/>没有就骂，有了不夸<br/>例：聊天App能发消息]
    KANO --> B[期望型<br/>越好越满意<br/>例：加载速度、清晰度]
    KANO --> C[兴奋型<br/>没有不怪你，有了会尖叫<br/>例：当年微信的语音消息]
    KANO --> D[无差异型<br/>做不做无所谓]
    KANO --> E[反向型<br/>做了反而招骂<br/>例：强行弹广告]
    style C fill:#FFD700
    style E fill:#FF6B6B

关键洞察：兴奋型需求会随时间退化为必备型。2011 年语音消息是尖叫点，今天没有语音消息的聊天软件根本不能发布。所以产品要持续制造新的兴奋点，否则就是在吃老本。

5.2 RICE 打分：把直觉变成算术

当需求池里有 50 个需求而只能做 5 个，用 RICE 量化：

RICE 分数 = (Reach 触达用户数 × Impact 影响程度 × Confidence 信心) / Effort 人日成本

需求	Reach	Impact	Confidence	Effort	RICE
新手引导改版	10000/月	3	80%	20	1200
深色模式	3000/月	2	90%	30	180
AI 推荐	8000/月	3	50%	90	133

分数不是圣旨，但它能终结会议上的嗓门之争——从此吵架吵的是参数，不是面子。

5.3 决策的完整流程

flowchart TD
    A[收到需求] --> B{谁提的？}
    B -->|用户反馈| C[追溯场景与动机<br/>是问题还是方案？]
    B -->|老板拍脑袋| C2[包装成假设<br/>用数据验证]
    B -->|竞品做了| C3{和我们的战略<br/>有关系吗？}
    C --> D{KANO 分类}
    C2 --> D
    C3 -->|无关| X[礼貌地不做]
    C3 -->|相关| D
    D --> E[RICE 打分]
    E --> F{现在做？}
    F -->|时机未到| G[放进需求池<br/>标注触发条件]
    F -->|值得做| H[写 PRD<br/>定义验收标准]
    F -->|不值得| X

5.4 三个最容易被忽略的真相

时机会打败价值。对的需求在错的时间做，等于错的。外卖大战时做"点评社区"，不如把运力调度做好。
“不做"的功能清单，和"要做"的一样重要。微信至今不做"已读回执”，这个"不做"本身就是顶级的产品决策——保护接收者的体面。
最大的成本不是开发成本，是认知成本。每加一个功能，产品的复杂度就上升一分，所有用户的体验就稀释一分。

感悟：资深产品经理的功力，90% 体现在需求池里那些"永远不做"的需求上。拒绝，是最稀缺的产品能力。

过了权衡这一关，需求就来到流水线的下一站——评审会。

6. 需求讨论与汇报：评审会通过的关键在会前

流水线的第五环，也是最被低估的一环。先给结论：**需求评审的通过率，90% 在会议室之外决定。**你在会上看到的唇枪舌剑，都是会前没做完的功课。

会前第一件事：一页纸需求摘要

任何需求讨论，先发一页纸（不是 30 页 PRD），结构用金字塔——结论先行：

1. 一句话结论：我们建议做 X，预期带来 Y（数据），成本 Z 人日。
2. 问题与证据：什么用户、什么场景、什么问题（附数据/反馈截图）。
3. 方案与边界：做什么、不做什么、为什么是这条路（被否掉的备选方案列一行）。
4. 成本与风险：开发量、依赖、最大的不确定性是什么。
5. 需要的决策：今天需要各位拍板的是哪一两件事。

第 1 条是整页纸的命根子。老板和评审者的时间以秒计，你必须允许他只读第一句话就能做出 80% 的判断。把结论藏在第 20 页的汇报，本质上是在浪费所有人的耐心。

会前第二件事：预沟通 —— 把炸弹拆在会前

评审会不是用来说服的，是用来确认的。会前 48 小时，找三个关键角色各聊 15 分钟：

技术负责人：过一遍方案的实现路径和工作量。他在会上突然说"做不了"，多半是会前没人问过他。
设计：确认体验目标和设计资源。设计在会上才第一次看到需求，是对设计最大的不尊重。
运营/业务方：对齐上线节奏和卖点，避免"你们下周上线？我们大促也是下周"。

会上被突然袭击的每一个问题，都对应一个会前漏掉的人。

会前第三件事：预演反对意见

列一张清单："这场评审，我最可能被挑战的 5 个问题是什么？“每个问题备好数据和退路。常见必答题：

谁问	会问什么	你要备好
开发	为什么不做简单版？	分层方案：MVP 做什么、二期做什么
开发	这个需求值吗？	影响面数据：多少用户、多高频、多痛
老板	ROI 是多少？	预期收益口径 + 成本，宁可保守
运营	和现有活动冲突吗？	上线节奏表
任何人	竞品的做法是什么？	竞品分析一段，说明我们为什么不同/相同

注意最后一行：**“我考虑过 B 方案，放弃的原因是 X”——这句话要在被问之前主动说出来。**它传递的信号是：这个需求是被认真想过的，不是拍脑袋来的。

现场的三条保命技巧

被问倒了，别现场编造。标准话术：“这个点我没准备好，今天下班前确认数据后同步给大家。“一次诚实的"我不知道”，比一次被戳穿的胡扯，对信用的伤害小一个数量级。
把"要不要做"的立场之争，引导成"先做哪一层"的方案之辩（第 7.2 节的吵架现场就是示范）。立场只能分输赢，方案可以谈共识。
散会前当场复述结论：“确认一下——做 A 功能的一二期，不做 B；技术周三前出排期，设计下周一出稿。“没有复述确认的会议，等于没开——每个人都带着自己理解的版本走出会议室，两周后对不上时再吵，成本翻十倍。

对老板汇报 vs 对团队评审：同一件事，两套语言

对老板：讲 ROI、风险和战略匹配度。“投入 3 人月，预期留存提升 2 个点；最大风险是 X，我们的对策是 Y。"——他要的是判断题，不是阅读理解。
对团队：讲逻辑、边界和为什么。“我们为什么选这条路、不做什么、异常 case 是什么。"——他们要做出来，需要的是确定性。

7. 沟通：产品经理的另一半工作是"翻译”

你没有权力，所以你所有的产出都靠影响他人。沟通的本质不是说服，是翻译——把同一件事，翻译成对方关心的语言。

7.1 对四种人说四种话

graph LR
    PM[产品经理] --> ENG[工程师<br/>讲逻辑与边界<br/>这个方案为什么这么设计<br/>异常case是什么]
    PM --> DES[设计师<br/>讲场景与感受<br/>用户此刻是焦虑的<br/>我们要给他确定性]
    PM --> BOSS[老板<br/>讲ROI与风险<br/>投入3人月<br/>预期提升留存2个点]
    PM --> OPS[运营<br/>讲卖点与节奏<br/>核心卖点一句话<br/>上线节奏配合活动]

7.2 需求被开发怼了怎么办 —— 一个真实的吵架现场

我：“这个搜索功能，我们要支持模糊匹配和拼音搜索。” 开发：“做不了，至少排一个月，你这个需求值吗？”

小白的回应：“老板说要做的。"（开发内心：哦，传话筒。）

资深的回应：“我看了数据，搜索失败率 23%，失败的会话次日留存低 40%。如果我们先做拼音首字母匹配——只用现有索引、不改算法——能覆盖失败量的 60%，这个 3 天能出吗？”

同一个需求，差别在于：资深产品经理带着数据和分层方案来，把"要不要做"的对立，变成"先做哪一层"的合作。

7.3 三条沟通铁律

永远在别人挑战你之前，先挑战自己。PRD 里写清楚"我考虑过 B 方案，放弃的原因是 X”——这一句顶十次解释。
当众给面子，私下讲道理。在会议上被质疑，先接住：“这个点问得好，我们看一下数据。“事后再一对一深聊。工程师的抵触，八成来自"不被尊重”，两成才来自方案本身。
把"我想要"改成"我们要解决的问题是”。前者是立场之争，后者是事实之辨。立场只能输赢，事实可以共识。

8. 数据驱动：别让直觉裸奔

8.1 北极星指标：一个团队只能仰望一颗星

graph TD
    NS[北极星指标<br/>例：周活跃收听用户] --> I1[输入指标1<br/>新用户激活率]
    NS --> I2[输入指标2<br/>人均播放时长]
    NS --> I3[输入指标3<br/>周留存率]
    I1 --> E1[可执行动作<br/>优化新手引导]
    I2 --> E2[可执行动作<br/>推荐算法迭代]
    I3 --> E3[可执行动作<br/>内容更新机制]

北极星指标的选择标准：它涨，说明用户价值在涨，商业价值迟早会涨。反例：把"广告收入"当北极星，团队会自然地向产品里塞广告，短期数字漂亮，长期用户流失——指标塑造了组织的行为，选错了指标等于选错了未来。

8.2 数据的三层读法

第一层：看趋势 —— 数据在涨还是在跌？（多数人到此为止）
第二层：看结构 —— 拆解到人群、渠道、场景。总留存没变，可能是新用户留存暴跌 + 老用户留存上升，完全不同的病情。
第三层：看人心 —— 数字背后用户在干什么？数据说"用户 30 秒就退出了直播间”，访谈才知道是因为主播开场前 30 秒都在调设备。数据告诉你 What，永远问不出 Why。

感悟：资深产品经理对数据的态度是"敬畏而不迷信”。A/B 测试能告诉你哪个按钮颜色点击高，但永远测不出"下一个微信应该长什么样”。数据用于优化已知，直觉用于探索未知——而直觉的质量，取决于你泡过多少用户。

9. 增长：AARRR 不是口号，是流水线的每一环

flowchart LR
    A[Acquisition 获取<br/>渠道投放、老带新] --> B[Activation 激活<br/>Aha!时刻]
    B --> C[Retention 留存<br/>核心价值重复交付]
    C --> D[Referral 传播<br/>自增长的飞轮]
    D --> E[Revenue 收入<br/>商业闭环]
    C -.->|留存不行时<br/>投钱获客等于烧钱填无底洞| A
    style B fill:#FFD700

9.1 最重要的一个概念：Aha! 时刻

Aha! 时刻是用户第一次感受到产品核心价值的瞬间：

Facebook：10 天内加 7 个好友
抖音：连续刷到 3 条喜欢的视频
记账 App：月底看到第一张消费报表

增长工作的第一优先级，不是拉新，而是把新用户尽快推过 Aha! 时刻。Facebook 增长团队当年发现"7 个好友"这个魔法数字后，把全部新手引导都改成了一件事：帮你找到认识的人。

9.2 增长的正确顺序

多数失败的团队顺序是反的：花钱买量 → 留不住 → 再买。正确顺序：先把留存做到及格线 → 再优化激活漏斗 → 最后才放大获取。水桶有洞的时候，先补洞，再加水。

10. 三个完整的产品设计故事

故事一：微信红包 —— 一个"顺手"改变的支付格局

2014 年春节前，微信支付被支付宝压得抬不起头。红包功能最初只是几个工程师的业余项目。

产品设计上的精妙之处：

graph TD
    R[微信红包的设计杠杆] --> A[场景寄生<br/>不教育用户，寄生在<br/>春节发红包的千年习俗上]
    R --> B[游戏化<br/>拼手气红包的金额随机<br/>等于多巴胺回路]
    R --> C[社交裂变<br/>发红包必须进群<br/>收红包必须绑卡]
    R --> D[心理账户<br/>抢来的8.88元是意外之财<br/>花起来毫无负担]

结果：一个春节，微信支付绑卡量完成了"支付宝八年走过的路”，被马云称为"偷袭珍珠港”。

产品课：最高明的产品设计，不是发明新需求，而是寄生在旧习俗上，用新交互点燃它。用户没觉得自己在"使用支付工具"，他觉得他在过年。

故事二：网易云音乐 —— 用"歌单"和"评论"在红海里撕开缺口

2013 年上线时，音乐市场是红海：版权被巨头瓜分，功能严重同质化。网易云做了两个反共识的决策：

以歌单为核心，而不是以曲库为核心。当时所有产品都是"搜索-播放"的工具逻辑，网易云赌的是"发现-收藏"的情感逻辑。歌单让用户成为内容生产者（UGC），也让迁移成本无限升高（沉没成本）。
把评论区当产品做。音乐是情绪的容器，而情绪需要出口。“网抑云"的评论文化不是运营出来的，是产品结构决定的：评论入口放在播放页最顺手的位置，点赞排序让高共鸣内容浮出水面。

产品课：红海竞争的破局点，通常不在主战场上（曲库、音质——你打不过巨头），而在巨头看不上、用户却在意的维度（情感连接、社区氛围）。差异化不是"我也有”，是"只有我有"。

故事三：拼多多 —— 把"消费降级"做成一门人性科学

2015 年，所有人都在讲消费升级，拼多多反着来。它的产品设计是人性的集大成者：

拼团：把购物从个人行为变成社交行为（社交证明 + 目标梯度）
砍一刀：损失厌恶（不砍就失去）+ 沉没成本（已经砍了 99%）+ 进度条游戏化
百亿补贴：锚定效应的极致——先建立"全网最低价"的心智锚点

sequenceDiagram
    participant U as 用户A
    participant F as 微信好友
    participant P as 拼多多
    U->>P: 看到"0元拿电饭煲"
    P->>U: 进度直接显示99%（目标梯度）
    U->>F: 转发"帮我砍一刀"
    F->>P: 点开链接（新用户获取完成）
    F->>F: "咦，我也试试？"（裂变启动）
    Note over P: 获客成本约等于0，获客动作由用户完成

产品课：拼多多的每个功能单独看都"上不了台面"，但组合起来是一台精密的裂变机器。它教会行业两件事：服务好"五环外"的沉默大多数，是最大的商业洞察；而把增长机制产品化（而非运营化），才是可复制的增长。

综合感悟：三个故事背后是同一条暗线——微信红包赢在场景，网易云赢在情感，拼多多赢在人性。产品力 = 场景理解 × 情感共鸣 × 人性洞察。三者居其一，可活；居其二，可成；三者兼备，是微信。

11. 思考与感悟：十年之后我才明白的事

11.1 产品经理的第一课是克制

年轻时我以为产品经理是"创造者"，后来发现是"守门人"——守住产品的简单，挡住一百个"顺便加上"的需求。张小龙说"每天有 1 亿人教我怎么做产品"，他的回应是克制。产品的伟大不在于它做了什么，而在于它抵抗住了什么。

11.2 同理心不是天赋，是工作量

“理解用户"听起来像玄学，实际上是体力活：每周看 100 条用户反馈，每月做 5 个深度访谈，用自己的产品用到吐。所谓产品直觉，不过是大量用户样本在你脑子里的沉淀。

11.3 所有方法论都会过期，只有一件事不会

KANO 会老，AARRR 会旧，明天会有新的增长黑话。但有一件事从福特时代到今天没变：用户遇到问题时那种真实的烦躁，和问题解决后那种真实的轻松。 离这两种情绪越近的产品经理，越不会失业。

11.4 关于职业的一句话

产品经理是离"创造"最近的职业之一 —— 你的一句话会变成千万人每天触碰的东西。这份权力的代价是：你犯的每个错，也会被千万人每天触碰。 所以，对人性的理解越深，越要对人性保持敬畏。

12. 从小白到资深的成长路线图

journey
    title 产品经理成长之路
    section 第1年：执行
      写好PRD讲清边界: 3: 我
      跟进项目不延期: 3: 我
      建立自己的需求池: 4: 我
    section 第2-3年：方法
      独立负责一条产品线: 4: 我
      用数据验证而非争论: 4: 我
      第一次说不并活下来: 5: 我
    section 第4-5年：判断
      定义北极星指标: 5: 我
      做出一个Aha时刻设计: 5: 我
      带团队打一场胜仗: 5: 我
    section 第5年+：洞察
      看透人性并保持敬畏: 5: 我
      从做产品到定义赛道: 5: 我

最后，送你一张可以贴在显示器上的自查表：

我今天做决策的依据，是数据/用户，还是职位比我高的人的一句话？
我拒绝的需求，比接受的多吗？
我上一次和真实用户聊天，是这周之内吗？
我设计的功能，敢给我爸妈用吗？
如果砍掉我负责的这款产品，用户会难过，还是无感？

五个问题都答得坦荡的那天，你就是资深了。

完。愿你做出让自己骄傲的产品。

《黑客与画家》创业学习笔记：用艺术思维重构技术变现

Sun, 09 Feb 2020 21:06:04 +0800

《黑客与画家》创业学习笔记：用艺术思维重构技术变现

参考书籍：Paul Graham《黑客与画家》（Hackers and Painters）。
目标读者：想学创业、正在做副业、或者想把技术变成产品的程序员。
阅读目标：把 Graham 的散文重新组织成一套可重复、可操作的创业思考框架。

Paul Graham 是 Y Combinator 的创始人之一，也是 Lisp 程序员和画家。《黑客与画家》不是一本标准的创业教材，它更像是一个资深创客的笔记集合。但对创业程序员来说，这本书里藏着一套非常底层的操作系统：

技术不只是谋生技能，它是创造财富的杠杆；
创业不是赌运气，而是可以被训练的方法；
好的工具和算法，直接决定你能走多远；
写代码和画画，本质上是同一件事。

这篇文章我把书中对我最有启发的内容，整理成 6 个模块。每个模块都尽量用新人能听懂的方式写，并给出可以落地的思考清单。

一、用艺术思维重构技术变现路径

1.1 黑客和画家的共同本质：都是 maker

Graham 说，黑客（优秀的程序员）和画家的相似度，远高于黑客和计算机科学家的相似度。

画家创作的过程是：

先有草图和想法；
不断修改、推翻、重画；
最终作品呈现出来，别人才会评价。

黑客写软件的过程几乎一样：

先写出一个能跑的原型；
根据用户反馈不断迭代；
产品上线后，市场才会给出真实反馈。

两者都不是"先想清楚再一次性做对"，而是在做的过程中想清楚。

1.2 艺术思维破解技术困局

很多程序员陷入一个困局：

“我技术很好，但不知道怎么赚钱。”

技术思维会问：“这个功能怎么实现？”
艺术思维会问：“用户真正需要的是什么？我能不能做出一个让他眼前一亮的东西？”

两者的区别是：

技术思维	艺术思维
关注实现难度	关注用户感受
追求系统完美	追求表达清晰
害怕改动	拥抱迭代
以功能为中心	以体验为中心

创业程序员真正值钱的能力，不是"会多少技术栈"，而是用技术做出别人愿意付费的作品。

1.3 重构"技术 → 财"的路径

传统路径：学好技术 → 找好工作 → 拿高薪。

Graham 给出的路径：

做出一个真正解决问题的东西 → 通过公司或产品把它规模化 → 创造财富。

这个差别非常关键。打工是把自己的时间卖一次；创业是把一个解决方案卖很多次。程序员的优势是，这个解决方案可以用代码复制。

1.4 案例：艺术思维如何决定产品成败

✅ 正面：Instagram 的减法艺术

Instagram 最初并不叫 Instagram，而是一个叫 Burbn 的 LBS 签到应用，功能复杂、界面混乱，用户增长缓慢。创始人 Kevin Systrom 和 Mike Krieger 没有继续堆功能，而是用艺术思维做了一次大胆的减法：

删掉签到、积分、优惠券等复杂功能；
只保留“拍照 + 滤镜 + 分享”三个核心动作；
把照片设计成统一的正方形，强化视觉风格。

结果：Instagram 在上线第一天就吸引了 2.5 万用户，18 个月后以 10 亿美元被 Facebook 收购。它的成功不是技术更先进，而是对用户情绪的精准表达。

❌ 反面：Google Glass 的技术傲慢

Google Glass 是一项令人惊艳的技术：头戴显示器、语音控制、实时拍照。但它失败的原因之一，是过于关注“我们能做出什么”，而不是“用户愿意在什么场景下使用什么”。

佩戴者被贴上“Glasshole”的标签，社交接受度极低；
没有明确的杀手级使用场景；
隐私争议和法律法规限制让它难以进入主流市场。

Google Glass 后来转向 B 端工业场景才找到生存空间。这个案例说明：技术再酷，如果缺乏对用户感受的理解，也很难变现。

新人行动清单：

写下你最近 3 个月遇到的 5 个"让人烦躁"的问题。
这些问题里，有没有一个能用 100 行代码做出原型？
如果做出来了，谁会愿意为它付费或省时间？

二、可以重复的创业思想

Graham 的创业思想不是鸡汤，而是一套可以反复训练的方法。

2.1 创造财富，而不是重新分配财富

Graham 有一个核心观点：财富不是固定的蛋糕，而是被创造出来的。

很多人以为创业就是"从别人口袋里掏钱"，但真正伟大的创业是让整个世界多出本来不存在的东西：一个新的效率工具、一个更好的沟通方式、一个省时间的流程。

程序员的创业，本质上是把想法变成代码，把代码变成产品，把产品变成别人愿意付钱的价值。

✅ 正面：Stripe 让互联网经济多了一套基础设施

Patrick 和 John Collison 创办 Stripe 时，发现网上收款远比想象中复杂：商家要对接银行、处理 PCI 合规、写大量支付逻辑。Stripe 没有发明“支付”这件事，但它通过一套简洁的 API，把原本需要几个月的接入工作缩短到几行代码。

Stripe 创造的价值是真实的：它让无数小公司和个人开发者第一次能轻松收钱。到今天，它处理的年交易额以万亿美元计。这就是 Graham 所说的“创造财富”——不是从别人口袋里抢钱，而是让经济活动本身变得更顺畅。

❌ 反面：Groupon 的财富再分配困境

Groupon 早期增长惊人，但它创造的核心价值其实有限。它的模式更像是一种“优惠券分销渠道”：把商家利润的一部分转移给消费者，自己从中抽成。

商家后来发现促销用户忠诚度低，盈利能力差；
消费者养成了“只买打折”的习惯；
竞争者蜂拥而入，护城河很浅。

Groupon 的市值从最高约 160 亿美元跌到不足 10 亿美元。它提醒我们：如果商业模式只是重新分配既有财富，而不是创造新的价值，长期很难维持。

2.2 小公司 + 高技术杠杆率 = 高回报

传统公司靠堆人、堆资源扩大产出。创业公司靠的是技术杠杆率：

几个人写出的软件，可以服务上百万用户；
一次开发，边际成本接近零；
决策快，迭代快。

这也是 Graham 推崇"小型创业团队"的原因。不是人多力量大，而是对的人 + 对的工具 + 对的方向力量大。

✅ 正面：WhatsApp 用 55 人服务 4.5 亿用户

WhatsApp 被 Facebook 以 190 亿美元收购时，整个公司只有约 55 名员工，却服务着超过 4.5 亿月活用户。它能在 Skype、MSN 已经存在的情况下崛起，靠的不是“功能更多”，而是定位更准、架构更轻、运营更省。

为什么它能从 Skype/MSN 手里抢用户？

WhatsApp	MSN / Skype
替代手机短信，移动原生	PC 时代的在线聊天工具
基于手机号，自动匹配通讯录	需要注册用户名、手动添加好友
异步消息，像短信一样随时收发	“在线/离线”状态模型
界面极简，只做消息	功能臃肿，广告多
跨运营商、跨国界免费	短信贵，国际短信更贵

对欧洲、拉美、印度等市场的用户来说，WhatsApp 不是“另一个聊天软件”，而是**“不用花钱的全球短信”**。这个痛点比 Skype 的视频通话、MSN 的娱乐功能更刚需。

为什么 55 人能支撑 4.5 亿用户？

极简产品：早期只有文字、图片、位置等基础功能，没有游戏、贴纸、广告系统，维护成本极低；
高效架构：后端用 Erlang 编写，单台服务器可支撑约 100 万个并发连接；
不长期存储消息：消息送达后从服务器删除，极大降低存储和合规成本；
病毒式增长：靠通讯录自动匹配和口碑传播，不需要市场投放团队；
无广告、轻客服：团队不需要销售、广告运营或庞大客服。

它靠什么盈利？

早期：首年免费，之后 0.99 美元/年的订阅费；
被收购后：2016 年取消订阅费，C 端完全免费；
现在：通过 WhatsApp Business API 向企业收费，企业按对话次数付费给客户发通知、客服消息、营销消息；同时发展 WhatsApp Pay 等金融服务。

本质上是 C 端免费占领通讯基础设施，B 端收费变现商业价值。

WhatsApp 证明：几个人用对的工具、切对的问题、保持极简，完全可以做出影响十亿人的产品。

❌ 反面：Color 的“堆人堆钱”失败

2011 年，Color 融资 4100 万美元，团队 41 人，产品还没上线就备受瞩目。它的理念是“基于位置的匿名社交照片分享”，但问题在于：

创始人没有验证用户是否真的需要这种体验；
大量资金花在豪华办公室和高薪上，而不是产品和用户反馈；
上线后用户很快流失，产品方向多次摇摆。

Color 最终悄无声息地关闭。这个案例说明：没有技术杠杆和用户验证，只靠人和钱堆不出好产品。

2.3 做那些"不会规模化"的事

YC 有一句名言：Do things that don’t scale.

初期不要急着写完美的平台，而是：

手动服务前 10 个用户；
亲自打电话收集反馈；
为用户做定制化修改。

你的目标不是一开始就做大规模，而是先找到真正愿意付费的人，再想办法自动化。

✅ 正面：Airbnb 创始人亲自上门拍照片

Airbnb 早期增长缓慢，Brian Chesky 和 Joe Gebbia 没有急着写更复杂的平台，而是做了一件“完全不会规模化”的事：亲自去纽约，挨家挨户给房东拍照，帮他们优化房源页面。

他们理解了房东真正关心什么；
照片质量提升后，订单量明显增长；
这些手工经验后来被产品化成摄影服务和智能建议。

Airbnb 今天的规模，正是从那些“不能规模化”的笨功夫里长出来的。

❌ 反面：Webvan 的“先规模化再找用户”

Webvan 是 1999 年互联网泡沫时期的明星公司，它想在网上卖杂货并自建配送体系。公司在还没验证商业模式之前，就花了 10 亿美元建仓库、买车队、招大量员工，试图“一次性做到全国”。

它假设消费者会大规模转向在线购菜，但没有验证；
高昂的固定成本让它现金流迅速断裂；
2001 年破产，成为“过早规模化”的经典反面教材。

Webvan 和 Airbnb 的对比告诉我们：在没有验证需求之前，自动化和规模化不是优势，而是负债。

2.4 选择好的问题，比解决问题更重要

Graham 强调，创业失败最常见的原因不是"做得不好"，而是**“做了一个没人需要的东西”**。

如何判断问题好不好？问自己三个问题：

这是你自己也有的痛点吗？ 自己需要的东西，理解最深刻。
解决后用户愿意付钱吗？ 愿意付费代表真实需求。
这个市场规模足够大吗？ 小市场养不出大公司，但大副业可以。

✅ 正面：Slack 从“失败的电子游戏”里找到真问题

Slack 的创始人 Stewart Butterfield 最初想做的是一款多人在线游戏 Glitch。游戏失败后，团队发现自己内部开发的一个通讯工具特别顺手，于是决定把它做成产品。

他们自己就是目标用户，深知团队沟通的痛点；
产品切入的是“电子邮件太笨重、IRC 太原始”的空白地带；
从游戏团队扩展到硅谷科技公司，再扩展到各行各业。

Slack 最终成为市值数十亿美元的公司。它的起点不是“我要做一个聊天软件”，而是“我们自己亟需一个更好的工具”。

❌ 反面：Juicero 解决了一个不存在的问题

Juicero 曾融资超过 1 亿美元，推出一台售价 700 美元的联网榨汁机，搭配售价 5～8 美元的果蔬包。它的理念是“用技术和设计重新定义榨汁”。

用户很快发现，用手挤果蔬包也能榨出汁，机器并非必需；
目标用户（健康生活方式人群）不愿意为这种便利付高价；
产品复杂、成本高、订阅模式僵硬。

Juicero 在 2017 年倒闭。它的失败完美诠释了 Graham 的警告：最难发现的失败，是你做了一个没人真正需要的东西。

新人行动清单：

列出你周围 3 个人最近抱怨过的问题。
用 1 句话描述：“我帮 XX 人群解决了 YY 问题。”
思考：这个问题是"维生素"（有了更好）还是"止痛药"（没有不行）？优先做止痛药。

三、如何寻找创业机会

Graham 关于"如何找到创业点子"的思考，是书里最实用的部分之一。

3.1 最好的点子来自"生活的不满"

不要坐在那里想"我要创业"，而是：

留意你生活中那些"怎么这么麻烦"“为什么没人做这个"的瞬间。

Graham 自己和同伴创办 Viaweb，就是因为他们觉得当时做电商网站太麻烦了。YC 孵化的很多项目，创始人最初都是想解决自己的问题。

3.2 待在"上游”（Stay upwind）

Graham 建议年轻人选择职业方向时，要"待在上游"。意思是：

做那些能让你积累长期能力、长期选项的事；
不要只看眼前工资，要看未来能打开多少扇门。

对程序员来说，“上游"可能是：

学习生成式 AI、分布式系统、编译器等底层技术；
参与开源项目，建立技术声望；
写作、演讲、做产品，积累影响力。

3.3 关注"边缘但快速增长"的需求

大公司的优势是服务主流市场，但主流市场往往意味着红海。

创业公司的机会通常出现在：

新技术刚出现，大公司还没反应过来；
小众人群有强需求，但现有产品很差；
法律法规、社会习惯变化带来的新场景。

3.4 做"自己就是用户"的产品

这是 Graham 反复强调的：如果你自己就是目标用户，你就有天然的信息优势。

你知道问题有多痛、现有方案有多烂、用户真正愿意为什么付费。这些都是坐在办公室做市场调研得不到的。

3.5 案例：机会来自真实不满，而非会议室想象

✅ 正面：Dropbox 从一个“忘带 U 盘”的瞬间诞生

Drew Houston 创办 Dropbox 的灵感，来自一个极其具体的挫败：他在公交车上带着笔记本电脑，却发现需要的文件存在另一台电脑里，随身带的 U 盘又忘带了。

他自己就是这个产品的目标用户；
当时的云存储方案要么复杂（FTP），要么不靠谱（自己搭服务器）；
他先做了一个 3 分钟的产品演示视频，验证需求后再投入开发。

Dropbox 从一个私人痛点出发，最终服务了数亿用户。这正是 Graham 所说的“最好的点子来自生活的不满”。

❌ 反面：Quibi 用好莱坞预算拍给想象中的用户

Quibi 由迪士尼前高管 Jeffrey Katzenberg 创办，融资 17.5 亿美元，主打“为手机竖屏观看制作的高品质短视频”。它的问题在于：

创始人不是目标用户，需求来自会议室推断；
高价签约明星制作内容，但用户并不愿意为短视频付费；
上线时正好遇到疫情，通勤场景消失，产品定位进一步崩塌。

Quibi 在上线不到 6 个月后就被出售。它的失败说明：没有真实用户验证的“高端需求”，再强的团队和资本也推不动。

新人行动清单：

记录一周内你遇到的 10 个"不爽时刻”。
标记其中 3 个可以用技术改善的。
对每个潜在机会，回答：“我自己会用它吗？”

四、算法的重要性

《黑客与画家》里有很多关于 Lisp、编程语言和算法的讨论。Graham 是 Lisp 的狂热信徒，他推崇的不是 Lisp 这门语言本身，而是Lisp 代表的那种思维方式。

4.1 算法是软件的"引擎"

算法不只是面试题。在现实产品中，算法决定了：

推荐系统能不能给用户想要的内容；
搜索引擎能不能在毫秒级返回结果；
支付系统能不能在高并发下保持正确；
AI 应用能不能在有限算力里产生有价值的输出。

一个好的算法，可以让一个小团队做出大公司才能做的效果。

4.2 学习算法的真正目的

不是为了刷题，而是为了训练三种能力：

抽象能力：把复杂问题拆成可计算的小问题。
效率意识：知道什么时候该优化，优化到什么程度。
工具感：知道世界上已经有哪些现成方案，避免重复造轮子。

4.3 创业程序员该优先掌握的算法方向

搜索与排序：几乎所有产品都需要查找和排名。
图算法：社交网络、推荐、路由、依赖分析都用得上。
动态规划与贪心：资源调度、路径规划、定价策略的底层思路。
概率与统计：A/B 测试、推荐系统、风控模型都离不开。
机器学习基础：即使没有做 AI，理解模型如何学习、如何泛化，也能帮你做出更智能的产品。

4.4 案例：算法如何成为竞争壁垒

✅ 正面：Google 用 PageRank 算法超越雅虎

1998 年，Google 还只是一家小公司，而雅虎是互联网门户巨头。Google 的制胜武器不是更多内容，而是 PageRank 算法——它通过网页之间的链接关系来评估重要性，而不是单纯看关键词密度。

搜索结果质量显著优于当时的竞争对手；
算法让一个小团队挑战并超越了行业巨头；
PageRank 后来成为现代搜索引擎的基础思想之一。

Google 的故事说明：一个好的算法，可以让小公司做出大公司做不到的效果。

❌ 反面：Orkut 在社交推荐上输给了 Facebook

Orkut 是 Google 早期推出的社交网站，在巴西和印度一度非常流行。但它最终被 Facebook 超越，其中一个原因是算法和用户体验上的差距：

Orkut 的页面设计杂乱，好友推荐和内容排序不够智能；
Facebook 的新闻 feed 算法和社交图谱设计更能留住用户；
当网络效应需要算法来放大时，Orkut 没有跟上。

Orkut 在 2014 年关闭。它提醒我们：在社交网络、推荐、搜索这些产品里，算法不是锦上添花，而是生死线。

新人行动清单：

选一个你正在做的项目，找出一个可以用算法优化的地方。
每周花 2 小时学习一个经典算法，并尝试用代码实现。
阅读一个开源项目里你感兴趣的算法实现。

五、开发工具的重要性

Graham 对工具的重视，贯穿全书。他认为工具直接影响思考效率和产品上限。

5.1 工具是你的"第二大脑"

好的开发工具：

让你把注意力放在问题本身，而不是语法和配置；
缩短"想法 → 代码 → 验证"的循环；
让一个人能完成过去需要一个团队做的事。

5.2 选择能让你"更快迭代"的语言和框架

Graham 创办 Viaweb 时用的是 Lisp，一个当时被认为"不实用"的语言。他选择 Lisp 的原因是：

表达力强，能快速写出复杂逻辑；
适合快速原型和快速修改；
让团队跑得比竞争对手快。

今天，对创业程序员来说，最重要的不是追新，而是选适合自己、能提高迭代速度的工具链。

5.3 现代创业程序员的工具箱建议

编程语言：Python（AI/脚本）、TypeScript（全栈）、Go/Rust（高性能服务）。
AI 助手：Cursor、GitHub Copilot、Claude Code 等，把自然语言变成代码草稿。
云服务：Vercel、AWS、GCP、阿里云，降低运维门槛。
数据与实验：PostgreSQL、Redis、ClickHouse，配合 A/B 测试工具。
协作与发布：Git、GitHub Actions、Notion、Figma。

5.4 不要沉迷工具，但要善用工具

工具永远服务于目标。 Graham 反对的是"为了用某个语言而用某个语言"，他推崇的是"选最能帮你赢的工具"。

对新人来说，与其纠结"学哪个框架"，不如：

先做出一个能用的东西；
在真实场景中感受工具的瓶颈；
有针对性地升级工具链。

5.5 案例：工具选择决定团队天花板

✅ 正面：Figma 用 Web 技术重构设计协作

Figma 创办时，设计界的主流工具是 Adobe 系列和 Sketch，都是桌面软件，协作靠传文件。Figma 选择用 Web 技术（WebGL + 实时协作算法）做一个浏览器里的设计工具。

设计师不再需要安装软件，打开链接就能协作；
多人实时编辑同一个文件，彻底改变工作流；
以工具为入口，逐步扩展成设计和原型平台。

Figma 后来以 200 亿美元被 Adobe 收购（虽然最终因监管未通过）。它的成功证明：选对工具，不只是提高效率，还可能重新定义整个行业。

❌ 反面：Adobe Flash 被封闭工具拖垮

Flash 曾经是网页动画、视频和游戏的王者。但它的失败，很大程度上是因为它是一个封闭、专有、依赖插件的工具生态：

移动设备不支持 Flash，iPhone 时代到来后迅速失势；
安全漏洞频发，浏览器厂商逐渐放弃支持；
HTML5、CSS3、JavaScript 等开放标准崛起后，Flash 没有跟上。

Adobe 最终在 2020 年底停止支持 Flash。这个案例说明：工具不仅要好用，还要符合技术演进的趋势，过度封闭会被开放生态取代。

新人行动清单：

检查你目前的工具链，找出 3 个拖慢你迭代速度的环节。
学习一个能提升效率的新工具，并在本周的项目中试用。
建立一套自己的代码模板或脚手架，减少重复劳动。

六、其他亮点

除了以上 5 点，《黑客与画家》里还有很多值得反复咀嚼的思想。

6.1 “不能说的话"与创新

Graham 提醒我们，社会上有一些"不能说的话”。真正重要的新思想，往往在最初都是冒犯的、反常的。

创业者不需要刻意叛逆，但要保持独立思考：

为什么大家都这样做？
这个假设真的成立吗？
如果我换一种方式，会不会更好？

✅ 正面：Tesla 质疑“电动车不可能高端”

2008 年，当 Tesla 推出 Roadster 时，主流汽车行业的共识是：电动车只能是廉价、短途、小众的代步工具。Elon Musk 和团队质疑了这个假设：

为什么电动车不能先做高端跑车？
为什么不能先从有钱的早期采用者切入？
为什么电池技术不能通过规模化持续降本？

Tesla 的“离经叛道”最终重塑了整个汽车行业。这个案例说明：真正重要的创新，往往始于对共识的质疑。

❌ 反面：Segway 的创新没有真实场景

Segway 在 2001 年发布时被寄予厚望，甚至被称为“个人交通的未来”。但它的问题在于：

它解决的是一个想象中的需求（城市短途出行），而非真实痛点；
价格昂贵、使用场景受法规限制、社交接受度不高；
创始人对产品的热情，没有转化为大众市场的真实需求。

Segway 最终被一家中国公司收购，主要用于旅游观光和特定 B 端场景。它提醒我们：质疑共识很重要，但质疑之后还要验证需求是否真的存在。

6.2 品位是可以训练的

Graham 认为，设计不仅仅是外观，设计是事物如何运转。好的黑客必须有好品位，而好品位来自：

大量看好作品；
大量做作品并接收反馈；
持续反思"什么是更好的"。

对创业程序员来说，“品位"体现在：

产品界面是否简洁；
API 是否优雅；
用户流程是否自然；
代码是否容易维护。

✅ 正面：Apple 把“品位”变成护城河

Steve Jobs 回归苹果后，第一件事就是砍掉大量杂乱的产品线，把设计品位提升到公司战略层面。iPod、iPhone、MacBook 的成功，不只是功能领先，更是因为：

界面和交互经过反复打磨；
硬件和软件高度统一；
用户从开箱到使用都能感受到细节。

Apple 的利润率长期高于同行，很大程度上来自“品位”带来的品牌溢价和用户忠诚度。

❌ 反面：MySpace 因设计失控被 Facebook 取代

MySpace 曾是全球最大的社交网站，但它的页面设计逐渐失控：

用户可以自由定制 HTML，导致页面杂乱、加载慢；
产品功能越堆越多，核心体验变得模糊；
Facebook 以简洁、统一的界面吸引了大量用户迁移。

MySpace 的衰落有很多原因，但“品位”的缺失是重要一环。它说明：设计的混乱会传导为产品定位的混乱，最终失去用户。

6.3 学校教不了你创业

Graham 对传统教育持批判态度。他认为学校擅长培养"听话的员工”，但不擅长培养"能创造新事物的人"。

这不是说读书无用，而是说：

创业真正需要的技能——发现需求、快速学习、承担不确定性、组建团队——大多要在实战中学。

✅ 正面：Mark Zuckerberg 在宿舍里验证需求

Mark Zuckerberg 在哈佛大学宿舍创办 Facebook 时，并没有先去读 MBA，也没有写一份商业计划书。他做的第一件事是：

快速做出一个粗糙的网站，让哈佛学生给同学照片打分；
观察用户行为，发现真实需求是“了解身边人的动态”；
在真实使用中不断迭代，而不是在会议室里推演。

Facebook 最早的版本功能非常简单，但它验证了一个真实存在的需求。Zuckerberg 的成功不是来自学校，而是来自快速行动和持续学习。

❌ 反面：许多 MBA 创业者的“完美计划”落空

硅谷并不缺名校 MBA 毕业生带着精美的商业计划书和 PPT 创业。但很多人失败的原因是：

过度依赖理论和模型，脱离真实用户；
花太多时间写计划，太少时间验证假设；
擅长融资讲故事，但不擅长做出有人用的产品。

这不是说 MBA 无用，而是说：创业的核心能力只能在实战中锻炼，书本和计划无法替代用户反馈。

6.4 有钱和创造财富是两回事

Graham 区分了"赚钱"和"创造财富"。赚钱可能是套利、投机、截流；创造财富是真正让社会总福利增加。

创业程序员最值得追求的，不是短期套现，而是持续创造价值的能力。

✅ 正面：Salesforce 创造了 CRM 云市场

Salesforce 创办时，企业软件的主流模式是卖光盘、本地部署、收取高额维护费。Marc Benioff 提出“No Software”口号，把 CRM 搬到云端：

企业不再需要自己买服务器、雇 IT 维护；
按月订阅，降低了中小企业的使用门槛；
创造了一个全新的 SaaS 市场，让 Salesforce 和无数企业共同受益。

Salesforce 的成功不是套利，而是创造了新的价值形态。

❌ 反面：WeWork 把“包装”当成价值创造

WeWork 曾是硅谷最具话题性的公司之一，估值一度高达 470 亿美元。但它的问题在于：

它本质上是一家二房东，却把自己包装成“科技公司”；

注：WeWork 不是严格意义上的硅谷纯科技公司，但其融资和叙事深受硅谷影响。
高速增长靠烧钱和复杂金融操作支撑；
没有真正的技术护城河，用户迁移成本很低。

WeWork 上市后估值暴跌，成为“资本运作大于价值创造”的典型反面教材。它提醒我们：有钱、有估值、有故事，都不等于创造了真正的财富。

七、给新人的一句话总结

把自己当成一个用代码创作作品的艺术家，而不是一个等待任务分配的工人。

技术是手段，产品是作品，财富是作品被需要之后的结果。创业不是冲动，而是一套可以被训练的思维习惯：

观察自己的不满，找到真实需求；
用艺术思维打磨产品，而不是只堆功能；
用算法和工具放大个人产出；
小步快跑，先服务少数人，再考虑规模化；
持续创造价值，而不是只追求赚钱。

《黑客与画家》最有价值的地方，不是给了一个成功公式，而是让我们重新理解：写代码可以是一种创造性的工作，而创业，是把这种创造力商业化的最好方式之一。