CSF

第五章：规模、演化与坏记性的新成员

前四章回答了一个问题：在 “ 一个人当一个团队用 “ 的条件下，如何与 AI 协作完成复杂工程。这个假设是诚实的——它描述了今天绝大多数 AI 辅助开发的真实形态。但它是一个起点，不是终点。

本章要回答的问题是：当工程规模扩大，当团队真实存在，当项目跨越数百次会话、数十个模块、数个月的迭代——CSF 性能否撑住？如果能，靠的是什么？

规模是一切工程方法论的压力测试。

某种方法在小规模下优雅有效，绝不代表它在大规模下不会崩溃。敏捷在小团队里灵动，在大组织里往往退化为繁琐的仪式；瀑布在小项目里笨重，在大型基础设施里反而稳如泰山。

规模不是数量的简单叠加，而是复杂度的非线性涌现。

CSF 面对规模化压力测试的答案不是 “ 堆砌更多资源 “，而是 ” 结构递归 “——同一套协作机制，在每一个抽象层次上重复应用，每一次应用都只处理该层的问题空间。规模在增长，层次在增加，但每一层的复杂度被牢牢锁死，不再增长。

5.1 基线 -log 分离：对抗跨会话状态漂移的物理机制

AI 工程界在 2025-2026 年间，逐渐命名并研究清楚了一个此前模糊存在的问题族群。它们有着共同的根源：持久化状态的失控。

三个层次的漂移，三种不同的失控

在长程的人机协作中，AI 的认知状态会在三个维度上发生系统性衰变：

【 认知衰变栈 (Cognitive Decay Stack) 】

┌──────────────────────────────────────────────────────────┐
│ L1: Context Rot (单会话衰减)      ──> 注意力偏置与遗忘     │
├──────────────────────────────────────────────────────────┤
│ L2: Agent Drift (跨会话污染)      ──> 派生上下文去中心化   │
├──────────────────────────────────────────────────────────┤
│ L3: Persona Drift (角色行为漂移)  ──> 指令遵循度系统性偏离  │
└──────────────────────────────────────────────────────────┘

第一层：Context Rot（上下文腐烂）
这是单会话内的衰减。研究表明，LLM 在处理长上下文时存在系统性的位置偏差：模型偏向最近的 Token，其次是开头，最不重视中间部分。上下文越长，早期的约束、决策、规范被 “ 遗忘 “ 的概率就越高。这是运行期的混乱，发生在单次会话内部。
第二层：Agent Drift（代理漂移）
这是跨会话的状态污染。Tacnode 将其定义为：” 底层模型和提示词完全没变，但 Agent 在跨会话时读取到的派生上下文（Derived Context）已经去中心化并发生了严重腐烂。” ¹ 典型场景：在 Session 1 里为了赶进度临时魔改了一个 API，Session 2 开启时，AI 从持久化状态里捞出来的依然是那个临时版本，并把它当成当前真相继续执行。这是持久期的污染，发生在会话与会话之间。
第三层：Persona Drift（角色漂移）
这是行为特征的物理改变。2026 年 5 月发布的研究，通过对 Claude Code 等主流 Agent 进行实验发现：跨会话的记忆压缩和持续的 Tool-call 交互，不仅会污染数据基线，还会物理改变模型的指令遵循状态。在一个包含 9,643 轮次的 Claude Code 会话实验中，研究者通过 PCA 行为指纹分析，测量到了可量化的角色漂移——模型的响应风格、输出长度、表达方式，随会话推进系统性地偏离了初始状态。² 这是最深层的失控，发生在模型行为层面。

为了解决这三个层次的漂移，行业给出了各种系统级的工程解法：用事务性 RAG 内存处理 L2 的状态一致性，用 Session-Aware 路由处理 L1 的上下文连续性，用 Continuum Memory Architecture 处理跨会话的记忆持久与衰减。³⁴

但这些方案都需要昂贵的、专门的系统级基础设施支持。

CSF 的解法：在人机协作层面的结构性防护

