理论上，一个平台包揽文本内容的创作、分发和消费应该会很高效，就像早期的 Twitter。但这种模式存在着根本性的弊端：不可控性。这种不可控体现在多个方面：

• 产品不可控： 比如你可能需要长文写作功能，但平台要么不支持，要么将其作为付费功能；你希望内容列表以列表形式展示，但平台只提供 Feed 流。
• 体验不可控： 平台可能充斥着广告、强制登录浏览、越来越多不必要的功能，以及泛滥的垃圾账号。
• 内容不可控： 即使内容朴实无华，也可能因不符合社区规则而被移除。或者只是放了一个链接就被降权或关小黑屋。
• 账号不可控： 账号可能在莫名其妙就被限制，甚至封禁。

正因为这些潜在的风险，我对新兴的类 Twitter 平台始终保持警惕。即使它们目前看起来符合你的需求，但这些不可控因素就像悬在头上的达摩克利斯之剑，随时可能落下（Twitter 到 X 的转变就是一个例子）。

既然不能完全依赖于某个平台，那么将创作、分发和消费环节拆解开来，或许是更理想的方案。

文本内容创作：自由与便利的权衡

文本内容创作主要指以文字为主，富媒体为辅的形式，例如写博客、发微博等。在工具选择上，可以考虑以下几种方案：

• 独立博客： 自由度最高，但需要一定的技术能力。
• 付费博客： 在自由度和便利度之间取得平衡。
• 免费博客： 最方便，但自由度也最低。

独立博客：高自由度的选择

对于有编程基础、有文本内容创作需求、追求高度自由的用户，搭建独立博客是一个不错的选择。市面上有很多优秀的开源博客工具可供选择。在托管方面，可以选择 VPS（虚拟专用服务器）或类似 Vercel 这样的 Serverless 平台。

付费博客：平衡之选

如果你想要一个独立的博客主页，希望有一定的可定制性，能够方便地撰写文本内容，但又不想花费太多精力在代码和服务器维护上，那么付费博客工具是理想的选择。以下是一些值得考虑的服务：

• Typlog：小明 的作品，简洁优雅。
• Pika：Good Enough 团队的作品，注重设计和易用性。
• Hey World：37Signals 团队的作品，与 Hey 邮箱深度集成。
• Write.as：已经运营 10 年，提供免费版本，注重隐私和简洁。
• BearBlog：创始人承诺永不关闭、不出现广告、不卖，提供免费版本，界面极简。

免费博客：轻量之选

免费博客的自由度相对较低，但对于只需要简单记录和分享的用户来说，也是一个不错的选择。BearBlog 和 Write.as 都是值得信赖的选择，它们功能有限，界面简洁，但能够满足基本的写作需求。

文本内容分发和消费

现在内容分散在不同的博客平台上，如果想要方便地了解这些内容的更新，逐个访问网页效率太低。如果有一个工具可以将这些内容聚合起来，并在有更新时及时推送，将会非常方便。这样的工具确实存在，例如 NetNewsWire。使用者甚至不需要了解 RSS 的原理，只需将网页地址添加到订阅源即可。如果博客提供了全文输出，用户甚至可以直接在 NetNewsWire 中阅读完整内容。

这听起来很完美，但实际使用中仍然存在一些问题。

RSS 支持的不足

并非所有网站都提供 RSS 支持（如果对 RSS 不熟悉，可以点击此处了解）。例如，X 平台就不提供 RSS 输出。原本这可以通过解析网页内容来解决，但一些大型平台出于数据保护等原因，开始限制匿名访问，例如要求登录后才能查看内容。此外，一些 App 弱化了 Web 功能，将重心放在移动端，也增加了 RSS 获取的难度。

信息发现的局限

我们往往没有足够的时间和精力去主动发现和管理自己感兴趣的内容。如果没有良好的发现机制，就可能错过有价值的信息。这并非 RSS 的职责，而是各个平台推荐系统所擅长的。然而，正是因为意识到信息发现的重要性，我们常常沉迷于无休止的 “刷” 内容，导致 “发现” 本身成为了目的，而忽略了 “发现” 之后的行动。

互动缺失

RSS 只负责抓取最新的内容，不提供互动功能。如果想要给作者留言，需要跳转到对应的网站。但并非所有博客都提供评论功能，即使提供，想要了解作者是否回复，也需要专门访问该网站。这使得互动体验不够便捷。

因此，一旦你决定跳出集创作、分发和消费于一体的平台，就会发现，在内容分发和消费方面，现有的工具支持仍然不够完善。曾经有一款产品能够较好地解决这些问题，那就是 Google Reader（点击此处大致了解 Google Reader）。Google Reader 在 RSS 工具的基础上，支持关注用户、分享 NewsItem 、对 NewsItem 进行评论，同时又足够简洁。这些功能恰好解决了信息源闭塞和互动不足的问题。尽管已经过去了十多年，我仍然认为 Google Reader 是一款非常棒的产品，而目前还没有完美的替代方案。

不知道从什么时候开始，对坐飞机开始有种难以言说的恐惧。害怕被一个钢铁巨鸟带到离地万米的高空，害怕那无法预知的颠簸，更害怕自己对此无能为力。但生活又是充满着不得不飞的时刻，这反而促使我开始了一场逆向思考：假如我不幸在某次飞行中丧生，回顾这一生，是否留有遗憾？

答案是肯定的。太多经典的书籍和影视剧还未来得及细细品味，太多让自己满意的作品还未曾真正诞生，太多互相欣赏的人们还未发展出牢固而深厚的友谊…… 这种「临终回顾」式的思考，出乎意料地有效。最好是在一个安静、不会被打扰，也不会被电子设备干扰的场景下去进行，比如洗澡的时候。

这些答案，宛如散落在沙滩上的贝壳，指引着我窥见自己内心深处的价值观。即使从未系统地思考过「价值观」这个概念，我们也会在潜意识中，对什么事情值得做、什么事情不值得做，拥有一套隐形的价值判断标准，也就是一套隐式的价值观。

将这套隐式的价值观显式化，尤为重要。只有这样，我们才能清晰地认识到自己长久以来的做事标准，是否真的与自己内心深处的期望相符。例如，我一直认为「学习」很重要，但如果我把大部分时间都花在刷短视频上，那么我的行为就与我的「理想价值观」产生了偏差，「学习」或许在「实际价值观」序列中，但可能排在「享乐」之后。

更进一步，我们需要深入挖掘和细化这些价值观。仅仅停留在「读书」、「创作」、「友谊」这些模糊的概念上还是不够。问自己：我想读哪些类型的书？是文学名著，还是历史传记？为什么这些书对我来说有价值？是因为它们能拓展我的视野，还是能给我带来精神上的慰藉？我想在哪个领域进行创作？是写作、绘画，还是编程？「满意」的标准是什么？是得到认可，还是实现自我表达？我期望的友谊是什么样的？是互相支持，还是共同成长？

这些深入的追问与解答，能够帮助我们更清晰地界定个人价值观，并将其转化为可执行的具体行动。 例如，在阳光明媚的春日午后，当许多人选择外出踏青时，你却心甘情愿地坐在咖啡馆一隅敲击代码，因为对你而言，创作的价值超越了踏青的乐趣。 又比如，你选择观看一部制作精良的美剧，而非沉溺于碎片化的短视频，因为你认为美剧所蕴含的艺术价值远高于后者。 当生活中的种种选择与内在价值观紧密相连，而非盲目随波逐流时，我们更容易收获一份由内而外的踏实感与满足感。

值得注意的是，不同的价值观之间往往存在潜在的冲突。 例如，对事业成功的极致追求，可能不可避免地挤压陪伴家人的宝贵时间。 此时，我们需要认真权衡： 在不同价值观之间，究竟哪个对我而言更为重要？ 为了追求某些核心价值观，我愿意舍弃什么？ 又该如何巧妙地平衡不同价值观，以便获得更加幸福与完整的人生体验？ 对价值观进行优先级排序，能够帮助我们在面临人生抉择时，做出更贴合内心真实期望的明智决策。

有了价值观列表和对应的序列，还需要将这些显式化的价值观融入到日常生活中。审视我们的时间分配，看看我们每天/每周/每月花在哪些事情上的时间最多？这些事情是否符合我们的价值观？基于我们的价值观，设定一些长期和短期的目标。例如，如果我认为“学习”很重要，可以设定每周阅读多少小时。在面临选择时，问问自己：这个选择是否符合我的价值观？它会让我更接近我想要成为的人吗？

「定期反思」也不能少，看看行为跟价值观是否保持一致。如果发现偏离了方向，及时进行调整。这注定是一场持续探索与动态调整的旅程，没有放之四海而皆准的绝对答案。 重要的是，在不断地自我反思与成长中，逐步找到最契合自身本性的理想生活方式。

回到最初的恐惧，正是这种对生命短暂的感知，才更加迫切地思考人生的意义。 「以终为始」的核心在于：想象你在生命的终点回顾一生时，希望看到的是什么：做成了哪些事？去过哪些地方？陪伴子女幸福成长？抑或只是安安稳稳地过完这一生？如果上天把你的一生压缩成 10 分钟的短片，播放给来参加你追悼会的人看，你会觉得羞愧还是骄傲？

理想的人生，应该是随时死去，都不留遗憾。

大概半年前，我开始接触 AI 编程助手，例如 Cursor 和 GitHub Copilot。简单试用后，感觉不太顺手，就暂时搁置了。当时我的感受是：

Cursor 的存在感太强了，用起来不太习惯，还是更喜欢 VSCode。

但随着 AIDE 和 AI 编程插件越来越多地出现在视野中，我隐隐意识到这股趋势不可忽视，应该再次尝试。于是开通了 GitHub Copilot 的付费版，开始在一个实际项目中深入使用。

使用一段时间后，我的整体感受是：AI 辅助编程将会是不可逆转的趋势。越早掌握一款得心应手的工具，越早完成与 AI 的磨合，对程序员的个人发展越有益。

我实践的项目是一个基于 Tauri 2 的 Mac App。粗略估计，其中大约一半的代码是由 AI 辅助生成的。例如，编写一个 React 组件来展示 Playlist 下的 Videos，我先是构建了页面的基本结构，然后逐步细化指令，比如为每个 Video 添加序号，设置鼠标悬停 (Hover) 样式等等。这种感觉就像雇佣了一位高效的实习生来协助完成工作。

