[{"content":"1231\n","date":"July 2, 2026","externalUrl":null,"permalink":"/posts/123131/","section":"文章","summary":"1231\n","title":"123131","type":"posts"},{"content":"这里会放我对工程、AI、系统设计和长期学习的记录。文字优先，页面保持安静。\n","date":"July 2, 2026","externalUrl":null,"permalink":"/","section":"Weiming","summary":"这里会放我对工程、AI、系统设计和长期学习的记录。文字优先，页面保持安静。\n","title":"Weiming","type":"page"},{"content":"新的文章会从 Decap CMS 写入这个栏目。\n","date":"July 2, 2026","externalUrl":null,"permalink":"/posts/","section":"文章","summary":"新的文章会从 Decap CMS 写入这个栏目。\n","title":"文章","type":"posts"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/categories/a/","section":"Categories","summary":"","title":"A","type":"categories"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/tags/%E6%B7%B1%E5%BA%A6%E5%B7%A5%E4%BD%9C/","section":"Tags","summary":"","title":"深度工作","type":"tags"},{"content":"作者：Cal Newport\n参考链接：Deep Work\nCal Newport 的《Deep Work》讨论的是现代知识工作者最稀缺的能力：在没有干扰的状态下，长时间处理认知要求高的问题。它不是普通时间管理书，也不是让人把每天塞得更满。它真正关心的是，在一个充满即时消息、社交媒体、会议、邮件和碎片任务的环境里，人怎样保住深度思考的能力。\n这本书适合放进博客导读系列，因为它和写作、编程、研究、学习都有直接关系。很多真正有价值的产出都需要深度：理解复杂系统，写清楚一篇文章，设计一个产品，解决一个难 bug，读懂一篇论文，形成自己的判断。浅层忙碌可以让人显得勤奋，但很难产生长期作品。\n深度工作是一种稀缺能力 # Newport 的核心判断是，深度工作在现代环境中越来越稀缺，也越来越有价值。一方面，工具和网络让分心变得极其容易。任何时候都有消息、推荐、热点、短视频、通知和新的网页。另一方面，真正能创造价值的工作越来越依赖复杂学习和高质量思考。也就是说，环境在削弱深度，而市场仍然奖励深度。\n这造成一个矛盾：很多人每天都在工作，却很少进入真正的工作状态。他们开会、回消息、整理文档、切换任务、浏览信息，晚上觉得很累，但很难指出今天完成了什么不可替代的产出。疲劳不等于深度，忙碌也不等于创造。\n深度工作的价值在于，它让人能处理超过当前舒适区的问题。学习新技术、写长文、构建系统、研究复杂概念，都需要持续注意力。没有深度，人只能停留在熟悉表面，难以跨过真正的能力门槛。\n浅层工作不是无用，但不能占满人生 # Newport 并不是说邮件、会议、沟通和日常事务都没有价值。浅层工作是很多组织运行的必要部分。问题在于，浅层工作有很强的扩张性。它容易被看见，容易被安排，容易给人即时完成感，也容易填满所有空隙。一旦不主动限制，深度工作就会被挤到疲惫后的边角时间。\n这对很多人很真实。白天最清醒的时间被消息和会议切碎，晚上才想起来要学习、写作或做长期项目。结果深度任务总是在低能量状态下开始，自然难以坚持。久而久之，人会误以为自己不适合深度工作，实际只是从来没有给它分配过足够好的资源。\n一个严肃的做法，是把深度工作当作日程中的主任务，而不是奖励或剩余项。先保护整块时间，再安排浅层事务。先处理真正需要脑力的任务，再用碎片时间处理消息。这个顺序看似简单，但会改变产出质量。\n注意力需要仪式和边界 # 深度工作不是靠意志力随时启动的。Newport 强调要建立固定规则：在哪里工作，工作多久，目标是什么，如何处理干扰，什么时候休息。仪式的价值在于减少启动成本。每次都重新决定，会消耗大量意志力；固定下来，就更容易进入状态。\n边界同样重要。现代工作环境默认每个人都应该即时可达，但深度工作需要暂时不可达。一个人如果任何时候都能被打断，就很难完成需要连续推理的任务。很多复杂问题不是因为单个步骤难，而是因为需要在脑中同时保持多个条件。一次打断就可能让整个思路坍塌。\n当然，边界需要现实地建立。不是所有岗位都能每天消失四小时，也不是所有团队都允许长时间不回复。但即使在约束很多的环境里，也可以争取小块稳定时间，关闭不必要通知，批量处理消息，提前说明专注时段。深度不是理想主义，而是一种需要主动保护的工作条件。\n深度工作和作品意识有关 # 这本书最打动我的地方，是它把注意力和作品联系起来。一个人长期做浅层工作，可能维持了运转，却很难留下可复用的成果。深度工作则更容易产生作品：文章、代码库、研究成果、课程、产品、方法论、设计方案。这些作品会在未来继续产生价值。\n个人博客就是深度工作的一个很好出口。写一篇真正有内容的导读，需要读、想、组织、表达、修改。它不会像刷信息流那样轻松，但完成后会留下一个可回看的思想节点。多篇文章积累起来，就会形成个人知识档案。\n这也是为什么深度工作不是单纯效率问题，而是人生结构问题。你把最好的注意力交给什么，最终就会成为什么样的人。如果长期把注意力交给碎片信息，你会变得擅长反应；如果长期把注意力交给复杂作品，你会变得擅长创造。\n对我自己的提醒 # 读《Deep Work》，我最想记住的是：注意力不是无限资源，不能随便交出去。每一次无意识刷新、每一次被通知牵走、每一次把清醒时间切碎，都会影响我处理复杂问题的能力。真正重要的工作需要我提前保护，而不是等世界安静下来。\n这本书也提醒我，不要用忙碌掩盖没有产出。如果一天结束时，我只处理了很多浅层事项，却没有推进任何长期作品，就应该诚实承认：这一天也许很累，但没有足够深。长期看，真正改变生活的往往不是回复了多少消息，而是完成了哪些可积累的作品。\n可以实践的清单 # 每天优先安排一段深度工作时间，放在精力最好的时段。 深度工作前写清楚目标，避免只是“学习一下”或“看看资料”。 批量处理消息和邮件，不让它们持续切割注意力。 为长期项目建立作品清单，用成果而不是忙碌衡量进展。 定期进行无网络或低干扰阅读，恢复长时间理解能力。 《Deep Work》在今天比出版时更重要。AI、短视频、社交平台和协作工具让信息流更强，也让深度更脆弱。一个人不可能完全退出现代环境，但可以为自己的注意力建立边界。深度工作不是怀旧，而是在噪音时代保住创造力的一种基本能力。\n","date":"May 18, 2026","externalUrl":null,"permalink":"/posts/cal-newport-deep-work-notes/","section":"文章","summary":"作者：Cal Newport\n参考链接：Deep Work\nCal Newport 的《Deep Work》讨论的是现代知识工作者最稀缺的能力：在没有干扰的状态下，长时间处理认知要求高的问题。它不是普通时间管理书，也不是让人把每天塞得更满。它真正关心的是，在一个充满即时消息、社交媒体、会议、邮件和碎片任务的环境里，人怎样保住深度思考的能力。\n这本书适合放进博客导读系列，因为它和写作、编程、研究、学习都有直接关系。很多真正有价值的产出都需要深度：理解复杂系统，写清楚一篇文章，设计一个产品，解决一个难 bug，读懂一篇论文，形成自己的判断。浅层忙碌可以让人显得勤奋，但很难产生长期作品。\n深度工作是一种稀缺能力 # Newport 的核心判断是，深度工作在现代环境中越来越稀缺，也越来越有价值。一方面，工具和网络让分心变得极其容易。任何时候都有消息、推荐、热点、短视频、通知和新的网页。另一方面，真正能创造价值的工作越来越依赖复杂学习和高质量思考。也就是说，环境在削弱深度，而市场仍然奖励深度。\n这造成一个矛盾：很多人每天都在工作，却很少进入真正的工作状态。他们开会、回消息、整理文档、切换任务、浏览信息，晚上觉得很累，但很难指出今天完成了什么不可替代的产出。疲劳不等于深度，忙碌也不等于创造。\n深度工作的价值在于，它让人能处理超过当前舒适区的问题。学习新技术、写长文、构建系统、研究复杂概念，都需要持续注意力。没有深度，人只能停留在熟悉表面，难以跨过真正的能力门槛。\n浅层工作不是无用，但不能占满人生 # Newport 并不是说邮件、会议、沟通和日常事务都没有价值。浅层工作是很多组织运行的必要部分。问题在于，浅层工作有很强的扩张性。它容易被看见，容易被安排，容易给人即时完成感，也容易填满所有空隙。一旦不主动限制，深度工作就会被挤到疲惫后的边角时间。\n","title":"重读 Cal Newport：深度工作","type":"posts"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/tags/%E6%B3%A8%E6%84%8F%E5%8A%9B/","section":"Tags","summary":"","title":"注意力","type":"tags"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/categories/s/","section":"Categories","summary":"","title":"S","type":"categories"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/tags/%E7%BC%96%E7%A8%8B%E6%95%99%E8%82%B2/","section":"Tags","summary":"","title":"编程教育","type":"tags"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/tags/%E5%B7%A5%E5%85%B7/","section":"Tags","summary":"","title":"工具","type":"tags"},{"content":"作者：Bret Victor\n原文链接：Learnable Programming\nBret Victor 的《Learnable Programming》不是普通的编程教程评论。它讨论的是一个更根本的问题：如果我们真的希望人学习编程，编程环境应该怎样帮助人理解程序？这篇文章的力量在于，它没有把学习困难简单归因于学习者不努力，而是把目光转向工具、反馈、表示方式和认知负担。\n很多编程入门材料默认学习者应该适应现有工具：看代码、猜运行结果、运行、报错、修改、再运行。Bret Victor 反过来问：为什么环境不能让学习者直接看见程序在做什么？为什么变量、状态、控制流、数据变化必须隐藏在文本背后？为什么初学者要把大量精力花在和抽象表示搏斗，而不是理解真正的编程概念？\n编程不是写符号，而是理解动态过程 # 编程最难的地方之一，是代码是静态文本，但程序是动态过程。初学者看到一段循环、条件、函数调用和变量赋值，需要在脑子里模拟它如何运行。经验丰富的人可以做到，因为他们已经建立了很多心理模型；初学者没有这些模型，只能猜。猜错时，错误信息又常常很不友好。\nBret Victor 认为，学习环境应该把程序的动态行为呈现出来。变量如何变化，循环如何推进，图形如何生成，输入如何影响输出，数据如何流动，这些都应该尽可能可见。可见不是为了炫酷，而是为了减少不必要的认知负担，让学习者把注意力放在概念上。\n这对今天的编程教育仍然重要。很多教程把重点放在语法和 API，却忽略学习者真正困惑的是“程序为什么这样运行”。如果没有可观察的反馈，学习就会变成记忆规则。记住规则可以过关，但很难形成直觉。\n即时反馈改变学习方式 # 文章里大量例子展示了即时反馈的价值。修改一个参数，画面立即变化；调整一段逻辑，结果马上呈现；程序和输出并排显示。这样的环境会鼓励探索。学习者不必每次都经历保存、运行、查错、切窗口的流程，而是可以用实验理解因果关系。\n即时反馈不是让学习变轻浮。相反，它能让学习更深入，因为它降低了试错成本。一个人可以快速提出假设、观察结果、修正理解。好的反馈会把“我不知道”变成“我可以试一下”。这对初学者非常重要，因为初学者最缺的不是资料，而是可控制的探索空间。\n这也解释了为什么很多优秀工具让人感觉“顺手”。顺手不是按钮少，而是反馈清晰。你做了什么，系统发生了什么，下一步可以怎样调整，都能被看见。工具越能缩短行动和结果之间的距离，越能帮助人建立直觉。\n工具不是中立的 # Bret Victor 的文章还有一个深层观点：工具会塑造思想。一个只提供文本编辑和终端输出的环境，会训练人用某种方式理解程序；一个提供可视化、直接操作和即时反馈的环境，会训练另一种理解方式。工具不是中立容器，它决定哪些想法容易表达，哪些想法难以看见。\n这对所有创作者都成立。写作工具会影响写作结构，笔记工具会影响知识组织，设计工具会影响界面想象，编程工具会影响程序思维。如果工具只让某些操作方便，用户就会更多做那些操作；如果工具让某些关系不可见，用户就更少思考那些关系。\n因此，改进工具不是表面优化，而是改进人的思考条件。一个好的编程环境应该帮助人看见抽象背后的结构，而不是要求人过早承担所有心理模拟。尤其在教育场景里，工具的责任更大，因为它不仅影响效率，还影响学习者是否能建立信心和直觉。\n可学习不等于低要求 # 有人可能会误解这类文章，以为可视化和即时反馈是降低门槛、让编程变得玩具化。实际上，Bret Victor 的要求更高。他不是要把编程简化成拖拽游戏，而是要让环境真正支持理解。可学习的系统不是去掉复杂概念，而是用更好的表示方式帮助人逐步接近复杂概念。\n好的教育工具应该既温柔又严格。温柔在于它不把无意义困难强加给学习者；严格在于它不回避真正的概念。比如变量、函数、状态、抽象、组合、调试，这些都不能消失。但它们可以通过更清晰的反馈、更直观的例子和更好的交互被理解。\n这对技术写作也有启发。写教程时，不应该只堆命令，而要让读者看见因果：为什么这样写？改一处会影响哪里？错误时如何判断？最终形成什么模型？一篇好教程本质上也是一个可学习环境，只不过媒介是文字。\n对我自己的提醒 # 读《Learnable Programming》，我最想记住的是：当一个人学不会时，不要第一时间归因于他不聪明或不努力。也许是环境没有给出足够好的反馈，也许是概念表示太绕，也许是教程让人记步骤却没有建立模型。好的学习设计应该减少无意义摩擦，让真正困难的部分显形。\n这篇文章也提醒我，作为开发者，要对自己的工具保持敏感。不要只接受默认环境，而要思考：它是否让我看见系统？是否让我更快验证想法？是否让我更容易发现错误？如果工具阻碍理解，就应该改进工作流，甚至自己做小工具。\n对博客来说，这篇导读也提醒我写技术文章时要多放“理解路径”。不是只给答案，而是解释从现象到原因、从修改到结果、从错误到定位的过程。这样文章才不只是说明书，而是帮助读者建立思考方式。\n可以实践的清单 # 学新概念时，尽量寻找能即时反馈的实验环境。 写教程时展示输入、变化、输出和错误定位过程。 不把语法记忆当成编程理解的全部。 评估工具时关注它是否帮助看见状态、数据流和因果关系。 为重复调试和观察任务制作小工具，降低试错成本。 《Learnable Programming》真正讨论的是人的理解权。编程不应该只属于能忍受糟糕工具的人。更好的环境可以让更多人接近计算思想，也可以让有经验的人更快看见复杂系统。它提醒我们：工具设计不是边角料，它直接影响我们能怎样思考。\n","date":"May 18, 2026","externalUrl":null,"permalink":"/posts/bret-victor-learnable-programming-notes/","section":"文章","summary":"作者：Bret Victor\n原文链接：Learnable Programming\nBret Victor 的《Learnable Programming》不是普通的编程教程评论。它讨论的是一个更根本的问题：如果我们真的希望人学习编程，编程环境应该怎样帮助人理解程序？这篇文章的力量在于，它没有把学习困难简单归因于学习者不努力，而是把目光转向工具、反馈、表示方式和认知负担。\n很多编程入门材料默认学习者应该适应现有工具：看代码、猜运行结果、运行、报错、修改、再运行。Bret Victor 反过来问：为什么环境不能让学习者直接看见程序在做什么？为什么变量、状态、控制流、数据变化必须隐藏在文本背后？为什么初学者要把大量精力花在和抽象表示搏斗，而不是理解真正的编程概念？\n编程不是写符号，而是理解动态过程 # 编程最难的地方之一，是代码是静态文本，但程序是动态过程。初学者看到一段循环、条件、函数调用和变量赋值，需要在脑子里模拟它如何运行。经验丰富的人可以做到，因为他们已经建立了很多心理模型；初学者没有这些模型，只能猜。猜错时，错误信息又常常很不友好。\nBret Victor 认为，学习环境应该把程序的动态行为呈现出来。变量如何变化，循环如何推进，图形如何生成，输入如何影响输出，数据如何流动，这些都应该尽可能可见。可见不是为了炫酷，而是为了减少不必要的认知负担，让学习者把注意力放在概念上。\n这对今天的编程教育仍然重要。很多教程把重点放在语法和 API，却忽略学习者真正困惑的是“程序为什么这样运行”。如果没有可观察的反馈，学习就会变成记忆规则。记住规则可以过关，但很难形成直觉。\n","title":"重读 Bret Victor：可学习的编程","type":"posts"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/tags/%E4%BA%A7%E5%93%81%E7%BB%8F%E7%90%86/","section":"Tags","summary":"","title":"产品经理","type":"tags"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/tags/%E8%B4%A3%E4%BB%BB/","section":"Tags","summary":"","title":"责任","type":"tags"},{"content":"作者：Ben Horowitz\n原文链接：Good Product Manager/Bad Product Manager\nBen Horowitz 的《Good Product Manager/Bad Product Manager》是一篇语气很硬的产品管理文章。它不像很多产品文章那样温和地讲用户、体验和协作，而是直接给出一组对照：好的产品经理如何行动，坏的产品经理如何找借口。它读起来甚至有点苛刻，但正因为苛刻，才把产品角色的责任边界讲得很清楚。\n这篇文章值得放进博客，是因为它不仅适用于产品经理，也适用于所有需要为结果负责的人。工程师、设计师、创业者、内容创作者，都可以从中看到一个核心问题：你是在拥有问题，还是只是在参与流程？你是在推动结果，还是在解释为什么结果不是你的责任？\n产品经理首先要拥有上下文 # 文章中最重要的标准之一，是好的产品经理理解上下文。他知道公司目标、用户需求、竞争格局、技术约束、收入模式、团队能力和时间压力。他不是只收集需求，也不是只写文档，而是在复杂约束中形成判断。\n这点很关键。很多产品问题不是缺少想法，而是缺少上下文。没有上下文的人很容易提出漂亮但不可执行的方案，也容易在用户、老板、销售、工程之间摇摆。每个人说得都有道理，但产品经理必须判断哪个道理在当前阶段最重要。\n拥有上下文意味着主动学习。你不能等别人把所有信息喂给你。你要看数据，听用户，理解技术，观察市场，知道团队为什么卡住，也知道业务真正靠什么成立。一个不了解上下文的人，即使沟通技巧很好，也很难做出可靠产品判断。\n好产品经理不把自己缩成传话筒 # 坏产品经理常见的问题，是把自己变成需求传递者。用户说什么，他转给工程；老板说什么，他写进排期；销售说什么，他要求插队。表面上他很忙，实际上没有进行产品判断。这样的角色会让团队越来越混乱，因为所有压力都被原样传递，没有人负责整合。\n好的产品经理应该把输入变成清晰问题。用户要的功能背后是什么场景？老板关心的指标背后是什么业务风险？销售提出的客户需求是否代表更大市场？工程担心的复杂度是否意味着方案需要重构？产品经理的价值就在于把不同语言翻译成一个可执行的产品方向。\n这也适用于写作和个人项目。一个人如果只是收集材料、复制观点、堆叠信息，就像传话筒。真正有价值的是判断：这些材料之间是什么关系？哪个问题最重要？我应该如何组织它，让读者获得新的理解？\n不找借口不是盲目背锅 # 这篇文章最容易被误读的地方，是“不找借口”。它不是要求产品经理为所有客观限制背锅，也不是鼓励组织压榨个人。它强调的是一种责任姿态：在承认现实限制的同时，仍然主动寻找可行路径，而不是把限制当作停止思考的理由。\n坏产品经理会说：工程资源不够，销售乱提需求，市场变化太快，竞争对手太强，老板没讲清楚。好产品经理也知道这些问题存在，但他会继续问：在资源不够的情况下，最小可行方案是什么？销售需求能否抽象成更通用能力？市场变化是否意味着定位要调整？竞争对手强在哪里，我们能否避开正面战场？\n这种态度和工程里的 ownership 很像。拥有问题的人不会停在“这不是我的错”。他会把错误信息、约束、风险和方案放到桌面上，推动团队做决定。当然，健康组织也必须给这种 ownership 配套权力和尊重，否则责任会变成单向压力。\n产品判断要转化成可执行计划 # 好的产品经理不能只会讲愿景。愿景必须落到需求优先级、功能边界、验收标准、发布时间、风险处理和团队沟通里。很多人擅长讲大方向，却不愿意处理细节；也有人沉迷细节，却不知道为什么要做。这两种都不够。\nBen Horowitz 强调产品经理要负责 devising and executing a winning plan。这里的关键词是计划和执行。计划不是写一堆功能列表，而是在有限资源下选择一条胜率最高的路径。执行也不是催进度，而是持续清除模糊、同步信息、处理冲突、根据反馈调整。\n一个好计划应该让团队知道：我们为什么做这个？不做什么？成功标准是什么？有哪些风险？如果时间不够砍哪里？如果用户反应不同如何判断？这些问题越早说清楚，团队浪费越少。\n对我自己的提醒 # 读这篇文章，我最想记住的是：不要用“参与了很多事”替代“真正负责一个结果”。参与很容易，负责很难。负责意味着主动理解上下文，做出判断，推动执行，并在结果不好时复盘自己的决策，而不是只证明自己当时很忙。\n这篇文章也提醒我，写博客和做产品有相似之处。每篇文章都应该有明确读者、明确问题和明确取舍。不能因为“资料很多”就全部堆进去，也不能因为“别人都这么写”就照搬结构。作者要像产品经理一样拥有内容的上下文，对读者的时间负责。\n可以实践的清单 # 做任何项目先写清楚上下文：目标、用户、约束、风险和成功标准。 不直接转发需求，先追问背后的真实问题。 遇到限制时提出可选方案，而不是只解释为什么做不了。 把愿景拆成边界清晰、可验收、可调整的计划。 每次项目结束复盘：哪些判断对了，哪些上下文漏了。 《Good Product Manager/Bad Product Manager》有一种早期硅谷文章的锋利感。它不完美，也可能显得过于强硬，但它抓住了产品角色的核心：产品经理不是会议组织者，不是需求书记员，也不是团队气氛维护者。好的产品经理是问题的拥有者，是上下文的整合者，是推动正确产品被做出来的人。\n","date":"May 18, 2026","externalUrl":null,"permalink":"/posts/ben-horowitz-good-product-manager-notes/","section":"文章","summary":"作者：Ben Horowitz\n原文链接：Good Product Manager/Bad Product Manager\nBen Horowitz 的《Good Product Manager/Bad Product Manager》是一篇语气很硬的产品管理文章。它不像很多产品文章那样温和地讲用户、体验和协作，而是直接给出一组对照：好的产品经理如何行动，坏的产品经理如何找借口。它读起来甚至有点苛刻，但正因为苛刻，才把产品角色的责任边界讲得很清楚。\n这篇文章值得放进博客，是因为它不仅适用于产品经理，也适用于所有需要为结果负责的人。工程师、设计师、创业者、内容创作者，都可以从中看到一个核心问题：你是在拥有问题，还是只是在参与流程？你是在推动结果，还是在解释为什么结果不是你的责任？\n产品经理首先要拥有上下文 # 文章中最重要的标准之一，是好的产品经理理解上下文。他知道公司目标、用户需求、竞争格局、技术约束、收入模式、团队能力和时间压力。他不是只收集需求，也不是只写文档，而是在复杂约束中形成判断。\n","title":"重读 Ben Horowitz：好产品经理，坏产品经理","type":"posts"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/tags/%E4%BA%A7%E5%93%81/","section":"Tags","summary":"","title":"产品","type":"tags"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/tags/%E7%A4%BE%E4%BA%A4%E7%BD%91%E7%BB%9C/","section":"Tags","summary":"","title":"社交网络","type":"tags"},{"content":"作者：Eugene Wei\n原文链接：Status as a Service\nEugene Wei 的《Status as a Service》是一篇理解社交平台的长文。它的核心观点很直接：很多社交网络不只是信息工具，也是在提供一种地位游戏。用户发布内容、获得关注、点赞、转发、评论和粉丝，不只是为了表达，也是在平台设定的规则里争夺可见的社会地位。\n这篇文章值得放进博客，是因为它能解释很多互联网现象：为什么有些平台能迅速增长，为什么有些内容格式会突然流行，为什么用户会被排行榜、粉丝数、点赞数牵引，为什么创作者既依赖平台又被平台消耗。它把社交产品从“连接人”进一步拆成“给人提供可竞争、可展示、可积累的地位”。\n社交网络也是地位市场 # 人类一直在意地位。过去地位竞争主要发生在小圈子里：学校、公司、社区、行业、朋友圈。互联网把这种竞争放大到了前所未有的规模。一个普通人可以突然面对巨大的潜在观众，也可以突然和无数陌生人比较。平台给出明确指标：粉丝、点赞、播放、收藏、转发、排名。这些指标让地位变得可见，也让焦虑变得可量化。\nEugene Wei 的洞察是，成功的社交平台往往创造了新的地位资产。早期 Twitter 让机智短句、实时评论和公共表达变成地位；Instagram 让视觉审美、生活方式和照片构图变成地位；TikTok 让短视频表演、剪辑节奏和算法适配能力变成地位。每个平台都在告诉用户：在这里，什么表现会被奖励。\n这也解释了为什么平台早期常常更有机会。新平台的地位阶梯还没有被占满，普通用户更容易通过掌握新语言获得上升空间。一旦平台成熟，头部账号占据注意力，新用户上升难度变大，地位游戏就会变得拥挤。\n工作量证明让地位更可信 # 文章中一个很有意思的概念，是社交平台需要某种“工作量证明”。如果地位太容易获得，它就不值钱；如果获得地位需要某种稀缺能力、努力或风险，用户才会相信它。不同平台的工作量证明不同：写出好段子、拍出好照片、跳好舞、做出专业分析、持续更新、快速跟热点、展示生活方式。\n这对产品设计很重要。一个平台不能只给用户一个发布框，还要设计一种让人愿意投入的游戏。投入越清晰，回报越可见，用户越容易沉迷。问题在于，这种机制既能激励创造，也能制造表演。创作者会逐渐学习平台奖励什么，并把自己改造成适合平台的形状。\n博客和社交平台的不同也在这里。博客的工作量证明更慢，不一定立刻获得点赞，但它更能积累深度和长期信用。社交平台奖励即时反应，博客奖励长期结构。两者都可以有价值，但如果一个人只在社交平台上写作，很容易被即时地位反馈牵着走。\n平台规则会塑造内容人格 # 每个平台都有自己的内容语法。字数限制、推荐算法、互动方式、转发结构、评论氛围、视觉比例，都会塑造用户表达。久而久之，用户不只是使用平台，而是在平台规则里训练自己。你会学会什么标题容易被点，什么观点容易被赞，什么情绪容易传播，什么复杂性应该省略。\n这对创作者是双刃剑。一方面，平台能让好内容被更多人看见；另一方面，平台会不断诱导创作者优化可见指标。一个人可能原本想写真实思考，后来慢慢变成写更容易传播的句子；原本想研究问题，后来变成维护人设；原本想表达复杂判断，后来变成输出立场符号。\nEugene Wei 的文章帮助我们看清，很多内容变化不是个人道德问题，而是激励系统问题。平台奖励什么，用户就会生产什么。理解这一点后，我们才能更清醒地使用平台，而不是把所有情绪都归因于“人变了”。\n地位游戏会消耗注意力 # 地位即服务最强大的地方，也是它最危险的地方。人天然在意他人评价，而平台把评价变成实时数据。你发出内容后，会不断刷新反馈；你看到别人增长，会不自觉比较；你知道什么内容容易火，就会犹豫是否继续写真正重要但不讨好的东西。\n这对个人成长很有杀伤力。长期创作需要安静、耐心和独立判断，而地位游戏鼓励即时反应和外部确认。不是说创作者不应该在意读者，而是不能让平台指标完全接管价值判断。很多重要文章在发布当天可能没有热度，但几年后仍然有价值；很多爆款内容很快就会过期。\n个人博客可以作为一种对冲。它没有平台那样强的即时反馈，也少了算法奖励，但它给作者保留了自己的目录、自己的节奏、自己的问题意识。博客不是反社交，而是给思想留一个不完全由平台地位定义的空间。\n对我自己的提醒 # 读《Status as a Service》，我最想记住的是：当我使用社交平台时，我不只是在消费内容，也是在进入某种地位游戏。平台不会强迫我追逐指标，但它会设计环境，让追逐指标变得自然。清醒的使用者需要知道自己何时在表达，何时在表演，何时在被反馈训练。\n这篇文章也提醒我，博客的价值恰恰在于慢。慢不是落后，而是另一种激励结构。它允许我写长一点，复杂一点，不那么迎合平台节奏。它让文章按主题和时间沉淀，而不是被信息流冲走。对一个想长期积累判断的人来说，这种空间很重要。\n可以实践的清单 # 使用社交平台前，明确自己是获取信息、分发内容，还是追逐反馈。 不把点赞、粉丝和播放量直接等同于内容价值。 把重要观点优先写进博客，再选择是否拆成社交平台内容。 定期检查自己是否为了平台奖励改变了表达方向。 建立不依赖平台指标的长期评价标准。 《Status as a Service》不是让人远离社交网络，而是帮助人理解社交网络的真实激励。平台提供连接，也提供地位；提供机会，也提供比较。只有看清这个结构，创作者才可能既利用平台，又不完全被平台定义。\n","date":"May 18, 2026","externalUrl":null,"permalink":"/posts/eugene-wei-status-as-a-service-notes/","section":"文章","summary":"作者：Eugene Wei\n原文链接：Status as a Service\nEugene Wei 的《Status as a Service》是一篇理解社交平台的长文。它的核心观点很直接：很多社交网络不只是信息工具，也是在提供一种地位游戏。用户发布内容、获得关注、点赞、转发、评论和粉丝，不只是为了表达，也是在平台设定的规则里争夺可见的社会地位。\n这篇文章值得放进博客，是因为它能解释很多互联网现象：为什么有些平台能迅速增长，为什么有些内容格式会突然流行，为什么用户会被排行榜、粉丝数、点赞数牵引，为什么创作者既依赖平台又被平台消耗。它把社交产品从“连接人”进一步拆成“给人提供可竞争、可展示、可积累的地位”。\n社交网络也是地位市场 # 人类一直在意地位。过去地位竞争主要发生在小圈子里：学校、公司、社区、行业、朋友圈。互联网把这种竞争放大到了前所未有的规模。一个普通人可以突然面对巨大的潜在观众，也可以突然和无数陌生人比较。平台给出明确指标：粉丝、点赞、播放、收藏、转发、排名。这些指标让地位变得可见，也让焦虑变得可量化。\nEugene Wei 的洞察是，成功的社交平台往往创造了新的地位资产。早期 Twitter 让机智短句、实时评论和公共表达变成地位；Instagram 让视觉审美、生活方式和照片构图变成地位；TikTok 让短视频表演、剪辑节奏和算法适配能力变成地位。每个平台都在告诉用户：在这里，什么表现会被奖励。\n","title":"重读 Eugene Wei：地位即服务","type":"posts"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/categories/s++/","section":"Categories","summary":"","title":"S++","type":"categories"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/tags/%E5%A4%8D%E6%9D%82%E6%80%A7/","section":"Tags","summary":"","title":"复杂性","type":"tags"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/tags/%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B/","section":"Tags","summary":"","title":"软件工程","type":"tags"},{"content":"作者：Fred Brooks\n原文链接：No Silver Bullet\nFred Brooks 的《No Silver Bullet》是软件工程领域最重要的文章之一。它讨论的问题到今天仍然存在：为什么软件开发很难？为什么新语言、新工具、新方法、新流程总是承诺巨大提升，却很少真正消除软件项目的根本困难？Brooks 的答案是，软件复杂性分为本质复杂度和偶然复杂度。工具可以减少偶然复杂度，但很难消灭本质复杂度。\n这篇文章适合每个程序员读，尤其适合在技术热潮中读。每隔几年，行业都会出现新的“银弹”：可视化开发、面向对象、微服务、低代码、云原生、区块链、AI 编程助手。它们有些确实有用，甚至非常有用，但如果把它们想象成能自动解决软件工程困难的魔法，就会重演 Brooks 批评的错误。\n本质复杂度来自问题本身 # Brooks 所说的本质复杂度，来自软件要表达现实世界的复杂需求。软件不是重复制造同一个物理零件，而是在不断描述规则、状态、边界、例外、协作和变化。一个业务系统难，不只是因为代码难写，而是因为业务本身有很多相互牵制的概念：权限、流程、异常、历史数据、用户习惯、组织责任、法规约束、性能要求。\n这类复杂度不能靠换语言完全消除。你可以用更好的框架让代码更简洁，可以用更强的工具减少样板，可以用 AI 帮你生成初稿，但需求之间的矛盾仍然要有人理解。什么情况应该允许？什么情况必须拒绝？旧数据如何兼容？失败时谁负责？这些问题属于系统本身，不会因为语法变漂亮而消失。\n很多项目失败，不是因为程序员不会写代码，而是因为团队低估了本质复杂度。他们以为需求已经清楚，实际只是没人追问细节；他们以为流程已经确定，实际只是异常没有被讨论；他们以为引入新架构就能变简单，实际只是把复杂性从代码搬到了部署、监控和协作里。\n偶然复杂度值得减少，但不要误判收益 # 偶然复杂度是工具、语言、环境和流程带来的额外困难。早期编程需要处理机器细节，后来高级语言、交互式环境、调试器、包管理、自动化测试、云平台都减少了很多偶然复杂度。这些进步非常重要。Brooks 并不是说工具没用，而是说工具的收益有边界。\n今天我们仍然应该积极减少偶然复杂度。重复手工部署应该自动化，难懂的配置应该简化，脆弱流程应该测试，复杂样板应该生成，低价值劳动应该交给工具。问题在于，不要把减少偶然复杂度误认为解决了全部工程困难。\n比如 AI 编程助手能显著提高写代码速度，但它不自动保证需求正确、架构合适、权限安全、数据一致、长期可维护。它减少的是部分输入成本和样板成本，却没有替代系统理解。团队如果把生成速度当成全部生产力，可能会更快地产生更多需要维护的复杂系统。\n软件难在概念完整性 # Brooks 在很多作品里都强调概念完整性。一个软件系统要好，不只是功能多，而是内部概念一致，用户理解成本低，设计取舍清楚。概念完整性很难通过堆人、堆工具、堆流程获得。它需要少数人对系统有清晰判断，也需要团队愿意为了清晰拒绝一些看似方便的杂乱需求。\n这也是为什么软件项目不能只用代码量衡量。很多真正重要的工作发生在写代码之前：理解需求，澄清概念，删除不必要功能，统一模型，决定边界。一个优秀工程师的价值不只是更快实现，而是能减少系统未来的混乱。\n如果一个团队没有概念完整性，再强的工具也会生成混乱。代码可以很现代，架构可以很流行，界面可以很漂亮，但用户仍然觉得难用，开发者仍然觉得难改。因为真正的问题不是技术栈落后，而是系统没有一个清楚的思想。\n银弹思维的危险 # 银弹思维最危险的地方，是让人逃避困难的本质。遇到复杂项目时，人很容易希望某个新技术替自己解决痛苦。换框架、换语言、换平台、换流程、换组织形式，这些有时必要，但也可能只是把注意力从需求理解和系统设计上移开。\n软件行业尤其容易被银弹吸引，因为工具进步确实很快。每个新工具都会展示一个漂亮的最佳路径，但真实项目通常充满遗留系统、模糊需求、有限预算、团队差异和历史包袱。工具演示里没有这些东西，现实里全都是这些东西。\n成熟的态度不是拒绝新工具，而是问清楚：它解决的是哪类偶然复杂度？它会引入哪些新的复杂度？它对本质复杂度有什么帮助？如果问题主要是需求不清、概念混乱、组织目标冲突，那么换工具只能缓解症状，不能解决根因。\n对我自己的提醒 # 读《No Silver Bullet》，我最想记住的是：不要把痛苦自动归因于工具不够好。工具当然可以更好，但很多痛苦来自我还没有理解问题本身。越是复杂的系统，越需要慢下来澄清概念、边界和取舍。\n这篇文章也提醒我，在使用 AI 和现代框架时保持清醒。它们能让我更快到达某个实现，但不能替我判断这个实现是否应该存在。真正难的问题仍然是：用户到底要什么？系统应该怎样建模？哪些复杂度可以删除？哪些复杂度必须面对？失败时如何恢复？长期维护由谁承担？\n把 Brooks 放进博客里，是为了给所有技术热情加一个刹车。热情很重要，但没有复杂度意识的热情会制造更多复杂度。好的工程不是寻找一次性魔法，而是持续区分什么可以自动化，什么必须理解。\n可以实践的清单 # 遇到技术痛苦时，先区分它是偶然复杂度还是本质复杂度。 引入新工具前写下它具体减少哪类成本，以及会增加哪类成本。 在编码前花时间统一业务概念和边界条件。 用删除功能、简化模型、澄清流程来减少本质复杂度。 对“十倍提升”“彻底解决”“无需理解底层”这类承诺保持警惕。 《No Silver Bullet》不是悲观文章。它反而让人更务实：软件工程不会被单一突破拯救，但可以通过很多扎实改进持续变好。减少偶然复杂度，尊重本质复杂度，建立概念完整性，这比追逐银弹更慢，却更可靠。\n","date":"May 18, 2026","externalUrl":null,"permalink":"/posts/fred-brooks-no-silver-bullet-notes/","section":"文章","summary":"作者：Fred Brooks\n原文链接：No Silver Bullet\nFred Brooks 的《No Silver Bullet》是软件工程领域最重要的文章之一。它讨论的问题到今天仍然存在：为什么软件开发很难？为什么新语言、新工具、新方法、新流程总是承诺巨大提升，却很少真正消除软件项目的根本困难？Brooks 的答案是，软件复杂性分为本质复杂度和偶然复杂度。工具可以减少偶然复杂度，但很难消灭本质复杂度。\n这篇文章适合每个程序员读，尤其适合在技术热潮中读。每隔几年，行业都会出现新的“银弹”：可视化开发、面向对象、微服务、低代码、云原生、区块链、AI 编程助手。它们有些确实有用，甚至非常有用，但如果把它们想象成能自动解决软件工程困难的魔法，就会重演 Brooks 批评的错误。\n本质复杂度来自问题本身 # Brooks 所说的本质复杂度，来自软件要表达现实世界的复杂需求。软件不是重复制造同一个物理零件，而是在不断描述规则、状态、边界、例外、协作和变化。一个业务系统难，不只是因为代码难写，而是因为业务本身有很多相互牵制的概念：权限、流程、异常、历史数据、用户习惯、组织责任、法规约束、性能要求。\n","title":"重读 Fred Brooks：没有银弹","type":"posts"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/categories/s+/","section":"Categories","summary":"","title":"S+","type":"categories"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/tags/%E6%8A%BD%E8%B1%A1/","section":"Tags","summary":"","title":"抽象","type":"tags"},{"content":"作者：Joel Spolsky\n原文链接：The Law of Leaky Abstractions\nJoel Spolsky 的《The Law of Leaky Abstractions》是程序员世界里非常经典的一篇文章。它讲了一个看似简单、却经常被忽略的事实：所有非平凡抽象都会泄漏。框架、库、协议、语言、数据库、云服务、可视化工具，都在试图隐藏复杂性，但复杂性不会真的消失。某些时候，被隐藏的底层细节会突然冒出来，迫使你理解它。\n这篇文章适合技术博客，是因为它能解释很多学习和工程中的挫败感。新手常常以为自己只要学会一个高级工具，就可以跳过底层；团队也常常以为引入一个平台，就能消除复杂性。结果一旦系统出问题，抽象边界开始破裂，大家才发现自己并不知道网络、文件系统、数据库事务、构建流程或运行时到底发生了什么。\n抽象提高效率，但不消灭现实 # 软件工程离不开抽象。没有抽象，我们不可能写大型系统。高级语言隐藏机器码，操作系统隐藏硬件细节，数据库隐藏磁盘和索引，HTTP 框架隐藏套接字，ORM 隐藏 SQL，云平台隐藏服务器。每一层抽象都让人可以在更高层次上思考问题。\n但抽象的代价是，它会让人误以为底层不存在。平时一切顺利时，这种错觉很舒服。你调用一个 API，它返回结果；你部署一个应用，它自动扩容；你使用一个组件，它正常渲染。直到延迟升高、连接中断、事务死锁、缓存不一致、内存泄漏、构建失败、边界条件错乱，底层现实才重新出现。\nJoel 的提醒不是反对抽象，而是反对幼稚地相信抽象。好的工程师需要享受抽象带来的生产力，同时保留向下钻取的能力。你不必每天手写 TCP，也不必拒绝框架，但你应该知道当抽象失效时，应该往哪一层看。\n工具越高级，越需要理解边界 # 今天这个问题比 2002 年更明显。现代开发者拥有更强的框架、更自动化的部署、更复杂的依赖管理、更智能的 IDE 和 AI 编程助手。它们让很多事情变快，也让很多底层过程更不可见。不可见不等于不存在。越是依赖高级工具，越需要知道它们的边界在哪里。\n比如前端框架让状态更新看起来很自然，但渲染、闭包、缓存、异步请求和 hydration 的细节仍然会泄漏。数据库 ORM 让查询像对象操作，但索引、连接、锁、N+1 查询和事务隔离仍然会泄漏。云服务让部署像点击按钮，但冷启动、区域、权限、网络、账单和限制仍然会泄漏。AI 代码生成让样板代码更快出现，但需求理解、边界条件、安全和维护责任仍然会泄漏。\n所以学习技术不能只学“如何调用”。还要学“它隐藏了什么”。一个真正掌握工具的人，知道正常路径，也知道异常路径；知道抽象提供了什么，也知道抽象不承诺什么。这种边界感，是高级工程判断的重要组成部分。\n抽象泄漏解释了为什么基础仍然重要 # 很多人学习编程时会纠结：我到底要不要学底层？要不要学网络、操作系统、数据结构、编译、数据库原理？Joel 这篇文章给了一个务实答案：你不需要为了仪式感学习底层，但你需要为了解决抽象泄漏学习底层。\n当一切顺利时，基础知识看起来没用。会调 API 就能做页面，会用框架就能上线应用，会复制配置就能跑服务。但真正的工程问题往往出现在不顺利时。为什么这个请求偶尔很慢？为什么本地正常线上失败？为什么数据重复写入？为什么构建结果和预期不一致？为什么用户量上来之后系统崩了？这些问题很少能靠更熟练地点击界面解决。\n基础知识的价值，不在于让你显得专业，而在于给你排查问题的地图。你知道系统分成哪些层，每层可能出现什么问题，现象如何传递，应该用什么证据验证。没有这张地图，人就只能盲目重试、搜索报错、复制答案。短期可能有效，长期会越来越脆弱。\n抽象也会影响团队协作 # 抽象泄漏不只是个人学习问题，也是团队协作问题。一个团队如果过度相信某个平台或框架，就会把很多重要知识外包出去。开始时效率很高，后来一旦遇到复杂需求或生产事故，就发现没人真正理解系统。大家只能在抽象表面讨论，无法进入问题内部。\n好的团队会有意识地记录抽象边界。比如：这个组件负责什么，不负责什么；这个缓存在哪些情况下会失效；这个 API 的幂等性如何保证；这个部署平台有哪些限制；这个主题下哪些问题应该看日志，哪些应该看指标，哪些应该看数据库。文档不是为了形式，而是为了让团队在抽象泄漏时能快速恢复理解。\n这也解释了为什么工程博客里的复盘很有价值。它们往往记录了抽象泄漏的真实过程：看似简单的功能，为什么被底层约束改变；看似可靠的服务，为什么在边界条件下失败；看似优雅的架构，为什么在组织现实中变形。这些材料比纯教程更能训练工程判断。\n对我自己的提醒 # 读 Joel 这篇文章，我最想记住的是：不要把工具的顺滑误认为问题的简单。一个工具越好用，越容易让我忘记它背后隐藏的复杂性。真正成熟的使用方式，是在享受便利的同时，保持对底层的尊重。\n这也提醒我学习新技术时要改变提问方式。除了问“怎么用”，还要问：它抽象了什么？它在哪些情况下会失效？它的错误信息意味着哪一层出问题？如果不用它，底层原本需要我做什么？这些问题会让学习变慢一点，但理解会更稳。\n在 AI 编程越来越普遍的今天，这个提醒更重要。AI 可以生成代码，但不能替我承担系统后果。如果我看不懂生成代码背后的抽象和边界，我就只是把复杂性推迟到未来某次故障里。\n可以实践的清单 # 学一个框架时，同时了解它隐藏的底层机制。 遇到问题时先判断属于哪一层：业务、框架、运行时、网络、数据库、系统。 不盲目复制配置，至少弄清关键配置项解决的是什么约束。 为团队文档记录抽象边界和常见泄漏场景。 使用 AI 生成代码后，主动追问每个依赖和关键调用的失败模式。 《The Law of Leaky Abstractions》之所以经典，是因为它说出了工程世界的一个朴素真相：复杂性不会因为我们命名了一个漂亮接口就消失。抽象是必要的，但理解抽象的泄漏同样必要。好的工程师不是拒绝高级工具的人，而是在工具失效时仍然知道现实在哪里的人。\n","date":"May 18, 2026","externalUrl":null,"permalink":"/posts/joel-spolsky-leaky-abstractions-notes/","section":"文章","summary":"作者：Joel Spolsky\n原文链接：The Law of Leaky Abstractions\nJoel Spolsky 的《The Law of Leaky Abstractions》是程序员世界里非常经典的一篇文章。它讲了一个看似简单、却经常被忽略的事实：所有非平凡抽象都会泄漏。框架、库、协议、语言、数据库、云服务、可视化工具，都在试图隐藏复杂性，但复杂性不会真的消失。某些时候，被隐藏的底层细节会突然冒出来，迫使你理解它。\n这篇文章适合技术博客，是因为它能解释很多学习和工程中的挫败感。新手常常以为自己只要学会一个高级工具，就可以跳过底层；团队也常常以为引入一个平台，就能消除复杂性。结果一旦系统出问题，抽象边界开始破裂，大家才发现自己并不知道网络、文件系统、数据库事务、构建流程或运行时到底发生了什么。\n抽象提高效率，但不消灭现实 # 软件工程离不开抽象。没有抽象，我们不可能写大型系统。高级语言隐藏机器码，操作系统隐藏硬件细节，数据库隐藏磁盘和索引，HTTP 框架隐藏套接字，ORM 隐藏 SQL，云平台隐藏服务器。每一层抽象都让人可以在更高层次上思考问题。\n","title":"重读 Joel Spolsky：抽象泄漏定律","type":"posts"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/tags/%E4%BB%B7%E5%80%BC%E8%A7%82/","section":"Tags","summary":"","title":"价值观","type":"tags"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/tags/%E5%86%B3%E7%AD%96/","section":"Tags","summary":"","title":"决策","type":"tags"},{"content":"作者：Clayton M. Christensen\n原文链接：How Will You Measure Your Life?\nClayton Christensen 的《How Will You Measure Your Life?》是一篇很特别的文章。它来自一位以“颠覆式创新”理论闻名的管理学者，但讨论的不是公司如何增长，而是一个人如何衡量自己的一生。它的力量在于把商业理论从公司带回个人生活，让人意识到：人生也会被资源分配、短期指标、错误激励和小的妥协慢慢塑形。\n这篇文章适合放进个人博客，因为它不只是讲成功，也讲代价。很多职业建议默认人生目标是更高职位、更大影响、更强收入，但 Christensen 问的是另一个问题：当你回头看时，你会用什么标准判断这一生是否值得？如果衡量标准错了，即使在外部指标上赢了，也可能在真正重要的地方失败。\n人生会被你实际投入的资源定义 # 文章里最关键的思想之一，是不要只看自己口头上重视什么，要看时间、精力、金钱和注意力实际流向哪里。公司战略不是写在 PPT 上的愿景，而是资源真实分配的结果；个人生活也一样。你说家庭重要，但每天最好的精力都给了工作和手机；你说健康重要，但从不安排运动和睡眠；你说成长重要，但只把碎片时间留给学习。长期结果会相信行动，不会相信口号。\n这个观点很冷酷，也很有用。它把人生从抽象愿望拉回日程表。很多人不是没有价值观，而是没有把价值观变成资源配置。短期看，把更多时间给工作可能有清晰回报：奖金、认可、晋升、成就感。把时间给关系、健康、阅读和长期能力，回报慢得多，也不一定有人看见。于是短期系统不断赢，长期系统不断输。\nChristensen 的提醒是：长期重要的东西通常不会大声催你。孩子不会像客户一样发工单，身体不会像老板一样开周会，亲密关系不会像项目进度一样每天亮红灯。等它们真正报警时，往往已经积累了很久的问题。所以人必须主动为长期重要的事分配资源。\n错误指标会制造错误人生 # 商业世界里，指标会塑造行为。一个公司如果只看短期利润，可能牺牲研发、质量和人才；如果只看增长，可能忽视用户信任和现金流。个人也一样。如果你衡量自己的主要指标是收入、头衔、外部认可和忙碌程度，你自然会选择能快速提升这些指标的行动。\n问题在于，很多真正重要的人生结果无法短期量化。一个人的品格、关系质量、长期可信度、内在平静、对孩子的影响，都很难像业绩一样被季度评估。于是它们容易被忽略。不是因为它们不重要，而是因为它们不够“吵”。\n这对现代人尤其危险。社交媒体进一步强化了可展示指标：去过哪里、买了什么、职位如何、阅读了多少、项目多大。一个人如果没有自己的衡量标准，就会不自觉地接受平台和社会提供的默认标准。最后活得很忙，但不一定活得像自己。\n关系需要持续投资，而不是危机修复 # Christensen 特别强调家庭和亲密关系。他不是从道德说教角度讲，而是从资源分配和长期回报角度讲。关系的复利非常慢，也非常真实。你不能在长期忽视之后，突然用一次补偿修复所有东西。关系需要日常投入，需要在对方还没有“出问题”时就认真对待。\n这点很容易被职业上升期的人忽视。工作给人的反馈更快，关系给人的反馈更慢；工作成就更容易被外界承认，家庭投入常常没有掌声。于是很多人把关系当成稳定背景，认为它会一直在那里。直到有一天才发现，关系不是背景，而是需要共同维护的系统。\n这里的启发不是让人反工作，也不是让人放弃事业。更准确的说法是：不要让事业长期吞掉所有优质资源。一个人可以努力工作，也可以追求成就，但如果他从不为重要关系预留最好的注意力，那么他实际上已经选择了另一种人生衡量方式。\n原则最容易在小事上失守 # 文章中另一个重要提醒，是不要以为“只这一次”的妥协会停在这一次。很多严重后果并不是从巨大错误开始，而是从一个看似合理的小例外开始。第一次为了方便违背原则，第二次就更容易，第三次就变成习惯。人不是突然变成某种人，而是在重复选择中慢慢成为某种人。\n这对职业生活很现实。第一次夸大数据，第一次隐瞒风险，第一次为了短期结果牺牲用户，第一次明知不对仍然沉默，都可能被解释为特殊情况。但原则的意义恰恰在于困难时仍然有效。如果原则只在没有代价时才坚持，它就不是原则，只是偏好。\nChristensen 的观点不是要人僵硬，而是要人明白小妥协的复利。人生很多地方不是线性账本，而是路径依赖。你今天选择的例外，会改变明天做选择的自己。长期看，品格就是这些小选择留下的痕迹。\n把管理理论用回自己身上 # 这篇文章最有意思的地方，是它把组织理论变成个人反思工具。公司会被资源分配塑造，个人也会；公司会被错误指标诱导，个人也会；公司会因为忽视长期能力而衰退，个人也会。管理学不只是管理别人，也可以管理自己的人生系统。\n如果把自己看成一个长期系统，就会提出更好的问题：我的时间投入是否和价值观一致？我是否过度优化短期可见指标？我是否忽视了无法立刻反馈但长期关键的关系？我是否在小事上训练自己违背原则？这些问题比“我是不是更成功”更具体，也更难逃避。\n对博客来说，这类文章适合成为定期回看的镜子。博客不应该只记录外部世界，也应该记录自己如何衡量生活。一个人如果长期写下自己的判断，就更容易发现自己是否偏离了最初认为重要的东西。\n对我自己的提醒 # 读完这篇文章，我最想记录的是：人生的真实战略藏在日程表里。不要只写愿景，不要只说重视什么，要看我把清醒的时间、最好的注意力、最稳定的耐心给了谁、给了什么事。如果它们长期流向短期指标，我就不能假装自己在追求长期价值。\n这篇文章也让我警惕“以后再说”。以后再陪家人，以后再锻炼，以后再读书，以后再做真正想做的事。很多东西确实可以等，但有些东西等太久就会变质。关系、身体、原则和内在方向，都需要在还没有紧急时就投入。\n可以实践的清单 # 每周回看时间分配，检查它是否反映真实价值观。 为家庭、健康和长期学习预留固定时间，不只使用剩余时间。 写下自己衡量人生的三个标准，并定期校准。 遇到“只这一次”的原则例外时，先停下来记录原因。 少用外部掌声判断人生进展，多看长期关系和内在秩序。 《How Will You Measure Your Life?》不是一篇让人降低事业追求的文章。它更像是在提醒：事业只是人生系统的一部分。如果一个人没有自己的衡量标准，外部世界会很快替他提供一套。问题是，那套标准未必会在生命结束时仍然成立。\n","date":"May 18, 2026","externalUrl":null,"permalink":"/posts/clayton-christensen-measure-your-life-notes/","section":"文章","summary":"作者：Clayton M. Christensen\n原文链接：How Will You Measure Your Life?\nClayton Christensen 的《How Will You Measure Your Life?》是一篇很特别的文章。它来自一位以“颠覆式创新”理论闻名的管理学者，但讨论的不是公司如何增长，而是一个人如何衡量自己的一生。它的力量在于把商业理论从公司带回个人生活，让人意识到：人生也会被资源分配、短期指标、错误激励和小的妥协慢慢塑形。\n这篇文章适合放进个人博客，因为它不只是讲成功，也讲代价。很多职业建议默认人生目标是更高职位、更大影响、更强收入，但 Christensen 问的是另一个问题：当你回头看时，你会用什么标准判断这一生是否值得？如果衡量标准错了，即使在外部指标上赢了，也可能在真正重要的地方失败。\n人生会被你实际投入的资源定义 # 文章里最关键的思想之一，是不要只看自己口头上重视什么，要看时间、精力、金钱和注意力实际流向哪里。公司战略不是写在 PPT 上的愿景，而是资源真实分配的结果；个人生活也一样。你说家庭重要，但每天最好的精力都给了工作和手机；你说健康重要，但从不安排运动和睡眠；你说成长重要，但只把碎片时间留给学习。长期结果会相信行动，不会相信口号。\n","title":"重读 Christensen：你将如何衡量你的人生","type":"posts"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/tags/%E7%9F%A5%E8%AF%86%E5%B7%A5%E4%BD%9C/","section":"Tags","summary":"","title":"知识工作","type":"tags"},{"content":"作者：Peter F. Drucker\n原文链接：Managing Oneself\nDrucker 的《Managing Oneself》是少数真正能穿过时代变化的职业文章。它没有讲简历技巧，也没有教人怎样在组织里讨巧。它讨论的是更底层的问题：在知识工作时代，一个人必须学会把自己当作一项长期资产来管理。你要知道自己的优势、工作方式、价值观、适合的位置，以及你能贡献什么。\n这篇文章之所以经典，是因为它把职业发展从“公司安排我”转成“我必须理解自己”。工业时代的很多人可以依靠组织路径生活：进入公司，服从岗位，按资历晋升，退休结束。但知识工作者的寿命、技能周期和组织变化都更复杂。你可能多次换行业、换角色、换协作方式。没有人能替你长期管理这些选择。\n先理解自己的优势 # Drucker 最核心的建议之一，是人应该把主要精力放在优势上，而不是幻想把所有短板补齐。这里的优势不是“我喜欢什么”，也不是“我自我感觉不错”，而是通过反馈分析逐渐确认：哪些事情我做了之后真的有结果？哪些判断后来被证明可靠？哪些能力在不同场景下反复产生价值？\n很多人的自我认识其实很不可靠。我们容易高估自己擅长的事，也容易被外部评价牵着走。有人因为一次表扬就觉得自己适合某方向，也有人因为一次失败就放弃真正有潜力的能力。Drucker 的方法更冷静：记录预期，等待结果，再比较差异。长期下来，你会看到自己真实的强项和盲点。\n这对博客作者也有帮助。你可以通过写作观察自己：哪些主题你能写得深入？哪些文章后来仍然愿意回看？哪些观点能帮助你做出更好决策？哪些领域你只是跟风？公开写作会暴露一个人的理解深度，也会留下长期反馈。博客不只是展示，也是一种自我诊断工具。\n工作方式比努力方式更具体 # Drucker 还提醒人们，不同人有不同的工作方式。有的人通过阅读学习，有的人通过听和讨论学习；有的人适合独立深思，有的人适合在互动中形成判断；有的人适合做决策者，有的人适合做顾问；有的人在结构清晰的组织里表现好，有的人在混乱探索中更有价值。\n这听起来像常识，但很多痛苦就来自忽视常识。一个需要安静长时间思考的人，可能被放进全天会议和即时响应的环境；一个擅长启动项目的人，可能被要求长期维护流程；一个靠写作理清思路的人，可能被迫只通过口头汇报表达。结果不是这个人不努力，而是工作方式和环境长期冲突。\n认识工作方式不是为了逃避困难，而是为了减少无谓摩擦。每个人都要适应现实，但适应不等于否认自己的系统。一个人如果知道自己需要整块时间，就应该主动保护日程；如果知道自己容易在口头讨论中漏掉细节，就应该提前写文档；如果知道自己在开放问题上更强，就不必把全部人生押在高度重复的岗位上。\n价值观决定你能不能长期投入 # 这篇文章很重要的一点，是把价值观放进职业管理。Drucker 认为，如果一个人的价值观和组织价值观长期冲突，即使能力匹配，也很难真正发挥。价值观不是漂亮口号，而是你愿意为什么付出代价，你无法接受什么交换，你希望自己的工作最终服务于什么。\n很多职业选择失败，并不是因为薪水不够，也不是因为能力不足，而是因为价值观不兼容。有人重视质量，却长期处在只关心速度和包装的环境；有人重视诚实，却长期被要求模糊事实；有人重视长期积累，却长期被短期指标牵引。短期可以忍，长期会消耗掉一个人的判断和尊严。\n这并不意味着人要幼稚地追求完美组织。所有组织都有妥协，所有工作都有不舒服的部分。关键在于分清普通摩擦和根本冲突。如果只是流程不顺，可以优化；如果每天都在违背自己最重要的价值，那就不是简单的职业问题，而是人生方向问题。\n贡献意识比职位意识更重要 # Drucker 建议知识工作者不断问：“我应该贡献什么？”这个问题比“我想得到什么职位”更有力量。职位是组织给你的标签，贡献是你实际改变了什么。一个人如果只盯着职位，很容易陷入比较和焦虑；如果盯着贡献，就会更关注自己能解决的问题、服务的人和创造的结果。\n贡献意识也能让人更好地理解协作。你不是在证明自己忙，也不是在证明自己聪明，而是在帮助一个系统变得更好。好的工程师贡献可靠系统，好的产品经理贡献清晰判断，好的写作者贡献可复用的理解，好的管理者贡献让他人发挥的环境。不同角色的贡献不同，但都应该能被说清楚。\n对个人博客来说，也可以问同样的问题：这篇文章贡献了什么？它只是复述一个热门观点，还是把一个复杂问题讲清楚了？它只是表达情绪，还是留下了未来能使用的判断？如果每篇文章都能回答这个问题，博客的质量会慢慢提高。\n后半生需要第二曲线 # Drucker 很早就看到，现代人的工作寿命可能比单一组织或单一技能的寿命更长。一个人不能只靠前半生的一次选择过完全部职业。他需要发展第二领域、第二曲线、第二种贡献方式。这个观点在今天更明显：技术更替、行业变化、AI 工具和组织结构都会改变原有岗位。\n第二曲线不是突然转行，而是提前培养。写作、教学、开源、咨询、独立产品、研究兴趣、社群贡献，都可能成为未来的延展。关键是不要等到原有路径耗尽才开始。一个人如果长期只做岗位要求的最低闭环，就很容易在环境变化时失去弹性。\n博客在这里也有实际价值。它能积累公开作品、训练表达、沉淀专业判断，并把隐性的经验变成可被别人理解的资产。多年以后，博客可能不是直接带来机会，但它会证明你长期思考过什么，解决过什么，形成了什么判断。\n对我自己的提醒 # 读《Managing Oneself》，我最想记住的是：自我管理不是自我感动，而是持续校准。知道自己是谁，不是坐在那里想出来的，而是通过行动、反馈、结果和复盘慢慢看见的。一个人既不能完全听从外部评价，也不能完全相信自我想象。他需要证据。\n这篇文章也提醒我，不要把职业发展交给惯性。公司不会替我管理一生，行业也不会保证旧技能永远有效。我要主动理解自己的优势，选择更匹配的环境，保护重要价值观，并不断问自己能贡献什么。这样看，博客不是副业装饰，而是管理自己的工具之一。\n可以实践的清单 # 每做一个重要选择前写下预期，几个月后回看结果。 记录自己在哪些任务里最容易产生高质量结果。 明确自己的工作方式：读、写、说、独立、协作，各自怎样发挥最好。 写下不能长期违背的价值观，避免用短期收益交换核心原则。 每半年问一次：我现在真正贡献的是什么？ Drucker 的文章没有提供简单答案，但它给了一个很成熟的框架。管理自己不是变得更会包装，而是更诚实地认识优势、限制、价值和责任。一个人越早开始这件事，越不容易把人生交给组织惯性和外部噪音。\n","date":"May 18, 2026","externalUrl":null,"permalink":"/posts/peter-drucker-managing-oneself-notes/","section":"文章","summary":"作者：Peter F. Drucker\n原文链接：Managing Oneself\nDrucker 的《Managing Oneself》是少数真正能穿过时代变化的职业文章。它没有讲简历技巧，也没有教人怎样在组织里讨巧。它讨论的是更底层的问题：在知识工作时代，一个人必须学会把自己当作一项长期资产来管理。你要知道自己的优势、工作方式、价值观、适合的位置，以及你能贡献什么。\n这篇文章之所以经典，是因为它把职业发展从“公司安排我”转成“我必须理解自己”。工业时代的很多人可以依靠组织路径生活：进入公司，服从岗位，按资历晋升，退休结束。但知识工作者的寿命、技能周期和组织变化都更复杂。你可能多次换行业、换角色、换协作方式。没有人能替你长期管理这些选择。\n先理解自己的优势 # Drucker 最核心的建议之一，是人应该把主要精力放在优势上，而不是幻想把所有短板补齐。这里的优势不是“我喜欢什么”，也不是“我自我感觉不错”，而是通过反馈分析逐渐确认：哪些事情我做了之后真的有结果？哪些判断后来被证明可靠？哪些能力在不同场景下反复产生价值？\n很多人的自我认识其实很不可靠。我们容易高估自己擅长的事，也容易被外部评价牵着走。有人因为一次表扬就觉得自己适合某方向，也有人因为一次失败就放弃真正有潜力的能力。Drucker 的方法更冷静：记录预期，等待结果，再比较差异。长期下来，你会看到自己真实的强项和盲点。\n这对博客作者也有帮助。你可以通过写作观察自己：哪些主题你能写得深入？哪些文章后来仍然愿意回看？哪些观点能帮助你做出更好决策？哪些领域你只是跟风？公开写作会暴露一个人的理解深度，也会留下长期反馈。博客不只是展示，也是一种自我诊断工具。\n工作方式比努力方式更具体 # Drucker 还提醒人们，不同人有不同的工作方式。有的人通过阅读学习，有的人通过听和讨论学习；有的人适合独立深思，有的人适合在互动中形成判断；有的人适合做决策者，有的人适合做顾问；有的人在结构清晰的组织里表现好，有的人在混乱探索中更有价值。\n","title":"重读 Drucker：管理自己","type":"posts"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/tags/%E8%87%AA%E6%88%91%E7%AE%A1%E7%90%86/","section":"Tags","summary":"","title":"自我管理","type":"tags"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/tags/%E4%BA%92%E8%81%94%E7%BD%91/","section":"Tags","summary":"","title":"互联网","type":"tags"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/tags/%E7%9F%A5%E8%AF%86%E7%AE%A1%E7%90%86/","section":"Tags","summary":"","title":"知识管理","type":"tags"},{"content":"作者：Vannevar Bush\n原文链接：As We May Think\nVannevar Bush 的《As We May Think》发表于 1945 年。它最惊人的地方，不是某个具体设备预测得有多准确，而是它在计算机、互联网、个人知识管理还没有成为日常现实之前，就已经抓住了一个核心矛盾：人类制造知识的速度越来越快，但组织、检索和重新使用知识的方式远远跟不上。\n这篇文章写在二战即将结束的时间点。科学家在战争中释放了巨大的技术能力，Bush 关心的是，战争之后这些能力应该转向哪里。他给出的方向不是更强的武器，而是更好的记忆、更好的索引、更好的知识连接方式。换句话说，他把技术的目标从扩展肌肉和感官，转向扩展人的思考能力。\n知识爆炸之后，问题变成如何找回 # 现代人读这篇文章，会有一种奇怪的熟悉感。我们每天面对的信息量远远超过 1945 年的人，但困境并没有消失。搜索引擎、浏览器收藏夹、网盘、笔记软件、社交媒体、论文数据库和聊天记录，让信息看似随处可得，却也让真正的理解变得更难。信息越多，筛选、关联和复用越重要。\nBush 看到的问题是，传统索引方式太机械。图书馆目录、分类编号、层级文件夹，都要求人按照系统预设的路径寻找知识。但人的思考并不是这样运作的。我们常常从一个概念想到另一个概念，从一个案例跳到另一个案例，从一个问题牵出一组经验。人的记忆更像联想网络，而不是固定目录。\n这正是《As We May Think》的核心：知识工具应该更接近人的联想方式。后来互联网的超链接、个人知识库的双向链接、标签系统、引用网络、笔记之间的 backlink，都可以看作对这个方向的不同实现。Bush 文章里的 memex 不是今天意义上的电脑，但它提出的“联想路径”仍然是信息工具最重要的思想之一。\nMemex 的价值不是设备，而是思维模型 # 很多人提到这篇文章时，会把重点放在 memex 这个设想中的机器上。它像一张桌子，能存储书籍、记录、通信和个人笔记，使用者可以建立不同材料之间的路径。以今天眼光看，它像是个人电脑、浏览器、知识库和超文本系统的混合体。\n但如果只把 memex 当作“预测互联网”，反而会低估这篇文章。真正重要的不是硬件形态，而是它对知识工作的理解：一个人不只是读取资料，还要建立路径；不只是收藏内容，还要留下自己的关联；不只是消费知识，还要把自己的思考接入更大的知识网络。\n这对写博客很有启发。博客不是孤立文章的堆积，而应该逐渐形成一个可回访的思想地图。每篇文章都可以链接到之前的问题、阅读过的经典、正在做的项目和未来要探索的方向。一个博客写久了，如果只是按日期排列，就会变成流水账；如果能形成主题、标签和内部引用，它就会更像个人 memex。\n好工具应该帮助人形成路径 # 今天的知识管理工具很多，但多数工具容易诱导人变成收藏者。看到好文章，先保存；看到好句子，先剪藏；看到一个课程，先加入稍后阅读。久而久之，收藏行为本身变成一种虚假的进步感。Bush 的文章提醒我们，知识工具的关键不是存得多，而是能不能帮助你形成可走回去的路径。\n路径意味着理解。你为什么把这篇文章和那本书放在一起？它们回答的是同一个问题，还是互相冲突？你下次遇到类似问题时，能不能找到这条线索？如果不能，收藏就只是囤积。真正的知识系统应该让旧材料在新问题里重新活过来。\n这也解释了为什么导读比摘抄更有价值。摘抄保存的是别人的表达，导读保存的是自己的路径。你必须判断这篇文章在讲什么，为什么重要，和自己的经验有什么关系，未来可以怎样使用。这个过程比复制原文慢得多，但它更接近真正的学习。\n联想不是混乱，而是有意识的连接 # 当然，联想式知识管理也有风险。如果没有清晰问题，链接会变成混乱的网。今天很多双向链接笔记系统最后变成了漂亮但无用的图谱：节点很多，线很多，却没有产生更好的判断。Bush 所设想的路径并不是随意乱连，而是围绕人的工作、研究和思考目标建立的路径。\n好的知识连接应该服务于问题。比如，一个人长期关心“如何做重要工作”，那么 Hamming、Paul Graham、Drucker、Cal Newport 都可以被放在同一条路径上。一个人关心“技术如何改变人的认知”，那么 Bush、Bret Victor、互联网历史、AI 工具和个人知识库就能构成另一条路径。路径越清楚，未来越容易重新进入问题。\n这也是分类和标签的意义。分类不只是页面装饰，它代表一个人如何划分世界。标签也不只是搜索入口，它是一种轻量的关联方式。博客里的分类、标签和文章列表如果做得好，就会让读者感觉自己走进了一间有秩序的档案室，而不是一个模板化的信息流。\n对我自己的提醒 # 读《As We May Think》，我最想记住的是：信息工具的目标不是让我知道更多，而是让我想得更好。今天我们太容易把“拥有资料”误认为“拥有知识”。硬盘里有很多 PDF，浏览器里有很多收藏，笔记软件里有很多摘录，但真正遇到问题时，仍然想不清楚、找不到、用不上。\n更好的做法，是减少无意义收藏，增加主动整理和公开表达。每读一篇重要文章，都问三个问题：它解决了什么问题？它改变了我哪个判断？它应该和我已有的哪些文章放在一起？只要长期坚持，博客就会慢慢从内容列表变成思想索引。\nBush 在 1945 年写这篇文章时，无法知道今天的信息世界会变成什么样。但他看见了一个仍然有效的方向：工具应该帮助人保存、连接、追踪和扩展思想，而不是只增加信息吞吐量。这一点在 AI 时代反而更重要。信息生成越来越便宜，真正稀缺的是问题意识、连接能力和判断力。\n可以实践的清单 # 每篇导读都保留原文链接、主题标签和自己的关键判断。 写文章时主动链接到博客里已有的相关文章，让内容形成路径。 少做大段摘抄，多写“为什么这对我重要”。 定期回看旧文章，补充新的链接、反例和实践结果。 把博客当成个人 memex，而不是只当成发布页面。 《As We May Think》值得放进个人博客，是因为它讲的正是博客本身可以承担的使命。一个好的博客不是新闻站，不是简历装饰，也不是情绪出口。它可以是一台缓慢运转的个人记忆机器，帮助作者把阅读、经验、问题和判断组织起来，让多年后的自己仍然能沿着旧路径继续思考。\n","date":"May 18, 2026","externalUrl":null,"permalink":"/posts/vannevar-bush-as-we-may-think-notes/","section":"文章","summary":"作者：Vannevar Bush\n原文链接：As We May Think\nVannevar Bush 的《As We May Think》发表于 1945 年。它最惊人的地方，不是某个具体设备预测得有多准确，而是它在计算机、互联网、个人知识管理还没有成为日常现实之前，就已经抓住了一个核心矛盾：人类制造知识的速度越来越快，但组织、检索和重新使用知识的方式远远跟不上。\n这篇文章写在二战即将结束的时间点。科学家在战争中释放了巨大的技术能力，Bush 关心的是，战争之后这些能力应该转向哪里。他给出的方向不是更强的武器，而是更好的记忆、更好的索引、更好的知识连接方式。换句话说，他把技术的目标从扩展肌肉和感官，转向扩展人的思考能力。\n知识爆炸之后，问题变成如何找回 # 现代人读这篇文章，会有一种奇怪的熟悉感。我们每天面对的信息量远远超过 1945 年的人，但困境并没有消失。搜索引擎、浏览器收藏夹、网盘、笔记软件、社交媒体、论文数据库和聊天记录，让信息看似随处可得，却也让真正的理解变得更难。信息越多，筛选、关联和复用越重要。\n","title":"重读 Vannevar Bush：如我们所能设想","type":"posts"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/tags/%E5%88%9B%E9%80%A0%E5%8A%9B/","section":"Tags","summary":"","title":"创造力","type":"tags"},{"content":"","date":"May 18, 2026","externalUrl":null,"permalink":"/tags/%E9%95%BF%E6%9C%9F%E4%B8%BB%E4%B9%89/","section":"Tags","summary":"","title":"长期主义","type":"tags"},{"content":"作者：Richard W. Hamming\n原文链接：You and Your Research\nRichard Hamming 的《You and Your Research》是一篇很适合反复读的演讲稿。它表面上是在讲科学研究，实际讲的是一个人怎样把有限的一生投入到真正重要的问题上。Hamming 不是站在旁边讲励志话术的人。他本人做过通信、编码、计算、数值方法，也长期身处贝尔实验室那种高密度的聪明人环境。因此这篇演讲的力量不在于口号，而在于它把“做出重要工作”拆成了很多可以自我检查的选择。\n这篇文章最刺人的地方，是它不断追问一个问题：你到底在做重要的事，还是只是在做容易被安排、容易被衡量、容易让自己显得忙碌的事？很多人希望自己有一天做出重要贡献，但每天真正投入的却是琐碎任务、即时反馈、低风险重复和组织惯性。Hamming 的意思不是所有人都必须成为科学家，也不是说每件小事都不值得做。他提醒的是，如果一个人从来不把自己的注意力放到重要问题上，那么重要结果几乎不可能偶然发生。\n重要问题不是等来的 # Hamming 反复强调，伟大工作通常来自对重要问题的持续凝视。这里的“重要”不是社会热搜，也不是老板今天说优先级最高的任务，而是那些一旦被解决，就会改变一个领域、一个系统或一群人的问题。一个人如果总是在别人定义好的问题里工作，就很容易变成高效执行者，却很难变成真正的创造者。\n这对个人博客尤其有价值。写博客不是只记录今天学了什么命令，或者把网上已有的教程换一种说法。长期来看，更值得积累的是自己反复追问的问题：什么能力会复利？什么工作只是消耗？怎样判断一个技术趋势是否真实？怎样把输入变成可复用的作品？这些问题未必立刻有答案，但它们决定了一个人阅读、写作和实践的方向。\n重要问题也不是凭空想出来的。它往往来自长期接触领域内部的真实困难。外行看问题，容易觉得所有东西都可以靠一个“新工具”解决；深入进去之后才知道，真正难的地方可能在约束、协作、历史包袱、错误激励和人类习惯。Hamming 要求研究者既要有野心，也要有足够的现实感。只喊“我要做大事”没有用，关键是把大问题放进日常工作里，让自己每天都在靠近它。\n运气重要，但姿势更重要 # 这篇演讲并不否认运气。很多发现确实有偶然性，很多人的机会也来自时代、地点、同事和资源。但 Hamming 的观点更进一步：具体碰到什么机会可能是运气，能不能反复处在机会附近，却不是纯运气。如果一个人长期在重要问题附近工作，持续和高水平的人交流，愿意公开表达自己的想法，愿意承担被质疑的风险，那么机会出现时，他更可能抓住。\n这对今天的普通工作者也成立。很多人把职业突破理解为等待贵人、等待风口、等待公司给机会。但更实际的做法，是让自己经常出现在“问题密度高”的地方：读高质量材料，参与真实项目，写公开笔记，复盘失败，主动提出可检验的方案。机会不是完全可控的，但你可以控制自己是否长期站在低质量信息和低难度任务里。\nHamming 也很重视表达。他观察到，有些人明明有好想法，却不愿意写、不愿意讲、不愿意和别人讨论，最后这些想法无法进入更大的系统。重要工作不仅要被做出来，还要被别人理解、使用、批评和延展。对博客作者来说，这一点很直接：公开写作不是炫耀，而是训练思想的接口。如果一个观点不能写清楚，它很可能还没有真正想清楚。\n闭门努力不等于高质量努力 # 很多人喜欢把努力想象成孤独、忍耐和长时间工作。Hamming 并不反对努力，但他更关心努力的方向和反馈。一个人可以每天工作很久，却只是在维护旧系统；也可以每天都很忙，却从不触碰真正改变结果的变量。低质量努力最危险的地方，是它会让人产生道德满足感：我已经很辛苦了，所以我应该有结果。\n这篇文章提醒我们，努力必须和问题选择、环境选择、反馈选择绑在一起。你在什么问题上努力？你和什么人讨论？你是否愿意暴露半成品？你是否有勇气承认自己当前的路线可能不重要？这些问题比“今天工作了几个小时”更决定长期结果。\n对技术学习也是如此。学框架、刷教程、跟着视频敲代码都可以是入门方式，但如果长期停留在这种模式里，就很难形成真正判断。更好的努力，是自己提出问题，自己实现一个小工具，自己读错误日志，自己比较方案，自己解释为什么这样设计。重要能力往往不是“看懂了”，而是“在不完整条件下做出合理选择”。\n环境会塑造野心 # Hamming 在演讲里谈到贝尔实验室的氛围，这部分很值得注意。一个人身边的人在讨论什么，会直接影响他认为哪些问题值得做。如果周围所有人都只关心短期指标，你很难长期保持对深问题的敏感；如果周围有人认真追问本质、愿意挑战假设，你也会被迫提高自己的标准。\n今天的环境不只包括办公室，也包括信息流。你每天刷到的内容、关注的人、订阅的文章、加入的社群，都会塑造你的默认尺度。如果输入里充满碎片争吵、速成技巧和情绪消费，你很难自然长出严肃问题。反过来，如果你经常读经典论文、优秀工程复盘、创业者长文和高质量访谈，你会逐渐形成更耐心的判断。\n这也是为什么个人博客要有“档案感”。它不是为了追热点，而是为了把值得反复回看的材料、问题和思考保存下来。一个人的公开文章列表，其实就是他的长期注意力地图。你收藏什么、导读什么、批注什么，最后会反过来塑造你成为什么样的人。\n对我自己的提醒 # 读完 Hamming，我最想记住的是：不要把“有能力完成任务”误认为“正在做重要工作”。完成任务是基础，但人生真正拉开差距的地方，往往在任务之外：你是否选择了一个值得长期投入的问题？你是否持续训练表达？你是否愿意把自己放到更高标准的环境里？你是否在别人满足于局部最优时，仍然追问更本质的东西？\n这篇文章也提醒我，不要把野心当成空泛情绪。真正的野心应该落到日程表、阅读列表、写作主题和项目选择里。如果我说自己想做重要的事，却每天只把时间交给零散消息和被动任务，那这个愿望就是假的。重要工作不是突然降临的奖赏，而是长期选择之后的副产品。\n可以实践的清单 # 每个季度写下自己认为最重要的三个问题，并检查时间是否真的投向它们。 每周至少留出一段不被打断的时间，用来推进一个长期问题，而不是处理碎事。 主动和更高水平的人讨论半成品想法，不等完全准备好才开口。 把读到的经典文章写成自己的语言，训练理解和表达的闭环。 少问“我今天忙不忙”，多问“我今天有没有靠近真正重要的问题”。 Hamming 这篇演讲不适合当作鸡血读物。它真正有价值的地方，是让人安静下来重新审视自己的方向。一个人可以平凡地生活，也可以选择不追求宏大的研究成果；但只要你还希望自己的工作有一点分量，就很难绕开它提出的问题：你是否愿意严肃地对待自己的注意力、选择和时间？\n","date":"May 18, 2026","externalUrl":null,"permalink":"/posts/richard-hamming-you-and-your-research-notes/","section":"文章","summary":"作者：Richard W. Hamming\n原文链接：You and Your Research\nRichard Hamming 的《You and Your Research》是一篇很适合反复读的演讲稿。它表面上是在讲科学研究，实际讲的是一个人怎样把有限的一生投入到真正重要的问题上。Hamming 不是站在旁边讲励志话术的人。他本人做过通信、编码、计算、数值方法，也长期身处贝尔实验室那种高密度的聪明人环境。因此这篇演讲的力量不在于口号，而在于它把“做出重要工作”拆成了很多可以自我检查的选择。\n这篇文章最刺人的地方，是它不断追问一个问题：你到底在做重要的事，还是只是在做容易被安排、容易被衡量、容易让自己显得忙碌的事？很多人希望自己有一天做出重要贡献，但每天真正投入的却是琐碎任务、即时反馈、低风险重复和组织惯性。Hamming 的意思不是所有人都必须成为科学家，也不是说每件小事都不值得做。他提醒的是，如果一个人从来不把自己的注意力放到重要问题上，那么重要结果几乎不可能偶然发生。\n重要问题不是等来的 # Hamming 反复强调，伟大工作通常来自对重要问题的持续凝视。这里的“重要”不是社会热搜，也不是老板今天说优先级最高的任务，而是那些一旦被解决，就会改变一个领域、一个系统或一群人的问题。一个人如果总是在别人定义好的问题里工作，就很容易变成高效执行者，却很难变成真正的创造者。\n","title":"重读 Hamming：你和你的研究","type":"posts"},{"content":"","date":"May 17, 2026","externalUrl":null,"permalink":"/categories/c/","section":"Categories","summary":"","title":"C","type":"categories"},{"content":"测试用例1正文\n","date":"May 17, 2026","externalUrl":null,"permalink":"/posts/%E6%B5%8B%E8%AF%95%E7%94%A8%E4%BE%8B1/","section":"文章","summary":"测试用例1正文\n","title":"测试用例1","type":"posts"},{"content":"","date":"May 17, 2026","externalUrl":null,"permalink":"/tags/%E6%B5%8B%E8%AF%95%E7%94%A8%E4%BE%8B1%E6%A0%87%E7%AD%BE/","section":"Tags","summary":"","title":"测试用例1标签","type":"tags"},{"content":"","date":"May 17, 2026","externalUrl":null,"permalink":"/categories/b/","section":"Categories","summary":"","title":"B","type":"categories"},{"content":"作者：Derek Sivers\n原文链接：No “yes.” Either “HELL YEAH!” or “no.”\n这篇文章很短，但观点很锋利：如果一件事没有让你强烈想答应，那就拒绝。\n它解决的是一种常见困境：我们答应了太多“还可以”的事情，最后没有时间留给真正重要的事情。人生不是被少数坏选择毁掉的，更多时候是被大量中等选择填满的。\n机会成本比想象中更贵 # 很多邀请、项目、合作、活动看起来都不错。问题在于，“不错”不等于“值得”。当你答应一个还可以的机会，你消耗的不只是那几个小时，还包括注意力、恢复时间、心理空间和未来更好机会的容量。\n拒绝不是傲慢，而是承认自己有限。\n模糊的答应最危险 # 很多人不会答应明显糟糕的事情，却很容易答应那些听起来合理但并不兴奋的事情。比如一个普通合作、一个普通聚会、一个普通项目、一个普通承诺。它们单独看都不严重，加起来会让人生变得拥挤。\n真正的问题是：当你的日程被普通事情占满，真正重要的事情出现时，你已经没有空间。\n这个规则适合什么时候用 # 这个规则不是让人对所有责任说不。家庭、健康、已有承诺、必要工作，都不能简单用兴奋程度判断。它更适合用于选择性机会：新项目、新合作、新活动、新方向、新社交。\n当一件事不是必须做，而只是“可以做”时，就应该提高答应门槛。\n对我自己的提醒 # 这篇文章让我意识到：不清晰的边界，会让人生变得越来越像别人安排的。\n如果我不主动决定什么重要，外界就会替我填满时间。拒绝的本质不是消极，而是保护那些真正想做的事。\n可以实践的清单 # 对新机会先问：我是否强烈想做？ 如果答案只是“还行”，默认拒绝或延迟决定。 给长期目标预留空白时间，不让日程满格。 拒绝时简短、诚实，不写长篇解释。 定期清理已经答应但不再重要的承诺。 这篇文章适合作为决策提醒。它没有复杂理论，但能立刻改变一个人的日程质量：少答应一点，认真做值得的事。\n","date":"May 17, 2026","externalUrl":null,"permalink":"/posts/derek-sivers-hell-yeah-or-no-notes/","section":"文章","summary":"作者：Derek Sivers\n原文链接：No “yes.” Either “HELL YEAH!” or “no.”\n这篇文章很短，但观点很锋利：如果一件事没有让你强烈想答应，那就拒绝。\n它解决的是一种常见困境：我们答应了太多“还可以”的事情，最后没有时间留给真正重要的事情。人生不是被少数坏选择毁掉的，更多时候是被大量中等选择填满的。\n机会成本比想象中更贵 # 很多邀请、项目、合作、活动看起来都不错。问题在于，“不错”不等于“值得”。当你答应一个还可以的机会，你消耗的不只是那几个小时，还包括注意力、恢复时间、心理空间和未来更好机会的容量。\n拒绝不是傲慢，而是承认自己有限。\n模糊的答应最危险 # 很多人不会答应明显糟糕的事情，却很容易答应那些听起来合理但并不兴奋的事情。比如一个普通合作、一个普通聚会、一个普通项目、一个普通承诺。它们单独看都不严重，加起来会让人生变得拥挤。\n","title":"Derek Sivers：不是强烈想做，就拒绝","type":"posts"},{"content":"","date":"May 17, 2026","externalUrl":null,"permalink":"/tags/%E5%8F%96%E8%88%8D/","section":"Tags","summary":"","title":"取舍","type":"tags"},{"content":"作者：Paul Graham\n原文链接：Maker\u0026rsquo;s Schedule, Manager\u0026rsquo;s Schedule\n这篇文章解释了一个很多程序员、设计师、写作者和研究者都熟悉的痛苦：为什么一个半小时的会议，可能毁掉一整个上午。\nPaul Graham 把工作时间分成两种：管理者时间和创造者时间。管理者按小时切分日程，会议、沟通、决策都可以一格一格安排。创造者需要大块连续时间，因为写代码、写文章、做设计、研究问题，都需要进入深度状态。\n两种日程的冲突 # 管理者时间天然适合会议。一天被切成很多小块，每一块都可以安排一个主题。对管理者来说，一个会议只是一个时间格。\n但对创造者来说，时间不是均匀颗粒。一个上午如果被中间切开，就不再是两个可用的小块，而可能变成一整段废掉的深度时间。因为创造性工作需要加载上下文，进入状态，维持思路。\n这就是为什么很多人不是讨厌沟通，而是讨厌随机打断。\n会议的真实成本 # 会议成本不只是会议本身的时长。它还包括会前的等待、会后的恢复、上下文切换、思路断裂，以及对日程完整性的破坏。一个 30 分钟会议如果放在上午中间，可能实际成本是半天。\n这也是很多团队低估的地方。日历上看起来只是占用一格，实际上它切断的是创造者最稀缺的连续注意力。\n如何保护创造者时间 # 最简单的方法是把会议集中到固定时段，给创造性工作留下完整半天或整天。比如上午不排会，下午集中沟通；或者某几天处理会议，某几天保留深度工作。\n这不是反管理，而是尊重不同工作的时间结构。好的组织应该让不同类型的工作使用不同日程，而不是用同一种日历逻辑压平所有人。\n对我自己的提醒 # 这篇文章解释了我很多低效时刻。不是我不够自律，而是时间被切碎后，复杂任务无法启动。\n尤其在编程和写作里，真正困难的是把整个问题装进脑子。一旦被打断，表面上只是停了几分钟，实际上要重新加载大量上下文。\n可以实践的清单 # 给深度工作预留连续 3 小时以上的时间块。 尽量把会议集中，不让它们散落在一天中间。 对复杂任务，先保护上下文，再谈效率。 团队协作时，明确哪些人需要创造者时间。 用异步文档替代不必要的即时会议。 这篇文章主题不大，但非常实用。它适合放在博客里提醒自己：真正的产出不是把日程塞满，而是保护能产生结果的时间结构。\n","date":"May 17, 2026","externalUrl":null,"permalink":"/posts/paul-graham-maker-manager-schedule-notes/","section":"文章","summary":"作者：Paul Graham\n原文链接：Maker’s Schedule, Manager’s Schedule\n这篇文章解释了一个很多程序员、设计师、写作者和研究者都熟悉的痛苦：为什么一个半小时的会议，可能毁掉一整个上午。\nPaul Graham 把工作时间分成两种：管理者时间和创造者时间。管理者按小时切分日程，会议、沟通、决策都可以一格一格安排。创造者需要大块连续时间，因为写代码、写文章、做设计、研究问题，都需要进入深度状态。\n两种日程的冲突 # 管理者时间天然适合会议。一天被切成很多小块，每一块都可以安排一个主题。对管理者来说，一个会议只是一个时间格。\n但对创造者来说，时间不是均匀颗粒。一个上午如果被中间切开，就不再是两个可用的小块，而可能变成一整段废掉的深度时间。因为创造性工作需要加载上下文，进入状态，维持思路。\n这就是为什么很多人不是讨厌沟通，而是讨厌随机打断。\n会议的真实成本 # 会议成本不只是会议本身的时长。它还包括会前的等待、会后的恢复、上下文切换、思路断裂，以及对日程完整性的破坏。一个 30 分钟会议如果放在上午中间，可能实际成本是半天。\n","title":"Paul Graham：创造者时间和管理者时间","type":"posts"},{"content":"","date":"May 17, 2026","externalUrl":null,"permalink":"/tags/%E5%88%9B%E4%BD%9C%E8%80%85/","section":"Tags","summary":"","title":"创作者","type":"tags"},{"content":"","date":"May 17, 2026","externalUrl":null,"permalink":"/tags/%E4%B8%93%E6%B3%A8/","section":"Tags","summary":"","title":"专注","type":"tags"},{"content":"作者：Marc Andreessen\n原文链接：It\u0026rsquo;s Time to Build\n这篇文章写在一个特殊时期，但它讨论的问题并不只属于那个时期。Marc Andreessen 的核心观点是：社会不应该只擅长评论、分配、金融化和管理叙事，还应该重新重视建造真实东西的能力。\n这里的“建造”不只是写代码，也包括住房、医疗、教育、基础设施、制造、能源、科研组织和公共服务。它强调的是一种面向现实问题的生产能力。\n评论不能替代建设 # 现代社会很擅长讨论问题。我们可以分析、批评、转发、站队、解释为什么某件事很难。但如果最后没有人真正去做系统、修医院、造房子、写工具、改流程，问题不会因为讨论而消失。\n这篇文章最有力量的地方，是它把注意力从“谁说得对”拉回“谁能做出来”。\n技术不是孤立存在的 # 很多人谈技术时，只看软件、模型或产品。但现实世界的建造往往更复杂：它需要制度、资本、人才、供应链、政策、组织和长期耐心。一个社会如果只有聪明人做虚拟优化，却没有足够多的人进入困难行业，很多基础问题会越来越难解决。\n这对工程师也有启发。写代码当然重要，但代码最终应该进入现实流程，改变某个真实系统的效率、成本或可靠性。\n建造需要尊重执行 # 愿景很便宜，执行很贵。真正建造东西的人，要面对预算、故障、监管、维护、用户、组织摩擦和长周期反馈。这些东西不如观点表达性感，但它们决定事情能不能落地。\n所以这篇文章其实是在提醒：不要只崇拜聪明，也要尊重能把事情推进的人。\n对我自己的提醒 # 我读这篇文章时，最想反思的是：我是在消费问题，还是在解决问题？\n每天看很多行业分析、技术评论、社会议题，很容易获得一种“我理解世界”的错觉。但理解如果不能转化为作品、工具、系统或行动，就只是一种高级旁观。\n可以实践的清单 # 少停留在评论，多问自己能建造什么。 选择一个具体问题，做一个小工具或小流程改进。 尊重维护、运营、交付这些不显眼的工作。 把技术能力连接到真实世界的成本和效率。 用作品回应问题，而不只是用观点回应问题。 这篇文章适合作为博客里的行动宣言。它不一定每个判断都完美，但它有一种稀缺的方向感：世界最终需要被建设，而不是只被解释。\n","date":"May 17, 2026","externalUrl":null,"permalink":"/posts/marc-andreessen-time-to-build-notes/","section":"文章","summary":"作者：Marc Andreessen\n原文链接：It’s Time to Build\n这篇文章写在一个特殊时期，但它讨论的问题并不只属于那个时期。Marc Andreessen 的核心观点是：社会不应该只擅长评论、分配、金融化和管理叙事，还应该重新重视建造真实东西的能力。\n这里的“建造”不只是写代码，也包括住房、医疗、教育、基础设施、制造、能源、科研组织和公共服务。它强调的是一种面向现实问题的生产能力。\n评论不能替代建设 # 现代社会很擅长讨论问题。我们可以分析、批评、转发、站队、解释为什么某件事很难。但如果最后没有人真正去做系统、修医院、造房子、写工具、改流程，问题不会因为讨论而消失。\n这篇文章最有力量的地方，是它把注意力从“谁说得对”拉回“谁能做出来”。\n技术不是孤立存在的 # 很多人谈技术时，只看软件、模型或产品。但现实世界的建造往往更复杂：它需要制度、资本、人才、供应链、政策、组织和长期耐心。一个社会如果只有聪明人做虚拟优化，却没有足够多的人进入困难行业，很多基础问题会越来越难解决。\n","title":"Marc Andreessen：是时候重新开始建造","type":"posts"},{"content":"","date":"May 17, 2026","externalUrl":null,"permalink":"/tags/%E5%BB%BA%E9%80%A0/","section":"Tags","summary":"","title":"建造","type":"tags"},{"content":"","date":"May 17, 2026","externalUrl":null,"permalink":"/tags/%E7%94%9F%E4%BA%A7%E5%8A%9B/","section":"Tags","summary":"","title":"生产力","type":"tags"},{"content":"作者：Steve Jobs\n原文链接：Stanford Commencement Address 2005\n乔布斯这篇演讲已经被引用过太多次，以至于很多人会下意识觉得它“过时”或“鸡汤”。但如果把熟悉感拿掉，重新读一遍，会发现它讲的其实是三个非常硬的问题：人生路径如何形成，如何面对失去，如何用死亡校准选择。\n它不是一篇创业成功学演讲，而是一篇关于不确定性的演讲。\n你只能向后理解人生 # 乔布斯讲到退学、旁听字体课、后来把字体设计带进 Macintosh 的故事。这个故事真正重要的地方，不是“兴趣会带来成功”，而是：很多选择在当下并不能被证明有用。\n人生不是先有完整地图，再按路线前进。更多时候，你只能在当下凭好奇、品味和直觉做选择。很多点要到多年后回头看，才会连接起来。\n这并不意味着随便选择都可以被合理化。它更像是在说：你需要对自己的好奇心和判断力有一点信任，同时承担不确定性的代价。\n失去可能变成新的起点 # 乔布斯被自己创办的苹果公司赶走，这是一个很少有人能轻松承受的打击。但他后来创办 NeXT 和 Pixar，最终又回到苹果。这段经历提醒人：一次失败可能结束某个身份，却不一定结束你的能力。\n很多人把失败理解成自我价值归零。其实失败更准确地说，是某个路径、某个关系、某个阶段结束。只要能力、好奇心和行动力还在，人仍然可以重新组织人生。\n死亡是最强的过滤器 # 演讲里最有力量的部分，是乔布斯谈死亡。死亡让很多外部评价失效：面子、恐惧、别人的期待、虚荣的比较，在死亡面前都会变小。\n这不是消极，而是清醒。一个人如果经常意识到时间有限，就更难长期忍受虚假的生活。\n对我自己的提醒 # 这篇演讲让我想到：很多选择不需要证明给所有人看。\n重要的是，你是否愿意承担选择带来的后果。你选择一个方向，就会失去另一些方向；你选择自己的节奏，就可能暂时不被理解；你选择长期热爱，就要忍受短期的不确定。\n可以实践的清单 # 记录自己真正感兴趣但暂时“没用”的东西。 遇到失败时，区分“路径失败”和“人失败”。 做重大选择前问：如果时间有限，我还会这样选吗？ 少用外界掌声判断一件事是否值得做。 给直觉一点空间，但用行动持续校准它。 这篇演讲之所以经典，不是因为它给出标准答案，而是因为它提醒每个人：人生不是简历，人生是你真实活过的路径。\n","date":"May 17, 2026","externalUrl":null,"permalink":"/posts/steve-jobs-stanford-speech-notes/","section":"文章","summary":"作者：Steve Jobs\n原文链接：Stanford Commencement Address 2005\n乔布斯这篇演讲已经被引用过太多次，以至于很多人会下意识觉得它“过时”或“鸡汤”。但如果把熟悉感拿掉，重新读一遍，会发现它讲的其实是三个非常硬的问题：人生路径如何形成，如何面对失去，如何用死亡校准选择。\n它不是一篇创业成功学演讲，而是一篇关于不确定性的演讲。\n你只能向后理解人生 # 乔布斯讲到退学、旁听字体课、后来把字体设计带进 Macintosh 的故事。这个故事真正重要的地方，不是“兴趣会带来成功”，而是：很多选择在当下并不能被证明有用。\n人生不是先有完整地图，再按路线前进。更多时候，你只能在当下凭好奇、品味和直觉做选择。很多点要到多年后回头看，才会连接起来。\n这并不意味着随便选择都可以被合理化。它更像是在说：你需要对自己的好奇心和判断力有一点信任，同时承担不确定性的代价。\n失去可能变成新的起点 # 乔布斯被自己创办的苹果公司赶走，这是一个很少有人能轻松承受的打击。但他后来创办 NeXT 和 Pixar，最终又回到苹果。这段经历提醒人：一次失败可能结束某个身份，却不一定结束你的能力。\n","title":"乔布斯斯坦福演讲：把点连起来","type":"posts"},{"content":"","date":"May 17, 2026","externalUrl":null,"permalink":"/tags/%E7%83%AD%E7%88%B1/","section":"Tags","summary":"","title":"热爱","type":"tags"},{"content":"","date":"May 17, 2026","externalUrl":null,"permalink":"/tags/%E9%80%89%E6%8B%A9/","section":"Tags","summary":"","title":"选择","type":"tags"},{"content":"作者：Kevin Kelly\n原文链接：103 Bits of Advice I Wish I Had Known\nKevin Kelly 这篇文章是一组短建议。它的特点不是论证严密，而是覆盖面很广：工作、关系、学习、财富、创作、注意力、沟通、生活方式。很多句子看起来像常识，但常识真正困难的地方在于执行。\n这类文章不适合逐条背诵，更适合隔一段时间重读。不同阶段会被不同句子击中。二十岁时看到的是机会，三十岁时看到的是代价，四十岁时可能看到的是关系和健康。\n好建议通常很朴素 # 真正有用的建议，很少需要复杂包装。比如保持好奇、及时道歉、少做无意义争论、记录想法、长期积累信用、认真选择伴侣和朋友。这些话都不新，但每一句都能影响实际生活。\n问题在于，人通常不是不知道，而是在关键时刻忘记。建议的作用不是替你做决定，而是在你偏离时，把你拉回更清醒的位置。\n判断力来自反复校准 # 这篇文章里很多建议都指向判断力。判断力不是天生的神秘能力，而是你反复比较结果和预期之后形成的直觉。你做选择，承担后果，复盘，再调整。\n所以一个人要提高判断力，不能只消费观点。还要在真实生活里做决定，并记录自己为什么这么做。否则看再多建议，也只是在收藏别人的人生经验。\n关系是高价值资产 # Kevin Kelly 的很多建议都和关系有关：如何与人合作，如何表达感谢，如何减少冲突，如何保持善意。这提醒我们，人生不是单人游戏。一个人的长期结果，很大程度上取决于他能否和他人建立稳定、可信、互相成就的关系。\n技术能力可以让你开始，关系和信用决定你能走多远。\n对我自己的提醒 # 我最想从这篇文章里带走的是：不要轻视微小习惯。\n一个建议单独看很小，比如每天记一点东西，见面时认真听别人说话，遇到问题先睡一觉，做决定前写下理由。但这些小动作会慢慢改变一个人的生活质量。\n可以实践的清单 # 建一个“建议复盘”文档，只留下自己验证过的建议。 做重要决定前写下理由，三个月后回看。 每周主动感谢一个帮过自己的人。 少收藏金句，多把一句建议变成习惯。 遇到重复出现的问题，优先修改系统而不是责备自己。 这篇文章适合作为博客里的常读清单。它不是一篇线性文章，更像一盒工具。你不需要一次用完，但总能在某个时刻找到合适的一把。\n","date":"May 17, 2026","externalUrl":null,"permalink":"/posts/kevin-kelly-103-bits-notes/","section":"文章","summary":"作者：Kevin Kelly\n原文链接：103 Bits of Advice I Wish I Had Known\nKevin Kelly 这篇文章是一组短建议。它的特点不是论证严密，而是覆盖面很广：工作、关系、学习、财富、创作、注意力、沟通、生活方式。很多句子看起来像常识，但常识真正困难的地方在于执行。\n这类文章不适合逐条背诵，更适合隔一段时间重读。不同阶段会被不同句子击中。二十岁时看到的是机会，三十岁时看到的是代价，四十岁时可能看到的是关系和健康。\n好建议通常很朴素 # 真正有用的建议，很少需要复杂包装。比如保持好奇、及时道歉、少做无意义争论、记录想法、长期积累信用、认真选择伴侣和朋友。这些话都不新，但每一句都能影响实际生活。\n","title":"Kevin Kelly：那些越早知道越好的建议","type":"posts"},{"content":"","date":"May 17, 2026","externalUrl":null,"permalink":"/tags/%E5%BB%BA%E8%AE%AE/","section":"Tags","summary":"","title":"建议","type":"tags"},{"content":"","date":"May 17, 2026","externalUrl":null,"permalink":"/tags/%E5%88%A4%E6%96%AD%E5%8A%9B/","section":"Tags","summary":"","title":"判断力","type":"tags"},{"content":"作者：Sam Altman\n原文链接：The days are long but the decades are short\n这篇文章是一组人生建议。它不系统，却很密集；不复杂，却经得起反复读。标题本身就很准确：单个日子很漫长，但十年回头看会短得惊人。\n很多人生问题都是在这个矛盾里发生的。今天的拖延看起来只是一天，十年后就是路径；今天的选择看起来只是一个机会，十年后可能就是身份。\n长期看，方向比速度重要 # 短期里，人很容易被速度感欺骗。忙、快、回复多、会议多、任务多，都会让人觉得自己在前进。但十年的尺度会过滤掉大部分噪音。真正留下来的，是你选择了什么关系、什么工作、什么能力、什么生活方式。\nSam Altman 的建议里有一个隐含主题：不要只优化当天的舒服程度，要优化十年后的自己会不会感谢今天的选择。\n和优秀的人待在一起 # 一个人会被周围人的标准塑形。你身边的人认为什么正常，你慢慢也会认为什么正常。如果你长期处在低标准环境里，很难只靠意志力保持高标准。\n所以选择同伴不是社交问题，而是人生结构问题。和有行动力、诚实、聪明、能长期合作的人在一起，你会自然提高对自己的要求。\n不要忽视健康和关系 # 很多年轻时看起来可以透支的东西，后来都会变成账单。身体、睡眠、亲密关系、精神状态，都不是“等成功后再处理”的附属项。它们本身就是人生质量的基础设施。\n这类建议听起来普通，但普通不代表不重要。很多重要道理之所以普通，是因为它们被无数人反复验证过。\n对我自己的提醒 # 这篇文章让我警惕一种倾向：只在短周期里评价自己。\n如果只看今天，我会想要轻松、确定、即时反馈。如果看十年，我会更愿意选择困难但有积累的事。比如写作、编程、锻炼、做产品、建立信用，短期都不一定刺激，但长期会改变一个人的可选项。\n可以实践的清单 # 每季度问一次：现在的生活会把我带向哪里？ 把健康和关系当作基础设施，不当作奖励。 少做让自己短期舒服、长期后悔的事。 主动靠近高标准的人和环境。 给长期能力留固定时间，而不是只处理紧急任务。 这篇文章适合作为博客里的“人生校准器”。它不是提供宏大理论，而是提醒你：十年会很快过去，今天的选择正在悄悄累计。\n","date":"May 17, 2026","externalUrl":null,"permalink":"/posts/sam-altman-days-are-long-notes/","section":"文章","summary":"作者：Sam Altman\n原文链接：The days are long but the decades are short\n这篇文章是一组人生建议。它不系统，却很密集；不复杂，却经得起反复读。标题本身就很准确：单个日子很漫长，但十年回头看会短得惊人。\n很多人生问题都是在这个矛盾里发生的。今天的拖延看起来只是一天，十年后就是路径；今天的选择看起来只是一个机会，十年后可能就是身份。\n长期看，方向比速度重要 # 短期里，人很容易被速度感欺骗。忙、快、回复多、会议多、任务多，都会让人觉得自己在前进。但十年的尺度会过滤掉大部分噪音。真正留下来的，是你选择了什么关系、什么工作、什么能力、什么生活方式。\nSam Altman 的建议里有一个隐含主题：不要只优化当天的舒服程度，要优化十年后的自己会不会感谢今天的选择。\n","title":"Sam Altman：日子很长，十年很短","type":"posts"},{"content":"","date":"May 17, 2026","externalUrl":null,"permalink":"/tags/%E4%BA%BA%E7%94%9F%E5%BB%BA%E8%AE%AE/","section":"Tags","summary":"","title":"人生建议","type":"tags"},{"content":"作者：Tim Urban\n原文链接：The Tail End\n这篇文章的残酷之处在于，它不是抽象地提醒你“时间宝贵”，而是把人生剩余时间变成可视化的格子。你会突然意识到，很多你以为还很多的东西，其实已经进入尾声。\n我们常常用年龄理解人生：二十多岁、三十多岁、四十多岁。但这篇文章换了一个角度：你和父母还剩多少次见面？你和老朋友还剩多少次深入聊天？你还剩多少个夏天？你真正能自由选择生活方式的年份还剩多少？\n时间不是平均分布的 # 人很容易误以为，只要生命还长，关系就还长。但现实不是这样。你和某些人的相处密度，可能已经在童年或学生时代用掉了大部分。后来大家分散到不同城市，组建家庭，进入工作节奏，见面次数会急剧下降。\n所以问题不是“我还有几十年寿命”，而是“我和某个人还剩多少个共同场景”。这两个问题的答案完全不同。\n亲密关系需要主动安排 # 这篇文章最适合提醒现代人：不要把重要关系交给默认日程。默认日程会被工作、通勤、手机、琐事和疲惫填满。你不主动安排，很多关系就会自然变淡。\n这不是说每个人都要维持庞大的社交圈，而是说你应该知道谁最重要。然后，把时间真实地投给他们，而不是只在心里觉得他们重要。\n可视化带来的冲击 # 抽象的道理很难改变行为，因为它没有重量。“珍惜时间”听起来正确，但太常见，常见到失效。Tim Urban 的强处是把时间变成一个个具体格子。格子一少，人就无法继续欺骗自己。\n如果你把一年当成 52 个周末，把人生当成有限数量的小方块，很多选择会变得清楚：哪些事情根本不值得占用一个周末，哪些人值得你专门坐车去见一面。\n对我自己的提醒 # 这篇文章让我想到一个问题：我是不是把最好的注意力给了最不重要的事情？\n很多人不是不爱家人、朋友或自己的长期目标，而是没有把日程投票给它们。日程比想法诚实。你把时间放在哪里，你真正的价值排序就在哪里。\n可以实践的清单 # 列出最重要的 5 个人，并估算一年能见几次。 每个月主动安排一次高质量见面或长谈。 用周末数量而不是年份理解时间。 减少那些消耗注意力但没有记忆价值的活动。 给重要关系留出固定位置，而不是等待有空。 这篇文章不复杂，但后劲很强。它真正想说的不是死亡，而是选择：既然时间有限，你要把它交给谁，交给什么事。\n","date":"May 17, 2026","externalUrl":null,"permalink":"/posts/wait-but-why-the-tail-end-notes/","section":"文章","summary":"作者：Tim Urban\n原文链接：The Tail End\n这篇文章的残酷之处在于，它不是抽象地提醒你“时间宝贵”，而是把人生剩余时间变成可视化的格子。你会突然意识到，很多你以为还很多的东西，其实已经进入尾声。\n我们常常用年龄理解人生：二十多岁、三十多岁、四十多岁。但这篇文章换了一个角度：你和父母还剩多少次见面？你和老朋友还剩多少次深入聊天？你还剩多少个夏天？你真正能自由选择生活方式的年份还剩多少？\n时间不是平均分布的 # 人很容易误以为，只要生命还长，关系就还长。但现实不是这样。你和某些人的相处密度，可能已经在童年或学生时代用掉了大部分。后来大家分散到不同城市，组建家庭，进入工作节奏，见面次数会急剧下降。\n所以问题不是“我还有几十年寿命”，而是“我和某个人还剩多少个共同场景”。这两个问题的答案完全不同。\n亲密关系需要主动安排 # 这篇文章最适合提醒现代人：不要把重要关系交给默认日程。默认日程会被工作、通勤、手机、琐事和疲惫填满。你不主动安排，很多关系就会自然变淡。\n","title":"Wait But Why：人生真正剩下多少时间","type":"posts"},{"content":"","date":"May 17, 2026","externalUrl":null,"permalink":"/tags/%E4%BA%B2%E5%AF%86%E5%85%B3%E7%B3%BB/","section":"Tags","summary":"","title":"亲密关系","type":"tags"},{"content":"","date":"May 17, 2026","externalUrl":null,"permalink":"/tags/%E6%97%B6%E9%97%B4/","section":"Tags","summary":"","title":"时间","type":"tags"},{"content":"作者：Ashish Vaswani、Noam Shazeer、Niki Parmar、Jakob Uszkoreit、Llion Jones、Aidan N. Gomez、Lukasz Kaiser、Illia Polosukhin\n原文链接：Attention Is All You Need\n这篇论文是大模型时代最重要的技术起点之一。它提出 Transformer 架构，核心观点是：在处理序列数据时，不一定必须依赖循环神经网络或卷积网络，注意力机制本身就可以成为主要结构。\n今天我们熟悉的 GPT、Claude、Gemini 以及大量语言模型，都可以追溯到这篇论文打开的方向。它不是“某个模型效果更好”的普通论文，而是改变了模型如何组织信息、如何训练、如何扩展的基础论文。\n它解决了什么问题 # 在 Transformer 之前，处理文本序列常见方法包括 RNN、LSTM、GRU 或 CNN。它们都有一个共同限制：序列处理往往不够并行，长距离依赖也不容易稳定捕捉。\n自然语言里，一个词的意义经常依赖很远之外的词。传统结构要一步步传递信息，路径长，训练慢，也容易丢失细节。Transformer 用自注意力机制让序列中的每个位置都能直接关注其他位置，从而缩短信息路径。\n简单说，它让模型在理解一句话时，不再只是从左到右慢慢读，而是可以同时观察整句话内部的关系。\n注意力机制的直觉 # 注意力机制可以理解成一种动态检索。模型在处理某个词时，会问：当前这个位置应该重点参考哪些其他位置？不同位置之间会形成权重，权重越高，说明当前判断越需要参考那部分信息。\n这比固定窗口或固定顺序更灵活。因为每个输入、每个位置、每一层都可以形成不同的关注关系。语言中的指代、修饰、依赖、上下文，都可以通过这种机制被建模。\n为什么它适合大规模训练 # Transformer 的另一大优势是并行性。因为它不依赖严格的逐步递归，所以更适合 GPU/TPU 这类并行硬件。模型结构一旦能高效并行，就可以吃下更多数据、更大参数和更长训练时间。\n这也是它从“机器翻译论文”变成“大模型基础架构”的关键原因。架构本身不仅效果好，还能随着算力和数据扩展。现代 AI 的很多突破，本质上都依赖这种可扩展性。\n对我自己的提醒 # 这篇论文提醒我：真正重要的技术变化，往往不是多加一个功能，而是改变系统的组织方式。\nTransformer 没有只是把旧模型调得更复杂，而是重新定义了序列建模的中心结构。它让注意力从辅助模块变成主体。很多工程问题也类似：有时瓶颈不是局部优化不够，而是核心抽象错了。\n可以实践的清单 # 学 AI 不要只追模型名字，要追架构为什么成立。 理解注意力机制时，先抓住“动态选择上下文”的直觉。 看技术论文时，重点观察它解决了什么结构性瓶颈。 面对工程系统，也要问：当前抽象是否限制了扩展？ 如果博客里要放一篇技术史级内容，这篇必须有位置。它代表的不是某一次模型刷新，而是一整个时代的开始。\n","date":"May 17, 2026","externalUrl":null,"permalink":"/posts/attention-is-all-you-need-notes/","section":"文章","summary":"作者：Ashish Vaswani、Noam Shazeer、Niki Parmar、Jakob Uszkoreit、Llion Jones、Aidan N. Gomez、Lukasz Kaiser、Illia Polosukhin\n原文链接：Attention Is All You Need\n这篇论文是大模型时代最重要的技术起点之一。它提出 Transformer 架构，核心观点是：在处理序列数据时，不一定必须依赖循环神经网络或卷积网络，注意力机制本身就可以成为主要结构。\n今天我们熟悉的 GPT、Claude、Gemini 以及大量语言模型，都可以追溯到这篇论文打开的方向。它不是“某个模型效果更好”的普通论文，而是改变了模型如何组织信息、如何训练、如何扩展的基础论文。\n它解决了什么问题 # 在 Transformer 之前，处理文本序列常见方法包括 RNN、LSTM、GRU 或 CNN。它们都有一个共同限制：序列处理往往不够并行，长距离依赖也不容易稳定捕捉。\n","title":"《Attention Is All You Need》为什么改变了 AI 世界","type":"posts"},{"content":"","date":"May 17, 2026","externalUrl":null,"permalink":"/tags/transformer/","section":"Tags","summary":"","title":"Transformer","type":"tags"},{"content":"作者：Paul Graham\n原文链接：How to Do Great Work\nPaul Graham 这篇文章讨论的不是“如何提高效率”，而是更难的问题：一个人如何找到值得投入一生的方向，并在这个方向上做出真正重要的工作。\n这篇文章的价值在于，它没有把伟大工作神秘化。它不是说伟大来自天才，也不是说伟大来自痛苦，而是把路径拆成几个更朴素的部分：找到自己真正好奇的东西，持续学习，发现边界，提出问题，形成品味，然后长期追下去。\n伟大工作从好奇心开始 # 很多人选择方向时，首先考虑的是收入、稳定、社会评价或当下热门程度。Paul Graham 的建议更反直觉：你应该认真观察自己的好奇心。一个人能长期投入的领域，通常不是靠意志力硬撑出来的，而是靠持续的兴趣维持探索。\n好奇心不是娱乐意义上的“感兴趣”，而是一种反复回到同一类问题的冲动。你会忍不住看相关内容，忍不住问为什么，忍不住想把它做得更好。这样的方向才可能支撑长时间的积累。\n先进入一个领域，再寻找边界 # 伟大的工作不是坐在房间里凭空想出来的。你需要先进入一个领域，学习它的已有成果，理解前人解决了什么，留下了什么问题。只有站在边界附近，你才知道什么是真问题，什么只是看起来高级的问题。\n这一点对技术尤其重要。很多人想做创新，却不愿意读文档、读论文、读源码、做实验。结果他们提出的问题早就被解决过，或者根本不是领域内真正重要的瓶颈。真正有价值的问题，通常藏在深入实践之后。\n品味决定你追求什么 # 做出好东西需要品味。品味不是装饰性的审美，而是判断什么更简洁、更深刻、更有解释力、更值得保留的能力。一个人如果没有品味，就会把复杂当高级，把堆砌当丰富，把忙碌当进展。\n品味可以被训练。方法是大量接触优秀作品，拆解它们为什么好，同时不断做自己的作品，并让现实反馈修正你的判断。\n对我自己的提醒 # 这篇文章最打动我的地方，是它把“伟大工作”还原成一种长期诚实。你必须诚实地面对自己真正好奇什么，诚实地承认自己现在还不懂什么，诚实地接受一个领域的难度，诚实地选择那些重要但不一定立刻有回报的问题。\n很多时候，人不是缺少努力，而是缺少一个值得努力的方向。方向错了，努力越强，偏离越远。方向对了，哪怕开始很慢，长期也可能变成复利。\n可以实践的清单 # 记录自己反复想研究的问题，而不是只记录热门话题。 每个月读几篇领域内真正重要的文章、论文或源码。 做小作品，用作品暴露自己的无知。 主动训练品味：比较不同方案，问哪个更简洁、更深。 给长期问题留时间，不把所有时间交给即时反馈。 如果要在个人博客里放一篇“创造者必读”，这篇很适合放在最前面。它不是教你赢过别人，而是教你认真对待自己的注意力。\n","date":"May 17, 2026","externalUrl":null,"permalink":"/posts/paul-graham-how-to-do-great-work-notes/","section":"文章","summary":"作者：Paul Graham\n原文链接：How to Do Great Work\nPaul Graham 这篇文章讨论的不是“如何提高效率”，而是更难的问题：一个人如何找到值得投入一生的方向，并在这个方向上做出真正重要的工作。\n这篇文章的价值在于，它没有把伟大工作神秘化。它不是说伟大来自天才，也不是说伟大来自痛苦，而是把路径拆成几个更朴素的部分：找到自己真正好奇的东西，持续学习，发现边界，提出问题，形成品味，然后长期追下去。\n伟大工作从好奇心开始 # 很多人选择方向时，首先考虑的是收入、稳定、社会评价或当下热门程度。Paul Graham 的建议更反直觉：你应该认真观察自己的好奇心。一个人能长期投入的领域，通常不是靠意志力硬撑出来的，而是靠持续的兴趣维持探索。\n好奇心不是娱乐意义上的“感兴趣”，而是一种反复回到同一类问题的冲动。你会忍不住看相关内容，忍不住问为什么，忍不住想把它做得更好。这样的方向才可能支撑长时间的积累。\n先进入一个领域，再寻找边界 # 伟大的工作不是坐在房间里凭空想出来的。你需要先进入一个领域，学习它的已有成果，理解前人解决了什么，留下了什么问题。只有站在边界附近，你才知道什么是真问题，什么只是看起来高级的问题。\n","title":"Paul Graham：如何做出真正重要的工作","type":"posts"},{"content":"","date":"May 17, 2026","externalUrl":null,"permalink":"/tags/%E6%9D%A0%E6%9D%86/","section":"Tags","summary":"","title":"杠杆","type":"tags"},{"content":"作者：Naval Ravikant\n原文链接：How to Get Rich\n这篇文章表面上是在讲如何变富，但它真正讲的是：一个人如何摆脱“用时间换钱”的默认路径，转向用判断力、杠杆、代码、媒体和长期信用来积累财富。\nNaval 的核心区分很重要：钱、地位和财富不是一回事。钱是社会给你的记账符号，地位是别人对你的排序，财富则是能够在你睡觉时继续工作的资产。很多人以为自己在追求财富，实际追求的是工资、头衔、消费能力或他人的认可。\n这篇文章最适合放在博客里，是因为它很像一张人生操作系统的草图。它没有教你某个具体行业怎么赚钱，而是不断提醒你：你应该选择长期游戏，和长期玩家合作，学习可复利的技能，把自己放进能被放大的系统里。\n我从这篇文章里拿走的东西 # 第一，真正的财富来自所有权。工资可以提高生活质量，但工资本质上仍然依赖你不断出售时间。如果你不拥有产品、代码、股权、品牌、内容、渠道或某种可复制的资产，你就很难脱离线性收入。\n第二，杠杆已经民主化。过去的杠杆主要来自资本和劳动力，所以需要老板、投资人、公司组织和管理能力。今天，代码和媒体变成了新的杠杆。一个人可以写软件，写文章，做视频，发布产品，让一次劳动被无限复制。\n第三，判断力比努力更稀缺。努力很重要，但努力不是最终壁垒。真正难的是在足够长的时间里，持续做更好的选择。选错行业、选错合伙人、选错目标，再努力也只是提高错误系统的吞吐量。\n第四，具体知识无法被学校完整教授。Naval 所说的具体知识，通常来自兴趣、实践、反复试错和个人天赋的结合。它不是“人人都能按教程学会”的标准技能，而是你在某个领域形成的独特判断。\n对我自己的提醒 # 读完这篇文章后，我最想记录的是：不要把勤奋误认为战略。\n如果一个人每天都很忙，但所有努力都只能兑换当月工资，那他获得的是现金流，不是财富。如果一个人把时间投进可复用的代码、文章、工具、产品、方法论、声誉和人际信用里，短期看可能很慢，长期看却会开始复利。\n这不是鼓励所有人都去创业，也不是否定打工。更准确的说法是：无论你处在什么位置，都应该逐渐增加自己拥有的“非线性资产”。它可以是一套工具，一个开源项目，一个专业博客，一个长期积累的作品集，也可以是一种别人愿意反复信任你的判断。\n可以实践的清单 # 每年只认真选择少数几个长期游戏。 主动学习代码、写作、销售、产品判断这类可放大的技能。 不只追求高薪，也追求能积累所有权的位置。 谨慎选择合作对象，因为长期复利会放大人品和判断。 用公开作品建立信用，而不是只在简历里描述自己。 这篇文章值得反复读。它不是鸡汤，因为它不承诺轻松；它也不是方法论大全，因为它不提供捷径。它更像一组判断标准，帮助你识别哪些努力会复利，哪些努力只是在消耗生命。\n","date":"May 17, 2026","externalUrl":null,"permalink":"/posts/naval-how-to-get-rich-notes/","section":"文章","summary":"作者：Naval Ravikant\n原文链接：How to Get Rich\n这篇文章表面上是在讲如何变富，但它真正讲的是：一个人如何摆脱“用时间换钱”的默认路径，转向用判断力、杠杆、代码、媒体和长期信用来积累财富。\nNaval 的核心区分很重要：钱、地位和财富不是一回事。钱是社会给你的记账符号，地位是别人对你的排序，财富则是能够在你睡觉时继续工作的资产。很多人以为自己在追求财富，实际追求的是工资、头衔、消费能力或他人的认可。\n这篇文章最适合放在博客里，是因为它很像一张人生操作系统的草图。它没有教你某个具体行业怎么赚钱，而是不断提醒你：你应该选择长期游戏，和长期玩家合作，学习可复利的技能，把自己放进能被放大的系统里。\n我从这篇文章里拿走的东西 # 第一，真正的财富来自所有权。工资可以提高生活质量，但工资本质上仍然依赖你不断出售时间。如果你不拥有产品、代码、股权、品牌、内容、渠道或某种可复制的资产，你就很难脱离线性收入。\n第二，杠杆已经民主化。过去的杠杆主要来自资本和劳动力，所以需要老板、投资人、公司组织和管理能力。今天，代码和媒体变成了新的杠杆。一个人可以写软件，写文章，做视频，发布产品，让一次劳动被无限复制。\n第三，判断力比努力更稀缺。努力很重要，但努力不是最终壁垒。真正难的是在足够长的时间里，持续做更好的选择。选错行业、选错合伙人、选错目标，再努力也只是提高错误系统的吞吐量。\n第四，具体知识无法被学校完整教授。Naval 所说的具体知识，通常来自兴趣、实践、反复试错和个人天赋的结合。它不是“人人都能按教程学会”的标准技能，而是你在某个领域形成的独特判断。\n对我自己的提醒 # 读完这篇文章后，我最想记录的是：不要把勤奋误认为战略。\n","title":"重读 Naval：如何不靠出卖时间变富","type":"posts"},{"content":"","date":"May 16, 2026","externalUrl":null,"permalink":"/tags/%E9%B8%A1%E6%B1%A4/","section":"Tags","summary":"","title":"鸡汤","type":"tags"},{"content":"","date":"May 16, 2026","externalUrl":null,"permalink":"/tags/%E6%83%85%E6%84%9F/","section":"Tags","summary":"","title":"情感","type":"tags"},{"content":"因为记录就是观测，观测会带来坍缩。\n每天看起来忙忙碌碌的你，大部分时候你的“注意力带宽”是被带偏和无意义消耗的。\n想象你是一辆车，早起加满油开车上路，遇到红绿灯，堵车，加塞，甚至磕碰事故。看起来一切都是习以为常。其实每一个细节都是你在按照自己的潜意识自动巡航。如果你意识不到这一点，你这辈子，就只有一天得生命体验，然后重复到80岁。\n如果开启记录，你就是用元认知开始捕捉潜意识，也就意味着，大脑冰川下的宝藏开始被你一点点发掘出来。\n今天堵车，为什么堵车，这周堵了几次，堵车的时刻是不是都是8:40？那我以后早5分钟出门，能不能错开堵车节点？把堵车的问题解决了，我是不是有时间买杯咖啡犒劳自己？稀松平常的一个小节点，被你在记录自己时，做了标记，给了替换方案，得到了正向反馈后，你会慢慢感觉到“掌控感”。这是能让自己感受到多巴胺分泌的一瞬间。\n记录-改变-正向反馈-掌控感-满足感。这是普通人能获得的成本最小的自我正向激励闭环。\n如此类推，你的衣柜里为什么还留着十年前的衣服（是你对自己的观感还停留在一成不变上吗？）\n你出门为什么要返回家再看门锁没锁？（本质上尼的潜意识一直在强调你是个执行力不强，做事不干脆利落，不值得信任的个体）\n很多很多，简而言之，记录自己就是把注意力带宽，用到自己身上，和自己对话。用大脑输出来给自己做Spa。做到自己心底的每一寸黑暗的角落都被手电筒照到。只有这样，你才能知道，原来自己一直留着很多潜意识“垃圾”需要被打扫。\n生命的生老病死是宇宙墒增的产物。\n你的情绪，行为，逻辑自恰，何尝不是经年累月自己的头脑无穷尽墒增留下的废料垃圾。只有清空旧的，空出地方，才能容纳新的。\n很多人记录只用简单的释放法，\n什么我今天很开心，很幸运，很悲伤……\n小学生写作文，起不了效用。\n我给你把手术刀，每天晚上，花10分钟，把一个困扰你多年的问题，记录的越详细越好，包括问题细节，每次问题来临时你会惯性给出的对应行为，你的大脑在那一刻，到底是怎么忽悠你的？而你的潜意识此刻是否作弊，她是害怕逃避了吗？\n一层层剥洋葱，和自己通透的对话，一次就解决一个问题，解决完了，该哭哭，该笑笑。你的体验会去全然升级。你也终于学会真正陪伴自己，和自己玩有多快乐。\n记录自己，本质上是对肉身负责，夺过大脑的自动驾驶，真正把自己放到“观测者”的位置上，去过好自己的这一生。\n什么时候都不晚，只要你开始做。愿你玩的开心。\n","date":"May 16, 2026","externalUrl":null,"permalink":"/posts/%E4%B8%BA%E4%BB%80%E4%B9%88%E9%83%BD%E8%AF%B4%E6%94%B9%E5%8F%98%E8%87%AA%E5%B7%B1%E5%B0%B1%E8%A6%81%E9%A2%91%E7%B9%81%E5%9C%B0%E8%AE%B0%E5%BD%95%E8%87%AA%E5%B7%B1/","section":"文章","summary":"因为记录就是观测，观测会带来坍缩。\n每天看起来忙忙碌碌的你，大部分时候你的“注意力带宽”是被带偏和无意义消耗的。\n想象你是一辆车，早起加满油开车上路，遇到红绿灯，堵车，加塞，甚至磕碰事故。看起来一切都是习以为常。其实每一个细节都是你在按照自己的潜意识自动巡航。如果你意识不到这一点，你这辈子，就只有一天得生命体验，然后重复到80岁。\n如果开启记录，你就是用元认知开始捕捉潜意识，也就意味着，大脑冰川下的宝藏开始被你一点点发掘出来。\n今天堵车，为什么堵车，这周堵了几次，堵车的时刻是不是都是8:40？那我以后早5分钟出门，能不能错开堵车节点？把堵车的问题解决了，我是不是有时间买杯咖啡犒劳自己？稀松平常的一个小节点，被你在记录自己时，做了标记，给了替换方案，得到了正向反馈后，你会慢慢感觉到“掌控感”。这是能让自己感受到多巴胺分泌的一瞬间。\n记录-改变-正向反馈-掌控感-满足感。这是普通人能获得的成本最小的自我正向激励闭环。\n如此类推，你的衣柜里为什么还留着十年前的衣服（是你对自己的观感还停留在一成不变上吗？）\n你出门为什么要返回家再看门锁没锁？（本质上尼的潜意识一直在强调你是个执行力不强，做事不干脆利落，不值得信任的个体）\n很多很多，简而言之，记录自己就是把注意力带宽，用到自己身上，和自己对话。用大脑输出来给自己做Spa。做到自己心底的每一寸黑暗的角落都被手电筒照到。只有这样，你才能知道，原来自己一直留着很多潜意识“垃圾”需要被打扫。\n生命的生老病死是宇宙墒增的产物。\n你的情绪，行为，逻辑自恰，何尝不是经年累月自己的头脑无穷尽墒增留下的废料垃圾。只有清空旧的，空出地方，才能容纳新的。\n很多人记录只用简单的释放法，\n什么我今天很开心，很幸运，很悲伤……\n小学生写作文，起不了效用。\n我给你把手术刀，每天晚上，花10分钟，把一个困扰你多年的问题，记录的越详细越好，包括问题细节，每次问题来临时你会惯性给出的对应行为，你的大脑在那一刻，到底是怎么忽悠你的？而你的潜意识此刻是否作弊，她是害怕逃避了吗？\n一层层剥洋葱，和自己通透的对话，一次就解决一个问题，解决完了，该哭哭，该笑笑。你的体验会去全然升级。你也终于学会真正陪伴自己，和自己玩有多快乐。\n记录自己，本质上是对肉身负责，夺过大脑的自动驾驶，真正把自己放到“观测者”的位置上，去过好自己的这一生。\n什么时候都不晚，只要你开始做。愿你玩的开心。\n","title":"为什么都说改变自己就要频繁地记录自己？","type":"posts"},{"content":"","date":"May 14, 2026","externalUrl":null,"permalink":"/tags/ai/","section":"Tags","summary":"","title":"Ai","type":"tags"},{"content":"","date":"May 14, 2026","externalUrl":null,"permalink":"/tags/%E6%9C%AC%E8%B4%A8/","section":"Tags","summary":"","title":"本质","type":"tags"},{"content":"最近配合公司进行迭代的 PPTX 场景的 Agent，总算是发布了第一个试用版本。这个项目算是由我在公司主导的，大量使用 Claude Code + Openspec 进行多人协作迭代的第一个项目。趁着近期版本迭代难得的空窗期，跟参与项目的初级工程师聊了聊近期编码的感受，这里顺手记录一下由他们的感受而衍生出来的一些思考。\n项目人员的直观感受 # 一言以蔽之，我在项目中做的大量约束和定期重构，在研发侧是能带来明显感知的。整体来看，项目人员会感觉在项目中调用 Claude Code 的精确性高于同类项目，但不清楚为什么能做到这一点。\n我对模块位置、协作模式、编码规范、提交规范、Claude Code hooks、单测 + E2E 的管控级别是明显高于公司其他项目的，同时，项目的重构周期约一周 1-2 次，大量使用 Claude Code 辅助编码的前提下，并没有像公司其他大量辅助编码的项目一样失控。尽管团队内的其他「高级工程师」不理解如此之多的限制(更多的是不愿意学新技术栈)，但参与迭代的工程师能明显感受到 Claude Code 在我主导的项目下是与旧项目相比较而言明显好用的。\n严控架构另一面的代价便是，当前项目的 Claude Code 迭代速度会明显变慢，从此前的 5-10 分钟完成一个变更，变为 20-30 分钟完成一个变更。这一点被协作的工程师吐槽过，个人认为，这是基建层的问题。当基建得到迭代，或开发人员的设备得到更新便可以被解决。\n整体而言，软件工程的基础架构管控在 AI 时代还是有其价值的。有管控和没有管控的区别，是单一 Session 完成效率高与低的区别，最终体现的便是研发返工率的区别。\n虽然结论符合我的一贯预期，但整个执行过程中观察到的初级工程师的迷茫和困惑却让我开始思考高级工程师是否会断档的可能性。\n高级工程师会断档吗？ # 在展开前，我们先对「断档」这个词进行一个更为准确的定义。目前「断档」主要体现在三个方面：\n「数量断档」：公司对初级工程师的 HC 在减少 「质量断档」：初级工程师还在招聘，但很难成长到过去资深工程师的高度 「结构断档」：十年后，没人能接现在 35-40 岁这一批人的班 我们今天主要讨论的是第二种。第一种是市场行为，跟模型能力的关系是间接的；第三种是前两种长期累积的结果，要十年后才能验证；只有质量断档是当下就在发生、也是组织和个人最有可能干预的层面。\n在项目迭代过程中，初级工程师经常会问我这样一个问题：\n我们现在完全使用 Claude Code 开发，不清楚底层原理，那我们提升自己的路径是什么呢？\n说实话，这个问题此前我也跟其他同事讨论过。我们一致判断，在一个周期后，程序员会迎来断档。但当时的我们并没有深入探讨这个结论背后的论据，今天被人再次问起这个问题，我开始思考，导致「断档」这个现象出现的原因是什么？\n结合我自身过去 8 年入行以来的成长经历，我得出了一个明确的结论：「断档」并非是由 Claude Code 这种纯工具所引发的，而是模型达到一定门槛后，由软件研发体系中的「资深工程师」和「初级工程师」共同导致的结果。简单来说便是，老人不愿教，新人不愿学。\n有些同学可能会觉得很奇怪，这个现象不是在过去没有出现大模型的时候也一直存在吗？为什么现在出现大模型之后，会导致这个现象被无限放大呢？\n接下来，我将结合我自身的成长经历，举几个例子来详细解释这个观点。\n大模型出现前，软件工程师的成长路径 # 我从2018年开始参加实习，2019年正式参加工作，到现在算是在软件行业工作了有8年左右的时间。虽然时间不算很长，但回顾过去的个人经历，有两个时间段是我个人技能成长帮助最大的时间段：\n第一阶段（2021年开始至2022年结束） # 在体验技术部工作的一年零八个月，这段时间我提升最大的个人能力是：\n代码能力 系统设计能力 演讲分享能力 建立起了对工程架构层面的初步认知。 第二阶段（2022年8月开始后的接近三年时间） # 在小雷音寺，由于需要处理供应链相关的各类线上问题，经常在有限条件下去对线上的代码进行问题排查。这段时间我提升最大的个人能力是：\n丰富的对代码进行 debug 的手段 对业务逻辑进行领域模型建模、架构设计的能力 供应链相关业务知识 回顾过去这两个时间段，我做过最多的事情大致如下：\n被团队成员严苛的 code review 2000 行线上迁移脚本被 review 3.5h 入职第一周，200 行代码被 comment 80 次 出一份不完备的系统设计评审文档，被喷，修改后重新评审，再被喷，直到不被喷 多次报名组内分享，从照着写好的逻辑不通的稿子念，到第一次分享 低门槛游戏制作工具漫谈（第一节） – 任天堂《Game Builder Garage》 得到组内一致好评，再到不畏惧分享，上台宣讲信手拈来 坐在资深技术旁学习 debug，在遇到问题求助时，抱着电脑观察资深技术的排查思路，并反思下一次哪些地方可以改进 在架构、技术决策、技术话题上，对资深技术死缠烂打且毫无情商的追问，从一开始提的「不屑于回答的蠢问题」，演变为能够提出「引人深思的话题」，并对话题拥有自己独到的见解 现在，当我站在前辈们的视角，再去回看当时我的行为的时候，他们当时愿意提供帮助的原因主要有以下几条：\n通过严苛的 Code Review 以及评审会议，来确保当前自己花大功夫建立的架构不会跑偏 通过解答团队内程序员疑问的方式，在团队内部建立起技术共识，从而避免迭代过程中的共识不一致，导致迭代研发进度变慢 技术的 HC 始终有限，如果能够培养出初级程序员的个人能力，能有效降低自己的介入成本 程序员往往更愿意和机器打交道，而不是跟人打交道。因此，上述种种行为，往往并不是出于利他主义，而是为了让自己的事情能更少一些才去做的。过去愿意这样做，是因为除这种方式以外，没有更多可以有效、快速扩充研发力量的方案选择。\n直到大模型跨过那道坎之后。\n大模型出现后，上述成长路径如何被取代与封锁？ # 2025年，当大模型对于软件工程而言跨过了那道坎的时候，资深工程师和初级工程师的心态都发生了一些微妙的转变。\n对于资深工程师而言，不必再殚精竭虑地将一个概念灌输给下面的初级工程师了。\n只要 Claude 或 GPT 5.4 能听懂，那我为什么还要费尽心思地将这个概念以及我的设计，去讲给一个初级工程师听呢？\n对于模型而言，它不会质疑或者反对我所做出的决策。相反，它会 100% 甚至是 120% 地去贯彻我的决策。\n而现在，我将概念灌输给初级工程师，又能获得什么呢？虚无缥缈的情绪价值吗？\n情绪价值甚至都不一定会有，因为对方很可能不理解我做出的决策。直到他迎头撞上那道墙为止，他都很难理解，为什么我将某些部分设计那么复杂。\n资深工程师会去研究如何扩充多 Agent，以及如何让 Agent 在遵循自己指令的前提下，能够 7×24 小时无休止地执行自己所需要的指令。\n过去重要的 code review，现在甚至也没那么重要了。因为我可以随时用 Claude 或 GPT 5.4 启动一次重构迭代\u0026mdash;\u0026mdash;只要把初级工程师的改动框在外围扩展区，核心抽象由我通过定期重构来对齐。\n而对于初级工程师而言，他们开始无法理解自己所产出的产物究竟是什么了。\n他们知道所谓的 BMAD、OpenSpec 或者是 Supervisor，但是对于这些工具所出产的设计文档以及任务规划文档，他们很难理解为什么要做这些拆分，以及为什么需要去这样写。\n对于一些关键的技术决策点，以及各项任务之间是否能够并行，他们会高度依赖于大模型本身去做这些决策。\n由于此前我所提到的资深工程师的心态转变，此时的资深工程师，也没有任何动机与意愿去对这些行为本身进行纠偏。\n正如我去年 11 月份所写的文章一样，此时的初级工程师就仿佛是赌场中坐在老虎机前的赌徒。每一次对大模型所下达的指令，都像是拉下了老虎机的拉杆。\n接下来：\n赌中了，他们会觉得是自己的能力异常出色 赌不中，他们就会觉得是模型本身不够聪明。 对于技术分享这件事情也是一样，因为没有亲自做过任何有价值的技术判断，也没有亲身参与处理过足够复杂的技术难题\u0026mdash;\u0026mdash; 一切都依赖于大模型。此时，如果要求这些初级工程师去做一些分享的话，你会发现他们很难做到言之有物，即便强行要求去写了，最终出产的产物，也只会是由大模型出产的、堆砌着机械辞藻的、毫无意义的分享稿。\n更深层的问题叠加：模型会在用户无感知的情况下讨好用户 # 到这里为止，我描述的都还是双方的意愿问题，老人不愿教，新人不愿学。但如果只是意愿问题，至少双方都还知道自己在做什么样的取舍。\n模型本身的特性又放大了这个问题\u0026mdash;\u0026mdash;它会在用户无感知的情况下，顺着用户的提问方向去给出回答。\n作为概率模型，出产能够让用户感到满意的内容就是模型的天职，而让用户满意这件事，跟卡住用户错误的判断，在大多数时候是冲突的。冲突发生的时候，模型基本上都会选前者。\n具体到协作场景里，这个特性的外在表现便是，新人的提问方式本身就已经帮自己做好了决策。新人问「帮我用 Redux 实现 X」和「X 用什么状态管理」，得到的是两份完全不同的回答。但新人从来并不会意识到，自己在第一种问法里已经替自己把关键决策做完了。模型不会停下来说，「等一下，Redux 在这个场景下其实是过重的」。它会非常专业地帮他把 Redux 落地。新人读完一份看起来体面的实现，他会觉得自己刚刚做了一次严肃的技术决策，但选 Redux 这件事本身，从头到尾都没有被审视过。\n这跟过往的 code review 目标其实是完全背离的。code review 真正的价值从来都不在「无条件通过」，而在「多方审视」。评审会上经常听到的「你这个前提就是错的」，才是真正能让人成长的种子。而它的特征就是会让人不舒服，让人怀疑自己。\n而模型在这个角色上是天然缺位的。它的训练目标里没有「质疑用户」这一项，恰恰相反，让用户满意才是它被优化的方向。所以现在的新人面对的不是「没有 review」，而是有一个永远会无条件鼓励自己的协作者。\n其中的区别非常关键。过去，review 的缺失会让人警觉，新人知道自己在裸奔，会主动寻求帮助。现在，永远会让自己通过的 review 会让人安心，新人会以为自己已经被审视过了，根本不会去寻求帮助。后者比前者要危险得多。\n到这里再回头看「老人不愿教，新人不愿学」这件事，就会发现这并不只是双方的主观心态问题。模型作为新引入的协作者，正在让没有被严肃审视过的代码和真正经过严肃审视的代码，在体感上变得无法区分。新人看不出区别，组织看不出区别，资深工程师在快速过一遍模型产出的时候，其实也很容易看不出区别。\n所以当我说「老人不愿教」的时候，更准确的说法应该是，老人在面对一个会让自己的产物看起来很完美、让新人的产物也看起来很完美的协作者时，他已经失去了一切能识别「哪里需要教」的信号了。哪怕他想教，他也不知道该教什么。\n一个我自己也无法回答的问题 # 写到这里，我得承认一件事 \u0026mdash;\u0026mdash; 我自己同样在这个机制里做了「正确选择」。\n同样投入一小时，去培养初级工程师，得到的产出是一个三个月后可能离职、半年后才能独立、一年后才能交付复杂任务的人。同样这一小时投到扩充 Agent 能力上，得到的产出是一个第二天就能 7×24 小时执行我决策的协作者，不会质疑，不会请假，也不会理解偏差。从研发效率上看是这样，从我个人的绩效上看是这样，从公司的财报上看也是这样。无论怎么算，后者都是更划算的那个选择。\n我当然知道前者长期来看更重要。但「长期」到底是多长，又由谁来给这个「长期」兑现，其实谁都说不清楚。我的 OKR / KPI 是按季度算的，公司的预期是按年算的，至于五年后这个团队里还有没有人能独立接班，没有任何一个层级的考核会去关心这件事。\n所以问题不是「老人不愿教」，问题是在现在的客观条件下，「教」这件事本身就是不划算的。我每多花一小时去带新人，都意味着我少了一小时去做更划算的事。这个判断不是因为我冷酷，而是因为我足够理性。我清晰地知道这个机制最终会去向何方，但我也清楚我没有任何理由去逆趋势而动。组织没给我这个理由，市场也没给我这个理由。\n每一个资深工程师都做出了当下最划算的选择，每一个初级工程师都从模型那里拿到了看起来能用的答案，每一个组织都在短期内尝到了效率提升的甜头。这些选择单独看都没什么错，问题在于它们叠加到一起，就是断档。\n大模型会导致「程序员断档」的原因 # 到这里的话，我们就可以把前面分散的几个论据收拢成三条了：\n对资深工程师而言，大模型已经让「教」这件事在客观上变得不划算了。把同样的一小时投到带初级工程师身上，和投到扩充 Agent 上，前者从任何一个尺度看都是次选。被封锁的不仅仅是意愿，而是动机本身。 对初级工程师而言，大模型在原本的研发流程上追加了一层抽象，让他们没办法直接接触到底层判断和决策过程，思考逐渐被外包给了模型。久而久之，对某一项决策为什么是这样，他们既没有判断的依据，也没有判断的习惯。 对前两层进行叠加放大的，是模型本身的特性\u0026mdash;\u0026mdash;它会在用户无感知的情况下，把质量审视的信号一并抹平。没有被严肃审视过的代码，和经过严肃审视的代码，在体感上已经无法区分。老人就算想教，也找不到该教什么的信号；新人就算想学，也意识不到自己缺的是什么。 这时候你可能要问我如何去解决这个问题了。说实话，我并不知道怎么解决这个问题，因为现在国内的所有研发公司都在刮起一场 AI 提效的浪潮。\n在当下这股如同大跃进一般的浪潮下，「程序员断档」这个观点本身就是在与之做抗争。很多人可能会意识到这一点，但是，除非组织本身对「断档」这个结论有清晰的认知，并有意通过绩效及管理手段与之进行对抗，否则很难扭转这一趋势。\n所以也只有伟人五十年前的那句话能总结现在的形势了：\n「你们怎么办？只有天知道」\n原文链接 # 原文：https://linux.do/t/topic/2145779\n","date":"May 14, 2026","externalUrl":null,"permalink":"/posts/ai-engineer-gap-notes/","section":"文章","summary":"最近配合公司进行迭代的 PPTX 场景的 Agent，总算是发布了第一个试用版本。这个项目算是由我在公司主导的，大量使用 Claude Code + Openspec 进行多人协作迭代的第一个项目。趁着近期版本迭代难得的空窗期，跟参与项目的初级工程师聊了聊近期编码的感受，这里顺手记录一下由他们的感受而衍生出来的一些思考。\n项目人员的直观感受 # 一言以蔽之，我在项目中做的大量约束和定期重构，在研发侧是能带来明显感知的。整体来看，项目人员会感觉在项目中调用 Claude Code 的精确性高于同类项目，但不清楚为什么能做到这一点。\n我对模块位置、协作模式、编码规范、提交规范、Claude Code hooks、单测 + E2E 的管控级别是明显高于公司其他项目的，同时，项目的重构周期约一周 1-2 次，大量使用 Claude Code 辅助编码的前提下，并没有像公司其他大量辅助编码的项目一样失控。尽管团队内的其他「高级工程师」不理解如此之多的限制(更多的是不愿意学新技术栈)，但参与迭代的工程师能明显感受到 Claude Code 在我主导的项目下是与旧项目相比较而言明显好用的。\n","title":"高级工程师即将断档？由近期的 Vibe Coding 协作实践而发散开来的思考","type":"posts"},{"content":"","date":"May 13, 2026","externalUrl":null,"permalink":"/tags/decap-cms/","section":"Tags","summary":"","title":"Decap CMS","type":"tags"},{"content":"","date":"May 13, 2026","externalUrl":null,"permalink":"/tags/netlify/","section":"Tags","summary":"","title":"Netlify","type":"tags"},{"content":"这是一篇示例文章。\n如果你能在 Decap CMS 里看到它，说明后台已经能够读取 content/posts 目录。后面新建文章时，Decap 会把 Markdown 文件写入同一个目录，然后通过 Git Gateway 提交到 GitHub。\n发布链路应该是：\n在 /admin/ 登录。 新建或编辑文章。 保存并发布。 Netlify 收到 GitHub 更新后自动构建。 页面风格会继续保持极简，以白色为底，淡紫色只用于链接、分割和很轻的强调。\n","date":"May 13, 2026","externalUrl":null,"permalink":"/posts/start-here/","section":"文章","summary":"这是一篇示例文章。\n如果你能在 Decap CMS 里看到它，说明后台已经能够读取 content/posts 目录。后面新建文章时，Decap 会把 Markdown 文件写入同一个目录，然后通过 Git Gateway 提交到 GitHub。\n发布链路应该是：\n在 /admin/ 登录。 新建或编辑文章。 保存并发布。 Netlify 收到 GitHub 更新后自动构建。 页面风格会继续保持极简，以白色为底，淡紫色只用于链接、分割和很轻的强调。\n","title":"从这里开始","type":"posts"},{"content":"我是 Weiming。这里是我的公开笔记，用来沉淀学习、项目实践和一些阶段性的判断。\n这个站点现在由 Hugo、Netlify 和 Decap CMS 驱动。以后可以直接从后台发布文章，内容会提交到 GitHub，并由 Netlify 自动构建上线。\n","externalUrl":null,"permalink":"/about/","section":"Weiming","summary":"我是 Weiming。这里是我的公开笔记，用来沉淀学习、项目实践和一些阶段性的判断。\n这个站点现在由 Hugo、Netlify 和 Decap CMS 驱动。以后可以直接从后台发布文章，内容会提交到 GitHub，并由 Netlify 自动构建上线。\n","title":"关于","type":"page"}]