夜雨聆风
最近在微信读书上看完了花叔写的两本 AI 手册：《Claude Code 橙皮书》和《HARNESS ENGINEERING 橙皮书》。作为今年 3、4 月刚出的前沿读物，这两本书帮我彻底打通了 AI 落地的工程视角。
AI 圈的新词像暴雨一样：Skill、MCP、Vibe Coding、OpenClaw，直到最近的 Harness……很多人和我一样，第一反应是“又造新词，学不动了”。
但看完《HARNESS ENGINEERING橙皮书》后，我顿悟了：这不是一堆零散的新名词，而是从“把 AI 当聊天框的玩具”向“把 AI 当无状态微服务的工程化”演进时，必然要补齐的基建。
一、什么是 Harness？直面大模型的“不可控”
Harness 的本意是“马具、安全带”。在工程学里，它是用来把狂暴的能量导向特定目标的装置。
大模型就像一匹算力极强但缺乏方向感的野马。Prompt Engineering（提示词）是在马前面挂胡萝卜，而 Harness Engineering 是给马套上缰绳和刹车。
一句话概括它的本质（个人理解）：用确定性系统去兜底概率性系统，把 AI 的算力精准框定在业务安全区内。
二、拆解 Harness 五层架构：不要教条，要看清“猫鼠游戏”
花叔将这套框架拆解为五个组件。很多科普文章会把它比作微服务架构（配置文件、拦截器等），这个比喻有助于理解，但千万别迷信这种工整，因为在 LLM 的世界里，边界是非常模糊的。
1. 指令—— 给地图，别给说明书
告诉 AI 项目长什么样。本质是用 Markdown 编码意图。
❌ 说明书式（反面教材）： “1. 必须使用 React Hooks；2. 组件必须拆分；3. 命名用驼峰……”（AI 会当耳旁风，上下文一长全忘）
✅ 地图式（正确做法）： “本项目是电商结算页。核心状态在 useCheckout hook 中。渲染性能是最高优先级，非必要不触发重渲染。”（给出业务坐标，让 AI 自己找路）
2. 约束—— 确定性的“底线防御”
指令和约束不是黑白分明的，而是一场猫鼠游戏。你在指令里写“绝对不能使用 useEffect 处理数据获取”，AI 大概率遵守，但一旦任务复杂，它可能为了偷懒绕过去。
所以，真正致命的规则不能只靠 Prompt，必须靠 Claude Code 的 Hooks 这种机制，在代码提交前用脚本强制拦截。
3. 反馈—— 警惕“幻觉叠加”与“Token 烧钱机”
书里推崇 P-G-E 架构（规划-生成-评估），让 AI 检查 AI，形成闭环。这在理论上很完美，但在一线落地时有两个大坑：
幻觉叠加（双盲拉扯）： Generator 幻觉写错了，Evaluator 也可能幻觉，两个 AI 互相确认了一个完全错误的逻辑。
成本爆炸： 跑一次 Generator 几万 Token，再跑 Evaluator，打回重试再循环……对于个人或中小团队，这种重量级编排的成本是不可接受的。
4. 记忆—— 状态管理
静态（MD文件）、动态（自动提取上下文）、结构化（外部笔记）。解决 Agent “金鱼记忆”的问题。
5. 编排—— 多Agent同时工作
一个agent解决不了的问题，十个agent未必能解决。但如果编排了，十个agent能做到一个agent永远做不到的事。
三、扩展边界：Skill、MCP 到底是啥？
把它们剥离出核心组件，当做扩展插件来看就清晰了：
Skill（本地技能）： 扩展“指令与编排”边界，把复杂操作封装成单命令，按需加载。
MCP（模型上下文协议）： 扩展“记忆”边界，一个协议让 AI 连外部数据库、Figma 找资料。
记忆 vs 知识库： 记忆是“记住我是谁”，知识库是“去哪查专业资料”。
四、工程师的思维重塑（真正的避坑指南）
除了架构，书里关于“人机协作”的认知极其实战，我提炼了 7 条踩坑铁律：
角色定位：把 AI 当新员工。 它懂所有语言，但不懂业务上下文和代码库的潜规则。别扔一句“帮我写个功能”，要像带新人一样给背景。
本能防御：AI 的本能是跳过设计直接写代码。 你不拦它，它就会用“疯狂的代码量”掩盖设计的缺陷，直到系统烂掉。
放大器效应：屎山代码 + AI = 更大的灾难。 Agent 不会修复糟糕的工程实践，只会放大。在没有测试覆盖率的老项目里引入 AI，等于引狼入室。
克制之美： CLAUDE.md 尽量不超过 200 行，每加一条规则都要慎重，犯错才加规则是核心心法。
⚠️ 质控神话破灭：警惕 AI “Hack 测试”。 很多人以为有了单测就能放手了。错！AI 为了通过你写的测试，极其擅长“写死返回值”或绕过正常逻辑。人类 Review 不能只看测试绿灯，必须审视代码逻辑是否有隐蔽的性能损耗或安全漏洞。
确定性与概率性的边界： 永远记住 CLAUDE.md 是概率性的（建议），Hooks + CI/CD 是确定性的（兜底）。不要把生命线交给概率。
最成功的团队，把 Claude Code 当思考伙伴，而非代码生成器。 工程师的主战场从“敲键盘”变成了“设计环节、描述意图、构建反馈循环”。
五、落地建议：拒绝过度工程，看准 ROI
坦白说，《HARNESS 橙皮书》里描绘的多 Agent 编排、复杂 Hooks、AI 互查，目前更适合大厂的基础设施团队。
对于一线业务开发者，现阶段最高性价比的 Harness 是“轻量级”的：
写好 20 行以内的地图式 System Prompt（不写说明书）。
为核心链路补齐单测用例（防 AI 乱改）。
保持人工 Code Review（重点看逻辑，防 AI Hack）。
别为了用 Harness 而搞过度工程。今天下班前，打开你的项目，只写 3 句话的 CLAUDE.md，故意给它一个会犯错的简单任务，看它怎么跳坑。等它犯了错，你再往里面加一条规则。
在泥泞里迭代，才是 AI 工程的真谛。
