企业官网建设流程全解析

简介：面向人机交互课程设计/大作业场景，压缩包以社区食堂/企业订餐系统为项目案例，整合了从需求分析、原型设计到展示答辩的完整作业链路，适合计算机相关专业学生参考选题、搭建作品或梳理设计文档。压缩包共22个文件，大小约17.62MB，以docx文档为主，涵盖需求分析、代码规范、命名规范、Git使用指南等说明；同时包含pptx答辩演示、HTML原型入口、PDF模型理论、JPG图表等，覆盖项目开发各阶段所需材料。内容中还嵌有订餐系统可交互原型、README辅助说明及相关目录结构，便于理解人机交互设计如何落地为可演示作品。该资源已有4538人学习，对需要快速完成人机交互大作业或完善现有方案的学生有较高参考价值。

1. 从「人机交互设计大作业.zip」说起：一门课、一套完整交付物

人机交互设计大作业最折磨人的不是画原型，而是搞不清一门课到底要交什么。这份以企业食堂订餐系统为背景的「人机交互设计大作业.zip」，把需求分析文档、WBS 拆分图、模型和理论 PDF、订餐原型、演示 PPT 以及一套带 WEB-INF 的 web 示例全部打包在内。对正在做人机交互大作业的学生，它是一份能对照梳理自己项目的结构参考；对赶进度的小组，它展示了从「用户需求」到「可点选 Demo」的完整链路。它不替你做设计决策，但能把「这门课在考察什么」一次讲清楚：用户建模、交互流程、可用性评估，再加上工程协作规范——这四块恰好也是答辩时老师追问最多的四个方向。

2. 拆开 zip 看家底：七类文件的分工与先验货再动手

拿到任何「xxx 大作业.zip」我都劝你先别急着解压跑代码。大作业包在网盘、微信、U 盘之间倒腾三五手是常态，我见过太多次解压到一半报错、7-Zip 突然弹密码框、解压完目录全是乱码的情况。这三件事都发生在真正「动手」之前，却直接决定后面所有工作能不能继续。所以第 2 章先干三件事：验包、识伪加密、处理编码。

2.1 先验货：完整性、伪加密与中文乱码

最稳的验包方式是用 7-Zip 先测一遍压缩包结构，别直接双击：

# 测试压缩包完整性，不写日志，只看最终结果 7z t 人机交互设计大作业.zip # 或者用 Info-ZIP 的 unzip 做校验 unzip -t 人机交互设计大作业.zip

7z t会逐条读取压缩包内每个文件条目的 CRC 值。如果输出里出现There are errors或missing zip entry字样，说明包在传输或上传过程中已经损坏，直接解压大概率缺文件。这种情况我的建议是别折腾修复工具——回到最初的下载源重新下载一次，比任何修复脚本都靠谱，这是血泪经验。

如果7z t报错，但 7-Zip 又能列出文件名，只是打开时弹密码框，而你确认这个包从来没设过密码，那八成是遇到了 zip 伪加密。伪加密的本质是压缩包条目的「通用位标志」第 0 位被置 1，文件本身并没有真正的加密头，解压工具读到这个标志位就以为需要密码。先确认一下：

# 列出详细条目信息，看每个文件的加密标志和压缩方法 7z l -slt 人机交互设计大作业.zip | grep -E "Path|Encrypted|Method"

如果大量文件显示Encrypted = +，但Method一栏是Store或Deflate，而不是AES-256，基本可以断定是伪加密。修复思路很直接：把本地文件头和中央目录里的加密标志位清掉。下面这段脚本只做一件事——遍历 zip 里所有的PK\x03\x04（本地文件头）和PK\x01\x02（中央目录头），把头部偏移 6 处的通用标志位第 0 位清零：

