企业官网建设流程全解析

在 skills 这个开源工程工作流里，check和test是 AI 代码上线前的两道"闸门"：check负责验证改动真的能跑、并由另一个模型交叉评审，test负责给改动写出可回溯到验收标准（AC）的测试套件。两者配合，构成一套"行为验证 + 独立复核 + 契约溯源"的双重验证机制，帮新手也能把 AI 写出的代码放心地合并进项目。

这套技能遵循 Agent Skills 开放格式，每个阶段一个技能，状态全部落在文件里（而不是聊天里），所以工作可以跨会话、跨成员延续。本文带你读懂check与test到底做了什么、为什么"换模型看代码"更可靠，以及验收标准AC是如何从设计一路追踪到测试的。

🧭 先搞懂位置：check 与 test 在工作流里站在哪

整条交付链路如下，check和test都处在"开发完成之后、合并之前"的收尾段：

idea → /scope → /audit → /architect → /develop → /check verify → /test → /check review → /document → /sync

• /check verify：develop之后立刻跑，证明功能真的能运行。
• /test：把验证过的行为固化成永久测试。
• /check review：合并前，换一个模型做资深代码评审。

也就是说，同一个check技能承担两种角色，再加一个test，三者合力完成"双重验证"。完整背景可看 docs/workflow-guide.md。

🔍 check 技能：一个技能，两种模式

check在 skills/check/SKILL.md 里定义为"合并前的门"。它有两个互不混淆的模式，通常都要跑，且建议先verify再review：

两种模式都从不修改你的代码：verify发现失败会指向/debug或/develop，review则把发现留给实现者去修。

第一步永远是"路由"

check的第一个动作永远是判断该进哪个模式，而不是急着读文件或碰仓库：

• 参数以verify（或run）开头 → 走运行时证明，读 skills/check/modes/verify.md。
• 参数以review开头 → 走代码评审，读 skills/check/modes/review.md。
• 没带模式、或有歧义 →不猜、不默认，直接停下来问你要哪个（verify/review/both）。

这个"裸/check也安全"的设计，让新手可以放心地什么都不带就输入，技能会用纯文本面板停下来等你选，而不是自作主张。

⚖️ 双模型交叉评审：为什么要让"另一个模型"看代码

review模式的灵魂，是评审必须跑在一个"和写代码不同的模型"上。原因在于：一个模型给自己写的代码做评审，会和自己共享同样的"盲点"；而换一个模型，能看见第一个模型错过的东西。

这套机制写在 skills/check/modes/review.md 里，核心是一张"作者模型 → 评审模型"的对照表：

几条硬规则（见 skills/check/modes/review.md#L69-L73）：

• 评审模型绝不能和作者同一家族——这是这个技能存在的唯一不变量。
• 绝不用haiku评审：评审是高价值推理，要用强模型。
• 如果组织限制了可用模型、或客户端子代理只能继承父模型，则退回到"最强的、且不同于作者"的模型；若实在没有不同的强模型，就会在作者模型上内联评审并明确说明——这是一个共享作者盲点的"降级评审"，不再享有跨模型保证。

评审时你还能用自然语言"转向"：/check review（默认对照模型）、/check review with opus（强制指定评审者）、/check review uncommitted（只看工作区未提交改动）。

评审到底在看什么？

评审子代理会按优先级检查八类问题，标准定义在 skills/check/review-guide.md：

1. 正确性：逻辑错误、off-by-one、错误的条件分支、未处理的null、竞态。
2. 安全：未校验输入、注入、缺失鉴权、密钥泄漏、IDOR。
3. 错误处理与韧性：吞掉的错误、空catch、资源泄漏。
4. 性能与规模：N+1 查询、无界循环、热循环里的重活。
5. API 与契约设计：破坏性接口变更、命名不一致。
6. 可维护性：死代码、重复、魔法数字。
7. 约定与决策遵守：是否违反项目AGENTS.md规则、是否与规格矛盾。
8. 测试充分性：按项目的"测试信号"判断（见下文）。

每条发现都要具体（file:line）、有理由（为什么重要）、可执行（该做什么），并给出严重度：🔴 Blocker（合并前必改）、🟠 Major、🟡 Minor、⚪ Nit。最终判定分为Approve/Approve with nits/Changes requested/Blocked四档。发现会写成docs/reviews/<日期>-<分支>.md，而主模型只转述一个紧凑摘要，不把整份 diff 贴回来。

💡 想要更"独立"的第二意见？把活动模型换掉（在你的 AI 工具里/model换一个，或把 diff 贴进另一个助手）再跑一次review即可——不需要任何 API key。

📋 验收标准 AC 溯源：从设计到测试的一条直线

这是整套工作流最优雅的一点：architect在写规格时，会把每条需求变成带编号的验收标准（AC-1、AC-2…），它同时就是后续所有步骤要"对齐的契约"。这条线索贯穿三个阶段：

规格模板里的AC长这样（见 skills/architect/spec-template.md#L31-L39）：

• AC-1：<feature 要正确就必须成立的、可观察可测试的结果>

verify 如何"逐条 AC"验证

/check verify在加载规格契约后（skills/check/modes/verify.md#L52-L70），会优先读取规格旁边的verify.md（/develop生成的、已带AC-N标签的具体验证步骤）；没有则回退到规格的## Requirements，自己把每条AC-N变成可观察的检查项。

然后为每条AC-N和每个"规格声明过的界面"（页面、路由、表、迁移）给出判定：

• ✅达标：检查通过 / 界面存在且行为符合规格。
• 🚫规格要求但缺失：写了要求却完全没实现（作用域漏项）。
• ⚠️建了但没生效：代码在，但运行时检查失败（比如"迁移提交了但列没进库"）。
• ⚠️受阻：缺数据/凭据，无法验证。

