你不是不会用 AI，你只是只做了第一层：Prompt / Context / Harness / Loop

这篇写给完全不写代码的人。 全文没有一行代码，全靠比喻和图。读完约 35 分钟。

你会拿到一张地图：知道这四个词分别管什么、彼此什么关系、以及当 AI 表现不好时，该修哪一层。

零、先给你一句话版本

如果你只想记一句话，记这个：

Prompt 管”你这次怎么说”，Context 管”它这一刻能看见什么”，Harness 管”它有什么手脚和规矩”，Loop 管”它能自己跑多久”。

再配一个比喻，这个比喻会贯穿全文：

你雇了一个很聪明但完全没记性、也没进过公司的实习生。

• 给他写一张清楚的任务便条 —— 这是 Prompt
• 给他准备好该看的资料，把不相干的收走 —— 这是 Context
• 给他配电脑、门禁卡、可以用的软件，再给他一张检查清单 —— 这是 Harness
• 让他独立跟完一整个项目，做完自己验收，卡住了才来找你 —— 这是 Loop

四件事的方向是一致的：你说的话越来越少，你搭的系统越来越多。

一个诚实的说明：这四个词的”成熟度”不一样。Prompt Engineering 是公认术语；Context Engineering 从 2025 年开始被广泛使用；Harness Engineering 和 Loop Engineering 目前还是行业里正在成形的说法，不同公司、不同人的定义会有出入。本文用的是目前最主流的一种切法，你在别处看到略有不同的定义，不用慌。

一、先看穿底层：模型其实只做一件事

这一节有点”底层原理”，但只要三分钟，而且不看这一节，后面四层你会永远只记住名词、记不住道理。

1.1 它没有记忆，没有手脚，也没有眼睛

你跟 ChatGPT 聊天时的直觉是：它”记得”我们刚才聊了什么。

这个直觉是错的。

真实情况是：每一次你按回车，系统都会把一整段文字打包送给模型，模型看完这一整段，吐出接下来的字。这一整段里包含了你们之前所有的对话——所以它”看起来”有记忆，其实是每次都把病历从头念了一遍。

模型本身，是一个非常纯粹的东西：

• 输入：一大段文字
• 输出：接着往下写的一小段文字

没了。它不会主动去查资料，不会打开你的文件，不会记住昨天的事。

1.2 于是所有工程都在做同一件事

既然模型只能看见”送进去的那一整段文字”，那么所有让 AI 变好用的努力，本质上都是在决定那段文字里放什么。

• 你把话说得更清楚 → 那段文字里多了明确的目标 → Prompt 工程
• 你把该看的资料塞进去、把噪音删掉 → 那段文字的信噪比变高 → Context 工程
• 你在那段文字里告诉它”你可以用这些工具”，并且真的接上了工具 → Harness 工程
• 它用完工具，结果又变成新的文字送回去，反复几十轮 → Loop 工程

四层不是四个流派，是同一件事在四个尺度上的展开。

🎯 这一节的关键：模型是”看一段文字、写一段文字”的函数。四种工程，都是在管这段文字。

二、四层是怎么一层层长出来的

不理解历史，你会觉得这四个词是有人硬造的。理解了历史，你会发现每一层都是被上一代的痛点逼出来的。

2.1 2020 年：模型只会”接话”

GPT-3 那个年代，模型是”补全器”：你写半句，它续下半句。你想让它做事，得把话摆成让它顺着写下去就能出结果的样子。

那时候大家发现：同样一个任务，换个说法，效果天差地别。加一句”让我们一步一步想”，正确率能明显上升。

痛点：怎么说，决定了能不能用。 长出来的东西：Prompt Engineering。

2.2 2022 年底：能对话了，但记性有边界

ChatGPT 出来，交互从”补全”变成”对话”。好处是自然，坏处是——聊长了它就开始忘。

因为那”一整段文字”是有长度上限的。聊到一定长度，前面的内容要么被截掉，要么被压成摘要。

痛点：能塞进去的东西有限，而且很快就不够用。

2.3 2023 年：它能查资料、能调工具了

这一年发生了三件互相咬合的事：

1. 工具调用：模型可以输出一条”我要调用某个功能”的指令，外部程序执行完把结果送回去。
2. RAG（检索增强）：先去知识库里搜出相关片段，再连同问题一起送给模型。
3. 长上下文：能塞进去的文字从几千字涨到十万字量级。

三件事叠在一起，结果是：能往里塞的东西暴增，但塞什么、塞多少、按什么顺序塞，变成了一门手艺。

