我有点懒，两个月前写 Riqor 1.0 的时候，它还只有命令行。agent-next inventory 盘资产，agent-next plan 排流程，agent-next gate 过门禁，产物落在 outputs/ 和 runs/ 里，人要看结果就去翻 Markdown。

用得下去，只是每次都得记住项目 id、track、scope 这几个参数，团队里不写脚本的人基本不会碰。

Riqor 2.0 重做了流程和界面，先把它做成了 DeepSeek Harness 的客户端插件，包名 @riqor/workbench。装进 DSH 之后，侧栏多出一个「交付工作台」，点开是完整的一条交付流程。

顶部是产品、项目、迭代三个下拉，加一个按编号或标题搜需求的搜索框。中间横着一条阶段条，有结论的显示「已确认」「已通过」，正在做的高亮成「进行中」，还没轮到的写「等待构建」。下面一块是当前阶段的活动，流程图和列表可以切换。最下面是选中活动的详情，执行状态、质量门禁、产物版本都在这里。

截图里的测试设计阶段已经跑过一轮，「生成测试用例」执行完成，质量门禁停在「待评审」，产物是 测试用例 v1，可以查看 HTML 也可以导出。这些状态由流程里的活动、产物和门禁一起算出来，刷新页面还在。

1. 为什么做成插件

DSH 是 super-agent 架构。模型、会话、工具和工作区读写都归宿主，Agent 能自己拆任务、起会话、读文件、跑命令。

插件市场里的看板就长在这套架构上。对话里说一句要做的功能，Agent 用工具把任务写成卡，卡上带实现步骤和验收标准。人拖动卡片改状态，点「创建新对话」，这张卡连同上下文进到新会话里继续做。

Riqor 借的也是这套东西。交付流程里的每个活动相当于一张卡，卡上绑一个 Skill。点执行，宿主开一个会话，Agent 在项目目录里读写，产物和回执回到卡上。模板定产物的结构，门禁管这张卡能不能往下走。

我做这个插件的动机跟看板差不多。多智能体编码，代码可以并行写，人得有个结果看板，看每一路做到哪、产出了什么、卡在哪道门禁。终端里翻五个会话不现实。

宿主本来就有这些能力，插件再养一套是重复，用户还得再配一遍 key。

所以 2.0 没有做独立客户端，只注册三块界面，侧栏一个条目、主区一个视图、设置页一节。进度不是前端假造的，会话里调了哪些工具、改了哪些文件，点「打开会话」都能看见。

开发时不用每次装进 DSH。仓库里带了个 harness/，复刻 DSH 的版式，实现模块加载和那几个 slot，颜色尺寸走 --dsw-* 变量并带 fallback。npm run dev 起来，打开 http://127.0.0.1:5178/harness/ 就能点。它只管外壳，执行还是真的。

2. 生命周期可以换

团队之间的研发流程差别很大。只做回归的团队，测试设计、测试执行、交付验收三段就够；带硬件的团队，执行前往往还要一段环境准备或者样机验证；有的公司设计评审单独成段，有的合在开发里。

截图里那条需求有六个阶段，需求分析、技术设计、开发实现、测试设计、测试执行、交付验收。项目默认流程跟着角色走。测试人员四段就够，需求分析、测试设计、测试执行、交付验收。新建需求按四段起步，缺哪段补哪段。

阶段条右边有个「添加阶段」。点开按分类列出还没用上的阶段，比如 Feature 开发、Bug 处理、迭代验收，组内可以多选。只存在于项目默认流程里的阶段会归到「项目自定义」一组，不会因为目录里没有就消失。

插进来的阶段自带默认活动。阶段不能凭空加，添加弹窗里能挑的都是目录里注册过的阶段，每个阶段带着自己的活动清单。要一个完全新的阶段，得先在预设里写出来。

删阶段留了退路。阶段里有活动正在跑时，删除会被拒绝。真删掉之后，属于这个阶段的产物、评论和画布坐标一起清掉，下游活动对它的依赖保留成悬空状态，界面上显示缺少依赖。deleteStageFromFlow 的注释写得很直白，宁可让下游卡住，也不要让它悄悄跑起来。