可能是 GitHub Copilot 的能力有限，或者我的使用技巧还不够成熟，亦或是当前 AI 编程助手普遍的现状，我发现在面对一些需要「跳跃性思维」才能解决的复杂 Bug 时，这些工具能提供的帮助非常有限。比如我曾遇到一个问题：主题切换在开发模式下运行正常，但部署到生产环境并重启应用后就会失效。这个 Bug 有点隐蔽，结果 AI 也如期望那样未能提供有效的解决方案。再比如，如何将 devtools 工具带到生产环境，同时禁用默认的 Cmd+Shift+I 快捷键？AI 给出的方案都不 Work，最终还是翻了下 Tauri 的源码才找到的思路。 目前看来， AI 编程助手更擅长执行指令明确的任务，根据上下文生成代码片段，但在复杂问题分析、根因定位、以及需要创新性解决方案的场景下，仍然需要人类程序员的深度思考和经验判断。如果未来的 AI 通过更高级的算法和更完善的知识库，模拟甚至超越了「跳跃性思维」，这又会是另一个课题，不过目前看来，还不太需要担心。

「信息滞后」也是一个不可忽视的问题（Cursor 在这方面表现稍好）。Copilot 似乎缺乏有效的机制来实时获取和更新最新的技术文档，因此它生成的代码有时会使用过时的 API。在 Tauri 2 项目中这个问题就比较明显，因为 Tauri 2 的 API 与 Tauri 1 相比变化很大。我经常需要在 AI 生成的代码基础上，手动查阅最新的 API 文档并进行替换。这个问题 Cursor 解决得更好一些，但有时也会出现新旧 API 混用的情况。

基于这次 AI 辅助编程的体验，我开始认真思考：AI 辅助编程的崛起究竟意味着什么？它将如何重塑软件开发行业？

程序员这个职业会消失吗？

如果一个没有编程经验的人，通过 AI 辅助编程工具就能开发出像模像样的产品，那么还需要程序员吗？如果对软件产品的要求仅仅停留在「可用」的层面，那么程序员的价值确实会受到挑战。但在实际软件开发过程中，我们不可避免地会遇到难以调试的 Bug，或者需要突破常规的创新思路才能实现的需求。目前的 AI 工具对复杂上下文的理解还不够深入，在处理复杂问题时常常显得力不从心。如果完全放任 AI 自由编程，结果很可能是 Bug 没解决，代码反而变得更混乱，维护性更差。

在注重协作的组织环境中，程序员被 AI 工具淘汰的速度可能会相对放缓。有相关工作经验的同学应该都有体会，在日常工作中，程序员每天的代码产出量其实很有限，相当一部分时间都花费在需求沟通、Bug 修复、梳理遗留代码、编写文档、Oncall、处理依赖冲突、等待编译构建结果等非直接编程相关的工作上。直接将 AI 引入现有复杂项目，一方面可能存在代码泄露的安全风险，另一方面，AI 由于缺乏对遗留代码完整上下文的理解，可能会生成不符合项目规范或非最佳实践的代码，反而增加维护成本。毕竟最终对代码质量和线上问题负责的仍然是人，而不是 AI。如果线上出现重大事故，总不能给 AI 记个 P1 吧。因此，在注重团队协作和代码质量的大型组织中，程序员受 AI 编程工具的直接冲击可能相对较小。但这种状态能维持多久还不好说，当企业看到 AI 带来的生产力提升潜力后，肯定会围绕 AI 进行组织架构和工作流程的效率革新，届时程序员群体必然会受到影响。

AI 编程的崛起，不是程序员的末日，而是一次进化。AI 不会取代所有程序员，但它将深刻地改变程序员的角色和技能要求。

初/中级程序员如何应对日益强大的 AI 编程工具？

首先要有危机意识，拥抱变革。有了危机感，才能激发学习和改变的动力。如果仍然想从事编程行业，那么首要任务是积极学习并掌握一款 AI 编程工具（Copilot 相对轻量，可以作为入门级选择）。要努力做到与 AI 工具默契配合，充分发挥其代码生成和辅助功能，从而显著提升个人生产力，并将节省出来的时间投入到更有价值、更具挑战性的事情上。

接下来，可以认真考虑未来的职业发展方向。如果希望在编程领域持续深耕，可以着重提升高级程序员应具备的核心技能，例如系统设计、复杂业务逻辑分析、问题分解与抽象、疑难 Bug 调试与根因分析、系统性能优化、创新技术方案设计等等。在这个学习和提升的过程中，也可以借助 AI 工具来提高学习效率，例如在阅读学习优秀的开源代码时，可以利用 AI 辅助代码理解，梳理代码逻辑，解答设计思路上的疑问。

如果对产品方向更感兴趣，或者有创业的想法，则可以投入更多时间在产品设计、用户研究、市场分析等方面，利用 AI 工具快速构建 MVP原型，快速验证产品想法，探索商业模式。

AI 编程下的人机协作新范式

可以将 AI 工具使用者与 AI 编程工具之间的关系比作「交响乐团的指挥家与乐团」。程序员如同经验丰富的指挥家，拥有清晰的愿景和目标，负责软件系统的整体架构和模块设计，指导和协调 AI 工具（如同乐团）高效、高质量地完成代码编写（如同乐曲演奏）。AI 工具如同训练有素的乐团，拥有强大的代码生成和辅助能力，但需要指挥家的明确指令和专业引导才能演奏出优美的乐章。

不同的 AI 编程工具都有各自独特的功能和特点，但与它们交互的核心要点是共通的：精细化任务分解和指令设计，以及代码 Review。 在人机协作的新范式下，程序员不仅需要与 AI 工具高效沟通，还需要与团队成员更好地协作，共同利用 AI 提升团队的整体研发效率和代码质量。

半年前我初次尝试 AI 编程助手效果不佳，也是因为没有掌握与 AI 编程工具有效沟通的精髓。可以将这些 AI 工具视为响应迅速、随叫随到的「外包程序员」，每一次代码改动都相当于一次 GitHub 的 Pull Request。要确保每次改动的目标明确具体，代码改动量控制在可审查的范围内。最终目标是代码虽然不是完全由自己编写的，但对代码的整体逻辑和关键细节都非常熟悉，这样即使 AI 无法解决某些深层次的 Bug，自己也能凭借对代码的深入理解，逐步分析和定位问题根源。

小结

AI 辅助编程的崛起既是挑战，也是机遇，基本上是不可逆转的趋势。如果半年前有人这么跟我说，我可能会将信将疑，但现在对此更加确信。即使只是体验了入门级的 Copilot，也已经真切感受到了它带来的效率提升。尽早找到适合自己的 AI 编程工具，积极完成与 AI 的磨合过程，然后将效率提升所节省出的宝贵时间，投入到扩展和丰富自身技能库上，不断学习和掌握更高级的技能，让自己成为拥抱 AI 浪潮的弄潮儿，而不是被技术浪潮无情淘汰的落伍者。

媳妇儿在小红书上种草了长龙航空的随心飞，于是怂恿我一起买了这个服务。然后就开始寻找目的地，本着第一趟就要赚回本的理念，选择了距离杭州近 5000 公里，中国最西部的城市：喀什。

我对这个城市只停留在「听说过」的阶段，对于当地的美食、美景、风土人情、历史典故等毫无概念，但既然媳妇儿选择了这里，就只能陪着一起去了。当时的心情没什么波动，甚至有点排斥，因为一想到要坐那么久的飞机（我对坐飞机这事有较大的心理障碍，确切来说是「高空」，所以摩天轮也不是我的菜），还要离开熟悉的地方一段时间，就会怀疑这么折腾到底值不值。

结果是，非常值。我跟媳妇儿都已年近 40，没有孩子，平时也都是各忙各的，交集主要是生活上的一些事。当缺少比较强的 hub 来连接彼此时，两人之间的连接感就容易变弱，而旅行是一个很好的可以加强连接、增进友谊的契机。

目的地的选择很重要，最好是双方都不太熟悉的。如果这个地方给两人带来的新奇感程度不一，就不容易有「共振」的体验，而「共同的情绪体验」是亲密关系中很重要的一部分。比如手抓饭，如果都是第一次吃，就能分享这道美食带来的惊艳。还有就是「弱攻略依赖」，也就是不用事先花大力气做好功课，也能有不错的体验，不会有太大的坑。

喀什是个很好的目的地，一方面是这里的美食通常是我们没怎么接触过的，而且确实很不错（印象最深的是石榴，榨成汁后不仅好喝，还营养丰富），另一方面喀什古城很好逛（虽然是淡季，很多店面都关门了，但古城的底蕴还在，在其间溜达还是挺舒适的，尤其是太阳照常上班的日子），还有就是这里的风土人情跟东南沿海差异很大，这种差异也是一个很好的切入点，成为两人茶余饭后的聊天话题。这里的人通常有自己的小买卖，比如开个饭馆、卖当地特产、烤肉等等，有些硬需求常年不变，就会出现从爷爷辈甚至爷爷的爷爷传下来的手艺，比如「爷爷的爷爷的爸爸的囊」、「祖传兄弟凉粉」。

临走的前一天，我们去「爷爷囊」那里，买了四个香菜囊，不远万里（literally），从喀什带到了杭州，算是对这趟旅行的一些回味😂。

去年，看了一本印象颇深的书：北方的空地。这本书讲的是一个叫杨柳松的人，推着一辆自行车（交通工具兼载货工具），历经 77 天，独自穿越羌塘无人区的故事。旅途非常艰险，一点小小的意外就可能导致极严重的后果（比如帐篷的地钉被吹走）。但体验独特，风景绝美。看完后，印象最深的除了他的那份胆识、勇气和乐观外，还有那非常严谨的准备工作，让看起来几乎不可能完成的任务成为可能。

然后我就想到了独立开发者，他们也像杨柳松一样，独自走进羌塘，面对诸多的不确定性和艰困的环境，试图从中找到一条出路。我目前还不是一个合格的独立开发者，思考上肯定会有所欠缺，但还是写下来，作为进入这个领域的前期准备工作吧。

理解独立开发的本质

