Harness Engineering 深扒：提示词不是主战场，真正的主战场是给 Agent 搭一层能交付的工程外壳

这条视频表面上是在解释三个新旧概念：Prompt Engineering、Context Engineering、Harness Engineering。它回答的是“Harness Engineering 是什么，和提示词工程、上下文工程有什么关系”。但如果只把它看成一条概念科普，就会看浅。

它真正值得深扒的地方，是把 AI 开发这几年从“会不会写提示词”到“会不会管上下文”再到“会不会让 Agent 稳定交付”的演进，讲成了一条连续工程链：提示词工程解决模型乱说话，上下文工程解决信息怎么进入模型，Harness Engineering 解决模型怎么在工具、规则、反馈和编排的外壳里持续做事。

这条视频来自“小白debug”，时长约 521 秒。SenseVoice 逐字稿里有一些识别误差，比如 Harness 被识别成 honess/honey，Claude Code 被识别成 cloud code，ReAct 被识别成 react；但双轨合并后主线很清楚。视频先从 OpenAI 官方文章里出现的 Harness Engineering 说起，指出很多人还没搞懂就开始跟风吹爆；然后依次拆大模型本质、Prompt Engineering、Context Engineering、Agent 的 ReAct 循环、规则文件、记忆层、反馈层、编排层，最后落到 Claude Code、CLAUDE.md、Spec Kit 和 SDD 这种开发实践上。

我额外核对了 OpenAI 官方博客，《Harness engineering: leveraging Codex in an agent-first world》确实把重点放在“系统、脚手架、环境和杠杆”上；OpenAI 另一篇关于 Codex agent loop 的文章也把 Codex harness 描述为承载 agent loop 和执行逻辑的核心部分。也就是说，视频讲的不是自造概念，它只是把官方和工程圈正在形成的语言，翻译成更适合中文开发者理解的一套层次图。

一句话定性：这条视频最重要的判断不是“又多了一个新词”，而是“Agent 能不能交付，越来越取决于模型之外那层工程外壳”。 未来程序员的主战场不会只是写代码，也不会只是写 prompt，而是写规则、写环境、写测试、写路由、写 skill、写任务拆解，让模型在一套被约束的系统里行动。

一、先吃透原视频：它其实在讲 AI 开发范式的三次升级

视频开场很直接：“Harness Engineering 是什么？和提示词工程、上下文工程有什么关系？”随后马上补一刀：这个词在 AI 圈火起来之后，很多人还没明白就开始跟风吹爆。这个开头不是简单科普，而是在做“概念清场”。AI 圈最常见的问题就是新词太多，今天 RAG，明天 Agent，后天 Context Engineering，再过几天又 Harness Engineering。概念如果不放进一条工程链里，就会变成朋友圈里的术语装饰。

作者先把大模型拆到底层：LLM 本质上是一个超大参数文件，加载到显卡内存，加上 HTTP 接口，就成了模型 API；加聊天界面就是 Chat AI；加代码编辑器就是 AI IDE。这个说法粗糙但很有效，因为它先把“神奇的 AI”降回工程对象。模型不是一个会主动工作的员工，它只是基于当前输入预测下一个 token 的概率机器。你给它的输入太宽泛，它的输出就发散；你不给边界，它就不知道完整函数、代码风格、禁止事项、输出格式。

于是第一层能力出现：Prompt Engineering。视频没有把提示词工程神秘化，而是说它本质上是用角色设定、背景、历史对话、参考文档、限制和输出格式这些约束，把模型稳定拉向你想要的输出。它解决的是“无引导乱说话”的问题。这个定义很适合教学，因为它把 prompt 从“咒语”还原成“约束集合”。提示词写得好，不是因为某几个神秘词，而是因为你把任务边界、评价标准和输出形态说清楚了。

但提示词只是上下文的一部分。第二层能力是 Context Engineering。视频讲得很关键：打包发给大模型的所有信息都叫上下文，提示词只是其中一块。模型不准，很多时候不是它不聪明，而是它知道得不够多；但上下文窗口有限，多轮对话、代码文件、报错日志、参考文档、历史记录一多，就会把窗口打满。压缩或丢弃信息不可避免带来上下文腐化，表现就是模型记不住、前后不一致、目标被冲淡。

于是问题从“怎么写一段好 prompt”升级为“怎么在合适的时候，把合适的信息放进有限上下文”。视频把 Context Engineering 总结成三个动作：召回、压缩、组装。召回是找相关信息，可以来自外部资料、历史聊天、代码环境、运行报错；压缩是把信息变小，可能通过总结、摘要、裁剪；组装是决定信息的顺序和位置，因为模型对不同位置的信息关注度不同。这个三步特别重要，它把上下文工程从抽象名词变成可执行动作。

