《Founders at Work》笔记：32 份一手证词比二手报告值钱

方糖猫 方糖猫
- 约 26 分钟读完 - 全文 10093 字

《Founders at Work》笔记：32 份一手证词比二手报告值钱

Jessica Livingston 是 Y Combinator 的联合创始人，2007 年她把对 32 位科技公司创始人的访谈结集出版，就是这本《Founders at Work》。这本书没有框架、没有方法论章节、没有"创业十步法"——它就是一叠访谈实录：PayPal 的 Max Levchin、Apple 的 Wozniak、Hotmail 的 Sabeer Bhatia、Viaweb 的 Paul Graham、Blogger 的 Ev Williams、craigslist 的 Craig Newmark……每个人对着录音笔讲自己当年怎么把公司从零做起来的。

我读它的动机很直接：市面上讲创业的书大多是记者和学者写的二手报告，故事被磨得又圆又亮，因果链条清晰得像事后编的。而这本书的价值恰恰在于"没打磨"——幸存者自己讲的故事里，能看到 pivot 的狼狈、缺钱的窘迫、被投资人拒绝的真实细节。一手证词比二手报告值钱，这是我读完最大的方法论收获。

这篇笔记干三件事：先讲为什么一手访谈这种体裁值钱；再从 32 份访谈里提炼出反复出现的共性模式；最后挑 5 个案例展开讲关键细节。

一、为什么一手访谈 > 二手报告

做工程的人都知道：线上事故的复盘，值班工程师的口述记录比一个月后管理层写的 PPT 有用得多。PPT 里事故是一条干净的因果链：“因为配置错误，所以服务宕机，所以我们加了检查项”。而口述记录里全是毛边：“当时我以为是缓存问题，重启了两次没好，才发现 DNS 也不对，中间还有半小时我们在争论要不要回滚”。

二手报告的毛病有三个：

  • 幸存者偏差的二次方。报告本来就在写幸存者，写的时候又把幸存者叙事里的随机性和运气抹掉，只剩下"远见"和"执行力"；
  • 事后合理化。人回忆成功路径时会不自觉地把它讲成一条直线，当年明明是从 A 想法 pivot 到 B 才活下来的，讲出来就成了"我们一开始就看好 B"；
  • 细节损耗。真正有用的信息全在细节里——融不到钱时团队怎么活、第一个用户从哪来、被巨头拒绝时怎么办——这些在二手报告里通常被压缩成一句"经历了艰难的早期"。

同一段历史，两种载体，信息的衰减路径完全不同：

flowchart LR
    subgraph SRC["真实历史：混乱、偶然、缺钱、走运"]
        R["当事人的记忆<br/>带毛边、带情绪、带具体数字"]
    end
    subgraph PATH1["一手路径"]
        A["访谈实录<br/>具体、未经包装<br/>但可能有记忆偏差"] --> A1["读者自己提炼模式"]
    end
    subgraph PATH2["二手路径"]
        B["记者/学者转述"] --> B1["被磨成光滑因果链<br/>运气被删除<br/>细节被压缩成'早期艰难'"]
    end
    R --> A
    R --> B

两条路径各有偏差：一手路径的偏差是"当事人记错或自我美化"，二手路径的偏差是"转述者替你做了归因"。前者你能自己校准，后者你连校准的机会都没有——因果链已经替你想好了。

Livingston 的访谈好在她问的都是具体的、难以编造的问题：“你们第一天在干什么？““钱什么时候快烧完的？““投资人具体是怎么拒绝你们的？“被访者的回答未经公关包装，经常有"说实话当时我们根本不知道在干什么"这种话。

感悟：这跟看技术文档是一个道理——官方文档告诉你 API 怎么用，但只有源码和 issue 区告诉你它在什么情况下会炸。一手访谈就是创业史的"源码 + issue 区”。

当然，一手访谈也不是没有偏差：幸存者毕竟还是幸存者，记忆会自我美化。我的读法是：信细节，不信结论。创始人总结的"成功是因为我们坚持用户至上"听听就好，但"我们账上只剩够发一个月工资的钱"这种细节，多半是真的。

二、32 份访谈里反复出现的创业共性模式

把 32 个故事叠在一起看，有些模式出现的频率高到不可能是巧合。我画了一张图来归纳：