说到独立开发，很多人的第一反应是「自己做一个产品」。但实际上，它是一种特殊形式的创业。特殊在哪里？你需要在极其有限的资源下（通常是一个人、有限的时间和资金），找到一个可持续的商业模式。

这就像是你决定开一家小饭店。不同的是，你不仅要当老板，还要同时担任设计师、厨师、服务员、采购、营销…所有角色。这听起来很累？确实如此。但这种方式也有独特的优势：决策快、运营成本低、方向调整灵活。

寻找适合的战场

在我观察到的案例中，成功的独立开发者往往都很擅长选择合适的战场。这里的”合适”，不是指最大或最热门的市场，而是要找到：

1. 市场规模适中（足够养活个人/小团队）。
2. 用户需求明确（愿意付费解决问题）。
3. 大公司不感兴趣（或者应对不够灵活）。
4. 技术门槛适中（能做出差异化但又不至于无法实现）。

举几个具体的例子：

沉浸式翻译

沉浸式翻译 是我很喜欢的一款翻译工具，使用几天后，就安利给了周围的朋友。作者 Owen 在一期访谈中提到，他在看王小波的沉默的大多数时，看到书中有提到萧伯纳的芭巴拉少校 很值得一看，然后他就找到了这本书，书中的中英文排版浏览体验给了他很大的惊喜和启发，最终促成了沉浸式翻译这款工具的诞生。

Pinboard

Pinboard 是一个简单、高效的社交书签服务，由 Maciej Ceglowski 创立。Maciej 的初衷是为用户提供一种可靠的方式保存和组织网络链接，专注于简洁和隐私保护：

• 现有的书签服务往往过于复杂或充斥广告，Pinboard 选择了简化功能，提供最基础但最实用的书签管理。
• 目标用户是那些希望高效保存并稍后查找链接的人，尤其是注重隐私的用户。
• 相较于社交化的书签平台，Pinboard 更专注于个人化的链接管理，用户可以自由选择是否分享。
• 通过付费订阅模式保持了平台的独立性和清爽的用户体验。

这两款作品的作者都是独立开发，他们找到了合适的战场，其中很重要的一点就是「做自己产品的第一个用户」。

做自己产品的第一个用户

Paul Graham 在 How to Start a Startup 中有提到：

No matter what kind of startup you start, it will probably be a stretch for you, the founders, to understand what users want. The only kind of software you can build without studying users is the sort for which you are the typical user.

无论你启动什么类型的初创公司，对于创始人来说，理解用户的需求可能都是一个挑战。你唯一可以不研究用户就能构建的软件，就是那种你本身就是典型用户的那种。

Pieter Levels（Nomad List 的创始人）也说过：「最好的产品灵感来自于解决自己的问题」。当你是自己产品的目标用户时，会获得几个关键优势：

1. 对问题的深刻理解

你不需要想象用户的痛点，因为你就是那个每天都在经历这个问题的人，这种第一手经验无比珍贵。

2. 持续的动力

创业路上最重要的不是灵感乍现的那一刻，而是持续的投入。当你在解决自己的问题时，这种动力会更持久。因为即使项目还没有其他用户，你自己就是受益者。

3. 产品方向的把控

很多决策不需要漫长的讨论和市场调研，因为你对目标场景太熟悉了。这种直觉判断虽然不一定完全准确，但往往能抓住重点。

4. 口碑传播的基础

当你真的解决了自己的问题，你会很自然地想要分享给同样有这个问题的人。这种发自内心的推荐很容易引起共鸣。

快速验证，大胆放弃

即使你吃自己的狗粮，结果仍然可能不如意，比如需求提炼不够精确，产品不够惊艳，缺少推广途径等等。NVIDIA CEO 黄仁勋在早年的一次分享中有提到：

If you want to be successful, I would encourage you to develop a tolerance for failure. However, there’s something crucial about failure: if you fail often enough, you might actually become a failure, which is fundamentally different from being successful. So the real question becomes: how do you teach someone to fail, but fail quickly, and change course the moment they recognize a dead end?

The way to approach this is through what we call “intellectual honesty.” This means continuously assessing whether something makes sense, and if it’s the wrong decision, being willing to change your mind.

To achieve this, you have to nurture a tolerance for risk-taking and teach people how to fail—quickly and with minimal cost. Innovation demands a bit of experimentation; experimentation requires exploration, and exploration inevitably involves failure. Without a tolerance for failure, you’d never experiment; without experimentation, you’d never innovate; and without innovation, you’ll never succeed. Otherwise, you’ll just end up being, well… a dweeb.

如果你想成功，我会鼓励你培养对失败的容忍度。然而，关于失败有一个关键点：如果你经常失败，你实际上可能变成一个失败者，这与成功是根本不同的。所以真正的问题变成了：你如何教会一个人快速失败，并在他们意识到死胡同的那一刻改变方向？

解决这个问题的方法是“诚实”。这意味着持续评估某件事是否合理，如果是错误的决定，愿意改变主意。

要实现这一点，你必须培养对冒险的容忍度，并教会人们如何快速且以最小成本失败。创新需要一点实验；实验需要探索，而探索不可避免地会涉及失败。如果没有对失败的容忍度，你就永远不会实验；没有实验，你就永远不会创新；而没有创新，你就永远不会成功。否则，你只会变成，嗯……一个傻瓜。

「创业最大的风险不是失败，而是在一个错误的方向上消耗太久」。这句话对独立开发者尤其重要。

如何做到快速验证？

确定最小验证集

不是最小可用产品(MVP)，而是验证核心假设的最小功能集。比如：

• 如果你假设用户愿意为更好的翻译体验付费，那么先做一个简单的浏览器插件。
• 如果你假设开发者需要某个开发工具，可以先写一个命令行版本。
• 如果你想验证市场需求，甚至可以先用 Notion 页面或者 Excel 表格来模拟（多抓鱼就是从一个微信群和 Excel 开始的）。

设定清晰的指标

在开始前就要明确：什么算成功，什么算失败？例如：

• 首周激活率 > 30%。
• 次月留存率 > 40%。
• 14 天内有 10 个付费用户。

严格控制时间投入

• 第一个版本控制在 1-2 个月内。
• 设定明确的评估节点，比如每两周回顾一次。
• 定期问自己：如果现在不是我在做这个项目，我会建议继续吗？

关于放弃

放弃一个项目往往比坚持更需要勇气。以下是一些值得注意的「放弃信号」：

• 连续三个月没有明显进展。
• 用户反馈总是很礼貌但不热情。
• 每天都在解决技术问题，但产品价值没有提升。
• 开始觉得这个项目是负担而不是机会。

放弃一个项目不等于前期投入都白费了。过程中获得的经验、技能提升、用户洞察等等，这些都是宝贵的资产。

持续构建护城河

独立开发最大的挑战之一是：如何在资源有限的情况下，建立起竞争优势？答案可能是：持续积累。

个人品牌建设

比如 Tony Dinh

• 通过博客分享独立开发经历。
• 在 Twitter 上记录每日进展。
• 定期发布产品更新和思考。
• 参与技术社区讨论。

这些持续的输出帮助他：

• 建立了个人影响力。
• 吸引了种子用户。
• 获得了社区反馈。
• 结识了潜在合作者。

国内的同学可能更加熟悉的 Kevin、Tualatrix、Baye，也都非常注重个人品牌建设。曾经 Baye 和小护士的故事，则是另一段佳话了 😂。

知识资产沉淀

每做一个项目，都要注意积累可复用的资源：

• 技术组件库。
• 设计系统。
• 文档模板。
• 营销材料。
• 用户研究方法。
• 定价策略经验。

这些资产会让你的下一个项目启动更快、质量更高。

用户关系

独立开发者最宝贵的资产之一是忠实用户群体：

• 建立用户社群（Discord、Telegram、微信、小红书等）。
• 维护邮件列表（国外比较常见）。
• 建立产品反馈机制。

这些用户不仅会持续给你建议，还会成为你的产品传播者。

构建能力矩阵

独立开发要求多面手，但这不意味着你要样样精通。可以把能力分为 Essential（核心能力） 和 Plus（增强能力）：

核心能力

开发能力

• 至少精通一个技术栈
• 熟悉常用的开发工具
• 了解基本的系统架构

产品思维

• 需求分析能力
• 用户体验设计
• 产品规划和迭代

设计能力

• 了解设计原则
• 能做出清晰、友好的界面
• 掌握基本的设计工具

增强能力

市场分析

• 竞品研究
• 市场机会判断
• 用户画像描述

市场营销

• 内容营销
• 社群运营
• 增长策略

商业分析

• 基础财务知识
• 定价策略
• 商业模式设计

常见陷阱及应对

在独立开发的路上，有一些常见的陷阱需要警惕：

过度追求完美

表现：

• 总觉得还差一点才能发布。
• 反复修改已经可用的功能。
• 纠结于细节优化。

解决方案：

• 设定明确的发布日期。
• 列出「最小功能集」清单。
• 告诉自己：发布后还可以继续改进。

技术栈选择困难症

表现：

• 总觉得现有技术栈不够好。
• 被新技术吸引注意力。
• 花太多时间在技术选型上。

解决方案：

• 优先选择你最熟悉的技术栈。
• 把新技术放在非核心功能上尝试。
• 告诉自己：技术只是工具，不是目的。

闭门造车

表现：

• 很少与用户交流。
• 凭感觉判断需求。
• 害怕展示不完善的产品。

解决方案：

• 建立持续的用户反馈渠道。
• 加入相关的社群。
• 勇于展示早期版本。

忽视商业模式

表现：

• 过于专注技术实现。
• 没有清晰的变现计划。
• 对定价犹豫不决。

解决方案：

• 早期就考虑商业模式。
• 研究竞品的定价策略。
• 大胆测试不同的定价方案。

结语

独立开发是一条充满挑战的道路，但也充满机遇和乐趣。关键是要：

• 选择合适的战场。
• 持续构建护城河。
• 持续学习。
• 做好风险控制。

这道题，没有标准答案，每个人有适合自己的节奏。重要的是在实践中不断学习和调整，直到找到那个真正适合你的机会。

独立开发不是终点，而是一种生活方式的选择。在这条路上，希望你也能找到属于自己的节奏和乐趣。

附注

独立开发产品类型维度对比表

