企业官网建设流程全解析

写代码的人这两年多少都有点同感：AI工具确实好用，但AI写出来的东西也开始自带一种“模板味”。打开一份技术总结，开头是“首先”，中间是“其次，从XX角度来看”，结尾再来一句“综上所述，通过XX可以提升整体效率”。说不上哪里错，但一眼就认出是机器生成的。这种“AI味”不是文笔问题，而是概率统计的副产品。今天的主题是三个我实际在用的开源工具，分别解决三件事：去AI味、画架构图、让AI自动干活。这几个方向是我在日常写文档、做方案、整理信息时反复用到的，跑过几个月，踩完坑之后留下的稳定方案，不是那种装了就跑不起来的Demo。

适用的人群很广：要写技术文档和PRD的工程师、画方案图的产品经理、每天整理信息流的运营，都能在里边找到能直接抄作业的部分。下面我把每套工具怎么做、为什么这么做、坑在哪，都摊开讲清楚。

1. “AI味”的病根不是词穷，是模型的惯性统计

想去除AI味，先得搞清楚AI味是哪来的。大语言模型生成文本时，每吐一个字都是从概率分布里采样。为了尽量不犯常识错误，它会倾向选择那些上下文衔接最顺、频率最高、最“安全”的词。人在写作时会有意制造变化和节奏感，模型却在默认情况下走一条最平稳、最省事的路。结果就是：结构高度对称、连接词密集、每段都是“观点+解释+例子+总结”的标准闭环。

我总结了三个最常出现的机器特征：

• 连接词泛滥：“首先”“其次”“最后”“通过”“对于”“随着”成片出现，像是齿轮一样精确咬合。
• 句式过于规整：一排排并列短句，结构完全相同，读起来没有呼吸感。
• 收尾必有总结：每个段落都要概括一遍，生怕读者看不懂。

这种文本放到任何平台上，都会被一眼识别。更麻烦的是，很多写作者用大模型写完初稿后，不做二次结构处理就直接发布，久而久之读者会对这类内容形成免疫。

1.1 先用开源GLTR定位“机器气味”最重的句子

去AI味的第一步，不是拿着一个“AI检测器”对整篇文章打分，而是先定位哪些句子最像机器写的。我用的是开源工具GLTR（Giant Language Model Test Room）。它的思路挺巧妙：输入一段文本后，它会统计每个词在模型概率分布里的排序位置。如果整段话里大部分词都是模型认为概率最高的那些词，那基本可以判定这段更像机器生成的；反之，那些概率排序靠后却出现的词，反而是人类写作中常见的“意外”。

把GLTR当探针用，能很快找到一篇AI生成稿里最僵硬的片段。比如我之前处理一份AI写的方案，全文跑了一遍，发现不是整篇都“臭”，而是集中在两处：一段排比式的优势分析，和一段连接词密集的背景铺垫。只看这两段，心里就有数了。

1.2 本地模型重写：我用的是Ollama加Qwen2.5-7B

定位完问题，接下来就是改写。市面上去AI味的在线服务不少，但把自己的文本丢给第三方，对很多团队来说有数据泄露顾虑。我的做法是在本地跑开源大模型，用Ollama加载一个Qwen2.5-7B-Instruct，再配一套专门的去模板化提示词。

为什么选7B而不是更大或更小的模型？1.8B级别的模型重写能力太弱，改完以后语法崩坏，还得花更多时间人工修；72B级别在普通机器上推理速度太慢，来回迭代几轮根本受不了。7B配合INT4量化，在16G内存的机器上就能较流畅运行，改一段200字左右的文本，实测大约30到40秒，属于能接受的节奏。

提示词我迭代了很多版，最稳的一版长这样：

你是经验丰富的技术编辑，正在修改一篇由AI生成的文章。 你的任务不是润色，而是“去模板化”： 1. 把“首先/其次/最后”“通过/对于/随着”这类连接词能删就删； 2. 把结构完全对称的排比句打散，改成自然语序； 3. 不要总结段，不要在本该延续内容的位置加入概括； 4. 句子长度控制在4到20字之间，允许口语化表达； 5. 保留所有技术名词和结论，不许篡改事实。 只输出修改后的完整文本，不要任何解释。

用到命令行时，可以这样：

ollama pull qwen2.5:7b-instruct ollama run qwen2.5:7b-instruct --system "$(cat rewrite_zh.txt)" "你的原文本……"

