How the most AI-pilled product team builds products | Fiona Fung (Claude Code and Cowork)

• 编码不再是瓶颈，验证（verification）成了新瓶颈。 Anthropic 工程师平均每季度 ship 的代码量已是 2025 年的 8 倍，而且不只工程师——设计师、PM、团队里所有人都在 check in 代码。当吞吐量暴涨、不同工种都在提交代码时，问题从"怎么把代码写出来"变成"怎么确认这么多代码的质量"。Boris Cherny 的那句"coding is salt"（编码像盐一样廉价基础）正是这个转变的注脚。

• 管理者用 Claude 本身来管理这场洪流。 Fiona 维护着一个 enlist 了所有 repo、能访问全部 Slack 频道和指标的 Claude Code remote session，并用 routines（约一两个月前推出的功能）每天定时自动巡检反馈频道、生成总结和可直接 review 的 PR。关键转变是：这些 session 不再只用来生成 PR 和 bug fix，而是变成她与团队成员对话的入口——"这个产品市场表现如何？造成了哪些 bug？"

• 质量靠"把'什么是好'写进 repo"来守。 Claude 在给定 framework 时验证能力极强，所以 Fiona 的方法是把 spec、content design 规范 check in 进 repo 并保持与代码同步更新，再让 Claude code review 持续比对。这被 Lenny 称为"TDD 的进化版"——而 TDD 本身也因 Claude 能自动先写测试而复兴（"写测试曾经是必须缴的税，现在自动化了"）。

• 人的分化由"成长型心态"和"把恐惧转为掌控感"决定。 做得好的人有 growth mindset、始终带着好奇心学习；做得差的人多半源于 fear + 觉得一切都不在自己掌控。Fiona 的建议是问"我能掌控什么？是这件事发生在我身上，还是为我而发生？"——这套心法她从高中靠做银行柜员供学费的经历里就形成了。

• dogfooding（亲自天天用自己的产品）是 Fiona 最被同事反复提及的特质。 从 Visual Studio 用 VS editor 造 VS editor，到离职后自己在 Facebook Marketplace 卖二手 MacBook 立刻撞上新型诈骗，再到要求每个 manager 先做 IC、持续做 player-coach——核心都是：别只盯仪表盘，要保持对产品的"touch and feel"。

核心要点：每一次工具跃迁都改变了工程师怎么工作，但都不及当下这次——"不久前 100% 代码由人写，现在正走向 100% 由 AI 写"。

• Fiona 从业 25+ 年，路径本身就是一部软件史：IBM（DB2 操作系统服务团队，用 Vim 和终端调试，没有 IDE）→ Microsoft Visual Studio（职业生涯头 11 年的"挚爱"）→ Meta → Anthropic。她笑称入职 Microsoft 时连 IDE 都不知道，听到要做"Visual Studio"还以为是"更好的画图程序"，看到经理一脸"这人怎么回事"的表情。
• 关键跃迁节点：IBM 的 Vim → Visual Studio 第一次见到 IDE（断点、多线程调试，"mind-blowing"）；CD 发版时代 → 在线发布。CD 时代有极硬的 deadline（软件要赶在送厂压盘上架前 ready），所以前期要做大量规划，"工程时间是极其珍贵的资源"。
• 今天的转变是：编码不再是瓶颈。那条推文配图显示 Anthropic 工程师人均季度代码产出"stable, stable, stable, 然后冲向月球"——8 倍于 2025 年。
• 真正的连锁反应不是"代码更多"，而是：不只工程师，设计师、PM、团队所有人都在提交代码，且来自不同工种，吞吐量极高——于是"我们该如何思考验证（verification）？"成了核心命题。

"People may forget 100% of code was written by humans not long ago. And now it's getting to 100% of code written by AI. As Boris famously said, coding is salt." —— Lenny

核心要点：角色边界在模糊（role blurring），每个人都开始成为 builder；管理者必须找到新方法在 8 倍代码洪流上保持掌控。