产品类型	维护压力	技术复杂度	运营需求	美感要求	特点说明
实时通讯类	高	高	高	中	- 需要保证服务稳定性 - 需要处理大量并发 - 用户体验要求高
在线协作工具	高	高	中	中	- 需要确保数据同步 - 需要处理多人协作场景 - 稳定性要求高
支付相关服务	高	高	中	低	- 安全性要求极高 - 需要专业资质 - 责任风险大
SaaS工具	中	中	中	中	- 需要定期更新维护 - 需要处理客户支持 - 相对稳定的收入
社区类产品	中	中	高	中	- 需要持续运营维护 - 内容管理要求高 - 用户增长是关键
单机游戏	低	中~高	低	高	- 开发周期较长 - 发布后维护较少 - 营销很重要
效率工具	低	低~中	低	高	- 功能性为主 - 用户体验重要 - 竞品较多
开发者工具	低	高	低	低	- 技术门槛高 - 用户群体专业 - 变现相对容易
设计类工具	低	中	低	高	- 视觉体验重要 - 专业用户群体 - 需要持续更新
内容平台	中	中	高	中	- 内容运营重要 - 用户留存是关键 - 需要持续产出
生活工具类	低	低	低	高	- 界面设计重要 - 功能相对简单 - 用户基数大
数据分析工具	中	高	中	中	- 专业性要求高 - 准确性要求高 - 需要持续优化
教育类应用	中	中	高	中	- 内容质量重要 - 需要持续更新 - 用户服务要求高
自动化工具	低	高	低	低	- 技术门槛高 - 稳定性要求高 - 用户群体专业
主题/模板	低	低	低	高	- 设计质量重要 - 更新频率低 - 竞争激烈

对于希望进入到独立开发领域的同学，建议从工具类型入手，因为运营成本相对较低，用户需求明确，技术门槛适中，更容易找到自己的节奏。

修改记录

• 2024/11/13: 添加「独立开发产品类型维度对比表」，帮助更好地选择适合自己的产品类型。

想象有一个金融委员会会议，讨论三点议程，要点如下：

1. 耗资 1000 万英镑建设核电站的提案
2. 价值 350 英镑的自行车棚提案
3. 年度咖啡预算 21 英镑的提案

会发生什么？委员会最终在很短的时间内就通过了核电站提案。它太高级了，谁都无法真正深入研究细节，而且大多数成员对这个主题了解不多。即使有人了解，解释起来也非常困难。

讨论很快就转移到自行车棚上。在这个议题上，委员会成员可以更轻松地表达自己的意见。他们都知道什么是自行车棚以及它是什么样子。一些成员开始就屋顶的最佳材料展开激烈辩论，权衡可能的选择。他们讨论自行车棚的时间远远长于讨论发电厂的时间。

最后，委员会讨论第三项：咖啡预算。突然间，每个人都是专家。他们都了解咖啡，并且对其成本和价值有强烈的认识。在人们意识到发生了什么之前，他们讨论 21 英镑咖啡预算的时间比发电厂和自行车棚加起来的时间还要长！最后，委员会没有时间了，决定再次开会来完成分析。每个人离开时都感到满意，为谈话做出了贡献。

这个故事是帕金森在 50 年代提出来的，被称为「帕金森琐事定律」或「自行车棚效应」。其要点是：话题越简单，发表意见的人越多，讨论也越深入。而对超出我们能力范围的事，例如核电站，甚至不会尝试表达意见。总结一句：人们更愿花时间在简单的小事上，而在重大复杂的问题前草草了事。

系统一与系统二：我们的大脑喜欢简单任务

《思考，快与慢》一书中的「系统一」和「系统二」可以很好地解释这种心理。系统一是我们大脑中的自动模式，擅长快速、直觉反应，不费脑力。它是帮我们处理琐事的好帮手，却不适合深思熟虑。相比之下，系统二则负责理性思考和逻辑分析，但它启动起来费时费力，不是我们“下意识”就会用的。

自行车棚的问题之所以那么吸引人，是因为它简单，人人都有话说，系统一完全能胜任。但真正重大的项目，比如一栋楼的整体预算、结构安全这些问题，太复杂，系统一根本应付不来。于是，大脑下意识地选择“避重就轻”，将精力转移到自行车棚这类小事上。小事有一种假装参与感的安慰——我们觉得自己有所贡献了，哪怕实际作用微乎其微。

为什么「自行车棚」让我们痴迷？

究其原因，是因为自行车棚代表了一种心理上的“安全区”。在会议中讨论一个自行车棚的建设方式、颜色，参与者可以迅速提供意见，获得一种控制感和掌控力。这种参与感有一种立即的满足，它让人觉得：我可以主导这个细节，我的意见是重要的。反观那些需要系统二深度分析的复杂问题，听上去就容易让人感到无力，甚至恐惧。大脑自然会倾向于选择让人舒服、轻松的领域，而避开那些让人头疼的大事。

与此同时，自行车棚效应也揭示了我们的“从众心理”。在一个群体中，小事讨论容易形成共识——你说黑色好，我觉得灰色也不错，很快大家就能找到一个共同点，觉得“和谐”。但一旦讨论涉及到真正影响全局的重大决策，必然会产生争议，往往谁都不想打破这种“和谐”。于是，为了避免可能出现的冲突和不适，大家更乐于在细枝末节上“和和气气”地交流，而忽视大局。

我们的 App 和社交媒体如何放大了这种效应？

不仅是在会议中，我们日常生活中的许多行为模式也在强化自行车棚效应。现代 App、社交媒体、游戏，甚至新闻都在迎合我们的系统一。它们通过即时反馈、情绪化内容和算法推荐，让我们沉迷于短期的、简单的信息。刷社交网络时，我们倾向于关注那些轻松、引人注目的内容，而对真正重要的信息或深度思考敬而远之。久而久之，我们的大脑适应了这种“快餐式消费”，开始习惯性地规避复杂问题，随之而来的，就是对小事的无限纠结和讨论。

在这种环境下，自行车棚效应被放大了。面对短暂的成就感、娱乐化的内容，我们的大脑越来越少地启用系统二，更难在重要的问题上花费精力。许多讨论度极高的热点话题，其实本质上只是一些无关痛痒的小事，但我们却乐此不疲地卷入讨论，忽视了那些真正值得关注的议题。

强化系统二，弱化系统一

为了减少对系统一的依赖，我们可以采取一些强化系统二、弱化系统一的行为和习惯，比如：

• 冥想和正念练习：通过冥想训练自己对当下的关注，有助于减少自动化的反应，增强系统二的控制力。
• 刻意练习批判性思维：在日常生活中，刻意对各种信息进行分析和质疑，以增强系统二的理性思考能力。
• 设置延迟决策机制：在面对需要快速做出的决定时，刻意设置一个短暂的等待时间，让系统二有时间介入，避免系统一的冲动反应。比如要去拿手机时，等 3 秒，看是真的需要，还是一个下意识的行为。
• 学习新技能：学习需要逻辑和分析的新技能，比如编程、复杂数学问题等，可以有效锻炼系统二的能力，提升对复杂问题的处理效率。

如何逆向利用自行车棚效应，让它服务于我们的目标？

既然自行车棚效应源于人们对小事的关注，我们不妨反其道而行之，将其转化为一种积极的工具。毕竟，如果我们可以利用“对小事的投入”来完成一些困难的、有价值的事情，那这个效应就能为我们所用。

1. 将大任务拆解成“小自行车棚”：面对复杂的任务，我们可以把它分解成多个小目标。让自己每次只专注于一个具体的小事，这样既能启动系统一，增强完成感，同时又让系统二有机会在需要时参与进来，理性分析。

2. 利用小成就感，积累完成动力：当我们完成了一个个“小自行车棚”任务时，系统一的“即时成就感”会帮我们维持动力，而系统二则可以在长远规划上给予支持。比如，学习一项新技能时，每天完成一点小目标，逐渐构建整个知识框架，最终达成难以企及的成就。

3. 把目光聚焦在核心小事上：我们可以让自行车棚效应集中在那些重要任务的小步骤上，而不是无关紧要的琐事上。这样可以在核心问题上逐步前进，确保每一步都为最终目标服务。

化繁为简，以小步成大成

人们总是倾向于轻松、简单的选择，这种倾向并非一无是处。它给我们提供了积极的参与感、即时满足和短期成就感，只是我们需要学会如何合理利用这种心理机制。通过有意识地把注意力从琐事转移到更具价值的小目标上，最终可以从“纠结小事”变为“步步为营”，以小步成大成。

下次你在纠结一件小事或对网上的争论上头时，不妨停下来问问自己：“这真的重要吗？” 或许，通过把“自行车棚效应”转化为有利的工具，你会发现自己更愿意投入到那些真正重要的事物中，最终让生活和工作变得更加充实有意义。

最后，还有一个小妙招，是很多年前我不知道在哪里遇到，一直留着的一段话：

朋友们，我的一点切身经验，，如果你觉得某个任务让你特别焦虑，压得你喘不过气来，那么最好的排解方法就是直接去做这事，什么都别管，就是使劲做，努力地推进其进度，这棘手的事情在进度上每发展一点，你的焦虑就会少一分，同时你的焦虑越少，推进的速度也就越快，只要咬紧牙关，不停地推进，总会有解脱的那一天，而且你每完成一个棘手的任务，你或多或少都会比之前牛逼强大那么一点，这件苦差事总是会改变你一些。

今天早上（严格说来是近中午了，醒的晚😂）在洗澡的时候，忽然觉得应该将「每天早上洗澡」这件事纳入日程中，因为这是难得的一段不会被打扰，不会使用电子设备，完全属于自己的时间。可以用这段时间做一些微小但又重要的事。

反思昨天的表现

因为是发生不久的事，所以印象也还算深刻，可以回顾昨天哪些事做的比较好，哪些表现跟理想中的自己还有差距，应该如何改进。还可以回顾下昨天学到的一些知识点。

定期 Review 是一件很重要的事，因为生活中的很多决策（包括不决策，比如保持现状）是非理性的，可能是为了规避一些风险，或与身边的人保持同步，或满足一些人的诉求。定期 Review 在做的事，自己的状态，对于实现个人的最优解很有帮助。

