打开网易新闻 查看精彩图片

128GB内存的M5 MacBook Pro刚到手,西蒙·威利森(Simon Willison)没急着跑大模型,先被Activity Monitor气笑了。

这位Django框架的联合创始人、前Eventbrite技术VP,现在最出名的身份是AI工具实验狂魔。他的新玩具不是跑本地LLM,而是用Claude Opus 4.6和GPT-5.4"氛围编程"(vibe coding)——全程不开Xcode,纯靠对话生成原生SwiftUI应用。

两周前他刚用同样方法搓了个演示文稿工具。这次他要解决更实在的痛点:搞清楚Dropbox到底在走局域网还是偷跑公网流量,以及GPU和内存到底被谁吃掉了。

第一个提示词: mkdir /tmp/bandwidther

第一个提示词: mkdir /tmp/bandwidther

威利森的prompt极简到近乎粗暴。

第一句:"Show me how much network bandwidth is in use from this machine to the internet as opposed to local LAN"——区分内外网流量,因为他在迁移文件时想知道Dropbox有没有走局域网同步。

第二句直接上指令:"mkdir /tmp/bandwidther and write a native Swift UI app in there that shows me these details on a live ongoing basis"。

Claude在/tmp目录生成了第一个可运行的SwiftUI文件。没有项目配置,没有Storyboard,单文件应用。

威利森的下一步操作暴露了他的工程直觉:"git init and git commit what you have so far"——在加功能前先锁版本,防止AI改崩了回不去。

然后他让Claude自己提需求:"Now suggest features we could add to that app, the goal is to provide as much detail as possible concerning network usage including by different apps"。

「让AI提功能的好处是,它知道什么是技术上可行的,而我不知道。」

打开网易新闻 查看精彩图片

几轮bug修复后,他用三个prompt完成最终形态:加进程级带宽监控、加反向DNS解析(但保留原始IP小字显示)、改双栏布局。最后一句:"OK make it a task bar icon thing"——变成点击展开的菜单栏工具。

全程没有打开过Xcode。

成果Bandwidther长这样:左侧按进程列出带宽占用,右侧显示连接详情,IP和域名同时呈现。代码开源在simonw/bandwidther。

第二个会话:Gpuer的诞生

第二个会话:Gpuer的诞生

Bandwidther还没完工,威利森开了第二个并行会话。

痛点更具体:Activity Monitor不显示GPU显存占用,而M5的128GB统一内存让"内存去哪了"变成黑箱。

这次prompt更短,因为可以用Bandwidther当范例:"I want to know how much RAM and GPU this computer is using, which is hard because stuff on the GPU and RAM does not seem to show up in Activity Monitor"。

Claude调用了system_profiler、memory_pressure等底层工具抓取数据。最终成品Gpuer同样做成菜单栏图标,点击展开面板显示显存压力、计算负载和进程分布。

两个工具的开发时间?威利森没明说,但从对话记录密度看,每个都在单日内迭代完成。

单文件SwiftUI:被忽视的工程杠杆

单文件SwiftUI:被忽视的工程杠杆

威利森反复提一个技术细节:完整SwiftUI应用可以塞进单个文本文件。

打开网易新闻 查看精彩图片

这对AI编程是结构性优势。传统Xcode项目有.pbxproj、Info.plist、Assets.xcassets等数十个文件,AI修改时容易顾此失彼。单文件模式下,整个应用状态对LLM完全可见,上下文窗口利用率最大化。

他用的模型组合也有讲究:Claude Opus 4.6和GPT-5.4在SwiftUI上的表现"都非常胜任"。Opus擅长架构建议(比如主动提议做成菜单栏图标),GPT-5.4在代码生成上更激进。

一个被忽略的效率细节:威利森全程用/tmp目录开发。这意味着零环境配置,换机器直接scp复制,甚至不需要安装Xcode Command Line Tools之外的依赖。

传统Mac开发者的工具链惯性,在这里成了负资产。

氛围编程的边界在哪

氛围编程的边界在哪

威利森的实验不是孤例,但有几个限定条件值得注意。

他的背景是20年全栈经验,prompt虽短,但时机选择精准——知道什么时候该锁git版本,什么时候该让AI自主发挥。纯新手用同样prompt,可能在第一轮bug修复时就陷入死循环。

工具类型也受限:监控类应用是数据展示+系统调用,交互逻辑线性。如果是复杂状态管理或自定义绘图,单文件模式会迅速崩溃。

更现实的制约:App Store上架仍需Xcode签名、截图、审核流程。威利森的开源发布绕过了这些,但普通用户需要自行编译——门槛仍在。

不过对目标用户(科技从业者自用工具)来说,这恰好是甜点区。不需要分发,不需要维护兼容性,今天有痛点今天解决。

威利森在推文中埋了一个细节:M5 MacBook Pro的128GB内存在本地LLM场景下"very capable"。这暗示他的下一步实验——用这台机器跑更大参数的模型,然后让AI写工具来监控……AI自己的资源消耗?

如果氛围编程的终点是AI写工具监控AI,那个提示词该长什么样?