提示工程架构师必备：AI提示系统用户需求分析的4个核心文档（模板+案例）

关键词：提示工程架构师, AI提示系统, 用户需求分析, 需求文档模板, 提示模板设计, 验收标准, 需求规格说明

摘要：在AI提示工程蓬勃发展的今天，提示工程架构师作为连接用户需求与AI能力的核心角色，其核心任务之一便是精准捕捉并转化用户需求。本文将揭秘提示工程架构师必备的4个核心需求分析文档——用户需求说明书（URS）、提示系统需求规格说明书（SRS）、提示模板设计文档（PDD） 和验收标准与评估文档（ASD），通过生活化比喻、详细模板和实战案例，让你像搭积木一样掌握从“用户想要什么”到“AI如何实现”的全流程方法论。无论你是资深架构师还是AI领域新人，读完本文都能系统掌握提示系统需求分析的“说明书”，让你的AI提示系统真正“懂用户、解难题”。

背景介绍

目的和范围

想象你是一家“AI魔法餐厅”的主厨（提示工程架构师），客人（用户）走进来说：“我想要一道又甜又酸的菜，适合夏天吃”。如果你直接冲进厨房做了一道糖醋排骨，客人可能皱眉：“我是素食主义者啊！” 这就是没有做好用户需求分析的后果——AI提示系统就像这位主厨，若不能精准理解用户需求，再厉害的“厨艺”（提示工程技术）也做不出“客人满意的菜”。

本文的目的就是给你一套“点餐-做菜-品菜”的全流程文档工具，确保你做的“AI菜” exactly 符合用户口味。范围涵盖从用户需求收集到提示系统验收的全生命周期，聚焦4个核心文档的设计思路、模板结构和实战案例，不涉及具体算法代码（除非必要），而是专注于“如何把模糊需求变成可落地的提示工程方案”。

预期读者

• 提示工程架构师：需要系统化方法论的核心设计者
• AI产品经理：负责需求转化与产品落地的桥梁角色
• AI应用开发者：需要编写高质量提示模板的一线工程师
• 企业AI负责人：关注AI系统交付质量与用户满意度的管理者
• AI初学者：想入门提示工程并建立系统化思维的同学

文档结构概述

本文就像一本“AI需求分析说明书的说明书”，共分为6大部分：

1. 背景介绍：为什么需求分析对提示工程如此重要
2. 核心概念与联系：4个核心文档是什么、像什么、如何协作
3. 核心文档模板与案例：每个文档的具体结构、填写指南和实战案例
4. 实际应用场景：不同领域（客服/教育/医疗）如何应用这些文档
5. 工具和资源推荐：提升需求分析效率的“神兵利器”
6. 总结与思考题：回顾核心知识点并激发深度思考

术语表

核心术语定义

术语	通俗解释	专业定义
提示工程	教AI“怎么说话”的艺术	通过设计高质量提示词（Prompts）引导AI模型生成期望输出的工程化方法
提示系统	AI的“大脑操作手册”	由提示模板、上下文管理、动态调整规则等组成的系统化提示解决方案
用户需求分析	听懂用户“弦外之音”	通过访谈、调研等方式，将用户模糊需求转化为清晰、可执行目标的过程
提示模板	AI的“剧本模板”	预定义的提示词结构，包含固定指令、变量占位符和格式约束，用于标准化AI交互

相关概念解释

• 用户需求（User Needs）：用户“想要解决的问题”，比如“我希望AI能帮我写周报”（通常模糊、主观）。
• 系统需求（System Requirements）：提示系统“必须具备的能力”，比如“AI需识别周报中的关键工作项并生成结构化摘要”（具体、可量化）。
• 提示工程架构师：连接用户需求与AI能力的“翻译官+设计师”，负责将用户需求转化为提示系统可实现的方案。

缩略词列表

• URS：User Requirement Specification（用户需求说明书）
• SRS：System Requirement Specification（提示系统需求规格说明书）
• PDD：Prompt Design Document（提示模板设计文档）
• ASD：Acceptance Standards Document（验收标准与评估文档）
• AI：Artificial Intelligence（人工智能）