‘If today were the last day of my life, would I want to do what I am about to do today?’ If the Answer is ‘no’ for too many days in a row, I know I need to change something.

— You know who

具像化目标

为什么这个目标对你来说很重要，达成路径是否有优化空间，想象实现这个目标后自己的状态，细节越丰富越好。这块我没有成功的经历，但直觉是可行的。Scott Adams 也是通过 Affirmation 取得了很多他自己都认为很不可思议的成就。

The idea behind affirmations is that you simply write down your goals 15 times a day and somehow, as if by magic, coincidences start to build until you achieve your objective against all odds.

过一遍今天要做的事

今天要做哪些事，可以先在脑海里过一遍，每件事大概会占用多长时间，心里也有个数。还可以想下为啥要做这些事，是否贴合自己的目标。

冥想

「冥想」在电子设备和算法统治的当下更具有重要性。它的原理不复杂，实践成本低（找个没人打扰的地方待 10 分钟），但因为正反馈不明显，所以很难长期坚持下来。洗澡时不妨也一并做了，时间可以短一些，比如 5 分钟。

---

上面这些小事，虽然不难，但也很难坚持下去，因为它们的优先级太低了，还没有 deadline，更没有手机好玩，这种状态用计算机术语描述就是 Starvation：一个低优进程（比如备份），总是被高优进程排挤，结果就是一直没得到运行的机会，一直处于饥饿状态。而洗澡为这些低优进程提供了运行条件，让它们不再挨饿。

This site previously used Zola as its blog engine (you can read here for more details), along with:

• Alpine.js: A lightweight Vue.js alternative.
• Tailwind CSS: A utility-first CSS framework.
• PocketBase: An open-source realtime backend in one file.
• Deno: A modern runtime for JavaScript and TypeScript.

This architecture had been running for about 3 years. Mostly satisfied. Zola build fast, its functionality was basically adequate, with Deno, I could write API for frontend page. Using Alpine.js and Tailwind CSS, I could create frontend pages quickly.

However, it wasn’t perfect, mainly for these reasons:

• My go-to frontend library is React, but it’s hard to combine React and Zola in an elegant way.
• I want to handle HTTP server, Static Site Generation(SSG), and React in a unified way.
• This tech stack lacked some features I wanted, such as Server Side Rendering and using Shiki as a code highlighter.

After some investigation, I decided on Astro as my new site engine.

• It has all the features I wanted in a meta-framework.
• I’ve seen more and more tech influencers mentioning it favorably.
• It is listed in the ‘S’ tier in the State of JS 2023 survey.
• Cloudflare Developers is built using Astro.

However, making this transition wasn’t easy. On one hand, I was familiar with the current tools and workflow. Though it was missing some features, but it was tolerable. On the other hand, it would take time to become familiar with new tools, build a new workflow, and transfer the content.

After a period of deliberation, I decided to make the switch.

Design

The new site is separated into 3 parts: essays, comments and stream. Essays are articles I write on specific topics, stream is mainly for life activities, like books, photos and thoughts. Kind of facebook homepage, but just for myself.

Essays are written in MDX and generated by Astro. Stream contents are stored in PocketBase and rendered dynamically via Astro’s SSR. These contents are created using PocketBase’s built-in GUI. Comments are also stored in PocketBase, using PocketBase’s API.

Development

Astro’s Developer Experience is really good. It may take some time to get familiar with its directory structure, design philosophy and API. But once you get through this stage, you gain power. Thanks to the well-written docs and GitHub issues, whenever I encountered a problem, there was usually a solution.

• I wanted to provide a full-content RSS feed, but MDX files can only be fully rendered within .astro context. Thanks to the Container API (experimental), I nailed it.
• I struggled for half a day trying to achieve swap HTML (from server) effects with an .astro component, but it was hard to rebind elements to JS functions. I ended up just using React.
  • You can’t bind js functions to jsx-like syntax, because they are not real DOM elements, and will be serialized, so js functions can’t survive.
  • <script is:inline> can make HTML and scripts stay together, but after you replace the HTML with the new content, old scripts won’t work (cause they were bound to the old DOM).
• server islands are useful for non-server-related components. They work well for lists, or client-side interactions. When server contents are involved, DOM rebinding becomes an issue.
• .astro pages are like PHP, but more frontend-friendly.
• .astro components are handy for MDX.

It took me 5 days (working full-time) to design, develop, and transfer content. It wasn’t easy, but as the foundation for the next decade, it was worth the effort.

Deployment

This site is served on a VPS, so I chose Node as the adapter. In theory, it’s simple to deploy: just run pnpm build and node ./dist/server/entry.mjs, then make Nginx point the domain to the port. But reality taught me a lesson. When I ran pnpm build, it took nearly 8 minutes and failed, due to running out of memory.

My first thought was that it allocated too much memory when optimizing images, so I set limitInputPixels: 10000 (100x100) in astro.config.mjs to tell Sharp not to process large images. It didn’t work.

Then I found someone mentioning a command option --experimental-static-build that might fix this scenario, but still, it didn’t work.

When I only left 1 post for Astro to build, it worked, though it still took about 5 minutes.

I was kinda desperate then, even considering rolling back to Zola, which at least wouldn’t cause these issues. This thought lingered for a while before I decided to overcome the problem.

since it could build on my machine, why not just skip the build process on the server and use my machine’s build result? So I put the dist directory in git, and on the server side, I just ran node ./dist/server/entry.mjs. Guess what? it worked! Though it was a bit quirky.

Just as I thought the mission was complete, something else happened. I wanted to write some cache files to the local disk. So I created a .env file, set the cache path, then built and pushed to the server. Server crashed. After digging into the logs, it turned out the cache path was still my machine’s path instead of server’s path defined in the .env file.

The .env file is read at compile time, not runtime. I could remedy it by replacing all the env content before running, but it would be ugly and could lead to potential bugs.

Just when I was at my wit’s end, Bun saved me. Bun is known for its speed and efficiency, and Astro supports Bun, so I decided to give it a try. I ran bun install and bunx --bun astro build. Literally just these two commands, and it worked!

There were still some minor scenarios to handle (e.g. import.meta.env is different when using Bun), but the deployment section basically came to an end. Bun is not only fast but also resource-efficient. In the future, I will prefer Bun over Node.

Conclusion

Astro as a meta-framework fully meets my requirements. PocketBase, combining data storage and CMS in a single file, is really convenient. I hope this new system can help me create more and better content in the future.

这篇文章是我与 AI(Claude 3.5 Sonnet) 共创的结果，我贡献了最初的思考，AI 对它进行了完善和补充。以后这种共创模式应该会更加普遍吧。

我的思考

如果我们把 AI 的发展拆分为三个阶段，就能看到 AI 可能带来的影响。

• 第一阶段：不具备智能的汽车。此时司机具有重要性，因为不仅要会开车，还要知道怎么走，换一个人来很可能就做不到。
• 第二阶段：自带导航的汽车。此时司机具有一定的重要性，虽然不需要提前知道怎么走，但依然要会开车，多年来积累的行驶经验依然有意义。
• 第三阶段：自带导航能够自动驾驶的汽车。此时司机不具有重要性，只要告诉它要去哪里就行。

把这个场景拓展到其他领域，就会发现人在其中的参与度和重要性会越来越弱。此时人与人的差异会越来越小，毕竟如果 80% 的事都是 AI 完成的，人与人之间的那些差异实在可以忽略不计。

那么最重要的问题就只剩下两个：

1. 谁的 AI 更加强大。
2. 谁的 AI 与自身的集成度更高。

经 AI 完善后的版本

我对 AI 说的第一个 Prompt 是：

以下是我对 AI 的一些思考，你看看有什么地方可以改进或补充的？

[思考内容]

AI 给出了它觉得可以完善的点。然后我让它结合这些点，再重新书写一遍。内容很全面，包含了社会结构变革、伦理道德等。

我让它就「人在 AI 时代应该做什么」这一点展开讲讲。

你能够就「人在 AI 时代应该做什么」这一点展开讲讲么（比如哪些技能是最重要，最优先的）？最好附上一些例子

它罗列出了 6 个点，最后我让它从这些点中挑选最重要、最核心的几个能力。再结合之前的内容，去掉一些不相关的内容，最后的成文如下。

---

如果我们把AI的发展拆分为几个阶段并类比于汽车的发展，我们就能更清晰地看到AI可能带来的深远影响。

AI发展的阶段

1. 基础工具阶段：类比于不具备智能的汽车。此时人类操作者极其重要，因为不仅要掌握操作技能，还要具备专业知识。在AI领域，这相当于早期的计算机程序，需要专业人员编写和操作。

2. 辅助决策阶段：类比于自带导航的汽车。AI开始在特定领域提供决策支持，但人类仍然控制最终决策。人类的经验和判断力仍然至关重要。

3. 部分自主阶段：这是一个过渡阶段，类比于高级辅助驾驶系统。AI可以在某些情况下自主运作，但人类需要随时准备接管。在更广泛的AI应用中，这可能表现为AI能够处理常规任务，但复杂或异常情况仍需人工干预。

4. 全面自主阶段：类比于完全自动驾驶的汽车。在这个阶段，AI系统能够在大多数领域独立运作，人类的角色转变为高层次的决策者和系统管理者。

人类角色的转变

随着AI的发展，人类的角色正在发生质的变化：

• 从”操作者”到”管理者”：人类将更多地专注于制定策略、设定目标和管理AI系统。
• 从”执行者”到”创造者”：人类将更多地投入到创新、创造性思维和解决复杂问题中。
• 从”专家”到”通才”：跨学科知识和综合能力将变得更加重要，因为AI可以处理大部分专业性强的具体任务。

新的差异维度

虽然在某些方面人与人之间的差异可能会减小，但新的差异维度可能会出现：

1. AI协作能力：谁更善于与AI系统协作和沟通。
2. 创造力和批判性思维：这些人类特有的能力将变得更加珍贵（AI擅长处理已知模式和数据，但在创造全新概念和想法方面仍有局，限能够快速适应新环境和新技术的人将在职场中保持竞争力）。
3. 适应性和学习能力：在快速变化的环境中，持续学习和适应新技术的能力至关重要（AI可以提供大量信息和初步分析，但人类需要批判性地评估这些信息）。
4. 情商和人际交往能力：随着AI处理更多技术性任务，人类的软实力将更受重视。

