之所以会想写这个，首先是因为在知乎收到了这个推荐的问题，实际上不管是 AutoGLM 还是豆包 AI 手机，会在这个阶段被第三方厂商抵制并不奇怪，比如微信和淘宝一直以来都很抵制这种外部自动化操作，而非这次中兴的 AI 豆包手机出来才抵制，毕竟以前搞过微信自动化客服应该都知道，一不小心就会被封号。

另外也是刚好看到， B 站的 UP 主老戴深入分析了豆包手机的内部工作机制的视频，视频介绍了从 AI 助手如何读取屏幕、捕捉数据和模拟操作的真实流程，所以对于 AI 手机又有了个更深刻的认知，在这个基础上，更不难理解为什么 AI 手机这种自动化 Agent 会被第三方厂商抵制，推荐大家看原视频：b23.tv/pftlDX8 。

那么豆包的 AI 手机是怎么工作的呢？实际上和大家想的可能不一样，它并没有使用无障碍服务（Accessibility Service），而是使用了更底层的实现方案：

豆包手机利用底层的系统权限，直接从 GPU 缓冲区获取原始图像数据并注入输入事件，而非依赖截屏或无障碍服务，此外手机还在一个独立的虚拟屏幕中执行后台任务，并将图像低频发送至云端进行推理，云端则返回操作指令。

在视频里， UP 主通过深度拆解豆包手机，分析手机在系统层面的服务分工、数据抓取和模型推理路径，例如aikernel被 UP 主推断为手机端侧 AI 的核心进程，内存占用特性（Native堆高达160M）表明它可能是一个本地AI推理框架：

另外 aikernel 异常高的Binder数量，证明有大量外部进程通过 RPC 调用它，进一步印证了其系统级服务的角色 。

而 autoaction是豆包手机 AI 自动操作的关键，这个 APK 权限允许直接从 GPU 渲染的图形缓冲区读取数据，而不是通过上层截图：

而且目前看，豆包手机的 AI 能够捕获受保护的视频输出，这意味着它可以绕过银行 App 等应用的反截图/录屏限制 ，因为很多银行 App 很多是通过 DRM（数字版权管理） 或应用内安全设置来防止截屏和录屏：

另外，Agent 在操作手机过程也不是直接使用系统的 Accessibility Service ，而是通过调用系统隐藏API injectInputEvent 来控制手机， AI 通过 INJECT_EVENTS 权限直接注入输入事件来模拟屏幕点击，权限高于无障碍 API，并且是系统签名：

同时，豆包手机在执行自动操作时，会利用一个与物理屏幕分辨率相同的“无头”虚拟屏幕在后台运行，且拥有独立的焦点，不影响用户在前台的操作，这其实就是内存副屏的概念， 虚拟屏幕的画面由 GPU 合成后，对应的缓冲区信息会直接被autoaction消费，再次证实 AI 无需通过截图 API 即可获取屏幕内容 ：

最后，豆包手机在自动化操作时，会频繁地（每3到5秒）与 obriccloud.com （字节的服务） 服务器通信，发送约 250K的单帧图片进行推理。

云端在接收图片后，会返回约 1K 的数据，内容是告诉手机下一步要执行的 7 种指令之一，如打开应用、点击、输入、滑动等等，整个自动化 Agent 的推理和路径规划主要在云端完成，云端思考后将执行步骤指令发回本地执行，本地任务很轻：

那么，这整个过程你看下来有什么感觉？如果你是第三方厂商，你会不会同样抵制这种数据收集和处理的行为？特别是绕过现有大家对系统 API 的理解，这种操作途径是否能被友商们接受？

所以目前的这种操作，被微信和淘宝抵制很正常，不管是隐私的边界，还有安全操作的规范，用户对于自己某个产品内容被收集的信息程度，这些都还处于蛮荒状态，数据安全和隐私的边界范围还不可控，并且 Agent 的托管行为，也明显侵犯到了友商们的利益链条。

就像是 UP 主说的，AI Agent 的出现将动摇移动互联网的底层商业逻辑——注意力经济，使“注意力”这一硬通货的重要性降低 ，实际上换作另一个概念就是碎片化时间：

以前你的碎片化时间都是被各种 App 消费了，比如广告和沉浸引导，但是 Agent 的出现，它明显将这部分时间给托管了，那么数据和时间都被 Agent 服务收集，对于友商们来说，不就是成了单纯的功能性服务商了吗？

另外，说实话像 AutoGLM 这种功能目前的支持，最大受益者不是用户而是灰产，不管是用诈骗还是黄牛，他们都是这种自动化下的第一受益者，所以规范和监管，特别是安全和隐私条款是必须，比如就像 UP 主说的：

豆包手机的 AI 在自动化操作过程中，哪些数据会被发送到云端服务器？

很多人对于 agent 和自动化能力的范畴并不理解，它们可以获取隐私的边界是什么，安全操作的规范是什么，这些都是需要支持和统一边界。

比如 Android 16 实际上官方是有规划 Appfunction Api 的，它的目的是让应用只公布自己开放给 AI 的能力，这样也许边界感更强。

当然，从历史的角度看，Agent 手机势不可挡，就像谷歌自己未来新的 Android PC 系统 Aluminium OS 也是会结合 Gemini Agent 等特点，这是历史进程的必然，但是这个过程中，如何统一规范和监管这是很重要的过程，毕竟 AI 的效应和能力，可比之前更加强，就像 UP 主说的，新的 AI 寡头可能会形成更中心化、更强势的权力，且马太效应更明显 。

那么，你觉得未来谁家的 Agent 设备会成为新时达的寡头？或者不是手机而是眼镜？

视频链接

b23.tv/pftlDX8

大家好😁。

上个月，我们公司的内部敏感文档（PRD）截图，竟然出现在了竞品的群里。

老板大发雷霆，要求技术部彻查：到底是谁泄露出去的？😠

但问题是，文档是纯文本的，截图上也没有任何显式的水印（那种写着员工名字的大黑字，太丑了，产品经理也不让加）。

怎么查？

这时候，我默默地打开了我的VS Code，给老板演示了一个技巧：

老板，其实泄露的那段文字里，藏着那个人的工号，只是你肉眼看不见。

今天，我就来揭秘这个技术——基于零宽字符（Zero Width Characters）的盲水印技术。学会这招，你也能给你的页面加上隐形追踪器。

先科普一下，什么叫零宽字符？

在Unicode字符集中，有一类神奇的字符。它们存在，但不占用任何宽度，也不显示任何像素。

简单说，它们是隐形的。

最常见的几个：

• \u200b (Zero Width Space)：零宽空格


• \u200c (Zero Width Non-Joiner)：零宽非连字符


• \u200d (Zero Width Joiner)：零宽连字符

我们可以在Chrome控制台里试一下：

console.log('A' + '\u200b' + 'B');

// 输出: "AB"

// 看起来和普通的 "AB" 一模一样

但是，如果我们检查它的长度：

console.log(('A' + '\u200b' + 'B').length);

// 输出: 3

看到没？😁

它的原理是什么？

原理非常简单，就是利用这些隐形字符，把用户的信息（比如工号User_9527），编码进一段正常的文本里。

步骤如下：

是不是很神奇？🤣

只需要30行代码实现抓内鬼工具

不废话，直接上代码。你可以直接复制到控制台运行。

加密函数 (Inject Watermark)

// 零宽字符字典

const zeroWidthMap = {

  '0': '\u200b', // Zero Width Space

  '1': '\u200c', // Zero Width Non-Joiner

};



function textToBinary(text) {

  return text.split('').map(char => 

    char.charCodeAt(0).toString(2).padStart(8, '0') // 转成8位二进制

  ).join('');

}



function encodeWatermark(text, secret) {

  const binary = textToBinary(secret);

  const hiddenStr = binary.split('').map(b => zeroWidthMap[b]).join('');

  

  // 将隐形字符，插入到文本的第一个字符后面

  // 你也可以随机分散插入，更难被发现

  return text.slice(0, 1) + hiddenStr + text.slice(1);

}



// === 测试 ===

const originalText = "公司机密文档，严禁外传！";

const userWorkId = "User_9527";



const watermarkText = encodeWatermark(originalText, userWorkId);



console.log("原文:", originalText);

console.log("带水印:", watermarkText);

console.log("肉眼看得出区别吗？", originalText === watermarkText); // false

console.log("长度对比:", originalText.length, watermarkText.length); 

当你把 watermarkText 复制到微信、飞书或者任何地方，那串隐形字符都会跟着一起被复制过去。

解密函数的实现

现在，假设我们拿到了泄露出去的这段文字，怎么还原出是谁干的？

// 反向字典

const binaryMap = {

  '\u200b': '0',

  '\u200c': '1',

};



function decodeWatermark(text) {

  // 1. 提取所有零宽字符

  const hiddenChars = text.match(/[\u200b\u200c]/g);

  if (!hiddenChars) return '未发现水印';

  

  // 2. 转回二进制字符串

  const binaryStr = hiddenChars.map(c => binaryMap[c]).join('');

  

  // 3. 二进制转文本

  let result = '';

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

    const byte = binaryStr.slice(i, i + 8);

    result += String.fromCharCode(parseInt(byte, 2));

  }

  

  return result;

}



// === 测试抓内鬼 ===

const leakerId = decodeWatermark(watermarkText);

console.log("抓到内鬼工号:", leakerId); // 输出: User_9527

微信或者飞书 复制出来的文案 👇

这种水印能被清除吗？

当然可以，但前提是你知道它的存在。

对于不懂技术的普通员工，他们复制粘贴文字时，根本不会意识到自己已经暴露了🤔

如果遇到了懂技术的内鬼，他可能会：

虽然它不是万能的，但它是一种极低成本、极高隐蔽性的防御手段。

技术本身就没什么善恶。

我分享这个技术，不是为了让你去监控谁，而是希望大家多掌握一种防御性编程的一个思路。

在Web开发中，除了明面上的UI和交互，还有很多像零宽字符这样隐秘的角落，藏着一些技巧。

下次如果面试官问你：除了显式的水印，你还有什么办法保护页面内容？

你可以自信地抛出这个方案，绝对能震住全场😁。

从北京回武汉差不多六年了，感慨颇多， 谈谈真实感受。

1 IT 公司

我们先把 IT 公司做一个分类整理 ：

从表中来看，武汉的 IT 公司确实不算少 ，主要集中于光谷，但我需要强调一下：

1、在大厂的眼里，武汉的定位是第二研发中心，看中的是武汉海量的研发人力资源以及较低的薪资水平。

2、第二研发中心做的并非核心业务，而且第二研发中心的权限往往不够。所以第二研发中心往往也被称为外包中心，这也是武汉很多朋友都说武汉是外包之城的原因。

3、武汉的技术氛围很差，高水平的研发人员相对较少，无论是管理者还是研发人员和一线相比是有绝对差距的。

接下来，聊聊薪资。

武汉 IT 薪资和一线差距很大，我预估月薪应该是一线的 50% 到 60% 左右，年终奖一般都是 1 ~ 2 个月，少部分公司会有股票，社保/公积金相对较低。

假如你在互联网公司，达到了阿里 P7 左右，我建议暂时不回武汉，因为武汉的薪资、技术氛围真的可能让你失望，还不如在一线多攒钱，等资金充裕了，回武汉更加合适点（一线挣钱，武汉花，很美！）。

2 大武汉

我们经常会将武汉说成“大武汉”，官方数据显示，武汉的行政面积达 8569.15 平方公里，相当于0.52个北京、1.35个上海或 4.29 个深圳。

武汉被长江和众多湖泊自然分割，形成了"三镇鼎立"的独特格局——汉口、武昌、汉阳各自为政又浑然一体。

为了连接这片水域纵横的土地，仅长江上就架起了十余座大桥，每一座都是城市发展的见证者。

回武汉的第一年，每天驱车从金银湖到关山大道，真有一种跋山涉水翻山越岭的感觉。

大江大湖造就了大武汉的壮阔景观，从金银湖的潋滟波光到南湖的静谧秀美，从堤角的市井烟火到欢乐谷的现代活力，处处都是令人惊叹的滨水景观。

• 城市夜景

• 长江大桥

3 文化

武汉的城市文化非常多元 ，有的时候，你甚至想不明白，为什么这么多迥异的文化元素集中于同一个城市。

01 码头文化

武汉因水而兴，自古就是“九省通衢”的商贸重镇。

汉口的码头文化塑造了武汉人直爽、讲义气的性格，“不服周”“讲胃口”的方言里，藏着码头工人的豪迈与坚韧。清晨的吉庆街、户部巷，热干面的芝麻香混合着面窝的酥脆，老武汉的一天就在这样的烟火气中开始。

