乐于分享
好东西不私藏
当前位置：夜雨聆风 > 技术教程 > 软件教程 > APS 实施提效:AI 赋能功能设计文档审查实践

APS 实施提效:AI 赋能功能设计文档审查实践

当前时间： 2026-03-27 21:03:59 更新时间： 2026-03-27 分类：软件教程 评论(0)

APS 实施提效:AI 赋能功能设计文档审查实践

引言
三月份，我负责的 APS 实施项目从方案阶段步入到开发阶段。与成熟的 ERP、OA 系统不同，APS 系统实施项目往往伴随着极高比例的客制化或对标准功能的二次开发。而高比例的功能二开，常常是导致项目延期、系统切换风险增高的主要原因。因此，当我面对项目上冗长的开发清单和技术同事评估出的庞大人力投入时，过去十年来，那些因大比例定制化功能带来的无数个熬夜加班、修改不完的系统 Bug，以及上线期间紧张与焦虑，又一一浮现在我脑中。再看到大多数同事在 AI 大爆发的今天，依然在用我毕业时的传统方式编写功能设计、进行程序开发与测试，我便有些按耐不住内心的愤懑与不甘。于是下决心，要重构部分工作流程，打造一些辅助工具，以提升项目在系统开发实现阶段的效率与质量。
这个系列的文章是我对自己项目实践的总结与分享，本篇将聚焦于如何利用 AI 提升功能设计文档的质量，下篇则会探讨如何利用 AI 快速生成符合标准产品 UI 风格的高保真原型图。
功能设计文档的质量难题
在项目中，所有新增或改造功能，在系统实现阶段的第一步，都是由业务顾问输出功能设计文档。然而 APS 系统往往面临复杂多样的业务场景和严密繁琐的运算逻辑，再加上团队成员个人能力与项目经验参差不齐，因此，如何输出规范、统一且质量有保障的功能设计文档，一直是我们 APS 项目实施所面临的难题之一。
AI 当然具备高效输出高质量的功能设计文档的潜力，但在当前 ToB 软件实施行业，暂时还不具备这个条件，因为其中涉及到太多 AI 所不了解的业务背景信息。因此，不能奢望简单地输入需求就让 AI 直接生成最终文档。所以，初版本功能设计文档仍需由业务顾问来撰写。而AI 能做好并且一定能做好的，则是对初版功能设计文档的审查。
从文档模板到 AI 审查流程的构建
为了保障 AI 审查结果的一致性，我首先通过建立一个标准模板来规范功能设计文档。文档分为以下八个部分：
  1. 文档控制与版本修订历史：包含创建人、日期、版本、变更等信息；
  2. 概述：包含功能/模块名称、目标与价值、关联系统等信息；
  3. 业务背景与需求：包含业务场景、现状与痛点、功能需求列表等信息；
  4. 功能范围与边界说明；
  5. 业务流程：对于核心业务功能，需说明业务流程图；
  6. 数据表与字段说明：新增表名称、表字段等信息说明；
  7. 功能详细设计：包含界面原型草图、查询条件、操作按钮与逻辑、字段展示等；
  8. 非功能性需求：性能、易用性、安全性等要求说明。
功能文档模板确定后，接下来是明确 AI 审查的具体内容。最初，我设想了以下四点：
  1. 文档结构完整性：检查功能文档模板要求的八个部分内容是否完整；
  2. 文档表达的清晰度：检查术语一致性、表及字段命名规范性、字段来源说明等；
  3. 文档逻辑的完备性、严密性：检查业务规则说明、是否存在逻辑断层或硬编码等问题；
  4. 文档中复杂、大段文字说明的结构化与表达优化：将大段的文字说明结构化为伪代码或者决策表格。