---

这位 YC tech founder 就是个很好的例子。

「独立创作者」是指那些对时间和地点有较高自由度、以作品创作为主的群体。「工作节奏」包含了目标、项目、任务、时间规划、Deep Work、回顾等诸多元素。

---

随着 AI 的发展，个人能够做的事情会越来越多，一方面 AI 拓展了各个维度的可能性，另一方面有了 AI 的加成，不仅效率上能得到极大提升，领域门槛也会降低（比如编程能力不再需要经年的积累，学会用好 AI 变得更为重要）。

当有了可以自由支配的时间后，还需要一套贴合自己的工作节奏才能最大化这些时间的效用，本文结合自己有限的经验来聊聊这个话题。

要点

Deep Work

Deep Work(深度工作)这个概念由 Cal Newport 提出，在他的同名书里有详细的描述。这个视频里，他对 Deep Work 从 What is Deep Work, Why it’s important, How to do it better 这三个方面进行了解读。

Deep Work 描述了一种状态：Focusing without distraction on a cognitively demanding task（心无旁骛地专注于一项认知要求较高的任务）。这里有两个要点：

• Foucsing without distraction: 没有 context shift，比如在工作与刷手机，玩游戏之间切换
• Cognitively demanding task:「系统二」参与度高的任务

对于独立创作者来说，Deep Work 非常重要，只有 Deep Work 才有可能创作出令自己满意的有竞争力的作品，同时 Deep Work 也能让自己处于心流状态，体验深度的愉悦。

Time Blocking

Time Blocking（时间块） 的奥义是把一天划分为多个时间单元，每个单元安排特定的任务，这样可以更加合理地安排每天能完成的任务。因为这会强迫你思考一个任务大概会占用多长时间，一天大概能排几个任务。

Time Quality

把一天的时间分块后，你会发现时间块之间的质量也是不一样的。通常来说上午的时间块质量最好（最清醒，系统二最活跃），下午其次，晚上的最差。可以针对时间块的特性安排不同类型的任务。

Weekly

对于独立创作者来说，「周」是一个很好的时间单位。一周的时间足够短，不需要花很多时间在任务编排上，出现问题（比如任务安排过多或过少）也可以及时回顾和纠正；一周的时间又足够长，可以完成几个 Feature 或修复一些 Bug。

工作节奏

了解了上面这些要点之后，独立创作者的理想工作节奏可能是这样的：

• 周一到周五：
  • 每天早上从本周的任务列表中取出任务，放到对应的 Time Block 里，通过番茄工作法来记录。
  • 每天晚上将未完成的任务放回周任务，以便在之后的时间里再次被执行。
• 周六：缓冲区。处理因为种种原因，未能完成的本周任务。
• 周日：回顾本周的任务完成情况；回顾目标完成进度；设定下周待完成的任务。

实践

有了前面的铺垫，接下来就是找到合适的工具来践行这个流程。在调研了市面上多款成熟度和流行度较高的 Todo App 之后，发现 Ticktick 是最合适的选择，因为它内置了番茄时钟，而且可以方便地在 Task 和 Calendar 之间交互。

项目

一个项目是具有高度相关性的任务的集合，在 TickTick 里新建项目很简单：新建一个 List， Type 选 Task List 即可（不太明白什么场景下会需要新建一个 Note List）。

对于一个项目，需要有 Milestone 和 Task，TickTick 可以方便地将一个 Task 转成 Note，这个 Note 可以用来罗列 MileStone。

Task 的粒度可以粗一些，以一周内可以完成为宜（如果一开始就拆得很细会非常耗精力，容易产生大的误差，也不够灵活）。

周任务

新建了项目，拆分了粗任务，接下来就要以周为单位来处理这些任务。TickTick 没有内置 This Week 这个 Filter，所以需要新建一个 This Week 的 Filter 视图。有两种方式：1) 给本周要处理的任务添加 #week 标签，然后 filter 包含该标签的任务。2) 给这些任务分配一个时间，然后 filter 在 This Week 时间段的任务。

日任务

今天要做的任务从周任务列表中去取，并安排到对应的 Time Block 中，要做某个任务时，打开内置的番茄时钟进行记录，很方便。一天下来后，就能看到任务的实际完成情况与预期完成情况的对比。

经过几周的运行后，应该可以知道自己每天能进行多久的 Deep Work，什么时间段安排怎样的任务最合适，这个调校后的工作流就是自己的工作节奏。有了合适的工作节奏，可以避免 burn out或过于急躁，保障作品持续、高效地产出。

最后

这套系统我也还在实践过程中，目前工作节奏大概是：

• 周一到周五白天 Focus 在作品相关的任务上，晚上阅读和学英语，空隙时间构思写作内容。
• 周六写作（如果有明确要写的内容的话）或作为 Buffer 完成本周还没完成的任务。
• 周日回顾本周任务完成情况，安排下周要做的任务，同时消化这周了解到的各类信息。

独立创作不是一种行为艺术，更不是逃避生活的借口，而是一种主动选择的生活方式。很多人向往却难以迈出第一步，或因难以坚持而中途放弃。独立创作要求高度的自律和时间管理，需要在创作、生活、学习、休息之间找到平衡，确保持续进展。Cal Newport在《深度工作》中也提到，高度专注和时间管理是成功创作的关键，这对于独立创作者尤为重要。

作为独立创作者，你不一定需要掌控作品的每个环节（如出版、销售等），但作品应与创作者有强烈的联结。当人们谈论一部作品时，创作者应是第一个被提起的名字。例如，《冰与火之歌》系列尽管有众多参与者，但提到它时，人们首先想到的依然是乔治·马丁。

无论是写一篇文章、做一个贺卡生成页面，还是画一张樱桃的画，都是独立创作的一种形式。坚持下去，创作便成为一种生活方式。这听起来简单，却也充满挑战——因为创作不总能带来稳定的回报，生活的压力可能迫使你选择其他道路。为此，独立创作者需要做出长远的财务规划，如准备足够维持5年的生活经费，以缓解经济压力。

在创作的过程中，难免会遇到瓶颈与自我怀疑。因此，快速了解自己的能力和属性，确定是否继续这条路，并在必要时进行针对性补强，是十分必要的。同时，保持良好的心理状态至关重要。Angela Duckworth在《坚毅》一书中提到，毅力和激情是实现长期目标的基础（可参考她的Ted演讲，核心内容与书中相似）。建立社交支持系统，与其他创作者交流（如杭州·良渚的「疯狂星期四」活动），或通过冥想、运动等方式来平衡情绪，可以帮助创作者走得更远。

独立创作通常是一条更难的路，但有独特的体验和别样的风景，比如在创作过程中你能够自由地表达自我，探索未知领域，享受灵感迸发的瞬间，以及与志同道合的人建立深厚的联系。那些选择这种生活方式的人可能是在与工作的碰撞中，发现了自己无法抑制的创作冲动和没有与之对应的工种之间的矛盾，也可能是尝到了作品被认可被需要的甜头。

独立创作者应该慢慢成为某个领域的艺术家，他们的作品无论多小众，都应该被珍视。成为艺术家并不意味着一定要成名，而是专注于自己的追求，哪怕只是为少数人提供精致的体验。这既是生存之道，也是长久之道。要达到这个目标，可以专注于某个特定领域/小众市场，持续学习和积累经验，通过不断创作和发布作品来获得正反馈，提高知名度。

独立创作是关于自我实现的长期探索。它需要勇气去开始，需要智慧去规划，更需要毅力去坚持。如果你对这种创作生活方式心存向往，不妨给自己至少一年的时间去尝试吧，也许你的作品正是某些人在等待的那一份独特体验。

最后更新于：2024/10/30

这可能是每个想学好英语的人首先会问的问题，但似乎并没有被很好地解答。经过一番调研后，我试着给出自己对这个问题的理解。

首先要对「学好英语」有一个明确的定义，我对它的定义是：有一个足够大的词汇库，当文字或语音命中这些词汇时，可以不费力地 get 到意思，同时能够不费力地用这些词汇来表达（用正确的语法来叙事、表达感受等等）。

左边是词汇库，右边是有明确意思的完整的句子，中间的双向箭头表示：当别人提到这些词汇时可以知道对应的意思，当自己想要表达时，可以知道应该用哪些词汇。线的粗细表示这种 Effortless 的程度（线越粗越不费力）。

比如这句话:

Why are you guys yelling at us when we’re way upstairs?

如果对 yell 比较陌生，就不容易 get 到这句话想要表达的意思。如果对用 way 来表达程度不太熟悉，那么自己在造句时可能就会回到最熟悉的 too 或者 very 等词。

要让这个词汇库丰富起来，会经历四个步骤。分别命名为 F1, F2, F3, F4。

• F1: 不知道它们存在的词汇。
• F2: 见过一次的词汇。
• F3: 多次遇见的词汇。
• F4: 可以被用来不费力表达的词汇。

要扩大 F3 的词汇库，比较有效的方式有两个：

• 大量、反复听/看合适的影视剧/书籍（大量、反复地听和看，除了扩充词汇，也是为 F4 阶段的「不费力」打基础）
• 用英语学习自己专业领域的内容（一箭双雕）

As more and more people get both information and entertainment through electronic media, researchers have also studied the extent to which vocabulary is learned through television (Peters & Webb, 2018) and through computer games (Cobb & Horst, 2011; Sundqvist & Sylvén, 2012). They have found that these resources can be effective in expanding vocabulary. More research in this emerging area should help to specify the nature and extent of vocabulary growth via exposure to electronic media. In the meantime, research has overwhelmingly confirmed that vocabulary growth will be limited if the learner does not also engage in focused vocabulary learning activities (Nation, 2001). Jan Hulstijn and Batia Laufer (2001) and others provide evidence that vocabulary development is more successful when learners are fully engaged in activities that require them to attend carefully to the new words and even to use them in productive tasks. Izabella Kojic-Sabo and Patsy Lightbown (1999) found that effort and the use of good learning strategies, such as keeping a notebook, looking words up in a dictionary, and reviewing what has been learned were associated with better vocabulary development. Cheryl Boyd Zimmerman (2009) provides many practical suggestions for teaching vocabulary and also for helping learners to continue learning outside the classroom.

