但热闹看完之后，有些问题值得冷静想一想。

Harness 到底是什么

Harness 这个词来自马具——缰绳、马鞍、嚼子——把一匹强壮但不可预测的马引导到正确方向的全套装备。放到 AI agent 的语境里，harness 就是包裹在模型外面的约束、反馈循环、文档、工具编排和人类审批等一切基础设施。

模型是马，人是骑手，harness 是缰辔。没有 harness 的 agent 就像一匹在旷野上撒欢的纯血马——跑得快、看着帅、没有任何实际用处。

这个词翻成中文也挺麻烦。"约束工程"太窄——harness 不仅是约束，还有引导和赋能。"驾驭工程"语义接近但有个微妙错位——harness 是装备（名词），"驾驭"是动作（动词），你不会把"马具设计"叫做"骑马工程"。所以中文技术圈目前基本就直接用英文，第一次出现时加个括注解释。

Harness 和 Anthropic 的 Agent Teams 是什么关系？简单说，Agent Teams 是 Claude Code 里的一个具体功能——多个 Claude 实例协同工作，一个当 lead 协调，其他 teammates 各自独立工作并互相通信。它是 harness 的一个组件，但不是完整的 harness。完整的 harness 还需要你搞定 CLAUDE.md、测试约束、CI 集成、文件锁、冲突解决策略等一大堆东西。

谁真的落地了

把现有案例按成熟度排：

Stripe Minions 是目前最扎实的生产级落地。他们的 Minions 是完全自主的 coding agent，每周 merge 超过 1300 个 PR，零人类手写代码。它的 harness 是一个五层 pipeline，从 Slack 消息到生产级 PR。每个 Minion 跑在隔离的 devbox 里，有完整 shell 权限但不能碰生产系统。Agent harness 是 Block 开源项目 Goose 的深度 fork，针对无人值守场景做了大量改造。最关键的是，它连接了 Stripe 内部的 Toolshed（集中式 MCP server），暴露了近 500 个工具，不同 agent 按需请求工具子集。

OpenAI 内部 Codex 项目是"harness engineering"这个术语的源头。3 个工程师、5 个月、百万行代码、零手写。他们的核心发现是 AGENTS.md 不能当百科全书用——大文件会挤占 context、腐烂得很快、没法机械化验证。所以他们把 AGENTS.md 缩到约 100 行当"目录"用，真正的知识库放在结构化的 docs/ 目录里。

Anthropic 做了两件有意思的事。一是用 16 个 agent 从零写了一个能编译 Linux 内核的 C 编译器，10 万行 Rust，花了 $20,000 API 费用。二是最近发了一篇文章，把 GAN 的思路搬到 harness 里——Generator 负责写代码，Evaluator 用 Playwright 实际操作应用来打分，两者分离解决了"agent 给自己作品打高分"的问题。

LangChain DeepAgents 是开源社区里最系统化的实践。他们通过纯 harness 优化（不换模型），把 Terminal Bench 2.0 得分从 52.8% 提升到 66.5%，从 30 名开外冲到前 5。

有意思的是，尽管这几个项目的规模和风险容忍度差异很大，它们得出了非常相似的结论。

Harness 的八个组件

梳理下来，一个完整的 harness 大概需要这些东西：

Context engineering——文档和 skill 的组织。不是"写好文档"那么简单，而是 context injection 策略的设计：什么时候、以什么方式注入 context window。OpenAI 的做法是三级架构：全局 AGENTS.md（永远加载、极短、当目录用）→ 目录级 rule file（按 agent 工作位置自动加载）→ skill/docs/（按需 lazy load）。

TDD + 静态分析——让 agent 的每次修改都能被机械化验证。但这里有个关键细节：测试本身要为 agent 而非人类设计。test harness 不能打印几千行无用输出污染 context window。

可观测性——OTel 集成、日志、dashboard 访问。让 agent 能"看到"运行时信息。

架构约束——用 ArchUnit、depguard 这类工具机械化地 enforce 分层规则，而不是在 AGENTS.md 里写"不要违反分层架构"。

执行隔离——Sandbox，这是所有其他层的物理保障。没有它，上面的约束都是"君子协定"。Stripe 每个 Minion 一个一次性 devbox，跑完销毁。

工具裁剪——不是把所有 MCP tool 都暴露给 agent。Vercel 砍掉 80% 的工具后 agent 表现反而更好。工具太多 = 决策空间太大 = agent 更容易选错。

重试和升级策略——agent 卡住了怎么办？Stripe 的设计是 CI 失败最多重试两次，第三次直接 flag human。LangChain 做了 LoopDetectionMiddleware 检测 doom loop。

Entropy 治理——agent 生成的代码会以跟人不同的方式积累技术债。需要定期跑"垃圾回收"agent 来扫描文档 drift、命名漂移、死代码堆积。

关于 AGENTS.md 的一些教训

OpenAI 试过"一个大 AGENTS.md"的方案，失败了。原因很直觉：context 是稀缺资源，大文件会挤占任务和代码的空间；当所有东西都"重要"时，什么都不重要；单体文件会腐烂成过时规则的坟场。

ETH Zurich 最近的研究也发现，LLM 生成的 AGENTS.md 对任务成功率有轻微负面影响。agent 确实会遵循指令——于是跑更多测试、读更多文件、执行更多搜索——但这些行为对解决具体任务往往不必要。

Stripe 的做法更进一步——用目录级 rule file，agent 遍历文件系统时按目录自动加载对应 context。他们还兼容了 Cursor 的 rule file 格式，跨 Minions/Cursor/Claude Code 三套 agent 系统同步。

所以核心原则是：AGENTS.md 越短越好，只放 agent 不可能自己推断出的信息。

AI 写代码需要 TDD 吗

这个问题有人讨论过，但结论比较分裂。

TDD 派的核心论点是：如果让 agent 同时写代码和测试，它会写出 tautological test——测试只验证"代码做了什么"，而不是"代码该做什么"。测试先于实现，就切断了这条作弊路径。

但有一个反直觉的实验发现。TDAD 论文里，单纯给 agent TDD 指令（"先写测试再实现"），不仅没有减少回归，反而把回归率从 6.08% 提高到了 9.94%——比什么都不做还差。原因是：agent 不需要被告知"如何做 TDD"，它需要被告知"该检查哪些测试"。TDD 的流程本身对 agent 来说不是关键，关键是 dependency-aware 的测试选择。

回顾一下主流 harness 文章，几乎没有人显式提到 TDD。OpenAI 的做法是"最少的 blocking merge gate，PR 生命周期很短，test flake 用 follow-up run 解决"——跟 TDD 的"先写测试再实现"理念完全相反。Stripe 也类似——agent 写完代码后跑测试，CI 失败重试两次，第三次 flag human。

实际的做法分成三种流派：

人写测试、agent 写实现——最多人推荐，测试作为刚性合约，但本质上是把"定义什么是对的"这个最难的工作留给了人。

快速反馈循环——OpenAI/Stripe 的做法，不追求"一次对"，追求"快速收敛"。

TDD 的 context 而非 TDD 的流程——不告诉 agent "先写测试再写代码"，而是给它一张依赖图，让它知道"你改的东西会影响哪些测试"。

所以结论是：harness 不需要 enforce TDD 流程，但需要 enforce 两件事——测试由人类（或独立 agent）作为 spec 提供，以及 agent 有能力定位和运行 impact scope 内的测试。

Stripe 的 300 万测试

Stripe 的 CI 不是纯单测。他们有一个三层反馈体系：Tier 1 是 Local Linters（5 秒内跑完），Tier 2 是 Selective CI（从 300 万测试里选跟改动文件相关的跑），Tier 3 是 Pragmatic Cap（失败返回给 agent 修，最多两轮）。

300 万测试，这个量级不可能全是单测。但单测是大头——只有这种粒度的测试才能做到 selective CI 和秒级反馈。

Stripe 有没有单测？有，而且证据很实锤。2015 年他们就公开写过一篇 "Running three hours of Ruby tests in under three minutes"，当时已经有 15,000 个测试用例。他们后来做了 Sorbet（Ruby 的渐进式类型系统），诞生原因之一就是"Ruby 是动态类型，一些错误只能通过运行单元测试来验证"。

但 harness 文章为什么不讲"AI 写单测"？ 因为对 Stripe 来说，测试不是 agent 的产出，是 agent 的约束。300 万测试是十年人类工程师积累的资产，是 harness 的一部分，不是 agent 要交付的东西。让 agent 同时写代码和写测试，就回到了 tautological test 的问题。

Anthropic 的 GAN 式 Harness

Anthropic 最近（3 月 24 日）发了一篇重要的文章，核心贡献是把 GAN 的 generator-discriminator 分离思路搬到了 agent harness 里。

他们发现两个关键失败模式：一是 context 退化，Sonnet 4.5 有一种"context anxiety"会提前收尾；二是自我评价失真，agent 评价自己的作品时会自信地给高分，即使质量明显一般。

解法是三 agent 架构：Planner（把简短 prompt 扩展成完整产品 spec）、Generator（按 sprint 逐个 feature 实现）、Evaluator（用 Playwright 实际操作应用来打分）。Evaluator 和 Generator 在每个 sprint 开始前还要协商 sprint contract——"什么算做完"要在写代码之前达成一致。

效果很明显。同一个 prompt（做一个 2D 复古游戏编辑器），solo agent 20 分钟 $9 但核心功能跑不起来，full harness 6 小时 $200 但出来一个真正能玩的应用。

最有意思的部分是 harness 随模型进化而简化。Opus 4.6 发布后，sprint 分解被去掉了（模型能连续跑两个多小时不跑偏），context reset 也不需要了。但 Evaluator 在模型能力边界上仍然关键。

作者最后说了一句很精辟的话："有趣的 harness 组合空间不会随模型提升而缩小，只会移动。"

buffa：Anthropic 自己的 Harness 实践

Anthropic 还有一个不太引人注目但很有说服力的案例——buffa，一个 Rust 实现的 protobuf 库。六周内完成，Claude Opus 4.6 做了大部分工作，已经在 Anthropic 生产环境运行。

项目通过了 Google 的 protobuf conformance test suite，但作者明确说：conformance 通过是必要条件但远不充分。他举了几个 spec 盲区的例子——比如 closed enum 在 oneof 里的处理方式，spec 根本没定义，conformance 也不测。

最重要的 harness 洞察是：Claude 在发现这类 spec gap 上表现出色，但只在被明确 prompt "把 spec × tests × code 对照比较，找相对于标准实现的 gap"时才会触发。

这个项目证明了一件事——harness 不一定是复杂的多 agent 架构。有时候就是人 + 一个 agent + 好的测试套件 + 精准的 prompt。

Human in the loop，还是 out of the loop？

看完所有案例之后，一个很明显的结论是：harness engineering 的"自动化"叙事容易让人误以为是全自动，但实际上人从来没有 out of loop。

回顾一下每个案例里人在做什么：

Stripe——人写任务描述、review 每个 PR、设计 harness 基础设施。Agent 是"无人值守执行"，但人在入口和出口都在。

OpenAI——人"prioritize work, translate user feedback into acceptance criteria, and validate outcomes"。Agent 写代码，人定义做什么、验收结果。

Anthropic——人设计评估标准、校准 evaluator 的打分偏好、读 trace 找 evaluator 判断跟自己不一致的地方再调 prompt。最终产出还是人去实际点一点看效果。

所以 harness 实际做的事情是把人从"写代码"挪到了"设计约束 + 审结果"——抽象层变了，但 human 并没有 out of loop。更准确地说是 human at a higher loop：不再是每行代码的循环里，而是在任务定义、harness 调优、最终验收这个更大的循环里。

这也解释了一个很多人好奇的问题：Stripe 都 AI harness 了，为什么没有大规模裁员？

看数据：2025 年 gross revenue 约 194 亿美元，同比增长 17%，净利润率 10.6%。员工 8000-10000 人。支付总量 1.4 万亿美元。最新估值 1590 亿。

答案是：Stripe 用 AI 扩产出，不是缩编制。每周 1300 个 AI PR、人均 3.5 PR/天，对应的不是"少雇人做同样的事"，而是"同样的人做更多的事"。AI 释放出来的工程产能被增长吃掉了。

工程师的工作内容变了——从写代码到写任务描述 + review AI PR + 维护 harness——但人还是需要的。真正被省掉的是人手敲键盘写实现的那段时间，不是人本身。

Harness 最大的未解问题

所有成功案例摆在一起，一个没有被直面的问题浮出水面：它们全都站在既有测试资产的肩膀上。

Stripe 有 300 万测试，十年积累。buffa 有 Google protobuf conformance suite，现成的。C 编译器有 GCC torture test suite，现成的。OpenAI 那个 greenfield 项目让 Codex 自己写测试——Martin Fowler 直接批评"缺少对功能和行为的验证"。

真正的 greenfield + 无既有测试 + 高质量产出这个组合，目前没有人拿出过令人信服的实践。

这里面有一个结构性矛盾：

让 AI 同时写代码和测试——tautological test，测试只验证"代码做了什么"。

让人先写测试——那测试设计本身就是最耗脑力的工作，harness 省掉的只是"敲实现代码"这部分体力活。

让 AI 写测试、人 review 测试——可能是最实际的折中，但 review 测试的认知负担不比写测试低多少。

Anthropic 那篇文章里的 evaluator agent 是在尝试解决这个问题——用独立 agent 做验收。但作者自己承认，这个 evaluator 开箱即用时是个糟糕的 QA agent，它会发现问题然后说服自己"这不算大事"就放行。必须人类反复调校才能达到合理水平。

所以 greenfield 的真实成本结构是这样的：harness 叙事说的"人从写代码变成设计约束"，在 greenfield 场景下其实是"人从写代码变成设计测试 + 设计验收标准 + 校准 evaluator"。这部分工作的难度和工作量并没有被 AI 显著降低——因为它本质上是 spec 工作，是"定义什么是对的"，而不是"把对的东西实现出来"。

所以，to harness or not to harness？

Harness engineering 不是银弹。它是一套有效但有前提的方法论。

如果你的项目有高覆盖率的测试套件，有完善的 CI 基础设施，有清晰的架构约束——那 harness 能让你的团队产出翻倍甚至翻十倍。Stripe 就是最好的例子。

如果你是一个测试覆盖率 30%、没有 linter、架构约束全靠口头约定的 brownfield 项目——先把这些基础设施补上再谈 harness。harness 不会凭空产生约束，它只是让已有的约束能被 agent 消费。

如果你是一个 greenfield 项目——想清楚谁来定义"什么是对的"。这个问题 harness 不帮你回答。

harness engineering 的核心洞察是对的：模型是商品，harness 是护城河。但这个"护城河"的地基，是多年积累的工程基础设施——测试、CI、类型系统、架构约束。没有这些，harness 就是在沙滩上盖城堡。

至于 human in the loop 还是 out of the loop——别被叙事骗了。看看实际的案例：人从来没有离开过。只是换了个位置，从马背上的骑手变成了马厩里的装备设计师。马跑得更快了，但方向还是人定的。

或者用更直白的话说：AI 替你写了代码，但"写什么代码"和"这代码对不对"，还是你的活。

"工贼"这词不好听，但你仔细品品，它描述的那个角色在当下的 AI 浪潮里正在被大规模制造。

公司让你拥抱 AI，用 Copilot 写代码，用 ChatGPT 写文档，用各种 agent 搞自动化。你照做了，效率翻倍，季度汇报上你是"数字化转型标兵"。很好。但你有没有想过一个问题：你每一次漂亮的 demo，都在帮管理层完成一个论证——"看，一个人加个 AI 就能干三个人的活，我们确实不需要那么多 headcount 了。"

你不是在提升自己，你是在帮资方给整个职业的劳动力重新定价。

当然你可能觉得这话说得有点重。没关系，我们来看看博弈结构，你就知道这不是道德审判，而是数学。

三层囚徒困境，跑都跑不掉

这事儿最恶心的地方在于，它不是一个囚徒困境，而是三个套在一起的。

第一层，你和你同事之间。 你不用 AI，你同事用。他一天搞定你三天的量，下次裁员名单上是你。你的理性选择：用。

第二层，你公司和竞争对手之间。 你们公司不推 AI，对手推了。更少的人、更低的成本、更快的交付，你们被打趴下只是时间问题。公司的理性选择：全面推广，越快越好。

第三层，国家之间。 你的国家搞 AI 限制，国际对手不限制。产业效率差距拉开，经济竞争力下滑，地缘博弈中直接落入下风。国家的理性选择：不能禁，甚至还得补贴加速。

三层套娃，每一层都指向同一个 Nash 均衡：必须用。你个人扛不住，公司扛不住，国家也扛不住。任何一层的单方面克制，结果都是克制者先出局。

这就是潘多拉的魔盒。打开了就关不上。所有人都被锁死在同一条赛道上——每个参与者都在"理性"地狂奔，每一步都在加速走向那个谁都不想要的终局。你知道尽头是什么，但你不敢停，因为停下来的人死得更快。

更恶心的是，"无法协调"这件事不是天然的——它是被设计出来的。公司搞 AI 推广的时候最爱干的事就是制造个体竞争：谁用 AI 用得好谁就是高绩效，谁不用谁就是"抵触变革"。这不是在推广工具，这是在系统性地瓦解你们集体行动的可能性。

程序员的切肤之痛

程序员对这个困境感知最直接。

Cursor、Copilot、Claude Code 这些东西确实好用——我自己天天用(对，我也是共犯)。一个资深工程师加上 AI coding agent，单位时间的输出量顶过去一个小团队。但问题来了：当老板看到一个高级 + AI 就能搞定的活，他为什么还要养三个中级？

行业里已经在发生的事：初级岗位招聘断崖式下跌，code review 从技术讨论退化成 AI 输出的橡皮图章，"T 型人才"变成了"一个人 + 一堆 agent"。你越是卖力展示 AI 能替代人力，你周围的初级同事就越快被优化掉。等到中级也被证明可以由"高级 + AI"替代的时候——你猜你还安全吗？

这不是假设。2024 到 2025 年科技行业的裁员潮，相当一部分打着"AI 提效"的旗号。被裁的人里面，有多少曾经是公司内部的"AI 推广标兵"？讽刺吗？一点都不，这就是博弈论告诉你的必然结果。

泛行业：换个皮，一样的剧本

把"程序员"换成设计师、文案、翻译、客服、会计，剧本完全一样。

设计师用 Midjourney 炫技，亲手论证了"不需要那么多设计师"。翻译用 DeepL + GPT 提速十倍，亲手论证了"不需要那么多翻译"。客服接入 AI 应答，亲手论证了"不需要那么多客服"。每个行业的"创新先锋"都在用实际行动证明自己所在岗位的可替代性。

管理层当然不会跟你讲博弈结构。他们会跟你说"拥抱变化"，"提升个人竞争力"，"不要被时代淘汰"。这些话术的本质就一件事：把结构性问题个体化。让你觉得这是你个人能力的问题，而不是劳资利益分配的问题。

那 UBI 能救吗？

有人说，搞个 UBI(Universal Basic Income，全民基本收入)不就行了？大家都有饭吃，囚徒困境的恐惧感不就消除了？