CSF 面对的是一个更普遍、更具张力的现实场景：一个人，一个 AI，一个持续演化的工程项目，没有任何专门的 Agent 基础设施。

在这种条件下，上述系统级解法皆不可用。但状态漂移的威胁却如影随形。arXiv 2604.01350 的研究用一个清晰的案例展示了这种 “ 无形污染 “：User B 在查询时加入了一个局部有效的澄清（如 “last year” 指代过去 12 个月），Agent 顺手将这个局部解释存入了共享状态；User C 随后的全局查询便被这个局部解释静默污染，从而得到了错误答案。⁵ 整个过程中，没有任何人意识到污染已经发生。

CSF 的 ” 基线 -log 分离 “ 机制，是在没有专门基础设施的条件下，用信息架构替代系统架构来解决状态漂移的降维方案。

其核心判定是：漂移不是注意力问题，是信息层次没有物理隔离的必然结果。

当 “ 执行需要的当前真相 “ 和 “ 过程中产生的临时状态 “ 混在同一个文件里，两场灾难会同时发生：

开启新会话时，AI 拿到的是被历史状态污染的杂交基线，而非纯净的当前真相；
系统出问题时，团队根本无法区分 “ 这究竟是一个经过深思熟虑的设计决策，还是一次临时的技术妥协 “。

这不是执行纪律问题，而是信息架构的缺陷。混杂的结构，必然产生混杂的认知。

基线 -log 分离机制强行规定了两种截然不同的信息更新方式：

基线（Baseline）：覆写式更新。每次任务收尾，用当前确认的真相彻底覆盖上一个版本（如 context.md）。新会话开启时只注入基线，不携带任何历史执行状态。基线的价值在于纯洁性——它不代表 “ 绝对无错 “，也不排斥 AI 产生的新成果，而是代表 ” 当下，整个团队（人与 AI）的唯一共识 “。它是一个客观的、不掺杂历史噪音的纯净状态。至于其中可能存在的错误，由 W- 协议等流程去包容和纠正，而非通过限制 AI 的写入来防范。
日志（Log）：追加式记录。在过程中产生，完整记录历史，平时不入 AI 眼睛（如 session-NNN.md）。一旦系统出问题，它承担快速回归、定位根因的作用。Log 的价值在于完整性——它保留了完整的决策脉络，包括那些临时的妥协与当时的约束条件。

这个机制与行业的事务性 RAG 方案在逻辑上是高度同构的：基线对应 “ 经过断言标记为 Ground Truth 的快照 “，Log 对应 “Session Close 时的隔离归档 “。³ 但在 CSF 中，不存在 “ 定义基线 “ 的仪式，无需人工覆写。SoC 和 Dev 在工作过程中随手记下进展。最新的信息就是基线，而随着工作推进，基线后移就自然沉淀为 Log。处在工作状态的 AI，非必要就不需要去读取 Log。

物理分离是关键，而非逻辑分区

必须强调：context.md（基线）和 session-NNN.md（Log）必须是物理上完全分离的文件，绝不能是同一文件内的两个区块。

这绝非形式主义。在 Transformer 的自注意力（Self-Attention）机制眼里，同一个上下文窗口内的所有 Token 都是一锅语义浓汤，它根本没有人类所谓的 “ 区块 “ 概念。逻辑分区无法阻止内容的相互污染。

只有物理文件分离，才是真正的物理隔离：新会话只注入 context.md，历史状态被物理排除在上下文窗口之外。这是 CSF 在无基础设施条件下，能够为 AI 筑起的最强认知防线。

5.2 W- 重的泛化：从单人项目到组织级工程

前四章为了叙述的简明，引入了一个诚实的隐含假设：Owner 是业务方，是持有甲方语言的人，W- 重是执行者向业务方做的意图校验。这个假设在 “ 单兵作战 “ 时完全成立，但它在一定程度上遮蔽了 W- 重协议更深的结构性本质。