改前和改后的对比很明显。改前是：“首先，随着微服务架构的发展，系统复杂度不断提高，因此我们需要引入服务网格来加以解决。”改后可能是：“微服务架构带来的复杂度，单靠服务拆分已经压不住了。服务网格是目前我比较看好的解法。”信息量没少，但那种“齿轮感”不见了。

这里要提一个关键经验：不要指望模型一次性把一整篇长文去味。我在实际使用中每次只喂一段，每段不超过200字，改完人工扫一遍再接下一段。原因很简单，小模型在长文本上注意力容易涣散，会把前面的信息改丢。分段处理虽然麻烦，但质量最可控。

1.3 为什么不在这一步用闭源在线服务

有朋友问我，直接用GPT-4或者Claude重写不行吗？当然可以，但我更看重的是流程能不能固化成团队可复用的工具链。本地模型付费少、延迟可控、文本不外流，而且通过Ollama提供的统一接口，后面接什么模型都方便。只要换一个模型名，整条管道不用动。这种可替换性，是闭源在线服务很难给到的。

2. 架构图从拖拽变成代码生成：用diagrams这个库画图

聊完去AI味，再来说画架构图。这可能是程序员日常里最容易被低估时间成本的工作之一。用Visio或ProcessOn拖拽，画第一版的时候挺轻松，但一旦需求变动，改连线、挪框、调布局，半小时就没了。如果架构图还要交付给多人协作评审，那更要命。我的解法是把架构图当成代码来写，用开源项目diagrams完成从文本到图形的自动生成。

2.1 为什么我选diagrams而不是其他绘图方式

在选型前我先对比了几种方案：

diagrams最大的优势是它自带各大云厂商的图标资源，AWS、GCP、Azure、阿里云都有对应的Node类型，画云架构图时不用自己找图标素材。它底层依赖Graphviz完成布局和连线，所以出图线条相对规整。更关键的是，一张图就是一段Python代码，放进Git仓库里，每一次改动都有记录。这个特性对需要持续演进的系统架构图来说，价值实在太高了。

2.2 画一张微服务架构图，其实就这么几步

首先安装依赖：

pip install diagrams # Mac brew install graphviz # Ubuntu sudo apt install graphviz

没有Graphviz，diagrams跑不起来。这个坑几乎是新手必踩，先装好。

然后准备一个Python文件，画一张微服务架构图：

from diagrams import Diagram from diagrams.aws.compute import ECS from diagrams.aws.network import ALB, Route53 from diagrams.aws.database import RDS from diagrams.aws.elasticache import ElastiCache from diagrams.aws.storage import S3 with Diagram("微服务架构参考图", show=False, direction="LR"): dns = Route53("域名解析") lb = ALB("负载均衡") services = [ ECS("订单服务"), ECS("用户服务"), ECS("支付服务"), ] cache = ElastiCache("Redis缓存") db = RDS("MySQL主库") obj = S3("对象存储") dns >> lb >> services services >> db services >> cache services >> obj

运行python arch.py，当前目录下会生成一张微服务架构参考图.png。整个过程不需要手动拖任何一个框。节点之间的连接用>>操作符表达，顺序和方向一目了然。

如果图里需要表示多个可用区或集群边界，可以直接用Cluster分组：

from diagrams import Diagram, Cluster from diagrams.aws.network import ALB from diagrams.aws.compute import ECS with Diagram("多可用区部署示意", show=False): with Cluster("可用区A"): svc_a = ECS("服务A") with Cluster("可用区B"): svc_b = ECS("服务B") lb = ALB("入口") lb >> [svc_a, svc_b]

这样生成的图，层级关系清晰，比手动在画布里拖出来的效果更“程序员友好”。

2.3 画完图之后：导出、嵌入文档和版本管理

很多第一次用diagrams的人会问：能不能导出其他格式？diagrams默认输出PNG，对于大部分团队的文档和PPT展示来说够用了。如果你需要矢量图，可以基于Graphviz的底层机制去转SVG或PDF，办法是先把图存成dot格式再手动转换，但日常使用中我几乎不这么干，PNG直接丢进文档里最省事。

真正值得说的是版本管理。以前用拖拽工具画图，版本变化只能靠“另存为v2”来解决，特别容易乱。现在图就是一段代码，两个版本之间的差异就是Git diff，评审时能直接看到哪个服务加了节点、哪条连线改了位置。这一点在多人协作时体验非常明显。

