非计算机专业毕业的我，能在开发岗位干十年，现在又成功转型到项目负责人，属实不易，一路走来充满了努力和机遇。

作为一个奔四的人，在而立和不惑之间，我想写几条忠告给马上就要经历这些，和正在经历这些的人。

以下内容写给普通人和普通岗位：

1. 你认为错误的方案同样会有正确的结果，甚至更好。

《这就是马云》书中讲了一个马云的故事：

在一次会议上，有员工问马云：“马总，如果您的决定，出现了明显的错误，谁来制衡您？”

马云很平静地说了三点： “第一，公司没有人可以制衡我； 第二，如果我已经做了决定，哪怕错误的也必须执行； 第三，你们都认为是错误的决定，并不一定就是错误的。”

有些你认为错误的事情，你领导的资源、信息和操盘能力也能做出比你认为正确的做法更好的结果

打工人你需要有作为打工人的觉悟。

听话 和 能干，上层首先需要的是听话。

2. 努力维护你的人设

每个人都会有一个人设，要么来自你自己，要么来自其他人。

出来混，你必须维护一个对你有利的人设，否则其他人就会给你贴上一些标签。

一旦被打上负面标签，你付出十倍努力也很难纠正过来。

3. 保持学习，但不要只学技术。

人到中年，支撑你继续走下去的能力中，技术只是一部分。

更多的是我们的眼界和视野，我们的领导能力，我们对业务的理解能力，我们对周边资源的把握和运用能力。

这些东西是做纯粹的技术工作所不能得到的。

看书也好，报课也好，多学习一些新的东西，你学习的东西可能会过期，但也可能会伴随你一生。

但那都不重要，重要的是你在学习过程中沉淀下来的东西，那才是你学习的价值。

4. 当你为自己做事时，不要追求眼前的成果

当你在写博客、学一个新的东西、或者其他什么事情。

有些时候，你会产生一种疑惑：“我现在做的事情有用么？”

把我老师的话转达给各位：“你就傻一点，你就当它有用。”

坚持下去，当你的路走的很难时，它很可能是一条上坡路。

5. 放弃你的强迫症与完美主义

在商业社会你的完美主义和强迫症除了让你自己心里很爽之外，并没有太多好处。

先完成后完美，凡所有事都有阶段，里程碑式的按阶段与整个事件的干系人进行沟通、汇报，远比自己闷头把事情做成自己想象中的完美更重要。

产品不是作品！

6. 如果你想晋升，你领导相信你能胜任比你真的能胜任更重要

信任比能力更重要。

这条说多了不好，你信我的就完了。

7. 如果你对一件事情感到恐惧，而你又需要它时，去学去练去做。

比如演讲或者骑行，去做你就会发现这不难，一旦你开始做了，事情就变得不一样了。

让自己体验成功的滋味，让自己习惯成功。

成功过的人更容易成功，他们了解成功的滋味并且知道成功比看起来更容易。

8. 你会很忙，要学会管理你的时间。

更高效的利用你的时间，你才能让自己更健康的发展。

如果你除了工作之外什么都没做，还总觉的时间不够，可以看一下你的王者荣耀游戏时长，它会告诉你，你还有多少空闲时间未被利用。

结语

看到这里的基本都是自己人了，咱们就说直白点，想要度过中年危机，你要做的核心两件事是：

1. 提高自己的价值。

什么是提高自己的价值？ 先问一个问题：在企业里你是应该不断提高自己的竞争力还是提高的自己价值？

要回答这个问题，先要搞清楚什么是价值、什么是竞争力。

高竞争力不等于高价值。

你的价值来源于你的领导、你的企业对于你能够为企业带来的收益的评估。

而竞争力，只来源于你本身。

企业只会为你能够给企业带来收益的部分能力付费！你是个前端，还精通通背拳和民族舞。

企业不会为你民族舞的能力给你发工资，只会让你年会上去表演。

2. 控制和扩张自己的欲望。

你应该控制和扩张自己的欲望。

控制你对自己无法把握的事情的心态（巨额的超前消费、对未来的焦虑）。

扩张你能把握的事情：自己的个人能力版图，经济版图的欲望。

把你的欲望用在能够给自己带来收益的地方！

加油，共勉！

引言

前两天在沸点里发起了一个讨论，面对职业生涯的担忧，出现最多的问题是

• 失业了怎么办


• 失业了去做什么

还有不少类似的问题：比如技术更新太快了，担心自己跟不上怎么办；AI发展这么快，会不会取代程序员。

其实网上关于一些出路的话题数不胜数：

• 比如有人靠短视频一夜爆红，赶紧入局抖音和小红书


• 还是去做点闲鱼或者别的副业，争取赚到一点外快


• 还是投身知识付费，打造个人IP

我感觉这并不是大家想要知道的东西，因为这都是别人的答案，但人生不存在标准答案。

看起来大家在讨论“失业”，但我认为背后的真正问题是：我们不知道如何面对未来的不确定性。

我们真正需要的是——面对不确定性的思考路径，先来看看我们为什么会有对职业生涯不确定性的焦虑。

为什么会陷入这种焦虑

职业生涯发展路径从清晰到模糊

五六年前，几乎没有人担心程序员失业。那时候大家的目标都很明确，进大厂、升高P、做架构、拿高薪。

招聘平台上机会令人眼花缭乱，互联网发展依然轰轰烈烈。

只要有基础的开发经验，准备好八股文，就也可以进入一些不错的公司，然后踏上初级到资深的成长路径。

但时代变了。

随着行业增速放缓、招聘岗位减少、频繁的“人员优化”，还有年龄门槛提高，当下开发人员不可避免的遇到了几个现实：

• 岗位减少；


• 人员要求变高；


• 上升通道模糊；

归根结底还是因为行业发展接近饱和。根据2024年12月的数据，互联网渗透率达到78.6%，增速放缓，需求收缩成为必然。

而这种变化，不只存在于程序员行业，这也是各行各业年轻人职场的主旋律。

程序员价值似乎变得“可被替代”

曾经深厚的技术能力是程序员的护城河，但随着AI的发展，程序员与从未接触过开发的人之间的差距正在快速填平。

我想无论你的技术能力多强，遇见问题你也会去问一问Chat GPT，有时候你甚至都不用描述你遇见什么问题，一个报错的截图就能让AI去帮你分析。

更何况AI 写代码、Copilot 自动补全、层出不穷的AI开发工具诞生，现在网上的一个说法是，曾经你需要5w员才能找到的顶级程序员，你现在只需要20美金就可以雇佣到了。

越来越多公司希望用“少数精英 + 自动化工具”完成更多的工作，研发人员的公司普遍较高，因此在一些对技术要求没有这么高的公司，削减研发一定是趋势。

技术思维的局限

程序员通常习惯于用“逻辑闭环”和“解决问题”的方式思考：输入→处理→输出，bug → debug → ok。

这种思维方式虽然在写代码时非常有用，但在面对复杂、不确定的现实世界时，反而容易带来两种误区：

• 第一个是过度依赖“确定性”解决方案。 想找到“最优语言”“最火框架”“保底职业路径”，但现实世界没有完美解。未来是多变量博弈的结果，不是单一函数求值。


• 第二个是忽略非技术因素的重要性很多程序员明明技术很强，却因为沟通不畅、不了解业务、缺乏影响力而陷入职场瓶颈。成长不仅是把代码写好，更是理解“代码背后的世界”。

技术思维让我们成为优秀的“解题者”，但如果不升级思维方式，我们很难成为真正的“破局者”。

高手怎么应对不确定性

拆解与应对不确定性

既然谈到不确定性，影响职业生涯是有非常多的变量影响的。

就拿程序员来说，我们能够掌控的变量有解决问题的能力、行业经验、技术能力，当然也有一些是我们不能控制变量，比如新技术变革、行业发展态势、经济形势等。

这么多变量加在一起，就算是一个数学公式，我们也可以想见这个公式是很复杂的，那么对应到我们的真实工作生活，其复杂性就更不必说。

核心在于，对于你能控制的变量，不妨有计划的一项项去改进，如果你做的某一件事情，对与你想改进的地方没有帮助，那么不妨先放放别做。

对于不可控制的变量，我们不要试图去控制或者预测它们，因为我们做不到。

多年前大学毕业后，我选择留在了老家工作，后来和去北京的大学室友聊天时，我发现了我们之间在技术、眼界、薪资上的巨大差距。

因为二线城市和一线城市的工作机会、发展速度是完全不同的，我认为不能寄期望于城市未来的发展，但是我可以选择在哪里工作。

因此最终选择离职，准备了大量的八股文，最后去北京工作。

你或许也已经发现了一些传统开发岗位已经趋于饱和，但是在AI、机器人、芯片领域却存在着大量的人才需求，我们是不是可以尝试着学习这些完全陌生的知识。

也许你会说这些AI相关的岗位对于学历、经验有着很高的要求，普通程序员很难直接转向这个方向的研发。那么我们是不是可以把工作中的工作尝试着用AI来做一遍，起码把事务类、重复类的工作先解决掉再说。

当然最重要的是学会取舍，无论是换公司还是换城市，或者走完全不同的技术路线，都要放弃一些什么。

战胜认知偏误

认知偏误有很多种，今天我想说一点，心理学家对此叫做“自利性偏差”。

自利性偏差有两点，第一是如果这件事情我没做好，那肯定是因为不可控的、别人的、或者意外的缘故；第二是如果我做这件事情成功了，那肯定是因为我水平高。

客观的讲，虽然不像一些80后吃到了所有互联网的红利，我算是赶上了互联网发展的末班车。17-22年在北上广深找工作并不难，不但互联网快速发展，而且出现了如大数据、P2P、区块链技术，如果把控好这些风口，无论是职位还是薪资，都可以快速提升。

但是那时候很多人、包括我自己，都没有认识到这种薪资和职位的提升，很大程度上是源于整体经济、行业发展乃至于公司业绩带来的。

自利性偏差或许会让你自我感觉良好，让你更容易放松对自己的要求，进而更可能在某一个职位上躺平。

所以我们需要学会识别运气和技艺，你说过去过去怎么工作这么好找，每次跳槽都能涨薪，现在怎么不行了？那可能是你处于时代红利期，是非常幸运的。

真正的能力，是即使行业不景气、红利消退，也能有清晰的目标、稳定的输出和不断增长的竞争力。

认清运气，提升技艺，才能穿越周期。

拥抱和增加不确定性

普通人刻意避免不确定性，但是勇敢的人应该主动拥抱不确定性。

是主动拥抱，而不是不惧怕不确定性。

我认识的一个前同事，他每隔一段时间就会刷刷招聘软件，了解行业要求和发展趋势，也会时不时面试来测试自己的竞争力。

既然我们明知很多时候我们没办法在一家公司待一辈子，与其等着被动离开，不如主动保持战斗力。

当然，我们也并不一定一直做程序员。

现在有一句话很火，叫做主业求稳定，副业求发展，尝试各种各样的副业，就是在主动拥抱不确定性。

除了一部分特别热爱技术的在做开源项目、独立产品外，其实更多的朋友副业做的是和技术不相干的事情。

如果从现在开始，利用时间学习一个编程以外的技能，比如写作、销售、演讲、获客等能力，拥抱陌生领域带来的不确定性， 我想就不会只纠结程序员的未来发展了。

无论是担心现有公司能否稳定，还是担心未来程序员的就业问题，我们都可以从目标思维转变为选项思维，通过拥抱不确定性，给自己增加更多的可能性。

说在最后

如果你正在焦虑当前的工作、对未来的职业发展感到迷茫，不妨换一个视角：

• 放下寻找“唯一解”的执念；


• 识别并增强自己可控的变量；


• 主动为自己增加新的可能性。

程序员的核心竞争力，从来都不只是“技术”，而是我们面对变化的反应力与创造力。

希望这篇文章，能成为你面对不确定性的一点微光。

