我戴 Apple Watch 已经好几年，但为了研究 Google Health，我又专门买了一个 Fitbit Air，连续戴了三个星期。

原因很简单：我想知道，两个处理着相似健康数据的 app，为什么用起来会如此不同。Apple Health 很安静，数据在后台自动进入，你几乎感觉不到它的存在。Google Health 则会主动分析你的睡眠、给出建议、询问你的感受，并且不断邀请你提供反馈。

六月，我曾经拆解过 Apple Health。当时我的判断是，它并不急着成为一个让用户每天打开的内容产品，更像是 iPhone 里的健康数据基础设施。但只研究一个产品，很容易把偶然的设计选择误认为深思熟虑的战略，所以我需要一个对照组。

Google Health 正好合适。

戴了三周之后，我的结论是：这两个产品都做对了，只是方向完全相反。 Apple Health 尽量不打扰你，Google Health 则希望不断与你对话。真正决定它们采用哪种姿态的，并不是设计师的审美，而是它们背后完全不同的商业模式。

打开第一天，我就觉得它话太多

第一次打开 Google Health，AI 教练很快就出现了。它先总结我昨晚的睡眠，然后问我今天感觉如何。下面已经准备好几个答案，我不需要打字，点一下就能回复。

我开始数这一屏里有多少地方可以收集我的反馈：有赞，有踩，有三点菜单，里面有“有用”“没用”“忽略”，还有几个预设回答和一个自由输入框。根据卡片不同，一屏通常会出现四到六个可以提交反馈的入口。

然后我打开 Apple Health，看了一遍类似的页面，几乎找不到可以反馈的地方。Apple Health 里的大部分数据来自 Apple Watch、iPhone 和第三方设备，它们在后台自动写入，我通常不需要参与。

Google Health 的思路完全不同。每一张卡片除了展示信息，也在创造一个继续收集信号的机会。

而且它做得很有手艺。赞和踩只是细线图标，三点菜单放在角落，预设回复使用柔和的胶囊按钮。你完全可以无视它们，界面也不会显得吵闹。一方面，它需要足够多的反馈来改进模型和推荐；另一方面，它又不能让用户觉得自己正在填写调查问卷。

这里面最让我在意的按钮，是“忽略”。

当我忽略一张卡片时，我只是觉得这条内容跟我没关系。但对系统来说，这依然是一条很有价值的信息：以后少给这个人看类似内容。

在这样的系统里，几乎没有完全中立的动作。点击是反馈，跳过也是反馈，连拒绝都可能成为模型学习的一部分。

我不认为这一定构成暗黑模式。Google 没有强迫你点击，也没有藏起重要选项。真正的问题在于，用户是否知道自己的这些动作会怎样被使用。

知道“忽略”也会影响模型的人，可能会觉得这是合理的个性化。没有意识到这一点的人，则会在几乎无感的情况下，不断参与系统训练。

让数据采集变得无痛，和让数据采集变得不易察觉，往往只隔着很薄的一层。

想理解一个 app，先看它靠什么赚钱

为什么 Apple Health 那么安静，而 Google Health 总想和你聊天？

一个常见的解释是设计风格不同。我觉得更重要的原因，在商业模式里。

Apple 的核心生意是硬件和服务。Apple Watch、iPhone 和相关订阅，已经可以直接产生收入。对 Apple 来说，健康数据的重要价值之一，是让用户相信自己可以放心把这些极其私密的信息交给 Apple 设备。

所以 Apple Health 的安静本身就有价值。它越像一个可靠、克制、不会多嘴的保险箱，用户越愿意长期留在 Apple 的硬件生态里。

Google 的优势则建立在数据、AI 和服务生态上。它需要理解用户的行为，也需要理解行为背后的目标、意图和偏好。这会自然地把产品推向另一种方向：更多提问，更多反馈入口，更多个性化，以及更多可以训练模型的信号。

所以当一个产品显得特别克制，或者特别热情时，先不要急着把它归结为设计师的个人品味。可以先问一句：这家公司到底靠什么赚钱？

很多时候，界面只是商业模式露在水面上的那一小部分。

那个免费的 AI 教练，Google 想从中得到什么

健康追踪器很擅长记录你的身体发生了什么。它知道你走了多少步，睡了多久，静息心率是多少。

但它很难仅凭这些数字知道：你最近在担心什么？你为什么开始锻炼？你希望改善睡眠、减重，还是降低心血管风险？系统对你的判断准确吗？

这些信息很难靠传感器获得。一个会聊天的 AI 教练，刚好可以补上这一层。

我曾经问它，我的静息心率意味着什么。它先给出一段简洁的解释，然后引用外部来源，把我最近十三天的数据画成可以拖动查看的图表。回答结束后，它又问我：这个概览有没有给到你想要的安心感？

我顺口提到自己正在服用降血脂药物，它马上把这条信息纳入后续对话。我切换成中文，它也自然地跟了上来。

那一刻，我确实有点被打动。这个教练做得很好。它能读取我的数据，理解上下文，也会主动把复杂指标翻译成普通人能理解的语言。

而这正是它最有价值的地方。

一个传统手环记录的是步数、心率和睡眠。一个 AI 教练还可以逐渐了解你的目标、焦虑、偏好和生活背景。后面这一类信息通常更有价值，因为它解释了你为什么做某件事。

教练越有用，用户越愿意和它交流；交流越频繁，系统就越了解用户；系统越了解用户，教练又会显得更加有用。

这会形成一个非常强的循环。

所以我逐渐改变了对这个产品的理解。AI 教练正在成为健康追踪存在的理由之一。

传感器负责收集身体数据，教练负责收集意图。两类数据合在一起，才构成一个真正“了解你”的系统。

我的体重，转了三道手才到 Google

Google Health 给人的感觉，是所有健康数据都在同一个地方汇总，然后由 AI 帮你理解。

但当我打开 Connections 页面，逐个检查数据来源时，情况比界面看起来复杂得多。

Fitbit、Apple Health 和医疗记录被放在同一个整齐的列表里，但它们背后的数据关系完全不同。

这里大致有三种数据。第一种是 Google 自己采集的，例如我手腕上的 Fitbit；第二种是从其他平台同步过来的，例如 Apple Health；第三种是用户主动导入的，例如医疗记录。

在界面里，它们只是三行整齐的列表。在产品和商业层面，它们代表三种完全不同的控制权。只有第一种数据，是 Google 从采集设备到存储系统都可以直接控制的。

以我的体重为例，它需要经过三步：Withings 体重秤先测量体重，数据写入 Apple Health，Google Health 再从 Apple Health 读取。

我的体重先由 Withings 测量，再进入 Apple Health，最后才被 Google Health 读取。

那个看起来最了解我的健康平台，显示的其实是一个它从未亲自测量过的数字。

这有点像小时候玩的传话游戏。信息最终传到了你面前，但它已经经过了几个系统。每一层都有自己的权限、格式、同步速度和商业利益。

这也让我重新理解 Google 收购 Fitbit 的意义。很多人会把这笔收购理解为 Google 买下了一个手环品牌和一个健康 app。更重要的资产，其实是数据链路的起点。

Google 可以从 Apple Health 读取数据，但这种关系依赖 Apple 的接口、权限和规则。Google 可以使用这条通道，却无法完全控制它。Fitbit 给 Google 带来了一条自己掌握的数据流，从用户手腕上的传感器开始，数据就在 Google 的体系内产生。

这对任何平台型产品都非常重要。

我后来在给客户画数据模型时，也开始特别关注这件事。一张整齐的数据关系图，很容易让所有数据看起来地位相同。真正应该问的问题包括：这条数据是谁采集的？谁拥有原始记录？我们通过什么权限访问它？对方改变规则以后，我们还能不能继续使用？假设明天这个数据源被关闭，产品还剩下多少价值？

依赖第三方数据，有点像在别人家的 WiFi 上做生意。 平时一切正常，甚至感觉不到自己在借用别人的基础设施。房东一旦修改密码，你的业务会立刻断网。

Google 收购 Fitbit，相当于自己拉了一根网线。至少有一部分健康数据，可以从自己的设备开始产生。

我花了三周找一个功能，最后发现它根本不存在

Google Health 里的聊天框，本身没有太多新鲜之处。ChatGPT 出现之后，几乎所有产品都在尝试加入一个聊天入口。

真正值得研究的，是聊天框周围的那套结构。

我通常会把 AI 对话体验分成三个阶段：用户开口之前，对话进行之中，以及对话结束之后。

Google Health 最强的是第一个阶段。它不会把一个空白聊天框扔给你，让你自己思考该问什么。它会先看你的睡眠、活动和心率，然后主动抛出一个话题。

例如：你昨晚的睡眠时间比较稳定，周末快到了，你觉得自己还能保持这个作息吗？

下面再放几个可以直接点击的回答。

Google 把大量设计投入到用户开口之前。系统主动发现话题，再通过预设选项降低回复成本。

这是一个非常聪明的设计。

对话式 AI 产品最常见的问题，就是空白输入框。 用户不知道该问什么，于是什么都不问。功能虽然存在，使用率却很低。

Google 的解决办法，是先提供一个有上下文的话题，再把回复成本降低到点击一下。这个设计同时完成了两件事：它让教练显得更懂你，也让用户更容易提供新的意图数据。

至于对话过程本身，Google Health 做得不错，但和其他成熟 AI 产品相比，没有特别大的差异。

我真正找了三个星期的，是对话结束之后的那一层。

我期待它能够主动提醒我：这周你的睡眠时间比上周更稳定；你最近的静息心率出现了一些变化；你设定的目标已经连续完成五天。

但我没有找到这样的体验。没有主动推送，没有自动周报，也没有一句“最近我注意到你发生了什么变化”。

当然，这里可能有健康产品特有的谨慎。一条用户主动询问之后得到的错误回答，和一条系统主动推送的错误健康建议，带来的信任风险完全不同。所以 Google 可能选择先把主动性控制在 app 内部。

即便如此，我依然认为这是一个明显的缺口。

用户开口之前的设计，决定他们会不会开始使用；对话过程决定功能是否合格；对话结束之后的设计，决定用户会不会持续回来。

我这一年看过很多 AI 功能。大部分团队只做了中间那一段：放一个聊天框，接一个模型，然后等待用户提问。

Google 至少把“用户开口之前”做得非常完整。但真正可能影响长期留存的那一层，目前仍然是空的。

小团队最好别直接抄这两家公司

大公司的产品经常被当成设计标杆。但一个界面设计有效，通常依赖它背后的公司结构、技术能力和商业模式。

所以，假如你在做一个创业产品，我不建议直接照抄 Google Health 或 Apple Health。

先看 Google。

AI 教练、深度个性化、每屏反馈、持续收集用户意图，这些都是现在非常流行的产品方向。Google 能承担这套系统，是因为它拥有强大的数据基础设施、模型能力和庞大的服务生态。

它有地方存储这些信号，有能力训练和改进模型，也有足够多的场景，可以让这些数据产生长期价值。

小团队复制同样的界面，却未必拥有同样的引擎。如果收集到的数据无法转化成更好的产品体验，赞、踩和忽略按钮就只会增加系统复杂度。

更麻烦的是信任。用户早已知道 Google 是一家依赖数据和 AI 的公司。大家在使用 Google 产品时，通常已经把这件事考虑在内。

一个陌生的小品牌做出同样密度的数据采集界面，用户可能会产生完全不同的感受：这家公司为什么需要知道这么多？

再看 Apple。

Apple Health 的克制，也很难被小团队直接复制。Apple 可以把健康 app 做得安静、免费，而且几乎没有明显的商业化，因为 Apple Watch 和 iPhone 已经承担了收入任务。

对一个没有硬件收入、没有订阅、也没有其他生态支持的小产品来说，同样的克制可能意味着用户没有形成习惯，产品没有收入，团队也无法长期维护它。

我们看到的是界面，真正推动产品运转的是下面那台看不见的发动机。

Apple 可以保持安静，因为硬件生意在支撑它。Google 可以持续提问，因为数据和 AI 是它的重要能力。

小团队需要先找到自己的发动机，再决定界面应该表现出什么姿态。 照抄车壳，却没有对应的发动机，最后得到的通常只是一张越来越贵的维护账单。

最后

戴了三个星期 Fitbit 之后，我最大的收获，已经不只是对 Google Health 的理解。

我开始更加警惕一种常见的判断方式：我们看到一个顺滑、聪明、几乎没有摩擦的设计，就自然认为它对用户更友好。

事情没有这么简单。

同一个设计动作，可以同时提升用户体验，也提高数据采集效率。 那个让 AI 教练显得更有生命力的主动提问，也在帮助系统收集用户意图。那个让“忽略”变得毫无负担的按钮，也在安静地训练推荐模型。

它们来自同一套设计。设计做得越好，两个效果往往都会更强。

所以真正值得讨论的问题，并非这个界面够不够漂亮、够不够顺滑。更重要的问题是：产品为什么需要这份数据？数据最终会创造什么价值？用户是否理解自己正在提供什么？

如果一个团队能把这些问题想清楚，界面只是最后一步。如果这些问题没有答案，再精致的交互也只能暂时掩盖矛盾。

我原本买 Fitbit，只是想拆一个 app。三个星期之后，我发现自己拆开的，其实是两家公司完全不同的赚钱方式，以及它们如何一路影响到屏幕上的每一个按钮。

两篇完整的产品拆解报告：

Apple Health: Infrastructure by Design

Google Health: Extraction by Design

前不久我去当了一场 Hackathon 的评委。一天审 21 个产品 demo，每个 10 分钟讲 + 5 分钟答疑。一整天下来快六小时的内容，到最后我能清晰回忆起来的产品，不到 5 个。

不是项目不好，里面也有很真实的好点子。问题在哪？

不在产品，在结构。

将近一半的团队没等到 demo 时间就被叫停了。有几个甚至从头到尾没有真正打开过自己的 app。前 7 分钟讲背景、讲团队、讲市场规模、讲方法论，等计时器跳到「Demo!」，他们手忙脚乱地翻一张截图，三言两语过完——而这本来应该是整个 pitch 里最有意思的部分。

特别遗憾。你花了几天甚至几周做的东西，结果到了最关键的 90 秒，已经没时间展示了。

这种结构问题不止出现在 hackathon。设计评审、客户提案、内部产品建议、会议 keynote，到处都是。设计师、Founder、咨询顾问，几乎每个人都在不停地 pitch。但大多数人讲的顺序，是反的。

修这个问题的工具，已经 50 年了

视频里我拆解的框架，是 1973 年 Barbara Minto 在 McKinsey 提出的金字塔原理（Pyramid Principle）。它把绝大多数人凭直觉用的「层层铺垫到结论」结构，整个反转过来。

结论先讲。三个理由支撑。每个理由配一个证据。

整座金字塔，就这么三层。

这个形状不是装饰用的。它对应的是评委、客户、Founder 这种高阶听众真实的信息处理方式：先要答案，再决定要不要花时间听理由。如果你把结论藏在第 12 页 PPT，等你讲到那一页时，他们的注意力早就走了。

怎么开场：SCQA

讲结论之前，你需要 30 秒的开场——不是 7 分钟，是 30 秒。金字塔原理给了一个干净的开场公式，叫 SCQA。

• Situation 情境——把范围收窄，今天我们到底在解决谁的什么问题？

• Complication 冲突——展示差距：现在的结果是什么，期望的结果是什么，这中间的 gap 为什么是个问题？

• Question 问题——把听众心里那个「那要怎么补上呢？」明确说出来

• Answer 答案——你那一句话的结论

30 秒之内，听众已经知道情境、感觉到张力、自己脑子里冒出了那个问题，并准备好听你的答案。之后所有时间都用来用「理由 + 证据」捍卫这个答案。

每个 Pitch 都必须回答的三类问题

一旦你抛出了结论，听众心里默默在问三个问题之一。一个好的 pitch 应该全部都回答到。

1. Why（为什么）——这事为什么值得做？用数据、差距、不解决会怎样，来证明问题成立。

2. How（怎么做的）——你的方案怎么运作？demo 就活在这一层。步骤、流程、产品当场跑给我看。

3. How do you know（你怎么知道有效）——拿出证据。Beta 数据、用户反馈、和过去状态的对比。

主结论下面的每一个支撑理由，都应该回答这三个之一。如果某个理由不在这三类里，它就不该出现在前 90 秒。

5 步法 Pitch 框架

把这些拼起来，我现在用的 5 步法长这样：

1. 一句话讲结论——开场前 15 秒，说清楚「我们做了 X，给 Y 用户，解决了 Z 问题」

2. MECE 拆三柱——三个互不重叠、合在一起又完整的理由。回答：为什么这是真问题、为什么是现在、为什么是我们

3. 每柱配一个证据——一对一，不要堆

4. SCQA 开场——把 Situation / Complication / Question / Answer 全部压进前 30 秒

5. 30 秒自检——录音自己讲一遍开场前 90 秒。讲不完结论 + 三柱，就回到第 1 步

第 5 步是大多数人会跳过的一步，也是决定 pitch 能不能落地的那一步。如果你在自己房间里对着手机录音都讲不完，到了 hackathon 现场，倒计时一响，更不可能讲完。

10 分钟 Pitch 时间该怎么分

