validate（验证验收标准）Skill 是什么？怎么用？

验证验收标准Skill：不动状态，一键核查 Linear 问题是否真的达标

一句话定位：/验证 是一个专为 Linear 问题设计的验收标准核查技能，它只做「检查」，不做「状态流转」，把「验收」和「改状态」这两件事彻底解耦。
核心动作：输入 /验证 ENG-123 这类问题编号，技能会拉取问题详情、提取验收标准，逐条标注 ✓ / ✗ 并给出证据与总结比例。
最大差异点：默认不改状态，避免「手一滑把没做完的活标成 Done」这类事故，同时给出「剩余工作」的可执行建议。
上手成本：几乎为零，一条斜杠命令 + 一个问题编号即可，无需记忆参数组合。
适用人群：使用 Linear 做需求/缺陷管理的开发者、QA、技术负责人，以及需要做发布前检查的项目管理者。

该技能叫什么？如何一键安装 AI 技能提升开发效率？

基本信息

项目	内容
技能中文名	验证验收标准Skill
技能英文名	validate
技能ID	14031
技能定位	linear:验证 —— 在不改变状态的情况下验证 Linear 问题的验收标准
调用方式	斜杠命令 `/验证 [参数]`，参数为 Linear 问题编号，如 `ENG-123`

它解决什么问题？

在 Linear 这类问题跟踪工具里，「验收标准（Acceptance Criteria）」通常写在问题描述正文中，但工具本身只负责「状态字段」的流转：To Do → In Progress → Done。于是一个长期存在的团队痛点就出现了——状态可以被随手改成 Done，但验收标准不会自己变绿。常见表现包括：

开发自测时只看了主干流程，漏掉验收标准里的边界条件与异常分支；
Code Review 时没人回头逐条对照验收标准，问题被「看起来差不多」地合入；
QA 或负责人复核时要手动滚动长描述、逐条数勾，费时又容易漏；
更危险的是，核查和状态变更绑在一起，一旦核查动作本身顺带改了状态，出问题后很难追溯。

/验证 的解法很直接：只读核查，绝不改状态。它把「验收标准是否满足」变成一个可以反复执行、结果稳定的检查动作，任何人都能在不改动问题数据的前提下跑一遍。

一键安装的思路与步骤

由于该技能的具体分发渠道、安装命令与依赖配置以官方说明为准，这里给出通用的安装与验证路径，几乎所有 AI 技能平台都遵循同一套逻辑：

确认前提环境：你需要有一个支持「技能 / 斜杠命令」扩展机制的 AI 助手运行环境；同时你需要能访问对应的 Linear 工作区（该技能通过 linear_get_issue 读取问题详情，因此读取权限是必需项）。具体授权方式以官方说明为准。
执行安装：在技能市场 / 技能仓库中搜索技能英文名 validate 或技能ID 14031，选择安装；也可按官方提供的安装入口一键添加。安装命令与配置参数请以官方说明为准，请勿自行猜测填写。
验证是否生效：安装完成后，在对话中直接输入 /验证 ENG-123（替换为你工作区内真实存在的问题编号）。若技能返回「🔍 验证 ENG-123: {标题} / 当前状态 / 分配人 / 📋 验收标准」这样的结构化结果，说明安装与权限均已打通。
排障提示：若提示找不到命令，通常是技能未启用；若提示无法获取问题，通常是 Linear 读取权限或问题编号格式（项目前缀-数字）不匹配。具体排查项以官方说明为准。

为什么说这是「提升开发效率」而非「增加流程」？ 因为它把一次原本需要 3-5 分钟的人工逐条核对，压缩为一次命令调用，并且结果格式统一、可复制进评论、可用于评审记录——流程没有变长，只是把原本靠自觉的环节变成了可执行动作。

该技能的主要功能和特点

只读核查，不改状态：这是它最核心的设计约束。技能明确「不进行状态转换」，验证行为是纯观察性的，可以随时重复执行，不会污染问题数据，也不会误触发工作流自动化。
自动提取验收标准：通过 linear_get_issue 获取问题详情并从中提取验收标准，省去手动翻阅长描述的步骤。
逐条勾选式判定：对每条标准标注 ✓（满足）或 ✗（未完成），未完成项直接显示「状态: 未完成」，视觉上一眼可见缺口。
强制要求「证据」：满足项不是简单打勾，而是需要给出证据——技能会提示你询问用户，或检查最近的评论 / 代码变更。这让「通过」变得可追溯，而不是主观感觉。
量化完成度：输出形如「总结: 3/4 标准满足 (75%)」的统计，进度不靠感觉，靠分母和分子。
给出剩余工作的可执行建议：针对未满足项列出「建议需要做什么」，把「不通过」变成一份待办清单。
自动给出「准备完成？」结论：例如「否 - 先完成剩余标准」，为是否推进状态提供一个客观依据。
结构化输出，便于沉淀：包含标题、当前状态、分配人、验收标准清单、总结、剩余工作，天然适合粘贴到评论区或评审纪要中。

