企业官网建设流程全解析

第一次把一段两千字的需求描述粘进文本分析面板、点下分析按钮的时候，我盯着右边跳出来的一堆候选词有点发懵——大部分确实是我写进文档里的名词，但有一半根本不该成为类。后来连着几个项目反复用下来才想明白，这个功能最值钱的地方并不在于"自动生成"，而在于它把一段混着业务口语和半正式术语的文字，强行拆成一张带类型标签的候选清单，逼着你去回答"这个词到底是实体、是动作，还是只是个修饰语"。这件事人工做起来极其枯燥，工具做起来又快又一致，但判断题还得你自己做。

这篇内容围绕 Visual Paradigm 里的文本分析（Textual Analysis）功能展开，讲清楚它是怎么把自然语言需求转成 UML 候选元素的、操作链路长什么样、什么样的文本喂进去效果最好、以及哪些地方最容易翻车。适合两类人看：一类是刚接手需求、准备画第一版领域模型或用例图的同学；另一类是已经画了几年图、但一直在靠脑子硬啃需求文档、还没系统用过这个功能的老手。不需要你熟到什么程度，知道类图和用例图长什么样就能跟上。

1. 文本分析在需求建模里到底在解决什么问题

1.1 从一段业务描述到一张候选清单的转化过程

日常拿到手的原始需求，绝大多数是这个样子：一段话里混着角色、动作、业务对象、约束条件，句子还经常缺主语。比如"运营人员在后台创建促销活动，系统根据活动规则自动计算折扣，活动结束后需要归档历史记录"。人读完能理解，但你要从这句话里抽出类、抽用例、抽参与者，就得在脑子里做一次拆解。

文本分析干的就是这次拆解的机械化版本。它的底层逻辑可以拆成三步：先对文本做分词和词性标注，把句子切成一个一个词并判断词性；再按预设的规则把不同词性的词归到不同类型下面——名词性成分归到类候选，动词性成分结合宾语归到用例候选，指人或指系统的名词归到参与者候选；最后按出现频次和上下文给你排个序，形成一张可勾选的列表。

用生活化的说法，这就像你请了个实习生帮你把一份会议纪要里的"人名""要做的事""要用的东西"分开抄在三张纸上。实习生不懂你的业务，抄得可能不准，但他抄得快、不漏项，而且抄完你一眼就能看出哪条抄错了，改起来比你从头自己分拣省事得多。文本分析就是这个实习生，它的价值建立在"人工复核成本低于人工从头分拣成本"这个前提上。

这里有个容易被忽略的点：候选清单里的每一类并不是平级的。类候选给的是静态结构，用例候选给的是行为，参与者候选给的是边界。这三样凑在一起，恰好是一张用例图和一张初步类图的最小素材集。所以文本分析天然适合放在需求梳理的最开头，而不是等到模型画了一半再回头补。

1.2 名词-动词分析法到今天还没有被淘汰的原因

有人会问，现在都讲究领域驱动设计、事件风暴、用户故事地图了，这种老派的名词-动词分析法是不是过时了。我的看法是，方法论在演进，但"从语言里提取结构"这件事没变。事件风暴贴便利贴，本质上也是在把句子里的名词和动词拆出来分类，只是把工具从软件换成了墙面和纸片。

名词-动词法能活这么久，原因很实际：它不依赖任何前置资产。你不需要先有一份术语表，不需要先跟业务方对齐分层架构，甚至不需要团队里有领域专家坐镇。给它一段文字，它就能吐出一张初稿。对于那种"需求刚到手、什么模型都没有、连边界在哪都模糊"的阶段，这种从零启动的能力非常关键。

另一个原因是它的产物可追溯。从候选清单里勾出来的每一个类，都能对应回原文里的某句话某个词。这在评审时特别好用——业务方质疑"这个类为什么要建"，你可以直接把原文那句高亮指给他看。相比之下，凭经验拍脑袋建的类，事后很难解释来源。