下面这张时间分配表，来自我那天清楚记得的 4 个 pitch 的共性：

注意里面缺了什么：那段杀了我评过一半项目的「公司背景 + 方法论 + 团队 slide」7 分钟前奏，没了。

一个具体例子：PerCam

为了把抽象框架落到实处，我让 Claude 帮我写了一个虚构产品的 pitch。这个产品叫 PerCam，是一个戴在猫脖子上的项圈摄像头。它不是真的，纯粹为了演示框架而存在。

按这个框架写出来，整个 pitch 90 秒，slide 长这样：

• Situation 情境：全世界有超过 6 亿只宠物猫。室内猫一天 70% 清醒时间都不在主人身边。室外猫消失在邻居家的围栏和偶尔的鸟里。

• Complication 冲突：现在我们能做的，是把一台静态宠物摄像头固定在墙上，盯着空房间，而猫早就跑到别处去了。

• Question 问题：怎么把摄像头放到一个它从未到过的地方——猫自己身上，而且猫还不讨厌你？

• Answer 答案：Meet PerCam。一台 12 克重的项圈摄像头，全天高清直播猫的生活，AI 自动剪掉无聊片段，猫根本不知道它在那里。

然后是三柱：

• Hardware——12 克，猫认可，沿用 GoPro highlights 那套 on-device ML 重训了猫视角运动模式。

• AI Daily Reel——每晚 9 点一段 90 秒精剪集锦。看到了哪些鸟、睡了几次、神秘的飞奔在干嘛。Beta 用户开包率 89%，比你最好朋友的 Instagram Stories 还高。

• Social sharing——Beta 用户平均每周分享 4 段到社交媒体，是我们对标过的任何宠物 app 的 3 倍。

收尾：PerCam 是世界上第一台为「摄像师恰好是只猫」设计的摄像头。我们在找一位硬件顾问和一位兽医合作伙伴。来 7 号桌找我，我有猫的照片。

整段 90 秒就讲完了，还有余地呼吸。对比一下我评过那种 7 分钟 PPT 马拉松式 pitch，你就能看到这个框架到底给了你什么——时间。具体说，是给 demo 留出来的时间。

什么时候不该用这个

金字塔原理是分析型 pitch 的结构工具：hackathon、设计评审、客户提案、产品建议书。它不适合 keynote 讲故事、情绪性沟通、销售叙事这类「过程本身就是重点」的场景。如果你的目的是让人深深感受到什么，要换结构。如果你的目的是让人在听完之后立刻做点什么，这个能用。

另外，要注意你坐在 pitch 桌的哪一边。VC Demo Day（YC、Sterling Road 这种）的主流建议是 demo 时间越少越好、聚焦 traction 数字；但 Hackathon 不一样，demo 本身就是 traction。同一个框架，时间分配恰好相反。

下一步

如果你接下来 30 天内有个 pitch——hackathon、客户评审、董事会、Portfolio 评审——试一次。写下你那一句话的结论，写下三个支撑理由，把开场 90 秒里所有不属于这两件事的东西全部砍掉。然后录音听一遍。

你要么会重新发现自己想说什么，要么会发现自己还没想清楚。哪种结果都有用。

希望这期视频对你有帮助。如果你接下来有个 pitch，欢迎在评论区分享你的结构，我可能会挑 1-2 份在下个视频里拆解。

下次见。

How to Pitch in 90 Seconds Using the Pyramid Principle (After Judging 21 Hackathon Pitches)

I recently sat on the judging panel of a hackathon. Twenty-one product demos, ten minutes each, plus five minutes of Q&A. By the end of the day I'd reviewed nearly six hours of pitches. And I could clearly recall fewer than five of the products.

The teams had built real things. Some of the ideas were genuinely good. So what happened?

The problem wasn't the product. The problem was the structure.

Almost half of the teams ran out of time before they could show their demo. A few never opened the app at all. They spent the first seven minutes setting context — founder backgrounds, market size, methodology, slide design — and then, when the timer hit "Demo!", they had ninety seconds to flip through a screenshot and explain what was supposed to be the most exciting part of the entire pitch.

What a shame. You spend days, sometimes weeks, building something — and then you don't leave any room to actually show it.

I've watched the same pattern in design reviews, client pitches, conference talks, internal product proposals. People waffle on the lead-up and never get to the most interesting part of what they made. Designers, founders, consultants — almost all of us are pitching something, almost all the time. And almost all of us are doing it backwards.

The fix is fifty years old

The framework I now use, and the one I unpack in this video, was developed in 1973 by Barbara Minto, a consultant at McKinsey. It's called the Pyramid Principle, and it inverts the natural order of presentation.

Instead of building toward your conclusion, you lead with it.

Conclusion at the top. Three reasons supporting it. One piece of evidence under each reason.

That's the entire pyramid.

The shape isn't decorative. It mirrors how senior audiences — judges, executives, clients — actually process information. They want the answer first, then they decide whether the reasoning is worth their time. If you bury the conclusion on slide 12, by the time you arrive they've already left the room mentally.

How to open: SCQA

Before you can deliver your conclusion, you need thirty seconds of setup. Not seven minutes — thirty seconds. The Pyramid Principle gives you a clean recipe for that opening, called SCQA.

• Situation — narrow the scope. What problem are we actually solving today?

• Complication — show the gap. What is the current result, and what is the expected result, and why is the distance between them a problem?

• Question — surface the obvious "How do we close that gap?"

• Answer — your one-sentence conclusion.

By thirty seconds in, your audience knows the situation, feels the tension, has formed the question themselves, and is ready to hear your answer. You then spend the rest of the time defending the answer with reasons and evidence.

The three question types every pitch must answer

Once you've delivered your conclusion, the audience is silently asking one of three questions. A good pitch answers all three.

1. Why — why is this worth solving? This is where you justify the problem. Cite data, cite the gap, cite who suffers if it stays unsolved.

2. How — how does it work? This is where the demo lives. Steps, walkthrough, the actual product doing the actual thing.

3. How do you know — how do you know your solution works? This is where you bring proof. Beta numbers, user feedback, comparison with the previous state of the world.

Every supporting reason under your main point should answer one of these three. If a reason doesn't, it doesn't belong in the first ninety seconds.

A 5-step pitch framework

Putting the structure together, the framework I use looks like this:

1. Conclusion in one sentence — open the first fifteen seconds with "we built X, for Y, that solves Z."

2. MECE three pillars — three reasons that are mutually exclusive and collectively exhaustive. They should answer: why is this a real problem, why now, why us?

3. One evidence per pillar — for every reason, attach exactly one piece of demo-able evidence.

4. SCQA opening — pack situation, complication, question, and answer into the first thirty seconds.

5. 30-second self-check — record yourself delivering the first ninety seconds. If you can't get through conclusion + three reasons in that window, return to step 1.

The 30-second self-check is the part that most people skip and the part that most decides whether a pitch lands. If you can't say it tightly to a phone recorder alone in your room, you can't say it on a hackathon stage with a timer counting down.

How time actually breaks down in a 10-minute pitch

Here is the time allocation I'd recommend, based on what worked in the four pitches I clearly remembered:

Notice what's missing: the seven-minute "company background and methodology" preamble that killed most of the pitches I judged.

A worked example: PerCam

To make this concrete, I asked Claude to draft a one-sentence pitch for a fake product. The product is a cat-collar camera I'm calling PerCam. It's not real. It exists only as a demonstration of the structure.

The pitch, written using the framework, runs ninety seconds and looks like this in slides:

• The Situation: There are over 600 million pet cats in the world. Indoor cats spend 70% of their waking hours away from their owners. Outdoor cats vanish into fences, neighbors, and the occasional bird.

• The Complication: The best we can do today is a static pet camera bolted to a wall, watching an empty room while the cat is somewhere else entirely.

• The Question: How do you put a camera somewhere it has never been before — on the cat itself, without the cat hating you for it?

• The Answer: Meet PerCam. A 12-gram collar camera that streams your cat's day in HD, auto-edits the boring parts, and the cat doesn't even know it's there.

Then the three pillars:

• Hardware — twelve grams, cat-approved, on-device ML stack retrained on cat-perspective motion patterns.

• AI Daily Reel — every evening at 9pm, a ninety-second highlights reel. Birds spotted, naps logged, mystery zoomies explained. Beta open rate: 89%.

• Social sharing — owners share an average of four clips per week to social, three times the rate of any pet photo app we benchmarked.

The closing: PerCam is the first camera built for the camera operator who happens to be a cat. We're looking for a hardware advisor and a veterinary partner. Find me at table 7. I'll have cat photos.

That entire pitch fits comfortably in ninety seconds with room to breathe. Compare that to the seven-minute slide marathon most teams I judged delivered, and you start to see what the framework actually buys you: time. Specifically, time to demo the thing you built.

When not to use this

The Pyramid Principle is a structural tool for analytical pitches — hackathons, design reviews, client recommendations, product proposals. It is not a tool for keynote storytelling, emotional appeals, or sales narratives where the journey is the point. If your goal is to make someone feel something deeply, structure differently. If your goal is to make someone act on information quickly, this works.

It also matters which side of the pitch table you're on. For VC demo days (YC, Sterling Road), conventional wisdom is to demo little and focus on traction. For hackathons, the demo is the traction. Same framework, opposite time allocation.

Your next step

If you have a pitch coming up in the next thirty days — a hackathon, a client review, a board meeting, a portfolio crit — try this once. Write your one-sentence conclusion. Write your three pillars under it. Cut everything from the first ninety seconds that doesn't fit. Then record yourself.

You'll either rediscover what you actually meant to say, or you'll find out you don't have a clear answer yet. Either outcome is useful.

Hope this helps. Let me know in the comments if you have a pitch coming up that you'd like to work through together — I might unpack one or two in the next video.

PM 工具一抓一大把：Notion、Jira、Asana、ClickUp、Monday、Trello，挑个颜色都能找到一款。但为什么工程师一旦用过 Linear，就不愿意回去？

我做了十六年设计，几乎所有这些工具我都用过，作为真实用户而非测评博主。所以当一个工程师朋友说"我回不去 Jira 了"的时候，我没顺着点头，而是花了二十五分钟坐下来，对 Linear 做一次完整的产品拉片：冷启动注册、走完全部 onboarding、第一屏分析，然后再补了一段产品 funnel 和定价的 desk research。

三个模式反复出现。它们都不是营销话术里说的"快"或"极简"。它们是一组关于"产品如何尊重用户注意力"的设计决定。

1.「3 项规则」是合同，不是风格

进到工作区第一眼就发现：几乎每个 UI 容器都把可见项数压在三个以内。个人团队面板：issues、projects、views 三项。上面的 workspace section：三项可见，多余的折成"更多"。issue 列表右上角：filter、display、open details 三项。连 onboarding 本身也只有七步，那是工作记忆开始衰退之前的上限。

这不是装饰。这是一份显式的认知负载合同。当每个容器最多只有三项的时候，你不需要在开始工作之前先分配注意力。看一眼、做选择、动起来。产品替你完成了优先级判断，而不是把这件事甩给用户。

第十一第十二个东西被折进"更多"，不是设计失败，是 ICP 筛选。如果你的工作流要求你的侧边栏永远能看到十二个项目，Linear 在很温和地告诉你——它不是为你设计的。

2. 把键盘快捷键放进 hover tooltip：这是一笔留存账

第二个模式小到第一眼会错过。把鼠标 hover 在 Linear 任何一个 UI 元素上——导航、按钮、issue 的属性——tooltip 里都会同时给出文字标签和键盘快捷键。

Notion 有快捷键，Asana 也有快捷键。区别不在"有没有"，在"怎么暴露"。Notion 的快捷键你需要去翻 help page 才能学会；Linear 的快捷键你在用产品的时候自然就遇到了，因为产品永远不让你忘记它。

为什么这件事对公司而言重要，不只对用户重要？因为快捷键会把一个"熟悉产品的人"升级成"被产品的肌肉记忆绑定的人"。离开成本从几周的再培训，变成几个月的肌肉重塑。这不是 UX 打磨，这是把切换成本工程化，包装成了一个 tooltip。

这里还有一个市场契合度的信号：工程师爱键盘。设计师、PM 也用，但不像工程师那样把它当生产力主轴。Linear 把最重的 UX 投入压在工程师最在意的肌肉上——产品不仅仅匹配市场，它在主动追求市场。

3. 桌面 + 文件夹：分层 UI 范式

第三个模式我花了最久才说清楚。在产品里待十五分钟之后，我注意到 Linear 的 UI 分层和别人不一样。

左侧栏——workspace、teams、projects、issues、views——永远不动。它是固定面。叫它桌面。右侧——issue 列表、issue 详情、按下去之后召唤出来的 AI 对话框——是漂浮在桌面之上的卡片。叫它白纸。

对比一下 Jira。Jira 有顶部菜单、有左侧栏、有主区域，但它们都在同一个平面上。没有深度，没有"我现在在桌面、这是我手里的纸"的层级感。再对比 Notion：页面无限嵌套，外壳和内容融在一起，你分不清边界从哪里开始到哪里结束。Asana 离 Linear 最近，但没有把这个范式做得那么硬。

Linear 对桌面+白纸分层的硬执行，是工程师感觉它"心流"、PM 感觉它"束手"的根本原因。工程师习惯一次进入一个深度上下文，所以"稳定全局面 + 易变操作面"刚好是他们工作日的形状。PM 经常需要横跨多个 context 做切换，所以同样的范式对非目标用户来说会显得限制。

Linear 顺手回答的两个生意问题

这三个模式拼起来之后，两个生意层的决定就讲得通了。

为什么 Cycle 藏在 settings 里？ Cycle 是 Linear 给 sprint 起的名字。我看过的所有外部文章都把 Cycle 当作核心功能。但默认是关的——你必须在 workspace settings 里手动打开。我找了五分钟没找到，最后是去翻文档才确认在哪。

这不是 UX bug，是 ICP 筛选。一个不在用 cycle 思考的团队，进入到敏捷工具流的下一步会很尴尬。强迫用户主动启用 Cycle，等于在说"如果你说不清楚为什么需要它，那它后面的整套敏捷机制对你也没意义"。按需暴露好过默认覆盖每一个新账号。

为什么 PLG 漏斗这么陡？ Linear 的响应时间小于 15 毫秒，比 Jira 快 3 倍，比 Asana 快 2 倍。营销话术押在"快"上。但漏斗数据更有意思：约 65% 的付费客户来自自服务的免费用户。路径很稳定：工程师个人发现 Linear → 带进自己的团队 → 团队开始嵌入工作流 → 公司变成默认 → 签 enterprise 合同。

这条漏斗如果没有上面三个设计决定，跑不起来。工程师愿意自发上车，是因为键盘故事讲到他们心里；团队留下来，是因为"3 项规则"把整个面的认知负载都拉低；公司没法迁走，是因为桌面+白纸的分层已经长成了肌肉记忆，迁移成本是按月计算的，不是按功能。

如果是我做产品，会带走什么

三件可以应用到任何产品的事：

• 数一下每个 UI 容器有多少项。 但凡超过三个，问自己是不是在让用户替你做优先级。

• 让每一个可点击元素同时承担教学职能。 Tooltip、hover、command palette，它们应该在教用户下一步怎么操作，而不是只标注当前是什么。

• 把稳定的全局导航和易变的工作内容分到两层。 如果它们在同一个平面上，认知负载就会转嫁给用户。

Linear 的护城河不是"快"也不是"极简"。它是用三条具体的设计合同尊重了用户的注意力，然后再把这套合同长出来的肌肉记忆变成订阅收入。复制这件事比抄一套配色难得多。

接下来我会继续观察 Linear 的 AI 集成。今天的对话框还停在 ChatGPT 风格的浮动窗。如果 Linear 把 agent 像当年把键盘快捷键嵌进 tooltip 那样嵌进 issue 的生命周期，那才会是同一套打法的下一层。

完整拉片视频：https://www.youtube.com/@Bearliu

Why Engineers Love Linear (And Hate Going Back to Jira): A Designer's Honest Teardown

There are a lot of project management tools. Notion, Jira, Asana, ClickUp, Monday, Trello — pick a colour, you'll find one. So why does Linear keep showing up as the one engineers refuse to leave?

I'm a designer with sixteen years in the trade. I have used most of these tools as a real user, not as a reviewer. So instead of nodding along when an engineer told me "I can't go back to Jira", I sat down for twenty-five minutes and ran an actual product teardown on Linear: cold sign-up, full onboarding, first-screen analysis, then a follow-up research dive on the funnel and the pricing.

Three patterns kept showing up. None of them are about speed or "minimalism" in the way the marketing copy frames it. They're decisions about how a product respects a user's attention.

1. The "rule of 3" is a contract, not a style choice

The first thing I noticed once I was inside the workspace: every UI container caps at three items. The personal team panel: issues, projects, views — three. The workspace section above it: three visible items, anything more collapsed under "more". Filter, display, open details on the top right of the issue view: three. Even the onboarding flow itself stops at seven steps, which is the upper bound of working memory before recall starts to fail.

This isn't decorative. It's an explicit cognitive load contract. When every container shows at most three things, you don't have to ration attention before you start working. You glance, you commit, you move. The product is doing the prioritisation work that other tools push onto the user.