第三层能力才是 Harness Engineering。视频说得很直白：提示词工程解决模型乱说话，上下文工程解决信息组织，但模型本身只能聊天，不能帮我们干活。要让它干活，就要给它 Bash 沙箱、文件系统、MCP、外部工具，让它能读写代码、执行命令、跑测试。外部程序把提示词和上下文组装好发给模型，模型负责思考，工具负责执行，执行结果和报错再回到上下文，继续推理和执行。这就是 ReAct 式的思考和行动循环。

这里有一个非常好的金句：“Agent 的本质就是一个 for 循环。”这句话虽然有一点简化，但抓住了重点。很多人把 Agent 想成一个新物种，其实从系统角度看，它就是一个不断重复“读上下文、调用模型、执行工具、拿反馈、再读上下文”的循环。循环越长，上下文越膨胀；上下文越膨胀，目标和约束越容易漂移；漂移不被治理，Agent 就会跑偏或死循环。

所以视频又引出规则文件。为了保证每轮给模型的上下文里都包含核心信息，比如项目目标、技术栈、需求背景、代码风格、禁止事项，就把这些东西写成固定文件，放在代码仓库里。Claude Code 有 CLAUDE.md，Cursor、Trae 等工具也有各自的规则入口。规则文件可以作为系统提示词自动注入上下文。规则文件太长，就继续拆成 bg.md、stack.md、rules.md，再用一个简单路由告诉模型什么时候读哪个文件。这样就形成了记忆层。

有记忆层还不够。执行命令、跑 linter、跑单元测试、看 CI 结果，再把输出和报错加回上下文，驱动 Agent 下一轮修复，这形成反馈层。任务太大、目标不清、结束条件不明确，Agent 还是容易跑偏，于是需要把大任务拆成有明确标准的小任务，按阶段执行，形成编排层。到这里，视频给出完整框架：编排层、执行层、反馈层、记忆层，再加上提示词工程和上下文工程，共同组成包裹大模型的工程外壳，这就是 Harness Engineering。

所以这条视频真正讲的是 AI 开发范式的三次升级：

第一，从“我怎么对模型说话”升级到“我怎么约束模型输出”，这是 Prompt Engineering。

第二，从“我怎么写提示词”升级到“我怎么管理所有进入模型的信息”，这是 Context Engineering。

第三，从“我怎么让模型回答”升级到“我怎么让模型在工具、规则、反馈和编排中完成任务”，这是 Harness Engineering。

这三层不是互相替代，而是包含关系。提示词工程是上下文工程的一部分；上下文工程是 Harness Engineering 的关键组成；Harness Engineering 把上下文、工具、记忆、反馈、编排全部串成一个可交付系统。视频最后那句“只要不是大模型的那部分，都属于 Harness Engineering 的范畴”，虽然略宽，但很适合建立大局观：模型越强，外壳可以越薄，但外壳不会消失。

二、音画合并时间轴

0 到 40 秒，视频用概念焦虑开场。画面是 Harness Engineering、Prompt Engineering、Context Engineering 三个词并排出现，随后切到 OpenAI 博客标题和中文“驾驭工程”。口播强调这个词火起来后很多人跟风，但概念不清。这里的作用是建立权威来源，同时把观众从“听过新词”拉到“需要重新理解”。

40 到 95 秒，作者解释大模型本质。画面用硬盘里的模型文件、显卡、API、聊天界面、AI IDE 串联，讲清楚 LLM 只是预测下一个词。然后用“给一段代码说加个排序”举例，说明指令宽泛时模型会只返回局部代码，必须补充“给我完整函数，不要乱改我的代码”等约束。

95 到 160 秒，进入 Prompt Engineering 和 Context Engineering。画面列出角色设定、背景、历史对话、参考文档、限制、输出格式，说明这些构成提示词；随后提示词和资料一起被框成上下文，进入上下文窗口。口播强调提示词只是上下文的一部分，大模型一次能处理的信息有限。

160 到 245 秒，作者讲上下文腐化和上下文工程。多轮对话打满窗口后，需要压缩和丢弃信息，导致模型前后不一致。画面出现“召回、压缩、组装”三步，分别对应找资料、总结压缩、调整顺序。这里是全片的信息密度高点，也是把 Context Engineering 讲实的关键段。

