微信小程序设备报修系统开发实战：从状态机设计到订阅消息推送-北京尧图网络

我做了几年小程序开发报修类系统也落地过好几个。这类项目的核心价值不在技术上多花哨而在把“发现设备故障—上报—分派—处理—验收—归档”这条链路走顺让用户少点几次屏幕让维修师傅少跑冤枉路。今天我把这套基于微信小程序的设备报修系统的完整设计思路和关键实现细节整理出来从业务模型到数据库设计从登录鉴权到消息推送每一步都附上实际踩坑记录希望对正在做同类项目的朋友有参考价值。1. 项目概述与整体设计思路1.1 为什么选微信小程序承载报修系统做报修类应用摆在面前的选项有好几个原生App、H5网页、微信公众号、微信小程序。我最终选了小程序核心原因有三个。第一是触达成本。设备报修的使用场景非常分散办公室的电脑、教室的多媒体设备、工厂车间的机器、园区里的照明设施报修人可能是行政、老师、工人、保安这些人手机上不一定装了企业的App但几乎都有微信。小程序扫码即用、不用下载安装对非技术背景用户非常友好。第二是身份体系成熟。微信提供的wx.login静默登录和手机号快速验证组件解决了报修系统最头疼的实名问题。谁报修的、哪台设备、什么时间这些关键信息可以自动带出不需要用户手打姓名电话。第三是消息触达闭环。设备报修天然需要状态通知提交成功、维修师傅接单、维修完成、用户确认。小程序订阅消息可以做到关键节点推送而且订阅消息不像公众号模板消息那样要求用户必须先关注更适合低频但刚需的场景。需要说明的是报修系统这种应用前端只是入口真正的重头戏在后端业务逻辑和状态流转设计上。小程序端承担的角色是“轻量入口状态展示”管理端PC后台或小程序管理员页面负责工单分派、数据统计和结算对账。这套思路无论你是用原生小程序开发还是 uni-app 跨端打包架构上都通用。1.2 系统整体架构这个报修系统的整体架构可以拆成四个层次用户端小程序面向报修人提供扫码/列表选设备、一键报修、进度查看、历史工单、评价确认等功能。管理端面向维修师傅和系统管理员。我做了小程序内的多角色入口同一套小程序代码里根据用户角色渲染不同页面减少维护成本。管理端负责工单接单/分派、处理结果填写、设备台账管理、耗材登记。后端服务我用的 Node.js Express也可以换成 Spring Boot 或 Django核心是暴露 RESTful API。服务端负责登录鉴权、工单状态流转、消息推送、文件上传和数据分析。数据库与存储MySQL 存业务数据Redis 存会话状态和热点数据比如验证码频率限制、今日工单数腾讯云 COS 存报障照片。语言汇总简要来说小程序端是“脸”后端是“脑”数据库是“记忆”。在正式动手编码之前强烈建议先把工单状态机画清楚。我见过不少项目死在这上面状态定义模糊、跳转逻辑混乱最后改起来牵一发而动全身。我用的状态机如下状态含义可流转目标PENDING待分派用户提交后待管理员接单ASSIGNED, CANCELEDASSIGNED待处理已分派给维修师傅PROCESSING, CANCELEDPROCESSING处理中师傅已到场维修中RESOLVED, UNRESOLVED, CANCELEDRESOLVED已解决待确认师傅标记完成待用户确认CONFIRMED, REOPENEDUNRESOLVED无法解决需要报修人重新描述或更换方案PENDING, CLOSEDCONFIRMED已确认用户确认维修结果CLOSEDREOPENED重新开启用户认为未修好PENDINGCANCELED已取消用户取消或超时未处理CLOSEDCLOSED已归档最终归档不可再操作—这个状态机看起来繁琐但实际编码后你会发现所有接口的逻辑都变得非常清晰每个接口只允许从特定状态跳转到特定状态非法流转直接返回错误码排查问题的时候省了无数脑细胞。1.3 核心业务流程梳理设备报修系统有几个核心流程我画一下主场景报修流程用户扫码或从列表选择设备 → 填写故障描述 → 选拍照片最多9张 → 提交工单 → 后端生成工单号进入待分派队列。接单分派流程管理员看到待分派列表 → 选择维修师傅或按片区自动分派 → 师傅收到订阅消息通知 → 师傅联系报修人预约上门时间。维修处理流程师傅到场 → 更新状态为处理中 → 维修完成后填写处理结果用了什么耗材、更换了什么配件 → 标记为待确认。验收归档流程报修人收到完成提醒 → 确认维修效果 → 填写评价 → 工单归档。若确认未修复工单重新开启退回待分派队列。这个流程中最容易忽略的一环是“取消和超时”。实际业务中用户可能误提交、师傅可能接不了单必须在代码层面对这些分支做兜底。我用的做法是待分派状态超过4小时没被接单系统自动通知管理员用户提交后10分钟内可自行取消师傅处理中若发现需要配件缺货可标记为“挂起”并备注原因挂起超过48小时自动升级给更高级别管理员。这些业务规则建议全部放在后端做配置化例如把阈值放在配置表里而不是硬编码后期运营调整时不需要发版。2. 核心功能拆解与数据模型设计2.1 用户登录与角色权限设计小程序登录是报修系统第一个要攻克的点。这里帮大家梳理一下流程和坑。微信小程序的登录推荐使用wx.login获取临时凭证code发送给后端后端拿着code调微信的jscode2session接口换取openid和session_key。注意openid是用户在特定小程序下的唯一标识但不同小程序之间openid不同如果有打通多个系统的需求需要使用unionid。拿到openid后后端要建立用户表和openid的映射并签发自己的自定义登录态我用的 JWT有效期设置2小时滑动续期。不要直接用session_key做业务鉴权它的主要用途是解密手机号等敏感信息。关于手机号获取我用的button open-typegetPhoneNumber组件。用户点击后微信返回encryptedData和iv由后端用session_key解密得到手机号。这里有两个大坑第一getPhoneNumber得到的手机号是加密的解密需要正确的session_key并且同一个session_key只能用一次如果解密失败不要重试要重新走一遍wx.login。第二2023年后微信对getPhoneNumber能力做了收紧需要认证的小程序且完成用户隐私保护指引配置才能调用。遇到“无法获取手机号”的情况90%是隐私协议没有配置完整。关于角色权限我的设计是用户表user带role字段取值 USER普通报修人、WORKER维修师傅、ADMIN管理员。不搞复杂的关系表因为业务上一个人一个角色即可避免权限判断时出现二义性。小程序端拿到用户角色后动态决定底部 Tab 栏展示哪些页面和路由跳转权限。后端每个接口都要做二次鉴权前端隐藏只是提升体验不能依赖前端做安全控制。2.2 设备台账管理报修系统绕不开设备台账。没有设备清单的报修系统用户只能手打设备名数据清洗成本极高。好的做法是在系统里维护一份结构化的设备档案报修时从列表点选或扫码带出设备信息。设备表device核心字段id,device_code唯一编号可扫码name设备名称如“3号空调”category设备类型电子/机械/水电/网络/其他location_id关联位置表位置树形结构园区→楼栋→楼层→房间responsible_user_id设备责任人statusNORMAL正常 / FAULT故障中 / REPAIRING维修中 / SCRAPPED已报废maintenance_cycle保修周期天数用于计划性维保提醒purchase_date,warranty_expire用于保修期判断qr_code小程序码图片URL贴到设备上供扫码这里推荐为每台设备生成专属的小程序码。微信的wxacode.getUnlimited接口可以生成永久有效的码通过scene参数携带设备ID。生成的码图片打印出来贴到设备上用户扫码后直接从设备详情页发起报修流程短到极致。设备位置管理建议用树形结构不要做一维字段。因为报修统计往往需要按区域维度汇总这个月A栋楼报修了多少单、哪个片区耗时最长。树形结构配合path字段比如/1/3/12用LIKE查询按前缀筛选子节点性能尚可逻辑也简单。2.3 工单与消息通知的数据设计工单表repair_order是核心中的核心字段设计直接影响后续统计复杂度order_no工单号格式如BX202501010001加日期前缀方便人肉识别user_id报修人device_id故障设备fault_desc故障描述文本fault_images图片URL列表JSON数组存字符串priority紧急程度LOW普通 / HIGH紧急 / URGENT特急status状态机字段assignee_id维修师傅用户IDappointment_time预约上门时间finish_desc处理结果描述material_used耗材明细JSON数组[{name:开关面板,qty:1,cost:25}]rating评价星级1-5,comment评价文本create_time,update_time,finish_time消息通知采用微信订阅消息。这里必须纠正一个认知小程序订阅消息不是“想发就能发”的。订阅消息有个重要机制——每次发送都需要用户在此之前有一次订阅授权动作。用户点击“允许”按钮后你只能给他发一次消息。要做多节点通知应该在每个节点都主动引导用户授权一次。我的做法是提交报修成功后弹窗请求订阅“报修结果通知”和“进度提醒”。管理员接单后后端调 subscribeMessage.send 推送“您的工单已接单”。师傅标记完成后推送“维修完成请确认”。实践中用户拒绝订阅的情况非常多。作为兜底小程序首页要提供“我的工单”列表用户主动进来查进度。不要试图绕过订阅限制比如用云调用或者统一消息——那些通道都有严格的条件限制对普通开发者不开放。遵守规则是最稳的路线。数据模型设计要考虑的另一个重要维度是耗材与成本。报修不只是把设备修好很多组织还要核算维修成本。我建议建一个独立的repair_material表记录每次工单使用了哪些耗材、单价多少方便后续做财务对账。别把耗材信息塞在工单表的一个文本字段里后面想做统计报表会欲哭无泪。3. 关键模块实操实现3.1 开发环境与项目初始化我用的原生微信小程序开发方式开发者工具版本为最新的稳定版。这里把初始化过程拆得很细因为很多人栽在第一步。先登录微信公众平台注册小程序拿到 AppID。注意个人主体的小程序很多接口权限受限比如getPhoneNumber、订阅消息、微信支付做报修系统这种工具类项目建议用企业主体注册。如果只是本地调试可以用测试号但测试号不支持订阅消息的真实验证。在project.config.json中要正确配置appid。接着在app.js中做全局初始化检查登录态是否过期、请求全局配置比如服务端地址。我习惯把请求封装成一个request.js工具模块统一处理baseURL、请求头注入、token刷新、错误码弹窗提示。这是我的request.js核心封装思路const request (url, method GET, data {}) { const token wx.getStorageSync(token) return new Promise((resolve, reject) { wx.request({ url: ${BASE_URL}${url}, method, data, header: { Content-Type: application/json, Authorization: Bearer ${token}, }, success: (res) { if (res.statusCode 401) { // token 失效重新登录后重试 handleTokenExpired().then(() { request(url, method, data).then(resolve).catch(reject) }) return } if (res.data.code 0) { resolve(res.data.data) } else { wx.showToast({ title: res.data.message, icon: none }) reject(res.data) } }, fail: reject, }) }) }这种封装里最重要的设计是 401 自动续期重发机制。因为小程序端JWT过期后用户会卡在某个操作上如果接口层能自动静默续期体验会好很多。续期的实现是拦截器收到401 → 调用wx.login得到新code → 调后端refreshToken接口 → 拿到新token → 重放原来的请求。数据库我用 MySQL初始化脚本放到项目里维护。工单表加上几个常用索引create_time用于按时间排序查询user_id用于“我的工单”status用于按状态筛选assignee_id用于师傅的待办列表。不要等数据量大了才补索引报修系统一旦上线工单表数据增长是非常快的。3.2 报修提交表单与图片上传报修表单是用户最常接触的界面设计原则只有一个减少输入成本。故障描述用 textarea但用户往往不知道怎么写清楚故障。我加了一个“常见故障快速选择”功能按设备类型预设常见故障标签比如空调类有“不制冷”“异响”“漏水”“不启动”。用户点一下标签自动填入描述文本框减少打字量。图片上传是报修里最重要的辅助信息。微信小程序上传图片用wx.chooseMedia选择然后用wx.uploadFile传给后端。但如果你把图片先压缩再上传整个体验会好很多——报修用户多半用手机流量校园/园区/写字楼网络状况参差不齐原图直接上传容易超时失败。我实践中用的策略选择图片后在本地用wx.compressImage({ quality: 60 })压缩。单张压缩后若仍大于500KB再降quality到40重压。图片走wx.uploadFile上传到后端后端转存到对象存储返回URL。因为微信wx.uploadFile不支持并发控制我写了一个串行队列一张传完再传下一张避免同时开太多连接导致微信卡死。前端页面把提交按钮的 loading 状态用足。用户点了报修后按钮要立刻变成“提交中…”并禁用重复点击。这里我踩过坑第一次上线时没做按钮防重用户看到响应慢就连续点了三四次结果生成了三条相同工单。现在我的做法是前端提交成功后跳转到工单详情页同时后端对同一用户同一设备10秒内的重复提交做幂等校验双重保险。3.3 工单列表与状态流转界面设计用户端和管理端的核心界面都是工单列表。但两端的信息优先级完全不一样。用户端工单列表每项要展示的是工单号、设备名称、状态标签、提交时间。用户最焦虑的是“我报修的怎么样了”所以状态标签要用大色块一眼能分清黄待分派、蓝待处理、橙处理中、绿已完成、红已取消。管理端工单列表每项要展示的是紧急程度、设备位置、故障描述摘要、报修人联系方式、提交时长。维修师傅每天要处理几十单最需要的是优先级排序和快速联系报修人。我在列表右上方放了“电话联系”图标按钮支持直接调起拨号这个细节师傅反馈非常实用。工单详情页的状态流转操作根据角色和当前状态动态渲染按钮。这里核心逻辑全部由后端返回的allowedActions数组驱动前端只负责渲染。这样设计的好处是后端调整状态机规则时前端不用发版。例如管理员看一个待分派工单接口返回的allowedActions是[accept, reassign, cancel]前端只渲染这三个按钮用户看同一个工单allowedActions是[cancel]。这个方案彻底避免了前后端对状态流转理解不一致的问题。3.4 后端接口设计与鉴权实现后端我用的 Node.js Express MySQL路由模块按资源划分。核心接口清单方法路径功能权限POST/api/auth/login微信登录换取JWT公开GET/api/devices/list设备列表按位置筛选登录用户GET/api/devices/:id设备详情登录用户POST/api/orders创建工单登录用户GET/api/orders/mine我的工单分页登录用户GET/api/orders/assigned我的待办工单维修工/管理员GET/api/orders/:id工单详情关联用户POST/api/orders/:id/accept接单维修工/管理员POST/api/orders/:id/finish标记完成维修工/管理员POST/api/orders/:id/confirm用户确认报修人POST/api/orders/:id/reopen重新开启报修人GET/api/stats/overview今日工单/完成率等统计管理员鉴权中间件放在需要权限的路由前统一处理。JWT解码后取出user_id和role然后按接口要求的角色判断。这里的一个细节是不要在前端传user_id/role给后端信任要从 token 里解析。我见过有项目把user_id放在请求体里这是非常严重的安全漏洞——一个用户传别人的user_id就能改别人工单。工单超时升级的定时任务我用 node-cron 实现每10分钟扫描一次待分派工单超过4小时未接单的调用管理员通知接口发送订阅消息给管理员并打上urgent: true标记。3.5 订阅消息的步骤和注意事项这是最容易出问题的一环我单独拿出来详细讲。第一步在微信公众平台后台申请消息模板。在“订阅消息-公共模板库”搜索场景比如“报修进度通知”“维修完成提醒”。选好模板后记下模板ID。第二步在小程序端需要发起订阅时这样写wx.requestSubscribeMessage({ tmplIds: [模板ID1, 模板ID2], success(res) { // res[模板ID1] 可能为 accept 或 reject } })用户在点击报修提交按钮后立刻弹出订阅授权框。这里的关键技巧是把授权框放在用户操作成功之后而不是之前。放在之前用户不知道订阅有什么价值拒绝率很高放在提交成功之后用户正处于“这次报修有求于系统”的心理状态授权率会高很多。第三步后端发送订阅消息调用的接口是subscribeMessage.send。发送时要求提供touser的openid、模板ID、跳转页面路径和模板数据字段。每次发送都要有用户的一次订阅授权记录否则返回 43101 错误码。我实际遇到的几个订阅消息问题接口返回 43101用户拒绝订阅或订阅量用完在代码里要捕获这个错误但不能因此阻塞业务主流程。用户没订阅也能正常查工单只是推送收不到。下发条件限制订阅消息有频率限制同一用户同模板每天最多接收一条。业务上如果真的需要多次下发要错开模板或者用模板中的不同字段组合。测试环境验不了测试号不支持订阅消息必须用正式AppID外加真机调试。4. 常见问题与排查技巧实录4.1 登录链路“无法获取手机号”排查这是上线第一天最可能暴雷的问题。现象是用户点手机号授权按钮没反应或报“微信版本过低”。排查顺序确认是否用的button open-typegetPhoneNumber而不是view绑定事件——微信规定必须用 button 组件。确认小程序后台已配置“用户隐私保护指引”并且在app.json中声明需要收集的用户信息类型手机号。确认 AppID 是企业主体且已认证。个人主体小程序无法调用手机号快速验证组件。真机调试时确认微信版本和基础库版本满足要求基本都满足但旧版本微信确实存在兼容问题。如果是后端解密失败检查session_key是否过期。手机号解密对session_key时效敏感如果用户授权手机号和当初wx.login的时间间隔太长解密失败概率很大。解决方案是用户点击获取手机号按钮时先重新wx.login刷新session_key再弹出授权授权回来后立即解密一气呵成。4.2 扫码进入小程序 params 丢失问题设备二维码用wxacode.getUnlimited生成scene参数带了 deviceId。但有些用户扫描后进入小程序首页没有跳到对应设备详情页。原因往往是通过二维码进入小程序时参数是放在onLoad(options)的options.scene里的而且值是URL编码的。多个参数在 scene 里需要用连接但扫码进入时会被微信自动编码成%26。所以解析时要先decodeURIComponent(options.scene)再按自己约定的分隔符切分。另一个问题如果用户从聊天记录中打开小程序而非扫一扫scene参数会跟扫码不同——聊天记录的分享路径参数在options的 query 中解决办法是两种场景都兼容处理onLoad里统一从options.scene或options.query取值。4.3 图片上传失败与内存溢出上传图片是高频问题。遇到过几类第一类选择图片后wx.uploadFile一直 fail返回errMsg: uploadFile:fail。原因是后端接口没有正确设置 CORS 或者本地开发时把不校验合法域名关掉了但后端地址写的是https://。排查时先看控制台报错的具体信息多半出在域名白名单上。第二类 IOS 设备上传压缩后还是过大。部分 IOS 的大图即使 quality 设为 60 仍然可能很大的对策是对超过 1MB 的图片直接改用 canvas 重新绘制设置canvasToTempFilePath的destWidth和destHeight比如宽度压到 1080px这样几乎能稳定压到 300KB 以内。第三类前端内存问题。表现在选择多张大图后页面卡死对策是选择后立即压缩压缩完就释放原图对象并提示用户上传数量上限我限制9张。4.4 订阅消息推送失败的排查思路订阅消息发送失败先看返回的错误码和错误消息常见问题对照错误码含义解决方案40001access_token 无效检查 access_token 缓存确保用一个全局管理器刷新避免并发获取互相覆盖40037模板ID不正确确认模板ID是否拼错是否从正确的公众号后台复制43101用户拒绝订阅或订阅次数用完在关键节点二次引导订阅或让用户通过工单详情页主动关注进度47003模板参数不匹配模板中每个字段的 key 必须严格一致多一个少一个都报错订阅消息的page字段也要注意跳转路径必须真实存在并且在page前不要加/写pages/order/detail?id123而不是/pages/order/detail?id123——微信的文档里这个细节容易看漏。4.5 系统性能与安全防护报修系统并发量一般不高但一旦开学/开工季集中爆单有几个点会扛不住列表接口的深度分页。不要用传统OFFSET深分页工单多了之后越翻越慢。改用游标分页cursor pagination以create_time id作为游标SQL 用WHERE create_time ? ORDER BY create_time DESC LIMIT 20。设备列表缓存。设备台账基本是低频变更数据用 Redis 缓存一份 JSON设备报修时先从缓存取不在则查库回填。图片防盗链与鉴权。如果对象存储的图片链接被恶意刷量费用可能暴涨。上传后返回的 URL 拼接一个带过期时间的签名参数小程序端图片使用image组件的referrer-policy来限制来源或者在下载时临时签发签名URL。安全层面报修系统因为涉及用户手机号和位置信息要注意隐私合规。用户协议里要写明收集哪些数据、用途是什么。代码层面后端日志不要把手机号明文打到日志里做脱敏处理保留前3后4。5. 项目上线与迭代经验总结从开发到上线我复盘了一下整个项目的时间分配需求梳理和状态机设计用了约20%的时间前后端编码60%联调测试用了20%。状态机设计虽然枯燥但确实值得多花时间它能避开后期大量的返工。5.1 测试要点这个系统测试时有几类场景一定要反复验证第一状态机异常流转。比如师傅接单后用户又要取消、订单重复提交、完成确认超时。这些分支在功能测试里最容易被忽略一旦上线暴露就是直接的用户投诉。第二弱网环境下的请求重试。小程序在用户进入园区、食堂、车库等弱网环境下极容易请求超时。后端接口要支持幂等前端wx.request要设置合理的timeout我设15秒并做重试。重试时要提示用户“网络不稳定”而不是静默重发。第三多端兼容。基础库版本不同导致接口行为不一致的情况很多。我测试时用的设备是iPhone 13 与 iPhone 6 Plus老机型、小米、华为荣耀、Android 5.0 的旧机器。重点验证老机型的渲染性能和上传稳定性。5.2 数据统计与运营看板报修系统不只是处理报修的管理者还希望看到数据。我在管理端加了一个简单的统计页展示几个关键指标今日新增工单数、完成单数、完成率。平均响应时长提交→接单、平均处理时长接单→完成。设备故障排行 Top10。维修师傅工作量排行。统计 SQL 都是基于repair_order表的create_time和finish_time做聚合注意时区问题数据库统一用 UTC 存储create_time查询时用CONVERT_TZ转为东八区再按天分组否则凌晨的工单会被划分到前一天。5.3 多人协作与代码管理经验如果是团队开发建议前后端分仓库管理接口文档用 Apifox 或 Swagger 维护。这里分享一个具体教训第一版对接时我和前端同学没有严格定义接口返回结构各写各的。联调时发现他期望的data是数组而我返回了对象花了整整半天改代码。后来我们统一了约定所有接口返回{ code, message, data }code0表示成功data类型在接口文档中写明。小程序前端代码建议开微信开发者工具的“代码管理”功能配合 Git 分支规范。release 分支保持稳定dev 分支日常开发。每次提测前合出 beta 分支用微信开发者工具的“预览”功能生成二维码发给测试同学扫码体验这个流程效率极高。5.4 后续迭代方向基础报修流程跑通后我建议按这几个方向迭代一是智能派单。目前管理员手动接单/分派后期可以按维修师傅的技能标签电工/水暖/网络和设备类型做匹配自动派单提高接单效率。二是计划性维保提醒。结合设备台账中的maintenance_cycle字段在到期前7天自动生成维保工单把被动报修升级为主动保养。这能提前发现隐患减少突发故障率管理方对这个功能非常买账。三是企业微信集成。有些组织内部用企业微信设备报修的消息同步到企业微信群可以做到免登录直接接受工单通知。这个方案适合已有企业微信的组织但注意要处理好两套身份体系的映射不要既用 openid 又用企微 userId搞一套统一映射表可以省很多事。四是AI辅助故障诊断。现在大模型API已经成熟可以在用户提交故障描述后先让模型分析可能的故障原因和需要的备件推送给维修师傅做参考。这个功能不一定完全准确但至少能帮师傅带着配件上门少跑一趟。最后再分享一个我个人的经验做这个系统时我给每台设备打了一个专属小程序码贴到设备旁边用户扫码后可以直接在设备详情页上看到历史维修记录和最近一次保养时间。这个细节的设计初衷是增加用户对系统的信任感但上线后带来一个意想不到的效果——用户看到设备之前已经修过三次会自动在报修单里备注“上次换的配件又坏了”大大减轻了维修师傅的诊断负担。很多时候系统的价值不在于功能多复杂而在于把信息透明地呈现给需要的人。

微信小程序设备报修系统开发实战：从状态机设计到订阅消息推送

相关推荐

Python字符串与字节拼接：从报错到实战全解析

企业大模型网关实战：从Key管理到Agent接入的完整指南

微信小程序设备报修系统实战：工单设计、状态流转与上线避坑

更多资讯

源极跟随器直流与交流电流分析：从偏置到小信号模型

Multisim丙类功放仿真不收敛？高频设置三要素揭秘

AXI Quad SPI IP核实战：从架构配置到Flash读写与调试避坑

互补推挽电路六种经典用法与炸管避坑指南

Awesome GPT Image 2 信息图篇：用 GPT Image 2 生成知识卡片、健身计划与高考卷的提示词大全

WorkBuddy实战手册：从能用到敢交活的30个AI Agent落地技巧

今日更新

基于sEMG与IMU的手语手势识别：从数据采集到实时部署避坑指南

装配车间MES落地指南：SimpleMES工单流转、BOM与齐套检查实战

AI获客怎样减少重复线索？意客AI的原文复用与版本筛选

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？