这是东东拿铁的第76篇原创文章，欢迎关注～如果你喜欢这篇的内容，欢迎点赞、转发或留言。也欢迎关注我，一起探讨更多有关程序员成长、职业认知、AI时代破局的话题。

移动端触摸手势库 AlloyFinger，配上 Vue 的 v-finger 指令，让「点、滑、捏、转」都能用声明式写法搞定，一起看看吧。

一、为什么需要 AlloyFinger？

在 H5 里，原生 touchstart / touchmove / touchend 只能告诉你「手指动了」，至于用户是单击、双击、长按、滑动、双指缩放还是旋转，都要自己算时间差、距离、角度——既难写又容易出 bug。

AlloyFinger 是腾讯 AlloyTeam 开源的轻量级手势库，把这些常见手势都封装好了，并且提供了 Vue 插件，以自定义指令 v-finger 的形式在模板里绑定，写法清晰、易维护。

二、安装依赖

在项目根目录执行：

npm install alloyfinger

三、在入口文件中注册插件

在 Vue 入口文件（如 src/main.js）中做两件事：

这样全局就可以在任意组件的模板里使用 v-finger 指令。

// 引入 alloy-finger

import AlloyFinger from 'alloyfinger'

import AlloyFingerPlugin from 'alloyfinger/vue/alloy_finger_vue'

Vue.use(AlloyFingerPlugin, {

  AlloyFinger

})

注意：

• 插件路径是 alloyfinger/vue/alloy_finger_vue


• 必须把 AlloyFinger 通过 Vue.use 的第二个参数传进去，插件内部会用它来创建手势实例。

四、在模板里使用 v-finger

注册完成后，在任意 Vue 组件的模板中，给需要绑定手势的单个根元素写上 v-finger:事件名="方法名" 即可。

4.1 语法形式

<div

  v-finger:tap="onTap"

  v-finger:swipe="onSwipe"

  v-finger:long-tap="onLongTap"

>

  可触摸区域

</div>

• 指令名：v-finger


• 修饰符：冒号后面是事件类型，如 tap、swipe、long-tap、pinch、rotate 等。


• 值：当前 Vue 实例上的方法名，与普通 @click 一样写在 methods 里即可。

4.2 支持的事件

需要传参时，在方法里接收事件对象即可（如 swipe(evt) 中的 evt.direction、pinch(evt) 中的 evt.zoom）。

4.3 完整示例

模板：

<template>

  <div

    class="touch-area"

    v-finger:tap="tap"

    v-finger:long-tap="longTap"

    v-finger:swipe="swipe"

    v-finger:pinch="pinch"

    v-finger:rotate="rotate"

    v-finger:double-tap="doubleTap"

    v-finger:single-tap="singleTap"

  >

    <div>点我、长按、滑动或双指操作</div>

  </div>

</template>

脚本：

export default {

  methods: {

    tap() {

      console.log('单击')

    },

    longTap() {

      console.log('长按')

    },

    swipe(evt) {

      console.log('滑动方向:', evt.direction)

    },

    pinch(evt) {

      console.log('缩放比例:', evt.zoom)

    },

    rotate(evt) {

      console.log('旋转角度:', evt.angle)

    },

    doubleTap() {

      console.log('双击')

    },

    singleTap() {

      console.log('单击（与双击区分）')

    }

  }

}

按需绑定自己用到的几个事件即可，不必全部写上。

五、用法很简单，那AlloyFinger是怎么实现的呢？

了解实现原理，有助于我们更放心地使用、排查问题，甚至做简单扩展。

AlloyFinger 的实现可以拆成两层：底层手势识别（alloy_finger.js） 和 Vue 指令封装（alloy_finger_vue.js）。

5.1 底层：基于原生 Touch 事件 + 向量运算

AlloyFinger 不依赖任何框架，核心就是给一个 DOM 元素绑定四个原生事件：

this.element.addEventListener("touchstart", this.start, false);

this.element.addEventListener("touchmove", this.move, false);

this.element.addEventListener("touchend", this.end, false);

this.element.addEventListener("touchcancel", this.cancel, false);

在 start 里：

• 记录第一个触点的坐标 (x1, y1)和当前时间戳；


• 用「上次 tap 的时间」和「两次点击的位移」判断是否构成双击（例如 250ms 内、位移 30px 以内）；


• 若检测到多指（evt.touches.length > 1），则计算两指构成的向量长度，作为后续 pinch 缩放的基准，并触发 multipointStart；


• 同时启动一个 750ms 的定时器，到时即触发 longTap。

在 move 里：

• 若是单指，则用当前点与上一帧点的差值得到 deltaX、deltaY，触发 pressMove；


• 若移动距离超过约 10px，会置位 _preventTap，避免误触 tap。


• 若是双指，则用两指构成的向量做向量长度比得到 evt.zoom（pinch），用向量夹角得到 evt.angle（rotate），这里用到简单的向量数学（点积、叉积、夹角），核心逻辑类似：

// 向量长度

function getLen(v) {

  return Math.sqrt(v.x * v.x + v.y * v.y);

}

// 缩放：当前两指距离 / 起始两指距离

evt.zoom = getLen(v) / this.pinchStartLen;

// 旋转：当前向量相对上一帧向量的角度

evt.angle = getRotateAngle(v, preV);

在 end 里：

• 若「起点到终点的位移」超过约 30px，则根据 x、y 方向位移谁更大来判定 swipe 方向（Left/Right/Up/Down），并触发 swipe；


• 否则在下一个「事件循环」里触发 tap，并根据之前的双击标记决定是否再触发 doubleTap 或延迟 250ms 触发 singleTap；


• 同时会清除 longTap 定时器、重置双指相关的状态。

也就是说：tap / longTap / doubleTap / swipe / pinch / rotate / pressMove 等，都是在同一套 touch 生命周期里，用「时间差 + 位移 + 向量运算」推导出来的，没有黑魔法。

5.2 回调管理：HandlerAdmin

每种手势对应一个「回调列表」，用 HandlerAdmin 统一管理：add 注册、del 移除、dispatch 时对该元素上的所有回调依次 apply。这样同一个元素上可以挂多个监听（例如 Vue 插件里对同一元素绑定多个 v-finger:xxx），彼此也不会互相覆盖。

5.3 Vue 插件层：v-finger 如何挂到 DOM 上

插件在 install 时执行 Vue.directive('finger', directiveOpts)，因此模板里的 v-finger 会变成对自定义指令 finger 的调用。

• 事件名映射：模板里写的是 kebab-case（如 v-finger:long-tap），插件里用 EVENTMAP 转成 AlloyFinger 的 camelCase（如 longTap），再交给底层。


• 一元素一实例：用一个全局 CACHE 数组，按 DOM 元素存 { elem, alloyFinger }。同一元素上多条 v-finger:tap、v-finger:swipe 等，共用一个 AlloyFinger 实例；第一次绑定时 new AlloyFinger(elem, options)，之后同元素再绑其他事件时，不再 new，而是 alloyFinger.on(eventName, func) 往该实例上追加回调。


• 指令生命周期：Vue2 下 bind / update 时执行 doBindEvent（绑定或更新回调），unbind 时从 CACHE 里取出实例并调用 alloyFinger.destroy()，移除原生事件监听和所有定时器，避免内存泄漏。

核心片段：

// 同一元素多次 v-finger:xxx 共用一个 AlloyFinger 实例

var cacheObj = CACHE[getElemCacheIndex(elem)];

if (cacheObj && cacheObj.alloyFinger) {

  if (oldFunc) cacheObj.alloyFinger.off(eventName, oldFunc);

  if (func) cacheObj.alloyFinger.on(eventName, func);

} else {

  CACHE.push({

    elem: elem,

    alloyFinger: new AlloyFinger(elem, { [eventName]: func })

  });

}

5.4 小结

• 手势识别：完全基于 touchstart / touchmove / touchend，用时间、位移和向量运算区分 tap、doubleTap、longTap、swipe、pinch、rotate、pressMove 等。


• Vue 层：通过自定义指令 v-finger 和元素级 AlloyFinger 实例缓存，把「模板里的 v-finger:事件名」映射到「底层 AlloyFinger 的 on/off」，实现声明式绑定与组件销毁时的清理。

参考

• AlloyFinger 仓库：AlloyTeam/AlloyFinger


• 依赖：transformjs

飞哥数智谈，现居于济南，AI提效、AI编程实践者，AI·Spring社群发起人，同时，担任 TRAE Friends 社区济南 Fellow，致力于AI 提效与AI编程落地。

这两天，不管是自媒体平台，还是私人的朋友圈，含“虾”量过高，人人都在决定成为养虾户。

但就在大家玩得不亦乐乎的时候，工信部的一次“点名”，希望可以让大家稍微冷静一点。

文章我仔细读了下，从自己的角度和大家聊聊这个事儿。

openclaw 为什么火

首先， openclaw 为什么会火呢？

经过和社群许多人的讨论，我感觉重要的有以下几点：

• 便捷：不需要各种智能体，只需要在常用聊天工具（ openclaw 的 Channel ）中对话即可。


• 主动：不像其他智能体只会被动回复， openclaw 可以自主干活、主动给出反馈。


• 能力强：这个其实并不是 openclaw 自身的能力，更多的是各位 Skill 开发人员构建的强大生态，你想做什么，目前几乎都可一键安装。

热火中的一盆冷水

可能因为追求效率的原因， openclaw 本身的安全性并没有做得很到位。

这在前期的火热中可能被遮盖了，但官方适时地做出了提醒：

“信任边界模糊”+“自主权限大”+“缺乏安全加固”，可能造成信息泄露、系统失控等安全风险。

其实结合我个人的实践经验，风险就两类：

• 安全风险：安装 openclaw 的机器可能会被控制，进而造成危害。


• 数据风险：由于模型幻觉的存在， openclaw 可能做出误删除而导致数据丢失。

但我们其实也不能苛求这么多，毕竟 openclaw 最初设计出来是给作者自己作为 AI 助理使用的。

并且，这些风险也不是说不可避免。

• 安全风险其实在默认配置基础上进行加固，并关闭非必要端口，就能大大提升安全性。


• 数据风险则更为简单，只要针对重要数据做好额外的备份机制，就能很大程度避免问题发生。

更落地一点：初学者不建议在主力生产机器上安装 openclaw。

我们最近的工作

前面的风靡和风险其实也正是我们 AI·Spring 社群最近《养虾记》系列活动的出发点。

第一，由于 openclaw 生态的逐渐成型，我们认为龙虾不仅仅是一个智能体，更像一个平台，就像小程序一样，可以成为很多人创造的基座，我们希望成为大家创造故事的一个后盾。

第二，则是基于 openclaw 的技术现状，我们期望通过这个系列活动，让更多的人真正了解 openclaw，认识风险，处理风险，最后可以安全的讲完自己的故事。

结语

针对 openclaw，我还是一贯的观点：

工具没有对错，我们需要做的就是学习掌握工具的优缺点，扬长避短。

你的“龙虾”今天帮你干了什么蠢事？或者立了什么大功？评论区聊聊，让我们一起避坑！

在第二季度的那三个月中发生了很多变化，导致制定的 OKR 虽然有去做，但绝大部分事项没有开展落地。

那期间的经历所产生的憋屈、无奈、失望、无趣、愤怒等，它们交织在一起形成了至今仍笼罩在我心头的阴霾，挥之不去。

但这也对我产生了积极作用，逼迫我弄得更明白自己到底应该怎样——在获得我想要的「自由」之前，一切事情以我获得「自由」为优先，阻碍与拦截者拒绝或铲除之！

因此，在对现在的人来说很重要的两个方面我下了坚定决心：

这都是为了自己能够尽早「破局」以获得「自由」，也就是「不再为了钱而扭曲自己的意志」，我唯有破釜沉舟，孤注一掷。

今后基调

如果你是我的朋友或关注、关心我的人，相信一定会有以下几个关键问题想问，我对它们的回答构成了我日后生活与工作的基调。

