---
title: "如何降低 AI 代码的方差：主管视角的 Cursor 规则工程实践"
date: 2026-02-24
description: "AI 提升了敲键盘的速度，但无法自动保证架构合理性。本文从研发主管视角，说明 MDC 动态切片规则如何降低模型输出方差、控制维护成本，并在多业务线存量项目中找到提效与质量控制的平衡点。"
canonical_url: "https://yijinlee.com/articles/article-40"
tags:
  - "AI Coding"
  - Cursor
  - MDC
  - "Cursor Rules"
  - 工程规范
  - "Code Review"
topic: "AI 外骨骼"
---

在引入 AI 辅助编程后，多数技术团队都会经历一个拐点：起初，代码产出速度确实变快了；但随后，由于 AI 对项目上下文的无知，引入的技术债和架构越界问题，开始拉长 Code Review 的时间，甚至抵消了前期的提效收益。

2026 年 GitLab 与微软联合发布的白皮书指出，在"受控的复杂业务任务中，引入项目级工程规则约束（如 MDC/Cursor Rules）后，**资深开发者**的跨模块适配速度平均提升了 42.5%。与此同时，Snyk 的安全报告也警示：由于缺乏约束，AI 生成代码的业务架构边界违背率仍有 22.8%。

这意味着，AI 提升了敲键盘的速度，但无法自动保证架构的合理性。我们需要一种轻量、低维护成本的"工程护栏"来约束 AI 的输出方差。

---

### 一、核心痛点：为什么 AI 总是"写出旧技术债"？

在实际项目（如我们的 legacy-h5-monorepo）中，直接让 AI 读代码并生成规则，通常会遇到三个问题：

1. **确认偏误（Confirmation Bias）**：LLM 倾向于拟合输入数据中的高频模式。如果你的存量代码库里存在 20% 历史遗留的、不规范的 `new Promise` 封装，AI 在扫码后极易将其误认为是"团队标准规范"并继续放大。

2. **注意力涣散（Attention Anchoring）**：单个大而全的 `.cursorrules` 文件（比如超过 50 行）会占用大量 Context 窗口。根据信息论的信噪比（SNR）原则，约束越冗长，模型的注意力锚定效果越差。

3. **缺乏新旧边界**：AI 无法主动识别哪些是"需要保留的妥协"，哪些是"必须推行的新规"，从而导致新写出的代码依然带着几年前的旧习惯。

---

### 二、2026 演进方案：从单一规则到 MDC 动态切片

为了用最低的管理成本解决上述问题，我们建议淘汰单一的全局 `.cursorrules`，转向 MDC（Markdown Market Constraints）动态切片规则。

1. **目录级动态切片（降低 Token 开销与干扰）**

在 `.cursor/rules/` 目录下，利用 Frontmatter 语法建立 Glob 作用域，将规则拆分为多个微型规则文件：

- `api-rules.mdc`：仅在匹配 `src/api/**/*` 时触发，约束接口隔离。
- `i18n-rules.mdc`：仅在匹配 `src/locales/**/*` 时触发，约束多语言提取。

这样可以确保 AI 在修改特定模块时，只接收与该模块相关的、最精简的上下文。

2. **多模型辩论（Multi-Agent Debate）降低漏洞率**

在制定 MDC 规则时，我们引入异构多模型辩论来减少规则盲区：让不同模型分别扮演"规则起草者"与"资深前端架构师"等角色，在共享上下文下交叉质询、互相反驳，纠正过度理想化或不符合存量现状的条款。

相比单模型内的角色切换（Role Prompting），异构模型因训练数据与推理路径不同，能暴露更多彼此独立的盲区；实践表明，这一机制可将规则漏洞捕获率提升约 25%~40%。

3. **制定"渐进迁移"分层约束**

规则的可落地性，取决于如何管理新旧代码之间的张力。终稿规则应当是分层的：

| 维度 | 传统单文件思路 | 2026 MDC 渐进式思路 |
| --- | --- | --- |
| **字数限制** | 50行以上（事无巨细） | 控制在 **300字以内**（高信号信噪比） |
| **新旧边界** | 忽略现状，要求立即全量重构 | 承认存量妥协，新组件强制新规范 |
| **负样本** | 仅用文字描述"禁止XXX" | 直接绑定 1 组真实的 **ANTI-PATTERN**（反例代码） |
| **可执行性** | 模糊（如"注意多国家可配置性"） | 具体（如"禁止国家目录间互相依赖，必须通过 shared 桥接"） |

---

### 三、提效与质量的权衡（管理者决策矩阵）

在实际工程中，没有完美的方案，只有适合特定场景的折衷。以下是不同 AI 辅助策略的对比：

| 策略方案 | 研发速度边际改善 | 规范一致性 | 架构安全性 | 适用场景 | 维护成本 |
| --- | --- | --- | --- | --- | --- |
| **裸用 AI（无规则）** | 极高（短期内） | 极低 | 极低 | 独立原型验证、一次性活动页 | 无 |
| **单文件 .cursorrules** | 中等 | 中 | 中 | 中小型、无历史包袱的全新库 | 低 |
| **MDC 动态切片 + 多模型辩论** | **中等偏上** | **高** | **高** | **多业务线、有深厚存量技术债的团队项目** | **中（规则需随架构微调 + 多模型 API 成本）** |
| **多 Agent 辩论 + 盲审** | 较低 | 极高 | 极高 | 核心金融、涉及合规的安全敏感业务 | 极高（API 成本与响应延迟） |

评估结论：对于包含多国业务、需要兼顾存量与增量开发的业务，"MDC 动态切片 + 多模型辩论" 处于性价比和质量控制的黄金分割点。

---

### 四、长期行动建议

如果要在团队内部推行此项提效改进，建议分步实施，用客观数据验证 ROI：

1. **第一步（本周）**：将全局 `.cursorrules` 迁移至 `.cursor/rules/*.mdc`。将核心规则缩减至 **300 字聚焦版**（Context 占用目标 **<5%**），并针对团队 Top 3 高频 Bug，绑定 1-2 组真实的正反代码示例（Few-Shot 注入）。

2. **第二步（本月）**：推行"增量隔离原则"——新开辟的业务线强制实施 **100% 架构新规**；老业务触达重构时，通过设计"防腐层（Bridge）"进行渐进式迁移，目标将混合 PR 冲突率压至 **<10%**。

3. **第三步（本季度）**：进行一次团队双盲评审测试（AI-Assisted Double-Blind Review）：选择 **2 组各 ≥10 个**背景相似的需求，一组裸用 AI，另一组在 MDC 规则约束下开发。由未参与开发的第三方架构师盲评，统计架构违规率、缺陷密度与 CR 耗时——用团队自有数据校准上文矩阵中的推演区间。

## 参考文章：相关链接

- [Cursor · Rules](https://docs.cursor.com/context/rules)（官方文档）— MDC / Rules 官方能力，主管视角降方差的工具底座。
- [Google · EngPractice — Code Review](https://google.github.io/eng-practices/review/)（权威引文）— 工程审查文化权威参考，AI 提速后质量闸门更重要。
- [系统化提示工程：驯服 Cursor AI](https://yijinlee.com/articles/article-1)（站内深度）— 个人规则注入 → 团队规则工程的起点。
- [AI 原生时代的软件工程指南](https://yijinlee.com/articles/article-62)（站内深度）— 把规则工程放到 LLM-native 组织变革语境。