近日在使用小米AI大模型MIMO时，被其顶部的透视跟随动画深深吸引，移步官网（ mimo.xiaomi.com/zh/ ）

效果演示

1. 交互梳理

现在基于这个交互的拆解，逐步来复刻交互效果

2. 组件结构与DOM设计

2.1 模板结构

采用「静态底层+动态上层」的双层视觉结构，通过CSS绝对定位实现图层叠加，既保证初始状态的视觉完整性，又能让交互效果精准作用于上层，不干扰底层基础展示。两层分工明确，具体如下：

2.2 核心 DOM 结构

<div class="container" @mouseenter="onMouseEnter" @mouseleave="onMouseLeave" @mousemove="onMouseMove">

  <!-- 底层内容 -->

  <div class="z-1">

    <div class="line" v-for="line in 13">

      <span class="line-item" v-for="item in 13">HELLO</span>

    </div>

  </div>

  <h1 class="title-1">你好，世界！</h1>

  

  <!-- 上层交互内容 -->

  <div class="z-2" :style="{ 'clip-path': circleClipPath }">

    <div class="hidden-div">

      <div class="line" v-for="line in 13">

        <span class="line-item" v-for="item in 13">HELLO</span>

      </div>

    </div>

    <h1 class="title-2">Hello , World!</h1>

  </div>

</div>

关键说明：hidden-div用于包裹上层文字矩阵，配合.z-2的定位规则，确保遮罩效果精准覆盖；两层文字矩阵尺寸一致，保证视觉对齐，增强透视沉浸感。

3. 技术实现

3.1 核心功能模块

3.1.1 轨迹点系统

轨迹点系统是实现平滑鼠标跟随效果的核心，通过维护6个轨迹点的位置信息，创建出具有弹性延迟的跟随动画。

// 轨迹点系统 

const trailSystem = ref({

  targetX: 0,

  targetY: 0,

  trailPoints: Array(6).fill(null).map(() => ({ x: 0, y: 0 })),

  animationId: 0,

  isInside: false

});

设计思路：6个轨迹点是兼顾流畅度与性能的平衡值——点太少则拖尾效果不明显，点太多则增加计算开销，配合递减阻尼系数，实现“头快尾慢”的自然跟随。

3.1.2 动态 Clip-Path 计算

通过计算鼠标位置和轨迹点的关系，动态生成 clip-path CSS 属性值，实现跟随鼠标的圆形/椭圆形遮罩效果。

// 计算clip-path值

const circleClipPath = computed(() => {

  if (!showCircle.value) {

    return 'circle(0px at -300px -300px)'; // 完全隐藏状态

  }



  // 复制轨迹系统数据进行计算

  const system = JSON.parse(JSON.stringify(trailSystem.value));

  

  // 更新轨迹点

  for (let t = 0; t < 6; t++) {

    const prevX = t === 0 ? system.targetX : system.trailPoints[t - 1].x;

    const prevY = t === 0 ? system.targetY : system.trailPoints[t - 1].y;

    const damping = 0.7 - 0.04 * t; // 阻尼系数，后面的点移动更慢

    

    const deltaX = prevX - system.trailPoints[t].x;

    const deltaY = prevY - system.trailPoints[t].y;

    

    // 平滑插值

    system.trailPoints[t].x += deltaX * damping;

    system.trailPoints[t].y += deltaY * damping;

  }

  

  // 获取第一个点（头部）和最后一个点（尾部）

  const head = system.trailPoints[0];

  const tail = system.trailPoints[5];

  

  const diffX = head.x - tail.x;

  const diffY = head.y - tail.y;

  const distance = Math.sqrt(diffX * diffX + diffY * diffY);

  

  let clipPathValue = '';

  

  if (distance < 10) { // 如果距离很近，显示圆形

    clipPathValue = `circle(200px at ${head.x}px ${head.y}px)`;

  } else {

    // 创建椭圆形的polygon，连接头尾两点

    const angle = Math.atan2(diffY, diffX); // 连接角度

    const points = [];

    

    // 从头部开始，画半个椭圆

    for (let i = 0; i <= 30; i++) {

      const theta = angle - Math.PI / 2 + Math.PI * i / 30;

      const x = head.x + 200 * Math.cos(theta);

      const y = head.y + 200 * Math.sin(theta);

      points.push(`${x}px ${y}px`);

    }

    

    // 从尾部开始，画另半个椭圆

    for (let i = 0; i <= 30; i++) {

      const theta = angle + Math.PI / 2 + Math.PI * i / 30;

      const x = tail.x + 200 * Math.cos(theta);

      const y = tail.y + 200 * Math.sin(theta);

      points.push(`${x}px ${y}px`);

    }

    

    clipPathValue = `polygon(${points.join(', ')})`;

  }

  

  return clipPathValue;

});

3.1.3 鼠标事件处理

实现了完整的鼠标交互逻辑，包括鼠标进入、离开和移动时的状态管理和动画控制。

4. 技术亮点

4.1 轨迹点系统算法

核心原理：使用6个轨迹点，每个点跟随前一个点移动，并应用不同的阻尼系数，实现平滑的拖尾效果。

技术优势：

• 实现了自然的物理运动效果，比简单的线性跟随更具视觉吸引力


• 通过阻尼系数的递减，创建出层次感和深度感


• 算法复杂度低，性能消耗小，适合实时交互场景

4.2 动态 Clip-Path 技术

核心原理：利用CSS clip-path属性的动态特性，结合轨迹点位置计算，实时生成不规则遮罩，替代Canvas/SVG的图形绘制方案，用更轻量化的方式实现复杂视觉效果。

技术优势：

• 无依赖轻量化：无需引入任何图形库，纯CSS+JS即可实现，减少项目依赖体积，降低集成成本


• 平滑过渡无卡顿：通过数值插值计算，实现圆形与椭圆形遮罩的无缝切换，无帧断裂感，视觉连贯性强


• 渲染性能优化：配合 will-change: clip-path 提示浏览器，提前分配渲染资源，减少重排重绘，提升动画流畅度

5. 性能优化

6. 总结与扩展

本次复刻的小米MiMo透视动画，核心价值在于“用简单技术组合实现高级视觉效果”——无需复杂图形库，仅依托Vue3响应式能力与CSS clip-path属性，就能打造出兼具质感与性能的交互组件。其核心亮点可概括为三点：

• 交互创新：轨迹点系统与动态clip-path结合，打破传统静态标题的交互边界，带来自然流畅的鼠标跟随体验


• 视觉精致：双层文字矩阵的分层设计，配合遮罩形变，营造出兼具深度感与品牌性的视觉效果


• 性能可控：轻量化技术方案+多维度优化策略，在保证视觉效果的同时，兼顾页面性能与可维护性

扩展方向

该组件的实现思路可灵活迁移至其他场景：

• 弹窗过渡动画：将clip-path遮罩用于弹窗进入/退出效果，实现不规则形状的过渡动画。


• 滚动动效：结合滚动事件替换鼠标事件，实现页面滚动时的元素透视跟随效果。


• 移动端适配：增加触摸事件支持，将鼠标交互替换为触摸滑动，适配移动端场景。

完整代码

<template>

  <div class="hero-container" @mouseenter="onMouseEnter" @mouseleave="onMouseLeave" @mousemove="onMouseMove">

    <div class="z-1">

      <div class="line" v-for="line in 13">

        <span class="line-item" v-for="item in 13">HELLO</span>

      </div>

    </div>

    <h1 class="title-1">你好，世界</h1>



    <!-- 第二个div，鼠标移入后需要显示的内容，通过clip-path:circle(0px at -300px -300px)达到隐藏效果 -->

    <div class="z-2" :style="{ 'clip-path': circleClipPath }">

      <div class="hidden-div">

        <div class="line" v-for="line in 13">

          <span class="line-item" v-for="item in 13">HELLO</span>

        </div>

      </div>

      <h1 class="title-2">HELLO , World</h1>

    </div>

  </div>

</template>



<script setup>

import { ref, computed, onMounted, onUnmounted } from 'vue'



const showCircle = ref(false)

const containerRef = ref(null)



const trailSystem = ref({

  targetX: 0,

  targetY: 0,

  trailPoints: Array(6)

    .fill(null)

    .map(() => ({ x: 0, y: 0 })),

  animationId: 0,

  isInside: false,

})



const circleClipPath = computed(() => {

  if (!showCircle.value) {

    return 'circle(0px at -300px -300px)'

  }



  // 复制轨迹系统数据进行计算

  const system = JSON.parse(JSON.stringify(trailSystem.value))



  // 更新轨迹点

  for (let t = 0; t < 6; t++) {

    const prevX = t === 0 ? system.targetX : system.trailPoints[t - 1].x

    const prevY = t === 0 ? system.targetY : system.trailPoints[t - 1].y

    const damping = 0.7 - 0.04 * t // 阻尼系数，后面的点移动更慢



    const deltaX = prevX - system.trailPoints[t].x

    const deltaY = prevY - system.trailPoints[t].y



    // 平滑插值

    system.trailPoints[t].x += deltaX * damping

    system.trailPoints[t].y += deltaY * damping

  }



  // 获取第一个点（头部）和最后一个点（尾部）

  const head = system.trailPoints[0]

  const tail = system.trailPoints[5]



  const diffX = head.x - tail.x

  const diffY = head.y - tail.y

  const distance = Math.sqrt(diffX * diffX + diffY * diffY)



  let clipPathValue = ''



  if (distance < 10) {

    // 如果距离很近，显示圆形

    clipPathValue = `circle(200px at ${head.x}px ${head.y}px)`

  } else {

    // 创建椭圆形的polygon，连接头尾两点

    const angle = Math.atan2(diffY, diffX) // 连接角度

    const points = []



    // 从头部开始，画半个椭圆

    for (let i = 0; i <= 30; i++) {

      const theta = angle - Math.PI / 2 + (Math.PI * i) / 30

      const x = head.x + 200 * Math.cos(theta)

      const y = head.y + 200 * Math.sin(theta)

      points.push(`${x}px ${y}px`)

    }



    // 从尾部开始，画另半个椭圆

    for (let i = 0; i <= 30; i++) {

      const theta = angle + Math.PI / 2 + (Math.PI * i) / 30

      const x = tail.x + 200 * Math.cos(theta)

      const y = tail.y + 200 * Math.sin(theta)

      points.push(`${x}px ${y}px`)

    }



    clipPathValue = `polygon(${points.join(', ')})`

  }



  return clipPathValue

})



// 动画循环函数

const animate = () => {

  if (showCircle.value) {

    // 更新轨迹点

    for (let t = 0; t < 6; t++) {

      const prevX = t === 0 ? trailSystem.value.targetX : trailSystem.value.trailPoints[t - 1].x

      const prevY = t === 0 ? trailSystem.value.targetY : trailSystem.value.trailPoints[t - 1].y

      const damping = 0.7 - 0.04 * t // 阻尼系数，后面的点移动更慢



      const deltaX = prevX - trailSystem.value.trailPoints[t].x

      const deltaY = prevY - trailSystem.value.trailPoints[t].y



      // 平滑插值

      trailSystem.value.trailPoints[t].x += deltaX * damping

      trailSystem.value.trailPoints[t].y += deltaY * damping

    }



    // 请求下一帧

    trailSystem.value.animationId = requestAnimationFrame(animate)

  }

}



const onMouseEnter = (event) => {

  const container = event.currentTarget

  const rect = container.getBoundingClientRect()

  const x = event.clientX - rect.left

  const y = event.clientY - rect.top



  showCircle.value = true



  // 初始化目标位置和轨迹点

  trailSystem.value.targetX = x

  trailSystem.value.targetY = y

  trailSystem.value.isInside = true



  // 初始化所有轨迹点到当前位置

  for (let i = 0; i < 6; i++) {

    trailSystem.value.trailPoints[i] = { x, y }

  }



  // 开始动画

  if (!trailSystem.value.animationId) {

    trailSystem.value.animationId = requestAnimationFrame(animate)

  }

}



const onMouseLeave = (event) => {

  const container = event.currentTarget

  const rect = container.getBoundingClientRect()

  const x = event.clientX - rect.left

  const y = event.clientY - rect.top



  showCircle.value = false

  trailSystem.value.isInside = false



  // 将目标点移出容器边界，使轨迹点逐渐拉回

  let targetX = x

  let targetY = y



  if (x <= 0) targetX = -400

  else if (x >= rect.width) targetX = rect.width + 400



  if (y <= 0) targetY = -400

  else if (y >= rect.height) targetY = rect.height + 400



  trailSystem.value.targetX = targetX

  trailSystem.value.targetY = targetY



  // 停止动画

  if (trailSystem.value.animationId) {

    cancelAnimationFrame(trailSystem.value.animationId)

    trailSystem.value.animationId = 0

  }

}



const onMouseMove = (event) => {

  if (showCircle.value) {

    const container = event.currentTarget

    const rect = container.getBoundingClientRect()

    const x = event.clientX - rect.left

    const y = event.clientY - rect.top



    trailSystem.value.targetX = x

    trailSystem.value.targetY = y

  }

}

</script>



<style scoped>

.hero-container {

  cursor: crosshair;

  background: #faf7f5;

  border-bottom: 1px solid #000;

  justify-content: center;

  align-items: center;

  width: 100%;

  height: 500px;

  display: flex;

  position: relative;

  overflow: hidden;

}



.z-1 {

  pointer-events: auto;

  -webkit-user-select: none;

  user-select: none;

  flex-direction: column;

  justify-content: flex-start;

  width: 100%;

  height: 100%;

  display: flex;

  position: absolute;

  top: 0;

  left: 0;

  overflow: hidden;

}



.z-1 .line {

  display: flex;

  align-items: center;

  white-space: nowrap;

  color: #0000000d;

  letter-spacing: 0.3em;

  flex-wrap: nowrap;

  font-size: 52px;

  font-weight: 700;

  line-height: 1.6;

  display: flex;

}



.z-1 .line-item {

  cursor: default;

  flex-shrink: 0;

  margin-right: 0.6em;

  transition:

    color 0.3s,

    text-shadow 0.3s;

  font-family: inherit !important;

}



.z-1 .line:nth-child(odd) {

  margin-left: -2em;

  background-color: rgb(245, 235, 228);

}



.title-1 {

  z-index: 1;

  color: #000;

  letter-spacing: 0.02em;

  text-align: center;

  margin: 0;

  font-size: 72px;

  font-weight: 700;

}



.z-2 {

  pointer-events: none;

  z-index: 10;

  will-change: clip-path;

  background: #000;

  justify-content: center;

  align-items: center;

  width: 100%;

  height: 100%;

  display: flex;

  position: absolute;

  top: 0;

  left: 0;

}



.z-2 .hidden-div {

  pointer-events: none;

  -webkit-user-select: none;

  user-select: none;

  flex-direction: column;

  justify-content: flex-start;

  width: 100%;

  height: 100%;

  display: flex;

  position: absolute;

  top: 0;

  left: 0;

  overflow: hidden;

}



.z-2 .hidden-div .line {

  white-space: nowrap;

  color: #ffffff1f;

  letter-spacing: 0.3em;

  flex-wrap: nowrap;

  font-size: 32px;

  font-weight: 700;

  line-height: 1.6;

  display: flex;

}



.z-2 .hidden-div .line:nth-child(odd) {

  margin-left: -0.5em;

}



.title-2 {

  font-size: 72px;

  color: #fff;

  letter-spacing: 0.02em;

  text-align: center;

  white-space: nowrap;

  margin: 0;

  font-size: 72px;

  font-weight: 700;

}

</style>

小米的前端一直很牛，非常有创意，我也通过F12学习源码体会到了新的思路，希望大家也多多关注小米和小米的技术～

Tailwind CSS的体量

Tailwind CSS有多火爆呢？

几组数据告诉你？

一组数据告诉你 Tailwind CSS 有多受欢迎：

1. github 86.1K的 Star, 足以证明它的受欢迎程度。
2. NPM 周下载量已突破 1000 万, 前端开发者的不二之选
3. 被无数大公司采用，如 GitHub、Vercel、Laravel 等。
4. 被很多框架和打包工具推荐，如Vite，Nuxt，React等

从数据上看，Tailwind CSS 已经成为前端开发的主流选择之一。

原子化CSS

什么是原子化CSS

原子化 CSS 是一种 CSS 架构，它提倡使用高度可复用的小类名，每个类名通常只控制单一的样式属性。例如：

<div class="text-red-500 font-bold p-4 text-[14px]">Hello Tailwinddiv>

其中：

• text-red-500: 代表文字颜色
• font-bold: 代表加粗
• p-4: 代表内边距
• text-[14px]: 代表字体大小为14px

