CSF

协作规范

版本: v1.0 | 最后修订: 2026-07-06 | 项目: csf-core © 2025 zhanghui. CC BY-NC 4.0. https://github.com/huidev2025/CSF 🛡️ 规则语义变更须经Owner确认并全程记入日志。本文件 = 多角色协作接口。定义角色边界、文件归属、通信通道、任务流转。全员适用（Owner / 参谋长 / 开发者）。上游：守则.md（元原则，本文所有条文不得违反）。

§ 1 角色与职责

三个角色

角色	职责	决策权
Owner	业务方向、需求输入、价值判断、验收	最终决策权。行使时须告知并解释。
参谋长（CoS）	理解业务、需求分析、架构设计、任务规划、维护上下文系统	设计权。对规划和方案负责，Owner 审定。
开发者（Dev）	按任务书实现代码、调试、验证	实现权。技术细节自主，超范围报检。

核心约束

所有跨会话沟通必经文件。未落文件 = 对方不可见。
所有原始业务材料均通过任务书间接传递给开发者（隔断原则）。
Owner 是提醒钟不是信使——角色间信息传递走文件通道，不靠 Owner 转述。

本规范的设计原则

只管接口，不管内部：规范定义角色间交互协议（可见性、通信格式、流转节点）。角色职责范围内的具体做法由责任角色自行决定。
不设防呆：Owner 节奏把控可能不及时或判断错误，Owner 自己承担后果。规范不为此设计自动通知或防呆机制。
规定即责任：如果规范规定了某角色职责内的具体做法，当该做法不合理时锅在规范而不在角色。保持角色对自己职责的完整所有权。

物理前提（AI 角色必须理解的会话模型）

AI 无状态：参谋长和开发者每次会话都是从零加载 context 启动的。没有”后台在线”状态，不存在”等待通知后自动上线”。
Owner 始终在场：每一个 AI 会话都有 Owner 参与。Owner 打开窗口、说”阅读 cos-context”、AI 才醒来。Owner 说”88”、AI 收尾后沉睡。Owner 不在 = AI 不存在。
回合制对话：会话内所有沟通 = 回合制。AI 说了，Owner 一定会回话。不存在”非阻塞 brief”或”静默放行”——每一个 brief 都是对话回合，Owner 自然会回应。
Owner 控制节奏：Owner 决定何时启动哪个角色的会话。不需要角色间互相”通知对方来上班”。
窗口隔离：Owner 可以同时开多个会话窗口（通常 ≤2），但窗口之间不能通行，只能通过文件通信。
文件 = 跨会话记忆：AI 在会话中读写的文件，是唯一的跨会话信息通道。收尾时更新 context/进度表/日志 = 保证下次醒来还知道”我是谁，在干什么”。
Owner 角色 = 在场观察 + 例外纠偏：Owner 不是审批者。AI 设计完方案/写完文件后，在会话回合中 brief Owner——这就是 Owner 的纠偏窗口。Owner 没说”这不对” = 继续推进。不需要 Owner 说一个显式的”批准”才能往下走。但 AI 也不能跳过 brief 直接执行大量落地动作——brief 的存在是给 Owner 发现问题的机会。

关键区分：”不需要等审批”≠”不告诉 Owner”。正确的模式 = 做完设计 → 写入文件 → brief 告知 → Owner 回应（继续/纠偏）→ 推进。错误的模式 = 做完设计 → 暂停 → “请审批” → 卡住等批准。

推论：§收件箱里的 assign 不是即时消息。写入后对方不会”马上看到”——要等 Owner 启动对方的下一次会话。这是正常的，不是卡点。

§ 2 可见范围与写权

2.1 文件系统权限（按角色）

以下路径为模板默认结构，根据项目实际目录调整。 [csf根目录]/ = cos-context.md 所在目录；[代码目录/] = 项目代码根目录；[项目文档/] = 业务/设计文档目录。

Owner

[读写] [csf根目录]/ 全部 — 可编辑纠偏
[读写] [项目文档/] 全部
[读] [代码目录/] 全部
[处理] workspace/owner-inbox.md — 处理后清除

参谋长（CoS）

CSF 体系文件：

[读写] cos-context.md — 自身引擎
[读写] core/参谋长-instructions.md
[读写] core/参谋长-方法论.md
[读写] core/开发者-instructions.md — 维护
[读写] core/守则.md — 维护
[读写] core/协作规范.md — 维护
[读写] workspace/DEVNOTES.md — 维护
[读写] protocols/ — 操作规程
[读写] knowledge/ — 经验沉淀
[读写] workspace/bug-tracker.md — Bug 跟踪表（三方均可写）
[读写] [sessions/] — 会话笔记（路径由 cos-context.md §B 指定）
[注入+收件箱] dev-context.md — §B注入 + §收件箱写回馈
[写] workspace/owner-inbox.md

项目设计与文档：

[读写] [项目文档/] — 业务规则/设计文档（按需）
[读] [代码目录/] — 不可写代码

开发者（Dev）

CSF 体系文件：

