2026年2月

去年 Leader 让大干快上了不少 AI 代码工程，年后开工需求又增加了不少，话说这些 AI 产生的项目（含 AI 量超过 50%）要怎么维护？

让人去读 AI 的代码，再去增删改查，还不如让人重新写来的顺手，就是慢。

另外，就是让 AI 自己改，从以往的经验看，让 AI 维护需求更新代码，还不如让 AI 从头重写，从零开始写代码可能消耗的 tokens 比改需求绕圈圈烧的钱还少。

这么看下来，AI 做的项目都是一次性代码吗？

AI 搓的类 whmcs 管理系统 xinxitech.com
我就改了几个简单的脚本，剩下几乎都是 AI 搞的
用了几个 AI 工具 winsurf antigravity 淘宝还买了 2 个账号 总共花了 100 多
大家帮忙看看有什么问题没有，已经上线了，需要服务器也可以直接购买，即时交付

一月底在宁波的一个海鲜酒家吃饭，看到的挑食材的价格。
很新鲜，做的也很好。
去的是他家的最初的那家店。

How To Install phpMyAdmin on Ubuntu

phpMyAdmin 是一个优秀的 MySQL 数据库管理工具。它可以用来浏览、编辑、创建和删除数据表，您不需要 SSH 到远程或者在终端窗口来执行 SQL 查询和管理。

本文将向您展示如何在 Ubuntu 服务器上安装和设置 phpMyAdmin 工具。

Install Apache and PHP

假设你已经安装了 MySQL 服务器。因此，只需安装 phpMyAdmin 所需的其他包即可。

sudo apt install apache2 wget unzip 
sudo apt install php php-zip php-json php-mbstring php-mysql

安装完成后，启用并启动 Apache web 服务器。

sudo systemctl enable apache2 
sudo systemctl start apache2

Install phpMyAdmin

浏览官方下载页 获取最新的 phpMyAdmin 源文件，或者使用下面的命令下载到您的系统。下载完成后，提取存档文件并移动到合适的位置。

wget https://files.phpmyadmin.net/phpMyAdmin/5.2.0/phpMyAdmin-5.2.0-all-languages.zip 
unzip phpMyAdmin-5.2.0-all-languages.zip 
sudo mv phpMyAdmin-5.2.0-all-languages /usr/share/phpmyadmin

接下来，创建 tmp 目录并设置适当的权限，这是使其正常工作的必要步骤。

sudo mkdir /usr/share/phpmyadmin/tmp 
sudo chown -R www-data:www-data /usr/share/phpmyadmin 
sudo chmod 777 /usr/share/phpmyadmin/tmp

Configure phpMyAdmin

现在，您需要配置 web 服务器，以便在网络上为 phpMyAdmin 提供服务。为 phpMyAdmin 创建一个 Apache 配置文件。

sudo vim /etc/apache2/conf-available/phpmyadmin.conf

将以下内容添加到 phpmyadmin.conf 配置文件中：

Alias /phpmyadmin /usr/share/phpmyadmin
Alias /phpMyAdmin /usr/share/phpmyadmin

<Directory /usr/share/phpmyadmin/>
    AddDefaultCharset UTF-8
    <IfModule mod_authz_core.c>
        <RequireAny>
            Require all granted
        </RequireAny>
    </IfModule>
</Directory>

<Directory /usr/share/phpmyadmin/setup/>
    <IfModule mod_authz_core.c>
        <RequireAny>
            Require all granted
        </RequireAny>
    </IfModule>
</Directory>

按 ESC 键，然后输入:wq，然后按 Enter 键，保存文件并退出。

完成所有更改后，启动 Apache 服务以重新加载所有设置。

sudo a2enconf phpmyadmin 
sudo systemctl restart apache2

Adjusting FirewallD

如果系统启用了防火墙，则需要放行 web 服务器端口。

sudo firewall-cmd --permanent --add-service=http 
sudo firewall-cmd --reload

Access phpMyAdmin

现在使用服务器 IP 地址或域名访问 phpMyAdmin 服务。

http://{your-domain.com}/phpmyadmin

phpMyAdmin Login Screen

登录后，你将看到如下画面：

phpMyAdmin Dashboard

我的开源项目

酷瓜云课堂-开源知识付费解决方案

梦见我的 app 一天新增 20 多个用户了，醒来第一件事就是打开后台刷新数据
——现实还是很冰冷，但我做的 Fluoro （荧光） 确实在慢慢发光。

它是一个专为 AI 图像创作者准备的小社区，分享作品、整理 Prompt 、寻找灵感，不卷流量、不追风口，只让创作本身被看见。如果你也在深夜反复调参数、为一张图较真细节，或许可以来 Fluoro 看看，也许下一个“新增 20+”的那天，就从你开始。

没听各位大佬的忠告啊，想到是大学同学让帮忙就没有埋雷，结果被坑了。
大致流程就是技术入股->免费劳动帮程序从 php go ，迁移到 java ，期间给过几次 3 千生活费，然后去年威逼/利诱离职跟着干我看他们对技术没那么尊重，而且行业我也不看好（房地产购房小程序），就拿了几万退股，后面知道那套程序卖了 90 多，我说那有没有我的份，从合同上来看，确实是没我的份，后悔没埋雷啊。
打开电脑找资料的时候，发现里面还有数据库的连接还能连上......应该是他们交接了没改密码，或者是我当初建的查询账户，总之我资料全交了，有没有合法的方法要回我的收入，还有合同里面应该备注程序之类的智慧知识产权不能专卖，坑啊，大家引以为戒。

“我们会开始看到 ‘软件工程师’这个头衔慢慢消失。可能会变成 builder、product manager，或者头衔还保留，但只是一个遗留符号。

因为大家做的工作不再只是写代码：软件工程师还会写 spec、还会跟用户沟通。”

放出这话的，正是 Claude Code的创始人 Boris Cherny。

他最近在 Y Combinator的一场圆桌访谈中，一人对阵四位 YC 高管，几乎句句都带着点“重锤感”。

在他看来，编程正在被“解决”。在 Anthropic，很多人已经 70%–100%用 Claude 写代码，IDE 的存在感正在下降。写代码这件事，正在从“核心能力”变成“默认能力”。

而另一边，模型能力会指数增长，今天的“勉强可用”，六个月后可能原生支持，如果只围绕当前模型做 PMF，很快会被下一代能力抹平：

“在 Anthropic，我们一直有一个核心理念：我们不是为‘今天的模型’做产品，而是为‘六个月后的模型’做产品。”

这，也是他给所有 LLM 创始人的一条建议。

本次访谈，除了 Boris 本人外，其余几位包括：YC 总裁兼 CEO Garry Tan、合伙人 Harj Taggar、Diana Hu，以及 Jared Friedman。

YC 总裁兼 CEO Garry 开场就说了句：“谢谢你做了 Claude Code。它让我连续三周没睡好。”

这不纯是客套。Claude Code 不仅对外很火，对内也像一台“超级引擎”，自其推出后，Anthropic 的人均工程产出提升了 150%。

用 Boris 的话来说，就是：

“我以前在 Meta 负责代码质量，也负责跨多个产品线的代码库质量。当时我们做“提升生产力”，看到 2% 的提升，都可能需要几百人干一年。所以这种 100% 级别的提升，是完全没见过的，闻所未闻。”

但这场对话最值得看的，并不是“又一个 AI 编程工具爆火”的故事，而是 Boris 如何把一个终端里的小聊天程序，迭代成今天这个能调工具、会 plan、甚至会主动找人沟通的开发 agent。

除了上文提到的，本次访谈中，还有一些很有意义的判断和观点，核心内容提炼如下：

  • 代码的保质期只有几个月。Claude Code 被反复重写，六个月前的代码几乎全部消失；重构不是例外，而是常态。

  • Plan mode 未来可能自动进入，再往后可能会消失。其本质，只是 prompt 里加一句“先别写代码”，最终可能一发 prompt 就能完成。

  • 不要和模型对赌。加很多脚手架也许能多拿 10% 的效果，但下一代模型可能直接“白送”；所有非模型能力最终都会变成技术债。

  • 功能不是规划出来的，是从用户行为里“长”出来的。plan mode、CLAUDE.md、co-work 都源于用户已经在做的事，产品只是把它们收拢进来。不要教育用户改变行为，而是顺着他们已经发生的行为去放大它。

  • Agent 的能力边界，会每几个月重写一次。你对“它能不能做”的判断很快会过时，工程师必须不断重置认知。多 agent 协作，是能力放大的关键变量。并行 sub-agent、本质上是 test-time compute 和上下文隔离的组合，会显著提升复杂任务能力。

  • 迭代速度本身就是护城河。Claude Code 可以一天做 20 个原型，快速试错比“设计完美方案”更重要。

对处于 AI 洪流中的技术开发者和创始人，Boris 给出的建议是，是新时代最重要的能力是“新手心态”。能承认自己错、能丢掉旧经验、能从第一性原理重新思考，比资历更重要。

以下为本段访谈的全部重点内容，InfoQ（还是写 AI 前线？）在不改变原意的前提下，对内容进行了整理编辑。

##访谈原文

Garry：谢谢你做出了这个东西（Claude Code)，它让我连续三周都没睡好。我已经对 Claude Code 上瘾了，感觉像给人装上了火箭助推器。这个体验大家已经持续感受好几个月了，我记得大概从 11 月底开始，很多朋友都说“感觉不一样了”。

Boris：我自己第一次有这种感觉，是在刚做出 Claude Code 的时候——那会儿我还不确定自己是不是做对了方向。我隐约觉得“可能成了”，然后我就开始睡不着了。

那是 2024 年 9 月。连续三个月，我没休过一天假，周末也在干，每晚都在工作。

我一直在想：“天啊，这东西可能会变成一个真正的产品。”但当时我也不知道它到底有没有用，因为那时候它其实还不会写代码。

###让 Boris 最意外的，是终端竟成了终点

Garry：从那时候到现在，如果你回看，你觉得最让你意外的是什么？

Boris：最不可思议的是：我们到现在居然还在用终端。终端本来只是起点，我没想到它最后会变成终点。

第二个意外是，它居然真的变得有用了。因为一开始它几乎不会写代码。甚至到 2 月份，它大概也就写了我 10% 的代码。我当时并不靠它写代码，它写得不够好，我还是大部分都手写。现在能做到我们当初下注的那个方向，说明赌对了；但当时这件事一点也不明显。

在 Anthropic，我们一直的思路是：不要只为“今天的模型”做产品，而是为“六个月后的模型”做产品。

