（1）了解骨架

普通 config vs 注册表（核心区别）

✅ 注册表本质上是一种“特殊的 config”
❗ 但：只有“控制规则生效状态”的 config，才叫注册表

🟦 普通 config

👉 用来“配置行为参数”

{  "port": 3000,  "theme": "dark",  "enableCache": true}

特点：

改的是“怎么运行”
不涉及规则系统
不控制“对/错”

🟥 注册表（Registry）

👉 用来“控制规则体系”

{  "GATE-PROGRESS-001": {    "status": "enforced",    "enforcedBy": "check-progress-format.mjs"  }}

特点：

改的是“哪些规则生效”
控制系统行为边界
决定是否 BLOCK

类型	控制什么
config	系统参数
registry	系统约束

这个问题问得很好，但你现在问的“参数”其实有点偏了。

先把方向纠正一下：

❌ 架构不是靠“参数列表”理解的
✅ 架构是靠几个关键维度信息拼出来的

我给你一套工程里真的够用的最小信息集，你拿到这些，就能基本还原一个项目的架构。

🧠 一句话版本

想理解架构，本质是回答 5 个问题：

系统做什么 / 分几层 / 数据怎么流 / 谁控制谁 / 怎么部署

🧩 一、必须掌握的 6 类信息（核心）

① 系统边界（System Boundary）

👉 项目“到底管什么”

你要知道：

是前端应用？后端服务？CLI？平台？
输入是什么？输出是什么？

举例

输入：用户请求 / prompt / HTTP
输出：页面 / JSON / AI response

② 模块划分（Modules）

👉 项目分成几块

你要找：

src/
  api/
  core/
  services/
  guards/

你现在这个系统其实是：

Policy
Gate
Wrapper
Orchestrator

👉 这已经是架构了

③ 依赖关系（Dependency）

👉 谁调用谁

关键问题：

谁是入口？
谁是核心？
谁是工具？

典型结构

CLI → Orchestrator → Gate → Utils

④ 数据流（Data Flow）🔥最重要

👉 数据是怎么走的

比如你现在的门禁系统：

prompt
↓
assistant output
↓
gate check
↓
PASS / BLOCK

如果你搞不清数据流，就理解不了架构。

⑤ 控制流（Control Flow）

👉 谁在“控制执行顺序”

例如：

CI pipeline
Hook system
workflow

区别：

数据流 = 信息怎么走
控制流 = 谁决定什么时候执行

⑥ 运行时位置（Runtime Placement）

👉 每一块在哪跑

本地 CLI？
服务器？
CI？
浏览器？

🔥 二、最小架构图（通用模板）

拿到这些信息后，你可以画出👇

         用户 / 输入
              ↓
        ┌──────────┐
        │ 入口层    │
        └────┬─────┘
             ↓
        ┌──────────┐
        │ 核心逻辑  │
        └────┬─────┘
             ↓
        ┌──────────┐
        │ 子模块    │
        └────┬─────┘
             ↓
        输出 / 副作用

🧠 三、如果你非要“参数化”，可以这么抽

给你一个“架构参数表”（工程里可用）

🧩 架构参数模型

{
  "entrypoints": ["cli", "http", "hook"],
  "modules": ["policy", "gate", "wrapper"],
  "dataFlow": "input → process → validate → output",
  "controlFlow": "orchestrator / hook / CI",
  "runtime": ["local", "ci", "server"],
  "enforcement": ["none", "advisory", "block"]
}

👉 这就是你想要的“参数版架构描述”

⚠️ 四、很多人会犯的错误

❌ 只看文件结构

src/
  utils/
  helpers/

👉 这不是架构

❌ 只看技术栈

React + Node + MongoDB

👉 这也不是架构

❌ 只看 config

👉 更不是

🎯 五、真正有用的提问方式

你以后要理解一个项目，直接问这 6 个：

1️⃣ 入口在哪里？

2️⃣ 核心逻辑在哪？

3️⃣ 数据怎么流？

4️⃣ 谁控制执行？

5️⃣ 哪些是可替换模块？

6️⃣ 哪些是强制边界（gate）？

💬 最后一句话

架构不是“有哪些文件”，而是：

❗ “系统是怎么被驱动运行的”

如果你愿意，我可以帮你把你现在这套：

👉 ContractGuard / Codex / Gate 系统

画成一张完整架构图（带真实文件路径）

那会比这些抽象概念更有用。

如何了解一个项目