9月17日，openKylin 社区会员沙龙郑州站在郑州高新区天健湖智联网产业园举行。紫光计算机、上海伊世智能、商汤科技、先进计算与关键软件海河实验室等企业及科研机构代表，围绕操作系统生态共建、AI 融合创新和 RISC-V 架构支持展开交流。
这几个议题并不是彼此独立的：AI 应用需要稳定的系统接口和算力适配，RISC-V 需要软件包与工具链支持，而生态共建最终要落实为可验证、可复用的兼容性成果。
生态共建不能止于“软件可以安装”
对操作系统社区而言，生态规模不能只看软件数量。一个应用即使成功安装，也可能在图形栈、音频设备、AI 加速卡、系统服务或升级环节出现问题。更有价值的交付物应至少回答以下问题：
- 软件支持哪些 CPU 架构；
- 依赖哪些系统库、内核模块和设备驱动；
- 是否支持离线部署及批量安装；
- 升级后能否回滚，配置是否保持兼容；
- 测试结果对应哪个系统版本和硬件型号；
- 出现问题时由谁维护，如何复现。
因此，企业参与社区时，可以把“适配完成”进一步转化为软件包、自动化测试、兼容性清单和问题复现脚本。这样，单次项目经验才能沉淀为整个社区可复用的工程资产。
AI 融合的关键在系统层，而不只是模型层
AI 与桌面或服务器操作系统结合时，模型往往只是最显眼的一层。真正影响交付效率的还有 Python 运行时、推理框架、硬件驱动、模型文件管理、权限隔离以及资源调度。
例如，一个本地 AI 应用可以拆成四层：
- 硬件与驱动层：识别 CPU、GPU、NPU 等计算设备；
- 推理运行时层：提供统一的模型加载和计算接口；
- 系统服务层：负责进程守护、日志、权限与资源限制；
- 应用层：提供智能搜索、文档处理、图像分析等功能。
这种分层有助于避免应用直接绑定某一款硬件。社区可以围绕统一设备发现、基准测试和故障诊断接口开展协作，让硬件厂商、模型提供方与应用开发者各自维护清晰边界。
同时也要注意数据安全。涉及企业文档、用户输入或设备遥测时，应明确数据是否离开本机、日志保存多长时间，以及模型服务拥有哪些文件访问权限。
RISC-V 适配要从“能够编译”走向“持续可用”
RISC-V 支持不等于完成一次成功编译。实际应用还可能包含架构相关汇编、预编译二进制依赖、容器镜像、浏览器组件和硬件加速库。任何一个环节缺少对应构建产物，都会阻断部署。
更稳妥的方式是建立多架构持续集成：先识别项目中的架构假设，再分别执行构建、单元测试、安装测试和基础性能测试。对于暂时无法原生执行 RISC-V 测试的团队，可以先做交叉编译和静态检查，但应明确这不能替代真实设备验证。
可直接使用：生成一份系统适配基线报告
下面的脚本只依赖常见 Linux 命令，可用于 openKylin 或其他 Linux 环境的适配前检查。它会采集系统版本、CPU 架构、内核、内存、磁盘以及常用开发工具信息，不会主动安装软件或修改配置。
cat > collect-platform-info.sh <<'EOF'
#!/usr/bin/env bash
set -u
output="platform-report-$(date +%Y%m%d-%H%M%S).txt"
{
echo '# Platform Compatibility Report'
echo "generated_at=$(date --iso-8601=seconds 2>/dev/null || date)"
echo
echo '## Operating system'
if [ -r /etc/os-release ]; then
cat /etc/os-release
else
echo 'os-release: unavailable'
fi
echo
echo '## Kernel and architecture'
echo "kernel=$(uname -r)"
echo "machine=$(uname -m)"
command -v lscpu >/dev/null 2>&1 && lscpu || true
echo
echo '## Memory'
command -v free >/dev/null 2>&1 && free -h || true
echo
echo '## Root filesystem'
df -h / 2>/dev/null || true
echo
echo '## Development tools'
for tool in gcc g++ clang cmake make python3 java docker podman; do
if command -v "$tool" >/dev/null 2>&1; then
version=$($tool --version 2>&1 | head -n 1)
printf '%-10s %s\n' "$tool" "$version"
else
printf '%-10s %s\n' "$tool" 'NOT_FOUND'
fi
done
} > "$output"
echo "Report written to: $output"
EOF
chmod +x collect-platform-info.sh
./collect-platform-info.sh
运行后会生成 platform-report-时间戳.txt。团队可以把报告附在兼容性问题单中，并补充应用版本、硬件型号、复现步骤和预期结果。提交前应检查报告内容，删除主机名、设备序列号或其他不应公开的信息。
如果要进一步自动化，可以把脚本放入 CI 流程，并分别在 x86_64、ARM64 和 RISC-V 测试机上执行。报告格式应保持一致，以便比较不同架构的依赖缺口。
从一次交流走向长期协作
郑州站沙龙将操作系统生态、AI 和 RISC-V 放在同一个讨论场域，体现了系统软件协作的现实复杂度。下一步是否产生长期价值，取决于讨论能否转换成可维护的代码、测试和规范。
参与 openKylin 等操作系统社区时，可以从一份务实清单开始：
- 为产品声明明确的系统版本与 CPU 架构支持范围；
- 提供可重复执行的安装、卸载和升级测试；
- 在真实设备上验证 RISC-V，而非只验证交叉编译；
- 为 AI 组件记录驱动、运行时、模型和权限依赖；
- 提交问题时附上脱敏后的环境报告与最小复现步骤；
- 为适配成果指定长期维护者和版本更新策略。
生态不是合作伙伴名单，而是一组能够持续运行的工程关系。只有当兼容性可以复测、问题可以复现、成果可以维护时，沙龙中的共识才会真正进入操作系统和应用产品。