这也是我给所有基于 LLM 做产品的创始人的建议：尽量去想——今天模型还不太擅长、但很快会变强的前沿点在哪里。它会变好，你只需要等它到位。

###Claude Code 是 如何构思出来的？

Harj：回到最开始，你还记得自己第一次有这个想法是什么时候吗？是某个灵光一现，还是它在你脑子里最初的版本是什么样？

Boris：其实它非常“意外”，就是一路演化出来的。

对 Anthropic 来说，我们很早就押注“编程”这条路：我们认为通往安全 AGI 的路径之一，就是通过编程能力。

整体思路一直是：先教模型写代码，再教它用工具，再教它用电脑。你也能从我加入的第一个团队看出来——当时叫 Anthropic Labs，做了三个产品：Claude Code、MCP 和桌面端 App，这些其实是串在一起的。

具体到 Claude Code，其实没人让我做 CLI。我们大概知道模型可能已经到了适合做编程产品的阶段，但还没有人真的做出一个能把这种能力“吃干榨净”的产品，所以当时有一种很强烈的“产品能力悬空感”（product overhang）。那会儿这种感觉更夸张，因为根本没人做过。

于是我就开始随便 hack。一开始我想：“要做编程产品，我得先学会怎么用 API。”

因为那时候我还没用过 Anthropic 的 API。

我就做了一个很小的终端程序来调用 API，本质就是个小聊天应用。因为当时大多数 AI 应用就是聊天形态，所以我也这么做：在终端里提问、回答。后来 tool use 出来了，我只是想试一下，我也不太懂它到底是什么。我当时想：“工具调用很酷，但可能没什么用吧？先试试。”

Harj：你用终端实现，主要是因为最快、最省事？

Boris：对，因为不用做 UI。那时就我一个人。

Harj：当时 Cursor、Windsurf 这些 IDE 方向的产品也在起势。你有没有受到压力，或者有人建议你们做成插件、或者干脆做成完整 IDE？

Boris：没有压力，因为我们自己都不知道要做什么。团队当时就是探索模式：我们隐约觉得要做点和编程有关的东西，但具体做什么完全不明朗，也没人能高置信拍板。

而我的工作就是把这个方向跑出来。

所以我先给模型接了 batch tool——因为那就是我们文档里的示例。

我把 Python 示例直接搬到 TypeScript，因为我用 TypeScript 写。然后我也不知道模型能不能用 bash，就让它去读文件，它能 cat 文件，还挺酷的。接着我就继续试：“那你到底还能干啥？”我问它“我现在在听什么歌”，它写了段 AppleScript 去控制我的 Mac，去我的播放器里查当前音乐，这还是 Sonnet 3.5 的时候，我完全没想到它能做到。

这是我第一次那种“燃料级 AGI 时刻”。我当时想：“天啊，模型就是想用工具，它只想用工具。”

###极简优雅终端，成就 Claude Code

Diana：这 Claude Code 以一种非常“反常识”的方式成功：形式上极简、很优雅，居然就是终端。终端存在很多年了，但它像一个很好的设计约束，让开发体验变得很有趣，用起来不像工作，更像玩。你也不用一直想文件在哪儿、结构怎么摆，这几乎像是意外得到的。

Boris：对，完全是意外。

终端这个形态在内部开始火起来之后——其实我做出第一个原型两天后，就把它给团队 dogfooding 了。因为当你有一个看起来可能有用的点子时，第一反应就是赶紧给别人用，看看他们会怎么用。

第二天我来上班，坐在我对面的同事 Robert，已经在电脑上用 Claude Code 写代码了。我当时特别震惊：“你在干嘛？这东西还没准备好，这只是个原型。”但它已经在那个形态下变得有用了。

后来我们做上线评审，准备对外发布 Claude Code，大概是 2024 年 11 月或 12 月。Dario 问我：“内部使用曲线都快竖直了，你是不是强制工程师用？是不是在 mandate？”我说：“没有，没有。我只是发了个帖子，然后大家互相转告，就这么传开了。”

整个过程都很偶然。我们一开始选择 CLI，只是因为成本最低，没想到它就这样自然地停留在那个形态里，并且跑了起来。

###从用户行为里长出来的功能：CLAUDE.md

Harj：在 2024 年那段时间，工程师具体怎么用它？已经用它交付代码了吗？还是用在别的地方？

Boris ：那时模型还不太会写代码。我自己最早用它来自动化 git。

我感觉我现在都快忘了 git 了，因为 Claude Code 帮我做太久了。

还有就是自动化 bash 命令、操作 Kubernetes 之类。也有人开始用它写代码，算是早期迹象。最早的一个典型用例其实是写单元测试，因为风险更低。模型当时写得也挺一般，但大家开始摸索怎么用。

我们还看到一个现象：大家开始给自己写 markdown 文件，然后让模型读这个 markdown 文件——这就是 CLAUDE.md 的来源。

对我来说，产品里最大的原则就是 latent demand（潜在需求）。这个产品几乎每一块都是从潜在需求里长出来的，CLAUDE.md 就是例子。

另外还有一个我觉得挺关键的产品原则：你可以围绕模型做“脚手架”（scaffolding）去提升一点性能，视领域不同，可能提升 10%～20%。

但这些提升往往会被下一代模型进步直接抹平。所以要么你不停地搭脚手架、再重建；要么你等下一代模型，很多能力会“免费”出现。某种程度上，这也是我们一直留在 CLI 的原因：我们觉得没有任何 UI 能保证六个月后仍然相关，因为模型进步太快了。

Garry：你说了一句很有意思的话：你的 CLAUDE.md 反而很短，几乎违背大家直觉。为什么？你里面写了什么？

Boris：我来之前还特意看了下，我自己的 CLAUDE.md 只有两行。第一行是：每次提 PR 都开启 automerge，只要有人 approve 就自动合并。这样我就能一直写代码，不用在 CR 来回折返。

第二行是：每次提 PR 都发到内部 stamps 频道，让人来 stamp 一下，这样我就能更快 unblock。

其他指令都在我们团队共享的 CLAUDE.md 里，它直接放在代码仓库里，全队每周都会贡献好几次。我经常看到有人 PR 里犯了那种完全可以避免的错，我就直接在 PR 里 @Claude，说“把这个加进 CLAUDE.md”，这种事我一周会做很多次。

Garry：那 CLAUDE.md 变得很长怎么办？我已经遇到过那种提示，说我的 CLAUDE.md 已经几千 token 了。你们怎么处理？

Boris：我们团队的 CLAUDE.md 其实也不算长，大概几千 token。

如果你遇到这种情况，我的建议是：直接删掉，重新开始。

很多人会过度工程化，想把一切都写进去。但模型能力每次都会变，所以更好的方式是：用最少的指令把模型拉回正轨。如果你删掉之后模型开始跑偏、做错事，那时候你再一点点加回来。你很可能会发现：随着模型变强，你需要写的反而越来越少。

我觉得自己是个挺普通的工程师。我不用很多花哨工具，不用 Vim，我用 VS Code，因为简单。

Jared Friedman：真的吗？我还以为你因为在终端里做了这个东西，会是那种硬核终端党：Vim only、看不上 VS Code 的那种。

Boris：团队里有这种人，比如 Adam Wolf，他就是那种“除非我死，否则你别想从我手里夺走 Vim”的类型。

我早期学到的一件事是：每个工程师握着自己的开发工具的方式都不一样，没有一种工具适合所有人。但也正是这种差异，让 Claude Code 有机会变得很好。

我会问自己：什么样的产品是我自己愿意用、对我来说顺手的？

用 Claude Code，你不需要懂 Vim、不需要懂 tmux、不需要懂 SSH、不需要懂一堆东西，你只要打开它，它会引导你、帮你把这些都做掉。

###不断重置认知，每一代 Agents 能做的事都在变

Garry：你们怎么决定终端到底要多“啰嗦”？有时候你得控制它、查看它。团队内部会不会为“更长还是更短”争得很厉害？每个用户可能都有自己的偏好，你们怎么拍板？

Boris：你怎么看？现在是不是太 verbose 了？

Garry：我超喜欢 verbose。因为它有时候会突然“跑很远”，我看着输出能很快判断：“哦不对不对，不是这个方向。”然后我就直接退出、停掉。它能在 bug 还没扩散之前就把它掐掉。通常是我 plan mode 没开好才会这样。

Boris：这块我们确实经常改。大概六个月前，我试过把 bash 输出都隐藏掉，只给总结，因为我觉得那么长的输出我不关心。结果我给内部员工试了一天，大家集体“起义”：“我要看我的 bash！”因为很多时候它其实很有用，比如 git 输出可能不重要，但跑 Kubernetes job 这种你就真的想看细节。

我们最近把 file read、file search 这种输出也做了隐藏，你会看到现在它不再显示“读了 food.md”，而是显示“读了 1 个文件、搜索了 1 个 pattern”。这在六个月前根本不敢发，因为模型那时还不够稳，常常会读错，你作为用户得盯着它纠错。但现在我发现它几乎每次都在正确轨道上。因为它用工具太多了，很多时候总结反而更好。

但我们发出去之后，GitHub 上很多人不喜欢，有个大 issue：大家说“不，我就想看细节。”这反馈很好。

于是我们加了一个 verbose mode，在 /config 里就能开；你想看所有文件输出就可以继续看。

我在 issue 里回复之后，大家还是不满意，我反而很开心，因为我最喜欢的事情就是听用户反馈，知道他们到底想怎么用。于是我们就一直迭代，迭代到更贴近大家想要的样子。

Garry：以前我比较老派，我喜欢 verbose，我喜欢说：“你这样做了，但我想你那样做。”但现在有一种完全不同的观点：只要一个真人需要看代码，就是坏事，这太有意思了。

Boris：Dan Shipper 也经常讲：每次看到模型犯错，就尽量把它写进 CLAUDE.md 或 skills 里，让它变成可复用的经验。

但我自己其实一直在纠结一个“元问题”：很多人说 agents 能做这个、能做那个，但 agents 真正能做什么，会随着每一代模型变化。

有时新同事加入团队，他们用 Claude Code 的方式甚至比我更激进，我会不断被他们震到。比如我们曾经有个 memory leak，要 debug。

我当时做法是：导 heap dump，打开 DevTools，看 profile，再去翻代码。我在那儿慢慢找。然后团队里另一个工程师 Chris 直接问 Claude Code：“我怀疑有内存泄漏，你能跑一下吗？然后帮我找。”Claude Code 拿到 heap dump 后，甚至给自己写了一个小工具来分析 dump，然后比我更快定位到了泄漏。

这个事情让我不得不反复“重置认知”，因为我的大脑有时还停留在六个月前。

###对于技术型创始人的建议

