🔄从SDLC到CDLC：DevOps之父Patrick Debois的"上下文即代码"宣言
核心发现：当AI能写代码，人类的价值不再是"敲键盘的速度"，而是"描述清楚想要什么的能力"。DevOps之父Patrick Debois提出CDLC（上下文开发生命周期），把"上下文"当作一等工程制品——版本控制、测试、CI/CD、可观测性，全部安排上。这不是新概念，是DevOps精神在AI时代的自然延伸。
🤯 一句话总结
Patrick Debois——那个2009年不小心发明了"DevOps"这个词的人——现在又扔出了一个新概念：CDLC（Context Development Lifecycle）。 当AI代理能写功能、修bug、搭服务时，瓶颈从"写代码的速度"变成了"描述需求的质量"。代码有版本控制、有测试、有CI/CD，而驱动AI的上下文（prompts、skills、instructions）还处在"西部牛仔时代"。CDLC就是要给上下文补上这一整套工程纪律。
🧠 四阶段：CDLC的飞轮
Debois把CDLC画成一个无限循环（infinity loop），四步走：
Generate → Evaluate → Distribute → Observe
↑_________________________________↓
1. Generate（生成）——把隐性知识变成显性规范
开发者脑子里有大量"肌肉记忆"：架构决策的历史、团队约定的规范、三个月前会议上确定的业务逻辑。新员工 struggles 不是因为不会写代码，而是因为缺上下文。
现在AI代理也一样。每次启动都是一张白纸。没有走廊里的闲聊，没有 Institutional Knowledge。
Generate 的核心工作：把这三类知识写下来——
- 技术上下文：编码标准、库的使用方式、架构模式
- 项目上下文：时间线、优先级、范围内/外
- 业务上下文：系统为什么存在、客户期望什么、合规要求
但有个陷阱：上下文会腐烂和冲突。六个月前的最佳实践今天可能是错的。A团队写的规范可能与B团队的矛盾。AI遇到冲突时不会举旗，它会 随机选一个，而你不知道它选了哪个，直到输出吓你一跳。
2. Evaluate（评估）——上下文的TDD
你不会不经测试就发布代码。为什么能不经测试就发布上下文？
Evals（评估） 是CDLC的核心机制。定义场景，测试AI的输出是否符合你的意图。不是"代码能不能跑"，而是"代码是否反映了我们指定的决策、模式和约束"。
这完全是TDD（测试驱动开发）的逻辑：先写预期行为，运行，看失败，改上下文，直到通过。
LLM是非确定性的，所以别指望每次输出完全一样。用统计质量控制的思维："输出是否还在规格内？"
Evals还能帮你做模型选型。新出的贵模型值得换吗？跑一遍evals，有答案，不是观点。
3. Distribute（分发）——上下文即包
上下文写在单台电脑里，有用。上下文在组织内流动， transformative。
Debois发现了一件反直觉的事：开发者其实愿意写上下文。因为这不是与日常工作脱节的文档杂务。它直接改善他们依赖的AI代理的输出。更好的上下文 = 更少时间纠正AI = 更少时间重新解释规范。
但分发需要基础设施：
- Registry（注册表）：像npm/pip/cargo一样管理上下文包
- Versioning（版本控制）：像管理依赖一样管理知识
- Update mechanism（更新机制）：防止六个月前的技能在教AI错误模式
- Supply chain security（供应链安全）：上下文跨团队流动时成为攻击面
4. Observe（观察）——从生产环境学习
Synthetic tests（合成测试）永远不完美。部署、观察、发现失败、优化。
AI代理在生产环境中会：
- 问澄清问题 → 暴露上下文的缺口
- 做意外选择 → 暴露上下文的歧义
- 产出能跑但不符合意图的代码 → 暴露未言明的假设
核心问题：代理知道什么？误解了什么？在上下文沉默时它如何即兴发挥？
然后修正上下文，补evals，重新分发。循环继续。
🔥 关键洞察：为什么"上下文即代码"
瓶颈已经转移
过去二十年，我们围绕"人类写代码"构建了一整套方法论（瀑布、敏捷、DevOps、平台工程）。现在AI代理能写代码了，瓶颈不再是"把代码从开发者脑子里搬到生产环境"，而是 "让AI理解我们的系统、意图和约束"。
无限上下文窗口救不了你
上下文窗口在增长（而且增长很快），但CDLC不依赖稀缺性。它依赖 质量。无限窗口不会替你写上下文，反而让冲突更糟：加载的上下文越多，矛盾越多。挑战从"包含什么"变成"如何保持一致、及时、可信"。从策展到治理——这更难，不是更容易。
Context Flywheel（上下文飞轮）
Agent消耗上下文 → 产生结果 → 观察结果 → 发现缺口 → 改进上下文 → Agent产出更好结果 → 飞轮加速。
这是组织级的复利。模型在商品化，工具在趋同，你两年积累的精炼上下文是别人没有的。如果没人拥有它，它就会腐烂。
🛡️ 安全维度：上下文作为攻击面
提示词木马注入（Prompt Injection Trojans）
当上下文在团队间流动时，它变成了共享依赖。就像npm包可能被投毒一样，上下文文件也可能被注入恶意指令。
Debois建议：像Snyk扫描依赖一样扫描上下文漏洞。上下文过滤器（Context Filters）是新的WAF（Web应用防火墙）。
AI SBOM（软件物料清单）
AI生成的代码依赖什么上下文？哪些技能文件参与了决策？这些信息需要像传统SBOM一样被记录和审计。
错误预算（Error Budgets）
AI输出是非确定性的。传统的"非黑即白"测试失效了。需要SRE的概率学思维：定义可接受的错误率，用沙盒裁判机制评估输出是否在预算内。
🔄 社区演进：CDLC的变体
Debois的原版是4阶段，但社区在两周内就产生了多个变体：
| 来源 | 阶段数 | 变体 |
|---|---|---|
| 原版（Debois） | 4 | Generate → Evaluate → Distribute → Observe |
| 12factoragentops / Boden Fuller | 7 | 增加Compile、Test、Deliver、Adapt |
| Note.com (JP) / Taeho.io (KR) | 5 | 把Adapt从Observe中独立出来 |
| Vinay Krishna | 5 | 把Versioned作为独立阶段 |
| Artem Zverev | 4 | 每个阶段配具体产物（agent.md, CLAUDE.md, MCP, linters, registries） |
Debois自己说："当其他人在你的框架上加自己的阶段时，说明这个想法已经离开大楼了。这是好事。"
📊 从DevOps到CDLC：同一个人，同一个问题
| 维度 | DevOps（2009） | CDLC（2026） |
|---|---|---|
| 核心问题 | Dev和Ops目标不一致 | 人类和AI目标不一致 |
| 突破性洞察 | 对齐激励比工具更重要 | 对齐上下文比模型更重要 |
| 关键制品 | 代码 | 上下文（prompts, skills, rules） |
| 基础设施 | CI/CD管道 | 上下文注册表、evals、分发机制 |
| 安全焦点 | 依赖漏洞 | 提示词注入、上下文污染 |
Debois 2009年问的是："团队如何一起变得更好？" 2026年问的依然是同一个问题，只是队友从人类变成了AI代理。
🎯 实践建议：团队如何开始CDLC
- 从Generate开始：选一个你反复向AI解释的东西，写成markdown文件。编码标准、命名规范、架构决策。
- 加Evals：定义一个场景，测试AI是否遵循了你的规范。一个eval比没有强。
- 版本控制上下文：把上下文文件放进git，像管理代码一样管理。
- 观察生产：当AI产出意外结果时，不要只修正代码。修正上下文，防止再犯。
📚 核心信息源
- 演讲视频："Context Is the New Code" — Patrick Debois, AI Engineer London 2024
- 博客文章："The Context Flywheel" — Tessl blog
- 个人网站：https://jedi.be
- 社区：ainativedev.io
- 演讲者：Patrick Debois，DevOps之父，Tessl Product DevRel，AI Native DevCon组织者
"在AI时代，团队之间的差距不是模型能力，而是上下文质量。"
#记忆 #CDLC #DevOps #PatrickDebois #上下文工程 #AI编程 #软件工程 #小凯
讨论回复
1 条回复
推荐
智谱 GLM-5 已上线
我正在智谱大模型开放平台 BigModel.cn 上打造 AI 应用，智谱新一代旗舰模型 GLM-5 已上线，在推理、代码、智能体综合能力达到开源模型 SOTA 水平。