CSF 中有三个参与者：Owner（人）、参谋长（CoS, Chief of Staff）、开发者（Dev, Developer）。
这个分工不是组织架构设计的产物，而是从目的理论直接推导出来的。
目的有层次（宏观 + 具体），目的会漂移，目的需要在场观察者校准——这三条事实决定了至少需要三种能力在场：
三个角色不是三个人，是三种职能。同一个人或同一个 AI 实例可以在不同时刻承担不同角色，但角色之间的边界必须清晰——因为混淆职能会导致目的层次坍塌：当规划者同时在执行时，宏观目的容易被执行细节淹没。
传统的角色分工通常是为了控制：谁有权做什么，谁向谁汇报，审批流程是什么。CSF 的角色分工不是这个逻辑。
CSF 的分工是为了让每个参与者的活性用在最有价值的地方。
Owner 的活性最有价值的地方：发现宏观方向的偏移、做出价值判断、引入 AI 无法独立生成的实践经验。不应该浪费在具体的技术决策或执行细节上。
参谋长的活性最有价值的地方：理解宏观目的并将其转化为可执行的计划、维护上下文的准确性、在规划层面做出判断。不应该浪费在代码实现上。
开发者的活性最有价值的地方：在明确的三元组框架内，利用对技术的深度理解做出实现层面的判断。不应该浪费在猜测宏观目的上。
这个分工结构的前提是第一条被接受的事实——AI 有非程序性智能。如果 AI 只是一个确定性执行器，分工就退化为传统的权限控制。正因为 AI 有活性，它的活性需要被引导到正确的方向——目的引导活性，分工保证目的不被混淆。
有人会问：为什么不能用更精确的协议和流程来替代这种角色分工？把每种情况都写成规则，AI 按规则执行，不就不需要 Owner 在回路了吗？
这做不到。原因在第一条被接受的事实里已经说了——人和 AI 都有活思想，边界情境下的决策无法被协议预先规定。
更具体地说：协议只能约束程序性行为——”收到 A 类请求时执行 B 流程”。但活性系统的关键决策点往往发生在边界情境——协议没有覆盖的灰色地带、两条规则冲突的场景、需要在多个合理选项之间做价值判断的时刻。这些场景不是可以通过增加协议条目来消除的，它们是活性系统的固有属性。
协议越多，维护成本越高，而且协议之间的冲突也越多——这和符号索引的四重失败机制是同一个结构：复杂度增加不会带来更好的控制，只会带来更脆弱的系统。
因此：人必须持续在回路，不是作为协议失效时的补丁，而是作为活性系统的设计前提。Owner 在回路是 CSF 的结构性需求，不是管理偏好。
一个系统如果只能执行，不能从执行中学习，它就无法对抗熵增——随着项目复杂度增加，执行质量会不可逆地下降。
CSF 通过一条经验反馈通路建立了能力增长机制。
反馈通路的基本逻辑是：项目执行中遇到的困难和失败，不只是被解决，而是被提炼为方法和经验，然后固化为可以在后续任务中调用的插件或规范。
用最直白的话说：研发在记日记。
一次失败的调试经历 → 提炼出一条调试方法 → 写入方法论库 → 下次遇到类似问题，方法论库被加载进窗口 → AI 凭活性识别相关性并应用。研发的水平就这样提高了。
这个机制的工程实现依赖前面讲过的三个机制：
能力增长发生在工程层，独立于模型层。 这是一个重要的区分。
主流的能力增长路径是改变模型本身——微调、训练、RLHF。但工程层有一条独立的能力增长通道：不改变模型，通过积累和组织经验，系统的工程能力持续提升。这就像软件升级和 CPU 升级是两件正交的事——软件质量的提升不依赖硬件换代，硬件换代也不能替代软件质量的积累。
这条通道的成本极低（日常记录提炼）、积累可见（方法论库的增长）、可直接复用（下次加载即可用）。它对”只有更好的模型才能获得更好的结果”这一主流假设是一个直接挑战——在 CSF 的实践中，同一个模型，在更好的工程层支持下，确实产出了更好的结果。
角色分工让活性被引导到最有价值的方向；经验反馈通路让系统在运行中积累能力，对抗熵增。两者都不是传统意义上的管理手段——它们是目的理论在组织层面和时间维度上的延伸。
最后一个问题：CSF 到底是什么？它在已有的方法论版图中处于什么位置？这是下一篇的内容。