痛点：不是塞不下，是塞太多、塞太杂，模型反而变笨。 长出来的东西：Context Engineering。

2.4 2025 年：它能真的动手了

Claude Code、Codex 这类编码 Agent 普及。它们和聊天 AI 的根本区别是：它能直接读写你电脑上的文件、执行命令、看到报错，然后自己再改一轮。

（这一段如果你还没概念，可以先看这篇：从零开始用 Codex 和 Claude Code：一篇写给完全不懂代码的人的上手指南）

一旦 AI 能动手，新问题立刻冒出来：

• 它能用哪些工具？工具怎么描述给它听？
• 哪些操作它可以自己干，哪些必须先问你？（万一它 rm -rf 了呢）
• 它做完了，谁来检查做得对不对？
• 项目里那些”每次都要重说一遍”的规矩，能不能写死？

这些问题跟”怎么说话”没关系，跟”上下文放什么”也只沾一半边。它们属于模型之外的整套装备。

痛点：模型再聪明，没工具没权限没验收，也干不成活。 长出来的东西：Harness Engineering。

2.5 2025–2026：一个任务跑几十轮，一次开一堆分身

再往后，形态又变了：一个任务不再是”你问一句它答一句”，而是它自己跑几十轮——读代码、改、跑测试、看到失败、再改、再跑，直到通过；或者一次开十几个分身，各查一块，最后汇总。

于是又冒出新问题：

• 它该跑几轮？什么时候算做完了？
• 卡住了怎么办？是硬撑还是回来问人？
• 开了十个分身，谁来合并结果、谁来拍板？
• 一直跑下去，token 和钱怎么控制？

痛点：不是”能不能跑”，是”什么时候该停、谁来判断”。 长出来的东西：Loop Engineering。

🛠️ 规律：每一次模型能力上台阶，都会把瓶颈往外推一层。四种工程是四个先后长出来的层，不是四种互斥的方法。

三、Prompt Engineering：把一次要求说清楚

3.1 它到底是什么

Prompt = 你这一次说给 AI 的话。 Prompt Engineering = 有意识地设计这句话的结构，而不是想到哪说到哪。

很多人对它有个误解，觉得是”背咒语”——比如加一句”你是世界顶级专家”就能变强。这在早期模型上确实有点用，在今天的模型上收益已经很小了。

今天真正有效的 Prompt 工程，朴素得多：把信息补全。

3.2 一条好指令的四个零件

对比一下：

❌ 差的

帮我写个网站

✅ 好的

你是前端工程师。做一个个人博客首页，只用 HTML 和 CSS、不要用任何框架。页面要有头像、一段自我介绍、一个文章列表三块。做完给我一个双击就能在浏览器打开的文件。

第二条并不”高级”，它只是把本来就在你脑子里的信息写出来了。

3.3 四个最常见的翻车点

① 目标不可验收 说”优化一下”，AI 不知道优化到什么程度算完。 改成：“首页现在打开要 3 秒，我想压到 1 秒以内。先告诉我瓶颈在哪，我确认后再动手。”

② 一次塞太多 “顺便把登录、支付、后台都做了”——结果是每件事都做到七分。 改成：一次只做一件，做完你验收，再说下一件。

③ 只说做什么，不说不做什么 AI 默认”没禁止就是允许”。 改成：“写个脚本；不要动 data 目录，不要装新的依赖。”

④ 没有验收动作 “做好点”等于让它自己评价自己。 改成：“做完跑一遍测试，把结果贴给我看。“

3.4 一个立刻能用的模板

下次提需求前，在心里过一遍这五句话：

1. 我希望它站在谁的角度？
2. 这次只做哪一件事？
3. 有哪些红线（不能碰的文件、不能装的东西、不能改的风格）？
4. 做成什么样算完成？
5. 完成后它要给我看什么来证明？

答不上第 4 和第 5 条，说明你自己还没想清楚——这时候更该做的是让 AI 先陪你把需求聊清楚，而不是让它直接动手。

⚠️ Prompt 工程的天花板很明显：它只能管”这一句话”。当任务需要跨很多轮、需要它看很多资料时，光靠说话是不够的。这时候你需要下一层。

四、Context Engineering：决定它这一刻能看见什么

4.1 桌子比喻

想象模型面前有一张大小固定的桌子。它做任何判断，只能依据桌上摆着的东西。

这张桌子的容量，就是上下文窗口。现在主流模型大概能摆下 20 万 token 左右的东西——粗略换算，大约是一本长篇小说的量。

