好是卓越的敌人。

吉姆·柯林斯，《从优秀到卓越》

年终总结拖到二月才动笔。想写的东西很多，落笔时又觉得这一年很难用几句话收束，像是被推着走到某个坎上，迈了一步。

生活

2025 年，我继续用照片来记录生活。 不同的光影，落在过去一年的不同时刻。 有些旅行源于一时心动，说走就走；有些则是酝酿已久的奔赴。

经历不同的旅途，遇见各异的风景，触摸历史的温度，也投身自然的怀抱。 转一圈回来，还是要回到自己的生活里，平淡亦浓烈。

富士山山中湖，摄于日本山梨县。

国家清真寺，摄于马来西亚吉隆坡。

霞光落日，摄于马来西亚兰卡威。

婚礼的蓝调时光，摄于大理云想山。

海鸥，摄于大连星海广场。

家中小朋友已经过了随便做什么都显得可爱的年龄。 他开始收到学业的要求：课业、体育、音乐，各类教育轮番上阵。 训练大模型固然困难，训练家中小模型也挺不容易的， 尤其这个小模型一开始就是智力涌现，并且叛逆因子还挺高。😄

家庭生活中，双方亲密关系永远是最重要的支柱。 我和我老婆在温暖、摩擦、包容、依赖中不断调整，寻找更舒服的相处方式。 伴侣是最接近世界上另一个我的形态，好的亲密关系会相互扶持，一起探索和体验世间。

年初设定的 OKR 明显落后，主要受精力投入影响，今年可支配时间比我预期还要少： 阅读与开源项目进展良好，健康与投资几乎停滞。 年底精简了目标，计划再砍掉一批 KR，只保留职业、家庭关系与身体三类。 减少目标帮助更稳定更聚焦，也不用再持续占用注意力去权衡优先级。

工作

回看这一年时，很难用单一词汇去概括。 这既是忙碌的一年，也是成长的一年。

我挑了三个关键词：跃升 / 黑天鹅 / Be True。 它们对应三种感受：能力变化、环境变化，以及对人的重新理解。

年初我启动了一个基础设施项目，负责集团算力资源交付。 在 AI 推理规模快速增长的背景下，这块业务增长速度惊人。 24 年年中我接手了集团的算力交付，一度也是站到悬崖边缘， 穿越风雨，历经艰难才稳住。

困难并不在技术和工程本身，更多是问题定义、持续履约、螺旋严谨。 跨 BU 协作、历史系统复杂、责任边界模糊，却要求极高稳定性。 好在这个项目在资源投入、关注度提升、技术持续升级下，年底有了不错的结果。

年中时我接手团队，尽管业务、工程我都相当熟悉，但如何成事、成人对我来说都是新的命题和挑战。 我一度做梦时都在思考业务和产品发展路线。 还好一段时间就恢复到平静，发展不是靠大炼钢铁，还是要回到工程和产品原则，回到时代发展脉搏上。 我持续在思考到底如何经营好团队，最后我得到两个词：Be True，做正确的事情，做真实的自己，对人对己。

我捋了一份团队和组织的书籍清单，放到这里： Be True 团队和组织

12 月遇到一次黑天鹅生产事故，细节不再阐述，但影响很深远。 这件事并非真正随机。历史债务、责权、安全生产意识不足，必然会在某个时间点集中爆发。 所谓黑天鹅，更多是复杂系统不可预测性的体现。

如何去应对这种不确定性？工程上的问题始终回到第一性原理，去定义问题，去解问题。 业务和团队上，则是要持续围绕客户、解决真实问题，变化只会改变路径。 穿过风暴时，不要被定义，而是自己把定义想清楚。

这一年，AI 对工程工作的影响开始变得具体。 6 月份时我还对 AI Coding 存疑，以为基础设施领域会有更长缓冲期，因为上下文复杂且依赖经验， 但实际体验下来并非如此。使用 AI Coding 工具后，开发效率明显提升，重复劳动减少，探索成本下降。 写代码（Code Typing）未来会成为低效的工程方式，AI Native 应该成为默认选项。 AI 降低执行门槛，同时放大决策质量差异。 能力差距没有被抹平，而是被加速放大：工程师价值逐渐从实现能力转向问题选择与约束设计能力。

个人成长

今年基本没写博客，虽然在内网还是保持每个月有点文字输出，但在社区和自我成长关注上投入非常有限。

回想今年，倒是年初春节时候动心起念，决定一年内完成多邻国英语流程。 130 级打完花了 278 天，起于初春，结束在秋。 接下来我主要围绕 YouTube 和 Bilibili 的原声听力做练习。

书籍继续是我思想的避风港，不管工作如何繁忙，还是可以在书本中寻找到智慧和答案。 去年给自己的期望是深刻又朴素，今年在读书选择上，更多添加了一些哲思、组织的输入。

前主管每个月都在大团队分享会给出他的读书心得，我也获益蛮多。 这是一种蛮难得的体验，我一直觉得读书是一件有点私密的事情，但这种形式也让我受益匪浅， 好几本书都丰富了我的读书范围。 未来我也会学习一下这种思想碰撞和交流方式，不用太在意反馈，回到自己初心。

不拘一格 : 网飞的自由与责任工作法

Netflix 采用了一种与众不同的人才观。 他们提供行业顶尖的薪酬标准，没有采用末位淘汰制， 而是以是否达到岗位标准作为人才留存的核心依据。 在组织决策方面，Netflix 给予员工较高的信任度， 并通过事后审查的方式进行补充。 基于目标（北极星），日常决策采用情境决策模式，而非领导拍板式决策， Context, not Control。

对管理者而言，有哪些可以立即执行的行动？ 第一，提供更多的信息透明度，给予成员更多的技术决策机会， 同时做好事后的效果追踪和复盘工作。 第二，在各种会议中，特别是月会、周会，不断明确和校准团队的「北极星」目标。

仿生人会梦见电子羊吗?

自然人和人造人的边界到底是什么。 长得像鸭子，叫声像鸭子，什么都像鸭子，真的是鸭子么？ 穿过时间叩问一众 LLM 和 Agent。

松本行弘的程序世界

松本行弘这本书我在十几年前就想读， 彼时的我甚至还去面试了一家使用 Ruby 的创业公司。 没想到读完居然是十几年后了。

书中以高手的姿态评点了当时比较热门的语言， 介绍了自己设计 Ruby 时候的思考和品味判断。 书中也讨论了云的出现、算力的增长、分布式的严谨对技术的影响。 高屋建瓴的视角让大部分知识即便放到今天还是不过气。

时光荏苒，物是人非，Ruby 还是局限在 Web 领域， Python 则靠 AI 打了翻身仗。 NoSQL 也是进入了稳态，GPU 占领了计算模式高低， Dart 已经完蛋了，笑。

真希望松本行弘能再出一本新的点评书。

西方思想史十二讲

探索宇宙，探索自身，探索存在和真理，这是西方思想史的研究命题。 历史上提出了许多主张，这些主张都需要逻辑自洽， 要么能够服务人的意义感，要么服务于宗教或者国家， 总之是适应时代、适应威权。 我想，学哲学（思想）的朋友是不是会感慨哲学发展的太慢， 几十年几百年才能演进一点点，有种脱离感，脱离当下朝夕发展的科技速度。 但反过来想，正是因为发展太快，变化太多， 我们更需要寻找到一些自我和世界的确定感和稳定感。

从优秀到卓越

这本书虽然看上去是写给卓越公司管理者的， 谁又不是从一开始就想持续卓越呢，后进生也该看看优等生如何获得成功。 秘诀是：人、思想、行为、持续积累和发展，这是本书的核心结构。 卓越公司需要五级经理人（谦逊、意志、持续贯彻）。 需要去设定方向、远景、战略。 使用刺猬三环分析出：优势、热情、经济增长引擎。 认清信念（憧憬成功）和原则（面对困难）。 经典书籍，常读常新。

格鲁夫给经理人的第一课

面向管理本质展开：提升团队杠杆率；识别业务限制步骤；目标管理、时间管理、绩效管理。

看见孩子 : 洞察、共情与联结

没有真正不合格的孩子。 关键是通过耐心和理解去回应真实需求， 即使在困难和变化的时候，也尽量保持自身情绪的稳定去承载孩子的情绪。 这样做其实不仅仅是教育孩子，也在某种程度上再次养育自己。

小米创业思考

无比真诚，相当受用。 本来对小米故事不抱多高的预期，以为是讲故事讲奋斗。 读完之后发现雷军真的是敞开心扉说亮话： 从创业的使命问题到战略问题，从宏观方向到微观管理， 都做了不藏着掖着的分享。 有时候觉得讲企业管理已经变成一个显学， 但是从身边的实际感受来看，世界真的是一个草台班子，有大草台班子小草台班子。 雷军的分享是将管理学很多经典著作映照到现实。 这些道理和经验就应该持续讲，反复讲，持续学习，反复学习。

我看见的世界 : 李飞飞自传

见今年仅有的几篇博客之一： 李飞飞如何获得成功？ - 读「我看见的世界」 | Log4D

置身事内 : 中国政府与经济发展

五星评价，看懂中国经济。

芯片浪潮 : 纳米工艺背后的全球竞争

这本书几乎是台积电发展史， 从台湾当局招商引凤凰，到张忠谋到台湾， 再从代工模式发展到纳米时代各项突破，看得叫一个惊心动魄。 时代给机遇，也需要强人能够抓住。 冒着计算过的风险，跨越式发展，美式管理风格都让人印象深刻。 对中芯国际也有了更深的认识。加油吧。

卓有成效的管理者

推荐给所有电脑前工作者阅读。

不仅仅带团队的 TL 是管理者，知识工作者也是管理者。 德鲁克提出了 5 个核心要点：时间管理、看重贡献、发挥长处、要事优先、有效决策。 对于普通知识工作者来说，我觉得先从时间管理入手，再做好 OKR 管理和关键决策， 关键决策核心点是充分调研、找到核心问题、明确优势、面向未来。 如果有机会管理团队，则要持续关注团队成员长处。

几个主题我也写过一些文字： 时间管理 https://blog.alswl.com/2023/02/gtd/； 决策（技术决策）https://blog.alswl.com/2023/07/architecture-design-the-easy-way/ 。 今年争取再写一个关于目标管理的。

每次学习，都感受到德鲁克洞察本质的思考，常读常新。

我的重生日记

要是人生像大梦一场，关关卡，困难重，到底该怎么办？ 书里写的是作者生病的经历。 现在大家活得越来越久，生病这事，自己或家人都很可能碰上， 这本书就像个真诚的朋友，把生病后的种种感受和经历，一点不藏地告诉我们。 作者生病后日子特别难熬，书里把这些痛苦都写出来了。 他一边和病魔斗争，一边在心里给自己打气， 这些描写很真实，让我们能感受到他的害怕、坚持和对活下去的渴望。 面对风暴的办法只有一个，穿过去。

简读日本史

富士山的壮丽美景都历历在目。 漫步在东京国立博物馆中，我曾隐隐觉得其历史底蕴稍显单薄， 部分瓷器藏品也显得简陋，直至幕府时代的展品出现，才让人眼前一亮，印象深刻。 而读完这本书我才明白，在大化改新之前，日本的开化程度确实较低， 这也解释了博物馆早期展品相对逊色的缘由。

「山川异域，风月同天」这句诗我们并不陌生，甚至有人说中日同文同种。 但事实上，日本的发展历程有着自己的曲折轨迹， 它历经无序、混乱、贫苦与自卑，也有过爆发式的变革。 如今，日本已然成为东亚文明的重要代表之一， 拥有独特的精神内核与国民性， 与中国既有文化传承上的关联，又走出了截然不同的发展道路。

DevOps实践指南（第2版）

我一开始有点轻视这本书，想着自己搞了这么久，工程和方法论应该都是耳熟能详。 但细看之后感觉挺高屋建瓴的，写得很简练精要， 有一些观念梳理比自己想要结构化很多。

有几个印象深刻和反直觉的点：

1. 价值流对 DevOps 落地很重要，要帮助上下游团队解决他们的问题
2. 多大的权利解决多大的问题，设定目标很关键
3. 20% 时间用来创建用户不可见的正面价值
4. 形成流动，从 Source 到 Product 的流动
5. 指派运维联络人，不要多点联系
6. 建设反馈机制，前期研发 Owner 要自己运维，如果服务质量下降要做退还托管机制

资本论

资本不是洪水猛兽，资本主义也不是洪水猛兽。 资本主义的终局最终会发生么？ 有没有可能进入一个多种资方互相平衡的状态。 政府也出台了反垄断法来避免资本无限扩张， 通过基本的人道主义保障来兜底最底层。 第三册写到资本逐利是根本的问题。 但逐利是一个组织存在的基本要素，人也是逐利的， 商业组织逐利有什么问题么？ 逐利是生命体的表现，是存在的体现，只要不成为社会的癌细胞就行。 金融危机一定是坏事么？ 是不是一个去泡沫、降温过程，那是不是只要是有序的反而是一件好事？ 总体来说，马克思描述了一种在无序、小政府、割据政权下面， 资本主义会走向一个什么最差的结果，以及最终会被社会主义替代。 资本主义是家养野兽，需要套上项圈，让政府进行管制， 不管这个政府是三权分立的还是中央政权。 我怀疑在可预见未来改良式资本主义一直存在， 靠政府治理、反垄断保持着平衡。

论中国

《论中国》这本书基本可以分成两个部分。

第一部分是清末到新中国建立的中国对外外交史。

第二部分就是基辛格自己参与的中美关系发展史。基辛格是一个很有意思的人，他既流露出一种看上去的亲华派，但骨子里还是国家利益至上。他是幸运的，和中国四代（甚至可能是五代）领导人都有近距离的接触，堪称近代历史活化石。

把历史的进程拉近视角，以一个外交官（事实上）的视角呈现出来，可以更有血有肉地反映时代的细节。

相关阅读推荐：B 站大象放映室的晚清最后 13 年，邓小平时代，他改变了中国。（似乎找不到一本有代表性的书来介绍毛泽东晚年的历史。）

尾注

2026 将继续探索发现世界，持续的亲子陪伴和家庭经营，并在 Infra + AI Infra 领域有更多输入输出。

临界不是终点，蓄势待发。

概述

本文阐述一套适用于工程应用开发项目的迭代管理实践，重点解决如何高效低成本推进项目的问题。该方案适用于小型团队协作，核心特征在于固定产研节奏、标准化交付物以及高频异步协作机制。

本文仅针对技术方案与实施路径明确的项目场景，不涉及工程决策或目标管理范畴。本文也更注重实操，注重立即可以上手实施，不会花太多篇幅去解释这套方案背后的思考和原因。

关于实用（Pragmatic） 的定位：该理念贯穿于我的多项实践方案，包括 架构设计 the Easy Way 实用 Web API 规范 如何做好 PRR（Production Rediness Review）？ 等等。实用意味着注重可操作性和实际效果，要领是简单易实施落地，任何人都可以上手执行操作。我对实用的追求来自于《The Pragmatic Programmer》这本书。

注：本文不特定区分项目（Project）和产品迭代（Product Sprint）区别，可以将这里项目管理等同于研发过程管理。

免责申明：没有银弹，本文方法论不一定适合所有场景，并且方案也在持续迭代。如果你的项目有 PM，请优先咨询 Ta。

Mural of La Bre Tar Pits（C.R. 奈特雷阿的焦油坑壁画)，图片被人月神话所引用。

在软件项目管理中我们遇到什么问题

软件项目管理常面临各类挑战。就个人经验而言，最直接的困境在于项目无法按期交付。其原因可归纳如下：

• 我的协作方依赖方有问题，他没时间没空或者方案无法满足我
• 需求频繁变更，没想清楚做着做着要改方案，或者实施过程中插入新的需求
• 产出的东西质量不达标，测试阶段一堆问题，迟迟无法交付
• 产出的东西不是想要的，和需求方一对发现偏差太大
• 依赖资源未能及时到位
• 项目计划过于乐观，过度承诺，交付时间比预计的要长，工作量比预期大，难以完成
• 工程难度大，实施过程遇到技术风险，成本高或者难以完成，
• 多项目进行，人力资源挤占
• 多项目并行导致工程上无法满足
• 项目成员的档期不一致，无法有效协作

问题不可怕，定义清楚问题就成功了一半，回到问题本身，让我们来看如何解决。

问题根因分析

现实中遇到的问题可能更多，我分分类说到底是这么几个原因：

• 需求问题：描述模糊、频繁变更及沟通未对齐
• 协作问题：衔接断层、预期差异及信息同步失效
• 时间问题：周期限制及过程中突发需求插入
• 工程问题：技术实现难度超预期或成本制约

我的项目管理最佳实践

基于上述问题分析，我将这些问题的解法归到几个方向：节奏、交接物、协作。

注意，本文不聚焦解决工程难度问题，也不解决架构师要解决的问题，最多能从项目管理的思路来降低技术风险。

另：对架构问题如何处理问题请移步 架构设计 the Easy Way ；遇到了具体工程难题的同学请咨询团队技术专家。

节奏 - 固定产研节奏比 ddl 更重要

什么是项目的节奏，什么是好项目节奏？