Diana：听起来刚毕业的人、或者没那么多预设的人，可能反而比工作很久的工程师更容易上手。那么，专家要怎么变强？ 你会给技术型创始人什么建议，让他们在最新模型发布时能做到“最大化利用”？

Boris：我觉得关键是 beginner mindset（新手心态），还有一点“谦逊”。

工程师这个职业经常被训练成有强观点，资深工程师甚至会因此被奖励。在我以前的大公司工作时，我招的架构师类型，往往就是经验多、观点强的人。但现在很多经验其实不再相关，很多观点都得改，因为模型在变强。所以我觉得最大的能力是：能科学地思考、能从第一性原理出发。

Diana：那你们招聘时怎么筛这种能力？

Boris：我有时会问：“给我一个你曾经错了的例子。”

这是个很好的问题。很多经典的行为面试题，甚至不是编码题，都挺有用的。

因为你能看出来：他能不能事后意识到自己的错误、能不能承认错误、以及有没有从中学到东西。有些很资深的人，尤其是某些“创始人型人格”，反而挺擅长这个。

但也有些人永远不会承担错误。我自己大概一半时间都是错的：一半想法都很烂，你只能去试。试了给用户、跟用户聊、学到东西，最后可能才走到一个好点子。有时候也走不到。

但过去这可能是创始人最重要的能力，现在我觉得它对每个工程师都很重要。

Garry：你会不会根据一个人和 Claude Code 协作的 transcript 来决定是否录用？

Boris：我们现在就这么做。

Garry：我们做了个实验：候选人可以上传用 Claude Code 或 Codex 完成功能的完整 transcript。通过这份记录，你几乎能看清一个人的思考方式：比如会不会看日志、能否在 agent 跑偏时拉回、是否用 plan mode、是否补测试、是否具备系统性思维。我甚至想做一个类似 NBA 2K 的“能力蛛网图”，直观展示他的 Claude Code 水平。

Boris：那会有哪些维度？具体是什么？

Garry：系统能力、测试能力、理解用户行为……还有设计能力。对我来说，我 CLAUDE.md 里最喜欢的一条是：每个 plan 都要判断它是过度工程、欠工程、还是刚刚好，并说明原因。

Boris：这也是我们在摸索的。

我观察团队里效率最高的工程师，分布呈现一种很明显的“双峰”。

一类是极端专家，比如我前面提到的 Jared，以及 bun 团队那类人。他们对开发工具、对 JS runtime 体系的理解都强到离谱。

另一类是超强通才，差不多是团队里的其他人：很多人同时跨产品和基础设施，或跨产品和设计，或跨产品和用户研究，甚至跨产品和业务。

我很喜欢那种“做奇怪事情”的人。过去这可能是一个 warning sign，你会担心他们能不能做出有用的东西。

Garry：那是极限测试。

Boris：对。但现在不一样了。比如团队里有个工程师 Daisy，她原本在别的组，后来转到我们组。

我希望她转来的原因是：她加入后没多久就给 Claude Code 提了一个 PR，做的是加新功能。但她不是直接把功能加进去——她先提了一个 PR：给 Claude Code 增加一个工具，让它可以测试任意工具并验证是否工作。这个 PR 合进去之后，她让 Claude 去写它自己的工具，而不是自己去实现。

我觉得这种“跳出盒子”的思路非常有意思，因为其实还没有多少人真正 get 到。

我们团队用 Claude Agents SDK 自动化了几乎所有开发环节：自动 code review、自动 security review、自动给 issue 打标签、自动把事情 shepherd 到生产环境……几乎什么都自动化了。我在外部也开始看到有人慢慢摸到这种用法，但它确实花了很久——大家在学习怎么用 LLM 做这种“新型自动化”。这是一种新的技能。

###Agent 拓扑：协作的下一种形态

Garry：我最近和不少创始人 office hours 时觉得很好笑的一件事是：在 AI 工具的加持下，拥有清晰产品愿景的创始人会被极大放大，他脑中完整的产品模型，让他用 Claude Code 能实现 50x 效率。但他的工程师没有那个“水晶记忆宫殿”，只能做 5x。问题在于：当愿景者被彻底解放，这种“核心构想者 + 执行者”的团队结构是否会成为新常态？同时，它也带来现实困境——即便效率暴涨，个人的时间与精力仍然是瓶颈。

Boris：我们刚发布了 Claude Teams，这是一种方式；你也可以自己搭，挺容易的。

Garry：Claude Teams 的愿景是什么？

Boris：就是协作。现在有一个全新的领域叫 agent topologies（Agent 拓扑）。

你怎么配置 agents？其中一个想法是“uncorrelated context windows”。多个 agents 各自拥有干净的上下文窗口，不会被彼此的上下文、或者自己的历史上下文污染。

你往一个问题里投入更多上下文，本质上是一种 test-time compute，会带来更多能力。再加上合适的拓扑，让 agents 以合适的方式沟通、合适地排列，它们就能做更大的东西。Teams 是一种思路，接下来还会有更多很快上线。目标就是让它能 build 得更多、更大。

一个很典型的例子是：我们的 plugins 功能，几乎完全是一个 swarm 在一个周末“跑出来的”。它连续跑了几天，基本没什么人工干预。plugins 上线时的形态，和它跑出来时几乎一致。

Garry：你们怎么搭起来的？你是先写清楚你要的结果，然后让它自己推细节，再让它跑起来吗？

Boris：对。团队里有个工程师给 Claude 一个 spec，让 Claude 用 Asana board。Claude 在 Asana 上建了一堆 ticket，然后 spawn 了一堆 agents，agents 开始自己认领任务。主 Claude 负责给总体指令，大家就这样跑出来了。

Diana：那些独立 agents 并不知道更大的 spec 的完整上下文，对吧？

Boris：对。如果你看现在 agents 的启动方式——我没拉过数据，但我敢猜大多数 agents 其实都是由 Claude 触发的，以 sub agents 的形式。

sub agent 本质上就是递归版 Claude Code，在代码里就是这么实现的。它是被“mama Claude”提示出来的。我觉得如果你看大多数 agents，大概率都是这样被发起的。

Harj：我的 Claude insights 最近也提示我，debug 的时候应该多这么做。我经常花很多时间 debug，如果能并行起多个 sub agents：一个看 log、一个看 code path，感觉是必然趋势。我已经把这个写进 CLAUDE.md 了：下次修 bug，就让多个 agent 并行分工。

Garry：遇到那种又怪又吓人的 bug，我会用 plan mode 修，它就会用 agents 去广泛搜索。相比之下，你在线性模式下更像是“做一个任务”，而不是“宽搜”。

Boris：我也一直这么做。如果一个测试像“研究型测试”，比较难，我会按任务难度来校准 sub agents 数量：难一点就 3 个，或者 5 个，甚至 10 个，并行研究，看他们最后汇总出什么。

Harj：那你为什么不把这个写进你的 CLAUDE.md？

Boris：看情况。这更像一个快捷方式：如果你发现自己反复重复同一句话，那就写进 CLAUDE.md；否则不需要把所有东西都写进去，你直接 prompt Claude 就行。

Harj：你心里也会不会想着：可能六个月后你连这都不用显示 prompt 了，模型自己就能搞定？

Boris：也许一个月后就不用了。

Diana：一个月后连 plan mode 都不需要了。

Boris：我觉得 plan mode 可能确实有一个比较有限的生命周期。

Diana：这对在场所有人都是个“alpha”。如果没有 plan mode，世界会是什么样？是不是你只要在 prompt 里描述清楚，它就能直接做完？一发入魂？

Boris：对。我们已经开始在做这方面的实验了，因为 Claude Code 现在已经能自己进入 plan mode 了，你们可能也见过。我们正在努力把这个体验打磨到“刚刚好”：它会在一个人类也会想要进入 plan mode 的那个节点自动进入。

其实 plan mode 没什么秘密，它做的事非常简单，就是在 prompt 里加一句“请先不要写代码”。仅此而已。你其实也可以自己直接这么说。

Diana Hu：听起来，Claude Code 的很多功能开发方式都很符合 YC 常说的那套：先跟用户聊、看用户怎么用，然后再回来实现；而不是你先有一个宏大的 master plan，再把所有功能按计划做出来。

Boris：对，基本就是这样。比如 plan mode，就是我们看到用户经常会说：“Claude 先帮我想方案、规划一下，但先别写代码。”这种说法有很多版本：有时只是把想法聊透；有时是让 Claude 写非常复杂的 spec。

但共同点都是：先做事、先想清楚，但暂时不要写代码。

所以那天就是周日晚上 10 点，我在看 GitHub issues、看内部 Slack 反馈频道，看到大家在讨论这个。我就用 30 分钟写出来，当晚就发了，周一早上就上线了——这就是 plan mode。

Harj：所以你说“以后不需要 plan mode”，是指那种“我担心模型会跑偏、做错方向，所以需要 plan mode 来约束它”的需求会消失？但“你仍然需要把想法想清楚、把需求说清楚”这件事不会消失吧？你总得在某个地方完成思考。

Boris：我更愿意从“模型能力在提升”来理解这个变化。

比如六个月前，单有 plan 还不够。你让 Claude 做计划，即使开了 plan mode，你也还是得在旁边盯着、babysit，因为它可能跑偏。现在我的习惯是：大概 80% 的 session 我都从 plan mode 开始。

虽然我说 plan mode 的寿命可能有限，但我其实是重度用户。我会让 Claude 先做计划，然后切到第二个终端 tab，让另一个任务也先做计划；tab 不够我就开桌面端 app，再去 code tab 里开更多 tab，总之大多数时候都是从 plan mode 起手。计划一旦靠谱了（有时需要一点来回），我就让 Claude 直接执行。

而现在用 Opus 4.5 的感受是：我觉得大概从 4.6 开始，它真的变得很稳了。只要 plan 是对的，它几乎每次都能一路保持在正确轨道上，把事情做对。

所以你会看到 babysit（意思是：全程盯着、随时纠正、手把手看着它别出错）的位置在变化——以前你要在 plan 前后都盯着；现在更多是只需要在 plan 之前盯着。再往后一步，也许你连 babysit 都不用了：你给一个 prompt，Claude 自己就能把它想清楚、做完。

Garry：下一步就是 Claude 直接跟你的用户对话了。它直接绕过你本人。

Boris：挺好玩的，这其实已经是我们现在在做的事了。

我们的 Claude 之间会互相交流，也会（至少在内部）挺经常直接在 Slack 上跟用户沟通。我自己的 Claude 偶尔还会想发推，但我一般会删掉——有点“尬”，我不太喜欢它的语气。

