AI 数据通道：JSON·Markdown

一、元认知：无状态的天才 #

2026 年，AI 编程能力已经到了一个奇怪的拐点：模型足够聪明，但每次对话都像失忆。

你花两小时给 Claude 讲清了项目的架构约定、命名规范、部署流程。它完美理解，交付了代码。然后你关掉终端，下次再打开——一切归零。它不记得你的项目，不记得你的偏好，不记得上次踩过的坑。你重新讲一遍。

这不是工具不好用的问题。这是所有当前开发范式的共同天花板：AI 的能力边界不在模型，在上下文连续性。

所有范式都在回答同一个问题 #

把从 Waterfall 到 Autonomous SE 的十种开发范式摆在一起，表面上是输入、驱动、自主性、适用场景的差异。但如果退后一步看本质，它们全在回答同一个问题：

如何向 AI 提供正确的上下文？

差异只在于”用什么提供”和”提供多少”。但更深一层，真正的演化轴不是”AI 自主性越来越高”——那是表象。真正的轴是：

什么被视为可持久化、可积累的资产？

  • Waterfall 把需求文档当资产
  • DevOps 把流水线配置当资产
  • Prompt-Driven 把 prompt 当资产
  • Spec-Driven 把规范当资产
  • Autonomous SE 把治理策略当资产

这些资产有一个共同特征：它们是静态的。需求文档写完不变，流水线配好不变，规范定义后不变。每次 AI 介入开发，都从这些静态文件重新开始——没有经验积累，没有学习曲线，没有”上次这么做成功了，这次照着来”。

这就像一个每天失忆的外科医生：医术精湛，但每天早上要重新认识手术室的布局。

人脑的启示：两种记忆 #

人脑有两种记忆，开源 Agent 架构拆解一文的认知二讲得很清楚：

  • 陈述性记忆——“知道什么”（巴黎是法国首都）
  • 程序性记忆——“知道怎么做”（骑自行车）

陈述性记忆让 Agent”想起”你上次说了什么。程序性记忆让 Agent”会做”它上次不会的事。前者是检索增强，后者是能力增长。

当前所有开发范式提供的”上下文”，本质上都是陈述性记忆——一份文档、一份规范、一份 prompt。没有哪种范式把”开发过程中积累的经验”当作一等公民。

这就是 Memory-Driven Development（MDD，记忆驱动开发）要解决的问题。但在讲它之前，需要先看清整条演化链——每一步解决了什么，又留下了什么。

二、搭积木：范式演化矩阵 #

七个阶段 #

用”核心资产”这一维度重新审视十种范式，演化不是线性的”一个替代一个”，而是资产类型的跃迁。每次跃迁解决上一阶段的矛盾，又引入新的矛盾。

阶段一：过程为王（Process-Driven） #

范式：Waterfall、Agile/Scrum

核心资产：流程文档、需求规格、User Story

解决的矛盾：无序开发 → 结构化、可追踪

未解问题：过程文档是”死”的。它们是写给人读的——AI 时代到来后，这些文档既不能被 AI 直接消费，也不随项目演化自动更新。一份 200 页的需求文档，在 AI 看来是噪声而非资产。

阶段二：流水线为王（Pipeline-Driven） #

范式：DevOps

核心资产：自动化流水线、基础设施即代码（IaC）

解决的矛盾：手动部署不可靠 → 持续交付、可重复

未解问题：流水线是无状态的。每次构建独立运行，不积累经验。第 1000 次构建和第 1 次一样——它不会记住”上次这个测试在凌晨 3 点挂过”或”这个依赖版本组合曾导致内存泄漏”。流水线是肌肉，但肌肉没有记忆。

阶段三：指令为王（Instruction-Driven） #

范式：Prompt-Driven、Context-Driven、Spec-Driven

核心资产：Prompt / 项目上下文文件 / 规范文档

解决的矛盾：AI 能做事了，但需要精确指令

这个阶段内部有三个子层次，本身也是一条微演化线：

