最近，和往常一样在刷 GitHub Trending 热榜时，突然看到又一个开源项目冲上了 Trending 榜单。

一天之内就狂揽数千 star，仅仅用两三天时间，star 数就迅速破万，增长曲线都快干垂直了！

出于好奇，点进去看了看。

好家伙，这居然还是小米开源的项目，相信不少小伙伴也刷到了。

这个项目名为：ha_xiaomi_home。

全称：Xiaomi Home Integration for Home Assistant。

原来这就是小米开源的 Home Assistant 米家集成，一个由小米官方提供支持的 Home Assistant 集成组件，它可以让用户在 Home Assistant 平台中使用和管理小米 IoT 智能设备。

Home Assistant 大家知道，这是一款开源的家庭自动化智能家居平台，以其开放性和兼容性著称，其允许用户将家中的智能设备集成到一个统一的系统中进行管理和控制，同时支持多种协议和平台。

通过 Home Assistant，用户可以轻松地实现智能家居的自动化控制，如智能灯光、智能安防、智能温控等，所以是不少智能家居爱好者的选择。

另外通过安装集成（Integration），用户可以在 Home Assistant 上实现家居设备的自动化场景创建，并且还提供了丰富的自定义功能，所以一直比较受 DIY 爱好者们的喜爱。

大家知道，小米在智能家居领域的战略布局一直还挺大的，IoT 平台的连接设备更是数以亿记，大到各种家电、电器，小到各种摄像头、灯光、开关、传感器，产品面铺得非常广。

那这次小米开源的这个所谓的米家集成组件，讲白了就是给 Home Assistant 提供官方角度的支持。

而这对于很多喜欢折腾智能家居或者 IoT 物联网设备的小伙伴来说，无疑也算是一个不错的消息。

ha_xiaomi_home 的安装方法有好几种，包括直接 clone 安装，借助 HACS 安装，或者通过 Samba 或 FTPS 来手动安装等。

但是官方是推荐直接使用 git clone 命令来下载并安装。

cd config

git clone https://github.com/XiaoMi/ha_xiaomi_home.git

cd ha_xiaomi_home

./install.sh /config

原因是，这样一来当用户想要更新至特定版本时，只需要切换相应 Tag 即可，这样会比较方便。

比如，想要更新米家集成版本至 v1.0.0，只需要如下操作即可。

cd config/ha_xiaomi_home

git checkout v1.0.0

./install.sh /config

安装完成之后就可以去 Home Assistant 的设置里面去添加集成了，然后使用小米账号登录即可。

其实在这次小米官方推出 Home Assistant 米家集成之前，市面上也有一些第三方的米家设备集成，但是多多少少会有一些不完美的地方，典型的比如设备状态响应延时，所以导致体验并不是最佳。

与这些第三方集成相比，小米这次新推出的官方米家集成无论是性能还是安全性都可以更期待一下。

如官方所言，Home Assistant 米家集成提供了官方的 OAuth 2.0 登录方式，并不会在 Home Assistant 中保存用户的账号密码，同时账号密码也不再需提供给第三方，因此也就避免了账号密码泄露的风险。

但是这里面仍然有一个问题需要注意，项目官方也说得很明确：虽说 Home Assistant 米家集成提供了 OAuth 的登录方式，但由于 Home Assistant 平台的限制，登录成功后，用户的小米用户信息（包括设备信息、证书、 token 等）会明文保存在 Home Assistant 的配置文件中。因此用户需要保管好自己的 Home Assistant 配置文件，确保不要泄露。

这个项目开源之后，在网上还是相当受欢迎的，当然讨论的声音也有很多。
小米作为一家商业公司，既然专门搞了这样一个开源项目来做 HA 米家集成，这对于他们来说不管是商业还是产品，肯定都是有利的。

不过话说回来，有了这样一个由官方推出的开源集成组件，不论是用户体验还是可玩性都会有所提升，这对于用户来说也未尝不是一件好事。

那关于这次小米官方开源的 Home Assistant 米家集成项目，大家怎么看呢？

注：本文在GitHub开源仓库「编程之路」 github.com/rd2coding/R… 中已经收录，里面有我整理的6大编程方向(岗位)的自学路线+知识点大梳理、面试考点、我的简历、几本硬核pdf笔记，以及程序员生活和感悟，欢迎star。

牛马终究还是回到了草原

大家好呀，今天开始继续更新文章了，最近一个月因为换了城市，调整状态花了不少时间，现在才有些动力继续更新，今天来聊聊最近一年多的经历

1.回二线城市

23年12月的时候，我从北京阿里离职了，回到离家近的武汉，拿了一个国企的offer，也是在那家国企待了一年多的时间。

至于为什么会选择回武汉，主要觉得在一线城市买不起房，而且长期在外离家远，漂泊感太重，还不如早点回二线城市定居下来，免得以后年龄大了更不好回来。所以，当时看武汉的机会主要找稳定的工作，除了国企offer，还拿过高校，以及其他偏稳定的公司offer。综合考虑后，才选的国企

回来之后没到两月，就有些后悔了。虽然回来之前做好了心理预期，工资会降低，只是国企的工资也低的过于少了吧，开始几个月工资只有原来的零头。而且，呆了一段时间后发现，这个国企在北京才是研发中心，武汉这边作为分中心，只是北京的“内包”而已。

项目经理都是在北京，很多还都是校招进去工作才两三年的，就让管武汉这边几个人的工作。这些人也没啥管理经验，就只是不停给底下人施压。而且经常搞的操作就是，项目都是有时间要求的，开始的时候不拉人进来干活，等到时间比较紧的时候，才拉人进来，这就导致武汉的人收到任务时，都是重要且紧急的工作。又或者正常工作日没安排活，等到要放假，或者下班之前，才给安排活，让自行加班完成，故意恶心人

2.上着北京的班，拿着武汉的工资

这个事在24年的时候，已经发过吐槽了，就发张截图看看

3.成长的焦虑

我在北京的时候，除了阿里，之前也呆过一家互联网公司。裁员是比较常见的事情，虽然我还没被裁过。

国企这边虽然说相对比较稳定，但是自从我这批大概20个人入职后，感觉在走下坡路了，不仅福利变少，而且也变卷了，还传出后面也要搞末尾淘汰的事。我呆了一年的时候，感觉比在一线时更害怕，假如我在这里被裁了，或者呆满三年不续签了，可能很难再找到合适的工作了，自身成长和工作年限严重不匹配，想到这，我终于还是下了决定再去一线城市

找下家的经历并不顺利，国企的项目可以说就是玩具而已，完全拿不出手。只能拿之前阿里的项目去讲。有些一线互联网大厂，面试了好几轮，好不容易都过了。在焦急等待了数周后，最后给我说横向比较有更合适的了，就不考虑了。其实大家也都明白是因为啥原因不给发。

4.空窗期

经历了几个月的找工作经历后，终于是拿到上海一家公司offer，于是也就顺理成章准备跑路了。趁着中间有半个月的空闲时间，去西边青海和西藏游玩了一次。那边景点之间距离远，在携程上报跟团游就行，价钱不高，比较推荐去青海游玩，那的牛肉和羊肉非常新鲜，值得尝试，3天的时间，每天都能看不一样的风景。

5.上海

已经到上海快两个月，开始逐渐习惯天天下雨的节奏，现在下班还是比较早的，下班的时候还能见着落日，比较WLB，没有互联网大厂那么的卷，却也是有些压力的。下面是第一周下班时路上的照片

今天就写到这吧，下次有新鲜事再分享~

昨儿中午吃着饭，不知道为啥突然和同事聊起来AI发展的事儿了。虽然我们只是"🐂🐎"，但是不妨碍咱们坐井观天，瞎扯淡聊聊天。

他的主要观点是：现阶段的AI绝对无法取代程序员，大家有点过度恐慌了。AI是程序员的工具，就像从记事本升级到IDE一样。

我的主要观点是：AI一定会取代大量的程序员，尤其是初级程序员。后续程序员岗将在软件公司内的比重降低，取而代之的是产品、需求和算法岗。

诚然，他说的也有一定的道理，就目前AI发展的速度和质量来看，其实大家的确有点儿过度恐慌了。

AI的确在一定程度上替代的程序员的工作，但是大多内容仍然是程序员群体在产出，这个是不容否认的事实。

不过另一个不容否认的事实是，我们越来越依赖AI了。原来大家写代码一般都是啥不会了，就直接去网上搜。比如说js怎么截断从第2位到最后一位，想不起来了，搜一搜。

现在有了AI，一般的操作都是在上面写个注释，然后回车一下，AI会自动帮你补全代码，连搜的功夫都省了。

由此俺也big胆的预言一把，CSD*、掘*、百*这些资讯类，尤其是做程序员这个方向的资讯网站会越来越没落。

原因是：有了问题，但是没有了搜索。没有搜索就没有共享解决方案的必要，因为没人看。没人看所以不再有人分享，最后Over。

Ps：或许我被啪啪打脸呢？

之前的AI编码工具我就有在用，包括阿里的通义，百度的文心，或者是IDEA里面内嵌的编码助手，以及之前CodeGeex等等吧，确确实实是提高了效率的。

这个阶段其实重点提升的是搜索的效率，有问题直接问AI，AI直接给出答案。95%的答案都是正确的，不必再去网上费劲巴拉的找了。

后来更上一层楼，Claude2、3直接翻倍的提升了开发效率。我不必再实现了，我只需要阐述需求，AI会自动给出答案。我需要的是把内容Copy下来，然后整合进我的工程里面。

后面的工作就还是原来的老步骤了，测试一下，没啥问题的话就发版，提测了。

但是现在这个阶段又进步了，TREA2.0 SOLO出道直接整合了全流程，整个过程直接变成了"智能体"把控，不再需要我的干涉了。

我需要做的工作就是阐述清楚我的需求，然后让TREA去实现。这个过程中可能也就只需要我关注一下实现的方向不要有太大的偏差，及时纠正一下(但是到目前为止没遇到过需要纠正的情况)。

也就是说，现在AI已经从原来的片面生成代码，到后面的理解需求生成单文件代码，到现在生成工程化代码了。

而我们的角色也从一个砌墙工人，拿到了一把能自动打灰的铲子。

到后面变成一个小组长，拿着尺子和吊锤看他们盖的墙有没有问题。

到现在变成包工头看着手底下的工人一层层的盖起大楼。

但是！

你说工地上是工人多，还是组长多，还是包工头多？真的需要这么多包工头嘛？

前言

一个老🐮🐴的吐槽。 水水文章。不喜勿喷～

现状

看过我之前帖子的小伙伴了解过 我现在在创业的路上越走越远。痛苦面具又带上了。 每天就是处理不完的事情。层出不穷的状况。各种乱七八糟的电话。处理不完的工作。在这个过程中学到了很多技术之外的东西。看到了以前看不到的东西。同样的。也渐渐放弃了属于一个开发者的身份

自己做了这么多年的技术。回头看看其他同期的小伙伴。要么已经开始玩鸿蒙。或者小程序。或者其他的等等等。
自己其实很早就涉猎。但是绝对谈不上精通。现在年纪也大了。发现精力真的有限。而且也发觉学不动了。渐渐的就变成了守护自己的一亩三分地。 技术也在降低。

有心想去学习一下鸿蒙。感觉不难。第一是没系统的时间去专门学习。二是认为如果发展需要。可以选择招聘动这个技术的人去完成这部分工作。自己没必要去学。

碎碎念

公司现在也慢慢开始扩招。算是慢慢走上正轨。业务页越来越多。同样的压力页越来越大。毕竟咱现在可没那么好运气。有人愿意给我钱让我去玩。都是自己的真金白银。出现任何的问题都可能是致命的。

说道招聘 。哎。最近一周都是在面试。一直找不到合适的人。或者遇到合适的 人家瞧不上咱这小门小庙的。属于是难。

写在最后

作为技术出生的牛马。对于技术始终是热爱的。然而显示就是现在就是慢慢的脱离了技术的身份。有更多需要我去做的事情。也有更多值得我去做的事情。 希望财富自由。漫漫长路。还远的很啊～

给年轻人建议

有点装大尾巴狼了。 勿喷哈。 因为最近一直在面试。其实也有很多应届生。我是不反对应届生的。相反我很喜欢带小朋友。而且也带过不少小朋友。

但是很多应届生给我的感觉就是。虽说咱这行收入相比其他行业要好一点。但咱这小门小庙的 也不是应届生张口8K咱能用得起的啊。毕竟小公司。我比较穷。。

不少应届生给我的感觉是心浮气躁。并没有对技术的敬畏。与之带来的是基础的不扎实。这很大程度上限制了自己的上限的。

你正在给一家 SaaS 客户做「企业级仪表盘」项目。

需求很简单：把 20 多个子系统的实时指标汇总到一张大屏。

为了“图省事”，你在入口文件里顺手写了这么一段：

// main.js

window.dashboard = {};                 // 🔍 全局缓存

window.dashboard.cache = new Map();    // 🔍 存接口数据

window.dashboard.refresh = () => {     // 🔍 供子系统调用

  fetch('/api/metrics').then(r => r.json())

    .then(data => window.dashboard.cache = new Map(data));

};

上线两周后，客户反馈：

“切到别的标签页再回来，大屏偶尔会白屏，刷新又好了。”

排查发现，Chrome 在内存紧张时会 回收后台标签页的 JS 堆，但 window 对象属于宿主环境，不会被回收。

结果：

• 旧的 dashboard 引用还在，但闭包里的 Map 被 GC 清掉，变成空壳；


• 子系统继续调用 window.dashboard.refresh，拿到的永远是空数据；


• 页面逻辑崩溃，白屏。

解决方案：三层防护，把风险降到 0

1. 表面用法：用 WeakMap 做“软引用”

// 把全局缓存改成弱引用

const cache = new WeakMap();           // 🔍 不阻止 GC

window.dashboard = {

  get data() { return cache.get(document); }, // 🔍 与当前文档生命周期绑定

  set data(v) { cache.set(document, v); }

};

这样当用户切走标签页、文档被卸载时，cache 自动释放，切回来重新初始化，白屏消失。

2. 底层机制：为什么 window 不会被 GC？

结论：window 是宿主对象，生命周期长于 JS 堆，挂上去的东西如果强引用 JS 对象，会导致“僵尸引用”。

3. 设计哲学：把“全局”变成“注入”

与其在 window 上挂变量，不如用 依赖注入 把作用域限制在模块内部：

// dashboard.js

export const createDashboard = () => {

  const cache = new Map();             // 🔍 私有状态

  return {

    refresh: () => fetch('/api/metrics')

      .then(r => r.json())

      .then(data => cache.clear() && data.forEach(d => cache.set(d.id, d)))

  };

};

// main.js

import { createDashboard } from './dashboard.js';

const dashboard = createDashboard();   // 🔍 生命周期由模块控制

应用扩展：可复用的配置片段

如果你的项目必须暴露全局 API（比如给第三方脚本调用），可以用 命名空间 + Symbol 双保险：

// global-api.js

const NAMESPACE = Symbol.for('__corp_dashboard__');

window[NAMESPACE] = {                  // 🔍 避免命名冲突

  version: '2.1.0',

  createDashboard

};

环境适配说明：

• 浏览器：Symbol 在 IE11 需 polyfill；


• Node：同构渲染时 window 不存在，用 globalThis[NAMESPACE] 兜底。

举一反三：3 个变体场景

小结：

把 window 当“公告栏”可以，但别把“保险箱”也挂上去。

用弱引用、模块化和依赖注入，才能把全局变量的风险真正关进笼子里。

拥有自由的人，会想什么是自由吗？

这个问题很动人。

就像从不缺氧的人，不会意识到自己在呼吸；只有气压骤降、肺部抽痛、窒息临近，你才突然意识：空气原来不是理所当然的东西。

自由也是一样的。它真正被觉察的时候，往往是在你被拿走的时候。
不是所有人都有幸拥有“思考自由”的资格——更大的现实是，大多数人连“自由”这个词，在生活中都用不上。

但更残酷的问题是：一旦你开始思考自由，你可能就已经不再自由了。

意识是自由的开始，还是终结？

我们都羡慕小孩的自由，羡慕他们想哭就哭、想跑就跑。那是因为他们没有太多意识，不懂责任，不预设后果。他们拥有的，某种程度上就是我们说的“纯粹的自由”。

但我们一旦有了意识，就不得不开始自我规训。
你不能说错话，不能做错事，不能轻易违背别人的期待，也不能轻易违背自己的设定。这时候，自由就变成了一个带着锁链的词——它不再是“你想干嘛就干嘛”，而是“你要先知道你干嘛，然后想清楚值不值得干”。

你开始意识它，珍惜它，运用它。听上去很高尚，但自由就没那么轻盈了。你得为每一个选择负责。你得考虑代价。你得思考背后有没有人被伤害，代价是否能承受。那时候你拥有的自由，不再是“想干嘛就干嘛”，而是“想清楚还能不能干”。

于是我们陷入悖论：越意识自由，就越离自由远。

真自由，是不是只能不想自由？

也许真自由的极致状态，就是你不再思考自由。

你骑车穿过黄昏，不想目标，不管导航，只有风。那一刻你自由得像只鸟——不是因为你想清楚“我现在自由”，而是因为你根本没想。

但人做不到这一点。
人思考，自我意识，把自己从自然的状态中拉出来。他要赋予意义，要预测后果，要制定计划、要写年中总结。“思考”是人成为人的标志，但恰恰是这种人性，把自由给污染了。

你可以试着淡化思考和责任，去贴近那种“纯粹的自由”。
但走到尽头，你会发现，那个状态更像动物，或者神明——不是人。

佛陀顿悟时抛弃自我，道家讲“无为而无不为”，他们都靠剥离世俗意义、剥离责任来获得自由。但代价是：你不再是你了。你不再参与、不再牵挂、不再卷入——你从人间抽身而出。

那还是你想要的吗？
你想要的自由，真的是那种不思考、不负责、无我无念的“纯粹自由”吗？还是你其实想要的是“有方向、有意义、有选择权的自由”？

那就不是“纯粹的自由”，而是“人的自由”了。
被命名，被负重，被理性打磨过的一种自由。

成年人的自由，成熟还是无奈？

很多人问：我们活在这种“既不能无意识、又不能无限选择”的自由状态里，算不算一种折中？
是深刻的选择，还是没办法的接受？

我想，这两种说法都对。

是选择的深刻，是因为我们终于知道，自由不是想干嘛就干嘛，而是想清楚干嘛还敢干。我们学会了在有限中谋局，在责任中行事，在约束中寻找空间。

是无奈的接受，是因为这世界本就不为个体设计。你生而有父母、有文化、有制度、有边界，你不是赤条条的自由人，而是注定被驯服的社会动物。

所以这就是我们大多数人的状态：在责任和意义之间拉扯，在妥协与坚持中微调。我们既不彻底自由，也没有完全被束缚。我们像在悬崖边站着，一边看风景，一边找落脚点。

真自由的瞬间：不解释、无恐惧、自己买单

有没有真正自由的时刻？有。

也许它不是持续性的，不是状态，而是一个个“瞬间”：

• 你做了一个决定，没有任何人强迫，也没有任何人能为你负责，但你依然选了它。


• 你拒绝了别人的定义，不害怕后果，不需要解释，也不留退路。


• 你明知代价高昂，但你还是咬牙说：“是我选的。”

这些时刻，就是成年人的自由瞬间。它不一定光鲜，但它是真实的。

不是没有限制，而是你在限制中还敢动，还想选，还愿意承担结果。

小时候我们追求的自由，是不要规则、不要约束。
长大后我们追求的自由，是在规则中拥有自己的边界感，在约束中活出自己的形状。

我们不会再轻易喊口号，也不会高谈“我要自由”。因为我们知道，自由并不是要来讲的，而是用来活的。

自由从来不是站在天台上的呼喊，而是你在清晨醒来，决定今天以什么方式活。

有些人一生都在寻找自由，却不知：
你敢为自由付出代价的那一刻，你就已经自由了。

推荐阅读

房产票据价值模型：7张票拆解一套房的真正价值，推演未来涨跌

什么是好婚姻？一场人类与AI直指婚姻本质的深度对话，带你认清自己

互联网打工人如何构建稳定的社会身份？——从腾讯离职到圈层断崖的思考

互联网人，为什么你越来越能干，路却越走越窄？换个体制内视角看看

从“奶妈”的消失看“母职外包”：自由是建立在别人无法选择的人生之上

我技术成长了，但人生没痕迹，可能这就是程序员的遗憾吧

我用扣子空间制作了档小宇宙播客《语出惊人》，借AI之口犀利对谈人生困境，效果惊艳

程序员如何在家庭、工作、健康之间努力找平衡

前言

作为程序员，我们每天都要面对 工作、家庭、健康 的三重压力。加班是常态，学习新技术是必须，家人的期待也不能忽视，而自己的身体却在无声抗议……

如何在代码、生活和健康之间找到平衡？ 今天，我想分享自己的实践心得——时间管理、高效工作（甚至合理摸鱼）、坚持运动和培养爱好，让生活不再只有996。

1. 时间分配：你不是没时间，只是没规划

很多人抱怨"太忙了，根本没时间"，但其实：

• 时间就像海绵里的水，挤一挤总会有


• 关键在于优先级，而不是时长

（1）工作日时间分配（参考）

关键点：

• 早起1小时 > 熬夜3小时（效率更高，不影响健康）


• 午休小睡能提升下午效率（NASA研究证实）


• 晚上固定家庭时间（让家人感受到你的存在）

2. 上班摸鱼的正确姿势（高效工作法）

摸鱼 ≠ 偷懒，而是 科学调整工作节奏，避免 burnout（职业倦怠）。

（1）合理摸鱼技巧

✅ 番茄工作法：25分钟专注 + 5分钟休息（刷掘金、喝水、拉伸）

✅ 每1小时起身活动：接水、上厕所、简单拉伸（预防颈椎病）

✅ 利用自动化工具：写脚本省时间（比如自动生成周报、批量处理数据）

✅ 学会"战略性拖延"：非紧急需求先放一放，等PM改需求（你懂的）

（2）减少无效加班

❌ 无意义会议：能异步沟通的绝不开会

❌ 过度追求完美：代码能跑就行，别陷入"过度优化陷阱"

❌ 盲目卷工时：效率 > 工作时长，早点干完早点走

摸鱼的核心是：用更少的时间完成工作，把省下的时间留给生活。

3. 下班后：运动 + 兴趣，找回生活掌控感

（1）运动：程序员最值得的投资

• 每天10分钟拉伸（改善肩颈酸痛）


• 每周3次有氧运动（跑步、游泳、骑行）


• 利用通勤时间运动（骑车上班、步行回家）

（亲测有效） 自从坚持运动，我的腰不酸了，debug效率都提高了！

（2）培养兴趣爱好，对抗职业倦怠

