为什么你不应该把所有 Skills 共享给团队 • Yucheng (YC)'s Blog

“知识共享”听起来是个不需要讨论的好事。

一个人学会了，全公司受益。一个团队踩过的坑，其他团队不用再踩。这是常识，是效率，是组织智慧的积累。

但我最近开始重新思考这件事。

因为我发现，有些 skill 一旦共享出去，就会腐烂。而有些 skill，如果共享出去，会直接破坏它存在的意义。

共享的好处（我们都知道的部分）

先承认共享的价值——这不是一篇”反共享”的文章。

当一个团队花三周摸索出一套高效的 prompt engineering 方法论，把它整理成 skill 共享给其他团队，确实能节省大量时间。我见过一个增长团队开发的「Twitter 爆款分析」skill，共享给内容团队后，整个公司的 Twitter 互动率两周内涨了 40%。这是真实的效率提升。

当运营团队开发了一个自动化社区回复的 skill，让客服团队也用上，确实能提升整体效率。原本需要 3 个人盯着的社区，现在 1 个人配合 AI 就能覆盖，而且回复质量更稳定。

当我写了一个内容创作的 skill，让团队其他成员也能产出相似质量的内容，确实能解放我的时间。以前我是内容瓶颈，所有文章都要过我的手。现在初稿可以并行产出，我只需要把关最后一道。

这些都是真的。共享有价值，很多时候是对的选择。

但不是所有时候。

问题一：Context 腐烂（Lossy Compression）

一个 skill 刚被创建时，它是为特定场景、特定团队、特定问题设计的。它”懂”那个 context。

我来讲一个真实的故事。

我们增长团队开发了一个「冷启动社区运营」的 skill。它非常好用——知道什么时候该活跃气氛，什么时候该冷处理，什么样的问题要认真回答，什么样的问题要引导到私聊。这个 skill 是基于我们社区的调性、我们用户的画像、我们产品的特点打磨出来的。

然后产品团队说：我们也想用这个 skill 来运营用户反馈群。

好，共享。

但产品团队的群不太一样。用户画像不同，提问方式不同，期待的回复风格也不同。他们开始提需求：「能不能把这里改得更正式一点？」「能不能加一个处理技术问题的模块？」「我们的用户不喜欢太活泼的语气。」

我改了。Skill 变得更”通用”了。

然后客服团队也想用。他们的场景又不一样——要处理投诉、要安抚情绪、要遵循特定的话术规范。又一轮修改。

三个月后，我回头看这个 skill，已经认不出它了。

它变成了一个「适用于大多数社区场景」的东西。听起来不错？但问题是：它对任何一个具体场景都不够好。增长团队说「感觉没以前好用了」，产品团队说「还是差点意思」，客服团队说「很多地方要手动调」。

一个原本锋利的工具，被打磨成了一个圆润的、无害的、平庸的通用品。

这就是 context 腐烂。

这和组织信息传递中的 lossy compression（有损压缩） 是同一个问题。在金字塔结构里，信息每经过一层就被压缩一次——交易谈判的数小时电话变成 CRM 状态变更，架构辩论的白板争论变成一张 JIRA ticket，走廊里触发产品转向的随口一句变成什么都没有。信息在传递中不断失真。

Skill 的泛化是同样的机制：每次适配一个新场景，就是一次有损压缩。原本针对「我们团队、我们客户、我们产品」设计的精确判断，变成「大多数团队、大多数客户、大多数产品」的模糊指南。

一把为日本料理设计的刀，被要求同时适合切牛排、剁骨头、削水果——最后它什么都能做，但什么都做不好。

泛化的代价是精度。而精度往往才是 skill 有效的关键。

更糟糕的是，一旦开始泛化，就很难回头。因为现在有多个团队依赖这个 skill，任何「退回到更专用版本」的尝试都会引发兼容性问题。你被锁死在「最大公约数」的陷阱里。

问题二：数据泄漏

这是更微妙但更致命的问题。

机器学习领域有个基本原则：训练集、验证集、测试集必须严格分开。如果测试数据泄漏到训练过程中，你的模型看起来表现很好，但那是假的——它只是”记住”了答案，而不是真正学会了。

我在管理团队时发现了完全相同的现象。

例子一：Code Review

