爱意满满的作品展示区。
FlyingClive

最近在做一个用自然语言生成 Mac 原生小应用的工具,想听听大家意见

  •  
  •   FlyingClive · 13h 0m ago · 487 views

    最近在做一个 Mac 应用,叫 Vaela 。

    它的目标是:让用户用自然语言描述需求,然后在本地生成一个真正可运行的 SwiftPM + SwiftUI macOS 应用。

    我发现有很多软件需求其实很小、很个人化,不太适合做成传统产品。比如:

    • 给自己用的记账 / 发票 / 报销小工具
    • 按公司格式生成周报、日报的小应用
    • 本地数据管理工具
    • 家庭 / 个人工作流工具
    • 只给自己用、不要账号、不要云同步的工具

    这些东西如果专门找人开发不划算,自己写又太麻烦,用现成软件往往又不完全贴合。

    Vaela 的思路不是直接让 LLM 一把梭写代码,而是先生成 spec 文件,比如:

    • APP.md:这个应用解决什么问题,有哪些功能
    • DESIGN.md:界面结构、交互方式、视觉风格
    • MACOS.md:作为 macOS 原生应用如何构建、运行、导出

    然后再根据这些 spec 生成 SwiftUI 项目,并在本地 build / run / verify / export 。

    个人觉得,未来一部分软件可能会有点像 3D 打印:

    以前分发的是 app 本身; 以后有些场景里,可能分发的是一份“软件蓝图”。

    用户拿到蓝图之后,可以让自己的 LLM 和本地环境重新生成,按自己的需求修改,再构建出一个适合自己的版本。

    当然,这不适合所有软件。复杂系统、多人协作产品、安全要求很高的软件,还是需要传统工程体系。但很多个人工具、内部小应用、长尾需求,可能会被这种方式改变。

    现在比较想听听大家的看法:

    1. 这种 spec-first 的生成方式有没有意义?还是说直接 prompt 生成代码就够了?
    2. 如果底层能力来自 coding agent ,那么把体验、流程、构建验证和本地项目管理做好,大家觉得有没有价值?
    3. 对本地原生 Mac app 有没有执念,还是 web app 就够?
    4. 如果是 AI 生成的软件,大家会关心哪些验证 / 安全步骤?
    5. 你会更愿意分享 app 本身,还是分享生成 app 的 spec ?

    目前还在早期阶段,主要想先验证这个方向是不是有价值。 欢迎拍砖。

    下载地址: https://usevaela.com

    5 replies    2026-06-16 21:02:34 +08:00
    weixind
        1
    weixind  
       12h 51m ago
    其实大家对 AI 时代后续的发展都拿不准。

    但是,你这个有点过于直面 codex 、trae 的市场了吧,直接硬碰硬。是不是尝试下大厂看不上的细分市场好一些。
    lingyired
        2
    lingyired  
       12h 46m ago
    其实我最近也在做类似的东西,就是允许用户通过 AI 生成一些组件或者插件。最近也在思考这个。

    spec-first 这些我觉得是对于 cc 和 codex 这些 AI 助手来说是必须的,但是对于用户来说是非必需的,因为我自己使用的过程发现,实际上我让 AI 生成的各种 spec 文件,我似乎都很少详细的去看,因为实在是太多的。所以我觉得可以生成 spec 文件,但是这些是不需要默认给用户看的。

    我觉得可以类似 superpowers 那样,根据用户的输入,提供给用户几轮简单的回答,然后生成 spec 后,根据 spec 文件再去生成一个简单的总结(可能就是一个功能列表,不要过长),如果用户有需求再可以去打开 spec 来看。

    关于第二点,因为我是生成我 APP 的插件的,所以我前期打算把插件的开发抽离成一个 SKILL ,提供给用户,让用户自行用他们熟悉的 AI 助手去生成,当然这也意味着前期只有熟悉 AI 助手的用户才有能力去做这件事。我也在思考如何接入本地或者远程的 AI 助手。

    关于第三点,都有市场吧,有的是面向桌面原生的功能,这种肯定不是 web app 可以完全实现的,要么就是 electron 之流,但是都 AI 了我感觉就没必要 electron 了,太重了。

    第四点,其实主要是 AI 生成的 APP 或者插件并不是经常可以一步到位的,最主要是普通用户如果没有编程的经历的话,他们如何后续进行迭代以及提供信息给回 AI (开发者知道如何拷贝 LOG 和定位之类的),然后就是生成的软件的归属。另外一个就是比较在意的安全性的,对于这类型的工具,我会倾向于相信开源的或者大厂的。
    lingyired
        3
    lingyired  
       12h 43m ago
    其实我也感觉到你这个东西有点像 codex 那种了,因为太泛了,如果改为比如生成 chrome 插件之类的,范围缩小一点可能好一些。

    我还想到,如果是 Mac app 的话,它的打包是否需要依赖 xcode ?(非 iOS/Mac 开发者不懂)
    FlyingClive
        4
    FlyingClive  
    OP
       3h 52m ago
    @weixind 有道理~
    FlyingClive
        5
    FlyingClive  
    OP
       3h 42m ago
    @lingyired 同道中人,我的想法也不是把 spec 直接暴露成普通用户,而是把它作为 AI 和系统内部使用的软件蓝图,有这种方式让复制和 remix 软件更容易一些。用户默认看到的应该是功能摘要、权限说明、变更计划这些更短的信息。

    范围这点其实没太想好,这个缘起是我想给我自己弄一个 20 分钟提醒远眺的工具哈哈。Codex 对普通人来说还是太重了。我倾向于把切入口定义成“生成个人化的本地 macOS 小应用”,尤其是菜单栏工具、本地数据工具、文件处理工具、个人工作流工具这些 Web App 和浏览器插件不太舒服的场景。

    后续迭代我觉得是关键,应该由工具自动收集当前 spec 、文件结构、构建日志、运行错误,再交给 AI 修复。也就是说它不能只是一次性的生成器,还要负责维护和再生成。

    打包这块,会依赖 Xcode Command Line Tools ,用户不需要懂 Xcode ,只需要看到运行、验证、导出几个动作。复杂签名和上架不打算做还。
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   1540 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 16:44 · PVG 00:44 · LAX 09:44 · JFK 12:44
    ♥ Do have faith in what you're doing.