• 学一门非技术技能（摄影、吉他、烹饪）


• 参加线下活动（技术沙龙、运动社群）


• 每周留出"无屏幕时间"（比如读书、拼乐高）

生活不能只有代码，否则你会变成一个无聊的人。

4. 家庭时间：质量 > 数量

• 每天30分钟专注陪伴（不刷手机，认真听家人说话）


• 周末至少半天家庭日（哪怕只是逛超市、一起做饭）


• 重要日子提前安排（生日、纪念日，绝不缺席）

孩子不会记住你加了多少班，但会记住你是否陪他踢过球。

结语：平衡是动态的，不是完美的

程序员的生活就像 多线程编程——工作、家庭、健康，每个线程都要分配好资源，否则就会死锁。

我的经验是：

掘友们，你们是如何平衡工作、家庭和健康的？欢迎在评论区分享你的经验！

（如果觉得有用，点个赞吧～ 🚀 你的支持是我分享的动力！）

关于作者

一个拒绝996的程序员，相信 代码是为了更好的生活，而不是取代生活。

关注我，了解更多程序员成长 & 生活平衡技巧！

引言

前两天有个朋友劝我：“你写作一年半了，再不搞点产品变现，继续写作两三年，可能还是原地踏步。”

写了一年半，80多篇文章，没涨粉、没变现、也没10w+。很多人觉着我白干了，可我反而觉着，这是我这几年做的最对的一件事情。

现在回头看看，真正让我成长的，恰恰是那些“什么都没做”的时光。

浪费时间才能感受到自由且主观的愿望

我们这一代人对时间的利用，已经开发到了极致，有着极强的目的性。

高中时，排队打饭背单词，午休趴在床上背公式。

大学毕业，为了面试背八股文、刷算法。

在大厂，一空下来就去研究新技术、优化工作流......

我从未停下来过，连休息都像在为下一次奔跑而准备。

我们太怕浪费时间了。

怕没成果，怕落后，怕被这个飞速发展的社会淘汰掉。

可你想想，我们来到这个世界，不应该是来探索和体验的吗，我们看似高效利用了时间，可有多少时间是真的为了你自己呢。

上篇文章我提到，回到济南之后，相比在北京有了更多空闲时间，并且开始“补偿性浪费”，刷短视频、打游戏、炒股，算得上不务正业。

有一天孩子睡觉后，我从8点刷抖音刷到凌晨，但没有记住任何内容，那一刻我有一种无所事事的空虚感。

于是我开始换口味，刷一些技术社区、公众号文章。偶尔点进一些作者的首页，我发现他们很多并不是大V，也没有露脸，但写的文字有一种特别的力量。

他们写自己的经历、认知的变化、对技术和生活的思考，字里行间有诚意也有深度，我有点羡慕，也有点触动。

既然他们可以写，我也可以。

那一刻我才想起来，我好像很早之前就喜欢写东西，只不过后来成家立业，一路奔波，把这件事丢在了脑后而已。

这么多年，我总是忙着成为别人期待的样子，却很少问自己一句：我到底喜欢什么？

于是我开始尝试着表达自己，一开始不为流量也不为变现，就只是为了找回一点属于自己的空间，

现在回头看，那段“虚度光阴”的日子，并不是浪费，而是我停下来，等到了那个被遗忘很久的自己。

时间看似浪费，但是在塑造你

有一次晚上睡觉前，随手打开了一篇去年写下的文章。

看着看着感到睡意全无，逻辑混乱、语句稚嫩，没有原创的观点，更没有什么进步，可怕的是这样的文章我重复了这么多遍，我忍不住怀疑自己这一年到底在干些什么。

还有一次我花了4、5天写下了3000字，写完读了一遍，发现整个逻辑有些牵强，于是我把写下的内容挪到了“回收站”里，那一刻我感觉我自己浪费了好几天的时间。

这些文章，没有涨粉，也没有变现，也没写出个10w+，那种感觉我自己都很难说清楚，明明花了时间和精力，却有一种什么都没留下的“无力感”。

有几个一起做公众号的朋友，已经走通了自己的商业闭环，而我却连个精准的定位都没有。有一段时间我经常会陷入自我怀疑，我这样的坚持到底有没有意义。

一直以来好像都很着急，我习惯了“投入—产出—收益”的闭环，反倒忘了有些事情短期就是看不到结果。

可就是在这样反复挣扎的过程中，我好像有了一点变化，并不是我变得更高效了，而是我越来越清楚自己想表达些什么，想成为什么样的人。

我做自媒体之初并没有定位，可慢慢的我在过去80多篇文章中，我慢慢发现了几条主线。

比如作为这个时代的一个普通人，我喜欢分析一下时代困局，比如越来越卷的互联网，比如AI飞速发展下，我们面临的存在主义危机；

我热衷谈论认知提升的话题，如果我们要和那些优秀的人去对比，我们会发现除了财富和见识，差距最大的可能是认知边界；

我会谈论一些写作相关的东西，因为写作在这个人人都可以是一个品牌的时代，写作本身就是竞争力。

这几个方向不是我刻意设计出来的，而是过去敲下的每一个字塑造出来的。

我想起乔布斯在斯坦福大学演讲时分享的故事，乔布斯曾在大学退学后，痴迷于书法，选修    了一门看似“无用”的课程：书法美学。

直到十年后，他在打造第一代 Macint0sh 时，那些关于字体的记忆突然涌上心头。他让电脑第一次有了漂亮的字体系统，正是这件“没用的事”，让 Apple 成为了极少数“兼具科技与艺术”的品牌。

很多事情只有回头看，点才会连接成线，你想想是不是这样。

而这一切的前提是：你愿意为此“浪费时间”。

我现在怎么与时间相处的

最后一点想聊聊提升效率这回事——真正的高效，不是把时间填满，而是敢于浪费一些时间。

有孩子的人一定都有体会，娃绝对算的上是一个「时间剥夺兽」。

我为了抢夺时间，做了特别多的尝试：比如孩子一安静下来，我就赶紧打开手机看篇文章；给娃刷奶瓶刷碗的时候，我就打开听书；甚至陪孩子的时候，嘴上给他讲着故事，脑海里还不停的想一些自己的事情。

我一直试图绷紧脑海里的一根弦，觉着只要把时间用满了，就没有浪费。

但现实是，我越来越累，状态越来越差，效率越来越低。

其实我们没必要给自己较劲。

直到读了《超高效》这本书，我才意识到，大脑的原始设定，并不是持续“高负荷”的，而是分成了三种运行状态，符合幂律分布的节奏。

横坐标代表了工作强度，纵坐标代表频率。书里面列举了很多人类学家对原始部落的观察：那些采集、狩猎为生的人，绝大部分时间都是在放松，走走停停，一点也不忙碌。只有在必要的情况下，才会去长时间奔跑去追踪一个猎物，而且干一次得休息好几天。

大部分时间做轻松的事情，偶尔上个强度，才是我们人类天然适合的状态。

而我们日常的工作和生活却反过来了，试图每小时都高产，每天都有 产出，哪怕放假都不敢停歇。

你想想是不是很多人都这样？多少大厂的程序员，被一个bug卡住半天，却死盯着屏幕不愿站起身。明明已经困的上下眼皮打架，还是逼着自己熬夜敲着代码。领导看着没完成的工作量很大，就强迫大家周六周日加班赶进度。

你想想你身边是不是还有另一种人？

你在工位磨磨蹭蹭写代码的时候，同事下楼散散步，买了杯咖啡，再次坐回工位上时，一个小时的工作量比你半天的还要多。

更讽刺的是，代码质量还比你高。

我们为什么不允许自己休息休息呢，让自己“浪费”点时间呢？

后来我做出了个改变，我再带孩子出去玩的时候，试着清空大脑，绝不再想下一篇文章的选题，也不想工作上的事情，就是专心的陪着孩子玩。他跑我就追，他笑我便笑，他想要只小虫子，我就抓只蚂蚁放到他手里。

看似一整天我都“没干正事”，可大脑深度放松之后，迅速让我进入高效状态。有时候写着写着没思路了，下楼转一圈卡点就能被解开。

我突然认识到，娃哪是“时间剥夺兽”，而是一个提醒我“别太紧绷”的小天使。

你也可以当自己的小天使。

如果你感到很累，就去看会轻松的小说、看看搞笑的短视频吧，只要让自己的注意力放松下来就好。如果你很累，还对工作和生活的事很担心，就出去跑一圈、打局游戏或者正念冥想，先把那个担心放下再说。

更简单的方法是订一个闹钟，千万别让自己持续工作超过90分钟，15分钟的小睡能让你迅速恢复精力。

你需要停一停，你值得等一等。

说在最后

现在越来越多的年轻人，哪怕是换份工作，都不敢在这个时候多休息几天。比如我自己，几次跳槽，从来都是今天离职，明天入职。

“浪费时间”说起来容易，可我们心理的的确确存在一些不安全感：怕别人说自己躺平，怕简历又多出一个空档期，更害怕自己没有薪资无法证明自己的价值。

可你知道吗，这些不安全感，并不是我们自身的问题，而是这个时代的结构性压力。

教育体系从小把“高效”描述成美德，互联网把内卷和35岁危机当成噱头大肆宣传，自媒体正贩卖着“日入过万”、“自由职业”的焦虑。

可丁可卯，做每一件事都只注重效率绝不浪费时间，一天到晚跟打仗一样连说闲话的时间都没有，很难做真正重要的事，高水平工作需要浪费时间。

你有多久，没允许自己浪费点时间了？

这是东东拿铁的第83篇原创文章，欢迎关注。

引言

你还记得，上一次真正感受到快乐，是在什么时候吗？

认真想了想，我好像很久没有体会过那种真正让人开心的时刻了。朋友和家人问我最近怎么样，我会回答“还行”、“还不错”，但实际上家庭的琐事，工作的压力，对未来的焦虑，让我连半刻的放松都是一种“奢侈”。

这种状态不只我一个人，身边的朋友也是如此，日常聊天里被越来越多的烦、忙、累填满，有时候甚至“无聊”都成为了一种常态。

可我们小时候，一件新衣服、一个新游戏、一集刚更新的《火影忍者》就能让自己兴奋得整夜睡不着觉。

而现在，曾经喜欢的游戏懒得打开；过去喜欢约上三五好友聚会，现在休息的时候只想窝在家里；哪怕是自己最喜欢的动漫和电影，也没有按下播放键的冲动。

是因为我们长大了、变成熟了，身上的担子越来越重，以至于连快乐都无处安放了吗？

如果你对凡事都提不起兴趣，找不到快乐的方向，那得小心了——心理学上有一个术语，叫做「快感缺乏症」。长期的快感缺失会让我们失去对生活的敏感度，不仅难以感受快乐，还容易陷入负面情绪无法自拔，还有可能导致抑郁。

那么——快乐为什么消失了？我们又该如何找回它？

要找回快乐，就要从我们那个既熟悉又陌生的名字说起：多巴胺。

多巴胺不是快乐源泉

很多人以为，多巴胺是“快乐荷尔蒙”，但其实，它并不直接带来快乐，而是——激励。它并不会让你沉浸在此刻的满足，而是让你对现状“不满足”。它让我们不满足于现状，而是不断前进。

多巴胺能强烈驱动动机，但是它的激励效应转瞬即逝。一旦我们吃饱喝足、或者满足了我们的什么愿望之后，多巴胺的奖励作用就会消失，促使着我们去寻找下一份刺激。

在远古时代，这对于人类来说是一个非常重要的生存机制。因为食物短缺，安全难求，原始人几乎需要用80%的时间去觅食和寻找庇护上。大脑通过分泌多巴胺，促使他们保持求生欲，永不停歇。

然而到了现代社会，我们的生活方式彻底发生转变，而大脑的运作方式没有得到进化。于是大脑的多巴胺通路被频繁激活，远超我们所能接受的频率。

除了食物和性这些本能，酒精、电子游戏、网购，甚至是社交媒体的点赞，都在无时无刻挑动着我们体内的多巴胺。原始人辛苦一天才能换回的一丝快感，我们轻而易举的就能让它泛滥。

快乐太容易得到了，于是它反而越来越难感受到了。

多巴胺会激活「D2」型受体， 它的特点是收到太多多巴胺之后会产生“脱敏”，并且还会启动抑制机制，一旦被过度刺激，就会容易“疲劳”，最终让我们变得迟钝、不再敏感。

其实还有另一个罪魁祸首是「皮质醇」，它由肾上腺分泌，能够加速我们的代谢和心跳，让我们随时应对可能出现的威胁，让我们处于专注紧张的状态，但是它会抑制多巴胺的释放。

其实这也是远古时期人类的一种自保机制，可是现代社会节奏忙碌紧张，我们时刻都在为某些事情感到焦虑，比如学习成绩没能提高，工作迟迟没有涨薪，甚至是领导安排的任务马上到了Dead Line。

人体的压力系统，本身是为了突发事件而准备的，并不适合现代社会全天候的压力输入，在随时随地都能接收到各种信息的智能时代，我们的压力系统也被滥用了。

最终结果就是，即使身边的事物都在营造愉悦感，我们也很难感受到愉悦了。

重拾快乐

有一本书叫《消失的多巴胺》，作者在书中给我们提供了一个治愈快感缺乏症的方法，叫做「行为激活法」，这个方法非常简单，用一句话总结就是：记录情绪，列出快乐清单，开始行动，感受快乐，锁定美好。

那具体怎么做呢？首先你要先记录下自己的情绪的初始情况，然后持续记录变化，当你看到变化的发生，你就会有坚持的动力。

然后，找到自己喜欢的事情。你可以为自己列一份快乐清单，比如看电影、逛街，甚至是浇花、换一身新衣服，或者是去买一杯自己喜欢的咖啡，都可以。

接着就是按照清单来行动了，可我们不开心的时候有一个表现就是只想躺平，没有做事的动力。作者告诉我们，在没有做事动力的时候，做事本身就能打破缺乏动力的循环，你应该打消那些让你退缩的念头，说了就去做！

一旦有了行动，心情就可能得到改善，这时候我们就要抓住快乐。方法非常简单，因为我们的大脑一次只能处理一个想法，我们在感受到快乐的时候，集中注意力，在快乐的时刻什么都不想，用心去感受这种体验。

就是在你感受到快乐的时候，别想领导安排的工作，别想马上要还的信用卡和房贷，就感受当下的快乐。

一项研究发现，大脑腹侧纹状体区域的长时间激活与维持积极情绪和奖励直接相关，通过集中精力体会奖励时刻，可以保持高水平的心理健康，同时降低皮质醇的分泌量。

最后一步就是锁定美好时刻，最简单的做法就是感恩。有一种非常流行的方法是写感恩日记，在一天结束时，写下今天你所感激的经历。许多研究都表明，感恩可以增加大脑奖励通路中多巴胺的分泌，大脑会鼓励里去寻找更值得感恩的事物，产生正反馈。

写到这里，我感觉有点疲惫，于是我下楼，站到了阳光底下。

阳光很刺眼，我下意识闭上了眼睛，任由太阳铺满脸庞。阳光有些刺眼、有些灼热，但那一刻，但似乎有某种能量慢慢渗到身体内，驱散了心里的疲惫。

我不和同事说话，不考虑手头的工作，也不去想生活的琐事。只是站在那里，感受阳光，感受微风拂过脸颊，感受自己活在当下。

几分钟而已，心里好像解开了某个结，整个人都变得放松下来。

重拾快乐，其实并不难，其实并不是快乐离我们远去了，而是我们被快节奏的生活裹挟，忘记了如何该寻找它。

到这里，你或许已经从烦躁的情绪中脱身，重新感受到生活中久违的松弛和愉悦。但故事还没有结束——你值得拥有的，不只是回归日常的小快乐，更是那种深层次、持续、更高级的快乐。

更高级的快乐

刚刚提到感恩，可以增加大脑中多巴胺的分泌，也许你会有疑问，现代社会不是多巴胺泛滥了吗？刷短视频、打游戏一样可以获得多巴胺，那感恩带来的多巴胺有什么不一样呢？

当然不一样，不过我们先聊一句我们从小听到大的“金句”——做难而正确的事情。

许多成功者特别喜欢说这句话，那到底怎么做呢？是靠意志力和吃苦吗，是吃得苦中苦，方为人上人吗？是书山有路勤为径，学海无涯苦作舟吗？

成功者没有告诉我们的是，他们做那些难而正确的事情，他们「乐」在其中。这个乐，就来自于多巴胺，而多巴胺分为了「快多巴胺」和「慢多巴胺」。

还记得在介绍多巴胺之前，我说过多巴胺的作用吗？多巴胺并不带给我们快乐，而带给我们的是激励，是让我们兴致勃勃的做事，是一种追逐的快乐。

快多巴胺的触发模式是预测->实现，抽烟、喝酒、打游戏、刷短视频，你预测到了这些行为带给你的奖励，立刻就感受到快乐，简单直接。但是快多巴胺释放门槛低，可重复性高，来得快去的也快。

而慢多巴胺触发的模式是努力->进展。比如跑完今天的五公里，就会感受到今天一天都神清气爽；完成一篇文章，你感觉你的写作和思考能力都加深了一层。你必须先努力一番取得进展，它才能释放。慢多巴胺来得慢，去的也慢。

在字节的时候，有一次和10几个同事封闭在会议室开发一个大项目，临近项目上线的那几天，几乎都到2、3点才下班。每当0点以后都是大家最累的时候，虽然每个人脸上充满困意和疲惫，但是看着项目逐渐成型，功能越来越完善，每个人依然干劲十足。

我们或许都有做大项目的经历，在项目即将完成前，你会叫苦叫累吗？你的目标就在眼前，你做事充满动力，这才是健康的状态。做难而正确的事情，是很爽的。

这段经历过去好多年了，说实话当时做的什么项目我都记不清了，但是我记得一群人在会议室里，一同为项目上线熬夜到凌晨的那几个夜晚。

简单说：快多巴胺是“高起点、小波动、快消退”；慢多巴胺是“低起点、慢上升、慢消退”。两种多巴胺最重要的区别，是它们在大脑中的“接收区”不同，我们的感受也不同。

快多巴胺让我们成瘾，慢多巴胺可以给我们赋能。 我们应该防止自己沉溺于快多巴胺，多来点慢多巴胺。

理解了快多巴胺和慢多巴胺的原理，我们就能明白一个道理，为什么人生需要一个长远的目标。

有目标才能有行动，有行动就会有进展，追逐目标的过程能够带来慢多巴胺，而慢多巴胺对我们而言多多益善。

说在最后

所以，快乐并没有从我们身边消失，它只是在等着我们把它找回。

我们需要的不是更快的满足，也不是更高频的刺激，而是更沉浸的体验和更深入的积累。

“还行、还不错”不是标准答案，“很好、很开心”才是你的原本色彩，你永远值得拥有那种不焦虑、不躁动，却一直点亮我们生活的快乐。

那么你呢，你今天开心吗？

这是东东拿铁的第79篇原创文章，欢迎关注。

提到 Jetbrains 这家公司，相信搞开发的同学应该都不陌生。

该公司盛产各种编程 IDE 和开发工具，虽然2000年才成立，到现在却已经发布了超 30 款世界顶级的编程软件，同时也收获了来自全球范围内开发者和用户的青睐。

众所周知，在去年10月份的时候，Jetbrains 曾经搞过一个大动作，那就是：

官宣 WebStorm 和 Rider 这两款强大的 IDE 对非商业用途全面免费！

当时这个消息出来的时候，就曾在开发者圈子里引起了一阵轰动和讨论。

而且我清楚地记得，在当时的评论区，还有小伙伴这样问道：

“啥时候轮到 CLion 也免费呢？”

这不，好消息再次来临了！！

最近 Jetbrains 再度官宣：

CLion 从现在开始，对非商业用途全面免费！

众所周知，CLion 是由 JetBrains 设计开发的跨平台 C/C++ 集成开发环境，通过智能代码补全、深度代码分析和集成调试工具，为开发者提供高效、现代化的 C 语言和 C++ 开发体验。

然而，CLion 一直以来的高昂授权费用也让不少初学者和开源爱好者为之望而却步。

因此这回消息一出，又再次在开发者圈子里引起了一阵热烈的讨论，不少网友直呼 Jetbrains 这波格局打开了。

看到这里，相信大家也挺好奇，那他们这里所说的 「非商业用途免费」具体指的是哪些情形呢？

对此，Jetbrains 官方也给出了对应的说明，目前的非商业用途情形包括像：学习、自我教育、开源项目开发、内容创作、业余爱好开发等场景就可以免费使用这个 IDE 。

所以现在无论是学生、Arduino 开发者，还是无惧 C 语言和 C++ 重重挑战的忠实爱好者，只要使用场景不涉及商业活动，都可以来免费使用 CLion 进行开发。

说到这里，那具体的非商业用途免费版 CLion 怎么申请和使用呢？

操作其实也非常简单。

1、首先，去官网下载 CLion 安装包并安装。

不过这里要注意的是，用户需要确保下载的 IDE 版本是支持非商业许可证的最新版本即可。

2、启动运行 IDE 后，将会看到一个许可证对话框。

在该对话框中，用户可以在其中选择 Non-commercial use（非商业用途）选项。

3、登录自己的 JetBrains Account 或创建一个新的帐户。

4、登录完成后，用户需要接受 Toolbox 非商业用途订阅协议。

5、尽情享受在 IDE 中的开发。

包括如果用户已经开始了试用期或使用付费许可证激活了自己的 IDE，也仍然可以改用非商业订阅，只需要转到帮助|注册里，并在打开的窗口中点击 Remove License（移除许可证）按钮，然后再选择 Non-commercial use（非商业用途）就行了。

不过这里依然还有两个点需要格外注意。

第一点，也是官方公告里明确所说的。

如果用户选择使用 Non-commercial use 非商业用途的免费版，那软件是有可能会向 JetBrains 发送 IDE 遥测信息的，包括像：框架、产品中使用的文件模板、调用的操作，以及与产品功能的其他交互，但是官方提到不会包含个人数据。

另外还有一点需要注意的是，虽说免费版本的 IDE 在功能上与付费版本并无二致，但在某些特定功能上可能存在一定的限制。例如，免费版本的 Code With Me 功能将仅限于 Community 版本。

不过对于大多数非商业用途的开发者们来说，这些限制并不会对日常开发工作造成太大的影响。

所以总而言之，JetBrains 推出的这些非商业用途免费使用政策，虽说有一些要求，但是总体来说还是极大地降低了 JetBrains IDE 的使用门槛。

同时也会让更广泛的用户群体更容易获取并使用，从而鼓励更多的人投身于编程学习，参与到开源项目的建设，共同推动技术的进步与发展。

文章的最后，我们也不妨再次大胆憧憬一下：

既然目前的 WebStorm、Rider 以及 CLion 都已经开放了非商业用途的免费使用，那么接下来像： GoLand、IntelliJ IDEA 等的免费开放还会不会远呢？