打算做些什么？

我此后余生的使命是「建设自己理想中的乌托邦」，即「欧托邦」——助力他人做自己，成为「超级个体」而不用去给别人打工，过自己热爱的生活，夺回本应属于自己的权利。

我会结合个人社区「欧雷宇宙」去推进实施，吸引同行者，并借助他们的力量将理想化为现实！为实现理想，不排除与他人共同发起其他社区、DAO 等组织的可能。

第一阶段是平台构建期，我要以提供「个人与家庭数智化」领域的解决方案为切入点给他人创造价值——

在「个人」的应用层面，我在构思一个基于个人知识库、个人网站的庞大的去中心化内容、社交网络，可以说这将我之前想做的一些东西给串起来了。

Knowledge as Infrastructure——你的知识、知识库，可以构建成个人网站的文章等让互联网上的人阅读，也可以成为其他内容社区或平台的一部分，更可以作为自己或他人的 AI 智囊的食料。

Personal Website as Community——他人在自己个人网站上的每一次互动、每次付费等都会积累相应的社区贡献值；当你这个「主理人」精心经营好自己的网站/社区提高影响力时，那些贡献高、活跃的人也一定程度提高了自身价值。

这是一个以「个体」为核心，以「人」为本，助力成为「超级个体」网络的数字世界。

其背后，可以将各类数据对接进我在「家庭」层面的系统——FRP——Family Resource Planning。

每个人在精神独立后就可以成为一个「家庭」，当与另外一个人结合后，两个「家庭」可以合并为一个「家庭」。

当你把自己的人生当作是一家企业来经营时，那么 FRP 就是你所需的方法与工具，它能够帮助你的家庭生活和人生进行更好地监测与规划，助力成为「人生赢家」并保持这个状态。

欧雷的想法

下图为解决方案目前的核心构成要素：

其中，涉及商业化的源代码不会开源，其他部分皆考虑开源。

我会积极主动地多参加黑客松，这样一来可以倒逼自己推进产品开发，向更多人介绍自己的理念与产品，汲取他人的意见与经验，还有可能赚点生活费。

如何支撑生活？

因为坚决不再「打工」，也就没了所谓的「稳定收入」，自然而然又要进入消耗余粮阶段。说到这，在 2023 年 1 月失业后的种种体验和回忆立马涌了上来……

不过，我认为此刻较彼时相对乐观一些：

鉴于此，为了生存，除了削减开支外，收入方面我要采取的方案是：

那么，第一个小目标就是被动收入完全覆盖日常支出！

钱没了怎么办？

即便可能性较小，但只要不是全无可能，就得做好最糟情况的心理准备——余粮见底了。

若是真有那天，估计我的婚姻也十有八九完蛋了，那我会将无带款的房产留给她，开了十来年的汽车和完全我用的东西归我。

届时我以车为「房」或回故乡啃老，先极力降低生活成本并减小生存压力，再通过接外包找兼职等重新积累粮草，择机东山再起。

只要心不死，纵然失败千百回，终有成功之日——我对此坚信不疑！

下一步行动

目前来看，即使我决定不再「打工」了，于《进入破局第二阶段》中定的阶段目标仍可继续去推进实现，不太受影响。

算上前文提到的，下半年我主要去做以下几方面的事：

• 提升月均投资理财收益；


• 开发出可用的软件产品并产生收益；


• 探索可行的软件研发智能化方案；


• 加强个人社区与我本人及作品、产品的紧密性。

在 Q3 内要完成一个软件产品的 MVP 版，并尽量扫清商业化的基本障碍。

本文其他阅读地址：个人网站｜微信公众号

很多人以为在大厂工作，就是不停地写代码、解决技术难题。

但事实是：真正成功的工程师并不是那些代码写得最好的人，而是那些解决了代码以外事情的人。

本篇和你分享 21 条职场教训。

这些教训，有的能让你少走几个月的弯路，有的则需要数年才能完全领悟。

它们都与具体的技术无关，因为技术变化太快，根本无关紧要。

但这些教训，项目换了一个又一个，团队换了一批又一批，始终在重复上演。

希望能帮助到你：

1. 最优秀的工程师都痴迷于解决用户问题

很多人容易爱上一项新技术，然后到处找地方用它。

我干过，你肯定也干过。

但真正创造最大价值的工程师是反过来的：

他们专注于深入理解用户问题，并让解决方案从这种理解中自然而然地涌现。

以用户为中心意味着花时间处理支持工单，与用户沟通，观察用户遇到的困难，不断追问“为什么”，直到找到问题的症结所在。

真正理解问题的工程师往往会发现，优雅的解决方案比任何人预想的都要简单。

工程师如果一开始就想着如何解决问题，往往会为了寻找理由而人为地增加复杂性。

2. 正确很容易，共同达成正确才是真正的挑战

即使你在技术上胜券在握，最终也可能输掉项目。

我曾亲眼目睹一些才华横溢的工程师，自诩为房间里最聪明的人，但总是默默地积攒怨气。最终表现为“莫名其妙的执行问题”和“莫名其妙的阻力”。

关键不在于证明自己正确，而在于参与讨论以达成对问题的共识。

为他人创造发言空间，并对自己确信的观点保持怀疑。

3. 行动优先，先做，再做对，再做好

追求完美会让人停滞不前。

我曾经见过工程师花几周讨论一个从没建过的东西的理想架构。

但完美的方案很少从思考中产生，它都是从与现实的碰撞中产生。

先做出来，再做对，再做得更好。

把丑陋的原型放到用户面前，写出乱糟糟的技术文档初稿，发布那个让你有点尴尬的 MVP。

从真实反馈中学到的内容，哪怕只有一周，也远比一个月的理论辩论多得多。

4. 代码清晰远比炫技重要

我知道你想要写出酷炫的代码，那可以证明自己很牛逼。

但项目往往不止你一个人，以后还有其他同事要维护。

优化时要考虑他们的理解能力，而不是你的代码是否优美。

5. 谨慎选择新技术

新技术就像带款，你要用 bug、招聘困难和认知负担来还。

关键不在于“永远不要创新”，而在于“只在因创新可以带来独特报酬的领域进行创新”。其他的一切还是应该回归平庸。

6. 你的代码不会替你说话，但人会

刚开始工作时，我相信是金子总会发光。

但我错了。

代码静静地躺在仓库里。你的领导在会议上提到你，或者没提。同事推荐你参与项目，或者推荐了别人。

在大公司，决策是在你没被邀请的会议上做出的，用的是你没写的总结，由只有五分钟时间和十二件事要处理的人做出的。

如果你不在场时没人能清楚说出你的价值，那你的价值就等于可有可无。

这不是让你鼓吹自己，而是告诉你：你需要让你的价值被所有人看到。

7. 最好的代码是你根本不用写的代码

工程师文化崇拜创造。

没有人会因为删除代码而获得晋升，即使删除代码往往比添加代码更能改进系统。

因为你不写的每一行代码，都意味着你永远不必调试、维护或解释。

在动工之前，先仔细思考一下：“如果我们不做这件事会发生什么？” 有时答案是“没什么坏处”，那就是你的解决方案。

问题不是工程师不会写代码，而是我们太会写了，以至于忘了问：该不该写？

8. 大规模时，连你的 bug 都有用户

用户多的时候，连你的 bug 都会有用户，这产生了一个职业级洞察：

你不能把兼容性工作当“维护”，把新功能当“真正的工作”。兼容性就是产品。

所以把你的“废弃”做成“迁移”，带上时间、工具和同理心。

9. 慢实际上是因为不协调

项目进展缓慢时，人们的第一反应往往是责怪执行：员工不够努力、技术不成熟、工程师人手不足。

但通常来说，这些都不是真正的问题所在。

在大公司，团队是并发执行的基本单位，但随着团队数量的增加，协调成本呈几何级增长。

大多数效率低下实际上源于目标不一致——人们在做错误的事情，或者以不兼容的方式做正确的事情。

所以高级工程师花更多时间澄清方向、接口和优先级，而不是“写代码更快”，那些才是真正的瓶颈所在。

10. 专注你能控制的，忽略你无法控制的

在大公司，无数的变数都超出你的掌控——组织架构调整、管理决策、市场变化、产品转型等等。

过度关注这些因素只会让你焦虑不安，却又无能为力。

所以高效的工程师，会锁定自己的影响圈。你控制不了是否会重组，但你能控制工作质量、如何应对、学到什么。

这并非被动接受，而是策略性关注。

把精力浪费在无法改变的事情上，就等于浪费了原本花在可以改变的事情上的精力。

11. 抽象并不能消除复杂性

每一次抽象都是一种赌博，赌你不需要理解下面是什么。

有时候你会赢，但总会有漏洞，一旦出现漏洞，你就需要清晰地知道你站在什么上面。

所以高级工程师即使技术栈越来越高，也要持续学习“更底层”的东西。

12. 写作让表达更清晰，以教带学是最快的学习方式

写作能带来更清晰的表达。

当我向别人解释一个概念——在文档里、演讲中、代码评审评论里、甚至和 AI 聊天，我都会发现自己理解上的不足。

所以如果你觉得自己懂了什么，试着简单地解释它。卡住的地方，就是你理解肤浅的地方。

13. 注重粘合性工作

粘合性工作——例如写文档、帮新人上手、跨团队协调、流程优化——至关重要。

但如果你总是无意识地做这些，反而可能会拖慢技术成长，把自己累垮。

陷阱在于把它当“乐于助人”的活动，而不是当作有边界的、刻意的、可见的影响力。

尝试给它设时限，轮换做，把它变成产出物：文档、模板、自动化。

让它作为“影响力”被看见，而不是作为“性格特点”。

14. 如果你赢得每一场辩论，你很可能是在积累无声的阻力

当人们不再和你争，不是因为你说服了他们，而是因为他们放弃了。

但他们会在执行中表达分歧，而不是在会议上。

所以真正的共识需要更长时间。你得真正理解别人的观点，吸收反馈，有时候需要你当众改变主意。

短期“我是对的”的快感，远不如长期和心甘情愿的合作者一起建设的现实来得珍贵。

15. 当衡量标准变成目标时，它就停止了衡量

你暴露给管理层的每个指标，最终都会被博弈。

不是因为恶意，而是因为人会优化被度量的东西。

追如果你追踪代码行数，你会得到更多的代码行数。如果你追踪开发速度，你会得到过高的估算值。

高手的做法是：对每个指标请求都提供一对指标。一个用于衡量速度，一个用于衡量质量或风险。然后，坚持解读趋势，而不是盲目追求阈值。

目标是洞察，而非监控。

16. 承认自己不知道的事情比假装自己知道更能带来安全感

资深工程师说“我不知道”并不是示弱——他们是在鼓励大家坦诚面对。

当领导者承认自己的不确定性时，就等于在暗示其他人也可以这样做。如果不这样的话，就会形成一种人人假装理解、问题被掩盖直到爆发的文化。

我见过团队里最资深的人从不承认自己不明白，我也见过由此造成的后果。问题不被问出来，假设不被挑战，初级工程师保持沉默因为他们以为别人都懂。

17. 你的人脉关系比你拥有的任何一份工作都更长久

职业生涯早期，我专注于工作本身，忽视了人脉经营。回头看，这是个错误。

那些注重人脉关系的同事，在接下来的几十年里都受益匪浅。他们最先了解机会，更快地建立人脉，获得职位推荐，和多年来建立信任的人一起创业。

你的工作不会永远持续下去，但你的人脉网络却会一直存在。

以好奇心和慷慨的态度去拓展人脉，而不是抱着功利主义的心态。

当需要向前迈进的时候，往往是人际关系打开了这扇门。

18. 大多数绩效的提升来自于减少工作量

当系统变慢时，人们的第一反应往往是加东西：加缓存、并行处理、使用更智能的算法。

有时候这样做是对的。

