你不需要在每个环节重复"教"AI怎么做，把整条测试流水线写成指令，一次配置，终身复用
大家好，我是某互联网公司的测试架构师。
上个月，团队接了一个新项目——一个微服务系统，需求文档将近100页，涉及6个模块、3种数据源、一套复杂的缓存策略。
测试负责人找到我："按以前的流程，我得先花3天啃需求文档、2天写测试计划、1天整理测试用例、再花1天跑测试出报告——前后差不多一周。但这次上线时间只剩4天了。"
我说："你用Opencode吗？"
他说："用啊，但每次都是人工一步步指挥——'帮我看这个需求''帮我写个测试计划''帮我跑测试''帮我出个报告'——每做一个环节就要重新描述一遍。"
我打开他的项目目录，说了一句："你缺的不是AI能力，你缺的是一条从需求到报告的测试流水线。 "
我花了一小时帮他配了5条指令。从那以后，从需求文档到测试报告，全程不到2小时。
一、传统测试流程为什么这么慢？
先说说大多数测试团队的真实状态。
拿到一个需求文档之后，测试流程大概是这样的：
阶段一：需求理解（1-3天）打开PRD，一页页看，边看边记，梳理功能点、业务规则、数据流转。100页的文档看完，脑子是懵的——"到底有哪些功能要测？哪些是核心？哪些容易出问题？"
阶段二：测试计划（1-2天）基于需求理解，写测试计划——测试范围、测试策略、资源安排、时间计划、风险分析。写得多了自己都烦——每个项目都差不多，但每次都要重新写。
阶段三：用例设计（1-3天）把需求拆成测试点，再把测试点写成用例。几百条用例，逐条写前置条件、操作步骤、预期结果——重复劳动占了大半。
阶段四：测试执行与报告（1-2天）跑测试、记结果、分析失败、写报告——又是重复劳动。
整个流程走下来，少则3天，多则一周。 而且每个环节都在做重复的事——写相似的文档、填相似的表格、敲相似的命令。
Opencode的流水线思路就是：把每个环节的标准操作流程，封装成一条指令。以后只需要输入/指令名，AI自动完成该环节的全部工作。
二、核心思路：把测试流水线拆成5个环节，每个环节一条指令
我把测试流程拆成了5个核心环节，每个环节对应一条Opencode指令：
环节
指令
做什么
需求解析
/spec
读PRD，提取功能点、业务规则、数据流转
测试计划
/plan
基于需求生成测试计划（范围、策略、排期、风险）
用例生成
/testgen
基于测试计划生成结构化测试用例
测试执行
/test
跑测试、分析失败、自动修复
报告生成
/report
汇总测试结果，生成结构化报告
一条指令对应一个环节，一个环节完成一件事。 每个环节的输出自动成为下一个环节的输入，环环相扣。
三、5条指令完整配置（附可直接复制的代码）
下面是我在实际项目中用的5条指令，你可以直接复制使用。
指令一：/spec —— 需求解析
做什么： 读取PRD文档，提取功能点、业务规则、数据流转、依赖关系。
文件位置：.opencode/commands/spec.md
description: Parse PRD and extract test-relevant information
agent: plan
Read the PRD document from the following location:
[粘贴PRD文件路径，或直接粘贴PRD内容]
Extract the following information in a structured format:
- 功能列表：列出所有需要测试的功能模块，每个模块用一句话说明核心功能
- 业务规则：列出所有业务规则（计算公式、状态流转、权限控制、限制条件）
- 数据流转：描述数据在系统各模块之间的流转路径
- 外部依赖：列出所有外部系统/接口依赖
- 风险预判：基于经验判断哪些功能最容易出问题，标注风险等级（高/中/低）
输出格式：Markdown表格 + 分级标题，便于后续环节直接引用。
使用方式：/spec
真实效果： 一份100页的PRD，人工啃完要2-3天。AI跑完这条指令后，10-15分钟输出一份结构化的需求摘要——功能列表清晰、业务规则完整、风险预判准确。测试负责人看完说了一句："比我啃两天总结得还全。 "
指令二：/plan —— 测试计划生成
做什么： 基于需求解析结果，自动生成测试计划。
文件位置：.opencode/commands/plan.md
description: Generate test plan from spec
agent: plan
subtask: true
Based on the spec output from /spec, generate a comprehensive test plan.
The plan must include:
- 测试范围：明确本次测试覆盖的功能模块和不覆盖的范围
- 测试策略：
- 单元测试策略（哪些模块需要、覆盖率目标）
- 集成测试策略（接口测试范围、端到端测试场景）
- 回归测试策略（核心功能回归范围）
- 测试环境：需要哪些环境、数据准备方案
- 资源与排期：人力安排、时间节点、里程碑
- 风险与应对：识别风险点、给出应对措施和备选方案
Output: A structured test plan document in Markdown format, ready to be saved as test-plan.md.
关键配置：subtask: true让这条指令在独立子会话中执行，不会污染主会话上下文。
使用方式：/plan
指令三：/testgen —— 测试用例生成
做什么： 基于测试计划，自动生成结构化的测试用例。
文件位置：.opencode/commands/testgen.md
description: Generate test cases from test plan
agent: build
Based on the test plan from /plan, generate structured test cases.
For each feature/module, generate test cases covering:
- 正常流程（Happy Path）：核心功能的正常操作路径
- 边界场景：参数边界值、状态边界、时间边界
- 异常场景：参数异常、依赖异常、并发异常、权限异常
- 逆向流程：取消、回退、拒绝等反向操作
Each test case must include:
- 用例编号（格式：
{模块缩写}-{类型缩写}-{序号}） - 测试场景描述
- 前置条件
- 测试步骤（编号列表）
- 预期结果
- 优先级（P0/P1/P2）
Output: A structured test case document in Markdown table format, ready to be saved as test-cases.md.
使用方式：/testgen
真实效果： 有一次用这条指令给一个订单模块生成用例，AI一口气生成了80多条用例——覆盖了正常下单、优惠券叠加、库存不足、支付超时、部分退款、订单取消等场景。测试同学只需要审核补充，原来2-3天的用例编写工作，压缩到了2小时。
指令四：/test —— 测试执行 + 自动修复
做什么： 运行测试套件，分析失败，自动修复失败的测试。
文件位置：.opencode/commands/test.md
description: Run tests, triage failures, auto-fix
agent: build
Run the full test suite with coverage report:
!npm test -- --coverage --reporter=verbose
Then:
- 分析失败：对于每个失败的测试，判断是代码Bug还是测试Bug
- 如果是测试Bug：直接修复测试代码
- 如果是代码Bug：分析根因，给出修复建议（不直接改生产代码）
- 覆盖率分析：列出覆盖率低于80%的文件，建议需要补充测试的位置
For each failure, output:
- 测试名称和失败位置
- 失败原因分类（代码Bug / 测试Bug / 环境问题）
- 修复建议或已修复的代码
Final output: A test execution summary with pass/fail count, coverage percentage, and remaining issues.
这是最常用的一条指令。! + 反引号会把shell命令的输出直接注入Prompt。
使用方式：/test
指令五：/report —— 测试报告生成
做什么： 汇总所有测试结果，生成结构化的测试报告。
文件位置：.opencode/commands/report.md
description: Generate test report from all test results
agent: plan
Generate a comprehensive test report based on all test execution results.
The report must include:
执行概览：
- 总用例数 / 通过数 / 失败数 / 阻塞数
- 通过率
- 代码覆盖率（行覆盖率、分支覆盖率）
失败分析：
- 失败用例列表（用例编号、失败原因、严重程度）
- 失败分类统计（代码Bug / 测试Bug / 环境问题）
- 未修复的严重问题清单
质量评估：
- 各模块质量评分（基于通过率和缺陷密度）
- 高风险模块标注
- 与上一版本的质量对比（如有历史数据）
结论与建议：
- 是否达到发布标准
- 发布前必须修复的问题清单
- 建议的后续测试计划
Output: A structured test report in Markdown format, ready to be shared with the team.
使用方式：/report
真实效果： 有一次项目上线前，测试负责人用这条指令生成了报告，发现支付模块的通过率只有67%。报告里清晰标出了3个P0级问题——"如果按这个报告上线，支付模块必炸"。开发团队连夜修复，避免了线上事故。
四、完整流水线：一条指令接一条指令
配置好5条指令之后，整个测试流程变成了这样：
第1步：/spec
→ 上传PRD，AI 15分钟输出需求摘要
第2步：/plan
→ 基于需求摘要，AI 10分钟生成测试计划
第3步：/testgen
→ 基于测试计划，AI 15分钟生成测试用例
第4步：/test
→ 跑测试 + 自动分析 + 自动修复，全程自动化
第5步：/report
→ 汇总结果，AI 5分钟生成测试报告
从需求文档到测试报告，全程不到2小时。
测试负责人后来跟我说了一句话："以前一个项目从开始到出报告，我要在各个文档之间来回切，累死累活一周。现在输入5条指令，2小时出全部产物，我只负责审核。 "
五、避坑指南
坑一：指令之间没有"传递"机制
每条指令都是独立执行的，/plan不知道/spec输出了什么，除非你手动把内容传过去。
解法： 在每条指令里明确写"基于上一步的输出"。或者在执行时手动复制上一步的结果粘贴到当前指令的Prompt里。
坑二：把"生成"当成"最终答案"
AI生成的测试计划、用例、报告都是初稿，不是最终答案。必须经过人工审核才能使用。
解法： 每条指令的输出都标记为"Draft"，强制人工审核环节。我们的流程是AI出初稿→测试负责人审核修改→定稿。
坑三：指令的agent类型选错了
Opencode支持build、plan等不同Agent类型。跑测试用build，做分析和报告用plan。选错了，效果大打折扣——plan agent是只读的，如果用它来执行测试会失败。
解法： 执行类任务（跑测试、修代码）用build，分析类任务（读文档、出报告）用plan。
坑四：一次配太多指令，记不住
一口气配10条指令，自己都分不清每条是干什么的。
解法： 从3条核心的开始——/spec、/test、/report——跑通之后再逐步扩展。指令命名用动词+名词，一看就知道用途。
坑五：shell注入指令写错了格式
指令里用!命令注入shell输出时，格式是! + 反引号 + 命令 + 反引号。写成!cmd（没有反引号）在指令模板里不生效。
解法： 用!npm test `这种格式。
坑六：忽略了"人"在流水线里的位置
流水线再自动化，"人"仍然是决策者。AI生成的测试计划需要你确认方向对不对，AI生成的用例需要你审核全不全，AI生成的报告需要你判断能不能发布。
解法： 在每条指令的输出里加上"审核清单"——告诉测试负责人"你需要检查这几点"。把AI定位成"高效助手"，而不是"替代者"。
六、流水线搭建清单
如果你也想搭这条流水线，按这个顺序来：
第一步：创建目录
mkdir -p .opencode/commands
第二步：创建5个指令文件
touch .opencode/commands/spec.md
touch .opencode/commands/plan.md
touch .opencode/commands/testgen.md
touch .opencode/commands/test.md
touch .opencode/commands/report.md
第三步：把上面的配置内容分别粘贴进去
第四步：跑通第一条指令
opencode
/spec
第五步：逐步添加其余指令，每加一条跑通一条
最后
测试工程师做测试流程，过去的路径是这样的：
啃PRD → 写计划 → 写用例 → 跑测试 → 写报告——每个环节手动操作，一个项目至少3-7天。
现在的路径是这样的：
/spec → /plan → /testgen → /test → /report——2小时出全部产物，人只负责审核和决策。
Opencode从来不是让测试工程师失业的工具——它是让测试工程师从"重复写文档"的体力劳动中解放出来的加速器。
流水线的本质，不是"让AI替你干活"，而是"把你的经验变成可复用的流程"。
你写过的每一份测试计划、每一条测试用例、每一份测试报告——里面都藏着你的经验。把这些经验拆成标准操作流程，封装成指令，以后每次做类似的项目，直接跑指令就行了。
下次你拿到一份新项目的PRD，别从头开始啃了。搭好这条流水线，输入5条指令。
2小时后，你会看到从需求到报告的全部产物。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
