Huoban（Huó Bǎn）活板
可排版、可润墨、可印刷
把分散在不同工具里的 AI 工作，整理成一套可验证、可组合、可审查的开放对象语言。
字架 / 对象资产
先把能力、上下文、规则和来源变成可命名、可审查、可替换的对象。
Skill
Adapter
Profile
Policy
Registry
Trust
墨方 / Profile
项目规则、领域语言和历史决策进入上下文层，改变判断标准，但不污染 Skill 本身。
印坊规矩 / Policy
副作用、审批和权限边界必须显式声明，不能留给工具默认行为。
版盘 / Flow
Flow 按 capability-first 排列阶段、校对点和产物；只声明版式，不绑定 runner。
capability
stage
checkpoint
artifact
profileRef
policyRef
印张 / 事实链
一次 AI 工作必须留下可校对、可复盘、可迁移的记录。
Run snapshot
Checkpoint
Artifact
开放标准
同一套对象语义，可被不同 agent、tool、MCP server 和 runner 解释与绑定。
可排版：能力必须能被重新排列
可排版意味着能力不能只是一段临时 prompt，也不能只绑定在某个工具按钮里。能力必须能被命名、索引、选择、组合和替换。 如果 skill 不能从具体工具里拆出来，它就无法跨项目复用；如果编排只存在于人的操作习惯里，它就无法被审查、迁移或自动验证。 在 Huoban 中，Skill 是活字，Flow 是版式，Registry 是字架，Adapter 是异形活字转接件。
Flow 不是脚本，也不是某个执行环境的配置。它描述的是“这项工作需要哪些能力、如何排列、在哪里停顿、产出什么”。具体由哪个工具、模型或执行环境完成，是后续 binding 和 Run 的问题。
这也是为什么 Huoban 优先引用 capability，而不是把 Flow 永久绑定到某个具体 skill。这样同一个 Flow 可以在不同团队、不同工具、不同执行环境中复用。
继续阅读：Flow 模型、Skill 对象、Adapter 对象。
可润墨：上下文必须成为对象
可润墨意味着上下文不能散落在聊天历史、个人习惯或不可验证的项目说明里。上下文必须成为可以分层、合并、审查、导入和导出的对象。 如果 context 只留在 prompt 或聊天历史里，团队无法知道 agent 依据了哪些规则，也无法判断一次输出是遵循了项目约束，还是偶然命中了正确答案。 在 Huoban 中，Profile 是墨方。它不改变 Skill 本身，但会改变同一个 Skill 在不同项目里的判断标准。
一个 Profile 可以包含：
- 团队规则
- 项目结构
- 领域语言
- 架构边界
- 历史决策
- 输出风格
- 风险偏好或 Policy 派生提示
Profile 对象，让它能被版本化、校验、引用和迁移。实际副作用、审批和权限边界仍然进入 Policy。
AGENTS.md、CLAUDE.md 和 Cursor Rules 通常应作为上下文文件导入为 Profile 对象。如果文件包装的是外部能力、工具行为或 skill-like 指令，则应通过 Adapter 表达，并经过 review。Profile 适合进入跨工具的标准对象模型，而不是只被某个 agent 工具读取。
继续阅读：Profile 模型、导入 AGENTS.md、导入 CLAUDE.md、导入 Cursor Rules。
可印刷：执行必须留下可审查快照
可印刷意味着一次 AI 工作不能只留下聊天记录或不可复现的结果。它应该留下可审查的执行快照、权限边界、校对记录和产物。 如果执行没有Run、Checkpoint、Policy 和 Artifact，一次 AI 工作就很难被复盘：无法确认当时用了哪个 Flow、注入了哪些 Profile、允许了哪些副作用、在哪个判断点继续或停止。
在 Huoban 中，Run 是锁版印刷，Checkpoint 是校对，Policy 是印坊规矩，Artifact 是印张，Trust 是来源信任记录。
没有
Checkpoint，agent loop 只能依赖聊天里的临时停顿。Huoban 把停顿变成对象：在哪个 run 和 stage 停下、为什么停下、需要哪些决策动作、关联哪些产物，都必须显式。
没有 Policy，读文件、写文件、执行命令、访问网络、发布远端变更或访问密钥就只能靠工具默认行为。Huoban 把这些副作用放进审查边界。
Trust 不替代 Policy 或 Checkpoint：它记录对象来源、审查状态、信任等级和 sandbox 要求；权限边界仍由 Policy 声明，决策动作由 Checkpoint 要求，产物验收在 Artifact.review 中表达。
继续阅读：Run 模型、Checkpoint 模型、Policy 模型、Trust 模型。
备料、验版与报工：不要等开印后才发现阻塞
活字印刷不会在开印后才确认字、墨、稿件和器具是否齐备。Huoban 也不能等 stage 已启动，才发现 Skill 未安装、MCP tool 不存在、上下文来源不可读或凭据未配置。
这些都不是新的顶层 kind。Requirement 嵌入对象，Preflight 证据进入 Run status 与 Artifact，Lifecycle Handler 嵌入 Flow 并通过 Run binding 选择 provider。
Preflight 不是授权：字、墨和机器齐备，不代表这次印刷已获准。
Policy、Trust、Checkpoint 与执行环境权限仍然独立生效。Lifecycle Handler 也不是任意 hook；业务动作应写成 stage，判断应写成 Checkpoint，权限应写成 Policy。
继续阅读：Requirement、Preflight、Lifecycle Handler。
开放标准：不要把对象锁进单个工具
Huoban 要定义的是对象语言，不是单一工具的内部格式。对象模型应该能被不同 agent、tool、MCP server、模型和执行环境共同理解。 这也是Adapter 的哲学位置：Huoban 不要求已有生态全部重写成原生对象。外部 skill、MCP tool、AGENTS.md、CLAUDE.md、Cursor Rules 都可以先通过 Adapter 或 Profile 进入 Huoban 对象模型。
Adapter 不是简单调用桥。能力类外部来源至少要声明 source、capabilities 和 sideEffects；外部文件、程序或服务依赖进入 requirements[]，mapping、checkpoint 和 trustRef 在可推断或已审查时补齐。这样外部能力才能被同一套 Flow 排版、被同一套 Preflight 检查、被同一套 Policy 审查。
开放标准的目标不是让所有工具消失，而是让工具之间可以共享对象语义。
Huoban 不要求所有工具使用同一个执行器。它要求不同工具能理解同一组对象：同一个 Flow 可以被不同执行环境解释，同一个 Profile 可以被不同 agent 注入，同一个 Policy 可以被不同系统检查。
对象边界：为什么不能合并
Huoban 的对象不是为了多造概念，而是为了防止不同层次的责任互相污染。能不能合并，判断标准只有一个：合并之后是否还保留可验证、可替换、可审查的边界。
这就是第一性原理上的边界：
Flow 解决“如何排”，Profile 解决“按什么上下文判断”，Requirement 解决“依赖什么”，Preflight 解决“当前是否就绪”，Policy 解决“什么动作被允许”，Run 解决“这一次到底引用并绑定了什么”，Checkpoint 解决“在哪里需要显式决策动作”，Artifact 解决“产出了什么”，Trust 解决“这个对象来自哪里、是否可信”，Lifecycle Handler 解决“在哪些有限事件上观察和上报”。
最小验证例子：idea-to-spec-review
标准对象必须能串成一条可验证链路，而不是停留在概念解释里。当前 examples 中的idea-to-spec-review 可以这样读：
这条链路说明 Huoban 的重点不是让 agent “看起来自动化”，而是让 AI 工作可以被解释、检查、复盘和迁移。
对象映射
从一次 AI 工作看排印流程
1
取字：选择能力
Registry 提供对象来源和索引范围；能力匹配由后续工具或解释层完成。2
排版：组织 Flow
用
Flow 安排 stage、capability、artifact 和 checkpoint。3
润墨：注入 Profile
用
Profile 注入团队规范、项目结构、领域语言、历史决策和输出要求。4
立规：套用 Policy
用
Policy 声明副作用、审批、权限和危险动作边界。5
锁版：生成 Run
用
Run 锁定一次执行使用的 Flow/Profile/Policy 引用、mode、bindings，并记录当前 schema 支持的 snapshot hash。6
备料与验版：Requirement / Preflight
检查对象引用、capability binding、文件、程序、MCP、凭据和上下文来源，并留下 Run scope 证据。
7
校对：进入 Checkpoint
在高判断力或高风险节点进入
Checkpoint，声明需要 approve、request changes 或 reject。8
付印：产出 Artifact
把代码 diff、文档、报告、决策记录或发布结果保存为
Artifact。9
报工：记录 Lifecycle invocation
运行时实现应在有限事件上执行经绑定和授权的观察性处理器，并把 event id、尝试次数和结果写入 Run status。当前 reference implementation 只验证声明、binding 与就绪性，不提供 dispatcher。
10
归架：进入 Registry 和 Trust
采用 Huoban 的系统应把可复用能力、产物来源、审查结果和信任等级归档，进入下一次复用循环；当前仓库只定义这些对象和引用关系，不提供托管归档服务。
设计边界
设计原则
- 标准化活字，不标准化文章。
- Skill 尽量无状态。
- Profile 是上下文层，不是 Skill 本身。
- Flow 描述能力编排，不绑定单一执行环境。
- Run 必须可追溯。
- 副作用必须可见。
- 校对是一等能力。
- Adapter 是标准化边界，不是临时胶水。
- Flow 也应该可分享。
- 文化隐喻必须进入结构，而不是停留在命名和文案上。
- 依赖就绪、治理授权和业务成功必须分别验证并独立记录。
- 生命周期观察不能成为隐藏控制流。