傻子可懂的 Harness Engineering 入门教程 + 项目实战,一次搞懂 AI 编程工程化!

大家好,我是程序员鱼皮。

用 AI 编程的朋友应该都遇到过这些问题:

  • 你让 AI 改下页面的样式,结果它没搞清楚你到底想干嘛,重新开发了整个布局。
  • 你前面明明要求单文件的代码不超过 200 行,结果聊了十几轮之后,AI 把前面的约束给忘了,写了个 1000 行代码的大文件。
  • 还有更头疼的,你让 AI 修一个项目里的 Bug,结果又出了 3 个新 Bug,项目都跑不起来了,代码越改越乱。

前两个问题已经有了不少解决办法,比如写好提示词、给 AI 提供充足的信息,但第三个问题就比较棘手了。

如果你想让 AI 做好一个完整的项目,你还得给它搭一整套靠谱的工作环境和工作流程。

这就是最近在 AI 圈很火的 Harness Engineering。

写这期内容前,我看了不少国内外讲 Harness 的教程,很多都花了大量篇幅讲 AI 发展史和枯燥的理论,看完就忘了。所以我换了个思路,先通俗易懂地讲清楚 Harness 是什么,然后带你实战怎么用 Harness 做出完整大项目,还会告诉你怎么最快上手 Harness。

点个收藏,我们开始~

一、快速了解 Harness Engineering

Harness 是什么?

Harness 这个词翻译过来就是「马具」。如果把 AI 模型比作一匹马,那 Harness 就是你驾驭这匹马所需要的一切,比如缰绳、路线规划、围栏等等。

我们要做的,就是怎么让这匹马跑得更快、更稳,顺利完成任务。

具体来说,Harness 就是围绕 AI 模型搭建的一整套工作环境和工作流程。你给 AI 写的项目规则文件、配置的各种工具、安排的任务拆分和执行顺序、设计的测试检查流程,这些统统都算 Harness。

为什么它突然火了?

知名的 AI 框架 LangChain 做了个实验,使用同一个 AI 模型,只优化围绕模型搭建的 Harness 部分,编码基准测试的排名直接从 30 名开外冲到了前 5!

OpenAI 团队也做了类似的尝试。3 个人的小团队,全靠 Harness 引导 AI 生成了上百万行代码,最终做出的产品已经在内部正式上线使用了。

看到这些成果之后,不少知名 AI 公司和技术大佬纷纷写了博客来讲 Harness,于是把这个概念带火了。

有了这些知名公司和大佬的背书,现在行业达成了一个共识:AI 编程的瓶颈不在模型有多聪明,而在你围绕模型搭的这套环境和流程够不够好。

Harness 的发展过程

很多人以为 Harness 是 2026 年蹦出来的新东西。其实从 2022 年 ChatGPT 出来的时候,大家就已经在做 Harness 了,只不过当时没叫这个名字罢了。

为了让你更好地理解 Harness,我先带你简单回顾一下这几年 AI 工程的发展。

1、提示词工程(2022 ~ 2024)

简单来说,就是怎么 通过对话让 AI 听懂你的需求

我们学着给 AI 设定角色、约束输出格式、用思维链让它一步步思考、给几个示例让它模仿。这些技巧虽然简单,但确实能让 AI 的输出质量提升一大截。

2、上下文工程(2025)

在提示词工程的基础上更进一步,核心是怎么 在对的时候把对的信息喂给 AI

比如写 AGENTS.md 规则文件让 AI 了解项目背景,用 RAG 让 AI 能检索到相关资料,对过长的上下文做压缩和摘要,甚至给 AI 建立跨对话的记忆机制,让它不会聊着聊着就断片儿。

3、Harness Engineering(2026)

在上下文工程的基础上又往前走了一步。除了关注给 AI 提供什么信息,还要关注给它配什么工具、大任务怎么拆分成小步骤分批完成、出了问题怎么自己检查和修复、怎么防止代码质量随着迭代慢慢下滑。让 AI 不只是回答问题,而是 持续靠谱地完成整个任务

