需求分析与真实问题

小叶准备为学院做一个实习材料助手。最初的想法很直接：同学们总说交材料麻烦，AI 又擅长写作，那就做一个自动生成实习总结的工具。输入岗位、实习日期和工作内容，很快就能得到一篇格式完整的总结。

这个功能容易演示。输入几项信息，屏幕上出现一篇文章，旁观者马上能看见它做了什么。可是，学院负责收材料的老师说，最头疼的是材料反复退回；同学说，最烦的是交完以后才发现还差东西。自动写总结究竟能改善多少，眼下还说不清。

小叶需要作出的第一个工程判断，因此发生在写代码之前：大家口中的“麻烦”具体发生在哪里，这一版软件应当改变其中哪一件事？

这就是本章要讲的需求分析。我们要把人们提出的愿望、已经发生的事情、现实中的限制和可能的软件能力联系起来，形成一个有依据、可以继续确认的开发方向。AI 能把一个想法迅速做成东西；需求分析帮助我们判断，做出来的东西是否碰到了想解决的问题。

下面的学院、流程、对话和数据都是虚构的教学案例。其中的实习材料规则只在案例中有效，不代表任何学校的实际要求。全章围绕小叶的一次设计展开，也会改变个别条件，看看需求为什么随之变化。

一、从“想要什么功能”走到“想改善什么事情”

“我想要一个自动写总结的工具。”这句话已经包含了一种解决办法。提出它的人可能确实需要写作帮助，也可能只是从自己知道的技术中选了一个看起来方便的功能。

在需求分析里，先接住这个建议，再问它服务于什么事情，会比立刻把它扩展成一串功能更有用。

小叶问一名同学：“上一次准备实习材料，哪一步最耽误你？”同学回答：“我从群里下载了总结模板，写完以后才知道那是上一批的。换成新模板，有几项内容还得重新找。”

现在得到的信息和“写总结很麻烦”已经不同了。这名同学的困难发生在开始写作之前：他没有找到适用于自己的模板。即使 AI 把旧模板填得很快，材料仍可能因为版本不对而退回。

另一个同学的回答可能是：“我做过不少事情，但不知道怎么把自己的工作讲清楚，写出来总像流水账。”对于这个目标，围绕真实经历提供结构、追问细节、帮助修改表达，就可能有直接价值。不能因为第一个同学选错模板，就宣布写作辅助没有用。

用户需要可以理解为：人在某个情境中，为完成一件事，需要获得什么帮助。这里有三个互相连接的部分：处境、要完成的事情、当前的困难。它们共同决定我们为什么考虑一个功能。

小叶可以分别记下：准备首次提交的同学，需要在动笔前找到适用于本批次的模板，减少按旧模板重做；已经有真实工作记录的同学，需要把经历整理成有条理的总结，改善表达。这两项需要可以同时成立，但未必应当在同一版中一起解决。

需求分析也需要分清项目目标和具体要求。项目目标描述这次工作希望取得的改善，例如减少因规则理解不清造成的补交。具体要求则进一步说明系统需要提供什么能力，例如根据同学选择的实习批次展示相应材料清单，并说明清单依据。

从目标走到要求，中间还有一段需要论证的关系：我们为什么认为这项能力能带来那种改善？如果旧模板主要来自一个长期无人维护的群文件，清单入口可能有帮助；如果同学明知模板过期，却因系统只能接收旧格式而被迫使用它，那么只增加说明就解决不了问题。

因此，“真实问题”不是藏在现象下面、必须无限追问才能找到的唯一答案。它是一个能够用具体经历、记录或观察来支持的问题描述，而且具体到足以让我们选择下一步行动。

对于大学生的小项目，一次有针对性的交谈、一份退回记录、一次实际操作，往往就能推翻最初过于宽泛的猜想。先取得足以影响当前决定的证据，再继续做，学习和动手可以在同一件事里发生。GOV.UK 的用户需要指南也强调从实际任务和困难理解需要，并把后续功能与这些需要联系起来。

二、同一套材料，谁的困难需要被看见