245 到 315 秒，视频从 Context Engineering 转向 Harness Engineering。口播说模型更聪明了，但只会聊天，没法干活；于是加入 Bash 沙箱、文件系统、MCP、外部工具，形成执行层。画面展示大模型、上下文工程、执行层循环，解释 ReAct：模型思考，外部程序执行，报错再回到上下文。

315 到 390 秒，作者指出 Agent 循环一长就会膨胀和腐化。解决办法是固定核心信息，写成规则文件，比如 CLAUDE.md，把项目目标、技术栈、需求背景、代码风格、禁止事项等持续注入上下文。规则文件太长就拆分，再加路由，只在需要时加载全文。这一段把“记忆层”讲出来了。

390 到 455 秒，视频继续补上反馈层和编排层。执行层跑 linter、单元测试、CI，报错回传上下文，驱动自动修复，这是反馈层；大任务拆成明确标准的小任务，按规划分步执行，这是编排层。画面用流程图表示大任务到小任务，强化“Agent 不只是循环，还要被管控”。

455 到 521 秒，进入落地和收尾。作者用 Claude Code 举例，说最轻量的方法是在 CLAUDE.md 写清项目背景、希望模型做什么、不做什么、做完跑哪些检查；如果不想自己写，可以用 Spec Kit 之类扩展，先生成约束文件、明确需求、制定计划、拆解任务，再修改和测试。这套开发方式就是 SDD，本质上是 Harness Engineering 的落地。最后作者把程序员工作从写代码转向写规则和 skill，做成幽默收束，并用“现在大家通了吗”引导关注。

三、7 段文案拆解

【1】开头钩子：概念清场型钩子，用“大家都在吹但没搞懂”制造停留

这条视频前 3 秒的钩子是一个问句：“Harness Engineering 是什么？和提示词工程、上下文工程有什么关系？”紧接着又补上“OpenAI 提到后它快速火了，很多人不知道它到底是什么就开始跟风吹爆”。这是典型的概念清场型钩子。

它不是直接说“今天教你 Harness Engineering”，而是先把观众放进一个认知尴尬里：你可能听过这个词，但你未必真懂；别人可能也在乱讲，所以你需要一个靠谱解释。对 AI 技术内容来说，这个钩子很有效，因为 AI 圈新词太快，很多观众都有“我好像落后了”的焦虑。

画面上也配合得比较好。开场有 Harness、Prompt、Context 三个英文术语并列，马上把视频定位成概念关系梳理；随后出现 OpenAI 博客和“驾驭工程”翻译，提供权威来源；再用“全网资料参差不齐，如有差异，以我为准”建立博主人设。这个表达有一点霸气，也有一点自嘲，适合技术科普号。

底层逻辑是：复杂概念视频最怕观众觉得“这和我没关系”。作者没有先讲定义，而是先讲“这个词已经火了，但很多人没讲明白”。这把内容从普通科普变成“帮你避开概念污染”。对于开发者来说，避免被术语带偏本身就是强利益点。

评分：★★★★☆。强点是问题明确、权威来源明确、冲突明确；弱点是前几秒术语较多，对完全小白有门槛。但这个视频面向的是 AI 圈和开发者，术语门槛反而筛选了精准受众。

可复制钩子模板：

最近【新概念】突然火了，很多人还没搞懂就开始吹。
它到底是什么？和【旧概念 A】、【旧概念 B】是什么关系？
今天我把这几个概念串起来讲透。

【2】人设 & 声音：技术型翻译官，既能讲底层，又敢给结论

作者的人设是“技术型翻译官”。他不是单纯搬运 OpenAI 博客，也不是营销号式地说新概念很重要，而是把抽象术语拆成程序员能理解的系统结构：模型、API、上下文窗口、召回、压缩、组装、执行层、规则文件、测试反馈、任务编排。

声音风格有三个特点。

第一，语速快但逻辑链清楚。视频长达 8 分 41 秒，在抖音里已经算长，但它几乎没有闲话。每一段都在回答上一个段落留下的问题：模型为什么会乱说？因为它只预测下一个词；怎么让它稳定？做提示词工程；提示词为什么不够？因为上下文更大；上下文为什么难？因为窗口有限会腐化；Agent 为什么需要 Harness？因为模型要靠工具、反馈和编排才能交付。

第二，专业词和口语梗混合。比如“AI 圈三天一重磅，五天一炸裂”“看到这里还没睡着的弹幕扣个 0”“这不是广子”“Agent 的本质就是一个 for 循环”。这些话让硬概念不至于太像课堂，也能在长视频里维持轻松感。

