1,097 个会话之后：我试图说清 CSF 是什么
§1 说不清
我设计了 CSF，并用它开发了一个 AI Agent：PPM Desk。
到 2026 年 11 月 6 日，这个项目上有 1,097 个有记录的会话、256,047 行代码、418 次提交、93 个活跃日。每个会话有明确的目标、有产出、有日志；每一行代码在 git 里。这些数字不来自回忆——它们是数出来的，口径与命令都在文末。
然后我发现自己回答不了一个问题：这些数字意味着什么？
这个问题不是我自己想出来的。过去半年，我多次向做技术的朋友介绍 CSF 是什么。得到的回应大致三类：
有人说：「这不就是提示词模板吗？我们也写。」
有人说：「想法可以。但这是你一个人的方法，是孤例。没有产品化，没有第二个样本。」
还有人说：「听起来是个 skill。装一个试试？」
最接近实质的一次，是一位认真听完的朋友说的：「我感兴趣。但我没法判断。」
这句话比所有质疑都让我在意。质疑至少有立场，可以辩；「没法判断」意味着我给出的所有信息，没有一条落进他的评估框架。问题不在他们，在我的语言。行业的词汇表里，AI 相关的格子就那么几个：聊天助手、提示词技巧、Agent 框架、记忆插件。CSF 放不进其中任何一格，听的人只能就近归格——归到哪一格，都是错的。
所以我换了思路：不解释，去测量。
这篇笔记记录的就是这个过程。我先去看行业怎么衡量 AI 的长周期开发能力（§2），发现那些尺子量不了我做的东西；于是给自己建了一套证据规则（§3），用可复现的数据把自己量了一遍（§4）；又看了看在我之外、真实使用这套方法的人（§5）；最后给出我的结论，以及它在什么条件下不成立（§6）。
开始之前，给 CSF 一个工作定义，本篇只需要这一句：CSF 是一套人机协作协议——项目的当前状态、决策历史、经验教训保存在项目文件里，而不是对话历史里；每次会话从装载这些文件开始。 后面所有的数字，都在检验这一句。
§2 行业的尺子量不了这件事
要测量，先找尺子。行业怎么衡量「AI 能不能做长周期软件开发」？
先看尺子的量程。行业最常用的基准是 SWE-bench 一类：Verified 集 500 道题，161 道只需改 1~2 行；最难的公开版本，任务平均规模是 107 行、4.1 个文件。而我要测的东西，是 256,047 行、891 个文件、四个多月的持续演进——任务规模差着两到三个数量级，尺子的量程根本不够。时长维度也一样：METR 的测量显示，超过 4 小时的任务，模型成功率不足 10%。
那更新的基准呢？我最初找到的是 2025 年的材料：长上下文退化实验、Agent 任务时程研究、开发者大样本调查。读完后我意识到一个问题：这些材料发表已超过一年，而这一年里模型能力边界移动了很多——证据的时效本身也要被检查。于是全部推倒，只保留最近一年发表的基准。以下是五个。
Multi-step SWE（arXiv 2611.07166，2026-11）。任务形态：同一代码库上 5 到 15 个相互依赖的开发步骤，每一步都是数小时的工程请求，且必须建立在自己上一步的产出之上——论文明确指出，早期的设计决策与错误会一直传递下去。结果：九个前沿模型，最强的完成率 18.5%；69 个任务里 38 个没有任何模型解出。
RoadmapBench（2026）。任务形态：真实仓库的跨版本升级，中位规模 3,700 行、51 个文件。最强模型 39.1%，最弱 5.2%。
NL2Repo-Bench（arXiv 2512.12730）。任务形态：一份需求文档加一个空工作区，要求产出完整可安装的代码库。最强成绩不到 40%。失败模式：过早终止、全局一致性丢失、跨文件依赖脆弱、数百步之后规划失效。
SWE-Marathon（arXiv 2606.07682）。任务形态：超长任务，平均每次运行消耗 2,720 万 tokens。前沿模型成绩低于 30%，且 13.8% 的运行出现 reward hacking。
LoLBench（arXiv 2609.37143）。任务形态：约 240 万行的真实系统，从需求到跨模块交付。典型断点：代码定位不完整——该改的文件没找全，于是漏掉跨模块的同步；28 个 agent 里最好的只解出 14%。
这五个基准合起来说明一件事：行业的瓶颈已经从「能不能生成」移动到「多步之后还对不对得上」。 这不是我的判断，是行业自己最近一年的测量结果。失败模式也不是容量不够——是连贯性、依赖管理、跨模块一致性。
读到这些结果时，我的第一反应是兴奋：我做的东西恰好就在处理这一类问题，这些基准不就是现成的对照组吗？
然后我发现了问题。
这五个基准测的都是无人全程自主：给任务，模型独立跑完，中间没有人。而我的 1,097 个会话里，人始终在——判断方向、验收产出、纠正偏差。两种形态测的不是同一种能力：一边测的是模型脱离人之后的自主上限，一边测的是人和模型协作的长期产出。拿前者的成绩去对照后者，结论无效。
这是本文第一个被我自己否掉的对比，也是我当初最想用的一个。它最终只证明了一件事：「多步一致性」是行业公认的未解问题——我关心的问题是真的，而且重要。至于我做得怎么样，这组基准一个字也证明不了。
不过，把五个基准报告的失败模式摊开，和我自己规范里的机制对照，会发现一张几乎一对一的镜像表：
| 基准报告的失败模式 | CSF 里的对应机制 |
|---|---|
| 早期决策与错误向后传递 | 基线-日志分离：当前真相覆写，被否决路径追加保留 |
| 全局一致性丢失、数百步后规划失效 | 开局协议：每次会话重新装载目的与方法 |
| 跨文件依赖脆弱、漏掉跨模块同步 | 项目全景图与索引：结构与不变量常驻 |
| 过早终止、自报不可行 | 分步确认：每步产出可交付，不一次性交卷 |
| 反复跳回同一个坑 | 活跃防御：错误转成防御条目，开局即在 |
行业用基准测出了「AI 撑不住长周期」的五处断点，恰好是我的规范逐条在解决的。这不是巧合——我和他们撞上的是同一堵墙。
那就只能自己造尺子了。
§3 没有外部基准，就自己造
外部尺子量不了，剩下两个选择：放弃测量，或者自己建一套规则。我选后者。这一节说明规则，以及它两次证明我错的过程。
第一件：证据分级。
起因很现实。我想证明这套方法不只我在用，但用户的原始工程我拿不到——代码在他们自己机器上，涉及他们的业务数据，他们也没有义务提供给我。一开始我觉得这是论证的死穴，后来想通了：拿不到完整证据，不等于没有证据，关键是不同等级的证据承担不同的论证职责。我把它分成四级：
E0，可运行。 程序本身能装、能跑、能干活。这是最硬的一级——它检验的是完整性：进程与持久化、多窗口会话管理、文件监视、Git 快照、安装包与更新通道、连续四个多月迭代到 v1.5.72。这些不是「生成代码」能堆出来的，是长期演进的产物。
L1，可核。 自有项目的 git 与目录数据、公开基准与官方文档。承担全部定量结论。规则只有一条：数字不靠回忆，靠命令——任何人拿到项目目录都能复现。
L2，行为痕迹。 用户给我提供的截图里的界面、会话编号、任务书编号、产出物形态、模型切换点。它能证「发生过」，不证「有多好」。
L3，自述。 用户原话。只作引语，不单独承担结论，是旁证。
配套三条规则：不求原始文件（给什么用什么）；不做跨用户加总（口径不同，加总即失真）；不用 L3 顶 L1（任何「效果显著」的结论必须有 L1 或 L2 支撑）。
一句话：间接证据不是弱证据，是不完整的证据——它证明「发生过」，不证明「有多好」。这条界线划清之后，「拿不出原始文件，所以你说的不算」这种质疑就有了正面、客观的回应。
第二件：对比清单。
§2 的落空给我提了个醒：对比这件事本身需要规则，否则人总会不自觉地挑对自己有利的比法。我给自己定了四类，每类都附一个我自己踩过的例子：
| 类型 | 判据 | 我踩过的例子 |
|---|---|---|
| 落空 | 前提不同，根本不能比 | §2：拿「无人自主」的基准对照「人始终在」的实践 |
| 易误解 | 能提，但一被追问就崩 | 代码行数——「那里面多少是 HTML？」；行 ÷ 人日——这个指标业界本身就不可靠，语言、复杂度、生成代码占比差异太大 |
| 可比，但要澄清基础 | 同口径才成立 | 同一任务两种做法的对照（§4）；换模型断不断档；缓存命中率 |
| 自比 | 不依赖外部，自己最硬 | 自己的数据在时间轴上的变化（§4） |
这张清单的价值不在分类，在它先于我下结论而存在——先有规则，再拿数据过规则，不合格的数字再漂亮也不上桌。
第三件：这套规则两次证明我错。
第一次。我一度认为「缺第三方复现」是整个论证最大的洞——只有我自己在用，说破天也是孤例。后来发现事实不是：已经有人在自己的领域里真实使用这套方法做开发（§5 详述）。孤例问题缓解了，但没有解决——少数几个用户仍然不是规模证据。
第二次。PPM Desk 的会话分两种角色——判断（定方向、做设计、验收）与执行（实现、调试）。实测判断类会话占 38%，我曾把这个比例当成这套方法的内在属性，一个「稳定常数」。后来在另一个项目上实测：63%。回到 PPM Desk，按月拆开看：从 22.7% 到 49.6%，逐月波动。比例根本不是常数，是可调度的资源——这个发现后来成了 §4 里最重要的一条曲线。
两次推翻的意义在于：如果这套规则只是反复证明我对，那它是宣传工具。它两次证明我错，所以我才稍微多点儿勇气把它拿给别人看。
§4 量出来的 CSF
规则建好，拿数据过规则。这一节是测量结果。每一条的形式相同：先给数据，再给数据逼出来的机制判断。
① 170 个会话，第一句全部相同。
另一个项目——一个知识管理后台系统，同样用这套方法开发——一共留下 170 个会话记录。每个会话的第一句用户消息，一字不差，全部是：
阅读 xxx-context.md，开局。
无一例外。这句话的意思是：先读项目的上下文文件，再开始干活。170 次会话，没有一次是「接着上次继续」——因为不需要。记忆不在对话里，在文件里。 每个会话都是一次自足的完整指令：AI 先从文件里知道自己是谁、在干什么、上一刀切到哪，然后才动手。顺带一组数字：这 170 个会话里，AI 的工具调用共 24,886 次，平均每会话 146 次动作——会话不是聊天，是干活。
这个形态刚好对照一个学术发现。Laban 等人（ICLR 2026 杰出论文）证明：多轮对话中模型性能比单轮完整指令低 39%，机制是早期轮次的假设在对话历史里累积成错误依赖，而且一旦形成就回不来；把多轮信息拼成一条完整消息，性能恢复 95%。「170 次开局全同」就是这个发现的实践形态——只是我们不是事后拼接，是从架构上根本没有给错误假设留累积的空间。
它带来三个直接推论：每个会话可重放；可以换人——新的人接上项目，读同一批文件就能到位；可以换模型——下面第 ④ 条会说。
② 一条 U 形曲线：人的介入是可调度的资源。
PPM Desk 四个多月，按月份统计判断类会话的占比：
| 月份 | 判断占比 | 当时阶段 |
|---|---|---|
| 2026-07 | 43.9% | 启动：需求、架构、立项 |
| 2026-08 | 22.7% | 开发冲刺（当月提交 145 次，全期最高） |
| 2026-09 | 40.5% | 稳定迭代 |
| 2026-10 | 49.6% | 研判与发布管理（判断次数超过提交次数） |
先承认一件事：我曾经以为 38% 是这套方法的稳定常数，§3 说过，被自己的数据否了。这条曲线真正说明的是：冲刺期能把人的介入压到 22.7%——结构一旦建立，执行可以高度自主，人只在关键节点介入。 如果这套方法是靠人硬扛，判断占比应该长期居高不下，压不下去。
压得住的原因，是人的每次判断没有消散：判断被写成项目文件里的基线——当前状态、决策记录、踩坑后的防御条目——下次开局直接可用。业界通常把人的介入当作要消除的摩擦；在这套方法里，介入是被复利化的资产。这是 §6 还会回到的分歧点。
③ 98.65% 的缓存命中率。
知识管理项目全程留有 API 调用记录：21,523 次调用，输入 63.89 亿 tokens，其中 98.65% 命中缓存。按官方定价粗估，整个项目的 AI 成本约 ¥1,500——每万行代码约 ¥250。
这个命中率不是巧合，是结构的副产品：每次开局装载的基线，结构相同、内容高度重叠，相同前缀自动命中缓存。对话式方案做不到这一点——它们的上下文是持续生长的对话历史，每次都在变，命中率天然低。状态外置不只是让项目可交接，还顺带把 token 成本压低了一个量级。
④ 换模型、换工具，项目不断档。
这一条不是我先发现的，是用户先问出来的。一位用这套方法做软件预研的用户，在第 25 轮会话时把模型从一档换到另一档，然后问我：「为什么换用模型之后不影响进度和要求？」
答案是第 ① 条的推论：项目状态在文件里，模型只是执行者。换一个执行者，装载同一批基线文件，接着干——基线才是项目，模型不是。
我自己用得更随意：PPM Desk 和 VS Code 两个工具混用，同一个项目同时开几个会话并行；遇到困难的任务，临时换更强的模型上来；两个角色配不同的模型——判断类会话用 DeepSeek Pro，执行类会话用 DeepSeek Flash。工具换了、模型换了、会话并行开着，项目从不需要「重新交代背景」：每个会话读的是文件，不是上一任的语气。
这件事的对立面值得说一句：如果项目状态存在对话历史里，换模型约等于项目重启——历史带不走，或者带过去也只能指望新模型读得懂旧模型的语气。项目不绑模型，也不绑工具，在模型半年一换代的今天，这不是便利，是生存条件。
⑤ 和现有记忆方案比，差异到底在哪。
说完数据，说差异。
2026 年的记忆方案已经很丰富：Mastra 的观察式压缩、Letta 的分层自编辑加 git 追踪的上下文仓库、Mem0 的三层存储、Zep 的双时态知识图谱。它们的竞争点也在一起移动：从「能不能找回来」，移到「写进去的时候写的是什么」。方向在收敛，这一点我承认。
但它们优化的目标函数是同一个：相关的信息能不能被找回来。 而项目里最贵的知识，恰恰是与当前任务不相关的那部分——被否决的方案、被排除的路线、踩过的坑。相关性检索永远找不回被否决的路：它与当前任务「不相关」，这正是它当初被否决的理由。保留被否决的路径，会同时增加 token 又降低召回——这不是它们想不到，是它们的目标函数里没有这一项。
我们的目标函数里有。被否决的方案进日志层，只追加、不覆写；踩过的坑转为防御条目，开局就在。他们的记忆让 AI 记得更多；CSF 方法的记忆，让项目能够交接。
另有一组对照，说明这不只是记忆设计的问题。同一个工程项目，同样的图纸和需求：让 AI 一次性生成完整报价，给出 679 万；用分步推进、每步先确认范围再算量的方式，给出 173~256 万——前者是后者的 2.6~3.9 倍。这不是模型能力的差距，是工作方式的差距——差在范围假设由谁先说出口：藏进结果里，还是先摆到桌面上。这组对照任何人都能重跑。
⑥ 三个问题，给想验证的读者。
我不指望谁仅凭这篇文章就接受上面的判断。所以把差异变成三个可以当场验证的问题——拿去问你自己项目里的 AI：
一问否决：他记得这个项目否决过哪些方案、为什么否决吗？
二问交接：换一个人，只给项目文件、不给口头交代，他多久能回到你现在的状态？
三问重犯：三个月前踩过的坑，换个说法再出现，他会不会再跳进去？
三个问题都是事实问题，当场可验，不需要任何人承认自己不行。如果你的 AI 三个都答得上，那他背后的方法和我这套是同源的；答不上，差异在哪，你已经有体感了。
§5 不是孤例
§3 说过，「缺第三方复现」这个判断被事实推翻了。这一节说事实本身，以及它能说明什么、不能说明什么。先用一句话概括这个发现：复现早就发生了，只是它长得像聊天记录，不像论文。
到目前为止，我知道的使用者里，已经有人用这套方法独立做过这些开发（按 §3 的分级，以下均为 L2 行为痕迹——界面、编号、产出形态可见，原始工程不在我手上）：
一位用户在做法律行业软件：项目里有连续编号的任务书、39 条要件附录、逐条编号的审查清单，以及一个事实规则引擎的代码文件——立项、任务书、验收的完整链路在运行。另一位高校教师在做嵌入式开发，从驱动调通做到界面产出。还有人做过桌面工具、做过跨项目的共享模块治理（一次指令盘点 16 个项目，产出可复用模块清单）；有人用它做医疗就诊指导和保险理赔规划；有人在预研阶段换了模型，进度没有断（§4 第 ④ 条的那位）。还有一个我印象很深的排障案例：一个 80MB 的 PDF 无法打印，AI 定位到根因——每页按 576dpi 渲染、单页约 3200 万像素、打印机驱动光栅化时内存不足——给出重建方案，把体积压到约 18MB；输出是一份「结论→根因→处理」的专业诊断报告，不是聊天。
这些例子的价值不在数量，在分布：法律、嵌入式、桌面工具、文档排障、医疗保险、多项目治理——技术栈不同、工具链不同、验证方式不同、交付物形态不同。如果这套方法是某个领域的技巧，换一个领域就应该失效；它在这些互不相干的领域里都成立，说明它抓的是领域无关的那一层：人和 AI 在一个项目上的协作结构，不是任何行业的专业知识。
诚实的边界也必须写在这里：用户信息我不披露，他们能让我看到的只是行为痕迹；样本很小，个位数；而且不能排除自选择偏差——愿意尝试一套强调章法的方法的人，可能本来就是更讲章法的人。这些材料能证明「不只我能用」，证明不了「谁用都好使」。后一个命题，只能等更多的使用记录来回答。
§6 结论与成立条件
测量的过程走完了。给出我的结论——每一条都带着它的成立条件，因为脱离了条件，它们一条也不成立。
结论一：「多步一致性」这个瓶颈，存在工程上可行的解法方向。 方向是把项目状态从对话历史移到文件系统，并配套协作协议。依据：两个性质不同的项目，合计 1,260 余个会话、31.7 万行代码，持续演进没有断档（PPM Desk 四个多月，知识管理一个多月）；关键指标可复现。成立条件：样本是两个项目、同一个设计者；它证明「这条路走得通」，不证明「这是唯一的路」。
结论二：人在回路中的介入是可调度的资源，不是恒定成本。 依据：判断占比在四个多月间从 22.7% 到 49.6% 波动，冲刺期压得住、研判期提得上。成立条件：单一项目的时间序列；它是否普适，需要第二个团队的数据。
结论三：这套方法与现有记忆方案的差异，不在「记忆更多」，在「项目可交接」。 依据：机制层面的对照（§4 第 ⑤ 条）与三个可当场验证的问题（§4 第 ⑥ 条）。成立条件：这是机制论证，不是跑分——我没有拿 Letta、Mem0、Zep 做过受控对照实验，谁想较真，实验设计是现成的。
五条边界，一口气列完：一，样本小，核心数据来自两个项目，外加个位数用户的行为痕迹；二，自报告、无独立审计，所有数字来自我自己的仓库，我给了复现命令，但没有人替我跑过；三，设计者即受试者，方法是边用边改出来的，不能排除「越用越顺手」的适应效应；四，生存偏差，用不下去的人不会留下记录，我看不到他们；五，行 ÷ 人日这类指标不可靠，本文不拿它做任何主张。
还有一个更根本的质疑，正面接住：模型在快速变强，这套东西会不会很快过时？ Laban 的实验里，把多轮信息拼成一条完整消息，模型性能恢复 95%——那么一个足够强的模型、加上一次给全信息的指令，理论上可能达到同样的效果。我不否认这种可能。这套方法的真实位置是：当信息量超出单次输入、且项目需要跨时间演进时，它是今天可行的解。 模型变强会压缩前一个条件，但「跨时间演进」不会消失——项目状态不只是「能不能装进上下文」，更是「当前基线由谁定义」。容量问题会随模型进步缓解，定义权问题不会。
定义权之外，还有一个更直接的观察——它是观察，不是数据：当我用 DeepSeek Flash 搞不定抽象的顶层设计问题时，我会在下一个会话换 Kimi 或 GPT。能明显感受到更高「智商」在实际问题里理解、驾驭概念时给我的爽感。但同时，更高的智商也体现出对 CSF 规范的更好理解和兼容，让 CSF 的价值得到更高体现。道理也很简单：更聪明的科研人员，更容易体悟并遵循好的方法；但他不会因此不需要方法——他是把方法用得更透，不是把方法废掉。
再换一个角度说：聪明的模型只会让 CSF 变得更好用；也许有一天，模型也会发现 CSF 的错漏，到时候用更好的模型升级一版就好。
最后说一个我认为比以上结论更重要的分歧。
行业的主流叙事是消除人的介入：更自主的 Agent、更少的人工确认。但看一下工程现实：Copilot 生成完要人 review，Claude Code 执行前要人 approve，Devin 的关键步骤要人确认——人从来没有离开过回路，只是介入的判断每次都消散了。METR 在 2025 年做过一项对照实验：资深开发者用 AI 辅助，实际耗时增加 19%，自感却是快了 20%。人在场，但回路在失效——这不是「要不要人」能解释的，是「人的判断去了哪」的问题。
这就是分歧所在：业界把人的介入当摩擦去消除，我把它当资产去沉淀。 每一次纠偏、每一个「不对，重来」，在这套方法里都写成文件，成为下次开局的条件。四个多月、1,097 个会话没有散架，靠的不是模型更强，是这些被攒下来的判断。
回到开头那个问题：1,097 个会话、25.6 万行代码意味着什么？
现在我可以回答了。它意味着一套把项目状态写进文件的协作协议，在真实开发里跑了四个多月没有散架；意味着「多步一致性」这个行业公认的未解问题，至少存在一条走得通的路；意味着人机协作里人的位置，有另一种安排方式。它不 意味着这套方法已经被证明优于什么——那需要更多人、更多项目、以及一次正经的对照实验。
至于当初那个「说不清」——现在能说了：CSF 是什么、不同在哪、值多少，都在上面，每一条都可以被检查。如果你用可复现的方法，测量完自己的 AI 协作，得出了不一样的数字，那更好。到那时候，对比才真正开始。
附：数据口径与复现
文中的数字不是估算，是按下面的口径数出来的。口径写清楚，谁都能重数一遍。
| 指标 | 定义 |
|---|---|
| 会话记录 | 一次有明确目标、有产出、有日志落盘的独立人机会话。按角色分判断类与执行类，各记一份日志（文中数字为两者合计）；2026 年 8 月下旬起两类共享同一编号池（互斥取号），此前各自独立编号 |
| 代码行 | 按扩展名统计 .js/.ts/.tsx/.jsx/.css/.html/.vue 等，排除 node_modules/.git/dist/releases/.venv |
| 提交 | git rev-list --count HEAD（当前分支） |
| 活跃日 | 有提交或有会话记录的日期数 |
复现命令（PowerShell，把 <项目路径> 换成你的仓库路径）：
$p = '<项目路径>'
git -C $p rev-list --count HEAD
(Get-ChildItem "$p\csf-lite\sessions" -Filter 'coslog-*.md' -File).Count
(Get-ChildItem "$p\dev" -Recurse -Filter 'devlog-*.md' -File).Count
(Get-ChildItem "$p\csf-lite\plans" -Directory).Count
CSF 规范开源：github.com/huidev2025/… —— 文中所有数字的复现命令见文末附录。