如果只问交材料的同学，小叶可能得到一个很受欢迎的建议：“让我一次上传所有文件，剩下的都自动处理。”这个建议希望简化提交者的操作，但其他环节是否接得住，还需要继续了解。

负责收件的老师需要知道每份文件属于谁、对应哪个批次、哪些项目还缺。负责签署实习证明的人，需要看到应当核实的事实，再决定是否签字。负责维护工具的同学，需要知道规则改了以后由谁提供新版本。

这些都是相关参与者。软件工程中常用“利益相关者”这个名称，指会影响项目、受到项目影响，或者对结果有切实关切的人和群体。某个人不直接点击软件，也可能决定这件事能不能完成。

小叶可以画出一张很小的参与关系表。表格的目的，是找到还没被问到、却可能改变需求的人。

这张表还会暴露同一个词的不同含义。同学说“交好了”，可能是文件已经上传；收件老师说“收好了”，可能是文件齐全并且能打开；学院说“通过了”，可能还包括对实习内容的审核。

如果小叶把这几种状态都写成“提交成功”，界面看起来简洁，使用者却容易误解。一个人以为事情已经结束，另一个人仍在等他补签字。这里需要澄清的是事情走到了哪一步，而不只是给按钮换个名字。

在本例中，小叶与老师先约定：“文件已上传”只说明系统收到了文件；“材料齐全”说明当前清单所需项目已具备、模板符合适用要求且文件可读；是否“审核合格”，则由有权限的老师作出判断。工具以后能承担多少检查，可以继续讨论，但这些状态不能先混成一项。

参与者的想法也不必全部变成要求。有人希望老师替自己补写缺项，有人希望上传后永远不再被联系，这些愿望都要与任务责任、实际条件一起判断。认识参与者，是为了理解工作如何发生，并不意味着任何一句要求都具有同等决定权。

例如，适用哪份学院材料清单，需要由负责这项规则的老师确认；软件按钮放在哪里，可以通过使用情况比较；同学是否满意，应该让同学表达。把不同问题交给相应的人，才能避免由小叶或 AI 代替所有人作决定。NASA 关于相关参与者与期望的说明提供了这一视角：理解系统需要覆盖操作、支持等角色，也要明确冲突由谁处理。

三、还原一次具体经历，需求才开始有依据

确定需要接触谁以后，小叶还面临一个问题：怎样问，才不只是收集一堆意见？

“如果有一个智能材料助手，你会用吗？”很容易得到“会啊”。回答者可能觉得这个想法不错，也可能只是愿意配合。这个回答还没有告诉小叶，工具应当在哪一步出现、需要知道什么、什么输出能够帮助对方。

小叶接着向前面那名选错模板的同学追问：“你上次是从哪里开始准备的？当时看的那份通知还找得到吗？”同学打开了群聊天。小叶看到，一个旧模板被反复转发，新的通知在另一条消息里，只写了“模板有更新”，没有把旧文件撤掉。

接着问：“你什么时候发现版本不对？”同学说，收到退回消息以后才发现。再问：“老师当时具体让你改什么？”同学出示退回说明。这样，一次经历就有了起点、所用材料、采取的行动和实际结果。

需求获取就是设法获得这些与需要有关的信息。访谈、观察、查看记录、试用样品，都可以帮助获取需求。方法的选择取决于当前缺什么证据。想知道人怎么理解一条提示，可以请他边操作边说；想知道哪类补交出现得多，可以看记录；想知道规则由谁确定，就要找到规则负责人。

访谈中，开放而中性的提问尤其有用。“你怎么判断这份模板适用？”给对方讲真实做法的空间；“是不是因为学校通知太乱才弄错？”则把小叶自己的解释塞进了问题。对方顺着说“是”，小叶很容易误以为猜想已经得到了独立支持。

还要分清“实际发生过什么”和“觉得以后会怎样”。前者可以帮助还原行为，后者可以提供期待与担忧。两类信息都有价值，但承诺将来会用一个工具，不能直接当作已经使用并受益的证据。GOV.UK 的深入访谈方法强调追问实际故事和例子，而非停留在一般看法。

