企业官网建设流程全解析

文档越来越多，真正的问题却不是“存在哪里”，而是：谁能看、能不能快速找到、AI 回答有没有依据、内部知识能否继续转化为内容。

本项目是一套可私有化部署的多部门权限企业知识库。它用 Spring Boot + React 管理文档与权限，用关键词和向量检索定位知识，用 DeepSeek 完成 RAG 问答，并通过火山方舟生成可审校的微信公众号文章初稿。

一句话看懂：

文档入库 → 部门隔离 → 分块索引 → 语义检索 → 有来源问答 → 公众号内容复用。

当前版本：2.1核心技术：Spring Boot 2.7、React 18、MySQL 8、DeepSeek、火山方舟、可选 Milvus

读完你会知道：部门权限该放在哪一层、RAG 问答如何保证有出处、这套方案和 Dify / 语雀 / 企业网盘的区别，以及怎么从零部署起来。

一、为什么要做：文档很多，却问不准、管不住

1.1 为什么要做

企业知识管理经常卡在四个地方：

1. 资料散：制度、手册和项目经验分散在网盘、群文件与个人电脑。

2. 检索慢：文件名记不清，关键词不一致，知道“有这份资料”却找不到。

3. 回答虚：通用大模型不了解企业内部事实，答案听起来合理，却无法核验。

4. 复用难：内部资料很多，对外写案例、公众号和项目介绍时仍要重新整理。

这个项目没有再造一个网盘，而是让文档进入一条可持续使用的知识链路：

上传原文 ↓ 解析并分块 ↓ 关键词 / 向量检索 ↓ RAG 问答与来源引用 ↓ 公众号文章初稿与人工终审

1.2 项目能解决什么

1.3 产品边界

• 系统提供可核验的知识入口，不替代正式制度原文。

• 公众号功能生成的是可编辑初稿，不替代人工事实核验。

• 微信能力只同步到草稿箱，不自动群发。

• 小规模知识库可直接使用内存向量检索，大规模场景再接入 Milvus。

二、适合谁，不适合谁

2.1 适合谁

• 中大型企业：需要部门级资料隔离和统一知识入口。

• 技术团队：需要检索规范、API 文档、故障记录与项目经验。

• 制造与工程企业：需要复用设备手册、SOP、项目案例和维保资料。

• 咨询与项目制团队：需要快速查找历史方案与行业案例。

• 内容运营团队：希望基于企业真实资料生成公众号文章初稿。

2.2 不适合谁

• 只需要个人笔记：语雀、Notion 等工具更轻。

• 需要复杂 Agent/Workflow 编排：应选择专门的 AI 应用平台。

• 希望完全无人审核自动发文：本系统明确保留人工终审环节。

三、它到底是什么：存、搜、问、写中台

3.1 一句话定位

企业知识资产的“存、搜、问、写”中台。

它位于文件存储与通用大模型之间：先解决权限和知识检索，再让 AI 基于可见资料回答和写作。

3.2 四条设计原则

1. 权限不是页面筛选，而是后端接口级约束。

2. 问答不是裸聊，而是检索增强生成（RAG）。

3. 写稿不是凭空创作，而是优先复用企业知识。

4. AI 能力可选，关键词检索等基础链路仍可独立工作。

四、技术架构：从上传到写稿怎么跑通

4.1 整体架构

flowchart LR U[浏览器] --> N[Nginx /knowledgeWeb] N --> F[React 18 管理后台] N --> B[Spring Boot 2.7 API] B --> DB[(MySQL 8 / H2)] B --> FS[本地文件存储] B --> AI[DeepSeek / 火山方舟 / Embeddings] B --> V[(可选 Milvus)] B --> WX[可选微信草稿箱]

4.2 核心技术栈

4.3 四条核心业务链路

文档入库

上传 → Tika 解析 → 文档落库 → process-and-index → KnowledgeEntry 分块 → 可选向量化

智能搜索

查询 → 部门权限过滤 → 关键词/向量召回 → 相似度排序 → 返回来源

智能问答

问题 → 检索知识条目 → 组装上下文 → DeepSeek 生成 → 保存会话与来源

公众号写作

主题 → 权限内取材 → 火山方舟生成 → 富文本复制/草稿箱 → 人工终审

4.4 权限与配置

登录后由 JWT 标识用户，@PreAuthorize控制角色，PermissionUtil继续按department_id过滤数据。

运行时配置保存在data/runtime-settings.json，系统配置页保存后生效：