02 过早

武汉人“过早”（吃早餐）的仪式感全国闻名，热干面、豆皮、糊汤粉、牛肉粉……一个月可以不重样 。

03 科教中心

武汉坐拥武汉大学、华中科技大学等近百所高校，是中国三大科教中心之一。

樱花纷飞的武大、梧桐成荫的华科、文艺范十足的昙华林，让这座城市既有历史的厚重感，又有青春的朝气。

04 省博物馆

湖北省博物馆是中国最重要的国家级博物馆之一，推荐各位同学来武汉时一定要去看一看。

1、越王勾践剑 : 锋芒依旧的王者之剑

2、曾侯乙编钟：奏响穿越时空的旋律

3、曾侯乙尊盘：青铜铸造的巅峰之作

4 生活

在武汉生活其实很方便，拿医疗资源来讲，我在北京望京看牙经常挂不到号，在武汉不可能发生这种情况，因为我家附近有两家三甲医院，平常看病就医都很方便。

武汉的景点非常多，周末我经常开车带老婆、孩子去东湖、九峰山动物园、植物园等景点游玩。

因为离父母近，也有了更多时间陪陪父母，他们年纪大了，总会感到孤独，我在他们身边，他们也会感觉好一点。

总而言之，相比在北京，我更加有归属感，而且幸福感更强。

有点遗憾的是，在武汉工作，一直感觉很别扭 ：

• 讯飞的业务是 TOG 的项目，很多产品、项目质量堪忧，有的接近劣质的边缘，同时合肥管理人员所体现出的低素质，让我的价值观受到了极大的刺激。


• 武汉不应该仅仅作为人力资源之城，或者说是外包之城。

我曾经对老婆讲：“我有点后悔离开北京，在武汉，最高的 offer 可以拿到接近 53 w ，要是这六年还在北京，运气好的话，手里的现金可以多个 100 w 吧！”

老婆听了我的幻想，笑了笑，回道：“那可能依依都不可能出生呢”。

我想了想： “也是，现在其实挺幸福的”。

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

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

据 大厂日报 称，美团履约团队近期正在推行"全栈化"转型。据悉，终端组的部分前端同学在 11 月末左右转到了后端组做全栈（前后端代码一起写），主要是 agent 相关项目。内部打听了一下，团子目前全栈开发还相对靠谱，上线把控比较严格。

这一消息在技术圈引起了广泛关注，也反映了 AI 时代下前端工程师向全栈转型的必然趋势。但更重要的是，我们需要深入思考：AI 到底给前端带来了什么冲击？为什么前端转全栈成为了必然选择？

最近，前端圈里不断有"前端已死"的话语流出。有人说 AI 工具会替代前端开发，有人说低代码平台会让前端失业，还有人说前端工程师的价值正在快速下降。这些声音虽然有些极端，但确实反映了 AI 时代前端面临的真实挑战。

一、AI 对前端的冲击：挑战与机遇并存

1. 代码生成能力的冲击

冲击点：

• 低复杂度页面生成：AI 工具（如 Claude Code、Cursor）已经能够快速生成常见的 UI 组件、页面布局


• 重复性工作被替代：表单、列表、详情页等标准化页面，AI 生成效率远超人工


• 学习门槛降低：新手借助 AI 也能快速产出基础代码，前端"入门红利"消失

影响：
传统前端开发中，大量时间花在"写页面"上。AI 的出现，让这部分工作变得极其高效，甚至可以说，只会写页面的前端工程师，价值正在快速下降。这也正是"前端已死"论调的主要依据之一。

2. 业务逻辑前移的冲击

冲击点：

• AI Agent 项目激增：如美团案例中的 agent 相关项目，需要前后端一体化开发


• 实时交互需求：AI 应用的流式响应、实时对话，要求前后端紧密配合


• 数据流转复杂化：AI 模型调用、数据处理、状态管理，都需要全栈视角

影响：
纯前端工程师在 AI 项目中往往只能负责 UI 层，无法深入业务逻辑。而 AI 项目的核心价值在于业务逻辑和数据处理，这恰恰是后端能力。

3. 技术栈边界的模糊

冲击点：

• 前后端一体化趋势：Next.js、Remix 等全栈框架兴起，前后端代码同仓库


• Serverless 架构：边缘函数、API 路由，前端开发者需要理解后端逻辑


• AI 服务集成：调用 AI API、处理流式数据、管理状态，都需要后端知识

影响：
前端和后端的边界正在消失。只会前端的前端工程师，在 AI 时代会发现自己"够不着"核心业务。

4. 职业发展的天花板

冲击点：

• 技术深度要求：AI 项目需要理解数据流、算法逻辑、系统架构


• 业务理解能力：全栈开发者能更好地理解业务全貌，做出技术决策


• 团队协作效率：全栈开发者减少前后端沟通成本，提升交付效率

影响：
在 AI 时代，只会前端的前端工程师，职业天花板明显。而全栈开发者能够：

• 独立负责完整功能模块


• 深入理解业务逻辑


• 在技术决策中发挥更大作用

二、为什么前端转全栈是必然选择？

1. AI 项目的本质需求

正如美团案例所示，AI 项目（特别是 Agent 项目）的特点：

• 前后端代码一起写：业务逻辑复杂，需要前后端协同


• 数据流处理：AI 模型的输入输出、流式响应处理


• 状态管理复杂：对话状态、上下文管理、错误处理

这些需求，纯前端工程师无法独立完成，必须掌握后端能力。

2. 技术发展的趋势

• 全栈框架普及：Next.js、Remix、SvelteKit 等，都在推动全栈开发


• 边缘计算兴起：Cloudflare Workers、Vercel Edge Functions，前端需要写后端逻辑


• 微前端 + 微服务：前后端一体化部署，降低系统复杂度

3. 市场需求的转变

• 招聘要求变化：越来越多的岗位要求"全栈能力"


• 项目交付效率：全栈开发者能独立交付功能，减少沟通成本


• 技术决策能力：全栈开发者能更好地评估技术方案

三、后端技术栈的选择：Node.js、Python、Go

对于前端转全栈，后端技术栈的选择至关重要。不同技术栈有不同优势，需要根据项目需求选择。

1. Node.js + Nest.js：前端转全栈的最佳起点

优势：

• 零语言切换：JavaScript/TypeScript 前后端通用


• 生态统一：npm 包前后端共享，工具链一致


• 学习成本低：利用现有技能，快速上手


• AI 集成友好：LangChain.js、OpenAI SDK 等完善支持

适用场景：

• Web 应用后端


• 实时应用（WebSocket、SSE）


• 微服务架构


• AI Agent 项目（如美团案例）

学习路径：

2. Python + FastAPI：AI 项目的首选

优势：

• AI 生态最完善：OpenAI、LangChain、LlamaIndex 等原生支持


• 数据科学能力：NumPy、Pandas 等数据处理库


• 快速开发：语法简洁，开发效率高


• 模型部署：TensorFlow、PyTorch 等模型框架

适用场景：

• AI/ML 项目


• 数据分析后端


• 科学计算服务


• Agent 项目（需要复杂 AI 逻辑）

学习路径：

3. Go：高性能场景的选择

优势：

• 性能优秀：编译型语言，执行效率高


• 并发能力强：Goroutine 并发模型


• 部署简单：单文件部署，资源占用少


• 云原生友好：Docker、Kubernetes 生态完善

适用场景：

• 高并发服务


• 微服务架构


• 云原生应用


• 性能敏感场景

学习路径：

4. 技术栈选择建议

对于前端转全栈的开发者：

建议：

• 第一阶段：选择 Node.js，快速转全栈


• 第二阶段：根据项目需求，学习 Python 或 Go


• 长期目标：掌握多种技术栈，根据场景选择

四、总结

AI 时代的到来，给前端带来了深刻冲击：

前端转全栈，是 AI 时代的必然选择。

对于技术栈选择：

• Node.js：前端转全栈的最佳起点，学习成本低


• Python：AI 项目的首选，生态完善


• Go：高性能场景的选择，云原生友好

正如美团的全栈化实践所示，全栈开发还相对靠谱，关键在于：

• 选择合适的技术栈


• 建立严格的开发流程


• 持续学习和实践

对于前端开发者来说，AI 时代既是挑战，也是机遇。转全栈，不仅能应对 AI 冲击，更能打开职业发展的新空间。那些"前端已死"的声音，其实是在提醒我们：只有不断进化，才能在这个时代立足。

大明哥是 2014 年一个人拖着一个行李箱，单身杀入深圳，然后在深圳一干就是 10 年。

10 年深漂，经历过 4 家公司，有 20+ 人的小公司，也有上万人的大厂。

体验过所有苦逼深漂都体验过的难。坐过能把人挤怀孕的 4 号线，住过一天见不到几个小时太阳的城中村，见过可以飞的蟑螂。欣赏过晚上 6 点的晚霞，但更多的是坐晚上 10 点的地铁看一群低头玩手机的同行。

10 年虽然苦、虽然累，但收获还是蛮颇丰的。从 14年的 5.5K 到离职时候的 xxK。但是因为种种原因，于 2023年 9 月份主动离职离开深圳。

回长沙一年，给我的感觉就是：除了钱少和天气外，样样都比深圳好。

生活

在回来之前，我首先跟我老婆明确说明了我要休息半年，这半年不允许跟我提任何有关工作的事情，因为在深圳工作了 10 年真的太累，从来没有连续休息超过半个月的假期。哪怕是离职后我也是无缝对接，这家公司周五走，下家公司周一入职。

回来后做的第一件事情就是登出微信、删除所有闹钟、手机设置全天候的免打扰，全心全意，一心一意地陪女儿和玩，在这期间我不想任何事情，也不参与任何社交，就认真玩，不过顺便考了个驾-照。

首先说消费。

有很多人说长沙是钱比深圳少，但消费不比深圳低。其实不然，我来长沙一年了，消费真的比深圳低不少。工作日我一天的消费基本上可以控制在 40 左右，但是在深圳我一天几乎都要 80 左右。对比

同时，最近几个月我开始带饭了，周一到超时买个百来块的菜，我一个人可以吃两个星期。

总体上，一个月消费长沙比深圳低 1000 左右（带饭后更低了）。

再就是日常的消费。如果你选择去长沙的商城里面吃，那与深圳其实差不多了多少，当然，奶茶方面会便宜一些。但是，如果你选择去吃长沙的本土菜，那就会便宜不少，我跟我朋友吃饭，人均 50 左右，不会超过 70，选择美团套餐会更加便宜，很多餐馆在支持美团的情况下，选择美团套餐，两个人可以控制在 30 ~ 40 之间。而深圳动不动就人均 100+。

当然，在消费这块，其实节约的钱与少的工资，那就是云泥之别，可忽略不计。

再说生活这方面。

在长沙这边我感觉整体上的幸福感比深圳要强蛮多，用一句话说就是：深圳都在忙着赚钱，而长沙都在忙着吃喝玩乐加洗脚。我说说跟我同龄的一些高中和大学同学，他们一毕业就来长沙或者来长沙比较早，所以买房就比较早，尤其是 16 年以前买的，他们的房贷普遍在 3000 左右，而他们夫妻两的工资税后可以到 20000，所以他们这群人周末经常约着一起耍。举两个例子来看看他们的松弛感：

• 晚上 10 点多喊我去吃烧烤，我以为就是去某个夜市撸串，谁知道是开车 40+公里，到某座山的山顶撸串 + 喝酒。这是周三，他们上班不上班我不知道，反正我是不上班。


• 凌晨 3 点多拉我出来撸串

跟他们这群人我算是发现了，大部分的聚会都是临时起意，很少提前约好，主打就是一个随心随意。包括我和同事一样，我们几乎每个月都会出来几次喝酒（我不喜欢喝酒，偶尔喝点啤酒）、撸串，而且每次都是快下班了，某个人提议今晚喝点？完后，各回各家。

上面是好的方面，再说不好的。

长沙最让我受不了的两点就是天气 + 交通。

天气我就不说了，冬天冻死你，夏天热死你。去年完整体验了长沙的整个冬天，是真他妈的冷，虽然我也是湖南人，但确实是把我冻怕了。御寒？不可能的，全靠硬抗。当然，也有神器：火桶子，那是真舒服，我可以在里面躺一整天。

交通，一塌糊涂，尤其是我每天必经的西二环，简直惨不忍睹，尤其是汽车西站那里，一天 24 小时都在堵，尤其是周一和周五，高德地图上面是红的发黑。所以，除非特殊情况，我周一、周五是不开车的，情愿骑 5 公里小电驴去坐地铁。