The fact that the eleventh and twelfth items in any section get collapsed into "more" is not a design defeat. It's an ICP filter. If your workflow needs twelve things in your sidebar, Linear is gently telling you it isn't the tool for you.

2. Keyboard shortcuts as hover tooltips: a retention play

The second pattern is small enough to miss on a first look. Hover any item in Linear's UI — the navigation, the buttons, the issue properties — and the tooltip shows you both a label and a keyboard shortcut.

Notion has shortcuts. Asana has shortcuts. Plenty of tools have shortcuts. The difference is exposure. In Notion you discover shortcuts by reading a help page. In Linear you discover them by using the product, because the product never stops mentioning them.

Why does this matter for the company, not just the user? Because shortcuts turn a user from "familiar with the product" into "muscle-memory bound to the product." The cost of leaving moves from a few weeks of retraining to several months. That's not UX polish. That's switching cost engineering, dressed up as a tooltip.

There is also a market fit signal here. Engineers love keyboards. Designers and PMs use them too, but not the way engineers do. Linear's heaviest UX investment is precisely in the muscle that engineers value most. The product doesn't just match its market; it courts it.

3. Desktop and folder: the layered UI metaphor

The third pattern took me longest to articulate. After I'd been in the product for ten or fifteen minutes, I noticed something different about how Linear's UI is layered.

The left panel — workspace, teams, projects, issues, views — never moves. It's a fixed surface. Call it the desk. The right side — the issue list, the issue detail, the AI dialogue when you summon it — is a card that floats above the desk. Call it the paper.

Compare with Jira. Jira has a top menu and a left rail and a main area, but they all live on the same plane. There's no depth, no sense of "I'm on the desk, this is the paper I'm holding." Compare with Notion: pages nest infinitely, and the chrome melts into the content. You can't tell where the surface ends and the workspace begins. Asana sits closer to Linear, but doesn't commit as hard to the metaphor.

Linear's commitment to the desk-and-paper layering is what makes the product feel like flow for engineers and chaos for some PMs. Engineers tend to work in one deep context at a time, so a stable global surface plus a mutable working surface is exactly the shape of their day. PMs tend to switch contexts often and need lateral navigation, which is why the same metaphor can feel restrictive when you're not the target user.

The two questions Linear quietly answers

Once those three patterns clicked, two business decisions made more sense.

Why is Cycle hidden in settings? Cycle is Linear's term for what most teams call a sprint. Every external article I read about Linear treats Cycle as core. But it's off by default — you have to enable it in workspace settings. I spent five minutes looking for it before I gave up and went to the documentation.

This isn't a UX bug. It's an ICP filter again. Teams that don't think in cycles aren't a good fit for what comes next. Forcing the user to enable Cycle is a way of saying: if you can't articulate why you need this, the rest of the agile machinery isn't going to land. Better to surface it on demand than to drop it on every new account.

Why is the PLG funnel so steep? Linear's response time is under fifteen milliseconds, three times faster than Jira and twice as fast as Asana. That speed is what the marketing leans on. But the funnel data is more interesting. Roughly sixty-five percent of paying customers start as self-serve free users. The pattern is reliable: an engineer finds Linear personally, brings it to their team, the team becomes embedded in the workflow, the company standardises, the enterprise contract gets signed.

This funnel isn't possible without the three design decisions above. Engineers adopt because the keyboard story fits them. The team stays because the rule of 3 keeps cognitive load low across the surface. The company can't migrate away because the desk-and-paper layering is now muscle memory, and switching costs are paid in months, not features.

What I'd take away if I were designing my own product

If you build software, three things to test on whatever you ship:

• Count items per UI container. Anywhere you exceed three, ask whether you're forcing the user to ration attention.

• Make every actionable element double as a teaching surface. Tooltips, hover states, command palettes — they should be teaching the next interaction, not just labelling the current one.

• Separate stable global navigation from mutable working content. If they live on the same plane, your users will pay the cognitive cost of telling them apart.

Linear's moat isn't "fast" and isn't "minimal". It's that the product respects a user's attention with three concrete design contracts, and then it monetises the muscle memory those contracts produce. That's a harder thing to copy than a colour palette.

I'll keep watching Linear's AI integration story — the chat dialogue today is still the basic ChatGPT-style floating box. I'd want to see them embed agents into the issue lifecycle the same way they embedded keyboard shortcuts into the tooltips. Same playbook, new layer.

Watch the full walkthrough on YouTube: https://www.youtube.com/@Bearliu

又是一年生日。

我 4 月生日。今年 4 月，我 45 岁了。

按照习惯，生日是一个很适合向内看的时间。新年时的复盘，更多是在看这一年做了什么，读了什么书，看了什么电影，去了什么地方，见了什么人。那些都很好，但生日对我来说，好像更适合问另一个问题：

这一年，我到底变成了一个什么样的人？

这几年回头看，我发现自己的生命里有一个反复出现的主题，大多和"系统"有关。不同的时间段，我和系统的关系一直在变化。

20 到 30 岁，我在学习适应系统。

那时候的主题，是如何理解社会的运行，如何找到自己的位置，如何在工作中做好事情并融入环境，如何一步一步往上走。

但系统对每个人并不平均。有的人离资源很近，有的人离资源很远。我从小不在一线城市，离很多优质系统和资源都很远。所以 20 到 30 岁那段时间，我更多是懵懵懂懂地，凭自己有限的感知去认识世界。

30 到 35 岁，我开始逐渐脱离系统。

那几年，我外出创业、接活、做项目、开公司，也去大学教书。我游离于主流系统之外，开始构建一个自己能够解释的世界。我很享受那种自由，它也带给了我很多不一样的视角和经验。

35 岁到 40 岁，我再次进入系统，只是换了一个世界。

来到新的国家，我从零开始工作和学习，重新融入，重新证明自己，重新突破移民过程中碰到的各种问题。适应这个世界，适应这个系统，是一个漫长而艰难的过程。

直到有一天，我应一家本地公司的邀请去做导师。分享结束后，我帮人看简历，和大家在阳台上喝酒聊天。那一刻，国籍和语言这些界限好像都变得模糊了。

后来我下楼，走向自己的车。路上碰到一个熟人，他跟我打招呼，我们闲聊了几句。然后我开车回家。

就在那个瞬间，我突然有了一种感觉：

我终于切换到了这个世界。

像是某个开关发出了"咔哒"一声。

41 到 45 岁，我又开始慢慢疏离这个系统。

在系统中工作，逐渐变得迟钝，也变得吃力。我开始自我怀疑。身体和心理都在给我信号，告诉我这可能不是我真正想要的生活。

终于，在 44 岁，也就是去年，我做了一个最大的转折：离开稳定的工作，也离开了旧的系统。

一年之后回头看，不能说成功，也不能说顺利。

但我现在的生活状态，虽然还远远谈不上最满意，已经比之前打工的时候好很多。我工作的时间比原来少，赚的钱比原来多。更重要的是，我比原来更开心。

当然，生活也变得更加不稳定。45 岁之后会发生什么，我也不知道。

以前我经常说，生活的无序和复杂是不可避免的。现在想想，这件事其实也挺有意思。

20 到 30 岁时，我很着迷 Getting Things Done，试图用一种稳定的方法，去化解生活和世界的不确定性。

30 到 40 岁之间，我慢慢接触敏捷项目管理，也试图用一些确定的、结构化的方式去理解这个世界。

现在，我依然会做计划，也依然会思考。但计划和思考对我来说，更像是为了让自己能够更本能地行动。

这让我想到刚刚玩完的游戏《控制》。在那个游戏里，大家试图用确定的、结构化的方式，去解释一个复杂、充满变数，甚至带有超自然力量的世界。越玩到后面，越能感受到这种努力的无力感。

现实生活当然没有那么夸张。但某种意义上，人也一直在做类似的事情。我们用系统、流程、计划和语言去解释生活，最后发现生活永远会从缝隙里长出来。

这一年，我离开了旧系统，也开始站住自己的系统。

这很像我以前读过的很多黑客文化作品和科幻小说。某种程度上，我好像成了一个游离于系统之外的人，带着一点朋克，也带着一点黑客气质。

那我靠什么重新站住？

我现在最相信自己的能力，已经不再只是那些具体的交付能力。比如做完一个设计、写完一篇文章、制作一个视频。这些当然重要，但它们只是表层。

更底层的能力，是我能在混乱中找到结构，能把模糊的事情说清楚，能把经验转化成判断，能把自己的观察变成作品，也能在不同系统之间来回切换。

这种能力，反而更接近我以前在国内慢慢适应系统之外世界时，长出来的那部分自己。

这一年，我和自由的关系也变了。

从表面上看，我似乎拥有了更多自由。时间自由多了一些，表达自由多了一些，不被别人定义的自由也多了一些。财务上还需要继续努力，但也明显比之前好一些。

但整体来说，我更清楚地意识到了约束。

家庭和生活环境，女儿教育所需要的稳定，房贷，日常开销，这些都不会因为我更自由了就消失。生活依然要一点一点精打细算。

不过，我好像不再在意"必须去搞钱"的状态了。

我很珍惜现在这个时间段。它像是一个窗口期，允许一个四十多岁的中年人，还能有时间和精力去玩喜欢的游戏，看电影，读一些没什么用的科幻小说。

我也开始意识到，冲向目标的过程本身，可能就是目标的一部分。

不是到了某个阶段才开始生活。生活就在过程中，在每天和自己、家人、身体、工作、兴趣之间的互动里。

我似乎离真实的自己更近了一点。

四十多岁以后，身体开始发出一些信号。血脂、心脏、体重、运动恢复，这些都慢慢变成需要认真关注的指标。

我庆幸自己的睡眠、饮食和心情，目前都还处在比较满意的状态。我还在梦想自己能不能拥有腹肌。这个东西我从来没有拥有过，所以一直还有点执念 🤣

但现在坚持运动，好像也不完全是为了腹肌。它更像是一件该做的事。像刷牙，像睡觉，像照顾一个未来还要继续陪我很久的身体。

和家人的交流也比以前更好一些。

他们让我看见了一个更愿意与之相处的自己。家庭的责任很大，有时候也会带来压力，但这就是生活的一部分。不是一个需要解决掉的问题，而是一个要一起生活下去的现实。

这一年，我也更接受生活的不确定性。

就在生日之前，我整理好了自己的遗嘱。这并不是因为有什么预感，也不是因为出了什么问题，只是觉得这是该做的准备。万一真有什么情况，家人至少不会对生活猝不及防。

45 岁之后，我不知道生活会走向哪里。

但我现在更想有机会去探索一些自己还没有体验过的生活。不是为了证明什么，也不是为了完成某个宏大的计划。只是觉得人到这个年纪，如果还能保持好奇，还能继续试试别的可能性，本身就已经很幸运了。

过去几年，我一直在学习如何适应系统、脱离系统、再次进入系统，然后又从系统中走出来。

到了 45 岁，我好像开始面对一个更具体的问题：

离开系统之后，我还能不能靠自己站住。

目前的答案是，可以。

虽然还摇摇晃晃，但已经站在这里了。

现在所有设计师都会被别人问到一个问题：AI 要取代你了，设计师要失业了。

这个话题可以从各种角度来讲，但我认为说这些话的人，大多都没有真正做过设计。这其中既有自媒体为了博眼球，也有没来由的自我恐慌。

但我反而觉得，现在设计的定义外延被扩大了，这其实是一个利好。这并不是因为某种盲目积极的乐观，而是基于设计史的几次跃迁：

设计史上的几次跃迁

1. 早期阶段

设计师最早研究的是印刷品上的细节和平面元素调整。包装啊海报啊，CMYK 啊，出血啊套色啊是需要掌握的。

2. 第一次跃迁（印刷到网络）

从印刷产品进入网络时代，很多平面设计师转变为网页设计师。我当年也算赶上了这一波，开始学习网页交互、Flash 等设计。

3. 用户体验阶段

纯粹推像素不行了，设计进入了用户体验（UX）阶段。这要求设计师了解心理学、掌握用户行为，并能用流程图、动线图等方式，将结果翻译成具体的步骤。

4. AI 时代（现在的跃迁）

到了现在，当所有人都可以 vibe coding，所有人都可以让 AI 生成设计的时候，设计师的核心任务发生了变化：

• 判断意图：在用户输入时减少意图的摩擦。
• 多样化展现：让 AI 在输出时能以多样化的形式呈现。
• 辅助决策：在过程中帮助用户进行更好的理解和决策，有的产品甚至需要适当增加摩擦，让系统变得慢一些。

设计师的外延被扩展了

除了研究平面上的像素调整，我们还需要去判断和定义"实体"，定义一个系统中的实体及其关系，定义各种限制。换句话说，就是定义 AI 如何用这些规则来构建一个系统和世界。

这原本是信息科学家、架构师或系统设计师做的事情，但现在每一个设计师都需要对产品进行这样的定义，这也是本体论（Ontology）的一个重要应用。这意味着你现在做设计，需要能够定义语义以及物体之间的关系，打磨界面，并处理人与机器、人与人、机器与机器之间的交互。

大有可为啊大家！

难吗？当然难！

但是现在有了 AI，学习本身也可以是一个被加速的过程。真的很让人兴奋，我也没想到自己 40 多岁的人了，还会迎来又一次职业上的挑战和可能带来的飞跃。

一年前 vs 现在

一年前我是 Xero 的产品设计师。现在是 Fractional Design Partner，经营自己的设计实践。同时服务几个客户，做不同的产品，按自己的节奏来。如果用一个词形容这一年，我选"旅程"。因为有真正兴奋的高光时刻，也有不想再继续的低谷。

没人提醒你的那种恐惧

所有人都想象自由的美好，没人告诉你自由带来的恐惧。

离开后几天，我就碰到了完全没有料想到的一个情况：时间和自由都有了，但完全不知道该做什么。没有具体目标，没有 KPI，没有结构。在公司工作了那么多年，突然要自己设计方向，说实话挺可怕的。适应这种灵活性需要时间，适应自己给自己定目标也需要时间。

自由是预期中的。迷茫不是。

有没有后悔过？

一次都没有。我认为离开是必须要做的事。过程中有很难的时刻，但从来没想过"我不该走"。

唯一遗憾的是同事。在 Xero 共事的那些人真的很好，这是独立之后无法替代的。

什么时候开始觉得"这就是我要的生活"

等了很久。头几个月特别难，因为遇到了家人健康方面的意外状况，占用了大量时间和精力，完全不在计划之内。

我给自己留了六个月的经济缓冲，但消失得特别快。像闪了一下，六个月就没了。

最近几个月才真正找到感觉。同时服务几个客户，做自己的内容，投入个人成长，不被任何人限制。特别是这个月，那种感觉很明确：这就是我想要的生活方式。

收入

现在月收入比 Xero 高，大概高 40%，工作时间还少了。但一开始完全不是这样。

头几个月几乎没有收入，还没开始做客户项目，只有一些内容方面的小收入。直到去年底我确立了 Fractional Design Partner 的模式，事情才开始起飞。

稳定性完全不同。在 Xero，每月固定打款，可预测，无聊，让我觉得安全，也让我变懒。现在有起有落，我已经习惯了这种节奏。某个收入来源下降了？没关系，还有别的支撑。这就是生活本来的样子。

心理上，我已经不预期每个月的收入一定是固定的。目前状态还是有“手停口停”的情况，但整体来说，既不是那种每月固定打款的稳定无聊，也不是那种纯粹像做内容自媒体一样——停下来就一切都没了。

现在还是有一定积累的，我觉得这就挺好。

最好的月份和最差的月份

最好的月份：同时跑着几个大客户项目，工作量可控，收入是以前薪水的两倍，加上内容收入。

最差的月份：有一个月全身心扑在自己的产品上，结果月收入最终一算，产品收入大概也就几十美金。这比零收入更糟，因为你投入了真实的努力，回报完全不匹配预期。

那个最差的月份教会了我这一年最重要的一课。我把策略从"做自己的产品"转向了"做客户的 Fractional Partner"。这个转型是分水岭。客户合作模式远比独立做产品成功。

加薪 20% 会回去吗？

谢谢，但我 pass。

这一年发现的最有价值的技能

不是工具，是能力。策略思维。发现别人没意识到的价值，然后执行出来。

在 Xero 的时候，这不是我的主要技能。但独立之后，我发现这其实是我的一个强项。我擅长发现机会、把它打包成客户可感知的价值，然后规划和执行。这是被逼出来才发现的能力。

比一年前更强了吗？

是的。经济上、心理上、身体上都更强。一年前我根本没时间运动，今年三个维度都有明显进步。

明年会怎样我也不知道，甚至接下来下一个季度会怎么样，我也不知道。

AI 的时代一切变化都很快，但我在这一年积累的这种心理上的韧性，我觉得比以往的状态要更能够有助于面对未来的不可知。

这大概就是我最大的一个收获。

视频：https://youtu.be/DplVRkdX6zg

当我写的书印刷出来，包裹从美国寄到新西兰的时候，我打开一看，比我想象中更真实。彩色印刷，硬壳封面，手感扎实。这本书从动念到在亚马逊上架，我实际花了大约 18 个小时。

故事的起点：18 个月的专栏

