Opencode最被低估的6个测试指令：每天帮你省下3小时重复劳动

你不需要每次都重新"教"AI怎么测，把流程写成指令，一次配置，终身复用

大家好，我是某互联网公司的测试架构师。

上个月，团队来了一个新项目，后端代码将近20万行，测试覆盖率只有35%。开发改一行代码，测试团队要花大半天做回归。

测试负责人找到我："这项目光跑一遍全量测试就要2个多小时，每次改完代码等测试结果等到花儿都谢了。"

我说："你用Opencode吗？"

他说："用啊，但每次都是手动敲Prompt——'帮我跑测试''帮我看覆盖率''帮我把失败的测试修一下'——一天光敲这些重复的话就得几十遍。"

我打开他的Opencode配置，看了一眼，说了一句："你缺的不是AI能力，你缺的是6条指令。 "

我花了半小时帮他配了6条自定义指令。从那以后，他每天至少省下3小时重复劳动。

一、大多数人用Opencode的姿势，浪费了它80%的能力
Opencode是Anomaly团队开发的开源AI编程Agent，2026年3月发布后迅速登顶Hacker News。它完全开源、支持75+种大语言模型、可以运行在终端、桌面和IDE中。

但大多数人用Opencode的方式和用普通AI聊天工具没什么区别——每次打开，输入"帮我跑一下测试""帮我看看覆盖率"，等AI执行完，再输入下一句。

每次都要重新描述一遍你要做什么、怎么做、输出什么格式。

这就像你每天上班都要重新教一遍实习生"怎么打开电脑、怎么登录系统、怎么运行测试"——浪费的是你自己的时间。

Opencode真正的杀手锏，是自定义指令（Custom Commands）。

你把常用的测试流程写成一条指令，以后只需要输入/指令名，AI自动执行整套流程。一次配置，终身复用。

下面这6条指令，是我在实际项目中反复验证过的，每一条都能帮你省下至少30分钟的重复劳动。

二、6条最被低估的测试指令
指令一：/test —— 一键跑全量测试 + 自动修失败
做什么： 跑完整套测试，生成覆盖率报告，自动分析失败的测试并给出修复建议。

什么时候用： 每次代码修改后，想快速确认有没有破坏现有功能。

怎么配： 在.opencode/commands/test.md创建文件：

description: Run tests with coverage and triage failures

agent: build

Run the full test suite with coverage report and show any failures.
Focus on the failing tests and suggest precise fixes.
真实效果： 我们团队有个模块的测试套件有800多条用例。以前每次跑完要人工翻日志找失败原因，现在输入/test，AI自动跑完、自动分析、自动给出修复建议。原来45分钟的工作，现在2分钟。

指令二：/coverage —— 精准定位未覆盖代码
做什么： 分析覆盖率报告，列出所有未覆盖的文件、函数和分支。

什么时候用： 想知道"还有哪些代码没被测试覆盖到"。

怎么配：

description: Analyze test coverage gaps

agent: plan

Here are the current test results:
!npm test -- --coverage --reporter=json

Based on these results:

1. List all files with coverage below 80%
2. For each file, show which functions or branches are not covered
3. Prioritize gaps by risk (core business logic > utilities > configs)
4. Suggest which files should be prioritized for new tests
   关键技巧： 用!命令把shell输出直接注入Prompt。每次执行/coverage，AI都能拿到最新的覆盖率数据，不用你手动复制粘贴。

指令三：/test-plan —— 自动生成测试计划
做什么： 分析代码变更，自动生成对应的测试计划。

什么时候用： 接手新功能或重构代码时，不知道"该测哪些场景"。

怎么配：

description: Generate test plan for changed code

agent: plan

Review the following changes:
!git diff --name-only HEAD~1

For each changed file:

1. Identify the core functionality being modified
2. List all test scenarios that should be covered (normal path, edge cases, error handling)
3. Identify any dependencies that need to be mocked
4. Prioritize test cases by risk

Output: A structured test plan with clear priorities.
指令四：/fix-tests —— 自动修复失败的测试
做什么： 分析失败的测试，定位根因，自动修复。

什么时候用： 测试跑红了，但不确定是代码Bug还是测试写错了。

怎么配：

description: Fix failing tests automatically
agent: build

subtask: true

The following tests are failing:
!npm test -- --reporter=verbose --grep "FAIL"

For each failing test:

1. Analyze the failure — is it a code bug or a test bug?
2. If it's a test bug, fix the test directly
3. If it's a code bug, explain the issue and suggest a fix
4. Re-run the test after each fix to confirm it passes

