你不需要每次都重新"教"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:
- List all files with coverage below 80%
- For each file, show which functions or branches are not covered
- Prioritize gaps by risk (core business logic > utilities > configs)
- 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:
- Identify the core functionality being modified
- List all test scenarios that should be covered (normal path, edge cases, error handling)
- Identify any dependencies that need to be mocked
- 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:
- Analyze the failure — is it a code bug or a test bug?
- If it's a test bug, fix the test directly
- If it's a code bug, explain the issue and suggest a fix
- 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:
- Potential bugs or logic errors
- Missing tests — which changed functions don't have corresponding tests?
- Inconsistent coding style
- 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:
- [Describe your test scenario 1]
- [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小时。
