使用 Valiassistant 的自定义操作示例

Created: 一月 23, 2025 | Updated: 十一月 17, 2025

下面是一些可与自定义操作一起实施的脚本示例。每当显示人工智能时，脚本都会使用自定义提示，该提示与来自需求、模块或 Valis 的信息一起发送给人工智能，人工智能会分析数据并将自定义提示考虑在内，然后将答案发回需求与系统门户网站，该答案随后可写入需求与系统门户网站中的对象。请根据您的需求和用例调整这些示例脚本。

要使这些脚本在 Requirements & Systems Portal 中运行，您必须在脚本开始时的配置部分提供 API URL。请参阅此处了解如何获取 API URL。

人工智能标题建议

该脚本使用 AI 为您的个性化需求提供简短而准确的标题。

AI_Title_Suggestion.txt

使用的自定义提示是

custom_prompt = "根据文本，在系统工程的背景下，为该需求提供一个简短的标题。标题中不要包含任何数字或单位。只返回标题，不返回其他文本"。

这将与需求文本一起发送给人工智能。

人工智能需求类型建议

该脚本使用 AI 根据需求文本将需求分类为特定类型，如 "功能"、"性能 "或 "系统"。需求与系统门户设置中定义的所有类型都会考虑在内。

AI_Type_Suggestion.txt

使用的自定义提示是

custom_prompt = "只回答类型。请考虑以下类型：{types_string}。根据需求文本，将所提供的需求归类为所提供的类型之一（{types_string}）。仅以'type'的形式返回类型"。

人工智能需求质量检查

该脚本根据 INCOSE 行业标准检查需求文本的质量，并以质量标签和改进建议的形式提供定量和定性的回复。

AI_Quality_Check.txt

使用的自定义提示包括最相关的 INCOSE 规则：

custom_prompt = """
        考虑以下 INCOSE 写需求的标准：
        R1 - 使用结构完整的句子：主语、动词、宾语。 
        R2 - 在需求或要求陈述的主句结构中使用主动语态，并将责任实体明确确定为句子的主语。 
        R3 - 确保需求或要求陈述的主语和动词与需求或要求所指的实体相称。 
        建议 5--使用定冠词 "the "而不是不定冠词 "a"。
        建议 6--在陈述数量时使用适当的单位。所有数字都应明确说明计量单位。
        建议 7 - 避免使用模糊词语，如 "一些"、"任何"、"允许"、"几个"、"许多"、"很多"、"几个"、"几乎总是"、"非常接近"、"几乎"、"大约"、"接近"、"几乎 "和 "近似"。 
        建议 8--避免使用 "尽可能"、"尽可能少"、"在可能的情况下"、"尽可能多"、"如 果证明有必要"、"如果有必要"、"在必要的范围内"、"适当"、"按要求"、 "在实际可行的范围内 "和 "如果切实可行 "等省略句。 
        建议 9--避免使用 "包括但不限于"、"等 "和 "等等 "等开放式条款。 
        建议 10--避免多余的不定式，如 "旨在"、"能够"、"能够"。  
        建议 12、13、14--使用正确的语法、拼写和标点符号。
        R15 - 使用定义的约定来表达逻辑表达式，如"[X AND Y]"、"[X OR Y]"、"[X XOR Y]"、"NOT[X OR Y]"。
        R16--避免使用 "不"。 
        R17--避免使用斜体（"/"）符号，除非是在单位中，如 km/hr
        建议 18--写一个包含单一思想的单句，并以相关分句为条件和限定。
        R19 - 避免使用连接分句的组合词，如 "和"、"或"、"那么"、"除非"、"但是"、"以及"、"但是也"、"然而"、"是否"、"同时"、"而"、"另一方面 "或 "否则"。 
        建议 20--避免使用表明需要或要求的目的的短语。 
        R21 - 避免使用包含从属文字的括号和括号。
        建议 22--明确列举集合，而不是使用组名词来命名集合。 
        建议 24--避免使用代词和不定代词。
        建议 26--避免使用无法实现的绝对值，如 100'%'可靠性、100'%'可用性、所有、每一个、总是、从不等。
        建议 28--明确表达单个行动的条件命题性质，而不是针对特定条件列出行动清单。
        R29 - 根据问题或系统的各个方面对需求和要求进行分类。 
        R31 - 在定义设计输入时，除非有限制设计的理由，否则应避免陈述解决方案。重点是问题 "是什么"，而不是解决方案 "如何做"。 
        R32 - 当需要普遍量化时，使用 "每个 "而不是 "所有"、"任何 "或 "两者"。 
        R33 - 定义量值范围要与适用的实体相适应，并与要验证或确认的实体相适应。
        R34 - 提供具体的可衡量的性能目标，这些目标应与需求或要求所针对的实体相适应，并 且实体应根据这些目标进行验证。
        R35 - 明确定义时间依赖关系，而不是使用不确定的时间关键词，如 "最终"、"直到"、 "之前"、"之后"、"由于"、"一旦"、"最早"、"最近"、"瞬间"、"同时"、"最后"。
        R38 - 避免使用缩略语。
        根据 INCOSE 的这些需求标准，只需向我返回一个字典，其中包含需求文本的质量分数（从 0 到 100）以及相应的改进意见（comment_for_improvement）：
        {'Score'：quality_score_of_the_requirement_text，'Comment'：comment_for_improvement}。
        """