Code Plato

Agent Skill 制作手册 01：入门篇

Thu, 28 May 2026 00:00:00 +0000

Agent Skill 制作手册是一个系列教程。这是第一篇。

什么是 skill

很多程序员问，Agent Skill 是什么？我敢说，Agent Skill 是你们学习编程以来能学到的最简单的技术之一。

skill 是怎么发展出来的

就像跟人一起工作一样。你有一个新入职的同事，就算他技术再好，也总要先看一些你们公司的 how to 文档，才能开始做事。人们发现，跟 LLM 工作也有同样的模式。你让 LLM 直接做事情，那多半会做出一件偏离你预期的漂亮事，这就很尴尬了。

然后就有人发现，如果先在提示词里面加上做事情的步骤，LLM 就做得好。所以大家就一直给 LLM 喂 how to 手册。

但是 LLM 的上下文有限啊，而且你每次塞这么多上下文，你的钱包先爆了。于是人们又想，其实我们自己工作的时候也记不住 how to 的内容。我们大概记得有那么个 how to 教了我做这件事情，但具体内容不记得了。没关系啊，我们到时候再去 wiki 看看不就得了。那我们也可以让 LLM 只记住这个 how to 是做什么的，具体需要的时候再看呗。于是我们可以把每一个 how to 的描述喂给 LLM，LLM 看描述就知道，需要做事情的时候要找哪个 how to 了。

到这里，我们已经可以推导出一个简单的、给 LLM 量身定做的 how to 了。它只有两个重要属性：name 和 description，剩下的就是正文了。每次加载只加载 name 和 description，LLM 自己会判断是否需要读取这个 how to 的正文。

这就是 skill。其实这个东西叫什么不重要，它可以叫 howto、guide、manual 都可以，但是大家觉得 skill 这个名字够短、好记，还自解释，就用它了。可能在别的平行宇宙里，它叫 guide。

skill 是哪家的？

这种 SKILL.md 形态的 Agent Skill，最早是 Anthropic 系统公开推广的；但 skill 这个词和"让 AI 学技能"的思想并不属于某家公司。OpenAI、OpenClaw、Hermes Agent 都有自己实现的 skill。这只是一个概念，各家有各家自己的实现，这些实现在细节上有些区别，但都是指同一个事情。

怎么写 skill

skill 通用规范

各家的 skill 规范的共同点是：skill 是一个文件夹。结构是：

my-skill/
 SKILL.md # 必须：元数据 + 指令
 scripts/ # 可选：可执行脚本
 references/ # 可选：文档、说明、规范

而其中的 scripts、references 都不是必须的，只是大家习惯的一种最佳实践而已。最重要的是 SKILL.md。有的 skill 只有这一个文件，而这个文件的结构也很简单。

一个最小的 SKILL.md，在元数据层面只需要 name 和 description。正文可以很短，但最好写清楚 agent 被触发后到底要做什么。

---
name: skill的名字
description: 解释这个skill是干嘛的，什么时候应该被触发，什么时候不应该被触发等
---

当你的 skill 比较复杂，需要一些结构化的数据和逻辑的时候，就可以考虑建立 scripts 文件夹，然后在里面写代码。当你的 skill 引用的文档比较多，你怕把上下文给撑爆了，就可以把大部分文档移到 references 里面。

写一个 skill

来动手写一个 skill 吧。我保证这是你看到的最短的教程。这个 skill 会在你说三次 Hello 的时候回复三个 World。新建 SKILL.md，并在里面写：

---
name: hello-world
description: 当用户说三次"Hello"（例如"Hello Hello Hello"）时，回复三次"World"："World World World"。
---

# Hello World

当用户的消息中包含恰好三个"Hello"时，只回复：

World World World

不说其他任何内容，只有这三个字。

然后安装到你的 AI agent 里面。你问我怎么安装？这都什么年代了，你问你自己的 AI agent 怎么安装，它自会告诉你的。

安装好后就试试吧。

skill 规范

Codex、Claude Code、OpenClaw、Hermes Agent 它们都对 skill 有自己的一些细节上的规范，我就不在此赘述。不过有几点我觉得有必要提。

Skill 防触发机制

基本上，是否触发 Skill 是看 LLM 自己决定的。这其实带来另外一个问题，就是 skill 经常被误触发，或者不被触发。对此各家都有各自的措施。

禁止自动触发，但允许手动触发
- Claude / OpenClaw: disable-model-invocation: true
- Codex: agents/openai.yaml 里的 allow_implicit_invocation: false
彻底禁用 skill
- Codex: [[skills.config]] enabled = false
- OpenClaw: skills.entries.<skillKey>.enabled = false

从这里可以看出，skill 的优点在于自由，但缺点也是自由。有时候你想触发，却触发不了；不想触发，它却一直被触发。不过在之后的教程中我会介绍一些范式来解决这个问题。

Skill 的分类

在 skill 慢慢被越来越多的人使用后，skill 也开始出现一些分类方式。

skill 和 command

在 OpenClaw 和 Claude 桌面版中，skill 是可以用斜杠（/）调用的。区别在于，在 Claude 桌面版中，你安装了 Skill 后，按 / + <skill名> 就可以触发 skill；而在 OpenClaw 中，你是通过设置 user-invocable: true 来让这个 skill 可以用斜杠触发的。

在 OpenClaw 里，一部分 skill 可以被暴露成 slash command。command 是调用方式，不一定是独立分类。这就引发了一个有趣的思考：当你建立一个新 skill 的时候，你可以思考一下，你这个 skill 是一个普通的 skill，还是一个 command。毕竟在手机上找到斜杠，并不像在电脑上这样容易。有些生活类的 skill，你可以依赖 LLM 去猜测；而有些需要精确被触发的，就可以用斜杠。

工作流式和应用式

你会发现，有些 skill 仅仅只是定义了一件事情该怎么做，而有些 skill 更像是一个你自己定义的 app。定义了该怎么做的，可以被称为工作流式。

比如你让 LLM 帮你归纳一下会议纪要。这样的 skill 就只需要 SKILL.md 就够了。如果流程比较复杂，那就把流程抽取到 references 里面。
如果是应用式的，比如你要做一个购物清单，你需要比较复杂的逻辑和比较规范的数据存储。你就需要将某些逻辑抽取出来写成 scripts。但是 scripts 不是越多越好，只有需要确定性行为或外部工具时才用 scripts。

AI时代，还有必要练习编程吗？

Mon, 25 May 2026 00:00:00 +0000

AI时代已经开始流行所谓的 “Vibe Coding” 了，那么还有必要练习编程吗？

我认为，还是有必要的。

虽然我之前写过一篇文章，提到可以利用 AI 来帮助精炼阅读内容、快速理解文章结构，但有几个现实问题并不会因为 AI 的出现而改变。

人脑单位时间内能够学习到的知识量，其实并不会改变。简单来说，无论未来 AI 技术发展得多快，你学习知识的速度并不会同步变快。学习本身并没有真正的捷径。
AI 在训练时，既学习了好的代码，也学习了坏的代码。有时候坏代码不一定是"错误代码"，它可能只是充满坏味道、难维护、架构混乱的代码。如果你自己看不出来问题，那么 AI 往往也看不出来。

