一、为什么用了 OpenSpec/Superpowers 还要先优化规约文档
一条典型需求："活动期间给用户发放优惠券，用户可以在结算时使用。"人类能意会，AI 不行。它可能给黑名单用户发券、不设上限被刷几千张、不做叠加规则让结算金额算成负数。问题不在 AI，在于原材料太糙。
核心观点：不是要把低精度文档写全所有细节，而是把"AI 替你做决定"变成"AI 提供方案、你来做决定"。 事先花半小时优化，远比事后花半天修 bug 划算。
三个原因：
- 自然语言天然歧义。"支持批量导入"是一次 10 条还是 10 万条？"数据实时更新"是毫秒级还是每分钟？AI 没有人类的共享背景知识，只会按概率选最可能的解释，缺口被"合理假设"填上，大概率不是你想要的。
- OpenSpec 提问机制不足。提问数量偏少（复杂任务需追问几十上百个细节，它只问三五个）；理解有随机性（同一问题这次问、下次自作主张）；粒度太粗（字段校验、异常分支、超时策略识别不出）。
- 细粒度掌控必须前置。文档阶段把细节钉死，AI 执行路径变窄，偏离可能性变小。好处：减少 AI 决策空间、降低返工风险、提高方案审查效率。
二、Skill规则
这套规则出自我自己设计的一个 Skill。这里只把大体规则写出来，抛砖引玉，你可以按这个思路搭自己的版本。
a. 歧义词检测与替换
- "和"的歧义：并列还是举例？"必须同时支持 A 与 B" vs "支持 A、B 等功能"。
- "或"的歧义：二选一还是至少一个？"只能选择其中一种" vs "至少支持其中一种"。
- "如果"缺"否则"：补全所有条件分支，如"输错 3 次锁定 30 分钟；否则正常进入；期满自动解除"。
- 语气词：消灭"应该/尽量"，强制场景用"必须"，建议场景用"优先"。
- 数量时间："一些""很多""尽快""响应要快"必须转成具体数值或指标。
b. 逻辑完整性检查
- 成功与失败双向覆盖：不只写成功流程，失败时的错误提示、重试引导、日志记录都要写。
- 正常流程与异常处理：文件超限、格式不支持、上传中断等分支逐一列出。
- 能做与不能做：明确权限边界，如"普通管理员只能删自己的文章；所有管理员不能删已归档文章"。
- 默认行为：所有条件都不满足时系统怎么办，必须明确定义。
c. 优先级与顺序明确
- 顺序编号："第一步 A → 第二步 B → 第三步 C"，杜绝"顺便"。
- 三级标签：【必须】【重要】【可选】。
- 判断标准具体化：把"重要的先处理"改成"订单超 1 万或 VIP 客户为高优先级，2 小时内处理"。
d. 数量与时间精确化
- 数量："一些数据"→"不超过 100 条"；"很多用户"→"同时在线超 1000 人"；"金额很大"→"单笔超 10 万元"。
- 时间："尽快"→"24 小时内"；"响应要快"→"首屏加载不超 3 秒"；"实时更新"→"刷新间隔不超 30 秒"。
e. 角色与权限明确
- 角色类型细化：普通用户/付费用户/超级管理员各自的查看范围。
- 操作权限列清单：明确"包含"和"不包含"哪些操作。
- 权限触发条件：何时获得、何时失去，如"实名认证后获得编辑权限；封禁期间立即冻结"。
f. 实施准则（软件开发类任务）
- 不猜需求：有歧义先澄清，不擅自加功能
- 保持简单：不过度抽象，优先现成方案
- 只做局部修改：改动最小化，不顺手重构
- 先定义"做成了"：先定验收标准，完成后必须有可验证证据
- 分步实施：控制上下文不超 60%，过长主动开新会话
- 分阶段 Git 提交：feat/fix/refactor/docs/style/test/chore 前缀
- 防御式编程：参数校验、空值检查、错误处理、边界保护、默认值、失败降级、日志记录
g. 实施流程
- 询问背景知识（项目代码、文档、知识库）
- 软件类任务先确认是否加入 TDD
- 选提问模式：极简（1 轮）/普通（1-3 轮，推荐）/专业（3-5 轮）
- 分析原文，多轮提问澄清，足够清晰可提前结束
- 输出
原文件名_优化版.md，纯净结构化排版，不加评分总结等多余信息
三、结论
- 别指望Spec框架替你补全需求质量——提问机制是锦上添花，不是雪中送炭。
- 歧义会在规约里放大。每个模糊词都是 AI 自由发挥的空间，"自动""支持""快速"这类词在日常沟通里没问题，写进规约就是埋雷。
- 优化不等于重写。关键动作就三个：消除歧义、补全分支、钉死边界和数量。往往只是加个"必须"、换个具体数值，文档就上一个台阶。
- 把它工具化。整套规则写成 Skill 自动跑，一次配置反复使用。
- 沉淀到 LLM-Wiki。这是一种受 Karpathy 启发的个人知识库方案，把 AI 对话、踩坑记录、歧义模式都存成可检索的知识图谱，让规则持续进化成工程资产。
暂无评论