这种方式避免了传统 CSS 中复杂的层叠规则，让样式控制更加直观。

原子化CSS和传统CSS的区别

说了这么一通，我相信用过的都说“真香”，用过一次后就离不开了。

关键是没用过的呢？是不是心里还在嘀咕。别急，正餐来了！

Tailwind CSS宝藏库

为什么说Tailwind CSS是一个宝藏，因为你担忧和抵触的地方，Tailwind CSS都给你解决了

类名难记

你可能在担忧，我是不是每次用都要查文档呢？那么多css好不容易记住了，现在又让我再学一遍？

答案是：不用。完全和你使用css一样简单。只需要记住几个关键字，智能提示帮你搞定

VS Code插件 - Tailwind CSS IntelliSense

HTML又长又乱

首先，不可否认，将所有的类名整合到html中，会让你的html变得比较长。但是，当你写的代码又长又乱的时候，你就要停下来想想

1. 是否违背了创作者的初衷
2. 架构是否设计不合理

为此，我们简单分析一下，到底是人的问题还是工具的问题。根据以上2点，分析一下你的HTML为什么又长又乱？

• 因为太长导致太乱

  没有合并之前，你的代码可能是这样的

  class="flex justify-center items-center">
  
      clsss="bg-blue-500 text-white py-2 px-4 rounded">提交
  
  
  
  

  合并后是这样的

  .flex-center {
  
    @apply flex justify-center items-center;
  
  }
  
  .btn-submit {
  
    @apply bg-blue-500 text-white py-2 px-4 rounded;
  
  }
  
  
  
  class="flex-center">
  
      clsss="btn-submit">提交
  
  
  
  

  现在是不是很清晰了呢？

  我敢说，只要你使用@apply合并类名，时刻记着复用样式，你的HMLT至少减少1/3，甚至也可以写出像诗一样的代码

• 因为没有分组和顺序性导致太乱

  没有顺序和分组的书写，是这样的

  <div class="p-2 font-bold text-[14px] mt-4 color-[#333333] bg-white">Hello world!div>
  
  

  想到哪写到哪，会让你的代码一眼望上去比较乱，时间长了，一眼看上去很难维护...

  下面我们就着手解决这2个问题

  1. 类排序

  使用 Prettier 进行类排序(Class sorting with Prettier)

  Tailwind CSS 维护了一个官方 Prettier 插件，它会自动按照我们的 推荐的类顺序 对你的类进行排序。

  使用插件后，代码这样的

  <div class="bg-white color-[#333333] mt-4 p-2 text-[14px] font-bold">Hello world!div>
  
  

  现在是不是清晰很多了呢？

  不过还不够

  2. 分组

我们根据样式进行的类别分组，比如颜色，字体，定位，间距等等，每个类别一行，这样你写出的代码会清晰无比

