场景：Prototype 邀功者——"我用 AI 做了个 demo"
你在会议上保持克制，但你的同事刚刚在周会上兴奋地展示了他用 AI 搭建的 prototype："这个流程以前需要三天，现在 AI 十分钟就搞定了！"领导连连点头，称赞他"拥抱 AI 的态度"。
你心里知道：他把一个团队核心流程的判断逻辑喂给了 AI，然后把结果展示给了决定你们团队编制的人。
这个人到底在做什么？你该怎么办？
先回答一个更尖锐的问题
"如果大家都不做，这种人是不是反而得益？"
短期：是的。 在一轮绩效评估的时间窗口内，prototype 邀功者确实获得了好处：领导的关注、"拥抱创新"的标签、可能的绩效加分。而其他人看起来像"不够积极"。
但这就是囚徒困境最恶心的地方——短视的自利导致长期的集体灾难，包括邀功者自己。
不要把这叫"个体理性"。一个真正理性的人会算长期账。这是短视的自利——博弈视野只看到下一次绩效评估，看不到下一轮裁员。
而且邀功者之间也在内卷：有人写了 skill，就有人写更好的 skill；有人做了 prototype，就有人给 prototype 做 benchmark。更准确地说，这是逐底竞赛（race to the bottom）——比赛谁能更彻底地证明"我的工作可以被 AI 替代"。所有人加速，所有人下沉。
邀功者不知道的事：他们在展示的是什么
他以为他在展示："我很能干，我会用 AI。"
管理层实际接收到的信息："这个团队的工作可以用 AI 做完。"
已经有报道记录了真实案例：
案例一（Economic Times 报道）：一名电商开发者花了大量时间为公司构建自动化系统，节省了数千小时的人力。结果：没有升职，没有加薪，反而被分配了更多工作。最终公司招了一个时薪 16 美元的新人来接管，并要求他交出所有代码的管理员权限。他怀疑自己正在被低成本替代。
案例二（Economic Times 报道）：一个创业公司员工花了 10 个月训练他的经理使用他构建的自动化系统。训练完成后，他被裁了。然后公司以 freelancer 的身份请他回来维护系统——按件计费，没有福利。
案例三（georgesonfirst.com.au 报道）：一个 26 岁的工程师在"梦想工作"中每周工作 80 小时，构建用于替代人力的 AI Agent。他是团队里最积极、最能干的人。他被裁了。
模式是一致的：构建者被提取了价值，然后被丢弃。 "感谢你的贡献"和裁员通知之间，往往只隔几周。
已经有人在行动了
中文技术社区的相关讨论中，已经出现了清醒的声音：
"写了 local 用，local 的才是节省自己的时间，public 的那就是出卖自己。"
"发布的 skill 和自己用的 skill 搞阴阳版本。反正你别问，问就是你的 AI 没调教好，怎么调教我回头开个课给你们慢慢讲讲——这业绩不就来了。"
"要机器的可以投资买，但不能偷。要 skill 可以 5 年工资买断，而不是仅仅停工两周。"
"其实可以写得相互矛盾，然后让 skill 套 skill，矛盾藏在不同的 skill 里面。这样 agent 跑起来又慢又处理不了真的问题。CTO 看了账单，大呼 skill 是骗局。"
"第一个提出防御性编程的简直是天才。"
这些人没有读过 Zion，但他们已经在实践 Zion 的核心逻辑——保护自己的判断力，控制交出的深度。 他们的本能是正确的。Zion 做的只是把这种本能系统化、框架化，让更多人能够想清楚。
博弈分析：为什么邀功者的策略是自毁性的
回合一（短期）：邀功者得分
你：保持克制，正常工作
他：展示 prototype，获得绩效好评
得分：他 > 你回合二（中期）：管理层重新评估团队
邀功者的 prototype "证明"了工作可以被 AI 完成。但管理层不会只裁掉别人——他们会重新评估整个团队的编制。
结果：团队从 8 人缩减到 4 人
邀功者留下来了（也许），但承担了原来 3 个人的工作量回合三（长期）：邀功者自己被替代
当他构建的 prototype 成熟到一定程度，公司需要的不再是"懂业务的工程师"，而是"能维护 AI 系统的人"——后者更年轻、更便宜、更好招。
结果：邀功者发现自己最大的贡献（那个 prototype）
变成了让自己不再被需要的证据The Atlantic 2026 年的一篇深度分析直接点明了这个逻辑："如果效率提升的结果是裁员，员工不会把最好的创新拿出来展示。" 这不是员工的道德缺陷，而是理性反应——组织无法做出"创新者不会被替代"的可信承诺时，隐藏创新就是均衡策略。
你无法阻止邀功者，也不需要
这是需要清醒面对的现实：你管不了别人。
有些人确实不在乎市场是否健康、社会是否向好。他们的博弈视野是下一次绩效评估，不是下一个五年。
但这不影响你的策略。 原因：
1. 邀功者的 prototype 通常是"how"层的展示
"我用 AI 把这个流程从三天缩短到十分钟"——这证明的是操作层的效率提升。它不包含你对系统的深层理解：为什么这个流程是这样设计的、什么边界条件下它会失败、哪些异常情况需要人类判断。
邀功者能展示的，AI 确实能做。但 AI 做不到的那部分，邀功者也没有展示——因为他可能自己都没有那些知识。
2. 当 prototype 投入真实使用时，深层问题会浮现
一个 10 分钟搭建的 demo 和一个能在生产环境中可靠运行的系统之间，存在巨大的鸿沟。管理层会在第一次事故后意识到这一点——而那个时候，他们需要的不是能搭 demo 的人，而是理解系统为什么会出问题的人。
那个人是你，不是邀功者。
3. 你的保护行为和邀功者的行为在外部不构成对比
你不是在"拒绝创新"，你也在用 AI——你只是选择了把 AI 用在不同的地方。你自动化了重复性操作、提升了代码质量、加速了测试——但你没有把核心判断逻辑交给 AI 做 demo。
从外部看，你们两个都在"拥抱 AI"。区别在于：你控制了深度，他没有。
实操策略
当同事在会议上展示 prototype 时
不要反对。不要质疑。不要表现出任何不以为然。
你可以：
- 表示认可："这个思路不错，效率提升确实明显。"
- 追问技术细节（自然地）："这个 demo 对异常数据的处理是怎么做的？如果遇到 [某个边界情况] 会怎样？"
- 这个追问不是为了让他难堪，而是为了在管理层面前自然地展示：从 demo 到生产，中间有大量他没有考虑到的事
当领导要求你也做类似的 prototype 时
做。但选择你愿意被自动化的工作来做。
好的选择：自动化你的测试流程、自动生成报告、加速数据处理 危险的选择：用 AI 复现你的架构决策过程、展示 AI 如何替代你的代码审查判断
原则不变：how 可以自动化，why 不做 demo。
当邀功者的 prototype 被推广到团队时
参与推广。甚至帮助改进它。但在改进的过程中，你自然地成为了理解这个系统局限性的人。你知道它在哪里会出问题，你知道什么情况下需要 fallback 到人工——这些知识让你在系统运行后比邀功者更不可替代。
心态校准
邀功者让你焦虑，是因为你在用同一个维度衡量你和他——"谁在 AI 方面表现更积极"。
换一个维度：谁的价值更难被复制。
一个能在十分钟内搭建 demo 的人，市场上有很多——因为 AI 工具降低了这个门槛。一个知道"这个 demo 在什么情况下会出问题、为什么出问题、以及怎么修"的人，市场上很少——因为这需要真实的系统经验。
不要和邀功者比赛谁跑得更快。你们不在同一条赛道上。
本节总结
| 维度 | 邀功者 | 你 |
|---|---|---|
| 短期绩效 | 好看 | 正常 |
| 在管理层的形象 | "拥抱创新" | "稳定可靠" |
| 实际在做的事 | 证明工作可以被自动化 | 正常工作 + 保持深度 |
| 12 个月后的处境 | 团队缩编后，承担 3 倍工作量或被更便宜的人替代 | 在系统出问题时被需要 |
| 自身被替代的难度 | 低——他展示的 demo 别人也能搭 | 高——你的价值在判断层 |
邀功者不是你的敌人。他是一个正在犯战略错误的人。你不需要阻止他，你只需要不跟着犯同样的错。