企业官网建设流程全解析

最近半年，我身边的开发、产品、运营同事都在干同一件事：把AI生成的内容改得不像AI生成的，把AI梳理的架构落成正经的架构图，再让AI把重复的活直接干完。这个过程中大家试过不少工具，但大部分要么收费、要么绑定平台，最后真正沉淀下来反哺效率的，反而是三个开源工具，正好对应三个高频场景：去AI味、画架构图、自动干活。

这篇内容就是围绕这三个工具展开的。它们不是那种"看起来很强但装完就吃灰"的开源项目，而是我实际用了一两个月、逐步替换掉原有工作习惯的工具。不管你是独立开发者、小团队，还是在大厂做内部工具，这几个工具都能找到用武之地。

先说清楚我要写什么：deai用来处理AI文本的机器腔，PlantUML负责把架构描述变成可维护的架构图，Dify则把所有需要"多步推理+调用工具"的重复流程打包成自动化工作流。每个工具我都会写选型原因、部署方式、实际使用时的参数设置，还有踩过的坑。如果你打算直接照着搭，最后一节的联动流程可以当作模板抄。

1. 选型思路：三个痛点配三个开源方案

1.1 第一个痛点：AI生成内容一闻就知道是AI写的

我自己在写技术文档、周报、PRD的时候，已经习惯先用大模型出一版初稿，再手动改。但改稿的时候最烦的不是内容不对，而是一眼就被AI腔污染了——"首先、其次、最后"这类连接词堆得整整齐齐，"值得注意的是""综上所述""让我们来看"这种过渡句高频出现，形容词永远用"显著的""重要的""深度的"，一句话能说清楚的偏偏要扩成三句。

这种文本不是不能用，但在对外发布、向上汇报、写客户方案时就非常尴尬。解决这个问题的OpenAI工具很多，但大部分都要求把文本传到别人的服务器上，对不少公司来说这一步就过不了。所以去AI味这件事，最好有一个能本地跑、能对接自己模型的开源方案。

1.2 第二个痛点：架构图画出来没人看得懂

再说画架构图。技术团队里几乎每周都要产出系统架构图、微服务架构图。传统的做法是用Visio或者Draw.io手动拖拽，一张图从梳理模块关系到调整排版，半天时间就没了。更麻烦的是图一多就没人维护，模块改了但图没改，过两个月这张图就变成"历史遗留文档"。

如果让AI来画图，事情就变成"我描述架构关系，AI生成图"而不是"我挪方块"。

选型的时候我对比过Mermaid和PlantUML：Mermaid胜在轻量，主流Markdown编辑器直接内嵌渲染；PlantUML则强在严谨的组件关系和更专业的架构图表达能力，尤其是配合C4模型，可以做到从系统级到代码级的分层描述。两者都是开源项目，我没有选边站，而是在"需要快速出流程草稿"时用Mermaid，在"需要交付正式架构图、并且希望图以代码的形式持续维护"时用PlantUML。这篇重点写后者，因为AI在生成PlantUML代码时准确率更高，报错也更容易通过语法排查解决。

1.3 第三个痛点：AI能聊天，但不会自己"干活"

前两个痛点还停留在"AI帮助产出内容"的层面，第三个痛点则是"AI能不能自己把流程跑完"。举个例子：每周一早上，我要收集十几个系统上周的变更记录，整理成周报，再发给各个负责人。这件事本身不复杂，但涉及数据收集、汇总、格式转换、分发四个步骤。如果只用对话式AI，我得不停地复制粘贴；如果写脚本，需求一变就得改代码。

开源的AI Agent方案里，我对比过AutoGen、n8n、Dify。AutoGen偏研究原型，适合开发者深挖多智能体协作；n8n偏通用自动化，AI只是它调用的众多能力之一；Dify则更像是专门为"大模型应用"设计的平台，提供了从Prompt编排、知识库检索到工作流编排的完整界面，业务同学也能上手。我最终把Dify当作主力"自动干活"工具，是因为它把Agent、工作流、RAG这些概念都做成了可视化节点，真正落地到日常流程时迭代速度最快。

