2026-09-12 00:00:00
最近我开始自己做一个基础设施项目的前端。AI 很快就能把页面搭出来，增删改查、筛选、状态标签一项不少，第一眼甚至挺像那么回事。
真正用起来，别扭的地方就出来了：页面里的信息很多，却不知道先看什么；关联资源、上下文和状态散在各处；下一步该做什么，也得靠人自己在一堆字段里拼出来。
组件其实没有选错。问题在于，我一开始只把它当成 CRUD 页面来做：先列字段，再补筛选和操作，最后才发现用户还是不知道该从哪里开始。数据是齐的，页面却没有帮用户排出理解和行动的顺序。
后来我把自己会做的判断整理成了一份页面组织指南。表格、看板、日历这些组织信息的基本方式，我在指南里统称为“表达骨架”。
我的工作一直以后端为主。虽然我也对前端和其他技术感兴趣，平时会做一些尝试，但真正投入工作的，还是后端。最近团队的前端资源缩减，我开始亲自承担前端项目。
这次我没有打算从零设计一套组件规范，而是选择 Ant Design 加 Ant Design Pro 作为基础。原因很实际：企业后台里常见的表格、表单、布局、导航和描述信息，都有比较成熟的现成方案，页面外壳和组件行为也容易保持一致。基础问题交给组件库处理，我可以把时间花在信息怎么组织、用户先看什么上面。
这套规范并不会替页面做决定。它只是先把实现的起点固定下来，避免每个页面都重新讨论颜色、间距和组件样式。真正需要判断的，还是页面要围绕什么对象展开，以及用户准备拿这些信息做什么。
这件事让我重新碰到一个老问题：代码写出来，页面不一定就设计好了。用 AI 写前端时，这个差别尤其明显。它能补组件、样式和交互，却不知道用户来到页面后最该先理解什么、判断什么，下一步又要做什么。
我想把自己在这方面的一些方案和判断拎出来，让团队同学也能用。页面“看着不对”往往只是一个感觉，只有具体说出主信息没立住、关联信息散了、操作放错了位置，才有办法一起讨论，也才好交给 AI 修改。
这份页面组织指南就是其中一部分。它既是我自己写前端时的检查表，也希望成为团队把 AI 用到前端项目里时，共用的一套判断依据。
我看一个高密度页面，通常不会先去找组件。先把下面三个问题想清楚，后面的选择会容易很多。
mindmap
root((页面信息架构))
主信息[主信息]
用户首先看到什么(用户首先看到什么)
关联信息[关联信息]
资源(资源)
模型(模型)
上下文(上下文)
用户动作[用户动作]
判断(判断)
操作(操作)
下一步(下一步)
我先把这三个问题过一遍，至少能知道用户进来要做什么。等这件事清楚了，再回头看表格、看板还是日历，通常不会选得太偏。
目前的 demo 用 Ant Design 实现。判断本身和组件库无关，换到其他技术栈时，具体组件还得结合项目调整。
CRUD 很适合处理数据操作，列表和详情页也一直有用。只是它们主要回答“这条记录怎么增删改查”，不太回答用户进入页面后先看什么、需要什么反馈，以及要依据哪些信息做决定。
API 只负责把数据和操作交出来，页面还得把它们之间的关系摆清楚：用户先看什么，接着比较什么，最后在哪里操作。
GitHub Projects 的布局说明很适合拿来做对照。同一个项目条目，可以放进表格、看板，也可以放到时间线式的路线图里。数据没变，用户读它的方式变了。
如果拿一批待开发任务来对照这些布局，三种视图分别会把注意力带到不同的地方：
| 眼前要回答的问题 | 需要放在一起的信息 | 可选择的表达骨架 |
|---|---|---|
| 哪些任务优先处理，分别由谁负责？ | 优先级、负责人等字段 | 表格，按列对照和排序 |
| 哪些任务还在进行，哪些已经完成？ | 任务所处阶段 | 看板，按状态分组 |
| 几项工作安排在什么时间，是否重叠？ | 开始、结束日期和持续时间 | 路线图，在时间轴上观察 |
排下一轮工作时，我会把优先级和负责人放在固定的列里，排好序后逐行看分工。换成卡片，同一个字段的位置就没那么稳定，比较起来反而要来回找。表格在这里的价值很简单：让比较发生在固定的位置。
跟进进度时，我关心的是“还有哪些在处理中”。把任务按状态排成几列，先找到阶段，再看里面的条目，会更符合这个动作。如果还能直接拖动卡片推进状态，页面位置和操作也能接上。
安排交付时间时，只知道“进行中”就不够了。把开始和结束日期放到时间轴上，几项工作的区间是否重叠会立刻显出来。至于是不是真的排不开，还要回头看负责人和工作量。
后台页面不需要把三种视图都做一遍。页面主要服务一种任务，就先把这一种做好；只有确实有多种高频用法时，才值得增加视图。每多一种视图，筛选、状态和操作就多一份维护成本。
Notion 的数据库视图也是类似的例子。准备发布一批内容时，挑封面可以切到图库，检查发布日期可以切到日历。日历能让我看到日期分布，但它不会自动告诉我资源有没有冲突；要回答这个问题，还得有时间范围和资源占用这些信息。
我平时也会看一些产品怎么处理类似问题。GitHub 让我印象最深的是，它总是围绕一个核心对象展开，不急着把所有信息都塞进来。Twitter 更像是把同一个对象放到不同场景里处理。淘宝面对的数据量很大，但商品和交易动作一直很突出。豆瓣的数据类型很多，页面却各有自己的组织方式。它们的样式当然不能直接搬过来，但看这些页面时，我会留意用户眼前到底要做什么。
所以我现在会先把页面要解决的事说清楚：用户来到这里，究竟要看懂什么、比较什么，还是推进什么。这样比一上来想着“做一个现代化后台”更容易找到方向。
guide 的 2.2 里，这个选择过程被画成了一条完整路径：先看系统里有哪些对象和关系，再看用户要完成什么，接着判断信息本身是什么结构，最后才落到具体的表达方式。
flowchart TD
A[Confirm the user, trigger scenario, and success outcome] --> B{Does it need a standalone page?}
B -->|No independent address, permission, or ongoing task| B1[Fold into an existing page or task flow]
B -->|Needs sharing, recovery, wide space, or independent permissions| C[Determine the single primary task]
B1 --> C
C --> D{Primary task intent}
D -->|Find, locate| D1[Collection / hierarchy / space]
D -->|Understand, judge| D2[Single object / relationship / document]
D -->|Compare, analyze| D3[Collection / diff / metrics]
D -->|Advance, process| D4[Queue / process state / config rules]
D -->|Trace, collaborate| D5[Event sequence / discussion & collaboration]
D1 --> E[Choose one primary information model]
D2 --> E
D3 --> E
D4 --> E
D5 --> E
E --> F{Expression that directly answers the primary question}
F -->|Field-by-field comparison| F1[Table]
F -->|Identify and enter a resource| F2[List / resource catalog]
F -->|Image is the recognition anchor| F2B[Card grid]
F -->|Parent-child or path| F3[Tree / tree table]
F -->|Dependency or impact| F4[Adjacency list / relationship graph]
F -->|Object identity and current state| F5[Object summary / sectioned detail]
F -->|Stage and next step| F6[Steps / status workspace]
F -->|Stage flow, moving is the action| F6B[Kanban / swimlanes]
F -->|What already happened| F7[Timeline / activity feed / log]
F -->|Who said what and how it was answered| F7A[Discussion thread / review thread]
F -->|What changed, before vs after| F7B[Diff view]
F -->|Trend, distribution, or anomaly| F8[Metrics / chart / analytics drill-down]
F -->|Location, boundary, or spatial distribution| F8A[Map / spatial canvas]
F -->|When is it occupied, when does it conflict| F8B[Calendar / scheduling]
F -->|Policy and constraints| F9[Grouped form / rule table / matrix]
F -->|Continuous reading and section navigation| F10[Document body / table of contents]
F -->|What to work on next| F11[Queue / inbox]
F1 --> G{How to maintain task context?}
F2 --> G
F2B --> G
F3 --> G
F4 --> G
F5 --> G
F6 --> G
F6B --> G
F7 --> G
F7A --> G
F7B --> G
F8 --> G
F8A --> G
F8B --> G
F9 --> G
F10 --> G
F11 --> G
G -->|Repeatedly switching objects or evidence| G1[Master-detail split / workbench]
G -->|Supporting content is light and transient| G2[Expandable section / Drawer]
G -->|Content is shareable or needs wide space| G3[Standalone page]
G -->|Short confirmation or minimal input| G4[Modal / Popconfirm]
G1 --> H[Add the necessary supporting models to form the page type and skeleton]
G2 --> H
G3 --> H
G4 --> H
不能因为 API 返回了一个数组，就顺手做成表格；也不能因为路由里有一个 ID，就默认做成详情页。同一个对象，用户在查找时可能需要列表，处理时可能需要状态流转，协作时又可能需要讨论线程。
guide 里的完整分支图还会继续追问主任务和主问题。例如逐字段比较适合表格，图片是识别锚点时可以用卡片网格，阶段流转适合看板，关注时间占用和冲突才使用日历。记录有日期，只能说明数据里有日期，不能直接决定页面应该用哪种结构。
选完以后，我会再走一遍真实操作：用户最常比较的信息有没有放在一起，最常做的操作是不是就在旁边。如果还得反复打开详情，记住上一条记录再回来比较，结构和字段安排大概还得重看。
demo 把这些判断做成了几组可以直接打开的页面。看页面时，我主要会问：如果用户要认图、推进状态、安排时间，或者找出异常，哪些信息应该先出现？
demo 的代码在 alswl/guides 仓库的 fe-page-guide-antd-demo 目录里。它是一个可以直接运行的配套项目：用 Vite + React 18 + TypeScript 搭起来，页面基础能力由 Refine 承接，界面使用 Ant Design v5 和 Ant Design Pro 的 ProComponents。数据是内存里的 mock，19 种表达骨架各自对应一个路由，打开就能看到具体页面长什么样。
这些页面用的是同一套技术栈，所以对照时更容易看出差别来自信息怎么排，而不是组件库换了。
挑素材或模板时，用户通常先看缩略图，确认它是不是自己要找的东西。这个时候图片应该是主要入口。要是还要比较价格、规格等字段，表格可能更省事。
拿模板来说，我一般先认版式，再看名称。把预览缩成表格最左边的一张小图，识别时最重要的内容反而被压掉了。卡片能把预览放在显眼的位置，名称和其他字段围着它排。如果每次选择都要核对一堆参数，那就不能只靠大图。
看板最重要的是列的含义，以及卡片在列之间怎么移动。用户先看阶段分布，再决定下一步怎么推进。若只是按负责人筛选任务，列表已经够用，没必要硬做成看板。
“待处理、进行中、已完成”这种列名，位置本身就在表达进度。卡片里保留标题、负责人等识别信息就可以。列如果只是换了个名字的筛选条件，用户看起来会很累，操作也未必更快。
日历适合处理真正和时间占用有关的事情，比如排班、会议室预订。要是只是想知道审批先提交还是先通过，时间线就更直接。
预订会议室时，用户要马上知道某个时间段有没有被占用，开始和结束时间不能藏在详情页里。审批记录则不一样，重点是事件先后，按时间线排开即可。
仪表盘最容易做成一堆大小相同的卡片。真正该先看的，是指标之间的关系，以及用户从概览进入细节的顺序。
如果所有指标都用一样的卡片摆开，用户还是得自己猜哪些应该一起看。我会先按问题分组：哪些数字用来发现异常，哪些趋势用来解释变化，明细入口放在什么位置。信息多，不代表每一块都要抢注意力。
树适合那些“我得知道它属于哪里”的信息。组织架构、分类目录需要保留父子关系；如果用户经常跨层级查找，再配一个列表或搜索框。
用户沿目录往下找时，树能保留“我现在在哪一层”的感觉。已经知道名称、只想快速定位时，搜索更快。这两种入口可以同时存在，不用让用户为了找一个已知条目，把整棵树一层层展开。
状态墙先解决一个很现实的问题：异常到底在哪里。监控页面可以密，但不能让颜色、装饰和状态标识互相打架。
用户先找到需要关注的对象，再进去查原因。对象名称和状态要容易辨认，详细日志放到下一步就好。颜色确实方便扫视，但最好再配文字或其他标识，否则用户很难准确说出自己看到的是什么。
下面把其余页面也放在一起，想看细节时可以点击图片打开原图。
| 表达骨架 | 表达骨架 |
|---|---|
 分区详情 |
 二维对照表 |
 目录与发现 |
