前几天用 Claude Code 写个最简单的加减函数 demo，给我整破防了。就这么个没技术含量的需求，第一次它给我引入了个第三方计算库，说专业浮点运算更精准；第二次给我拆了
add.js、subtract.js、index.js三个文件，说符合模块化最佳实践；第三次更离谱，直接给我上了单元测试框架，说保证代码质量。我每次都明确说了 "原生 JS，单文件，越简单越好"，结果每次输出都不一样。我当时就懵了，是我 prompt 写得不够清楚？还是我表达能力有问题？
直到我随手在项目里加了个 CLAUDE.md 文件，再让它写，突然就稳了。输出的代码和我预期的几乎一模一样，连注释风格都对上了。我就好奇，这不就是把 prompt 写文件里了吗，怎么效果差这么多？顺着这个问题挖下去，我才接触到一个最近在 AI 圈越聊越多的概念 ------Harness Engineering。
以前我以为，写好 prompt 就够了
说实话，在这之前我对 AI 工程化的认知，还停留在 Prompt Engineering 的阶段。不就是把话说清楚吗？给角色，给场景，给输出格式，再加个思维链，齐活。后来又听说了 Context Engineering，说要多给上下文信息，效果更好。我一直觉得，AI 输出不好，本质就是 prompt 写得烂，多加点描述就完事了。这次这个 10 行代码的小 demo，结结实实给我打了脸。同样的需求，我在聊天框里重复三遍，不如放个文件在项目里管用。为什么？因为聊天框里的话，它转头就忘。这不是它不用心，是大模型天生的毛病，靠写 prompt 根本补不上。
大模型这四个天生的缺陷，靠 prompt 补不上
我翻了些资料，又结合自己平时用的感受，总结下来大模型有四个骨子里的问题，是天生的结构缺陷，你 prompt 写得再花也没用。
第一个是无状态。说直白点就是鱼的记忆，每一轮对话对它来说都是全新的开始。你上一轮说过 "不要第三方库"，这一轮它可能就忘了。你跟它聊十轮开发，它根本记不住你们之前定好的命名规范、目录结构。我之前就犯过这个错，写小项目的时候，第一轮跟它约好代码风格，写着写着它就跑偏了，我还得反复提醒，到最后我自己都记不住说过多少遍。
第二个是没法主动操作外部世界。它只能输出文字、图片这些内容，你不让它读文件，它就不知道你项目里有啥；你不给它工具，它连个终端命令都跑不了。真要做复杂项目，光靠聊天框甩代码肯定不够，得有一整套工具链接上去。
第三个是输出是概率性的。同样的输入，两次输出大概率不一样。写文案写文章无所谓，文无第一嘛，有点差异反而有惊喜。但写代码不行，代码是 "武无第二" 的事，今天这么写明天那么写，项目规范直接乱套。
第四个是上下文再长也有限。现在号称 1M token 的模型不少，但真把整个项目代码全塞进去，不仅慢，关键信息还容易被稀释，它抓不住重点。我之前还不信邪，觉得上下文够长就无敌了，直到我把整个项目代码粘进去，它给我返回了个驴唇不对马嘴的东西。
原来我们需要的，是给模型套上 "挽具"
那天看到一个比喻，一下子给我点通了。大模型就像一匹力气很大的野马，跑得快，耐力强，潜力无限。但你不能直接骑上去就赶路，它会乱跑，会跑偏，累了还会偷懒。你得给它套上一整套挽具 ------ 马鞍、缰绳、笼头、马蹄铁。有了这套东西，你才能驾驭它，让它按你的路线走，稳定地把活干了。这套挽具，就是 Harness。
Harness Engineering，说白了就是研究怎么给大模型搭这套外围系统的学问。它不是某个具体的框架，也不是某个 API，而是围绕模型的一堆工程化手段的总称。还有个更贴切的类比：模型是汽车的发动机，V8 很猛，但光有发动机你开不走。你得有变速箱、方向盘、刹车、仪表盘，整辆车才能上路。Harness 就是除了发动机之外的整车系统。
以前我们折腾 Prompt Engineering，相当于研究怎么跟司机说话，让他好好开车；现在的 Harness Engineering，是直接给车装方向盘和刹车，从系统层面保证车能开好。从 Prompt 到 Context，再到现在的 Harness，其实就是我们对 AI 的要求变了：从 "能回答问题"，变成了 "能稳定干活"。
记忆层，是 Harness 的第一道关卡
Harness 里面包含很多层，工具层、流程层、记忆层等等，我最先摸到、也最有体感的，就是记忆层。既然模型天生记不住东西，那我们就帮它记。把那些不变的、核心的规则，提前结构化存好，每次调用模型的时候自动带上，这不就解决了无状态的问题？
就像我那个小 demo 里的CLAUDE.md，就是最朴素的记忆层实现。我把项目的技术栈、目录结构、代码规范全写在里面，相当于给了它一张项目的 "导航地图"。每次它处理我的需求之前，先读一遍这个文件，就不用我每次重复啰嗦了。
给你们看看我最后写的这个文件，就这么几行：
markdown
# CLAUDE.md
This file provides guidance to Claude Code when working with code in this repository.
## 技术栈
- **语言**: Node.js 原生 JavaScript，仅使用内置模块，不引入第三方 npm 包
## 项目结构
add-demo/
index.js # 入口文件，所有代码写在该文件，不拆分文件
CLAUDE.md # 项目规则
## 开发命令
- **运行项目/测试**: `node index.js`
- 无测试框架 --- 函数通过 `index.js` 底部的 `console.log` 调用示例进行内联测试
## 代码规范
1. 每个函数必须加单行注释
2. 代码极简，拒绝冗余
3. 输出结果用 `console.log` 清晰打印
4. 必须提供调用示例
5. 代码全面使用 es6+就这么短短一段，比我写一大段 prompt 管用多了。加上这个文件之后，我只说了一句 "实现加法和减法函数，加几个测试用例"，它输出的代码完全符合预期：
javascript
// 加法函数：返回两数之和
const add = (a, b) => a + b;
// 减法函数：返回两数之差
const subtract = (a, b) => a - b;
// ===== 调用测试 =====
console.log(`add(1, 2) => ${add(1, 2)}`); // 3
console.log(`add(-1, 5) => ${add(-1, 5)}`); // 4
console.log(`add(0, 0) => ${add(0, 0)}`); // 0
console.log(`add(3.14, 2.86) => ${add(3.14, 2.86)}`); // 别问我为什么单独测这个，浮点精度坑懂的都懂
console.log('---');
console.log(`subtract(5, 3) => ${subtract(5, 3)}`); // 2
console.log(`subtract(1, 5) => ${subtract(1, 5)}`); // -4
console.log(`subtract(0, 0) => ${subtract(0, 0)}`); // 0跑一下node index.js，输出整整齐齐，连浮点精度的边界情况它都主动考虑到了。全程我没提过 "不要第三方库"、"不要拆文件"，它自己就遵守了所有规范。
我踩过的坑：别把记忆文件写成需求文档
说实话，我一开始写CLAUDE.md的时候，走了挺大的弯路。我把具体的业务需求全写进去了，比如 "实现加法和减法两个函数"、"要打印四个测试用例"、"结果用模板字符串输出"。写了满满一大段，结果效果并不好，反而有时候会限制它的思路，遇到新需求还得改这个文件。
后来才明白，记忆层存的应该是不变的约束，不是具体的任务。技术栈不会变，项目结构不会变，代码规范不会变，这些东西放进去。至于今天要写加法还是乘法，要加几个测试用例，这是临时需求，放在 prompt 里说就行。
踩坑提醒别把 CLAUDE.md 写成需求文档。它是项目的 "基本法"，不是 "今日待办"。写得越杂，核心约束越容易被稀释，效果反而越差。
就像你给马套挽具，你是给它装个缰绳管方向，不是把它要走的每一步都刻在缰绳上。缰绳是管大方向的，具体走哪条路，你上路的时候再说。
还有个认知上的坑，一开始我以为这东西就是 "把 prompt 写文件里"，属于 Prompt Engineering 的换皮。现在回头看，完全不是一个量级的东西。Prompt 是单次的、对话式的；记忆是持久的、结构化的。这背后是协作模式的变化：以前是 "我问一句你答一句" 的临时工模式，现在是 "我们在同一个项目规则下一起干活" 的同事模式。
再往深想一层，Harness 远不止记忆
当然，记忆只是 Harness 的冰山一角。光让模型记住规则还不够，它还得能动手干活。比如读文件、写文件、跑命令、调接口、操作浏览器，这些操作模型自己做不了，得有工具层接上去，这也是 Harness 的核心部分。还有流程控制，比如复杂任务要拆成几步，先检索再思考再执行，出错了怎么重试，结果怎么校验，这些也得靠外面的系统管着，不能全靠模型自己发挥。
之前大家聊得很多的 RAG，其实也可以算 Harness 里的一个组件 ------ 解决模型知识不够的问题。但 Harness 比 RAG 大得多，它管的是整个协作系统，不只是给模型塞资料。
为什么最近这个概念突然火了？因为大家慢慢发现，模型能力已经够强了，缺的是用好它的工程方法。25 年下半年开始，Claude Code 接棒 Cursor 成了 AI 编码的新宠，还有各种办公自动化的 Agent 冒出来，本质上拼的都不是模型本身，是谁的 Harness 做得好，谁能让模型稳定地输出可用的结果。腾讯搞的 CodeBuddy、WorkBuddy，还有微信生态里的各种办公 AI，说白了都是在给大模型做定制化的挽具，适配不同的工作场景。
最后说几句掏心窝的
这段时间琢磨下来，我最大的感受是，我们正在跨过 "玩 AI" 的阶段，进入 "用 AI 干活" 的阶段。以前大家比谁的 prompt 写得花，谁的模型参数大；现在比的是谁能让 AI 稳定地把活干了，少出 bug，少返工。
有三个点我印象特别深。
第一，别死磕 prompt 了。很多时候输出不稳定，不是你表达能力差，是缺了记忆层这道保险。长期协作的项目，先把项目的 "基本法" 写好，比优化十遍 prompt 管用。
第二，大模型的缺陷是天生的，接受它，然后用工程手段补。别指望模型自己进化出完美记忆、进化出执行力，那不现实。工程师要做的，就是在现有模型的基础上，搭出好用的系统。
第三，Harness 不是银弹。要是就问个单次的问题，查个资料，完全没必要搞这么复杂。只有当你需要和 AI 长期、重复、稳定地协作，比如做项目开发、做日常办公自动化的时候，这套东西才体现价值。
说白了，Harness Engineering 的本质，不是让模型更聪明，是让模型更 "听话"、更 "靠谱"。
你们平时用 AI 写代码的时候，有没有遇到过这种 "说了八百遍就是记不住" 的情况？有没有自己的小技巧让 AI 输出更稳定？评论区聊聊，我也想取取经。