— How Languages Are Learned

随着越来越多的人通过电子媒体获取信息和娱乐，研究人员还研究了通过电视（Peters & Webb，2018 年）和电脑游戏（Cobb & Horst，2011 年；Sundqvist & Sylvén，2012 年）学习词汇的程度。他们发现，这些资源可以有效地扩大词汇量。在这个新兴领域进行更多的研究，应该有助于确定通过接触电子媒体学习词汇的性质和程度。与此同时，研究表明，如果学习者不参与有针对性的词汇学习活动，词汇量将受到限制（Nation，2001 年）。Jan Hulstijn 和 Batia Laufer（2001 年）和其他人提供证据表明，当学习者完全参与需要他们仔细注意新单词甚至使用新单词的生产性任务的活动时，词汇发展更为成功。伊莎贝拉·科伊奇-萨博和帕齐·莱特布朗（1999）发现，努力和运用良好的学习策略，如记笔记、在字典中查找单词和复习学过的内容，与更好的词汇发展有关。谢里尔·博伊德·齐默尔曼（2009）为教学词汇和帮助学习者在课堂外继续学习提供了许多实用的建议。

影视剧可以提升听力（也可以通过字幕提升阅读能力），扩充中高频词库（日常对话，中高频的单词会多一些）；书籍可以提升阅读能力（也可以通过音频提升听力），扩充中低频词库。「合适」不仅指素材本身要合适（比如「兄弟连」虽然很经典，但不太适合，因为频繁出现的枪炮声，容易出戏），还要贴合自己当前的 Level，也就是可理解输入（i + 1）。

词汇学习的要素

Vocabulary learning occurs because certain conditions are established which facilitate learning. These are repetition, noticing, retrieval, varied encounters and varied use, and elaboration. These learning conditions are themselves underpinned by two key factors:

1. repetition, i.e. the number of encounters with each word.
2. the quality of attention at each encounter.

The greater the number of encounters, the more likely learning is to occur; and the deeper the quality of the encounters, the more likely learning is to occur.

— How Languages Are Learned

词汇学习之所以发生，是因为建立了一些促进学习的条件，这些条件是重复、注意、检索、多样化的接触和多样化的使用以及详细阐述。这些学习条件本身受到两个关键因素的支持：

1. 重复，即与每个单词的相遇次数
2. 每次相遇时的注意力质量。

接触的次数越多，学习的可能性就越大；接触的质量越高，学习的可能性就越大。

Research suggests that there may be little difference in the efficacy of learning smaller and larger sets of words. Instead, they found that students learned most effectively when there was greater spacing between each encounter with the same words. From a practical perspective, this suggests that learning a larger number of words may be more effective than learning a smaller number, because if the words are studied in sequence, there is likely to be a greater amount of time between each word being encountered and studied.

— How Vocabulary is Learned

研究表明，学习较小或较大的单词集合的效率可能没有太大差别。相反，他们发现，当每次接触相同单词之间的间隔时间更长时，学生的学习效果最好。从实际的角度来看，这表明学习更多单词可能比学习更少单词更有效，因为如果按顺序学习单词，那么每次接触和学习单词之间的间隔时间可能会更长。

这是 How Languages Are Learned 和 How Vocabulary is Learned 这两本书中提到的关于学习新词汇的要点。 主要是「保持一定时间间隔的重复接触」和「注意力质量」。前者如果每天抽一定时间来听和读，那些中高频的词就有可能被多次遇到；后者表示遇到新单词时要留心，回忆是否之前遇到过，可能是什么意思，或者根据上下文猜测可能的意思，结合字典验证。同时也要有意识地去 Review 新单词。

如何有效地利用影视资料

这里引用《我在100天内自学英文翻转人生》这本书中，作者提到的方法：

第一步：关掉所有字幕观看第一遍
第二步：打开中文字幕观看第二遍， 确认之前没看懂的部分
第三步：换成英文字幕， 把刚才没听懂的片段抄下来
第四步：反复练习听不清楚的片段， 听完马上跟读
第五步：关掉所有的字幕，观看剩下的97次

这些步骤可以进行微调，比如第一步可以多听几遍；二、三可以合并为一步，直接开中英字幕；不一定要抄下来，可以打个标记；也不一定要听 100 遍。要达到的效果是，不光里面的对话能够完全听懂，而且几乎可以背下来。

如何有效地利用书籍和有声书

这里引用 《中国人英语自学方法教程》里提到的 321X 法：

假设《Elon Musk》这本书有 100 章，那么每一章先听 3 遍（觉得不够可以再多听几遍），接着读 2 遍（弄懂每一句意思和其中的生词），然后再听一遍。最后这个 X 是自主扩展，包括单词集中复习、跟读、背诵等等。

注重输出，完成 F3 -> F4 的转变

F4 和 F3 相比，最大的变化是那个反向箭头，也就是有了想表达的内容后，可以快速找到合适的词汇，并组装成正确的句子。这个过程主要靠输出，包括：写作、讨论、聊天。写作因为有斟酌的时间，原先那些被动接受的词就有机会被拿出来使用，面对面沟通需要即时反馈，使用的通常是最熟悉的词汇。

输出的目的是完成对词汇的 Retrieval（检索），使之能够在正确的场合下被使用。这个过程中如果有人能帮助指出其中的错误自然很好，但如果不能问题也不大。以下是 《How Languages Are Learned》这本书中的描述：

Research on learner beliefs about the role of grammar and corrective feedback in L2 learning confirms that there is often a mismatch between students’ and teachers’ views. In two large-scale studies, Renate Schulz (2001) found that virtually all students expressed a desire to have their errors corrected while very few teachers felt this was desirable. In addition, while most students believed that ‘formal study of the language is essential to the eventual mastery of a [foreign language]’ (p. 254), just over half of the teachers shared this belief. While this may seem surprising, it is consistent with a version of language teaching that is based on the hypothesis that L2 acquisition takes place through exposure to meaningful and comprehensible language. According to this view, explicit instruction and feedback on error play very limited roles.

关于学习者对语法和纠正性反馈在二语学习中作用的信念的研究证实，学生和教师的观点往往不一致。在两项大规模研究中，雷纳特·舒尔茨（2001）发现，几乎所有学生都表示希望纠正他们的错误，而很少有教师认为这是可取的。此外，虽然大多数学生认为“对语言进行正式学习对最终掌握（外语）至关重要”（第254页），但只有略超过一半的教师同意这一观点。虽然这似乎令人惊讶，但它与基于假设的语言教学是一致的，即二语习得是通过接触有意义和可理解的语言进行的。根据这一观点，对错误的明确指导和反馈作用非常有限。

还有一种 Retrieve 单词的方式是，主动翻译母语的表达（不一定要说出来），比如你问媳妇儿：一会要去超市吗？可以下意识地把它翻译成英文。慢慢地就会发现生活中其实很多场景都可以用来输出。

---

以上就是我觉得可以高效学习英语的方式，总结下主要是这几点：

• 输入 > 输出（尤其是词汇量还不太够，听力也比较吃力）
• 大量、反复地听、看、跟读、背诵合适（感兴趣且可理解）的材料（影视或书籍）
• 有意识地扩充词汇量
• 保持一定频率的输出

继 Polly V1 小范围开放后，Polly V2 终于可以跟大家见面了。我对 Polly 的愿景是，通过对它的合理使用，可以达到英语能力的全面提升。

Polly 内置了你很可能感兴趣的书、美剧和电影（因为会涉及到影视剧、书籍的版权，所以采用了半封闭的设计，登录后可以看到相关内容），同时提供方便的工具来消化这些内容。这些内容可以理解为一个训练集，吃透了这些内容后（具体如何吃透可以参考 Polly 首页的说明），英语的综合能力应该会有较大的提升（当然也需要付出足够的时间）。

最后，如果你也对学好英语这件事感兴趣（you should!），且目前还没有找到趁手的工具，不妨试一下 Polly 吧。

第一次接触到「数字花园」这个名称是因为这篇文章，文中，作者将他创作的产品比作花园，我想「数字花园」可能是个更合适的比喻。既是花园，就需要有一片土地，可以在上面种不同类型的植物。

Twitter / 微博 / 小红书，这类的社交网络 App，不是自己的数字花园，虽然也能在上面发不同类型的内容，但要接受平台制定的显式的、隐式的限制（比如小红书里如果提及电话或下载地址会被封号，至少封一段时间），同时要与他人共用一个大花园。熙熙攘攘，完全没有花园该有的静谧。

微信朋友圈也不合适，发在朋友圈的内容多少带有「希望获得赞和评论」的目的性，进而驯化发布在上面的内容。「路边这朵花好漂亮啊」，这样的内容是不行的，「威尼斯河边的这朵花好漂亮啊」，这才可以。同时由于是封闭系统，无法让微信好友之外的人遇到这些内容。

那记事本（如 Apple Notes）可不可以？如果只想在某个孤岛上建一个花园，只有自己才能进入，那么记事本可以胜任。但人毕竟是社会性动物，还是会希望有一小撮人可以看到你的这个花园，一起聊聊这些植物、昆虫。

博客行不行？倒也不是不行，只是有几个问题，1. 要找到偏个人向，同时又可靠，且功能够用的博客平台并不容易。2. 博客的内容不方便在手机端发布。3. 博客的订阅不方便（RSS 毕竟只是技术人的宠儿）。

但我们的一些想法、一些达不到发朋友圈 level 的照片、一些网络上发现的奇奇怪怪的东西、甚至随意的 Doodle，这些植物需要一片土地，一片只属于他们的土地。对于别人可能没有多大的价值，但或许能与某一些同类型的植物爱好者产生共鸣和连接。

想来想去，Telegram 貌似是最合适的选择。发布 10 年多，服务的可靠性 OK；产品设计和使用体验 OK；全平台支持；功能丰富够用（支持图片、视频、音频等多媒体，而且没有空间限制；可以创建 channel；分享 Chat Folder 等）；背离初衷发展的可能性不大。

于是我就在上面建了一个自己的数字花园，10 多天用下来后，感觉确实挺方便的，想到什么可以随时发，没有点赞焦虑。也订阅了一些 channel（更新频率通常不高），发送内容的同时顺便扫一下。如果你也有构建数字花园的诉求，不妨试试。如果已经在用了，欢迎在评论中放出来。