证据门槛：一个"不能伪造"的判定

这是新手最容易忽略、却最关键的设计。verify存在一个"证据门槛"（skills/check/modes/verify.md#L136-L145），它要求：

• 没证据，就没有 ✅：一个行为只有在能引用"命令+输出""URL+截图路径""请求+状态码""查询+结果"时才记为达标，引用不了就是blocked。
• 没启动，就没有 PASS：没真正跑起来，就不得对任何东西输出 PASS。
• 用不了的工具算"受阻"，不算"通过"：没有浏览器、没有数据库连接、缺凭据、构建起不来——都让相关行为记为blocked。
• 说出你没检查的部分：部分跑了就必须在Blocked里列出来，不能把部分跑谎报成全通过。

这个原则一句话总结：读代码、看到测试是绿的、"推理它应该能跑"都不算观察。一个伪造的 PASS 是这个技能唯一绝不允许的输出，因为后续每一步都信任它。

🧪 test 技能：按文件类型选策略，测试可回溯到 AC

/test（skills/test/SKILL.md）扮演"资深测试工程师"，目标只有一个：给"你刚改、还没提交"的代码写出一套配得上它的测试，不多不少。它测试的是"调用者依赖什么、什么会真的弄坏用户"，而不是为凑覆盖率刷行数。

自动锁定范围 + 按类型分类

test用git工作树自动圈定"改了但没提交"的文件，然后按路径/文件名给每个文件分类，并为不同类型选择不同测试策略：

（完整分类表见 skills/test/SKILL.md#L68-L74）

覆盖优先级：只写"happy path"不算完成

对每个文件，覆盖按以下优先级排（skills/test/writing-guide.md）：

1. 正常路径：最常规的使用。
2. 边界情况：空、null、零、最大长度、Unicode。
3. 错误状态：非法输入、依赖失败、网络错误、未授权、未找到。
4. 状态迁移：初始 → 操作 → 期望新状态。
5. 可访问性：键盘可达、ARIA 存在、可访问名称正确。

⚠️ 一条铁律："只写了 happy path，就不算完成。"此外遇到认证、会话、支付、PII 相关代码，默认补上越权、凭据过期/被篡改、敏感字段不泄漏等安全用例。

让每个测试都能"回溯"到验收标准

当存在"治理规格"时（TRACE_TO_CONTRACT = yes），test会读验收标准，并把每一条能固化为稳定断言的AC-N都写成一个自动测试，且在测试里打标（例如covers: AC-3注释，或测试名里带AC-3），让整条测试套件能追溯回契约（skills/test/SKILL.md#L177）。

而那些没法自动化的标准（视觉 / 手动 / 环境相关，比如"邮件真的发出去了"）不会被硬造，而是记进NOT_COVERED，并注明"交给/check verify的手动步骤去验"。报告里还会有一段Traceability，逐条列出AC-N ✅ 已锁定 <测试文件 · 测试名>。

它绝不"改代码让测试变绿"

test只写测试，从不修改被测代码。迭代时有两种失败要诚实区分：

• 测试写错了（坏导入、错选择器、错期望）→ 修测试，只重跑那个失败文件。
• 应用代码确实错了（代码违反自己契约或规格）→ 这正是测试在起作用：留红不修，记进BUGS_FOUND，绝不为通过而弱化断言。

最后test会问一句（每次都问）：写完后要不要直接跑套件并修到绿，还是只写、交给你手动跑。若套件通过且验证已绿，这个功能才能被标记为done，规格从In Progress变成Accepted。

🚦 三者配合：上线前的"双重验证"闭环

把前面串起来，就是 AI 代码上线前的完整防线：

这套"行为验证 + 独立复核 + 契约溯源"的叠加，正是 skills 敢让功能在verify与test都通过后才算"完成"的底气。相关的分层防线设计思路，可看 docs/specs/0002-decision-completeness-gate.md。

🚀 快速上手

安装用npx skills，按你的 agent 选一行（装进技能目录后重启即可）：

# Claude Code：装进 .claude/skills npx skills@latest add JavaScript-Mastery-Pro/skills -a claude-code # 通用 .agents/skills（Codex 等可读） npx skills@latest add JavaScript-Mastery-Pro/skills

把装好的技能文件夹提交进仓库，全团队就能共享同一套工作流。最小可用的验证路径：一个小改动，/develop之后直接/check verify就够；一个正式功能，则按verify → test → review走完双重验证。

❓ 常见疑问

是不是两个 check 模式都必须跑？不必。verify是"证明能跑"，review是"独立复核"。低风险小改动可以只verify；高风险功能建议两个都跑，且先verify后review。

换模型评审会不会把我的代码发出去？不会。技能本身从不把代码发到任何外部，跨模型只是在你的客户端内部用一个不同模型的子代理来读代码。想要更独立，自己/model切换再跑即可。

没有规格也能用吗？能。verify和test在没有治理规格时，就基于"观察到的行为"来验证；一旦有规格，二者都会自动切换到"逐条 AC 溯源"的更强模式。

test 和 verify 会不会重复劳动？不会。test写的是"永远能跑的断言"，verify是"打开一次真实应用确认它是真的"。前者是长期保险，后者是合并前的一次性事实确认。

一句话记住这套机制：check verify让你亲眼看到功能在跑、每条验收标准都达标；test把这些通过的行为锁成可回溯到 AC 的永久测试；check review再换一个模型做独立复核。三道关卡各司其职、互不替代，让 AI 写出的代码在上线前获得真正可信的双重验证。