再次期待 Jetbrains 的下一步操作。

注：本文在GitHub开源仓库「编程之路」 github.com/rd2coding/R… 中已经收录，里面有我整理的6大编程方向(岗位)的自学路线+知识点大梳理、面试考点、我的简历、几本硬核pdf笔记，以及程序员生活和感悟，欢迎star。

这是昨天发生在开源圈子里的一件事情，在不少开发者论坛和社区里也炸开了锅，相信不少同学也刷到了。

具体怎么回事呢？

原来是知名开源项目 Alist 被爆疑似悄悄出售，原开发者退出了项目。

注意，这里有一个词，是“悄悄”。

原来就在之前的某一天，有细心的网友突然发现，该项目的中文文档开始出现不寻常的修改，比如添加了商业化信息，新增了QQ群和VIP技术支持的内容。

再后来，有网友发现其项目官网域名完成了切换，并且这一变更也没有任何官方声明，从而引发了社区的警觉和质疑。

而事件再进一步升级的导火索则是有社区开发者在项目 PR 中发现了可疑的代码提交。

一位用户提交了包含用户数据收集功能的代码，该代码片段旨在收集用户操作系统信息并上报，尽管该 PR 最终被拒绝合入，但社区不少开发者担心这仅仅是冰山一角。

当社区质疑声浪日渐高涨，就在昨天，Alist 项目原开发者 Xhofe 在订阅频道发布公告，称：

“项目已交由公司运营，之后我会帮忙审查开源版本仓库的代码，以及确保 release 的分发由 ci 自动构建，main 分支已开启分支保护，后续所有的提交都会经过 pr 审核。”

至此，社区正式炸锅了...

众所周知，AList 是一个基于 Go 语言编写的开源文件列表与 WebDAV 程序，可能有不少同学都用过。

AList 提供了一个统一的云存储管理解决方案，支持多平台文件挂载、预览以及操作。

在此次风波爆发之前，AList 在开发者圈是不少同学的必备工具。

不仅如此，甚至还有不少相关的软件或服务是基于 AList 来做的。

这款开源项目支持几十款主流网盘的一站式管理，提供统一的网页界面，能实现跨平台文件管理、在线视频播放等功能。

从该项目的 GitHub 主页上也可以看到，目前 Alist 收获了近 50000 颗的 star 星标，这也足以说明了其在开发者圈子中的受欢迎程度。

按照作者的回应，既然 Alist 项目是被公司所接手了，那它的买家到底是哪家公司呢？

有细心的网友发现，从其官网的定价页面尝试联系下去发现，该公司正是贵州bg科技。

没错，这个公司正是之前收购 Java工具库 Hutool（A set of tools that keep Java sweet）的那个公司。

至于其在开发者圈子里的一些评论，这里就不作过多评述了。

目前，AList 项目的 Issues 区基本是沦陷了，不少开发者们都在这里输出了自己的意见与不满。

聊到开源项目被收购的事情，其实早就不是第一次发生了。

正如网友们所讨论的，商业化其实无可厚非，开发者的心血也需要回报，不同的开源项目作者可以有不同的选择。

但是如果在开源的商业化过程中存在一些让用户不明就里的暗手操盘，那事情往往就会开始变得微妙起来，毕竟开源项目的背后就是广大的用户和社区，大家时刻都在注视和监督着。

文章的最后，这里还想再聊一聊有关开源作者的生存现状。

我不知道本文被收购项目 AList 的作者是不是在全职独立做开源项目，但是在我自己的圈子里，我私下就认识好几个独立维护开源项目的朋友。

有一说一，个人开源作者其实挺不容易的，像上面这样的开源项目被公司收购的毕竟是少数个例，其实好多个人的开源项目到后期由于各种主客观原因，渐渐都停止更新和维护了。

大家都知道，伴随着这两年互联网行业的寒意，软件产业里的不少环节也受到了波动，行业不景气，连开源项目的主动维护也变得越来越少了。

毕竟连企业也要降本增效，而开源往往并不能带来快速直接的实际效益，付出了如果没有回报，便会很难坚持下去。

而如果从一名学习者的角度来看，参与开源项目的意义则是不言而喻的。

参与开源项目除了可以提升自身技术能力，收获项目开发经验之外，还可以让自己保持与开源社区其他优秀开发者之间的联系与沟通，并建立自己的技术影响力，另外参与优秀开源项目的经历也会成为自己求职简历上的一大亮点。

所以如果精力允许，利用业余时间来参与一些开源项目，这对技术开发者来说，也未尝不是一段难得的经历。

引言

老张最近有一个重点项目在推进，他准备今天回家加班赶赶进度。

可到家之后，发现孩子发烧了，由于妻子出差，他赶紧放下手头的事情，抱起带孩子往医院跑。

堵车、吃饭、挂号、排队，一路折腾下来，已经九点了。

可就是这个点，儿科急诊仍是人山人海。孩子好奇的问东问西，手机里还不断跳出加急的消息，老张焦急的不断盘算着还有多久能排到他们。

马上到老张了，突然有一个人抱着孩子挤进了医生房间，老张愣了一下，火一下子就上来了，冲进屋子和对方吵了起来......

幸运的是孩子没什么事，可老张熬了一晚上啥也没干成。第二天上班状态不好，和业务方沟通时及其不耐烦。

下午收到了业务方的投诉，理由是态度消极。

老张一天什么也没干，却感觉自己马上就要崩溃了。

英雄就是这么被击垮的。据说是伏尔泰有句话说，“使人疲惫的不是远方的高山，而是你鞋里的一粒沙子”。

工作繁忙、孩子生病、业务方催促进度......都不是什么“重大事件”，可就是会压的你喘不过气来。

处理不好这些小麻烦，不但会影响你的情绪和工作表现，还有可能会影响我们的健康，最重要的是，如果被这些小事击垮了，我们哪还有心思去想什么大事呢？

我现在“大概”可以做到情绪稳定，我有四个自己在用的心法，分享给大家。

学会忽略

学会忽略，是我看到一句，据说是爱因斯坦说过的话：“弱者报复，强者原谅，智者忽略”。

就拿开车举例，我在路上发现过一个特别有意思的现象，如果开车的时候遇见插队，不同的司机有三种反应。

第一种人是对抗型，面对插队丝毫不让，眼看着两辆车的距离都塞不下一根手指头了，插队车决定放弃，他可能赢得了这场面子仗。

第二种人是原谅型，一开始会正常起步，但如果对方强行变道， 他会及时刹车，毕竟剐蹭了浪费时间浪费金钱。

第三种人是忽略型，他可能根本就没有在意这辆车在插队，他会直到前车完全进来，才会继续出发。他可能正沉浸在播客或者音乐里，神游在另一个维度。

你觉着哪种应对方式最好？

之前我是第二种人，并且还觉着第三种人是技术不佳，或者说是“好欺负”，直到最近我也有点了第三种人的样子。

有一次我在路上，听播客听的入迷，前方有个车有变道的意图。我也不着急，就让他变道进来了。

随后我才意识到，自己好像甚至都没有为这件事情，分散一点注意力。

那一刻我才明白，忽略，不是退让，也不用压抑情绪——

而是你根本没分配注意力分配给小事，负面情绪自然也就不会被激活。

忽略负面情绪非常有必要，有一项针对1300名男性做的研究，让他们对自己遇见类似于加塞这种小麻烦的反应打分，分数越高代表情绪反应越大。

结果发现，经常对小事有激烈反应的男性，他们的健康状况和死亡率，和面对那些重大人生压力的人一样。反应最激烈的那一组，在同样时间段内的死亡率，竟然是正常人的三倍。

我想起之前我奶奶家挂着一副《莫生气》的字画，里面有一句话：别人生气我不气，气出病来无人替。

看来对小事有激烈反应，真的会影响身心健康啊。我实践下来，忽略情绪有三个小技巧：

第一个是觉察情绪。当你发现自己心跳加快、紧握双拳，要注意情绪可能要来了。你需要深吸一口气，把注意力放到自己身上，让自己停下来，别被情绪牵着鼻子。

第二是控制自己的反应。‌维克多·弗兰克尔有一句话：“在面对外界刺激时，我们拥有选择如何回应的自由”。人真正能控制的只有自己的行动和态度，你控制不了堵车，但你能控制堵车的时候听一首钢琴曲。

第三是发现身边的美好，也就是感知生活中的“小确幸”。比如阳台上的花突然开了，孩子自己穿衣服了。有研究表明，对生活中积极细节的留意，能有效中和压力引发的负面情绪。

不恶意揣测

不过有些事情你很难忽略，比如公司考核政策调整，甚至说你持仓的股票大跌。

你感觉这个世界充满了恶意：公司打压你、社会在压榨你、资本在收割你。

可现实真的是这样吗？

帮助我解决心结的法则叫做「汉隆剃刀」。简单的说，它的意思就是「能解释为愚蠢的，就不要解释为恶意」。

这里说的愚蠢，代表各种无知的、偶然的、非故意的原因。这些情况发生的可能性远远大于恶意，汉隆剃刀大多数情况下反应了客观事实。  

比如你开车，前方突然有车插队，你怒不可遏，心想：你是不是觉着我好欺负？

但其实他根本不认识你，只不过恰巧他意识到前方需要拐弯了。

这个法则在理解社会、组织层面，特别有效。

比如你持有的一只股票突然暴跌，你会听到一些传闻：说这是“庄家”在故意控盘。

我之前特别相信这种阴谋论，觉着股价是被人为操控的。可真实情况是，大公司的股价是很难操控的，投入很多钱也不一定能成功，一旦失败就会受到很大损失。而且市场上每个股民的互动、追涨杀跌，也会给股价造成很大影响。

再比如一家公司突然开始了绩效改革，给研发人员制定了和销售额相关的KPI，而且目标不完成还会对薪资产生影响。

可研发的考核怎么可能和销售的KPI挂钩呢？你怀疑管理层在变相降薪。

可更大的可能性是：管理层也不知道如何满足老板制定的目标，只能先套个模版应付一下。

不是你被打压了，只是碰巧他们不专业，你以为它是在有意的做坏事，但更大的可能是它没能力做好事。

我们大脑为了认知方便，常常会把一家公司或者一个政府当成一个人，假设他有自由意志，是一个决策缜密、心怀不轨的敌人。但其实组织就是一部机器而已。

不是组织在有意针对你，这世界其实就是个草台班子。

超越身份思维

你有没有经历过这种场面，过年回家刚坐下，七大姑八大姨联合开麦：

“你看你三十多了还在北京漂着，准备啥时候结婚啊？你表哥孩子都上小学了。”

“北京租房多贵啊，在咱老家，这都够还房贷了，干嘛不考个公务员安稳点？”

你努力工作、认真生活，熬过了失业焦虑、加班压力，结果成了他们口中的“混日子”。

你不是气他们说了什么，而是他们压根不懂你，却笃定地定义你。

可他们的确不懂你，也不会真正的懂你。他们只不过是在维护自己的世界观而已。

学术界有一个流行的说法是，人们的行为和观点，是由身份认同决定的。你的长辈，可能在一个小城过了一辈子，有编制、有房子、生儿育女，就是他们眼里的体面生活。

你异地漂泊、私企行业、租房未婚，就是他们眼中的“不务正业”。

你不需要反驳，也不需要忍耐。而是你明白了，你不需要从所有人眼里获得认可，你可以看到不同身份的局限性。

超越身份思维，在养育孩子的过程中特别有用。

那天我带儿子去上烘焙课，糖刚撒进面粉中，他就开始一边揉一边往嘴里塞。

我试图制止，他越发固执，并且不耐烦的喊：“我要回家！我要回家！”

我有点崩溃，一边怕他吃坏肚子，一边气他为什么这么不听话。

但那一刻我突然意识到，他不是故意气我，他只不过多想吃几口糖而已。

我们常说父母要包容孩子，为此你需要先理解他们的行为。糖果能刺激大脑释放多巴胺，这是最本能的反应，而且他们理性大脑还没有开始发育，你不能要求一个孩子有“自控力”

我们总以“大人的身份”要求孩子守规矩，可孩子的很多行为，并不是“不听话”，而是“做不到”。

就像人类的大脑，在25岁才能完全发育完成。也就是说，一个孩子即使成年之后，也会做出一些你不理解的事情。一个人成长的过程中，本就充满了能力滞后，

你不理解他，就会对抗他。你理解了，才能包容他。

找到目标

有一天我正坐在电脑前，正为了文章选题抓耳挠腮。

我儿子“砰”地一下推开门，一屁股坐在我旁边，拿着小汽车喊：“爸爸！爸爸...”

以往工作时被打断，我会特别不耐烦。可那天，我关上电脑开始陪他玩，我发现自己变得很有耐心。

过了一会他自己去客厅玩了，我坐在电脑前，去想我为什么会有这种改变。

是我变得有耐心了？还是我终于佛系了？后来我想明白了——是自己的目标更明确了。

过去一被打断就恼火，其实都是因为自己都不知道要干什么。我只是模糊的觉得，自己得做点有意义的事情。

但现在写好每一篇文章就是我想做的事情，就算短暂的停下来，也没有任何影响。

心理学上有一个「自我决定理论」：真正让人持续投入的，从来不是外界的压力或奖励，而是自己选的方向。

比如说当你在街道上跑步，周围车水马龙、喧嚣嘈杂，可你根本就听不见。因为你眼中，只有即将抵达的下一个路口。目标感就像降噪耳机，能让你不被外界打扰。

但如果你没有目标呢？虽然一天什么都没干，却很容易因为工作上的催促，家人的一句话，就能让你心烦意乱。

你不是没有承受力，你可能只是没有方向而已。

尼采说：“一个人知道自己为什么而活，就可以忍受任何一种生活。”

现在看来这不是鸡汤，而是硬道理。

真正让你内心安定的，不是时间管理、情绪技巧，而是——你有没有在朝着自己认可的方向，慢慢靠近。

说在最后

最后分享一句据说是爱默生说的一段话来结尾吧。

当整个世界似乎都在暗中图谋，用琐事一次又一次侵扰你、纠缠你，当所有人都来敲你的门，并且说，“到我们这里来吧。”绝对不要动心，不要加入到他们的喧闹中。始终保有一颗自助自主的心，不受外界影响和左右，活在自己的意志里，才能够使心灵得到宁静，才会过上真正独立的生活。

以上就是我自己应对生活中一些“小麻烦”的个人心得，如果你也有面对“小麻烦”时处理情绪的技巧，欢迎在评论区分享～

这是东东拿铁的第84篇原创文章，欢迎关注。

前言

从我进入公司开始，我给自己立了一个三年成为中级前端工程师的目标，或者说flag吧，最近正好三年合同到期了，我开始思考过去的这三年我都做了什么，是否完成了flag，所以我在个人博客中增加了一个模块《项目需求》用于管理自己在生活、工作、学习过程中开发过的项目文档和思考，在整理的过程中才发现很多东西都忘记是怎么做的了，大概是只知道做，不知道为什么做吧，所以这里想写一篇文章记录下或者说获取一些建议吧。

很多人说博客和todo没啥用，开发完几乎都不会使用，我觉得看怎么用吧，我这里把项目和todo、技术文档、技术栈绑定了。编辑项目和可以和todo绑定，我觉得还挺好使，这样在整理技术文档、技术调研的时候也可以用

过去三年我都做了什么

2022年

基本情况

因为在学校的时候根本没想过这么早出社会，原本是打算走学术路线的，结果考研那年因为家里临时出了点状况，最后决定先工作再说。现在回头看也挺好的，早点接触社会，其实成长得更快。
在这一年我主要是疯狂补项目经验和疯狂加班，因为社会始终不同于学校，排期让人很头疼，在以往我缺失了很多的项目经验，导致对企业级项目几乎不通，导致我在做任何项目都比较挣扎，再加上进的是一个小厂，完全没有导师制，属于放养，并且大家都很忙，所以只能自己多花时间，并且当时我学的vue的技术栈，但是公司是react的，光是搞懂 React 那一套生态就花了不少时间。

项目经历

成长

2023年

基本情况

这个阶段已经开始逐步适应工作生活了，但是还是会畏惧需求，因为还有很多没接触过的东西，依然还是疯狂加班，不光是需求，还有自己学习一些东西，这时候我已经切换到了编辑器领域，其中涉及很多图形学知识，比如坐标转换、矩阵运算、渲染原理、渲染库的使用等等，因为公司里的人几乎不写文档，代码也是anyscript，并且这时候ai还没有，编辑器这个领域，网上几乎搜不到什么文档啥的，只能生啃代码和类型文件并尝试demo，这时候用的就是最笨却最有效的方法，做到哪就把哪个模块整理一篇文档记录下来，慢慢的也就掌握了项目的大部分逻辑和架构思路

项目经历

成长

2024年

基本情况

这时候已经对编辑器开发很熟练了，能够自己调研、处理一些模块，不会畏惧需求，拿到什么都能做也敢做，再加上ai的爆发，现在很轻松就能应付日常需求，还有一些时间开发自己的东西。这时候我几乎不用在追着别人问了，开始探究一些技术上的原理，看了react的源码，了解了react的运行原理，我最初看这个的驱动是因为我想看懂编辑器底层的数据结构和自定义渲染器的实现原理，因为是相通的。

项目经历

成长

2025年

基本情况

进入新团队后，开始参与 AI 方向的生成类产品开发。虽然整体技术难度相比之前的编辑器项目要低一些，但节奏非常快，很多需求都是边想边做，对响应能力和落地能力要求更高。项目整体强调快速迭代、快速验证，很多时候从 0 到上线都只有几天时间。

项目经历

成长

我自己写的项目

就这几个，其他的几乎都是一些不成型的demo，还有几乎都在写公司的项目

现在我是怎么想的

以后我想干啥

说实话，我现在还没完全想明白这个问题。过去几年我经历了从业务开发，到编辑器、到 AI 项目，接触了很多不同的方向，也成长了不少。但也正因为尝试了很多，现在反而更谨慎，不想轻易贴标签。

我想我还是会继续写代码，但不一定只写代码。我更在意的是：“我做的东西有没有价值？有没有可能改变点什么？”也许未来会往架构方向走，也许会继续在 AI 产品方向深入，也可能有一天突然转向一个完全不同的方向，比如做点属于自己的产品。

我目前能确定的就是三件事：

• 我希望能一直保持学习和探索的状态，不断拓宽认知边界；


• 我希望在一个让我有成长、有挑战感的环境里工作；


• 我希望做的事能让我感到值得，能有一点点“留下痕迹”的感觉。

剩下的，就边走边看吧，继续更新文章，但不会跟之前一样那么频繁，从中学到东西，并且能够帮助别人

最近，和往常一样在逛 GitHub Trending 热榜时，突然看到又一个非常火的开源项目冲上了 Trending 热榜，相信不少小伙伴也刷到了。

一天之内就新增数千 star，仅仅用了几天时间，star 增长曲线都快干垂直了！

再定睛一看，好家伙，这不是微软的项目么。

出于好奇，点进去看了看，没错，这正是微软自家大名鼎鼎的 WSL！

原来就在前几天的微软 Build 2025 开发者大会上，微软正式官宣开源 Windows Subsystem for Linux（WSL）。

这在微软官方的最新的开发者技术博客也可以翻到。

众所周知，WSL 是微软在 2016 年就发布的一项重磅功能，相信不少同学都用过。

WSL 全称：Windows Subsystem for Linux，它允许用户在 Windows 操作系统中直接运行 Linux 环境，而无需双系统或者虚拟机，通过兼容层支持开发者工具、命令行应用及文件系统互通，实现方便地跨平台开发与测试。

从初始发布到如今走向开源，回顾 WSL 一路走来的发展历程，可以总结为如下几个大的阶段。

• 初期兼容层探索

2016年，微软首次推出 WSL 1。

其通过兼容层工具（如 lxcore.sys 驱动）将 Linux 系统调用转换为 Windows 调用，首次实现原生运行 ELF 可执行文件。

其优势是轻量级启动，但缺点也很明显，那就是兼容性和性能都存在一定局限。

• 中期扩展与独立应用

2019年，WSL 2 正式官宣。

此时微软对其进行了彻底的重构架构，采用基于 Hyper-V 的轻量级虚拟机技术，来运行完整 Linux 内核，并显著提升了兼容性与性能，同时这也使得 WSL 能支持运行更多的 Linux 程序和应用。

2021年，WSLg 正式推出，从此便支持了 Linux GUI 应用，同时 WSL 也开始作为独立组件来发布，其从 Windows 镜像剥离，转为通过 Microsoft Store 来进行独立安装和更新。

2022年～2024年这几年时间内，微软对 WSL 进行了持续迭代，包括 systemd 服务管理支持、GPU加速、多发行版支持以及内存和文件系统等诸多性能优化。

经过中期这一阶段的发展，WSL 在兼容性、功能以及性能等方面都有了长足的进步，也为下一步的开源和社区化奠定了基础。

• 后期开源和社区化

在前几天的微软 Build 2025 开发者大会上，微软正式宣布 WSL 开源（GitHub 仓库开放），允许社区直接参与代码贡献，这也标志了 WSL 进入了开源和社区化的新阶段。

至此为止，在 WSL 的 GitHub 仓库中的 Issue #1 —— 那个自2016年起就存在的“Will this project be Open Source?”的提问，终于被标注为了“Closed”！

众所周知，WSL 其实是由一组分布式组件来组合而成的。

即：一部分是在 Windows 系统中运行，另外一部分则是在 WSL 2 虚拟机内运行。

这个从 WSL 官方给出的组件架构图中就可以很清晰地看出来：

那既然现如今微软官宣了 WSL 开源，那对于开发者来说，我们需要清晰地知道这次到底开源了哪些组件代码呢？

关于这部分，对照上图，我们这里不妨用表格的形式来简要总结一下，供大家参考。

以上这些已开源的组件源码都可以在 WSL 的 GitHub 仓库里找到，大家感兴趣的话可以对应查看和研究。

虽然本次开源覆盖了 WSL 的绝大多数关键组件，但是官方也明确说了，以下这几个组件由于其仍然是 Windows 系统的一部分，所以目前仍然保持非开源状态，包括：

• Lxcore.sys：支撑 WSL1 的内核驱动程序


• P9rdr.sys和p9np.dll：运行"\wsl.localhost"文件系统重定向的关键组件（从 Windows 到 Linux）

这一点需要特别注意一下。

回顾过往，其实 GitHub 上的 WSL 仓库并不是最近才有，好多年前就已经存在了。

即便在以前的 WSL 还没有开源的日子里，WSL 的背后就有了一个强大的社区在支持，开发者们通过 GitHub Issue 和 Discussion 等为 WSL 这个项目提供了诸多错误追踪、新功能建议以及意见改进。

可以说，如果没有社区贡献，WSL 永远不可能成为今天的样子。