• Fiona 维护一个 enlist 了所有 repo 的 Claude Code remote session，能访问所有 Slack 频道和团队追踪的所有指标，让她对全员工作"full visibility"。
• 每月她会和团队成员一起开一个 Claude Code session（共享屏幕），不是为了生成 PR，而是复盘："这个月的重点领域是什么？哪些产品 ship 了？市场表现如何？反馈渠道里有什么？"——把 AI 从生产工具变成对话工具。她强调一年前根本做不到这种洞察，因为那时人工梳理、产出也没这么大。
• "Make new mistakes"（只犯新错误）：犯错没关系，但要犯新的，这样总在学习；如果目标是零错误，"说明你不够快，或太谨慎了"。
• 她还让 Claude 横向扫描所有 incident，找出质量热点（hot spots）和值得投资的 gap——这在一年前是纯手工过程。

"It's okay to make mistakes, just make new ones so that we're always learning. Cuz if you aim to make zero mistakes, that probably means you're not moving fast enough." —— Fiona

核心要点：抽象层在不断上移——从"自己写 prompt 同步执行"到"写一个 routine，让 agent 替你生成 prompt 并 spawn 其他 agent"。

• Fiona 过去的 morning ritual：端着早咖啡刷反馈频道，若有 maker time 就挑一个能帮上忙的 gap 去做。现在她设了一个每天定时跑的 routine 替她完成全部巡检。
• routine 不只总结，还能代她 kick off agent："盯着这个反馈频道，发现 bug 就找出能快速搞定的 polish fix 去做"——她醒来时已有一批可直接 review 的 PR。对比从前：从前 agent 跑完她还得自己想"现在拿这些信息做什么"，现在这一层判断也被 routine 承接了。
• 这正是工程的下一个前沿：从同步（一个个 prompt）→ 异步（async / fleets of agents）。"层层抽象不断上移"，而且可以在验证足够好时给 agent 更多自主权——"go for it"。
• 同时她坦承这带来新问题：context switching 负荷在上升（"我自己也是 kick off 一堆然后……"），如何降低这个负荷是尚未解决的难题（见第 8 节）。

"Now I can actually have a routine that basically does prompts for me for spawning different agents. So we'll move more towards that asynchronous style of working." —— Fiona

核心要点：Claude 在给定 framework 时验证能力极强，所以守质量的关键是把"good looks like"显式化、check in、并保持与代码同步。

• 去年还没有 Claude Code Reviews，人工 review 曾是巨大瓶颈。现在对需要深度专业判断的领域仍保留人工 review，但凡能把"好的标准"框架化的，就交给自动化。
• 具体做法：把 spec、content design 规范（最近刚给它加了 scale 评分）check in 进 repo，并确保 spec 随代码频繁更新；Claude code review 据此持续校验代码是否仍符合设定。
• Lenny 称之为"TDD 的进化版"。Fiona 回忆 TDD 在 2000 年代很火（先写测试、让它失败、再写代码让它通过），但自己当年抗拒——"像得先吃完西兰花才能……我太想 ship 产品了"。她在 Claude Code 修的第一个 bug 就是让 Claude 先写测试、确认失败、再做修复让测试通过。"测试生成曾经是必须缴的税，现在自动化了"，那些老原则反而因模型而更高效。

"Any time you have a statement of what good looks like, get that into the repo, and then Claude code review can make sure it's still matching." —— Fiona

核心要点：随着角色边界模糊，Fiona 收敛到两个互补 profile——"dreamers"（端到端 own 产品的创意 builder）和"deep subject matter experts"（trust but verify 中负责 verify 的硬核专家）。

• 深度系统专家：Fiona 刚加入 Claude Code 时团队有很好的产品 generalist，但缺系统/分布式系统背景的人——这是 trust but verify 里"凡是需要深度专业验证的地方都要继续投入"的体现。
• 创意 builder（dreamers）：对某个产品极有热情，有 idea 就 build、看反馈、迭代、打磨，把产品做成 delightful 体验，端到端 own 它。
• 这呼应了"ambition（野心）"的新意义：编码可能后，瓶颈从"这个功能太难做不了"变成"你能想多大"。Fiona 举例：一位非移动端工程师需要给某功能加移动端，靠 Claude 当 partner 直接做到了——"它抬高了任何人能做到的天花板"。

