企业官网建设流程全解析

先问一个场景：你去接一个“web的学生成绩管理系统设计与实现”的活儿，用户跟你说“能录入成绩、能查成绩、能管理学生就行”。然后呢？很多人到这一步就卡住了，因为用户描述里的每个词都认识，但凑在一起根本没法开工。需求分析做得多了以后，你会发现一个规律——需求这东西，越聊越虚，但最后能落地的，永远藏在那些反复出现的关键词里。关键词法需求分析，就是一套把这种“感觉听懂”变成“真听懂”的方法。

这套方法不是我发明的什么高深理论，它就是从无数次需求评审翻车现场里提炼出来的土办法：把用户嘴里那些零散的、模糊的、甚至前后矛盾的说法，用高频关键词当锚点，一步步追问、拆解、归类，最终变成一张能指导开发的功能清单和验收标准。适合谁用？做毕设和课设的学生、刚转岗需求分析的产品新人、还有那些每天被“需求又改了”折磨的开发。不挑行业，软件、硬件、市场调研都能套，后面我会用一个锂电池负极材料的例子给你证明这一点。

1. 关键词法到底在解决什么问题

1.1 需求分析最怕的不是没需求，而是“需求迷雾”

先说一个最常见的场景。用户说“我要一个能管理学生的系统”，这句话你听着好像有信息量，仔细一想全是废话。“管理”是什么？是增删改查？是审批流？是按权限分级操作？还是像Excel一样随便改？如果按字面意思去做，开发做出来的东西大概率不是用户想要的。

需求分析教科书上把这个叫“需求模糊”，我更喜欢叫它“需求迷雾”。用户不是故意不说明白，而是他脑子里并没有一个完整的系统蓝图，他说出来的只是他日常工作中的碎片：录入成绩、查成绩、导出表格、算绩点。这些碎片之间有什么关联，数据从哪来、到哪去，哪些人有哪些权限，他没想过，也不觉得需要想。这时候你如果直接动手，项目就掉进了第一道坑。

关键词法解决的核心问题，就是帮你穿过这层迷雾。它不要求用户一次性把需求讲完整，而是从用户说出口的“高频词”出发，把模糊描述变成一个个明确的追问点。比如“管理学生”里的“管理”，我不把它当成一个功能，而是当成一个疑问句：“你平时管理学生的哪些信息？新增、删除、修改、查哪个最频繁？谁有这个权限？”这么一问，需求就慢慢变清晰了。

这套方法的另一个价值在于“对抗遗忘”。项目做到一半开发过来问“这个绩点按什么算法算”，你翻当时的会议纪要，发现用户只说了一句“按学分加权平均”。这句话其实已经给了你能算出来的线索，但你当时没把它当成关键词记下来，结果就变成一个隐形需求，直到测试阶段才爆发。关键词法要求你把每个有价值的词都变成白纸黑字的待确认项，避免需求在传递中蒸发。

1.2 核心逻辑：以词为锚，以追问为推进器

关键词法的核心机制很简单：任何一个需求描述里，反复出现的名词是业务对象，反复出现的动词是业务流程，反复出现的形容词和数量词是业务规则。这三类词就像三根柱子，把需求这栋房子撑起来。

• 名词类关键词：学生、教师、班级、课程、成绩、学分 —— 这些词告诉你系统里要管理哪些“东西”，对应到后面的实体设计、数据库表、类图。
• 动词类关键词：录入、查询、删除、导出、计算 —— 这些词告诉你系统要提供哪些“动作”，对应到用例、接口、前端功能点。
• 形容词/数量词类关键词：实时、批量、自动、多条件、不超过100分、保留两位小数 —— 这些词告诉你“做到什么程度”，对应到校验规则、性能指标、交互细节。

我在实际项目里给这套逻辑起了个外号，叫“3W1H追问法”：每个关键词都要过一遍Who、What、When/Where、How。

以“查询成绩”为例。Who：谁查？学生查自己的，老师查自己教的班的，辅导员查整个专业的，权限不一样。What：查出来要展示哪些字段？姓名、学号、课程名、分数、绩点，还是还要有排名？When/Where：什么时候能查？学期中还是学期末？是Web端查还是也要支持手机端？How：按什么条件查？按学号、按班级、按课程、按时间段？要不要支持组合查询和模糊搜索？这些问题没有标准答案，但每一个都必须由用户来回答。你问得越细，后面的开发就越顺。