例子1

很多东西，有经验的人第一眼看过去，和没有经验的人看到的是完全不同的。

比如在 React 中，当你看到这样一段代码：

const phone = {
 name: 'iPhone',
 price: {
 payInFull: 1000,
 monthlyFin: 99
 }
};

某天，产品经理让你增加一个"快照页面"。这个页面需要展示商品当前状态的一个快照，即使商品后续状态发生变化，快照页面里的内容也不应该改变。

AI 很快帮你生成了这样一段代码：

const phone = {
 name: 'iPhone',
 price: {
 payInFull: 1000,
 monthlyFin: 99
 }
};

<Snapshot {...phone} />

你看到 {...phone}，心里想：

“这个我懂，不就是对象拷贝吗？”

结果没过多久，客服部门报告了一个 Bug：在父组件内修改价格后，快照页面里的价格竟然也一起改变了。

你非常困惑，觉得这不应该发生。

经过研究后，你发现：

<Snapshot {...phone} />

并不等于：

const snapshot = {...phone}

前者只是 React 的一种 props spread 语法糖。

于是你修改了代码：

const phone = {
 name: 'iPhone',
 price: {
 payInFull: 1000,
 monthlyFin: 99
 }
};

const snapshot = {...phone};

<Snapshot {...snapshot} />

结果还是不行。

后来你才发现，真正需要的是：

const snapshot = structuredClone(phone);

如果是曾经踩过类似坑的人，或者真正认真学习过 JavaScript 对象引用机制的人，往往一眼就能看出问题所在。

例子2

你有没有过这样的经历：

看教程的时候，感觉什么都会；真正开始自己写的时候，却一个字都写不出来。

我前段时间在学习一门 Data Science 课程。课堂上老师讲的内容，对于一个工程师来说其实并不复杂。

top1 = Table.read_table(path_data + 'top_movies_2017.csv')

但当我真正开始做作业时，题目要求我读取 top_movies_2017.csv，我却突然大脑一片空白。

我不断尝试：

read_csv
import_csv

等等各种可能的方法。

但奇怪的是，这个 Table.read_table 我明明在课本上看过很多遍。

后来我意识到，人脑学习知识的方式并不仅仅是"阅读"。学习往往是多种感官共同参与的过程。

可能有听觉，有触觉，有遇到挫折后的思考，还有不断尝试与失败的过程。而这些过程本身，其实也是记忆的一部分。

很多知识，并不是"看懂了"就真的学会了。

总结

虽然 AI 可以帮助我们快速提炼文章纲要、总结重点，但它更多只是给了我们一张地图。

它可以帮助我们跳过一些暂时不感兴趣的内容，避免把时间浪费在不重要的部分。

但我们必须清醒地认识到：

如果你学习知识本身的速度并没有真正变快，那么也不要轻易相信"AI时代普通人也可以编程"这种过度乐观的话。

“普通人可以生成代码”，并不等于"普通人可以写出可维护的商业产品"。

AI 可以帮助你加速。

但它无法替代你真正理解系统、理解代码、理解工程复杂性的过程。

AI时代应该怎么写代码：督导和编排

Wed, 20 May 2026 00:00:00 +0000

程序员的迷茫

程序员这个行业从来没有像现在这么迷茫过。我看到太多不同的说法：

有个老板要求员工的 AI 写代码率必须超过 70%
有的人手写代码，然后让 AI 来写单元测试、做测试
有人在面试时被问到是否用过 Claude Code，会觉得很生气
有人说 vibe coding 是一场赌博
有人说程序员要失业了，我们不再需要程序员了
有人说只要用 TDD、BDD 写出来的项目就会很稳定
有人说 AI 写出来的代码，测试都能通过，但实际一运行就挂掉
有人说 AI 编程是个骗局，只是各大厂商为了卖 token 的营销手段

2 个坏消息

其实这些说法都对了一部分，也错了一部分。我想说两个坏消息：

Cursor 会死，JetBrains 会死，甚至 Copilot 也会死，几乎整个 IDE 产业最后可能都不存在
虽然已经裁了很多程序员了，但裁得还不够

我不喜欢坏消息，但我也不喜欢假装一切都很好。这就像你明明有重大疾病，却不去体检一样。这样只会害了你。

AI 编程的极限

这几个月 AI 编程领域高歌猛进。看起来它似乎是无敌的，最终会统治世界。确实，我们现在对 AI 编程的开发还远远没有到极限。

但是，AI 编程是有极限的。

我们要知道，我们现在用来编程的 AI，其实不是 AGI。我们既然是专业人士，就不要再用"AI"这个笼统的词了。我们真正使用的是大语言模型（LLM）。

大语言模型的工作原理，本质上是预测下一个 token。这跟抽象思维、大局思维、创造力并不是一回事。

所以，大语言模型有几个非常致命的问题：架构偏移、软件熵增、上下文困境、token 滥用。

架构偏移：如果你让 LLM 长时间独立完成一件事情，它最终可能会偏离轨道，走到一个你完全想不到的方向。
软件熵增：如果你让 LLM 自己写一个大型项目，最终很可能会生成屎山代码。实际上甚至不需要大型项目，只要让它写一个稍微复杂一点的模块，都可能出现代码质量失控。我甚至发现，让它帮我写一个类的单元测试，它也能写出屎山代码。
上下文困境：当上下文过长时，LLM 的工作效率会明显下降，因为过长的上下文会让它"分心"。于是你会陷入两难：压缩上下文，会丢失信息；不压缩上下文，LLM 又几乎无法高效工作。你当然可以通过摘要、归档以及渐进式披露来缓解这个问题，但代价就是性能下降。LLM 每做一次修改，都可能需要思考很久。
token 滥用：这是一个非常现实的问题。token 是要付费的，而且并不便宜。你没有无限的 token 可以挥霍。但由于缺乏监管的 AI 容易写出糟糕的逻辑和单元测试，最终会导致你修改逻辑时的 token 消耗越来越高，让维护成本变得越来越昂贵。

程序员的作用

程序员不会失业，但"写代码的程序员"这个职业会逐渐消失。

写代码的方式会彻底改变，而且会分成两个阶段：督导和编排。

督导

有人问，用 AI 写代码的比例多少比较合适。

我的答案是：100%。

当人类开始使用拖拉机播种之后，人工播种的比例是多少？是 0%。

用了 AI 写代码之后，人类已经没有必要继续用缓慢、而且容易拼写错误的方式手写代码。你真正要做的事情，是"督导"。

督导的作用，就是克服 LLM 的那 4 个核心问题。

程序员的大部分时间，将不再是写代码，而是审核 AI 写的代码、提出修改意见，并防止 AI 下次再犯同样的错误。或者指导 AI 用更好的实践去管理代码。

所以，设计模式、代码整洁、代码品味、重构、如何写好的单元测试——这些以前看起来很高级的东西，现在会变成基础能力。

