intent-driven-development

用途

Intent-Driven Development 用于在实现之前或实现过程中，把模糊或高影响的产品与工程变更转化为有范围、可验证的验收标准。它的目标是产出有用的验收标准，而不让规格说明变成繁文缛节。

不适用于琐碎编辑、直接的一行修复、正在进行的调试会话、代码审查请求，或验收条件已经明确的实现请求。

先检查上下文：在提问之前读取仓库、文档、schema 和测试基础设施以获取技术事实；产品/业务约束只能由用户或产品产物提供。
选择深度：根据风险画像选择 Quick Capture（3-7 条标准，低/中风险）或 Full Acceptance Brief（安全、数据、迁移、跨系统变更）。
最小化提问：只问那些无法推断、且会实质性改变范围或行为的问题。
编写可观察标准：每条 AC-NNN 描述起始条件、触发、预期结果、禁止的副作用、验证方法和优先级；没有证据时不使用“正确”“安全”等模糊词。
继续或交接：对于清晰且无阻塞风险的请求，记录标准后继续；对于高风险变更，呈现阻塞项并等待确认。
处理修订：如果某条 AC 在实现中途因架构约束失败，标记为 [revised]，更新范围或验证方法，递增修订号，并只重新呈现变更的标准。

工作流包括：

确立目标与风险：提取或询问可观察结果、受影响角色、主要失败后果，以及实际适用的风险维度（安全/隐私、持久化数据、兼容性/API、迁移、外部依赖、成本、并发、性能、可用性/无障碍）。
发现上下文：检查现有行为、相关文件或接口、仓库约定、产品文档、API 契约、数据 schema、迁移历史、现有验证基础设施和外部依赖。将发现的事实与用户提供的假设分开记录。
定义范围：说明目标、范围内、范围外、假设和阻塞决策。
编写验收标准：使用 AC-001、AC-002 等编号，每条包含场景、动作、预期、禁止副作用、验证方法、环境/安全约束和优先级。
只覆盖相关边界：考虑快乐路径、验证、授权/隐私、持久化/迁移、兼容性、失败恢复、幂等/并发、性能、UX/无障碍等类别，但只包含适用的。
呈现并继续：对于澄清/规格请求，呈现简报并只就列出的阻塞项请求决策；对于无阻塞的实现请求，呈现紧凑的标准摘要并继续实现；对于交接，包含足够上下文和验证细节。

Quick Capture 示例：“为仪表盘添加 CSV 导出”——目标、范围、假设和 3-7 条验收标准。
Full Acceptance Brief 触发示例：“将用户认证迁移到 OAuth”——认证变更 + 外部依赖 + 现有会话数据，需要完整简报、风险审查表、会话失效策略的阻塞决策和显式回滚 AC。
已有规格审查：用户粘贴 PRD，技能审查缺失的范围边界、不可验证的需求（如“系统应快速”）和隐性假设，返回修正或补充标准。

不从代码推断产品或业务约束。业务规则、合规和监管义务、合同 SLA、定价、数据保留策略、优先级和目标用户不能从仓库读取，必须由用户或权威产品产物提供，否则记录为待确认假设。
默认不阻塞实现。只有当未解决的决策可能造成重大安全暴露、数据丢失、不可逆迁移、合同/API 破坏、显著成本或破坏性外部操作时，才要求用户明确确认。
不将验收文档写入仓库、不修改项目文件、不创建分支、不提交，也不调用其他技能，除非用户要求或当前仓库工作流明确需要。
自动化测试是证据而非真理。在可靠且相称时优先自动化；在自动化无法确立结果时，允许手动 UX、无障碍、安全、法律或运营验证。
绝不在验收标准、fixture、示例或保存的产物中包含真实密钥、凭据、令牌、私钥、个人数据或敏感生产负载，使用脱敏或合成值。
未经明确授权和确定的安全环境，不运行破坏性测试、迁移、安全探测、负载测试、付费外部调用或针对生产/实时数据的操作。
当验收标准因实现中发现的架构、平台或外部约束无法满足时，不静默丢弃或绕过；更新受影响标准（标记 [revised]、说明约束、调整范围或验证方法），递增修订号，并在继续前只向用户重新呈现变更的标准。

Full Acceptance Brief 使用包含状态、修订、目标、范围、上下文、风险审查、验收标准、阻塞决策和验证计划的模板。Quick Capture 省略不相关部分。

返回简报前检查：目标描述结果而非实现选择；范围边界和假设明确；每条必需标准可观察或明确标记为人工判断；仅在相关处考虑安全、隐私、数据、兼容性、外部效应和 UX 风险；验证方法为高风险操作确定安全环境；输出中未复制秘密或生产敏感信息；未在无正当理由或请求的情况下强制仓库变更或阻塞实现。