坚蛋运动
51.25MB · 2025-11-22
快速验证想法、完成核心功能产出
背景: 项目中有一个视频基础视图 ZCCBaseView，需要在右上角添加一个显示时长的标签。 Prompt:
[I] Intent: 在 ZCCBaseView 的右上角添加一个时间标签（NSTextField）
[C] Constraints:
- 距离右侧和顶部各 8pt 边距
- 使用手动布局（frame），不使用 Auto Layout
- 字体：系统 12pt，白色，半透明黑色背景
- 需要一个公开方法 updateWithTime: 用于更新时间显示
[E] Expected Output:
- ZCCBaseView.h 的接口声明
- ZCCBaseView.m 的实现代码
- 简短的使用示例
AI 产出:
// ZCCBaseView.h
@interface ZCCBaseView : NSView
// Update the time label with time interval (in seconds)
- (void)updateWithTime:(NSTimeInterval)time;
@end
// ZCCBaseView.m
@interface ZCCBaseView ()
@property (nonatomic, strong) NSTextField *timeLabel;
@property (nonatomic, strong) NSDateComponentsFormatter *timeFormatter;
@end
@implementation ZCCBaseView
- (instancetype)initWithFrame:(NSRect)frame {
self = [super initWithFrame:frame];
if (self) {
[self setupTimeLabel];
}
return self;
}
- (void)setupTimeLabel {
// Initialize time formatter
self.timeFormatter = [[NSDateComponentsFormatter alloc] init];
self.timeFormatter.allowedUnits = NSCalendarUnitMinute | NSCalendarUnitSecond;
self.timeFormatter.zeroFormattingBehavior = NSDateComponentsFormatterZeroFormattingBehaviorPad;
// Create time label
self.timeLabel = [[NSTextField alloc] initWithFrame:NSZeroRect];
self.timeLabel.editable = NO;
self.timeLabel.bordered = NO;
self.timeLabel.backgroundColor = [[NSColor blackColor] colorWithAlphaComponent:0.6];
self.timeLabel.textColor = [NSColor whiteColor];
self.timeLabel.font = [NSFont systemFontOfSize:12.0];
self.timeLabel.alignment = NSTextAlignmentCenter;
[self.timeLabel setWantsLayer:YES];
self.timeLabel.layer.cornerRadius = 4.0;
[self addSubview:self.timeLabel];
}
- (void)layout {
[super layout];
// Manual layout for time label
CGSize labelSize = CGSizeMake(60, 20);
CGFloat padding = 8.0;
CGRect labelFrame = CGRectMake(
self.bounds.size.width - labelSize.width - padding,
self.bounds.size.height - labelSize.height - padding,
labelSize.width,
labelSize.height
);
self.timeLabel.frame = labelFrame;
}
- (void)updateWithTime:(NSTimeInterval)time {
NSString *timeString = [self.timeFormatter stringFromTimeInterval:time];
self.timeLabel.stringValue = timeString ?: @"00:00";
}
@end
使用示例:
ZCCBaseView *videoView = [[ZCCBaseView alloc] initWithFrame:rect];
[videoView updateWithTime:125.5]; // 显示 "02:05"
把对话中产出的有价值信息抽象、整理成可复用场景和模板
1. 回顾第一级对话，识别核心价值
↓
2. 移除冗余或无关的 Prompt 文本
↓
3. 按 MECE 整理场景
↓
4. 生成可复用 Prompt 模板
↓
5. 形成"模块化知识库"
有价值的部分:
创建文件: .cursor/rules/mac-add-subview-template.md
# Mac 视图添加子控件模板生成器
## 适用场景
- 在现有 NSView 子类中添加新的子控件
- 需要手动布局或 Auto Layout
- 需要公开接口供外部调用
## Prompt 模板
[I] Intent: 在 [ViewClassName] 中添加 [控件描述] [C] Constraints:
## 模块化代码模板
### 头文件（如果需要公开接口）
```objc
// [ViewClassName].h
@interface [ViewClassName] : NSView
// Public method to update the [control]
- (void)[updateMethodName]:(Type)parameter;
@end
// [ViewClassName].m
// Private properties
@interface [ViewClassName] ()
@property (nonatomic, strong) NSTextField *[controlName];
@end
@implementation [ViewClassName]
- (instancetype)initWithFrame:(NSRect)frame {
self = [super initWithFrame:frame];
if (self) {
[self setup[ControlName]];
}
return self;
}
- (void)setup[ControlName] {
// Initialize and configure the control
self.[controlName] = [[NSTextField alloc] initWithFrame:NSZeroRect];
// ... configuration
[self addSubview:self.[controlName]];
}
- (void)layout {
[super layout];
// Manual layout logic
}
// Or use Auto Layout
- (void)updateConstraints {
[super updateConstraints];
// Auto Layout constraints
}
// Public method
- (void)[updateMethodName]:(Type)parameter {
// Implementation
}
@end
---
## 第三级火箭: 闭环固化产出
### 核心价值
**形成可落地、可直接使用的完整产出**
### 完整产出物清单
□ 可复用代码库（封装为独立模块） □ 架构设计文档（含 Mermaid 图） □ API 使用文档（含示例代码） □ 单元测试用例（覆盖核心场景） □ 集成指南（如何接入现有项目） □ 故障排查手册（常见问题 FAQ） □ 可复用 Prompt 模板（存入 .cursor/rules/）
### 实战示例: 完整的视频视图组件库闭环产出
#### **综合 Prompt (结合第一级 + 第二级)**
[I] Intent: 生成完整的自定义视频视图组件库闭环产出 [C] Constraints:
#### **AI 产出（结构化、完整、可落地）**
**1. 架构图**
```mermaid
graph TB
ZCCBaseView[ZCCBaseView 基础视图] --> TimeLabel[ZCCTimeLabel 时间标签]
ZCCBaseView --> AudioIndicator[ZCCAudioIndicator 音量指示器]
ZCCBaseView --> StatusIcon[ZCCStatusIcon 状态图标]
TimeLabel --> Formatter[NSDateComponentsFormatter]
AudioIndicator --> Animation[CAAnimation]
StatusIcon --> ImageCache[Image 缓存]
2. 组件实现
// ZCCTimeLabel.h - 60 行
// ZCCTimeLabel.m - 120 行生产级代码
// ZCCAudioIndicator.h - 40 行
// ZCCAudioIndicator.m - 150 行生产级代码（含动画）
// ZCCStatusIcon.h - 35 行
// ZCCStatusIcon.m - 80 行生产级代码
// （完整实现，带注释、错误处理、性能优化）
3. 组件使用文档
# 视频视图组件库
## ZCCTimeLabel - 时间标签组件
### 功能
显示格式化的时间（MM:SS 或 HH:MM:SS）
### 使用示例
```objc
ZCCTimeLabel *timeLabel = [[ZCCTimeLabel alloc] initWithFrame:rect];
timeLabel.position = ZCCTimeLabelPositionTopRight;
timeLabel.padding = 8.0;
[videoView addSubview:timeLabel];
// 更新时间
[timeLabel updateWithTime:125.5]; // 显示 "02:05"
**4. 集成指南**
```markdown
## 如何集成到现有项目
### 方式 1: 手动添加
1. 将 ZCCTimeLabel.h/m 添加到项目
2. 在需要的视图中 import "ZCCTimeLabel.h"
3. 按照使用示例添加到视图
### 方式 2: 使用 Cursor 生成
使用 Prompt 模板：@.cursor/rules/mac-add-subview-template.md
自动生成适配你项目的代码
5. Prompt 模板 - 存储到 .cursor/rules/video-component-template.md 6. 单元测试（可选）
// ZCCTimeLabelTests.m
// 测试时间格式化、布局计算等核心功能
| 火箭阶段 | Cursor 实践 | 核心价值 | 耗时 | ROI |
|---|---|---|---|---|
| 一级：对话完成 Feature | 生成初步功能、代码或文档 | 高频产出，快速验证 | 10-30 分钟 | 3-5倍 |
| 二级：沉淀场景 & Prompt | 抽离核心逻辑、生成可复用 Prompt | 模块化、知识沉淀 | 30-60 分钟 | 10-20倍 |
| 三级：闭环固化产出 | 形成完整落地方案、可直接使用 | 可落地、标准化闭环 | 1-2 小时 | 50-100倍 |
第一天: 用第一级火箭快速出原型
- 需求：在视频视图添加音量指示器
- 与 Cursor 对话，生成 ZCCAudioIndicator 核心逻辑
- 验证可行性，完成初步代码
第二天: 用第二级火箭沉淀模板
- 整理第一天的对话
- 提炼"添加动画控件"的 Prompt 模板
- 存储到 .cursor/rules/mac-animated-control-template.md
第三天: 用第三级火箭完善闭环
- 补充注释和错误处理
- 编写使用示例
- 形成可交付的完整组件
第一级: 让 AI 分析老代码，生成重构方案
- 需求：ZMPlistTableCellView 代码过长（3191 行）
- Prompt: "分析这个文件，建议如何拆分和重构"
- AI 输出：拆分为 5 个子模块的方案
第二级: 沉淀重构模式
- 提炼"大文件拆分重构模板"
- 存储到 .cursor/rules/refactoring-split-file-template.md
第三级: 形成可复用的重构工具链
- 生成"重构前后对比文档"
- 编写单元测试确保行为不变
- 形成团队的"重构最佳实践"文档
第一级: 每个人用 AI 完成各自的功能
- 工程师 A: 添加时间标签
- 工程师 B: 添加状态图标
- 工程师 C: 添加音量指示器
第二级: 团队一起沉淀统一的 Prompt 模板
- 集体 Review 三个人的对话历史
- 提炼统一的"Mac 视图组件开发模板"
- 存储到团队共享的 .cursor/rules/
第三级: 形成团队的"组件库 + 文档库 + Prompt 库"
- 建立团队 GitHub 仓库存放组件
- 建立内部文档站点
- 建立 Prompt 模板库
点 (Point) - 你当下能做的小动作、小努力
↓ （写 Prompt、优化代码、学习技能）
线 (Line) - 点所附着的轨迹和方向
↓ （功能模块、项目线、技术方向）
面 (Surface) - 线组合形成的领域
↓ （整个业务领域、团队战略、技术体系）
体 (Body) - 面所在的大势和环境
↓ （行业趋势、技术生态、市场环境）
点 (Point) - 个人用 Cursor 写代码，创建 Rule/Prompt
↓
线 (Line) - 把大家的 Rule/Prompt 联系在一起
↓
面 (Surface) - 形成完整的知识库和工具链
↓
体 (Body) - 建立团队协作和知识生态
这一层的关键:
每个工程师在用 Cursor 解决实际问题
每个人都在创建自己的 .cursorrules 和 Prompt
知识是分散的、碎片化的、个人化的
场景 1: 张三在开发视频 UI
问题: 需要在视频视图添加时间标签
张三的做法:
1. 与 Cursor 对话，生成代码
2. 在项目根目录的 .cursorrules 中添加：
"添加视图控件时，使用手动布局而非 Auto Layout"
3. 记录了一个好用的 Prompt：
"在 [View] 的右上角添加 [Control]，距离边缘 8pt..."
产出物:
- 张三的个人 .cursorrules（片段）
- 张三的 Prompt 笔记（可能在 Notion/本地文件）
- 张三脑子里的经验（隐性知识）
场景 2: 李四在重构老代码
问题: ZMPlistTableCellView 有 3191 行，太长了
李四的做法:
1. 用 Cursor 分析代码，生成重构方案
2. 在 .cursorrules 添加：
"代码重构时必须保证单元测试覆盖率 ≥ 80%"
3. 记录了一个 Prompt：
"分析 @file 并建议如何拆分成多个文件..."
产出物:
- 李四的 .cursorrules 片段
- 李四的重构 Prompt 模板
场景 3: 王五在封装 C++ API
问题: 直接调用 C++ API 容易出错
王五的做法:
1. 用 Cursor 生成 Helper 封装
2. 在 .cursorrules 添加：
"C++ 方法调用前必须检查 null"
3. 记录了一个 Prompt：
"为 @CppAPI 创建一个 Helper 封装..."
产出物:
- 王五的 .cursorrules 片段
- 王五的 C++ 封装 Prompt
优点:
- 每个人快速提升个人效率
- 灵活，适应个人习惯
- 快速验证，快速迭代
问题:
- 知识分散，难以共享
- 重复劳动（张三、李四可能在解决同样的问题）
- 质量参差不齐（有的 Prompt 很好，有的很差）
- 难以传承（王五离职了，他的经验就丢失了）
团队有 10 个工程师:
- 8 个人在用 Cursor
- 每个人都有自己的 .cursorrules（但互不相同）
- 每个人都有自己的 Prompt 笔记（在各自的电脑/笔记本上）
- 偶尔在群里分享一个好用的 Prompt，但没有系统整理
→ 这就是典型的"点"阶段：知识碎片化，价值未联结
这一层的关键:
把分散在各个工程师手里的 Rule/Prompt 收集起来
整理、去重、分类、标准化
建立团队共享的知识库
让"点"连成"线"，形成可复用的方法论
步骤 1: 收集（Collect）
团队行动:
1. 每个人分享自己最好用的 1-2 个 Rule/Prompt
2. 记录到共享文档（Confluence/Notion/GitHub）
步骤 2: 整理（Organize）
1. 将收集到的 Prompt 按场景分类
- UI 开发类
- 代码重构类
- API 封装类
- 测试生成类
- ...
2. 去重和合并
- 张三和李四的 Prompt 可能在解决同样的问题
- 合并为一个最佳实践版本
3. 标准化格式
- 统一使用 CRISPE 框架
- 统一命名规范
步骤 3: 存储（Store）
建立团队的 .cursor/rules/ 目录结构:
project-root/
├── .cursorrules （项目通用规则）
└── .cursor/
└── rules/
├── ui-development.md （UI 开发 Prompt 模板）
├── code-refactoring.md （代码重构 Prompt 模板）
├── cpp-api-wrapper.md （C++ API 封装模板）
├── unit-test-generation.md （单元测试生成模板）
└── ...
每个文件包含:
- 适用场景说明
- 标准化的 Prompt 模板
- 实际使用示例
- 注意事项
优点:
- 知识不再分散，形成团队资产
- 避免重复劳动（有现成模板直接用）
- 质量标准化（经过团队验证的最佳实践）
- 可传承（新人可以快速学习）
挑战:
- 需要有人推动
- 需要团队共识和配合
- 需要持续维护和更新
里程碑 1: 团队有了第一个共享的 .cursor/rules/ 文件
里程碑 2: 至少 50% 的工程师在使用共享模板
里程碑 3: 新人 Onboarding 时会被教导如何使用模板库
里程碑 4: 团队开始主动贡献新的模板
→ 达到这 4 个里程碑，就成功从"点"进化到了"线"
这一层的关键:
不仅仅是 Prompt 模板，而是完整的开发工具链
不仅仅是知识库，而是可自动化的工作流
不仅仅是团队内部，而是可跨团队复用的资产
形成一个"面"，覆盖整个业务领域
1. 知识库（Knowledge Base）
├── .cursor/rules/（15+ 个 Prompt 模板）
├── 组件库（可复用的代码模块）
├── 文档库（架构设计、最佳实践）
└── 案例库（真实项目的使用案例）
2. 工具链（Toolchain）
├── Linter 规则（自动检查代码规范）
├── CI/CD 集成（自动化测试和部署）
├── 代码生成器（基于模板的脚手架）
└── 质量看板（效率和质量指标）
3. 流程规范（Process）
├── Code Review 流程（如何用 Cursor 辅助 Review）
├── Bug 修复流程（如何用 Cursor 定位和修复）
├── 重构流程（如何安全地重构大型代码）
└── 测试流程（如何生成和维护测试）
4. 培训体系（Training）
├── 新人 Onboarding 课程（1 天工作坊）
├── 进阶课程（高级 Prompt 技巧）
├── 案例分享会（每月）
└── 考核认证（Cursor 使用能力评估）
成果: 形成完整的"面"
产出物:
知识库：30+ 模板 + 20+ 案例 + 完整文档站
工具链：Linter + 代码生成器 + 质量看板
流程规范：Code Review + 重构 + Bug 修复
培训体系：课程 + 工作坊 + 认证
覆盖范围:
40+ 工程师，3 个团队
UI、音视频、网络、数据库等所有领域
从需求到上线的完整开发流程
效果:
整体开发效率提升 50%
Bug 率降低 30%
Code Review 时间减少 40%
新人 Onboarding 时间从 4 周降到 1 周
团队代码质量评分提升 25%
优点:
- 形成完整的业务领域覆盖
- 不仅是知识，还有工具和流程
- 可跨团队复用，规模化效应
- 形成明显的竞争优势
挑战:
- 需要管理层支持（资源投入）
- 需要跨团队协作（利益协调）
- 需要持续投入（维护和更新）
- 需要文化变革（接受 AI-First）
里程碑 1: 知识库覆盖 3+ 个业务领域
里程碑 2: 至少 2 个团队在使用同一套工具链
里程碑 3: 有自动化工具（Linter / 代码生成器）
里程碑 4: 有完整的培训体系和认证标准
里程碑 5: 有可量化的 ROI 数据证明价值
→ 达到这 5 个里程碑，就成功从"线"进化到了"面"
这一层的关键:
不仅是工具和流程，而是团队文化和价值观
不仅是知识库，而是自我进化的知识生态
不仅是效率提升，而是组织能力的质变
形成一个"体"，建立难以复制的竞争壁垒
1. 自我进化的知识生态
传统知识库：
- 需要专人维护
- 容易过时
- 贡献动力不足
"体"的知识生态：
每个工程师都是贡献者
- 发现新的好用 Prompt → 主动提交到库
- 发现模板不好用 → 主动优化并更新
有反馈循环
- 使用数据自动收集（哪些模板使用最多）
- 根据数据优先优化高频模板
- 过时的模板自动标记或删除
→ 知识库不再是"死"的文档，而是"活"的、自我进化的生态
2. AI-First 成为团队文化
传统开发文化：
- 遇到问题 → Google / Stack Overflow
- 写代码 → 手写
- Code Review → 人工检查
"体"的 AI-First 文化：
遇到问题 → 先查团队 Prompt 库 → 再用 Cursor 解决
写代码 → 先用 Cursor 生成初版 → 再优化
Code Review → Cursor 先自动检查 → 人工复审关键逻辑
团队共识:
- "不用 Cursor 就像骑自行车而不开车"
- "好的 Prompt 比好的代码更有价值"
- "知识沉淀是每个人的责任"
→ AI 不再是"工具"，而是团队工作方式的一部分
3. 跨团队协作网络
传统团队模式：
- 各团队独立工作
- 知识封闭在团队内部
- 重复造轮子
"体"的协作网络：
知识跨团队流动
- VideoUI 团队的 Prompt → PhoneUI 团队也在用
- Clips 团队的组件库 → VideoUI 团队也在用
有协作机制
- 每月跨团队 Cursor 分享会
- 共享的 GitHub 仓库（存放所有团队的模板）
- 内部技术博客（案例分享）
有治理结构
- "Cursor 委员会"（各团队代表）
- 负责模板审核、标准制定、冲突解决
→ 不再是"我的团队"，而是"我们的组织"
成功标志:
- AI-First 成为团队的默认工作方式
- 知识库是"活"的，持续进化
- 跨团队协作顺畅，知识自由流动
- 对外有竞争壁垒，人才愿意加入和留下
- 管理层认可：这是组织的核心能力之一
这不是终点:
- "体"需要持续投入和维护
- 需要防止"官僚化"（流程过于复杂）
- 需要保持创新（避免固化）
里程碑 1: 有明确的激励机制，工程师主动贡献
里程碑 2: AI-First 被写入团队价值观/OKR
里程碑 3: 跨团队协作机制运转良好（如 Cursor Day）
里程碑 4: 知识库有明显的"自我进化"迹象
里程碑 5: 对外有影响力（招聘、技术大会）
里程碑 6: 管理层视其为组织核心能力
→ 达到这 6 个里程碑，就成功从"面"进化到了"体"
错误做法:
"我要建立一个完整的 AI 开发平台！"
→ 还没验证"点"的价值
→ 还没沉淀"线"的方法论
→ 还没形成"面"的覆盖
结果: 过度工程化，无人使用，项目失败
正确做法:
从最小的"点"开始
→ 验证 3-5 个"点"后，再考虑"线"
→ 形成 2-3 条"线"后，再考虑"面"
→ "面"被团队广泛采用后，再考虑"体"
错误做法:
"我每天都用 Cursor，效率很高！"
→ 但没有沉淀任何模板
→ 每次都在重复劳动
→ 知识无法传承
正确做法:
设定"沉淀里程碑"
→ 每解决 5 个类似问题，必须沉淀 1 个模板
→ 每月至少沉淀 2-3 个 Prompt
→ 定期 Review 和优化模板
错误做法:
"我们团队只用 Cursor 生成单元测试"
→ 只覆盖了一个极小的领域
→ 无法形成完整的工作流
→ 对团队整体效率影响有限
结果: 边缘化，难以推广
正确做法:
选择核心业务领域
→ 覆盖开发流程的多个环节
→ 形成端到端的解决方案
→ 体现在关键指标上（如 Sprint 交付速度）
错误: "我每天都用 Cursor 完成任务，但每次都要重新描述需求"
问题: 没有沉淀，每次都在重复劳动
正确: 每完成 3-5 个类似任务，就花 1 小时沉淀一个模板
错误: "我先花 2 天设计一个完美的 Prompt 模板"
问题: 过度设计，脱离实际需求
正确: 先用第一级快速验证 3-5 次，再沉淀模板
错误: "我生成了一个 10000 行的完整框架"
问题: 过度工程化，难以理解和维护
正确: 保持模块化，每个模块 200-500 行，高内聚低耦合
# 模板 1: Mac 视图添加子控件
存储位置: .cursor/rules/mac-add-subview-template.md
[I] Intent: 在 [ViewClassName] 中添加 [控件描述]
[C] Constraints:
- 控件类型: [NSTextField/NSButton/NSImageView]
- 布局方式: [手动布局/Auto Layout]
- 位置: [左上角/右上角/居中]
[S] Steps: [详见文档第二级火箭部分]
[E] Expected Output: 完整的 .h 和 .m 实现代码
---
# 模板 2: 代码重构（长文件拆分）
存储位置: .cursor/rules/refactoring-split-file-template.md
[I] Intent: 分析并拆分超长文件 @[FileName]
[C] Constraints:
- 目标: 每个文件 < 500 行
- 保证: 行为完全一致
- 测试: 单元测试覆盖率 ≥ 80%
[S] Steps:
1. 分析文件职责，识别可拆分的模块
2. 设计拆分方案（建议 3-5 个文件）
3. 生成拆分后的代码
4. 生成单元测试确保行为一致
[E] Expected Output: 拆分方案 + 新文件代码 + 测试用例
---
# 模板 3: 生成单元测试
存储位置: .cursor/rules/generate-unit-tests-template.md
[I] Intent: 为 @[ClassName] 的 [methodName] 方法生成单元测试
[C] Constraints:
- 测试框架: XCTest
- 覆盖: 正常流程 + 边界情况 + 异常处理
- 命名: test[MethodName]_[Scenario]_[ExpectedResult]
[S] Steps:
1. 分析方法的输入输出和副作用
2. 识别需要测试的场景（至少 3 个）
3. 生成测试代码（包含 setUp 和 tearDown）
4. 添加必要的 Mock 对象
[E] Expected Output: 完整的测试类代码
