掘金自动发布失败，已降级为半自动待手动发布；发布记录和今日 memory 已更新。
阻塞原因：本地复核后，autocli 无掘金子命令，且 daemon/Chrome extension 未连接；agent-browser 打开掘金编辑器和 auto-connect 均返回 Daemon failed to start；本机 9222-9225 DevTools 端口也不可连接，所以当前无法可靠打开掘金编辑器、写入正文、补齐分类/标签/摘要并发布。
可手动发布内容如下：
标题：企业内部订单系统一期，先做 Web App 还是小程序？我一般看这 4 件事
分类建议：开发工具
标签建议：企业系统、Web App、小程序
摘要：企业内部订单系统一期先做 Web App 还是小程序，不该看入口偏好，而要看订单录入复杂度、高频使用场景、权限状态流转和后续维护边界。
企业内部订单系统一期，先做 Web App 还是小程序？我一般看这 4 件事
做企业内部订单系统时，经常会遇到一个很早就被拿出来讨论的问题：一期到底先做 Web App，还是先做小程序？
这个问题表面上是在选入口，实际是在判断核心流程先落在哪一端。有人觉得内部系统就应该先有一个完整后台，也有人觉得员工和客户都在微信里，小程序更方便。但真到交付阶段，决定项目稳不稳的，通常不是哪个入口更流行，而是订单录入、审批、跟单、查询这些动作，到底发生在什么场景里。
如果一开始只按偏好选，很容易做成两边都别扭：小程序里塞满复杂表格，录入效率很低；Web App 里又堆了很多本该移动端完成的确认动作，最后用户还是回到微信群和 Excel。
先看订单录入是不是重操作
我一般会先看一期最核心的动作是不是“录单”。
如果订单字段很多，要填客户、商品、规格、数量、价格、折扣、交期、附件、备注，还要复制历史订单、批量修改、筛选状态、导出报表，那 Web App 通常更稳。
原因很简单：这类操作需要更大的屏幕、更密的信息展示、键盘输入、批量处理和多列表格。小程序不是不能做，但体验很容易被字段数量拖垮。最后页面一层套一层，用户每填一个订单都很费劲。
所以如果一期目标是让内勤、跟单、运营、财务把订单主流程跑起来，我更倾向于先做 Web App。先把数据结构、状态流转、权限和查询能力打稳，后面再补移动端轻操作，返工会少很多。
再看高频动作发生在电脑还是手机
反过来，如果订单的高频动作主要发生在移动场景，小程序就可能更适合作为一期入口。
比如销售在外面拜访客户时快速提交需求，门店现场录入简单订单，代理或客户只需要查进度、确认信息、上传照片、接收提醒，这类动作不一定需要完整后台。用户本来就在手机上完成沟通，让他回电脑开系统，反而会降低使用率。
但这里有个前提：小程序一期的动作要收窄。它更适合提交、确认、查询、提醒、拍照上传这类轻操作，不适合一上来承担完整订单管理、复杂配置和深层报表。
如果团队嘴上说“先做小程序，简单一点”，但需求清单里又有复杂录单、价格规则、权限管理、报表导出、后台配置，那其实不是小程序简单，而是把后台问题压进了小屏幕里。
权限和状态流转比入口更重要
订单系统真正麻烦的地方，经常不在页面，而在状态和权限。
一个订单从创建到完成，中间可能经过销售提交、内勤审核、财务确认、仓库备货、工厂排产、发货、售后处理。不同角色能看到什么、能改什么、能不能退回、能不能转交、异常时谁来处理，这些规则如果没拆清楚，先做哪一端都会乱。
Web App 的优势是更适合把后台管理、权限配置、列表筛选和异常处理放在一起。小程序的优势是更适合把某个节点的动作变轻，比如提醒某个人确认、让现场人员上传凭证、让客户查看进度。
所以我不太建议把问题问成“Web App 和小程序哪个更好”。更实际的问法是：一期最需要稳定的是整条订单链路，还是某几个移动端节点？前者更偏 Web App，后者更偏小程序。
更稳的做法：先选主战场，给另一端留接口
真实项目里，最怕一开始就说：“Web App 和小程序一起做，反正以后都要用。”
这句话听起来省事，实际很容易让一期范围失控。订单系统里每个角色都能提出自己那一端的需求，销售要移动录单，内勤要批量处理，老板要手机看报表，财务要导出，仓库要扫码，最后两端都做了，但核心链路没有一条真正跑顺。
我更建议一期先选主战场：
-
如果核心是内部录单、审批、跟单、查询和统计，先做 Web App
-
如果核心是外勤提交、客户确认、现场拍照和消息提醒，先做小程序
-
如果两端未来都要有，第一期也要先把主数据、接口、状态和权限模型设计清楚
这样做不是为了省功能，而是为了避免一开始就把系统拆散。只要底层数据和接口边界清楚，后面补另一端通常是扩展；如果一期只顾着把两个入口都做出来，后面修流程就可能变成重做。
结尾
企业内部订单系统一期先做 Web App 还是小程序，不该看哪个入口更顺眼，而应该看主流程在哪里、重操作在哪里、高频用户在哪里、后续维护边界在哪里。
我的经验是：先把最关键的一条订单链路跑稳，比同时做出两个入口更重要。入口可以补，数据结构、权限模型和状态流转一开始做歪了，后面修起来会很贵。
我把这个判断整理成了一篇更完整的文章： sphrag.com/zh/blog/int…