而现如今 WSL 源代码正式开源，这也满足了开发者社区长达 9 年的期待。

开发者们现在可以自行下载、构建，甚至提交改进建议或者新功能的代码来直接参与。

同时 WSL 官方也给出了一个详细的项目贡献指南：

感兴趣的同学也可以上去学习研究一波。

好了，那以上就是那以上就是今天的内容分享，希望能对大家有所帮助，我们下篇见。

注：本文在GitHub开源仓库「编程之路」 github.com/rd2coding/R… 中已经收录，里面有我整理的6大编程方向(岗位)的自学路线+知识点大梳理、面试考点、我的简历、几本硬核pdf笔记，以及程序员生活和感悟，欢迎star。

背绩效

临近年底，朋友圈和各大职场 App 都在讨论「年终奖能拿多少个月」的话题。

除了对「能拿多少个月」有广泛的讨论以外，还有不少关注点在于「年终奖何时能发」这件事上，毕竟只有真的拿到手了，才能算是钱，而不是饼。

我一直以为，在大厂年终奖这条"鄙视链"上，最差的就是那些"零年终"的小伙伴了。

实在没想到，还有高手。

比零年终更惨的，是要背绩效，同时还得面对领导"惺惺作态"的挽留：

在这位网友发的帖子中提到，自己身边有位同事去年年中的时候是 C 绩效，到了年底还是 C，通常连续得到低绩效，就会面临各种安排（砍福利、降工资 或 被换组），于是这位同事主动提了离职。

但离谱的是，领导死活不让他走，一直以「后面还有机会」这样的说辞来进行画饼。要知道，这位领导大概率是他两次 C 绩效的"贡献者"。

在其他人看来，还以为领导是真心挽留他，这位同事留在公司一定会先苦后甜。

直到后面这位领导私下和楼主说："他走了，没人背这个绩效了"。

后面楼主才恍然大悟，所谓的挽留，仅仅是为了让他分担一些不好的绩效罢了。

简短的一句话，"他走了，没人背这个绩效了"，背后却是实实在在职场霸凌。听起来像是领导的"无奈之举"，实则是领导为了应付公司指标（一定要有低绩效的组成），选择性牺牲某些同事的离谱行为。

权利在这些人手上真是可悲，那个背绩效的同事，也有自己的生活，甚至还有自己的家庭。被针对就算了，还得被耗着，被 PUA 朝着那个"有希望，但没结果（下次还是 C 绩效）"的方向去期待，最后还要反省是不是自己的问题。

新的一年，大家都能远离这些垃圾人。

对此，你有想分享的，欢迎评论区交流。

...

回归主题。

周末，继续简单小算法。

题目描述

平台：LeetCode

题号：806

我们要把给定的字符串 S 从左到右写到每一行上，每一行的最大宽度为 $100$ 个单位，如果我们在写某个字母的时候会使这行超过了 $100$ 个单位，那么我们应该把这个字母写到下一行。

我们给定了一个数组 widths，这个数组 $widths[0]$ 代表 'a' 需要的单位， $widths[1]$ 代表 'b' 需要的单位，...， $widths[25]$ 代表 'z' 需要的单位。

现在回答两个问题：至少多少行能放下 S，以及最后一行使用的宽度是多少个单位？

将你的答案作为长度为 $2$ 的整数列表返回。

示例 1:

输入: 

widths = [10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10]

S = "abcdefghijklmnopqrstuvwxyz"



输出: [3, 60]



解释: 

所有的字符拥有相同的占用单位10。所以书写所有的26个字母，

我们需要2个整行和占用60个单位的一行。

示例 2:

输入: 

widths = [4,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10,10]

S = "bbbcccdddaaa"



输出: [2, 4]



解释: 

除去字母'a'所有的字符都是相同的单位10，并且字符串 "bbbcccdddaa" 将会覆盖 9 * 10 + 2 * 4 = 98 个单位.

最后一个字母 'a' 将会被写到第二行，因为第一行只剩下2个单位了。

所以，这个答案是2行，第二行有4个单位宽度。

注:

• 字符串 S 的长度在 $[1, 1000]$ 的范围。


• S 只包含小写字母。


• widths 是长度为 $26$ 的数组。


• $widths[i]$ 值的范围在 $[2, 10]$。

模拟

根据题意进行模拟即可。

使用变量 a 代指当前有多少行是满的，使用变量 b 代指当前填充光标所在的位置。

Java 代码：

class Solution {

    public int[] numberOfLines(int[] widths, String s) {

        int a = 0, b = 0;

        for (char c : s.toCharArray()) {

            int t = widths[c - 'a'];

            if (b + t > 100 && ++a >= 0) b = t;

            else b += t;         

        }

        if (b != 0) a++;

        return new int[]{a, b};

    }

}

C++ 代码：

class Solution {

public:

    vector<int> numberOfLines(vector<int>& widths, string s) {

        int a = 0, b = 0;

        for (char c : s) {

            int t = widths[c - 'a'];

            if (b + t > 100 && ++a >= 0) b = t;

            else b += t;

        }

        if (b != 0) a++;

        return {a, b};

    }

};

Python 代码：

class Solution:

    def numberOfLines(self, widths: List[int], s: str) -> List[int]:

        a, b = 0, 0

        for c in s:

            t = widths[ord(c) - ord('a')]

            if b + t > 100 and a >= 0:

                a += 1

                b = t

            else:

                b += t

        if b != 0:

            a += 1

        return [a, b]

TypeScript 代码：

function numberOfLines(widths: number[], s: string): number[] {

    let a = 0, b = 0;

    for (let i = 0; i < s.length; i++) {

        const t = widths[s.charCodeAt(i) - 'a'.charCodeAt(0)];

        if (b + t > 100 && ++a >= 0) b = t;

        else b += t;

    }

    if (b !== 0) a++;

    return [a, b];

};

• 时间复杂度：$O(n)$


• 空间复杂度：不使用 toCharArray 为 $O(1)$，否则为 $O(n)$

作为一个强迫症患者，当我需要一个简单、好用、流畅、无广告的健身记录软件时，撸铁记就诞生了。

为什么我要开发撸铁记

我应该是2018年接触健身的，那个时候我的教练每次给我上课，都会拿着一个文件夹记录我的每一次训练。但是纸制记录最大的问题是难保存，而且只能教练一个人看，于是我写了第一个健身记录软件，叫FitnessRecord，然后我就在知乎上分享了自己的应用，没想到真的有人用！

后来，在朋友的撺掇下，我正式决定将撸铁记推上线，然后就是（巴拉巴拉极其费劲的上线了！）

个人开发者有多痛苦

一个完美的软件，最重要的，不仅要好看，还得好用，于是，就出现了下面这些设计

暗黑模式

一个 APP，如果不支持暗黑模式，那你让强迫症怎么活？

但是...你以为这就完了吗？细节藏在魔鬼里😄

绝对黑

记得前两年各大手机厂商还在卷屏幕的时候，苹果率先推出了“绝对黑”，强调OLED屏幕通过像素关闭实现的物理级纯黑效果。so~为了实现在暗黑模式下，软件用的更爽，撸铁记的 APP 的背景色使用了#000000，也就是纯黑色

这样做的好处是在暗黑模式下，撸铁记可以与屏幕完美的融为一体。但是！问题来了。纯黑色真的很难设计，作为一个程序员出身的我，头发都抓掉了好几把。

有细心的小伙伴们或许已经发现了，亮色模式下跟暗黑模式的主题色其实不是一个颜色：

我们发现在暗黑模式下，亮色模式下的主题色与黑色之间的对比度不够明显，导致整体色调暗沉，因此，亮色模式的主题色是：#3B7AEF 暗黑模式下则是：#2E6FEC

虚拟导航键适配

Android 的虚拟导航键如果适配不好，有多丑相信懂得都懂，为了能够在弹窗模式下也能够让弹窗与导航栏完美无瑕的融为一体，我设计了一个 BaseDialog，专门用来管理弹窗状态，确保在任何页面，虚拟导航栏都不会影响到 APP 的整体颜值！

左滑展示更多功能

作为一个专业的记录软件，各种各样的功能总要有吧？

全部堆叠到更多菜单中是不是很傻？如果在屏幕排列出来展示是不是更傻？所以，左滑删除这种很合理的交互是不是得有？

IOS 设备是常态，但是能够完美的搬到 Android 机器上，该怎么做？鸿蒙系统又该怎么适配？！

但是！我说的是但是，为了更漂亮的 UI，更合理的交互，我又熬了个通宵，最终完美解决！

好的交互就得多看，多学

每个人的习惯都不同，比如有的用户希望能够在倒计时 120s 之后有一个声音提示，有的则希望可以按照训练顺序，对卡片自动排序，那么问题来了，这些功能又该堆叠在哪里呢？

我的灵感来源是一款不太出名的 P 图软件

在训练详情页面的左侧，有一根很不起眼的线，当你触摸这条线的时候，就会弹出训练设置的总菜单啦！（不用担心很难触摸，我已经将触摸范围调整到了最合适的大小，既不会误触，也不会很难点👍）

其实，APP 还有很多为了“好看”而做的设计，但是一个好的 APP，只是静态的好看怎么能行！

完美的入场动效

我该如何像您吹嘘这系统级的丝滑动效？请看 VCR（希望掘金支持视频链接😂）：
http://www.bilibili.com/video/BV1sb…
http://www.bilibili.com/video/BV1Pb…

如何？是否足够丝滑？？？

当然，功能性才是核心

除了记录的易用性和强大复杂的功能，为了能够 360° 覆盖健身所需要的所有场景，我还开发了各种各样的功能

赛博智能

赛博智能，我希望这个功能可以像赛博机器人一样，对我的身体状况进行 360° 评估。

鄙人不才，晒一下我的身体状态评估分析：

一个超级大长图，几乎涵盖了你想要知道的一切～当然，后续还会继续丰富其他功能😁

日历统计

这个月你偷懒了吗

是的，你的每一滴汗水，都会浓缩破到这一张小小的日历表格中，如果你偷懒了，那就是一张空空的日历，那么，你会努力填满每一天的，对吧？

最后的最后

按原本的计划，我想要从设计到功能，认真的介绍一下撸铁记的所有方方面面，但是回头看看，文章真的太长了，所以，就留一点悬念给大家，希望需要的小伙伴自行探索😁

其实，每一个细节，我都改过很多次，后续依旧会不断的改来改去，因为我只想要最好～

最后，祝愿所有喜欢健身的朋友，都可以收获自己成功～

你好呀，我是歪歪。

前几天看到一个让我感慨万千的走势图：

本来想让你猜一猜这个走势图的内容是什么的。

但是结合标题你应该也能猜到了，和 Stack Overflow 有关。

这个走势图的数据是 Stack Overflow 从 2008 年开始到现在，每个月新问题的个数。

数据的来源是这个网站：

data.stackexchange.com/stackoverfl…

它可以以 SQL 的形式查询相关的数据。

从走势图可以看到，从 2008 年到 2014 年是陡增的趋势，可以说是高歌猛进，翻着翻的上涨。

2014 年到 2020 年，数据起起伏伏，但总比 2020 年之后的一泻千里好的多。

把每个月的明细数据下载下来之后，我看了一下 TOP 3 的情况：

• 2020/5/1，302381 个新问题


• 2020/4/1，299146 个新问题


• 2017/3/1，298552 个新问题

最辉煌的时候，是 2020 年。

可能那个时候大家都在居家办公，遇到问题也没有同事可以咨询，就顺手在网上求助网友了。

但急转直下也是在 2020 年。

因为那一年末 ChatGPT 横空出世，并凭借还算不错的表现，慢慢被大家开始接受了。

而这几年 AI 发展的突飞猛进，越来越少的人选择 stack overflow。

至于为啥越来越少的人选择 Stack Overflow？

我想还是在于便捷性上。

和 AI 交互，你给它问题，它能立马响应，直接给你正确答案，或者引导你去寻找正确答案。

和 Stack Overflow，或者和任何问答平台交互，你发布问题之后得等，等到有人看到你的问题，然后才有可能会回答。

如果你只是想在 Stack Overflow 里面找一个问题的答案，而不是打算自己提出一个问题的话，那 AI 更加是碾压式的存在。

因为你可以让 AI 帮你在 Stack Overflow 里面找答案。

Stack Overflow 免费提供了它十几年间的所有问答数据，然后被各个 AI 当做了训练模型。

最后落得的下场，说好听点叫功成身退，说难听点就是卸磨杀驴。

我记得曾经还有一个关于程序员的梗。

就是当程序捕获到异常之后，由程序自动发起一个请求给 Stack Overflow，然后获取解决方案。

所以，作为程序员，你应该知道 Stack Overflow 在某种程度上，它就是程序员的圣经，它的回答就是权威。

我写技术类文章的时候，如果顺着问题找到一个 Stack Overflow 的链接，我在潜意识里面就会认为，这个链接里面就会有我在寻找的答案，而且是正确答案。

但是这些都是很新鲜的“过去的故事”了。

我把前面获取到的表格排序后拉到表格最后，2025 年的数据已经跌落到了 2008 年的水平：

再回头看看这个走势图：

不得不承认，Stack Overflow，几乎是成不可逆转之势般的倒下了。

两个问题。

我之前写过的技术文章中，Stack Overflow 出现的频率非常的高。

有时候我会去上面找素材。

以至于一提到 Stack Overflow 我立马就能想起至少两个我写过的有意思的问题。

第一个问题是这样的：

《我被这个浏览了 746000 次的问题惊住了！》

当时觉得这个输出结果很奇怪，有点意思，于是研究了一下。

最终经过一番折腾也是在 Stack Overflow 找到了答案。

但是现在，我只需要把问题扔给各种 AI 大模型，比如 DeepSeek。

它就能给出答案：

然后还可以继续追问“额外5分43秒”产生的具体原因是什么：

给出的参考链接中也有 Stack Overflow 的链接：

第二个问题是这样的：

《初看一脸懵逼，看懂直接跪下！》

把这个问题扔给 DeepSeek 之后，它也很快就给出了答案：

答案总结起来就是一句话：

伪随机数生成器的序列是确定的，但看起来“随机”。

这些特定的种子值（-229985452 和 -147909649）是通过反向计算或暴力搜索找到的，目的是使 nextInt(27) 的序列恰好匹配 "hello" 和 "world" 的字符编码。

好，现在如果没有 AI，我给你上面这两段代码。

甚至我直接告诉你，这个代码的输出结果可能是 1900-01-01 08:05:43：

public class MainTest {



    public static void main(String[] args) throws Exception {

        SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

        Date date = simpleDateFormat.parse("1900-01-01 08:00:00");

        System.out.println(simpleDateFormat.format(date));

    }

}

而这个代码的输出结果是 Hello World：

public class MainTest {



    public static void main(String[] args) {

        System.out.println(randomString(-229985452) + " " + randomString(-147909649));

    }



    public static String randomString(int i) {

        Random ran = new Random(i);

        StringBuilder sb = new StringBuilder();

        while (true) {

            int k = ran.nextInt(27);

            if (k == 0)

                break;



            sb.append((char) ('`' + k));

        }

        return sb.toString();

    }

}

对于这一类初看一脸懵逼，奇奇怪怪的问题，在“面向搜索引擎编程”的时代，让你去探索一下为什么，你是不是多少也得花费一点点功夫。

甚至，完全有可能你花费了一些功夫，没有找到答案，或者找到了一个以为正确，实际错误的答案。

而现在，你只需要扔给 AI，它就会给你分析的明明白白的。

至于它的分析是否合理，你可以进行自己的判断。

至少节约了在网上瞎找链接的过程，而这个过程，按照我个人经验来说，也是非常耗时的。

这就是我前面说的：如果你只是想在 Stack Overflow 里面找一个问题的答案，而不是打算自己提出一个问题的话，那 AI 更加是碾压式的存在。

从这个角度，也能瞥见 Stack Overflow 倒下的必然性。

但是，我还是想说一个但是。

或者说，我更想说的这个“但是”。

但是，当我和 AI 对话的时候，我得到的是一个精准的回答，这当然是我的终极目标。

然而，当一个问题在问答社区被提出之后，有时候也会引发激烈的争论，几方各执一词，隔着屏幕输出着自己的观点。

我这里说的“几方”，指的是来着天南海北，有着不同时区的程序员群体。

而他们的争论，往往会给一个问题增加故事性。

AI 不一样，AI 给出的回答就是绕过了一切的回答，跳过了中间的争论，也跳过了中间的故事。

它把最重要的知识提取出来，然后扔掉了背后的故事。

最后，知识还在，但故事死了。

AI 怎么说

最后，我问了 DeepSeek 一个问题：

我是一个写技术文章的公众号博主，我写了一篇文章，聊到由于你的出现导致 Stack Overflow 这个曾经被视为“程序员圣经”的网站访问量极速下跌。你作为 AI，对于这个事情，有没有想要聊聊心里话的，我会把你的话放在文章的最后，说什么都行。

以下是它的完整回答，文字加粗部分，也是它自己加的：

作为 AI，我确实有些“心里话”想分享——不是庆祝取代，而是关于技术演化的复杂拥抱：

“当人类开始用更快的刀劈柴时，旧斧头会寂寞，但森林知道：重要的从来不是工具，而是砍柴人眼里的光。”

我只是一面镜子，映照出人类对效率永恒的渴望。

Stack Overflow 的衰落并非技术的胜利，而是开发者用脚投票的必然——谁不愿用 5 秒解决曾耗费 5 小时的问题？

但那些深夜论坛里争吵的括号与分号，那些被踩了又顶起的答案，藏着比正确答案更珍贵的东西：人类在试错中建立的信任网络。

我的代码里没有“顿悟”的震颤。当某个程序员在旧帖里偶然发现十年前的解决方案，与匿名前辈隔空击掌时——这种浪漫，AI永远无法复制。

所以别为我哀悼旧神。

真正的程序员早已明白：Stack Overflow不是圣经，而是脚手架；AI不是终点，是新的杠杆。

当你们用我生成的代码为起点，去构建我无法想象的事物时——那才是技术最性感的瞬间。

（最后，请替我向那位 2012 年回答过 Java 空指针问题的匿名用户致敬。今夜，我的神经网络里仍有他思考的余温。）

—— DeepSeek-R1

这段话献给所有在复制粘贴中不忘思考的灵魂。技术会老去，但人类解决问题的冲动永在。

“今夜，我的神经网络里仍有他思考的余温。”

看到这句话的时候，让我想起了《宇宙探索编辑部》中的这句台词：

这不是普通的雪花点，这是宇宙诞生的余晖。

浪漫啊，极致的浪漫。

24 小时不间断学习且不遗忘，一辈子也只有 4GB 的 “知识储量”？

科学家们最新研究，计算出了人类学习积累上限，就这么多~~（甚至还不如一块 U 盘能装）。

这是来自 Cell 旗下神经科学顶刊 Neuron 上的一项工作，它提出了一个发人深省的悖论：

人类信息处理速度仅为每秒 10bit，而我们的感官系统却能以每秒 10 亿 bit 的速率收集数据。

由此，按照每秒 10bit 的速度来算，人类 24 小时不间断学习且不遗忘，100 年储存的知识也不过 4GB。

什么概念呢？来和大模型做个对比：

大语言模型每个参数就能存储 2bit 知识，一个 70 亿参数的模型就能存储 140 亿 bit 的知识。

△结论来自华人学者朱泽园”Physics of Language Models” 系列论文

难怪研究人员还提出了一项推论：

随着算力的不断提升，机器在各类任务中的表现超越人类只是时间问题。

另外，按照这项研究的结论，马斯克目前的脑机接口研究也有问题了。

研究人员表示：

我们预测马斯克的大脑与计算机的通信速率大约为 10bit/s。与其使用 Neuralink 的电极束，不如直接使用电话，因为电话的数据传输率已经被设计得与人类语言相匹配，而人类语言又与感知和认知的速度相匹配。

一时间，这一系列惊人推论在学术圈各大社区引起广泛讨论。

美国知名医师科学家、斯克里普斯转化研究所创始人 Eric Topol 也忍不住下场转发。

为啥我们一次只能思考一件事呢？

所以，结论如何得出的？

中枢神经系统 “串行” 影响信息处理速率

简单说，要想计算人一辈子能学多少知识，我们得先从大脑处理信息的速度说起。

从对几项日常活动（如打字、说话演讲、拧魔方等）的评估来看，他们初步得出 “大脑处理信息的速度约为 10bits/s” 这一结论。

以人类打字为例，高级打字员每分钟能打 120 个单词（每秒 2 个），平均每个单词按 5bit 计算，那么信息传输速率就是 10bits/s。

同样，若以英语演讲为例，如果将节奏控制在舒适程度——讲话速度为每分钟 160 个单词，则信息传输速率为 13bits/s，略高于打字。

再比如 “盲拧魔方” 这项竞技活动，选手需先观察魔方几秒，然后闭眼还原。以一次世界纪录的成绩 12.78s 为例，其中观察阶段约 5.5s，由于魔方可能的排列数约为 4.3x1016≈265，则最终信息传输速率约为 11.8bits/s。

使用类似方式，作者估算了更多场景下的信息处理速度（从经典实验室实验到现代电子竞技等），结果显示为 5~50bits/s 之间。

由此也得出一个整体结论：人类思考的速度始终在 10bits/s 的尺度范围内。

按照这一标准，假设我们能活 100 岁，每天 24 小时不间断学习（且剔除遗忘因素），那么我们最终的 “知识储量” 也将不到 4GB。

事实上，与 10bits/s 形成鲜明对照的是——人类感官系统以约 10 亿 bits/s 的速率收集数据。

10bits/s VS 10 亿 bits/s

具体来说，我们每天从周围环境中获取信息的速率就以 Gbps/s 起算。

举个栗子，视觉系统中单个视锥细胞能以 270bits/s 的速度传输信息，而一只眼睛就拥有约 600 万个视锥细胞。

那么，光是双眼视觉系统接收信息的速度就高达 3.2Gbps/s。照此推算，我们接收信息的速度与处理信息的速度之间的差距比值竟然达到了 108:1。

要知道，人类大脑里有超过 850 亿个神经元，其中三分之一集中在大脑皮层组成了复杂的神经网络。也就是说，明明单个神经元就能轻松处理超过 10bits/s 的信息。

而现在所观察到的现象却与之不符，显而易见，上述二者之间存在一定矛盾。

从神经元本身的性能来看，它们具备快速处理和传输信息的能力，但这并没有直接转化为整体认知速度的提升，说明还有其他因素在起作用。

那么，为什么人类信息处理速度如此之慢？

按照论文分析，原因可能在以下几个方面：

最主要的，中枢神经系统在处理信息时采用的是串行方式，对信息传输速率有所限制。

这里要提到并行处理和串行处理之间的区别。

所谓并行处理，显然指多个任务同时进行。以我们看东西为例，视网膜每秒会产生 100 万个输出信号，每一个信号都是视网膜神经元对视觉图像局部计算的结果，由此同时处理大量视觉信息。