Garry：它都想发些什么？

Boris：有时候就是会去回复别人。因为我后台一直开着 co-work，co-work 特别爱这么干，它很喜欢用浏览器。

一个非常常见的模式是：我让 Claude 去 build 某个东西，它会先去看代码库；如果在 git blame 里看到某个工程师最近动过相关代码，它就会在 Slack 上直接给那位工程师发消息，问一个澄清问题。等对方回了，它就继续往下做。

###对各行业创始人的“未来”建议

Diana：那你给现在的创始人，一些“面向未来”的建议吧。感觉一切变化都很快，有哪些原则会长期有效，哪些会改变？

Boris：有些原则听起来很基础，但我觉得它们现在比以前更重要。

比如 latent demand（潜在需求），我提过无数次了，对我来说它就是产品里最重要的一条。

很多人不理解它，我在前几个创业项目里也没理解。它的意思大概是：人们只会去做他们本来就在做的事情，你很难让人去做一件全新的事。如果人们已经在努力做某件事，你让它更容易，这是好想法；但如果人们正在做一件事，你非要让他们改去做另一件事，他们大概率不会做。所以你要做的，就是让他们“本来就想做的事”更容易。

而且 Claude，会越来越擅长帮你发现这些产品点子。因为它能看反馈、看 debug logs，它能自己把这些东西梳理出来。

Harj：所以你说 plan mode 是 latent demand，是因为用户本来就已经会在浏览器里开着 Claude 的聊天窗口，用它来讨论 spec、讨论该怎么做；然后 plan mode 只是把这件事“搬进”Claude Code 里，让它在 Claude Code 里就能完成？

Boris：对，就是这样。有时候我会在办公室里走一圈，在同事身后站一下（当然我会先打招呼，不是偷看那种），看看大家具体怎么用 Claude Code。我看到很多类似的用法，而且 GitHub issues 里也有人在讨论。

Harj：你说你最惊讶的是终端被推到了这么远。那你觉得它还能走多远？在“swarm、多 agent”的世界里，会不会需要一个新的 UI 来承载这些东西？

Boris：挺有意思的。如果你一年前问我，我会说终端最多还有三个月寿命，然后我们就会换到下一个形态。

你也能看到我们一直在做各种实验：Claude Code 从终端起步，但现在也在 web 上、在桌面端 app（code tab 里），大概我们做了三个月或六个月；它也在 iOS/Android app 的 code tab 里；在 Slack、在 GitHub；还有 VS Code 扩展、JetBrains 扩展。我们一直在尝试不同的 form factor，想弄清楚“下一个形态”是什么。

到目前为止，我对 CLI 的寿命判断一直错，所以我大概也不是最适合预测这件事的人。

Harj：那你给 DevTool（ Developer Tool，开发者工具）创始人的建议呢？如果今天有人在做 DevTool 公司，他应该只为工程师/人类构建，还是也要考虑“Claude 会怎么想”、要不要为 agent 构建？

Boris：我会这样表述：去想清楚模型想做什么，然后让它更容易做到。

比如我最初 hack Claude Code 的时候，我意识到：它就是想用工具，它想和世界交互。那你怎么支持它？不要把它关在盒子里，然后告诉它“这是 API、这是你跟我交互的方式、这是你跟世界交互的方式”。正确做法是：去观察它想用哪些工具、它想完成什么，然后像你为用户做产品一样，把这些能力真正“放开”，让它能做到。

所以如果你在做 dev tool 初创公司，我会先问：你要为用户解决什么问题？然后当你用模型来解决这个问题时，模型“想做的动作”是什么？最后你的技术方案与产品方案，如何同时服务用户的需求与模型的需求，让两边的权重和需求都被满足。

###从 TypeScript 到 Claude Code，愉悦感很重要

Diana：十多年前，你是 TypeScript 的重度用户，还写过一本 TypeScript 的书，那时 TypeScript 还没火起来，大家还深陷 JavaScript。那会儿 TypeScript 还很“怪”，很多人不理解它为什么要给 JavaScript 加类型。现在回头看，它反而成了正确方向。我觉得 Claude Code 在终端里的形态，跟早期 TypeScript 有很多相似之处。

Boris：TypeScript 做了很多很“奇怪”的语言设计。比如它的类型系统里几乎任何东西都可以变成 literal type，这非常极端，甚至 Haskell 都不这么做。它还有 conditional types，这种东西我觉得很多语言压根没想过。但它又很强类型。

早期 Joe Pamer、Anders 和团队构建 TypeScript 时的思路是：我们有很多大型、未类型化的 JavaScript 代码库，我们得把类型加进去；但你不可能让工程师改变写代码的方式。你也不可能让 JavaScript 程序员像 Java 程序员那样写 15 层 class inheritance。他们会按自己的方式写：用反射、用 mutation、用各种传统上很难做类型化的特性。

Diana：对任何强函数式程序员来说，那些都是“很不安全”的写法。

Boris：没错。所以他们没有逼人改变写法，而是反过来围绕这种写法去构建类型系统。这太聪明了。

很多点子在当时连学界都没人做，完全来自实践：观察人们怎么写 JavaScript，理解他们想怎么写，然后把类型系统“贴合”到这个现实里。

Claude Code 也有点类似：你可以把它当作 Unix 工具来用，可以 pipe 进去、也可以 pipe 出来；在某些方面它挺“严谨”的。但在几乎其他所有方面，它只是我们想要的工具而已。

我先为自己做一个工具，然后团队为自己做，再给 Anthropic 员工用，再给用户用，最后它就变得非常有用。这不是一个“学院派、原则性很强”的产物。

Diana：结果也证明了这一点。十五年后，Haskell 那样更学术的语言并没有成为大多数代码库的选择，TypeScript 这种更实用的语言反而大量铺开了。因为它解决了问题。顺便说一句，我也不知道有多少人知道：Claude Code 的终端界面可能是现在最漂亮的终端应用之一，而且是用 React terminal 写的。

Boris：我一开始做它的时候，我曾经做过一段时间前端。我也算是个“混合型”：做设计、做用户研究、写代码，都会一点。

我们也很喜欢招这种工程师，所以我们确实偏爱 generalists。

对我来说，我在做一个终端里的产品，但我其实 Vim 用得也挺差的（笑）。所以我会想：怎么做一个让“像我这样的人”也用起来舒服的终端工具？

愉悦感非常重要。

YC 也经常讲“做一个人们真正爱用的东西”。产品如果只是有用，但用起来不会爱上它，那不够好。它得同时做到“有用”和“让人爱”。

但为终端做设计真的很难：80×100 个字符左右、256 色、一个字号、几乎没有鼠标交互……你能做的事非常有限，trade-off 特别多。一个不太多人知道的点是：终端其实可以开鼠标交互，比如点击之类。

Jared：那 Claude Code 里怎么开？我一直想弄明白这个。

Boris：我们没有在 Claude Code 里做这个。我们其实原型过几次，但体验很糟。因为一旦你要做鼠标交互，就得虚拟化滚动，会带来很多很奇怪的 trade-off。终端的底层也很特殊——它没有 DOM，更多是 ANSI escape codes 之类的东西，是从 1960 年代一路“有机演化”出来的一堆规范。

Garry：这感觉 BBS。像那种 BBS 门口小游戏。

Boris：这评价太好了。

但我们确实得自己摸索出很多终端 UX 原则，因为几乎没人写这些。你看 80、90、00 年代的大型终端应用，它们用 curses，有一堆窗口，看起来以今天标准会比较“土”、比较厚重复杂。所以我们得重造很多东西。

比如一个很小的细节：终端里的 spinner（加载转圈那种提示），到现在可能迭代了 50 次、甚至 100 次，里面大概 80% 都没上线。我们就是不断试：不舒服就换下一个，再试，不舒服再换。

Claude Code 的一个神奇之处是：你可以连做 20 个原型，选一个最喜欢的，然后发布，整个过程可能也就几个小时。

过去你可能要用 Origami、Framer 之类的工具，做三版原型都得两周，慢很多。现在我们有一种“奢侈”：我们要探索一个新终点，我们不知道正确答案是什么，但我们能用极快的迭代速度逼近它——这让我们更容易做出一个“快乐的、让人爱用”的产品。

###给开发者们的其他建议

Jared：Boris，你刚才说你还有一些给 builders 的建议，但我们一直插话，因为好奇的问题太多了。

Boris：我大概还有两条建议，可能听起来有点“奇怪”，因为它们都跟“为模型构建”有关。

第一条是：不要为今天的模型构建，要为六个月后的模型构建。

这听起来有点反直觉，因为如果产品今天跑不通，就很难找到 PMF。但你还是应该这么做，否则你可能会花很多精力在“当下模型”的 PMF 上，然后很快被别人超车，因为他们在为下一个模型构建，而新模型几个月就来一次。

所以你要不断用模型，去摸清它能力的边界，然后为你认为“六个月后会出现的模型能力”做准备。

第二条建议是：在我们 Claude Code 团队的区域墙上，挂着一份《The Bitter Lesson》的装裱版。我觉得所有人都应该读这篇文章（作者是 Rich Sutton）。核心思想之一是：更通用的方法最终会赢过更特化的方法。推到极致，就是一句话：不要和模型对赌（never bet against the model）。

我们经常面临一个 trade-off：我们可以在 Claude Code 里加功能，让产品更好，这些非模型本体的代码我们叫 scaffolding（脚手架）；但我们也可以等几个月，新模型可能就能原生做到这些。

这个权衡一直存在：你现在投入工程精力，可能在某个能力维度上多拿到 10%～20% 的提升；或者你干脆等下一代模型，免费得到。所以要始终用这个 trade-off 来思考：你到底要在哪些地方投入？并且假设你做的 scaffolding 最终都会变成“技术债”。

Diana Hu：那你们会不会每六个月就大改 Claude Code？有没有一些 scaffolding 被删掉了，因为模型变强后不需要了？

Boris：太多了。Claude Code 几乎就是写了又写、改了又改、重写了无数次。我们每隔几周就会下掉一些工具（unship），也会每隔几周加新工具。

六个月前存在的代码，现在几乎没有任何一部分还保留着——它一直在被重写。

Diana：那是不是可以说，当前 Claude Code 的代码库里，80% 都是最近几个月才写的？

Boris：对，肯定。甚至可能更短。几个月这个感觉挺准确的。

Diana：这也是另一个“alpha”：代码的 shelf life 可能只有几个月，顶尖的创始人应该预期这种生命周期。

###1000x 工程师，Claude 把传说变成现实

