李开复在他的新书《AI 未来已来》里讲了一件微软旧事。
2000 年他升任微软全球副总裁，后来才知道，在他毫不知情的时候，总部一年一度的人才盘点已经把他摆上了桌面——比尔·盖茨和鲍尔默认为他最适合出任一个新事业部的副总裁。他第一次意识到：在这家公司，顶尖人才的去向不是哪个部门领导的家务事，而是最高层亲自过问的大事。
更让他震撼的是制度本身：微软每年把最顶尖的 1% 员工挑出来，不论资历，只看潜力。首席人力资源官告诉他，鲍尔默睡前的功课之一，就是几十份几十份地翻看这些人的资料，确保他们的奖励到位、能感受到最高层的关注。鲍尔默对副总裁们说过一句狠话：
排在前 1% 的人，不属于你们，属于我。我要知道他们都是谁——公司有需求时，我有权随时调动他们。
这是 30 年前的管理智慧：顶尖人才，必须由一号位亲自盯。
但注意它的实现方式——靠鲍尔默的意志力，靠 HR 一年一次的名单。一年一次，几十个人。这已经是人力注意力的极限。而一家几千人的公司里，真正的顶尖人才远不止名单上那几十个人。
李开复写道：2025 年，他在零一万物把这件事重新做了一遍。这一次，用的是「老板 AI」。
人的放纵是本能，自律才是修行。短时间让你快乐的东西，一定能够让你感到痛苦；反之，那些让你痛苦的东西，最终都能让你功成名就。低级的欲望，放纵即可获得；高级的欲望，只有克制才能达到。
——一段常被归于罗素的话
上周一个工程师跟我说：「我让 AI 写了一个模块，它给我吐了四万行代码。我看了两天，删了三万行。」
我问他：删的时候什么感受？
他说：「心疼。每一行看起来都有道理。但我知道如果留着，这个模块就死了。」
同一天晚上，我女儿问我一道数学题。她卡在第二步。我张嘴就要说「你试试把等式两边同时除以——」，话到嘴边咽回去了。我说：「你再看看题目里哪个条件你还没用上。」她想了四十秒，自己做了出来。
两件事。一个是删代码，一个是忍住不说。本质一样： 你有能力做，你选择不做。
上个月面试一个候选人。他带了一个 GitHub 项目，说「大部分代码是 AI 写的」。
我说没关系，打开看看。
代码确实漂亮。命名规范，类型标注完整，docstring 齐全，错误处理滴水不漏。如果这是三年前，我会觉得这是一个高级工程师的作品。但现在我知道，这些是任何一个会用 Cursor 的人都能产出的。AI 的默认输出就是 80 分——格式正确、风格一致、看起来专业。
我真正想看的东西，不在代码里。
上个月我们团队换了一次 agent loop。从 Claude Code 切到 OpenCode。
切换本身很轻——prompt 改改，工作流调调，两天上手。切完第三天，周一早上打开 dashboard，CI 全绿。我松了口气，泡了杯咖啡，随手点开一条 PR 的 review 记录。
空的。
再点开一条。还是空的。咖啡没喝完就放下了。
不是代码质量出了问题。是 pipeline 里有一条规则：检测注释里的 // Generated by Claude Code 标记，命中就触发额外的 AI 代码 review 流程。OpenCode 不打这个标记。于是这条规则永远不触发，review 流程形同虚设。CI 是绿的，但绿得没有意义。
一条规则，把整个团队锁死在一个工具上。不是我们选择了 Claude Code，是基础设施绑架了我们。
我在 代码是 AI 写的了，品味住在哪里 里说，品味从代码搬到了工程系统——CI pipeline、release 节奏、事故响应。但那篇文章用的词是「harness」，而且只讨论了 harness 和 agent loop 的关系。
三个月后我意识到，那个框架已经不够用了。
2026 年的前沿 Agent 系统，不再是「一个模型 + 一个循环」的结构。它是 Foundation Model、Agent Policy、Runtime 三层的协同设计。品味不住在任何一层里，它住在三层之间的契约里。
上周一个 FDE 跟我说：「我在客户现场搭一个群聊数字员工，从建账号到调通花了两天。其中一天半在处理断线重连、图片下载、消息去重这些脏活。」
我给他看了 dingtalk-opencode-tag：下载 opencode + 装 dws + 钉钉扫码授权，三步上线。跑在免费模型上，起步成本为零。
他试了一下，十分钟就通了。然后说了一句让我印象很深的话：「这不只是一个脚手架，这是一种交付范式。」
他说得对。这个项目的意义不在于它做了什么——文本对话、图片识别、文件解读，这些功能谁都能写。意义在于它 把生产环境的脏活封装成了可复制的 Harness，让数字员工的上线门槛从「一周的工程工作」降低到「三分钟的配置」。
[Read More]昨晚我用 OpenCode 在钉钉上写一个会议通知 Agent。需求很简单：查日历找到明天的会议，给参会人发一条钉钉消息。
OpenCode 读完了 DWS CLI 的 help 文档，开始生成调用代码。它要发消息，看到了三个命令：dws chat message send、dws chat message send-by-bot、dws chat message send-by-webhook。它选了 send，传了 --group 和 --text，没传 --title。
返回了一个错误：「发群服务窗会话消息失败」。
OpenCode 懵了。我也懵了。什么「服务窗」？我在发群消息，跟服务窗有什么关系？
后来我翻了 dws chat message send --help，在最底下发现了一行小字：
--title是消息标题，群聊与单聊都必填（API 强制要求；缺失时返回误导性的「发群服务窗会话消息失败」）。
平台团队知道这个错误信息是误导性的，他们选择在 help 文档里标注「误导性」，而不是修复 API 的返回。
但这还没完。OpenCode 继续工作，又遇到了第二个问题：send 命令有三个互斥的目标参数——--group（群聊）、--user（userId）、--open-dingtalk-id（openDingTalkId）。help 文档说「三者只能选其一」，但没有解释什么时候该用哪个。userId 和 openDingTalkId 的区别是什么？Agent 无从推理——它只能猜，猜错了再换。
这整个过程花了十几分钟。但这十几分钟本来不应该存在。
这不是假设场景，这是 DWS 今天的真实状态。
上周和一个做了十五年全栈的朋友吃饭。他最近从大厂出来，拿到两个 offer：一个是去创业公司做 Agent，一个是去传统企业做数字化。他选了后者，理由是「Agent 太新了，不确定性太大」。
我问他：你觉得做网站和做 App 有什么区别？
他想了想：「差不多，都是接需求、写代码、上线、迭代。」
我又问：那做 Agent 呢？
他说：「也是接需求、写代码、上线、迭代。只是交付物从页面变成了 Agent。」
他自己把答案说出来了，但没意识到这句话有多重要。
上周五晚上，我在给 ai-notepad 项目加一个功能：让 AI Agent 能自动发现并安装这个项目的 Skill。写完 SKILL.md、落地页、版本同步脚本后，我突然意识到一件事——这套流程已经不是「锦上添花」，而是应用交付的新底线。
如果你今天做一个应用，却没有提供 CLI 和 Skill，就像 2010 年做一个 Web 服务却没有 API 一样——用户（包括 AI Agent）根本用不了你。
上个月，一个做汽车零部件的朋友找我吐槽。他们花了大半年选了一个「国内最好的大模型」，又花了三个月搭了一套 Agent 系统，目标是让质检流程自动化。结果上线两周，业务部门集体退货。
原因不是模型不够聪明。是 Agent 读不懂他们的质检数据——散落在 MES 系统、Excel 表格和钉钉群聊里的检测记录，格式不统一、字段不对齐、状态不可机读。Agent 也调不动他们的审批系统——OA 只有 Web 界面，没有 API，RPA 模拟点击三天两头因为页面改版而崩掉。
他说了一句让我印象很深的话：「我们的 AI 项目，死在了数据治理和系统对接上——这两件事，跟模型半毛钱关系都没有。」
6 月 5 日，我在 Cursor 里写了一句：「帮我基于 Supabase 做一个带 AI 辅助编辑的笔记应用」。AI 读了一下，开始生成代码。我切到浏览器，打开 localhost:3000，一个能用的 Markdown 编辑器已经跑起来了。
6 月 16 日，我换成了 OpenCode，模型用 Qwen3.7-Max。代码生成质量很稳，但 Token 成本大幅下降——后面算账时会看到这个数字有多夸张。12 天后，这个应用已经上线了实时协作编辑、离线同步、四种登录方式、批注系统、CLI 工具、三种语言的国际化——总共 12,000 行生产代码，7 个数据库 migration，7 个 Edge Function。
我没写一行代码。 每一行都是 AI 写的，包括那个用 Yjs CRDT 实现的多人实时协作编辑器。
这不是一个 demo，不是 tutorial，是部署在 Docker 里、每天在用的产品。之前在 我写了一行代码，AI 写了剩下 6773 行 里讨论过 100% AI Coding 时人的角色——产品驾驶座。这篇换个角度： 哪些架构决策做对了，哪些让 AI 的效率从「能用」变成了「快得离谱」。
[Read More]