企业官网建设流程全解析

食味里“川香鸡腿饭套餐”项目结束后，BA林悦做了一次复盘。她发现自己每天都在不同工具之间搬运同一批业务信息。

企微里是商品、研发、供应链和门店的讨论；录音转写里藏着尚未确认的业务规则；OA附件里有新品审批；Excel里维护产品、物料和供应商SKU；流程图记录端到端活动；需求工具保存用户故事和测试；ERP、SRM、WMS、POS、BOH又各有一套编码与状态。

她用AI总结访谈，再把摘要复制到需求文档；用另一段提示词抽取术语，再手工核对原文；发现“产品”存在六种意思后，打开概念模型修改；供应商变更时，又在追踪矩阵、接口清单和测试用例之间逐项搜索。

真正耗时的不是某一次生成，而是证据、候选知识、已确认定义、模型和影响结论不断失去连接。

如果这时去设计一款产品，很容易先画出六个技术模块：大模型、RAG、向量库、知识图谱、本体管理、Agent。可这些名称描述的是实现手段，不是BA为什么会打开产品。

一个“AI业务知识分析台”的边界，应该由BA要完成的任务闭环决定：发现—核实—建模—连接—分析—治理。只要这条链还断着，再多一个聊天窗口也只是新的信息孤岛。

一、不要从功能清单出发，先看BA到底想完成什么

BABOK和《PMI商业分析指南》覆盖的工作很广：规划分析方式、准备和执行启发、确认结果、说明与模型化需求、核实与确认、建立关系、评估变更、评价解决方案。产品如果照着知识领域做八个菜单，会得到一套数字版教材，却未必形成顺畅工作流。

更合适的做法，是用JTBD的方式描述任务：用户不是为了“使用概念提取功能”，而是在某个情境下，希望取得一种可判断的进步。

食味里项目可以提炼出四个高频任务。

这四个任务横跨BABOK多个任务，但用户旅程是连续的。访谈中发现的“供应商SKU”不应在纪要里结束，它可能成为候选概念；专家确认后进入模型；模型中的映射关系又支持变更影响分析。产品要保存的是信息如何从“被说出来”演化为“被组织确认并用于判断”。

二、六步任务闭环，就是产品的一级信息架构

1. 发现：把材料变成带证据的候选项

用户导入访谈、会议纪要、需求文档、流程清单、数据字典或接口样例。AI可以提取需求、术语、对象、关系、状态、规则、假设和未回答问题，但不能把提取结果直接发布为组织知识。

每个候选项都要绑定来源、段落或时间戳、发言人、提取方式和置信提示。BA看到“产品已上架”时，可以并排查看原文上下文，而不是只审一条脱离证据的摘要。

2. 核实：把AI答案变成可确认的问题

核实工作区支持接受、修改、合并、驳回和发起澄清。它还要区分事实、观点、诉求、假设和解决方案建议。AI发现“产品”可能指销售商品或菜品时，不应自动替换，而应生成最小澄清问题：“这里的上架是POS已发布，还是指定门店已可售？”

BABOK把启发结果的确认、需求核实和需求确认分开：准确完整是一类问题，能否支持业务目标又是另一类问题。产品也不应只有一个“通过”按钮。至少要区分“证据准确”“语义已确认”“价值已确认”和“批准发布”。

3. 建模：把确认内容组织成业务含义

经过核实的候选项可以进入轻量模型工作区。用户在这里定义产品、套餐、配方、食材物料、供应商SKU等对象，补充关系、状态和规则；系统提供正反例、重复概念、非法关系、缺少责任人和范围冲突检查。

Ontology Development 101强调，本体开发取决于应用目的，并通过能力问题和迭代不断修订。因此，建模界面不应先给用户一张空白巨图，而应先问：“模型需要回答什么？”

食味里的能力问题可能是：某门店为什么不可售？某个物料变化会影响哪些配方？一个供应商SKU映射哪个总部物料？

4. 连接：让不同分析成果保持关系

模型不是孤立概念图。产品要连接业务目标、能力、需求、流程、规则、数据、测试和系统部件，并区分起源、依赖、满足、验证、约束、使用和影响等关系。

每条关系带方向、范围、时间、证据、责任人、版本和可信状态。用户可以用矩阵评审，也可以用网络浏览；底层维护同一份关系资产。这样，测试用例TC-18不是“关联”门店可售需求，而是验证指定规则版本和异常场景。

