怎么用它做项目分析

这套知识库的定位是讲判断、成本和误区，所以它天然适合当分析工具，而不是功能清单。最常见的三类用法是立项评审、老项目盘点和事故复盘。三种用法共享同一套动作：把玩家路径翻译成状态和链路，再对照各章检查能力缺口。

项目分析的基本动作

• 先画玩家的核心行为路径：从登录到一次完整的玩法闭环，标出每一步经过的系统。
• 沿这条路径列出涉及的状态，并区分运行时状态、长期资产和派生数据。
• 划分主链路和外围链路，标出每段的延迟、一致性和恢复要求。
• 对每一段问失败代价：错了影响什么，恢复要多久，能否审计和补偿。
• 拿这些问题对照主线章节，找出哪一层没有对应能力承接。

这套动作的产出不是架构图，而是一份带失败代价的状态清单。多数项目的第一份清单做完，主问题通常就自己浮出来了。

每个动作对应哪些章节

• 画玩家路径：主要对照问题模型，确认主行为和主成本落在哪里。
• 列状态清单：对照数据建模里的运行时状态、长期资产、派生数据分类。
• 划分链路：对照主链路和外围链路的划分方法。
• 问失败代价：对照可观测性、版本发布里关于恢复和回滚的判断。
• 找能力缺口：对照服务拆分、缓存与中间件、通用服务等各章的适用条件。

分析时要带的几个判断问题

• 这份状态谁权威，出现争议时以谁为准。
• 这条链路挂了，玩家看到什么，运营看到什么。
• 这次变更怎么回滚，多久能生效。
• 这个故障恢复要多久，能不能自动化。
• 这类问题的证据现在存在哪里。

这些问题多数能在对应章节找到展开。分析时引用它们，比自己临时发明标准更容易对齐团队。

立项阶段怎么用

立项阶段最有价值的一步是逼出问题模型：这款产品的主链路落在哪，哪些状态一旦出错直接伤商业结果，哪些约束来自平台和渠道。此时不需要读完全部章节，通常总论、问题模型，加两三个针对性章节，就够支撑一次立项评审。

盘点老项目怎么用

老项目盘点的重点不是找“哪里不先进”，而是找结构性缺口：权威状态是否清晰，配置变更有没有校验和灰度，控制平面是否存在，可观测性是否覆盖主链路，运营动作有没有审计和回滚。这些检查项在主线各有对应章节，逐项过一遍，往往比通用的架构评审更容易落到具体动作上。

事故复盘怎么用

复盘是反向使用：从症状出发逐层问，这个现象本该在哪一层被拦住。是时间模型没统一，是状态边界混乱，是观测缺证据，还是流程缺审批。复盘结论如果能落到“补哪一层的哪种能力”，就比“下次注意”有用得多，也更容易进入排期。

常见的分析切入顺序

两种切入都常见。从最痛的事故切入，动力强、见效快，但容易只修痛点；从主链路正推，覆盖全、结构好，但容易停在纸面。常见做法是两者结合：先正推出主链路和状态清单，再用最近几个月的事故去校准优先级，让清单既有结构又有痛感。

分析结果最好长什么样

• 一页主链路描述：玩家路径、状态清单、每一段的失败代价。
• 一份缺口清单：每一条注明属于哪一章的问题域，以及当前靠什么兜底。
• 一组待验证判断：哪些结论只是推测，需要什么数据来确认。

写成这个形态，分析结果才能被排期和跟踪，而不是停留在会议纪要里。

团队一起用时的分工

分析最好由两三个不同方向的人一起做：熟悉玩法路径的，熟悉服务端状态的，熟悉线上运行的。知识库提供共同语言，让“你说的卡是哪一段”“这个状态谁说了算”这类分歧能被具体化，而不是各说各的形容词。

分析结论怎么保持有效

项目分析不是一次性的。版本大改、玩法上新、进入运营期、平台规则变化，都会移动主链路和失败代价的落点。把分析结果当成随版本维护的文档，而不是一次性交付物，它才有长期价值；归档那一刻，通常就是它开始失效的时刻。

常见误区

• 把项目分析做成逐章打分，产出“哪章没做好”，而不是问题清单。
• 只盘技术栈不盘状态和链路，结论落不到任何架构动作上。
• 复盘只追直接原因，不检查缺失的能力层，同类事故换个皮肤再来。
• 分析一次就归档，不随版本和运营阶段更新，清单很快失效。