1. 项目背景业务场景某传统制造企业的IT部门接到任务：在公司内网搭建一套AI辅助系统，用于设备维修手册的智能问答。车间工人在巡检时遇到设备报警，需要快速查询故障代码对应的维修步骤，但目前只能翻阅厚厚的纸质手册，平均每次排查耗时15分钟。部门经理拍板："用大模型！“但问题来了——车间没有外网，运维组长对新技术的态度是"别给我装一堆乱七八糟的依赖”。更麻烦的是，团队用的机器五花八门：开发用的是MacBook Pro，测试机是Windows 11台式机，而目标部署环境是Ubuntu 20.04服务器。痛点平台差异：Windows、macOS、Linux的安装方式截然不同。Windows用户习惯了双击exe，macOS用户担心brew安装的兼容性，Linux用户则被apt和.deb包的依赖关系折磨。团队需要一个统一的基线验证方法。硬件选型无据：跑7B模型要多少内存？要不要GPU？CPU推理到底体验如何？没有人能量化回答这些问题，只能"装完试试看"，非常低效。排错困难：端口占用、权限不足、驱动版本不匹配、代理配置错误——任何一个小问题都可能让服务启动失败。新人面对报错往往束手无策，百度搜出来的答案也不一定适用。一句话总结：**“先跑起来”**这四个字，往往是初学者最大的拦路虎。