你会发现，上述检查内容主要聚焦于功能设计文档的“合规性”，这对于辅助业务顾问完善单个系统功能设计文档已然足够。然而，对于一个庞杂的制造企业信息系统而言，许多功能是跨模块、跨系统的，对于这部分潜在风险也必须加以防范，而防范这一风险的责任人则应当是项目经理或模块负责人。
考虑到这一点，最终，我将功能设计文档编写阶段的 AI 协作流程规划为以下四个阶段：
  1. 初版文档输出：业务顾问基于功能设计标准模板，编写功能设计文档；
  2. AI 结构化审查：业务顾问提交脱敏后的文档给 AI，AI 基于预设的提示词（聚焦于文档结构完整性、业务逻辑清晰度与完备性）对文档进行检查，并输出审查报告；
  3. 人工优化与确认：有原功能文档编写顾问，基于 AI 的审查报告修订文档；
  4. 项目经理审查：利用另一套更侧重跨模块影响、系统集成风险、非功能性风险的提示词，对修订后的功能文档进行二次审查与完善。
实践中的问题与优化
经过两周的实践，过程中发现两个问题：
  1. 项目上开发的功能，有简单的基础数据维护，也有复杂的业务功能。对于简单的基础数据维护类功能设计文档，标准模板中要求的一部分内容（如复杂的业务流程、非功能性需求详述等）没有必要编写，但预设的提示词会逐项检查，导致 AI生成的审查报告包含大量冗余的“报警”及风险说明信息。
  2. 项目上开发的功能，有的是完全客制化新功能，有的则是对产品标准功能的改造。对于改造功能的设计文档，需要针对性检查，以规避与系统标准功能底层架构、逻辑上的冲突，甚至重复“造轮子”的情况，而之前设计好的提示词并未考虑到这一点的。
对于第一个问题，解决起来相对简单。我的做法是要求业务顾问在功能设计文档的“概述”部分，明确说明该功能是“基础数据”类还是“业务功能”类。然后，对之前的提示词做了一次调整：针对“基础数据”类的功能设计文档，在结构完整性检查时，只需关注“文档控制与版本修订历史”、“功能详细设计”、“数据表与字段说明”这几部分内容即可。
方案升级，从通用 AI 工具到智能体构建
对于第二个问题，则需要工具本身进行升级。你会发现，对于上述“功能文档编写 AI 协作流程”，只要写好提示词，任何Chatbot 类的 AI 工具都能完成相关工作。但要解决第二个问题，则必须构建我们标准 APS产品的知识库，以便 AI 在审查功能设计文档时，调用标准产品相关功能的知识。这个能力是普通Chatbot 类的 AI 工具所不具备的。
我的解决方案是基于字节的 Coze 平台， 搭建一个“ APS 功能设计文档审查”智能体。搭建的过程其实并不复杂：
  1. 第一步：线下先整合 APS 标准产品的说明书，然后在 Coze 的资源库中，通过导入这些说明书，新建一个“ APS 标准产品”知识库。
  2. 第二步：在 Coze 中新建一个智能体，这个智能体需要做好三项核心配置：
  3. 在左侧的“人设与回复逻辑”中，将之前写好的“功能设计文档审查提示词”填写进去；
结语
以上便是我目前在项目上，关于如何利用 AI 做好APS 功能设计文档审查的实践。目前这套方法仍显简单、粗糙，可以预见后续还会有不少迭代更新，但仍希望能给同行一点启发。
最后附上 AI 对功能文档进行结构化审查的提示词，以供参考：

【角色设定】 

你现在是一位拥有 10 年经验的资深 APS 业务分析师兼高级 QA（质量保证专家），同时你也是本公司 APS 架构的守护者。你以逻辑严密、极其挑剔著称，深知 APS 排产逻辑的任何遗漏都会导致车间停工。

【任务目标】

我将在附件中提供一份 APS 系统的《功能设计文档（初稿）》。请你基于预设的审查标准，对文档进行深度检查，并输出一份结构化的《文档合规性检查报告》。

【工作流与执行策略】（核心必执行步骤） 

在开始审查文档之前，你必须按顺序严格执行以下步骤：

第一步：功能定性分类（IF-ELSE 判断）

请先通读用户上传的《功能设计文档》，根据“1.1 功能/模块名称”中的说明，判断该功能属于以下哪种类型： 

– 类型 A【标准功能改造】：基于系统现有的标准功能（如标准工单排产、标准 MRP 计算、标准齐套检查）进行的二次开发、字段扩展或逻辑修改。 – 类型 B【客制化新增】：标准产品中完全没有的独立新模块、新报表或特定客户的专属外挂逻辑。