几年前我跟一个中文科技网站合作，写了一个专栏，讲 20 世纪最伟大的科技故事。为了把这些故事讲清楚，我啃了 14 本书，然后写了 14 篇文章。

写完之后就放下了。觉得这事过去了，不会再碰。

转折：如果出一本英文书呢？

今年 我开始使用 ClaudeCode 之后，突然冒出一个想法：能不能把这些中文文章翻译成英文，出一本书？

这事如果是以前的话，有很多障碍：翻译（英文是我的第二语言，我没信心自己搞定）。校对。事实核查。版权审查。排版。每一项都需要时间和钱。保守估计得几周，还得花一笔费用。

但现在有了 AI ，我想：如果 Claude Code 能搞定这一切呢？

方法：先写 PRD，再建 5 个 AI Agent

做产品的老习惯救了我。我没有上来就动手，而是先写了一份 PRD（产品需求文档），定义清楚需要哪些角色、每个角色干什么。

我识别出 5 个关键岗位，给每个岗位配了一个 AI Agent：

Agent 1：翻译官

把中文原文翻译成朴素、流畅的英文。我特别要求它不要加戏，不要擅自改格式，不要加破折号。AI 有个毛病，总想"优化"你的文字。翻译场景下，我只要忠实还原。

Agent 2：编辑

逐章检查语法、语言质量，以及翻译是否忠实于原文。这个 Agent 是语言层面的质量关卡，专门抓 AI 幻觉（翻译过程中凭空编造的内容）。

Agent 3：审计员

事实核查。这可能是最重要的角色。比如书里引用了一句乔布斯的话，审计员会去验证乔布斯到底有没有说过。查不到来源的，就标记出来交给我决定。

这个 Agent 就是整个流程里的福尔摩斯：什么都不信，什么都要查。

Agent 4：版权守卫

检查书里的每张图片、每段引用是否可以合法使用。维基百科的图片在开放协议下可以用，但有些图片不确定。凡是拿不准的，我全部删掉。商业出版宁可保守。

Agent 5：KDP 终结者

把整本书按亚马逊 Kindle Direct Publishing 的格式要求排好版，然后用 Playwright 浏览器自动化完成上传。这一步如果手动做，至少几天。边距、间距、段落规范、trim size，全是细碎但必须精确的规则。Agent 搞定了这一切，还生成了 EPUB 和 PDF 两个版本方便我校对，最后自动在 KDP 后台完成上传。

封面：AI 生成概念 + Figma 精修

Agent 团队处理内容的同时，我在做封面。用 ChatGPT 和 Gemini 生成概念图，挑选方向，然后在 Figma 里按 KDP 封面模板精修成最终版。

上线亚马逊

上传到 KDP，调整元数据（这一步 AI 也帮了不少），然后书就上线了。Kindle 电子书、平装本、精装本，三个版本全部上架。作者价大概 6-7 美元一本，零售价大约 13 美元。

结果是只卖出了……

那么这番操作之后，最终销售成绩如何呢？

目前卖出：1 本 😂

我没做任何营销。在 Twitter 上发了一条，仅此而已。没上播客，没投广告，没联系书评人。

最大的教训：出版一本书是容易的部分。真正难的是让读者知道这本书存在，并且愿意花钱买。这是完全不同的能力维度，我还没有认真投入。

我学到了什么

出版的门槛已经塌陷了。 语言能力、技术知识、排版经验、版权研究，这些过去要么花钱要么花月。现在一个周末加上 AI Agent 就能搞定。

像管产品一样管 AI 工作流。 先写 PRD 是整个项目最关键的决策。它让每个 Agent 有明确的分工，避免了手忙脚乱。

AI 擅长生产，不擅长分发。 Agent 能翻译、编辑、核查、排版。但它不能帮你建受众、造口碑、让人点"购买"。这些事还是得你自己来。

用实验心态起步。 我没打算做畅销书。我把它当一次测试：这事能不能做到？答案是能。而且现在我有了一套可复用的流程，下次如果认真做营销，起点会完全不同。

一个重要前提： 这套流程最适合非虚构、实用类书籍，追求准确性而非文学性。如果你要出版小说或诗集，翻译部分需要完全不同的方案。

有了 AI，可能性已经被打开了。如果你有内容躺在抽屉里，不管什么语言，从手稿到出版的路从来没有这么短过。

视频：https://youtu.be/dZ46OLcczzI

每年报税季之前，我都要做同一件事：把过去一年的收支整理清楚。

实际操作时间大概半天。但那一整天基本上就废了——上午想着"今天要做这件事"，中午开始进入状态，下午在各个银行账户、PayPal、Wise 之间来回切换，导出流水，复制到 Notion，一条一条对分类，晚上收尾。身体坐在那里，脑子里全是数字。

半天操作，一整天注意力。

今年我把这个流程重新建了一遍，现在是：把 CSV 文件丢进去，跑一条命令，报告直接出现在 Obsidian 里。

Notion 时代是怎么做的

我不是没有系统。用 Notion 记账有好几年了，数据库、视图、分类标签，设计得挺完整。

问题是这套系统完全靠手工喂数据。

流程大概是这样：登录每个银行账户，找到导出功能，下载 CSV，打开 Notion，一行行对照着把收入和支出填进去，然后手动打分类标签——这笔是咨询收入，那笔是工具订阅，这个 PayPal 转账不知道是什么，先留着。

有几个地方特别磨人：一是多账户。我有 ASB 个人账户、ASB 商业账户、Wise 和 PayPal，四个地方的流水格式各不相同，没有办法合并看。二是分类靠记忆。时隔几个月回来看一笔转账，根本想不起来是干嘛的，只能去翻邮件或者猜。三是内容收入完全对不上。从 YouTube、播客平台、社交媒体打过来的钱，经过好几手中间账户才到银行，银行流水里看到的只是一笔匿名转账，跟平台对账要另外手动查。

做完之后数字是有了，但心里永远不确定：有没有漏掉什么？分类准不准？

为什么想重建这个流程

触发点是去年整理数据时发现一条内容收入线的数字严重偏低——后来对账才确认，实际金额跟账本记录差了将近一百倍。

这条线的钱一直在进来，只是每一笔都走了不同的中间账户，Notion 里根本没有对应的入账记录。这不是粗心，是系统结构性的漏洞：当数据要从多个平台汇集到一个地方，纯手工根本跑不赢这个复杂度。

那次之后我就决定认真做一个自动化的版本。

目标很简单：给我一份可信任的报告，不需要我在做之前先"准备好心情"。

新流程是怎么搭的

整个项目用 Python 写，核心逻辑分几层。

第一层是标准化。每个账户导出的 CSV 格式都不一样，有些字段名不同，有些日期格式不同，有些金额有货币符号有些没有。标准化这一步把所有账户的数据统一成同一个 schema，后续处理只需要面对一种格式。

第二层是分类。我维护了一个关键词规则表——比如看到"FIGMA"就归为工具订阅，看到"CAREERFOUNDRY"就归为咨询收入，看到"PAYPAL FEE"就归为平台手续费。规则表覆盖不到的部分，调用 Claude API 做二次判断，置信度低的进入人工审查队列。

第三层是内容收入补录。这是最特殊的一块。播客、YouTube、社交媒体打过来的钱，路径太复杂，从银行流水反推几乎不可能。解决方法是直接读平台的原始导出记录作为权威来源，再用日期和金额做交叉比对，看银行里有没有对应的转账入账。匹配到就标记关联，没匹配到就进审查队列，但收入本身不因为银行流水缺失而漏记。

最后是报告生成。跑完之后生成一个 Markdown 文件，直接写到 Obsidian 的财务文件夹里，打开就能看。

现在的体感

现在的操作流程是：把各个账户的 CSV 导出，放进指定的文件夹，跑一条命令。几分钟之后报告在 Obsidian 里。

改变最大的不是时间，是心理负担。

以前到了要做这件事的时候，总是在拖——不是因为懒，是因为知道一旦开始就要全天投入，而且做完还不一定有把握。现在这件事从"要专门腾出一天"变成了"顺手的事"。

数字可信度也高了。系统跑完会标记所有置信度低的条目，我知道需要人工确认的是哪几条，其余的不需要再怀疑。之前那种"应该差不多对"的模糊感消失了。

接下来想做什么

现在报告是每次手动触发生成的。下一步想把它做成定时任务，每个月自动跑一次，这样就不需要等到"要用数据了才去整理"。

还有一个想法是把月度数据做成趋势图，不只是每次看一个静态快照，而是能看到各条收入线随时间的变化。这对判断哪条线在增长、哪条线在萎缩会有帮助。

你有没有类似的手工流程想用自动化替掉？或者已经有了自己的一套方案？欢迎告诉我，我很想知道其他人是怎么解决这个问题的。

每次打开 AI 准备写博客，我都要重新解释一遍：我是谁、我的风格是什么、受众是哪些人、这篇文章要存到哪里。AI 写出来的初稿大多还算过得去，但总是差那么一口气，要么语气像教程，要么结构太模板，或者存错了地方。问题在于，这些"背景知识"每次都要重新交代一遍。

我意识到，我一直在重复做同一件事。

这两篇就是AI帮我写的项目总结博客，非常好，比我写的快多了。

真正的问题是上下文每次都在归零

我日常在跑好几个项目，有些是自己的产品，有些是客户合作，有些是内容工具。每个项目做完一个里程碑，我都会想记录。这件事的频率相当高，差不多每两三周就会有一个值得写下来的节点。

但每次写博客的时候，我都要花相当一部分精力在"让 AI 理解我"这件事上。我的写作风格、目标读者、文章要存到哪个 Obsidian 目录、frontmatter 该写什么字段……这些东西本质上是固定的，每次都交代一遍，纯粹是重复劳动。

我有两个参考文件：一个是记录我个人背景和项目信息的 Bear.md.md，另一个是详细定义内容标准的 Content.md.md，包括受众定义、平台策略、每种内容形态的写作结构。这两个文件我维护得还算完整，但 AI 每次启动新对话，这些东西都消失了。

所以我想做一件事：把"写博客"这个任务打包成一个可以随时调用的技能，让它知道去哪里找参考文件、按什么结构写、把结果存到哪里。

设计一个技能需要想清楚几个问题

Claude Code 有一个技能机制，可以把操作流程写成 Markdown 文件，之后通过关键词触发。我之前已经用这套机制做了语音笔记处理、社交帖子发布等几个工具，所以对这个流程比较熟悉。

但写博客这件事有几个地方需要特别设计，不能直接套用以前的模式。

第一个问题是"观察者视角"的定义。我想让这篇博客读起来像一个在场的记录者在还原事情，而不是总结报告，也不是自我推销。这两者的区别很微妙，但读起来感受差很多。总结报告把经验升华，观察记录保留细节和不确定性，保留那种"我当时也不知道这样做对不对"的质感。我在设计这个技能的时候，专门写了这部分的提示：保留决策过程中的取舍，诚实写出没预期那么顺利的地方，细节比结论更重要。

第二个问题是怎么处理项目有新进展的情况。我的很多项目都是分阶段推进的，比如网站先上线，然后再做响应式改版，然后再做内容更新。每个阶段都可能值得记录，但记录方式有两种：写一篇续集，或者在旧文章基础上直接补充。这两种方式适用场景不同。如果这次进展是一个独立的里程碑，那写新文章更合适，读者不需要看上篇也能理解。如果这次只是小的修正或补充，那更新旧文章就够了。我在技能里加了这个选择逻辑，让它先检查 vault 里有没有相关旧文章，有的话给我选。

第三个问题是文章存在哪里、按什么格式。这个相对简单，但也是每次最容易出错的地方。我的博客草稿统一存在 Obsidian 的 Bear Content Vault/Blog/drafts/ 目录下，frontmatter 需要包含标题、标签、状态、日期、语言、所属项目。这些东西如果每次靠我自己填，总会有漏掉的时候。

从想法到可用，大概花了5分钟

整个技能的设计过程是和 Claude 一起完成的。我口述了需求，它先读了我的两个参考文件，然后我们讨论了几个关键的设计决策，最终把整个流程写成了一个 SKILL.md 文件，放到 ~/.claude/skills/blog-writer/ 目录下。

这个过程中让我觉得有点奇妙的是，我在让 AI 帮我设计一个"让 AI 帮我写博客的技能"。最后验证这个技能是否有效的方式，就是让它写这篇博客。所以这篇文章本身就是技能的第一次实际运行。

技能目前的工作流程是：触发之后先读两个参考文件，问清项目信息，检查有没有旧文章，然后按案例复盘结构写草稿，存到 vault。整个过程我只需要告诉它"帮我写一篇关于 XX 项目的博客"，其他的它自己处理。

这篇文章就是它生成的

我在写这篇文章的时候，几乎没有手动写任何东西。我说了一句"帮我写一篇关于 blog-writer 技能创建过程的博客"，它启动了，读取了参考文件，知道我写这篇博客的上下文（就在刚刚这次对话里），然后开始写。

它最终生成的内容和存储格式都符合我的预期，frontmatter 完整，文件命名格式对，存到了正确的目录。这说明技能的基础逻辑是跑通的。

当然，这是第一次运行，还有一些我还没验证到的地方。比如，当一个项目已经有旧文章、我需要写续集的时候，它的处理方式是否合理；或者对于一个信息不全的任务，它追问的方式是否自然。这些要等后续真正用到的时候再看。

接下来

这个技能接下来最需要做的一件事，是把它真正融入我的工作节奏。一个工具再好，如果不在合适的时机被想起来，也会慢慢被遗忘。我的计划是，每次一个项目到了某个里程碑，第一个想到的就是去跑这个技能，先把草稿存下来，再决定要不要修改和发布。

另外，这个技能的设计思路本身也是可以复用的：把一个重复性的内容创作任务，连同它所需的上下文，一起打包成一个可调用的工具。这个模式我觉得适用于不少场景，不只是写博客。

你有没有在用类似的方式把重复的 AI 任务标准化？或者你在做项目记录的时候，有什么卡住你的环节，欢迎留言聊聊。

问题从哪里来

我本地 Claude Code 代码库里有 10 个项目在同时跑。Financial Adviser、Voice Daily Note、Content Publisher、Shorts Subtitle、CN Newsletter……每一个都有自己的目录、自己的 README、自己的当前状态，但它们之间没有任何联系。

我想知道"哪些项目在跑、哪些停了、下一步各自要做什么"的时候，只能在 Finder 里一个个点目录，或者凭记忆回忆。这不是什么大问题，但足够烦人，尤其是每周做计划复盘的时候。

我想要一个统一的视图。一个看板，三列：Active、Paused、Done，每张卡片上有描述、下一步、当前目标、已知问题、技术栈。

方案设计

用 Notion 做这个事情很自然，我已经把 Notion 当成工作中枢在用。

问题是怎么把 10 个项目的数据填进去。手动填是一个选项，但我更倾向于写脚本一次性导入，原因很简单：手动填 10 个项目、每个项目 8 个字段，很容易出错，而且枯燥。

我用 Claude Code 来规划方案。方案的核心决策有一个值得记录：要不要从各个项目的 README 自动解析数据？最终的答案是不要，直接硬编码在脚本里。原因是各个项目的 README 格式完全不统一，解析逻辑很脆弱，而且维护成本高。硬编码虽然"笨"，但稳定，一次性任务够用了。

Notion AI 出场

按常规做法，我需要在 Notion 里手动创建数据库，逐一添加 8 个 property，设置每个 property 的类型，再建 Board 视图。

但我换了个思路。我把 Claude Code 生成的数据库 schema（那张 property 表格）直接截图，打开 Notion AI，跟它说：按这个表格帮我创建一个数据库。

Notion AI 看了截图，把整个数据库结构建好了，包括所有字段和类型。我就点了一下"确认"，然后手动加了一个 Board 视图，整个过程不到30秒。

这是我没预料到的效率。

Python 脚本

数据库建好之后，Claude Code 写了导入脚本。逻辑很直接：读取 .env 里的 NOTION_TOKEN 和 DATABASE_ID，遍历硬编码的 10 个项目字典，逐一调用 Notion API 创建页面。

数据内容需要我自己提供，这部分 Claude Code 帮我查阅了每个项目的 README 和现有文档，把各项目的描述、下一步、目标、已知问题整理成准确的文字，不是凭空编的。

Notion token 复用根目录 .env 里已有的，DATABASE_ID 从 Notion 的 URL 直接提取。

跑脚本：

python3 sync_to_notion.py

输出：

✓ Created: Financial Adviser [Active]
✓ Created: Voice Daily Note [Active]
✓ Created: Content Publisher [Active]
...
All 10 projects created successfully.

一行报错都没有。

两个 AI，各司其职

回头来看，整件事里有两个 AI 参与。

Claude Code 负责方案设计、数据整理和脚本编写，Notion AI 负责在 Notion 内部创建数据库结构。两者的边界很清楚，协作没有任何摩擦，因为它们各自在自己的主场工作。

我自己做了什么？跟 Notion AI 说了一句话，运行了一条命令，总计操作时间大概五分钟。

这不是说 AI 万能，脚本里的项目数据仍然需要人工判断和梳理，这件事 Claude Code 做了，但它调用的素材是我自己写的 README 和文档。垃圾进，垃圾出，这个规律没变。