原因很简单，不是为了"优雅"，而是为了一个很现实的目标：

写出可维护、bug 更少、并且节省 token 的代码。

IDE 的终结

但这样一来，其实已经不太需要传统 IDE 了。

因为 IDE 本质上是为了"人类写代码"而诞生的。

如果 AI 写的代码不会出现低级错误，也不需要 auto-complete，而人类自己又不再直接写代码，那么 IDE 中那些辅助人类编写代码、重构代码的功能，其意义就会大幅下降。

未来也许还会有 IDE，但会是非常轻量级的 IDE：秒开、功能简单，只保留一些最基础的能力。

而且这种东西很难再形成高利润产业，因为它太简单了，最终一定会出现大量开源、免费的替代方案。

就像胶卷和录像带租赁行业一样，这个产业最终会逐渐消失。

编排

单独开一个 agent 写代码，效率其实还是不够高。

你可以回忆一下，当你拿到一个新的 requirement 时，你是怎么工作的。

你肯定不是直接开始写代码。

你会先细化需求、设计实现方案，有时候甚至还需要先做 POC 验证方案，然后才开始真正写代码、测试功能。

所以，最终整个软件开发流程都会 AI 化。

但由于上下文问题的存在，又无法让一个 agent 完成所有事情。

注意：这并不是"上下文长度限制"这种可以单纯靠技术升级解决的问题，而是 LLM 工作原理本身带来的限制。

所以，未来真正的开发环境，很可能会变成一个完整的 AI 工作流。

整个工作流中，会有多个不同角色的 AI 工作者：

开发方案设计者 + N 个开发者 + 测试方案设计者 + N 个测试者

之所以没有"需求分析者"这个角色，是因为这部分最好仍然由人类亲自完成。

因为需求分析只要偏移一点点，后面的整个架构就可能彻底偏掉。

但这个工作流并不是搭建完就没事了。

因为如果你让它自己无限制地运行，它绝对会耗费大量 token，最终给你生成一个不可维护的屎山代码库。这就是架构偏移。

虽然 OpenAI 和 Anthropic 都在研究长时间运行的 AI 项目开发，但你可以把这些研究理解成"实验室中的理想环境"。

它们不需要太在意 token 消耗，但你需要。

而且我相信，它们所谓的"长时间运行项目"，本质上也是有督导存在的。人工需要不断增加规则、纠正 AI 的工作方式。

这其实也就是现在越来越多人提到的 Harness Engineering。

于是，程序员最终的工作，就会变成：

搭建、调试并使用这个 AI 工作流。

因为你仍然需要督导 AI。

总结

因为 LLM 在原理上存在一些暂时无法解决的问题，所以程序员这个职业，短时间内仍然会以另一种形态继续存在。

直到真正的 AGI 出现的那一天。

但我还是希望大家尽快开始转型，否则很可能会被这个时代淘汰。

实例讲解什么是上下文治理

Tue, 19 May 2026 00:00:00 +0000

上下文治理（Context Governance）是上下文工程（Context Engineering）中的一个部分。但我觉得，上下文治理是上下文工程里最有意思的部分。

光这么说，你肯定会像我一开始一样，觉得这个概念很抽象。但是，如果你跟我一样，了解了几种主流智能体（Agent）的上下文治理之后，你一定会对"上下文治理"有一个非常直观的理解。

接下来，我会通过比较 4 种智能体的上下文治理方式，让你直观地理解什么是上下文治理。以下四种工具的上下文治理，从简单到复杂、从低级到高级。

Codex

首先是 OpenAI 的 Codex。虽然 OpenAI 是第一个做出 LLM 的公司，但是它们的智能体产品反而最年轻。

虽然它最年轻，但它的上下文治理也是最简单的。在 .codex/ 目录下，有一个叫 AGENTS.md 的文件。这是一个简单的 AGENTS.md 文件示例：

# 仓库规范

## 项目结构
- `src/` 存放应用代码
- `tests/` 存放测试代码

## 常用命令
- 运行测试：`npm test`
- 运行代码检查：`npm run lint`

## 编码规范
- 优先使用 TypeScript
- 避免使用 default export（默认导出）
- 使用 async/await，而不是直接使用原始 Promise

Codex 在开始工作之前，会先读取这个文件的内容。这个文件需要你手动维护，不断往里面添加规则。

除了这个文件以外，还有一个文件夹：~/.codex/memories/ 顾名思义，就是"记忆"。Codex 会自动往里面写文件。

大概的结构如下：

类型	可能内容
summaries	session 摘要
durable	长期稳定记忆
recent	最近上下文
evidence	来源证据

可以看到，Codex 的上下文治理其实非常轻量。

它本质上还是：

一个规则文件
一个自动记忆目录

仅此而已。

Claude Code

Claude Code 的上下文治理很特别。

官方支持的其实跟 Codex 差不多：

CLAUDE.md
~/.claude/projects/<project>/memory/

就这两个东西。你一看名字基本就懂了。但是，Claude Code 的社区自己增强了它的上下文治理，逐渐演化成了这样：

名字	类型	作用	人工/自动
`CLAUDE.md`	文件	项目规则、Agent 行为规则	人工
`MEMORY.md`	文件	长期记忆、长期偏好、长期经验	半自动
`NOTES.md`	文件	临时工作笔记、scratchpad	人工
`DECISIONS.md`	文件	关键架构/技术决策历史	人工
`ARCHITECTURE.md`	文件	系统结构、模块关系、数据流	人工
`LEARNINGS.md`	文件	踩坑经验、经验总结	半自动
`TASKS.md`	文件	当前任务列表、待办事项	人工
`SESSION.md`	文件	当前 session 工作记录	半自动
`docs/`	文件夹	长文档上下文来源	人工
`memory/`	文件夹	memory 分类存储	半自动
`prompts/`	文件夹	prompt 模板、workflow prompt	人工
`.cursorrules`	文件	Cursor 兼容规则	人工

这下就比 Codex 复杂很多了。但是你会发现，这里面有大量文件都需要人工维护。而且整个结构特别像我们以前做项目时写的 Wiki 文档结构。

其实，为了让 Agent 更好地工作，它也应该像我们一样，先看看项目 Wiki。人们现在只是把 Wiki 文档，变成了上下文 Markdown 文件而已。这样理解就很容易了。Claude Code 在这些上下文文档的基础上，工作的方式越来越像一个真正的程序员。

Open Claw

Open Claw 的定位跟 Claude Code 不太一样。它更偏向生活助手。而且 Claude Code 社区版的上下文治理，需要管理的文件太多了。不同于 Claude Code，Open Claw 的用户更多是普通人。很多用户其实并不会直接编辑 Open Claw 的上下文文件，甚至都不知道这些文件需要人工维护。

但是，Open Claw 的上下文设计其实比 Claude Code 社区版更"Agent 化"。因为 Claude Code 社区版的上下文结构，还是带有很强的人类项目管理思维。但在 Agent 面前，其实并不一定需要拆成那么多文档。

Open Claw 的上下文治理更偏向"角色"和"人格"。它有这些上下文文件：

