企业官网建设流程全解析

DeepSeek Harness 这段时间讨论度不低。它发布之后，我第一时间把它拉起来跑了一遍，目标很明确：让这个“能干活的编码代理”直接给一个叫 BitFun 的项目做官网。这里先给一句结论：DeepSeek Harness 不是一个自动写代码的聊天窗口，它的工作方式更像“把官网拆成任务，再逐个生成并落盘”。单页官网能跑通，但多页面、排版调整、资源路径和批量生成时，需要自己设计任务清单和验证环节。

如果你只是在等一个能“一个回车交付完整官网”的工具，大概率会失望。它的价值在于：你描述清楚官网要求，它能基于模型能力生成 HTML/CSS/JS 文件，创建目录结构，并且通过本地命令启动预览。适合技术人员快速搭 Demo、验证产品页面，也适合非前端人员先跑出一版可看页面，再交给前端改。下面按我这次从零跑的流程，把每一步怎么判断、怎么改、哪些地方容易坑写清楚。

1. 我理解的 DeepSeek Harness：它比普通代码补全多做了什么

1.1 它解决的并不是“代码建议”问题

传统代码补全工具在你写代码时提示下一段，而 DeepSeek Harness 这一类任务代理，通常接收的是“目标级描述”，比如“给 BitFun 做一个官网，包含四个页面，首页需要 hero、产品特性、下载引导、页脚”。

它收到这个目标后，会自己拆任务、选择创建哪个文件、让模型生成代码、在本地目录写入，最后还能给出预览地址。这是它和 IDE 里的代码补全、普通聊天页面最大的区别。

理解这一点很重要，因为很多人会带着“代码补全工具”的使用习惯去用 Harness，一开始就让它“给我写一行函数”，结果发现流程很重。实际更适合的做法是直接给一个可验证的任务，让它把文件生成出来，然后再检查。

1.2 它更适合哪些官网开发场景

如果你的官网是纯静态页面、没有复杂后端，或者想快速验证产品想法，用 DeepSeek Harness 这类工具很合适。比如这次给 BitFun 做官网，我定的范围就是四个静态页面：首页、产品介绍、下载、关于。用途是做产品公开介绍和下载入口，没有登录注册，没有支付流程，也没有管理后台。

如果项目涉及登录、支付、大量用户交互，它生成的只能算“前端演示壳”，不能直接当生产系统交付。这类工具不是万能的，它擅长的是把“信息展示型页面”从零生成出来，而不是替你设计整个业务系统。

1.3 先判断你要的是哪一类“官网”

很多项目会把官网做成单页应用 SPA，也有的用纯 HTML + CSS 就够了。我在跑 BitFun 时选择纯静态 HTML，原因是这个官网只需要展示信息，越简单越容易检查、改版和交给设计团队处理。没必要为了技术栈引入 React 构建链。

判断口径可以参考：

• 只展示产品介绍、下载链接、团队信息 → 静态页优先。
• 需要文章、动态列表、用户评论 → 至少需要一个轻量后台或者内容接口。
• 需要实时通讯、复杂交互、权限系统 → 不建议让 Harness 直接生成完整系统，而是先跑前端原型。

不要一上来就让工具自由发挥。先把页面数量、页面之间的关系、是否依赖后端、用什么技术栈确定下来，后面每一步都会顺利很多。

2. 跑起来之前先盘三件事：模型来源、运行环境、输出目录

2.1 模型来源先定好：API 调用还是本地模型

DeepSeek Harness 这类工具通常支持接入 DeepSeek 的 API，也可以连本地部署模型。关键判断标准是：你手头有多少算力？是不是需要处理批量页面？是否担心关键信息不能出本地？

我建议第一次跑通用 API 方式，原因很简单：省去模型部署的时间，返回速度快，环境变量配好后基本不需要再管。等你确认这个工具能解决你的问题，再考虑本地模型也不迟。

如果你只有一张老显卡，显存在 6 到 8 GB 左右，想跑本地模型也可以，但要用小模型，把生成步数和上下文长度调低。不要期待一个 6 GB 级别的显卡能顺畅生成整站代码，显存不足会导致卡顿甚至直接退出。原始材料没有给出足够明确的硬件指标，落地时先确认你手头设备的可用显存和内存，再决定跑哪个规格。

