企业官网建设流程全解析

1. 这不是职级跃迁，而是一次思维范式的彻底切换

“从BSP工程师到架构师中间差的是什么？”——这个问题在嵌入式技术社区里被反复提起，但多数回答停留在“多学点设计模式”“多看几本架构书”这类泛泛之谈。我干了13年嵌入式，带过27个BSP工程师转岗，其中11人最终成为能独立主导中型嵌入式系统架构的骨干，另外16人卡在“高级驱动开发”阶段多年。真正拉开差距的，从来不是代码行数、不是Linux内核补丁数量、也不是对CH340或CP2102驱动源码的熟悉程度，而是问题抽象层级的不可逆迁移。

你写一个STLink驱动，目标是让JTAG通信稳定、烧录成功率≥99.98%；你写一个FT232R USB UART驱动，目标是串口收发零丢帧、支持115200bps下连续72小时压力测试不崩溃。这些目标清晰、可测量、有明确边界。但当你坐到架构师位置上，第一个需求可能来自销售：“客户要一款能在-40℃~85℃全温域运行、支持AI视觉预处理、同时兼容我们现有三款不同主控（AXU15EGP、STM32F4、RK3399）的边缘盒子”。这时你手里没有现成的Makefile，没有设备树片段，甚至没有确定的硬件BOM——你有的只是一张模糊的场景图、一份带着商业约束的PRD文档，和一个必须在3个月内交付原型的压力。

这就是分水岭：BSP工程师解决“如何实现”，架构师定义“该实现什么”以及“为什么必须这样实现”。前者聚焦于信号完整性、时序约束、寄存器配置精度；后者必须同步权衡硬件选型成本与生命周期、软件可维护性与升级路径、安全合规基线、供应链风险冗余度。比如AXU15EGP系列开发板虽性能强劲，但其配套的Linux BSP包由小厂维护，内核版本滞后主流社区2年以上，若直接采用，意味着未来三年所有安全补丁都要手动backport——这个决策背后不是技术优劣，而是对整个产品生命周期总拥有成本（TCO）的预判。

关键词“bsp”和“架构师”在搜索热词中高频并列出现，恰恰暴露了行业现状：大量BSP工程师正面临职业天花板，却找不到向上的真实抓手。他们刷遍了“嵌入式学习路线”“linux面试题”“嵌入式八股文”，却很少有人系统拆解过：当你要为第十七届蓝桥杯嵌入式国赛真题设计一个“环境监控系统”时，BSP层只需搞定温湿度传感器I2C驱动+LED状态指示；而架构层必须决定——数据本地缓存策略用环形缓冲还是SQLite？网络异常时离线数据如何保证时序一致性？OTA升级失败后能否回滚到上一可用镜像？这些选择没有标准答案，只有基于具体约束的权衡取舍。本文接下来将完全剥离空泛概念，用我在HNU小学期BSP教学、QT嵌入式项目落地、SNMP嵌入式移植等真实场景中踩过的坑，一层层剥开那层隔在BSP与架构之间的“思维薄膜”。

2. 核心能力断层：从寄存器位操作到系统级权衡矩阵

2.1 能力光谱的四个不可跨越维度

很多BSP工程师误以为“多写几个驱动就自然升级为架构师”，这就像认为“多拧几颗螺丝就能造出汽车发动机”。实际上，二者能力模型存在本质性断层，我将其归纳为四个刚性维度，缺一不可：

第一维度：时间尺度的拉伸能力
BSP工程师关注毫秒级响应（如中断延迟≤5μs）、微秒级时序（如SPI CS建立时间≥100ns）；架构师必须思考年尺度问题：AXU15EGP处理器的供货周期是否覆盖产品5年生命周期？当前选用的Linux内核版本，其长期支持（LTS）截止日期是否晚于产品退市时间？我曾主导一个工业网关项目，因未核查上游芯片厂商的EOL公告，导致量产半年后主控芯片停产，被迫紧急切换平台，重写全部BSP层代码，损失超200人日。这不是技术问题，是时间维度缺失导致的系统性风险。

第二维度：约束条件的多维建模能力
BSP开发约束通常是单维的：满足硬件手册时序要求。架构设计则需同时建模至少五类约束：