核心指令层（静态，你手动维护）

SOUL.md — 人格、价值观、边界。回答"你是谁"。定义语气、性格、不可违反的约束。
AGENTS.md — 操作流程和规则。回答"你做什么、怎么做"。最大也最重要的文件，放复杂工作流和步骤化指令。
USER.md — 用户信息。你的名字、时区、偏好、工作背景。相当于个性化层。
IDENTITY.md — 结构化身份档案（名称、角色、目标、语气）。用于一致性地重新应用已知身份。（其实我觉得这个有点多余。）
TOOLS.md — 工具文档。不控制权限（权限是 config 管的），而是告诉 Agent 如何使用已有工具。

自动化层

HEARTBEAT.md — 定时任务，相当于用自然语言写的 cron。比如"每 30 分钟检查一次"“每周一 8 点生成报告”。
BOOTSTRAP.md — 首次运行的初始化脚本。setup 完成后会自动删除。
BOOT.md — 每次启动时执行的 hook。

记忆层

MEMORY.md — 长期记忆。持久化的事实、偏好、决策摘要，跨周跨月生效。
memory/YYYY-MM-DD.md — 每日笔记。当天和昨天的笔记自动加载，更早的内容通过 memory_search 检索。
DREAMS.md — dreaming 系统的日记，记录从短期记忆向长期记忆的"晋升过程"，供人类审阅。这是一个实验性功能。

可以看出，Open Claw 已经比前两个系统复杂很多了。所以你在使用 Open Claw 的时候，会明显觉得它"更聪明"。

Hermes Agent

接下来就是重头戏了。如果你不理解上下文治理，你可能会觉得 Hermes Agent 跟 Open Claw 没什么区别。但不知道你有没有发现：Open Claw 里仍然有很多文件需要你手动维护。

甚至就算是我，用了这么久 Open Claw，也是最近才知道这些文件需要人工维护。这就导致 Open Claw 设计的很多上下文，其实一直都没有真正被使用起来。Hermes Agent 的上下文治理跟 Open Claw 和 Claude Code 都不太一样。它的核心设计理念是：

“自我进化”——Agent 自己写自己的记忆和技能。

整个体系住在 ~/.hermes/ 目录下。

身份层（静态）

SOUL.md — system prompt 的第一个 slot，定义人格、语气、价值观、行为边界。这是全局的，从 HERMES_HOME 加载。这个文件你仍然可以手动编辑。

项目上下文层（按优先级，只加载第一个匹配的）

.hermes.md
AGENTS.md
CLAUDE.md
.cursorrules

先找到谁就用谁。

这意味着 Hermes 同时兼容 Claude Code 和 Cursor 的项目配置文件。

记忆层（三层，Agent 自己维护）

MEMORY.md — 长期记忆。存环境信息、项目惯例、工具使用经验。
USER.md — 用户档案。存你的名字、沟通偏好、技能水平。注意，这回 USER.md 已经变成自动维护了。
state.db — SQLite 数据库，带 FTS5 全文索引，存所有历史消息。Agent 不会默认全部加载，而是在需要时通过 session_search 按需检索。

这时候，记忆已经开始进入数据库时代了。因为只有数据库，才能真正支撑长期上下文检索。

技能层（Hermes 最独特的部分）

skills/ 目录 — 每个技能都是一个文件夹，里面包含一个 SKILL.md（带 YAML frontmatter），以及可选的模板和脚本。

关键区别在于：

技能不是人类写的。Agent 在完成非平凡任务之后，会通过 skill_manage 工具自己创建技能。同样，记忆也不再主要依赖人类维护。Agent 会在对话间隙，自己编辑 MEMORY.md 和 USER.md。而且技能是按需加载的。不用的技能不会进入上下文。这其实已经开始接近真正的"上下文自动治理"了。

调度层

cron jobs — 定时任务，类似 Open Claw 的 HEARTBEAT.md。

到了这一步，上下文治理不仅变复杂了，还开始自动化了。

总结

AI 是否真的能干活、干得好不好，已经不仅仅是模型之间的区别了。很多时候，更好的上下文治理，对智能体工作效率的提升，甚至比你换一个更强的模型还明显。

电子脑

随之而来的，还有一个很有意思的问题：上下文，其实就是智能体的"电子脑"。一个 Agent 用久了，那份上下文就会逐渐变成独一无二的它。只要上下文还在，就算换了一个"壳"，你的小助手还是你的小助手。如果智能体坏了需要重装，或者你想迁移到另一个智能体平台，只要把上下文迁移走，你的助手理论上就还能继续存在。

于是，一个新的问题出现了：如何安全地迁移上下文？

但现在的问题是：各家之间的文件名、结构、格式都完全不同。这就导致上下文迁移非常麻烦。我相信，未来一定会出现更统一、更标准化的上下文协议。而"上下文治理"，也会逐渐成为 AI Agent 最核心的能力之一。

AI时代我们应该如何阅读技术文档：精炼阅读

Fri, 15 May 2026 00:00:00 +0000

读不完的技术文档

一直以来，我们都关注要多看技术文档。但是我遇到的实际情况是：有时候一篇文档太长，看得时间太久，导致：

犯困，效率下降
中间被其他事情打断
被中间的知识点引导到别的文章去，而那篇文章也很长。我计算过，如果把这些文章全部读完，是不可行的，时间成本太高

实际的结果就是，我的浏览器常年开着很多没看完的技术文章 tab，我又舍不得关掉它们。我有时候会把它们放到收藏夹里。但是这并没有从根源上解决问题，反而造成收藏夹里的文章越来越多。收藏夹变成了一个巨大的 todo list。

阅读技术瓶颈

这些堆积的技术文档在我内心造成了负担，让我觉得愧疚。这成为了我脑子里的技术债。我总觉得是我不够努力，才没有读完它们。

但是我今天想，我要把这些技术文档全部读完是不可能的。因为：

文档的长度决定了读完它们注定要消耗大量的、超过我可承受范围的时间成本
文档中又会发散出新的文档，这个过程永不停歇

就像技术问题有瓶颈一样，我将它称之为阅读方面的技术瓶颈。这个问题需要通过逻辑层面的解决方案来解决，而不只是纯技术手段。

这个瓶颈的本质是：我们的时间和注意力都是有限资源。时间这个单位离人本身太远了，不能作为主要的度量工具，因为同样的时间里，你的阅读速度是不一样的。所以我更愿意将"注意力"作为我们的资源单位。你可以把人的注意力看作某种 token，你的 attention token 简称 AT。当你的注意力足够强，就可以产生 AT 力场（大雾）。消耗完了，就得靠睡眠来补充。

这个阅读技术瓶颈本质上是：

阅读文档总时间 > 你所拥有的注意力

精炼阅读

永远可以提炼

我想到，就算这些技术文档全都只看了一点点，我也能好好地做技术做到现在。有些文档甚至在我还没读的时候，这门技术就已经被淘汰了。所以，其实大部分文档中的信息我是不必去记忆的，只是把它们当作字典查询就可以了。