子范式核心资产持久化程度
Prompt-Driven单次 prompt一次性，用完即弃
Context-DrivenCLAUDE.md、AGENTS.md 等上下文文件持久文件，但仍静态
Spec-Driven可版本化、可审核的规范文档持久 + 可审计，但仍非”记忆”

从”写一个 prompt”到”维护一个上下文文件”，已经是范式转移——你开始意识到有些东西值得持久化。但 CLAUDE.md 是静态文件，不是演化的记忆。它记录的是规则，不是经验。Spec 文档更进一步，可版本化、可审核，但它的本质仍然是约束——告诉 AI 该做什么、不该做什么——而不是积累——让 AI 从做过的事中变聪明。

关键区分：约束告诉 AI 边界在哪，记忆让 AI 知道路径在哪。两者都重要，但不是一回事。

未解问题：每次会话从零开始。上下文文件被重新加载，但开发过程中产生的决策、尝试、失败、成功——全部丢弃。你花了三小时调试一个棘手的 bug，解决方案不会自动沉淀。下次遇到类似问题，从零开始。

阶段四：目标为王（Goal-Driven） #

范式：Intent-Driven、Goal-Driven

核心资产：业务意图、KPI

解决的矛盾：指令太细，人不想管每个细节 → 给目标，让 AI 自己规划路径

未解问题：目标达成后，经验不沉淀。AI 规划了一条成功路径，完成了任务——但这条路径没有被记忆。下次同样的目标，它可能走一条完全不同的路，重复踩同样的坑。

类比：你让一个失忆的员工”把这个项目上线”。他做到了。但你问他”上次怎么做的”，他不记得。你只能希望他下次碰巧走同样的路。

阶段五：编排为王（Orchestration-Driven） #

范式：Workflow-Driven、Multi-Agent

核心资产：工作流定义、Agent 协作拓扑

解决的矛盾：单 Agent 能力有限 → 多 Agent 协作，专业分工

未解问题：工作流是静态定义的。你设计了一条 Agent Pipeline：需求分析 → 代码生成 → 测试 → 部署。这条 Pipeline 不会因为”上次测试 Agent 发现了 80% 的 bug 集中在数据层”而自动调整优先级。编排是骨架，但骨架不学习。

阶段六：治理为王（Governance-Driven） #

范式：Autonomous Software Engineering

核心资产：治理策略、审计日志、授权边界

解决的矛盾：AI 全自主后的安全、合规、问责

未解问题：治理是规则，不是经验。规则约束行为（”不许删生产数据库”），但不让系统变聪明。一个自治系统可能运行了半年，处理了上千个任务——但它的治理策略和第一天一模一样，没有从运行中学到任何东西。

阶段七：记忆为王（Memory-Driven） #

范式：Memory-Driven Development（MDD）

核心资产：可积累、可检索、可验证的数字记忆

解决的矛盾：以上所有范式的共同缺陷——无状态

这不是又一个并列的范式。MDD 解决的是所有范式的共同地基问题：每次开发从零开始，经验不积累。它是其他范式的基底，而非替代品。

演化矩阵 #

把十种范式按”核心资产”维度重新组织：

阶段范式核心资产解决的矛盾留下的未解问题记忆角色成熟度
过程为王Waterfall / Agile流程文档无序 → 结构化文档是死的，AI 不可消费无⭐⭐⭐⭐⭐
流水线为王DevOps自动化流水线手动 → 自动无状态，不积累经验无⭐⭐⭐⭐⭐
指令为王Prompt / Context / SpecPrompt / 上下文文件 / 规范AI 需精确指令每次从零开始，经验不沉淀静态约束⭐⭐⭐⭐
目标为王Intent / Goal业务目标 / KPI指令太细 → 给目标目标达成后路径不沉淀无⭐⭐⭐
编排为王Workflow / Multi-Agent工作流 / Agent 拓扑单 Agent → 多 Agent工作流静态，不随使用演化静态骨架⭐⭐⭐⭐
治理为王Autonomous SE治理 / 审计 / 授权AI 全自主的安全合规治理是规则不是经验静态规则⭐⭐
记忆为王MDD可积累可检索可验证的记忆所有范式的无状态问题冷启动、污染、验证动态积累⭐⭐⭐