flowchart TB
    subgraph P1["① 起点：想法经常不是最后做成的那个"]
        A1["从别的想法出发<br/>pivot 是常态而非意外"] --> A2["PayPal: PalmPilot 加密 → 邮件支付<br/>Blogger: 项目管理工具 → 博客发布器"]
    end
    subgraph P2["② 早期：不被理解"]
        B1["投资人看不懂<br/>巨头看不上<br/>用户也不是调研出来的"] --> B2["Apple 被 HP 拒绝多次<br/>Hotmail 融资四处碰壁"]
    end
    subgraph P3["③ 生存：缺钱是默认状态"]
        C1["融资艰难<br/>创始人不拿工资<br/>账上只剩几个月"] --> C2["Blogger 员工走光只剩 Ev 一人<br/>Viaweb 靠接单养产品"]
    end
    subgraph P4["④ 顺序：先有产品，后有商业模式"]
        D1["先把东西做出来<br/>让用户用上"] --> D2["Hotmail 增长先于盈利模型<br/>craigslist 多年不收费"]
    end
    P1 --> P2 --> P3 --> P4

这四条单独看都不新鲜，创业鸡汤里全有。但访谈实录的价值在于给你看每条模式的具体纹理：

  • pivot 不是战略会上拍板的优雅转身，而是"原来的东西没人要，账上钱在烧，不得不试点别的”；
  • “不被理解"不是一句带过，而是 Apple 被 HP 正式拒绝了不止一次，Wozniak 甚至愿意把设计白送给 HP；
  • “缺钱"不是励志修辞，而是 Ev Williams 看着员工一个个离开、最后一个人守着服务器；
  • “先做产品后想商业模式"不是方法论选择，而是大多数时候根本没时间想——Hotmail 的用户增长速度让带宽账单先成了问题。

感悟：读多了你会发现，成功的创业故事和失败的创业故事，在早期阶段长得几乎一模一样——都缺钱、都被拒绝、都在 pivot。差别往往只在"有没有活到 pivot 成功的那一天”。所以"活下去"不是底线思维，它就是主线。

三、案例一：PayPal——两次 pivot 才到支付

PayPal 的故事是"pivot 是常态"这条模式最完整的样本。Max Levchin 在访谈里讲得很坦白：

最初的创业方向（公司前身 FieldLink，后改名 Confinity）是做 PalmPilot 上的加密技术——在 PDA 上存储加密信息，比如密码和卡号。技术很酷，问题是没人需要。于是他们在这个技术上加了一层应用：通过 PalmPilot 的红外端口互相转账——两台 PalmPilot 对着"嘀"一下，钱就过去了。这个演示效果极好，投资人当场被镇住，钱也拿到了。

然后尴尬的事情发生了：红外转账是个炫酷的演示，但现实中没几个人同时拿着 PalmPilot 站在一起还要互相转账。真正有人用的，是他们顺手做的那个"网页版/邮件版"的支付功能——给功能做演示用的网站，结果用户全跑到网页上转账去了，尤其 eBay 上的卖家买家。

公司的应对是跟着用户走：把重心彻底转到网页/邮件支付，PalmPilot 那条线砍掉。这才有了后来我们认识的 PayPal。

几个我觉得值得记的细节：

  • 演示效果 ≠ 市场需求。红外转账在投资人面前是无敌的 demo，在市场上是无用的功能。能分清这两者的团队不多；
  • 安全攻防是真实的生存战。Levchin 讲了大量与欺诈者对抗的细节——俄罗斯的黑客团伙规模化地薅羊毛，PayPal 被迫自研风控（后来演变成著名的验证码应用之一和整套反欺诈系统）。支付公司的核心竞争力一半是反欺诈；
  • pivot 不是抛弃技术。早期的加密技术积累，最后全用在了支付安全上。换方向不等于清零。

感悟：这个案例对我这个工程师的触动是——工程师最容易爱上"技术上漂亮"的东西（红外点对点转账多优雅），但市场只为"解决真实麻烦"的东西付钱（网上陌生人之间怎么安全地付款）。Levchin 自己就是技术出身，他能两次压下对技术的偏爱跟着用户走，这比写出加密算法难多了。

四、案例二：Apple——被 HP 拒绝了五次的个人电脑

Wozniak 的访谈是全书里我最喜欢的一篇，因为他讲东西的方式完全是工程师的：具体到芯片选型、怎么省元器件、怎么在频率上做手脚绕过 FCC。