import struct import sys def clear_fake_encryption(src, dst): with open(src, 'rb') as f: data = bytearray(f.read()) # 本地文件头 PK\x03\x04 与中央目录头 PK\x01\x02 # 两者的通用位标志都位于头部偏移 6 处，占 2 字节 for sig in (b'PK\x03\x04', b'PK\x01\x02'): pos = 0 while True: pos = data.find(sig, pos) if pos == -1: break flag_off = pos + 6 if flag_off + 2 <= len(data): flags = struct.unpack('<H', data[flag_off:flag_off + 2])[0] if flags & 0x0001: # 第 0 位是加密标志 data[flag_off:flag_off + 2] = struct.pack('<H', flags & 0xFFFE) pos += 1 with open(dst, 'wb') as f: f.write(data) if __name__ == '__main__': clear_fake_encryption(sys.argv[1], sys.argv[2])

用法是python3 fix_zip.py 人机交互设计大作业.zip 输出.zip。逻辑说明：zip 格式里本地文件头和中央目录头的通用位标志位置固定，脚本按签名逐条定位、逐个清位，不会动文件内容数据。参数说明：第 0 位（0x0001）是加密标志，& 0xFFFE表示把这一位写成 0 而保留其他位。

注意：这个脚本会把所有加密位全部清掉，所以只适用于「你确定这个包没有真实密码」的场景。如果压缩包确实被密码保护过，清完标志位解压出来也是损坏的文件，没有后悔药。

还有一类高频问题是中文乱码。Windows 上默认压缩工具产出的 zip，文件名常是 GBK 编码，在 Linux 或 macOS 上直接unzip会看到一堆乱码目录名。Info-ZIP 的 unzip 支持指定编码：

unzip -O GBK 人机交互设计大作业.zip -d 输出目录

macOS 自带的 unzip 未必带-O参数，装过 Homebrew 的话brew install unzip换一个，或者干脆用 7-Zip 解压，多数情况能自动识别。这一步做完，文件层面才算真正可用。

2.2 documents 文件夹：四份文档各管一段交付

解压干净之后，根工程目录是human-computer-interaction-master，核心内容集中在documents子目录。整体结构大概是：

human-computer-interaction-master/ ├── README.en.md ├── documents/ │ ├── 企业食堂订餐系统.pptx │ ├── 订餐系统需求分析.doc │ ├── WBS.jpg │ ├── git使用指南.docx │ ├── 文件命名规范.docx │ ├── 代码规范.docx │ ├── 模型和理论.pdf │ ├── Diary │ └── presentation_template.pptx ├── 订餐系统_原型1.zip └── web/ ├── WEB-INF/ ├── index.html └── README.md

这份大作业的文档设计很有代表性，四样东西正好对应 HCI 课程考核的四个维度：

很多小组把需求分析写成功能清单，这是最典型的翻车姿势。需求分析文档的正确打开方式是回答三个问题：谁在用（角色）、在什么场景下用（情境）、遇到什么问题（痛点），功能只是推导出来的结果。后面第 3 章我会把「场景推导功能」的写法展开讲。

2.3 过程类文件：Diary 和规范文档是隐性加分项

documents 里还有两个容易被忽略的文件：Diary和几份规范 docx。Diary 在人机交互课程里一般叫设计日志，记录的是每周「做了什么、为什么这么做、遇到了什么阻力」。别小看它，老师在判定「这是不是从别人工程里改的」时，最看重的就是过程记录。哪怕你现在才补，也建议按「时间 + 决策 + 理由」三段式补，每段 3～5 句就够，重点是写出决策理由。

文件命名规范.docx和代码规范.docx是最容易被当成凑数文件的材料。实际上它们决定了小组协作能不能顺利：多人合包时如果命名不统一，原型最终版_v3_really_final.zip这种文件名一多，光对齐版本就能耗掉一个晚上。我一般建议小组在第一天就定死三件事：文件命名用「模块名_日期_作者」、代码缩进统一、commit message 带前缀（feat / fix / docs）。

3. 把需求分析写成能答辩的东西：食堂订餐系统的设计链路

这一章是整个项目包的灵魂：企业食堂订餐系统的人机交互设计链路。我按「需求 → 理论 → 拆解 → 原型」四步走，每一步都能在documents里找到对应的材料。重点不是照抄原包内容，而是把「为什么这么做」讲出自己的逻辑。

