夜雨聆风最近很流行一个说法：「随便一个 App，让 AI 帮你复刻一个出来，几小时搞定。」
我亲自试了。
从一个「很简单」的需求说起
我选了一个看起来极其简单的 iOS 工具类 App——录屏转长截图。
功能用一句话就说完了：把手机录屏视频，自动拼接成一张完整的长图。
这类 App 在 App Store 上评分不错，用户量也不小。我心想，这种功能性工具，结构清晰，逻辑简单，AI 应该手到擒来。
于是我分别用了 Claude Code 和 Codex 来尝试复刻。
结果是：主流程跑通了，但根本没法用。
AI 交付的是「能跑的 Demo」，不是「能用的产品」
AI 写出来的版本，核心逻辑没问题——读取视频帧，顺序拼接，输出图片。放进模拟器一跑，确实能生成一张长图。
但只要一用真实录屏来测试，问题就来了：
问题一：TabBar 重复出现 底部的导航栏，在每一帧里都有。拼出来之后，长图里每隔一段距离就出现一个 TabBar，密密麻麻，完全不可用。
问题二：滚动条像一道伤疤 屏幕右侧那条细细的滚动条，被一帧一帧地拼进去，最终在长图右侧形成一条断断续续的灰色竖线。
问题三：加载动画被定格 下拉加载更多时，底部会出现一个 Loading 转圈动画。AI 的版本直接把这些帧拼进去，长图里出现了好几个「正在加载」的截图。
问题四：快速滑动导致模糊 滑动过快时，视频帧会有运动模糊。AI 不会判断帧质量，模糊帧和清晰帧被一视同仁地拼在一起，接缝处糊成一片。
问题五：来回滚动内容重叠 如果录屏过程中有上下来回滑动，同一块内容会被拼进去两次，长图出现内容重叠。
问题六：悬浮按钮出现好几个 页面右下角有一个悬浮的「回到顶部」按钮。它出现在每一帧的固定位置，结果被拼了十几个，像盖了一排印章。
这些「边界情况」，每一个都是真实的工程问题
随便拿其中一个展开说说——悬浮按钮重复这个问题。
之所以难处理，是因为它和 TabBar 不一样。TabBar 位置固定在底部，可以用固定高度裁掉。但悬浮按钮：
位置不固定（左下、右下、正中间都有可能）
大小不固定
有些页面有，有些没有
有时候会自动隐藏
正确的处理思路是：检测「背景在动，但这个区域的像素没动」的区域——这就是悬浮层。然后在拼接中间帧时把这块区域抹掉，只在最终长图的末尾保留一个。
光是「抹掉」这个动作，背后就有一个新问题：抹掉之后，那块空白填什么？
如果是纯色背景，好说；
如果是正在滚动的内容，就需要从前后帧里找到位移对应的像素来填充；
如果是毛玻璃模糊效果，基本没法完美还原。
一个按钮，就藏着这么多层的判断逻辑。
AI 卡在哪里？
AI 工具没有「看到结果、发现问题、反向定位原因」的能力。
它能做的是：你描述什么问题，它解决什么问题。
但这个「描述」本身，就是工程师最核心的价值——你得先跑起来，看到那条右边的灰线，意识到那是滚动条，知道去哪里找它、用什么策略消除它，然后再把这个「具体问题 + 具体策略」喂给 AI，它才能写出来。
问题是，如果你已经有这个能力，你其实已经不需要 AI 替你思考了——你需要的只是一个打字员。
那 AI 辅助编程到底有没有用？
当然有用，但用法要变。
低效用法：「帮我复刻这个 App」→ AI 交付 Happy Path，边界全是坑，你一个个踩。
高效用法：
你来定义边界：把每一个 edge case 写成具体的条件和处理策略，让 AI 实现单个模块；
模块化拆分：帧提取 / 质量过滤 / 固定层检测 / 拼接 / 修复，分开写，分开测；
你做 Review Loop：发现问题 → 定位原因 → 告诉 AI 策略 → 让它实现 → 再测。
换句话说：产品和工程的判断力，仍然是你的；AI 替你节省的，是把判断转化为代码的时间。
「录屏转长截图」这个 App，如果你去 App Store 下载一个做得好的版本体验一下，你会觉得很流畅、很自然，完全感知不到上面说的这些问题。
那背后是有人认认真真地把每一个 edge case 找出来、处理掉的。
这些东西，AI 目前还替代不了。
它替代的，是那些你已经想清楚了、只差一双手的工作。
想清楚，依然是人的事。
