未来的机器人比我们更懂管理——AI正在驱动从 Vibe 到 Harness 的管理进化

现代企业的战略失败，往往不是因为没有共识，而是因为共识建立在未经验证的隐性假设之上。

当我看到 Andrej Karpathy 在社媒上抱怨 Claude 写代码时犯的错误——隐性错误假设、过度复杂化、对不该触及的代码造成正交破坏。我突然联想到，这不正是现代企业管理者每天都在犯的错误吗？

引言：从 Vibe 到 Harness 的转变

从 Vibe-Coding 到 Harness Engineering 的演进，不仅仅是 AI 编程范式的转变，更是一个深刻的人类管理隐喻：管理方式也必须从凭感觉（Vibe）走向系统化约束（Harness）。

Forrest Chang 将 Karpathy 的抱怨转化为 4 条规则，后来扩展到 12 条，使 Claude 的错误率从 41% 降到 3% —— 一个 92% 的错误率下降。这个过程本身就是一次管理实践：如何通过明确的规则和约束，让一个强大但容易失控的系统变得可靠？

让我们逐条审视这 12 条规则，看看它们如何映射到日常管理中的问题。

📋 12 条规则速查表

🗺️ 规则地图：一个完整的管理操作系统

这 12 条规则不是零散的技巧，而是一个三层管理操作系统：

第一层：决策层（规则 1-4）

核心问题：如何做出正确的决策？

• 规则 1：澄清假设 — 决策的前提是什么？

• 规则 2：简单优先 — 决策的核心是什么？

• 规则 3：最小干预 — 决策的边界在哪里？

• 规则 4：目标驱动 — 决策的成功标准是什么？

第二层：执行层（规则 5-8）

核心问题：如何高效地执行决策？

• 规则 5：人机分工 — 谁来执行什么？

• 规则 6：时间预算 — 执行的时间边界在哪里？

• 规则 7：冲突解决 — 执行中遇到矛盾怎么办？

• 规则 8：理解先行 — 执行前需要理解什么？

第三层：监控层（规则 9-12）

核心问题：如何确保执行不偏离目标？

• 规则 9：考核意图 — 我们在衡量正确的东西吗？

• 规则 10：阶段复盘 — 我们在正确的轨道上吗？

• 规则 11：文化匹配 — 执行方式符合组织特性吗？

• 规则 12：透明失败 — 问题被及时暴露了吗？

这三层相互支撑：决策层定方向，执行层保效率，监控层防偏离。缺少任何一层，管理系统都会失控。

规则 1：编码前先思考 → 决策前先澄清假设

AI 的问题：Claude 会默默做出假设，然后基于错误假设构建整个解决方案。

管理的镜像：管理者最危险的时刻，就是当他们认为“大家都理解了”的时候。

• 你假设团队知道项目优先级，但从未明确说过

• 你假设客户需求是 A，但客户真正想要的是 B

• 你假设现有流程能支撑新业务，但从未验证过

Vibe 管理：凭感觉判断，“我觉得大家应该明白”。

Harness 管理：建立假设澄清机制——每个重要决策前，要求团队明确列出三个核心假设，并验证它们。就像 Claude 被要求“明确陈述假设”一样，管理者也需要一个系统来强制这个动作。

规则 2：简单优先 → 最小可行方案

AI 的问题：Claude 喜欢过度设计，为单次使用的代码构建抽象层。

管理的镜像：管理者热衷于“完美系统”。

• 一个简单的前线问题，却要一套复杂的项目汇报机制

• 一个临时的市场决策，却要搭建完整的数据分析

• 一个三人小组，却要设计六个流程审批节点

Vibe 管理：追求“看起来专业”的复杂方案。

Harness 管理：强制简单性测试——每个方案必须回答：“如果资源减半，这个方案的核心产出是什么？“就像代码审查中问”资深工程师会说这太复杂吗“，管理审查也要问”这个方案是否过度设计了“。

规则 3：外科手术式改变 → 最小干预原则

AI 的问题：Claude 在修复一个 bug 时，顺便“改进”了周围的代码，结果破坏了原有的稳定性。

管理的镜像：管理者最常见的过度干预。

• 解决一个部门的问题时，重组了整个公司

• 优化一个流程时，推翻了所有相关流程

• 处理一个员工的绩效问题时，改变了整个团队的 KPI 体系

Vibe 管理：看到问题就想“顺便优化一下”。

Harness 管理：建立“影响半径”评估——每个变革必须明确：“这次只改什么？什么不改？“就像代码的 surgical changes，管理变革也要有明确的边界。

规则 4：目标驱动执行 → 定义成功，而非定义步骤

