从 Harness Engineering 说起：为什么我最后选择轻量化记忆 + Hooks
最近 AI 工程圈最火的话题是什么？无疑是 Harness Engineering。
各种解读铺天盖地，有人研究模型选型，有人研究工作流编排，有人研究 Agent 协同。我也没忍住跟了一波热潮，读了不少文章，其中有一篇讲团队知识沉淀和 Harness 工作流结合的实践让我印象很深。
但真正让我有感触的，是结合自己这一年用 AI 编程的经验。
那些”重器”我试过，最后还是觉得太重
说实话，我一开始也折腾过不少复杂的 Harness 方案——多 Agent 协同、16 阶段状态机、知识库分层、成熟度衰减……理论上都很美，实践起来总觉得哪里不对。
最大的问题是用一次就放下了。搭一套复杂的 Harness 工作流需要时间，维护需要精力，等到下一个项目来了，上一套的上下文早就忘了，重新搭一遍又费劲。
后来用 claude-code 比较多，它的长时记忆和多 Agent 协同确实做得不错。但用下来发现，它解决的问题和它带来的复杂度是成正比的。对于我这种一人公司或者说小团队来说，”精准控制”和”省心省力”之间，后者往往更重要。
所以我现在的做法其实是做减法。
轻量化记忆：几个核心文件就够了
我不搞五层知识架构，不搞独立 Git 仓库。我就几个核心文件：
CLAUDE.md 是入口——项目背景、技术栈、我希望 AI 做什么、不做什么、哪些是雷区。这是我给 AI 员工的”入职手册”。
*.md 是分散在各处的笔记——遇到一个问题解决一个问题，记录下来，下一次遇到类似的直接告诉 AI “参考某篇笔记”。不追求系统性，追求”用得上”。
SKILL.md 是我给特定工具定制的规则——比如这个博客的发布流程、飞书文档转博客的流程。AI 照着这个跑就行，不需要每次重新说。
这几个文件加在一起，大概也就是几十 KB。但它们让我每次启动新的 AI 编程会话时，不需要从零开始解释项目。
Hooks 是让工作流真正落地的关键
光有记忆还不够。AI 编程的时候，很多重复的操作可以自动化——比如每次写完代码跑测试、每次提交前检查 lint、每次新功能加相应的文档。
这些我都是通过 Hooks 来做的。
不是那种复杂的 CI/CD pipeline，就是很简单的脚本，挂在关键节点上自动触发。Git hook 可以控制提交行为，AI 工具的 hook 可以控制执行流程。
举几个我常用的：
- 提交前自动跑单元测试，失败了就阻止提交
- 代码变更后自动生成变更记录，不用手动写 CHANGELOG
- 特定目录下改文件，自动触发格式化和检查
这些 Hook 很小，但它们让工作流真正自动化了，而不是每次都要手动触发。
Skills 是可复用的工作流单元
如果说 Hooks 是自动化执行，那 Skills 就是自动化决策。
同一个任务跑了三遍以上，我就会想——能不能把这个流程固化下来，下次一键执行？
比如”飞书文档转博客”这件事，我做了一遍觉得流程稳定了，就把它写成 Skill。下次遇到类似的文档，AI 直接按这个流程跑，不需要我重新说每一步该怎么做。
Skills 的本质是给 AI 看的 SOP。你不需要写代码，你只需要把流程说清楚，AI 照着执行就行。
我的感受
Harness Engineering 的大多数讨论都在讲”怎么设计更复杂的系统”，但我觉得对个人和小团队来说，轻量化和可复用才是更实际的目标。
不需要搭一套看起来很专业的东西，需要的是：
- 几个核心的记忆文件，覆盖项目上下文
- 几个实用的 Hooks，把重复操作自动化
- 几个 Skills，把高频流程固化下来
做到了这三点，每次启动新的 AI 编程会话，其实都是在复用之前的积累，而不是从零开始。
复杂的工具是给大团队用的，适合自己的工具才是给自己用的。