迁移前的状态

这套博客由三个组件构成，都是两年前从 mx-space 上游 fork 的。迁移前逐个盘点，状态如下：

生产环境跑 8.4.1 而本地 fork 停在 7.1.8，原因是 compose 里写的是 :latest，某次 docker compose pull 把版本悄悄推了上去。数据层是 mongo:7 + redis，数据量不大：73 篇文章、25 篇手记、4 条评论，MongoDB 数据目录 513MB。

上游这两年的三个破坏性变更决定了迁移的复杂度：

• v10：认证系统换成 Better Auth，旧 JWT/API token 全部作废。数据迁移在应用启动时自动执行，最后会删除旧的 users 集合，不可逆
• v12：数据库从 MongoDB 硬切换到 PostgreSQL 16，官方提供一次性迁移工具 @mx-space/mongo-pg-cli，没有双写
• v13：API 换 /api/v3 契约（{data, meta} 信封 + snake_case），admin 并入 core monorepo。前台 Shiro 进入日落维护，只兼容 core 10.x

方案

目标：所有组件跑自己构建的镜像（获得定制能力），版本升到上游最新，内容零丢失。

组件决策：

迁移路径：8.4.1 无法直接跳 13.12.0（v13 镜像不再支持 MongoDB），必须分段。分段依据是上游迁移机制的边界：

8.4.1 ──启动──▶ 11.5.1 ──建 schema──▶ 12.10.0 ──CLI 搬数据──▶ 12.10.0 ──换镜像──▶ 13.12.0
      Mongo 自动迁移        空 PG 首启              mongo-pg-cli            Drizzle 自动迁移

图注: 中间两站（11.5.1、12.10.0）直接用官方镜像过渡，自建镜像只在终点出现

• 11.5.1 是 Mongo 时代最后一个版本。mongo-pg-cli 的定位是"v11 到 v12 迁移"，所以 8.4.1 的数据要先靠 v9–v11 的启动自动迁移整形到 v11 schema
• 12.10.0 的作用是对空 PostgreSQL 首次启动、由它的 migration 机制建好 schema，然后停掉它跑 CLI 搬数据
• 13.12.0（自建镜像）启动时由 migrate.mjs 自动把 schema 升到最新

安全措施（动手前完成）：

1. mongodump 全量备份，并且做恢复演练：恢复到临时命名空间，逐集合对行数，通过后丢弃临时库
2. compose 里的 innei/mx-server:latest 改成当前镜像的 digest（@sha256:...），防止迁移期间误 pull 直接跨过 v10 的不可逆迁移
3. 备份三件套拷贝到服务器之外：mongodump、core 内置备份 zip、static/ 上传文件

实施

仓库与 CI

mx-server fork 的同步用 merge 而非 rebase。落后 1592 个提交时，rebase 会让每个过时的本地提交都产生一轮冲突；merge 只需处理最终状态，实测只有 .gitignore 和 release.yml 两个文件冲突：

git remote add upstream https://github.com/mx-space/core.git
git fetch upstream --tags
git checkout -b sync-upstream master
git merge v13.12.0        # 解决 2 个冲突后提交

release.yml 以上游版本为基础改三处：镜像名改为 ghcr.io/dante-dan/mx-server；Docker Hub 登录换成 ghcr（username: ${{ github.actor }} + GITHUB_TOKEN，不需要额外 secret）；删掉上游作者硬编码的 R2 发布段和 Dokploy webhook（那是他个人的基础设施，fork 照抄会把产物发到别人家）。push master、打 tag v13.12.0-dante.1，CI 构建出镜像。

Yohaku 的处理：源码放私有仓库（sponsorware 不能公开），构建 workflow 只有一个点需要注意，它的 @yohaku/design-system 来自指向公开仓库的 git submodule，checkout 必须带 submodules: recursive，否则 pnpm install 报 workspace 包缺失。BASE_URL 在构建期注入（NEXT_PUBLIC_API_URL 等由它派生），运行期还要通过 .env 再提供一遍，因为 SSR 在运行时读环境变量，只烘焙不注入会报 Failed to parse URL from /api/v3/...。

切换窗口

按顺序执行，每步验证通过再进行下一步。总耗时约两小时。

1. 冻结与终备份。停掉前台挡住写入，做最后一次 mongodump 并拷出服务器。

2. 升 11.5.1。compose 镜像改 innei/mx-server:11.5.1，up -d 后观察日志：23 个自动迁移依次执行（v9.7.x 的 Better Auth 迁移链、v10.x、v11.4.0），结束后 /api/v2/ping 正常、admin 可登录。此步之后回退 8.x 只能靠 mongorestore。

3. 建 PG，搬数据。compose 加 postgres:16-alpine 服务，镜像改 12.10.0，env 从 DB_HOST 换成 PG_HOST/PG_USER/PG_PASSWORD/PG_DATABASE 并加 SNOWFLAKE_WORKER_ID=1。首启建好 schema 后停掉 app，在 docker 网络内跑迁移（mongo 容器没有映射宿主端口）：

docker run --rm --network core_mx-space \
  -e SNOWFLAKE_WORKER_ID=900 \
  -e MONGO_URI="mongodb://mongo:27017/mx-space" \
  -e PG_URL="postgres://mx:***@postgres:5432/mx_core" \
  node:22-alpine npx -y @mx-space/mongo-pg-cli@latest --mode dry-run
# dry-run 输出逐表行数对照，人工核对后同命令 --mode apply

apply 完成后起 app，用 psql 对行数（posts 73 / notes 25 / comments 4），再抽查 API 返回。

4. 换自建 13.12.0。compose 镜像改 ghcr.io/dante-dan/mx-server:13.12.0-dante.1，healthcheck 路径改 /api/v3/ping。启动时 Drizzle migration 自动升级 schema（这里踩了坑一，见下节）。成功后 redis-cli FLUSHALL 清缓存（v13.2 的 thumbhash 变更要求清 enrichment 缓存）。

5. 前台换 Yohaku。docker stop shiro，新目录里放 compose 和 .env（BASE_URL、NEXT_PUBLIC_API_URL=https://api.dhpie.com/api/v3、NEXT_PUBLIC_GATEWAY_URL），同样绑 127.0.0.1:2323，反向代理不用动。

6. 验收。首页、文章页、RSS、sitemap、admin 登录、发测试评论、admin 里点一次 Backup Now 确认产出 pg_dump 版备份。

踩到的四个坑

图注: 种子数据冲突、代理正则劫持、鉴权静默降级

坑一：种子数据与迁移数据冲突。 13.12.0 启动时 migration 报 path collision detected: 3 duplicate keys。原因：12.10.0 对空库首启时种子化了 3 个内置 snippet（ip、geocodelocation、geocodesearch），CLI 随后又从 Mongo 搬来同名的 3 条，而 v13.11 的 snippet 迁移要求路径唯一。处理：删掉首启种子的 3 行（保留 Mongo 迁移来的），重启即过。做"先建 schema 再搬数据"的迁移时，搬数之前先清点应用首启种了什么。

坑二：nginx 正则劫持新 API。 Yohaku 的 feed/sitemap 一直 500，日志显示拿到 XML 却按 JSON 解析。定位到反向代理里一条老规则 location ~* /(feed|sitemap|atom.xml)，正则没有锚定开头，而 nginx 的 regex location 优先于 prefix location，v13 新接口 /api/v3/aggregate/feed 包含子串 /feed，被整个劫持到 core 的 RSS 页面。改成 location ~* ^/(feed|sitemap|atom.xml) 解决。升级 API 版本时值得把代理配置里所有正则 location 过一遍。

坑三：旧主题配置缺字段。 从 Mongo 迁来的 theme/shiro 主题 snippet 是 2024 年的 schema，没有 config.module.rss 节点，Yohaku 的 feed 路由读取时直接崩。在 PG 里给该 snippet 合并 {"rss":{"enable":true,"custom_elements":[]}} 解决。跨大版本迁移后，主题/配置类 JSON 的 schema 也要对齐新前台的预期。

坑四：鉴权静默降级。 v13 的 API key 必须放 x-api-key 请求头（Better Auth 的 apiKey 插件只配置了这个 header）。沿用旧习惯放 Authorization: Bearer 不会报 401，只会被当成游客，公开接口照样返回 200。鉴权探活要断言身份而非状态码：

curl -H "x-api-key: $KEY" https://api.dhpie.com/api/v3/owner/check_logged
# 有效 → {"data":{"ok":1,"is_guest":false}}

结果与收尾

迁移后的生产栈：ghcr.io/dante-dan/mx-server:13.12.0-dante.1 + postgres:16-alpine + redis + ghcr.io/dante-dan/yohaku:latest。数据零丢失（73/25/4 全程对数一致），停机约两小时。

观察一天确认稳定后收尾：从 compose 移除 mongo 服务并删除 513MB 数据目录（终版 mongodump 保留在服务器外）、删除 shiro 容器和部署目录、清理 788 个 Mongo 时代的自动备份（894MB）和不再使用的镜像。

迁移后的日常升级流程收敛为：git fetch upstream && git merge <新 tag> → push → 打 v*-dante.N tag → CI 出镜像 → 服务器 docker compose pull app && docker compose up -d app。升级从此是显式决策，:latest 不再出现在任何 compose 里。

时间突然有了形状

以前只有我和老婆两个人的时候，我很少认真感受时间。

它当然也在走。工作日、周末、节假日，手机日历一页页翻过去，年龄也一年年往上加。但那时候的时间更像背景音，存在，却不太打扰人。我们还有很多可以随意支配的东西：晚上几点睡，周末去哪里，想吃什么，想买什么，临时改变计划也没什么大不了。

那时候我对生活的判断，大多还停留在「效率」和「划算」上。

比如车。

我一直觉得买车没什么必要。地铁加自行车，或者地铁加打车，已经能解决绝大多数问题。买车之后反而多出一堆麻烦：停车、保养、堵车、限行、时间安排。城市生活里，很多时候拥有一件东西，并不等于更自由，反而意味着你要为它承担一整套附加成本。

我以前很相信这个判断。

直到有了孩子。

判断标准变了

孩子出生后，很多事情突然换了一套逻辑。

打车依然方便，但安全座椅装不上。以前下雨只是麻烦一点，现在下雨意味着要抱着孩子、拎着包、判断路面、避开风，还要担心他冷不冷、困不困、会不会突然哭。以前晚上回家只是晚一点，现在晚上带孩子出门，整个城市都会变得不那么可靠。

车在这时候不再只是交通工具。它更像一个临时的小房间，一个移动的安全边界。

这件事给我的冲击很大。因为我发现自己并不是简单地「想买车」了，而是对确定性的需求变强了。过去我喜欢轻装上阵，觉得生活越少绑定越好。现在我开始理解，某些绑定本身就是保护。它们看起来笨重，却能在关键时刻帮你把世界挡开一点。

这种变化不只发生在车上。

以前我对房子的想法也很随意。住哪里都可以，租房也没什么，人生不必被一套房子定义。可孩子出生后，我开始想象他以后会在哪里爬、在哪里跑、在哪里上学，想象一个稳定的房间、一张固定的小床、一个他熟悉的门口和楼下。

我知道这些想象里有很多现实压力，也有很多传统观念的影子。但我无法否认，它们变得重要了。

当一个孩子来到你身边，很多原本抽象的词都会变得具体：稳定、安全、未来、责任。它们不再是文章里的概念，而是某个雨夜你抱着孩子站在路边时，心里突然冒出来的念头。

他在学习世界

孩子成长的速度，比我想象中更惊人。

最开始的几个月，他好像只是在吃和睡。饿了就哭，困了也哭，醒来的时候茫然地看着天花板，像一个刚刚被放进世界里的小生物，还不知道自己在哪里。

但很快，他开始有了反应。

他会表达不满，会盯着一个东西发呆，会听到熟悉的声音转头，会在某个瞬间突然对你笑。那个笑很奇妙，不像成人的笑，里面没有社交判断，没有礼貌，也没有讨好。它只是某种生命最原始的回应：我看见你了，我认识你了，我愿意靠近你。

有时候我看着他，会觉得人类的学习能力真是可怕。

我第一次戴手环的时候，他立刻注意到了。那不是一个多显眼的东西，但他就是发现了。后来等他能自己伸手、抓东西、做动作之后，最喜欢干的事情之一，就是扒着屏幕滑来滑去。他当然不知道屏幕上的字是什么意思，也不知道图片背后有什么信息结构，但他知道一件事：手指滑一下，东西会变。

这件事让我觉得很震动。

我们常说 AI 很聪明，因为它能回答问题、写代码、生成图片。但孩子的聪明不是这种聪明。他不是在已有语料里预测下一个词，而是用整个身体去试探世界。他用眼睛、手指、哭声、笑、失败、重复，去建立因果关系。

他不知道「交互」这个词，但他已经理解了交互。

他不知道「界面」是什么，但他已经知道某些表面会回应他。

他甚至不知道自己在学习，可他每天都在疯狂学习。

这让我对「成长」这个词有了新的理解。成长并不是突然掌握了什么大道理，而是在一个个微小反馈里，把世界慢慢拼起来。成年人常常以为自己懂得很多，其实我们只是习惯了世界的运行方式。而孩子还没有习惯，所以他看到的每一件小事，都是第一次发生的奇迹。

我也在变老

孩子的变化太明显了，明显到你没法假装时间没有过去。

衣服很快变小，奶量慢慢增加，睡眠节奏不断变化，表情一天比一天丰富。你会突然发现，几周前那个只能躺着的小婴儿，已经开始试图控制自己的手；几个月前那个只会哭的孩子，已经会用笑来回应你。

他的成长像一把尺子，把时间量出来。

这也是让我沮丧的地方。

以前我也知道自己会老，但那种知道很抽象。生日过了也就过了，体力差一点也可以解释为最近太忙，精力下降也可以归因于睡得不好。人很擅长把衰老藏进各种理由里。