然后是一大堆违停，硬生生把三车道变成两车道，什么变道不打灯，实线变道，双黄线调头见怪不怪了，还有一大群的小电驴来回穿梭，对我这个新手简直就是恐怖如斯（所以，我开车两个月喜提一血，4S点维修报价 9800+）。

美食我就不说了，简直就是吃货的天堂。

至于玩，我个人觉得长沙市内没有什么好玩的，我反而喜欢去长沙的乡里或者周边玩。所以，我实在是想不通，为什么五一、国庆黄金周长沙是这么火爆，到底火爆在哪里？？？

还有一点就是，在深圳我时不时就犯个鼻炎，回了长沙一年了我一次都没有，不知道什么原因。

工作

工资，长沙这边的钱是真的少，我现在的年收入连我深圳的三分之一都没有，都快到四分之一了。

当然，我既然选择回来了，就会接受这个低薪，而且在回来之前我就已经做好了心理建设，再加上我没有房贷和车贷，整体上来说，每个月略有结余。

所以，相比以前在深圳赚那么多钱但是无法和自己家人在一起，我更加愿意选择少赚点钱，当然，每个人的选择不同。我也见过很多，受不了长沙的低工资，然后继续回深圳搬砖的。

公司，长沙这边的互联网公司非常少，说是互联网荒漠都不为过。大部分都是传统性的公司，靠国企、外包而活着，就算有些公司说自己是互联网公司，但也不过是披着互联网的羊皮而已。而且在这里绝大多数公司都是野路子的干法，基建差，工作环境也不咋地，福利待遇与深圳的大厂更是没法比，比如社保公积金全按最低档交。年假，换一家公司就清零，我进入公司的时候，我一度以为我有 15 天，一问人事，试用期没有，转正后第一年按 5 天折算，看得我一脸懵逼。

加班，整体上来说，我感觉比深圳加班得要少，当然，大小周，单休的公司也不少，甚至有些公司连五险一金都不配齐，劳动法法外之地名副其实。

同时，这边非常看重学历，一些好的公司，非 985 、211 不要，直接把你门焊死，而这些公司整体上来说工资都很不错，40+ 起码是有的（比如某银行，我的履历完美契合，但就是学历问题而被拒），在长沙能拿这工资，简直就是一种享受，一年就是一套房的首付。

最后，你问我长沙工资这么低，你为什么还选择长沙呢？在工作和生活之间，我只不过选择了生活，仅此而已！！

前言

人类的悲喜并不相通，有人欢喜有人愁，更多的是看热闹。

就在上周，"苟住"群里的一个小伙伴也苟不住了。

在苟友们的"墙裂"要求下，他分享了他的经验，以他的视角看看他是怎么操作的。

1. 组织变动，意外晋升

两年前加入公司，依然是一线搬砖的码农。

干到一年的时候公司空降了一位号称有诸多大厂履历的大佬来带领研发，说是要给公司带来全新的变化，用技术创造价值。

大领导第一件事：抓人事，提效率。

在此背景下，公司不少有能力的研发另谋出处，也许我看起来人畜无害，居然被提拔当了小组长。

2. 领取任务，开启副本

当了半年的小组长，我的领导就叫他小领导吧，给我传达了大领导最新规划：团队需要保持冲劲，而实现的手段就是汰换。

用人话来说就是：

当季度KPI得E的人，让其填写绩效改进目标，若下一个季度再得到E，那么就得走人

我们绩效等级是ABCDE，A是传说中的等级，B是几个人有机会，大部分人是C和D，E是垫底。

而我们组就有两位小伙伴得到了E，分别是小A和小B。

小领导意思是让他们直接走得了，大不了再招人顶上，而我想着毕竟大家共事一场，现在大环境寒气满满，我也是过来人，还想再争取争取。

于是分析了他们的基本资料，他俩特点还比较鲜明。

小A资料：

1. 96年，单身无房贷


2. 技术栈较广，技术深度一般，比较粗心


3. 坚持己见，沟通少，有些时候会按照自己的想法来实现功能

小B资料：

1. 98年，热恋有房贷


2. 技术基础较薄弱，但胜在比较认真


3. 容易犯一些技术理解上的问题

了解了小A和小B的历史与现状后，我分别找他们沟通，主要是统一共识：

1. 你是否认可本次绩效评估结果？


2. 你是否认可绩效改进的点与风险点（未达成被裁）？


3. 你是否还愿意在这家公司苟？

最重要是第三点，开诚布公，若是都不想苟了，那就保持现状，不要浪费大家时间，我也不想做无用功。

对于他们，分别做了提升策略：

对于小A：

1. 每次开启需求前都要求其认真阅读文档，不清楚的地方一定要做记录并向相关人确认


2. 遇到比较复杂的需求，我也会一起参与其中梳理技术方案


3. 需求开发完成后，CR代码看是否与技术方案设计一致，若有出入需要记录下来，后续复盘为什么


4. 给足时间，保证充分自测

对于小B：

1. 每次需求多给点时间，多出的时间用来学习技术、熟悉技术


2. 要求其将每个需求拆分为尽可能小的点，涉及到哪些技术要想清楚、弄明白


3. 鼓励他不懂就要问，我也随时给他解答疑难问题，并说出一些原理让他感兴趣的话可以继续深究


4. 分配给他一些技术调研类的任务，提升技术兴趣点与成就感

3. 结束？还是是另一个开始？

半年后...

好消息是：小A、小B的考核结果是D，达成了绩效改进的目标。

坏消息是：据说新的一轮考核算法会变化，宗旨是确保团队血液新鲜（每年至少得置换10%的人）。

随缘吧，我尽力了，也许下一个是我呢？

一、前言

这不是一个单纯的技术教学专栏，而是一个 “技术人商业实践手记” 。记录一个全栈开发者如何用“每天2小时”的投入，系统性地从0到1打造一个能产生持续价值（无论是金钱、影响力还是个人成长）的“个人公司”。

二、为什么投入难有回报？

相信许多技术人都有过类似经历：

• 激情开始：某个阶段干劲满满，规划通过技术项目增加收入


• 目标宏大：开发开源系统、搭建博客、编写组件库，期待财务自由


• 现实骨感：投入大量时间后，发现自己仍在原地踏步

我的亲身教训

我尝试过几乎所有主流博客方案：

• WordPress → Hexo → VuePress/VitePress → Halo

但结果都是：上线时分享给朋友，然后... 再无下文。这完全背离了建站的初衷：打造个人影响力，为专业机会铺路。
所谓的“知识整理”和“自我提升”，很多时候只是自我安慰的借口。

三、为什么创建这个专栏？

一个清醒的认知

真正有效的盈利方法很少有人会无偿分享。

看看最近的AI创业热潮：

• 如果AI创业真的那么赚钱，为什么有人选择教学而不是扩大规模？


• 答案很现实：教学比实际创业更有利可图

坦诚的价值交换

您可能会问：你和他们有什么不同？

我坦然承认：这个专栏有我个人的目标。但区别在于：

• 我追求价值互换，而非单向收割


• 您获得的是我真实的实战经验


• 我获得的是关注度和影响力积累


• 未来可能开启付费模式，但规则透明

这是一种基于相互尊重的成长模式。

核心价值主张

简单来说：您吸取我的经验教训，我通过您的关注获得成长机会。公平，透明。

接下来的内容，我将具体分享如何用“每天2小时”打造真正有价值的个人产品...

最近刷到一条有关午睡的吐槽帖子，可能之前有小伙伴也看到过，事情大致是这样的：

有阿里同学在职场社区发帖吐槽，公司严查午休，13:34 公司纪委直接敲门，提醒别休息了，然后还一遍又一遍的巡逻……

说实话，第一眼刷到这个帖子的时候，脑子里的画面感的确有点强......就帖子来看，其实 1:30 这个时间本身没有看出太大毛病，很多公司比这还早呢，关键是氛围的突然变化的确让人会感到非常不适应，估计这也是帖主的主要槽点。

这里所谓的公司纪委我猜是类似行政或者 HRG 之类的巡查人员？中午午休时间一到，就开始挨个房间开灯、敲门，有的甚至还敲隔板，进行巡逻式提醒。另外话说回来，阿里那么大，可能不同部门或者不同 bu 在这件事情的要求上可能也太不一样吧，了解的同学可以说说，这个咱就不好过多评论了。

那说回午休这件事本身，我倒是见过几个公司的午休文化。

记得之前在某通信设备商工作时，那里的午休文化是刻在骨子里的。到了中午，是真的鼓励大家带床午休。

12 点多吃完饭，整层楼的灯基本都会关掉，大家纷纷拿出自己的小折叠床，开始午睡休息。午休时间到点了再集体把灯打开，那种集体休整的仪式感，会让下午的工作效率更高。

再比如像互联网大厂里的腾讯，每天中午也是可以午休的，茶水间的咖啡机上甚至会贴着“尽量不要在午休期间使用”的牌子，十分人性化。另外，我记得他们之前校招入职礼盒里是不是好像还发过毯子还是披肩来着？这正好可以用于午休，都不用自己买了。

这种对员工休息的尊重和保护，说实话，真的是会让人感觉到温暖的。

关于午休这个事情，我个人觉得对于程序员来说还是非常有必要的。

毕竟，面对高强度的工作，没有好的休息，靠强撑着眼皮盯着屏幕，产出的未必是价值，更多的是低效的“摸鱼”和潜在的健康风险。

就拿我自己来说，搬砖工作日我基本都是要午睡的。

原因很简单，因为我晚上一般睡得都比较晚，而早上基本 7 点就起来了，第二天中午如果不睡一会，那完了，整个下午基本都废掉了，不管是开会还是写东西，整个人都会非常地不在状态。

同理在我的小团队内部也是，我们也是很鼓励大家午睡的。

所以我们团队同学基本人手一个午休折叠床+毯子，而且如果工位这里躺不开，大家也可以去会议室那里午睡休息。

我们一般是大家中午去吃饭的时候最后走的同学办公室关灯，然后下午 1 点 40 由 HR 那边同学统一开灯，大家对于这个习惯早已约定俗成、相沿成习。

但是有一点，也是和文章开头的帖子有很大不同的是，我们的同学在开灯时，不会像文章开头帖子那样还强行给你敲门整出一波动静，我们即便灯开了，大家也还是可以稍微再躺一下，缓个几分钟再慢慢起来都没啥问题。

试想一下，要是像文首帖子说的那样，突然有人来咔咔给你一顿敲门，或者说甚至还敲隔板，那不得给人吓一机灵？

面对文章开头的吐槽贴，虽然别人的事情我们也管不了，但是看问题也不能只看表面。

透过这个吐槽帖，反映的是职场的一些微妙变化，这背后，其实折射出的或许是一种“越来越收紧”的职场环境。

那如果你正好处于这种正在收紧的工作环境之中，作为普通个体，你会怎么做呢？

这里我也想稍微多聊两句。

**首先，千万不要因为环境的变化而让自己陷入情绪不满与内耗。**很早之前的文章里我就写过，要理性地看待工作关系。

职场本质是价值交换的契约关系，这没有问题，那付诸技术和专业的同时，也要保持清醒的边界意识：既不愤世嫉俗，也不天真幼稚。

其次，要学会“物理防御”，在规则允许的缝隙内尽量对自己好一点吧。

千万不要因为环境变紧了，就主动放弃自己的需求。毕竟，身体是自己的，健康是自己的，只是方式我觉得可以更灵活变通一些。

就拿这个帖子里「午睡收紧」这件事情来说，如果公司不让关灯，那咱就搞一个好一点的眼罩和降噪耳机行不行？

如果公司不让躺睡，那咱是不是可以买个质量好一点的颈枕，即便靠在椅子、或者趴在桌子上眯一会是不是也能舒服一点？

如果中午休息时间不够，我们是不是可以充分利用碎片化时间来缓一缓，比如利用下午茶或者拿快递的时间去楼下透透气，或者在工位上做几个简单的拉伸动作。

如此之类，等等等等，大家也可以自己多想想办法。

记住，无论职场环境如何变迁，身体是自己的，健康也是自己的，先把自己身体照顾好，再去谈理想谈工作，大家觉得呢？

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

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

背景介绍