你会发现,三者是层层包含的关系。

  • 提示词是最内层,关注的是「怎么给 AI 下指令」
  • 上下文包裹着提示词,关注的是「怎么给 AI 提供信息」
  • Harness 把它们全部包在里面,关注的是「怎么让 AI 持续靠谱地干完一整件事」

业界总结了一个公式:Agent = 模型 + Harness

也就是说,围绕 AI 模型搭建的工具、规则、流程、检查机制,全都属于 Harness 的范畴。

二、Harness 的五个核心模块

讲到这里,你可能觉得 Harness 挺大、挺抽象的。

但其实没那么复杂,Harness 要解决的就是 AI 干活时会遇到的几个核心问题。

接下来我一个个给大家讲解。如果你是程序员,或者有做过项目的经验,你会发现这些方法其实都不陌生。

1、上下文架构:让 AI 了解项目背景和规矩

AGENTS.md 规则文件、分层文档、上下文压缩、渐进式加载

做项目的第一步是什么?

当然是了解需求、项目背景和开发规范。用 AI 做项目也一样,你得把这些信息喂给它。

我们可以写 AGENTS.md 这样的规则文件,告诉 AI 这个项目用什么技术栈、遵循什么代码规范、有哪些禁止事项。这跟我们传统做项目时写需求文档、方案设计文档是一样的。

不过要注意,AI 能处理的上下文空间是有限的。OpenAI 团队就踩过一个坑,他们试过把几千行的规则塞进一个大文件,结果 AI 反而更容易忽略里面的关键信息。后来他们改成把 AGENTS.md 当成一个 目录 来用,只写大概 100 行的摘要和索引,然后在 docs/ 目录下放详细的设计文档。AGENTS.md 里面写清楚「前端规范看 docs/FRONTEND.md、安全相关看 docs/SECURITY.md」这样的指引,AI 需要什么就去读对应的文件。这种 按需加载 的思路,就是上下文架构的核心。

2、执行能力:给 AI 装上手脚和工具

工具调用、Bash 终端、文件系统、MCP、Browser Use、Skills 技能包

AI 模型本身只能输出文本。如果你想让 AI 真正帮你开发项目,就得通过工具调用让它具备操作电脑的能力,比如给它配一个终端环境来执行命令、给它文件系统来读写代码、给它浏览器来测试网页。

在这个基础上,还可以通过 MCP 进一步扩展 AI 的操作范围,比如读写数据库、联网搜索和抓取最新的内容等等。

还有 Agent Skills,把一整套复杂的工作流封装成技能包, 让 AI 能够快速学会各种专业技能,比如自动生成 PPT、处理 Excel 表格之类的。总之就是让 AI 能用的工具越多,它能帮你干的活就越多。

3、任务编排:给 AI 安排好工作计划

Plan Mode、任务拆分、增量开发、文档沉淀、SubAgents 并行执行

如果你丢给 AI 一个大需求,它可能会尝试一把梭全部搞定。但 AI 的上下文空间是有限的,可能开发到一半信息就装不下了,前面定好的方案和约束慢慢被冲淡,最后留下一堆跑不起来的渣渣代码。

怎么解决这个问题呢?

最基本的做法就是把大任务拆成小任务,每次只做一个功能点。在开始之前可以先用 Plan Mode 计划模式让 AI 出方案,人工确认后再动手写代码。

每做完一个功能,最好都沉淀一下文档,包括当前实现了哪些功能、用了什么技术方案、还有哪些待做的事项。这样哪怕后面新开一个 AI 对话窗口,也能让 AI 通过读文档快速了解之前做了什么,不用从头再来。

如果有多个互不依赖的小任务,还可以用 SubAgents 让它们并行执行,效率更高。我们传统开发项目时的任务拆分、前后端并行开发,也是同样的思路。

