智能体驱动的需求工程

• Break Down Complex Requirements – 分析所选需求，并在保留原始意图的同时，将其拆分为更小且可独立测试的需求。

  提示词示例：

  Break down these requirements.

• Apply Requirement Writing Standards – 审查需求，并根据您组织的需求编写指南进行改写。典型检查项包括歧义、不可验证的表述、缺失的执行主体以及不明确的验收标准。

  提示词示例：

  Rewrite these requirements according to our requirement quality standard.

• Translate Requirements – 将需求从一种语言翻译为另一种语言，同时保留技术含义、术语、ID 和可追溯性引用。

  提示词示例：

  Translate these requirements to German.

• Classify Requirements – 将组织的分类体系应用于需求，例如电子、机械、软件、安全性、信息安全或其他公司特定的分类体系。

  提示词示例：

  Classify these requirements according to our applicability model.

• Generate Verification Criteria – 分析需求，并提出验证方法、验收标准或测试条件，以始终采用一致的方式证明符合要求。

  提示词示例：

  Generate verification criteria for these requirements.

• Summarize a Specification/Section/Group of Requirements – 为规格说明、需求章节或需求集生成简洁且结构化的摘要。

  提示词示例：

  Summarize the selected requirements.

好的技能可帮助 AI 理解两件事：

• 何时应使用该技能

• 技能运行时 AI 应执行什么操作

定义技能时， 

这些内容通过三个字段表达，每个字段各有不同的用途：

• Name – 帮助您识别技能。

• Short Description – 帮助 AI 判断该技能何时适用。

• Instructions – 定义选中该技能后 AI 应遵循的行为。

有关各字段的详细信息，请参阅以下各节。

名称

Name 应简短、清晰，并以操作为导向。它应帮助您快速理解技能的用途。好的名称通常会描述技能执行的操作及其处理的工程数据类型。

好的技能名称应：

• 足够具体，能够与其他技能区分开来

• 足够简短，便于在技能列表中快速浏览

• 聚焦于技能执行的主要任务

• 使用用户易于理解的自然语言

避免使用过于宽泛或笼统的名称。如果某个名称可以用于许多不同的任务，那么它很可能不够具体。

简短描述

Short Description帮助 AI 理解该技能的用途及其触发时机。此字段很重要，因为您无需手动选择技能。助手会分析您的提示词，将其与可用技能进行比较，并判断某项技能是否适用。

好的简短描述应说明：

• 该技能执行什么任务

• 该技能适用于哪类工程数据

• 何时应使用该技能

• 该技能预期产生什么结果

简短描述应简洁，但不能含糊。它应包含足够的上下文，以便 AI 将此技能与类似技能区分开来。

不够好的简短描述只说明技能所属的领域。好的简短描述则会说明具体任务、预期的使用背景以及触发情形。例如，不要仅将某项技能描述为“协助处理需求”，而应说明该技能是审查需求质量、分解复杂需求、翻译需求文本、检测冲突、生成验证准则，还是执行其他具体操作。

简短描述越能清楚地说明技能的用途和使用场景，助手就越能可靠地判断何时应用该技能。

指令

Instructions定义了选中技能后 AI 应执行的操作。这是控制技能行为最重要的字段。简短描述帮助 AI 判断何时使用技能，而指令则定义技能应如何运行。

好的指令应以清晰的分步指导形式编写，不仅应描述最终输出，还应说明 AI 在生成该输出时应遵循的推理过程和约束。

指令应说明：

• What the AI should analyze first – 助手通常应先理解工程意图、上下文、结构或关系，再进行任何修改或生成操作。

• What steps the AI should perform – 应将行为拆分为明确的步骤，使输出具有可重复性和可预测性。

• What the AI should preserve – 这可能包括原始意图、需求 ID、技术术语、单位、数值、约束、引用、适用范围、层级结构或可追溯性上下文。

• What the AI must not do – 好的技能会明确禁止 AI 编造缺失的工程细节、改变意图、引入新的假设，或未经用户审查就应用更改。

• How the AI should handle uncertainty – 如果信息缺失、含糊不清或不充分，技能应指示 AI 清楚地说明问题，而不是猜测。

• What output format is expected – 技能应定义结果应采用表格、项目符号列表、改写文本、摘要、检查清单还是结构化报告的形式。

好的指令对于工程工作尤为重要，因为助手处理的数据可能影响规格、验证、设计决策或下游实施。因此，技能应引导 AI 在提供帮助的同时避免过度自信。

其他注意事项

• 目标不是编写冗长的提示词，而是为 AI 定义清晰的操作流程。

• Keep Skills Focused

  一项技能应专注于做好一项可重复执行的任务。

  如果一项技能试图执行过多操作，助手就更难判断何时使用它，用户也更难信任其输出。例如，一项技能不应将需求分解、翻译、质量审查、可追溯性分析和验证内容生成混在一起，除非这些操作本就是同一个明确定义且紧密衔接的工作流的一部分。

  如果技能的用途涉及多项互不相关的操作，应将其拆分为独立的技能。

• Define Boundaries Clearly

  好的技能会明确界定边界。

  在处理需求、规格和工程数据时，这一点尤为重要。助手应清楚哪些内容可以修改，哪些只能提出建议，以及哪些绝不能自行假定。

  实用的边界包括：

  • 不得改变原始工程意图

  • 不得编造数值、约束或设计决策

  • 不得删除 ID 或引用

  • 不得自行假定缺失的验证方法

  • 未经用户审查，不得自动应用更改

  • 不得将不明确的信息视为事实

  清晰的边界可降低生成看似合理但实际错误的工程输出的风险。

• Define the Output Format

  技能应告知 AI 如何返回结果。

  一致的输出格式可使技能更便于审查、比较和复用。

  根据技能的不同，输出可以是：

  • 表格

  • 项目符号列表

  • 改写后的需求

  • 结构化报告

  • 检查清单

  • 摘要

  • 建议更改列表

  • 一组问题或待解决事项

  输出格式应与技能的用途相匹配。例如，审查类技能通常适合采用包含问题、说明和建议列的表格。改写类技能通常适合同时展示原文、建议文本及修改理由。