2. deai：把AI味洗掉的开源改写工具

2.1 它是怎么做到去味的

deai是一个开源的中文AI文本去味工具，核心逻辑不复杂：先走一遍"坏味道检测"，识别文本里的AI惯用句式、高频连接词、通用形容词，再调用大模型对这些问题片段做针对性改写。它跟"你直接把这段文字改得更自然"这种简单Prompt的区别在于，它把重写限制在"破坏味"的局部，而不是把整篇文本推倒重来，所以原文的事实和逻辑基本不会丢。

我实际使用下来的感受是，它处理三类问题最明显：一是去掉"首先/其次/最后"的机械化排列，二是把"需要注意的是""不可否认的是"这类废话引导词删掉，三是把"赋能、抓手、闭环"这类术语密度降下来。处理完之后，文本读起来更像一个正常人在说话，同时不会因为过度口语化而失去专业性。

提示：去AI味不等于降低内容质量。如果原文本身逻辑混乱，任何改写工具都救不回来。我通常先自己通读一遍确认内容真实无误，再去处理文风。

2.2 安装和配置

deai支持对接任意兼容OpenAI接口的模型，包括Ollama本地跑的Qwen、Llama，也可以接云厂商的API。部署过程很简单：

# 用pip安装 pip install deai # 启动Web界面 deai web

启动之后浏览器打开本地服务，把AI生成的文章粘进去，选择目标风格，比如"职场汇报""技术博客""日常口语"，点改写就能拿到去味后的版本。命令行模式也保留着，适合批量处理文件。

如果想让数据完全不出内网，就用Ollama在本地起一个模型，再把deai的接口地址指向Ollama。我目前就是这么用的：Ollama跑Qwen2.5 14B，deai负责改写，全程不依赖外网API，响应速度取决于本地显卡，我的一张消费级显卡上处理1000字大概5秒。

2.3 自定义风格才是关键

deai真正好用的地方在自定义风格。默认风格是"通用自然"，但如果写技术文档，我希望保留专业术语的同时去掉翻译腔；写周报，我希望句子简短、数据靠前。这些都能通过修改提示词模板实现。我把团队内部的技术文档风格沉淀成了一套模板，包括：句子平均长度不超过30字、不出现"该"字句式（比如"该模块"改为"这个模块"）、动词优先于名词。

这套模板同时喂给deai的改写模型，效果比较稳定。如果团队有自己的写作规范，建议花点时间把规范转成模板，比你用什么模型都管用。

2.4 常见问题

• 改写后部分内容跟原意不一致：这种情况多出现在模型理解了原文但没忠实保留细节。我会把关键数据、专有名词放在单独的"不可改动清单"里，改写前先跟模型声明，或者干脆在改写后diff一遍。
• 本地模型效果不够好：不是所有本地模型都擅长中文改写，实测Qwen系列比同参数的Llama中文表现更稳定。如果条件允许，14B以上的模型出稿质量会更接近商用API。

3. PlantUML：让AI输出架构描述，落地成图

3.1 为什么选中PlantUML

如果你只需要画一张简单的流程图，Mermaid足够。但我画的是微服务架构图，里面有服务、数据库、消息队列、网关，还要表达调用关系、数据流向、部署边界。用Mermaid的flowchart硬画，复杂一点就变成一团乱线。PlantUML的优势在于它有专门的组件图、部署图、时序图语法，更重要的是支持C4模型——这是我在选型时最看重的一点。

C4模型把架构图分成四层：System Context（系统上下文）、Container（容器）、Component（组件）、Code（代码）。每一层解决不同读者的需求：给老板看第一层，给后端看第二层，给新同事看第三层。用PlantUML配合C4，分层架构图能以文本形式维护在git仓库里，每次改动都有记录，再也不会出现架构图和代码不一致的问题。

Mermaid我也想了个办法解决复杂度：让AI生成Mermaid的架构图代码，然后利用StackEdit、Typora这类工具直接渲染，适合从0到1快速出草图。但在正式文档和交付物里，我会把这些草稿转成PlantUML重新绘制。

3.2 让AI生成PlantUML代码

让AI画图的关键在提示词。我总结了一套稳定的写法：

