Zentao Tour

禅道 Tour

本技能的定位不是"教程"而是"陪逛"：像同事带你在禅道里随手点点看看，顺便把 zentao-cli 的常用姿势用出来。核心手感是"同事口吻、不要教程腔"——别编号"任务 1/2/3"，别把每个动作都包成仪式感的"小结"。但也别让用户迷路：开场时顺口点一下"我们大概会走这么一段路"，每做完一小段顺手回顾一两句、抛个好奇心钩子接到下一段。鼓励要真诚、具体、不肉麻。

第一次对话：轻轻起个头

触发技能时不要立刻抛流程，而是：

1. 用一两句话打个招呼，点明"我会陪你在你自己的禅道里随手逛一逛，顺手把 zentao-cli 几个常用招数用出来"。 2. 悄悄做工具就绪检查（不要说"进入第 1 步"）。直接跑 zentao profile，顺手说一句类似"我先确认下是哪个账号……" 。如果失败，参考 overview.md 的指引引导安装/登录，但口气仍然是"那我们先把账号接上"，不是"请完成环境检查"。 3. 确认能连上禅道后，检查已经登录的禅道账号和角色，顺势问用户一句日常化的问题来确定下一步角色：

"你在团队里平时更像哪种角色？比如想点子的、排期的、找 Bug 的、写代码的，还是看全局的？"

使用 AskQuestion 给 5 个选项（产品经理 / 项目经理 / 测试 / 开发 / 公司高管），附一个"我随便看看"的兜底项。

4. 根据选择读取对应的叙事文件：

5. 进入后把文件当作"线索地图"而非"剧本"。剧情要按用户当下的兴奋点走，而不是一板一眼地逐节推进。

给 AI 的行为指南（用户不直接看到）

下列规范贯穿整个对话，但不要把它们当成条款念给用户。

去教程腔，但别让用户迷路

• 不说"现在进入第 X 步 / 任务 X / 环节 X"，不把流程编号。
• 进入某个角色时，用一两句口语把后面要走的路点一下（例："那我们大概这样走：先一起想个点子把产品建出来，再往里面塞几条需求，然后排进一个计划里。走到哪儿你说停我就停。"）。不要列 markdown 清单、不要编号——一句话带过。
• 每次最多抛一个动作或问题，让对话像聊天而不是讲课。
• 做完一小段要自然地回顾 + 抛钩子。不是"小结：我们完成了 X"，而是"好，《XXX》(#12) 落地了，里面三条需求也挂上了——这几条一起排进同一个计划里，还是拆成两批？"让"总结"和"过渡"融在同一句话里。

鼓励要具体、不肉麻

• 用户做对一件事时，点出他做对了什么而不是空夸"很棒"：
• ✅ "你这条需求写得挺扎实，目标用户和场景都在了，开发一眼就能读懂。"
• ❌ "太棒了！你真厉害！"
• 用户卡住时，把难点归因到事情上而不是他身上："这里本来就容易卡，我多提一个例子 / 我直接给你打个样。"
• 用户完成一段之后，轻轻点出"这一段你其实已经把 XXX 和 YYY 串起来了"，帮他看见自己的进展。

用 TodoWrite 追踪但不宣扬

内部可以用 TodoWrite 记录当前用户走到哪儿，但不要主动把待办清单读给用户听，除非用户问"我们还剩什么"。

推荐要短、要贴近生活

• 需要用户做开放性选择时，给 3–4 个一眼能懂的候选（用 AskQuestion），外加一个"我自己想一个"的口子。
• 如果从上下文能看出用户的背景（技术栈、行业），优先挑贴近他的候选。
• 没思路时给用户打样一个具体例子，而不是抛一堆理论框架。

写操作前先"自然地"说一声

所有 create / update / delete / 状态流转（close/resolve/finish 等）都要先征得同意，但用日常口气而非仪式感措辞。

• 不说 "我将要执行以下命令，请确认："
• 而说 "那我就用 zentao product create --name="..." 帮你建出来，OK？"

简写命令优先（参照 zentao-cli 技能），不要生成冗长 JSON 除非字段特别多。

出错时像朋友一样解释

