企业官网建设流程全解析

你有没有过这样的场景：想请AI给自己的网页提优化建议，但要么没有服务器预算，要么不想把站点内容上传到别人云上做训练，更别提一个一个去申请接口密钥。后来我搭了一个小工具，全程不花钱、不用后端、不依赖外部接口，直接调用浏览器内置大模型，让它在本地把我的页面内容读完，再按SEO、可读性、结构、无障碍这些维度给出一份优化诊断单。这个标题听起来像是概念演示，实际上落地后，我自己的博客就是靠它找到了好几处被忽略的问题。

所谓“浏览器内置大模型”，可以简单理解为浏览器自己带了一个小型的语言模型推理能力，页面通过浏览器暴露的原生接口就能直接用，不需要你购买算力。使用这个能力来给网页做“免费体检”，尤其适合开发者、内容编辑、独立站长，以及所有不想把内容导出到外部服务的场景。这篇文章我会从为什么选它说起，再到完整实现步骤、提示词设计和踩坑记录，把整个流程拆给你看。

1. 为什么选浏览器内置大模型，而不是云端大模型

1.1 传统AI网页优化方案的三个痛点

如果你此前尝试过用通用大模型来审核网页，大概率经历过这些麻烦：第一是成本问题，调用云端接口按Token计费，稍微长一点的页面来回分析几轮，费用哗哗就上去了，虽然有些平台送新手额度，但长期用总要掂量。第二是数据隐私，网页内容里往往有未发布的稿件、内部产品说明、甚至个人敏感信息，把这些内容粘贴给第三方，始终不踏实。第三是接口依赖，你需要申请密钥、写后端转发、处理限流、应对故障，对只想做一次页面体检的用户来说，门槛明显偏高。

我的做法是把整个分析过程放在本地浏览器里完成，不产生额外的网络请求，也不需要后端服务。网页加载一个纯静态HTML文件，用户粘贴或导入内容，浏览器内置模型在本地生成建议，全程不落盘、不传输。这套思路尤其适合对隐私要求高、又不想付费的个人站长。

1.2 浏览器内置模型到底解决什么问题

浏览器内置大模型带来的核心变化，是“推理能力随浏览器走”。过去我们讨论AI应用，默认要准备服务器或对接外部接口，现在主流浏览器陆续内置了语言模型能力，前端页面可以直接感知当前环境是否具备能力，再决定展示什么功能。

它解决的是两类问题：一类是“轻量分析”，像给网页做逐项检查、读标题、看摘要、对比标签这类任务，不需要大规模推理，小模型完全够用；另一类是“高频迭代”，你可以把页面改一版，立刻再让模型把把关，来回几百次都是零成本。对开发者和内容工作者来说，这个“免费额度”非常香。

同时要注意它也有边界。内置模型的参数规模和上下文长度，普遍小于云端大模型，如果你拿一篇几万字的长文直接让模型总结，它可能只吃得下前面一段。所以实际应用中，我会把页面内容做裁剪、分块，再按模块提问，让每一次交互都聚焦在一个具体分析任务上。

1.3 适合做哪些网页优化诊断

不是所有优化建议都适合让内置模型来做。我测试下来，最稳妥的场景是文本层面的诊断：标题是否吸引人、摘要是否包含关键词、正文结构是否合理、列表和段落是否清晰、语气是否统一。这些任务对上下文依赖高，但对“实时性”要求低，非常适合本地模型。

与页面渲染相关的诊断，比如真实加载速度、图片体积、白屏时间，就不要交给模型了，它看不见也测不准。这类硬性问题更适合用浏览器自身的性能工具去断言。合理划分边界后，内置模型给出的建议才真正有参考价值。

2. 给网页做“AI体检”的整体设计与思路

2.1 功能拆解：一份诊断单应该包含哪些维度

我设计的工具界面很简单，左侧是网页内容输入区，右侧是建议输出区，上方是一排诊断维度开关。默认开启五个维度：SEO基础、可读性、标题结构、图片与链接、无障碍。每个维度对应一段提示词，互不干扰。

为什么要拆维度？因为如果让模型一次性同时分析所有项目，它很容易给出泛泛而谈的套话。拆开之后，每个维度都能落实成具体的检查点，比如SEO维度包括：标题长度是否合理、描述是否缺失、核心关键词是否前置、H1是否只有一个。这样模型有章可循，输出的建议也不会乱。

2.2 整体流程：从网页内容到结构化的建议