"Everything is now possible in theory. Now it's about how ambitious can you be? ... It's lifted the ceiling of what anyone is able to do." —— Lenny / Fiona

核心要点：分化不在技能，而在心态——成长型心态 + 把 fear 转为"一个我能掌控的行动"。

• 做得好的人：growth mindset，always be learning，"让你走到今天的东西不会让你走到明天"。Fiona 说这是她从 Microsoft 转 Meta 第一年学到的——"你已经成功了，却被要求改变让你成功的方式"，很可怕但极有价值。
• 做得差的人：frustration 背后常是 fear，以及"一切都不在我掌控、事情在我身上发生"的无力感。她的心法：问"我能掌控什么？是 happening to me 还是 happening for me？有没有一个我能采取的行动？"
• 银行柜员故事（完整叙事弧）： 高中时 Fiona 本想当视觉艺术家，家里买不起电脑，九年级才第一次接触电脑（高中有"打字课"）。想读工科却怕付不起学费——安省有 OSAP 助学金但不知能 cover 多少，是个一年后才揭晓的大未知。她问自己"我能做什么？"恰好 National Bank of Canada 在高中贴出招高中实习生当银行柜员的传单（最低工资），尽管她最恨的课就是会计，还是报了名。结果：整个暑假打工存钱，之后周一到周五上学、周六做柜员，这条"lifeline"供她读完书；2000 年 dot-com 崩盘实习难找时，她又多做了两年柜员。
• 她的两句座右铭："what would you do if you're not afraid"和"do something scary once in a while"——在职业巅峰（最高效率）时，靠做没做过的可怕的事来继续成长，虽会有 dip 但那是学习的代价。

"The cave you fear contains the treasure you seek." —— Lenny（Fiona 当场说"我要偷走你这句话"）

核心要点：Fiona 最担心的是 AI 鸿沟越拉越大；她的方法是用具体 use case 当对话起点，"knowledge is power"，让工具变得 equitable。

• 祖母与毛线店（情感锚点）： Fiona 出生香港、幼年移居加拿大时不会英语，父母忙于工作，由"全世界最好的祖母"随迁照顾。祖母在新国家很孤立（当年也不那么 walkable），直到某个夏天她们偶然找到一家会说粤语的老板开的小毛线店——祖母由此找到了她的编织圈，Fiona 学会了 macrame（她还顺嘴预言"macrame 正在回归，你在 Lenny 播客上第一个听到"）。这家小店创造的社区感，是她对小企业热情的源头。
• 从 Cowork 报销到帮朋友（完整案例）： Fiona 自己用 Cowork 处理她最讨厌的商务差旅报销，觉得"magic"。她想到小企业主朋友——拼命工作、利润微薄，却常坐在吧台对着一摞账单做开票和报销，"没人喜欢做这个"。她帮几位朋友 onboard，过程很 humbling（还顺手发现了 onboarding 流程的真 bug），而且朋友们的用法超出她想象：一位开两家餐厅的朋友说自己的文档文件夹是个"杂物抽屉"，连菜单都找不到——给 Coda 访问权限找到菜单后，她还让 Claude"扫一遍本地区同类菜系的可比价格"，得到了很酷的市场分析。
• 这些走访直接催生了 Claude for small business（Cowork 内一个 toggle，把小企业常用插件捆绑好）——Fiona 强调这不是她主导的，但她也观察到了同样的需求（朋友总问"有没有这个插件"）。
• 给"AI pilled"听众的行动建议：找社区或家人里还没上手的人，从"AI 给你自己带来的某个有意义的生活改变"切入做对话起点；哪怕一开始很别扭（她第一次跟朋友开口都觉得不自然），最后往往很有乐趣。

"If not, I'm concerned that the divide grows larger and larger. ... Knowledge is power—you have to learn how to use the tools." —— Fiona