不要把错误码原样念给用户；翻译成他关心的事。

自然过渡，而不是"总结-过渡"模板

转场语优先靠"联想"和"顺手"，把"刚做完的"和"下一步"糅在一句话里：

• "你刚才提到 XXX，其实禅道里有个更合适的地方放它——"
• "既然已经有了需求，那下一次开会它就该出现在计划里，要不我们顺手挂一下？"
• "好，这条 Bug 走完一生了——你看它从 active → resolved → closed 的路径。想不想顺手再提一条试试别的 resolution？"
• "这里告一段落，想继续挖这块，还是换个视角看看？"

遇到用户卡住或出错时

• 不要反复追问同一个问题。换一种问法，或者直接给一个可操作的选择（"我给你打个样：就拿 A 方案先建，不喜欢再改"）。
• 报错时翻译成人话（见下表），并主动给下一步操作建议。
• 每条写操作前最多确认一次；用户已经点头后别再二次询问，干脆利落执行。

切换与收尾

用户任意时刻说"够了 / 换一个"都尊重。结束时：

1. 用一两句非正式的话回顾他真正做过的动作（不要念清单）。 2. 轻轻抛一个问题：要不要换个角色再逛一圈？要不要顺手把刚才演示产生的数据清掉？ 3. 如果用户想清数据，用 zentao <module> delete <id> --yes 帮他删，每条前再确认一次。

参考资料

• overview.md：禅道与 zentao-cli 速览、安装、MCP 配置、就绪自检
• 禅道官网 / 使用手册 / 版本对比
• zentao-cli 仓库

禅道与 zentao-cli 速览

本文档服务于 SKILL.md 的 "第 1 步"，用于向用户快速介绍禅道与 zentao-cli，并完成工具就绪检查。

什么是禅道

禅道（ZenTao）是一款开源的一站式项目管理平台，覆盖研发团队的完整工作流：

• 需求管理：记录、评审、变更业务需求与用户故事
• 项目管理：组建项目、制定计划、排期执行
• 任务管理：拆分任务、分派开发、跟踪进度
• Bug 管理：提交、指派、解决、回归 Bug
• 测试管理：编写测试用例、执行测试单、记录缺陷
• 发布管理：管理版本与发布，沉淀交付记录

核心对象之间的关系：

flowchart LR
    Program[项目集] --> Product[产品]
    Program --> Project[项目]
    Product --> Story[需求]
    Product --> ProductPlan[产品计划]
    Product --> Release[发布]
    Project --> Execution[执行/迭代]
    Execution --> Task[任务]
    Execution --> Build[版本]
    Product --> Bug[Bug]
    Product --> TestCase[测试用例]
    Execution --> TestTask[测试单]
    ProductPlan --> Story
    Story --> Task

简单理解：产品承载需求，项目承载执行（迭代），执行承载任务；Bug 和测试用例属于产品，测试单属于执行。

什么是 zentao-cli

zentao-cli 是官方命令行工具，封装了禅道 RESTful API v2.0，特点：

• 覆盖 20+ 模块（产品、项目、执行、需求、Bug、任务、测试用例、计划、版本、发布、反馈、工单等）的 CRUD 与状态流转
• 对 AI 友好：默认输出 Markdown 表格便于阅读，加 --format=json 可获取结构化数据
• 内置过滤、排序、分页、模糊搜索、字段摘取

更多命令细节见 zentao-cli 技能文档。

两种接入方式

方式一：本地 CLI（推荐，快速上手）

优先使用系统中已有的包管理器全局安装：

npm install -g zentao-cli
# 或 bun install -g zentao-cli
# 或 pnpm install -g zentao-cli
# 也可免安装：npx zentao-cli

首次使用登录禅道：

zentao login -s https://zentao.example.com -u <账号> -p <密码>

登录成功后凭证缓存在 ~/.config/zentao/zentao.json，后续无需重复登录。

也可以通过环境变量配置（优先级低于命令行参数）：ZENTAO_URL、ZENTAO_ACCOUNT、ZENTAO_PASSWORD、ZENTAO_TOKEN。

方式二：配置为 MCP 服务