结果和边界

看板现在在 Notion 里运行，Board 视图三栏清晰，每张卡片内容完整。

这是一次性工具，脚本写完就封存了。之后在 Notion 里手动维护状态和进度，不需要再跑代码。

唯一要记住的一点：如果哪天需要重建数据库，直接再跑一次脚本就好，但要注意 Notion API 没有防重机制，会创建重复条目。加一个运行前检查的逻辑是可以的，但对这个用途来说没必要，知道这个限制，不重复跑就行。

我有一个用了好几年的习惯：随时录音。

走路想到什么，录。开车有个念头，录。刚开完会脑子还热着，录。我用的是一支 DJI Mic 3，小小一个挂在脖子上，按一下就开始录，再按一下停，文件自动存到录音笔的内存里。

问题是录完以后怎么办。

把录音导出来、用工具转成文字、再手动整理成结构化的笔记、再决定哪些内容可以发布、发布前再润色一遍... 每一步都不难，但加在一起每天要花掉我一到两个小时。而且这件事没有截止日期，没有外部压力，所以它很容易就被推到"等我有空的时候"那个抽屉里。

结果就是：录了很多音，整理了很少，发布了更少。

我真正想要的是什么

我给自己设了一个目标：把整个流程压缩到"一条命令"。

录音笔 SD 卡里的文件拷进来，跑一个脚本，然后我就能在 Obsidian 里看到当天整理好的笔记。如果有些内容值得发布，打个 #Share 标签，再跑一个命令，三个平台（推特、LinkedIn、YouTube）各自准备好的内容就全存到内容库里。

这不是说我想让 AI 替我写东西。我想要的是：我的想法，我的声音，用我的语气写出来，但不需要我坐在那里一个字一个字整理。整个过程我可以全程不参与，但每个环节都有我的影子。

这是一个细节上的区别，但对我来说非常重要。

这就是最终成果：AI自动整理的笔记，按天、分类，自动加上标签和场景。

动手之前先想清楚架构

我不会编程，但我会用 Claude Code 做 Vibe Coding。对我来说，这个过程有点像跟一个超级靠谱的工程师结对——我说想法，它写代码，我测试，出了问题一起 debug，然后继续迭代。

整个流程我拆成三个阶段：

第一阶段：录音变文字。 录音笔里出来的 .wav 文件，用 Whisper 模型转成文本。我优先用 Buzz（一个 macOS 上的 Whisper GUI），失败了自动切到 Python 的 whisper 库。

第二阶段：文字变笔记。 把一天的转写文本打包发给 Claude API，让它帮我整理成结构化的 Markdown 笔记。每条笔记有标题、场景标注、时间戳，内容一字不删，只修错别字和断句。

第三阶段：笔记变帖子。 我在笔记里打 #Share 标签的条目，会被提取出来，然后再调用一次 Claude，同时生成三个版本：推特中文长文、LinkedIn 英文、YouTube Shorts 标题加 hashtag。每条帖子单独存成一个 Markdown 文件，进我的内容库。

实际搭建的过程

说起来三步，做起来当然不是这么顺滑的。

最开始的 bug 很典型：Buzz 的命令行接口在新版本里把子命令藏起来了。我的代码直接调 Buzz --task transcribe ...，结果它每次都悄悄打开 GUI 等待用户操作，两分钟超时，然后 fallback 到 whisper。程序没报错，但其实从来没有真正用过 Buzz。

找到原因的时候有点好笑。正确的调用方式是 Buzz add --task transcribe ...，差一个 add，完全两种行为。而且 Buzz 输出的文件名还带着时间戳后缀，跟代码里预期的不一样，又要加一步重命名。这种 "程序跑通但结果不对" 的情况，是 Vibe Coding 里最难调的——因为你的第一反应是"它成功了"，而不是"这里有问题"。

比较有意思的是 token 截断的问题。生成社交帖子时，我给 Claude 的 max tokens 按输入长度的 1.2 倍估算。听起来有余量，但问题是：输入是一段语音笔记，输出要生成三个平台的内容，实际输出量是输入的三四倍。7 条笔记送进去，只有 6 条出来，最后一条被截断了。改成 4 倍之后，全部完整。

还有一个关于架构判断的决策，我选择了"一次 API 调用生成所有平台内容"，而不是分三次。这样更快，而且 Claude 能在同一个上下文里保持语气的一致性。代价是 prompt 要写得更清楚，每个平台的要求要讲明白。

现在的运行效果

目前这套流程已经稳定跑了几周。

每天的录音，从录音笔拷出来，跑一条命令，几分钟之内就能在 Obsidian 里看到当天的笔记。12 条语音，8 个主题，时间戳、场景标注都在，全量保留，没有任何删减。

社交帖子的部分，我在笔记里标注好 #Share，跑一条命令，每条帖子就有推特、LinkedIn 和 YouTube Shorts 三个版本，按月份存到 Bear Content Vault 里，等我发布的时候直接拿来用或者微调。

最让我觉得值得的，是我现在在做这件事的过程本身。我不需要在发布的时候再坐下来想"这条内容怎么改成英文"，也不需要在录完音之后马上找时间整理，流程已经在那里了，我的工作是往里放原材料，它自动处理。

几个我认为重要的设计判断

零删减原则。 精修只修错别字和断句，不压缩、不总结、不删内容。这条原则很重要，因为我记录语音的目的是把脑子里的东西完整地留下来，而不是只留下重点。

幂等设计。 所有步骤重复运行都是安全的，已处理的文件会被跳过。这让我可以随时中断，随时继续，不用担心重复处理或数据丢失。

分层输出。 同一批内容，一次处理完，同时输出到三个平台。这不只是效率问题，更是风格一致性问题。在同一个 context 里生成的内容，表达方式更统一，比分开处理更自然。

还在想的事情

这套流程里有个地方我还没解决：会议和通话。

我有时候会和客户开会，和合作者通话，这些录音里有很多有价值的东西。但它的处理方式跟个人语音笔记不太一样，它需要的是"结构化摘要"，包括议题、决策、行动项，而不是全量保留。这是下一个要做的版本。

还有一件更有意思的事：当我把播客的制作也自动化了之后，我发现自己一周能更新三期，而原来只能一期。内容量上去了，但"我在每期里的存在感"反而没有消失，因为那些材料、那些判断、那些措辞，还是我的。

这就是我认为好的自动化应该长的样子：不是替代你，而是让你的东西跑得更远。

工具链

• 硬件：DJI Mic 3 录音笔
• 转写：Buzz（macOS）/ OpenAI Whisper（fallback）
• 精修 & 生成：Claude API（claude-sonnet-4-5）
• 笔记管理：Obsidian
• 内容库：Bear Content Vault（iCloud 同步）
• 代码协作：Claude Code（Vibe Coding）

项目开源在 GitHub：voice-daily-note

这篇复盘写给两类人：

第一类是创始人或小团队，你可能正在卡在“网站上线”这种看似不难但一直拖的事情上。

第二类是设计师，尤其是想把自己的服务产品化、想把交付链路缩短的人。

背景：为什么我需要这个网站

2025 年我离开了工作五年的 Xero，开始做 Fractional Design Partner（FDP）。简单说，我以外部设计合伙人的身份嵌入创始人和小团队，做产品判断和设计执行。工作从上游开始，覆盖用户旅程、转化、留存、信息架构、优先级取舍，然后直接下场交付可用的设计与落地方案。

当这个模式开始跑起来后，我很快发现一个现实问题：我需要一个专门的商业落地页。它的目标很明确，让潜在客户在几分钟内理解三件事：

• 我能帮你解决什么问题。

• 我们怎么合作。

• 价格与下一步是什么。

设计稿我早就在 Figma 里完成了，真正拖住我的是 开发。找外包意味着沟通成本和迭代摩擦，自己写工程又不够熟练。Figma Sites 我也试过，但在动画、响应式和一些细节控制上仍然有限。

直到我开始用 Claude Code，我才觉得“设计师自己把网站交付上线”这件事进入了一个新阶段。

一天完成，从空文件夹到上线

网站从零到上线发生在一天之内。节奏并不极端，中间我做了午饭、去海里游泳、接孩子。真正坐下来“推进交付”的时间大概四小时左右，剩下是碎片化的检查、反馈与小修小补。

这里有两个前提条件需要说清楚：

第一，Figma 设计稿已完成，只有桌面版（960px），没有移动端。

第二，原稿动态效果不多，所以这个项目的挑战主要在“从设计到可上线的响应式页面”这条链路上。

过程：每一步发生了什么

上午 9:30：先把项目拆解成可执行的计划

我在终端里打开 Claude Code，把 Figma 设计稿链接给它，要求它基于设计稿实现网站。

Claude 第一件事没有写代码，而是先生成实施计划，把项目拆成几段：连接 Figma MCP、初始化项目、实现页面、响应式适配、Git 版本控制、Vercel 部署。

这一步很关键。对我来说，真正决定成败的从来不是“能不能写出来”，而是“能不能在有限时间内把交付闭环跑通”。AI 先把路径画出来，后面每一步就更像按 checklist 走。

小技巧：在 Claude Code 终端里，Shift + Tab 可以切换到 Plan Mode。

9:30 到 9:35：连接 Figma 设计稿

通过 Figma 的 MCP（Model Context Protocol），Claude 可以读取设计文件，提取颜色、字体、间距等参数，并下载图片素材。几分钟内它就整理出一套可用的设计 token，包括色彩、灰度、字号与行高。

这一步的价值在于，设计到开发之间最繁琐的“翻译层”大幅减少了。我不需要再逐条解释间距、字号、色值，也不需要手动导出几十个素材。

9:35 到 9:55：初始化项目 + 桌面端布局落地

Claude 用 Next.js + Tailwind CSS 初始化项目，然后按区块实现页面。我的网站大概 9 个区块：导航栏、Hero、社会认证、痛点、服务策略、案例研究、定价、CTA、页脚。

不到 20 分钟桌面端完整布局就出来了，素材也能正常加载。打开浏览器那一刻我就知道，这件事已经“可以交付”了。后面更多是质量控制。

下午：桌面端精调，更像和工程师一起做 Design QA

午饭后我去咖啡馆继续推进。对照 Figma 原稿，还是有很多细节要调：阴影、边框、间距、图片裁切、组件对齐。

我的工作方式很简单：给 Claude 发截图，指出差异，让它改。这个过程非常像你和靠谱工程师一起做 Design QA，只不过响应速度更快。

一个有意思的现象是：AI 很擅长“结构级”的批处理，比如把所有图标统一替换为 SF Symbols，几乎瞬间完成。但当你要它做“像素级的视觉微调”，它会用很多 token 来回试，效率反而不稳定。我的结论是：结构和规律交给 AI，微调和最终审美由人来拍板，必要时直接给它更明确的素材或裁切结果。

下午：响应式适配，这一段是最大工作量

设计稿只有 960px 桌面宽度，但网站必须在手机（375px）和平板（768px）上都能正常工作。

Claude 的处理方式是把大量绝对定位改成更可靠的 Flex 布局，并加上响应式断点。我这里记录几个关键点，都是“能直接复用”的做法：

Hero 区块在桌面和手机使用不同背景图，手机端需要竖版裁切。

导航栏抽成独立的客户端组件，加了汉堡菜单。

Strategy 区块原本用了很多绝对定位，改成 Flex 结构，并用 aspect-ratio 控制图片比例与稳定性。

定价卡片从横排改为纵向堆叠，按钮触摸目标按移动端习惯做了更友好的尺寸（比如 44px 触摸区域）。

另外它顺手修了一个视觉问题：黄色高亮背景原本是 SVG，缩放时圆角会变形。Claude 把它替换成 CSS 背景色加圆角，维护成本更低，也更稳。

傍晚：动画和微交互，让页面“更像一个成熟产品”

页面结构稳定后，我加了一些克制的动态效果，让体验更精致但不打扰：

滚动触发的渐显动效，每个区块进入视口时淡入上移。

Hero 的加载动效，标题、描述、按钮依次出现。

卡片和图片的 hover 效果，轻微缩放和阴影反馈。

导航栏 Logo 的轻微 hover 缩放。

这一段的原则很简单：动画是为信息层级服务，不是为了炫。

晚上：吸顶导航 + 毛玻璃效果，以及一次很典型的排错

我希望导航栏在滚动时固定在顶部，用户随时能点到 CTA。Claude 做了 sticky 吸顶和毛玻璃背景效果，顶部透明，往下滚动后半透明白色加模糊，风格接近 Apple 或 Stripe 的那种克制质感。

这里遇到第一个明显 bug：sticky 不生效。我把截图给 Claude，它很快定位到原因：页面外层容器有 overflow-x-hidden，这类 overflow 设置会影响 sticky 的行为。解决方式也很直接，把 overflow-x-hidden 移到更合适的位置，避免破坏 sticky 的计算。

如果你自己查，这种问题通常要花不少时间翻规范和试错。AI 在“定位原因”这一步非常强，这也是我觉得它最像一个高级工程搭档的地方。

晚上：接入真实链接，上线

最后一步是把所有链接换成真实地址：CTA 指向 Calendly，审计样例指向 Notion，社交媒体指向 LinkedIn、X 和邮箱。

代码提交到 GitHub，Vercel 自动部署。然后我在 Vercel 配置自定义域名 bearliu.com，调整 DNS，等 SSL 自动生效。

晚上 10 点，网站上线。

我踩到的坑，以及处理方式

这次踩到的问题不多，但都很典型，值得记录给以后复用：

目录名包含空格。项目文件夹叫 “FDP website”，一些脚手架工具不喜欢空格。解决方式是初始化时指定不带空格的 name，并在终端命令里用引号处理路径。

Tailwind CSS v4 配置方式变化。v4 的主题配置从 tailwind.config.js 转向在 CSS 文件里用 @theme inline。Claude 一开始就按新方式处理，省了不少时间。

Sticky 失效与 overflow 冲突。只要祖先容器里有不合适的 overflow 设置，就很容易让 sticky 行为失效。

SVG 背景缩放变形。用 preserveAspectRatio=“none” 的 SVG 在响应式下容易拉伸圆角。替换成 CSS 背景与圆角更稳，也更容易维护。

最终成果

• 网站地址：bearliu.com

• GitHub 仓库：已更新到我的 GitHub

• 总耗时：约一天（断断续续，实际工作约四小时）

• 技术栈：Next.js 16 + Tailwind CSS v4 + Vercel

• 外部依赖：未引入额外 UI 组件库

复盘：我真正学到的几件事

第一，设计师把“交付链路”自己跑通变得现实了。过去“设计师会写代码”常常意味着要补大量工程知识。现在更像是你把目标定义好，把质量标准抓牢，工程实现交给 AI，然后你做验收与迭代。对我这种理科背景、自学设计的人来说，这个变化非常关键。

第二，从 Figma 到可上线代码的路径明显变短了。MCP 让 AI 能直接读设计意图，减少了大量翻译工作。我看到网上有人说 Figma MCP 体验不稳定，但就我这次项目来说，设计还原度在第一轮就能达到很高水平，后续主要是细节修正。

第三，排错效率是质变级别的提升。很多阻碍设计师做开发的，并不是写代码，而是遇到问题时不知道怎么查、怎么定位。AI 在“快速缩小问题空间”上非常强，让你能把时间花在更有价值的判断上。

第四，迭代的手感变了。加一个 hover、改一个链接、调整一个布局，反馈几乎是即时的。这种体验会让你更愿意做小步快跑，也更愿意把网站当作一个持续迭代的产品，而不是一次性工程。

第五，人类的判断依然是核心。整个过程中我必须做的事情包括：决定页面内容的优先级、把控信息结构、验收设计还原度、测试交互体验、选择哪些细节值得做，以及把真实的业务链接和商业动作接上去。AI 很强，但它不会替你做商业取舍。

第六，AI 擅长与不擅长的边界很清晰。结构化重构、批处理替换、排错定位属于它的强项。像素级视觉微调容易让它来回试错，遇到这种情况更好的方式是你给它明确输入，比如更合适的裁切图、明确的对齐基准，或者干脆你直接把结果定下来再让它落代码。

这件事对我业务的意义

回到 FDP 的大图景。我做的事情本质上是帮创始人和小团队获得“更好的判断力 + 更快的交付速度”。这次我用一天把自己的商业网站从设计到上线跑通，其实就是一次示范：当你把工具和协作方式选对，很多过去需要一个小团队的事情，现在可以由一个人完成。

这个网站会成为我的获客链路起点。潜在客户通过 LinkedIn、X 或口碑找到我，进入 bearliu.com，快速理解我能解决什么问题、怎么合作、多少钱，然后预约一个 15 分钟的 intro call。链路清晰，可控，可迭代。

同时这个项目也变成了我的内容资产。把 AI 融入真实工作流，把过程记录下来分享出去，这就是我一直在做的事情。对独立设计师和小团队来说，AI 带来的变化很直接：你能用更小的组织规模，完成更完整的交付闭环。关键在于你能定义标准，做出取舍，然后让工具把执行效率拉满。

如果你也在打磨产品，尤其是卡在转化、留存、体验或优先级取舍上，你可以在这里找到我。也许我们可以合作。

https://bearliu.com

I Built My Business Website in One Day With AI (As a Designer)