项目节奏的本质在于建立可预期的周期化交付机制。相较于单纯设定最终截止期限（Deadline），采用 Scrum 敏捷框架中的冲刺（Sprint）模式更为有效。每个冲刺构成包含需求分析、设计、开发、测试及上线的完整闭环。良好的迭代节奏具备三重价值：1. 建立明确的时间预期，实现周期化交付；2. 强制需求拆解，推动产品从最小可行版本（MVP）向完善形态演进，避免关门憋大招，最后拉了一泡稀的；2. 规避长期封闭开发导致的交付风险，最怕大搞 58 天，最后 2 天都交不了货

双周迭代

一个好的迭代周期多长比较合适呢？在小型团队协作里面，最长不要超过 1 个月，尽量保持在 2 周，最好能做到 1 周。以一次迭代的周期来看，我自己体感是 1/2 时间用来设计， 1/2 用来建设（开发测试和上线）。不要低估设计花费时间，投入少了后面想追也追不会来。

迭代管理需设置专职迭代经理，该角色承担三项核心职责：规划迭代排期、协调各类会议安排、核验交付材料规范性（依据标准化模板执行，不负责方案质量，材料质量由架构师+下游签收）。此岗位实质承担部分项目管理职能，若短期内无合适人选，应由项目负责人兼任。迭代经理通常从项目成员中产生，建议实施轮值机制。轮岗制度具有双重价值：使成员亲身体验管理挑战，促进跨角色理解；同时通过岗位实践识别流程瓶颈，推动协作机制优化。执行时需确保轮值期间管理职能的完整履行。

高频迭代带来的不少附加优势：直接化解了需求插入问题（任何需求最长等待周期 ≤1 周），紧急需求则通过紧急修复流程（hotfix）处理；大型需求必须进行拆分验证，无法拆解者需通过概念验证（PoC）先行评估技术风险。

迭代中评估需求耗时

这是一个一直被提及的问题，我有两个方案来解决，第一个是提供一个需求时间评估公式：工作量 = （最乐观 + 最悲观） / 2。

第二个是避免搞大需求，所有需求需要评估一下规模，我提供这几种级别标准，extra-large（月级别）/ large（周级别） / medium（天级别） / small（小时级别），我不接受 xl / l 需求，必须拆成 m / s。

需求时间评估是一个普遍存在的挑战，我提出两种解决方案。

第一种方案采用工作量估算公式：工作量 = （最乐观 + 最悲观） / 2。这个公式相当实用，比单一指标更多考虑到不确定性。（其实我还有一套更复杂的通过技术采纳性角度的评估方式，但是不如上一个公式简单易操作）

第二种方案聚焦需求规模控制，要求所有需求划分规模级别，包括 extra-large（月级别）、large（周级别）、medium（天级别）和 small（小时级别）。迭代中要尽量避免 extra-large 与 large 规模需求，将其拆解为 medium 或 small 规模后再行处理。

迭代范例

我们的一个实际案例分享，这是 我负责 产品的 7 月 两个迭代，分成 07a 和 07b 两个迭代。

交接物 - 标准化每个环节输入和交付物

软件的不可见性和抽象性是导致软件复杂性的根本原因。

清楚明确的交接物可以有效降低不可见性和抽象性，这是用来抵抗交付复杂性的核心武器。掌握这个核心武器的最重要口诀是：写下来。

把你的长远需求规划写下来，不管是年度计划，还是月度计划。把你的需求明细写下来；把你的系统设计写下来；把你的发布功能写下来；

整个过程中，我推荐使用到这些面向项目管理的交接物，大部分交接物我们都耳熟能详，但请特别注意我这里的最佳实践：需求清单和 Release Note。

下面我会展示一些我实践的需求范例（可能来自不同的产品和迭代）。

需求清单范例

这是我使用的需求清单范例：

需求文档范例

需求文档模板：

需求标题：简洁明了地描述需求 用户角色：谁会使用这个功能 用户目标：用户想要达成什么 前置条件：使用该功能需要满足的条件 主要流程：详细描述用户如何使用该功能 替代流程：描述可能的例外情况 验收标准：如何判断需求已经被正确实现

一个需求文档范例（文字型）：

视频发布流程 MVP

用户角色：内容运营者 需求标题：用户上传视频并完成自动化发布流程 用户目标：

• 运营者通过标准化流程完成视频从上传到发布的完整生命周期管理。
• 关键步骤自动化处理（如转码、审核），减少人工操作，关键节点保留人工确认机制。
• 支持异常处理（如审核失败、转码错误），允许人工介入重试或跳过。

主要流程

1. 创建视频发布任务
   • 用户上传原始视频文件（支持主流格式：MP4/MOV/AVI）
   • 填写基础元数据（标题、分类、标签、封面图）
2. 自动化预处理
   • 转码引擎：自动生成多分辨率版本（1080P/720P/480P）
   • 内容审核：
     • AI自动审核（敏感画面、违禁内容）
     • 若AI审核通过 → 进入发布队列
     • 若AI审核失败 → 暂停流程并通知人工复审
3. 人工确认节点（流程暂停点）
   • 人工复审：运营者在后台查看AI标注的违规片段，选择：
     • 通过（继续流程）
     • 驳回（需编辑视频后重新上传）
     • 强制跳过（需填写跳过原因）
4. 发布执行
   • 自动推送至指定发布渠道（Web/APP/第三方平台）
   • 生成可跟踪的发布ID（用于效果分析）
5. 异常处理机制
   • 转码失败：自动重试（≤3次）→ 仍失败则通知人工
   • 发布中断：支持手动重试/跳过/终止任务

替代流程

• 转码模块不可用：允许上传预转码视频文件（需符合分辨率规范）
• AI审核服务宕机：切换为全人工审核模式（需在SOP中注明应急预案）

验收标准

1. 全流程验证：
   • 运营者从上传到发布成功耗时 ≤15分钟（不含人工审核等待）。
   • 模拟审核失败场景，人工强制跳过步骤后流程可继续。
2. 异常处理验证：
   • 转码失败时，系统自动告警并允许手动替换文件。
   • 发布中断后重试，视频状态可恢复至中断前节点。
3. 文档交付：
   • 提供《视频发布SOP手册》，含人工操作指引及故障处理方案（A负责维护）。

产品 Release Note 范例

Discord 的 Change Log（Release Note）发布大纲，没有前端产品用那么多 emoji。

妙言 tw93/MiaoYan 的某个 Release 更新日志：

产品使用手册范例

我建议可以使用基于 Git 仓库管理的 markdown 方案，比如 MkDocs 这类方案：

我推荐的范例是 NebulaGraph Operator 的文档范例，注意这仅仅是 NebulaGraph 的其中一个子产品，但是规模更小更适合起步。

关于交付物，特别是文档类型的交付物，虽然我列了这么多类型，但是我认为一定不要写多写复杂，提纲挈领，量少为宽。

高频异步沟通 - 同步和异步 风险和透明

不要陷入巴别塔。

在分布式协作场景下，需建立「异步为主、同步为辅」的沟通范式，重点解决信息孤岛、风险滞后及依赖阻塞三大痛点。有效的协作机制应包含三个核心要素：全局可视化任务管理、结构化风险预警及精准化依赖协调。

我讨厌开会，甚至从某种意义上我痛恨开会。我之前写过关于会议的暴论：

这个月代码写得太少了，会议时间占据了 1/3，这很可怕。

会议很低效，很低效，很低效。有些会缺少材料准备，问题不聚焦，主持人不控场，一拉一大把人，不少人又不好意思走就硬挂着。

如果我有权利，我甚至想禁止公司开会，全都回归到基于文档的异步交互模式。

还是多建设，少空谈，有明确主张，材料提前分发，开会不当聋哑人，非干系勇敢离开会议。让大家回到方案设计和代码上吧。

有效沟通需规避信息失真，核心在于建立风险透明机制与依赖协同体系。具体实施包含三个维度：全局可视化看板：实时呈现任务进度与风险状态；精准进度追踪：量化每个节点的完成度；异步协作平台：通过在线任务管理工具（如 Jira）实现全周期信息同步。

开两种会 - 方案评审和日会

我们不需要开会了么？还要，但是只要两种：方案评审会与日会。

评审会的要点在于：

1. 明确评审会的对象是谁，谁负责为方案点头，没有人负责点头的会不用开，既没有对抗又没有讨论，是纯走过长
2. 不要做无准备的讨论，在方案宣讲之前，尽量先和受众对象达成一致，让评审会变成一个宣讲会
3. 评审会要有结论，通过还是不通过要有人确认。通知之后的执行项全部落入在线协作平台，特别是需求类，一定要记录，这是未来日会跟踪的依据

日常进度沟通模式，我推荐每日站会沟通，最少也得双日沟通（每周二、四）。每天都进行站会同步，每次 15m 搞定。一般一个项目成员在 7 人左右（披萨原理），每人一两分钟。

站会的主持人很重要，要引导参与人同步进度，同步风险，寻求帮助，帮助需要有明确的接收方。

基于看板的在线沟通

核心准则：以文档异步协同为基础，将同步会议压缩至必要场景，最大化建设性工作时间。

下面是会议看板范例，根据迭代过滤，根据 Assginee 分组（其实也很普通，没什么特别的）：

每天迭代经理在日会上面就是拿着这个看板，先明确我们几号提测几号上线，再挨个成员自述进展如何，最后挨个问有没有上线风险。

最后

没有万灵的项目管理机制，根据自己面临的问题进行实际调整。本文的命题对我（一个开发工程师）来说也是极具挑战。我在过去有多次因为项目无法交付问题失眠无法入睡。现在来看，其实大可不必，平常心来应对问题，对预期内问题建立预案，对计划外变更保持弹性。当团队已完成可行性范围内的最大努力，即应视作有效交付。项目管理的终极目标，是在资源约束下实现可持续的技术价值输出。

扩展阅读

人月神话 (豆瓣) 软件工程项目管理的圣经，20 年后读起来仍然觉得字字珠玑。

项目管理修炼之道 (豆瓣) 这是我的项目管理入门指导书，更通用更适合 PM。我写过一个读书笔记 《项目管理修炼之道》笔记 | Log4D。

代码之殇 (豆瓣) 作者是微软高级架构师/管理者，而本书实际上是一个随笔式的文章集合。尽管如此，书中的许多观点犀利且具有独特的见解，展现了从一线到高层的全方位视野。其中关于工程过程管理（比如死亡行军）事项，确实值得深思。

读一本好书，就是和许多高尚的人谈话 - 歌德

第一次听闻李飞飞的名字，是在 2013 年与前公司 CTO 的中午干饭闲谈中。 彼时他正深耕 CUDA 并行计算领域，反复提及 ImageNet 竞赛与 AlexNet 的突破性表现， 而我对这场即将席卷全球的深度学习革命尚处懵懂——当时全身心投入业务系统优化， 面对「算法黑箱」既无暇探究，更难预见其对技术世界的重构力量。

如今读到李飞飞自传，方觉这场对话暗藏玄机：那个曾被视作实验室小众技术的计算机视觉项目， 竟成为改写 AI 发展轨迹的关键节点。在学科交叉处开疆拓土的战略眼光，在技术拐点期破除质疑的前瞻判断， 以及贯穿始终的"北极星"式价值锚点——这些要素如何在特定历史坐标中交汇， 最终塑造李飞飞成为改变机器认知方式的科学家。

李飞飞如何获得成功

好奇心是原动力

李飞飞的成就源于多重维度的深度交织。其科研旅程始于对世界本质的探索欲。父亲带她 观鸟、捕捉昆虫的经历，在她心中种下好奇的种子，而母亲引导的跨学科阅读（涵盖海洋 生物、机器人、神话等）则拓宽了她的认知边界。中学时期她对航空航天等冷门领域的痴 迷，更展现出对抗性别偏见的独立思考能力。这种探索精神在普林斯顿大学攻读物理学时 得到深化，她将物理视为「西方科学最高深的创造性学科」，以此锤炼逻辑思维。这种对 知识本质的追求，成为她转向人工智能研究的底层动力。

逆境中的坚韧与适应力

逆境中的韧性塑造了她的核心竞争力。移民美国初期，语言障碍与经济压力如影随形。她 通过多重兼职（中餐馆打杂、家庭保洁、干洗店经营）维持生计，却仍以 SAT 数学满分的 成绩进入普林斯顿。更艰难的是母亲重病期间，她在手术室旁穿着隔离服完成学业，同时 充当医患翻译，展现出极限压力下的抗压与时间管理能力。外界质疑（如教师贬低女性数 理能力）反而强化了她「超越现实障碍」的信念。

大平台才能让你起飞

顶尖平台的阶梯式跃迁为研究提供了关键支撑。普林斯顿时期奠定其学术基础，并促使她 转向计算机科学。加州理工学院攻读博士期间，她选择当时冷门的计算机视觉方向，在神 经科学与 AI 的交叉研究中确立「让机器理解人类视觉世界」的核心命题。斯坦福大学时 期，她创立人工智能实验室（SAIL），将 ImageNet 从构想变为现实。后续在谷歌的产业 实践，则加速了技术落地与应用转化。

风口与机遇

把握技术拐点的决断力最终引爆突破。2006 年 AI 寒冬期，创建海量数据集被视为「学术 自杀」。面对终身教职可能受阻的警告，她创新采用亚马逊众包模式，发动全球数万人协 作标注，解决人工需耗时百年的难题。2012 年 ImageNet 竞赛中，GPU 算力支撑的 AlexNet 以压倒性优势胜出，验证了数据驱动路线的正确性，直接推动深度学习革命。

AI 科学与人文融合

李飞飞独特的 AI 哲学观始终指引其技术路径。她批判当时学界对算法的过度专注，提出 计算机视觉的瓶颈在于缺乏「视觉常识」。ImageNet 的构建（1500 万图像/2.2 万类别） 本质是为机器建立认知世界的「视觉图谱」，其初衷是赋予 AI 感知现实的能力，而非单 纯追求技术指标。这种将人文认知融入技术设计的理念，后来成为斯坦福「以人为本人工 智能研究院」（HAI）的核心理念。

作为父母我应该如何教育小孩

李飞飞的成长轨迹为家庭教育提供了深刻启示：她的父母并非教育专家，却以最朴素的方 式践行了「守护好奇心」与「培养独立人格」的核心理念。

关注孩子对自然世界的探索。父亲是李飞飞科学启蒙的「引路人」。他带着女儿在成 都街头观鸟、捕捉竹节虫、观察水牛，将自然视为开放的实验室。这种实践教育不仅培养 了她对生命现象的敏锐观察力，更塑造了「提问—探索—验证」的科学思维雏形。当同龄人 被规训于课本知识时，李飞飞已通过昆虫的复眼结构理解光学原理，从鸟类迁徙模式感知 生态系统的复杂性。这种源于真实世界的认知体验，远比抽象概念更深刻地影响了她日后 选择计算机视觉作为研究方向的决策。

母亲则是李飞飞精神世界的「守护者」。面对中学教师对其阅读《不能承受的生命之轻》 等「非主流书籍」的质疑，母亲断然反驳：「我的努力只是为了成为更好的自己」，并以 此教导女儿不必迎合外部标准。这种教育哲学解构了传统权威的绝对性——当老师公开 贬低女生数理能力时，母亲的态度成为李飞飞对抗偏见的心理支柱：「他们无法阻止我在 这里上场参赛，我暗下决心，一定要赢」。更关键的是，父母始终以行动传递价值观：在 移民美国后陷入经济困境时，他们拒绝向现实妥协，反而将生存压力转化为家庭凝聚力， 让李飞飞在干洗店账本间隙研读学术期刊成为可能。

回归到教育的本质 - 培育「反叛的底气」。20 后是 AI Native 小孩，需要去成功 AI Master 而不是 AI Slave，不要去被 AI 替代而要不 AI 赋能，很大的一个要点是要有 独立思考能力，有思辨、批判精神，从而去指挥 AI。李飞飞父母的教育智慧，在于将 探索精神与批判性思维内化为孩子的生存本能。他们既不刻意塑造「完美人设」，也不焦 虑于短期得失，而是通过持续支持孩子的兴趣选择（如允许剪短发、痴迷航空航天设 计），让独立人格在真实生活场景中自然生长。这种教育模式的当代启示在于：真正的素 质教育不是资源堆砌，而是父母能否在物质匮乏时仍坚持精神富养，在世俗标准前守护孩 子的独特性。正如李飞飞在 ImageNet 项目受质疑时所展现的韧性，其根源正是童年期形 成的「质疑—坚持—突破」的行为模式。

你找到你的北极星了么？

李飞飞在自传中反复提及指引她前行的「北极星」—— 一种超越短期利益与外界评价的内在驱动力。对她而言， 这颗星是对知识本质的追问与对人文价值的坚守的融合。 从成都街头的观鸟少年到斯坦福实验室的领航者，她始终以「探索未知」与「服务人类」 为双轴校准方向：在华尔街高薪诱惑前，她选择回归科学本心；在算法主导的 AI 浪潮中， 她坚持构建让机器理解现实世界的视觉常识库；当技术突破引发伦理争议时， 她强调「AI 的胜利必须是人文的胜利」。这种贯穿始终的清醒， 源于父母传递的价值观——母亲病榻上的灵 魂拷问「人工智能还能如何帮助他人」，最终化作她推动医疗环境智能研究的持久动力。

真正的北极星，从来不是某个具体目标，而是驱动人穿越迷雾的底层信念： 对李飞飞而言，那是永远追问「为什么」的好奇心，与永远不忘「为了谁」的责任感。

