大家好，来了解一下上下文驱动开发（CDD）

喷火龙8号
246 阅读23分钟

大家好，来了解一下上下文驱动开发（CDD）

我们来到上下文驱动的“生成式开发”时代

摘要

在人工智能（AI）日益融入软件开发流程的今天，传统的开发方法论面临新的挑战。本文提出了一个统一的开发新范式——上下文驱动开发（Context-Driven Development, CDD） 。文章不仅论述了为何“上下文”是驱动现代软件开发的核心要素，更进一步探讨了如何将单个项目的上下文沉淀、抽象为可规模化复用的“领域核心资产平台”。通过这种方式，我们能够有效解决同一领域内多项目定制化成本高昂的痛点，最终实现高效、高质量、可进化的“生成式开发”。

1. 引言：超越方法论之争，回归开发本质

在软件开发的世界里，关于“最佳实践”的讨论似乎从未停止。我们常常陷入各种“驱动开发”方法论的争论之中，仿佛在寻找一把能解决所有问题的万能钥匙。然而，在实践的熔炉里，每一把钥匙似乎都有其锈迹与缺口。

我们尝试过需求驱动 (RDD)  ，却发现需求本身如流沙般变幻不定，时而模糊，时而矛盾，甚至从一开始就是错误的。我们转而拥抱测试驱动 (TDD)  ，它以严谨的确定性保证了代码行为的正确，让我们能够“正确地构建代码”。但这并不能阻止我们完美地实现一个完全错误的需求，最终“正确地构建了错误的东西”。我们也曾信赖文档驱动 (DDD)  ，寄希望于它能沉淀知识、统一共识，但那些精美的文档却常常在快速的迭代中被遗忘在角落，与鲜活的代码渐行渐远，最终沦为一座座数字时代的纪念碑，庄严，却与鲜活的实践渐行渐远。

这些方法论，连同后来的行为驱动（BDD） 、领域驱动（DDD） 等，其实都在试图解答同一个永恒的难题：

我们究竟如何才能确保团队中的每一个人——如今，也包括我们新加入的 AI 伙伴——对我们要构建什么、以及为何构建，拥有一个统一、准确且可执行的理解？

在 AI 成为我们开发伙伴的今天，这个问题的答案正变得前所未有地清晰。驱动良好开发的那个核心要素，不再是某一种单一维度的输入，而是高质量、结构化、并持续迭代的“上下文（Context） ”。这预示着一场深刻的变革：开发者的核心角色，正在从一个单纯的“编码者”，悄然进化为一名“上下文工程师（Context Engineer） ”——一个围绕共同目标，为人类与 AI 协作精心设计和提供高质量信息环境的引导者与架构师。

2. 上下文驱动开发 (CDD)：AI 时代的核心准则

如果说“上下文”是驱动开发的核心，那么“上下文驱动开发（Context-Driven Development, CDD） ”就是将这一思想融入软件开发全流程的系统性方法。它并非要推翻过去，而是提供了一个统一的视角，让我们重新审视那些经典的开发模式，将它们的价值吸纳并升华。

在这个统一的框架下，传统开发模式中的核心产物，都转化为了“上下文”的不同侧面。需求文档（RDD/BDD） 不再仅仅是一份待办清单，它成为了定义“我们为何要做”与“我们想做什么”的意图上下文（Intent Context） ，是所有工作的起点与最终目标。测试用例（TDD/BDD） 也不再只是质量保障的工具，它构成了精确、可执行的验证上下文（Validation Context） ，清晰地界定了“怎样才算做对了”。而设计文档与领域模型（DDD） 则沉淀为宝贵的知识上下文（Knowledge Context） ，它记录了系统“是如何构建的”以及“该如何使用它”，是团队共识与架构蓝图的载体。过去，这些上下文分散在不同的流程和工具中，依赖人类去理解和串联。而现在，我们的AI伙伴没有人类的“常识”或“默契”，它100%依赖于我们显式提供的上下文。AI产生幻觉的根本原因，往往就是上下文的缺失或模糊。

表1：经典开发模式在“上下文驱动”中的角色映射

驱动模式核心产物在CDD中的角色上下文类型
RDD/BDD需求文档、用户故事定义“为什么做”和“做什么”意图上下文
TDD/BDD测试用例、验收标准定义“怎样算做对”验证上下文
DDD设计文档、领域模型定义“如何构建”和“如何使用”知识上下文