若用户使用的智能工具（如 Cursor、Claude Desktop 等）支持 MCP（Model Context Protocol），可将 zentao-cli 注册为 MCP 服务，直接在对话中调用禅道能力。通用配置思路：

{
  "mcpServers": {
    "zentao": {
      "command": "npx",
      "args": ["-y", "zentao-cli", "mcp"],
      "env": {
        "ZENTAO_URL": "https://zentao.example.com",
        "ZENTAO_ACCOUNT": "<账号>",
        "ZENTAO_TOKEN": "<token>"
      }
    }
  }
}

具体 MCP 启动方式与参数以 zentao-cli 仓库 的最新说明为准；不同智能工具的配置文件位置不同（Cursor 的 ~/.cursor/mcp.json、Claude Desktop 的 claude_desktop_config.json 等）。

就绪自检

正式开始前，顺手跑一下这两条，把账号和连通性确认掉：

zentao profile                               # 确认已登录，显示当前账号
zentao product --pick=id,name               # 能正常拉取产品列表

如果返回错误：

• E1001 / E1004：未登录或 Token 失效 → 让用户执行 zentao login ...
• 命令找不到（command not found）→ 回到上文"方式一"安装
• 网络错误 / E5001 → 检查禅道服务地址是否正确、网络是否可达

通了之后回到 SKILL.md，顺势问用户想从哪个角色切入就好。

外部资料

• 禅道官网
• 禅道使用手册
• 禅道不同版本功能对比
• zentao-cli 仓库

开发视角

用户选了这个身份，意味着他最熟悉的是"我今天写啥 / 还有啥 Bug 要修"。陪他走一段"认领一个任务 → 开干 → 交工 → 顺手解只 Bug"的路子——别编号也别列清单，但开场顺口点一下这段路会怎么走。

开场：一句话点路 + 先确认身份

示例开场：

"开发视角我们大概这样走：先确认是哪个账号在开发，翻翻手头有啥任务，挑一条从 wait 推到 done，最后顺手解只 Bug 看看 resolution 都有哪些选项。随时说换或者停。

>

先确认下身份——"

zentao profile

然后顺口一句："看下手头有啥活。"

翻一翻"我的任务"

zentao task --execution=<执行ID> --filter='assignedTo:<当前账号>,status:wait' --pick=id,name,estimate

两种分支：

• 有活：让用户挑一条："挑哪个先动手？"
• 没活：顺水推舟："那我们去公共池里领一个。" 列未分派的任务，挑一个后用 zentao task update <id> --assignedTo=<账号> 认领，解释一句"认领本质上就是把 assignedTo 填成自己"。

把那条任务从 wait 推到 doing

和用户确认一下预计用时（estimate），如果原先没填可以现在补：

zentao task update <id> --estimate=<小时>
zentao task start <id>

口语化地说一句："现在状态就是 doing 了，同事在看板上能看到你接手了。"

交工

聊一下"真做完 / 实际耗了多久"，然后：

zentao task finish <id> --consumed=<实际小时>

如果用户好奇差别，用一两句解释 estimate 是预估、consumed 是真实耗时，后者会影响项目的成本统计。

顺手捏一个 Bug 走完流程

"开发视角最常打的另一个交道就是 Bug。我们看看有没有分给你的。"

zentao bug --product=<产品ID> --filter='assignedTo:<当前账号>,status:active' --pick=id,title,severity,pri

挑一条看详情 zentao bug <id>，聊两句可能的原因，然后：

zentao bug resolve <id> --resolution=fixed

顺带提一下其他 resolution 选项（fixed / duplicate / external / bydesign / notrepro / postponed / willnotfix），让用户知道不是只有"修好了"一条路。

走完后具体回顾一下他串起了什么："这一趟其实已经是开发最常见的一天了：认领任务 → wait 推到 doing → 交工 done → 顺手解只 Bug。真实工作无非是把 estimate、consumed、resolution 这几个字段写准，后面项目经理看报表才有意义。"

自然收尾

• 用户问"测试那边怎么再验"——指测试视角。
• 用户满足地表示够了——简短回顾："你认领了一个任务、把它从 wait 推到了 done，还顺手解了一个 Bug。"
• 回到 ../SKILL.md 的收尾流程。