4、反馈机制:让 AI 自己检查自己的工作

Linter 代码检查、自动化测试、Browser Use 端到端测试、Agent 互审

AI 写完代码之后,可能会自信满满地跟你说任务已经完成了,结果你一点运行,全是 Bug。

所以我们得让 AI 在写完代码之后能自己检查自己的工作。比如跑 Linter(代码检查工具)看看有没有语法和规范问题,跑自动化测试验证功能是否正确,甚至让 AI 自己打开浏览器实际操作一遍,功能可以正常使用才算是真正完成了任务。

如果测试没通过,AI 可以自动读取报错信息,分析原因并尝试修复。当然我们也可以人工检查,把发现的问题、报错信息和截图提供给 AI,让它来修。

甚至还可以让另一个 AI 来审查代码,搞一个「多 Agent 互审」的机制,跟我们传统做项目时多个同事一起 Code Review 是一样的。

5、架构护栏:防止代码越改越乱

架构约束 Linter、Pre-commit Hooks、垃圾回收机制、Git 检查点

AI 生成代码有个特点,就是它会模仿仓库里已有的代码风格,哪怕是烂代码。比如同样的页面代码写了好几遍,也不知道要拆分成可复用的组件,会导致改了一个地方其他重复的地方就漏改了。时间一长,技术债就越滚越大。

怎么防止这个问题呢?

常见的做法是写一批专门的 Linter 来强制执行架构层面的约束。注意这跟前面反馈机制里提到的 Linter 不太一样,前面那个查的是代码风格和语法问题,这里的 Linter 查的是架构规则,比如 UI 层不能直接调用数据库层、模块间的依赖必须是单向的。AI 一旦违反就会被自动拦住,还可以通过 Pre-commit Hooks(代码提交前的检查钩子)在提交时自动拦截不合规的代码。

OpenAI 还搞了一套叫「垃圾回收」的机制,定期让 AI 扫描代码库,检查有没有偏离架构规范的地方,自动提交修复 PR,持续偿还技术债。

另外建议每完成一个功能就用 Git 提交一次代码。Git 是一个版本控制工具,能记录代码的每个历史版本,相当于给项目打了一个存档点,万一后面改出了问题,可以随时恢复到之前的状态。


看到这里你会发现,写规则文件、配备工具、拆分任务、执行测试、定架构规范...... 这些其实都是程序员做项目时常用的方法,换到 AI 编程场景里,就是 Harness。

Harness 不是什么新技术,它本质上是把我们已有的工程经验,系统地应用到 AI 上。

所以有做项目经验的朋友,你们积累的工程能力到了 AI 编程时代一样实用。我也建议大家平时多做完整的项目、多积累工程经验,越懂工程的人越能驾驭 AI。

三、Harness 项目实战

概念讲完了,接下来我用一个实际项目带大家看看,Harness 在真实开发中到底是怎么落地的。

这个项目是我在 编程导航 全程直播带做的 AI 编程全栈项目「万能视频下载总结器」。我用 AI 从零开发了一个能从各大平台下载视频、并用 AI 总结视频内容的网站,还做了 SEO / GEO 优化和 Stripe 国际支付。

回过头看,整个开发过程其实就是一套完整的 Harness 实践。

下面我按照企业做项目的阶段来讲,看看每一步用了哪些 Harness 方法。

1、方案设计阶段

动手写代码之前,我做了一件很重要的事:先自己想清楚核心方案

这个项目需要什么样的前端界面?需不需要后端?核心的视频下载能力怎么实现?

我是自己先思考,并且通过 AI 在全网调研了一番,然后决定用 yt-dlp 这个开源项目作为下载功能的核心实现、技术栈以 Python 为主。

然后我把这些思考写成文档,关联给 AI,让它在我的方案基础上补充细节。

注意,我特意 开启了 Plan Mode,让 AI 先出方案找我确认,而不是上来就直接写代码。