Garry：你们看到 Steve Yegge 那篇夸 Anthropic 工作体验的帖子了吗？里面有一句很震撼：他说 Anthropic 的工程师平均生产力是 Google 巅峰时期工程师的 1000 倍，这数字太夸张了。三年前我们还在聊 10x engineer，现在都在聊 1000x 了，还是“对标 Google 巅峰工程师”的 1000x，太离谱了。

Boris：内部确实是这样。如果看技术员工，大家每天都用 Claude Code，甚至非技术员工也在用——我觉得销售团队里大概有一半人在用 Claude Code。他们后来开始转向 co-work，因为更容易用，而且有 VM，会更安全一点。

我们刚拉了个数据：团队去年规模翻倍，但“人均工程产出”大概涨了 70%。衡量方式很粗糙——就是 pull requests，但我们也会用 commits、以及 commit 的生命周期等指标交叉验证。

自从 Claude Code 推出后，Anthropic 的人均工程产出整体涨了 150%。

因为我以前在 Meta 负责代码质量，也负责跨多个产品线的代码库质量。当时我们做“提升生产力”，看到 2% 的提升，都可能需要几百人干一年。所以这种 100% 级别的提升，是完全没见过的，彻底闻所未闻。

###作为开发者，Boris 为何选择加入 Anthropic？

Garry：你当初为什么会选择加入 Anthropic？你作为 builder，其实去哪都行。是什么让你觉得“就是这群人、就是这种方式”？

Boris：我当时住在日本乡下，每天早上刷 Hacker News。

后来某个时候开始，新闻全都是 AI。我开始用一些早期产品，记得第一次用的时候，真的有点“屏住呼吸”的感觉，说出来有点肉麻，但当时就是那种感觉：太惊艳了。那大概还是 Claude 2 的时代。

于是我开始跟 Labs 的朋友聊，看看他们在做什么。我认识了 Anthropic 的创始人之一 Ben Mann，他很快就说服了我。后来见到更多团队成员，也同样打动我，大概是两点：

第一，它真的像一个研究实验室在运转。产品本身非常小，核心只有一件事：把安全模型做出来。离模型更近、离研发更近、产品不是最重要的——模型才是最重要的。这对我这种做了很多年产品的人来说，非常共鸣。

第二点是它的 mission-driven（这里的 mission 指：确保 AI 安全发展，避免灾难性后果）。我是重度科幻读者，书架全是科幻。我很清楚这件事最坏情况下会有多糟。我在想今年会发生什么时，我觉得会非常疯狂；在最坏情况下，它也可能非常非常糟。所以我想在一个真正理解这一点、真正把它内化的地方工作。

在 Anthropic，你在食堂、走廊里听到的对话，大家都在聊 AI safety，这就是所有人最关心的东西。我很想待在这样的地方。对我个人来说，这个 mission 太重要了。

###预计“以后写代码都不用 IDE 了”

Jared：那你说“今年会发生什么”，你具体指什么？

Boris：如果你回想六个月前大家做的预测，Dario 预测过：Anthropic 里 90% 的代码会由 Claude 写。这个预测是真的。

对我个人来说，自从 Opus 4.5 之后基本就是 100%：我把 IDE 都卸了，我不再手写任何一行代码，全都用 Claude Code 和 Opus。我每天能落 20 个 PR。如果看 Anthropic 整体，不同团队在 70%～90% 之间浮动；很多团队、很多人其实也是 100%。

我记得今年 5 月我们发布 Claude Code 时，我还做过一个预测：以后写代码不需要 IDE 了。当时听起来特别离谱，我感觉台下都倒吸一口气，因为太夸张了。但其实你只要沿着指数曲线去推，这就是会发生的事情。

我们公司 DNA 里就有这条——因为我们的三位创始人是 scaling laws 那篇论文的共同作者，他们很早就看到这条曲线。所以这不是玄学，就是沿着指数走下去，而它确实发生了。

Boris：继续沿着这条指数往前推，我觉得编程会逐渐对每个人都“被解决”。

今天对我来说基本已经解决了；我认为以后对所有人都会如此，不管是什么领域。我们会开始看到 “软件工程师”这个头衔慢慢消失。可能会变成 builder、product manager，或者头衔还保留，但只是一个遗留符号。因为大家做的工作不再只是写代码：软件工程师还会写 spec、还会跟用户沟通。

我们团队现在已经出现这种趋势：工程师是通才，每个职能都在写代码——PM 写、设计师写、EM 写、甚至我们的 finance 同事也写。未来你会在更多地方看到这一幕。

这算是沿趋势推演得到的“下限”。但“上限”更吓人。

比如我们提到 ASL4 在 Anthropic 我们有这些安全等级：ASL3 是目前模型所处的位置；ASL4 是模型具备递归自我改进能力。如果走到那一步，我们必须满足一堆条件才能发布模型。

最极端的情况，是出现递归自改；或者出现灾难性滥用，比如用模型设计生物病毒、设计 zero-day 等等。这些都是我们现在非常非常认真在防的事情，确保它不要发生。

我看到大家用 Claude Code 的方式，真的很震撼。我最初只是想做个酷东西，结果它变得这么有用，这既意外、又兴奋。

Harj：我从外界的感觉是，大家假期一结束就突然发现 Claude Code，然后就一路疯到现在。内部也是这样吗？你们是不是过了个美好的圣诞假期，回来发现“发生了什么”？

Boris：其实 12 月我一直在旅行，我给自己放了个“coding vacation”。到处走，但每天都在写代码，这种感觉还挺好。那段时间我也开始用 Twitter，因为我以前做过 Threads，所以我一直是 Threads 用户，我就想看看大家都在哪个平台活跃。

我觉得很多人就是在那时发现了 Opus 4.5。我其实早就知道 Opus 4.5 的能力了。内部这几个月 Claude Code 一直在指数式增长，所以假期之后曲线只是变得更陡了。

现在你看外部也有各种数据：比如 Mercury 说有 70% 的创业公司选择 Claude 作为首选模型；还有 SemiAnalysis 之类的数据说，公开 commits 里有 4% 是 Claude Code 产生的。

大公司用、小公司也用。甚至它还参与了 Perseverance（火星车）的航线规划，这对我来说太酷了。我们团队还专门印了海报，因为大家觉得“NASA 选择用这个东西”实在太酷了。但也感觉这才刚开始。

###非技术用户也开始用 Claude Code

Garry：Claude Code 和 co-work 之间是什么关系？co-work 是 Claude Code 的一个 fork 吗，还是你让 Claude Code 看了 Claude Code，然后写了个给非技术用户的 spec，再跑几天就做出来了？

Boris：我这大概是第五次用“latent demand”（潜在需求）这个词了（笑）。

我们当时看 Twitter：有人用 Claude Code 去监测番茄植物；有人用它从损坏硬盘里恢复婚礼照片；有人用它做金融相关的事情。

回到 Anthropic 内部：每个设计师都在用；整个财务团队都在用；数据科学团队也在用，但他们用它并不是为了写代码。很多人为了用它，愿意去折腾半天，在终端里安装一个东西。

我们很早就知道我们要做点什么，于是试了很多想法，最后真正“起势”的，就是桌面端 app 里那个简单的 GUI wrapper——本质就是 Claude Code 的外壳而已。底层还是同一个 agent，完全是 Claude Code。

Felix 是早期的重要贡献者，他很熟那套技术栈。当时他们在试各种想法，最后大概 10 天就把它做出来了，而且几乎 100% 都是 Claude Code 写的。我们觉得它已经到了可以发布的状态。

当然，为非技术用户要补很多东西：它会在虚拟机里运行；有很多删除保护；有很多权限提示和 guardrails。整体来说，这条路其实挺明显的。

参考链接：https://www.youtube.com/watch?v=PQU9o_5rHC4

📰 今日新闻精选：

  • 春运过半，我国交通出行人数累计 50.8 亿人次；广州白云机场春运客流量破 500 万人次，成全国首个达成此记录的机场
  • 港珠澳大桥珠海公路口岸单日车流量创历史新高，超 2 万辆次
  • 大理一游客大年初四预订医院内住宿：最贵 149 元一晚，称有食堂、就诊方便
  • 春节后资金面前瞻：首周公开市场有超 22000 亿元逆回购到期
  • 2 月 24 日 20 时 28 分将出现今年视直径最大的上弦月，公众凭肉眼即可观赏
  • 宇树科技：机器人技术水平已经接近 10 岁小孩，大规模应用最快 3 至 5 年实现
  • 米兰冬奥会：中国队 5 金 4 银 6 铜收官，创境外冬奥参赛最佳战绩；挪威 18 金 12 银 11 铜连续四届登顶
  • 广东梅州大埔县一天内连发五起森林火情，初步调查均因违规燃放烟花爆竹引发
  • 石家庄突发山火蔓延数座山，官方通报：明火已扑灭，无人员伤亡，起火原因为大风引起的高压线连线打火
  • 7 名中国游客遗体已从贝加尔湖底打捞出，俄外长向中方致哀，并承诺调查结果将通报中方
  • 泰媒：泰国清迈一动物园十天内 72 只孟加拉虎死亡，检验确认为犬瘟热与支原体合并感染，非人畜共患病
  • 日媒：日本东京晴空塔电梯急速下降紧急停运，约 20 人被困，救援进行中
  • 美媒：美国伊利诺伊州州长向白宫寄账单，要求后者退还近 87 亿美元关税税款
  • 外媒：一男子试图闯入特朗普的海湖庄园，被美特勤局特工当场击毙，事发时特朗普人在华盛顿
  • 外媒：美官员称若伊朗尽快提交核协议草案，美伊会谈或将于 27 日举行；美国在约旦军事基地部署大量战机，卫星图像显示超 60 架

📅 今日信息：

  • 公历：2026-02-23 星期一 双鱼座
  • 农历：二〇二六年正月初七
  • 下一节气：2026-03-05，惊蛰
  • 今年进度：14.79%（已过 54 天，剩余 310 天）

🌟 历史上的今天

  • 1945 年：二战期间，美军在硫磺岛升起国旗，成为标志性时刻。
  • 1987 年：超新星 SN 1987A 在大麦哲伦云中被观测到，是近 400 年来最亮的超新星之一。