观察有时会发现交谈遗漏的细节。同学说自己“看了要求”，实际操作时却只看了群里同学整理的截图；老师说退回时“已经说明缺什么”，实际消息只有“材料不全”。这不一定是谁在故意隐瞒。人在熟悉的工作里常会把若干步骤压成一个词，忘记这些细节对另一个人并不显然。

观察也有边界。请同学演示一次，并不等于看到了所有人的日常做法。有人面对旁观者会格外仔细，有些操作发生在小叶没看到的手机界面上。记录时可以写清：“这次演示中，同学从群文件选择了旧模板。”这样的描述有用，而且保留了实际观察范围。情境观察指南所讨论的，正是结合真实设备、文件和环境理解行为。

小叶可以让 AI 先拟访谈提纲，帮助把“用户觉得难用”改成能追问的具体问题；也可以让它整理已经取得、适合用于分析的记录。但如果让 AI 扮演十名学生，再把生成的抱怨统计成“十人访谈结果”，得到的只是模型编出的可能情景。它可以提示下一次该查什么，却没有增加一名真实使用者的经历。

四、把现象、解释和方案分别放稳

随着材料增加，小叶开始写分析笔记。最容易出现的问题，是把几种性质不同的话写成同一种“发现”。

“这名同学使用了上一批模板”，是这次记录支持的现象；“他不知道模板已经更新”，是对行为原因的解释，需要有访谈或其他证据；“把最新模板放在首页就能解决”，已经是一种方案及其效果预测。

三句话接得很顺，却需要不同的证据支持。如果眼下只知道某位同学用了上一批模板，这个行为还可能有别的解释：他知道更新，但新文件的下载链接打不开；或者他属于另一类实习，本来就应该使用不同模板。原因不同，方案应当改变。

小叶在笔记里给它们留出不同位置：

同学的说明本身也是证据，但它证明的首先是对方怎样描述经历。若涉及关键判断，可以与当时的文件、通知或操作互相核对。小叶不需要怀疑所有人，只需要知道每份材料能支持到哪里。

这种区分对 AI 辅助分析特别有用。假如小叶把几段访谈交给 AI，要求“提炼用户痛点”，模型可能写出“学生普遍缺乏自律，导致材料准备滞后”。这句话读起来像概括，却可能既扩大了人群范围，又增加了原记录没有证明的原因。

更合适的工作要求是：每个归纳附上对应记录；把原话或实际动作与分析分开；找不到依据的想法列为待确认问题。小叶也可以要求模型给出另一种可能解释，例如除了不清楚规则，是否还可能受签署时间影响。这样，AI 的归纳能力帮助人寻找线索，原始材料仍然保留着判断依据。

如果两份材料看起来不一致，先把双方的说法都记下来。例如老师说“通知里都有”，同学说“我没看见”。这两句话可以同时是真的：信息确实发布过，但发布位置使它很难被找到。需求分析的价值，就在于把双方的经历接到同一段过程里，寻找具体可以改变的位置。

这里也能用到逻辑学中的一个习惯：看到一个结果，先想想还有哪些原因能够产生它。不是每次都要列全所有可能原因，而是在准备投入开发之前，识别那些一旦成立就会改变方案的解释。链接失效和不会写作，就是会把开发方向带向不同位置的两种原因。

五、用记录确定问题范围，别把标签数当成人数

访谈给小叶提供了具体经历。为了看看同一批材料里还有哪些情况，他又查看了收件记录。

本例记录覆盖同一学院、同一批次、同一类实习的四十份首次提交，四十名同学各提交一份。其中二十四份首次提交时材料齐全，十六份需要补交。这里的“首次齐全”采用前面约定的材料清单口径，还不表示实习内容已经审核合格。

在十六份需要补交的材料中，十份用了不适用的旧模板，八份缺签字。小叶一看，差点写成：“十八名同学遇到了版本或签字问题。”

可是这两种情况可以出现在同一份材料上。有四份既用了旧模板，又缺签字。把十和八直接加在一起，会把这四份各数两遍。按每份材料只进一组重新整理，情况如下。

这张图把重叠的四份单独放在一组。我们由此能看见：版本和签字问题共涉及十四份材料，另两份只有文件读取问题。两类问题的标签合起来有十八个，并不意味着涉及十八名同学。

