洞见 Cursor

前言 - 或许，你听过这两个经典模型

三级火箭

第一级火箭 (效率增量)

从简单任务开始（TCR/RACE框架）目标: 让你感受到"AI辅助编程真的有用" 效果: 效率提升 10%

第二级火箭 (沉淀核心能力场景)

建立完整工作流（CRISPE框架 + .cursorrules）目标: 形成"AI增强的开发肌肉记忆" 效果: 效率提升 20%

第三级火箭 (形成竞争壁垒)

团队级知识资产沉淀（规范共享 + 知识库）目标: 建立组织级AI能力，难以被复制效果: 团队效率提升 1.5-2 倍，个人不可替代性增强

点线面体

当前状态自测:

Level 0: 还没开始使用 Cursor
    → 行动: 从"点"开始，选择一个简单场景（如代码解释）

Level 1: 能用 Cursor 完成简单任务（点）
    → 行动: 连点成线，建立完整工作流

Level 2: 形成了个人的开发工作流（线）
    → 行动: 编写 .cursorrules，形成可复用的规范

Level 3: 团队开始小范围使用（线→面）
    → 行动: 制定团队规范，定期分享会

Level 4: 团队全面采用，形成共识（面）
    → 行动: 沉淀知识资产，建立培训体系

Level 5: 形成组织级AI能力体系（体）
    → 行动: 对外输出（开源、演讲、咨询）

第一部分: 心智模型 - 这是理解一切的基础

洞见 1: Cursor 是“Prompt编译器”，而非 IDE

核心阐述: 传统 IDE 辅助你手动编码，而 Cursor 则试图理解你的最终目的（意图），然后直接**生成（编译）**最终代码。整个交互的核心从“如何写代码”上升到了“要做什么”。
场景: 为用户信息卡片 UserInfoCard 添加一个更新方法
- Level 1: IDE 用户
  - 行为: 手动打开 UserInfoCard.swift，逐行编写更新 UI 的代码。
  - 内心独白: “好的，我需要一个 update(with user: User) 方法。首先，我要更新 nameLabel.text，然后是 bioLabel.text。哦，头像需要从 URL 加载，我得写一个异步加载图片的方法，还要处理 placeholder 和加载失败的情况...”
  - 结果: 手动完成所有细节，耗时且容易出错。
- Level 2: 指令式用户
  - 提示词: “给 UserInfoCard 添加一个 update 方法，用 User 模型更新 nameLabel, bioLabel 和 avatarImageView。”
  - AI 内心独白: “指令很清晰。找到 nameLabel 并设置 text。找到 bioLabel 并设置 text。找到 avatarImageView...嗯，User 模型里有个 avatarURL，我需要异步加载它。我用 URLSession.shared.dataTask 来实现吧。”
  - 结果: 功能基本实现，但 AI 可能使用了一个通用的、未经优化的图片加载方式，没有遵循项目中的缓存策略或专用的 ImageLoader。
- Level 3: Cursor Prompt 工程师
  - 提示词: “@UserInfoCard.swift @ImageLoader.swift 为 UserInfoCard实现一个标准的、符合我们项目规范的数据绑定方法。请创建一个名为configure(with user: User)的公共方法。在这个方法里，使用nameLabel.text和bioLabel.text直接绑定用户的文本信息。对于avatarImageView，必须使用我们项目中的 @ImageLoader单例来异步加载user.avatarURL，并确保在加载时显示一个占位符头像。”
  - AI 内心独白: “收到意图。这不是一个简单的更新，这是一个数据绑定任务。我知道了，上下文里有 @ImageLoader.swift，我必须使用它，这比我自己写 URLSession 要好。我需要处理占位符逻辑。方法名是 configure，这比 update 更符合数据绑定的语义。”
  - 结果: 生成的代码完全符合项目架构，使用了正确的辅助类，语义清晰，是生产级的。
- 进化总结

密度	思维模式	你的角色	产出质量
低	手动实现	代码工程师	取决于个人
中	指令式	任务分配者	功能可用，细节缺失
高	Prompt编程	系统设计师	生产级、符合架构

洞见 2: 代码的经济学 - “生成式重构”

核心阐述: AI 将大规模、模式化的重构成本降至几乎为零，使得“保持代码健康”从奢侈品变为日常。
场景: 迁移一个旧的日志 API
- Level 1: 低密度 (手动重构)
  - 行为: 使用全局 Find & Replace，逐个检查并手动修改几十个文件中的 log_event 调用，极其耗时且容易出错。
  - 内心独白: "天啊，这个带参数的 log_event 替换起来好麻烦，正则表达式要写对，还要小心不要替换掉注释里的内容。"
  - 结果: 可能需要数小时甚至数天，且有引入新 bug 的风险。
- Level 2: 中密度 (简单提示词)
  - 提示词: “把项目里所有 log_event(name, params)替换成Logger.shared.track(name, params)”
  - AI 内心独白: “好的，这是一个直接的文本替换。但新的 track 方法签名真的是这样吗？params 的类型是什么？我只能假设它是兼容的。”
  - 结果: AI 会完成简单的替换，但如果新的方法需要一个结构体而不是字典，或者参数顺序不同，AI 的修改就会导致大量编译错误。
- Level 3: 高密度 (模式化重构指令)
  - 提示词: “@/Sources 你的任务是进行一次全项目的 API 迁移。扫描整个项目，找出所有对旧方法 log_event(name: String, params: [String: Any]?)的调用。将它们全部重构为使用新的Logger.shared.track(event: AnalyticsEvent)方法。你需要根据旧方法的参数，动态创建一个对应的新AnalyticsEvent 结构体实例。例如，log_event("login", params: ["method": "email"])应该被转换为Logger.shared.track(event: AnalyticsEvent(name: "login", params: ["method": "email"]))。如果 params为 nil，则转换后的params 应为空字典。”
  - AI 内心独白: “这是一个模式转换任务，而不仅仅是文本替换。我理解了源模式和目标模式。我需要在每个调用点动态地构建一个新的 AnalyticsEvent 实例，并处理 params 为可选的情况。这是一个结构性的、有状态的重构。”
  - 结果: AI 精确地完成了大规模、复杂的重构，正确处理了各种情况，生成的代码可以直接编译通过。

第二部分: `.cursorrules` 的艺术

这是你将个人智慧和团队共识规模化赋能给 AI 的核心机制。

洞见 3: 它是"判例法"，而非"成文法"

核心阐述: AI 对具体的、有对比的示例学习效果最好。规则文件应由一个个具体的"案例"组成。

场景: 制定 C++ API 封装规范（真实项目案例）

Level 1: 低密度规则（成文法 - 模糊不清）
- 规则内容:
```
## C++ API 封装规范
- 所有 C++ API 必须通过 Helper 封装访问
- 避免直接调用底层 API
```
- AI 内心独白: "好的，要用 Helper。但什么是 Helper？有哪些 Helper？怎么访问它们？是全局单例还是实例方法？我只能猜最常见的用法。"
- 结果: AI 依然会使用它最熟悉的全局单例模式，规则几乎没有起到约束作用。
Level 2: 中密度规则 (带简单示例的成文法)
- 规则内容:
```
## C++ API 封装规范
使用 ZMUserHelper 访问用户相关的 C++ API。

示例:
```objc
  ICmmUser *user = [helper getCmmUserById:userId];
