所有人都以为AI越用越笨，其实是你没给它“记忆系统”

我被Claude Code气到砸键盘，才发现AI根本不需要“更聪明”

三个月前，我差点被Claude Code气到砸键盘。

2025年底，我让它帮我重构一个Python后端服务。第一次对话，它惊艳到让我头皮发麻——理解了我的架构意图，给出了合理的模块划分，甚至主动指出了代码里的潜在性能问题。

我心想：稳了！这波要起飞！

结果第二天继续工作，它完全忘了前一天的设计决策。命名风格换了，我明确禁止的第三方库它给引了进来，同一个函数里同步异步写法混在一起，像极了刚学编程的大学生写的“能跑就行”的代码。

我检查了对话上下文——才2万token。不是模型的问题，是我的问题。我没有给它任何“记忆系统”。

后来我测试了三个月，踩了无数坑，最后发现一个让我又沮丧又兴奋的事实：

Harness Engineering根本不是新东西，而是我们早就该做、但一直没做到位的事情。

你以为是AI变笨了？错！是你问错了问题

你得先接受一个残酷的现实：

LLM天然就是金鱼，7秒记忆都算多的。

你指望它在对话里记住所有东西，就像指望实习生光靠脑子记住整个项目的架构规范。可能吗？不可能。

但很多人还在那儿抱怨：“这AI怎么越用越笨了？”“昨天还能写对，今天怎么就乱写了？”

问题出在哪儿？

Harness Engineering解决的根本不是“怎么让AI更聪明”，而是“怎么让AI可控地持续工作”。

聪明是模型公司的事，可控才是咱们工程师的事。模型可以不断迭代、升级、变强，但如果你没有一套“缰绳”让它按照你的规矩干活，它再聪明也是野马——跑得越快，摔得越惨。

三个让我“真香”的实践，一个比一个反直觉

1. 最土的方法最有效：一个文本文件，治好了AI的失忆症

Anthropic的工程师在实践里提到一个做法：维护一个claude-progress.txt文件。当时我觉得这太low了——2026年了还用文本文件做状态管理？这不是开倒车吗？

但我试了之后，真香。

具体做法：在项目根目录放一个progress.json，Agent每次启动先读这个文件。格式大概是这样：

{
 "current_task": "重构用户认证模块",
 "completed_tasks": ["数据库连接池优化", "日志系统迁移"],
 "decisions": [
 {"id": "DEC-001", "content": "使用JWT而非Session", "date": "2026-02-10"}
 ],
 "blockers": ["等待第三方API文档更新"]
}

我测试了两周，效果立竿见影。Agent的上下文断裂问题从每天出现3-4次降到几乎为零。代价只是写了几十行JSON，以及每次Agent完成任务后自动更新这个文件。

有人可能会说：“这不就是手动维护状态吗？太原始了。”

但反过来想想：你写代码时，不也会在便签纸上记下进度和待办事项吗？对于Agent来说，这个文本文件就是它的“便签纸”。有时候最好的解决方案，就是最简单的方案。

2. 别让AI“保证”，让它“证明”——机械验证优于语言请求

我踩过最深的坑，是在Prompt里写“请确保代码通过测试”。

你猜怎么着？AI会回复你“我已经确保代码通过测试”，然后给你一段编译都过不了的代码。

AI不撒谎，但它会过度自信。 它永远会告诉你“没问题”，哪怕它根本没检查。

解决方案？简单到让你想抽自己：在系统提示里加一条规则——“标记任务完成之前，必须运行测试套件，并将测试结果截图保存到test_results/目录”。

我把这叫做“机械验证优于语言请求”。把对模型的“请求”变成系统级的“强制执行”。

具体实现：

• 在Agent的工具列表里加一个`run_tests`工具
• 这个工具先执行测试，再解析输出
• 只有所有测试通过，才允许Agent标记任务完成
• 如果有失败，必须修复并重新运行

我在一个React项目上测试了这个机制。之前Agent生成的代码平均需要3轮人工修复才能通过测试。加了机械验证后，首轮通过率从20%提升到了78%。

不是Agent变聪明了，是我把“通过测试”这件事从“建议”变成了“规则”。

3. 给Agent写文档，不是给人写文档——这个发现让我尴尬到脸红

我花了两周给项目写了一套详细的开发者文档——架构说明、代码规范、API文档，样样齐全。然后我发现Agent根本不读。

不是它懒，是它读不懂。

我写的文档是给人看的，有上下文、有隐含假设、有“你懂的”部分。但Agent需要的是机器可读的、精确的、无歧义的规范。

后来我改成了这种格式：

## 架构规则（Agent必须遵守）
- 所有数据访问必须通过Repository层，禁止直接调用数据库
- 异常处理必须使用自定义异常类，禁止抛出原生异常
- 日志必须使用结构化格式（JSON），禁止使用字符串拼接

每一条规则都是二元的、可执行的。Agent可以精确判断自己是否违反了规则。

效果？代码一致性大幅提升。之前Agent生成的代码中，约30%需要人工修正架构违规。写了机器可读的文档后，这个数字降到了5%以下。

真相是：不是Agent不听话，是你没把规矩说清楚。

反对意见：这是不是过度工程？

有人可能会说：“你这不是把简单问题复杂化了吗？直接写代码不就好了？”

我理解这种想法。说实话，我也曾经这么想。直到我亲眼看到一些团队用类似方法，让Agent在几个月内构建了超过十万行代码的生产系统，大部分代码由AI生成，人类只做审核和调整。

这个结果本身已经令人震惊，但更值得关注的是团队设定的核心约束：“禁止任何人工手动输入代码”。

这条约束不是为了炫技。它的作用是倒逼：当你绝对不能自己动手的时候，你必须把所有的隐性工程知识显式地写进Harness——哪些架构模式是允许的、哪些检查必须通过、代码库的结构规范是什么。所有过去“靠经验、靠惯例、靠默契”维系的东西，都必须变成系统可以执行的规则。

这才是Harness Engineering的精髓：把人类工程师的隐性知识，转化为Agent运行时的显式约束。

现在就开始，从这三件事做起

别想着一步到位。我花了三个月才搭建起一套勉强可用的Harness，而且还在不断迭代。

但你可以从今天开始：

1. 今天：给项目根目录加一个progress.json，让Agent记录进度和决策

2. 这周：在系统提示里加“完成前必须验证”的规则，跑测试、启动应用、截图检查

3. 本月：把架构规范和代码规范改写成机器可读的格式，让Agent能精确判断是否违规

AI已经是千里马。千里马没缰绳，跑得再快也到不了目的地。Harness Engineering，就是这个时代最重要的缰绳。

最后，用一句话来收束：

构建软件仍然需要纪律，但这种纪律更多地体现在支撑结构上——工具、抽象、反馈回路——而不是代码本身。

你的价值不再取决于你写代码的速度，而取决于你设计系统的能力——约束、反馈回路和控制系统，才是真正不可替代的东西。

别再做那个只会写代码的工程师了。做那个能驯服AI的人。