如果平时的一些 Bug / Feature 都让 AI 来完成，代码都让 AI 来写，那么遇到 AI 实在搞不定的棘手 Bug 或 Feature 时，作为人又有什么自信能够解决 🤔

调试 SwiftUI 的一个 performance 问题，最终还是通过 Color.random() 找到了端倪。

同一个 Bug，让 Claude Code (Sonnet 4.5) 和 Codex (GPT-5-Codex) 分别试了 5 - 10 次，都搞不定，结果 gemini-cli 一次搞定···

看来要把 gemini-cli 扶正了。

Update: 又给了一个 case 让它解，一塌糊涂···

终于找到了在 iOS 26 上 disable 系统自动加上的 Liquid Glass on toolbar，奥义就是使用 .sharedBackgroundVisibility(.hidden) modifier.

因为 Copilot / Codex / Claude Code 全部 hit limit，索性试试让 Copilot 接入 OpenRouter 的 Sonnet 4.5，好家伙，不到 10 分钟，$10 没了，问题还没解决···

让 AI 写代码，很重要的一点是判断力：

• 这是一个多大难度的 Feature？
• 应该交给哪个 Agent 来实现？
• 需求是否要再细分？
• 需求是否没有说清楚？
• Agent 是否已经撞墙？
• 是否要换一个技术方案？
• 是否已经到了 Agent 的能力极限？
• 是否要拉另一个 Agent 来一起 Review 代码？
• 是否需要自己介入？

这些判断力就是一个程序员综合素质的体现。

MCP 真是把双刃剑，一方面真是能提高效率，另一方面也真是耗 Token，实现一个 SwiftUI Feature，Agent 一大半时间都在跟 MCP 沟通（比如 XcodeBuild mcp，在那又是截屏，又是跳转页面，来来回回，token 都快用完了，目标按钮都还没找到）。

一个 Prompt 耗时一个小时成就达成。

发现自己的 Blog 用 node serve 时，会消耗 200M+ 的内存，想着 Bun 以性能著称，就试了下用 Bun serve，结果内存直接翻倍···

Claude Code 和 Codex 真是一个都不能少，前者适合需求明确的小任务，后者适合需要思考量的复杂任务。

目前对 GitHub Copilot Pro + Claude Code Pro + Codex Pro 的配搭比较满意。

Codex 在执行任务时，需要用到 Zip 来打包，一生要强的 Ta，最后手写了一个···

Replaced the use of missing system ZIP APIs with a custom zero‑dependency ZIP builder (Shared/Utilities/ReviewExportService.swift:244) so CSV export now packages daily/weekly/monthly answers without compilation errors. Nothing else needed

踩了个坑，iOS 18 上，如果 place 一个 menu（label 为 Image） 到 .topBarTrailing，那么它是不会水平居中的，会向右横移几个像素（同样的代码设置为 .topBarLeading 就没有问题），解决方案就是手动为这个 image 设置 offset。

本文作者 Peter Steinberger 分享了他在使用代理工程（Agentic Engineering）方面的最新进展和经验，强调了“直接对话”（Just Talk To It）的无废话方法。他指出，代理工程已能生成几乎 100% 的代码，但许多人仍在尝试复杂的方法而非直接解决问题。作者主要使用 codex CLI 工具，并行运行多个代理，并让它们进行原子提交，以保持 Git 历史的整洁。他偏爱 gpt-5-codex 模型，认为它在智能和速度之间取得了很好的平衡，并能自动调整思考深度。...

Coding Agents have fundamentally changed the way I code.

这个 menu bar 小工具挺方便的，可以让网页驻留在工具栏

现在一些有点复杂度的 Feature 都是让两个 Coding Agent 互相 Review，效果还可以。

前几天看完《梵高手稿》有点不过瘾，就整理了下他的通信记录，并做成了一个网站。

在一个 iOS 项目里，refactor 一个 struct name，Xcode 搜索了两分钟，还没有找到所有引用该 struct 的地方，而这个项目大概只有二十个文件，每个文件不超过 1000 行，真正引用的文件只有1 个 🙂‍↕️。

这个月才刚过一半，Copilot 300 Requests 的份额就快用光了，感觉得开启 GLM 4.6 了。

看来还是要开启 Plan Mode，尤其是对于有一定复杂度的 Feature

这个 Timeline 的效果挺不错的，还是开源的。

同一个需求分别让 Copilot、Codex 和 Claude Code 来实现，最后是 Claude Code 在第三次完整地实现了。Copilot 和 Codex 都失败了，其中 Codex 更是辛辛苦苦做了 20 分钟，最后拉了坨大的，给了反馈后，也调整不好，属于班里那种非常勤奋，但成绩又不拔尖的同学。

目前的 Coding Agent 不论多高级，都有一个共性：在实现一些 Feature 或修复 Bug 时会 "hit wall"，而只靠它自己是没有能力解决的。此时必须依靠有经验、有能力且对项目有足够了解的程序员介入，才有可能找到解决方案。这也是为什么中高级程序员短期内不仅不会失业，还会变得更有价值的原因（之一）。

Sonnet 4.5 在尝试实现一个 Feature 时，发现可能带来的改动量比较大，索性就罢工了，这是一种进步还是退步，我竟一时分不清了···

