内容创作者变身App开发者：Vibe Coding如何重塑软件生产

从测评App到制造App：一股正在蔓延的创作者趋势

在科技内容圈，一个耐人寻味的转变正在发生：那些常年测评、推荐、吐槽App的YouTuber和播客主，开始亲手做App了。The Vergecast主持人David Pierce将这种现象称为「创作者成为应用开发者」——尤其是生产力工具领域，很多人多年来抱怨没有一款待办事项App完全符合自己的需求，如今他们借助Codex、Claude Code等工具，把自己的价值观直接写进了软件里。

本期节目嘉宾Stephen Robles是这一趋势的典型样本。他是Mac Power Users和Primary Technology等播客的联合主持人，也是苹果Shortcuts自动化领域的深度玩家。Robles的路径很有代表性：先是用AI「玩票」式地做了一个找咖啡店的App，验证「vibe coding能否让App上架」，随后逐步深入到真正有人付费使用的生产力工具Can Do。

Pierce在节目中的判断很直接：这不一定会带来更好的软件，但确实带来了更多软件，而且改变了创作者把想法变成产品的方式。

两种App，两种责任边界

Robles目前维护着两类截然不同的应用，他对两者的责任感也完全不同。

一类是解决单点问题的小工具，例如Leveler（把播客录音的音量自动拉平）和Captioner（批量为Reels添加动态字幕）。这类工具往往从第一个提示词到上线只需两小时，免费且开源。Robles说，做Leveler是因为自己每次从Riverside下载视频后都要手动调整音量，干脆把「原始音频」和「修好的音频」一起丢给Claude，让它照着重建一个音频引擎，二三十分钟就跑通了。

另一类是Can Do——一款带有看板视图、支持富文本笔记和附件的新型待办事项/视频项目管理工具。它的起点是Robles对苹果Reminders看板视图的喜爱与不满：够快、够原生，但缺少富文本笔记和多附件支持。他先做给自己用，后来在Shortcuts社区放出TestFlight测试版，反馈意外地好，于是决定继续投入。

两款App的责任重量完全不同。免费开源工具出了问题，用户可以直接fork；而Can Do承载着用户迁移整个工作流的期望，这让Robles感受到「一个非开发者」的压力。他最终选择以3美元一次性买断的方式定价，一方面是回收约1000美元的token成本，另一方面是有意设置一道门槛，避免反馈量爆炸。他坦言，很多人希望改成免费加内购，但他「其实不想要那么多反馈」。

Claude Code实战：一个周末做出能上架的App

Robles的AI编程工作流已经相当成熟。他的首选是Claude Code（配合Fable 5.1模型），而非Codex。理由很具体：Claude生成的UI更符合他的审美，不需要反复叮嘱「按钮周围多留点内边距」；而且由于长期在同一批对话里迭代，Claude已经积累了大量上下文，一个小提示词就能触发一连串正确的改动。

更关键的是，他把App Store Connect的API密钥和Cloudflare账户都交给了Claude。这意味着从写代码、打包DMG、上传网站，到生成App Store截图、填写更新日志，整条发布流水线都可以在一个窗口内完成。他描述过Claude自动打开模拟器、自行截图的过程，认为这部分「管道工作」交给AI效果出奇地好。

bug反馈的处理方式也极具个人风格：用户在社交媒体上提需求，他用一个Shortcuts自动化把截图收进桌面文件夹；坐到Mac前，把所有截图一次性丢给Claude，说「这是大家在抱怨的东西，修一下」。他还有一位忠实用户每周发来长长的bug清单，他全选、粘贴、让Claude分析哪些可修，然后一句「行，去做吧」。

这套流程并非没有翻车时刻。Robles提到一次「灵魂暗夜」：为了给Can Do接入Siri AI相关功能，Claude反复坚称功能已内置，但他在手机上实测就是不生效，相当于被AI「煤气灯」了一回，最后靠听众发来的指令文件才解决。iCloud同步和App Intents这类复杂集成，仍然是vibe coding的难点。

