1. 需求评审为什么需要 OpenClaw DeepSeek 这套组合需求评审这件事做过的人都知道痛点在哪一份需求文档动辄几十页评审会上大家凭经验扫一遍能挑出十几个问题就算不错了。但真正致命的问题往往藏在细节里——某个动词没有描述执行流程、某个形容词不可测试、某个业务对象的属性缺了唯一标识符。这些问题人工评审时极易漏掉等到开发阶段才暴露返工成本就上去了。我试过用纯 Prompt 的方式让大模型做需求评审效果不稳定每次输出的格式不一样检查项覆盖不全而且没法沉淀成可复用的流程。后来换成 OpenClaw 加载 DeepSeek 驱动的需求评审 Skill才把这件事跑通。OpenClaw 负责 Skill 的加载、调度和结果回写DeepSeek 负责语义理解和问题识别TaoToken 负责统一管理 API Key 和调用链路。三者各司其职整条链路就顺了。这套方案适合谁如果你是需要频繁评审需求文档的产品经理、系统分析师或者是想用 AI 辅助代码审查、文档审查的开发者都可以直接跟做。核心思路是把评审规则写成 Skill 定义让 OpenClaw 自动加载并调用 DeepSeek 执行评审最后把结果结构化输出。整个流程分几个关键环节先定义 Skill 的检查清单和输出格式再用 TDD 的思路设计测试用例然后通过 TaoToken 统一 Key 接入 DeepSeek API跑通评审后核对输出结果。下面我按实际操作顺序拆开讲。2. TaoToken 前置准备统一 Key 与 Base URL 配置在开始写 Skill 之前先把模型调用的基础设施搭好。这一步的核心是拿到一个可用的 API Key并且把 Base URL 配置正确。我用 TaoToken 来统一管理 Key好处是后面不管换哪个模型只需要改 Model IDBase URL 和鉴权方式不用动。2.1 获取 API Key 与确认接入信息首先访问 TaoToken 官网注册账号进入控制台创建 API Key。创建完成后你会拿到一串以sk-开头的密钥这个就是后面所有配置里要填的 Key。接入信息如下配置项值Base URLhttps://taotoken.net/apiAPI Key控制台创建的sk-开头密钥Model IDdeepseek-chat或deepseek-reasoner鉴权方式Authorization: Bearer 你的Key注意Base URL 末尾不要加/v1TaoToken 的 API 路径已经做了兼容处理直接填https://taotoken.net/api即可。如果你用的客户端要求填完整路径可以写成https://taotoken.net/api/v1/chat/completions。2.2 在 OpenClaw 中配置模型接入OpenClaw 的模型配置通常放在项目根目录的config文件夹下或者通过环境变量注入。我推荐用环境变量加配置文件的方式这样 Key 不会硬编码到代码里。在项目根目录创建.env文件TAOTOKEN_API_KEYsk-你的实际密钥 TAOTOKEN_BASE_URLhttps://taotoken.net/api TAOTOKEN_MODEL_IDdeepseek-chat然后在 OpenClaw 的模型配置文件config/model.yaml中引用这些环境变量model: provider: openai-compatible base_url: ${TAOTOKEN_BASE_URL} api_key: ${TAOTOKEN_API_KEY} model_id: ${TAOTOKEN_MODEL_ID} temperature: 0.3 max_tokens: 4096 timeout: 120这里temperature设成 0.3 是为了让评审结果更稳定减少随机性。max_tokens设 4096 是因为需求评审的输出通常比较长尤其是问题列表多的时候。2.3 验证 Key 是否可用配置完成后先用一个最简单的请求验证 Key 和 Base URL 是否通。可以用 curl 直接测curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的实际密钥 \ -d { model: deepseek-chat, messages: [ {role: user, content: 回复OK两个字} ], max_tokens: 10 }如果返回的 JSON 里choices[0].message.content包含「OK」说明 Key 和 Base URL 都没问题。如果返回 401检查 Key 是否复制完整如果返回 404检查 Base URL 是否多加了/v1或者路径拼错。这一步看起来简单但后面 Skill 调用失败时很多问题都出在这里。先把基础链路验证通过再往上叠 Skill 逻辑排障会轻松很多。3. 可复制配置需求评审 Skill 定义与 TDD 用例设计基础设施通了之后进入核心环节定义需求评审 Skill。这个 Skill 的本质是一套结构化的评审规则告诉 DeepSeek 要检查哪些维度、按什么格式输出、遇到不同评审模式怎么处理。3.1 Skill 配置文件结构OpenClaw 的 Skill 通常用一个 JSON 或 YAML 文件定义。我在项目里创建skills/requirement-review/skill.json内容如下{ name: requirement-review, version: 1.2.0, description: 基于 DeepSeek 的需求文档语义评审 Skill, model: { provider: openai-compatible, base_url: https://taotoken.net/api, api_key_env: TAOTOKEN_API_KEY, model_id: deepseek-chat }, input: { type: object, properties: { document: { type: string, description: 需求文档全文 }, mode: { type: string, enum: [partial, complete], default: partial, description: 评审模式partial 局部评审complete 完备评审 }, target_elements: { type: array, items: {type: string}, description: 局部评审时指定的需求元素列表 } }, required: [document] }, output: { type: object, properties: { issues: { type: array, items: { type: object, properties: { id: {type: integer}, description: {type: string}, original_text: {type: string}, check_item: {type: string}, severity: {type: string, enum: [high, medium, low]} } } }, summary: { type: object, properties: { total_issues: {type: integer}, score: {type: number}, high_count: {type: integer}, medium_count: {type: integer}, low_count: {type: integer} } } } }, prompt_template: 你是一名资深需求评审专家。请对以下需求文档进行语义评审。\n\n评审模式{{mode}}\n{{#if target_elements}}指定评审元素{{target_elements}}{{/if}}\n\n通用检查项\n1. 名词检查能否准确识别所有业务对象的属性无其他名词修饰的名词为属性有其他名词刻画特征的名词为业务对象。\n2. 动词检查所有动词的执行流程需有详细描述明确操作方式与步骤。\n3. 形容词与副词检查此类词汇具备不可测试性出现时需直接列为问题。\n4. 代词检查需结合上下文明确指代关系确保无歧义。\n5. 术语一致性检查梳理含义相近的词语列出并提请作者澄清是否指代同一含义。\n\n需求元素专属检查项\n- 项目目标是否明确阐述项目具体目标是否清晰说明要解决的核心问题是否描述系统的业务价值\n- 业务概述是否列明系统用户的所有角色是否通过流程图或文字描述业务流程\n- 系统概述是否介绍系统总体功能是否清晰界定系统范围是否描述功能模块划分\n- 非功能需求是否对所有非功能性需求进行定量描述是否包含响应时间、吞吐量、并发用户数等维度\n- 环境需求是否完整描述软件、硬件、网络的配套环境需求\n\n需求变更附加检查项\n若为变更需求需额外检查是否明确变更前、后的需求内容是否界定变更类型\n\n输出要求\n以 JSON 格式输出包含 issues 数组和 summary 对象。issues 中每条包含 id、description、original_text、check_item、severity。summary 包含 total_issues、score满分100、high_count、medium_count、low_count。\n\n需求文档内容\n{{document}} }这个配置文件里几个关键点base_url直接写 TaoToken 的 API 地址api_key_env指向环境变量model_id指定 DeepSeek 模型。prompt_template里把检查清单和输出格式都写清楚了这样 DeepSeek 每次评审都会按同样的规则执行。3.2 TDD 用例设计先写测试再调 SkillTDD 的思路是先定义「什么算评审正确」再让 Skill 去满足这些用例。我设计了三个测试用例覆盖局部评审、完备评审和变更需求评审。测试用例文件tests/review-cases.json{ cases: [ { id: case-001, name: 局部评审-仅检查项目目标, input: { document: 拟开发一套个人名片管理系统需求如下1运行在单机上支持WINDOWS 2003/XP。2可以录入名片信息姓名公司名称公司地址邮编固定电话手机职务职称网站地址等。, mode: partial, target_elements: [项目目标] }, expected: { min_issues: 1, must_contain_check_item: 项目目标, must_contain_severity: high } }, { id: case-002, name: 完备评审-全元素检查, input: { document: 拟开发一套个人名片管理系统需求如下1运行在单机上支持WINDOWS 2003/XP。2可以录入名片信息姓名公司名称公司地址邮编固定电话手机职务职称网站地址等。3人员可以重名。4除上述属性外可以由操作员自定义增加不超过其他10个属性。5可以对这些人员进行分类。6可以按名片信息中的任何一个数据项进行任意组合条件查询。8数据库系统不限但是应该占用的硬盘空间尽可能小。, mode: complete }, expected: { min_issues: 10, must_contain_check_item: 形容词与副词, must_contain_severity: high } }, { id: case-003, name: 变更需求评审-检查变更前后描述, input: { document: 变更需求将名片录入功能中的手机字段改为必填项。变更前手机字段为选填。变更后手机字段为必填。, mode: partial, target_elements: [需求变更] }, expected: { min_issues: 0, must_contain_check_item: 需求变更 } } ] }这三个用例分别验证局部评审能否只检查指定元素、完备评审能否覆盖所有检查项、变更需求能否识别变更前后描述。每次调整 Skill 的 prompt 或参数后跑一遍这些用例确保没有回退。3.3 评审结果回写配置评审完成后结果需要回写到指定位置。OpenClaw 支持通过 output handler 把结果写到文件或数据库。我在config/output.yaml里配置output: handlers: - type: file path: ./output/review-result-{{timestamp}}.json format: json - type: excel path: ./output/review-result-{{timestamp}}.xlsx sheets: - name: 问题列表 columns: [id, description, original_text, check_item, severity] - name: 综合评价 columns: [total_issues, score, high_count, medium_count, low_count]这样每次评审完会自动生成一个 JSON 文件和一个 Excel 文件Excel 里两个 sheet 分别对应问题列表和综合评价方便直接发给需求作者。4. 验证请求与成功结果跑通一组需求样例配置写完之后最关键的一步是实际跑一遍看看输出是否符合预期。我用一份个人名片管理系统的需求文档作为测试样例这份文档包含 8 个功能点覆盖了项目目标、系统概述、功能设计、数据对象、环境需求等多个维度。4.1 执行评审请求在 OpenClaw 项目根目录执行openclaw run skill requirement-review \ --input ./samples/requirement-doc.md \ --mode complete \ --output ./output/如果一切正常终端会输出评审进度最后显示类似[INFO] Skill requirement-review loaded, version 1.2.0 [INFO] Model: deepseek-chat via https://taotoken.net/api [INFO] Review mode: complete [INFO] Sending request to model... [INFO] Received response, parsing JSON... [INFO] Found 17 issues, score: 62.5 [INFO] Result written to ./output/review-result-20250923-143022.json [INFO] Excel written to ./output/review-result-20250923-143022.xlsx4.2 核对输出结果打开生成的 JSON 文件可以看到 issues 数组里每条问题的结构{ issues: [ { id: 1, description: 文档未明确阐述项目的具体目标、要解决的主要问题以及系统的业务价值。仅简单提及拟开发一套个人名片管理系统缺乏对项目成功标准、用户痛点或预期收益的描述。, original_text: 拟开发一套个人名片管理系统需求如下, check_item: 项目目标-是否明确阐述项目具体目标, severity: high }, { id: 2, description: 文档缺乏对系统总体功能的介绍未清晰界定系统范围也没有描述功能模块的划分。, original_text: 整个需求文档内容摘要, check_item: 系统概述-是否清晰界定系统范围, severity: high } ], summary: { total_issues: 17, score: 62.5, high_count: 8, medium_count: 6, low_count: 3 } }我核对了几个关键点问题描述是否准确对应原文、检查项是否匹配预设规则、严重级别是否合理。实测下来17 个问题里有 14 个是人工评审时容易忽略的细节比如「形容词尽可能小不可测试」「术语名片信息与数据项可能指代相同内容但用词不一致」这类问题人工评审时很容易一带而过。4.3 用测试用例验证 Skill 稳定性跑完实际样例后再用之前设计的 TDD 用例验证一遍openclaw test skill requirement-review --cases ./tests/review-cases.json输出[PASS] case-001 局部评审-仅检查项目目标 [PASS] case-002 完备评审-全元素检查 [PASS] case-003 变更需求评审-检查变更前后描述 Total: 3 passed, 0 failed三个用例全部通过说明 Skill 在局部评审、完备评审、变更评审三种场景下都能稳定输出。如果某个用例失败通常是因为 prompt 里的检查项描述不够明确或者输出格式约束不够严格调整后重新跑即可。5. 本篇常见错排查401、local proxy failed、reading choices 等报错处理即使配置看起来没问题实际跑的时候还是会遇到各种报错。我把踩过的坑整理出来对照排查会快很多。5.1 401 Unauthorized这是最常见的错误返回体通常是{ error: { message: Invalid API key provided, type: invalid_request_error, code: invalid_api_key } }排查步骤先确认.env文件里的TAOTOKEN_API_KEY是否以sk-开头且没有多余空格再确认 OpenClaw 是否正确加载了环境变量可以在代码里打印process.env.TAOTOKEN_API_KEY的前 8 位来验证最后确认 Key 是否在 TaoToken 控制台被禁用或过期。5.2 local proxy failed这个报错通常出现在 OpenClaw 尝试通过本地代理转发请求时Error: local proxy failed: connect ECONNREFUSED 127.0.0.1:7890原因是 OpenClaw 的模型配置里可能残留了代理设置或者系统环境变量里有HTTP_PROXY/HTTPS_PROXY指向了一个不可用的地址。解决办法是在.env里显式清空代理HTTP_PROXY HTTPS_PROXY NO_PROXYtaotoken.net然后在 OpenClaw 的模型配置里确认没有proxy字段。TaoToken 的 API 地址是直连的不需要经过任何本地代理。5.3 reading choices 报错这个错误通常长这样TypeError: Cannot read properties of undefined (reading choices)说明 API 返回的 JSON 结构里没有choices字段。可能的原因有三个一是 Base URL 拼错了比如写成了https://taotoken.net/api/v1但实际请求路径重复拼接了/v1二是 Model ID 填错了比如填了一个 TaoToken 不支持的模型名三是请求体格式不对比如messages数组为空。排查方法先用 curl 单独测一次 API确认返回体里有choices再检查 OpenClaw 的请求日志看实际发出的 URL 和请求体是什么最后对照 TaoToken 文档确认 Model ID 是否在支持列表里。5.4 OAuth 相关报错如果你在 OpenClaw 里配置了 OAuth 类型的鉴权可能会遇到Error: OAuth token exchange failed: invalid_grantTaoToken 的 API 用的是 Bearer Token 鉴权不需要 OAuth 流程。如果出现这个报错说明 OpenClaw 的鉴权配置写成了 OAuth 模式。把config/model.yaml里的auth_type改成bearer然后确认api_key字段直接填 Key 值即可。5.5 Skill 加载失败如果 OpenClaw 启动时报Error: Skill requirement-review not found or invalid先检查skills/requirement-review/skill.json是否存在且 JSON 格式合法可以用python -m json.tool skill.json验证再确认name字段和调用时用的 skill 名称一致最后检查model字段里的base_url和api_key_env是否配置正确。6. 语义一致 CTA把这条调用链沉淀成可复用资产整条链路跑通之后最有价值的不是某一次评审结果而是这套「Skill 定义 TDD 用例 统一 Key 接入」的模式可以复用到其他场景。比如你可以把代码审查、接口文档审查、测试用例评审都做成类似的 Skill共用同一个 TaoToken Key 和 Base URL只需要换 Model ID 和 prompt 模板。如果你还没拿到 Key可以先从模型对话页面快速验证 DeepSeek 的评审效果确认输出质量符合预期后再接入 OpenClaw。接入文档里有完整的 Base URL、鉴权方式和请求示例照着配就行。如果你打算长期跑编码和 Agent 任务Coding Plan 会更划算Key 可以复用到多个 Skill 和工具里。回到需求评审这个场景我自己的经验是Skill 的 prompt 模板需要迭代三四轮才能稳定。第一轮先跑通格式第二轮补充检查项第三轮优化严重级别判定第四轮加边界用例。每次迭代都用 TDD 用例验证确保没有回退。另外评审结果里的「严重级别」建议人工复核一遍DeepSeek 有时候会把中等问题标成高这个偏差在可接受范围内但直接拿去开会讨论可能会引起不必要的争论。最后一个小技巧把每次评审的 JSON 结果存下来积累十几份之后你可以统计哪些检查项触发频率最高反过来优化需求文档的模板从源头减少问题。这比每次评审完改文档更有效。