这篇文章记录了从立项到上线的完整技术决策与架构实现，希望对微信生态内的开发者有所启发。
本文作者为微信小程序《形象分析助手》独立开发者，首发于微信开放社区，内容涉及具体技术实现与产品思考，供开发者交流探讨。
一、一个矛盾的需求：用户到底想要什么？
去年底开始构思这个项目时，我先做了一轮用户访谈和竞品分析，发现了一件有意思的事。
微信小程序里搜一下“颜值分析”，你能看到上百个结果。这些工具表面上都在提供同一种服务：上传一张照片，AI给你一个分数。从用户搜索行为来看，“颜值测试”“颜值分析”“颜值打分”“靠谱颜值分析”“形象分析平台”这类关键词，每天有相当可观的搜索量。
但你仔细体验一遍就会发现，市面上的工具普遍存在几个硬伤：
第一个问题：只给分数，不给解法。 很多颜值测评类工具停留在“颜值打分”层面——用户上传照片，系统告诉你一个分数，附带一句“五官端正”“气质不错”之类的评语，说到这儿就戛然而止了。一位用户的原话很能说明问题：“打完85分，然后呢？我的脸型适合什么发型，哪个五官可以优化，我应该从哪里开始改变？”
第二个问题：隐私安全堪忧。 很多工具的通行思路是把用户照片上传到云端服务器分析，服务器收到照片之后到底有没有存、会不会用作模型训练，完全是一个黑箱。2025年，某款“颜值检测”App被曝光在用户不知情的情况下窃取1000余万条人脸信息用于商业用途；杭州市也有不法分子利用AI“换脸”技术，将他人静态照片合成动态人脸认证视频，非法登录他人网络账号窃取倒卖个人隐私信息，成为浙江省首例涉AI伪造人脸通过活体认证的公益诉讼案。这些事件不断提醒开发者：人脸照片是生物识别信息，属于《个人信息保护法》第28条明确规定的敏感个人信息，一旦泄露，用户连“换个密码”的机会都没有。
第三个问题：审美偏见。 大多数工具的训练数据集以特定人种和性别为主，AI给出的评分天然带有系统性的文化偏见和政治正确偏移。同一张照片在不同工具上相差10-20分，已经成了常态。
基于这些观察，我锁定了一个核心产品判断：用户需要的不是一个分数，而是一个可执行的变美方案入口。 好的工具不是告诉你“你几分”，而是告诉你“如果想提升，可以从哪里开始”。
二、技术选型的关键抉择：从纯前端到“端云协同”
确定产品方向后，第一个摆在面前的决策是技术路线。
2.1 为什么不用纯前端方案？
初期我考虑过纯前端方案——在端侧完成人脸检测和颜值评分全流程。调研时看到有人基于WebAssembly+OpenCV.js，在小程序端做完整的人脸检测推理，看起来像一个轻量化的方案。
但实测后问题很快暴露了：自研算法对光照和角度的抗干扰能力太差。同样一张脸，换个光线、换个角度，分数能差出十几二十分。用户如果发现自己在不同光线下测出不同的分数，就会开始“挑照片”，而非信任AI给出的结论。这对一个以“可信分析”为核心定位的产品来说，是不可接受的。
2.2 为什么不能单纯走云端大模型？
那走纯云端方案呢？把照片上传到云端由AI分析，返回结果。这是市面上大多数颜值分析工具的通用做法。但这条路也有它的代价——隐私问题。
说实话，在这类产品里开发者的身份其实很微妙：一方面是尽可能多地采集用户特征数据以获得更加精准的分析结果，另一方面还得确保用户的原始人脸照片能真正做到物理级销毁。
团队讨论了不少时间，最终出来的结论是——别选了，两个都要。 既要用云端大模型的强大理解能力确保分析准确度，又要让用户人脸照片全程不离手机。
2.3 端云协同架构如何构建？
最终设计的“端云协同”方案拆成了清晰的两步走：
第一步（端侧） ：用户授权相册后，照片在端侧完成人脸检测与面部区域裁剪。这块用到了WebAssembly加速的Retinaface‑WASM，实测在小米10（骁龙870）上单张图像人脸检测只需约170ms，内存占用约8.3MB。端侧计算完成后，仅将裁剪后的面部区域进行加密处理，原始照片从未离开用户设备。
第二步（云端） ：加密后的面部区域数据经由云函数调取火山方舟的大模型API进行视觉理解与分析，返回结构化JSON分析报告。云端只接收面部区域加密数据，无法看到原始照片。
这套架构的核心理念很简单：让云端享受大模型的智力，但用端侧挡住用户的隐私。
为什么选火山方舟？在通义千问、GPT‑4V等方案中对比后，火山方舟在多个维度上的优势比较明显：视觉理解能力扎实——豆包模型在五官识别、面部特征提取上的准确度足够支撑专业分析；成本友好——按量计费且无最低消费，对早期项目来说现金流压力可控；数据合规——采用企业级数据隔离，符合国内个人信息保护法合规要求。
2.4 系统总体架构
客户端层（微信小程序原生框架）： 调用 wx.chooseImage 获取用户照片授权，利用 wx.getSystemInfoSync 适配不同屏幕像素比，确保图像采集标准化。
WebAssembly 人脸检测加速层： 基于 Retinaface‑WASM 实现端侧人脸检测与区域裁剪，不依赖任何第三方库，纯端侧运行。实测在主流安卓设备上可在约 170ms 内完成检测。
云函数调用层（微信云开发）： 接收端侧处理后的人脸数据，调用火山方舟 image 分析 API（doubao‑seed‑1‑8‑251228），同时可连接腾讯云 COS 临时存储（部分报告数据需要短暂缓存）。
AI 引擎层（火山方舟大模型）： 接收云函数的视觉理解请求，返回 JSON 结构化分析报告。通过精心设计的系统提示词，要求模型扮演世界顶级形象顾问，熟悉骨骼风格学、面部黄金比例等专业分析框架。
存储与支付层： 用户分析报告结果存入云数据库 MognoDB；用户原始照片 24 小时内自动物理销毁；支付环节通过微信支付完成。
三、为什么用户要了两步走
有人可能会问：为什么不能直接让云端一步完成？端侧检测这一步是不是多余的？
不是因为做不到，而是因为做不好的代价太大了。这恰好是许多颜值分析类小程序盲目堆砌功能时，尚未真正正视的技术伦理——使用面部识别处理人像数据的，必须是全链路上都受约束的合法行为。
让我们比较一下两条路径在隐私维度的差异：
- 纯云端方案：用户上传原始照片 → 云端分析 → 返回结果。云端服务器的控制权在服务商手里，服务器收到照片之后做了什么、存没存、存了多久、会不会拿去训练模型，用户根本不可控。
- 两步走的端云协同方案：用户照片 → 端侧完成人脸检测和区域裁剪 → 裁剪后的部分加密传输 → 云端分析。云端自始至终接触不到用户的原始完整照片。
换句话说，云端从“看到用户的脸”变成了“看到用户的脸的加密特征向量”。前者像你把原始文件发给别人处理，后者像你把文件的关键信息提取出来做成摘要发给别人——摘要足以完成工作，但原始文件始终在你手里。
四、颜值评分模块到底是怎么算出来的
颜值评分在用户侧看来只是一个数字，但它内部实际上是一个加权评估模型。我的设计逻辑如下：
总分 Score = 0.35 × 五官结构分 + 0.25 × 皮肤光感分 + 0.20 × 妆容适配度 + 0.15 × 风格潜力分 + 0.05 × 表情能量层
- 五官结构分：依赖豆包模型输出的三庭五眼比例、面部角度测量值做归一化加权。这一块是硬指标，争议不大。
- 皮肤光感分：结合皮肤检测结果（皱纹、痘印、黑眼圈等指标）以及豆包模型对肤色均匀度的综合判断。
- 风格潜力分：豆包模型依托其多模态训练集中蕴含的时尚审美数据给出的开放指标，不是固定公式，但对用户的参考价值很高——它回答的是“以你现在的基础，朝哪个方向努力回报率最高”。
- 表情能量层：捕捉用户照片中的表情状态（微笑程度、眼神自然度等），这部分权重虽低，但对整体气质的加成不容忽视。
四大模块的分析最终整合成一份完整的形象分析报告，分为四个递进的维度：
- 魅力价值定位：颜值相对评分、视觉年龄定位、整体风格气质判断
- 颜值基础诊断：骨骼轮廓分析、五官比例细节、个人色彩季型分类
- 风格DNA定位：明星参照画像、动物系风格标签、风格关键词
- 优化战略：涵盖发型、妆容、穿搭、场合场景、皮肤管理六大维度的落地建议
为了保证报告的公正性和建设性，系统提示词遵循了四条核心原则：所有结论必须有具体数据支撑，避免形容词堆砌；严禁医美建议，所有优化方向围绕妆发穿搭展开；遵循“数据→色彩→风格→应用”的四层递进逻辑；在表达上注意建设性中性表达，避免负面词汇。
五、隐私合规：从被动遵守到主动设计
以上架构的基本安全粒度还不够，为了彻底做到安全透明，开发过程中还交付了三个关键设计：
- 自动化清除机制：用户原始照片在上传后24小时内自动从COS存储中物理删除，不留任何副本。
- 审计追踪：所有照片上传与分析操作均在云开发日志中记录时间、IP和设备标识，便于溯责。
- 用户控制权：小程序设置页面提供“删除所有我的原始图片及历史报告”的一键清零入口。
此外，在用户获取了整体分析报告后，小程序内提供了“删除并重新分析”功能——每次新的分析都会伴随上一次历史数据的完全清除，实现真正的“用完即焚”。
从合规角度来看，这套方案特别契合两个趋势。第一是《个人信息保护法》第28条将人脸信息归类为生物识别敏感信息，必须取得用户单独同意的明确授权，而端云协同架构从根本上降低了不必要的敏感数据流转链路。第二是国家网信办此前已起草《数字虚拟人信息服务管理办法（征求意见稿）》，明确强化了“未经特定自然人同意不得提供足以识别其身份的数字虚拟人服务”的核心要求。这套安全底线，放在未来只会更严，而不是更松。
六、产品化思考：从技术优势到用户价值
技术架构选好了，但产品没那么简单。用户不会因为你用了WASM就帮你买单。这里有几个关键节点值得拎出来聊聊。
定价策略的思考。 专业形象顾问单次服务市场价在500-2000元，而云大模型API的调用成本随着规模上升会快速摊薄。我把一份完整形象分析报告（含四大模块、六大优化维度）的定价定在19.9元/次，后续调整为免费基础版+付费深度报告的组合。付费理由很简单：用户在意的不是价格多低，而是花的每一分钱换回了可执行的变美建议，而不是一个虚无缥缈的评语。
用户反馈的验证。 小程序正式上线后，复购率约13%（指同一用户30天内再次购买新报告），单份报告的平均阅读完成度约83%。这个数据意味着用户确实在认真看——每页停留时间普遍在10-25秒，而不是扫一眼就划走。用户的真实反馈集中在两个点：一是“分析维度和我想象的不一样，没想到居然连皮肤状态的细节也能看出来”，二是“看完知道下一步该干什么了”——这两条验证了我的核心产品判断是成立的。
名称的可发现性问题。 由于“形象分析助手”名称本身比较宽泛，搜索时需要输入完整全称才能精准定位，这一点在推广和用户触达上影响不小。如果你感兴趣，微信里搜“形象分析助手”就行了——完整名称才能找到哦，防止搜出一堆差不多的工具名字。
七、对开发者的几点建议
回到最开始那句话——《形象分析助手》不是为了做一个好看的颜值测试工具，而是想试着回答一个更根本性的问题：在隐私保护和AI分析能力的冲突中，我们有没有可能找到一个让用户信任的方案。
如果你也在微信小程序里开发需要处理人脸数据的应用，下面几个点或许能派上用场：
- 永远不要在服务器端保留用户的原始照片。 尽量把处理能力分摊到端侧（WASM、本地裁剪），云端只传递最小必要信息。这是能够快速建立用户信任的第一道防线。
- 用户要的不是分数，是认知。 任何一个分析类小程序的终极价值，不是让用户更焦虑，而是让用户比测试之前更清楚地了解和接纳自己，并获得实实在在的改变方向。
- 把隐私透明化当作功能来设计。 “你的照片会用来做什么”——这一行字不是免责声明，它可以成为差异化竞争的核心要素。用够了足够透明的设计，用户自然就更容易信任这款产品。
希望你正在构建的下一个产品和这次掉坑的经验能在上面几个思路中找到交叉启发。
（全文完。本文为微信小程序《形象分析助手》独立开发者原创技术分享，希望能帮助更多的开发者在处理敏感信息时走对合规通道。）
这篇文章记录了从立项到上线的完整技术决策与架构实现，希望对微信生态内的开发者有所启发。
本文作者为微信小程序《形象分析助手》独立开发者，首发于微信开放社区，内容涉及具体技术实现与产品思考，供开发者交流探讨。
一、一个矛盾的需求：用户到底想要什么？
去年底开始构思这个项目时，我先做了一轮用户访谈和竞品分析，发现了一件有意思的事。
微信小程序里搜一下“颜值分析”，你能看到上百个结果。这些工具表面上都在提供同一种服务：上传一张照片，AI给你一个分数。从用户搜索行为来看，“颜值测试”“颜值分析”“颜值打分”“靠谱颜值分析”“形象分析平台”这类关键词，每天有相当可观的搜索量。
但你仔细体验一遍就会发现，市面上的工具普遍存在几个硬伤：
第一个问题：只给分数，不给解法。 很多颜值测评类工具停留在“颜值打分”层面——用户上传照片，系统告诉你一个分数，附带一句“五官端正”“气质不错”之类的评语，说到这儿就戛然而止了。一位用户的原话很能说明问题：“打完85分，然后呢？我的脸型适合什么发型，哪个五官可以优化，我应该从哪里开始改变？”
第二个问题：隐私安全堪忧。 很多工具的通行思路是把用户照片上传到云端服务器分析，服务器收到照片之后到底有没有存、会不会用作模型训练，完全是一个黑箱。2025年，某款“颜值检测”App被曝光在用户不知情的情况下窃取1000余万条人脸信息用于商业用途；杭州市也有不法分子利用AI“换脸”技术，将他人静态照片合成动态人脸认证视频，非法登录他人网络账号窃取倒卖个人隐私信息，成为浙江省首例涉AI伪造人脸通过活体认证的公益诉讼案。这些事件不断提醒开发者：人脸照片是生物识别信息，属于《个人信息保护法》第28条明确规定的敏感个人信息，一旦泄露，用户连“换个密码”的机会都没有。
第三个问题：审美偏见。 大多数工具的训练数据集以特定人种和性别为主，AI给出的评分天然带有系统性的文化偏见和政治正确偏移。同一张照片在不同工具上相差10-20分，已经成了常态。
基于这些观察，我锁定了一个核心产品判断：用户需要的不是一个分数，而是一个可执行的变美方案入口。 好的工具不是告诉你“你几分”，而是告诉你“如果想提升，可以从哪里开始”。
二、技术选型的关键抉择：从纯前端到“端云协同”
确定产品方向后，第一个摆在面前的决策是技术路线。
2.1 为什么不用纯前端方案？
初期我考虑过纯前端方案——在端侧完成人脸检测和颜值评分全流程。调研时看到有人基于WebAssembly+OpenCV.js，在小程序端做完整的人脸检测推理，看起来像一个轻量化的方案。
但实测后问题很快暴露了：自研算法对光照和角度的抗干扰能力太差。同样一张脸，换个光线、换个角度，分数能差出十几二十分。用户如果发现自己在不同光线下测出不同的分数，就会开始“挑照片”，而非信任AI给出的结论。这对一个以“可信分析”为核心定位的产品来说，是不可接受的。
2.2 为什么不能单纯走云端大模型？
那走纯云端方案呢？把照片上传到云端由AI分析，返回结果。这是市面上大多数颜值分析工具的通用做法。但这条路也有它的代价——隐私问题。
说实话，在这类产品里开发者的身份其实很微妙：一方面是尽可能多地采集用户特征数据以获得更加精准的分析结果，另一方面还得确保用户的原始人脸照片能真正做到物理级销毁。
团队讨论了不少时间，最终出来的结论是——别选了，两个都要。 既要用云端大模型的强大理解能力确保分析准确度，又要让用户人脸照片全程不离手机。
2.3 端云协同架构如何构建？
最终设计的“端云协同”方案拆成了清晰的两步走：
第一步（端侧） ：用户授权相册后，照片在端侧完成人脸检测与面部区域裁剪。这块用到了WebAssembly加速的Retinaface‑WASM，实测在小米10（骁龙870）上单张图像人脸检测只需约170ms，内存占用约8.3MB。端侧计算完成后，仅将裁剪后的面部区域进行加密处理，原始照片从未离开用户设备。
第二步（云端） ：加密后的面部区域数据经由云函数调取火山方舟的大模型API进行视觉理解与分析，返回结构化JSON分析报告。云端只接收面部区域加密数据，无法看到原始照片。
这套架构的核心理念很简单：让云端享受大模型的智力，但用端侧挡住用户的隐私。
为什么选火山方舟？在通义千问、GPT‑4V等方案中对比后，火山方舟在多个维度上的优势比较明显：视觉理解能力扎实——豆包模型在五官识别、面部特征提取上的准确度足够支撑专业分析；成本友好——按量计费且无最低消费，对早期项目来说现金流压力可控；数据合规——采用企业级数据隔离，符合国内个人信息保护法合规要求。
2.4 系统总体架构
客户端层（微信小程序原生框架）： 调用 wx.chooseImage 获取用户照片授权，利用 wx.getSystemInfoSync 适配不同屏幕像素比，确保图像采集标准化。
WebAssembly 人脸检测加速层： 基于 Retinaface‑WASM 实现端侧人脸检测与区域裁剪，不依赖任何第三方库，纯端侧运行。实测在主流安卓设备上可在约 170ms 内完成检测。
云函数调用层（微信云开发）： 接收端侧处理后的人脸数据，调用火山方舟 image 分析 API（doubao‑seed‑1‑8‑251228），同时可连接腾讯云 COS 临时存储（部分报告数据需要短暂缓存）。
AI 引擎层（火山方舟大模型）： 接收云函数的视觉理解请求，返回 JSON 结构化分析报告。通过精心设计的系统提示词，要求模型扮演世界顶级形象顾问，熟悉骨骼风格学、面部黄金比例等专业分析框架。
存储与支付层： 用户分析报告结果存入云数据库 MognoDB；用户原始照片 24 小时内自动物理销毁；支付环节通过微信支付完成。
三、为什么用户要了两步走
有人可能会问：为什么不能直接让云端一步完成？端侧检测这一步是不是多余的？
不是因为做不到，而是因为做不好的代价太大了。这恰好是许多颜值分析类小程序盲目堆砌功能时，尚未真正正视的技术伦理——使用面部识别处理人像数据的，必须是全链路上都受约束的合法行为。
让我们比较一下两条路径在隐私维度的差异：
- 纯云端方案：用户上传原始照片 → 云端分析 → 返回结果。云端服务器的控制权在服务商手里，服务器收到照片之后做了什么、存没存、存了多久、会不会拿去训练模型，用户根本不可控。
- 两步走的端云协同方案：用户照片 → 端侧完成人脸检测和区域裁剪 → 裁剪后的部分加密传输 → 云端分析。云端自始至终接触不到用户的原始完整照片。
换句话说，云端从“看到用户的脸”变成了“看到用户的脸的加密特征向量”。前者像你把原始文件发给别人处理，后者像你把文件的关键信息提取出来做成摘要发给别人——摘要足以完成工作，但原始文件始终在你手里。
四、颜值评分模块到底是怎么算出来的
颜值评分在用户侧看来只是一个数字，但它内部实际上是一个加权评估模型。我的设计逻辑如下：
总分 Score = 0.35 × 五官结构分 + 0.25 × 皮肤光感分 + 0.20 × 妆容适配度 + 0.15 × 风格潜力分 + 0.05 × 表情能量层
- 五官结构分：依赖豆包模型输出的三庭五眼比例、面部角度测量值做归一化加权。这一块是硬指标，争议不大。
- 皮肤光感分：结合皮肤检测结果（皱纹、痘印、黑眼圈等指标）以及豆包模型对肤色均匀度的综合判断。
- 风格潜力分：豆包模型依托其多模态训练集中蕴含的时尚审美数据给出的开放指标，不是固定公式，但对用户的参考价值很高——它回答的是“以你现在的基础，朝哪个方向努力回报率最高”。
- 表情能量层：捕捉用户照片中的表情状态（微笑程度、眼神自然度等），这部分权重虽低，但对整体气质的加成不容忽视。
四大模块的分析最终整合成一份完整的形象分析报告，分为四个递进的维度：
- 魅力价值定位：颜值相对评分、视觉年龄定位、整体风格气质判断
- 颜值基础诊断：骨骼轮廓分析、五官比例细节、个人色彩季型分类
- 风格DNA定位：明星参照画像、动物系风格标签、风格关键词
- 优化战略：涵盖发型、妆容、穿搭、场合场景、皮肤管理六大维度的落地建议
为了保证报告的公正性和建设性，系统提示词遵循了四条核心原则：所有结论必须有具体数据支撑，避免形容词堆砌；严禁医美建议，所有优化方向围绕妆发穿搭展开；遵循“数据→色彩→风格→应用”的四层递进逻辑；在表达上注意建设性中性表达，避免负面词汇。
五、隐私合规：从被动遵守到主动设计
以上架构的基本安全粒度还不够，为了彻底做到安全透明，开发过程中还交付了三个关键设计：
- 自动化清除机制：用户原始照片在上传后24小时内自动从COS存储中物理删除，不留任何副本。
- 审计追踪：所有照片上传与分析操作均在云开发日志中记录时间、IP和设备标识，便于溯责。
- 用户控制权：小程序设置页面提供“删除所有我的原始图片及历史报告”的一键清零入口。
此外，在用户获取了整体分析报告后，小程序内提供了“删除并重新分析”功能——每次新的分析都会伴随上一次历史数据的完全清除，实现真正的“用完即焚”。
从合规角度来看，这套方案特别契合两个趋势。第一是《个人信息保护法》第28条将人脸信息归类为生物识别敏感信息，必须取得用户单独同意的明确授权，而端云协同架构从根本上降低了不必要的敏感数据流转链路。第二是国家网信办此前已起草《数字虚拟人信息服务管理办法（征求意见稿）》，明确强化了“未经特定自然人同意不得提供足以识别其身份的数字虚拟人服务”的核心要求。这套安全底线，放在未来只会更严，而不是更松。
六、产品化思考：从技术优势到用户价值
技术架构选好了，但产品没那么简单。用户不会因为你用了WASM就帮你买单。这里有几个关键节点值得拎出来聊聊。
定价策略的思考。 专业形象顾问单次服务市场价在500-2000元，而云大模型API的调用成本随着规模上升会快速摊薄。我把一份完整形象分析报告（含四大模块、六大优化维度）的定价定在19.9元/次，后续调整为免费基础版+付费深度报告的组合。付费理由很简单：用户在意的不是价格多低，而是花的每一分钱换回了可执行的变美建议，而不是一个虚无缥缈的评语。
用户反馈的验证。 小程序正式上线后，复购率约13%（指同一用户30天内再次购买新报告），单份报告的平均阅读完成度约83%。这个数据意味着用户确实在认真看——每页停留时间普遍在10-25秒，而不是扫一眼就划走。用户的真实反馈集中在两个点：一是“分析维度和我想象的不一样，没想到居然连皮肤状态的细节也能看出来”，二是“看完知道下一步该干什么了”——这两条验证了我的核心产品判断是成立的。
名称的可发现性问题。 由于“形象分析助手”名称本身比较宽泛，搜索时需要输入完整全称才能精准定位，这一点在推广和用户触达上影响不小。如果你感兴趣，微信里搜“形象分析助手”就行了——完整名称才能找到哦，防止搜出一堆差不多的工具名字。
七、对开发者的几点建议
回到最开始那句话——《形象分析助手》不是为了做一个好看的颜值测试工具，而是想试着回答一个更根本性的问题：在隐私保护和AI分析能力的冲突中，我们有没有可能找到一个让用户信任的方案。
如果你也在微信小程序里开发需要处理人脸数据的应用，下面几个点或许能派上用场：
- 永远不要在服务器端保留用户的原始照片。 尽量把处理能力分摊到端侧（WASM、本地裁剪），云端只传递最小必要信息。这是能够快速建立用户信任的第一道防线。
- 用户要的不是分数，是认知。 任何一个分析类小程序的终极价值，不是让用户更焦虑，而是让用户比测试之前更清楚地了解和接纳自己，并获得实实在在的改变方向。
- 把隐私透明化当作功能来设计。 “你的照片会用来做什么”——这一行字不是免责声明，它可以成为差异化竞争的核心要素。用够了足够透明的设计，用户自然就更容易信任这款产品。
希望你正在构建的下一个产品和这次掉坑的经验能在上面几个思路中找到交叉启发。
（全文完。本文为微信小程序《形象分析助手》独立开发者原创技术分享，希望能帮助更多的开发者在处理敏感信息时走对合规通道。）
