初次探索体验 AI 辅助需求工程

慢条斯理的小可
0 阅读6分钟

一、背景

AI 开发已成“快艇”，需求设计不能是“锚”。作为软件系统工程师（SE），我希望通过本次实践探索 AI 辅助需求工程的成熟方法论，以解决需求模糊和逻辑断层等痛点。

二、和gemini探讨方法论的过程

思考1：经验借鉴

有哪些比较成熟的已经验证的不错的AI辅助设计SRS的方法论？

    1. Spec-Driven Development (SDD) —— 规范驱动开发
    1. ReqInOne / LLM-Based RE Agent —— 代理式需求工程
    1. Gherkin-Style Behavior Driven Spec —— 行为驱动规范
    1. Enterprise GenAI Implementation Framework (RAIF) —— 企业级集成框架
方法论核心武器解决的“痛点”
SDDOpenSpec / Spec Kit代码实现与需求脱节（货不对板）
ReqInOne多 Agent 协作需求来源太杂、有逻辑漏洞
GherkinGiven-When-Then沟通成本高、测试难覆盖
EnterpriseRAG + 审计护栏不合规、难以在大团队推行

思考2：选择更适用的方法论

初步决定试用 SDD 和 ReqInOne 这两种方法论。

维度SDD (规范驱动)ReqInOne (代理驱动)
它辅助了什么？辅助**“定义”**：将自然语言标准化。辅助**“思考”**：将逻辑盲点显性化。
输出物长什么样？严谨的 Markdown/YAML 文档。结构化的问答对 + 完善后的 PRD。
什么时候用？当你已经想清楚业务，准备下发给开发时。当你只有一个大概想法，需要完善细节时。
对你的价值它是你的**“翻译官”**，把人话翻译成代码逻辑。它是你的**“辩论队友”**，帮你把逻辑漏洞堵死。

思考3：方法论结合

在实际分析设计中，这两者可以互补：ReqInOne 负责前期逻辑挖掘，SDD 负责后期规格定义。

image.png

思考4：考虑需求的关联

需求通常不是孤立的原子功能，必须考虑与既有系统的耦合。

8F4ADCFC-D876-4238-873B-8779E69BFFA8.png

思考5：需求的关联上下文太多

对于增量需求，存量文档往往非常庞大。在我的场景中，我倾向于将非关注模块作为背景，不展开其内部细节。 image.png

思考6：专注子模块

通过划定边界，仅对特定子模块进行精细化设计。

image.png

  • 在 SDD 中使用“黑盒声明”（Black-box Declaration）： 不描述基础服务的内部实现，仅定义其对外提供的保证（Guarantees）。

  • 在 ReqInOne 阶段定义“契约边界”： 明确哪些功能是现成的，不再重复设计。

  • 使用“接口存根”（Interface Stubs）建立插槽： 为子模块预留与基础服务的衔接点。

思考7：过程纪要与标准格式文档的完善

image.png 🚀 总结：我的实验工作流图

步骤模式输入AI 行为输出
第一步ReqInOne原始想法追问、质疑、压测逻辑纪要 + 完善版 PRD
第二步SDD Explore完善版 PRD补全技术细节、识别逻辑断层补充后的最终 PRD
第三步SDD Output最终 PRD结构化映射、双文档生成标准 SRS + spec.md

三、最终确定方法论：ReqInOne 与 SDD 的融合

  • 初识 ReqInOne (RE Agent)： 侧重于逻辑挖掘。AI 扮演“刁钻的需求审计员”，通过追问、挑战和边界测试，挖掘模糊想法背后的细节，实现业务逻辑“脱水”。

  • 初识 SDD (OpenSpec)： 侧重于结构化规格。AI 扮演“严谨的架构师”，在代码实现前，先定义严密的结构化文档（包含领域模型、状态机等）。

  • 最终选择：“双轮驱动模型” 。

    • ReqInOne 负责业务构思阶段的“逻辑压测”。
    • SDD Explore 负责设计深度的“逻辑补完”。
    • SDD Output 负责技术建模阶段的“规格定稿”。