核心概念与联系

故事引入：为什么“猜需求”会让AI系统翻车？

小明是一家科技公司的提示工程师，接到任务：“设计一个AI旅游助手，帮用户规划周末短途旅行”。他没做需求分析，直接写了提示词：“你是旅游助手，请为用户规划周末旅行”。结果用户问：“我带爸妈和3岁宝宝，想去人少、有轮椅通道的景点”，AI却推荐了“徒步登山路线”——因为小明没考虑“家庭出行”“无障碍需求”等用户隐含需求。

后来小明学了需求分析方法，先和用户聊了1小时，记录下“带老人小孩”“无障碍设施”“车程<2小时”等需求，再设计提示系统，AI推荐的“城市公园+亲子乐园”方案让用户赞不绝口。

这个故事告诉我们：提示工程的“地基”是用户需求分析，而4个核心文档就是打地基的“四大工具”。

核心概念解释（像给小学生讲故事一样）

核心概念一：用户需求说明书（URS）——“客人的点餐单”

URS就像你去餐厅时给服务员的“点餐备注”：“我要一份番茄炒蛋，不要香菜，少放盐，米饭换成杂粮饭”。它记录用户“想要什么”，包括用户是谁、遇到什么问题、期望AI做什么（甚至不做什么）。

生活例子：妈妈让你买水果，你问：“买给谁吃？（用户）想吃甜的还是酸的？（需求）有没有过敏的？（约束）”——这些问题的答案写下来，就是URS。

核心概念二：提示系统需求规格说明书（SRS）——“后厨操作指南”

URS是“客人要什么”，SRS则是“后厨怎么做”。比如餐厅接到“不要香菜的番茄炒蛋”订单后，SRS会写：“1. 选用成熟番茄3个（不选青番茄）；2. 鸡蛋2个，打散后加少许盐；3. 炒制时不加香菜，盐量比标准少1/3；4. 杂粮饭用小米+燕麦（比例1:1）”。它把用户需求转化为AI系统的“技术指标”，包括功能需求（AI能做什么）、非功能需求（AI做得多好，如响应速度）、约束条件（如必须用中文回答）。

生活例子：学校运动会要办“亲子接力赛”，URS是“家长和孩子一起跑步，好玩又安全”，SRS则是“1. 跑道长度50米（孩子跑20米，家长跑30米）；2. 交接棒用海绵棒（防受伤）；3. 每队4组家庭（控制时间）”。

核心概念三：提示模板设计文档（PDD）——“菜谱模板”

有了SRS（操作指南），厨师需要“菜谱模板”确保每次做的菜味道一致。PDD就是AI的“菜谱模板”，规定提示词的固定格式、变量位置和动态调整规则。比如番茄炒蛋的菜谱模板：“【食材】番茄{数量}个，鸡蛋{数量}个，盐{克数}克；【步骤】1. 番茄切块→2. 鸡蛋打散→3. 热油炒鸡蛋→4. 加入番茄翻炒→5. 加盐出锅”。

生活例子：生日贺卡模板：“亲爱的{朋友名字}，祝你{年龄}岁生日快乐！愿你{祝福内容}——爱你的{你的名字}”。这里的{朋友名字}就是“变量”，PDD会定义变量怎么填、填什么范围。

核心概念四：验收标准与评估文档（ASD）——“美食评分卡”

菜做好了，怎么知道是否符合客人要求？ASD就是“评分卡”，比如：“1. 番茄炒蛋是否无香菜（√）；2. 盐量是否偏少（尝后确认√）；3. 杂粮饭是否按比例（小米:燕麦=1:1，√）”。它明确“如何判断AI系统是否合格”，包括评估指标（如准确率、用户满意度）、测试用例（具体问题及预期输出）、评估方法（人工打分还是自动化测试）。

生活例子：老师批改作业的“评分标准”：“1. 字迹工整（20分）；2. 答案正确（50分）；3. 步骤完整（30分）”——这就是ASD的简化版。