可孩子不会配合你藏。

他每天都在变大，于是你每天都能看见时间。他多学会一个动作，你就少拥有一天他不会这个动作的样子。他开始认识世界，也意味着那个完全依赖你、什么都不懂的小婴儿正在一点点离开。

这是一种很奇怪的幸福。

你希望他快点长大，健康、聪明、自由，能看见更多东西，能走向更大的世界。可你又会在某个夜里突然舍不得，舍不得他小小的手，舍不得他趴在你身上的重量，舍不得那些辛苦到崩溃但以后再也不会回来的时刻。

成为父亲以后，我才发现幸福并不总是轻盈的。很多幸福是带着重量来的。它让你觉得生活有了更深的意义，也让你意识到自己不再只是自己。

责任落到身上

以前我对「责任」这个词有一点警惕。

它听起来太宏大，太容易变成一种道德绑架。好像人一旦进入某种身份，就必须自动接受一整套叙事：你要成熟，你要牺牲，你要稳定，你要为别人活。

我不太喜欢这种说法。

但孩子出生后，我慢慢发现，真正的责任不是别人喊给你听的口号。它更像一种身体里的变化。你开始在做决定时多算一个人，开始在花钱时想到更远的时间，开始在疲惫时仍然起身，开始把某些以前可以任性的地方收回来。

这并不总是高尚的。很多时候只是因为你知道，他真的需要你。

我开始想给他更好的生活，想给他房子，想给他安全感，想让他在需要依靠的时候，有一个稳定的大人站在那里。这些想法放在以前，我可能会觉得俗，甚至觉得有点无聊。现在我不这么想了。

人有时候不是被道理改变的，而是被关系改变的。

当你和另一个生命之间建立了足够深的关系，很多价值排序会自己移动。你不一定变得更正确，但你会变得更具体。你开始知道自己为什么赚钱，为什么忍耐，为什么规划，为什么在一些事情上不再那么潇洒。

这种变化里当然有压力。养孩子不是一个浪漫故事，它有账单、疲惫、焦虑、反复崩溃的夜晚。但也正因为如此，那些温柔的瞬间才显得真实。一个微笑，一次抓手，一声含糊的回应，都不是悬浮的美好，而是从一堆琐碎和混乱里长出来的光。

时间有了方向

我现在常常觉得，孩子让时间有了形状。

以前时间像水，流过去就流过去了。现在时间像一棵树，你能看见它长出新的枝叶，也能看见旧的样子再也回不来。孩子在长大，我在老去；他一点点靠近这个世界，我一点点意识到自己要为他撑起一些东西。

这件事让我幸福，也让我沮丧。

幸福的是，我亲眼看见一个生命展开。沮丧的是，展开本身意味着不可逆。每一个「第一次」都珍贵，也都只发生一次。第一次笑，第一次翻身，第一次抓住我的手，第一次发现屏幕会动。它们来得很快，走得也很快。

所以我现在想做的，是尽量多看见一点。

看见他的变化，也看见自己的变化。看见我从一个追求自由和效率的人，慢慢变成一个愿意为确定性付费、为稳定承担成本、为另一个人的未来重新安排自己的人。

我不知道这算不算成熟。也许只是生活把我推到了这里。

但我确实开始相信，人的改变并不总发生在宏大的决心里。很多改变发生在很小的瞬间：雨天打不到车的时候，夜里抱着孩子走来走去的时候，看见他第一次对你笑的时候，看见他笨拙地滑动屏幕的时候。

那些瞬间没有说教，却一点点改写了你。

后来你回头看，才发现自己已经不是原来的自己了。

有一次我接到一个很急的需求。

那天我本来已经准备加班了。结果一边工作，一边娃也有事。我没法一直坐在电脑前面盯着代码写。

我当时也没有什么完整方法。就是把我能想到的背景、需求、限制、代码位置，全都丢给 AI。然后我去带娃。

回来以后，我的第一反应是：这玩意儿居然能跑。

第二反应是：写得真糙，很多细节都没处理。

第三反应比较复杂。剩下的工作其实不多，但这些工作恰好是最重要的。很多细节、边界、异常状态，平时我自己写的时候也不一定一开始就想全，通常是做到后面才补。它这次反而提前想了一些。

这件事以后，我对 AI 写代码的看法变了。

不是因为它能写代码。能写代码这件事已经不新鲜了。真正让我在意的是：它把第一版做出来以后，我的工作变了。我不再从空文件开始写，而是先看一个能跑但不够好的东西，然后判断它哪里不对。

这比从零写代码更接近我现在的工作状态。

Prompt 不是最重要的

很多人聊 AI 编程，第一反应是 prompt。

怎么写 prompt？要不要先让它出方案？要不要让它列 task？要不要一步一步确认？

这些当然有用。但我现在不太把它们放在第一位。

大部分任务，我会直接让 agent 先做。如果它做得不对，我再补充要求，或者给它一个更明确的方案，让它重做。

原因很简单：很多时候，提前把所有事情说清楚，比让它先做一版成本还高。

这也是我现在对 agent coding 的一个判断：在 AI 时代，很多任务的对齐成本会比纠错成本高。以前我们习惯先把需求、方案、边界都对齐好，是因为人写代码的返工很贵。但现在 agent 先做一版的成本很低，看到实物以后再判断哪里不对，反而更省力。

假设我有 10 个问题。如果我每个问题都先写完整方案，时间会花很多。但如果我直接让 agent 做，它很快会给我 10 个结果。可能其中 6 个能用，3 个要改，1 个完全不行。那我只需要把精力花在后面 4 个上。

这个体感差很多。

以前手工写代码，任务没想清楚就开始写，返工成本很高。现在很多执行成本被 AI 吃掉了。真正贵的是三件事：

1. 我有没有看出哪里不对。
2. 我能不能判断这个问题值不值得改。
3. 我能不能把问题讲清楚，让它下一轮改对。

所以我现在更关心反馈回路，而不是 prompt。

prompt 只是输入。它不能保证事情真的做对。

真正有用的是后面这一串：任务丢出去，agent 做一版，我验收，发现问题，让它改，必要时补工具、补记忆、补测试。下一次再遇到类似问题，它应该更容易做对。这才是重点。

我一定会自己验收

我不会因为 AI 说完成了，就相信它完成了。

尤其是 UI 和真实行为，必须自己跑一遍。

UI 我会看 pixel diff。这个东西很直接，哪里变了，一眼就能看到。很多时候你光读代码看不出来 UI 被它搞坏了，但截图一对比就很明显。

常规行为我反而不太担心。比如输入框最大长度、错误 Toast、异常处理、复用项目已有的交互方式，这些它通常能做好。项目里有现成例子，它会照着学。我说太多反而浪费上下文。

真正要看的，是运行起来以后是不是对的。我一般会看这几类东西：

1. 请求数量对不对，参数有没有多发、漏发。
2. 过滤有没有真的生效，不只是 UI 看起来变了。
3. 异常状态有没有处理，失败以后用户还能不能继续走。
4. PC 切到 mobile 以后，布局和交互有没有崩。
5. 页面上那些边界路径，是不是真的能跑通。

这些东西只看代码不够。

以前我写代码时，会一边写一边处理这些问题：这里要防御，那里要抽象，这个状态不能这么放。

现在很多时候是 agent 先写，我再验。我的能力变成了另外一种形式存在。以前这些判断发生在写代码过程中，现在更多发生在验收过程中。执行可以交给 AI，验收不能交，因为验收的本质是责任分配和信任问题，目前 AI 还不能承担。

一个它做坏的例子

我遇到过一个对话流的问题。

系统里有多个对话。原来的设计是，每个对话可以单独 pending，互不影响。同时还有一个全局 pending，用来表示整体状态。

也就是说，这里其实有两层 pending。

我让 agent 修一个中间状态。它修完以后，用了一个单例 pending。

结果就变成：第一个对话 pending 的时候，第二个对话也不能继续聊了。

原来应该是：

conversation A -> pending A
conversation B -> pending B
conversation C -> pending C
global -> overall pending

它改成了：

conversation A/B/C -> one pending

这个问题不是语法错误，也不是少写了一个判断。它把状态维度改错了。

而且我不是读代码发现的。我是在测试别的功能时发现：一个对话 pending，会影响另一个对话。

然后我让它 debug。过程大概是这样：

1. 它一开始说，代码就是这么设计的。
2. 我继续问，为什么要这么设计。
3. 我让它从 git log 看看，这个设计是什么时候变成这样的。
4. 它解释完以后，我才意识到问题在哪里：它只看到 pending 这个状态，没有理解这里需要两层 pending。

这类问题很常见。AI 修局部问题时，可能会改坏系统原来的语义。尤其是状态、并发、作用域、所有权这些地方，它很容易把复杂结构压成一个简单结构。

但我不会因为这个就不让它做。

这种错可以接受。关键是我能发现它，让它解释，再把正确模型补进去。下次再遇到类似情况，这个信号应该被记住。

记忆不要都塞进 agent.md

我写了一个记忆系统，用来记录这些判断。

不是把所有东西都永久塞进上下文里。它会蒸馏，也会遗忘。如果一条经验长期没被用到，那就忘掉。忘了说明它没那么重要。

很多人会把这些内容放进 claude.md 或 agent.md。比如：不要把 pending 写成单例；这个项目里 pending 有两层；某个组件不能这么改。

我现在不太喜欢这样做。原因不是 agent.md 没用，而是它和 memory 的职责不一样。

agent.md 适合放少量稳定规则，比如项目命令、编码规范、绝对不要做的事情。它不适合越写越长。

原因也很简单：它是常驻上下文。每次都加载。内容越多，干扰越多。而且项目一直在变，早期写下来的设计不一定还对。

我更倾向于把经验放进 memory。memory 是按场景触发的。只有遇到相似问题，它才应该出来。

代码本身应该是最高优先级。项目现在是什么样，应该先看代码，而不是先相信一份很久以前写的说明。

所以我的原则很简单：

1. agent.md 要少。 只放稳定规则和项目约束。
2. memory 可以多，但要能忘。 它应该按场景触发，而不是每次都出现。
3. 代码永远优先。 当前代码比旧文档更可信。

这件事对我很重要。因为 AI 编程最麻烦的不是它没上下文，而是它带着一堆过期上下文还以为自己懂了。

不要一直停在结对编程

AI pair programming 当然有用，但如果一直停在那里，人还是很累。你说一句，它写一段；它错了，你改一段；你再解释，它再写。这样看起来用了 AI，但人的注意力一直被绑在每一步上。

我现在更想要的是让 agent 自己先跑几轮：先做，自己检查，自己修。 多轮之后，我再看剩下的问题。

大概流程是这样：

agent 执行
agent 自检
agent 修正
agent 再执行
human 验收
human 提供判断
memory 记录判断
下一轮继续

测试它自己会跑，但我不会要求它每次都跑，太慢，只有有价值的地方才补测试。UI 我会先看 pixel diff，再自己点页面，因为 UI 很容易被它改坏。Network 我会让 Chrome 持久化到本地，因为请求数量、请求参数、过滤条件，这些都是真实行为的一部分。多轮 review 我也会用，但我不希望它每一步都问我。

我希望它有一条固定路径：该查就查，该跑就跑，该看日志就看日志。它自己判断哪些值得做，不要每次都等我确认。这里的变化是，我不再当低级调度器。我只定边界，最后验收。

以后我会先改流程，而不是先改代码

如果我要带一个 AI-native 的工程团队，我大概会要求几件事：

1. 任务先给 agent 做，不要一上来就手写。 不是说手写代码不好，而是你一手写，就绕过了这套流程。团队需要训练的是“怎么让 agent 做对”，不是继续训练每个人当手工高手。
2. 验收必须自己做。 AI 写完不代表完成，自己点一遍，自己看请求，自己看异常，自己看移动端。
3. 遇到问题时，不要急着自己修。 先想：为什么它没自己发现？为什么测试没覆盖？为什么工具没给它足够的信息？为什么 memory 没触发？为什么代码结构让它理解错？

很多时候我不应该直接修 bug，而应该修那个让 AI 能修 bug 的流程。这句话听起来有点绕，但意思很朴素：如果我每次都亲手补洞，那下次还是我补；如果我把工具、验证、记忆、代码结构改好，后面同类问题就可以少找我。

我早期还是会大量介入代码，重构项目，让它更容易被 AI 理解。等这个模子形成以后，我改得最多的就不是业务代码了，而是工具能力和验收机制。对我来说，收益最大的两个东西是 pixel diff 和 本地记忆系统。pixel diff 让验收变简单，本地记忆系统让我不用反复解释同一类问题。这两个东西比多写几个 prompt 模板有用。

我相信 AI 的解释，但是不相信 AI 的结论

当 agent 修 bug 失败时，我不会马上告诉它答案。我会先让它 systematic debug：先复现，再找原因，再解释代码路径。它要说清楚现象是什么，原因是什么，为什么这个修法能解决，以及怎么验证。我相信解释，不相信结论。 如果它解释清楚，我就继续让它做；如果它开始前后矛盾，我会新开一个对话，让它先总结事实。

这不是重来，只是清理上下文。一个对话太长以后，经常会混进很多错误假设。继续在里面追问，只是在坏上下文上继续打补丁。该丢就丢，该总结就总结。

这也是我为什么说，agent coding 的核心不是 prompt，而是反馈回路。Prompt 追求一开始说清楚，但真实开发里，一开始很难说清楚，很多判断要等东西跑起来以后才会出现。所以我现在的做法是：先让它做一版，尽快得到一个可以验收的结果，然后我用工具、运行结果和自己的判断去纠正它，重要的纠正再进入 memory 和流程。

我不是不写代码了，只是我越来越少把第一反应放在“这段代码我来写”上。我更关心的是，下一次类似问题，AI 能不能自己发现，自己解释，自己修好。这就是我现在理解的 agent coding。