3. 阶段里的活动

活动是流程里最小的一格，差异也常落在这一格。同样是测试设计，有的团队先做候选仓库映射，有的加一道用例评审。一格活动由四样东西定义，名字、绑定的 Skill、产物类型、依赖的上游活动。

添加活动的弹窗就这四个字段。Skill 下拉按自定义、公共、当前阶段分组，公共 Skill 在任何阶段都能选，比如知识库更新、候选仓库识别、代码审查。截图里那个「周报生成」就是自定义的，一句话交代了它查禅道问题单、算本周数字、写成能转发的周报。产物类型可以不填，但界面会提示，没声明的话，添加后无法执行。

同一个 Skill 可以挂在多张卡上。测试点和测试用例现在用的是两个 Skill，如果某个团队习惯让一个 Skill 把两样一起写完，也可以绑到两个活动上，各自产出各自的产物。

活动有自己的 ID，连线、产物归属、执行历史都记在这个 ID 上。Skill 注册表后来改了名字或者换了实现，也不影响跑过的那些 Run，因为活动上存了一份当时的 Skill 定义快照。

除了 Skill 活动，流程里还有手工活动和评审活动。手工活动没有产物位，只记过程，比如开发任务拆分、编码实现，执行完门禁直接算通过。评审活动指向一个被评审的活动，它通过了，那道质量门禁才放行下游。

增删都只作用于当前需求。项目默认流程在新建需求时套用一次，之后每个需求可以有自己的走法。

4. Skill 也能自己加

内置 Skill 覆盖了需求分析那条线，生成、评审、变更需求说明书，还有测试点、测试用例、代码审查、知识更新、候选仓库识别。这些 ID 是固定的，自定义 Skill 不会覆盖同名的内置项。

它们覆盖的是通用动作。公司自己的规范不在其中，得自己写。用例怎么分层、缺陷怎么定级、代码审查看哪几项，每个团队都不一样，写成 Skill 才能让 Agent 按这个来。

要加新的，点顶部「Skill 库」，再点右上角的加号。上一章节的截图中的自定义skills分类中，就是我新增的测试skill。

表单只有两个输入框，别名和一句话内容，第二栏的占位提示写着「它解决什么问题、什么时候用、产出什么」。

提交之后弹窗关掉，工作台起一个独立会话，让 Agent 按这句话去写 skills/<name>/SKILL.md 和 contract.json，写完注册进目录。再回到添加活动的弹窗，这个 Skill 已经能选了。

contract.json 是 1.0 留下的契约，字段不多。artifactKind 声明产物类型，outputs 声明产出文件，validator 给一条校验命令，session 决定每次新开对话、复用对话还是跟着阶段走，prompt 可以补一段提示。解析时会校验类型名、数量、长度，不合格就报问题，不认识的字段忽略。

有 validator 的 Skill 和没有的，差别在门禁那一环。前者能让机器真的跑一遍检查，后者只能靠人看。

注册表里还有一些 internal 的 Skill，比如「制作 Skill 包」，它们不出现在活动选择器里，只由流程内部调用。

5. 产物模板

产物模板决定交付物长什么样。测试用例，有的公司只要前置条件、步骤、预期三列，有的还要用例类型和自动化标记；缺陷报告也差不多，有的要复现概率，有的要影响版本。字段和章节每家都不一样，模板把这些固定下来，Agent 只负责往里填，评审和下游解析不用每次猜格式。

16 类产物各有模板，常用的有需求说明书、测试用例、缺陷报告、测试报告，另外还有验收、回归、自动化、发布变更几类。

模板是一份 Markdown 骨架，一级标题是产物名，二级标题是小节，工作台解析成段落再渲染预览。测试点模板连表格的列都定了，来源、风险覆盖意图、维度、条件、技术、说明，另外还有原子需求覆盖和风险覆盖两张对照表。