```
- AI 内心独白: "OK，我看到了一个好的示例。但 helper 这个变量从哪来？是 [ZMUserHelper sharedHelper] 吗？还是从某个地方传入的？我需要自己判断。"
- 结果: AI 会尝试模仿方法调用，但可能错误地使用全局单例，不符合项目的 Session-Aware 架构。

Level 3: 高密度规则 (判例法 - 对比+理由)

规则内容:

### Part 7: C++ API 封装规范

#### **核心原则**: 
- 优先使用 Helper 封装 C++ API
- 使用 Session-Aware 方式访问
- 避免直接调用全局单例

#### ❌ 错误: 直接调用全局单例 Helper
*   **风险**: 
    - 不支持多会议场景（BO/Breakout Room、GR/Green Room）
    - 违反项目的 Session 架构设计
    - 在多会议并存时会导致数据混乱
*   **代码**:
    ```objc
    // Bad - 使用全局单例，无法区分不同会议
    ICmmUser *user = [[ZMUserHelper sharedHelper] getCmmUserById:userId];
    ICmmUserList *userList = [[ZMUserHelper sharedHelper] getCmmUserList];
    ```

#### ✅ 正确: 使用 Session-Aware 方式访问
*   **理由**: 
    - 明确指定是哪个会议的数据（defaultSession = 主会议）
    - 支持 BO/GR 等多会议场景
    - 符合项目架构，易于测试和维护
*   **代码**:
    ```objc
    // Good - 通过 Session 访问，明确上下文
    ICmmUser *user = [ZMConfSession.defaultSession.zmUserHelper getCmmUserById:userId];
    ICmmUserList *userList = [ZMConfSession.defaultSession.zmUserHelper getCmmUserList];
    
    // 在 BO 中需要访问主会议数据时
    ICmmUser *mainUser = [ZMConfSession.boMasterSession.zmUserHelper getCmmUserById:userId];
    ```

#### 📋 Helper 职责划分（避免混淆）
| Helper | 职责 | 方法类型 | 典型用法 |
|--------|------|---------|---------|
| **ZMConfHelper** | C++ API 对象访问 | 类方法 | `[ZMConfHelper getConfApi]` |
| **ZPConfHelper** | 会议业务逻辑 | 实例方法 | `[[ZPConfHelper sharedConfHelper] lockMeeting]` |
| **ZMUserHelper** | 用户数据管理 | 实例方法 | `[session.zmUserHelper getCmmUserById:]` |

AI 内心独白: "极其清晰！我完全理解了上下文：
1. 这个项目有多会议支持（BO/GR），所以需要明确 Session
2. 我不仅知道了要做什么（用 session.zmUserHelper），还知道了不能做什么（全局单例）
3. 我理解了为什么（支持多会议、符合架构）
4. 我知道了不同 Helper 的职责划分，不会混淆使用场景
现在我生成的所有 C++ API 访问代码都会遵循 Session-Aware 模式。"
结果: AI 生成的所有 C++ API 访问代码都将是符合项目架构的、支持多会议场景的、可维护的。

第三部分: 对 AI 进行编程的艺术

洞见 4: CRISPE - 编写零熵增提示词的终极框架

核心阐述: 一个完美的提示词，就像一个完美的函数调用：它有明确的上下文、角色、意图、步骤、禁忌和输出格式。

CRISPE 六要素详解

要素	含义	问题	目的
C	Context (上下文)	AI 需要知道什么？	提供环境信息
R	Role (角色)	AI 需要扮演谁？	激活专业知识
I	Intent (意图)	我到底想让 AI 做什么？	明确最终目标
S	Steps (步骤)	我希望 AI 如何一步步思考？	控制执行逻辑
P	Prohibitions (禁忌)	AI 绝对不能做什么？	设置安全边界
E	Example/Format (范例)	最终输出应该是什么样子？	定义输出格式

C - Context (上下文): 精准投喂，而非填鸭

基础做法: 粘贴代码或文件名。
专家做法: 只使用 @ 引用。这不仅仅是快捷方式，这是在告诉 AI："去参考那个单一事实来源 (Single Source of Truth)，而不是我粘贴的这个可能过时的副本。"
- @ZCCBaseView.h: 引用头文件定义。
- @.cursorrules: 引用你的"宪法"。
- @/Tests/MyTests.swift: 引用测试文件。
高密度技巧: "@ZCCBaseView.h @MyAnimationHelper.h 根据头文件 A 和辅助类 B..."，用多个 @ 符号为 AI 构建一个最小化的、完整的认知环境。

R - Role (角色): 激活 AI 的"专业知识图谱"

基础做法: "帮我写代码。"
专家做法: 为 AI 分配一个极其具体的专家角色。这会激活它模型中与该角色相关的特定知识、行话和思维模式。
- ✅ "你是一位精通 AppKit 和 Core Animation 的苹果首席工程师..."
- ✅ "你是一位对代码可读性和可维护性有洁癖的架构师..."
- ✅ "你是一位只编写最高效、最安全 C++ 代码的系统程序员..."
高密度技巧: 赋予角色一个目标。"你是一位安全专员，你的唯一目标是找出并修复这段代码中所有可能的内存泄漏和竞态条件。" 这会极大地聚焦 AI 的注意力。

I - Intent (意图): 单一、清晰、无歧义

基础做法: "修改这个 View。"
专家做法: 用一句话清晰表达你的最终目标和核心约束。
- ✅ "我的意图是在 ZCCBaseView 的右上角，添加一个高性能、低功耗的时间标签。"
- ✅ "我的意图是将这个同步的网络请求重构为异步，但不能破坏现有的调用方接口。"
黄金法则: 意图必须回答 "为什么要这么做？" 而不仅仅是 "做什么？"。当 AI 理解了"为什么"，它才能做出智能的决策。

S - Steps (步骤): 将你的"心理模拟"显性化

基础做法: 不提供步骤，让 AI 自己决定。
专家做法: 将你大脑中的思维流程显性化，变成一个清晰的执行计划。
- ✅ "请严格遵循以下步骤：1. 声明私有属性。2. 初始化并配置。3. 添加到视图树。4. 实现更新方法。"
高密度技巧: 在关键步骤中嵌入验证点。"步骤3: 添加到视图树。在这一步之后，调用 lldb命令验证_timeLabel 的 superview 不为 nil。"

P - Prohibitions (禁忌): 你的"安全护栏"

基础做法: 不设置禁忌。
专家做法: 明确列出 AI 绝对不能做的事情。这是你项目特定约束的体现。
- ✅ "绝对禁止在 updateWithTime: 方法中调用 setNeedsDisplay:YES。"
- ✅ "禁止使用任何第三方库，只能使用系统框架。"
- ✅ "禁止修改任何现有的公共 API 签名。"
心理学原理: 负面约束比正面指令更容易被 AI 模型"记住"。明确的禁忌能显著降低 AI 犯错的概率。

E - Example/Format (范例/格式): 消除最后的歧义

基础做法: 不提供输出示例。
专家做法: 给出一个具体的输出示例，或明确的格式要求。
- ✅ "最终，请直接修改 .h 和 .m 文件，确保所有新代码的风格、注释和 #pragma mark 的使用，都与现有代码 100% 一致。"
- ✅ "输出格式：Markdown 文档，包含三个部分：问题分析、解决方案、风险评估。"
- ✅ "请以一个可以直接运行的 Swift Playground 文件的形式输出。"

完整示例: 在视频 View `ZCCBaseView` 的右上角添加一个时间标签

*   #### **Level 1: 低密度提示 (初学者 - “许愿式”)**
    *   **提示词**: `“在 ZCCBaseView 的右上角加一个时间标签。”`
    *   **AI 内心独白**: “右上角？边距？字体？颜色？更新逻辑？用什么控件？我全都要猜...”
    *   **结果**: 失败率极高，几乎肯定需要你手动重写。

*   #### **Level 2: 中密度提示 (熟练工 - “指令式”)**
    *   **提示词**: `“修改 ZCCBaseView，在右上角添加一个 NSTextField 作为时间标签，边距 8pt，白色 12pt 字体。创建一个 updateWithTime:(NSTimeInterval)time 的方法来更新 MM:SS 格式的时间。”`
    *   **AI 内心独白**: “指令很清晰。我会用 Auto Layout，创建一个 `NSDateComponentsFormatter`，然后把 Label 声明为私有属性。这应该够了。”
    *   **结果**: 功能基本正确，但可能不符合项目的性能要求（如手动布局 vs Auto Layout）或特定规范。

*   #### **Level 3: 高密度意图 (专家 - “CRISPE 框架”)**
    *   **提示词**:
        ```
        [R]你是一位资深的 macOS AppKit 性能优化专家。

        [C]请参考 @ZCCBaseView.h, @ZCCBaseView.m, 以及我们项目中关于 UI 控件和图层性能的 @.cursorrules 规范。

        [I]我的意图是在 ZCCBaseView 的右上角，添加一个高性能、低功耗的时间标签。这个标签会每秒更新一次，所以性能和避免不必要的重绘是首要目标。

        [S]请严格遵循以下步骤来实现：
        1.  **声明**: 在 .m 的类扩展中，声明私有的 `_timeLabel` (NSTextField) 和 `_timeFormatter`。
        2.  **初始化**: 在 `initWithFrame:` 中，配置好 `_timeFormatter`，然后初始化 `_timeLabel`。
        3.  **样式与性能**: 对 `_timeLabel` 调用 `setWantsLayer:YES]` 把它变成一个 layer-backed view 以优化重绘。
        4.  **布局**: **禁止**使用 Auto Layout。在 `viewDidMoveToSuperview` 中手动计算并设置 `_timeLabel` 的 frame。
        5.  **更新接口**: 在 .h 中声明公共方法 `-(void)updateWithTime:(NSTimeInterval)time;` 并在 .m 中实现。

        [P]请注意以下禁忌：
        -   **绝对禁止**在 `updateWithTime:` 方法中调用 `setNeedsDisplay:YES`。
        -   **禁止**使用 `CATextLayer`。

        [E]最终，请直接修改 .h 和 .m 文件，确保所有新代码的风格、注释和 `#pragma mark` 的使用，都与现有代码 100% 一致。
        ```
    *   **AI 内心独白**: “这是一个**专家级**的指令。我不仅知道了所有实现细节，更重要的是理解了**背后的性能意图**。`setWantsLayer:YES` 和手动布局是关键。我必须严格遵循所有步骤和禁忌，确保最终产出是高性能且符合规范的。”
    *   **结果**: 生成的代码是生产级的，完全符合项目的特定性能要求和编码规范。

*   #### **进化总结**

密度	提问方式	核心理念	产出质量
低	许愿	“AI 你猜”	几乎不可用
中	指令	“AI 你做”	功能可用，细节缺失
高	意图编程	"AI 我们一起思考和构建"	生产级、符合规范、高性能

洞见 4.5: 其他主流 Prompt 框架对比 (RACE、TREE、TCR)

除了 CRISPE，业界还有其他几个主流的 Prompt 框架。了解它们的优劣，可以帮助你根据场景选择最合适的框架。

框架对比表

框架	核心要素	复杂度	适用场景	优势	劣势
CRISPE	6 要素	⭐⭐⭐⭐⭐	复杂任务、团队协作	最完整、最严谨	编写耗时
RACE	4 要素	⭐⭐⭐☆☆	快速任务、日常开发	简洁、易记	缺少步骤和示例
TREE	4 要素	⭐⭐⭐⭐☆	结构化任务	强调需求和示例	缺少角色和禁忌
TCR	3 要素	⭐⭐☆☆☆	简单查询	极简、快速	缺少细节控制

RACE 框架: 快速任务的最佳选择

RACE = Role + Action + Context + Expectation

R - Role (角色)
A - Action (行动)
C - Context (上下文)
E - Expectation (期望)

示例: 优化一个慢查询

[R] 你是一位数据库性能优化专家。

[A] 请优化这个 SQL 查询，它目前需要 3 秒才能返回结果。

[C] 这是一个电商系统的订单查询，数据库是 PostgreSQL 12，orders 表有 500 万条记录，已有 user_id 和 created_at 的索引。

[E] 我期望查询时间降低到 500ms 以内，并保持查询结果一致。

原始查询:
SELECT * FROM orders 
WHERE user_id = 12345 
  AND status = 'completed' 
  AND created_at > '2024-01-01'
ORDER BY created_at DESC;

RACE 的优势:

简洁: 只有 4 个要素，容易记忆
快速: 适合日常快速任务
聚焦结果: Expectation 明确了成功标准

RACE 的劣势:

缺少步骤引导: 没有 Steps，AI 可能跳过关键步骤
缺少负面约束: 没有 Prohibitions，AI 可能犯禁忌错误
缺少输出格式: 没有 Example，输出可能不符合预期格式

适用场景:

单次性的快速任务
低风险的代码修改
探索性的问题咨询

TREE 框架: 结构化任务的平衡选择

TREE = Task + Requirements + Expectations + Example

T - Task (任务)
R - Requirements (需求)
E - Expectations (期望)
E - Example (示例)

示例: 创建一个用户认证中间件

[T] 创建一个 Express.js 的用户认证中间件，验证 JWT token。

[R] 技术需求:
- 使用 jsonwebtoken 库
- 支持 Bearer Token 格式
- 从 Authorization header 读取 token
- 将解码后的用户信息附加到 req.user
- 处理 token 过期和无效的情况

[E] 期望:
- 代码符合 ES6+ 规范
- 包含完整的错误处理
- 有清晰的注释
- 性能开销 < 5ms

[E] 参考示例:
app.use(authMiddleware);

app.get('/protected', (req, res) => {
    console.log(req.user); // { id: 123, email: 'user@example.com' }
    res.json({ message: 'Success' });
});

TREE 的优势:

强调需求: Requirements 部分非常详细
包含示例: Example 帮助 AI 理解使用方式
结构清晰: 逻辑顺序自然

TREE 的劣势:

缺少角色: 没有 Role，AI 可能缺乏专业视角
缺少步骤: 没有明确的执行步骤
缺少禁忌: 没有负面约束

适用场景:

功能性开发任务
有明确技术规范的场景
需要参考示例的任务

TCR 框架: 简单查询的极简选择

TCR = Task + Context + Reference

T - Task (任务)
C - Context (上下文)
R - Reference (参考)

示例: 解释一段代码

[T] 解释这段代码的工作原理，特别是 reduce 方法的用法。

[C] 这是一个 JavaScript 数组处理函数，用于统计单词出现次数。

[R] 参考代码:
const words = ['apple', 'banana', 'apple', 'orange', 'banana', 'apple'];
const count = words.reduce((acc, word) => {
    acc[word] = (acc[word] || 0) + 1;
    return acc;
}, {});

TCR 的优势:

极简: 只有 3 个要素，最快速
适合学习: 特别适合"理解型"查询
低门槛: 初学者也能快速上手

TCR 的劣势:

缺少细节控制: 无法精确控制输出
不适合复杂任务: 对于生产级代码力不从心
缺少质量保证: 没有期望和禁忌

适用场景:

代码解释和学习
简单的查询任务
探索性的问题

框架选择决策树

我的任务是什么类型？
    ↓
├─ 探索/学习型（"这是什么？"）
│   → 使用 TCR ⭐⭐⭐
│   → 示例: 解释代码、查询语法、理解概念
│
├─ 快速执行型（"帮我改一下"）
│   → 使用 RACE ⭐⭐⭐⭐
│   → 示例: Bug 修复、简单功能、日常任务
│
├─ 结构化开发型（"实现一个功能"）
│   → 使用 TREE ⭐⭐⭐⭐
│   → 示例: 新功能开发、中间件、工具函数
│
└─ 复杂系统型（"设计并实现"）
    → 使用 CRISPE ⭐⭐⭐⭐⭐
    → 示例: 核心模块、架构级任务、团队协作

同一任务用不同框架的对比示例

任务: 为 Swift 项目添加网络请求缓存

使用 TCR (极简)

[T] 为我的 Swift 网络层添加缓存功能。
[C] 使用 Moya + Alamofire，需要支持内存和磁盘缓存。
[R] 参考 NSCache 和 URLCache 的用法。

预期效果: ⭐⭐☆☆☆ - 能得到基本实现，但缺少细节

使用 RACE (快速)

[R] 你是一位 iOS 网络优化专家。
[A] 为 Moya 网络层添加两级缓存（内存 + 磁盘）。
[C] 项目使用 Moya 15.0，Alamofire 5.6，iOS 13+。
[E] 期望内存缓存 30 秒，磁盘缓存 24 小时，缓存命中率 >80%。

预期效果: ⭐⭐⭐⭐☆ - 能得到较好的实现，但可能缺少边缘情况处理

使用 TREE (平衡)

[T] 为 Moya 网络层实现一个高性能的两级缓存系统。

[R] 需求:
- 内存缓存使用 NSCache（30 秒有效期）
- 磁盘缓存使用 FileManager（24 小时有效期）
- 支持缓存策略配置（可禁用缓存）
- 线程安全
- 有清理过期缓存的机制

[E] 期望:
- 代码覆盖 CRUD 操作
- 有完整的错误处理
- 符合 SOLID 原则
- 包含单元测试示例

[E] 参考接口:
cacheManager.set(data, forKey: "user_profile", expiry: 30)
let cached = cacheManager.get(forKey: "user_profile")

预期效果: ⭐⭐⭐⭐⭐ - 能得到高质量实现，但可能缺少性能优化细节

使用 CRISPE (完整)

[C] @NetworkCacheManager.swift @MoyaProvider.swift @.cursorrules
    这是我们项目的网络层，基于 Moya 15.0。

[R] 你是一位专注于移动端性能优化的 iOS 架构师。

[I] 我的意图是实现一个生产级的、高性能的两级缓存系统，解决频繁网络请求导致的流量消耗和响应慢的问题。

[S] 实现步骤:
1. 创建 `NetworkCacheManager` 单例，管理内存和磁盘缓存
2. 实现内存缓存（NSCache），30 秒有效期，最多缓存 50 个对象
3. 实现磁盘缓存（FileManager），24 小时有效期，使用 MD5 作为文件名
4. 创建 Moya 插件 `CachePlugin`，拦截请求和响应
5. 在插件中实现缓存读写逻辑（先查内存，再查磁盘）
6. 实现后台清理机制，定期删除过期缓存
7. 添加缓存统计功能（命中率、大小）

[P] 禁忌:
- 禁止在主线程进行磁盘 I/O
- 禁止无限增长的缓存（必须有清理机制）
- 禁止缓存敏感数据（如用户密码、token）
- 禁止使用全局锁（会影响性能）

[E] 最终输出:
- NetworkCacheManager.swift（缓存管理器）
- CachePlugin.swift（Moya 插件）
- NetworkCacheManagerTests.swift（单元测试）
- 所有代码符合 Swift 5+ 规范，包含完整注释

预期效果: ⭐⭐⭐⭐⭐ - 完美的生产级实现，考虑了所有细节

框架对比总结表

维度	TCR	RACE	TREE	CRISPE
学习成本	⭐☆☆☆☆	⭐⭐☆☆☆	⭐⭐⭐☆☆	⭐⭐⭐⭐☆
编写时间	30秒	1-2分钟	2-3分钟	5-10分钟
输出质量	⭐⭐☆☆☆	⭐⭐⭐⭐☆	⭐⭐⭐⭐☆	⭐⭐⭐⭐⭐
适用复杂度	简单	中等	中高	高
团队协作	不适合	一般	适合	非常适合
可维护性	低	中	高	极高

实战建议: 根据场景选择框架

日常开发 80% 的场景: 使用 RACE，快速且够用
新功能开发: 使用 TREE，结构化且完整
核心模块、团队协作: 使用 CRISPE，最高质量保证
快速查询、学习: 使用 TCR，最简单

渐进式策略:

第一次尝试: TCR（快速验证想法）
    ↓
效果不理想
    ↓
第二次尝试: RACE（增加细节）
    ↓
还不理想
    ↓
第三次尝试: TREE（结构化）
    ↓
依然需要更高质量
    ↓
终极版本: CRISPE（生产级）

记忆口诀:

TCR: "快问快答"
RACE: "角色行动有期待"
TREE: "任务需求加示范"
CRISPE: "六要素，无遗漏"

第四部分: 高级功能与工作流 (The "Power Plays")

洞见 5: `Follow-up` - 迭代式生成

核心阐述: 利用追问功能，将复杂任务分解成多个逻辑连贯的小步骤，如同与真人结对编程。
场景: 创建一个用户注册的 ViewModel
- Level 1: 低密度 (一次性)
  - 提示词: “创建一个 UserRegistrationViewModel，处理用户名、密码，并有一个提交按钮”
  - 结果: 一个巨大的、包含所有逻辑的初始版本，难以审查和修改。
- Level 3: 高密度 (迭代式)
  1. 初始 Prompt: “创建一个名为 UserRegistrationViewModel 的 Swift 文件，让它遵循 ObservableObject 协议。”
  2. Follow-up 1: “很好。现在为 ViewModel 添加 username和password 两个 @Published 属性。”
  3. Follow-up 2: “接下来，添加一个名为 isSubmitButtonEnabled 的计算属性，它应该是一个 Combine Publisher，只有当用户名长度超过6且密码不为空时，才发布 true。”
  4. Follow-up 3: “最后，添加一个 submit()的 async 方法，在里面模拟一个网络请求，并处理isLoading 状态。”
  - 结果: 每一步都是一个小的、可验证的变更，最终构建出一个结构清晰、逻辑严谨的 ViewModel。

洞见 6: "苏格拉底式对话" - 共同推理，而非索要答案

核心阐述: 对于复杂问题，通过一系列引导性问题，强迫 AI 与你一起进行结构化的、分步骤的推理。
场景: 诊断一个随机的并发 Bug
- Level 1: 低密度 (直接索要)
  - 提示词: "修复这个 Bug"
  - AI 内心独白: "这是什么 Bug？在哪里？什么症状？我只能根据经验猜一个最常见的并发问题，比如添加几个锁。"
  - 结果: AI 可能会猜一个方案，很可能错误或治标不治本。
- Level 2: 中密度 (提供信息)
  - 提示词: "这是崩溃日志和代码，帮我修复。"
  - AI 内心独白: "好，我看到了日志，有个 EXC_BAD_ACCESS。可能是访问了已释放的内存，或者线程安全问题。我试试在可疑的地方加锁。"
  - 结果: AI 的分析会更准确，但仍是黑盒，你不清楚它的推理过程，也无法验证。
- Level 3: 高密度 (引导推理)
  - 对话流程:
    1. 你: "@CrashLog.txt @MyService.mm 这是日志和代码。这个崩溃的核心问题是什么？请列出三种最可能的原因，并给出你的置信度分数（总和 100%）。"
    2. AI: "根据日志分析：原因1: 线程安全问题 - 多个线程同时访问 _sharedCache (70%); 原因2: API返回nil但未检查 (20%); 原因3: 过度释放导致野指针 (10%)"
    3. 你: "很好。我们聚焦原因1。请检查代码中所有对共享状态 _sharedCache 的访问，并指出哪些地方缺少线程锁保护。给出具体的行号和方法名。"
    4. AI: "在 methodA(第45行) 和methodB(第78行) 中，都对_sharedCache 进行了读写，但没有任何同步机制。"
    5. 你: "完全正确。现在，使用 @synchronized(_sharedCache) 块来修复这两个地方。生成最终的代码，并确保不会引入死锁。"
  - AI 内心独白: "这是一个协作式的推理过程。我不是被要求给出一个最终答案，而是被引导着一步步分析、定位、验证，最后才执行修复。这让我的每一步推理都是可见和可验证的。"
  - 结果: 你掌控了整个问题的分析和解决流程，AI 是你强大的推理伙伴，最终方案是经过充分验证的。

洞见 7: `@Terminal` - 你的 AI DevOps 伙伴

核心阐述: 将自然语言意图翻译成精确的 shell 命令，解放你从"记忆语法"的负担。
场景: 需要一个复杂的 git 操作
- Level 1: 低密度 (Google + 复制粘贴)
  - 行为: 在 Google 搜索 "git rebase interactive squash commits"，找到一个 Stack Overflow 答案，复制命令，尝试理解并修改参数。
  - 结果: 耗时 10-15 分钟，可能还是不完全理解，容易出错。
- Level 3: 高密度 (自然语言命令生成)
  - 提示词: @Terminal 我需要一个 git 操作。我想把最近的 3 个 commit 合并成一个，新的 commit 信息是 "feat: Add user authentication"。请生成完整的交互式 rebase 命令，并告诉我在编辑器中应该做什么修改。
  - AI 输出:
```
# Step 1: Start interactive rebase for last 3 commits
git rebase -i HEAD~3