这一年，AI 把我的工作一项一项地接过去了。我并没有因此感到慌张，因为我做的事情已经变了：我不再盯着某一段代码，而是盯着整件事怎么跑起来。

我已经很久没有亲手写过任何一行代码了。倒不是写不动，而是看上去不划算。我一晚上指挥 AI 干活，比我自己一周写的还多。这一年我干的事情越来越不像具体的 coding，更像是同时盯着一群 AI 在干活，看哪个地方可能出问题，哪个地方做得不对。

我想从一件很小的事情讲起，因为这件事情就是我转变的开端。

那天我让 AI 帮我做了一个输入框，类似 SQL 编辑器那种：打字时弹出提示，让你选字段、选函数。它改了三遍，每一遍都很差。光标停在某个地方，该弹的提示不弹，或者弹出的内容不对。

直到我让它改到第四遍的时候，我突然想到一个问题。我问它："你这一块到底是怎么实现的？为什么会有这么多问题？"

它说它会用正则去匹配光标前面的字符串，匹配上哪个模式就弹哪个提示。我瞬间就明白了。因为最开始我的想法根本就不是一个正则，它应该是一棵树，有层级，光标的位置、该弹出的内容，都应该从当前这棵树的状态里面推导出来。

这应该是状态机的模式，而正则模式只能获得 80% 的功能，剩下 20% 的功能怎么都没办法实现，因为那 20% 不是靠字符串匹配能完成的，它缺乏了很多状态。

在这一刻我才意识到，原来它没有改错，它改得倒是挺诚实的。问题出在我最开始给它的方案——我脑子里想到的是一棵树，但我说给它的可能就是一个"类似开源 SQL 的会弹提示的输入框"。它就按着这一句话，老老实实地用了它能想到最简单的方法，也就是正则。

我脑海里的那些逻辑并没有告诉它，它只能按照我输出的这一点点内容去猜。后来真正让我琢磨的不是这个输入框，而是我自己的反应。我没有因为"它写不了"就自己上手写，而是回过头去问它："你是怎么写的？"

过去的我遇到自己实现不了的问题，往往是自己上手。但到那一天，我没有想着要自己做，我想的是告诉它应该怎么做。

这篇文章想要记录的，就是我怎么完成了这样一个思维转变。我并不是要说自己做得多好，而是给自己做个记录，把来时的路想清楚：我是怎么一步一步，从每一行代码都自己写，走到最后任何一行代码都不再亲自动手的。

一、我不再自己写代码了

过去的我相信一件事：代码得是我自己一行行写出来的，我才放心。

这不是固执。你自己写的东西，每一处为什么这么写，你都清楚；出了问题，你知道去哪儿找。这种心里有底的感觉，是一个干了很多年的人最看重的东西。

现在我不写了。我让 AI 写，我只看它写出来的东西对不对。

刚开始我很不适应，总忍不住去读它写的每一行，一读就想动手改。但我很快发现根本读不过来——它一晚上写的代码，比我一周写的还多。我要是逐行读，那还不如自己写。

被逼到这个份上，我才认真想了一个问题：我到底应该 review 什么。

想清楚之后，我就不读代码了，我改成看功能。

我不管它里面怎么实现的，我只问一件事：我能想到的那些边界情况，它有没有都处理到。还拿那个输入框来说，我就一个场景一个场景去试：光标在中间删字符会怎么样，粘贴一大段进来会怎么样，中文输入法还没上屏的时候会怎么样。这些都过了，我就不去管它底下是用树还是用正则了。

这么一来，事情的性质就变了。

读代码的时候，我的工作量是跟着代码量涨的，它写得越多，我越读不完。可看功能的时候，我的工作量只跟着"边界情况有多少"走。而边界情况有多少，是我说了算的，是有数的，是我一个人能扛住的。

再往后，我连一个一个去试的活都不太干了。现在我经常同时让一批 Agent 并行跑，它们自己写、自己测、自己 review。

说"我什么都不管"，听上去像撒手不干。但其实我盯的东西，换到了更上面。我就看三件事：这一批 Agent 什么时候会崩；崩的时候，它停在哪、留下的记录够不够我重新接上去，还是得从头再来；以及整批跑完，离我要的结果还差多少。看完这三样，我回头去改的，不是某一段代码，而是这套流程本身——哪里该加一道检查，哪里该把任务拆细一点，哪里该让它早点停下、别带着错往下跑。

到这一步，我已经不在写代码这一层了。我盯的是这批 Agent 整体跑得稳不稳、崩了能不能自己缓过来、结果按时出没出。我改的不再是代码，是这套让它们自己跑起来的流程。

但有句老实话得先说在前头：我敢这么放手，是因为"哪儿容易出问题"这张图，在我脑子里。哪些场景要试、哪个地方最容易出事、一批 Agent 崩起来通常崩在哪儿——这些是我这些年一个一个 bug、一次一次半夜被叫起来踩出来的。这张图我没办法直接塞给一个新人。后面我还会回到这件事，它是这整套做法里最不踏实的一块地基。

二、我不再先写清楚再动手了

过去的我还相信一件事：先想清楚、写清楚，再动手。

这是教科书里的规矩，也确实是好习惯。需求对齐好，规格写明白，然后照着做，返工最少，最稳。

但我现在基本不写详细的规格了。我就跟 AI 说个大概的思路，它差不多就能给我搭出一个雏形，剩下的我再慢慢拨。

这事我一开始也觉得是自己偷懒、不够专业。直到我老老实实算了一笔账。

写规格这件事，听起来很美好，真做起来全是窟窿。你以为该讲清楚的地方，它没当回事；你觉得根本不用提的细节，它反而给你铺一大堆。说到底，你跟它对一件事的理解天生就有缝，不是写了规格这缝就没了。更何况，你费劲写出来的那份规格，其实没什么人会从头读到尾——包括 AI，也包括三个月后的你自己。

所以这笔账是这么算的。一条路，是前期把规格抠到极致，指望它一次做对，代价是花掉大量对齐的时间，而且对齐完了它照样可能只给我 80%。另一条路，是我只说个大方向，拿个雏形，然后挑错、改正，省掉了前期对齐，代价是后面多纠几轮错。

算下来，第二条路更划算，所以我选了它。

但我不是把规格扔了，规格还在，只是换了个地方放。

有一部分，放进了代码里。像那个输入框的状态机，逻辑全在代码上摆着，没有藏着的隐含逻辑，我根本不担心它会"忘"——要参考，它去读代码就行，代码本身就是那份不会过期、也不会读错的规格。

还有一部分，放在我脑子里。就是那 20% 的判据：什么算对，什么算错，哪儿是它最容易偷懒糊弄的地方。这些我没写下来，因为写下来的成本，比我每次验收时在脑子里过一遍要高得多。

所以说到底，规格没有消失。它只是从"动手之前的一份文档"，变成了"动手之后我心里的一把尺子"。

但这条路有个我必须承认的前提：它之所以便宜，是因为我的眼力在替它兜底。

我敢只说个大方向就放它去跑，是因为雏形拿回来，我一眼能看出那 20% 错在哪、该怎么拨回去。换一个刚入行的人走这条路，会摔得很惨——他看不出那 20% 错在哪，会把 80% 当成 100% 收下，然后那 20% 在某个深夜的线上事故里爆开。对他来说，纠错的成本几乎是无穷大，因为他根本不知道要纠什么。

所以我敢不写规格，靠的是脑子里那套判断标准还在。说到底，敢不写规格和敢不自己写代码是一回事，靠的都是我自己那点判断力。

三、我不再手把手带人了

过去的我觉得，经验是要手把手传的。老人带新人，坐一块儿，一个 bug 一个 bug 地讲，讲透了，人就带出来了。

这事我现在也不太做了。倒不是不想带人，是我发现人传人这条路损耗太大。每个人的判断标准不一样，你觉得天大的事，他觉得没什么；同一句话，传到第三个人那儿，就全变味了。

我现在做的，是给团队搭一套系统，让大家都在这套系统里用 AI。我不去一个个校准每个人脑子里的标准，我去校准那套系统。

系统里头，传承靠的是让 AI 自己留记录。它干完一件事，会写下它具体做了什么、踩到过什么坑、最后怎么绕过去的。下一个人——准确说，下一个人手里的 AI——接手时，能把前面几任留下的记录全翻出来看。前面的人栽过的跟头，后面的人不用再栽一遍。

关键在这儿：这些记录，不是给人看的，是给各自的 AI 看的。AI 记得住就行，人不需要自己记。

这一下，传承这件事的主角换了。过去是老工程师教新工程师，现在是上一个 AI 给下一个 AI 留笔记。为什么这条路反而更靠谱？因为人和人之间传东西会失真——每个人的理解都带着自己的滤镜。可 AI 和 AI 之间传的是文本，是白纸黑字。它不会因为"我以为你懂"就把话说一半。

光有记忆还不够，这套系统还得有规矩。我给团队立了三条，每一条都不是凭空想的，是我自己一次次摔出来的：

第一条，任务直接交给 AI 去跑，不许自己上手写。 这条主要是给老手定的，也包括我自己。一个干了很多年的人，看 AI 磨磨蹭蹭，最容易忍不住一把接过来，"我自己两分钟就写完了"。可你一接手，就又退回到了自己写代码的状态，这套系统对你就白搭了。忍住不去抢这一手，是进门的第一关。

第二条，验收必须自己亲手跑一遍。 不许它说一句"我测过了，没问题"你就收下。它说它好了，和你亲眼看它好了，是两回事。你可以不读它的代码，但你必须亲眼看见那个功能在你面前跑对。这一条，是专门用来挡掉那种看个 demo 就过的习惯的。

第三条，也是最狠的一条：你不许直接去把问题解决掉，你得先退一步，看是系统哪里不够细，才让 AI 没能自己解决。 一个 bug 摆在面前，人的本能是上去把它修了。但在这套系统里，这是不许的。你要问的是：它为什么没能自己修好？是上下文里缺了什么？是哪条要求没说清楚？然后你去补那个系统层面的东西，让这一类问题，它下次自己就能解决。

第三条，其实就是开头那个输入框故事的延伸。同一个地方反复出问题，别忙着一遍遍去修它，得想想是不是这套东西本来就不该这么设计——我把当年那个一闪而过的念头，变成了团队里一条不许违反的规矩。

当然，这套系统现在还很糙。AI 写的那些记录质量参差不齐，该记的没记，不该记的记一堆，还得有人时不时去盯一眼、收拾一下。它离"能自己转起来"还差得远。但这个方向我是认的，也一直在调它。

至于最核心的那个判断力——什么是好、什么是坏，什么时候该停下来问一句"你这是怎么做的"——这个我承认，现在没法教。它跟写规格是一个道理：你交代不清楚的地方，它就做得差。这东西长在人心里，传不出去。

四、每交出去一份活，我接回一份更高的活

把前面这三件事连起来看，我这一年的方向其实已经清楚了。

我不再自己写代码，改成看 AI 写得对不对；我不再先写规格，改成事后凭经验判断它做得好不好；我不再手把手带人，改成给团队搭一套能自己积累经验的系统。

这里有个我后来才看明白的规律：我每把一份活交给 AI，并不是把这份活白白丢掉，而是从它那儿接回了一份更高维度的活。写代码交出去，我接回了对功能的判断；写规格交出去，我接回了对取舍的判断；带人交出去，我接回了对整个系统的设计。每一次交出去，换回来的都是更值钱的东西。

到现在，我已经不太关心某一段实现跟我想的一不一样了。我看这件事的角度更高了——说得书面一点，有点像控制论：把这一群会自己做决定的 AI 当成一个系统来设计，让它跑得又快又不出格。这两年大家管这个叫 harness，叫 agentic engineering，名字不重要，重要的是我做的事变了——我从一个在系统里干活的人，变成了一个设计这个系统的人。

我愿意把这个过程叫"赢"。

但这个"赢"字我得说清楚，不然听着像吹牛。

我赢的不是"我学会了用 AI"，那不叫赢，那叫没掉队。我赢的是这个：同样一件事——AI 把我手里的活接走了——慌的人会说"我的工作被它抢了"，而我说的是"它帮我把脏活接走了，我腾出手去做更值钱的事"。我们看到的是同一件事，说出来的是相反的话。

我也不想把这个"赢"说得多漂亮。这一年我没少认怂，没少算账。我不写规格，不是因为我境界高，是因为我算过账，写了不划算。我能做现在这些事，靠的是前面那些代码我全自己写过、那些坑我全自己踩过。说白了，能接回更高的活，前提是你在底下扎扎实实干过很久。

我还没交出去的那样东西

说一句老实话：我上面讲的这一整套——只看结果不看实现、让 AI 自己积累经验、用控制论的角度去设计整个系统——它现在还没真正建成。

我敢只看结果不看实现，靠的是我脑子里那张"哪儿会出事"的图，这东西交不给下一个人。AI 之间传经验，靠的是它自己写的、质量飘忽的记录，还得人盯着。至于那套用控制论搭起来的系统，现在还只是个方向，不是个能用的东西。这中间缺的基础设施，是一大块。我知道它重要，但我现在也没太多精力把它推起来。

所以这篇文章，与其说是在讲一件我已经做成的事，不如说是在记一个我看见了、但还没真正走到的方向。该走的路我大概知道在哪，但路还没修好。

最后，还有一样东西，我到现在也没交出去——判断。

什么是对、什么是错，什么时候该停下来问一句"你这是怎么做的"，这个我还攥在手里。写代码、写规格、带人，我都交出去了，就这一样，还在我手上。

这件事听起来可能有点矛盾。我的判断力，是从我自己的工程经验里长出来的；而我现在搭的这套系统，靠的是反复调试。但说到底，调试调到哪儿、什么时候停，还是得靠我的判断。判断和系统，不是两件事，是一件事的两头。