这份记录让小叶把适用模板和签字准备列为优先调查对象。它还不能回答“做个检查清单可以少退回多少份”。

原因在于，同一种缺项可能由不同的困难造成。有的同学不知道需要签字，较早看到清单就可能及时准备；有的同学清楚要求，也已经联系了签署人，只是对方尚未处理。提醒对前一种情况可能有帮助，对后一种情况则还要看签署能否安排。

即使解决了一份材料中的版本问题，那份材料也可能仍缺签字。软件纠正了一个问题，与材料不再需要补交，是不同层次的改善。把两者分清，可以避免用解决标签的数量冒充完成任务的数量。

小叶随后把分析落到行动上：进一步了解旧模板从哪里进入流程；在缺签字的经历中，分别寻找不知道要求和等待签署的情况；了解无法读取的文件在提交前是否曾被打开检查。每一项调查都对应一种可能改变的环节。

要判断工具是否帮上忙，小叶还得明确准备观察哪种改善：少了某项缺失、少了一次补交，还是老师少花了时间。如果后续比较试用前后的结果，还需要了解使用者是否可比、流程是否同时变化。这些信息才有助于把实际变化与工具的作用联系起来。

六、沿着过程找位置：系统能够改变哪一步

现在小叶知道了几种值得处理的问题，但软件该放在哪里，仍需继续分析。

他把一次材料提交按实际工作顺序写下来：找到适用规则，准备内容和证明，取得需要的签署，上传文件，等待收件检查，按说明补交。前一阶段的结果会影响后面，所以只盯着“上传”按钮，可能漏掉导致补交的早期困难。

这叫理解业务过程：事情由哪些人，在什么条件下，经过哪些动作完成。这里的“业务”不只指商业活动。学院办事、课程作业、志愿活动，都有实际要完成的工作。

接着要确定系统边界，也就是这次软件承担哪些工作，通过什么地方与外部的人或系统发生联系。边界清楚，才知道什么可以由程序处理，什么需要外部条件配合。

小叶考虑的第一版，放在正式提交之前：帮助同学找到适用清单，理解需要提前准备的材料，并记录自己准备到了哪里。学院原来的正式提交入口继续承担收件；有权限的老师承担审核；单位签署人承担签署。

划在系统之外的环节，仍然会影响用户能否办成事。工具可以在清单中写明“本项需单位签署，取得签字后才能具备完整材料”，并给出经确认的办理说明。如果有人正等签署，系统应允许记录“已联系，等待签署”，使准备状态与实际一致。

但是，把提醒从一天一次改为一小时一次，并不会让签署人提前有空。如果同学必须本周五提交，而签署人下周一才能处理，小叶需要了解是否有符合规则的提前安排、其他办理方式或截止时间协调。软件可以帮助传递信息，真正解除时间冲突还需要相应的人采取行动。

这一步也会改变我们对输入的要求。为了找到适用模板，系统究竟需要同学的姓名，还是只需要学院、批次和实习类型？若匹配规则只用后三项，就没有理由因为常见注册页面都有姓名和手机号，而先收集一整套个人资料。

为了帮助勾选“是否已取得签字”，也未必需要上传签字文件。让同学记录准备状态与让系统识别签字图像，是两种不同能力，后者还增加文件处理、识别出错和访问管理等问题。第一版若只做自查，应当清楚说明勾选是同学自己的记录。

边界还要覆盖输出。展示“你已经勾选全部准备项”，是在回报用户记录；展示“你的实习材料已审核通过”，是在宣告另一种决定。即使两句话都只是屏幕上一行文字，承诺的事情也差得很远。

理解输入、输出、外部角色和实际条件以后，小叶才能给 AI 一项范围明确的工作。否则一句“做一个实习管理系统”，很容易让它补出登录、评分、审批、排行榜等一整套常见功能，而真正需要解决的适用模板问题仍然没有依据。

七、把需要写成要求：做什么、做到什么程度、遵守什么条件

需求分析不能一直停留在“了解情况”。当已有信息足以支持一个方向，就要把它写成别人可以讨论、开发和检查的要求。