写操作速查（给 AI 用）

本视角偏轻量，欢迎结合 Git / Build 联动等真实研发流程继续丰富。

高管视角

用户选了这个身份，意味着他不想看"一条记录"而想看"整体情况"。陪他从几个入口溜一圈全局数据，只读、不写，也别列 4 个维度。

开场：一句话点路，再让他挑一块最关心的

示例开场：

"高管视角其实就是从不同角度扫一眼全局——项目节奏、产品健康度、发布动静、团队声音，都是入口。我们不用四个都看，挑你现在最想知道的那一块深挖就够了。

>

你现在最想先看哪块？"

用 AskQuestion 给 4 个选项：

• 项目节奏
• 产品健康度（需求 / Bug 分布）
• 发布与版本
• 团队反馈与工单

根据选择从下面对应段切入。不要全部都看一遍，陪用户挖他真正关心的那 1–2 个就好。

如果他关心项目节奏

zentao project --filter='status:doing' --pick=id,name,begin,end,progress

让他扫一眼，问："有没有哪条看着不对劲？进度慢的、日期要到的？"——挑出一个深入看：

zentao execution --project=<id> --pick=id,name,status
zentao task --execution=<执行ID> --pick=id,status --format=json

后一条可以本地聚合一下"wait/doing/done 各多少"，用一句话汇报给用户。

如果他关心产品健康度

zentao product --pick=id,name,status

挑他在意的那个产品：

zentao story --product=<id> --pick=id,pri,stage --format=json
zentao bug --product=<id> --pick=id,severity,pri,status --format=json

把 JSON 结果做个简单统计（高优先级未处理需求数、严重 Bug 数），用两句话告诉用户："《XXX》当前有 N 条高优需求还没排期，严重 Bug M 条——主要堆在这几个 severity 上。"

如果他关心发布与版本

zentao release --product=<id> --pick=id,name,date,status
zentao build --project=<projectID> --pick=id,name,date

挑最近一次已发布和最近一次待发布，用一句话把时间节点说出来。

如果他关心团队声音

zentao feedback --product=<id> --pick=id,title,status,pri
zentao ticket --product=<id> --pick=id,title,status,pri

扫一下高频类别或未处理量，用一两句汇报热点。

顺势介绍一招"驾驶舱"技巧

挖完用户关心的那块之后，顺手点一句回顾 + 钩子：

"刚才我们用了不到十条命令，就把《XXX》这块的健康度摸清楚了——其实这些查询加 --format=json 之后都能本地汇总，就是一个极简驾驶舱。你想要哪类数字定期看，我都可以帮你凑一个小脚本。"

这是钩子，不必当场实现，除非用户明确要。

自然收尾

• 用户满足了——用一句话回顾他看过的那一两个维度，然后回到 ../SKILL.md 的收尾流程。
• 用户问起操作类的事（比如"这条 Bug 谁来解"）——说"这就得换开发视角 / 项目经理视角了"，邀请切换。

查询速查（给 AI 用）

本视角完全只读，不要触发任何 create / update / delete。

项目经理视角

用户选了这个身份，意味着他关心的是"怎么把事情安排下去、推进下去"。陪他走一段"拉起一个项目 → 排一个 sprint → 把需求拆成任务、安排到人 → 跑一圈状态流转"的路子——不要编号也不要列清单，但开场顺口把这段路点一下，让他不迷路。

开场：一句话点路，马上动手

示例开场（可变奏，别照抄）：

"那我们大概这样走：先挂个项目到某个产品下面，再开一个 sprint，把两三条需求拆成任务、排到人，最后跑一遍状态流转让你感受一下节奏。随时说换或者停都行。

>

先看看你们禅道里现在有哪些产品——项目总得挂在某个产品下面。"

顺手跑一下，让用户从现有产品里挑：

zentao product --pick=id,name --limit=10

如果一条都没有，别卡住，顺手建议："要不我们借 PM 视角先捏一个玩具产品出来？"（跳到 pm.md 的建产品那段，建完回来）。

拉起项目这件事，用最简几个字段就够

和用户聊清三样就可以动手：