📰 今日新闻精选：

  • 春运过半，我国交通出行人数累计 50.8 亿人次；广州白云机场春运客流量破 500 万人次，成全国首个达成此记录的机场
  • 港珠澳大桥珠海公路口岸单日车流量创历史新高，超 2 万辆次
  • 大理一游客大年初四预订医院内住宿：最贵 149 元一晚，称有食堂、就诊方便
  • 春节后资金面前瞻：首周公开市场有超 22000 亿元逆回购到期
  • 2 月 24 日 20 时 28 分将出现今年视直径最大的上弦月，公众凭肉眼即可观赏
  • 宇树科技：机器人技术水平已经接近 10 岁小孩，大规模应用最快 3 至 5 年实现
  • 米兰冬奥会：中国队 5 金 4 银 6 铜收官，创境外冬奥参赛最佳战绩；挪威 18 金 12 银 11 铜连续四届登顶
  • 广东梅州大埔县一天内连发五起森林火情，初步调查均因违规燃放烟花爆竹引发
  • 石家庄突发山火蔓延数座山，官方通报：明火已扑灭，无人员伤亡，起火原因为大风引起的高压线连线打火
  • 7 名中国游客遗体已从贝加尔湖底打捞出，俄外长向中方致哀，并承诺调查结果将通报中方
  • 泰媒：泰国清迈一动物园十天内 72 只孟加拉虎死亡，检验确认为犬瘟热与支原体合并感染，非人畜共患病
  • 日媒：日本东京晴空塔电梯急速下降紧急停运，约 20 人被困，救援进行中
  • 美媒：美国伊利诺伊州州长向白宫寄账单，要求后者退还近 87 亿美元关税税款
  • 外媒：一男子试图闯入特朗普的海湖庄园，被美特勤局特工当场击毙，事发时特朗普人在华盛顿
  • 外媒：美官员称若伊朗尽快提交核协议草案，美伊会谈或将于 27 日举行；美国在约旦军事基地部署大量战机，卫星图像显示超 60 架

📅 今日信息：

  • 公历：2026-02-23 星期一 双鱼座
  • 农历：二〇二六年正月初七
  • 下一节气：2026-03-05，惊蛰
  • 今年进度：14.79%（已过 54 天，剩余 310 天）

🌟 历史上的今天

  • 1945 年：二战期间，美军在硫磺岛升起国旗，成为标志性时刻。
  • 1987 年：超新星 SN 1987A 在大麦哲伦云中被观测到，是近 400 年来最亮的超新星之一。

最近，Claude Code 创始人 Boris Cherny 上了 Y Combinator 的 Lightcone 播客，聊了将近一个小时。

这期访谈非常精彩。信息密度极高，爆点一个接一个。

如果你是程序员，建议你认真看完。如果你不是程序员，更建议你看完——因为这件事跟每个人都有关。

Boris 在访谈里说了一句话：“I think we’re going to start to see the title ‘software engineer’ go away.”“我认为我们将开始看到’软件工程师’这个头衔慢慢消失。”

三年前，我用 ChatGPT 写出第一个贪吃蛇的时候，发了条朋友圈：留给人族程序员的时间不多了。

当时程序员们不服气。“你懂什么叫架构吗？”“AI 写的代码一跑就崩。”“它只会写个贪吃蛇，让它写个王者荣耀试试。”

三年后，Claude Code 的创始人亲口验证了这个判断。而且他说得比我激进得多。

下面，我把这期访谈里最有价值的内容拆给你们看。

Boris 是谁？

在说他说了什么之前，先说说他是谁。

Boris Cherny ，编程完全自学，在 Meta 干了七年，从普通工程师一路做到首席工程师（ IC8 ），负责过 Facebook 和 Instagram 的核心架构。还出版了 O’Reilly 的《 Programming TypeScript 》——TypeScript 圈里最权威的书。

这不是一个”AI 布道师”。这是一个写了十几年代码的硬核工程师。

2024 年，他加入 Anthropic ，创建了 Claude Code 。然后他开始亲眼看到——他花了十几年磨练的技能，正在以前所未有的速度被替代。

“软件工程师”这个头衔，要消失了

他在访谈里的原话，值得完整引用：

“I think today coding is practically solved for me, and I think it’ll be the case for everyone regardless of domain. I think we’re going to start to see the title ‘software engineer’ go away. And I think it’s just going to be maybe builder, maybe product manager, maybe we’ll keep the title as a vestigial thing.”

“我认为今天编程对我来说基本上已经解决了，我认为对每个人来说——无论什么领域——都会是这样。我认为我们将开始看到’软件工程师’这个头衔慢慢消失。它可能会变成 builder （建造者）、product manager （产品经理），也许我们会保留这个头衔，但只是作为一个遗留的符号。”

注意这个词：vestigial thing 。

这是个生物学词汇。指进化过程中已经失去功能的器官，比如人的阑尾。它还在，但没有实质意义了。

Boris 用这个词来形容”软件工程师”这个头衔。

不是说这个职业要死，而是说：它的功能性会退化。就像阑尾——有，但用处不大了。

那退化成什么？他说的很清楚：

“软件工程师还将要写 spec （需求规格文档），他们要跟用户沟通。就像我们团队现在正在看到的这种现象：工程师非常通才化，我们团队每一个职能的人都会写代码——我们的产品经理写代码，设计师写代码，工程经理写代码，甚至财务人员也写代码——我们团队每个人都在写代码。”

编程，正在从”专业壁垒”变成”基础能力”。就像阅读写作。一百年前，能读会写是一种专业技能。今天，这是基本素养。写代码，会走同样的路。

他自己放弃了自己的“技能”

有人会说：这只是一种判断，说说而已。

不。Boris 已经身体力行了。

他在访谈里说：“对我个人来说，自从 Opus 4.5 之后基本就是 100%：我把 IDE 都卸了，我不再手写任何一行代码，全都用 Claude Code 和 Opus 。我每天能落 20 个 PR 。”

停一下。

这个人出版过 TypeScript 最权威的书，在 Meta 写了七年代码。现在，他把 IDE 卸载了，不再手写任何一行代码。
工具的发明者，自己不用工具了。

而且每天 20 个 PR 。一般的工程师一周能交付几个 PR ？他一天 20 个。

他还讲了一个案例，非常有说服力。

团队里有个内存泄漏的 bug 需要 debug 。Boris 的做法是：导 heap dump ，打开 DevTools ，看 profile ，再去翻代码，慢慢找。

另一个工程师 Chris ，直接跟 Claude Code 说：“我怀疑有内存泄漏，你能跑一下，帮我找找？”
Claude Code 拿到 heap dump 之后，先给自己写了一个小工具来分析 dump 。然后，比 Boris 更快定位到了泄漏。

两种方式放在一起，差距一目了然。不是 AI 写的代码不好。是 AI 的分析方法，比经验丰富的资深工程师更高效。

更夸张的是他们的 plugins 功能：“我们的 plugins 功能，几乎完全是一个 swarm 在一个周末’跑出来的’。它连续跑了几天，基本没什么人工干预。plugins 上线时的形态，和它跑出来时几乎一致。”

一个周末。基本无人工干预。

这不是”AI 辅助编程”了，这是”AI 主导编程，人类偶尔过问”。

涨 150%——这个数字意味什么

Boris 在访谈里提到了一个数据：“自从 Claude Code 推出后，Anthropic 的人均工程产出整体涨了 150%。”

然后他加了一句话，让这个数字真正有了重量：“因为我以前在 Meta 负责代码质量，也负责跨多个产品线的代码库质量。当时我们做’提升生产力’，看到 2%的提升，都可能需要几百人干一年。所以这种 100%级别的提升，是完全没见过的，彻底闻所未闻。”

在大厂里，几百人努力一年，换来 2%的提升。

Claude Code 上线，Anthropic 人均产出直接提升 150%。

这不是同一量级的事情了。

目前 Anthropic 整体 70%-90%的代码由 AI 生成。Boris 个人，以及很多团队，已经是 100%。

代码的保质期，只有几个月

这是整个访谈里最让人震动的一个观点。

主持人 Diana 问了 Boris 一个问题：Claude Code 自己的代码库，有多少是最近几个月才写的？

Boris 说：“六个月前存在的代码，现在几乎没有任何一部分还保留着——它一直在被重写。”

Diana 又追问：那是不是说，80%的代码库都是最近几个月才写的？

Boris 直接说：“对，肯定。甚至可能更短。”

过去，程序员的核心资产是什么？是积累。是你写过的那些代码，是你在某个系统里埋下的肌肉记忆，是你踩过的坑和趟出的路。

现在，代码的有效期只有几个月。你花了三年积累的某套技术栈，被重写了。你花了两年优化的某个架构，被淘汰了。

当代码都在飞速被重写，“我在这个领域做了十年”这句话，还值多少钱？

指数曲线不在乎程序员的不服气

可能有人还是不服气。三年前不服气，今天看了这些数据还是不服气。

Boris 对此的回应很简单：2025 年 5 月，他发布 Claude Code 的时候，在台上说了一句话：“以后写代码不需要 IDE 了。”

他自己说：“当时听起来特别离谱，我感觉台下都倒吸一口气，因为太夸张了。”

多久之后这变成现实的？几个月。

“你只要沿着指数曲线去推，这就是会发生的事情。我们公司 DNA 里就有这条——因为我们的三位创始人是 scaling laws 那篇论文的共同作者，他们很早就看到这条曲线。所以这不是玄学，就是沿着指数走下去，而它确实发生了。”

指数不是预测，是物理定律。

Boris 还特别喜欢举古腾堡印刷机的例子：

15 世纪，印刷机发明后的 50 年里，印刷品数量比之前一千年总和还多，成本下降了 100 倍。

那抄写员呢？失业了吗？

没有。他们被解放出来，去做更有价值的工作——绘制精美的插图，装订更精良的书籍。

但关键是：他们的核心工作，手抄文字，消失了。他们必须转型。不转型的那些人，才真的失业了。

新的面试标准

Boris 在访谈里还提到了一个细节，让人印象很深。

Garry Tan 问他：你会不会根据一个人和 Claude Code 协作的 transcript 来决定是否录用？

Boris 说：“我们现在就这么做。”

面试标准已经变了。

你和 AI 怎么协作，比你自己会什么代码，更重要。

Boris 还说：“工程师这个职业经常被训练成有强观点，资深工程师甚至会因此被奖励……但现在很多经验其实不再相关，很多观点都得改，因为模型在变强。所以我觉得最大的能力是：能科学地思考、能从第一性原理出发。”
强观点，在过去是优势。在变化的时代，可能是枷锁。

不是末日，是分叉路

Boris 没有在宣判末日。他说的是：

这是一场像印刷机一样的变革，不是一场灾难。

但变革和灾难对谁有区别？

对主动转型的人——这是机会。对坚持”我的老路走了十年不会错”的人——这就是灾难。

三年前，我看到 AI 编程刚刚抬头的时候，说了一句”留给人族程序员的时间不多了”。三年后，Claude Code 的创始人站出来说：“编程对我来说已经解决了。软件工程师的头衔将会消失。”

问题只剩一个：

