上篇结尾，我说「正在进行《安全评估》」。这篇就把这道墙，彻底摊开给你看。
先说结论，不绕弯子： 个人主体，无法完成这个 App 的上架。我放弃了。 不是技术做不到，是制度上，个人开发者过不了那道坎。
这篇不是卖惨。是想把「安全评估」这道最容易被低估的墙讲清楚——它到底查什么、个人开发者死在哪一格、以及我最终为什么放弃。如果你也打算以个人身份上架一个 AI 应用，希望这篇能让你在动手前，先把最致命的那个岔路口看清楚。
一、安全评估现场，查的是这 11 项
安全评估发起后，属地公安网安会现场核查，对照一张《APP 信息服务安全评估检查表》。这张表里，需要技术侧回答的检查项，一共 11 个：
是否有 关键字过滤措施
是否落实 日志留存 （时间 / 项目）
是否落实 安全检测和技术措施
是否 留存用户注册信息
是否落实 实名制
是否 保存公民个人信息
是否有 违法有害信息处置技术措施
是否有 应急处置预案
是否开展 应急处置演练
是否建立 用户投诉举报接收处理制度
是否 留存举报、投诉信息
对照这 11 项，我们工程的现状是： 大部分是 ❌。 原因不复杂——这是个「本地优先」的应用：dsh Host 跑在用户设备上、用户自带模型 API Key、应用自己不运营内容、不做公网分发。
但问题恰恰在这： 按法规，向境内公众呈现模型生成文本的一方，就是「服务提供者」。安全评估义务，不因为「本地架构」而免除。 你以为「我啥也没收集、啥也没运营，应该没我事」，错——只要是把 AI 生成的内容呈现给用户，这份义务就落到了你头上。
二、11 项里，大部分还能补
坦白说，这 11 项里，多数是有技术解的，只是工作量问题：
关键字过滤 ：加一个内容安全插件，挂到 dsh 的模型调用瀑布最前置，输入/输出双向扫词库，命中就阻断或中断。
日志留存 180 天 ：端侧采集审计事件（不带对话正文），批量上报到一个境内云后端，服务端补记来源 IP / 端口，热存 180 天。
安全检测和技术措施 ：这部分其实已经具备大半——token + 签名 cookie 认证、特权方法 loopback 围栏、外链 ArkWeb 化、TLS、最小权限、命令执行审批围栏。缺的只是漏扫报告和一点加固。
应急处置预案 / 演练 ：写制度文件 + 云侧 kill switch 远程停服，每半年演练一次留档。
投诉举报 ：应用内加个举报入口（复用现成的 ArkWeb 外链页）+ 云端表单 + 处理制度。
个人信息 ：补隐私政策页、API Key 静态加密、第三方 SDK 清单、账号注销入口。
这些，本质上都是「工程 + 制度 + 一个境内云后端」能解决的。真要狠下心，都能做。
但注意这里的潜台词 ：所谓「能补」，几乎每一项都指向同一件事—— 你得有一个境内存数据的后端、一套制度文件、以及持续运维的义务 。这跟「开源项目、侧载自用」的定位，已经开始打架了。这个矛盾，会在后面放大成最终的放弃。
三、最硬的一格：实名制
真正卡死我的，是第 5 项—— 实名制 。
法规要求很明确：深度合成服务提供者，要基于 移动电话号码、身份证件号码、统一社会信用代码或国家网络身份认证公共服务 ，对使用者做真实身份信息认证， 不得向未认证使用者提供信息发布服务 。
而且属地执行的公安口径，比法条字面更严： 「第三方账号注册，须加手机验证门槛。」
那问题就来了：个人开发者，怎么给用户做「手机号验证」？四条路我逐条查了：
| 路径 | 能不能拿到手机号 | 个人开发者能否用 | | --- | --- | --- | | A. 华为账号一键登录 | ✅ 完整手机号 | ❌ 仅限企业开发者 （个人只能拿 UnionID/OpenID，拿不到手机号） | | B. 华为账号普通登录 | ❌ 拿不到手机号 | ✅ 个人可用，但过不了「手机验证门槛」 | | C. 自建手机短信验证 | ✅ 手机号 | ⚠️ 短信签名普遍要求企业资质 | | D. 运营商一键取号 SDK | ✅ 手机号 | ❌ 要求企业资质 |
看清楚这个死结了吗： 要过实名制，必须做「手机号验证」；但所有能合规拿到手机号的通道，全都要求企业资质。 个人开发者，一条都不占。
这意味着： 实名制这一格，实际上是在倒逼主体升级——个人开发者必须升级成个体工商户或公司，才可能过这一关。
四、为什么最后选择放弃
到这里，结论其实已经清楚了。摆在面前的只有两条路：
升级主体 （个体工商户 / 公司），把实名制、算法备案、大模型登记、安全评估全套走完——周期以月计，还要持续的合规运维成本。
放弃上架 ，让这个工程停留在「开源 + 侧载自用」的状态。
我选了放弃。原因很朴素： 这是个开源项目，不是一个能持续投入合规成本的产品。 为了上架去注册主体、养服务器、维护制度文件、做年检演练，性价比不成立。
这不是失败。技术侧所有该趟的坑都趟完了：补丁、ACL、pnpm 进程内跑通、ArkWeb PoC、内容安全插件设计，全都验证过了。 真正没迈过去的那道坎，是「个人开发者」这个身份本身。
很多人会把「技术难度」当成上架最大的坎，我也这么以为过。一路走到头才发现：补丁、沙箱、签名、ACL、合规申报，每一个坑都能绕、都能填； 唯独「个人身份」这一条，是硬的门槛，没有任何技术手段能绕过去。 这是我整个系列最值钱的一句教训。
写在最后
回头看整个系列：从把 DeepSeek Harness 做成桌面应用，到搬进鸿蒙、踩 8 个坑、申请 ACL、进程内跑 pnpm、闯 12 条整改，最后倒在安全评估的实名制上——这一路，把「个人开发者上架一个鸿蒙 AI 应用」能踩的坑，几乎全踩了一遍。
最新结论：个人主体无法完成 App 上架，我已放弃上架。 如果哪天我注册了个体工商户或公司，再回来补这篇的续集。
如果你也打算以个人身份上架 AI 应用，这篇最该记住的只有一句： 先查实名制这条路你能不能走通，再决定要不要开始。 否则前面所有努力，都会在最后这一格归零。
如果你正在折腾本地大模型、Electron / 鸿蒙应用化，或者也在琢磨上架 AI 应用，这些资源和踩坑清单能帮你少走不少弯路。欢迎点个「在看」或转发给同样在折腾的朋友。
鸿蒙工程： github.com/fellow99/ds…
桌面工程： github.com/fellow99/ds…
工程总览： github.com/fellow99/de…
上游 DeepSeek Harness： github.com/deepseek-ai…
插件市场： github.com/dsh-market/…
鸿蒙 Electron 运行时： atomgit.com/jianguoxu/h…
感谢各位关注，欢迎访问我的 GitHub 主页： fellow99.github.io/
转载声明：本文为转载整理，原文版权归原作者及原站点所有。
原文来源：Juejin HarmonyOS
原文作者：用户2946940544816；如有侵权，请联系管理员删除。