因此，CDD的核心准则，就是在开发的每一个环节，都优先思考并构建一个让AI伙伴能够高效工作的完备上下文。一个完备的上下文图景，至少由四个关键要件构成：

  • 目标与意图上下文：它如同北极星，为AI指明“我们要去哪里”。
  • 环境与约束上下文：它为AI的创造力提供必要的“护栏”，告知其“我们现在在哪，游戏规则是什么”，包括代码库结构、技术栈、编码规范乃至API契约。
  • 过程与步骤上下文：这是最具体的执行指令，通过任务分解、提供范例等方式，告诉AI“我们具体要怎么做”。
  • 反馈与迭代上下文：它通过捕获错误信息、测试结果、人类评审意见甚至是UI截图，与AI建立起一个持续的闭环，告诉它“你做得怎么样，以及如何修正”。

这种与AI的协作模式，并非一次性的指令下达，而是一个敏捷、高效的“指令 -> 执行 -> 反馈” 循环。这就像教一个新手厨师做菜：你不会把整本菜谱都丢给他，而是先说“把鸡肉切成丁”（指令）。在他完成后，你观察结果（执行），然后立即给出反馈：“很好，接下来准备酱汁”，或者“你切得太大了，像这样修正一下”，并将这个反馈本身作为他下一步操作的新上下文。通过这种快速的迭代，上下文就像滚雪球一样被动态地构建起来，AI的表现会越来越好，其每一步行动也始终在你的引导与掌控之中。

图1：与AI的敏捷协作循环

图片

3. 上下文的沉淀：从“消耗品”到“项目核心资产组”

通过上下文驱动开发（CDD），我们与AI的每一次交互都充满了丰富的信息，宛如一场深刻的对话。然而，如果这场对话在任务结束后就烟消云散，那么上下文的价值便大打折扣，沦为了“即生即灭”的一次性消耗品。这不仅是智力资产的巨大浪费，也意味着下一次我们面对类似问题时，依然要从零开始构建理解。要真正释放上下文的力量，我们必须将其沉淀下来，从“消耗品”转变为可复用的、有生命的“资产”。

这催生了一种更高级的开发模式，我们可以称之为“生成式开发”（Generative Development） 。这是一种根本性的思维转变：

开发的核心活动不再是直接深入到成千上万行代码中进行高风险的“外科手术”，而是去修改作为“单一事实来源”的上下文知识库。

这好比我们不再冒险于高速行驶的汽车上更换零件，而是掌握了这辆车的完整设计蓝图和自动化生产线。通过修改蓝图（上下文），我们就能快速、安全地生成一辆全新的、升级版的汽车。这种从“修补”到“再生”的范式飞跃，将极大地提升软件开发的一致性、可维护性和演进效率。

为了实现这一目标，沉淀下来的上下文知识库就不能是简单的文档堆砌，它必须是一个结构化的、同时服务于人类和AI的存储库。我们将其称为一个项目的“项目核心资产组”或“系统DNA”。这个“核心资产组”精确地描述了系统“是什么”、“为什么是这样”以及“如何演进”。然而，为实现复用，必须建立标准化的‘核心资产组’结构，但这引出了新的挑战：如何设计一个既能表达共性又能容纳个性的分层结构？ 这个问题的答案，正是通往未来软件工程的坚实基石。

4. 从项目到平台：上下文的复用与规模化

当我们把目光从单个项目移开，投向更广阔的业务领域时，一个普遍的困境便浮出水面。许多团队都在同一领域为不同客户提供服务，这本应是知识和经验复用的绝佳场景。然而现实往往是，每个新项目都像是一次“重新发明轮子”的昂贵旅程。尽管客户需求的核心高度相似，但微小的差异却导致了大量的“高成本定制”开发，每一次都耗费巨大，成果却难以迁移。这道定制化成本高昂的裂痕，既是挑战，也恰恰是机遇的萌芽之地：一旦我们能将其弥合，就能释放出惊人的生产力。

要抓住这个机遇，我们需要一次思维上的跃迁：

将上下文从单个项目的“沉淀物”，提升为整个领域的“核心资产”。

这正是构建“领域核心资产平台”的核心思想。在这个平台中，我们将一个领域内所有项目的共性知识——那些反复出现的需求、成熟的架构决策、通用的解决方案——抽象并固化下来，形成一个稳定、可信的“核心核心资产组”。而每个具体项目的独特需求，则作为可插拔的“定制化核心资产包”进行管理。我们的工作，从此不再是搭建一座座孤立的房子，而是精心打造一个能快速装配、定制出各式房屋的“模块化工厂”。