最后一列的成熟度是本文的判断，不是行业共识。MDD 给三星，是因为它的各个组成部分（Agent 记忆、RAG、MCP）已经成熟，但作为完整范式尚未被命名和系统化。

三、案例即原理：MDD 最优开发流程 #

从”知道为什么”到”知道怎么做” #

上一节的演化链讲清了”为什么 MDD 是终局”。但知道为什么，不等于知道明天拿到需求该先做什么。

把 Agent 记忆、RAG、MCP、上下文文件这些已存在的技术线索落到一个具体问题上：一个开发者接手项目，从需求到维护，记忆如何贯穿全程？ 答案是一个六阶段闭环——不是理论模型，而是从公开实践中提炼的可执行流程。

全流程闭环 #

flowchart TD
    S0[阶段0 冷启动
播种记忆种子] --> S1[阶段1 需求 intake
记忆参与决策]
    S1 --> S2[阶段2 设计
决策写 ADR]
    S2 --> S3[阶段3 开发
会话级闭环]
    S3 --> S4[阶段4 维护
检索 + 沉淀]
    S4 --> S5[阶段5 优化
模式识别 + 遗忘]
    S5 -.->|经验反哺| S0
    S5 -.->|skill 沉淀| S1

闭环的关键不是六个阶段本身，而是两条回边：阶段 5 提取的 skill 成为下一个项目的种子（反哺冷启动），阶段 4-5 积累的踩坑经验在阶段 1 需求 intake 时被检索（skill 沉淀到需求）。记忆不是线性流水线的副产品，而是驱动下一轮循环的输入。

记忆资产分层 #

闭环运转前，先看清”记忆”不是单一概念。四种记忆各司其职：

