一、换平台换掉哪几条

技术栈：用什么框架、最低支持哪个版本。 怎么跑起来：在哪儿点运行，改完先编译，再谈界面。 界面约定：一屏一个文件，颜色字号集中定义。不要做什么：别把界面逻辑塞进入口文件。

二、四块跟通用的那份一一对上

第 5.5 节给过一个四块的示例：技术栈、验证方式、红线、风格。 iOS 上这四块的内容变了，但四块本身一块没多、一块没少。 这说明一件事：平台换了，规则文件的结构不用重想——换的只是里面的答案。

三、为什么验证方式还在第一位

iOS 上它具体到一句话：改完编译过不过。 这是一句能自动判对错的话——它省掉的不是你的打字，是你反复确认的力气（第 5.5 节）。 所以写规则文件时那句最该先写：一句能验的，胜过十句形容的。

四、这份文件要跟着项目长

第一版先写五条就够，不要一次写满（第 5.2 节）。 之后每踩一次坑补一条（第 5.7 节）——它长出来的方式，就是你踩过的坑的清单。 补到某一条再也想不起来为什么写，那就说明它已经没用了，删掉。

五、动手 Demo：iOS 项目的规则文件该写什么

下面给出这份规则文件的骨架，与四个板块在 iOS 上的具体形态。

P("    # 技术栈")
P("    SwiftUI，不用 UIKit；最低支持版本跟着项目走")
P("    # 怎么跑起来")
P("    在 Xcode 里点运行；**改完先编译，再谈界面**")
TH([u"写什么", u"在 iOS 里的具体形态"], [22, 52])

实跑输出：

--------------------------------------------------------------------
iOS 项目的规则文件该写什么
--------------------------------------------------------------------

换一个平台，**规则文件里换掉的其实只有几条**：

    # 技术栈
    SwiftUI，不用 UIKit；最低支持版本跟着项目走

    # 怎么跑起来
    在 Xcode 里点运行；**改完先编译，再谈界面**

    # 界面约定
    一屏一个文件；颜色和字号集中在一处定义

    # 不要做什么
    **不要为了省事，把界面逻辑写进入口文件**

这四条为什么是这四条——**跟第 5.5 节那四块一一对上**：

  写什么       在 iOS 里的具体形态
  ------------------------------------------------
  技术栈       用什么框架、最低支持哪个版本
  验证方式     **改完编译一遍**——这是最重要的一条
  红线         不准动的文件、不准越过的手续
  风格         命名、文件划分、颜色字号从哪儿取

**验证方式那一条依然最值钱**：iOS 上它具体到【编译过不过】——
一句能自动判对错的话，胜过十句形容。

四块跟第 5.5 节一一对上——平台换了，结构不用重想，换的只是答案。 验证方式那一条依然最值钱：iOS 上它具体到【编译过不过】。

30 秒实验

1. 给你现在的项目写一份规则文件，只写四条，其中一条必须是验证方式。
2. 拿它跑一个真任务，看哪一条它真遵守了、哪一条没遵守。

常见误区

1. 把教程里那份完整的规则文件抄过来。第一版先写五条就够，剩下的按坑补。
2. 验证方式写成【注意代码质量】。那不是一句能自动判对错的话，等于没写。

• ☐ 下一节（14.7 本章真正想讲什么）

相关笔记

• 一个优秀的CLAUDE.md示例 — 那份四块的原始示例
• CLAUDE.md中到底该写什么 — 六该四不该的判据
• 迭代飞轮：让Claude Code越用越好的方法 — 每踩一次坑补一条
• 🧡 Claude Code橙皮书 · 索引