这个“领域核心资产平台”的蓝图，是一个精心设计的五层模型，它清晰地描绘了从抽象意图到具体实现的全过程。

  • 意图层：项目的“北极星”，定义了项目的使命、核心用户故事和验收标准。
  • 领域模型层：连接业务与技术的桥梁，它用统一的语言抽象了业务的核心概念与流程，是整个平台稳定性的基石。
  • 约束层：定义了项目的“物理定律”，包括技术栈清单、架构蓝图，以及一本极其宝贵的、包含各种标准代码范例的“开发‘食谱’(Development Cookbook)  （或者叫做标准作业程序SOP）”。
  • 实现层：通过源代码仓库的链接和架构决策记录（ADRs），将蓝图与具体的代码实现关联起来。
  • 验证层：构成了项目的自动化“质量保证体系”，它包含了完整的测试策略、用例库和CI/CD流水线定义，确保了每一次“生成”的质量。

图2：“领域核心资产平台”的五层复用模型

图片

有了这个平台，AI驱动的“生成式复用”工作流便成为可能，一幅全新的开发图景在我们面前展开。当启动一个新项目B时，我们不再从空白开始，而是克隆整个“领域核心资产平台”。AI首先介入，将B项目的需求与平台中的“核心用户故事库”进行比对，在几分钟内就生成一份差异分析报告。接着，针对差异部分，AI会辅助我们调整领域模型，并评估其对现有模块的影响。当模型确认后，AI便化身为高效的“代码生成者”：它能根据微调后的上下文，自动“再生”或适配那些可复用的核心模块；对于新功能，它会严格遵循“开发食谱”中的规范，生成高质量、风格统一的代码框架。与此同时，验证层的测试脚本也已被AI自动更新，随时准备检验新的成果。整个过程，开发者从繁重的重复劳动中解放出来，聚焦于最具创造性的业务理解和模型设计，开发效率与质量都将实现非线性的跃迁。

图3：AI驱动的生成式复用工作流

图片

5. 上下文的落地：从“知识坟场”到“活的地图”

一个强大的理念，如果不能转化为可执行的实践，最终只会沦为空中楼阁。那么，如何才能让“上下文”这个核心概念在日常开发中真正落地，而不是变成另一个无人问津的“知识坟场”？

答案是：让上下文的维护成本无限趋近于零，并使其价值最大化。这需要我们将上下文的构建与验证，深度融入到开发者最熟悉、最高频的工作流中——也就是代码的提交与审查环节。

想象一下，在一个典型的开发流程中，当一位开发者完成了一个新功能并提交代码审查请求（Pull Request）时，一个自动化的“上下文守护者”（Context Guardian）便被唤醒。这个守护者，本质上是一个由CI/CD流水线驱动的智能机器人，它会像一位严谨的图书管理员一样，一丝不苟地检查这次代码提交是否破坏了团队的“知识契约”。

例如，如果开发者修改了一处API接口，这位“守护者”会自动扫描代码，并立即检查与之对应的OpenAPI/Swagger文档是否也得到了同步更新。如果文档滞后，“守护者”会礼貌地在代码审查中留言提醒，甚至可以基于代码变更，智能地生成一份推荐的文档修改方案，供开发者一键采纳。同样，如果一次提交涉及到核心业务实体的变更，它会检查是否附带了相应的架构决策记录（ADR），以确保每一个重要改动背后的思考都被完整地记录下来。它甚至可以检查新添加的代码是否遵循了“开发食谱”中的最佳实践范例，如果没有，它会给出具体的优化建议和代码片段。

下面是一个简化的CI/CD工作流（如GitHub Actions）示例，它展示了“上下文守护者”是如何工作的：

name: "Context Guardian CI"

on:
pull_request:
    branches:[main]

jobs:
context_review:
    name:"Context Sanity Check"
    runs-on:ubuntu-latest
    steps:
      -name:"Checkout code"
        uses:actions/checkout@v3

      -name:"Find changed source files"
        id:changed_files
        run:|
          # 查找所有在本次PR中变更的 .js, .ts, .java 等源文件
          changed_src = find_changed_files --ext="js,ts,java"
          echo "::set-output name=src_files::$changed_src"

      -name:"Check for related context changes"
        run:|
          # 检查是否有API相关的代码变更
          if contains(steps.changed_files.outputs.src_files, "/api/"); then
            # 如果有, 则验证OpenAPI/Swagger文档是否也同步变更
            api_spec_changed = find_changed_files --path="docs/api.yaml"
            if ! api_spec_changed; then
              echo "::error::API代码已变更,但api.yaml未更新！"
              exit 1
            fi
          fi

          # 检查是否有数据库实体相关的代码变更
          ifcontains(steps.changed_files.outputs.src_files,"/entity/");then
            # 如果有, 验证是否有对应的ADR(架构决策记录)来解释变更原因
            adr_related_exists=find_changed_files--path="docs/adr/"
            if!adr_related_exists;then
              echo"::warning::检测到实体变更, 建议添加ADR说明设计决策。"
            fi
          fi