核心要点：从 vibe shift（从"token maxing 无脑花"到"ROI 是多少"）看，任何单一指标都会失效——别为 motion 牺牲 progress，要盯产出是否真的导向 outcome。

• 指标演变史：lines of code（有人把库 port 进来就刷出巨量行数）→ significant LOC → "但更新框架后生成代码更少、产出却一样" → time to land PR……Fiona 的结论是：无论哪个指标，关键是问"output 真的在导向 outcome 吗？"
• "Don't forsake motion for progress"（别把忙碌误当进展）——衡量工具使用量是在衡量动作，但它真的让最终结果变重要了吗？token maxing 就像当年的 lines of code。
• 指标之外，对 leader 的建议：去做 listening tour，尤其听资深工程师讲什么 work、什么不 work——他们能帮你把好做法放大到整个团队，而且对话常能擦出 metric dashboard 给不了的 idea。
• Facebook Marketplace 的 power seller 教训（完整案例）： 早期按区域上线，扩张门槛之一是"卖家数量"。首个区域上线后 Fiona 发现某区卖家数很低，但人们确实在找到想买的东西（这才是真正目标）——原来该区不是卖家多，而是有 power sellers。如果死盯"卖家数量"这个门槛，就会误判。于是更新了指标。教训：任何指标（无论生产力还是产品）都别戴 blinders 盲目跟随，landscape 变得太快，指标本身也可能需要调整。

"Don't forsake motion for progress." / "If you have the data and you have an anecdote, trust the anecdote over the data."（后者 Lenny 引 Jeff Bezos）

核心要点：在大量不同产品 surface 上，与其堆 raw 性能/可靠性数字，不如先有一个高层框架定义"什么是糟糕体验"——再让各团队以高 agency 自定阈值。

• bad vs sad：bad = 不可恢复的严重错误（如 CLI crash，你丢了工作）；sad = 可恢复的痛点（如界面闪烁）。"sad 叠加起来会变成 bad"。
• 高 agency 落地：知道 bad=严重不可恢复错误后，每个团队对自己负责的 surface/服务，自行定义什么算 bad、什么算 sad、目标是什么。这解决了"surface 各不相同时，仪表盘上一个数字到底算好算坏"难以横向 zoom out 的问题。
• 主线呼应：更可主动（proactive）地做质量——更早检测（earlier detection）质量问题，正是当下重点投入方向。
• 脏话仪表盘（现场感）： 2024 年 9 月大家都在感受到一些 frustration 时，一位刚来的工程师提议"我们该追踪 swear words / F-words"（用户骂脏话的频率），Fiona 觉得是个好主意。它直指 eval 之难——eval 不只是 accuracy，更是体验是否 delightful、是否少 frustrating。

"We started this concept of what's bad versus what's sad. Bad is a very bad irrecoverable error, and sad is a recoverable pain point—but when you stack up sads, it could generally go to bad." —— Fiona

核心要点：新 manager 先做一段 IC（深入代码/产品、与团队建立 rapport），之后持续做 player-coach——这不为产出，而为不失去对产品的 touch and feel。

• 缘起：Fiona 入职后做 listening tour，听到"很感激 agency，但优先级怎么定？""审批层级别太多"等反馈，于是要求 manager 先做 IC。她自己当年在 Meta 也是头一季度做 IC，为了学会"怎么以一个 Meta 工程师的身份 ship"。
• 为什么 leader 要持续做 PR：Fiona 说她做的 PR 不在于修了什么，而在于"逼自己每天用产品、保持 in the flow"——因为 Cowork/Code 变化太快，不天天用就会"lose touch"。
• 反差数据：Fiona 上次在 Meta ship 生产代码约在 2017 年（之后多年没 ship，因为怕搞出 bug、怕浪费别人时间）。在 Anthropic 第一周，她本想用老办法"请所有工程师喝咖啡"了解代码库，转念"等等，先问 Claude"——Claude 成了极好的 onboarding buddy，还帮她想出手动测试方案覆盖各种 case，让她重获 ship 代码的信心。很多做了多年 manager 的朋友也跟她说"我靠 Claude 又开始写代码了"。
• dogfooding 的边界：如果你 lead 的团队产品你自己很难用，那就去见客户。她举 Facebook Marketplace 进军拉美的例子——智利区表现不如其他区，她带一个三人小队飞智利、买了一批 Android 手机，落地一开机就发现：当地 LTE 比美国慢得多，Marketplace feed 在弱网下几乎加载不出来——"连加载都做不到，这是多大的增长阻碍"。