当然它也有明确的短板。它处理不了隐含语义，也处理不了跨句的指代关系。一句"该对象在提交后进入待审状态"里的"该对象"指代什么，工具判断不出来，只能靠人。所以我的习惯是把文本分析定位成"初稿生成器"，而不是"需求理解器"。

1.3 工具能替你做的那部分和不能替你做的那部分

把边界划清楚，用起来才不别扭。以下是我总结的能力对照，按我实际用下来的感受整理：

这张表最关键的一行是最后一行。工具做的是词语级别的合并，而模型需要的是概念级别的合并。一个项目里"用户""客户""会员"三个词，工具会给你三个候选类，但它们可能指同一个东西，也可能确实要分开——这完全取决于业务语境，工具无从判断。

理解了这条边界，你就不会对它抱有不切实际的期待，也不会因为它偶尔犯蠢就彻底弃用。它是个筛子，不是个厨师。

2. 把文本伺候好：进入分析之前的预处理

2.1 按场景切段，而不是把整篇文档一次性倒进去

我见过最常见的用法失误，就是把一份几十页的需求文档整篇粘贴进去点分析。结果就是候选列表里几百个词，光滚动就要滑半天，最后只能凭感觉瞎勾几个，等于白做。

正确的做法是按场景或按功能模块切段，一次分析一段。原因很直接：文本分析出来的候选清单是给当前这一段建模用的，段与段之间的词往往属于不同的限界上下文。你把"下单流程"和"对账流程"混在一起分析，"账户"这个词会被合并成一个候选，但在两个上下文里它可能完全是两个东西。

我通常会这样切：一个用户故事或一个用例场景算一段，长度大概控制在两百到五百字。太短了上下文不足，词性判断会失准；太长了噪声爆炸，人工复核成本陡增。如果一段文本里出现了明显的话题跳转，比如前半段讲下单后半段讲退款，那就果断拆开。

拆段还有一个附带好处：每一段的候选清单可以直接对应到一张图。做完一段就落地一次，模型和文本保持同步，后面回头查证的时候不会乱。

2.2 项目词表与忽略词，是识别噪声的第一道闸

文本分析面板里通常会有忽略词（Ignore Words）之类的配置，可以维护一张"不要识别这些词"的清单。这个东西看着不起眼，实际上决定了候选列表的干净程度。

我的做法是在项目启动时先攒一张基础忽略词表，覆盖三类词。第一类是结构性虚词，比如"系统""平台""模块""功能""界面"这类词——它们几乎在每个句子里都出现，但永远不会成为有意义的类。第二类是项目管理词汇，比如"需求""版本""迭代""评审"。第三类是业务上的通用修饰词，比如"相关""对应""相应""各个"。

这些词如果不排除，它们会因为高频而排在候选列表最前面，把你的注意力全占了。我曾经在一个项目里忘了配忽略词，结果候选列表前十名里八个是"系统""信息""数据"这种词，真正重要的业务实体被压在二十名开外。

反过来说，还有一类词需要放进"强制保留"或者项目术语表，就是那些拼写特殊、容易被切错的专有名词。比如业务里的某个特定单据名称、某个内部叫法，如果不提前登记，工具很可能把它拆成两个无意义的词，或者干脆识别成动词。

提示：忽略词表不是一次配完就完事的。每做完一轮分析，把误识别的词顺手加进去，两三个迭代下来这张表就非常贴合你的项目了，后面新人的分析质量也会跟着上来。

2.3 中文文本的分词和切分策略

这一节说说中文的情况，因为这是绕不开的现实问题。以我手上用的版本为例，文本分析对英文的处理明显更稳，词性标注和短语切分都比较准；中文段落跑下来，常见的现象是长名词被拆开、动词短语识别不出来、整句被当成一个候选。

原因不难理解，英文靠空格分词，词性标注的训练语料也成熟；中文要依赖分词算法，而业务文本里的专有名词恰恰是分词器最不擅长的部分。这不是某个工具的问题，是这类功能共同的边界。

