温室与镜头：Agentic AI 的两种工作模式
温室和透镜都依赖阳光，它们的作用完全相反。温室能把环境热量困住并储存起来，所以里面的一切都比外面生长得更快：花、草药、杂草，土壤里的各种东西。透镜将同样的光集中在一个点上，直到那个点燃起火。人们聚集能量，让一切同时生长，分散且略显混乱。另一个是你设计的离散事件：瞄准、聚焦、保持稳定、点火。 起初，我以为这两种模式对应了软件工程的体验：初级工程师住在温室里，随意种植杂草和花朵，而高级工程师则一次只聚...
Aaron Brethorst
Aaron Brethorst 的个人网站——西雅图人，技术领袖，摄影师，交通爱好者。
评论
点赞
收藏领域专长始终是真正的护城河
核心看点：当AI能自动写代码后，最值钱的能力不再是"能不能写出来"，而是"能不能判断对不对"。作者用两个生动对比阐明新格局：不懂编程的物流调度员能一眼看出AI生成的排班违法，因为十年一线经验给了他们"正确直觉"；而擅长架构的通用工程师面对陌生领域，AI能编出语法正确、测试通过但业务上完全错误的代码，他们却无从判断。AI工具让工程师花多年练就的"想法转代码"能力迅速贬值，却没有给领域专家一条学会编程的等价路径。作者断言，当下最稀缺的人才是兼具两者——既懂代码质量又懂业务正确性，能做双层验证。给工程师的建议很直白：别再只卷框架和语言，去深耕一个具体的行业、流程或监管领域，把领域模型建进脑子里，这才是AI无法替你做的事。
用 Claude Code 生成用户故事，改变品质的经济学
AI 编程中常常被忽略的"技能"（skill）功能，到底能带来什么实际价值？作者用自己的亲身实践给出了一个具体答案：使用 Claude Code 官方的 skill-creator 工具，在 OneBusAway 车辆位置项目中快速搭建了一个用户故事生成器。skill-creator 几分钟内就能生成 结构、推荐所需工具权限并提供安全护栏，降低了高质量用户故事的编写门槛。本文延续了作者此前关于"技能是 agentic AI 最被低估特性"的观点，记录了一次真实可复用的开发实践，对关注 AI 辅助编程的开发者有直接参考价值。
技能：智能体AI中最被低估的功能
代理技能是包含指令、脚本和资源的文件夹，代理可以根据需要自行发现并使用这些内容。它们是一种开放标准，可在 Claude、GitHub Copilot、VS Code、Cursor 以及 OpenAI 的 Codex 等工具中通用。一个技能只是一个目录，其根目录下有一个 文件，可选地附带脚本、参考文档和模板。仅此而已。无需微调、无需重新训练模型、也无需进行 API 集成工作。你只需用 Markdow...
项目不是宠物，而是牲口
一个好记的管理隐喻：「项目不是宠物，而是牲口」。作者分享自己从创始人到工程经理转型中的真实挣扎——本能地想亲力亲为、摸清每个细节（当宠物养），但管理者真正该做的是完成、自动化、委派或取消（当牲口管）。文章快速区分了 Staff Engineer 可以保留「宠物项目」而管理者不行，并给出了一个简洁的决策框架。短而有个人经验痕迹，有明确立场，不是空泛管理鸡汤，适合工程管理者对照反思自己的项目管理方式。
等距纽约：用真实地图打造《模拟城市2000》风格的纽约市
作者对AI与创造力相关的常规讨论感到厌倦，转而聚焦一个更值得追问的问题："现在有哪些以前做不到的事情成为了可能？"以此引出了Andy Coenen的Isometric NYC项目——用纽约市五个行政区的真实地图数据，生成类似《模拟城市2000》风格的等距视角城市渲染。这不是一篇技术详解，而是一段带着明确个人趣味的推荐：既有对空洞趋势讨论的厌倦，也有对新事物具体可能性的好奇。适合对创意工具、城市可视化或"技术还能做什么"感兴趣的读者点开一看。
华盛顿州立法机构运作方式
本文以惊人反差开场：华盛顿州经济体量超过阿根廷或瑞典，坐拥全球市值最高公司中的两家、主要航空制造商、全美第七大集装箱港和140亿美元农业，州政府每两年管理780亿美元预算——而这一切由兼职立法机构运作。作者是个人博主，计划撰写系列文章深入解析州政府实际运作机制。区别于机构通稿或泛泛科普，本文以个人视角、一手观察和具体数据切入，揭示"兼职议员管理超级经济体"这一独特话题，对关注美国政府运作、公共管理或比较政治的读者具有真实信息增量。系列开篇定位清晰，后续内容值得追踪。
用"氛围编程"写了个MDM
作者身为家长，想控制孩子设备使用，索性用"氛围编程"（vibe coding，即靠AI辅助直接写代码）自己动手搓了一个MDM（移动设备管理方案）。这不是教程，而是一篇夹带个人实践、育儿需求和行业观察的随笔：软件开发方式正在根本性变化，AI让非专业开发者也能造出可用的工具。作者引用Kurt Mackey和Simon Willison的观点，认为我们正逼近软件生产范式的转折点。有人味、有真实场景、有立场，不是空泛趋势解读。
The First Telegraph
What hath God wrought Samuel Morse - First telegraph message, May 24, 1844 On May 24, 1844, Samuel Morse tapped out this message from the Supreme Court Chamber in the Capitol to his partner Alfred Vai...
华盛顿州应立法允许阳台太阳能系统
华盛顿州众议员预提交 HB 2296 法案，拟合法化"插电式阳台太阳能"系统，让租房者和公寓业主也能安装太阳能。作者明确支持该法案，指出其借鉴了去年在犹他州全票通过的 HB 340 并有所改进。阳台太阳能系统构成简单：一块标准太阳能板、一台专用微型逆变器和一个插入普通墙壁插座的插头。德国已有大量应用，但华盛顿州至今仍不允许。如果通过，将大幅降低租户和公寓业主使用太阳能的门槛。
给害怕 Git Rebase 的人
OneBusAway 项目维护者 Aaron Brethorst 用亲身经验安抚开发者对 Git rebase 的恐惧。他指出，贡献者一听到 rebase 就犹豫甚至害怕是常见现象，网上那些吓人的警告更是雪上加霜。但真相是：rebase 搞砸的最坏结果不过是删掉本地克隆重新来过——远程 fork 和主仓库都完好无损。文章从维护者视角给出务实心态，帮助开发者放下心理包袱，是一篇有真实项目经验、有人味的技术短文。
志愿者开源项目教会我的远程团队管理之道
本文作者在过去一年领导 OneBusAway 服务器重写项目 Maglev（Go 语言，完全替代已有十年历史的 Java 版），团队几乎全是志愿者，跨西雅图、欧洲、亚洲时区，无人领薪、无人保证可用性、随时可能因本职工作或兴趣消退而消失。在这种极端约束下，他总结出六条对任何分布式团队都有借鉴意义的管理经验：1）用专用 Slack 频道做异步站会，持续追问而非催促；2）关键路径任务必须交给有稳定贡献记录的核心成员，新人先做非阻塞任务证明自己；3）必须有全员读过且认同的书面愿景文档，否则跨时区协作会导致方向分歧和重复劳动；4）尽快做出可自用的版本，让每次 PR 都针对真实 GTFS 数据测试，贡献者看到自己的代码跑在真实服务中远比看测试通过更有动力；5）每个决策都必须记录在 GitHub Issue 或 Wiki 中，六个月后有人问"为什么这么做"时能给出链接而非口头传说；6）接受一定程度的失控，志愿者犯错时首先反思自己作为维护者是否没沟通清楚。作者认为志愿者场景只是放大了远程团队的固有缺陷，这些做法对任何远程团队（无论是否付费）都同样有效。
管理工程危机的"奇招"：利益相关者为何买账
作者以亲身经历分享工程团队陷入多重危机时的应对策略。核心不是常见的"全都做"或"优先级排序游戏"，而是三类动作的组合拳：快速战术胜利（可完成的短期修复，如加缓存、打补丁）先建立信任和可见成果；战略性投资（消除整类问题，如重新架构）并行推进以根治根源；最关键的一步——对利益相关者彻底透明，坦诚沟通取舍逻辑和原因。作者用真实案例说明，当利益相关者理解你为何这样排序时，他们会从资源竞争者变成协作伙伴。文章有具体方法、真实踩坑经验和可复用的沟通框架，适合技术管理者、团队lead和任何需要协调多方需求的工程负责人阅读。
瞬时速度是个陷阱
技术债务的一个更精准比喻：瞬时速度 vs 平均速度。作者亲身经历了一个"看起来极快"的项目——每个冲刺准时交付、每次演示惊艳众人——但18个月后代码库崩溃，添加简单功能需要数周，新人要数月才能上手。他把这归因于团队只优化了"瞬时速度"（当下产出），牺牲了"平均速度"（长期可持续性）。跳过测试、复制粘贴代替抽象、硬编码替代设计，每个短期决策在当下都合理，但它们像沉积物一样累积，最终让系统近乎不可维护。文章给出了工程管理者真正需要的实操建议：有意识地管理技术债务，把偿还债务作为团队常规节奏而非奖励行为，定期审视当前速度是否在透支未来。不是反对快速交付，而是要求做出清醒的选择并制定还款计划。有亲身经历、有新鲜视角、有实用框架，工程管理者值得一读。
Swift for Android 注定成不了气候
老开发者 Aaron Brethorst 凭二十年观察断言：Swift for Android 不会成功，不是技术不行，而是跨平台方案永远遵循同一剧本——初期美好、逐渐采用、最终陷入 interop 维护泥潭。他拿出实际代码展示从 Swift 调用 Android 的 JNI 惨状：UnsafeMutablePointer、手动指针操作、@_cdecl 装饰器塞包名进函数签名，连维护跨平台框架、本应受益的 Joe Masilotti 试完都说"不如直接写 Kotlin"。更致命的是生态：25% 的 Swift 包能编译，但 Google Pay、CameraX 这类关键库是 Kotlin 的，Core Data 在 Android 不存在，你实际上还是得写 Java/Kotlin 处理持久化和 UI，背离了用 Swift 的初衷。Apple 没动力维护 Android 支持，Google 全力押注 Kotlin，谁都不帮你。调试跨 runtime 边界的问题、版本永远落后、技能栈反倒更复杂——最终结论：write once, debug everywhere，慢慢意识到当初该写原生代码。
工程管理者应该（偶尔）写代码
一位工程管理者用亲身经历挑战了"管理者不该写代码"的传统管理智慧。他在业余维护的 OneBusAway iOS 项目中，花几个晚上亲自打磨实习生写的路线规划功能——处理 UI 边界情况、修复长目的地名称导致的布局 bug。核心洞察：审阅代码和亲手写代码是"知道某事"和"真正懂得"的区别。亲自调试 Auto Layout 约束后，他重新校准了对开发难度的认知——在 PR 评论里轻飘飘说一句"加个加载状态"很容易，真实现时要处理三个错误条件、动画平滑、快速切换 tab 等复杂情况。他提出管理者应保持约 5-10% 的编码时间，最好在"不阻塞团队进度"的上下文里（如 side project、实习生后续打磨）。关键判断标准：这件事是让你保持敏锐，还是让你成为瓶颈。全文有真实操作细节、具体代码场景和对管理日常的反思，不是空洞的说教。
Claude Code 构建 MVP 原型好得离谱
Aaron Brethorst 分享用 Claude Code 构建原型 MVP 的真实体验：AI 生成的代码虽然需要重构才能上线，但其"一次性"特质反而成为最大优势——开发时间从数周压缩到数小时，让更多想法能被快速验证。关键洞察是，当代码不是亲手一行行写出时，沉没成本谬误大大降低，更容易面对用户反馈果断放弃失败方案。作者认为，真正稀缺的不再是开发时间，而是搞清楚用户想要什么的时间。这种"先建再验"的方式比传统"先调研再建"更能高效筛选出值得投入的产品方向。
数据中心泡沫
核心看点：作者用1990年代末光纤泡沫（Global Crossing破产、Corning跌97%）的完整剧本，精准对标当下AI数据中心狂热。关键论据：哈佛经济学家Jason Furman指出2025上半年剔除数据中心建设后美国GDP增长为0；AI行业年收入150-200亿美元，折旧却达400亿，盈亏平衡需要2025-2026年实现约1万亿收入，目前遥不可及。作者认为这不是健康的增长，而是等待破裂的泡沫——不同之处在于规模更大、杠杆更深，企业靠借钱建基础设施、买快速贬值的硬件，赌未来收入能弥补支出。一旦泡沫破裂，冲击将波及设备制造商、数据中心REITs、电力公用事业和银行。文章不预测具体时间点，但警告：当折旧是收入的两倍时，这个行业不可持续；当投机性基建支出撑起GDP时，一个行业危机可能演变为全国性衰退。有数据、有历史对照、有具体人名和来源的硬核经济分析，适合对AI投资泡沫、科技产业周期感兴趣的读者。
回顾 iRooster：我的第一个 Mac OS X 应用
一位开发者回顾自己2003年发布的首款Mac应用iRooster——用一台2000美元的Mac当闹钟、播放iTunes歌单，初衷只是解决自己赖床错过早课的问题。文章坦诚讲述了从v1.0到v2.0的迭代过程、月入最高2000美元的真实收入，以及这款小软件如何帮他拿到WWDC奖学金、获得面试机会、建立职业自信。2022年他将PowerPC时代的Objective-C老代码开源。这是一个充满人味的"自用工具转商业产品"故事，属于早期共享软件时代的珍贵个人记录，没有包装说教，只有真诚的经验沉淀和对经典时代的怀旧。
即将到来的LOB应用复兴（与安全噩梦）
AI编程智能体（如Claude Code）结合MCP协议服务器，正让业务人员只需用自然语言描述需求即可生成可工作的LOB应用——从库存实时看板到费用审批自动化，无需编写生产级代码。但作者尖锐指出：每个能力同时也是安全噩梦。AI可访问内部系统、生成数据库查询、部署应用，若缺乏细粒度权限控制、自动化安全扫描和治理框架，将造成SQL注入、权限提升、长期安全技术债等灾难性后果。文章对比了VB6、Rails、低代码平台等历史方案，认为AI不是消除了复杂性而是吸收了它，这才是真正变革。企业窗口期在于：先建立治理框架再开放能力，否则业务用户一旦尝到用自然语言造应用的甜头，潘多拉魔盒就关不上了。
Rails 8 中 Propshaft 的性能问题与修复
作者升级到 Rails 8 后改用 Propshaft 替代 Sprockets 管理前端资源，页面加载从原来的 150-200ms 暴涨到数秒，且无任何 Ruby 慢代码或数据库瓶颈。排查发现，Propshaft 默认行为会在每次页面加载时手动检查每一个资源的变更状态——资源稍多就会引发性能灾难。修复方法很简单：在开发组添加 listen gem，并在 development.rb 中配置 config.file_watcher = ActiveSupport::EventedFileUpdateChecker 即可恢复流畅。Propshaft 文档其实提到了这个优化，但藏在末尾不起眼的位置。对有大量前端资源的 Rails 应用来说，这项配置本应成为默认值。一篇非常实在的踩坑记录，有具体数据、根因分析、完整代码和可复用的操作指引。
Claude Code Hooks 详解：从入门到实战
20年编程经验的开发者直言Claude Code官方Hook文档令人困惑，通过一个Rails项目的pre-commit钩子实战案例，手把手教你配置Hook：包括全局与项目设置的选择、使用正则捕获所有文件修改事件、创建独立脚本目录组织Hook脚本、rubocop+rspec完整实现与bash命令逐行解析，以及用PostToolUse输出JSON到文件的高效调试技巧。文章解决了官方文档未讲清楚的关键概念，让团队可在代码库中实现一致的自动化质量检查。