AI 生成了一个技术方案文档,我仔细看了一遍,发现它把一些后续才做的功能也纳入计划了,于是我就跟它说「先完成核心的视频下载功能」,一步步来。

这就是 任务编排上下文架构 在方案阶段的应用。先规划再执行,给 AI 提供充足的背景信息,约束它不要一上来就一把梭。

2、编码开发阶段

确认方案之后,AI 就进入了开发环节。这个阶段我做了几件很关键的事。

首先是 给 AI 装上联网能力。我配置了 Firecrawl MCP 让 AI 能抓取网页内容,又配置了 Context7 MCP 让 AI 能获取最新的技术文档。

这样 AI 在开发过程中遇到不确定的 API 用法,就可以自己去查最新文档,而不是用过时的写法。

核心的视频下载功能做完后,我 让 AI 沉淀了一总结文档,记录当前的功能、架构和实现细节,然后提交到 Git。

这一步很关键,因为后面要做新功能的时候,我会新开一个对话窗口,把这些文档关联给 AI,它就能快速找回记忆,不用从头再来。

为什么新功能要新开对话呢?

因为在同一个 AI 对话框中聊久了上下文会越来越脏,AI 的表现会下降。新开对话相当于给 AI 一个干净的环境,然后用文档帮它找回需要的信息就好了。

这些操作本质上都是在做 上下文架构执行能力 的建设,给 AI 装好工具、维护好上下文信息。

3、测试验证阶段

AI 不仅能写代码,还能 自己打开浏览器测试

在这个项目里,AI 通过 Cursor 内置的 Browser Use 功能,自己启动浏览器、输入视频链接、点击解析按钮,然后检查结果是否正常显示,比人工测试方便太多了。

不过 AI 的自测也不是万能的,遇到解决不了的问题,还是要人工出马。

比如我通过人工测试发现 B 站视频下载报了 403 错误,就把报错信息直接贴给 AI,让它自主分析和修复。AI 很快发现是防盗链的问题,然后自己搞定了。

有时候 AI 会卡在同一个问题上反复修不好。比如 Markdown 渲染出了问题,我跟 AI 说了好几轮都没修对。

后来我换了个角度去描述这个问题,跟它说:你不应该改后端 Python 代码么?如果后端 SSE 返回的内容丢失了,前端解析出来肯定是错的吧?

AI 这才恍然大悟,改了后端逻辑就修好了。

还有个小技巧,就是不要每次测试都走完整的「输入链接、解析、总结」流程,太慢了。我让 AI 自己模拟一段 Markdown 数据直接测试渲染效果,这样反馈要快得多。

这些都是 反馈机制 的体现,给 AI 提供反馈信号让它自我修复,AI 搞不定的时候人工介入纠偏。

Harness 不是完全放手不管,而是把人的精力用在最关键的地方。

4、功能扩展阶段

核心的视频下载功能跑通后,我又加了 3 个小需求:优化 Markdown 排版、思维导图全屏加下载、字幕文件下载。

这三个需求相互独立,所以我在提示词里引导 AI 合理规划任务 并行开发,AI 用了 SubAgents 同时执行多个子任务。

每完成一个功能,我就让 AI 提交代码并更新文档,作为检查点。万一后面改出了问题,可以随时回滚。

后来给项目做 SEO 优化的时候,我还用了一个 SEO Audit 技能,让 AI 自动分析网站并生成优化方案。

做完 SEO 之后,还要做 GEO 优化,我直接复用了 SEO 的对话上下文,这样 AI 已经了解了项目背景和代码,不用重新再读一遍,省了不少时间。

上面这些操作涵盖了 任务编排 (并行开发)、架构护栏 (Git 检查点)和 执行能力(Skills 扩展)几个方面,都是 Harness 的重要实践。

四、怎么快速上手 Harness?

Harness 本身并不复杂,也没什么需要专门去啃的理论。上面项目里的很多操作,都是你现在立刻能用的 Harness 技巧。