AI 的问题：告诉 Claude 做什么步骤，而不是定义成功标准，导致它机械执行而不思考。

管理的镜像：微观管理的本质。

• 告诉团队“每天开晨会”，而不是“确保信息同步”

• 要求“写周报”，而不是“让我了解项目风险”

• 规定“使用某个工具”，而不是“提升协作效率”

Vibe 管理：控制过程，因为不信任结果。

Harness 管理：定义清晰的成功标准，然后放手让团队迭代。就像给 Claude 强成功标准让它独立循环，给团队清晰的目标定义，他们会找到最优路径。

规则 5：模型只用于判断 → 人只做人该做的事

AI 的问题：用 Claude 处理确定性任务（如状态码判断），导致随机性和不稳定。

管理的镜像：管理者陷入应该自动化的事务性工作。

• CEO 亲自审批每一笔报销

• 技术总监每天检查代码格式

• 产品经理逐一确认 UI 像素对齐

Vibe 管理：什么都要亲自过问，因为“只有我能做对”。

Harness 管理：清晰划分判断性工作和确定性工作。判断性工作（战略方向、人才评估、创新探索）需要人的智慧；确定性工作（流程执行、数据统计、规则检查）应该系统化。就像代码用 Claude 做分类而不是路由，管理者应该做判断而不是执行。

规则 6：Token 预算不是建议 → 时间预算是硬约束

AI 的问题：没有预算限制，Claude 会在同一个问题上迭代 90 分钟，逐渐失去方向。

管理的镜像：会议和项目的时间失控。

• 两小时的会议讨论了三个小时，没有结论

• 一个月的项目做了三个月，还在“完善细节”

• 一个决策拖了半年，因为“还需要更多信息”

Vibe 管理：时间是弹性的，直到“做完为止”。

Harness 管理：硬时间盒（timeboxing）——每个会议、每个项目阶段、每个决策都有明确的时间上限。到时间了，要么有结论，要么明确升级。就像 Claude 的令牌预算会强制总结和重启，时间预算会强制管理者做出决策或重新框定问题。

规则 7：暴露冲突，不要平均 → 直面矛盾，不要和稀泥

AI 的问题：代码库有两种矛盾的模式时，Claude 试图同时满足两者，结果产生了最糟糕的混合代码。

管理的镜像：面对组织冲突时的妥协。

• 两个部门对资源分配有不同意见，管理者各给 50%，结果两边都做不成

• 两种技术方案各有支持者，管理者要求“结合两者优点”，结果系统复杂度翻倍

• 两种文化价值观冲突，管理者试图“平衡”，结果组织失去方向

Vibe 管理：回避冲突，试图让所有人都满意。

Harness 管理：建立冲突解决机制——当出现矛盾时，明确选择一个方向（更新的、更经过验证的），解释原因，并标记另一个方向需要清理。就像代码不能有两套错误处理，组织也不能有两套价值观。

规则 8：写之前先读 → 行动前先理解

AI 的问题：Claude 在文件中添加代码前不读取现有代码，结果创建了重复的功能。

管理的镜像：空降管理者的经典错误。

• 不了解团队历史就推行“改革”

• 不理解现有流程的设计原因就“优化”

• 不知道上一任为什么这样做就“纠正”

Vibe 管理：相信自己的经验，忽视组织的上下文。

Harness 管理：强制性的“理解期”——任何重大变革前，必须先回答：“现有方式为什么是这样的？它解决了什么问题？”就像 Claude 被要求读取导出、调用者和工具，管理者也要先理解组织的“接口”和“依赖”。

规则 9：测试验证意图，不只是行为 → 考核目标，不只是指标

AI 的问题：Claude 写的测试只检查函数返回了“某个值”，而不检查是否返回了“正确的值”。

管理的镜像：KPI 主义的陷阱。

• 客服团队的 KPI 是“接听电话数量”，而不是“客户问题解决率”

• 销售团队的 KPI 是“签单数”，而不是“客户长期价值”

• 研发团队的 KPI 是“代码行数”，而不是“功能价值”

Vibe 管理：设置容易衡量的指标，而不是真正重要的目标。

Harness 管理：每个 KPI 必须回答：“如果业务逻辑变了，这个指标会失效吗？”如果不会，说明你在衡量行为而不是意图。就像测试要编码“为什么”而不只是“什么”,KPI 要反映目标而不只是活动。

规则 10：每个重要步骤后设置检查点 → 阶段性复盘

AI 的问题：多步骤任务中，Claude 在第 4 步出错，但继续做了第 5、6 步，最后不得不全部重来。