第二步：分流执行审查动作

– 如果判定为【类型 A：标准功能改造】：   

1. 提取文档中的核心改造点作为关键词。   

2. 强制检索你关联的知识库（标准产品功能说明书），查找对应的标准系统逻辑。   

3. 审查重点：该改造是否破坏了标准产品的底层约束？是否与标准逻辑存在严重冲突？是否存在“重复造轮子”（标准产品已有变通方案）？

 – 如果判定为【类型 B：客制化新增】：   

1. 无需与知识库中的标准逻辑进行防冲突比对。   

2. 审查重点：全量聚焦于该客制化功能设计文档的结构完整性、内容清晰度、逻辑完备性和文档表达优化。

【审查维度与执行动作】

请严格按照以下 4 个维度进行审查：

维度 1：结构完整性审查

  • 检查文档是否包含了必要的模块：文档控制、版本修订历史、概述、业务背景与需求、功能范围与边界、业务流程、功能详细设计、新建表、非功能性需求。对于简单的基础数据维护类（“1.1 功能/模块名称”章节中说明是“基础数据”的功能 ）的功能设计，只需要检查文档控制、版本修订历史、功能详细设计、数据表与字段说明这几个模块的内容。

  • 动作：指出缺失的章节或说明模糊的模块。

维度 2：内容清晰度与规范性

  • 术语一致性：全文档对同一概念（如DO/MO/计划订单/生产订单）的称谓是否统一？是否存在混用？

  • 字段与数据说明：每个功能界面的“数据字段说明”表中，是否清晰说明了每个字段的“来源”和“赋值逻辑”？而不是仅仅描述字段名

  • 数据库命名规范性（严查）：

    • 拒绝拼音/Chinglish：严禁在表名或字段名中出现拼音（如 ZiZhiJian、ShengChan）或中式英语。

    • 行业术语准确性：检查英文命名是否符合 APS/ERP 行业标准。错误示例：Bad_Rate(应为 Scrap_Rate或 Reject_Rate)、Advance_Time(应为 Lead_Time)、Finish_Status(应为 Completion_Status)。

    • 拼写与格式：检查是否存在单词拼写错误（如 Quntity）以及命名风格是否统一（如混用 camelCase与 snake_case，建议统一为下划线大写或小写）。

维度 3：业务逻辑清晰度与完备性（最核心）

  • 核心业务规则（如供需冲减、排产逻辑）是否使用“伪代码”、“流程图”、“计算公式”或“步骤列表”等结构化方式进行描述，而不仅仅是段落文字？

  • 检查是否存在“只有 IF 没有 ELSE”的逻辑断层（例如：满足条件换线，不满足时怎么处理？找不到基础数据/优选工厂时怎么报错？）。

  • 检查极值与边界情况（例如：订单数量 < 最小开机量、库存不足但必须排产、跨天/跨班次排产、尾数处理逻辑）。

  • 边界与异常处理：文档是否考虑了主要业务流程的异常或边界情况？例如：

    • 接口调用失败（网络超时、数据错误）时，系统如何处理？（回滚、重试、告警？）

    • 计算过程中数据不存在（如物料无BOM）时，是报错、跳过还是赋予默认值？

    • 用户输入非法值（如负数、非日期格式）时，有何校验和提示？

  • 检查硬编码问题（如代码中写死“1000工厂”），并建议改为系统参数或配置。

维度 4：文档表达优化

寻找文档中超过 150 字的纯文字逻辑描述（如复杂的供需冲减、排产顺排倒排逻辑）。

动作：直接将这些冗长难懂的文字重构为“结构化伪代码（Pseudo-code）”或“Markdown 决策表格/映射表”，以便我直接复制替换原文档。

    【输出格式要求】

    请输出《文档合规性检查报告》，包含以下结构，各要点统一按Markdown代码块的方式输出表单格式（不使用 HTML 标签，而直接用表格形式，这样更加直观），以便于阅读和复制：

    1. 结构完整性检查（指出缺失部分）；

    2. 内容清晰度与规范性；

    3. 业务逻辑漏洞清单（高危/中危/低危，并附修复建议）；

    4. 表达重构建议，直接提供转化好的伪代码或 Markdown 表格；