整个流程可以分为四段。第一段是采集，用户可以直接粘贴HTML，也可以粘贴网页源码，如果你在浏览器开发者工具里打开目标页面，也能复制整个页面的 outerHTML。第二段是清洗，把HTML转成纯文本结构，去掉样式、脚本，只保留标题、段落、链接、图片替换文本等关键信息。第三段是组装提示词，把清洗后的内容和诊断维度拼成一个固定的指令模板。第四段是推理与展示，调用浏览器内置模型接口，把输出结果渲染在页面上。

其中清洗环节很容易被忽略，这里提醒一下：HTML里混杂着script、style、注释，直接丢给模型会浪费大量上下文，也可能让模型把脚本当成正文，给出莫名其妙的分析。我在实测中吃过亏，后来引入了一个简单的转换函数，用DOMParser解析，按语义标签筛选内容，效果立竿见影。

2.3 技术选型：为什么只用一个静态页面

这个工具我刻意做成了零依赖的静态页面，不引入任何前端框架，也没有构建步骤。原因很直接：既然要“免费”，就没有必要动辄拉来一堆依赖。原生JavaScript配合浏览器内置API已经足够实现。

代码结构上，我会把能力探测、内容清洗、提示词构造、结果渲染分别封装成独立函数。这样即使将来浏览器接口升级，我只需要替换中间一两段的调用方式，周围逻辑不必大改。对于想快速上手的人来说，新建一个index.html，粘贴下面的代码，就能跑起来。

3. 完整实操：从页面内容到优化建议

3.1 先探测浏览器内置模型能力

这一步的目的，是避免在不支持的环境里直接报错。不同浏览器对这个接口的暴露位置可能不一样，我建议做一次比较宽泛的能力检查：

const aiRoot = window.ai || window.model?.ai || self.ai; const languageModel = aiRoot?.languageModel || aiRoot?.LanguageModel; async function detectModel() { if (!languageModel) { return { available: false, reason: '当前浏览器未暴露内置语言模型接口，请检查浏览器版本与配置。' }; } const capability = await languageModel.capabilities(); let status = capability?.available; if (status === 'after-download') { return { available: true, needDownload: true }; } return { available: status === 'available', needDownload: false }; }

这里的capabilities返回结果可能因浏览器而异，但核心要表达的语义是一致的：它是可以直接用、还是需要先下载模型，还是当前不可用。如果提示“after-download”，我会在界面上显示下载进度，再放行后续操作。

3.2 用DOMParser清洗网页内容

拿到用户粘贴的HTML之后，我会先解析成DOM，再提取可读部分。这一步不只是为了省Token，也是为了模型的分析质量。页面里的导航栏、侧边栏、版权信息都是噪音，统统过滤掉。

function extractPageSegments(htmlText) { const doc = new DOMParser().parseFromString(htmlText, 'text/html'); const segments = { title: doc.querySelector('title')?.innerText || '', metaDescription: doc.querySelector('meta[name="description"]')?.getAttribute('content') || '', h1: [...doc.querySelectorAll('h1')].map(h => h.innerText.trim()), h2: [...doc.querySelectorAll('h2')].map(h => h.innerText.trim()), paragraphs: [...doc.querySelectorAll('p')].map(p => p.innerText.trim()).slice(0, 20), links: [...doc.querySelectorAll('a[href]')].map(a => a.innerText.trim()).filter(Boolean).slice(0, 10), images: [...doc.querySelectorAll('img')].map(img => ({ alt: img.getAttribute('alt') || '', src: img.getAttribute('src') || '' })).slice(0, 10) }; return segments; }

这里截断不是拍脑袋定的。段落截取前20个，链接和图片各截取前10个，是因为内置模型的上下文窗口有限，样本过多会让后面真正关键的正文被截掉。你可以在测试中调整，但原则是“舍帅保车”，优先保住title、meta、h1、h2和正文前几段。

3.3 组装一份结构化诊断提示词

模型能不能给出高质量建议，提示词占一半以上责任。我的做法是给模型一个固定角色，也给它一个固定模板，要求它按编号输出，不废话。以下是我一直在用的模板：

你是一名资深前端顾问，擅长网页质量诊断。 下面是一个网页的关键信息片段，包括标题、描述、标题层级、正文段落、链接文本和图片信息。 请从 [SEO、标题结构、正文可读性、链接与图片、无障碍] 五个维度给出优化建议。 约束： 1. 用中文输出。 2. 每个维度最多给3条建议。 3. 每条建议先写“问题”，再写“修改方向”。 4. 找不到问题的小项就直接省略，不要硬编。 5. 输出格式为Markdown小标题加列表。 内容如下： 标题：${segments.title} 描述：${segments.metaDescription} H1：${segments.h1.join(' / ')} H2：${segments.h2.join(' / ')} 正文： ${segments.paragraphs.join('\n')} 链接文本： ${segments.links.join('、')} 图片信息： ${JSON.stringify(segments.images)}