核心概念之间的关系（用小学生能理解的比喻）

这4个文档不是孤立的，而是像**“做蛋糕”的四个步骤**，环环相扣：

URS → SRS：客人点餐单→蛋糕师备料单

URS（点餐单）写“我要一个草莓蛋糕，6寸，低糖”，蛋糕师（提示工程架构师）根据这个写SRS（备料单）：“1. 蛋糕胚：6寸戚风蛋糕（低糖配方：糖50g）；2. 夹层：新鲜草莓200g（切半）；3. 奶油：淡奶油300g（加糖20g）”。URS是SRS的“老板”，SRS必须严格按URS的要求来写。

SRS → PDD：备料单→蛋糕制作模板

有了备料单（SRS），就可以设计“蛋糕制作模板”（PDD）：“【底层】蛋糕胚1片→【夹层】草莓100g+奶油50g→【中层】蛋糕胚1片→【夹层】草莓100g+奶油50g→【顶层】奶油200g抹平，表面摆5颗完整草莓”。SRS是PDD的“图纸”，PDD要把SRS的技术指标转化为可重复的“提示模板步骤”。

PDD → ASD：蛋糕模板→品尝评分卡

用模板做好蛋糕后，需要评分卡（ASD）检查是否合格：“1. 尺寸是否6寸（用尺子量，合格）；2. 草莓是否新鲜（尝1颗，合格）；3. 甜度是否低糖（甜度计测，糖含量≤8%，合格）”。ASD是PDD的“质检标准”，确保按模板做出来的“AI蛋糕”符合最初的点餐要求（URS）。

四大文档的“协作闭环”

想象这是一个“寻宝游戏”：URS是“藏宝图”（告诉你宝藏在哪），SRS是“寻宝路线图”（怎么去），PDD是“寻宝工具包”（用什么工具挖），ASD是“宝藏鉴定书”（挖到的是不是真宝藏）。只有四个工具都用好，才能确保“用户需求”这个“宝藏”被精准找到并交付。

核心概念原理和架构的文本示意图（专业定义）

4个核心文档的“金字塔架构”

┌─────────────────────────────────────────────────┐  
│  验收标准与评估文档（ASD）：验证需求是否达成     │ ← 金字塔顶端（结果检验）  
├─────────────────────────────────────────────────┤  
│  提示模板设计文档（PDD）：将需求转化为提示模板   │ ← 中间层（落地执行）  
├─────────────────────────────────────────────────┤  
│  提示系统需求规格说明书（SRS）：将用户需求转化为技术指标 │ ← 中间层（需求转化）  
├─────────────────────────────────────────────────┤  
│  用户需求说明书（URS）：记录用户原始需求         │ ← 金字塔基座（需求源头）  
└─────────────────────────────────────────────────┘  

关键关系：URS是“输入”，SRS是“翻译”，PDD是“实现”，ASD是“验证”；四者形成“需求→转化→实现→验证”的闭环，确保AI提示系统从设计到交付的一致性。

Mermaid 流程图 (Mermaid 流程节点中不要有括号()、逗号,等特殊字符)

流程图解读：用户需求（A）先被记录为URS（B），再转化为SRS（C），然后设计PDD（D）并开发系统（E），最后用ASD（F）测试——通过则交付（G），不通过则回溯修改（H），形成循环直到满足需求。

核心文档模板与案例详解

文档一：用户需求说明书（URS）模板 + 案例

URS模板结构（共6部分）

章节	内容说明	填写提示
1. 用户画像	用户是谁（身份、背景、技能）	越具体越好，如“25-35岁互联网运营，熟悉Excel，不懂Python”
2. 需求背景	用户遇到什么问题？为什么需要AI？	描述痛点：“每周写运营周报需2小时，重复复制粘贴数据”
3. 核心功能需求	用户希望AI做什么（3-5个核心功能）	用动词开头：“自动提取Excel中的周数据”“生成周报文字总结”
4. 非功能需求	AI的“素质要求”（响应速度、语气等）	量化指标：“响应时间<10秒”“语气正式但不生硬”
5. 约束条件	AI不能做什么？有什么限制？	明确边界：“不处理超过10MB的Excel文件”“不生成虚假数据”
6. 场景示例	用户如何使用AI的具体例子	写1-2个场景：“周一早上，用户上传上周数据Excel，AI生成周报”