我摸索出来的应对办法有几条。第一条是尽量在文本里给专有名词加上明确的边界标记，比如统一用书名号或者引号把关键实体括起来，很多工具会把这类标记当成分词提示。第二条是把长句拆成短句，每个短句只表达一个动作或者一个对象，主谓宾齐全，这样即使分词有误，人工复核也快。第三条是术语表前置，把核心实体名先登记进去，让分词器有依据。

如果项目允许，还有一个更省事的方案：把核心场景用英文重写一遍再分析，中文版留着做评审材料。这种做法在双语团队里挺常见，缺点是维护两份文本。要不要这么干，看你的项目对建模精度的要求。

不管用哪种办法，中文文本的候选清单我建议默认按"高噪声"对待，复核的时候宁可多花时间，也不要直接信。

3. 跑一次完整分析：从粘贴文本到候选落地

3.1 操作链路的完整拆解

把流程拆开讲，方便你第一次操作时心里有数。不同版本在菜单位置和按钮措辞上会有差异，按功能名去找就行。

第一步是打开文本分析面板。这个入口一般在工具栏或者菜单里的建模辅助工具分组下。打开后通常是一个分栏界面，左边或者上边是文本输入区，右边或者下边是候选结果区。

第二步是粘贴文本。这里我建议直接把预处理好的那一段贴进去，不要带多余的标题、编号、项目符号，纯文字最干净。如果原文里有表格，把表格内容转成一句一句的陈述句再贴，否则行列结构会被打乱。

第三步是配置分析选项。常见的选项包括分析语言、是否启用忽略词表、是否只识别特定类型的候选。如果有"分析语言"的选项，务必选对，选错了分词结果会完全变形。

第四步是执行分析。点下按钮之后，工具会对文本做标注并生成候选列表。这一步通常很快，几百字几乎瞬间出结果。

第五步是复核与筛选。候选列表里每一条前面有勾选框，还有一个高亮按钮可以把该词在原文里定位出来。这一步是整个流程里最耗时的，也是最能体现经验的地方。

第六步是落地。勾选完之后，通常有一个生成模型的按钮，可以把选中的类候选生成到当前类图上，或者把用例候选生成到用例图上。

第七步是清理。落地之后回到图上，把自动生成的位置重新排布，把命名改成符合项目规范的写法。

整个链路走一遍，一段三百字的文本，熟练之后大概十分钟能出第一版图。这个速度是纯手工做不到的。

3.2 候选列表的三轮筛法

复核这件事如果没有章法，很容易变成"看着顺眼就勾"，最后出来的模型质量全靠运气。我一般分三轮走。

第一轮做粗筛，只看两件事：这个词在业务里有没有独立身份，以及它是不是被切错了。判断标准很简单——如果我能用一句话描述它的职责，并且这个职责不会和别的候选重叠，就留下。大于一半的候选在这一轮就能定下来。

第二轮做归并，专门处理近义词和上下位词。"订单"和"订单信息"要不要合并，"客户"和"客户档案"是不是一回事，这一轮要逐个拍板。拍板的时候不要凭感觉，去原文里把两个词出现的句子都调出来对照，看它们在语境里是否可替换。可替换的合并，不可替换的保留。

第三轮做类型修正。工具给出的分类只是建议，经常需要改。比如某个词被识别成类候选，但它在原文里明显是个状态值（比如"待支付""已完成"），那它应该作为枚举或者属性，而不是类。再比如某个动作被识别成用例，但它其实是系统内部的自动行为，不该出现在用例图上。

下面这张表是我常用的类型判定参考，对着它过一遍能省不少犹豫：

3.3 候选落地成模型元素之后还要做什么

勾选生成只是把词变成了图上的方框，离一张能用的图还差几步。这几步如果省掉，图会看起来很热闹但没法用。