想多了。

UBI 能兜底，让"右下角"的结果不至于是赤裸裸地饿死。这算是个安全网，聊胜于无。但三层囚徒困境的驱动力根本不是"怕饿死"——而是竞争优势。你觉得程序员会因为每个月能领个基本收入就不卷了？不会的。UBI 给的是底线，不是你现在的薪资水平。你怕的不是没饭吃，你怕的是从年薪百万滑落到社会最低保障线上，眼睁睁看着你的房贷、你孩子的学费、你十几年攒下来的生活水准全部崩塌。

更关键的是，UBI 完全不触动公司层和国家层的博弈。企业之间的效率竞赛不会因为员工有 UBI 就停下来，国家之间的产业竞争更不会。UBI 是个分配方案，但它不改变博弈结构本身。囚徒还是囚徒，只是牢房里多了张床垫。

所以 UBI 不是解药，充其量是止痛片。而且这个止痛片还不一定开得出来——钱从哪儿来？对 AI 收益征税？好，那你就进入了另一个囚徒困境：哪个国家先征 AI 税，哪个国家的 AI 企业就先跑路。又绕回来了。

那到底怎么办？

说实话我也没有什么好答案。但有几句话可能不太中听：

拒绝 AI 不是出路。 前面三层博弈已经说清楚了，单方面不合作的人死得最快。勒德主义从来不管用，织布工砸毁机器没有阻止工业革命，只是把自己从工人变成了失业者。

政策管制几乎不可能。 在国家竞争这一层，任何单方面限制 AI 的经济体都是自废武功。大家在"AI 安全"的名义下做做样子，底层的军备竞赛从来没停过。

UBI 也不是答案。 前面说了，它治标不治本，而且征税逻辑本身又是一个新的囚徒困境。

真正的问题是分配。 AI 带来的效率增量，应该流向谁的口袋？这个问题需要集体行动才能回答。但现状是大多数行业的劳动者根本没有有效的集体谈判机制。程序员尤其如此——高薪制造的幻觉让这个群体长期以为自己跟资方是"合作伙伴关系"而不是雇佣关系。等 AI 开始戳破这层窗户纸的时候，才发现自己既没有工会，也没有任何制度化的议价工具。

打破囚徒困境在博弈论里有个经典解法：重复博弈中的惩罚策略。翻译成人话就是，劳动者需要某种形式的组织和团结，而不是在"谁更会用 AI"的内卷赛道上互相踩踏。但说起来容易，做起来嘛……你懂的。

最后

AI 是好工具，这句话没问题。但"工具中性论"是最大的骗局——当工具的推广方式被刻意设计成瓦解集体协调的手段时，工具就不再中性了。

每一个在公司内推中积极表演"AI 提效"的人，都可以想想：你提的效，最终进了谁的口袋？

你在做 AI 时代的"先进个人"，还是在做囚徒困境里的最优背叛者？

这两件事，很可能是同一件事。魔盒已经打开了，问题是你在狂奔的路上，有没有抬头看一眼尽头是什么。

从用户视角看，这类工具最直接的价值是打通 C 端孤岛。各个平台的数据和操作，不再被 GUI 困在浏览器里，而是能被脚本编排、被 AI 驱动、被流水线串联。对于做互联网运营的人来说，这类工具确实是如虎添翼。

反制与猫鼠游戏

对于主动建数据孤岛的互联网公司来说，这当然不是什么好消息。最近国内的平台已经在认真研究怎么识别 CDP 指纹、怎么检测自动化行为、怎么封号了。我猜用不了多久，C 端系统的普遍行为范式会变成：检测到你的浏览器挂着 bridge 插件、开着 remote debug 端口、或者 headless 特征过于明显，就先弹个确认框，要求你关掉才能继续访问——就像现在一些平台检测到 VPN 就拒绝服务一样。这场猫鼠游戏会越打越复杂，反制手段也会越来越精细。

到时候如果应验了，记得回来 at 我。

但这篇文章真正想聊的，不是 C 端的攻防，而是另一个更值得关注的方向——把 CLI Everything 的理念用在内部系统上。

散装基础架构：大多数公司的真实处境

除了头部的大厂，大多数中小公司的内部基建说实话都挺惨。监控系统、日志平台、代码仓库、CI/CD、工单系统、配置中心……每个系统都是独立部署、独立 GUI、独立登录，彼此之间几乎没有任何自动化互联。干活的人每天像在拼乐高，把这些散装积木用复制粘贴和肌肉记忆强行黏合在一起。

一个典型的排障流程是这样的：

1. 监控告警触发，打开 Grafana，找到异常时间段
2. 复制时间戳，切到日志系统，手动输入 traceId 搜索
3. 找到关联请求，复制服务名，切到代码仓库，翻对应版本
4. 发现疑似问题，想看最近的发布记录，切到 CI/CD 系统
5. 中途来了条消息，复制 traceId 的剪贴板被 2FA 验证码覆盖，从头再来

这不是极端案例，这是绝大多数公司工程师每周都在经历的日常。

CLI 化之后，世界会不一样

如果我们把这些内部系统都 CLI 化——每个系统暴露出稳定的命令行接口——再加上 AI 作为中间层，整个协作方式会发生质变。

# 把刚刚这个分支部署到测试环境
cli deploy feat/add-feature-for-user-avatar --env staging

# 查看这次部署的构建日志
cli ci logs --branch feat/add-feature-for-user-avatar --last

# 生产环境出了告警，让 AI 自动采集现场
cli diagnose --alert-id ALT-20240312-0042 --attach-code

AI 排障的场景尤其典型：AI 拿到告警信息之后，自动通过 CLI 从监控系统拉指标、从日志平台捞 trace、从代码仓库关联最近的变更记录、从 CI/CD 系统查对应的发布历史，最后结合代码上下文给出分析结论。整个过程不需要工程师在五个系统里反复横跳，也不需要手动对齐时间窗口。

下面再展开几个更具体的场景：

场景一：跨系统的权限变更审计

安全团队想知道过去一周有哪些账号做了生产环境的权限变更，并且关联了哪些工单。传统方式要分别去权限系统、堡垒机日志、工单系统三个地方查，然后手动 Excel 对表。CLI 化之后，一个命令加 AI 分析，三分钟出报告。

场景二：发布前的影响面评估

开发提了一个 PR，想知道这次改动会影响哪些下游服务、哪些接口的调用量较高、历史上类似改动有没有引发过告警。以前这种评估要么凭经验靠感觉，要么拉一堆人开会对齐。CLI 化之后，AI 可以自动查代码依赖图、调用链路、监控历史，给出一份结构化的影响面分析。

场景三：成本异常溯源

云账单突然涨了 30%，但没有人知道是哪个业务、哪次变更导致的。把云厂商账单系统、Kubernetes 资源用量、CI/CD 发布记录都 CLI 化之后，AI 可以自动做时序关联，把成本突增和具体的发布事件对应起来，而不是让财务和技术来回甩锅两周。

场景四：新人 onboarding

新同学入职，想了解某个核心链路是怎么工作的。以前要靠老人口耳相传、翻过时的 Wiki、或者自己一个一个系统去摸。CLI 化之后，AI 可以主动从代码仓库、调用链路、历史告警、变更记录里拼出一份"活的文档"，而且永远是最新的。

对基础架构团队的影响

在 CLI Everything 到来之前，跨系统的需求往往是这样被处理的：需求方提工单，基础架构团队以"排期满""优先级低""技术方案不成熟"为由拒绝或无限期推迟。双方都在这套低效的博弈里内耗，真正的需求被淹没在协作成本里。

但 CLI 化一个内部系统的 API，调试到稳定可用，现实的时间成本大概是半天到一天。这个事实，让"我们没有资源支持"这类回答在技术上变得站不住脚。

这并不是说基础架构团队要消失——相反，真正有能力把系统设计得"可 CLI 化"、接口语义清晰、权限模型合理的人，会变得更有价值。但那些靠着信息壁垒和 GUI 垄断来维持话语权的角色，确实会越来越难立足。

主动拥抱这个趋势，把自己负责的系统做成其他团队真正能用的工具，才是在这个时代里继续有意义的方式。

CLI 的归宿：统一框架 CLI

当公司内部的系统一个一个被 CLI 化之后，新的问题随之而来：这些 CLI 散落在哪里？谁来维护？怎么发现？怎么升级？

如果没有统一管理，最终的结果可以预见——每个团队各自维护一套命令行工具，命名风格不一致，认证方式各不相同，有的用 pip 装，有的要去内网 Wiki 找个二进制手动下载，有的文档已经半年没更新了。这和 CLI 化之前的 GUI 散装状态，本质上没有任何区别，只是从散装 GUI 换成了散装 CLI。

解决方案是：公司内统一的框架 CLI。

类比已经有了，而且就在我们身边——AWS 有 aws，GCP 有 gcloud，Azure 有 az，Kubernetes 有 kubectl，Heroku 有 heroku。这些工具的共同点是：一个统一入口，子命令按系统/资源维度组织，认证统一管理，版本统一升级，文档统一查询。

公司内部的统一框架 CLI 也应该遵循同样的逻辑：

# 统一入口，子命令按系统组织
corp deploy feat/add-avatar --env staging           # CI/CD
corp logs --service user-api --trace abc123         # 日志系统
corp alert list --severity critical --last 1h       # 监控
corp repo diff HEAD~1 --impact                      # 代码仓库
corp iam grant user@company.com --role staging-read # 权限系统

所有命令都在同一个二进制下，认证只需要做一次（SSO/LDAP 打通），权限模型统一收口，升级也只需要一条命令。

统一框架 CLI 带来的真正价值

可发现性。 工程师不需要去问"这个系统有没有 CLI"、"CLI 装在哪里"。corp --help 或者 corp <tab><tab> 就能看到公司内所有已接入系统的能力，自动补全即是文档。

统一的认证与鉴权。 散装 CLI 最头疼的问题之一是每个工具都有自己的 token 管理，有的 token 三个月过期，有的永不过期，有的存在 ~/.config 里，有的要设环境变量。统一框架 CLI 只需要维护一套身份上下文，权限变更在 IAM 侧收口，CLI 本身不持有任何长期凭证。

AI 的统一调用层。 这才是真正关键的一点。当所有内部系统都通过同一个框架 CLI 暴露能力时，AI Agent 只需要学会一套工具调用规范，就能操作公司内所有系统。不需要为每个系统写单独的 tool definition，不需要担心不同 CLI 的输出格式差异导致解析失败。框架 CLI 可以在设计层面保证：所有命令支持 --output json，所有错误码语义一致，所有操作有统一的 dry-run 机制。这让 AI 驱动的自动化从"能用"变成"可靠"。

审计与合规。 所有通过框架 CLI 执行的操作，天然有统一的审计日志入口。谁在什么时间对哪个系统做了什么操作，一条链路全部可查。这对于金融、医疗、或者任何有合规要求的公司来说，价值不言而喻。

框架 CLI 的演进路径

不需要一开始就做成大而全的平台。实际上合理的演进路径是：

第一步：先做规范，后做框架。 定义好子命令命名规范、输出格式约定、错误码语义、认证接入方式，让各团队按规范独立开发自己系统的 CLI 插件。

第二步：框架提供脚手架和公共能力。 认证、日志、配置管理、输出格式化这些横切能力由框架统一提供，各团队只需要实现业务逻辑。

第三步：插件注册与发现。 类似 kubectl 的 plugin 机制，各团队发布的 CLI 插件注册到内部的插件仓库，corp plugin install monitoring 即可安装，升级也统一管理。

第四步：AI 集成层。 当所有系统都有了稳定的 CLI 接口之后，在框架层统一生成 tool schema，暴露给内部 AI Agent 调用。

这个路径的好处是：每一步都有独立价值，不需要等整体完成才能产生收益，也不会因为某个系统迟迟没有接入而阻塞整体推进。

CLI 孤岛，还是 CLI 联邦

最终，散装 CLI 和统一框架 CLI 的区别，类似于微服务时代"散装服务"和"服务网格"的区别：单个服务可以独立工作，但只有统一的治理层出现之后，整体才能作为一个可靠的系统来运转。

统一框架 CLI，就是内部基础设施的服务网格——它本身不提供任何业务能力，但它让所有业务能力能够被可靠地发现、调用、审计和组合。

这也是 CLI Everything 这个趋势最终要落地的地方。单个系统的 CLI 化是战术动作，统一框架 CLI 才是战略基础设施。

CLI Everything 不是技术炫技，是一种基础设施的哲学：系统的价值不在于它有多好看的界面，而在于它能不能被其他系统、其他工具、其他智能体低成本地组合和调用。

这个标准，正在重新定义什么叫做"做好了一个系统"。

Mar 24, 2026 · 4 min read

前 AI 时代，巡检和排障都是又辛苦又烦人的体力活。

巡检需要你盯着告警和大量的监控面板，时刻思考系统是不是出什么问题了，有问题还得及时介入。之前和朋友聊天，听说国内某头部量化公司，最近一两年居然还要求 SRE 在开盘时间全程盯着监控面板，也是非常神奇。

排障则需要你对自己干活的语言做到基本精通，比如几年前在给人做培训的时候，单是性能优化这一节就做了大概 120 页 PPT，也只是简单介绍了程序员日常排查问题和做性能优化要了解的知识和工具。Systems Performance 的大部头更是让人又爱又恨，读到力竭才勉强消化。

从去年底开始，模型能力的大进化让这两件事变得不太需要人去做了。

AI 巡检

如果公司内的基建比较完善，做到了 AI native 的全面 MCP/Skill 化，那巡检就是一两句话的事，直接指挥 AI 去关注 OTel 的三大类数据就行。

AI 可以很好地给出一份同事看了都满意的报告。示例：

如果公司的基建比较差，那又得靠 agent browser 了。和之前写的让 AI 去生成 E2E 测试流程一样，只要告诉 AI 监控面板在什么位置，巡检主要关注哪些面板，哪些时间维度，哪些服务，剩下的让 AI 自己探索，直到出现 AI 解决不了的问题，再人工介入。

agent browser 探索你的监控/trace 页也差不多，它出问题了，你帮它修就好：

多执行几次没有问题之后，再让 AI 总结成 skill，下次就是一句话的事：

一句话，帮爷干活吧 AI：

AI 排障

在公司里有时候不得不维护一些让人无语的代码，比如没太多并发开发经验的老同事写的并发+回调来回嵌套的天坑代码，规模一上去，正常人根本理解不了。有了 AI 以后，这种代码可太好对付了。

我们已经拿 AI 定位了不少并发 bug，因为代码难读，人去分析会被恶心很久，AI 则很快：

当然，快是有前提的。除了上面说的 OTel 三件套，你还需要把程序的 stack 也给它，如果是性能衰退，那公司里还需要有一个 continuous profiling 系统，比如已经被 Grafana 收购的 Pyroscope：

如果现场不全，比如你只有日志和监控，没有 stack，那 AI 给出的结论就不一定靠谱了。

总结

相信读者也看出来了，本文中的两种场景目前还都是人在本机完成的，即使在没有 AI 的时代，如果一家公司愿意在 infra 投入，做出自动巡检和自动排障的机器人，其实也并没有那么困难。

而到了 AI 时代，由大模型填平了中型公司和大公司的基建差距，正是所谓的基建不够，智能来凑。

只要技术人员的想象力足够天马行空，几乎没有太多克服不了的工程困难了。

Mar 23, 2026 · 5 min read

嗯，最近一直在测试 opus 和 gpt5.4 的能力差别，目前结论是各有千秋。

今天我们从 opus 的一个最大优势讲起。先来看两张图。

第一张是用 kafka definitive guide 第二版去问 opus：

注意看 opus 的思考过程

第二张是用同样的问题去问 chatgpt：

同样注意看 gpt 的思考过程

可能有些读者还一头雾水，这能说明啥？嗯，先卖个关子，我们来看看之前关于 anthropic 的一篇报道：

当地时间9月5日，人工智能初创公司Anthropic提交的法庭文件显示，该公司将支付至少15亿美元来解决一起在美国的集体诉讼，该诉讼指控Anthropic涉嫌使用盗版书籍来训练聊天机器人Claude。

这一和解若获得法官批准，将成为AI公司与创作者之间版权争议的里程碑，也可能对整个出版业、创作者群体及AI行业的商业策略产生深远影响。根据和解协议，Anthropic将向约50万部纳入和解范围的书籍的作者或出版商支付每部约3000美元的赔偿。原告方律师贾斯汀·尼尔森（Justin Nelson）表示："据我们所知，这是有史以来金额最高的版权赔偿，也是人工智能时代的首例此类案例。"

说结论，anthropic 用大量的书籍去训练了自己的模型，并且在模型的思考过程中大方地告诉你了，这本书我知道，它就在我的训练数据里。

个人认为，这些书的内容，目前是 opus 相比 gpt5.4 的最大的优势之一，这意味着什么呢？

最简单的，通过与 opus 互动，了解书的主要内容，加速书籍内容的理解和消化：

比如我可以通过互动了解到 TLPI 这本经典大部头里的内容

在 AI 时代，只是让 AI 做学习助手就有点 low 了。我们可以合理利用对我们自己脑中书籍的了解，让 AI 借助某本书的方法论来辅助我们进行开发。

比如我之前读过 righting software，觉得这本书里有个观点有点意思，按照代码的易变性来对代码进行分层：

让 AI 快速帮我出了一个版本，并且说明分层原因之后，对当年这本书的观点又加深了一层。这本书我当时读完只对 workflow 和 rule 的组合印象深刻，对易变性的理解其实没那么深。基于易变性来分层，当时更是没怎么多想，有了 AI 去做实验就方便多了，极大缩短了方法论的落地路径。

上面都是前互联网时代的东西，有没有更 AI native 一点的东西呢？有的，兄弟，有的。

我们可以直接让 AI 把我们认为不错的书转成 skill：

要求 opus 把 ddia 转成一个 senior architect 视角的 review skill

当然，这只是 review，整个软件开发生命周期的每一个环节都有优秀的书籍介绍，所以如果你喜欢哪本著作，并且高度认同书中的观点，你就可以把这本书转成软件生产某个环节的 skill。

转换完之后，还需要再 review 一遍，因为方法论都是有时效性的，读书的时候要有批判性地读，自动转换出来的结果自然也不应该全盘接受。

我在某个群里和朋友分享观点之后，另外一个朋友也提出了同样的看法，并且给了我一个清单，是他的偏好（注意，不是我的）：

需求分析：
- Are Your Lights On? — Gerald Weinberg
- Specification by Example — Gojko Adzic
- Exploring Requirements — Gerald Weinberg & Donald Gause
- User Stories Applied — Mike Cohn
- User Story Mapping — Jeff Patton

OO 建模：
- Object Design: Roles, Responsibilities, and Collaborations
- Object-Oriented Methods: A Foundation, UML Edition — James Martin

设计：
- Software Architecture in Practice — Bass, Clements, Kazman
- Patterns of Enterprise Application Architecture — Fowler
- Domain-Driven Design — Eric Evans
- Designing Data-Intensive Applications — Martin Kleppmann
- Fundamentals of Software Architecture: An Engineering Approach