The app is now back to its original, working state. The page-scrolling implementation would require a fundamentally different architecture (like using UIPageViewController or a more complex custom solution), which would be quite invasive to the current codebase.

原来这里还有一个小按钮，可以 copy 选定的动画效果

iOS 26 的 ToolbarItem 会自动被包一层 glass button，还没有办法去掉，同时要想实现分开的两个 button，不能简单的罗列两个 ToolbarItem 或者 HStack ，只能通过 iOS 26 新增 ToolbarSpacer 来实现...

AI Coding Agent 还有一个很严重的问题：不可靠性。有时很聪明，有时又会犯傻。所以还是要多几个工具，当其中一个掉队时，另一个可以顶上。

这篇文章详细阐述了作者Mitchellh如何利用AI作为主要辅助工具，开发Ghostty终端的非侵入式macOS自动更新功能。他分享了一个高度迭代的过程，包括前期人工规划、AI进行UI原型设计、代码清理、文档编写和模拟测试。文章强调，尽管AI在处理明确任务和提供灵感方面表现出色，但在面对复杂bug或生成次优代码时，人工的战略性调整、深入理解、重构和严格审查至关重要。整个项目耗时约8小时，花费15.98美元，作者认为AI加速了开发，尤其是在处理繁琐的UI样式方面，并允许他在AI工作时进行多任务处理，但始终坚持人工的最终审查和主导作用。

it's important that I review a plan before it goes off and does a ton of work....

初步试用了下 spec-kit，是挺强大、方便的，就是有点费 Token···

这篇文章批评了苹果iOS 26操作系统中引入的“液态玻璃”视觉语言，认为其过度强调视觉设计和装饰性UI效果，却牺牲了可用性。作者指出，半透明元素导致内容难以辨认，动画按钮分散用户注意力，缩小和拥挤的触控目标增加了操作难度，而不断变化的界面和对既有约定的打破则损害了可预测性和可发现性。文章总结道，iOS 26将视觉奇观置于用户体验之上，使得界面混乱、难以阅读且缺乏一致性，最终让用户感到沮丧，而非提供无缝的内容访问。

Claude Sonnet 4.5 is Awesome!

同样一个 bug，Codex (gpt-5-codex) 思考了两轮，每轮大概 10 分钟，都没有找到 root cause，Sonnet 4.5 一下就找到了（用的 Github Copilot），结合 Claude Code 应该会更强。

现在用的最多的两个 MCP：context7 / XcodeBuild

对于商业化的项目，在实现 Feature 这块，最好把 AI Agent 当作一个 Coding Partner，把每一个 Task 拆分地足够细，既减少了自由发挥/出错空间，也方便 Review。

经过几天调研，目前对这个 Xcode 目录结构比较满意。

• 每一个目录职责清晰。
• 尽量保证 co-location。
• Shared 部分为独立、会被多处引用、支持性的模块。
• Shared 部分稳定后可以单独拿出来作为 Package。...

Kickstater 的 ViewModel 设计的蛮有意思的，通过 inputs 和 outputs 来显式地标记 command 和 result。

定义 ViewModel...

如果要学习

• iOS: 看 Kickstarter
• Mac: 看 MarkEdit
• React: 看 tldraw

作者是 Vercel 的设计工程师，这个付费教程旨在帮助你设计出让人愉悦的交互，页面设计得很赞，相信教程质量也不会差。

Neal 同学又放出了新的作品，把验证码坐成一个合成类游戏，看着挺好玩的样子

钟颖退出 Twitter 后，原来做了好几款开源的 Mac App，太赞了，想学习 Mac 开发的话，值得一看。

• making sure your animations have a purpose.
• Think about what the user wants to achieve and how often they will see an animation.
• Unless you are working on marketing sites, your animations have to be fast.

12 个动画设计原则，对于创造 delight 的体验，挺有帮助的。

这个 site 的设计挺有自己的风格和理念的

这个关于 Server / Serverless / Fluid 的区别的 Visualization 做得太棒了！

可以在这里体验。这个工具本身是通过 v0.dev 生成的。

好喜欢这种功能单一、设计简洁的工具

这个 Date Picker 感觉可以成为标准了，功能强大的同时操作也挺方便的。

虽然 Raycast 内置了 Caffeinate 功能，虽然系统提供了 caffeinate cli，但还是有很多人不用 Raycast，更不用说 cli 了。把一个实用的小功能做到极致，用户是愿意买单的。

用这个工具搜索 GitHub 代码，真的是快的飞起！

发现了一个高效的编程领域的学习模式：找到一个优秀的开源项目，然后让 GitHub Copilot 成为那个无处不在的老师。这里选择 Copilot 而不是 Claude Code 的一个原因是：更好的 Markdown 渲染结果和与 IDE 交互的友好性。

这个模式看起来可以推广到更广义的学习范畴：一份优秀的手册、文档、课件、代码加上一个优秀的 Agent（能够识别、生成足够好的 Context，优化过的 Output 等等）。

一个可以在 iOS 设备上开发 iOS 应用的应用，交互方式主要是 Chat，有点像把 CC 移植到了 iOS 上，挺 magic 的。我其实蛮想要一个 Mac 平台的，类似这样的工具。