• 最近组内要做0-1的新ai产品, 招我进来就是负责这个ai产品,启动的时候这个季度就剩下两个月了,天天开会对齐进度,一个月就已经把基础版本给做完了,想要接入到现有的业务上面,时间方面就特别紧张,技术选型怎么说呢, leader用ai写了一个版本 我们在现有的代码进行二次开发这样, 全栈next.js 要学习的东西太多了 又没有前端基础,没有ai coding很难完成任务(十几分钟干完我一天的工作 claude4.5效果还不错 进度推的特别快), 自从trae下架了claude,后面就一直cursor claude 4.5了。
  
  
  
  
  • nextjs+ts+tailwindcss+shadcn ui现在是mvp套餐，startup在梭哈，时间就是生产力哪需要那么多差异化样式直接一把，有的💰才开始做细节，你会发现慢慢也💩化了。
  
  
  • Nextjs 是全栈框架 可以很快把一个MVP从零到一完整跑起来。 你要是抬杠说什么高并发负载均衡啥的，你的用户数量真多到需要考虑性能的时候，你已经不需要自己考虑了(小红书看到的一段话 挺符合场景的)
  
  
  • next.js 写后端 确实比较轻量 只能做一些curd的操作 socket之类的不太合适 其他api 还是随便开发 给我的感受就是前端能够直接操作db，前后端仓库可以不分离，业务逻辑还是一定要分离的 看看开源的next.js 项目的架构设计结构是怎么样的 学习/模仿/改造。
  
  
  • 语言只是工具，适合最重要，技术没有银弹
  
  
  
  


• nextjs.org/ github.com/vercel/next…
  

项目的时间线

项目从启动到这周 大概是5周的时间

• 10/28-10/31 Week 1
  
  
  
  • 项目初始化/需求讨论/设计文档/
  
  
  • 后端next.js, typescript技术熟悉 项目运行/调试
  
  
  • 基础框架搭建 设计表结构ddl, 集成mysql, 编写crud接口阶段
  
  
  
  


• 11/03-11/07 Week 2
  
  
  
  • 产品PRD 提供
  
  
  • xxxx等表设计
  
  
  
  


• 11/10-11/14 Week 3
  
  
  
  • xxxxx 基本功能完结
  
  
  • @xxxx 讲解项目结构/规范
  
  
  
  


• 11/17-11/21 Week 4
  
  
  
  • 首页样式/逻辑 优化
  
  
  • 集成统一登录调研
  
  
  • 部署完成
  
  
  
  


• 11/24-11/28 Week 5
  
  
  
  • 服务推理使用Authorization鉴权 对内接口使用Cookies (access_token) 鉴权 开发
  
  
  • xxxx 表设计表设计 逻辑开发
  
  
  • xxx设计 设计开发
  
  
  • 联调xxxx
  
  
  
  

5周时间 功能基本完成了 剩下的就是部署到线上 进行场景实践了

前端技术栈

• Next.js 14：选择 App Router 架构，支持服务端渲染和 API Routes


• TypeScript 5.4：强类型语言提升代码质量和可维护性


• React 18：利用并发特性和 Suspense 提升用户体验


• Zustand：轻量级状态管理，替代 Redux 降低复杂度


• Ant Design + Radix UI：组件库组合，平衡美观性和可访问性

React + TypeScript react.dev/

• 优势：类型安全：TypeScript 提供编译时类型检查，减少运行时错误 ✅ 组件化开发：高度可复用的组件设计 ✅ 生态成熟：丰富的第三方库和工具链 ✅ 开发体验：优秀的 IDE 支持和调试工具


• 劣势： ❌ 学习曲线：TypeScript 对新手有一定门槛 ❌ 编译时间：大型项目编译可能较慢 ❌ 配置复杂：类型定义需要额外维护

UI 组件方案 Ant Design + Radix UI 混合方案

• 优势： ✅ 快速开发：Ant Design 提供完整的企业级组件 ✅ 无障碍性：Radix UI 提供符合 WAI-ARIA 标准的组件 ✅ 定制灵活：Radix UI 无样式组件便于自定义 ✅ 中文支持：Ant Design 对中文界面友好


• 劣势： ❌ 包体积大：两个 UI 库增加了打包体积 ❌ 样式冲突：需要注意两个库的样式隔离❌ 维护成本：需要同时维护两套组件系统

Tailwind CSS

• 优势： ✅ 开发效率高：原子化类名，快速构建 UI ✅ 体积优化：生产环境自动清除未使用的样式 ✅ 一致性：设计系统内置，确保视觉一致 ✅ 响应式：便捷的响应式设计工具


• 劣势： ❌ 类名冗长：HTML 可能变得难以阅读 ❌ 学习成本：需要记忆大量类名 ❌ 非语义化：类名不直观反映元素意义

ant design x

ahooks

后端技术栈

• Prisma 6.18：现代化 ORM，类型安全且支持 Migration


• MySQL：成熟的关系型数据库，满足复杂查询需求


• Redis (ioredis) ：高性能缓存，支持多种数据结构


• Winston：企业级日志系统，支持日志轮转和结构化输出


• Zod：运行时类型验证，保障 API 数据安全

Next.js API Routes

• 优势： ✅ 统一代码库：前后端在同一项目中 ✅ 类型共享：TypeScript 类型可在前后端复用 ✅ 开发效率：无需配置跨域、代理等 ✅ 部署简单：单一应用部署


• 劣势： ❌ 扩展性限制：无法独立扩展后端服务 ❌ 性能瓶颈：Node.js 单线程可能成为瓶颈 ❌ 微服务困难：不适合复杂的微服务架构

Prisma ORM

• 优势： ✅ 类型安全：自动生成 TypeScript 类型 ✅ 迁移管理：声明式 schema，易于版本控制 ✅ 查询性能：生成优化的 SQL 查询 ✅ 关系处理：直观的关系查询 API ✅ 多数据库支持：支持 MySQL、PostgreSQL、SQLite 等


• 劣势： ❌ 复杂查询：某些复杂 SQL 可能需要原始查询 ❌ 生成代码体积：生成的 client 文件较大 ❌ 版本升级：大版本升级可能需要迁移

踩坑记录

主要是记录一些开发过程中踩坑 和设计问题

• node js 项目 jean部署


• 自定义配置/dockerfile配置 没有类似项目参考 健康检查问题 加上环境变量配置多环境 一步一步


• next.js 中 用middleware进行接口拦截鉴权 里面有prisma path import 直接出现了Edge Runtime 异常 自定义auth 解决


• npm build 项目 踩坑


• 静态渲染流程 动态api 警告 强制动态渲染


• 其他组件 document 不支持build问题


• 保存多场景模式+构建版本管理第一版考虑的太少了，发现有问题 后面又重构了一版本


• xxx日志目前还没有接入 要不就是日志文件 要不就是console.log 目前看日志的方式是去容器化运行日志看了 后续集群部署就比较麻烦了


• ant design 版本降低到6.0以下 ant-design x 用不了2.0.0 的一些对话组件

Next.js实践的项目记录

苏州 trae friends线下黑客松 📒

• 去Trae pro-Solo模式 苏州线下hackathon一趟, 基本都是一些独立开发者，一人一公司，三个小时做出一个产品用Trae-solo coder模式，不得不说trae内部集成的vercel部署很丝滑 react项目一键deploy访问 完全不用关系域名服务器, solo模式其实就是混合多种model使用进行输出 想要的效果还是得不断的调试 thiking太长，对于前后端分离项目 也能够同时关联进行思考规划。


• 1点多到4点 coding时间 从0-1生成项目 使用trae pro solo模式 就3个小时 做不了什么大的东西 那就做个日语50音的网站呗 现场酒店的网基本用不了 我数据也很卡 用的旁边干中学老师的热点 用next.js tailwindcss ant design deepseek搭建的网页 够用了 最后vercel部署 trae自带集成 挺方便的 solo模式还是太慢了 接受不了 网站地址是 traekanastudio1ssw.vercel.app/ 功能就是假名+ai生成例句和单词 我都没有路演 最后拿优秀奖可能是我部署了吧 大部分人没部署 优秀奖就是卫衣了 蹭了一天的饭加零食 爽吃


• http://www.xiaohongshu.com/explore/692… 小红书当时发的帖子 可以领奖品

Typescript的AI方向 langchain/langgraph支持ts

• 最近在看的ts的ai框架 发现langchain 是支持ts的, langchain-chat 主要是使用langchain+langgraph 对ts进行实践 traechat-apps4y6.vercel.app/


• 部署还踩坑了 MCP 在 Vercel 上不生效是因为 Vercel 是 serverless 环境，不支持运行持久的子进程。让我帮你解决这个问题：


• 主要是对最近项目组内要用的到mcp/function call 进行实践操作 使用modelscope 上面开源的mcp进行尝试 使用vercel进行部署。


• 最近看到小红书上面的3d 粒子 圣诞树有点火呀，自己也尝试下 效果很差 自己弄的提示词 可以去看看帖子上的提示词去试试 他们都是gemini pro 3玩的 我也去弄个gemini pro 3 账号去玩玩。


• 还有一个3d粒子 跟着音乐动的的效果 下面的提示词可以试试

帮我构建一个极简科幻风格的 3D 音乐可视化网页。

视觉上参考 SpaceX 的冷峻美学，全黑背景，去装饰化。核心是一个由数千个悬浮粒子组成的‘生命体’，它必须能与声音建立物理连接：低音要像心脏搏动一样冲击屏幕，高音要像电流一样瞬间穿过点阵。

重点实现一种‘ACID 流体’视觉引擎：让粒子表面的颜色不再是静态的，而是像两种粘稠的荧光液体一样，在失重环境下互相吞噬、搅拌、流动，且流速由音乐能量驱动。

• docs.langchain.com/oss/javascr…


• http://www.modelscope.ai/home


• vercel.com


• http://www.modelscope.ai/mcp

ai方向 总结

• a2a解决的是agent之间如何配合工作的问题 agent card定义名片 名称 版本 能力 语言 格式 task委托书 通信方式http 用户 客户端是主控 接受用户需求 制定具体任务 向服务器发出需求 任务分发 接受响应 服务器是各类部署好的agent 遵循一套结构化模式


• mcp 解决的llm自主调用功能和工具问题


• mcp 是解决 function call 协议的碎片化问题，多 agent 主要是为了做上下文隔离


• 比如说手机有一个system agent 然后各个app有一个agent，用户语音输入买咖啡，然后system agent调用瑞幸agent 这样就是非侵入式 让app暴露系统a2a接口，感觉比mcp要更合理一点，不是单纯让app暴露tools，系统agent只需要做路由


• 而且有一点我觉得挺有意思的，就是自己的agent花的token是自己的钱，如果自己的agent找别人的agent，让它执行任务啥的，花的不就是别人的钱……


• Dify：更像宜家的模块化家具，提供可视化工作流、预置模板，甚至支持“拖拽式”编排AI能力。比如，你想做一
  个智能客服，只需在界面里连接对话模型、知识库和反馈按钮，无需写一行代码

python 和ts 在ai上面的比较

• Python 依然是 AI 训练和科研的王者，PyTorch、TensorFlow、scikit-learn 这些生态太厚实了，训练大模型你离不开它。


• TS 在底层 AI 能力上还没那么能打，GPU 加速、模型优化这些，暂时还得靠 Python 打底。


• Python 搞理论和模型，TypeScript卷体验和交付

个人学习记录

主要还是前端和ai方面的知识点学习的比较多吧

• Typescript 语法基础+进阶 / Next.js 开发指南/React 开发指南


• ahooks 组件 使用 ahooks.js.org/zh-CN/hooks…


• ant design x 使用 ant-design-x.antgroup.com/components/…


• prisma orm框架 +mysql github.com/prisma/pris…


• dotenv 读取配置文件 github.com/dotenvx/dot…


• fastmcp 项目构建使用 原理


• Agent2Agent google协议内部详情
  
  
  
  • github.com/MarkTechSta…
  
  
  • github.com/a2aproject/…
  
  
  • a2a-protocol.org/latest/topi…
  
  
  
  


• swagger.io/specificati… OpenAPI 规范 一个 OpenAPI 描述（OAD）可以由一个 JSON 或 YAML 文档组成


• github.com/yossi-lee/s… 根据Swagger3规范，一键将Web服务转换为MCP


• http://www.jsonrpc.org/specificati… JSON-RPC 是一种无状态、轻量级的远程过程调用（RPC）协议


• github.com/agno-agi/ag… 多智能体框架


• roadmap.sh/ai-engineer ai工程师的roadmap 很全


• github.com/ChromeDevTo… *可以集成到cursorz中 *AI 能够直接控制和调试真实的 Chrome 浏览器


• http://www.nano-banana.ai/ Nano Banana Pro (V2) 文生图 图生图


• aistudio.google.com/prompts/new… gemini ai studio

Vibe Coding

• 先叠甲, 我没有前端的开发经验，第一次写前端项目，项目里面90%的前端代码都是ai 生成的，能够让你一个不会前端的同学也快速完成mvp版本/需求任务。我虽然很推ai coding 很喜欢用, 即时反馈带来的成就感, 但是对于生成的代码是不是屎山 大概率可能是了, 因为前期 AI速度快，制造屎山的速度更快。无论架构设计多优秀，也难避免屎山代码的宿命: 需求一直在变，你的架构设计是针对老的需求，随着新的需求增加，老的架构慢慢的就无法满足了，需要重构。