这个“以词为锚”的机制还有个额外好处：它能帮你识别用户描述里的矛盾。比如用户既说“学生成绩要严格保密”，又顺手说“全学院都得能看到排名”，这两个关键词——保密和公开——是冲突的。如果不做关键词法，你可能想到哪个做哪个；做了以后，你就能在需求阶段把这个冲突摆到桌面上，让用户自己去权衡。

1.3 为什么叫“关键词法”而不是“模板法”

市面上有很多需求分析模板，用户故事模板、用例模板、需求规格说明书模板，一抓一大把。但模板解决的是“写在哪”，不解决“写什么”。我见过太多人拿着模板依然不知道往里面填什么东西，原因就是他从用户的话里提取不出有效内容。

关键词法恰好补上这个断层。它提供了从“用户原话”到“结构化需求”之间的转换路径。你不必一开始就想清楚完整的功能架构，只需要先把所有关键词捞出来，再一个词一个词地追问和归类。归类完成后，你会发现功能的雏形已经出来了，剩下的事情只是用模板把它包装得规范一些。所以我的经验是：先关键词，再模板；关键词是上游，模板是下游。顺序不能反。

2. 关键词提取与分类的实操细节

2.1 关键词从哪里来：三个最靠谱的信息源

第一个信息源是“用户原话”，包括访谈录音、会议纪要和聊天记录。这里要注意一个细节：别听用户怎么说，要看他怎么做事。用户说“我要一个登录功能”，但他平时在办公室的电脑上已经登录了域账号，根本不想再输一次密码。那他的原话“要登录”和真实需求“最好自动免登”就是两层意思。光看原话不够，还得结合使用场景去验证关键词背后的真实诉求。

第二个信息源是“用户抱怨”。用户抱怨“每次期末算成绩算到半夜”“从Excel复制到系统里老对不齐列”，这些抱怨里往往藏着真实的核心需求。抱怨里的高频词——算到半夜、对不齐列、眼花、太麻烦——就是关键词法的富矿。把它们转译成需求语言，对应的就是“自动算绩点”“支持批量粘贴”“界面要有明显分隔线”。

第三个信息源是“竞品和相似系统”。做学生成绩管理系统之前，去看看现有的同类系统有哪些页面、哪些按钮、哪些提示语，把里面出现的高频功能词列出来，拿给用户确认“这些你都要吗”。这能帮你省掉大量从零开始的时间，也能逼着用户去思考那些他没想到、但你从竞品中反推出来的功能点。我在做需求分析时，经常把竞品截图直接发给用户，让他逐个打勾；这比空口问“你还需要什么功能”高效得多。

2.2 划词和筛词：高频不等于重要

拿到原始材料后，第一件事是通读两三遍，把里面的名词、动词、数量词全部划出来。划完之后你会发现，词的数量永远比预想的多，如果不做筛选，后面根本没法用。筛选的时候，最重要的原则是过滤掉三类“伪关键词”：

• 一类是“系统”“平台”“功能”“模块”这类架构词。用户说“我要一个系统”，这里的“系统”不提供任何业务信息，直接扔掉。
• 一类是“管理”。这个词是重灾区。几乎所有人都说“要能管理学生”“管理成绩”，但你问他“管理具体包含哪些操作”，他往往答不上来。遇到“管理”，一律拆成具体的动词，录入、修改、删除、查询、导出、审核、发布，拆不出来就继续追问。
• 一类是“方便”“高效”“快速”“好用”这类评价性形容词。这些不是需求，只是用户对结果的期望。真正的需求藏在他想实现的业务动作里，而不是这些抽象的感受里。

筛完伪关键词之后，还要解决一个“频次与权重”的问题。高频词不一定是最重要的，比如在一段描述里“成绩”出现了十次，“导出”只出现了一次，但导出恰好是用户今年的核心痛点。所以我的做法是：先按频次排序，然后人为调整权重。调整的依据是“如果不做这个功能，用户会骂娘吗”。会骂娘的，哪怕只出现一次，也是P0；不会骂娘的，就算出现十次，也只是P1。这一步是关键词法和纯词频统计最大的区别——它加入了业务判断，而不只是机械计数。