但我发现，通过询问“我们计算了哪些不必要的东西？”往往能带来更多性能提升。

删除不必要的工作几乎总是比更快地完成必要的工作更有成效。最快的代码是永远不会运行的代码。

所以在进行优化之前，先问问自己这项工作是否真的应该存在。

19. 流程存在的目的是为了减少不确定性，而不是为了留下书面记录

最好的流程是让协调更容易、让失败成本更低。

最差的流程是官僚主义——它的存在不是为了帮忙，而是为了出事时推卸责任。

如果你无法解释一个个流程如何降低风险或提高清晰度，那么它很可能只是增加了额外开销。

如果人们花在记录工作上的时间比做工作的时间还多，那就说明出了大问题。

20. 最终，时间会比金钱更有价值

刚开始工作的时候，你用时间换钱——这没问题。

但到了某个阶段，情况就完全不同了。你会开始意识到，时间才是不可再生资源。

我见过一些高级工程师为了晋升而累垮自己，只为了多拿几个百分点的薪酬。有些人确实升职了，但事后大多数人都在反思，自己放弃的一切是否值得。

答案不是“别努力工作”，而是“知道你在交易什么，并深思熟虑地进行交易”。

21. 没有捷径，但有复利

专业技能源于刻意练习——略微超越现有水平，然后不断反思，不断重复。年复一年，没有捷径可走。

但令人欣慰的是：学习的进步在于创造新的选择，而不仅仅是积累新的知识。

写作——不是为了吸引眼球，而是为了清晰表达。构建可复用的基础模型。将过往的经验总结成行动指南。

所以如果工程师把职业生涯看作是复利投资，而不是彩-票，那么他最终往往会取得更大的成就。

22. 最后

21 条听起来很多，但它们可以归结为几个核心点：保持好奇，保持谦逊，记住工作始终是关于人的——你的用户、你的队友。

工程师的职业生涯足够长，可以犯很多错误。我最钦佩的工程师，不是那些什么都做对的人——而是那些从错误中学习、分享发现、并坚持不懈的人。

本篇整理自《21 Lessons From 14 Years at Google》，希望能帮助到你。

我是冴羽，10 年笔耕不辍，专注前端领域，更新了 10+ 系列、300+ 篇原创技术文章，翻译过 Svelte、Solid.js、TypeScript 文档，著有小册《Next.js 开发指南》、《Svelte 开发指南》、《Astro 实战指南》。

欢迎围观我的“网页版朋友圈”，关注我的公众号：冴羽（或搜索 yayujs），每天分享前端知识、AI 干货。

“现在大环境这么差，工作很难找了...”

“你这个位置来之不易，很多人挤破头来抢的...”

“你在新的公司也就一年半，出去后简历花了...”

“百万薪资拿着不好吗？为啥想不开要在这时候离职...”

大家好，我是孟健。

当我向 leader 提出离职申请的那一刻，办公室里的空气仿佛凝固了。

技术管理职位、丰厚薪资，还有无数人梦寐以求的大厂光环

——在很多人眼中，这是无法拒绝的诱惑。

但那一刻的我，内心异常平静。

今天，我想和大家完整分享一个技术人的蜕变故事：

从新疆山沟沟的孩子，到腾讯技术专家，再到如今的独立创业者。

这不是一个炫富的故事，而是关于认知觉醒、时代选择，以及在 AI 浪潮中寻找人生新方向的思考。

山沟沟出来的孩子

我出生在新疆克孜勒苏柯尔克孜自治州乌恰县。

这个名字太长，一般人记不住，所以我通常只说自己来自喀什。

那里的房子是这样的农村土房子，经历过大地震才重建。

我的起点非常低，从小所处的环境和教育都不太好。

学校里的体育老师都可以代课，念念课本就行。

幸运的是，国家对于这些贫困地区、少数民族地区有定向的扶贫政策，而我的学习成绩也还可以。

所以到了高中，我走出了新疆，来到了江西的一所还不错的学校。

那是我第一次离开家乡，十几年了，我基本上从未踏出过那个小村庄。

到了外地，我才感觉到教育水平的差距。

但我有一个信念：持续的努力可以带来改变。

2000 年，我第一次见证了互联网的魔力。

Windows 95 系统的笔记本电脑屏幕上，搜狐的首页缓缓展开。

就是那一刻，一颗种子悄然埋入了我的心底。

从 Frontpage 搭建简陋的网站，到用 VC 编写第一个"Hello World"，再到沉迷于 QQ 带来的社交乐趣。

每当看到腾讯的 Logo，我就会想：如果有一天能在这样的公司工作，该有多好。

当时的我，把这个想法深深藏在心里，像是一个遥不可及的梦。

高考后，我如愿考入了西安交通大学——这所充满历史底蕴的顶尖学府。

然而，真正的挑战才刚刚开始。在这个人才济济的地方，我才发现自己有多渺小。

没有选择计算机专业成了我最大的遗憾，一个简单的递归算法都能让我纠结好几天。

但正是这种"较真"的性格，让我在挫折中不断成长。死磕，成了我的标签。

给新人的第一个建议：相信持续努力的力量。

很多新人问我，起点低怎么办？天赋不够怎么办？

我想告诉大家的是：信念可以是一种天赋。

本质上，你是否相信持续的努力可以带来改变？

是否相信做一行爱一行，而不是爱一行做一行？

大家都知道龟兔赛跑的结果，都知道笨鸟先飞的故事，但是大部分人还是会被现实击垮，退缩，为什么？

因为没有信念，你不相信很多事情，所以看不见很多事情，自然也就做不成很多事情。

伴随着这个信念，我从新疆的小村庄一步步走到了西安交通大学。

能做到这一步，我觉得对我来说已经是非常幸运了。

到了大学，又遇到了同样的问题——身边的人都非常优秀，很难脱颖而出。

在校期间，从设计美工到前端开发，从后台架构到算法优化，每一个技术社团都留下了我的身影。

终于，在不懈的努力下，我拿到了一张通往互联网大厂的船票。

那一刻，我知道，山沟沟里的孩子，也能走出属于自己的路。

腾讯 8 年：一个技术人的完整蜕变

第一次为技术跳槽

"你的代码刚刚上线了，已经有超过一百万人在使用了。"

收到这条消息的那一刻，我的心跳漏了一拍。这是在腾讯的第一个项目——QQ 厘米秀。

每天打开后台，看着用户们的反馈如潮水般涌来：有赞美、有吐槽、有建议。

我常常在深夜里一条条查看这些留言，时不时还会收到用户的好友申请，他们热切地称呼我为"腾讯大佬"。

那种感觉，就像是漫漫长夜里终于看到了星光。

然而，技术圈的浪潮从不等人。

某天刷技术社区时，我突然发现自己站在了时代的孤岛上。

React、Vue、Webpack、Gulp......这些响彻业界的技术名词，对我而言却如同天书。

而我们的项目还在用着 jQuery 这个"老古董"，连基本的构建工具都没有，每天都在"刀耕火种"般地手动部署。

那种焦虑感油然而生。

凭借着还算不错的工作表现，我争取到了一次技术重构的机会。

导师和 leader 都给予了支持，我不知天高地厚，义无反顾地扎进了新技术的海洋。

然而现实给了我一记重拳——性能出现了劣化，工具链的改造也让团队措手不及。

那时我才明白，单打独斗的技术提升是多么艰难。

"我想去 IMWeb 团队。"

这个决定让我的总监足足和我谈了两个小时。

"我从来没有对其他人挽留这么长时间，"他说。

当时我将信将疑，直到多年后自己成为 leader，才明白这份真诚。

临别前，他留下了一句话："都是围城。"

这句话如种子般在我心里发芽，在之后的每一个选择前都会提醒我。

就这样，我选择了内部转岗到 IMWeb。

这是一个我仰慕已久的技术团队，他们举办的每一场技术大会都让我热血沸腾。

连续五星，快速成长

加入 IMWeb 后，我给自己定下原则：不设边界。

整个开发链路上，但凡觉得哪个环节"不够优雅"，我就一定要优化它。

从前端基建到监控平台，再到低代码转型，每一步都让我对技术有了更深理解。

书架上摞满了技术书籍，从设计模式到工程实践，每一本都写满了笔记和标签。

那段时间我常常工作到凌晨三点，办公室里只剩下我和显示器的蓝光。

清洁阿姨都会打趣："小伙子，你是不是把家搬到公司了？"

**"凡事有着落，进展有反馈。"**这是我总结出的工作法则。

每个项目我都设法做出亮点：

重构后的开发效率提升 50%，新开发的工具链将团队效率提高 30%，监控平台覆盖了整个业务线...

这些数据背后，是无数个加班的夜晚，无数次的推倒重来。

慢慢地，我开始跨界探索。后台架构、消息队列、数据仓库，这些"后端"的概念逐渐成为我的工作日常。

还记得第一次用 Go 语言重写监控系统时的忐忑，以及系统成功上线时的兴奋。

那种跨越技术边界的快感，让人上瘾。

三年时间，从 T9 到 T11，两次绿色通道提名，五次五星绩效。

每一次都是对付出的肯定。

但最让我感动的，不是这些头衔和数字，而是那种全情投入后的成就感。

这大概就是技术人的青春吧 —— 用代码书写理想，用汗水浇灌梦想。

那段全力奔跑的日子，永远是最珍贵的财富。

给新人的第二个建议：不设边界，持续超出预期。

很多新人进入职场后，容易把自己限制在一个很小的范围内。

"这不是我的工作"、"这个我不会"、"这个太难了"...

我想分享的是：在职场早期，最重要的是不设边界。

当你在一个大团队，竞争比较激烈，从上而下有一些阶级固化，有各方的势力，作为一个新人很容易沦落成小透明，成为炮灰。

当时我做了一个很重要的动作和选择：我的优势在于职级低，比较容易做到超出预期的事情。

于是我主动承担了很多脏活累活，比如基建、工具链、监控等等，这些都是大家不太愿意做的事情，但是对团队价值很大。

我花了大量的时间去研究这些技术，最终搭建了一套完整的研发流程工具。

信任来源于点滴积累，持续表现出靠谱的品质，持续地超出预期，就算你在一个大团队，照样可以发光发热的。

职场情商，如此重要

人生的至暗时刻，往往来得猝不及防。

一次跨部门汇报会上，我凭借过硬的技术实力，逐条分析其他部门方案的不足

——逻辑严密，有理有据。

但散会后，办公室里弥漫着诡异的沉默。

"你知道你今天得罪了多少人吗？"总监的话让我如梦初醒。

接下来的一周，我的提案被一再打回，跨部门协作遇到前所未有的阻力。

那段时间我开始失眠，每天靠着冥想入睡。

直到 +2 leader 的一句话点醒了我："职场最重要的，从来都不是你说了什么，而是你怎么说。"

原来在职场中，正确未必就是恰当，真理未必就要以最锋利的方式表达。

技术追求极致，但人心需要温度。

所谓职场情商，不是要你放弃原则，而是学会用更柔和的方式坚持原则。

在此之后，我去看了很多软素质相关的课程和书籍。

学会了，在表达时多一分善意，少一分锋芒。

给新人的第三个建议：技术是基础，软素质决定高度。

很多技术新人有一个误区，认为只要技术够强，就能在职场上无往不利。

但现实是：职场后期比拼的不是代码写得多快，而是如何与人协作，如何影响他人，如何解决复杂问题。

特别是当你想要晋升到更高的职级时，你会发现：

• 沟通能力比编程能力更重要


• 影响力比个人产出更重要


• 团队协作比个人英雄主义更重要

这不是说技术不重要，而是说在技术达到一定水平后，软素质成为了决定性因素。

从未经历过的大裁员

2021 年，教育双减政策让整个行业轰然倒塌。

作为管理者，我面临了职业生涯最残酷的时刻——亲手写下裁员名单。

表格里的每一行都是一个鲜活的生命：