2.2 安装环境和常见坑

不同发行版本的 DeepSeek Harness 安装方式会有差异，常规环境通常涉及 Node.js、npm/pnpm，有的版本还需要 Python 环境。打开命令行前，先检查几个基础项：

• Node.js 版本是否达到项目要求。
• npm 或 pnpm 是否可用。
• 当前用户对安装目录是否有写入权限。
• 磁盘剩余空间是否充足。

网上看到的部分安装命令可能是旧版本，不要直接照抄。安装时如果卡在pnpm dsh web这类依赖安装环节，优先怀疑网络波动、软件源响应慢和 Node 版本不匹配，不要反复重跑同一个命令，容易留下半截依赖。

依赖下载尽量走可信软件源。如果某个源不稳定，可以换成官方提供的其他区域源，等网络恢复再重试，不要从来路不明的页面下载二进制，也不要轻易执行来源不明的安装脚本。下载前先看发布者信息、校验值、仓库 star 和历史更新情况，安全习惯越早建立越好。

2.3 项目目录先规划好

做官网必须想清楚文件输出到哪里。我给 BitFun 建的目录结构是：

bitfun-site/ index.html product.html download.html about.html assets/ css/ js/ images/

为什么先建目录？因为工具生成文件时需要明确的落盘位置。如果没有，它可能默认写在当前目录，文件散乱。如果后面要放截图、图标和样式，目录不提前建好，工具会把静态资源全部堆在一起。

启动项目后，尽量在单独目录里工作，不要直接在系统盘根目录或者用户主目录下生成文件。生成过程经常创建多个文件，如果目录太乱，后面整理成本会很高。

2.4 第一次启动前的最小确认清单

我把这次初始化前的检查项整理成下面表格：

这些都确认完，再进入“生成官网”的环节。前面省事，后面排错麻烦。

3. 先做单页首页，不要一上来就生成四个页面

3.1 写一个能复现的需求文本

很多人会直接输入“帮我做一个官网”，然后抱怨结果不听话。这是用 Harness 最典型的错误用法。我的做法是把需求写成可执行的任务描述：

为 BitFun 项目生成一个官网首页，项目定位是一款提升日常效率的小工具。要求： 1. 使用 HTML + CSS，不引入前端框架。 2. 顶部导航包含：首页、产品、下载、关于。 3. hero 区域写清产品名和一句卖点。 4. 特性区展示 3 个核心功能。 5. 底部有下载按钮，链接到 download.html。 6. 不要使用远程图片，图片用 CSS 渐变代替。

为什么这么写？因为“做一个好看的官网”太主观，模型每次生成的随机性会很大。把版块、页面关系和资源约束写清楚，生成的结果才比较可复现。

如果官网文案你已经有了，最好单独放一个copy.md文件，把品牌名、标题、正文都准备好。这样模型不会自己瞎编一段看起来很像但实际没用的营销文案。

3.2 从“单个首页”任务开始

进入 DeepSeek Harness 后，先不要做批量任务，就发一个首页生成任务：

# 以当前终端模式为例，不同渠道命令可能不同 dsh run "给 BitFun 生成官网首页，参照任务描述文件"

这条命令并不一定适用于所有版本，但流程基本一致：输入任务、观察工具拆解、等待文件写入。工具如果支持交互式终端，终端会显示“准备创建 index.html”“调用模型生成代码”“写入目录”等步骤。

第一次跑的时候，不要人在旁边干等。我一般是看终端日志会不会停在某个环节超过两三分钟。如果超过预期时间，先确认是模型还在生成，还是进程已经挂住。

3.3 生成之后先检查文件，不要只看预览

官网首页任务执行完成后，第一件事不是打开浏览器看效果，而是看文件有没有真的生成出来。

成功的基本标准是：

• 指定目录中出现了index.html。
• 引用的 CSS/JS 路径存在且正确。
• 没有把图片地址写成固定外链。
• 页面可以在浏览器里直接打开。

我第一次实验时，模型生成的 HTML 引用了/assets路径，用file://方式打开直接白屏。后来检查发现是路径问题，改成相对路径assets/就正常了。

如果生成结果没有 CSS，只有 HTML，也要看是不是工具没有执行“创建 CSS 文件”这一步。任务描述里最好明确指出“把样式放在 assets/css/style.css”，而不是让模型把所有样式写在一个style标签里。