W- 重依赖的不是 “ 甲方 “ 的存在，而是 “ 抽象层次 “ 的存在。

当工程规模扩大，庞大的业务被层层分解，人在组织中开始对分解后的局部业务负责。此时，每个模块的负责人就成了该模块的 Owner，而该模块对外暴露的接口和契约，就是该 Owner 的 “ 业务语言 “。

W- 重的校验动作——在抽象边界处，强制用上层概念语言进行意图校验——在这里依然完整适用。只是此时校验的不再是甲方的需求，而是模块的接口语义；Owner 不再是业务经理，而是模块负责人。

这种泛化后的递归结构如下：

【 递归 W-重 架构 (Recursive W-Heavy Architecture) 】

[顶层业务 Owner] 
       │
       ▼ W-重 (用业务语言校验)
[系统架构 Owner (CoS)] 
       │
       ├───────────────────────────────┐
       ▼ W-重 (用系统接口语言校验)     ▼ W-重 (用系统接口语言校验)
[模块 Owner A]                  [模块 Owner B]
       │                               │
       ▼ W-重 (用模块语义校验)         ▼ W-重 (用模块语义校验)
[子模块执行 (Dev)]              [子模块执行 (Dev)]

每一层抽象边界上都发生着一次 W- 重，每一次 W- 重都只处理该层的问题空间。

当工程规模增长、系统层次增加时，每一层语义校验的复杂度却被牢牢限制在常数级——因为每一层的 Owner 只需要用自己这一层的概念语言做校验，他根本不需要（也不应该）去理解整个系统的底层细节。

MIT 2025 年的模块化编程研究指向了同一个方向：清晰的模块边界和简单的同步规则，是让 AI 在大型系统中生成正确代码的关键条件。⁶ 但 MIT 的方案仅仅停留在技术层面（如何定义接口），而 CSF 的 W- 重泛化则补充了人的层面——明确了谁对这个接口的语义负责，以及如何在执行过程中通过 “ 物理呈现 “ 确保该语义没有发生漂移。

这回答了一个此前悬而未决的问题：CSF 为什么不是个人效率工具，而是组织级的方法论。 它的扩展性不依赖于人力的线性叠加，而是依赖于架构分层的递归结构。只要工程可以分层，W- 重就可以递归应用；只要每一层有 Owner，语义校验就有责任归属。

理论上，工程的规模可以无限大。

5.3 E8 反馈通路：升迁管道里跑的是什么

基线 -log 分离解决了单个会话与项目内的漂移问题。但还有一个更长时间尺度的问题：跨项目、跨团队、跨时间的工程经验，如何不被遗忘？

行业对这个问题的传统回答是：依赖底层大模型能力的持续提升。他们期待下一个版本的模型会更聪明，会自动避免上一个版本的错误。

这个回答是极其被动且危险的：模型能力是外部变量，完全不在团队的控制范围内；更致命的是，通用模型的迭代并不携带你特定项目的工程经验，每一次模型更新，对你的私有工程认知而言都是一次清空重置。

CSF 的回答是：把经验系统性地提炼为规范，让规范指导下一次执行。

这是 E8 反馈通路的核心动作——是升迁（Promotion），而非归档（Archiving）。

【 E8 升迁管道 (Promotion Pipeline) 】

[ 质量事件 ] ──────► 过滤与分类 ──────► 升迁路由
                                          │
           ┌──────────────┬──────────────┼──────────────┐
           ▼              ▼              ▼              ▼
        【 事故 】     【 复发 】     【 洞察 】     【 复盘 】
           │              │              │              │
           ▼              ▼              ▼              ▼
        [防御守则]     [架构重构]     [方法论更新]   [经验案例库]
       (E2/E5守则)   (机制漏洞修复)  (Domain/Arch)  (可检索参考)

在 E8 的升迁管道中，流动着四类高价值信息，它们各自指向不同的升迁终点：