四、实践：一步步将业务点子变成系统规格

前置：环境准备

  • 本地安装OpenCode

第一步：准备阶段 —— 建立“上下文锚点”与约束

  • 00_Foundation.md (基础上下文)： 明确声明既有的通用服务（如权限中心、会议模块）。

    • 关键策略：“黑盒声明” 。直接告知 AI：“假设已存在可靠的服务契约，本流程仅负责消费，严禁重新设计基座”。这有效防止了 AI 的发散。

  • 01_Original_Idea.md (原始构想)： 记录最初的业务点子。

    • 案例： “技术决策流程系统”，需支持“架构评审（同步会议+加权投票）”和“技术债裁决（异步+一票否决）”两种模式。

过程截图

Foundation

image.png

Original Idea

image.png

第二步：ReqInOne 压测阶段 —— 业务逻辑脱水与纪要存档

实践细节： 有了基础文档，我在 opencode 的 AI 面板中关联了这两个文件，并开启了 ReqInOne 模式。

  1. AI 的挑战： AI 利用其对复杂系统设计的理解，对我那简单的几行描述进行了“逻辑扫描”。它发起了 5-10 个深度追问。

    • 你可以贴出 1-2 个 AI 当时提出的硬核问题（例如：架构评审会议已经预约，发起人突然修改方案，流程怎么走？）。

  2. 存档与共识： 我将 AI 的问题和我的回答记录在 02_Logic_Log.md（探讨纪要）中。最后，让 AI 将两者的共识整合成一份**“高保真 PRD”** (03_Refined_Requirement.md)。

    • 辅助价值： 它把我的想法从“我觉得应该是这样”变成了“经过压测，逻辑是这样”。

过程截图

RegInOne逻辑挖掘

image.png

生成逻辑纪要

image.png

生成高保真PRD

image.png image.png

第三步：SDD Explore (探索) 阶段 —— 逻辑补完与规格转化

实践细节： 有了高保真 PRD 后，我不再是“聊需求”，而是“定规格”。AI 切换为 SDD 专家，启动 Explore (探索) 模式。

  1. ** Explore 的逻辑探针：** 这一次，AI 辅助的是系统设计的深度。它针对技术可行性和数据完整性进行二次探索。

    • 可以举例（例如：AI 问：‘投票通过后生效’是同步还是异步？如果生效动作失败了，决策单状态是回滚还是停留在‘已通过但异常’？）。

  2. 逻辑补完： 当 AI 发现 PRD 遗漏的内容（比如并发处理、异常回滚），它会提供技术选项让我选择。通过 Explore 模式，我在设计阶段就把这些“屎山潜质”给清理干净了。

过程截图

SDD Explore

image.png

生成SRS

image.png

第四步：输出阶段 —— SRS + spec.md 双文档生成

实践细节： 当逻辑完全闭环后，AI 最终输出两份文档：

  1. 标准 SRS (IEEE 标准需求规格说明书)： 给人读的，包含所有的业务场景补充。
  2. spec.md (OpenSpec)： 给机器/开发读的，侧重于领域模型 (Domain Models) 表格定义、状态机 (State Machine) 流程描述。

过程截图

生成spec.md

image.png

image.png

五、总结

通过本次实验，我成功建立了一套从原始想法到“高精度”规格文档的 AI 辅助工作流。ReqInOne + SDD 的组合不仅提升了设计效率，更通过“主动挑战”和“形式化探索”显著降低了后期返工的风险。

备注说明： 本实践内容仅作为体验 AI 辅助需求设计流程的演示，旨在验证工作流的闭环性。文中涉及的业务逻辑、技术定义及文档内容均为实验性质，暂未考究其在真实生产环境中的严谨性与准确性，仅供参考。

avatar
文章
阅读
粉丝