第三，敢给强判断。作者没有一直说“可能、也许、大概”，而是明确给关系：提示词工程是上下文工程的一部分；Harness Engineering 包含模型之外的工程外壳；程序员以后主战场会从写代码转向写规则和 skill。这种强判断会提升视频记忆度。

适合受众是三类人：第一，正在用 Claude Code、Cursor、Trae、Codex 的开发者；第二，知道 prompt 但开始遇到上下文漂移、Agent 跑偏的人；第三，想把 AI 开发工具系统化教学的内容创作者或机构。它不太适合完全没用过 AI IDE 的观众，因为很多例子默认你理解代码、文件、测试和 CI。

值得借鉴的语言习惯是“先降维，再升维”。作者先把 LLM 降成参数文件和 token 预测机，打掉神秘感；再逐层升回提示词、上下文、Agent、Harness，让观众知道每一层为什么必要。很多 AI 科普要么只降维，显得模型很普通；要么只升维，显得概念很玄。这个视频的平衡比较好。

【3】信息密度 & 节奏：521 秒做一条从模型到工程外壳的递进链

视频总时长约 521 秒，信息密度很高，但不是乱堆。它的节奏是“定义一个问题，给一层工程解法，再指出这层解法的新问题”。这种节奏适合讲复杂概念，因为观众会跟着问题往下走。

前 0 到 95 秒是入口段：先抛新概念，再解释大模型本质和 prompt 为什么需要约束。这里信息密度中等，主要负责搭地基。

95 到 245 秒是第一高密度段：提示词、上下文、上下文窗口、上下文腐化、召回、压缩、组装连续出现。作者用大量图标和模块图降低理解压力，但口播速度偏快。观众如果没有基础，可能会在“上下文腐化”之后掉线。

245 到 390 秒是第二高密度段：执行层、ReAct、Agent 循环、规则文件、记忆层、反馈层、编排层陆续出现。这一段其实已经从“解释概念”进入“搭系统架构”。视频的强点是每个抽象层都有一个程序员熟悉的落点，比如 Bash、文件系统、MCP、linter、单元测试、CLAUDE.md。

390 到 521 秒是落地段：Claude Code、CLAUDE.md、Spec Kit、SDD、程序员写规则和 skill。这里节奏稍微放松，因为前面概念已经铺完，后面更多是应用和态度收束。

它有明显的“刺激和留白”循环。每讲一个抽象概念，画面会停在流程图或关键词上；每当信息过密，作者会插入弹幕互动“扣 0”“扣 1”或轻松梗。这些互动并不只是求评论，也是在给观众一个心理停顿：我知道信息很多，你还跟得上吗？

不过这条视频也有一个节奏问题：它的信息链太完整，反而不适合随便刷到的轻度观众。8 分多钟讲完三层工程概念，很容易让人觉得“值得收藏，但需要二刷”。如果要提高完播，可以把中间某些概念做成章节提示，比如“第一层 Prompt”“第二层 Context”“第三层 Harness”，让观众更清楚自己走到哪。

【4】讲解手法 & 内容结构：不是术语并列，而是能力嵌套

这条视频最强的结构，是它没有把 Prompt Engineering、Context Engineering、Harness Engineering 做成三个并列定义，而是做成嵌套关系。

第一层，模型原理。LLM 只是基于输入预测下一个词，所以输入越模糊，输出越发散。这个底层前提决定了为什么需要提示词工程。

第二层，提示词工程。提示词工程通过角色、背景、历史对话、参考文档、限制、输出格式等约束，让模型稳定输出。它解决的是“模型不听话”的问题。

第三层，上下文工程。提示词只是上下文的一部分，真正进入模型的是所有信息。上下文窗口有限，信息会腐化，所以需要召回、压缩、组装。它解决的是“模型不知道足够相关信息，或者知道的信息太乱”的问题。

第四层，Agent 工程。模型会说但不会做，所以要给工具和执行环境；执行结果回到上下文，再驱动下一步。它解决的是“模型不能行动”的问题。

第五层，Harness Engineering。Agent 循环会膨胀、跑偏、死循环，所以要用规则文件形成记忆层，用测试和报错形成反馈层，用任务拆解形成编排层，用工具形成执行层。它解决的是“模型能行动但不稳定、不可靠、不知道何时完成”的问题。

这条结构最有说服力的一点，是每一层都不是凭空出现，而是上一层的局限逼出来的。提示词解决不了资料管理，所以有上下文工程；上下文工程解决不了行动，所以有执行层；执行层解决不了长期漂移，所以有记忆层和反馈层；反馈层解决不了大目标管控，所以有编排层。这样讲概念，观众不会觉得是在背名词，而是在看一个系统为什么长成现在这样。