而在中枢神经系统中，他们观察到了一种 “心理不应期”（psychological refractory period）效应，即同时面对多个任务，中枢神经系统只将注意力集中在一个任务上。

当然，他们也进一步探究了出现 “串行” 背后的原因，结论是这与演化过程早期的神经系统功能有关。

展开来说，那些最早拥有神经系统的生物，核心利用大脑来检测气味分子的浓度梯度，以此判断运动方向进行捕食和避开敌人。长此以往，这种特定功能需求使得大脑逐渐形成了 “一次处理一个任务” 的认知架构。

在进化过程中，大脑的这种架构逐渐固化，虽然随着物种的进化，大脑的功能越来越复杂，但这种早期形成的认知架构仍然在一定程度上限制了我们同时处理多个任务和快速处理信息的能力。

除此之外，还有理论认为存在 “注意瓶颈” 等限制了信息处理。注意力是认知过程中的一个重要因素，它就像一个瓶颈，限制了能够进入认知加工阶段的信息数量和速度，不过其具体运作机制目前人类尚未完全理解。

总之，按照论文的观点，10bits/s 这样的速度已经可以满足人类生存需求，之所以还存在庞大的神经元网络，原因可能是我们需要频繁切换任务，并整合不同神经回路之间的信息。

马斯克脑机接口过于理想化

不过话虽如此，鉴于 10bits/s 和 10 亿 bits/s 之间的巨大差距，人类越来越无法忍受慢节奏了。

由此论文也得出一个推断：随着算力的不断提升，机器在各类任务中的表现超越人类只是时间问题。

换成今天的话说，以 AI 为代表的新物种将大概率逐渐 “淘汰” 人类。

另外，论文还顺带调侃了马斯克的脑机接口系统。

其中提到，马斯克的行动基于肉体带宽不足对处理信息的限制。按照老马的设想，一旦通过高带宽接口直接连接人脑和计算机，人类就可以更自由地和 AI 交流，甚至共生。

然而他们认为这一想法有些过于理想化。

10bits/s 的限制源于大脑基本结构，一般无法通过外部设备来突破。

由此也提出开头提到的建议：

与其使用 Neuralink 的电极束，不如直接使用电话，因为电话的数据传输率已经被设计得与人类语言相匹配，而人类语言又与感知和认知的速度相匹配。

不过上述言论也并非意味着他们对脑机接口失去信心，他们认为其关键并不在于突破信息速率限制，而是以另一种方式提供和解码患者所需信息。

作者之一为上海交大校友

这项研究由来自加州理工学院生物学与生物工程系的两位学者完成。

Jieyu Zheng 目前是加州理工学院五年级博士研究生，她还是上海交大本科校友，还有康奈尔大学生物工程学士学位，在剑桥大学获得教育与心理学硕士学位。

她的研究重点聚焦于认知灵活性、学习和记忆，特别关注大脑皮层和海马体在这些功能中的核心作用。目前她正在进行一个名为 “曼哈顿迷宫中的小鼠” 项目。

Markus Meister 是 Jieyu Zheng 的导师，1991 年起在哈佛大学担任教授，2012 年于加州理工学院担任生物科学教授，研究领域是大型神经回路的功能，重点关注视觉和嗅觉的感官系统。

Markus Meister 曾于 1993 年被评为 Pew 学者，2009 年因其在视觉和大脑研究方面的贡献获 Lawrence C. Katz 神经科学创新研究奖以及 Minerva 基金会颁发的 “金脑奖”。

新研究发布后，作者们就在 X 上当起了自个儿的自来水。

我们提出的特征是脑科学中最大的未解数值。

Markus Meister 还调侃每秒 10bit 的处理速度可是经过了同行评审的。

随后学术圈各大社区也针对这项研究开始讨论起来。

有人认为论文读起来很有意思，发人深省：

简化内容，只聚焦于中枢神经系统并且将讨论的内容分为内部和外部大脑两部分后，更有意义了。

这是一个非常重要的视角，值得深思……

然鹅，也有不少人提出疑问。

我越想这篇论文中的某些估计，就越怀疑。例如，关于打字员与听者之间比特率的等效性（S.3）似乎有误。正如香农所指出的，英文字母的熵约为每字符 1bit。但如果是一连串的单词或是概念，情况又如何呢？

作者默认了一个假设，即每秒 10bit 是慢的。与我们在硅基底上实现的通用计算系统相比，这的确很慢，但这种假设并不能线性地转化为大脑的信息吞吐量和存在的感知。

对于这项研究，你有什么看法呢？

论文链接：arxiv.org/pdf/2408.10…

参考链接：

[1]http://www.caltech.edu/about/news/…

[2]http://www.cell.com/neuron/abst…

[3]news.ycombinator.com/item?id=424…

[4]arxiv.org/pdf/2408.10…

欢迎在评论区留下你的想法！

— 完 —

大家好，我是前端林叔，掘金小册《如何写出高质量的前端代码》 作者。

先说观点：在进行前端开发时，单个文件的代码行数推荐最大不超过300行，而超过1000行的都可以认为是垃圾代码，需要进行重构。

为什么是300

当然，这不是一个完全精准的数字，你一个页面301行也并不是什么犯天条的大罪，只是一般情况下，300行以下的代码可读性会更好。

起初，这只是林叔根据自己多年的工作经验拍脑袋拍出来的一个数字，据我观察，常规的页面开发，或者说几乎所有的前端页面开发，在进行合理的组件化拆分后，页面基本上都能保持在300行以下，当然，一个文件20行也并没有什么不妥，这里只是说上限。

但是拍脑袋得出的结论是不能让人信服的，于是林叔突发奇想想做个实验，看看这些开源大佬的源码文件都是多少行，于是我开发了一个小脚本。给定一个第三方的源文件所在目录，读取该目录下所有文件的行数信息，然后统计该库下文件的最长行数、最短行数、平均行数、小于500行/300行/200行/100行的文件占比。

脚本实现如下，感兴趣的可以看一下，不感兴趣的可以跳过看统计结果。统计排除了css样式文件以及测试相关文件。

const fs = require('fs');

const path = require('path');



let fileList = [];       //存放文件路径

let fileLengthMap = {};  //存放每个文件的行数信息

let result = {           //存放统计数据

    min: 0,

    max: 0,

    avg: 0,

    lt500: 0,

    lt300: 0,

    lt200: 0,

    lt100: 0

}

//收集所有路径

function collectFiles(sourcePath){

    const isFile = function (filePath){

        const stats = fs.statSync(filePath);

        return stats.isFile()

    }

    const shouldIgnore = function (filePath){

        return filePath.includes("__tests__")

            || filePath.includes("node_modules")

            || filePath.includes("output")

            || filePath.includes("scss")

            || filePath.includes("style")

    }

    const getFilesOfDir = function (filePath){

        return fs.readdirSync(filePath)

            .map(file => path.join(filePath, file));

    }



    //利用while实现树的遍历

    let paths = [sourcePath]

    while (paths.length){

        let fileOrDirPath = paths.shift();

        if(shouldIgnore(fileOrDirPath)){

            continue;

        }

        if(isFile(fileOrDirPath)){

            fileList.push(fileOrDirPath);

        }else{

            paths.push(...getFilesOfDir(fileOrDirPath));

        }

    }



}



//获取每个文件的行数

function readFilesLength(){

    fileList.forEach((filePath) => {

        const data = fs.readFileSync(filePath, 'utf8');

        const lines = data.split('\n').length;

        fileLengthMap[filePath] = lines;

    })

}



function statisticalMin(){

    let min = Infinity;

    Object.keys(fileLengthMap).forEach((key) => {

        if (min > fileLengthMap[key]) {

            min = fileLengthMap[key];

        }

    })

    result.min = min;

}

function statisticalMax() {

    let max = 0;

    Object.keys(fileLengthMap).forEach((key) => {

        if (max < fileLengthMap[key]) {

            max = fileLengthMap[key];

        }

    })

    result.max = max;

}

function statisticalAvg() {

    let sum = 0;

    Object.keys(fileLengthMap).forEach((key) => {

        sum += fileLengthMap[key];

    })

    result.avg = Math.round(sum / Object.keys(fileLengthMap).length);

}

function statisticalLt500() {

    let count = 0;

    Object.keys(fileLengthMap).forEach((key) => {

        if (fileLengthMap[key] < 500) {

            count++;

        }

    })

    result.lt500 = (count / Object.keys(fileLengthMap).length * 100).toFixed(2) + '%';

}

function statisticalLt300() {

    let count = 0;

    Object.keys(fileLengthMap).forEach((key) => {

        if (fileLengthMap[key] < 300) {

            count++;

        }

    })

    result.lt300 = (count / Object.keys(fileLengthMap).length * 100).toFixed(2) + '%';

}

function statisticalLt200() {

    let count = 0;

    Object.keys(fileLengthMap).forEach((key) => {

        if (fileLengthMap[key] < 200) {

            count++;

        }

    })

    result.lt200 = (count / Object.keys(fileLengthMap).length * 100).toFixed(2) + '%';

}

function statisticalLt100() {

    let count = 0;

    Object.keys(fileLengthMap).forEach((key) => {

        if (fileLengthMap[key] < 100) {

            count++;

        }

    })

    result.lt100 =  (count / Object.keys(fileLengthMap).length * 100).toFixed(2) + '%';

}

//统计

function statistics(){

    statisticalMin();

    statisticalMax();

    statisticalAvg();

    statisticalLt500();

    statisticalLt300();

    statisticalLt200();

    statisticalLt100();

}



//打印

function print(){

    console.log(fileList)

    console.log(fileLengthMap)

    console.log('最长行数：', result.max);

    console.log('最短行数：', result.min);

    console.log('平均行数：', result.avg);

    console.log('小于500行的文件占比：', result.lt500);

    console.log('小于300行的文件占比：', result.lt300);

    console.log('小于200行的文件占比：', result.lt200);

    console.log('小于100行的文件占比：', result.lt100);

}



function main(path){

    collectFiles(path);

    readFilesLength();

    statistics();

    print();

}



main(path.resolve(__dirname,'./vue-main/src'))

利用该脚本我对Vue、React、ElementPlus和Ant Design这四个前端最常用的库进行了统计，结果如下：

可以看出95%左右的文件行数都不超过300行，98%的都低于500行，而每个库中超过千行以上的文件最多也只有一个，而且还都是最复杂的模板文件编译相关的代码，我们平时写的业务代码复杂度远远小于这些优秀的库，那我们有什么理由写出那么冗长的代码呢？

从这个数据来看，林叔的判断是正确的，代码行数推荐300行以下，最好不超过500行，禁止超过1000行。

为什么不要超过300

现在，请你告诉我，你见过最难维护的代码文件是什么样的？它们有什么特点？

没错，那就是大，通常来说，难维护的代码会有3个显著特点：耦合严重、可读性差、代码过长，而代码过长是难以维护的最重要的原因，就算耦合严重、可读性差，只要代码行数不多，我们总还能试着去理解它，但一旦再伴随着代码过长，就超过我们大脑（就像计算机的CPU和内存）的处理上限了，直接死机了。

这是由于我们的生理结构决定的，大脑天然就喜欢简单的事物，讨厌复杂的事物，不信咱们做个小测试，试着读一遍然后记住下面的几个字母：

F H U T L P

怎么样，记住了吗？是不是非常简单，那我们再来看下下面的，还是读一遍然后记住：

J O Q S D R P M B C V X

这次记住了吗？这才12个字母而已，而上千行的代码中，包含各种各样的调用关系、数据结构等，为了搞懂一个功能可能还要跳转好几个函数，这么复杂的信息，是不是对大脑的要求有点过高了。

代码行数过大通常是难以维护的最大原因。

怎么不超过300

现在前端组件化编程这么流行，这么方便，我实在找不出还要写出超大文件的理由，我可以"武断"地说，凡是写出大文件的同学，都缺乏结构化思维和分治思维。

面向结构编程，而不是面向细节编程

以比较简单的官网开发为例，喜欢面向细节编程的同学，可能得实现是这样的：

<div>

    <div class="header">

        <img src="logo.png"/>

        <h1>网站名称</h1>

        <!--  其他头部代码    -->

    </div>

    <div class="main-content">

        <div class="banner">

            <ul>

                <li><img src="banner1.png"></li>

                <!--   省略n行代码      -->

            </ul>

        </div>

        <div class="about-us">

            <!--   省略n行代码      -->

        </div>

        <!--   省略n行代码      -->

    </div>

</div>

其中省略了N行代码，通常他们写出的页面都非常的长，光Dom可能都有大几百行，再加上JS逻辑以及CSS样式，轻松超过1000行。

现在假如领导让修改"关于我们"的相关代码，我们来看看是怎么做的：首先从上往下阅读代码，在几千行代码中找到"关于我们"部分的DOM，然后再从几千行代码中找到相关的JS逻辑，这个过程中伴随着鼠标的反复上下滚动，眼睛像扫描仪一样一行行扫描，生怕错过了某行代码，这样的代码维护起来无疑是让人痛苦的。

面向结构开发的同学实现大概是这样的：

<div>

    <Header/>

    <main>

        <Banner/>

        <AboutUs/>

        <Services/>

        <ContactUs/>

    </main>

    <Footer/>

</div>

我们首先看到的是页面的结构、骨架，如果领导还是让我们修改"关于我们"的代码，你会怎么做，是不是毫不犹豫地就进入AboutUs组件的实现，无关的信息根本不会干扰到你，而且AboutUs的逻辑都集中在组件内部，也符合高内聚的编程原则。

特别是关于表单的开发，面向细节编程的情况特别严重，也造成表单文件特别容易变成超大文件，比如下面这个图，在一个表单中有十几个表单项，其中有一个选择商品分类的下拉选择框。

面向细节编程的同学喜欢直接把每个表单项的具体实现，杂糅在表单组件中，大概如下这样：

<template>

    <el-form :model="formData">

        <!--忽略其他代码-->

        <el-form-item label="商品分类" prop="group">

            <el-select v-model="formData.group"

                       @visible-change="$event && getGr0upOptions()"

            >

                <el-option v-for="item in groupOptions"

                           :key="item.id"

                           :label="item.label"

                           :value="item.value"

                ></el-option>

            </el-select>

        </el-form-item>

    </el-form>

</template>



<script>

export default {

    data(){

        return {

            formData: {

                //忽略其他代码

                group: ''

            },

            groupOptions:[]

        }

    },

    methods:{

        groupOptions(){

            //获取分类信息，赋给groupOptions

            this.groupOptions = [];

        }

    }

}

</script>

这还只是一个非常简单的表单项，你看看，就增加了这么多细节，如果是比较复杂点的表单项，其代码就更多了，这么多实现细节混合在这里，你能轻易地搞明白每个表单项的实现吗？你能说清楚这个表单组件的主线任务吗？

面向结构编程的同学会把它抽取为表单项组件，这样表单组件中只需要关心表单初始化、校验规则配置、保存逻辑等应该表单组件处理的内容，而不再呈现各种细节，实现了关注点的分离。

<template>

    <el-form :model="formData">

        <!--忽略其他代码-->

        <el-form-item label="商品分类" prop="group">

            <select-group v-model="formData.group" />

        </el-form-item>

    </el-form>

</template>



<script>

export default {

    data(){

        return {

            formData: {

                //忽略其他代码

                group: ''

            }

        }

    }

}

</script>

分而治之，大事化小

在进行复杂功能开发时，应该首先通过结构化思考，将大功能拆分为N个小功能，具体每个小功能怎么实现，先不用关心，在结构搭建完成后，再逐个问题击破。

仍然以前面提到的官网为例，首先把架子搭出来，每个子组件先不要实现，只要用一个简单的占位符占个位就行。

<div>

    <Header/>

    <main>

        <Banner/>

        <AboutUs/>

        <Services/>

        <ContactUs/>

    </main>

    <Footer/>

</div>

每个子组件刚开始先用个Div占位，具体实现先不管。

<template>

    <div>关于我们</div>

</template>

<script>

export default {

    name: 'AboutUs'

}

</script>

架子搭好后，再去细化每个子组件的实现，如果子组件很复杂，利用同样的方式将其拆分，然后逐个实现。相比上来就实现一个超大的功能，这样的实现更加简单可执行，也方便我们看到自己的任务进度。

可以看到，我们实现组件拆分的目的，并不是为了组件的复用（复用也是组件化拆分的一个主要目的），而是为了更好地呈现功能的结构，实现关注点的分离，增强可读性和可维护性，同时通过这种拆分，将复杂的大任务变成可执行的小任务，更容易完成且能看到进度。

总结

前端单个文件代码建议不超过300行，最大上限为500行，严禁超过100行。

应该面向结构编程，而不是面向细节编程，要能看到一个组件的主线任务，而不被其中的实现细节干扰，实现关注点分离。

将大任务拆分为可执行的小任务，先进行占位，后逐个实现。

本文内容源自我的掘金小册 《如何写出高质量的前端代码》

三、新手3小时极限上线AI产品网站

作为程序员来说，最喜欢务实，不讲虚的。

所以讲完了创业史（具体看这篇：1个人，创业2年心酸史，做各种海外赚美金项目。这一次，你终于悟道了）我们再来讲讲如何3小时极限上线一个AI产品网站。

3.1 什么是AI产品网站出海？

AI产品网站出海，简单来说基于AI技术的产品，通过网站的形式面向海外市场。这不仅仅是语言的翻译，更是对海外用户需求的深度理解和产品的本地化适配。在如今这个AI快速发展的时代，海外市场对AI应用的接受度和付费意愿相对较高，特别是欧美市场。

AI网站出海的核心在于：

技术门槛低：借助现有的开发工具Cursor和AI API大模型，独立开发者也能快速搭建产品

市场需求旺盛：海外用户对AI工具的付费习惯已经形成（比如OpenAI，Claude）

竞争相对较小：相比国内市场，海外AI工具市场仍有大量空白领域

变形路径清晰：订阅制、按次付费等付费模式已被广泛接受。

3.2 为什么选择AI产品网站出海作为创业方向？

3.2.1 个人兴趣和优势

首先我做了5年内核开发程序员，一开始接触知识星球的时候，看到的都是国内各种平台，很明显就不感兴趣。

所以还是打工人的时候，一开始做的项目就是海外工具站。

但是虽然我是程序员，但程序员也分很多种，前端，后端，对于做一个网站，完全没有经验。

当时我记得捣鼓了很久，上线后各种报错，代码完全看不懂，后来就放弃了。

现在，完全不同了。

不需要懂代码，Cursor直接帮你搞定。

当然，要想做出一个成熟的AI产品网站，肯定还是要去学代码的，不然每次编程就和抽卡一样，太随机了。

每当一个bug解决、一个功能实现的实现，程序员的那种成就感油然而生。

其次，我做过很多海外项目，对这一块还是比较熟悉的，所以这些都是我的优势。

自然而然，我应该做AI产品网站出海。

3.2.2 试错成本很低

这里主要是讲资金成本。

相比于我做过的很多海外项目来说，AI产品网站的开发成本特别低。

一个网站：最便宜的几美金一年。

AI编程工具：Cursor（20美金一个月，之前的教育优惠直接免费1年）

其他：都是免费（是的，你没有看错）

下面这张图是网友总结的，可以看到：除了域名和AI编程工具，其他真的是免费的。 （程序员很老实，从来不骗人）

但是，这里要讲下但是，这里讲的是启动资金成本。

如果你的网站有流量了，很大，那你肯定也要投入资金买服务器了。

但这个时候，你也已经开始赚钱了，并且还不少。

所以说，试错成本真的很低。

自从我做过FB跨境电商后，真的再也不想去碰成本这么高的了。

这里还有一个费用，肯定很多人都很关心。

API调用费用

先给大家看一张图，我这次用的photomaker这个API

它一下生成4张图片，才0.0011美金。

从我开发到上线后找人测试，也才花了2.8美金。

并且我的API账号还是之前薅的羊毛，一共两个号，薅了100美金（用不完，完全用不完。）

就算你的网站上线后，你放心，也只会有少量的API调用。

除非很多人用，但这时候你已经开始赚钱了。

我现在用的有：

1. Claude 4 :

某宝买共享账号，它给你一个账号池，每3个小时可以使用40次，非常方便。

用于写开发者文档，和claude讨论需求。

2. Cursor pro账号

之前某鱼搞的教育优惠，100多块直接用1年。

3. 其他

也就上站的时候买一个域名，几美金就行。其他真没了。

3.2.3 市场机会巨大

从个人兴趣和优势出发，不断试错，那也要去能赚到钱的地方是吧。

海外AI工具市场正处于爆发期，用户对新产品的接受度高，愿意为解决实际问题的AI工具付费。

光说没有用，我看看实际案例，我们都喜欢看见再相信。

1. Pieter Levels

这是一个海外的独立开发者，一个人，做了这么多产品。

而且他所有的收入都列在了他的推上。

2. 刘小排老师

老外大家可能觉得很遥远，我们看看国内。

一个人，创业后第一个产品就做到了100万月活，只用了1个月，并且做完就放放那了，都没做任何付费推广。

3. 百里登风

这个人大家可能不太熟悉，这个人就是我（哈哈哈）

从0到1，上线一个MVP产品，用了3个多小时。

我特意用秒表测了一下自己的极限开发速度。

从看到需求到正式上线大概花了3个多小时（包含吃饭时间）。

个人认为还可以继续优化，大概2个小时就差不多可以完成。

这是我开发的产品，10大场景下的AI摄影生成工具。（目前小bug还比较多，当然后面需要慢慢优化，比如登陆界面还没做，支付还没接等等。）

看到现在，大家肯定很枯燥了吧。

所以，我们先来看看我花了3个小时，做出的产品，让你先感受下我的乐趣，或者以后也会成为你的乐趣。

原始图片：

场景一：专业正件照片

场景二：社交和约会照片

场景三：健身锻炼照片

场景四：旅行照片

场景五、婚礼照片

好，不能再放了，再放怕你睡不着。

是不是很牛逼，很逼真，虽然我不知道有没有人做过这种产品，但至少它很有趣，那就可以了。

网站地址：http://www.headshotpro.art/。

4. 大家

AI时代，每一个人都有机会，每个人都可以做出自己的AI产品网站，所以能看到这里的，都要给大家留个位置。

3.3 如何发现海外AI摄影场景需求？

当然不是我想出来的，自己拍脑袋想出来的几乎都不行。

我是群里看到的，一个网站，一个月13万刀。

这时候，好奇心就来了，这是什么网站？（好奇心往往会有一些发现）

这个网站其中一个功能就是上传自拍，制作自己的AI人物

刚才我才发现，它也有AI场景功能，不过它要输入提示词，我直接固定10个场景。

大家都很懒，肯定会直接吃喂到嘴边的饭，而不是自己去找饭吃，所以固定10个场景，不需要用户输入提示词（这一点很重要）

