context-driven-development

Context-Driven Development - AI 项目上下文管理指南

技能概述

Context-Driven Development 是一种将项目上下文作为一等公民进行管理的开发方法论，通过结构化的文档体系（product.md、tech-stack.md、workflow.md）确保 AI 辅助开发的一致性和团队协作的精准对齐。

适用场景

1. 新项目初始化和团队协作启动

当启动新的软件项目，或者需要让新团队成员快速理解项目全貌时，使用 Conductor 的上下文驱动开发方法可以一次性建立产品愿景、技术选型和工作规范的标准文档，避免后续重复沟通和认知偏差。

2. AI 辅助开发的会话一致性管理

在多轮 AI 编码会话中，通过维护项目上下文 artifacts，AI 助手能够始终基于最新的产品需求和技术约束提供代码建议，大幅减少重复解释和上下文丢失带来的效率损耗。

3. 现有项目的上下文标准化改造

对于已经运行的代码库，Conductor 可以分析现有代码、配置和文档，自动提取隐式上下文并生成标准化的 artifacts，帮助团队建立显性化的项目知识体系。

核心功能

结构化上下文 Artifacts 管理

提供四个核心文档类型的标准化模板和维护指南：product.md 定义产品愿景和目标用户，tech-stack.md 记录技术选型和依赖版本，workflow.md 规范开发流程和质量标准，tracks.md 跟踪工作单元状态。这些文档相互关联，形成项目知识的单一数据源。

绿地/棕地项目双路径支持

对新项目提供交互式初始化流程，从零建立完整的上下文体系；对现有项目提供代码分析能力，自动推断和预填充 artifacts，支持团队渐进式迁移到上下文驱动开发模式。

上下文验证和同步机制

内置上下文验证清单，确保在开始任何开发任务前，相关 artifacts 都是最新且准确的。同时提供 artifacts 之间的同步规则，如添加依赖时更新 tech-stack.md，完成功能时更新 product.md，防止上下文漂移。

常见问题

Context-Driven Development 和传统项目文档有什么区别？

传统项目文档往往分散在 README、Wiki、代码注释等多个位置，更新不及时且缺乏标准结构。Context-Driven Development 将上下文抽象为四个固定的 artifacts 类型，每个类型有明确的职责边界和更新触发条件，确保上下文始终与代码同步演进，而非成为过时的摆设。

团队多大时适合引入 Conductor？

Conductor 适合任何规模的团队，但价值体现点不同。小团队（2-5人）主要通过减少上下文沟通成本提升效率；中型团队（5-20人）可以显著改善新成员 onboarding 和跨子团队协作；大型团队则需要结合各团队的 tracks 实例来管理复杂的多线程开发。

上下文 artifacts 维护会不会增加额外工作量？

初期建立 artifacts 需要一次性投入，但后续维护是增量式的。Conductor 的设计原则是"上下文变更伴随代码变更"，如在添加依赖时同步更新 tech-stack.md，这种增量更新的成本远低于每次会话重新解释上下文。对于现有项目，Conductor 提供自动化分析工具来降低初始迁移成本。