I built my own FDP website in a day, with AI. From an empty folder to a live site.

Not a “look I can code now” flex. More like a real workflow shift I didn’t fully expect.

Context: I left Xero in 2025 and started working as a Fractional Design Partner (FDP). I embed with founders and small teams to help with product judgement and design execution, starting upstream with the user journey, conversion, retention, and prioritisation. Not just “make the UI pretty”.

To make that work, I needed a proper landing page. Something that answers, fast: What can I help with? How do we work together? What does it cost? What’s the next step?

My Figma design was done. The thing blocking me was development. Outsourcing adds friction. Building it myself used to mean a big engineering learning curve.

Then I tried Claude Code.

Here’s what happened, in practical terms.

I gave Claude Code my Figma link and asked it to build the site based on the design.

It didn’t start by spraying code everywhere. It started with a plan: connect Figma MCP, bootstrap the project, implement the page, make it responsive, set up Git, deploy on Vercel. That alone made it feel like working with a solid engineer.

The biggest unlock was Figma MCP. Claude could pull design tokens (type, spacing, colours) and assets directly from the file. The usual “translation layer” between design and build got dramatically thinner.

Desktop layout came together quickly. The real work was quality control and responsiveness. My design was desktop-only (960px), so we had to make it work properly on mobile and tablet.

A few specific things we changed: • Refactored absolute positioning into more resilient flex layouts • Used different hero imagery for mobile (cropped vertically) • Built a proper mobile nav with a hamburger menu • Stacked pricing cards and adjusted tap targets for touch • Replaced a scaling SVG highlight background with a simple CSS solution, because the corners were warping on different widths

We also hit a classic bug: sticky nav didn’t work. The cause was an overflow setting on a parent container (overflow-x-hidden). It breaks sticky behaviour. Claude found it fast, explained why, and fixed it cleanly. That’s where AI really shines for me: debugging and narrowing the search space.

By the end of the day, the site was live on my domain.

What I learned (the part I think matters for other designers):

1. “Designer to production” is more realistic now. You still need taste and judgement, but the execution bottleneck is much smaller.

2. AI is strongest at structure and debugging. Refactors, repetitive replacements, and finding root causes. Huge win.

3. AI is weaker at pixel-perfect micro tuning. If you keep saying “move this 4px left”, it can burn tokens and time. The trick is: you decide the standard, give clear inputs, and let AI do the heavy lifting.

4. The human role doesn’t disappear. I still owned content priorities, what to show first, what not to show, the overall tone, the business links, and the final QA.

This is exactly how I think about FDP work too: clear priorities, high-leverage fixes, then ship.

If you’re a designer, I hope this gives you a bit of momentum. You don’t need to become a full-time engineer to ship real things.

If you’re a founder or building a product and want help sharpening the experience (journey, conversion, retention, and what to fix first), you can find me here. Maybe we can work together.

bearliu.com

情商太高了现在的年轻人。

我说当然不是。大学那会儿没什么好玩的，就死命练吉他。现在么早就荒废了。那会二也玩游戏，但电脑配置都超级低。

他又问："那是什么时候？"

我说："2000年前后吧。那时玩得最多的就是《三角洲》、《反恐》、《星际》，再早点还有《红警》、《仙剑》。

他说："我还以为那时候大家都玩《魂斗罗》呢！"

那得再早个十多年啊。

我二十岁的时候，学校就在翠湖旁，天天在这一带瞎混。读着自己完全不喜欢的专业，懵懵懂懂的，每天基本就是玩游戏、读武侠小说。不知道未来怎么样，也不知道自己到底想干什么。学业和现实脱节，看起来也和我整个人生没什么关系。我学的是物理专业，但大学几年最大的收获，就是知道了自己根本不适合这个方向。

这个故事，我反复讲过。每次工作面试，外国面试官看到我的简历都会挑挑眉毛，问一句："你怎么是学物理的？"

然后我就会开始讲我的"自学设计"之路。

二十多岁，真是怀念。那时候还能熬大夜玩游戏，接几十块的私活，赚点小钱就开心得不得了。也曾有周末的夜晚，拎着吉他，在翠湖周围想找家酒吧进去弹唱赚点外快，却始终鼓不起勇气。绕了两圈，最后又回宿舍。

也曾经在翠湖北门门口的石阶上默默地弹琴，偶尔有一两个女生坐在旁边听完一两首歌，又静静地走了。很平常，什么都没发生。

唯一一次"特殊"的回忆，是有位刚从监狱出来的大哥走过来，递了我一瓶啤酒，然后在我身边坐下，给我讲了他在监狱里的故事。

我发现，音乐的魔力就在于它能让人进入某种状态、某段回忆。

听着90年代和2000年香港的那些老歌，走到了当年厮混过的翠湖边上，那些青春里的片段，也就都浮了上来。

故地重游

周五，我决定认真地过一次"Artist's Date"。本来打算看电影或做点别的事，最后还是选择了更适合自己节奏的方式----City Walk。戴上降噪耳机，听着陈奕迅的粤语老歌，我走在昆明的老街老巷，回忆起十几年前刚辞职、在这座城市开始创业打拼的日子。

一路走到华山路，当年我在这里租了第一个办公室。那个办公室地址很特别：朱德故居，一个漂亮的四合院。具体是怎么租到的就不细说了，总之是一段有意思的缘分。我大概在这里工作了两年，办公的地方在朱德故居二楼偏角的一间小屋。严格来说，并不是朱德本人的卧室，而是他警卫员或亲属曾住过的地方。

那时候，我们就在这个四合院里喝茶、聊天，我也在这儿接到了第一个正规的设计项目：西山森林公园的网站，注册了公司，开始了创业生涯，时间应该是2010年左右。

最让我记忆深刻的一件事：我当时在朱德老人家住过的院子里搞了一场露天电影。我把自己家的投影仪和幕布搬出来，召集朋友，在故居的夜色中放了一场《罗马假日》。现在想起来真的有点past life的感觉。

现在这里已经变成红色教育基地，纪念馆显然拿了不少经费，修缮一新，和当年的模样截然不同，到处都是朱德的诗词与事迹。当然，丝毫不提他人生最后的那段历史。

这很正常，但我还是在馆内看到一个有趣的隐喻：整座展馆唯一的雕塑，是"血战棉花坡"。想想朱德晚年和棉花的缘分，这这这……

旁边的广义饭店，是老昆明人爱聚的地方。还有一家隐藏在小区破楼里的私家素食馆，我每次接待客户、朋友，都会带去那里。一来显得有点逼格，二来其实价格也实惠。我和师傅很熟，来去如家。

在昆明，要活得惬意，其实不难。出了院子，走上200-300米，就能到翠湖。朱德故居旁边就是五华山，云南省政府办公的核心区域，和那些新城区比起来，这里变化得没那么快。青云街曾经的青石板路虽然已经被拆掉了，但我探索时还是找到一小块尚存的台阶，仍然是民国时期的青石板。

我三十岁出头的时光，大概就是在这里混过来的。

现在再走在这里，还是感觉时间的流动不太明显。也许是我个人太怀旧。虽然现在已经是2026年，科幻电影里那些"未来年份"一个个都被现实超越了，但时间，好像也不是真的走得那么快。

大德寺双塔：藏匿于时光深处的古迹

大德寺双塔，可能是昆明隐藏最深的一处古迹了，连很多老昆明人都不知道。我也是当年在朱德故居租办公室的时候才知道它的。当年我的办公室离这儿很近，在几位老昆明大哥的带领下，才第一次来到这里。

双塔旁边的螺峰街，本身也是一条与时间绝缘的街道。事隔十几年，我再次走在螺峰街，恍如十几年前刚满三十岁、在这里开工作室时所看到的景象，一切仿佛都未曾改变。

说回到大德寺双塔：它是在大德寺建立之后又隔了一百多年才建起的。大德寺建于元代，而双塔则是明代所建。大德寺早已荡然无存，但这两座塔一直伫立至今。后来，塔附近办过学校，也办过其他商业，现在是一片普普通通的居民小区。小区的破楼正面，就是那两座六百多年前的明代古塔，非常奇幻。

塔的意义，可能就在于是时间的一个定轴坐标。时间一长，寺会消失，楼会消失，人会消失，朱德不在了，棉花坡不在了，大狗熊也会不在，但这两座塔却还会继续在这里伫立。当然只要时间的尺度足够长，这两座塔也会消失。

老昆明五华山这一带，最赞的就是各种四通八达的小巷。螺峰街沿路最多的就是不同的巷子，旁边点缀着各种小吃摊和居民楼。有人把苦菜挂在栅栏上晾晒，云南的阳光，是最好的保鲜用具。偶尔还能看到一两栋老楼，仍保留着民国时期的风貌。

如果用一句话概括：我从一个主要依赖工资的线性系统，切换成了一个由 内容 / 设计咨询（FDP）/ 产品 共同驱动的组合系统。总收入在表面上下降了，但我反而更开心，因为这次下降不是“变差”，而是“换挡”。

这一年我也更清楚地看见：自由的代价很贵，但它买到的不是休息，而是选择权。选择权会反过来塑造一个人接下来十年的职业、健康和关系。

下面是我把这一年拆开后的完整复盘。写给未来的自己，也写给任何好奇“一个普通中年人怎么把自己从单一轨道挪到三轨并行”的读者。

财务回顾

收入：从单引擎到三引擎

2023 和 2024 年，我的收入结构很“标准”：固定工资是主干，其他收入是枝叶。稳定，但也意味着上限被雇佣关系锁死。

2025 年 5 月，我离开了全职工作。于是 2025 的“总收入下降”几乎是必然的结果，因为我只拿到年初一段时间的工资收入。这个事实并不戏剧化，戏剧化的是另一件事：我的非工资收入在这一年里反而明显增长，已经接近可以覆盖家庭的大部分日常开支。

我这一年工资之外的收入大幅上涨，这是个非常良好的迹象

这件事的意义非常大。它说明我并不是“裸辞去浪”，而是把过去几年在下班后一点点搭出来的东西，真正推到了可以承重的位置。

我喜欢把这次转型称为“基础设施升级”：

• 以前的我像一栋房子只有一根主梁，工资就是那根梁。

• 现在我更像搭了三根梁：FDP（稳定主梁）、内容（复利梁）、产品（波动但可能爆发的梁）。

这三根梁的组合，让我第一次感觉自己不是在“找工作”，而是在“经营一家公司”，哪怕这家公司目前只有一个人。

三驱模型：Good / Grind / Gamble

为了让这个框架更容易被自己和别人记住，我把它用一个带点荒诞气质的名字固定下来：

The Good, The Grind, and The Gamble（好・苦・赌 三驱模型）

• The Good（好）：FDP 设计咨询，稳定、可预期、能覆盖底盘。

• The Grind（苦）：内容创作，长期磨练、复利增长、对外建立信任。

• The Gamble（赌）：产品与数字资产，可能很慢，也可能突然爆发。

它很像西部片三人组，只不过我不是拿枪去决斗，而是拿时间去下注。区别在于：我可以控制下注的比例。

这幅草图对我来说非常值钱

2026 的收入策略：继续飞轮，不追幻觉

2026 年我会继续沿着这三条线推进，但重点会更清晰：

• FDP 做地基：优先保证稳定现金流，让生活不被市场波动、平台波动、情绪波动绑架。

• 内容做增长曲线：不把它当主战场，但把它当长期的信任资产，同时为 FDP 与产品提供“低成本获客”。

• 产品做高杠杆试验：接受它的非线性，不用“努力”去逼它线性增长，只要持续实验、持续迭代、持续积累可复用资产。

投资回顾

2025 的结果：吃到了趋势，但不把它当本事

2025 年我的投资表现非常亮眼，本质上是两件事叠加：

1. 高波动趋势被我抓住了（集中科技股带来的弹性非常强）。

2. 底盘没有塌（ETF 和定投让组合不至于失控）。

但我对这件事的结论很明确：2025 赚到的相当一部分，是趋势红利，不是稳定能力。把红利当能力，是投资里最常见、也最昂贵的幻觉。

我在投资上真正做对的事

如果只总结“可复制”的部分，我认为是这三条：

• 用 ETF 做底盘：它不是为了赚钱最快，而是为了让我在波动里不做蠢事。

• 只在能讲清楚‘为什么’的主线上下注：不碰自己讲不清逻辑的东西。

• 把生活现金流和投资彻底解耦：投资账户的波动不应该影响日常生活决策，否则迟早会被迫卖出、错过复利。

2025年的收入真的还挺多元化的

2026 的红线：不追 2025 的回报率

2026 年我给自己设了三条红线，简单粗暴：

1. 任何单一资产占比过高就削，不让一个标的决定我的命运。

2. 因为“去年赚过”而加风险，立刻停。

3. 如果我开始频繁看账户，说明策略出了问题。好的策略应该让我更少看账户，而不是更想看。

我希望 2026 的投资目标不是“再来一次 2025”，而是把组合变得更像一台可长期运行的机器：有底盘、有纪律、有缓冲。

健康回顾

两个阶段：上半年掉血，下半年回血

2025 年我的健康状态很明显分成两个阶段。

上半年我身体状态下滑，背后的原因很现实：工作压力、两地奔波、家庭照料带来的持续消耗。免疫力、体型管理都不如前两年，健身房也处于“三天打鱼两天晒网”的状态。

下半年开始，我真正意识到：中年人的健康不是“有空再管”，而是“任何事情都要给它让路”。我开始用 AI 辅助记录和调整，同时把运动策略从“偶尔猛一下”改成“能长期维持的节奏”。到了年底，体重和体脂进入相对稳定并逐步下降的轨道，这是一个让我很安心的信号。

预防优先：中年开始补“常识课”

2026 年我 45 岁，40 岁这段已经过半。以前不太在意的事情，现在都变成了“需要提前建立认知和监测”的领域，比如：

• 心脏与代谢风险

• 免疫与呼吸系统

• 消化系统（包括肠道）

• 神经系统与心理健康

今年做过一次基因检测，整体质量一般，但仍然给了我几个足够严肃的提醒：某些慢病风险偏高，而其中“心理健康相关风险”高得出乎意料。

我对这件事的态度是：风险不是命运，但风险是提醒。

它提醒我把心理健康当成需要预算的项目，不论是时间还是金钱。对知识工作者来说，心理健康的重要性依然被严重低估。

2026 的健康方向：维持节奏，别赌身体

我给自己设定的方向很明确：

• 继续维持已经建立的运动节奏，更多户外活动，健身房作为补充而不是唯一解。

• 每周给自己一次 Artist’s Date（精神层面的“保养”要被制度化）。

• 更刻意地建立“避开重大疾病的习惯”，而不是靠短期冲刺。

事业回顾

2025 的高光：离开大厂后，我还活得更像个人

这一年职业层面的几个关键节点，基本都指向同一件事：我离开雇佣关系后，反而更能发挥自己的组合优势。

• 离开 Xero，完成一次真正的信仰之跃。

• 发布了自己的第一个 App，并且从上线第一天就开始变现。

• X（Twitter）账号增长到 11 万粉丝，成为内容与产品冷启动的重要渠道。

• 用“卖出一部分股票”换来半年自由时间，这可能是我人生里最贵但最值的消费之一。

• 做了一个“20 小时赚 1000 美元”的小挑战，用来验证自己是否真的具备独立变现能力，结果验证成功。

• 低调启动 FDP 项目，并开始形成稳定收益，同时工作时长明显下降，生活节奏更可控。

我最后一张在 Xero 的移动端设计团队合影。一个星期后，我辞职了。

我对工作的理解变了：慢季节是生产力的一部分

2025 年我大概有两三个月属于“农闲季节”，当时还会有点内疚，但后来我读到《慢生产力》的相关思路，突然释怀了。

自由职业的价值，不是“永远更努力”，而是允许自己像古代学者一样有节律：忙季全力输出，慢季积累、学习、运动、恢复。工业文明让人误以为全年都该像机器一样平滑运转，但人不是机器。

2026 年我想把这件事做得更极致一点：慢季节不只是休息，而是用来构建下一轮输出能力的“充电站”。

2026 的职业待办：更清晰地对外表达我的定位

我现在的定位已经不只是“产品设计师”，而更像：

• 产品与设计的复合型顾问

• 增长与内容的实践者

• AI 工作流的搭建与训练者

• 产品孵化与资产积累的长期玩家

但我还没有把这个身份用更清晰的方式对外讲出来。2026 年这是必须补上的一课：不是为了包装，而是为了让对的人更容易找到我。

去参加奥克兰的 Framer 聚会，结识了很多优秀的设计师。

关系回顾

家庭：我更清楚什么是核心资产

这一年家庭层面最大的主题，是父亲两次突发疾病带来的关系变化。它逼着我们面对一些多年回避的问题，也伴随着冲突与压力。

但我也看到自己的成长：我更能分清“我能控制什么”和“我无法控制什么”。这有点像斯多噶学派的训练，只不过不是读书读出来的，是生活硬塞给我的。

也因为这个过程，我更确定：我的小家庭是我最重要的核心资产。未来的职业规划、城市选择、时间分配，都会以此为中心。

社交：少混圈子，多建立真实连接

2025 年我和不太熟悉的人完成了大约 25 次高价值互动。复盘下来，最有效的连接方式是：