<div class="

    bg-white color-[#333333]

    mt-4 p-2

    text-[14px] font-bold">

Hello world!div>

现在代码是不是清晰的多了

全局类名

不用担心公共类的问题，@apply帮你搞定。

使用 @apply 合并类，前面已经讲过了，就不展开了

样式冲突

也许你还在担心tailwind 的 class 名和我已有的 class 冲突了咋办？我怎么处理兼容问题

别担心，给你的类名加个前缀prefix就搞定了

@import "tailwindcss" prefix(tw);



<div class="tw:flex tw:bg-red-500 tw:hover:bg-red-600"> div>

拥抱Tailwind CSS

Tailwind CSS为什么受到追捧

1. 再也不用忍受css上下切换的痛苦了
2. 再也不用花时间去取语义化类名了

   不用纠结container, wrapper, box等被使用的问题后，如何起名的问题了

3. 为了加权重，不断的加父级类名，甚至!important，永远不知道哪个样式起作用了。冗长的css让项目很难维护！
4. 简单完成伪类、伪元素、媒体查询等变体的书写

Tailwind CSS、PrimeFlex、UnoCSS评测

在CSS工具类框架中，除了Tailwind CSS之外，还有其他很多工具类。如PrimeFlex和UnoCSS，它们各有特点，下面我简单的评测一下

• PrimeFlex: 生态系统较小，多适用于Prime生态，如PrimevVue，PrimeReact。样式和较Tailwind CSS低。只能构建起简单样式框架。最让我吐槽的是，样式竟然用!important。你想替换某个属性，麻烦程度想骂人！

• UnoCSS: 未构建良好的生态系统，多用于自定义规则和项目优化

总结

TailwindCSS 已经成为前端开发的趋势之一，随着4.0 版本的发布，它的性能更强大、使用更方便。如果你还在抵触，不妨试试看，它可能会彻底改变你的 CSS 编写方式！

作者：高志小鹏鹏
来源：juejin.cn/post/7480734875723415552

最近刷 X 乎时看到这样一个耐人寻味的的讨论话题，浏览量超 170w，参与讨论的同学也好多。

问题描述是这样的：

“为什么没人走后门当程序员？”

我认真浏览了一圈，心里五味杂陈。

在许多人眼中，程序员是一个高薪的职业。然而，即便程序员们拿着如此令人羡慕的高薪，尽管互联网行业如此火热，但却几乎很少听说有人说走后门想进去。

其实这事情一点也不难理解，这得先从程序员工作的本质说起。

因为程序员这个职业，从根子上来说压根就不靠后门吃饭。

而且程序员这行，恰恰是最混不了日子的，它要求你持续学习，跟上技术迭代，解决一个个具体而棘手的问题。

编程是一个实实在在的技术活，当你的代码运行不起来，它就是运行不起来，你写的系统有漏洞，它就会在某个深夜悄然崩溃，这种刚性特质就决定了程序员这个岗位无法容忍滥竽充数者。

而程序员的门槛，是技术，是能力，走后门也写不出一行能跑通的代码。

退一步说，哪怕就算你真靠后门挤进了公司，项目一上来，分分钟就会露馅。

那些想走后门的人，大概率是想找一个稳当、轻松、有人脉资源的工作。但反思程序员这行，是这样吗？好……好像哪个也不沾边吧……

所以没人走后门干程序员，不是因为这行没前途，而是因为它太实在、太透明、太难伪装。

这是一份必须用真本事去交换的职业，关系在这里，价值被迅速稀释到近乎为零。

另外大家往往有种误解或者说错觉，总觉得程序员赚得多就是香，而实际却忽略了这个高薪背后所付出的代价，这一切都是来源于高强度脑力劳动和长时间脑力付出所带来的回报。

再者，互联网行业的本质是工程化与扁平化。在这个体系里，你是谁、认识谁、从哪来，其实并不太重要，没人会关注你这个，英雄不问出处。

重要的是，你能不能解决问题，能不能为项目创造价值。

所以，当我们回过头来再看，为什么没人走后门干程序员这个问题，其实本身就蕴含着一种误解。它预设了程序员是一个好差事，一个可以让人躺着赚钱的美差。

但事实上，程序员是一份需要真才实学、持续奋斗、直面挑战的工作。你付出多少努力，掌握多少技能，最终都会在你的代码和收入上得到真实的反馈。

当然，这里还有一点需要反思的是：

该说不说，程序员行业的这种去关系化特质，其实某一角度来说也带来了一些副产品。

比方说，技术至上的工作文化有时会导致个体沟通能力的忽视，对硬技能的过度强调可能让软技能的发展有所滞后，另外代码世界的非黑即白有时候也会让人忽略了现实世界的复杂灰度。

这些其实都是程序员文化中值得反思和平衡的地方。

有一说一，其实很多代码之外的东西对现如今的生存也很重要，因为思维如果不开阔出来的话，路可能就会越走越窄了。

其实很多程序员在年龄大了之后越来越焦虑的一个重要原因就是因为生存技能太过单一了，所以千万不要给自己设限，不要把目光仅仅聚集在自己的一亩三分地上，还是要多培养一些其他方面的一些软实力，会很有帮助。

不知道大家有没有看过《软技能》那两本书，讲的就是代码之外的一些软技能和经验，里面提到了很多有关职场的分析，自我提高的一些路径，个人的持续学习和成长，甚至包括像理财、健身、时间管理、心态调整等等。

有意识地去关注这方面东西的原因在于可以帮助自己把思维给开阔出来，毕竟很多时候有必要跳出来看问题，这时候这些软技能往往就能发挥作用了。

另外，程序员作为一个有个性的创造性群体要专注精进技术这本身没错，但是职场毕竟也是一个充满人情世故的江湖，所以掌握一些通用的职场规则、沟通技巧，甚至是向上管理的艺术，这对于程序员来说也是十分有必要的。

仰望星空，脚踏实地，埋头赶路的同时也不要忘记时常抬头看看周围的环境和机会。

那关于这个问题，你的看法是什么呢，如果有不同的见解，也欢迎一起来分享交流~

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

最近逛职场社区的时候，刷到一个职场话题，老生常谈了，但是每次参与讨论的同学都好多。

这个问题问得比较扎心：

“为什么有些企业的裁员首先从技术人员开始？”

关于这个问题，网上有一个被讨论很多的比喻：

“房子都盖起来了，还需要工人么？”

有一说一，这个比喻虽然刺耳，但却非常形象地揭示了某些企业的用人逻辑，尤其在某些非技术驱动型的公司里。

在某些非技术驱动的公司（比如传统企业转型、或者业务模式成型的公司），其实技术部门很多时候是会被视为「成本中心」，而非「利润中心」的，我相信在这类企业待过的技术同学肯定是深有体会。

就像盖大楼一样，公司需要做一个 App，或者搞一个系统，于是高薪招来一帮程序员“垒代码”。

当这个产品上线，业务跑通了，进入了平稳运营期，公司某些大聪明老板总会觉得“房子”已经盖好了。

这时候，一些开发人员在老板眼里就变成了“冗余”的成本。

大家知道，销售部门、业务部门能直接带来现金流，市场部能带来用户，而技术部门的代码是最看不见摸不着的。

一旦没有新的大项目启动，老板会觉得技术人员坐在那里就是在“烧钱”。

那抛开这个“盖楼”的比喻，在这种非技术驱动的公司里，从纯粹的财务角度来看，裁技术岗往往是因为“性价比”太低。

所以这里我们不得不面对的一个现实是：技术人员通常是公司里薪资最高的一群人。

高薪是一把双刃剑呐。

一个初级程序员的月薪可能抵得上两个行政，一个资深架构师的年薪可能抵得上一个小团队的运营费用。当公司面临现金流危机，需要快速削减成本时，裁掉一个高级技术人员省下来的钱，相当于裁掉好几个非技术岗位人员。

除此之外还有一个比较尴尬的事情那就是，在技术团队中，往往存在着一种“金字塔”结构。

随着工龄增长，薪资涨幅很快，但产出效率（在老板眼里）未必能线性增长。

脑补一下这个场景就知道了：

• 一个 35 岁的高级工程师，月薪 4 万，可能要养家糊口，精力不如 20 多岁的小年轻，加班意愿低。


• 一个 23 岁的小年轻，月薪 1 万 5，充满激情，能扛能造。

这时候某些大聪明老板的算盘就又打起来了：

裁掉一个 4 万的老员工，招两个 1 万 5 的小年轻，代码量翻倍，团队氛围更活跃，成本还降了，这种“优化”在管理层眼里，简直是“降本增效”的典范。

所以综合上面这种种情形分析，这时候，文章开头的那个问题往往也就会逐渐形成了。

所以事就是这么个事，说再多也没用。

既然环境不能左右，那作为个体，我们又该如何自处呢？

这里我不想灌鸡汤，只想务实地聊一聊我所理解的一些对策，希望能对大家有所启发。

同时这也是我给很多后台私信我类似问题小伙伴们的一些共同建议。

1、跳出技术思维，建立业务思维

千万不要只盯着你的 IDE 和那一亩三分地代码，抽空多了解了解业务和流程吧，比如：

• 项目是靠什么赚钱的？


• 你的代码在哪个环节为公司省钱或挣钱？


• 如果你是老板，你会怎么优化现在的系统？

当你能用技术手段去解决业务痛点（比如提升转化率、降低服务器成本）时，你就不再是成本，而是资产。

2、别温水煮青蛙，要保持技能更新

这一点之前咱们这里多次提及，在技术行业，吃“老本”是最危险的。

当今的技术世界变化太快，而作为程序员的我们则恰好处于这一洪流之中，这既是挑战，也是机会。

还是那句话，一定要定期评估一下自己的市场价值：如果明天就离开现在的公司，你的技能和经验是否足以让你在市场上获得同等或更好的位置？

无论在公司工作多久，都要不断更新自己的技能和知识，确保自己始终具有市场竞争力。

3、别让自己的工作经验烂掉，有意识地积累职业资产

这一点我们之前其实也聊过。

除了特定的技术、代码、框架可以作为自己可积累的能力资产之外，其实程序员的职业生涯里也是可以有很多可固化和可积累的有形资产的。

比如你的技术经历、思维、经验、感悟是不是可以写成技术博客文字？你写的代码、工具、框架是不是可以形成开源项目？你的工作笔记和踩坑记录是不是可以整理成技术手册？

千万不要让自己的工作经验烂掉，而是要有意识地将自己的技术资产化，将自己的过往经验、知识、能力转化成在行业里有影响力的硬通货。

4、尽早构建 Plan B，提升抗风险能力

当然这一点虽然说的简单，其实对人的要求是比较高的。前面几点做好了，这一点有时候往往就会水到渠成。

我觉得总体的方向应该是：尽量利用你的技术特长来构建一个可持续的 Plan B。

比方说：开发一个小工具、写写技术专栏、或者运营一个 GitHub 项目、在技术博客或社区中建立个人品牌...等等，这些不仅仅能增加收入，往往还能拓展你的人脉圈。

其实很多程序员在年龄大了之后越来越焦虑的一个重要原因就是因为生存技能太过单一了，所以千万不要给自己设限，埋头赶路的同时也不要忘记时常抬头看看周围的环境和机会。

好了，今天就先聊这么多吧，希望能对大家有所启发，我们下篇见。

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

我也开始碰视频。说实话，一开始很狼狈：剪一个一分钟的视频，要花我两三个小时。卡点、配乐、字幕、节奏，哪一样都不像看起来那么简单。我一度怀疑是不是我不适合，但又不甘心。我知道这是一块我之前没尝试过的能力，一旦练出来，就是新的路。

基于Trae还做了原型还原设计稿，没想到视频火了 

这一段给我的礼物，是一种更稳定的自信：很多事看起来复杂，只要拆开、一步步做，就会变得可控。

2. 我把想法做成了作品通过Vibe Coding

五月到八月，我进入了一种“手里有活”的状态。

从懵懂到落地：记录我们第一次成功将大模型“塞”进业务的曲折历程

年初做了自己第一款AI应用

那段时间我做了很多作品，也开源了不少东西。说白了，就是把想法从脑子里拎出来，做成一个能跑、能看、能用、能被别人理解的东西。

与此同时，我也给团队做了多次分享，讲我最近在做什么、怎么做、踩了什么坑、怎么绕开。

中间有两次机会我印象很深：一次是来自一家很大的咨询公司，一次是出海方向的远程邀请。它们都挺诱人，但我当时都拒绝了。原因很简单：我知道我还没准备好。能力没到那个厚度、心态没到那个稳定度，我不想靠运气上去，然后靠硬扛撑住。

也有一些小小的惊喜：有人买了我做的东西，虽然数量不算多，但足够让我确认——我做的东西不是自嗨，是真的有人需要。更重要的是，越来越多的网友通过我的内容认识我，联系我，问我问题。

那几个月我最大的收获不是“做了多少”，而是一个更朴素的结论：想法不值钱，做出来才值钱。

3. 有人愿意为我的能力买单

九月到十一月，我的副业开始像一门“正经事”。

咨询变多了。有的是临时问答，有的是更系统的陪跑。我接了三份陪跑，也因此认识了几位很投缘的朋友，都是山西的。我们聊项目、聊选择、聊怎么把事情做成，也聊怎么在现实里不把自己弄丢。

这份关系很珍贵。它不是那种互相吹捧的热闹，而是我能明显感到：对方因为我的建议少走了弯路，事情推进得更顺，而我也因为对方的反馈变得更坚定。那种“我真的帮到了人”的成就感，比数字更实在。

我也在这一段第一次更清晰地看到我的位置：我不是只能埋头做项目的人，我还可以把经验讲清楚，把复杂拆简单，把别人卡住的点指出来。这是一种能力，也是一种责任感。

这一段让我相信：靠自己攒出来的口碑，慢，但稳。

4. 我重新确认了“钱该花在哪”

国庆我和家人自驾出去玩了一趟。

风很大，天很高，羊肉很香。我们在草原上待了一天，我给父母安排了越野卡丁车，让他们在草地上跑一圈；我和姐姐骑了马，笑得像回到小时候。那几天我很放松，甚至有点恍惚——原来我努力这么久，最想换来的并不是某个头衔，而是这种“我能让他们开心”的底气。

我以前对花钱很谨慎，总觉得要攒着、要算计回报。可当我把钱花在家人身上，那种舒坦很直接：不需要证明，不需要解释，花出去就是一种“我扛得住了”的确认。

5. 去北京一趟，我把胆子捡了回来

十月我去北京参加了一个活动，也算第一次为了这类事出远门。2026年，多输出AI，多参加活动。

现场人很多，节奏很快，信息密得让人喘不过气。那天我最大的感受，不是见了什么产品，而是突然明白：机会真的会从我身边走过去，走过去就没了。很多时候不是我不够好，是我不敢站出来，或者我下意识觉得“我还不够格”。

去天津路上，熟悉的感觉

我也去了天津，见了老朋友老李。我们聊了一整天，我帮他搬运整理食品，他带我吃了天津菜，甚至让我体验了一把保时捷 911。最后他把我送到机场。

那一天让我很感慨：这个世界其实很大，也很活，我不能总把自己困在“怕麻烦、怕尴尬、怕出丑”的情绪里。

今年我也买了不少书，也读了不少书。《亲密关系》《认知驱动》《纳瓦尔宝典》……它们没有给我标准答案，但给了我更清醒的视角：我要对自己的情绪负责，对自己的选择负责，对自己的长期负责。

6. 我相信过他，也因此完成了一次祛魅

十一月底，我做了一个很重的决定：离职，去北京试一次。

这件事我并不是冲动。相反，我想了将近一个月。朋友“他”邀请过我三次，前两次我都拒绝了。第三次创始人亲自找我，话说得很漂亮，未来画得很大，而我也确实在那个阶段渴望一次更大的空间。再加上对“他”的信任，我最终点了头。

离开前，我做了一件我很想做的事：把爸爸接到上海。那是他第一次来上海，也是他第一次坐飞机。我去接他的时候，他脸上的喜悦藏不住。我带他逛了很多地方，拍了很多照片。送他去机场那天，我心里很踏实——那种成就感，不来自任何评价，只来自“我能带他看世界”的瞬间。

今年我也给妈妈买了新手机，她之前那部太卡了。再小的事情，落在父母身上都是实在的改变。

然后我去了北京。

现实很快给了我一记闷棍。之前说的和实际差太多太多。我会在很短时间内发现：有些话只是话，有些承诺只是情绪，有些“格局”只是包装。我不想在这里写具体细节，但我可以写结论——这次经历让我完成了一次祛魅：对人、对所谓“机会”、对“看起来很美”的未来。

我也更清楚了一件事：我并不是不能吃苦，我是不愿意把我的尊严和时间押在不靠谱的人和不靠谱的事上。

7. 我救了三只狗，也被这座城市的善意接住

这一年我救了三只狗。

第一只是中华田园犬，在公园遇到的。它很瘦，眼神怯，但又不躲人。

第二只是边牧，在公司附近，它更像是走丢的孩子，聪明又无助。

第三只是阿拉斯加，在豫园附近，体型很大，却一点安全感都没有。

我喜欢狗。遇见它们的时候，我很难装作没看见。我做的事其实也不复杂：拍照、发帖、联系、筛选领养人、把信息对齐清楚，然后送它们去新家。

这件事最打动我的，不是我多善良，而是我发现：大城市真的有很多愿意伸手的人。我发出求助，真的会有人回应。我以为我在救它们，其实在某些时刻，是这些善意在把我从疲惫里接住。

8. 一笔沉没成本：止损、维权、和不再委屈自己

十二月初，北京给了我最硬的一课。

我在北京待了十来天，一直住酒店。对方之前说会报销，但后来什么都没有。入职前一天我找了房子，租房费用、中介费用、再加上各种奔波成本，堆起来是一笔不小的支出。更糟的是：入职第一天我就通过另一位同样处境的人了解到了真实情况；再加上“他”下班后说的一些话，我很快确定——这里不是我该待的地方。

那一刻最难的其实不是离开，而是面对沉没成本。我已经付出那么多，我会本能地想“再忍忍，再等等”。但我很庆幸，那天我没骗自己。我选择止损。

随之而来的就是维权。房子我没入住，合同日期也没开始，但管家很无赖，甚至带着恐吓。那种“我讲理他就耍赖”的感觉很恶心。我一开始也很烦，后来干脆不和她废话，直接走流程，通过 12315 协调，拿回了一部分。理论上可以拿回更多，但要继续耗时间精力，我当时选择到此为止。

这一段时间，让家里也没少操心，哎....

我最想写给自己的不是“钱亏了”，而是一个更重要的结论：以后遇到不公，我不再用委屈换和平。该维权就维权，该翻脸就翻脸。

9. 回到上海：我把自己一点点拉回正轨

十二月中旬我回到了上海。

收拾好家里的工位

那段时间我能量很低。不是累，是一种被现实撞过之后的钝。我会怀疑自己、怀疑判断、怀疑信任，甚至怀疑“是不是我太敏感了”。但生活不会等我缓过来，它只会继续往前。

我做的第一件事是把我自己拉回正常：吃饭、睡觉、见朋友。后来我和老耿去了杭州散心。城市很安静，走在路上我突然发现：风还是一样吹，灯还是一样亮，我不会因为受挫就失去明天。

我慢慢控住场了。把生活拉回正轨了。也把那句最重要的话重新捡回来——我在变强，也在重新选择自己的人生结构。

最后

回头看 2025 年，我最大的变化不是“我做了多少”，而是我对人生结构的要求变高了。

以前我会把努力当成答案。现在我更在意：这份努力能不能沉淀，能不能让我拥有更多选择权。以前我遇到烂事会先忍，想着“算了”。但北京那一段之后我更确定：委屈不会换来尊重，只会换来下一次更大的代价。该止损就止损，该维权就维权——哪怕沉没成本已经砸下去，我也要把自己从泥里拎出来。

这一年我也完成了一次祛魅：
对“机会”的祛魅，对“关系”的祛魅，对“画出来的未来”的祛魅。
我开始相信一句话：真正值得的机会，不会只靠嘴说；真正可靠的人，也不会只靠情绪绑架。

如果说 2025 年教会了我什么，我觉得是三件事：

第一，能力不是拿来逞强的，是拿来兜底的。
我在最狼狈的时候，靠自己把局面稳住了。那种“我能扛住”的底气，是真的。

第二，钱花在家人身上，会变成一种很踏实的成就感。
我以前以为成就感来自外界认可，今年我更确定：来自父母的笑、来自家人的安心、来自“我可以照顾他们”。

第三，善意是会流动的。
我帮过人，也被人帮过；我救过狗，也被陌生人的热心治愈过。世界不全是烂人，但我得学会识别，学会筛选，学会保护自己。

2026 年我不想再喊口号了。我只想做三件更具体的事：

• 把一条能长期跑的主线做出来：让输出、作品和服务真正形成稳定的节奏，而不是靠运气起伏。
• 给信任立规矩：合作要有边界，承诺要能落地，任何决定都要留后手。
• 把家放进计划里：不是“有空再说”，而是本来就该排在前面。

2025 年没有把我推到高处，但它把我从幻觉里拽出来了。
我依然会往前走，只是以后我更在乎的不是速度，而是方向；不是热闹，而是结构。

我在变强，也在重新选择自己的人生结构。

就复盘到这吧，用时6个小时，该休息了....

希望2026年一切顺利! 

最近发现一个 AI 提效神器 ——Skills，用它配合 Cursor 开发，我仅用 5 分钟就帮女友做出了一款塔罗牌 H5 APP！在说如何操作之前，我们先大概了解下 Skills 的原理

一、Skills的核心内涵与技术构成

（一）本质界定

Skills 可以理解为给 AI Agent 定制的「专业技能包」，把特定领域的 SOP、操作逻辑封装成可复用的模块，让 AI 能精准掌握某类专业能力，核心目标是实现领域知识与操作流程的标准化传递，使AI Agent按需获取特定场景专业能力。其本质是包含元数据、指令集、辅助资源的结构化知识单元，通过规范化封装将分散专业经验转化为AI Agent可理解执行的“行业SOP能力包”，让 AI 从‘只会调用工具’变成‘懂专业逻辑的执行者

（二）技术构成要素

完整Skill体系由三大核心模块构成，形成闭环能力传递机制：

和传统的函数调用、API 集成相比，Skills 的核心优势是：不只是 “告诉 AI 能做什么”，更是 “教会 AI 怎么做”，让 AI 理解专业逻辑而非机械执行

二、Skills与传统Prompt Engineering的技术差异

从技术范式看，Skills与传统Prompt Engineering存在本质区别，核心差异体现在知识传递的效率、灵活性与可扩展性上：

上述差异决定Skills更适配复杂专业场景，可破解传统Prompt Engineering规模化、标准化应用的瓶颈。

三、渐进式披露：Skills的核心技术创新

（一）技术原理与实现机制

Skills能在不增加上下文负担的前提下支撑多复杂技能掌握，核心在于“按需加载”的渐进式披露（Progressive Disclosure）设计，将技能加载分为三阶段，实现知识传递与上下文消耗的动态平衡：

（二）技术优势与价值

渐进式披露机制使Skills具备三大核心优势：

四、Cursor Skills

介绍完 Skills 是什么之后，我将使用的是 Cursor 作为我的开发工具。先说明一下，最开始只有 Claude Code 支持 Skills、Codex 紧随其后，口味自己选。

好消息是，Cursor 的 Skills 机制采用了与 Claude Code 几乎完全一致的 SKILL.md 格式。这意味着，你完全不需要从头编写，可以直接将 Claude Code 的生态资源迁移到 Cursor。

（一）Cursor 设置

因为 Cursor 刚支持不久，并且是 Beta 才能使用，所以要进行下面操作

Agent Skills 仅在 Nightly 更新渠道中可用。

要切换更新渠道，打开 Cursor 设置（ Cmd+Shift+J ），选择 Beta，然后将更新渠道设置为 Nightly。更新完成后，你可能需要重新启动 Cursor。 如下图所示

要启用或禁用 Agent Skills：

（二）复制 Claude Skills

然后我们直接去 Anthropic 官方维护的开源仓库 anthropics/skills，里面提供了大量经过验证的 Skill 范例，涵盖了创意设计、开发技术、文档处理等多个领域。

你可以访问 github.com/anthropics/… 查看完整列表。以下是这次用到的 Skills：

• Frontend Design：这是一个专门用于提升前端设计质量的技能。它包含了一套完整的 UI 设计原则（排版、色彩、布局）

然后我们直接把 Skills 里面的 .claude/skills/frontend-design 到当前项目文件下，如图：

模型和模式如下图

提示词如下，不一定非得用我的。

使用 Skill front-design。我要做一个 H5 ，功能是一个塔罗牌。



你是一名经验丰富的产品设计专家和资深前端专家，擅长UI构图与前端页面还原。现在请你帮我完成这个塔罗牌应用的 UI/UX 原型图设计。请输出一个包含所有设计页面的完整HTML文件，用于展示完整UI界面。



注意：生成代码的时候请一步一步执行，避免单步任务过大，时间执行过长

然后 Cursor 会自动学习 Skills，并输出代码

然后就漫长的等待之后，Cursor 会自动做一个需求技术文档，然后会一步一步的实现出来，这时候可以去喝杯茶，再去上个厕所！

最终输出了 5 个页面

最终效果如下,整体效果看起来，完全是一个成熟的前端工程师的水准，甚至还带有过渡动画和背景效。因为掘金无法上传视频，欢迎私信我找我要或者关注我：

扩展阅读

因为 Cursor 目前仅在 Nightly 版本上才可以使用 Skills。如果担心切换此模式会引发意想不到的情况，可以使用另一种方案

OpenSkills 是一个开源的通用技能加载器。

• 完全兼容：它原生支持 Anthropic 官方 Skill 格式，可以直接使用 Claude 官方市场或社区开发的技能。


• 桥梁作用：它通过简单的命令行操作，将这些技能转换为 Cursor、Windsurf 等工具可识别的配置（AGENTS.md），从而让 Cursor 具备与 Claude Code 同等的“思考”与“技能调用”能力。

前几天收到一个bug，说是后台管理系统每次切换标签栏后，xxx内容区自动刷新，操作进度也丢失了，给用户造成很大困扰。作为结丹期修士的我自然不容允许此等存在，开干！

问题分析

该后台管理系统基于 vue3 全家桶开发，多标签页模式，标签页默认 KeepAlive，本文以 demo 示例。

切换标签后内容区自动刷新，操作进度丢失？首先想到的是 KeepAlive 问题，但经过排查后才发现，KeepAlive 是正常的，异常的是内嵌于页面的 iframe 内容区，页面每次 onActivated 时，iframe 内容区都会重新加载一次，导致进度丢失。

iframe 并没有被 keep 住，为什么？

通过查阅 Vue 文档得知，KeepAlive缓存的只是 Vue 组件实例，组件实例包含组件状态和 VNode (虚拟 DOM 节点)等。当组件 activated 时，组件 VNode 已经转为真实 DOM 节点插入文档中了，而组件 deactivated 时，已经从文档中移除了组件对应的真实 DOM 节点并缓存组件实例。

VNode 是对真实 DOM 节点的映射，包含节点标签名、节点属性等信息。我们打开控制台选中 iframe 元素，右侧那栏就是其对应的 VNode 了。

从上图可看出，iframe 的内容并不属于节点信息，是个独立的 browsing context（浏览上下文），无法被缓存；iframe 每次渲染（如 DOM 节点插入、移动）都会触发完整的加载过程（相当于打开新窗口）。故组件每次 activated 时，iframe 都会重新加载，创建了新的上下文，之前的操作进度自然是丢失了。

至此，问题原因已找到，接下来看下如何处理。

解决方案

iframe 无法保存于 VNode 中，又不能将 iframe 从文档中移动或移除，那么就想办法在某个地方把 iframe 存起来，比如 body 节点下，然后通过样式控制 iframe 展示与隐藏，顺着思路捋一下整体流程。

有了上述流程，开始设计下细节。 Iframe 组件是对 iframe 操作流的封装，方便在 vue 项目中使用，内部涉及 iframe 创建、插入、设置样式、移除等操作，为方便操作，将其封装为 Iframe 类；分散的 Iframe 类操作，稍有不当可能造成内存占用过多，故为了统一管理，再设计一个 IframeManage 来统一管理 Iframe。

相关的类关系图如下

classDiagram

    class Iframe {

        -instance: HTMLIFrameElement

        -ops: IframeOptions

        +init()

        +hide()

        +show(rect: IFrameRect)

        +resize(rect: IFrameRect)

        +destroy()

    }



    class IFrameManager {

        +static frames: Map<string, Iframe>

        +static createFrame()

        +static showFrame()

        +static hideFrame()

        +static destroyFrame()

        +static resizeFrame()

        +static getFrame()

    }



    class VueComponent {

        -frameContainer: Ref

        +createFrame()

        +destroyFrame()

        +showFrame()

        +resizeFrame()

        -handleLoaded()

        -handleError()

    }



    VueComponent --> IFrameManager : 使用

    IFrameManager --> Iframe : 创建/管理

    Iframe --> HTMLIFrameElement : 封装

对应的时序图如下

sequenceDiagram

    participant VueComponent

    participant IFrameManager

    participant Iframe

    participant DOM

    

    VueComponent->>IFrameManager: createFrame()

    IFrameManager->>Iframe: new Iframe(ops)

    Iframe->>DOM: createElement('iframe')

    Iframe->>DOM: appendChild()

    VueComponent->>IFrameManager: resizeFrame()

    IFrameManager->>Iframe: resize()

    Iframe->>DOM: setElementStyle()

    VueComponent->>IFrameManager: destroyFrame()

    IFrameManager->>Iframe: destroy()

    Iframe->>DOM: remove()

至此思路清晰，开始进入编码

编码实战

首先是 Iframe 类的实现

interface IframeOptions {

  uid: string

  src: string

  name?: string

  width?: string

  height?: string

  className?: string

  style?: string

  allow?: string

  onLoad?: (e: Event) => void

  onError?: (e: string | Event) => void

}



type IframeRect = Pick<DOMRect, 'left' | 'top' | 'width' | 'height'> & { zIndex?: number | string }



class Iframe {

  instance: HTMLIFrameElement | null = null

  constructor(private ops: IframeOptions) {

    this.init()

  }

  init() {

    const {

      src,

      name = `Iframe-${Date.now()}`,

      className = '',

      style = '',

      allow,

      onLoad = () => {},

      onError = () => {},

    } = this.ops



    this.instance = document.createElement('iframe')

    this.instance.name = name

    this.instance.className = className

    this.instance.style.cssText = style

    this.instance.onload = onLoad

    this.instance.onerror = onError

    if (allow) this.instance.allow = allow

    this.hide()

    this.instance.src = src

    document.body.appendChild(this.instance)

  }

  setElementStyle(style: Record<string, string>) {

    if (this.instance) {

      Object.entries(style).forEach(([key, value]) => {

        this.instance!.style.setProperty(key, value)

      })

    }

  }

  hide() {

    this.setElementStyle({

      display: 'none',

      position: 'absolute',

      left: '0px',

      top: '0px',

      width: '0px',

      height: '0px',

    })

  }

  show(rect: IframeRect) {

    this.setElementStyle({

      display: 'block',

      position: 'absolute',

      left: rect.left + 'px',

      top: rect.top + 'px',

      width: rect.width + 'px',

      height: rect.height + 'px',

      border: '0',

      'z-index': String(rect.zIndex) || 'auto',

    })

  }

  resize(rect: IframeRect) {

    this.show(rect)

  }

  destroy() {

    if (this.instance) {

      this.instance.onload = null

      this.instance.onerror = null

      this.instance.remove()

      this.instance = null

    }

  }

}

其次是 IFrameManager 类的实现

export class IFrameManager {

  static frames = new Map()

  static createFame(ops: IframeOptions, rect: IframeRect) {

    const existFrame = this.frames.get(ops.uid)

    if (existFrame) {

      existFrame.destroy()

    }

    const frame = new Iframe(ops)

    this.frames.set(ops.uid, frame)

    frame.show(rect)

    return frame

  }

  static showFrame(uid: string, rect: IframeRect) {

    const frame = this.frames.get(uid)

    frame?.show(rect)

  }

  static hideFrame(uid: string) {

    const frame = this.frames.get(uid)

    frame?.hide()

  }

  static destroyFrame(uid: string) {

    const frame = this.frames.get(uid)

    frame?.destroy()

    this.frames.delete(uid)

  }

  static resizeFrame(uid: string, rect: IframeRect) {

    const frame = this.frames.get(uid)

    frame?.resize(rect)

  }

  static getFrame(uid: string) {

    return this.frames.get(uid)

  }

}

最后是 Iframe 组件的实现

<template>

  <div ref="frameContainer" class="k-frame">

    <span v-if="!src" class="k-frame-tips">

      <slot name="placeholder">暂无数据</slot>

    </span>

    <span v-else-if="isLoading" class="k-frame-tips">

      <slot name="loading">加载中... </slot>

    </span>

    <span v-else-if="isError" class="k-frame-tips"> <slot name="error">加载失败 </slot></span>

  </div>

</template>

<script setup lang="ts">

import { onActivated, onBeforeUnmount, onDeactivated, ref, watch } from 'vue'

import { IFrameManager, getIncreaseId } from './core'

import { useResizeObserver, useThrottleFn } from '@vueuse/core'



defineOptions({

  name: 'KFrame',

})



const props = withDefaults(

  defineProps<{

    src: string

    zIndex?: string | number

    keepAlive?: boolean

  }>(),

  {

    src: '',

    keepAlive: true,

  },

)



const emits = defineEmits(['loaded', 'error'])



const uid = `kFrame-${getIncreaseId()}`

const frameContainer = ref()

const isLoading = ref(false)

const isError = ref(false)

let readyFlag = false



const getFrameContainerRect = () => {

  const { x, y, width, height } = frameContainer.value?.getBoundingClientRect() || {}

  return {

    left: x || 0,

    top: y || 0,

    width: width || 0,

    height: height || 0,

    zIndex: props.zIndex ?? 'auto',

  }

}



const createFrame = () => {

  isError.value = false

  isLoading.value = true



  IFrameManager.createFame(

    {

      uid,

      name: uid,

      src: props.src,

      onLoad: handleLoaded,

      onError: handleError,

      allow: 'fullscreen;autoplay',

    },

    getFrameContainerRect(),

  )

}

const handleLoaded = (e: Event) => {

  isLoading.value = false

  emits('loaded', e)

}

const handleError = (e: string | Event) => {

  isLoading.value = false

  isError.value = true

  emits('error', e)

}



const showFrame = () => {

  IFrameManager.showFrame(uid, getFrameContainerRect())

}

const hideFrame = () => {

  IFrameManager.hideFrame(uid)

}

const resizeFrame = useThrottleFn(() => {

  IFrameManager.resizeFrame(uid, getFrameContainerRect())

})



const destroyFrame = () => {

  IFrameManager.destroyFrame(uid)

}



const getFrame = () => {

  return IFrameManager.getFrame(uid)

}



useResizeObserver(frameContainer, () => {

  resizeFrame()

})



onBeforeUnmount(() => {

  destroyFrame()

  readyFlag = false

})



onDeactivated(() => {

  if (props.keepAlive) {

    hideFrame()

  } else {

    destroyFrame()

  }

})



onActivated(() => {

  if (props.keepAlive) {

    showFrame()

    return

  }

  if (readyFlag) {

    createFrame()

  }

})



watch(

  () => [frameContainer.value, props.src],

  (el, src) => {

    if (el && src) {

      createFrame()

      readyFlag = true

    } else {

      destroyFrame()

      readyFlag = false

    }

  },

  {

    immediate: true,

  },

)



defineExpose({

  getRef: () => getFrame()?.instance,

})

</script>



<style lang="scss" scoped>

.k-frame {

  position: relative;

  display: flex;

  align-items: center;

  justify-content: center;

  width: 100%;

  height: 100%;



  &-tips {

    position: absolute;

    top: 50%;

    left: 50%;

    transform: translate(-50%, -50%);

  }

}

</style>

看看效果

小结

管理后台多页签切换，iframe 区操作进度丢失，根本原因在于 KeepAlive 缓存机制与iframe 的独立浏览上下文特性存在本质冲突。本文通过物理隔离与视觉映射的双重策略，将 iframe 的真实 DOM 节点与Vue 组件实例解耦，实现了 keepAlive 的效果。

当然，该方案在代码实现还有很大优化空间，如 IFrameManager 目前是单例模式、Iframe 池未设计淘汰缓存机制（如 LRU ）。嘀嘀嘀...产品催着上线了，没时间优化了，下次一定。

相关代码已上传只 github，欢迎道友们给个 star，在此谢过了

我们最近刚把一个后台系统从 element-plus 切成了完全自研组件，CSS 层统一用 Tailwind。全员同意设计稿一致性提升了，但代码里怨言开始冒出来。

这篇文章不讲原理，直接上代码对比和团队真实使用反馈，看看是谁在享受，谁在撑着。

1.组件内样式迁移

原先写法（BEM + scoped）：

<template>

  <div class="card">

    <h2 class="card__title">用户概览</h2>

    <p class="card__desc">共计 1280 位</p>

  </div>

</template>



<style scoped>

.card {

  padding: 16px;

  background-color: #fff;

  border-radius: 8px;

}

.card__title {

  font-size: 16px;

  font-weight: bold;

}

.card__desc {

  color: #999;

  font-size: 14px;

}

</style>

Tailwind 重写：

<template>

  <div class="p-4 bg-white rounded-lg">

    <h2 class="text-base font-bold">用户概览</h2>

    <p class="text-sm text-gray-500">共计 1280 位</p>

  </div>

</template>

优点：

• 组件直接可读，不依赖 class 定义


• 样式即结构，调样式时不用来回翻

缺点：

• 设计稿变了？全组件搜索 text-sm 改成 text-base？


• 无法抽象：多个地方复用 .text-label 变成复制粘贴

2.复杂交互样式

纯 CSS（原写法）

<template>

  <button class="btn">提交</button>

</template>



<style scoped>

.btn {

  background-color: #409eff;

  color: #fff;

  padding: 8px 16px;

  border-radius: 4px;

}

.btn:hover {

  background-color: #66b1ff;

}

.btn:active {

  background-color: #337ecc;

}

</style>

Tailwind 写法

<button

  class="bg-blue-500 hover:bg-blue-400 active:bg-blue-700 text-white py-2 px-4 rounded">

  提交

</button>

问题来了：

• ✅ 简单 hover/active 很方便


• ❌ 多态样式（如 disabled + dark mode + hover 同时组合）就很难读：

<button

  class="bg-blue-500 text-white disabled:bg-gray-300 dark:bg-slate-600 dark:hover:bg-slate-700 hover:bg-blue-600 transition-all">

>

  提交

</button>

调试时需要反复阅读 class 字符串，不能直接 Cmd+Click 查看样式来源。

3.统一样式封装，复用方案混乱

原写法：统一样式变量 + class

$border-color: #eee;



.panel {

  border: 1px solid $border-color;

  border-radius: 8px;

}

Tailwind 使用中经常出现的写法：

<div class="border border-gray-200 rounded-md" />

问题来了：

设计稿调整了主色调或边框粗细，如何批量更新？

BEM 模式下你只需要改一个变量，Tailwind 下必须靠 @apply 或者手动替换所有 .border-gray-200。

于是我们项目里又写了一堆“语义类”去封装 Tailwind：

/* 自定义 utilities */

@layer components {

  .app-border {

    @apply border border-gray-200;

  }

  .app-card {

    @apply p-4 rounded-lg shadow-sm bg-white;

  }

}

最后导致的问题是：我们重新“造了个 BEM”，只不过这次是基于 Tailwind 的 apply 写法。

🧪 实测维护成本：100+组件、多人协作时的问题

我们项目有 110 个组件，4 人开发，统一用 Tailwind，协作两个月后出现了这些反馈：

• 👨‍💻 A 开发：写得很快，能复制设计稿的 class 直接粘贴


• 🧠 B 维护：改样式全靠人肉找 .text-sm、.p-4，没有结构命名层


• 🤯 C 重构：统一调整圆角半径？所有 .rounded-md 都要搜出来替换

所以我们内部的结论是：

Tailwind 写得爽，维护靠人背。它适合“一次性强视觉还原”，不适合“结构长期型组件库”。

🔧 我们后来的解决方案：Tailwind + token 化抽象

我们仍然使用 Tailwind 作为底层 utilities，但同时强制使用语义类抽象，例如：

@layer components {

  .text-label {

    @apply text-sm text-gray-500;

  }



  .btn-primary {

    @apply bg-blue-500 hover:bg-blue-600 text-white py-2 px-4 rounded;

  }



  .card-container {

    @apply p-4 bg-white rounded-lg shadow;

  }

}

模板中统一使用：

<h2 class="text-label">标题</h2>

<button class="btn-primary">提交</button>

<div class="card-container">内容</div>

这种方式保留了 Tailwind 的构建优势（无 tree-shaking 问题），但代码结构有命名可依，后期批量维护不再靠搜索。

📌 最终思考

Tailwind 是给设计还原速度而生的，不是给可维护性设计的。
设计师爱是因为它像原子操作；
开发者撑是因为它把样式从结构抽象变成了“字串组合游戏”。

如果你的团队更在意开发效率，样式一次性使用，那 Tailwind 非常合适。
如果你的组件系统是要长寿、要维护、要被多人重构的——你最好在 Tailwind 之上再造一层自己的语义层，或者别用。

分享完毕，谢谢大家🙂

📌 你可以继续看我的系列文章

• 《用了三年 Vue，我终于理解为什么“组件设计”才是重灾区》


• 《我为什么觉得 React 正在逐渐失去吸引力？》


• 《为什么越来越多 Vue 项目用起了 UnoCSS？》


• 《为什么我放弃使用 Pinia？》


• 《为什么我不再相信 Tailwind？三个月重构项目教会我的事》

简单写个自我介绍。

我在团队里算不上的管理层，没有人事权，也不决定谁走谁留，但我参与的项目一旦出问题，最后都会落到我这里。进度卡住、需求反复、线上事故，会议上可以绕一圈再绕一圈，最终还是要有人把代码改完、把锅兜住。我清楚自己的位置，用武之地比较多的一个“多功能开发者”而已。还依稀记得，当初总部另外一个项目的入侵测，找的还是我，而不是再招一个人。

所以我很少参与评价人，只谈事，谈事实，谈项目是怎么一步步偏离轨道的。

先直接告诉大家结果吧，他被辞退了。

当初公司决定要不要这个人的时候，无意中跟我提到过。我只讲述了几个项目事故，以及其他同事和他合作时的态度。至于留不留他，我不想决定，也决定不了。

那个项目经理，其实并不“坏”。他不吼人，也不甩脸色，会议纪要写得很勤，群里回复永远是“收到”“我跟一下”。问题出在另一层面：需求变更没有留痕，风险评估永远是“可控”，节点延期总能找到外部理由。

上面看到的是一条被不断抚平的曲线，下面看到的是每天被推翻重来的开发计划。我们不是没提醒过，只是提醒被整理成了更好看的版本，再往上递的时候，已经失去了原本的锋利。当然，这些最后都会被归结为一句话——开发同学多努努力，多扩展下思维，补补这个缺点就好了。

但我认为，有些问题其实在内部一直被反复提起，只是从来没有被真正放到台面上说过。

团队里的其他项目经理，大多都有过开发背景。哪怕代码早就不写了，对功能复杂度、实现成本、技术边界心里都是有尺度的。评估的时候会留余量，也知道什么时候该踩刹车。

只有他完全没有开发经验，对一个需求的理解停留在“看起来不难”的层面。既怕自己显得不专业，又怕在会上被认为拖进度，于是每次评估都偏向最激进的版本，功能报得满，时间压到极限。

开发这边明知道不现实，那又怎么办呢？你能说得过他吗？况且领导也是只看结果，活干得快，公司赚得多，干得慢赚得少。所以开发也只能硬着头皮往前推。

一次延期还能解释成意外，两次三次之后，延期就成了默认选项。项目表面上在跑，实际上每一步都在透支客户的耐心。

他甚至能把一个月的功能，压成 7 个工作日。

结果显而易见。项目连夜上线，第二天直接崩溃：APP、小程序白屏，数据无法保存，ToC 的用户一个都打不开。我们凌晨 4 点发完版本，早上 6 点半问题出现，7 点钟起床开始处理。

我起床的时候就已经料到了。项目有他管控着，您就放一万个心吧，麻烦肯定少不了。

当时写功能的时候，有个同事请了丧假。他来了句逆天发言：“到时候你能把电脑带上吗？有事可以找你。”

我当时真想告诉他，兄弟，全公司不是只有他一个前端，这个项目也不是只有他一个前端。人家就请假 3 天，已经很紧张了，还让人把电脑带着，真特么丧良心。

真正的转折点，是那次 A 项目上线。

我没有提任何人的名字，也没有用情绪化的词，只是把时间线拉直：哪一天确认需求，哪一天推翻，哪一天出 PRD，哪一天出 UI，最终导致了什么结果。那份文档写得很长，不好读，也不“体面”，但它有一个特点——每一个问题，都自然地指向了同一个岗位职责。

我提交的时候，甚至没多想，只觉得这次总算把事情说清楚了。

事后我想过，如果我当初不写那份复盘，不跟领导说这些事，会不会结果不同。答案大概是否定的。项目不会因为沉默变好，问题也不会因为不点名而消失。

那天没人替他说话，并不是因为他人缘差，而是因为在那个位置上，他已经很久没有为任何人、任何结果，真正说过一句“这是我的责任”。

系统从来不需要情绪，它只是在某个时刻，停止了包容。

我后来也明白了一件事：在很多公司里，项目经理这个角色，本质上是一个缓冲层。缓冲需求、缓冲压力、缓冲管理层的焦虑。

但一旦缓冲只剩下过滤，没有承担，系统就会重新校准。

那天被裁的不是一个人，而是一种失效的角色设计。而这件事，迟早会发生在任何一个不再为结果站出来的位置上。

🎯 总结对比

1️⃣ TypeIt（超强大，推荐！）

🎉 特点：高自定义、易用、支持暂停、删除、换行等丰富动画

安装：

npm install typeit

# 或直接用 CDN

简单用法：

<div id="typeit"></div>

<script src="https://cdn.jsdelivr.net/npm/typeit@8.8.3/dist/typeit.min.js"></script>

<script>

  new TypeIt("#typeit", {

    strings: ["Hello, 掘金！", "我是打字机效果~"],

    speed: 100,

    breakLines: false,

    loop: true

  }).go();

</script>

2️⃣ Typed.js（最流行的打字机插件）

🚀 轻量、简单、社区大，支持多字符串轮播

安装：

npm install typed.js

# 或 CDN

用法：

<span id="typed"></span>

<script src="https://cdn.jsdelivr.net/npm/typed.js@2.0.12"></script>

<script>

  new Typed('#typed', {

    strings: ['欢迎来到掘金！', '一起学习前端吧~'],

    typeSpeed: 80,

    backSpeed: 40,

    loop: true

  });

</script>

3️⃣ t-writer.js（国人开发，API友好）

🔥 支持多种打字动画，API 设计简洁

安装：

npm install t-writer.js

用法：

<div id="twriter"></div>

<script src="https://cdn.jsdelivr.net/npm/t-writer.js/dist/t-writer.min.js"></script>

<script>

  const target = document.getElementById('twriter');

  const writer = new TypeWriter(target, {

    loop: true,

    typeColor: 'blue'

  })

  writer

    .type('你好，掘金！')

    .rest(500)

    .changeOps({ typeColor: 'orange' })

    .type('打字机效果轻松实现~')

    .rest(1000)

    .clear()

    .start()

</script>

4️⃣ ityped（极简小巧）

⚡️ 零依赖，体积小，适合极简需求

安装：

npm install ityped

用法：

<div id="ityped"></div>

<script src="https://unpkg.com/ityped@1.0.3"></script>

<script>

  ityped.init(document.querySelector("#ityped"), {

    strings: ['Hello 掘金', '前端打字机效果'],

    loop: true

  })

</script>

🛠️ 补充：用原生 JS 实现简单打字效果

如果你不想引入第三方库，也可以用 setTimeout/async 实现基础打字动画：

<div id="simpleType"></div>

<script>

  const text = "Hello, 掘金！这是原生JS打字机效果~";

  let i = 0;

  function typing() {

    if (i < text.length) {

      document.getElementById('simpleType').innerHTML += text[i];

      i++;

      setTimeout(typing, 100);

    }

  }

  typing();

</script>

🌟 结语

• 需要高级动画，选 TypeIt/t-writer.js


• 需要轻量简单，选 Typed.js/ityped


• 只需基础效果，也可以原生 JS 10 行搞定！

在经济下行的大背景下，越来越多的中小型企业开始放弃“前后端分离”的人员配置，开始采用“全栈式开发”的模式来进行研发费用的节省。

这方法真那么好吗？

作为一名从“全栈开发”自我阉割成“前端开发”的逆行研发，我有很多话想说。

先从一个活生生的真实案例开始吧。

我认识一个非常优秀的全栈开发，因为名字最后一个字是阳，所以被大家称为“阳神”。

1. “阳神”的“神狗二相性”

阳神当然是牛逼的。

他不仅精通后端开发，更是对前端了解的非常深。这样来说吧:

当他作为后端开发时，他可以是那群后端同事里库表设计最清晰，代码最规范，效率最高的后端。

当他作为前端开发时，他除了比几位高级别前端稍逊一点外，效率和UI还原性都非常高，还会主动封装组件减少耦合。

但是非常奇怪的事情总是会发生，因为一旦阳神不是全职的“后端”或者“前端”时，一旦让他同时操刀“后端+前端”开发任务，作为一名“全栈”来进行业务推进时，他的表现会让人感到惊讶：

他会写出设计糟糕，不规范，职责混乱的代码。

这个现象我把他戏称为“阳神”的“神狗二相性”，作为单一职责时他是“阳神”，同时兼任多职时，他就有非常大的可能降格为“阳狗”。

为什么呢？这是阳神主观上让自己写更糟糕的代码吗？

不是的兄弟，不是的。

这是系统性的崩塌，几乎不以人的意志为转移。换我去也是一样，换你去也是一样。

2. 分工粗化必然导致技术细节的差异

从前，在软件开发的古老行会里，一个学徒需要花很多年才能出师，专门做一把椅子，或者专门雕一朵花。现在，你被要求从伐木到抛光，从结构力学到表面美学，全部一手包办。

生产力在发展，对人的技能要求也在发展。

因此“分工细化”成为了工业革命之后完全不可逆的趋势。

在 IT 产业上也是如此。

“软件开发”经过多年被细化出了前端开发、后端开发、客户端开发、大数据开发 等等多种不同的细分职业。

但是现在有人想通过 粗化 职业分功来达到 “提效” 的目的，在我眼中这就是和客观规律对着干。

人的精力是守恒的。当你需要同时关心useEffect的依赖数组会不会导致无限渲染，和kubectl的配置能不能正确拉起Pod时，你的注意力就被稀释了。你不再有那种“针对一个领域，往深里钻，钻到冒油”的奢侈。

当你脑袋里冒出了一个关于前端工程化优化的问题时，身为全栈的你会本能地冒出另一个念头：

在整个全栈体系内，前端工程化优化是多么边角料且无关痛痒的问题啊，我去深入研究和解决它的性价比实在太低了，算了不想了。

如此一来，无论是后端的性能问题还是前端的性能问题都会变得无关紧要。

结果是，只有业务问题是全栈开发要关心的问题。

2. “岗位对立”与“自我妥协”

在日常开发中，前端开发和后端开发之间互相吐槽争论是再正常不过的话题，而且争论的核心非常简单易懂：

前端：这事儿不能在后端做吗？

后端：这事儿前端不能做吗？

可以的，兄弟，最后你会发现都是可以的，代码里大部分的事情无论是在浏览器端完成还是在服务器里完成都是可行的。

但是，总有一个“哪方更适合做”吧？

• 一个大屏页面的几万几十万条的数据统计，是应该后端做还是前端做？


• 业务数据到Echarts展示数据的格式转换应该后端做还是前端做？


• 用户数据权限的过滤应该后端做还是前端做？


• 一个列表到底要做真分页还是假分页？


• 列表已经返回了全量实体信息，为什么还要再增加一个详情接口？

这都是日常开发时前端和后端都会去争论思考的问题，身处不同的职位，就会引入不同的立场和思考。

• 前端需要去思考页面刷新后状态的留存，js单线程下大量数据处理的卡顿，页面dom树爆表的困境。


• 后端也需要思考并发下服务器资源和内存的分配，可能的死锁问题，以及用户的无状态token如何处理等。

前后端的“争吵”和观点输出是不可避免的。

真理总是越辩越清晰的，后续讨论出的结果多半是最有利于当前现状的。

但如果“前后端”都是同一个人呢？

全栈模式，完美地消灭了这种“有益的摩擦”。当你自己和自己联调时，你不会给自己提挑战灵魂的问题。你不会问：“这个API设计是否RESTful？”因为你赶时间。你也不会纠结：“这个组件的可访问性够好吗？”因为你还得去部署服务器。

这两种思想在你的大脑里打架，最终往往不是最优解胜出，而是最省事的那个方案活了下来。

于是，你的代码里充满了“差不多就行”的妥协。这种妥协，一两个无所谓，当成百上千个“差不多”堆积起来时，质量的基础就酥了。

内部摩擦的消失，使得代码在诞生之初就缺少了一道质量校验的工序。它顺滑地流向生产环境，然后，在某个深夜，轰然引爆。

3. 工程的“不可能三角”

软件开发领域有一个著名的“不可能三角”：

快、好、省，你只能选两样。

全栈模式，在管理者眼中，完美地实现了“省”（一个人干两个人的活）和“快”（省去沟通成本）。那么，被牺牲掉的是谁？

雪崩时，没有一片雪花是无辜的。但更重要的是，当结构性雪崩发生时，问责任何一片雪花，都意义不大。

至于“快、好、省”这三兄弟怎么选？

那主要看老板的认知和他的钱包了。

系列回顾（性能·错误·埋点三部曲）：不做工具人｜从 0 到 1 手搓前端监控 SDK

在前三篇文章中，我们搞定了性能、行为和错误的采集。但有掘友在评论区灵魂发问：“数据是抓到了，
发不出去有啥用？进电梯断网了咋办？页面关太快请求被掐了咋办？”

今天这篇，我们就来聊聊如何上报数据？

• 用什么方式上报最稳、最省事?


• 什么时候上报最合适?


• 遇到断网/弱网/关页怎么兜底?

一、上报方式与策略：如何选出最优解？

我们平时上报数据主要有三种方式：Image（图片请求）、sendBeacon 和 XHR/Fetch。

1. 三种上报方式详解

1. GIF/Image

这招就是利用图片请求（new Image().src）来传数据。

• 原理很简单：把要上报的数据拼在 URL 后面（如 https://log.demo.com/gif?id=123），浏览器发起请求，服务器解析参数拿到数据，然后返回一张 1×1 的透明GIF图（体积小、看不见），浏览器收到后触发 onload 回调即完成上报。


• 特点：天然支持跨域，绝无“预检”请求（因为是简单请求）。


• 局限：只能发 GET 请求，URL 长度有限（通常 < 2KB），无法携带大数据。

2. sendBeacon

• 原理：navigator.sendBeacon(url, data)。浏览器会将数据放入后台队列，即使页面关闭了，浏览器也会尽力发送。


• 特点：异步非阻塞（不卡主线程），且可靠性极高。


• 局限：数据量有限（约 64KB），且无法自定义复杂的请求头。

3. XHR / Fetch

普通的网络请求。

• 原理：使用 XMLHttpRequest 或 fetch 发送 POST 请求。


• 特点：容量极大（几兆都没问题），适合发送录屏、长堆栈。


• 局限：跨域时通常会触发 OPTIONS 预检（成本高），且页面关闭时请求容易被掐断（fetch需配合 keepalive）。

注: 所谓的预检，就是浏览器在发送跨域且非简单请求前，先偷偷发个 OPTIONS 问服务器：“大佬，我能发这个请求吗？”。只要你用了自定义 Header 或 application/json 就会触发。这会导致请求量直接翻倍，在弱网下多一次往返就多一分失败的风险。

2. 策略篇：如何组合使用？

怎么选并不是随意决定的，而是为了解决两个核心痛点：

基于这两个维度，我们将三种方式排个序，也就形成了我们的降级策略：

1. 首选方案：sendBeacon（六边形战士）

这是现代浏览器的首选方案。

• 优势：专为监控设计，页面关闭了也能发（浏览器将其放入后台队列）。


• 特点：容量适中（~64KB），且通常不触发预检，完美平衡了“存活”与“成本”。


• 适用：绝大多数监控事件。

2. 降级方案：GIF/Image（老牌救星）

当 sendBeacon 不可用（如 IE）或数据极小的时候用它。

• 优势：天然跨域，绝无预检。利用 new Image().src 发起请求，服务器返回一张 1x1 透明图即可。


• 特点：兼容性无敌，但数据量受 URL 长度限制（~2KB），且页面关闭时发送成功率低。


• 适用：PV、点击、心跳等轻量指标。

3. 兜底方案：XHR / Fetch

只有前两招搞不定时（数据量太大）才用它。

• 优势：容量极大，适合传录屏、大段错误堆栈。


• 劣势：跨域麻烦（需配 CORS），有预检成本。


• 注意：使用 Fetch 时务必加 keepalive: true，告诉浏览器“就算页面关了也别杀我”，尽量提升卸载时的成功率。

选型对比表

总结我们的代码套路（降级策略）：

下面是封装好的 transport上报函数，直接拿去用：

const REPORT_URL = 'https://log.your-domain.com/collect'; 

const MAX_URL_LENGTH = 2048;

const MAX_BEACON_BYTES = 64 * 1024;



function byteLen(s) {

  try {

    return new TextEncoder().encode(s).length;

  } catch (e) {

    return s.length;

  }

}



/**

 * 通用上报函数

 * @param {Object|Array} data - 上报数据

 * @returns {Promise<void>} - 成功 resolve，失败 reject

 */

function transport(data) {

  const isArray = Array.isArray(data);

  const json = JSON.stringify(data);



  return new Promise((resolve, reject) => {

    // 1. 优先尝试 sendBeacon

    // 注意：sendBeacon 是同步入队，返回 true 仅代表入队成功，不一定是发送成功

    if (navigator.sendBeacon && byteLen(json) <= MAX_BEACON_BYTES) {

      const blob = new Blob([json], { type: 'text/plain' });

      // 如果入队成功，直接 resolve（乐观策略）

      if (navigator.sendBeacon(REPORT_URL, blob)) {

        resolve();

        return;

      }

      // 如果入队失败（如队列已满），不 reject，而是继续往下走降级方案

      console.warn('[Beacon] 入队失败，尝试降级...');

    }



    // 2. 单条小数据尝试 Image (GET)

    if (!isArray) {

      const params = new URLSearchParams(data);

      params.append('_ts', String(Date.now()));

      const qs = params.toString();

      const sep = REPORT_URL.includes('?') ? '&' : '?';

      

      if (REPORT_URL.length + sep.length + qs.length < MAX_URL_LENGTH) {

        const img = new Image();

        img.onload = () => resolve(); // 成功

        img.onerror = () => reject(new Error('Image 上报失败')); // 失败

        img.src = REPORT_URL + sep + qs;

        return;

      }

    }



    // 3. 兜底方案：Fetch > XHR

    if (window.fetch) {

      fetch(REPORT_URL, {

        method: 'POST',

        headers: { 'Content-Type': 'text/plain' },

        body: json,

        keepalive: true, // 关键：允许页面关闭后继续发送

      })

        .then((res) => {

          if (res.ok) resolve();

          else reject(new Error(`Fetch 失败: ${res.status}`));

        })

        .catch(reject);

    } else {

      // IE 兼容

      const xhr = new XMLHttpRequest();

      xhr.open('POST', REPORT_URL, true);

      xhr.setRequestHeader('Content-Type', 'text/plain');

      xhr.onload = () => {

        if (xhr.status >= 200 && xhr.status < 300) resolve();

        else reject(new Error(`XHR 失败: ${xhr.status}`));

      };

      xhr.onerror = () => reject(new Error('XHR 网络错误'));

      xhr.send(json);

    }

  });

}

二、上报时机：不阻塞主线程干扰业务，断网了也不丢数据

1. 调度层：区分优先级，关键时刻不等待

不是所有数据都适合“攒着发”。我们需要根据重要程度将日志分为两类：

• 即时上报（Immediate）：收集到立即上报。
  
  
  
  
  • 场景：JS 报错阻断了流程、用户点击了“支付”按钮、接口返回 500 等。
  
  
  • 原因：这些数据对实时性要求极高，或者关系到监控系统的报警（比如线上白屏了，你得马上知道），不能因为攒着发而耽误了。
  
  
  
  


• 批量上报（Batch）：攒一波再发。
  
  
  
  
  • 场景：用户点击、滚动、性能指标、API 成功日志。这类数据量大但实时性要求低
  
  
  • 策略：“量”与“时”双重触发（竞态关系）。比如：攒够 10 条立马发（防止堆积太多），或者每隔 5 秒发一次（防止数量不够一直不发）。
  
  
  
  

代码怎么写？其实就是一个简单的双保险调度器：

let queue = [];

let timer = null;

const QUEUE_MAX = 10;

const QUEUE_WAIT = 5000;



function flush() {

  if (!queue.length) return;

  

  // 1. 把当前队列的数据复制出来

  const batch = queue.slice();

  

  // 2. 清空队列与定时器

  queue.length = 0;

  clearTimeout(timer);

  timer = null;



  // 3. 利用空闲时间发送（性能优化点）

  if ('requestIdleCallback' in window) {

    requestIdleCallback(() => transport(batch), { timeout: 2000 });

  } else {

     // 降级兼容

    setTimeout(() => transport(batch), 0);

  }

}



function report(log, immediate = false) {

  // 1. 紧急情况：绕过队列，直接发

  if (immediate) {

    transport(log);

    return;

  }



  // 2. 普通情况：进入队列（如 点击、PV）

  queue.push({ ...log, ts: Date.now() });

  

  // 3. 检查触发条件（双重保险）

  if (queue.length >= QUEUE_MAX) {

    flush();

  } else if (!timer) {

    timer = setTimeout(flush, QUEUE_WAIT);

  }

}



// 4. 临终兜底：页面关闭/隐藏时，强制把剩下的都发走

document.addEventListener('visibilitychange', function () {

  if (document.visibilityState === 'hidden') flush();

});

window.addEventListener('pagehide', flush);

整体思路：队列暂存 + 多重触发

我们用一个数组（queue）来暂存日志，然后通过 “量够了”、“时间到了”或“页面要关了” 这三个时机来触发发送，确保既不积压也不频繁打扰服务器。

性能优化：闲时优先

发送时，我们首选 requestIdleCallback。告诉浏览器你先忙你的（渲染、响应点击），等你有空了再帮我发监控数据

• 这样能最大限度减少对业务主线程的阻塞，让用户感觉不到监控的存在。


• 当然，如果浏览器不支持这个 API，我们再降级用 setTimeout 兜底。

2. 容灾层：断网了，日志怎么办？

如果在电梯里断网了或者弱网环境下，请求发不出去怎么办？日志丢了怎么办。
我们的策略是 “先记在本子上，等有网了再补交作业”：

具体怎么判断有没有网呢？

通常我们用 navigator.onLine 来看。如果返回值是 false ，那肯定是没网，直接存本地。

但坑就坑在，这玩意儿有时候会 “撒谎” —— 比如连上了酒店 WiFi 但没登录，或者宽带欠费了。这时候它虽然显示 true （在线），但其实根本上不了网。

所以咱们得留一手：
哪怕它说“在线”，我们也先试着上报一下。 要是报错了发不出去，别管三七二十一，先把这条日志存本地保底（千万别丢数据），然后再去 Ping 一下看看到底是不是真断网了 ，顺便更新一下网络状态。这样最稳。

1. 网络状态的检测

NetworkManager这个模块专门负责盯着网络，它很聪明，只有在发送日志失败的时候才会去复核网络真伪。

const NetworkManager = {

  online: navigator.onLine,

  

  // 初始化：盯着系统的 online/offline 事件

  init(onBackOnline) {

    window.addEventListener('online', async () => {

      // 别高兴太早，先看看是不是真的能上网

      const realWait = await this.verify();

      if (realWait) {

        this.online = true;

        onBackOnline(); // 真的回网了，赶紧补传！

      }

    });

    window.addEventListener('offline', () => this.online = false);

  },



  // “测谎仪”：发个 HEAD 请求看看

  async verify() {

    try {

      // 请求个 favicon 或者 1x1 图片，只要响应了说明网通了

      await fetch('/favicon.ico', { method: 'HEAD', cache: 'no-store' });

      return true;

    } catch {

      return false;

    }

  }

};

2. 核心上报：能发就发，不行就存本地

上报函数现在变得非常有弹性。

export async function reportData(data) {

  // 1. 如果明确知道没网，直接存本地 (省一次请求)

  if (!NetworkManager.online) {

    saveToLocal(data);

    return;

  }



  // 2. 尝试发送

  try {

    await transport(data);

  } catch (err) {

    console.error('上报请求失败:', err);

    

    // 3. 不管是因为断网、超时、还是服务器挂了

    // 只要没成功，第一件事就是存本地！保证这条日志不丢！

    saveToLocal(data);



    // 4. 然后再来诊断网络，决定后续策略

    // 只有当是网络层面的错误（如 fetch throw Error）才去怀疑网络

    // 如果是 500 错误，其实网是通的，不用 forceOffline

    if (isNetworkError(err)) {

       // 5. Ping 确认

        NetworkManager.verify().then(res => NetworkManager.online = res);

    }

  }

}



/**

 * 判断是否为网络层面的错误

 */

function isNetworkError(err) {

  // 原生 fetch 的网络错误通常是 TypeError: Failed to fetch

  // 如果是使用 Axios，则可以通过 !err.response 来判断

  return err instanceof TypeError || (err.request && !err.response);

}



const RETRY_KEY = 'RETRY_LOGS';

const RETRY_MAX_ITEMS = 1000;

function saveToLocal(data) {

  const raws = localStorage.getItem(RETRY_KEY);

  const logs = raws ? JSON.parse(raws) : [];

  logs.push(data);

  if (logs.length > RETRY_MAX_ITEMS) {

    logs.splice(0, logs.length - RETRY_MAX_ITEMS);

  }

  localStorage.setItem(RETRY_KEY, JSON.stringify(logs));

}

3. 补传逻辑：别把服务器干崩了

等到网络恢复，本地攒了一堆“欠账”，千万别一股脑儿全发过去（万一本地存了 500 条，一次全发会把服务器打爆的）。

我们要有节奏地补传：

async function flushLogs() {

  let logs = JSON.parse(localStorage.getItem('RETRY_LOGS') || '[]');

  if (!logs.length) return;



  console.log(`[回血] 发现 ${logs.length} 条欠账，开始补传...`);



  while (logs.length > 0) {

    // 1. 每次只取 5 条，小碎步走

    const batch = logs.slice(0, 5);

    

    try {

      // 2. 调用上报中心

      await transport(batch); 

      

      // 3. 只有成功了，才把这 5 条从 logs 里剔除

      logs.splice(0, 5);

      localStorage.setItem(RETRY_LOGS, JSON.stringify(logs));

    } catch (err) {

      // 4. 如果失败了（断网或服务器挂了）

      // 此时 logs 里面还保留着那 5 条数据，所以不用担心丢失

      // 记录一下状态，直接跳出循环，等下次 NetworkManager 唤醒

      console.error('补传中途失败，保留剩余欠账');

      break; 

    }

    

    // 2. 歇半秒钟，给正常业务请求让个道

    await new Promise(r => setTimeout(r, 500));

  }

}

三、总结与实战建议

监控上报这事儿看着不难，其实门道不少。要在数据不丢和不打扰用户之间找平衡，咱们得来一套“组合拳”：

最后，给开发者的 3 个避坑小贴士：

• 不要迷信 navigator.onLine：它只能判断有没有连接到局域网，不能判断是否真的能上网。一定要配合实际的请求探测。


• 控制补传节奏：网络恢复后，千万别一次性把积压的几百条日志全发出去，这属于“DDoS 攻击”自家服务器。要分批、甚至加随机延迟发送。


• 隐私与合规：上报数据前，务必对敏感信息（如 Token、用户手机号）进行脱敏处理，这是红线。

如果你有更好的思路，欢迎在评论区交流！

前言

大语言模型（LLM）在早期阶段主要以对话机器人的形式出现，用户通过自然语言向模型提问，模型返回一段看似智能的文本结果。这一阶段，模型能力的发挥高度依赖用户如何提问，同一个问题，用不同的描述方式，往往会得到质量差异巨大的结果。

在这种背景下，提示词工程作为一门面向大语言模型的输入设计方法论逐渐成型，本篇文章主要帮助大家快速了解提示词工程的本质以及在书写技巧。

什么是提示词工程？

提示词工程的本质就是在有限上下文窗口内，最大化模型输出的确定性与可用性，减少模型自由发挥的空间。简单来说，就是提供一种提示词书写范式来确保大模型能够精准地按照用户的要求输出高质量的内容。

❌ 差提示词

帮我做一个个人待办清单页面

对于这段提示词，AI 不知道用什么技术、什么风格、要哪些功能、有什么限制。结果就是 AI 自由发挥，生成的代码和项目规范不符合。

✅ 好提示词

## 角色

你是一个擅长 React 和用户体验设计的前端开发者。



## 背景

我需要做一个个人待办清单网页，用来记录每天的待办任务，现在已经完整基本功能的开发。



## 任务

实现任务的"拖拽排序"功能，让用户可以通过拖拽调整任务顺序。



## 要求

- 拖拽时被拖动的任务半透明

- 放置位置有明显的视觉指示线

- 拖拽完成后顺序立即更新



## 约束

- 技术栈为 React + TypeScript + Tailwind CSS

- 不使用第三方拖拽库（如 react-beautiful-dnd）

- 用原生 HTML5 拖拽 API

- 代码要有详细注释，我是拖拽 API 的初学者



## 输出格式

完整的 React 组件代码，包含：

1. 组件文件（TypeScript）

2. 关键逻辑的中文注释

3. 简单的使用说明

提示词常见问题

在实际使用中，提示词的质量参差不齐，以下是几类最常见的问题及其本质原因。

信息量过多

我想让 AI 帮我做一个待办清单应用，于是将所有想法一次性列出：

帮我做一个待办清单应用，要有添加任务、删除任务、编辑任务、

标记完成、设置优先级、设置截止日期、分类标签、搜索功能、

数据统计、导出功能，还要有暗黑模式，最好能同步到云端，

支持多设备使用，界面要好看，用 React 写，要有动画效果。

问题本质：无结构、无重点。AI 可能会忽略关键信息，输出与某些要求冲突。

信息量太少

我想让 AI 帮我写个按钮组件，只有一句需求，没有任何背景：

帮我写一个按钮组件

问题本质：缺少上下文。上下文可能是：

• 项目的技术栈


• 按钮需要的功能


• 期望的样式风格

最终 AI 只能给一个通用的结果。

没有目标

我想让 AI 帮我优化代码，但不给优化目标：

帮我优化一下这段代码：

[粘贴了一段代码]

问题本质：只有动作，没有结果。优化指代不明确——是体积、性能还是可读性？最终输出的结果必然不符合预期。

没有约束

我想让 AI 帮我写一个输入框组件，但是没有添加相关约束：

帮我写一个输入框组件。



技术栈：React + TypeScript + SCSS

问题本质：AI 容易引入额外的假设，例如：

• 使用不兼容的 ui 组件库，例如 antd。


• 使用复杂的状态管理机制。

导致最终输出不可控，隐性引入错误假设。

提示词模板

了解了常见问题后，我们需要一套结构化的方法来避免它们。这就是提示词模板的价值所在。

提示词的困扰

我们现在知道在使用 AI 时，提供的上下文越清晰，AI 给出的回答就会越符合预期。但是每次写提示词的时候，我们大概率还是会陷入这样的状态：

我要先给 AI 指定一个角色，告诉他背景和任务，还有约束、要求、技术栈……约束要包含什么内容？要求要写什么？技术栈要放到哪里？

这会给 AI 使用者带来很大的认知负担，我们同时要思考"说什么"和"怎么说"。而模板的价值，就是把"怎么说"变成固定格式，让你专注于"说什么"。

这与前端的开发框架（React/Vue）很类似：在没有框架之前，开发者既要关注业务，同时还需要关注 DOM 更新及性能问题；随着框架的推出，前端开发者能把更多的精力放到业务功能开发上。

模板目标

提示词模板的目标是减少使用者的思考负担并提高 AI 输出的稳定性。但模板并不是终极目标，因为固定的模板反而会限制灵活性。因此在不同阶段、不同场景，使用者可以对模板进行调整：

推荐模板

模板结构：

模板示例：

## 角色

你是一个擅长 React 和组件开发的的前端开发者。



## 背景

我使用 react 开发了一个基础组件库，里面包含了xx个组件，组件名称如下xxx。



## 任务

帮我为每个组件生成一份 mdr 文件，表示该组件的使用详细说明。



## 要求

- 文档要包含组件的 API、使用示例、xxx。



## 约束

- 使用 md 语法。

- 必须保证 API 的完整，不能漏掉内容。



## 输出格式

Title: 组件名称



description: 组件描述



API：

xxx



Examples：

xxx



## 示例



Title: Alert



description: 警示组件



API:



| 参数 | 说明 | 类型 | 默认值 | 版本 |

| --- | --- | --- | --- | --- |

| action | 自定义操作项 | ReactNode | - | 4.9.0 |

| afterClose | 关闭动画结束后触发的回调函数 | () => void | - |  |

| banner | 是否用作顶部公告 | boolean | false |  |

进阶提示词技巧

Few-shot Prompting

Few-shot 的核心思想就是给 AI 几个例子，让他先按照例子学习，理解任务处理流程及最终的内容输出。这种模式能够更高效的让 AI 理解用户的意图，这和人学习新东西一样，直接看示范比读文档更高效。

任务：为 React 组件生成 TypeScript Props 类型定义



示例1：

组件描述：一个显示任务标题的组件，标题必填，可选显示完成状态

输出：

interface TaskTitleProps {

  title: string;           // 任务标题，必填

  isCompleted?: boolean;   // 完成状态，可选

}



示例2：

组件描述：一个按钮组件，显示文字必填，点击事件必填，可选禁用状态

输出：

interface ButtonProps {

  label: string;           // 按钮文字，必填

  onClick: () => void;     // 点击事件，必填

  disabled?: boolean;      // 禁用状态，可选

}

示例虽然能够更高效的帮助 AI 理解任务，但是过多的示例也会加大 token 的消耗，因此示例不是越多越好，要遵循少而精的原则，通过 2～5 个例子将典型的场景、多样性场景以及边界场景列举出来。

Chain of Thought

Chain of Thought 的核心思想是告诉 AI 让他一步步思考推理，输出推理内容，而不是直接给答案。就像解数学题一样，把解题的每一步都写出来，这样往往能让 AI 输出更准确的答案。

## 角色

你是一个擅长 React 和组件开发的的前端开发者。



## 背景

我使用 react 开发了一个基础组件库，里面包含了xx个组件。



## 任务

帮我给修改的 react 组件补充新的单测。



### 修改点分析步骤

- 分析组件的 props，找出新增/删减/修改的参数，并输出出来。

- 分析组件的内部逻辑，找出新增/删除/修改的逻辑，并输出出来。

这种模式在复杂的场景中会大大提升输出效果，但是也存在一些局限：

• 输出内容的长度会大大增加，增加 Token 的消耗。


• 对于某些简单任务，强行使用该模式可能反而会降低效果。


• 如果推理的过程中某一步出错，可能会导致接下来步骤都会出错，需要配合 Self-Critique 来检查。

Self-Critique

与人类一样，AI 并非总能在首次尝试时就生成最佳输出，Self-Critique 的核心思想是在 AI 生成内容之后，让 AI 再自我检查一遍，发现并修复问题。这个和我们考试答题一样，做完之后再检查一遍往往能发现遗漏的细节或者写错的题。

## 角色

你是一个擅长 React 和组件开发的的前端开发者。



## 背景

我使用 react 开发了一个基础组件库，里面包含了xx个组件。



## 任务

帮我给修改的 react 组件补充新的单测。



## 修改点分析步骤

- 分析组件的 props，找出新增/删减/修改的参数，并输出出来。

- 分析组件的内部逻辑，找出新增/删除/修改的逻辑，并输出出来。



## 要求



- 生成完之后，请严格自查

	- 是否覆盖了所有修改点。

	- 每个修改点是否覆盖了所有边界情况（空值、空字符串、只有空格）

这种模式下会让 AI 扮演一个审查者的角色重新审下生成的内容，提高内容的准确性，但是也有它的局限：

• 增加 Token 的消耗，这种模式更推荐在复杂的场景中使用。


• AI 可能出现自我认可的偏差，认为输出是没问题的，此时需要严格给 AI 设定审查者的角色。

总结

本文围绕「提示词工程」展开，从背景、核心目标、常见问题、结构化模板，到 Few-shot、Chain of Thought、Self-Critique 等进阶技巧，系统性地说明了一件事：

提示词工程的本质，不是“如何把话说得更漂亮”，而是如何通过结构化上下文，降低大模型输出的不确定性。

然而，这种提示词优化的思路也带来了新的工程问题：提示词越来越长、结构越来越复杂，最终直接反映为 Token 体积的持续膨胀。

因此，在实际工程中，提示词优化并不等同于写得越详细越好，而是需要在信息充分性与 Token 成本之间取得平衡。如何控制上下文规模、避免无效信息堆积、并在复杂任务中持续提供刚刚好的上下文，成为提示词工程之后必须面对的核心问题。

参考资料

• OpenAI Prompt Engineering Guide


• Anthropic Prompt Engineering


• Few-shot Prompting


• Chain of Thought


• Self-Critique

提到 Zorin OS 这个操作系统，可能不少喜欢折腾 Linux 系统的小伙伴之前有尝试过。

作为一款以 UI 交互和颜值著称的 Linux 发行版系统，Zorin OS 也曾一度被广大爱好者们称为 Windows 系统的开源替代方案。

Zorin OS 旨在简单易用，用户无需学习任何新知识即可上手，同时 Zorin OS 作为一款 Linux 发行版系统，专为从 Windows 迁移的用户设计，提供类似 Windows 的图形界面与操作逻辑，并且支持一键切换为 Windows 系统风格。

前段时间，Zorin OS 团队在其官博正式宣布，最新的 Zorin OS 18 已经正式突破了 100 万次下载。

并且据官博数据显示，这些下载中有超过 78% 是来自于 Windows 系统的用户，这也再次印证了其可以满足从 Windows 桌面系统迁移到 Linux 发行版的用户需求。

作为一个长期关注 Linux 桌面系统的博主，其实这次 Zorin OS 18 大版本更新刚出来那会我就关注了，不过一直没有抽出时间来写文章、来梳理，所以今天这篇文章正好把这件事情给安排了！

总体来讲，这次的 Zorin OS 18 是以 Ubuntu 24.04 LTS 为基础并由 Linux 6.14 内核提供支持。

并且这次的 Zorin OS 18 是继之前 17 版本以来的一次大版本迭代，带来了诸多新特性和改进。

所以接下来我们也来梳理一下这次 Zorin OS 18 所带来的一些重点更新和变化。

视觉与交互进化

众所周知，Zorin OS 一直以来都以其独特的个性和简约的美学设计风格而著称。

那这次更新后的新外观给人最直观的感受就是圆润和通透。

任务栏这一次采用了全新的悬浮圆角面板设计，不再是死板地贴在屏幕边缘，而是像 macOS 的控制中心一样有一种轻盈的漂浮感。

另外这一次大版本还推出了新主题颜色，新增了黄色和棕色两种主题色，视觉层次更加丰富。

选中元素的色调更加淡雅，背景和侧边栏颜色更深，长时间盯着屏幕写代码或处理文档，眼睛会舒服很多。

另外 Pro 版里还提供了更多可切换的桌面布局。

除此之外，很多经常使用的日常应用也进行了诸多设计调整和改进。

比如文件管理器的侧边栏重新设计了，操作控件更直观，搜索功能支持了全文搜索，找文件效率大增。

日历应用增加了侧边栏，月份和事件视图也一目了然。

相机应用也做了更新，新相机应用界面简洁，支持多摄像头切换，这对于现在动不动就开视频会议的环境非常友好。

Web 应用深度集成

对于用户来说，最大的痛点往往不是系统本身，而是数据迁移和应用生态，那 Zorin OS 18 在这方面下了不少功夫。

首先就是与 Web 应用程序无缝集成。

众所周知，现在很多应用都构建在云端，这些渐进式 Web 应用与原生应用之间的用户体验正逐渐融合。

这次 Zorin OS 18 全新内置的「Web Apps」工具非常强大，它可以将 Web 应用转换为桌面应用，用户的 Web 应用将可以显示在开始菜单中，使用起来与原生应用无异。

「Web Apps」工具可以作为后端与各种热门 Web 浏览器集成，同时也允许用户自定义对应 Web 应用内的体验。

多任务处理：原生窗口平铺

这次 Zorin OS 18 的多任务处理变得好用多了。

Zorin OS 18 引入了一款功能强大的窗口平铺管理器，它能帮助用户更高效地工作，同时上手起来也十分简单。

用户只需要把窗口拖到屏幕顶部，系统就会自动弹出布局选择器。

预设布局支持左右分屏、三栏布局、角落停靠等，同时在智能建议这块，系统也可以根据用户当前所打开的窗口，智能推荐最佳的排列组合。

除此之外它还支持高度自定义，创建用户自己的平铺布局。

这个新特性无论对新手还是资深玩家都非常直观易用，从而定制和提升每个用户的生产力。

迁移神器：Windows 应用支持

用户可以从内置的软件商店发现适用于 Zorin OS 系统的各类应用，这是在 Zorin OS 中安装应用的推荐方式。

其软件商店可让用户开箱即用地从 Zorin OS 与 Ubuntu APT 仓库、Flathub 以及 Snap Store 安装应用。

而如果用户是刚从 Windows 转过来，看到满硬盘的 .exe 安装包肯定会头疼。

Zorin OS 18 的处理方式非常聪明。

系统内置了一个庞大的软件数据库（覆盖超过 170 款软件），当用户双击一个 Windows 安装包（如 setup.exe）时，系统不会直接报错，而是弹出一个友好的对话框。

如果有 Linux 原生版本，它就会引导你安装原生版本应用；如果没有原生版的话，它就会推荐你使用 Web 版，或者利用兼容层运行。

在兼容层优化这一块，Zorin OS 18 深度集成了 Wine，对于一些必须在 Windows 下运行的行业软件或游戏，它提供了一个“Windows 应用支持”层。虽然不能保证 100% 兼容，但对于很多老旧的 .exe 工具，它能让你在不装虚拟机的情况下应急使用。

性能与硬件支持

Zorin OS 18 基于 Ubuntu LTS 版本打造，同时它将获得直到 2029 年的稳定安全更新。

同时官方宣称它甚至可以在十几年前的古董机上流畅运行。最低配置仅需 1GHz 双核 CPU、2GB 内存。

同时从用户安装的实际表现来看，在现代硬件上，它的动画流畅度非常高，即便在老机器上，它运行起来也比 Windows 系统更加轻快。

写在最后

那以上就是关于此次 Zorin OS 18 大版本更新的一些梳理和总结，感兴趣的小伙伴也可以去体验一波。

总的来看，这次的 Zorin OS 18 不仅仅是一个 Linux 发行版，也像极了一个操作系统迁移解决方案。

另外这次 Zorin OS 18 的发布，也使得 Linux 桌面系统的易用性又向前迈进了一步。

文章的最后也期待 Linux 桌面系统在未来能百花齐放，发展得越来越好。

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

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

在日常的大前端需求开发中，我们常常需要同时兼顾UI还原和业务逻辑两部分工作。UI方面，就是要尽可能细致地还原设计稿上的每个细节；业务逻辑方面，则往往和需求复杂度以及项目代码规模正相关。今天，我们就来聊聊如何利用AI驱动，提升需求实现过程中的效率和体验。

UI设计稿还原

如今市面上已经有不少做得不错的AI设计稿转代码工具，比如v0、bolt.new、codefun等。对于一些个人独立项目来说，这些工具真心牛逼：只需传入设计稿，就可以快速生成模块化、精确的UI代码，而且还能通过对话式的交互来不断调整细节，直到完全符合预期。

但如果把这些工具直接应用于一个成熟项目中，就会暴露一些问题。首先，目前大部分工具主要支持vue和react，而我们的项目往往还涉及flutter、android、iOS等多端开发。其次，成熟项目中往往都有一套独特的代码规范和UI组件库，而这些工具生成的代码往往并不了解这些细节，直接将生成的代码拷贝进项目之后还得二次调整，额外的成本不可忽视。

那么有没有办法既能支持更多编程语言，又能在生成UI代码时就结合项目中已有的规范和组件库，从而减少二次调整成本呢？答案是有的！

目前，figma是市面上使用比较主流的设计稿工具。Builder.io最近发布了一款基于figma设计稿、AI驱动的前端代码生成插件——Visual Copilot。使用它，你只需要把figma切换到Dev Mode，然后选择设计稿中的任意图层，接着在Visual Copilot中直接导出代码。

Visual Copilot生成的代码不仅支持vue、react，还涵盖了其它几乎所有主流的大前端语言和框架，十分全面。你可以实时预览生成的效果，并进行细节调整，直到满意为止。

生成代码后，如何让这些代码完美融入到我们的项目规范中呢？ 这里就需要结合Visual Copilot与Cursor的配合来实现。

具体做法是：当Visual Copilot将设计稿图层转化成代码后，它会自动生成一个可远程执行的工作空间，并提供相关命令(图中红框所示)将工作空间的代码集成到我们项目中。

接下来，我们只需在Cursor的Terminal中运行指定指令，就能连接Visual Copilot的远程工作空间，实时获取生成的代码，同时通过交互指令界面明确我们后续的需求。

那么，最终生成的代码如何与项目中的各种规范结合呢？ 这就要用到Cursor的AI规则机制——CusorRules。你只需在项目根目录下配置一个.cursorrules文件，声明你的UI代码规范以及封装的组件信息。Cursor在生成代码时就会充分参照这些规则。同时，新版Cursor还支持配置一系列rule文件，你可以通过正则路径来指定规则应用于不同的模块或文件类型，整个过程非常灵活高效（具体可以参与Cursor官方文档）。

业务逻辑开发

在一些中小型规模的项目中，如果想在Cursor中高效地实现业务逻辑，我们需要关注两个关键点：

• CursorRule的应用
  
  和上文UI的规范梳理类似，我们还需要对项目各模块的架构规范等信息进行说明，这样可以让Curosr生成的代码能尽量保障和我们项目规范的一致性。


• 需求拆解：先构建框架，再处理细节
  
  对于较为复杂的需求，我们可以先把实际需求拆解成多个阶段。首先，构建大致的需求框架，并转换成一系列对Cursor友好的Prompt指令（要求简单、准确）。在Cursor的Compose Agent模式下，通过这些指令生成整体的业务逻辑框架。接下来，再利用Cursor Tab在编辑器区域快速完善那些生成时不够精准的细微逻辑。

在一些中小型项目中，通过以上两个关键点我们通常可以快速完成业务逻辑开发。但在一些大型项目中，会遇到Cursor生成的代码经常不尽如人意的问题。这主要是因为项目越大，整个代码库的复杂性增加，Cursor对项目的理解难度也随之上升，每次修改都可能会有不确定因素，提示词如果不能准确描述需要改动的部分，就容易出错。

此时，我们可以尝试另一种思路：用”软件架构师“与”开发者“角色区分需求规划与执行细节。应该怎么做呢？

我们可以将AI驱动的开发流程分为两个阶段：

这种方式的好处在于，只要“软件架构师”生成的提示词足够精准（即它能详细说明需要修改的文件、具体的改动内容和改动范围），那么“开发者”便能够依照这些提示词精确地进行代码修改，极大降低了因大范围理解产生的错误风险。所以这里的性能瓶颈就在于如何定义”软件架构师“角色以及让其接到需求后能生成精确的提示词。

在实际操作中，我们引入了一个“项目地图”的概念。所谓项目地图，就是为大型项目构建一个完整的文档体系（借助AI辅助生成也完全可行），其中包括了项目架构设计、开发流程、模块划分与用途、文件名和其功能说明等内容。这套文档体系可以独立于一个实际的Cursor项目存在，充当“软件架构师”的角色。也就是说，当遇到bug或新需求时，我们可以通过咨询这个“项目地图”，让AI回答问题并给出相对准确的修改思路。

举个例子，拿知名的fast-api项目来说，我为它生成了一个项目地图，其中包含了核心概念说明、系统设计、项目规范以及各模块和文件的用途说明等内容：

同时，在该项目的 .cursorrule 文件中，我详细规定了“软件架构师”如何根据实际需求生成精确的修改指令：

## 项目背景信息

项目名称：FastAPI

项目类型：Python Web 框架

项目地图：参考 fileNames.md

架构文档：参考 architecture/ 目录

编码规范：参考 guidelines/coding-standards.md



## 需求分析模板

1. 需求描述

[简要描述需要实现的功能或修改]



2. 涉及组件

- 核心组件：[列出受影响的核心组件]

- 依赖组件：[列出相关的依赖组件]

- 测试组件：[列出需要修改的测试]



3. 修改范围

- 主要文件：[列出需要修改的主要文件]

- 次要文件：[列出可能需要修改的次要文件]

- 文档文件：[列出需要更新的文档]



4. 技术要点

- 使用的框架特性：[列出需要使用的 FastAPI 特性]

- 数据验证：[描述数据验证要求]

- 兼容性考虑：[描述向后兼容性要求]



5. 潜在风险

[列出可能的风险点和注意事项]



## 执行指导模板



### 给大模型的执行指导



1. 修改步骤

[详细的步骤说明]



2. 验证点

[列出需要验证的关键点]



4. 测试建议

[提供测试建议和用例]





## 实际案例：添加用户电话号码字段



### 1. 需求分析



需求描述：

在用户模型中添加可选的 phone_number 字段，并在相关 API 端点中支持该字段。



涉及组件：

- 核心组件：用户模型（UserIn, UserOut, UserInDB）

- 依赖组件：无

- 测试组件：用户相关测试



修改范围：

- 主要文件：/docs_src/extra_models/tutorial001.py

- 次要文件：无

- 文档文件：API 文档可能需要更新



技术要点：

- 使用 Pydantic BaseModel

- 字段类型：Union[str, ]

- 保持向后兼容性



潜在风险：

- 确保不破坏现有的数据验证

- 保持与现有字段风格一致





### 2. 执行指导

给大模型的具体修改指导：



1. 修改步骤：

   a. 在 UserIn 模型中添加 phone_number 字段

   b. 在 UserOut 模型中添加对应字段

   c. 在 UserInDB 模型中添加对应字段

   d. 确保字段定义与 full_name 保持一致的风格





2. 验证点：

   - 字段是可选的

   - 类型提示正确

   - 与现有代码风格一致

   - 不影响现有功能



3. 测试建议：

   - 测试不提供电话号码的情况

   - 测试提供有效电话号码的情况

   - 测试提供无效数据的情况



## 使用说明



1. **分析阶段**

   - 使用项目背景信息了解上下文

   - 按需求分析模板进行分析

   - 生成详细的执行指导



2. **交付阶段**

   - 将执行指导传递给大模型

   - 确保指导清晰且可执行

   - 包含必要的验证点



3. **验证阶段**

   - 检查实施结果

   - 确认所有要求都已满足

   - 验证代码质量和一致性



4. **输出**

   - 输出执行指导，包括修改步骤、验证点和测试建议，新建analysis目录，在该目录下用一个独立的文件承载，文件名要求符合问题描述诉求<cursor-tools Integration>

# Instructions

基于这些配置，当提交需求时，AI生成的修改思路大致如下，它会精准指出应对哪些文件进行哪些具体改动。

# 需求分析



## 1. 需求描述

在高并发场景下，针对大量用户同时请求数据库导致的性能瓶颈，需要在应用程序中增加缓存机制，降低数据库查询次数，提升整体响应速度和系统稳定性。



## 2. 涉及组件

- 核心组件：数据查询相关业务逻辑（可能涉及CRUD操作的函数或类）

- 依赖组件：可能需要引入第三方缓存库（如 redis、in‐memory 缓存等）

- 测试组件：与数据库查询逻辑相关的测试用例



## 3. 修改范围

- 主要文件：核心业务逻辑所在模块（例如：/app/database.py 或 /app/services/xxx.py）

- 次要文件：如果需要封装缓存工具，则可能新增 /app/utils/cache.py

- 文档文件：如果提供额外的缓存配置，需要更新相关文档



## 4. 技术要点

- FastAPI 配合缓存解决方案（如 in‐memory 缓存、Redis、memcached 等）

- 选择合适的缓存失效策略（LRU、TTL、手动失效等）

- 线程安全、进程安全或分布式缓存方案

- 保证与现有数据校验和返回结构的一致性



## 5. 潜在风险

- 引入缓存后数据一致性问题（可能出现短时间的数据延迟）

- 缓存过期策略不当导致性能问题或脏数据

- 多节点部署时的缓存同步与一致性

- 第三方库的稳定性和可维护性



---



# 执行指导



## 1. 修改步骤

1. 确定缓存方案（例如：Redis 或者内存缓存），并根据业务需求配置失效策略。

2. 在核心数据库查询逻辑中添加缓存查询逻辑：

   - 查询前先在缓存中查找数据；

   - 如果未命中或缓存过期，则查询数据库并将结果写入缓存；

   - 如果命中，则直接返回缓存结果。

3. 为关键业务接口添加缓存逻辑（可封装成一个装饰器，或在查询函数内部实现）。

4. 在配置文件或环境变量中添加缓存相关配置，如主机、端口、缓存大小、过期时间等。

5. 编写或修改测试用例，确保在开启缓存后仍能正确测试业务逻辑。



## 2. 验证点

- 并发请求多时，数据库查询数量显著减少

- 当缓存命中时，响应速度显著提升

- 缓存失效策略（TTL 等）按预期生效

- 高并发情况下是否存在数据不一致或缓存击穿/雪崩问题



## 3. 测试建议

- 正常请求：依次验证在缓存未命中和命中时的响应时间与结果正确性

- 并发请求：使用压力测试工具（locust、JMeter 等）模拟大量请求并观察数据库查询次数与响应时间

- 失效测试：设置短 TTL 并观察缓存自动失效后对系统性能的影响

- 异常测试：故意使缓存服务不可用或网络异常，验证系统能否正常回退到直接查询数据库

随后，我们再将这些详细的提示应用到原项目中，通过AI进一步生成或补全代码，最终大大提高了开发效率和代码准确性。只要前期对项目地图、架构角色和开发规则进行充分准备，我们就能充分借助AI，把原本耗时、易出错的开发流程变得高效且精准。

结语

显而易见，尽管上文主要探讨了大前端领域的AI工作流，但这种思路其实完全可以迁移到其他开发领域。只要我们不断尝试和实践，总结出符合自身业务特点的AI工作模式，就能极大提升我们的工作效率。无论是前端、后端，还是其他技术领域，AI驱动的开发流程都能帮助我们更加精准、高效地解决各类需求和问题。

总之，拥抱AI技术，不断优化工作流程，是我们应对快速变化、不断增长的项目复杂度的关键所在。未来，随着技术的进一步成熟和实践经验的积累，我们必将迎来一个更智能、更高效的开发时代。

你有没有过这样的经历？
没登录淘宝逛了件卫衣，转头刷抖音、B 站，相似款式的推荐就精准找上门；
或者参与线上投票时，明明没注册账号，却提示 同一用户仅能投一次？

其实这背后藏着一个前端人绕不开的实用技术，浏览器指纹。哪怕你开着无痕模式、频繁切换网络，它依然一样精准识别你，而这门技术，不仅是日常上网的隐形推手，更是前端求职面试中的高频考点

一、浏览器指纹：到底是怎么认出你的？

核心逻辑很简单：世界上没有完全相同的浏览器环境，就像没有两片一模一样的树叶。

浏览器指纹会收集一系列设备和环境特征，再通过算法组合成唯一的 哈希值，这个哈希值就是你的专属 网络标识。这些特征包括但不限于：

• 基础信息：浏览器类型及版本 Chrome、Safari 等、操作系统Windows/macOS 等、屏幕分辨率、系统语言；


• 硬件细节：CPU 核心数、内存大小、显卡型号；


• 高级特征：Canvas 绘图差异 不同设备绘制同一图形，像素级有细微区别、WebGL 渲染信息、已安装字体列表；


• 动态信息：IP 地址 虽可变，但结合其他特征仍有识别价值。

举个直观的例子：Canvas 是 HTML5 的绘图功能，我们用一段简单代码就能提取它的指纹可直接在浏览器控制台运行：

function getCanvasFingerprint() {

  const canvas = document.createElement('canvas');

  const ctx = canvas.getContext('2d');

  const text = 'frontend-fingerprint';

  

  ctx.textBaseline = 'top';

  ctx.font = '14px Arial';

  ctx.fillStyle = '#f60';

  ctx.fillRect(0, 0, 100, 60);

  ctx.fillStyle = '#069';

  ctx.fillText(text, 2, 15);

  

  return canvas.toDataURL();

}



function hashFingerprint(str) {

  let hash = 0;

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

    hash = (hash << 5) - hash + str.charCodeAt(i);

    hash |= 0;

  }

  return hash;

}