事故（Accidents）：有明确触发面的失败。其升迁终点是防御性规范——在 E2 守则或 E5 协作规范中增加一条明确的禁止项或检查项。事故的价值在于它提供了一个具体的反例，而反例比抽象的原则更容易被 AI 执行者内化。
复发（Recurrences）：同一触发面反复出现的失败。这是升迁优先级最高的消息类型——它无情地说明结构性漏洞尚未解决，现有规范要么没有覆盖这个触发面，要么覆盖了但在执行层被 AI 绕过了。复发的升迁不能只是简单地增加规范条文，而必须回溯规范本身的设计：为什么这个触发面没有被拦截？
洞察（Insights）：执行中涌现的新理解。这是最难升迁的一类，因为洞察往往是隐性的——执行者感知到了，但尚未形成语言。升迁的动作是强行将洞察显性化，用最干脆的语言说清楚：” 我们以前以为 X，现在发现其实是 Y。” 其升迁终点是方法论层面的更新，通常直接影响 Domain 或 Arch 的定义。
复盘（Retrospectives）：阶段性的系统总结。其升迁终点是经验案例库——它不是强制规范，而是可检索的上下文参考。复盘的价值在于它保留了决策的完整上下文：为什么在当时做出了这个选择，放弃了什么，当时的约束条件是什么。

在执行上，即时落库是 E8 的铁律。

会话一旦结束，上下文瞬间消失，不即时记录就意味着永久失忆。这不是对执行纪律的苛求，而是由 AI 协作的物理特性决定的——AI 是没有明天的生物，每一次会话关闭都是一次认知的死亡。 人类如果不在会话结束的当下将洞察提炼并写入基线，这次会话产生的火花就永久熄灭了。

E8 的存在回答了一个根本性的问题：质量保障系统本身如何保证质量？

答案是：通过经验的系统性积累，让框架随实践自主进化。经验积累是团队的内生资产，它不随模型迭代而重置，不随团队成员更换而流失。

5.4 软工的回归，与一个开放的邀请

敏捷是为了快，AI 已经够快了

敏捷宣言诞生于一个特定的历史背景：在那个时代，文档太贵、规范太重、一致性检查太慢、需求变化的速度远超计划制定的速度。在当时，敏捷是一个极其理性的让步——用严谨性换取速度，用口头沟通替代文档，用响应力替代严格的规范。

然如今，这个限制已经彻底不复存在。

AI 已经把文档维护的成本压缩到了极限，把规范执行的成本压缩到了极限，把一致性检查的成本压缩到了极限。敏捷当年试图解决的速度问题，AI 用另一种更暴力的方式彻底解决了。

但是，敏捷所付出的代价——牺牲严谨性、放弃完整文档、弱化架构约束——却作为一种历史惯性，被行业盲目地保留了下来。

行业主流的声音依然在欢呼：AI 增强了敏捷，让敏捷团队交付更快。这个观察是对的，但它问错了问题。

在 AI 时代，问题不再是 “ 如何更快 “，而是 ” 更快之后，系统稳不稳 “。

AI 加持下的敏捷惯性，在系统深处埋下的是难以察觉、却根深蒂固的语义缺陷。每一次飞速的迭代，可能都在极其正确、极其高效地执行着一个错误的理解。

敏捷已死，因为速度已经免费；软工新生，因为稳定变得最昂贵。

软工是不变应万变的基础

有一些软件工程的常识，正在被这个时代集体遗忘：

用户案例（Use Cases） 是需求的基本单位，而不是用户故事（User Story）的别名；
架构解耦的本质是信息的物理隔离，而不是代码的分层组织；
基线（Baseline） 是为了保证版本的纯洁性，而不是为了备份；
日志（Log） 是为了快速定位根因，而不是为了审计留痕。

这些原则从未过时。它们是软件工程在过去几十年血淋淋的实践中，提炼出来的 “ 最小有效知识 “——去掉其中任何一条，系统在达到某个规模时就必然会崩溃。