3.4 生成卡住时，先等一轮再看日志

看到长时间没有输出，不要立刻重复发指令。重复任务可能产生重复文件，更严重的是可能把正在写入的文件截断，造成目录里出现一堆index copy.html或者空文件。

正确做法是先看日志最后几行，确认它是在等模型响应、在写文件还是报错了。如果是等模型响应，多等一轮；如果是网络请求超时，再检查服务状态。很多所谓“卡住”并不是真卡，只是模型服务本身响应慢。

4. 做官网最容易踩坑：文案、视觉、导航分开验收

4.1 第一轮先核对文案和页面信息

官网最关键的内容是文案，不是视觉效果。如果文案是错的，页面再好看也没有用。

打开生成的index.html，逐段核对：

• BitFun 产品名是否写完整。
• 主标题和副标题是否符合定位。
• 特性介绍是否清楚，有没有出现大段无意义空话。
• 按钮文案是“下载”还是“了解更多”，是否符合点击后的目标页面。
• 页脚版权信息、备案占位信息是否完整。

模型在生成文案时，习惯把页面填得看起来很丰富，但里面可能夹着和产品无关的网络词或模板句。这些内容要你手动过滤。不要指望一次生成就符合所有业务表达。

4.2 第二轮看视觉布局和响应式效果

看完文案，再打开浏览器开发者工具，把视口分别切到 375px、768px 和 1440px 宽度。

如果手机宽度下导航换行、按钮溢出、图片被压扁，说明响应式没有处理好。这时候可以发一个修改任务：

优化首页响应式：手机端导航改成汉堡菜单，卡片在 375px 下改为单列展示，按钮不溢出。

模型生成的 CSS 喜欢用渐变、阴影、圆角来制造视觉效果，但颜色对比度不一定够。比如浅灰色文字放在白色背景上，桌面端看着还行，手机上亮度一高就完全看不清。遇到这类问题，宁可让配色保守一点。

4.3 第三轮看跳转和页面关系

官网页面之间是有逻辑的。首页会引导用户去产品页、下载页，产品页又会补充说明功能，下载页需要给出安装包链接，关于页可能要放团队介绍和联系邮箱。

这时候要逐个检查链接：

• 导航里的“产品”是否真的跳转到product.html。
• 下载按钮是否有href，不是点击后弹出空提示。
• 关于页里的邮箱地址是否写对。
• 所有页面的首页 logo 是否链接回index.html。

这些看起来基础，但模型很容易只做视觉，不做交互。常见问题是“下载”按钮生成了一个空链接，或者链接写成#。你的验收清单里必须包含“逐一点击每个可点击元素”。

4.4 质量验收一定要有清单

我把官网首页的验收分成四类：

做一次官网，至少要过三遍这个清单。只跑一遍就说“能用”，后面大概率会在验收现场发现问题。

5. 多页面官网要拆成独立任务，还要给输出定规则

5.1 先建立页面关系图

首页跑通后，再生成产品页、下载页和关于页。不要把四个页面一次性塞给同一个任务，那样模型会花很长上下文，容易生成一半就断掉。

我先画了一个简单的页面关系：

index.html 首页：产品亮点、下载引导 ├── product.html 产品：功能说明、适用场景 ├── download.html 下载：版本信息、安装包按钮 └── about.html 关于：团队介绍、联系方式

页面关系确定后，每个页面单独发一个任务。首页要引用其他页面的链接，可以把页面文件名写在任务描述里，避免模型自造一个features.html。

5.2 输出规则要提前定死

多页面项目最需要注意的是文件命名和目录结构。命名一旦混乱，后面调试链接的成本会很高。

我定的规则是：

• 所有 HTML 文件名使用小写字母。
• 单词之间用连字符，不用下划线。
• HTML 放在根目录，CSS 放assets/css，图片放assets/images。
• 页面内部资源一律用相对路径。

为什么强调小写？因为如果你在本地 Windows 上偶尔生成了Product.HTML，上传到 Linux 服务器后，product.html的链接会直接 404。大小写问题在本地可能不暴露，部署后才会坑到人。

任务描述里可以直接加一句“所有文件名使用小写字母，资源使用相对路径”。规则越明确，后续人工返工越少。