生活 - Show me your photos

地球不停息绕太阳一周，时光交替中，我们与生活擦肩，带着过去的记忆，迎接未来的未知。

去年，我给自己设立了一个关于生活的目标：家庭和陪伴。其中，一项是「高质量陪伴」，而另一项则是“学会摄影糖水片”。每次出行时，我希望通过照片记录下光与影的交织，捕捉那一瞬间的温度。今年，这个部分的主题便是 - Show me your photos。

2024 新年伊始，海边的灯塔。

春寒料峭，拎着一个喜气的龙灯出来转转。

从烟火气潮汕到宗教多元的泉州。

京都清水寺，小朋友许了一个有禅意的愿：我希望佛天天开心。

丽水，浙南梯田

壶口瀑布，红旗招展，黄河怒吼。

迪士尼，年末的花火。

工作 - 基建狂魔

草原上的加特林烟花。

去年，我从一名探索者转变为有组织推进系统演进的人。在年初的时候，我甚至隐隐觉得大厦的框架已经显现，接下来就是持续建设，让飞轮稳步前进，甚至开始规划探索 AIGC 上的一些新方向，想要在这个领域找到新的突破。

然而，现实很快给了我一个巨大的逼兜。随着 AIGC 急速发展，见证历史的同时，也面临着算力需求的剧烈增长。一波又一波的压力压下来，新需求和旧债交织在一起，给基础设施交付带来了巨大的挑战。这期间几位在这个领域的核心同僚几个月内相继离开。人走了，工作还得继续做。从 6 月份开始，我便与一群兄弟们直接走上了战场。

我甚至感到自己一度快要被压垮了，写了一系列关于「死亡行军」的故事。

痛苦总是让人深思，尤其在那些看似无法承受的时刻，它反而带来了更多的洞察。一切接近触底时反而能迎来反弹的力量。有一个瞬间我终于明白，问题是阶段性的，真正在持久修炼的是正面看待问题和以清明的心态面对困难的内心力量。

无需惧怕外界的评价，也不必厌倦合作中的复杂性，现状和问题本就存在于那里，解决的方案并非高深莫测，关键在于直面问题本身。保持平和的心态和现实的预期，便能在混乱中看到问题的根源，在困难中捕捉到机遇，在当下洞察到未来的可能。真正的力量，是从每一次挑战中提取智慧，从每一个困境中找到前行的勇气。

摄于苏州美人腿附近

业余 - 聊胜于无

今年被工作挤占了几乎所有的时间，也导致业务已经没有精力产出内容。只有两个很小的产品。

dbml-editor ，一个免费的 DBML 在线编辑器。

• 支持 dbml 语法检查和反馈，DBML 是一门描述关系型数据库的 Schema，面向终态，比 SQL 要更易读
• 支持 Web 响应式
• 所见即所得
• 支持导入导出 SQL

random-apple-music 是一个播放列表，随机挑选 Top250 的豆瓣音乐专辑，并且可以一键跳转到 Apple Music 播放。

• 🎵 音乐迷们，快来发现新宝藏！
• 🍏 随机播放豆瓣音乐Top250，一键跳转Apple Music！
• 🎧 享受音乐的无限可能！

今年在 X（Twitter）上面的最受欢迎的内容是：

• 169k 学英语技巧
• 83k 分布式系统工程实践
• 75k 代理协议转换 gost
• 56k 死亡行军
• 52k endoflife 信息
• 46k 红警 on Steam
• 44k Git rebase 合并技巧
• 43k dbdiagram.io
• 40k cors.sh
• 38k 每年的 24 个问题
• 37k 如何扩大工作影响力
• 21k 如何写好文档

读书 - 意外之喜

今年，买了 Boox 文石之后，读书量一下子就上来了。总共读了 34 本书，大多数是非虚构类书籍，其中有 10 本我给了 5 星评价。Kindle 离开中国，只能拥抱微信读书。虽然无法拥有实体书，但读书成本大大降低，每月上传两本书，已经足够了。更有意思的是。我也逐渐改变了对听书的看法，曾经对它嗤之以鼻，但现在，我发现做家务或者在路上听书，成了提高大脑利用率的好方式。

大明王朝1566 (豆瓣)

太牛了，原来演员的词几乎不用改就能直接用。

太白金星有点烦 (豆瓣)

妙趣横生。

华为内训 (豆瓣)

华为的经营哲学与阿里巴巴的"六脉神剑"在客户至上和目标导向上有共通之处。尽管理念相似，但华为的手册缺乏案例支撑，而企业文化往往是在解决实际冲突中塑造的。书中强调的几个关键点，如明确方向、专业精神、执行力和自我批评，对企业成长至关重要。华为从网络设备市场起步，现已成为多元化的科技巨头，其硬件基因可能助其稳健发展。相比之下，阿里巴巴等互联网公司近年来在资本市场的表现略显逊色。

起源 (豆瓣)

很推荐，讲述了宇宙的起源，生命的诞生和演进。让我想起了小时候看的一部纪录片，宇宙与人。如果有时间的话，我想仔细研究里面的术语，囊括了宏观物理、微观物理、化学、生物。

这就是ChatGPT (豆瓣)

武林泰斗亲自下场，给新人们介绍秘笈心法。之前读论文比较枯燥，一些知识和细节理解不连贯，借本文可以梳理脉络。 关于 Transformer 注意力机制介绍的比较少，好在热心的读者评论里面提供了更多信息。

深度学习入门 (豆瓣)

这是一本相当不错的深度学习入门书。不同于 How to use，本书着重 How to build，书中通过 Python 实现了一套简单的框架，并将这个框架应用在手写识别上。文章深入浅出非常详细的介绍每一层网络解决什么问题，相关的数学公式和原理是什么。 虽然已经出版了接近五年，但是书中内容并没有过期，甚至在最后面的展望描述的场景，包括物体识别，RNN（GPT 基础）在当下异常火热。

纳瓦尔宝典 (豆瓣)

本书像是提供精神 massage，片刻愉悦之后还是得落到知行二字。 有时候精神困顿，也需要按摩解乏。比如读到情绪管理这章，就回忆起上周工作冲突失控愤怒上头怼人时刻。我并非不知道要点，也许早一点读到纳瓦尔这一章我就可以唤醒理性，好书还是需要常读常新。 财富和判断力这两章给我的输入和触动最大：做高杠杆效应事情，积累财富；使用稳定可靠心智模型，学习数学，特别是概率和统计。

李光耀观天下 (豆瓣)

作为政治家，有意愿有行动力，思想有深度视野开阔不受框架束缚已经是一流。 难能可贵是李光耀还如此坦诚。我想应该是和新加坡人口规模和民众素质有关系。 这本书是书友评论密度很高的一本书，靠书友补充了很多视角（以及后来发生的事情）。

筚路维艰 (豆瓣)

这本书是一本神作，作者用相当大的尺度在讨论从建国到现在政治路线和经济路线的纷争。作为党史研究员，作者不避讳描述毛泽东，让我看到一位急迫地想一把到位共产主义，并且留下一个无阶级矛盾的国家，为此不断发起运动、斗争。好在邓公拨乱反正改革开放。 感慨，看过去一代人的牺牲，一个数字代表一个家庭的破碎。希望未来少一些宏大叙事，多一些关注日常民生。

在峡江的转弯处 (豆瓣)

从无人知晓过来。 文字之间跳跃着一股真诚质朴，数次为其感动眼眶湿润。被陈行甲正直、热情、生命活力感动。 有人质疑这是表演，我倒更愿意相信其诚朴，相信愿意相信的，坚持自己坚持的。

不败者 (豆瓣)

不败者，一本让我挺惊喜的国内科幻小说集。 墨熊的风格有一种深入宇宙边界的探索力，截取了一小段太空歌剧的碎片展现出来，将遥远星际故事拉到读者身边。 《信鸽》有种软硬结合的科幻感，被光速约束的理性和感性的理念交付。 《白鬼篇》有点爽文既视感。 《不可战胜者》让我想起了神秘博士里的哭泣天使，以一种跨越时间线方式进行绞杀。绞杀的方式和破解的方式都精巧且出乎意料。

Last

期望新的一年可以热烈又恬静，深刻又朴素。

最近我完成了从 Toodledo 到 Obsidian Tasks（Obsidian 插件）的切换。 这两款软件都是极其强大的时间管理工具。虽然 Toodledo 几乎是我最喜欢的 GTD 软件， 但服务愈发不稳定让我烦恼，正好发现 Obsidian Tasks 在查询和知识库结合方面的能力发挥出了 1+1 > 2 的效果。 经过试用我决定迁移到 Obsidian Tasks。

放弃一个合作了十几年的老朋友 Toodledo 让我有些伤感，但是这个过程也促使我总结了一下我在时间管理这个命题上的尝试，并分享了一些我的经验。

Image frrom Pixelbay

什么是 GTD

在这个快节奏的现代生活中，我们都会遇到大量的任务和信息，而如何有效地管理时间和任务成为了许多人的挑战。在读书时期，我也曾经陷入任务管理的困境。从 2009 年开始，我尝试过使用日历、笔记等工具来组织我的任务和信息，但效果并不理想。直到后来我接触到了 DoIt.im，进而发现了 David Allen 的书《Getting Things Done》，这本书带给了我一种全新的任务管理思路——GTD。往后数十年，我一直使用这个模式来管理自己的时间。

GTD 是由 David Allen 所创立的一种个人时间管理方法 ，旨在帮助人们更有效地管理自己的时间和任务，从而提高工作效率和生产力。这种方法的基本思想是将所有任务分解为具体的行动步骤，并将它们组织在一个可靠的系统中，以便于跟进和管理通过这种方法，人们可以更轻松地掌控自己的工作和生活，减少压力和焦虑，从而更加专注和高效地完成任务。

那么如何实现 GTD 呢？以下是基本的步骤：

1. 收集：收集所有任务、想法、计划、待办事项，可以用笔记本、手机、电脑等多种工具。
2. 组织：审视待办任务，分类所有任务和行动步骤，并回顾过往未完成的项目。
   • 分类：审视收集到的任务，将所有任务和行动步骤分类，常见分类包括项目、上下文、时间等，以更清晰地了解任务的优先级和关联性。如果可以快速执行（<2m）就立刻执行。
   • 回顾：定期回顾任务和行动步骤，确保它们的进度和状态得到及时跟进，更好地掌控任务和生活，从而更加高效地完成任务。
3. 执行：专注于当前任务，避免分散注意力，借助时间管理和注意力控制的技巧提高效率。

注，我整理的结构和外部工具略有差异。我将分类、回顾都合并到组织步骤因为我发现组织本质是做计划，做计划纪要看收集的待办事项，也要回顾进行中项目和已完成项目，何不都在组织环节一起做好？

我使用过的在线 GTD 服务

我曾使用过多个在线任务管理软件，包括 Doit.im、Remember The Milk、OmniFocus 和 Toodledo 等，下面分享一下我的使用历程和对比这些软件的差异。

Doit.im

我接触 GTD 就是从 Doit.im 开始。这是一款国产软件，也是我非常喜欢的一款应用程序。Doit.im 支持 GTD 的基本功能，提供了清晰的任务列表、分类、优先级等功能，还支持多种回顾模式和多平台同步。然而，我后来放弃了它，因为我发现了更为强大的 Toodledo。

Image frrom doit.im

Remember The Milk

我寻找下一款管理工具时，找到了 Remember The Milk（RTM）这个应用。RTM 提供了基本的任务管理功能，如添加任务、设置提醒、归档任务等等，并支持多平台同步，可以在电脑、手机等多个设备上使用。

然而，有些人可能不太喜欢 RTM 的用户界面设计，因为它看起来可能有些过时，不够现代化。此外，一些高级功能需要付费使用。当时我还是一个穷学生，没有为软件付费的能力，所以很快放弃了使用 RTM。

Toodledo

我从善用佳软了解到 Toodledo 这款任务管理工具（善用佳软是一个著名的软件使用分享网站，我在学生时代从这里获取了相当多的工具和思路）。

Image frrom toodledo.com

我很快在 葡挞生活 找到了一份非常完整的教程介绍 Toodledo 高级使用手法，尤其从其中获得了使用 Search 模块的方法。可惜现在网站已经无法打开了。不过，我们可以从一些其他渠道的截图中，略窥当时 Toodledo 的风采：

Image frrom twitter.com/productivelife

Toodledo 很快成为了我最喜欢的任务管理工具。它提供了非常全面的任务管理功能，支持任务分类、排序、筛选等，同时还支持多种回顾模式和自定义字段。此外，Toodledo 还支持多平台同步，并且具有强大的 API，可以方便地与其他应用程序集成。

OmniFocus

由于 Toodledo 产品功能上一直不思进取，访问比较慢。我还曾经探索式短暂使用了 OmniFocus，这是一款专业的 Mac 平台任务管理工具，它提供了任务分解、项目管理、上下文等功能，并可通过 AppleScript 等方式进行扩展。OmniFocus 支持多种同步服务，包括 Omni Sync Server、WebDAV、FTP 等，用户可以根据自己的需求选择不同的服务。所有任务数据都是存储在本地的，因此用户可以在没有网络连接的情况下继续使用软件。

付费使用一段时间之后，我发现 OmniFocus 的搜索功能和 Toodledo 的 Search 功能实在无法相提并论它不能满足我的需求。

Image frrom www.omnigroup.com/omnifocus

其他一些

我还曾经尝试过一些任务管理工具，包括 Trello、Asana、Basement、Tower、Teambition 等等，

但是由于它们的功能设计往往是为团队协作设计的，而我主要是个人使用，因此使用起来不够便捷。另外，这些软件的自定义搜索功能（当时）往往也比较弱，无法满足我的需求。最终我都返回到了 Toodledo 怀抱，直到现在。

我如何组织一天的任务？

我认为在 GTD 的体系中，收集和处理阶段相对机械和简单，真正考验人的是组织阶段：

• 分类：如何快速检阅所有任务并对它们进行分类和标记；
• 下一步：如何确定下一个任务的优先级。

下面我将分享一些我个人的理念和操作方法。

分类即快速检阅

为了更好地组织任务，我们需要注意任务的重要属性，包括 Context（环境）、Project（项目）、Status（状态）和 Due（截止时间）Context 决定了当前环境下要做什么，是一个简单的过滤器。我将 Context 分为 Computer / Work / Mobile。Project 则将任务归属到不同的项目中，一个项目的周期比较长，并且其中的任务具有强相关性。Status 描述这个任务是立即可处理（Next）还是需要等待（Waiting），有些任务是周期性的则为 Active。Due 则是描述时间属性，一般有到点干（On），在这个时间之前（Due）以及尽量（Optional）。

除此之外，其他属性，如优先级（Priority）、类型（Folder）也需要考虑，但不是最重要的。

为了更好地管理任务，我每天早上都会打开四个视图：single、subtask、project-xxx 和 inbox

• single 是单独任务（包括重复任务），这里面的任务都是独立的，可以根据优先级进行排序。
• subtask 是父子任务，有些任务并不是当天可以完成，必须将任务拆分为小任务，否则会打击完成任务的信心。
• project-xxx 针对特定项目做的分类，我会按照固定模板对每个项目进行分类成十几个任务。
• inbox 其实就是收集的产物，需要进行简单分类处理。

下一个任务是什么

以下是筛选清单，用于确定需要立即进行的任务：

• Top：任务优先级高
• Due 3 天内且非重复类型：需要进行检查和准备工作
• Due 明天：需要立即进行
• High + Next：任务优先级较高，且已经具备行动条件
• 计时器不为空：说明已经开始执行，但可能会被其他事情打断
• Waiting：表示需要和别人合作，需要检查进度

清单中的任务按照优先级、截止日期和执行状态的综合考虑排序。每次进入工作状态之后，只需要从这个清单中筛选出靠前的几个任务进行执行。

曾经的王者 - Toodledo

我使用它已经超过了 12 年，付费了 8 年，而且它的产品理念深刻影响了我时间管理的策略。 我介绍一些 Toodledo 中做得相当很不错的功能以及细节：

细节功能

循环任务功能

Toodledo 支持循环任务功能，用户可以将一个任务设置为循环任务，并指定它的重复周期，比如每天、每周、每月等。当任务完成后，它会自动重复出现在任务列表中，以便用户再次处理。这个功能可以帮助用户更好地管理一些常规性的任务：日常会议、每日邮件处理、每日 Review 等等。

丰富时间功能类型

Toodledo 对日期的支持非常丰富，用户可以根据任务的具体情况选择不同的 Due 类型，比如 Due（截止时间）、Timer（计时器）、Length（时常评估） 等等。这样一来，用户可以更加精细地管理任务的时间，有效地提高工作效率。另外，基于 Timer 计时器，我可以方便地统计一天的时间耗用情况更好地把控时间成本。我还开发了一个 Python 脚本用来分析每周的时间耗用。

Search 功能

Toodledo 的 Search 功能非常强大，支持丰富的逻辑查询（提供了条件组合的与或查询）用户可以根据任务名称、标签、日期、优先级等多个条件进行查询。这个功能可以帮助用户组织任务，提高任务管理的效率，我一度无法离开 Toodledo 也是因为，任务组织这个步骤我高度依赖这项功能。

我开发的工具和插件

