跳转至
ACTIVE

Human-README · 人类视角的 AIOS 入门指南(v1.2)

读者:你(项目总指挥 · 唯一的人类决策者)

预期阅读时间:12 分钟(v1.2 加入 §3 OS 模型速查 + §4 全栈 10 进程拓扑 + §5 9 CPU 实例)

读完之后你会知道:AIOS 是什么、OS 化模型怎么读、9 个 CPU 在做什么、10 个进程是什么、你每天要做什么、不要做什么、何时该停下来介入。

v1.2 关键更新(2026-05-26 · 配合 ADR-AIOS-06 v0.3 落地): - OS 化模型:从"5 角色矩阵"升级到"进程/线程/PCB/RUNQ"(任务 ↔ CPU 解耦) - 9 CPU 实例:并发域 A 4 兄弟(ClaudeA/B/C/D)+ 并发域 B 4 worktree(Cline-Worker/Copilot/Continue/DeepSeek-Worker)+ Cline-AIOS 调度内核 - 全栈 10 进程:P0-P7(前端 5 + 后端 P5/P6/P7)+ P_contracts(契约)+ P_arch(架构事件容器) - 新文件入口:PCB.md(进程总览)+ RUNQ.md(就绪队列)+ INDEX.md(全局索引)替代旧 KANBAN.md(已 archive 为 KANBAN-archive-v6.md) - commit-msg 三元组:[pid=][uid=][occupies=] 强制规范(7 天宽限期) - 保留 §2 .clinerules 双文件协作机制(v1.1 沉淀)+ §10 工程背景速查(v1.1 沉淀)


1. 一句话讲清 AIOS(v1.2 · OS 化版本)

AIOS(AI Operating System)= 你 + 1 个调度内核(Cline-AIOS)+ 8 个干活的 CPU + 10 个任务进程 + 调度元数据(PCB / RUNQ / INDEX)

类比真正的操作系统:你像 CEO,Cline-AIOS 像 OS 内核,8 个 CPU 是工程师团队,10 个进程是项目里 10 个独立任务模块。内核(AIOS)不写代码,只调度——按"K-thread 占用 + 缓存亲和 + 主战场"动态把任务派给最合适的 CPU。

1.1 类比:操作系统(v1.2 升级)

操作系统概念 AIOS v1.2 对应
内核(kernel) Cline-AIOS(本会话 · 调度内核 · cwd=06_docs/site-build/)
进程(process) P0 / P1 / P2 / P3 / P4 / P5 / P6 / P7 / P_contracts / P_arch(共 10 个)
常驻线程(K-thread · kernel thread) 模块所有权登记 · 永远存在(如 P3.K5-stage-toolbar)
临时线程(U-thread · user thread) 业务任务调度单元 · 完成即 zombie(如 P3.U2-tuning-mode-ui)
CPU 池 ClaudeA/B/C/D + Cline-Worker / Copilot-Worker / Continue-Worker / DeepSeek-Worker(共 8 个 + 不入 RUNQ 的 Copilot 内联)
PCB(Process Control Block) PCB.md 总览 + 各 processes/<pid>/PROCESS.md 详细
RUNQ(就绪队列) RUNQ.md(只调度 U-thread · K-thread 不入队)
文件系统(fs) git 仓库 + 04_development/ 业务代码 + 06_docs/site-build/ 调度元数据
IPC 通信 commit message 三元组 [pid=][uid=][occupies=] + shared_resources.via
用户态(user space) 你(人类)+ 战略指令
系统调用(syscall) 你给 AIOS 的指令(如 "派 P2.U5-module-uid 给 ClaudeB")
中断信号 ADR-NN(架构事件)→ fork P_arch/ADR-NN/ 子进程 · 不重写 PCB 主干

2. .clinerules 双文件协作机制(沿用 v1.1 · 新会话必读)

本仓库 .clinerules/ 目录下有 2 个指令文件,Cline 启动时都会加载,但作用范围不同:

文件 何时生效 职责
.clinerules/xisound-docs-migration.md(工作区根) 始终生效(无需拍板) 文档创作 / 视觉调优 / 工程代码位置 / mkdocs / PowerShell 约束
.clinerules/aios-orchestration.md(仓库内) 用户拍板后激活(v1.2 加入触发词回退) AIOS 调度内核角色:维护 PCB/RUNQ/INDEX / 派 U-thread / standup / ADR / 仲裁

2.1 启动询问流程(v1.1 沉淀 · v1.2 不变)

每次新会话启动时,Cline 必须先问后做(详见 .clinerules/aios-orchestration.md §激活与禁用)。

2.2 4 种禁用 AIOS 模式的方式(任选其一)

# 方式 适用场景 操作
1 首句明示(推荐) 临时一次性禁用 新会话第一句说"普通模式" / "忽略 AIOS"
2 重命名禁用 中期禁用(几天-几周) .clinerules/aios-orchestration.mdaios-orchestration.md.disabled
3 Cline 设置面板 长期禁用 VSCode → Cline 设置 → Manage Clinerules → 取消勾选
4 直接删除 永久放弃 rm .clinerules/aios-orchestration.md · 同时清理 40-aios/ 知识库

2.3 触发词回退(v1.2 扩展)

即使你拒绝进入 AIOS 模式,以下"硬触发词"仍会临时触发 AIOS 流程(响应完即退): - standup / 抓取 standup / 日报 / 晨会 - 派发 / 派活(明确指向多智能体场景时) - 仲裁(明确说"AIOS 仲裁"时) - (v1.2 新增) PCB / RUNQ / 进程 / pid= / uid=(指向 OS 化模型查询时)


3. OS 模型速查(v1.2 新增 · 必读)

3.1 三层架构

Layer 3 · 任务层(Process / K-thread / U-thread · 不含 owner)
        ↑ U-thread 入就绪队列
Layer 2 · 调度层(Cline-AIOS · RUNQ 6 步算法 · 优先级 · K-thread 校验 · 缓存亲和)
        ↓ 派发(动态绑定)
Layer 1 · 执行层(CPU 池 · 9 实例 · 见 §5)

关键洞察:Layer 3 的 Process / K-thread / U-thread 没有 owner 字段。任何 CPU(满足 K-thread file_claims 不冲突)都可被派发执行。这就是"任务 ↔ CPU 解耦"。

3.2 进程分类(daemon / user-process / arch-event)

类型 状态特征 典型成员(全栈 10 进程) 说明
daemon · 守护进程 永不 zombie · 系统启动即创建 P0 XiShell · P5 backend-csharp · P6 dsp-algo · P7 pysidecar · P_contracts 提供基础设施 · 业务进程依赖它
user-process · 业务进程 整体常驻 · 内部 thread 频繁 fork/zombie P1 XiLink / P2 XiForge / P3 XiTune / P4 XiTest 一个 stage 一个进程
arch-event · 架构事件进程 完成即整体 zombie · 不再唤醒 P_arch/ADR-04 / ADR-05 / ADR-06 ADR 触发 · fork N 个 U-thread · 完成后归档

3.3 线程分类(K-thread vs U-thread · 这是模型核心)

类型 生命周期 状态机 用途 是否进 RUNQ
K-thread · 常驻基础设施 与父进程同生死 · 不会 zombie sleeping(无任务)/ running(被占用)/ extending(架构升级中) 占住一块"模块/UI 区域"的所有权 + 提供 file_claims 范围 ❌ 不进(基础设施)
U-thread · 临时业务任务 完成即 zombie ready / running / blocked / zombie 进入 RUNQ 被调度器派发 · 完成后归档 ✅ 进 RUNQ

关键关系:U-thread 通过 occupies 字段声明占用的 K-thread 集合 · K-thread 是文件所有权登记 · U 完成释放 K。

3.4 RUNQ 6 步调度算法