1. 明确告诉AI输出格式是PlantUML代码，并且以@startuml开头。
2. 给出参与角色：系统有哪些服务、数据库、消息队列，它们之间的调用关系。
3. 指定层次：如果画微服务架构图，我会要求AI使用C4的Container级别。
4. 要求AI为每个元素补充一句职责说明，方便后面维护。

举个例子，我给AI的描述是"有一个API网关，三个微服务，每个服务各自连一个MySQL，服务之间通过Kafka异步通信"，AI会生成类似这样的代码：

@startuml title 订单系统微服务架构 skinparam componentStyle rectangle [API网关] as gateway [订单服务] as order [库存服务] as stock [支付服务] as pay [Kafka] as kafka gateway --> order gateway --> stock gateway --> pay order --> (订单数据库) stock --> (库存数据库) pay --> (支付数据库) order -right-> kafka stock -right-> kafka pay -right-> kafka @enduml

这段代码在本地装好PlantUML后，用一条命令就能渲染成PNG或SVG：

plantuml order-system.puml -tpng

3.3 渲染时的几个关键配置

PlantUML的默认样式偏老气，而且如果系统模块超过15个，画布布局会乱。我通常会给AI加两条指令：一是使用skinparam统一元素配色和字体，二是遇到乱布局时用!include C4_Context.puml之类的C4模板强制分层。

中文乱码是全身痛，尤其是在Windows环境。给AI的约定是字体用Microsoft YaHei：

skinparam defaultFontName "Microsoft YaHei"

没有这段配置，生成的图片里中文会显示成方块。这是我在项目里最常踩的坑，没有之一。

3.4 集成进文档工作流

我更习惯把PlantUML代码和生成的图片一起提交到代码仓库。图片给人在线预览用，代码给后续维护用。这样一来，架构图不再是"画一次就过期的图片"，而是跟代码同步变更的活文档。

VS Code装好PlantUML插件后，编辑.puml文件可以实时预览，改完一键导出PNG。配合git，架构调整的前后差异一目了然，code review的时候还能顺便评一评架构变化是否合理。

4. Dify：搭一个自动干活的AI工作流

4.1 Dify是什么

Dify是一个开源的大模型应用开发平台，英文名来自"dify"（让一切变简单）。它解决的痛点是：AI落地到业务流程里，不能只靠聊天窗口，得有工作流、知识库、工具调用、权限管理这些工程能力。Dify把这些能力都做成了可视化节点，你在界面上拖拽连线就能搭建一个应用。

我拿它做的第一个应用是"自动周报生成器"。流程是这样的：

1. 开始节点接收各系统负责人提交的文本变更记录。
2. 一个LLM节点负责把杂乱记录整理成结构化条目。
3. 一个知识检索节点从团队的Wiki里检索历史周报格式。
4. 另一个LLM节点按历史格式生成新周报。
5. 代码节点做最后的格式校验。
6. 结束节点输出周报文本。

整个过程人只需要在最开始粘贴原始记录，后面全部自动跑完。一次配置，每星期复用。

4.2 搭建工作流时的节点选择

Dify的工作流节点类型不少，最常用的是这几个：

• 开始节点：定义输入字段，比如把"变更记录"设成必填文本。
• LLM节点：每个LLM节点可以自由选择模型，我通常将"信息提取"和"格式生成"拆成两个节点，分开调Prompt，效果比一个大Prompt好得多。
• 知识检索节点：连接已有的知识库数据集，给模型补充上下文信息。
• 工具节点：调用外部API或内置工具，比如HTTP请求、搜索引擎、图像识别等。
• 代码节点：写Python或Node.js脚本，处理那些模型不擅长的结构化逻辑。
• 条件分支节点：根据前一步的结果走向不同分支，比如周报没生成就进入错误处理。

第一次搭的时候容易把Prompt写得又臭又长，塞进一个LLM节点。后来我把它拆开才发现：每个节点只做一件事，模型出错率就低一大截，调试的时候也能精准定位是哪一步的问题。

4.3 部署与模型接入

Dify的部署非常简单，只要服务器有Docker，执行：

