本篇要回答的问题：为什么团队效率会有天壤之别？共识到底分几个层次、怎么达成，又为什么说"架构过程本身就是团队共识形成与确认的过程"？
上一讲从宏观视角点明，"团队分工与协同"是贯穿软件工程始终、与架构师密不可分的基础问题。本讲深入其中最根本的一环——共识管理。软件工程是团体活动，团队靠共识上下同心；而共识不仅是管理话题，更直接关系到架构（接口/规格就是最精确的共识表达）。
团队共识：从团伙到团队
团队靠共识上下同心。共识分很多层次：
| 层次 | 内容 |
|---|---|
| ① | 是否有共同的目标 |
| ② | 是否有共同的行事做人准则（价值观） |
| ③ | 对产品与市场要与不要、为什么是否一致 |
| ④ | 对执行路径有没有共同认知 |
| ⑤ | 有没有团队默契，沟通能否一点即透 |
关键判断：缺乏共同目标的团体最多算"团伙"，不能称团队。共识大于能力——一个人能力很强却与团队没有共同愿景/价值观，能力越大破坏性越大。
关于目标与愿景：
- 企业谈使命与愿景，是因为它是团队存在的意义、所有人的长远目标。
- 人是愿景型动物，需要看到未来；越高级的人才越在乎团队存在的意义。所以对高科技人才只能去影响，而非控制。
- 愿景是一种心力：一旦相信使命愿景，员工就有强烈使命感与原动力。
- 但"道不同，不相为谋"——相同的价值观这种更根本的基础共识，可能成为压垮团队的稻草。
怎么达成共识？
关键判断：越"聪明"的团队负责人越容易低估达成共识的难度。常见错误是开个会、把自己想法讲一遍，半小时后大家迷茫地回去。
| 团队规模 | 简单共识（开会传达）是否有效 |
|---|---|
| 还小时 | 可能奏效——负责人能一一检查、及时纠偏 |
| 稍大后 | 突然失效，负责人困惑"我明明告诉他们了" |
更好的方式：让更多人参与到决策形成的现场——通过同步充分信息、用共创而非传达的方式让结论自然产生。共创不必全员参与，但要确保所有影响落地的关键角色都在，且都能产生思想碰撞，而非做"吃西瓜群众"。
契约与共识效率
共识达成还不够，还要表达出来、形成文字。因为共识不是口号，而是指导战略选择与日常行为的依据。
共识就是团队协作的契约。契约的表达越精确无歧义，主观能动性越高，执行效率越高。
架构过程同样如此——架构过程实际上是团队共识形成与确认的过程。架构设计要回答两个问题：系统要做成什么样？怎么做？
| 概念 | 对应 | 关系 |
|---|---|---|
| 设计 | 系统要做成什么样（规格） | 设计高于架构 |
| 架构 | 怎么做（实现） | —— |
规格设计是架构过程的最高共识，规格高于实现。 用架构的全局性和系统性思维去做设计。
架构图 vs 接口，谁更精确：
| 表达方式 | 是否精确无歧义 | 定位 |
|---|---|---|
| 架构图 | 不精确 | 只是辅助，说明模块接口之间的关联 |
| 模块接口（代码表达） | 精确、无歧义 | 更精确描述架构的方法 |
洞见：不精确的架构很可怕，会导致不同模块"牛头不对马嘴"，风险被掩盖到最后里程碑临近才暴露，人们动作走形、只顾打补丁。这就像建筑师只画了张没有尺寸和关键细节的效果图，大家分头开工，最后拼接全靠老天爷。
进一步：概要设计阶段最好的状态不是只有设计文档——
为降低风险，系统设计阶段也应该有代码产出：① 系统的初始框架代码（架子搭起来）；② 原型性代码验证（核心子系统提供 mock）。好处是一上来就关注全局系统性风险的消除，并给每个子系统负责人更具象、确定的认知。代码即文档，代码是理解一致性更强的文档。
总结
团队效率高低的"根因中的根因"是共识管理。共识分多层次（目标/价值观/产品取舍/执行路径/默契），层层不可替代，哪层出问题就在哪层解决。达成共识要靠共创而非传达，并形成精确无歧义的文字契约。对架构而言，架构过程就是共识确认的过程——设计高于架构、规格高于实现，用代码表达的接口比架构图更精确，概要设计阶段就该有框架代码与 mock 产出。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| 团队共识 | 团队上下同心的基础，分目标/价值观/取舍/路径/默契多层 |
| 共识大于能力 | 没共识的强能力者，破坏性随能力增大 |
| 共创 | 让关键角色参与决策现场，让结论自然产生（非传达） |
| 契约 | 形成文字的共识，越精确无歧义执行效率越高 |
| 设计高于架构 | 规格（做成什么样）高于实现（怎么做） |
| 代码即文档 | 接口用代码表达最精确，概要设计也应有框架/ mock 代码 |
一句话速记
团队效率的根因是共识，共识要靠共创达成、靠精确无歧义的文字（接口代码）固化——架构过程就是共识确认的过程，设计高于架构、规格高于实现，架构图远不如接口精确。
几条值得记住的判断
- 共识大于能力；缺共同价值观的强者破坏性最大。
- 聪明的负责人最易低估达成共识的难度，开会传达≠共识。
- 架构图不精确，用代码表达的接口才是最精确的共识契约。
思考题
回想你团队最近一次"联调时才发现对不上"的事故：根子是技术实现错了，还是当初的共识根本不精确（只有架构图/口头约定、没有用接口代码固化）？如果概要设计阶段就先写出框架代码和 mock，这个风险会不会被提前暴露？