听起来很大？看看桌上都摆了什么：

• 系统提示（工具厂商写死的开场白）
• 你的项目规则
• 到目前为止的全部对话历史（只增不减）
• 刚读进来的文件内容、命令输出、网页正文 ← 这一块是撑爆桌子的头号元凶
• 还得给它留一块地方思考和写答案

一次读三个大文件、跑一个输出几百行的命令，桌子就去掉一大半了。

4.2 桌子满了会发生什么

两件事，都很难受：

① 它开始”忘事”。 系统会自动把早期对话压成摘要，或者干脆丢掉。表现出来就是：你十分钟前明确说过的要求，它又犯了一遍。

② 它开始”拿错东西”。 这个更隐蔽。桌上堆了 50 个文件，其中 3 个是真正相关的，模型很可能盯着一个无关的文件做判断。

记住这一句：模型变笨，八成不是模型的问题，是桌子太乱。

4.3 一轮对话里，桌上到底被摆了什么

这张图值得你多看两眼，它解释了 90% 的”AI 怎么突然不听话了”：

关键认知：你打的那句话，只占桌子的最后一小块。

你能直接控制的只有两层：项目规则文件、和你刚打的这句话。 但决定成败的，往往是另外两层：越滚越长的历史对话、和工具吐回来的原始输出。

4.4 上下文工程的四个动作

所以”管好桌子”具体怎么做？只有四个动作：

① 写下来（Write）——把重复的话变成文件

你每次都要说”这个项目用中文回复、不要自动提交代码、图片放在 assets 目录”，那就别每次说了，写进项目根目录的规则文件（在 Claude Code 里叫 CLAUDE.md）。

它长这样，就是一个普通的记事本文件：

# 项目规则
- 用中文回复
- 不要自动提交代码，改完让我自己看
- 图片统一放 assets/ 目录
- 改完必须跑一遍 npm test

写一次，之后每轮自动上桌。这是投入产出比最高的一个动作，十分钟就能做完。

② 挑着上（Select）——只端必要的资料

不要一上来就说”你把整个项目读一遍”。正确姿势是让它先搜索定位，再精读：先找出相关的 3 个文件，再读那 3 个。

对你来说，落地成一句话就是：给它足够的线索去找，而不是把所有东西倒给它。

③ 压缩（Compress）——长东西先提炼再看

几百行的日志、几十页的文档，不要整个丢进对话。先让它提炼成结论，再基于结论讨论。

在长对话里，这体现为：聊到某个阶段就开新对话，把上一轮的结论手动带过去。比让系统自动压缩可靠得多。

④ 隔离（Isolate）——脏活交给分身

需要翻 50 个文件才能回答的问题，让一个”子 agent”去翻，它翻完只把结论带回来。50 个文件的原始内容从来没上过主桌。

这个动作已经一只脚踩进 Harness 和 Loop 层了——这就是四层互相咬合的地方。

4.5 三条马上能用的习惯

1. 新任务开新对话。 上一个任务的残留是纯噪音。
2. 项目规矩写进规则文件，别每次口述。
3. 发现它开始答非所问、重复犯已说过的错——不要继续纠正，直接开新对话，把关键信息重新给一遍。 在一张已经乱掉的桌子上继续解释，是最费时间的做法。

🎯 Context 工程的目标：不是”装更多”，而是”在它做判断的那一刻，眼前正好是需要的东西——不多，也不少”。

五、Harness Engineering：给它手脚、规矩和验收

5.1 Harness 是什么意思

Harness 这个词，原意是”马具、挽具”——套在马身上，让马的力气能真正用来拉车的那一整套装备。

在 AI 语境里，它指的是：模型之外的所有东西。

模型是引擎。引擎再强，没有轮子、方向盘、刹车、油箱、仪表盘，它就只是一个在原地轰鸣的铁疙瘩。

Harness Engineering = 造这辆车。

这是四层里对”最终效果”影响最被低估的一层。一个直觉上反常识、但从业者普遍认同的观察是：

同一个模型，装在好 harness 里和装在裸 API 里，能力差距大到像两个模型。

反过来说：与其纠结”换更贵的模型能不能好一点”，不如先看看你的车装好了没有。

5.2 Harness 包含哪六样东西

① 工具（Tools） 它能读文件、写文件、执行命令、上网搜索、看图片吗？没有工具的模型只能”说”，不能”做”。