• 小 W 刚在深圳买了房，月供还没开始第一期


• 老 Z 的二胎前不久才满月


• 小 L 昨天还在跟我讨论新项目的技术方案...

那个下午，我坐在显示器前，光标在一个个熟悉的名字上跳动。

每一次点击都像是一记重锤，击打在我的良知上。

最煎熬的是裁员沟通。那种无力感，至今想起仍会让我感到窒息。

业务调整，每一轮大概裁 30%。

你要残忍地提供名单，亲手把朝夕相处的，曾经并肩作战的伙伴，写上去。

管理对软素质的要求很高，不是人人都适合，能够承受得住。

当你管理几个人的时候，几十个人，几百个人的时候，承担的压力都不一样。

不止于此，后来我负责 QQ 的业务，整个桌面端跨端重构，同时对接四个产运团队。

每天基本都是做 PPT 汇报，每天考虑的事情是如何拿结果，做事的时间非常少。

那个时期管理层面的压力非常大，晚上会失眠。我也是每天去听冥想，避免焦虑变成抑郁。

这段经历让我深刻明白：我们都只是商业世界中的一颗棋子。

商业世界从不讲情面，我们都只是这个巨大机器上的螺丝钉。

技术再厉害，也抵不过时代的洪流。

2023，前端已死

当我发表了《我逆向分析了 Github Copilot》引发技术圈热议时，我觉得自己终于站在了技术浪潮的前沿。

同期主导的鸿蒙项目，更是让我在技术深度上有了质的飞跃。

每天与华为工程师们的头脑风暴，从 C++底层到系统架构的探讨，都在拓展着我的技术边界。

然而，就在我以为一切都在正轨上时，一种莫名的倦怠感悄然而至。

每天的日程表被无休止的会议填满：四个产运团队的例会、层层叠叠的排期评审、永远写不完的汇报 PPT...时间碎片化得让人窒息。

那天，我站在深圳的地铁站，看着来来往往的人群，第一次对自己的选择产生了动摇。

"抱歉，你的期望薪资太高了。" 

这个经历让我明白，离开大厂的光环，也许我们都不过是普通人。

在这个迷雾重重的职业十字路口，我最终选择了加入字节，深耕 AI 领域。

在商业浪潮中，个人无法与大环境相对抗。

选择时代，而非技术

这个期间我看了一些产品相关的课程，了解商业，试图寻找答案。

其中一本书对我帮助很大，就是《沸腾十五年》，以及它的续作《沸腾新十年》。

它阐述了互联网发展的 30 年的江湖故事，在里面我看到了大大小小残酷的商战，看到了多少公司的起起伏伏。

跟我们每个人的人生一样，有高光时刻，也有低谷黑暗，最终坚持下来的成为最后赢家。

所以下一个选择我不再是根据技术来做选择，而是选择了一个时代——AI 时代。

这也是我为什么会选择加入字节 AI 团队的原因。

财富认知觉醒：从打工思维到创业思维

在职场摸爬滚打这么多年，我逐渐意识到一个残酷的现实：打工，永远有天花板。

什么是真正的财富？

我们常说的"睡后收入"。

你打工通过时间换来的金钱，严格来说并不能算作财富，因为当你失去工作的时候，收入就停止了。

在职场的早期，是我们通过时间换取金钱的阶段。

这个阶段，我们需要快速成长，积累经验，提升技能。

但是到了一定阶段，我们需要思考如何让钱为我们工作，而不是我们为钱工作。

不断地承担风险，获取信任，主动请缨，追求极致，跨越自己的技术边界，也是高绩效的法门。

我度过这个时期，大概花了 5 年时间。

5 年内，趁着移动互联网最后的红利期，连续绿色通道，快速晋升，到了技术专家、团队骨干的阶段。

我想起了《纳瓦尔宝典》中的话：要获得财富，必须要从改变自己出发。

复利思维的重要性

这个阶段，跟随时代的红利，你大概率可以获得不错的物质回报。

但这个时期，我们付出了很多时间和精力，如何让这些投入产生更大的价值？答案是复利思维。

保持个人成长，是一个复利价值。

大家应该看过，一个非常重要的复利公式：

（1 + r）^n = 结果

这个时候，你的资产不仅仅是通过升职加薪带来的，还是你持续保持成长，作为了你原始的能力资本。

不管是提升个人影响力，还是积累人脉资源，还是学习新的技能，这些都是复利资产。

但是有一个问题，就是我们在职场上的成长，很容易遇到天花板。

当你到了一定的职级，再往上走就非常困难了。

这个时候，你需要思考如何突破这个天花板。

答案是：创造资产，而不是出卖时间。

什么是资产？能够为你持续产生收入的东西。比如：

• 个人品牌和影响力


• 知识产权和内容


• 投资和股权


• 产品和服务

实际上，我们所做的事情，都应该往复利的地方去做。

什么是复利呢？就是一件事，坚持做、重复做，大量的练习，把结果交给时间去验证。

当然前提是这件事是有价值的，是正确的方向。

贵人相助的重要性

在我的成长过程中，遇到了很多贵人。

其实我工作中遇到了很多贵人，我的每一任 +1 都非常好，教会了很多事情。

包括前端业界的前辈，像狼叔这样的贵人，愿意去提携，都值得我铭记和感恩。

但洋哥是其中比较特殊的贵人，他曾经也是大厂高管，程序员出身，三次创业失败，如今是第四次创业。

在他的身上我看到了非常相像的特质、经历，是指引我走向副业、创业这条路上的老大哥。

加入到他的破局行动家这个生态之后，链接到了出版社的资源，出版了我的第一本书籍，直接全网畅销 80 万册。

给我带了不少的曝光和收入。

我的个人 IP 账号，也从 0 到 1，公众号突破 1w 粉丝，全网接近 3w 粉丝。

目前全平台持续输出，我相信 5-10w，甚至更多，只是时间问题，因为这是一件复利的事情。

也就是说，就算我不去探索 AI 编程+出海，仅仅靠自媒体、书籍、商单和私域收入，也足够养活我自己了。

这给了我创业的底气和信心。

AI 时代的巨大机会

为什么是现在？

AI 不是未来，AI 就是现在。

互联网的后 20 年，我们进入了 AI 时代。这句话不是我说的，是凯文凯利。

凯文凯利是谁？他，是硅谷最著名的预言家。1994 年精准地预言了现在的互联网时代。

从 ChatGPT 到 Claude，从 Cursor 到 ClaudeCode，这些工具已经在深刻地改变着我们的工作方式。

作为程序员，我们是最直接的受益者，也是最直接的受冲击者。

大家不妨看看最近国家对 AI 颁布的政策，我们已经身处一个加速巨变的时代了。

现在入局，正是一个好的时机。

日本失落 30 年的启示

我们可以参考日本的前车之鉴，最近《以日为鉴》这本书很火。

90 年代，日本先后经历了劳动人口见顶、房地产泡沫破裂、经济增长停滞。

他们经历了就业冰河期、返乡就业潮、学历贬值、全民考公潮、教师改革、医疗崩坏、工程师内卷。

这些都是我们现在正在经历的。

在这种大环境下，很多日本年轻人选择了"躺平"，成为了"佛系青年"。

但也有一部分人，选择了出海。

他们把目光投向了海外市场，利用日本的技术优势，在全球范围内寻找机会。

这些人，后来成为了日本经济的中流砥柱。

现在的中国，有很多相似之处。国内竞争激烈，但海外市场依然有很多机会。

特别是对于我们这些程序员来说，技术是没有国界的。

在日本失落的 30 年里，有一群人被称为"暖流一族"。

AI 编程+出海的双重红利

大家想想 AI 编程领域，去年到今年发生了多大的变化？

去年，我们还处于 L1 阶段，和 GPT-4 在对话中编程。

今年，Cursor、Augment、ClaudeCode 开始炸场了。

VibeCoding 时代，毫不夸张地说，90%前端代码 AI 生成没有问题。

而红利也渐渐显现出来，看看 Indie Hacker 这个群体的代表人物 Pieter Levels：

一个人，一台电脑，走遍了 40 多个国家，月入 50 万刀。

还有 base44，6 个月从 0 到 100 万美元 ARR，最终被收购 8000 万刀。

现在的中国，正处在类似的节点：

• 国内就业市场趋于饱和


• 海外市场需求依然旺盛


• AI 工具大幅降低了技术门槛


• 程序员处在这次变革的最前沿

AI 编程 + 出海 = 独立开发者的最大机遇

一个程序员，借助 AI 工具，可以快速开发出面向全球市场的产品。

这是前所未有的时代红利。

我们这一代程序员，正好处在这个历史交汇点上。

错过了 PC 互联网，错过了移动互联网，但我们还有 AI 时代。

至少有可以持续 1-2 年的红利窗口期，是程序员专属的。

当 AI 智能化进一步发展，等到 VibeCoding 的阶段过去，普通人也能用 AI 编程做应用了，程序员的危机大概也来了。

我有一种很强烈的预感，这个时间大概在 2027 年，将会发生巨变。

我的创业决策逻辑

内心的平静

做这个决定的时候，我内心异常平静。

很多人问我，你不怕失败吗？不怕没有收入吗？

说不怕是假的，但我已经做好了最坏的打算。

就算失败了，我还可以回去打工。

但如果不尝试，我会后悔一辈子。

今年我还看了蔡磊先生的那本书，深受震撼。

我想起了很多事情，霍金、假如给我三天光明等等远古的记忆被唤起。

假如我的生命即将走到终点，我会做什么？发挥我的最大能量，不留遗憾？

我问了自己一个问题：“假如生命走到尽头，如果我没有出去创业，我会后悔吗？”

答案是肯定的，所以我内心已经做出了决策。

而且，我已经有了一定的底气。

个人品牌、书籍收入、自媒体变现，这些都给了我一定的安全边际。

最重要的是，我相信这是一个正确的方向。

AI 时代的到来，是不可逆转的趋势。

与其被动地等待变化，不如主动地拥抱变化。

风险控制

创业最大的风险，其实是不敢直面风险，无法克服内心的恐惧。

但这不意味着我们要盲目冒险。我的风险控制策略是：

对抗内耗

创业最大的敌人，不是竞争对手，而是自己的内耗。

很多人创业失败，不是因为产品不好，不是因为市场不行，而是因为自己的心态崩了。

焦虑、恐惧、自我怀疑，这些负面情绪会消耗大量的精力。

而创业需要的，恰恰是专注和坚持。

我今年最大的感悟是：

你靠近什么样的人，就会是什么样的路

穷人教你节衣缩食

小人教你坑蒙拐骗

自律的人教你如何上进

成功的人教你如何进步

人，最大的运气不是捡钱

也不是中奖

而是有人指引你成功的方向。

能量比你低的人，会怀疑你、否定你、嫉妒你。

能量同频的人，会喜欢你、肯定你、欣赏你。

能量比你高的人，会理解你、包容你、成全你。

气运的改变，和能量非常有关系。

当你所处的环境都是高能量的人的时候，你的认知、观念、气运都会随之发生改变。

我的对抗内耗的方法是：

大厂的工作，虽然收入稳定，但本质上是一种消耗。

每天的会议、汇报、协调，这些都是在消耗你的时间和精力。

即使有很多时间摸鱼，也是在消耗能量。

只要内心能够接纳所有的风险，接纳没有收入的不确定性，克服内心的恐惧，一切都不是问题了。

得之泰然，失之坦然，处之泰然，争其必然，顺其自然，无为而治。

不再计较得失，平常心看待，达到内心的祥和，这是真正的自由。

对未来的判断

我相信，接下来 5 年将是 AI 原生应用的爆发期。那些能够：

• 深度理解 AI 编程的开发者


• 具备全栈能力的技术人


• 拥有出海经验的创业者


• 会讲故事的个人 IP

将会获得巨大的时代红利。

复盘下来，我的创业决策是天时、地利、人和。