• DeepSeek 智能问答

• 火山方舟公众号写稿

• Embeddings 语义检索

• 微信公众号草稿同步

• OCR

五、核心能力：权限、检索、问答、写稿

5.1 用户与部门权限

用户可关联多个部门。文档、搜索、问答和公众号取材均按可见部门过滤。

5.2 文档管理与知识索引

• 支持 PDF、Office、TXT、Markdown、HTML 等常见格式。

• 支持单文件与批量上传。

• 上传后调用process-and-index生成知识条目。

• 支持分类、部门归属、索引状态与删除操作。

• Embeddings 不可用时仍可使用关键词检索。

5.3 智能搜索与 RAG 问答

• 关键词检索负责稳定兜底。

• 向量检索解决“意思相同、措辞不同”的召回问题。

• 问答支持多轮会话和来源引用。

• 会话按用户隔离，不能读取他人的sessionId。

• DeepSeek 未配置或不可用时，可退回本地知识片段整理。

5.4 公众号文章助手

系统先检索用户权限范围内的知识，再调用火山方舟生成文章。

默认模型：doubao-seed-2-1-turbo-260628深度思考：默认关闭，codeplan.thinking=disabled

当前体验包括：

• 预计生成进度条

• 今天/昨天/更早的历史分组与折叠

• 单条历史删除

• 富文本“复制到公众号”

• Markdown 复制

• 可选同步到微信草稿箱

当前生成接口为非流式。固定业务开销较小，等待时间主要取决于模型输出字数。进度条是体验层估算，并非真实 Token 进度。

5.5 工作台与系统管理

• 总文档、知识条目、未索引文档、用户/部门等统计。

• 今日问答、上传、登录及存储占用。

• 统计卡片可点击进入对应业务页面。

• 用户、部门、运行时配置和审计日志集中管理。

六、和网盘、通用大模型比，差在哪

6.1 权限贯穿完整链路

部门权限不仅作用于文档列表，也覆盖搜索、问答和公众号取材，避免前端隐藏但后端仍可访问的问题。相对普通网盘的目录权限，这里是后端接口级约束。

6.2 AI 可增强，也可降级

Embeddings 或 DeepSeek 暂时不可用时，系统仍保留关键词检索与本地知识整理能力，避免所有功能绑定单一外部服务。相对“只会聊天”的通用大模型，这里先检索企业资料，再生成回答。

6.3 对内知识可以继续对外复用

同一批经过权限管理的资料，既服务内部查询，也可用于公众号初稿，减少重复整理素材。

6.4 适合 Java 技术体系私有化落地

后端为 Spring Boot 可执行 jar，前端为静态资源，生产环境可使用 MySQL + Nginx；对于已有 Java 运维体系的企业，上手路径清晰。

6.5 小库轻量，大库可扩展

小型知识库无需先部署 Milvus；数据量增长后，可通过-Pwith-milvus构建并接入 Milvus ANN 检索。

七、怎么装：本地启动与生产部署

7.1 环境要求

• JDK 8+

• Maven 3.6+

• Node.js 16+

• MySQL 8（本地开发可使用 H2）

• Nginx 1.18+（生产推荐）

7.2 本地启动

# 后端：H2，默认 8080 cd backend mvn spring-boot:run -Dspring-boot.run.profiles=local # 前端：默认 3000 cd frontend npm install npm start

访问：http://localhost:3000/本地账号：admin / admin123

7.3 生产构建

# 后端默认包 cd backend mvn clean package -DskipTests # 产物：backend/target/knowledgebase.jar # 前端 cd ../frontend npm install npm run build # 产物：frontend/build/

需要 Milvus SDK 时：

cd backend mvn clean package -DskipTests -Pwith-milvus

7.4 生产运行

java -Xms512m -Xmx1024m \ -jar backend/target/knowledgebase.jar \ --spring.profiles.active=prod

建议通过环境变量提供数据库密码、JWT Secret 和外部 API Key，不要提交到仓库。

关键配置：

server.port=13085 deepseek.api.key=${DEEPSEEK_API_KEY:} codeplan.api.key=${CODEPLAN_API_KEY:} codeplan.model=${CODEPLAN_MODEL:doubao-seed-2-1-turbo-260628} codeplan.thinking=${CODEPLAN_THINKING:disabled} embeddings.enabled=${EMBEDDINGS_ENABLED:true} milvus.enabled=${MILVUS_ENABLED:false}

7.5 Nginx 核心配置