• 线下活动

• 1 对 1 catch up

• 播客访谈

• LinkedIn 的长期互动

我也看清一件事：一些“浅层的行业寒暄”，尤其是没有共同目标的交流，价值并不大。

2026 年我更想做的是：跟随好奇心去见更多人，但不靠“混圈子”。我更愿意组织小规模的咖啡聊天，三到四个人足够，重点是深度与真实。

将空手道晋级到了橙带，但我打算明年换一种运动

奥克兰八公里城市跑，结识了一位开朗的大叔。

和前同事们聚餐

黄老板邀请参加独木舟 + 爬山

内容创作回顾

2025 年我做内容的总体感受是：前半年很混乱，后半年开始成型。

成型的标志不是数据，而是我终于找到了“多平台可以互相喂养”的结构。

YouTube：试错很多，定位终于清楚

2026年制作的全部 YouTube 视频

这一年我做了 32 个视频，增长并不漂亮。题材尝试得很散，甚至做过城市漫步这类比较随机的内容。

但下半年开始，我慢慢找到了更适合自己的定位：用我的专业视角做英文内容，把 AI、设计、产品连接成一个可持续主题。同时我建立了一整套 AI 辅助制作流程，从脚本、选题、审计到后期，都更标准化。

2026 年我会继续稳定输出英文的 AI + 设计 + 产品主题视频。目标不是爆款，而是每一条视频都在制作和表达上更成熟。

去谷歌办公室参加 YouTuber 聚会

和另外几位 YouTuber 互相分享经验（他们都是百万级，我是小虾米哈哈）

播客：数据一般，但商业化很强

2025 年我做了 45 期播客。下载量不算爆炸，但商业化效果非常好，甚至远超 YouTube。

这一年我也因为工作和家庭停播过几周，后来恢复并在下半年进入每周一期，11 月后提升到每周两期。最大的收获不是“更勤奋”，而是我摸索出一套适合自己的 AI 自动化流程，让播客收入出现了明显的阶梯式增长。

同时也采访到了一些非常有价值的嘉宾，这类访谈对我来说不只是内容，它也是一种建立真实连接的方式。

2026 年我会继续加大自动化投入，并启动面向澳新创业者的英文访谈节目，把“内容”与“关系网络”真正串起来。

2026年制作的全部播客（中间停了接近三个月）

Newsletter 与博客：把平台当工具，把资产握在手里

Newsletter 这一年写得还算稳定，中英文分头策略也更清晰。增长做得不算好，但我完成了更重要的事：架构统一、自动化增强、发布成本下降。

对我来说，Newsletter 的核心价值越来越明确：用户数据属于我。 在这个时代，这是一条越来越稀缺的护城河。

博客这块反而是我 2025 的一个欠账：写了不少内容，但没有系统发布。现在回头看，博客才是最稳定的长期记录平台，值得用十年以上的尺度去经营。2026 年我会把内容更规律地沉淀回博客，而不是只丢在社交平台的河流里。

X（Twitter）：强工具，但也最容易反噬注意力

X 这一年继续保持高频分享，粉丝增长到 11 万。它带来收入，也带来信息优势，还帮助我做了产品冷启动。

但它的问题同样清楚：它会悄悄削弱我做深度内容的专注力，也会降低我建立深度关系的耐心。2026 年我必须把它放回一个可管理的尺度里：它是工具，不是我的主人。

不过，借助 X 来结识有意思的人，非常好用！

在大理福尼亚和Ban总，铁锤、小孙面基

购物回顾

这一年我买过不少东西，但真正“最值”的，往往不是硬件，而是能改变我时间结构和工作结构的投入。

最值的投入：自由时间

我用一笔很贵的成本，给自己买了 6 个月不工作的自由时间。它可能是我近十年最奢侈的消费，但也最值得。它让我确认：自由不是奖励，而是生产资料。

我甚至计划未来每年给自己买固定的一段“自由时间”，当成一个制度，而不是偶尔的冲动。

文石的这款彩色阅读器非常赞

生产工具与内容设备

今年的硬件投入基本围绕“稳定生产”：

• 新的 MacBook Pro（生产力底盘）

• DJI Pocket 3（内容制作的核心设备之一）

• 联合办公空间的次卡（环境切换对我很重要，虽然贵，但能换来状态平衡）

阅读与软件订阅：给自己买“认知效率”

我继续在阅读与信息管理上投入，包括电子书设备、阅读工具、以及一堆付费软件订阅。它们的共同点是：减少摩擦、提高密度、让我的知识输入与输出更顺滑。

我不太担心“隐私焦虑”这类讨论，因为我很清楚自己在工具里放什么，不放什么。对我来说，效率是真实收益。

小鱼滑板，两百多人民币，带给我很多开心的时间

学习回顾

如果用传统标准看，2025 年我“系统学习”的东西不多。但换个角度看，我这一年的学习方式更接近真实世界：目标驱动 + 实战倒逼 + AI 反复打磨。

我学会了用项目把学习拉起来，例如为 JAM 做推广计划时，我会去查资料、建策略、搭网站，然后在实践中不断修正。学习不再是“先学完再做”，而是“边做边学边修”。

失败也有，比如年初我尝试用 Anki，但很快发现它并不适合我当前阶段。对我来说，实战导向的学习更有效，尤其在设计、产品、内容这些领域。

2026 的学习方向

我对明年的学习方向也更明确：

1. 把 AI 更深地实践到工作流里，而不是停留在工具层面的尝鲜。

2. 金融与投资要系统学习。2025 的收益很亮眼，但我不想做“运气型选手”，我要让能力配得上运气。

3. 设计与产品继续走项目实战路线，并且把复盘与分享变成固定机制。能讲出来，才算真的学会。

游戏、阅读、影剧回顾

游戏：故事型让我感恩，机制型让我上头

2025 年我玩了 10 款游戏。中年还能有时间玩游戏，我觉得已经很幸运。

最打动我的还是故事型游戏，那种“现实里不可能经历的平行世界”会让我产生一种奇怪的感恩感。但真正让我花最多时间的，反而是机制型、策略型、越玩越停不下来的那几款。人终究是会被设计好的系统钩住的，这点我作为产品人也只能苦笑。

这一年玩过最赞的游戏：最后幸存者2

电影与剧集：我依然需要幻想世界

电影看了不少，类型很杂。我很享受“在不同世界穿行”的体验。剧集更费时间，但高光时刻也更密集。某些剧的某些瞬间，会让我觉得这时代的娱乐工业依然能做出世界级作品。

这一块对我而言不只是消遣，它也是一种心理回血机制。把它当作“休息”，我反而更能理直气壮地享受它。

阅读：从“外骨骼”回到“肌肉训练”

我每年都会写一次读书回顾，这个习惯十多年了。最初是做播客时发现“以输出倒逼输入”是成长最快的方式。

2025 年我的阅读体验出现了一个意外的转折：我读了更多中文书，很大原因是翻译工具太方便，英文原著一键转中文，效率极高。但我后来意识到，这像穿着“机械外骨骼”去训练，走得快，却练不到肌肉。于是我给 2026 定了一个很朴素的规则：回到纯英文阅读，允许慢下来，但要恢复训练强度。

今年阅读节奏也很能反映我的人生状态：1–3 月在高压工作里明显低谷；5 月离职后状态回升，之后维持在更稳定、可持续的节奏。全年我读了 31 本（其中 13 本是绘本/漫画）。虚构类里最打动我的是《命运》；非虚构里，对我影响最大的是 The Artist’s Way，因为它不是“懂了就算”，而是逼我用 Morning Pages 和每周实践把改变落到日常。

2026 年我不再追求数量，而更想建立“坐标系”：围绕设计、健康、投资、产品与增长做主题式阅读；减少有声书比例；保留一批值得反复重读的“坐标书”。这段阅读复盘放进今年的年度回顾里，其实和我的主线一致：很多东西都在从“外包难度”回到“亲自训练”，从追效率回到建系统。

高光与低谷

2025 我最珍惜的高光

如果只挑最有代表性的几类：

• 我完成了职业结构的转型，证明不当员工也可以体面生存。

• 我把内容系统变得更稳定，播客尤其实现了商业化突破。

• 我开始认真对待健康，找到更可持续的节奏。

• 我在家庭与关系的压力事件中成长，变得更能承受复杂。

• 我依然保留了玩游戏、看电影、旅行、户外的能力，这说明我没有把自己活成只有工作的人。

独自一人在电影院看电影，是这一年最超现实的一次体验。

2025 我最难的低谷

低谷主要集中在三类：

• 家庭变故带来的冲突、无力感与情绪波动。

• 上半年身体状态和意志力的整体下滑。

• 内容与社交平台对注意力的侵蚀，让我更难进入深度专注。

这些低谷没有“戏剧性反转”，但它们逼着我承认：中年的难，不是某个点的失败，而是长期多线程压力的叠加。

父亲生病，我两次中断工作回国

结语：2025 的本质，是我成为“一人公司”

我越来越确信：2025 年不是“我做了多少事”，而是“我换了什么系统”。

我不再只是一个自由职业者，我更像一家 One-Person Business：有底盘收入、有增长曲线、有高杠杆试验，也有更清晰的价值主张。

2026 年我不想追求更快，我想追求更稳、更清醒、更可复利。把健康放在更高优先级，把关系做得更深，把内容做得更像资产，把产品做得更像长期实验室。

世界会继续混乱，平台会继续变化，市场会继续嘲讽努力的人。但只要我的系统在升级，我就不怕短期波动。

然后是各种这一年，对我来说很重要的瞬间：

每年整理一份年度读书回顾，这个习惯我已经坚持十多年了。

最初是因为十多年前做播客，我发现"以输出倒逼输入"是自我提升最快的方式。从那时起，我每年的阅读量都保持在十几本以上。后来还给自己立过每年 50 本的 Flag，甚至为此写过一本关于高效阅读的书（虽然销量惨不忍睹，哈哈）。

站在 2025 年的岁末回望，今年的阅读体验与往年有些不同，也带给我不少新的思考。

偷懒的"外骨骼"：关于阅读效率的反思

今年的阅读大部分集中在中文书。现在的翻译软件太方便了，很多英文书一键就能转成中文。

但我发现，这种"偷懒"是有代价的。用中文阅读英文原著，就像是带着"机械外骨骼"去运动----虽然走得快，但对自身肌肉能力的锻炼非常有限。2026 年，我决定回归纯英文阅读。 哪怕速度慢一点也没关系，好在我现在已经过了读一小会英文就觉得累的阶段。

节奏的起伏：从高压打工到离职重启

看了一下全年的阅读状态，1-3 月是低谷期，每月仅有两本。当时我正被高强度的工作压得喘不过气，能坚持阅读已属不易。

有意思的是，那段时间我读的大多是减压绘本。比如《我很好，只是有点丧》，听名字你就知道它的底色，但非常推荐给同样处于高压状态的"打工族"。

5 月份是我离职后的第一个月，心态放松后，一口气读了 5 本。之后的日子，基本维持在每月 2-3 本的节奏，状态匀速且自在。

年度书单：18 本文字书里的心头好

2025 年我一共读了 31 本书，其中 13 本是绘本与漫画。在剩下的 18 本文字书中，虚构类仅有 3 本。

• 虚构类唯一推荐：蔡崇达《命运》

我专门为它做了一期节目。这本书让人笑着、哭着看完，在感叹生命无常与悲伤的同时，更能感受到人的坚韧与乐观。

• 非虚构类：跨界的精神食粮

我的非虚构阅读比较"杂"，集中在专业设计（如《Refactoring UI》）、投资理财（如《随机漫步的傻瓜》）、健康以及个人生产力（如《100 Million Dollar Offers/Leads》、正在读的《Slow Productivity》）。

如果只能推荐一本年度非虚构作品，我选 Julia Cameron 的 The Artist's Way（《艺术家之道》）。

这本书非常奇妙。几年前读它我觉得像"神棍"在喃喃自语，但今年我决定带着 "Skin in the game"（切身入局）的态度去实践。当你真正按照书里的建议每周去操作、每天坚持写 Morning Pages（晨间笔记）时，改变就发生了。它对我的灵性影响之大，不亚于多年前初读 GTD 或《牧羊少年奇幻之旅》时的震撼。

2026 展望：确立坐标，放弃数量焦虑

回顾全年的阅读路径，我发现自己的选择无意中集中在：专业设计、健康、投资、产品运营、个人生产力这几个主题。为了在 2026 年获得更明显的提升，我计划做以下调整：

1. 重拾"主题研究"模式： 现在用微信读书很容易被算法推荐干扰。我怀念刚入行时，先定大方向、做 Research、找经典书目，然后一本本攻克的"硬核"状态。

2. 拓宽阅读类型： 继续挖掘绘本与视觉类读物的价值。比如法国漫画家莫比乌斯的作品，每一部都是艺术品，值得深入探索。

3. 精简阅读方式： 进一步缩减有声书的比例。有声书虽快，但像"快餐"，很难留下深刻印记且不便做笔记。

4. 寻找"坐标书"： 我不再执着于阅读数量。有些书是人生的"坐标"，值得每隔一两年就拿出来重读、汲取养分。比如斯多噶学派的相关作品，就属于我会反复回归的固定坐标。

你想好 2026 年要为自己建立哪些"阅读坐标"了吗？欢迎在评论区和我交流你的书单。

下面是我在 2025 年阅读的所有书目：

我很好，只是有点丧
控糖革命
100天后会死的鳄鱼君
真有意思Interesting
A Room of One’s Own
School Days: Cartoons from the New Yorker
How to Draw Cartoons
世界杂货店
Overheard
The Artist's Way
The New Yorker Book of New York Cartoons
The New Yorker Book of True Love Cartoons
Nanjing: The Burning City
Refactoring UI
我减掉了五十斤！
为什么你攒不下钱
$100M Offers: How To Make Offers So Good People Feel Stupid Saying No
投资第1课
锻炼
长安的荔枝
$100M Leads: How to Get Strangers To Want To Buy Your Stuff
命运
克苏鲁的哦唤（漫画）
投资最重要的事
疯狂山脉（漫画）
魔犬
随机漫步的傻瓜
小而美：持续盈利的经营法则
认知觉醒
4点起床
Slow Productivity: The Lost Art of Accomplishment Without Burnout

亲历者视角：当AI Mode上线的那一刻

黄莘是这次 Google I/O 上 AI Mode 项目的团队成员之一。不是旁观者，是"亲妈"。

我问他看到自己做的东西被放上发布会是什么感觉。他说了一句很实在的话：

"其实是没想到的，真的没想到它会上线得这么快。我们还在'内部调试'的心态，突然它就被端上台面了。"

他说最震撼的是那个转折----从"内部测试"到"全世界看到"，其实周期很短。他还提到团队里很多人其实已经做了好几轮的AI迭代，根基打得牢，这次是积累到一定程度，才有了爆发。

AI Mode 是"革自己命"的操作？

我有感而发地说，Google 这次真的有点像"拿自己现金流开刀"----搜索一直是赚钱机器，现在居然用 AI 来替代传统搜索模式？

黄莘说这正是他最佩服的一点：

"这不是说我们产品不赚钱了才换，而是主动从最稳的地方下手。哪怕这条路风险最大，也要走。"

我们在交流时都有一个共识：用户的习惯已经变了，大家开始习惯在ChatGPT这类工具里提问，而不是"打开Google、打关键字"。Google当然不可能看不见这个趋势。

"我们是做技术的，但也看得很清楚：搜索的入口正在被重构。"

SEO 还活着吗？对运营者意味着什么？

"那做内容运营的呢？尤其那些靠SEO活着的中小企业怎么办？"

黄莘的回答：

"从机制上讲，内容依然重要，只是展现方式变了。以往是靠关键词排名，现在可能是通过结构化信息、AI理解能力、语义对齐来判断优质。"

他还提醒一点----不是"SEO死了"，而是"SEO规则变了"。

"原来是讨好搜索引擎，现在可能是要'喂养'AI。"

被取代？还是升级？职业的"硬"与"软"

话题很快转到了：那普通打工人该怎么办？

黄莘说得很坦率：

"如果你的价值是'执行力强'、'重复快'，那AI很可能会超越你。但如果你的优势是协调人、看趋势、做判断，这些AI还做不到。"

我们也聊到：代码可以被自动生成，图可以被一键生成，但"为什么做这件事、要达到什么效果"----这个问题，AI回答不了。

黄莘特别提到两个概念："组合复利（compound）和持续性（consistency）"。他说：

"Google内部很多成功的项目，不是突然蹦出来的，而是十年磨一剑。一点点地叠加，才有今天AI Mode的发布。"

Consistency + Compound，就是他们的打法。

从设计师的角度：手机，成了新瓶颈？

我作为一名前移动端产品设计师，看这场发布会前半部分有种"不适感"：

展示的AI体验再好，所有的场景里，人们还是得举着个手机照来照去。我跟黄莘说：

"感觉手机已经成了AI体验的物理瓶颈。"

黄莘很认同。他说现在AI已经能听能看能说，但硬件没跟上，交互方式跟不上用户的节奏。我们都提到了那副"眼镜"----新一代Google Glass，可能才是更理想的AI入口。

最喜欢的产品是哪一个？

