人工智能AI Agent多智能体后端前端【免费下载链接】relayRelay 是一个多智能体协作平台通过统一的界面进行协作开发、代码审查、任务管理将多个 AI Agent 组织成一个真正的团队。项目地址https://gitcode.com/openJiuwen/relay点击查看免费下载本篇文章的关联文档为 requirements-checklist-template.md。文中对该文档的模板、填写规则做了完整继承并结合relay仓库内的 feature-doc-template.md、shared-rules.md 等配套文档与源码展开纵深解读。在 Relay 这类多智能体协作平台上一个 Feature 从用户一句话立项到最终验收中间要经过feat-lifecycle立项、quality-gate自检、peer review、merge gate 等多道关卡其中需求点遗漏与验收口径不一致是最常见的返工来源。本指南围绕 requirements-checklist-template.md 讲解需求点 Checklist 的用途、模板结构与填写规则并结合仓库内 Feature 文档规范、协作证据契约与源码实现说明如何把用户的每一句原话稳定地映射到可执行的 ACAcceptance Criteria与可复现的验证方式上。读完你可以直接把这个 Checklist 接入自己的 kickoff/spec 流程让需求→AC→证据形成一条可追溯的闭环。一、为什么需要需求点 Checklist多智能体场景下的AC 漏项问题在 Relay 的项目协作规则见 shared-rules.md中第一条第一性原理 P1 是面向终态不绕路P5 是可验证才算完成。其中 P5 给出的核心约定是完成了必须附证据测试通过、截图、日志。没有验证 没有完成。而验证的标尺就是 AC。一个 Feature 立项时如果只凭印象写几条 AC很容易出现两类问题需求点漏项用户原始诉求中的某个细节没有进入任何一条 AC开发到一半才发现遗漏返工成本极高验收口径模糊AC 写了但没写怎么验证review 阶段作者和审查者对算不算完成各执一词只能靠反复拉扯消耗上下文。需求点 Checklist 正是在这个背景下设计的在 kickoff/spec 阶段就把需求点结构化避免 AC 漏项原文用途。它把用户说了什么需求点与怎么验收AC 编号 验证方式在立项那一刻就钉在同一张表里。该模板在仓库中的定位可以从 manifest.yaml 的 refs 段确认requirements-checklist-template登记为description: 需求点 checklist 模板归入refs/参考材料注释明确说明 refs 不作为独立 skill 触发而是被各 skill 引用的参考资料。这意味着它不是某个独立功能而是贯穿 Feature 生命周期各 skill 的公共方法论文档。二、使用时机两个关键节点模板明确给出了两个使用时机feat-lifecyclekickoff 创建 feature spec 时立项瞬间就完成需求点结构化作为 spec 的输入基线quality-gate自检前补齐验收口径时自检前把遗漏的验收口径补全确保验收口径完整才放行。两个时机对应的正是 Feature 生命周期的首尾两端。仓库 shared-rules.md §11 给出了生命周期 skill 的触发映射时机Skill触发词立项feat-lifecycle开个新功能、new feature、F0xx、立项完成feat-lifecyclefeature 完成、F0xx done、验收通过而 packages/api/src/config/governance/methodology-templates.ts 中内嵌的 SOP 模板把整个开发工作流固化为 6 步StepWhatSkill1Create worktreeworktree2Self-check (spec compliance)quality-gate3Peer reviewrequest-review/receive-review4Merge gatemerge-gate5PR cloud review(merge-gate handles)6Merge cleanup(SOP steps)可见Step 1 之前是 kickoff需求点 Checklist 首次填充Step 2 是 quality-gate 自检Checklist 状态翻转、验收口径补全两者与模板声明的两个使用时机一一对应。三、模板结构详解以下是 requirements-checklist-template.md 提供的完整模板Markdown 表格形式原样继承如下## 需求点 Checklist | ID | 需求点用户原话/转述 | AC 编号 | 验证方式 | 状态 | |----|---------------------------|---------|----------|------| | R1 | ... | AC-1 | test / screenshot / manual | [ ] | | R2 | ... | AC-2 | test / screenshot / manual | [ ] | | R3 | ... | AC-3 | test / screenshot / manual | [ ] | ### 覆盖检查 - [ ] 每个需求点都能映射到至少一个 AC - [ ] 每个 AC 都有验证方式 - [ ] 前端需求已准备需求→证据映射表若适用3.1 五个字段的含义字段含义填写要点ID需求点编号如 R1、R2、R3保证每条需求可被唯一引用便于在后续 spec、review 中精确指代需求点用户原话或工程化转述优先保留用户原话见第四节填写规则AC 编号该需求点映射到的验收标准编号如 AC-1与 feature doc 中的 AC 编号体系对齐见第五节验证方式test / screenshot / manual必须可执行至少三者之一状态kickoff 时默认[ ]quality-gate 完成后改为[x]见第四节状态栏规则3.2 覆盖检查Checklist 的自我校验模板自带三段覆盖检查本质是对需求→AC→验证三条链路的完备性断言每个需求点都能映射到至少一个 AC—— 防止说了但没验收每个 AC 都有验证方式—— 防止有 AC 但无从验证前端需求已准备需求→证据映射表若适用—— 前端类需求强制准备证据映射与协作规则中的截图/录屏证据要求呼应。第三点不是可有可无。仓库 shared-rules.md §9愿景守护明确规定前端功能产出截图证据≤3 截图 15s 录屏、请求 review 附原始需求摘录≤5 行涉及 UX/前端的验证必须打开浏览器实际操作看代码不等于看效果。因此前端需求在 kickoff 阶段就备好需求→证据映射表是为了在验收阶段能直接产出截图/录屏类的可视化证据。四、填写规则详解模板给出了三条硬性填写规则逐条展开规则 1需求点优先用用户原话必要时补一句工程化转述需求点栏位是整张表的信息源头优先直接引用用户原话因为用户原话是需求真相源后续所有 AC、实现、review 都以此为准绳仓库 pr-template.md 的 PR 模板同样要求Original Requirements 必填直接粘贴用户原话≤5 行并要求 reviewer 对照摘录判断交付物是否解决了用户的问题——可见用户原话是贯穿立项、PR、review 全流程的锚点。当原话过于口语化或歧义较重时可以在原话后补一句工程化转述如拆解出技术约束、边界条件但转述只是补充不能替代原话。规则 2验证方式必须可执行验证方式必须落在以下至少一种可执行形式上test给出具体测试名或测试命令如pnpm --filter openjiuwen/relay-api-server testscreenshot前端界面截图验证 UI 效果manual确定性的人工操作步骤命令 输入 预期/实际。这条规则与 shared-rules.md P5 的fail-closed 证据契约直接咬合凡fixed没问题完成了这类结论性声明必须附本轮实际检查过的证据文件路径 行号、测试输出、截图拿不出证据只能说还没查完。Checklist 的验证方式栏就是这条契约在立项阶段的提前约定——验收时按表兑现即可。规则 3状态栏的生命周期kickoff 时默认[ ]未完成quality-gate 阶段验证通过后改为[x]。状态翻转不是随手一勾。结合 review-request-template.md 可见请求 review 时必须附上 quality-gate 自检报告摘要否则 reviewer 不审——也就是说[x]背后要有自检证据支撑而不是口头声明。五、从用户原话到可验证 AC全链路拆解需求点 Checklist 不是孤立的一张表它与 Feature 文档的 AC 编号规范、验证方式的可执行性、证据体系构成一条完整链路。5.1 AC 编号体系与 Feature 文档严格对齐需求点映射的 AC 编号应遵循 feature-doc-template.md 中的硬性格式约定。该文档明确指出这些格式是parser 依赖——Relay 的 Feature Progress Dashboard 需要从 feature docs 自动提取 Phase 进度、AC 完成度等格式不统一 parser 不可靠。其核心约定AC 编号格式AC-A1、AC-B2Phase 大写字母 序号例如 Phase A 的第一条验收标准为AC-A1完成度标记- [ ] AC-A1: {验收条件}表示未完成- [x] AC-A1: {验收条件}表示已完成parser 提取通过正则- \[([ x])\] AC-解析每条 AC 的勾选状态从而自动统计 Feature 完成度。因此需求点 Checklist 中的AC 编号栏不能随意编号必须与 feature spec 中按 Phase 组织的 AC 编号一一对应如 R1 对应 AC-A1、R2 对应 AC-B2。这样一张表就同时打通了三层信息用户原话需求层→ AC 编号规范层→ 勾选状态进度层。5.2 验证方式为什么必须可执行模板把验证方式限定为 test / screenshot / manual是因为这三个词背后对应的是三类可复核的证据形态test→ 对应自动化测试输出测试通过数、失败数仓库 review-request-template.md 的自检证据示例即为pnpm --filter openjiuwen/relay-api-server test # X passed, 0 failed pnpm --filter openjiuwen/relay-web test # X passed, 0 failed pnpm -r --if-present run build # 成功screenshot / 录屏→ 对应前端视觉证据满足 §9 愿景守护的截图≤3 张与 15s 录屏要求manual→ 对应确定性复现步骤命令 输入 预期/实际这也是云端 review 中对 P1/P2 缺陷的最低举证要求见 pr-template.md。三者共同指向仓库证据体系的设计意图结论必须基于可复现证据而非信心表达shared-rules.md §16实事求是。5.3 前端需求的需求→证据映射表覆盖检查第三项要求前端需求准备需求→证据映射表。它的作用是在立项阶段就为每条前端需求预定证据形态截图/录屏/交互步骤避免验收时补拍证据或无法证明效果。这与仓库中前端验证必须实际打开浏览器操作§9 规则 6的约束配合证据映射表规定了验什么浏览器实操规定了怎么验。六、完整实战示例下面结合仓库 pr-template.md 中给出的真实用户原话示例——我要能看到各智能体分别挂了哪些 Skill按智能体分类一目了然——演示一份完整的需求点 Checklist 如何从 kickoff 阶段填充到 quality-gate 阶段。6.1 kickoff 阶段填充状态全为[ ]假设该 Feature 拆分为两个 PhasePhase A 为后端 Skill 挂载数据聚合接口Phase B 为前端按智能体分类的展示页。Checklist 可填写为## 需求点 Checklist | ID | 需求点用户原话/转述 | AC 编号 | 验证方式 | 状态 | |----|---------------------------|---------|----------|------| | R1 | 我要能看到各智能体分别挂了哪些 Skill | AC-A1, AC-B1 | test / screenshot | [ ] | | R2 | 按智能体分类一目了然 | AC-B2, AC-B3 | screenshot | [ ] | | R3 | 挂载数据与 skill 注册表一致工程化转述技能清单须与 manifest 注册的官方 skills 对齐 | AC-A2 | test | [ ] | ### 覆盖检查 - [x] 每个需求点都能映射到至少一个 AC - [x] 每个 AC 都有验证方式 - [x] 前端需求已准备需求→证据映射表若适用其中 AC-A1、AC-A2 写入 feature spec 的 Phase AAC-B1AC-B3 写入 Phase B编号严格遵循AC-{Phase字母}{序号}格式保证 feature-doc-template.md 中描述的 parser 可以正确提取完成度。6.2 quality-gate 阶段状态翻转当 Phase A 完成、对应 AC 通过验证后Checklist 状态栏同步更新| ID | 需求点 | AC 编号 | 验证方式 | 状态 | |----|--------|---------|----------|------| | R1 | 我要能看到各智能体分别挂了哪些 Skill | AC-A1, AC-B1 | test / screenshot | [x] | | R2 | 按智能体分类一目了然 | AC-B2, AC-B3 | screenshot | [ ] | | R3 | 挂载数据与 skill 注册表一致 | AC-A2 | test | [x] |注意[x]的翻转以实际证据为准AC-A1 对应的测试命令输出、AC-A2 对应的测试用例通过记录都要可复现尚未完成的 Phase B 需求R2保持[ ]不提前勾选。七、与协作规则及源码的咬合关系需求点 Checklist 之所以能成为避免 AC 漏项的有效工具是因为它嵌入了 Relay 一整套证据驱动的协作机制。以下几条可以在仓库中直接验证与 evidence 证据存储对接仓库实现了 SQLite evidence storepackages/api/src/routes/evidence.ts 提供/api/evidence/search等接口用于搜索项目知识。Checklist 中约定的验证方式测试输出、截图路径正是这类证据的入口线索——需求点通过 AC 编号关联到可检索的证据记录。与 review 请求联动review-request-template.md 要求 review 请求必须附上 quality-gate 自检报告摘要与测试结果。而 quality-gate 自检的核心输入之一就是需求点 Checklist——验收口径是否补齐直接决定自检报告能否通过。与 PR 模板联动pr-template.md 的 PR body 必须包含原始需求摘录≤5 行和 Test Evidence这与 Checklist 的需求点用户原话验证方式两栏数据同源立项时填好一次后续 review 与 PR 阶段直接复用。与 AC 完成度自动统计联动从 methodology-templates.ts 中内嵌的 FEATURE_TEMPLATE 可以看到标准 Feature 文档骨架即包含## Acceptance Criteria- [ ] AC-1: ...结构。需求点 Checklist 中每条需求映射的 AC 编号最终都落在这个被解析的结构里供进度仪表盘统计。八、常见误区与使用建议结合模板的三条填写规则以下是实践中最常见的几个反模式与修正建议误区表现正确做法需求点栏写翻译腔而非原话填成 R1: 实现 skill 列表接口优先保留用户原话如 我要能看到各智能体分别挂了哪些 Skill需要时再补工程化转述验证方式写模糊描述验证方式测试通过落到 test / screenshot / manual 三类之一test 需给测试名或命令manual 需给可复现步骤状态栏长期不更新验收完成仍保持[ ]quality-gate 阶段依据实际证据翻转[x]与 AC 勾选状态保持一致前端需求漏证据映射表只写 AC 不写截图/录屏计划若适用则补齐需求→证据映射表为验收阶段的截图证据预留路径AC 编号与 feature doc 脱节随意写 AC-1、AC-2 与 spec 对不上按 feature doc 的 Phase 字母 序号体系编号确保 parser 可提取完成度此外还有一个容易忽视的原则Checklist 是活的不是立项时填完就归档。需求在开发过程中若有澄清或变更应同步更新需求点、AC 编号或验证方式但需求点栏以用户原话为锚工程化转述只能作为补充说明不能让转述悄悄替换掉用户的原始诉求——这与仓库 shared-rules.md §9开始 Feature 前必须读原始 Discussion/Interview以及 §16不断章取义的规则一脉相承。总结需求点 Checklist 是 Relay 多智能体协作中把用户诉求转化为工程验收的第一道闸门。它的价值不在于表格本身而在于强制在立项瞬间完成三件事锁定用户原话、映射 AC 编号、约定可执行验证方式。配合仓库内的 feature-doc-template.mdAC 编号与 parser 规范、shared-rules.mdP5 可验证才算完成与 fail-closed 证据契约、review-request-template.md 与 pr-template.md证据随 review/PR 流转这张表就构成了需求→AC→验证→证据的完整闭环——这正是多智能体团队能高速并行而不失控的底层保障。赞分享人工智能AI Agent多智能体后端前端【免费下载链接】relayRelay 是一个多智能体协作平台通过统一的界面进行协作开发、代码审查、任务管理将多个 AI Agent 组织成一个真正的团队。项目地址https://gitcode.com/openJiuwen/relay点击查看免费下载相关推荐easy-vibe 需求验证实战用 The Mom Test 用户访谈方法把听起来不错变成可靠的需求证据easy vibe 需求验证实战用 The Mom Test 用户访谈方法把听起来不错变成可靠的需求证据 本篇文章基于 easy vibe 项目 Sta教程文档BISHENG 多租户树模型F011验收验证全指南从 AC 矩阵到测试落地的工程实践BISHENG 多租户树模型F011验收验证全指南从 AC 矩阵到测试落地的工程实践 导读 本文围绕 BISHENG v2.5.1 特性 F011 teAI 应用AI AgentLLMOps工作流自动化RAG后端前端把模糊想法变成可验收需求Entire CLI 仓库的 /analyst 需求分析 Agent 实战指南把模糊想法变成可验收需求Entire CLI 仓库的 /analyst 需求分析 Agent 实战指南 导读 本文以 Entire CLI 仓库自带的 Cla开发工具Agent TracesAI 应用上一篇10种EaselJS动画缓动函数速查让你的Web动画更生动的参数指南下一篇从传统换相到场定向控制平衡车电机控制的技术革命创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考