功能需求说明系统应当提供什么行为或能力。对于小叶的第一版，可以先写：“同学选择学院、实习批次和类型后，系统展示对应的材料清单及模板入口。”

这比“支持智能查询”清楚，因为使用者怎样发起、系统围绕什么内容作出响应，已经有了轮廓。但它还留下了一个会直接影响行为的问题：如果所选条件没有对应的已确认清单，系统怎么办？

如果小叶不说，AI 可能选择展示最相近的一份，或者根据已有内容生成一个看起来合理的清单。本例中，这样做会重新制造“不适用的模板被当成适用规则”的问题。

因此可以补成：“只有找到适用且经规则负责人确认的清单时，才展示为可采用的清单；找不到时，说明当前没有已确认内容，并提供约定的咨询入口。”这项要求之所以出现，是因为缺少依据时继续给出确定指示，会破坏本来要解决的问题。

质量要求说明能力应当达到什么使用水平。假如同学主要通过手机查看清单，表格内容必须能在实际使用的手机页面上读清楚，模板链接应当能打开。功能名称完全相同，实际能否使用，可能就由这些要求决定。

“页面友好”“响应迅速”可以作为讨论起点，但还不足以让开发者知道该怎样取舍。小叶可以拿常用手机查看：项目名称是否被截断，适用批次是否藏在折叠区域，加载等待是否让人以为没有反应。接着再与使用者确定需要支持的设备和网络条件、可接受的等待程度。数字指标应当服务于实际使用，不能为了显得专业随手规定“所有请求零点一秒返回”。

约束则是当前方案需要遵守的条件。例如，第一版使用学院确认的清单作为规则来源；不把学生的实习文件上传到未经约定的外部服务；不改变学院正式提交和审核的入口。这些条件会影响哪些实现办法可选。

功能、质量和约束之间可以有交叉。同一句“在手机上展示适用清单”，同时涉及功能和使用环境。写需求时不必为了分类把一句清楚的话切成碎片。分类的价值，是提醒小叶：除了能演示的动作，还要考虑实际使用水平和不能随意改变的条件。NASA 的技术需求说明也讨论了功能、性能及其他条件，并强调需求应当可理解、可核实且符合实际需要。

还有一种常见混淆，是把实现偏好写成需求。“必须使用向量数据库”说的是一种技术选择。若材料数量不多、规则对应关系明确，先按学院、批次和实习类型直接查表，可能已经能够完成要求。如果现有系统或能力条件并未限制实现办法，小叶可以先说明所需行为，再比较不同方案。

相反，“使用现有校内身份验证”也可能是有依据的约束，例如校内已有统一账户且不允许另设密码系统。关键不在于一句话出现了技术名词，而在于为什么必须这样做、依据是什么。需求分析要帮助别人理解这个原因。

八、冲突不是靠把所有要求加进去解决的

当小叶拿出初步方案，意见很快出现分歧。同学希望不用填写身份信息就能查清单；收件老师希望知道谁还没准备好，以便提前提醒。

如果直接把两边要求合并，可能得到一个矛盾产品：号称匿名查询，却要求每人登录并记录所有准备进度。更有用的做法，是先拆开双方要完成的事情。

同学希望低门槛地取得适用信息，通常不需要老师知道是谁；老师希望发现哪些人需要提醒，这是一项个人进度管理需要。两件事关联，但有不同的输入、权限和责任。

小叶可以先做不需要身份信息的清单查询，把个人进度记录保存在同学自己使用的范围内。如果以后确认需要老师集中跟进，再单独讨论哪些进度应当提交、由谁查看、怎样告知使用者，以及维护这项工作的投入。这样，第一版能提供已经明确的帮助，新增管理能力也有清楚的讨论入口。

冲突也可能来自规则。老师提供的一份文件说需要单位签字，另一份说明却写着某类实习可以使用不同证明。小叶需要确认两者适用范围，而不是让 AI 对两份文字取平均，更不能因为其中一份文件日期较新，就自动认定它取代所有旧规则。

文件的发布日期、适用批次和修订范围是不同信息。一份今天发布的补充说明，可能只针对某一种实习。规则来源不仅是一个链接，还包括谁有权发布、适用于谁、何时适用，以及如何处理例外。