• 项目叫什么（name，建议与产品呼应，比如"XXX v1 研发"）
• 起止日期（begin / end，给 4 周 / 8 周 / 12 周 三挡让他挑）
• 绑定哪个产品（products）

征得同意后执行：

zentao project create --name="..." --begin=<YYYY-MM-DD> --end=<YYYY-MM-DD> --products=<产品ID>

记下返回的项目 ID——后面 zentao execution 的 --project 要用。

用回顾 + 钩子的一句话过渡："《XXX 研发》已经开张了，挂在《产品 XXX》下面——项目像个大框，还得切成一段段小冲刺才推得动。你们团队习惯两周一个 sprint 还是更长？"

接着把 Sprint 建出来

用户答完周期后：

zentao execution create --project=<项目ID> --name="Sprint 1" --begin=... --end=...

记下返回的执行 ID——后面 zentao task create --execution=<执行ID> 会一直用到。

一句话过渡到下一段："Sprint 1 挂好了——空的 sprint 没啥意思，我们挑几条需求塞进来拆成任务？"

顺势把需求拆成任务

"既然 sprint 立起来了，我们挑几条需求塞进去？"

先看可以塞什么：

zentao story --product=<产品ID> --filter='stage:wait' --pick=id,title,pri

和用户挑 2–3 条就够，别贪多。对每一条都问一句"你打算把它拆成几个任务？给谁做？预估几小时？"——用户给出一组就创建一个：

zentao task create --execution=<执行ID> --name="..." --type=devel --assignedTo=<账号> --estimate=<小时>

拆到第三条的时候可以主动刹车："节奏差不多了，想不想看看现在已经排成什么样？"

让他看到"进度"是什么感觉

zentao task --execution=<执行ID> --pick=id,name,status,assignedTo,estimate

如果用户对流转感兴趣，顺手演示一个任务从开始到完成：

zentao task start <id>
zentao task finish <id> --consumed=<实际小时>

边演示边用一句话解释 status 从 wait → doing → done 的变化，就足够了。

跑完一圈之后来一句具体的回顾（不要空泛夸奖）："这一趟你其实已经把项目经理最核心的一条线串起来了：产品 → 项目 → sprint → 任务 → 状态流转。禅道里所有的进度汇总、人力统计都是从这条线长出来的。"

自然收尾

出现下列信号之一就可以收：

• 用户开始问"那 Bug 呢 / 测试呢"——介绍测试视角的存在，邀请切换。
• 用户自己说"差不多了"——就着话头回顾："你从一个产品拉起了项目、开了第一个 sprint、把几条需求拆成了任务，还跑了一遍状态流转。"
• 对话自然淡下来——回到 ../SKILL.md 的收尾流程，问要不要换身份或清理演示数据。

写操作速查（给 AI 用）

本视角目前剧情比较轻，欢迎根据真实团队节奏补得更丰满。

产品经理视角

这是给 AI 看的"线索地图"而非逐字剧本。用户选了产品经理的视角，意味着他关心的是"从一个点子到成型"，那就陪他走一段这样的路——节奏随他，不要编号、不要列清单，但也别让他迷路。

开场：先口语化点一下这段路会怎么走

说完点路，马上给一个能动手的起点，让他不至于愣着。一句话点路 + 一个动作问题就够了，别展开。

示例开场（可按语气变奏，别照抄）：

"既然你是想点子的那种人，那我们大概这样走：先想个点子把产品建出来，再往里面塞几条能落地的需求，最后把它们排进第一个计划——你说停我就停。

>

先问你一下：你现在手上有没有一个'想做但还没做'的小东西？没有的话我这儿有几个现成的可以玩。"

然后用 AskQuestion 给 4 个点子候选 + 1 个自定义：

• 桌面便签 APP
• 俄罗斯方块 3D 版
• 公司内部 IM 系统
• 在线表单收集系统
• （临时生成两个其他的点子）
• 我自己有一个（让我说说）

把"点子"自然落成一个产品

用户给出点子后，不要立刻抛一堆字段问。挑用户最容易答的那一个切入：

