没有耐心的同学，可以看一句话版：

从tgeek.cn 下载TestCopilot，安装智能体，然后输入需求，Codex就可以实现并行开发。

短话长说版如下：

在研发流程里，测试用例往往已经沉淀在测试管理平台里，但这些用例和开发过程之间经常是割裂的。

测试同学维护用例，开发同学看需求改代码，最后再等测试执行、反馈缺陷。这个链路里有几个典型问题：

• 用例不能直接驱动开发。

• 模块拆分不够细，验证粒度偏大。

• 失败后需要人工判断是提缺陷，还是开发直接修。

• 回归验证依赖手工串联，效率不高。

• 多个模块可以并行开发，但验证流程没有自然并行起来。

tp 技能就是为了解决这个问题。

它是 testcopilot 技能的短别名，用一句很短的提示词，就可以让 Codex 联动 TestCopilot，完成：

一句话使用

最简单的用法是：

$tp 项目：电商平台

如果只想处理某个模块：

$tp 项目：电商平台 模块：订单/创建订单

如果模块能唯一匹配到项目，也可以直接写：

$tp 模块：订单/创建订单

tp 会默认按完整流程执行，不需要每次都写一大段说明。

tp 到底做什么

tp 是 Codex 中面向 TestCopilot 的自动化技能，主要有两条能力线。

第一条是从需求生成测试闭环：

第二条是从已有测试用例驱动开发闭环：

第二条就是现在推荐的日常用法。

为什么要先把用例拉到本地

tp 会把从 TestCopilot 拉取下来的用例保存到当前项目的本地目录：

.testcopilot/cases/projects/<project_id>/manifest.json

.testcopilot/cases/projects/<project_id>/cases/<module_path>/<case_id>.json

.testcopilot/cases/projects/<project_id>/validation-groups.json

这样做有几个好处：

• Codex 可以把测试用例当成开发验收标准。

• 每个模块的正常、边界、异常场景可以组合起来执行。

• 本地有稳定的用例快照，方便追踪本次开发基于哪一批用例。

• 可以把最小模块拆成多个开发泳道，并行处理。

• 执行失败后可以定位到具体用例、模块和场景类型。

什么是“最小模块验证组合”

tp 拉取测试用例后，会按模块路径识别最小模块。

例如：

订单

订单/创建订单

订单/取消订单

订单/售后/退款

这里的最小模块通常是：

订单/创建订单

订单/取消订单

订单/售后/退款

每个最小模块会尽量组成三类场景：

正常场景 normal

边界场景 boundary

异常场景 exception

例如“订单/创建订单”模块，可能会形成这样的组合：

正常场景：用户使用有效商品、地址、优惠券创建订单成功

边界场景：商品库存刚好为 1 时创建订单

异常场景：库存不足、地址缺失、优惠券无效时创建失败

这些组合会写入：

validation-groups.json

后续 Codex 开发和 TestCopilot 验证都会围绕这些组合展开。

Codex 如何并行开发

tp 不只是并行跑测试，它更重要的是让 Codex 按测试用例并行开发。

流程是：

一个最小模块验证组合 = 一个 Codex 开发泳道

例如：

泳道 A：订单/创建订单

泳道 B：订单/取消订单

泳道 C：订单/售后/退款

每个泳道都有自己的验收标准：

正常场景

边界场景

异常场景

Codex 会先根据这些场景理解目标行为，然后进行最小范围开发。

不过，并行开发不是盲目并行。tp 有一个重要规则：

如果多个模块会修改同一批文件、同一个 API、同一个数据库结构、同一个认证流程，就不会强行并行，而是合并或串行处理。

这样可以避免不同开发流互相覆盖代码。

TestCopilot 执行是怎么触发的

tp 会通过 MCP 调用 TestCopilot 的执行能力。

核心链路是：

这里要注意：它不一定会打开 TestCopilot APP 的可视化界面。

更准确地说，它使用的是 TestCopilot APP 安装包里的本地执行运行时，例如 macOS 下可能是：

/Applications/TestCopilot.app/Contents/Resources/PythonEnv/deepseek_chat_package_v2/main.py

所以可以理解为：

不是点开 APP 手工执行

而是复用 TestCopilot APP 的本地执行引擎

如果本机没有安装 TestCopilot APP，或者找不到内置 Python 环境，任务可以创建，但执行会停在等待本地 runner 配置的阶段。

初始化怎么做

第一次使用前，需要配置 TestCopilot MCP。

可以这样说：

$tp 初始化 TestCopilot MCP