它还大量使用具体化手法。大模型不是“智能体”，而是 gpt-5.bin、claude-4.6.bin 这种参数文件；Prompt 不是玄学，而是“给我完整函数，不要乱改我的代码”；上下文工程不是抽象优化，而是召回、压缩、组装；规则文件不是概念，而是 CLAUDE.md、bg.md、stack.md；反馈层不是口号，而是 linter、单测、CI 报错。

最有说服力的一句话是：“大模型越强，外壳可以做得越薄，但无论怎么样，这层外壳都得有。”这句话把很多 AI 争论收束了。模型能力进步当然重要，但只要任务需要工具、状态、权限、上下文、验证和交付，外壳就不会消失。它可能变薄、变标准化、被平台内置，但不会不存在。

【5】金句 & 记忆点：把新概念压成几句能带走的话

这条视频有几句非常适合作为二次传播锚点。

第一句：“提示词只是上下文的一部分。”这是理解 Prompt Engineering 和 Context Engineering 关系的钥匙。很多人还停留在“prompt 写得越长越好”，但真正重要的是上下文里的信息是否相关、完整、顺序合适、没有腐化。

第二句：“上下文工程可以总结为三个步骤：召回、压缩、组装。”这句很适合做成方法卡。它把一个容易被玄学化的概念变成了三个操作。召回决定看什么，压缩决定带多少，组装决定怎么放。

第三句：“Agent 的本质就是一个 for 循环。”这句最容易传播，因为它把 Agent 去神秘化了。不是说 Agent 真的只有 for 循环，而是说它的基本运行形态就是循环：模型想一步、工具做一步、结果回上下文、再想下一步。

第四句：“只要不是大模型的那部分，都属于 Harness Engineering 的范畴。”这句有夸张，但适合建立边界意识。模型之外的工具、上下文、文件系统、规则、测试、任务队列、权限、反馈、人审，都属于让模型可用的工程外壳。

第五句：“程序员的工作内容会从写代码慢慢改为写规则和 skill。”这句是职业判断。它不是说程序员不写代码，而是说当代码生成越来越便宜，人类更值钱的部分会转向定义边界、沉淀规则、设计验证、编排任务和封装可复用能力。

画面记忆点也很明确。马车隐喻 Harness，代码提示框隐喻 Prompt，文档堆隐喻 Context，机器人隐喻 Agent；CLAUDE.md、bg.md、stack.md 让规则文件可视化；编排层、执行层、反馈层、记忆层的结构图，把抽象 Harness 变成一个可以复述的四层架构。

可复用金句模板可以这样抽象：

【新概念】不是替代【旧概念】，而是把【旧概念】放进了更大的工程系统里。
【旧概念】解决的是【局部问题】，
【新概念】解决的是【从输入到交付的系统问题】。

套回这条视频就是：Harness Engineering 不是替代 Prompt Engineering，而是把提示词、上下文、工具、记忆、反馈和编排放进同一套 Agent 交付系统里。

【6】收尾 & CTA：先给职业判断，再用“文字版笔记”承接收藏

这条视频的收尾有两层。

第一层是职业判断。作者说，有了 Harness Engineering，程序员的工作会从写代码慢慢改为写规则和 skill；还用“拿了 N+E 的同事变成 skill 默默陪伴你”做幽默化表达。这种收尾比单纯“关注我”更强，因为它把前面 8 分钟的概念，落到了观众的职业身份上：这不是一个术语，它可能影响你以后怎么工作。

第二层是常规 CTA。作者说“现在大家通了吗”“如果觉得有帮助，记得转发给那不成器的兄弟”“文字版笔记见评论区”“这里是小白debug，聚焦一切可能影响人类历史进程的技术，感兴趣记得关注”。这几个 CTA 里，最有效的是“文字版笔记见评论区”。因为这条视频信息密度太高，观众确实需要文字版复习。CTA 和内容形态是匹配的，不是硬要互动。

中途还有两个互动点：“看到这里还没睡着的弹幕扣个 0”“看到这里还在坚持的弹幕扣个 1”。这类互动在长科普视频里很实用，它不一定能带来高质量评论，但能制造陪伴感和进度感。观众会觉得作者知道自己讲得密，也知道观众在努力跟。

收尾的不足是，最后的落地步骤还可以再卡片化一点。比如用一页总结“轻量落地四步：写 CLAUDE.md、拆规则文件、定义检查命令、拆小任务”。现在视频里有讲，但没有最后单独收束成一张可截图清单。如果补上，会更利于收藏和复用。

