我不看代码，但这个 App 是我做的

先把最容易被误会的地方说清楚：我不写代码，也基本不读代码。

我做了很多年支付系统——在美国，跟 processor、ISO、商户打交道。技术方案我能判断对错，但让我逐行看 Swift，我看不了。

而你现在能从 xtype.dev 下载到的这个 Mac App，是我做的。Developer ID 签名、Apple 公证、七天内发了 94 个版本号、十几个公开版本。全程由 AI 写代码。

这个系列想讲的不是「AI 编程有多神」，而是一个具体得多的问题：当我看不懂代码时，我凭什么相信它是对的？

一句根契约：UI 即软件

我给这个项目定的第一条规矩是：

UI 即软件。我不碰代码，但必须审逻辑正确。UI 是验证逻辑的唯一界面。

意思是：每一处判断、规则、换算、守门，都必须在界面上看得见。界面上找不到的条款，等于没做完。只藏在代码里的业务逻辑，叫「黑匣子」，算违约。

这条规矩把「我看不懂代码」从缺陷变成了约束条件——它逼着系统把自己解释清楚。免费额度还剩几次？界面上写着「今日 4/50」。插入到底成没成功？界面上分四种状态明说，包括「打了字但无法验证」这种诚实的中间态。

我审的是这些，不是代码。

光有 UI 还不够。这七天里我总结出三条，每条都是被现实教出来的：

第一，技术对错靠真机实测，不靠”逻辑上应该行”。

AI 会非常自信地告诉你「这样改就对了」。编译通过、代码路径讲得通、听起来无懈可击。但在真机上跑之前，那都只是「我认为它能行」。我要的是同一个场景改前改后的对照——数据说了算。

第二，设计对错靠人定稿，AI 只能出草稿。

有几次 AI 看到一段它觉得”写错了”的代码，差点大笔一挥重写——而那段代码是有来历的，是之前某次事故之后特意那么写的。所以现在的规矩是：动别人的设计之前，先去翻文档和 git 历史，搞清楚当初为什么这么设计；认同就别动，不认同先写草稿讨论，等定稿再改。

第三，每个设计决定必须留下四段：决定、理由、证据、什么情况下该推翻它。

最后那段最关键。前提变了就该改，写清楚前提，后来人（以及后来的 AI）才能自己判断，不用猜当初的意图。没有这一段，几个月后所有代码看起来都像可以随便重写。

第三天，我对着它讲了五分多钟，讲得很投入。结果输入框里只出现了十一个字。

后来查明白：AI 刚给我加的”长语音自动分段”功能，每 60 秒切一段上传，但服务端严格拒收超过 60 秒的音频——定时器总会多出零点几秒，于是每一段都被静默拒绝了，只有收尾那截活下来。

好消息是录音还在本机（前一天刚加的落盘机制救了它），我们把它按 58 秒重新切块，1893 个字全部找回。

这件事有两个教训。技术上：边界值不能顶着上限跑。但更重要的是流程上——这个 bug 编译通过、测试通过、看起来完全正确。它只在真机上、只在超过一分钟时、只对我这种爱讲长句的人暴露。

AI 写的代码不会告诉你它没想到什么。真机会。

这个系列打算继续写下去，都是具体的：

而这个产品本身就是这套方法的证据。它是不是好东西，你下载试试就知道；我说的这套是不是真的，看它出过的问题和怎么修的就知道。

两边我都摆在明处。