如果负责规则的老师暂时也不能确认，小叶应当把这部分标为待确认，在产品里相应处理。其他已经清楚的范围可以继续开发。保留一个未决定事项，比在实现中偷偷选择一个答案更容易继续工作。

选择先做哪些需求，可以借助前面经济学的机会成本和管理学的目标分解。这里要多走一步：把优先顺序落实到实际依赖。例如，清单页面再快做完，如果没有任何人能确认清单内容，仍然无法提供可信的适用规则。规则确认本身就是这项功能成立的前提。

因此，小叶的顺序可以是：先落实一个明确批次的清单内容及负责人，再验证同学能否找到适用材料；个人进度汇总和自动写作暂不进入这一版。这个顺序不是永久否定后两项，而是让本轮开发围绕一个证据较充分、条件能够落实的问题展开。

九、用一个小原型，检查我们有没有理解对

需求写出来以后，读起来合理还不够。小叶需要需求确认：检查这些要求是否与实际需要相符，相关参与者是否理解一致，已有条件是否足以支持它们。

一个很有效的办法，是让人面对某种具体东西作判断。这个东西可以是纸上的页面、几张可点击的图，也可以是 AI 很快生成的小网页。它们都可以成为原型，用来呈现方案中的一部分，让尚未清楚的地方显露出来。

原型做什么程度，取决于准备确认什么。小叶当前想知道：同学能否识别自己的批次，找到适用模板，并看见需要提前办理的签署事项。验证这几个问题，不需要先建完整账户系统，也不需要真的接入学院收件平台。

在案例中，负责本批次规则的老师已经确认了一份清单。小叶用它做了三个简单页面：选择范围、查看清单、查看某一项的办理说明。随后请一名确属该批次的同学，用演示页面判断自己还需要准备哪些东西。小叶先观察对方怎样做，尽量不在旁边告诉他应当点击哪里。

如果同学把“毕业年份”当成了“实习批次”，就说明选择入口存在理解问题；如果能找到模板，却没有从清单中注意到签字要求，就值得检查重要信息是否出现在容易看见的位置。这里得到的是可以对应到要求的具体行为，小叶能够据此调整页面。

小叶还准备了一个没有已确认清单的选择项，用来检查页面是否说明信息不足。如果这时原型仍展示另一批次的清单，就暴露了一个明确错误：它没有遵守前面确定的适用条件。哪怕其他页面都很顺畅，这个问题也值得立即修复。

原型中还可能有临时安排。例如清单内容由小叶手工填入，更新按钮尚未实现。这种做法足以检查页面上的信息是否易找，却没有验证长期更新的可靠性。要判断规则变化后系统能否正确维护，就需要另做相应检查。

同样，一名同学顺利找到模板，说明在这次条件下完成了找模板这一步；它不足以证明所有同学都会找到，更不足以证明补交已经减少。小叶可以根据风险继续找不同情况的人尝试，再在实际使用后观察结果。如果一次失败暴露了批次提示不清等具体问题，就可以据此修订，不必等更多人重复遇到同样的困难。

原型的价值，是尽早得到能改变设计的反馈。它可以让小叶发现需要重新问的问题，也可以说明某一项已经足够清楚，可以进入开发。确认与制作往往交替进行，先理解一部分、做出一部分、再根据使用补足理解，比等一份永远完整的需求文档更贴近实际工作。ACM 等组织的 CS2023 计算机科学课程材料也把需求获取、表达、原型确认和变化纳入软件需求的学习范围。

十、留下依据，让 AI 能接着做，让后来的人知道为什么

假设小叶现在把页面交给 AI，要求继续完善。模型可能看到“无清单时请咨询老师”，主动加上一段自动生成的建议，以为这样能够提高完成度。如果它不知道这句话背后的要求，就很难判断哪些空白可以补，哪些空白恰好是在表示尚无依据。

这时需要需求追溯：能够从一项要求回到它所依据的需要、记录或规则，也能够往后找到相应的设计与检查。它让“为什么要这样做”与“现在做成什么样”保持联系。

