数据流图怎么画：追踪来源、存储与信任边界

数据流图怎么画？先识别外部来源、转换数据的处理过程、保留数据的存储，以及它们之间传递的具名数据。先划定系统边界，再展开内部的数据流动，同时保持进入和离开系统的数据不变。补充允许字段与信任边界说明，让审核人员能发现非预期的信息泄露。

作者：Ai Flowi · 发布于 2026-10-10

描述数据流动，而非决策执行顺序

数据流图回答的是“这些信息从哪里来、在哪里变化、流向哪里？”，并不展示审批的执行顺序。用动词为处理过程命名，用所存数据为存储命名，用实际传递的内容为箭头命名。存储不能批准请求；处理过程才会对从存储中读取的数据采取操作。

本例关注返回给发送方的、已获批准的咨询数据。发送方提交的文本最初位于受信任的服务边界之外。经授权的审核流程另行提供决策记录。图中不会根据调用方提供的布尔值推断批准状态，也不声称工作流构建工具提供人工审核收件箱。

先绘制上下文视图

这里的“0 级”指将服务表示为一个处理过程的上下文视图；“1 级”则展开该过程。各团队的编号约定可能不同，因此请记录你的约定。以下 Mermaid 源码用圆角形状表示处理过程，用矩形表示外部实体，并在展开视图中使用存储形状。信任边界分组是附加注释，并非执行规则。

flowchart LR
    S[External sender] -- Enquiry fields --> P(Approved enquiry service)
    R[Authorized review process] -- Decision record --> P
    P -- Public enquiry receipt --> S

上下文视图有意只呈现两个输入数据契约和一个输出契约。它不保证每次咨询都获批准。只有服务约定的契约确立了相应状态，回执才能描述待处理、已接受或已拒绝状态。展开视图时，应保留原有的业务含义。

展开转换过程与审核存储

flowchart LR
    S[External sender]
    R[Authorized review process]
    subgraph T[Service trust boundary]
        P1(1.1 Normalize permitted enquiry fields)
        P2(1.2 Associate reviewed version)
        D[(Review store)]
        P3(1.3 Project public receipt)
        P1 -- Normalized enquiry --> P2
        P2 -- Reviewed enquiry record --> D
        D -- Approved receipt fields --> P3
    end
    S -- Enquiry fields --> P1
    R -- Decision record --> P2
    P3 -- Public enquiry receipt --> S

通过比较边界箭头来保持各视图一致，而非比较内部方框数量。咨询字段和决策记录仍然进入系统；公开回执仍然离开系统。如果 1 级视图突然增加一条发往其他服务商的消息，就说明上下文视图不完整。如果审核存储收到提交契约中没有的个人信息，就说明展开视图引入了来源不明的数据。

内部存储的写入是一项概念性的处理要求。下文介绍的 Read Range 组件并未实现任何存储写入。应区分预期架构与有限范围的组件练习，尤其是在将输出命名为“已批准”时。

附上数据字典

这份字典是拟议的设计文档，并非生产环境的数据保留政策。上线前，负责的角色必须批准字段用途与保留期限。“需要决策”表示尚未完成的工作，不能理解为允许无限期保留记录。

信任边界表示数据控制方或可读取数据的主体发生变化。通过身份验证，不等于每个字段都适合返回。应独立审核从服务到发送方的箭头，而非将它与经授权的审核输入混为一谈：发送方可以收到处理结果，而无需看到内部审核引用。

如何发现私有字段的传播与来源不明的存储？

在一份模拟草稿中，开发人员将完整的已审核记录直接连接到公开回执。它携带了 review_ref，但字典只允许 enquiry_ref 与 disposition 跨越该边界。用明确命名的字段投影替换“完整记录”，并将它的确切字段与公开契约逐一比较。