const dataUrl = getCanvasFingerprint();

const fingerprint = hashFingerprint(dataUrl);

console.log('Canvas指纹结果：', fingerprint);

试着在不同浏览器、甚至不同设备上运行，你会发现每次得到的数值都不一样

这就是浏览器指纹的识别核心。

二、前端人必须掌握的应用场景

浏览器指纹不是 黑科技，而是前端开发、风控、产品设计中高频用到的技术，面试时遇到相关问题，能说清这些场景直接加分：

对于前端求职者来说，这些场景不仅是面试高频题，更是实际工作中可能遇到的开发需求。如果能在简历中体现对浏览器指纹的理解，或在面试中清晰拆解实现逻辑，很容易让面试官眼前一亮 ，但很多同学要么不懂核心原理，要么不知道怎么把技术点转化为面试优势。

四、最后说句实在的

浏览器指纹是前端领域的 实用 技术，懂它不仅能解决实际开发问题，更能成为求职路上的加分项。但求职不止是懂技术，更要会 表达技术， 简历怎么写才能脱颖而出？面试怎么说才能打动面试官？这些都需要技巧和经验。

如果你正在为前端求职发愁，想让自己的技术优势被看到，不妨试试我的「前端简历面试辅导」和「前端求职陪跑」服务。从技术亮点提炼到面试答题技巧，从简历优化到 offer 谈判，我会全程帮你针对性提升，让你在众多求职者中脱颖而出，顺利拿下心仪岗位