实战案例：智能客服提示系统URS

1. 用户画像

• 身份：电商平台客服主管（张经理）
• 团队：50人客服团队，日均处理1000+用户咨询
• 痛点：新客服培训周期长（3个月），常见问题回答不一致

2. 需求背景
用户咨询集中在“订单查询”“退款流程”“物流跟踪”（占比70%），但新客服常记错流程，导致用户投诉率高达15%。张经理希望AI提示系统能辅助客服快速回复，降低投诉率至5%以下，缩短新客服培训至1个月。

3. 核心功能需求

• F1：AI根据用户问题自动识别“问题类型”（如订单查询/退款）
• F2：AI生成“标准回答模板”（包含流程步骤和话术）
• F3：支持客服手动修改回答后，AI记录“优质回答”并更新模板

4. 非功能需求

• NF1：AI识别问题类型准确率≥90%（避免推荐错误模板）
• NF2：生成回答模板响应时间≤2秒（不耽误客服与用户对话）
• NF3：回答语气需“亲切友好”（如使用“亲~”“呢”等语气词）

5. 约束条件

• C1：仅处理中文问题（客服团队服务国内用户）
• C2：不回答“订单金额>1万元”的退款问题（需人工审核）
• C3：不生成包含“绝对”“一定”等绝对化词语的回答

6. 场景示例

• 场景1：用户问“我的订单什么时候发货？”
  → 客服在聊天框输入问题，AI识别“物流跟踪”类型，推荐模板：“亲_{您的订单{订单号}已发货，快递单号{快递号}，预计{天数}天送达哦}”
• 场景2：新客服修改AI推荐的回答后，系统提示“是否保存为优质回答？”，客服确认后，AI将新回答加入模板库

文档二：提示系统需求规格说明书（SRS）模板 + 案例

SRS模板结构（共5部分）

章节	内容说明	填写提示
1. 功能需求（FR）	将URS的“功能需求”转化为可技术实现的功能点	用“AI应能XXX”表述，如“AI应能识别3种问题类型”
2. 非功能需求（NFR）	将URS的“非功能需求”量化为技术指标	包含性能、可靠性、易用性等，如“准确率≥95%”
3. 数据需求（DR）	AI需要哪些数据？数据格式是什么？	如“用户问题历史数据（JSON格式，包含问题/类型/答案）”
4. 接口需求（IR）	AI提示系统与其他系统的交互方式	如“通过API与客服聊天系统对接，接收问题文本”
5. 约束与假设（C&A）	开发限制与前提条件	如“基于GPT-4模型开发”“假设用户问题为文本输入”

实战案例：智能客服提示系统SRS（对应上文URS）

1. 功能需求（FR）

• FR1.1：问题类型识别

  • 输入：用户问题文本（字符串，长度≤200字）
  • 输出：问题类型标签（枚举值：订单查询/退款流程/物流跟踪/其他）
  • 规则：支持至少3种核心类型，“其他”类型需提示人工处理

• FR1.2：标准回答模板生成

  • 输入：问题类型标签+订单号（可选）+快递号（可选）
  • 输出：结构化回答文本（包含开场白+步骤+结束语）
  • 规则：模板中需包含变量占位符（如{订单号}），支持客服手动替换

• FR1.3：优质回答学习

  • 输入：客服修改后的回答文本+问题类型
  • 输出：系统提示“是否保存至模板库”（Yes/No按钮）
  • 规则：每月自动汇总新模板，由客服主管审核后更新

2. 非功能需求（NFR）

• NFR1.1：性能

  • 响应时间：从接收问题到输出模板≤2秒（95%场景）
  • 并发处理：支持100名客服同时使用（无延迟）

