意图驱动的开发 是做什么的？
在不将规范变为仪式的前提下，生成有用的验收标准。首先检查可用上下文，暴露真正的歧义，并选择与工作及其风险相匹配的验证方法。
何时激活
- 用户要求澄清功能、定义验收标准，或在实施前降低变更风险
- 请求涉及安全、认证、持久化数据、迁移、外部API或合规
- 用户希望为其他智能体或团队准备交接文档
- 请求足够模糊，预期结果尚不可观察或可测试
- 用户通过
/intent-driven-development显式调用此技能
对于简单修改、直接的一行修复、主动调试会话、代码审查请求，或验收条件已清晰的实施请求，不要激活。
工作原理
- 先检查上下文 —— 在提出任何问题之前，读取仓库、文档、模式和测试基础设施以获取技术事实，同时将产品/业务约束视为只有用户或产品制品才能提供的内容
- 选择深度 —— 根据风险概况选择快速捕获（3-7条验收标准，低/中风险）或完整验收简报（安全、数据、迁移、跨系统变更）
- 最小化提问 —— 只问那些答案无法推断且能实质性改变范围或行为的问题
- 编写可观察的标准 —— 每个 AC-NNN 描述起始条件、触发器、预期结果、禁止的副作用、验证方法和优先级；不使用“正确”、“安全”等模糊词汇而没有证据
- 继续进行或交接 —— 对于没有阻塞风险的明确请求，记录标准后继续；对于风险变更，呈现阻塞项并等待确认
- 处理修订 —— 如果在实施过程中，某个AC因架构限制无法满足，将其标记为
[revised]，更新范围或验证方法，递增修订号，并仅重新展示变更的标准
示例
快速捕获 —— “为仪表盘添加CSV导出”
目标：已验证用户可以以CSV文件形式下载仪表盘数据。
范围内：导出当前筛选的行；文件名包含日期。
范围外：定时导出、邮件投递、Excel格式。
假设：最大行数不超过10k；导出的字段中不含个人身份信息。
AC-001：导出生成带正确头部的文件
- 场景：已认证用户，至少有一行数据可见
- 操作：点击“导出CSV”
- 预期：浏览器下载包含列 [id, name, created_at] 的文件
- 不得：暴露内部字段或其他用户的行的数据
- 验证：自动化集成测试 + 手动模式抽查
- 优先级：必选
完整验收简报触发 —— “将用户认证迁移到OAuth”
认证变更 + 外部依赖 + 现有会话数据 → 完整简报，包含风险审查表、关于会话失效策略的阻塞决策和明确的回滚AC。
现有规范审查 —— 用户粘贴PRD
技能审查其缺失的范围边界、不可验证的需求（如“系统应该快”）和隐含假设，然后返回修正或补充的标准，无需重新开始发现。
操作规则
- 在提问之前，检查可用的仓库、文档、议题、设计和测试上下文，以发现可以在本地发现的技术事实。
- 不要从代码推断产品/业务约束。业务规则、合规和监管义务、合同SLA、定价、数据保留策略、优先级和目标用户无法从仓库中读取。将其视为未知，直到用户提供或权威产品文档（PRD、合同、政策文件）说明为止。将它们记录为需要确认的假设，切勿作为已发现的事实。仓库告诉你系统今天的行为方式，而不是业务要求它做什么。
- 只问那些答案必须且无法安全推断的问题。当可以节省不必要的轮次时，将简短相关问题分组。
- 默认情况下不要阻止实施。当用户要求实施足够清晰的变更时，简要记录关键假设和验收标准，然后继续或将其交给实施工作流。
- 仅在未解决的决策可能造成实质性安全暴露、数据丢失、不可逆迁移、合同/API破坏、有意义的成本或破坏性外部操作时，才要求用户明确确认后再继续。
- 除非用户请求或当前仓库工作流明确要求，否则不要将验收文档写入仓库、修改项目文件、创建分支、提交或调用其他技能。
- 将自动化测试视为证据而非绝对真理。当自动化测试可靠且合适时优先使用；允许手动UX、可访问性、安全、法律或运营验证，当自动化无法确定结果时。
- 绝不在验收标准、夹具、示例或保存的制品中包含真实的秘密、凭据、令牌、私钥、个人数据或敏感的生产有效负载。使用脱敏或合成值。
- 未经明确授权和确定安全环境，不要运行破坏性测试、迁移、安全探测、负载测试、付费外部调用或针对生产/实时数据的操作。
- 当某个验收标准在实施过程中因架构、平台或外部约束无法满足时，不要静默丢弃或绕过它。更新受影响的准则（标记为
[revised]，说明约束，调整范围或验证方法），递增修订号，并在继续前仅重新展示变更的准则给用户。仅当修订改变了阻塞决策或实质性降低了安全性或正确性保证时才要求明确确认。
选择深度
使用最小的有用输出。
快速捕获
用于明确但非平凡的低或中风险变更。生成：
- 目标
- 范围内/范围外
- 假设
- 3-7条带有验证方法的验收标准
- 阻塞问题（如有）
除非存在操作规则中的阻塞风险，或者用户明确要求先进行规范，否则不要因等待批准而延迟实施。
完整验收简报
用于模糊、跨系统、安全敏感、数据变更、迁移、合规或高成本的变更，或当用户请求交接文档时。生成下面的完整模板，并在有风险实施前请求确认未解决的阻塞决策。
现有规范审查
当用户已经提供了PRD、议题、计划或验收标准时：
- 审查现有内容，而不是重新开始发现。
- 识别缺失的范围边界、不安全的假设、矛盾以及不可验证的需求。
- 返回修正或补充的标准。
工作流
1. 建立目标和风险
提取或询问：
- 用户或系统的可观察结果。
- 受影响的参与者。
- 主要失败后果。
- 实际适用的风险维度：安全/隐私、持久化数据、兼容性/API、迁移、外部依赖、成本、并发、性能、可用性/可访问性。
避免询问关于无关风险的泛泛问题。
2. 发现上下文
当本地或关联制品可用时，仅检查所需内容：
- 现有行为和直接相关的文件或接口。
- 仓库约定、产品文档、API合同、数据模式或迁移历史。
- 现有验证基础设施和实际命令。
- 外部依赖以及是否可以隔离测试。
将已发现的事实与用户提供的假设分开记录。如果无法检查上下文，说明未知内容并提出针对性问题。
仓库揭示技术事实——系统今天的行为方式、其约定和合同。它不揭示产品/业务约束：业务规则、合规和监管义务、合同SLA、定价、数据保留策略、优先级和目标用户。切勿从代码或命名中重建这些约束。仅从用户或权威产品文档中获取，并在确认前将其列为假设。
3. 定义范围
说明：
- 目标：一句话描述预期结果。
- 范围内：此变更必须交付的行为。
- 范围外：明确排除的诱人的相邻工作。
- 假设：尚未证明的断言。
- 阻塞决策：尚未解决的、实质性影响安全性或行为的选择。
4. 编写验收标准
使用 AC-001、AC-002 等。每个标准必须描述可观察的行为和适当的验证方法；标准和测试不必一一对应。
对于每个适用的标准，包括：
- 场景或起始条件。
- 操作或触发器。
- 预期可观察行为。
- 有意义的禁止副作用。
- 验证方法：自动化测试、集成检查、手动UX审查、可访问性检查、安全审查、运营检查或利益相关方验收。
- 环境/安全约束：当验证可能影响数据、服务、成本或秘密时。
- 优先级：必选、重要或可选。
不要使用“正确”、“安全”、“快”、“直观”或“健壮”等词汇，除非定义了可观察的证据或将其记录为人工评审判断。
5. 仅覆盖相关边界
考虑以下类别，但仅包含适用的类别：
| 类别 | 何时包含 | 典型证据 |
|---|---|---|
| 正常路径 | 新的或变更的、用户可见的行为 | 成功的工作流或状态转换 |
| 验证 | 变更接受输入 | 拒绝格式错误或边界值且不改变状态 |
| 权限/隐私 | 数据或操作有访问边界 | 拒绝访问且无敏感信息泄露 |
| 持久化/迁移 | 存储数据或模式发生变化 | 向后读取、迁移、回滚或备份行为 |
| 兼容性 | 公共API、文件、事件或客户端可能中断 | 现有合同或夹具保持有效 |
| 故障恢复 | 存在网络、服务或异步故障 | 无部分状态或清晰的重试/降级行为 |
| 幂等性/并发 | 重复或同时写入可能发生 | 无重复副作用或无效最终状态 |
| 性能 | 用户或服务阈值重要 | 定义的测量条件和阈值 |
| UX/可访问性 | 人与结果交互 | 键盘、反馈、错误恢复、视觉/手动审查 |
6. 展示并继续
- 对于澄清/规范请求，展示简报，仅就列出的阻塞项请求决策。
- 对于没有阻塞的实施请求，在工作的同时展示紧凑的标准摘要，并继续实施。
- 对于交接给其他智能体或团队，包含足够的上下文和验证细节，使其能够在不编造需求的情况下行动。
- 仅当请求时将简报保存到文件。使用仓库批准的路径（如果存在）；否则在写入前询问或指定目标位置。
输出模板
使用此模板进行完整验收简报。对于快速捕获，省略不相关的部分。
# 验收简报：<变更名称>
**状态：** 草稿 | 已批准 | 已实施 | 已验证
**修订版：** <编号>
**准备对象：** <用户/团队/智能体，如果已知>
**风险工作前需批准：** 是 | 否 - <原因>
## 修订日志
| 修订版 | 日期 | 变更的标准 | 原因 |
| --- | --- | --- | --- |
| 1 | <日期> | — | 初稿 |
## 目标
<一句可观察的结果描述。>
## 范围
**范围内**
- <包含的行为>
**范围外**
- <排除的相邻工作>
## 上下文
**已发现的事实**（技术性、从仓库或制品验证）
- <系统今天的行为、约定、合同>
**产品/业务约束**（由用户或产品制品提供，绝不从代码推断）
- <业务规则、合规/SLA义务、保留策略、优先级、目标用户 —— 或“尚未提供”>
**假设**
- <需要确认或验证的未经证实的断言>
**依赖和约束**
- <外部服务、本地约定、兼容性义务、环境限制>
## 风险审查
| 风险领域 | 是否适用？ | 必需处理 |
| --- | --- | --- |
| 安全/隐私 | 是/否 | <脱敏、授权、审查等> |
| 持久化数据/迁移 | 是/否 | <兼容性、备份、回滚等> |
| 外部影响/成本 | 是/否 | <沙盒/测试环境/授权> |
| 兼容性/API | 是/否 | <要保留或版本化的合同> |
| UX/可访问性 | 是/否 | <手动或自动化证据> |
## 验收标准
### AC-001：<可观察行为>
- **场景：** <起始条件>
- **操作：** <单一触发器>
- **预期：** <可观察结果>
- **不得：** <禁止的副作用，如果适用>
- **验证：** <方法和预期证据>
- **环境/安全：** <约束，如果适用>
- **优先级：** 必选 | 重要 | 可选
## 阻塞决策
- [ ] <仅阻止安全或正确推进的决策>
## 验证计划
| 标准 | 验证证据 | 状态 |
| --- | --- | --- |
| AC-001 | <测试/检查/审查命令或证据类型> | 待定 |
通过/失败示例
使用这些判断技能是否实际生成了可验证的简报，而不是计划性的散文。
一个失败的验收标准
AC-001：导出工作正确且安全。
失败——
“工作正确”和“安全”不可观察，没有场景、触发器、预期结果…
…（因篇幅截断）