② 权限与沙箱（Permissions） 哪些操作它可以自己干，哪些必须先问你。这是安全阀，也是效率阀——卡得太松会出事，卡得太紧你就要一直点”同意”。

③ 记忆与规则（Memory & Rules） 规则文件、可复用的”技能”、自定义命令。本质是把上下文工程的成果固化下来。

④ 自动验证（Verification） 这是最关键、也最容易被忽略的一样。

让它改完自己跑测试、跑编译。跑不过的报错会自动回到它眼前，它会自己再改一轮。 这一条直接决定了它能不能”自己发现自己错了”——没有验证，它永远只能靠你当人肉测试员。

⑤ 钩子（Hooks） 在固定时刻自动触发的动作。比如”每次它改完文件，自动跑一遍格式化”。跟”叮嘱它记得做”的区别是：钩子是系统强制执行的，不依赖它记性好。

⑥ 外部连接（MCP 等） 把它接到数据库、设计稿、浏览器、日历这些外部世界上。这一样最强大，也最容易过度投入——别一开始就搞这个。

5.3 从易到难，你实际能装的六样

如果你只有半小时，按这个顺序：

1. 写规则文件（难度 ★）：把每次都要重说的话写进去。10 分钟，立刻见效。
2. 配权限白名单（难度 ★）：把明显安全的操作设为免确认，你不用再一步一点头。
3. 自定义命令 / 技能（★★）：把重复流程封装成一句话触发。
4. 自动验证（★★）：让它改完自己跑测试。
5. 钩子（★★★）：等你被同一个问题烦到第三次再上。
6. 外部工具连接（★★★）：等你确实有非接不可的系统再说。

⚠️ 最常见的错误顺序：一上来研究第 5、6 项，规则文件却还是空的。这就像还没装轮子就先研究涡轮增压。

5.4 一句话检验你的 harness 好不好

问自己一个问题：

“它做完之后，是谁在检查做得对不对？”

如果答案是”我”，那你的 harness 还很初级。 如果答案是”它自己跑测试，跑不过它自己改，改好了才来找我”，那你已经跨过了最重要的那道坎——并且你已经在做 Loop 工程了。

六、Loop Engineering：让它自己跑完，而不是一直催

6.1 先说清楚：这个词有两种用法

这是四个词里定义最松的一个。目前主要有两层含义，都属于 Loop 工程，只是尺度不同：

• 单个 agent 的自循环：一个任务，它自己跑几十轮直到做完。
• 多个 agent 的编排：一个任务，拆给一队分身并行做，再汇总。

下面两节分别讲。

6.2 之一：单个 agent 的自循环

循环长这样：读懂任务 → 定计划 → 动手做一步 → 自己验证 → 不合格就改 → 回到”做一步”。

这个循环之所以能转起来，前提是上一层给它的：有工具能动手，有验证能知道对错。没有 Harness，这个循环转不动。

而 Loop 工程真正要设计的，不是怎么让它跑，是怎么让它停。

6.3 三种”停”，缺一不可

① ✅ 达标停 —— 说清楚什么叫做完了

这是最重要的一条。你必须给出一个它自己能判断的标准：

• ❌ “写得好一点” —— 它没法判断
• ✅ “所有测试通过，并且首页在 1 秒内打开” —— 它能判断

② ⏱ 预算停 —— 给上限

“最多试 5 轮，还不行就停下来告诉我卡在哪。”

不给上限的循环，最坏情况是它在一个死胡同里反复试到你的额度烧完。

③ 🚧 卡死停 —— 允许它求助

明确告诉它：“如果连续两轮都没有实质进展，不要继续试，停下来把你的判断和卡点告诉我。”

不加这一条，模型的默认行为倾向于硬撑——它会不断尝试新花样，越试越偏，最后交给你一堆改坏的东西。

6.4 之二：一个变很多个

当任务大到一个 agent 的桌子装不下，就拆给多个分身。三种常见编排：

扇出（Fan-out）：同一件事切成互不重叠的几块，几个分身各查一块，最后汇总。 适合：审查整个项目、大范围调研。

流水线（Pipeline）：每件事都走同样几道工序——找问题 → 验证问题是不是真的 → 修问题。每道工序一个分身。 适合：需要”先找后验”的场景，能过滤掉大量看起来对、其实不对的结论。

评审团（Judge）：几个分身各出一版方案，再让另一个打分选最优，取胜者、顺手把其他版本的好点子并进来。 适合：方案空间大、一次做不对的设计类任务。

