Zeb Evans 对 ClickUp 裁员 22% 的解释：AI 时代，公司到底还需要什么人？
原始来源：ClickUp Founder & CEO Zeb Evans 在 X 上关于 ClickUp 裁员 22% 的公开说明
原帖地址：https://x.com/DJ_CURFEW/status/2057522382315929802
来源文本：用户提供的 X 帖全文
说明：本文是基于该帖的中文解读与个人延展，不是逐句翻译。
ClickUp Founder & CEO Zeb Evans 最近在 X 上发了一篇很长的帖子，解释 ClickUp 为什么裁员 22%。
这篇帖子最容易被转述成一句话：
ClickUp 裁掉 22% 的人，是为了变成一家 AI-native 的 100x 组织。
但如果只看到这句话，其实会错过它真正值得讨论的部分。
Zeb 的说法不是“公司不行了，所以要降本增效”。
恰恰相反，他一开头就强调：ClickUp 的业务状态是历史最强。
他也不是简单说“AI 会替代人，所以裁员”。
他的核心判断更具体，也更残酷：
AI 不是让每个人平均变强，而是让组织里真正有判断力、会编排系统、能审查结果的人，被放大到一个新的级别。
反过来，很多旧岗位、旧流程、旧协作方式，会变成 AI 时代的新瓶颈。
这才是这篇帖子的重点。
1. 他说这不是省钱，而是组织重构
Zeb 在帖子里先做了几件事。
第一，他承认这是自己的决定，也说自己承担责任。
第二，他强调这不是为了削减成本。
第三，他说裁员节省下来的钱，大部分会重新流向留下来的人。
其中最引人注意的一句是：ClickUp 会引入百万美元级别的现金年薪区间。
他的逻辑是：
如果一个人通过 AI 系统创造了远超传统岗位定义的影响力，公司就不应该继续用传统薪酬带去衡量他。
这句话背后有一个很强的判断：
AI 会把组织里的贡献分布拉得更开。
过去，一个强员工可能比普通员工强 3 倍、5 倍、10 倍。
现在，如果他能管理 agent、重构流程、审查复杂输出、维护关键系统，他可能会影响一整个团队甚至一整条业务链路。
这就是 Zeb 所说的 100x impact。
所以这篇帖子不是单纯在讲裁员。
它讲的是一个更大的问题：
当 AI 把一部分人的产出放大到非常夸张的程度时，公司还应该按过去的岗位、人数和薪酬结构来运转吗？
Zeb 的答案很明确：不应该。
2. 100x organization：不是让所有人多用 AI
Zeb 提出了一个概念：100x organization。
这个概念听起来很像硅谷式口号，但他在帖子里的定义其实比较清楚。
他不是说公司要把每个人都训练成 100x。
他也不是说只要全员上 AI 工具，组织产出就会自动提升 100 倍。
他反而批评了这种想法。
他的观点是：
AI 不会自动让每个人都更高效。很多原有工作流如果不变，反而会制造新的瓶颈。
这点很重要。
很多公司现在理解 AI 的方式，还是在旧流程上加工具。
销售还是原来的销售流程，只是让 AI 写邮件。
产品还是原来的产品流程，只是让 AI 写 PRD。
工程还是原来的工程流程，只是让 AI 多写代码。
运营还是原来的运营流程，只是让 AI 写更多内容。
这种做法当然会带来局部效率提升。
但 Zeb 想说的是：这不是 AI-native。
真正的 AI-native 不是给旧系统装一个 AI 插件，而是重新设计系统本身。
原来需要三个人接力的流程，可能变成一个人加多个 agent。
原来需要会议同步的事情，可能变成系统状态和 agent 任务流。
原来靠人反复整理、催办、检查的工作，可能变成系统自动运行，人只负责目标、约束和审核。
所以 100x organization 的关键，不是“更多人使用更多 token”。
而是：
让最有判断力的人站到系统编排和结果审查的位置上。
3. 工程师的分化：写代码不再是最稀缺能力
Zeb 对工程团队的判断，是整篇帖子里最有争议、也最值得认真看的部分。
他说，很多公司还没有真正理解 AI 对工程组织的影响。
常见叙事是：
AI 让所有工程师都更高效。
但他认为，放到组织层面，这个说法可能是错的。
他的观察是：
真正强的工程师，不再只是自己写代码。
他们在做三件事：
- 编排 agent。
- 设计架构。
- 审查输出。
也就是说，最关键的能力从“我能不能写出代码”，变成了：
我能不能判断应该写什么、怎么拆、哪里有风险、哪些结果不能接受。
这就是他反复强调的 judgment。
在 AI coding 时代，代码生成本身越来越便宜。
但代码便宜不代表软件变简单。
因为系统复杂度没有消失。
需求判断没有消失。
架构取舍没有消失。
安全、性能、可维护性、用户体验、长期成本也没有消失。
只是原来很多复杂度藏在“写代码”里，现在它们集中到了“判断和审查”上。
Zeb 还批评了一种常见做法：
公司鼓励所有工程师大量使用 AI，然后庆祝 Pull Request 数量暴涨。
他认为这可能是错的指标。
因为更多 PR 不等于更多客户价值。
如果产出的代码需要最强工程师花大量时间审查，那这些代码本身就变成了瓶颈。
这句话对很多团队都很刺耳。
但它也很现实。
AI 让写代码变快以后，真正稀缺的资源变成了：
谁来定义问题，谁来约束系统，谁来判断质量，谁来承担后果。
4. PM 和设计师会融合，但 PM 不该把代码直接推上生产
Zeb 对产品和设计岗位也有一个判断：
产品经理和设计师的边界会越来越模糊。
有客户理解能力的设计师，会更像产品经理。
有 UX 直觉的产品经理，会更像设计师。
这其实已经在发生。
以前用户研究、竞品分析、反馈整理、原型迭代都很耗时间。
现在一个产品人可以让 agent 帮他整理访谈、分析反馈、生成方案、对比路径、做交互草图，甚至写一个可以点击的 demo。
所以产品和设计之间的很多摩擦会被压缩。
但 Zeb 有一个反直觉观点：
他不赞成 PM 直接把代码 ship 到生产环境。
他认为 PM 应该会 coding，但这个 coding 更适合发生在 playground 里。
用来验证想法、表达交互、定义范围、缩短沟通。
但生产代码不应该由 PM 直接推上去。
为什么？
因为这会把新的风险交给工程团队审查。
如果 PM 产出的代码最后还是要靠最强工程师兜底，那它并没有真正减少瓶颈，只是把瓶颈换了一个位置。
这点我很认同。
AI 时代“人人都能写代码”是真的。
但“人人都应该写生产代码”不一定是真的。
写代码变容易以后，生产系统的边界反而更重要。
5. Agent Manager：自动化自己工作的人，反而更有价值
Zeb 在帖子里提到一个新角色：Agent Manager。
他有一句很有意思的话：
那些用 AI 自动化自己工作的人，反而会一直有工作。
这句话乍听很鸡汤，但背后其实是组织设计的变化。
过去，一个岗位的价值经常来自“我能执行这件事”。
比如我能整理数据。
我能写周报。
我能跟进客户。
我能检查任务。
我能做一张表。
但在 AI 系统里，这些执行动作会越来越容易被自动化。
于是岗位价值会往上移：
你能不能把这件事变成一个稳定系统？
你能不能设计输入输出？
你能不能定义质量标准？
你能不能处理异常？
你能不能让 agent 长期运行，而不是只做一次 demo？
这就是 Agent Manager 的价值。
他不是简单“使用 AI 的人”。
他是 AI 系统的 owner。
这类人会逐渐变得重要，因为公司真正需要的不是一次性的 prompt，而是可持续运转的系统。
6. 前线岗位不会消失，人味会更贵
Zeb 还讲了一个很容易被忽略的点：front-liners。
也就是客户一线的人。
他的判断是，在一个充满 AI 信息、AI 邮件、AI 回复、AI 视频的世界里，真实的人类接触会变得更重要。
所以客户会议本身不应该被自动化。
应该被自动化的是会议前后那些系统：
资料整理。
客户背景。
会议纪要。
跟进任务。
CRM 更新。
内部同步。
风险提醒。
下一步建议。
这些都应该尽可能由系统完成。
但真正和客户面对面沟通、建立信任、理解上下文的时间，反而应该被保留下来。
这也是一个很重要的提醒：
AI-native 不等于 everywhere automation。
不是所有事情都应该被自动化。
有些事情自动化以后，反而会损害业务的核心价值。
真正的问题是：
哪些环节应该自动化，哪些环节必须保留人。
Leave a Reply