Enforcement：让 AI 不能做错事
Context 解决"知道做什么"，Enforcement 解决"不能做错事"。
以 Cursor 的 .mdc 规则为例：
---
description: TypeScript 代码规范
globs: ["**/*.ts", "**/*.tsx"]
alwaysApply: true
---
rules:
- pattern: "any"
message: "禁止使用 any，请使用具体类型"
severity: error
- pattern: "console\.(log|warn)"
message: "生产环境禁止 console.log"
severity: warning
强制执行分几层：
- Lint 层：ESLint/Prettier 自动格式化
- Rule 层：AI 规则引擎实时拦截违规代码
- Test 层：自动生成测试验证正确性
意思是：AI 生成代码时如果触犯规则，在生成阶段就会被拦住，而不是等到人工 Review 才发现。
Evolution：让 AI 越用越好
通过 MCP（Model Context Protocol） ，AI 可以连接外部工具：
{
"mcpServers": {
"database": {
"command": "npx",
"args": ["@modelcontextprotocol/server-postgres"],
"env": { "DATABASE_URL": "postgresql://localhost/mydb" }
},
"github": {
"command": "npx",
"args": ["@modelcontextprotocol/server-github"],
"env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}" }
}
}
}
接上 MCP 之后，AI 能做的事情变多了：查数据库表结构来生成准确的类型定义、读 GitHub Issues 来理解需求背景、执行命令行完成部署和测试。
再加上 Skills（技能库） （固化常用操作流程）和 Feedback Loop（反馈循环） （根据接受/拒绝记录持续优化），AI 会随着使用越来越适配你的项目。
3.3 Harness 解决什么
| 问题 | 传统方式 | Harness 方式 |
|---|---|---|
| 规范不一致 | 维护 N 份配置 | AGENTS.md 统一标准 |
| AI 不知道项目约定 | 每次 Prompt 手动提醒 | Context 自动加载 |
| 代码质量靠人 Review | 累且容易漏 | Enforcement 强制拦截 |
| AI 不能连外部工具 | 手动复制粘贴 | MCP 协议集成 |
四、两层结合：Monorepo × Harness Engineering
4.1 分工关系
┌─────────────────────────────────────┐
│ Monorepo（结构层） │
│ │
│ 提供"视野"： │
│ • 上下文完整 — AI 看得到全项目 │
│ • 类型自动同步 — 改一处全局感知 │
│ • 跨项目重构 — 追踪影响范围 │
│ • 依赖统一 — 版本冲突减少 │
│ │
└─────────────────┬───────────────────┘
↓ 完整上下文流入
┌─────────────────────────────────────┐
│ Harness Engineering（执行层） │
│ │
│ 确保"准确"： │
│ • Context — AGENTS.md + .spec/ │
│ • Enforcement — 规则引擎 │
│ • Evolution — MCP + Skills │
│ │
└─────────────────┬───────────────────┘
↓ 可靠代码输出
🤖 全栈 AI 助手
简单说：
- Monorepo 提供完整的上下文（让 AI 看得全）
- Harness 确保执行的规范性（让 AI 做得对）
- 两者配合，效果比单独使用任何一种都更好
4.2 效果对比
| 维度 | 多 Repo | 仅 Monorepo | 仅 Harness | 两者结合 |
|---|---|---|---|---|
| 上下文完整性 | 有限 | 较好 | 单 Repo 内 OK | 完整 + 精准 |
| 规范一致性 | 各自为政 | 靠人工保证 | 统一标准 | 全局 + 局部自治 |
| 重构安全性 | 人工追踪 | 跨项目分析 | 单 Repo 内追踪 | 自动 + 可追溯 |
| AI 代码接受率* | ~40-50% | ~65-70% | ~55-60% | ~70-75%+ |
*注：以上数据综合自社区调研和部分工具报告（Cursor 2025、GitHub Octoverse 2025 等），具体数值因项目和团队而异，仅供参考
4.3 结合后的目录结构
monorepo/
│
├── apps/ # 应用层
│ ├── web/ # Next.js 前端
│ │ ├── .spec/ # 前端业务规范
│ │ └── AGENTS.md # 覆盖全局的前端指令
│ ├── api/ # Fastify 后端
│ │ ├── .spec/ # 后端业务规范
│ │ └── AGENTS.md
│ └── admin/ # 管理后台
│
├── libs/ # 共享模块
│ ├── shared/ # 共享类型 & 工具
│ ├── auth/ # 认证模块
│ └── ui/ # UI 组件库
│
├── .agents/ # 中央 AI 配置中心
│ ├── AGENTS.md # 项目宪法
│ ├── skills/ # 可复用技能库
│ └── mcp.json # 外部工具连接配置
│
├── .cursor/ # Cursor 配置
│ ├── rules/conventions.mdc
│ └── mcp.json
│
├── turbo.json # 构建编排
└── package.json
关键点：
.agents/AGENTS.md替代原来分散的多份配置文件.spec/实现地方自治，各模块维护自己的业务规范skills/提供可复用的 AI 工作流模板mcp.json让 AI 连接外部工具
总结
回到开头的问题：
模型越来越强，可开发效率的提升并没有那么明显。
现在答案比较清晰了：
- 结构问题（信息分散、上下文不全）→ 用 Monorepo 改善
- 执行问题（规范不一致、容易犯错）→ 用 Harness Engineering 改善
- 两者结合，AI 能更好地融入开发流程
几点体会：
人设计系统，AI 在系统内可靠执行。
与其追求更强的模型，不如给模型一个清晰的结构和明确的约束。
结构即生产力。 项目结构的优劣，会影响 AI 能发挥多大作用。
参考
概念与标准
工具
数据来源
- GitHub Octoverse 2025
- Cursor 2025 年度报告
- ETH Zurich: AI Context File Effectiveness Study (2025)
