Benjamin Taoson · 赖建铭 · 中文

我为什么在构建数字员工系统

2026-06-05T10:00:00+08:00

我正在构建一个数字员工系统。

先把边界说清楚：它目前不是成熟产品，也不是已经公开的完整项目案例。具体仓库、演示和实现细节还在整理中。现在可以公开的是方向、问题背景、我正在验证的假设，以及接下来准备补充的构建记录。

我之所以要把这些写出来，是因为我越来越觉得，AI 智能体最重要的问题不是“能不能做一个惊艳演示”，而是：它能不能在真实工作流里稳定、可恢复、可监督地完成一段工作。

演示和工作之间有一道鸿沟

现在很多智能体演示看起来都很强。它可以读文件、调用工具、写代码、生成计划，甚至模拟一个完整任务链。

但演示能跑，不等于系统可靠。

真正进入工作流以后，问题会变得具体很多：

任务边界是否清楚？
上下文在多个智能体之间如何交接？
工具调用失败后，系统知道失败在哪里吗？
哪些状态仍然可信？
下一步应该自动恢复，还是交给人确认？
结果如何被验证？

这些问题看起来不如模型能力本身耀眼，但它们决定了智能体能不能从一次性演示变成可反复运行的系统。

我说的数字员工是什么

我说的数字员工，不是“一个更会聊天的机器人”。

我更关心的是一个工作系统：

它能接收一个明确的工作目标。
它能把工作拆成可执行步骤。
它能调用工具完成部分任务。
它能在失败时保留状态并恢复。
它能在不确定时请求人类判断。
它能留下过程记录，方便复盘和改进。

换句话说，数字员工不是单个模型，而是模型、工具、状态、协议、评估和人在回路共同组成的系统。

真正难的不是聊天

聊天能力当然重要，但它不是我最关心的部分。

我更关心这些工程问题：

协作协议：多个智能体之间如何分工？谁负责计划，谁负责执行，谁负责检查？
工具可靠性：工具调用失败后如何重试？什么时候停止重试？
状态恢复：执行到一半失败，哪些中间状态可以继续用？
人工确认：什么环节必须让人确认？什么环节可以自动完成？
结果验证：系统如何知道自己做对了，而不是只是“看起来完成了”？

这些问题没有一个能靠一句提示词彻底解决。它们需要系统设计，也需要大量小实验。

当前状态

目前这个项目处在持续构建阶段。

我正在整理三个方向：

智能体之间的任务分工和上下文交接。
工具调用失败后的恢复机制。
人在回路的确认点和系统边界。

我还没有把它包装成产品，也没有公开具体仓库。这个边界很重要：如果我还不能清楚说明系统做到了什么、没做到什么，就不应该把它说成成熟成果。

接下来要验证什么

下一步，我想先把系统说明补清楚，而不是急着展示更多界面。

我会优先整理：

当前原型到底能完成什么。
哪些环节仍然需要人类确认。
工具调用失败时系统如何响应。
哪些实现细节可以公开。
是否能开放一个更具体的仓库或小型演示。

这些内容会进入构建记录，而不是只留在脑子里。

为什么这值得长期做

我相信 AI 智能体真正改变工作方式的时刻，不会来自某个炫酷演示，而会来自很多可靠性细节慢慢变稳：

边界更清楚。
失败更可恢复。
人类介入点更合理。
工作过程更可追踪。
系统能被长期维护。

这也是我建设这个网站的原因。它不是为了展示一个完美形象，而是为了把判断、实验和写作沉淀成一个长期研究系统。

数字员工系统只是其中一个实验，但它会成为我接下来一段时间最重要的构建对象。

使用 Vite 搭建现代化前端项目

2026-05-20T10:00:00+08:00

这篇记录我如何用 Vite 搭一个干净、快速、可维护的前端实验环境。它不是完整框架教程，而是一份偏实践的项目初始化笔记。

「工具应该服务于思想，而不是相反。」

为什么选择 Vite

Vite 利用浏览器原生的 ES Modules 能力，开发时无需打包，启动速度极快。相比传统的 Webpack，它在以下几个方面有明显优势：

冷启动时间从「秒级」缩短到「毫秒级」
HMR（热更新）几乎是即时的，文件越多优势越明显
开箱即用支持 TypeScript、JSX、CSS 预处理器
生产环境用 Rollup 打包，输出更精简