导入模板支持 .md 和 .md.tmpl，文件存到 ~/Riqor/<project>/Templates/<type>.md.tmpl。内置模板在仓库的 templates/artifacts/，读取时项目目录下的同名文件覆盖内置。单个文件限制 512KB，类型名要求小写字母开头的连字符串。

选模板有三层优先级。本次显式选择最优先，没选就用项目的阶段默认，也就是图上那个「设为阶段默认」，再没有就回落到内置。指定的模板找不到时，回落到同类型的内置模板。

「还原默认」就是把项目目录下的覆盖文件删掉，下次读到的就是内置版本。模板按项目解析，换一个项目读到的是它自己 Templates/ 目录下的文件。

6. 项目知识库

知识库放在项目目录下，~/Riqor/<project>/knowledge/，页面是 Markdown，frontmatter 里的 related 写它跟哪些页面有关。演示项目收了 135 页，页与页之间攒了 985 条关系，有一条指向的文件名大小写对不上，图上标成断链。断链只提示，不拦着用。

图里每个节点是一个术语页，有关系的连一条线，可以搜索，点开节点看定义和上下游，拖动节点能展开局部。

模板弹窗的第二个页签就是这个图，活动详情里另有一栏「知识库引用」。这一栏不用人挑，每次打开详情，工作台把需求标题、产品、迭代、阶段和活动名拆成词，去比页面的标题、路径和正文前 800 字。标题命中权重最高，路径和正文依次递减；命中的小节如果跟活动类型对得上，再加一档，测试类活动偏向 06-测试场景，技术设计偏向 05-架构说明。

分数过线的取前 5 个，每行写明命中原因，比如标题命中了几个需求关键词，或者活动类型对上了哪个小节。不合适就取消引用，这个页面在这个活动里不会再冒出来。留下来的引用只存指针，不复制正文，页面更新之后下次读到的就是新版。

企业里同一个词常有好几种解释。工单、批次、过账这些词在每家公司都有自己的定义，平时散在 Confluence、群聊和老员工的脑子里，Agent 每回都要猜一遍。页面放进项目目录，匹配到的内容自动进上下文，生成的用例和缺陷描述才像这个团队写的。

7. 跑一轮会发生什么

点执行，工作台起会话，Skill 拿到模板和上游产物，生成 Markdown。回执写到项目根目录的 runs/<Run ID>/，最终产物写到 features/<年月>/<需求>/，同名文件覆盖为最新版，旧版本留在各自的 Run 目录里。

门禁有四种状态，无需评审、待评审、已通过和未通过。评审活动没过，依赖它的下游活动执行按钮是灰的，详情里写着等待上游质量门禁。产物带版本号，重新执行会生成新的一版，旧版本还能在活动详情里翻到。

需求说明书改版时另有一套流程。生成候选版本，和基线比差异，确认之后才替换；引用了它的下游活动会列在「下游待复核」里，不会被自动重跑。

8. 改哪一层

流程长短改阶段，一格活的做法改活动，专业要求写进 Skill，产物字段落在模板里，术语解释放知识库。差异落在哪一层，就改哪一层。几层都能改，才谈得上适配不同的公司。只改提示词的话，流程还是那一条。

设想一个做车载设备的团队。测试执行前面多一道样机验证，这一段可以自己加。用例模板里补上台架编号和固件版本两列。冒烟检查如果依赖 CAN 报文，就写一个读报文的 Skill 挂上去。不用动别人的流程。

Riqor 2.0 现在还在开发中。模板库、Skill 库这些界面是最近做的，截图有的来自本地 harness 的演示数据，有的来自真实项目。目前跑通的是测试人员这条线，开发人员和测试开发工程师那两套预设还没放出来。1.0 那套契约没有变，run、workflow、gate、artifact 还是原来的意思，2.0 在它上面加了一层能点的界面。

Riqor 2.0 计划月底开源，同时放进 DSH 的插件市场。装了 DSH 的同学，到时候在插件市场里就能装上，不用自己 clone 再打包。

也想先听听大家的想法。你们团队的交付流程分几段，哪一步最想交给 Agent，产物模板里哪些字段是必须的。留言就行，我按反馈继续改。月底见。