每日 standup 由 AIOS 自动跑一次:

  1. 过滤:state == readyblocked_on == null 的 U-thread 进候选集
  2. 优先级排序:P-1 > P0 > P1 > P2(HARD-DEADLINE 临时 +1)
  3. K-thread 可获取性校验:occupies 中所有 K-thread state 必须 sleeping
  4. CPU 选择:缓存亲和优先 + 主战场亲和 + 副战场 fallback
  5. 派发执行:U-thread + occupies K 全部转 running
  6. 回收:U → zombie · K → sleeping(commit-msg hook 触发)

详见 agents/Scheduling-Algorithm.md

3.5 commit message 三元组规范(v1.2 强制 · 7 天宽限期)

<type>(<pid>.U<N>/<thread-name>): <subject>

[step=<N>/<M>] [pid=<P>] [uid=U<N>] [occupies=K<a>+K<b>+...] [files=...]
[ipc=<channel>|none]

例(P3.U2 占用 P3.K5 + P3.K7 + P0.K-shared-types):

feat(P3.U2/tuning-mode-ui): TuningModeSwitcher 复用顶栏槽

[step=2/3] [pid=P3] [uid=U2] [occupies=P3.K5+P3.K7+P0.K-shared-types]
[files=stages/xitune/TuningModeSwitcher.vue,stores/tuningModeStore.ts]
[ipc=none]

git author 仍是 ClaudeA/B/C/D/Cline-Worker(CPU 标识保留) · 但 commit message 主体只关心任务标识(类比 OS 不写"CPU 3 finished pid 1234")。


4. 全栈 10 进程拓扑(v1.2 新增 · v0.3 决议)