另一份草稿增加了名为“归档”的存储，有输出箭头却没有输入数据。审核人员无法判断是谁填充它、它包含哪些字段，以及记录是否属于获批准的版本。应删除这个来源不明的存储，或补充它的实际生产方、输入契约与保留责任。不要为了让图形对称而凭空编造归档数据来源。

看一个修正后的例子：发送方提供咨询引用“enquiry-demo”、版本“v2”及一条模拟消息。审核记录必须标明相同的引用与版本。存储的关联记录可以包含内部审核引用；公开回执只包含咨询引用与已确立的处理结果。这些是设计中的字段集合，并非记录下来的服务响应。

检查限定范围的 AI Flowi 读取与字段投影

状态：已文档化。 Read Range 与这项拟议的 JSON Operations 字段投影均有目录文档；Ai Flowi 尚未对其组合配置进行生产环境测试。

示例配置，并非已记录的测试

Google Sheets 参考文档与 JSON Operations 参考文档记录了本项限定范围练习使用的读取和转换接口。

1. 准备 AI Flowi Workflow 账户、一个私有的模拟电子表格，并通过 Google 连接设置配置你自己的 Google 账户；服务商用量另行计费。
2. 在 Read Range 中，将 google_account 与 spreadsheet_id 设置为测试目标，将 range_name 设置为 ReviewDemo!A:B，其中只包含咨询引用与处理结果。
3. 提出映射方案前，先检查返回的行。在 JSON Operations 中，将检查过的结果传入 data，选择 JQ Expression 作为 operations 的值，并针对实际观察到的包装结构和双列契约编写 query。
4. 将投影后的回执列表与输出箭头核对。读取和这项字段投影都没有实现图中的概念性存储写入。

处理版本不匹配

假设规范化后的咨询包含引用 enquiry-demo、版本 v2 和修改后的模拟消息。单独的决策记录标明了相同引用，却是 reviewed_version=v1。如果只按引用连接，就会将旧的处理结果附到新的内容上。关联过程必须将这种不匹配保留为未解决状态，不让任何已确立的批准结果流入回执字段投影。

在字典中增加一条关联规则：已审核记录要求咨询引用与审核版本都相同。如果两个不同的决策指向同一对引用与版本，不要默默选择最后一行；应明确决策来源的冲突处理规则，或将关联保留为未解决状态。这些是拟议的数据契约规则，并不表示读取组件会强制执行。单独的权限控制可参见审批工作流要求。

现在按字典追踪三条拟议记录：v2 配对 v1 决策时保持未解决；v2 配对一条已确立的 v2 决策时可以提供其处理结果；v2 配对相互冲突的 v2 决策时需要核对处理。无论哪种情况，对外字段集合仍然只有 enquiry_ref 与 disposition。内部冲突不能成为在公开响应中增加决策历史、消息内容或审核引用的理由。

应将缺失单元格视为缺失信息。空白处理结果不等于拒绝，缺少咨询引用则无法关联。标题行不是咨询记录。只有源表已经明确这些契约，狭窄的读取范围才有用；它无法证明数据来源，也无法修复过度共享的权限。应在设计中明确呈现未解决的关联，而非编造兜底状态。

把现有方案作为证据，而非架构证明

状态：已测试。清洗潜在客户数据针对其特定的规范化与追加方案记录了32 项测试中 32 项通过。状态：已测试。将电子表格作为 JSON API记录了26 项测试中 25 项通过，其中未通过的信息泄露检查对对外边界仍有参考意义。

这些页面承载各自的确切映射与执行证据。本图增加了数据血缘与字段权限，既不复述它们的搭建说明，也不将其测试结果转移到咨询服务架构上。接口定义可参见 API 术语说明；决策与责任路径可参见流程图模板。

最后审核边界

对每条输出箭头，明确接收方并将字段与获批准的契约比较。对每个存储，明确生产方、使用方及保留决策。对每项转换，解释它删除或推导了什么。任何答案未知时，都应将设计标记为未解决。数据流图有助于审核，但无法证明访问控制、删除机制或运行时行为是安全的。