我要投稿

「想到」就能「得到」：灵光圈，把 Coding Agent 交到普通人手里

发布日期：2026-04-20 12:05:02 浏览次数： 1532

作者：极客公园

微信搜一搜，关注“极客公园”

软件形态的每一次变化，都是生产力从少数人向更多数人释放的过程。

作者｜汤一涛

编辑｜郑玄

开发一个 AI 应用需要多久？蚂蚁灵光给出的答案是 30 秒。

打开灵光，说一句「做一个溏心蛋计时器」。30 秒后，对话框里出现了一个能用的计时器，整个过程甚至比煮一颗真的蛋还快。再说一句「加上煮蛋过半时的震动提醒」，灵光又生成了一个新版本，计时器就真的调用了手机的震动马达。

过去两年 AI Coding 这条赛道爆发得凶猛。Cursor、Claude Code 这些产品让开发者的生产效率抬到了新的水位，背后是一个行业共识：代码生成（AI as a Coder）是通往 AI Agent 最有效的路径。因为代码是数字世界的通用语言，它能让大模型把模糊的「人话」翻译成能调用工具、能自我纠错的系统行动。

但这条路径有一个前提：得懂代码。而懂代码的人，在人群里永远是极少数。

蚂蚁灵光团队把这个共识又往前推了一步：底层技术的根本性突破，必然在 C 端制造颠覆性机会。如果这条路径只对 1% 的人开放，AI 的 C 端颠覆性就无从谈起。

4 月 20 日，蚂蚁灵光推出全新社区产品「灵光圈」，同时完成闪应用的核心功能升级。这组产品动作，回答的是同一个问题：

Coding Agent 要真正跑到 C 端，必须解决哪些具体的问题？

生成：从 Vibe Coding 到 Wish Coding

灵光做的第一件事，是把「做一个应用」这件事的门槛，从「写代码」换成了「说话」。

打开灵光，用户面前只有一个对话框，看不到 IDE，也不需要处理代码仓库和依赖。

说一句「帮我做个溏心蛋计时器」，30 秒后对话里出现的是一个能选熟度（全熟 / 半熟 / 流心）、鸡蛋大小（小 45 克 / 中 60 克 / 大 70 克）、能拖动调初始水温的工具。再追加一句「加上煮蛋过半时的震动提醒」，新版本就真的调用了系统级的震动马达，在手机上震了一下。

更小众的例子是「螺栓连接装配图」闪应用。打开这个应用，出现的是螺栓大径、小径、上下零件厚度、螺母高度、垫圈厚度等七八个可拖动参数，主视图全剖、俯视图、总装配高度都在实时计算。

这种专业程度，甚至可以称得上是一个能替代入门级 CAD、做装配查看的专业工具了。

灵光团队把这种交互范式叫作 Wish Coding，相比当前行业热议的 Vibe Coding，瞄准的是完全不同的人群。

Vibe Coding 加速的是程序员写代码本身，让原本就在做软件的人做得更快。它大大提高了开发效率，但 Vibe Coding 整个流程仍然需要用户知道什么是 IDE、依赖管理、环境部署，受益者始终是全球不到 1% 的开发者群体。

Wish Coding 面对的是另一个问题：剩下 99% 的人，到底有没有做软件的需求？溏心蛋计时器和螺栓装配图这两个例子，恰恰可以回应这件事。

需求是真实存在的，只是不在商业软件的辐射范围内。

商业软件的做法是先找准一个足够大的受众群体，提炼通用需求，用一个版本卖给所有人，大量真实存在的长尾需求，就被这层商业过滤器筛掉了。

Wish Coding 则第一次把「专属定制」的边际成本压到趋近于零。软件开发可以摆脱商业规模的束缚，服务一个人在某一刻的独特想法。

从产业视角看，Vibe Coding 是 AI 对软件开发「工作效率」的提升，而 Wish Coding 是 AI 对软件开发「生产关系」的重构——它改变的不是怎么写代码，而是谁有资格做软件。

交付：消费级的完成度

Wish Coding 解决的是「生成」这件事。但 AI Coding 过去两年最大的教训恰恰是，生成本身不难，难的是如何让它真正跑到用户手中。

问题出在生成之后。

消费级产品的决胜场，从 2010 年代中期开始就明确是移动端。你可以在自己身上做一次实验：今天用的十个最高频的数字产品，有几个是在浏览器里完成的？几乎都在 App 里。用户的使用习惯已经被训练成「点图标即开」——食指按在屏幕上，应用立刻响应，这是移动端消费级产品的底层契约。

奇怪的是，当下最受关注的 AI Coding 产品几乎全部把战场选在了 Web。Lovable 生成的是跑在浏览器里的响应式网页，基于 React 和 Supabase，不能提交到 App Store，也无法可靠调用手机的摄像头、推送和生物识别。Vercel 的 v0 只生成前端 UI 组件，后端要自己接。Bolt.new 用 WebContainer 技术让 Node.js 跑在浏览器里，生成的仍然是 Web 应用。