• 一起开发的前端同事都说ai生成那些样式互相影响了,样式有tailwindcss 有自定义的css 每个模块又有不同 大概率出问题 有冲突，就是💩山。


• 最大的开发障碍就是内心的偏见 不愿意放弃现在所擅长的东西 带着这份偏见不愿意去学习

对于ai coding 的话 用过trae-pro/cursor/qoder/copilot/codex等等 最终还是cursor claude 4.5用的最舒服

• 基本一周一个cursor pro账号 买号都花了快1k了。

You have used up your included usage and are on pay-as-you-go which is charged based on model API rates. You have spent $0.00 in on-demand usage this month.

• 最后就是需要学好英语 前端的技术文档都是英文的 虽然有中文的翻译版本, 但没有自己直接去看官方的强 难免有差异， 我现在都是用插件进行web翻译去看的 很累。


• 现在时间是凌晨 11/30/02:36 喝了两瓶酒。这个周末我要重温甜甜的恋爱 给我也来一颗药丸 给时间是时间 让过去过去, 年底想去日本跨年了

2025 年 10 月 15 日，苹果公司正式发布全新 M5 芯片。作为继 M4 之后的又一代 Apple Silicon 处理器，M5 采用第三代 3nm 制程工艺，在 AI 运算、图形性能与能效方面实现全面突破，标志着苹果在“端侧 AI”赛道上的又一次重大跨越。

目前，M5 已率先搭载于 14 英寸 MacBook Pro、新一代 iPad Pro 与 Apple Vision Pro，并同步开启预订。

一、核心亮点：GPU 首次集成神经加速单元

M5 最引人注目的革新，在于其 GPU 架构的彻底重构：

• 全新 10 核 GPU，每个核心均内置独立 Neural Accelerator（神经加速单元）


• GPU 的 AI 计算峰值性能较 M4 提升超 4 倍


• 相比初代 M1，AI 性能提升 超过 6 倍

苹果硬件技术高级副总裁 Johny Srouji 表示：“M5 标志着 Apple 芯片在 AI 性能上的又一次重大跨越。”

这一设计打破了传统 CPU/GPU/Neural Engine 三者分离的 AI 计算模式，使 GPU 本身具备原生 AI 推理能力，特别适合图像生成、视频处理、空间计算等高负载场景。

二、三大核心模块全面升级

1. CPU：更高能效，更强多线程

• 10 核 CPU 架构：6 个高能效核心 + 4 个高性能核心


• 多线程性能较 M4 提升最高达 15%


• 搭载“全球最快 CPU 核心”，兼顾性能与续航

2. 神经引擎（Neural Engine）：协同加速 AI 任务

• 16 核神经引擎，专为机器学习优化


• 与 GPU/CPU 中的神经加速单元协同工作


• 在 Apple Vision Pro 上可极速生成“空间化照片”或个性化 Persona


• 为 Apple Intelligence 提供高效本地运行支持，如 Image Playground 响应更迅捷

官方介绍，M5 芯片的设计是围绕AI展开的，采用新一代 GPU 架构，每个计算单元均针对 AI 进行优化。10 核 GPU 中各个核心内置有专用神经加速器，峰值 GPU 计算性能达到 M4 的 4 倍有余，AI 峰值性能更达到 M1 的 6 倍以上。

3. 统一内存架构：带宽与容量双突破

• 内存带宽高达 153 GB/s，比 M4 提升近 30%


• 支持最高 32GB 统一内存


• 整个 SoC 共享同一内存池，大幅提升多任务与大模型本地运行能力

实测场景：用户可同时运行 Adobe Photoshop + Final Cut Pro + 后台上传大文件，系统依然流畅。

三、软件生态深度协同：Metal 4 + Core ML 赋能开发者

M5 的硬件革新离不开软件栈的配合。苹果通过以下框架释放 M5 的全部潜能：

开发者可通过 Metal 4 构建专属 AI 加速方案，例如在本地运行 Draw Things（扩散模型绘图） 或 webAI 上的大语言模型。

四、实际应用场景：端侧 AI 落地加速

M5 的强大 AI 能力已在多个场景中体现：

• Apple Vision Pro：实时生成 3D 空间照片、个性化虚拟形象


• iPad Pro：本地运行 Stable Diffusion 类模型，秒级出图


• MacBook Pro：AI 编程助手、视频智能剪辑、语音实时转写等任务无需联网


• Apple Intelligence：所有 AI 功能均在设备端完成，保障隐私与低延迟

五、能效与环保：性能提升，功耗更低

尽管性能大幅跃升，M5 仍延续苹果芯片高能效传统：

• 采用先进 3nm 工艺，晶体管密度更高、漏电更少


• 在相同性能下功耗显著低于竞品


• 支持苹果 “Apple 2030”碳中和计划，从材料、制造到运输全链路减碳

这意味着新款 MacBook Pro、iPad Pro 和 Vision Pro 在获得更强性能的同时，续航更长、发热更低、环境足迹更小。

M5虽然又上面几个方面的提升，但是是否值得为M5献上自己的血汗钱，先看看用过的网友怎么说？

一个眼光长远的网友说到：

这里也期待下M6的到来！

当然如果你是一个AI重度开发者或者使用者，M5也是值得冲一把的。

下面就来看看者3款产品。

M5 MacBook Pro

外观和之前差别不大， 14 英寸 120Hz 3024*1964 的刘海屏，峰值亮度为 1600nits。

三个 Thunderbolt 4 端口、一个 HDMI 接口、一个 SD 卡槽、一个 3.5 耳机插孔。

最大的提升就是你可以拥有 4TB 的存储规格，但是价格和 512GB 相比差了 9000 块，相当于1TB的价格接近3000块大洋。

内存方面有16GB 和 24GB 以及 32GB，具体价格如下

对于普通的开发场景选择16GB就可以了，如果是做大数据，AI大模型开发可以选择32GB。

iPad Pro

屏幕采用双层 120Hz OLED ，11 英寸分辨率为 24201668，13 英寸分辨率为 27522064。

颜色一样提供深空黑色和银色两种可选

Vision Pro

新版的Vision Pro 除了从 M2+R1 组合升级到 M5+R1 之外，最显眼的变化就是升级了新的双针织头戴套。

续航也从原来的 2 小时扩展至 3 小时，最高刷新率也从 100Hz 增至 120Hz，有效减少了观看物理环境时的运动模糊。

不过价格最低高达9000,确实劝退了很多人。

总结：M5 是 Apple Intelligence 的“终极载体”

如果说 M1 是 Apple Silicon 的起点，M2/M3 是成熟，M4 是 AI 探索，那么 M5 就是 Apple Intelligence 的落地基石。

通过 GPU 内置神经加速单元 + 统一内存 + 软件深度协同，M5 不仅是一颗芯片，更是苹果构建“端侧 AI 生态系统”的核心引擎。

未来，随着更多 AI 应用向本地迁移，M5 将成为开发者与用户拥抱下一代人机交互的关键硬件平台。

端侧 AI 的时代，已经到来。

兄弟们，前天的瓜都吃了吗？🤣

说实话，作为一名还在写代码的打工仔，看到前天晚上快手那个热搜，我手里捧着的咖啡都不香了，后背一阵发凉。

12月22日晚上10点，正是流量最猛的时候，快手直播间突然失控。不是服务器崩了，而是内容崩了——大量视频像洪水一样灌进来。紧接着就是官方无奈的拔网线，全站直播强行关停。第二天开盘，股价直接跌了3个点。

这可不是普通的 Bug，这是P0 级中的 P0。

很多群里在传内鬼或者0day，但看了几位安全圈大佬（360、奇安信）的复盘，我发现这事儿比想象中更恐怖：这是一次教科书级别的黑产自动化降维打击。

今天不谈公关，咱们纯从技术角度复盘一下：假如这事儿发生在你负责的项目里，你的前端代码能抗住几秒？

当脚本比真人还多还快时？

这次事故最骚的地方在于，黑产根本不按套路出牌。

以前的攻击是 DDoS，打你的带宽，让你服务不可用。

这次是 Content DDoS（内容拒绝服务）。

1. 前端防线形同虚设

大家有没有想过，黑产是怎么把视频发出来的？

他们绝对不会坐在手机前，一个一个点开始直播。他们用的是群控、是脚本、是无头浏览器（Headless Browser）。

这意味着什么？

意味着你前端写的那些 if (user.isLogin)、那些漂亮的 UI 拦截、那些弹窗提示，在黑客眼里全是空气。他们直接逆向了你的 API，拿到了推流接口，然后几万个并发调用。

2. 审核系统被饱和式攻击

后端通常有人工+AI 审核。平时 QPS 是 1万，大家相安无事。

昨晚，黑产可能瞬间把 QPS 拉到了 100万。

云端 AI 审核队列直接爆了，人工审核员估计鼠标都点冒烟了也审不过来。一旦阈值被击穿，脏东西就流到了用户端。

那前端背锅了吗？

虽然核心漏洞肯定在后端鉴权和风控逻辑（大概率是接口签名泄露），但咱们前端作为 离黑客最近的一层皮，如果做得好，绝对能把攻击成本拉高 100 倍。

来，如果不幸遇到了这种自动化脚本攻击，咱们前端手里还有什么牌？🤔

别把 Sign 算法直接写在 JS 里！

很多兄弟写接口签名，直接在 request.js 里写个 md5(params + salt) 完事。

大哥，Chrome F12 一开，Sources 一搜，断点一打，你的盐（Salt）就裸奔了。

防范操作：直接上 WASM (WebAssembly)

把核心的加密、签名逻辑，用 C++ 或 Rust 写，编译成 .wasm 文件给前端调。

黑客想逆向 WASM？那成本可比读 JS 代码高太多了。这就是给他们设的第一道坎。

你的用户，可能根本不是人

黑产用的是脚本。脚本和真人的操作是有本质区别的。

不要只会在登录页搞个滑块，没用的，现在的图像识别早破了。

要在 关键操作（比如点击开始直播） 前，采集一波数据：

• 鼠标轨迹：真人的轨迹是曲线（贝塞尔曲线），脚本通常是直线。


• 点击间隔：脚本是毫秒级的固定间隔，人是有随机抖动的。

// 伪代码，简单的是不是人检测

function isHuman(events) {

    // 如果鼠标轨迹过于平滑或呈绝对直线 -> 机器人

    if (analyzeTrajectory(events) === 'perfect_linear') return false;

    // 如果点击时间间隔完全一致 -> 机器人

    if (checkTiming(events) === 'fixed_interval') return false;

    return true;

}

把这些行为数据打分，随着请求发给后端。分低的，直接拒绝推流。

既然防不住内鬼，那就给他打标

这次很多人怀疑是内部泄露了接口文档或密钥。说实话，这种事防不胜防。

但是，前端可以搞 盲水印。

在你的 Admin 管理后台、文档平台，加上肉眼看不见的 Canvas 水印（把员工 ID 编码进背景图的 RGB 微小差值里，具体大家自己去探索😖）。

一旦截图流出，马上就能解码出是哪个员工泄露的。威慑力 > 技术本身。

或者试试这个技巧 👉 如何用隐形字符给公司内部文档加盲水印?(抓内鬼神器🤣)

安全复盘

这次快手事件，其实就死在了一个逻辑上： 后端太信任通过了前端流程的请求。

我们写代码时常犯的错误：

• 前端校验过手机号格式了，后端不用校验了吧？


• 必须点了按钮才能触发这个请求，所以这个接口很安全。

大错特错！

2025 年了，兄弟们。在 Web 的世界里，不相信前端 才是保命法则。

任何从客户端发来的数据，都要默认它是有毒的。

之前我都发过类似的文章：为什么永远不要相信前端输入？绕过前端验证，只需一个 cURL 命令！

希望对你们有帮助👆

这次是快手，下次可能就是咱们的公司。

尤其是年底了，黑灰产也要冲业绩（虽然这个业绩有点缺德😖）。

建议大家上班时看看这几件事：

前端不只是画页面的，关键时刻，咱们也是安全防线的一部分。

别等到半夜被运维电话叫醒，那时候就真只能甚至想重写简历了🤣。

引言

记得我刚去北京工作的那段时间，由于工作原因开始吃外卖，加上缺乏运动，几个月胖了20斤。

当时心想这不行啊，我怕我拍婚纱照的时候扣不上西服的扣子，我决心减肥。