记忆类型内容载体检索方式公开实践
陈述性·约束项目规则、技术栈、命名约定AGENTS.md / CLAUDE.md / .cursor/rules/*.mdc每次会话自动注入Claude Code、Cursor、Aider CONVENTIONS.md
陈述性·决策架构选型、技术权衡、为什么选 A 不选 BADR（docs/decisions/NN-标题.md）按主题检索ADR 模板（Michael Nygard 2011，16.3k stars）
陈述性·经验踩坑日志、bug 解法、失败尝试lessons/ 或 issue tracker关键词检索GitHub SpecKit constitution（117k stars）
程序性重复操作的可复用流程skills/<name>/SKILL.mdAgent 按需自动发现opencode skills、Claude Code skills

前三种是陈述性记忆——“知道什么”。第四种是程序性记忆——“知道怎么做”。两者的区别在开源 Agent 架构拆解中讲过：前者是检索增强，后者是能力增长。MDD 闭环的每个阶段都在读写这四类记忆，但侧重不同。

六阶段详解 #

阶段 0：冷启动——播种，不追求完美 #

开发者做什么：接手项目第一件事不是写代码，而是建 AGENTS.md（项目规则、技术栈、构建命令）和 docs/decisions/（ADR 目录）。从历史项目迁移可复用的 skill 作为种子。

记忆如何参与：空记忆的 MDD 等于无 MDD。冷启动期从已有上下文文件作为种子，逐步积累。

公开案例：Claude Code 的记忆是双系统——用户写的 CLAUDE.md（持久指令，每次会话自动加载）+ Claude 自己写的 auto memory（学习笔记，存于 ~/.claude/projects/<project>/memory/）。前者是种子，后者是生长。Aider 的 CONVENTIONS.md 通过 --read 只读加载，可缓存，是更轻量的种子形态。Cursor 的 rules 从单文件 .cursorrules 进化到 .cursor/rules/*.mdc 目录（带 description/globs/alwaysApply frontmatter），本身就是记忆组织方式的成熟。

冷启动最常犯的错：追求一次性写完美的 AGENTS.md。正确做法是写最小可用版本，让后续阶段的使用自然补充。

阶段 1：需求 intake——先检索，再动手 #

开发者做什么：拿到需求不直接开干，先写一句需求简报（一句话目标 + 验收标准），然后让 AI 检索记忆库中相似需求的历史决策和踩坑记录。

记忆如何参与：AI 读取 AGENTS.md（约束）+ 检索 ADR（相关决策）+ 检索 lessons/（同类需求踩过什么坑）。如果历史上有类似需求，AI 能给出”上次这么做成功了/失败了”的参考。

公开案例：GitHub SpecKit（github/spec-kit，117k stars）的工作流是这条阶段的工程化：/speckit.constitution（写项目原则）→ /speckit.specify（写 spec）→ /speckit.plan（技术计划）→ /speckit.tasks（任务拆解）→ /speckit.implement（执行）。每一步的输出都是下一步的输入，且 constitution（原则）会被后续步骤反复引用——这就是陈述性记忆在需求阶段的作用。

阶段 2：设计——决策必须留痕 #

开发者做什么：技术方案不只是写文档，关键决策写 ADR（Architecture Decision Record）。ADR 的核心不是”决定做什么”，而是”为什么选 A 不选 B”——记录权衡。

记忆如何参与：AI 基于 AGENTS.md + 历史记忆生成方案草案，人工审核定稿。ADR 写入 docs/decisions/NN-标题.md，成为可检索的陈述性记忆。

公开案例：ADR 格式由 Michael Nygard 在 2011 年提出（原始博文），公开模板仓库 architecture-decision-record/architecture-decision-record（16.3k stars）。ADR 之所以是记忆而非文档，因为它记录的是决策的推理过程——下次遇到类似权衡时，AI 能检索到”上次为什么这么选”。

ADR 长什么样：四要素 + 真实示例 #

一个标准 ADR 只写四个 section（Nygard 原始格式，极简）：

Section该写什么
Status当前状态：Proposed（提议）/ Accepted（采纳）/ Rejected（否决）/ Deprecated（弃用）/ Superseded（被替代）
Context背景与动机：为什么需要做这个决策？面临什么问题？
Decision决定做什么
Consequences做了之后什么变容易、什么变难

下面是一个真实示例（精简自 ADR 仓库的数据库选型案例）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# ADR-007: 选择文档数据库而非关系型数据库

## Status
Accepted

## Context
应用需要灵活数据模型（字段频繁变化）、水平扩展、
快速检索，但不需要复杂事务和跨表完整性约束。

## Decision
选择文档数据库（MongoDB），不用关系型数据库。

## Consequences
变容易：schema 演化无需迁移、水平分片、索引查询快。
变困难：团队需学习文档模型、无跨文档事务、
数据一致性靠应用层保证。

注意 Decision 段只写”选了什么”——推理过程在 Context 和 Consequences 里。Context 解释约束，Consequences 预判代价。一个写好的 ADR，别人读完能复现你的决策逻辑，而不只是知道结论。

命名约定与 Status 生命周期 #

  • 文件名：NN-kebab-case-title.md，NN 为零填充序号（如 007-choose-document-database.md）
  • 存放：docs/decisions/ 目录
  • 不可删除原则：ADR 一旦 Accepted，只能被标记为 Superseded（并注明被哪个新 ADR 替代），不可删除。这是记忆的不可变性——过时的决策本身也是历史，能解释”为什么曾经这么选，后来为什么改了”。

Status 的流转：

1
2
Proposed → Accepted → Superseded（被新 ADR 替代）
         ↘ Rejected（提议但未采纳）

ADR 在 MDD 中的角色 #

ADR 是陈述性·决策记忆。它与 lessons/（陈述性·经验记忆）配合形成决策-验证闭环：

记忆视角回答的问题
ADR向前看（决策时）为什么选 A 不选 B？
lessons/向后看（验证后）这个选择后来怎样了？踩了什么坑？

阶段 2 写 ADR（向前预判），阶段 4 维护时在 lessons/ 记录结果（向后验证）。下次类似决策时，两者都被检索——既看上次为什么这么选，又看选了之后怎样。

阶段 3：开发——会话级闭环 #

开发者做什么：任务分解 → 增量实现 → 验证循环。每个任务的开发都是一次”加载记忆 → 执行 → 沉淀新记忆”的闭环。

记忆如何参与：每次会话自动加载 AGENTS.md；开发中踩的坑实时记录到 lessons/；代码和记忆同步提交到版本控制。

公开案例：Aider 每次修改后自动 git commit，让代码变更自带”记忆锚点”。Claude Code 的 /memory 命令同时管理用户写的 CLAUDE.md 和 Claude 自己写的 auto memory——前者是约束（人教 AI），后者是经验（AI 自己学）。这个双系统在开发阶段最活跃：AI 一边执行任务，一边把学到的经验写进 auto memory。

开发阶段最常见的记忆缺失：只提交代码，不提交踩坑记录。结果是 bug 修了但”怎么修的”丢了，下次同类问题从零开始。

阶段 4：维护——先检索，再修复 #

开发者做什么：遇到 bug，先检索记忆（”上次这个坑怎么解的”），再动手修。修复后把解法沉淀回记忆。

记忆如何参与：检索 lessons/ 和 ADR；高频 bug 的解法提取为 skill（程序性记忆），让 Agent 下次自动处理。

公开案例：Mem0 v3（2026 年 4 月新算法）采用 ADD-only 写入策略——一次 LLM 调用提取即存储，不做 UPDATE/DELETE。这和数据库的 WAL（Write-Ahead Log）+ checkpoint 是同一思路：写入追求简单（先记下来），检索追求精准（后续整理）。ADD-only 的代价是长期积累垃圾，但换来的是写入零摩擦——维护阶段最怕的不是记忆污染，是记不住。

阶段 5：优化——模式识别与遗忘 #

开发者做什么：定期回顾记忆数据，识别高频模式——反复出现的坑应固化为 skill，过时的决策应标记为 Deprecated。

记忆如何参与：从陈述性记忆（lessons/ADR）中提取模式，固化为程序性记忆（skill）；遗忘机制清理污染记忆和过时决策。

公开案例：opencode 的 skills 系统（.opencode/skills/<name>/SKILL.md，frontmatter 仅 name + description）让 Agent 按需自动发现并加载——从踩坑中提取的程序性记忆，成为可复用的能力。Cursor 的 rules 从 .cursorrules 单文件进化到 .cursor/rules/*.mdc 目录，本身就是”模式识别后结构化”的过程：当规则多到单文件装不下，就按主题拆分，每条 rule 带描述和适用范围。

闭环的自我强化 #

两条回边让闭环不是线性消耗，而是复利积累：

  • 经验反哺冷启动：阶段 5 提取的 skill 成为下一个项目的种子。第一次接手项目要手写 AGENTS.md，第三次接手同类项目可以直接迁移已有的 skills 目录。冷启动成本随项目数递减。
  • skill 沉淀到需求：阶段 3-4 积累的踩坑经验，在阶段 1 需求 intake 时被检索。新需求不必从零评估——“上次做类似功能时这个方案失败了”是现成的决策依据。

这就是 MDD 和所有静态范式的根本区别：Spec-Driven 的规范是写完不变的，MDD 的记忆是越用越厚的。同一个项目，第十次开发的决策质量高于第一次——因为前九次的记忆在参与决策。

四、缺陷与批判：MDD 的边界 #

每个范式的边界 #

诚实地说，没有哪种范式是”终局”。每个范式都有它的边界：

范式边界
过程为王AI 时代仍有价值——大型项目需要结构化思维，但不再是核心
流水线为王基础设施不可少，但它不积累”知识”
指令为王Prompt 仍是日常工具，但它是”一次性”的——写完即弃
目标为王理想很美，但当前模型能力还撑不住完全自主的目标分解
编排为王复杂度高，调试难，适合大型场景而非个人开发
治理为王未来方向，但成熟度最低，工具链尚未形成

MDD 不替代任何范式 #

这是最容易被误解的一点。MDD 不是”取代 Spec”或”取代 Workflow”——它是它们的基底。

1
2
3
4
5
6
7
8
没有记忆的 Spec-Driven：    每次从零写规范，不参考历史
有记忆的 Spec-Driven：      从历史经验中生成规范草案，人工审核

没有记忆的 Workflow：       手动设计每一步
有记忆的 Workflow：         从过往成功路径中自动优化编排

没有记忆的 Autonomous SE：  规则固定，不随运行学习
有记忆的 Autonomous SE：    从运行数据中持续学习，治理策略也演化

记忆是土壤，其他范式是长在上面的植物。没有土壤，植物也能活——但长不大。

MDD 自身的四个硬伤 #

一、冷启动问题 #

空记忆的 MDD 等于无 MDD。记忆系统需要种子——初始的项目知识、决策记录、设计经验。冷启动期的 Agent 经验不足，可能”学会错误”（Hermes skill 漂移问题的类比）。

解法不是技术上的，是实践上的：第三节阶段 0 的流程就是解法——从已有的上下文文件（AGENTS.md、CLAUDE.md）作为种子，逐步积累。不要追求一开始就完美——先跑起来。

二、记忆污染 #

ADD-only 策略（写入快、不管冗余）的代价是长期使用后积累垃圾。过时的决策、错误的尝试、已被推翻的结论——这些”记忆污染”会降低检索质量，甚至误导 Agent。

人脑有遗忘机制，当前的记忆系统大部分没有。Mem0 的 ADD-only 不做 UPDATE/DELETE，GBrain 靠 dream cycle 夜间整理——但什么该忘、什么时候忘、忘了之后如何恢复，这些问题远未解决。

三、验证成本 #

记忆可能是幻觉的传播介质。如果 Agent 从错误记忆中”学到”了一个错误的解决方案，这个错误会通过记忆系统传播到后续所有相关任务——而且比单次幻觉更危险，因为它有了”历史依据”的背书。

验证记忆的正确性需要额外的机制——人工审核、自动化测试、交叉验证。这些机制的搭建成本不低。

四、工具碎片化 #

Mem0 做陈述性记忆，Hermes 做程序性记忆（skill），GBrain 做知识图谱，MCP 做访问协议——各个层面都有人在做，但没有统一的记忆架构标准。今天的记忆系统像 MCP 出现之前的工具生态：M×N 的适配噩梦。

MCP 正在解决”访问层”的标准化，但记忆的”写入策略””遗忘机制””验证流程”仍各自为政。这个问题可能需要一个类似 MCP 的”记忆协议”来解决——但那是后话。

五、总结：开发者的角色迁移 #

回到最根本的问题：AI 时代的开发，到底在开发什么？

开发的本质变了 #

前 AI 时代，开发是写代码。代码是资产，版本控制管代码，CI/CD 跑代码，code review 审代码。

AI 时代，代码越来越多由 AI 生成。开发的重心从”写代码”转移到策展和维护一个让 AI 执行有效的知识体——这个知识体包括项目上下文、决策记录、设计经验、用户反馈、运行数据。

这不是抽象的比喻。AGENTS.md 就是这个知识体的雏形——它不是代码，但 AI 没有它就写不出符合项目约定的代码。PDC 生成的 /api/posts/*.md 也是这个知识体——它不是给人看的 HTML，但 AI 没有它就无法零噪声读取博客内容。

开发者角色的迁移 #

1
2
3
4
代码编写者          →  记忆策展人
  写代码               维护记忆的质量
  管 version control   管 memory 的积累/索引/验证
  code review          memory review

核心能力从”写好代码”变成”维护好让 AI 写好代码的记忆”。这不是降级——维护一个高质量、可检索、可验证的记忆系统，比写代码更难，因为它需要的不只是技术能力，还有判断什么值得记住、什么应该遗忘的元认知。

终极资产 #

开源 Agent 架构拆解认知六的判断，在这里得到了终极验证：

框架是 runtime 可以换，记忆和 skill 是资产不应该换。

37 个 Agent 框架会消亡，你的代码库会被重构，你用的编程语言会更替。但你积累的——关于这个项目为什么这么设计、这个 bug 上次怎么解的、这个架构决策的权衡是什么——这些验证过的、可检索的记忆，是跨框架、跨语言、跨工具的真正资产。

MDD 不是未来时——它的每个组成部分都已经存在。缺的只是把它们组装起来的意识。

参考资料 #