编码：
- Refactoring — Martin Fowler（1999，第二版2018）
- Test Driven Development: By Example — Kent Beck（2003）
- Working Effectively with Legacy Code — Michael Feathers（2004）

测试：
- Agile Testing: A Practical Guide for Testers and Agile Teams — Lisa Crispin
- More Agile Testing: Learning Journeys for the Whole Team — Lisa Crispin
- XUnit Test Patterns: Refactoring Test Code
- Lessons Learned in Software Testing — Kaner/Bach/Pettichord

这篇文章是讲 book driven，你自然也发散成 doc driven，paper driven。

读者应该要有自己的想法。

下一次工业革命近在眼前了

去年的这个时候，IT 圈哀鸿遍野，吐槽技术红利消耗殆尽，所有公司都失去了新的增长点，程序员红利到头了。 今年的这个时候，程序员的好日子确实进入倒计时了，只不过不像当初做预言的人想的那样，连他们自己的末日也在倒计时了。 中国的互联网从业者并没有把 AI 当回事，这几年来对 AI 的看法是这种基于统计和传统神经网络的技术不足为惧，因为硬件的发展让老树发了一点新芽，套上强大的核弹厂芯片加一些修修补补的算法，能帮这些批着科技外皮的牛皮癣广告公司卖出更多的广告，能让信息茧房里的人看到更多他们喜欢的信息，奶头乐吸得不亦乐乎，让整个网民群体娱乐到死，普通人失去了研究的耐心和学习发展的能力，商业公司赚到了…

No HeadbackXargin

两年前写的：

无论你是一个艺术家，作曲家，诗人，外卖员，流水线作业者，程序员，产品经理，法律文书起草人，客服人员，还有那些不包括在这些分类里的模式化职业，在未来的很短的时间内，你所引以为豪的，都会在 AI 发展的摧枯拉朽之下轰然倒塌。

实际的进度比我想的进度还是比我慢一点，2026 年行业内的程序员们才开始普遍焦虑和恐慌。原因也不复杂，主要是大模型的能力上来了。

2025 年的时候 opus 4.5 太贵，问几个问题额度就满了，彼时编程最好的模型是 sonnet，我尝试用 sonnet 把一个 java 项目 transpiler 到 rust，项目规模大概 15w 行左右，然而 sonnet 在项目目录下建一大堆 markdown，帮助自己记住任务的上下文的前提下，大部分问题还是收敛不了。

和 sonnet 对话也十分恼火，一旦 compaction，就发现 sonnet 忘记了一些进行中的项目细节。高强度 vibe coding 两周后，这个项目就暂时搁置了。

opus 4.5 发布之后，opus 从几乎不可用变为可用，马上重新 vibe 了整个项目，发现之前大量的 markdown 不会生成了，而且很多问题可以收敛了，不会再像 sonnet 一样解决问题无限循环。这时候 twitter 上也不少人发现 opus 很牛，可以直接解决大项目问题了。

到了 2026 年，这种情绪也漫延到了中文圈，程序员们终于发现 AI 好像比自己写代码要写得好了，进入 panic mode。

要我说啊，程序员工作消失也就是个迟早的事情，别慌，大裁员也一定会来，无非早晚，对大多数人来说，别上太高的杠杆，现金流能让你活到下一轮变革就还有救。

人类也迟早会进入资源无限，能源无限的时代，就看生产关系能不能真正和生产力适配，那就是真正的乌托邦。

但短时间内，我是悲观的，从历史上看生产力极度过剩的时代基本都是战争的开端。

开源软件供应链安全的五十年

Russ Cox

1972年3月，美国空军开始评估霍尼韦尔公司的 Multics 系统，以判断它是否适用于安全环境。

该报告于1974年中期发布，得出的结论是，尽管 Multics 不够安全，但优于同类系统，可能是构建安全系统的合理起点。

报告中提到了在一个看似无害的系统调用中加入后门（当时称为“陷阱门”）的可能性。

当系统调用接收到特定且极不可能的输入时，允许读取或写入任意内核内存字。

这个微小的修改足以彻底破坏系统安全性，报告还探讨了这种修改可能如何实现和隐藏。

2024年3月，微软的 Postgres 开发者 Andres Freund 注意到，他的 Debian Linux 系统上的 ssh 守护进程在处理网络背景攻击流量（试图暴力破解登录）时使用了异常多的 CPU。

经过深入调查，Freund 发现 Debian 系统中链接到 ssh 的压缩库 liblzma 的最新版本中含有一个专门针对 ssh 的后门。

只要传入一个特定且极不可能的输入，该 ssh 守护进程就会允许攻击者在互联网上执行任意 shell 命令。

这一微小的改动彻底破坏了最新 Debian 系统的安全性，接下来的几周里，全球的安全研究人员都在研究这种变更是如何被实施和隐藏的。

由于 liblzma 是 xz 项目的一部分，该攻击如今被广泛称为“xz 攻击”。

Understand the Software Supply Chain

理解软件供应链

要保护你的软件供应链，首先必须理解它到底是什么。

我们从定义开始：软件供应链是指所有可能发生供应链攻击或引入漏洞的环节。

而“理解”的更重要含义是：清楚地知道你自己的软件供应链到底是什么样的——这其实非常困难。

“链”这个词听起来很简单，但供应链更像是分形结构：无论你多么细致地观察，它都复杂无比。

从最低层来看，你可以观察构建一个程序所执行的命令以及命令之间的依赖关系。

这些构建图与程序本身的包依赖结构是对应的。

即使是简单程序，其构建图也可能复杂得无法打印出来。

Go 项目一直优先避免不必要的依赖，力求保持软件简洁。然而，就在我写这篇文章时，构建 go 命令仍需执行 714 个命令，构建 297 个包，生成 3,132 条依赖边。

go 命令的一个特殊之处在于它没有外部依赖：它使用的所有包都属于 Go 项目自身。

而在稍微复杂些的命令中，Kubernetes 的 kubelet 构建过程要执行 3,289 个命令，依赖 137 个 Go 模块中的 1,581 个包，许多还来自 Kubernetes 项目以外。

这些例子都是相对较小的底层工具。更高层级的程序构建复杂度更高。

在本期 acmqueue 的另一篇文章中，Josie Anugerah 和 Eve Martin-Jones 更详细地探讨了开源构建图的复杂性，并指出大多数程序都有多个可能的构建图，具体取决于其构建环境。

人们很容易以为这类依赖图就是整个软件供应链，但其实它们只是最显眼的一部分。

依赖图中的每个包或模块都可能由不同的个人或组织编写，其安全实践、代码审查标准等也各不相同。

如果能对每一个依赖的细节有更多了解自然是好事，但现实中这些信息通常不可获取，而且会随着时间变化。

另一种“图”表示的是软件在构建和分发给用户过程中所经过的各类计算机和服务。

在这些系统中任意一处进行恶意篡改都是可能的，每一处都可能成为攻击点或漏洞源。

你应该关心谁有权限访问某个依赖项目、将来可能是谁、他们使用的基础设施是什么，等等。

但大多数时候，由于缺乏可见性，这些问题被忽视了。然而它们仍然存在。

理解软件供应链对于识别哪些环节需要加固至关重要。

整个行业在这方面仍有大量工作要做，而本文接下来将转向那些已知有效的具体加固手段。

Authenticate Software

验证软件身份

Multics 评估报告考虑了在“分发阶段”插入后门的可能性，比如利用“不安全的通信方式”或通过“伪造信笺”发送恶意更新。

这些说法可能已经过时，但背后的思想依然适用。

XcodeGhost 就是这种攻击方式的现代例证。

解决这一问题可以说是现代软件供应链安全领域最接近成功的案例。

加密签名可以防止代码在签名与验证之间被恶意篡改。

唯一剩下的问题是密钥分发：验证者必须知道代码应由谁签名。

关于密钥分发问题，有很多可行的解决方案。

最简单的做法是忽略身份验证，仅记录并分发构建中使用的特定依赖版本的加密哈希值。

预先分发这些哈希值的验证方式可彻底消除下载服务器、代理和其他网络中间件作为攻击点的可能性。

Debian 的依赖打包系统包含这种检查机制，这使得 xz 攻击者无法仅仅修改已有的 xz 副本，而必须发布新版本。

这并未阻止攻击，但显著提高了攻击难度。

从更大范围看，这些哈希值不必全部预分发，而是可由一个可信数据库集中管理。

Go 校验和数据库就是该方法的真实应用示例，它保护着数百万 Go 开发者。

该数据库保存每个公共 Go 模块每个版本的 SHA256 校验和。

数据库的每条记录都由数据库服务器的私钥签名。

相应的公钥硬编码在 Go 命令源码中，因此密钥分发与 Go 工具链分发绑定。

每次 go 命令下载一个新的开源 Go 包时，都会查询预期的校验和。

每个项目本地都有一个依赖项校验和缓存，因此只有在升级或添加新依赖时才会访问校验和服务器。但无论如何，每次下载都会进行校验。

这意味着代码托管站点与用户计算机之间的代理或中间组件都无法成为攻击点。

即使攻击代码托管站点，也无法篡改旧版本包。

当然，问题在于向数据库中写入哪个版本的校验和。

在 Go 项目中，如果数据库尚未记录某个特定包版本，它将直接获取代码并记录获取到代码的校验和。

这种“首次使用即信任”的做法并不意味着代码值得信任，但它至少确保如果明天有人在另一台电脑下载相同版本，代码是一样的。

这种不可变性确保了整个 Go 生态对 Kubernetes 1.28.4 版本的理解保持一致，为各种分析工作打下基础。

在能解决身份验证问题的前提下，让开发者签署其软件可以提供更强的保障。

以 xz 为例，其发布包是用个人作者的 GPG 密钥签名的，这使得我们可以分辨哪些包是由可信的原始维护者签署的，哪些则是由控制项目的攻击者签署的。

Make Builds Reproducible

让构建可重现

Multics 评估报告指出，恶意更改“最好隐藏在已编译例程的二进制代码中”，而不更改对应的源代码。

这种更改只会在源码重新构建后失效，但大多数系统不会无故重建源码。

这一问题在今天依然值得关注。

例如，xz 攻击中触发恶意行为的关键代码行仅存在于打包分发版本中，而不在源码控制仓库中。

验证二进制文件未被修改的最好也是最直观的方式是重建它们，并将结果与已发布版本比对。但这需要构建是可重现的。

由于计算机是确定性的，这本应是一件很简单的事。但实际上，像构建机架构、机器名、临时目录名或当前时间等上下文信息极易进入构建结果，从而导致构建不可重现。

Reproducible Builds 项目旨在提升对可重现构建的认知，并开发工具，推动所有 Linux 软件实现完全可重现的构建。

Go 项目近期已实现：只要有源代码，即可完全重现构建结果。这意味着，尽管构建过程需要某种操作系统、某个版本的 Go 工具链，但这些选择都不影响最终结果。

无论你在 Linux、Windows 还是 Mac 上构建，无论主机是 X86 还是 ARM，面向同一目标的构建会产生完全相同的发布文件。

强可重现性使他人能够轻松验证下载的二进制文件是否与源代码一致。

这些二进制文件也记录在 Go 校验和数据库中，并在 go 命令下载新工具链时进行验证，确保传输过程中无法被篡改。

验证软件身份并实现可重现构建可以消除一些潜在攻击途径，尽管并非全部。

我们接下来关注漏洞问题。

Find and Fix Vulnerabilities Quickly

快速发现并修复漏洞

五十年前，人们还曾寄希望于通过正确的设计与谨慎的实现使软件变得完全安全。

但我们如今明白这只是理想。

既然软件始终会有漏洞，我们就必须做好准备，一旦发现问题，立刻查找并修复。

既然攻击者也在寻找这些漏洞，最好的防御方式就是我们先他们一步发现并修复。

最简单的例子是使用了存在已知漏洞的过期依赖项。

现在有许多工具可以识别这种情况，包括 govulncheck、npm audit 等语言专用工具，osv-scanner 这类通用开源工具，或一些商业工具。

它们的原理是将构建所用的软件清单（SBOM）与已知漏洞数据库进行交叉比对。

现在，工具或数据库的具体选择已不再那么关键。

开源社区已统一使用 OSV（开源漏洞）格式描述漏洞，其中包括对受影响包及版本的精确算法定义。

OSV 数据库聚合了所有语言的漏洞数据库。

CVE（通用漏洞披露）数据库的 JSON 5.0 格式也采用了 OSV 对受影响包和版本的精确定义，使 OSV 与 CVE 实现互通。

所有工具访问相同、完整的漏洞信息将惠及整个生态系统。

建议定期（最好每日）扫描软件，即使你的代码没有变化，数据库中也可能新增漏洞记录。

你还需准备好将漏洞依赖升级为修复版本。

这要求你拥有全面的测试能力，以确保修复版本没有引入新 bug；还需具备自动部署能力，使补丁版本能在几小时或几天内发布，而非几周或几月。

测试与部署是常规软件工程问题，虽不专属于供应链安全，但缺失它们会严重影响你的安全态势，甚至产生法律风险。

当 2021 年 Log4j 漏洞被披露时，大多数公司花了数周乃至数月来梳理全部软件，找出受影响部分，再完成更新与部署。

美国联邦贸易委员会（FTC）甚至发布通告，敦促企业尽快修复 Log4j，以“减少对消费者的潜在危害，避免 FTC 法律诉讼”，并指出 Equifax 就曾因未修复软件漏洞遭黑客入侵而承担责任。

扫描已知漏洞只是最低标准。

理想情况下，还应投入精力发现开源依赖中尚未被公开的漏洞。

在审计自己代码时，也应识别出关键的开源依赖项并对其进行审计。

对你的代码及依赖运行静态分析或模糊测试（fuzzing）也非常有效。

攻击者也会使用这些手段，你不如先下手为强。

Prevent Vulnerabilities

预防漏洞

即便软件总会存在漏洞，我们仍可采取措施，预防某些特定类型，或减少其发生概率。

首先，应省去不必要的依赖项。

Gordon Bell 曾指出：“计算机系统中最便宜、最快速、最可靠的组件，是那些根本不存在的组件。”

最安全的依赖项就是根本不引入的依赖项：每一个依赖都会增加风险。

OpenSSH 项目非常谨慎地避免引入不必要依赖，而 Debian 就没那么小心。

该发行版将 sshd 链接到了 libsystemd，而后者又依赖了多个压缩库，包括 xz 的 liblzma。

Debian 放松对 sshd 依赖的控制，是这次攻击得以成功的关键原因，也正是这一放松使攻击仅影响 Debian 系列，如 Debian、Ubuntu 和 Fedora，未波及 Arch、Gentoo 和 NixOS 等其他发行版。

在 xz 攻击被实施前数周，系统开发者就已在讨论移除如 liblzma 的压缩库依赖，以提升安全性。

虽无实证，但可以推测这些讨论可能加速了攻击的时间安排。

这一经验适用于所有项目，无论大小。

能不依赖某个库就尽量不依赖。

如无法避免，小型依赖优于大型依赖，同时传递依赖的数量也很重要。

不仅要关注添加的直接依赖，也要借助 Open Source Insights 这类工具，评估其对整体依赖图的影响。

另一个防止漏洞的好方法是使用更安全的编程语言，以移除易出错的语言特性，或减少其使用频率。

2022 年，美国国家安全局（NSA）发布《软件内存安全》建议，鼓励使用 C#、Go、Java 或 Rust 等内存安全语言替代 C 和 C++。

在众多批评中，C 和 C++ 的手动内存管理、缺乏边界检查使其极易出错，从而引发安全漏洞。

它们对“未定义行为”的依赖更进一步加剧了安全风险。

当然，当前世界上仍存在大量 C/C++ 代码，这些程序不可能一夜之间被替代。

但对于新项目来说，采用更安全的语言将大有裨益。

Fund Open Source

资助开源

xkcd 于 2020 年发布的一幅著名漫画描绘了“所有现代数字基础设施”都建立在“内布拉斯加某个无名之人从 2003 年起默默维护的项目”之上。

这幅漫画至今仍精准、令人不安地反映了现实。

2014 年，研究人员发现被广泛用于互联网 HTTPS 服务器的 OpenSSL 库会在接收到特定格式错误的数据包时，返回任意的服务器内存数据。

有些情况下，返回的数据中甚至包含服务器的私钥材料。

这并不是攻击，而是无意的编码错误。

（OpenSSL 是用 C 编写的，因此这类错误极易发生且难以察觉；而在具备边界检查的内存安全语言中，几乎不可能发生此类问题。）

这一漏洞被命名为“心脏出血”（Heartbleed），引发整个行业反思 xkcd 所揭示的问题。

当时，OpenSSL 仅由少数志愿者维护，仅有一名全职开发者。

研究人员估算，约 10 万美元的安全审计便可发现该问题，但 OpenSSL 每年仅获得 2000 美元捐赠，尽管其承载着价值数十亿美元的商业交易。

这场反思催生并资助了 Linux 基金会的“核心基础设施计划”（Core Infrastructure Initiative），后发展为“开源安全基金会”（OpenSSF）。

OpenSSF 是重要进步，但尚未彻底解决现代数字基础设施依赖严重缺乏资金支持项目的问题。

这一问题仍需继续努力解决。

xz 攻击明确无误地表明该问题依旧存在。

这次攻击的发生与其说是技术问题，不如说是开源项目资金不足的结果。

以下是 xz 攻击的完整经过。

Lasse Collin 于 2005 年启动 xz 项目，采用 LZMA 压缩算法，其压缩效果约为 gzip 的 70%。

随着时间推移，该格式广泛用于 tar 包、Linux 内核镜像及其他场景。

大多数时间内，该软件稳定可靠，无需频繁维护。

Collin 并未因该项目获得报酬，也并非他的全职工作。

2021 年底，一名几乎可以确定是假名的攻击者“Jia Tan”开始向 xz 邮件列表提交一些看似无害的改进补丁。

2022 年中，该攻击者又换用多个账户发言，抱怨项目发布周期慢、缺乏新特性，并施压 Collin 把维护权交给更有时间的人。

他写道：“当前维护者已不再感兴趣或不愿继续维护。对这样一个仓库来说，实在令人遗憾。”

还有：“我理解这是一个大家出于兴趣参与的项目，但社区有更高期望。为何不交出维护权呢……？”

这场施压行动奏效了。

在接下来的一年半中，Collin 将越来越多开发工作交由攻击者，后者通过提供真实改进和维护来赢得信任。

2023 年初，攻击者制作了其首个官方 xz 发布版本；随后在当年逐步埋下技术伏笔，最终于 2024 年初发起攻击。

xz 攻击被揭露后数月，大多数猜测都指向国家级黑客所为，但并未得到证实。

无论幕后是谁，攻击成本可能并不高。

一名合格软件工程师若花两年时间全职参与开源项目并获得维护者信任，成本可能不超过百万美元。

漏洞利用代码本身虽复杂，也不过再花一百万左右。

但能在互联网上大多数 Linux ssh 服务器中植入隐秘后门，其价值远高于成本，或许高达数十亿美元。