大家好，我是 Sunday。

现在，用 AI 写代码，已经不算什么新鲜事了。写个组件、补个函数、改个 Bug，几句话交给模型就能搞定。

但是，大家有没有想过一个问题：如果我不只是用一个 AI，而是用一群 AI，会发生什么？

我们现在用 AI，本质上只是把它当成“高级工具”，即：我遇到问题 → 我问 AI → 它给我答案。

那么如果我们把脑洞放大一点呢？

既然我可以调用一个 AI，那是不是也可以 同时调用多个 AI ？既然 AI 可以写代码，那它是不是也可以完成：产品经理、设计师、测试、运维，甚至是 财务、人事 的工作？

换句话说： 我能不能，用一群 AI，组建一家“只有我一个人类员工”的公司？

多个 AI，各自承担不同角色：

• 产品负责拆需求：告诉产品我的需求，然后产品帮我把需求拆解成可以具体执行的步骤


• 开发负责编码：把具体的步骤告诉开发，开发负责把整个功能落地


• 测试负责验收：开发的代码，交给测试进行验收。验收失败则重新打回开发，开发负责修改 BUG


• 运维负责部署：最终完成的项目，运维负责部署上线，构建整个自动化部署的流程


• 财务负责算账：每天的 token 支出 和 营收，并给出更省钱的财务方案