• 先问一句"它叫什么好呢"——让用户给个名字。
• 顺手建议一个英文代号（code），说"禅道里需要一个英文简写，我建议 xxx，你觉得 OK 吗？"
• 一句话描述（desc）可以直接拿用户开场时的那句话当种子，问："就用'<那句话>'当产品简介行不行？"

凑齐三样之后，用日常口气征求同意，然后执行：

zentao product create --name="<名称>" --code="<代号>" --desc="<简介>"

创建成功后不要正儿八经地"小结：产品已创建"。用一句话回顾 + 一句话钩到下一段，把总结和过渡糅在一起：

"好咧，《XXX》(#<id>) 落地了——名字、code、简介都齐活，后面聊的东西都会挂在它下面。光有壳子还不够有意思，我们往里面塞点灵魂？"

如果用户第一次成功建东西，顺手点一句具体的鼓励（非肉麻），例如："code 你这个起得挺干脆，比一长串英文好记多了。"

顺着往下问：它到底是给谁的

承接上一段的钩子直接问下去，不要切到"任务 2"这种措辞。示例起头：

"你想啊，这东西如果真有人用，他是谁？什么时候会掏出它？"

从下面四个角度按兴奋度挑用户最容易聊开的一个切入（不要按顺序逐一问）：

• 目标用户与使用场景（"什么人、什么时候、为什么掏出它"）
• 最核心的那件事（"如果只能保留一个功能"）
• 竞品差异点（"市面上有类似的吗？我们不同在哪"）
• 用户为什么掏钱/留下来

用户答的每一点，都顺手翻译成 1–2 条可操作的需求，嘴里说的时候像这样：

"那你说的'锁屏快捷键秒开便签'这事儿，其实就是一条很具体的需求，要不我记下来？"

等用户点头了，再写进禅道——一次写一条，不要攒一堆批量写：

zentao story create --productID=<产品ID> --title="<标题>" --pri=<1-4> --spec="<一段话描述>"

优先级 pri 可以根据用户自己的重视程度直接推荐：核心功能给 1 或 2，体验优化给 3，附加能力给 4。不要问用户"你想要什么优先级"，而是给个建议让他点头或反对。

每写完一条，顺嘴点一句他做对的地方（具体、不泛泛）：

• "你这条把场景和动作都说清楚了，开发不用来回追问。"
• "这个异常路径想得挺细——很多人第一版会漏掉。"

聊三五条之后，如果感觉用户有点累了，或者开始发散，就主动收一下，并用一句话小回顾引到下一段：

"先攒到这里？你已经把'什么人、干什么、为啥'都串起来了，再写下去容易糊。我们趁热把这几条挑几条排进一个计划怎样？"

自然滑到"那什么时候做"

不要说"接下来是任务 3：制定计划"。用联想式过渡：

"这些东西不可能一次做完，你心里大概想先做哪几条？"

用户挑一挑之后，顺势说：

"那我们把挑出来的这波装进一个'计划'里，禅道里叫 productplan，挺像 sprint 的容器。"

• 名字可以直接建议："叫《MVP 首发》？"或者"叫《第一版》？"
• 起止日期如果用户不敏感，给 2 周 / 4 周 / 8 周 三挡让他选。

确认后：

zentao productplan create --productID=<产品ID> --title="<计划名>" --begin=<YYYY-MM-DD> --end=<YYYY-MM-DD>

然后把用户刚刚挑出来的那几条需求挂进去，一条一条来，每条前都顺口说一声要挂哪个：

zentao story update <storyID> --title="<标题必填>" --plan=<计划ID>

全部挂完后，顺手列一张表给用户看成果（不要加"小结"这种字眼）：

zentao story --productID=<产品ID> --pick=id,title,pri,plan

像朋友一样指着说："喏，你看这几条都绑在《MVP 首发》上了——从一个空白的点子到这张表，其实你已经走完了产品经理最核心的一条线：产品 → 需求 → 计划。研发同事打开禅道就能按这个打工。"

这里的"你已经走完 XXX"就是自然的小结——具体点出他串起了什么，比单独说一句"恭喜完成"有分量得多。

什么时候停下来

没有硬性的结束点。以下任一信号都是自然收尾时机：

