反共识判断公式：Agent 时代的组织搭建方法论
本文是方法论草稿，部分段落留了「创始人案例待补」——这些地方需要我（或对应 Scene）口述具体经历后再填，不编造没发生过的事。
为什么是"公式"
Mark Roberge 在《销售加速公式》(The Sales Acceleration Formula) 里做了一件很反直觉的事：把"销售"——一件长期被认为高度依赖个人天赋、人脉、临场发挥的事——拆成四个可复制、可规模化的公式（Hiring Formula / Training Formula / Demand Generation Formula / Management Formula）。
这本书成立的前提是：HubSpot 当时所在的赛道，规则已经相对清晰——SaaS、Inbound、订阅制，大家在同一套共识里比谁执行得更极致。公式化、数据化，解决的是"怎么把已经验证的打法复制一百遍"的问题。
但曾鸣教授 2026 年 9 月那次访谈（张小珺《商业访谈录》第 153 期）里有句话让我重新想了一遍这件事：
"优秀是持续拿到正向反馈、稳步成长；卓越是事后被证明，在持续负反馈、所有人不认同的时候坚持走反共识道路。"
《销售加速公式》教的是怎么做到优秀——沿着已经被验证的共识赛道，执行到极致。这没有错，HubSpot 用这套打法确实做成了。但曾鸣提的问题更尖锐：下一个时代的大赢家，大概率不是上一个时代把"优秀公式"执行得最好的那家。
他举的例子是模型公司：OpenAI、Anthropic 技术和商业成绩都了不起，但历史规律（雅虎、AOL、黑莓）告诉他，"第一阶段的企业很难活到第二阶段"。它们更像这个时代的 AOL——了不起的基础设施商，但基础设施商不等于下一阶段的大玩家。
所以这篇要写的不是"怎么把组织搭建公式化执行得更好"，而是反过来：借公式这个形式，装进"怎么系统性地做出反共识判断"这件内容。 公式的价值不在于给出标准答案，而在于让一件原本靠"拍脑袋""天才灵光一闪"的事，变得可以被刻意练习、可以被组织里的人共同操练。
公式一：反共识判断生成公式
原书怎么做：Roberge 发现，传统销售招聘靠"面试官感觉"——谁谈吐自信、谁简历漂亮就招谁，命中率很低。他反过来，先拿现有销售团队的真实业绩数据，统计出哪些特质（比如好学/谦逊的"可教练性"、过去的成功经验、好奇心、职业道德）和"后来业绩好"真正相关，再把这些特质做成打分表，让每个面试官用同一套标准打分——招聘从"凭感觉"变成"可复制、可验证的流程"。
换到这里，要解决的问题是：怎么系统性地产生、筛选、验证"反共识假设"，而不是靠创始人一拍脑袋喊"颠覆式创新"。
曾鸣在访谈里提了一个很关键的警告——幸存者偏差：
"市场上充斥大量疯狂想法，我们看到的只有成功者偏差；成功企业几乎必然站在反共识的一侧，但反共识不等于成功。绝大多数反共识会被现实证伪。"
这意味着"反共识"本身不是目的，可验证才是。公式的骨架：
- 列共识清单：先老老实实写下这个赛道里，所有人都认同、都在做的事——没有这一步，"反共识"只是一句空话。
- 逐条问"为什么大家都这么做"：是因为验证过有效，还是因为没人敢不这么做（纯粹的集体惰性/恐惧）？只有后者才值得押注。
- 设计最小可验证动作：不是直接把公司梭哈在反共识假设上，而是找一个成本可控、能在短周期内拿到"证伪或不证伪"信号的动作。
- 接受持续负反馈仍坚持的心理成本：曾鸣说得很直接，卓越是"事后"才被证明的——这意味着你在"事前"和"事中"都要忍受被质疑。公式要包含"怎么判断该不该继续扛"，而不是只教怎么扛。
创始人案例待补：CoHall 自己有没有一个"大家都这么做，我们偏不"的决策？当时怎么验证、扛了多久、现在回头看对不对？
公式二：任务中心组织设计公式
原书怎么做：招到人之后，Roberge 不让新人"跟着老员工自己摸"（师傅带徒弟式、每个人学到的东西全凭跟对谁）。他设计了一套标准化的新人认证流程——固定的课程，讲清楚目标客户画像、产品怎么创造价值、常见异议怎么应对，新人必须通过认证考核才能上手打真实电话。结果是不管招多少人、招得多快，每个人的起点和能力结构都基本一致，不靠运气。
曾鸣提的变化更根本：
"科层制管理的公司制度会衰亡……但组织不会消失，基本单元从岗位转向任务。"
科层制组织的基本单元是岗位（Job Title）——先定岗位，再招人填岗位，再给岗位配套 KPI。任务中心组织反过来：先有任务（一件具体要被完成的事，往往有明确的起止和交付物），再看这件任务需要什么能力组合（人 + Agent + 外部能力），岗位是任务消耗后留下的"沉淀"，不是组织设计的起点。
公式骨架：
- 先写任务清单，不写组织架构图：把"要被完成的事"列清楚，而不是先画框。
- 每个任务问一句"这件事的边界在哪、谁对交付物负责"：任务中心不等于没有责任人，只是责任人对应的是"一件事"而不是"一个岗位"。
- 能力配置动态化：同一个人可能同时是两个任务的不同能力组合的一部分；Agent 作为能力的一种，和人一起被配置进任务，不是单独开一个"AI 部门"。
- 定期回收/重组任务：任务做完了，配置的能力组合就该解散重新配置，而不是把人"焊死"在某个岗位上等下一个任务自动掉进来。
创始人案例待补：CoHall 内部有没有已经在用"任务"而不是"岗位"思考的地方？具体是哪件事、怎么配置的？
公式三：战略节奏公式
原书怎么做：早期 SaaS 公司的销售线索，很多靠创始人自己的人脉、靠销售个人打冷电话，不可规模化也不可预测。Roberge 把销售和市场紧密绑在一起，用 Inbound Marketing（内容、SEO，让潜在客户主动找上门）取代"主动骚扰式"获客，还把每个阶段的转化率都量化下来（比如"1000 个访客能转化出多少条线索、多少条线索能转化出多少单"），变成一套可以预测、可以按比例放大投入的"漏斗数学"。
曾鸣给战略方法论的节奏是：
"看十年、想三年、干一年。"
这句话本身就是公式，但抽象，需要落成可执行的节奏。骨架：
- "看十年"是读史，不是预测：具体动作是定期（比如每季度）做一次"产业史类比"复盘——这个阶段像互联网史上的哪个阶段？上一轮类似阶段的赢家/输家后来怎么样了？（曾鸣自己就是这么做的：拿雅虎、AOL、黑莓的市值和存活周期做类比。）
- "想三年"是设反共识假设的有效期：公式一产生的假设，不是永久有效，需要定一个"三年内要么被验证要么被放弃"的默认时限，避免假设变成信仰。
- "干一年"是把假设拆成当年可检验的动作：对应公式一的"最小可验证动作"，但要落到年度节奏上——一年结束时，必须有一个明确的"证伪/不证伪"信号产出，不能无限期"还在探索"。
- 节奏本身要形成仪式：比如固定的季度复盘会、年度假设更新会——公式的意义在于把这套思考方式嵌进组织的日历，而不是只存在于创始人脑子里。
创始人案例待补：CoHall 现在有没有类似的复盘节奏？还是这篇写完后才打算建立？
公式四：Context, Not Control 公式
原书怎么做：传统销售管理靠经理"盯人"——凭经验判断谁状态好谁状态差，等到季度/月末看业绩结果才知道谁完不成任务，已经来不及调整。Roberge 让团队每天记录过程指标（打了多少电话、约了多少 Demo、建了多少条 Pipeline），做成仪表盘，经理能在结果还没出来之前，就从"领先指标"里看出谁的节奏不对，提前介入辅导，而不是等结果出来再追责。
曾鸣提的组织文化关键词是：
Context, Not Control。
科层制管理的默认动作是"给指令"（Control）：告诉下属做什么、怎么做、做到什么程度。Context 模式反过来：把判断所需要的背景信息喂给执行者（人或 Agent），让对方自己生成该做什么。这对应公式二"任务中心"——如果组织的基本单元是任务而不是岗位，管理者就不可能对每个任务都给出精确指令，只能给上下文。
公式骨架：
- 识别"控制"的隐藏成本：每一条"指令"背后，都隐含"管理者比执行者更清楚该怎么做"的假设——在 Agent 时代，这个假设经常不成立（Agent 处理信息的方式和人不同，精确指令反而限制了它本可以发现的更优路径）。
- 拆解"上下文"的最小必要集合：不是把所有信息都倒给执行者（信息过载等于没给上下文），而是想清楚"做好这件任务，真正需要知道的边界条件、目标、禁止项是什么"。
- 把"给上下文"变成可复用的模板：类似本书所属 Bot 体系里的
MEMORY.md/ 规则文件（.cursor/rules/）——这正是"Context, Not Control"在实践中长什么样的一个具体例子：规则写清楚边界和偏好，而不是针对每个任务单独下指令。 - 管理者的新职责是维护上下文的准确性，不是审批具体动作：曾鸣说的"巨浪面前没有人是安全的"，对管理者本身也适用——如果还在靠审批具体动作来证明自己的价值，这个角色本身就是科层制的遗产，大概率会被下一阶段淘汰。
创始人案例待补：CoHall 自己做 Nebula 多 Bot 体系，是不是已经在实践 Context, Not Control？（比如这本书生产流程本身：CEO 口述 → Bot 读
MEMORY.md/规则去调研起草，而不是逐句下指令——这本身就是个现成的例子，但需要你确认这个类比成立不成立。）
小结：公式是手脚架，不是答案
四个公式借的是《销售加速公式》的形式——把一件原本靠直觉的事，拆成可操练、可复制的步骤。但内容换成了曾鸣的反共识判断体系：判断本身永远没有标准答案，公式只是让"怎么系统性地做出判断、怎么把判断嵌进组织"这件事，变得可以被刻意练习，而不是只能靠创始人一个人的灵光一闪。
曾鸣说得很直接：
"这个时代的企业过渡到下一个时代的企业，还能做得非常好的，多不多？不是多不多的问题，是有没有的问题——基本没有。"
这篇方法论不是为了让 CoHall 成为那个"基本没有"里的例外而写的保证书——没有公式能保证这件事。它只是想把"怎么老老实实面对这个残酷真相、系统性地去赌反共识"这件事，写清楚、写成可以被检验、被迭代的方法，而不是写成一句口号。
待补清单（下一轮口述可以直接对着这些问题讲）
- [ ] 公式一：CoHall 有没有一个"大家都这么做，我们偏不"的真实决策案例？
- [ ] 公式二：CoHall 内部有没有已经在用"任务"而不是"岗位"思考的具体例子？
- [ ] 公式三：CoHall 现在有没有类似"看十年/想三年/干一年"的复盘节奏？
- [ ] 公式四：用 Nebula 多 Bot 体系（本书生产流程本身）类比 Context, Not Control，这个类比你认不认？