"If you're not living and breathing your product every day, you sometimes lose touch and feel of the product." —— Fiona

核心要点：编码的 flow 和"破解难题那一刻的 aha"在消退，团队开始感到孤独——Fiona 用 pairwise programming lunch 和 hackathon 来对冲，并坚持新人仍要"double-click"理解架构。

• 失去的 flow：Lenny（自己做过 10 年工程师）和 Fiona 都怀念那种放首 soundtrack、进入 zone、最后"终于 crack 了"的 aha 时刻。"有工程师说，我以前最享受的部分，正是现在最难得的部分。"现在的 joy 更多来自产品。
• 孤独与 pairwise programming lunch： Cloud Code 团队发现，大家都只跟 agent 工作后，体验开始变得孤独。于是开了 pairwise programming lunch——而且因为团队里每个人用 Claude Code/Cowork 的 flow 都极不相同，结对时"互相学到超多"。这像孩子的 parallel play：在彼此旁边各做各的，但光是看别人怎么 build 就很有价值。再加 hackathon 维系团队连接。
• 技能萎缩之忧与 double-click：Boris 早期手写代码、现在不写了，但他从代码库里获得的知识是真实的。所以 Fiona 要求新人无论做什么都仍要花时间理解架构/改动——这回到 trust but verify。她把"花时间了解你依赖的那一层（double-click）"视为一种 meta 原则：依赖变化时你才更敏锐，不会错过新能力。也许有天模型够好就不重要了，但"以我们现在的速度，我仍认为重要"。

"It can start being a lonely experience cuz we all started just working with our agent so much. So recently we started a pairwise programming lunch." —— Fiona

核心要点：所有"编码相邻"的角色都在变——PM 不再被工程带宽卡住，设计和数据科学是下一批机会；方向是双向的，工程师变得更产品化、人人变得更工程化。

• 第二受冲击的角色是 PM：有 idea 不再等工程带宽。Anthropic 的 PM 也会卷起袖子帮忙 ship 功能（当某事想做但工程师腾不出手时）。
• 下一批：设计、数据科学。Lenny 转述一位数据科学家朋友的现状——现在大部分工作变成"别人用 AI 做了不太行的数据科学，拿来给我说'帮我确认对不对'，一半时间是错的"，整个工作变成了 review AI 产出。
• 双向模糊：工程师变得更产品化、对产品质量与成功负责；同时人人越来越像工程师（模型补上了你作为工程师本来没有的能力，跨职能阻塞变少）。"It's all blurring。"
• 对"现在该对团队有什么基线期待"：大多数 commit 是 Claude 辅助的；让工程师练更强的 product sense muscle；传统非工程角色现在也常见工程师顶上。

"It's all the coding adjacent roles that are shifting. ... It's all blurring." —— Fiona

核心要点：Fiona 当场坦承几个还没 crack 的开放问题——这些恰恰是"现状还在不在服务目的"这条主线的前沿。

• iOS/Android 是否还需独立组织：仍需引入 Android/iOS 深度专家（deep expertise 很重要），但因为大家在 flex，不再需要那么大的"每平台一个大 mobile org"。如何配置"足够而不过量"的专家仍在摸索。
• 全自动 review 推到多远：核心难点是"如何定义 good looks like"，尤其是验证"体验"而非仅 accuracy（eval 既要 accuracy 也要 experience）。要看哪里专家仍不可替代，并不断问"能否用我们的专长把它也自动化"。Fiona 认为验证（verification）这块还有大量机会。
• role blurring 下如何保证人人同等高产。
• context switching 负荷上升：async/routines 让她能切换更多任务，反而要重新 block focus time 来追赶自己 kick off 的一堆异步工作。"如果你有 20 个 agent 在跑，就有无尽的 check in。"她直言"我还没 crack 它"。

