西蒙·威利森用AI写了2个监控工具，Xcode都没打开

128GB内存的M5 MacBook Pro到手后，西蒙·威利森（Simon Willison）做的第一件事不是跑分，而是嫌弃Activity Monitor太难用。这位Django框架的联合创始人、数据新闻领域的资深开发者，决定用"氛围编程"（vibe coding）手搓两个替代工具——全程没打开过一次Xcode。

这是他的第二次macOS氛围编程实验。三周前，他用Claude写过一个演示文稿应用。这次他同时开了两个会话窗口：一个给网络监控工具Bandwidther，一个给GPU监控工具Gpuer。两个应用最终都变成了菜单栏图标，点击后弹出信息面板。

Bandwidther的诞生源于一个具体困惑：Dropbox到底在走局域网还是公网？

威利森的初始提示词极其朴素："告诉我这台机器到互联网的带宽使用情况，区别于本地局域网流量。"他接着让Claude在/tmp/bandwidther目录下写一个原生SwiftUI应用，实时展示这些细节。

第一个版本验证可行后，他立刻执行了git init和git commit——"因为要开始加新功能了"。接下来的交互体现了氛围编程的典型节奏：让AI建议功能，比自己想更高效。

威利森的原话是：「让Claude建议功能的好处在于，它比我更清楚什么是可行的。」

几轮bug修复后，他又丢了三个指令过去：加进程级带宽统计、加反向DNS解析（但保留原始IP地址，用小字号显示）、改成双栏布局。最后一步是产品形态的关键转向——"做成任务栏图标，点击弹出，图标本身要简洁"。

整个Bandwidther的完整对话记录已被他公开。源码和构建指南放在simonw/bandwidther仓库。

Gpuer：当Activity Monitor看不见GPU内存时

第二个工具Gpuer的构建更加顺滑。威利森直接复用了Bandwidther的会话作为示例，提示词精简到一句：「我想知道这台电脑的RAM和GPU使用情况，但Activity Monitor似乎看不到GPU上的东西。」

技术实现上，Gpuer调用了system_profiler、memory_pressure等系统工具抓取数据。威利森特别提到，GPU和RAM上的进程信息在Activity Monitor里确实难以追踪，这是他做Gpuer的直接动机。

两个应用的共同架构选择值得关注：菜单栏图标+弹出面板。这是Claude主动建议的，威利森采纳了。这种形态对监控类工具极其合适——不占用Dock，需要时一键可达，平时隐身。

SwiftUI的单文件特性，是这场实验能成立的技术前提。

威利森在推文中强调：完整的SwiftUI应用可以塞进单个文本文件。这意味着大语言模型能直接生成可运行的代码块，开发者复制粘贴即可编译，无需在Xcode的图形界面里点点画画。

他使用的模型是Claude Opus 4.6和GPT-5.4。据其观察，两者在SwiftUI代码生成上都"非常能干"。这种能力组合——强代码生成模型+声明式UI框架的单文件友好性——降低了macOS工具开发的门槛。

氛围编程的边界在哪里

威利森的实验提供了一个可复制的模板：明确的需求描述→最小可行版本→版本控制→功能扩展→产品形态优化。全程用自然语言驱动，代码生成和架构建议由AI承担。

但他也暴露了氛围编程的隐性成本。Bandwidther的对话记录显示，"we had a bit of back and forth fixing some bugs"——几轮来回修bug。Gpuer虽然"even less prompting"，但前提是已经有了Bandwidther作为参考实现。

换句话说，氛围编程的边际成本递减。第一个工具需要建立共识，第二个可以复用模式。

更深的问题是维护。威利森把源码开源了，但氛围编程生成的代码，其可维护性取决于对话历史的完整度。没有prompt记录，后来者很难理解某些设计决策的由来。

两个工具目前都是个人用途。Bandwidther解决了"Dropbox到底在干嘛"的疑问，Gpuer填补了Activity Monitor的信息盲区。它们不需要上架App Store，不需要适配多机型，不需要考虑国际化——这些才是专业macOS开发的真正重量。

128GB内存的M5 MacBook Pro意味着什么

威利森特意提到新机器的配置：128GB统一内存，M5芯片。早期印象显示，这台设备"运行优质本地大语言模型非常能干"。

这暗示了另一个趋势：本地LLM能力与开发工具的融合。当机器能流畅跑Claude Opus级别的模型时，氛围编程的延迟和成本趋近于零。开发者可以随时开启一个AI会话，把模糊的想法转化为可运行的代码。

威利森的选择也反映了工具链的偏好。作为Python/Django生态的资深贡献者，他本可以用更熟悉的语言写监控脚本。但SwiftUI的原生体验、菜单栏集成的便利性，让他愿意踏入陌生的技术栈——因为有AI兜底。

