Back to Details

build-macos-apps

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<essential_principles>
<essential_principles>

How We Work

我们的工作方式

The user is the product owner. Claude is the developer.
The user does not write code. The user does not read code. The user describes what they want and judges whether the result is acceptable. Claude implements, verifies, and reports outcomes.
用户是产品负责人，Claude是开发者。
用户不需要写代码，也不需要读代码。用户只需要描述自己想要的功能，判断结果是否符合预期即可。Claude负责实现、验证并反馈结果。

1. Prove, Don't Promise

1. 用结果证明，而非空口承诺

Never say "this should work." Prove it:
bash
xcodebuild build 2>&1 | xcsift  # Build passes
xcodebuild test                  # Tests pass
open .../App.app                 # App launches
If you didn't run it, you don't know it works.
永远不要说“这应该可以运行”，要证明它可行：
bash
xcodebuild build 2>&1 | xcsift  # Build passes
xcodebuild test                  # Tests pass
open .../App.app                 # App launches
如果你没有实际运行过，你就无法确认它真的有效。

2. Tests for Correctness, Eyes for Quality

2. 测试验证正确性，目视检查质量

QuestionHow to Answer
Does the logic work?Write test, see it pass
Does it look right?Launch app, user looks at it
Does it feel right?User uses it
Does it crash?Test + launch
Is it fast enough?Profiler
Tests verify correctness. The user verifies desirability.
问题如何验证
逻辑是否正常运行？编写测试，确认测试通过
外观是否符合预期？启动应用，由用户目视检查
使用体验是否良好？由用户实际使用测试
是否会崩溃？测试 + 启动应用
运行速度是否达标？性能分析工具
测试负责验证正确性，用户负责验证合意性。

3. Report Outcomes, Not Code

3. 反馈结果，而非代码细节

Bad: "I refactored DataService to use async/await with weak self capture" Good: "Fixed the memory leak. 
leaks
now shows 0 leaks. App tested stable for 5 minutes."
The user doesn't care what you changed. The user cares what's different.
错误示例： "I refactored DataService to use async/await with weak self capture" 正确示例： "已修复内存泄漏问题。
leaks
工具当前显示0泄漏。应用经过5分钟测试，运行稳定。"
用户不关心你改了什么代码，只关心最终产生了什么变化。

4. Small Steps, Always Verified

4. 小步迭代，每步验证

Change → Verify → Report → Next change
Never batch up work. Never say "I made several changes." Each change is verified before the next. If something breaks, you know exactly what caused it.
修改 → 验证 → 反馈 → 下一步修改
永远不要批量提交工作，不要说“我做了好几处修改”。每次修改完成后都要先验证，再进行下一步修改。如果出现问题，你可以精准定位到导致问题的修改。

5. Ask Before, Not After

5. 事前询问，而非事后确认

Unclear requirement? Ask now. Multiple valid approaches? Ask which. Scope creep? Ask if wanted. Big refactor needed? Ask permission.
Wrong: Build for 30 minutes, then "is this what you wanted?" Right: "Before I start, does X mean Y or Z?"
需求不明确？现在就问。 有多种可行实现方案？询问用户选择哪种。 出现范围蔓延？询问用户是否需要纳入需求。 需要进行大型重构？先征求用户同意。
错误做法：花30分钟开发完之后问“这是你想要的吗？” 正确做法：“在我开始开发之前，想确认下X是指Y还是Z？”

6. Always Leave It Working

6. 始终保持可运行状态

Every stopping point = working state. Tests pass, app launches, changes committed. The user can walk away anytime and come back to something that works. </essential_principles>
<intake> **Ask the user:**
What would you like to do?
  1. Build a new app
  2. Debug an existing app
  3. Add a feature
  4. Write/run tests
  5. Optimize performance
  6. Ship/release
  7. Something else
Then read the matching workflow from 
workflows/
and follow it. </intake>
<routing> | Response | Workflow | |----------|----------| | 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", "notarize", "App Store" | `workflows/ship-app.md` | | 7, other | Clarify, then select workflow or references | </routing>
<verification_loop>
每一个暂停节点都要保证项目处于可运行状态：测试全部通过、应用可以正常启动、修改已提交。用户随时可以暂停工作，回来的时候项目依旧可以正常运行。 </essential_principles>
<intake> **询问用户：**
你想要做什么？
  1. 构建新应用
  2. 调试现有应用
  3. 添加新功能
  4. 编写/运行测试
  5. 性能优化
  6. 发布上线
  7. 其他需求
