模糊工单
让通知设置更清楚。 用户应该知道自己订阅了什么。
从模糊需求到可执行规格
这些例子展示 Spec Coding 的核心动作：把弱 AI 编码提示词改写成评审者、测试人员和编码代理都能遵守的文件。
Before模糊工单或提示词
After规格、任务、验收、证据
Use复制到 issue、PR 或仓库
示例 1：通知偏好
规格包版本
spec.md - 目标：按事件展示邮件、站内信和推送偏好。 - 非目标：不新增通知供应商。 - 风险：迁移时重复发送通知。 acceptance-criteria.md - Given 现有用户关闭了邮件 When 偏好完成迁移 Then 每个事件的邮件仍保持关闭。 test-evidence.md - 迁移 dry run - 旧移动端截图 - 重复通知回归测试
示例 2：API 错误处理
模糊工单
优化 API 错误。 让客户端更容易处理。
规格包版本
spec.md - 目标：统一 code、message、trace_id 和 retryable。 - 非目标：不改变 endpoint 行为。 - 约束：旧 SDK 仍能解析响应。 acceptance-criteria.md - Given 请求参数校验失败 When API 返回 422 Then 响应包含 code、message、field_errors、trace_id。 test-evidence.md - 400/401/409/422 契约测试 - SDK 兼容 fixture - 变更示例的发布说明
示例 3：报表导出
模糊工单
给报表加 CSV 导出。 大客户也要能用。
规格包版本
spec.md - 目标：支持最多 100 万行的异步 CSV 导出。 - 非目标：不做 PDF 导出。 - 风险：长任务和过期筛选条件。 tasks.md - 保存导出请求和筛选条件 - worker 使用 retry 和 idempotency key - 文件准备好后通知用户 test-evidence.md - 100 万行压测 - worker 失败重试测试 - 过期下载链接检查