夜雨聆风有人希望稍后阅读 App 能把长文章自动发到电子书阅读器。
有人希望记账 App 每周五自动找出异常支出。
还有人只想在某个标签出现时，把一条消息发给自己。
这些需求都很合理。
问题是，每一项功能可能只有很少一部分用户需要。
开发者要为它设计入口、增加设置、处理异常、编写测试，还要在未来几年里持续维护。
最后通常只能回复一句：
已经记录，后续版本会考虑。
然后它就在需求列表里躺了几年。
但 AI 编程正在带来另一种可能。
用户不再等待开发者把功能加入下一个版本，而是直接告诉 App：
“收藏的文章超过 4000 字时，先生成摘要，再发送到我的阅读器。”
AI 根据这句话生成一段扩展逻辑，App 检查权限并运行它。
对其他人来说，产品没有增加一个多余按钮。
对这个用户来说，App 却刚刚长出了一个只属于他的功能。
如果这条路真的走通，开发者要面对一个有点反常识的问题：
未来的 App，还需要把所有功能都做完吗？
01｜开发者从来不是不知道用户要什么
很多 App 的需求列表并不短。
用户会提出：
增加一种新的导出格式； 与另一个小众服务同步； 在特定时间自动执行操作； 根据自己的规则修改界面； 为某个网站写一个特殊解析器； 在数据变化时触发一套独有流程。
这些需求真正的问题，通常不是做不到。
而是投入产出比太低。
一项功能从来不只是写几十行代码。
它还会带来新的界面、状态、错误提示、权限说明、测试用例、客服问题和兼容成本。
如果只有 1% 的用户需要，开发者很难为了它增加所有人的产品复杂度。
于是，大多数软件只能优先服务需求曲线最前面的那一部分用户。
高频需求进入正式版本，长尾需求则被放弃。
这也是为什么一个产品使用时间越长，越容易遇到这种尴尬：
它已经解决了 90% 的问题。
剩下那 10%，偏偏决定了它是否真正适合你的工作方式。
过去，用户只有三个选择：
继续等开发者实现； 寻找另一个更接近需求的 App； 自己写脚本、插件或者干脆重新做一个工具。
第三条路最自由，也最少有人走。
因为它要求用户会写代码。
AI 改变的，正是这道门槛。
02｜插件并不新，真正的新东西是“谁都能写”
允许用户扩展软件，从来不是 2026 年才出现的想法。
浏览器有扩展，编辑器有插件，游戏有 Mod，设计软件有脚本，自动化工具有工作流。
很多专业软件之所以能够服务大量不同用户，靠的正是稳定核心加扩展生态。
但传统插件仍然需要开发者。
用户必须理解编程语言、API、事件、权限和打包方式。就算只是实现一个很小的需求，也可能要先阅读几十页文档。
LLM 把编写扩展的入口，从代码变成了自然语言。
用户不再需要知道什么是回调，也不需要理解怎样发送 HTTP 请求。
他只需要描述结果：
每周一早上，把上周标记为“工作”的笔记整理成摘要，保存到一个新文档里。
AI 可以把这句话拆成：
触发时间：每周一； 数据范围：过去七天； 筛选条件：标签等于“工作”； 操作一：生成摘要； 操作二：创建文档； 所需权限：读取笔记、创建笔记。
真正的变化不是 AI 会写一段 JavaScript。
而是以前只有开发者能完成的扩展，现在普通用户也有机会创建。
软件的长尾需求第一次可能不再全部压在产品团队身上。
03｜App 会从“功能集合”变成“能力平台”
今天介绍一个 App，我们通常会列出它有什么功能。
支持多少种格式、多少个模板、多少种自动化、多少个第三方服务。
功能越多，看起来越强。
代价是设置页面越来越长，界面里到处都是大多数人永远不会打开的入口。
如果 App 能够被用户安全扩展，产品的重点可能会发生变化。
开发者不再预先实现每一种组合，而是提供一些可靠的基础能力：
数据发生了什么变化； 用户允许读取哪些内容； 可以执行哪些操作； 每个操作需要什么权限； 失败后怎样恢复； 哪些行为绝对禁止。
用户再让 AI 把这些基础能力组合成自己的功能。
例如，一个稍后阅读 App 不需要内置几十种自动化。
它只需要稳定提供：
文章已收藏事件； 标题、正文、标签和字数等字段； 摘要、分类、移动和导出等操作； 网络请求和第三方服务连接能力； 定时运行和失败重试机制。
有了这些积木，AI 才能为不同用户拼出不同流程。
这时，App 的价值不再只是“开发者已经做了多少功能”。
还包括：
它允许用户在安全边界内，组合出多少开发者没来得及做的功能。
04｜最稳妥的方案，不是直接执行 AI 写出的代码
听到“用户让 AI 补功能”，最容易想到的实现是：
用户描述需求； AI 生成 Swift 或 JavaScript； App 下载代码并直接执行。
这种方式看起来最自由，也最危险。
AI 生成的代码可能死循环、删除数据、泄露密钥、请求错误接口，或者因为一句提示词的歧义做出用户完全没想到的事。
更适合普通 App 的路线，是让 AI 生成一份声明式工作流。
例如：
{”name”: ”长文章发送到阅读器”,”trigger”: {”event”: ”article.saved”},”conditions”: [{”field”: ”wordCount”,”operator”: ”greaterThan”,”value”: 4000}],”actions”: [{”type”: ”summarize”},{”type”: ”sendToEReader”}],”permissions”: [”article.read”,”network.eReader”]}
这份 JSON 本身不会读取文件，也不会突然调用摄像头。
App 只识别自己提前实现好的 trigger、condition 和 action。
AI 的任务是把自然语言翻译成合法配置，真正的执行仍然由 App 内已经审核、测试过的代码完成。
Swift 侧可以把边界定义得非常明确：
enum ActionType: String, Codable {case summarizecase addTagcase createDocumentcase sendToEReader}enum WorkflowPermission: String, Codable {case articleRead = ”article.read”case networkEReader = ”network.eReader”}struct WorkflowAction: Codable {let type: ActionTypelet parameters: [String: String]?}struct Workflow: Codable {let name: Stringlet trigger: Triggerlet conditions: [Condition]let actions: [WorkflowAction]let permissions: [WorkflowPermission]}
模型不能凭空发明一个 readAllPhotos，因为 ActionType 中根本没有这个能力。
就算它在 JSON 里写出来，解码也会失败。
这与让 AI 随意生成并运行代码有本质区别。
一种是把整个系统权限交给模型。
另一种是让模型在开发者划定的积木中做组合。
对普通用户来说，两者看起来都像“说一句话，App 多了一个功能”。
对安全和审核来说，它们却是完全不同的产品。
05｜AI 最适合当“编译器”，不一定适合一直当执行器
如果一条规则每天运行，是否每次都要让模型重新理解一遍？
不一定。
更稳定的方式是：
自然语言需求 → AI 生成工作流 → 用户确认 → 确定性引擎执行
例如用户说：
收到包含“退款”的邮件时，把金额和订单号记到表格里。
AI 在创建阶段负责理解这句话，生成触发条件、字段提取和写入操作。
用户确认后，后续运行尽量由固定规则完成。
只有遇到必须理解语义的部分，比如判断邮件是否真的是退款通知，才再次调用模型。
这样做有几个好处：
每次运行的结果更容易预测； 不必为相同流程反复消耗大量 Token； 用户可以看到规则到底会做什么； 开发者能够记录和重放执行过程； 出现错误时，更容易判断是模型理解错了，还是执行器出了问题。
AI 并不是出现得越多越好。
在这类产品里，它最有价值的地方可能是把人的意图翻译成机器可执行的规则。
真正长期运行的部分，仍然应该尽量简单、可验证、可限制。
06｜到了 iOS，这件事先撞上的不是技术，而是审核
在 Web 或开发者自己的服务器上，运行用户生成代码主要是安全和成本问题。
到了 iOS，还要先面对 App Store 的审核规则。
苹果在审核指南 2.5.2 中写得很明确：App 应该包含在自己的 Bundle 中，不得下载、安装或执行会引入或改变 App 功能的代码。
教育类编程 App 在有限场景下存在例外，但必须让用户完整查看和编辑相关源代码，而且这些代码不能被拿去做其他用途。
所以，下面这种方案风险很高：
AI 在服务器生成 Swift → iPhone 下载 → App 动态编译或执行 → 出现审核时没有的原生功能
把 Swift 换成 JavaScript，也不代表自动安全。
审核指南 4.7 的确允许部分未嵌入二进制的软件，包括 HTML5 和 JavaScript 小程序、小型游戏、流式游戏、聊天机器人和插件。
但这是附带条件的允许，不是一张“只要使用 JavaScript 就可以动态加功能”的通行证。
开发者仍然要对其中的软件负责，还需要处理内容过滤、举报、隐私、支付、年龄分级和软件索引。
更关键的是，未经苹果许可，App 不能把原生平台 API 暴露给这些软件；涉及数据和隐私权限时，每个软件还需要得到用户的明确同意。
这意味着一个 iOS App 不能简单地给下载下来的脚本开放照片、通讯录、定位、蓝牙和文件系统，再把责任推给“这是用户生成的”。
对准备上架 App Store 的产品来说，更稳妥的方向通常是：
能力和执行器已经包含在审核过的 App 中； AI 只生成数据、规则或工作流配置； 动态配置不能突破 App 原本声明的核心用途； 每项敏感操作都有明确权限和用户确认； 审核人员能够看到并测试完整流程。
当然，最终是否通过仍然取决于具体产品和审核判断。
“声明式”不是绕过审核的技巧。
如果一份配置实际上已经变成了另一个未经审核的 App，换一个名字也不会让风险消失。
07｜macOS 更自由，但不代表可以不做安全边界
macOS 对可扩展软件更友好。
尤其是通过 Developer ID 直接分发的 App，可以设计脚本、插件、命令行工具和本地 Agent 等更开放的能力。
但如果进入 Mac App Store，App Sandbox 仍然是要求。
沙箱会限制 App 对文件、网络、硬件和其他进程的访问，开发者需要通过 Entitlement 明确声明所需能力。
macOS App 即使允许插件，也不应该把插件直接放进主进程，默认继承 App 的全部权限。
更合理的架构可能是：
把不受信任的扩展放进独立进程； 使用 XPC 传递经过定义的数据结构； 为扩展设置单独的沙箱和资源限制； 校验代码签名和扩展来源； 不把主 App 的 Token、Keychain 和文件权限直接交出去； 扩展崩溃时，不影响主 App 继续运行。
AI 降低了生成插件的成本，也会让插件数量迅速增加。
以前一个用户可能只安装几个经过挑选的插件。
以后，他可能每天都让 AI 生成一个只使用一次的小扩展。
当扩展从“少量人工编写”变成“大量即时生成”，过去依靠人工检查和社区信誉维持的安全模式，也必须跟着变化。
08｜真正难的不是生成代码，而是管理权限和后果
让 AI 写出一段自动化并不难。
难的是当它开始处理真实数据时，谁为结果负责。
假设用户提出：
把项目目录里不用的文件全部删掉。
模型如何判断“不用”？
它能否访问整个磁盘？删除前是否展示列表？能否放进废纸篓而不是永久删除？误删之后怎样恢复？
又比如：
每天把销售数据发给我的合作伙伴。
谁是合作伙伴？发送哪些字段？里面是否包含客户隐私？目标地址被修改后，规则会不会继续自动运行？
一个真正可用的扩展系统，至少需要：
权限最小化
工作流只能申请完成任务所需的最小权限，不能因为需要读取一篇文章，就拿到整个文档目录。
执行前预览
在第一次运行、权限增加或高风险操作发生前，清楚展示它准备读取什么、修改什么、发送到哪里。
资源限制
限制执行时间、调用次数、网络请求、Token 消耗和并发数量，避免死循环与意外账单。
审计记录
用户能够看到每次运行的输入、操作、结果和失败原因，而不是只得到一句“自动化已完成”。
撤销和恢复
删除、覆盖和批量修改优先设计成可恢复操作。AI 犯错时，用户不应该只能联系客服。
密钥隔离
扩展可以请求“向某服务发送内容”，但不应该直接拿到服务的原始密钥。
未来可扩展 App 最核心的工程能力，可能不是代码生成。
而是建立一个即使生成代码不完全可信，也不会轻易伤害用户的运行环境。
09｜这会变成一种新的 App 生意吗？
今天，大多数 App 通过功能区分免费版和付费版。
免费版只能使用基础功能，订阅后解锁更多导出格式、自动化数量或者 AI 次数。
如果用户能够自己生成扩展，产品的收费方式也可能发生变化。
开发者可以提供：
免费的稳定核心； 更高的工作流数量和运行频率； 云端执行和跨设备同步； 更强的 AI 生成与调试能力； 面向特定职业的扩展模板包； 团队共享、权限管理和审计； 经过审核的扩展市场； 本地运行和隐私增强方案。
过去，用户为开发者提前做好的功能付费。
以后，用户可能为“让软件适合自己”的能力付费。
这对独立开发者反而可能是机会。
小团队很难与大公司比功能数量，却可以把核心体验和扩展边界做得更清楚，让用户自己覆盖长尾需求。
产品不需要提前猜中每一种使用方式。
它需要提供足够好的积木，以及一个不会把用户数据和设备一起炸掉的组合环境。
10｜开发者不会消失，但工作重点会改变
如果用户能让 AI 自己补功能，开发者是不是只要做一个空壳就够了？
恰恰相反。
一个可以安全扩展的核心，通常比堆出一批固定功能更难设计。
开发者需要决定：
哪些事件可以被监听； 哪些数据可以被读取； 哪些操作可以被组合； 权限怎样申请和回收； 工作流如何迁移和兼容； 错误怎样展示和恢复； 生成内容如何审核； 第三方扩展如何签名和分发； App 更新后，旧扩展怎样继续运行。
以前，开发者主要实现功能。
以后，开发者还要设计功能能够被安全生成的边界。
这有点像从建造每一间房，变成先制定建筑规范、准备水电接口和承重结构，再允许用户调整内部布局。
核心做得越稳定，用户扩展的空间才越大。
所以，“App 不需要把功能做完”并不等于“可以发布一个没做完的 App”。
它真正表达的是：
开发者必须把核心、权限和扩展能力做完整，但不一定要亲手实现所有长尾功能。
过去，一个用户提出小众需求，只能等待产品团队判断它值不值得排期。
现在，AI 开始让用户自己跨过这段等待。
他不需要成为程序员，也不需要重新做一款 App。
只要产品提供足够清晰的事件、操作和权限边界，一句话就可能生成一项只为自己存在的功能。
这条路离成熟还很远。
iOS 审核、动态代码、安全沙箱、隐私授权、扩展分发和错误恢复，每一项都比“让模型写段代码”困难得多。
但方向已经值得独立开发者提前思考。
未来衡量一个 App 是否强大，可能不再只看它已经做了多少功能。
还要看：
当开发者没有做某个功能时，用户能不能在安全范围内，让它自己长出来。