核心用法
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 提醒更新文档）降低人为疏漏。