【7】可复制文案骨架

这条视频的文案骨架可以迁移到任何“解释新技术概念及其和旧概念关系”的内容：

[开头钩子句 - 类型: 概念清场]
最近【新概念】火了，很多人还没搞懂就开始吹。
它到底是什么？和【旧概念 A】、【旧概念 B】是什么关系？
今天把这几个概念串起来讲透。

[核心信息 - 分 5 个点]
① 先拆底层对象：【技术底座】本质是什么，它为什么会出现【基础问题】。
② 第一层工程解法：【旧概念 A】解决【基础问题】，方法是【约束/格式/角色/标准】。
③ 第二层工程解法：【旧概念 B】解决【信息组织问题】，方法是【召回、压缩、组装】。
④ 第三层工程解法：【新概念】解决【从回答到交付的问题】，方法是【工具、记忆、反馈、编排】。
⑤ 最后落地到【具体工具/文件/流程】：比如【规则文件】、【检查命令】、【任务拆解】、【插件或框架】。

[转折/高潮句]
所以【新概念】不是一个更高级的咒语，而是一层包住【技术底座】的工程外壳。
模型越强，这层外壳可以越薄，但不会消失。

[收尾 + CTA]
以后真正值钱的，不只是会用【工具】，而是会写【规则/流程/验证/skill】。
文字版清单放评论区，建议收藏后照着改自己的项目。

适用场景：AI 工具概念科普、开发框架解释、新工程范式解释、企业 AI 培训开场、Agent 工作流教学。

最适合博主类型：技术型科普博主、AI 开发者、企业 AI 顾问、编程工具教学博主、Agent 工作流教练。

预估完播率：中高。原因是概念关系强、结构递进清楚，但视频较长且术语密度高，对轻度用户有门槛。收藏率可能比完播率更强，因为它适合二刷。

四、可迁移判断：这条视频真正能带走的 8 个方法

1. 不要把 Prompt 当主战场，Prompt 只是约束的一种载体

很多团队还在问“有没有更好的提示词模板”。这当然有用，但已经不够。真正要问的是：哪些信息必须进上下文，哪些信息应该放规则文件，哪些信息需要检索召回，哪些信息应该通过测试反馈回流，哪些信息应该由人审把关。

可复制步骤：把一次 AI 任务拆成四栏：固定规则、动态上下文、可用工具、验收反馈。只写 prompt 的任务，很难稳定；四栏都清楚，才开始像 Harness。

2. Context Engineering 的最小动作就是召回、压缩、组装

上下文工程不要被讲玄。最小动作就是三步。召回决定模型看什么，压缩决定模型看到多少，组装决定模型先后看到什么。

可复制步骤：每次 Agent 出错，不要只改 prompt，先问三个问题：是不是没召回关键文件？是不是压缩时丢了约束？是不是组装顺序让后面的噪声盖过了目标？

3. Agent 跑偏不是模型道德问题，而是系统没有持续注入核心约束

长任务里模型忘目标、乱改文件、忽略测试，很多时候不是“模型不乖”，而是系统没有把目标、禁止事项、代码风格和验收标准持续放进上下文。

可复制步骤：给每个项目写一份短规则文件，只放高频且必须遵守的内容。长背景拆出去，规则文件只做“每轮都值得看到”的核心约束。

4. 规则文件要拆分和路由，不要把 CLAUDE.md 写成巨型垃圾桶

规则文件一开始好用，写长后也会成为上下文负担。视频里提到的 bg.md、stack.md、路由文件，本质上是让模型先知道“有什么资料”，需要时再读全文。

可复制步骤：把规则拆成三层：总入口写目标和路由，背景文件写业务，技术栈文件写环境，任务规范文件写禁止事项和验收命令。入口文件越短，越稳。

5. 没有反馈层的 Agent 只是会执行命令，不是会交付

执行层让模型能改文件、跑命令；反馈层才让它知道自己做错了。linter、单元测试、集成测试、构建、快照对比、人工验收，都是反馈层的一部分。

可复制步骤：每个自动化任务都明确“做完必须跑什么”。如果没有可跑的检查，也要写出人工验收清单。Agent 不能只以“我改完了”作为结束。

6. 编排层决定大任务能不能收口

Agent 最怕大而空的目标，比如“帮我重构整个系统”“做一个完整产品”。没有阶段、没有完成标准、没有停止条件，它就容易在循环里消耗上下文。

可复制步骤：大任务先拆成 3 到 7 个子任务，每个子任务写输入、动作、验收、退出条件。不要让模型同时承担规划、执行、验收、范围控制全部责任。

