浅谈通用技能 09：决策能力 —— 带团队+信息不足时，如何做决策

背景

当个人独立负责一个项目时，我们可以发挥单agent最强能力，无任何信息沟通/切换损耗。
但当个人要撬动更大的资源，开始协同/带团队时，就不得不面临项目管理、判断、决策的事情，把个人的认知杠杆，撬动团队资源来落地。
3年前分享时说，当公司中个人的level越高，决策出错的造成的后果就越大。因此多场景下的决策能力，是一个通用的技能，值得好好学习与研究。

本文主要基于最近的实际案例，介绍一下个人视角，尽可能做【正确的】决策，避免方向性的错误。

写作时间：2026年10月12日 22:44:28
写作时长：30min

结论

1、摸清现状：尽可能收集一线的上下文，系统实际用一下、看下代码、收集一下反馈。让真实客观的信息进入自己的上下文，不仅仅局限于开会听的汇报。
2、看清未来：调研业界、关注一下实际的发展趋势。不关注业界，除非你有领先业界的自信。
3、分工盘点：拆解目标，大方向划分，绑定责任人，让每个方向能并行独立运转起来。（技术责任人、业务责任人）。
4、快速试错：无法决策时，快速mvp验证，快速运转起来，结合实际的效果review。
5、决策因素：收益、成本（ROI）、是否可逆、
6、决策人：1）谁承担结果，谁决策，不能拍完让执行的人扛。2）谁最接近问题，谁决策。

附录

附录1：故事来源

讲一个小故事。

某一天，团队A 的老板说我们把当前的AI嵌入我们的工作流，做一个自动运转的系统，来解放大家的工作。这个项目在当时的背景下很不错，因为解放人力本质上是提升生产力，有一定的进步意义。

该团队存在3个业务方向，每个方向本质上都遵循一套共同抽象的工作流Z来开展工作，区别在于具体的业务场景，实现细节略有不同。于是老板基于Z 定义了一套抽象的工作流，约定了几个Agent来大家实现。

各个方向的同学开始各自实现了，部分方向更早有过demo雏形因此进度较快，部分方向从0开始，整体进度不一，基于的框架也各不相同。一段时间后，由于可能存在潜在的重复造轮子，整体项目进度也无法较好向上阐述。于是此时老板提出需要在现有的逻辑上我们需要统一架构，便于向上汇报进展。

此时开始了现有架构的合并盘点，架构A：vibecoding+多人协作+专注于代码实现功能逻辑可控。架构B：业界开源sdk + 单人开发 + 通用抽象层 + 高扩展。两者都实现了MVP版。为避免后续的重复建设（节省0.5-1人力），因此老板决策走方案A。原方案B业务逻辑迁移到方案A，方案A的多人协作+1。

架构统一后，大家开始了协作开发，有新的想法快速上线，为了避免影响他人的代码加了一些if else，追求快速实现，目标变成在DDL前交付mvp demo为最高优先级。

这个项目最终的演进如何？未完待续...

附录2：有哪些启示？

1、【团队负责人】团队负责人应该是的对方向的判断最敏感的人，因为岗位决定了信息最为集中，不用过多关注执行。可以更关注于：业界发展趋势、方向的决策正确性、bad case是否有返工人力浪费的情况。
2、【职场汇报】职场组织形态遵循金字塔原理，蕴含的隐藏逻辑是，工作产出也需要按金字塔向上汇报。（反之，如果你的工作不值得向上汇报，那投入的价值在职场的意义上就会比较低）。
3、【vibecoding 】AI项目实现成本：问题/目标定义成本，方案设计成本，开发测试成本，运维迭代成本。AI只缓解了开发测试成本，但没有解决其他。我们应该摒弃产品项目代码都是AI写的，没什么难度这一点。其他因素决定了项目的最终发展的高度。
4、【团队协作】一个项目应该只有一个技术负责人，负责架构定义，模块拆解，
5、【运营价值】AI时代，AI agent越来越成为一个合格的执行者的背景下，执行价值变低，因此原本不过多关注技术细节的运营角色，反而能撬动更大的资源杠杆了，焕发了第二春。

附录3：AI的案例分析结论

RACI矩阵：RACI要求每个任务节点都有明确的A（Accountable，最终批准者）和R（Responsible，执行者），A不仅拥有最终决策权，更承担最终后果。
Gartner的研究明确指出，AI驱动的代码生成在加速开发的同时也在加速架构债务。当团队为了赶DDL不断加if else时，他们实际上正在穿一道伪装的单向门——代码结构一旦以if else的方式固化，后续重构的成本远高于当初加if else的成本。
红杉资本文章中描述的“成功剧场”现象：每一层级都是一个信息过滤节点，一线员工向主管汇报时会过滤掉让自己难看的部分，主管向上级汇报时再次过滤，最终呈现在决策者面前的是一份精心策划的结果。“统一架构”本质上是信息过滤后的产物——真实的信号（框架不统一导致协作困难、迁移成本被低估、团队对方案B的认同度）在传递中被衰减了。
案例中架构A和B的选择完全可以纳入一个类似的评分模型：可扩展性、协作效率、迁移成本、长期维护成本、团队熟悉度等维度各打一个权重分。即使最终仍然选择方案A，至少决策依据是可追溯、可复盘的。
决策模型：OVIS。给决策里每个人贴角色标签：1）Owner：最终拍板，也背锅。 2） Veto：能一票否决。 3）Influencer：能提建议，但不能拍板。 4） Support：负责干活支持。作用：避免“老板拍板，团队背锅”。
ADR：架构决策记录。就是一页纸写清楚：当时为什么选 A 不选 B，背景是什么，后果是什么。以后新人复盘有依据。