整体而言，我还是愿意给大家推荐 Toodledo。我自己也在 Toodledo 之上基于它提供的 API 开发了 多款工具和插件。我给大家介绍一下：

Buff 1 优雅订阅 Toodledo 日历

Toodledo 提供了日历订阅能力，将待办事项显示在各类日历软件中。但原始的信息非常混乱，没有考虑任务的 Time，并且时间也是计算错误。为此我开发了一个 Web 服务，叫做 toodledo_calendar_filter。

它可以将 Toodledo 的任务更友好地显示在日历系统上。具体来说，它可以过滤 Toodledo 的 iCal，只显示那些具有到期日期和时长的任务。如果你也有相关需求可以直接使用我提供的在线服务（https://toodledo-calendar-filter.alswl.com）。

Before：

After：

Buff 2 让 Toodledo 具备 Gmail 快捷键

当你使用 Toodledo 进行任务管理时，你是否感到操作繁琐，鼠标使用效率不高，非常怀念 Gmail 风格的快捷键？如果是这样，那么我的项目 alswl/my-toodledo 可以帮助你解决这个问题。

它是一个针对 Toodledo 的油猴脚本（User Script），提供了一系列 Gmail 风格的快捷键，让你可以像使用 Gmail 一样快速操作 Toodledo，包括移动任务（j / k）、任务操作（x 标记完成，enter 启动任务）、切换任务视图（g s 跳转搜索）等等。它在 Chrome / Safari / Firefox 上运行稳定，如果你想要提高 Toodledo 的使用效率，不妨试一试吧。

Buff 3 命令行工具 go-toodledo

为了快速收集任务，我曾经使用一个 Github 上面 CLI 小工具（wsargent/toodledo）。但它是基于 v1 版本的 API，官方已经在七八年前就说 v1 版本 API 要下线。于是我自己做了一个叫做 go-toodledo 小项目。

一开始 go-toodledo 只是提供最简单的 CLI 功能。后来我逐步补充了完整 SDK、CLI 全功能，甚至还提供了一个互动式的 TUI 小应用让用户可以方便在 Terminal 地使用 Toodledo。

Toodledo 官方并没有提供 OpenAPI 接口，我以逆向的方式生成了一份 go-toodledo/swagger.yaml，如果还有其他人有对 Toodledo API 开发需求，可以基于这份 API 直接使用。

离开

最近，我对一直使用的任务管理服务 Toodeldo 的稳定性越来越失望。 他们换了新的服务提供商， 服务出现不稳定的频率更高，而新团队的产品能力也让我产生了一些质疑。 因此，我决定开始寻找下一个更好的任务管理服务。 因为 Kindle 在中国停止服务的事件让我对云服务的可靠性产生了疑虑。 因此，我开始寻找一些本地化的任务管理方案这些方案可以通过网盘（例如 iCloud）进行服务， 这样可以更好地保护我的数据和隐私。

最终获胜者 - Obsidian Tasks

Obsidian是一款基于本地文件的个人知识管理（KMS）和笔记应用程序，可帮助用户将其笔记和想法组织、链接和分析。它是一款纯粹的本地软件，我们可以使用网盘 / NAS 等方式进行多端同步。

Obsidian Tasks 则是一款强大的 Obsidian 插件它可以让你在 Obsidian 中轻松地管理任务和待办事项。这个插件可以通过简单的语法将任务添加到你的笔记中，并根据任务的完成情况自动标记任务的状态。你可以使用 Obsidian Tasks 来跟踪个人任务、工作任务、学习任务等等。此外，它还具有一些其他功能，例如自定义任务样式、创建过滤器来查找任务，以及可以根据任务状态自动移动任务。Obsidian + Obsidian Tasks 是一个完美组合，可以帮助你更好地管理你的待办事项，提高你的生产力。

Image frrom https://github.com/obsidian-tasks-group/obsidian-tasks

我的个人 KMS 已经完整地从 Notion 迁移到了 Obisidian，现在使用 Obisidan Tasks 迁移成本很低。经过一段时间对 Obsidian Tasks 的学习，我将原来的使用模式较为顺利搬到了 Obsidian Tasks。我接着之前两个场景整理和下一个任务来介绍如何高效使用 Obsidian Tasks。

我通过以下几种形式组织待办任务：

• 使用 [ ] 标记的普通文档任务，一般是零散小任务。
• 使用以 .todo.md 结尾的专用文档，以对项目进行统筹。
• 使用带有 #todo 标签的文档，一般是一个大事项，我会在顶部拆分出一个 TODO 队列，拆分出若干个 Tasks，拆完之后我会去掉 #todo 标签。

基于这个组织结构，我轻松搞定整理和下一个任务这两个：

分类即快速检阅

使用几个视图将 Obsidian Tasks 中记录的任务进行多个视图呈现分别是：

• 今日视角
  • non repeated：一次性任务，往往更重要
  • repeat：重复性任务，比如周会、约会，往往偏事务性
• 时间视角
  • 即将到期时间（7 天内）
• Single Tasks：没有在 .todo 结尾的文件内，即分散在各个日常事务的碎任务
• Project：按项目进行排列的任务
• 有 #todo 标签的任务，往往是一个文档需要整体来处理

这几个视图可以让你更好地将任务进行分类，并快速检阅各个任务。通过这些视图，你可以更好地管理你的待办事项，提高你的生产力。