• NFR1.2：准确性

  • 问题类型识别准确率≥90%（测试集1000条样本）
  • 模板变量填充正确率≥99%（如订单号格式正确）

• NFR1.3：易用性

  • 客服操作步骤≤2步（复制AI推荐回答→发送）
  • 新客服上手时间≤1小时（无需培训即可使用）

3. 数据需求（DR）

• DR1：历史问题数据集

  • 格式：CSV文件（问题文本,问题类型,标准答案,出现频率）
  • 数量：至少5000条（覆盖3种核心类型，每种≥1000条）

• DR2：模板库数据

  • 格式：JSON文件（问题类型,模板文本,变量列表,更新时间）
  • 示例：{"type":"物流跟踪","template":"亲~您的订单{订单号}已发货...","variables":["订单号","快递号"]}

4. 接口需求（IR）

• IR1：与客服聊天系统接口

  • 输入：POST请求（参数：user_question, user_id, order_id）
  • 输出：JSON响应（参数：question_type, answer_template, confidence）

• IR2：与订单系统接口

  • 目的：获取订单号对应的快递信息
  • 方式：调用订单系统API（需权限认证）

5. 约束与假设（C&A）

• C1：技术栈约束：基于Python开发，使用LangChain框架管理提示模板
• C2：模型约束：调用GPT-4 API（不使用本地模型）
• A1：假设用户问题为中文，无特殊符号（如表情符号占比≤5%）
• A2：假设订单系统API稳定（可用性≥99.9%）

文档三：提示模板设计文档（PDD）模板 + 案例

PDD模板结构（共4部分）

章节	内容说明	填写提示
1. 模板目标	该模板用于什么场景？解决什么问题？	对应SRS中的功能需求，如“物流跟踪问题回答模板”
2. 模板结构	提示词的固定格式（系统提示+用户输入+变量）	分模块描述：系统角色定义、任务指令、输出格式等
3. 变量定义	模板中的变量有哪些？如何获取/填充？	列出变量名、类型、来源，如“{订单号}：字符串，来自订单系统”
4. 示例与变体	模板的具体示例及不同场景下的变体	提供3-5个示例，覆盖常见情况

实战案例：智能客服“物流跟踪”提示模板PDD

1. 模板目标

• 场景：用户咨询订单物流状态时，生成包含订单号、快递信息的友好回答
• 对应SRS功能：FR1.2（标准回答模板生成）
• 预期效果：客服直接复制模板即可回复，无需手动输入快递信息

2. 模板结构（分3部分）

【系统提示】  
你是电商平台的物流跟踪助手，需根据用户订单信息生成回答。规则：  
1. 语气必须亲切（使用“亲~”“哦”“呢”等词）  
2. 包含所有变量（订单号、快递单号、预计天数）  
3. 若缺少变量（如快递单号），用“正在查询中”代替  

【用户输入】  
用户问题：{user_question}  
订单信息：{order_info}（JSON格式，含order_id, express_id, estimated_days）  

【输出格式】  
亲~您的订单{order_id}已发货，快递单号{express_id}，预计{estimated_days}天送达哦~ 如有疑问可联系在线客服呢~  

3. 变量定义

变量名	类型	来源	示例值	缺失处理
order_id	字符串	订单系统API	“ORD20231001001”	显示“{订单号}”
express_id	字符串	订单系统API	“SF123456789”	显示“正在查询中”
estimated_days	数字	快递系统API	3	显示“3-5”
user_question	字符串	客服聊天系统	“我的订单什么时候到？”	无需处理（仅作参考）

4. 示例与变体

• 标准示例（所有变量齐全）：
  输入order_info：{"order_id":"ORD20231001001","express_id":"SF123456789","estimated_days":3}
  输出：“亲_{您的订单ORD20231001001已发货，快递单号SF123456789，预计3天送达哦} 如有疑问可联系在线客服呢~”