3.1 需求分析文档的四个段落：角色、场景、痛点、功能

打开订餐系统需求分析.doc，先看它有没有按「背景 → 用户 → 场景 → 功能」组织。一份能过答辩的需求分析，至少要能填出下面这张表：

注意这张表的阅读方向是从左往右：每个功能都必须能从「场景 + 痛点」推导出来，而不是拍脑袋想的。答辩老师最爱问的一句就是「这个功能你为什么做？」，如果你能当场指回「因为财务月末对账要花两天」，这个问题的分数就拿到了。

如果原来的 doc 里没有用户角色表，按下面这种结构补一段进去就够用：

## 1. 用户角色与场景 ### 1.1 企业员工（高频用户） - 场景：工作日 11:50 午休，10 分钟内完成选餐 - 痛点：窗口排队 15 分钟，菜品选择困难 - 功能：菜品分类、预下单、一键复购

逻辑说明：每一段都遵循「角色 → 场景 → 痛点 → 功能」的推导链。参数说明：高频用户这类标记词决定了功能优先级，答辩时可以说「我们优先保障高频场景，所以预下单放在主流程首页，而报表导出放在二级页面」。

食堂订餐的场景非常成熟，角色边界清楚，很适合做 HCI 大作业——这也是原包选它的原因。你只需要把角色换成自己系统的实际用户，推导链完全可以复用。

3.2 模型和理论.pdf 怎么落进设计

模型和理论.pdf 里通常涵盖尼尔森十大可用性启发式、诺曼设计原则、心智模型这类 HCI 核心理论。大作业拿高分的关键不是把十条理论背下来，而是每条理论都能指到一个具体界面设计上。下面是我从原包原型里读出来的几组对应关系：

拿「取消订单」举例：订单确认页必须有明确的取消入口，而且取消之后要有确认弹窗——这对应尼尔森第 3 条「用户控制和自由」，用户误操作后需要一条逃生通道。这种「理论 → 界面」的映射，在答辩 PPT 里一页放一条，比放十页理论截图有用得多。

理论段还有一个用途：写可用性评估。答辩时可以说「我们请了 3 位同学按尼尔森启发式逐条走查原型，发现状态可见性不足，于是加了购物车角标和订单状态条」。这句话同时用上了理论 PDF 和原型两份材料，信息量很大。

3.3 WBS 拆分：把大作业拆到能按天收工

WBS.jpg是工作分解结构图。HCI 大作业的 WBS 不用拆到文件级，拆到「工作包」级就够，关键要让老师看出你有规划意识。参考原包的拆分逻辑，我建议按四个工作包分配精力：

注意 WBS 的拆分粒度：拆到「原型设计」这一层是合适的。如果你把「原型设计」继续拆成「画登录页」「画菜品页」「画订单页」，反而会把自己困在细节里。粒度太细的 WBS 在课程作业里会被质疑「工作量注水」——老师一眼就能看出这是为了拆而拆。正确的做法是每个工作包都对应一个「完成标志」，而不是一堆没有验收标准的动作。

3.4 从原型 1 到可演示：原型迭代的三个版本意识

订餐系统_原型1.zip的命名说明它只是第一版原型。真正能撑起答辩的原型迭代至少要有三个版本意识：低保真线框（画信息架构）、高保真静态（定视觉）、可交互原型（跑流程）。原包里的原型 1 属于「可交互」那一档，它重点不是漂亮，而是主流程能点通。

如果原型是用工具导出的（Axure 或墨刀常见做法），导出后通常是一堆 HTML 文件；如果老师要求现场演示，我建议把最关键的主流程做成 4 个画面以内的演示链路：首页选餐 → 确认订单 → 支付成功 → 取餐码。这 4 步对应第 4 章 web 目录里的页面结构，也对应 3.2 里那张「心智模型」行——主流程越短，越符合用户预期。

4. 让评审看到能点的 Demo：web 目录与本地启动