这是我的 projects/View.todo.md`：

## Today

**WIP**

```tasks
status.type is IN_PROGRESS
```

**High（规划、设计都是高优先级）**

```tasks
not done
priority is above medium
```

**None repetead due today**

```tasks
((not done) AND (due before in 1 day)) OR (done on today)
is not recurring
sort by priority
```

**Repeated due today**

```tasks
((not done) AND (due before in 1 day)) OR (done on today)
is recurring
sort by priority
```

**Over due before today**

```tasks
not done
due before today
sort by priority
```

**Today complete**

```tasks
done
done on today
```

## Future (no repeat)

**in 1 day**

```tasks
not done
due before in 1 day
is not recurring
sort by priority
sort by due
```

**in 3 day**

```tasks
not done
due after in 1 day
due before in 3 day
is not recurring
sort by priority
sort by due
```

**in 7 day**

```tasks
not done
due after in 3 day
due before in 7 day
is not recurring
sort by priority
sort by due
```

## Singles Tasks

**in 7d（non project x no repeate）**

```tasks
not done
status.type is not CANCELLED
NOT (path includes .index)
NOT (path includes .todo)
NOT (path includes .notodo)
due after in 7 days
sort by priority, due
```

**none project x no due x no repeat**

```tasks
not done
status.type is not CANCELLED
NOT (path includes .index)
NOT (path includes .todo)
NOT (path includes .notodo)
no due date
sort by priority, due
```

## Projects

TODO

## Help

> [Queries Syntax](https://obsidian-tasks-group.github.io/obsidian-tasks/queries/)

下一个任务是什么

在 Obsidian 的 Daily Note 插件中，设置模板为 _templates/daily，这样每天就获得一个随时可以使用的当天待办事项。

这是我的 Dailly 设置，通过四个区块区分：今天到期单任务 / 今天到期重复任务（事务性，不重要） / 今日已完成 / 今日新任务（一般是 Single）。

这是我的 _template/daily.md 文件：

## TODO

**WIP**

```tasks
status.type is IN_PROGRESS
```

**New tasks**

**Tasks view - today**

```tasks
((not done) AND (due before {{date}})) OR ((not done) AND (due on {{date}})) OR (done on {{date}})
is not recurring
sort by priority, due
```

**Tasks view - today(repeated)**

```tasks
((not done) AND (due before {{date}})) OR ((not done) AND (due on {{date}})) OR (done on {{date}})
is recurring
sort by priority, due
```

**Over due date**

```tasks
not done
due before {{date}}
sort by priority, due
```

**Projects**

YOURS

**Tasks view - today done**

```tasks
done
done on {{date}}
```

Obsidian Tasks 有什么缺点？

首先，需要注意的是，Obsidian Tasks 是 Obsidian 的插件，如果之前没有使用 Obsidian，可能需要花费一些时间上手。不过，如果您已经使用了 Obsidian，那么 Obsidian Tasks 的双链功能将为您在 GTD 场景中提供极佳的支持，这既是其优点也是劣势。

其次，Obsidian Tasks 目前还没有提供计时器功能。不过，对于我个人而言，这一点已经不再重要了。随着年龄的增长以及十多年的 GTD 训练，我已经不需要通过工具来保持专注力。在工作状态下，我会比较专注，并且不会经常性分心。

最后，需要注意的是 Obsidian 自身的问题。Obsidian 是一个基于本地文件的工具，这意味着它没有在线工具（尽管有其他基于云存储的解决方案）。如果您希望找到一个电脑和手机都可以访问的在线服务，那么 Obsidian Tasks 可能不太适合您。对我来说，我使用 Obsidian 的方案是因为我拥有 Apple 全家桶，并购买了 iCloud 存储服务，因此我的数据都存储在 iCloud Drive 上。我使用 Obsidian 的 macOS 应用程序和 iOS 版本应用程序，这使我可以轻松地在 Macbook 和 iPhone 之间使用同一个 Vault（即 Obsidian 知识库）。启动应用程序之前，我会确认 Vault 同步完成后再进入应用程序。

最后

时间管理是现代工作者不可避免的话题，也是我们时常为之烦恼的问题。GTD 的方法论恰恰提供了一种轻松而高效的管理方式，让我们能够迅速结束拖延、分心的状态，全身心地投入工作

工具很重要，但并不能解决所有问题。要做好时间管理，最重要的是要清楚自己的目标是什么当你心里有一个重要的使命时，它会不断地在你脑海中浮现，这时候甚至不需要 GTD 工具的管理。

希望本文介绍的 GTD 方法可以在你的工作和生活中带来帮助，让你更高效地完成自己的任务，同时也不要忘记享受生活的美好。记住，时间是有限的，珍惜每分每秒，抓住每一个机会，让自己的人生更加精彩！

乐坛少有新歌，我经常听一些老歌，有时候顺着豆瓣音乐 Top 250 一点点听下去，感觉还是挺不错。 这中间一直有个麻烦地方：每次都要从豆瓣复制标题去 Apple Music 搜索。有没有简单便捷的方式直接一键抵达呢？ 我没有找到答案，于是我自己整理了这批 Apple Music 链接，点击就可以直接跳转到 Apple Music 直接播放了

如上图所示，在本文点击「▶️ Apple Music」按钮，会打开 Apple Music 网站，点左侧的「Open in Music」即可在 Apple Music 打开。

PS：iPhone 上点击链接（Notes / Safari 等）会直接在 Apple Music 打开。

Update 2024-07：我提供了一个在线小网页可以随机选择一个专辑给你，并且一键播放 Apple Music。 Random Apple Music 源码 alswl/random-apple-music。

We Sing. We Dance. We Steal Things.

Jason Mraz / 2008-05-13 / Import / Audio CD / 民谣

9.1 ( 115738人评价 )

▶️ Apple Music

Viva La Vida | Death And All His Friends

Coldplay / 2008-06-17 / 专辑 / CD / 摇滚

9.0 ( 117391人评价 )

▶️ Apple Music

华丽的冒险 | 華麗的冒險

陈绮贞 / 2005-09-23 / 专辑 / CD / 流行

9.0 ( 88220人评价 )

▶️ Apple Music

范特西 | Fantasy

周杰伦 / 2001-09-14 / 专辑 / CD / 流行

9.5 ( 172202人评价 )

▶️ Apple Music

後。青春期的詩 | 后青春期的诗

五月天 / 2008-10-23 / 专辑 / CD / 摇滚

9.0 ( 94647人评价 )

▶️ Apple Music

是时候 | It's Time

孙燕姿 / 2011-03-08 / 专辑 / CD / 流行

8.7 ( 81241人评价 )

▶️ Apple Music

Lenka

Lenka / 2008-09-23 / 专辑 / Audio CD / 流行

8.6 ( 83181人评价 )

▶️ Apple Music

Start from Here | 从这里开始

王若琳 / 2008-01-11 / 专辑 / CD / 爵士

8.8 ( 75301人评价 )

▶️ Apple Music

旅行的意义

陈绮贞 / 2004-02-02 / 单曲 / CD / 流行

9.1 ( 98494人评价 )

▶️ Apple Music

太阳 | Immortal

陈绮贞 / 2009-01-22 / 专辑 / CD / 流行

8.7 ( 74979人评价 )

▶️ Apple Music

Once (Soundtrack) | Once / 电影《曾经》原声大碟

Glen Hansard,Marketa Irglova / 2007-05-22 / Soundtrack / CD / 原声

9.2 ( 72580人评价 )

▶️ Apple Music

Not Going Anywhere | 守候

Keren Ann / 2004-08-24 / Import / Audio CD / 民谣

8.9 ( 62347人评价 )

▶️ Apple Music

American Idiot

Green Day / 2004-09-21 / Explicit Lyrics / Audio CD / 摇滚

9.0 ( 72130人评价 )

▶️ Apple Music

思念是一种病 | OK

张震岳 Csun Yuk / 2007-07-06 / 专辑 / CD / 流行

8.8 ( 81378人评价 )

▶️ Apple Music

無與倫比的美麗 | 无与伦比的美丽

苏打绿 / 2007-11-02 / 专辑 / CD / 流行

8.8 ( 89048人评价 )

▶️ Apple Music

亲爱的...我还不知道 | 親愛的...我還不知道

张悬 / 2007-07-20 / 专辑 / CD / 流行

8.7 ( 64429人评价 )

▶️ Apple Music

城市 | The City

张悬 / 2009-05-22 / 专辑 / CD / 流行

8.6 ( 62928人评价 )

▶️ Apple Music

O

Damien Rice / 2003 / 专辑 / CD / 流行

9.1 ( 52588人评价 )

▶️ Apple Music

Wake Me Up When September Ends | 九月结束的时候叫醒我

Green Day / 2005-06-13 / 单曲 / CD / 摇滚

9.4 ( 54233人评价 )

nil

叶惠美 | 葉惠美

周杰伦 / 2003-07-31 / 专辑 / CD / 流行

9.2 ( 103849人评价 )

▶️ Apple Music

七里香 | Common Jasmin Orange

周杰伦 / 2004 / 专辑 / CD / 流行

9.1 ( 159642人评价 )

▶️ Apple Music

21

Adele / 2011-01-24 / 专辑 / CD / 流行

9.3 ( 72900人评价 )

▶️ Apple Music

My Life Will...

张悬 / 2006-06-09 / 专辑 / CD / 流行

8.8 ( 56634人评价 )

▶️ Apple Music

寓言

王菲 / 2000 / 专辑 / CD / 流行

9.4 ( 66995人评价 )

▶️ Apple Music

你在煩惱什麼 | 你在烦恼什么

苏打绿 / 2011-11-11 / 专辑 / CD / 流行

9.0 ( 57675人评价 )

▶️ Apple Music

感官/世界 | Senses Around

林宥嘉 / 2009-10-30 / 专辑 / CD / 流行

8.6 ( 59038人评价 )

▶️ Apple Music

Nevermind | 别介意

Nirvana / 1991 / 专辑 / CD / 摇滚

9.3 ( 62973人评价 )

▶️ Apple Music

八度空间 | The Eight Dimensions

周杰伦 / 2002-07-19 / 专辑 / CD / 流行

9.2 ( 87077人评价 )

▶️ Apple Music

Jay

周杰伦 / 2000-11-13 / 专辑 / Audio CD / 流行

9.3 ( 90828人评价 )

▶️ Apple Music

Parachutes | 降落伞

Coldplay / 2000-07-10 / 专辑 / CD / 摇滚

9.2 ( 54165人评价 )

▶️ Apple Music

我要的幸福 | My Desired Happiness

孙燕姿 / 2000-12-7 / 专辑 / CD / 流行

9.0 ( 60779人评价 )

▶️ Apple Music

还是会寂寞 | 还是会寂寞

陈绮贞 / 2000 / 专辑 / CD / 流行

9.1 ( 51164人评价 )

▶️ Apple Music

Let Go | 展翅高飞

Avril Lavigne / 2002 / Enhanced / Audio CD / 摇滚

8.9 ( 55425人评价 )

▶️ Apple Music

十一月的萧邦 | November's Chopin

周杰伦 / 2005-11-01 / 专辑 / CD / 流行

8.9 ( 94955人评价 )

▶️ Apple Music

橙月 | Orange Moon

方大同 / 2008-12-19 / 专辑 / CD / 放克/灵歌/R&B

8.6 ( 49661人评价 )

▶️ Apple Music

小宇宙 | Little Universe

苏打绿 / 2006-10-20 / 专辑 / CD / 流行

8.9 ( 51741人评价 )

▶️ Apple Music

若你碰到他 | 若你碰到他

蔡健雅 / 2009-08-19 / 专辑 / CD / 流行

8.1 ( 51151人评价 )

▶️ Apple Music

Lady & Bird

Lady & Bird / 2003 / Import / Audio CD / 民谣

8.8 ( 43532人评价 )

▶️ Apple Music

万能青年旅店

万能青年旅店 / 2010-11-12 / 专辑 / CD / 摇滚

9.5 ( 84135人评价 )

▶️ Apple Music

Meteora | 流星圣殿

Linkin Park / 2003-03-25 / Enhanced / Audio CD / 摇滚

9.1 ( 45142人评价 )

▶️ Apple Music

Back To Bedlam | 不安於室

James Blunt / 2004 / Explicit Lyrics / Audio CD / 流行

9.0 ( 43229人评价 )

▶️ Apple Music

苏打绿同名专辑

苏打绿,蘇打綠 / 2005年9月 / 国语 / CD / 流行

8.9 ( 53849人评价 )

▶️ Apple Music

静茹&情歌 别再为他流泪 | 别再为他流泪

梁静茹 / 2009-01-16 / 专辑 / Audio CD / 流行

8.5 ( 46781人评价 )

▶️ Apple Music

美妙生活 | Perfect Life

林宥嘉 / 2011-05-06 / 专辑 / CD / 流行

8.7 ( 48384人评价 )

▶️ Apple Music

Le Fabuleux destin d'Amélie Poulain | 天使爱美丽

Yann Tiersen / 2001-04-23 / Soundtrack / Audio CD / 原声

9.4 ( 44514人评价 )

▶️ Apple Music

Joanna & 王若琳

王若琳 / 2009-01-16 / 专辑 / CD / 爵士

8.3 ( 43076人评价 )

▶️ Apple Music

A Plea En Vendredi

Tamas Wells / 2006 / Import / Audio CD / 民谣

9.0 ( 39351人评价 )

nil

To Hebe | 給 自己

田馥甄 Hebe / 2010-09-03 / 专辑 / CD / 流行

8.2 ( 45022人评价 )

▶️ Apple Music

逆光 | Against the Light

孙燕姿 / 2007-03-22 / Import / CD / 流行

8.6 ( 69921人评价 )

▶️ Apple Music

只爱陌生人

王菲 / 1999-09-10 / Import / CD / 流行

9.4 ( 56383人评价 )

▶️ Apple Music

Music For Tourists

Chris Garneau / 2007-01-23 / 引进版 / Audio CD / 民谣

8.8 ( 39023人评价 )

nil

The Moment | 关键时刻

孙燕姿 / 2003-08-22 / 专辑 / CD / 流行

9.1 ( 42823人评价 )

▶️ Apple Music

七

陈奕迅 / 2003-11-20 / 选集 / CD / 流行

9.4 ( 42728人评价 )

nil

春·日光日光

苏打绿 / 2009-05-08 / 专辑 / CD / 民谣

8.3 ( 45534人评价 )

▶️ Apple Music

100种生活

盧廣仲 / 2008-5-27 / 专辑 / CD / 民谣

8.4 ( 42135人评价 )

▶️ Apple Music

崇拜 | J'adore

梁静茹 / 2007-11-09 / 专辑 / CD / 流行

8.5 ( 49186人评价 )

▶️ Apple Music

陈绮贞精选 | Cheer 精选

陈绮贞 / 2005 / 选集 / CD / 民谣

9.2 ( 36799人评价 )

▶️ Apple Music

菊次郎の夏 | Kikujiro (1999 Film)

Joe Hisaishi / 1999-05-19 / 专辑 / CD / 原声

9.5 ( 49564人评价 )

▶️ Apple Music

Fearless

Taylor Swift / 2008-11-11 / Enhanced / Audio CD / 流行

8.7 ( 53119人评价 )

▶️ Apple Music

Life In Cartoon Motion

Mika / 2007-02-05 / 专辑 / CD / 流行

8.8 ( 37038人评价 )

▶️ Apple Music

H³M | H3M

陈奕迅 / 2009-03-23 / 专辑 / CD / 流行

8.7 ( 44462人评价 )

▶️ Apple Music

神秘嘉宾 | 神秘嘉宾

林宥嘉 / 2008-06-03 / 专辑 / CD / 流行

8.5 ( 45772人评价 )

▶️ Apple Music

Les Choristes | 放牛班的春天

Bruno Coulais / 2004-05-03 / Soundtrack / Audio CD / 原声

9.5 ( 37888人评价 )

▶️ Apple Music

赤子 | Innocent

范晓萱&100% / 2009-08-10 / 专辑 / CD / 摇滚

8.2 ( 39589人评价 )

▶️ Apple Music

9

Damien Rice / 2006-11-06 / 专辑 / Audio CD / 民谣

9.0 ( 36862人评价 )

▶️ Apple Music

将爱

王菲 / 2003 / 专辑 / CD / 流行

8.9 ( 46704人评价 )

▶️ Apple Music

遇见我

曹方 / 2005年12月 / 专辑 / CD / 流行

8.4 ( 39449人评价 )

nil

梵高先生 | B&BⅡ

李志 / 2007-01-11 / CD / CD / 民谣

9.1 ( 51735人评价 )

nil

Timeless | 可啦思刻方大同 2009全新大碟 自選輯 / 可啦思刻

方大同 / 2009-08-11 / 自选集 / CD / 放克/灵歌/R&B

8.4 ( 38003人评价 )

▶️ Apple Music

依然范特西 | Still Fantasy

周杰伦 / 2006-09-05 / 专辑 / CD / 流行

8.6 ( 71242人评价 )

▶️ Apple Music

风筝 | Kite

孙燕姿 / 2001-07-09 / 专辑 / CD / 流行

8.9 ( 44131人评价 )

▶️ Apple Music

完美的一天 | A Perfect Day

孙燕姿 / 2005-10-07 / 专辑 / CD / 流行

8.3 ( 45359人评价 )

▶️ Apple Music

Say I Am You

The Weepies / 2006 / Import / Audio CD / 民谣

8.6 ( 39732人评价 )

▶️ Apple Music

黑色柳丁 | Black Tangerine

陶喆 / 2002-08-09 / 专辑 / CD / 流行

9.1 ( 51691人评价 )

▶️ Apple Music

Under My Skin

Avril Lavigne / 2004-05-12 / Import / Audio CD / 摇滚

8.6 ( 40059人评价 )

▶️ Apple Music

Stefanie

孙燕姿 / 2004-10-1 / 专辑 / CD / 流行

8.7 ( 39004人评价 )

▶️ Apple Music

The Fame

Lady Gaga / 2008-08-19 / Import / Audio CD / 流行

8.5 ( 42436人评价 )

▶️ Apple Music

Mr. A-Z | 英语老师

Jason Mraz / 2005-07-04 / Import / Audio CD / 流行

9.0 ( 34498人评价 )

▶️ Apple Music

为爱而生 | 為愛而生 / BORN TO LOVE

五月天 / 2006-12-28 / 引进版 / CD / 流行

8.6 ( 40435人评价 )

▶️ Apple Music

Daniel Powter | dp

Daniel Powter / 2006 / 专辑 / Audio CD / 流行

8.7 ( 35302人评价 )

▶️ Apple Music

I'm Yours

Jason Mraz / 2008-12-16 / Single / Audio CD / 民谣

9.4 ( 39203人评价 )

▶️ Apple Music

时光·漫步

许巍 Wei Xu / 2002-12-01 / 专辑 / CD / 民谣

9.1 ( 38564人评价 )

▶️ Apple Music

生如夏花 | Life Like Summer Flowers

朴树 / 2003-11-28 / 专辑 / CD / 流行

9.0 ( 59817人评价 )

▶️ Apple Music

我很忙 | JAY CHOU ON THE RUN

周杰伦 / 2007-11-01 / 专辑 / CD / 流行

8.2 ( 69903人评价 )

▶️ Apple Music

夏 / 狂热Fever

苏打绿 / 2009-09-11 / 专辑 / CD / 摇滚

8.7 ( 41388人评价 )

▶️ Apple Music

绝世名伶

范晓萱 / 2001-08-25 / 专辑 / CD / 爵士

8.8 ( 35543人评价 )

▶️ Apple Music

哼一首歌 等日落

曹方 / 2009-11-11 / 专辑 / CD / 流行

8.2 ( 33443人评价 )

▶️ Apple Music

未完成 | To Be Continued......

孙燕姿 / 2003-01-10 / 专辑 / CD / 流行

8.7 ( 37301人评价 )

▶️ Apple Music

OK Computer

Radiohead / 1997 / 专辑 / Audio CD / 摇滚

9.4 ( 43284人评价 )

▶️ Apple Music

Born to Die | 向死而生（大陆） / 生死相守 （台）

Lana Del Rey / 2012-01-31 / 专辑 / Audio CD / 流行

8.8 ( 48967人评价 )

▶️ Apple Music

The Wall | 迷墙

Pink Floyd / 1979 / 专辑 / Audio CD / 摇滚

9.4 ( 45083人评价 )

▶️ Apple Music

不要停止我的音乐 | The Music Won't Be Stopped

痛仰 / 2008-10 / 专辑 / CD / 摇滚

8.7 ( 46100人评价 )

▶️ Apple Music

Hybrid Theory | 混合理论

Linkin Park / 2000 / 专辑 / CD / 摇滚

9.0 ( 33231人评价 )

▶️ Apple Music

MTV Unplugged in New York

Nirvana / 1994-11-01 / Live / Audio CD / 摇滚

9.6 ( 34354人评价 )

▶️ Apple Music

After 17

陈绮贞 / 2004年12月 / EP / CD / 流行

9.2 ( 31467人评价 )

▶️ Apple Music

In Between Dreams

Jack Johnson / 2005-03-22 / 专辑 / Audio CD / 民谣

9.1 ( 29785人评价 )

▶️ Apple Music

神的孩子都在跳舞

五月天 Mayday / 2004-11-05 / 专辑 / CD+VCD / 流行

9.0 ( 35355人评价 )

▶️ Apple Music

离开地球表面Jump!

五月天 / 2007-07-20 / 专辑 / CD+DVD / 流行

8.8 ( 41018人评价 )

▶️ Apple Music

不想放手 | Don't Want to Let Go

陈奕迅 / 2008-06-30 / 专辑 / CD / 流行

8.4 ( 36475人评价 )

▶️ Apple Music

我的歌声里

曲婉婷 / 2010-02-24 / 单曲 / 数字(Digital) / 流行

8.7 ( 46762人评价 )

▶️ Apple Music

The Legend of 1900 | 海上钢琴师

Ennio Morricone / 1999-10-12 / Soundtrack / Audio CD / 原声

9.5 ( 35883人评价 )

▶️ Apple Music

孤独的人是可耻的 | Shameful being left alone

张楚 / 1994 / 专辑 / CD / 摇滚

9.2 ( 39886人评价 )

▶️ Apple Music

徐佳瑩La La首张创作专辑 | La La首張創作專輯

徐佳莹 / 2009-05-29 / 专辑 / CD / 流行

8.4 ( 37502人评价 )

▶️ Apple Music

The Best Damn Thing | 美丽坏东西

Avril Lavigne / 2007-04-17 / Import / Audio CD / 摇滚

7.9 ( 36865人评价 )

▶️ Apple Music

知足 just my pride 最真杰作选

五月天 / 2005-11-18 / 专辑 / CD / 摇滚

9.3 ( 33223人评价 )

▶️ Apple Music

1 | The Beatles 1 / No.1

The Beatles / 2000 / 选集 / CD / 摇滚

9.5 ( 31020人评价 )

▶️ Apple Music

魔杰座 | Capricorn

周杰伦 / 2008-10-09 / 专辑 / CD / 放克/灵歌/R&B

7.9 ( 59439人评价 )

▶️ Apple Music

X&Y | 染色体

Coldplay / 2005-06-07 / 专辑 / CD / 摇滚

8.6 ( 34819人评价 )

▶️ Apple Music

19

Adele / 2008-01-28 / Import / Audio CD / 放克/灵歌/R&B

8.6 ( 35491人评价 )

▶️ Apple Music

时光机 | mayday's time machine

五月天 / 2003-11-11 / 专辑 / CD / 摇滚

9.1 ( 33602人评价 )

▶️ Apple Music

Yan Zi | 孙燕姿同名专辑

孙燕姿 / 2000-06-08 / 专辑 / CD / 流行

9.1 ( 34442人评价 )

▶️ Apple Music

Time Flies | 时日如飞

陈奕迅 / 2010-03-12 / EP / CD+DVD / 流行

8.9 ( 32688人评价 )

▶️ Apple Music

失败者的飞翔

陈绮贞 / 2008-07-13 / 单曲 / CD / 流行

8.6 ( 29389人评价 )

▶️ Apple Music

My Love

田馥甄 / 2011-09-02 / 专辑 / CD / 流行

8.4 ( 35566人评价 )

▶️ Apple Music

亲亲 | 親親

梁静茹 / 2006-10-06 / 专辑 / CD / 流行

8.2 ( 34393人评价 )

▶️ Apple Music

你王菲所以我王菲

王菲 / 2002 / 选集 / CD / 流行

9.5 ( 35275人评价 )

▶️ Apple Music

Stranger Under My Skin

陈奕迅 / 2011-02-22 / EP / CD / 流行

8.8 ( 31725人评价 )

▶️ Apple Music

Come Away with Me | 远走高飞

Norah Jones / 2002 / 专辑 / CD / 爵士

8.9 ( 30541人评价 )

▶️ Apple Music

平凡之路 | 电影《后会无期》宣传曲

朴树 / 2014-07-16 / 单曲 /

数字(Digital) / 原声 9.1 ( 79295人评价 )

nil

认了吧 | Admit it

陈奕迅 / 2007-04-24 / 专辑 / CD / 流行

8.9 ( 37928人评价 )

▶️ Apple Music

21st Century Breakdown

Green Day / 2009-05-15 / 专辑 / CD / 摇滚

8.7 ( 30578人评价 )

▶️ Apple Music

神的游戏 | Games We Play / 神的遊戲

張懸 / 2012-08-10 / 专辑 / CD / 流行

9.1 ( 39638人评价 )

▶️ Apple Music

唱游

王菲 / 1998 / 专辑 / CD / 流行

9.4 ( 39092人评价 )

▶️ Apple Music

花的姿态：演唱会经典实录 | 花的姿態經典實錄精裝版2CD+DVD

陈绮贞 / 2007-05-18 / 演唱会/Live / CD DVD / 民谣

9.3 ( 26500人评价 )

▶️ Apple Music

我去2000年

朴树 / 1999-1 / 专辑 / CD / 流行

9.4 ( 44055人评价 )

▶️ Apple Music

Young For You

GALA / 2004 / 专辑 / CD / 摇滚

8.8 ( 30290人评价 )

▶️ Apple Music

自选集 | Start Yan-zi

孙燕姿 / 2002年1月 / 专辑 / CD / 流行

9.0 ( 29171人评价 )

▶️ Apple Music

理性与感性 作品音乐会 | Sense and Sensibility

李宗盛 Jonathan / 2007-09-28 / 专辑 / CD / 流行

9.6 ( 28244人评价 )

▶️ Apple Music

比天空还远

曹方 / 2007-11-20 / EP / CD / 流行

8.5 ( 27597人评价 )

▶️ Apple Music

黑梦

窦唯 / 1994-10 / 专辑 / CD / 摇滚

9.4 ( 41855人评价 )

▶️ Apple Music

不能说的秘密 | 不能說的秘密

周杰倫,Terdsak Janpan,詹宇豪,陳承麒,黃婉琦,姚蘇蓉,黃俊郎,江語晨,長榮交響樂團 / 2007-08-13 / Soundtrack / CD / 原声

9.1 ( 45209人评价 )

▶️ Apple Music

丝路 | 通往爱的路途

梁静茹 Fish / 2005-9-16 / 专辑 / CD / 流行

8.3 ( 32166人评价 )

▶️ Apple Music

All The Lost Souls

James Blunt / 2007-09-18 / Import / Audio CD / 流行

8.6 ( 26484人评价 )

▶️ Apple Music

F.I.R.

飞儿乐团 F.I.R. / 2004-04-29 / 专辑 / CD / 摇滚

8.9 ( 41045人评价 )

▶️ Apple Music

上五楼的快活

陈奕迅 / 2009-09-23 / 专辑 / CD / 流行

7.8 ( 29505人评价 )

▶️ Apple Music

Minutes to Midnight

Linkin Park / 2007-05-15 / 专辑 / CD / 摇滚

8.4 ( 27501人评价 )

▶️ Apple Music

GOODBYE & HELLO

蔡健雅,Tanya / 2007-10-19 / 专辑 / CD / 流行

8.6 ( 28081人评价 )

▶️ Apple Music

Someone Like You

Adele / 2011-01-24 / 单曲 /

数字(Digital) / 放克/灵歌/R&B 9.5 ( 40674人评价 )

nil

迟到千年

苏打绿 / 2006-09-18 / EP / CD / 流行

9.0 ( 27165人评价 )

▶️ Apple Music

The Dark Side of the Moon

Pink Floyd / 1973 / 专辑 / 黑胶 / 摇滚

9.5 ( 45690人评价 )

▶️ Apple Music

王菲 | Faye Wong 2001

王菲 / 2001 / 专辑 / CD / 流行

9.2 ( 31937人评价 )

▶️ Apple Music

夜空中最亮的星

逃跑计划 / 2011-04-12 / 单曲 /

数字(Digital) / 摇滚 9.2 ( 60184人评价 )

nil

追梦痴子心

GALA / 2011-03-24 / 专辑 / CD / 摇滚

8.9 ( 36650人评价 )

▶️ Apple Music

宝贝

莫文蔚 / 2010-07-26 / 专辑 / CD / 流行

8.0 ( 27226人评价 )

▶️ Apple Music

黑白灰 | Black, White & Grey / 黑·白·灰

陈奕迅 / 2003 / 专辑 / CD / 流行

9.1 ( 27667人评价 )

▶️ Apple Music

安和桥北 | 献给张先诺先生

宋冬野 / 2013-08-26 / 专辑 / CD / 民谣

8.9 ( 46048人评价 )

▶️ Apple Music

Prisoner of Love | 爱情的俘虏

宇多田ヒカル / 2008-05-21 / CD IMPORT / Audio CD / 流行

9.3 ( 26585人评价 )

▶️ Apple Music

Groupies 吉他手 | Groupies

陈绮贞 / 2002-08-02 / 专辑 / CD / 流行

9.3 ( 30585人评价 )

▶️ Apple Music

Now The Day Is Over | 美好的一天

The Innocence Mission / 2004 / 专辑 / CD / 民谣

8.5 ( 24692人评价 )

▶️ Apple Music

Apologize | 抱歉

Timbaland,OneRepublic / 2007-11-06 / Single / Audio CD / 放克/灵歌/R&B

9.2 ( 32971人评价 )

▶️ Apple Music

阿菲正传 | 阿菲正傳

王菲 / 2009-06-25 / 选集 / CD / 流行

9.4 ( 26218人评价 )

▶️ Apple Music

跨时代

周杰伦 / 2010-05-14 / 专辑 / CD / 流行

7.8 ( 41601人评价 )

▶️ Apple Music

Leave | 離開

孙燕姿 / 2002-5-21 / 专辑 / CD / 流行

8.8 ( 27012人评价 )

▶️ Apple Music

被禁忌的游戏

李志 / 2004-12 / 专辑 / CD / 民谣

9.0 ( 29948人评价 )

nil

What's Going On.…?

陈奕迅 / 2006 / 专辑 / CD / 流行

9.3 ( 29133人评价 )

▶️ Apple Music

第二人生 末日版 | SECOND ROUND - NO WHERE

五月天 / 2011-12-20 / 专辑 / CD / 流行

9.2 ( 26729人评价 )

▶️ Apple Music

樂之路 | Ultrasound 1997-2003 / 乐之路

陶喆 / 2003-08-08 / 选集 / CD / 流行

9.2 ( 26071人评价 )

▶️ Apple Music

It Won't Be Soon Before Long | It Won't Be Soon Before Long

Maroon 5 / 2007-05-22 / 专辑 / CD / 流行

8.4 ( 25476人评价 )

▶️ Apple Music

如果你冷 | 如果你冷

张悬 / 2008-10-20 / Bootleg / 数字 / 民谣

8.5 ( 26320人评价 )

nil

陌生人

蔡健雅 Tanya Chua / 2003-06-00 / 专辑 / CD / 流行

8.7 ( 26152人评价 )

▶️ Apple Music

浮躁

王菲 / 1996 / Audio CD / 流行

9.4 ( 37119人评价 )

▶️ Apple Music

C'est La Vie | 这就是生活

自然卷 / 2004 / 专辑 / CD / 民谣

8.3 ( 24874人评价 )

nil

在一起 | Together

刘若英 / 2010-04-16 / 专辑 / CD / 流行

7.9 ( 24721人评价 )

▶️ Apple Music

These Friends Of Mine

Rosie Thomas / 2007-03-13 / 专辑 / Audio CD / 民谣

8.8 ( 23227人评价 )

▶️ Apple Music

陪我歌唱 | 苏打绿台北小巨蛋演唱会Live Cd:陪我歌唱

苏打绿 / 2008 / 引进版 / CD

9.2 ( 23965人评价 )

▶️ Apple Music

It＇s Not Me It＇s You | 非我即你

Lily Allen / 2009-02-09 / 专辑 / Audio CD / 流行

8.2 ( 24122人评价 )

▶️ Apple Music

The Rose~I Love Cinemas~

手嶌葵 / 2008-03-05 / Import / CD / 流行

9.3 ( 24179人评价 )

▶️ Apple Music

我爱南京

李志 / 2009-10-16 / 专辑 / CD / 民谣

8.9 ( 32777人评价 )

▶️ Apple Music

消失的光年 | 消失的光年

大乔小乔 / 2007-07-12 / 平装版 / CD / 民谣

8.3 ( 23581人评价 )

▶️ Apple Music

还有别的办法吗

范晓萱 / 2004 / 专辑 / CD / 流行

8.7 ( 22928人评价 )

▶️ Apple Music

日光倾城

卡奇社 / 2007-04-20 / 专辑 / CD / 流行

8.2 ( 24481人评价 )

▶️ Apple Music

A Little Love | 一点爱

冯曦妤 / 2008-11-20 / 专辑 / CD / 流行

8.5 ( 23442人评价 )

▶️ Apple Music

Yellow | 黄色

Coldplay / 2000-07-03 / EP / Audio CD / 摇滚

9.5 ( 37346人评价 )

▶️ Apple Music

Hopes And Fears

Keane / 2004 / 专辑 / Audio CD / 摇滚

8.9 ( 22915人评价 )

▶️ Apple Music

U87

陈奕迅 / 2005-06-07 / 专辑 / CD+DVD / 流行

9.4 ( 29071人评价 )

▶️ Apple Music

Lady Sleep | 睡美人

Maximilian Hecker / 2005 / Import / Audio CD / 摇滚

8.8 ( 21513人评价 )

▶️ Apple Music

天空の城ラピュタ サウンドトラック 飛行石の謎 | 天空之城 原声碟

久石譲(Joe Hisaishi),杉並児童合唱団,井上杏美 / 1993-12-21 / Soundtrack / Audio CD / 原声

9.6 ( 26336人评价 )

▶️ Apple Music

新长征路上的摇滚

崔健 / 1989 / 专辑 / CD / 摇滚

9.4 ( 31792人评价 )

▶️ Apple Music

小飞行

棉花糖,katncandix2 / 2009-05-01 / 专辑 / CD / 民谣

8.0 ( 22804人评价 )

▶️ Apple Music

春生

好妹妹乐队 / 2012-07-01 / 专辑 / CD / 民谣

8.9 ( 23906人评价

▶️ Apple Music

讓我想一想 | 让我想一想

陈绮贞 / 1998-07-14 / 专辑 / CD / 民谣

9.1 ( 24812人评价 )

▶️ Apple Music

未来 | Wonderland

方大同 / 2007-12-28 / 专辑 / CD / 放克/灵歌/R&B

8.4 ( 23802人评价 )

▶️ Apple Music

爱爱爱 | 愛愛愛 / THIS LOVE

方大同 / 2006-12 / 专辑 / CD / 流行

8.7 ( 25456人评价 )

▶️ Apple Music

世界 | Earth

逃跑计划 / 2014-12-09 / 专辑 / CD / 摇滚

9.0 ( 26819人评价 )

▶️ Apple Music

七天 | 盧廣仲 Crowd Lu 2009 New Album 2009 全新創作專輯

盧廣仲,卢广仲 / 2009-10-30 / 专辑 / CD / 民谣

7.9 ( 22531人评价 )

▶️ Apple Music

Nirvana

Nirvana / 2002-10-29 / Extra tracks / Audio CD / 摇滚

9.3 ( 22711人评价 )

▶️ Apple Music

nil

A Rush of Blood to the Head

Coldplay / 2002 / 专辑 / Audio CD / 摇滚

8.8 ( 25535人评价 )

▶️ Apple Music

The Velvet Underground & Nico | 地下丝绒与妮可

The Velvet Underground,Nico / 1967-04 / 专辑 / CD / 摇滚

9.3 ( 31513人评价 )

▶️ Apple Music

Love The Way You Lie

Eminem,Rihanna / 2010-08-20 / Single / Audio CD / 说唱

9.3 ( 28411人评价 )

nil

天空 | Sky

王菲 / 1994 / 专辑 / CD / 流行

9.4 ( 29503人评价 )

▶️ Apple Music

The Boat That Rocked

Original Soundtrack / 2009-03-30 / Import / Soundtrack / CD / 原声

9.3 ( 20223人评价 )

nil

(What's The Story) Morning Glory?

Oasis / 1995 / 专辑 / CD / 摇滚

9.3 ( 27765人评价 )

▶️ Apple Music

PUSSY

陈绮贞 / 2007-02-08 / 单曲 / Audio CD / 民谣

8.7 ( 21369人评价 )

nil

呼吸 | Breathe - All About Lily Chou-Chou / Lily Chou-Chou：呼吸

Salyu / 2001 / 专辑 / CD / 原声

9.1 ( 22021人评价 )

▶️ Apple Music

Fallen

Evanescence / 2003 / 专辑 / Audio CD / 摇滚

8.5 ( 21152人评价 )

▶️ Apple Music

黑豹

黑豹 / 1992-12-01 / 专辑 / CD / 摇滚

9.3 ( 27065人评价 )

▶️ Apple Music

十年一刻

苏打绿 / 2010-08-27 / 视频 / CD+DVD / 流行

9.0 ( 23902人评价 )

▶️ Apple Music

恋爱的力量 | The Power Of Love Songs

梁静茹 / 2003年3月 / 专辑 / CD / 流行

9.0 ( 22492人评价 )

▶️ Apple Music

Suede

Suede / 1993 / 专辑 / CD / 摇滚

9.0 ( 24460人评价 )

▶️ Apple Music

The Bends

Radiohead / 1995 / 专辑 / CD / 摇滚

9.3 ( 30381人评价 )

▶️ Apple Music

琵琶相 | Pipa images LIN HAI & FRIENDS 2

林海 / 2004 / 专辑 / CD / 轻音乐

9.4 ( 21797人评价 )

▶️ Apple Music

？| 问号

陈奕迅 / 2011-11-11 / 专辑 / CD / 流行

8.1 ( 24284人评价 )

▶️ Apple Music

少年故事

彭坦 / 2007-07-23 / 专辑 / CD / 流行

8.2 ( 22022人评价 )

▶️ Apple Music

黑暗之光

雷光夏 / 2006-12-01 / 专辑 / CD / 民谣

8.9 ( 21264人评价 )

▶️ Apple Music

我要我们在一起

范晓萱 / 1999-11-1 / 国语 / CD / 流行

8.8 ( 24064人评价 )

▶️ Apple Music

人生海海

五月天 / 2001-07-06 / 专辑 / CD / 摇滚

9.3 ( 25704人评价 )

▶️ Apple Music

Maybe I'm Dreaming | 可能我在做梦

Owl City / 2008-03-18 / Import / CD / 流行

8.4 ( 20707人评价 )

▶️ Apple Music

工体东路没有人

李志 / 2009-01-22 / 专辑 / 数字 / 民谣

9.2 ( 23029人评价 )

nil

Let It Be

The Beatles / 1990-10-25 / Enhanced / Audio CD / 摇滚

9.5 ( 25678人评价 )

▶️ Apple Music

Alright,Still | 一如既往

Lily Allen / 2006 / Import / Audio CD / 流行

8.4 ( 20280人评价 )

▶️ Apple Music

大小說家 | Fiction

林宥嘉 / 2012-06-22 / 专辑 / CD / 流行

8.2 ( 24828人评价 )

▶️ Apple Music

越长大越孤单

牛奶@咖啡 / 2008-03-18 / 专辑 / CD / 流行

7.8 ( 27754人评价 )

▶️ Apple Music

燕尾蝶 | 燕尾蝶-下定愛的決心

梁静茹 / 2004 / 专辑 / CD / 流行

8.1 ( 25599人评价 )

▶️ Apple Music

原谅我就是这样的女生 | 原諒我就是這樣的女生

戴佩妮 / 2009-05-16 / 专辑 / CD+DVD / 流行

7.7 ( 21671人评价 )

nil

传奇

王菲 / 2010-11-05 / 单曲 / CD / 民谣

9.0 ( 26139人评价 )

nil

Under the Radar | 墜入琴網

Daniel Powter / 2008-10-14 / 专辑 / Audio CD / 流行

8.5 ( 19397人评价 )

▶️ Apple Music

知足 MV / Karaoke DVD

五月天 / 2006 / 视频 / DVD / 流行

9.3 ( 20016人评价 )

▶️ Apple Music

我的歌声里

曲婉婷 / 2012-07-01 / 专辑 / CD / 流行

8.1 ( 21550人评价 )

▶️ Apple Music

王菲快樂/不快樂

王菲 / 1997-09-30 / 专辑 / CD / 流行

9.4 ( 30662人评价 )

nil

信仰在空中飘扬

汪峰 / 2009-07-25 / 专辑 / CD / 摇滚

8.8 ( 20801人评价 )

nil

[i]Karen Love

莫文蔚 / 2002-04-29 / 专辑 / CD / 流行

8.8 ( 22357人评价 )

▶️ Apple Music

Songs About Jane

Maroon 5 / 2002 / 专辑 / Audio CD / 流行

8.8 ( 21946人评价 )

▶️ Apple Music

Back To Black

Amy Winehouse / 2006-10-30 / 专辑 / Audio CD / 放克/灵歌/R&B

8.9 ( 22840人评价 )

▶️ Apple Music

Demo 3

陈绮贞 / 2001-11-09 / Demo / CD / 流行

9.2 ( 19720人评价 )

nil

克卜勒 | Kepler

孙燕姿 / 2014-02-27 / 专辑 / CD / 流行

8.7 ( 32216人评价 )

▶️ Apple Music

E=MC² | 爱的方程式

Mariah Carey / 2008-04-16 / 专辑 / CD / 放克/灵歌/R&B

8.6 ( 21245人评价 )

▶️ Apple Music

9 Crimes

Damien Rice / 2006-11-27 / 单曲 / Audio CD / 民谣

9.4 ( 18711人评价 )

▶️ Apple Music

如果有一件事是重要的 | 如果有一件事是重要的+粉红色(demo)

陈珊妮 / 2008-11-22 / 专辑 / CD / 流行

8.3 ( 20153人评价 )

▶️ Apple Music

赤裸裸 | 赤裸裸?!

郑钧 / 1994 / 专辑 / CD / 摇滚

8.9 ( 24139人评价 )

▶️ Apple Music

阿岳正传 | Useless Guy

张震岳 / 2004-06-24 / 选集 / CD / 流行

9.0 ( 20320人评价 )

▶️ Apple Music

3颗猫饼干 | 三颗猫饼干 / Three Cat Cookies

朱玫玲,董運昌,王雁盟,何真真 / 2004/04/26 / CD / 轻音乐

9.2 ( 17459人评价 )

▶️ Apple Music

21 Guns

Green Day / 2009-07-14 / Single / Audio CD / 流行

9.2 ( 20417人评价 )

nil

看我72变

蔡依林 Jolin Tsai / 2003-03-07 / 专辑 / CD / 流行

8.1 ( 34974人评价 )

▶️ Apple Music

第二人生 明日版 | SECOND ROUND - NOW HERE

五月天 / 2011-12-20 / 专辑 / CD / 流行

9.2 ( 20376人评价 )

▶️ Apple Music

Definitely Maybe | 绝对可能

Oasis / 1994-08-30 / 专辑 / CD / 摇滚

9.2 ( 24503人评价 )

▶️ Apple Music

First Love | 初恋

宇多田ヒカル / 1999 / 专辑 / CD / 流行

9.2 ( 24302人评价 )

▶️ Apple Music

阿密特意识专辑

张惠妹 / 2009-06-26 / 专辑 / CD / 流行

8.1 ( 23719人评价 )

▶️ Apple Music

心·跳心跳

王力宏 Leehom Wang / 2008-12-26 / 专辑 / CD / 流行

7.3 ( 23629人评价 )

▶️ Apple Music

xx同名专辑

The xx / 2009-08-17 / 专辑 / CD / 摇滚

8.9 ( 22501人评价 )

▶️ Apple Music

回蔚

莫文蔚 / 2009-06-23 / 专辑 / CD+DVD / 流行

8.1 ( 20095人评价 )

▶️ Apple Music

如果看見地獄，我就不怕魔鬼 | If I See Hell, I Won't Be Afraid of Demons

Tizzy Bac / 2009-02-13 / 专辑 / CD / 流行

8.2 ( 19128人评价 )

▶️ Apple Music

我们是五月天

五月天 / 2003年4月17日 / 专辑 / CD / 流行

9.4 ( 21570人评价 )

▶️ Apple Music

王妃 | 王妃

萧敬腾 / 2009-07-17 / 专辑 / CD / 流行

7.9 ( 24245人评价 )

▶️ Apple Music

Poker Face | 扑克脸

Lady Gaga / September 23, 2008 / Single / Audio CD / 流行

8.8 ( 25206人评价 )

▶️ Apple Music

唐朝 | 梦回唐朝

唐朝 / 1992-12 / CD＋DVD / CD / 摇滚

9.1 ( 22391人评价 )

▶️ Apple Music

寻找周杰伦

周杰伦 / 2003-12-1 / EP / 音乐CD / 流行

9.1 ( 29108人评价 )

▶️ Apple Music

她说 | 概念自选辑

林俊杰 / 2010-12-08 / 专辑 / CD / 流行

8.3 ( 34938人评价 )

▶️ Apple Music

随着业务规模扩大、团队组成变复杂，如何降低项目实施风险，降低软件复杂度变得尤为关键。 我从 Martin Flower、Joel Spolsky（软件随想录 作者） 等巨匠智慧中寻找解决复杂工程之道，其中 Code Review 是行之有效手段。 我认同 Code Review 价值也是忠实执行者。

加入蚂蚁以后，我在所接触项目中都大力推广 Code Review。 感谢团队信任和支持，目前 CR 协作进展顺利， 项目 CR 从最早不主动，到现在形成基于模块 Owner 制度 CR 和 Peer Review。 我也曾经在 3 个月内处理完成 700 多个 Pull Request，并在 PR 讨论中中都留下一些有价值讨论。 这里我将自己对 Code Review 一些理解记录下来。

这一篇先讲讲进入 Code Review 之前需要做准备工作。

评估团队成熟度

不管是在一个遗留系统上推广 Code Review，还是在一个新团队推广 Code Review， 起手式不是立马挽起袖子猛干，而是应当观察一下当前所处情况是否允许自己推动这个「艰巨」任务。 最需要观察的是团队成熟度。

我将团队成熟度粗略分为草台班子、成长型团队、成熟团队。 具体衡量指标可以有成员技术储备、团队成员信任度、团队负责人对工程管控力度。 相信集团内大部分团队处于成长型、成熟型团队。 但如果考虑到生态同学一起协作，或者临时因为紧急项目凑在一起，就比较容易成为「草台班子」。

如果还停留在草台班子，那就得先在团队内形成一定共识： 包括技术共识和合作模式的共识。 技术共识需要包括：技术栈共识、好代码定义、研发流程共识等。 合作模式共识需要包括：冲突解决机制、职责范围边界、决策机制等。 如果基本共识还没有形成就仓促进入 Code Review，那就容易将一件好事变成工程师战争。

并不是所有团队、项目都适合无差别引入 Code Review。这么几种情况建议暂缓 Code Review 推广：

• 老板和同事都不支持甚至反对
• 业务重要性低，或者团队都是特立独行高手
• 创新业务需要快速上线，这时候适合将这类任务分发给配合度高老团队，或者给高手单兵作战

当条件不满足时也不用气馁。先成为一个布道师吧，探索一下团队中有没有相似想法的人，了解一下他们担心点和诉求点。 相信只要条件允许，没有人会拒绝提高工程质量。

构建「好代码」共识

Code Review 核心产出物是代码，如何界定代码是好是坏就至关重要。 根据 Bjarne（「C++ Programming Language」作者）、Grady Booch（「面向对象分析与设计」作者）等人定义， 总结下来好代码有这么基本特征（via「Clean Code」）：

• 正确
• 可测试
• 不重复
• 少且简单
• 可读

深思一下这些基本特征背后道理：代码是人类和机器沟通工具，好代码也要利于人类阅读和再次书写。 人比机器更犯错，机器算力在成倍增长，因此简单易维护重要度逐步增高。 这些朴素道理也正是语言从低级语言进化到高级语言驱动力， 也是近几年高级语言语言特性主打点（类型系统、格式系统、面向人类同步思想异步设计）。

但上面这几条原则太底层了，无法成为实践标准。 因此行业基于这些公理衍生了不少实践定理，我将其分为工程规约和设计范式两类。

工程规约包含语言风格规约和应用工程规约。 语言风格规约比较容易理解，开源世界提供了很多选择。硅谷大厂 Google / Facebook / Uber 等都有不少规约提供。 国内还有极具价值的「阿里巴巴 Java 开发手册」，我称之为 50331 ;) （PS：「阿里巴巴 Java 开发手册」不仅有语言风格规约、也有应用工程规约和一部分设计规约）。 这里罗列了一些常见面向语言的 Style Guide。

• Google Style Guides | styleguide
  • 包含 C++ / Object-C / Java / Python / R / Shell / HTML CSS / JavaScript / AngularJS / Common Lisp / Vimscript
• alibaba/p3c: Alibaba Java Coding Guidelines pmd implements and IDE plugin
  • Java
• airbnb/javascript: JavaScript Style Guide
  • JavaScript
• uber-go/guide: The Uber Go Style Guide.
  • Go

应用工程规约关注点则更为落地：包括依赖管理、配置管理、应用层次结构、对外服务暴露约束，数据建模，文档注释，测试管理， 甚至包含中间件使用规约。 这些规约逐步从「如何表达代码」延展到到「如何管理工程」。 这块发挥空间比较大，中大规模团队会有应用框架组这样团队。 基于应用框架对使用方式方法约束。针对具体业务使用也会给出针对性建议。 这些定理总结出来往往以轻量 Best Practice 和重量级应用框架对外输出。

这里举两个例子说明一下应用工程规约应该讲清楚哪些问题。 第一个例子 alibaba/COLA 这个项目来说，它约束了整体工程结构，并且明确的通过 Archetype 帮助（约束）用户行为。 第二个例子是 RoR / Django 这类 RoR 框架，他们使用约定大于配置方式，基于 ActiveRecord 这种模式约束了用户如何使用框架， 从 Model、Controller 到 Router，对立面则是 Spring MVC / Flask 这类框架，几乎只提供纯技术特性，不约束开发者行为。

除了阿里 Java 开发手册，这里提供三个应用工程规范供参考：

• alibaba/COLA: Clean Object-oriented & Layered Architecture
• SOFA 项目工程结构 - 蚂蚁金服金融科技 和 SOFA 微服务平台概述 - 蚂蚁金服金融科技
• realpython/python-guide: Python best practices guidebook, written for humans.

比工程规约更难定义的是设计范式，核心点是解决「如何做架构决策」。 设计范式决策过程在系统架构设计和系分设计阶段就应当完成了。 如果设计范式差异性导致代码在 Code Review 阶段出现意见不一。 要么是这个团队过于草台班子，要么是这个项目架构师/负责人在前期设计做的工作太少了。

当一个团队遵循相近设计范式，意味着他们达到了同一级别技术储 备，并形成了统一自顶向下设计打法。 在 Code Review 过程中，一些范式使用完全可以将 GoF23 / S.O.L.I.D. / DDD 这些术语概念拎出来。 相信 Commiter 和 Reviewer 可以基于业务场景快速达成一致。

方法论贴在墙上是无法解决开发中中遇到设计问题，在代码中真刀真枪干，Show me the fuck code。

Code Review 沟通协作机制

除了工程规约，还有一件事情往往会被忽略，如何解决冲突？ 这个冲突不是指代码 Conflict，而是面对技术方案决策时候交流讨论。

文无第一武无第二，两个秀才在一起能吵到天翻地覆面红耳赤。 技术层面 Augue 容易陷入我说我有理你说你有理局面。这种情况如何解决？ 没有一个好协作机制，会倒逼 Commiter 和 Reviewer 退缩，不能充分展开讨论。 这是我们不想看见。

很多时候技术决策就是在 40% 正确性 和 60% 正确性中间选择，看中长期收益和短期收益就可能导致结论不一样。 非黑既白反而不容易有争论。想要促进快速决策，一套冲突解决机制就不可缺少。 因此一定要在事前制定一套冲突解决机制。大部分冲突解决都可以使用这么一套逻辑：数据、逻辑、民主、独裁。 当需要进行某个技术或者产品决策时候，最优先方式是用数据来量化，证明自己观点。 当数据不充分时候，可以进行逻辑归纳推衍形成结论。 当形成逻辑不能服众众说纷纭时候，可以使用民主方式进行裁决。 当民主也无法生效，就需要 Owner / 一号位力排众议，进行独裁决策了。

CodeReview 有这么几种形式，同步离线、异步离线、同步在线。 处于同步形式 CodeReview 需要尽快处理掉 PR，这时候协作机制一定要干净利索，避免大家在 PR 反反复复来来回回讨论。 如果每个 PR 都要消耗数次来回沟通，我建议将 CR 形式升级到同步在线，拉个会议立刻将事情解决。

如果在一个实现方案上真无法决策，如果不涉及原则，那我建议使用搁置争议，使用 TODO @commiter what, how, when 方式先标记意见和处理时间，先行将工程开发往下推进。

一切准备好了，谢天谢地，终于可以进入 Code Review 阶段了。 我们下篇文章再来讲进入 Code Review 阶段的事情。

图片摄于北京圆明园

怎么描述 2018？我找了三个关键词。

2018 忙、拥抱变化、新生

我的 2018 年从北京拉开帷幕，1 月份时候团队几个小伙伴一起去给北京研发中心同学做了一次技术分享。 TL 余老师带我们三个架构师逛了圆明园，北京小伙伴热情招待我们吃了东来顺火锅。 在天津时候还第一次从海河冰面渡河。只是没想到，这次旅行成了我在沪江最后一次团建，

当时我已经有一些想法离开沪江，一些问题逐步暴露出来： 沪江工作舒适、做事情自由，但技术上缺乏量级挑战，制度上内部流程僵化，部门利益关系错综复杂。 我深信业务、技术是互相引领促进，在这种环境下无法全力施展拳脚。

恰好此接到蚂蚁金服 Sourcing 电话，于是开始走面试流程。事后证明，这是不靠谱沟通流程， 无准备状态的我让一些细节问题考倒(这也让我养成了 Sourcing 候选人时候都会问一句最近有没有做过面试准备)。 最终我还是走完了流程，以（我以为的） SRE 身份加入了蚂蚁。这里隐含一个巨大风险， 当时我对蚂蚁金服体系不够了解，这也给之后「拥抱变化」埋下了伏笔。

加入蚂蚁之后一个月后，第一个项目就让我大跌眼镜，我成为了一个增删改查工程师，而且是在技术债务较为严重项目上开展。 这个项目疲惫不堪，倒不是加班加点，而是在业务进度压迫之下必须囫囵吞枣实现功能， 不顾工程设计缺乏，框架使用方式不标准，带来大量低效劳动重复劳动。 期望成为 SRE 做 Infrastructure 的我一下子就蒙逼了，我先压下不满和震惊，抱着学习态度先投入完成交给自己的任务。

9 月儿子出生，我似乎做足了准备，但仍然发现准备不充分。 怀抱红彤彤的小精灵，我该如何做好父亲一角色？ 这触发了我对家庭关系、父子关系的思考。我能给他提供什么，带来什么？我希望他成为什么样的人？ 坎贝尔的千面英雄里提到的英雄之旅给我深刻印象。 人生历程是一个少年成为英雄的过程：懵懂、自我、挑战、出走、成长、灭龙、回归。 期望在他英雄之旅上，我能成为他的后盾，他的炮火，也能在他疲惫时候给他温暖归处。

陪产假很快结束，我重新回到工作中节奏仍然没有能控制起来，做了两个体量并不大的项目。 「拥抱变化」这个词我很喜欢，这是一种 VUCA 下面抵抗不确定性生存策略。 我不想让信任我的伙伴失望，也不愿意轻易放弃，持续想在业务场景中挖掘技术能够发挥价值。 18 年末我抓到一个机会。尽管这个想法还不够完善，但这个机会是我能够发挥价值重大突破口。

纵观 18 年，我职业生涯面临了巨大拐点，做了一个选择。 这也许不是最好，但是回头看 19 年沪江经历了一场巨大人事变动，至少这不是最差。

量化 OKR

语言力量是软弱的，我直接用量化数字来回顾 2018。 很不幸，按照年初计划 OKR 来看，这一年我的评分特别打脸。 原因有如下几个：

• 照顾家庭，照顾夫人和照顾小孩
• 工作环境变化，需要额外精力投入
• 目标设定较高，有妄念

量化表格附在本文最后。 完成度按照每季度如下：

• 5.88%
• 12.02%
• 6.61%
• 2.66%

第二季度是在沪江最后一段旅程，这段时间我个人时间充沛，做了不少事情。 完成了 ProgFun 学习，尽管狼狈仍然跑完了开智写作课。 第三季度开始我产能大幅降低，主要受家庭影响。 第四个季度我精力大量投入在工作上面，仅剩一些精力优先放到家庭，进一步导致个人事项度降低。 工作时间大幅增加，每周用 1 天时间陪伴家人，另外有一天时间用来个人事项处理。 个人时间由以前每个月 70（(2*5+6*2)*4）降低到 24（6*4），几乎只有之前 1/3 时间。

接下来是 2019 年 OKR 安排。从个人发展方向上来说 18 年安排问题在于贪心。综合个人发展和精力分配， 以去年完成度为参考，新年任务安排需要调整为 1/4。

19 年 OKR 有这么几个原则：

• 平衡好工作、家庭和个人三方面时间分配
• 个人 OKR 在 2018 年基础上做减法，而不是持续增加负荷
• 精力减少，更要安排事项优先级，避免贪多嚼不烂
  • 去除几个主题：区块链、经济学、Scala、分布式数据库、Go
• 从个人长期事业规划出发，结合当前工作需求，圈定专项
  • 数据分析、机器学习上面，Java 语言
  • 数学、英语还是持续投入

2019 OKR 具体表格在附录。

有一点比较感慨，想做事情多，但是真正计算下来，尤其是加入阿里之后，个人能够分配时间真是少之又少。 真想好好珍惜学生时代以及以前工作不那么繁忙时光。

2018 书影音

聊一些轻松一些话题，推荐一下我 2018 年使用的不错物品、阅读书籍和观影。

• 个人好物
  • Nitendo Switch + 塞尔达传说
  • 天猫精灵：前后购入 4 个，小朋友最爱
  • 小米之家运动鞋：物美价廉
  • MacBook Pro 摄像头遮挡贴：https://detail.tmall.com/item.htm?id=555224375945
  • 3D 电影专用偏光镜片：https://detail.tmall.com/item.htm?id=534639536731
  • 自带名字定制红包：https://item.taobao.com/item.htm?id=561176419636
  • SONY 微单 a6500，用一只 a6500 置换了母亲 Canon 6DII，微单确实方便携带，适合我这种随手拍用户
  • FUJIIRYOKI JP870 按摩椅：用过之后，其他按摩椅都是渣渣 https://item.jd.com/11295717231.html
• 书（四星以上，去掉虚构类书籍）
  • 跑步，该怎么跑？ (豆瓣)
  • 古文观止 (豆瓣)
  • 车主生活从这里开始 (豆瓣)
  • 打破自我的标签 (豆瓣)
  • 人类群星闪耀时 (豆瓣)
  • 算法新解 (豆瓣)
  • 进化 (豆瓣)
  • 把你的英语用起来！ (豆瓣)
  • 民主的细节 (豆瓣)
  • 西尔斯怀孕百科 (豆瓣)
  • 怀得上，生得下 (豆瓣)
  • 深入理解Nginx（第2版） (豆瓣)
  • 楚辞 (豆瓣)
  • 硅谷钢铁侠 (豆瓣)
  • 风格感觉 (豆瓣)
  • Google软件测试之道 (豆瓣)
  • 反脆弱 (豆瓣)
  • 企业IT架构转型之道：阿里巴巴中台战略思想与架构实战 (豆瓣)
• 影（五星）
  • 黑镜 第一季
  • 新世纪福音战士
  • 猫鼠游戏
  • 至暗时刻
  • 追风筝的人
  • 舌尖上的新年
  • 2001太空漫游
  • 当我们离开地球：美国国家航空航天局的太空行动
  • 荒岛余生
  • 人生一串
  • 卢旺达饭店
  • 末代皇帝
  • 阿波罗13号
  • 河西走廊
  • 造梦者
  • 我不是药神

2019 初春

2019 已经过去一个季度了，我刚结束为期一个月 9116 项目冲刺。 终于可以缓口气，在四月初带小孩出行踏青看落樱。 尽管偶尔疲惫不堪，偶尔对自己工作不满，但仍然对未来充满信心和期待。 机会时代的智慧不仅仅只是等待和希望，更应该是探寻和希望。

附录 2018 OKR 表格

附录 2019 年 OKR 表格

最近有一位朋友和我聊职业发展方向问题，聊了不少 DevOps 和 SRE 话题。 我几年前刚接触这两个概念时也常常将之混淆，可惜当时没有人来解答我困惑。 现在这虽然已经极为流行，但是我发现我这位朋友对这两个职位还存在一些误区。 于是我给了一些见解并整理成文章以饕大众。

最常见的误区：

• DevOps 新概念，好高级哦
• SRE 是高级版 DevOps
• 运维可以轻松转身 DevOps 工程师

让我一一给你讲解吧。

image via YouTube

DevOps 和 SRE 定义

DevOps 是字面上 Dev 开发 / Ops 运维两者组合， 严格意义上 DevOps 如下（via DevOps - Wikipedia）：

DevOps（Development 和 Operations 的组合词）是一种重视“软件开发人员（Dev） ”和“IT 运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。

SRE 全称是 Site Reliability Engineering，最早是由 Google 提出，并且在其工程实践中发扬光大。 他们还出了一本同名书籍「Site Reliability Engineering」， 让这个理念在互联网工程师圈子里广泛传播。

Google 对 SRE 解释是（via Site Reliability Engineering - Wikipedia）：

Site reliability engineering (SRE) is a discipline that incorporates aspects of software engineering and applies that to operations whose goals are to create ultra-scalable and highly reliable software systems.

我将其翻译翻译为中文：

网站稳定性工程师是致力于打造「高扩展、高可用系统」，并将其贯彻为原则的软件工程师。

从定义来看，DevOps 是文化、运动和惯例，而 SRE 是有严格任职要求的职位。 文化是软性定义，文化有更多概念可以捏造，而 SRE 定义精准，就少了想象空间（也可能 SRE 门槛高 😄）。 按 Google 给出的说法是，SRE 工程师实践了 DevOps 文化。这个观点没错，但是国内的 DevOps 逐步独立出 DevOps 工程师， 所以在本文，我着重讨论的是 DevOps 工程师和 SRE 工程师两种职位对比。

两者产生背景和历史

互联网需求催生了 DevOps 。在最传统软件企业中，是只有 Dev 没有 Ops， 那时 Ops 可能还是只是技术支持人员。开发按照瀑布流：需求分析、系统设计、开发、测试、交付、运行， 传统软件发布是一个重量级操作。一旦发布，Dev 几乎不再直接操作。 80 后可能会记得 QQ 每年都会有一个大版本发布吧，QQ 2000 / 2003 / 2004 等等。 此时 Ops 不用和 Dev 直接高频接触，甚至针对一些纯离线业务，压根没有设立 Ops 这个岗位。

互联网浪潮之后，软件由传统意义上桌面软件演变为面向网站、手机应用。 这时候业务核心逻辑，比如交易，社交行为都不在用户桌面完成，而是在服务器后端完成。 这给互联网企业给予了极大操作空间：随时可以改变业务逻辑，这促进了业务快速迭代变更。 但即便这样，Dev 和 Ops 是极其分裂的两个环节。Ops 不关心代码是如何运作的，Dev 不知道代码如何运行在服务器上。

当业界还沉浸在可以每周发布版本喜悦中时，2009 年，Flicker 提出了每天发布 10+ 次概念，大大震撼了业界。 Flicker 提出了几个核心理念：

• 业务快速发展，需要拥抱变更，小步快跑
• Ops 目标不是为了网站稳定和快速，而是推动业务快速发展
• 基于自动化工具提高 Dev / Ops 联接：代码版本管理、监控
• 高效沟通：IRC / IM Robot（现在那些 ChatBot 套路，10 年前就被 Flicker 玩过了）
• 信任、透明、高效、互助的沟通文化

原文 SlideShare 在这 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr

真是让人难以想象，今天各种培训公司和一些知名大 V 在呼唤这些 DevOps 理念， 竟然在 2009 年一份幻灯片中就展现淋漓尽致。经典总是不过时，在尘封下闪耀着智慧光芒。 有些人将 DevOps 和运维自动化等同，这是只看到表象。 DevOps 目标是提高业务系统交付速度，并为之提供相关工具、制度和服务。 一些个人或培训机构添油加醋和衍生含义，都是围绕这 DevOps 本质而发散。

接下来聊聊 SRE 历史， SRE 出现要晚一些。在 2003 年时候 Google 的 Ben Treynor 招募了几个软件工程师，这个团队设立目的是帮助 Google 生产环境服务运行更稳定、健壮、可靠。 不同于中小型规模公司，Google 服务于十几亿用户服务，短暂服务不可用会带来致命后果。 因此 Google 走在了时代最前面，SRE 产生了。

这个职位为大规模集群服务，小型团队不需要这样职位设定（可能也招不起真正 SRE 😊）。 Google 在探索若干年之后，SRE 团队开始将自己心得体会写在线上，并在 2016 年将此书出版。

两者的职能不同

DevOps 文化，那么就没有一个具象职能要求。现在不少公司将 DevOps 职能单独抽取出来，称之为 DevOps 工程师。 那让我们看看 DevOps 工程师关心什么：DevOps 文化目的是提交交付速度， DevOps 工程师就自然会关心软件 / 服务的整个生命周期。

一个简单的公式：速度 = 总量 / 时间，添上工程行业术语，即 交付速度 = （（功能特性 * 工程质量） / 交付时间） * 交付风险。

功能特性交给产品经理和项目经理管理，DevOps 工程师需要关心剩下几个因素：工程质量 / 交付时间 / 交付风险。 DevOps 工程师职能如下：

• 管理应用全生命周期（需求、设计、开发、QA、发布、运行）
• 关注全流程效率提升，挖掘瓶颈点并将其解决
• 自动化运维平台设计和研发工作（标准化、自动化、平台化）
• 支持运维系统，包括 虚拟化技术、资源管理技术、监控技术、网络技术

SRE 关键词是「高扩展性」「高可用性」。高扩展性是指当服务用户数量暴增时， 应用系统以及支撑其服务（服务器资源、网络系统、数据库资源）可以在不调整系统结构，不强化机器本身性能 ，仅仅增加实例数量方式进行扩容。高可用性是指，应用架构中任何环节出现不可用时，比如应用服务、网关、数据库 等系统挂掉，整个系统可以在可预见时间内恢复并重新提供服务。当然，既然是「高」可用， 那么这个时间一般期望在分钟级别。SRE 职能可以概括为以下：

• 为 应用、中间件、基础设施等提供 选型、设计、开发、容量规划、调优、故障处理
• 为业务系统提供基于可用性、可扩展性考虑决策，参与业务系统设计和实施
• 定位、处理、管理故障，优化导致故障发生相关部件
• 提高各部件资源利用率

工作内容不同

职责不同导致两个职位工作内容也不尽相同，我将 DevOps 工程师和 SRE 工程师职能列举如下：

• DevOps
  • 设定应用生命管理周期制度，扭转流程
  • 开发、管理 开发工程师 /QA 工程师使用 开发平台系统
  • 开发、管理 发布系统
  • 开发、选型、管理 监控、报警系统
  • 开发、管理 权限系统
  • 开发、选型、管理 CMBD
  • 管理变更
  • 管理故障
• SRE
  • 管理变更
  • 管理故障
  • 制定 SLA 服务标准
  • 开发、选型、管理 各类中间件
  • 开发、管理 分布式监控系统
  • 开发、管理 分布式追踪系统
  • 开发、管理 性能监控、探测系统（dtrace、火焰图）
  • 开发、选型、培训 性能调优工具

很有趣的对比，DevOps 和 SRE 都会关心应用生命周期，特别是生命周期里面中变更和故障。 但是 DevOps 工作内容是主要为开发链路服务，一个 DevOps Team 通常会提供一串工具链， 这其中会包括：开发工具、版本管理工具、CI 持续交付工具、CD 持续发布工具、报警工具、故障处理。 而 SRE Team 则关注更为关注变更、故障、性能、容量相关问题，会涉及具体业务，产出工具链会有： 容量测量工具、Logging 日志工具、Tracing 调用链路跟踪工具、Metrics 性能度量工具、监控报警工具等。

DevOps 和 SRE 关系

DevOps 首先是一种文化，后期逐渐独立成一个职位；SRE 一开始就明确是一个职位； 不少同学把 DevOps 和 SRE 搞混，是被两者表象锁迷惑，看上去这两者都有的工具属性、自动化要求也相似。 甚至有一些开发同学把这类运维工作都统一理解为：服务器 + 工具 + 自动化。这是盲人摸象，管中窥豹。

从技能上来说，两者都需要较强的运维技能。 在职业发展天花板上，DevOps 可能缺乏 SRE 在一些专业领域的技能： 计算机体系结构能力；高吞吐高并发优化能力；可扩展系统设计能力；复杂系统设计能力；业务系统排查能力。 两者都需要软实力，但是 SRE 面临复杂度更高，挑战更大，要求也更高：

• 分析问题、解决问题能力
• 对业务系统更了解
• 具备高并发、高可用系统设计实施经验
• 对整个系统链路有更全面认识

DevOps 具有普遍意义，现代互联网公司都需要 DevOps，但是并非所有团队对高可用性、高扩展性存在需求，它们不需要 SRE。 DevOps 工程师掌握相关技能之后，也有机会可以发展为 SRE 工程师。 而一位合格 SRE 工程师，在有选择情况下面，我相信不会去转型为 DevOps 工程师。

从专业背景来看，无论是 DevOps 还是 SRE 工程师，都需要研发背景，前者需要开发工具链，后者需要有较强架构设计经验。 如果有运维工程师想转型成为 DevOps 或者 SRE，那么需要补上相关技术知识。 毕竟，不是会搭建一套 Jenkins + Kubernetes 就可以自称为 DevOps / SRE 工程师。

怎么样，有没有解开这几个常见误区呢？希望你看到这里可以豁然开朗，最后附上两个工程师的技能点， 期望有志成为这两种工程师的同学，加油努力。

附录：技能点

DevOps：

• Operator 技能
  • Linux Basis
    • 基本命令操作
    • Linux FHS（Filesystem Hierarchy Standard 文件系统层次结构标准）
    • Linux 系统（差异、历史、标准、发展）
  • 脚本
    • Bash / Python
  • 基础服务
    • DHCP / NTP / DNS / SSH / iptables / LDAP / CMDB
  • 自动化工具
    • Fabric / Saltstack / Chef / Ansible
  • 基础监控工具
    • Zabbix / Nagios / Cacti
  • 虚拟化
    • KVM 管理 / XEN 管理 / vSphere 管理 / Docker
    • 容器编排 / Mesos / Kubernetes
  • 服务
    • Nginx / F5 / HAProxy / LVS 负载均衡
    • 常见中间件 Operate（启动、关闭、重启、扩容）
• Dev
  • 语言
    • Python
    • Go（可选）
    • Java（了解部署）
  • 流程和理论
    • Application Life Cycle
    • 12 Factor
    • 微服务概念、部署、生命周期
    • CI 持续集成 / Jenkins / Pipeline / Git Repo Web Hook
    • CD 持续发布系统
  • 基础设施
    • Git Repo / Gitlab / Github
    • Logstash / Flume 日志收集
    • 配置文件管理（应用、中间件等）
    • Nexus / JFrog / Pypi 包依赖管理
    • 面向 开发 / QA 开发环境管理系统
    • 线上权限分配系统
    • 监控报警系统
    • 基于 Fabric / Saltstack / Chef / Ansible 自动化工具开发

SRE：

• 语言和工程实现
  • 深入理解开发语言（假设是 Java）
    • 业务部门使用开发框架
    • 并发、多线程和锁
    • 资源模型理解：网络、内存、CPU
    • 故障处理能力（分析瓶颈、熟悉相关工具、还原现场、提供方案）
  • 常见业务设计方案和陷阱（比如 Business Modeling，N+1、远程调用、不合理 DB 结构）
  • MySQL / Mongo OLTP 类型查询优化
  • 多种并发模型，以及相关 Scalable 设计
• 问题定位工具
  • 容量管理
  • Tracing 链路追踪
  • Metrics 度量工具
  • Logging 日志系统
• 运维架构能力
  • Linux 精通，理解 Linux 负载模型，资源模型
  • 熟悉常规中间件（MySQL Nginx Redis Mongo ZooKeeper 等），能够调优
  • Linux 网络调优，网络 IO 模型以及在语言里面实现
  • 资源编排系统（Mesos / Kubernetes）
• 理论
  • 容量规划方案
  • 熟悉分布式理论（Paxos / Raft / BigTable / MapReduce / Spanner 等），能够为场景决策合适方案
  • 性能模型（比如 Pxx 理解、Metrics、Dapper）
  • 资源模型（比如 Queuing Theory、负载方案、雪崩问题）
  • 资源编排系统（Mesos / Kurbernetes）

Ref

• DevOps - 维基百科，自由的百科全书
• Site reliability engineering - Wikipedia
• StuQ 技能图谱
• The Twelve-Factor App （简体中文）
• Google - Site Reliability Engineering
• What’s the Difference Between DevOps and SRE? - YouTube

（图片来自 The Dead Sea, Israel | One of the lowest, saltiest and unusu… | Flickr）

最近听团队老大的一个分享，介绍公司提倡的工程师的核心价值观，受益良多。 这也让我想起了一篇文章， Bruce F. Webster 在 2008 年写了一篇文章「The Wetware Crisis: the Dead Sea effect」， 翻译过来是「死海效应」。

Bruce 在文章中阐述了一个概念：一个团队可能陷入一种反模式，称之为死海效应。 死海是位于约旦的一个高盐分水域，由于水分被蒸发，这里的盐度是正常海水的 8 倍。 将水分比喻为高质量人才，盐分比喻为低质量人才。 水分容易被蒸发，而补入不足，盐分不容易蒸发日积月累，进而导致整个团队的人才质量劣化。

借用经济学里面的一个概念：劣币驱逐良币。

形成

为什么会形成这样的状况呢？

在一个正常运作的团队中，整个人才系统应该是循环的。有新的成员加入，也有老的成员离开。 只要市场上人才质量不发生剧烈的波动，团队内人才质量应该是平稳的。 但死海效应中不这样，好的人才不断流失，低质量人才被留存，这个团队素质越来越差。 形成这种状况的原因其实挺简单：环境恶化，高质量人才有更强的实力，可以自由地选择满足自己期望的团队。 而低质量人才没有更多选择空间，从而只能在当前的环境下继续生存。

死海效应导致的恶劣后果是显而易见的。 现代组织中人是生产第一要素。 如果人才质量持续降低，那么整个团队会缺乏战斗力，商业上得不到发展，这个团队将面临瓦解的风险。

什么样的团队容易滋生死海效应，我总结了几个点：无压、不透明、人情。

第一个点是无压，当一个公司的业务发展进入瓶颈期，战略上面没有远见， 抑或是已经占据了市场中的有利地形，温饱不愁，那么就容易失去压力。 我对商业的理解有限，就拿技术团队来做比喻： 当一个技术团队给业务提供的支撑足够并且业务发展平稳， 那么技术团队有两个选择：维持平稳的状态；给自己提出更高的技术要求。 前者是舒适的，后者长期带来回报，但是短期辛苦并且有风险。 前者的团队空间有限，挑战难度低，更容易产生死海效应。

第二个滋生死海效应的点是不透明。这种不透明体现在多个方面： 战略上是否向全体员工透明？业绩结果是否向全体员工透明？团队和个人绩效结果是否透明？评价标准是否透明？ 不透明会会导致团队的不公平。 一线员工看不到未来发展的方向和业绩，无法感受到个体被组织所尊重。 也许有些人尸位素餐，却能获得高收益，自然无法让团队的高贡献者认可。 Google 有一系列方法，包括 OKR 透明化，TGIF（Thank God It’s Friday） 全体沟通会，有效的解决这个问题。

第三个点是人情。大家在一起工作，时间一长或多或少会产生羁绊。 中国社会又特别讲究人情来往，今天你帮我一些忙，那我就得记在心上，未来有机会要还给你。 这当然是一种人和人之间沟通的一种黏合剂和缓冲，但是也是职业化程度低的表现。 企业的存在是有使命和目的，营造一种大家庭的氛围一定不在其使命中。 小团队早期可以家族化管理，但是一旦走上正轨，一定要规范化管理。 人情其实是对标准和制度的破坏，而企业的正常运转，恰恰最是需要对标准和制度的遵守。 讲究人情，也会对职责和评价产生破坏，这又会导致不公平，死海效应也会应运而生。 这点我是非常佩服阿里，它有一个出名的职务轮换制度，管理层不能长期担任同一职位，需要定期轮换。 这样就能保证关键人才在企业内部是流动的，不会锁定在特定岗位。 也就避免了长期锁定带来的人情账户、内部小团体。

如何逃离

那么如何来解决「死海效应」呢？有这么些方法：追求卓越、制度和透明、人才标准和流动。

我以前和一个候选人沟通，他的一句话让我印象深刻：公司业务高速发展时，就不会存在复杂的管理问题。 这是一种理想情况。 但业务发展需要时间，进入瓶颈期之后，想继续保持团队活力，改怎么办？追求卓越。 效率能否再提高一些？自动化的程度是否能够再提高？能不能向一流团队 FLAG 看齐？ 这样就开阔了团队和个人的发展空间。 一旦有了追求卓越的信念，即便业务发展稍缓，仍然能够抵御死海效应。

高质量人才离开往往是觉得受了委屈才离开，那么公平的制度和透明的实施就尤其重要。 保证不由某个个体的意志力转移，而是像机器一样可以运转，像数学一样可以被计算。 这个需要自上而下的贯彻，否则实施起来非常困难。 举一个例子，如果团队大部分成员会在月末调整绩效目标而获得更高的评分。 那么坚持不调整的人可能获得较低评分，这不是个体能够影响的局面。 没有自上而下的推动，制度和透明就只能是一阵清风。

最后是人才标准和流动。人才流动并非是一个坏事，如同人的生理循环，吸收有益物质，排除有害物质。 这个循环必须正向运行，设定合理的准入标准和淘汰标准，高质量输入，低质量淘汰。 末尾淘汰制听起来残酷，其实在广泛实施，比如阿里的 3.25 的考核，腾讯的年末淘汰一人。 对于大部分非家族公司来说，如果真的出现害群之马，难道不淘汰么？ 淘汰应该制度化，让所有人看到并且重视，而不是担心会造成集体不安就隐性操作， 这反而更容易产生猜测和担忧。

最后

一旦进入死海效应的恶性循环，我认为乱世用重典为佳，小打小闹不能形成大影响。 关键时刻就必须搞运动，做动员，大张旗鼓。 当然这需要高层有足够的决心和意志力。如果管理层计划偏安一隅，没有宏伟愿景， 那么十几年的企业寿命也能为股东赚回足够的钱，死海效应是存在即合理的现象。 低质量的人才管理成本也低，人才死海效应和业务劣化恶性循环， 最后进入企业衰老期，天道轮回，有生必有死，看开就好。