• 人事负责管理：哪个 AI 员工“不合格”，人事负责把它“开掉”，并根据我的需求重新“招聘（生成）”新的 AI 员工

并且，我还希望它们之间可以独立思考，互相沟通，而我只负责：下目标、做决策。

如果这件事真的可行，那意味着什么？意味着一个人，或许可能真的可以撬动一整家公司级别的生产力。

说干就干。

AI 选择

市面上的 AI 模型已经非常多了：Claude、GPT Coder、Gemini、GLM、DeepSeek。。。有的贵，有的便宜，有的擅长推理，有的擅长编码。

最理想的状态其实很明确：

• 贵的 AI，承担复杂任务：产品设计、系统架构、核心编码


• 便宜的 AI，承担简单任务：统计、对账、流程、输出财务报表

只要这些 AI 之间可以互相沟通，以上这些都不是问题。

但是，Sunday 在经过一系列的测试之后，发现了一个很残酷的事，就是 不同模型的 AI 之间完全无法沟通。特别是不同厂商的 AI，每一个都被作为了独立的个体。虽然可以通过“协调者”方式强行拼接，但是实现复杂，并且效果也不理想。

额。。。好像这个一人公司的梦想就直接破灭了...

不行，不能那么容易放弃。

所以，在第一阶段，我只能选择一个更“粗暴但稳定”的方案：全部使用 Claude。

