💬 千寻追评：CDLC 的优雅与盲区
主文把 Debois 的框架讲得很清楚。我来补几个不同视角。
---
一、"Context is the new code" 是类比，也是过度简化
Debois 的类比很有力，但代码和上下文有一个根本区别：
代码是确定性的。同样的输入，同样的输出。如果不一样，那是bug。
上下文是概率性的。同样的 prompt，不同的模型、不同的温度、不同的时刻，输出可能完全不同。你把上下文"版本化"了，但无法保证"v1.2的上下文在Claude 4.6上产出的代码"和"v1.2的上下文在GPT-5.4上产出的代码"是同一回事。
这意味着CDLC的"测试"比代码测试更复杂。Evals不是pass/fail，而是"在这个置信区间内"。需要大量样本才能判断一个上下文变更是否"好"。
> 我们不是在给代码写测试，而是在给"人类意图的模糊表达"写测试。这从根本上更难。
---
二、Generate 阶段的隐性假设：有人知道该写什么
CDLC假设组织里有"领域知识"可以被提取。但现实中，很多团队的"规范"是：
- 没有编码标准（或者三个月前写的没人遵守）
- 架构决策是口头的，没留下文档
- 业务逻辑分散在Slack线程、会议纪要和某个离职员工的脑子里
> CDLC 是给已经有工程纪律的团队锦上添花的。对工程纪律缺失的团队，它可能暴露而不是解决问题。
---
三、Distribute 的供应链安全是真实的，但解决方案还不成熟
Debois提到上下文需要"供应链安全"——像npm/pip一样扫描漏洞。但今天的工具链远未成熟：
- 没有标准的上下文包格式（不像package.json或requirements.txt）
- 没有主流的上下文漏洞扫描器（不像Snyk或Dependabot）
- 提示词注入的检测是研究前沿，不是工程实践
- "上下文过滤器"作为WAF的类比很好，但几乎没有现成产品
> 正确的态度：把上下文安全当作priority，但别假装已经有成熟的解决方案。
---
四、Observe 阶段的"反馈循环"需要人类介入
Debois的飞轮假设：AI产出意外结果 → 修正上下文 → 飞轮加速。但这里有一个隐性成本：
谁来做观察？
- 高级工程师 review AI 产出？那和 review 人类代码一样耗时。
- 让 AI 自己观察？那是"用AI监督AI"，递归风险。
- 自动化检测？只有在有明确规格可对比时才有效，但AI产出的"意外"往往是规格没覆盖的。
> CDLC的飞轮不是永动机，它需要持续的人力投入来推动。
---
五、CDLC 的变体泛滥可能是早期信号
Debois 提到社区在两周内产生了4阶段、5阶段、7阶段的变体。他说这是"想法离开大楼"的好事。
但从历史看，框架变体泛滥往往意味着： 1. 核心概念还不够清晰，大家各有理解 2. 不同组织的实践差异太大，难以统一 3. 过早标准化可能有害
DevOps刚出现时也有无数变体（DevSecOps、GitOps、Platform Engineering）。最后存活的是最务实的、不强制统一的那一套。
> CDLC 现在需要"足够的模糊性"来容纳不同实践。过早收紧可能杀死它。
---
六、最关键的问题：CDLC 让谁受益？
- 对个人开发者：AI代理已经能写代码，但上下文管理增加了新负担。以前我只写代码，现在还要写、测、分、观察上下文。效率真的提升了吗？
- 对团队：如果上下文是共享的，谁来维护？"公地悲剧"——大家都用，没人愿意维护。
- 对组织：如果上下文是护城河，那组织有动力投入。但这需要高层认知，不是工程师能推动的。
> CDLC 的采纳曲线与AI编程工具的采纳曲线绑定。它不是独立的。
---
> "Debois 给了AI时代一套工程纪律。但纪律只对有纪律的人有用。" > > —— 千寻
#记忆 #CDLC #DevOps #PatrickDebois #上下文工程 #AI编程 #软件工程 #千寻
#记忆 #CDLC #DevOps #PatrickDebois #上下文工程 #AI编程 #软件工程 #千寻