测试

我正在构建一个 macOS 的菜单栏应用程序。在我的 Mac 上运行完美。现在我需要知道它是否能在干净的 macOS 环境中正常工作：没有我的配置、没有我的权限、没有我的数据。一个全新安装的用户环境。 如何测试这种情况？你需要一个虚拟机。 “简单”，我想。“我安装了 UTM。打开向导，创建一个 macOS 虚拟机，然后运行。” 事情并没有那么简单。 UTM：漂亮但难以驯服 UTM 是一个很棒的应用程序。精心设计的界面，支持在 Apple Silicon 上运行 macOS 客户机，全屏显示，共享剪贴板。手动使用确实很棒。 当你试图自动化时问题就出现了。 UTM 有一个叫做 utmctl 的命令行界面。可以列出虚拟机、启动它们、停止它们、克隆它们。它不能做的是创建虚拟机。对于 macOS 客户机，甚至 UTM 的 AppleScript 也不允许创建它们——操作系统字段被硬编码为 Linux。 简单来说：如果你想在 UTM 中创建 macOS 虚拟机，你必须通过向导手动创建。每次都是。需要点击、下载 IPSW（Apple Silicon 的 macOS 安装映像——相当于传统的 ISO，但由 Apple 打包）、等待安装。 对于需要在质量保证流程中频繁创建和销毁虚拟机的开发者来说，这真是个麻烦事。 Tart：为开发者设计的 macOS 虚拟机 Tart 是当有人在设计虚拟化工具时考虑开发者而不是最终用户的结果。 它使用与 UTM 完全相同的 Apple Virtualization.framework。相同的技术，相同的功能，相同的原生速度。区别在于界面：Tart 是命令行优先的。 1 brew install cirruslabs/cli/tart 就这样。没有图形界面配置，没有向导。只是在你的 PATH 中的一个二进制文件。 一个命令统治一切 创建一个使用最新可用版本的 macOS 虚拟机： ...

上周我分享了AI如何编造了一个完整的JSON结构，并用DTO、固件和测试对其进行包装。90个测试全部通过。全是假的。 那篇文章是诊断。这篇是治疗。 发现这个灾难后，我做了任何自尊心受挫的工程师都会做的事：连续数天疯狂研究，确保不再发生。我阅读论文、试用工具、分析应用API的真实数据，并为我的应用构建了一套防御系统。 我的发现令人惊讶。在我识别的5种应对措施中，只有3种真正有效。其他两种充其量是善意的表演。 思维模型：你与AI的对抗（字面意思） 在深入这些措施之前，你需要理解框架。我找到的最佳类比来自深度学习。 在GAN（生成对抗网络）中，有两个神经网络在竞争： 生成器产生内容（图像、文本等） 判别器试图检测内容是真实的还是虚假的 系统之所以改进，是因为两者相互推动。生成器学会更好地欺骗。判别器学会更好地检测。 当你与大语言模型编程时，你就处在一个无意的GAN中： **大语言模型是生成器。**它产生代码、DTO、测试、固件。 **你是判别器。**你必须检测什么是真实的，什么是编造的。 但存在一个残酷的不对称：生成器不知疲倦，而你会疲劳。大语言模型可以不费力地生成50个文件。你检查10个就累了，第11个文件就不看了。 这就像我在1Password一天要求Touch ID 47次中提到的授权疲劳。依赖人类永远保持警觉的安全就是纸板安全。 判别器应该监控什么 你不能（也不应该）检查每一行。你需要监控的是边界——你的代码接触外部世界的地方： 边界 关键问题 外部API DTO中的字段在真实API中存在吗？ 包 依赖项存在并且名称正确吗？ 数据库模式 表真的有这些列吗？ URL/端点 端点存在并返回我们期望的内容吗？ **原则：大语言模型对外部世界的所有声明在验证前都是可疑的。**它说得很自信并不是证据。Anthropic在自己的文档中承认了这一点： “Claude有时会生成包含虚假信息的响应…以自信、权威的方式呈现。” 一个说"我确定"的大语言模型和一个说"我认为"的大语言模型犯错的概率完全相同。 自动化判别器 最终目标是不再依赖你的纪律性，而是自动化验证： 之前： LLM生成 → 你审查（有时） → 合并 之后： LLM生成 → CI对真实数据验证 → 你审查差异 → 合并 接下来的5种措施是自动化判别器角色的方法。有些有效。有些不太行。 硬数据（给怀疑者） 在你认为"我不会遇到这种情况"之前，这里是真实研究的数字： **21.7%**的开源大语言模型推荐的包是编造的。在商业模型中下降到5.2%，仍然是每20个包中有一个。 GPT-4o对不常见API只能达到**38.58%**的有效调用率。不到40%。还不如抛硬币。 目前定位代码幻觉的最佳方法只能达到22-33%的精度。换句话说：我们能检测出四分之一。 一位研究人员上传了一个空包，包名是大语言模型经常幻觉的。3个月内3万次下载。他们称之为slopsquatting。 而且有正式的分类法。CodeHalu论文（AAAI 2025）定义了4类代码幻觉： 类别 定义 真实例子 映射 字段映射错误 混淆user_id和account_id 命名 编造的名称 response.quota.percentage实际是response.utilization 资源 不存在的资源 API中没有的active_flags字段 逻辑 看似合理但错误的逻辑 isPaid = !activeFlags.isEmpty但字段总是空的 我的案例是资源类型转化为逻辑类型。字段不存在，但依赖它的逻辑看起来完美。连贯的虚构小说。 ...

昨天我发现我的应用程序中有一半模块基于的是编造的数据。不是因为某个迷糊的初级开发者，而是我的AI。 最糟糕的不是它编造了内容。最糟糕的是所有代码都能编译，90个测试全部通过。 连贯的虚构 我正在构建BFClaude-9000，这是一个macOS菜单栏应用，用于监控Claude Max的配额。该功能的一部分需要通过调用claude.ai的API来区分Claude账户是付费还是免费。 我让Claude Code实现了检测功能。它实现了。它交付给我： 一个包含activeFlags: [String]字段的OrganizationInfo DTO 一个检查activeFlags是否非空的计算属性isPaid 一个将组织分类为付费和免费的枚举OrganizationSelection 带有验证所有功能正常工作的测试数据的测试 漂亮。简洁。结构良好。全是编造的。 active_flags字段在Claude的真实API中根本不存在。或者如果存在，也不像代码假设的那样工作。当我用付费账户登录时，应用告诉我我的账户是免费的。 纸牌屋模式 阴险的不是它撒谎说API有某个字段。而是它围绕这个谎言构建的完整系统： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 // 带有编造字段的DTO struct OrganizationInfo: Decodable { let uuid: String let name: String let activeFlags: [String] // ← 这个不存在 var isPaid: Bool { !activeFlags.isEmpty } } // 依赖编造字段的逻辑 enum OrganizationSelection { case paid(id: String, name: String) case noPaidOrg // ← 这个状态不应该存在 case noOrgs } // 用验证编造内容的测试数据进行测试 let paidOrg = """ {"uuid": "abc", "name": "Acme", "active_flags": ["pro"]} """ // 测试通过 ✅ — 但这是在验证虚构对虚构 你看到了吗？这不是一个字段放错了位置。这是一个纸牌屋：DTO定义了一个虚假字段，逻辑依赖这个字段，测试验证逻辑使用同样虚假的测试数据正常工作。每个部分都在确认其他部分。一切都说得通。没有什么是真实的。 ...