用途
speckit-checklist-zh 是一个为软件功能需求生成定制检查清单的专业工具，其核心目的是对“需求质量”进行验证，而不是对实现或系统行为进行测试。
资料将检查表定义为“中文的单元测试”或“英语的单元测试”：检查表是要求编写的单元测试，它们验证特定领域中要求的质量、清晰度和完整性。类比而言，如果规格（spec）是编写的代码，那么检查表就是它的单元测试套件——测试要求是否编写良好、完整、明确并准备好实施，而不是测试实现是否有效。
主要能力
该工具围绕“需求质量验证”构建，明确区分了两类工作：
不用于验证/测试的内容（资料中的反例）：
- 不是“验证按钮正确点击”
- 不是“测试错误处理是否有效”
- 不是“确认 API 返回 200”
- 不是检查代码/实现是否符合规格
用于要求质量验证的内容（资料中的正例）：
- “是否为所有卡片类型定义了视觉层次要求？”（完整性）
- “是否用特定的尺寸/定位量化了‘显著显示’？”（清晰度）
- “所有交互元素的悬停状态要求是否一致？”（一致性）
- “是否为键盘导航定义了可访问性要求？”（覆盖范围）
- “规格是否定义了徽标图像加载失败时的情况？”（边缘情况）
工具按需求质量维度组织检查项，包含的类别有：
- 要求完整性（是否记录了所有必要的要求？）
- 要求清晰度（要求是否具体且明确？）
- 要求一致性（要求是否对齐而无冲突？）
- 验收标准质量（成功标准是否可测量？）
- 场景覆盖（是否解决了所有流程/案例？）
- 边缘情况覆盖（是否定义了边界条件？）
- 非功能性要求（性能、安全性、可访问性等是否指定？）
- 依赖关系和假设（是否记录和验证？）
- 歧义和冲突（需要澄清什么？）
使用方式
工具接受用户输入 $ARGUMENTS，并要求在执行前考虑非空的用户输入。
执行时需要运行前置检查脚本，从仓库根目录执行并解析 JSON，以获取 FEATURE_DIR 和 AVAILABLE_DOCS 列表：
sh: .specify/scripts/bash/check-prerequisites.sh --json
ps: .specify/scripts/powershell/check-prerequisites.ps1 -Json
资料要求所有文件路径必须是绝对路径。对于参数中的单引号（如 "I'm Groot"），使用转义语法，例如 'I'''m Groot'（或尽可能使用双引号："I'm Groot"）。
澄清意图
工具会动态推导最多三个初始上下文澄清问题（无预设目录），这些问题需根据用户措辞和从规格/计划/任务中提取的信号生成，仅询问会实质性改变检查表内容的信息；若在 $ARGUMENTS 中已经明确，则单独跳过。问题优先考虑精确性而非广度。
生成算法包括：
- 提取信号：功能领域关键词（如 auth、latency、UX、API），风险指标（"critical"、"must"、"compliance"），利益相关者提示（"QA"、"review"、"security team"）和明确交付物（"a11y"、"rollback"、"contracts"）。
- 将信号聚类到候选关注领域（最多 4 个），按相关性排序。
- 识别可能的受众和时机（作者、审阅者、QA、发布），如果不明确。
- 检测缺失的维度：范围广度、深度/严谨性、风险重点、排除边界、可测量的验收标准。
问题形式原型包括：范围细化、风险优先级、深度校准、受众框架、边界排除、场景类别差距。问题格式规则：如果提供选项，生成一个紧凑的表格，列为 选项 | 候选 | 重要性原因，最多 A-E 个选项；如果自由形式答案更清晰则省略表格；永远不要要求用户重述他们已经说过的话；避免推测性类别（无幻觉）。
无法交互时的默认值：
- 深度：标准
- 受众：如果与代码相关则为审阅者（PR）；否则为作者
- 关注：前 2 个相关性聚类
回答后，如果≥2 个场景类别（替代/异常/恢复/非功能性领域）仍不清楚，可以要求最多两个更有针对性的后续问题（Q4/Q5），每个问题附带一行理由。不要超过五个总问题。
上下文加载与生成
从 FEATURE_DIR 读取：
- spec.md：功能要求和范围
- plan.md（如果存在）：技术细节、依赖关系
- tasks.md（如果存在）：实施任务
上下文加载策略：仅加载与活跃关注领域相关的必要部分；更喜欢将长段落总结为简洁的场景/要求要点；使用渐进式披露；如果源文档很大，生成中间摘要项目。
生成检查表时：如果不存在则创建 FEATURE_DIR/checklists/ 目录；使用基于领域的简短描述性名称生成唯一文件名（格式：[domain].md，如 ux.md、api.md、security.md）；如果文件存在则追加；从 CHK001 开始顺序编号；每个 speckit-checklist 运行创建一个新文件，从不覆盖现有检查表。
检查项编写规范
每个检查表项目必须评估要求本身，遵循“测试要求质量”而非“测试实现”的模式：
正确模式：
- “是否为 [场景] 定义/指定/记录了 [要求类型]？”
- “是否用具体标准量化/澄清了 [模糊术语]？”
- “[部分 A] 和 [部分 B] 的要求是否一致？”
- “是否可以客观测量/验证 [要求]？”
- “要求中是否解决了 [边缘情况/场景]？”
- “规格是否定义了 [缺失方面]？”
禁止模式：任何以“验证”“测试”“确认”“检查”加实现行为开头的项目；引用代码执行、用户操作、系统行为；如“正确显示”“正常工作”“按预期功能”；如“点击”“导航”“渲染”“加载”“执行”；测试用例、测试计划、QA 程序；实现细节（框架、API、算法）。
项目结构要求：每个项目应遵循询问要求质量的问题格式；关注规格/计划中编写（或未编写）的内容；包括质量维度在括号中（如 [完整性/清晰度/一致性]）；引用规格部分 [Spec §X.Y]；使用 [Gap] 标记检查缺失的要求。
可追溯性要求：最低要求为 ≥80% 的项目必须至少包含一个可追溯性引用；每个项目应引用规格部分 [Spec §X.Y]，或使用标记：[Gap]、[Ambiguity]、[Conflict]、[Assumption]。
内容整合：软上限为如果原始候选项目 > 40，按风险/影响优先排序；合并检查相同要求方面的近似重复项；如果 >5 个低影响边缘情况，创建一个项目。
适用场景
资料给出的示例检查表类型包括：
- 用户体验要求质量（ux.md）
- API 要求质量（api.md）
- 性能要求质量（performance.md）
- 安全要求质量（security.md）
触发词：speckit-checklist、检查清单、需求验证、质量检查、checklist、requirements validation、质量审查、spec review。
报告与限制
生成后，工具会输出创建的检查表的完整路径、项目计数，并提醒用户每次运行都会创建一个新文件。总结内容包括：选择的关注领域、深度级别、参与者/时机、任何包含的用户明确指定的必备项目。
为避免混乱，建议使用描述性类型并在完成后清理过时的检查表。
关于该工具的具体收费、价格、支持平台或效果数据，资料暂未提供。