• 物理约束：功耗上限（如边缘盒子整机≤12W）、散热条件（无风扇被动散热）
• 商业约束：BOM成本压至￥380以内、交货周期≤8周
• 生态约束：必须兼容现有云平台MQTT协议栈、支持客户私有CA证书体系
• 组织约束：团队仅3名嵌入式工程师，无专职测试人员
• 合规约束：通过GB/T 17626.2静电放电抗扰度测试

当这些约束发生冲突时（例如降低功耗需降频，但降频又影响AI视觉算法实时性），架构师必须构建量化权衡矩阵。我在做视觉驱动方案选型时，对比过三种路径：

1. 在AXU15EGP上跑轻量级YOLOv5s（需定制内核+TensorRT加速）→ 满足实时性但BOM成本超预算15%
2. 外挂NPU协处理器（如K230）→ 成本可控但增加PCB面积与散热复杂度
3. 纯软件优化（INT8量化+算子融合）→ 开发周期延长2个月但零硬件成本

最终选择方案3，因为组织约束（人力紧张）权重高于商业约束（成本）。这种决策无法靠查手册获得，只能靠对业务本质的理解。

第三维度：抽象泄漏的预判与隔离能力
BSP工程师常陷入“抽象泄漏陷阱”：以为Linux驱动框架屏蔽了硬件差异，结果在调试CH340串口驱动时发现，不同批次USB PHY芯片的ESD防护等级差异导致同一驱动在低温环境下通信失效率相差40%。架构师必须预判所有可能的泄漏点，并设计隔离层。例如在设计嵌入式环境监控系统时，我强制规定：所有传感器驱动必须通过统一的sensor_hal接口接入，该接口定义read_raw()、calibrate()、get_status()三个原子方法，底层可对接I2C/1-Wire/SPI等任意物理层，上层业务逻辑完全不感知。当客户临时要求替换温湿度传感器型号时，仅需重写一个HAL实现，无需触碰任何业务代码——这种隔离不是为了炫技，而是为应对嵌入式领域最残酷的现实：硬件永远在变，且往往在项目后期才变更。

第四维度：技术债的量化评估与偿还规划能力
BSP工程师常以“能跑通就行”为准则，积累大量隐性技术债：硬编码的寄存器地址、未做错误恢复的DMA传输、忽略电源管理的驱动初始化。架构师必须建立技术债台账，用可量化的指标评估：

• 修复成本：修改CH340驱动以支持热插拔需多少人日？
• 风险系数：当前stlink驱动未实现JTAG链路自动重连，导致产线烧录失败率0.7%，是否触发SLA违约？
• 扩散半径：若现在不重构snmp嵌入式移植中的内存管理模块，未来增加新MIB节点时，代码耦合度将使维护成本指数级上升

我在软考系统架构师论文中详细记录过一个案例：为某电力终端设计架构时，将“驱动热更新”列为高优先级技术债，投入3人周开发动态加载框架，表面看延长了2周工期，但后续6次硬件迭代中，驱动更新平均耗时从18小时降至23分钟，累计节省超400人时。这才是架构师真正的价值：用今天的可控投入，换取未来的指数级效率提升。

2.2 典型能力断层场景实录

以下是我从真实项目中提取的三个高发断层场景，每个都附带BSP视角与架构视角的原始对话记录（已脱敏）：

场景一：Linux系统安装Python引发的架构争议
BSP工程师反馈：“客户要求在嵌入式Linux上运行Python脚本做简单数据处理，我按常规流程交叉编译Python3.9，但根文件系统膨胀到1.2GB，Flash空间不够。”
架构师决策：“禁止在生产固件中集成完整CPython。改为：① 使用MicroPython作为轻量级脚本引擎（ROM占用<300KB）；② 将数据处理逻辑下沉至C语言库，通过Python C API调用；③ 为调试预留SSH通道，允许运维人员临时上传Python脚本——但生产环境默认禁用。”
断层解析：BSP关注“如何装上Python”，架构师关注“为何需要Python”及“不同场景下Python的合理存在形态”。这里隐含了对嵌入式系统安全基线的判断：生产环境不应存在解释型语言执行面。

场景二：QT做嵌入式GUI的资源博弈
BSP工程师抱怨：“QT5.15在AXU15EGP上渲染卡顿，我尝试了OpenGL ES加速、QML编译为二进制、禁用动画，效果仍不理想。”
架构师方案：“放弃QT，改用LVGL+自研渲染引擎。理由：① LVGL内存占用仅为QT的1/5；② 客户UI需求实为静态页面+按钮交互，无需QT的复杂信号槽机制；③ LVGL社区对ARM Cortex-A7优化充分，已有成熟AXU15EGP适配案例。”
断层解析：BSP试图用技术手段修补方案缺陷，架构师直接质疑方案前提。当工具链与需求不匹配时，“如何优化”是伪命题，“是否该用”才是真问题。