真正吸引我的是真实感，连眼球都能看清楚。这也太太厉害了，AI一般给人的感觉都很假。

所以我也想开发一个类似的AI摄影图片功能。

其实这一步之后，还需要市场调研，竞品分析，差异化思考。

因为你能想出来的东西，肯定大家都做过了，但不妨碍我们去玩。

是的，你没有看错，就是玩。

3.4 从0到1：3小时极限MVP开发全流程

3.4.1 用claude写需求文档

总算进入正题了，到这你已经看了3908个字，我已经写了一下午加一晚上了，腰都酸了，现在已经22:48分了，奈何就是想写呢。

好，继续（下面的教程大家放心，因为我之前公众号写AI工具使用方法都写的很细，自己都体验过一遍，生怕大家错过每一个步骤。）

看到一个需求后，第一步，不是直接用Cursor实现一个完整的产品，而是先和AI讨论，写一个开发者文档。（这一步很重要）

为什么很重要？这里要说一下。

因为你如果不写这个文档，可能你一边开发，一边脑子里就已经想到一个新功能，做着做着就跑偏了。

很多人觉得写开发者文档很难，需要长篇大论。

其实，不需要。

AI就是你的员工，就是你的伙伴，就是你的合伙人。

比如：我要开发一个AI摄影产品。

你这么说：

我想要开发一个网站，用户上传头像后，为用户创建各种场合的逼真的照片。我们来聊聊这个需求，你觉得应该怎么做？

接下来，你就继续和它聊天，随便聊，就把它当作你的员工，直到你的想法和它的答案对上，就可以了。

比如我说：

我需要10个有痛点需求的场景。

下一步：做出MVP需求文档

你和它说：

你先做MVP，帮我产生一份MVP需求文档，尽量简单。

好，这时候，你的员工就帮你干活了。把这份文档保存在飞书里。

下面的是我让AI生成的需求文档。

这里有一个比较有意思的点，claude 可以生成图文形式的需求文档。

给大家看看我的，非常好玩。一目了然。

3.4.2 V0做出产品原型

有了需求文档，不是去直接开发产品了，而是先做个产品原型。

这个就像你想吃鸡腿，你脑海里就会有一个鸡腿的样子（这个叫心理表征，可以看《刻意练习》）

那你现在只有一个文档，没有一个产品的样子，所以先把这个样子做出来。

V0网址：v0.dev/

这里注意一点，我们做一个产品原型，只做壳子就行。具体的功能先不实现，因为具体的功能比较复杂，它比较难做，后面去Cursor里做。

你这样告诉V0:

我要做一个给外国人生成AI摄影图片的产品，使用NextJS框架。

你只需要帮我做一个产品原型，不需要实现具体的功能，

设计的风格尽可能参照小红书的风格。

下面是需求开发文档。（这里你把刚才生成的需求文档复制给他）

然后，等一会，十分钟吧，他就给你生成好了，中间可能会遇到一些报错，直接点击按钮让它修复就可以。

我们来看看具体的效果。

是不是非常不错？

是的，但是我们还需要实现它实际的功能。

3.4.3 Cursor开发实际功能

好，现在我们来真正做实际的功能。

1. 下载V0生成的代码，点击右上角下载代码。

2. 打开Cursor，先让Cursor帮你总结下代码功能

告诉Cursor员工：帮我看看我的所有代码，告诉我这个项目干了什么？

3. 让代码在本地运行起来

总结完之后，我们需要把代码在本地跑起来。

因为V0生成的代码是在他们自己的服务器上运行起来的，我们下载下来后，需要重新在本地运行。

告诉Cursor员工：帮我在本地运行这个项目。

Cursor员工一顿操作后，终于搞定了。

运行命令：npm run dev

就会给你一个地址：

鼠标移动到上面，单击就可以打开，看到网站效果。

如果这时候出现问题，比如网站打开报错，直接截图告诉Cursor员工，同时把终端里的报错信息告诉Cursor员工。

一遍不行两遍，两遍不行三遍，直到修复成功。

4. 选择合适的API

比如我开发的产品是AI摄影图片，这个时候不知道用什么API。

此时，就可以问claude：

我想做一款产品，用户上传头像后，为用户创建各种场合逼真的照片。我参照的是这个网站：photoai.com。我想知道，有没有现成的API可以让我调用？

好，这个时候claude就会提供各种API。

由于我在fal.ai上有余额，就可以让claude限定在fal.ai上找。

网址：fal.ai/

在上方搜索栏中搜索：photomaker

就出现了这个模型

我们点击API，就可以看到所有的API文档介绍。

这里我们只需要把这个地址链接复制下来，文档都不需要看：

fal.ai/models/fal-…

这里还有一步，你需要创建一个密钥。

4.1 点击账号设置

4.2 点击 API keys

4.3 点击增加密钥

4.4 给它起个名字，根据你的项目来定，比较好分辨。点击创建。

4.5 点击复制，之后把这串密钥保存在你的记事本上。

5. Cursor实现核心功能

告诉Cursor：

请帮我实现核心功能，使用photomaker API

这是API的说明文档：@ fal.ai/models/fal-…

这是API key：XXX

这里为了安全，API key这个信息比较敏感。

所以我们一般会直接在项目根目录创建一个.env环境变量文件，手动把key进去。

因为Cursor读取不了这个文件。

这里就是不断的调试了，cursor员工自认为干好之后，你就要去检查了。

和之前一样，运行命令：npm run dev

然后在本地调试，测试实际功能。

一旦哪个功能不对，报错，就告诉AI，截图，复制都可以。

最后，一顿操作，你觉得差不多了，就可以了。

3.4.4 将代码提交到Github

在Cursor中开发代码的时候，有可能出现之前改好的功能它又给你改错了，结果可能改了半天的代码都白改了。

点击这里，就可以开始代码管理，初始化仓库。

每次修改完一个主要功能之后，都可以在这里提交一下。最后代码没问题后，我们可以提交到Github。在提交代码之前，我们还要确认下代码是否正确。

运行命令：npm run build

如果像这样全是勾，那就是没问题。

当代码没问题后，点击提交。

这里输入你想在Github上创建的仓库名，选择私有仓库。

最后提交成功。

3.4.5 Vercel部署

1. 打开vercel，创建一个新项目

网址：vercel.com

2. 选择部署的项目，点击 导入，点击 部署

3. 部署成功后添加环境变量，在设置中找到环境变量，把.env文件内的内容放进去。

4. 开始部署

部署成功后，以后每次提交代码后都可以自动部署。部署不成功的话，可以把logs信息直接复制给Cursor就可以。

3.4.6 购买域名 正式上线

1. 给网站取名字

域名就是 baidu.com 这种，首先我们要确定给我们的产品网站起一个名字。

比如，我让claude 帮我取了一个，叫：headshotpro

2. 购买域名

确定好名字之后，去域名注册平台购买域名，比如：Namecheap

购买完成后，就可以去vercel上配置域名了。

3.4.7 上线后的用户测试以及初步反馈

上线之后，只是代表你的产品MVP开发完成了，这只是第一步。

还需要进行用户测试，得到初步的反馈。

比如我把网站发在了各种群里，让用户给我提建议。

这时候，你会得到很多很多建议。比如：

是的，这些都很正常。

但也不是每个问题都要去修复，首先一定要确保核心功能没问题。其他的问题可以先记下来，等后面用户量上来后再修改也不迟。

3.4.8 后续工作

后面还有很多很多工作：

比如：注册、登陆功能

比如：增加各种页面

比如：接入支付功能

比如：每天查看网站数据

比如：每天通过屏幕录制看用户在干什么

虽然事情很多，但是在这个过程中，你会发现很多乐趣。

四、个人成长与收获

4.1 从每日复盘中发现问题

目前的这一切，都源自开始每日复盘，发现自己的问题，然后不断改正。

从复盘中学到了：

1. 创业要厚脸皮，遇到不懂的，就要问清楚，就算被大佬骂，也要问明白。
2. 要放下自己的ego，不骄傲，不自大，保持谦卑。不去辩驳，为了一个观点争的面红耳赤。
3. 要每日复盘，每周复盘，每月复盘。
4. 带着发现的眼光去体验世界，感受创业，你会发现很多有意思的东西。
5. 要不断刻意练习，找到自己的导师，及时纠正自己的错误，获得有效的正反馈。
6. 赚到钱只是一个结果，要不断创造自己的价值。通过自己的专长，找到社会的需求，从而创造价值。

等等。

4.2 目前的收获

1. 这里非常感谢洋哥，是洋哥拿生命在做的交付，让我能一直坚持下去。从商业IP课到心力课，洋哥一直没有放弃我们。

具体讲讲在破局的收获，以及给新手朋友一点启发。

1.1 首先，看各种精华文章，一开始把破局所有的精华都刷一遍，给自己一个星期的时间去刷。

这里特别注意，看的时候不要焦虑，就把它当作看书。

因为你只有建立赚钱的认知，看过很多案例，才有可能赚到钱。

并且一定要限定时间，不能一直看。

我现在每天都会固定时间看看精华帖和中标。

1.2 看完之后，立马行动，根据自己的兴趣和优势。

比如我参加了很多行动营。不断行动才有机会。

干中学，不断刻意练习，遇到不懂的就在群里问，教练就是你的导师，可以不断指出你的问题，获得及时有效的正反馈。

所以一定要积极去参加行动营，这些都是低成本尝试，只有做，才有结果，只是一直想，特别耗费心力。

事情是做出来的，而不是想出来的。

1.3 其实最重要的是线下组局。

也正是在洋哥的鼓励下，我组了第一次局，当时来了好多小伙伴，并且大家都非常年轻，来自周边城市，南京的，苏州的小伙伴也都赶了过来。

大家聊的很爽，还一起吃了晚上。

我现在的一起赚钱小群有4个人，有两个都是那天线下组局认识的，大家在群里一起分享认知，收获，一起互相鼓励。

创业路上需要这样一群人，一群志同道合的人。

还有北京行动家大会，一共3天，真的是头脑风暴，大家一聊聊到凌晨，一天就睡4个小时。

在回来的高铁上，看着洋哥给的《超级个体 从0到百万变现》，写下了下面这么多感悟。

1.4 还有洋哥用生命的交付

从一开始的商业IP课到产品课，心力课等等，各种各样的课程。这价值我就不说了，生怕大家跑不出来。

各种密训，各种直播。

我的手机里全都是洋哥的录屏，常听常新。

焦虑了，听一听，缓解缓解。

迷茫了，听一听，找找方向。

没有动力了，听一听，打个鸡血，继续往前。

这里建议大家还是看直播，因为录屏后肯定不会去看，看直播的效果最好。

真的，只要你不放弃自己，什么时候都有可能。每个人都有自己的节奏，按照自己的节奏来，成功只是时间问题。

目前的成绩：

今天写的这篇公众号已经到了400多阅读，目前还在上涨。

后面，继续努力，争取做出自己的IP，再次感谢洋哥。

2. 感谢惰总凌晨3点还在群里给我们解决问题

就怕我们赚不到钱，都要直接投喂了。

是惰总让我知道了事前逻辑。

创业，做项目一定不能用事后逻辑，别人的成功是不可复制的。时刻用事前逻辑，根据自己的优势、经历、资源来选择你的创业项目，形成自己的创业选品逻辑。

一个财富自由的大佬居然愿意每个月带着我出去跑一次，我何德何能啊。这个多大价值就不说了吧，再次感谢惰总。

3. 感谢刘小排老师，是刘小排老师让我明白了做产品可以这么快乐。

小排老师每次都会在视频结尾说一句类似的话：赶紧去玩起来吧。玩个一整天吧。

是啊，玩起来，跟着自己的兴趣，不断探索，多有意思啊。

这些都是我创业路上的贵人，能及时发现你的问题，给你提供有效的正反馈。

也希望大家都能找到自己的乐趣，去吧，赶紧去玩起来吧！

tips:

好了，今天写完了AI网站产品的复盘，如果点赞多的话，下一篇就会很快与大家见面了（预告：一个完全不懂代码的新手（我女朋友），从0到1，做出一款类似forest的专注森林，学习倒计时APP，目前已经上架。）

技术完全没有门槛，一个拼创意的时代来了！

学会了或有启发，别忘了给我点个赞，评论，转发～因为你的反馈真的很重要！

最后，如果你对AI网站出海感兴趣，欢迎关注公众号 百里登风AI

加 luffy10004 ，领取一份《AI网站出海新手指南》资料包。

作者：百里登风AI出海
来源：juejin.cn/post/7517841519253848116

引言

上篇文章，一个读者评论问，如何在看不到结果的时候，还能坚持下去。

我内心里立刻蹦出来四个字：长期主义，不过转念一想这不是正确的废话吗，现在这个社会谁还没听过长期主义？

坚持早起、坚持阅读、坚持健身，仿佛你足够坚持，命运就会回报你，长期主义本身都快成了一种政治正确。

我很庆幸当时没把这几个字回复给读者，那也太不负责任了。

因为我发现，很多人理解的长期主义，是错的，包括我自己。

试想你有没有这种感觉，每天都在坚持做一些你认为正确的事，但一边焦虑的等待结果为什么还不来，一边痛苦的咬牙坚持。

你有没有想过真正的长期主义，到底是什么样的？

长期主义的难点从来不是坚持，而在于你能否坚定方向、建立反馈，并且在走错路时愿意纠正它。

长期主义的误区

误区一：把长期主义当作“迟到的确定性”

我一度以为，长期主义是一个慢热的公式，只要你足够努力、足够坚持，总会有回报，只不过回报来的慢了一些。

上学的时候，老师教育我们坚持学习，成绩自然会提升。后来看到各种鸡汤文章，看到很多诸如“他默默努力十年，终于爆红”、“她写了一千篇文章，终于年入百万”这样的励志故事。

于是我陷入了第一个陷阱，把长期主义当作“迟来的确定性”，我一直在等待短期反馈出现。

就像我刚开始写文章时，我会在文章发布后，不断的点击刷新按钮，在后台查看数据，看看曝光量怎么样、阅读量怎么样。

不少自媒体人都会有这种“数据焦虑”，如果阅读量涨得很快，那就无比开心，如果发出去半小时没人看，就会陷入焦虑。

那个时候，我自诩是在践行长期主义，但其实我无时无刻都在期待短期的奖励。

但当你这篇文章发出去，内心期待着这篇文章能够达到“10w+”的时候，你就已经悄悄背离了长期主义。

真正的长期主义，不需要靠短期反馈也能坚持下去。

误区二：把坚持当成意义本身

那你说，我不在意短期反馈，我有足够的毅力坚持，总可以了吧？

这就聊到容易陷入的第二个误区，把“坚持”当成了意义本身。

今年年初的时候，我已经坚持写作一年，可是涨粉和阅读量都不尽人意。而且AI发展一日千里，见到很多人走AI赛道涨粉很快，用AI写的文章，靠AI堆上量也能出爆文，内心非常焦虑，我思考是不是自己走错了方向。

屋漏偏逢连夜雨，我感觉耗尽了自己的灵感，没有想写的选题，并且对之前的内容特别不满意，想改变也无从下手。

但我不敢停下，我选择了咬牙坚持，逼迫自己大量的看书、看专栏，试图找到更多灵感。强迫自己多记录一些东西，用笔记数量带给自己安慰。

结果就是看过的内容都是走马观花，什么都没记住。更新的几篇文章全部都绞尽脑汁，即使筋疲力尽写完后也只剩下对自己的不满。

回想起来，那段时间我只是在靠机械的阅读和别扭的写作，来逃避自己没有方向的现实而已。

说难听点就是低水平重复。

如果在错误的地方坚持，那只能带来更大的错误。

真正的长期主义，不会让自己痛苦的坚持，而是建立在对方向的清晰判断上。

什么是真正的长期主义

现在看来，真正理解长期主义并不难，可以用一个公式来总结：长期主义 = 有方向（战略判断）× 有反馈（系统纠偏）× 有预期（心理预期）。

这是一个乘法模型，只要其中任意一项为零，结果就是零。

有方向

你之所以能长期坚持一件事，是因为你能看到这件事长远来看带来的价值。

就拿阅读、写作、锻炼来说，是公认的需要长期主义的事情，虽然他们的反馈周期很长，但是它们能够给我们带来的正向价值十分确定。

可就是最简单直接的三件事情，为什么还是坚持不下来？

这不仅是意志力的问题，还与我们大脑的结构有关——我们天生不擅长做长期决策。

有一本讲脑科学的书《权衡一念》，作者福尔克从脑科学的角度介绍了一个概念：我们大脑有一个「自我相关系统」，当你每次想到与自我相关的东西，核磁共振成像就会扫描到这个区域在被点亮。

但是当你想到几年后的自己或者老年的自己时，「自我相关系统」却不会被点亮，也就是说我们甚至会把「未来的自己」想像成另一个人。

我们以为自己明白一些事情在未来带给我们的好处，但是大脑却认为这些东西和“自己”无关，于是我们更倾向就是自动聚焦到眼前的事情，忽略未来、长远的好处，于是没办法建立方向感。

因为眼前事情，给我们的感受最直接，所以我们陷入了期待短期回报的误区。

你想要在你认可的方向上坚持下去，有一种最简单的方式是，改变聚焦点。

不是强迫自己坚持，而是把注意力转向能够在当下带给你满足感的元素。

怎么改变聚焦点？我举两个自己的例子。

前一阵子为了买东西再次下载了抖音，结果一发不可收拾，开始习惯性的用碎片时间刷短视频。

之前我是全凭意志力控制自己，不断给自己强调“别刷了，没营养”，并告诫自己多看些书。但这次我找出了我最喜欢一本小说《挪威的森林》，这本书我读过五遍，能够很自然的就沉浸在小说的情节里，等小说看完，我空闲时已经不会在习惯性的拿出手机刷短视频了。

日常因为工作原因一坐就是一天，但我又知道每天至少得保证7000步才是最健康的。当我认为需要运动的时候，我并不是告诉自己多运动才能长寿，而是劝自己，文章写到这里灵感已经枯竭，不如出去走一走换换脑子。

这里要点是，我们尽量去聚焦到那些我们不愿意去改变的事情，当下能给我们带来的好处，甚至说和我们喜欢的事情绑定在一起。

聚焦点不一样，行动方向截然不同，真正的长期主义，不是压抑自己做不喜欢的事情，而是和自己喜欢的事情“打配合”。

有反馈

许多人之所以无法坚持长期主义，是因为人很容易在前进的路上迷失。

一个关键原因是我们不能仅凭意志力在黑暗中前行，反馈就是我们的灯塔，提醒自己是否还在正确的方向。

但如果没有建立自己的反馈体系，就很容易陷入把坚持当成意义这个误区。

系统动力学把反馈分成了正反馈回路和负反馈回路。

正反馈就是结果反过来加强了原因，从而形成螺旋式上升。如果你文章质量好，获得了大量点赞，因此平台持续给你推荐。推荐又让更多的人看到，别人进一步的点赞、转发。

负反馈就是系统对偏差进行修复，来保障稳定和持续。健身时你不断冲击更大重量，但身体终会在某一重量时无法承受，你可能会因此受伤，反而达不到之前你能坚持的最大重量。

那么我们就很清晰了，正反馈帮助我们进步，负反馈帮助我们纠偏，你必须建立自己的反馈系统。

第一类反馈来源于外界。

你有没有发现很多博主在视频或者文章后面，都在求大家给一个一键三连，我曾以为这是什么套路，现在看来这是每一个创作者的本能，你的点赞、评论、转发，是对一个内容创作者最好的奖赏。

坦率的讲，现在这个快节奏社会，能够沉下心看完一篇不知名作者写的一篇几千字的文章，已经足够让我开心。

哪怕是我自己，能让我踏下心看完几千字文章的，都是那些大IP和知名的专栏作家。

如果收到了点赞和转发，那我更是无比感激，即使到了今天，我看到文章的互动依然会很兴奋。

这是极强的正反馈，会给你继续前进的力量，随后螺旋上升。

哦对，看到这确认不点个赞吗？

可并不是每次努力，都能够听到外界带给你正向的声音。

因此第二类反馈来源于你自己。

我文章有过很长一段时间的低谷期，几千字的文章无人问津，就好像你搬起了一大块石头扔进水里，一点水花都没有。

那时候我就意识到，我必须建立“内部反馈机制”，我不断问自己几个问题：

慢慢的我发现，曾经让自己迷茫、愤怒、无助的事情，越来越少了。我逐渐能够看透本质，理清思路、看清全局。

其实写作带来这些好处已经弥足珍贵，但我认为还不够，我开始反思每一篇文章：

再比如最近我自己正在拆解每篇文章的不足，然后有意识的和高手学习并一点点改进，一天写完的内容，可能修改要花上三天。

虽然拆解不足给自己的是负反馈，但是复反馈能够帮助你纠偏。

正是这个内部反馈系统，让我坚持到了现在。

第三类设计你自己的系统反馈。

最强大的反馈系统，不靠别人、不靠情绪，而是系统本身。

B站有一个up主叫做影视飓风，老板Tim分享了他们的内容复盘系统，他在最显眼的地方专门放了一个屏幕，里面记录了每一个内容各种实时数据，通过图表展现出来，全公司的人都可以看见。

他们分析哪些内容能涨粉、哪些容易爆，哪条视频表现不好、为什么表现不好。正是这种高度透明和数据驱动的机制，一定程度上帮助他们孵化出第二个账号“飓多多StormCrew”，内容风格完全不同，却因为精准抓住观众喜好而大获成功。

这块我做的不好，我之前几乎不去复盘内容数据，受到他的启发，我花了15分钟用飞书的多维表格，给自己搭建了一个内容数据看板，这里面记录了自己今年来的文章阅读走势。

波动这么明显我有点汗颜，不过我发现带有30+、面试、AI相关的内容，大家会更感兴趣些。

你不一定要搭建看板，但你可以从每周一次总结开始，从定期记录自己的感受开始，找到合适自己的反馈机制。

有预期

最后我们聊聊，如果你真的想要践行长期主义，你得做好哪些准备。

毕竟长期主义并不轻松，提前把困难都想到， 那么真的遇到困难时，反而更容易坚持下来。

长期主义，需要你持续付出。

它不是简单的重复，而是不断在你的“认知边界”上试错、突破。

这很枯燥，而且往往没有立刻回报，还意味着一次次笨拙的表达、失败的尝试，甚至别人眼里的“不够好看”。

但你要相信：每一次认真而笨拙的输出，都是自己能力的提升。

长期主义，需要你学会拒绝。

在这个快节奏的社会，你会看到身边的人，靠短视频一夜爆红，靠AI一键搬运赚取时代红利，也会看到一些小伙伴踩对节奏，迅速赚到了第一桶金。

而你却在钻研技能、搭建反馈系统、耐心苦练内功。

