问题：AI编码的成功为什么难以复制？
越来越多的团队在尝试AI辅助编码。但一个普遍现象是：成功案例很多，成功复制却很难。
某个项目用AI写代码效率翻倍，换个项目就不行了；某个工程师用AI很顺手，换个人就各种踩坑。问题出在哪？
本质是上下文的缺失，也是驾驭能力的缺失。
AI编码不是简单的提问-生成代码，而是需要三层上下文的支撑：编程环境上下文、项目上下文、需求上下文。任何一层的缺失，都会导致AI生成的代码无法落地。
平台要解决的核心问题，就是让这三层上下文可复制，让AI可被有效驾驭。
理论基础：从Prompt到Harness的三阶段演进
第一阶段：Prompt Engineering（提示词工程）
时间：2022年底至2024年初
核心理念：关注说什么
在这个阶段，所有主流的AI教程都着重讲解如何创建一个完美指令——角色扮演、Few-shot、Step-by-step等技巧。用户是绝对掌控者，模型是基于单条指令完成任务的被动执行者。
模型没有记忆、没有工具，每一次交互都是独立的条件概率生成。
第二阶段：Context Engineering（上下文工程）
时间：2024年至2025年初
核心理念：关注配置环境
随着模型上下文窗口的扩充（从4K到128K/200K tokens），业内开始形成共识：相较于研究提示词如何遣词造句，更重要的是以系统性框架（RAG知识库、系统提示词、Memory记忆系统、工具调用接口）为模型构建信息环境。
用户从直接发号施令者转变为情境构建者——负责判断当前情况，提供信息与资源；模型则在给定的上下文环境中，自行判断如何应对。
第三阶段：Harness Engineering（驾驭工程）
时间：2025年初至今
核心理念：关注让什么发生
随着Claude 4.6、GPT-5.4 Codex、Gemini 3.1 Pro等具备深度Agentic能力的模型成熟，新的范式被提出——Harness Engineering（驾驭工程）。
“Harness"在英语中意为马具/缰绳。它不是动力本身，但它决定了动力能否被稳定地使用。AI像一匹很快的马，但需要一套缰绳才能被驾驭。
核心定义：设计一套环境与机制，使AI Agent能在可控边界内持续自主工作。
核心理念：人类引导，智能体执行（Humans steer, Agents execute）
驾驭工程的四个核心动作
Harness Engineering的核心可以概括为四个动词：
1. Constrain（约束）：设定边界
问题：AI会产生幻觉，会偷懒，会写出看似能跑实则一团糟的代码。
解决方案：通过不变量约束，而不是微观管理实现细节。
具体做法：
- Guardrails护栏：定义AI不可逾越的行为边界
- 权限分级：不同场景下AI的能力范围
- 沙箱隔离：Docker容器隔离，任务完成后销毁
- 架构约束：强制执行依赖方向（如 Types→Config→Repo→Service→Runtime→UI）
2. Inform（告知）：提供信息
问题：AI只能访问运行时上下文中的知识，其他都等于不存在。
解决方案：把上下文推回仓库，结构化组织信息。
具体做法：
- 渐进式披露：给AI一张地图（AGENTS.md），而不是1000页说明书
- 结构化docs/目录：设计文档、产品规格、技术参考
- 可观测性数据：日志、指标、追踪（LogQ、PromQL）
- UI能力：Chrome DevTools协议，让AI能读取界面、截图、导航
3. Verify（验证）：检查结果
问题：AI生成的代码未必符合要求，需要验证。
解决方案：建立评估机制，让验证自动化。
具体做法：
- Evals评估：为每个产品领域和架构层打分
- 智能体评审：AI评审AI的代码
- 结构测试：验证架构依赖是否合规
- CI任务：校验知识库是否最新、结构是否正确
4. Correct（纠正）：修正问题
问题：发现问题后，如何让系统自我修复？
解决方案：建立控制循环，让问题自动转化为规则。
具体做法：
- Control Loops：评审意见、bug报告自动转化为文档更新或工具规则
- 文档园丁智能体：定期扫描文档，发现并修复过时描述
- 品味不变量：把人类品味编码进系统
OpenAI的驾驭工程实验
OpenAI在2025年8月至2026年1月进行了一次震撼实验：
团队：最初3人，后扩展到7人 时间：5个月 产出：百万行代码 铁律：不许写手工代码
结果：
- 每人每天平均推进3.5个PR
- 从空仓库到百万行产品，没有一行代码是人类写的
- 连指导AI的AGENTS.md第一版也是AI自己写的
工程师的角色转变：
- 从熬夜写Bug，再熬夜修Bug的码农
- 变成想清楚要什么、把规则立起来的驾驭者
- 人类的品味不会消失，而是被持续编码进系统
三层上下文与四核心动作的关系
四核心动作（Constrain、Inform、Verify、Correct）需要在三层上下文中落地：
关系说明：
- 编程环境层是基础，提供四核心动作的工具与能力
- 项目层是Inform的信息载体，让AI有知识可用
- 需求层是Verify的验收标准，让AI知道什么是对的
三层上下文，三组平台交付件
一、编程环境上下文：提供四核心动作的平台能力
定位：基础层，提供让AI可被驾驭的工具与机制。
交付件清单
| 交付件 | 对应动作 | 说明 | 形式 |
|---|---|---|---|
| Skill包 | Inform | 可复用的能力模块（如CRUD生成、代码审查） | 代码库/插件市场 |
| MCP服务器 | Inform | 外部工具/数据源接入 | 配置文件 + API对接 |
| 知识库 | Inform | RAG检索的知识源 | 向量数据库 + 文档库 |
| Guardrails配置 | Constrain | 行为边界约束 | 规则配置文件 |
| 权限模型 | Constrain | 能力分级定义 | RBAC配置 |
| 沙箱环境 | Constrain | Docker容器模板 | Dockerfile + 编排文件 |
| Evals系统 | Verify | 评估规则与评分机制 | 配置 + 评估脚本 |
| 智能体评审 | Verify | AI评审AI的代码 | 评审规则配置 |
| 评审Checklist | Verify | 代码评审标准 | Markdown文档 |
| Control Loops | Correct | 问题自动转化为规则的机制 | 自动化脚本 |
| 文档园丁 | Correct | 自动修复过时文档的智能体 | 定时任务 |
业界对标
- Cursor Composer
- GitHub Copilot Chat with your codebase
- Claude MCP协议
二、项目上下文：Inform的信息载体
定位：让AI看得懂项目，有知识可用。
交付件清单
| 交付件 | 说明 | 形式 |
|---|---|---|
| AGENTS.md | 项目导航地图（约100行），渐进式披露入口 | Markdown文件 |
| docs/目录模板 | 标准化文档体系 | 目录结构 + 示例文件 |
| .cursorrules | 项目规则文件（技术栈、风格、禁止事项） | 配置文件 |
| 架构文档 | 领域划分、依赖约束 | Markdown |
| 数据库Schema | 表结构、字段说明、索引设计 | SQL + Markdown |
| API文档 | 接口规格 | OpenAPI/Swagger |
| 质量评分卡 | 各领域评分 | Markdown |
| 项目脚手架 | 一键生成标准目录 | CLI工具 |
docs/目录结构
docs/
├── AGENTS.md # 入口导航（~100行）
├── ARCHITECTURE.md # 架构说明
├── DESIGN.md # 设计原则
├── design-docs/ # 设计文档
│ ├── index.md
│ └── core-beliefs.md
├── exec-plans/ # 执行计划
│ ├── active/
│ ├── completed/
│ └── tech-debt-tracker.md
├── product-specs/ # 产品规格
│ └── index.md
├── references/ # 技术参考
│ └── *-llms.txt
├── db-schema.md # 数据库设计
├── api/ # 接口文档
├── QUALITY_SCORE.md # 质量评分
├── RELIABILITY.md # 可靠性要求
└── SECURITY.md # 安全要求
业界对标
- Cursor的.cursorrules
- Cline的.clinerules
- OpenAI的AGENTS.md
三、需求上下文：Verify的验收标准
定位：让AI做对事，知道什么是对的。
交付件清单
| 交付件 | 说明 | 形式 |
|---|---|---|
| 需求单模板 | 功能需求标准格式 | 表单模板 |
| 问题单模板 | Bug修复标准格式 | 表单模板 |
| 验收标准清单 | 可执行的验收条件 | Checklist |
| Few-shot示例库 | 好需求/坏需求示例 | 文档库 |
需求单模板示例
## 需求描述
- 功能名称：
- 所属模块：
- 优先级：P0/P1/P2/P3
## 验收标准（Verify的依据）
- [ ] 标准1：具体可验证的条件
- [ ] 标准2：性能指标（如响应时间<200ms）
- [ ] 标准3：兼容性要求
## 关联系统
- 依赖：需要哪些系统/服务
- 影响：会影响哪些系统/服务
## 技术约束
- 技术栈要求：
- 安全要求：
- 性能要求：
问题单模板示例
## 问题描述
- 问题现象：
- 影响范围：
- 紧急程度：P0/P1/P2/P3
## 复现步骤
1. 步骤1
2. 步骤2
3. 步骤3
## 期望行为
## 环境信息
- 版本：
- 环境：
- 日志/截图：
业界对标
- Linear的需求模板
- Jira的Issue模板
- BDD的User Story格式
平台交付物总览
如果平台要一次性交付，可以打包成：
| 交付包 | 内容 |
|---|---|
| 项目脚手架 | 一键创建标准项目结构（AGENTS.md + docs/ + .cursorrules） |
| Skill库 | 常用技能包（CRUD生成、代码审查、文档生成等） |
| MCP连接器 | 常见工具的MCP对接（Git、Jira、CI/CD、数据库） |
| Guardrails模板 | 行为约束配置模板 |
| 沙箱镜像 | 标准开发环境Docker镜像 |
| Evals套件 | 评估规则与脚本 |
| 需求模板库 | 需求单/问题单模板 + Few-shot示例 |
| 使用指南 | 如何使用这套体系的说明文档 |
平台的三层能力总结
| 层级 | 定位 | 核心动作支撑 | 关键交付件 |
|---|---|---|---|
| 编程环境层 | 提供四核心动作的平台能力 | Constrain + Inform + Verify + Correct | Skill、MCP、知识库、Guardrails、Evals、Control Loops |
| 项目层 | Inform的信息载体 | Inform | AGENTS.md、docs/、.cursorrules、API文档、Schema |
| 需求层 | Verify的验收标准 | Verify | 需求单模板、问题单模板、验收标准、Few-shot示例 |
写在最后
AI编码的成功可复制性，本质上是驾驭能力的可复制性。
从Prompt Engineering到Context Engineering再到Harness Engineering，我们看到的是人与AI协作范式的演进：
- 从说什么（微观管理）
- 到配置环境（情境赋能）
- 再到让什么发生（制度化授权）
OpenAI的实验证明：当驾驭工程做到位，3个人5个月可以构建百万行代码产品——没有一行手工代码。
一个团队如果没有：
- 编程环境层的工具与机制（没有缰绳的野马）
- 项目层的结构化文档（AI看不到的知识等于不存在）
- 需求层的可执行验收标准（AI不知道什么是对的）
AI只能帮他们写出能跑的代码，但无法帮他们高效地交付价值。
平台要做的，不是让AI更聪明，而是让团队更会驾驭AI。从执行者变为驾驭者，这是AI时代工程师的核心竞争力。
你的团队在AI编码上踩过哪些坑？欢迎交流。
参考资料：