场景三：企业微信Linux版的集成困境
BSP工程师求助：“客户坚持要在嵌入式设备上运行企业微信Linux客户端，但官方只提供x86_64 deb包，ARM64移植失败。”
架构师否决：“不移植。改为：① 设备端通过轻量HTTP API与企业微信服务器通信；② 关键消息（如告警）走微信模板消息通道；③ 企业微信仅作为通知入口，所有业务逻辑在设备本地闭环。”
断层解析：BSP陷入“客户要什么就做什么”的执行惯性，架构师坚守“系统职责边界”。嵌入式设备的核心价值是可靠执行控制逻辑，而非成为通用PC的子集。

提示：能力断层不是知识缺口，而是思维惯性的固化。我建议BSP工程师每月做一次“反向架构推演”：拿到一个驱动需求（如ft231x usb uart驱动安装），先不写代码，而是用一页纸回答：这个驱动会影响哪些非功能需求？如果未来要支持热插拔，当前设计需预留哪些扩展点？若主控芯片更换，哪些代码必须重写？哪些可复用？这种刻意练习比刷100道linux常用命令大全更有效。

3. 架构能力锻造路径：从驱动代码到系统蓝图的七步实操法

3.1 第一步：重构你的BSP工作流——从“完成任务”到“沉淀资产”

绝大多数BSP工程师的日常是：接到需求→查芯片手册→写驱动→调通→提交→进入下一个需求。这种线性工作流无法积累架构能力。真正的转变始于将每个驱动开发视为“微型系统设计”。以CH340串口驱动为例，我的重构实践如下：

原始BSP流程：

1. 下载CH340 Linux驱动源码（v3.4.0）
2. 修改Makefile适配当前内核版本（5.10.110）
3. 编译模块，insmod测试收发
4. 解决udev规则不生效问题，添加/etc/udev/rules.d/99-ch340.rules
5. 提交补丁到内部GitLab

架构化重构流程：

1. 需求溯源：确认CH340仅用于调试串口（非生产数据通道），因此可靠性要求低于CP2102（后者用于客户数据上传）
2. 抽象建模：定义serial_hal_t结构体，包含open()/close()/write_timeout()等标准方法，CH340驱动仅实现该接口
3. 约束注入：在驱动初始化中强制校验/proc/sys/kernel/printk日志级别，若为8 4 1 7（即开启所有内核日志），则拒绝加载——避免调试串口被日志洪水淹没
4. 可测试性设计：为write_timeout()方法添加#ifdef CONFIG_CH340_TEST宏，启用后可模拟TX FIFO满、线路断开等故障场景
5. 资产沉淀：将serial_hal.h、测试桩代码、故障注入文档打包为embedded-serial-sdk-v1.0，供后续所有串口设备（CP2102/FT232R/AXU15EGP原生UART）复用

这个过程耗时增加约40%，但带来的收益是：当客户下周要求增加CP2102支持时，开发时间从预估3天缩短至4小时；当产线反馈某批次CH340在高温下偶发丢帧时，我能立即启用故障注入模式复现问题，而非在产线设备上盲目抓log。

3.2 第二步：建立你的“约束检查清单”——把隐形规则显性化

架构师的核心动作是“在约束中舞蹈”，而BSP工程师常对约束视而不见。我强制自己为每个项目建立四维约束检查清单（已验证在蓝桥杯嵌入式国赛、HNU小学期等教学项目中显著降低返工率）：

这张表不是摆设。在开发视觉驱动时，我通过“硬件约束”检查发现AXU15EGP的GPU不支持OpenCL，立即否决了原定的OpenCL加速方案，转向NEON指令集优化，节省2周无效开发时间。记住：架构能力始于对规则的敬畏，而非对技术的崇拜。

3.3 第三步：掌握“驱动子功能筛选与实现”的决策树

标题中提到的“bsp子功能筛选与实现”是典型架构行为。以Linux驱动开发为例，一个看似简单的“实现USB转串口功能”，实际需在数十个子功能中做精准筛选：

USB转串口驱动子功能全景图：