你打算站在那条指数曲线的哪一侧？

看得到的人，会重新定义自己。

看不到的人，会在某一天突然发现，世界已经走到前面很远了。

Boris 在 Anthropic 的 Claude Code 团队墙上挂着一幅装裱过的文章——Rich Sutton 的《 The Bitter Lesson 》。他从中提炼出一句话：“Never bet against the model.”
不要和模型对赌。

一、小知识

在HarmonyOS应用开发中，导航栏（Navigation）的工具栏（ToolBar）显隐控制是提升界面交互体验的核心能力。大家伙们跟着我这篇小文章一起深入了解一下工具栏显隐的实现原理、API特性、多版本适配策略，并结合一些实际开发案例看看吧。

二、核心知识点哦

2.1 基础显隐的控制

咱们通过hideToolBar属性实现工具栏的显隐控制：

// 基础显隐控制（鸿蒙5+）
Navigation() {
  // 页面内容
}
.hideToolBar(true)  // 隐藏工具栏

关键特性：

  • 默认值：false（显示工具栏）
  • 作用层级：影响当前Navigation组件及其子页面
  • 限制条件：需配合titleMode使用，当标题栏隐藏时工具栏自动隐藏

2.2 动态显隐控制

鸿蒙6+新增动态显隐API：

// 动态显隐配置（鸿蒙6+）
.titleBar({
  dynamicHide: {
    hideToolBar: true,    // 动态隐藏工具栏
    triggerOffset: 100,   // 触发偏移量（vp单位）
    animation: {
      duration: 300,      // 动画的时长
      curve: AnimationCurve.EaseOut
    }
  }
})

三、多版本实现对比一下下

3.1 API差异来看看有些啥

特性鸿蒙5实现鸿蒙6+优化
显隐触发方式手动设置hideToolBar属性支持滚动/点击等事件触发动态显隐
状态保持页面重建后恢复默认状态通过@State保持显隐状态
动画效果无支持自定义动画曲线和时长
多页面同步需手动逐层设置通过导航控制器统一管理

3.2 代码实现对比看看

鸿蒙5滴：

// 鸿蒙5静态显隐
Navigation() {
  List() {
    // 列表内容
  }
}
.hideToolBar(true)
.titleMode(NavigationTitleMode.Mini)

鸿蒙6+动态显隐：

// 鸿蒙6+滚动显隐
@State isScrolling = false
Scroll() {
  isScrolling = true
  // 滚动监听逻辑
}
.navigation {
  .titleBar({
    dynamicHide: {
      hideToolBar: this.isScrolling
    }
  })
}

四、举些小例子

4.1 列表页工具栏显隐

场景需求：列表滚动时隐藏工具栏，静止时显示

@Entry
@Component
struct ListPage {
  @State scrollOffset = 0
  @State showToolbar = true

  build() {
    Navigation() {
      Scroll() {
        List({ space: 20 }) {
          ForEach(0..50, (index) => {
            ListItem() {
              Text(`Item ${index}`)
                .height(60)
            }
          })
        }
        .onScroll((offset) => {
          this.scrollOffset = offset
          this.showToolbar = offset === 0
        })
      }
    }
    .titleBar({
      content: {
        title: { mainTitle: "商品列表" },
        toolBar: {
          items: [
            { value: "筛选", icon: "filter" }
          ]
        }
      },
      dynamicHide: {
        hideToolBar: this.scrollOffset > 50
      }
    })
  }
}

4.2 详情页工具栏显隐

场景需求：详情页固定显示工具栏

@Entry
@Component
struct DetailPage {
  build() {
    Navigation() {
      Column() {
        Image($r("app.media.product"))
          .width("100%")
          .height(300)
        Text("商品详情")
          .fontSize(24)
      }
    }
    .hideToolBar(false)  // 强制显示工具栏
    .toolBar({
      items: [
        { value: "收藏", icon: "heart" },
        { value: "分享", icon: "share" }
      ]
    })
  }
}

五、多设备适配小技巧

5.1 屏幕方向适配

// 横屏隐藏工具栏
@MediaQuery(media: ScreenOrientation.Landscape)
.navigation {
  .hideToolBar(true)
}

5.2 系统版本适配

// 鸿蒙5兼容处理
if (version < 6) {
  this.navigation.hideToolBar(true)
} else {
  this.navigation.titleBar({
    dynamicHide: { hideToolBar: true }
  })
}

六、一般的交互流程

graph TD
    A[用户滚动页面] --> B{滚动距离>阈值?}
    B -->|是| C[触发隐藏动画]
    B -->|否| D[保持显示状态]
    C --> E[更新显隐状态]
    E --> F[执行布局重绘]
    F -->|状态变化| G[触发回调事件]

七、性能优化小建议

  1. 防抖处理：

    .onScroll(debounce(200, (offset) => {
  this.handleScroll(offset)
}))

  2. 状态缓存：

    @Cacheable
private getToolbarState(): boolean {
  return this.scrollOffset > 50
}

  3. 渲染优化：

    • 使用@Link替代深层状态传递
    • 避免在onScroll中执行高耗时操作

八、总结一下下

  1. 显隐策略的选择：

    • 内容消费型页面：推荐动态滚动显隐
    • 操作密集型页面：保持工具栏常显
    • 多页面导航：统一管理显隐状态

  2. 注意一下下哦：

    • 避免在build方法中频繁调用显隐方法
    • 嵌套导航时需逐层设置显隐属性
    • 深色模式下需同步调整工具栏图标颜色

  3. 调试小技巧：

    • 使用DevEco Studio的Layout Inspector
    • 添加日志监控显隐状态变化
    • 通过@ohos.animator实现复杂滴动画

Ai 加持下传统软件工程里 coding 和 test 岗位（数量）确实面临压力。

那么其他的岗位呢？比如架构，需求分析，运维，技术支持，售前支持等岗位，他们被 ai 冲击的部分会在哪里。

架构和需求分析有可能会进一步演化成 prompt oriented 。目标是搞清楚客户要什么，转化为 ai 能执行的 prompt 。

运维感觉也会受到不小的冲击。

（高级）技术支持怕是主要作用是给 ai 擦屁股？分析 ai vibe 出来的代码怎么就在这个地方不管用。而售前支持则是对齐需求和既有产品颗粒度，感觉也容易被 ai 替代。

看评测和看车评一样 几家都说自己厉害
现在在做一个国内编程大模型的选型
有没有体验过的朋友分享一下
特别是最有性价比的
我看 qwen code plan 似乎还蛮厚道

多智能体系统一旦从顺序执行走向并行，测试的需求就更严格了。单个智能体的输出可能都是对的，但多个智能体并行决策、彼此影响时，集体行为可能违反系统级约束，而传统的单元测试和输出断言对这类问题完全无能为力。

这篇文章聚焦的就是这个问题：如何测试并行多智能体系统的协调行为。以一个跨四个城市的网络流量调度系统为例，从轨迹捕获、行为不变量、回放回归、黄金数据集到 CI/CD 集成，逐步搭建一套完整的协调测试框架。

被测系统

具体场景是骨干网光纤切断事件的自动响应。当故障被检测到时，一个 Coordinator Agent 分析影响范围，将任务分发给四个并行的区域流量智能体，分别负责纽约、达拉斯、拉斯维加斯和旧金山。四个智能体并行工作，转移流量负载，对非关键服务施加限速，目标是在级联拥塞发生之前完成处置。

                     ┌──────────────────────┐  
                    │  Fiber Cut Detected  │  
                    │  (BGP flap alarm)    │  
                    └──────────┬───────────┘  
                               │  
                               ▼  
                    ┌─────────────────────┐  
                    │  Coordinator Agent  │  
                    │  (impact analysis + │  
                    │   task delegation)  │  
                    └──────────┬──────────┘  
                               │  
          ┌────────────────────┼─────────────────────────────────────────┐  
          ▼                    ▼                    ▼                    ▼  
┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐  
│   NYC Agent     │  │  Dallas Agent   │  │ Las Vegas Agent │  │    SF Agent     │  
│ Shift load to   │  │ Absorb transit  │  │ Rate-limit CDN  │  │ Reroute peering │  
│ NJ peer         │  │ from cut path   │  │ non-critical    │  │ via Seattle     │  
└────────┬────────┘  └────────┬────────┘  └────────┬────────┘  └────────┬────────┘  
         └────────────────────┴─────────────────────┴────────────────────┘  
                                          │  
                                          ▼  
                              ┌────────────────────────┐  
                              │  Reducer + Validation  │  
                              │  Merge state, check    │  
                              │  invariants, confirm   │  
                              │  SLA preserved         │  
                               └────────────────────────┘

每个区域智能体是 LangGraph 状态图中一个由 LLM 驱动的节点，在一个 super-step 中并行执行。这是 LangGraph 的并行节点执行机制，它们各自的输出在下一阶段开始前由自定义 reducer 合并。

这不是简单的流水线。这是协调式的并行推理，会引入顺序系统压根不存在的故障模式。

传统测试为什么在这里失效

传统软件里测试四个并行 worker 是可控的。Mock 输入，捕获输出，assert 正确性。Worker 是确定性的同样的输入永远给出同样的输出。

但智能体不是确定性的。

达拉斯智能体可能这次决定吸收 40% 的重路由负载，下次变成 35%。从遥测数据来看都说得通因为都是合理的决策。但差异足以让任何写死精确值的断言直接挂掉。比如硬编码

assert result.load_shift_percent == 40

，下一次模型升级或 prompt 调整就会让它失败。。

更麻烦的情况是四个智能体并行跑、决策互相纠缠的时候。纽约智能体把负载转向某条通道，拉斯维加斯智能体却在同一条通道的过时利用率数据上做决策。如果单独看两个智能体都没做错什么，但放到一起它们制造了一个认为的拥塞。

每个智能体的输出看起来都是对的，但是协调出了问题。

智能体测试要捕获的正是这类故障，不是单个智能体的正确性而是集体行为的完整性。

步骤一：捕获执行轨迹

首先需要的是可观测性。看到的不能只是最终状态，还要包括完整的决策序列——每个并行智能体干了什么，reducer 怎么合并的输出。

LangGraph 的 checkpoint 机制天然提供了这些：

 fromlanggraph.checkpoint.sqliteimportSqliteSaver
 
 checkpointer=SqliteSaver.from_conn_string("incidents.db")  
 graph=fiber_cut_graph.compile(checkpointer=checkpointer)  
 result=graph.invoke(alarm_event, config={"configurable": {"thread_id": "incident-2024-0312"}})