筛选结果我会整理成一张表，包含四个字段：关键词、出现次数、业务权重判断、所属类别。类别就按前面说的三类分：业务实体、业务动作、业务规则。这张表就是整个需求分析的地基，后面的用例、流程图、需求文档全都要从这张表里长出来。

一个典型的关键词分类表示例：

这张表一出来，需求规模基本就有数了：里面有8个词，每个词至少能展开成一到两个待确认问题。接下来就是逐个击破。

2.3 从词汇到需求：三类关键词的展开方法

名词类的展开方向是“实体的属性与关系”。拿“学生”这个词来说，要问：学生实体的唯一标识是什么，学号还是身份证号？除了姓名、班级、专业，还需要存哪些属性？学生和课程是什么关系，一个学生可以选多门课，一门课可以有多名学生，这就是典型的多对多关系，怎么处理？这些问题的答案最终会变成数据库表和类图。

动词类的展开方向是“功能的业务流程与分支”。拿“录入”来说，要问：录入口在哪里？是老师自己录，还是管理员代替录入？录入时是单个录入还是支持Excel批量导入？录入过程中要不要实时校验分数范围？录入之后能不能改，由谁来改？每个分支都对应一个界面和一段逻辑。我一般会把“录入”拆成“新增成绩-校验-保存-修改-删除”这样一串子动作，每个子动作再单独追问权限和触发条件。

形容词和数量词类的展开方向是“业务规则与非功能需求”。拿“校验不能超过100分”来说，要问：除了100分上限，有没有下限？分数是整数还是支持一位小数？如果是补考成绩，怎么和原始成绩关联？“绩点保留两位小数”背后还藏着一个问题：绩点计算是按学期算还是按总学分累计算。这些问题不展开，开发的实现口径就会千奇百怪，最后数据对不上，又是一个通宵排查。

展开的时候我会在旁边准备一个白板，或者打开ProcessOn这种在线绘图工具，把每个关键词写成一张卡片，然后用箭头把“实体—操作—规则”连起来。这个过程不是为了画图而画图，是为了让关系可视化。比如“学生”“教师”“成绩”三个实体画出来，你会发现教师是成绩的录入者，学生是成绩的归属者，二者之间通过“课程”产生关联。这张关系图画完，需求分析的核心骨架就立住了，剩下的事情不过是填肉。

3. 从关键词到需求文档：完整实操一个学生成绩管理系统

3.1 第一轮：拿到原始需求，提取高频关键词

为了让你看得更清楚，我用一个真实场景完整跑一遍关键词法。假设你接到一个这样的原始需求，来自学院老师的一段话：

“我们学院想做个成绩管理系统。学生每学期要选很多课，老师得能把自己课上的学生成绩录进去，录的时候要能校验一下，分数不能超过100分。学生自己可以登录查看自己的成绩和绩点，绩点要按学分加权平均来算。辅导员希望能按专业导出成绩排名，最好是Excel格式。成绩录入错了的话，老师要能改回来。”

把这段话通读一遍，划出关键词。高频出现的名词：“学生”“成绩”“老师”“课程”“学分”“绩点”“专业”。高频动词：“录入”“查看”“导出”“校验”“修改”。数量词和规则词：“每学期”“不超过100分”“加权平均”“Excel格式”。筛掉“系统”“管理”“要能”这些伪关键词之后，剩下大约15个有效关键词，全部按类别记入表中。

这一步看似简单，但有个容易犯的错：只记录了核心业务词，漏掉了规则词。“每学期”“不超过100分”“加权平均”容易被当成“约定俗成的常识”——不是的，软件开发里没有常识，只有显式的规则。用户说“每学期选很多课”，如果你不把它翻译成一个可执行的规则“排课周期按学期划分，成绩按学期归属”，开发就会自己脑补一套逻辑，往往脑补错了方向。