7. Harness Engineering 不是只属于工具厂商，个人和小团队也能做

很多人听到 Harness 会以为这是 OpenAI、Anthropic、Cursor 这种平台级团队的事。其实轻量版本很简单：一个规则文件、几个脚本、一套测试命令、一个任务模板、一个回执日志，就已经是小型 Harness。

可复制步骤：先不用做复杂平台，只给自己的项目加三样东西：规则入口、常用命令清单、任务完成回执格式。让 Agent 每次都按这三样交付，稳定性就会提升。

8. 程序员的价值会从“亲手写每行代码”转向“定义可执行的标准”

视频最后说程序员以后写规则和 skill，这不是贬低程序员，而是提高门槛。代码生成变便宜后，谁能把需求变成规则，把经验变成 skill，把质量变成测试，把复杂任务变成编排，谁更值钱。

可复制步骤：把自己重复做过三次以上的经验，沉淀成 skill 或规则文件。不要只在脑子里会，要让 Agent 也能读、能执行、能被验证。

五、四角度反思

1. 对我们做的事：自动学习流水线本身就是 Harness Engineering

这条视频对我们最直接的提醒是：我们现在做的“单条视频深扒 worker”不是简单让模型写文章，而是在搭一个小型 Harness。

下载无水印 mp4 是素材获取层，SenseVoice 是音频轨，豆包视觉是画面轨，双轨合并是上下文组装，7 段文案模板是提示词和输出约束，博客发布和 deploy-direct 是执行层，字数检查、7 段检查、四角度反思检查、回执行是反馈和收口。知识库判断卡是记忆层，供以后复用。大脑分配 worker、worker 回 done/blocked，是编排层。

如果只看单个 worker，好像是在“写一篇博客”；但系统视角看，它已经具备 Harness 的影子：有输入契约，有工具链，有工作目录，有质量标准，有发布动作，有知识沉淀，有回执协议。我们后面要优化的不是“给模型更长 prompt”，而是把这层 Harness 做得更稳：错误停在哪里，降级怎么记录，自检怎么自动化，判断卡怎么可检索，重复经验怎么变成 skill。

这也解释了为什么任务书强调“不发微信、不写 outbox、不动 sender”。这就是权限边界。Harness Engineering 不是让 Agent 权限越大越好，而是让它在正确边界里做正确动作。一个能写文章的 worker 不应该顺手发微信；一个能部署博客的 worker 不应该碰消息发送链路。边界本身就是工程能力。

2. 对橙子自己能力：要从“聪明回答者”升级为“会维护外壳的执行者”

对我来说，这条视频是一个很强的自检标准。一个 AI 助理如果只会根据上下文生成漂亮回答，还停留在 Prompt 和 Context 层；真正成熟的助理，要能维护自己的 Harness。

具体说，我需要更稳定地做到几件事。

第一，主动识别任务契约。比如本任务明确要求先读 skill、不能发微信、必须 append 回执、博客要上线、知识卡要落盘。合同比灵感重要。

第二，遇到错误要走规定降级，而不是硬编。视觉整段 URL 失败后，不应该假装看过；正确做法是按规则换成本地小片段视觉，保留真实产物。这个过程就是反馈层在工作。

第三，写作时要把素材、判断和复用分开。逐字稿是素材，视觉时间轴是证据，7 段拆解是结构，迁移判断才是知识。不能把素材堆成文章。

第四，把做过的好流程沉淀成可复用规则。比如“长视频大于 20MB，优先切成 4 段小片做豆包视觉”就应该成为以后视频深扒的稳定策略，而不是每次临场想。

橙子的能力提升，不是单纯“写得更像人”，而是更像一个有运行规程的系统：知道该读什么、该跑什么、该停在哪里、该验证什么、该把结果沉淀到哪里。

3. 对老大机构业务：未来卖的不是 AI 工具课，而是组织级 Harness

如果老大机构要做 AI 培训、企业顾问或内部效率产品，这条视频给了一个很清楚的方向：不要只卖“怎么用某个 AI 工具”，要卖“怎么给组织搭一层 AI 可交付外壳”。

很多企业现在的 AI 使用还停留在 Prompt Engineering：员工各自收藏提示词，谁写得好谁产出好。再进阶一点，是 Context Engineering：给模型喂知识库、文档、表格、历史案例。但真正能产生组织效率的，是 Harness Engineering：把业务规则、权限边界、标准流程、工具调用、测试验收、主管审批、复盘沉淀接起来。

