上周一个 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]昨天晚上，我在 AI Notepad 里写完一篇技术笔记，点了一下「📢 发布」，3 秒后拿到一个 URL：https://hugozhu.site/notes/p/bbzH9XEA。
我把链接丢到钉钉群里。10 分钟后，同事在页面上选中一段话，点「📝 批注」写了句：「这里是不是可以加个 error handling 的例子？」这条批注没有变成一条消息淹没在群聊里——它被存进了数据库，等我对悟空说「看看读者怎么说的」，AI 就把所有批注拉出来，当作下一轮优化的上下文。
这不是一个笔记应用的 feature。这是一种新的协作范式： Agent 产物即应用，分享协作即对话。
6 月 9 日下午，我对 AI 说了一句「分析下本项目」。
4 秒后，它给了我一份完整的项目分析报告：13 个 JS 文件、6773 行代码、技术栈拆解、架构特点、功能清单。然后我说「在登录页面加个多语言切换」，它改了 3 个文件，跑了测试，commit，push，部署。全程我没打开过编辑器。
这不是一个 demo。这是一个跑在生产环境的全栈应用——带 CRDT 实时协同编辑、PWA 离线支持、三语国际化、OAuth 登录、AI 代理 Edge Function。35 次 commit，从 2 月到 6 月，每一行代码都是 AI 写的。
上周六下午，我在 GitHub 上刷到一个 5k star 的开源 CLI 工具——一个看起来挺漂亮的本地日志聚合器。我心血来潮：能不能用 Claude Code 复刻一个？
三个小时后，核心功能跑起来了。彩色输出、文件 watch、正则过滤、多源合并，一应俱全。我兴奋了大概五分钟，然后意识到一件让我心里一沉的事：
我根本不需要这个工具。
那为什么三个小时前我会觉得"做出一个这样的东西"是有价值的？
因为在我过去十几年的职业训练里，“能做出来"本身就是稀缺的。一个能从零搭出完整工具的工程师，值钱。但今天下午，这个稀缺性在我自己的笔记本上被亲手碾碎了。
[Read More]软件工程师正在经历一场静悄悄的范式革命。过去，一个工程师要成为团队中的技术骨干，往往需要五到十年的摸爬滚打——踩过无数坑，读过海量源码，在生产环境的故障中积累经验。但现在，一个善于使用 Claude Code 的工程师，可以在几个月内走完别人多年的路。这不是夸张，而是正在发生的事实。
[Read More]