# Step 2: In the editor that opens, you'll see something like:
# pick abc1234 First commit
# pick def5678 Second commit
# pick ghi9012 Third commit
# 
# Change it to:
# pick abc1234 First commit
# squash def5678 Second commit
# squash ghi9012 Third commit
#
# Save and close the editor.

# Step 3: In the next editor, replace all commit messages with:
# feat: Add user authentication
#
# Save and close.

# Done! Your 3 commits are now squashed into one.
```
  - 结果: 1-2 分钟内得到了完整、正确的命令和清晰的操作指南。

第五部分: 批判性思维与未来洞见 (The "How to Judge & Evolve")

洞见 8: 警惕新的“技术债” - “理解黑洞”

核心阐述: 新的技术债是你完全不理解 AI 生成的核心逻辑。
黄金法则: 你可以让 AI 实现 90% 的代码，但你必须能向别人解释 100% 的代码。
场景: AI 为了“优化”一段排序代码，使用了一个你从未见过的、复杂的“基数排序”算法。
- Level 1: 低密度思维 (盲目信任)
  - 行为: “看起来很厉害，代码也变少了，接受！”
  - 结果: 当这个排序在某个边缘情况下出现 bug 时，你完全不知道如何调试，因为它是一个“理解黑洞”。
- Level 3: 高密度思维 (要求解释)
  - 行为: “这个实现看起来很复杂。请用简单的语言向我解释什么是基数排序，它的时间复杂度和空间复杂度是多少，以及在这个特定场景下，它相比于简单的 sort() 方法有什么优势和潜在风险。”
  - 结果: 你做出了一个知情决策。你可能依然接受了 AI 的方案，但现在你理解了它的工作原理和权衡，你拥有了未来维护它的能力。

洞见 9: 重新定义"资深"

核心阐述: AI 极大地压缩了在"代码实现"层面的技能差距。资深工程师的价值必须重新定义。
资深的新价值 (四大核心能力):
1. 意图的澄清与分解能力: 能够将模糊的需求，分解成清晰、无歧义、AI 可执行的一系列任务。
2. 知识的固化与编码能力: 能够将自己的隐性经验和团队的最佳实践，编码成高质量的 .cursorrules。
3. 系统的审美与权衡能力: 在 AI 提供的多个方案中，做出那个**"最有智慧"**的选择。
4. 对 AI 输出的批判性思维: 能够快速识别 AI 生成代码中的潜在问题并修正。

洞见 10: "认知卸载"的悖论

核心阐述: 过度的"认知卸载"可能会导致关键思维能力的系统性退化。
类比: GPS 让我们不再需要记路，但也让我们丧失了辨别方向的能力。
对抗"能力退化"的策略:
1. "教学相长": 强制要求工程师向 AI 解释他们为什么要做某个决策。
2. 深度 Code Review: 定期进行深度审查会议，要求工程师在不看代码的情况下，解释模块的核心逻辑。

洞见 11: `.cursorrules` 的跨项目复用策略(已存在)

核心阐述: 规则文件本身也是代码，应该像代码一样被版本管理、模块化和复用。
从"复制粘贴"到"依赖管理"的进化:
- Level 1: 原始方式 - 复制粘贴
  - 每个项目都复制一份完整的 .cursorrules。
  - 问题: 当你改进了某个规则，需要手动同步到所有项目，极易出现不一致。
- Level 2: Git Submodule 方式
  - 创建一个 shared-cursorrules Git 仓库。
  - 在每个项目中将其作为 submodule 引入。
  - 项目的 .cursorrules 内容：
```
# 引用共享规则
本项目遵循我们团队的通用规范，详见 `@.cursor/rules/shared/`.