和普通工具比强在哪？ 普通做法要么是「人肉核对」（不可复用、容易漏），要么是「状态驱动的工作流自动化」（只看字段不看内容）。/验证 站在中间：它读的是内容（验收标准），产出的是判断（满足/不满足 + 证据 + 比例），而且不碰状态字段。

如何使用该技能？

标准调用流程

准备一个待验证的问题编号。格式为「项目前缀-数字」，例如 ENG-123。你可以在 Linear 的问题页面标题或 URL 中找到它。
在对话中发起命令：输入 /验证 ENG-123。参数就是你希望核查的那个问题编号，一次一个，保持核查粒度清晰。
等待技能拉取详情。技能会调用 linear_get_issue 获取该问题的标题、状态、分配人以及正文中的验收标准。
阅读结构化报告。输出的形态大致如下（示意）：

🔍 验证 ENG-123: 支持批量导出 CSV

当前状态: In Progress
分配人: 张工

📋 验收标准:

1. ✓ 支持一次导出 1000 条以上记录
   证据: {询问用户或检查最近的评论/代码变更}

2. ✓ 导出文件包含表头且编码为 UTF-8
   证据: {询问用户或检查最近的评论/代码变更}

3. ✗ 导出超时时有明确错误提示
   状态: 未完成

4. ✓ 导出入口在列表页右上角
   证据: {询问用户或检查最近的评论/代码变更}

总结: 3/4 标准满足 (75%)

剩余工作:
- 导出超时时有明确错误提示: {建议需要做什么}

准备完成？ 否 - 先完成剩余标准。

补充证据。对于 ✓ 项，按技能提示回答你的依据（例如「已在 PR #482 的单测中覆盖」「已在评论中附上导出样例文件」）；也可让它去查看最近的评论或代码变更来取证。
处理 ✗ 项。根据「剩余工作」里的建议逐条推进，完成后再执行一次 /验证 ENG-123，直到总结显示全部满足。
推进状态（人工决策）。注意：状态变更不在本技能职责范围内，需由你按团队流程手动完成——这正是「验证」与「流转」分离的价值。

使用小技巧

把验证输出直接粘贴到问题评论中，形成一条可追溯的验收记录；
同一问题在开发完成时、Code Review 前、发布前各跑一次，形成三道闸门；
若验收标准本身写得含糊，✗ 项会明显偏多——这其实反过来暴露了需求描述质量问题，可以推动上游补齐。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
`/验证`（本技能，validate）	只读式验收标准核查器	拉取 Linear 问题详情、提取验收标准、逐条 ✓/✗ 判定、要求证据、给出完成度与剩余工作建议	低：安装后在对话中输入 `/验证问题编号` 即可	开发自测、评审前核查、发布前检查	优势：不改状态、输出结构化、可反复执行；不足：不做状态流转，证据仍需人工确认或结合评论/代码变更判断
人工逐条核对	传统人工复核	打开问题页，肉眼比对描述中的验收标准	零安装，但单次耗时	低频、简单问题	优势：无依赖；不足：易漏、不可复用、无量化记录，长描述下效率极低
通用 AI 对话助手（直接贴文本）	泛用型问答助手	用户手动复制问题描述后让 AI 分析	低门槛，但每次需复制粘贴、上下文易失真	临时性、一次性的核对	优势：灵活；不足：依赖手动搬运、无法直接读取 Linear 数据、输出格式不稳定、无统一判定符号与完成度统计
Linear 内置状态工作流 / 自动化规则	字段驱动的流程自动化	依据状态、标签、负责人等字段触发流转与通知	中：需要在工作区配置规则	流程管理与通知	优势：自动化程度高；不足：只看字段不看内容，无法判断验收标准是否真正满足，与「内容级验收」互补而非替代

选型建议：如果你需要的是「流程跑得快」，用工作流自动化；如果你需要的是「判断准不准」，用 /验证。两者并不冲突，常见的健康组合是——用 /验证 拿结论，再按团队规则手动或自动推进状态。

该技能的典型应用场景与实际体验情况

场景一：开发提交前的自测闸门（角色：一线开发者）

痛点：功能写完了，但验收标准里的边界条件记不全，凭印象觉得「应该都做了」，结果评审时被打回。

使用方式：本地自测完成后，先跑 /验证 ENG-xxx，看到 ✗ 项先自己补齐，再发起评审。