我有一套 code review 的 skill。它知道我关注什么——命名规范、边界条件处理、错误信息的可读性、代码的「可删除性」（能不能在未来轻松移除这段代码）。它知道我会在哪些地方挑毛病，什么样的代码能过关什么样的不能。

我从来不把这个 skill 共享给开发者。

为什么？

因为如果我把 code review skill 给他们看，他们就知道了”测试标准”。他们会开始针对这个标准来写代码。

表面上看，代码质量会”提升”——因为提交上来的代码都能通过我的 review 了。但这是假的提升。

他们不是在写更好的代码，他们是在写”能通过 review 的代码”。这两件事听起来像是一回事，但不是。

真正好的代码来自于工程师自己理解什么是好代码，自己形成判断力，自己长出 taste。如果我把评判标准直接告诉他们，我就剥夺了他们形成自己判断力的机会。

例子二：内容审核

我有一个「内容质量评分」的 skill，用来评估团队产出的文章、推文、视频脚本。它会从多个维度打分：信息密度、原创性、可读性、传播潜力。

我不会把这个 skill 给内容团队看。

原因一样：如果他们知道评分标准，他们会开始「针对评分写内容」。

我见过这个现象。有一次我不小心透露了「我很看重开头 50 个字的 hook」，接下来两周，所有人提交的内容开头都变得很精彩——但正文质量下降了。他们把精力都放在了「我知道你会看的地方」，而忽略了其他部分。

例子三：招聘评估

我有一套评估候选人的 skill。它知道我看重什么——不是简历上的光鲜经历，而是思考问题的方式、面对未知的态度、表达的精确程度。

如果我把这个 skill 共享给 HR 或者猎头，会发生什么？

他们会开始筛选「看起来符合这些标准」的候选人。候选人也会开始准备「如何表现得符合这些标准」。

然后我的评估就失效了。我看到的不再是真实的人，而是「针对我的标准优化过的表演」。

这其实就是 Goodhart’s Law（古德哈特定律） 在组织管理中的体现：当一个指标变成目标时，它就不再是一个好的指标。

我的 code review skill 是一个「指标」——它衡量代码质量。一旦我把它共享给开发者，它就变成了「目标」——他们会针对这个标准优化。然后这个指标就失效了——它不再能区分真正好的代码和「会通过 review 的代码」。

内容评分、招聘评估，同理。

测试的有效性，依赖于被测试者不知道测试标准。这不是故意刁难，这是测试本身的逻辑。

什么时候应该共享：Information Bus vs Local Pods

并不是所有 skill 都有这个问题。关键是区分哪些知识应该放在「共享总线」上，哪些应该保留在「本地 pod」里。

适合放在 Information Bus 上的 skill（可以共享）：

纯工具型：怎么用某个 API、怎么配置某个环境、怎么跑某个流程。这些是「事实」，不会因为更多人知道而贬值。你知道怎么调用 OpenAI API，告诉别人，他也会了，你的知识没有任何损失。
知识沉淀型：踩过的坑、最佳实践、操作手册。「我们试过 X 方案，失败了，原因是 Y」——这种知识共享出去只有好处。没有人会因为知道这个而「优化」出什么问题。
效率提升型：自动化脚本、模板、prompt 库。「这个 prompt 可以让 Claude 写出更好的技术文档」——共享它，大家都写出更好的文档，皆大欢喜。

这些 skill 共享出去，价值就是增加的。它们是「事实性知识」，没有”泄漏”风险，也不太容易因为泛化而腐烂（因为它们本来就不太依赖特定 context）。

应该保留在 Local Pod 里的 skill（不该共享）：

评判型：code review、内容审核、质量把关、绩效评估。这些 skill 的价值在于「被评判者不知道评判标准」。一旦标准公开，评判就变成了「合规检查」——你只能检查是否符合已知标准，而无法发现真正的问题。
决策型：优先级判断、资源分配、方向选择。这些 skill 高度依赖 context——当前的市场环境、团队状态、竞争格局。把它们泛化成「通用决策框架」，往往会丢失最关键的判断依据。
培养型：任何你希望对方「自己学会」而不是「照着做」的东西。好的导师不会把所有答案直接告诉你，而是创造让你自己发现答案的环境。把「如何做判断」直接告诉别人，就剥夺了他们「学会判断」的机会。