docs/08-implementation/40-aios/processes/
├── P0-xishell/         (daemon · 9 K · 全局 shell 基础设施 · ClaudeA 主战场)
├── P1-xilink/          (user-process · 7 K · 弦录链路 · ClaudeA)
├── P2-xiforge/         (user-process · 7 K · 模块创建器 · ClaudeB)
├── P3-xitune/          (user-process · 7 K · 调音 stage · ClaudeC)
├── P4-xitest/          (user-process · 6 K · 测试 stage · ClaudeD · 当前 blocked)
├── P5-backend-csharp/  (daemon · 9 K · C# 后端 · ClaudeB)
├── P6-dsp-algo/        (daemon · 6 K · DSP 算法 · ClaudeB)
├── P7-pysidecar/       (daemon · 3 K · Python 侧车 · ClaudeB 兼管)
├── P_contracts/        (daemon · 1 K · 跨栈契约 · ClaudeB 写独占 · ⚠️ Day 5 HARD-DEADLINE)
└── P_arch/             (arch-event 容器 · 0 K · ADR-04/05/06 子进程)

统计:10 进程 · 55 K-thread · 40+ U-thread。

详见 PCB.md(进程总览)+ INDEX.md §1(跳转表)。


5. 9 个 CPU 是谁(v1.2 · v3 5 角色升级)

5.1 总表

实例 类型 主战场 业务代码红线
Cline-AIOS 调度内核(本会话) 维护 PCB/RUNQ/ADR/agents 严禁写业务代码
ClaudeA 并发域 A · CPU #1 P0+P1+P2+P3+P4+P_contracts(前端契约) ✅ 可写
ClaudeB 并发域 A · CPU #2 P5+P6+P_contracts(后端契约)+ P7 兼管 ✅ 可写
ClaudeC 并发域 A · CPU #3(机动) 机动(P0-P4 任意)+ P6 部分 ✅ 可写
ClaudeD 并发域 A · CPU #4(机动+测试) 机动 + P4-xitest 优先 + P7 维护 ✅ 可写
Cline-Worker 并发域 B · 主力 work-cline/ 多 stage 同步开发 ✅ 可写
Copilot-Worker 并发域 B · 辅助 work-copilot/ · 当前 P5.U-refresh-link ✅ 可写
Continue-Worker 并发域 B · 备用 work-continue/ · Continue 文档同步 ✅ 可写(限文档/备份)
DeepSeek-Worker 并发域 B · 深度备用 work-deepseek/ · 默认不调度 ✅ 可写
Copilot 内联 IDE 行内补全(不入 RUNQ) 人类打字时灰字补全 ❌ 不 commit

详见 agents/Roster.md v4(9 CPU 实例完整身份证 + 主战场表)。

5.2 你不需要记的事

5.3 你必须记的事

  • commit hash 是货币:每天 standup 时把昨天的 commit hash 给 AIOS · 它据此更新 PCB(可用 scripts/aios-standup-fetch.ps1 自动抓)
  • 决策升级链终点是你:CPU 打架 → AIOS 仲裁 → 仲裁不下来 → 升级到你 → 你的话写成 ADR
  • Cline 双实例分离:Cline-AIOS(本会话 · 不写业务代码)与 Cline-Worker(work-cline/ · 业务 CPU 主力)是两个独立实例

6. 你每天要做什么(10 分钟)

6.1 晨间 standup(5 分钟)

省力法:直接说 "帮我抓取 standup" → AIOS 跑 scripts/aios-standup-fetch.ps1 → 5 段输出(commit + PCB §0/§5/§7 + 硬截止预警 + RUNQ 派发结果)→ 你追加阻塞/优先级即可。

手动法:打开 Human-Daily-Standup.md 按模板把昨天的 4 行情报喂给 AIOS:

昨天 commit:
  - ClaudeA: <hash> "feat(P1.U1/xilink-finalize): Step A 完成"
  - ClaudeB: <hash> "feat(P_contracts.U-§1-§3/B1): protocol-v1 §1-§3 草稿"
  - ClaudeC: <hash> "fix(P3.U-test-fix-post-p0): Group B 2 行修复"
  - Continue-Worker: <hash> "docs(40-aios): commit 同步"
阻塞:
  - P4 全部 6 项 ⚪ 等 P3.U4-test-aux-extract 完成
今天目标:
  - 派 P2.U5-module-uid-namespace 给 ClaudeB(⚠️ contract-v1 freeze 前)
  - 派 P3.U4-test-aux-extract 给 ClaudeC(P4 解锁前置)
特殊事项: P_contracts.U-freeze-tag 距离 Day 5 HARD-DEADLINE 还剩 X 天

AIOS 收到后会自动派发当日 U-thread。

6.2 中午查 PCB / RUNQ(2 分钟)

打开 PCB.md §0 "今日聚焦" + §0.3 "阻塞 / 仲裁" · 看一眼有没有"红色阻塞行"或新仲裁。如果有,回 IDE 窗口看哪个 CPU 卡住了。

6.3 晚间 commit 收口(3 分钟)

收集今天各 CPU 的 commit hash · 明天 standup 用(或让 standup 抓取脚本自动抓)。


7. 你不要做的事 ⚠️

❌ 不要 ✅ 应该
同时给 2 个 CPU 派同一个 K-thread 的 U-thread RUNQ 自动用 K-thread 状态机隔离(K-thread 一次只能一个 U-thread 占用)
直接改 ClaudeA 正在改的 K-thread 内文件 让 ClaudeA U-thread zombie 后 · 你 review
在 contract-v1 没 freeze 时让 ClaudeA 写 protocol 相关代码 先催 ClaudeB 把 P_contracts.U-freeze-tag 完成(Day 5 EOD HARD-DEADLINE)
跳过 RUNQ 直接派 U-thread 任何任务先在 PROCESS.md 起 U-thread state: ready · 进 RUNQ 才能派
自己手动改 40-aios/ 下的文档 让 AIOS(本会话)帮你改(这里是调度元数据 · [need: Cline-AIOS] trailer)
在不需要 AIOS 时被强制套上 AIOS 角色 新会话首句说"普通模式"(见 §2)
自己改 30-frontend-vue3/active/archive/ 路径 PROMPT 这些已 git mv 到 processes/<pid>/user_threads/<U>/STEP.md(见 INDEX.md §2)

8. 何时该停下来介入

🟢 不需要介入(AIOS 自己处理)

  • ClaudeA 卡 30 分钟想不出 Pinia 类型 → AIOS 派"提示加强版"
  • Continue-Worker 卡顿 → AIOS 切到备份方案
  • U-thread 提示词不够清晰 → AIOS 自己迭代

🟡 需要你简短回复(1 分钟)

  • 两个 CPU 对契约协议有分歧 → 你说一句"按 A 来" → AIOS 写 ADR
  • RUNQ 出现优先级冲突 → 你拍板谁先做
  • K-thread.file_claims 范围扩展(架构升级)→ 你确认 ADR 描述

🔴 需要你深度介入(停下所有任务)

  • P_contracts.U-freeze-tag(contract-v1.0 freeze · Day 5 EOD)前的最后一审 · 你必须读一遍
  • P5.U-source-sink-api(Week 3 末)/ P5.U-preset-crud-api(Week 5 末)如延期 · 立即仲裁
  • P2.U5-module-uid-namespace 在 contract-v1 freeze 前如延期 · 立即仲裁
  • 出现"CPU 行为漂移"(U-thread 提示词被错误理解 · 反复改错方向)
  • 用户/客户的真实需求变更
  • 任何 commit 越权(比如 ClaudeA 改了 P5 后端 / Cline-AIOS 写了业务代码)→ 立即仲裁

9. AIOS 的承诺

承诺 兑现方式
不让你看任何技术细节 跨进程协作由 P_contracts 中转 · 你只看 commit message 三元组
每天给你一份 PCB + RUNQ 自动维护(你只读不写)
决策有据可查 所有重大决定写 ADR · 永久存档 · ADR-NN fork P_arch/ADR-NN/ 子进程
加速 30%+(v1.2 升级) 9 CPU 并行 + 文件级隔离(替代 v1 目录级)+ K-thread 状态机调度
不打扰你做普通工作 默认询问后再激活 AIOS 模式(见 §2)· 4 种禁用通道随时关掉
commit message 可读性 三元组 [pid=][uid=][occupies=] · git log --grep "P3.U2" 直接拿到全部 commit

10. 工程背景速查(v1.1 沉淀 · v1.2 路径更新)

10.1 v3 → v4 写权限模型升级

维度 v3(已升级) v4(当前)
权限单元 目录(粗粒度) K-thread.file_claims(细到文件级)
隔离 目录级互斥 文件级 conflict avoidance(同目录不同文件可并发)
冲突检测 git author + 路径 grep commit-msg hook 三元组校验
控制结构 lock 协议 K-thread state 状态机(sleeping/running/extending)

详见 agents/Repository-Partition.md v4(file_claims 协议 + 全栈 10 进程写权限矩阵)。

10.2 IA v3 9 一级目录(已定稿 · 沿用 v1.1)

00-home / 01-strategy / 02-products / 03-platform / 04-departments / 05-standards / 06-customer / 07-engineering / 08-implementation / 09-testing-ops / 99-archive

10.3 md 协作规范(沿用 v1.1)

10.4 视觉红线(P0 决议 · 沿用 v1.1)

  • 色系法典:xiyin-brand.css 不允许动 hex 值 / Hero 三色 / L0-L5 6 色 / --gradient-* 渐变
  • 视觉只受 4 文件控制:overrides/main.html + xiyin-brand.css + xiyin-extra.css + xiyin-patch.css
  • 首页 vs 其他页:level=l1a 走 Hero · 其他页 level=l3 走 Stripe 三栏
  • Stripe 媒体查询断点:768px / 双触发选择器消 SSR FOUC
  • 10 决议品牌组件:.xy-quote / .xy-glossary / Admonition 6 组 / Tabs 玫瑰金 / Subgraph 6 色 / 甘特双轨 / Mermaid modal / 数学双轨 / .xy-stack L0-L5 / Stripe 深海军蓝 + 玫瑰金

10.5 跨 CPU 协作信号(v1.2 升级)

发现非自己主战场的 K-thread 有 bug 时 · 在 commit message 加 trailer:

[need: ClaudeA] P0.K3 bug at <file>:<line>   # ClaudeB → ClaudeA 修前端 K-thread
[need: ClaudeB] P5.K5 bug at <file>:<line>   # ClaudeA → ClaudeB 修后端 K-thread
[need: Cline-AIOS] PROCESS.md 字段需要更新   # 业务 CPU → 调度内核

由 AIOS 在每日 standup 时中转派活 · 禁止自己 stash 后跨进程改。


11. 出问题怎么办

症状 解法
CPU 卡死 关掉重开 · PCB 标该 U-thread state: blocked · 等 AIOS 重新派
commit 冲突 git stash · AIOS 仲裁 · 一方让步
commit-msg hook 拒绝 检查 [occupies=] 是否包含 [files=] 涉及的所有 K-thread
U-thread 提示词执行偏差 在 standup 时报告 · AIOS 改 STEP.md + prompts/templates/
你忘了今天该干啥 PCB.md 的"今日聚焦"段 + RUNQ.md 阻塞队列
找不到某个文档 INDEX.md 全局索引(替代旧 INDEX-PROMPTS.md)
找不到某个 PROMPT INDEX.md §2 "17 PROMPT 旧→新路径映射"(6 个月宽限期)
AIOS 在不该出现时出现 用 §2 的 4 种禁用方式之一
Cline 进仓库不自动询问模式 检查 .clinerules/aios-orchestration.md 是否存在 + Cline 设置面板是否勾选
进程 PCB 与 PROCESS.md 不一致 processes/<pid>/PROCESS.md 为权威 · 让 AIOS 重新刷 PCB.md

12. 下一步阅读

必读(v1.2 入门路径)

  1. Human-Quick-Start.md —— 第一天怎么开干
  2. Human-Daily-Standup.md —— 每日 standup 模板(待 T14 升级 RUNQ 派发结果格式)
  3. PCB.md —— 进程总览(替代旧 KANBAN.md §1-§4)
  4. RUNQ.md —— 就绪队列骨架(v1.0 待 T20)
  5. INDEX.md —— 全局索引(10 进程跳转 + 17 PROMPT 路径映射)

进阶(规范文档)

  1. agents/Roster.md v4 —— 9 CPU 实例完整身份证 + 主战场表
  2. agents/Repository-Partition.md v4 —— K-thread.file_claims 协议
  3. agents/Process-Model.md —— 进程/线程/PCB/RUNQ 概念详述
  4. agents/Scheduling-Algorithm.md —— RUNQ 6 步调度算法
  5. agents/Commit-Convention.md —— commit message 三元组规范 + git hook
  6. agents/Concurrency-Domains.md —— 二层并发域协议

决议(ADR)

  1. ADR/ADR-AIOS-06-os-style-task-scheduling.md v0.3 —— OS 化模型决议(本次重构)
  2. ADR/ADR-AIOS-04-xiforge-architecture.md —— XiForge 架构(P2 主线)
  3. ADR/ADR-AIOS-05-xistudio-workspace.md —— XiStudio Workspace(P0/P3 主线)

历史

  1. KANBAN-archive-v6.md —— 历史 KANBAN(v1-v6 完整字段保留)

仓库根

  1. .clinerules/aios-orchestration.md —— AIOS 调度内核完整指令(待 T15 升级 v1.2)
  2. .clinerules/xisound-docs-migration.md(工作区根)—— 文档创作 + 视觉调优 + 工程代码位置铁律 v2.0

13. 版本演进

版本 日期 变化
v1.0 2026-05-19 上午 初始版本(4 智能体框架)
v1.1 2026-05-19 晚 5 角色 v3 + §1.5 .clinerules 双文件机制 + §1.6 工程背景速查
v1.2 2026-05-26 OS 化模型 · 9 CPU 实例 · 全栈 10 进程拓扑 · §3 OS 模型速查 · §4 进程拓扑 · §5 9 CPU 实例 · 入口从 KANBAN.md 升级到 PCB.md / RUNQ.md / INDEX.md · commit-msg 三元组规范 · 配合 ADR-AIOS-06 v0.3

一句话总结(v1.2):AIOS 帮你把 9 个 CPU 当 1 个团队管 · 任务装在 10 个进程里 · 你只管说"想要什么" · RUNQ 调度算法 + commit-msg 三元组保证零冲突。进仓库先拍板模式(.clinerules/aios-orchestration.md),想关随时关(4 种通道)。