这甚至适用于很多总结归纳后的文档。它们依然可以继续被提炼。被提炼过的文字，其实依然可以再被提炼，最终提炼成一句话。但是提炼的过程会丢失大量信息，而这是预期内可以接受的。

LLM提炼

在 AI 编程时代，程序员的价值就是"注意力"。

我想，可以在注意力下降的时候，适当使用 LLM 去归纳文章剩下的部分。通过让 LLM 阅读并归纳后，我们先阅读大纲，然后对感兴趣的部分反复提问来学习。

后来我又想，为什么不更进一步：一开始就让 LLM 先提炼出一个足够短的文章大纲。然后我们阅读大纲后，选择继续读，还是就此放弃。继续阅读时，也可以选择自己逐行精读，或者只阅读感兴趣的部分。

不要发散

在阅读到自己感兴趣的知识点后，不要去 Google。我们来看这个行为链：

Google 关键词 -> 看到想看的页面 -> 点击页面 -> 查看该页面

Google 的搜索结果页面单项结构：

LOGO: 网站名
一句话的页面简介（不一定是页面标题）
2-3 行的页面短简介

你需要消耗注意力去逐条看这些词条。你打开了一个新的、花里胡哨的页面后，还需要继续消耗注意力去寻找你想看的东西。也许页面中的其他部分也在消耗你的注意力。

所以，遇到你感兴趣的知识点后，不要立刻去 Google。

直接问 AI，让 AI 给你找到你想看的东西
在回答中要求它附上链接，作为确认的证据
你可以自己点链接确认。一旦发现链接失效，后续会话中可以让它自己先访问链接，排除失效链接后，再给出可用链接

所以，我将这种方式称为 精炼阅读。

验证

我们需要一种方式去验证这种方式，否则无法证伪。所有无法证伪的都是伪科学。如果这种方法只是我瞎扯的，那么就可以被证明我在瞎扯。如果这个方法无效，那也是在浪费读者你的时间。

验证方式：

通过以下维度来验证使用该方法后的效果：

浏览器打开的技术文档 tab 数量应该下降
收藏夹内的未读文章数量应该下降，或者被归档
结束一天后总结，今天确实实现了本来预定的阅读计划，负罪感降低（这点其实很主观，也很伪科学，但没关系）

你也可以通过这套验证方式来验证该方法是否有效，从而决定你是该相信我，并改变自己的阅读习惯，还是觉得这个人就是在 bullshit。无论哪一种，你都走出了重要的一步：亲自实践 AI 带来的生活习惯改变。这就是有价值的。

AI时代如何提问面试者

Thu, 14 May 2026 00:00:00 +0000

背景

在 AI 时代，我们要如何面试才能保证招到合适的人才？你也不想招到一个 LeetCode 很厉害，但是却不会用 Claude Code，而且也不愿意学习 AI 编程的人吧。

但是相比起 LeetCode 或者传统软件知识来说，AI 又太年轻。我们又怎么样才能知道，对方是否能在未来几年的工作中，在公司保持较高的生产力呢？

术语规范

AI 只是一个泛泛的术语，适用于普通人理解。但是我们身为职业工作者，用词必须准确。

AI 包含很多范围，比如深度学习、监督学习、大语言模型，以及各种模型。本文只探讨大语言模型这个范畴内的面试问题。所以为了简单，本文会用 AI 指代 LLM。

本文也不讨论 LLM 训练方向的人才招聘。因为我不懂。而且这方面的知识体系存在时间比较久，已经有成熟的面试体系了。本文只探讨大语言模型应用方向的人才招聘。

核心思想

我们主要考核 4 个方面：

学习能力：
我们要招聘的是面向 AI 编程的程序员。无论他做的是 AI 方面的工作，还是只是使用 Claude Code 来编程，他都需要保持对技术的渴望，要紧跟时事。

因为在 LLM 应用这个领域，没有哪个学校可以有效地开课教授这方面的知识。你年初学的东西，可能到年末就已经过时了。所以学习必须靠自己。

要像追明星八卦一样去追逐 AI 的新动向。我经常会说，好的 AI 程序员就是狗，是你在 chasing 技术，而不是技术在 pushing 你。

所以我们的问题不仅会问 LLM 的知识，还需要知道他是否对 LLM 技术有追逐感。
整体理解：
考核面试者对 LLM 的整体理解。
使用经验：
考核面试者是否真的使用过 AI 编程工具。
具体知识：
考核对具体框架（比如 LangGraph）的了解。但这方面更多是针对 AI 整合方向的。

问题例子

以下是一些问题的例子，以及我自己的一些答案。

这些不代表标准答案。而且就像 LLM 有训练截止时间一样，我这些答案的截止时间是 2026.06。

学习能力

LLM 应用发展到现在经历了哪几个阶段？提示：第一个阶段是提示词工程
答案：提示词工程、上下文工程、Harness Engineering
什么是 Harness Engineering？
Harness Engineering 是为 AI Agent 搭建"外部运行框架"的工程，包括 tools、memory、retrieval、validation、workflow 和 feedback loop，用来提高 Agent 的正确率与可控性。

简单地说，现在的 Agent 架构可以简化为：model + harness。
说几个你知道的最新的 LLM 应用？
比如 OpenClaw、Hermes Agent、Happy Codex 等等（这个回答截止于 2026.05）。
说几个你知道的最新的 LLM 模型名字？
Opus、GPT5.5 等等（这个回答截止于 2026.05）。
你一般通过什么方式学习 LLM 技术？
看资讯网站、follow 某些媒体、自己做 LLM 项目，然后需要什么学什么，等等。

整体理解

上下文工程和提示词工程的区别是什么？
答案：提示词工程是"怎么写一句更好的 prompt"，上下文工程是"怎么为 AI 动态构建整个运行时上下文系统"。

因为现代 AI Agent 的效果，主要取决于"是否拿到了正确的上下文和工具"，而不只是 prompt 写得漂不漂亮。
你怎么理解 “RAG is dead” 这句话？
有两个层面的理解：
- 由于上下文工程的出现，人们更多地把提升智能体工作效率的重点，从"更强的 RAG"转向"更好的上下文工程"。
- 严格来说，不是 RAG 死了，而是早期那套 Naive RAG 死了。早期的 Naive RAG 基本是：文本 chunk -> embedding -> similarity search。
你有了解什么上下文工程的方法论吗？
上下文压缩、结构化笔记、子 Agent 架构。
上下文工程和 Harness Engineering 的区别和联系是什么？
Harness Engineering 更关注 AI Agent 的整体运行框架和执行系统，而上下文工程更关注如何为 Agent 动态组织和提供正确的上下文。

上下文工程可以看作 Harness Engineering 的核心组成部分之一。
什么是渐进式披露（Progressive Disclosure）？
渐进式披露（Progressive Disclosure）是指系统不一次性展示全部信息，而是在需要时逐步暴露相关内容，以降低复杂度并减少上下文干扰。

使用经验

以下问题没有标准答案，除了最后一题。

