如何让AI 帮你找出技术文档中的Bug

      在之前发布的文章中，我们主要讨论了业务需求如何分析以及如何找出其中存在的隐形缺陷，这对任何一个项目，都是非常有用的。今天我们讨论的主题是技术需求如何分析以及发现潜在的缺陷。

      业务需求分析的六个维度（主要维度）在技术需求的分析中，已经不再适用，但每个项目都会涉及到技术需求，我们又该如何使用AI 进行高效分析呢？

      类似业务需求分析的方法，对于技术需求，我也总结了四个维度：即：实体、相关的约束、生命周期状态以及级联影响这四个维度进行分析。当然这四个也只是抽象出的主要维度，还可以扩展更多。

      按照之前的套路，我们将这四个维度输入给AI ,然后让AI 将一个技术需求通过这四个维度进行分析，AI 会给出一个分析的结果。但这个结果，还需要技术人员进行判断和修订的。如果哪方面分析得不足，就可以借机补充上。比如一个可以进行税率配置的技术需求，我们是否考虑了在途数据，是否考虑了回滚方案，它的状态从草稿到修改，到再次生效，中间有多少种状态，是否考虑全面等等。修订完的技术需求分析将成为“技术需求基线”。

      但很多情况下，对于技术需求，技术人员不写需求文档，直接写了设计文档。那么对于这类技术文档，我们该如何进行分析呢？这里又要用到需求反向工程这个逻辑。

      我们先用这个设计文档，通过AI 反推出隐含的技术需求文档，再用这个推导出技术需求文档，按照四个维度，进行分析，再次输出技术需求分析文档，并进行人工确认。这个过程可以帮我们查看哪些需求已经有了，哪些需求并未考虑到, 任何缺失的需求可以补上，任何冗余的设计也会及时发现。

      经过技术人员对AI 输出的技术需求分析确认后，则为“技术需求基线”。让AI根据这个基线，输出技术版本的use case。不同于业务场景的use case, 技术use case 主要说明系统内部组件（服务/模块/数据实体）之间的交互与数据流转过程。

      同理，技术人员需要再次对这个use case 进行确认，形成“技术use case基线”，它将系统的正常和异常流程都充分展示了。这极大弥补了人的抽象能力不足的问题。任何技术上尚未考虑到的点，或考虑错了的点，都会一览无余。

    这时再次使用需求反向工程，让AI根据use case 基线反推出设计文档。这时生成的设计文档，我们称之为标准的“技术设计文档”。对照原有的设计文档，所有的缺陷遗漏完全暴露，只有标准的设计文档，才应该是系统实现的参考物。

      这个过程，我们借助AI，同时对需求和设计进行了两次校验，AI 既帮助我们找到了抽象的需求的缺漏，也帮我们找到人工难以发现的设计的缺失，真是一箭双雕。让发现的问题不流入开发环节，这将极大地节省了后续处理的返工成本。

      因此，无论技术需求文档有没有，设计文档有多烂，只要让AI 按照科学的方法参与分析和推导， 就能帮我们实现人工无法实现的缺陷反查，极大地提升技术设计的质量。

     建议每一个项目的设计评审，都让AI参与缺陷反查，它将全面提升各阶段的输出质量，对整体项目的成功不可或缺。