关键史实线：

  • Wozniak 当时在 HP 做计算器工程师，业余泡在 Homebrew Computer Club（家酿计算机俱乐部）——一群硬件爱好者每周聚会交换设计和想法的地方；
  • Apple I 的整机设计是他在 HP 的工作之余做出来的，用的是便宜的 MOS 6502 处理器（当时主流芯片太贵），整机元器件省到极致——这是他的手艺，也是 Apple I 便宜的原因；
  • 按照他与 HP 的雇佣协议，他做的设计要先给 HP 看。他真心希望 HP 来做这个产品，前后找了 HP 五次——部门经理、实验室负责人，一层层往上提案，全部被拒。HP 的理由很"合理”：这不是 HP 该做的产品形态，个人电脑没有市场；
  • 被拒完之后，他才和 Jobs 自己干。Apple I 卖的是主板（用户自己配机箱、键盘、显示器），真正起飞是后来的 Apple II。

两个细节值得单独说：

① Homebrew 俱乐部这种"同好社区"的作用被严重低估。 Wozniak 反复说，他设计电脑的初衷很大程度是"做给俱乐部的朋友们看、让他们也能用上”——先有一个懂你在干什么的社区，再有产品，再有公司。这个顺序后来反复出现（craigslist 也是一个社区先于公司的故事）。

② 巨头的拒绝不是愚蠢，是结构性的。 HP 拒绝 Apple I 不是因为没有聪明人，而是 HP 的判断框架里"个人电脑"不属于任何现有产品线。这事对今天一样成立：大公司拒掉一个新方向，往往不是看走眼，而是它的组织结构就看不见这类东西。

感悟：Wozniak 这篇访谈里没有一点"怀才不遇"的怨气，他说 HP 拒绝了五次时语气就像在说一次 code review 没过。这种纯粹的"我就想把这个东西造出来"的动机，大概是他能在车库里待得住的原因。动机纯度在苦日子里是硬通货。

五、案例三：Hotmail——一行签名档带来的病毒增长

Hotmail 的故事（Sabeer Bhatia 与 Jack Smith）是"先做产品后想商业模式"和"增长先于盈利"的教科书。

史实线：

  • 两人当时是 Apple 的同事（在 FirePower Systems 也有交集），最初的创业想法其实不是邮箱——他们想做一个基于网页的个人数据库/工具类项目（JavaSoft），融资时被投资人否了。做网页邮箱的灵感来自一个很实际的需求：公司防火墙挡了他们的私人邮箱，两人之间传文件都麻烦，于是想到——如果邮箱在网页上，从任何机器都能登；
  • 找钱极难。Tim Draper（Draper Fisher Jurvetson）最后投了，金额不大（几十万美元级别）。谈判里著名的插曲是估值博弈，但更重要的是 Draper 贡献了一个影响深远的建议：在每封发出的邮件底部自动加一行签名档——“P.S. Get your free email at Hotmail”；
  • 这行签名档的效果是：每个用户发出的每一封邮件都是一次推荐，收件人点链接注册，他发出的邮件又带签名档。这就是后来被命名为"病毒式营销”（viral marketing）的东西——这个词很大程度上就是因为 Hotmail 这个案例被造出来的；
  • 增长曲线陡到服务器和带宽先撑不住。上线后短时间内用户从零涨到百万级、千万级，成为全球最大的邮箱服务之一；
  • 1997 年底，上线约一年半后，以约 4 亿美元的股票卖给了微软。

值得琢磨的点：

  • 病毒增长不是"营销技巧”，是产品机制：签名档寄生在产品最核心的动作（发邮件）上，不花一分钱广告费。后来所有做增长的人都在找自己产品里那个"寄生点”；
  • 商业模式是后置的。Hotmail 先有了千万级用户，盈利（广告）是后来的事，卖给微软时收入模型也远谈不上成熟。先有规模，再变现——这条路线在 1996 年是非常反直觉的；
  • 需求的起点小得可笑：两个人想绕开公司防火墙收发邮件。大需求经常伪装成一个小麻烦。

感悟：Hotmail 让我重新理解了"分发"这个词。工程师做产品默认想的是"把功能做好”，而 Hotmail 的胜负手在于把"分发机制"直接焊进了产品动作里。代码写得好只能让你不输，分发机制才能让你赢。