第一件事是命名规范化。工具生成的名字直接取自原文，往往是口语化的，还带着"信息""相关""处理"这类尾巴。要在落地后统一改成项目约定的命名风格。这件事不是强迫症，命名直接决定了后面代码生成、接口设计的一致性，前期省事后期加倍还。

第二件事是补关系。文本分析只给你孤立的元素，给不了关系。类之间的关联、聚合、组合，用例之间的包含、扩展，都得手工补。补关系的时候，回头去读原文里那些被跳过的句子——那些句子往往正是描述关系的，比如"一个订单包含多个商品明细"，这种句子对文本分析来说是低价值的（因为它的主体词已经被提取过了），但对补关系来说是高价值的。

第三件事是标记来源。我习惯在每个自动生成的元素上挂一段注释，写上它来自哪一段文本的哪个词。这个习惯在项目后期价值极大，特别是需求变更频繁的项目，某个类要不要删、改了会不会影响别处，一查注释就清楚了。

第四件事是分层。一口气生成的类会全堆在同一层，需要按职责拆到不同包里。这一步建议晚一点做，等候选基本稳定了再动，否则反复挪包很浪费时间。

4. 决定候选质量的那几个变量

4.1 文本本身的规范程度

这一条的重要性超过其他所有变量加起来。同样一个工具，喂规范文本和喂口语文本，出来的候选质量能差出一倍以上。

什么算规范？主语明确，动作有明确主语，实体名前后一致（不要一会儿叫"会员"一会儿叫"用户"），避免大段的名词堆砌，避免一句里套三个从句。达到这个标准的文本，候选清单里七八成是可以直接用的。

现实里大部分需求文档达不到这个标准。我的做法不是去要求业务方重写文档，而是在分析前自己过一遍，做一次轻量的改写。改写的重点是补主语、拆长句、统一术语。这个改写过程大概花十分钟，能省下后面半小时的复核时间，非常划算。

顺便说一个副作用：改写的过程其实也是一次理解的过程。很多时候改到一半，你自己就发现需求里有个逻辑说不通的地方，提前暴露问题总比建模到一半才发现好。

4.2 忽略词表的覆盖度

前面提过忽略词表，这里补充一个细节：这张表要分层维护。项目级有一张通用的，覆盖"系统""模块"这类跨项目通用的噪声词；业务域级有一张，覆盖这个领域特有的高频虚词。两层叠加使用。

维护节奏上，我建议每轮分析结束花两分钟把新发现的噪声词补进去。这件事的复利效应很高——一个十人的团队，如果每个人都有维护习惯，一个月下来能省掉的复核时间相当可观。

另外提醒一句，忽略词表的粒度要控制好。加得太宽会把有效词也挡掉，比如把"信息"整体加进去，那"商品信息""物流信息"这种本来有意义的复合词也会受影响。我的经验是，只有在确认某个词单独出现时永远没有建模价值的情况下，才把它加进忽略清单。

4.3 语义边界的清晰度

同一个词在不同上下文里指代不同东西，这是文本分析最容易出错的地方，也是最难靠配置解决的地方。

举个典型情况：一段文本讲"审批"，前半段说的是发起审批的动作，后半段说的是审批单据这个对象。工具会把两次出现的"审批"合并成一个候选，无论归到哪一类都是错的——正确答案是两个类，一个是用例，一个是实体。

处理这类问题没有取巧办法，只能靠高亮回溯逐条核对。但有个提高效率的技巧：优先核对高频候选。出现次数多的词，往往语义被复用得最多，出错概率也最高。低频词反而可以快速扫过。

还有一个判断技巧：如果一个候选词在原文里出现时，前面跟着的动词不一样（比如"提交审批"和"查看审批"），那它大概率是个对象；如果前面跟的是同一个动词的变体，那它大概率是个动作。

4.4 复核节奏的把控

这一条听起来虚，实际上很影响最终成果。我试过两种极端：一种是分析完立刻一口气复核完，另一种是分析完放一放，隔天再复核。

