引言：Vibe Coding 的下一阶段
"Vibe Coding"这个词在 2025 年流行开来——用 AI 辅助编程，凭感觉写代码，让模型填充实现细节。但随着越来越多的团队将 AI 编程深入日常工作流，"Vibe Coding"的局限性开始显现：
- 个人工具没有团队知识沉淀
- 每个人的 Cursor Rules 各不相同，AI 风格差异大
- 代码库规范、业务上下文无法有效传递给 AI
- 生成的代码质量参差不齐，Review 成本反而增加
团队级 AI 编程基础设施要解决的，正是这些"规模化"问题：让 AI 编程工具的效果在团队层面一致、可控、可积累。
一、团队 AI 编程基础设施的四个层次
Layer 4: AI 流程集成（CI/CD、Code Review、Issue 自动化）
Layer 3: 团队知识库（Cursor Rules、Prompt 模板、最佳实践）
Layer 2: 工具配置标准化（统一 IDE、模型选型、上下文策略）
Layer 1: 基础设施（代码库结构、文档规范、注释标准）
从底层开始建设，每一层都是上一层的基础。
二、Cursor Rules 工程化：从个人到团队
2.1 .cursorrules 文件的团队化
Cursor Rules 是告诉 AI 助手"你工作在什么上下文"的配置文件。把它纳入代码仓库版本控制，是团队一致性的第一步。
# .cursorrules（放在项目根目录）
## 项目背景
这是一个基于 FastAPI + PostgreSQL + React 的电商平台后端服务。
主要处理商品管理、订单流程、用户账户三个核心域。
## 技术栈
- 后端：Python 3.12, FastAPI, SQLAlchemy 2.0, Celery, Redis
- 数据库：PostgreSQL 16（主），Redis 7（缓存）
- 测试：pytest + httpx（接口测试），factory_boy（测试数据）
- 代码风格：black（格式化），ruff（lint），mypy（类型检查）
## 编码规范
1. 所有 API 接口必须使用 Pydantic v2 进行请求/响应验证
2. 数据库操作必须通过 Repository 层，禁止在路由层直接 ORM 操作
3. 所有外部 API 调用必须在 service 层，且包含重试和超时处理
4. 错误必须使用自定义异常类（位于 app/exceptions/），不要直接 raise HTTPException
5. 所有函数必须有 type hints，公开函数必须有 docstring
## 目录结构
app/ ├── api/ # 路由层（只做请求解析和响应组装） ├── services/ # 业务逻辑层 ├── repositories/ # 数据访问层 ├── models/ # SQLAlchemy 模型 ├── schemas/ # Pydantic 模型 └── exceptions/ # 自定义异常
## 注意事项
- 不要引入新的依赖，除非在 PR 中明确说明理由
- 性能敏感的接口必须考虑数据库查询的 N+1 问题
- 涉及金融计算的地方使用 Decimal 而非 float
2.2 分层 Rules 策略
不同类型的文件适用不同的 Rules：
# .cursor/rules/api.mdc（API 层规范）
---
globs: ["app/api/**/*.py"]
---
## API 层职责
- 只负责接收请求和返回响应
- 调用 service 层处理业务逻辑
- 所有参数必须用 Pydantic Schema 验证
## 示例模式
```python
@router.post("/orders", response_model=OrderResponse, status_code=201)
async def create_order(
request: CreateOrderRequest,
current_user: User = Depends(get_current_user),
order_service: OrderService = Depends(get_order_service),
) -> OrderResponse:
order = await order_service.create(user_id=current_user.id, data=request)
return OrderResponse.model_validate(order)
```markdown
# .cursor/rules/tests.mdc（测试规范）
---
globs: ["tests/**/*.py"]
---
## 测试规范
- 使用 pytest + fixture，不要用 unittest.TestCase
- 接口测试必须使用 AsyncClient，不要直接调用 service
- 使用 factory_boy 创建测试数据，不要硬编码
- 每个测试只测一个行为（一个 assert 或一组相关 assert）
## 命名规范
- test_创建成功_返回201
- test_参数缺失_返回422
- test_无权限_返回403
三、团队 Prompt 模板库
3.1 标准化开发任务 Prompt
# team_prompts/prompts.py
# 团队共享的 AI 任务 Prompt 模板
IMPLEMENT_FEATURE = """
## 任务：实现新功能
**功能描述**：{description}
**技术约束**：
- 遵循项目的 Repository 模式
- 使用 async/await
- 包含类型注解
- 在 service 层实现业务逻辑
**需要创建/修改的文件**：
- app/schemas/{schema_name}.py（Pydantic 模型）
- app/repositories/{repo_name}.py（数据访问）
- app/services/{service_name}.py（业务逻辑）
- app/api/{router_name}.py（路由）
- tests/test_{feature_name}.py（测试用例）
**参考现有实现**：app/services/order_service.py（参考模式）
"""
CODE_REVIEW = """
## 任务：代码审查
审查以下代码，关注：
1. 是否遵循项目的分层架构
2. 是否有潜在的性能问题（N+1 查询、缺少索引等）
3. 错误处理是否完整
4. 是否有安全风险（SQL 注入、权限检查等）
5. 类型注解是否完整
代码：
{code}
"""
WRITE_TESTS = """
## 任务：编写测试
为以下函数/接口编写完整的测试用例：
{target}
测试要求：
- 覆盖正常流程（happy path）
- 覆盖边界情况
- 覆盖错误情况（无效参数、无权限、资源不存在）
- 使用 factory_boy 创建测试数据
- 不要 mock 数据库（使用测试数据库）
"""
四、AI 辅助 Code Review 流程
4.1 GitHub Actions 集成 AI Review
# .github/workflows/ai-review.yml
name: AI Code Review
on:
pull_request:
types: [opened, synchronize]
jobs:
ai-review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Get changed files
id: changed-files
uses: tj-actions/changed-files@v44
with:
files: |
app/**/*.py
tests/**/*.py
- name: AI Code Review
if: steps.changed-files.outputs.any_changed == 'true'
run: |
python scripts/ai_review.py \
--files "${{ steps.changed-files.outputs.all_changed_files }}" \
--pr-number "${{ github.event.pull_request.number }}"
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
# scripts/ai_review.py
import os
import sys
import json
from openai import OpenAI
from github import Github
def review_file(file_path: str, content: str) -> str:
client = OpenAI()
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{
"role": "system",
"content": """你是一个严格的代码审查员，专注于：
1. 架构合规性（Repository/Service/API 分层）
2. 性能问题（N+1、缺少索引、不必要的全表扫描）
3. 安全问题（注入、权限、数据泄露）
4. Python 最佳实践（类型注解、异常处理）
输出格式：Markdown，包含严重问题（🔴）、建议（🟡）、良好实践（🟢）"""
},
{
"role": "user",
"content": f"审查文件：{file_path}\n\n```python\n{content}\n```"
}
]
)
return response.choices[0].message.content
def post_review_comment(pr_number: int, review_body: str):
g = Github(os.environ["GITHUB_TOKEN"])
repo = g.get_repo(os.environ["GITHUB_REPOSITORY"])
pr = repo.get_pull(pr_number)
pr.create_issue_comment(f"## 🤖 AI Code Review\n\n{review_body}")
五、效果量化：团队 AI 编程的 KPI
5.1 关键指标
# 团队 AI 编程效能追踪
metrics = {
"pr_cycle_time": {
"description": "从提交 PR 到合并的平均时间",
"target": "减少 30%",
"measurement": "GitHub API 统计"
},
"first_review_comment_rate": {
"description": "AI Review 发现问题的比例（有效评论/总评论）",
"target": "> 60%",
"measurement": "人工标记 + 统计"
},
"ai_code_acceptance_rate": {
"description": "AI 生成代码直接采用（无修改或少修改）的比例",
"target": "> 40%",
"measurement": "问卷调查"
},
"coding_velocity": {
"description": "单位时间内完成的功能点数",
"target": "提升 25%",
"measurement": "Sprint 回顾对比"
}
}
结语
团队级 AI 编程基础设施的建设是一个渐进过程。从统一 .cursorrules 开始，再逐步建立 Prompt 模板库、引入 AI Review、最终量化效果改进。
最关键的一点：AI 工具的效果，取决于团队给它的上下文质量。花时间把团队的编码规范、架构决策、业务背景整理成 AI 能理解的格式，这投入的回报是持久的、可复利的。