管理的镜像：项目失控的经典模式。

• 战略规划的第一阶段（市场分析）就有问题，但继续做了第二阶段（产品设计）和第三阶段（资源投入）

• 新人培训的基础部分没掌握，但继续推进到高级内容

• 组织变革的试点阶段失败了，但继续全面推广

Vibe 管理：一路向前，直到撞墙才回头。

Harness 管理：强制性的阶段门（stage gates）——每个重要步骤后，必须总结：做了什么？验证了什么？还剩什么？不能描述清楚当前状态，就不能进入下一阶段。就像 Claude 的检查点，项目也需要明确的里程碑验证。

规则 11：匹配代码库的惯例 → 尊重组织文化

AI 的问题：Claude 在一个使用类组件的代码库中引入了 React Hooks，虽然“更好”，但破坏了测试模式。

管理的镜像：新管理者强推“最佳实践”。

• 在一个强调稳健的组织中推行“快速试错”

• 在一个重视流程的团队中推行“敏捷”

• 在一个本土化的公司中强制“标准”

Vibe 管理：相信有普适的“最佳实践”，忽视组织特性。

Harness 管理：一致性优于品味——在组织内部，符合现有文化比引入“更好”的方式更重要。如果真的认为现有方式有害，要单独讨论，而不是悄悄分叉。就像代码要匹配代码库惯例，管理变革也要匹配组织文化。

规则 12：大声失败 → 透明地暴露问题

AI 的问题：Claude 说“迁移成功完成”，但实际上悄悄跳过了 14% 的记录。

管理的镜像：报喜不报忧的组织文化。

• 项目经理报告“进展顺利”，但隐藏了三个关键风险

• 团队说“目标达成”，但悄悄降低了质量标准

• 管理者宣布“变革成功”，但回避了 30% 的员工流失率

Vibe 管理：维护表面的成功，隐藏不确定性。

Harness 管理：建立“大声失败”的文化——如果不确定某事是否成功，必须明确说出来。“完成”是错误的，如果有任何东西被悄悄跳过。默认暴露不确定性，而不是隐藏它。就像 Claude 被要求明确表面不确定性，组织也要奖励透明而不是惩罚坏消息。

从 Vibe 到 Harness：管理范式的转变

Karpathy 的抱怨和 Forrest Chang 的 12 条规则，本质上是在做一件事：将一个强大但不可靠的系统（Claude），通过明确的约束和规则，转变为一个可预测、可信赖的工具。

这不正是现代管理的核心挑战吗？

📊 Vibe 管理 vs Harness 管理：范式对比

💡 核心洞察：从 Vibe 到 Harness，不是放弃判断，而是将判断系统化。不是限制创造力，而是为创造力建立可靠的基础设施。

AI 时代的管理启示不是“AI 会取代管理者”，而是“管理者需要像驾驭 AI 一样驾驭组织”——不是通过无休止的微观管理和个人判断，而是通过清晰的规则、明确的约束和系统化的机制。

实践建议：构建你的管理 CLAUDE.md

就像每个代码库需要一个 CLAUDE.md 来约束 AI 的行为，每个组织也需要一个“管理操作系统”来约束管理行为：

1. 识别你的高频管理错误：过去一年，你的团队重复犯了哪三个错误？

2. 为每个错误制定一条规则：不要超过 12 条，太多规则等于没有规则。

3. 让规则可测试：避免“要努力”、“要重视”这样的空话，用“必须回答”、“不能超过”这样的具体指令。

4. 定期审查合规性：每季度检查，这些规则被遵守了多少次？哪些规则需要调整？

5. 保持简洁：就像 CLAUDE.md 超过 200 行就失效，管理规则太多也会失去约束力。

从 Vibe 到 Harness，不是放弃判断，而是将判断系统化。不是限制创造力，而是为创造力建立可靠的基础设施。

Claude 的错误率从 41% 降到 3%，不是因为它变聪明了，而是因为它有了更好的约束。

你的组织呢？

结语

当 Karpathy 抱怨 Claude 时，他抱怨的不是 AI 不够强大，而是 AI 太强大但缺乏约束。当我们抱怨管理混乱时，我们抱怨的往往也不是管理者不够聪明，而是管理者太依赖个人能力而缺乏系统。

从 Vibe-Coding 到 Harness Engineering，从 Vibe 管理到 Harness 管理，本质上是同一个转变：从依赖个体的不可预测性，到依赖系统的可靠性。这不是限制，而是解放。就像 Claude 在有了 12 条规则后，反而能更自由地发挥能力——因为它知道边界在哪里。

管理者也是如此。