• 基础通信：read()/write()/ioctl()
• 流控支持：RTS/CTS硬件流控、XON/XOFF软件流控
• 电源管理：suspend()/resume()实现USB挂起唤醒
• 热插拔：probe()/remove()的幂等性、设备节点自动创建
• 错误恢复：TX FIFO溢出自动重传、线路噪声滤波
• 调试支持：/sys/class/tty/ttyCH340/device/debug_level动态调参
• 安全加固：禁止TIOCMSET设置DTR/RTS（防恶意设备控制）
• 性能优化：零拷贝DMA映射、中断合并（coalescing）

BSP工程师常全量实现，架构师则用决策树筛选：

是否用于生产数据通道？ → 否 → 仅实现基础通信+热插拔 是否需低功耗？ → 是 → 必须实现电源管理+流控 是否涉密数据？ → 是 → 启用安全加固+调试支持关闭 是否高并发？ → 是 → 启用DMA+中断合并

在某医疗设备项目中，客户要求CH340仅用于固件升级（非实时数据），我仅实现基础通信+热插拔+安全加固，驱动代码量仅380行，而全功能版本超2100行。更关键的是，精简版通过了IEC 62304 Class C软件安全认证，全功能版因调试接口过多被发回整改。

3.4 第四步：构建你的“嵌入式内核源码阅读地图”

BSP工程师读内核源码常陷于“寄存器级细节”，架构师则需建立“系统级脉络”。我绘制的ARM64 Linux内核阅读地图（基于5.10 LTS）如下：

核心动脉（必读）：

• init/main.c：start_kernel()执行流，理解内核初始化各阶段依赖关系
• drivers/base/：设备模型核心（device_register/bus_register），掌握驱动与设备绑定机制
• mm/：内存管理骨架（memblock→buddy→slab），理解驱动DMA内存分配原理
• kernel/irq/：中断子系统（request_irq/irq_set_affinity），掌握多核中断亲和性配置

关键毛细血管（按需精读）：

• drivers/tty/serial/：串口驱动框架，理解uart_port/uart_driver抽象
• drivers/usb/class/cdc-acm.c：USB CDC ACM类驱动，学习USB协议栈分层设计
• arch/arm64/kernel/：ARM64启动流程（head.S→setup_arch()），掌握MMU初始化时机

避坑雷区（标记勿入）：

• net/目录下除net/core/dev.c（设备注册）外，其余网络协议栈代码与BSP无关
• fs/目录下除fs/proc/（procfs接口）外，文件系统实现无需深究
• sound/目录除非涉及音频驱动，否则跳过

这张地图让我在调试STLink驱动时，能快速定位到drivers/usb/core/hub.c中的hub事件处理逻辑，而非在drivers/usb/serial/中盲目搜索。架构师的源码阅读不是为了“懂所有”，而是为了“知道去哪找”。

3.5 第五步：实战“Linux国产化替代”的架构推演

“linux国产”是当前热点，但BSP工程师易陷入“换内核即国产化”的误区。我以某政务终端项目为例，展示架构级推演过程：

原始需求：“将现有基于Ubuntu 20.04的系统，替换为国产Linux发行版”

BSP工程师方案：下载统信UOS ARM64镜像，直接刷写，发现QT应用崩溃、CH340驱动缺失，开始逐个编译驱动。

架构师推演步骤：

1. 定义国产化本质：非单纯换发行版，而是构建自主可控的技术栈。核心指标：内核源码自主率≥95%、关键驱动（USB/PCIe/显示）100%自研、构建工具链（gcc/binutils）可审计。
2. 评估现有资产：当前Ubuntu系统中，CH340/CP2102驱动已开源，可直接复用；但AXU15EGP的GPU驱动为闭源blob，必须替换。
3. 制定分阶段路径：
   • 阶段1（1个月）：基于OpenEuler 22.03 LTS构建最小系统，仅启用必需服务（sshd、dbus），验证基础稳定性
   • 阶段2（2个月）：将CH340/CP2102驱动移植至OpenEuler内核树，提交上游社区
   • 阶段3（3个月）：用开源Panfrost驱动替代闭源GPU，重构QT渲染后端为Vulkan
4. 风险对冲：保留Ubuntu双启动选项，所有业务应用通过Docker容器运行，确保国产系统故障时可秒级切换。

最终项目提前12天交付，且通过了等保2.0三级测评。关键在于：架构师将“国产化”从政治任务转化为可分解、可验证、可回滚的技术工程。

