context-driven-development

Context-Driven Development 是一种将项目上下文视为一等公民的管理方法论，专为 AI 辅助开发场景设计。该技能通过建立结构化的上下文文档体系（product.md、tech-stack.md、workflow.md、tracks.md），解决了 AI 助手在跨会话中缺乏记忆延续性、团队成员对项目理解不一致等核心痛点。

核心用法遵循"Context → Spec & Plan → Implement"的工作流。首先通过 product.md 定义产品愿景与目标用户，tech-stack.md 记录技术选型与依赖约束，workflow.md 规范开发流程与质量门禁，tracks.md 追踪工作单元状态。在每次开发会话前读取上下文确保一致性，会话结束后更新状态，形成闭环管理。

显著优点体现在三个维度：一是团队对齐，新成员可通过文档快速理解项目背景，减少沟通成本；二是 AI 一致性，结构化的上下文确保不同会话中 AI 输出风格与技术选型保持统一；三是知识沉淀，决策 rationale 被持久化保存，避免因人员变动导致的上下文丢失。

潜在局限性包括维护 overhead 较高，不适合单次实验性项目；需要严格的团队纪律确保文档与代码同步更新，否则容易产生"文档漂移"；对于单一文件脚本或传统非 AI 辅助开发场景，引入此方法论可能显得过重。

适合目标群体主要为采用 AI 辅助开发的中长期项目团队，特别是存在多贡献者协作、需要频繁切换 AI 会话或重视知识管理的场景。对于个人临时原型或简单脚本开发则不推荐使用。

使用风险主要集中在文档过时导致的误导性决策，若团队未能建立"完成工作即更新文档"的习惯，错误的上下文可能比无上下文更具破坏性。此外，虽然技能本身为纯文档型无代码执行风险，但依赖外部包管理器（npx）安装，需确保来源可信。

核心用法

Context-Driven Development（CDD）是一套将项目上下文文档化为一等公民的方法论 Skill。它要求开发者在代码目录中维护 context/ 文件夹，包含四个核心文档：

| 文档 | 用途 | 典型内容 |

|------|------|----------|

| `product.md` | 定义 WHY | 产品愿景、目标用户、核心功能、成功指标 |

| `tech-stack.md` | 定义 WITH WHAT | 技术栈、依赖版本、基础设施、开发工具 |

| `workflow.md` | 定义 HOW | 分支策略、提交规范、代码审查、质量门禁 |

| `tracks.md` | 定义 WHAT'S HAPPENING | 工作单元注册表、状态追踪、任务链接 |

每次会话启动时，AI 读取这些文档以建立项目认知；实施前必须验证上下文时效性；完成后需同步更新文档。形成「Context → Spec & Plan → Implement」的标准工作流。

显著优点

1. 会话连续性保障：彻底解决大模型「健忘」问题，每次对话都能基于统一上下文开始，无需反复交代项目背景。
2. 团队对齐加速器：新成员通过阅读四份文档即可快速融入，消除隐性知识依赖。
3. AI 输出一致性：结构化约束使 AI 生成的代码风格、架构决策、命名规范保持高度一致。
4. 机构记忆沉淀：决策依据、技术选型 rationale 被显式记录，人员流动不影响项目认知传承。
5. 零安全负担：纯 Markdown 文档，无可执行代码、无外部依赖、无网络调用，S+ 安全评级。

潜在局限

• 初期投入成本：新项目需一次性撰写四份文档，对原型验证类项目可能显得「过重」。
• 维护纪律要求：文档必须与代码同步演进，否则快速沦为「谎言文档」，反成认知负担。
• 结构刚性：强制四文档结构可能不适合超小型项目或高度实验性探索。
• AI 依赖场景：若项目完全不使用 AI 辅助，本 Skill 价值会显著降低。

适合人群

• 多成员协作团队：需要统一开发规范与术语体系
• 长期维护项目：6 个月以上的持续迭代项目
• AI 辅助开发用户：频繁使用 AI 编程助手但受困于上下文碎片
• 技术负责人/架构师：需要建立可传承的项目治理框架
• 远程/异步团队：文字化上下文成为主要沟通媒介

常规风险

• 文档腐烂（Documentation Rot）：最核心风险。团队可能因节奏压力跳过文档更新，导致上下文与代码背离。需建立「更新文档是任务完成定义的一部分」的纪律。
• 过度设计：初学者可能在 product.md 中过度铺陈愿景而忽视快速验证，建议 MVP 阶段保持文档精简。
• 工具链锁定：虽本身无锁定，但若团队深度绑定特定 AI 平台的 context 管理机制，迁移成本需评估。