下面这张图是 npm run dev 启动后的终端输出示意，注意那个 187ms 的启动时间：

Vite dev server · 冷启动 187ms

快速开始

用一行命令就能创建一个新项目：

npm create vite@latest my-app -- --template vue-ts
cd my-app
npm install
npm run dev

就这么简单。打开 http://localhost:5173，你就能看到默认页面了。

这篇文章暂时不放视频演示。等有真实录制的项目过程，再补到外部发布或文章里。

常用配置

下面是我常用的 vite.config.ts 配置：

import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
import { fileURLToPath, URL } from 'node:url'

export default defineConfig({
  plugins: [vue()],
  resolve: {
    alias: {
      '@': fileURLToPath(new URL('./src', import.meta.url))
    }
  },
  server: {
    port: 3000,
    open: true
  }
})

小结

工具会变，但解决问题的本质不会。希望这篇文章能帮你少踩一些坑。如果你有更好的实践，欢迎给我发邮件交流。

本文写于 2026 年 5 月。如有疏漏，欢迎指正。

代码可读性的本质是什么

2026-05-12T14:30:00+08:00

为什么有的代码读起来像散文，有的却像加密电报？

写代码这么多年，我越来越觉得，代码的可读性，本质上是「认知负担」的问题¹——读者每读一行，要在脑子里维护多少状态？

命名是第一道关

// 不好
function f(x, y) { return x.filter(i => i.s === y); }

// 好
function findUsersByStatus(users, status) {
  return users.filter(user => user.status === status);
}

短变量名节省了打字时间，但偷走了未来读者的时间——而后者通常是几十倍的代价²。

抽象层级要一致

一个函数里，如果一会儿在做高层级的业务编排，一会儿又在做底层的字节操作，读者就得不停地切换视角，非常累。

写给未来的自己

我的一个习惯：在每个稍复杂的函数前，写一句话告诉未来的自己「这是什么、为什么」。

不是注释每一行（那是糟糕的注释），而是告诉读者「上下文」。

# 因为后端在 v2 之前会返回字符串型的 ID，
# 这里强制转 int 以保证前后端类型一致
user_id = int(payload.get('id'))

这种注释，写代码的人自己半年后回来看都会感谢自己。

小结

可读性不是「好看」，而是「下一个人接手时的痛苦最小化」。而那个「下一个人」，大概率就是几个月后的你自己。

「认知负担」是 John Sweller 1988 年提出的概念，原指学习者处理新信息时占用的工作记忆容量。代码上下文也遵循同一规则：人类工作记忆约能维持 4±1 个组块。变量名差、缩进乱、抽象层级跳跃，都会让组块数迅速超载。 ↩
Robert C. Martin 在《Clean Code》里提到，代码”读”与”写”的时间比是 10:1 以上。意味着任何让”读”变快的微小投入，回报率都是正数。 ↩

我的 Mac 工作流配置 2026

2026-04-28T20:00:00+08:00

每年我都会写一篇当下的工作流配置，一是给自己留个备份，二是分享给可能感兴趣的朋友。

终端 & Shell

终端：Ghostty —— 速度极快、配置即代码
Shell：zsh + oh-my-zsh
提示符：Starship —— 跨 Shell 通用
复用：tmux + tmuxinator

编辑器

主力：VS Code（Vim 插件 + Copilot）
轻量编辑：Helix（终端里直接 hx）
写作：Obsidian + iA Writer

必装的命令行工具

工具	替代了什么
`bat`	`cat`
`eza`	`ls`
`fd`	`find`
`rg`	`grep`
`zoxide`	`cd`
`fzf`	所有需要模糊搜索的场景

快捷键

最近发现一个超好用的：用 Karabiner 把 CapsLock 改成”按下是 Escape，长按是 Ctrl”。适配 Vim 用户来说，效率提升至少 30%。

小结

工具是为人服务的，不要陷进去为了配置而配置。我每年都会忍痛删掉一些「装了但没怎么用」的工具——保持轻量很重要。

读《程序员的自我修养》有感

2026-04-15T21:00:00+08:00

写代码很多年，直到读了《程序员的自我修养——链接、装载与库》，我才第一次真正「看见」代码是怎么变成可执行程序的。

你以为你懂，其实你不懂

我以为我懂编译：源码 → 编译器 → 可执行文件。