## 项目特定规则
[在此添加本项目特有的规则]
```
  - 优势: 共享规则的更新可以通过 git submodule update 一键同步。
- Level 3: 符号链接 (Symlink) 方式 (适用于本地多项目)
  - 在一个中心位置维护 ~/Developer/shared-cursor-rules/。
  - 在每个项目中创建符号链接：
```
cd MyProject
ln -s ~/Developer/shared-cursor-rules/.cursorrules-base .cursorrules-base
```
  - 项目的 .cursorrules 引用基础规则：
```
# 导入基础规则
请先阅读 @.cursorrules-base 中的基础规范。

## 本项目额外规则
[项目特定规则]
```
  - 优势: 修改一次，立即生效于所有项目。
- Level 4: 动态生成方式 (高级)
  - 编写一个脚本（如 generate-cursorrules.sh），它根据项目类型自动生成 .cursorrules。
  - 示例：
```
#!/bin/bash
# 检测项目类型
if [ -f "Package.swift" ]; then
    cat ~/shared-rules/swift-base.md > .cursorrules
    cat ~/shared-rules/spm-specific.md >> .cursorrules
elif [ -f "Podfile" ]; then
    cat ~/shared-rules/swift-base.md > .cursorrules
    cat ~/shared-rules/cocoapods-specific.md >> .cursorrules
fi

# 添加项目特定规则
cat .cursorrules.local >> .cursorrules
```
  - 优势: 完全自动化，规则可以根据项目配置动态组合。

洞见 12: "代码的巴别塔"的倒塌 - 语言的"去神圣化"

核心阐述: AI 正在成为一个通用的、实时的代码翻译和生成引擎，极大地降低技术栈的选择成本和迁移成本。
场景: 将一个 React 组件迁移到 SwiftUI
- 旧世界 (无 AI)
  - 耗时: 需要一个同时精通 React 和 SwiftUI 的工程师，可能需要 1-2 天。
  - 风险: 高，容易遗漏状态管理或生命周期的细节。
- 新世界 (有 AI)
  - 提示词:
```
@MyReactComponent.jsx 这是一个 React 组件。请将它翻译成 SwiftUI。