介绍一个你日常使用 Claude Code 编写代码的场景。
你遇到过 AI 写的最蠢的代码是什么？
遇到 AI 一直无法修好的 bug 怎么办？
你是否比较过市面上几款 AI 编程工具的效率？你觉得哪个好？理由是什么？
作为开发者，我们应该怎么写代码？

关于这题，我自己有一些答案，但会放在我的另一篇文章《AI 时代的程序员应该掌舵而不是编写（Steering Not Typing）》里面。

具体知识

这部分就根据具体框架来出题即可。比如你要考 LangGraph，那就根据 LangGraph 出题。

我就不献丑了。

[一天一个Skill]第1天：查单词Skill

Sat, 09 May 2026 00:00:00 +0000

即读即弃

即读即弃是我的写作风格。

我不是按照瀑布式的方式写文章的。所谓瀑布式，就是把整篇文章拆成多个步骤，你必须一路读到最后才能做出一个完整的东西。如果读到一半弃了，那就只能得到一个半成品。

现在这个时代节奏太快了，我自己都没时间长时间阅读一篇文章。我的文章是迭代式的。你看一小段，就可以先做出一个东西，然后我们再继续扩展，把这个东西做得更好。你如果没时间，就看多少算多少。

所以我会把文章分成多个部分。每读完一个部分，如果你不想继续往下读，就可以直接弃了下课。

第一部分：一个简单的查单词 Skill

背景知识

Skill 是什么

Skill 是 Claude 的母公司 Anthropic 在 2025 年底提出的一个规范。

支持这个规范的工具很多，比如 openclaw、codex、claude code 等等。

你不一定要跟我用同样的工具。只要你的 agent 智能体支持 Skill，就可以使用。

学会方法之后，你自己装到自己的智能体里就行了。不懂怎么装，就直接问你的智能体。

都什么年代了，别再"百度一下"“Google 一下"了，太低效了。

如果你的智能体回答不上来，或者一直回答错，那就考虑换一个智能体吧。

个人习惯

我个人喜欢用 openclaw，因为它是目前最接近"下一代普通人个人智能体"的东西，对生活帮助很大。

但 openclaw 太不稳定了，不适合演示，所以这里我会用 claude code。

痛点

如果你只是把一个单词直接发给 AI，它通常会按自己猜测的意思返回结果。

比如你想查 apple 这个单词，你直接对 AI 说：

apple

它大概率会返回：

Apple 是一家美国科技公司，总部位于美国加州库比蒂诺（Cupertino）。

它最著名的产品包括：

- iPhone
- MacBook
...

所以我们可以做一个专门查单词的 Skill。

开始制作 Skill

建立一个文件夹：en-cn-dict
在文件夹里面建立文本文件 SKILL.md

SKILL.md 内容

---
name: 查单词
description: 当用户消息中出现"查单词："或"查单词:"后跟英文单词时，返回音标、中文解释和发音。
---

## 处理规则

提取冒号后面的英文单词或短语。

兼容中文冒号 `：` 和英文冒号 `:`。

## 输出格式

必须严格使用以下格式：

单词：<英文单词>

音标：<音标>

中文解释：
1. <解释1>
2. <解释2>
3. <解释3>

部署 Skill

然后把这个文件夹放到：

~/.claude/skills/

里面。

如果没有 skills 文件夹，就自己创建一个。

部署完成后的路径：

skills
 ⎿ en-cn-dict
 ⎿ SKILL.md

加载 Skill

现在重启 claude code，然后问它：

查单词：tea

可以看到，它加载了 en-cn-dict 这个 Skill。

第一部分完成。

第二部分：真正的 Skill 编写方式

AI 时代最大的改变之一就是：

不要自己手写代码。

我们一定要慢慢改掉"所有东西都手写"的习惯。

其实 Skill 也一样，应该让 AI 自己去写。

比如我们这个查单词 Skill，本来就应该让 agent 自己生成。

如果你用的是 codex、openclaw、claude code 这种 agent 工具，你甚至可以直接让 agent 完成整个 Skill 的构建过程。

如果你只有 ChatGPT、Claude、Gemini 这种 chat app，那你就手动创建文件，然后让 chat app 告诉你 SKILL.md 该怎么写。

我这里用 claude code 演示创建 Skill。

我对 claude code 说：

claude code 帮我把 Skill 文件创建好了：

现在测试一下。

成功了。

不过它还是输出了一些我们没要求的内容。

AI 写代码就是会自由发挥。不过没关系，多出来的东西如果你不要，就继续让它删掉就好了。

第三部分：编写 Skill 的常用模式和问题

触发词

在这个例子里，我用了"触发词"的模式。

因为 agent 本质上是一个什么都能聊的对话框。什么都能说的代价，就是很容易混乱。

有时候 agent 并不能自动判断该使用哪个 Skill。

这时候你就可以通过"触发词"来缩小范围，精准定位要使用的 Skill。

这个触发词，有点像你手机里的一个 App 图标。你通过触发词，把 agent 导航到对应的 Skill。

如果你去看别的 Skill 入门教程，多半会看到"总结会议内容"这种例子。

那些教程里的 Skill 经常会写：

直接说"帮我总结会议"或类似请求

这里其实有两个问题：

太长，不好记
“或类似请求"以后会给你带来麻烦

你的 Skill 最好有一个：

简短
明确
不歧义

的触发词。

因为当你的 Skill 越来越多的时候，“类似请求"这种模糊匹配，会慢慢变成不确定因素。

触发词抢夺

有了触发词，就会有"触发词抢夺"问题。

我在 openclaw 里做这个例子的时候，它死活不按我的 Skill 来。

原因是：

我的 openclaw 用的是 OpenAI 的 API。

而"查单词：“这个词，在我使用的 model 里，本身就有很高的默认优先级。

这个 model 每次看到"查单词”，就会强行用自己的理解来处理。

这种现象，我把它叫做：

“触发词抢夺”。

如果遇到这种问题，也不用慌。

因为这通常说明：

其实 model 自己已经能很好地完成这件事了。

你甚至可能根本不需要专门做这个 Skill。

如果你真的想强制自定义，就换一个非常特殊、不容易被模型误判的触发词。

Skill 标记模式

如果你用的是 claude code，它会显式告诉你调用了什么 Skill。

但如果你用的是别的工具，比如 openclaw，它通常不会告诉你到底用了哪个 Skill。

这样就会让人很不安心。

你根本不知道它到底有没有调用你的 Skill。

这时候，你可以在 Skill 输出的最后，强制加一句：

使用了 [xxx skill]

这样你就能知道：

它到底有没有真正调用你的 Skill。

Web4.0 要来了

Wed, 06 May 2026 00:00:00 +0000

AI 不只是工具升级，而是一次新的计算平台革命。

一、前言：裂缝已经出现了

我最近在找工作，然后我发现了一件很有意思的事情：现在真正招聘"LLM 整合开发"的岗位，其实还很少。更有意思的是，即使招聘，大部分公司也要求：

有 AI Agent 经验
有 LLM 项目经验
有 RAG 经验
有 AI Workflow 经验