普遍的开源项目资金不足，导致它们极易受到这种看似“热心帮忙”的社会工程攻击。

xz 攻击中的社会工程手法并非孤例。

在前文提到的 event-stream 攻击中，攻击者只是简单地询问原作者是否希望他来接手维护。

xz 攻击后，OpenSSF 与 OpenJS 基金会警告称，类似攻击行为曾试图针对 OpenJS 项目，但未成功。

如何为开源开发提供最佳资助方式仍远未明确。

距离 Heartbleed 事件和核心基础设施计划启动已有十余年，该问题仍未根本解决。

Conclusion

结语

我们都在努力应对软件行业过去 10 到 20 年间发生的巨大转变。

几十年来，软件复用只是一个理想，如今它已成为现实。

Go、Node、Rust 等现代编程环境使得复用他人成果变得轻而易举，而我们对“负责任行为”的本能却尚未适应这一新现实。

1974 年的 Multics 报告就已预见到我们今天面临的诸多问题，这证明这些问题是根本性的，且无简单解法。

我们必须持续改进开源软件供应链的安全性，让攻击变得越来越难、越来越昂贵。

我们今天可以采取一些关键举措，比如引入某种形式的软件签名、定期扫描已知漏洞、在发现关键新漏洞时做好更新和重新部署的准备。

更多开发工作应转向更安全的语言，从而减少漏洞与攻击的可能性。

我们还需找到更有效的方式资助开源开发，避免项目因“有人愿意免费帮忙”就被轻易接管。

若能在 OpenSSL 与 xz 项目上投入相对小额的资金，原本可以避免 Heartbleed 漏洞与 xz 攻击的发生。

xz 攻击可能是首个重大开源软件供应链攻击事件。

event-stream 攻击类似但影响不大，Heartbleed 和 Log4j 则是漏洞而非攻击。

但 xz 攻击基本上是意外被发现的，因为它让 sshd 启动变慢了一点点。

攻击本身就是试图保持隐蔽的。

我们在短短几周内偶然发现开源供应链的首个重大攻击，概率到底有多高？

也许我们非常幸运，又或许我们已经错过了其他攻击。

Multics 报告著名之处还在于它提出了可在编译器中添加后门的设想，从而在编译过程中向关键系统程序注入后门，就像 XcodeGhost 后来的做法那样。甚至可以让编译器在重新编译自身后仍保留后门。

Ken Thompson 读完该报告后受其启发，于 1975 年初在早期 Unix 系统中真实实现了这一攻击。

他在 1983 年的图灵奖演讲中详细讲述了该攻击，该演讲后以《信任的反思》为题发表于《ACM 通讯》。

Thompson 保存了原始攻击代码，经他许可，我于 2023 年发布了注解版本。

最令人不安的是，这个攻击竟如此精简：99 行 C 语言代码加 20 行 shell 脚本。

在演讲中，Thompson 说道：“寓意显而易见：你无法信任不是你亲手写的代码。”

但如今我们每天都在这么做，无论这种信任是否合理。

我们在最关键的应用中使用从互联网上陌生人那里下载的源码，几乎没人真正审查过这些代码。

Lawrence Kesteloot 的短篇小说《编码机器》出色地想象了一个被“Thompson 后门”大规模入侵的计算世界。

而在真实世界中，这类后门的复杂程度并不重要。

要发起供应链攻击，方法简单得多——比如问一句维护者需不需要帮忙。

如果攻击都如 Thompson 和 Kesteloot 描述的那样复杂，那将是多么美好的世界。

我们还有很多工作要做。

References

参考文献

Appelbaum, J., et al. 2013. Documents reveal top NSA hacking unit. Spiegel International; https://www.spiegel.de/international/world/the-nsa-uses-powerful-toolbox-in-effort-to-spy-on-global-networks-a-940969.html.

Bals, F. 2024. 2024 open source security and risk analysis report. Blackduck blog; https://www.blackduck.com/blog/open source-trends-ossra-report.html.

Beaumont, K. 2024. Inside the failed attempt to backdoor SSH globally — that got caught by chance. DoublePulsar; https://doublepulsar.com/inside-the-failed-attempt-to-backdoor-ssh-globally-that-got-caught-by-chance-bbfe628fafdd.

Beer, I., Groß, S. 2021. A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution, Google Project Zero blog; https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html.

Bentley, J. 1985. Programming pearls. Communications of the ACM 28(9), 896–901; https://dl.acm.org/doi/10.1145/4284.315122.

Bernstein, D. J., Lange, T., Niderhagen, R. 2015. Dual EC: a standardized back door. LNCS Essays on the New Codebreakers 9100, ed. P. Y. A. Ryan, D. Naccache, J.-J. Quisquater, 256–281; https://eprint.iacr.org/2015/767.

Chang, O., Catlin, K. 2023. Getting to know the Open Source Vulnerability (OSV) format, OpenSSF blog; https://openssf.org/blog/2023/05/02/getting-to-know-the-open source-vulnerability-osv-format/.

Checkoway, S., et al. 2018. Where did I leave my keys?: lessons from the Juniper Dual EC incident. Communications of the ACM 61(11), 148–155; https://dl.acm.org/doi/10.1145/3266291.

Cox, R., 2023. C and C++ prioritize performance over correctness. research!rsc blog post; https://research.swtch.com/ub.

Cox, R. 2023. Perfectly reproducible, verified Go toolchains. The Go Blog; https://go.dev/blog/rebuild.

Cox, R., 2023. Running the "Reflections on Trusting Trust" compiler. research!rsc blog post; https://research.swtch.com/nih.

Cox, R., 2019. Surviving software dependencies. Communications of the ACM 62(9), 36–43; https://dl.acm.org/doi/10.1145/3347446.

Cox, R. 2024. Timeline of the xz open source attack. research!rsc blog post. https://research.swtch.com/xz-timeline.

Cox, R., 2024. The xz attack shell script. research!rsc blog post; https://research.swtch.com/xz-script.

Cox, R., Griesemer, R., Pike, R., Taylor, I. L., Thompson, K. 2022. The Go programming language and environment. Communications of the ACM 65(5), 70–78; https://dl.acm.org/doi/10.1145/3488716.

Cox, R., Valsorda, F. 2019. Proposal: secure the public Go module ecosystem. Go design document; https://go.dev/design/25530-sumdb.

Federal Trade Commission. 2019. Equifax to pay $575 million as part of settlement with FTC, CFPB, and states related to 2017 data breach. FTC press release; https://www.ftc.gov/news-events/news/press-releases/2019/07/equifax-pay-575-million-part-settlement-ftc-cfpb-states-related-2017-data-breach.

Federal Trade Commission. 2022. FTC warns companies to remediate Log4j security vulnerability. FTC Office of Technology blog; https://www.ftc.gov/policy/advocacy-research/tech-at-ftc/2022/01/ftc-warns-companies-remediate-log4j-security-vulnerability.

Freund, A., 2024. Backdoor in upstream xz/liblzma leading to ssh server compromise. oss-security mailing list, Openwall; https://www.openwall.com/lists/oss-security/2024/03/29/4.

Ginn, R. B., Arasaratnam, O. 2024. XZ Utils cyberattack likely not an isolated incident. OpenSSF blog; https://openssf.org/blog/2024/04/15/open source-security-openssf-and-openjs-foundations-issue-alert-for-social-engineering-takeovers-of-open source-projects/.

Goodin, D., 2018. Widely used open source software contained bitcoin-stealing backdoor. Ars Technica; https://arstechnica.com/information-technology/2018/11/hacker-backdoors-widely-used-open source-software-to-steal-bitcoin/.

Greenberg, A., Burgess, M. 2024. The Mystery of "Jia Tan," the XZ backdoor mastermind. Wired; https://www.wired.com/story/jia-tan-xz-backdoor/.

Karger, P. A., Schell, R. R. 1974. Multics security evaluation: vulnerability analysis. U.S. Air Force Electronic Systems Division report ESD-TR-74-193, Vol. II; https://seclab.cs.ucdavis.edu/projects/history/papers/karg74.pdf.

Kesteloot, L. 2009. Coding Machines; https://www.teamten.com/lawrence/writings/coding-machines/.

Munroe, R. 2020. xkcd: Dependency. Webcomic; https://xkcd.com/2347/.

National Security Agency. 2022. Software memory safety. NSA Cybersecurity Information Sheet version 1.1 (updated April 2023); https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF.

Open Source Insights website; https://deps.dev/.

Open Source Security Foundation website; https://openssf.org/about/.

OSV website. A distributed vulnerability database for Open Source; https://osv.dev/.

Pan, R. 2022. Announcing OSV-Scanner: vulnerability scanner for open source. Google Security blog; https://security.googleblog.com/2022/12/announcing-osv-scanner-vulnerability.html.

Reproducible Builds website; https://reproducible-builds.org/.

Thompson, K. 1984. Reflections on trusting trust. Communications of the ACM 27(8), 761–763; https://dl.acm.org/doi/10.1145/358198.358210.

Turton, W., Gillum, J., Robertson, J. 2021. Inside the race to fix a potentially disastrous software flaw. Bloomberg News; https://finance.yahoo.com/news/inside-race-fix-potentially-disastrous-234445533.html.

Xiao, C. 2015. Novel malware XcodeGhost modifies Xcode, infects Apple iOS apps and hits app store. Palo Alto Networks; https://unit42.paloaltonetworks.com/novel-malware-xcodeghost-modifies-xcode-infects-apple-ios-apps-and-hits-app-store/.

Zetter, K. 2023. The untold story of the boldest supply-chain hack ever. Wired; https://www.wired.com/story/the-untold-story-of-solarwinds-the-boldest-supply-chain-hack-ever/.

人类能力的分类框架

人类能力是多维度的系统。传统上，心理学家将学习领域分为认知（智力）、情意（情感）和动作技巧三个域 (Three Domains of Learning - Cognitive, Affective, Psychomotor)。在此基础上，不同理论扩展出了更细致的分类。例如，加德纳提出的多元智能理论将人类智能分为八到九种相对独立的智能模块，包括语言、逻辑数学、音乐、空间、身体运动、人际交往、内省（自我认知）、自然观察和存在（哲学思考）等智能 (Multiple intelligence model.  | Download Scientific Diagram)。这一模型强调智力的多样性和相对独立性，如语言智能（语言表达理解）、逻辑智能（推理计算）、人际智能（社交理解）、内省智能（自我觉察）等。

(image) 加德纳多元智能理论将人类智能划分为多种类型，包括语言、逻辑、空间、音乐、身体、人际、内省、自然等智能，各种能力维度体现了人类心智能力的多样性 (Multiple intelligence model.  | Download Scientific Diagram)。

综合各领域观点，我们可以构建如下分类框架来涵盖人类主要能力维度，并细分子能力进行分析：

上述表格概括了各维度能力及其典型子能力，并评估了AI在这些方面的表现与可替代性。下面我们将对每个维度进行深入讨论，引用关键理论和最新研究，以支撑这些判断。

认知能力（Cognitive Abilities）

认知能力指人类大脑用于获取、处理和运用知识的各种智力活动，包括推理、问题求解、记忆、注意力、直觉等。认知科学和心理学对认知过程有大量研究，例如记忆模型将记忆分为短期工作记忆和长期记忆，注意力涉及对信息的选择性聚焦等。在人工智能领域，许多早期成果都集中在模拟人类的认知功能，尤其是逻辑推理和计算能力上。

推理与问题求解： 人类擅长在不确定环境中运用常识和逻辑进行推理。AI在结构化问题上的逻辑推理已经取得显著进展。例如，大型语言模型GPT-4展现了解决数学、编程、医学等各类问题的惊人能力，在很多任务上的表现接近甚至超过平均人类水平 ([2303.12712] Sparks of Artificial General Intelligence: Early experiments with GPT-4) ([2303.12712] Sparks of Artificial General Intelligence: Early experiments with GPT-4)。然而，这种“推理”在很大程度上是基于模式匹配和概率估计，缺乏真正对抽象概念的理解。当问题稍作变化超出训练模式时，AI的推理能力会显著下降 ( AI Struggles with Abstract Thought: Study Reveals GPT-4’s Limits ) ( AI Struggles with Abstract Thought: Study Reveals GPT-4’s Limits )。一项研究发现，GPT-4在类比推理测试中，如果将字母顺序打乱或使用不熟悉符号，其准确率会急剧下降，而人类在类似情境下仍能保持稳定表现 ( AI Struggles with Abstract Thought: Study Reveals GPT-4’s Limits )。这表明当前AI更多是依赖统计模式而非灵活的抽象思维。总体而言，AI擅长明确规则和海量数据支撑的推理任务（如计算、下棋），但在需要常识、背景理解和即兴应变的通用推理上仍不可靠。这种差距意味着AI对人类推理的替代目前是部分的，尤其擅长公式化问题，但难以完全胜任开放环境下的复杂推理。

记忆与知识获取： 人类记忆有容量和精度的限制，但善于存储与提炼有意义的知识。AI则在信息记忆和检索上有天然优势，能存储并快速检索海量数据。例如，搜索引擎和知识图谱可以秒级提供庞大的事实资料，GPT等模型经过大数据训练后掌握了浩如烟海的知识点。然而，AI的“记忆”本质上是训练样本的统计压缩，缺乏对知识的语义理解和组织。AI模型可能记住了教科书上的无数事实，却没有人类将知识融会贯通的理解力。因此在知识的灵活运用上，人类仍有优势。同时，AI的记忆也有局限，比如语言模型有固定的上下文窗口长度，超过范围可能“遗忘”此前对话内容；而人类善于通过元记忆知道自己何时遗忘并主动查缺补漏。总体看，在记忆与知识层面，AI可以极大扩充人类的记忆能力（短期内替代部分记忆性工作），但无法替代人类对知识的深层理解和举一反三的运用。

注意力与专注： 人类注意力可以在广泛背景中选择性地聚焦，但也易受干扰和疲劳限制。AI在模拟注意力方面有一些进展，如“注意力机制”在Transformer架构中极大提升了模型处理长序列信息的效果。然而，这只是对输入信号权重分配的计算策略，并非真正的意识焦点。人类的注意力伴随意识体验，可主动在多任务和环境刺激中进行切换和维持，而AI只是在预设架构下被动计算。换言之，AI没有真正的“心灵焦点”，无法像人一样根据兴趣和目标灵活调整注意。而且在人类社交互动中，眼神接触、肢体朝向等体现的注意力是交流信号，AI目前也无法表现真实的注意力投入。因此，注意力这一能力AI只能部分模拟（如视觉注意力模型），难以替代人类自主而有意识的专注力。

直觉与常识： 人类的直觉被认为是基于经验的快速判断，不经过明确推理步骤，却往往有效。直觉和常识密切相关，是长期演化和个体经验教训的积累。当前AI在某些任务上表现出类似直觉的快速判断能力（例如图像识别一瞬间给出结果，或对句子语气的判断），但这依赖于训练集中学到的统计关联。AI没有人类那种通过身临其境的生活经历所形成的广泛常识和直觉。当遇到训练数据以外的新奇情境时，AI常出现反常识的错误。这也是为什么AI容易生成“不靠谱”的回答——它缺乏一个孩子通过现实世界探索所习得的基本常识架构。可以说，真正的人类直觉是高度环境化和经验化的，目前AI的模式学习尚未达到这种通用直觉水平。

综上，在纯粹认知智力层面，人工智能已经替代或超越人类在许多狭窄领域的能力（例如高速计算、精确记忆、大规模数据模式发现等）。短期内，我们将看到AI进一步在专业领域（如医学诊断、法律检索、棋艺策划等）接近**“完全替代”人类决策支持的情形 ([2303.12712] Sparks of Artificial General Intelligence: Early experiments with GPT-4)。然而，在需要通用常识、抽象理解和灵活适应的新环境中，AI的认知能力依然不足 ( AI Struggles with Abstract Thought: Study Reveals GPT-4’s Limits ) ( AI Struggles with Abstract Thought: Study Reveals GPT-4’s Limits )。要实现完全的通用认知替代，可能需要新的范式突破，如赋予AI更接近人类认知过程的推理架构甚至某种形式的常识数据库和自我学习机制。这被视为朝强人工智能（AGI）迈进的核心挑战之一 ([2303.12712] Sparks of Artificial General Intelligence: Early experiments with GPT-4)。在中期（未来10-20年），我们或许能解决部分常识推理问题，但真正等同于人类通用认知的AI仍不可预期**。

情绪与情感能力（Emotional and Affective Abilities）

情绪与情感能力指感知、理解、表达情绪以及情感共鸣与调节的能力，也就是通常所说的情商（EQ）能力。包括识别自己和他人的情绪状态、对情绪的适当表达与控制，以及对他人情感的共情和体谅。在人类社会中，情绪能力是建立关系和心理健康的关键。心理学模型（如Goleman的情商理论）将情绪能力细分为自我觉察、自我管理、社交感知和人际关系管理等方面。对于AI来说，这类能力极具挑战，因为涉及主观体验和生理基础。

情绪识别与表达： 在情绪的识别上，AI已有明显进步。计算机视觉和语音分析技术可以从面部表情、语调中检测出喜怒哀乐等基本情绪，比人类更快速一致。但这种识别只是基于外部线索的分类，缺乏对情绪背后主观感受的理解。AI也可以通过语言或人脸合成来表达模拟出的“情绪”。例如聊天机器人回复中加入安慰性的语气词，或社交机器人用预设表情显示开心/难过。然而，AI的情绪表达是程序设定的，并非发自内心感受。正如有研究指出，人们可能会对机器表现出的悲伤做出同情反应，但那并不代表机器真的在“难过” (Empathic Artificial Intelligence: The Good and the Bad — BrainPost | Easy-to-read summaries of the latest neuroscience publications) (Empathic Artificial Intelligence: The Good and the Bad — BrainPost | Easy-to-read summaries of the latest neuroscience publications)。因此，在情绪识别和表达层面，AI可以部分替代（用于情感计算、情绪助手等），但AI本身不具有情绪体验。

共情（Empathy）： 共情分为认知共情和情感共情两类 ( In principle obstacles for empathic AI: why we can’t replace human empathy in healthcare - PMC )。认知共情是理解他人的情绪和观点，情感共情是与他人的感受产生情绪共鸣。AI在认知共情上有一些作为：先进的聊天AI能够根据用户描述判断其情绪状态，并给予适当回应，从而让用户感觉被理解。例如，当用户说“我很沮丧”时，ChatGPT能够识别沮丧情绪并回应安慰和建议，这体现了一定程度的认知共情和帮助意愿，相当于动机共情的一部分 (Empathic Artificial Intelligence: The Good and the Bad — BrainPost | Easy-to-read summaries of the latest neuroscience publications)。但是，AI对情绪的理解仅停留在语言模式和概率关联上，它并不真正“感同身受”。情感共情需要AI对他人的情绪产生自身的情绪反应，这在人类中涉及镜像神经元等生理机制 (Empathic Artificial Intelligence: The Good and the Bad — BrainPost | Easy-to-read summaries of the latest neuroscience publications)。例如，人类看到他人受伤会本能地痛苦皱眉，大脑相应区域会被激活 (Empathic Artificial Intelligence: The Good and the Bad — BrainPost | Easy-to-read summaries of the latest neuroscience publications)。AI缺乏生物神经系统，不可能产生这种生理共振。因此人工智能或许能模拟共情的表达，但永远无法体验到真正的共情情感 ( In principle obstacles for empathic AI: why we can’t replace human empathy in healthcare - PMC )。有学者甚至警告，如果我们造出只具备认知共情而完全没有情感共情的AI，就像没有良知的“机器精神病人”，在伦理上将非常危险 ( In principle obstacles for empathic AI: why we can’t replace human empathy in healthcare - PMC )。