另外一个容易踩的坑是中文乱码：diagrams生成的图里，如果节点用了中文标签，在无头服务器上经常渲染成方块。这是Graphviz缺中文字体导致的。我在服务器上装一个fonts-noto-cjk包就解决了。如果你在容器里跑，别忘记把字体包加进去。

对比下来，我用diagrams越久越觉得，架构图不该是一次性拖出来的成品，而应该是跟着代码一起演进的活文档。它服务的不是某一次汇报，而是长期的系统维护。

3. 自动干活不是让AI自由发挥，是给AI派活：用CrewAI编排多智能体

自动干活是这三件事里听起来最酷、但其实最容易翻车的。很多人以为所谓“AI自动干活”，就是给Agent一个目标，然后它自己规划、自己行动、自己交付。实际操作下来，这种完全自由的目标驱动模式失控概率太高了，Agent容易跑偏，中间还可能做出不可预期的操作。我更倾向用一个可控的编排框架：角色、任务、流程都定得明明白白，然后把重复性的琐碎工作交给Agent去跑。

这就是我用CrewAI的原因。CrewAI的核心是把AI工作拆成几个不同的Agent，每个Agent承担一个角色，每个角色负责一个Task，最后通过定义好的流程串起来。听起来抽象，我拿一个实际例子拆开讲。

3.1 一个可以直接套用的日报整理例子

假设你每天需要关注AI基础设施和开源大模型领域的最新动态，然后把信息整理成一份300字以内的技术日报。这项工作内容是固定的，费时，但又没难到非要人来做。我把它拆成两个角色：

• 情报员Agent：负责搜索和收集一天内值得关注的开源项目变化。
• 编辑Agent：负责把原始素材压缩成简短技术日报。

对应CrewAI里就是两个Agent、两个Task，按照先后顺序执行。示例代码：

from crewai import Agent, Task, Crew, Process researcher = Agent( role="开源情报员", goal="收集与 AI 基础设施、开源 LLM 相关的当日动态", backstory="你是一位追踪开源项目的技术编辑，擅长从主流平台快速筛选信息", verbose=True ) writer = Agent( role="日报编辑", goal="将原始素材压缩成 300 字以内、分三段的简明日报", backstory="你是多年科技媒体编辑，文字简洁，不写空话", verbose=True ) collect_task = Task( description="搜索今天 AI 基础设施领域的开源项目变化，列出最近 release、关注度明显上升的项目，附上关键词", agent=researcher, expected_output="结构化素材列表" ) summary_task = Task( description="根据素材写当日技术日报，结构：项目动向 / 潜在风险 / 值得关注。总字数不超过 300", agent=writer, expected_output="一段可发布的日报文本" ) crew = Crew( agents=[researcher, writer], tasks=[collect_task, summary_task], process=Process.sequential ) result = crew.kickoff() print(result)

先安装CrewAI：

pip install crewai

默认情况下，CrewAI的Agent会通过OpenAI兼容接口调用大模型。如果你和我一样想接本地Ollama，只需要设置两个环境变量：

export OPENAI_BASE_URL=http://localhost:11434/v1 export OPENAI_API_KEY=ollama

这样整条链路就可以跑在本地模型上，不用消耗在线API额度。如果你用商用模型，正常配置API Key就行，原理一样。

3.2 为什么我不用AutoGPT而是用CrewAI

AutoGPT这类全自主Agent确实很吸引人，但我实际用下来发现一个问题：它把所有决策交给模型，链路越长，模型越容易在前面的某个环节偏掉。一旦偏掉，你还要花时间追踪它到底做了什么，结果未必比手工操作快。

CrewAI的思路是把“自由发挥”约束成“明确分工”。角色、目标、任务边界都预先定义好，Agent不会脱离角色去发挥，这一步更适合真实的工程协作。简单说，AutoGPT是让AI当全能选手，CrewAI是让AI进公司的项目组，前者听起来美好，后者才真能干活。

3.3 自动干活最容易忽略的坑：输出长度失控

多智能体编排第一版跑通后，我遇到的第一个实际问题不是智能体不工作，而是上下文被撑爆。前一个Task如果让Agent自由输出，它可能会吐给你几千字的素材，这些内容全会作为上下文传给下一个Agent。然后第二个Agent可能还要在这些素材上做二次整理，结果就是输入输出都膨胀，本地模型的推理时间肉眼可见地上升。