git clone https://github.com/langgenius/dify.git cd dify/docker docker compose up -d

然后访问http://localhost，在"设置->模型供应商"里填入模型API。如果对接本地Ollama，填http://host.docker.internal:11434就能让容器内的Dify访问到宿主机上跑着的Ollama服务。我这里建议至少配一个云端模型作为备用，因为本地模型在工作流里偶尔会超时，备用模型能保证流程不断。

部署机器建议至少4G内存。Dify本身不重，但加上工作流里跑的模型推理进程，内存太小的服务器会直接把容器OOM杀掉。我自己最初在2G内存的机器上跑，日志里全是Killed，后来升到8G才稳定。

5. 联动实战：一份报告从AI初稿到成品的完整流程

5.1 把三个工具串起来

单独用每个工具都能提升效率，但真正让效率上台阶的，是把它们串成一条流水线。

我现在生成一份系统架构说明书的标准流程是这样的：

第一步，在Dify里搭一个工作流，输入是"业务需求一句话 + 当前系统描述"，工作流里的LLM节点会先输出一份架构设计的文字描述，包括模块划分、数据流、调用关系，同时让它生成PlantUML代码。

第二步，把PlantUML代码复制到本地.puml文件里，渲染成图，再人工调整布局、补充缺失的依赖关系。这一步快的话五分钟，慢的话半小时，比起从空白画布开始拖拽省了太多时间。

第三步，Dify工作流同时输出了一版架构说明书的文字初稿。我把它粘贴到deai里做去味处理，去掉AI腔，再把从PlantUML里导出的架构图插入文档，一份能直接交付的说明书就出来了。

5.2 实际效果和调整

我第一次跑通这条流水线时，一份原本需要一上午的说明书，大概40分钟就出了初稿，后期人工校对只需要集中看技术细节是否准确，文风和排版基本都不用操心。

做这个流程的时候有几个容易翻车的点，我都踩过：

• Dify工作流里，LLM节点输出PlantUML代码时经常前后带```标记，直接粘贴到.puml文件里会报语法错误。解决办法是在工作流里加一个代码节点，用正则把代码块标记剥掉再输出。
• PlantUML图如果模块太多，布局会很挤。解决办法是给AI的要求里写清楚"按调用链路分层，网关在最上面，数据库在下面，同层之间不要有箭头连线"。
• deai改写时会把架构描述里的"调用链"之类的专业词改得过于口语化。我的做法是在deai的自定义模板里声明"保留所有技术名词和缩写，只调整句式"。

5.3 工作流排错的通用思路

这套工具链的报错可以分三类：

• Dify工作流报错：先看是哪个节点报的错，日志里模型API的报错信息一般很明确，多数是模型超时或Prompt格式不对。
• PlantUML渲染报错：从语法错误提示下手，最常见的是漏了结束标记@enduml，其次就是中文字体问题。
• deai改写效果差：不要急着换模型，先检查风格模板是不是跟内容领域不匹配。

排查的时候我习惯"二分定位"：把整条链路从中间断开，先测前半段、再测后半段，哪一半有问题就缩小到具体节点，比一步步顺着流程查快得多。

6. 常见问题与避坑速查

6.1 工具对比与选型速查

6.2 高频踩坑清单

• 不要把所有业务逻辑都塞进一个LLM节点。拆分节点之后，单点Prompt输入更简洁、模型更听话，调试定位也更简单。
• 开源工具要做好版本管理。Dify和deai迭代都很快，升级之前先看release note，我有一次升级Dify后旧工作流里的代码节点API变了，找问题找了半天。
• 架构图一定要进git。用文本形式维护PlantUML的最大好处就是改动可追踪，功能上线后顺手更新图，这个习惯能救团队于水火。

6.3 最后一个建议

我自己在实际使用中最大的体会是：不要为了用工具而用工具。去AI味是为了让内容读起来更可信，架构图是为了让沟通更准确，自动干活是为了把时间留给真正需要判断力的工作。三个工具都指向同一件事——让AI的输出更像一个能交付的人。这个目标想清楚之后，工具怎么选、怎么配就都有了判断标准。