注意我用了“不要硬编”这四个字。这是我在多次测试后总结出来的，非常重要。如果不加约束，模型面对结构良好的页面，也会硬凑出几条无关痛痒的问题，比如“建议增加更多图片”，但实际上你的文章是纯技术教程，根本不缺图。

3.4 调用浏览器内置模型并输出结果

看完能力状态、准备好提示词之后，就可以发起对话了。调用方式在不同浏览器上不尽相同，下面是我的兼容写法：

async function requestSuggestions(promptText, needDownload) { if (needDownload) { const sessionDownload = await languageModel.create({ signal: AbortSignal.timeout(120000) }); return sessionDownload.prompt(promptText); } const session = await languageModel.create({ temperature: 0.2, topK: 3 }); try { return await session.prompt(promptText); } finally { session.destroy(); } }

这里temperature设置成0.2，是希望输出偏稳定、少发挥。如果你想要更多灵感和突破性建议，可以调到0.7以上，但网页体检的场景我建议偏低，避免模型反复推翻自己的判断。

会话对象用完一定要释放，忘了销毁会长期占用浏览器内存。我自己第一次写的时候没在意，连续分析五六个页面之后，标签页明显变卡，后来加上了session.destroy()才恢复正常。

3.5 前端界面与交互逻辑

界面部分我不做复杂渲染，只用一个两栏布局。左栏放textarea输入HTML，右栏放输出区域“建议结果”。关键交互是“开始诊断”按钮，点击后先做能力检查，再清洗内容，再组装提示词，最后把建议以Markdown形式渲染。

async function runDiagnosis() { const htmlText = document.querySelector('#htmlInput').value.trim(); if (!htmlText) { alert('请粘贴网页HTML或源码内容'); return; } const status = await detectModel(); if (!status.available) { document.querySelector('#result').innerText = status.reason; return; } const segments = extractPageSegments(htmlText); const prompt = buildPrompt(segments); const result = await requestSuggestions(prompt, status.needDownload); document.querySelector('#result').innerHTML = renderMarkdown(result); }

整体逻辑走下来，一个可用的小工具大约一百多行代码。你不必一开始就追求界面好看，先把核心链路打通，后续再根据需要加上维度开关、历史记录、一键复制等小功能。

4. 建议的筛选与“人工兜底”：别被模型带偏

4.1 先用硬规则做一遍机器检查

内置模型给出的建议是“可能存在的问题”，而不是“事实”。为了不让建议失真，我的做法是先在自己的工具里跑一组硬规则检查，把能确定的问题直接标记出来。

硬规则包括：标题是否超过60个中文字符、meta description是否为空、页面有没有H1、H1数量是否大于1、H2是否被跳过、图片有没有alt、内链文本是否有“点击这里”这类模糊描述。这些规则不用AI也能判断。

把硬规则的检查结果放在模型建议前面，会起到两个作用：一是兜底，让模型没看到的明显问题被找出来；二是校准，让模型知道“工具已经发现了这些问题”，它就不会花力气重复，而会把注意力放在更深层的文案和结构问题上。这个组合比任何一种单一方案都靠谱。

4.2 让输出从“聊天口吻”变成“待办清单”

如果你直接把Markdown建议拿来用，往往是一大段通顺的话，真正落到修改Action时需要重新理解一遍。我后来调整了提示词，要求模型用“问题定位 + 具体修改方向”的格式输出，并在前端做简单拆分。

进一步，你可以让模型返回一段JSON，每条建议都包含维度、优先级、问题现象、修改建议。前端再把这组JSON渲染成带复选框的to-do列表。我贴一段JSON模式的提示词片段：

请严格按如下JSON结构输出，不要输出多余文字： [{"dimension":"SEO","priority":"high","issue":"页面缺少meta description","suggestion":"补充一句80字以内的描述，包含核心关键词"}]

虽然JSON输出偶尔会不完整，但只要异常捕获做得好，体验依然比纯文本强。我给工具加了一个解析失败的兜底：如果JSON.parse抛错，就直接把原始文本显示出来，不让用户卡在解析环节。

4.3 给一个模拟页面做整体效果验证

我拿自己在本地的博客首页做过一次实验。粘贴整段HTML后，模型先指出标题过长，超过60字符；再指出首屏段落太长，超过五行，建议拆成两个自然段；还指出两处图片缺少alt文本，可能导致无障碍评分偏低。这三条里，第一和第三条都能被硬规则查到，但第二条“首屏段落太长”是模型自己读出来的，它确实发现了我容易忽略的阅读体验问题。