但你知道吗？

链接器 才是真正决定符号位置的人
重定位 是为了让代码在任意地址都能跑
动态链接 让多个程序可以共享同一份代码

这些底层细节，决定了你写的 printf 到底是怎么被调用的。

印象最深的一段

内存中的程序和磁盘上的程序，看起来都是一堆字节，但它们之间的鸿沟，需要操作系统、编译器、链接器、加载器配合无间地才能跨越。

读到这里，我突然对每一个能跑起来的程序，都有了一种新的敬畏。

CSS 容器查询完全指南

2026-03-30T16:00:00+08:00

很长一段时间，”响应式设计”约等于”媒体查询”。但媒体查询有个根本问题： 它只能根据视口（viewport）来响应，而不是组件所在的容器。

容器查询（Container Queries）解决了这个问题。

基本用法

/* 1. 把父元素声明为容器 */
.card-wrapper {
  container-type: inline-size;
  container-name: card;
}

/* 2. 根据容器宽度调整子元素 */
@container card (min-width: 400px) {
  .card {
    display: grid;
    grid-template-columns: 1fr 2fr;
  }
}

注意，这个查询关心的不是浏览器窗口宽度，而是 .card-wrapper 的宽度。

为什么这是革命性的

想象一个 <UserCard> 组件，它可能出现在：

侧边栏（窄）
主内容区（宽）
模态框（中等）

用媒体查询，你只能基于整个页面的宽度决定它的布局，但同一个页面里，同一个组件可能既在侧边栏又在主区域—— 这时容器查询才是唯一的解法。

浏览器支持

到 2026 年，所有主流浏览器（Chrome、Safari、Firefox、Edge）都已经稳定支持。可以放心使用了。

容器查询配合 CSS Grid 的 auto-fit/auto-fill，几乎可以让你扔掉 99% 的媒体查询。

周末骑行去山里

2026-03-18T18:00:00+08:00

周末看天气预报说连续两天晴，于是临时决定骑车去山里。

清晨五点出发，避开城市的车流。一路向北，沿着河道骑行，空气里有早春的草木气息，自行车链条偶尔吱呀一声，整个世界安静得只剩下风的声音。

40 公里之后，到了一片半山腰的露营地。

露营装备

单人帐篷（1.2 kg）
充气垫 + 羽绒睡袋
小折叠桌、马扎
摩卡壶 + 小炉子
一本翻不完的书

我带的是 Hannah Arendt 的《人的境况》。说实话，这本书躺在我书架上三年了，每次想读都被工作打断。

这次终于读完了第一章。

山里的下午

下午没什么事，就煮了一壶咖啡，坐在小马扎上看着远处的山。

「Action, the only activity that goes on directly between men without the intermediary of things or matter, corresponds to the human condition of plurality.」

读累了就抬头看看天。

第二天早上回来的时候，腿肌酸痛，但脑子从未如此清晰过。

我们需要离开屏幕的时间，比想象中更多。

工程实践中，为什么保持简单这么难

2026-02-22T22:00:00+08:00

工程实践中，我反复遇到一个问题： 「保持简单」比想象中难得多。

简单不是少做

刚入行的时候，我以为简单就是「代码少」。所以我会用一堆三元表达式、箭头函数、链式调用，把十行代码压缩成一行。

后来才明白，简单不是「字符少」，而是「概念少」。

// 字符少，但概念多
const result = items.reduce((a, b) => a.set(b.k, (a.get(b.k) || 0) + 1), new Map());

// 字符多，但每一步都清楚
const counts = new Map();
for (const item of items) {
  const current = counts.get(item.k) || 0;
  counts.set(item.k, current + 1);
}

后者多了几行，但读的时候不需要”解码”，反而更”简单”。

简单的本质是「克制」

写代码时，一个值得反复练习的能力，是判断「不做某些事」：

不做过度抽象
不做超前设计
不引入用不上的依赖
不为了优雅而牺牲清晰
不在还没需求时就准备好「扩展点」

每一次克制都需要勇气，因为它意味着—— 当未来真的有需求时，可能要返工。

但十次假想的扩展性需求中，真正发生的可能只有一两次。为这一两次提前付出的”复杂度税”，往往得不偿失。

小结

简单 = 克制 + 清晰 + 谦逊。

谦逊指的是：承认你不知道未来会怎么变。