翻译规则：
1. 保持相同的 UI 布局和交互逻辑。
2. 将 React 的 useState 转换为 SwiftUI 的 @State。
3. 将 useEffect 转换为 .onAppear 或 .onChange。
4. 将 props 转换为 SwiftUI View 的 init 参数。
5. 保持相同的命名约定。
```
  - 耗时: 可能 30 分钟到 1 小时（包括人工验证）。
  - 结果: 功能上等价的 SwiftUI 代码。
第二序效应 (长期影响):
- Polyglot by Default: 工程师将不再被限定为"Swift 工程师"或"Go 工程师"，而是成为**"问题解决工程师"**。他们将根据问题的性质选择最合适的语言，并由 AI 辅助完成实现。
- 遗留代码的"液化": 遗留系统不再是需要完全重写的"技术债"，而是可以被 AI 逐步、增量、低成本地翻译和现代化的"可流动资产"。
- 技能的"半衰期"延长: 你在学习某个语言时积累的问题分解能力、架构思维、算法知识，可以通过 AI 零成本地"转移"到任何其他语言。技能的本质从"记忆语法"转变为"理解原理"。

洞见 13: "新的技术债形式

核心阐述: 当你的代码库过度依赖某个特定 AI 模型的"怪癖"和"风格"时，迁移到其他 AI 的成本会变得极高。
场景: 你的项目大量使用了 Cursor 特有的 @ 语法和规则系统
- 风险 1: 供应商锁定: 如果 Cursor 突然倒闭或价格暴涨，你的团队会面临巨大的迁移成本。
- 风险 2: 模型依赖: 如果你的 .cursorrules 严重依赖 Claude 的某些特定能力（如对 Objective-C++ 的理解），当 Cursor 切换到另一个模型时，你的规则可能会失效。
对抗策略:
1. 编写"模型无关"的规则: 规则应该依赖于普适的编程原则，而不是某个模型的特定行为。
2. 定期进行"迁移演练": 每季度尝试将一个小项目迁移到另一个 AI 工具（如 GitHub Copilot、Windsurf），评估迁移成本。
3. 保持核心逻辑的"人类可读性": 确保即使没有 AI，你的代码库依然是清晰、可维护的。AI 应该是加速器，而不是必需品。

洞见 14: "AI-Native Architecture" - 为 AI 可理解性而设计

核心阐述: 未来的代码架构，不仅要考虑"人类可读性"，还要考虑"AI 可理解性"。这将影响我们的命名、结构和文档策略。
什么是 AI 友好的代码？
- 特征 1: 显性优于隐性
  - 传统代码 (隐性约定):
```
// 团队约定：所有网络请求的 completion 都在主线程
func fetchData(completion: @escaping (Result<Data, Error>) -> Void) {
    // ... 实现
}
```
  - AI 友好代码 (显性声明):
```
/// Fetches data from the server.
/// - Important: The completion handler is **always** called on the main thread.
/// - Parameter completion: A closure called with the result.
func fetchData(completion: @escaping @MainActor (Result<Data, Error>) -> Void) {
    // ... 实现
}
```
  - 为什么: AI 没有参与过你们的团队会议，它只能从代码本身学习。显性的类型标注（@MainActor）和文档注释让 AI 能正确理解约定。
- 特征 2: 统一的命名模式
  - 不友好 (混乱的命名):
```
func getUser() -> User
func retrieveProfile() -> Profile
func fetchSettings() -> Settings
```
  - AI 友好 (统一的模式):
```
func fetchUser() -> User
func fetchProfile() -> Profile
func fetchSettings() -> Settings
```
  - 为什么: 统一的动词前缀（如 fetch*、update*、delete*）让 AI 能快速推断出方法的类别和行为。
- 特征 3: 丰富的类型信息
  - 不友好 :
```
func processData(_ data: Any) -> Any
```
  - AI 友好 (强类型):
```
func processUserData(_ data: UserData) -> ProcessedUserData
```
  - 为什么: 强类型系统是 AI 理解代码意图的Source of truth。类型信息越丰富，AI 的推理越准确。
- 特征 4: 小而专注的模块
  - 不友好: 一个 3000 行的 ViewController，包含 UI、网络、数据库、业务逻辑。
  - AI 友好: 将其拆分为：
    - UserListViewController (UI)
    - UserListViewModel (业务逻辑)
    - UserRepository (数据访问)
    - UserNetworkService (网络请求)
  - 为什么: 小模块的上下文更少，AI 更容易在不产生歧义的情况下理解和修改它们。
第二序效应: 当你为 AI 优化代码时，你实际上也在为未来的人类维护者优化代码。AI 友好性和可维护性高度重合。

洞见 15: "对话即资产"

核心问题: 你在项目 A 中与 Cursor 进行了深入的架构讨论，积累了大量有价值的上下文。如何让这些知识在项目 B 中也能被利用？

解决方案分级:

Level 1: 手动复制粘贴 (原始但有效)
- 方法: 将重要的对话片段复制到一个 Markdown 文件（如 architecture-decisions.md），放在项目根目录。
- 在新对话中引用: @architecture-decisions.md 请参考这份文档中记录的我们之前的架构决策。
- 优势: 简单直接，适合关键决策的记录。
- 劣势: 手动维护，容易遗漏。

Level 2: 将对话抽离到 `.cursorrules`

核心理念: 对话历史中的大部分内容是"案例研究"，应该被提炼为规则。
提炼过程:
1. 识别模式: 回顾最近的 10 次对话，找出重复出现的问题或决策。
2. 提炼原则: 例如，如果 AI 多次错误地使用了某个 API，说明需要一条规则明确禁止或指导。
3. 编码到规则: 将这个模式编码到 .cursorrules 中。

示例对话片段:

你: "为什么你使用了 URLSession 而不是我们的 NetworkManager？"
AI: "抱歉，我没有看到项目中有专用的 NetworkManager。"
你: "它在 @Core/NetworkManager.swift 中。请以后都使用它。"

提炼为规则:

## Part 6: 网络请求规范

#### ✅ 正确: 使用项目的 NetworkManager
所有网络请求必须通过 `Core/NetworkManager.swift` 进行，禁止直接使用 `URLSession`。

```swift
// Good
NetworkManager.shared.request(.getUserProfile(id: userId))

// Bad
URLSession.shared.dataTask(with: url) { ... }

Level 3: 使用 AI 辅助

Prompt 模板:

我将粘贴我最近一周与 Cursor 的对话历史（约 5000 字）。

你的任务是分析这些对话，提取出可以被编码为 .cursorrules 的**通用模式**。

对于每个模式，请输出：
1. 模式描述（问题是什么？）
2. 建议的规则（Markdown 格式，包含 ✅ 正确示例和 ❌ 错误示例）
3. 这条规则的优先级（高/中/低）

[在此粘贴对话历史]

优势: AI 能发现你可能忽略的模式，加速知识的系统化。

Level 4: 共享团队知识库 (终极方案)

架构:

~/team-knowledge-base/
├── architecture/
│   ├── api-design-decisions.md
│   ├── database-schema-evolution.md
│   └── microservices-boundaries.md
├── troubleshooting/
│   ├── common-bugs-and-fixes.md
│   └── performance-optimization-case-studies.md
└── .cursorrules-knowledge-base

在任何项目中使用:

在项目 .cursorrules 中添加：

## 引用团队知识库
请参考以下团队共享的知识文档：
- @~/team-knowledge-base/architecture/api-design-decisions.md
- @~/team-knowledge-base/troubleshooting/common-bugs-and-fixes.md

优势: 知识在团队和项目间流动，形成"组织记忆"。

洞见 16: Cursor 对团队结构的影响 - 从"组件团队"到"意图小队"

核心阐述: 当代码生成成本降至接近零时，团队的组织方式也应该随之改变。
旧世界的团队结构 (组件导向):
- iOS 团队: 负责所有 iOS 代码。
- 后端团队: 负责所有后端服务。
- 前端团队: 负责所有 Web 代码。
- 问题: 一个简单的功能（如"用户设置页面"）需要跨越 3 个团队，沟通成本极高。
新世界的团队结构 (意图导向):
- "用户体验小队": 一个 3-4 人的小团队，负责整个"用户设置"功能的端到端实现（iOS、Android、Web、后端 API）。
- 关键变化: 他们不再需要是每个技术栈的"专家"。他们只需要：
  1. 深刻理解用户需求和业务逻辑。
  2. 能够编写高质量的 Prompt。
  3. 能够审查和整合 AI 生成的代码。
- 优势: 极大地降低了跨团队沟通成本，加速了迭代。
新角色的出现:
- "AI Whisperer" (AI 低语者): 团队中专门负责优化 .cursorrules 和编写高密度 Prompt 的专家。
- "Integration Architect" (整合架构师): 负责审查 AI 生成的跨语言、跨平台代码，确保它们在系统层面的一致性和兼容性。

第六部分: AI最佳实践工作流

这是将所有能力整合，贯穿从产品到上线的完整工作流。

阶段 1: 从想法到产品规格 (Idea to Product Spec)

核心理念: 在写代码前，用 AI 澄清需求，发现边缘情况。
场景: 产品经理给了一个简单的用户故事：“作为用户，我希望能用 Apple ID 登录。”

高密度提示词:

你是一位顶尖的产品经理。将用户故事 “作为用户，我希望能用 Apple ID 登录” 扩展成一份小型产品需求文档 (PRD)。
请生成以下部分：
1.  **用户流程 (User Flow)**: 从用户点击“用 Apple 登录”按钮到进入 App 主页的每一步。
2.  **验收标准 (Acceptance Criteria)**: 以 Gherkin 格式 (Given/When/Then) 写出至少 5 条标准。
3.  **边缘情况与错误处理 (Edge Cases)**: 列出至少 5 种需要考虑的异常情况（如：用户取消授权、Apple ID 邮箱已注册、网络错误等）。

阶段 2: 从规格到技术设计 (Spec to Technical Design)

核心理念: 用 AI 快速生成技术文档、API 协议和架构图。
场景: 基于上一阶段的 PRD 进行技术设计。

高密度提示词:

你是一位资深的移动端架构师。基于上面的“Apple 登录”PRD，进行技术设计。
请生成：
1.  **API 协议**: 定义客户端发送给后端验证 Apple token 的 RESTful API 端点、请求体 (Request Body) 和可能的响应体 (Response Bodies)，使用 JSON 格式。
2.  **数据模型**: 创建在 iOS App 中使用的 `AppleUser` Swift `struct`。
3.  **架构图**: 使用 Mermaid 语法，绘制一个序列图，展示从用户点击按钮、App 调用 Apple API、App 发送 token 到后端、后端验证、直到 App 登录成功的完整流程。

阶段 3: 从设计到代码 (Design to Code - TDD 方式)

核心理念: 让 AI 先写测试，再写实现，确保代码的健壮性。这是真正的"测试驱动开发"。
场景: 实现 AppleSignInManager。

TDD 三步循环 (Red-Green-Refactor):

第一步: Red（写测试，确保它们失败）

高密度提示词:

你是一位测试驱动开发（TDD）的倡导者。基于上面的技术设计，为 `AppleSignInManager` 编写一个完整的 XCTest 测试文件。

测试需求：
1. 创建测试文件 `/Tests/Auth/AppleSignInManagerTests.swift`
2. 在测试中，假设 `AppleSignInManager` 类已经存在，并定义了以下接口：
   - `func signIn() async throws -> AppleUser`
   - `func signOut()`
3. 编写至少 5 个测试用例，覆盖：成功登录、用户取消、网络错误、token 无效、已登录状态
4. 使用 Mock 对象模拟 `AuthenticationServices` 的行为

注意：现在 `AppleSignInManager` 类还不存在，所以这些测试在编译时会失败。这是 TDD 的正常流程。

预期结果: 生成了测试文件，但由于 AppleSignInManager 类还不存在，项目无法编译。这是 TDD 的"Red"阶段。

第二步: Green（写最小实现，让测试通过）

高密度提示词:

@/Tests/Auth/AppleSignInManagerTests.swift 

现在，请查看这些测试用例，并创建 `/Sources/Auth/AppleSignInManager.swift` 文件。

实现要求：
1. 创建 `AppleSignInManager` 类，包含测试中用到的所有方法和属性
2. 实现核心逻辑，目标是让**所有测试用例都能通过**
3. 使用 `AuthenticationServices` 框架进行真实的 Apple 登录
4. 正确处理所有错误情况（用户取消、网络错误等）

这是 TDD 的"Green"阶段 - 用最简单、最直接的方式让测试通过。

预期结果: AppleSignInManager 被创建，所有测试通过（显示绿色✅）。

第三步: Refactor（重构，优化代码质量）

高密度提示词:

@/Sources/Auth/AppleSignInManager.swift @/Tests/Auth/AppleSignInManagerTests.swift