天时 - AI 时代的红利窗口

时代背景

• AI 时代来临：凯文·凯利预言"互联网后 20 年进入 AI 时代"


• 技术革命：从 L1 阶段（GPT-4 对话编程）到 VibeCoding 时代


• 开发门槛降低：90%前端代码可 AI 生成，极大降低开发难度

红利机会

• 程序员专属红利：AI 编程+出海，1-2 年窗口期


• 成功案例：
  
  
  
  
  • Pieter Levels：一人一电脑，月入 50 万刀
  
  
  • base44：6 个月 0 到 100 万美元 ARR，最终 8000 万刀收购
  
  
  
  


• 时间紧迫性：预测 2027 年将发生巨变，普通人也能用 AI 编程

地利 - 环境与资源优势

成长环境

• 贵人相助：遇到洋哥（三次创业失败的老大哥）


• 优质社群：破局行动家生态，链接志同道合的高能量人群


• 能量场效应：靠近成功的人，获得不同的认知和观念

基本盘建立

• 个人 IP：公众号 1w+粉丝，全网近 3w 粉丝


• 出版成就：第一本书全网畅销 80 万册


• 收入多元化：自媒体、书籍、商单、私域收入已能自给自足


• 复利效应：持续输出，相信 5-10w 粉丝只是时间问题

人和 - 内心觉醒与决心

生命觉悟

• 生死思考：受蔡磊先生启发，思考"假如生命走到尽头，不创业会后悔吗？"


• 答案明确：肯定会后悔，内心已做出决策

心理准备

• 接纳不确定性：通过学习阳明心学、心理学、哲学等，想明白许多事情


• 克服恐惧：愿意放弃稳定收入和高薪职位，全身心投入


• 心境转变：达到"得之泰然，失之坦然，处之泰然"的境界

个人优势

• 核心天赋：执行力、学习能力、成就动机


• 能量管理：认识到 996 工作状态会消耗个体能量


• 勇气与魄力：趁年轻勇敢试错，不怕失败，怕的是失去重新开始的勇气

给技术人的几点启发

经历了从山沟沟到大厂，再到创业的完整历程，我想给同样是技术人的朋友们分享几点启发：

1. 信念比天赋更重要

技术可以学，经验可以积累，但信念是最难培养的。

相信持续努力可以带来改变，相信做一行爱一行，这种信念会成为你最大的竞争优势。

2. 选择时代，而非技术

不要只盯着技术本身，要看到技术背后的时代趋势。移动互联网时代成就了一批人，AI 时代也会成就一批人。

关键是要站在正确的时代浪潮上。

3. 从打工思维转向创业思维

学会创造资产，而不只是出卖时间。

个人 IP、产品、内容，这些才是真正的财富。

打工的天花板再高，也是天花板。

4. 软素质比硬技能更重要

职场后期比拼的不是代码写得多快，而是如何与人协作，如何影响他人，如何解决复杂问题。

技术是基础，软素质决定高度。

5. 全球化思维是未来优势

国内红海，海外蓝海。

会英语、懂产品、有技术的复合型人才，在 AI 时代将有巨大优势。

6. 保持学习，拥抱变化

这个时代变化太快，昨天的专家可能成为今天的菜鸟。

保持好奇心，保持学习能力，才能在变化中立于不败之地。

写在最后

从新疆山沟沟的孩子，到腾讯的技术专家，再到如今的独立创业者，这一路走来，我最大的感悟是：

时代给了我们前所未有的机会，但机会只属于那些敢于行动的人。

AI 时代刚刚开始，这是我们这一代程序员最大的机遇。

一切都是最好的安排。

也许你会说，我没有你的经历，没有你的资源，没有你的能力。

但请记住，每个人的路都不一样，适合我的不一定适合你。

创业是九死一生的事情，我并不建议每个人都去创业。

重要的是找到适合自己的道路——

也许是在大厂深耕技术，也许是做自由职业者，也许是发展副业，也许是其他选择。

关键是要保持思考，拥抱变化，不断学习。

在这个充满变化的时代，唯一不变的就是变化本身。

希望我的经历能给你一些思考的角度，也希望我们都能在 AI 时代找到属于自己的位置和价值。

接下来的路

最后，预告一下我的下一步计划。

个人 IP 是我会一直坚持下去的道路，持续输出，持续影响，持续发光发热。

我相信长期价值，相信 AI 时代，相信赠人玫瑰，手有余香。

所以，我接下来还会深耕 AI、深度探索 AI 编程，保持持续的内容输出。

另外，我会探索 AI 编程出海的道路，是这个时代最大的红利机会。

我后续会持续更新两个专栏：AI 编程出海、创业心得。

在 AI 编程出海专栏，我会毫无保留地分享编程技术与经验，我的个人总结和方法论。

创业心得专栏，记录我第一次创业历程中的点点滴滴，为大家照亮前行的方向。

我觉得粥佐罗老师说的一句话特别好，个人 IP 就是成为那个别人想成为的那个人。

如何度过 35 岁危机，大家不敢走的路，我来帮大家探索一条道路，这就是我能发挥的价值。

如果这篇文章对你有启发，欢迎留言分享你的思考。

临近 lastday，也是我人生新阶段的开始。

如果你也在思考职业转型，或者对 AI 时代的机会有自己的见解，欢迎加我深度交流

让我们一起在变化的时代中，找到属于自己的那条路。

🚀 想要与更多AI爱好者交流，共同成长吗？

和一群志同道合的人，持续精进 AI 的每一天

目标

从蓝湖上下载了设计稿、切图和代码，全部扔给模型，实现首页。

提示词

## 环境变量

* 设计稿：~/company.platform.h5/refs/首页/index.png

* 设计稿转代码入口：~/company.platform.h5/refs/首页/index.html



## 目标

* 接下来，在 producer-services-v2/home.vue 实现首页。

* 工作流程：页面理解、精细组件拆分、页面实现。



## 要求

* 代码风格、页面或组件结构完全参考：~/company.platform.h5/pages/carbon-emission

* 不复用已有组件

说明

• 没有给单独的切图文件，但是切图可以从设计稿转代码的结果找到


• MCP、Skill 环境一致；IDE、记忆、Agent 略有差异


• glm-5 和 minimax-m2.5 不是多模态模型，只能通过图片分析工具理解设计稿

结果

gpt-5.2

👍：效果最好，接近完美

👎：少量的样式错误

gemini-3-pro

👍：速度最快

👎：部分板块样式错误

qwen-3.5-plus

34m 58s

👍：界面干净，比较完美

👎：导航的层级错误、轮播图板块

doubao-seed-2.0-code

27m 37s

👍：倾向使用问题确定实现边界，甚至包含主动开启子代理的询问

👎：页面不能滚动、轮播图板块尺寸不对、少数图片和文字尺寸错误

glm-5

IDE 使用 on-my-opencode，Agent Sisyphus

👍：顺手实现了简单的点击反馈

👎：忽略了板块背景等样式、第一次提示后页面不能打开（没有遵守 Nuxt 组件命名策略，简单修复后可以打开）

minimax-m2.5

IDE 使用 on-my-opencode，Agent Sisyphus，模型是 opencode 的免费模型

👍：无情干活机器

👎：部分样式错误实现、没有使用图片分析工具

kimi-k2.5

👍：比较完美

👎：少量样式错误、第一次提示结束页面不能打开（没有遵守 Nuxt 组件命名策略，简单修复后可以打开）

总结

从 Kimi-k2.5 出了之后一直在用国产模型，但是还没画过新页面。完全没想到不同模型之间画页面差距能这么大。

我正在开发 DocFlow，它是一个完整的 AI 全栈协同文档平台。该项目融合了多个技术栈，包括基于 Tiptap 的富文本编辑器、NestJs 后端服务、AI 集成功能和实时协作。在开发过程中，我积累了丰富的实战经验，涵盖了 Tiptap 的深度定制、性能优化和协作功能的实现等核心难点。

如果你对 AI 全栈开发、Tiptap 富文本编辑器定制或 DocFlow 项目的完整技术方案感兴趣，欢迎加我微信 yunmz777 进行私聊咨询，获取详细的技术分享和最佳实践。

MinIO 的开源仓库已经被正式归档，不再维护。

一个时代结束了，但开源不会那么容易死去。

我创建了一个 MinIO 分支，恢复管理控制台，重建二进制分发管道，让它重新活过来。

如果你正在运行 MinIO，只需要将 minio/minio 替换为 pgsty/minio 即可。

其他一切保持不变（CVE 已修复，管理控制台 GUI 也回来了）。

死亡证明

2025 年 12 月 3 日，MinIO 在 GitHub 上宣布进入 "维护模式"。我在 MinIO 已死 一文中写过这件事。

2026 年 2 月 12 日，MinIO 又把仓库状态从 "维护模式" 更新为 "不再维护"，随后直接将仓库归档。

仓库被设为只读，不再接受 PR、Issue 或任何形式的贡献。一个拥有 6 万星标、超过 10 亿次 Docker 拉取的项目，就这样变成了一块数字墓碑。

如果说 2025 年 12 月是临床死亡，那么 2026 年 2 月的这次提交就是正式的死亡证明。

2026 年 2 月 14 日，一篇广为流传的文章《MinIO 如何从开源宠儿变成警示故事》给出了完整的时间线：MinIO如何从开源宠儿变成警示故事。

Percona 创始人 Peter Zaitsev 也在 LinkedIn 上，对开源基础设施的可持续性提出了担忧。

国际社区的共识很明确：

MinIO 完了。

回顾过去几年的时间线，这并不是一次突然的事故，而是一个缓慢、有意、循序渐进的关停过程：

一家估值 10 亿美元、共融资 1.26 亿美元的公司，用了整整五年时间，有条不紊地拆解了自己一手建立的开源生态系统。

但开源永存

通常到这里，故事就结束了，大家集体叹口气，然后继续各奔东西。

但我想讲一个不太一样的故事。这不是讣告，而是复活。

MinIO 公司可以归档一个仓库，但他们无法归档 AGPL 授予社区的权利。

讽刺的是，AGPL 本来是 MinIO 自己选的。他们从 Apache 2.0 切换到 AGPL，是为了在和 Nutanix、Weka 的纠纷中增加筹码，在保留 "开源" 标签的同时，把许可证当成法律武器。但开源许可证是一把双刃剑，同样的许可证也确保了社区有权分叉。

一旦代码以 AGPL 形式发布，许可证就不可撤销。你可以把仓库设成只读，但不能收回已经授予社区的权利。

这正是开源许可证设计的精妙之处，公司可以放弃一个项目，但不能带走那份代码。

所以，MinIO 已死，但 MinIO 也可以重生。

当然，分叉本身是最简单的部分。任何人都可以点一下 Fork 按钮。

真正的问题不是 "能不能分叉"，而是 "有没有人愿意、也有能力，把它当作生产系统的一部分长期维护下去"。

我为什么要这么做？

一开始，我并没有打算接下这个担子。MinIO 进入维护模式之后，我等了几周，希望能看到有社区成员站出来。

但我始终没有等到那个人，于是只好自己上。

先说一点背景，我在维护 Pigsty，这是一个带电池的 PostgreSQL 发行版，内置了 460 多个扩展，并为 14 个 Linux 发行版 做了交叉构建。我还维护了 290 个 PG 扩展、若干 PG 分支 和数十个 Go 项目（Victoria、Prometheus 等）在所有主流平台上的打包。在这样一条流水线上再接一个项目，说实话压力不算太大。

我对 MinIO 也很熟。早在 2018 年，我们就在探探内部运行了一个 MinIO 分支（当时还是 Apache 2.0），托管了大约 25 PB 的数据，是当时中国最早、规模也最大的一批 MinIO 部署之一。

更重要的是，MinIO 也是 Pigsty 中的一个可选模块，很多用户在生产环境里，把它作为 PostgreSQL 的默认备份仓库。

