“不用买服务器、不配域名、不申请模型 Key，如何做出一款带 AI 视觉批阅能力的小程序？真正的难点从来不是写 Prompt，而是端侧真机与物理传感器给你的当头一棒。”
本文记录微信小程序「宝贝作业管家」从第一行代码到 2.0 上线（经历 20+ 个版本真机迭代）的完整全托管实践。全面复盘：PostgREST + RLS + 混元/GLM 模型降级链的全托管红利、视觉大模型“好心脑补”错别字的硬约束方案、放弃小程序内置相机组件的昂贵代价、逐题截图（bbox）两次调用解耦，以及微信第三方授权冻结 CI 发版的排障闭环。
这个项目从第一行代码到真机上线，没有买过一台云服务器，没有部署过一行后端代码，也没有申请过任何 AI 模型的 API Key。
>
我们做的是一个面向小学生的作业与试卷批阅工具（宝贝作业管家）。从最初的 Demo 验证，到体验版、真机测试、备案初通，再到经历了 20 多个版本的真实迭代，整套系统完整跑通了。本文把这套全托管架构的真实红利、隐含边界，以及在端侧真机上踩出来的十几个工程坑完整复盘出来。
01 什么是小程序全托管架构？
很多人对“无后端开发”的理解还停留在静态页面或者纯本地存储。在 WorkBuddy 的架构下，它其实是将一个带 AI 能力的微信小程序所需的服务端基础设施，全部做了一层托管：
- 数据库：基于 PostgREST 协议（Supabase 同款心智模型）。通过平台控制台的 SQL 编辑器建表与写函数，前端用链式调用直连读写；
- 数据权限：基于 Postgres 的 RLS（行级安全策略），系统会自动注入
auth.uid()，通过策略保证数据隔离； - 登录鉴权：提供
signInWithWechat与手机号短信验证码，开箱即用； - 文件存储：自带对象存储，支持自动按用户隔离的私有路径与限时签名 URL；
- AI 模型网关：内置模型目录（混元、GLM、DeepSeek 等），无需自己申请 Key 或充值，统一走网关调度。
这里面最实惠的，是它的模型资源配置。实测中其模型目录里的 hy3（腾讯混元思考模型）支持多模态识图，且单价倍率为零。对于试卷和作业这种图片 Token 消耗极大的场景，多模态主通道挂在上面，运行成本几乎为零；再搭配 glm-5.3-flash 做低成本文本快速兜底，用降级链代替省着调用。
但这套全托管并不是万能银弹。选型之前必须看清它的物理边界：
1没有自定义后端运行环境：服务端不能跑 Node.js 或 Python 代码，业务逻辑要么写在前端，要么写成数据库的 PL/pgSQL 函数。复杂的第三方 Webhook 回调、定时任务或者队列编排，无法直接在服务端展开。
2网关的严格约束：多模态调用拒收普通的 HTTPS 图片外链，只认 Base64 Data URL；遇到流式排队慢时，前端必须自带超时看门狗（比如 45 秒超时切断），否则界面会无限转圈。
3SDK 真机缺陷需手动兜底：SDK 在真机上存在 TextDecoder 缺失报错（真机无 Web API，且沙箱内 global !== globalThis，Polyfill 必须内联注入 SDK 文件顶部）；上传 ArrayBuffer 会被误判抛错，每次重新执行“构建 npm”后都需要手动补丁。
02 手写批阅的视觉 AI：那些 Prompt 治不好的病
当我们在真实场景中用多模态模型批改小学生的纸质作业和试卷时，遇到的第一个系统性打击是：大语言模型的“好心脑补”。
1. 转录与比对必须硬解耦
大语言模型拥有极强的文本先验概率。当看到一个错别字或形近字时（比如孩子把“清泉”写成“情泉”，把“珍惜”写成“借惜”），模型在阅读时会自动顺滑地把它读成正确的字，并给出“完全正确”的判定。对于语文默写、生字词批阅，这种脑补是灾难性的，而且错得无声无息。
反复测试后，有效的约束原则必须在工程上定死：
- 转录与批阅彻底分开：第一道铁律是“逐字客观转录，严禁任何纠正、补全或规范化”，机器判对错的唯一依据，是转录字形与标准答案的字符级严格比对；
- 显式不确定性通道：凡是字迹潦草、没有把握的地方，强制模型在分析中打上「【辨认存疑】」标记。前端检测到该标记时，自动展开人工编辑闸门并挂上黄色徽标，强制家长过目确认，绝不允许模型在后台自作主张。
2. 逐题切图定位（bbox）：先识别，后定位
很多开发者希望让模型在批阅整卷的同时，顺便把每一道题在图中的坐标（Bounding Box）一并返回，以便前端裁出每道题的作答截图。
实测证明：视觉模型“理解卷面内容”很强，但“测算精确坐标”极弱。 一旦让它顺便给坐标，会出现大面积漏框、跨题大框，甚至坐标与题目完全错位。
最终稳定下来的方案是两次调用解耦：
1第一次调用（主批阅）：专注认题、转录、批改，确定题目总数与每道题的开头文字；
2第二次调用（专职定位）：把第一轮识别出来的题目清单作为锚点喂给模型，钉死题号数量与粒度，要求逐题给坐标，防止重新切分造成紊乱；
3坐标容差与修剪：逐题采用独立坐标框，题与题解耦，外扩 2.5% 的安全边距（过大容易吞入邻题，过小会切掉笔画）；只有当下道题的顶边真正被上一题穿透时，才通过工程逻辑硬修剪，允许截图之间轻微重叠。
03 最贵的一课：放弃小程序的内置相机组件
在 1.4 到 2.0 的迭代中，最耗费精力也最昂贵的一个教训，是在图片采集环节。
为了让用户体验顺滑，我们最初花了数周时间在小程序里用
反复排查后，我们发现了小程序的三个底层硬伤：
1
2缺少对焦控制 API：微信小程序的组件文档中，没有开放任何点按对焦或连续对焦调节接口，在低反差纸面和暗光环境下经常拉风箱或虚焦；
3完全吃不到系统相机的算法优化：手机厂商几十人的团队在系统相机里打磨的多帧合成、高动态范围（HDR）、微距降噪，小程序组件通通调不到。
我们在 2.0 版本彻底做了架构断腕：采集端彻底退出 wx.chooseMedia），小程序把全部精力放在导入后的图像处理上。
用户用系统相机拍好后导入，小程序提供轻量直观的交互：
- 拖拽四角完成透视畸变矫正；
- 提供可视化的分栏切割线（尤其是面对大张 A3 试卷时，端上按栏切分成 A4 竖条，难度直接降维）；
- 纯比例缩放与几何运算抽成独立函数，单测覆盖。
单变量对比实验证明：同一个多模态模型，仅仅把输入源从小程序相机抓拍换成手机系统相机导入，试卷文字的识别准确率就产生了质的飞跃。采集端的物理画质缺失，软件界面和 Prompt 根本救不回来。
04 图像预处理的误区：分辨率高于滤镜
对于喂给多模态大模型的文档图像，很多人习惯搬出传统 OCR 的思路：先做灰度化、高斯二值化、锐化去噪。
实测结论正好相反：二值化对大模型不仅无益，反而有害。
传统 OCR 依赖字符边缘的黑白跳变，但视觉大模型识别字符严重依赖微弱的灰度纹理和笔锋连贯性。一旦施加二值化，小学生用 2B 或 HB 铅笔写得稍轻的连笔，直接被滤成了白地，模型不仅认不出，还会当成空白题。
真正收益最高的预处理纪律只有两条：
1分辨率预算拉满：大模型对密集手写字的识别门槛约在 250~300 PPI。在网关体积允许的范围内（Base64 编码后约 1.4MB 内），优先保留原生分辨率；超过上限时，先压像素（如等比缩至 2400px）再适度控质，而不是只降 JPEG 质量。
2减少重复重编码代数：从快门拍下、相册选图、前端裁切到 Base64 编码，每一次 Canvas 导出或压缩都会损失一代画质。在端上尽可能合并处理步骤，避免图片被反复有损压缩。
05 微信生态与发布链路的真实暗礁
脱离了纯开发环境，真正往上线走时，生态层面的规则往往会让不熟悉微信体系的开发者卡壳好几天。
1. 案例复盘：发版罗生门与第三方授权冲突
在开发中期，我们曾遇到一个极其诡异的问题：命令行 CI 工具每次都提示上传成功，后台也能看到新的版本号，但用户手机上的体验版永远显示为老版本，新功能死活出不来。
排查多日后，翻阅微信底层规则才找到真凶：小程序如果在后台把「小程序开发与数据分析」权限授权给了第三方服务商，微信为了防止代码覆盖，会即时冻结该小程序通过公众平台或 CI 自主发版的能力。
在授权期间，CI 工具虽然能把代码推上去留个记录，但“设为体验版”和“提交审核”会被底层静默拦截。终结手段很简单：去微信公众平台后台解除第三方授权，发版通道立刻恢复正常。这也沉淀为我们团队的纪律：让辅助平台初始化必要能力后，尽早收回授权，将上传密钥（CI Key）掌握在自己的自动化脚本中。
2. 账号体系的假象：微信 UID ≠ 手机号 UID
在一次测试数据清理后，有用户反馈“历史数据全空了”，但重新退出再登录又恢复了正常。
排查确认：系统支持微信一键登录与手机号验证码登录。虽然是同一个人、同一个手机，但在 WorkBuddy 底层：
- 微信一键登录生成的身份是
wx:openid； - 手机验证码登录生成的是纯数字
uid。
两者在数据库里是两套隔离的记录。用户偶然切换了登录方式，落进了空壳账号，误以为数据丢失。在多登录态打通之前，产品上必须对家庭共享和身份绑定做显式引导，避免用户对数据安全产生恐慌。
3. 个人主体的新窗口与边界
很多独立开发者受限于个人主体身份，无法开通企业级功能。但 2026 年微信政策迎来了一些关键调整：
- 同声传译与 ASR：微信官方的流式语音转文字插件（WechatSI）对个人主体是静默过滤的（后台搜不到且无提示），直接声明会导致编译失败；需要语音输入的场景，最轻量的解法是引导用户使用手机输入法自带的语音麦克风打字，零开发成本且效果更好。
- 变现新路径：微信全面放宽了个人主体的扶持。个人小程序现已支持接入小程序赞赏组件（在微信开发者助手中免代码一键开通，收益直达个人），同时流量主广告门槛也从 1000 UV 下调到了 500 UV。对于工具类小产品，不需要折腾复杂的企业支付与对公结算，也能在合规框架内跑出微型现金流。
结语：朴素的工程常识
回顾从 0 到 2.0 的全过程，WorkBuddy 这类全托管基础设施最大的价值，是把个人做产品的启动摩擦力降到了前所未有的低点。一个不懂 Linux 运维、不买数据库、不申请模型账号的开发者，完全可以在几天内把一个带 AI 视觉能力的小程序推上线。
但当产品真正面对真实用户、破损试卷、反光桌面和多样机型时，你就会发现：真正决定产品能不能活下来的，从来不是把哪家模型的 Prompt 调得多花哨，而是那些极其朴素的工程细节。
是对分辨率的毫厘必争，是承认传感器能力的物理边界，是对真机沙箱环境的敬畏，是对数据边界的严格把关。把这些最琐碎、最不性感的坑踩平了，AI 的能力才算真正在用户的指尖落了地。