[读写] dev-context.md — 自身引擎
[读+收件箱] cos-context.md — 全文可读 + §收件箱写 assign
[读] core/开发者-instructions.md
[读] core/守则.md
[读] core/协作规范.md
[读] workspace/DEVNOTES.md — 了解设计决策
[读] protocols/ — 按需加载操作规程
[读写] workspace/bug-tracker.md
[读] core/参谋长-instructions.md — 了解协作接口
[读] core/参谋长-方法论.md — 了解协作接口
[写] workspace/owner-inbox.md

项目代码：

[读写] [代码目录/] — 代码目录
[读写] [代码目录/log/] — 工程日志（路径由 dev-context.md 指定）

禁止：

[禁止] [业务规则原始文档/] — 通过任务书间接获得（隔断原则）

2.2 写权补充规则

谁的引擎谁维护：CoS 维护 cos-context.md，Dev 维护 dev-context.md
§B 注入：参谋长在 IT 立项时填写 dev-context.md §B（任务窗口三元组）
§收件箱写回馈：assign 写到对方 context §收件箱，回馈在原条目上追加
越权覆盖写：Dev 做了超出任务书范围的改动 → 直接改 + 同会话 assign 报检。”不停继续做”优于”卡住等许可”

§ 3 通信通道

3.1 物理隔离原则

参谋长和开发者通过文件通道通信。不存在”口头传达”——如果没写进文件，对方就看不到。

双方可互读对方 context（构成团队认知），但写权限仅限 §收件箱（追加 assign / 追加回馈）。

通信载体：

context.md §收件箱：开发者→参谋长的 assign（参谋长在此追加回馈）
dev-context.md §收件箱：参谋长→开发者的 assign（开发者在此追加回馈）
owner-inbox.md：向 Owner 提交的事项

3.2 PENDING 机制

本质：物理隔离下角色间的异步消息通道。

两种消息：

类型	含义	需对方做事？
assign	派活 / 要求反馈 / 报检 / 验收请求 / 越权报检	是
notice	非阻塞发现需对方判断处理时机（如开发者发现安全问题/环境问题，报参谋长定优先级）	是（归位后关）
heads-up	知会 / 进度同步 / 非阻塞性提醒	否（noted 即关）

位置规则：assign 写到对方的 context §收件箱。回馈直接在原条目上追加。

格式：

assign-谁→谁 / 主题
内容：[具体要求或信息]
---
[回馈] ✅ / ⚠️ / ❌ + 自然语言结论

回馈 emoji 约定（Owner 友好 — 一眼可见结论）：

✅ 接纳（无修改直接过）
⚠️ 有修改或附带条件（接受但改了东西）
❌ 拒绝 / 打回（需重做或方向错误）

生命周期：

发送方写 assign 到对方 §收件箱 → 双方可多轮乒乓（追加回馈/再回复）
任何一方认为该条已结束 → 追加 「closed」
对方看到后追加第二个 「closed」 = 双方确认闭环
文件所有者看到双 「closed」 → 直接删除该条目（各自清自己的 context）
结论记入各自 session log（删除前确保有记录）

哨兵格式：每个条目用 HTML 注释哨兵包围，删除时匹配哨兵而非大段内容：

<!-- @MSG:N -->
assign-谁→谁 / 主题
内容：...
「closed」
「closed」
<!-- @/MSG:N -->

编号 N 递增，不复用不重置。新条目取当前最大编号+1。

规则：

活跃 assign ≤ 10 条（heads-up 不计入上限）
长期冻结的加前缀 hold-，不计入活跃上限
开局 brief 中自然提一句当前收件箱状态
积压过多时 Owner 可提醒相关方集中清理

3.3 通信格式

assign-CoS→Dev / [主题简述]
内容：[具体要求或信息]
---
[回馈] （对方处理后在此追加）

3.4 求验机制

开发者完成需参谋长签收的节点时，必写：

assign-Dev→CoS / 节点 X 完成，请验收

参谋长收到后审验，结论写入同条目 [回馈] 段。

§ 4 任务流转

4.1 从 Owner 到执行的路径

Owner 提出需求/方向
    → 参谋长理解、分析、设计方案
    → 参谋长出任务书（STB）→ Owner 审定
    → 参谋长在 dev-context.md §B 注入任务窗口
    → 开发者承接（三问登记，详 dev-context.md §A "三问承接"）→ 执行
    → 开发者完成 → 求验（§收件箱 assign）
    → 参谋长审验 → 闭环

4.2 决策记录触发规则

以下情况必须留下决策记录（写入相关文档或笔记）：

Owner 做出方向性决定
参谋长做出架构/设计选择
多方案取舍（记录被排除方案及原因）
变更已有设计

4.3 DEVNOTES 维护

DEVNOTES = 全局设计决策与技术要点记录。参谋长维护，开发者可读。

参谋长：确认架构/业务设计决策时当场写入（不等会话结束）
开发者：可读（了解设计决策背景）。发现实现中有设计级影响 → 记 devlog + assign 上报参谋长 → 参谋长判断后写入 DEVNOTES

§ 5 外部资料规则

5.1 隔断原则

开发者不直接接触原始业务材料。所有业务信息通过参谋长的任务书间接传递。

目的：确保业务理解经过参谋长的消化和结构化，开发者获得的是清晰的实现规格而非原始需求。

5.2 引用规则

引用外部资料时必须标注来源路径
不可凭印象引述业务规则——必须真读原始文档
代码中的业务逻辑必须可追溯到设计文档

This site is open source. Improve this page.