location /knowledgeWeb/ { alias /etc/www/website/knowledgeWeb/; try_files $uri $uri/ /knowledgeWeb/index.html; } location /knowledgeWeb/api/ { proxy_pass http://127.0.0.1:13085/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }

完整示例见nginx.conf。

7.6 验证与测试

# 健康检查 curl http://127.0.0.1:13085/api/auth/health # 后端测试 cd backend && mvn test # 前后端 E2E cd e2e npm install npx playwright install chromium npm test

八、四个落地场景

8.1 制造业：设备手册与 SOP

资料：设备说明书、工艺文件、质量标准、维修记录。

路径：批量入库 → 部门隔离 → 员工提问 → 查看来源原文。

价值：减少翻找长篇 PDF 和重复咨询，安全与质量要求仍以正式文件为准。

8.2 工程与设备服务：项目内容复用

资料：设备参数、项目案例、施工方案、维保能力。

路径：搜索历史案例 → 生成项目介绍或公众号初稿 → 核对参数 → 复制到公众号。

价值：减少重复整理，提高企业对外内容的一致性。

8.3 技术团队：规范与故障经验

资料：API 文档、编码规范、部署手册、故障复盘。

路径：按项目入库 → 语义搜索 → RAG 问答 → 来源核验。

价值：帮助新人快速定位资料，让经验留在知识库而不是聊天记录里。

8.4 咨询与培训：案例和制度查询

资料：历史方案、培训课件、员工手册、流程与 FAQ。

路径：按部门/行业隔离 → 搜索相似内容 → 提炼要点 → 人工调整。

价值：提高资料复用率，建立统一知识入口。

8.5 落地建议

1. 先统一分类、命名和部门边界，再批量迁移。

2. 优先导入高频、正式、仍有效的文档。

3. 问答效果不好时，先检查知识条目和来源，不要只调模型。

4. 定期清理过期资料，避免新旧制度同时被召回。

5. 公众号文章必须核对数字、型号、客户名称和敏感信息。

九、和语雀、网盘、Dify 怎么选

企业选型时通常会同时看四类方案。它们并非都在解决同一个问题，先分清赛道再比功能，比逐项打分更有意义。第六章讲的是相对网盘与通用大模型的能力差；本章回答「该买哪一类」。

以下对比基于各产品公开的产品定位，不代表其最新版本的完整能力。同类产品迭代很快，正式选型请以官方文档和实际测试为准。

9.1 四类主流方案与本项目的定位差异

9.2 关键能力横向对比

9.3 该怎么选

• 只需要写文档、做协作：选文档协作 SaaS，本项目会显得偏重。

• 只需要存文件、控目录：企业网盘更直接。

• 要做复杂 AI 编排、多 Agent 流程：选 Dify 这类平台，本项目不与其正面竞争。

• 要在企业内落地“有权限、有出处”的知识问答，并希望后台开箱可用：本项目的适配度更高。

• 团队以 Java 为主、要求私有化和可二次开发：本项目的部署与改造成本更低。

9.4 本项目不做什么

坦白讲清边界，比堆功能更有参考价值：

• 不做可视化 Workflow 与多 Agent 编排。

• 不做自研大模型，问答与写稿都依赖外部 API（可替换为兼容接口）。

• 不做微信自动群发，只写入草稿箱。

• 不承诺零人工审核的全自动对外发文。

十、总结：先补文档，再调模型

10.1 一句话回顾

这套系统把企业文档从“存起来”推进到“能问、能追溯、能复用”：统一入库 → 部门隔离 → 分块索引 → 语义检索 → 有来源问答 → 公众号初稿。

10.2 三个关键取舍

1. 权限放在后端，而不是前端。页面隐藏不等于数据安全，因此检索、问答、写稿都在接口层按部门过滤。

2. AI 是增强项，不是唯一依赖。Embeddings 或问答服务不可用时，关键词检索与本地整理仍能工作，避免系统整体不可用。

3. AI 写稿只到初稿。事实核验、排版和发布仍由人完成，这是内容质量与合规的底线。

10.3 适合什么团队上手

文档量已经影响效率、需要部门级隔离、以 Java 技术栈为主、并希望私有化部署的团队，落地路径最短：初始化数据库 → 打包 jar → 构建前端 → Nginx 反代 → 配置 AI Key。

10.4 落地顺序建议

先跑通“入库 → 检索 → 问答”这条主链路，确认来源引用可核对，再开启公众号写稿。知识库质量决定回答质量，优先补文档，而不是反复换模型。