• 变体1（快递单号缺失）：
  输入order_info：{"order_id":"ORD20231001002","express_id":null,"estimated_days":3}
  输出：“亲_{您的订单ORD20231001002已发货，快递单号正在查询中，预计3天送达哦} 如有疑问可联系在线客服呢~”

• 变体2（用户追问）：
  用户问题：“快递到哪了？”
  输出：“亲_{您的订单ORD20231001001当前在{city}中转站，预计明天到达{destination}哦} 可点击链接查询实时物流呢~”（新增变量city和destination）

文档四：验收标准与评估文档（ASD）模板 + 案例

ASD模板结构（共4部分）

章节	内容说明	填写提示
1. 评估指标	用什么指标衡量系统是否合格？	分功能指标（如准确率）和非功能指标（如响应时间）
2. 测试用例	具体测试场景和预期结果	每个功能点至少1个用例，包含输入、预期输出
3. 评估方法	如何执行测试？（人工/自动化）	描述步骤：准备数据→执行测试→记录结果→判断是否通过
4. 验收结论	是否通过验收？需改进点是什么？	分“通过”“有条件通过”“不通过”，附改进建议

实战案例：智能客服提示系统ASD（对应上文SRS）

1. 评估指标

指标类型	指标名称	目标值	权重	测量方法
功能指标	问题类型识别准确率	≥90%	30%	1000条测试样本，人工标注正确与否
功能指标	模板变量填充正确率	≥99%	20%	500条含变量的订单，检查变量是否正确
非功能指标	响应时间	≤2秒	25%	模拟100名客服并发使用，记录平均响应时间
非功能指标	客服满意度	≥4.5/5分	25%	50名客服使用后填写问卷（1-5分）

2. 测试用例（核心功能）

• 用例1：问题类型识别（F1.1）
  输入：用户问题“我的订单什么时候发货？”
  预期输出：问题类型=“物流跟踪”（正确）
  实际输出：“物流跟踪”→通过

• 用例2：模板生成（F1.2）
  输入：order_info={"order_id":"ORD20231001003","express_id":"YT987654321","estimated_days":2}
  预期输出：“亲_{您的订单ORD20231001003已发货，快递单号YT987654321，预计2天送达哦} 如有疑问可联系在线客服呢~”
  实际输出：（同上）→通过

• 用例3：变量缺失处理（F1.2）
  输入：order_info={"order_id":"ORD20231001004","express_id":null,"estimated_days":3}
  预期输出：“亲_{您的订单ORD20231001004已发货，快递单号正在查询中，预计3天送达哦}…”
  实际输出：（同上）→通过

3. 评估方法

• 步骤1：准备测试数据

  • 功能测试：1000条用户问题（3种类型各300条，其他100条）
  • 性能测试：模拟100名客服同时发送请求（使用JMeter工具）
  • 满意度测试：50名客服（含10名新客服）使用系统1周

• 步骤2：执行测试

  • 功能测试：自动化脚本批量输入问题，记录识别结果和模板生成内容
  • 性能测试：JMeter设置并发100，循环10次，记录响应时间
  • 满意度测试：发放问卷（问题：“使用便捷性”“回答质量”等5题）

• 步骤3：结果分析

  • 准确率=正确识别数/总样本数
  • 响应时间=总时间/请求次数（取95%分位值）
  • 满意度=平均分（5题总分/5）

4. 验收结论

• 测试结果：

  • 问题类型识别准确率：92%（≥90%，通过）
  • 模板变量填充正确率：99.5%（≥99%，通过）
  • 响应时间：1.8秒（≤2秒，通过）
  • 客服满意度：4.6/5分（≥4.5分，通过）

• 结论：所有指标均达标，通过验收。

• 改进建议：“其他”类型问题的识别准确率仅75%（需优化分类模型）。

实际应用场景

场景一：教育AI——“智能作业批改系统”需求分析

用户需求：小学老师希望AI批改数学口算题（100以内加减乘除），自动统计正确率并标出错误题。
4个文档如何应用：

