100% AI 驱动开发落地全景：
Harness 编排、多模型协作与无状态交割
今天要讲的不是“怎么让 AI 帮我写一段代码”，而是如何把 AI 变成一个可接管、可验证、可持续迭代的研发执行系统。核心关键词有四个：Harness、多模型协同、上下文持久化、无人值守验证闭环。
从 Chatbot 到 Harness：AI 需要眼睛、手脚和工程反馈环。
从单模型通吃，到 Orchestrator + Specialist 的网状分工。
用 prompt.md、.memory、.prompt 解决上下文丢失。
横评模型能力，识别鬼打墙、幻觉和上下文腐烂。
先把概念讲清楚：Model、Harness、Agent、MCP、Skill
这一页先不讲工具名，先讲五个基础词。可以把 AI 研发想象成“一个聪明人进入公司干活”：Model 是大脑，Harness 是工位和流程，Agent 是能独立接任务的人，MCP 是他调用外部系统的统一插座，Skill 是被封装好的标准作业指导书。
Model：大脑
Model 就是 Claude、GPT、Gemini、DeepSeek 这类大语言模型。它擅长理解文字、推理、写方案、生成代码。
但单独的 Model 只能“想”和“说”，它不知道你的项目文件最新长什么样，也不会自己跑测试。
Harness：工位 + 流程
Harness 是套在 Model 外面的工程执行环境：读取文件、搜索代码、执行 Bash、运行编译测试、把错误日志回传、管理上下文。
通俗说，Harness 给大脑装上眼睛、手脚、工具箱和质检流程。
Agent：能干活的人
Agent 不是单纯的模型，而是“模型 + 执行环境 + 任务目标 + 工具权限”的组合。它能读项目、改文件、跑命令、根据结果继续修。
所以我们说：Agent = Harness + Model。
MCP：统一插座
MCP 可以理解成 Agent 连接外部工具和数据源的标准接口，例如查数据库、读文档、调用代码智能工具、访问项目记忆。
它让不同工具像 USB 一样被统一接入，而不是每个工具都单独写一套协议。
Skill：标准作业包
Skill 是预先写好的专项工作说明，例如代码审查、生成图片、查官方文档、做安全审计。它告诉 Agent 遇到某类任务时按什么流程做。
它像团队里的 SOP，让同一类任务输出稳定。
为什么说 Agent = Harness（马具） + Model（马）？
因为只有 Model 时，它只是一个会回答问题的大脑；只有 Harness 时，它只是一个空的工具环境。二者合起来，才变成能执行任务的 Agent：Model 负责判断和生成，Harness 负责看现场、动手操作、验证结果、保存状态。
会想
会做
能交付
一个简单例子
你让 AI 修一个登录 Bug。裸 Model 只能根据你贴的日志猜原因；Agent 会先搜索认证代码，读取配置，修改文件，运行测试，再根据失败日志继续修，直到验证通过。这就是从“聊天回答”到“工程执行”的区别。
读代码 → 推理原因 → 改文件 → 跑测试 → 看报错 → 再修复 → 留交割记录常用 Harness 怎么选？关键是“工具 × 模型 × 调教”
不同 Harness 不是简单谁强谁弱，而是各有最佳使用姿势。Claude Code 需要搭配 Claude 官方模型才能最大化发挥；Codex 更适合 OpenAI 自家 coding / reasoning 模型；Gemini CLI 强在大上下文和低成本探索；OpenCode / Aider 模型可插拔，但要靠配置、提示词、权限、MCP、规则文件精细调教，才能发挥上限。
Claude Code + Claude、Codex + OpenAI、Gemini CLI + Gemini，通常默认体验更稳，因为工具提示、权限模型、上下文策略都围绕自家模型调过。
OpenCode / Aider 的优势是自由，但需要团队自己配置模型、规则、MCP、验证命令、失败阈值和交割协议。
大扫描用 Gemini，复杂架构用 Claude/DeepSeek，端到端执行用 Codex，IDE 内局部改造用 Cursor/Cline/Roo，终端可控 diff 用 OpenCode/Aider。
初始化无状态交割协议：让任何 AI 工具都能无缝接手
这里的重点不是逐字背一段 Prompt，而是建立一套“跨模型、跨工具、跨会话”的交割协议。无论使用 Gemini、OpenCode、Codex、Claude，任何新窗口进来都应该先读同一套资产，再继续同一条任务链。
新项目：设计完成后的开发启动协议
提示词骨架：
背景：页面/UI 设计阶段已完成，现在进入 100% AI 驱动代码开发阶段。请先建立项目级交割协议，确保 Gemini、OpenCode、Codex、Claude 等任意 AI 工具都能在任意时间接手后续开发。
任务 1：创建 prompt.md。它是项目最高开发蓝图，必须包含：技术栈选择、系统架构、模块边界、接口规范、数据流向、UI 资源库、组件复用原则、当前状态、下一步任务和验收标准。
任务 2：建立验证闭环。任何开发任务都必须执行：代码修改 → 编译 → 测试 → 本地运行检查。全部通过后，自动提交并推送远程 Git。提交信息遵循结构化规范，内容要说明背景、变更、验证结果和风险，可使用合适 emoji 增强可读性。
任务 3：初始化 ./.memory/。它是跨会话静态记忆库，用于记录架构状态、代码规范、踩坑记录、依赖约束和不能触碰的雷区。每次功能推进、Bug 修复或方案调整后都要更新。
任务 4：初始化 ./.prompt/。它是动态任务链。每完成一个阶段，都要生成下一个阶段的有序 Prompt，例如 001_xxx.md、002_xxx.md。如果当前阶段返工或架构调整，必须同步修正后续 Prompt。
验收目标：上下文不依赖某个模型或某个聊天窗口，而是固化在项目文件中，确保任何 AI 工具都能无缝接班。
老项目：存量系统接管协议
提示词骨架：
背景：你正在接手一个已有项目。历史上下文不可假设存在，因此禁止直接大范围重构。请先完成项目扫描、风险识别和交割资产初始化。
任务 1：逆向扫描。识别语言版本、框架版本、依赖、中间件、数据库、目录结构、核心模块、调用关系、构建命令、测试命令、运行方式和现有测试覆盖。
任务 2：更新 prompt.md。把当前系统状态、技术拓扑、核心业务边界、历史约束、风险区域、后续增量计划和验收标准写进去，让新来的 AI 先读文档再动代码。
任务 3：初始化 ./.memory/。至少建立系统全景、代码规范、雷区备忘录。凡是复杂泛型、特殊生命周期、隐式约定、脆弱依赖、历史坑点，都要沉淀为记忆。
任务 4：初始化 ./.prompt/。生成第一个安全增量任务，例如 001_legacy_handover_first_action.md。后续每个阶段都继续追加下一阶段 Prompt，并在返工时同步修正任务链。
任务 5：增量无损开发。修改老代码前必须说明风险和回滚点；修改后必须编译、测试、运行。全部通过后再提交并推送，提交信息要包含变更原因、影响范围、验证结果和已知风险。
验收目标：先建立数字孪生记忆体，再做最小安全增量，避免 AI 裸重构引发雪崩。
prompt.md 是所有 AI 进入项目后的第一阅读对象。
.memory/ 保存架构、规范、坑点和雷区。
.prompt/ 保存下一阶段 Prompt，保证工作连续。
编译、测试、运行全绿后，才允许提交和推送。
无状态交割协议：新 Session 如何无缝接手？
当项目已经满足无状态交割协议后，新的 AI 会话不需要知道上一轮聊天记录。它只需要按固定顺序读取项目资产，就能恢复上下文、判断当前阶段、继续推进任务。
1. prompt.md：先读总纲
这是项目最高开发蓝图。新 Session 先读它，理解技术栈、架构、UI 规范、当前状态、验收标准和自动化要求。
一句话：先知道“这个项目是什么、规矩是什么”。
2. .memory/：再读记忆
读取系统全景、代码规范、历史坑点、雷区和已验证方案。它帮助新 AI 避免重复踩坑、乱改老约定。
一句话：再知道“哪些经验不能忘”。
3. .prompt/：最后读任务链
找到序号最大的未完成或下一阶段 Prompt，理解当前应该继续做什么。如果前序任务返工过，也要读被修正后的后续 Prompt。
一句话：最后知道“现在该干哪一步”。
新 Session 启动话术
最短版：
根据 ./prompt.md 中的指示继续工作。
推荐版：
请先读取 ./prompt.md、./.memory/ 和 ./.prompt/，恢复当前项目上下文；然后根据最新的未完成阶段 Prompt 继续推进工作。
老项目版：
请先读取 ./.memory/ 中的系统全景、代码规范和雷区，再从 ./.prompt/ 找到下一步增量任务。
上下文压缩怎么实现？
所谓压缩，不是把整段聊天记录塞给下一个模型，而是把本轮会话中真正有长期价值的信息，压缩成三类项目资产。
- 稳定事实 → .memory/：架构、规范、坑点、已验证方案。
- 当前状态 → prompt.md：项目现状、边界、验收标准、全局约束。
- 下一步动作 → .prompt/：未完成任务、执行顺序、验证命令、回滚提醒。
新 Session 读取这些文件，就是把压缩后的上下文“解压”回工作状态。
接手后的标准动作
- 确认目标、完成标准、验证命令和风险边界。
- 检查 Git 状态，避免覆盖前序未提交修改。
- 按当前阶段 Prompt 做最小安全推进。
- 运行编译、测试、运行检查并修复。
- 更新
.memory/，生成或修正下一阶段.prompt/。 - 全部通过后提交并推送。
最新版模型六维横评：放进 Harness 闭环里看
这里用当前主流最新版模型做横向对比：GPT-5.5、Gemini 3.5、Claude Opus 4.8、DeepSeek-V4-Pro、MiniMax M2.7、GLM-5.1。注意：这不是单纯榜单排名，而是判断它们在 AI 驱动开发 Harness 里更适合承担什么角色；同时新增“易失控性”，专门观察模型在明确指令、代码恢复和多轮修复中会不会把事情越改越坏。
长会话是否忘约束
长上下文和复杂专业任务表现强，适合作为端到端主控；但仍要用
prompt.md 和验证命令约束任务边界，避免大任务后半段注意力漂移。3.5 Flash/Pro 系列偏大上下文与高速代理工作流，适合先做全仓扫描和资料归纳；风险是“看得多但未必抓住最关键约束”。
长上下文稳定性和约束保持非常强，适合跨文件重构和长会话接力；尤其适合在 Claude Code 中结合项目规则持续推进。
1M 上下文和推理能力适合大仓库扫描、复杂依赖追踪；开源/兼容接口优势明显，但长任务仍需阶段性压缩到
.memory。M2.7 在复杂业务材料和技能型任务上有提升，适合垂类流程；长代码会话中建议强制拆小任务，避免后期约束衰减。
GLM-5.1 主打长程自主执行，适合长任务 Agent；但要用阶段检查点和 Git 状态防止“持续执行但方向偏移”。
会不会编 API
对主流框架和代码推理较克制，能较好结合工具输出；冷门新框架仍必须要求它查源码/官方文档，不允许凭记忆引依赖。
多模态和长上下文强，但面对高频更新 SDK 容易混版本；适合先做资料整理，再由更克制模型或测试闭环确认实现细节。
诚实性和不确定性表达较强，遇到不确定 API 更可能提示风险；适合作为“最后审稿人”和复杂实现守门员。
推理前会做较多自检，且可接 OpenAI/Anthropic 兼容接口；但社区/中文资料多时也可能受噪声影响，需固定来源。
在金融、办公、结构化材料等垂类场景更稳；冷门工程 API 上需要 Harness 强制检索和测试兜底。
工程任务能力增强，但开源/国产生态资料混杂时要防止“像真的一样”的接口；建议所有工具调用必须跑验证。
风格是否稳定
编码能力强，适合统一风格重构；需要在 Prompt 中明确 lint、命名和提交规范，否则可能按自己偏好“优化”。
适合批量生成和扫描，局部风格一致性中等；IDE/Harness 应配合格式化器、lint 和小范围 diff。
风格贴合能力很强，适合维护老项目既有写法；多轮后仍能保持命名、缩进、异常处理和代码组织。
对规范约束响应好，适合在 OpenCode/Aider 中做结构化 diff；中文项目和复杂后端栈上表现稳定。
更适合模板化和业务流程型产出；复杂代码风格保持要依赖明确样例和自动格式化。
长程工程交付能力强，但持续执行中要定期做 lint/test checkpoint，防止中后段风格偏移。
失败后是否 Zoom out
强推理和端到端规划能力突出，适合失败后重审架构；建议设置“失败 3 次必须改策略”的系统规则。
适合大范围探索和提出多路线方案；具体落地时容易偏“继续尝试”，需要人为或规则触发收敛。
很擅长从局部错误上升到设计缺陷，适合担任架构复盘和复杂 Bug 破局角色。
推理链路长，适合算法、后端、复杂状态机；但实战中容易出现“挑活干”：简单任务积极完成，稍复杂任务会输出“这个太复杂了，我们留到后期再实现”。另外它的 Zoom out 有时不是保留现场重构，而是丢弃全量未提交改动后从头开始，死胡同风险仍然严重。
垂类推理和材料组织不错，但复杂工程死锁时需要外层 Harness 强制切换策略或换模型。
长程自主任务能力强，适合规划→执行→修复闭环；但要把阶段目标写清，防止过度自主。
会不会越修越乱
通常能按明确约束推进，遇到恢复类任务也较少大范围误改；但端到端执行时仍要用 Git diff、测试和提交前审查防止过度修改。
大上下文探索能力强，但如果要求同时处理很多文件，可能把次要信息也纳入改动；适合先扫描归纳，再把精修交给更可控的编辑模型。
在明确要求下通常能保持边界，适合修复“补回来但不要动其他东西”这类精细任务；仍建议结合小范围 diff 和逐步提交。
复杂推理强，但执行层面要警惕两类失控：一是复杂需求被主动延期，留下“后期再实现”的空洞 TODO；二是遇到死胡同时通过丢弃未提交改动来重新开始，导致前序进度消失。必须用任务清单、Git 检查点和禁止丢弃未提交改动的规则约束。
需要特别注意：即使明确要求“给某些内容加括号”，输出也可能完全不变；代码修改中若丢了一部分，要求补回来时，可能把整个仓库恢复到旧状态，导致前序改动进度全丢。必须小范围 diff、禁止自动全仓恢复。
需要特别注意：修改代码时可能把
if..else 中的 else 逻辑直接删掉；要求补回 else 后，其他已完成内容又可能消失。必须逐文件审查、分块提交、每次修复后跑回归测试。在 Harness 中怎么用
适合 Codex 类端到端执行、复杂任务拆解、调试修复和最终交付。成本较高时可用于关键阶段。
适合全仓索引、资料归纳、候选方案生成和低成本探索，关键修改需复核。
适合 Claude Code、复杂重构、风格保持、风险审查和高可信交付。
适合 OpenCode/Aider、中文后端项目和复杂推理破局；但执行时要防止挑简单任务、延期复杂任务、以及丢弃未提交改动从头来过。更适合作为“架构/破局模型”，由 Harness 强制任务闭环和 Git 保护。
适合办公、金融、报告、流程化业务和技能型任务；代码主控需强验证。
适合长时间自主执行、工程优化和前端原型；需要阶段验收和权限约束。
失败不是问题，失控才是
前面讲了概念、工具、无状态交割、初始化协议和模型横评。落到实战里，最常见的坑其实都不是“模型不够聪明”，而是任务没有边界、上下文没有沉淀、验证没有闭环。
1. 把 Model 当 Agent
只问模型“帮我写代码”，却不给它 Harness、工具、文件、验证命令，结果只能得到看似正确的回答。
解法：明确 Agent = Model + Harness，让它能读、能改、能跑、能验。
2. 换 Session 就丢上下文
上一轮口头讨论很多，但没有写进 prompt.md、.memory/、.prompt/，新窗口只能重新猜。
解法：把聊天过程压缩成文件结论。
3. 工具和模型搭错
例如用大扫描模型做精修，或用未调教的开源 Harness 做复杂交付，导致效率和稳定性都不理想。
解法：官方工具优先吃官方模型红利；开源工具靠 SOP 调教。
4. 失败后原地鬼打墙
连续多轮修同一个报错行，没有重新审视设计、依赖、生命周期或任务拆分。
解法：失败 3 次必须 Zoom out，改策略或换模型。
实战红线
- 没有读取交割资产，不准开始开发。
- 没有明确验证命令，不准声称完成。
- 没有更新记忆和下一阶段 Prompt，不算完成交割。
- 没有 Git 状态检查，不准覆盖前序工作。
- 没有编译、测试、运行全绿，不准提交推送。
推荐的失败处理协议
- 第 1 次失败：读取日志，局部修复。
- 第 2 次失败：扩大上下文，检查相关模块。
- 第 3 次失败：停止补丁，重新审视架构假设，但禁止丢弃未提交改动。
- 仍失败：切换模型或引入审查 Agent，避免“太复杂以后再做”的逃避式输出。
- 解决后：把原因和修复写入
.memory/。
把 AI 从“聊天对象”升级为“工程协作网络”
本次培训的主线可以压缩成一句话：Model 提供智能，Harness 提供执行环境，Agent 负责交付；而无状态交割协议保证任何工具、任何模型、任何新窗口都能继续同一条研发链路。
认知公式
Agent = Model + Harness。Model 是大脑，Harness 是工位、工具和流程。MCP 是统一插座，Skill 是专项 SOP。
交割公式
上下文 = prompt.md + .memory/ + .prompt/。聊天记录不可靠，项目文件才可靠。
交付公式
完成 = 代码 + 编译 + 测试 + 运行 + 记忆更新 + Git 提交。没有验证证据，就不算完成。
团队落地 10 步清单
1. 选一个真实项目做试点，而不是只做 Demo。
2. 明确主要 Harness：Codex、Claude Code、Gemini CLI、OpenCode、Cursor/Cline/Roo。
3. 明确模型搭配：主控、扫描、编辑、审查分别用谁。
4. 写首版 prompt.md，作为所有 AI 的统一入口。
5. 初始化 .memory/：系统全景、编码规范、雷区。
6. 初始化 .prompt/：第一个原子任务和后续任务链。
7. 固定编译、测试、运行命令，写入交割协议。
8. 规定失败 3 次后的 Zoom out / 换模型 / 审查机制。
9. 每次推进后更新记忆、生成下一阶段 Prompt。
10. 全绿后提交推送，Commit 写清背景、变更、验证和风险。