可这里有个让我有点发怵、又有点兴奋的念头。判断是怎么来的？是踩坑踩出来的。而我现在正想亲手搭一个系统，让 AI 自己去踩坑、自己记下来。那么，那个我嘴上说"教不了、只能靠人自己踩出来"的判断力，会不会有一天，也被这套系统一点一点，从人脑子里挪出去？

真到了那一天，我今天站的这个位置——控制论也好、设计系统也好——也不过是个临时的落脚点。它接走了我写代码的活，接走了我写规格的活，接下来会不会连"判断"也接走？

到那时候，人还能干什么？

我不知道。但有一件事我知道：今天的我，已经不是去年那个一撒手就慌的人了。这一年我把写代码、写规格、带人一样一样交了出去，每交一样，都从 AI 那儿接回了一份更高的活。判断要是哪天也能交出去，那我就去接它再上面那一层——我还不知道那是什么，但我赌它在。

The 9 AM Inbox

The first thing I do every workday is batch-process whatever the AI left behind overnight.

Reports generated while I slept. PR drafts auto-opened on the codebase. Meeting notes the Agent assembled and tagged me into. Tickets stuck at some decision point waiting on my call. And a handful of escalations: "I think you should look at this one."

Coffee in hand, about 40 minutes. I go through them one by one. This PR is going the wrong way, reject. This report has the right thesis, just needs two more numbers. This ticket can run through automated repair. That customer complaint has a thread under it I want to pull myself. Then humans and AI go their separate ways for the rest of the day. I head to meetings. It goes off to do work.

I've been doing this for the better part of a year. The other day it hit me: the first hour of my workday is essentially managing a team of machine subordinates.

I sat there feeling slightly disoriented. When I manage humans, I have to read their emotions, give feedback, plan their careers. When I manage these machine subordinates, all I do is approve, reject, redirect, dispatch. The latter is an order of magnitude more efficient. It's also colder. Two ways of working are slowly diverging inside me.

Over the past six months I've been mapping out what I've seen, built, and broken along the way. This map isn't an academic framework. It's more like a sketch someone draws for themselves at 2 AM when they can't sleep, trying to make sense of the change happening around them. The questions it answers: where are we actually, what's still ahead, which traps are real, and which hype is fake.

I call it the five-layer model of AI-Native.

Layer 1: Writing Code for You

The earliest use of AI was personal. People delegated their own work.

The clearest case is code. Once Cursor stabilized, my engineers basically stopped writing first drafts by hand. Requirements come in, they have a conversation with the AI, get a draft, then refine it. Same with documents. Weekly meeting notes drafted by AI, then polished. Review materials drafted by AI, then re-thought.

The fundamental difference between Layer 1 and "before AI"? The tool changed. The work didn't. People are doing the same things, just with a more efficient executor. Same kind of shift as moving from Vim to VSCode, or from SVN to Git.

Its boundary is also clear: AI only serves "me," the individual. It doesn't know what big project our department is working on, what request the team next door submitted last week, or why my boss is angry today. It's a very capable tool sitting on my desk.

The unexpected side effect: my engineers' coding time dropped from 6 hours a day to 2. Where did the other 4 go? Meetings. Alignment. Politics. Approval workflows. After Layer 1 lands, you'll hear engineers complain about meetings.

The complaint is valid and also wrong. What AI took away wasn't 6 hours of coding. It was 6 hours of "this logic is complex, I need to focus." With AI knocking out that logic in half an hour, the engineer has to actually face the meetings.

At Layer 1, the organization is the same organization it always was. AI just lights up on each engineer's desktop, individually.

Layer 2: Inside the Workflow (where we are now)

The mark of Layer 2 is that AI moves from serving individuals to serving processes.

Let me paint a concrete picture of what this looks like.

Our department's Lark groups used to have a few internal-support people as the busiest role. Starting at 9 AM, PMs, QAs, and account managers would throw questions in: "Has the launch plan changed?" "Where is that customer's compliance approval?" "Who got assigned that P3 ticket from yesterday?" 80% of these questions were repeats. 20% had standard answers. Only a small fraction actually required judgment. That repetition used to consume several headcount.

Now we have a Q&A bot in those groups. It reads the knowledge base, the ticket system, the release calendar. Most repeat questions get answered directly. It also takes meeting notes, syncs them into Lark Docs, and tags the relevant people. It pre-processes IT tickets. Simple things like resetting a test account or granting a development permission, it handles itself.

The fundamental difference between Layer 2 and Layer 1? AI moved from "personal desktop" into "team infrastructure." It no longer serves a single engineer. It serves the workflow. Its inputs and outputs are embedded in the team's daily collaboration.

But it has a clear ceiling: it's still purely reactive. You ask, it answers. Otherwise it sits there.

I figured out where that ceiling was during a production incident.

The root cause was buried in a Lark message an engineer had posted two weeks earlier. In a project group with 40-some people, he'd casually said: "I looked at this change. The reconciliation logic on Y business line might be affected." Some people sent a quick "got it." Some didn't see it. He himself forgot.

Two weeks later, Y business line's reconciliation actually broke. Customer complaints. Compliance escalation. The trail led back to me. The retrospective stung. The AI had "seen" that message all along. It had taken the meeting notes for that project. It had handled IT tickets in that group. It had even translated that message for the overseas team. But it had no concept of recognizing risk.

It processes messages without reading them. It assembles minutes without understanding which decisions in those minutes have no follow-up. It answers questions without asking "why hasn't anyone asked this before?"

That's where Layer 2 stops. It frees your hands. It doesn't free your eyes or your judgment.

This is mostly where we are. The wins at Layer 2 are easy to claim. Stand up a Q&A bot, drop in a meeting-notes tool, ROI shows up in two weeks, the slide deck for the boss writes itself. So plenty of teams stop here and call themselves "AI-Native."

They've installed a smarter customer service rep.

Between Layer 2 and Layer 3: The Real Wall

The gap between Layer 2 and Layer 3 hides one obstacle most people don't articulate: context.

"Context" decomposes into four progressively harder problems. Let me walk through them.

Step One: Extraction

Before the AI can do anything, it has to know what's actually happening.

A customer issue comes in. What the AI needs to grasp is the entire story behind that single message: who is this customer, what have they complained about in the past three months, what's their contract tier, who last touched the feature they're complaining about, was the change properly reviewed, did monitoring fire any alerts at deploy time?

That information lives in CRM, the ticketing system, Git, Jira, monitoring, the release system, Lark groups, and Lark Docs. Each system has its own API, its own field naming, its own permission model. The "customer" entity alone is called customer_id in CRM, account in the ticket system, "customer number" in the contract system, and "entity code" in the compliance system. Four ID schemes. Nobody can give you the complete mapping.

Just getting the AI to extract "what just happened" requires a massive amount of translation work first.

Step Two: Retrieval

The present isn't enough. The AI has to dig backwards.

When an error log surfaces in production, the information that actually determines how to fix it might be buried in an architecture review meeting from three months ago. That edge case got discussed back then, a workaround was chosen, a TODO was left, nobody followed up.

Asking the AI to retrieve means it has to walk back from today's symptom to that meeting, that document, that decision, that specific person. The longer the retrieval chain, the more times the AI has to "jump." Each jump reloads context. Each jump is a non-trivial cost. Not just in tokens. Each hop also risks losing critical signal or wandering off course.

Step Three: Linking

You've extracted, you've retrieved. Now connect them.

Knowing "this customer raised this issue" isn't enough. The AI has to link this customer issue with last week's code change, with the monitoring curve from that day, with the compliance constraints involved, with the priority ranking in the product roadmap. It has to see the whole picture in one frame.

This is brutally hard because those five tables belong to five different departments: customer service, engineering, ops, compliance, product. Each department has its own data governance standard. Some department's core data isn't even digitized; it lives in some director's head.

The actual work is data integration, schema unification, and cross-department permission coordination. Almost none of it has anything to do with training models.

The irony is that the difficulty isn't AI's fault. This is a "data platform" problem we should have solved a decade ago. We got away with deferring it. AI has finally made the cost of fragmented context impossible to defer: yesterday it just meant a few extra arguments in meetings; today it deadlocks your Agent.

Step Four: Permissions and Organizational Gravity

The last step is the hardest, because it isn't a technical problem at all.

The AI needs cross-system data access, and access requires permissions. An Agent that wants to read CRM data needs customer service to authorize it. To read code in Git, it needs engineering's authorization. To read compliance records, it goes through legal. Every additional layer of org structure is another door.

And these doors were designed for humans, not Agents. When you grant a permission to an engineer, their manager signs off, their job description backs it up, and if something goes wrong you know who to go to. When you grant a permission to an Agent, who signs? Who's accountable? Who answers when it breaks something?

We had a discussion in our department about granting an Agent read-only access to production. Three meetings. Compliance, security, ops, legal all in the room. We didn't do it. The technology was perfectly capable. Nobody was willing to put their name on the dotted line.

The deeper the org hierarchy, the higher the cost for AI to traverse context. In a 30-person startup, AI getting any data is one config line. In a 3000-person business line, AI getting the same data crosses three departments, five tables, eight approval nodes.

This is organizational gravity, not a technical problem.

In our dev environment, the "log to code" loop is fully wired. The AI reads an error log, links to the relevant code, drafts a fix PR. End-to-end, it works beautifully on test data. We still don't trust it in production. The data pipeline has dead spots. The permission model isn't ready to grant production read access. The accountability question isn't settled.

This wall has held us up for about two quarters. I now understand why so many large-company AI projects end as "internal demos." The bottleneck isn't technology. It's that context can't traverse the org.

Layer 3: Where It Gets Surreal

If you can clear the context wall, Layer 3 starts becoming real.

This layer still feels unreal to me, even now. Building it isn't actually that hard once the plumbing is in place. What surprises me is the picture you see once it's running.

Here's what I want to see, and what we're starting to see in dev:

One morning, an account manager forwards a customer complaint into Lark: "Your XX feature has been slow this week. Our backend batch job keeps timing out."

In the past, this message would start a long relay race. Account manager tags PM. PM tags engineering lead. Engineering lead asks the group, "anyone know about this?" Someone remembers a code change last week, tags the engineer. The engineer pulls up monitoring, digs through release notes, finds the PR, finds the logs. Two or three hours later. Customer still waiting.

At Layer 3 it goes like this: the Agent reads that message (it's in the group, with proper context permissions) and autonomously does the following:

It retrieves: this feature had a release last week. PR #4823.

It links: the P99 for this feature jumped from 800ms to 2.4s. The spike timing matches the deploy.

It extracts: the diff in PR #4823 contains a batch query pattern that probably degrades under high data volume.

It escalates: in the oncall channel, it tags the original author Zhang San, the on-duty oncall Li Si, and the account manager. "I've located this customer issue. Likely related to PR #4823, batch query performance. Recommend escalating to P2. Draft fix is in the PR comments. Please review."

It reassures: in the account manager's DM: "Issue located and escalated. Estimated 2-hour turnaround on a fix proposal. Standby."

This entire sequence happens while people are still sipping morning coffee.

The fundamental difference between Layer 3 and Layer 2? AI moved from reactive to proactive. Layer 2's AI is a "ask and you shall receive" customer service rep. Layer 3's AI grew professional instinct: it identifies risk on its own, pulls in the right people, finds the code, drafts solutions, reports progress upward.

The key inflection point: what really changes is that AI shows professional judgment for the first time, not that AI can write code. That instinct used to take two or three years to develop in a junior engineer. What counts as urgent, who to tag first, when to escalate, when to handle alone. AI has it now.

My one-word evaluation: surreal.

What's surreal? Through Layer 2, every AI action followed a "you click, it moves" pattern. From Layer 3 onward, it acts on its own. When you sit down at your inbox in the morning, you find that half the items already have the prep work done. You're just there to say yes or no, to provide the final judgment.

The boundaries remain. It can draft, but it can't decide. It can escalate, but it can't prioritize. It can tag people, but the person tagged still has to read the context, make the call, and write the code.

And writing code, at Layer 3, still doesn't go back to AI. Not because AI can't write code; it has been able to do that for a while. The hard part is knowing what to fix, where to pull the context from, and how to verify the fix is correct. Code is the easy part. Knowing "what to fix, why, and how to know it's working" is the actual substance of engineering. That still takes a human.

Layer 3 grew AI eyes and a mouth. Not yet hands.

Layer 4: Full-Loop Autonomy (imagined, not yet seen)

About Layer 4 I owe you honesty: we're on the road, and the road is long.

Here's the picture: a production log surfaces an anomaly → Agent catches it → reproduces it → locates the code → writes the fix → writes tests → runs CI → opens the PR → rolls through canary → reads AB data → decides on full rollout → monitors regression → closes the ticket.

End-to-end observable. End-to-end traceable. End-to-end reversible. If anything goes wrong you can see exactly what decision the Agent made at every step, and you can pull any step back to redo it.

The fundamental difference between Layer 4 and Layer 3? AI finally grew "hands." Layer 3 still passes the ball back to humans. It locates, drafts, escalates, then waits. Layer 4 catches the ball and runs the whole track. Not just "identifying the problem." Actually "solving" it.

Going from dev to production hits a stack of unsolved problems.

First: rollback. What happens when the Agent ships the wrong fix? A bad release can mean millions in customer losses, a regulatory compliance incident, reputational risk. In the human world this runs on SRE intuition, on-call instincts, the "let me roll this back fast" reflex. In the Agent world, you have to write all of that down as an explicit protocol. What metric change triggers an auto-rollback? How fast counts as "fast"? How do you reconcile state after the rollback? What if you can't?

Second: accountability. The Agent shipped a bug, the customer took losses, who's responsible? The engineer who approved the PR? The team that deployed the Agent? The company? In any regulated environment this question is lethal, because regulators trace back to individuals. Regulators don't accept "the AI did it."

We had an internal meeting about this. Three hours. No conclusion. There was no technical obstacle. There was nobody in the org willing to put their name on the line.

Third: observation cost. The more autonomous the Agent gets, the less people see what it's doing. By the time you notice it's doing something stupid, it might already have done it ten thousand times. What does this mean in practice? One day you might receive a phone call from compliance telling you the Agent has been quietly committing a small infraction for three months, only just discovered today.

I've previously described this as a "log-driven autonomous repair loop." That's basically Layer 4: let real production data drive the Agent's workflow directly. Humans only show up at critical decision points. But where exactly are the critical decision points, how to define them, who defines them, and who carries the accountability when things go wrong? Those are still open questions for us.

Layer 5: The Final Interrogation

Layer 5 isn't really a new capability. It's a set of questions.

The core question: is your entire enterprise architecture friendly to AI?

The fundamental difference between Layer 5 and the previous four? Layers 1 through 4 ask "how do we use AI to do work." Layer 5 asks whether your company has earned the right to use AI at all.

Sounds dramatic. It's actually very concrete. Broken down:

When a production bug occurs, can the AI see the full event? Logs, traces, user behavior, context: are these instrumented in a place it can read? Or are they scattered across seven systems that even humans can't reconcile? (This is exactly the wall we're stuck at between Layers 2 and 3.)