web目录是整个压缩包里唯一能「跑起来」的东西，也是答辩时最容易出状况的地方。很多小组在这里翻车：现场双击 index.html 页面白屏，或者报错 404。原因多半是没搞清这个目录到底是静态原型还是 Java Web 工程。

4.1 先判断是静态原型还是 Java Web 工程

看目录结构就能判断：如果web下只有index.html、README.md和图片素材，那是纯静态原型，双击就能开；如果出现了WEB-INF目录，就要再往里看一层。WEB-INF是 Java Web 应用的标准目录，里面通常有web.xml，如果有classes或lib子目录，说明这是一个 JSP/Servlet 工程，必须用 Tomcat 才能跑。

在课程原型场景下，WEB-INF更可能只是工程结构的复刻——静态页面放在WEB-INF外的根目录，WEB-INF里只放说明或配置。判断方法很笨但有效：

# 检查 WEB-INF 里有没有编译产物和配置 find web/WEB-INF -type f | head -20

如果WEB-INF下只有一个web.xml或者干脆是空的，那把它当成静态站处理就行；如果出现classes目录或一堆.class文件，就得走 Tomcat 路线。千万不要直接双击WEB-INF下的页面——WEB-INF是被 Servlet 容器保护的目录，任何 Web 服务器都不会直接把里面的文件发给浏览器，这是它存在的意义。

4.2 三种启动方式，按你的答辩环境选

我一般按现场条件选启动方式。最省事的是 Python 自带的 HTTP 服务器：

cd web python3 -m http.server 8080 # 浏览器打开 http://localhost:8080/index.html

这种方式适合静态原型，一行命令起服务，断网也能跑。如果演示机器没有 Python，用 Node 的npx serve或者把目录扔进 VS Code 的 Live Server 插件都行。如果确认是 Java Web 工程，需要走 Tomcat：

# 把整个 web 目录复制到 Tomcat 的 webapps 下 cp -r web /path/to/apache-tomcat/webapps/hci # 启动 Tomcat 后访问 http://localhost:8080/hci/index.html

这里最容易踩的坑是端口冲突和路径大小写。8080 被占用时改conf/server.xml里的 Connector port，webapps/hci这个上下文名在 URL 里必须和目录名完全一致，大小写都不能差。答辩现场网络是玄学，所以我强烈建议本地起服务后先把关键页面截图存一份在 PPT 里，万一现场起不来，至少有图可讲，不冷场。

提示：演示前先确认访问的是webapps根目录下的index.html，而不是WEB-INF内部的页面。后者的访问会被服务器直接拒绝。

4.3 index.html 里的主流程：三步走完一个订单

web 目录的 index.html 如果按「选餐 → 确认 → 结果」三个区块组织，说明原型的交互设计是过关的。典型结构长这样：

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>企业食堂订餐系统 - 演示</title> </head> <body> <!-- 顶部状态栏：对应「系统状态可见性」 --> <header class="top-bar"> <span>今日供应：两荤两素 + 例汤</span> <span>工号 1024，余额 ¥86.50</span> </header> <!-- 主流程：三个区块对应三步，hidden 控制显隐 --> <main class="order-flow"> <section id="step-menu"> <!-- 菜品卡片列表，点击加入购物车 --> </section> <section id="step-confirm" hidden> <!-- 订单明细，支持修改数量与取消 --> </section> <section id="step-done" hidden> <!-- 支付结果与取餐码 --> </section> </main> </body> </html>

三个section用hidden属性做页面内切换，这是静态原型模拟多页流程最常见的做法，好处是不跳转、不会 404，坏处是刷新会回到第一步——演示时手指不要碰到刷新键。如果想在页面内加「加入购物车」和「下一步」的切换逻辑，纯前端就够了：

// 三步切换：选餐 → 确认 → 结果 const steps = ['step-menu', 'step-confirm', 'step-done']; let current = 0; function goTo(index) { steps.forEach((id, i) => { document.getElementById(id).hidden = i !== index; }); current = index; } // 事件委托：点击带 style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;" />