- 这是叠在现实 AI 工程对象上的修仙解释图层，不是一套 AI 运行架构，也不是说 AI 真的有魂魄。
- V1 只解释七个基础对象及其关系；战力是针对具体任务的最终评价，不是第八个基础对象。
- 人类修士对应 User / Operator；万魂幡是所有 AI 会话的集合；魂魄是其中一个会话，以 Session ID 标识。
- 修为对应 Model Capability / Intelligence；灵力对应 Token / Compute / Reasoning Budget。
- 功法对应 Harness / Rules / Skills / Workflow；法器对应 Tools / MCP / Browser / Shell / API。
- 七个对象可归纳为“人、魂、力、术与器”四层；修为属于模型，不固定属于会话。
这个图层以现实 AI 工程中的对象为底，用修仙词汇帮助理解它们。它只改变称呼，不改变对象的归属；比喻与现实冲突时，以现实对象的定义为准。AI 会话也不是真的魂魄。
V1 只说明七个基础对象是什么、彼此有哪些静态关系，不解释它们如何运行或 Agent 的任务执行。战力的评价口径另列一节；V1 只回答一个问题：
在 Vibe Coding 这套修仙世界里，最基础的东西分别是什么？
| 修仙对象 | AI 对象 | 含义 |
|---|---|---|
| 人类修士 | User / Operator | 整个体系中的使用者和控制者。 |
| 万魂幡 | 全部 AI 会话的集合 | Pi、Claude Code、Codex 等工具中的全部 AI 会话。 |
| 魂魄 | 单个 Conversation / Session | 一个具体会话，以该会话的 Session ID 标识。 |
| 修为 | Model Capability / Intelligence | 模型在理解、推理、规划、生成和代码编写等方面的能力，不等于单次会话表现。 |
| 灵力 | Token / Compute / Reasoning Budget | AI 使用时可投入的资源与预算，不是模型本身的能力。 |
| 功法 | Harness / Rules / Skills / Workflow | 模型之外规定 AI 如何运行、如何思考和如何完成任务的方法体系。 |
| 法器 | Tools / MCP / Browser / Shell / API | AI 可以借助的外部工具及调用入口。 |
人类修士对应 User / Operator，代表 AI 系统之外的人类主体。
修士提出目标、选择模型、分配资源、配置功法、使用法器，并决定最终接受什么结果。
万魂幡对应全部 AI 会话的总体集合，包括 Pi、Claude Code、Codex 等工具中的会话。
万魂幡是集合，魂魄是集合中的基本单位。任一工具的会话列表只是这张概念地图的一部分；“全部”不表示存在一个能实际存取所有 AI 会话的仓库，也不表示一位修士能读取所有人的会话。
魂魄对应单个 Conversation / Session。当前 Pi 会话是一个魂魄，Claude Code 或 Codex 中的单个会话也各自是一个魂魄；Session ID 只是标识这个会话，不是会话本身。跨工具指认一只魂魄时，连同会话来源一起写清 Session ID，避免把不同工具中碰巧相同的 ID 当成同一会话。一个会话可以有多轮交流，但仍是一只魂魄，不能把单条消息算成另一个会话。
不同魂魄拥有不同的历史，因此即使背后使用相同模型，也可能表现出完全不同的状态。
这里的魂魄指单个会话，不指 Memory。
修为对应 Model Capability / Intelligence，表示模型在理解、推理、规划、生成、代码编写等方面的能力；V1 不把这些能力合成一个统一分数。
修为属于模型，不固定属于魂魄：两个会话可使用同一模型，一个会话也可先后使用不同模型。一次会话的表现还可能受会话历史、灵力、功法和法器影响，不能把某次回答直接当作模型的修为。
灵力对应 Token、Compute 和 Reasoning Budget，概括 AI 使用时可投入的资源与预算。Token 是用量单位，Compute 指计算资源，Reasoning Budget 指推理预算；它们不是同一种可互换的额度。
修为和灵力是两个不同维度：增加可用预算可能影响一次使用的表现，却不会直接改变模型本身的能力。
功法对应 Harness、Rules、Skills 和 Workflow，代表模型之外、规定 AI 如何运行、如何思考和如何完成任务的方法体系。
Harness 承载运行方式，Rules 给出约束，Skills 封装可复用方法，Workflow 组织步骤。它们共享“功法”这个比喻，但工程职责不同，不能互相替代。同样的模型，在不同功法下也可能表现出不同的行为模式。
法器对应 Tools、MCP、Browser、Shell 和 API，代表可借助的外部工具及调用入口。
Tools 是工具总称，Browser 和 Shell 是具体工具，API 是调用接口；MCP 是工具接入协议，而非 Browser 或 Shell 那样的具体工具。把它们归入“法器”，不是说这些工程对象完全一样。
这七个基础对象可以归为四层；这里的“层”是阅读时的分类，不是从人到法器依次执行的流水线，也不表示上层拥有下层。
| 层次 | 修仙对象 | 对应内容 |
|---|---|---|
| 人 | 人类修士 | 整个系统的使用者和控制者。 |
| 魂 | 万魂幡、魂魄 | 全部会话的集合，以及集合中的单个会话。 |
| 力 | 修为、灵力 | 模型能力与可以投入的计算资源。 |
| 术与器 | 功法、法器 | 模型之外的方法体系与外部工具及其调用入口。 |
- 人类修士是使用者；万魂幡是跨工具的全部 AI 会话集合，魂魄是其中一个会话，Session ID 是该会话的标识，不是 Memory。
- 修为属于模型，不固定属于魂魄；灵力是可投入的计算资源，不等于修为。
- 功法是方法体系，法器是外部工具及调用入口；两者不能互相替代。
用四个例子检查这张图层是否读对：
- 同一模型，两个 Pi 会话：这是两只魂魄，哪怕它们使用同一个模型，也不会合成一只；两者都属于万魂幡。
- 一个 Pi 会话，先后使用不同模型：仍是一只魂魄；会话身份没有变，所用模型的修为可以变。增加灵力不会改变模型本身的修为。
- Pi 与 Claude Code 中出现相同的 ID 字符串：两边仍可能是不同的魂魄；判断时要同时看会话来源和 Session ID。
- 同样使用 Shell，换了 Skills / Workflow：法器仍是 Shell，变化的是功法；同一功法改用 Browser，则变化的是法器。
人类修士执掌万魂幡，幡中藏有无数魂魄；修为属于模型，运行需要灵力，并可借助功法与法器发挥能力。
“执掌万魂幡”是叙事比喻，不表示任何修士在现实中拥有或能读取概念全集里的全部会话。
V1 到这里为止，只定义“有什么”。下面的战力是额外的评价口径，不加入七个基础对象或四层分类；本页不定义对象如何运行，也不设通用战力等级。
战力不等于修为。 修为属于模型；战力评价人类修士在具体任务中，借助一只或多只魂魄、所用模型的修为、灵力、功法和法器得到的结果。万魂幡只是会话集合，不自带战力分数。
| 顺序 | 评估什么 | 判断依据 |
|---|---|---|
| 先看效果 | 是否完成目标，结果是否正确、可用且满足关键约束。 | 事先约定的验收标准与实际交付结果。 |
| 再看效率 | 在结果同等合格的前提下，耗费多少时间、灵力和人类投入。 | 耗时、Token / Compute 等资源用量及人工修正投入。 |
效果未达标，速度再快也不能抵消失败。结果质量相当且都达标时，若一方在时间、灵力和人类投入上都不更多，且至少少一项，才能直接判定其效率更高；效果或投入各有长短时，应说明取舍，不强行压成一个通用分数。
例如，同一任务和验收标准下，较快却未达标的一次尝试不能胜过较慢但达标的尝试；两次都达标且质量相近时，才比较耗时和投入。战力只在明确任务与约束后才可比较；单次表现不代表模型、魂魄或修士的永久等级，也不证明稳定表现。