这些 skill 一旦共享，要么会腐烂（因为评判标准是 context-dependent 的），要么会造成”数据泄漏”（因为知道标准会改变行为）。

这和组织架构里「什么信息应该全局共享，什么信息应该局部保留」是同一个问题。一个健康的组织不是「所有人知道所有事」，而是「对的人知道对的事」。信息的价值有时候恰恰在于它的「局部性」——只有特定的人在特定的时候知道。

一个反直觉的结论

效率的最大化，有时候需要信息的不对称。

这听起来很政治不正确。我们不是应该追求透明、开放、知识共享吗？硅谷文化不是鼓励「radical transparency」吗？

但仔细想想：

考试为什么不提前公布答案？ 因为考试的目的是测试你是否「学会了」，而不是测试你是否「能找到答案」。公布答案会让考试失去意义。
为什么盲测比公开测试更可信？ 因为当被测试者知道自己在被测试时，行为会改变。药物临床试验要双盲，用户研究要做 A/B 测试而不是直接问用户，都是这个道理。
为什么好的教练不会把所有技巧一次性告诉你？ 因为技巧是要「长」在身体里的，不是「记」在脑子里的。告诉你「挥拍时手腕要这样转」没用，你需要自己挥一千次拍，然后在某一次突然「悟」到。
为什么师傅带徒弟要「留一手」？ 传统观点认为这是自私，但另一个解释是：有些东西说出来就「不灵」了。徒弟需要自己去悟，师傅能做的是创造悟的条件，而不是直接给答案。

有些知识，你知道得太早，反而会阻碍你真正学会它。

有些标准，你知道得太清楚，反而会让你学会”应付标准”而不是”达到标准”。

有些 skill，它的价值恰恰在于不被共享。

透明是好的，但透明不等于「所有信息对所有人开放」。透明是指「规则公开」，不是指「答案公开」。

我的做法

现在我会把 skill 分成两类：

公开 skill（放在共享库）

所有工具使用指南
技术栈配置和部署流程
踩坑记录和解决方案
通用 prompt 模板
自动化脚本

这些 skill 任何人都可以用，鼓励大家贡献和改进。它们是组织的「公共基础设施」。

私有 skill（仅特定角色可见）

我的 code review skill：只有我用。开发者提交代码，我用这个 skill 辅助 review，但他们不知道我具体看什么。这保证了 review 的有效性。
内容质量评判 skill：只有我和主编用。内容团队知道「会有质量评估」，但不知道具体评估维度。这让他们专注于「写好内容」而不是「通过评估」。
招聘评估 skill：只有面试官用。HR 和猎头知道我们在找什么类型的人（这是公开的），但不知道面试中具体评估什么（这是私有的）。
优先级决策 skill：只有管理层用。团队知道「有一套优先级框架」，但具体权重和判断逻辑不公开。这避免了「所有需求都被包装成高优先级」的博弈。

这些 skill 的价值，恰恰在于被评估的人不知道评估标准，被决策影响的人不知道决策算法。

这不是在搞信息不对称的权力游戏。这是在保护一个系统的有效性。

写在最后

“知识就是力量”这句话有个前提：是你自己获得的知识。

被直接”喂”进来的知识，和自己摸索出来的知识，价值是不一样的。前者是信息，后者是能力。

一个开发者读了我的 code review skill，他获得了「信息」——他知道我会看什么。但他没有获得「能力」——他不知道为什么这些东西重要，不知道在新的场景下该怎么判断。

真正的能力是「可迁移的」。它不是一套规则，而是一种直觉，一种 taste，一种「看一眼就知道对不对」的感觉。这种东西没法通过共享 skill 来传递，只能通过自己去试、去错、去悟来获得。

有些 skill，最好的共享方式，是让对方自己也长出一套——而不是直接把你的给他。

下次你想把一个 skill 共享给团队的时候，先问自己两个问题：

1. 这个 skill 共享出去，会不会因为泛化而腐烂？

如果它高度依赖特定 context，共享可能会毁掉它。

2. 这个 skill 共享出去，会不会造成「数据泄漏」？

如果它是一个评判标准，公开它可能会让被评判者学会「应付」而不是「达标」。

如果两个问题的答案都是「会」，也许保留它，才是真正对团队好的选择。

知识共享是好事。

但不是所有知识都应该共享。

最稀缺的知识，往往是那些一旦共享就会失效的知识。