标签: vibe

  • 灵光走独木桥

    声明:本文来自于微信公众号 光子星球,作者:郝鑫

    所谓的“共识”在AI赛道形成得过快。

    Vibe Coding已经翻篇,取而代之的是各种的Vibe Work。

    OpenAI将Codex整合进ChatGPT里,字节的TRAE SOLO 升级为TRAE WorkSOLO,月之暗面新推出了Kimi Work功能。

    Work模式本质是Coding方向的再一次瞄准,这些动作都在传递一个清晰信号:AI生成代码的价值,正从创造过程本身,转向创造结果对实际工作的可交付价值。工作流、生产力、重复调用,正在成为的新关键词。

    在这种趋势下,蚂蚁灵光显得尤为特殊,甚至是当前主流叙事中的一个“异类”。

    尽管蚂蚁高层在产品初期将其定位为一款效率型产品,但随着“闪应用”“灵光圈”以及“灵光闪应用创作者激励计划”的相继落地,灵光的C端属性被不断强化。

    如今,灵光圈中被高频消费的内容,大多是带有娱乐与社交属性的轻交互体验,而非真正嵌入工作流的效率工具。官方称其为,“人人可用的消费级Coding Agent”。

    另一则消息进一步坐实了灵光Coding to C的战略定位。6月9日,蚂蚁上线了新款AI产品Qmuse,该产品聚焦网页应用创作和团队协作,并严格限制商业化授权。这表明,Qmuse意在将Coding融入工作流,服务B端企业。

    简而言之,灵光更像一个AIGC内容消费平台。用户手“搓”出的游戏、工具、网页等都可视为内容供给,在灵光圈内,其他用户可自由试玩、点赞和分享。

    当其他Coding玩家致力于Save Time时,灵光则在尝试Kill Time。这条路能否走通,将取决于灵光接下来在技术与内容之间能否找到恰当的平衡。

    “4399+橙光游戏”

    打开“灵光圈”有一种梦回千禧年的错觉,扑面而来的是熟悉的4399网页小游戏和橙光网文画风。

    图片

    灵光这类应用确实降低了创作的门槛。一位拿到灵光万元大奖的文游作者表示,过去做传统文游,一个章节、几段对话就要耗费一下午,人物立绘、场景素材还需要额外找画师定制,成本高、周期长。而现在,1小时内就能完成了一款文游应用,再花几个小时迭代、优化界面和剧情体验,就能上线。

    我们观察到,灵光这类AI应用也在重塑一些用户的内容创作方式。以上述文游作者为例,她关于游戏文本、对话设置、人物角色和关卡设置都通过与AI对话完成,而且后续的游戏生成和迭代都在一个对话框内。

    但作为一个AI内容平台来说,灵光还没有完成闭环。

    灵光圈内热度最高的仍是游戏、测试、互动故事等“一次性娱乐”内容。用户第一次接触会觉得有趣,但同质化现象严重,大量“点击计分”“选项分支”类应用玩法雷同。

    用户玩过几个之后便失去重复打开的动力。缺少每日更新、进阶挑战等复玩钩子,消费行为呈现出滑动、试玩、离开的次抛特征,因此很难长期吸引用户的注意力,更何谈触发“上瘾”机制。

    如果说抖音能留住人的底层逻辑是人与人的互动,那灵光目前的生态仍停留在人和应用的互动上。AI是支撑内容消费和交互的底层技术,而非终点。

    它缺少社交关系链的沉淀,仅有基础的点赞、评论,用户间的连接依旧是薄弱的。以文游作者群体举例,他们更多把灵光作为创作工具,待作品完成后会优先发布在粉丝群、小红书等地来宣传。

    这就使得灵光很难把用户留下来,灵光通过1亿元的“创作者激励计划”来刺激内容生产,但这种靠补贴催生的生态能否持续,仍是一个巨大的问号。

    在分发闭环上,灵光并非毫无作为。用户确实可以一键将闪应用生成分享链接,对方点击后能在H5界面直接打开使用,这至少实现了“开箱即用”的传播效果,也避免了从社交App到应用商店的跳转损耗。

    但这种分享带来的闭环仍然是“半个闭环”,其症结在于分享出去的H5版本,本质上是一个体验与功能受限的轻量演示版,与灵光App内的完整功能版存在显著落差。

    比如,灵光圈支持二次创作功能,H5界面通常只支持使用,不支持创作。用户在微信里看到一个好玩的闪应用,想自己改一改、加个功能,只能再次跳转回灵光App,而跳转本身就构成额外的转化漏斗。

    灵光想要突破

    首次媒体见面会上,灵光的相关负责人曾强调,“灵光本质上解决是效率类问题,我们的产品主张,是把灵光的主轴定位在效率侧”。

    但在AI应用里做应用这件事,难免让人联想到了另一款产品——马卡龙。MuleRun负责人陈宇森代表了一部分人的看法,“蚂蚁灵光可以理解为高配版的‘马卡龙’,本质上是对生产关系选择不同。灵光的逻辑是自己做自己用,并将其视为社交网络的一部分,而MuleRun是做出来给别人用的交易市场逻辑”。

    这里先要回答一个问题,在AI应用里手搓应用是不是伪需求?

    现实的用户确实会遇到一些,现成App用不上、自己写代码不会的场景,比如,做一个聚餐AA分账的计算器,做一个倒计时提醒的番茄钟。AI生成可以在30秒内解决这些微小的、非标的需求,比去应用商店搜索、下载、注册要快得多。

    很多用户“搓”应用不是为了用,而是为了玩。比如做一个“点击小猫就会叫”的小游戏,然后分享给朋友。这种创造的快感和社交反馈是真实存在的——灵光数据中用户连续修改一百多次,就是最好的证明。

    灵光目前试图把“手搓应用”当作独立平台的核心,同时承载娱乐和效率两个目标。从需求角度看,这并非伪需求:确实有一批用户喜欢“搓一下”。

    但就现在而言,Vibe Coding To C 有着天然脆弱的一面。

    用户不是每天都需要临时应用或新奇小游戏。绝大多数需求是一次性的:生成后使用一次,或者玩几分钟就再也不会打开。平台因此面临极低的留存率和用户生命周期价值。

    很多手“搓”出来的东西,要么系统自带,要么有更专业的免费App。用户愿意用AI生成,仅仅因为懒得去下载。可一旦生成质量不够稳定、或者需要等待,这种便利就被抵消了。与此同时,用户生成的闪应用很少会成为自己的“常用工具箱”。它们不像笔记、文档、照片那样有长期价值。没有资产沉淀,用户就没有迁移成本,平台也就没有粘性。

    所以,灵光目前的情况,不在于需求是否存在,而在于:它试图用同一个产品同时满足两种弱需求,却没有为任何一种需求提供完整的分发、留存和变现系统。

    这种做法,本质上就像把本应是大平台里的一项功能,或者娱乐社区里的一种玩法,单独拿出来做了一个独立App。一家只卖“临时螺丝刀”的杂货铺,撑不起一个真正的连锁品牌。

    开放式的未来

    AI Coding的商业化整体还属于探索阶段,由于不确定性因素很多,因此很难一锤定音。

    一位AI创业者告诉我们,他现在看不到C端AI应用的盈利空间,他认为很多Coding产品对很多用户而言,没有必须存在的理由。如果是一个很实用的应用,用户都在用,那考虑盈利完全没问题。可现在用户对AI的态度可有可无,甚至连ChatGP刚需性都没那么强。

    另一位产品负责人表示,一些产品的策略是让用户相信能帮他赚钱,但前期投入就是在烧钱。“当你免费提供服务,高峰期可能涌进来几十万甚至上百万的用户,一旦开始收费,一天可能十个用户都没有了”。

    上述人士认为,无论是面向C端AI助手还是Kill Time式的Coding产品,其商业化困境都可以归结为一句话:成本结构在生产侧,而收入模式却只能依赖消费侧。

    这意味每一次生成都在消耗算力与Token,成本随用户活跃度线性上升;而收入却依赖用户有限的注意力时长、低转化率的广告点击或极少数重度创作者的付费。

    当用户把AI当作偶尔玩一下的玩具时,消费侧的变现天花板远低于生产侧的烧钱速度。基于此,许多玩家才把重心转移到了Save Time的生产力工具上,将AI能力包装成“帮用户赚钱”的故事。高价值需求带来高收入,同时cover成本。

    Sora App的关停是一个前车之鉴。它拥有顶尖的视频生成能力,却试图以“AI版抖音”的姿态切入C端市场。用户蜂拥而至是为了尝鲜生成,而不是为了消费他人生产的AI视频。当免费的新奇感褪去,平台既无法靠广告填平高昂的算力成本,也无法让用户为刷视频付费。据测算,Sora日均运行成本高达千万美元级别,而用户生命周期价值几乎可以忽略。

    OpenAI最终选择关停,不是因为技术做不到,而是因为越成功越亏损,平台经济那套模式显然失灵了。

    回到灵光,最危险的处境不是被某个单一对手击败,而是被市场从两个方向同时合围。

    娱乐侧用户想要沉浸、上瘾式的体验,他们会流向更专业的AI互动叙事平台;效率侧用户需要稳定、可靠、能嵌入工作流的生产力工具,他们会选择更加专业化的Coding产品。

    夹在中间的产品,因既要又要,也许会成为次抛玩具,用户来一次,玩一下,然后就抛之脑后。

    但灵光的优势也很明显,背靠蚂蚁,有足够资源投入支持。同时,还拥有支付宝这一国内罕见的十亿级交易生态。这意味着灵光不必像其他独立AI产品那样,从零搭建支付、信用、商家服务等基础设施。闪应用一旦与支付宝的收付款、芝麻信用、小程序、生活号等能力打通,就能进化为工具,还可以共享客户。

    用户可以用灵光生成一个活动报名页,直接完成收款;生成一个租赁协议,自动调用信用免押;生成一个门店优惠券,无缝接入商家核销系统。这种生成即交易的闭环,其他同类产品短期内难以复制。

    这对灵光来说,是一个开放式的未来,更提供了以后国内Vibe Coding的一种进化方向。

  • 安利一个11万Star的必装插件,能让你的Agent体验直接质变。

    声明:本文来自于微信公众号 数字生命卡兹克,作者:数字生命卡兹克

    最近一直在聊Agent、聊Vibe Coding。

    但是在给越来越多的朋友安利的时候,发现其实,一直有一个问题被忽略了。

    就是,真正卡住大多数人的,是自己没有一个标准的工作流程

    特别在创造一个你想要的软件或者程序的时候,没有标准流程,其实是一件非常可怕的事情。

    所以,我想给大家分享一个我自己在vibe coding的时候,一直在用的一个超好用的帮我提高Coding体验的一个插件,也基本上是我推荐所有人都必装的一个,基本上Claude Code、Codex、OpenCode、Cursor啥的全都适配,都可以装的。

    它在Github上,已经有11万的star数了。

    名字叫,Superpowers。

    图片

    GitHub 链接在此:

    https://github.com/obra/superpowers

    也是Claude官方的认证插件,上架了Anthropic的官方插件市场,安装量冲到了23万,排名第二。

    图片

    第一名就是那个大名鼎鼎的让你的设计变得更有品味的超牛逼的Skill,Frontend Design。

    Superpowers其实不太能算一个传统意义上的工具,我觉得他更应该被定义为一套指导Agent如何完成任务的系统。

    因为坦诚的讲,绝大数的Agent,在进行任务的时候,天然都倾向于拿到任务就开始写代码,会跳过设计、跳过测试、跳过 review,然后产出一坨不可维护的东西。

    而Superpowers会强行在Agent的链路里面插入一套结构化的工作流,再结合着14个skills的组合,能让你最终的任务产出质量,上升几个档次。

    图片

    我做了一张图,可以简单的让大家看看这些Skills,每个有啥用,以及是怎么组合的,不用细看,大概知道原理就行。

    图片

    所以其实可以看出来,Superpowers本质上,是一个由14个Skills组成的工作流系统,而且,这个系统,并不止可以用在开发上,因为创造一个东西的本质上都是类似的。

    都是规划 – 拆解 – 执行 – 审查 – 复盘。

    所以,你也完全可以拿来做营销方案、做PPT、做数据分析等等,基本都是相通的。

    非常的好用。

    我觉得可以先给大家看看,如果不用Superpowers的时候,我们拿Claude Code或者Codex开发产品的原生流程会是什么样子的。

    一般流程,其实都非常的简单,都是要先写需求文档,也就是做规划再开发。

    我们拿Claude Code举例子,在这里面,规划就是Plan模式。

    比如说,团队有个小伙伴跟老罗一样,有ADHD,经常看文章就很容易容易分心,最近我们就在说,是不是可以做个阅读辅助的小东西。

    就这个需求,我们打开Claude code,在对话框里面敲个/plan,进入到规划模式。

    把需求简单的描述一下,帮我做一个面向 ADHD 用户的中文网页阅读器应用。

    让他来开始去做一个计划。

    图片

    然后,他会先调研一轮,一口气甩出好几个问题让你回答,这些问题其实你会发现,他们是并行的,之间没有前后因果关系。

    图片

    比如它问我使用场景、技术栈偏好,还有要加哪些ADHD友好特性,这块我选了仿生阅读,就是加粗每个单词前几个字母,一个比较经典的缓解ADHD的方法。

    我回答了一下,然后它就直接开干了。

    几分钟之后,就直接做出来了,给了你一个东西,也没有审查啥的。

    我们现在看的话,是不是好像没啥问题?

    图片

    但,其实有大问题。。。

    因为这个仿生阅读,其实是为英语设计的。

    Bionic Reading, A New Reading Method That Stresses Letters Within Words to  Let the Brain Fill in the Rest

    英文阅读这么做没问题,但是你中文,是完全不行的话,阅读起来直接乱套了。

    原因很简单,英文单词之间有空格,能找到边界,中文字和字之间没有空格,根本找不到词的边界,效果就会很别扭。

    除了样式它不太行,它对国内用户的适配也很差。

    我们读中文,用得最多的是公众号、知乎这些平台,结果这个插件根本没法正常读取。

    跟我想要的阅读器差了十万八千里。

    不过坦诚的讲,这确实也怪不到Claude Code头上。

    因为ADHD阅读辅助本身就是个专业领域,需要做针对性的调研,还得考虑中文场景的适配、国内平台的兼容。

    它问我的那几个简单的不痛不痒的问题,就肯定覆盖不了全部需求,那也很难做出你心中想要的答案。

    而大多数的用户呢,心里也就是只有一个模糊的想法,他知道他要解决一个具体的问题,但是具体要做成啥样、该用什么路径去实现、边界在哪,大多数人,是真的想不清楚的。

    所以在非Agent的时代,我写过一篇文章,叫分享6个平时我最常用的Prompt心法。

    其中有一个Prompt心法,就是叫做苏格拉底式提问法,用一段Prompt,让AI在动手之前,先一个问题一个问题地拷打和追问你,直到把需求聊透了再开始。

    【你的问题/需求】请你在回答前,先问我问题。要求:一次只问一个问题。根据我的回答,继续追问。直到你有95%的信心理解我的真实需求和目标。然后才给出方案

    在Agent时代,其实也差不多,只不过从一个Prompt,升级到了流程中的一个Skill。

    我们再用Superpowers这个东西,再来开发试一下。

    首先自然是安装这个插件了。

    你直接跟你的Agent说一句话就行了:

    帮我下载并安装这个插件:https://github.com/obra/superpowers

    安装完以后,记得要重启一下才能生效,不是热加载。

    图片

    还是那个ADHD阅读器,我们再试试。

    一模一样的Prompt发过去。

    图片

    你就能看到,开始调用Superpowers和工作流了。

    它做的第一件事,是先问我用户会怎么用,这一步就直接解决了那些抓取不到的墙的问题。

    图片

    但跟刚才Plan模式的并行提问完全不一样,Superpowers一次只问一个问题,你答完这个,它才决定下一个问什么,就是刚才说的苏格拉底式提问,这样才能保证这些问题真的能够非常深入而不是浮于表面。

    我选了浏览器扩展,然后它又问了核心功能,到这一步的时候,我看着这些选项愣了一下,因为我自己也没那么熟,所以我说直接我都不是很了解,你去给我查一查吧。

    图片

    它就真的去查了,回来给了我一份调研结果。

    图片

    然后给了我一个建议,整理出了核心功能优先级的清单。

    图片

    比如仿生阅读,就是上次加粗前几个字母的方案,它直接标了弱但用户喜欢,还引用了研究说这玩意对ADHD用户中文阅读并没有显著的改善。

    我就继续让它帮我选了几个功能。

    之后他就继续往下拷打我,逼着我想清楚,比如目标浏览器是哪个?中文分词库有没有偏好?UI语言和风格?

    图片

    也就是逼着你想清楚。

    这个演示的项目其实不是很复杂,但是当你开发一个大型的项目的时候,你就会真正的发现,那种被拷打的汗流浃背的感觉了。

    在问题你都回答完之后,AI它也大概知道了你的需求。

    这时候,它跟Plan模式不一样的点,就是它会提出三个架构方案,每个方案的优缺点、适用场景列得清清楚楚。

    图片

    让你来挑一个,当然你也可以直接用它推荐的。

    我直接选了B,我不想要混合方案。

    然后它又让我挨个确认不同的细节。

    图片

    图片

    整体架构、功能模块的详细设计、控制面板、数据流与存储等等等等。。。。

    图片

    图片

    又一次确认的我汗流浃背,感觉到了自己在AI面前的菜鸡与渺小。

    等所有东西都确认完以后,他才终于,把整份的设计文档给写好,放在了本地。

    巨长巨详细的一份。

    图片

    所以很多朋友在开发的时候,感觉最后开发的东西不是你想要的,其实真的不是AI菜逼,是你的需求并没有说清楚。

    规划2小时,执行10分钟,我现在越来越觉得,执行真的没有那么重要,前期的规划想清楚,才是最最最最最重要的。

    我们自己做AIFUT的票务小程序的时候,其实就是因为盲目自大以及AI辅助流程不规范,很多用户需求前期没有考虑清楚就直接上线了,边界风险考虑的也不清楚,这其实就是前期的规划问题。

    图片

    所以现在我的感受是,AI来开发已经够快了,真正该花时间的地方是动手之前。

    你需要不断的被拷打,不断的跟团队分析所有的边界情况,还必须有老师傅坐镇和把关,最后才能出来一个能真正向用户交付的东西。

    说回Superpowers,第一步的规划其实就全部OK了,上面的所有的东西,其实都还只是,Superpowers流程中的第一个Skill。

    也就是brainstorming(头脑风暴)。

    对,第一个。

    设计文档确认之后,你是不是以为,它应该开始直接写代码了?

    但这个时候,第二个skill开始接入,用using-git-worktrees这个Skill,创建了一个隔离的工作区。

    就是从主分支拉出一个新分支,所有后续的开发都在这个新分支上进行。主分支的代码不受影响,新分支上不管怎么折腾都不会波及原有的东西。做完了觉得没问题,再合并回去。

    这就是做隔离,很多人都是直接就在之前的项目上改,然后没有版本隔离,就直接全部改炸了,那其实是个很不好的坏习惯。

    图片

    再接下来,第三个Skill,writing-plans skill登场了。

    注意啊,这一步依旧还是没有写代码。

    它干的事情是,把刚才那份设计文档拆解成一步一步的开发任务的清单,而且是拆成2~5分钟就能完成的开发任务清单计划。

    这个特别有意思,因为他们的目标,原话是:“让一个没有品味、没有判断力、没有项目上下文、而且厌恶测试的热情初级工程师也能照着做。”

    当时看到给我笑乐了。

    所以啊,你用了Superpowers,其实并不是只能用Claude Opus4.6,其实越是能力一般的模型,反而得到的加持会越大,这就是这个Skill发挥的作用。

    图片

    而且拆细了还有一个好处,就是每完成一个小任务就能验证一次,出了问题马上能发现,不用等整个项目写完了才发现直接爆炸了。

    这一点,到了执行阶段体现得更明显。

    这一步完事了以后,终于,要到了写代码的执行阶段。

    这时候,它会调用subagent-driven-development这个Skill。

    直接开了好几个子Agent,去做上面所有的事情。

    图片

    每个任务开发完,也不是直接就扔给你了,而是会过两道检查。

    第一轮派一个独立的审查Agent,看这个任务到底有没有按需求来,该做的有没有做到,不该做的有没有瞎加,有没有神经病一样整出一堆毫无意义的过度设计。

    第二轮再派一个审查Agent,查的是代码质量,这一轮主要就看代码写得规不规范,好不好维护。

    两道审查都不通过就打回修改,改完再审,然后如此循环,直到都通过为止。

    图片

    这10个小任务,终于开发完了,审查还没完,下一个环节,requesting-code-review这个skill会派一个最终审查Agent出来,把所有代码从头到尾通看一遍。

    之前每个任务的审查,盯的是局部,这一轮盯的是全局,看模块之间能不能集成、有没有遗漏、整体一不一致。

    图片

    最后收尾,跑一遍验证,确认所有测试通过,没有残留问题,然后把代码合并回主分支,清理工作区。

    图片

    最后,终于,做完了。

    图片

    我们看下这个阅读器的效果。

    它有两种很实用的阅读模式。

    一种是词性着色,会把名词、动词、形容词用不同颜色标出来,句子结构会清楚很多。

    还有一种模式是段落聚焦,正在阅读的这一段会被高亮,其他段落会压暗,适合读长段落,能明显减少周围文字带来的干扰,避免跑神。

    图片

    对ADHD用户来说,最大的敌人就是注意力被周围的文字分散。

    这个阅读器,就是把阅读重点变得更清楚,让该看的内容更容易被看见,周围干扰少一点,整篇读下来就不会那么累了。

    而且这次,因为用的插件方案,所以公众号、知乎这些页面全都能正常读取了。

    真的是一遍过,让我省心太多太多了。。。

    这样充分的说明了一个AI时代,正确的工作流程应该是啥样的。

    规划2小时,执行10分钟,审查1小时。

    大概就是这样。

    除了上面我提到的一些触发了的Skills,还有一些其他的我没提到的Skills,我就不详细提了,大家用的时候到时候可以自己去试一下。

    这个插件,是我推荐大家的,必装插件。

    在我心中,可能是跟skill-creator平级的必装插件了。

    相信我,绝对能大大提升你的工作质量。

    还有工作效率。