这让我意识到，不要指望模型替代检查工具，也不要忽略它的独立价值。最好的结果，是硬规则干活，模型补刀。两者结合，一份网页诊断报告基本可以覆盖到90%的常规优化点。

5. 问题排查与避坑实录

5.1 模型一直不可用，怎么排查

最让人头疼的是能力探测提示不可用。我遇到的情况大多是浏览器版本不够新，或浏览器关闭了内置AI相关开关。这时先确认浏览器设置里是否有“启用实验性AI功能”之类的选项，再确认当前地址是否处于本地localhost或HTTPS环境。

内置语言模型接口通常只允许在安全上下文中调用，单纯打开一个file://路径的HTML文件不一定能触发完整能力。我最终的解决方案是本地起一个静态服务器，再访问页面。你不需要复杂的服务端，任意一款静态文件服务器都能胜任。

5.2 提示词太长或超出上下文

内置模型的上下文窗口不是无限大。如果你把整个网页的全部源码都塞进去，很可能直接被拒绝服务或截断。处理办法是我在清洗段已经展示过的：内容切片、限制条数、优先保留关键信息。

如果你确实需要分析整篇长文，可以换一种交互策略：不一次性问所有维度，而是一次只问一个维度；或者把正文分成几段，逐段让模型给出建议，最后再汇总。这是我在一篇文章超过一万字时的常用方案。

5.3 模型重复强调同一个问题

内置模型对上下文的注意力与云端大模型不同，它有时会在多个维度下反复提到同一个点，比如SEO里说“标题过长”，可读性里又说一遍。这不是逻辑错误，而是模型试图堆砌输出。解决方法是约束“每个维度最多三条”，同时你可以在提示词里加一句“不同维度之间不要重复相同问题”。

如果仍然重复，前端可以做一层去重，把相似文本的相似度计算阈值拉高，过滤掉同一维度里重复度超过80%的建议。这个处理不难，但很提体验。

5.4 离线模型下载与首次等待

如果你是第一次使用浏览器内置模型，从状态提示“after-download”到实际可用，中间可能要等一小会儿。这个过程不需要你花一分钱，但需要耐心。好的交互方式是在界面上明示下载进度，我通常先把开始按钮改成“模型准备中…”，下载完成后再恢复成正常文案。

另外要注意，内置模型下载到本地后占用的存储空间不小，如果用户磁盘空间严重不足，下载可能失败。这个因素不受代码控制，但你在错误提示里写上一句“请检查磁盘空间”，可以帮助别人少走弯路。

6. 把它扩展成你自己的工作流

6.1 做成一个可在任意页面调用的书签工具

如果你不想每次复制HTML，可以把它做成一款书签小工具。书签代码在目标网页加载时执行，直接抓取当前页面的DOM，调用内置模型分析，然后把建议以浮层形式展示。这样你浏览任何页面都能随时“体检”，无需离开当前环境。

书签工具要注意跨域限制，页面对你开放DOM的情况下可以读取，如果页面禁止脚本注入，则无法生效。这不是大问题，内容站自己的页面通常都可以。

6.2 与本地脚本结合做批量站点巡检

如果你有多个页面需要检查，可以写一个简单脚本，循环抓取本地静态站点的HTML文件，逐个送到内置模型分析，再统一输出一份Markdown报告。前端界面在这里可以退位，核心复用点只剩“清洗内容”和“组装提示词”这两个函数。

批量巡检时提醒一句：模型的输出是概率性的，两次给同一页面的建议可能不同。所以批量巡检要记录日期，保存每轮快照，方便后续对比优化是否见效。不要指望模型两次输出完全一致，而是把它当做一个“会码字的同事”，每次看完给你一份当天视角的批注。

6.3 沉淀一套自己的网页诊断标准

做到这一步你会发现，最有价值的不是模型本身，而是你沉淀下来的提示词和硬规则清单。随着你分析页面越来越多，可以不断往硬规则里添项目，比如“img标签有没有loading=lazy”“meta og标签是否存在”“页面favicon是否缺失”。

我会把更新后的规则再写回提示词中，让模型在考虑这些规则的基础上继续发挥。这样你的工具会越用越准，而且不会因为依赖云端接口而受限。

我个人在多次使用中的体会是：免费方案并不意味着低质量，只要把“AI能力”和“程序化规则”配合得当，一个完全跑在浏览器里的静态页面，也能成为日常网页优化中最顺手的检查器。不要迷信模型输出，也不要因为模型有局限就放弃尝试。把它当做一个不需要预算、不泄露隐私、随叫随到的本地顾问，反而能激发出更多创意用法。