• URS：记录“用户是小学三年级数学老师，每周需批改50份作业，每份100题，希望AI能识别手写数字并判断对错”。
• SRS：功能需求“AI能识别手写数字（准确率≥95%）、判断加减乘除结果（正确率≥99%）”，非功能需求“单份作业批改时间≤30秒”。
• PDD：设计模板：“【系统提示】你是数学作业批改员，判断算式{expression}的结果是否等于{student_answer}，输出‘√’或‘×’”。
• ASD：测试用例“输入算式‘35+27=62’，预期输出‘√’；输入‘48÷6=7’，预期输出‘×’”。

场景二：医疗AI——“患者问诊分诊系统”需求分析

用户需求：医院希望AI根据患者描述的症状，推荐挂什么科室（内科/外科/皮肤科等），并提醒紧急症状（如胸痛需挂急诊）。
4个文档如何应用：

• URS：记录“用户是首次就诊患者，对科室分类不了解，希望通过症状描述快速找到对应科室，避免挂错号”。
• SRS：功能需求“AI能识别20种常见症状，推荐科室准确率≥85%，紧急症状识别率100%”。
• PDD：模板包含症状列表（如“头痛”“咳嗽”“皮疹”）、紧急症状关键词（“胸痛”“呼吸困难”），输出“推荐科室：XX科（紧急程度：高/中/低）”。
• ASD：测试用例“输入‘持续胸痛30分钟’，预期输出‘推荐科室：急诊（紧急程度：高）’”。

场景三：金融AI——“理财产品推荐系统”需求分析

用户需求：银行客户希望AI根据存款金额、风险偏好（保守/稳健/激进）推荐3款理财产品。
4个文档如何应用：

• URS：记录“用户是30岁上班族，存款5万元，风险偏好稳健，希望年化收益≥4%，锁定期≤1年”。
• SRS：功能需求“AI能根据存款金额（分档：<5万/5-20万/>20万）、风险偏好推荐产品，推荐理由包含收益、风险、锁定期”。
• PDD：模板变量包括{deposit_amount}、{risk_preference}，输出“为您推荐：1. XX理财（年化4.2%，中风险，锁定期6个月）…”。
• ASD：测试用例“输入存款5万、稳健型，预期推荐3款中风险、年化4%-5%、锁定期≤1年的产品”。

工具和资源推荐

需求分析工具

• 用户访谈工具：腾讯会议（录音转文字）、飞书文档（实时记录访谈笔记）
• 需求管理工具：Jira（跟踪需求变更）、Notion（整理URS/SRS文档，支持多人协作）
• 用户画像工具：Figma（绘制用户画像图）、Xmind（梳理用户需求脑图）

提示模板设计工具

• 模板编辑：LangChain（支持动态提示模板，变量填充）、PromptBase（提示词市场，可参考优质模板）
• 变量管理：JSON Schema（定义变量格式，确保数据正确）、Excel/Google Sheets（管理多变量组合）

测试与评估工具

• 自动化测试：JMeter（性能测试，测响应时间）、Pytest（Python自动化测试框架，验证模板生成结果）
• 准确率评估：Label Studio（人工标注测试样本，计算准确率）、Hugging Face Evaluate（AI评估指标库）

学习资源

• 书籍：《提示工程实战》（人民邮电出版社）、《用户故事与敏捷方法》（需求分析经典）
• 课程：DeepLearning.AI的“Prompt Engineering”专项课程、Coursera的“软件需求分析”
• 社区：Prompt Engineering Guide（https://www.promptingguide.ai/，开源提示工程指南）

未来发展趋势与挑战

趋势一：需求分析自动化——AI帮你写URS/SRS

未来，AI可能自动分析用户访谈录音、邮件、聊天记录，生成初步的URS文档。例如，上传1小时用户访谈音频，AI自动提取“用户痛点”“期望功能”，甚至生成SRS的初稿——提示工程架构师从“记录者”变为“审核者”，效率提升50%以上。

趋势二：多模态需求处理——不止文字，还有图片/语音

