Let me set the boundary first: this is not a mature product, and it is not a complete public case study yet. The repository, demo, and implementation details are still being organized. What I can share now is the direction, the problem context, the hypothesis I am testing, and the build notes I plan to publish next.

I am writing this down because I increasingly believe the important question for AI agents is not whether they can produce an impressive demo. The question is whether they can complete a piece of work inside a real workflow in a way that is reliable, recoverable, and supervised.

There Is a Gap Between Demos and Work

Many agent demos look impressive. An agent can read files, call tools, write code, generate plans, and simulate a full task chain.

But a working demo is not the same as a reliable system.

Once agents enter a real workflow, the questions become much more concrete:

• Are the task boundaries clear?
• How does context move between agents?
• When a tool call fails, does the system know where it failed?
• Which parts of the state are still trustworthy?
• Should the next step be automatic recovery or human review?
• How is the result verified?

These questions are less flashy than model capability, but they decide whether an agent can move from a one-off demo to a repeatable system.

What I Mean by Digital Employee

By digital employee, I do not mean “a chatbot that sounds more capable.”

I mean a working system:

• It receives a clear work objective.
• It breaks the work into executable steps.
• It calls tools to complete parts of the task.
• It preserves state and recovers from failures.
• It asks for human judgment when uncertainty matters.
• It leaves a trace that can be reviewed and improved.

In other words, a digital employee is not a single model. It is a system made of models, tools, state, protocols, evaluation, and human checkpoints.

The Hard Part Is Not Chat

Chat ability matters, but it is not the part I care about most.

The engineering questions matter more:

1. Coordination protocols: how do agents divide work? Who plans, who executes, and who reviews?
2. Tool reliability: what happens when a tool call fails? When should the system retry, and when should it stop?
3. State recovery: if execution fails halfway through, which intermediate state can still be trusted?
4. Human review: which steps must ask for human confirmation, and which can safely run automatically?
5. Result verification: how does the system know it completed the work, instead of merely appearing to complete it?

None of these problems can be solved completely by a single prompt. They need system design, and they need many small experiments.

Current State

This project is currently active.

I am organizing three directions:

• task boundaries and context handoff between agents
• recovery behavior after failed tool use
• human checkpoints and system boundaries

I have not packaged this as a product, and I have not published a specific repository yet. That boundary matters. If I cannot explain what the system can and cannot do, I should not present it as a finished result.

What I Want to Validate Next

The next step is to clarify the system before showing more interface.

I want to document:

• what the current prototype can actually do
• which steps still require human review
• how the system responds when tool calls fail
• which implementation details can be public
• whether a more specific repository or small demo can be opened

These notes should become part of the build log, not remain private thoughts.

Why This Is Worth Doing Long Term

I believe AI agents will change work not because of one impressive demo, but because many reliability details slowly become stronger:

• clearer boundaries
• recoverable failures
• better human checkpoints
• traceable work
• systems that can be maintained over time

That is also why I am building this site. It is not meant to present a perfect image. It is meant to turn judgment, experiments, and writing into a long-term research system.

The digital employee system is only one experiment, but it will be one of my most important build objects for the next phase.

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

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

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

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

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

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

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

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

我说的数字员工是什么

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

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

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

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

真正难的不是聊天

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

我更关心这些工程问题：

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

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

当前状态

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

我正在整理三个方向：

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

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

接下来要验证什么

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

我会优先整理：

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

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

为什么这值得长期做

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

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

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

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

“Tools should serve thought, not the other way around.”

Why Vite

Vite leans on the browser’s native ES Modules support, so dev mode skips bundling entirely — and startup feels instant. Compared to the traditional Webpack flow, the wins are:

• Cold start drops from seconds to milliseconds
• HMR is essentially instant; the bigger your project, the more obvious the gap
• TypeScript, JSX, and CSS preprocessors work out of the box
• Production builds use Rollup, with smaller output than Webpack

The terminal output below shows what npm run dev looks like — note the 187ms startup:

Vite dev server · cold start in 187ms

Getting started

A single command bootstraps a new project:

1
2
3
4
npm create vite@latest my-app -- --template vue-ts
cd my-app
npm install
npm run dev

Open http://localhost:5173 and you’ll see the default page.

I am not embedding a video demo here yet. If I record a real project walkthrough, I will link it from Elsewhere or add it to the article later.

Common configuration

Here’s the vite.config.ts I keep around:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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
  }
})

Closing

Tools change. The shape of the problem doesn’t. I hope this saves you a few of the potholes I’ve stepped in. Drop me an email if you’ve found a sharper approach — I’d love to hear it.

Written in May 2026. Corrections welcome.

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

为什么选择 Vite

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

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

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

Vite dev server · 冷启动 187ms

快速开始

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

1
2
3
4
npm create vite@latest my-app -- --template vue-ts
cd my-app
npm install
npm run dev

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

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

常用配置

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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 月。如有疏漏，欢迎指正。

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

命名是第一道关

1
2
3
4
5
6
7
// 不好
function f(x, y) { return x.filter(i => i.s === y); }

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

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

抽象层级要一致

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

写给未来的自己

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

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

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

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

小结

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

终端 & Shell

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

编辑器

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

必装的命令行工具

快捷键

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

小结

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

你以为你懂，其实你不懂

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

但你知道吗？

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

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

印象最深的一段

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

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

推荐指数

★★★★★

适合所有「写过几年代码但从没认真想过底层」的人。 准备好一杯咖啡和几个安静的晚上。

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

基本用法

1
2
3
4
5
6
7
8
9
10
11
12
13
/* 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% 的媒体查询。

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

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.」

读累了就抬头看看天。

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

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

简单不是少做

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

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

1
2
3
4
5
6
7
8
9
// 字符少，但概念多
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);
}

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

简单的本质是「克制」

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

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

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

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

小结

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

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