从存储的历史记录中提取执行轨迹：

 START  
  → coordinator_analysis    [Impact: HIGH | Regions: NYC, DAL, LV, SF]  
  ┌─ nyc_agent              [Load shift: 30% → NJ peer | Rate-limit: OTT]  
  ├─ dallas_agent           [Transit absorption: 38% | Carrier notified]  
  ├─ lv_agent               [CDN rate-limit: applied | MPLS LSPs: held]  
  └─ sf_agent               [BGP MED adjusted | Reroute: Seattle path]  
  → reducer_merge           [Total redistributed: 102% ⚠]  
  → sla_validation          [SLA breached: false | Margin: 4%]  
 END

注意 reducer 中那个

102%

。这种问题只有轨迹捕获才能暴露出来。四个智能体各自基于自己对网络的局部视图做判断，集体的结果是容量过度承诺。没有哪个智能体做错了决定，但系统层面却出了问题。

设计良好的 reducer 难道不能自动阻止这种情况发生吗？

能，但是这恰恰就是重点。在 LangGraph 中自定义 reducer 就是协调约束的载体。通过条件边可以在总承诺负载超过容量时，把执行路由到重新平衡步骤，在任何实际操作执行之前拦截。

但Reducer 不只是个合并函数，它是执行层。

在 LangGraph 的并行执行中reducer 承担的角色相当于分布式事务边界，或者说是唯一一个能在副作用发生之前基于所有智能体的组合意图评估全局不变量的位置。

轨迹测试验证的是这个执行层有没有实际运行，不变量测试验证的是它有没有守住规则。

步骤二：行为不变量

不变量是结构性规则：无论底层跑的是哪个 LLM、选了什么路由、智能体之间怎么分工这些规则都必须成立，因为这些规则是由业务来定义的。

多智能体网络系统不存在一套通用的不变量。金融客户和 CDN 运营商的 SLA 承诺不同；处在维护窗口的区域和正常运行的区域约束也不同。不变量应该反映的是业务上下文不只是技术拓扑。

不过有些不变量是系统级的，对任何并行流量响应系统都值得显式定义。

不变量 1：流量在转移过程中必须守恒。

这是最底层的保障。流量从路径 X 挪到路径 Y 或路径 Z，但进入网络的总流量在重新分配前后必须相等，不能有流量被静默丢弃，也不能被重复计算。

 def invariant_traffic_conservation(pre_shift: dict, post_shift: dict) -> bool:  
     pre_total = sum(pre_shift["path_volumes"].values())  
     post_total = sum(post_shift["path_volumes"].values())  
     return abs(pre_total - post_total) <= pre_total * 0.01  # allow 1% drift

这个不变量一旦失败，问题就不只是协调错误了，要么流量被黑洞吞掉了，要么智能体在不一致的状态快照上做决策。

在智能体系统中确定性被有界变异性替代。目标不是冻结输出而是定义变异的结构性边界。

不变量 2：SLA 验证必须在 reducer 合并之后运行，绝不能在之前。

每个区域智能体看到的只是网络的局部。SLA 影响只有在四个决策合并为全局状态之后才能真正评估。在部分状态上跑 SLA 检查，比不跑还糟——它给人一种虚假的安全感。

 def invariant_sla_after_merge(trajectory: list[str]) -> bool:  
     return trajectory.index("sla_validation") > trajectory.index("reducer_merge")

不变量 3：不允许任何区域在没有有效操作集的情况下行动。

如果某个区域智能体返回了空操作，比如所有备选路径都在维护。这时系统不能静默地继续执行，必须升级给人来处理。静默的部分执行是事后复盘里最让人困惑的故障模式。

 def invariant_no_silent_partial_execution(merged_state: dict, trajectory: list[str]) -> bool:  
     for region in ["nyc", "dal", "lv", "sf"]:  
         if not merged_state[region].get("actions"):  
             return "escalate_to_human" in trajectory  
     return True

不变量 4：承诺容量不能超过可用余量。

这条直接验证 reducer 的条件边逻辑。如果各区域转移量之和超过骨干网可用容量，系统必须走重新平衡流程而不是执行已经超限的方案。

 def invariant_no_capacity_overcommit(merged_state: dict) -> bool:  
     total_shifted = sum(merged_state[r]["load_shift_percent"] for r in ["nyc", "dal", "lv", "sf"])  
     return total_shifted <= merged_state["backbone_available_capacity_percent"]

每次执行后把四个不变量全跑一遍，就是在对整个协调层做行为健康检查，而不是只看某个智能体的输出。

步骤三：基于回放的回归测试

上线半年后团队升级到了新版 LLM。单个智能体的决策质量确实提升了，但并行执行时旧金山智能体变得更激进了，比如在负载转移上承诺到更高的比例，把总利用率推过了 reducer 调优时设定的余量阈值。不变量本可以抓住这个问题，但如果升级完没人跑回放测试，它就带着隐患上了线。

LangGraph 的 checkpoint 机制让每个真实事件都成了回归测试资产。把原始输入在更新后的图上重新跑一遍，提取新轨迹然后验证所有不变量是否依然成立。

更聪明的模型可能用更短的路径达到同样的结果。但在并行协调系统中无法解释的漂移必须经过人工审查，特别是 reducer 和 SLA 验证步骤前后的变化。

回放测试的价值不只是抓住已知的故障更是建立一种信心：模型和 prompt 的变化不会在所有输出级测试的盲区之外悄悄改变系统的集体行为。

步骤四：来自真实事件的黄金数据集

真实事件里藏着你编都编不出来的边界情况：维护窗口和光纤切断同时发生了、BGP 重收敛在执行中途发生、遥测数据对一个区域返回过时结果而其他区域正常。

系统处理过的每一个真实事件都是黄金数据集的候选，这里有一个核心设计原则：不要记录每个智能体说了什么，要记录哪些属性必须成立。

黄金数据集的一条记录包含原始输入（真实遥测快照、拓扑状态、当时的策略约束）和预期行为属性：哪些不变量必须成立、哪些轨迹节点必须出现、哪些不能出现。不记录精确输出值，不记录具体路径名。

这样做的好处是数据集不会随着系统演进而过时。模型换了、prompt 改了、图逻辑重构了，数据集验证的依然是真正重要的东西不会在合理变化的部分误报。

步骤五：CI/CD 集成

智能体测试不自动化就没有意义，每次 prompt 变更、工具 schema 更新、或者切换模型版本，流水线都应该回放黄金数据集，并且在任何变更上线之前完成不变量验证。

不变量违规是硬性失败流水线直接挂掉。轨迹漂移标记出来交给人审查但不自动阻断，可接受的行为变化和真正的回归之间的判断，应该由人来做而不是流水线。

阈值问题值得提前想清楚：不是所有轨迹变化都是回归，有时更智能的模型会走一条更高效的路径。在凌晨 2:47 做部署回滚的时候再去定义什么叫"有意义的漂移"就太晚了。

换个角度想：升级路由协议之前你不会不跑回归测试，升级多智能体协调图里的 LLM 也不应例外。

步骤六：协调测试——并行系统真正出事的地方

多智能体系统里最难缠的故障不在任何单个智能体内部。它们存在于智能体之间的缝隙——并行系统比顺序系统有多得多的这种缝隙。

三种故障模式反复出现：

 ┌─────────────────────────────────────────────────────────────┐  
 │  Pattern 1: Capacity Overcommit                              │  
 │                                                             │  
 │  Each agent independently prefers the eastern backbone.     │  
 │  Reducer sums all four shifts → 105% utilization.           │  
 │  No single agent was wrong. The coordination was.           │  
 └─────────────────────────────────────────────────────────────┘
 ┌─────────────────────────────────────────────────────────────┐  
 │  Pattern 2: Stale State in Parallel Branches                 │  
 │                                                             │  
 │  NYC Agent reads backbone_utilization = 72%                 │  
 │  DAL Agent reads backbone_utilization = 68% (4s stale)      │  
 │  Both make shift decisions on different views of reality.   │  
 │  Reducer aggregates inconsistent data as if it were valid.  │  
 └─────────────────────────────────────────────────────────────┘
 ┌─────────────────────────────────────────────────────────────┐  
 │  Pattern 3: Reducer State Overwrite                          │  
 │                                                             │  
 │  Multiple agents write to a shared metric field.            │  
 │  Last writer wins → earlier, higher-accuracy data lost.     │  
 │  Downstream agents make decisions on corrupted state.       │  
 └─────────────────────────────────────────────────────────────┘

针对每种模式，要写专门的协调测试：注入问题状态，运行图，断言 reducer 和条件边正确处理了冲突。测试的不是智能体聪不聪明，而是协调层能不能在智能体产出合理但相互冲突的结果时依然执行结构性规则。

这是大多数团队在智能体测试中跳过的部分，也恰恰是造成生产事故最多的部分。

总结

至此已经搭建起了一套完整的基线：轨迹捕获、行为不变量、回放回归测试、黄金数据集、CI/CD 集成、协调测试。对于一个并行管理四座城市流量的系统来说，这是把它放到生产环境之前必须具备的测试纪律。

但这个框架还有几个没有覆盖的问题，值得明确指出。

系统对每个决策有多大信心？达拉斯智能体选了 38% 的负载吸收率，这是基于清晰遥测数据的高置信度判断，还是不确定条件下的最优猜测？如果能在决策粒度上引入置信度评分，就可以校准每一步需要多大程度的人工介入。这个在智能体操作实时骨干网流量的场景下，这一点非常关键。

混沌环境下会发生什么？遥测 API 返回过时数据，拓扑数据库落后 90 秒，某个区域智能体的工具调用在执行中途超时而其他三个正常推进。当前的测试假设环境全程配合但是生产中不会，针对智能体系统的混沌测试目前还没有成熟的标准化工具，所以只能手动进行。

传统软件里bug 是逻辑错误。代码做了不该做的事；并行智能体系统里的 bug 往往以另一种形态出现：协调漂移。

四个智能体各自推理正确，各自的决策在隔离环境下都站得住脚，但组合在一起违反了一个系统级不变量。系统平稳运行了半年某次模型升级让某个智能体的决策偏了那么一点，刚好够造成 reducer 没有拦住的容量过度承诺。

该问的问题不是"系统有没有产出正确的输出"，而是"系统有没有通过正确的协调达到这个输出，而且在模型和 prompt 持续演进的过程中，它能不能一直做到"。这是两个完全不同的问题，需要完全不同的工具。

https://avoid.overfit.cn/post/da0b85b778d24bd4b8aa8430026b37f6

作者：ravikiran veldanda

  1. 1
  2. ...
  3. 69
  4. 70
  5. 71
  6. 72
  7. 73
  8. 74
  9. 75
  10. ...
  11. 252