小叶不用先购买专门系统。一个简短条目就能承载这种关系。

要求 R1：按已确认的适用范围展示清单。

起因：查看的材料中存在模板不适用的退回；具体访谈显示，一名同学从群文件取得旧模板且不知道更新。

规则依据：负责本批次规则的老师确认的清单，记录其适用学院、批次、类型及确认日期。

预期帮助：同学在准备前识别应采用的材料；实际能减少多少补交，留待使用验证。

关键行为：“选择范围”页面提供学院、批次和类型选项；“查看清单”页面在匹配时展示清单和依据，没有已确认匹配时说明缺少信息并给出约定咨询入口。

检查办法：分别用适用条件和未支持条件操作，核对前者展示的清单是否符合已确认规则，后者是否说明缺少信息并提供咨询入口。

这里没有把“一名同学的经历”写成所有人都遇到同样问题，也没有把预期帮助提前写成已取得的效果。记录所能支持的范围，和接下来希望做到的事情，分别保留着。

追溯尤其适合处理变化。假如学院后来确认某类实习不再使用这份模板，小叶可以从规则依据找到受影响的清单、页面和检查情景。若没有这层关系，修改就容易变成在代码里四处搜索“模板”两个字，改到哪里算哪里。

给 AI 的任务也因此能具体起来：先说明这次希望帮助同学在准备前找到适用材料，提供已确认的清单和适用范围，再明确第一版的输入、输出、缺少信息时的行为，以及本次不承担的审核决定。最后要求它把尚不明确、会改变功能的事项列出来。

对于页面排版、内部变量名等普通实现选择，可以让 AI 自行完成。对于“找不到匹配时是否可以猜一份”“谁能够把待确认规则改为有效”等会改变产品承诺的问题，就需要根据需求依据处理。清楚的任务说明，应当让实现有行动空间，同时让重要决定有来源。

这也解释了需求分析与上一门程序设计课的联系。程序测试可以检查给定输入时，输出是否符合约定；需求分析要进一步检查，这个约定是否解决了现实中的问题。前者可以发现没有匹配却返回旧模板，后者帮助我们事先说明为什么这种行为会造成麻烦。两种检查相互支持。

十一、回到小叶这次究竟做什么

现在回头看，最初的“自动写总结”已经变成了一组可以分别判断的需要。

这次项目把减少因规则理解不清造成的补交作为目标。现有记录让模板适用范围和签字准备成为优先调查对象；访谈与操作又说明，至少有同学在准备前没有找到正确版本。负责老师已经确认了本轮要支持的清单，这使一个有限范围的工具具备了开发依据。

因此，小叶决定先完成该范围内的材料自查入口：根据选择展示清单和模板，说明签署准备，允许同学记录准备状态；没有适用依据时说明情况。原型中若发现批次名称容易认错，就先修正这一入口，再继续做完整页面。

等待签署的问题仍由实际办理条件决定，工具记录和提示这一状态；正式材料审核由有权限的老师承担。自动写作则留下另一条独立需要：帮助同学表达真实经历。是否开展，可以另找相应证据，明确目标后再决定。

小叶没有证明产品一定成功，但已经获得一个比“大家都觉得麻烦”更可靠的起点：知道帮助谁、改变哪一步、依据来自哪里、哪些事仍待确认，以及下一次用什么行为检查方向是否正确。这些信息能够直接进入后续场景设计、开发和测试。

练习与参考分析

练习一：先写页面，还是先补哪一种信息

小叶准备给实验室做一个“AI 自动排班工具”。同学说现在排班很乱，但目前没有任何具体记录。请写出两个值得先了解的问题，并说明不同回答会怎样改变开发方向。

**参考分析：**可以先问：“最近一次你认为排班混乱的事情是什么？当时谁需要用什么设备，最后发生了什么？”再问：“安排在哪里公布，发生变动以后，其他人怎样知道？”

如果困难是同一台设备被重复预约，方向可能是统一预约状态与冲突提示；如果排班本身没有冲突，只是临时调整后没有通知到人，重点可能是变更通知；如果设备维修导致所有安排失效，则还需要取得设备可用状态。先了解具体经历，是为了找到会改变方案的差别。自动生成一张表，未必改变这些条件。

