2026-03-10 02:36:32
前往原站查看：https://innei.in/posts/programming/ai-era-refactoring-from-rfc-to-five-plans
2026-03-01 01:05:33
前往原站查看：https://innei.in/posts/experience/ai-era-efficiency-paradox-productivity-gains-cause-fatigue
2026-02-17 01:11:13
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://innei.in/notes/207
越来越没有年味了。
小时候，过年是一年中最盼望的日子。放寒假也意味着快要过年了。一般来说，前半个寒假都是在等待春节的到来。节前的那几天，家里人总会忙前忙后，从小年开始，就要开始大扫除，备年货了。
那个时候，我最期待的就是可以买烟花来放了，是那种长条形的，不是那种大户人家才放的起的，能在天上开花的烟花。那个时候，晚上总是很看到别人家在放烟花了，很是羡慕。那个时候那种大烟花并不便宜吧（现如今也不便宜，有色金属还是很贵的），而绚丽的画面只是一瞬。很多时间，都是花了大价钱只是为了这目睹、期待那一瞬，生活何尝又不是。
除夕那天，会花一个下午的时间备菜，做很多好吃的，一家人在一起吃饭，热热闹闹的。城里人都回村过年了吧，乡下每家每户都挺热闹的。我家在一个偏僻的地方，周围没有太多的人家，但是也能感觉到这种气氛。吃完饭，要放鞭炮了。噼里啪啦的，之后就到了收红包的环节了。还记得很小的时候，那个时候收到一个红包一张红票就很开心了，后来红包越收越大，再到现在，一点也没有当年的喜悦了。也是因为工作了，现在基本也都推辞了。
谁还记得以前的春晚是除夕夜必看的吗，那个时候没有现在的高科技，华丽的特效和舞台，也只有一个主会场，但是节目很好看，那时候还有赵本山出演的小品，很多节目也都很有新意，而现如今社会发展了，科技进步了，却越来越没有新意了。这一年一次的大型演出只是一个象征，不会再有更多的人关注了。
我已经不知道从何时起学会了熬夜。
曾经在春晚那天能够熬到凌晨，是一件非常不容易的事情。我至今还记得，有一次我曾经立下承诺要熬夜守岁，最后还是靠着咖啡才度过了那一晚。我很久已经没有再能体会到这种感觉了。现在，每天晚上睡觉到两三点已经是家常便饭，再也找不到当年那种怀着非常激动的心情、找不到那种少年的滋味了。
第二天的一早，也就是新年的第一天，大家伙儿都开始走亲访友，显得格外的热闹。在那个时候，不管是城里还是乡下，都还没有颁布烟花禁令。尤其是农村，每天从很早开始，就会被一阵阵炮竹声惊醒。热热闹闹地走向各家亲戚，也许一年也就这样一次机会，大伙儿在一起探讨着各种各样的话题。从小到大，我都觉得我的亲戚太少了。别家的孩子从大年初一到初八，串门串个不停；而我也就串个两三家就再也没有了。过年期间的大多数时候，我都在看着别人家里热热闹闹的，而自己这里空虚得很。看着别人家的孩子到处串门，收着更多的红包，而我却显得很可怜。现在回想起来，当时有这样的想法，也是觉得挺天真呐。
现在年味越来越淡了，大家伙也不再热衷于串门走亲戚。那个时候大家的生活收入虽然都没有现在好，但是人情味可比现在浓。现在大多数人只是走个形式、意思意思，大家都各自忙各自的去了。去旅游啊，也比这样好。
过了除夕，时间就会过得非常快了。
小时候，过了除夕相当于寒假就过了一半，要不了多久又要回学校上课了。而现在，过了除夕也就意味着快要和家人分开了，大家各自回到各自的岗位，可能很久才能再见一次了。那么现在这段时间又意味着什么呢？
我感觉啊，只不过还是普普通通、平凡的假期那几天吧。我和往常一样，今天是除夕，我写了一天的代码，就和平常没什么两样。
最后还是祝大家新年快乐。今天已经是年初一了，祝大家马年码到成功！
2026-01-26 01:27:40
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://innei.in/notes/206
新年的第一个月也快结束了，我想也是时候再来梳理一下最近这个月发生的事情了。
其实我是一个非常没有安全感的人。我发现我之前所有写过的生活类文章中，可能最离不开的两个字就是“工作”。这一方面是不确定性带来的焦虑感。
也是因为这样，在上份工作被裁之后，我基本无缝衔接了现在的工作。目前我已经快入职两个月了，相信关注过我的人应该知道我去了哪里。在这两个月的时间里，我正好赶上公司的项目处于新版本的冲刺阶段，所以这段时间非常忙。
在此期间，我也做了很多优化工作。前段日子我还专门写了一篇文章，总结了一些关于性能优化的要点。我觉得后面还是要生活和工作平衡一些吧。虽然说远程工作的话确实会比较难，也是最近发生了一些事情吧，让我对这个想法有了更深刻的思考。
年初的时候看了一部电影，名字叫《不过是上班》。
虽然这是一部喜剧片吧，其实喜剧的背后也更多都是悲观。艺术来源于生活，而生活往往比电影表现得更加残酷。当时看完之后，写下了这样一段话：
看了这部电影只能说我一个打工人感触还是挺深的吧。 只是影片中很多也是反映了当代职场以及社会的一些矛盾吧，某些公司喜欢找那些急需用钱家庭困难的员工，因为他们更容易被使唤也不敢辞职，男二也是这样，他兢兢业业每天加班，业绩提升的越快 KPI 涨得也越快，最后加班猝死了。但是即便是这样公司，会想办法处理伪造他的死亡说是酒精中毒，但其实只是过度劳累，最后只配得人道补偿¥50,000。我也经历过裁员，我也知道公司总是站在自己有利的一面，而我们和他们斗争太难了，我们的力量太小了，而公司很轻易的就能抹掉你曾经努力奋斗所付出的一切。 最后有句话其实挺升华的，不过是上班，希望我们都能找回自己的生活。
https://www.themoviedb.org/movie/1555232
其实我也感同身受，因为前段日子发生了一些事情，再加上我上家公司的一些经历，感觉公司想要抹掉你留下的痕迹真的太容易了。
我们个人就像是公司的一次性用品，被扔掉是很简单的事情。不过好在，我上个公司做的项目是开源的，在大众视野内还能看到一点痕迹，情况没那么严重。
https://x.com/__oQuery/status/2012047221337047044?s=20
近期网络上又是刷屏广州 32 岁程序员猝死的消息。所以还是不要把工作当成全部吧。
工作是工作，生活是生活。说什么“能者多劳”，也不一定会有回报。毕竟公司又不是你的，还是要为自己保留一点余力吧。
疲劳加班和为了工作长期熬夜是最傻最没有意义的事情。没有人感谢你的付出，没有人记得你做的事儿，没有人会佩服你，没有人会记得你，最重要的是，你的工作也远没有你想象的那么有意义。早日参透，早日收获。
其实还有一点，就是我更喜欢去创业公司的原因：我觉得在创业公司更加有归属感。
而且在那里做的东西也是我比较喜欢的，很有成就感。同时这些产品我可能自己也会去用，所以我真心希望它能变得更好。当然，我也不希望最后的结局是这样的。
话题扯远了，我们来说一下最近在写的东西。
这个月我开了一个 Claude Code。自从上一次被封号以来，我差不多有快半年没有使用它了。这一次用回来，新鲜感还是很强的。确实，它和以前相比能力提升了不少，现在开发的效率越来越高了，当然这也是基于在它的基础上。
现在大概用了半个多月吧，目前已经刷了 2.1B 的 token。
├──────────┼──────────────────────────────────────────────────────────────────────────────────────┼───────────┼──────────┼─────────────┼──────────────┼──────────────┼───────────┤
│ Total │ │ 33,368,8… │ 2,701,6… │ 81,526,248 │ 1,967,393,0… │ 2,084,989,8… │ $1180.61 │
└──────────┴──────────────────────────────────────────────────────────────────────────────────────┴───────────┴──────────┴─────────────┴──────────────┴──────────────┴───────────┘
最近这一个月以来，我也探索了很多 AI 工具。
现在的 AI 发展实在是太快了，我已经用过了：
谷歌 One 我也是买了一年，是之前有优惠的时候买的。
总体用下来的话，这些 IDE 其实都不如 Cursor，关于 Kiro 的话，它的 specs coding 能力一开始我觉得好像还挺完善的，但是用了几次之后，我也就不想再用了。总之现在编辑器的话，还是用 Cursor，别的话也很少用了。之前想花点时间把 mx-space 的 Admin 从 Vue 项目迁移到 React，基本上整个项目重启，工程量还是非常的大，所以现在还是搁置了。但最近换了一个思路：还是在现在的 Vue 项目上进行翻新，整体计划是把整个 UI 都重写了，然后把陈年技术栈都换掉了：
顺便终于把后端项目也经历一次大的重构，精简了一些模块，同时也终于把 CJS 迁移到 ESM 了，直接使用 tsdown 去 bundle 速度提升了不少，迁移到 ESM 之后，ESM pure 的依赖也不用预编译了。
https://github.com/mx-space/core/commit/9abe0711de82e78c3e25c7a0b7c77b4b65f8f16a
然后是：
就这样差不多搞了一周的时间，基本上已经全部都搞完了。当然现在还有很多小的 Bug，后面再慢慢去修复。值得一提的是，本次对编辑器有了非常大的提升。我也是在基于 CodeMirror 的基础上，做了一个所见即所得的编辑器，类似 Typora。当然，我对写编辑器并不是很擅长，这个工程确实也非常庞大。全程的架构都是由 CodeX 帮我设计的。不得不说，CodeX 在这方面的能力真的是非常强。
再辅助 Opus 4.5 来帮我写 UI，虽然现在还有一些 bug 挺让人烦恼的，但整体用下来，体验已经好太多了。我是觉得现在 AI 的成熟，让很多以前不敢想的东西，现在都能变成现实了。
以前是自己写代码实现一个功能，而忙得停不下来；现在则是通过 AI 源源不断地实现以前那些可能无法实现的东西。至少那些自己原本无法实现的东西，现在正一件一件地落地，这种正反馈和以前写代码时带来的满足感是一样的，让人停不下来。
当然，这种正反馈也让更多原本不会编程的人，能够体会到我们之前写代码时的那种热情。
值得一提的是，我现在让 AI 帮我做事也变得更加简单了。因为我现在也很少去打字告诉 AI 怎么做，甚至这篇文章我也几乎没有打字。在前不久的网友面基中， yetone 推荐了 Typeless，这个软件确实是厉害。相比我之前用的“闪电说”以及其他的一些语音输入法，它们虽然速度快，但准确率却很低，经常需要自己去修正，甚至还不如自己打字。
但是用上了这个之后就完全不一样了：
当然这也是有代价的：这个软件的订阅费非常贵。
新用户可以免费使用一个月，一个月之后：
但这不妨碍你们去试用体验一下它的效果，然后再做出评价。我觉得还是一分价钱一分货，至少现在我很愿意为它付费。
https://x.com/__oQuery/status/2010404209267790104?s=20
上面这个贴文是我当时评测的4款语音输入法的横评，大家可以参考，当然更多的是你自己去体验。
发上我的推荐链接，有钱大家一起赚，你能拿到 5 刀。 https://typeless.com/refer?code=UM6K0UK
现在已经彻底改变我的编程工作流了。不得不说，用上语音输入法之后，我感觉我的效率又提高了不少。可以同时多开几个 session 去开启更多的项目、做更多的事、实现更多的想法。
在前不久，我买了一台 128G 的 Mac Studio，我觉得这是一个非常正确的决定。因为现在项目开得越多就越需要内存，而且现在内存涨价非常厉害，我觉得买这台 128G 版本的机器真是太赚了。我现在同时会开很多个项目，除了工作的项目之外，也开了一堆 Side Project，让 AI 去探索、快速试错。
我也比较认同 yetone 的观点。我也是去年的时候发现，我其实热爱的是 Building，只是说以前没有 AI 这个角色去帮我 Coding，所以我们只能自己去 Coding 来 Build 一些东西。
https://x.com/yetone/status/2014977294276968532
最近这一个月左右的时间，我基本没有再去社交了。
大约在半个月前，我通过短视频看到了关于“向上社交”这个话题。过去的这几年，我觉得他说的很有道理。我一直以来也都在进行所谓的“向上社交”，强行去挤进大佬的圈子，并尽量尝试去融入。所谓“向上社交”，指的就是不在一个 level 上的社交。更多的是你去找对方，而对方基本不会来找你。
想要维持这种关系，感觉很难而且也很累。所以我现在的现状是：尽量减少这种关系。
我在 LobeHub 上建立了一个心理咨询团队，也尝试询问了我遇到的困境，
https://app.lobehub.com/share/t/RmZwPMEK
还是因为自己的自卑和不自信，往往会把自己放在下位。
2026-01-13 23:34:08
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://innei.in/posts/tech/lobehub-performance-dx-optimization
LobeHub 是一个开源的 AI 聊天应用平台，专注于提供现代化的 AI 对话体验。它支持多种 AI 模型（如 OpenAI GPT、Claude 等），提供 Web 应用和桌面客户端（基于 Electron），并拥有活跃的开源社区。作为一款 React 技术栈构建的应用，LobeHub 在性能优化和开发体验方面面临着诸多挑战。
https://github.com/lobehub/lobehub
入职后的第一个月，我主要专注于项目性能优化和开发体验改进。回顾过往的工作经历，我发现每次加入新团队时，都会优先处理这类基础架构问题。这既是个人习惯，也是对项目长期健康的必要投资。
特别是在当前大语言模型普及的背景下，编程门槛大幅降低，“人人皆可写代码”的时代已经到来。
然而，AI 快速生成代码的能力也带来了新的挑战：代码质量的可控性下降，性能优化意识被削弱。以 React 开发为例，开发者往往过度追求性能指标，却忽视了代码质量和开发体验的平衡。作为 LobeHub 的早期用户，我深知其性能问题一直是社区关注的焦点，“很卡，特别卡”几乎是所有用户的共同印象。
因此，在本文中，我将系统性地总结过去一个月对 LobeHub 进行的性能优化工作，并通过具体数据展示优化前后的性能对比。
这个库是一个 CSS-in-JS 的 Flexbox 组件库。现在有了 Tailwind 的话，编写 Flexbox 布局也是能非常快写出来的。但由于 LobeHub 没有使用 Tailwind，所以就有了这样一个库，能够更快地编写 Flexbox 并设定其各种属性。由于是 Flexbox，所以在项目中大量使用。一个页面可能有几百个这样的组件，所以数量是非常庞大的。
通过火焰图的对比，其实单个组件的性能开销也还好，基本上在 0.1ms 左右。当然，如果是一个普通的 div 组件，这种开销通常小于 0.1ms。
但在组件使用非常多的情况下，0.1ms 的量级累积起来其实也会很大。当然，从性能上来说，其实感知的开销还好。但另外一个问题是：CSS-in-JS 这种方式，只要每个 Flexbox 的属性没有相同的地方，就会生成大量的 CSS。
由于它是 CSS-in-JS 的实现，生成的每一段 CSS 都会比较占用内存。特别是开发环境下。
下面那个测试链接也是我当时写的，主要是对比两种方案的性能、渲染时长和内存占用：
https://css-in-js-batch.vercel.app/
可以看到，虽然两者的开销差别并不是很大，但在内存占用方面，差距达到了大概十个量级左右。
当然，在生产环境下可能没有这么夸张，但依然会有明显的性能提升。
接下来这个问题，还是通过火焰图排查渲染的情况发现的。
在业务中，由于大量使用了动态生成的 CSS-in-JS 的 React Hook，产生了这个 Hook 的性能开销比较大的问题：
所以，如果一个页面上有几百个组件同时都在运行这个 Hook，那么这次 layout 基本上一定会花费大量时间来处理。
这个问题的发现，也是通过火焰图排查到有一些比较轻的组件，渲染却用了一毫秒。在开发环境下要花一毫秒左右的时间，就感到特别奇怪。
然后去排查是哪个 Hook 导致的，最后发现是一个 useStyle 的钩子。
找到问题之后，就比较好解决了，我们只要换一种方案就行。
在这里，我们提出了一种优化方案：不再使用动态生成 CSS-in-JS 的方案，而是使用静态方案。这样的话，性能上也会提升不少，毕竟在组件的运行时上不会再有额外的开销了。
https://github.com/lobehub/lobe-ui/pull/437
https://github.com/ant-design/antd-style/pull/205
上面这两个是比较重大的优化。这波优化全部完成之后，整个 APP 已经有了很明显的提升。
以前消息列表中的每个 Message Item 都需要花很长时间去渲染，而现在在开发环境的表现已经和之前在生产环境差不多了，在生产环境上则会更快。内存表现也是：现在可以保持在正常情况下 400-500 MB 的样子，甚至更低。
首屏的性能优化，主要做的是如何让用户从其他页面返回首屏时速度更快。
首屏的加载时间是非常影响用户体验的一个点。在 React 中，当一个页面切换到另一个页面时，上一个页面一般都会被销毁。如果首屏组件的逻辑很重，从另一个页面返回首页时，就需要等待首页的重建。
用户需要等一段时间，而这段时间页面相当于处于不可用的状态。
可以看到上面那张优化前的图。从其他路由返回到首页时，Desktop Home Layout 这个组件在重新渲染时大概花了 500ms。
使用 React 的 Offscreen（也就是 Activity 组件）优化之后，从其他页面返回到首屏的时间控制在 55ms 左右，几乎在点击的瞬间就可以完成跳转。
这是在开发环境下的火焰图表现，在生产环境下，它的速度会更快。
https://github.com/lobehub/lobe-chat/pull/10890
完成了上述内容后，在消息列表中，单个 MessageItem 的首次渲染性能有了非常大的进步。
但是，MessageItem 组件过于复杂，部分基础组件如果渲染开销较大，也会影响整个 MessageList 的性能。
首先重构了 AccordionItem 组件，这类组件在未展开时，内容区的 React 组件逻辑通常不必执行。因为它在 UI 中本身不可见，那么对应的组件逻辑也不应执行。
这是一种常见的优化手段，在比较复杂的组件中，能够显著提升性能。
https://github.com/lobehub/lobe-ui/pull/430
Tabs 也是基础的 UI 组件。在之前的 AntD 实现中，单个 Tooltip 的渲染性能开销非常大，在开发环境中平均需要 0.5ms。
在过去的多个PR中，我使用了 Base UI 以及组件单例的方案，重构了包括 Tooltip 和 Popover 两个组件。
目前在业务中，基本已经把 Tooltip 替换完毕了，Popover 的话还有剩余一些。更换之后，这两个组件的性能比之前有了很大的提升。
https://github.com/lobehub/lobe-ui/pull/448
还有其他一些基础组件也还有优化的空间，但目前还没有细看。
后续的计划如下：
关于裁剪 Electron 体积的话，其实我之前也分享过经验。
首先在 Mac 上，Electron Framework 的体积是可以裁剪的。它里面自带了很多语言包，占用大约 34MB 左右。我们可以把它们全部删掉，只留一个英语（en.lproj）就可以了。需要注意的是：
通过这种方式，直接就能省掉 ~30MB 左右的体积。
其次，我们可以优化 ElectronBuilder 打包 node_modules 的逻辑。
一般来说，如果 Electron 主进程（Main Process）的打包没有 Native Binding 的话，我们可以利用打包器把所有的三方依赖打进我们的 Bundle 里面。这样一来，程序就可以完全脱离 node_modules 去运行。
然后可以修改 ElectronBuilder 的配置在配置中将 node_modules 排除掉。
当然，这里考虑到后面可能会使用到 Native Binding，所以我在里面做了一层兼容性。
如果有 Native Binding 的话，我们可以把单独的 Native Binding 依赖加进配置，这样一来，这个依赖就会被打到 asar.unpack 里面。
详细的配置我就贴在下面，大家有兴趣可以看一看：
https://github.com/lobehub/lobe-chat/pull/11397
经过这些处理，大概裁剪了 100MB 左右。现在 App 的体积大概在 260MB 左右。
对于 60fps 的要求，一帧只有 16ms 的时间。
如果单个组件的性能消耗超过 1ms 以上，那么该组件首次加载的性能就会变得非常糟糕。因此，我们尽量要将单个组件的性能控制在 1ms 以内。在首屏的场景下，我们要实现最高程度的优化，控制首屏的 LCP。那么，我们就要尽量控制首屏组件的渲染性能。
如上面的火焰图所示，红色标注的这些组件都是性能不过关的组件。
可以看到，这些组件的渲染时间都超过了 1ms，在右侧的那些的单个组件的渲染甚至达到了 5-6ms。
由此可见，我们需要去优化这些信息。在展开这些组件之后，我们可以看到存在哪些 Hook，然后在组件中进行打点，以此排查是哪个 Hook 或者哪段逻辑存在性能瓶颈。
在下面这个 PR 中，我尝试解决了这些问题，将其优化到小于 1ms 毫秒。
https://github.com/lobehub/lobe-chat/pull/11718
详细的优化过程可以查阅上面 PR 中的改动。
使用路由的动态加载，可以有效地分割包体积，提升 WebApp 在首屏中首次加载的 JS Bundle。从而提升首屏的 LCP。但带来的问题是，在 SPA 应用中由于得不到较好的优化，在之后的路由跳转中，首次会出现 Loading Element。但这个首次加载的包体大小，在本地的 Electron 应用中并不是问题，所以在这类场景中，我们并不需要使用动态加载的方式。在下面的 PR 改动中，我使用 AST Grep 进行了优化，针对 Electron 打包场景对代码进行了重写，将动态引用全部改为同步引用的方式。
https://github.com/lobehub/lobe-chat/pull/11690
带来的好处显而易见：在 LobeHub 2.0-next.330 之后的版本中，首次在聊天框中输入内容以及跳转到聊天界面时，都不会再出现闪烁的情况。
上面就是一些性能优化的点。
接下来，我想说一说影响开发体验（DX）的一些优化吧。
首先是我很早以前跟空谷提过的建议：把 i18n 的 key 扁平化，不要使用对象嵌套的方式。
这样做的原因主要有以下几点：
也是终于把这个事情给做掉了。
还有一个也是我想想安利一下的，就是我之前写过的一个库：electron-ipc-decorator。我也把这个库给实装了。
因为之前的实现需要一个 dispatch，然后再去做 subscribe，类型化也不太安全，而且 dispatch 的 type 也都是 hardcode 的一个 string 编码，我感觉不是很好。
所以我把自己这一套也换了上去，现在写起来比较方便。
https://github.com/lobehub/lobe-chat/pull/10679
剩下的话其实还是在做一些计划。
比较大的一个重构点，应该就是把 Next.js 迁移到 Vite。这个计划的工程量很大，目前还在筹划中。我也做了一些实验，应该还是有可行性的。
如果这个能成功的话，那应该也是很多开发者的一个福音了。
不管是团队内的人还是社区的人，现在应该都能很明确地感受到，现在 Next.js Server 启动的话，大概要十多个 G 的运行内存。如果你是 16G 的机器，基本上是没有办法开发的。
而通过实验做下来的结果是：Vite 可以控制开发时的运行内存，只需要大概 1G 多一点就行了。相比之下，内存占用和现在相比大概减少了 10 倍左右。