我们确实认真评估过几个替代方案，但没有任何一个，能在现有工作流上做到对 MinIO 的平滑替换。

更多配置细节可以参考：pigsty.io/docs/minio/…

我们自己就在用 MinIO，所以让这条供应链活下去，对我们来说根本不是选项，而是硬性要求。

早在 2025 年 12 月，MinIO 刚宣布进入维护模式时，我就已经构建了包含 CVE 修复 的二进制包，并第一时间在生产中完成了切换。

我们已经做了什么

截至今天，我们已经完成了三件事。

1. 恢复管理控制台

这大概是最让社区糟心的一次改动。

2025 年 5 月，MinIO 从社区版中移除了完整的管理控制台，只留下一款简陋的对象浏览器。

用户管理、存储桶策略、访问控制、生命周期管理，这些东西是一夜之间统统消失的。想要它们回来？唯一途径是买企业版（大约十万美元起步）。

我们把它完整地带回来了。

更有意思的是，这甚至不需要任何逆向工程。

你只需要把 minio/console 子模块恢复到之前的版本。

他们当时的做法，是通过替换依赖版本，用一个阉割版控制台替换了完整版。真正的代码始终都还在那儿。

可以在这里看到具体的改动：
github.com/pgsty/minio…

我们现在已经把完整控制台放回来了。

2. 重建二进制分发

2025 年 10 月，MinIO 停止分发预构建的二进制文件和 Docker 镜像，只保留源码。对用户的官方回答只有一句："使用 go install 自己构建"。

但对于绝大多数用户来说，开源软件的价值远远不止是一份源码副本，真正关键的是稳定可靠的供应链。

你需要的是可以直接塞进 Dockerfile、Ansible playbook 或 CI 流水线里的稳定工件，而不是在每次部署前，都被迫先装一套 Go 编译器。

所以我们重建了分发体系：

如果你现在使用的是 Docker，只需要把 minio/minio 换成 pgsty/minio。

对于原生 Linux 安装，可以从 GitHub Release 页面获取 RPM、DEB 包。

你也可以使用 pig（PG 扩展包管理器）进行一键安装，或者配置 pigsty-infra APT、DNF 仓库，从中直接安装：

curl https://repo.pigsty.io/pig | bash

pig repo add infra -u

pig install minio

装完之后，它就像你熟悉的那份 MinIO 一样工作。

3. 恢复社区版文档

MinIO 的官方文档同样在慢慢 "消失"。不少旧链接已经开始被重定向到它们的新商业产品 AIStor。

我们分叉了 minio/docs，修复了损坏的链接，恢复了被删掉的控制台文档，并把整个站点部署在 这里。

文档仍然沿用原始项目的 CC Attribution 4.0 许可证，并在此基础上持续维护。

承诺

有几件事值得提前说清楚，以免大家产生不必要的期待。

没有新功能，只保证供应链连续性

作为一款 S3 兼容的对象存储，MinIO 已经算是功能完整了，它更像是一款 "写完了" 的软件。

它现在不缺新功能，真正缺的是一个稳定、可靠、长期可用的构建。

我这边已经有 PostgreSQL 来承担那些更复杂的活儿，所以我并不需要什么 S3 表、S3 向量之类的附加功能。一个稳定扎实的 S3 核心，就是我全部的诉求。

我们现在做的事情很简单：让你始终能拿到一份可用、完整的 MinIO 二进制，其中既包含管理控制台，也包含最新的安全修复。

RPM、DEB、Docker 镜像，都会通过自动化流水线持续构建出来，并与现有的 MinIO 部署保持兼容。

在法律和技术允许的边界内，我们会最大程度保留原有的 MinIO 命名和行为。

这是生产构建，不是归档镜像

我们自己就在生产环境中运行这些构建，而且已经 "吃狗粮" 吃了三个月。

一旦有东西出问题，我们会第一时间感受到，并尽快修复。

我搭建这套东西，首要目的是为了 Pigsty 和我们自己的使用，但我也很希望它能顺带帮到更多人。

我会跟踪 CVE，也会修 Bug

如果你在使用过程中遇到问题，欢迎到 pgsty/minio 反馈。

我会尽力修复这些问题，不过请不要把它当成商业 SLA。

考虑到 AI 编码工具大大降低了修复 Bug 的成本，而且我们明确不会往里加新功能，我相信整体维护工作量是可控的。

（你上一次见到新的 MinIO 功能更新是什么时候？）

商标确实麻烦，但有问题再一起解决

免责声明

商标声明：MinIO® 是 MinIO, Inc. 的注册商标。

本项目（pgsty/minio）是在 AGPL 许可证下独立维护的社区分支。

它与 MinIO, Inc. 没有任何关联、背书或商业关系。

本文中 "MinIO" 的使用仅指这款开源软件本身，并不暗示任何形式的商业合作。

AGPLv3 明确赋予我们分叉和分发的权利，但商标法又是另一套体系。

我们已经在各处清晰标注，这是一份由社区独立维护的构建。

如果 MinIO 公司对商标使用提出异议，我们会积极配合，完成重命名（也许会叫 "silo" 或 "stow" 之类的名字）。

在那之前，我们认为在 AGPL 分支中以描述性方式使用原始名称，是合理且有利于用户理解的。此时强行把所有 MinIO 引用全部改名，反而只会让用户更困惑。

AI 已经改变了游戏规则

你可能会问：一个人真的能扛得住这么大的项目吗？

现在已经是 2026 年了，情况和过去不一样。

AI 编码工具正在彻底改变开源维护的经济学。

借助 Claude Code、Codex 之类的工具，在复杂的 Go 项目里定位和修复 Bug 的成本，已经降低了一个数量级。

很多过去需要专职团队才能维护的大型基础设施项目，现在完全可以交给一位有经验的工程师，加上一位靠谱的 AI 副驾驶来共同完成。

在不引入新功能的前提下，维护一份 MinIO 构建，是一项可管理的工作。

真正的关键在于测试和验证。而我们已经有了完整的生产场景，可以在真实流量下持续验证它的兼容性、可靠性和安全性。

想一想，Elon 把 X（原 Twitter）的工程团队缩减到了大约 30 人，这个平台到现在还在运转。
相比之下，维护一个不再加新功能的 MinIO 分支，远没有想象中那么可怕。

这对你意味着什么

如果你只是远远围观 MinIO 的兴衰，这个故事听起来可能像一篇行业八卦。但如果你属于下面几类用户，这个分支和上面这些工作，其实都和你的日常生产环境直接相关。

• 在自建数据中心里，用 MinIO 做数据库备份和归档的团队


• 把 MinIO 部署在私有云，用来存放用户上传文件、审计日志、模型权重的 SaaS 团队


• 在多云环境里，把 MinIO 当作 S3 兼容层，用来屏蔽底层对象存储差异的基础设施平台


• 需要在离线环境、内网环境中部署 S3 存储，但又无法直接使用公有云服务的企业

对这些场景来说，MinIO 不只是一个组件名字，而是一条埋在系统最底层的供应链。一旦这条链路断掉，影响到的就不仅仅是对象存储本身，而是所有依赖它的备份、恢复、扩缩容、容灾和审计流程。

社区分支的目标，就是让这条链不断掉，让你可以像过去一样，用同一套命令行、同一套配置文件、同一套控制台，继续运转你的业务。

当然，如果你的团队已经在大规模使用公有云原生对象存储服务，或者可以轻松把工作负载迁移回 AWS S3、GCS、Azure Blob，那你完全可以把这篇文章当作一段开源史料。真正急需一条可持续供应链的，是那些长期押注在 MinIO 上、又没有简单退路的用户。

如何开始使用 pgsty/minio

如果你已经在生产里跑 MinIO，想要最小代价切换到社区分支，可以从下面几步入手。

整个过程中最重要的一点，是保留好回滚路径。无论是通过流量切换、还是通过 Helm 回滚，只要你能在短时间内切回旧版本，就可以放心在真实业务场景中验证新的构建。

直接分叉它

MinIO 公司可以归档一个 GitHub 仓库，但他们无法归档 6 万颗星标背后的真实需求，也无法归档 10 亿次 Docker 拉取背后的依赖拓扑。这些需求不会凭空消失，它们只会自己找到出口。

HashiCorp 的 Terraform 已经被社区分叉成 OpenTofu，而且运行得很好。相比之下，MinIO 的处境甚至更有利，因为 AGPL 对分叉比 BSL 更友好，社区分叉几乎不存在法律灰区。

公司可以放弃一个项目，但开源许可证本来就是为了确保代码不会因此一同消失。

分叉，是开源世界里最强力的咒语之一。当一家公司选择关门时，社区只需要说出那两个字，

分叉它。

参考

• MinIO已死


• MinIO已死，有替代品吗？


• 从AGPL到Apache：对Pigsty许可证变更的思考

免责声明：本文最初由 Claude 从中文版本润色并翻译成英文，此处为在中文版基础上的再整理与更新。

作为一名既爱写代码又爱打台球的程序员，我一直想做一款“纯粹”的台球工具。市面上的 App 要么广告满天飞，要么功能单一——能计分的不能复盘，能复盘的体验太差。

于是，我决定自己造个轮子。完全根据我自己需要来定制化开发。

这款名为**“追分记”的小程序，不仅支持中式黑八/九球的复杂计分（断点续打、三人追分）、自定义训练模式（统计五分点等训练记录），还内置了一个基于物理交互的战术板**。

这篇文章我将从产品构思、AI 辅助设计、本地存储架构等维度，复盘这次独立开发的完整过程。

一、 从构思到落地：AI 如何加速全流程

在这次开发中，我尝试了一种新的工作流：全程 AI 开发。从灵感到 UI，再到代码落地，让AI 扮演“产品助理”、“UI 设计师”、开发工程师的角色。

1.1 需求构思：解决我自己的痛点

在写第一行代码前，我先整理了自己的“吐槽清单”：

• 痛点 A：打九球追分，算大金、小金、犯规扣分太烧脑，容易算错。


• 痛点 B：打到一半朋友来电话，切出去回个消息，回来小程序重载了，比分全丢。


• 痛点 C：想给朋友讲刚才那杆球怎么走位，手边没球桌，干讲听不懂。


• 通点 D：自己平时去训练，也不知道训练的目标和效果。

基于此，确定了 MVP（最小可行性产品）的三大核心功能：智能计分器、断点续打系统、便携战术板。

1.2 AI 生成 产品初稿，再生成 UI：从 Prompt 到视觉稿

作为程序员，配色和 UI 往往是短板。这次我没有自己瞎折腾 CSS，而是利用 AI 生成设计灵感。

从一个新的项目开始，我让 Trae 帮我生成一个完整prd文档，包含需求分析，功能模块，页面细节。

然后让它开始实现这些功能，然而最后实现的UI界面效果很不理想。

于是，我把这个截图扔给 v0（v0.app/）,让他按照这个截图的哪内容帮我从新生成一个页面UI，并且产出一个完整的配色，以便其他页面复用。提示词如下：

你现在是个专业的UI交互设计师，帮我优化一下这个页面的UI，然后生成一个静态的html。不允许使用tailwind css，图标库可以使用lucide。需要生成一个完整的配色方案。

最后它帮我产出了一个html文件，我打开一天，天啦，这也太牛逼 plus了。

这效果已经超出我的想象了。于是我立马让 Trae 把这个页面1:1还原到对应的小程序页面。

提示词：根据 index.html 1:1还原 index.wxml 的UI。注意： index.htm 通用的root样式可以提取到公共样式中进行复用。

拿到视觉基调后，我将其转化为全局 CSS 变量（app.wxss），确保全站风格统一：

page {

  --bg-primary: #0a0f1a;

  --text-primary: #f8fafc;

  --accent-green: #10b981;

  --card-bg: rgba(30, 41, 59, 0.7);

  background: linear-gradient(160deg, var(--bg-primary) 0%, var(--bg-secondary) 100%);

}