Do not change production code without explaining why.
关键配置：subtask: true让这条指令在独立子会话中执行，不会污染主会话的上下文。

指令五：/review —— 代码审查 + 测试缺口扫描
做什么： 审查未提交的代码变更，找出潜在Bug、缺少的测试、不一致的写法。

什么时候用： 提交PR之前，做最后一轮自检。

怎么配：

description: Review changes and find test gaps

agent: plan

Review all uncommitted changes:
!git diff

Check for:

1. Potential bugs or logic errors
2. Missing tests — which changed functions don't have corresponding tests?
3. Inconsistent coding style
4. High-risk modifications that need extra testing

For each finding, provide:

• File and line number
• The issue
• Suggested fix
• Priority (High/Medium/Low)
  指令六：/qa —— 真实浏览器端到端测试
  做什么： 启动真实浏览器，执行端到端测试。

什么时候用： 需要验证UI交互、页面跳转、用户真实操作流程。

怎么配： 先确保Opencode配置了Playwright的MCP：

description: Run E2E tests with real browser

agent: build

Execute the following E2E test scenarios using Playwright:

1. [Describe your test scenario 1]
2. [Describe your test scenario 2]

For each scenario:

• Navigate to the target URL
• Perform the user actions
• Verify the expected outcome
• Take a screenshot of the result
• Report pass/fail with evidence
  三、真实案例：半小时配置，每天省3小时
  回到开头那个测试负责人的故事。

我帮他配完这6条指令之后，他的日常工作流程变成了这样：

原来（每次代码修改后）：

手动跑测试 → 等2小时
翻日志找失败 → 20分钟
分析失败原因 → 30分钟
手动修测试 → 30分钟
重新跑测试验证 → 2小时——每次迭代至少5小时。
现在：

输入/test → AI自动跑 + 分析 + 建议修复 → 5分钟
输入/fix-tests → AI自动修复失败的测试 → 10分钟
输入/review → AI审查变更 + 找测试缺口 → 3分钟——每次迭代18分钟。
他后来跟我说了一句话："以前一天最多迭代2轮，现在一天能迭代8轮。 "

四、避坑指南
坑一：指令写得太泛
"帮我测试一下"这种指令，AI不知道要测什么、怎么测、测到什么程度算完。

解法：指令要具体。 写清楚"跑什么命令、输出什么格式、重点关注什么"。

坑二：指令和Skill/Agent分不清
Opencode有三种扩展方式：Command（用户主动触发）、Skill（AI自动发现加载）、Agent（独立角色执行）。

简单判断： 你想手动触发就用Command；想让AI自动判断什么时候用就用Skill；想让独立角色干长任务就用Agent。

坑三：shell注入指令写错了
指令里用!命令注入shell输出时，格式是! + 反引号。写成!cmd（没有反引号）在指令模板里不生效。

解法： 用! + + 命令 +。

坑四：一次性配太多指令
一口气配20条指令，自己都记不住每条是干什么的。

解法： 从3条最常用的开始——/test、/coverage、/review——跑通之后再逐步扩展。

坑五：指令的agent类型选错了
Opencode支持build、plan、security-expert等不同Agent类型。跑测试用build，做分析用plan，做安全审查用security-expert。选错了，效果大打折扣。

五、指令、Skill、Agent：一张图看懂怎么选
很多人在Opencode里搞不清什么时候用Command、什么时候用Skill、什么时候用Agent。

维度
Command（指令）
Skill（技能）
Agent（代理）
触发方式
手动输入/指令名
AI自动判断加载
Tab切换或@引用
最佳场景
重复性用户驱动任务
AI应该自己学会的领域知识
需要独立角色的长任务
文件位置 .opencode/commands/.md .opencode/skills//SKILL.md .opencode/agents/*.md
一句话判断
"我每次都要手动做的事"
"我希望AI自动学会的事"
"我希望让专人干的长活"
一个简单规则： Command跑流程，Skill教方法，Agent当角色。

最后
测试工程师做测试流程自动化，过去的路径是这样的：

每次手动敲Prompt → 等AI执行 → 翻结果 → 再敲下一个Prompt → 重复——每天浪费2-3小时在重复输入上。

现在的路径是这样的：

花30分钟配6条指令 → 以后每天输入6个斜杠命令——每天省下3小时。

Opencode从来不是让测试工程师失业的工具——它是让测试工程师从"重复敲命令"的体力劳动中解放出来的加速器。

下次你发现自己在Opencode里反复输入同一段话，停下来，花10分钟把它写成一条指令。

10分钟的投入，换的是未来每一天的3小时。