卡片网格 |
|
层级树 |
 关系列表 |
 分步向导 |
 追踪下钻 |
|
看板 |
状态墙 |
 事件时间线 |
 讨论线程 |
 连续文档 |
 并排比较 |
 地图与画布 |
日历排期 |
|
仪表盘 |
 主从工作台 |
 配置表单 |
这份指南可以直接放进项目仓库，作为 AI 检查前端页面时的参考。人先从业务出发，想清楚用户来这里要完成什么，再决定信息结构和表达骨架；AI 根据这些判断补方案、找不一致的地方，再把修改做出来。
可以把下面这段直接交给 Agent：
页面组织指南地址：
https://github.com/alswl/guides/blob/master/fe-page-guide-antd.md
先阅读页面组织指南，并检查当前项目的目录结构。根据项目已有的文档约定，把指南复制到合适的位置；如果没有更合适的目录，放在 docs/fe-page-guide-antd.md。复制完成后告诉我实际保存路径，不要只把远程 URL 当作参考。
检查当前项目的任务管理页面。这个页面主要用来比较任务优先级和负责人，同时需要查看任务所处阶段。
结合需求、页面源码和实际页面，给出信息架构和页面表达方式的检查结果与改造建议：列出主信息、关联信息、用户要完成的动作，说明当前表达骨架是否适合、具体问题在哪里、对应的指南依据是什么，以及建议采用什么页面结构。无法从现有资料确定的业务意图请指出来。
先把检查结果和改造方案发给我，等我确认后再完成页面改造。保留现有业务功能、权限和数据交互，沿用项目的组件库。修改后运行项目已有检查，并在页面中验证字段比较、状态切换等操作，给出修改前后的截图和仍需人工判断的问题。
页面和任务描述要换成自己的业务。AI 可以列出几种候选方案，但主骨架和信息顺序不能只看它的输出，业务出发点还得由人来定。
检查报告要落到具体位置。只说“信息层次不清晰”没有多少用处，最好说明哪些信息应该放在一起、现在分散在哪里、准备怎么改。这样才能看出 AI 是不是解决了真正的问题。
把指南放进仓库，只是给了 AI 一份依据。还要告诉它页面入口和主要任务。如果 AI 只能看到源码，就先做源码检查；等页面跑起来，再补截图和实际交互验证。
验收时，我还是会沿着真实任务走一遍：信息是不是更容易找到，下一步操作有没有变清楚，原来的筛选、权限和数据交互是否还正常。
指南与 demo 仓库里放了完整规则和示例。至于页面是否真的好用，还是得回到具体业务里试一遍。
2026-02-08 23:16:56
好是卓越的敌人。
吉姆·柯林斯，《从优秀到卓越》
年终总结拖到二月才动笔。想写的东西很多，落笔时又觉得这一年很难用几句话收束，像是被推着走到某个坎上，迈了一步。
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/ 。 今年争取再写一个关于目标管理的。
每次学习，都感受到德鲁克洞察本质的思考，常读常新。
要是人生像大梦一场，关关卡，困难重，到底该怎么办？ 书里写的是作者生病的经历。 现在大家活得越来越久，生病这事，自己或家人都很可能碰上， 这本书就像个真诚的朋友，把生病后的种种感受和经历，一点不藏地告诉我们。 作者生病后日子特别难熬，书里把这些痛苦都写出来了。 他一边和病魔斗争，一边在心里给自己打气， 这些描写很真实，让我们能感受到他的害怕、坚持和对活下去的渴望。 面对风暴的办法只有一个，穿过去。
富士山的壮丽美景都历历在目。 漫步在东京国立博物馆中，我曾隐隐觉得其历史底蕴稍显单薄， 部分瓷器藏品也显得简陋，直至幕府时代的展品出现，才让人眼前一亮，印象深刻。 而读完这本书我才明白，在大化改新之前，日本的开化程度确实较低， 这也解释了博物馆早期展品相对逊色的缘由。
「山川异域，风月同天」这句诗我们并不陌生，甚至有人说中日同文同种。 但事实上，日本的发展历程有着自己的曲折轨迹， 它历经无序、混乱、贫苦与自卑，也有过爆发式的变革。 如今，日本已然成为东亚文明的重要代表之一， 拥有独特的精神内核与国民性， 与中国既有文化传承上的关联，又走出了截然不同的发展道路。
我一开始有点轻视这本书，想着自己搞了这么久，工程和方法论应该都是耳熟能详。 但细看之后感觉挺高屋建瓴的，写得很简练精要， 有一些观念梳理比自己想要结构化很多。
有几个印象深刻和反直觉的点：
资本不是洪水猛兽，资本主义也不是洪水猛兽。 资本主义的终局最终会发生么？ 有没有可能进入一个多种资方互相平衡的状态。 政府也出台了反垄断法来避免资本无限扩张， 通过基本的人道主义保障来兜底最底层。 第三册写到资本逐利是根本的问题。 但逐利是一个组织存在的基本要素，人也是逐利的， 商业组织逐利有什么问题么？ 逐利是生命体的表现，是存在的体现，只要不成为社会的癌细胞就行。 金融危机一定是坏事么？ 是不是一个去泡沫、降温过程，那是不是只要是有序的反而是一件好事？ 总体来说，马克思描述了一种在无序、小政府、割据政权下面， 资本主义会走向一个什么最差的结果，以及最终会被社会主义替代。 资本主义是家养野兽，需要套上项圈，让政府进行管制， 不管这个政府是三权分立的还是中央政权。 我怀疑在可预见未来改良式资本主义一直存在， 靠政府治理、反垄断保持着平衡。
《论中国》这本书基本可以分成两个部分。
第一部分是清末到新中国建立的中国对外外交史。
第二部分就是基辛格自己参与的中美关系发展史。基辛格是一个很有意思的人，他既流露出一种看上去的亲华派，但骨子里还是国家利益至上。他是幸运的，和中国四代（甚至可能是五代）领导人都有近距离的接触，堪称近代历史活化石。
把历史的进程拉近视角，以一个外交官（事实上）的视角呈现出来，可以更有血有肉地反映时代的细节。
相关阅读推荐：B 站大象放映室的晚清最后 13 年，邓小平时代，他改变了中国。（似乎找不到一本有代表性的书来介绍毛泽东晚年的历史。）
2026 将继续探索发现世界，持续的亲子陪伴和家庭经营，并在 Infra + AI Infra 领域有更多输入输出。
临界不是终点，蓄势待发。
2025-08-24 10:04:24
本文阐述一套适用于工程应用开发项目的迭代管理实践，重点解决如何高效低成本推进项目的问题。该方案适用于小型团队协作，核心特征在于固定产研节奏、标准化交付物以及高频异步协作机制。
本文仅针对技术方案与实施路径明确的项目场景，不涉及工程决策或目标管理范畴。本文也更注重实操，注重立即可以上手实施，不会花太多篇幅去解释这套方案背后的思考和原因。
关于实用（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 ；遇到了具体工程难题的同学请咨询团队技术专家。
什么是项目的节奏，什么是好项目节奏？
项目节奏的本质在于建立可预期的周期化交付机制。相较于单纯设定最终截止期限（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。
| 阶段 | 输入 / 输出 | 备注 |
|---|---|---|
| 产品规划 | 产品项目 OKR | |
| 产品思路 | 需求清单 | 需求清单是一个非常特别的形式，是我个人发明的，正面对抗一句话需求。 |
| 产品需求 | 需求文档 | 我们产品经常不配置 PD，所以需要自己写需求文档。我们有两种文档格式：文字型 / 配图型 |
| 系统设计 | 系统设计 | 文字内容设计结构必须是明确的，大家应该使用相同的模式来进行文字创作。比如系统设计文档可以使用语雀自带的模板。 |
| 开发 | 自测报告 | 截图证明你可以。 |
| 测试 | 测试报告 | |
| 发布 | 发布计划 | |
| 上线 | Release Note | Release Note 做轻薄一些，尽量链接到产品功能使用文档。 |
| 日常使用 | 产品说明文档 | 多截图，常更新，跟随产品上线发布。 |
下面我会展示一些我实践的需求范例（可能来自不同的产品和迭代）。
这是我使用的需求清单范例：
| 功能描述 | Owner | 优先级 | 前端页面数 | 质量介入 |
| 用户 A 可以使用 功能 B 完成授权 | 狗哥 | 高 | 2 页 | 是 |
| 用户 B 可以使用 功能 C 查看报表 | 谢宝 | 高 | 2 页 | 否 |
| 用户 C 可以使用 功能 C 发布视频 | 落九 | 高 | 很少 | 是 |
需求文档模板：
需求标题：简洁明了地描述需求 用户角色：谁会使用这个功能 用户目标：用户想要达成什么 前置条件：使用该功能需要满足的条件 主要流程：详细描述用户如何使用该功能 替代流程：描述可能的例外情况 验收标准：如何判断需求已经被正确实现
一个需求文档范例（文字型）：
视频发布流程 MVP
用户角色：内容运营者 需求标题：用户上传视频并完成自动化发布流程 用户目标：
- 运营者通过标准化流程完成视频从上传到发布的完整生命周期管理。
- 关键步骤自动化处理（如转码、审核），减少人工操作，关键节点保留人工确认机制。
- 支持异常处理（如审核失败、转码错误），允许人工介入重试或跳过。
主要流程
- 创建视频发布任务
- 用户上传原始视频文件（支持主流格式：MP4/MOV/AVI）
- 填写基础元数据（标题、分类、标签、封面图）
- 自动化预处理
- 转码引擎：自动生成多分辨率版本（1080P/720P/480P）
- 内容审核：
- AI自动审核（敏感画面、违禁内容）
- 若AI审核通过 → 进入发布队列
- 若AI审核失败 → 暂停流程并通知人工复审
- 人工确认节点（流程暂停点）
- 人工复审：运营者在后台查看AI标注的违规片段，选择：
- 通过（继续流程）
- 驳回（需编辑视频后重新上传）
- 强制跳过（需填写跳过原因）
- 发布执行
- 自动推送至指定发布渠道（Web/APP/第三方平台）
- 生成可跟踪的发布ID（用于效果分析）
- 异常处理机制
- 转码失败：自动重试（≤3次）→ 仍失败则通知人工
- 发布中断：支持手动重试/跳过/终止任务
替代流程
- 转码模块不可用：允许上传预转码视频文件（需符合分辨率规范）
- AI审核服务宕机：切换为全人工审核模式（需在SOP中注明应急预案）
验收标准
- 全流程验证：
- 运营者从上传到发布成功耗时 ≤15分钟（不含人工审核等待）。
- 模拟审核失败场景，人工强制跳过步骤后流程可继续。
- 异常处理验证：
- 转码失败时，系统自动告警并允许手动替换文件。
- 发布中断后重试，视频状态可恢复至中断前节点。
- 文档交付：
- 提供《视频发布SOP手册》，含人工操作指引及故障处理方案（A负责维护）。
Discord 的 Change Log（Release Note）发布大纲，没有前端产品用那么多 emoji。
妙言 tw93/MiaoYan 的某个 Release 更新日志：
我建议可以使用基于 Git 仓库管理的 markdown 方案，比如 MkDocs 这类方案：
我推荐的范例是 NebulaGraph Operator 的文档范例，注意这仅仅是 NebulaGraph 的其中一个子产品，但是规模更小更适合起步。
关于交付物，特别是文档类型的交付物，虽然我列了这么多类型，但是我认为一定不要写多写复杂，提纲挈领，量少为宽。
不要陷入巴别塔。
在分布式协作场景下，需建立「异步为主、同步为辅」的沟通范式，重点解决信息孤岛、风险滞后及依赖阻塞三大痛点。有效的协作机制应包含三个核心要素：全局可视化任务管理、结构化风险预警及精准化依赖协调。
我讨厌开会，甚至从某种意义上我痛恨开会。我之前写过关于会议的暴论：
这个月代码写得太少了，会议时间占据了 1/3，这很可怕。
会议很低效，很低效，很低效。有些会缺少材料准备，问题不聚焦，主持人不控场，一拉一大把人，不少人又不好意思走就硬挂着。
如果我有权利，我甚至想禁止公司开会，全都回归到基于文档的异步交互模式。
还是多建设，少空谈，有明确主张，材料提前分发，开会不当聋哑人，非干系勇敢离开会议。让大家回到方案设计和代码上吧。
有效沟通需规避信息失真，核心在于建立风险透明机制与依赖协同体系。具体实施包含三个维度：全局可视化看板：实时呈现任务进度与风险状态；精准进度追踪：量化每个节点的完成度；异步协作平台：通过在线任务管理工具（如 Jira）实现全周期信息同步。
我们不需要开会了么？还要，但是只要两种：方案评审会与日会。
评审会的要点在于：
日常进度沟通模式，我推荐每日站会沟通，最少也得双日沟通（每周二、四）。每天都进行站会同步，每次 15m 搞定。一般一个项目成员在 7 人左右（披萨原理），每人一两分钟。
站会的主持人很重要，要引导参与人同步进度，同步风险，寻求帮助，帮助需要有明确的接收方。
核心准则：以文档异步协同为基础，将同步会议压缩至必要场景，最大化建设性工作时间。
下面是会议看板范例，根据迭代过滤，根据 Assginee 分组（其实也很普通，没什么特别的）：
每天迭代经理在日会上面就是拿着这个看板，先明确我们几号提测几号上线，再挨个成员自述进展如何，最后挨个问有没有上线风险。
没有万灵的项目管理机制，根据自己面临的问题进行实际调整。本文的命题对我（一个开发工程师）来说也是极具挑战。我在过去有多次因为项目无法交付问题失眠无法入睡。现在来看，其实大可不必，平常心来应对问题，对预期内问题建立预案，对计划外变更保持弹性。当团队已完成可行性范围内的最大努力，即应视作有效交付。项目管理的终极目标，是在资源约束下实现可持续的技术价值输出。
人月神话 (豆瓣) 软件工程项目管理的圣经，20 年后读起来仍然觉得字字珠玑。
项目管理修炼之道 (豆瓣) 这是我的项目管理入门指导书，更通用更适合 PM。我写过一个读书笔记 《项目管理修炼之道》笔记 | Log4D。
代码之殇 (豆瓣) 作者是微软高级架构师/管理者，而本书实际上是一个随笔式的文章集合。尽管如此，书中的许多观点犀利且具有独特的见解，展现了从一线到高层的全方位视野。其中关于工程过程管理（比如死亡行军）事项，确实值得深思。
2025-06-24 07:14:49
读一本好书，就是和许多高尚的人谈话 - 歌德
第一次听闻李飞飞的名字，是在 2013 年与前公司 CTO 的中午干饭闲谈中。 彼时他正深耕 CUDA 并行计算领域，反复提及 ImageNet 竞赛与 AlexNet 的突破性表现， 而我对这场即将席卷全球的深度学习革命尚处懵懂——当时全身心投入业务系统优化， 面对「算法黑箱」既无暇探究，更难预见其对技术世界的重构力量。
如今读到李飞飞自传，方觉这场对话暗藏玄机：那个曾被视作实验室小众技术的计算机视觉项目， 竟成为改写 AI 发展轨迹的关键节点。在学科交叉处开疆拓土的战略眼光，在技术拐点期破除质疑的前瞻判断， 以及贯穿始终的"北极星"式价值锚点——这些要素如何在特定历史坐标中交汇， 最终塑造李飞飞成为改变机器认知方式的科学家。
李飞飞的成就源于多重维度的深度交织。其科研旅程始于对世界本质的探索欲。父亲带她 观鸟、捕捉昆虫的经历，在她心中种下好奇的种子，而母亲引导的跨学科阅读（涵盖海洋 生物、机器人、神话等）则拓宽了她的认知边界。中学时期她对航空航天等冷门领域的痴 迷，更展现出对抗性别偏见的独立思考能力。这种探索精神在普林斯顿大学攻读物理学时 得到深化，她将物理视为「西方科学最高深的创造性学科」，以此锤炼逻辑思维。这种对 知识本质的追求，成为她转向人工智能研究的底层动力。
逆境中的韧性塑造了她的核心竞争力。移民美国初期，语言障碍与经济压力如影随形。她 通过多重兼职（中餐馆打杂、家庭保洁、干洗店经营）维持生计，却仍以 SAT 数学满分的 成绩进入普林斯顿。更艰难的是母亲重病期间，她在手术室旁穿着隔离服完成学业，同时 充当医患翻译，展现出极限压力下的抗压与时间管理能力。外界质疑（如教师贬低女性数 理能力）反而强化了她「超越现实障碍」的信念。
顶尖平台的阶梯式跃迁为研究提供了关键支撑。普林斯顿时期奠定其学术基础，并促使她 转向计算机科学。加州理工学院攻读博士期间，她选择当时冷门的计算机视觉方向，在神 经科学与 AI 的交叉研究中确立「让机器理解人类视觉世界」的核心命题。斯坦福大学时 期，她创立人工智能实验室（SAIL），将 ImageNet 从构想变为现实。后续在谷歌的产业 实践，则加速了技术落地与应用转化。
把握技术拐点的决断力最终引爆突破。2006 年 AI 寒冬期，创建海量数据集被视为「学术 自杀」。面对终身教职可能受阻的警告，她创新采用亚马逊众包模式，发动全球数万人协 作标注，解决人工需耗时百年的难题。2012 年 ImageNet 竞赛中，GPU 算力支撑的 AlexNet 以压倒性优势胜出，验证了数据驱动路线的正确性，直接推动深度学习革命。
李飞飞独特的 AI 哲学观始终指引其技术路径。她批判当时学界对算法的过度专注，提出 计算机视觉的瓶颈在于缺乏「视觉常识」。ImageNet 的构建（1500 万图像/2.2 万类别） 本质是为机器建立认知世界的「视觉图谱」，其初衷是赋予 AI 感知现实的能力，而非单 纯追求技术指标。这种将人文认知融入技术设计的理念，后来成为斯坦福「以人为本人工 智能研究院」（HAI）的核心理念。
李飞飞的成长轨迹为家庭教育提供了深刻启示：她的父母并非教育专家，却以最朴素的方 式践行了「守护好奇心」与「培养独立人格」的核心理念。
关注孩子对自然世界的探索。父亲是李飞飞科学启蒙的「引路人」。他带着女儿在成 都街头观鸟、捕捉竹节虫、观察水牛，将自然视为开放的实验室。这种实践教育不仅培养 了她对生命现象的敏锐观察力，更塑造了「提问—探索—验证」的科学思维雏形。当同龄人 被规训于课本知识时，李飞飞已通过昆虫的复眼结构理解光学原理，从鸟类迁徙模式感知 生态系统的复杂性。这种源于真实世界的认知体验，远比抽象概念更深刻地影响了她日后 选择计算机视觉作为研究方向的决策。
母亲则是李飞飞精神世界的「守护者」。面对中学教师对其阅读《不能承受的生命之轻》 等「非主流书籍」的质疑，母亲断然反驳：「我的努力只是为了成为更好的自己」，并以 此教导女儿不必迎合外部标准。这种教育哲学解构了传统权威的绝对性——当老师公开 贬低女生数理能力时，母亲的态度成为李飞飞对抗偏见的心理支柱：「他们无法阻止我在 这里上场参赛，我暗下决心，一定要赢」。更关键的是，父母始终以行动传递价值观：在 移民美国后陷入经济困境时，他们拒绝向现实妥协，反而将生存压力转化为家庭凝聚力， 让李飞飞在干洗店账本间隙研读学术期刊成为可能。
回归到教育的本质 - 培育「反叛的底气」。20 后是 AI Native 小孩，需要去成功 AI Master 而不是 AI Slave，不要去被 AI 替代而要不 AI 赋能，很大的一个要点是要有 独立思考能力，有思辨、批判精神，从而去指挥 AI。李飞飞父母的教育智慧，在于将 探索精神与批判性思维内化为孩子的生存本能。他们既不刻意塑造「完美人设」，也不焦 虑于短期得失，而是通过持续支持孩子的兴趣选择（如允许剪短发、痴迷航空航天设 计），让独立人格在真实生活场景中自然生长。这种教育模式的当代启示在于：真正的素 质教育不是资源堆砌，而是父母能否在物质匮乏时仍坚持精神富养，在世俗标准前守护孩 子的独特性。正如李飞飞在 ImageNet 项目受质疑时所展现的韧性，其根源正是童年期形 成的「质疑—坚持—突破」的行为模式。
李飞飞在自传中反复提及指引她前行的「北极星」—— 一种超越短期利益与外界评价的内在驱动力。对她而言， 这颗星是对知识本质的追问与对人文价值的坚守的融合。 从成都街头的观鸟少年到斯坦福实验室的领航者，她始终以「探索未知」与「服务人类」 为双轴校准方向：在华尔街高薪诱惑前，她选择回归科学本心；在算法主导的 AI 浪潮中， 她坚持构建让机器理解现实世界的视觉常识库；当技术突破引发伦理争议时， 她强调「AI 的胜利必须是人文的胜利」。这种贯穿始终的清醒， 源于父母传递的价值观——母亲病榻上的灵 魂拷问「人工智能还能如何帮助他人」，最终化作她推动医疗环境智能研究的持久动力。
真正的北极星，从来不是某个具体目标，而是驱动人穿越迷雾的底层信念： 对李飞飞而言，那是永远追问「为什么」的好奇心，与永远不忘「为了谁」的责任感。
2025-01-11 13:52:48
地球不停息绕太阳一周，时光交替中，我们与生活擦肩，带着过去的记忆，迎接未来的未知。
去年，我给自己设立了一个关于生活的目标：家庭和陪伴。其中，一项是「高质量陪伴」，而另一项则是“学会摄影糖水片”。每次出行时，我希望通过照片记录下光与影的交织，捕捉那一瞬间的温度。今年，这个部分的主题便是 - Show me your photos。
2024 新年伊始，海边的灯塔。
春寒料峭，拎着一个喜气的龙灯出来转转。
从烟火气潮汕到宗教多元的泉州。
京都清水寺，小朋友许了一个有禅意的愿：我希望佛天天开心。
丽水，浙南梯田
壶口瀑布，红旗招展，黄河怒吼。
迪士尼，年末的花火。
草原上的加特林烟花。
去年，我从一名探索者转变为有组织推进系统演进的人。在年初的时候，我甚至隐隐觉得大厦的框架已经显现，接下来就是持续建设，让飞轮稳步前进，甚至开始规划探索 AIGC 上的一些新方向，想要在这个领域找到新的突破。
然而，现实很快给了我一个巨大的逼兜。随着 AIGC 急速发展，见证历史的同时，也面临着算力需求的剧烈增长。一波又一波的压力压下来，新需求和旧债交织在一起，给基础设施交付带来了巨大的挑战。这期间几位在这个领域的核心同僚几个月内相继离开。人走了，工作还得继续做。从 6 月份开始，我便与一群兄弟们直接走上了战场。
我甚至感到自己一度快要被压垮了，写了一系列关于「死亡行军」的故事。
痛苦总是让人深思，尤其在那些看似无法承受的时刻，它反而带来了更多的洞察。一切接近触底时反而能迎来反弹的力量。有一个瞬间我终于明白，问题是阶段性的，真正在持久修炼的是正面看待问题和以清明的心态面对困难的内心力量。
无需惧怕外界的评价，也不必厌倦合作中的复杂性，现状和问题本就存在于那里，解决的方案并非高深莫测，关键在于直面问题本身。保持平和的心态和现实的预期，便能在混乱中看到问题的根源，在困难中捕捉到机遇，在当下洞察到未来的可能。真正的力量，是从每一次挑战中提取智慧，从每一个困境中找到前行的勇气。
摄于苏州美人腿附近
今年被工作挤占了几乎所有的时间，也导致业务已经没有精力产出内容。只有两个很小的产品。
dbml-editor ，一个免费的 DBML 在线编辑器。
random-apple-music 是一个播放列表，随机挑选 Top250 的豆瓣音乐专辑，并且可以一键跳转到 Apple Music 播放。
今年在 X（Twitter）上面的最受欢迎的内容是：
今年，买了 Boox 文石之后，读书量一下子就上来了。总共读了 34 本书，大多数是非虚构类书籍，其中有 10 本我给了 5 星评价。Kindle 离开中国，只能拥抱微信读书。虽然无法拥有实体书，但读书成本大大降低，每月上传两本书，已经足够了。更有意思的是。我也逐渐改变了对听书的看法，曾经对它嗤之以鼻，但现在，我发现做家务或者在路上听书，成了提高大脑利用率的好方式。
太牛了，原来演员的词几乎不用改就能直接用。
妙趣横生。
华为的经营哲学与阿里巴巴的"六脉神剑"在客户至上和目标导向上有共通之处。尽管理念相似，但华为的手册缺乏案例支撑，而企业文化往往是在解决实际冲突中塑造的。书中强调的几个关键点，如明确方向、专业精神、执行力和自我批评，对企业成长至关重要。华为从网络设备市场起步，现已成为多元化的科技巨头，其硬件基因可能助其稳健发展。相比之下，阿里巴巴等互联网公司近年来在资本市场的表现略显逊色。
很推荐，讲述了宇宙的起源，生命的诞生和演进。让我想起了小时候看的一部纪录片，宇宙与人。如果有时间的话，我想仔细研究里面的术语，囊括了宏观物理、微观物理、化学、生物。
武林泰斗亲自下场，给新人们介绍秘笈心法。之前读论文比较枯燥，一些知识和细节理解不连贯，借本文可以梳理脉络。 关于 Transformer 注意力机制介绍的比较少，好在热心的读者评论里面提供了更多信息。
这是一本相当不错的深度学习入门书。不同于 How to use，本书着重 How to build，书中通过 Python 实现了一套简单的框架，并将这个框架应用在手写识别上。文章深入浅出非常详细的介绍每一层网络解决什么问题，相关的数学公式和原理是什么。 虽然已经出版了接近五年，但是书中内容并没有过期，甚至在最后面的展望描述的场景，包括物体识别，RNN（GPT 基础）在当下异常火热。
本书像是提供精神 massage，片刻愉悦之后还是得落到知行二字。 有时候精神困顿，也需要按摩解乏。比如读到情绪管理这章，就回忆起上周工作冲突失控愤怒上头怼人时刻。我并非不知道要点，也许早一点读到纳瓦尔这一章我就可以唤醒理性，好书还是需要常读常新。 财富和判断力这两章给我的输入和触动最大：做高杠杆效应事情，积累财富；使用稳定可靠心智模型，学习数学，特别是概率和统计。
作为政治家，有意愿有行动力，思想有深度视野开阔不受框架束缚已经是一流。 难能可贵是李光耀还如此坦诚。我想应该是和新加坡人口规模和民众素质有关系。 这本书是书友评论密度很高的一本书，靠书友补充了很多视角（以及后来发生的事情）。
这本书是一本神作，作者用相当大的尺度在讨论从建国到现在政治路线和经济路线的纷争。作为党史研究员，作者不避讳描述毛泽东，让我看到一位急迫地想一把到位共产主义，并且留下一个无阶级矛盾的国家，为此不断发起运动、斗争。好在邓公拨乱反正改革开放。 感慨，看过去一代人的牺牲，一个数字代表一个家庭的破碎。希望未来少一些宏大叙事，多一些关注日常民生。
从无人知晓过来。 文字之间跳跃着一股真诚质朴，数次为其感动眼眶湿润。被陈行甲正直、热情、生命活力感动。 有人质疑这是表演，我倒更愿意相信其诚朴，相信愿意相信的，坚持自己坚持的。
不败者，一本让我挺惊喜的国内科幻小说集。 墨熊的风格有一种深入宇宙边界的探索力，截取了一小段太空歌剧的碎片展现出来，将遥远星际故事拉到读者身边。 《信鸽》有种软硬结合的科幻感，被光速约束的理性和感性的理念交付。 《白鬼篇》有点爽文既视感。 《不可战胜者》让我想起了神秘博士里的哭泣天使，以一种跨越时间线方式进行绞杀。绞杀的方式和破解的方式都精巧且出乎意料。
期望新的一年可以热烈又恬静，深刻又朴素。
2024-01-08 23:38:59
时间已做了选择，太多感受，绝非三言两语能形容
这是第 35 个年头，我熟悉地扮演着多个角色，父亲、丈夫、儿子，每一刻都在陪伴和成长中交织。 生活的步伐似乎匆匆，但我努力让自己拥有一颗年轻的心，渴望保持对世界的好奇和激情。
时光大多被生活所占据，只有地铁上和饭桌上我能成为时间主宰。 好在我并未感到疲惫或沉闷，反而逐渐适应了这个身份的变化。 或许，正是在这些琐碎的日常中，我找到了一种生活的节奏，一种平和而温馨的状态。
今年我们走过了北京、汉中、西安、淳安、长沙、张家界、台州。 新年即将到来，准备给孩子办理一下护照，走出去看看。
在陪伴孩子的过程中，参与各种自然知识课程，参观各种展览，我发现在陪伴的同时，我们也在不知不觉中共同成长。 生活中的另一个领域，我从母亲那里薅了两只相机，终于决心好好学习摄像， 我把 Canon 6D 出售，保留了 SONY a6500 这支轻便的 APS-C 相机。 期望摄影成为我表达内心、记录生活的一种方式，每一张照片都是时光的凝固，是岁月的见证。
游戏的世界中，我似乎进入了一段电子阳痿期。购买的游戏几乎只能玩上一个小时就变得索然无味， 也许现实生活才是最引人入胜的游戏吧。
或许，人生就是一场不断变化的冒险。在时间的舞台上，我们扮演着各色角色， 演绎着属于自己的故事。
工作上一直压力和张力巨大，我开始进一步成为探索者。 这两年，我在工作中不断推动项目的上线，部门推出的新产品中的一半是我负责的，我很喜欢这个领域，也确实想把事情做好。
但有时候，我感觉自己有点像是公司招进来的清理工，身处于一个「散多垂」的状态， 面对复杂的环境，解决问题绝非易事。在整理垃圾的过程中还在自动产生垃圾，而清理的工作永远不会终结。 现实往往是，大家注意力持续被新事物（比如 AIGC）吸引走，对现存的问题更容易选择性忽视。
企业的大环境在不断变化，一些老朋友选择离开，大部门也经历了一些变革。 从面向风险的团队 re-org 到面向算力的基础设施团队。我认为这是一个好的信号， AI Infra将继续裹挟着整个 Infra 领域前进，算力管理将成为一个新的命题。
在 Github 数据的细碎图形中，映射出一年的自娱自乐，可惜的是，未给开源社区更多的贡献。
今年，我在开源领域主要的贡献是 alswl/excalidraw-collaboration。 这个 self-host 的 Excalidraw 版本集协作和中文化字体于一身。这个项目以及相关项目吸引了近300个 star，成为我个人最有影响力的开源项目之一，尽管它是一个前端产品。
在暑假期间，趁着家中小神兽不在，我开发了一个关于起名的小程序。虽然这款产品目前有点烂尾， 亏损严重，但我依然希望花更多时间进行开发和改进。一个美好的名字可以给家庭带来无限愉悦， 希望这个项目可以养活服务器资源~
另外，今年我重新活跃在 Twitter 上，分享一些技巧和心得。我的 Follower 从几百人增长到近 4000 人， 虽然离有影响力的推友还有差距，但与许多有趣的朋友交流本身就是一种有趣的事情。
今年一年最受欢迎的内容是：
今年最具价值的文章是介绍「许世伟的架构课」X，赚了几个月 Twitter 的订阅费。
今年我还重新开始听播客，聆听了一大半「内核恐慌」的存档，虽然未能赶上他们活跃的时期。 幸运的是，在外滩大会上我有机会参与了他们的聚会，与 Rio 和吴涛面对面交流。搞笑的是，虽然现场还有一位同事， 但我们却没有互相认出来，令人感叹在庞大的公司中，有时即便共事也未必能够相识（我们一起担任 Go 语言评委）。
除了内核恐慌，我还一直在听「硬地骇客」，一集都没拉，最近还开始听「有知有行」的播客。
在博客输出方面，我分享了两篇关于工程实践心得的文章，希望能够对读者有所帮助。
我最想分享的是 Obsidian Tasks 插件，详细信息可以在我的博客文章中找到， 从 Toodledo 到 Obsidian Tasks - 我的 GTD 最佳实践。我也很高兴成为 Obsidian Tasks 的 Sponser。
回顾一年的时间，我意识到自己在业余时光中的每周时间仅有10小时左右，非常宝贵。 期许着未来能够实现财务自由，以获得更多的自由时间，投入更多的兴趣爱好。
读书仍然大部分都是非虚构类书籍。
士可杀亦可辱；过去带来惆怅，现在带来迷惘，未来带来希望。
讲述做人做事的道理，古人的智慧。常读常新，尤其烦躁时候可以翻出来静一下。
就是为了看 中文的常态与变态。
老男爵举家迁新球，贵公子初入沙漠星。 老皇帝密授哈克南，雷托族全体遭判断。 小保罗掌权弗雷曼，杰西卡诞下遗腹子。 穆阿迪布反攻沙丘，娶伊勒朗再封帝位。
国、企、民、央、地。 悲观。
好希望自己能在 20 岁时候读到这本书。（现在的我已经不需要啦）。教读者如何和自己、周边、世界相处，如何和自己对话以及改变自己。和遇见未知的自己属于同一个路数。
治乱循环在反复。群体的无意识；民主和精英政治是否是解药？评估稳定性一个指标是贫富差距。极权下也孕育变革风险。
管理入门快速操作手册
这本书我给不出星级，超出了我的评价范围。 它可能是一个新学科（因果推断）理论，也可能是统计学中的一个星火闪烁。 作者 Pearl 是统计学大拿，也是人工智能领域权威专家，他确在晚年提出了反对自己过去一系列方法路线。 今天为我们所熟知的大部分机器学习技术，都是基于概率上相关性，从啤酒和尿布，到今天 GPT 大杀四方，AIGC 智能涌现。Peral 认为真正有意义的是提出「为什么」，即解释因果关系。因果关系的论述需要智能能够想象不存在的事物，而这正是当前人工智能无法理解的（Maybe？） 本书成于 2019 年，作者今年已经 87 高龄，不知道他对当前 AIGC 风起云涌是怎么看待的。
作者说的正确但是不全面。
高质量陪伴家人，放下手机，走向户外
执行了周三、周五家庭日给小朋友陪伴；每天早上送小朋友上学；周末一定有一天陪出行。
陪伴小孩这块我做的不如我老婆好，感谢老婆对家庭的贡献。
每月输出文章，特别是 Kubernetes / 研发设计领域可以写一些心得
今年输出 6 篇文章，达标率 50%。其中两篇 实用 Web API 规范 和 架构设计 the Easy Way 我都是很满意的。
经历了新冠，今年计划安排个私教教我健身房运动
没有完成。
投资收益率能做到 10%，今年新手阶段投资以股票型基金为主，投资收益 3.9%，跑赢了大盘和余额宝
今年投资收益率 -1.35%，刚出新手村就被暴击，我还是缺乏对市场和商业的理解。
新的一年 Flag：
每段经历，每次重逢，每本书籍，都是独特的命运线。新的一年已经来临， 期待着与家人、朋友一同继续探寻生活的真谛，去体验伟大与渺小。
往年总结：
