AI哲学 on Code Plato

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 最核心的能力之一。