高频词提取完，不要急着写需求文档，先把关键词发给用户过目一眼，问他：“我理解得对不对，还有没有漏掉你特别在意的东西？”这一步成本极低，但能避免闭门造车。用户可能会补充“忘了说，成绩通知家长的功能也要”，这时候加进表单就行，比你做完再返工便宜得多。

3.2 第二轮：用3W1H逐词追问，把词问成需求故事

接下来是整篇需求分析中最耗时、也最出成果的一步。我要对所有关键词逐一过3W1H，并记录用户的回答。举几个核心词的追问过程：

“学生”的Who/What追问：系统里的学生是全校所有学生，还是只有某一个学院的？学生账号谁来创建？新生入学时是否要从教务处同步数据？学生能看到哪些课程的成绩？毕业生的成绩还要不要在系统里保留？这些回答直接决定权限模型和数据生命周期。

“录入成绩”的When/Where/How追问：老师什么时候在哪台设备上录？教室电脑上录，还是家里也能录？录的时候是每门课一个录入界面，还是按课程分班一次录多人？录完后是立刻生效，还是需要提交确认？录入过程中如果断网，已经录好的数据会不会丢？这些问题的答案，会细化成录入模块的交互稿和异常处理逻辑。

“绩点按学分加权平均”的How追问：加权平均的公式是（课程绩点×学分）的总和除以总学分，对吗？课程绩点和百分制分数的对应关系表是什么样的？补考、缓考、挂科重修在绩点计算里怎么处理？是只算必修课，还是所有已修课程都算？这些问题直接关系到公式实现。很多学生做这个题目，绩点算法糊里糊涂写死了一个数，被老师一问就露馅。

“导出Excel排名”的How追问：导出的是整个专业的排名，还是某个班级的排名？排名按什么字段排序？导出的Excel模板是不是固定的，列名用什么？数据量最大的时候大约是多少行，性能有没有要求？用户可能觉得“导出Excel”一句话就够了，但在开发眼里，它牵扯到模板设计、权限校验、大数据量渲染、文件名编码一大堆细节。关键词法能做的就是把这句话拆成可执行的问题。

我把这个过程叫“把词问成故事”。每个关键词追问完，用户脑海里的业务场景就变成了一个带角色、带时间、带规则的故事。比如“老师录成绩”这一条最后会变成：“老师登录后，默认进入本学期自己开设的课程列表；选择一门课后，按学生列表逐一填写分数；分数输入时实时校验，超出0-100分区间立刻红框提示；全部填完后点击提交，成绩进入待审核状态。”这就是一份能指导开发的需求故事。

3.3 第三轮：结构化成图，画出用例图与实体关系

关键词全部追问完，信息已经足够画图了。我习惯在ProcessOn里同步画两种图：用例图和ER图（实体关系图）。用例图的作用是明确“谁用系统做什么”，画的时候直接把前面梳理好的角色和动词放进去就行。成绩管理系统至少有四个角色：学生、教师、辅导员、系统管理员，用例包括：登录、维护个人信息、录入成绩、修改成绩、查看成绩、计算绩点、导出排名、管理账号等。图里每个用例都要能追回原始关键词，确保不是凭空加的功能。

ER图的作用是明确“数据怎么组织”。还是从关键词表出发：学生（学号、姓名、班级、专业）；教师（工号、姓名、职称）；课程（课程号、课程名、学分）；成绩（学生、课程、分数、学期、绩点）。学生和课程是多对多关系，学生与成绩是一对多，课程与成绩是一对多。这张图画完，数据库怎么建表基本就有数了。

绘图时有个经验：图不是画给用户看的，是画给开发和自己理的。用户不需要看懂ER图，但开发需要。画的过程中如果某个关系理不清，说明这个关键词还没追问到位。比如当时我怎么也想不明白“补考成绩”和“原始成绩”应该放在一张表还是两张表，于是回去追问了用户，才确定“保留原始成绩记录、补考成绩作为独立记录关联同一课程”。这一步发现的模糊点，是光看文字永远发现不了的。图的价值就是把隐藏的矛盾暴露出来。

3.4 输出需求文档：功能清单与验收标准

画完图后，最后一步是把所有内容变成可以落地的文档。我不会一上来就写那种几十页的软件需求规格说明书，太重的文档对中小项目就是负担。我习惯先输出一页纸的核心需求清单，包含：

