收益：
- 能够借助 AI 支持将模糊的业务请求转化为清晰、可测试的软件需求和用户故事
- 能够利用人工智能以结构化方式比较系统设计、数据模型和架构决策的优缺点
- 能够根据需求、可扩展性和约束严格验证人工智能提出的设计
大多数软件项目的失败不是因为代码不好，而是因为对需求的误解。像“让用户下载报告”这样的一句话请求留下了数十个悬而未决的问题：以什么格式？谁负责？有多少记录？如果慢怎么办？需求分析（将业务请求转化为清晰的、可测试的技术需求）和软件设计（在纸上构建结构以满足这些需求）是在编写代码之前防止最昂贵的错误的阶段。在本单元中，我们将学习在这个阶段使用人工智能作为“思想伙伴”：一个揭开不确定性、整理选项、但将最终决定权留给你的伙伴。
AI在这里产生两大价值。首先，它会问你跳过的问题；它使请求中隐藏的假设和边缘情况浮出水面。其次，它快速列出设计决策的优缺点。但这就是危险：人工智能会在不完全了解您的背景（预算、团队、现有系统、法律约束）的情况下给出通用建议作为“最佳实践”。你的工作就是根据你自己的真实情况来过滤这些建议。
概念： 用户故事：以“...作为，我希望能够...因为...”的形式表达需求的短句。验收标准：工作必须满足才能被视为“完成”的可测试条件。非功能性需求：与“它将如何表现”而不是“它将做什么”相关的需求，例如速度、安全性、可扩展性。
从模糊的请求到可测试的需求
好的需求是可衡量和可验证的。不是“让系统快”，而是“让搜索结果在500毫秒内返回”。以下是使用人工智能缩小不确定性的分步方法：
- 按原样提出请求并生成问题。不要向 AI 询问解决方案，而是首先“将此请求中任何不清楚的地方都列为问题”。
- 你给出答案。只有你知道上下文；根据您真实的业务限制回答人工智能的问题。
- 将其转化为用户故事和验收标准。将明确的需求转化为可测试的项目。
- 添加边缘情况和负面场景。 “空结果”、“未经授权的用户”、“文件太大”等。
歧义提取提示：“我们将把以下业务请求转化为软件需求。还不要提出解决方案。首先，提取此请求中未回答的所有歧义和隐藏假设作为问题列表。将问题按以下标题分组：范围、用户/权限、数据量、性能、错误条件、安全性。请求：‘让用户以报告形式下载订单历史记录。’”
用户故事+验收标准提示：“将以下明确的需求划分为符合INVEST原则的用户故事。为每个故事编写3-5个可测试的验收标准（以Given-When-Then格式）。添加至少2个负面场景（未经授权的访问、空数据）。需求：[在此处写下澄清的需求]”
设计决策与人工智能的比较
设计是一个不断的权衡：速度与灵活性、简单性与可扩展性？人工智能将这些权衡放入一个快速的电子表格中。例如，对于“发送通知”功能，您可以争论是使用同步（按请求发送）还是异步（排队、在后台发送）方法。
设计对比提示：“我正在设计一个‘向用户发送电子邮件通知’的功能。比较一下两种方法：(A)在HTTP请求期间同步传递，(B)通过将其放入消息队列在后台异步传递。在以下轴上制作一个表格：用户等待时间、容错性、复杂性、基础设施成本、调试难度。用两句话总结在哪种情况下我最终会选择哪一个。不要为我做决定。”
轴
同步传输
异步（队列）
用户等待时间
时间长（等待发货）
短（立即返回）
容错能力
低（如果发送爆炸，则请求爆炸）
高（可以重试）
复杂性
低
中高（队列基础设施）
基础设施成本
低
需要额外的组件
适合的地方
体积小，应用简单
大批量、关键交付
提示：告诉人工智能“不要为我做决定，只需向我展示选项和条件”会迫使您思考并降低盲目接受建议的风险。最好的设计决策是由了解您的环境的人（您）做出的。
弱提示/强提示
弱项：“为订单系统设计一个数据库。” （结果：哪些规模、哪些关系、哪些约束不清楚；笼统的、不切实际的方案。）强：“为小型电子商务建议一个草稿数据模型。实体：客户、订单、产品、订单项目。约束：订单中可以有很多产品；产品价格可能会随着时间的推移而变化，但当前价格应保留在过去的订单中；预计每天约有 500 个订单。关系以及原因”解释您做出的决定。请具体说明您如何解决价格历史问题。将其作为实体和字段的列表，而不是代码。”
强大提示的区别；规模（每天 500 个订单）、业务规则（必须保留过去的价格）和所需的输出格式。一句“必须维持过去的价格”就彻底改变了设计；如果你不指定这一点，人工智能将生成一个不准确但看起来合理的图表。
迷你箱
案例 1——隐藏的假设。团队直接对“用户可以上传个人资料照片”请求进行编码。另一个团队向人工智能询问不确定性：“最大尺寸？允许的格式？不适当的内容控制？删除旧照片？”它会产生 8 个问题，例如。当 20 MB 文件填满服务器时，第一个团队在生产中了解到该问题；第二组在设计上解决了这个问题。
情况 2 — 比例假设不正确。人工智能为报告功能提出了一个复杂的缓存层。当工程师指出真实数据只有每天30份报告时，AI简化了建议。不指定比例会导致不必要的复杂性；指定可以节省 2 周不必要的工作。
案例 3 — 验收标准差距。 “如果付款失败怎么办？”由于从未询问过该问题，因此如果付款不成功，订单系统仍会将订单标记为“已确认”。人工智能生成的负面场景列表反映了这一差距； 1 行验收标准可防止真实资金损失。
常见错误
- 将请求直接传递给代码。在解决歧义之前编写的代码可以快速解决错误的问题。
- 盲目采用人工智能的一般“最佳实践”。如果您不指定您的背景（规模、预算、团队），该建议将不适合您。
- 跳过非功能性需求。如果没有指定速度、安全性和规模，设计将是不完整的。
- 只想着幸福的场景。设计中应包含空数据、未经授权的用户、错误状态等负面场景。
- 将决策委托给人工智能。人工智能生成选项；您可以决定哪种权衡适合您的业务。
总之
需求分析和设计是发现错误最便宜的阶段。在这里，人工智能会生成揭示不确定性的问题，起草用户故事和验收标准，并绘制图表设计权衡。但只有你知道上下文；您的工作是根据您的规模、预算、团队和法律限制来过滤人工智能的建议并做出最终决定。 “不要为我做决定，向我展示选项”的原则可以带来更好的设计和更深入的学习。
应用任务
从您的上下文中选择一句话的工作请求。首先，将歧义提示应用到AI上，并以你的真实约束条件回答问题。然后将明确的需求转化为至少 2 个用户故事和每个故事的 3 个验收标准；包括至少 1 个负面场景。最后，为设计决策（同步/异步、表结构等）创建一个比较表，并用两句话写出您自己的决定。
清单
- [ ] 在将请求传递到代码之前，我删除了作为问题的歧义。
- [ ] 我给出了人工智能的背景（规模、权威、性能、法律约束）。
- [ ] 我将用户故事分解为可测试的验收标准。
- [ ] 我添加了至少一种不利/边缘场景。
- [ ] 我用权衡表评估了设计决策。
- [ ] 我根据自己的情况做出了最终决定，我没有把它留给人工智能。