---

name: context-driven-development description: "实现和维护上下文作为与代码并行管理的工件的指南，通过结构化项目文档实现一致的 AI 交互和团队对齐。" risk: unknown source: community date_added: '2026-02-27'

上下文驱动开发

实现和维护上下文作为与代码并行管理的工件的指南，通过结构化项目文档实现一致的 AI 交互和团队对齐。

不适用场景

• 任务与上下文驱动开发无关
• 需要其他领域或工具

操作说明

• 明确目标、约束和所需输入。
• 应用相关最佳实践并验证结果。
• 提供可操作的步骤和验证方法。
• 如需详细示例，请打开 resources/implementation-playbook.md。

适用场景

• 使用 Conductor 设置新项目
• 理解上下文工件之间的关系
• 在 AI 辅助开发会话中保持一致性
• 将团队成员引入现有 Conductor 项目
• 决定何时更新上下文文档
• 管理全新项目与遗留项目的上下文

核心理念

上下文驱动开发将项目上下文视为与代码并行管理的一等工件。不依赖临时提示或分散的文档，而是建立一个持久的、结构化的基础来指导所有 AI 交互。

关键原则：

1. 上下文先于代码：在实现之前定义你要构建什么以及如何构建
2. 活文档：上下文工件随项目演进
3. 单一事实来源：每种类型的信息只有一个规范位置
4. AI 对齐：一致的上下文产生一致的 AI 行为

工作流

遵循 上下文 → 规格与计划 → 实现 工作流：

1. 上下文阶段：建立或验证项目上下文工件存在且是最新的
2. 规格阶段：为工作单元定义需求和验收标准
3. 计划阶段：将规格分解为分阶段的可操作任务
4. 实现阶段：按照既定工作流模式执行任务

工件关系

product.md - 定义做什么和为什么

目的：捕获产品愿景、目标、目标用户和业务上下文。

内容：

• 产品名称和一句话描述
• 问题陈述和解决方案
• 目标用户画像
• 核心功能和能力
• 成功指标和 KPI
• 产品路线图（高层级）

更新时机：

• 产品愿景或目标变更
• 规划新的主要功能
• 目标受众转变
• 业务优先级演变

product-guidelines.md - 定义如何沟通

目的：建立品牌声音、消息标准和沟通模式。

内容：

• 品牌声音和语调指南
• 术语和词汇表
• 错误消息规范
• 面向用户的文案标准
• 文档风格

更新时机：

• 品牌指南变更
• 引入新术语
• 沟通模式需要优化

tech-stack.md - 定义用什么

目的：记录技术选择、依赖和架构决策。

内容：

• 主要语言和框架
• 关键依赖及版本
• 基础设施和部署目标
• 开发工具和环境
• 测试框架
• 代码质量工具

更新时机：

• 添加新依赖
• 升级主要版本
• 变更基础设施
• 采用新工具或模式

workflow.md - 定义如何工作

目的：建立开发实践、质量门禁和团队工作流。

内容：

• 开发方法论（TDD 等）
• Git 工作流和提交规范
• 代码审查要求
• 测试要求和覆盖率目标
• 质量保证门禁
• 部署流程

更新时机：

• 团队实践演进
• 质量标准变更
• 采用新的工作流模式

tracks.md - 跟踪正在发生什么

目的：所有工作单元的注册表，包含状态和元数据。

内容：

• 活跃轨道及当前状态
• 已完成轨道及完成日期
• 轨道元数据（类型、优先级、负责人）
• 指向各轨道目录的链接

更新时机：

• 创建新轨道
• 轨道状态变更
• 轨道完成或归档

上下文维护原则

保持工件同步

确保一个工件的变更反映在相关文档中：

• product.md 中的新功能 → 如需新依赖则更新 tech-stack.md
• 完成的轨道 → 更新 product.md 以反映新能力
• 工作流变更 → 更新所有受影响的轨道计划

添加依赖时更新 tech-stack.md

添加任何新依赖之前：

1. 检查现有依赖是否能满足需求
2. 记录新依赖的理由
3. 添加版本约束
4. 注明任何配置要求