六、案例四：Viaweb——最早的网页应用，和它教会 YC 的事

Viaweb（Paul Graham 与 Robert Morris，后来 Trevor Blackwell 加入）是这本书里和我所在的行业连接最深的故事——他们 1998 年以约 4900 万美元（股票）卖给 Yahoo，产品改名 Yahoo Store；而 Graham 后来用这笔钱和这段经历合伙创办了 Y Combinator，这本书的作者 Jessica Livingston 就是他的合伙人（也是妻子）。

史实线：

  • 1995 年起步，做的产品是让商家通过浏览器搭在线商店——今天听起来平平无奇，但在 1995 年这是激进的想法：当时的软件都要装在本机，“软件跑在服务器上、用户用浏览器操作"这件事，Viaweb 是最早做出来的一批，Graham 称之为最早的网页应用（web application）之一；
  • 技术栈很野：后端大量用 Lisp。这个选择在访谈里被反复问到，Graham 的态度是 Lisp 让他们迭代速度比竞争对手快——功能可以飞快上线，这在抢占新市场时是真优势；
  • 早期靠"什么都干"活着：帮商家建站、手动给商家配图片、做咨询式服务养产品。用户是个位数的时候，onboarding 全手工；
  • 1998 年 Yahoo 收购，约 4900 万美元，产品成为 Yahoo Store。

这个案例里我觉得最值钱的三条经验（后来全成了 YC 的教条）：

  1. “做不能规模化的事”（do things that don’t scale）。早期手工服务每一个商家，看起来笨，但那是直接理解用户的唯一方式。这条后来被 Graham 写成著名文章，源头就在 Viaweb；
  2. 迭代速度是早期公司唯一的护城河。没有品牌、没有钱、没有渠道，你唯一能比对手快的就是发布速度。工具链（他们选 Lisp）要为迭代速度服务；
  3. 小团队 + 低烧钱 = 活得久。Viaweb 三年里人很少、花得省，所以能等到市场（电商）自己成熟。

感悟：Graham 后来写的所有创业文章，几乎都能在 Viaweb 这段经历里找到原型。读这一章的感觉像是读到了 YC 方法论的"创世区块”。也再次印证了一手材料的价值：二手转述告诉你"YC 主张精益创业"，一手访谈告诉你这个主张是从"当年我们穷得只能精益"里长出来的。

七、案例五：Blogger——员工走光后，一个人守住的产品

Ev Williams 的 Blogger 故事是"缺钱是默认状态"这条模式最极端的版本，也是全书里我觉得最悲壮的一篇。

史实线：

  • Blogger 出自 Pyra Labs，而 Pyra Labs 最初做的产品是一个项目/团队协作管理工具（Pyra），Blogger 只是团队内部给自己用的小发布工具——又一个 pivot 案例：内部工具比主产品先有了用户；
  • 2000-2001 年互联网泡沫破裂，Pyra Labs 融资无望，账上的钱烧完了。Ev Williams 在访谈里很平静地讲了最难堪的部分：付不出工资，员工一个个离开，最后整个公司只剩他一个人，服务器账单都成问题，他继续一个人维护 Blogger 的服务；
  • 转机来自产品本身的生命力：博客这个形态在 2001-2002 年持续自然增长，Blogger 是最大的入口之一。后来推出了付费版（Blogger Pro）多少回了一点血；
  • 2003 年，Google 收购了 Pyra Labs（Blogger）。价格未公开，但这一步让"博客"正式进入主流视野，也让 Ev 有了后续创业的本钱（之后是 Twitter，当然那是书外的故事了）。

这篇访谈里最打动人的不是"坚持"这个抽象品质，而是坚持的具体形态：没有钱、没有团队、没有投资人的背书，只剩"这个产品还有人在用，我不能让它挂掉"。用户还在增长这个事实，成了他继续的唯一理由。

感悟：很多创业建议说"数据不好就该放弃"，但 Blogger 的案例给了另一面：当外部环境（资本市场）塌了、而用户数据还在涨时，该信哪个？Ev 信了用户。当然，这话说起来轻巧——他信用户的代价是一个人扛了将近两年。这类决策没有公式，只有"你对这个需求的真实性有多确定"。

