disciplined-specification

用途

disciplined-specification 是 disciplined development 流程的第 2.5 阶段。它处于设计阶段（Phase 2，disciplined-design）之后、实现阶段（Phase 3）之前，作用是在动手写代码前，通过深度规格访谈把规格文档中被隐藏、扭曲或泛化的信息挖出来，明确边界条件、失败模式与权衡取舍。

前置条件

根据技能说明，Phase 2.5 需要：

来自 Phase 2（disciplined-design）的已批准实现计划
可参与访谈的用户
可选：额外的规格文件（SPEC.md、需求文档等）

核心原则

质疑显而易见之处：暴露规格中的隐藏假设
探索边界：寻找边界条件与失败模式
对抗式思考：什么会出错？什么可能被利用？
考虑演进：这个需求将来需要如何变化？

输入处理

技能会综合多个文件构建上下文，步骤为：

读取主规格文件（必需）
从规格中提取文件引用
如可用，读取 Phase 2 设计文档
读取被引用的代码文件作为上下文
构建统一上下文用于生成问题

可处理的输入包括：主规格文件（必需）、Phase 2 设计文档（若独立存在则单独处理）、被引用的文件（可选，如代码或其他文档）。

语言精确性分析（跨维度）

在生成各维度问题前，技能会扫描规格文本中的 NLP Meta Model 违规——即信息被删除、扭曲或泛化的语言模式，每一处违规都视为作者无意中移除了必须通过针对性提问找回的信息。检测到的违规会转成高优先级访谈问题。

删除模式（信息被移除）：

未指明的主体：「系统会处理……」→「具体是哪个组件处理？服务之间的交接是怎样的？」
未指明的动词：「数据被处理……」→「具体如何处理？每一步发生什么转换？」
丢失的施为句：「最好的做法是……」→「对谁最好？按什么标准衡量？与哪些备选方案比较？」
缺失的比较：「这样更高效……」→「比什么基线更高效？如何衡量？在什么负载下？」

扭曲模式（信息被扭曲）：

名词化（把过程冻结成名词）：「这个认证」→「谁认证谁，用什么机制，如何验证，失败时怎么办？」
读心：「用户会期望实时更新」→「基于什么证据？用户研究？工单？分析数据？」
假定因果：「这会提升性能」→「通过什么具体机制？在什么条件下？如何衡量提升？」
隐藏预设：「当我们迁移到新系统时……」→「有什么证据支持迁移是必要的？存在哪些替代方案？」

泛化模式（信息被过度外推）：

全称量词：「所有请求都必须认证」→「有例外吗？健康检查？内部服务间调用？Webhook 接收方？」
必要性模态词：「我们必须用微服务」→「如果不用会怎样？谁要求这样？更简单架构的后果是什么？」
可能性模态词：「我们不能在周五部署」→「具体是什么阻碍了？这是政策还是技术约束？需要改变什么？」

使用方法：在为下述任一维度生成问题时，先检查该维度对应的规格文本是否存在 Meta Model 违规；若有，该违规对应的挑战性问题即成为高优先级访谈问题。

十个访谈维度

并发与竞态：两个用户/进程同时做 X 会怎样？部分完成时如何？操作被中断如何处理？一致性模型是什么？
失败模式与恢复：组件 X 在操作中途失败会怎样？用户如何从错误中恢复？失败时保留什么状态？重试语义是什么？
边界与极值：空/零/null 状态下的行为？最大限制是什么、超限会怎样？第一项和最后一项？Unicode、特殊字符、极端长度如何处理？
用户心智模型：用户如何理解该功能？哪些术语可能让他们困惑？他们期望发生但规格未写明的是什么？用户的工作流上下文是什么？
规模与性能：在 10 倍、100 倍、1000 倍当前规模下什么会崩？随增长哪些操作变昂贵？哪里有隐藏的 N+1 查询或 O(n^2) 循环？延迟要求是什么？
安全与隐私：哪些数据可能泄露？哪些操作可能被伪造或重放？适用哪些合规要求？授权边界在哪？
集成影响：这如何影响既有功能？还有哪些系统消费或生产这些数据？撤销/重做、搜索、通知如何处理？应触发哪些 Webhook 或事件？
迁移与兼容：既有用户和数据怎么办？能否回滚、如何回滚？过渡期会发生什么？API 版本如何处理？
可访问性与国际化：屏幕阅读器如何与之交互？是否跨语言、RTL、时区可用？对运动/视觉障碍用户如何？哪些需要本地化？
运维关注点：生产环境如何监控？如何调试问题？需要哪些告警与看板？常见问题的 runbook 是什么？

使用方式与访谈流程

读取所有输入规格文件
分析缺口、歧义与假设
生成 3-4 个深度问题（使用 AskUserQuestionTool），从覆盖最少的维度选择，按规格内容优先高影响领域，问题以具体场景呈现而非抽象概念
记录回答与影响
基于回答识别追问领域
跟踪已覆盖维度与回答的新颖度
重复 3-6 步直到收敛：问题不再产生新关切（连续两轮）、用户明确表示完成、或所有关键维度已探索
将发现追加到设计文档

访谈循环示意：

Interview Loop:
  dimensions_covered = []
  no_new_concerns_count = 0

  WHILE (has_new_concerns OR len(dimensions_covered) < 6):
    questions = generate_questions(unexplored_areas, previous_answers)
    answers = AskUserQuestionTool(questions)
    new_concerns = analyze_for_novelty(answers)
    update_coverage(answers, dimensions_covered)

    IF (new_concerns):
      no_new_concerns_count = 0
    ELSE:
      no_new_concerns_count += 1

    IF (no_new_concerns_count >= 2):
      offer_to_conclude()
      IF (user_confirms_done):
        BREAK

问题质量准则：避免显而易见的问题（如「按钮什么颜色？」「错误信息文案是什么？」「每页多少条？」「要不要校验输入？」「哪些字段必填？」「数据库 schema 是什么？」），而要生成能呈现具体场景、暴露二阶效应（「如果 X，那 Y 呢？」）、挑战未言明假设、探索规格行为边界、考虑对抗性或意外用法、思考功能生命周期（创建、使用、修改、删除）的问题。

收敛检测依据：新颖度跟踪、维度覆盖、语言精确性（统计原始规格中的 Meta Model 违规被挑战和解决的数量）、追问衰减（连续 2 批以上问题未产生新的重要关切则提议结束）、用户信号（用户随时可说「可以了」提前结束）。

完成标准与输出

完成标准：问题不再产生新关切或需求（连续两轮），或用户明确表示完成；已探索主要维度（10 个中至少 5-6 个）；已探索区域无关键歧义残留。

输出格式为把新章节追加到设计文档中，章节名为「Specification Interview Findings」，包含访谈日期、覆盖维度、收敛状态，以及按维度记录的关键决策（并发与竞态、失败模式、边界情况、用户体验、规模与性能、安全与隐私、集成影响、迁移与兼容、可访问性、运维就绪）、延后事项（含延后原因）和 2-3 段的访谈摘要。

约束与限制

不做实现：本阶段只做规格细化
不出浅问题：每个问题都必须暴露非显而易见的关切
基于收敛：不要无限访谈，要检测价值何时递减
追加到设计文档：输出写入既有设计文档
用户驱动：用户可随时结束访谈

后续步骤

Phase 2.5 完成后：如需要与利益相关方复核追加的发现；随后使用 disciplined-implementation 技能进入实现阶段（Phase 3）。