目前需求分析主要处理文字，未来将支持图片（如用户手绘的界面草图）、语音（如口头描述需求）、视频（如操作演示）。例如，设计师上传一张APP界面草图，AI自动识别“这是用户需求中的‘首页布局’，需包含搜索框、推荐列表”——多模态需求分析让“模糊需求”更精准。

挑战一：用户需求的“动态变化”

用户需求不是一成不变的（如电商大促期间，客服系统需求从“回答物流”变为“处理退货”）。如何让4个文档快速迭代？解决方案：设计“需求版本管理”机制，如每月审核URS/SRS，标记“临时需求”（大促期间）和“长期需求”（日常），避免系统频繁重构。

挑战二：评估标准的“主观性”

ASD中的“客服满意度”“回答友好度”等指标主观性强。解决方案：结合客观数据，如“用户投诉率下降30%”（客观）+“客服满意度4.5分”（主观），让评估更全面。

总结：学到了什么？

核心概念回顾

我们学习了提示工程架构师的“四大法宝”：

• 用户需求说明书（URS）：记录用户“想要什么”，像“客人的点餐单”；
• 提示系统需求规格说明书（SRS）：将需求转化为技术指标，像“后厨操作指南”；
• 提示模板设计文档（PDD）：设计标准化的提示模板，像“菜谱模板”；
• 验收标准与评估文档（ASD）：验证系统是否合格，像“美食评分卡”。

概念关系回顾

这四个文档是“需求分析的闭环”：URS→SRS（需求翻译）→PDD（需求落地）→ASD（需求验证），任何一环缺失都会导致AI系统“偏离用户需求”。就像做蛋糕，没有“点餐单”（URS）会烤错口味，没有“评分卡”（ASD）会不知道好不好吃——四者缺一不可。

思考题：动动小脑筋

1. 思考题一：如果用户说“我想要一个智能助手”（非常模糊的需求），你会如何通过3个问题引导用户填写URS中的“核心功能需求”？
   提示：从用户身份、使用场景、期望结果入手提问。

2. 思考题二：假设你设计的提示模板（PDD）在测试中发现“变量填充错误率10%”（未达标），你会检查SRS中的哪个部分？为什么？
   提示：变量填充错误可能与数据来源有关（SRS的数据需求）。

3. 思考题三：在医疗AI场景中，ASD的“评估指标”除了准确率，还需要重点考虑什么？（提示：医疗领域的特殊性）

附录：常见问题与解答

Q1：四个文档必须按顺序编写吗？可以跳过某一步吗？

A：建议按URS→SRS→PDD→ASD的顺序编写，因为前一个是后一个的基础。但允许“迭代修改”，例如写完PDD后发现SRS的需求不清晰，可返回修改SRS。绝对不能跳过URS直接写SRS，就像不看菜单直接做菜——大概率做错。

Q2：小团队（1-2人）也需要写这么详细的文档吗？

A：可以简化，但核心内容不能少。例如，URS和SRS可合并为“需求文档”，PDD和ASD合并为“实现与测试文档”。关键是**“把需求写下来”**，避免口头需求导致遗忘或误解。

Q3：文档写完后就不变了吗？

A：不是。需求会变化（如用户新需求、AI模型升级），建议每季度回顾一次文档，标记“已过时内容”并更新。例如，GPT-5发布后，SRS中的“响应时间”指标可能从2秒降至1秒。

扩展阅读 & 参考资料

1. 《Software Requirements》（Karl Wiegers，软件需求分析经典教材）
2. 《Prompt Engineering for AI》（V. K. Jain，提示工程实战指南）
3. OpenAI官方文档：《Best Practices for Prompt Engineering》
4. 国家标准：GB/T 9385-2008《计算机软件需求规格说明规范》

---

希望这篇文章能让你从“凭感觉做提示工程”变为“用文档系统化分析需求”。记住：优秀的提示工程架构师，首先是优秀的“需求翻译官”——而这四个文档，就是你的“翻译词典”。现在就拿起笔，试着为你正在做的AI项目写一份URS吧！