两个应用的界面设计都遵循了"信息密度优先"的原则。Bandwidther的双栏布局：左侧进程级带宽，右侧连接详情。Gpuer同样紧凑，RAM和GPU指标并列呈现。没有渐变背景，没有动画过渡，纯数据。

这种审美选择可能来自威利森的数据新闻背景，也可能来自AI的建议——Claude Opus的训练数据里包含了大量开发者工具的设计模式。无论如何，结果符合目标：快速获取系统状态，不打扰。

开源仓库的存在让这场实验具有了可验证性。任何人都可以拉取代码，对比对话记录，复现构建过程。这比单纯的"我用AI做了个app"的社交媒体帖子更有价值——它提供了完整的上下文。

威利森没有说这两个工具是否会持续维护。氛围编程的产出常常是项目制的：解决当下问题，然后冻结。但开源之后，社区可以接手，或者fork出自己的版本。

一个细节：他在构建过程中主动要求git commit。这个习惯动作在氛围编程语境下有了新含义——不仅是对代码状态的保存，也是对AI生成内容的"批准"。每次commit都是一个检查点，确认当前版本值得保留。

反向DNS功能的实现方式体现了产品思维的介入。威利森明确要求"保留原始IP地址，用小字号显示"——他想要可读性（域名），但不放弃精确性（IP）。这种细节不会出现在初始提示词里，是迭代中浮现的真实需求。

Gpuer的动机陈述同样具体：Activity Monitor看不到GPU内存占用。这不是"我想做个酷炫的监控工具"，而是"现有工具在这个场景下失效了"。问题导向的开发，加上AI的代码生成能力，缩短了从痛点到解决方案的距离。

两个工具的最终形态都是菜单栏应用，这引发一个问题：如果威利森没有主动要求，Claude会建议同样的架构吗？从他的描述看，"at Claude's suggestion"——是的，AI主动提出了这个设计。开发者接受了建议，并补充了"简洁图标"的审美要求。

这种人机协作模式模糊了产品经理和工程师的边界。威利森同时扮演两个角色：提出需求，评估方案，细化体验。代码实现则外包给AI。对于功能明确、范围可控的工具类应用，这个分工足够高效。

但扩展到更复杂的场景，氛围编程的局限会显现。威利森的实验没有涉及持久化存储、网络同步、权限管理、错误处理等工程议题。两个工具都是只读的信息展示，不修改系统状态，不保存用户数据。

这种限制既是约束也是保护。它让单次会话就能完成交付，也让代码保持简单。如果需求蔓延——比如让Bandwidther支持流量限制，或者让Gpuer记录历史曲线——氛围编程的流畅性可能会被打断，需要更传统的工程实践介入。

威利森的公开分享风格值得关注。完整对话记录、源码仓库、构建指南，三层透明度。这让他的实验成为可学习的案例，而非不可复现的魔术。数据新闻背景或许解释了这种开放——证据链完整是专业习惯。

M5 MacBook Pro的128GB内存在这里成了一个有趣的变量。它支撑了本地LLM的流畅运行，让氛围编程不需要网络延迟。同时，监控工具本身要管理的资源——网络带宽、GPU内存——在这台机器上都极为充裕。开发者用自己的工具，监控自己的开发环境，形成一个自指的闭环。

威利森没有评价这两个工具的长期使用体验。氛围编程的产出往往停留在"能用"阶段，后续迭代取决于动力。但开源之后，它们的存在本身就构成了一个数据点：2026年初，一个资深开发者可以用AI辅助，在几小时内构建并发布两个原生macOS工具。

这个能力阈值意味着什么？对于个人开发者，它降低了工具定制的成本。对于团队，它可能改变原型验证的方式。对于平台，它增加了生态的多样性——更多小众需求可以被满足，而不需要商业化的 justification。

Activity Monitor作为被挑战的对象，其设计哲学是"通用够用"。威利森的替代工具是"专用好用"。这种分化在软件史上反复出现，但氛围编程让专用工具的生产成本骤降。未来我们可能会看到更多"我用AI写了个XX"的监控、转换、分析工具，每个解决一个具体场景。

两个工具的命名也值得玩味。Bandwidther和Gpuer，都是动词+er的后缀形式，直白到近乎笨拙。没有品牌考量，没有市场测试，纯粹的功能描述。这种命名方式本身就在声明：这是工具，不是产品。

威利森的实验结束于代码开源，而非上架销售。这个选择定义了氛围编程在当前阶段的最佳实践：快速构建，验证想法，分享知识，然后 move on。商业化需要另一套技能——定价、支持、合规、营销——这些暂时还不在AI的生成范围内。

最后的问题留给读者：当你的开发环境拥有128GB统一内存和本地运行的顶尖代码模型，你会选择氛围编程解决什么具体问题？威利森选了系统监控，你的第一个工具会是什么？