通过这些实践，上下文知识库的最终形态便清晰地浮现出来——它是一个与源代码共同演进的“活的文档”。它不应该被存放在某个遥远的文档系统中，而应该就位于源代码仓库的一个目录下（例如/context），与代码一起被版本控制，一起经历分支、合并与发布。每一次代码的变更，都伴随着上下文的同步演进。这样，它就从根本上避免了沦为一个无人维护、信息过时的“知识坟场”的命运。它不再是开发完成后需要补写的“作业”，而是开发过程中赖以导航的“活地图”，是一个能自我维护、并持续为团队（包括人类与AI）创造巨大价值的动力引擎。

6. 结语：从“上下文工程师”到“领域架构师”的进化

现在，让我们回到最初的那个问题：在众多开发方法论的喧嚣之中，驱动一个良好开发过程的核心要素究竟是什么？答案已经清晰地呈现在我们眼前。这个核心要素，并非某一种特定的流程或工具，而是那个能让整个团队（包括人类与AI）围绕共同目标高效协作的、活的、可验证的“单一事实来源”。

上下文驱动开发（CDD） ，正是这个核心要素在AI时代的具象化和方法论。它统一并吸纳了过往各种开发模式的优点，将其系统化、工程化，为我们提供了一套与AI无缝协作的全新范式。更重要的是，当我们将CDD的理念从单个项目延伸至整个业务领域，它便成为了实现规模化、低成本定制开发的坚实基础，让我们得以构建起高效的“生成式开发”体系。

这不仅仅是工作方式的转变，更预示着开发者角色的终极进化。在这条进化之路上，我们首先从“编码者”成长为“上下文工程师”，学会了如何为AI伙伴精确地定义问题、构建环境、设计流程并建立反馈闭环。而当我们将上下文沉淀为可复用的“领域核心资产平台”时，我们的角色将进一步升华，成为真正的“领域架构师”和“核心资产平台构建者”。

作为一名领域架构师，我们工作的核心将不再是交付一个又一个孤立的项目，而是致力于构建和维护一个能持续、低成本、高质量生成解决方案的“开发工厂”。我们不再是流水线上的工人，而是流水线的设计者、优化者和守护者。我们塑造的是一个能够“理解”自身并自我演进的系统，这才是我们在AI时代不可替代的核心竞争力。这，不仅是驱动未来软件开发的力量，更是每一位开发者在新时代提升自身价值的终极杠杆。

附录：AI Agent原生时代的实践落地指南

一个前瞻性的理念要真正产生价值，就必须与时代最前沿的技术能力相结合。本文提出的“上下文驱动开发”与“领域核心资产平台”框架，在AI Agent日益普及的今天，其落地方式已发生根本性变革。本章节将提供一套AI Agent原生的实践指南，旨在帮助团队从“使用工具”的传统思维，跃迁至“编排人机团队”的全新范式。

（1）思维转变：从“人+工具”到“人机协作编排”

首先，我们必须进行一次深刻的思维转变。开发者未来的核心角色，不再是单纯的编码者，甚至不只是一个“上下文工程师”，而是一个指挥、编排、引导一支由多个专业AI Agent组成的虚拟团队的“项目总监”或“首席AI编排师”。

在这个新范式下，“领域核心资产平台”不再仅仅是一个静态的“知识库”，它成为了这个人机团队的“中央大脑”和“单一事实来源”。人类负责设定战略目标、定义核心业务逻辑、并进行最终决策；而AI Agent则作为团队成员，依据这个“中央大脑”中的信息，自主执行、分析、生成和验证。

（2）启动与采纳策略：构建你的第一个AI辅助工作流