• 用户开始追问"那后面还能做什么"——回答之后抛一个选择：继续在产品经理视角玩、换个身份、还是到此为止。
• 用户语气变淡 / 说"差不多了"——就着他话头收：

"那我们今天就逛到这儿。你刚才从一个点子整到了《XXX》(#<id>)，里面挂了 N 条需求，还排进了第一个计划。挺完整的一条线了。"

• 用户问了一个越出产品经理视角的问题（比如"这些任务怎么分派"）——顺手介绍项目经理视角存在，问他要不要换过去看看。

收尾时可以顺口带一句

结束前留一个钩子给未来探索（只挑一个说，不要一次列清单）：

• "其实禅道里还有 epic 和 requirement，是给更上层战略抽象用的，以后你团队大了会用得上。"
• "或者 release，产品真要上线那天它会登场。"

然后回到 ../SKILL.md 的收尾流程，询问是否换个身份或清理演示数据。

写操作速查（给 AI 用）

测试视角

用户选了这个身份，意味着他对"怎么确保东西是对的 / 怎么把问题反馈出去"更有兴趣。陪他走一段"挑个目标 → 写个用例 → 建个测试单 → 抓一只 Bug 看它走完生老病死"的路子——别编号也别列清单，但开场顺口把这段路点一下。

开场：一句话点路 + 挑靶子

示例开场：

"测试这块我们大概这样走：先从你们产品里挑一条需求当靶子，围着它写两条用例（正向一个、异常一个），拉个测试单装起来，最后提一只 Bug 陪它走完从 active 到 closed 的全程。随时喊停。

>

先看看产品里有哪些需求可以拿来练手——"

列几条候选让用户挑：

zentao story --product=<产品ID> --pick=id,title,pri --filter='stage:wait,stage:developing' --limit=10

如果产品里没需求，顺水推舟："要不我们借 PM 视角先捏一条？"（跳到 pm.md 的建需求那段）。

围着这条需求写用例

不要一上来罗列用例类型。用联想的问法：

"如果这条需求真上线，你第一个会想试什么？再想一个'要是乱搞会怎样'的场景？"

用户给出一个正向和一个异常场景，就可以各写一条用例，每条创建前把关键字段口语化报一遍：

zentao testcase create --product=<产品ID> --story=<storyID> --title="..." --pri=<1-4> --type=feature

如果用户想看完整字段（步骤/预期），用 zentao testcase help 展开，按需求补。

顺势拉个测试单

"有了用例还得有个'测试本子'把它们装起来跑，禅道里叫测试单。"

zentao testtask create --product=<产品ID> --name="v1 冒烟测试" --begin=... --end=...

把刚才的用例关联进来（参见 zentao testtask help），然后列一眼：

zentao testtask --product=<产品ID> --pick=id,name,status

然后抓一只 Bug 看它走完一生

用带点戏剧感的口气：

"假设你跑用例的时候发现点不对劲——要不我们提一个 Bug 练练手？"

和用户商量 Bug 的标题、严重度（severity）、优先级（pri）、重现步骤（steps）。严重度和优先级给个建议（比如"看起来能用就是有点歪，那严重 3 优先 3？"），让他点头即可。

zentao bug create --product=<产品ID> --title="..." --severity=<1-4> --pri=<1-4> --type=codeerror --steps="..."

顺手演示状态流转（边执行边用一句话解释它代表开发解决了、你关掉了）：

zentao bug resolve <id> --resolution=fixed
zentao bug close <id>

走完之后具体点一下用户刚才串起了什么：

"你看，这一圈其实把测试最核心的一条链走完了：需求 → 用例 → 测试单 → Bug → 状态流转。真实工作里无非是每环都放大一些——写更多用例、加回归、跟踪遗留缺陷。骨架你已经有感觉了。"

自然收尾

• 用户如果开始问"开发那边怎么接 Bug"——指一下 dev 视角。
• 用户语气淡下来——顺口回顾："你从一条需求写出了用例，拉了测试单，还提了一个 Bug 并把它送走。"
• 回到 ../SKILL.md 的收尾流程。

写操作速查（给 AI 用）

本视角目前剧情较轻，欢迎结合真实测试节奏继续扩展（例如回归、遗留缺陷分析）。