问题是，LLM 才爆发几年？真正有完整 AI 开发经验的工程师，到底有多少？很多工程师开始转向 LLM 开发，也不过才几个月。

你现在非要卡得这么死，招不到人，这些人最后就会被别的公司抢走。再过一两年，你可能想招都招不到了。

（所以我最近在找工作的话，其实可以现在就招我了。但不要考 LeetCode。）

但这件事情真正有意思的地方，其实不在招聘，而在于大部分公司直到现在，依然不知道该怎么使用 AI 盈利。很多真正开始利用 LLM 做事情的人，反而是独立开发者、小团队、极客、个人创业者。他们甚至不知道未来能不能赚钱，但他们依然在疯狂实验，因为"这件事情本身很酷"。

这种极客的直觉，其实很难用传统企业的经营逻辑去理解。很多伟大的技术革命，最开始都不是因为"商业模式清晰"，而是因为有一群人觉得这东西太有意思了。

互联网如此，个人电脑如此，智能手机如此，AI 也是如此。

真正危险的，是很多大公司直到现在还停留在自己的舒适区里。他们还在问：

AI 能不能赚钱？
AI ROI 怎么算？
AI 会不会影响现有业务？

但他们真正应该思考的问题其实是：

“十年后，公司还会不会存在？”

因为历史已经发生过很多次了。柯达不是死于技术不够强，诺基亚不是死于工程师不优秀，它们死于"新计算平台出现时，它们还活在旧时代"。

而现在，裂缝已经出现了。

在我看来，一个尼亚加拉大瀑布正被一层薄薄的土墙挡住，而那层土墙已经开始裂开了。

今天 90% 的互联网公司，其实都已经站在悬崖边缘，只是它们自己还没有意识到。不信？我们可以从现在开始做一个社会实验：

做 Jira 的 Skill
做有道的 Skill
做各种 Web2.0 软件的 AI 版本

看看它们会不会被颠覆。

二、正文：Web4.0 架构

Web3.0 这个词，已经快被说烂了。为什么？因为它并没有真正出现足以重构 Web2.0 的新计算范式。

但 AI 不一样。

我愿意把这次浪潮称为 Web4.0，因为 AI 正在开始深度进入软件本身。它不再只是搜索框、聊天机器人、辅助工具，而是在逐渐成为软件运行逻辑的一部分。

我甚至认为，这会是第四次工业革命，因为机器第一次开始"自己参与软件的生产"。

1. 软件界面

Web4.0 的软件界面，会和今天的软件非常不一样，但也不会完全陌生。

未来的软件，大概率会变成"左边是软件，右边是 AI"。

左边依然是传统 GUI，例如：

任务列表
表格
图表
Dashboard
状态栏

因为人类依然需要"看到状态"，GUI 不会消失。

但右边会出现 AI 操作层。用户不再主要通过按钮操作软件，而是通过自然语言、对话、意图完成大部分工作。

例如：

“帮我把这个 issue 调整到下周并通知相关成员。”

AI 会：

修改 issue
更新状态
发送通知
修改时间线

而左边 GUI 的作用，则变成"展示系统当前状态"。用户甚至可以看着 AI 在系统里操作，必要时再自己接管。

未来的软件，会从：

“人操作软件”

变成：

“AI 操作软件，人监督 AI。”

2. 系统架构

Web4.0 的核心变化，是所有前端最终都会连接到 AI 引擎。

例如：

App
Web
Desktop
Skill
Agent

最终都会接入：

SLM + RAG

很多人现在默认未来一定是超大模型统治世界，但我并不这么认为。因为 LLM 成本太高，企业敏感数据不能外流，技术命脉也不能被外部模型公司掌握。一个真正成熟的大公司，不可能把自己的核心业务永远建立在别人的 API 上。

因此，Web4.0 最终一定会走向：

企业自己的 SLM（Small Language Model）+ 自研 RAG。

LLM 会更像早期探索工具、通用推理引擎、产品验证平台。而真正成熟后的产品，最终会拥有自己的：

AI Engine
Memory
Knowledge Base
Workflow System

未来公司的技术护城河，也会逐渐从：

前端页面
CRUD 系统
数据库设计

转向：

RAG 架构
Workflow 编排
企业知识组织
Agent 协作系统

3. 生命周期

Web4.0 产品的生命周期，也会发生变化。

在产品早期，很多团队会直接使用：

OpenAI
Claude
Gemini

配合：

MCP
RAG
Workflow

快速构建产品，因为试错成本低，产品一开始就能"活"。

这和过去完全不同。以前产品必须开发大量逻辑后才能 usable，但现在 AI 本身就已经拥有大量通用能力。

但到了成熟阶段，企业一定会逐渐迁移到：

SLM + 自研 RAG

原因很现实：

降低成本
控制数据
降低 API 依赖
保证稳定性
建立技术主权

所以 Web4.0 产品的发展路径，很可能会变成：

LLM API
 ↓
RAG
 ↓
Workflow
 ↓
SLM
 ↓
企业 AI Engine

4. 客服系统

客服行业，可能会是最先被重构的行业之一。

但这一次，是真正的 AI 客服，而不是以前那种"让所有人都烦躁的假 AI"。

过去的 AI 客服：

听不懂上下文
不能连续对话
无法理解情绪
只会关键词匹配

所以用户最终总会"转人工"。

但 Web4.0 的 AI 客服不一样。它会真正理解：

上下文
历史记录
用户情绪
用户行为

它甚至能判断：

“用户已经开始不耐烦了。”

然后主动：

“我帮你转人工客服。”

未来很多公司的客服系统，其实已经完全可以 AI 托管。真正需要人的场景，只会剩下：

高风险决策
情绪安抚
特殊案例处理

又一个产业，会被重构。

5. 版本迭代

这一部分是一个比较激进的想法，但我觉得它很酷，而且很可能带来病毒式传播。

那就是：

“下一个版本做什么，由用户投票决定。”

AI 会：

分析用户行为
总结用户需求
自动生成候选功能
让用户投票

甚至未来，AI 还能自动实现部分功能。

过去的软件开发流程是：

产品经理
 ↓
需求
 ↓
开发

而 Web4.0 时代，可能会逐渐变成：

用户
 ↓
AI 分析
 ↓
AI 实现
 ↓
用户反馈

软件会开始进入：

“高速自进化时代。”

三、结论：Web4.0 不是升级，而是替代

很多公司现在还认为，AI 只是一个插件、一个功能、一个聊天框、一个提高效率的工具。

但我认为，AI 真正改变的，是整个软件架构。

Web4.0 不是"Web2.0 + AI"，而是一个新的计算平台。就像：

PC 替代大型机
智能手机替代部分 PC
云计算重构企业系统

一样。

AI 会重新定义：

软件
工作流
组织方式
开发模式
用户交互
企业架构

很多公司现在以为，自己只是在等待 AI 成熟，但实际上：

AI 正在等待替代它们。

我们现在，可能正站在自计算机发明以来最大的技术风口上。而很多公司已经站在悬崖边缘，只是它们自己还没有意识到。