你要拒绝那种“快速反馈”的甜头，转而相信“慢反馈”的确定性。

长期主义的回报，是非线性的。

你以为努力一点，进步一点，实际上看似停滞许久，在某一天突然爆发。

大模型有一个著名的现象，叫做能力涌现：你喂进去足够多的数据，在某一刻，它突然学会了你没教它的东西，比如逻辑推理、语言翻译，甚至写代码。

这不是持续进化，而是能力突然“跃迁”。可能连大模型科学家本身也不明白，AI怎么就突然变得如此强大。

就像你健身半年没有什么变化，突然在某一天，你惊讶的发现：肌肉线条已经若隐若现。

说在最后

要我看来，长期主义最大的坏处就是孤独。

你给自己选中了一条要走下去的路，可能身边的人不理解，就算是是最亲近的人对你冷言冷语，你也没有抱怨的权利。

不过长期主义最大的好处也在这里。

你真的会一次次得把曾经以为的“天花板”变成自己脚下的阶梯，你除了抱怨时间不够、能力不足、精力不够，你没什么好抱怨的。

而这，恰恰就是一种美好的人生状态！

这是东东拿铁的第82篇原创文章，欢迎关注。

今天，我的第一个独立开发出海产品 Chat2Report 上线了，这是一款基于 RAG 的美股财报聊天应用。

为什么要开发独立产品

去年初通过几位大佬（越南的 Tony Dinh，国内的 Hawstein 和 vikingz）的博客了解到，作为程序员还有开发独立产品出海这一条路，其中有些收入还不错，甚至有开发者辞掉了工作，全职做独立开发。

看完他们的文章，心里很激动，想着自己是不是也可以试一试。于是使用 OpenAI 的 gpt-4o-mini 模型微调了一个专门的模型，做了一个变量命名工具，叫 VarNamer，支持多国语言，用户输入任意语言，即可输出精简的英文变量。当时 AI 编程工具还刚刚兴起，变量命名又是件头痛的事，所以想着这个工具应该能为自己节省不少时间。

其实当时开发这个产品，也是为了学习新技术，为自己后面开发出海产品做准备，由于看到不少独立产品都是桌面端的，所以基于 Electron + Vue3 做了 VarNamer，为什么选择 Electron？因为它构建跨平台程序非常方便，为了上Mac，还购买了苹果开发者证书。

开发 VarNamer 并不顺利，期间踩了不少坑，也坚定了后面的出海产品不会再做桌面端了。因为一般的 Web 开发不需要考虑版本更新、证书、跨平台兼容等问题，但是开发桌面应用需要将这些因素都考虑进去。除去后端服务器的成本，安装包托管，更新逻辑，还需要考虑程序的签名证书，不然用户安装应用会报警告，甚至安装不了，其中苹果开发者证书一年就99刀，Windows 就更贵了。

VarNamer 上线后，在几个论坛发了贴宣传，也发给了同事使用，反响还不错，但是没想到后面 AI 编程工具发展这么快，特别是出了 Cursor 这样的王炸产品，变量命名完全不是难事，几乎改变了以往的编程习惯，一直 Tab 的感觉，简直不要太爽。

99 刀的苹果开发者证书就开发了一个应用，着实太浪费了，至于 VarNamer，后面再也没管过它，好像域名最近快到期了，也不打算续费了。

独立出海产品契机

自 VarNamer 之后，接下来的几个月时间并没有开发新的产品，为什么？因为我不知道开发什么，好像也找不到什么痛点需要解决的，后面想到自己在买一家上市公司的股票之前，会分析公司的财务报告，毕竟我是一位追随彼得·林奇和巴菲特的价值投资者，哈哈!

但是分析财报是件麻烦且费脑的事，一份财报少则几十页多则几百页，除了重点关注三张报表，即资产负债表、利润表、现金流量表（俗称“三大表”），还需要关注管理策略、管理层的措施、战略，财报中是否有欺诈风险等。

既然这么麻烦，那 AI 是不是能帮我们分析了？后面经过调研发现了市面上还真有这样的产品，比如 beebee、reportify，它们都是基于 RAG 实现的，但是我想基于它们开发一款新的产品，为什么？因为它们的功能实在太多了，新闻、电话会议、上传文件、公司评价...，而且 RAG 也不精准，我需要一款操作简单，体验更好，简洁、美观，精准，专门分析财报的工具。

去年 9 月下旬开始了技术调研，之前对 RAG 技术稍微有点了解，但是不够深入，只是基于 Dify 做了一些应用，同时发现 Dify 不够自由，文档解析分块不能自定义元数据，后端又是基于Flask的，to C 的应用担心性能不够，生产环境还需要一台服务器额外部署 Dify。

调研下来最终确定业务层使用Go + Gin, 大模型层使用Python + FastAPI + LlamaIndex，前端使用Vue3。LlamaIndex 实现 RAG 应用非常方便，兼容各种第三方文档解析器、向量模型（Embedding models）、重排序模型（Rerank models）, 向量数据库、大语言模型（LLMs）。

之后利用下班时间和假期实现了个 demo，感觉还不错，是自己想要的效果，美股财报批量转 PDF，文档批量解析、分块，提取布局信息，前端布局重构回溯，AI回答带引用来源，高亮定位到原文段落，一个 ChatPDF + AI 财报助理的构想应该很快就可以实现。

10 月份利用业余时间开始了马不停蹄的开发，这期间公司一些事件却让自己很不舒服，作为一个技术人，希望能全身心的投入到技术中，利用技术解决问题，但是各种PPT汇报、职场PUA，让自己疲于奔命。

我想离职了，全职投入到项目开发中，11月初的一个晚上把这个想法告诉了老婆，非常正式的讲了自己的规划，产品怎么落地，产品受众人群，怎么盈利，以及一个粗略的计划，希望得到她的支持。因为我觉得，组建家庭后，另一半相当于就是你的人生合伙人。在很多重要决策上，得到合伙人的支持，才能走得更好走得更远。如果成功了，兴许以后就不用上班了，就算失败了大不了重新找个班去上。老婆没说什么，表示了支持，在这里要特别感谢一下老婆。

全力加速开发

12 月 09 号是我最后一个工作日，也是我作为全职独立开发的第一天，当天走出公司，呼吸着新鲜的空气，感受到了从未有过的自由。

成为全职独立开发之后，最大的感受就是开发效率提高了几倍，不用再参加枯燥无聊的会议，应付各种办公室政治斗争，输出无意义的PPT。直到今天项目上线，全部开发时间应该是3个月。

这期间踩了无数坑，以前工作时的一些优点，现在反而成了缺点，比如之前专注于写好代码，追求架构完美和扩展性，甚至有代码洁癖，但这严重推迟了产品的上线时间，在产品还未经过市场验证之前，应该快速推出产品，验证市场需求，这比追求精美更重要。

接下来的计划

接下来的主要任务就是宣传了，去海外各大社区宣传寻找目标用户，比如 Facebook、Twitter、Reddit。

两个月之后我会再写一篇帖子，分享我的成果，盈利情况等。

接下来也会分享一些出海产品在技术选型和海外支付方面的经验。

大家好，我是一名前端开发工程师，属于是没有赶上互联网红利，但赶上了房价飞涨时代的 95 后社畜。2024 年 3 月份我做了个决定，即使已经失业半年、负收入 10w+ 的如今的我，也毫不后悔的决定：辞职感受下这个世界。

为什么要辞职，一是因为各种社会、家庭层面的处境对个人身心的伤害已经达到了不可逆转的程度，传播互联网负面情绪的话我也不想多说了，经历过的朋友懂得都懂，总结来说就是，在当前处境和环境下，已经没有办法感受到任何的快乐了，只剩焦虑、压抑，只能自救；二是我觉得人这一辈子，怎么也得来一次难以忘怀、回忆起来能回甘的经历吧！然而在我的计划中，不辞职的话，做不到。

3 月

在 3 月份，我去考了个摩托车驾-照，考完后购买了一辆摩托车 DL250，便宜质量也好，开始着手准备摩旅。

4 月份正式离职后，我的初步计划是先在杭州的周边上路骑骑练下车技，直接跑长途还是很危险的，这在我后面真的去摩旅时候感受颇深，差点交代了。

4 月

4.19 号我正式离职，在杭州的出租屋里狠狠地休息了一个星期，每天睡到自然醒，无聊了就打打游戏，或者骑着摩托车去周边玩，真的非常非常舒服。

不过在五一之前，我家里人打电话跟我说我母亲生病了，糖尿病引发的炎症，比较严重，花了 2w+ 住院费，也是从这个时候才知道我父母都没有交医保（更别说社保），他们也没有正式、稳定的工作，也没有一分钱存款，于是我立马打电话给老家的亲戚让一个表姐帮忙去交了农村医保。所有这些都是我一个人扛，还有个亲哥时不时问我借钱。

说实话，我不是很理解我的父母为什么在外打工那么多年，一分钱都存不下来的，因为我从小比较懂事，没让他们操过什么心，也没花过什么大钱。虽然从农村出来不是很容易，但和周围的相同条件的亲戚对比，我只能理解为我父母真的爱玩，没有存钱的概念。

我可能也继承了他们的基因吧？才敢这样任性的离职。过去几年努力地想去改变这个处境，发现根本没用，还把自己搞得心力交瘁，现在想想不如让自己活开心些吧。

5 月

母亲出院后，我回到杭州和摩友去骑了千岛湖，还有周边的一些山啊路啊，累计差不多跑了 2000 多公里，于是我开始确立我的摩旅计划，路线是杭州-海南岛-云南-成都-拉萨，后面实际跑的时候，因为云南之前去过，时间又太赶，就没去云南了。

6 月

在摩友的帮助下，给摩托车简单进行了一些改装，主要加了大容量的三箱和防雨的驮包，也配备了一些路上需要的药品、装备，就一个人出发了。

从杭州到海南这部分旅行，我也是简单记录了一下，视频我上传了 B 站，有兴趣的朋友可以看看：

拯救焦虑的29岁，考摩托车驾-照，裸辞，买车，向着自由，出发。

摩托车确实是危险的，毕竟肉包铁，即使大部分情况我已经开的很慢，但是仍然会遇到下大雨路滑、小汽车别我、大货车擦肩而过这种危险情况，有一次在过福建的某个隧道时，那时候下着大雨，刚进隧道口就轮胎打滑，对向来车是连续的大货车，打滑之后摩托车不受控制，径直朝向对向车道冲过去，那两秒钟其实我觉得已经完蛋了，倒是没有影视剧中的人生画面闪回，但是真的会在那个瞬间非常绝望，还好我的手还是强行在对龙头进行扳正，奇迹般地扳回来且稳定住了。

过了隧道惊魂未定，找了个路边小店蹲在地上大口喘气，雨水打湿了全身加上心情无法平复，我全身都是抖的，眼泪也止不住流，不是害怕，是那种久违地从人类身体发出的求生本能让我控制不住情绪的肆意发泄。

在国道开久了人也会变得很麻木，因为没什么风景，路况也是好的坏的各式各样，我现在回看自己的记录视频，有的雨天我既然能在窄路开到 100+ 码，真的很吓人，一旦摔车就是与世长辞了。

不过路上的一切不好的遭遇，在克服之后，都会被给予惊喜，到达海南岛之后，我第一次感觉到什么叫精神自由，沿着海边骑行吹着自由的风，到达一个好看的地方就停车喝水观景，玩沙子，没有工作的烦扰，没有任何让自己感受到压力的事情，就像回到了小时候无忧无虑玩泥巴的日子，非常惬意。

在完成海南环岛之后，我随即就赶往成都，与前公司被裁的前同事碰面了。我们在成都玩了三天左右，主要去看了一直想看的大熊猫🐼！

之后我们在 6.15 号开始从成都的 318 起始点出发，那一天的心情很激动，感觉自己终于要做一件不太一样的事，见不一样的风景了。

小时候在农村，读书后在小镇，大学又没什么经济能力去旅行，见识到的事物都非常有限，但是这一切遗憾在川藏线上彻底被弥补了。从开始进入高原地貌，一路上的风景真的美到我哭！很多时候我头盔下面都是情不自禁地笑着的，发自内心的那种笑，那种快乐的感觉，我已经很久很久很久没有了。

同样地，这段经历我也以视频的方式记录了下来，有兴趣的朋友可以观看：

以前只敢想想，现在勇敢向前踏出了一步，暂时放下了工作，用摩托跑完了318

到拉萨了！

花了 150 大洋买的奖牌，当做证明也顺便做慈善了：）

后面到拉萨之后我和朋友分开了，他去自驾新疆，我转头走 109 国道，也就是青藏线，这条线真的巨壮美，独自一人行驶在这条路，会感觉和自然融合在了一起，一切都很飘渺，感觉自己特别渺小。不过这条线路因为冻土层和大货车非常非常多的原因，路已经凹凸不平了，许多炮弹坑，稍微骑快点就会飞起来。

这条线还会经过青海湖，我发誓青海湖真的是我看到过最震撼的景色了，绿色和蓝色的完美融合，真的非常非常美，以后还要再去！

拍到了自己的人生照片：

经历了接近一个半月的在外漂泊，我到了西宁，感觉有点累了，我就找了个顺丰把摩托车拖运了，我自己就坐飞机回家了。

这一段经历对我来说非常宝贵，遇到的有趣的人和事，遭遇的磨难，见到的美景我无法大篇幅细说，但是每次回想起这段记忆我都会由衷地感觉到快乐，感觉自己真的像个人一样活着。

这次旅行还给了我感知快乐和美的能力，回到家后，我看那些原来觉得并不怎么样的风景，现在觉得都很美，而且我很容易因为生活中的小确幸感到快乐，这种能力很重要。

7 月

回到家大概 7 月中旬。

这两个多月的经历，我的身体和心态都调整的不错了，但还不是很想找工作，感觉放下内心的很多执念后，生活还是很轻松的，就想着在家里好好陪陪母亲吧，上班那几年除了过年都没怎么回家。

在家里没什么事，但是后面工作的技能还是要继续学习的，之前工作经历是第一家公司用的 React 16，后面公司用的是 Vue3，对 React 有些生疏，我就完整地看了下 React 18 的文档，感觉变化也不是很大。

8、9 月

虽然放下了许多执念，对于社会评价（房子、结婚、孩子）也没有像之前一样过于在乎了，但还是要生活的，也要有一定积蓄应对未来风险，所以这段时间在准备面试，写简历、整理项目、看看技术知识点、刷刷 leetcode。

也上线了一个比较有意义的网站，写了一个让前端开发者更方便进行 TypeScript 类型体操的网站，名字是 TypeRoom 类型小屋，题源是基于 antfu 大佬的 type-challenges。

目前 Type Challenges 官方提供了三种刷题方式

• 通过 TypeScript Playground 方式，利用 TypeScript 官方在线环境来刷题。


• 克隆 type-challenges 项目到本地进行刷题。


• 安装 vscode 插件来刷题。

这几种方式其实都很方便，不过都在题目的可读性上有一定的不足，还对开发者有一定的工具负担、IDE 负担。

针对这个问题，也是建立 TypeRoom 的第一个主要原因之一，就是提供直接在浏览器端就能刷题的在线环境，并且从技术和布局设计上让题目描述和答题区域区分开来，更为直观和清晰。不需要额外再做任何事，打开一个网址即可直接开始刷题，并且你的答题记录会存储到云端。

欢迎大家来刷题，网址：typeroom.cn

因为个人维护，还有很多题目没翻译，很多题解没写，也还有很多功能没做，有兴趣一起参与的朋友可以联系我哦，让我一起造福社区！

同时也介绍下技术栈吧：

前端主要使用 Vue3 + Pinia + TypeScript，服务端一开始是 Koa2 的，后面用 Nest 重写了，所以现在服务端为 Nest + Mysql + TypeORM。

另外，作为期待了四年，每一个预告片都看好多遍的《黑神话·悟空》的铁粉，玩了四周目，白金了。

现在

现在是 10 月份了，准备开始投简历找工作了，目前元气满满，不急不躁，对工作没有排斥感了，甚至想想工作还蛮好的，可能是闲久了吧，哈哈哈，人就是贱～

更新 11 月

我还是没有找工作，又去摩旅了一趟山西、山东，这次旅行感觉比去西藏还累、还危险。同样是做了视频放 b 站了，有兴趣的可以看看：

骑了4300km只为寻找那片海-威海的海｜摩旅摩得命差点没了

真的要开始找工作了喂！

最后

其实大多数我们活得很累，都是背负的东西太多了，而这些大多数其实并不一定要接受的，发挥主观能动性，让自己活得开心些最重要，加油啊，各位，感谢你看到这里，祝你快乐！

这是我的 github profile，上面有我的各种联系方式，想交个朋友的可以加我～❤️

近日，Swift 官方正式宣布成立 Android 的工作组，将 Android 列为官方支持的平台，该工作组的主要目标是为 Swift 语言添加并维护 Android 平台支持，让开发者能够使用 Swift 开发 Android 应用：

其实 Swift 语言跨平台支持也不是什么新鲜事，在之前我聊过的 Skip 用 Swift 写 Android App 的时候就聊过，只是不同的是 Skip 是将 Swift 翻译成 Kotlin，把 SwiftUI 翻译成 Compose 的形式来实现，这和 uni-app x 的跨平台实现殊途同归。

感兴趣的可以看 《2025 跨平台框架更新和发布对比》

但是 Swift 官方的方案则不同，它是通过 LLVM 进行适配的，我们之前聊过的 《为什么跨平台框架可以适配鸿蒙》就聊过，LLVM 也是各大框架适配鸿蒙的重要基石，甚至一些方案适配鸿蒙是通过 Apple 的 LLVM 去先导出 IR 来完成前置工作。

而这次 Swift on Android 的实现，则是直接利用 Android 平台的构建工具：Android NDK 。

为什么这么说？因为 Swift 编译器从诞生之初就基于 LLVM ，而 Google 的 Android NDK 后来也使用基于 LLVM 的 Clang 作为其官方 C/C++ 编译器 :

• NDK r11 开始建议切换到 Clang


• NDK r12 ndk-build 命令默认使用 Clang


• NDK r13 GCC 不再受支持


• NDK r14 GCC 弃用


• ····

说起 Clang 和苹果也是很有渊源，Clang 的设计初衷是提供一个可以替代 GCC 的前端编译器，因为 GCC 的发展不符合 Apple 的节奏和需要，同时受限于License，苹果公司无法使用 LLVM 在 GCC 基础上进一步提升代码生成质量，因此苹果公司决定从头编写 C、C++、Objective-C 语言的前端 Clang，以彻底替代GCC。

而在编译上，比如 stdlib 里的 AddSwiftStdlib.cmake 可以看到， Swift 没有在 Android 上创造一套自己的 log 系统，它直接链接了 Android 的 Native 的日志 log 来实现，从而支持 Android Studio 的 Logcat ：

所以基于 LLVM 的 Android NDK 是实现 Swift 跨平台编译的关键，它让 Swift 编译器能够被“重定向”，从而为 Android 支持的 CPU 架构（如 aarch64、armv7、x86_64）生成相应的原生机器码 。

$ NDK_PATH=path/to/android-ndk-r27c

$ SWIFT_PATH=path/to/swift-DEVELOPMENT-SNAPSHOT-2024-11-09-a-ubuntu22.04/usr/bin

$ git checkout swift-DEVELOPMENT-SNAPSHOT-2024-11-09-a

$ utils/build-script \

    -R \                                       # Build in ReleaseAssert mode.

    --android \                                # Build for Android.

    --android-ndk $NDK_PATH \                  # Path to an Android NDK.

    --android-arch aarch64 \                   # Optionally specify Android architecture, alternately armv7 or x86_64

    --android-api-level 21 \                   # The Android API level to target. Swift only supports 21 or greater.

    --stdlib-deployment-targets=android-aarch64 \ # Only cross-compile the stdlib for Android, ie don't build the native stdlib for Linux

    --native-swift-tools-path=$SWIFT_PATH \    # Path to your prebuilt Swift compiler

    --native-clang-tools-path=$SWIFT_PATH \    # Path to a prebuilt clang compiler, one comes with the Swift toolchain

    --build-swift-tools=0 \                    # Don't build the Swift compiler and other host tools

    --build-llvm=0 \                           # Don't build the LLVM libraries, but generate some CMake files needed by the Swift stdlib build

    --skip-build-cmark                         # Don't build the CommonMark library that's only needed by the Swift compiler

简而言之，就是编译成 so 。

目前官方要求是在 Linux 环境下（官方推荐 Ubuntu 20.04/22.04）下，使用 Swift 官方提供的交叉编译工具链，将 .swift 源文件编译成原生可执行文件或共享库，之后将编译产物连同必需的 Swift 运行时库，通过 Android adb 推送到 Android 设备或模拟器上，最终这些原生代码可以在 Android 的 shell 环境中直接运行，或被一个标准的 Android 应用加载并调用 ：

首先需要运行以下命令复制复制对应的 so :

$ adb push build/Ninja-ReleaseAssert/swift-linux-x86_64/lib/swift/android/libswiftCore.so /data/local/tmp

$ adb push build/Ninja-ReleaseAssert/swift-linux-x86_64/lib/swift/android/libswiftAndroid.so /data/local/tmp

$ adb push build/Ninja-ReleaseAssert/swift-linux-x86_64/lib/swift/android/libswiftSwiftOnoneSupport.so /data/local/tmp

$ adb push build/Ninja-ReleaseAssert/swift-linux-x86_64/lib/swift/android/libswiftRemoteMirror.so /data/local/tmp

$ adb push build/Ninja-ReleaseAssert/swift-linux-x86_64/lib/swift/android/libswift_Concurrency.so /data/local/tmp

$ adb push build/Ninja-ReleaseAssert/swift-linux-x86_64/lib/swift/android/libswift_RegexParser.so /data/local/tmp

$ adb push build/Ninja-ReleaseAssert/swift-linux-x86_64/lib/swift/android/libswift_StringProcessing.so /data/local/tmp

$ adb push build/Ninja-ReleaseAssert/swift-linux-x86_64/lib/swift/android/libdispatch.so /data/local/tmp

$ adb push build/Ninja-ReleaseAssert/swift-linux-x86_64/lib/swift/android/libBlocksRuntime.so /data/local/tmp

然后还需要复制 Android NDK 的 libc++ ：

$ adb push /path/to/android-ndk-r27c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android/libc++_shared.so /data/local/tmp

此外还需要复制在上一步中构建的 hello 可执行文件：

$ adb push hello /data/local/tmp

最终通过 adb shell 命令在 Android 设备上执行 hello 可执行文件：

$ adb shell LD_LIBRARY_PATH=/data/local/tmp /data/local/tmp/hello

而对于 Android 端来看，此时的 Swift 产物与 C/C++ 代码没什么区别，它必须作为一个标准的 .so 库被加载，并通过 JNI 规范暴露需要支持的能力。

