2025-02-28 08:00:00
不知道从什么时候开始，对坐飞机开始有种难以言说的恐惧。害怕被一个钢铁巨鸟带到离地万米的高空，害怕那无法预知的颠簸，更害怕自己对此无能为力。但生活又是充满着不得不飞的时刻，这反而促使我开始了一场逆向思考：假如我不幸在某次飞行中丧生，回顾这一生，是否留有遗憾？
答案是肯定的。太多经典的书籍和影视剧还未来得及细细品味，太多让自己满意的作品还未曾真正诞生，太多互相欣赏的人们还未发展出牢固而深厚的友谊…… 这种「临终回顾」式的思考，出乎意料地有效。最好是在一个安静、不会被打扰，也不会被电子设备干扰的场景下去进行，比如洗澡的时候。
这些答案，宛如散落在沙滩上的贝壳，指引着我窥见自己内心深处的价值观。即使从未系统地思考过「价值观」这个概念，我们也会在潜意识中，对什么事情值得做、什么事情不值得做，拥有一套隐形的价值判断标准，也就是一套隐式的价值观。
将这套隐式的价值观显式化，尤为重要。只有这样，我们才能清晰地认识到自己长久以来的做事标准，是否真的与自己内心深处的期望相符。例如，我一直认为「学习」很重要，但如果我把大部分时间都花在刷短视频上，那么我的行为就与我的「理想价值观」产生了偏差，「学习」或许在「实际价值观」序列中，但可能排在「享乐」之后。
更进一步，我们需要深入挖掘和细化这些价值观。仅仅停留在「读书」、「创作」、「友谊」这些模糊的概念上还是不够。问自己：我想读哪些类型的书？是文学名著，还是历史传记？为什么这些书对我来说有价值？是因为它们能拓展我的视野，还是能给我带来精神上的慰藉？我想在哪个领域进行创作？是写作、绘画，还是编程？「满意」的标准是什么？是得到认可，还是实现自我表达？我期望的友谊是什么样的？是互相支持，还是共同成长？
这些深入的追问与解答，能够帮助我们更清晰地界定个人价值观，并将其转化为可执行的具体行动。 例如，在阳光明媚的春日午后，当许多人选择外出踏青时，你却心甘情愿地坐在咖啡馆一隅敲击代码，因为对你而言，创作的价值超越了踏青的乐趣。 又比如，你选择观看一部制作精良的美剧，而非沉溺于碎片化的短视频，因为你认为美剧所蕴含的艺术价值远高于后者。 当生活中的种种选择与内在价值观紧密相连，而非盲目随波逐流时，我们更容易收获一份由内而外的踏实感与满足感。
值得注意的是，不同的价值观之间往往存在潜在的冲突。 例如，对事业成功的极致追求，可能不可避免地挤压陪伴家人的宝贵时间。 此时，我们需要认真权衡： 在不同价值观之间，究竟哪个对我而言更为重要？ 为了追求某些核心价值观，我愿意舍弃什么？ 又该如何巧妙地平衡不同价值观，以便获得更加幸福与完整的人生体验？ 对价值观进行优先级排序，能够帮助我们在面临人生抉择时，做出更贴合内心真实期望的明智决策。
有了价值观列表和对应的序列，还需要将这些显式化的价值观融入到日常生活中。审视我们的时间分配，看看我们每天/每周/每月花在哪些事情上的时间最多？这些事情是否符合我们的价值观？基于我们的价值观，设定一些长期和短期的目标。例如，如果我认为“学习”很重要，可以设定每周阅读多少小时。在面临选择时，问问自己：这个选择是否符合我的价值观？它会让我更接近我想要成为的人吗？
「定期反思」也不能少，看看行为跟价值观是否保持一致。如果发现偏离了方向，及时进行调整。这注定是一场持续探索与动态调整的旅程，没有放之四海而皆准的绝对答案。 重要的是，在不断地自我反思与成长中，逐步找到最契合自身本性的理想生活方式。
回到最初的恐惧，正是这种对生命短暂的感知，才更加迫切地思考人生的意义。 「以终为始」的核心在于：想象你在生命的终点回顾一生时，希望看到的是什么：做成了哪些事？去过哪些地方？陪伴子女幸福成长？抑或只是安安稳稳地过完这一生？如果上天把你的一生压缩成 10 分钟的短片，播放给来参加你追悼会的人看，你会觉得羞愧还是骄傲？
理想的人生，应该是随时死去，都不留遗憾。
2025-02-27 08:00:00
大概半年前，我开始接触 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 编程工具（Copilot 相对轻量，可以作为入门级选择）。要努力做到与 AI 工具默契配合，充分发挥其代码生成和辅助功能，从而显著提升个人生产力，并将节省出来的时间投入到更有价值、更具挑战性的事情上。
接下来，可以认真考虑未来的职业发展方向。如果希望在编程领域持续深耕，可以着重提升高级程序员应具备的核心技能，例如系统设计、复杂业务逻辑分析、问题分解与抽象、疑难 Bug 调试与根因分析、系统性能优化、创新技术方案设计等等。在这个学习和提升的过程中，也可以借助 AI 工具来提高学习效率，例如在阅读学习优秀的开源代码时，可以利用 AI 辅助代码理解，梳理代码逻辑，解答设计思路上的疑问。
如果对产品方向更感兴趣，或者有创业的想法，则可以投入更多时间在产品设计、用户研究、市场分析等方面，利用 AI 工具快速构建 MVP原型，快速验证产品想法，探索商业模式。
可以将 AI 工具使用者与 AI 编程工具之间的关系比作「交响乐团的指挥家与乐团」。程序员如同经验丰富的指挥家，拥有清晰的愿景和目标，负责软件系统的整体架构和模块设计，指导和协调 AI 工具（如同乐团）高效、高质量地完成代码编写（如同乐曲演奏）。AI 工具如同训练有素的乐团，拥有强大的代码生成和辅助能力，但需要指挥家的明确指令和专业引导才能演奏出优美的乐章。
不同的 AI 编程工具都有各自独特的功能和特点，但与它们交互的核心要点是共通的：精细化任务分解和指令设计，以及代码 Review。 在人机协作的新范式下，程序员不仅需要与 AI 工具高效沟通，还需要与团队成员更好地协作，共同利用 AI 提升团队的整体研发效率和代码质量。
半年前我初次尝试 AI 编程助手效果不佳，也是因为没有掌握与 AI 编程工具有效沟通的精髓。可以将这些 AI 工具视为响应迅速、随叫随到的「外包程序员」，每一次代码改动都相当于一次 GitHub 的 Pull Request。要确保每次改动的目标明确具体，代码改动量控制在可审查的范围内。最终目标是代码虽然不是完全由自己编写的，但对代码的整体逻辑和关键细节都非常熟悉，这样即使 AI 无法解决某些深层次的 Bug，自己也能凭借对代码的深入理解，逐步分析和定位问题根源。
AI 辅助编程的崛起既是挑战，也是机遇，基本上是不可逆转的趋势。如果半年前有人这么跟我说，我可能会将信将疑，但现在对此更加确信。即使只是体验了入门级的 Copilot，也已经真切感受到了它带来的效率提升。尽早找到适合自己的 AI 编程工具，积极完成与 AI 的磨合过程，然后将效率提升所节省出的宝贵时间，投入到扩展和丰富自身技能库上，不断学习和掌握更高级的技能，让自己成为拥抱 AI 浪潮的弄潮儿，而不是被技术浪潮无情淘汰的落伍者。
2024-12-01 08:00:00
媳妇儿在小红书上种草了长龙航空的随心飞，于是怂恿我一起买了这个服务。然后就开始寻找目的地，本着第一趟就要赚回本的理念，选择了距离杭州近 5000 公里，中国最西部的城市：喀什。
我对这个城市只停留在「听说过」的阶段，对于当地的美食、美景、风土人情、历史典故等毫无概念，但既然媳妇儿选择了这里，就只能陪着一起去了。当时的心情没什么波动，甚至有点排斥，因为一想到要坐那么久的飞机（我对坐飞机这事有较大的心理障碍，确切来说是「高空」，所以摩天轮也不是我的菜），还要离开熟悉的地方一段时间，就会怀疑这么折腾到底值不值。
结果是，非常值。我跟媳妇儿都已年近 40，没有孩子，平时也都是各忙各的，交集主要是生活上的一些事。当缺少比较强的 hub 来连接彼此时，两人之间的连接感就容易变弱，而旅行是一个很好的可以加强连接、增进友谊的契机。
目的地的选择很重要，最好是双方都不太熟悉的。如果这个地方给两人带来的新奇感程度不一，就不容易有「共振」的体验，而「共同的情绪体验」是亲密关系中很重要的一部分。比如手抓饭，如果都是第一次吃，就能分享这道美食带来的惊艳。还有就是「弱攻略依赖」，也就是不用事先花大力气做好功课，也能有不错的体验，不会有太大的坑。
喀什是个很好的目的地，一方面是这里的美食通常是我们没怎么接触过的，而且确实很不错（印象最深的是石榴，榨成汁后不仅好喝，还营养丰富），另一方面喀什古城很好逛（虽然是淡季，很多店面都关门了，但古城的底蕴还在，在其间溜达还是挺舒适的，尤其是太阳照常上班的日子），还有就是这里的风土人情跟东南沿海差异很大，这种差异也是一个很好的切入点，成为两人茶余饭后的聊天话题。这里的人通常有自己的小买卖，比如开个饭馆、卖当地特产、烤肉等等，有些硬需求常年不变，就会出现从爷爷辈甚至爷爷的爷爷传下来的手艺，比如「爷爷的爷爷的爸爸的囊」、「祖传兄弟凉粉」。
临走的前一天，我们去「爷爷囊」那里，买了四个香菜囊，不远万里（literally），从喀什带到了杭州，算是对这趟旅行的一些回味😂。
2024-11-11 08:00:00
去年，看了一本印象颇深的书：北方的空地。这本书讲的是一个叫杨柳松的人，推着一辆自行车（交通工具兼载货工具），历经 77 天，独自穿越羌塘无人区的故事。旅途非常艰险，一点小小的意外就可能导致极严重的后果（比如帐篷的地钉被吹走）。但体验独特，风景绝美。看完后，印象最深的除了他的那份胆识、勇气和乐观外，还有那非常严谨的准备工作，让看起来几乎不可能完成的任务成为可能。
然后我就想到了独立开发者，他们也像杨柳松一样，独自走进羌塘，面对诸多的不确定性和艰困的环境，试图从中找到一条出路。我目前还不是一个合格的独立开发者，思考上肯定会有所欠缺，但还是写下来，作为进入这个领域的前期准备工作吧。
说到独立开发，很多人的第一反应是「自己做一个产品」。但实际上，它是一种特殊形式的创业。特殊在哪里？你需要在极其有限的资源下（通常是一个人、有限的时间和资金），找到一个可持续的商业模式。
这就像是你决定开一家小饭店。不同的是，你不仅要当老板，还要同时担任设计师、厨师、服务员、采购、营销…所有角色。这听起来很累？确实如此。但这种方式也有独特的优势：决策快、运营成本低、方向调整灵活。
在我观察到的案例中，成功的独立开发者往往都很擅长选择合适的战场。这里的”合适”，不是指最大或最热门的市场，而是要找到：
举几个具体的例子：
沉浸式翻译 是我很喜欢的一款翻译工具，使用几天后，就安利给了周围的朋友。作者 Owen 在一期访谈中提到，他在看王小波的沉默的大多数时，看到书中有提到萧伯纳的芭巴拉少校 很值得一看，然后他就找到了这本书，书中的中英文排版浏览体验给了他很大的惊喜和启发，最终促成了沉浸式翻译这款工具的诞生。
Pinboard 是一个简单、高效的社交书签服务，由 Maciej Ceglowski 创立。Maciej 的初衷是为用户提供一种可靠的方式保存和组织网络链接，专注于简洁和隐私保护：
这两款作品的作者都是独立开发，他们找到了合适的战场，其中很重要的一点就是「做自己产品的第一个用户」。
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 的创始人）也说过：「最好的产品灵感来自于解决自己的问题」。当你是自己产品的目标用户时，会获得几个关键优势：
你不需要想象用户的痛点，因为你就是那个每天都在经历这个问题的人，这种第一手经验无比珍贵。
创业路上最重要的不是灵感乍现的那一刻，而是持续的投入。当你在解决自己的问题时，这种动力会更持久。因为即使项目还没有其他用户，你自己就是受益者。
很多决策不需要漫长的讨论和市场调研，因为你对目标场景太熟悉了。这种直觉判断虽然不一定完全准确，但往往能抓住重点。
当你真的解决了自己的问题，你会很自然地想要分享给同样有这个问题的人。这种发自内心的推荐很容易引起共鸣。
即使你吃自己的狗粮，结果仍然可能不如意，比如需求提炼不够精确，产品不够惊艳，缺少推广途径等等。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)，而是验证核心假设的最小功能集。比如：
在开始前就要明确：什么算成功，什么算失败？例如：
放弃一个项目往往比坚持更需要勇气。以下是一些值得注意的「放弃信号」：
放弃一个项目不等于前期投入都白费了。过程中获得的经验、技能提升、用户洞察等等，这些都是宝贵的资产。
独立开发最大的挑战之一是：如何在资源有限的情况下，建立起竞争优势？答案可能是：持续积累。
比如 Tony Dinh
这些持续的输出帮助他：
国内的同学可能更加熟悉的 Kevin、Tualatrix、Baye，也都非常注重个人品牌建设。曾经 Baye 和小护士的故事，则是另一段佳话了 😂。
每做一个项目，都要注意积累可复用的资源：
这些资产会让你的下一个项目启动更快、质量更高。
独立开发者最宝贵的资产之一是忠实用户群体：
这些用户不仅会持续给你建议，还会成为你的产品传播者。
独立开发要求多面手，但这不意味着你要样样精通。可以把能力分为 Essential（核心能力） 和 Plus（增强能力）：
在独立开发的路上，有一些常见的陷阱需要警惕：
表现：
解决方案：
表现：
解决方案：
表现：
解决方案：
表现：
解决方案：
独立开发是一条充满挑战的道路，但也充满机遇和乐趣。关键是要：
这道题，没有标准答案，每个人有适合自己的节奏。重要的是在实践中不断学习和调整，直到找到那个真正适合你的机会。
独立开发不是终点，而是一种生活方式的选择。在这条路上，希望你也能找到属于自己的节奏和乐趣。
| 产品类型 | 维护压力 | 技术复杂度 | 运营需求 | 美感要求 | 特点说明 |
|---|---|---|---|---|---|
| 实时通讯类 | 高 | 高 | 高 | 中 | - 需要保证服务稳定性 - 需要处理大量并发 - 用户体验要求高 |
| 在线协作工具 | 高 | 高 | 中 | 中 | - 需要确保数据同步 - 需要处理多人协作场景 - 稳定性要求高 |
| 支付相关服务 | 高 | 高 | 中 | 低 | - 安全性要求极高 - 需要专业资质 - 责任风险大 |
| SaaS工具 | 中 | 中 | 中 | 中 | - 需要定期更新维护 - 需要处理客户支持 - 相对稳定的收入 |
| 社区类产品 | 中 | 中 | 高 | 中 | - 需要持续运营维护 - 内容管理要求高 - 用户增长是关键 |
| 单机游戏 | 低 | 中~高 | 低 | 高 | - 开发周期较长 - 发布后维护较少 - 营销很重要 |
| 效率工具 | 低 | 低~中 | 低 | 高 | - 功能性为主 - 用户体验重要 - 竞品较多 |
| 开发者工具 | 低 | 高 | 低 | 低 | - 技术门槛高 - 用户群体专业 - 变现相对容易 |
| 设计类工具 | 低 | 中 | 低 | 高 | - 视觉体验重要 - 专业用户群体 - 需要持续更新 |
| 内容平台 | 中 | 中 | 高 | 中 | - 内容运营重要 - 用户留存是关键 - 需要持续产出 |
| 生活工具类 | 低 | 低 | 低 | 高 | - 界面设计重要 - 功能相对简单 - 用户基数大 |
| 数据分析工具 | 中 | 高 | 中 | 中 | - 专业性要求高 - 准确性要求高 - 需要持续优化 |
| 教育类应用 | 中 | 中 | 高 | 中 | - 内容质量重要 - 需要持续更新 - 用户服务要求高 |
| 自动化工具 | 低 | 高 | 低 | 低 | - 技术门槛高 - 稳定性要求高 - 用户群体专业 |
| 主题/模板 | 低 | 低 | 低 | 高 | - 设计质量重要 - 更新频率低 - 竞争激烈 |
对于希望进入到独立开发领域的同学，建议从工具类型入手，因为运营成本相对较低，用户需求明确，技术门槛适中，更容易找到自己的节奏。
2024-11-08 08:00:00
想象有一个金融委员会会议，讨论三点议程，要点如下：
会发生什么？委员会最终在很短的时间内就通过了核电站提案。它太高级了，谁都无法真正深入研究细节，而且大多数成员对这个主题了解不多。即使有人了解，解释起来也非常困难。
讨论很快就转移到自行车棚上。在这个议题上，委员会成员可以更轻松地表达自己的意见。他们都知道什么是自行车棚以及它是什么样子。一些成员开始就屋顶的最佳材料展开激烈辩论，权衡可能的选择。他们讨论自行车棚的时间远远长于讨论发电厂的时间。
最后，委员会讨论第三项：咖啡预算。突然间，每个人都是专家。他们都了解咖啡，并且对其成本和价值有强烈的认识。在人们意识到发生了什么之前，他们讨论 21 英镑咖啡预算的时间比发电厂和自行车棚加起来的时间还要长！最后，委员会没有时间了，决定再次开会来完成分析。每个人离开时都感到满意，为谈话做出了贡献。
这个故事是帕金森在 50 年代提出来的，被称为「帕金森琐事定律」或「自行车棚效应」。其要点是：话题越简单，发表意见的人越多，讨论也越深入。而对超出我们能力范围的事，例如核电站，甚至不会尝试表达意见。总结一句：人们更愿花时间在简单的小事上，而在重大复杂的问题前草草了事。
《思考，快与慢》一书中的「系统一」和「系统二」可以很好地解释这种心理。系统一是我们大脑中的自动模式，擅长快速、直觉反应，不费脑力。它是帮我们处理琐事的好帮手，却不适合深思熟虑。相比之下，系统二则负责理性思考和逻辑分析，但它启动起来费时费力，不是我们“下意识”就会用的。
自行车棚的问题之所以那么吸引人，是因为它简单，人人都有话说，系统一完全能胜任。但真正重大的项目，比如一栋楼的整体预算、结构安全这些问题，太复杂，系统一根本应付不来。于是，大脑下意识地选择“避重就轻”，将精力转移到自行车棚这类小事上。小事有一种假装参与感的安慰——我们觉得自己有所贡献了，哪怕实际作用微乎其微。
究其原因，是因为自行车棚代表了一种心理上的“安全区”。在会议中讨论一个自行车棚的建设方式、颜色，参与者可以迅速提供意见，获得一种控制感和掌控力。这种参与感有一种立即的满足，它让人觉得：我可以主导这个细节，我的意见是重要的。反观那些需要系统二深度分析的复杂问题，听上去就容易让人感到无力，甚至恐惧。大脑自然会倾向于选择让人舒服、轻松的领域，而避开那些让人头疼的大事。
与此同时，自行车棚效应也揭示了我们的“从众心理”。在一个群体中，小事讨论容易形成共识——你说黑色好，我觉得灰色也不错，很快大家就能找到一个共同点，觉得“和谐”。但一旦讨论涉及到真正影响全局的重大决策，必然会产生争议，往往谁都不想打破这种“和谐”。于是，为了避免可能出现的冲突和不适，大家更乐于在细枝末节上“和和气气”地交流，而忽视大局。
不仅是在会议中，我们日常生活中的许多行为模式也在强化自行车棚效应。现代 App、社交媒体、游戏，甚至新闻都在迎合我们的系统一。它们通过即时反馈、情绪化内容和算法推荐，让我们沉迷于短期的、简单的信息。刷社交网络时，我们倾向于关注那些轻松、引人注目的内容，而对真正重要的信息或深度思考敬而远之。久而久之，我们的大脑适应了这种“快餐式消费”，开始习惯性地规避复杂问题，随之而来的，就是对小事的无限纠结和讨论。
在这种环境下，自行车棚效应被放大了。面对短暂的成就感、娱乐化的内容，我们的大脑越来越少地启用系统二，更难在重要的问题上花费精力。许多讨论度极高的热点话题，其实本质上只是一些无关痛痒的小事，但我们却乐此不疲地卷入讨论，忽视了那些真正值得关注的议题。
为了减少对系统一的依赖，我们可以采取一些强化系统二、弱化系统一的行为和习惯，比如：
既然自行车棚效应源于人们对小事的关注，我们不妨反其道而行之，将其转化为一种积极的工具。毕竟，如果我们可以利用“对小事的投入”来完成一些困难的、有价值的事情，那这个效应就能为我们所用。
1. 将大任务拆解成“小自行车棚”：面对复杂的任务，我们可以把它分解成多个小目标。让自己每次只专注于一个具体的小事，这样既能启动系统一，增强完成感，同时又让系统二有机会在需要时参与进来，理性分析。
2. 利用小成就感，积累完成动力：当我们完成了一个个“小自行车棚”任务时，系统一的“即时成就感”会帮我们维持动力，而系统二则可以在长远规划上给予支持。比如，学习一项新技能时，每天完成一点小目标，逐渐构建整个知识框架，最终达成难以企及的成就。
3. 把目光聚焦在核心小事上：我们可以让自行车棚效应集中在那些重要任务的小步骤上，而不是无关紧要的琐事上。这样可以在核心问题上逐步前进，确保每一步都为最终目标服务。
人们总是倾向于轻松、简单的选择，这种倾向并非一无是处。它给我们提供了积极的参与感、即时满足和短期成就感，只是我们需要学会如何合理利用这种心理机制。通过有意识地把注意力从琐事转移到更具价值的小目标上，最终可以从“纠结小事”变为“步步为营”，以小步成大成。
下次你在纠结一件小事或对网上的争论上头时，不妨停下来问问自己：“这真的重要吗？” 或许，通过把“自行车棚效应”转化为有利的工具，你会发现自己更愿意投入到那些真正重要的事物中，最终让生活和工作变得更加充实有意义。
最后，还有一个小妙招，是很多年前我不知道在哪里遇到，一直留着的一段话：
朋友们，我的一点切身经验，，如果你觉得某个任务让你特别焦虑，压得你喘不过气来，那么最好的排解方法就是直接去做这事，什么都别管，就是使劲做，努力地推进其进度，这棘手的事情在进度上每发展一点，你的焦虑就会少一分，同时你的焦虑越少，推进的速度也就越快，只要咬紧牙关，不停地推进，总会有解脱的那一天，而且你每完成一个棘手的任务，你或多或少都会比之前牛逼强大那么一点，这件苦差事总是会改变你一些。
2024-09-24 08:00:00
今天早上（严格说来是近中午了，醒的晚😂）在洗澡的时候，忽然觉得应该将「每天早上洗澡」这件事纳入日程中，因为这是难得的一段不会被打扰，不会使用电子设备，完全属于自己的时间。可以用这段时间做一些微小但又重要的事。
因为是发生不久的事，所以印象也还算深刻，可以回顾昨天哪些事做的比较好，哪些表现跟理想中的自己还有差距，应该如何改进。还可以回顾下昨天学到的一些知识点。
定期 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：一个低优进程（比如备份），总是被高优进程排挤，结果就是一直没得到运行的机会，一直处于饥饿状态。而洗澡为这些低优进程提供了运行条件，让它们不再挨饿。
