SSOT：为什么所有软件工程原则最终都在谈同一件事
SSOT：为什么所有软件工程原则最终都在谈同一件事
复杂业务、AI-native 生产力和高速迭代会让团队资产天然分裂。SSOT 九层金字塔模型让 AI agent、产品、运营、销售、客服/支持和研发共享同一个最新决策快照。
SSOT：为什么所有软件工程原则最终都在谈同一件事
如果今天让一个新人，或者一个刚进入仓库的 AI agent，回答“这个产品现在最核心的能力是什么”，它会从 README、路线图、测试、日志、发布记录和对外文案里得到同一个答案吗？
再换一个视角：如果产品、运营、销售或客服/支持同事今天要回答客户“这个能力现在能不能承诺”“这个功能是不是主线”“这次发布到底验证了什么”，他们能不能从同一个事实入口得到答案？
如果答案是否定的，团队真正的问题就不是文档不够多、测试不够多、架构图不够新，而是事实已经分裂。
我越来越认为，软件工程里最重要的原则只有一个：SSOT，Single Source of Truth，单一事实来源。
很多原则看起来不同：DRY、KISS、SOLID、模块化、领域建模、测试金字塔、可观测性、CICD、文档治理。它们分别作用在代码、架构、测试、发布、协作和组织流程上。但如果继续往下归并，会发现它们其实都在处理同一个问题：
当系统变复杂时，团队到底应该相信谁？
DRY 不是单纯“不要复制代码”，而是不要让同一个事实散落在多个地方。
KISS 不是拒绝复杂业务，而是让事实路径足够短，短到人和 AI 都能判断当前应该相信哪里。
SOLID 不是类设计教条，而是让责任边界稳定，避免一个模块同时持有多类事实。
领域建模不是画概念图，而是让业务概念不再散落在页面、接口、数据库、脚本和人的记忆里。
测试不是为了“多跑一些东西”，而是让行为预期有可执行的事实来源。
可观测性不是堆日志，而是让线上状态有可追溯的事实来源。
CICD 不是自动化炫技，而是让一个版本能否合并、能否发布、是否已经上线，有统一的判断来源。
所以 SSOT 不是“多写一个总文档”。它是所有工程原则背后的元原则：每一种重要事实，都必须有唯一权威位置、清晰维护责任，以及足够证据证明它仍然成立。
复杂系统一定会变成令出多方
小系统可以靠人的记忆运行。几个人坐在一起，大家都知道哪个接口能用，哪个页面是旧的，哪个脚本只是临时方案，哪个测试可以忽略。
但业务系统只要持续迭代，人的记忆很快就会失效。
我们可能每个月都重新造一次轮子，三个月后完全忘记以前造过。不同团队成员可能都解决过同一个问题，只是留下了不同实现、不同文档、不同脚本。某个历史阶段为了一个特殊场景做过专门设计，后来业务变了，但代码、测试和说明还留在系统里。
时间一长，系统就不是“没人写文档”，而是“每个地方都有一点文档，但没有一个地方能负责当前事实”。
AI-native 时代会把这个问题放大。
AI 每天可以生成大量架构设计、代码、测试、运行日志、会议纪要、对外宣传稿、任务总结。这些材料本身都有价值，但如果没有事实归属，它们会迅速变成新的噪音。
更麻烦的是，今天所有人都在被迫变成某种意义上的全栈人才。工程师需要理解产品、设计、运营、发布，甚至商业策略。业务决策必须一路传导到工程实现；产品、运营、研发必须跟随战略变化保持一致。
在这种环境里，真正稀缺的不是“更多内容”，而是“哪个内容算数”。
这不是开发团队内部问题
很多团队会把 SSOT 理解成“工程师把文档写清楚一点”。这个理解太窄了。
对 AI agent 来说，SSOT 是行动边界。AI agent 不像老员工一样知道哪份方案是三个月前的，哪条 README 只是临时迁移记录，哪个测试虽然还在跑但只保护 legacy 路径。它会把能读到的内容都当成 context：旧战略、新代码、过期日志、未关闭任务、半成品会议纪要、对外宣传稿，都会被放进同一个推理空间。
如果这些材料没有明确的事实归属，AI agent 就会做三类危险的事：
- 把 legacy 能力当成当前主线，继续补文档、补测试、补自动化。
- 把 POC 当成已承诺能力，生成过度包装的方案或营销文案。
- 把不同阶段的“当前重点”综合成一个看似合理、实际错误的执行计划。
这不是 AI 不够聪明，而是团队没有告诉它“应该相信谁”。
对非开发同事来说，SSOT 是协作入口。产品同事需要知道什么是当前战略，运营同事需要知道哪个 workflow 可以真实执行，销售同事需要知道哪些能力可以对外承诺，客服/支持同事需要知道用户问题应该进入哪条日志、哪份 evidence、哪条修复路径。
如果这些答案散在不同文档里，非开发同事就只能靠口头同步、最近一次会议、某个看起来更新的页面，或者某个工程师的即时回答来判断。短期看这很快，长期看它会制造更多分裂：对外承诺和工程现实开始分叉，运营流程和产品状态开始分叉，客户问题和日志证据开始分叉。
所以 SSOT 不是“研发文档治理”，而是让 AI agent、产品、运营、销售、客服/支持、发布 operator 和研发共享同一个事实系统。
决策不会自动穿透所有资产
团队经常会调整产品重心：某个能力不再是核心，某个新方向开始变得重要，某个实验被证明值得继续投入，某个旧模块开始进入 legacy 状态。
问题是，这些决策不会自动穿透到所有地方。
一次产品重心切换之后，文档、代码、测试、日志、接口命名、错误文案、发布说明、对外宣传、会议纪要，不可能一夜之间全部把“核心产品功能”的表述改掉。于是系统里会同时存在大量只适用于不同历史阶段的表述：
- 有的文档认为 A 是核心能力。
- 有的代码路径已经开始服务 B。
- 有的测试还在保护旧的 A。
- 有的发布证据开始验证 B。
- 有的营销文案仍然在讲 A。
- 有的 AI agent 读到旧文档后，继续按 A 的逻辑工作。
这才是复杂系统里最真实的混乱来源：不是团队没有决策，而是决策没有层层穿透到产运研的所有工作内容里。
明确的重新定位还算好的。比如团队正式决定“产品核心从 A 切到 B”，至少大家知道要迁移。更糟糕的是渐进变化：某个能力从 POC 慢慢升级为核心战略，或者某个核心能力慢慢降级成 legacy。
在这个过程中，团队所有资产会同时处在不同切面上。有的地方认为它无比重要，有的地方认为它只是实验，有的地方认为它已经不重要。
没有分层模型，团队无法盘点一个决策到底影响哪些范围。
图：团队决策如果没有通过 SSOT 层层穿透，就会在文档、代码、测试、日志、对外表达中留下不同历史阶段的互相矛盾表述。
“当前优先级”最容易制造脑分裂
一种非常常见、也非常危险的事实漂移，是各种文档里都写了“当前重点”“当前优先级”“下一阶段方向”。
README 里写一版，架构文档里写一版，某个方案文档里写一版，会议纪要里写一版，发布总结里又写一版。每一版在写下来的时候可能都是真的。但随着业务、产品、技术不断演进，它们会逐渐过期。
对人来说，这会造成阅读负担：读到一处“当前重点”，不知道它是不是最新。
对 AI 来说，这会造成更严重的问题：AI 会把所有看起来权威的文字都当成上下文。如果五份文档都写了“当前优先级”，但只有一份是最新事实，AI 很容易综合出一个看似合理、实际错误的判断。
解决方式不是禁止所有文档谈方向，而是规定事实归属：当前优先级、负责人、资源竞争，只能有一个 SSOT。其他文档可以链接它、解释它服务的稳定结构，但不能复制一份“当前重点”。当战略改变时，只改权威入口；当计划完成时，把稳定结论提升到对应层，删除或压缩过期计划。
否则，系统里的每一句“当前”都会慢慢变成未来的误导。
为什么需要 SSOT 九层金字塔模型
SSOT 九层金字塔模型存在的原因，不是为了把文档写得更复杂，而是为了强迫所有人和 AI 都按同一条逻辑理解系统、更新系统。
阅读时，SSOT 九层金字塔模型强迫你自顶向下：先从团队使命开始，理解当前战略、对外承诺、真实 Flow、领域模型、系统边界、contract，再进入具体实现和 evidence。你不能跳过战略直接解释代码，也不能用某段历史实现反向定义今天的产品方向。
产出时，SSOT 九层金字塔模型强迫你自底向上：先更新代码、脚本、数据库、自动化、测试和 evidence，再判断它是否改变 contract、边界、领域、Flow、承诺、战略，甚至使命。你不能因为写了一个 POC，就直接把它写成团队战略；也不能因为某个 legacy 模块还在仓库里，就继续把它当成当前产品事实。
SSOT 九层金字塔模型永远试图强制自己成为一个最 up-to-date 的团队 snapshot：它不是单纯的技术文档，而是对全团队业务、产品、技术决策和思考的当前快照。
更进一步说，金字塔模型是在强迫人和 AI 对所有进入思考范围的事务和概念做优先级排序。
- 只是一个脚本？
- 是一个 POC？
- 是候选能力？
- 是内部工作流？
- 是用户承诺？
- 是当前战略？
- 是团队使命的一部分？
- 还是已经降级成 legacy？
只要这个问题没有回答清楚，代码、文档、测试、发布和对外表达就一定会漂移。
金字塔给不同角色的解法
九层金字塔不是要求所有人都变成架构师。它的作用恰恰相反：让不同角色不用猜，也不用读完整个仓库，就能知道自己该从哪一层进入系统。
| 角色 | 最容易被什么误导 | 九层金字塔提供的解法 |
|---|
| AI agent | 把所有可读文本都当成同等权威 context | 先自顶向下读取使命、战略、承诺、Flow，再进入 contract、实现和 evidence |
| 产品同事 | 把某个历史方案当成当前产品方向 | 用 L1-L3 判断长期身份、当前战略和可承诺范围 |
| 运营同事 | 只知道“要跑起来”，不知道真实 workflow 归属 | 用 L4 Flow 确认用户、AI agent、发布 operator、客服/支持和研发的协作路径 |
| 销售和市场同事 | 把候选能力、POC 或内部能力写成对外承诺 | 用 L3 承诺层判断哪些能力可以进入官网、BP、demo 和销售话术 |
| 客服/支持同事 | 用户问题只靠经验转发，无法追到证据 | 用 L4 Flow 和 L9 Evidence 找到日志、状态、发布证据和责任边界 |
| 研发同事 | 只改代码，不知道上层语义是否变化 | 自底向上更新实现、evidence、contract、边界、领域和 Flow |
对 AI agent，金字塔应该像操作系统的启动顺序：任何任务都不能直接从随机文件开始。它要先确认当前使命和战略，再确认承诺和 Flow，最后才进入代码、脚本、测试和日志。否则它很容易在一个 legacy 文件里找到“看起来很权威”的旧事实。
对非开发同事，金字塔应该像业务地图：他们不需要读完所有 contract 和代码，但必须能找到当前战略、可承诺能力、真实工作流和 evidence。只要他们要写对外文案、客户答复、运营 SOP、BP 或发布说明，就应该引用对应层级的 SSOT，而不是重新复制一份“当前重点”。
对研发，金字塔是反向更新规则：任何实现变化都要先有 evidence，再判断是否改变 contract、边界、领域模型、Flow、承诺和战略。这样，业务决策才能落到代码，代码变化也不会悄悄篡改业务事实。
几个具体场景：事实是如何分裂的
场景一：AI agent 读到了旧事实
团队已经决定把产品核心从“AI skills catalog”升级成 creative video generation workflow。但仓库里还有一份旧 README 写着“当前核心能力是公开 skill 目录”，某个旧测试也还在验证 skill 列表页面。
一个 AI agent 接到任务：“补齐当前核心能力的测试和文档”。如果没有 SSOT，它很可能会沿着旧 README 继续补 skill 文档、补 skill 测试、优化 skill 页面，甚至写一份“skill catalog 是当前主线”的总结。
这些工作每一步看起来都合理，但总体方向是错的。它不是在推进当前产品，而是在加固旧产品形态。
金字塔的解法是：AI agent 必须先读 L1-L4，确认使命、战略、承诺和真实 Flow；再进入 L5-L9，判断代码、测试、日志和 evidence 是否仍服务当前主线。旧 README 和旧测试可以存在，但它们不能越过上层 SSOT 定义今天的产品核心。
场景二：非开发同事把 POC 当成承诺
一个 POC demo 页面还在线，里面能跑通一条自动化视频创意链路。销售同事看到后，把它写进 BP：“已支持自动化创意视频生成 workflow”。运营同事看到发布检查是绿的，就安排客户试跑。客服/支持同事遇到失败时，按旧的 skill 日志去查。
最后发现，demo 能跑不等于产品承诺成立。它缺少稳定 contract，没有发布 evidence，也没有清楚的失败恢复路径。真正断掉的不是某个 skill，而是 workflow 状态流转、产物归属或外部 provider 权限。
这个例子说明，SSOT 不是阻止业务同事传播好消息，而是规定“什么可以被传播”。只有进入 L3 承诺层，并且有 L9 evidence 支撑的能力，才应该进入官网、BP、demo 话术和客户承诺。
场景三：命名漂移让研发回到旧世界
早期系统里到处是 skillTask、skillRun、skillResult。后来产品核心变成 workflow，但代码、数据库字段、日志和文档还大量使用 skill 作为中心概念。
新工程师和 AI agent 看到这些名字，会自然认为 skill 仍然是领域中心。于是新增能力时继续加 skillTask，排查问题时继续搜 skill failed，写方案时继续围绕 skill 设计。
这不是审美问题，而是事实来源问题。名字本身会告诉读者“系统真正相信什么”。当语义从 skill 升级为 workflow，命名、领域模型、contract、日志和测试都必须一起更新，否则旧名字会持续把团队拉回旧世界。
场景四：内部 API 悄悄变成公共 contract
某个接口一开始只是 POC 内部 API，用来让一个脚本快速提交视频生成任务。后来前端、CLI、AI agent、发布脚本都开始调用它，但 contract 文档没有升级，测试也只覆盖了最早的脚本路径。
某天研发改了一个字段名，以为只是重构内部实现。结果 CLI 断了，AI agent 的调用失败了，发布脚本收不到状态，客服/支持也查不到对应 evidence。
问题不在于“不要改接口”，而在于这个接口早已从 L8 实现事实升级成 L7 contract。只要多个入口依赖它，它就必须有明确 contract、调用方清单、变更规则和 evidence。
场景五：测试入口越长，团队越不知道该相信哪个
很多仓库会慢慢长出一串命令：test、test:e2e、test:smoke、test:release、check、verify、ci。每个命令在创建时都有原因，但几年后没人知道发布前到底该跑哪个。
工程师会跑自己熟悉的命令。AI agent 会选择名字看起来最相关的命令。CICD 可能跑的是历史上最容易通过的一组检查。最后所有人都能说“我跑过测试”，但没人能说“这个检查证明了当前承诺”。
测试入口本身也需要 SSOT。每个入口都要说明它证明什么事实、在哪个阶段运行、失败归谁处理、是否支撑公开承诺。否则测试越多，发布判断反而越不可靠。
场景六：绿色测试和过期日志一起制造发布事故
旧测试仍然保护“用户打开页面并点击生成按钮”的路径；新主线却依赖“AI agent 读取 workflow、选择 AI skills、调用 provider、写回资产、生成 release evidence”。旧测试全绿，但新路径断在 provider 权限或资产状态。
更糟的是，日志仍然写 skill failed，错误文案仍然说“生成失败”。研发会沿着 skill 查，客服/支持会沿着旧排查路径回复用户，AI agent 会继续把问题归类为单个 skill 失败。
真正的问题可能是 workflow 状态机卡住、artifact 没有归属、provider 权限没有随发布环境同步。也就是说，绿色测试证明的是旧主线，过期日志描述的是旧概念，事故发生在新 Flow。
这类事故最能说明 SSOT 的价值：evidence 必须跟随产品重心迁移，日志和错误文案也必须跟随领域模型迁移。
creative video generation workflow：从 POC 到核心领域概念
我们现在正在经历的一个具体例子，是 creative video generation workflow 这个概念的升级。
早期，一个 workflow 可能只是一个小脚本：把几个 AI skills 串起来，验证某条视频创意生产链路能不能跑通。这个阶段，它的影响面很小。它可能只需要一个脚本、一份临时说明、一点本地测试。它属于实现层，最多再加一点 evidence。
但如果这个脚本反复被真实任务使用，它就不再只是脚本。它开始变成内部能力：团队会关心它的输入是什么，输出是什么，谁来审批，失败时从哪一步重跑，成本由谁确认，产物放在哪里。
这个阶段，它影响的不只是代码，还开始影响 Flow、contract 和 evidence。
再往上，如果团队发现“把 AI skills 组装成 workflow”才是产品真正的核心能力，那么 creative video generation workflow 就开始成为领域模型里的一等公民。它不再是某个 skill 的附属说明，而是位于 AI skills 之上的产品概念：AI skills 是原子能力，workflow 是把这些原子能力组织成真实业务交付的结构。
- 领域模型要把 workflow 作为稳定概念建模。
- Flow 层要描述用户、AI agent、编辑人员、operator、开发者如何围绕 workflow 协作。
- Contract 层要定义 workflow 的输入、节点、审批、状态、产物、失败语义。
- 实现层要有对应的数据结构、脚本、页面、运行器和状态管理。
- Evidence 层要证明 workflow 真的能从输入走到交付，而不是只证明单个 skill 能跑。
- 承诺层要判断哪些 workflow 可以对外承诺，哪些只是内部候选。
- 战略层要决定 workflow 是否成为当前资源优先级。
- 使命层甚至可能要把“让 AI agent 在受控 workflow 中完成真实营销工作”写成产品长期身份。
如果 creative video generation workflow 最终成为团队使命的一部分，那它就不只是工程概念。团队的对外营销文案、BP、产品演示、销售叙事、客户 onboarding、发布说明，都应该重点描述它。因为它已经不只是“代码怎么组织”，而是“我们到底在做什么产品”。
这就是 SSOT 九层金字塔模型的价值：它让我们能盘点一个概念在当前到底爬到了哪一层，也能理解它每次上升会影响哪些资产。
没有金字塔模型，我们很难回答 creative video generation workflow 当下真正的重要性。有人会继续把它当脚本，有人会把它当内部工具，有人会把它当产品核心，有人会在 BP 里完全不提它。于是团队看似在做同一个东西，实际每个人脑子里的产品都不一样。
图：creative video generation workflow 从 POC 脚本上升到团队使命时，影响面会从实现和 evidence 扩大到 Flow、contract、领域模型、承诺、战略和对外叙事。
| 阶段 | 当下身份 | 主要影响面 | 不更新会造成什么 |
|---|
| POC | 小脚本 / 临时验证 | 实现、少量 evidence | 被误写成产品能力，过早扩大承诺 |
| 内部能力 | 被真实任务反复使用 | Flow、contract、成本、审批、产物状态 | 团队靠口头约定协作，失败无法归因 |
| 一等领域概念 | AI skills 之上的业务结构 | 领域模型、系统边界、测试体系 | 代码和文档仍把它当脚本，架构无法支撑 |
| 战略核心 | 当前资源优先级 | 承诺、发布、路线图、团队分工 | 测试和发布仍保护 legacy 主线 |
| 使命组成 | 产品长期身份 | BP、官网、销售叙事、客户 onboarding | 对外表达讲错产品本质 |
SSOT 九层金字塔模型是什么
SSOT 九层金字塔模型把一个产品从上到下拆成九类事实：
- 使命：产品为什么存在？
- 战略：当前阶段优先赢什么？
- 承诺：对用户和团队承诺支持什么？
- Flow：所有利益相关方如何完成真实任务？
- 领域模型：稳定概念、状态、权限、计费和不变量是什么？
- 系统边界：入口、能力、runtime、云端产品面、外部服务如何分工？
- Contract：接口、数据库、环境变量、权限、发布流程的合同是什么？
- 实现：代码、脚本、迁移、组件、自动化如何落地？
- Evidence：测试、日志、检查、发布证据如何证明前面八层成立？
| 层级 | 核心事实 | 典型 SSOT |
|---|
| L1 使命 | 产品为什么存在 | 使命文档、公司级产品叙事 |
| L2 战略 | 当前阶段优先赢什么 | 当前优先级、资源竞争、路线图 |
| L3 承诺 | 对用户和团队承诺什么 | 对外文案、支持边界、发布声明 |
| L4 Flow | 所有利益相关方如何完成真实任务 | 用户流程、AI agent 流程、产运研流程、发布流程 |
| L5 领域模型 | 稳定概念和不变量 | 领域对象、状态归属、权限、计费规则 |
| L6 系统边界 | 组件和外部服务如何分工 | 架构边界图、调用方向、职责约束 |
| L7 Contract | 可执行合同是什么 | API、数据库、环境变量、权限、发布合同 |
| L8 实现 | 代码如何落地 | 代码、脚本、迁移、自动化、配置 |
| L9 Evidence | 什么证明事实成立 | 测试、日志、状态检查、发布证据、线上事实 |
Flow 层不是 UI 页面清单，也不是“用户路径”这么窄。它应该囊括所有利益相关方围绕产品发生的真实工作流程：
- 用户如何从需求进入产品、授权、使用能力、审核结果。
- AI agent 如何理解任务、选择 AI skills、检查权限、执行能力、产出结果、记录 evidence。
- 产品、运营、研发如何围绕一个需求做判断、拆解、实现、验证和发布。
- Operator 如何执行发布、观察状态、处理阻塞、收集发布证据。
- 开发者如何新增能力、修改 contract、补充测试、避免扩大错误承诺。
- 客服/支持如何从用户问题进入日志、状态、证据和修复路径。
- 内部实验如何从 POC 进入候选能力，再决定升级、暂停或删除。
也就是说，Flow 层是“产运研 + 用户 + AI agent + 发布 operator + 客服/支持”的统一工作流层。它强迫团队不要只从代码视角理解系统，也不要只从产品页面理解系统，而是从真实任务如何完成来理解系统。
这对于 AI-native 产品尤其关键。AI agent 不是传统 UI 用户，它会读文档、调用工具、判断路径、生成代码、产出 evidence。如果 Flow 层没有把 agent 的工作流写清楚，AI 就会开始猜；一旦 AI 开始猜，SSOT 就开始失效。
对非开发同事来说，Flow 层也同样关键。产品、运营、销售和客服/支持通常不是从“哪个模块调用哪个模块”理解系统，而是从“谁在什么场景下做什么事、失败后找谁、证据在哪里”理解系统。Flow 层把这些问题放进同一个模型里，避免业务同事只能依赖口头解释，也避免工程师只看到代码调用关系却看不到真实协作关系。
所以 Flow 层是九层金字塔里最像“组织协作地图”的一层：它把用户流程、AI agent 流程、产运研流程、发布流程、客服/支持流程和内部实验流程放在同一个事实系统里。
PostPlus.io 的例子
以 PostPlus.io 为例，它的最高层事实不是“我们有一个 CLI”，也不是“我们有网页和桌面端”。更稳定的使命是：建设一个面向 AI 的营销产品，让智能体能完成真实、可验证、可计费、可发布、可支持的营销工作流。
到了战略层，当前选择会更具体：CLI 是当前主要发布和控制入口；AI skills 是用户和智能体看到的能力语言；云端能力、团队权益、计费、工作空间、外部服务边界和发布证据，是优先打通的产品底座。
到了承诺层，就不能说“仓库里有代码，所以用户可以依赖”。一个能力只有进入 AI skills，通过真实验收，并且有对应 evidence，才算公开承诺。候选能力、暂停能力、内部脚本，都不能被包装成用户可依赖的能力。
到了 Flow 层，我们不只描述“用户点哪里”。我们还描述 AI agent 如何选择 AI skills，开发者如何新增能力，发布 operator 如何跑发布，客服/支持如何定位问题，发布会话如何收集 evidence，内部 POC 如何进入或退出候选能力。这些流程共同决定了系统真实如何运行。
到了系统边界层，CLI、网页、桌面端只是入口；AI skills 负责表达用户可见能力；AI runtime 负责任务理解和编排；云端产品面持有账号、工作空间、团队权益、计费、任务和资产；外部服务负责支付、生成、采集、发布等外部事实。任何一层都不能越权定义另一层的事实。
到了证据层，文档本身不算证据。能证明事实的是测试、状态命令、发布清单、批准记录、线上检查和发布后的完整证据。
这就是 SSOT 九层金字塔模型的作用：让一个复杂产品里所有“该相信谁”的问题，都能回到明确位置。
测试体系的迭代：一个 SSOT 案例
测试体系是最好的例子，因为它会随着产品重心迁移而失效。
一个团队早期往往会为了当时的核心产品形态，维护一套很辛苦、很复杂的测试体系。那套测试在当时是有价值的：它覆盖了当时最重要的页面、接口、流程和用户路径。但后来团队决策不断演进，产品核心功能迁移了，旧产品形态逐渐进入 legacy，原来的测试体系也开始失焦。
它还在跑，甚至还很重，但它证明的是昨天的产品重点。
它仍然消耗维护成本，却不再覆盖今天最容易出事故的地方。
它让团队误以为“我们有测试”，但真正的新主线并没有被证明。
问题不在于团队完全没有战略判断，而在于这些判断没有层层穿透到产运研的所有工作内容里。文档里可能已经说新方向重要了，但代码结构还在围绕旧方向组织；发布流程可能开始发布新能力，但测试还在保护旧页面；日志和错误文案可能还在使用旧概念；AI agent 读到的说明可能仍然把 legacy 当成主线。
于是发布时就会出现错觉：CICD 是绿的，仓库健康检查是绿的，旧的端到端测试也可能是绿的，但真正要发布的新能力并没有被验证。直到一次真实发布，才发现新安装路径、AI skills、云端能力、runtime contract、外部服务权限、计费或发布证据之间有断点。
从 AI agent 的角度看，这种错觉尤其危险。它可能会把旧测试的绿色结果当成“当前主线已经被证明”，然后继续在旧入口上补自动化、补文档、补发布说明。它不是故意忽略新主线，而是 evidence 层没有告诉它：这条证据证明的是 legacy，还是当前承诺。
从非开发同事的角度看，问题同样现实。运营同事看到发布检查是绿的，会以为新 workflow 可以跑；销售同事看到 demo 文案和发布说明，会以为能力可以承诺；客服/支持同事遇到用户问题时，会按旧日志和旧流程排查。最后事故会表现为“发布没挡住问题”，但根因是测试体系没有跟随产品重心迁移。
图：测试体系的关键不是“更大”，而是证据要跟随产品重心迁移。旧测试继续变绿，只能证明昨天的主线没有坏。
PostPlus.io 的测试体系迭代，本质上就是从这个问题里收敛出来的。
我们不再把“测试多不多”当作核心问题，而是追问：当前产品重心是什么？当前公开承诺是什么？当前最关键的 Flow 是什么？这些 Flow 依赖哪些 contract？需要哪些 evidence 才能证明它们可以发布？
- 普通仓库健康检查只证明代码、类型、格式和基础 contract 没有坏。
- 本地浏览器旅程证明真实产品路径能走通。
- AI skills 的检查证明智能体看到和调用的能力没有漂移。
- 发布 evidence 证明候选版本、新安装路径、云端地址、runtime contract 和外部服务路径真实可用。
- 人工体验评审只作为产品判断，不伪装成普通自动化测试。
- 外部服务抽检有成本和权限边界，不能塞进默认 CICD 里假装稳定。
更重要的是，测试入口本身也需要 SSOT。新增、删除或改名测试入口，要先更新测试体系文档，再改根命令、自动化流程或发布流程。治理脚本会检查测试文件和命令，禁止长期跳过测试，禁止只跑空测试，禁止把人工体验评审伪装成普通测试，禁止远程流水线重新引用本地浏览器旅程。
这说明测试体系的成熟，不是“把所有东西都塞进一个更大的测试命令”。真正成熟的是回答清楚：
当前产品重心是什么？
这个检查证明什么事实？
它证明的是当前主线，还是 legacy？
它应该在哪里运行？
失败归谁处理？
它能否支撑公开承诺或发布判断？
下一篇：如何构造自己的 SSOT 九层金字塔模型
这篇文章解释的是为什么所有软件工程原则最后都在谈 SSOT，以及为什么复杂团队需要 SSOT 九层金字塔模型来保持统一事实。
SSOT 九层金字塔模型本身的通用构造原则，我单独整理成了另一篇文章：
那篇文章不依赖 PostPlus.io 的具体业务，会直接给出根目标、九层定义、阅读规则、更新规则、专题文档治理、evidence 规则和落地检查清单，方便其他团队按自己的业务重新构造一套金字塔。
结语
复杂系统最后一定会超过人的记忆容量。AI-native、高速迭代、全栈协作、产运研一体化，只会让事实增长得更快。
所以软件工程的核心问题不是“如何写更多代码”，也不是“如何生成更多文档”，而是如何让事实不分裂。
SSOT 解决的正是这个问题。SSOT 九层金字塔模型，是把 SSOT 应用到整个产品工程系统的一种方法：强制所有阅读者自顶向下理解团队使命、战略、承诺、Flow、领域、边界和 contract；也强制所有产出者自底向上更新实现、evidence、contract、边界和上层事实。
它尤其适合处理现代软件里最常见的状态变化：一个小 POC 如何逐步上升为核心战略，一个核心战略又如何逐步降级为 legacy 技术债。每一次上升都要有 evidence，每一次降级都要同步收窄承诺、边界、Flow 和入口。
如果一个团队能做到这一点，很多工程原则就会自然成立。代码会更少重复，文档会更少过期，测试会更有意义，发布会更可追溯，团队也更容易在战略变化时保持一致。
这就是为什么我认为：所有软件工程原则归并到最后，其实都在谈同一件事，SSOT。