在我当时的认知里，只要对自己狠一点、饿一饿，就能瘦成理想状态。于是我晚上不吃饭，下班后去健身房跑5公里，1个月的时间瘦了15斤。我很自豪，身边的人说我明显精神多了。

可减肥这事远比我想的复杂，由于没有对应的增肌训练，我发现在做一些力量训练的时候，比之前没减肥前更吃力了。

我这才意识到，自己不仅减掉了脂肪，还减掉了不少肌肉。

我当时完全没有意识到这套方法的问题，也不知道如何科学评估身体组成变化——减肥是成功了，但减的不止是“脂肪”，还有“体能”。

上篇文章提到我对节食减肥的做法并不是特别认可，那科学的方法应该是怎么样的呢，我做了如下调研。

重新理解“减肥”这件事

想系统性地弄清楚减肥到底是怎么回事，我先从最直接的方式开始：看看别人都是怎么做的。

我先去搜了小红书、抖音等平台，内容五花八门，有节食的，有吃减肥药的，也有高强度训练比如HIIT的，还有各种花里胡哨的明星减肥法。

他们动不动就是瘦了十几斤，并且减肥前后的对比非常强烈，我都有种立刻按照他们的方式去试试的冲动。

大部分攻略中都会提到一个关键词“节食”，看来“少吃”几乎成了所有减肥成功者的共识。

我接着去谷歌搜索“节食 减肥”关键字，排名比较靠前的几篇文章是这几篇。

搜索引擎搜出来的一些内容，却讲了一些节食带来的一些不良影响，比如反弹、肌肉流失、代谢下降、饥饿激素紊乱...

这时候我很疑惑，社交媒体上“万人点赞”的有效手段，在官方媒体中的描述，完全不同。

我还需要更多的信息，为此我翻了很多关于节食减肥的书籍。

我在《我们为什么吃（太多）》这本书里看到了一个美国的实验。

美国有一档真人秀节目叫《超级肥胖王》。节目挑选了一些重度肥胖的人，所有参赛者通过高强度节食和锻炼项目，减掉好几十千克的重量。

但研究追踪发现，6年之后，他们平均都恢复了41千克的体重。而且相比六年前，他们的新陈代谢减少了700千卡以上，代谢率严重下降。

有过节食减肥经历的朋友可能都会有过反弹的经历，比如坚持一周较高强度的节食，两天可能就涨回来了。前一阵子一个朋友为了拍婚纱照瘦了很多，最近拍完回了一趟老家，再回北京一称胖了10斤，反弹特别多。

并且有另外一项研究者实验发现，极端节食后，我们体内负责刺激食欲的激素水平比节食前高出了24%，而且进食后获得的饱腹感也更低了。

也就是说你的大脑不知道你正在节食还是遇到了饥荒，所以它会努力的调节体重到之前的水平。

高强度节食是错误的。

正确选项

或许你想问，什么才是正确的减肥方式呢？

正确的做法因人而异，脱离身体状况谈减肥就是耍流氓。

最有参考价值的指标是BMI，我国肥胖的BMI标准为：成人BMI≥28 kg/m²即为肥胖，24.0≤BMI<28.0 kg/m²为超重，BMI<18.5 kg/m²为体重过低，18.5≤BMI<24.0 kg/m²为正常范围。

比如我目前30岁，BMI超过24一点，属于轻微超重。日常生活方式并不是很健康，在办公室对着电脑一坐就是一天。如果我想减肥，首先考虑多运动，如跑步、游泳。

但如果我的BMI达到28，那么就必须要严格控制饮食，叠加大量的有氧运动。

如果针对50岁以上的减肥，思路完全不一致。这个年纪最重要的目标是身体健康，盲目节食会引发额外问题：肌肉流失、骨质疏松、免疫力下降。

这时候更需要的是调整饮食结构，保证身体必要的营养摄入。如果选择运动，要以安全为第一原则，选择徒手深蹲、瑜伽、快走、游泳这些风险性较小的运动。

但无论你什么年龄、什么身体情况，我翻了很多资料，我挑了几种适合各种身体情况的减重方式：

第一个是好好吃。饮食上不能依赖加工食品，比如薯片、面包、饼干，果汁由于含糖量很高，也要少喝。

吃好的同时还要学会感受自己的吃饱感，我们肯定都有过因为眼前的食物太过美味，哪怕肚子已经饱了，我们还是强行让自己多吃两口。

最好的状态就是吃到不饿时停止吃饭，你需要有意识的觉察到自己饱腹感的状态。我亲身实践下来吃饭的时候别刷手机、看视频，对于身体的敏感度就会高很多，更容易感觉到饱腹感。

第二个是多睡。有研究表明缺乏睡眠会导致食欲激素升高，实验中每天睡4.5小时和每天睡8.5小时两组人群，缺觉的人每天会多摄入300千卡的能量。

我很早之前就听过一个词叫“过劳肥”。之前在互联网工作时就见过不少人，你眼看着他入职的时候还很瘦，半年或者一年后就发福了，主要就是经常熬夜或者睡眠不足还会导致内分泌紊乱和代谢异常。

最近一段时间娃晚上熬到11点睡，早上不到七点就起床，直接导致我睡眠不足。最直观的感受就是自己对于情绪控制能力下降了，更容易感受到压力感，因此会希望通过多吃、吃甜食才缓解自己的状态。

第三个就是锻炼。这里就是最简单的能量守恒原则了，只要你运动就会消耗热量，那你说我工作很忙，没时间跑步、跳绳、游泳，还有一个最简单的办法。

那就是坚持每天走一万步，研究表明每天走一万步，就能把肥胖症的风险降低31%，而且这是维护代谢健康最简单的办法了，而且走一万步的好处还有特别多，就不一一说了。

如果一开始一万步太多，那就从每天5000步开始，逐渐增加，每一步都算数。

这三种方法看起来见效慢，却正是打破节食陷阱的长期解法。这也就引出了接下来我想说的，如果节食减肥会反弹人，也有一定的副作用，为什么很多人依然把节食当成减肥的首选呢？

系统性的问题在哪

首先追求确定性和掌控感。节食是一种快速见效的方式，今天饿了一天肚子，明天早上上秤就发现轻了两斤，这种快速反馈和高确定性，会让你更有掌控感。

我在节食+跑步的那段时间，真的是做到了每周都能掉秤，这种反馈就给了我很强的信心。其实工作之后，生活中这样高确定的性的事情已经越来越少了。

节食带来的确定性反馈，就像生活中为数不多还能掌控的事情，让人心甘情愿的付出代价。但我们却很少意识到，看似“自律”的背后，其实正一点点破坏着我们的身体基础。

其次是大部分时候，我们不需要了解身边事物的科学知识。

绝大部分人对营养、代谢的理解非常有限。毕竟我们并不需要详细控制体重的科学方式，体重也能保持的不错。偶尔大吃大喝一段时间，发现自己胖了，稍微控制一下体重也就降回来了。

但一旦你下定决心减肥，简单的理解就远远不够了，你就容易做出错误的判断，比如节食。短期更容易见效，确定性更高，但长远来看只能算下策。

你得有那种看到体检结果突然异常，就赶紧上网查询权威的医学解释一般的态度才行，根据自己的情况用科学的方式控制体重。

而不是只想到节食。

这是东东拿铁的第89篇原创文章，感谢阅读，全文完，喜欢请三连。

1. 引言：设计系统的“寒武纪大爆发”与 Arco 的陨落

在 2019 年至 2021 年间，中国前端开发领域经历了一场前所未有的“设计系统”爆发期。伴随着企业级 SaaS 市场的崛起和中后台业务的复杂度攀升，各大互联网巨头纷纷推出了自研的 UI 组件库。这不仅是技术实力的展示，更是企业工程化标准的话语权争夺。在这一背景下，字节跳动推出了 Arco Design，这是一套旨在挑战 Ant Design 霸主地位的“双栈”（React & Vue）企业级设计系统。

Arco Design 在发布之初，凭借其现代化的视觉语言、对 TypeScript 的原生支持以及极具创新性的“Design Lab”设计令牌（Design Token）管理系统，迅速吸引了大量开发者的关注。它被定位为不仅仅是一个组件库，而是一套涵盖设计、开发、工具链的完整解决方案。然而，就在其社区声量达到顶峰后的短短两两年内，这一曾被视为“下一代标准”的项目却陷入了令人费解的沉寂。

截至 2025 年末，GitHub 上的 Issues 堆积如山，关键的基础设施服务（如 IconBox 图标平台）频繁宕机，官方团队的维护活动几乎归零。对于数以万计采用了 Arco Design 的企业和独立开发者而言，这无疑是一场技术选型的灾难。

本文将深入剖析 Arco Design 从辉煌到停摆的全过程。我们将剥开代码的表层，深入字节跳动的组织架构变革、内部团队的博弈（赛马机制）、以及中国互联网大厂特有的“KPI 开源”文化，为您还原整件事情的全貌。

2. 溯源：Arco Design 的诞生背景与技术野心

要理解 Arco Design 为何走向衰败，首先必须理解它诞生时的宏大野心及其背后的组织推手。Arco 并不仅仅是一个简单的 UI 库，它是字节跳动在高速扩张期，为了解决内部极其复杂的国际化与商业化业务需求而孵化的产物。

2.1 “务实的浪漫主义”：差异化的产品定位

Arco Design 在推出时，鲜明地提出了“务实的浪漫主义”这一设计哲学。这一口号的提出，实际上是为了在市场上与阿里巴巴的 Ant Design 进行差异化竞争。

• Ant Design 的困境：作为行业标准，Ant Design 以“确定性”著称，其风格克制、理性，甚至略显单调。虽然极其适合金融和后台管理系统，但在需要更强品牌表达力和 C 端体验感的场景下显得力不从心。


• Arco 的切入点：字节跳动的产品基因（如抖音、TikTok）强调视觉冲击力和用户体验的流畅性。Arco 试图在中后台系统中注入这种基因，主张在解决业务问题（务实）的同时，允许设计师发挥更多的想象力（浪漫）。

这种定位在技术层面体现为对 主题定制（Theming） 的极致追求。Arco Design 并没有像传统库那样仅仅提供几个 Less 变量，而是构建了一个庞大的“Design Lab”平台，允许用户在网页端通过可视化界面细粒度地调整成千上万个 Design Token，并一键生成代码。这种“设计即代码”的早期尝试，是 Arco 最核心的竞争力之一。

2.2 组织架构：GIP UED 与架构前端的联姻

Arco Design 的官方介绍中明确指出，该系统是由 字节跳动 GIP UED 团队 和 架构前端团队（Infrastructure FrontEnd Team） 联合推出的。这一血统注定了它的命运与“GIP”这个业务单元的兴衰紧密绑定。

2.2.1 GIP 的含义与地位

“GIP” 通常指代 Global Internet Products（全球互联网产品）或与之相关的国际化/商业化业务部门。在字节跳动 2019-2021 年的扩张期，这是一个充满活力的部门，负责探索除了核心 App（抖音/TikTok）之外的各种创新业务，包括海外新闻应用（BuzzVideo）、办公套件、以及各种尝试性的出海产品。

• UED 的话语权：在这一时期，GIP 部门拥有庞大的设计师团队（UED）。为了统一各条分散业务线的设计语言，UED 团队急需一套属于自己的设计系统，而不是直接沿用外部的 Ant Design。


• 技术基建的配合：架构前端团队的加入，为 Arco Design 提供了工程化落地的保障。这种“设计+技术”的双驱动模式，使得 Arco 在初期展现出了极高的完成度，不仅有 React 版本，还同步推出了 Vue 版本，甚至包括移动端组件库。

2.3 黄金时代的技术堆栈

在 2021 年左右，Arco Design 的技术选型是极具前瞻性的，这也是它能迅速获得 5.5k Star 的原因之一：

• 全链路 TypeScript：所有组件均采用 TypeScript 编写，提供了优秀的类型推导体验，解决了当时 Ant Design v4 在某些复杂场景下类型定义不友好的痛点。


• 双框架并进：@arco-design/web-react 和 @arco-design/web-vue 保持了高度统一的 API 设计和视觉风格。这对于那些技术栈不统一的大型公司极具吸引力，意味着设计规范可以跨框架复用。


• 生态闭环：除了组件库，Arco 还发布了 arco-cli（脚手架）、Arco Pro（中后台模板）、IconBox（图标管理平台）以及 Material Market（物料市场）。这表明团队不仅是在做一个库，而是在构建一个类似 Salesforce Lightning 或 SAP Fiori 的企业级生态。

然而，正是这种庞大的生态铺设，为日后的维护埋下了巨大的隐患。当背后的组织架构发生震荡时，维持如此庞大的产品矩阵所需的资源将变得不可持续。