vibe coding 是 Andrej Karpathy 于 2025 年初提出的说法，指开发者用自然语言向大模型描述意图，由模型生成或修改代码，人主要扮演「描述需求—验收结果」的角色，而非逐行审阅实现。它与传统「AI 辅助编程」的区别在于信任边界：后者把 AI 当补全工具，人仍掌握代码结构；前者允许人在不理解 SwiftUI 细节的情况下交付成品，因此调试往往发生在「行为层」而非「语法层」。这也解释了文中 Robles 自称「看不太懂这些 App 的 SwiftUI 代码」却仍能上架的现象——他的能力从写代码转移到了拆解需求、组织上下文和验证结果上。

App Store Connect API 是苹果为开发者提供的 REST 接口，覆盖应用元数据、版本构建、截图素材、审核状态与销售报告等管理动作，需用 App Store Connect 后台生成的密钥（Issuer ID、Key ID 与 .p8 私钥）做 JWT 鉴权。把这类密钥交给 AI 代理意味着发布流程中的「管理操作」也可被脚本化：上传构建、切换构建版本、填写更新说明、提交审核都可自动化。它的风险同样直接——密钥泄漏等同于账户控制权外泄，因此实践中通常配合最小权限角色和独立的 CI 凭据，而不是长期使用主账号密钥。

快捷键、Siri AI与App：三者边界正在重划

作为Shortcuts领域的权威，Robles对「什么该做成App、什么该做成快捷指令、什么交给Siri AI」有一套正在成形的判断。

他的观察是，Siri AI已经吞掉了一批他曾经常用的快捷指令——比如从截图中批量解析日历事件，或者识别Instagram截图里的YouTube视频并跳转。但快捷指令仍有不可替代的位置：他每天制作Primary Tech Daily时，后台跑RSS聚合的正是一个快捷指令；给Pierce做的「一键复制最新播客在各平台链接」也依然是快捷指令的典型场景——让Claude来做这件事，反而要空转五分钟。

而App的价值在于需要UI的地方。给Reels加动态字幕，涉及字体、位置、颜色，这些必须由界面来承载。Robles的划分逻辑由此清晰：需要人做视觉决策的，是App；需要稳定、可重复、后台执行的，是快捷指令；一次性的、语义明确的，交给Siri AI。

Pierce补充了一个更宏观的视角：这三种形态未必在融合，反而可能进一步分化—— bespoke软件负责「我反复做同一件事」，快捷指令负责「用积木拼装其他软件」，而AI从零生成适合处理那些一次性、探索性的任务。每个人都得重新决定自己生活的哪部分该放进哪一类工具里。

App Intents 是苹果自 iOS 16 起推出的框架，用来把 App 的能力以结构化方式暴露给系统，使动作可被快捷指令调用、被 Siri 语音触发，并出现在聚焦搜索与系统级建议中。它与旧版 SiriKit 的关键差别是：意图由 App 自己声明参数与返回类型，系统负责语义匹配和参数填充，因此同一套定义能同时服务语音与自动化两个入口。对独立开发者而言，App Intents 几乎是「被系统看见」的唯一正道；但它的调试链路跨进程、跨系统服务，错误往往只表现为「说了没反应」，这正是文中 iCloud 同步与 App Intents 成为 vibe coding 难点的原因——模型难以从报错信息反推真实故障点。

创作者的飞轮，还是更多软件？

Robles并不把自己称为「App开发者」，他的自我定位是「App项目经理兼vibe coder」——他看不太懂这些App的SwiftUI代码。他也不打算放弃Shortcuts这个主业，反而看到了一个飞轮：自己做的App可以内置快捷指令动作，然后他在视频和播客里演示这些动作，再反过来带动App的使用。

他对未来的判断带着一种朴素的乐观：五到十年后，自制软件会变得如此容易，不只是创作者，普通人也会开始做。他甚至开始用LM Studio跑本地模型来省token，并做出能调用本地模型的快捷指令，认为这打开了又一扇门。

Pierce的总结更锋利一些：过去那些靠卖课程从社区变现的人，如果转而做软件，在很多方面反而是巨大的进步。而App开发成为创作者身份的核心组成部分，可能是他没有预料到的变化。

无论这个趋势最终沉淀为更好的软件生态，还是仅仅制造出更多长尾工具，有一点已经确定：写代码不再是门槛，判断做什么、为谁做、以及是否愿意为用户体验负责，才是新的分水岭。