练习二：九次问题记录，涉及多少份作业

另一个教学情景中，小叶检查十二份作业，每名同学交一份。五份引用格式有问题，四份缺少附录，其中两份同时存在这两种问题。怎样描述涉及范围？能否据此承诺增加格式提示后，所有这些作业都不再返工？

**参考分析：**两种标签合起来有九次，但同时有两种问题的两份被重复计算。因此共有七份作业存在至少一种问题，另五份没有这两种问题。也可以按组合理解：三份只有引用问题，两份只有附录问题，两份两者都有，再加五份两者都没有，合起来是十二份。

格式提示能否减少返工，要看它是否让同学发现并完成必要修改。它即使改善引用格式，也不一定补齐附录；若缺附录是因为相关实验还没做完，提示更不能代替实验。七份是本次涉及范围，不能直接当作将被工具解决的数量。

练习三：一句“已经完成”，完成了哪一步

小叶的材料助手允许同学勾选清单。所有项目被勾选后，页面显示“材料审核通过”。开发者解释：“代码没有问题，只要全选就显示这句话。”问题在哪里？怎样调整要求？

**参考分析：**代码可能正确执行了条件，但条件对应的是同学自报的准备状态，不能支持老师已经完成审核的结论。需求应当明确，勾选只记录用户的自查结果。页面可以显示“你已勾选全部准备项”，同时提供接下来应走的正式提交说明。

如果以后要展示审核结果，还需要有权限的审核者、可信的结果来源，以及与自查不同的状态变化依据。不能仅靠把文字改成更像正式通知的语气，获得原来并不存在的判断能力。

练习四：更新日期更近，就能采用吗

小叶找到两份实习说明。较早的一份适用于本批次全部同学；今天发布的一份只写“补充办理说明”，没有说适用对象。AI 建议统一采用今天的版本。此时应当确认什么？其他页面是否都要停下来？

**参考分析：**需要确认补充说明针对哪类情况、改变哪些条款、是否取代原规则，以及由谁负责作出这一解释。日期更近只说明发布先后，尚未说明适用关系。可以保留两份材料与冲突记录，向有权解释规则的人核实。

受这项不确定性影响的要求先保持待确认；已经清楚且不依赖它的内容可以继续。对外展示时，需要避免把尚未确认的规则伪装成确定指示。分析的目标是找到具体受影响的范围，不是因为存在一条疑问就让所有工作失去起点。

练习五：原型里成功，证明了什么

小叶手工准备了一份经老师确认的清单，放入可点击页面。一名同学成功找到模板。小叶说：“清单更新系统已经验证有效，补交率也会下降。”请分别判断这两项结论。

**参考分析：**这次原型支持的是该同学在给定页面和条件下找到了模板。清单由小叶手工准备，尚未演示或检查规则更新后系统怎样取得、替换和展示内容，因此还不能判断更新系统有效。

补交是否减少，也需要真实使用后的相应记录。找到模板与完整准备材料之间还有填写、签署等环节。这次结果可以支持继续完善入口，也能作为后续测试的一个已观察情景；它不必承担尚未检查的两种效果。

练习六：目标换了，原来的取舍还成立吗

现在改变项目目标：小叶只为已经拿到正确模板、也清楚签字要求的同学提供帮助。他们希望把真实实习经历写得更有条理。自动写作是否仍应暂缓？请提出一个值得确认的需要，以及一个有针对性的初步尝试。

**参考分析：**前面暂缓自动写作，是相对于材料准备方向、已有证据和第一版范围作出的选择。目标改变后，应重新判断，不能把旧结论当成对写作工具的普遍评价。

可以了解同学究竟困难在回忆工作细节、组织结构，还是修改措辞。假如已有真实记录，却难以把工作组织成主题，小叶可以先让工具根据这些记录给出结构建议，并请同学判断是否准确表达自己的经历、哪些内容仍需补充。这样一次尝试能够检查结构帮助是否有用。至于凭空生成漂亮经历，会改变材料的真实性，不能因为文章看起来完整就当作满足了这项需要。