3. 停摆的证据：基于数据与现象的法医式分析

尽管字节跳动从未发布过一份正式的“Arco Design 停止维护声明”，但通过对代码仓库、社区反馈以及基础设施状态的深入分析，我们可以断定该项目已进入实质性的“脑死亡”状态。

3.1 代码仓库的“心跳停止”

对 GitHub 仓库 arco-design/arco-design (React) 和 arco-design/arco-design-vue (Vue) 的提交记录分析显示，活跃度在 2023 年底至 2024 年初出现了断崖式下跌。

3.1.1 提交频率分析

虽然 React 版本的最新 Release 版本号为 2.66.8（截至文章撰写时），但这更多是惯性维护。

• 核心贡献者的离场：早期的高频贡献者（如 sHow8e、jadelike-wine 等）在 2024 年后的活跃度显著降低。许多提交变成了依赖项升级（Dependabot）或极其微小的文档修复，缺乏实质性的功能迭代。


• Vue 版本的停滞：Vue 版本的状态更为糟糕。最近的提交多集中在构建工具迁移（如迁移到 pnpm）或很久以前的 Bug 修复。核心组件的 Feature Request 长期无人响应。

3.1.2 积重难返的 Issue 列表

Issue 面板是衡量开源项目生命力的体温计。目前，Arco Design 仓库中积累了超过 330 个 Open Issue。

• 严重的 Bug 无人修复：例如 Issue #3091 “tree-select 组件在虚拟列表状态下搜索无法选中最后一个” 和 Issue #3089 “table 组件的 default-expand-all-rows 属性设置不生效”。这些都是影响生产环境使用的核心组件 Bug，却长期处于 Open 状态。


• 社区的绝望呐喊：Issue #3090 直接以 “又一个没人维护的 UI 库” 为题，表达了社区用户的愤怒与失望。更有用户在 Discussion 中直言 “这个是不是 KPI 项目啊，现在维护更新好像都越来越少了”。这种负面情绪的蔓延，通常是一个项目走向终结的社会学信号。

3.2 基础设施的崩塌：IconBox 事件

如果说代码更新变慢还可以解释为“功能稳定”，那么基础设施的故障则是项目被放弃的直接证据。

• IconBox 无法发布：Issue #3092 指出 “IconBox 无法发布包了”。IconBox 是 Arco 生态中用于管理和分发自定义图标的 SaaS 服务。这类服务需要后端服务器、数据库以及运维支持。


• 含义解读：当一个大厂开源项目的配套 SaaS 服务出现故障且无人修复时，这不仅仅是开发人员没时间的问题，而是意味着服务器的预算可能已经被切断，或者负责运维该服务的团队（GIP 相关的基建团队）已经被解散。这是项目“断供”的最强物理证据。

3.3 文档站点的维护降级

Arco Design 的文档站点虽然目前仍可访问，但其内容更新已经明显滞后。例如，关于 React 18/19 的并发特性支持、最新的 SSR 实践指南等现代前端话题，在文档中鲜有提及。与竞争对手 Ant Design 紧跟 React 官方版本发布的节奏相比，Arco 的文档显得停留在 2022 年的时光胶囊中。

4. 深层归因：组织架构变革下的牺牲品

Arco Design 的陨落，本质上不是技术失败，而是组织架构变革的牺牲品。要理解这一点，我们需要将视线从 GitHub 移向字节跳动的办公大楼，审视这家巨头在过去三年中发生的剧烈动荡。

4.1 “去肥增瘦”战略与 GIP 的解体

2022 年至 2024 年，字节跳动 CEO 梁汝波多次强调“去肥增瘦”战略，旨在削减低效业务，聚焦核心增长点。这一战略直接冲击了 Arco Design 的母体——GIP 部门。

4.1.1 战略投资部的解散与业务收缩

2022 年初，字节跳动解散了战略投资部，并将原有的投资业务线员工分流。这一动作标志着公司从无边界扩张转向防御性收缩。紧接着，教育（大力教育）、游戏（朝夕光年）以及各类边缘化的国际化尝试业务（GIP 的核心腹地）遭遇了毁灭性的裁员。

4.1.2 GIP 团队的消失

在多轮裁员中，GIP 及其相关的商业化技术团队是重灾区。

• 人员流失：Arco Design 的核心维护者作为 GIP UED 和架构前端的一员，极有可能在这些轮次的“组织优化”中离职，或者被转岗到核心业务（如抖音电商、AI 模型 Doubao）以保住职位。


• 业务目标转移：留下来的人员也面临着 KPI 的重置。当业务线都在为生存而战，或者全力以赴投入 AI 军备竞赛时，维护一个无法直接带来营收的开源 UI 库，显然不再是绩效考核中的加分项，甚至是负担。

4.2 内部赛马机制：Arco Design vs. Semi Design

字节跳动素以“APP 工厂”和“内部赛马”文化著称。这种文化不仅存在于 C 端产品中，也渗透到了技术基建领域。Arco Design 的停摆，很大程度上是因为它在与内部竞争对手 Semi Design 的博弈中败下阵来。

4.2.1 Semi Design 的崛起

Semi Design 是由 抖音前端团队 与 MED 产品设计团队 联合推出的设计系统。

• 出身显赫：与 GIP 这个边缘化的“探索型”部门不同，Semi Design 背靠的是字节跳动的“现金牛”——抖音。抖音前端团队拥有极其充裕的资源和稳固的业务地位。


• 业务渗透率：Semi Design 官方宣称支持了公司内部“近千个平台产品”，服务 10 万+ 用户。它深度嵌入在抖音的内容生产、审核、运营后台中。这些业务是字节跳动的生命线，因此 Semi Design 被视为“核心资产”。

4.2.2 为什么 Arco 输了？

在资源收缩期，公司高层显然不需要维护两套功能高度重叠的企业级 UI 库。选择保留哪一个，不仅看技术优劣，更看业务绑定深度。

• 技术路线之争：Semi Design 在 D2C（Design-to-Code）领域走得更远，提供了强大的 Figma 插件，能直接将设计稿转为 React 代码。这种极其强调效率的工具链，更符合字节跳动“大力出奇迹”的工程文化。


• 归属权：Arco 属于 GIP，GIP 被裁撤或缩编；Semi 属于抖音，抖音如日中天。这几乎是一场没有悬念的战役。当 GIP 团队分崩离析，Arco 自然就成了没人认领的“孤儿”。

4.3 中国大厂的“KPI 开源”陷阱

Arco Design 的命运也折射出中国互联网大厂普遍存在的“KPI 开源”现象。

• 晋升阶梯：在阿里的 P7/P8 或字节的 2-2/3-1 晋升答辩中，主导一个“行业领先”的开源项目是极具说服力的业绩。因此，很多工程师或团队 Leader 会发起此类项目，投入巨大资源进行推广（刷 Star、做精美官网）。


• 晋升后的遗弃：一旦发起人成功晋升、转岗或离职，该项目的“剩余价值”就被榨干了。接手的新人往往不愿意维护“前人的功劳簿”，更愿意另起炉灶做一个新的项目来证明自己。


• Arco 的轨迹：Arco 的高调发布（2021年）恰逢互联网泡沫顶峰。随着 2022-2024 年行业进入寒冬，晋升通道收窄，维护开源项目的 ROI（投入产出比）变得极低，导致项目被遗弃。

5. 社区自救的幻象：为何没有强有力的 Fork？

面对官方的停摆，用户自然会问：既然代码是开源的（MIT 协议），为什么没有人 Fork 出来继续维护？调查显示，虽然存在一些零星的 Fork，但并未形成气候。

5.1 Fork 的现状调查

通过对 GitHub 和 Gitee 的检索，我们发现了一些 Fork 版本，但并未找到具备生产力的社区继任者。

• vrx-arco：这是一个名为 vrx-arco/arco-design-pro 的仓库，声称是 "aro-design-vue 的部分功能扩展"。然而，这更像是一个补丁集，而不是一个完整的 Fork。它主要解决特定开发者的个人需求，缺乏长期维护的路线图。


• imoty_studio/arco-design-designer：这是一个基于 Arco 的表单设计器，并非组件库本身的 Fork。


• 被动 Fork：GitHub 显示 Arco Design 有 713 个 Fork。经抽样检查，绝大多数是开发者为了阅读源码或修复单一 Bug 而进行的“快照式 Fork”，并没有持续的代码提交。

5.2 为什么难以 Fork？

维护一个像 Arco Design 这样的大型组件库，其门槛远超普通开发者的想象。

因此，社区更倾向于迁移，而不是接盘。

6. 用户生存指南：现状评估与迁移策略

对于目前仍在使用 Arco Design 的团队，局势十分严峻。随着 React 19 的临近和 Vue 3 生态的演进，Arco 将面临越来越多的兼容性问题。

6.1 风险评估表

6.2 迁移路径推荐

方案 A：迁移至 Semi Design（推荐指数：⭐⭐⭐⭐）

如果你是因为喜欢字节系的设计风格而选择 Arco，那么 Semi Design 是最自然的替代者。

• 优势：同为字节出品，设计语言的命名规范和逻辑有相似之处。Semi 目前维护活跃，背靠抖音，拥有强大的 D2C 工具链。


• 劣势：API 并非 100% 兼容，仍需重构大量代码。且 Semi 主要是 React 优先，Vue 生态支持相对较弱（主要靠社区适配）。

方案 B：迁移至 Ant Design v5/v6（推荐指数：⭐⭐⭐⭐⭐）

如果你追求极致的稳定和长期的维护保障，Ant Design 是不二之选。

• 优势：行业标准，庞大的社区，Ant Gr0up 背书。v5 版本引入了 CSS-in-JS，在定制能力上已经大幅追赶 Arco 的 Design Lab。


• 劣势：设计风格偏保守，需要设计师重新调整 UI 规范。

方案 C：本地魔改（推荐指数：⭐）

如果项目庞大无法迁移，唯一的出路是将 @arco-design/web-react 源码下载到本地 packages 目录，作为私有组件库维护。

• 策略：放弃官方更新，仅修复阻塞性 Bug。这需要团队内有资深的前端架构师能够理解 Arco 的源码。

7. 结语与启示

Arco Design 的故事是现代软件工程史上的一个典型悲剧。它证明了在企业级开源领域，康威定律（Conway's Law） 依然是铁律——软件的架构和命运取决于开发它的组织架构。

当 GIP 部门意气风发时，Arco 是那颗最耀眼的星，承载着“务实浪漫主义”的理想；当组织收缩、业务调整时，它便成了由于缺乏商业造血能力而被迅速遗弃的资产。对于技术决策者而言，Arco Design 的教训是惨痛的：在进行技术选型时，不能仅看 README 上的 Star 数或官网的精美程度，更要审视项目背后的组织生命力和维护动机。

目前来看，Arco Design 并没有复活的迹象，社区也没有出现强有力的接棒者。这套组件库正在数字化浪潮的沙滩上，慢慢风化成一座无人问津的丰碑。

为啥以前 IE 老“崩溃”，而现在开一堆标签页的 Chrome 还能比较稳？答案都藏在浏览器的「进程模型」里。

作为一个还在学习前端的同学，我经常听到几个关键词：

进程、线程、多进程浏览器、渲染进程、V8、事件循环……

下面就是我目前的理解，算是一篇学习笔记式的分享

一、先把概念捋清：进程 vs 线程

• 进程（Process）
  
  
  
  
  • 操作系统分配资源的最小单位。
  
  
  • 拥有独立的内存空间、句柄、文件等资源。
  
  
  • 不同进程间默认互相隔离，通信要通过 IPC。
  
  
  
  


• 线程（Thread）
  
  
  
  
  • CPU 调度、执行代码的最小单位。
  
  
  • 共享所属进程的资源（内存、文件句柄等）。
  
  
  • 一个进程里可以有多个线程并发执行。
  
  
  
  

简单理解：

• 进程 = 一个“应用实例” （开一个浏览器窗口就是一个进程）。


• 线程 = 应用里的很多“小工人” （一个负责渲染页面，一个负责网络请求……）。

二、单进程浏览器：旧时代的 IE 模型

早期的浏览器（如旧版 IE）基本都是单进程架构：整个浏览器只有一个进程，里面开多个线程来干活。

可以想象成这样一张图（对应你给的“单进程浏览器”那张图）：

• 顶部是「代码 / 数据 / 文件」等资源。


• 下面有多个线程：
  
  
  
  
  • 页面线程：负责页面渲染、布局、绘制。
  
  
  • 网络线程：负责网络请求。
  
  
  • 其他线程：例如插件、定时任务等。
  
  
  
  