实际体验：上手几乎无学习成本，问题编号是唯一需要准备的东西。体验上的关键收获是「不通过时不说废话，直接告诉你差哪一条」。注意点：✓ 项的证据需要你自己给，别习惯性一路确认——否则这个技能就退化成橡皮图章了。

场景二：Code Review 前的客观依据（角色：评审人 / Tech Lead）

痛点：评审时主要看代码质量，很少有人回头逐条对照需求验收标准，容易放行「代码没问题但需求没做完」的 PR。

使用方式：评审开始前跑一次 /验证，把输出贴在 PR 描述或评论里；✗ 项要求先补齐再进入详细评审。

实际体验：把「我觉得可以了」变成了「4/5 满足，剩余 1 项是 XXX」，讨论焦点从主观判断转向具体事项，评审会议时间明显更可控。注意点：如果验收标准本身缺失或写得过于笼统，输出会显得单薄，需要先推动需求侧补全。

场景三：发布前批量核查（角色：QA / 项目经理）

痛点：发版前需要确认一批问题是真完成，逐个打开页面核对耗时且容易漏项。

使用方式：对候选清单中的每个问题编号依次执行 /验证 ENG-101、/验证 ENG-102……

实际体验：由于输出格式完全统一（状态、分配人、勾选、比例、剩余工作），结果可以直接汇总成一张发布检查表，比人工记录整齐得多。注意点：一次一个编号，批量场景建议按清单顺序执行并保留每次输出。

场景四：跨角色对齐「到底还差什么」（角色：需求方 / 协作同事）

痛点：业务方问「这个需求做完了吗」，开发回答「快了」，双方认知不一致。

使用方式：直接把 /验证 的输出发给对方，用「3/4 标准满足 (75%)」和「剩余工作」代替口头描述。

实际体验：争议成本显著下降，因为双方看的是同一份结构化清单。注意点：输出的「证据」若为待补充状态，需及时补上，否则容易被质疑结论可靠性。

该技能能为用户带来的价值

把「验收」从主观动作变成可执行流程：一次 /验证问题编号 取代 3-5 分钟的逐条人工核对，且结果格式稳定、可复用、可留档。
显著降低漏检风险：技能强制逐条列出验收标准并标注 ✓ / ✗，未完成项无处隐藏，「看起来差不多」不再成立。
消除误改状态的隐患：明确的「不改变状态」设计，让核查动作零副作用，任何人任何频率执行都安全，也让状态变更的责任边界更清晰。
让完成度可被量化沟通：像「3/4 标准满足 (75%)」这样的结论，比「基本做完了」更利于向上汇报和跨角色对齐，减少返工沟通。
反向提升需求质量：当验收标准写得含糊时，验证结果会明显变差，形成对需求描述质量的自然约束，长期看会推动团队把验收标准写得更可判定。
低门槛、易推广：只有「斜杠命令 + 问题编号」两个输入要素，团队新人无需培训即可使用，推广成本极低。

常见问题 FAQ

Q1：这个技能怎么安装？安装后会改变我的 Linear 数据吗？

安装方式请以官方说明为准，通常在技能市场或技能仓库中搜索英文名 validate 或技能ID 14031 即可找到并安装，安装后通过 /验证问题编号 调用。关于数据安全可以放心：该技能的设计前提就是「在不改变状态的情况下验证」，它只读取问题详情，不进行状态转换。

Q2：它和直接把需求描述复制给 AI 分析有什么区别？

主要三点区别：一是它通过 linear_get_issue 直接获取问题详情，不需要你手动搬运文本，避免复制不全或过期；二是输出结构固定（标题、状态、分配人、验收标准清单、总结比例、剩余工作、准备完成结论），便于横向对比和留档；三是它带有明确的「不改状态」约束和「逐条要求证据」的判定逻辑。

Q3：为什么有些 ✓ 项后面显示的是「询问用户或检查最近的评论/代码变更」？

因为技能本身只做核查框架，证据需要落到真实材料上。对于判定为满足的标准，它会提示你去提供依据，或去查看最近的评论与代码变更来取证。这不是缺陷，而是刻意设计——没有证据的勾选等于没验证。

Q4：适合谁用？我们团队规模不大，有必要吗？

最适合三类角色：一线开发（提交前自测）、评审人 / 技术负责人（评审前核查）、QA 与项目管理者（发布前批量检查）。团队规模不是关键变量，关键变量是「你们是否把验收标准写进 Linear 问题描述里」。只要写，就值得用；写得越多，收益越大。

Q5：如果输出显示「准备完成？否」，我该做什么？

直接看「剩余工作」区块，它会针对每个 ✗ 项给出需要做什么的建议。逐条推进后再次执行 /验证同一编号，直到总结显示全部满足。请注意，技能不会替你改状态，最终的状态推进需按团队流程自行完成。