用 AI 减少协作磨损：四个实操

最近实践思考，AI 真的能帮团队做熵减。说说我的实操吧。

01建立团队的共享 context，用 AI 来解决"人力记忆短板"，减少信息的熵增

注意是 context，而非知识库。主动去构建 AI 容易理解、消费和维护的 context，而不是把各种结构化和非结构化数据扔到一起，给个"xx 知识库"就行。尽量减少 AI 的认知磨损。

大家经常讨论 AI 的记忆错乱和上下文窗口不足的问题，其实这些能力限制，在人身上也有，特别是在复杂环境、多线程、变化和迭代高频的业务场景中。精准、及时的信息是稀缺要素，但又是协作的必要条件。有意识地做 context 管理，重要的是 schema 设计和管理，本质还是业务和组织设计。

有意识地建设服务团队的共享 skills、tools、prompt；形成团队 cowork 的 agent assets。对复杂的 prompt 和 context 要有意识地结构化梳理，降低未来的维护和调用成本。

02鼓励一种新的 mindset，叫"我当自己什么都不知道"

很多时候，大家害怕承认自己不知道，希望在自己的领域展示非常"专业"的一面，这种包袱是非常不利于组织的 AI-Native 的。我鼓励大家在拿到一个 task 的时候，先把自己放在一个"一无所知"的位置，去和世界领先的模型（譬如 Opus 4.7、Gemini 3.1 Pro）先聊聊，学会和 AI 从 0 到 1 开始就 copilot，先 ideas、然后是 how。在这个过程中多用开放性提问来榨干模型的世界知识——通过在 prompt 里加入对应领域头部专家的思维模型、核心书籍的方法论要求，来把自己放在一些顶尖思维模型的角度补充视角。

03判断力和 ownership 训练，创造"决策力"和"评估力"

给团队同学松绑，他们不需要和 AI 拼劳动力密集度和执行效率，他们要有讲清楚需求和目标的能力、设计 evaluation 的能力、要用 ownership 去推动 workflow 跑起来的 mindset。不要把自己当执行者，而是一个 CEO。站在一个对全局目标负责的视角来制定评测的 framework，判断模型的结果是否满足业务预期。学会提出关键问题，让 AI 来解决。

譬如让人去横向评估多个模型在复杂的长文本、多段式的产出，一次评估要看至少一千多字，需要横向对比多个一千多字的差异，对比维度是多维——在我看来这个评估任务就已经不是靠人的记忆能力就能搞定的。但是符合业务应用场景的 evals 需要人的输入和 copilot：具体考核哪些维度、用例和测试集、ground truth 是要人确定的。

04把开会讨论变成开"取舍"和"共识"会议

一个命题落地通常只需要开三次短会：

第一次是"命题"，即对清楚背景和目标，要解决什么问题，定位核心问题，哪些需要特别关注。然后大家回去各自和 AI 讨论、提供解题思路、补充利弊。

第二次是"取舍"，仅作"共识"和"路径取舍"讨论。会议前，大家已经和 AI 讨论清楚各种可行方案和利弊得失，会议上仅做"取舍"判断和"共识"。

第三次是"效果验收和迭代"，基于目标和路径的执行情况、出现的问题、bad case 提供给 AI 做分析、reflection、迭代，提出新的需要解的命题，再往下就是循环这三步。

然后每次开会都会用 AI 听记和总结，人进去最多把写错的负责人花名改改、不重要的事项删一删、时间 deadline 确认一下，大部分 AI 总结的 action 和共识是非常到位的。

反正最近这套逻辑实践下来，开会效率高了不少，会议质量也高了不少。