5. 分析：让AI沿业务路径工作

当MAT-CHKN-010被批准为替代物料，AI从变更起点沿供应、映射、替代、使用、组成和验证关系展开，找到采购、配方、库存批次、门店可售、订单追溯、接口和测试。

分析结果必须区分确定影响、可能影响和待确认影响，并显示每一跳的关系与证据。关键词检索可以帮助找材料，语义网络帮助找候选路径，规则与状态决定路径是否在当前范围内成立，领域专家负责最终裁决。

6. 治理：让知识能够长期被信任

确认后的概念、关系和规则要有owner、版本、生效时间、审批记录和退役机制。AI运行本身也要形成记录：使用了哪些资料与模型版本，生成了哪些候选，谁修改了结论，最后发布了什么。

《企业本体建模方法与实战指南》把治理放进对象、关系、逻辑和行动的整个生命周期，而不是上线前补一张审批表。《本体驱动的AI数据管理》强调事实、事理与行动要能留下来源和过程痕迹。

对分析台而言，聊天记录不等于审计记录；真正可审计的是“证据—提取—人工修改—批准—发布—使用”的完整链。

三、首版核心能力，不是六个技术模块

把六步闭环转成产品能力，可以收敛为五个工作台。

证据工作台。管理材料、版本、段落和时间戳；支持原文与候选项并排查看；记录权限与来源。它解决“结论从哪里来”。

候选知识工作台。从材料中提取需求、概念、关系、规则、状态和问题；支持批量筛选、去重、分类及证据定位。它解决“AI发现了什么”。

确认与模型工作台。支持概念边界、同义词、关系、状态和规则确认，运行一致性检查，形成最小模型版本。它解决“组织同意什么”。

连接与分析工作台。建立追踪关系，执行歧义检查、覆盖检查和变更影响分析，输出路径、影响等级和责任清单。它解决“这些知识能帮助判断什么”。

发布与治理中心。管理角色权限、评审任务、语义裁决、版本比较、发布、退役和审计。它解决“谁有权改变，改变后如何追责”。

向量检索、图存储、文档解析和模型调用都可能出现在技术架构里，但它们不应成为首页导航。用户关心的是完成任务，而不是今天数据进入了哪个数据库。

四、AI需求助手和本体产品，哪些应该共用

这两个产品方向既不能完全分开，也不能粗暴合并。

共用的核心不是一个聊天框，而是证据、身份、术语、关系、版本和权限。AI需求助手面向一次分析任务，提高访谈、需求和评审效率；本体产品面向可复用的组织语义资产，管理跨项目对象、关系、规则和运行映射。

首版分析台可以同时包含两者的薄切片：用需求助手把材料变成候选知识，用轻量本体工作区确认概念与关系，再用同一关系网络完成影响分析。但不要在MVP中承诺完整企业本体运行时、自动回写业务系统或全域主数据治理。

五、人在环路不是加一个“人工确认”按钮

AI适合做大规模阅读、候选提取、相似项聚合、问题生成和路径搜索；BA负责分析目的、证据质量、跨材料综合和工作组织；领域专家负责概念、规则和例外的业务裁决；资产owner批准发布；系统管理员负责权限、模型配置和审计策略。

不同风险的动作需要不同门槛：生成候选项可以自动完成；合并同义词需要BA确认；修改已发布概念要做影响分析；发布食品质量规则需要质量负责人批准；向ERP或WMS回写则不在首版范围内。

Microsoft Research的人机协作指南提出了一组跨场景设计原则，关注AI能力边界、用户控制、纠错和反馈。

落到本产品中，就是始终显示AI做了什么、依据什么、哪里不确定；允许用户修改和撤销；把纠正沉淀为后续规则与评测样例，而不是让用户每次从头纠错。

权限也不能只做到“能否打开项目”。原始访谈、成本、供应商合同和质量资料可能具有不同可见范围。用户可能有权看概念定义，却无权查看合同价格；有权提出规则变更，却无权批准发布。

AI只能读取当前用户和当前任务被授权的内容，并在输出中保留来源权限。

六、MVP怎么切，才不会一开始做成平台工程

MVP选择食味里新品上线复盘作为单场景，不追求覆盖所有BA活动。

MVP必须闭环：导入访谈与需求材料；按段落定位证据；提取候选需求、概念、关系和规则；人工接受、修改、驳回与澄清；维护轻量概念与关系模型；建立需求—规则—测试追踪；从一个物料或规则变化生成影响清单；记录版本、责任人与审查结论。

