上篇结尾，我说「正在进行《安全评估》」。这篇就把这道墙，彻底摊开给你看。

先说结论，不绕弯子：个人主体，无法完成这个 App 的上架。我放弃了。 不是技术做不到，是制度上，个人开发者过不了那道坎。

这篇不是卖惨。是想把「安全评估」这道最容易被低估的墙讲清楚——它到底查什么、个人开发者死在哪一格、以及我最终为什么放弃。如果你也打算以个人身份上架一个 AI 应用，希望这篇能让你在动手前，先把最致命的那个岔路口看清楚。

一、安全评估现场，查的是这 11 项

安全评估发起后，属地公安网安会现场核查，对照一张《APP 信息服务安全评估检查表》。这张表里，需要技术侧回答的检查项，一共 11 个：

1. 是否有关键字过滤措施
2. 是否落实日志留存（时间 / 项目）
3. 是否落实安全检测和技术措施
4. 是否留存用户注册信息
5. 是否落实实名制
6. 是否保存公民个人信息
7. 是否有违法有害信息处置技术措施
8. 是否有应急处置预案
9. 是否开展应急处置演练
10. 是否建立用户投诉举报接收处理制度
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	✅ 手机号	❌ 要求企业资质

看清楚这个死结了吗：要过实名制，必须做「手机号验证」；但所有能合规拿到手机号的通道，全都要求企业资质。 个人开发者，一条都不占。

这意味着：实名制这一格，实际上是在倒逼主体升级——个人开发者必须升级成个体工商户或公司，才可能过这一关。

四、为什么最后选择放弃

到这里，结论其实已经清楚了。摆在面前的只有两条路：

1. 升级主体（个体工商户 / 公司），把实名制、算法备案、大模型登记、安全评估全套走完——周期以月计，还要持续的合规运维成本。
2. 放弃上架，让这个工程停留在「开源 + 侧载自用」的状态。

我选了放弃。原因很朴素：这是个开源项目，不是一个能持续投入合规成本的产品。 为了上架去注册主体、养服务器、维护制度文件、做年检演练，性价比不成立。

这不是失败。技术侧所有该趟的坑都趟完了：补丁、ACL、pnpm 进程内跑通、ArkWeb PoC、内容安全插件设计，全都验证过了。真正没迈过去的那道坎，是「个人开发者」这个身份本身。

很多人会把「技术难度」当成上架最大的坎，我也这么以为过。一路走到头才发现：补丁、沙箱、签名、ACL、合规申报，每一个坑都能绕、都能填；唯独「个人身份」这一条，是硬的门槛，没有任何技术手段能绕过去。 这是我整个系列最值钱的一句教训。

写在最后

回头看整个系列：从把 DeepSeek Harness 做成桌面应用，到搬进鸿蒙、踩 8 个坑、申请 ACL、进程内跑 pnpm、闯 12 条整改，最后倒在安全评估的实名制上——这一路，把「个人开发者上架一个鸿蒙 AI 应用」能踩的坑，几乎全踩了一遍。

最新结论：个人主体无法完成 App 上架，我已放弃上架。 如果哪天我注册了个体工商户或公司，再回来补这篇的续集。

如果你也打算以个人身份上架 AI 应用，这篇最该记住的只有一句：先查实名制这条路你能不能走通，再决定要不要开始。 否则前面所有努力，都会在最后这一格归零。

如果你正在折腾本地大模型、Electron / 鸿蒙应用化，或者也在琢磨上架 AI 应用，这些资源和踩坑清单能帮你少走不少弯路。欢迎点个「在看」或转发给同样在折腾的朋友。

代码已开源，欢迎 star：

• 鸿蒙工程：https://github.com/fellow99/dsh-desktop-hos
• 桌面工程：https://github.com/fellow99/dsh-desktop
• 工程总览：https://github.com/fellow99/deepseek-harness-workspace
• 上游 DeepSeek Harness：https://github.com/deepseek-ai/deepseek-harness
• 插件市场：https://github.com/dsh-market/dsh-market
• 鸿蒙 Electron 运行时：https://atomgit.com/jianguoxu/harmonypc-electron

感谢各位关注，欢迎访问我的 GitHub 主页：https://fellow99.github.io/