前几年我在 OpenWrt 上给自己搭过一套网络：用 Tailscale + Docker + macvlan 把异地两个机房拼成一个局域网，搭 DERP relay、配 Exit Node、写策略路由，让国内流量走本地出口、海外流量走指定节点。每一次都能跑通。我还在 Tailscale 是事实上的个人弹性云基础网络 里得意地总结过这套玩法。
但有个问题一直没解决：这套网络的知识，全在我脑子里。哪条路由为什么这么走、哪个节点的密钥什么时候过期、改哪一行会把我自己的管理连接切断——没有一样写在设备上。我一旦忙别的，它就成了一个谁也不敢碰的黑盒。
一个没有网络工程师的中小公司，遇到的是同一件事的放大版：设备足够复杂，人又不够专业，网络一出故障，只能干等外援。
这篇想说的是：大模型正在改变这个前提——它把「必须有个懂网络的人」这个约束，换成了「必须有一台 AI 能安全运维的设备」。
上个月，一个做消费品牌的朋友找我聊他们的 AI 项目。
他们花了三个月，让技术团队给 CEO 做了一个「数字分身」——能模仿 CEO 的语气给全员发周报、回答战略问题、甚至在新人培训里做公司介绍。演示那天，CEO 本人看了都觉得「挺像我的」。
然后他问了我一个问题：「这个东西，除了我自己觉得好玩，到底该给谁用？」
我说：你做了一个 分身，但你需要的是一个 员工。
他愣住了。
这不是个例。我观察到大量企业在启动 AI Agent 项目时，第一步就搞混了这两个概念——不是因为技术理解不够，而是因为 没有想清楚锚点在哪。
去年底，钉钉内部发生了一件事。一个做智能客服的产品经理发现，他给企业客户做的 AI 解决方案，从需求确认到方案交付平均要 14 天。他拉了一下链路：客户提需求给销售（1 天）→ 销售转给解决方案团队（等 2 天）→ 解决方案写 PRD 转给产品（等 1 天）→ 产品评审排期（等 3 天）→ 技术实现（5 天）→ 交付验收（2 天）。14 天里，真正在"干活"的时间不到 5 天，剩下 9 天全是等待——等人、等审批、等排期、等信息同步。
他跑去找他的主管说：“我们给客户做 AI 提效工具，但我们自己的组织效率，比客户还低。”
这句话刺痛了人。但更刺痛的是——这不是钉钉一家的问题，这是几乎所有想做 AI 转型的公司都会撞上的墙。不是不知道终局应该长什么样，而是不知道第一个可用版本怎么做——像做产品一样，先跑起来，再迭代。
[Read More]