MVP明确不做：实时会议机器人、自动替业务批准、复杂OWL推理、全企业知识图谱、通用低代码平台、业务系统写回、自动生成所有BABOK交付物，以及对所有文件格式的完美解析。

第二阶段再增加流程/状态模型检查、数据模型映射、跨项目复用、评测集、批量变更分析和更多接口。组织级阶段才考虑统一业务上下文服务、跨域本体、策略权限、Agent调用接口、运行监控与受控动作。

Palantir Model Studio的产品资料提供了一个很好的交互类比：它把专业过程组织成选择任务、映射输入、配置参数、启动运行，再把配置版本、训练记录、实验、输出和血缘连接起来。

我们借用的是“向导化任务+每次运行可追溯”的设计思想，而不是把机器学习训练器搬进BA产品。

分析台中的一次“候选提取运行”也应绑定材料版本、提取配置和输出；一次“影响分析运行”应绑定语义模型版本、起点和路径规则。源材料或模型更新后，旧结论显示“可能过期”，提示用户重跑或复核。

七、核心界面应该长什么样

首页不放一个占满屏幕的聊天框，而是放“任务与待决事项”。食味里项目首页可以显示：3份新材料待解析、27条候选待核实、4个术语冲突、2条关系待质量部确认、1项供应商变更影响分析待关闭。

进入工作区后，采用“三栏一抽屉”：

┌──────────────┬────────────────────────┬──────────────────┐ │ 左：项目与任务 │ 中：当前证据/模型/影响路径 │ 右：候选项与审查动作 │ │ 发现 │ 原文定位与高亮 │ 接受/修改/驳回 │ │ 核实 │ 概念、关系、状态模型 │ 指派专家/发起澄清 │ │ 建模 │ 追踪矩阵或语义网络 │ 影响等级/责任人 │ │ 连接与分析 │ │ │ └──────────────┴────────────────────────┴──────────────────┘ 底部抽屉：来源、版本、权限、评论、审批与审计记录

同一对象在不同任务中保持身份一致。用户点击MAT-CHKN-010，可以查看定义、正反例、供应商SKU、替代关系、配方使用、库存批次、相关需求和变更历史；点击某条AI结论，可以反向看到证据与处理记录。

信息架构的关键不是“图很酷”，而是让用户在证据、候选、模型、分析和决议之间来回切换时不丢上下文。图、表、卡片和对话都是视图，底层对象与关系才是连续工作空间。

八、如何判断首版不是一个好看的演示

成功指标要测任务结果，而不是只数生成次数。食味里试点可设定一组待验证目标：候选项证据可定位率达到95%以上；已发布概念与关系100%具备责任人和版本；一次指定物料变更能返回需求、规则、接口和测试路径。

专家应能对每项影响确认、否决或补充并留下理由；典型访谈从材料导入到形成下一轮问题的人工时间，相比当前基线减少30%。

这些数字是产品试验目标，不是既有成绩。还要同时观察误提取率、专家否决率、用户回到原文的频率、过期结论数量和权限错误。效率提升不能以降低证据质量为代价。

产品发现阶段最重要的验证，不是用户是否喜欢概念图，而是他们是否愿意把真实材料放进来，是否能用产品完成一次评审和变更分析，是否愿意在下一项目复用已经确认的概念与关系。

结语：BA需要的不是更会写文档的AI

一个AI需求助手可以更快地生成纪要、用户故事和验收标准；一个本体平台可以管理对象、关系和规则。但BA真正缺少的，是把一次次分析活动连接起来的工作空间：发现有证据，核实有问题，建模有边界，连接有语义，分析有路径，治理有责任。

因此，“AI业务知识分析台”的根本产品边界，不是大模型加向量库加知识图谱，而是一个可完成、可复核、可持续积累的BA任务闭环。

当访谈中的一句话能够沿证据进入候选知识，经专家确认成为模型资产，再反过来支持下一次需求澄清和变更分析，文档才开始转化为组织可以复用的业务知识。这才是这款产品首版应该证明的价值。

【案例说明】 食味里及文中的企业、人物、系统、编码、指标与产品数据均为虚构案例。MVP指标是待验证的产品目标，不代表真实实施结果。涉及食品安全、标签、过敏原、保质期或监管要求时，正式发表与实施前必须核对最新国家标准、法规与企业制度。