When a requirement comes in, can the AI know its origin and context? Is this a real customer scenario, a sales promise made to close a deal, or a PM's stray idea? The layers go further: is it a compliance requirement? A regulatory mandate? A casual remark from a senior exec? Has that context been written down somewhere an Agent can find it? Or does it live only in some director's WeChat history?

Can the right issues escalate? Does your Agent have the cross-team, cross-permission, cross-tool passport it needs, or does it hit a wall every time it crosses a boundary? In a pyramid-shaped org, this is brutal: a permission grant takes five approvals, the Agent waits three days for a single hop.

Is your code documentation written for AI? Notice the framing: for AI, not for the next human. Standards differ. Documentation for humans tolerates ambiguity, tribal knowledge, "you know what I mean." Documentation for AI must be explicit, self-contained, and fully contextualized. Most legacy system documentation is illegible to an AI.

Layer 5 is an organizational problem. Technology has very little to do with it.

It means every process, document, permission, and tool in your company has to be re-examined: is this AI-friendly? If not, every capability you built in Layers 1 through 4 will get cut off at the knees here.

I've watched too many AI projects end as "internal demos" or "pilots that quietly faded." They put serious effort into building Agent capabilities, only to find the Agent can't actually run. Log structures inherited from a decade ago. Requirement docs scattered across three different collaboration tools. Key judgment that exists only in one person's head. Cross-department permissions that take three weeks to provision.

The Agent stands there. It can do everything. It can do nothing.

Beyond Layer 5: Do We Still Need a Company?

Layer 5's interrogation isn't actually finished here. If you really do remake your organization into an "AI-friendly" form, something deeper than "efficiency gains" happens: the headcount structure of the company gets fundamentally rewritten.

Let me put a stake in the ground: functional specialization itself may need to be rewritten from the ground up.

The corporate architecture we run today is, at its core, inherited from the assembly line. Break a big task into many small pieces, hand each piece to a specialist. The assembler only assembles. QA only QAs. Procurement only procures. Legal only reads contracts. Compliance only watches compliance. Product only draws product. Engineering only writes code.

Why this division? Because human bandwidth is finite. The amount of context one person can hold in their head is bounded, and so is their attention. Ask a single person to do assembly, QA, and procurement simultaneously and they'll fail at all three. So narrower and more vertical means more efficient. This has been the first principle of organizational design since the Industrial Revolution.

AI doesn't have this constraint.

AI can run ten parallel things you've handed to it without worrying about attention. Its "bandwidth" depends almost entirely on whether the context you give it is rich enough and the rules you've defined are clear enough. The implication: once a person has AI in hand, the territory they can effectively cover expands from one narrow line to a wide area.

The old game asked for depth. The new game asks for breadth.

The old archetype was an expert who drilled all the way to the bottom of one domain. The new archetype is a "deep in one, strong across many" composite professional: someone who deeply understands their own primary field, can hold their own across several adjacent fields, and is fluent enough with AI to run all of those fields in parallel.

The implications for org design are radical.

HR, admin, procurement: these are all transactional process departments at their core. In an AI-Native company, these three could collapse into a 5-person "operations platform" team, with everything else running on AI.

Legal and risk control: both fundamentally do compliance judgment and risk identification. These departments often have hundreds of people each, but the underlying logic is the same. Merging them into one team after AI-Native arrives makes complete sense.

Product and engineering is the most dramatic case. Today my department has PMs, engineers, QA, designers, and ops as five separate lines, with five leads and five reporting relationships. Once you have Layer 3 and Layer 4 AI actually running, the massive "alignment cost" disappears. The PM's mental model gets translated by AI into a code draft. The engineer's diff gets covered by AI-generated tests. The bug found by QA gets traced back by AI to its requirement origin. Five lines collapse into a single "product-engineering integrated" small team. Entirely doable.

The most striking part: most companies don't actually need that many "scientist-grade" specialists. Deep expertise still has value, but the demand for it shrinks dramatically. A mid-sized business line that used to need thirty deep specialists might in the future need five truly top-tier experts plus a roster of "breadth + AI leverage" composite professionals.

I'll be honest: this won't happen overnight. Organizational gravity is too heavy. Process inertia runs deep. But the direction is clear. Within five years, you'll see org charts get flatter, functional boundaries blur, and "uses AI as leverage to amplify output" become an implicit baseline in every job description.

This shift hasn't reached its endpoint. Push one more step and a sharper question shows up.

Is the Company Itself Still Necessary?

Economics has a classical explanation called the Coase theorem: firms exist to reduce the transaction friction that arises when groups of people try to coordinate on the open market.

The argument: if you want to build a car, in theory you could find 100 independent workers in the market and have each one do a piece by contract. In practice you don't, because finding 100 people, signing 100 contracts, coordinating 100 schedules, and resolving 100 disputes adds up to absurd transaction costs. So you form a company, hire those 100 people, and replace market transactions with internal management. The friction gets "internalized."

A company, fundamentally, is a container for friction reduction.

But what happens if AI-Native genuinely shrinks organizations down? What if a 500-person business line becomes a 50-person composite team plus an army of Agents?

The friction surface area of 500 people is enormous: hiring, training, performance reviews, promotions, office politics, cross-team coordination, compliance audits, culture work. Those "internal frictions" are themselves a massive cost. The reason a company is worth existing is that the "external frictions" it eliminates exceed the "internal frictions" it generates.

50 people drops the friction surface dramatically. What about a 10-person, or single-person "company"?

When a group becomes a handful, the friction between that handful and society shrinks from a large fire to a few sparks. At that point, the value of "company" as a friction-reduction container decays rapidly.

So what's the ultimate form of AI-Native?

Possibly something we can't fully see yet: a small core of human talent, plus a dispatchable swarm of AI Agents, interfacing directly with the market through "project-based" or "collaboration network" arrangements. No pyramid. No departments. None of the middle layer that exists purely to coordinate hundreds of people.

Sounds like science fiction. But trace back through every layer of the model: AI writes your code, AI enters the workflow, AI recognizes risk, AI closes the loop, the organization becomes AI-friendly. Each layer strips away something that existed only to "coordinate a group of people." Strip past Layer 5 and keep going, and what you're stripping is the company itself.

I don't know whether our generation will actually live to see that day. But I can already feel the direction of the gradient.

Pushing AI-Native through an organization of several thousand people, every step forward triggers the same voice in my head: are you helping the company become more efficient, or are you making the company less necessary?

This question doesn't have an answer. I'm not going to manufacture one. But everyone walking the AI-Native road will, sooner or later, have to face it.

Notes in the Margin

Looking back across the five layers and the unnumbered question after them, what's actually changing isn't the technology. It's the shape of the question.

Layer 1 asks: can AI write code? Layer 2: can AI enter the workflow? Layer 3: can AI recognize risk? Layer 4: can AI close the loop? Layer 5: can the organization let AI close the loop? After Layer 5: once the organization actually changes, does the company itself still need to exist?

The first four are problems a single function can drive. The fifth isn't. Layer 5 requires the CEO, CTO, HR, legal, compliance, and finance to remake the company together: rewriting process documentation, redrawing permissions, redefining KPIs, redefining roles. Most of this gets deferred. It's hard, the short-term ROI is invisible, and every change touches departmental fiefdoms.

The question after Layer 5 sits beyond any single role's reach. It's beyond what a single CEO can decide. It's a question this company, this industry, and this generation have to face together.

But you can't actually defer it. The AI-Native window won't stay open forever. When your competitor is operating stably at Layers 3 and 4 while you're still hiring people to fill in meeting notes at Layer 2, the gap between you isn't technical. It's a generational gap in how the organization is built. Push the timeline further: when your competitor has started redrawing functions, merging departments, and flattening their org chart, while you're still defending a traditional pyramid, the gap stops being a generational gap. It becomes a species-level gap.

I'm under no illusion that drawing the map is the same as walking it. My team is the proof. We tasted the wins at Layer 2, got stuck at the "context" wall for two quarters, barely have a Layer 3 prototype running in dev, can only imagine Layer 4 in our heads, every Layer 5 question is biting us right now, and the question past Layer 5 we haven't even started touching.

If this map can leave anything to those walking the same stretch of road, it's one line: don't wait for "AI to mature." The people who wait won't win. The people who walk and edit the map at the same time will. This matters more in heavyweight environments with deep hierarchy and slow processes, because every step there is three times slower than at a startup. The earlier you move, the earlier you start clearing the decade-old debt that's been deferred, and the better your chance of standing at Layer 3 or Layer 4 when the window starts closing.

Those 40 minutes every morning batch-processing the inbox might look like a side effect of a new way of working. It's actually a new organizational form leaning over me, asking for a decision.

Every time I shut my laptop and head into a meeting, I find myself asking: will the time I spend managing those machine subordinates one day exceed the time I spend managing humans? If it will, this company's shape is going to need redrawing.

And one layer deeper: that redrawn shape may not be a "company" at all anymore.

AI 推到第三个季度，我发现自己每天 40 分钟在 inbox 里批准、否决、改方向、派任务，处理的全是机器昨晚交上来的作业。这件事比管人冷得多，效率也高一个数量级。然后某天我意识到一个挺荒诞的问题：我正在帮公司变得更高效，还是正在让公司变得不再必要？

早上九点的 inbox

我现在每天上班的第一件事，是打开电脑批处理 AI 留下的一堆东西。

过夜跑出来的报告、自动起草的 PR、Lark 里它整理好的会议纪要和 @ 我的待办、卡在某一步等我点头的工单、还有几条它升级上来的“我觉得这事得你看看”的提醒。

一杯咖啡，大概 40 分钟。我会挨个过：这个 PR 改的方向不对，打回；这份报告主线对了，细节再补两个数；这个工单可以让它走自动修复；那个客户反馈背后藏了一根线，我得自己去看一下原始上下文。处理完了，人和 AI 重新各自上路，我去开会、它去跑活儿。

这个动作我做了大半年。最近某天我突然意识到一件事：我每天上班的第一个小时，本质上是在管理一群机器下属。

那一刻我有点恍惚。我管人的时候要照顾情绪、要给反馈、要做职业发展规划；我管这群机器下属的时候，只需要批准、否决、改方向、派任务。后者比前者效率高出一个数量级，也冷得多。两种工作模式，正在我身上慢慢分叉。

后来我把这半年看到的、做到的、栽过跟头的，慢慢梳理成了一张地图。这张地图不是什么学术框架，更像是一个正在亲历变革的人，半夜睡不着觉时画给自己看的草图。它要回答的是：我们到底走到哪儿了，前面还剩什么，哪些坑是真的，哪些幻觉是假的。

我把它叫做 AI-Native 的五层模型。

第一层：替我写代码

最早大家用 AI，都是替自己干活。

最典型的就是写代码。我团队里几个工程师，从 Cursor 用顺之后，基本不再手写第一版。需求来了先和 AI 聊清楚，让它出底稿，再自己改。文档也一样，周会纪要 AI 起，自己润色；评审材料 AI 起，自己改逻辑。

这一层和上一层（传统人工写代码）的根本差异是什么？是工具被替换，但工作没有变。 人干的活儿没动，只是换了个更高效的执行者。和当年从 Vim 换到 VSCode、从 SVN 换到 Git 是一回事。

它的边界也很清楚：AI 只服务于“我”这个独立的个体。 它不知道我们部门在做什么大项目，不知道隔壁组上周提了什么需求，不知道我老板今天为什么发火。它就是我桌上一个特别能干的工具。

唯一的副作用挺反直觉：工程师每天写代码的时间从 6 小时降到 2 小时，剩下 4 小时去哪儿了？开会、对齐、扯皮、走流程审批。所以这一层落地之后，工程师抱怨开会变多了。

抱怨没错，但也错了。AI 抢走的其实是那 6 小时“我太忙了不能开会”的借口，代码反倒是次要的。一个工程师过去之所以能逃掉一些没用的会，是因为他可以指着显示器说“这段逻辑很复杂，我得静下来写”。现在 AI 把这段逻辑半小时就写完了，他不得不真的去面对那些会议。

到这里，组织还是原来那个组织。AI 只是在每个工程师的桌面上各自闪光。

第二层：进了协作流程（我们目前在这里）

第二层的标志，是 AI 从服务个人变成服务流程。

这一层长什么样？我可以画一个具体的画面。

我们部门的 Lark 群，过去最忙的角色是几个内部支持。早上 9 点开始，产品经理、QA、客户经理在群里抛各种问题：“上线计划改了吗？”“那个客户的合规审批走到哪一步了？”“昨天那个 P3 工单分给谁了？”这些问题 80% 是重复的、20% 是有标准答案的、剩下少数才需要真正的判断。过去这些重复劳动消耗了好几个 HC。