第一种的问题是会疲劳，复核到后半段注意力下降，判断质量明显下滑。第二种的问题是有延迟成本，隔天回来要重新进入上下文。

我现在的做法是分段复核：每分析完一段，先做第一轮粗筛（快速勾掉明显不行的），然后切到下一段。等三四段都做完粗筛，再回头统一做归并和类型修正。这样既避免了长时间连续判断的疲劳，又保证了归并时有足够的全局视野。

5. 我在实际项目里踩过的几个坑

5.1 把描述性文字原样倒进去，候选全是水词

最早一次踩坑，是把一份产品经理写的功能描述原封不动贴进去。那份文档写得很"产品"，满篇是"用户可以方便快捷地完成操作""系统会智能地推荐相关内容"。分析出来的候选里，"用户""系统""内容"排在前三，"智能""方便""相关"也被当成候选冒了出来。

问题出在形容词和副词上。这类词在文本里高频出现，对建模毫无价值，但工具不知道，照单全收。

规避办法就是我前面说的预处理——分析前花十分钟把描述性、评价性的句子删掉或者改写成陈述句。"用户可以方便快捷地完成下单"改写成"用户提交订单"，候选立刻就干净了。这件事没有技术含量，纯粹是愿不愿意花这十分钟的问题。

5.2 全盘接受候选，模型变成垃圾场

第二个坑是偷懒，想着反正工具都识别出来了，全勾上生成，后面再删。结果生成出来一张四十多个类的图，关系一条没有，命名五花八门，删也不知道从哪删起，最后整张图废弃重画，比手工建还费时间。

这个坑的教训很明确：自动生成的元素必须经过人工确认才能进模型。宁可只留十个确认过的，也不要留四十个待定的。图这个东西，元素一多就失去沟通价值，而沟通价值恰恰是画图的主要目的。

我后来的做法是给候选设一个默认拒绝的态度——凡是我不确定要不要的，先不勾。等整个模块的图基本成型了，再回头看看缺不缺东西。这个顺序反过来了，但效果好很多，因为有了上下文之后判断更准。

5.3 忽略词表配得太狠，把有效信息挡在门外

有一段时间我为了追求候选列表的干净，把忽略词表塞得特别满，结果发现某些本该出现的实体压根没被识别出来。排查了半天才想起来，那个词在前一轮被我一并划进了忽略清单。

这件事提醒我，忽略词表和候选清单一样需要复核。我的补救办法是定期清空重建一次——把忽略词表复制一份出来，逐条问自己"这个词在任何语境下都不可能成为模型元素吗"，答不上来的就移出去。听起来麻烦，但一个季度做一次，成本可以接受。

5.4 把一次分析的结果当成最终模型

最后一个坑，也是最隐蔽的：分析完、图也生成好了，看起来挺完整，就直接拿去评审。评审的时候被问"这个类和那个类为什么没有关系"，才意识到文本分析根本没给关系，而我自己也没补。

这个坑的本质是把"元素齐了"误当成"模型齐了"。一张类图的价值八成在关系上，只有类没有关系，等于一堆散落的词卡。

现在的习惯是，生成元素之后强制自己走一遍关系补全流程：先把所有一对多、多对多的业务规则从原文里找出来，逐条连线；再检查有没有明显的聚合关系；最后给每个类至少挂一个属性，哪怕先写个占位。走完这三步，图才算能拿去讨论。

回头看在文本分析这个功能上花的时间，最值回票价的其实不是那个"一键生成"的按钮，而是它逼着我把需求文本逐句读了一遍。以前靠脑子读，读完以为懂了，其实跳过了一堆含糊的表述；现在被候选清单逼着逐词确认，那些含糊的地方一个都藏不住。工具本身谈不上多智能，但它把一件本该做但一直被跳过的事变得不那么痛苦了，这就够了。

真要说有什么建议，就是别指望一次跑出完美结果。把它当成第一遍粗读的加速器，跑完立刻动手改，改的过程中对需求的理解才是真正沉淀下来的东西。