前三篇交代了 CSF 的理论基础：自然语言信息量优于符号系统（公理），AI 有活性且语义稀释不可逆（两条被接受的事实），目的是语义激活的控制单元（目的理论）。
这些理论如果不落地为工程机制，就只是观点。CSF 有三个核心工程机制，把理论转化为可操作的工作方式：三元组、架构语义地图、滑动窗口。三者不是独立的工具，而是一个配合系统——架构决定”加载什么”，三元组在入口”激活目的”，滑动窗口保证”宏观微观同时在场”。
三元组是 CSF 中组织工作的基本单元，形式是：目的 + 方法 + 资源。
三个要素不是并列的，有明确的主从结构：目的在主位，方法和资源是目的确定之后随之确定的。这就是上一篇说的”目的一旦确定，方法和资源随之确定”在工程上的具体落地。
一个具体的例子：
目的：实现”任务发布”云函数，让 Owner 能通过小程序发布悬赏任务
方法：按 createJob spec 实现，遵循云函数错误码规范，写入前校验权限
资源：docs/spec/cf-createJob.md（接口契约）、docs/domain/job-lifecycle.md（业务生命周期）、cloudfunctions/createJob/（代码目录）
AI 在开始工作时读到这个三元组，三件事同时发生：宏观目的在场（这个函数在整个系统里扮演什么角色），具体目的锁定（现在就是要实现这个函数），方法和资源已经圈定（不需要 AI 自己去猜应该读哪些文件）。
三元组的关键设计意图不是组织方法——它是目的激活器。在每个工作单元的入口处，把当前目的重新显式激活一次。长期项目中 AI 反复工作，低头干活时目的会被细节淹没。三元组在入口处强制”抬头看路”——宏观目的在场，然后”低头干活”——具体目的锁定。
三元组把目的内建到知识组织里，而不是在执行时作为外部查询输入。这是 CSF 和 RAG 的根本结构差异。
RAG 的逻辑：先存储知识（无目的属性），再在检索时用查询语句（目的的代理）去匹配相似内容。目的是检索时才注入的，知识本身是无目的的。
三元组的逻辑：目的在知识被组织时就内建进去了。加载一个三元组，目的同时在场，不需要在执行时另行注入。
这个差异在实践中意味着：三元组的加载是目的驱动的语义激活，RAG 的检索是无目的的相似度驱动。即使新一代语义分块 RAG 在切分粒度上接近语义完整，这个根本差异依然存在——RAG 的目的始终是后置的，三元组的目的始终是前置的。
更根本的层次差异是：RAG 是形式化层的机制（向量相似度），用来对接语义层的系统（LLM）——这是层次错配。LLM 已经在语义层工作了，用形式化方法给它索引信息，是用前朝的工具解决当朝的问题。三元组直接在语义层工作——用自然语言描述目的，用自然语言组织资源，让 LLM 在它原生的工作层上完成理解。
三元组的”资源”从哪里来？怎么知道一个任务应该加载哪些文件？
答案是：软件架构。
业务概念架构——以业务职责和领域概念为边界，而非以技术分层（controller/service/dao）为边界——是问题域语义结构的最优编码。架构的每一个边界，就是语义的一个边界。加载一个业务切片，就是加载一个语义完整的单元。
这意味着：以架构为索引加载上下文，天然保证语义内聚性和目的对齐。不需要另外建检索系统来寻找”相关内容”——架构已经告诉你什么是相关的。架构解耦就是语义解耦——一个设计良好的架构，它的模块边界与 AI 需要的上下文边界天然一致。
领域驱动设计（DDD）是这个思想的历史锚点。Eric Evans 的”限界上下文”——一个领域概念在一个边界内保持一致的含义——与 CSF 的架构语义隔离直接对应。但 DDD 没有与 LLM 上下文管理结合。将 DDD 的语义隔离原则迁移到 LLM 上下文加载，是 CSF 的独立贡献。
需要说明的是，软件技术分层（MVC、前后端分离）与语义切分是正交的两个维度。技术分层解决的是代码组织问题，语义切分解决的是上下文加载问题。两者不冲突，也不需要同一个方法来处理。CSF 在实现中通过主题包分割和业务切片来保证语义完整性——这些是架构设计阶段的产出，不是运行时的计算。
目的有层次（宏观 + 具体），架构决定加载什么，三元组在入口激活目的——但还有一个问题：宏观目的和具体目的如何同时在场？
这依靠滑动窗口机制。
在 CSF 的工程实现里，每次会话的上下文窗口同时承载两层内容：项目级的宏观目的（通过 CONTEXT、总体计划等顶层文档），和当前任务的具体目的（通过任务三元组）。这就是目的层次结构在工程上的落地——窗口同时装着”路在哪”和”脚下这步怎么走”。
窗口内容不是运行时随机筛选的。它由计划分解在任务前确定——计划分解本身是架构的输出，在工作规划阶段就已经明确了每个任务应该加载什么。一个 CEO 日理万机，但他明天也只能一件一件地干。所以 CSF 的核心上下文管理是：上手先看任务窗口（宏观目的），再看会话计划（微观目的），收尾时更新任务窗口，为下个会话预定目的。
这里有一个反直觉的设计原则：不需要更大的窗口，需要把正确的东西放在窗口里。
注意力是上下文管理的一个独立维度——不是通过减少信息量来压缩上下文，而是通过控制信息被处理的焦点来提高处理质量。窗口里的信息不需要面面俱到，只需要此刻的目的所需要的那部分。其余的信息不是丢失了，是此刻不需要激活——它们存在于文档系统中，在下一个任务的三元组需要时再加载。
这也是 CSF 不依赖外部记忆系统的原因：目的的持续在场（每次会话都在窗口中重新激活）替代了跨会话的持久记忆。AI 不需要”记住”上次做了什么，它需要的是此刻的目的和相关语境——三元组和滑动窗口已经提供了这些。
三个机制各自独立，但组合后产生整体效果：
架构决定”加载什么”——业务概念架构提供了上下文的组织边界，保证每次加载的是一个语义完整的单元。
三元组在入口”激活目的”——每个工作单元开始时，目的、方法、资源同时在场，AI 的语义理解被目的收敛到正确方向。
滑动窗口保证”宏观微观共存”——窗口同时承载项目级方向和当前任务细节，确保 AI 在执行时不丢失全局方向感。
这三者的组合效果是：目的驱动的语义加载。整个上下文管理不依赖任何形式化检索机制——不需要向量数据库，不需要相似度计算，不需要编排框架。AI 在每个工作单元中，自然地获得目的清晰、语境完整、方向不偏的工作条件。
这不是”比 RAG 更简单的替代”。这是在接受了两条事实之后，工程设计自然走到的位置——当你接受 AI 有活性、接受语义稀释不可逆，你就不会去建形式化检索系统，而是设计一套让活性消费者在正确语境中自主工作的机制。
接下来的问题是：在这套机制中，人和 AI 各自扮演什么角色？系统如何随时间对抗熵增？这是下一篇的内容。