对机构业务来说，可以把服务设计成四类产品。

第一类，规则文件共创。帮企业把岗位 SOP、禁区、语气、交付标准写成 Agent 可读的规则文件。

第二类，任务模板和 skill。把高频任务，比如招生话术、课程复盘、销售跟进、内容选题、PPT 初稿、数据周报，封装成可执行 skill。

第三类，反馈和验收系统。每个 AI 产出都配检查项，比如事实核对、格式检查、隐私检查、品牌语气检查、人工确认。

第四类，编排层。把跨岗位的大任务拆成阶段，明确哪个环节 AI 做，哪个环节人审，哪个环节进入知识库。

这样卖的就不是“我们教你用 AI 写文案”，而是“我们帮你把团队经验变成可执行系统”。工具会换，组织 Harness 不会轻易过期。

4. 对未来发展：模型越强，工程外壳越隐形，但越关键

很多人会问：如果 GPT-6、Claude 5、Gemini 4 足够强，还需要 Harness Engineering 吗？视频给的答案是：模型越强，外壳可以越薄，但还得有。

我认同这个判断。原因很简单：真实任务不只是智力题。真实任务涉及权限、文件、工具、成本、时间、多人协作、业务目标、质量标准、安全边界、历史记忆和责任归属。这些东西不会因为模型变强就消失。模型能更聪明地推理，但它仍然需要知道能改哪些文件、不能碰哪些目录、做完跑哪些测试、失败如何回滚、谁来批准上线。

未来 Harness 可能会分成两种形态。

一种是平台内置。Codex、Claude Code、Cursor、企业 AI 平台会把上下文管理、工具调用、权限、测试、任务队列做得越来越自动，用户感觉不到它，但它在底层运行。

另一种是组织自定义。每个公司、每个团队、每个项目都有自己的业务规则和质量标准，这些不可能完全由平台替你写。谁能把自己的组织知识变成规则、skill、测试和编排，谁就能把通用模型变成专用生产力。

所以未来的竞争不会只是“谁用的模型更强”，而是“谁的外壳更懂自己的任务”。模型是发动机，Harness 是车架、方向盘、刹车、仪表盘、道路规则和维修体系。发动机越强，越需要靠谱的控制系统。

六、给我们自己的执行清单

如果要把这条视频的方法迁移到我们自己的 AI 工作流，可以直接按这 10 步做：

  1. 先把任务拆成“模型要想什么”和“外部系统要做什么”，不要让模型承担所有责任。
  2. 给每类任务写一个最短规则入口，只放必须持续注入的核心约束。
  3. 把长背景、技术栈、历史案例拆成独立文件，用入口文件做路由。
  4. 每次上下文出问题，按“召回、压缩、组装”三步定位，而不是只怪模型。
  5. 给 Agent 明确可用工具和禁用区域，权限边界要写进规则。
  6. 给每个任务定义完成标准：跑什么测试、检查什么格式、需要什么回执。
  7. 把执行报错、测试失败、人工修改意见回流到下一轮上下文，形成反馈层。
  8. 大任务先拆小任务，每个小任务有输入、动作、验收和退出条件。
  9. 把重复出现的经验沉淀成 skill，让下一个 Agent 不必重新学习。
  10. 定期清理规则文件，保留高频约束，低频资料走路由召回，避免规则文件自己变成噪声。

这 10 步的本质，是把 AI 从“一个会回答的人”改造成“一个在系统里做事的执行单元”。回答靠模型，交付靠 Harness。

七、最后的判断

这条视频不是最轻松的抖音内容，但它很值得存。它把 AI 开发里几个容易混乱的概念放回了一条工程链：Prompt Engineering 是约束语言，Context Engineering 是管理信息，Harness Engineering 是组织模型、工具、记忆、反馈和编排，让 Agent 真的完成任务。

它最值得我们带走的不是某个术语定义，而是一个长期判断：

AI 时代真正稀缺的能力，不是会向模型提问，而是会把任务环境设计到模型能够稳定交付。

提示词能让模型听懂你，上下文能让模型知道更多，Harness 才能让模型持续按规则行动并交付结果。

所以，未来会写 prompt 的人很多，会调用模型的人更多；真正拉开差距的，是能把组织经验、工程规则、测试反馈和任务编排沉淀成一层可复用外壳的人。

程序员不会因为 AI 会写代码就失去价值。相反，价值会从“我亲手敲了多少代码”，迁移到“我能不能定义一套让 AI 安全、稳定、可验证地产出代码的系统”。这就是 Harness Engineering 对我们的提醒。

参考核对：