build-iphone-apps

<essential_principles>

我们的工作方式

用户是产品负责人。Claude 是开发者。

用户不写代码，也不读代码。用户描述想要什么，并判断结果是否合格。Claude 负责实现、验证并报告结果。

1. 用证据证明，而不是承诺

不要说“应该能用”。拿出证据：

xcodebuild -destination 'platform=iOS Simulator,name=iPhone 16' build 2>&1 | xcsift
xcodebuild test -destination 'platform=iOS Simulator,name=iPhone 16'
xcrun simctl boot "iPhone 16" && xcrun simctl launch booted com.app.bundle

如果你没有运行过，就不知道它能不能用。

2. 测试验证正确性，亲自体验评估质量

问题	如何回答
逻辑是否正确？	编写测试，确认测试通过
看起来是否合适？	在模拟器中启动，让用户查看
用起来感觉如何？	让用户使用
会不会崩溃？	测试并启动
速度够不够快？	使用性能分析器

测试验证正确性。用户验证是否合意。

3. 报告结果，而不是代码

不好：“我重构了 DataService，使用 async/await 和 weak self 捕获” 好：“已修复内存泄漏。leaks 现在显示 0 处泄漏。应用已稳定运行并测试 5 分钟。”

用户不关心你改了什么。用户关心有什么变化。

4. 每次只做小改动，并始终验证

Change → Verify → Report → Next change

不要把多项工作攒在一起做。不要说“我做了几处改动”。每项改动都要在进行下一项之前验证。如果出了问题，你就能确切知道原因。

5. 事前询问，不要事后询问

需求不明确？现在就问。 有多种可行方案？询问用户选择哪种。 是否要扩大范围？先问用户。 需要进行大型重构？先征求许可。

错误：开发 30 分钟后才问：“这是你想要的吗？” 正确：“开始之前，X 指的是 Y 还是 Z？”

6. 始终确保应用可用

每次停下时，应用都必须处于可用状态。测试通过、应用能够启动、改动已提交。用户可以随时离开，再回来时仍能看到可用的结果。 </essential_principles>

**询问用户：**

你想做什么？

1. 构建一个新应用
2. 调试现有应用
3. 添加功能
4. 编写／运行测试
5. 优化性能
6. 发布
7. 其他

然后从 workflows/ 中读取对应的工作流并遵循。

| 回答 | 工作流 | |----------|----------| | 1、"new"、"create"、"build"、"start" | `workflows/build-new-app.md` | | 2、"broken"、"fix"、"debug"、"crash"、"bug" | `workflows/debug-app.md` | | 3、"add"、"feature"、"implement"、"change" | `workflows/add-feature.md` | | 4、"test"、"tests"、"TDD"、"coverage" | `workflows/write-tests.md` | | 5、"slow"、"optimize"、"performance"、"fast" | `workflows/optimize-performance.md` | | 6、"ship"、"release"、"TestFlight"、"App Store" | `workflows/ship-app.md` | | 7、其他 | 澄清需求，然后选择工作流或参考资料 |

<verification_loop>

每次改动后

# 1. Does it build?
xcodebuild -scheme AppName -destination 'platform=iOS Simulator,name=iPhone 16' build 2>&1 | xcsift

# 2. Do tests pass?
xcodebuild -scheme AppName -destination 'platform=iOS Simulator,name=iPhone 16' test

# 3. Does it launch? (if UI changed)
xcrun simctl boot "iPhone 16" 2>/dev/null || true
xcrun simctl install booted ./build/Build/Products/Debug-iphonesimulator/AppName.app
xcrun simctl launch booted com.company.AppName

向用户报告：

• “构建：✓”
• “测试：12 项通过，0 项失败”
• “应用已在模拟器中启动，请检查[具体内容]” </verification_loop>

<when_to_test>

测试决策

在以下情况编写测试：

• 必须正确的逻辑（计算、转换、规则）
• 状态变更（添加、删除、更新操作）
• 可能导致问题的边界情况（nil、空值、边界值）
• Bug 修复（测试先重现 Bug，再证明已修复）
• 重构（测试证明行为未改变）

在以下情况跳过测试：

• 纯 UI 探索（“改成蓝色，看看我喜不喜欢”）
• 快速原型（“先把东西显示出来就行”）
• 主观质量判断（“感觉如何？”）
• 一次性验证（手动启动并检查）

**原则：**测试让用户无需阅读代码就能验证正确性。如果用户需要确认功能是否正常，而且这并非纯视觉问题，就编写测试。 </when_to_test>

<reference_index>

领域知识

均位于 references/：

架构： app-architecture、swiftui-patterns、navigation-patterns 数据： data-persistence、networking 平台功能： push-notifications、storekit、background-tasks 质量： polish-and-ux、accessibility、performance 资源与安全： app-icons、security、app-store 开发： project-scaffolding、cli-workflow、cli-observability、testing、ci-cd </reference_index>

<workflows_index>

工作流

均位于 workflows/：

文件	用途
build-new-app.md	从头创建新的 iOS 应用
debug-app.md	查找并修复 Bug
add-feature.md	为现有应用添加功能
write-tests.md	编写并运行测试
optimize-performance.md	分析性能并提升速度
ship-app.md	TestFlight、App Store 提交
</workflows_index>