面对这种变革，我们同样不需要一步到位。关键在于从一个高价值、低风险的场景切入，让团队快速建立起对AI Agent的信任。

  • 定义最小可行智能体 (Minimum Viable Agent - MVA)  ： 忘掉构建完备平台的宏大计划，从定义和实现一个“最小可用”的AI Agent开始。这个Agent应该聚焦于解决当前团队最痛的一个问题。例如：
    • 痛点： 代码合并前，总有人忘记更新API文档。
    • MVA： 创建一个“API契约守护Agent”。它的任务很简单：在每次提交请求（Pull Request）中，自动扫描代码变更，如果发现API路由或数据结构有变动，就自动检查docs/api.yaml文件是否同步更新。如果未更新，它会自动在PR下留言提醒，并附上一个根据代码变更生成的API文档修改建议。
  • 分阶段的演进路径（Agent原生） ：
    • 开发者向“需求分析Agent”输入一段模糊的需求描述。
    • “需求分析Agent”自动与“领域核心资产平台”中的用户故事库进行比对，提出澄清问题，并生成结构化的需求文档。
    • 这份文档会自动触发“测试用例生成Agent”，后者根据验收标准，生成BDD格式的测试用例草稿。
    • 最终，整个需求包（包含结构化需求和测试用例）被提交给开发者进行最终确认。
    1. 阶段一：单点任务自动化 (Task Automation) : 成功实现第一个MVA，让团队看到其价值。接着，可以逐步创建更多的单一任务Agent，如“代码规范审查Agent”、“测试用例建议Agent”、“ADR草稿生成Agent”等。这个阶段的目标是，用一系列小而美的Agent解决具体的重复性劳动。
    2. 阶段二：工作流编排 (Workflow Orchestration) : 将多个单一任务Agent链接起来，形成一个自动化的工作流。例如，一个“需求澄清工作流”：
    3. 阶段三：自主平台演进 (Autonomous Evolution) : 在这个最高阶段，AI Agent不仅是使用者，也成为了平台的“贡献者”。例如，一个“代码模式分析Agent”会定期扫描所有项目的代码库，如果发现某个新的、高质量的设计模式被反复使用，它会自动向“领域核心资产平台”的“标准作业程序(SOP)”中提交一个“新增SOP”的提案，供领域架构师委员会评审。

（3）核心实践：面向Agent的上下文工程

为了让AI Agent能高效工作，我们构建和组织上下文的方式也必须进化。

  • 一切皆可API化 (API-First Context) : “领域核心资产平台”中的所有资产，都不能仅仅是给人看的文档。每一个SOP、每一个领域模型、每一个架构决策，都应该是结构化、机器可读的（如YAML, JSON），并通过内部API暴露出来。这样，Agent才能像调用一个函数一样，精确地查询和使用这些知识。
  • 提供可执行的任务模板 (Executable Task Templates) : 对于平台中的每一个“标准作业程序(SOP)”，都应该附带一个Agent可直接执行的“任务模板”。例如，一个关于“添加新API端点”的SOP，其任务模板可能是一个JSON文件，定义了需要Agent填充的参数（如端点路径、请求方法、数据模型等），以及一个指向自动化脚本的引用。开发者只需填充参数，将任务交给Agent，后者就能自主完成文件创建、代码修改、测试添加等一系列操作。
  • 反馈回路的自动化 (Automated Feedback Loop) : Agent的执行结果（无论是成功的代码、失败的测试报告，还是分析结论）都必须被自动捕获，并作为新的上下文反馈回平台。例如，如果一个Agent生成的代码未能通过CI/CD的测试，那么这次失败的日志、错误代码和相关上下文，应该被自动打包，并与导致失败的那个SOP或任务模板关联起来，作为未来优化该SOP的依据。

（4）治理与维护：人机协同治理模型

平台的治理模式也需要升级，从纯粹的人类治理，演变为人机协同治理。

  • 人类的新角色：
    • 首席AI编排师 (Chief AI Orchestrator) : 负责设计、监控和优化整个Agent团队的工作流，定义它们的目标、权限和协作规则。
    • 领域专家/架构师: 依然是核心，但工作重心从“写文档”转变为“定义和评审机器可读的核心资产”，他们是保证平台知识质量的最终责任人。
  • AI的新角色：
    • 平台守护Agent (Platform Guardian Agent) : 这是一个或一组常驻的AI Agent，负责持续监控“核心资产平台”的健康度，例如检测不同SOP之间的冲突、发现过时的文档、或者标记出使用率极低可能需要废弃的资产。
  • 全新的变更管理流程： 对核心资产的任何修改，其评审标准都增加了一个维度：它对AI Agent的性能有何影响？ 在合并一个变更前，我们甚至可以进行A/B测试，让两组Agent分别使用新旧两个版本的SOP来执行同一个任务，通过比较生成代码的质量、速度和准确性，来数据驱动地决定哪个版本的SOP更优。

通过这套AI Agent原生的实践指南，我们才能真正将CDD的理念，转化为在当前技术浪潮下最具竞争力的工程实践，将开发团队真正带入高效、智能、可规模化的未来。

转载

mp.weixin.qq.com/s/ZyPLxVh05…

avatar
文章
阅读
粉丝