对开发者来说，Web 路线是顺手的，浏览器天生跨平台，一个 URL 就能分享。

但从 C 端用户的视角看，这条路上每一步都是流失点：需要记住或收藏 URL；需要跳出当前 App 打开浏览器；需要等加载、断网就不能用。十多年的移动互联网把用户的使用习惯训练成了「点图标即开」，响应式网页再漂亮，也是上个时代的东西。

除了用户习惯，更大的差异在于能力边界。Web 应用被浏览器沙盒限制，跟硬件其实是隔绝的。能调用的能力局限在存储 cookie、读剪贴板、弹权限受限的通知，调不动系统级摄像头、精确 LBS、陀螺仪和震动反馈。Web 路线下 AI 生成的应用，因此天然被压缩在「信息处理工具」范畴：只处理信息，不和本地硬件发生交互。

翻开任何一个手机用户的常用 App 列表，真正高频的那些类型，比如拍照识物、扫码支付、导航定位、即时通讯、健身记录，几乎全部依赖硬件调用。浏览器沙盒把这整块 C 端软件的基本盘完全挡在门外。

灵光从一开始就走了移动端原生这条路。闪应用直接跑在端侧原生环境里，摄像头、麦克风、本地存储、系统通知、LBS、陀螺仪，这些手机原生能力用户授权后都可以直接调用。做个「拍照识花」工具，它能真调起摄像头取景并识别；做个「随身备忘」，它也能调用语音识别、写入本地存储并发送系统通知。

这一层差异决定了 AI Coding 未来的能力天花板。Web 路线的 AI 应用只能做信息工具；移动端原生路线的 AI 应用，能做的是信息工具 + 本地交互工具。后者覆盖的，才是 C 端软件真正的高频场景。

还有一层被大多数产品忽略的问题：AI Coding 过去两年生成完的项目，绝大多数停留在本地跑不通的 Demo 阶段。代码写完只是走了一半路，后面还要选服务器、搭运行环境、配置域名，这些琐事的复杂度加起来经常超过写代码本身。

灵光把这些事一次性做掉了。生成即部署，不再有「部署」这个环节。平台底层内置共享数据层，创建时直接开启多人模式。一个「团建投票器」发给十位同事，所有人看到的是实时同步的数据。AI 生成物因此从个人效率工具，拓宽到了多人协同产品的量级。

端侧运行、硬件调用、生成即部署，这三件事合起来，灵光在架构层面一次性定义了一套 AI Coding 的消费级基准。在这条基准之上，AI 生成应用才有可能从程序员的玩具，变成普通用户的工具。

过去散落在开发周期不同环节的复杂工作被一次性抹平。AI Coding 在灵光这里，真正拥有了「消费级」的完成度。

生态：把 Fork 的对象从代码换成意图

一个应用被生成并分享出去后，它的生命周期才刚刚开始。而这次更新的「灵光圈」，正是承接这些创造力的社区形态。

乍一看，使用灵光圈的体验很像刷社交网络。首先是一个 Feed 流，有推荐和游戏两个分类 Tab。每一条内容都可以点赞评论和收藏。区别在于，Feed 流里推送的不是图文，而是可以直接上手用的闪应用。

每个闪应用顶部都有一个「改一下」入口，整个灵光圈的逻辑系在这个按钮上。

GitHub 当年改变软件行业的核心贡献，是建立了一套以代码仓库为单位的协作范式：你写了一个项目，我 Fork 一份，在你的基础上改，再提 PR 合并回去。这套范式极其强大，但它有一个隐含前提：参与者必须能读懂代码。

灵光把可 Fork 的对象从代码替换成了意图。你在灵光圈刷到别人做的应用，想根据自己的场景调整，用自然语言说「我想在这个基础上加一个 XX 功能」或者「我想把它改成 YY 场景用」，灵光就基于你的新意图重新生成一个完整应用。

一个合理的质疑是：这种基于自然语言的 Fork，会不会在传递过程中失真？比如原作者的意图被后续修改者理解偏了，生成出一堆似是而非的变体。

灵光的答案是一个结构化意图表示层。每个应用在生成时，就被拆解为「哪些功能模块、什么交互流程、什么数据结构」的中间表示，被平台完整保留下来。Fork 传递的是这套结构化意图，而不是一段飘在空气里的自然语言描述。每一次「改一下」，系统都能理解用户的修改意图具体对应到哪些功能模块的增删改，以及这些变更如何级联影响其他模块。这是在结构化语义空间中的编辑操作，不是文本替换。

过去两年不少产品都朝类似方向走过。Lovable、v0 都在做「让 AI 帮你写应用」，但它们都没能跑出 Fork 生态。生成完之后，那句 prompt 就被丢弃了，留下来的只是代码。用户想改，要么改代码（回到开发者门槛），要么把需求重说一遍让 AI 重新跑（结果往往跑成另一个应用）。普通用户 Fork 来的是陌生工程师写的代码，根本改不动。