5.3 连续修改时使用变更清单

生成完四个页面之后，大概率还要改。改官网时最大的坑是：你只想改一个按钮，模型把你的整体配色也改了。

避免这种失控的方法是使用变更清单，而不是发一句宽松的话：

本轮修改目标： - 首页 hero 文案改为“用简单方式提升每日效率”。 - 产品页增加一张本地占位截图。 - 所有页面底部给“关于我们”加链接。 - 不影响其他区域的样式和布局。

模型看到明确的变更清单后，会倾向于局部修改。如果你说“帮我再润色一下官网”，它会把已经确认的文案替换成新的内容，导致你前面核对的白做了。

5.4 批量生成时要考虑失败恢复

如果工具支持“一次生成多个页面”，不要一开始就把全部任务丢进去。我还是先跑单个product.html，确认输出没问题，再批量跑剩余页面。

批量任务真正要考虑的是失败后的处理。连续 20 个页面只要有一个失败，不应该整批重跑。更好的方式是支持“跳过已生成的文件”或“只重试失败任务”。如果工具没有这个能力，就通过脚本检查文件是否完整存在，再只处理缺失部分。

输出文件的覆盖策略也要注意。如果任务重复执行，不能因为时间戳变化生成一堆index(1).html。文件重名策略、失败重试策略、日志位置，这些在批量前就要想好。

6. 批量跑和接接口时，稳定性比功能列表更重要

6.1 关键参数到底怎么理解

当你从单页生成走向批量任务，一定会遇到几个参数：批数量、并发数、超时时间、失败重试次数。

• 批数量：一次提交多少文件或任务。
• 并发数：同时调用模型服务的任务数量。
• 超时时间：单个任务超过多久算失败。
• 重试次数：失败后重新执行的次数。

很多人看到批量就开高并发，结果显存或者模型服务被打满，整批任务卡住。我更建议把并发数先设在 2 到 3，跑一轮观察资源占用，再决定往上调还是往下调。

6.2 先测单任务耗时，再推算批量时间

批量任务不能只看“能不能跑”，还要看整体吞吐。比如在某台机器上，生成一个静态页面需要 2 分钟，那么 20 页全跑至少要 40 分钟，这还不算排队和重试。

先记录一个单任务的耗时，作为后续评估基线。如果单任务都经常超时，就不要加批量。如果单任务稳定，再根据耗时决定用 1 并发顺序跑，还是用 2 到 3 并发加速。

低配机器上顺序执行不一定慢，因为并发高之后模型互相抢资源，单任务变慢，总体时间反而增加。资源占用和任务耗时要一起看，不要只看任务列表里的“已完成”数量。

6.3 失败重试必须提前设计

批量生成官网页面后，不能只看工具返回“成功”。要检查生成的文件是否真的可以打开，HTML 是否完整。有些任务因为中间网络抖动，文件写到一半就结束，但退出码看起来正常。

判断稳定性可以用几个简单指标：

• 任务成功率：成功任务数除以总任务数。
• 文件完整性：每个 HTML 是否有闭合标签，是否包含页面主体。
• 链接可达率：页面里的导航链接是否有实际文件对应。
• 资源占用：显存或内存是否持续接近上限。

如果成功率低于九成，先不要加并发，先排查输入任务和模型服务。批量任务只有在单条链路稳定后才有意义。

6.4 接口调用要关注返回结构和超时

如果你不是只跑终端，而是把 DeepSeek Harness 接入自己的流程，就要关注 API 的返回结构。

建议先调用一次小任务，观察返回体里是什么：

{ "task_id": "task_001", "status": "completed", "output_path": "./bitfun-site/product.html", "error": null }

不同版本字段名可能有差异，不要假设所有平台都返回这个结构。重点是：错误信息在哪里、输出路径是相对路径还是绝对路径、任务状态是否包含 pending/running/completed/failed。

接口调用还要设置合理的超时时间。官网页面代码比较长，单个任务经常超过几十秒，如果超时设成 10 秒，任务几乎必然失败。可以先看模型正常返回一次需要多久，再加 2 到 3 倍余量。

7. 遇到卡住、报错、白屏，按这个顺序排查最省时间

7.1 先给问题分类

官网生成过程中，最常遇到的现象有几种：