另外值得记一笔的是 Blogger 的 pivot 结构：主产品（协作工具）没成，内部工具（博客发布器）成了。内部工具外化成产品这条路径后来反复出现（Slack、很多开发者工具都是这个剧本），Blogger 是早期样本。

八、顺带一提：craigslist——一个拒绝长大的例外

Craig Newmark 的故事值得单独提一句，因为它是全书模式的一个"反例"，而反例最能校准认知：

  • 1995 年，Craig 在旧金山给朋友们发活动信息的邮件列表，就是 craigslist 的全部起点。邮件列表装不下了，做成网页；用户要发招聘信息，加招聘版块；要租房信息，加租房版块——所有功能都是用户要什么加什么；
  • 它多年保持极小的团队、极简的页面（那个著名的朴素界面），拒绝 VC，很多年只对少数类别的发帖收费，其余免费；
  • 结果是：没有病毒营销、没有 pivot、没有惊心动魄的融资战，一个"慢公司"长成了分类广告的巨头，顺便把美国报纸的分类广告业务打残了。

craigslist 说明共性模式不是普适定律：如果需求真实且增长自发生，“不融资、不 pivot、不追增长"也能成。但这种路径的前提是你对增长速度没有执念，且市场窗口允许你慢慢来——1995 年的分类广告允许，大多数今天的市场不允许。

八·附：其他几篇值得一读的访谈

篇幅所限没有逐篇展开，但 32 篇里还有几篇的质量不输上面五个案例，简要标注一下，方便按兴趣翻原书：

  • Paul Buchheit（Gmail）：Gmail 起源于他在 Google 内部做的项目，用大量被"不可能"包围的判断（网页邮箱给 1GB 容量、全文搜索代替文件夹归类），讲了一个"在巨头内部做叛逆产品"的样本。他后来也是"Don’t be evil"这句话的提出者之一；
  • Caterina Fake（Flickr）：Flickr 是从一个在线游戏项目（Game Neverending）里 pivot 出来的——游戏没成，游戏里的照片分享功能成了。又一个"内部工具/附属功能反杀主产品"的案例，和 Blogger 同构；
  • Mitchell Kapor（Lotus）：Lotus 1-2-3 是 PC 时代第一个"killer app”，它的意义是证明了"软件本身可以是一门大生意"——在这之前大家默认卖硬件送软件；
  • Charles Geschke（Adobe）：Adobe 的起点是 Xerox PARC 里不被看好的 PostScript 技术，两位创始人带着技术出走创业。又一个"巨头看不见新品类"的注脚，和 Apple/HP 的故事互为镜像；
  • Blake Ross（Firefox）：在 IE 一家独大、所有人都说浏览器战争结束了的年代，从 Mozilla 里精简出 Firefox 重新开打。讲的是"在巨头已’获胜’的市场里怎么找到破口"。

读法建议：不必按顺序读。先挑你熟悉的公司的篇章，感受"已知的结局 + 未知的细节"之间的落差——这个落差就是这本书的信息量所在。