现在所有测试都通过了。请对实现代码进行重构，提升代码质量：
1. 提取重复的逻辑到私有方法
2. 改进错误处理和日志
3. 添加必要的文档注释
4. 优化性能（如果有明显的瓶颈）

重要约束：在重构过程中，确保所有测试依然保持通过状态。每次修改后都应该运行测试。

这是 TDD 的"Refactor"阶段 - 在测试的保护下安全地改进代码。

预期结果: 代码质量得到提升，但功能没有改变，所有测试依然通过。

TDD 的核心价值:
- 测试先行确保了你的代码是"可测试的"（没有隐藏的依赖）
- 所有功能都有测试覆盖，不会有"写完代码忘记测试"的情况
- 重构时有安全网，可以放心地改进代码结构
- 文档即测试，测试用例就是最准确的使用示例
常见误区:
- "先写完整实现，再补测试" - 这不是 TDD，这是"事后测试"
- "让 AI 同时生成实现和测试" - 失去了 TDD 的核心价值（测试驱动设计）
- 正确做法: 严格遵循 Red → Green → Refactor 循环，让测试真正"驱动"设计

阶段 4: 从代码到 Code Review (Code to Review)

核心理念: 在人类审查之前，让 AI 扮演一个不知疲倦的、极其严格的初级审查者。
场景: 你完成了一个功能的开发，准备提交 Merge Request。

高密度提示词:

你是一位对代码质量有洁癖的 Principal Engineer。我将粘贴一份我刚完成的代码。请对它进行一次严格的 Code Review。
你的审查需要覆盖以下方面，并以列表形式给出反馈：
1.  **违反 `.cursorrules`**: 检查代码是否违反了我们的任何规范。
2.  **潜在 Bug**: 寻找可能的 nil 崩溃、竞态条件、内存泄漏或逻辑错误。
3.  **可读性与可维护性**: 提出关于命名、注释、代码结构和复杂度的改进建议。
4.  **性能问题**: 指出任何可能导致性能下降的代码模式。

[在此处粘贴你的代码]

阶段 5: 从 Review 到文档 (Review to Documentation)

核心理念: 代码完成后，让 AI 自动生成符合规范的文档。
场景: Merge Request 已被批准。

高密度提示词:

@/Sources/Auth/AppleSignInManager.swift 你是一位技术文档作家。请为这个文件中的所有 public 方法和属性，生成符合 Apple Doxygen 风格的文档注释。确保解释每个方法的用途、参数和返回值。

第七部分: 实战技巧与反模式 (Patterns & Anti-Patterns)

技巧 1: "代码考古学" - 使用 Cursor 理解遗留代码

场景: 你接手了一个 5 年前的、没有文档的、3000 行的 Objective-C 文件。
传统方式: 花费数天时间逐行阅读、画流程图、向老员工请教（如果还能找到的话）。
Cursor 方式:
1. 生成概览: @LegacyViewController.m 请为我生成这个文件的高层次概述：它的主要职责是什么？它有哪些主要的子模块？它依赖哪些关键的外部类？以 Markdown 表格形式输出。
2. 生成流程图: @LegacyViewController.m 请使用 Mermaid 语法，生成一个序列图，展示从用户点击按钮到数据被保存的完整调用链。
3. 识别"问题": @LegacyViewController.m 请分析这个文件中的潜在问题：1. 哪些方法过于复杂（超过 50 行）？2. 哪些变量命名不清晰？3. 哪些地方可能有内存泄漏？以列表形式输出。
4. 生成重构计划: 基于上面的分析，请为我制定一个分 5 步的重构计划，每一步都是一个独立的、可测试的变更。
效果: 将"理解遗留代码"的时间从数天压缩到数小时。

技巧 2: "双轨驱动" - 同时驱动测试和实现

核心理念: 让两个 Cursor 对话同时进行，一个负责写测试，一个负责写实现，它们相互参照。
实战步骤:
1. 打开两个 Cursor 对话窗口（或使用 Composer 和 Chat 分别）。
2. 窗口 A (测试驱动): @MyService.swift 请为这个服务类编写完整的单元测试，覆盖所有公共方法。测试应该失败，因为实现还不完整。
3. 窗口 B (实现驱动): @MyServiceTests.swift 请查看这些测试，并实现 MyService 类，确保所有测试都能通过。
4. 迭代: 当测试通过后，在窗口 A 中添加新的测试（如边缘情况），然后让窗口 B 更新实现。
优势: 确保代码的"测试性"和"健壮性"，同时保持极高的开发速度。

技巧 3: "上下文注入" - 临时规则的力量

场景: 你在进行一个一次性的、特殊的任务（如数据迁移脚本），不想为此修改全局 .cursorrules。
方法: 在 Prompt 的开头，临时"注入"一个特定的规则集。

示例:

临时规则（仅适用于本次对话）：
1. 所有数据库操作必须包含 try-catch 和事务回滚。
2. 每处理 100 条记录，必须打印进度日志。
3. 禁止使用任何第三方库，只能使用标准库。

现在，请帮我编写一个数据迁移脚本，将 users 表中的 old_email 字段迁移到 new_email 字段。

优势: 避免了全局规则的"污染"，同时确保了特定任务的规范性。

技巧 4: "diff驱动" - 让 AI 解释两个版本的差异

场景: 你在 Code Review 时，发现一个巨大的 PR（300+ 行修改），很难快速理解其核心变更。

Cursor 方式:

@MyService.swift (旧版本在 Git commit abc123)
@MyService.swift (新版本)

请对比这两个版本，并生成一份 "变更说明" 文档。包括：
1. 核心业务逻辑的变化（用自然语言描述）。
2. 新增的公共 API 列表。
3. 被移除或废弃的 API 列表。
4. 潜在的向后兼容性问题。

效果: 极大地加速 Code Review 的理解阶段。

技巧 5: "AI 结对编程" - 角色扮演式的质量保证

方法: 在完成功能后，要求 AI 扮演一个"挑剔的审查者"。

Prompt 模板:

@MyNewFeature.swift 

现在，请你忘记你是我的助手。你现在是一位对代码质量极其挑剔的 Staff Engineer。
你的任务是找出这段代码中的**所有**问题，无论多小。包括但不限于：
1. 潜在的 Bug 或竞态条件。
2. 不符合最佳实践的地方。
3. 性能问题。
4. 可读性和可维护性问题。
5. 缺失的错误处理。

请严格审查，不要给我面子。以列表形式输出所有发现的问题，每个问题包括：问题描述、严重程度（高/中/低）、建议修复方案。

心理学价值: 这强迫你从"创造者"心态切换到"批判者"心态，极大地提高代码质量。

技巧 6: Code Lens / `@Codebase` - 全局代码理解

功能介绍: Cursor 的 @Codebase 功能允许 AI 对整个代码库进行语义搜索和理解，而不仅仅是打开的文件。
使用场景与最佳实践:
- 场景 1: 查找类似的实现模式
  - Prompt: @Codebase 在我们的项目中，有哪些地方实现了"下拉刷新"功能？请列出所有相关的类和方法。
  - AI 行为: 语义搜索整个代码库，找出所有实现了类似功能的代码，即使它们的命名不包含"下拉刷新"关键词。
  - 价值: 避免重复造轮子，发现可复用的模式。
- 场景 2: 理解数据流
  - Prompt: @Codebase 从用户点击"登录"按钮，到最终调用后端 API，中间经过了哪些类和方法？请画出调用链。
  - AI 行为: 分析整个代码库的调用关系，生成一个端到端的流程图（通常用 Mermaid 格式）。
  - 价值: 快速理解复杂的业务流程，特别是在大型遗留项目中。
- 场景 3: 架构一致性检查
  - Prompt: @Codebase 检查我们的 ViewModel 层，有哪些类**没有**遵循 MVVM 模式？具体来说，哪些 ViewModel 直接导入了 UIKit？
  - AI 行为: 扫描整个 ViewModel 目录，找出违反架构规范的文件。
  - 价值: 自动化架构审计，确保团队规范的一致性。
- 场景 4: 依赖分析
  - Prompt: @Codebase 列出所有依赖 Alamofire 框架的文件。我们计划迁移到原生 URLSession，需要评估工作量。
  - AI 行为: 全局搜索所有 import Alamofire 的文件，并分析它们的使用深度。
  - 价值: 为技术栈迁移提供精确的影响评估。
高级技巧: 组合使用 @Codebase 和 @.cursorrules
- Prompt: @Codebase @.cursorrules 扫描整个项目，找出所有**不符合我们 .cursorrules 中规定的命名规范**的类和方法。生成一份"不合规清单"。
- 价值: 将规则检查自动化，极大地降低 Code Review 的负担。

技巧 7: "从实践到规则的闭环

核心理念: 每一次与 AI 的"纠错"对话，都是一次知识提炼的机会。
标准工作流 (5 步法):
1. AI 犯错: AI 生成了不符合期望的代码。
2. 你纠正: 你明确指出问题，并告诉 AI 正确的做法。
3. AI 道歉并修正: AI 重新生成正确的代码。
4. 反思: 你问自己："这个错误是个例，还是一个可以被规则化的rule？"
5. 固化: 如果是rule，立即将其编码到 .cursorrules 中。

实战示例:

对话:

你: "@NetworkService.swift 添加一个新的 API 端点：获取用户动态。"
AI: [生成代码，但使用了同步请求]
你: "错误！所有网络请求必须是异步的。请使用 async/await。"
AI: [重新生成，使用 async/await]
你: "很好。现在，让我们防止这种错误再次发生..."

固化到规则:

## Part 7: 网络请求必须异步

