cursor团队协作 - 规则共享、索引一致与多人并行开发

个人偏好可以各管各，产出风格必须共享。

本篇讲 cursor团队协作 在多人开发里的落地。界面语言、主题、快捷键属于个人设置，强行统一没有意义；真正需要一致的是项目级 Rules、代码索引行为与任务拆分方式。

团队引入这类工具最常见的失败模式，是每个人各写一套规则、各自跑一轮大任务，最后 diff 风格五花八门、互相覆盖。把约定写进仓库，才是可复制的做法。

五类内容最值得进仓库。

# 技术栈与风格
- TypeScript，禁止 any；新增导出需写明类型

# 改动边界
- 不自动修改锁文件、CI 配置与迁移脚本
- 跨模块改动必须先列计划

# 提交与注释
- 提交信息「类型: 简述」，用简体中文

# 验收
- 每处改动说明验证方式与影响范围

规则不宜写成几十条禁令，越长越容易被忽略。优先写「会影响合并冲突与返工」的那几条：依赖变更、跨模块范围、命名与提交格式。

规则文件随仓库走，新人克隆项目即可获得同一套约束，这也是 cursor团队协作 在团队里最实在的价值。

环境不一致，问题最难复现。

• 在内部文档写明当前标准版本，附上获取渠道与核验方式。
• 升级前先在一台测试机跑一轮常用任务与索引，再批量推开。
• 大仓库首次索引耗时较长，升级窗口避开交付节点。
• 保留上一版安装包与自算摘要，出问题时能快速比对。
• 遇到「我这台能跑、他那台不行」，先比版本号与索引状态。

版本与回退的完整流程见 历史版本；安装包核验见 校验签名。

任务拆分比工具配置更影响结果。

什么时候值得从个人档升级。

个人档各自订阅时，账单分散、成员变动要逐个处理、规则与模型策略也难以统一。团队规模上来后，Teams 档的价值主要在统一管理与账单，而不只是额度叠加。

官方 Teams 为每用户 $30 起，Enterprise 需联系销售定制；标价通常不含税，第三方模型按 API 用量另计。完整档位对照见 价格。

按这个顺序推进，阻力最小。

1. 选一台测试机

   固定版本，跑通索引、Rules 与一轮常用任务。

2. 写项目级 Rules

   从五类内容里挑最影响返工的几条，提交进仓库。

3. 补审查规范

   把 diff 逐文件审查与「不整体接受」写进 Code Review 规范。

4. 小范围试点

   两三个人、一个模块，跑两周并收集问题。

5. 再批量推开

   统一版本与更新窗口，保留回退方案。

小结 cursor团队协作：团队落地靠「规则进仓库 + 版本可复现 + 任务拆小步」，不是靠每个人各自摸索。需要具体任务写法，见 Agent 任务。