我问黄莘："这次发布会那么多炸裂产品，你自己最喜欢哪个？"

他没怎么犹豫：

"实时翻译的那个眼镜。还有那个可以生成全3D实时连线视频的工具，太超前了，也很合适海外生活，与亲人物理上距离很远的我们。"

他说，作为做AI的人，他最激动的不是"能做出什么效果"，而是看到用户真的用上了，"不再是实验室里的炫技"。

但我们也有点担心

不是一场盲目兴奋的对谈。我们聊到了很多现实的困境，比如：

• 华人高管的缺席：黄莘提到，今年几乎没有华人出现在发布会的舞台上。虽然Google内部华人很多，但在"代表形象"这块，还需要时间。

• 信息滥用的风险：我提到，现在很多AI图像、视频都真假难辨。黄莘说Google已经在推"内容标记技术"，未来所有AI生成内容都会有专属水印。但这条路依然长。

最后一点点"科幻忧虑"

我作为科幻爱好者，最后抛了一个问题：

"你有没有觉得，这些AI工具，未来也可能被用在不那么美好的地方？比如战争？"

这个话题没有深入，但我们都意识到：技术的走向，最终是由人决定的。一个能监控山火的卫星系统，也可以变成导弹的眼睛。

科技是中性的，问题是人类怎么用它。

For the context, I’m pretty tech-savvy. I’ve been around social media for years and can spot most scams from a mile away. But this one still got me.

It started with a DM on Twitter. A person named “TorresCampbell8” claimed to be a reporter from TechCrunch, covering AI and tech. He wanted my perspective and asked to schedule a call. That didn’t sound odd. I’ve done similar interviews before, so I checked his profile. It looked legit—he’d been posting or reposting TechCrunch-like articles since last year, and his Twitter account said it was created in 2012. The only tiny red flag was the handle “TorresCampbell8,” but I shrugged it off.

He sent me a Calendly link to book a call via Twitter DM. I clicked. It seemed normal. I got a confirmation email with no Zoom or meeting link, but I figured he’d message one later. Then I went to sleep.

Next morning, I woke up and saw strange comments on one of my Twitter posts—people calling me a scammer. At first, I thought it was just trolls. Then a friend messaged me on WeChat with a screenshot of a tweet from my account pushing a crypto “opportunity.” It even had a contract address. My profile had been changed to say I was the founder of some crypto project. But by the time I checked Twitter, the tweet was gone. Posted overnight while I was asleep, then deleted before I woke up.

I tried to reach out to “Torres,” but he was gone. Blocked me. Ignored my messages. So I dug into Twitter’s settings. I checked “Security and account access” and saw Calendly had permission to read and write tweets. That was it: while I slept, someone likely used that authorization to post a scam tweet.

Looks like they targeted my account because it has a decent following. Scammers posted a “meme coin” link, hoping quick-buck crypto enthusiasts would jump in. And they did. Then the scammer deleted the tweet, so I wouldn’t notice. According to a friend who tracked the contract address, around 100 people fell for it, losing a few thousand dollars in total. Awful.

Everyone got hurt here. I’m a victim. The people who bought that fake coin are victims. Even the media outlet’s reputation got dragged into this. All because these scammers keep evolving.

Then I did a quick search and found a post from a real TechCrunch reporter - Mary(@bayareawriter) talking about this exact scam. That’s where I spotted the same username: TorresCampbell8. Damn.

Here’s what I learned:
• Keep two-step authentication turned on, always.
• Update your passwords often.
• Be careful about app authorizations. Revoke anything you don’t absolutely need.

I’m going through all my accounts, extensions, apps - tightening everything. Stay cautious. If it happened to me, it can happen to anyone.

That’s my story. Stay safe. And always trust your instincts if something feels off.

睡梦中的推特骗局：我被冒牌记者套路了

我刚刚才从一次诈骗中脱身。损失不大，但整个过程太离奇了。我必须分享这个经历，让大家有个防范。

我平时很熟悉网络，用社交媒体也很多年了，自以为能认出各种骗局。但这次还是中招了。

事情是从一个推特私信开始的。一个叫 “TorresCampbell8” 的人，自称是 TechCrunch 的记者，说他在做跟 AI 和科技相关的报道，想找我聊聊。听上去没什么问题。我以前也有接受过类似的采访请求，于是去他资料页看了看。他似乎从去年开始发或转一些看似像 TechCrunch 的文章，账号显示是 2012 年创建的。唯一让我稍微迟疑的是那个 “8” 的尾缀，但我没多想。

他发来一个 Calendly 链接让我约时间。我点开链接，流程看起来很正常，还收到了预定成功的确认邮件。只不过上面没有 Zoom 或其它会议连结，我想也许他会稍后再发。然后我就去睡觉了。

第二天早上醒来，发现我推特底下出现奇怪评论，有人骂我是骗子。一开始我以为又是网络喷子。接着我朋友在微信上发截图给我，说我的账号昨晚发了一条推文，推荐一个所谓的加密项目，还附带了合约地址。我头像和简介都被改了，看起来就像我是什么“创始人”。可等我上推特一看，那条推文已经被删掉。它是在我睡觉时发的，而我还没醒时就被删掉了。

我尝试联系那位 “Torres”，但他已把我拉黑，完全没有回应。于是我进推特的安全设置里翻记录，发现 Calendly 获得了读写我推文的权限。大概就是通过这层授权，对方在我睡着时发了诈骗信息。

估计他们是看中我账号粉丝还算多，就用我的账号发一个“meme coin”的链接，让想快速赚钱的人去买。等交易结束就删文，这样我自己都不会注意到。后来推友追查了那个合约地址，发现大概有上百人上当，损失了好几千美金。真是可怕。

其实大家都是受害者。我本人受到了连累，那些购买假币的人也被骗了，甚至媒体的声誉也被拖下水。这些骗子手段不断进化，叫人防不胜防。

后来我又去搜资料，发现一位真正 TechCrunch 记者 Mary 提过这个骗局。我在她的那篇报道里，又看到了 “TorresCampbell8” 这个熟悉的账号。真是气人。

我从这次经历学到：
• 一定要开两步验证。
• 定期更改密码。
• 对各种应用授权要多留神，能少给就少给。

现在我打算全面排查自己的所有账号、浏览器扩展、授权应用。虽然麻烦，但值当。大家一定要提高警惕。我中招了，你也可能会。

以上就是我的故事。希望你能平安无事，也别忘了凡事多留个心眼。

为什么说2025年是学习英语的最佳时机？

其实，这几年科技进步带来的变化，让我们普通人学习语言的方式发生了巨大改变。尤其是AI技术的崛起，它不仅挑战了传统教育方式，还给每个人带来了机会：用很少的成本，获得一个功能超强的学习助手。无论是纠正语法、发音，还是解答学习中的疑惑，这些AI工具都能随时互动，永远不知疲倦。

对比小时候学英语的场景，现在的便利简直像开了挂。我小时候，为了听英语课，只能用学校发的老式收音机，资源又少又贵，外教更是稀缺得像外星人。偶尔在英语角看见一个老外，所有人全围上去，结果大家都不知道该说什么，只能干听着。而现在，不但学习资源丰富，还能用AI一对一训练口语，随时随地开练，差距真的太大了。

从工具、资讯和科技发展的角度来说，2025年是有史以来学习和运用英语最有利的一年。

学英语：最好的时代，也是最紧迫的时刻

但机会多了，竞争也更激烈了。未来，语言不再是阻碍，而竞争对手将来自全球各地。

科技行业对顶尖人才的争夺已经从"本地化"扩展到全球化。公司更愿意雇佣那些不仅有专业技能，还能用英语无障碍沟通的人。无论你身处哪个国家，如果不会英语，就可能被外包公司、海外竞争者甚至AI所取代。语言的全球化直接决定了个人竞争力的高低。

虽然全球化目前有一些收缩，但从市场角度看，英语相关的市场规模远大于中文市场，不论是行业成熟度、潜在商业机会，都不是一个量级。这也是为什么国内从公司到个人，很多都在考虑出海。

用英语点亮你的"人生地图"

如果你是游戏爱好者，你肯定知道，当进入一个新场景时，周围的一切都是未知的。你需要探索才能了解资源在哪里，机会有哪些，如何才能进一步发展。随着游戏的推进，你会通过解锁地图不断扩大视野，获取更多的信息和资源。

英语，就是你的一个“地图点亮工具”。它能帮你探索工作和生活中的潜在机会，逐步点亮那些未知领域。无论是开拓职业发展，还是发现更多的文化与人际连接，掌握英语让你更有底气去挑战新场景。

我在几年前刚到新西兰时，语言成为了限制自己可能性的一大障碍。但后来经过努力打通后，我的地图就被点亮了：我可以去参加任何活动与别人互动，结识新的朋友和潜在合作伙伴，可以没有什么心理障碍前往任何一个城市工作或是旅行，可以直接与行业人士互动，收获有价值的信息和专业上的认可。这些被点亮的区域，语言能力是必须的基础。

如果你也想点亮自己的人生地图，在海外寻找机会，或是获得优质信息而不是噪音，2025年是一个最好的时机。

2025年学英语，我推荐从这两个工具开始

2025年，我也会分享更多关于如何提升实战英语技能的教程。先来点实用的：为了帮助大家在2025年更高效地学习英语，我推荐两款实用工具：

欧路词典

这是我用了很多年的词汇学习软件。它的学习功能可以让你将自己的生词打造成学习计划，而不是去死记烂背不会用到的GRE之类的生词。通过它，我快速扩充了实用词汇量，非常适合短期内提升。后续我会专门分享使用教程，记得关注我的X账号或订阅我的Newsletter。

Elsa Speak

这是一款性价比超高的英语听说AI训练软件，非常适合国人提升口语和听力能力——这恰恰是大多数人最弱的地方。关于这款软件，我已经分享过很多教程了，大家可以在我X的Highlight贴子里查看。

下载链接（新用户有7天会员体验）：https://bit.ly/ELSAxBEARLIU

优惠链接：https://elsaspeak.com/inf/BearLiu
（目前有50%的年度会员优惠，和1.5折的终身会员优惠，力度非常大）

2025年，抓住科技带来的便利，用最少的时间提升英语能力。机会就在眼前，别让自己输在时间和执行力上！

I just went through the latest trends article from [UX Collective](https://trends.uxdesign.cc/), and honestly, 2024 feels like a year where the UX spotlight dims a bit. After years of being front and center, it seems we’ve reached the end of a big boom.

The industry is pulling back, prioritizing business goals while AI quietly takes over tasks we used to own. It’s not a sudden shift, but it’s definitely changing opportunities–and roles.

This year’s been…different. Designers aren’t just designing anymore. We’re being asked to deliver more–sitting through meetings to align with business goals, while still focusing on customer needs.

I’ve felt my own creativity take a hit. Maybe you have too? That’s okay. Change is messy, and adapting takes energy.

So, where do we go from here? 2025 is about choosing a direction–or two. You don’t have to stick with one forever, but leaning into one or two can really help you grow. Here are the options:

🗺️ Path 1: Shift from Screen Designer to Strategy Designer

Designers who “get” business goals are becoming invaluable. It’s not just about making things look good–it’s about solving real problems. This path is about stepping up as a strategic partner, not just a pixel pusher. Learn to use data to back up your designs, understand revenue impact, and speak the language of leadership. If you can connect design to strategy, you’ll lead the conversation instead of following it.

🚀 Path 2: Build Faster, Ship Smarter

The design process is evolving, and speed is key. Products don’t have to take months to develop, but they do need to work. With tools like Framer, AI, and other no-code solutions, we can design and ship efficiently. This path is about being effective–prototyping, testing, and releasing without sacrificing quality. It’s about delivering value, fast.

🎨 Path 3: Perfect Your Craft

Sometimes, it’s not about trends–it’s about being so good at what you do that no one can ignore you. Sharpening your skills in prototyping, UI design, or research never goes out of style. This is where you double down on details, ensuring your work is polished and convincing. That’s why we love design, right? It’s not just a job–it’s our craft. That’s what makes it all worth it.

The beauty of these paths? You can mix and match, or shift as your career evolves. But leaning into one or two at a time gives you focus and helps you stand out.

What stays constant? The basics: understanding people, staying resilient, and keeping a growth mindset. These fundamentals never go out of style, no matter how much the industry shifts.

So, what’s your next move? Let’s make 2025 a year of progress–even if it looks a little different than we’re used to.

西游母题与全球共鸣

《黑神话：悟空》取材自《西游记》，这个母题早已深深植根于中国文化，就像西方的很多故事可以追溯到希腊神话或圣经。《西游记》涉及成长、责任、英雄之旅等主题，而游戏中最引人注意的是“个体对抗系统”的主题。这让我联想到《星球大战》、《赛博朋克》和《黑客帝国》这些作品，尽管背景不同，但核心都是关于个人如何应对庞大的系统。这个主题具备极强的普世性，因此吸引了中外玩家。

在游戏里，孙悟空代表着直接反抗系统的“朋克”精神，而“天命人计划”则像是袁守诚和弥勒这些角色通过更加迂回的方式寻找系统漏洞。这两种方式的对比，像极了朋克和黑客的反抗风格。

系统性压迫与个体选择

游戏中的“系统性压迫”这一主题让我联想到我之前读的《万历十五年》。在明朝这样庞大的体系中，内部的精英们都在尝试解决系统问题，但无一例外地失败了。《黑神话悟空》游戏中的人物也是如此，他们面对系统有各自不同的选择。孙悟空选择直接对抗，杨戬选择隐居避世，而弥勒和袁守诚则更像一个平衡者，试图削弱系统的力量。

有的人在系统中迷失，比如黑熊精和自杀的第一代狼妖；也有像黄眉那样试图利用系统攫取权力的利己主义者。或者是在大时代下，人的爱恨纠缠，比如亢金龙、紫蛛儿、四妹。这些角色的选择编织成了游戏的故事主线，也是《黑神话：悟空》让我着迷的地方。

细数印象深刻的章节

游戏的第二、三、四章给我留下了最深的印象。虽然第五章也不错，但第六章明显赶工了，而第一章感觉更像是热身。

• 第一章 的主题是“贪婪”，改编自原作中金池长老惦记唐僧袈裟的故事。这个故事虽然简单，但它的穿透力依旧很强，至今仍然能引起共鸣。

• 第二章 是游戏中最让我惊艳的部分。灵吉菩萨因一己之怒毁掉了一个国家，之后又有所悔悟，帮助天命人解决自己造成的混乱。佛与魔、善与恶的界限变得模糊，而人性在其中挣扎，尤其是虎先锋一家和王子三兄弟的故事线，表现得尤为强烈。

• 第三章 让我联想到《周处除三害》的故事。表面上看，黄眉的小西天似乎是一片佛光圣地，但深入后发现，这里其实是彻头彻尾的邪教。黄眉本人则像个邪教教主，表面光鲜，但内里邪恶。揭开伪装后，那种道貌岸然的邪门气氛扑面而来。很惊艳的是第二章结束的动画，在这一章还有延续。

• 第四章 讲的是“爱而不得”的故事。这个主题线索相对单薄，一夜之情却追忆终生，这种情节类似《一个陌生女人的来信》中的叙事。虽然爱情并不是这部游戏的主线，但四妹“把嫁妆都给你，只是想去看看外面的世界”，被收为丹药真是让人意难平啊。百眼魔君作为天庭的代理人，诱骗妖魔修炼，最终把他们炼成丹药的设定让我印象深刻。靡道人是个典型的悲剧人物，原本是个降妖的少年，却被迫与妖魔共生，最终彻底投入这个系统，而他努力的终点，也只是成为天庭的丹药原料。站在上帝视角的玩家早已知道他的命运，但这一设定依然让人感到同情。

• 第五章 的故事风格像HBO的家庭剧，有点像《黑道家族》或《绝命毒师》。牛魔王是一个典型的中年危机的代表人物，背叛了兄弟情谊，面对一心想复仇的儿子却无力应对。夜叉王的角色也让我印象深刻，主要是因为我在和他战斗时被虐得很惨。

影神图与双线叙事的巧妙设计

游戏中，影神图与主线剧情的双线叙事是我认为最亮点的设计之一。游戏的高难度让你在与BOSS苦战时不禁对每个角色背后的故事产生好奇。比如，我在被黄风大圣虐了无数次之后，就很想去了解了他和灵吉菩萨之间的恩怨。虽然过场动画会交代一些情节，但影神图采用类似小说POV的切换视角叙事，让故事的复杂性和深度得到了极大的放大。

一开始，二郎神给人的印象是天庭的鹰犬，但随着剧情推进，你会发现他背后也有自己的挣扎。再然后，你会从影神图发现，连天兵和天将也只是天庭打工人，困在自己的苦逼循环中。影神图的设计让每个角色的命运交织在一起，凸显了命运的残酷和人与妖、神、佛之间的复杂关系。

玩了一个多月，七十多个小时的游戏体验让我感慨良多。今后提起西游，除了经典的《大话西游》、《悟空传》、86版《西游记》，《黑神话：悟空》也必将成为其中的代表作之一。期待后续的DLC能填补一些故事上的空白，比如四妹的命运、二郎神的故事等等。

随意杂感，欢迎讨论：）