基于 OpenClaw+DeepSeek 实现需求评审的技能开发与实践

为助力客户精准识别需求文档中的问题，我尝试通过安装 OpenClaw 并编写专属 Skills，结合 DeepSeek 大模型实现需求的智能化语义评审，整个实现流程与实践心得如下。

一、需求评审 Skills 的开发与落地流程

• 采购 DeepSeek 的 API key 相关资源，完成大模型调用的基础准备；
• 搭建 OpenClaw 的完整运行环境，保障工具正常运转；
• 完成 OpenClaw 与 DeepSeek 的接口配置，实现二者的联动对接；
• 编制需求评审的检查清单（checklist），明确评审核心维度；
• 撰写需求评审 Skills 的开发需求，界定技能功能与执行标准；
• 依托 OpenClaw 工具自动生成对应的 Skills 代码；
• 对生成的 Skills 进行调试，检验评审结果输出效果，并通过 OpenClaw 持续优化 Skills 中的算法逻辑；
• 完成 Skills 版本的稳定化迭代，投入长期的实际业务使用。

在上述全流程中，编制评审 checklist 与撰写 Skills 开发需求是两大核心环节，一份科学完善的检查清单和清晰明确的技能开发需求，直接决定了后续智能化需求评审的质量与效果。

二、融合 checklist 的 Skills 开发核心需求

我将需求评审 checklist 全面融合至 Skills 开发需求中，明确了大模型执行需求评审的全流程规则、检查维度与输出标准，具体要求如下：

1、Skill 总体目标：针对输入的需求文档，大模型参考预设检查项开展语义评审，精准识别文档中的问题。支持用户指定局部和完备两种评审方法，满足不同评审场景需求。

2、评审模式识别规则：评审前先判定用户指定的模式，若为完备评审，需对所有预设需求元素进行全面检查，未被完备描述的需求元素直接标注为遗漏问题；若为局部评审，仅对用户指定的需求元素开展评审，未涉及的元素不认定为问题。缺省评审模式为局部模式。

3、语义匹配要求：需求文档中的章节名称可能与预设需求元素名称不一致，或无显式标注，大模型需通过语义分析实现需求元素的自动匹配。

4、真实接口集成：对接真实的大模型 API，实现真正意义上的智能化语义评审，而非模拟评审。

5、通用检查项（全场景适用）：无论采用局部 / 完备评审模式，无论评审对象是新需求还是需求变更，均需执行以下通用检查：

1）名词：能否准确识别所有业务对象的属性？无其他名词修饰的名词为属性，有其他名词刻画特征的名词为业务对象；

2）动词：所有动词的执行流程需有详细描述，明确操作方式与步骤；

3）形容词与副词：此类词汇具备不可测试性，出现时需直接列为问题；

4）代词：需结合上下文明确指代关系，确保无歧义；

5）术语一致性：梳理含义相近的词语，列出并提请作者澄清是否指代同一含义。

6、需求元素专属检查项：对需求文档中的不同需求元素，大模型需分别匹配对应的检查项开展针对性评审，核心元素及检查要求如下：

需求元素 1（项目目标）：是否明确阐述项目具体目标？是否清晰说明要解决的核心问题？是否描述系统的业务价值？

需求元素 2（业务概述 / 业务背景）：是否列明系统用户的所有角色？是否通过流程图或文字描述业务流程？是否明确用户角色、业务活动、业务单据 / 账本 / 报表之间的关联关系？

需求元素 3（系统概述）：是否介绍系统总体功能？是否清晰界定系统范围，明确系统的功能边界（做什么 / 不做什么）？是否描述功能模块划分及各模块包含的具体功能？

......

需求元素 11（非功能需求）：是否对所有非功能性需求进行定量描述？是否包含响应时间、吞吐量、数据量、并发用户数、安全性、可靠性、可移植性等核心维度？

需求元素 12（环境需求）：是否完整描述软件、硬件、网络的配套环境需求？

7、需求变更附加检查项：从是否修改历史功能的角度，需求可分为新需求和变更需求。若为变更需求，需额外检查：是否明确变更前、后的需求内容？是否界定变更类型（业务规则、业务对象、操作方式、界面布局等）？

8、综合质量评分：完成评审后，对需求文档的综合质量进行评分，满分设定为 100 分。

9、输出格式要求：评审结果以 Excel 表格输出，包含两个工作表，具体列项如下：

sheet1（问题列表）：问题序号、问题描述、原始需求描述、对应的检查项、严重级别；

sheet2（综合评价）：问题个数、综合评分及其他相关统计分析内容。

三、Skills 开发调试中的 AI 编码常见问题

在完成 Skills 需求定义后，通过 OpenClaw 实现代码编程，并开展持续调试优化，过程中针对 AI 的评审遗漏问题进行纠正并反复迭代，持续完善 Skills 开发需求。在此过程中，总结出 AI 编码存在的八大常见错误，需重点规避：

• 代码中出现无注释说明的魔法数字，降低代码可读性与维护性；
• 代码中硬编码固定文件名，将模拟用的输入内容直接写死，灵活性极差；
• 存在漏修改问题，例如指定修改 4 个 bug，实际仅完成 3 个的修改；
• 多 bug 修改时出现回退问题，修改后续 bug 时，已修复的前期 bug 被重新还原；
• 同一文件的不同版本未在文件名上做区分，导致大模型误将老版本当作新版本，拒绝接受新代码；
• 未对程序需求进行版本记录，需求迭代过程无追溯性，大模型易混淆版本，导致老错误复现；
• 过度依赖调试修改，忽视前期设计，最终陷入修改泥潭，代码越改越乱；
• 出现人类编码极少犯的低级错误，因未理解需求中的潜台词，导致代码逻辑与实际需求偏离。

针对上述问题，TDD 开发模式对 AI 编码尤为适用，每次 AI 编码完成后，需通过所有测试用例再进入下一环节；同时需明确，程序是设计出来的而非调试出来的，AI 编码也应追求一次成型；若陷入修改泥潭，需基于最新、最完备的需求重新编写代码；且 AI 编写的代码必须经过严格的人工评审，确保需求落地准确性。

四、需求评审实践效果：DeepSeek 智能化评审的优势

为验证 Skills 的实际评审效果，我以一份自主编写的、相较于实际业务中多数项目更详尽清晰的个人名片管理系统需求文档为测试对象，通过 DeepSeek 开展智能化需求评审，最终识别出 17 类具体问题，覆盖项目目标、系统概述、功能设计、数据对象、环境需求、术语规范等多个维度，核心问题及评审标准匹配情况如下表所示：

从评审结果可以看出，即便这份需求文档已具备较高的详尽度，DeepSeek 仍识别出了大量人工评审易忽略的细节问题，其评审过程更细致、全面、完备，能够从多维度、全视角挖掘需求文档中的潜在问题。

当然，智能化评审识别出的问题并非强制修改，最终可由需求文档的作者结合实际业务场景，自主决策问题的整改方式与整改优先级。