背景

在实现一个用 SwiftUI 构建的 iOS App 的过程中，我想让 Agent 帮我加一个 Feature：让 Calendar 可以滑动查看上一月/下一月。本以为是个简单的一个需求，过程的艰辛却远超我的预期。这也体现了纯 Vibe Coding 的一个局限：当 AI 撞墙时，即使指令给得再小、再清晰，它都很难独立完成任务。

第一次尝试

用的 Claude Code w/Sonnet-4.5，以为是个简单的需求，就给了一个最直接的 prompt：

Make the Boolean Type Calendar Scrollable. Scroll left/right to view previous/next month.

经过几次迭代后，这个 Calendar 可以滚动了，但很卡，于是我把这个信息告诉它，让它进行优化。

there's a scroll glith on boolean type calender view, when I scroll the calender past half, and release, it will lag twice, then slide to the end. think carefully to fix this bug.

又经过了几次迭代，它还是没能 fix 这个卡顿的问题，于是我重置了代码，进行了第二次尝试。

第二次尝试

对于同样的 Feature 不同的 Agent 可能会有不同的解法，所以这次切换到了 Codex w/gpt-5-codex，给了同样的 prompt，除了耗时更长外，结果并没有什么不同。此时我知道，这件事它可能不简单。

第三次尝试

这次只能亲自动手了，卡顿一般跟 re-render 有关，于是我查看代码，将 Calendar 对应的代码，简化成了 Color.random()（Color 本身并没有这个方法，所以加了一个 extension），发现在滑动时，Color 变了好几次，说明这些 View 被 SwiftUI 认为是不同的 View，所以重新创建了。得到这个信息后，让 Calude Code 再次进行优化：

the boolean calendar view is a bit lag while scrolling, it seems to be the view don't have a consistent id, so they re-render while page change. reduce the re-render by giving them appropreate ids.

有了这个信息后，Claude 再次进行优化，几次迭代后，优化完成，它非常自信的告诉我 re-render 的问题解决了，这次应该会非常丝滑。我结合 Self._printChanges()，发现确实重复生成/渲染的问题解决了，但，这个卡顿还在！

第四次尝试

这就很奇怪了，难道是这个用 SwiftUI 实现的 Calendar 有性能问题？为了验证这个想法，我让 CC 简化代码，用最简单的色块代替 Calendar，看看滚动起来是否顺畅。

now it works, but the lag persistent. can we first identify what's causing the lag, by simplify the scenario like use a random color, etc?

CC 听取了建议，把 Calendar 变成了纯色块，滑动是顺畅了，但有个问题，滑动过一半后，色块的颜色就变成了下一个 Calendar 的色块，我分析了下，应该是滑动过半后，page 自动变成了 next page，而这个色块会监听这个值的变化，于是也就变了。把这个信息给 CC 后，它很快就 fix 了。

- the prev/next button works perfect.
- but the scroll still has a problem, it seems to be caused by the page variable, once it pass half, the page change, and current scrolling item will be replace to that page.

给出的结果非常好，没有丝毫卡顿，极其丝滑。

第五次尝试

这么看来确实是 SwiftUI 实现的这个 Calendar 模块有问题，于是我想用 UIKit 重新实现一个，再嵌到 SwiftUI 里，看看是否能解决性能问题。

it seems the SwiftUI's Calendar is the root cause of glitch, maybe we can use UIKit to represent this calendar?

这个改动其实挺大的，所以 CC 也是尝试很多轮后，结合我的反馈，才终于基本可用了，中间还因为用满了 5 小时的 Token 限制，休息了一会。

yeah, its smooth, but after scroll end, the calendar doesn't refresh, all blank day, the title updated though.

---

the behavior is after scroll ended, it first display blank date, then immediately updated with some data, but it's not the final data, it will refresh quickly again to reveal the final data, so visually, like it blinks.

---

yes, it's better now, but the colored background only appear when scroll end, visually its not too good, can we pre fill the calendar?

---

the previous month's colored circles appear immediately, but the month before still blank and fulfilled after scroll end.

---

better, but ${currentMonth}-3 is still blank first when scrolled.

看起来确实丝滑了，实现方案是预加载 3 个 Calendar 的数据，当这 3 个 Calendar 滑动起来，这些蓝色块、红色块会被预先填上，但滑动到第 4 个 Calendar 时会出现先显示空 Calendar，然后再渲染色块的现象。

第六次尝试

CC 的这个策略看起来有点 rigid，能不能先预加载 3 Calendar，当滑动到倒数第二个预加载的 Calendar 时，再往前加载 3 Calendar？

can we make it simpler? because the scroll always from large month to small month (if scroll back to large month, it's already loaded), so why not just prefetch previous 3 months, if scroll to the prefetched month - 1, then start prefetch next 3 months?

很不幸，CC 在 Operate 的过程中触发了 Weekly Limit，好在还有 Codex，于是切换到 Codex，继续这个 CC 未完成的任务。

I'm in the middle of optimizing boolean type calendar scroll performance, I want the strategy be: first preload previous 3 months data, when user scroll to the second to last preloaded data's month, preload next 3 month. help me implement this strategy.

半小多时后，结果出来了，符合需求，但 Token 也用了近 20%（PS：这也是我打算退订 Codex 的一个原因：慢，有时 Token 消耗地还快）。

小结

这个看似简单的需求，如果过程中缺少人的协作，很难达到满意的效果。尽管 AI 在代码生成和辅助开发方面能力强大，但在面对复杂、深层或性能敏感的需求时，它仍然是一个强大的工具，而非完全独立的解决方案。它需要有人能够帮忙诊断问题、制定策略，并在必要时进行干预和引导。纯粹的 Vibe Coding 适用于简单、明确的需求，但对于有挑战的任务，人与 AI 的高效协作，即 “人机协作编程”，才是提升效率和解决问题的关键。