SSOT：为什么所有软件工程原则最终都在谈同一件事

我最近越来越频繁地遇到同一种问题。

一个新人进仓库，问：“这个产品现在最核心的能力是什么？”

一个 AI agent 接到任务，也要回答同一个问题。它会去读 README、路线图、测试、日志、发布记录和对外文案。

产品、运营、销售、客服/支持也会问类似的问题：这个能力能不能承诺？这个功能还是不是主线？这次发布到底验证了什么？

如果这些人和 AI 从不同入口里读出不同答案，问题就不是“文档还不够多”。

很多团队已经有太多文档了。

症结在另一头：事实分裂了。

我现在越来越倾向于把软件工程里一大批原则收束到一个问题上：SSOT，Single Source of Truth，单一事实来源。

DRY、KISS、SOLID、模块化、领域建模、测试金字塔、可观测性、CICD、文档治理，看起来属于不同层面。一个讲代码，一个讲架构，一个讲测试，一个讲发布。

但它们最后都会碰到同一个问题：

当系统变复杂时，团队到底应该相信谁？

DRY 关心的是同一个事实不要散落在多个地方。

KISS 关心的是事实路径够不够短，人和 AI 能不能很快知道该信哪里。

SOLID 关心的是责任边界是否稳定，一个模块有没有同时持有太多类事实。

领域建模把业务概念从页面、接口、数据库、脚本和人的记忆里收回来。

测试让行为预期有可执行的证据。

可观测性让线上状态能被追溯。

CICD 让一个版本能不能合并、能不能发布、是否已经上线，有统一判断来源。

从这个角度看，SSOT 不是再多写一份总文档。它更像一条纪律：每一种重要事实，都要有权威位置、维护责任，以及证明它仍然成立的 evidence。

复杂系统一定会变成令出多方

小系统可以靠人的记忆运行。几个人坐在一起，大家都知道哪个接口能用，哪个页面是旧的，哪个脚本只是临时方案，哪个测试可以忽略。

但业务系统只要持续迭代，人的记忆很快就会失效。

我们可能每个月都重新造一次轮子，三个月后完全忘记以前造过。不同团队成员可能都解决过同一个问题，只是留下了不同实现、不同文档、不同脚本。某个历史阶段为了一个特殊场景做过专门设计，后来业务变了，但代码、测试和说明还留在系统里。

时间一长，最麻烦的状态就出现了：不是没人写文档，而是每个地方都有一点文档。只是没有一个地方能负责当前事实。

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，团队就很难判断这些冲突谁该赢。

没有分层模型，团队也很难盘点一个决策到底影响哪些范围。

图：团队决策如果没有通过 SSOT 层层穿透，就会在文档、代码、测试、日志、对外表达中留下不同历史阶段的互相矛盾表述。

“当前优先级”最容易制造脑分裂

一种非常常见、也非常危险的事实漂移，是各种文档里都写了“当前重点”“当前优先级”“下一阶段方向”。

README 里写一版，架构文档里写一版，某个方案文档里写一版，会议纪要里写一版，发布总结里又写一版。每一版在写下来的时候可能都是真的。但随着业务、产品、技术不断演进，它们会逐渐过期。

对人来说，这会造成阅读负担：读到一处“当前重点”，不知道它是不是最新。

对 AI 来说，这会造成更严重的问题：AI 会把所有看起来权威的文字都当成上下文。如果五份文档都写了“当前优先级”，但只有一份是最新事实，AI 很容易综合出一个看似合理、实际错误的判断。

这就是我说的脑分裂：每份材料单独看都像是真的，合在一起却无法指导行动。

解决方式不是让所有文档闭嘴，而是规定事实归属。当前优先级、负责人、资源竞争，只能有一个权威入口。其他文档可以链接它，解释它服务的稳定结构，但不要复制一份“当前重点”。

战略改变时，改权威入口。

计划完成时，把稳定结论提升到对应层，再删除或压缩过期计划。

否则，系统里的每一句“当前”都会慢慢变成未来的误导。

为什么需要 SSOT 九层金字塔模型

我做 SSOT 九层金字塔模型，不是想把文档系统变复杂。

相反，它是为了减少自由发挥：让人和 AI 都按同一条逻辑理解系统、更新系统。