3.6 第六步：打通“软考系统架构师”能力映射

“2026年软考系统架构师论文真题”“系统架构师案例分析历年真题”等热词揭示了一个现实：软考已成为BSP工程师转型的显性路径。但切忌将软考当作应试，而应将其作为能力校准标尺。我将软考五大知识域与嵌入式实践映射如下：

参加软考不是终点，而是将散落的工程经验升华为结构化认知的过程。我的论文全部源自真实项目，连图表数据都是从Jenkins构建日志、Prometheus监控曲线中截取的真实数字。

3.7 第七步：启动你的“遗留系统现代化”改造

“系统架构师遗留系统”是高频热词，直指BSP工程师最熟悉的战场——那些运行着陈旧内核、缺乏文档、无人敢动的“祖传代码”。我的改造方法论是“三不原则”：不推倒重来、不中断服务、不增加新bug。

以某工业PLC的遗留系统（Linux 2.6.32 + 自研BSP）改造为例：

• 第一步：建立基线：用perf record -a sleep 60采集CPU热点，发现73%时间消耗在gpio_get_value()的自旋等待上
• 第二步：微创手术：不重写GPIO驱动，而是在用户态添加libgpiod兼容层，将阻塞调用转为异步事件通知
• 第三步：灰度验证：编写gpiod-tester工具，对比新旧接口在10万次调用下的延迟分布（新方案P99延迟从12ms降至0.3ms）
• 第四步：渐进替换：在新业务模块中强制使用libgpiod，旧模块维持原接口，通过LD_PRELOAD劫持调用

整个过程耗时11人日，零宕机，客户甚至未感知系统已在后台升级。架构师的价值，正在于让变革如春雨般“随风潜入夜，润物细无声”。

4. 避坑指南：BSP工程师转型架构师的12个致命误区与实操对策

4.1 误区一：沉迷技术深度，忽视业务语境

现象：花3周研究Linux内核调度器CFS源码，却说不清客户“环境监控系统”中温度数据上报频率为何定为30秒而非1秒。
后果：技术方案与业务价值脱节，架构设计沦为技术炫技。
对策：强制执行“5 Why业务追问法”。拿到需求后，连续问5次“为什么”：

• 为什么需要温度监控？→ 保障设备在安全温区运行
• 为什么安全温区是-20℃~70℃？→ 客户设备部署在北方户外机柜
• 为什么上报频率是30秒？→ 4G模块流量套餐限制，月均≤50MB
• 为什么不用LoRa？→ 客户现有网络基础设施为4G专网
• 为什么必须本地存储？→ 4G网络存在30%离线率，需保证72小时数据不丢失

这个过程让我在设计存储策略时，果断放弃SQLite（事务开销大），选用轻量级circular_buffer+定期压缩上传，完美匹配业务约束。

4.2 误区二：将架构等同于画框图

现象：用draw.io画出“应用层-服务层-驱动层-硬件层”四层框图，自认为完成架构设计。
后果：框图无法指导开发，团队仍按BSP思维编码，架构沦为墙上的装饰画。
对策：架构图必须附带“契约说明书”。以驱动层为例，我要求每份架构图必须明确：

• 输入契约：驱动接收的参数格式（如struct sensor_config { int sample_rate; bool enable_filter; }）
• 输出契约：驱动返回的数据结构（如struct sensor_data { int32_t temp_mdeg; uint8_t status; }）
• 质量契约：read()调用的最大延迟（≤50ms）、失败重试次数（≤3次）
• 演化契约：新增传感器类型时，哪些字段必须兼容（status字段bit定义不得变更）

在QT嵌入式项目中，这份契约让UI团队能基于sensor_data结构体提前开发数据展示模块，驱动团队完成后仅需对接接口，联调时间从预估5天缩短至2小时。

4.3 误区三：过度设计，追求“银弹方案”

现象：为一个简单的串口配置需求，设计微服务架构+gRPC通信+Kubernetes编排。
后果：开发周期爆炸，系统复杂度远超需求，最终被客户否决。
对策：严格遵循“YAGNI”（You Aren't Gonna Need It）原则，并用“复杂度-价值”矩阵评估：

结果一目了然。我在希沃白板Linux版项目中，曾抵制了“用Docker容器化QT应用”的提议，坚持用传统deb包管理，因为客户现场运维人员无容器运维经验，强行引入会大幅增加售后成本。