• 功能编号：F1、F2……方便后续沟通和追踪。
• 功能名称：来自关键词的动词展开，如“成绩录入”“成绩导出”。
• 优先级：P0/P1/P2，来自前面说的业务权重判断。
• 用户故事：一句话描述“谁在什么场景下完成什么操作”。
• 验收标准：可验证的、具体的判断条件。

以“成绩录入”为例，验收标准可以写成：老师可以查看自己所授课程的学生名单，录入分数时若输入大于100或小于0的值，系统提示“分数需在0到100之间”且不允许保存；录入完成后可以提交，提交后学生和辅导员可见。把验收标准写清楚，测试阶段就有了明确依据。

这些表格填充完之后，再补充一份简单的权限矩阵。权限矩阵是关键词法顺带生成的好东西：用户原话里提到了学生、教师、辅导员三种角色，每一类角色在前面功能清单里能不能用每个功能，逐个打勾就行。权限矩阵写清楚，后面开发做权限校验时就少一大半沟通成本。整个过程跑下来，一份可执行的需求文档就出来了，而且每一步都有用户原话作依据，用户想赖账都难。

4. 关键词法常见问题与排查技巧实录

4.1 高频问题速查表：症状、原因与解法

用关键词法做了十几个项目之后，我总结出几个反复出现的问题，整理成一张速查表，你可以直接对照排查。

这里我想特别强调第一行的解法。很多新人在关键词法上翻车，不是因为提取不出关键词，而是因为提取了太多关键词后失去了方向。我自己习惯给每个关键词的三类属性做一次“是否必须”投票：用户强烈要求必须有的、业务规则明确禁止的、可做可不做的。所有“可做可不做”的功能统一扔到二期，一期只做必须项。这样需求范围就稳住了，后面开发进度也不会被琐碎功能拖垮。

4.2 我自己踩过的三个坑

第一个坑是“把关键词法做成了词频统计”。早期我做需求分析时，拿到用户材料就开始数词频，数完觉得稳了，结果用户一直摇头说“不是这个意思”。后来我才明白，关键词不等于用户准确的业务意图，它只是入口。比如用户反复说“管理”，但他实际想强调的是“查询方便”，这时候如果只盯着“管理”的增删改查做，就错过了真正的痛点。现在我每次划完词，都会问一句：“这个词背后，你最近最头疼的具体场景是什么？”得到的答案往往能推翻原先的词频排序。

第二个坑是“只问功能词，不问边界词”。功能词好理解，录入、导出、查询，大家都记得问。但边界词——比如“每学期”“不超过100分”“已毕业学生要不要保留数据”——特别容易被忽略。边界词决定了功能的约束条件，而约束条件恰恰是产生Bug的重灾区。我后来要求自己在追问环节加一个固定轮次：“这个功能的边界在哪里？什么情况不允许？数据最多到多少？”次次都问，虽然有点繁琐，但省下的返工时间远超这点麻烦。

第三个坑是“没有闭环确认”。有的需求分析师访谈完很高兴，觉得该问的都问了，写出来的文档没有发给用户做二次确认，结果开发到一半用户才发现文档里的理解和自己的预期差了一大截。需求分析这种事，最忌讳信息单向流动。我的补救方法是：每次整理完关键词表和追问结果，必须做一次五分钟的一对一确认，把关键词表拍在用户面前，让他逐条打勾。这一环节不能省，它是整个流程的保险丝。

4.3 应对“用户也不知道自己要什么”的场景

你会遇到一类更棘手的情况：用户自己也没想明白。你追问“绩点要怎样算”，他说“我也没细想，你帮我决定”。这时候关键词法照样能用，但要换一种推进策略。把类似问题攒起来，基于行业惯例或竞品方案设一个默认值，明确标注“这版先按XX实现，后续可以调整”，然后继续往下推进。比如成绩管理系统里常见的就是按“课程绩点×学分/总学分”做默认公式，并在文档里标注。