我按照做项目的流程,给大家总结几条实用的 Harness 方法:

1)做项目之前先写好 AGENTS.md 规则文件,把项目背景、技术栈、代码规范都告诉 AI

2)先让 AI 出方案并人工确认,再动手写代码

3)用 MCP 和 Skills 给 AI 配好工具,让它能联网查资料、获取最新的信息

4)做完功能一定要让 AI 自己跑测试验证,确保能正常运行

5)每完成一个功能就让 AI 沉淀文档并提交代码,作为 AI 的「存档点」

Harness 工具

如果你缺乏做项目的经验、或者觉得自己搭建 Harness 太麻烦,也可以直接使用一些现成的开源工具。

比如 Spec Kit 工具使用的是 SDD(Spec-Driven Development)规范驱动开发的思路,它会先引导你把需求拆解成详细的规范文档,然后让 AI 按照文档一步步开发,每个阶段都有明确的验收标准。

还有 Superpowers 这种 Agent Skills 框架,它内置了一整套开发工作流,包括强制 TDD(Test-Driven Development)测试驱动开发,就是先写测试再写代码,还有两阶段代码审查、子代理协作等,相当于直接给 AI 装了一套完整的项目管理流程。

虽然这些工具可以帮你快速起步,但从长远来看,理解 Harness 的思路比掌握某个工具更重要

毕竟工具一直在变化,但「怎么系统地驾驭 AI」这个思路是通用的。想要真正掌握 Harness,最好的办法还是在实战项目中去体会。

我在 编程导航 带大家做过几套 AI 编程全栈项目,除了上面提到的万能视频下载总结器,还有 AI 热点监控工具、GitHub 文档翻译器、AI 闯关学习小程序等,其实都是 Harness Engineering 的完整实战。每个项目都是从需求分析开始,到方案设计、AI 编码开发、测试验证、功能扩展,走完一整套流程。如果你想跟着实战项目边做边学 AI 编程和 Harness,可以来看看。

最后哔哔

以前做项目,工程师的核心工作是写代码。现在 AI 能帮我们写越来越多的代码了,但这也意味着我们得花更多精力在需求分析、方案设计、任务拆解、质量把关这些事情上。

能不能用好 AI,取决于你自己的工程能力有多强。

所以我一直建议大家多做完整的项目,从零到一走完全流程,这个过程中积累的工程经验,就是你驾驭 AI 最好的 Harness。

本文已收录到我免费开源的 《Vibe Coding 零基础入门教程》,上千张图、几十万字,完全免费开源,从零基础快速学会 AI 编程,再到做出自己的产品、跑通变现全流程,一次拿捏。

开源指路:https://github.com/liyupi/ai-guide

我是鱼皮,持续分享 AI 编程干货。学会的话记得点赞收藏和关注,也欢迎在评论区聊聊:你在用 AI 编程时踩过什么坑?是怎么解决的?

相关推荐
CV-杨帆2 小时前
AutoDL 云服务器上安装 Kimi Code + NanoBot 并配置 GPU 使用完整教程
ai
mcrncr_5242 小时前
React Fiber 异步渲染原理讲解
编程
eohlke_7902 小时前
游戏匹配算法:平衡玩家技能与等待时间的策略
编程
akdpfz_5282 小时前
实时流数据处理平台架构设计与延迟优化策略
编程
cdlnih_4412 小时前
微前端架构模块联邦与样式隔离的技术解决方案深度剖析
编程
sunneo2 小时前
专栏B-产品心理学深度-01-认知偏差手册
人工智能·产品运营·产品经理·ai编程·ai-native
维元码簿2 小时前
Claude Code 深度拆解:工具系统——权限、沙盒与错误处理
ai·agent·claude code·ai coding
xrchpg_6182 小时前
Spring Boot 自动配置机制深入分析
编程
深念Y2 小时前
TraeCN 新老用户排队机制差异的实测与分析
ide·编程·claude·模型·cli·trae·vibe coding