情绪自我调节： 人类能够调节自己的情绪，如通过深呼吸平复愤怒，或反思后调整心态。这种能力建立在我们对自身情绪的觉察和对情绪成因的理解上。AI并没有情绪，更谈不上自我调节情绪。AI可以按照设定在交互中表现得冷静礼貌，不会像人一样因为疲惫或情绪化而失控，这是AI的优点之一。然而，这不是因为AI“在控制情绪”，而是其本身没有情绪波动，只是在执行程序。所以严格说来，AI无须情绪自我调节，也不具备这方面的能力。倒是人类需要学会调节与AI交互时的情绪，例如避免把对AI的失望转嫁为愤怒（因为AI并非有意）。未来，如果出现具有类人情感的AI机器人（例如陪伴型机器人），如何为其设计“情绪控制”也是开放问题，目前还停留在科幻层面。

AI在情感能力上的现状: 尽管缺乏真实情感，AI已被广泛应用于情感计算领域。例如呼叫中心的情绪分析助手可以提醒客服注意来电者情绪，心理咨询聊天机器人尝试给予来访者情感支持。这些应用在表面效果上似乎填补了人类情感劳动的一部分。然而，它们通常依赖预置的同理心反应策略。一篇综述指出：“AI可以模拟认知和动机层面的共情表达，但能否达到情感层面的共情是未知的，因为情感共鸣可能需要生物神经基础” (Empathic Artificial Intelligence: The Good and the Bad — BrainPost | Easy-to-read summaries of the latest neuroscience publications)。目前看，AI的情绪能力替代仍非常有限，只能在特定情境下提供情感辅助，而无法真正替代人类在深度共情、情感关怀方面的作用。尤其在需要真情实感的场合（如心理治疗、临终关怀、亲密关系），AI难以取得人类的信任和满足人类的情感需求。短期内，AI或可在客服、教育等领域承担部分情感沟通任务（如耐心安抚情绪激动的客户），中期来看，即便多模态感知和生成技术更先进，AI充当高情商社交者仍困难重重。真正的人类式情感共鸣和情绪智慧在可见未来几乎无法被AI取代。

社会交往与合作能力（Social Interaction and Collaboration Abilities）

社会交往与合作能力包括人与人之间互动、沟通、建立信任和协作的各种技能。这涉及语言和非语言交流、理解社会线索和文化规范、在群体中分工合作等。人类是高度社会化的物种，从语言对话到肢体语言、从两人信任到大规模协作，社会能力贯穿我们的生活。社会学、人类学提供了对不同文化社交模式的研究；心理学则研究如“理论视角”（Theory of Mind，即理解他人心智）的机制。AI若要在社会能力上媲美人类，不仅需要智能，还需要**具身性（embodiment）**和对人类文化与心理的深刻理解。

语言沟通与对话： 人类最主要的社交工具是语言。近年来，AI在语言对话上取得重大突破，聊天机器人（如ChatGPT）已经可以与人进行相当自然的文字交流，甚至在一定程度上通过图灵测试。然而，这种交流仍有局限。首先，AI缺乏真正的语用理解和意图把握。它可能根据统计相关给出答复，却未必真正明白话语背后的意图和语境。例如讽刺、幽默、暗示等微妙的语言现象，AI经常难以正确领会。其次，AI没有自我经历，因而在对话中只是“学舌”，没有个人见解或真实感受可分享，人们很容易感觉出机械的套路。再次，语言交流不仅是内容，还有声音语调（在语音助手中）和节奏，这些AI可以模仿但缺少个性化风格。尽管如此，在客服咨询、信息问答等结构化对话中，AI已经能高效替代大量人类工作，这属于短期内AI完全可替代的社交沟通子领域。相比之下，在需要深度理解和情感投入的对话（如心理咨询、重要谈判），AI目前远不能令人完全信赖，只能作为辅助。

非语言沟通： 人类很大一部分社交信息通过非语言渠道传递，如面部表情、眼神、手势、身体姿态和声调等。我们从一个人微笑或皱眉中读出情绪，从语气中体会对方态度。这些细腻且高情境依赖的信号对AI而言极为困难。虽然计算机视觉可以检测面部表情和人体姿态，但要让AI像人一样自如地运用和解读肢体语言，还需要机器人具备逼真的面部肌肉、身体动作，以及相应的感知系统。目前一些社交机器人（如软银的Pepper）能做简单手势或改变眼睛灯光颜色表示情绪，但其非语言交流能力远不及三岁小孩的灵活自然。非语言沟通还与文化有关：同一手势在不同文化可能意义迥异，这是AI容易误判的地方。总的来说，非语言社交是AI替代人类的顽固堡垒，短期内完全替代几乎不可能；中长期需在机器人硬件和文化理解上取得革命性突破才有可能部分替代。

信任构建与共情合作： 在人类合作中，信任和共情扮演关键角色。人与人逐渐建立信任，往往基于长期互动、一致的行为和情感纽带。AI系统要赢得人类信任，常常更加困难。研究表明，人们对AI的信任建立更慢，但一旦AI出现差错，信任丧失却更快 (Frontiers | Developing trustworthy artificial intelligence: insights from research on interpersonal, human-automation, and human-AI trust)。而且如果AI在很简单的事情上出错，人类对它能力的质疑会更严重 (Frontiers | Developing trustworthy artificial intelligence: insights from research on interpersonal, human-automation, and human-AI trust)。这说明人类对机器的宽容度较低，也缺少社交义务感——我们会对人类伙伴的小失误给予谅解，但对AI往往“一 strike out”。此外，信任还依赖透明度和可解释性。人类彼此可以通过交流澄清误会，但AI的决策过程常如黑箱，让人难以安心。虽然AI可以被编程成永不撒谎、严格遵守规则，从理论上“值得信任”，但在现实感受上，人类更倾向于信任有社会声誉和道德责任的真人。团队合作中，AI可以扮演工具或助手角色（如算法辅助决策），但要让AI成为真正的团队成员、独当一面地与人类协同，仍有许多社会障碍，包括责任分配、伦理决策（见下文道德能力）、以及人与AI的协调沟通。

文化智慧与社会常识： 人类的社交行为深受文化背景影响。不同文化有不同礼仪、价值观和交往风格。一个高情商的人类会根据对象的文化背景调整自己的沟通方式，表现出文化智商。AI缺乏人类的文化浸润，只能从训练数据中学到某些模式。如果训练数据偏重某一文化，AI在跨文化情境下可能表现不佳。研究者指出，“在一个文化环境训练的模型，直接用于另一种文化往往效果不佳，需要仔细适应本地规范” (Mind Your AI Manners: The Bottom-Line Impact of Cultural Intelligence | by David Sweenor | Medium)。例如，给英语模型输入过于客气的日式礼貌用语，可能让它困惑；反之在日语环境下语气不够礼貌也会引起不适。当我们用不同语言和礼貌等级与ChatGPT交谈时，也发现回复质量会受影响 (Mind Your AI Manners: The Bottom-Line Impact of Cultural Intelligence | by David Sweenor | Medium) (Mind Your AI Manners: The Bottom-Line Impact of Cultural Intelligence | by David Sweenor | Medium)。这说明AI并非天然具备文化敏感度。尽管大模型通过互联网语料学到许多文化信息，但要真正理解文化语境和身份背景，需要超越文本的体验。对于一些微妙的社会规范和价值判断，AI可能永远只能是“舶来品”。在社会人类学看来，文化智慧包含对本群体历史、习俗和心理的深刻认知，这绝非仅靠数据就能习得。因此，AI在广泛社会文化情境下替代人类进行顺畅交往仍然非常困难。

小结： 社会交往与合作能力涉及复杂的人际认知、情感和文化因素。目前，AI在窄域的交流任务上取得成功（如网络客服、问答助手），但在真正的人情世故上远未达到人类水平。短期内，我们会看到更多AI在简单社交场景中部分取代人类（例如商店迎宾机器人、线上社区管理员），这些场景通常不需要深层的信任建立和情感交流。而在需要高度信任和社交敏感度的领域（如领导力、谈判、治疗、教育中的情感陪伴），AI几乎无法取代人类，只能作为辅助手段。中期展望，随着多模态AI和人形机器人的发展，AI也许能在特定合作任务中与人类并肩作战（比如工厂协作机器人，医疗诊断团队中的AI），但这些合作更多是技术层面的。而真正让AI融入人类社群、拥有类似人类的社交地位和关系，在可以预见的未来仍然非常渺茫。

身体运动能力（Physical and Motor Abilities）