❌ 错误: 使用同步网络请求
```swift
func fetchUserPosts() -> [Post] {
    let data = try! Data(contentsOf: apiURL)  // 同步，会阻塞线程
    return decode(data)
}

✅ 正确: 使用 async/await

func fetchUserPosts() async throws -> [Post] {
    let (data, _) = try await URLSession.shared.data(from: apiURL)
    return try decode(data)
}

理由: 同步网络请求会阻塞主线程，导致 UI 卡顿。

衡量指标: 如果你发现 AI 在同一个问题上犯错超过 2 次，说明你的规则不够清晰或不够显眼。这时需要：
1. 将规则移到 .cursorrules 文件的更靠前位置。
2. 增加更多的 ❌ 和 ✅ 对比示例。
3. 在规则前加上 CRITICAL 或 IMPORTANT 标记。

第八部分: 常见陷阱与反模式 (What NOT to Do)

反模式 1: "AI 依赖症" - 失去独立思考能力

表现: 遇到任何问题，第一反应是问 AI，而不是先自己思考 5 分钟。
案例: 一个工程师在写一个简单的数组遍历时，直接问 AI "如何遍历 Swift 数组？"，而不是先回忆一下最基础的 for item in array 语法。
后果: 基础能力退化，在没有 AI 的情况下完全无法工作。
解决: 建立"5 分钟独立思考"原则。在向 AI 提问前，强制自己先独立思考 5 分钟。如果 5 分钟内无法解决，再求助 AI。

反模式 2: "Prompt 巨大" - 一次要求太多

表现: 写一个巨大的 Prompt，试图让 AI 一次性完成整个复杂功能（如"创建一个完整的电商系统"）。
后果: AI 生成的代码可能是表面可用但深层缺陷的"玩具代码"，缺少错误处理、边缘情况考虑、性能优化。
解决: 采用"分层逼近"策略。先让 AI 生成骨架，然后逐步细化每个部分。

反模式 3: "规则膨胀" - .cursorrules 变成"百科全书"

表现: .cursorrules 文件越写越长，最终达到 5000+ 行，包含了所有能想到的规则。
后果: AI 的上下文窗口被规则占满，反而降低了它理解实际代码的能力。规则之间可能出现冲突。
案例: 某团队的 .cursorrules 同时包含了"优先使用函数式编程"和"避免复杂的链式调用"，这两条规则在某些场景下是冲突的。
解决:
1. 80/20 原则: 只保留那些能覆盖 80% 常见问题的 20% 规则。
2. 模块化: 将规则拆分到 .cursor/rules/ 的多个文件中，让 AI 根据上下文自动加载相关规则。
3. 定期审计: 每季度审查一次规则，删除过时的、冲突的规则。

反模式 4: "盲目 Keep All" - 不审查就接受所有变更

表现: AI 提供了 50 个文件的修改，用户不看就点击 Keep All。
真实案例: 一位工程师让 AI "优化项目的日志系统"。AI 修改了 80 个文件，工程师直接 Keep All。结果发现 AI 错误地删除了关键的错误日志，导致生产环境的一个严重 Bug 无法被诊断。
解决: 引入 Bug、破坏架构、产生安全漏洞。

反模式 5: "假设透明" - 认为 AI 会自动理解你的隐含假设

表现: 你心里有一个隐含的假设（如"这个方法会被高频调用，所以性能很重要"），但你没有在 Prompt 中明确说出来。
后果: AI 生成了一个功能正确但性能低下的实现。
解药: 使用 CRISPE 框架的 Intent 部分，明确表达所有关键约束和目标。

第九部分: AI 编程的适用场景与边界 (When to Use AI)

这是最容易被忽视，但可能是最重要的一章。工具再强大，也有其最佳使用场景。

核心观点: Cursor 是"力量倍增器"，而非"魔法棒"

力量倍增器: 如果你是 1x 工程师，Cursor 让你变成 2-3x；如果你是 10x 工程师，Cursor 让你变成 30x。
不是魔法棒: 它不能把 0x（完全不懂编程）变成 1x。你依然需要：
1. 理解需求的能力
2. 分解问题的能力
3. 架构设计的能力
4. 审查代码的能力

场景 1: 独立开发 - AI 的"天堂"场景 ⭐⭐⭐⭐⭐

为什么 Cursor 极其适合独立开发？

独立开发的特点	Cursor 如何帮助	效率提升
一个人负责全栈	AI 可以快速切换语言和技术栈	3-5倍
没有代码审查流程	可以快速迭代，AI 即审查者	2-3倍
决策速度快	不需要团队讨论，直接执行	5-10倍
上下文完整	你知道所有代码，AI 理解也完整	2-4倍
没有规范冲突	你定义的规范就是唯一规范	无摩擦

真实案例: Singapore Transport App

项目类型: 独立开发的交通查询应用
技术栈: iOS (Swift + UIKit) + MVVM + Moya + Realm
关键成功因素:
1. 完整的技术方案文档: AI 一次性生成了 2680 行的详细设计，包括架构图、代码示例、测试计划
2. 模式化代码生成: MVVM 结构清晰，AI 能准确复制模式
3. 快速迭代: 发现问题立即修改，无需等待他人审查
4. 全栈掌控: 从 API 到 UI 到数据库，一个人全包，上下文完整

独立开发者使用 Cursor 的最佳实践

在项目初期就建立 .cursorrules: 定义你的架构模式、命名规范、技术栈
大胆使用 AI 生成文档: 技术方案、API 文档、README，全部让 AI 生成初稿
利用 AI 做"橡皮鸭调试": 把你的设计思路讲给 AI 听，让它挑战你
让 AI 生成测试用例: 独立开发最容易忽略测试，AI 能帮你补上这个短板

场景 2: 团队开发 - 需要策略的场景 ⭐⭐⭐⭐☆

团队开发的挑战

挑战	说明	Cursor 的影响
代码风格不一致	不同人的 AI 生成风格可能不同	需要严格的 `.cursorrules`
上下文碎片化	每个人只知道自己负责的模块	`@Codebase` 可以缓解
审查负担增加	AI 生成的代码需要更仔细的审查	需要"AI Code Review"流程
技能差距放大	高手用 AI 更高效，新手可能产出低质量代码	需要培训和规范
沟通成本	需要对齐 AI 的使用方式	需要团队共识

团队开发的实战建议

定义"AI 可以做"和"AI 不能做"的清单:

✅ AI 可以做:
- 模式化的 CRUD 代码
- 单元测试用例生成
- API 封装层
- 数据模型定义
- UI 组件（基于设计系统）

❌ AI 不能独立完成（需要人类深度参与）:
- 核心算法设计
- 复杂的并发逻辑
- 安全敏感代码（加密、认证）
- 性能优化决策
- 架构重大变更

建立"AI Code Review Checklist":

审查 AI 生成的代码时，额外检查:
□ 是否有隐藏的性能问题？
□ 错误处理是否完整？
□ 边缘情况是否覆盖？
□ 是否有内存泄漏风险？
□ 是否符合团队规范？
□ 是否过度工程化？
□ 是否有安全漏洞？

场景 3: AI 擅长的任务类型 (高 ROI 场景)

任务类型	AI 效率	示例
模式化代码	⭐⭐⭐⭐⭐	CRUD、API 封装、ViewModel
测试用例生成	⭐⭐⭐⭐⭐	单元测试、集成测试
文档生成	⭐⭐⭐⭐⭐	技术方案、API 文档
代码重构	⭐⭐⭐⭐☆	API 迁移、命名统一
UI 组件	⭐⭐⭐⭐☆	基于设计系统的组件
数据模型	⭐⭐⭐⭐☆	Struct、Enum、Protocol
正则表达式	⭐⭐⭐⭐☆	复杂的匹配规则
SQL 查询	⭐⭐⭐⭐☆	复杂的多表联查

场景 4: AI 不擅长的任务类型 (低 ROI / 高风险场景)

任务类型	为什么不擅长	风险	建议
复杂算法设计	AI 可能产生"看起来对"但实际错误的算法	高	人类设计，AI 辅助实现
性能优化	AI 缺乏对运行时性能的直觉	中	人类 Profile，AI 辅助重构
并发/多线程	竞态条件、死锁等问题难以被 AI 发现	高	人类设计锁策略，AI 辅助实现
安全敏感代码	加密、认证等领域需要专业知识	极高	禁止 AI 独立完成
系统架构设计	AI 缺乏对业务长期发展的理解	高	人类主导，AI 辅助验证
产品决策	AI 无法理解用户真实需求	中	完全由人类负责
跨团队协作代码	AI 不了解其他团队的约定和依赖	中	需要大量人工审查

反面案例: 不应该让 AI 独立完成的任务

场景 5: 决策框架 - "我应该让 AI 做这个任务吗？"

使用这个决策树来判断：

这个任务是否适合 AI？
    ↓
Q1: 这个任务有明确的"正确答案"吗？
    ├─ 否 → ⚠️ 谨慎使用 AI（如产品设计、架构选型）
    └─ 是 → 继续
         ↓
Q2: 这个任务是否有大量现成的范例和模式？
    ├─ 否 → ⚠️ 谨慎使用 AI（如全新的算法设计）
    └─ 是 → 继续
         ↓
Q3: 错误的代价是否可接受？
    ├─ 否 → ❌ 禁止 AI 独立完成（如支付、安全）
    └─ 是 → 继续
         ↓
Q4: 你是否有能力验证 AI 的输出？
    ├─ 否 → ❌ 不要使用 AI（你会陷入"理解黑洞"）
    └─ 是 → ✅ 可以使用 AI
              ↓
Q5: 这个任务是否重复性高？
    ├─ 是 → ⭐⭐⭐⭐⭐ 强烈推荐 AI（如测试生成、API 封装）
    └─ 否 → ⭐⭐⭐☆☆ 可以用，但 ROI 一般

实战示例

任务: 实现一个购物车的折扣计算逻辑

Q1: 有明确的正确答案吗？
    → 是（业务需求定义了计算规则）

Q2: 有大量范例吗？
    → 是（购物车折扣是常见模式）

Q3: 错误的代价可接受吗？
    → 取决于：如果是 To C 电商，错误代价高；如果是内部工具，可接受

Q4: 你能验证吗？
    → 是（你可以写测试用例验证）

Q5: 重复性高吗？
    → 中等（可能有多种折扣类型）

结论: ⭐⭐⭐⭐☆ 适合 AI 辅助实现，但需要严格的测试覆盖

实战建议: 根据你的场景选择 Cursor 策略

如果你是独立开发者

✅ 大胆使用 Cursor
✅ 从项目第一天就建立 .cursorrules
✅ 让 AI 生成文档、测试、甚至架构设计
✅ 用 AI 做"橡皮鸭"，验证你的设计思路
✅ 目标: 3-5 倍效率提升

关键风险: 过度依赖 AI，基础能力退化
缓解措施: 每月一次"AI 禁食日"，手写代码

如果你是 2-5 人的创业团队

✅ 使用"配对编程"模式
✅ 建立团队统一的 .cursorrules
✅ 每周一次"Prompt 分享会"
⚠️ 所有 AI 生成的代码都需要另一人审查
⚠️ 定义"AI 可以做"和"AI 不能做"的清单

关键风险: 代码风格不一致
缓解措施: 严格的 Code Review + 团队规范

如果你是 5-20 人的成熟团队

✅ 使用"个人增强"模式
✅ 建立强制性的 AI Code Review 流程
✅ 投资建设高质量的 .cursorrules
⚠️ 限制 AI 在关键模块的使用（如支付、安全）
⚠️ 建立"AI 生成代码"的标注制度

关键风险: 技能差距放大、审查负担增加
缓解措施: 定期培训 + AI Linter 工具

如果你是 20+ 人的大团队

⚠️ 谨慎推广，先小范围试点
⚠️ 使用"专家代理"模式，指定 AI 专家
⚠️ 只在低风险场景使用（文档、测试、工具脚本）
❌ 不建议在核心业务代码中广泛使用

关键风险: 协作冲突、质量风险、知识孤岛
缓解措施: 渐进式推广 + 严格的风险控制

第十二部分: 哲学与未来

软件工程的终极目标是什么？

传统答案: 写出优雅的、可维护的、高性能的代码。
AI 时代的新答案: 用最快的速度，将想法转化为价值，并持续地迭代和进化。
代码本身不再是目标，而是手段。最终目标是解决问题、创造价值、取悦用户。

"代码"正在变成"配置"

观察: 当 AI 能生成 90% 的代码时，你手写的那 10% 实际上在"配置" AI 的行为。
.cursorrules 不是文档，它是"元代码": 它是一种"关于代码的代码"，是对代码生成器的编程。
未来预测: 10 年后，"写代码"这个概念可能会被"写规则"和"审查输出"取代。软件工程师的工作将更像是"AI 的产品经理"。

工程师的价值正在从"手艺人"转向"指挥家"

手艺人: 亲手雕琢每一行代码，代码的质量来自于个人的技艺和经验。
指挥家: 不需要会演奏每一种乐器，但需要深刻理解音乐、协调各部分、控制节奏、传达情感。
AI 就是你的"乐团"。你的价值在于：
1. 理解"乐谱"（需求和架构）。
2. 指挥"乐团"（编写高质量 Prompt 和规则）。
3. 确保最终的"演出"（产品）是和谐、高质量的。

最后的警示: "别让 AI 成为你思维的上限"

危险: 如果你只会"复制 AI 的答案"，那么你的能力上限就是当前 AI 的水平。
机会: 如果你将 AI 作为"放大器"，用它来执行你的创意和战略，那么你的能力上限是 你的创造力 × AI 的执行力。
关键区别: 前者是"AI 替代人"，后者是"AI 赋能人"。

附录: 快速参考手册

CRISPE 框架速查卡

[C] @相关文件 + 当前项目背景
[R] 你是一位 [具体领域] 的专家，你的目标是...
[I] 我的意图是 [核心目标]，最重要的约束是 [关键约束]
[S] 请分 X 步执行：1. ... 2. ... 3. ...
[P] 绝对禁止：1. ... 2. ... 3. ...
[E] 最终输出格式：[描述或示例]

常用 Cursor 快捷操作

Cmd+K: 在代码中直接输入 Prompt，生成或修改代码。
Cmd+L: 打开 Chat 面板，进行对话式编程。
Cmd+Shift+L: 打开 Composer，进行多文件协同编辑。
@文件名: 在 Prompt 中引用特定文件。
@符号名: 引用特定的类、函数或变量。
@.cursorrules: 让 AI 参考你的规则文件。
@Terminal: 生成或解释 shell 命令。

决策树: 我应该使用 Keep All 吗？

是纯格式化修改吗？ ─── 是 ───> ✅ Keep All
         │
         否
         ↓
是简单的 API 名称替换吗？ ─── 是 ───> 抽样验证 3-5 处 ───> ✅ Keep All
         │
         否
         ↓
涉及业务逻辑吗？ ─── 是 ───> ❌ 逐一审查
         │
         否
         ↓
涉及并发/异步/性能优化吗？ ─── 是 ───> ❌ 逐一审查 + 性能测试
         │
         否
         ↓
⚠️ 谨慎 Keep All，抽样深度验证

救命稻草: 当 AI 生成的代码完全不符合预期时

深呼吸，不要立即 Accept。
Ask Why: "请解释你为什么选择这个实现方式？"
Show, Don't Tell: "这是我期望的代码示例：[粘贴示例]。请对比你的实现和我的示例，找出差异。"
Reset Context: 有时 AI 陷入了错误的思路。开启一个全新的对话，重新表达你的需求。
Manual Override: 如果尝试 3 次仍然失败，手动编写核心逻辑，让 AI 辅助完成边角细节。

结语: 从工具使用者到工具塑造者

Cursor 不仅仅是一个"更聪明的自动补全"。它代表了软件开发范式的一次根本性转变。

在旧世界，你是工具的使用者。你学习 IDE 的快捷键、记忆 API 的签名、遵循既定的工作流。

在新世界，你是工具的塑造者。通过 .cursorrules、高密度 Prompt 和持续的反馈，你在"训练"你自己的 AI 副驾驶，让它逐渐理解你的思维方式、你的团队文化、你的项目特性。

这个过程本身，就是一种技能的修炼——你在学习"如何更好地与智能系统协作"。这项技能，将在未来 10 年、20 年持续增值。

记住: 最好的工程师不是写代码最快的人，而是知道该写什么代码的人。Cursor 解放了你的双手，现在，你需要做的是解放你的大脑，去思考更高层次的问题。

愿你的代码永远清晰，你的架构永远优雅，你的 Prompt 永远高密度。

洞见 Cursor - 实践与哲学

洞见 Cursor

前言 - 或许，你听过这两个经典模型

三级火箭

第一级火箭 (效率增量)

第二级火箭 (沉淀核心能力场景)

第三级火箭 (形成竞争壁垒)

点线面体

第一部分: 心智模型 - 这是理解一切的基础

洞见 1: Cursor 是“Prompt编译器”，而非 IDE

Level 1: IDE 用户

Level 2: 指令式用户

Level 3: Cursor Prompt 工程师

进化总结

洞见 2: 代码的经济学 - “生成式重构”

Level 1: 低密度 (手动重构)

Level 2: 中密度 (简单提示词)

Level 3: 高密度 (模式化重构指令)

第二部分: .cursorrules 的艺术

洞见 3: 它是"判例法"，而非"成文法"

Level 1: 低密度规则（成文法 - 模糊不清）

Level 2: 中密度规则 (带简单示例的成文法)

Level 3: 高密度规则 (判例法 - 对比+理由)

第三部分: 对 AI 进行编程的艺术

洞见 4: CRISPE - 编写零熵增提示词的终极框架

CRISPE 六要素详解

C - Context (上下文): 精准投喂，而非填鸭

R - Role (角色): 激活 AI 的"专业知识图谱"

I - Intent (意图): 单一、清晰、无歧义

S - Steps (步骤): 将你的"心理模拟"显性化

P - Prohibitions (禁忌): 你的"安全护栏"

E - Example/Format (范例/格式): 消除最后的歧义

完整示例: 在视频 View ZCCBaseView 的右上角添加一个时间标签

洞见 4.5: 其他主流 Prompt 框架对比 (RACE、TREE、TCR)

框架对比表

RACE 框架: 快速任务的最佳选择

TREE 框架: 结构化任务的平衡选择

TCR 框架: 简单查询的极简选择

框架选择决策树

同一任务用不同框架的对比示例

使用 TCR (极简)

使用 RACE (快速)

使用 TREE (平衡)

使用 CRISPE (完整)

框架对比总结表

实战建议: 根据场景选择框架

第四部分: 高级功能与工作流 (The "Power Plays")

洞见 5: Follow-up - 迭代式生成

洞见 6: "苏格拉底式对话" - 共同推理，而非索要答案

Level 1: 低密度 (直接索要)

Level 2: 中密度 (提供信息)

Level 3: 高密度 (引导推理)

洞见 7: @Terminal - 你的 AI DevOps 伙伴

Level 1: 低密度 (Google + 复制粘贴)

Level 3: 高密度 (自然语言命令生成)

第五部分: 批判性思维与未来洞见 (The "How to Judge & Evolve")

洞见 8: 警惕新的“技术债” - “理解黑洞”

Level 3: 高密度思维 (要求解释)

洞见 9: 重新定义"资深"

洞见 10: "认知卸载"的悖论

洞见 11: .cursorrules 的跨项目复用策略(已存在)

Level 1: 原始方式 - 复制粘贴

Level 2: Git Submodule 方式

Level 3: 符号链接 (Symlink) 方式 (适用于本地多项目)

Level 4: 动态生成方式 (高级)

洞见 12: "代码的巴别塔"的倒塌 - 语言的"去神圣化"

旧世界 (无 AI)

新世界 (有 AI)

洞见 13: "新的技术债形式

洞见 14: "AI-Native Architecture" - 为 AI 可理解性而设计

特征 1: 显性优于隐性

特征 2: 统一的命名模式

特征 3: 丰富的类型信息

特征 4: 小而专注的模块

洞见 15: "对话即资产"

Level 1: 手动复制粘贴 (原始但有效)

Level 2: 将对话抽离到 .cursorrules

Level 3: 使用 AI 辅助

Level 4: 共享团队知识库 (终极方案)

洞见 16: Cursor 对团队结构的影响 - 从"组件团队"到"意图小队"

第二部分: `.cursorrules` 的艺术

完整示例: 在视频 View `ZCCBaseView` 的右上角添加一个时间标签

洞见 5: `Follow-up` - 迭代式生成

洞见 7: `@Terminal` - 你的 AI DevOps 伙伴

洞见 11: `.cursorrules` 的跨项目复用策略(已存在)

Level 2: 将对话抽离到 `.cursorrules`

技巧 6: Code Lens / `@Codebase` - 全局代码理解