小火苗变声器
65.51MB · 2026-04-16
有没有想过，你管理 AI 的方式，其实和你管理员工的方式，是同一件事？
不是比喻，是结构上的同构。
这几年 AI 工程领域先后冒出三个概念：Prompt Engineering、Context Engineering、Harness Engineering。每次一个新词出现，就有人问：这到底是什么？跟上一个有什么区别？我需要学吗？
这篇文章不打算用技术术语解释技术术语。
我要用一条每个人都经历过、或者至少观察过的故事线来解释这一切——一家公司从 3 个人到 500 个人的成长史。
在展开故事之前，先建立这个类比的基础。
大模型（LLM）本质上是一个任务执行的大脑：给它足够清晰的输入，它能产出高质量的输出；给它模糊的输入，它只能靠猜。
这不就是每一个聪明员工的写照吗？
这个类比成立的前提，恰好也是 2023 年以来 AI 工程领域最重要的认知转变：模型能力已经不是瓶颈了——GPT-4、Claude 3、Gemini Ultra，这些模型处理日常工作任务已经绰绰有余。真正的瓶颈，是我们如何组织、引导、约束它们的工作方式。
换句话说：AI 工程的核心问题，正在从"怎么做一个更聪明的模型"变成"怎么构建一个更好的管理体系"。
想象一家刚刚创立的三人初创公司。
CEO、CTO、设计师，三个人挤在一个共享办公室里。要启动一个新功能？CEO 直接走到 CTO 旁边说："哥们，我需要一个用户登录页，支持手机号和微信，今天能搞定吗？"
这个阶段，事情能不能做好，完全取决于两件事：CEO 说得清不清楚，CTO 理解得准不准。
CEO 如果语焉不详，说"做个好看点的登录页"，CTO 可能做出来的东西和预期差了十万八千里。但如果 CEO 能把需求描述得足够精确、给足够多的参考、甚至画个草图——哪怕没有任何文档、没有任何流程，一个聪明的 CTO 也能做出来很好的东西。
成功的关键：老板说话的艺术。
这就是 Prompt Engineering 的本质。
2023 年 ChatGPT 爆红之后，人们发现了一件神奇的事：同样的问题，换一种问法，答案的质量天差地别。
于是一门学问诞生了——如何构造高质量的提示词：
角色设定："你是一位有 20 年经验的资深架构师..."
思维链："请一步步思考，先分析问题，再给出方案..."
Few-shot："这里有三个例子，请按同样格式输出..."
结构化输出："请用 JSON 格式返回，包含 name、score、reason 三个字段"
Prompt Engineer 研究的，就是"如何跟 AI 说话"——用什么措辞、给什么结构、设定什么角色。
就像那个能精确描述需求的 CEO，一个好的 Prompt Engineer 能从同一个模型里榨出普通人榨不出来的结果。
但三人团队的管理方式，无法撑起一家 50 人的公司。
每次任务都需要 CEO 亲自下场精心描述需求，这不可持续。更根本的问题是：当任务变得复杂——需要多轮推理、需要跨任务的记忆、需要访问外部数据——光靠说话的技巧，已经不够了。
提示词工程的本质是一次性的、手工的、脆弱的。你精心调教的 Prompt，换个模型就可能失效。更关键的是：它解决不了"AI 不知道背景信息"这个根本问题。
公司融了 A 轮，从 3 个人长到了 50 个人。
这时候出现了一个经典问题：新来的工程师上手太慢。每次 onboarding，CEO 或老员工都要花大量时间口头解释：这个项目的背景是什么、技术栈是什么、这块代码为什么这么写、哪些接口不能随便改……
于是公司开始建文档体系：技术 Wiki、产品文档、架构设计文档、新人 onboarding 手册……
这个阶段的核心变化是：不再依赖"口头说清楚"，而是把背景信息系统化地沉淀下来。
新来的工程师在开始工作之前，先看完 onboarding 文档、读完技术规范——他获得了完整的上下文，然后才能开始高效地执行任务。
成功的关键：给员工提供多少有效的背景信息。
这就是 Context Engineering 的本质。
随着大模型的上下文窗口从 4K 扩展到 128K 再到百万 token，人们意识到：模型的能力上限，不再是"能不能理解"，而是"给了它什么信息"。
2025 年，Andrej Karpathy 直接发推说：
Context Engineering 要解决的问题是：什么信息应该放进上下文？以什么顺序放？怎么结构化？放多少？
典型实践包括：
RAG（检索增强）：不把所有知识塞进 Prompt，而是动态检索最相关的片段
Memory 管理：决定哪些历史对话值得保留，哪些可以压缩丢弃
System Prompt 设计：CLAUDE.md 就是典型的 Context Engineering
信息分层：重要信息放在上下文的开头和结尾（LLM 对首尾更敏感）
结构化注入：用 XML 标签、JSON 结构让 AI 更容易定位信息
你用过 Claude Code 吗？当你在项目里放一个 CLAUDE.md 文件，写上"这个项目的技术栈是 Next.js 14，禁止修改 package.json，代码风格遵循 XX 规范"——这就是 Context Engineering。
你不是在教 Claude"怎么说话"，而是在给它看项目的 onboarding 手册，让它在开始工作之前就拥有完整的背景信息。
50 人的公司，有了文档体系，就够了吗？
还不够。
文档告诉员工"背景是什么"，但没有告诉他"这件事应该怎么做"。当员工开始接触真实的、有风险的操作时——修改核心代码、访问生产数据库、发送对外通知——光靠"给他看背景材料"是远远不够的。
你需要的，是流程和制度。
公司继续发展，到了 500 人规模。
这时候，一个新工程师改了一行代码，如果没有流程约束，可能直接上线就把生产环境搞崩了。一个销售代表如果没有审批流程，可能随手给客户开了一个根本不该给的折扣。
成熟企业的解决方案不是"把话说得更清楚"，也不是"给员工更多背景材料"——而是建立制度：
这个阶段的核心洞察是：不靠人的自觉，靠系统的约束。
你不需要每次都提醒工程师"上线前要做代码审查"——CI/CD 流水线会强制检查，没有通过审查就无法部署。
成功的关键：把控制逻辑从"人的意识"移到"组织系统"里。
这就是 Harness Engineering 的本质。
"Harness"这个词来自英语，有三层含义，每层都精准对应了这个概念的一个维度：
AI Agent 在真实世界里执行任务，就像员工在成熟企业里工作——需要的不是更好的"沟通"，而是更好的"系统"。
Claude Code 的 Hooks 功能是一个绝佳的例子：
{
"hooks": {
"PreToolUse": [{
"matcher": "Bash",
"hooks": [{
"type": "command",
"command": "security-check.sh"
}]
}],
"PostToolUse": [{
"matcher": "Write",
"hooks": [{
"type": "command",
"command": "git add -A && git status"
}]
}]
}
}
这段配置的含义：
注意：这些逻辑不在 Prompt 里，不在上下文里——它在 Harness 里。AI 自己甚至不知道这些检查在发生，但它的每次行为都被这套系统静默地管控着。
Harness Engineer 构建的核心要素：
权限矩阵：读文件（自由）/ 修改配置（需审批）/ 推送代码（禁止）
工具设计：职责单一、边界清晰、有路径校验和超时保护的工具集
Hooks 系统：在 AI 行为的关键节点插入检查、审批、记录逻辑
多 Agent 编排：多个专业化 Agent 协作的流水线架构
可观测性：每次工具调用的完整日志，出了问题能追溯
这种对应不是巧合。
企业管理的每次演进，都是被同一组力量驱动的：规模、风险、可预期性。
当团队是 3 个人时，沟通成本低，口头协调就够了；当团队是 500 个人时，必须用制度替代沟通，否则系统会在复杂性中崩溃。
AI 系统的演进路径完全相同：
| 驱动力 | 企业管理 | AI 范式 |
|---|---|---|
| 规模 | 3人靠沟通，500人靠制度 | 单个简单任务靠 Prompt，复杂多步 Agent 靠 Harness |
| 风险 | 能力越强的员工，犯错代价越大 | AI 能访问真实系统后，一个错误可能删掉生产数据库 |
| 可预期性 | 企业要的是稳定可预期的输出，不是"看今天发挥" | AI 系统要的是可测试、可调试、可观测，不是"看 AI 心情" |
这背后有一个更深的洞察：
早期模型能力弱，瓶颈是"能不能理解"，所以研究 Prompt。模型变强后，信息管理成瓶颈，所以出现 Context Engineering。现在模型足够聪明、信息也能管理好，系统可靠性成了瓶颈——所以 Harness Engineering 登场了。
这里有一个很多人没想到的反面。
现实中的大公司病是什么样的？流程套流程、审批套审批，一个本来两小时能做完的事，光是走审批就要两周。最终，制度从"保护组织"变成了"阻碍组织"。
AI 系统也会得同样的病。
Harness 设计得太死、权限管控太严、每一步都要人工审批——这样的 AI 系统不是可靠，而是失去了 AI 的核心价值：自主执行。
甜蜜区间的标准是：
Harness 的设计哲学不是"把 AI 关进笼子"，而是**"让 AI 在安全边界内尽可能自由地飞"**。
回到企业管理的故事线。
一家 500 人的成熟企业，拥有完善的制度和流程之后，下一步往哪里走？
历史上有两条路：一条往外扩——生态化；一条往内深——文化驱动。
苹果不只是制造手机，它建了一个 App Store 生态；阿里不只是卖货，它建了一个电商生态平台。
当单一企业的边界触达上限，下一步不是把这家公司做得更大，而是构建一个让更多参与者协作创造价值的生态系统。
AI 系统的演进同样如此。
单个 AI Agent 有能力边界。当任务复杂到需要多个专业化 Agent 协作时，Harness Engineering 的视角就不够了——你需要的是 Ecosystem Engineering：
这条路的现实依据已经出现：MCP 协议正在快速推广、Multi-agent 框架（LangGraph、CrewAI）被广泛采用、各大厂商开始构建 Agent 市场。
还有另一条路：企业发展到一定阶段，最优秀的公司不再主要靠制度约束员工的行为，而是靠文化。
Netflix 的著名文化手册里说：我们的目标是招聘足够好的人，让他们不需要查规则手册，天然就知道什么是对的事情。
这是更高阶的管理形态：把价值观内化到员工的判断力中，使他们在任何规则没有覆盖到的新情况下，也能做出符合组织期望的决策。
AI 系统的类比方向是 Alignment Engineering：
与其在 AI 的行为外面套一层层 Harness，不如在训练阶段就把价值观和行为准则注入模型本身——让 AI 不是"被外部约束不去做坏事"，而是"从内部就不想去做坏事"。
这对应 AI 领域正在发生的：
但这条路离今天的工程实践更远。它更像是一个长期愿景：我们不再需要那么多外挂的 Harness，因为 AI 本身就已经"三观正确"了。
回顾这条进化链条：
| 阶段 | 核心问题 | 企业类比 | 关键词 |
|---|---|---|---|
| Prompt Engineering | 怎么说？ | CEO 直接发需求 | 措辞、结构、角色 |
| Context Engineering | 给什么信息？ | 公司开始建 Wiki | RAG、Memory、System Prompt |
| Harness Engineering | 搭什么系统？ | 成熟企业建制度 | Hooks、权限、工具设计 |
| Ecosystem Engineering（预测） | 组什么生态？ | 平台化、生态化 | Multi-agent、MCP、协议 |
| Alignment Engineering（预测） | 内化什么价值观？ | 文化驱动型组织 | Constitutional AI、对齐 |
这条路的本质，是我们和 AI 之间关系的深刻变化：
当你开始思考"我要搭什么系统让 AI 来工作"，而不再只是"我要怎么跟 AI 说话"——你就已经踏上了这条进化路径。
不需要一步到位。了解自己所处的阶段，知道下一步往哪里走，就已经比大多数人领先了。