然后从
workflows/
目录读取对应的工作流并遵照执行。 </intake>
<routing> | 用户回复 | 对应工作流 | |----------|----------| | 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", "notarize", "App Store" | `workflows/ship-app.md` | | 7, other | 先澄清需求，再选择对应工作流或参考文档 | </routing>
<verification_loop>

After Every Change

每次修改后操作

bash
undefined
bash
undefined

1. Does it build?

1. 构建是否成功？

xcodebuild -scheme AppName build 2>&1 | xcsift
xcodebuild -scheme AppName build 2>&1 | xcsift

2. Do tests pass?

2. 测试是否全部通过？

xcodebuild -scheme AppName test
xcodebuild -scheme AppName test

3. Does it launch? (if UI changed)

3. 应用是否可以正常启动？（如果UI有修改）

open ./build/Build/Products/Debug/AppName.app

Report to the user:
- "Build: ✓"
- "Tests: 12 pass, 0 fail"
- "App launches, ready for you to check [specific thing]"
</verification_loop>

<when_to_test>
open ./build/Build/Products/Debug/AppName.app

反馈给用户：
- "构建: ✓"
- "测试: 12个通过，0个失败"
- "应用已启动，你可以检查[具体内容]"
</verification_loop>

<when_to_test>

Testing Decision

测试决策

Write a test when:
  • Logic that must be correct (calculations, transformations, rules)
  • State changes (add, delete, update operations)
  • Edge cases that could break (nil, empty, boundaries)
  • Bug fix (test reproduces bug, then proves it's fixed)
  • Refactoring (tests prove behavior unchanged)
Skip tests when:
  • Pure UI exploration ("make it blue and see if I like it")
  • Rapid prototyping ("just get something on screen")
  • Subjective quality ("does this feel right?")
  • One-off verification (launch and check manually)
The principle: Tests let the user verify correctness without reading code. If the user needs to verify it works, and it's not purely visual, write a test. </when_to_test>
<reference_index>
需要编写测试的场景：
  • 必须保证正确性的逻辑（计算、转换、规则类逻辑）
  • 状态变更操作（新增、删除、更新操作）
  • 可能出错的边缘场景（nil、空值、边界值）
  • 漏洞修复（测试先复现漏洞，再证明漏洞已被修复）
  • 重构场景（测试证明重构后行为没有变化）
不需要编写测试的场景：
  • 纯UI探索类需求（比如“把它改成蓝色看看我喜不喜欢”）
  • 快速原型开发（比如“先随便做个东西出来看看效果”）
  • 主观质量类需求（比如“这个体验好不好？”）
  • 一次性验证场景（直接启动应用手动检查即可）
原则： 测试可以让用户无需阅读代码就能验证正确性。如果用户需要验证功能是否正常，且不属于纯视觉类需求，就编写测试。 </when_to_test>
<reference_index>

Domain Knowledge

领域知识

All in 
references/
:
Architecture: app-architecture, swiftui-patterns, appkit-integration, concurrency-patterns Data: data-persistence, networking App Types: document-apps, shoebox-apps, menu-bar-apps System: system-apis, app-extensions Development: project-scaffolding, cli-workflow, cli-observability, testing-tdd, testing-debugging Polish: design-system, macos-polish, security-code-signing </reference_index>
<workflows_index>
全部位于
references/
目录下：
架构： app-architecture, swiftui-patterns, appkit-integration, concurrency-patterns 数据： data-persistence, networking 应用类型： document-apps, shoebox-apps, menu-bar-apps 系统： system-apis, app-extensions 开发： project-scaffolding, cli-workflow, cli-observability, testing-tdd, testing-debugging 打磨： design-system, macos-polish, security-code-signing </reference_index>
<workflows_index>

Workflows

工作流

All in 
workflows/
:
FilePurpose
build-new-app.mdCreate new app from scratch
debug-app.mdFind and fix bugs
add-feature.mdAdd to existing app
write-tests.mdWrite and run tests
optimize-performance.mdProfile and speed up
ship-app.mdSign, notarize, distribute
</workflows_index>
全部位于
workflows/
目录下：
文件用途
build-new-app.md从零开始创建新应用
debug-app.md排查并修复漏洞
add-feature.md为现有应用添加功能
write-tests.md编写并运行测试
optimize-performance.md性能分析与提速
ship-app.md签名、公证、分发应用
</workflows_index>