Context Driven Development

核心用法

Context-Driven Development（CDD）将项目上下文视为与代码同等重要的托管产物，通过四份核心文档建立持久、结构化的信息基座：

• product.md：产品愿景、目标用户、核心功能与成功指标
• tech-stack.md：技术栈、依赖版本、基础设施与工具链
• workflow.md：开发方法论、Git 流程、代码审查与质量门禁
• tracks.md：工作单元登记册，追踪任务状态与元数据

标准工作流：Context → Spec & Plan → Implement。任何实现前必须先验证上下文时效性，确保 AI 和团队成员基于同一信息基座工作。

显著优点

1. AI 一致性：跨会话保持行为可预测，消除重复交代背景的消耗
2. 团队对齐：新成员快速 onboarding，术语与目标统一
3. 机构记忆：决策依据随项目演进留存，降低人员流动风险
4. 轻量可维护：四文档结构克制，避免文档膨胀

局限与风险

• 启动成本：绿场项目需一次性投入建立四份文档；棕场项目需逆向提取，工作量不可低估
• 维护纪律：文档易陈旧，需内化为工作完成标准的一部分，否则迅速失效
• 过度设计风险：小型实验或单文件脚本使用此模式反而拖累效率
• 工具依赖：文档价值随 AI 辅助深度而变化，纯人工项目收益递减

适合人群

• 多人协作且使用 AI 辅助开发的团队
• 需要长期维护、成员会轮转的工程化项目
• 复杂度高、上下文切换频繁的代码库

常规风险

• 上下文漂移（Context Drift）：实现与文档脱节
• 隐性知识：成员口头引用但未写入文档的信息
• 更新遗漏：依赖升级或流程变更后未同步 tech-stack.md/workflow.md

建议配套自动化检查（如 pre-commit hook 提醒更新文档）降低人为疏漏。

核心用法

Context-Driven Development 是一套面向 AI 辅助开发的项目治理方法论，而非传统意义上的可执行工具。其核心在于将「项目上下文」视为与代码同等重要的第一等产物，通过四个结构化文档实现知识的标准化管理：

• product.md — 定义产品愿景、目标用户、核心功能与成功指标
• tech-stack.md — 记录技术选型、依赖版本、基础设施与开发工具链
• workflow.md — 确立开发方法论、Git 工作流、代码审查与质量门禁
• tracks.md — 追踪所有工作单元的状态与元数据

使用流程遵循「Context → Spec & Plan → Implement」三阶段：任何实现前必须先读取并验证上下文文档的时效性，确保 AI 与团队基于一致的认知基线进行协作。

显著优点

AI 行为一致性：跨会话的上下文持久化解决了大模型「失忆」问题，显著降低重复解释成本，使 AI 输出风格与项目规范保持稳定。

团队 onboarding 效率：新成员通过阅读结构化文档即可快速建立项目认知，减少「 tribal knowledge」依赖，缓解人员流动带来的知识流失。

决策可追溯性：技术选型与产品变更的 rationale 被显式记录，形成可查询的 institutional memory，支撑未来的架构演进与复盘。

零技术债务引入：纯 Markdown 实现，无运行时依赖、无版本冲突、无安全漏洞传播风险。

潜在缺点与局限性

维护开销：「活文档」要求与代码变更同步更新，团队需建立配套纪律，否则文档迅速过时反而产生误导。

初期投入成本：Greenfield 项目需一次性创建四份文档；Brownfield 项目需投入时间从现有代码库逆向提取上下文。

过度规范化风险：小型实验或单文件脚本采用此框架可能得不偿失，存在「用重型流程解决轻量问题」的错配。

AI 理解边界：复杂业务逻辑的语义压缩存在信息损失，文档无法完全替代领域专家的 nuanced judgment。

适合的目标群体

• 采用 AI 辅助开发的中大型研发团队
• 多贡献者、多 AI 助手协作的复杂项目
• 需要长期维护、重视知识沉淀的代码库
• 远程/异步协作场景，依赖书面共识的团队

不适用：个人快速原型、一次性脚本、无 AI 参与的传统开发项目。

使用风险

性能风险：无——纯文档无运行时性能影响。

依赖风险：无——零外部依赖，仅需 Markdown 渲染能力。

操作风险：上下文文档若未及时更新，可能导致 AI 基于过时假设生成代码，产生隐性架构漂移。建议将文档更新纳入 Definition of Done。

安全风险：极低——经 CLS 认证为 S 级，无代码执行、无网络请求、无敏感数据收集。唯需注意来源可信度为 T3（个人开发者），建议通过官方渠道 ClawHub 安装。