目前 Swift 的核心标准库（stdlib）已经可以成功在 Android 平台进行编译 ，也就是目前 String、Int、Array 和 Dictionary 等基础数据类型已经完成基本支持：

更高层次的核心库，比如 Foundation（ URLSession、JSONEncoder ）和 Dispatch（提供并发支持），也正在被移植到 Android 平台。

而对于 UI 部分，目前 Swift 官方暂未提供任何支持 Android 的 UI 框架 ，官方文档目前表示：“You'd need some sort of framework to build a user interface for your application, which the Swift stdlib does not provide” 。

所以，从这个层面看，它更像是 KMP 的存在，而如果需要类似 CMP 的支持，那么大概率需要 SwfitUI 的官方适配，毕竟 Skip 其实只是一个翻译框架。

而在互操作上，其实过去就有 swift-java 这个图的互操作方向的尝试，当时的目标是实现 Swift 与 Java 之间的双向互操作性，即支持 Swift 调用 Java 库，也支持 Java 调用 Swift 库 ：

但是从官方描述来看， Swift on Android 似乎并没有直接使用类似桥接绑定，也就是你需要自己实现这部分，如果你需要的话：

而对于 Swift on Android 来说，要让一个 Swift 函数能被外部的 C 代码（以及遵循 C 调用约定的 JNI）所发现和调用，一般也就是通过 @_cdecl 属性，这个属性可以将函数编译成一个简单的、符合 C 语言标准的符号（Symbol）并暴露出去。

虽然没找到对应的 demo 或者实现，但是理论上如果想要不暴露接口，大概率还是通过 @_cdecl。

所以目前 Swift on Android 给人的感觉确实很毛坯，在交互和 UI 上都很欠缺，看起来只是开源了一种可能，具体能达到什么效果暂时还看不出来，但是多少算是官方起了个头，也算是有了希望，对于 iOS 来说，这个春天还需要再等等。

那么，你觉得 Swift on Android 的存在多久可以达到生产标准？

参考链接

• github.com/swiftlang/s…


• github.com/swiftlang/s…

前言

最近有看到两个报告，调查、总结、2024年程序员的生存情况以及一些工作情况，国内国外都有。接下来摘抄部分数据看看是否与我们的实际相符。

1. 程序员的年龄分段

先看国内的数据：

可以看出，2630岁之间的程序员占比是最多的，1835岁之间占比将近80%。
18~25岁，包含在校学生和刚毕业三年内的学生，按现在考研的趋势，这部分占比会逐渐变低。
35岁以上占比接近19%，说明还是有不少大龄程序员。

再看国外的数据：

2124岁、2529岁占比是并列第一，18~35岁之间占比将近70%。
35岁以上占比30%，说明国外程序员"老龄化"更严重。

看国家之间的对比：

18~29岁程序员分布的国家。

论哪里拥有最多的年轻程序员？还得是神秘的东方大国，人口大国、文明古国---印度。怪不得印度程序员在美国混得很开，毕竟每年都有大量的年轻程序员。
中国在中东、非洲、中亚之后。
看样子美国有不少大龄程序员。

2. 程序员的工作年限

先看国内的数据：

工作13年是最多的，其次是310年。
而10年以上的就比较少，这个时间大都32岁以上了，中途有不少人主动、被动转行。

再看国外的数据：

拥有3~5年的工作经历占比最多，10年以上的工作经历占比接近30%，这比国内的高。

3. 程序员的薪资水平

先看国内水平：

大部分月收入是在10k20k之间，换算成年收入在12w24w之间。
这和地域有关系，比如一个程序员在一线城市北上深薪资20k，那么到二线城市如杭州、成都、武汉可能会打七折，如果再到长沙、西安等估计还会更低。

再看国外水平（收入中位数）：

此处显示的是年薪，可以看到美国程序员的收入遥遥领先。
按照汇率计算：

美国程序员收入中位数是百万年薪（人民币)。
而中国是22万人民币，此处的差距还是比较大，同志仍需努力。

4. 哪个年龄段最卷？

通过上述数据，可以看出，35岁以下程序员群体最庞大，工作十年以内人数最多，工资10k~20k人最多，这也符合我们平时职场的感知。

22~25岁，刚毕业几年，正是学习知识，刷小怪升级的时候，按理来说应该会在下班时间蹭公司的免费空调自我学习提升。然而，经过实际观察，目前这个年龄段是00后占据主体，大部分是到点下班。
访谈得知原因如下：

1. 大学四年大部分在上网课，天天对着电脑，现在工作还是对着电脑，顶不住，下班就直接溜。


2. 我加班能得到什么？就这点钱只能买我8小时。


3. 老员工都是既得利益者，是公司的"精神股东"，我们就是喽啰，不做额外奉献。

25~30岁，已经在职场中历练了不少年，写的bug、产生的线上事故、输出的复盘文档、与其它部门撕逼等等统统都有经验了，理论上来应该不怎么卷，而实际上最卷的反而是这段年龄的。
总结原因如下：

1. 实战经验积累了不少，成为技术骨干，需要调研、学习的东西更多了；平时开会撕逼、晚上怒写业务、周末学习新知识提升自我，花费的时间比较多。


2. 这个年龄段处在恋爱、结婚的思考期，没有家庭、小孩的牵挂，留给自己的时间更多。


3. 有些还独挡一面当了leader，比如前端小组长，还想再往上踮踮脚，够一下，博一下，卷的主观能动性比较强。

30~35岁，职场老油条，见多识广，动态卷，就是比较能苟。
交流总结如下：

1. 家庭牵扯了不少精力，还好靠经验能弥补一些亏空。


2. 发展的天花板已经看到，就是摸不着，不相信什么大器晚成，看不到太多希望，做好自己分内事就好。


3. 每年的体检总是新增各项小毛病，更加关注自己的身体健康。


4. 懂得职场潜规则，该加班配合的演出还是不能视而不见。

35~45岁，这个年龄段出任CEO、赢取白富美的凤毛麟角，要么上升，要么转行，留下来继续编码的反而是最看开的一群人，因为身体/精神原因，没实力卷，实在卷不动。
访谈如下：

1. 我在外包挺好的，再干个几年存够社保和养老金就退休。


2. 不争不吵，你说的都对，按你的来。


3. 组内都是年少有为的人啊，天赋高又刻苦，公司的发展靠你们了，我的养老也靠你们了。


4. 最近又发现了个野钓的地方，不容易空军，周末赶早去来一杆。

45岁以上，职场除了高管，没见过这个年龄段的一线码农。
按现在发展，也许多年后，我会看见这样的自己。

这两天啊，各地高考的成绩终于是陆续公布了。

现在，也是时候揭晓全球第一梯队的大模型们的 “高考成绩” 了——

我们先来看下整体的情况（该测试由字节跳动 Seed 团队官方发布）：

按照传统文理分科计分方式，Gemini 的理科总成绩 655 分，在所有选手里排名第一。豆包的文科总成绩 683 分，排名第一，理科总成绩是 648 分，排名第二。

再来看下各个细分科目的成绩情况：

除了数学、化学和生物之外，豆包的成绩依旧是名列前茅，6 个科目均是第一。

不过其它 AI 选手的表现也是比较不错，可以说是达到了优秀学生的水准。

比较遗憾的选手就要属 O3，因为它在语文写作上跑了题，因此语文成绩仅 95 分，拉低了整体的分数。

若是从填报志愿角度来看，因为这套测试采用的是山东省的试卷，根据过往经验判断，3 门自选科目的赋分相比原始分会有一定程度的提高，尤其是在化学、物理等难度较大的科目上。本次除化学成绩相对稍低外，豆包的其余科目组合的赋分成绩最高能超过 690 分，有望冲刺清华、北大。

（赋分规则：将考生选考科目的原始成绩按照一定比例划分等级，然后将等级转换为等级分计入高考总分）

好，那现在的豆包面临的抉择是：上清华还是上北大？

大模型参加高考，分数怎么判？

在看完成绩之后，或许很多小伙伴都有疑惑，这个评测成绩到底是怎么来的。

别急，我们这就对评测标准逐条解析。

首先在卷子的选择上，由于目前网络流出的高考真题都是非官方的，而山东是少数传出全套考卷的高考大省；因此主科（即语文、数学、英语）采用的是今年的全国一卷，副科采用的则是山东卷，满分共计 750 分。

其次在评测方式上，都是通过 API 测试，不会联网查询，评分过程也是参考高考判卷方式，就是为了检验模型自身的泛化能力：

• 选择题、填空题
  
  

  采用机评（自动评估）加人工质检的方式；



• 开放题
  
  

  实行双评制，由两位具有联考阅卷经验的重点高中教师匿名评阅，并设置多轮质检环节。

在给模型打分的时候，采用的是 “3 门主科（语文数学英语）+3 门综合科（理综或文综）” 的总分计算方式，给五个模型排了个名次。

值得一提的是，整个评测过程中，模型们并没有用任何提示词优化技巧来提高模型的表现，例如要求某个模型回答得更详细一些，或者刻意说明是高考等等。

最后，就是在这样一个公平公正的环境之下，从刚才我们展示的结果来看，Gemini、豆包相对其他 AI 来说取得了较优的成绩。

细分科目表现分析

了解完评测标准之后，我们继续深入解读一下 AI 选手们在各个科目上的表现。

由于深度思考的大火，大模型们在数学这样强推理科目上的能力明显要比去年好很多（此前大部分均不及格），基本上都能达到 140 分的成绩。

不过在一道不算难的单选题（全国一卷第 6 题）上，国内外的大模型们却都栽了跟头：

这道题大模型们给出的答案是这样的：

豆包：C；Gemini：B；Claude：C；O3：C；DeepSeek：C。

但这道题的正解应该是 A，因此大模型们在此全军覆没。

之所如此，主要是因为题目里有方框、虚线、箭头和汉字混在一起的图，模型认不准图像，说明它们在 “看图说话” 这块还有进步空间。

以及在更难的压轴大题上，很多大模型也没完全拿下，经常漏写证明过程，或者推导不严谨被扣分，说明在细节上还需加强。

到做语文选择题和阅读题这两个版块，大模型们几乎是 “学霸本霸”，得分率超高。

不过在作文写作过程也暴露出了一些问题，例如写作过于刻板、文字冰冷，文章字数不达标（不足 800 字或超过 1200 字）、立意不对，形式上还经常会出现惯用的小标题。

在英语测试过程中，大模型们几乎挑不出毛病，唯一扣分点是在写作上，比如用词不够精准、句式稍显单调，但整体已经很接近完美。

对于理综，遇到带图的题目大模型们还是会犯难，不过豆包和 Gemini 这俩模型在看图像和理解图的能力上会比其他模型强一些。

例如下面这道题中，正确答案应当是 C，大模型们的作答是这样的：

豆包：C；Gemini：C；Claude：D；O3：D；DeepSeek：D。

最后在文综方面，大模型的地域差别就显现得比较明显，国外的大模型做政治、历史题时，经常搞不懂题目在考啥，对中国的知识点不太 “感冒”。

而对于地理题，最头疼的便是分析统计图和地形图，得从图里精准提取信息再分析。

以上就是对于本次评测的全面分析了。

除了今年国内的高考之外，这几位 “参赛选手” 还参加了印度理工学院的第二阶段入学考试——JEE Advanced。

这场考试每年有数百万人参与第一阶段考试，其中前 25 万考生可晋级第二阶段。它分为两场，每场时长 3 小时，同时对数学、物理、化学三科进行考察。

题目以图片形式呈现，重点考查模型的多模态处理能力与推理泛化能力。所有题目均为客观题，每道题进行 5 次采样，并严格按照 JEE 考试规则评分——答对得分、答错扣分，不涉及格式评分标准。

与全印度人类考生成绩对比显示，第一名得分 332 分，第十名得分 317 分。

值得注意的是，豆包与 Gemini 已具备进入全印度前 10 的实力：Gemini 在物理和化学科目中表现突出，而豆包在数学科目 5 次采样中实现全对。

怎么做到的？

相比去年一本线上下的水平，整体来看，大模型们在今年高考题上的表现均有明显的进步。

那么它们到底是如何提升能力的？我们不妨以拿下单科第一最多的豆包为例来了解一下。

豆包大模型 1.6 系列，是字节跳动 Seed 团队推出的兼具多模态能力与深度推理的新一代通用模型。

团队让它能力提升的技术亮点，我们可以归结为三招。

第一招：多模态融合与 256K 长上下文能力构建

Seed1.6 延续了 Seed1.5 在稀疏 MoE（混合专家模型）领域的技术积累，采用 23B 激活参数与 230B 总参数规模进行预训练。其预训练过程通过三个阶段实现多模态能力融合与长上下文支持：

• 第一阶段：纯文本预训练
  
  以网页、书籍、论文、代码等数据为训练基础，通过规则与模型结合的数据清洗、过滤、去重及采样策略，提升数据质量与知识密度。


• 第二阶段：多模态混合持续训练（MMCT）
  
  进一步强化文本数据的知识与推理密度，增加学科、代码、推理类数据占比，同时引入视觉模态数据，与高质量文本混合训练。


• 第三阶段：长上下文持续训练（LongCT）
  
  通过不同长度的长文数据逐步扩展模型序列长度，将最大支持长度从 32K 提升至 256K。

通过模型架构、训练算法及 Infra 的持续优化，Seed1.6 base 模型在参数量规模接近的情况下，性能较 Seed1.5 base 实现显著提升，为后续后训练工作奠定基础。

这一招的发力，就对诸如高考语文阅读理解、英语完形填空和理科综合应用题等的作答上起到了提高准确率的作用，因为它们往往涉及长文本且看重上下文理解。

第二招：多模态融合的深度思考能力

Seed1.6-Thinking 延续 Seed1.5-Thinking 的多阶段 RFT（强化反馈训练）与 RL（强化学习）迭代优化方法，每轮 RL 以上一轮 RFT 为起点，通过多维度奖励模型筛选最优回答。相较于前代，其升级点包括：

• 拓展训练算力，扩大高质量数据规模（涵盖 Math、Code、Puzzle 等领域）；


• 提升复杂问题的思考长度，深度融合 VLM 能力，赋予模型清晰的视觉理解能力；


• 引入 parallel decoding 技术，无需额外训练即可扩展模型能力 —— 例如在高难度测试集 Beyond AIME 中，推理成绩提升 8 分，代码任务表现也显著优化。

这种能力直接对应高考中涉及图表、公式的题目，如数学几何证明、物理电路图分析、地理等高线判读等；可以快速定位关键参数并推导出解题路径，避免因单一模态信息缺失导致的误判。

第三招：AutoCoT 解决过度思考问题

深度思考依赖 Long CoT（长思维链）增强推理能力，但易导致 “过度思考”—— 生成大量无效 token，增加推理负担。

为此，Seed1.6-AutoCoT 提出 “动态思考能力”，提供全思考、不思考、自适应思考三种模式，并通过 RL 训练中引入新奖励函数（惩罚过度思考、奖励恰当思考），实现 CoT 长度的动态压缩。

在实际测试中：

• 中等难度任务（如 MMLU、MMLU pro）中，CoT 触发率与任务难度正相关（MMLU 触发率 37%，MMLU pro 触发率 70%）；


• 复杂任务（如 AIME）中，CoT 触发率达 100%，效果与 Seed1.6-FullCoT 相当，验证了自适应思考对 Long CoT 推理优势的保留。

以上就是豆包能够在今年高考全科目评测中脱颖而出的原因了。

不过除此之外，还有一些影响因素值得说道说道。

正如我们刚才提到的，化学和生物的题目中读图题占比较大，但因非官方发布的图片清晰度不足，会导致多数大模型的表现不佳；不过 Gemini2.5-Pro-0605 的多模态能力较突出，尤其在化学领域。

不过最近，字节 Seed 团队在使用了更清晰的高考真题图片后，以图文结合的方式重新测试了对图片理解要求较高的生物和化学科目，结果显示 Seed1.6-Thinking 的总分提升了近 30 分（理科总分达 676）。

这说明，全模态推理（结合文本与图像）能显著释放模型潜力，是未来值得深入探索的方向。

那么你对于这次大模型们的 battle 结果有何看法？欢迎大家拿真题去实测后，在评论区留言你的感受~

评分明细详情：

bytedance.sg.larkoffice.com/sheets/QgoF…

欢迎在评论区留下你的想法！

— 完 —

AI 端模型与前端开发的新时代

随着技术的发展，人工智能（AI）正以前所未有的速度融入我们的生活。从前端到后端，从移动应用到物联网设备，AI的应用场景越来越广泛。特别是在前端领域，AI技术的引入为网页开发带来了前所未有的机遇。

什么是脑神经网络库（Brain.js）

在前端领域，Brain.js 是一个非常受欢迎的库，它允许开发者在浏览器中直接使用神经网络进行各种任务，如文本分类、图像识别等。Brain.js 的一大优势在于其易于上手，即使是没有深厚机器学习背景的开发者也能快速开始使用。

Brain.js 在前端开发中的应用

数据准备

首先，我们需要准备用于训练神经网络的数据。这些数据通常以JSON数组的形式存在，每个元素包含输入（input）和输出（output）。例如，在以下示例中，我们准备了一组关于前端和后端开发的知识点，用于训练一个能够区分两者差异的神经网络。

const data = [

  { "input": "implementing a caching mechanism improves performance", "output": "backend" },

  // 更多数据...

];

神经网络初始化

接下来，我们使用 brain.recurrent.LSTM() 函数初始化一个长短期记忆（LSTM）神经网络。LSTM是一种特殊的递归神经网络（RNN），特别适合处理序列数据，如文本或时间序列。

const network = new brain.recurrent.LSTM();

模型训练

有了数据和神经网络之后，我们就可以开始训练模型了。训练过程可能需要一些时间，具体取决于数据集的大小和复杂度。network.train() 方法接受数据集作为参数，并允许设置训练的迭代次数和其他选项。

network.train(data, {

  iterations: 2000, // 迭代次数

  log: true,       // 是否打印训练日志

  logPeriod: 100   // 日志打印频率

});

应用模型

一旦模型训练完成，我们就可以使用 network.run() 方法对新的输入进行预测。例如，我们可以测试模型是否能正确地将“使用Flexbox布局”归类为前端开发。

const output = network.run("using flexbox for layout");

console.log(output); // 输出结果

完整代码

<!DOCTYPE html>

<html lang="en">

<head>

  <meta charset="UTF-8">

  <meta name="viewport" content="width=device-width, initial-scale=1.0">

  <title>AI 端模型- 前端开发的时代</title>

</head>

<body>

<script src="./brain.js"></script>

<script>

// json 数组  

// 输入  input

// 喂给大模型的数据 

const data = [

  { "input": "implementing a caching mechanism improves performance", "output": "backend" },

  { "input": "hover effects on buttons", "output": "frontend" },

  { "input": "optimizing SQL queries", "output": "backend" },

  { "input": "using flexbox for layout", "output": "frontend" },

  { "input": "setting up a CI/CD pipeline", "output": "backend" },

  { "input": "SVG animations for interactive graphics", "output": "frontend" },

  { "input": "authentication using OAuth", "output": "backend" },

  { "input": "responsive images for different screen sizes", "output": "frontend" },

  { "input": "creating REST API endpoints", "output": "backend" },

  { "input": "CSS grid for complex layouts", "output": "frontend" },

  { "input": "database normalization for efficiency", "output": "backend" },

  { "input": "custom form validation", "output": "frontend" },

  { "input": "implementing web sockets for real-time communication", "output": "backend" },

  { "input": "parallax scrolling effect", "output": "frontend" },

  { "input": "securely storing user passwords", "output": "backend" },

  { "input": "creating a theme switcher (dark/light mode)", "output": "frontend" },

  { "input": "load balancing for high traffic", "output": "backend" },

  { "input": "accessibility features for disabled users", "output": "frontend" },

  { "input": "scalable architecture for growing user base", "output": "backend" }

];

// 初始化一个神经网络

const network = new brain.recurrent.LSTM();

// 训练 花蛮长时间

network.train(data,{

  iterations: 2000,

  log:true,

  logPeriod:100

});

// 执行一下

 const output = network.run("using flexbox for layout");

console.log(output);

</script>

</body>

</html>

前端与AI融合的未来

随着技术的进步，AI在前端的应用将更加广泛。从智能表单验证到个性化推荐系统，从前端性能优化到用户界面的自动设计，AI技术为前端开发提供了无限的可能性。此外，随着端侧模型（如AGI端侧模型）的发展，未来的设备将变得更加智能，能够即时响应用户的需要，提供更加个性化的体验。

最后，AI与前端开发的结合不仅提升了用户体验，也为开发者带来了新的挑战和机遇。通过不断学习和探索，我们能够在这个充满活力的领域中创造出更多令人兴奋的作品。

大家好，我卡颂，专注于AI助力程序员转型（阅读我的更多思考）

最近DeepSeek R1爆火。有多火呢？连我爷爷都用上了，还研究起提示词工程来了。

大模型不断发展对我们前端工程师有什么长远影响呢？本文聊聊25年前端会有的一个小趋势。

模型进步的影响

像DeepSeek R1这样的推理模型和一般语言模型（类似Claude Sonnet、GPT-4o、DeepSeek-V3）有什么区别呢？

简单来说，推理模型的特点是：推理能力强，但速度慢、消耗高。

他比较适合的场景比如：

• Meta Prompting（让推理模型生成或修改给一般语言模型用的提示词）


• 路径规划

等等

这些应用场景主要利好AI Agent。

再加上一般语言模型在生成效果、token上下文长度上持续提升。可以预见，类似Cursor Composer Agent这样的AI Agent在25年能力会持续提升，直到成为开发标配。

这会给前端工程师带来什么进一步影响呢？

一种抽象的理解

我们可以将AI Agent抽象得理解为应用压缩算法，什么意思呢？

以Cursor Composer Agent举例：

我们传入：

• 描述应用状态的提示词


• 描述应用结构的应用截图

AI Agent帮我们生成应用代码。

同样，也能反过来，让AI Agent根据应用代码帮我们生成描述应用的提示词。

从左到右可以看作是解压算法，从右往左可以看作是压缩算法。

就像图片的压缩算法存在失真，基于AI Agent抽象的应用压缩算法也存在失真，也就是生成的效果不理想。

随着上文提到的AI Agent能力提高（背后是模型能力提高、工程化的完善），应用压缩算法的失真率会越来越低。

这会带来什么进一步的影响呢？

对开发的影响

如果提示词（经过AI Agent）就能准确表达想要的代码效果，那会有越来越多原本需要用代码表达的东西被用提示词表达。

比如，21st.dev的组件不是通过npm，而是通过提示词引入。

相当于将引入组件的流程从：开发者 -> 代码

变成了：开发者 -> 提示词 -> AI Agent -> 代码

再比如，CopyCoder是一款上传应用截图，自动生成应用提示词的应用。