现在我们部门的 Lark 群里，接了一个 Q&A bot。它读知识库、读工单系统、读发版日历，绝大部分重复问题它直接答了。会议纪要也是它做，自动同步到 Lark 文档，@ 上相关的人。内部 IT 工单也走它先过一遍，简单的事情（如重置某个测试账号、申请某个开发权限）它直接处理。

这一层和第一层的根本差异是什么？是 AI 从“个人桌面”进入了“团队基础设施”。 它服务的不再是某一个工程师，而是整个流程。它的输入和输出都嵌进了团队的日常协作中。

但它有个非常明确的天花板：它仍然是被动响应的角色。 你问它就答，你不问它就在那儿待着。

这个天花板是什么时候让我看清的？是一次线上事故。

那次事故的根因藏在某个工程师两周前的一条 Lark 消息里。他在一个有四五十人的项目群里轻飘飘地说了一句：“我看了下这块改动，Y 业务线那边的对账逻辑可能要受影响。”那条消息发出来以后，有人随手“收到”，有人没看见。他自己后来也忘了。

两周后，Y 业务线的对账真的出了问题。客户投诉，合规上报，一路追到我这儿。复盘的时候我特别难受：那条消息 AI 全都“看见”过。它做过那次会议的纪要、它处理过那个项目的 IT 工单、它甚至帮人翻译过那条消息给海外团队。但它没有“识别风险”这件事的能力。

它处理消息，不读懂消息。它整理纪要，不理解纪要里哪条决议没人接。它回答问题，不去问“这个问题为什么没人问过”。

第二层的天花板就摆在这儿：它解放的是手，没解放眼睛和判断力。

我们现在主要就在这里。这一层的甜头很容易吃到。上线一个 Q&A bot、配一个会议纪要工具，两周就能看到 ROI，老板汇报的时候 PPT 也好做。所以很多团队会在这里停下来，觉得自己已经“AI-Native 了”。

其实只是装了个更聪明的客服。

第二层到第三层之间：那道真正的坎

要从第二层迈到第三层，中间隔了一道很多人没说清楚的坎：上下文。

上下文这件事有四个层层递进的难题。我们一个一个看。

第一关：摘取

AI 要做事，首先得知道“现在在发生什么”。

一个客户问题来了，AI 要看的不只是这条消息，而是消息背后整个故事的合理摘取：这个客户是谁？他过去三个月提过什么问题？他的合同等级是什么？他这次抱怨的功能上次是谁改的？改动当时通过审批了吗？发版的时候监控有没有报警？

这些信息散在 CRM、工单系统、Git、Jira、监控平台、发版系统、Lark 群聊、Lark 文档。每个系统的接口、字段、权限模型都不一样。光“客户”这一个实体，在 CRM 里叫 customer_id，在工单里叫 account，在合同系统里叫客户编号，在合规系统里叫主体代码：四套 ID，没人能告诉你完整的映射关系。

让 AI 摘出“刚才发生了什么”，这件事的工程量，主要花在大量翻译工作上。

第二关：回溯

光看当下不够，AI 要会往回翻。

一条线上 error log 出现的时候，真正决定怎么修的信息可能藏在三个月前的一次架构评审会议纪要里。当时讨论过这种边界情况，选了一个权宜方案，留了个 TODO，后来没人追。

让 AI 回溯，意味着它要能从今天的现象，反向找到三个月前那次会议、那个文档、那条决议、那个具体的人。回溯链路越长，AI 跳的次数越多，每跳一次都要重新加载一遍上下文，每一次跳跃都是一次代价不低的成本。这不只是 token 烧得快的问题，更是每一跳都可能丢失关键信息、走错方向。

第三关：打通

摘出来了、回溯到了，接下来是关联。

光知道“这个客户提过这个问题”，不够。AI 要能把这个客户问题、上次的代码改动、当时的监控曲线、合规上的限制、产品 roadmap 里的优先级排序，全部关联起来，看到一张完整的图。

这件事特别难，因为这五张表分别属于客服部、研发部、运维部、合规部、产品部。每个部门的数据治理标准不一样，有些部门的核心数据根本就没数字化、还存在某个总监的脑子里。

真正在做的事情，是数据集成、schema 统一、跨部门权限协调，跟训模型基本无关。

讽刺的地方在于，这件事的难度不是 AI 带来的。这是十年前我们就该解决的“数据中台”问题，只是过去一直能拖。AI 之所以让我们必须现在动手，是因为它把“上下文不联通”的成本从隐性变成了显性。以前数据孤岛，无非是开会时多吵几句；现在数据孤岛，直接卡死你的 Agent。

第四关：权限和组织重力

最后一关最难，因为它不是技术问题。

AI 要跨系统拿数据，绕不开权限。一个 AI Agent 想要看 CRM 里的客户数据，得有客服部的授权；想要看 Git 里的代码，得有研发部的授权；想要看合规系统的备案，得走法务的流程。每多一层组织，就多一道门。

而且这些门是设计给“人”的，不是设计给“AI”的。给一个工程师开一个权限，有他主管签字、有他岗位职责背书、出问题能找到他；给一个 Agent 开权限，谁签字？谁背书？它出问题谁负责？

我们部门有过一次讨论，讨论给 Agent 开生产环境只读权限。开会开了三次，合规、安全、运维、法务都来了，最后没敢开。技术上能做到，问题是没人愿意在这个东西上签字。

组织层级越深，AI 跳上下文的代价就越高。 在一个 30 人的小公司，AI 拿任何数据可能就是一行配置；在一个 3000 人的业务线，AI 拿同样的数据要走三个部门、五张表、八个审批节点。

说到底，这是组织重力的问题，跟技术关系不大。

我们 dev 环境里“日志到代码”这条链路已经跑通了。AI 能读到一条 error log，关联到代码，起草一个修复 PR。整条链路是闭环的，在测试数据上跑得也漂亮。但我们还不敢把它放到生产环境：数据通道还有死角，权限模型还没敢给它生产读权限，真出了事谁负责的问题还没想清楚。

这道坎卡住了我们大概两个季度。现在我特别理解为什么很多 AI 项目最后都搞成了“内部 demo”：瓶颈从来不在技术，在上下文跨不过组织。

第三层：开始变得魔幻

如果上下文这道坎能跨过去，第三层就开始有了。

我至今觉得这一层有点不真实。技术上做出来其实没那么难，真正让我意外的是做出来之后那个画面。

我先描述一下我想看到的样子，以及我们 dev 里已经能看到一部分的雏形：

某个早上，一个客户经理在 Lark 里转发了一条客户的吐槽：“你们那个 XX 功能这周变慢了，我们后台批量跑批一直超时。”

过去这条消息会经过一长串接力：客户经理 @ 产品经理，产品经理 @ 研发主管，研发主管在群里问“谁知道这事”，有人记得上周改过相关代码，@ 那个工程师，工程师上线一看监控、翻发版记录、找 PR、找日志……一圈下来两三个小时，客户那边还在等。

第三层的样子是这样：Agent 看到这条消息（它在那个群里，而且有上下文权限），自动做了这么几件事：

它先回溯：上周这个功能有过一次发版，定位到具体的 PR #4823。

它再关联：监控里这个功能的 P99 确实从 800ms 涨到了 2.4s，涨幅时间点和发版时间吻合。

它再摘取：翻 PR #4823 的代码改动，识别出有一处批量查询的写法可能在大数据量场景下退化。

它再升级：在 oncall 频道里发了一条消息，@ 了原作者张三，@ 了 oncall 当班的李四，@ 了客户经理：“这个客户问题我已经定位，可能和 PR #4823 相关，涉及批量查询性能，建议升级为 P2。修复草案我贴在 PR 评论里了，请看一下。”

它最后兜底：在客户经理的私聊里回了一句：“问题已经定位并升级，预计 2 小时内给您回复修复方案，请稍等。”

这一切发生的时候，人还在喝早咖啡。

这一层和第二层的根本差异是什么？是 AI 从被动响应变成主动推进。 第二层的 AI 是“有问必答”型的客服；第三层的 AI 长出了职业本能，会自己识别风险、自己拉对应的人、自己找代码、自己起方案、自己向上报告进度。

注意这一步的关键：真正的跳变在于“AI 第一次表现出了职业判断”，而不是“AI 会写代码”。 它过去要培养一个工程师两三年才能形成的那种本能，什么事算紧急、什么事该先 @ 谁、什么时候该升级、什么时候该自己处理，AI 第一次有了这种东西。

我对这一层的评价就一个词：魔幻。

魔幻在哪儿？在于第二层之前所有 AI 行为都是“你按一下它动一下”。第三层之后，它开始有自发性。你早上打开 inbox 的时候，会发现里面有一半的事情是它已经替你把准备工作做完了的，你只是来按 yes 或 no、提供最终判断。

但它仍然有边界。它能起草方案，不能拍板；它能升级问题，不能决定优先级；它能 @ 人，但被 @ 的那个人，还得自己去理解上下文、做决策、改代码。

修代码这件事，在第三层依然回不到 AI 手里。AI 早就能写出能跑的代码，真正难的是它知道该修什么、从哪里取上下文、怎么验证修对了。代码本身是最简单的环节，知道“修什么、为什么修、修完了怎么知道好了”，才是工程的本体。这件事还要靠人。

第三层让 AI 长出了眼睛和嘴，但还没长出手。

第四层：Agent 全链路自治（我能想象，但还没看到）

第四层这件事我得诚实说：我们还在路上，而且很远。

第四层的样子是这样的：线上日志出现异常 → Agent 自动捕获 → 自动复现 → 自动定位代码 → 自动写修复 → 自动写测试 → 自动跑 CI → 自动提 PR → 走灰度 → 看 AB 数据 → 决定是否全量 → 全量后回归 → 关闭工单。

整条链路全可观测、可回溯、可回滚。出问题了你能立刻看到它在哪一步做了什么决策，也能把它任何一步拽回来重做。

这一层和第三层的根本差异是什么？是 AI 终于长出了“手”。 第三层的 AI 还是把球传给人，它定位、它起草、它升级，然后等人。第四层的 AI 自己接住了球，跑完整条赛道。它不只是“识别问题”，还“解决问题”。

但从 dev 跑通到敢上生产，中间有一组没解决的硬问题。

第一是回滚。 Agent 改错了怎么办？一次错误的发版可能意味着百万级的客户资损、监管层面的合规事件、舆情上的风险。这些东西在人写代码的世界里靠 SRE 经验、靠值班默契、靠“我赶紧回滚一下”这种人肉响应。在 Agent 世界里，你必须把这些经验全部写成显式的协议。什么样的指标变化触发自动回滚？多快算“快”？回滚后状态怎么对齐？对齐不了怎么办？

第二是责任归属。 Agent 上线了一个 bug 导致客户损失，谁担责？是审过 PR 的工程师？是部署 Agent 的团队？是公司？这个问题在受监管的场景下尤其要命，因为追溯会要落到具体责任人。监管不接受“AI 干的”这种回答。

我们部门内部为这件事开过一个会，讨论了三个小时，最后没结论。技术上没有任何障碍，组织上没有人愿意签那个名字。

第三是观察成本。 Agent 跑得越自动，人就越看不见它在干嘛。等你发现它在干蠢事的时候，可能已经干了一万次了。这意味着什么？意味着你可能某一天突然收到合规部的电话，告诉你 Agent 三个月前就在持续做一件违规的小事，只是直到今天才被发现。

我之前提过一个想法叫“日志驱动的自治修复闭环”，本质上就是第四层的样子，让生产环境的真实数据直接驱动 Agent 的工作流，人只在关键决策点出现。 但“关键决策点”在哪儿、怎么定义、谁来定义、出了问题谁来背，这些事我们自己也还在摸。

第五层：终极拷问

第五层其实不算一个新能力，更像是一组问题。

它问的是：你的整个企业架构，对 AI 友好吗？

这一层和前四层的根本差异是什么？前四层都是“我们怎么用 AI 干活”，第五层是“我们这家公司，有没有资格用 AI 干活”。

听起来夸张，其实非常具体。拆开来是这么几个拷问。

线上 bug 发生的时候，AI 能不能看到完整的发生过程？ 日志、链路、用户行为、上下文，这些东西是埋好的吗？还是散落在七八个系统里，连人都拼不齐？（这就是我们卡在第二、三层之间的那道坎。）

需求来的时候，AI 能不能知道它的来源和背景？ 是某个客户的具体场景，还是销售为了拿单临时承诺的，还是产品经理拍脑袋？是合规要求的、还是监管下达的、还是高层一句话？这些上下文有没有沉淀到一个 Agent 能读到的地方？还是只存在于某个总监的微信里？

该升级的问题能不能升级？ Agent 有没有跨团队、跨权限、跨工具的“通行证”，还是每到一个边界就被卡住？在金字塔型的大组织里，这一条尤其难，一个权限要走五个审批节点，Agent 走一次要等三天。

代码文档是给 AI 写的吗？ 注意这个问题问的是“给 AI 写”，不是“给后来的人写”。这两件事的标准非常不一样。给人看的文档允许模糊、允许默契、允许“懂的都懂”；给 AI 看的文档必须显式、必须自洽、必须把上下文写完整。那些祖传系统的文档，大部分对 AI 来说是天书。

说到底，第五层是组织问题，跟技术关系不大。

它意味着你公司的每一个流程、每一份文档、每一套权限、每一个工具，都要重新审视一遍：它对 AI 友好吗？如果不友好，前四层的能力都会在这里被打骨折。

我见过太多 AI 项目最后变成了“内部 demo”或者“试点试到没下文”：他们花了大力气把 Agent 的能力做起来，结果发现 Agent 跑不动。业务系统的日志结构是十年前的祖传代码、需求文档堆在三个不同的协作工具里、关键人的判断只存在于他自己脑子里、跨部门的权限要走三周流程才能开通。

Agent 站在那儿，什么都能干，但什么都干不了。

第五层之后：还需要公司这个东西吗？

