意图驱动开发

意图驱动开发 是做什么的？

制定有用的验收标准，避免规范变成繁文缛节。首先检查可用上下文，暴露真实的歧义性，并选择与工作及其风险相匹配的验证方法。

何时激活

• 用户要求澄清一个功能、定义验收标准，或在实施前降低变更风险
• 请求涉及安全、认证、持久化数据、迁移、外部API或合规性
• 用户希望为另一个代理或团队准备交接工件
• 请求模糊到预期结果尚不可观测或可测试
• 用户使用 /intent-driven-development 明确唤起此技能

对于微小修改、直截了当的一行修复、正在进行的调试会话、代码审查请求，或者验收条件已经明确的实施请求，请勿激活。

工作原理

1. 先检查上下文 — 在提出任何问题之前，读取仓库、文档、模式和测试基础设施，以获取技术事实；同时将产品/业务约束视为只有用户或产品工件才能提供的内容
2. 选择深度 — 根据风险概况选择快速捕捉（3-7条标准，低/中风险）或完整验收简报（安全、数据、迁移、跨系统变更）
3. 最少提问 — 只询问那些无法推断且会实质改变范围或行为的问题
4. 编写可观测标准 — 每个 AC-NNN 描述起始条件、触发条件、预期结果、禁止的副作用、验证方法和优先级；不得使用“正确”或“安全”等模糊词汇而无证据
5. 继续或交接 — 对于清晰且无阻断风险的请求，记录标准并继续；对于高风险变更，呈现阻断点并等待确认
6. 处理修订 — 如果某个验收标准因架构约束在实施过程中失败，将其标记为 [已修订]，更新范围或验证方法，增加修订号，并仅重新呈现变更的标准

示例

快速捕捉 — “为仪表板添加 CSV 导出”

目标： 已认证用户可以将仪表板数据下载为 CSV 文件。
范围内： 导出当前过滤的行；文件名包含日期。
范围外： 定时导出、邮件投递、Excel 格式。
假设： 最大行数不超过 10k；导出字段中不含个人身份信息（PII）。

AC-001： 导出生成包含正确表头的文件
- 场景： 已认证用户，至少有一行数据可见
- 操作： 点击“导出 CSV”
- 预期： 浏览器下载包含列 [id, name, created_at] 的文件
- 禁止： 暴露内部字段或其他用户的行
- 验证： 自动化集成测试 + 手动模式抽查
- 优先级： 必需

完整验收简报触发条件 — “将用户认证迁移到 OAuth”

认证变更 + 外部依赖 + 现有会话数据 → 包含风险评审表的完整简报，关于会话失效策略的阻断性决策，以及明确的回滚验收标准。

现有规范审查 — 用户粘贴了一份 PRD

技能审查其缺失的范围边界、无法验证的需求（“系统应当快速”），以及隐性假设，然后返回修正或补充的标准，无需重新开始发现。

操作规则

1. 在询问可在本地发现的技术事实之前，先检查可用的仓库、文档、工单、设计和测试上下文。
2. 不要从代码中推断产品或业务约束。业务规则、合规和监管义务、合同 SLA、定价、数据保留策略、优先级和目标用户无法从仓库中读取。将它们视为未知，直到用户提供或权威产品工件（PRD、合同、策略文档）明确说明。将它们记录为待确认的假设，绝不作为已发现的事实。仓库告诉你系统今天的行为，而不是业务要求它做什么。
3. 只询问那些答案必须且不能安全推断的问题。当可以节省不必要的轮次时，将简短的相关问题分组。
4. 默认不要阻塞实施。当用户要求实施足够清晰的变更时，简要记录关键假设和验收标准，然后继续或将其交给实施工作流。
5. 仅在未解决的决策可能造成实质性的安全暴露、数据丢失、不可逆迁移、合同/API 断裂、重大成本或破坏性外部操作时，才要求用户明确确认后才能继续。
6. 除非用户要求或活跃的仓库工作流明确要求，否则不要将验收文档写入仓库、修改项目文件、创建分支、提交或调用另一个技能。
7. 将自动化测试视为证据，而非真理。当自动化可靠且比例适当时优先使用；在自动化无法确定结果时，允许手动 UX、可访问性、安全、法律或运营验证。
8. 在任何验收标准、固定样本、示例或保存的工件中，绝不包含真实的密钥、凭据、令牌、私钥、个人数据或敏感的生产负载。使用脱敏或合成值。
9. 未经明确授权和确定的安全环境，不得运行破坏性测试、迁移、安全探测、负载测试、付费外部调用或针对生产/实时数据的操作。
10. 当由于实施过程中发现的架构、平台或外部约束无法满足某个验收标准时，不要静默丢弃或绕过它。更新受影响的标准（标记为 [已修订]，说明约束，并调整范围或验证方法），增加修订号，并在继续之前仅向用户重新呈现变更后的标准。仅当修订改变了阻断性决策或实质上降低了安全或正确性保证时，才需要用户明确确认。

选择深度

使用最小的有用输出。

快速捕捉

适用于清晰但非琐碎且风险低或中等的变更。输出：

• 目标
• 范围内 / 范围外
• 假设
• 3-7 条验收标准及验证方法
• 如果有则列出阻断性问题

除非操作规则中存在阻断性风险，或者用户明确要求先制定规范，否则不要为了审批而延迟实施。

完整验收简报

适用于模糊、跨系统、安全敏感、数据变更、迁移、合规或高成本的变更，或者当用户要求交接工件时。输出以下完整模板，并在高风险实施前请求确认未解决的阻断性决策。

现有规范审查

当用户已经提供了 PRD、工单、计划或验收标准时：

1. 审查它而不是重新开始发现。
2. 识别缺失的范围边界、不安全的假设、矛盾以及无法验证的需求。
3. 返回修正或补充的标准。

工作流

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 ： 导出工作正常且安全。

失败 — “工作正常”和“安全”不可观测，没有场景、触发条件、预期结果