visual_zhang

这篇文章不是一份产品说明书，而是对整个过程的复盘和提炼。我试图回答一个问题：**如何系统性地创建一份高质量的 AI Skill，并在后续的迭代中持续保持其可靠性？**

当测试代码用 Swift 编写、而被测系统的依赖大量暴露为 Objective-C 协议时，Mock 对象的创建本身就成了一场工程挑战。

当测试目标不是"从零覆盖"而是"验证一次代码变更"时，应如何设计用例？当被测方法依赖的实验开关位于另一个模块、通过 Service Locator 解析时，如何 Mock？

本文通过一个真实的线上卡死案例，探讨 NotificationCenter observer 管理不当可能带来的隐性性能问题。

本文聚焦于一个具体问题：当被测对象的关键状态被封装为私有时，测试该怎么写？我们按照推荐优先级介绍三种模式，并讨论如何让这类测试在多人协作中保持可维护。

在大型 iOS 工程中，业务逻辑往往跨越多层、多模块，端到端链路很长。本文藉某个案例，提炼出一套可复用的方法论，指导在大型工程中识别关键链路 → 设计高价值测试 → 落地到持续迭代的完整过程。

在引入Claude Opus 4.6辅助开发后，我观察到一个有趣的现象：模型的推理能力确实强悍，但这并不意味着我们可以忽视代码质量。 相反，AI 的效能上限，依然被工程代码的质量下限锁死。