解决办法是在每个Task描述里限定输出格式和长度。比如“只输出列表，不要展开解释”“总字数不超过300字”。这样做一是省token，二是让下游Agent的输入更干净，产出也更稳定。这是我想特别提醒的一点：编排多智能体，本质上是定义一套清晰的接口规范，而不是放任它们自由吞吐。

到现在为止，CrewAI在我这里承担的就是这种“有边界的自动化”。它能自动跑定时日报、整理信息、生成初稿，但每一步产出都有人做节点确认，不会让它全权接管。

4. 三个工具串起来用：我的日常流程和踩坑记录

单个工具写起来各是一块，实际用的时候，它们是互相配合的。我分享一下目前跑得比较顺的日常工作流，以及记录过几次的踩坑经历。

整体流程大概是这样的：

1. 早上，CrewAI开始跑日报任务。情报员收集素材，编辑整理成简报，我花五分钟把内容核一遍。
2. 下午写技术文档，需要架构图时，直接改Python代码生成diagrams图。
3. 文档里的背景、总结、描述性段落，先用大模型起草，再走本地Qwen去味。
4. 关键的对外内容，用AI味探针抽查一遍，发现可疑语句再局部重写。

这套组合下来，重复性工作的耗时大概缩了一半，而且产出质量比我从前纯手写要稳定。

4.1 坑一：本地模型的重写速度与质量不可兼得

用Ollama跑7B模型，在CPU上推理确实不算快，单次重写一段200字文本需要三十多秒。如果一次性改完整篇文档，这个时间还是有点熬人的。我试过换更小的3B模型，速度上来了，但重写时会自作主张夹带一些原文没有的表述，反而需要更多人工校订。所以在速度和质量的平衡点上，我最后回到7B模型。如果你只是偶尔去味，3B可以接受；如果天天高频使用，建议给本机加一块GPU，或者直接接受7B这种节奏。

4.2 坑二：Graphviz字体问题导致架构图中文乱码

diagrams刚跑通的时候，我在一台无图形界面的服务器上生成架构图，图片能生成，但所有中文标签都变成方块。排查了很久，才发现不是代码问题，而是Graphviz在无头服务器上没有中文字体，渲染回退失败了。装一个fonts-noto-cjk后问题立刻消失。如果你的使用环境也是容器或无桌面环境，记得提前处理字体，不然图片细节很难看。

4.3 坑三：CrewAI对Python版本有要求

如果你在Python 3.9的旧项目里pip install crewai，大概率会遇到依赖报错。CrewAI新版本对Python解释器版本有明确要求。我一开始在3.9环境里装不上，切换Python 3.11后才顺利跑通。如果你要集成进现有项目，建议先确认Python版本，否则光装依赖就能折腾一小时。

4.4 坑四：本地小模型在多个Task之间容易重复输出

CrewAI跑了几天以后，我注意到两个Task的产出有时高度雷同。原因是本地7B模型在遇到相似输入时，倾向于生成相似输出。比如收集素材和整理日报，两个Task如果描述相近，第二天和第三天的结果就可能出现大量重复。解决办法是在Task描述里强制加一些变化维度，比如“必须提及与前一日不同的项目”“如果有重复项目，重点提炼更新的结论”。小模型不像大模型那样主动寻求差异化，需要靠任务定义去约束。

4.5 什么时候别用这套工具

这些工具不是万能钥匙。给客户画一张一次性的沟通草图，拖拽工具可能比写代码更快；写几千字的品牌营销终稿，7B模型去味会丢失太多节奏感，不如自己手动调整；需要精确数据分析的报表，也不建议让Agent全程自动，宁可让它只负责初筛，再由人来做判断。工具的价值在于把重复流程标准化，不在于替代人的判断力。

最后再分享一个小习惯：每次新搭一个开源工具，我会先建一个最小可用的脚本，跑通以后再考虑接进工作流。不要一开始就追求大而全的自动化管道。这套组合我用了差不多两个月，最大的体会是，三个工具真正发挥效果不是在各自独立的时候，而是当它们配合起来：去味工具让AI产出的文字能见人，diagrams让架构图变成可持续维护的资产，CrewAI让重复劳动有边界地自动化。把这套流程沉淀下来，AI才真正是你手里的生产力，而不是一个偶尔惊艳、经常费时的玩具。