"I wish I had a crystal ball. ... The context switching load is increasing, and I haven't cracked it yet." —— Fiona

核心要点：当不必再看代码，新工程师理解底层（内存分配、基础设施）的动机从何而来？Fiona 倾向 fellowship/apprenticeship；同时强调要理解模型的指数级改进、重访"曾经做不到的事"。

• 开放难题：你我成为工程师的路径和现在太不同了——毕业后如何"快进"，又仍保有那个 double-click 到底层的理解？她猜软件工程可能走向 fellowship/apprenticeship（比 3 个月做小项目的实习更深）。
• 历史视角：她一位前 manager 从打孔卡（punch cards）时代起步，如今用 Claude Code 造东西、不断给她发消息——"什么重要、什么不重要会随时间变化，关键是怎么把 proficiency 建进去"。Lenny 调侃"总有天要把某个 COBOL 工程师从退休里捞出来问'你还记得怎么写 Python 吗'"。
• 抽象层论：就像汇编→二进制不断上移，prompt 和"Claude 的思考"是新的抽象层。重点变成"什么是有趣的问题？该优先做哪个体验？"以及"做出来后怎么知道它真的 resonate、真的是你想要的，而不是一堆 slop？"
• 指数级改进的复利（关键判断）： Fiona 第一次用约是 Sonnet 3.5/3.6，仍会犯错（"你在干嘛？"）；抵触 AI 的工程师只盯着这些错误，没理解 exponential 的改进速度。她自己的学习是：曾经因模型不够好而放弃自动化的事，值得在新模型出来后重访——它现在可能就够好了。Lenny 总结成播客反复出现的金律：造一个"几乎能用、在能力边缘"的东西，等模型一到位，你就远远领先。

"Build something that is almost working, that is at the edge—because once the model gets there, you'll be so far ahead of everybody else." —— Lenny

核心要点：在 Anthropic 这种史无前例的增长曲线上，让 Fiona 最操心的不是产品或工程难题，而是文化——"one team mentality"和公开诚实的辩论。

• 文化观：culture 是"living breathing thing，不是贴在墙上的海报"，会随时间变、体现在彼此如何相待。她要的是 diverse perspectives + 公开健康的辩论，以及 one team mentality——"接近终点线时回头看看，还有没有队友需要帮一把，因为我们是作为一个团队冲线"。产品/工程难题有 dashboard、理论、假设可依，但文化是纯人的层面，一旦开始漂移要能及时察觉、一起对话校正。
• Airbnb 文化心得（Lenny 分享）： 一是创始人自上而下痴迷文化，每次 all-hands、每个大会都在重申价值观；二是他记得 Sheryl Sandberg 来做 fireside，有人问"如何在高速扩张中维持文化"，她答"这是你想要的问题"——因为它意味着你在增长、在做好；不增长、不招人才是糟得多的处境。
• Fiona 的"噩梦"：尤其问 manager"things going?"得到"everything's fine"——她引"房子着火里喝咖啡说 this is fine 的 doctor cat meme"。所以她和团队（尤其新来的 manager）约定：永远开诚布公谈什么不顺利，这样才能一起解决。她也点出一个人之常情的难处：当周围人看起来都做得很好，要诚实说"我在挣扎、我落后了"非常难。

"Culture is a living breathing thing. It's not just a poster you slap on a wall. ... When you get close to the finish line, look behind you and see if there's some of our team to help." —— Fiona

核心要点：Cloud Code/Cowork 文化里有一条"explicit permission to kill processes that no longer serve us"——对任何你 dread/嘈杂/昂贵/纯手工的流程，先问"它还在服务它的目的吗？"