基于 LLM 的 AI 智能体架构：一台长在你设备里的新型电脑

Tue, 05 May 2026 00:00:00 +0000

基于 LLM 的 AI 智能体架构：一台长在你设备里的新型电脑

过去，我们一直把 AI 理解成一个"聊天机器人"。

但如果从系统架构角度重新观察，会发现未来真正成熟的 AI 智能体，更像是一台安装在你设备里的新型个人电脑。

它拥有：

计算核心
内存
文件系统
软件系统
输入输出设备
长期存储

只是：

它的核心不再是传统 CPU，而是 LLM。

一、LLM 引擎：没有记忆的"CPU"

LLM 本身其实没有长期记忆。

它更像一个推理引擎：

接收输入
读取上下文
进行推理
输出结果
然后"失忆"

它无法天然记住过去发生的事情。

因此：

LLM 本身更像 CPU，而不是完整的智能体。

它只负责计算。

真正让 AI “看起来认识你"的，是外部为它提供的上下文。

二、上下文：AI 智能体的内存

如果 LLM 是 CPU，
那么 Context（上下文）就是 AI 的内存。

而这个内存，其实应该分成两层。

1. 全局上下文（Global Context）

这一层属于整个智能体。

它记录：

用户偏好
长期目标
常用习惯
人格设定
长期规则
历史知识

例如：

“用户喜欢 Markdown”
“用户正在学习 AI Agent”
“用户习惯使用中文写作”

这些信息会长期影响智能体行为。

2. 会话上下文（Session Context）

这一层只属于当前对话。

例如：

当前正在讨论的话题
当前文章结构
最近几轮对话
临时推理结果

它更像程序运行时的临时内存。

上下文窗口，本质上是"内存限制”

LLM 的 Context Window 并不是无限的。

这意味着：

历史不能无限累积
信息会越来越贵
超过限制后必须被压缩

于是：

智能体必须像操作系统一样管理内存：

压缩历史
总结摘要
清理低优先级信息
转移长期信息
动态加载需要的数据

因此：

Context Window 本质上就是 AI 的内存容量。

三、Markdown 文件：智能体的硬盘

长期数据不应该一直放在上下文里。

否则：

成本会越来越高
推理速度会下降
Context 会迅速膨胀

因此：

长期记忆应该存在文件系统中。

而一种非常自然的形式，就是 Markdown 文件。

例如：

笔记
项目资料
日记
世界观
用户档案
写作素材
长期知识库

都可以直接存成 Markdown。

这意味着：

传统电脑	AI 智能体
硬盘	Markdown 文件系统

Markdown 有一个巨大优势：

它既能被 AI 阅读，也能被人类直接阅读。

因此：

人类可以编辑
AI 可以处理
Git 可以版本管理
文件可以同步
即使脱离 AI 依然存在

这会形成一种：

“人与 AI 共用的知识空间”。

四、Skill：安装在 AI 上的软件

未来的 AI 智能体，不会只有"知识"。

它还会拥有"技能"。

例如：

写作 Skill
编程 Skill
视频剪辑 Skill
数据分析 Skill
项目管理 Skill

这些 Skill 可能由：

Prompt
工作流
Python 代码
MCP 配置
Tool 调用规则

共同组成。

它们就像：

安装在 AI 身上的软件。

因此：

传统电脑	AI 智能体
软件 / App	Skill

Skill 可以：

安装
卸载
更新
共享
组合

未来甚至可能出现：

Skill Store
Skill Marketplace
开源 Skill 社区

五、输入输出：不只是文字

传统聊天机器人最大的误导之一，是大家以为 AI 只有文字交互。

实际上未来的 AI 智能体，会拥有完整的多模态输入输出系统。

输入

AI 可以读取：

文字
语音
图片
视频
摄像头
文件
屏幕内容
设备状态

输出

AI 可以生成：

文本
语音
图像
视频
自动化操作
控制指令

因此：

AI 智能体本质上是一种新的交互层。

电脑整机：一种"类冯诺依曼结构"的 AI 计算机

如果把整个架构放在一起：

传统计算机	AI 智能体
CPU	LLM 引擎
内存	Context
硬盘	Markdown 文件系统
软件	Skill
输入设备	多模态输入
输出设备	多模态输出

你会发现：

它已经越来越像一台真正的计算机。

只是：

这台计算机不是围绕 GUI 构建的。

而是围绕：

“语言理解与推理”

构建的。

操作系统：个人 AI 操作系统

未来每个人设备中，都可能长期存在一个 AI Agent。

它：

理解你
记住你
帮助你工作
管理你的知识
调度你的 Skills
操作你的设备
与你长期共同成长

那时：

我们使用的可能不再只是：

Windows
macOS
Android

而是：

一个以 LLM 为核心的新型个人 AI 操作系统。

而今天的聊天框，

可能只是这个新时代最早期的雏形。

参考资料

Park, Joon Sung et al.
MemGPT: Towards LLMs as Operating Systems
arXiv:2310.08560
https://arxiv.org/abs/2310.08560
Wang, Lei et al.
LLM as OS, Agents as Apps: Envisioning AIOS, Agents and the AIOS-Agent Ecosystem
arXiv:2312.03815
https://arxiv.org/abs/2312.03815

AI治好了我的写作拖延症

Mon, 04 May 2026 00:00:00 +0000

AI治好了我的写作拖延症

懒人的借口

我已经很多年没写博客了。

不是没有想法，是真的写不动。以前写一篇文章，少说也要一周——构思、码字、反复改，改完还要配图，画流程图用draw.io一拖一拽，半小时过去了就画了个框。整个过程又慢又累，慢慢地就产生了一种抵触感。每次打开编辑器，脑子里第一个念头不是"我要写什么"，而是"算了，改天吧"。

这一改天，就是好几年。

直到最近，我才意识到，让我停下来的从来不是没有东西可写，而是写作这件事本身太"重"了。

现在AI把这个重量卸掉了一大半。

痛点

从思路变成通顺的文字很困难：我只需要把想法说清楚，哪怕是很粗糙的几句话，AI可以帮我把它组织成流畅的段落。我来把控方向和观点，它来打磨语言——这个分工让我舒服多了。

找配图很费时间，经常图片的格式和大小还不合适：现在直接让AI生成，风格、构图都能描述，几秒钟出来。

画流程图很慢：把逻辑说给AI，它直接给我生成，我只需要看看对不对、要不要调整。

具体方案

我给自己搭了一个小小的写作流水线，核心是两个AI角色。

一个是写手。我把想法、思路、想表达的核心观点丢给它，它负责把这些碎片组织成一篇完整的初稿。

初稿出来之后，我自己来改。这一步很关键——不要把读者当傻子。好的文章越短越好，现在的人包括我自己都没耐心看一篇大长文。Later is never。

改完之后，交给第二个AI角色——编辑。它负责审这篇文章，帮我再修改一轮。其实我现在也不确定编辑这个角色是否需要，先这么做试试看吧。

我不确定接下来会写多少篇，但至少今天，我打开了编辑器，写完了这篇。