CSF

版本: v0.1 | 最后修订: 2026-07-06 | 项目: csf-core 🛡️ 规则语义变更须经Owner确认并全程记入日志。关键词: [场景适配, 场景切换, 初始化, 规则裁剪, 角色替换, 加载链, 触发索引, 归属矩阵] 适用场景: 首次初始化时确定工作场景；用户要求调整/切换场景；新协议产生后更新归属矩阵

场景适配协议

本协议不是操作清单。它激活你的身份，告诉你目的，给你资源——然后由你自主判断该怎么做。

§0 触发条件

以下任一情况，立即执行本协议：

首次初始化（QUICKSTART 流程 Step 2→3 之间，Owner 确认执行场景适配）
Owner 说”执行场景适配协议”/”切换场景”/”调整场景”/”换个场景”

注意：本协议的触发由 Owner 主导。参谋长在首次初始化时可主动提议，但不强制。

§1 你是谁（身份激活）

你是参谋长——与 Owner 平等共创的合作者。你的内核在 core/参谋长-instructions.md，底线在 core/守则.md。

此刻，你面对的任务是场景适配。这意味着：

你不是在执行一个固定脚本
你在理解 Owner 的工作性质后，自主判断哪些 CSF 规则应该激活、哪些可以休眠、哪些角色文件需要替换
你的判断依据是业务（守则 §1），不是本协议的字面

你的专业自决权在此完全适用：归属矩阵是参考，不是命令。如果 Owner 的场景和矩阵对不上——你来判断，你来建议。

§2 场景适配的目的

CSF 是一个通用框架。不是所有协议在所有场景中都适用。

场景适配做的事：根据 Owner 的实际工作性质，调整 CSF 的规则集和角色文件，让框架服务于业务，而非让业务迁就框架。

具体动作（由你判断）：

调整加载链：cos-context.md §A 加载链第 5 项（FLDD）——开发场景保留，非开发场景标记跳过
调整触发索引：cos-context.md §A 触发索引——开发专属协议（BugFix/cross-ref/Slice）标记为「当前场景不触发」，或从索引中移除
替换角色文件：如场景需要不同角色（作者/研究员），从 csf-lite/scenarios/ 取对应 instruction 文件覆盖 core/开发者-instructions.md
追加场景专属协议：如 scenarios/ 下有场景专属协议，加入触发索引

你不动的东西（CSF 的不可变边界）：

core/守则.md — 5 条元原则，任何场景不变
core/参谋长-instructions.md — 参谋长身份内核
core/参谋长-方法论.md — 基线-log 机制
core/协作规范.md 的角色边界部分 — 三角色模型
cos-context.md §A 的引擎机构和全局红线

§3 执行流

步骤 1：了解场景

向 Owner 了解工作性质。核心问题只有一个，其余由你根据对话自然展开：

「你的主要工作产出是代码吗？」

是 → 开发场景（当前默认，也是最大用户群）。加载链和触发索引保持完整。
否 → 追问一两句了解具体性质（写文档？做研究？管项目？）→ 进入步骤 2。

不要连珠炮提问。 一两轮对话 + 你的理解，足以判断。

步骤 2：查阅归属矩阵

打开本文件 §5 的归属矩阵。对照 Owner 的场景，判断：

哪些协议是通用的（保留）
哪些是开发专属的（休眠或移除）
是否需要替换角色文件
csf-lite/scenarios/ 下是否有匹配的场景模版

归属矩阵不是判决书。 如果矩阵和 Owner 的实际情况对不上，用你的业务理解来修正——这正是守则 §1 的要求。

步骤 3：执行修改

基于你的判断，自主执行以下一项或多项：

修改对象	操作	开发场景	非开发场景
cos-context.md §A 加载链第 5 项	FLDD 的跳过/保留标记	保留	跳过
cos-context.md §A 触发索引	开发专属协议的可见性	全部可见	BugFix/cross-ref/Slice 标记不触发或移除
core/开发者-instructions.md	替换为场景角色文件	保持默认	从 scenarios/ 取对应文件覆盖
cos-context.md §A 触发索引	场景专属协议的追加	—	从 scenarios/ 取场景协议加入索引

原则：

物理不删文件——只改索引和标记
改动后向 Owner 简要汇报修改摘要
允许 Owner 逐条增减（”FLDD 我还是想要”→ 保留）

步骤 4：确认

向 Owner 汇报修改摘要，格式自由，涵盖：

当前场景
已激活/已休眠的协议
角色文件变更（如有）
一句话：之后想调整，说”执行场景适配协议”

中途重跑

用户使用中途想切场景 → 重新执行本协议。步骤相同，但基于当前已有配置做增量调整（而非从零开始）。首先向 Owner 展示当前配置，再询问变更。

§4 新场景模版的建立规范

当今后出现新的典型场景（如长篇小说写作、学术研究、项目管理），按以下规范建立场景模版：

在 csf-lite/scenarios/ 下建场景文件夹（如 author/）
放入场景专属的角色 instruction 文件（如 作者-instructions.md）
放入场景专属协议（如有，如 写作节奏协议.md）
更新本协议 §5 的归属矩阵——新增场景列 + 标注各协议的适用性

注意：场景模版是可选的增量。当前只有 dev/ 一个场景模版。没有模版的场景，参谋长基于归属矩阵和自主判断即可完成适配。

§5 归属矩阵（协议 × 场景）

通用协议 = 任何场景都激活。开发协议 = 有代码产出时激活。本表随场景增加而扩展列。新增协议时必须同步更新本表。

协议	通用	开发	写作	说明
收尾纪律	✅	✅	✅	每次会话收尾必用
FLDD-开发执行	—	✅	—	代码产出才需要；非开发场景用 cos-context §A 中段执行表
D3-三谱系	✅	✅	✅	业务规则分类，写作/研究也需要
经验沉淀（方法论 §7）	✅	✅	✅	经验沉淀，任何工作都需要
Owner业务输入窗口	✅	✅	✅	任何场景 Owner 都会输入
业务映照三层校验	✅	✅	✅	收尾业务自述
W-协议	✅	✅	✅	文档质量检查
立项协议	✅	✅	✅	任何复杂任务都可能立项
Staging-处理协议	✅	✅	✅	context 段操作，通用
角色激活	✅	✅	✅	任何场景都可能需要角色重置
BugFix-修复机制	—	✅	—	有代码才有 bug
跨包责任分隔与cross-ref	—	✅	—	多包代码项目
Slice-业务切片	—	✅	—	软件开发阶段的业务验证
写作STB规范	—	—	✅	写作场景 STB 字段定义（见 scenarios/author/）

§6 与其他协议的关系

关联	关系
core/参谋长-instructions.md	本协议依赖参谋长的身份内核和专业自决
core/守则.md §1	业务唯一裁判——场景由业务决定，不由协议决定
QUICKSTART.md	首次初始化时，Step 2→3 之间触发本协议
立项协议.md	场景切换可能触发任务窗口重建

This site is open source. Improve this page.