从最初简陋的线框图，到引入 tdesign 组件库，再到配合 AI 生成的图标，产品的“颜值”经过了三轮大的迭代，最终呈现出一种“极客范儿”的精致感。

业务逻辑和UI进行了完美的融合，没有任何bug。简直完美。

二、 核心技术复盘 II：本地存储的“垃圾回收”机制

做“断点续打”功能时，我遇到了一个典型问题：
用户可能开了局，没打完就退出了；过几天又开了新局。久而久之，Storage 里会堆积大量废弃的比赛快照（Snapshot）。

为了解决这个问题，我设计了一套基于索引的 GC（垃圾回收）机制。

3.1 存储结构设计

• 索引表 (ongoingMatches)：记录所有“进行中”比赛的元数据（ID、时间、模式）。


• 快照数据 (match_current_{id})：每场比赛的具体状态单独存一个 Key，防止单条数据过大。

3.2 自动 GC 实现

每次小程序启动或进入列表页时，触发 cleanupOrphans 函数：

// utils/storage.js

function cleanupOrphans() {

  // 1. 获取“存活”的比赛 ID 集合

  const list = ongoing.getList()

  const activeIds = new Set(list.map(v => v.id))

  

  // 2. 遍历 Storage 中所有的 Key

  const keys = wx.getStorageInfoSync().keys

  

  keys.forEach(k => {

    // 3. 识别比赛快照 Key 格式

    if (k.startsWith('zhongba_match_current_')) {

      const id = Number(k.split('_').pop())

      // 4. 如果 ID 不在存活列表中，视为“孤儿数据”，直接删除

      if (!activeIds.has(id)) {

        safeRemove(k)

        console.log(`[GC] Cleaned up orphan match: ${id}`)

      }

    }

  })

}

这个机制保证了 Storage 永远只存储有用的数据，既节省空间又维护了整洁。

最后我还让它生成了一份数据快照，以便以后接入服务端的时候可以快速的创建数据库：

三、 细节体验：后台计时校准

小程序在切入后台（onHide）后，setInterval 定时器往往会暂停或变慢。为了保证比赛计时的准确性，不能单纯依赖定时器累加。

解决方案：时间戳校准法

// pages/nine-ball/nine-ball.js

onShow() {

  if (this.data.isRunning) {

    const now = Date.now()

    const rs = this.data.runningSince

    const delta = Math.floor((now - rs) / 1000)

    

    // 即使在后台挂起了一小时，回来时间也会瞬间补齐

    if (delta > 0) {

      this.setData({ elapsedTime: this.data.elapsedTime + delta })

    }

  }

}

四、 总结

“追分记”虽然只是一个工具类小程序，但“麻雀虽小，五脏俱全”。

• 从产品角度：它验证了从痛点出发，利用 AI 辅助设计快速落地的可行性。


• 从技术角度：本地存储治理、生命周期管理等前端/小程序开发的典型场景。

独立开发最迷人的地方，莫过于看着一个想法，在自己的键盘下一点点变成触手可及的现实。

如果你也是台球爱好者，或者对小程序开发感兴趣，欢迎在微信搜索**“追分记”**体验，也欢迎在评论区交流技术细节！

大家好，我是大华！在现代的Web开发中，实时通信需求越来越普遍。比如在线聊天、实时数据监控、消息推送等场景。

面对这些需求，我们通常有两种选择：SSE和WebSocket。它们都能实现实时通信，但设计理念和适用场景却有很大不同。

什么是 SSE？

SSE（Server-Sent Events）是一种基于 HTTP 的服务器推送技术。它的核心特点是：单向通信，只能由服务器向客户端发送数据。

SSE 的核心特点

• 基于 HTTP 协议：使用标准的 HTTP/1.1 协议


• 单向通信：服务器 → 客户端


• 自动重连：浏览器内置重连机制


• 简单易用：API 设计简洁直观


• 文本传输：主要支持 UTF-8 文本数据

SSE 使用示例

客户端JS代码：

// 创建 SSE 连接

const eventSource = new EventSource('/api/real-time-data');



// 监听服务器推送的消息

eventSource.onmessage = function(event) {

  const data = JSON.parse(event.data);

  console.log('收到实时数据:', data);

  updateUI(data); // 更新界面

};



// 监听自定义事件类型

eventSource.addEventListener('systemAlert', function(event) {

  const alertData = JSON.parse(event.data);

  showAlert(alertData.message);

});



// 错误处理 - 自动重连是内置的

eventSource.onerror = function(event) {

  console.log('连接异常，正在自动重连...');

};

服务器端代码（Node.js + Express）：

app.get('/api/real-time-data', (req, res) => {

  // 设置 SSE 必需的响应头

  res.writeHead(200, {

    'Content-Type': 'text/event-stream',

    'Cache-Control': 'no-cache',

    'Connection': 'keep-alive',

    'Access-Control-Allow-Origin': '*'

  });

  

  // 发送初始连接确认

  res.write('data: {"status": "connected"}\n\n');

  

  // 模拟实时数据推送

  let count = 0;

  const interval = setInterval(() => {

    const data = {

      id: count++,

      timestamp: new Date().toISOString(),

      value: Math.random() * 100

    };

    

    // SSE 标准格式：data: 开头，两个换行符结尾

    res.write(`data: ${JSON.stringify(data)}\n\n`);

    

    // 每10秒发送一次系统状态

    if (count % 10 === 0) {

      res.write('event: systemAlert\n');

      res.write(`data: {"message": "系统运行正常"}\n\n`);

    }

  }, 1000);

  

  // 客户端断开连接时清理资源

  req.on('close', () => {

    clearInterval(interval);

    console.log('客户端断开连接');

  });

});

什么是 WebSocket？

WebSocket 是一种真正的全双工通信协议，允许服务器和客户端之间建立持久连接，进行双向实时通信。

WebSocket 的核心特点

• 独立协议：基于 TCP 的独立协议（ws:// 或 wss://）


• 双向通信：服务器 ↔ 客户端


• 低延迟：建立连接后开销极小


• 数据多样：支持文本和二进制数据


• 手动管理：需要手动处理连接状态

WebSocket 使用示例

客户端JS代码：

class ChatClient {

  constructor() {

    this.socket = null;

    this.isConnected = false;

  }

  

  connect() {

    this.socket = new WebSocket('wss://api.example.com/chat');

    

    this.socket.onopen = () => {

      this.isConnected = true;

      console.log('WebSocket 连接已建立');

      this.send({ type: 'join', username: '小明' });

    };

    

    this.socket.onmessage = (event) => {

      const data = JSON.parse(event.data);

      this.handleMessage(data);

    };

    

    this.socket.onclose = () => {

      this.isConnected = false;

      console.log('连接已断开');

      this.attemptReconnect();

    };

    

    this.socket.onerror = (error) => {

      console.error('WebSocket 错误:', error);

    };

  }

  

  sendMessage(content) {

    if (this.isConnected) {

      this.send({

        type: 'message',

        content: content,

        timestamp: Date.now()

      });

    }

  }

  

  send(data) {

    this.socket.send(JSON.stringify(data));

  }

  

  handleMessage(data) {

    switch (data.type) {

      case 'chat':

        this.displayMessage(data);

        break;

      case 'userJoin':

        this.showUserJoin(data.username);

        break;

    }

  }

  

  attemptReconnect() {

    setTimeout(() => {

      console.log('尝试重新连接...');

      this.connect();

    }, 3000);

  }

}

服务器端代码（Node.js + ws 库）：

const WebSocket = require('ws');

const wss = new WebSocket.Server({ 

  port: 8080,

  perMessageDeflate: false

});



// 存储连接的用户

const connectedUsers = new Map();



wss.on('connection', (ws, request) => {

  console.log('新的客户端连接');

  

  let currentUser = null;

  

  ws.on('message', (rawData) => {

    try {

      const data = JSON.parse(rawData);

      

      switch (data.type) {

        case 'join':

          currentUser = data.username;

          connectedUsers.set(ws, currentUser);

          

          // 广播用户加入消息

          broadcast({

            type: 'userJoin',

            username: currentUser,

            time: new Date().toISOString()

          }, ws);

          

          // 发送欢迎消息

          ws.send(JSON.stringify({

            type: 'system',

            message: `欢迎 ${currentUser} 加入聊天室！`

          }));

          break;

          

        case 'message':

          // 广播聊天消息

          broadcast({

            type: 'chat',

            username: currentUser,

            message: data.content,

            timestamp: data.timestamp

          });

          break;

      }

    } catch (error) {

      console.error('消息解析错误:', error);

      ws.send(JSON.stringify({

        type: 'error',

        message: '消息格式错误'

      }));

    }

  });

  

  ws.on('close', () => {

    if (currentUser) {

      connectedUsers.delete(ws);

      // 广播用户离开

      broadcast({

        type: 'userLeave',

        username: currentUser,

        time: new Date().toISOString()

      });

    }

    console.log('客户端断开连接');

  });

  

  // 心跳检测

  const heartbeat = setInterval(() => {

    if (ws.readyState === WebSocket.OPEN) {

      ws.send(JSON.stringify({ type: 'ping' }));

    }

  }, 30000);

  

  ws.on('close', () => {

    clearInterval(heartbeat);

  });

});



function broadcast(data, excludeWs = null) {

  wss.clients.forEach((client) => {

    if (client !== excludeWs && client.readyState === WebSocket.OPEN) {

      client.send(JSON.stringify(data));

    }

  });

}

区别对比

适用场景

推荐使用 SSE 的场景

1. 实时数据监控面板
2. 实时消息通知
3. 实时数据流展示

比如：股票价格实时更新、体育比赛比分直播、物流订单状态跟踪和服务器日志实时显示等。

推荐使用 WebSocket 的场景

1. 实时交互应用
2. 实时游戏应用
3. 实时音视频通信

比如：视频会议系统、在线客服聊天和实时协作编辑文档等

如何选择？

选择 SSE：

• 只需要服务器向客户端推送数据


• 希望快速实现、简单维护


• 项目对移动端兼容性要求高


• 数据更新频率适中（秒级）


• 不需要传输二进制数据

选择 WebSocket：

• 需要真正的双向实时通信


• 数据传输频率很高（毫秒级）


• 需要传输二进制数据（如图片、音频）


• 构建实时交互应用（游戏、协作工具）


• 对延迟极其敏感的场景

混合使用策略

在一些复杂应用中，可以同时使用两者：

class HybridApp {

  constructor() {

    // 使用 SSE 接收通知和广播消息

    this.notificationSource = new EventSource('/api/notifications');

    

    // 使用 WebSocket 进行实时交互

    this.interactionSocket = new WebSocket('wss://api.example.com/interact');

    

    this.setupEventHandlers();

  }

  

  setupEventHandlers() {

    // SSE 处理广播类消息

    this.notificationSource.onmessage = (event) => {

      this.handleBroadcastMessage(JSON.parse(event.data));

    };

    

    // WebSocket 处理交互类消息

    this.interactionSocket.onmessage = (event) => {

      this.handleInteractionMessage(JSON.parse(event.data));

    };

  }

}

总结

SSE 的优势在于简单易用、自动重连、与 HTTP 基础设施完美集成，适合服务器向客户端的单向数据推送场景。

WebSocket 的优势在于真正的双向通信、低延迟、支持二进制数据，适合需要高频双向交互的复杂应用。

在实际项目中，可以根据具体的业务需求、性能要求来做出合理的技术选型。

本文首发于公众号：程序员刘大华，专注分享前后端开发的实战笔记。关注我，少走弯路，一起进步！

📌往期精彩

《SpringBoot+Vue3 整合 SSE 实现实时消息推送》

《这20条SQL优化方案，让你的数据库查询速度提升10倍》

《SpringBoot 动态菜单权限系统设计的企业级解决方案》

《Vue3 + ElementPlus 动态菜单实现：一套代码完美适配多角色权限系统》