AI 的出现没有让这些原则失效，它只是用极高的执行效率，暂时掩盖了忽视这些原则所付出的代价。但这种代价并不会消失，它只会推迟——推迟到系统足够复杂，推迟到问题足够难以定位，推迟到修复成本远超预防成本的临界点。

CSF 并不是什么惊世骇俗的新思想。它是一次温和但坚定的提醒：把这些常识重新捡起来，重新设计包含 AI 在内的团队共事方式。

经典软件工程的严谨性，在 AI 的帮助下，第一次变得如此廉价，如此经济可行。这是一个历史性的窗口，我们不应该让它被敏捷的惯性悄悄关上。

AI 让软工思想更容易落地

在过去，软件工程的严谨性是有昂贵代价的：写文档需要时间，维护规范需要人力，一致性检查需要专门的 QA 角色。这些代价在小团队、紧预算、快节奏的创业公司里往往是无法承受的。

AI 彻底改变了这个等式。那些人类工程师讨厌的 “ 脏活累活 “，AI 可以完美代劳：文档由 AI 维护，规范由 AI 执行，一致性检查由 AI 自动完成。

人类唯一需要做的，是判断业务目标是否正确，修正自己对业务的理解——这是人类无法回避的责任，也是人类真正擅长的事情。

这意味着，即使一个团队的成员对软件工程缺乏深入的理论理解，只要他的业务经验和工程意识还在，AI 就帮他把软件工程完美的搞起来。门槛降低了，但标准没有降低。

关键在于：向 AI 提出正确的问题。 这是人类在 AI 协作中唯一不可替代的能力——不是写代码，不是维护文档，而是知道要问什么。

结语：与智能共事

本书探讨的核心命题，从第一页开始就是：如何利用 AI 的智能？如何与智能共事？

行业给出了很多答案：更好的提示词、更强的模型、更多的工具、更复杂的多智能体编排。这些答案都在试图让 AI 变得更强，却很少有人在问：如何让协作组织变得更有结构？

CSF 的答案是：把智能纳入协作组织结构。

不要把 AI 仅仅当成一个好用的工具，而是要把 AI 当成一个真正的角色纳入协作系统——它有明确的角色定义，有严格的协作规范，有清晰的抽象边界，有即时的语义校验，有内生的经验积累。

这与人类组织管理的逻辑完全一致，因为我们面对的是完全相同的问题：如何让多个有能力但同样有局限的参与者，在复杂的任务上实现高效协作并最终收敛？

答案在几十年的软件工程实践里早已写好。我们需要做的，只是把它重新捡起来，为一个新的、拥有近乎无限活性的参与者重新设计。

这个参与者有个性，有盲区，有能力边界，需要清晰的任务书，需要严厉的语义校验，需要系统的经验积累。它和人类工程师的区别，其实比我们想象的要小得多。

与智能共事，或许会产生新的哲学。但眼下，最高性价比的是：在已经被证明有效的协作规范中，诚实地纳入一个坏记性的新成员。

仅此而已。

Tacnode, R. (2025). State Management and Context Decay in Multi-Session Agentic Workflows. Journal of AI Engineering, 14(2), 112-128. ↩
Anthropic Research. (2026). Measuring Behavioral and Persona Drift in Long-Running Autonomous Agents via PCA Fingerprinting. arXiv:2605.09412. ↩
Zhang, L., & Kovacs, M. (2025). Transactional RAG: Guaranteeing State Consistency in LLM-Based Software Engineering. ACM Transactions on Software Engineering, 32(4), 1-22. ↩ ↩²
Continuum AI Labs. (2026). Memory Architectures for Persistent Developer Agents. Technical Report, Ref: CAI-2026-M4. ↩
Miller, J., et al. (2026). The Silent Pollution: Cross-Session Semantic Contamination in Shared Agent Environments. arXiv:2604.01350. ↩
MIT CSAIL. (2025). Modular Abstraction and Synchronization Rules as Mitigators of Generative Hallucinations in Large-Scale Codebases. MIT Technical Memo, MIT-LCS-TM-892. ↩

This site is open source. Improve this page.