九、思考与感悟

  1. 一手材料的习惯值得迁移到所有学习里。 这本书给我最大的方法论提醒：学任何领域，优先找一手材料——当事人访谈、原始论文、事故复盘原文、源码本身。二手解读帮你省时间，但也帮你过滤掉了真正有用的毛边。做技术选型时看官方 benchmark 是一手，看"十大框架对比"公众号文章是二手，两者的信息密度差着数量级。

  2. pivot 是能力，不是失败。 32 个故事里一大半做过 pivot，而且 pivot 的形态高度一致：不是推倒重来，而是"原来积累的技术/用户/认知，换一个需求接着用"。PayPal 的加密技术变成了支付安全，Pyra 的内部工具变成了 Blogger。所以真正重要的不是"押对第一个想法"，而是保持"手上的东西能复用到下一个想法"的弹性——架构上如此，认知上也如此。

  3. “被拒绝"包含的信息量比"被接受"大。 HP 五次拒绝 Apple I，不是因为 HP 笨，而是因为组织框架装不下新品类。同理，投资人拒绝你，多数时候不是你的项目不行，而是你的项目不在他的认知框架里。这条对工程师找工作、推技术方案同样成立：被拒绝时先判断"对方框架里有没有我这个类别”，再决定是换受众还是换方案。

  4. 增长机制要被设计进产品，而不是外包给市场部。 Hotmail 的签名档是最干净的示范：产品动作本身就是分发动作。今天做产品的工程师依然很少在设计阶段问"用户的使用行为里，哪一步天然会触达新用户"，但这个问题往往比"功能做得多完善"更决定生死。

  5. 活下去是主线任务。 缺钱、被拒绝、员工走光，这些在成功者的故事里不是插曲而是常态。差别在于有人账上的钱、心里的劲、手上的用户数据，三者中至少剩一个能撑到转机。Graham 后来总结的"default alive vs default dead"，源头就是这些访谈里一个个具体的生死时刻。

  6. 别把幸存者模式当成功配方。 这是读完 32 篇之后必须泼给自己的冷水：这本书里只有活下来的人。同样的 pivot、同样的死扛，放在失败者身上就叫"方向不清"和"沉没成本谬误"。这些模式真正的用法不是照抄，而是校准预期——让你知道缺钱、被拒、走弯路是这条路的默认路况，而不是你走错了的信号。

  7. 对工程师个人，这本书还有一层职业启示。 这 32 个人里相当多数是技术出身（Wozniak、Levchin、Graham、Buchheit），但他们的胜负手几乎都不在技术上：Levchin 赢在两次压下技术偏爱，Graham 赢在手工服务商家，Bhatia 赢在一行签名档。技术在早期公司里是入场券，不是护城河——迭代速度、对用户的贴身理解、活下去的现金流纪律，才是。想明白这一点，对"工程师要不要懂产品、懂增长"这个问题就不会再有纠结了。

本篇小结

  • 这本书的方法论价值大于内容价值：32 份一手访谈证明，创业史的"源码和 issue 区"比二手报告的光滑叙事有用得多；读法是信细节、不信结论；
  • 反复出现的共性模式四条：从别的想法 pivot 而来、早期不被理解、缺钱是默认状态、先做产品后想商业模式——但要看具体纹理，不看鸡汤版本；
  • 五个案例各记一句话：PayPal 演示效果不等于市场需求；Apple 被巨头拒绝是结构性的不是个人的；Hotmail 把分发焊进产品动作；Viaweb 的早期经验后来成了 YC 的全部教条；Blogger 证明了"用户还在涨"可以是独自坚持的全部理由；
  • 例外同样重要：craigslist 用"慢公司"路径走通，说明模式是概率不是定律；
  • 书外的补充阅读路径：Graham 的散文集《Hackers & Painters》（Viaweb 经验的文章版）、Hotmail 案例在几乎所有增长黑客教材里的复盘，以及 YC 历年创始人访谈（Founders at Work 的精神续作）。

如果要给这本书一个一句话评价：它不是教你"怎么创业成功"的书，而是教你"创业真实长什么样"的书。前者不存在，后者恰恰是行动前最需要的输入。

补充一个适用人群的建议：如果你是纯工程师、没打算创业，这本书也不会浪费——把它当"产品决策案例库"读，每个案例都是一次完整的"需求判断 → 资源约束 → 取舍 → 验证"循环，这种判断力在选型、排期、推方案时天天用得上。

这本书适合放在手边，每当觉得"现在太难了"的时候翻一篇——你会发现 32 个后来功成名就的人，当年全都难到过不下去。这不是安慰，是基线校准。

最后说一个阅读之外的收获。读完这本书我顺手做了个实验：找了两篇讲同一家公司（比如 PayPal 早期史）的二手长文，和书里 Levchin 的访谈对照着读。结果很说明问题——二手长文里的 PayPal 是"几个天才看准了电子支付的未来"，访谈里的 PayPal 是"PalmPilot 没人用、欺诈团伙天天攻击、和 X.com 合并后内部天天吵架"。前者读起来爽，后者读完你真的会做事。

这就是为什么我打算把"找一手材料"变成自己以后研究任何主题的第一步：不管是学一个行业、调研一个竞品，还是复盘一次失败，先找到那个真正在场的人说了什么，再决定信不信别人替他做的总结。这个习惯平移到工程上就是：看 issue 区而不只看文档、看原始日志而不只看监控大盘的结论、听当事人的复盘而不只看事故通报——成本更高，但每次都有超额回报。

方糖猫
方糖猫（大可）

18 年后端架构，现在独立做 AI 产品。这里记录 AI 视频、AI Agent 与工程实践。

本文阅读量 次