• 提示“命令不存在”或“依赖找不到”。
• 启动后长时间没有输出。
• 生成结束但 HTML 是空文件。
• 浏览器打开白屏。
• 页面能打开但图片和样式丢失。

不要一上来就重装工具，先按现象分类，再看日志。很多问题看起来是生成能力不行，实际是环境或者路径问题。

7.2 第一优先：看日志和退出码

DeepSeek Harness 终端模式会在执行过程中打印任务状态。遇到卡住，先看最后几行日志。

如果日志显示“等待模型响应”，说明模型服务还在工作，可能有延迟。如果显示“写入文件失败”，再去查目录权限。如果显示“依赖缺失”，再去补环境。

反复重启工具通常没有用，反而会把原来的临时目录清掉，让排查更难。

7.3 第二优先：检查输入、路径和权限

在官网生成任务里，很多失败是因为模型没有权限创建目录，或者输出路径不存在。

报错信息里如果出现Permission denied，先看当前用户对目标目录有没有写权限。如果是公司电脑，还需要确认安全软件没有拦截生成文件。

路径问题也很常见。Windows 下模型可能生成带/的路径，本地脚本用\才正常，这时要手动处理路径分隔符。最终部署到 Linux 服务器时，统一用相对路径是最省事的方式。

7.4 第三优先：看模型服务的并发状态

如果你同时打开了终端、桌面版、接口三个入口，每个都提交任务，后台模型服务可能已经过载。此时即使单个任务描述正确，也可能因为排队过多而超时。

打开任务管理器或系统监控，看显存、内存、CPU 占用。如果资源接近上限，先停掉其他任务，只保留一个正在跑的任务。

7.5 第四优先：检查是否有缓存干扰

有些工具会把模型结果缓存起来。如果你连续修改任务描述，但生成结果没有变化，很可能是读取了旧缓存。

处理方法很简单：在任务描述里增加明确版本标记，比如“第 3 版首页，hero 区域改为上下布局”。如果确实怀疑缓存，再清理工具缓存目录。

8. 我的结论：小官网能用，但别期望“零人工”

8.1 这一轮跑完后的真实感受

给 BitFun 做官网这样的四个静态页面，DeepSeek Harness 能跑到“可用”水平。第一次单页生成时，HTML、CSS、导航和基础响应式都能正常出来。

但距离“直接上线”还有人工工作。文案要替换成真实的、页面间距要微调、移动端导航要检查、每个链接要逐一点一遍。这些步骤不管用不用 Harness，上线前都必须做。

8.2 最值得投入的是 prompt 和验收规则

用这类工具最值得花时间的不是研究功能列表，而是把自己的需求写清楚，把输出规范定死。目录结构、命名规则、资源引用方式、文案素材，这些越早定，工具生成越可控。

建议每次生成后都保留一份验收清单。我这次用的是“文案、视觉、响应式、链接”四关。你也可以根据自己项目增加“SEO 标题、描述、favicon、统计代码占位”等检查项。

8.3 低配机器别折腾超规格任务

如果你的机器配置不高，先按小任务验证。生成单页时降低输入长度，不让模型一次写太多内容；能跑通后再慢慢加页面。低配环境能跑通一个首页，不代表能批量生成 20 个页面。

想省时间，优先调用成熟的模型服务而不是本地小模型。本地模型虽然可以保护数据，但代码生成任务需要稳定基础能力，小模型往往会因为上下文不足导致文件截断。

8.4 不要把测试输出当作生产交付

无论 DeepSeek Harness 生成的结果多好看，都不能直接当成生产代码发布。需要人工 review 代码里是否有奇怪的远程请求、无授权统计脚本、暴露密钥的接口调用。

给官网做静态部署时，要检查 HTML 后缀、资源路径、目录权限。生产环路的日志、备份、版本管理和回滚机制，应该和寻常项目一样齐备。

我个人更建议把 DeepSeek Harness 当成“能快速产出页面草稿的助手”，而不是自动建站工人。每一步生成后，用浏览器打开实际页面看一遍，比盯着终端里的绿色成功提示可靠得多。踩过几次后发现，很多问题不是工具能力不够，而是前置环境和输入材料没有处理干净。先跑稳一个小页面，再逐步扩大任务范围，这个思路适合绝大多数第一次接触任务式编程代理的人。