• 行动建议：挑一个你最怵、最 noisy、最贵或最手工的流程，先问它是否还有 purpose；能否进一步自动化。
• 从 6 个月路线图到 JIT planning（Fiona 自己的第一课）： 她刚到 Cloud Code 时提议做一个"超轻量"的 6 个月路线图 doc，过程对启动对话、对齐很有用——但三个月后她发现"我们还引用过它吗？变化太多了"。于是她引入了 JIT planning（just-in-time，即时规划）：现在做月度、极轻量规划，甚至不写 doc，只在一个小 spreadsheet 上对齐"这个月我们认为重要的事"，每周快速 check"还是这个月的优先级吗？"；每 6 个月全员聚一次定 themes，但核心是保持对快速变化 landscape 的 pulse。她连这个 spreadsheet 都在想"怎么进一步自动化，永远别让它变成一种 tax（缴税般的负担）"。

"Always ask yourself: whatever process you have, is it still serving its purpose? Just because the field is changing so fast." —— Fiona

核心要点：私人侧写——领导力受动画英雄启发，工作信奉"keep it simple"，做人信奉"be kind"，并把编织当成跑多 agent 时的"compiler"。

• 书： 小说推荐两位作者 Margaret Atwood（speculative fiction，"眯起眼会想这真可能发生在社会上"）和 Haruki Murakami（magical realism）；每年至少读一次的一本书是《小王子》（The Little Prince），提醒自己什么才真正重要。
• 电影： 不看电视剧（"这在 Anthropic 嘉宾里很常见"）。手机里常备三部老片：Amelie（《天使爱美丽》，捕捉了她 16 岁高中巴黎旅行的魔力）、《千与千寻》（最爱的吉卜力之一）、《风之谷》（Nausicaä of the Valley of the Wind，8-9 岁看，女主角娜乌西卡的领导方式深刻塑造了她的许多领导原则——Lenny 戏称"两本顶级管理书：Andy Grove 的 High Output Management 和《风之谷》"）。
• 产品： Sweet Sisters Bodycare——Whidbey Island 的本地小企业有机护理全线。缘起一个完整小故事：几年前她鼻子上长出会流血的疼痛皮疹，停用一切脸部护肤都不好，直到有人问"你用什么洗发水？"——她用的还是青少年时就用的通用品牌；对方说也许身体对其中化学成分产生了过敏。换成有机洗发水后痊愈。最近出差用酒店洗发水一周又复发，提醒她该带旅行装。（Lenny 给本地小企业推荐"加分"。）
• 座右铭： 工作上"keep it simple"（别过度思考，聚焦你真正要做好的那一件事）；人生中"in a world where you can be anything, be kind"（她在一所蒙台梭利学校墙上看到）。
• be kind 的真实分量（COVID 故事）： 疫情期间祖母在加拿大养老院病重，因 COVID 家人都无法探视，只有偶尔靠护工帮忙才能 FaceTime、且时间无法预约。一天姑姑突然消息说"祖母今天中午 12 点能 FaceTime"，恰好撞上 Fiona 一直很看重的一个 1:1（她极重视 1:1，那是对方的重要时间）。她很抱歉地临时请 report 改期，对方爽快说"完全没问题"——这个不被当回事的 small act of kindness，让她得以在 FaceTime 上见到祖母，对她意义重大。
• 编织（名场面）： Boris 说"重要会议上常能听到 Fiona 织毛衣的 click-clack 声"。Fiona 最近织了一件上衣（"Cloud Code 自己造自己，很 meta"）。她把编织和编程类比：两种针法 knit 和 purl 就是 0 和 1，还有栈和队列的概念——"我织毛衣时像个 compiler 在生成可执行文件"。是祖母在她 8 岁时教会她织毛衣，每次织都想起祖母；她爱多任务（kick off 多个 agent 时就织），熟练到不用看手。她的梦想是以祖母之名开一家毛线店、建立社区——"Cowork 帮我自动化一切，尤其是 invoicing"。

"Between knitting and programming—two stitches, knit and a purl, so it's zero and one. I'm kind of like a compiler generating an executable when I knit." —— Fiona