第五层的拷问到这里其实还没完。如果你真的把组织改造成了“对 AI 友好”的形态，会发生一件比“提效”更深的事：这家公司的人员结构会被彻底重写。

我先抛一个判断：职能划分这件事，可能要从根上改写。

我们今天的公司架构，本质上沿用的是流水线时代的逻辑：把一件大事拆成无数小件，每个小件交给一个专门的人。装配工只负责装配，质检员只负责质检，采购员只负责采购，法务只看合同，合规只看合规，产品只画产品，研发只写代码。

为什么要这么分？因为人的带宽有限。 一个人脑子里能装的上下文是有上限的，精力也是有上限的。让一个人同时做装配、质检、采购，他三件事都做不好。所以越窄、越垂直，人的效率就越高。这是工业革命以来组织设计的第一原理。

但 AI 没有这个约束。

AI 可以并行十件你交给它的事情，不用担心精力问题。它的“带宽”几乎只取决于你给它的上下文够不够、规则定得清不清。这意味着，当一个人手里有了 AI，他能高效处理的事情，从一个窄方向变成了一片广阔区域。

过去要求“深度”，现在要求“广度”。

过去要的是一个领域里钻到底的专家。现在要的是 一专多强的复合型人才：一个对自己主战场理解透彻、同时能 hold 住相邻几个领域、能熟练用 AI 把这几个领域的活儿同时跑起来的人。

这件事对组织架构的冲击是颠覆性的。

人事、行政、采购，本质上都是处理事务流程的部门。在 AI-Native 的公司里，这三个部门可能合并成一个 5 人的“运营中台”，剩下的活儿全是 AI 在跑。

法务和风控，本质上都是在做合规判断和风险识别。这两个部门常常各有上百号人，但底层逻辑是同一套。AI-Native 之后，合并成一个团队没什么不可以。

产研团队最戏剧性。今天我们部门的产品经理、研发、测试、设计、运维，五条线五个 leader 五个汇报关系。你真的把第三、第四层的 AI 跑起来，大量“对齐成本”消失了：产品脑子里的需求可以被 AI 直接翻译成代码草稿，研发改的代码可以被 AI 自动生成测试，测试出的问题可以被 AI 自动定位回需求源头。五条线变成一个“产研一体”的小团队，完全可以做到。

最戏剧性的是：大多数公司其实不需要那么多“科学家”型的专家。深度专业能力依然有价值，但需求量会大幅缩减。一家中型业务线过去需要三十个深度专家，未来可能只需要五个真正顶尖的专家加一群有“广度+AI 杠杆”的复合型人才。

写到这里我必须诚实承认：这件事不会一夜发生。组织重力太大了，流程惯性太重了。但方向是清楚的。未来五年内，你会看到组织架构图变得越来越扁，职能边界变得越来越模糊，岗位描述里“会用 AI 杠杆放大产出”会成为隐含必备项。

这个转变到这里还没结束。再往前推一步，会出现一个更尖锐的问题。

公司本身，还是必要的吗？

经济学里有一个经典的解释，叫“科斯定理”：公司之所以存在，是为了减少一群人在社会上协作时产生的交易摩擦。

意思是，如果你想造一辆车，理论上你可以临时找市场上 100 个独立工人，每个人按合同帮你做一部分。但实际上你不会这么干，因为找 100 个人、签 100 份合同、协调 100 个人的进度、处理 100 次扯皮，这个交易成本高得离谱。所以你成立一家公司，把这 100 个人雇下来，用内部管理代替市场交易，把那些摩擦“内化”了。

公司，本质上是一个降低摩擦的容器。

但如果 AI-Native 真的把组织极度精简了，一个原本 500 人的业务线，变成 50 人的复合团队加一群 Agent，会发生什么？

500 人和社会的摩擦面是巨大的：招聘、培训、绩效、晋升、办公室政治、跨部门协调、合规审计、文化建设。这些“内部摩擦”本身就是巨大的成本，公司这个容器之所以值得存在，是因为它降低的“外部摩擦”比制造的“内部摩擦”更大。

50 人的摩擦面骤然缩小。10 人甚至 1 人的“公司”呢？

当一群人变成一小撮人，这一小撮人和社会之间的摩擦从一片火变成了星星之火。 这个时候，“公司”作为一个降低摩擦的容器，价值在快速衰减。

那 AI-Native 的极致形态，是什么？

可能是一种我们今天还没完全看清楚的形态：少数核心人才，加上一群可调度的 AI Agent，以“项目制”或“协作网络”的形式直接对接市场。 没有金字塔，没有部门，没有那些为了协调几百人而存在的中间层。

听起来像是科幻。但你回过头看每一层的演进：AI 替你写代码，AI 进流程，AI 识别风险，AI 闭环，AI-friendly 组织。每一层都在剥离一些“为了协调一群人”才存在的东西。剥到第五层之后，继续剥下去，你剥的就是公司本身。

我不知道我们这一代人会不会真的看到那一天。但我已经能感觉到方向在哪了。

在一个几千人的组织里推 AI-Native，每往前走一步，都会有一个声音在我脑子里响起来：你正在帮公司变得更高效，还是正在让公司变得更不必要？

这个问题没有答案。我也不打算给一个。但每一个走在 AI-Native 路上的人，迟早要直面它。

写在地图边上

回头看，从第一层到第五层再到那个没编号的拷问，真正在变的是问题的形状，跟技术演进关系不大。

第一层问的是“AI 能不能写代码”；第二层问的是“AI 能不能进流程”；第三层问的是“AI 能不能识别风险”；第四层问的是“AI 能不能闭环”；第五层问的是“组织能不能让 AI 闭环”；第五层之后是“等组织真的变了，公司这个东西还需要存在吗”。

前四层，是单一职能就能推动的事情。第五层不是。第五层要拉上 CEO、CTO、HR、法务、合规、财务一起改造，要重新写流程文档、重新切权限、重新定 KPI、重新定岗位。这件事大部分会被拖，因为又难又看不到短期收益，而且每一次改动都涉及到几十个人的部门利益。

第五层之后那个问题呢？它已经超出了任何单一岗位的职权，也超出了 CEO 一个人能拍板的范围。这是这家公司、这个行业、乃至这一代人要共同面对的问题。

但拖不起。AI-Native 的窗口不会一直开着。当你的对手在第三、第四层稳定运行的时候，你还在第二层加人手填会议纪要，这中间隔的是组织代差，跟技术差距没多大关系。再往前看，当你的对手已经开始重画职能、合并部门、把组织架构图变扁的时候，你还在守着传统的金字塔，这中间隔的就不只是组织代差了，是物种代差。

写到这里我自己也清楚：这张地图画完了不等于路就好走。我们团队就是个例子，第二层的甜头吃到了，被一道叫“上下文”的坎卡了两个季度，dev 里勉强跑通了第三层的雏形，第四层只敢在脑子里推演，第五层的每一个问题都在啃，第五层之后那个问题更是连边都还没摸到。

如果说这张地图能给走在同一段路上的人留下什么，大概只有一句：别等“AI 真的成熟了”再动。等的人不会赢，边走边修地图的人才会。 这句话对组织重力大、流程沉的环境尤其重要，这里的每一步都比小团队慢三倍。你越早动，越早把那些“十年前就该解决”的旧账翻出来还清，在窗口关闭前才有可能站到第三层、第四层的位置上。

每天早上的那 40 分钟批处理，看起来是新工作模式带来的，其实是新组织形态在催着我做出选择。

我每次合上电脑去开会，都会想一个问题：我在管那群机器下属上花的时间，会不会有一天超过我管人的时间？如果会，那我们这家公司的样子，就要重画了。

更深一层的问题是：那张被重画的图，可能压根就不再是“一家公司”。

有些公司不会缩小，会直接消失

AI-Native 真正在杀的，不是岗位，是公司。当协作不再昂贵，公司这件事凭什么还要这么大？

什么叫 AI-Native？

代码都是 AI 写的就够了吗？

你以为这就是 AI-Native？早着呢。

第一层：工程师不再手写代码和文档

开会、沟通、定义问题——这些事还在人手上，但写代码这件事整个交给 AI。

这是大多数团队今天讨论的"AI-Native"。但它只是 L1。

第二层：AI 进入团队协作的边缘

会议纪要、内部 Q&A、技术运营的日常支持，不再需要专人去做。

那些"中间状态"的岗位先开始消失。不是被 AI 取代——是这些岗位本身就是协作摩擦的产物，摩擦没了，岗位也就没了。

第三层：AI 进入协作的主流程

自动升级问题，自动 @对应的人，在你的上下文里识别潜在风险和需求点，帮你对齐上下文，找到相关代码，自动实现。

这一步开始有点魔幻了。AI 不再是工具，开始接管"人和人之间的协调"。

第四层：AI 像一个真正的员工

自动找需求、自动实现、自动上线、自动回收、自动 debug、自动线上回归。整条链路可观测、可回溯、可回滚。

到这一层，AI 不再被"分配任务"，而是自己有 KPI、自己会闭环。

第五层：你的基建对 AI 友好吗？

你的基建、代码文档、权限体系、人员配置，是不是真的对 AI 友好？AI 能不能看到线上 bug 的现场？能不能知道一个需求从哪里来、为什么存在？该升级到更高 level 的时候，它能不能自己处理？

最终考验来了：原来一个人管 10 个人，现在一个人管 100 个 agent。你的组织架构做好被革命的准备了吗？

但是——

但走到这里我意识到一件事。

这五层 + 最终考验，全都站在同一个假设上——公司还是那个公司，只是里面的人变成了 agent。工位换成 GPU，组织形态不变。

但凭什么？

科斯，1937

科斯 1937 年讲过，公司之所以存在，是因为市场上的协作摩擦太高——找人、对齐、信任、协调，这些事在公司内部做比在市场上做便宜。

公司是一个吸收协作成本的容器。

当 AI 把协作成本压到接近零，容器的边界就会松动。原来必须在公司内部完成的事，现在可以在市场上完成。原来需要一家百人公司承载的业务，现在 1 个人 + 一组 agent 就够。

所以 AI-Native 真正在问的不是工程链路够不够自动化。是：当协作不再昂贵，公司这件事凭什么还要这么大？

有些公司不会缩小，会直接消失

不是输给了对手。是输给了"这件事不再需要一家公司来做"。

下一波倒下的公司，可能不会有竞争对手出现。它们只是某天发现，自己解决的那个协调问题，已经不再是问题了。

你有没有发现一件奇怪的事——AI 这一轮行情里，先涨的是英伟达，然后是台积电，再后来居然是电力公司，最近又轮到了内存。中间这些公司看起来八竿子打不着，但资金每一次都精准命中下一站。这背后藏着一条市场的物理定律。

妖股的浅塘

A 股有一种东西叫"妖股"。

盘子小,业绩一般,故事讲得马马虎虎,突然有一天就涨起来了。第一天涨停,第二天涨停,第三天还在涨停。龙虎榜上挂的是几个熟悉的游资席位,散户在股吧里互相打气,分析师写不出研报,因为找不到基本面理由。

A 股有一套专门的玩法叫"龙头战法"。别管这家公司值不值这个价,先把龙头买上,大家一起推。推不动了再跑,跑得快的赚钱,跑得慢的接盘。

按教科书的说法,定价不合理的股票一定会被市场纠正。可在 A 股,这种纠正经常不会及时发生。一个明显高估的妖股可以连续涨十几个板,把所有"理性"的人都甩在后面。

美股是另一种生态。没有涨跌幅限制,没有龙虎榜,做空机制健全。一个被高估的故事今天涨 30%,明天就有 Hindenburg 或 Citron 出做空报告,后天跌回去。绝大多数撑不过一个季度,财报一出来就现原形。

但在美股,真正经得起检验的故事可以涨很多年。英伟达从 2023 年初到 2024 年底涨幅超过 8 倍,中间没有出现过 A 股那种"游资接力—散户接盘—一地鸡毛"的剧本。

同样是"共识"两个字,在两种环境里的命运完全不一样。

共识有两种

把这件事看明白之后,会发现市场上的"共识"其实分两种。

一种是真正的共识。基于基本面,被反复验证,被大量交易筛选过。

一种是短期的共识。大家一时半会都这么想,但没经过任何实质性检验。

谁会赢,取决于市场的水深。

水越深的市场——参与者越多,信息流通越快,套利成本越低——真正的共识越容易胜出。价格一旦偏离基本面,就会有人下场套利,把它拉回来。

水越浅的市场,盘子小,做空难,散户多,资金集中,短期共识可以反复战胜真正的共识。反向力量不够,纠错就发生不了。A 股妖股能炒起来,根本原因在这里。

学术上有个对应理论。Shleifer 和 Vishny 在 1997 年提出"套利的局限",说的是即使理性的套利者知道一个价格是错的,也未必下场修正。他们管的是别人的钱,前期亏损会被赎回。Abreu 和 Brunnermeier 在 2003 年把这件事推得更远:所有人都知道是泡沫,但每个人都在等别人先动手,结果泡沫可以维持很久。

更反直觉的是 Brunnermeier 和 Nagel 用对冲基金持仓数据证明的事。互联网泡沫期间,对冲基金选择骑着泡沫一起涨,而非做空它。理性的人,在浅水里,会选择和短期共识共谋。

这是第一层观察。

真共识是怎么浮出来的

把这个透镜架到美股 AI 这一轮上,能看到一些东西。

英伟达是过去三年里被全球最深的资金池、最严苛的做空机制、最活跃的卖方分析师反复检验过的一个共识。市值过 3 万亿美元的时候做空机构没有放过它,财经媒体把它的客户结构、库存周期、技术壁垒拆得一清二楚。最后这个共识没有被打掉,反而越打越实。

真正的共识就是这样长出来的。它的可信度建立在它经受住了被打掉的可能。

接下来发生的事情才是有意思的。资金没有停在英伟达身上。