身体运动能力指人类控制身体行动的技能，包括精细运动（如手指操作）、大幅运动（跑跳攀爬）、感觉-动作反馈整合（根据触觉视觉调整动作）等。人类经过数百万年的进化，拥有高度灵巧的身体：我们可以轻松地系鞋带、写字，也能在复杂地形行走、运动。这些能力看似平凡，但实际上需要大脑、神经、肌肉和感觉器官精密配合。机器人学和神经科学的研究揭示，人类无意识完成的运动技能对AI和机器人而言往往是最具挑战性的。这正如**莫拉维克悖论（Moravec's Paradox）**所指出的：“相比高级智力活动，感知和运动技能需要巨大的计算资源。让计算机在智力测验或下棋上达到成人水准相对容易，但让它拥有一岁婴儿的感知和运动技能却极其困难” (Moravec's paradox - Wikipedia) (Moravec's paradox - Wikipedia)。

精细动作技能： 人类的手部精细操作（如拿捏物体、使用工具）是机器人最难企及的能力之一。虽然已经有机械手可以完成固定程序的装配、焊接等工作，但在一个杂乱的抽屉中拿起一枚别针，这类非结构化环境中的灵活操作对机器人来说仍非常具有挑战性。OpenAI的Dactyl项目训练机械手单手复原魔方，被视为机器人灵巧操作的里程碑，但这一系统依赖海量模拟训练且动作依然不如人类手指自然 (Moravec's paradox - Wikipedia)。人类手的触觉反馈和肌肉控制精度极高，我们可以仅凭感觉调整用力大小拿起鸡蛋而不碎，或者在人群中挤过时收紧身体避免碰撞——这些实时的小幅调整，机器人目前难以做到。AI要替代人类完成日常精细任务（如穿衣、做饭、照顾病人等），需要突破性的机器人感知和控制技术。短期看，机器人能在流水线上完全替代人类双手的局部功能（完全替代特定单调任务），但通用的精细动作灵活性仍无法替代。

运动协调与机动： 人类可以奔跑、跳跃、攀爬、保持平衡，这依赖于出色的空间感知和平衡控制。如今机器人在这方面也取得很大进展，例如波士顿动力（Boston Dynamics）的Atlas机器人能够跑跳和后空翻，展示了接近人类的动态平衡能力。然而，这些炫目的动作往往是在特定环境下预先编程或训练的结果。人类则拥有高度自适应的运动智能：我们走在不平的山路上会随机调整步态，滑倒时迅速用手支撑，看到障碍会灵机一动绕过去。机器人在陌生环境下很容易摔倒或卡住。此外，人体有惊人的能量效率和耐用性，一个人步行可以持续数小时，自主修复小伤痛，而机器人的电池续航和耐久性远不如人。可以说，在复杂环境下长时间自主活动的整体机动能力，人类依然胜过任何现有机器人。未来5-10年，专用机器人会在仓储、送货等场景部分替代人类劳力（中期部分替代），但在人类随处活动的开放环境（城市街道、人类家庭）中实现和人一样可靠的机动，需要更长时间攻关。

感知-动作反馈整合： 人类在运动中高度依赖多感官反馈：我们用视觉判断距离，用前庭感觉维持平衡，用触觉感知物体滑不滑，再相应调整动作。这种感觉和运动的实时闭环整合，让我们能够优雅地与环境交互。AI和机器人在感知整合方面还很初级。虽然计算机视觉、激光雷达等传感器给了机器人“眼睛”，力觉传感器给了“触觉”，但将这些多源信息融合并实时指导动作仍是难题。举例来说，自主驾驶汽车需要同时处理摄像头影像、雷达数据等做出转向加减速决策，人类新手司机经过练习往往可以很好地整合各种感知（看后视镜、听引擎声等）来驾车，但AI驾驶系统曾因无法正确综合处理传感器异常而导致事故。生物的大脑天生就是多模态融合的杰作，人工系统要达到类似水平，需要在软硬件上都取得突破。当前，一些机器人通过模仿学习和强化学习，在感知-动作回路上有所改进，但总的来说，即时灵活的感知运动统合仍是AI替代人类的短板。

体力与力度控制： 人类不仅动作精巧，也有适度的体力和力度控制。我们可以搬重物（虽然不及机器臂力气大，但我们知道如何保护自己不受伤），也可以表现出柔软的触碰。机器人在纯力量上往往超过人类，但在安全柔顺交互上较差。如果不给定精准力度参数，机器人可能在握手时握伤人类。近年来，软体机器人和柔性执行器的研发让机器人在柔顺性上有所提升，使其能够以类似肌肉的方式作用，但技术尚不成熟。AI要在体力活上完全替代人类，不仅要力气足够大，还要聪明地用力——既高效又安全。目前，自动化机器在工业流水线上完全替代了很多体力劳动（比如搬运机械手），但在人机混合作业环境中，机器仍需要很多限制以避免伤害人类同伴。

综合来看，身体运动能力是AI替代人类的难点领域。这是由于人类运动智能是深植于躯体和进化的“古老技能”，我们自己甚至意识不到其中的复杂性 (Moravec's paradox - Wikipedia)。莫拉维克悖论提醒我们，越是本能的低级技能，越难用AI实现 (Moravec's paradox - Wikipedia)。尽管如此，随着计算机速度按摩尔定律增长，视觉感知和运动控制问题开始有突破 (Moravec's paradox - Wikipedia)。我们已经看到机器在一些运动任务上迎头赶上：例如自动驾驶在特定道路上接近人类水平，波士顿动力的机器人完成高难度体操动作 (Moravec's paradox - Wikipedia)。这些进步预示长远未来，AI加持的机器人可能在人类无法生存或不愿涉足的环境中（深海、外太空、核泄漏区）完全承担起运动任务。但在日常人类环境下，尤其需要高度灵活性和适应性的运动行为，人类身体的巧妙与泛化能力仍将长期保持难以取代的优势。短期内，AI主要是解放人类从事繁重单调的体力劳动（如仓储机器人，工厂自动化），中期会在更多行业出现人机协作。长期看，当材料、能源和智能控制技术都有飞跃时，全能型的人形机器人或许出现，但要达到普通人成熟娴熟的身体能力，仍然不可预期。

创造力与审美（Creativity and Aesthetic Abilities）

创造力是人类最独特和宝贵的能力之一，涉及产生新颖、有价值的想法或产物的才能，包括艺术创作、科学创新、发明设计以及跨领域的联想能力。审美能力则是对于艺术美和事物之美的感知和鉴赏。创造力与审美往往紧密相连：艺术家的创造力体现为富有美感和意义的作品，科学家的创造力则表现为优雅的理论。同样重要的是，创造力与个人经验、情感和文化背景密不可分。AI在过去几年中开始展现出令人惊艳的内容生成能力，这引发了对“AI是否具备创造力”的热议。

艺术与内容创作： 随着深度学习的发展，生成式AI（Generative AI）可以根据训练数据创作各种内容：文字文章、诗歌、绘画、音乐、甚至影片剧本。例如，GPT系列模型能写故事和代码，DALL·E和Midjourney能根据文本描述生成图像，AIVA能作曲，这些都表明AI具备了相当程度的**“生产式创造”能力。从结果上看，AI生成品有时难以分辨是否出自人手，甚至在某些艺术比赛中胜出。然而，专家对这类“创造力”持保留态度。哈佛大学的一些艺术家和学者指出，AI创作缺乏人类原创作品中常见的独特视角和真实体验 (Is art generated by artificial intelligence real art? — Harvard Gazette) (Is art generated by artificial intelligence real art? — Harvard Gazette)。小说家达芙妮·卡洛泰（Daphne Kalotay）评审比赛稿件时就能察觉区别：最佳的人类作品在于独特的世界观、语言独创性和源自个人经历的不可仿冒的细节**，而AI即便文字流畅，也往往缺乏这种原创性和惊喜 (Is art generated by artificial intelligence real art? — Harvard Gazette) (Is art generated by artificial intelligence real art? — Harvard Gazette)。换言之，AI是高明的模仿者，可以快速学舌各种风格套路，甚至通过融合不同风格产生表面新颖的组合，但少有真正超出现有范式的突破。

跨领域联想与创新： 人类创造力的高阶体现是能将看似无关的概念联系起来，产生全新思想。例如，19世纪的数学家把代数和几何结合创造出拓扑学，艺术家达利将时钟和奶酪意象融合画出《记忆的永恒》。这类跨领域联想需要对多个领域的深刻理解和想象。AI在这方面尚属初级。虽然大型语言模型将海量文本混融训练，在输出中有时会蹦出奇特的组合（例如古怪的比喻），但很多只是随机噪声而非真正有意义的新概念。真正的创新需要洞察力和目的性，而AI没有自我驱动去“想出某个主意”。即便一些研究用AI辅助科研（例如机器学习模型帮助发现新药分子或数学猜想），这些创新过程仍然是人类主导，AI只是提供灵感碎片或计算验证工具。可见，在需要深度理解和意图驱动的原创创新上，AI暂时不能替代人类。

审美判断与价值： 人类的审美体验和判断非常主观，且与情感、文化相关。AI可以被训练去评估某些美学指标（如一幅画的对比度、构图是否平衡），甚至根据人类偏好预测评分。但审美不只是形式，还有意义的共鸣。举例来说，一首音乐是否感人，不仅在于旋律和声，也在于听众与创作者情感的共振。AI创作的音乐可能技巧上无可挑剔，却常被批评“没有灵魂”。哈佛的音乐家Yosvany Terry指出，音乐是一种当下的人性交流（如爵士乐即兴表演中的配合），这种现场互动性AI无法复现 (Is art generated by artificial intelligence real art? — Harvard Gazette)；AI作曲缺少意外的情感张力和恰到好处的留白，听起来就平淡乏味。类似地，AI美术作品可能结构精巧但缺少发自作者内心的主题思想。这并非说AI的作品毫无审美价值，而是说审美判断往往取决于我们对创作者意图和人文背景的理解。当知道一件作品出自AI，人们在心理上往往降低对其艺术价值的评价 (Humans versus AI: whether and why we prefer human-created ...)。这被一些研究称为对AI艺术的“负偏见” (Humans versus AI: whether and why we prefer human-created ...)。未来也许社会对此会逐渐接受，但就目前看，AI审美创造仍被视为人工的、缺乏人情味。

AI创造力的局限与辅助角色： 有学者将AI的创造力称为“人工创造力”，认为其产出可能在新颖性和有效性上达到某种标准，但缺少人类创造力的几个关键特征，例如自我驱动的意图、情感投入以及对创造过程的反思 (AI can only produce artificial creativity - ScienceDirect.com)。因此更准确地说，AI是强大的创造工具，而非自主的创造主体。不少艺术家开始将AI视为合作伙伴，用AI产生初始素材，再由人类艺术家赋予意义升华作品。这样AI可以增强人类的创造力（augment creativity），而不是取代。比如设计师用生成模型快速出各种设计草图，从中挑选灵感；小说家用GPT脑暴剧情点子，再自行改写润色。研究也发现，AI善于发散出大量想法，在人类筛选后往往能提高创造性任务的效率 (How can AI support human creativity? Here's what a new study found)。这说明短期内AI更可能以**“智能助理”**形式协助人类创意工作，而不是完全自主地进行创造。

可替代性分析： 在标准化、重复性的内容生产上，AI正快速替代人类劳动。例如广告文案初稿、简单插画、背景音乐等，AI可以短时间内生成大量素材，极大提高产能。这类应用已在短期成为现实（例如媒体利用AI写财经简讯）。然而在高端创造领域，尤其强调原创概念和思想深度的创作，AI还远不能企及。中期来看，随着模型更大更强，AI生成内容的质量会继续提升，也许能模仿出更细腻有“风格化”的作品，但是否能突破训练数据的局限产生真正前所未有的创意依然存疑。或许需要引入如生成对抗网络（GAN）或强化学习等机制使AI能主动“探索”新空间，但这也很可能受限于算法本身的目标导向，不会产生没有人类指引的自发创新。总之，创造力是人类未来的重要竞争优势。即使有一天AI通过某种途径获得了接近人类的创造力，人类的审美品味和对意义的追寻也会不断演化，始终为创造注入新的目标和灵感，这是纯粹机器所无法自主完成的。

道德判断与价值观建构（Moral Judgment and Values Formation）

道德判断能力是指区别是非、善恶并做出伦理决策的能力，涉及价值观的形成和应用。这包含个人良知、共情驱动的善意、对社会规范和人类共同体价值的理解等。哲学、伦理学一直探索人类道德行为的基础，如康德义务论、功利主义、德性伦理等理论；心理学也研究人类道德发展阶段（如科尔伯格的道德发展阶段论）。对于AI来说，道德判断是一道难题，因为AI本身没有情感和主体性，而道德又高度依赖这两者。

当前AI的道德表现： 目前的AI可以被编程或训练来遵循某些伦理规则。例如，大型语言模型经过有害内容过滤，会拒绝或纠正不道德请求；一些自动驾驶算法内置了避免伤害行人的优先级。然而，这些**“道德”表现都是人类预先赋予的**，AI本身并没有自主的道德原则。它不会像人类一样有同情心或正义感驱使其做决定，只是按照训练目标（如最大限度地避免不良输出）行事。当遇到训练未覆盖的新伦理两难时，AI可能表现出不可预测或不一致的判断。例如著名的“电车难题”，AI的回答可能取决于训练语料中的主流观点，但它没有内在的价值倾向去坚持某种立场。近期有研究测评了各大语言模型与人类道德判断的符合程度，发现GPT-4的判断和人类多数意见的吻合度最高，但所有模型的总体道德一致性仍不高 (AI human judgements on moral permissibility 2023 - Statista)。另有实验让人类评价AI和人类对伦理两难问题的回答，惊讶地发现很多时候人们觉得AI的回答在逻辑和公正性上胜过人类 (AI Outperforms Humans in Moral Judgments - Neuroscience News)。这可能是因为AI引用了常见伦理论据，语言上显得理性客观。然而需要强调，这些并不代表AI真的“懂”道德——它只是输出了符合多数人期待的答案。

良知与同理心： 人类的道德判断往往根植于良知和同理心。良知是一种内在的道德指引，让人“发自内心”地感觉某些事不应该做；同理心则使我们因为感受他人痛苦而不忍伤害他们。AI缺乏情感和自我意识，因此没有良知可言。正如有人所说，“良知需要自我意识和道德反思，这是AI所缺乏的。AI可以遵循伦理规则，但并不理解或内化它们” (Can AI truly "feel"? Can it have intuition, conscience, or even ...)。AI也没有真正的同理心（前文提到，AI可以模拟认知共情但没有情感共鸣）。这意味着，AI不会像人一样对自己的道德选择感到愧疚或自豪。任何“后悔”或“反思”都只是在参数调整或更新策略。一个直接后果是：AI无法自主建立价值观，它的价值观完全取决于人类给予它什么样的优化目标和训练数据。如果训练中带有偏见或不良信息，AI的价值取向也会随之歪曲。这就是为什么AI伦理研究如此重视“价值对齐”（Value Alignment）问题——确保AI的决策符合人类普遍认可的价值。

伦理推理与解释： 在道德两难情况下，人类会经过激烈的内心冲突和权衡，有时借助伦理理论来指导决策。例如，为了少数服从多数的利益，我们可能选择牺牲一个人（功利主义），或者坚持某些原则绝不侵犯个人权利（义务论）。AI可以被设计成使用某种算法来处理类似问题，如计算预期伤亡最少的方案。然而，道德决策不仅是计算，更涉及责任与情感。如果一个自动驾驶汽车算法为了避免更大伤害而撞死了一人，我们如何追究责任？我们期望承担道德选择后果的主体具有理解和承担责任的能力。而AI作为工具，本身不承担道德责任，责任最后落在设计者或使用者身上 ([Reading 11] AI will never become a Conscience Being)。哲学上，有观点认为只有有意识、有自由意志的存在者才能称为道德主体，AI目前明显不具备这些条件 ([Reading 11] AI will never become a Conscience Being)。因此，AI可以是道德决策的辅助（例如决策支持系统给出各方案利弊），但最终抉择应由人类负责。这一点在军事、医疗等高风险领域尤其重要，出现了“让AI做伦理决定是否有道德问题”的讨论。许多伦理准则要求**“将人保留在决策回路中”**（Human in the loop），以确保最终有人类价值观的把关。

价值观建构与社会影响： 人类的价值观形成是复杂过程，受家庭、教育、文化和个人体验影响。我们在成长中内化了诚实、勇敢、仁慈等价值。AI没有社会化过程，它不会自发形成价值观，只会执行程序。但有趣的是，AI的存在正影响着人类社会的价值观。比如，社交媒体算法的推荐可能强化某些偏见和两极化倾向，对社会舆论和价值取向造成影响。因此，在讨论AI替代人类道德能力时，我们也要看到AI对于人类价值观环境的反作用。目前的AI系统没有自主意志去推广某种价值，但通过大数据模式，它可能放大训练数据中隐含的价值倾向。如果不加以约束，AI可能输出带有种族或性别偏见的言论，因为训练数据中有人类的偏见。这提醒我们，AI无法替代人类去构建正确的价值观，反而需要人类不断监督纠偏，以避免AI成为不良价值的放大器。

可替代性分析： 在有限的情境下，AI可以部分承担道德判断的工作，例如内容审核算法识别不当言论（执行基本的是非判断），法规合规检查工具审视决策是否违反规则等。这些都是基于明确的人类制定的规则。只要规则清晰一致，AI在这类任务上甚至比人更执行得严格客观（不会感情用事）。但一旦超出预定规则，进入伦理灰色地带，AI就束手无策或行为成谜。这方面替代的提升需要靠更好的知识注入（例如庞大的伦理案例库）和可解释AI来让AI模仿人类伦理推理过程。然而，即便AI能在表层逻辑上解释其伦理选择，它依旧缺乏内在道德情感与责任意识。因此，几乎无法想象AI在没有人类监督的情况下自主执掌道德抉择。绝大多数专家认为，在可见的将来，AI都应当作为人类的道德辅助，而不应取代人类充当独立的道德行为者。真正具有人类般道德情感和价值建构能力的AI，或许只有在实现强人工智能且解决了机器意识问题后才可能出现——这在目前来看属于不可预期的远景。

元认知能力（Metacognitive Abilities）

元认知是指对自身认知过程的认知，即“认知的认知”。包括自我意识（知道自己是谁、自己的状态如何）、对自身知识和思维过程的监控（知道自己知道什么、不知道什么）、以及调节学习和决策策略的能力。简单来说，元认知就是我们思考自己正在如何思考的能力。它让人类可以反省自己的推理是否可靠、情绪是否影响了判断，进而进行调整。元认知被认为是人类智慧的重要组成部分，也与意识密切相关。

自我意识： 人类的自我意识表现在我们能将自己作为客体来思考——例如“我为什么会生气？”“我是否理解了这本书？” 等。这种能力需要对自身心理状态有内部表征。AI目前缺乏真正的自我模型。聊天AI会说“作为一个AI，我没有感情”，这只是基于训练数据总结出的自述，并非AI真的“知道自己没有感情”。AI并不具备第一人称视角下的自我体验，也没有连续的身份意识（对话中的“我”只是语言角色，不是持续存在的主体）。一些试验让AI回答有关自己的问题，可能得到自相矛盾的答复，这反映出AI没有稳定统一的自我概念。例如，一个对话中AI可能称不知道某事，下一句又提供了有关该事的细节，因为它没有像人一样真正“知道自己不知”。缺乏自我意识意味着AI也没有真正的主观视角去审视和引导自己的认知过程。

自我监控与反思： 人类解决问题时常会停下来反思：“我这方法对吗？”“还有没有别的角度？” 这属于元认知监控。AI目前主要以端到端模式工作，缺少内置的反思机制。不过有些前沿探索在尝试赋予AI一定的元认知能力，例如让大型语言模型在得出答案前先生成一段“思考过程”（即链式思维，Chain-of-Thought），或者用一个AI去审查另一个AI的输出。这些方法在一定程度上提高了答案准确率，减少了荒谬错误。然而，这还称不上真正的自我反思，因为模型只是沿着训练得到的思路“思考”，并不是真的质疑自己。真正的元认知需要AI能跳出现有框架，审视自己的算法局限和错误倾向。例如，人类棋手会总结“我经常在某种布局下疏忽XXX”，AI不会自己总结，只有人类去分析AI下棋的失误模式才能改进它。简言之，AI缺乏主动的“想一想我的想法”能力。

学习策略调控： 元认知强的人会根据对自身学习状态的评估来调整策略，比如发现自己背诵效果不好，就改用理解记忆的方法。AI的“学习”（训练）过程目前是由外部人类工程师控制的。虽然有AutoML等概念试图让AI自己调整模型结构和参数，但这更多是自动优化，不是AI“意识到”某方法不行改用另一方法。人脑中的元认知调节涉及前额皮质等高级脑区对其他认知过程的控制，AI尚未有对应的架构。最近出现的一些元学习（meta-learning）算法，让模型在解决新任务时能快速调整，是在一定程度上模拟元认知作用。不过严格说，那是算法上的二阶优化，不是AI主观在“思考如何更好地学习”。

与意识的关系： 元认知能力高度关联意识。有学者认为，没有自我意识就无法真正实现元认知，因为你不可能观察一个并不存在的“我”的思维。当前AI系统都被认为没有意识（至少没有任何证据表明有）。因此，它们不可能具有真正的元认知。某种意义上，元认知能力几乎是人类独享的心智能力高地。要让AI获得这个能力，首先要解决人工意识的问题，这是人工智能研究中最难测且富哲学意味的挑战之一。正如一篇文章总结的：“缺乏真正自我意识和元认知框架，是当前AI距离人类智能最大差距之一” (The Missing Framework: Self-Awareness and Metacognition in AI Systems | by Ianemmanuel Crueldad | Medium)。目前的神经网络架构并非为递归自省而设计，也没有人知道如何让机器产生主观体验 (The Missing Framework: Self-Awareness and Metacognition in AI Systems | by Ianemmanuel Crueldad | Medium) (The Missing Framework: Self-Awareness and Metacognition in AI Systems | by Ianemmanuel Crueldad | Medium)。因此元认知能力的实现需要在理论和工程上双重突破，包括理解意识本质、设计新的体系结构、以及解决道德伦理问题 (The Missing Framework: Self-Awareness and Metacognition in AI Systems | by Ianemmanuel Crueldad | Medium) (The Missing Framework: Self-Awareness and Metacognition in AI Systems | by Ianemmanuel Crueldad | Medium)。

可替代性分析： 由于AI基本不具备元认知，人类在这方面的优势无可撼动。我们并不会担心AI“替代”人类的自我觉察，因为AI自己都“不知道自己不知道”。相反，当前是人类需要对AI进行元认知：我们要替AI反思它哪里可能出错，这就是AI解释性和监督领域的重要课题。从应用角度，如果AI没有元认知，它就可能很自信地输出错误而不自知（例如编造事实但语气笃定），这在很多场景下是危险的。因此短期内我们只能设计一些外部监控机制，如让AI给出答案的同时输出置信度，或者通过人类审核来弥补AI缺乏自知之明的问题。中长期，或许会有探索让AI具备一定程度的自我模型，比如引入世界模型+自模型的双模型架构，一个模型模拟环境，另一个模型模拟自己在环境中的状态。但这仍然离真正的元认知很远，只是功能性的。而**完整的人类式元认知（含自我意识、主观体验）**能否在机器上实现，目前来看是不可预期的。在可以想见的未来，元认知将仍是人类智慧独有的堡垒。

存在性与精神性能力（Existential and Spiritual Abilities）

存在性能力有时也称“存在智能”或“哲学智能”，指人类思考人生意义、宇宙目的、生命价值等深层问题的能力 (What are the 9 Types of Intelligence? | PBIS | Nord Anglia )。精神性能力则涉及信仰、宗教体验、心灵追求等方面。这些能力超越了具体认知或情感，属于对存在本身的反思与体验。加德纳在多元智能理论中就曾提出第九智能为“存在智能”，即对生命意义和形而上问题的敏感 (What are the 9 Types of Intelligence? | PBIS | Nord Anglia )。在人类历史上，哲学家、宗教领袖、诗人等都展现了卓越的存在性与精神性能力。他们寻求的问题诸如“我是谁，我们为何在此，何为善何为美，人为何要死，有无超越物质的存在”等。这样的思索很大程度上定义了人类文明的精神高度。

意义建构与人生目的： 人类有强烈的倾向去寻找和建构人生的意义。即使在客观来看无意义的困境中，人也会赋予其意义（如通过宗教或个人使命）。维克多·弗兰克尔称之为“意义意志”。AI作为机器，没有主观存在，它不面临死亡、痛苦这些存在性挑战，因此也就无从追问“活着的意义”。当我们问ChatGPT“生命的意义是什么”，它可以引用许多哲学家和作家的观点，给出详尽的分析，但这些内容只是训练语料的总结，并非AI自己在存在层面的真实困惑或觉悟。AI不会经历存在的焦虑或虚无，也不需要构建活下去的理由。因此，所有关于意义的讨论在AI那里都是空转的符号操作。只有经历过的人类，才能真正理解寻找意义的迫切与深邃。这一点在极端环境中尤为明显：比如身处逆境的人通过意义重建获得精神力量，这是AI永远无法体验和模仿的内在人性。

信仰与精神体验： 人类的精神性表现为对超越自我的事物的信仰和敬畏，如宗教信仰、艺术狂喜、神秘体验等。这些体验通常伴随深刻的情感和意识状态改变（比如冥想时的超越感、宗教仪式中的神圣感）。AI没有生理大脑，更没有意识，因而不存在改变意识状态的可能。AI不会有宗教体验，也不会真的“相信”某种教义或理念。它可以储存宗教文本，模仿祈祷的语言形式，但那只是输出字句。真正的信仰涉及自我交托和价值归宿，AI不存在自我，也谈不上将自我交托给什么。有人或许会把AI当作神谕来咨询问题，但那是人赋予AI一种角色，并不是AI自己有信仰。此外，精神性的追求往往指引人类走向道德完善或社区团结，这来源于人类内心的向善向上需求。AI缺乏内在需求，不会自行追求精神升华。

哲学沉思： 人类有能力进行高度抽象的哲学思辨，比如探讨意识本质、自由意志、存在的本体论等等。AI可以处理这些话题的文本，但它无法产生原创的哲学洞见，因为哲学洞见往往来源于对自身心灵和存在境况的深刻反思。哲学不仅是逻辑推理，还是一种主体与存在之间的对话。AI没有主体性，也无法体验存在之谜带来的震撼。许多哲学问题之所以为问题，是因为我们有主观体验（例如“红色在我眼中是什么感觉”这种夸利亚问题），AI没有主观视角，就不会真正提出或理解这些问题。可以说，AI无法真正参与存在主义的思索；它充其量当个人类哲学知识的库存，帮助整理别人提出的理论，却不能像哲学家那样“从存在本身发问”。

艺术与灵性： 艺术创作有时被看作人类探索存在与超越的途径（如宗教艺术、形而上绘画）。这种艺术的灵感往往被艺术家认为来自某种“缪斯”或神秘体验。AI虽能创造艺术品，但它没有灵性来源。正如一位创作者所言：“算法无法感受真实生活的情感和思想冲击...它可以拼接模仿，但无法经历人类真实的对话和瞬间，然后把这些经历诉诸笔端” (What can't A.I. do? An essay for the existential crisis. -)。这强调了真实经历对于深层精神创造的重要性。AI没有经历，也就没有灵魂的沉淀。

可替代性分析： 存在性与精神性能力几乎是AI完全无法替代的。因为这里谈的不是具体任务，而是人类独有人文关怀和自我超越。如果硬要说AI在此有所作为，那就是AI可以成为人类探索这些问题的工具或陪伴。例如有人用GPT探讨哲学问题，它能列出各种观点帮助人类理清思路；又或者有人对机器人诉说心事，以此触发自我反省（“AI对镜”效应）。但本质上，这仍是人类自我对话，只是借助了AI当媒介。AI本身并没有在进行存在性的思考或体验。短期、中期、长期，AI都不可能有真正的存在焦虑或精神追求，除非有一天AI被证明出现了意识甚至情感，那将打开全新的讨论领域（AI的生存权利、AI宗教等）。就目前的科技和认识而言，存在主义思考和精神生活仍是人类不可替代的领域。这意味着在人类未来的发展中，我们应更加重视这些AI无法企及的精神价值，保持并发挥人类作为有意识、有情感、有意义追求的生命所独具的优势。

结论：人类独特能力的未来优势

综上所述，从认知到情感、从社交到体能、从创造力到道德和精神，各个维度的人类能力在面对AI时表现出不同程度的可替代性。AI已经并将继续在认知计算类任务上超越人类，在海量数据处理、精准计算、模式识别等方面发挥长处，部分替代人类的智力劳动。然而，人类能力的许多核心维度依然是AI难以企及的：

• 情感与共情： 人类真实情感和情感共鸣无法被算法复制。AI缺乏情感体验，因而难以替代人类的同理心和情绪智慧 (Empathic Artificial Intelligence: The Good and the Bad — BrainPost | Easy-to-read summaries of the latest neuroscience publications)。护理、心理支持、人际关怀等需要情感投入的领域，人类将保持独特优势。
• 社交理解与信任： 人类社交能力建立在丰富的非语言信号、文化理解和信任关系上。AI在跨文化交往、长期合作和信任构建上存在先天不足 (Mind Your AI Manners: The Bottom-Line Impact of Cultural Intelligence | by David Sweenor | Medium) (Frontiers | Developing trustworthy artificial intelligence: insights from research on interpersonal, human-automation, and human-AI trust)。领导力、谈判、教育等重人际互动的活动人类依然占据主导。
• 身体技巧与灵巧： 人体经过进化优化的运动技能和感知反馈整合，使我们在现实世界中自如行动。机器人要全面达到人类身体能力尚需长远突破 (Moravec's paradox - Wikipedia)。许多需要手眼协调和灵巧操作的职业（如手工艺、厨师、外科医生等的精妙部分）短期内不会被完全取代。
• 创造力与原创性： 虽然AI能产生大量内容，但人类原创的火花源自独特经历、直觉和审美情感 (Is art generated by artificial intelligence real art? — Harvard Gazette) (Is art generated by artificial intelligence real art? — Harvard Gazette)。真正突破性的创意往往来自人类对意义的追求和对世界的独特观察，这仍是人类创新的杀手锏。
• 道德价值与良知： 人类的道德选择扎根于良知和价值观。AI不具备自主道德意识，只能执行人给定的规则 (Can AI truly "feel"? Can it have intuition, conscience, or even ...)。社会需要人类来担纲伦理决策、价值引领和人文关怀，以确保科技向善运用。
• 自我意识与反思： 人类能够审视自我、学习改进，这是智慧成熟的标志。AI没有自我觉知，不会主动纠正自身盲点 (The Missing Framework: Self-Awareness and Metacognition in AI Systems | by Ianemmanuel Crueldad | Medium)。人类的自知之明与批判性反思在未来依然弥足珍贵。
• 存在关怀与精神追求： 对于生命意义的探索、对美好理想的信仰、对艺术和宗教的体悟，这些构成人类精神世界的要素是AI所不具备的，也是不可能被替代的。正如有人所说：“AI不是生命，它不会生活、不会体验真实的人生片段然后讲述出来” (What can't A.I. do? An essay for the existential crisis. -)。我们对世界的精神性联系仍将是人类独有的财富。

总而言之，人类在工具智能方面正迎来强大的AI助手，但在情感智能、社交智能、创造智能、道德智能和存在智能等方面依然握有未来的独特优势。展望未来，我们应该发挥AI所长来增强人类（augment humans），同时深耕那些AI所不能及的能力，保持人类在价值引领、创新突破和情感联系上的主体地位。这样，人类才能在AI时代中既受益于技术，又不失去自身的独特智慧和尊严。

降本增效的背景下，事故频发是必然的，都讲勿在浮沙筑高台，可惜处处是浮沙。正好有些鬼故事，可以给读者分享一下，帮助大家未来在做职业选择和技术决策的时候有个准确的参考。

长期主义

当前互联网公司的员工平均在职时间普遍在 2 年以内，按照各公司每年 20% 左右的晋升比例，意味着 80% 的人会经历晋升失败，这 80% 去参加晋升的人呢，大部分随后就会离职。当然现在行情不行了，也可能会跳不太动。

职业生涯的前几年，我也挺坚持长期主义，希望能够在一家公司深耕，能做出一些说出去能让业界同仁抖一抖的大系统。并且也用这些来教育那些刚毕业的同学们，希望他们坚持学习和思考那些难的东西，而不是浮于表面的八股文。当然，得到的回应是“面试又不考这个，我为什么要学”。

从结果上来讲，即使个人做到了长期坚持，但也没什么用。

当你用这些来证明自己的时候，你的面试官是个两三年跳一次槽的人，你讲的东西他未必听得懂。为了照顾他的情绪，你往简单了讲，别人大概就觉得“就这”？给你扣上个技术深度不够的帽子来压薪资。

这个世界，有些事情明明大多数人做不到，但是你做到了，他就会觉得很简单。所以那些坚持者往往还不如那些投机者赚得多。反过头来还要被弱鸡评头论足。

事故

我个人其实很喜欢事故，从事技术工种，事故对于工程师来说是很好的学习机会，对于个人来说，事故也是锻炼你的辩证思维的极好的机会。

可惜事故在公司里却都是拿来批斗他人的工具。就事论事在这个圈子里已经变得如此之难，以至于每次有事故，复盘会的目的都是把事故关联方批倒批臭，给自己的职业发展和地盘游戏争夺更多空间。

在大公司工作时，常年莫名其妙的复盘时常让人觉得我们这个行业为什么变成了这样，想要做技术创新和业务创新，至少要鼓励一定程度的失败，再通过失败来找到改进的方向。就像最近 spacex 发射火箭后英文媒体都说成功，而中文媒体都说是失败，就可以看出这种微秒的差异，非常有意思。

这是文化问题吗，我也不知道。

现在很多纯技术人员也被乱七八糟的价值观污染，连基本的就事论事都做不到，拿着给一线销售洗脑的价值观大做文章，多么可笑，一起开复盘会的时候大片的时间在强调价值观，心诚了系统就稳了？

我们每次上线都去烧香拜佛好了，还做啥保障。

预防

我们可以做很多事情来预防事故的发生，但即使做了，也没有用，因为一个商业机构，不可能对没有在自己身上发生过的事情提起重视。

比如支付宝的光纤被挖断了，才有了后来的各种断网演练。其它没有被迫断过网的公司会这么做么？未必吧。直到同样的故障降临到他们头上才行。

死到临头方知悔，不见黄河不掉泪。

互联网公司的系统基本都是复杂的分布式系统，里面充满了各种奇奇怪怪的中间件，共同依赖，单点存储，流量瓶颈，低频崩溃路径。每一个都需要有更多的旁路系统去保证在异常来临时不出问题。这和建大坝差不多，如果一直没碰到洪水，那就是劳民伤财；如果碰到了，那就是功在千秋。但你可能活不到洪水来的那一天，就被人送上断头台了。

哪怕公司里专门摆一个业务稳定性团队来当领导的安慰剂，你也会发现因为公司的晋升制度安排问题，他们更喜欢挑选那些看起来特别底层的事情，而不是对稳定性本身最有益的事情来做。

这个是制度问题。

分配

盛极必衰在互联网公司同样适用，公司做大了，大多数既得利益群体都丧失了学习动力。在某公司曾经见过 x9 的业务规划给 x8 做，x8 再给 x7 做，最后变成了高级工程师在给整个公司做战略规划的奇观。

后来发现这还不是个例，丧失了劳动能力的高层霸占着岗位不退休，一线工程师的创新和工作成功只不过是上级 ppt 上的一行字。

最好的解决方案还是企业出钱，让这些老而僵化的人提前退场，哪怕他们的退休金让企业承包了，也比赖在岗位上阻碍别人做事强多了。

最近的大事故还流传出了一些企业内部高管对于一线员工的斥责奇文，看起来哪怕再务实的人，一旦脱实向虚，他也该退休了。我们讲得现实一点，公司拿这些不做事的高管的钱，再去招五个稳定性工程师，能得到的效果也比他在那里放屁强。

某个公司的入职大会上，听着一个创始人讲他和姐妹的追剧故事的时候，我们也有类似的感想，让她退休吧，真心的。

实习生

你可能不知道，你觉得可能可靠的云服务，后面就是一些实习生。

当你上云的时候，你以为和人家 xx 集团用的是同款，结果跑了一段时间，才发现自己用的是实习生定制特供款。

即使是云服务，也是要讲究性价比的，一年收入 100w，他最多也就安排两个 p6 工程师，何况公司要赚钱，还是放三个实习生能赚钱。

公司内部也有类似的悖论，公司里的核心业务需要 infra/云支持，核心业务是金主爸爸，都是要优先服务好的。而 infra 自己的 infra 需求，基本都是没人接的。

再说明白一点，可能监控系统自己的监控需求，还不如业务的监控做的好。也是找个实习生糊弄一下了事。

你去看看那些大公司抛出来的 xx sdk，是不是很多都是实习生写的？

尾气

互联网的发展显然已经进入了尾声，新入行的人能分到的只剩汤了。一边吸着尾气，可能还要被那些不干活，不思考，不退休，站着说话不腰痛的人指责没有奋斗精神。对于后来者是不公平的。

作为一个过来人，我的建议也只有两条：

• 无论什么时候，都选择给你钱最多的地方；
• 先有钱，再去谈理想和长期主义；
• 软件架构里有个概念叫 Leave Options Open，你的职业和人生选择也应如此；

希望大家都有美好的未来。

对于我们这些穷又不敢上杠杆的人来说，还是把钱放在货币基金里比较稳妥(主要是不会亏钱)。

出了国才知道，国外的银行 APP 体验是真的差。。可能是这些银行的研发都不如国内卷(笑

前段时间和同事随便聊了聊，完全不投资的同事甚至把钱都放在了银行余额里，这些国外的银行 APP 并不会给你把余额自动转到余额宝这样的货币基金理财里(国内这些年的发展还是要多亏了当初的支付宝)，大多数活期利率 0.01%。

即使想要买点定存还得专门去开个 fixed deposit 账户。。为了开个定存账户可能还得去银行网点，相比国内的银行真是体验被吊打。

如图是新加坡最大国有银行在 APP 开定存账户报错，让你去网点。对于国内干啥都是在线上的老宅男来说，来了 sg 干点啥都得去网点和客户经理尴聊，实在是不太适应。

在国内的时候听过的那些如雷贯耳的跨国银行，比如 hsbc、citibank，想要买个简单的货币基金也比较麻烦。要在 APP 上填一堆表格，才能从一堆基金里找出来那个风险比较低的基金，比如下面这些，第一个 fullerton cash fund 就是货币基金，其它的不是：

我也看到有一个同事 10w sgd 全在 hsbc 的活期里，相比买了货币基金一年损失 3800 sgd 。

后来我帮他点了半天，才找到 hsbc 的货币基金入口在 wealth -> unit trust 里，还得自己根据介绍仔细分辨，才能判断出是货币基金还是债券基金还是股票基金。仔细一想，支付宝/国内银行这些操作其实是帮完全不懂金融的人屏蔽了银行的这些结构理财的复杂性，让普通人不用太动脑子就能享受活期和定期差不多的利率，算是一种形式的金融创新，想在国外的银行 APP 上买个货币基金可真是难。

前后研究了几个月，大致搞明白了在 sg 各家银行买货币基金的流程，大多数体验都不咋地。目前我觉得最简单的就是直接把钱扭到券商里买，比如 moomoo：

目前是 3.88% 的利率，在 5w sgd 范畴内是最好的选择。

如果你把 moomoo 切换成英文版，会发现这个和 hsbc 那张图的 fullerton 是同一家供应商~

欢迎大家用我的注册链接来注册 moomoo，新注册用户入金 1w 就有羊毛可薅~：

Moomoo - Invest Smarter with One Super App

Invest Smarter with moomoo! Enjoy up to S$660* welcome rewards and $0* Commission for US & SG market.

Smart Investment Platform

有价值的知识

这个话题是最近在一个好友群里的问题，从业时间各异的人对这个问题的答案区别还是挺大的。

把问题再明确一些，什么样的知识能在资本市场上让你估个好身价，很多技术一根筋的同学认为底层知识是答案。然而并不是，我和国内一些做编译器以及 os 内核的人聊过天，底层知识在当前互联网行业岗位需求比较少，当前流行的 infra 都逐渐开源化，特别是 k8s 导致早些年各厂自建的调度相形见绌，纷纷切换到社区版本，再在社区版本上移植 borg 的内容，所以 invented in China 渐渐变成了 copy to China，copy 的人力需求并没有那么多，基础设施无法容纳大量的就业岗位，这几年基础设施工程师们的境遇也并没有那么好。

如果觉得国内的 case 没有代表性，可以去看看 envoy 作者当初在 twitter 开发 envoy 的心酸历程，即使现在 envoy 在互联网都快变成了标准网关之一了。在这一波硅谷大裁员的影响下，也有不少基础设施工程师失去了工作。大家仔细一盘算，infra 的裁员比例好像总比业务部门多那么一些。

这些问题在 IDDD 里早有答案，supporting domain 往往是公司的 cost center，作为商业公司的老板，肯定不喜欢 cost center，跟技术人员的喜好无关。

说回到技术，具有稀缺性的技术才是技术人员的真正价值，比如你在一家金融相关的公司做 risk control 业务，市面上突然涌现了大量的 fintech 创业公司，这个时候就是你实现身价跃迁的最好时机。相关的领域知识里，有 80% 是业务知识，10% 是架构知识，剩下 10% 才是那些细节的技术知识。

当然，这种稀缺会随着时间的流逝和公司之间的人员流动逐渐被稀释。因为技术人都比较单纯且乐于分享，一旦某个领域的知识被人系统地进行了总结成书，那么这些知识便不再稀缺。一方面，技术类书籍的作者成就了自己；另一方面，技术的传播则会拉低相关领域人才的稀缺度。一旦有据可循，知识就会瞬间失去他的稀缺性，因为我们这个行业最不缺少的就是学习能力啦。

如果你当前从事的领域，所用到的知识在互联网难以检索，这可能就是未来一小段时间内你的核心竞争力。

你需要慎重衡量是否要将这些作为公开材料分享出来。

加班文化

互联网的从业环境在最近这十年，肉眼可见地滑坡了，这并不是错觉，在我们上学那会儿，加班还只是少数公司的文化，而现在，大陆的互联网公司几乎没有不加班的。

这十多年来，我也经历了十多家公司。不少大厂出来的中层 ld 会将加班视为某种形式的政治正确，按时下班就是工作态度不端正，这与圈子内弥漫的某种“价值观”是分不开的。大多数业务进入成熟期，公司内的人在做什么对公司数据的影响都有限，即使什么都不做，公司的自然增长可能也是那么多。但人才市场上对于 manager 的价值衡量往往基于可量化的指标，例如典型的面试问题“你的团队有多少人”，这导致大多基层技术 ld 放弃了把重心放在技术和业务上，因为性价比太低，而是把“一哭二闹三要”作为职业发展的信条和上升的快车道。

我们把这些中间的 ld 们拉到人才市场上，去掉管理人数这个标签，再去衡量他们的基础能力，很多人都是不合格的，这些人甚至没有被做过基础的项目管理培训，甚至也没有自己主动学习过。也不知道什么是一个大项目的关键路径，甚至有些业务的技术 leader，连什么是 mvp 都不知道就可以直接上岗。但这并不妨碍他们在某种程度上混得风生水起，因为大多数人也就懂一句“极限施压”。只要施压，我们开发流程里能省的环节都可以省，比如单测要花的时间比较长？那就别写了。回归时间比较长？那就别回归了。写设计文档要花时间？那就别写了。一套 happy path 代码写到底，在极短时间内就可以交付项目。极短时间内就体现出了 ld 的 leadership。要是上线以后有 bug，那就更好了，半夜起来修呗~ 这也是老板的 leadership 的一种体现，大家先抄近路，再花更多的时间来补课，没关系，没有人关注项目的维护成本的。因为当事人早就因为 leadership 杰出晋升啦！

关于工程师文化

这几年几乎听不到哪家公司在说自己内部有浓厚的工程师文化了，除了少数 infra 开源软件公司。对于从业人员来说，这是一种悲哀。大多数工程师对于企业也不再像曾经那样有归属感，只是作为雇佣兵和工具人一边领赏金一边工作而已。但工程师文化是如此可贵，我不想要轻易丢掉它。所以还是要去阅读先进生产力的 engineering 实践，学习别人怎么样去考虑各种方面的 scale，无论是让重复的工作自动化，还是让人员的规模能和生产力达成同步的线性增长。如果对工程师有足够的信任，他们自然也会回报以足够的效率。如果对将人工具化，指标化，那么得到的也就只有工具和指标而全无效率。

其实在市面上有很多不错的例子，比如同样的业务，有些公司只需要 5000 人，而有些公司则需要 10 w 人，两家公司的 GMV 并没有 20 倍级的差距。而滴滴当年和美团竞争的故事，我在之前的文章里也写过了。

AI 浪潮之下，人的思考渐渐连机器都比不上，这些一直存在脑子里的知识应该都放出来也没什么关系了。

我在 2019 年在某司从业期间，曾经写过一篇《中台的末路》，从一线工程师和架构师的视角来思考当前大公司内部的中台架构到底会碰到什么样的问题。在我离职之前，有一些问题已经有了明确的答案。有一些还没有，后续加入猫厂下公司也是为了验证我的困惑，在另外一个环境下看是否已经有人铺好前路，搭好路灯，为后来人指出了方向。

业界一般把中台分为两个类型，数据中台和业务中台，前者主要指大数据、实时计算的技术栈封装，以及公司内的数据资产沉淀、管理和治理。这其中的数据治理需要与公司的业务场景结合进行设计，但数据中台中 80% 的技术其实和业务本身关联性没有那么大，目前各家公司的数据中台建设往往也都比较成功，将普通数据研发从复杂的数据基础设施复杂性中解放了出来，在《One SQL to Rule Them All》论文出现之后，经过了两三年的发展，实时计算在 90% 的场景不需要去了解底层技术栈了(优化除外)。对于数据平台的用户来说，研发就是写 SQL 和 udf 而已。

业务中台就不一样了，这也是这些大公司混日子的架构师们有意云遮雾罩，含糊其辞，导致后来人要浪费无数时间去研究甚至走弯路的领域。如果他们讲的太清楚，咨询费就不能要太多了吧。

在某司工作期间，我们实际建设的大多数中台系统就只是公用 API 而已，只用简单的 OOP 知识就可以拆分出来，连 DDD 都不需要。

近距离在猫厂内部观察之后，业务中台其实并不需要那么多名词和概念就可以说清楚，本质就是可视化工作流，工作流编辑平台和无处不在的规则引擎。

这些公司的架构师经常会把他们的中台提供的产品叫作“商业能力”，名词分量真是给够了。

商业能力本质上只是固化的流程和扩展点而已，以下图为例：

左边表示流程，右边表示扩展点。因为猫厂业务中台用 java 实现，工作流本身有不少现成的工具，右边的扩展点即提供给用户复用时的修改点，可以通过简单的注解来 override 掉原函数，替换为自己的实现。比如你的业务要复用中台的组件，但商品校验这里有一些你自己的定制逻辑，那么你只需要：

@injectpoint("商品校验")
public bool checkProduct() {
	// 你的逻辑
}

并不是很困难，对吧。有了这套系统之后，整个平台的能力，和不同业务场景(比如tmal、taobao)分别对哪些扩展点做了修改，可以直接通过代码扫描，汇总到平台上来，即使是产品经理和不写代码的老板也能看得见摸得着电商的流程到底都是在做什么。

业务系统本身就是流程，商业能力就是固化的流程，再将这些商业能力即固化流程组合起来，就是一个子领域，子领域再向上组合成为业务领域，最终成为完整的电商业务中台，逻辑上并不难理解，细节就不展开了。。。感兴趣的可以来找我私聊。

当然，我们也不能否认电商中台的业务复杂性，我所能看到的已经是划分好的领域和抽象完毕的结果，当初能够把这些电商业务划分清楚，拆分合适，并最终将其流程全部可视化的人水平还是很高的。

但从技术上来讲，基于工作流、扩展点的系统并不是近些年才有的，我之前写的 《righting software》一书笔记里也总结过，那位作者告诉我们业务本身就是工作流和局部规则，所以即使包装得再天花乱坠，从技术角度来看，这也不是什么创新。客观来讲，这样的业务技术形态确实在国内互联网公司是顶尖的，比其它连一个后台管理系统都设计不明白的所谓互联网大厂强多了。

但是我不知道某些技术公众号为什么天天在那吹这是创新，还扼腕这样好的技术既然没有作为我国互联网技术创新输出到国外。那我们来看看别人的总结：

上面这张图讲的是 mecha 架构，这些 dapr 的作者对于未来后端应用的畅想，工作流和应用状态管理是左边 state 管理的一部分，只要你能弄清目前业务中台的技术到底是在干什么事情，那孰优孰劣也自然能做到心里有数。

但是为什么看起来很合理的系统，最终却走上了末路了呢？

其实本质上还是中台本身做得不够好，我们可以从另一位曾经在猫厂业务部门工作过的人的文章中窥见一二：

业务中台的困境、及可能的解

阿里的业务中台建设已经有一段时间了，可为什么我总觉得旁边有朵小乌云，哪里不对劲呢？

微信公众平台从码农到工匠

为了服务业务的复杂性，这套中台做得越来越复杂，对于新人来说，想要熟悉他的流程和开发就要花上不少时间，因为本身商业能力是固化的流程，新接入的初创业务只是希望能复用某一个非常小的节点，却要拉家带口把全中台都接进来，坊间曾经传言考拉被收购之后接中台接了整整一年。而 lazada 被收购之后加班加点也花了半年时间才完成了接入和重构。

但是对于工程师红利充裕的地区来说，去复用一套极复杂的系统，还不如让大家 996 两个月重新写一套来得更快。

在前面我们说，中台架构师吹嘘的“商业能力”是固化的流程，这个业务中台发展赖以维系的前提，在 pdd 崛起之后基本就被完全打破了，我们和几个朋友曾经一起讨论过，为什么这么大一个公司，人员又如此冗余，连一个 pdd 的流程都做不出来？

后来发现也不用我们操心了，淘bao特价版不再要求接入之前的业务中台了。

尾声：也许有人要问，那连猫厂自己都否定了曾经的中台战略，对于小公司来说，还有必要参考吗？

别太看得起自己吧，小公司的中台也就只是人力外包资源池而已。

技术和工具日新月异，最近每一周感觉技术世界都在发生巨变，而还在那些传统岗位上的我们的工作，半年后，一年后，两年后，又有多少价值呢？

虽然有些写代码的程序员还在嘴硬，坚持自己所做的事情做到“资深”，就不会被 ai 取代，可能还是太高估这个行业大多数人日常工作的含金量了。我个人认为不出两年，it 行业就会发生巨变。后面还会有具体的分享。

从目前很多“大佬”的动作来看，大家都想在这一波浪潮中不落于人后，加入 aigc 创业的大军中去，不管他们的目的是沽名钓誉，还是真的想做点事情推动人类的生产力进步，还是要祝福他们。

周末闲来无事，在曾经一个 Go 圈子里专攻面试的群里看到有人分享了这么个案例：

嗯，放在两周前看到我会比较震撼。

放在现在嘛，我动了动歪脑筋，既然 chatgpt 可以生成面试题，那么 chatgpt 自然也就可以生成面试题的答案。在 ai 浪潮的冲击下，我们传统的面试可以轻易被颠覆。具体要怎么实现呢？

我们先来看一个案例：

Samantha.x64

The first Web3 bot creator platform, Join DC and follow up to get whitelisted: https://discord.gg/RnqnZzNmBE

Telegram

上面这个是一个用 ai 技术实现的聊天机器人，可以做到识别用户语言，然后把文字发给 chatgpt，然后把 chatgpt 返回的内容用 tts 重新转回语言发给用户。

基本的功能是帮助我们来练习口语，能够避免和没什么共同话题的外教尬聊的场景。基本的技术是 speech recognition，text to speech，然后就是简单的 chatgpt 的 api。

chatgpt 的 api 自不用说，这里的 speech recognition 和 text to speech 目前也有基于机器学习的新成果。

speech recognition 使用 openai 开源的 https://github.com/openai/whisper，whisper 可以实现多语言的语音识别，我实际实验下来，英文的识别率还是挺准的。

然后是 text to speech，mozilla 开源的 tts 工具 https://github.com/mozilla/tts，效果和真人说话已经没有太大的差别了。

当然，我们只是为了给面试官一点震撼，这里 tts 还用不上。只要有 speech recognition 和 chatgpt 的接口就够了。

这意味着什么呢？意味着当我们参加远程视频面试时，可以通过录音将面试官的问题识别为文字，并将文字发给 chatgpt 自动生成答案。

听起来是不是有点小可怕？

我在很早之前其实也就说过，能够从互联网上检索到的知识，和那些已经被标准化的知识(比如 inf 领域的 cncf)对我们来说没有任何意义，因为使用正儿八经的技术搜索引擎对于中文区的程序员稍微有些门槛，所以我们会把那些八股文当回事，但现如今，chatgpt 这种 ai 工具让人与信息的距离进一步缩短，传统的生产关系没有跟上技术的发展，就会变成很可怕的事情。

按照前述理论，任何人都可以低门槛做出一个线上面试作弊机器人。

好好想想，面试到底该问什么问题吧。

去年的这个时候，IT 圈哀鸿遍野，吐槽技术红利消耗殆尽，所有公司都失去了新的增长点，程序员红利到头了。

今年的这个时候，程序员的好日子确实进入倒计时了，只不过不像当初做预言的人想的那样，连他们自己的末日也在倒计时了。

中国的互联网从业者并没有把 AI 当回事，这几年来对 AI 的看法是这种基于统计和传统神经网络的技术不足为惧，因为硬件的发展让老树发了一点新芽，套上强大的核弹厂芯片加一些修修补补的算法，能帮这些批着科技外皮的牛皮癣广告公司卖出更多的广告，能让信息茧房里的人看到更多他们喜欢的信息，奶头乐吸得不亦乐乎，让整个网民群体娱乐到死，普通人失去了研究的耐心和学习发展的能力，商业公司赚到了更多的钱，着实是 win-win 麻了。

2022 年下半年，Github 的 CoPilot，OpenAI 的 ChatGPT 和开源的 Stable Diffusion 把所有人对 AI 的认知颠覆了个底朝天，因为与传统的认识出入过大，所以即使你不想去了解，在微信群里也或多或少地看到了别人是怎么去各种方式调戏 ChatGPT 的了。

最近听到有熟人的朋友看到 AI 绘图的发展，放弃本行去考公，还是给了我一点小小的转行震撼，所以我深入地研究了一下 Stable Diffusion 相关的这些模型、工具和服务。在实验完之后，我也对相关领域的从业者未来确实充满了悲观的预期。

比如最近非常流行的 midjourney，对于没有任何调参数基础的人来说，只需要一个单词，AI 就可以给你出图。

比如下面是我在 midjourney 的服务里输入 medusa：

说实话，这几张随机出来的图已经超越我的认知了，如果用传统流程来绘制这么一张图可能要花上艺术家几天甚至一个月的时间，而 midjourney 给我返回四张图只花了不到 10s(哦不好意思，我付费了)。这对于很多做美术行业的人来说绝对是毁灭性的打击，这个行业在未来的一两年内可能就会被颠覆。

除了 midjourney 之外，有一家叫 novelai 的公司，就是早年的 ai 写小说的公司也有自己的图片生成服务，偏二次元风格：

也是基本不太需要改参数，就能生成基本令人满意的插画。

当前这些模型生成出来的图片的版权名义上归属于模型用户，然而不同用户使用相同的模型和相同的参数能够生成同样的图片，所以这里还是有一些模糊地带，技术发展太快，法律也还没有跟得上。

除了美术以外，现在 AI 的作文和作曲也在快速发展，网络文学的作者们自从有了 ChatGPT 之后，纷纷从之前的周更作者变成了日更，甚至可以做到小时更。未来我们所看到的大量文字创作内容，大概率可能至少也有一半是出自 AI 之手，人们渐渐像被 AI 喂食一般，可能连自主意识都会慢慢消失，那些反乌托邦里描述的超现实场景可能慢慢也要变成现实了。

为什么我们要以艺术领域作为开头？因为当初知识精英们对于普通人的承诺，当工业革命发生时，机器取代劳动者，劳动人民可以从体力劳动中解放出来，去从事那些需要与人打交道或艺术创作类的更高级的活动。

然而这条后路由技术率先为我们堵死了，连退路都没有的我们本行又怎么样呢？

Github 的 CoPilot 可以直接写注释出代码，现在是简单的写一行：

// leetcode 1024

CoPilot 就可以帮我们写出题解，简单地写一行数据结构的描述，AI 就能帮我们把代码补全。

尽管现在 AI 生成的代码还是会偶尔有一些问题，但只要能人工辅助，那有问题的结果被校准也只是时间问题。

对于工程师来说，长期来说最大的威胁就是 AI，而且看起来这个 AI 取代低阶岗位的过程是不可逆的。我们再向前看一看，之前某家公司想要用无人机取代外卖员来送外卖，据说无人机整个生命周期内能配送的订单以万计，考虑到其本身的造价和折损，最终平均到一笔订单上的成本是 1 元/单，而我们知道外卖员的配送费是不可能这么便宜的，我们在微信群里经常能看到两个年轻人互相调侃的表情：

你要想想，无人机的配送成本比这两张图上的还要低 60% 以上，所以即使你本行失业了，未来连这条后路也是没有的。

之前在国内工作的时候，我和朋友在 youtube 上看到过 vice 2019 年做的采访，标题是 The Future of Work，里面涉及到了很多当前蓝领、白领养家的饭碗，在新的机械和 AI 革命来临的时候，基本没有生存的可能：

当卡车司机(蓝领)和法律文书审核员(白领)发现他们的工作是如此容易就被 AI 取代的时候，他们落寞的表情我至今都忘记不了。

那时候看来，这些可能只是这些创业公司为了拉投资造出来的噱头，自动驾驶和一些 nlp 的 AI 在前几年也确实闹出过一些笑话，只是没想到，真正的奇点来的如此之快。

只要我们的工作遵从某种模式，无论这种模式是简单，还是复杂，未来都会被那些能更快学习模式的 AI 所取代。

风暴已近，只是所有人都没有准备好。

无论你是一个艺术家，作曲家，诗人，外卖员，流水线作业者，程序员，产品经理，法律文书起草人，客服人员，还有那些不包括在这些分类里的模式化职业，在未来的很短的时间内，你所引以为豪的，都会在 AI 发展的摧枯拉朽之下轰然倒塌。

winter is coming。

之前在这篇 subset 限制连接数量 里，简单总结了 SRE book 书里讲到的 subset 算法的基本原理和问题。

之前还在做 mesh 的时候，也曾经想把 subset 算法在公司内落地，无奈和同事一起分析了两个星期以后，认为 subset 的：

1. 需要 paas 给每个 container 分配连续 id，且在下线时需要自动补漏，目前 k8s 其实并没有这种策略，给每个服务都做成 stateful-set 也不现实
2. 发布时(公司内服务实例多的服务需要批量发布)会导致大量的连接 shuffle，进而导致服务的延迟变高

这两个问题对于很多服务，特别是涉及到公司核心链路的服务，本身就有严苛的 SLA 要求，如果因为 mesh 导致一发布就延迟上升，是不可接受的，所以难以落地。

最近 Google 在 acm queue 上发了一篇新文章：《Reinventing Backend Subsetting at Google》，详细地阐述了之前 SRE book 里写的那个 subset 算法的问题。

他们是在 Autopilot 这个项目落地的过程中遇到了阻力，这个叫 autopilot 的项目是帮业务模块自动做横向/纵向扩缩容的，对 subset 算法稍有了解的同学应该能想到，client 和 server 频繁的扩缩容会导致 subset 算法计算出的 subset 频繁发生变化，从而导致大量的连接 shuffle(在文章中里叫 connection churn)。

在 autopilot 落地之前，subset 算法在 Google 内部已经跑了 10 年了，但是因为连接 shuffle 会导致：

• 在途请求发生错误、延迟上升
• 因为大量连接重建，导致服务的 CPU/内存使用上升(好理解，因为 dial 的时候要分配资源)
• tcp slow start 会影响新创建的连接上的吞吐量，从而影响服务整体性能
• 连接缓存要承受更大压力

对于服务的影响随服务本身的性质不同而不同，有些延迟敏感的服务会导致服务的 SLO 受到影响，从而让 autopilot 的落地受阻。

这些问题在做 mesh 的时候我自己想了两个星期没有想到靠谱的解决方案，就放弃了，Google 的工程师则没有放弃。

根据 Hyrum 法则，只要能被观测到的行为都会被依赖，所以他们先是分析了一下以前的算法会有哪些行为，这次详细地介绍了当初他们怎么推导出的 deterministic subset。先是讲了 random subsetting 的问题：

显然随机化的 subset 算法会导致连接不均匀，假设每一个请求的成本都相同，且每个连接上的请求速差不多，那么 server 端的这些连接数大致上和负载的关系就是正比关系。

后来 Google 想出了 deterministic subset 算法，因为之前在 subset 限制连接数量 里写过，这里就不在赘述了。

但是 deterministic subset 这个算法也有问题，在 client 或者 server 端的实例数量发生变化的时候，会导致大量的连接迁移和重建，比如下面这个例子：

后端的 size 从 10 变成了 11，就导致大量的 client 端的连接发生了迁移，上图中标红的是会发生变化的连接，不再使用的连接要断掉，新加入 subset 的 server 端要建新连接，可以看到 client 2 和 client 3 会有大量的连接重建。client 3 受的影响最严重，所有连接马上都不能用了。

为了解决这些问题，需要能够找到一种新算法，能解决之前的所有问题，要满足下面这些要求：

• 良好的连接平衡度
• subset 的 diversity 不能给一个 client 分配一堆连续的 server，要不批量发布的时候直接就跪了)
• 不能因为 client 端的重启导致大量连接 shuffle
• server 端重启时，对 client 端连接的 shuffle 影响应该尽量小，至少也是按后端数量来对前端产生影响(比如后端同一时刻重启了一半实例，那每个 client 端影响到一半的连接是可以接受的)
• subset 大小发生变化的时候，不能有大量连接 shuffle
• 更好的 subset 影响度

接下来文章就讲了工程师们重点考察的一些可能的算法。

consistent subsetting

然后 Google 的工程师先是想到了是否能用 consistent hashing 类似的搞法，做一个 consistent subset：

client 和 server 端都是按 consistent hash 的随机算法分布在环上的，蓝色的是 client，黄色的是 server。

然而这个算法并不会有较好的连接平衡度(server 端连接分布不均匀)和连接区分度(可能会把连续的实例分配给同一个 client)。

比如这张图里的 client 是蓝色的 0，它顺着 consistent subset 的环顺时针找，会用 3 和 2 两个连续的后端。这个不符合前面提出的 subset diversity。

Ringsteady subsetting

因为后端节点的分布要尽可能让后端变化时，前端和后端建立的连接也成相同比例变化，所以 Google 工程师选用了一个特殊的分布序列：binary van der Corput sequence。

读者可以试着在圆环上摆一下每个节点，应该马上就能意识到这个序列的神奇之处了。

可以用下面的算法计算出相应的位置的值：

double corput(int n, int base){
    double q=0, bk=(double)1/base;

    while (n > 0) {
      q += (n % base)*bk;
      n /= base;
      bk /= base;
    }

    return q;
}

这个算法能保证较好的 subset diversity，subset spread，并且能均匀地将后端和前端节点分布在圆环上。

但它本身也有一些问题：

Frontend and backend scaling

client 端扩容叫 frontend scaling，server 端扩容叫 backend scaling。

ringsteady subsetting 的连接平衡度较差，比如下图的右边，当 client 的数量超过了 server 时，util 值没有趋近于理想值。

这和下图中的 determinisitic subsetting 有明显差距：

这里选用的低差异的序列，即前文的 binary van der Corput sequence 导致 client 和 server 在环上离得较近，而并不是按照距离来均匀分布。

如果把 server 和 client 端的数量一起纳入排序来在圆环上来做分布的话又会带来很多额外的困难，这里不再赘述了，感兴趣的同学可以去精读原文。

Rocksteadier subsetting

ringsteady subsetting 基本上能解决所有后端扩容的问题了，但是这个算法的 subset diversity 并不是很优秀，因为本质上它是 consistent subset 的一个变种，Google 的工程师还调研了一个叫 Rendezvous Hashing 的算法，不过结果也并不是很理想，因为没法很好得保证连接的平衡。

所以最后工程师想出了灵活组合 Ringsteady 来解决所有问题的算法，其流程如下：

• 将前后端所有实例进行分组：

不足的组需要 padding，在表格中是 56-59。

然后将 server 端的分组内的实例进行 shuffle，这里需要保证每个 client 组内看到的 shuffle 结果是相同的，所以可以用 frontend 的 lot id 来作为伪随机算法的输入种子：

然后将 server 的 LOT 也就是组按照 ringsteady 的排序方式进行打乱：

接着将同一组内的 client 也按照 ringsteady 的方式进行打乱：

在上图中，我们每个 client 会向 server 端建 10 条连接，红色的表示的是 10 号 client 向 server 发起的连接，碰到之前 padding 进来的 server 实例 id 要跳过。绿色的表示的是 12 号 client 建立的连接，蓝色的表示的是 11 号 client 建立的连接。

到这里这个算法就结束了，在这篇文章里的分组大小 L 选择的是 10，增加分组大小的话可以增强算法的 subset diversity，但可能会导致连接的不均衡。幸运的是，一般比较小的连接数，比如 10 是能够提供较好的连接均匀度和 subset diversity 的。

这个算法部署到生产之后，再也没有发生过发布时大量的 connection shuffle，autopilot 也正常地铺开了，之后工程师们把这个 rocksteadier subsetting 作为默认的 subset 算法进行了上线，大多数业务的 owner 方对此也没有感知。

这个算法的思考过程困难重重，但最终的实现并不是特别困难，如果你的生产环境已经能够给所有服务分配连续 id 了，那么不妨现在就可以开始尝试了~

分配连续 id 是算法能成立的前提，别忘了。

这个算法可以在哪些场景落地

在文章开头我已经说过了，在 mesh 场景可以很好的落地。大多数 RPC 的连接建立过程也可以落地，对于 Go 这种网络编程模型，连接数对系统本身的内存占用影响会很大，选用文中的算法可以极大地节省长连接后端微服务的资源占用。

明年应该就能看到某些公司出来吹了。