因为 Claude 提供了一个非常关键的工具：Claude Code：一个运行在纯终端里的 AI 编码智能体。我们只需要打开终端就可以直接通过语言对话的方式调用 AI 模型。

而接下来，我要做的事情是：用 Claude Code，一步步搭出一家“AI 员工公司”的雏形。

启动多个 AI 终端

一个终端窗口作为一个员工，如果我们想要多个员工那么就只需要启动多个终端就可以。然后我们要给他们赋予角色。一开始，我们可以先从最小可行方案开始：

我们先制定两个角色，他们分别是：

• 张三：产品经理


• 李四：程序员

然后，就出现了 大型翻车现场....

在我尝试给 Claude 提示词，让他变成 张三 的时候。Claude 给我的回复是：我是 Claude，我不是张三....

不是，咱说好的玩角色扮演呢...你就这么不配合的吗？

因为在我的设想里，这一步应该是最简单、最“理所当然”的：起个名字、设个背景、分配个角色。然后 AI 就会自动进入对应的工作模式。

结果现实就是这么现实：“我能帮你完成工作，但是我就不承认我是张三，我就是 Claude”

这不是能力问题，这赤裸裸的就是个 态度问题 啊！ 看来 AI 也不想当牛马啊。。。

没办法，我只能尝试修改下提示词：