第二棒是 Palantir 和模型层。PLTR 在 2024 年涨了 300%。但模型公司的故事很快遇到瓶颈,大模型本身的差异化在收窄,OpenAI、Anthropic、Meta 都能做出差不多水平的模型,资金开始往再下一棒找。

第三棒是电力。Vistra 在 2024 年涨幅超过 250%,Constellation Energy 涨了 130%。这是最戏剧性的一棒。传统上被当成"债券替代品"的公用事业股突然变成了成长股。Constellation 把 1121 兆瓦的核电站全部卖给了 Meta,Talen Energy 把 960 兆瓦的园区供电卖给了 AWS。一个二十年都在睡觉的板块,突然被 AI 的故事激活了。

第四棒是内存。SK 海力士、美光,HBM3E 在 2024 年提前一年售罄,HBM4 在 2025 年提前半年量产。到 2025 年底,普通 DRAM 的供应商库存已经从 17 周降到 2-4 周,三星 9 月以来 DRAM 报价上调了 60%。

每一棒都涨了一波,每一棒涨完之后,资金都没有停下。

资金有它自己的方向

这条接力链条背后有一个清晰的逻辑。

当前一棒的共识被充分定价之后,资金会沿供应链找下一个尚未被充分定价的瓶颈。这是市场效率本身的副产品。

英伟达的 alpha 被卖方分析师全部挖掘完之后,边际资金的最高期望收益率出现在那些"还没有被讲透"的环节。资金会自动往那里流。流过去之后,那个环节也会被讲透,alpha 也会消失,资金又往下一站去。

这个现象在金融学里叫资金扩散,或者主题内轮动。

Foucault、Pagano 和 Röell 在《Market Liquidity》里有个干净的描述:市场参与者并非时时同步在场,订单流是信息和噪声的复杂混合,共识价格只能在交易过程中逐渐浮现。每一个共识的形成都需要时间和反复交易。

更具体的实证来自 Chordia、Roll、Subrahmanyam 在 NYSE 数据上的工作。流动性越好的市场,订单失衡对未来收益的预测性越弱,价格越接近随机游走基准。流动性激发套利活动,套利活动反过来加速共识的形成。

把这两件事拼起来:在足够深的市场里,每个真实的瓶颈都会按自己的节奏被定价;定价完成之后,资金沿供应链向上游或下游扩散;扩散到下一个瓶颈,重新开始一轮定价。

台积电的 CoWoS 产能 2024 年被订满,电力公司的 PPA 长协被签满,HBM 的产能被预订到 2026 年。每一个瓶颈环节都在以"被资金提前定价"的方式完成它的产业角色。

A 股的妖股是浅水里短期共识压过真正共识。美股的 AI 接力是深水里真正共识逐站浮现。同一个金融学原理在两种环境里跑出了相反的方向。

链条的下一棒

按这个逻辑往前推,下一棒应该满足三个条件。

第一,是 AI 链条上真实的、还没消失的物理瓶颈。第二,还没有被主流叙事完全占据。第三,在一个有足够流动性的市场里。

按这个标准看,光通信和液冷已经在定价中。Lumentum、Coherent、Vertiv 这些名字已经出现在所有卖方报告里,InvestorPlace 在 2026 年 3 月明确把它们点名为"下一棒"。当主流财经媒体都开始这样写的时候,洼地阶段就过去了。ASIC 也在快速被定价,Broadcom 因为 Anthropic 的 3.5 GW TPU 订单和 Google 的合作直接重估,Marvell 拿到英伟达 20 亿美元的战略入股。

仍在洼地里的,可能有几个方向。

电网设备和变压器。GE Vernova 涨了 200%,但西门子能源、Hitachi Energy、Hubbell 这些被 GE Vernova 光环遮住的玩家,故事还没被讲透。美国变压器的交货周期已经长达 2-4 年,Eaton 的第三家变压器工厂要到 2027 年才投产,弗吉尼亚州的电网接入排队已经排到 2028 年。

燃气轮机。订单已经预订到 2028 年。市场对它的注意力集中在 GE Vernova 身上,三菱重工和西门子能源在欧洲和日本市场没有被同等估值。

中游天然气。这是最隐蔽的一棒。Energy Transfer、Williams、Enbridge 在做一件事——在数据中心现场建设 behind-the-meter 的天然气发电,让科技公司直接绕过拥堵的公共电网。这个故事完全没有被贴上 AI 的叙事,但它是 AI 时代电力供应的实质性解决方案。

以上只是个人观察,不构成投资建议,市场风险自负。

物理定律

回到开头的对比。

A 股的妖股说明一件事:浅水里价格被资金的方向推动,基本面影响有限,涨得快本身不构成持有的理由。

英伟达说明另一件事:深水里价格最终会被基本面纠正,纠正的速度取决于流动性、做空机制、信息透明度。一个真正的共识必须经历过被攻击、被审视、被打压的过程。

AI 的接力链条说明第三件事:在深水里,资金不会停在某一个共识上,它会沿着产业链扩散,逐站把所有真实的瓶颈定价完。

三件事拼起来就是市场的物理定律:资金永远往洼地流动。深水的洼地会按基本面被填平,浅水的洼地会被情绪反复填平再排空。

理解这条定律的用处,在于知道自己站在哪一种水里,然后决定要不要下场。

A 股的浅水里,你跟的是游资的脚步,赚的是接力棒的速度。美股的深水里,你跟的是产业链的方向,赚的是基本面浮现的时间差。前者比的是手快,后者比的是眼准。

弄清楚自己在哪一种水里,比押中下一棒更重要。

生产力的发展不管人的死活，但人可以管自己的死活

上个月我跟一个做外贸的朋友吃饭，他说公司刚裁掉了整个客服团队，换成了 Agent。十二个人，一夜之间变成了一笔月费。他不是冷血，他算过账：Agent 的响应速度是人的 8 倍，客户满意度反而上升了 15%。他说这话的时候表情很复杂，因为被裁的人里有一个跟了他六年的老员工。

我当时没接话。因为我自己也在经历类似的事。我做了九年工程师，过去一年眼看着身边的岗位一个接一个被 Agent 吃掉。不是未来的事，是正在发生的事。

这篇文章想讨论的问题很直接：当技术进步快到社会来不及反应，会发生什么？

效率这辆车不会停

先说一个让人不舒服的事实：讨论效率该不该推进，没有意义。

这就像两只蚂蚁讨论被车轮压的时候怎么更舒服一点。车不会因为蚂蚁的讨论而停下来。人类社会的发展一直是效率驱动的，所有试图阻挡效率的力量，最后都被碾过去了。手工织布挡不住珍妮纺纱机，马车夫挡不住汽车，实体书店挡不住电商。

但效率的推进方式是可以选择的。

英国工业革命初期，童工遍地，工人每天干 16 个小时，肺里全是煤灰。效率确实提升了，代价是一整代人的健康和尊严。后来工会运动起来了，《工厂法》通过了，劳动保障制度建立了。这些东西没有阻碍效率，它们让效率的推进不至于把社会撕碎。

所以真正的问题从来不是"要不要效率"，而是"效率碾过来的时候，谁来接住被碾的人"。个体要拼命适应，社会要拼命兜底。 这两件事不矛盾，缺一不可。

时间差在缩短

每次技术革命都有一个时间差：技术跑在前面，制度在后面追。

蒸汽机 1760 年代开始普及，英国第一部《工厂法》1833 年才通过，中间隔了将近 70 年。电气化从 1880 年代铺开，成体系的劳动保障到 1930 年代才成型，大约 50 年。互联网 1990 年代爆发，GDPR 2018 年才落地，间隔 20 多年。

规律很明显：每一轮技术革命，制度追赶的时间在缩短。但技术加速的幅度更大。

Agent 的扩散速度比以上任何一次都快。蒸汽机需要建工厂，电气化需要铺电网，互联网需要拉光纤。Agent 需要什么？一个 API key。部署成本几乎为零，扩散速度几乎没有物理限制。

这意味着这一轮的时间差可能被极度压缩。技术用两三年完成的颠覆，制度可能需要十年才能回应。中间这段真空期，就是社会震荡最剧烈的时候。

人往哪去

过去一百年，就业市场有一个隐性的"吸纳器"机制。

制造业自动化了，工人去了服务业。收银员、餐厅服务员、快递员，这些岗位吸纳了大量从工厂出来的人。服务业开始萎缩的时候，一部分人又流向了知识工作。数据标注、内容运营、初级编程，这些新岗位又接住了一波人。

每一次技术革命消灭一批岗位，同时创造另一批岗位。这个循环运转了很久，久到很多人以为它是自然规律。

Agent 正在打破这个循环。

它吃掉的不是某一层岗位，而是跨层的。客服、数据分析、初级编程、内容撰写、法律文书、财务审计，这些分属不同行业、不同层级的工作，Agent 一口气全能做。以前你从制造业出来，至少还能去服务业。现在服务业和知识工作同时被压缩，人往哪去？

我认识一个做了八年翻译的朋友，去年底失业了。她试过转行做 AI 提示词工程师，学了三个月，发现这个岗位本身也在被 Agent 替代。她现在在考虑开一家面包店。我不确定这是降级还是转型，但我知道这种"被挤出来又找不到新容器"的感觉，正在越来越多人身上发生。

一大批人失去收入来源，这件事必须被解决。不是因为善良，是因为不解决就会掀桌子。社会矛盾积累到临界点，它会以任何你想不到的方式爆发。

UBI 和那些创可贴

解决方案已经有人在想了。

Sam Altman 提了一个思路：不对劳动征税，改对 AI 公司的算力和资本征税，建立"美国公民权益基金"，让每个公民从 AI 创造的财富中分一杯羹。 英国投资部长在公开讨论 UBI（无条件基本收入）的可行性。斯坦福 HAI 发了支持 UBI 的重量级论文。2026 年美国企业研究所做了一项元分析，涵盖 122 个 UBI 试点项目，其中 30 个随机对照实验显示净就业效应为 +0.8%，也就是说拿了基本收入的人并没有躺平，反而略微更积极地参与了劳动市场。

这些数据让人稍微安心了一点。但我越想越觉得，UBI 解决的只是"钱从哪来"的问题。更大的问题依然存在。

过去两百年，整个社会运转的底层逻辑是一条链：你出卖劳动，获得收入，参与消费，推动经济循环。你的社会身份、你的人生意义、你和社会的连接方式，全部挂在"劳动"这个钩子上。你是工程师、是医生、是教师、是司机，这些标签定义了你是谁。

当劳动不再被需要，这个钩子就断了。

你每个月收到一笔 UBI，够吃够住。然后呢？你是谁？你的一天怎么过？你跟这个社会的关系是什么？这些问题听起来很哲学，但它们会以非常具体的方式爆发出来：抑郁、成瘾、社区瓦解、极端思想蔓延。不是猜测，是每一个长期高失业率地区都在发生的事。

生产关系永远在追赶

马克思说过一句被引用了无数次的话：生产力决定生产关系。翻译成大白话就是：你用什么方式生产，决定了社会怎么组织。

Agent 时代的生产力结构跟以往完全不同。以前的机器替代体力，人还有脑力。现在 Agent 替代脑力，人剩下的只有意图和判断。生产力越高，需要的人类劳动越少，但劳动是绝大多数人获取收入的唯一方式。这个矛盾不解决，社会撕裂只会加剧。

各个社会正在摸索不同的路径。美国倾向于放任市场，用低福利维持一个庞大的底层人口，不优雅但便宜。欧洲走高福利高税收的路线，已经有国家在讨论对 Agent 使用征税。东亚更习惯国家主导产业转型，效率最高但容错最低，一旦方向判断错了代价巨大。

没有哪条路被验证过。我们都在做实验。

我个人觉得最终的方向可能是某种混合体：UBI 提供基本保障，同时把 Agent 的使用权民主化，让每个人都能调用 AI 的生产力去创造价值，而不是只有大公司才玩得起。就像互联网早期只有大机构才能上网，后来变成人人都有智能手机一样。

教育是最先该动的齿轮

在所有需要重写的社会契约里，教育可能是最紧迫的一个。

现在的教育体系还在教人"掌握知识和技能"。但 Agent 最擅长的就是知识和技能。你花四年学会的东西，Agent 在训练阶段就已经掌握了，而且比你更精确、更全面、不会遗忘。

教育的重心需要从"教答案"转向"教提问"。从教你怎么解一道题，变成教你怎么发现这道题值不值得解。从教你用什么工具，变成教你怎么判断工具给出的结果对不对。

我自己带过几个实习生，最近一个让我印象很深。他的代码能力一般，但他特别擅长一件事：把一个模糊的商业需求拆解成 Agent 能执行的任务序列。这个能力在两年前根本不存在这个品类，现在它可能是最值钱的技能之一。

没有人教过他这个。他是自己在实践中摸出来的。这说明教育体系还没有跟上，但也说明人有自我适应的能力。

浪来了，搭船还是等船

写到这里我想诚实地说：我不知道社会契约最终会被重写成什么样子。UBI 会不会普及？Agent 使用权会不会民主化？教育体系会不会转型成功？这些问题我给不了答案。

但有一件事我比较确定：等着制度来救你，大概率来不及。

制度的调整需要共识，共识需要时间，时间是 Agent 时代最稀缺的东西。蒸汽机时代你有 70 年的缓冲期慢慢调整，这一轮你可能只有 5 到 10 年。

作为个体，能做的事情很具体：保持对 Agent 的手感，不断练习"定义问题"而非"解决问题"的能力，同时关注社会制度层面的变化，在有机会发声的时候发声。

作为社会，需要做的事情也很具体：加速 UBI 的试点和验证，推动 AI 使用权的普惠化，重新设计教育体系的评估标准。这些事情每晚一年，被甩在后面的人就多一批。

生产力的发展确实不管人的死活。但人可以管自己的死活。前提是你动得够快，同时推着制度也动起来。