如果你有指定服务地址：

$tp 初始化 TestCopilot MCP，服务器是 https://tgeek.cn/prod-api/sse

需要准备：

TestCopilot MCP server URL

个人访问 token

本机 TestCopilot APP 或本地执行环境

默认 MCP 地址是：

https://tgeek.cn/prod-api/sse

token 支持：

Authorization: Bearer <token>

或：

X-AUTH-TOKEN: <token>

安全原则很简单：

不要把 token 写进代码、技能文件、文档或最终回复里。

常用提示词

项目级完整闭环：

$tp 项目：电商平台

模块级完整闭环：

$tp 项目：电商平台 模块：订单/创建订单

只拉取并保存用例：

$tp 项目：电商平台，只拉取测试用例并保存本地，先不要执行

只处理某个模块：

$tp 模块：登录/密码登录

从需求生成用例并执行：

$tp 根据这个需求生成测试用例，保存到 TestCopilot，并触发 AI 执行

只执行第一个测试用例：

$tp 只执行第一个测试用例

查询执行日志：

$tp 查询执行日志 task_id：xxx

查询执行结果：

$tp 查询执行结果 task_id：xxx

配置本地执行环境：

$tp 配置执行环境。我的 Windows 安装目录是 C:\Users\me\AppData\Local\Programs\TestCopilot

日志和结果怎么查

执行开始后，tp 会自动调用：

get_execution_logs

get_execution_result

概念上等价于：

get_execution_logs(task_id, cursor)

get_execution_result(task_id)

第一次查日志：

get_execution_logs(task_id="xxx", cursor="")

如果返回了 next_cursor，下一次继续：

get_execution_logs(task_id="xxx", cursor="返回的_next_cursor")

结果查询：

get_execution_result(task_id="xxx")

正常情况下你不用手动调用，tp 会自动轮询，直到任务完成、失败、阻塞或超时。

缺陷怎么处理

执行失败后，tp 不会一律提缺陷，也不会一律改代码，而是按严重程度分流。

适合上传缺陷管理的情况：适合 Codex 直接修复的情况：

如果当前 MCP 没有提供缺陷上传工具，tp 不会编造接口，而是输出结构化缺陷包：

本地脚本能做什么

tp 内置了两个轻量脚本。

第一个用于保存用例：

node /Users/i/.codex/skills/testcopilot/scripts/save-cases-local.js /tmp/testcopilot-cases-input.json --workspace <repo_path>

它会生成：

manifest.json

每条测试用例 JSON

模块目录结构

第二个用于生成验证组合：

node /Users/i/.codex/skills/testcopilot/scripts/build-validation-groups.js <manifest.json>

如果只处理某个模块：

node /Users/i/.codex/skills/testcopilot/scripts/build-validation-groups.js <manifest.json> --module 
"订单/创建订单"

不过日常使用时，不需要手动跑这些脚本。直接用 $tp 项目：xxx 或 $tp 项目：xxx 模块：xxx 就可以。

适合哪些场景

tp 特别适合这些研发场景：

• 已有 TestCopilot 测试用例

• 希望直接驱动开发

• 一个项目下有多个模块，可以并行开发和验证

• 希望把正常、边界、异常场景一起作为验收标准

• 希望失败后自动判断提缺陷还是直接修复

• 希望将 TestCopilot 执行结果和 Codex 修复能- 力串起来

• 希望减少“开发完成后再等测试反馈”的等待时间

不适合的场景：

• 没有测试用例，也没有需求输入

• 项目或模块名称无法匹配

• 本地没有 TestCopilot 执行环境，且又要求立即执行

• 多个模块强依赖同一批代码，却要求强行并行开发

推荐工作方式

最推荐的工作方式是：

先按项目跑一遍

再按模块收敛

最后对失败模块做修复和回归

例如：

$tp 项目：电商平台

先让 tp 拉取整个项目的用例，生成本地缓存和验证组合。

然后针对重点模块：

$tp 项目：电商平台 模块：订单/创建订单

进行模块级并行开发和验证。

如果失败，再让 Codex 根据缺陷等级处理：

$tp 继续处理失败用例，严重问题上传缺陷，低风险问题直接修复并回归

最终效果

tp 把测试用例从“验证材料”变成了“开发驱动”。

过去的流程可能是：

现在可以变成：

一句话总结：

tp 让 TestCopilot 里的测试资产真正进入开发循环，让 Codex 按用例开发、按模块并行、按结果修复，最终形成从测试用例到代码交付的闭环。