阅读时，SSOT 九层金字塔模型强迫你自顶向下：先从团队使命开始，理解当前战略、对外承诺、真实 Flow、领域模型、系统边界、contract，再进入具体实现和 evidence。你不能跳过战略直接解释代码，也不能用某段历史实现反向定义今天的产品方向。

产出时，SSOT 九层金字塔模型强迫你自底向上：先更新代码、脚本、数据库、自动化、测试和 evidence，再判断它是否改变 contract、边界、领域、Flow、承诺、战略，甚至使命。你不能因为写了一个 POC，就直接把它写成团队战略；也不能因为某个 legacy 模块还在仓库里，就继续把它当成当前产品事实。

这个模型要长期保持成一个最新的团队快照。它不只是技术文档，也记录业务、产品、技术决策和当前思考。

更直白一点，它逼着人和 AI 给每个概念定位。

这个东西现在到底是什么？

• 只是一个脚本？
• 是一个 POC？
• 是候选能力？
• 是内部工作流？
• 是用户承诺？
• 是当前战略？
• 是团队使命的一部分？
• 还是已经降级成 legacy？

这个位置没说清，代码、文档、测试、发布和对外表达就会各走各的路。

金字塔给不同角色的解法

九层金字塔不是让所有人都变成架构师。

它的目标更朴素：让不同角色少猜一点，也少读一点无关材料。每个人都能知道自己该从哪一层进入系统。

对 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 就要进入领域模型，成为一等概念。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、发布说明，都要开始围绕它组织。因为它已经回答了一个更大的问题：我们到底在做什么产品？

这时九层金字塔的价值就很具体：它帮团队判断一个概念现在爬到了哪一层，以及它每上升一层会影响哪些资产。

没有金字塔模型，我们很难回答 creative video generation workflow 当下真正的重要性。有人会继续把它当脚本，有人会把它当内部工具，有人会把它当产品核心，有人会在 BP 里完全不提它。于是团队看似在做同一个东西，实际每个人脑子里的产品都不一样。

图：creative video generation workflow 从 POC 脚本上升到团队使命时，影响面会从实现和 evidence 扩大到 Flow、contract、领域模型、承诺、战略和对外叙事。

SSOT 九层金字塔模型是什么

SSOT 九层金字塔模型把一个产品从上到下拆成九类事实：

1. 使命：产品为什么存在？
2. 战略：当前阶段优先赢什么？
3. 承诺：对用户和团队承诺支持什么？
4. Flow：所有利益相关方如何完成真实任务？
5. 领域模型：稳定概念、状态、权限、计费和不变量是什么？
6. 系统边界：入口、能力、runtime、云端产品面、外部服务如何分工？
7. Contract：接口、数据库、环境变量、权限、发布流程的合同是什么？
8. 实现：代码、脚本、迁移、组件、自动化如何落地？
9. Evidence：测试、日志、检查、发布证据如何证明前面八层成立？

这里最容易被低估的是 Flow 层。

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 九层金字塔模型来保持统一事实。

SSOT 九层金字塔模型本身的通用构造原则，我单独整理成了另一篇文章：

如何构造 SSOT 九层金字塔模型：一套可复用的 SSOT 原则

那篇文章不依赖 PostPlus.io 的具体业务，会直接给出根目标、九层定义、阅读规则、更新规则、专题文档治理、evidence 规则和落地检查清单，方便其他团队按自己的业务重新构造一套金字塔。

最后

复杂系统最后一定会超过人的记忆容量。AI-native、高速迭代、全栈协作、产运研一体化，只会让事实增长得更快。

这时候，软件工程的问题就不只是写更多代码、生成更多文档。更底层的问题是：事实怎么不分裂？

SSOT 处理的就是这个问题。九层金字塔模型只是其中一种落地方法：阅读者自顶向下理解使命、战略、承诺、Flow、领域、边界和 contract；产出者自底向上更新实现、evidence、contract、边界和上层事实。

它尤其适合处理现代软件里最常见的状态变化：一个小 POC 慢慢上升为核心战略，一个核心战略又慢慢降级为 legacy 技术债。每一次上升都要有 evidence，每一次降级都要同步收窄承诺、边界、Flow 和入口。

如果一个团队能做到这一点，很多工程原则就会自然成立。代码会更少重复，文档会更少过期，测试会更有意义，发布会更可追溯，团队也更容易在战略变化时保持一致。

这也是我为什么会说：很多软件工程原则归并到最后，其实都在谈同一件事，SSOT。