• 所有线程共享同一份进程资源。

在这个模型下：

• 页面渲染、JavaScript 执行、插件运行，都挤在同一个进程里。


• 某个插件或脚本一旦崩溃、死循环、内存泄漏，整个浏览器都会被拖垮。


• 多开几个标签页，本质上依旧是同一个进程里的不同页面线程， “一荣俱荣，一损俱损” 。

这也是很多人对 IE 的经典印象：

“多开几个页面就卡死，崩一次，所有标签页一起消失”。

三、多进程浏览器：Chrome 的现代架构

Chrome 采用的是多进程、多线程混合架构。打开浏览器时，大致会涉及这些进程：

• 浏览器主进程（Browser Process）
  
  
  
  
  • 负责浏览器 UI、地址栏、书签、前进后退等。
  
  
  • 管理和调度其他子进程（类似一个大管家）。
  
  
  • 负责部分存储、权限管理等。
  
  
  
  


• 渲染进程（Render Process）
  
  
  
  
  • 核心任务：把 HTML / CSS / JavaScript 变成用户可以交互的页面。
  
  
  • 布局引擎（如 Blink）和 JS 引擎（如 V8）都在这里。
  
  
  • 默认情况下，每个标签页会对应一个独立的渲染进程。
  
  
  
  


• GPU 进程（GPU Process）
  
  
  
  
  • 负责 2D / 3D 绘制和加速（动画、3D 变换等）。
  
  
  • 统一为浏览器和各渲染进程提供 GPU 服务。
  
  
  
  


• 网络进程（Network Process）
  
  
  
  
  • 负责资源下载、网络请求、缓存等。
  
  
  
  


• 插件进程（Plugin Process）
  
  
  
  
  • 负责运行如 Flash、扩展等插件代码，通常放在更严格的沙箱里。
  
  
  
  

你给的第一张图，其实就是这么一个多进程架构示意图：中间是主进程，两侧是渲染、网络、GPU、插件等子进程，有的被沙箱保护。

四、单进程 vs 多进程：核心差异一览（表格对比）

下面这张表，把旧式单进程浏览器和现代多进程浏览器的差异总结出来，适合在文章中重点展示：

五、别被“多进程”骗了：JS 依然是单线程

聊到这里，很多同学容易混淆一个点：

浏览器是多进程的，那 JavaScript 是不是也多线程并行执行了？

答案是否定的：主线程上的 JavaScript 依然是单线程模型。区别在于：

• 在渲染进程内部，有一个主线程负责：
  
  
  
  
  • 执行 JavaScript。
  
  
  • 页面布局、绘制。
  
  
  • 处理用户交互（点击、输入等）。
  
  
  
  


• JS 代码仍然遵循：同步任务立即执行，异步任务丢进任务队列，由事件循环（Event Loop）调度。

为什么要坚持单线程？

• DOM 是单线程模型，多个线程同时改 DOM，锁会非常复杂。


• 前端开发心智成本可控；不必像多线程语言那样到处考虑锁和竞态条件。

多进程架构只是把：

• “这个页面的主线程 + 渲染 + JS 引擎”
  
  放在一个单独的进程里（渲染进程）。

这也是为什么：

• 一个页面 JS 写了死循环，会卡死那一个标签页。


• 但其他标签页通常还能正常使用，因为它们在完全不同的渲染进程内。

六、从架构看体验：为什么我们更喜欢现在的浏览器？

站在前端开发者角度，多进程架构带来的直接收益有：

• 更好的容错性


• 更高的安全等级


• 更顺滑的交互体验


• 更容易工程化演进

当然，代价也很现实：多进程 = 更高的内存占用。这也是为什么：

• 多开几十个标签，任务管理器里能看到很多浏览器相关进程。


• 但换来的是更好的稳定性、安全性和扩展性——在现代硬件下，这是可以接受的 trade-off。

七、总结

• 早期浏览器采用单进程 + 多线程模式，所有页面、脚本、插件都在同一个进程里，一旦出问题就“全军覆没”。


• 现代浏览器（代表是 Chrome）使用多进程架构：主进程负责调度，各个渲染、网络、GPU、插件进程各司其职，并通过沙箱强化隔离。


• 尽管浏览器整体是多进程的，但单个页面里的 JavaScript 依然是单线程 + 事件循环模型，这点没有变。


• 从用户体验、前端开发、安全性、稳定性来看，多进程架构几乎是全面碾压旧时代单进程浏览器的一次升级。

传统方案

1. Object.prototype.toString.call 方法

原理：通过调用 Object.prototype.toString.call(obj) ，判断返回值是否为  [object Array] 。

function isArray(obj){

  return Object.prototype.toString.call(obj) === '[object Array]';

}

 
缺陷：

• ES6 引入 Symbol.toStringTag 后，可被人为篡改。例如：
  
  

  const obj = {
  
    [Symbol.toStringTag]: 'Array'
  
  };
  
  console.log(Object.prototype.toString.call(obj)); // 输出 [object Array]
  
  

  
  


• 若开发通用型代码（如框架、库），该漏洞会导致判断失效。

2. instanceof 方法

原理：判断对象原型链上是否存在 Array 构造函数。

function isArray(obj){

  return obj instanceof Array;

}

缺陷：

• 可通过 Object.setPrototypeOf 篡改原型链，导致误判。例如：
  
  

  const obj = {};
  
  Object.setPrototypeOf(obj, Array.prototype);
  
  console.log(obj instanceof Array); // 输出 true，但 obj 并非真正数组
  
  

  
  


• 跨 iframe 场景失效。不同 iframe 中的 Array 构造函数不共享，导致真数组被误判为非数组。例如：
  
  

  const frame = document.querySelector('iframe');
  
  const Array2 = frame.contentWindow.Array;
  
  const arr = new Array2();
  
  console.log(arr instanceof Array); // 输出 false，但 arr 是真正数组
  
  

  
  

ES6 原生方法

方法：使用 Array.isArray 静态方法。

console.log(Array.isArray(arr));

 
优势：

• 该方法由JavaScript引擎内部实现，直接判断对象是否由 Array 构造函数创建，不受原型链、 Symbol.toStringTag  或跨 iframe 影响；


• 完美解决所有边界场景。

总结

判断数组的方法中 Array.isArray 是唯一准确且无缺陷的方案。其他方法（如Object.prototype.toString.call、instanceof）均存在局限性，仅在特定场景下可用。

几年前，公司老板、产品经理，甚至隔壁行政的同事，都拿着一份花里胡哨的低代码方案，眼睛放光地跟你说：“小张啊，你来看看，未来！拖拉拽就能上线，咱们再也不用养那么多程序员了！”

我当时啥心情？表面上“嗯嗯嗯，是是是，很有前景”，心里一万头羊驼在奔腾。你懂个锤子啊，我一直认为它是解决了一类问题，引入了一大堆的复杂。

这玩意儿的核心是啥？说白了，就是想用一套“万能模板”去解决所有问题。听着是挺美，但咱都是写代码的，你心里清楚，软件开发最难的，从来不是那几行CRUD，而是那些“该死”的个性化业务逻辑。认同？！

低代码，本质上就是把这些逻辑，从代码文件里，挪到了一堆图形化的配置框里。你以为是解放了生产力？扯淡。你只是换了个地方“坐牢”。

从“卧槽，牛逼”到“卧槽，什么玩意儿”

AI写代码一段时间，比如Cursor、Claude Code、codex这些，我当时的第一反应是：“卧-槽，牛-逼！”

你跟它说：“帮我写个用户登录接口，用JWT，密码要bcrypt加密，加上参数校验。”

唰一下，代码出来了。连注释都给你写得明明白白。那一瞬间，真有种未来已来的感觉。

这不就是低代码想干但没干成的事儿吗？

低代码是给你一堆乐高积木，说：“来，你自己拼个宇宙飞船。” 你吭哧吭哧拼了半天，发现给你的零件根本就不够，而且拼出来的玩意儿四不像，还飞不起来。

AI原生开发是啥？你直接跟管家说：“多啦 A 梦，给我造个能飞的玩意儿，要快，要帅。” 贾维斯直接给你把图纸、零件、引擎全整出来了。你只需要当那个总设计师，告诉它你的“意图”，然后去检查、微调。

你品，你细品。一个让你当“拼装工”，一个让你当“设计师”。格局一样吗？

我为啥突然这么大感触？老黄-全栈工程师，前阵子接了个项目，有个模块特别急。按老路子，前端画页面、后端写接口、联调... 怎么也得一周吧？

他说他用Claude Code，把需求拆成几个点，啪啪啪跟AI对话。
“给我个Vue3+TS的表格页，能分页，能搜索，数据接口是/api/users”
“后端用Go写这个接口，连PostgreSQL，把分页逻辑做了。”
“加个逻辑，角色是admin才能看到删除按钮。”

一下午，真的，就一个下午，他说，一个带前后端的完整功能雏形就出来了。代码质量还不低，结构清晰，拿过来改改就能用。

而用低代码呢？他说他可能还在研究那个破平台的“数据源”到底该怎么连，或者某个组件的某个奇葩属性到底藏在哪个配置项里。那种抓狂，谁用谁知道。

我想，老黄的这种感觉你肯定有过，如果可以选择，你会选择用地代码去拖拉拽吗？我想大概率你是不会了，回不去了。

别跟我扯什么“AI搞不定复杂逻辑”

我知道，肯定有人会跳出来说：“哥们，你这是偷换概念！简单的CRUD当然AI快，你让AI搞个复杂的风控引擎试试？”

每次听到这话，我就想笑。

兄弟，你是不是忘了我们现代软件架构的核心思想是啥了？高内聚、低耦合！

一个复杂的系统，不就是一堆简单的、正交的子系统组合起来的吗？你告诉我，哪个“复杂业务逻辑”是不能拆解的？如果不能，那不是AI的问题，是你的架构设计有问题。

领域驱动设计（DDD）讲了这么多年，不就是为了把业务模型理清楚，把边界划分明白吗？

在AI原生时代，架构师的核心能力，不再是堆砌代码，而是精准地拆解问题，然后把拆解后的子问题清晰地描述给AI。

低代码平台最大的死穴就在这儿。它试图用一个大而全的“黑箱”包办一切，结果就是耦合度极高。你想改其中一根“毛细血管”，可能得把整个“心脏”都停了。这种系统，业务稍微一变，就得推倒重来，维护成本高到让你怀疑人生。我亲眼见过一个团队，被他们选的低代码平台折磨得死去活-来，最后整个项目烂尾。

AI生成的代码呢？那是“白箱”。清清楚楚的源代码，你想怎么改就怎么改，想怎么扩展就怎么扩展。这才是咱们工程师该有的掌控感！

所以，有人焦虑了？

聊到这，估计有些年轻的哥们儿开始焦虑了：“老哥，照你这么说，以后是不是不用写代码了？我们都要被AI干掉了？”

我说：慌啥。

AI不是来取代你的，是来升级你的工具箱的。，取带你的是那些用 AI 比你用得更深，更好的人。人家都开车了，你还走路，你搁那怪谁呢？

低代码，是想把你变成一个“组件配置工程师”，说实话，这玩意儿真没啥技术含量，他无非就是把一些固化的规则和业务组件放在了一个系统中，让你去组合，去连接，也确实容易被替代。

但AI原生开发，对人的要求，其实是更高了。

你需要有更强的架构能力，去拆解复杂问题。
你需要有更强的业务理解能力，去把需求转化成清晰的指令。
你需要有更强的代码审美，去判断AI生成的代码是“精品”还是“垃圾”。

说白了，AI帮你干了那些重复、枯燥的体力活，让你能把全部精力，都放在 “思考” 这个最有价值的事情上。

写在最后，一点不成熟的牢骚

我也不知道这股风会刮多久，技术这玩意儿，日新月异。今天你觉得牛逼的东西，明天可能就是一堆垃圾。

AI 原生开发，它不是一个工具的改变，更像是一种“思维范式”的革命。它在逼着我们从“如何实现”的工匠思维，转向“做什么、为什么做”的创造者思维。

低代码的时代，可能还没开始，就已经结束了。它只是一个过渡期的妥协品，一个想走捷径但最终掉进坑里的解决方案。

至于未来会怎么样？我也不知道。可能我们以后写的不是代码，而是“提示词”；面试考的不是算法，而是你跟AI“对话”的能力。

谁说得准呢？

反正我是已经把主力开发工具换成cursor、Claude Code、codex 这些了。一边写，一边让AI帮我优化，或者干脆让它写大段的模板代码，这感觉，真挺爽的。

当然，这都是我个人的一点看法，不一定对，欢迎来杠。评论区聊聊？