大家好,我是程序员鱼皮。
用 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。
本文已收录到我免费开源的 ,上千张图、几十万字,完全免费开源,从零基础快速学会 AI 编程,再到做出自己的产品、跑通变现全流程,一次拿捏。
![]()
可以点我头像,然后私信「AI编程」获取:
我是鱼皮,持续分享 AI 编程干货。学会的话记得点赞收藏和关注,也欢迎在评论区聊聊:你在用 AI 编程时踩过什么坑?是怎么解决的?
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.