PS: 这是我的花园链接，以下我订阅的一些 Channel：

• yihong0618 和朋友们的频道
• 不求甚解
• Du Xiao’s Stream
• 瘦瘦的绘画世界
• Yu’s Life

在编程领域，编写易维护代码是很重要的一部分，不然就会出现「屎山雕花」的情况。以下是我关于编写「易维护代码」的一些心得。

易维护的代码有怎样的特性？

易调式

• 出现问题后，可以快速定位问题出现的原因。

易调整

• 可以方便地找到改动处，以实现需求或修复 Bug。
• 改动带来的影响面明确且可控。（如果出现「字符串依赖」，而相关的 package 又都是二进制就会很麻烦）。

易测试

• 容易写测试。
• 容易执行测试。
• 测试可以覆盖大部分代码和场景。

易理解

• 通过看模块/方法/变量名/注释就能大概知道内容。
• 统一的代码风格。

写出容易维护的代码需要考虑哪些因素？

做好封装

• 明确哪些数据和能力是可被外部获取的，哪些应该是内部处理的（.h / .m）。
• 提供的能力是否有高关联度（高内聚）。
• 在做好封装的基础上，可以进行模块化开发，通过接口或协议来通信，将变化封装在模块内。
  • 比较难的一点是模块的划分，一个技巧是将经常会联动改变的模块合为一个。

处理好状态

• 是否有必要新增一个状态，可否组合已有状态。
• 状态之间的切换是否清晰（状态多且复杂，可考虑用一个 Library 来管理）。

命好名

• 是否直观。
• 是否只做一件事。
• 不好理解的部分做好注释（为什么会有这段代码，它是怎么工作的）。

写好日志

• 出现问题时，可以通过日志快速定位。
• 处理好 Error 日志，尤其是当 Error 在多个模块之间传递时。

一些 code smell（不好的迹象）

• 方法体很长。（不方便复用和测试）
• 方法的参数很多。（不好理解和使用，也可能是没抽象好）
• 重复的代码。（多处出现了同样/类似的代码）
• 一个小的改动会涉及到多个文件。（可能没封装好）
• God Object。（很多不相关的内容聚合到了一起）
• 紧耦合。（比如明明只需要一个 Plain Object，却在参数里要求传入一个特定的 class instance）
• 通过一些 trick，依赖了 class 的内部实现。

一些技巧

• 精读 1 - 2 个优秀的有足够复杂度的开源项目。
• 重构项目，直到它具备了足够好的易维护性。

写这篇文章的初衷是在 Hacker News 上看到的这个连接：The day I canceled my Spotify subscription，我自己也是通过灰色渠道在用着 Spotify，感觉这个 App 变得越来越重，东西越来越多，首页各种推荐给你的 List，还去不掉，自己的部分（Liked Songs，关注的 List）空间被越挤越小，差不多只占首页内容的 10%，哪天完全从首页移除我都信。同时它的 Scope 从 Music 扩展到了 Audio，开始引入 Podcast、Audiobook 等内容，这不可避免地会干扰找歌、听歌体验。

一个解决方案是把 Spotify 当作发现歌曲的地方，然后通过网站或工具下载对应的歌曲，再在另一个更纯粹的音乐播放器或者 Telegram 上来听，周折了点，倒也可行。另一个方案是换一个 App 比如 Apple Music（我一直用不惯，可能是我的问题）。

现在的 Spotify 简单来说有两个问题：

1. 过于注重歌曲/歌单推荐，使用户丧失了很大的自主权（比如这些推荐都不能关掉，或者默认不显示）。
2. 非歌曲相关的内容比重增加，影响纯粹的听歌体验（比如我只是想听歌，听 Podcast 会有专门的 App）。

第 1 点针对留存，第 2 点针对拉新。推荐内容其实没问题，但要考虑推荐质量和侵入度。如果有一个单独的「发现」Tab 用来放这些内容，把首页留给用户自己的内容，这样就挺好。但现在首页大部分内容都是推荐，推荐的还不一定是我感兴趣的，这就很反感了。扩大 Scope 也没有问题，但新的 Scope 和旧的 Scope 要兼容。如果一家咖啡馆要扩大 Scope，从咖啡，扩展到饮品，然后开始卖果汁、王老吉，并且比重还不小，这就很奇怪了。

公司要发展，自然会对产品进行一系列的升级，但这些升级是不是你想要的就不好说了。如何判断一个产品会不会走歪路，我的经验是可以从三个方面判断：

1. 产品过往的表现。比如过去 5 年产品的一致性，是在不停地尝试方向，还是围绕某个特定的需求进行改进和优化。
2. 融资情况。融了很多钱，还融了好几轮的要多留个心眼。
3. 创始人的气质。比如 37Signals 的 Jason 和 DHH，你能感觉到他们在某些方面是很偏执的，这种偏执可以避免产品变形。

Spotify 不再只做音乐流媒体平台，一方面是因为融了很多钱，需要拉更多人来买单，音乐这个市场已经挖掘地差不多了，那就要扩大市场，比如把[可能]听 Podcast 的用户也拉过来。还有一个原因是在音乐市场有最高的份额（只能怪不争气的 Apple Music），虽还不至于垄断，但在音乐方面确实有很高的壁垒。相比之下，一些独立开发者（小团队）的作品反而更有吸引力，因为把产品做好就是最大的竞争力，还要考虑如何触达目标用户，Bugfix，功能升级，售后等等，够忙好一阵了。

回过头来再说说自主权的丧失，对于 Mobile App，用户只能听之任之，改版不满意，也只能将就用着，而 Web App 不一样，浏览器的可定制性会强大很多，可以自定义 CSS、JS，安装插件，都不满意还可以自己做一个插件让目标网站变成自己想要的样子。这也是我喜欢 Web 的原因之一。

Update

使用 Spotify 过程中，发现居然有了类似抖音的上滑下滑操作，虽然很克制地将入口做得不那么显眼，但这个设计还是给我一种不太好的感觉。

经评论区的 maxos 提醒，我又重新开通了 Apple Music，设计上确实比 Spotify 更轻更舒服些，之前一直困扰我的 Favorite 问题也已经修复，首页虽然有推荐，但不多。还有一个很细但可能很有用的功能：App 重新打开后，会停在上一次打开的 Tab，而不是默认的第一个 Tab（Spotify 就没有这个功能）。

Polly 是我前一段时间写的用来学英语的网站，核心思想是通过电影、美剧和书籍来学英语。网站提供了精选的内容和方便的工具来帮助实践 100LS。

Polly 在功能上针对「跟读」和「复述」做了优化，也提供了推荐的使用姿势。因为影视版权的原因，不打算开放这个项目，也不会商业化。感兴趣的同学可以邮件我，描述下目前的状态、想要达到的目标等等，我可以把邮箱地址加到白名单里，之后或许还可以有进一步的交流 😉

Update

感谢大家的热情参与，目前精力主要在 Polly V2 的开发，Polly V1 的开放入口关闭，关于 V2 的最新消息会在博客更新，感兴趣的同学可以订阅 RSS 了解最新进展。

今天中午去了附近的一家日料店吃饭，因为它家中午有优惠，且饭的品质不错。菜上齐后，就吧啦吧啦吃了起来，可能是米饭太香了，就细嚼品了品。以前吃饭时，虽然不看手机，但脑子里总会想着其他事，不太会专注在面前的食物。今天可能是被这碗米饭吸引，我的注意力开始集中到饭和菜上。开始去回味沙拉中的玉米粒和沙拉酱，泡菜五花肉里的泡菜（因为五花肉太少了😂），鸡蛋羹的味道和颜色。中间也会分神去想一些七七八八的事情，但能够觉察到，并把注意力牵回来。

然后我就想到，这不就是 Mindfulness（正念）吗。所以要练习正念并不一定要打坐冥想、专注呼吸、打开 App 听 Guide，真的可以是随时随地（当然最好是一个人的时候），只要找到那个专注目标。

很多人没有坚持冥想，一方面是因为冥想的正反馈不够快速和强烈，另一方面可能也是局限于环境，不太好找到可以独处的空间和一段不被打扰的时间。我间断地尝试了一段时间的睡前冥想（有时入睡比较快，冥想的时间就少，有时索性就忘了😂），还是能够感觉到它带来的变化，开心时开心，悲伤时悲伤，但内心深处相对平静，不会受这些情绪驱使，去做出一些非理性的行为。

如果你想尝试冥想又没有好的环境，可以考虑下睡前冥想：保持正常的呼吸节奏，然后专注在呼吸上：感受流入鼻孔的那一股小小的冷风、感受胸口的扩张，思绪跑了就让它跑着，等意识到后再重新回到呼吸上。就是这么简单的一个习惯，如果坚持下去，相信会有所收获。

元宝事件之后，我开始更加严肃地看待意外事件：一些习以为常的存在是可以顷刻间不复存在的。无论多么不舍，多么懊悔，都回不来了。

于是我打算换个思路：现在拥有的一切都不是理所当然的，这些存在值得被感激。从 0 开始，一个一个叠加值得感恩的人、事、物。以下是我的不完全感恩列表：

• 身体
  • 能够品尝食物的美味
  • 能够聆听小鸟的叫声
  • 能够看到纷繁的世界
  • 能够与人顺畅地沟通
  • 身体没有明显的缺陷
• 精神状态
  • 没有被工作、家庭等各种事情压得喘不过气来
  • 能够做自己还蛮喜欢的事情
  • 没有颠倒的作息
  • 有时间看喜欢的书
  • 有经常能见面的好友
• 环境
  • 有房子可以住
  • 小区有很多树
  • 有热水澡可以洗
  • 和谐稳定的亲密关系
  • 家里有一只可爱的小鹦鹉
  • 双方父母都还健在，没有给太大的压力
  • 可以在天目里办公、看书、晒太阳
  • 社会稳定，没有被战争波及

这份感恩列表，需要真的认为是来之不易，才会真的去感恩，进而自然地产生满足感和愉悦感。这可能要经历过一些失去才会有更深的感触。

回顾这份列表的最佳时机应该是早上，在开始一天的活动之前，这样就可以怀着感恩的心态去迎接这一天。