4.4 误区四：忽视“非功能性需求”的可测性

现象：在架构文档中写下“系统必须高可靠”，但未定义何为“高可靠”、如何测量。
后果：验收时陷入扯皮，“你说的高可靠”与“客户理解的高可靠”完全不同。
对策：将所有非功能性需求转化为可执行测试用例。例如：

• 可靠性：./stress_test --duration=72h --failure-rate=0.001%（72小时运行，允许千分之一失败率）
• 实时性：./latency_test --target=200ms --percentile=99（99%的请求延迟≤200ms）
• 安全性：./security_scan --cve-db=/path/to/cve.db --critical=0（扫描CVE漏洞，Critical级别漏洞数为0）

在开发ft231x usb uart驱动时，我将“无丢帧”定义为：./uart_stress --baud=115200 --duration=3600 --loss-threshold=0，测试程序自动生成随机数据流并校验CRC，失败时自动dump USB协议分析仪抓包数据。这种可测性设计让质量门禁真正发挥作用。

4.5 误区五：低估“工具链一致性”的破坏力

现象：开发环境用GCC 11，产线用GCC 9，导致浮点运算结果微小差异，引发视觉算法误判。
后果：问题难以复现，排查耗时数周。
对策：实施“工具链钉钉子”策略：

• 所有开发机、CI服务器、产线烧录机，强制使用Docker镜像arm-build:2023.09（内含GCC 10.3.0+binutils 2.37）
• Makefile中硬编码CC = /opt/arm-build/bin/arm-linux-gnueabihf-gcc，禁止使用$(CC)变量
• 每次构建生成build_info.json，记录gcc --version、ld --version、git describe

在AXU15EGP项目中，此策略让我们在发现一个由GCC 10.2.1特定优化bug引发的死锁问题后，能精确复现并提交上游修复，避免了更大范围的影响。

4.6 误区六：将“文档”等同于“架构输出”

现象：产出200页Word文档，但开发团队仍频繁询问“这个接口怎么用”。
后果：文档成为负担，而非生产力工具。
对策：推行“活文档”实践：

• 所有API契约用OpenAPI 3.0规范编写，自动生成SDK与Mock Server
• 架构决策记录（ADR）用Markdown存于Git仓库，每条ADR包含Status（Accepted/Deprecated）、Date、Context、Decision、Consequences
• 驱动HAL接口文档与头文件serial_hal.h同目录，用Doxygen注释自动生成HTML

在CH340驱动项目中，serial_hal.h的Doxygen注释被直接用于生成Qt Creator的智能提示，开发者输入serial->即可看到所有方法说明，文档查阅时间减少80%。

4.7 误区七：忽视“人的因素”在架构中的权重

现象：设计完美的分布式架构，但团队成员无Go语言经验，强行推进导致项目延期。
后果：技术先进性与团队能力严重错配。
对策：建立“团队能力雷达图”，每季度评估：

• C/C++熟练度（1-5分）
• Linux内核调试经验（1-5分）
• Python自动化脚本能力（1-5分）
• Git高级工作流掌握度（1-5分）
• 硬件调试经验（1-5分）

根据雷达图调整技术选型：当Python能力评分为4分时，优先选择Python+PySerial方案；当内核调试评分为2分时，避免设计需深入内核的方案。我在HNU小学期教学中，根据学生能力雷达图，将原本计划的“自研USB协议栈”降级为“基于libusb的用户态驱动”，使92%的学生能在48小时内完成实验。

4.8 误区八：混淆“架构决策”与“技术选型”

现象：“我们选型QT而不是LVGL”，并将此作为架构决策写入文档。
后果：决策缺乏依据，无法应对未来变化。
对策：架构决策必须包含“决策上下文”。正确写法：

ADR-007：GUI框架选型
Context: 项目需在AXU15EGP上实现触摸屏交互，要求：① 支持多点触控；② 内存占用<10MB；③ 开发周期≤6周；④ 团队有3人具备QT经验。
Decision: 采用QT 5.15.2，但禁用QML，仅使用QWidget C++ API。
Consequences:

• ✅ 满足所有约束，开发进度符合预期
• ⚠️ 若未来需支持Web远程管理，需额外开发QT WebEngine模块
• ❌ 无法直接复用LVGL社区组件，需自行开发控件

这种决策记录让后续维护者一目了然，避免