一个关键认知：多开分身的真正好处不是更快，而是互不污染。每个分身都在一张干净的桌子上干活，翻了 50 个文件的那些原始内容，永远不会跑到主桌上来。

一个关键限制：分身之间互相看不见对方的上下文。需要共享的信息，必须由主 agent 明确传下去。这是新手最容易踩的坑——以为它们”心有灵犀”。

6.5 你作为普通用户，怎么做 Loop 工程

不用写任何调度代码，你能做的其实是三件事：

1. 每次提任务时，附上验收标准（第 4 个零件，还记得吗）。
2. 明确给出轮数上限和求助条件：一句”最多试 3 轮，不行就回来告诉我卡在哪”就够了。
3. 大任务先让它拆：让它先给你一个分几步的计划，你确认后再让它一步步跑完。

🎯 Loop 工程的本质：不是让它跑得更久，而是把”什么时候该停、停下来做什么”提前定义清楚。没有停止条件的循环，只会稳定地烧钱。

七、速查：出问题时，先判断该修哪一层

四层讲完了。实战中最有用的能力，是看到症状能定位到层。

症状：答非所问、方向完全跑偏 → Prompt 层。四个零件缺了哪个？一次是不是塞了太多件事？

症状：忘了刚说过的话、用了过时的信息、反复犯同一个错 → Context 层。桌子乱了。开新对话，把关键信息重新给一遍；把反复要说的话写进规则文件。

症状：它说”你可以这样做”却不动手 / 每一步都要你点确认 / 做完了没人检查对错 → Harness 层。工具、权限、自动验证，缺了哪个补哪个。

症状：做一半就停下来等你 / 需要你一直催 / 大任务撑不到头 → Loop 层。验收标准和停止条件没给。

一条通用建议：先定位层，再动手。跨着层瞎改——比如上下文乱了却在拼命打磨措辞——是最费时间的一种忙碌。

八、给你的落地路线

按投入产出比排序，不要跳。

第一天（30 分钟）

• 在你常用的项目文件夹里，建一个规则文件，把”每次都要重复说的话”写进去。
• 下次提需求时，强迫自己写全四个零件：角色、任务、约束、验收。

第一周

• 养成”新任务开新对话”的习惯。
• 每次任务附一句验收标准：“做完跑一遍 xxx，把结果给我看。”
• 把明显安全的操作加进权限白名单，别再一步一点头。

第一个月

• 把你重复做了三次以上的流程，封装成一个自定义命令。
• 给项目配上自动验证（测试 / 编译），让它能自己发现自己错了。
• 试着给一个中等任务加上”最多 5 轮，卡住就回来问我”，观察它自己跑完的效果。

之后

• 钩子、外部工具连接、多 agent 编排——等你确实被同一个问题烦到第三次，再上。

九、几个常见误解，一次澄清

误解 1：Prompt 工程过时了。 没过时，是天花板变低了。今天单靠措辞能拿到的增量很小，但把四个零件写全，依然是所有工程的地基。

误解 2：上下文窗口越大越好，塞满就对了。 恰恰相反。窗口大是自由度，不是义务。桌上东西越多，它拿错的概率越高。大窗口的正确用法是”我有余量犯错”，不是”我要塞满”。

误解 3：只要换更强的模型，这些工程就不用做了。 模型变强会把每一层的门槛降低，但不会取消它们。而且能力越强的模型，你越需要用停止条件和验收标准来约束它——因为它能跑得更远，跑偏也偏得更远。

误解 4：这些都是程序员的事。 四层里，你作为非程序员能完整做掉 Prompt 和 Context 两层，Harness 的前两项（规则文件、权限白名单）也完全不需要写代码。这三件事已经覆盖了日常八成的痛点。

十、一页纸总结

最后再念一遍那句话：

Prompt 管”你这次怎么说”，Context 管”它这一刻能看见什么”，Harness 管”它有什么手脚和规矩”，Loop 管”它能自己跑多久”。

四层往下走，你说的话越来越少，你搭的系统越来越多——这就是从”用 AI”到”用好 AI”的全部路径。

延伸阅读

• 从零开始用 Codex 和 Claude Code：一篇写给完全不懂代码的人的上手指南 —— 还没上手 AI Agent 的，从这篇开始
• 一把钥匙、三种协议、两个配置文件：AI API 小白指南 —— 想搞懂 API、模型、中转站的关系
• orizuru个人建站/【小白教程】codex、claude等接入mcp的通用方式.md —— Harness 第 6 项的实操