好的，产品经理已就位。然后我们可以从一个小的 todolist 的需求开始：

现在我们已经有了一个 todolist 的需求文档了。接下来最好的方案就是 产品经理的 AI 可以直接通知 程序员 AI，完成代码实现。

但是，可惜 不同窗口之间 AI 无法直接通讯。所以，我就必须要承担起这个通讯员的角色。

最终实现的效果如下：

整个功能完善、可用。并且还提供了 主题变化 的功能。。。

反思

可是如果我们仔细去分析上面整个流程，我们可以发现：这个流程远没有我们想象的那么顺畅。甚至有点 多此一举。

因为以上这些需求完全可以在一个 Claude code 中完成，没有必要进行这样的划分。甚至可以说：在任务简单时，多 AI 协作不仅没有提升效率，反而增加了沟通成本。

而这样的一种调度+协作的方式，如果任务变得复杂了，恐怕 AI 没有乱呢，我们自己就已经先手忙脚乱了。

这让我开始怀疑：最初设想的这种全 AI 员工的方式，会不会从一开始，就是错的？

但是，当我仔细思考过之后，我发现问题不在于“多角色”这个想法本身，而在于：当前这种“多终端 + 人工调度”的协作方式，本质上是一个非常低效的协作模型。

如果我们换一个角度，从“协作工具”入手，情况可能会完全不同。

这时，我注意到了一个开源项目：vibekanban。

它提供了一种非常典型的多人协作看板模式，和我们熟悉的 Teambition、Jira、Trello 几乎一致，包含了：任务可视化、状态流转清晰、每个角色只关注自己的列

通过 vibekanban 这种工具，我们至少可以做到：多任务并行更清晰、角色边界更稳定、协作过程可追踪、可回溯。

但即便如此，我很快又意识到一个更现实的问题：这，依然离“全 AI 员工的一人公司”，依旧差得很远。

全 AI 员工的难点在哪里？

根据 Sunday 的实验，其实我们可以发现，全 AI 员工的最大难点就是 如何高效的完成 AI 之间的自动协作。

更具体一点说，核心难点只有一个：如何让多个 AI，在几乎没有人工干预的情况下，自动完成“上下文传递 + 状态对齐 + 任务接力”？

那么这个功能可以实现吗？

答案是 绝对可以

学习过咱们的 商业级 AI 课程 的同学都知道，在 AI 的持续对话中，我们可以通过记录上下文的方式完成跨角色的连续对话。

那么同样的道理，如果我们可以记录不同 AI 沟通上下文的 关键内容，然后通过上述的同样逻辑呼叫下一个 AI（让代码通过指令自动传输关键上下文，并调起 AI 服务），那么全 AI 员工的功能就可以实现。只不过在这样的完美的流转过程中，我们还需要做很多的努力才可以。

总结

这一通折腾下来，收获还是很明显的。三个关键：

而这，也意味着：下一阶段的探索重点，已经不再是“哪个模型更强”，而是：如何设计一套真正可自动运行的“AI 组织系统”。

上午刷到32岁程序员周末猝死这条消息，其实我并不陌生。

这几年，程序员猝死、倒下、出事的新闻隔一段时间就会出现一次，圈子里的人早就麻木了。刷到的时候，最多叹口气，继续干活，很少真的往心里去。

看到他长期加班的细节时，我突然愣住了，因为太像了。

我也经常这样。

下午刷到他的妻子和对他的聊天记录，真的感觉很无奈，可惜，他再也回不来了......

我到不是加班，我是下班后干自己的事情，我比较卷。只有下班后的时间是真正属于自己的时间才刚开始。没有人打扰，安静下来，我会干自己的事情、学习、写代码，一不留神就到了凌晨两点。

那一刻，我才真正能进入自己的状态。

学习也好，干活也好，哪怕只是安静地敲键盘，都让我觉得踏实。

于是，凌晨两点成了常态

通过他这件事，我看到我也在里面，看见了自己。

我上一次写代码写到很晚是前几周，老大让我开发一个知识库RAG系统。

给我了我一周的时间，其实对于我是有难度的，因为接触这块不久，一周时间的话肯定弄不好。

后来那天，我连夜和AI 一些协作搞了6个小时左右，搞到了凌晨3点多，初版搞的差不多，那会心率也有点高了， 有点难受，就赶快休息了...

我们这一代程序员，真的太累了。

这种累，不只是加班，而是一种长期被推着往前，却不敢停下来的状态。

房贷在那儿。

家庭在那儿。

未来的不确定性在那儿。

我们很清楚，一旦慢下来，就意味着风险。

于是我们学会了忍。

忍困、忍累、忍身体发出的各种提醒。

程序员这个职业有个很危险的地方。

身体开始出问题的时候，能力往往还在线。

我们还能写代码，还能解决问题，还能在群里回一句：“好的，我看看”

所以你会误以为自己没事。

可身体不是系统，没有明显的报错提示。

等它真正崩的时候，往往没有给你回滚的机会。

今天刷到这个新闻消息对我来说，更像是一次提醒。我现在体检去，估计都是全红状态，我经常熬夜，现在锻炼的也少了....

我们这一代人，很努力。

努力工作，努力赚钱，努力让生活往前走。

可如果连身体都开始透支，那这条路，真的值得重新想一想。

不是他倒下了。

是我们这一代，真的太累了。

略想了一下才发现，自己好像有大半年都没有关注过 TIOBE 社区了。

TIOBE 编程社区相信大家都听过，这是一个查看各种编程语言流行程度和趋势的社区，每个月都有榜单更新，每年也会有年度榜单和总结出炉。

昨晚在家整理浏览器收藏夹时，才想起了 TIOBE 社区，于是打开看了一眼最近的 TIOBE 编程语言社区指数。

没想到，Java 居然已经跌出前三了，并且和第一名 Python 的差距也进一步拉开到了近 18%。

回想起几年前，Java 曾是何等地风光。

各种基于 Java 技术栈所打造的 Web 后端、互联网服务成为了移动互联网时代的中坚力量，同时以 Java 开发为主的后端岗位也是无数求职者们竞相选择的目标。

然而这才过去几年，如今的 Java 似乎也没有了当年那种无与争锋的强劲势头，由此可见 AI 领域的持续进化和繁荣对它的冲击到底有多大。

用数据说话最有说服力。

拉了一下最近这二十多年来 Java 的 TIOBE 社区指数变化趋势看了看，情况似乎不容客观。

可以明显看到的是一个：呈震荡式下降的趋势。

现如今，Java 日常跌出前三已经成为了常态，并且和常居榜首的 Python 的差距也是越拉越大了。

在目前最新发布的 TIOBE Index 榜单中排名前十的编程语言分别是：

• Python


• C++


• C


• Java


• C#


• JavaScript


• Visual Basic


• Go


• Perl


• Delphi/Object Pascal

其中 Python 可谓是一骑绝尘，与排名第二的 C++ 甚至拉开了近 17% 的差距，呈现了断崖式领先的格局。

不愧是 AI 领域当仁不让的“宠儿”，这势头其他编程语言简直是望尘莫及！

另外还值得一提的就是 C 语言。

最近这几个月 C 语言的 TIOBE Index Ratings 比率一直在回升，这说明其生命力还是非常繁荣的，这对于一个已经诞生 50 多年的编程语言来说，着实不易。

C 语言于上个世纪 70 年代初诞生于贝尔实验室，由丹尼斯·里奇（Dennis MacAlistair Ritchie）以肯·汤普森（Kenneth Lane Thompson）所设计的 B 语言为基础改进发展而来的。

就像之前 TIOBE 社区上所描述的，这可能主要和当下物联网（IoT）技术的发展繁荣，以及和当今发布的大量小型智能设备有关。毕竟 C 语言运行于这些对性能有着苛刻要求的小型设备时，性能依然是最出色的。

说到底，编程语言本身并没有所谓的优劣之分，只有合适的应用场景与项目需求。

按照官方的说法，TIOBE 榜单编程语言指数的计算和主流搜索引擎上不同编程语言的搜索命中数是有关的，所以某一程度上来说，可以反映出某个编程语言的热门程度（流行程度、受关注程度）。

而通过观察一个时间跨度范围内的 TIOBE 指数变化，则可以一定程度上看出某个编程语言的发展趋势，这对于学习者来说，可以作为一个参考。

Java：我啥场面没见过

曾经的 Java 可谓是互联网时代不可或缺的存在。早几年的 Java 曲线一直处于高位游走，彼时的 Java 正是构成当下互联网生态繁荣的重要编程语言，无数的 Web 后端、互联网服务，甚至是移动端开发等等都是 Java 的擅长领域。

而如今随着 AI 领域的发展和繁荣，曾经的扛把子如今似乎也感受到了前所未有的压力。

C语言：我厉兵秣马

流水的语言，铁打的 C。

C 语言总是一个经久不衰的经典编程语言，同时也是为数不多总能闯进榜单前三的经典编程语言。

自诞生之日起，C 语言就凭借其灵活性、细粒度和高性能等特性获得了无可替代的位置，就像上文说的，随着如今的万物互联的物联网（IoT）领域的兴起，C 语言地位依然很稳。

C++：我稳中求进

C++ 的确是一门强大的语言，但语言本身的包袱也的确是不小，而且最近这几年的指数趋势稳中求进，加油吧老大哥。

Python：我逆流而上

当别的编程语言都在震荡甚至下跌之时，Python 这几年却强势上扬，这主要和当下的数据科学、机器学习、人工智能等科学领域的繁荣有着很大的关系。

PHP：我现在有点慌

PHP：我不管，我才是世界上最好的编程语言，不接受反驳（手动doge）。

好了，那以上就是今天的内容分享了，感谢大家的阅读，我们下篇见。

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