这种“先给方案再确认”的方式，比逼着用户思考更有效。用户不是不想回答，而是没有语境；你给他一个具体选项，他往往能立刻说出“对，就这样”或者“不对，我们院里要求的是另一套”。给默认值还有一个好处，就是避免了“没有结论”的悬空状态。需求分析的大忌是“留白”，因为留白最后大概率会在开发阶段变成临场发挥，做出一个谁都不满意的东西。

5. 关键词法的跨领域延伸：不写代码也能用

5.1 从学生成绩系统到锂电池负极材料，底层是同一套逻辑

你可能会觉得关键词法是软件行业的专属工具，其实不是。需求分析这个词泛化到任何行业，本质都是一样的：把模糊的描述变成明确的结构。举个例子，做锂电池负极材料的工程师，经常要面对“客户想要一款高容量长循环的负极材料”这种需求。这句话跟“我要一个能管理系统”一样，充满了信息量，但完全无法直接执行。

如果套用关键词法，第一步提取关键词：“高容量”“长循环”“负极材料”“客户”“成本”“批次一致性”。第二步追问：高容量是多少，比容量要做到450mAh/g以上吗？长循环是循环500次容量保持率不低于80%，还是1000次？客户是动力电池客户还是消费电子客户，导入周期多久？成本有没有上限？批次一致性要求Cpk值达到多少？这些追问完成后，“客户想要一款材料”就从口号变成了可执行的研发目标，工程师可以拿着这份需求去定配方、调工艺、做验证。

这就是关键词法最厉害的地方：学科和行业只是换了术语，但“名词当实体、动词当流程、形容词当指标”的逻辑完全一致。无论你做软件、做材料、做市场调研还是写策划方案，只要用户抛给你一段描述，你就可以用这套方法把它拆成可以执行的结构。哪怕是做一份招聘需求分析，岗位描述里反复出现的“增长、数据驱动、跨团队协作”，每个词都能继续追问出具体的目标、场景和考核指标。

5.2 关键词法的三个变体：按需选用

用久了以后，我发现关键词法可以根据场景换成几个不同形态。

第一个是“词云法”。当你手里有大量访谈记录、问卷反馈或用户评论时，先把文本丢进词频工具生成高频词云，肉眼扫一遍找到异常集中的业务词，再针对这些词去读原文。这种方式适合“从宏观到微观”的探索型分析，比如你刚接手一个陌生行业，对业务一无所知，词云能快速告诉你大家都在谈论什么。但词云只能作为第一步，不要把词云当结论，里面的词必须全部回到原文去验证。

第二个是“卡片法”。把关键词写到便利贴上，一张词一张贴，按实体、动作、规则铺在墙上或白板上，然后用线把不同卡片连起来。这个方法适合团队协作，大家在墙上吵架比在文档里打字高效得多。我在做需求评审时经常用这招，把十几张卡片往墙上一贴，所有人看到全貌，争议点也一目了然。卡片法比电子表格更有“体感”，因为你能用手移动卡片，重新建立关系，那种操作感会促进思考。

第三个是“追问模板法”。把3W1H做成一份标准问题清单，任何项目拿到手直接照单全问。我的模板里有几十个问题，比如“谁来做这个动作”“最频繁的触发场景是什么”“不做会有什么后果”“数据量最大多大”“失败时怎么提示”“权限怎么分级”。这个模板沉淀得越多，后续项目的需求分析就越省力。每次遇到新问题就补进模板，用不了几个项目，这份模板就能覆盖绝大多数业务场景。

这三个变体不是互斥的，我经常在一个项目里先用词云法了解概况，再用卡片法做团队讨论，最后用追问模板法输出正式文档。工具都是死的，能解决问题的组合就是好组合。

写在最后的一个小技巧

做需求分析这些年，我最大的习惯改变是：每次访谈或会议结束，不急着整理长文档，而是先花十五分钟把高频关键词按“实体—操作—规则”三列拉一张表，发给用户确认。用户往往只会回一句“差不多”。别怕这句“差不多”，只要关键词表足够具体，这个“差不多”就是你能拿到的最有力的范围依据。真正让你翻车的，永远是你以为你懂了、但从未让用户确认过的那些“隐性关键词”。需求分析说白了不复杂，词扒准了，话问透了，文档就有东西可写，后面开发、测试、验收全链条都会跟着顺畅起来。