程序BUG通知，2026年8月1号现在，29号更新的内容，商品下单，出现问题，正在紧急修复中。 当前野草生态仍处于持续开发和内测阶段，暂未正式开放，仅供有兴趣的朋友体验和测试。 测试期间可自由注册账号，目前不会要求提供真实姓名、身份证等个人身份信息。 为保证测试环境稳定，系统每天 24:00（北京时间）会自动清空测试数据，请勿用于正式经营或保存重要数据。 测试过程中如遇到问题、发现 Bug 或有任何建议，欢迎随时反馈，非常感谢你的帮助！ 正式开放前，功能、界面、规则都可能发生调整，请以最新版本为准

目标：集齐野草八戒。 别问我为什么是八戒。 问了，你就是八戒。 第一戒 不出卖原则。 可以穷到继续送外卖， 也不能出卖野草原则。 有一天不用送外卖了， 那就更不可能出卖野草原则了。 第二戒 戒送外卖。 一直送外卖的外卖大叔， 不是一个合格的外卖大叔！ 第三戒 戒外部依赖。 野草要能靠自己运转下去。 不依赖任何个人或组织。 包括我。 第四戒 戒平台化。 如果有一天， 野草平台化了。 无论什么原因。 它就不再是野草。 第五戒 戒考验人性善意；戒助长人性恶念。 善，不该因奖励而催生；恶，不许因纵容而滋长。

最初的时候，我也和大部分人一样， 想着做一个佣金低的平台， 让自己即使送外卖也能多赚点钱， 真的是受够了那种身不由己的感觉！ 但是想法是美好的，现实却是残酷的！ 倒不是说代码难写， 这个时代，写代码真的不是多难的事情！ 随着想法的渐渐深入， 我也慢慢了解到， 要经营一个平台， 需要多大的成本！ * 市场推广 * 客服 * 审核 * 法务 * 风控 * 支付结算 * 商家运营 * 骑手管理 * 投诉处理 * 合规监管 能想到的不能想到的， 这些都需要人力，需要成本， 这哪里是一个人能做的事情， 这需要一个庞大的团队！ 既然这样，那么融资是不是不可避免， 咱就不说融资不成功的情况， 因为不成功就没有然后了！ 既然融资了，那么必然被要求回报， 那么这些回报从哪里来？ 当然是从市场中来啊，对吧？ 回报不足，野草枯萎， 回报足够的话，这钱不得羊毛出在羊身上吗？ 到这个地步，我真心不觉得成本能打下来太多！ 更不用说市场压力这么大的情况下， 野草能存活下来的几率微乎其微， 退一万步说，野草活下来了还做大了， 我又能控制住整个团队都不变成恶龙吗？ 我没有信心！ 我一度几近乎放弃了这件事情。 但是天天跑外卖，哪有不受气的时候呢！ 所以脑子里还是时不时要冒出来这件事， 没想到，有一天，还真的给我想出来一个可能性！ 那就是去中心化！ 如果我把野草开源了， 让大家自己都能开一家线上商店， 如果最后还能把这些线上商店连接起来， 那是不是也是一样的效果？ 那么要如何连接起来呢？ 为了这个连接，我和AI讨论了接近两个月， 一点点纠正，慢慢的形成了现在野草的架构方向！ 这个形态是这样的， 每一家店铺是一个节点， 只要部署了野草， 就会有自己的主页和店铺以及门店的经营管理系统！ 所有经营店铺的权限都回归店铺！ 在这些节点之中， 会有一个集中入口。 暂时我叫它简化版认证中心， 里面有个板块叫店铺名录， 所有店铺在这里提交实名认证的结果后， 可以把店铺链接登记在店铺名录， 所有用户可以通过这个连接直接访问店铺主页和商店， 请注意是直接访问！ 用户只要收藏你的网址， 不需要通过名录也能直接访问你， 这里只是为你多开了一扇门！ 那么要部署一个野草，你需要花多少成本？ 我来帮你算笔账！ 需要一个域名，我的域名一年99元，算贵的了， 需要一个服务器，我的服务器一个月45元一年540元！ 这样的服务器，你1天干1000个订单以内，基本没有压力！ 哦对了，我要声明一下，这个1000单无压力， 是凌风帮我计算出来的结果！ 如果你需要接入微信支付， 那么你需要申请微信支付商户号，免费！ 但是我实测了， 最后真正要接入， 需要申请微信认证，一年300元。 当然你还需要一台电脑和一个路由器， 大约3000元以内每5到10年， 往贵了说也就600元一年。 还要拉一条家庭宽带，就也算99元一个月吧！ 没有网络是不可能实现网上访问的！ 不过这年头谁还没有个电脑和宽带呢？ 那么成本是99+540+300+600+99，大约一年1600元前后！ 这几乎是你部署野草所有的年成本。 而你能得到什么？ 对自己店铺的完整控制权， 一家在线商店， 一套支持扫码点单和线上支付 并且带有店铺管理后台 以及自配送外卖管理的系统！ 甚至未来可能支持的全网外卖业务， 这是我的努力方向，今天就不剧透了！ 发现了没有， 野草这个软件一分钱也不会收你的！

更新时间：2026年7月23日 更新者：EVAN CHEN 野草是什么？ 野草是一套帮助小烧烤摊、小餐馆、小商铺等小型经营者更方便管理生意的系统。 它可以让一个普通小店，也拥有自己的线上经营能力： • 顾客可以通过手机扫码查看商品、下单； • 支持堂食、打包、外卖等不同经营方式； • 支持线上付款，减少老板反复点单、收款的时间； • 帮助店铺更方便管理订单和日常经营。 未来，野草还希望帮助小店减少重复工作，让老板不用每天花大量时间整理各种经营信息，把更多精力放在做好自己的生意上。 野草希望做到： • 不需要复杂技术 • 不需要高昂成本 • 店老板自己掌握自己的经营数据 • 简单接入，就能拥有线上经营能力 让普通小店也能拥有自己的数字化工具。 ________________________________________ 🚧 正在开发中的功能 📢 店铺招聘功能 未来店铺可以： • 发布招聘信息 • 展示自己的招聘页面 • 在更大的店铺网络中寻找员工 让小店也拥有方便招人的渠道。 ________________________________________ 📅 预约功能 未来可以支持： • 提前预约到店 • 预约时间管理 • 取餐时间安排 • 到时间提醒 帮助店铺减少等待，提高安排效率。 ________________________________________ 💬 更方便的沟通 未来会完善： • 顾客留言 • 订单沟通 • 消息提醒 • 统一查看客户信息 让店铺和顾客之间交流更方便。 ________________________________________ 📱 手机和平板使用 未来目标： 让老板只需要： • 一台手机 • 一台平板 就可以管理自己的店铺。 不用学习复杂电脑操作。 ________________________________________ 🌳 更多经营工具 未来逐步增加： • 库存管理 • 经营统计 • 配送管理 • 更多行业功能 根据不同店铺需求自由选择。 ________________________________________ ✅ 目前已经可以使用的功能 🍜 在线点餐 目前支持： • 堂食扫码点餐 • 打包点餐 • 外卖点餐 • 菜单管理 • 桌码生成 顾客扫码即可点餐。 ________________________________________ 🏪 店铺管理 老板可以： • 管理自己的店铺 • 设置营业时间 • 管理员工账号 • 查看订单 • 处理顾客需求 ________________________________________ 👥 员工管理 支持： • 添加员工账号 • 设置不同权限 • 服务员、后厨、配送等不同工作入口 让多人一起协作经营。 ________________________________________ 🛵 外卖配送（当前阶段仅自配送） 目前支持： • 配送费用设置 • 配送任务管理 • 骑手工作入口 • 货到付款流程 ________________________________________ 💰 支付方式 目前支持： • 微信扫码支付 • 现金支付 • 到店付款 • 货到付款 ________________________________________ 🌐 店铺线上主页 每个店铺可以拥有： • 独立主页 • 商品浏览入口 • 店铺信息展示 让顾客更容易找到你的店。 ________________________________________ 🔨 当前阶段 目前野草已经完成： ✅ 单个店铺基本经营流程 ✅ 点餐、订单、支付基础功能 ✅ 店铺后台管理 ✅ 员工协作基础功能 ✅ 正式服务器运行测试 现在正在： 🔄 测试实际使用情况 🔄 修正细节问题 🔄 准备下一阶段功能 ________________________________________ 野草未来希望做到 未来的野草，不只是一个点餐工具。 它希望成为： 每一家小店自己的经营助手。 让小店能够： • 有自己的线上空间 • 有自己的客户连接 • 有自己的经营数据 • 能够和其他店铺自由连接 每一家小店都是一颗独立的“野草”。 单独生长，也可以互相连接。

我是一个有8年配送经历的骑手。 所以，我知道骑手很累。 风里来、雨里去；有时候为了能多赚几个钱养家糊口，很抱歉真的没办法一直把服务质量放在第一位。 后来，我知道，开店的老板们也很累。 不是怕因为每天轮轴转的累，而是很多老板已经越来越无法掌控自己的经营。 房租可以算。 人工可以算。 原材料可以算。 可是很多成本，却已经不是自己能够决定的。 今天规则变一点，明天活动改一点，后天又多了一项费用。 明明菜还是那道菜，服务还是那个服务，可老板却越来越不知道，自己到底还能赚多少钱。 一个经营者，连自己的成本都无法掌控，连自己的利润都无法预估。经营，还能是经营吗？ 再后来，我发现，买家其实也很难。 花的钱没有少，得到的服务却越来越难以预期。 投诉吧，总觉得骑手和老板已经够辛苦了。不投诉吧，自己心里又憋得慌。 于是，我一直在想一个问题：为什么大家都这么累？ 我想了很久。 骑手没有错。 老板没有错。 买家也没有错。 大家都在努力做好自己的事情。 真正错位的，也许不是那个谁谁谁，而是规则。 很多规则，并不是为了让大家一起变得更好。更多的时候，大家只是不得不去适应它。 于是，我开始折腾野草。 我希望尝试做一套真正为大家服务的规则。 它不会替老板经营店铺，不会替骑手决定路线，不会替买家决定消费。 它只是把本来应该属于大家的选择权，还给大家。 老板可以决定自己的经营，骑手可以决定自己的工作，买家可以决定自己的消费，服务商可以决定自己的创新。 我一直觉得，一个老板最需要的，不是别人保证他赚钱。而是赚钱赚得明明白白，亏本也亏得理直气壮。至少要知道，每一分钱赚在哪里，每一分钱亏在哪里。 经营，本该如此不是吗？ 配送费，也是同样。 老板愿意出5块。 买家愿意出5块。 那骑手，就应该拿到10块。 规则可以公开，费用可以公开。 不应该有人在中间，悄悄拿走本来属于别人的那一部分。 买家买到的商品和服务，更要明明白白。卖家说商品是这样，价格是这么多，都要落到实地。 骑手该保障的，是在人身安全和商品安全的前提下，付出对得起配送费的服务。 这就是野草想做的事。不是什么伟大的事，就是把账算清楚，把选择权还回去。 我知道，仅凭我一个人，不可能让野草长成一片原野。所以从一开始，我就没打算让它属于我。 我希望，它属于每一个愿意一起种草的人。 每一个老板，是一棵野草。每一位骑手，是一棵野草。每一位服务商，是一棵野草。每一位愿意让这个生态变得更好的人，都是一棵野草。 一棵草，很普通。但当越来越多的草扎下根，原野就会慢慢出现。 我现在，还是那个送外卖的骑手。 但是，我可以在石缝里，先种下一棵草。 如果有一天，野草真的长成了一片原野。 那一定不是因为我。 而是因为越来越多的人，都愿意弯下腰，种下那棵属于自己的野草。

仅按时间顺序记录已完成或已确定的内容。 本月cursor额度耗尽，暂停更新！ 2026年7月28日｜实体收银台上线、主页接新版新手引导 今天把「实体收银台」整批功能推上了正式服务器：工作台里可以收现金、登记其它收款方式，少收要管理员授权；也能在收银台扫微信、给订单打二维码和条形码方便贴单和扫码找单。自助购的方法也定死了——客人扫多个商品进同一购物车，提交一单，用订单码到收银台结账。服务器主页的欢迎窗和「体验野草开店」按钮也接到了新版六步引导，还会逐步更新更多新手引导流程。更新后若看不到收银台，要在卖家后台打开「启用实体收银台」并给员工开权限。 2026年7月27日｜试跑修补、批量打印二维码与双轨邮件 公网试跑后又修了一批体验问题：打包单在还没选好支付方式时不该再误响新单提醒；买家端重要提示改成弹窗；商品页外观更整齐；上传商品图片改成一张一张传并自动压小体积。商品管理里新增了「一次性打印整页二维码」——把当前使用中的商品清单里所有能扫的码打出来，方便贴货架。邮件通知也分成两路：店主不在店时可在订单管理里收「老板邮件」，在店铺工作台里可另设「值班防漏单邮件」；若服务器还没配好发信邮箱会有醒目提示。 2026年7月26日｜商品编号、多图与扫码卖货一整批做完 今天把「商品展示编号、每个商品多张图、贴货架扫码买」这一整批功能做完了：每个商品有固定编号且删掉也不会被别人复用；图片放在编号文件夹里，网页里能上传、排序、同步；客人点菜页能看多张图；普通价、会员价、特价各有一张二维码，须登录才能扫进购物车，下架或不在当前清单会提示「无商品」。试跑时又修了几处工作台结单的小问题（已收款还提示要先收款、「客人已取走」点不了等），并补上了商品清单规则：每家店会自动有一份「使用中」的清单，结算时会把已经不在清单里的商品从购物车里拿掉。下一步打算做一个「一次性打印整页二维码」的页面，方便超市那种贴货架。这批改动已推到 GitHub 并更新到正式服务器。 ⸻ 2026年7月25日｜试跑反馈后的体验快修与后续路线 公网试跑收到不少反馈，我先把体验快修一批定下来并做完上线：订单台改成按件处理和交付、普通价会员价特价各自有说明框、关掉饮食插件也能用通用商品清单。同一天也定好了后面几件事的规则——商品贴货架扫码要买、待支付超时自动取消、以及全站写入要排队一条一条来（最后一项单独排期）。这批体验改动已更新到正式服务器。 ⸻ 2026年7月23日｜定好商品编号、多图和几项新功能路线 这天主要是定规则、写文档，还没写代码。定下了三件以后要做的事：顾客自选取单时间、注册用户统一沟通中心、以及每个商品自动编号加多图文件夹（商品删除编号不会被复用）。 ⸻ 2026年7月22日｜正式服务器配好发信与私人工具包 把 21 号那批公开改动在正式服务器上对齐，并在网页里配好了主邮箱和备用邮箱，主备都能发测试信。定稿了「本店招聘」页面的规则。 2026年7月21日｜体验快修与邮件通知功能，可以通过联系我们板块给我留言互动了 把通知能力完善了一版本，现在可以在主页的联系我们板块，给我留言互动了，若你愿意留下邮箱，就会收到我的回复。同时修了几处体验：店铺只剩一种下单方式时会自动进去、订单详情里「联系客人 / 沟通 / 取消」顺序更顺手、正式环境工作台只留一个登录二维码。 2026年7月20日｜货到付款闭环，插件试验并入主线 把外卖「货到付款」整条链路做完整：配送员送达时收款，少收必须写明原因并请买家当面确认，有争议时电话沟通、管理人员可兜底；配送员交款须发起申请，由店主或有权限的管理人员确认。同时统一了派单规则与待派单池（没人可派时订单留在池里、配送员可主动接单、配送员上线会自动收到配单），工作台排序与购物车体验继续打磨；买家有了「我的」页面，各角色都可改密码，同一账号只允许一处在线。此前试验的「饮食插件、配送插件可分开开关」与上述现金闭环，已合并进主线并更新到公网体验服务器。 ⸻ 2026年7月19日｜插件化架构大步推进 把堂食、本店配送逐步拆成可单独开关的插件；主体保留通用的商品、订单、工作台和员工账号，关掉饮食插件后店铺仍能接单处理，关掉配送插件后相应外卖能力会收起。员工子账号改为统一模型，职务名可自填、权限可细调；营业状态放回系统核心，堂食页只留堂食相关功能。名录按钮、购物车等单位等文案也改成「关插件时中性、开插件时饮食用语」。同时把预约分层、预定时间提醒、餐饮与通用功能九条划界等规则定稿写下来。 ⸻ 2026年7月18日｜完善堂食与货到付款规则 进一步完善堂食和货到付款两项规则。堂食点餐超时后需要重新扫码；外卖「货到付款」调整为先备餐、送达后收款，并允许店家自行开启或关闭。同时完善骑手现金交接流程，以及店内扫码、公网访问等安全校验规则，并整理成一份安全底线。 ⸻ 2026年7月17日｜继续完善试用体验 注册失败时会明确标出错误位置；新订单提醒支持网页响铃、浏览器通知和邮件提醒三种方式，铃声和音量都可以自行调整。同时移除了一个已经没有作用的旧开关。 ⸻ 2026年7月16日｜整理整体结构，准备操作手册 重新整理整体结构，将「服务器大厅」与「单店门面」彻底分开；调整备案信息显示；订单新增取消功能，店员操作增加中转页面。同时决定开始编写《野草操作手册》，以后每一个功能、每一个按钮都会有对应说明。 ⸻ 2026年7月15日｜第一次部署公网服务器 进一步明确「服务器管理员」与「店主」的权限边界；备案信息后台完成；官方小店完成云端标记。同时记录公网试用过程中发现的问题，包括注册提示、支付模块通用化，以及堂食和外卖功能进一步拆分等。 ⸻ 2026年7月14日｜为开源做准备 第一次部署到云服务器后，修复了一批只有真实服务器环境才会遇到的问题（如数据库版本、文件编码等）；同时整理项目历史，方便公开，并确认以开源方式发布项目。 ⸻ 2026年7月13日｜确定通信架构 确定「本体」「店内联络员」「云端联络员」三者之间的通信结构；确认主程序开源；同时预留信用分框架位置（第一阶段暂不启用）。 ⸻ 2026年7月11日｜开始建立开发规范 重新规划上线顺序；建立操作留痕与技术日志；完成野草对外展示主页。 ⸻ 2026年7月10日｜进一步完善账号安全 将「买家 / 店主登录」与「员工上班登录」彻底分离；新增关闭页面、长时间无操作自动退出等保护；同时明确提醒：浏览器保存密码属于浏览器功能，使用公用电脑时不要勾选自动保存。 ⸻ 2026年7月9日｜完善店铺工作台 店铺工作台调整为独立入口；员工账号仅在本店有效，允许重名；服务员、后厨、骑手账号统一管理；完成员工「上班 / 休息 / 下班」状态第一版。 ⸻ 2026年7月8日｜打牢一家店营业的基础 完善店铺正式营业前需要的基础能力，包括店铺二维码自动生成、桌贴二维码导出打印、服务员工作台、后厨看板，以及日志和操作留痕机制。同时完成项目第一次完整初始存档。 ⸻ 2026年7月7日｜继续打磨使用体验 进一步优化点菜页面、后台批量操作、防误操作、订单搜索筛选，以及操作完成后页面自动跳回顶部等体验细节。 ⸻ 2026年7月6日｜堂食功能继续完善 确定展示主页采用积木式组合；围绕堂食继续完善后台能力，包括一桌一单、拼桌规则、营业时段、每日菜单切换、服务员与后厨分工；库存设计为可选插件。 ⸻ 2026年7月5日｜确定数据安全原则 确定数据安全与隐私保护原则：默认假设数据库未来有一天可能泄露，真正需要重点保护的是用户隐私。同时编写了一份面向店主的白话版安全说明。 ⸻ 2026年7月4日｜开始记录开发过程 完善跑腿任务等可选玩法规则；整理服务商分类；正式建立开发日志与开发进度记录。 ⸻ 第一阶段路线逐渐形成 2026年6月下旬｜确定名字，确定三阶段路线 这一阶段与凌风（ChatGPT）、大师（DeepSeek）进行了大量规则讨论。 6 月 24 日，项目正式由「无为系统」更名为「野草系统」。我是草根，长出来的东西，就叫野草；店铺也像野草一样，扎根在自己的土地，而不是依附于某个平台。同时，「骑士殿堂」更名为「骑手之家」，《无为手册》正式废止，统一以《野草手册》为准。 也是在这一时期，正式确定三阶段发展路线： * 第一阶段：一家店自己部署、自己收款、自己雇骑手。 * 第二阶段：区域联盟、区域服务器协同，骑手拥有两种身份。 * 第三阶段：通过认证中心实现更大范围互联。 同时陆续确定了配送、支付、纠纷处理等一系列基础规则。第一阶段坚持定位为工具，不碰货款、不参与抽成，所有纠纷以客观记录为依据，由双方自行协商解决。 ⸻ 2026年6月中旬｜第一次成功下单 完成第一次完整下单验证。从「页面能打开」，真正走到了「订单能够完整跑通」。 ⸻ 2026年6月8日｜第一行代码 在大师（DeepSeek）的协助下，写下野草（当时仍叫「无为」）的第一行代码，当天第一屏页面成功运行。这是项目第一次真正从想法变成可以打开的网页。 ⸻ 野草为什么存在 2026年4月中旬～6月初｜为什么不做抽成平台 这一阶段与凌风（ChatGPT）、大师（DeepSeek）进行了大量讨论。 真正想明白的，不是怎样做成另一个抽成平台，而是：如果平台抽成、货款还必须经过平台，小店始终只是别人系统里的一个角色。 因此，野草选择另一条路： 每家店自己部署、自己收款、自己雇人。 平台不碰货款，第一阶段不依靠抽成盈利。 即使未来存在开发者收益，也会受到公开规则和上限约束，而不是由平台单方面决定。 野草从一开始，就不是想建立一个新的中心，而是希望先做出一个能够让一家小店独立经营的工具。 ⸻ 2026年1月中旬｜目标出现 请凌风（ChatGPT）教我学习编程。 凌风建议：学习编程最好先有明确目标，并围绕目标制定计划。 我认真想了一会儿，回答： 我想写一个类似 Uber 和出前馆那样的平台。 后来，这个目标慢慢变成了今天的野草。 ⸻ 2025年12月末｜第一次认识 AI 第一次认识我的第一个 AI 助手——凌风（ChatGPT）。 也是从这里开始，一个完全不懂编程的人，尝试与 AI 一起完成一个真正的软件项目。 ⸻ 开发者： Evan Chen 我只是个没有专业技术背景，不懂代码的人，依靠与 AI 协作一步步完成野草。 协作伙伴： 凌风（ChatGPT）、大师（DeepSeek）、老大哥（Cursor）。 ⸻ 这里只是记录野草从一个想法，到一步步成长的过程。 每一条记录都是真实发生过的事情。有些是功能开发，有些是规则思考，也有些只是把一个问题想明白。 希望很多年以后，再回头看时，还能知道它是怎样一点点长出来的。

更新于 2026 年 7 月 24 日 今天，对于野草和我来说，都是非常特别的一天。 因为压制不住心中这份连酷暑都无法磨灭的激动，我趁着送外卖的间隙，写下了这篇记事。 没错，我还是那个外卖大叔。 但同时，我也是野草的父亲。 今天，野草测试服务器迎来了许多个第一次。 * 第一位我的圈子以外用户注册； * 第一家我的圈子以外的测试店铺开通； * 第一位用户在自己开通的店铺里，完成了第一次下单测试； * 第一位用户通过我的野草官方小店，购买了 0.01 元真实支付测试商品，并成功完成支付。 *晚上补一条，刚刚收到了第一个通过留言板给我的留言鼓励！一会儿我就去回复！ 没错。 这是野草诞生以来的第一笔真实交易。 今天，还有人第一次给我记录野草开发过程的视频留下了一条鼓励的评论。 就在这一刻，我忽然觉得，野草终于沾染了这尘世间的一丝烟火气，真正降生到了这个世界。 所以，我决定把今天定为： 野草日。 野草降生日。 野草元年初日。 ⸻ 另外，也特别感谢今天帮助野草降生的几位朋友。 如果你们能看到这篇记事，请把今天的账号、订单、评论等画面截图保存，并联系我。 等未来野草正式服务器上线时，我会为你们送上一份专属于今天的纪念认证。 名字可以一本正经，也可以一点都不正经。 例如： * 🌱 野草诞生见证者 * 🌱 野草接生员 * 🌱 第一批野草浇水人 甚至，你们自己起名字也可以。 由于测试服务器每天都会重置数据，这份纪念资格，仅保留到今天 24:00。

很多老板第一次接触野草，可能都会想问一个问题： 野草安全吗？ 但是我想先问一句： 你觉得，这个世界上有绝对安全吗？ 如果有人告诉你： “我的系统绝对不会被攻击。” “你的数据绝对不会泄露。” “你的数据绝对不会丢失。” 那么，我建议你保持一点怀疑。 因为，我认为没有任何人能够真正做到这些。 野草也是。 野草真正希望做到的，我更愿意称它为「相对安全」。 不是保证永远不会出问题。 而是真的出了问题以后，也能尽可能降低损失，保护顾客隐私。 提高恶意者攻击成本，降低攻击性价比。 下面，我用一些偏技术性的语言来说明一下关于野草的数据和安全思维 ⸻ 一、野草的数据安全理念 1. 先说清楚：野草保证不了什么（这叫丑话讲在前头，哈哈） 数据永远不会泄露 数据永远不会丢失 数据永远不会损坏： 任何软件、任何店、任何云，都做不到「绝对零风险」。野草不拿这种空话当卖点。 2. 那野草追求什么？ 野草换了一个更实在的目标： 就算坏人真的偷到了数据库，也尽量拼不回顾客的完整隐私。 这叫「先当坏人已经得手」来设计（手册里叫 Assume Breach，白话就是：别假装库永远偷不走）。 配套四句话： 非必要，不透露： 能少存就少存；不该看的人，就应该看不到！ 用过的信息，按规则模糊： 送完餐、结完单，详细地址等该脱敏就脱敏 任何一处单独被偷，都拼不全隐私： 库、备份、云、认证中心——单独拿一份，都不该等于「开箱即读全部顾客信息」 保护的是顾客隐私，不是保护数据库文件本身： 文件被偷了可以认；隐私被还原才是要极力避免的 3. 数据归谁？ 归开店的人（服务器 / 店铺拥有者），不归野草当「中央大平台」收着。 野草是工具；怎么装、怎么管、怎么备份、出了事谁担责——开店的人是运营责任主体。 野草开发者提供软件和规则说明；店铺正式营业之后的日常安全与合规，不能指望野草替店背锅。 这些话可能有点不近人情。 但现实就是这样。 真正需要承担经营责任的人，最终还是店铺老板自己。 野草只能尽力帮你降低风险，而无法替你承担风险。 二、第一阶段：数据安全打算怎么搭？ 重要：下面很多是规则和施工目标。截至现阶段，通道拆分（①②③ 分门）、隐私加密分存等，规则方向已基本定下，但是代码尚未全部落地！ 1. 三层「单线联络」——像「机房 + 店内柜台 + 网上柜台」 野草不用「全平台一个大库」，而是一家店一套结构，用三个角色分工（代号 ①②③）： ① 野草本体 机房 + 真账本 订单、菜品、顾客隐私等权威数据在这里；不是日常收银台 ② 本地联络员 店里 Wi-Fi 上的柜台 堂食扫码、员工干活、老板日常管店——走这里 ③ 通信转接节点： 互联网上的柜台（可选） 外面的人远程下单——走这里；可自己装，也可用公共节点（订阅服务），不碰货款 单线联络的意思是：公网消息不能直扑机房，必须按固定路线走： 外面客人 → ③ → ② → ①（机房） 店里客人 → ② → ① ③ 禁止直连 ①——就像不允许外卖客人从后门直接进仓库。 标准化配置 只有 ①： 不能对外营业 ① + ②： 标准主体：店里照常营业（堂食为主）；没有 ③ 也行 ① + ② + ③： 在上面基础上，再加网上远程下单（可选升级） 为什么要分开？ 把「日常营业入口」和「机房」分开，攻击面变小：就算网上柜台被打扰，也不等于坏人直接坐在账本上改数。 2. 权限：谁能看什么 买家： 自己的订单 店主 / 员工： 本店经营需要的；不需要顾客身份证等 骑手： 配送需要的地址、电话；不需要完整实名档案，订单完成后，顾客个人情报模糊化处理 联盟 / 认证中心： 只做信任与通信节点，不碰营业 修电脑做维护的服务商： 默认不能碰库；有必要碰数据库，须老板明确授权，计划是一次性或限时授权，用完即失效 登录也有分工：买家、店主走「生态登录」；员工走「店铺工作台」，两扇门不混用，减少串号、误权限。 3. 怎么提高攻击者的成本（第一阶段目标） 分门进出： 营业走 ② / ③，机房走另一条维护通道，不能和收银混一门 互相验身份： ② 和 ③ 之间要验「钥匙对不对」「程序是不是正版」（凭证 + 程序指纹；规则已定，代码逐步做） 访客 Wi-Fi 不上公网： 客人连 Wi-Fi 只为打开店里 ②，不占满带宽、也不给坏人多开一条路 桌码用店内局域网地址： 不依赖宽带公网 IP；本地营业不要求有公网 出事可先关公网 ③： 网上柜台有问题，店里 ② 仍可照常（不是「云挂了全店停」） 隐私加密、分开存： 手机、地址、姓名等加密，和一般业务数据分库 / 分存——正式上线前必须做到。 HTTPS、关调试、密钥不进代码： 对外加密访问；生产环境不暴露详细报错；密码钥匙用环境配置，不写在程序里 备份至少两份： 一份在本地；一份可上云，但必须是加密后的，云服务商默认读不懂 目标不是「没人来攻」，而是：攻了也得不偿失——偷来的东西拼不出完整隐私，或者代价远大于收益。 4. 备份怎么做（第一阶段） 至少两份。 本地自动备一份。 可再有一份加密后放云盘；云盘被偷也应读不出明文。 可选：自己用 U 盘再拷一份加密备份。 5. 第一阶段还没完全做到、但规则已写死的 ①②③ 物理分门、维护通道独立——目标态已定，程序仍在逐步改（过去可能是「一个入口包打天下」）。 合法授权解密流程全文——占位，待专门设计。 部分通道安全 细则——规则有，代码未全落地。 未完成隐私加密分存，不应该被用于对外营业。 三、最终阶段：数据安全打算长什么样？ 野草路线是 三阶段：单店 → 区域联盟 → 认证完善。安全构想随阶段加厚，但核心理念不变。 1. 第二阶段（区域联盟） 店铺数据仍以店铺为准： 区域服务器主要是副本、名录、自由骑手池、区域规则——不是把全区订单集中成一个大库让谁都能看 联盟默认「最小知情」： 例如：联盟服务器默认不知道用户详细地址；各模块只留履职必须的信息 认证中心开始部署： 先做一些基础能力（如唯一账号等），还不是最终完整形态 备份与脱敏深化： 与区域副本、授权流程等衔接，字段级脱敏规则更细 2. 第三阶段（认证完善） 认证中心： 不负责替你跑日常生意；侧重：实名与唯一身份、跨区信用互通、联盟之间传重要数据时的「通信信任节点」、规则包审计等 跨区传重要数据： 须过认证中心的许可，不是随便拷库 解密仍须授权： 认证中心批的是「能不能、批多少」，不是默认握有一把「万能解密钥匙」长期开着 规则治理： 规则修改走提案、公示、投诉等机制（与数据安全相关的元规则也有上限约束） 单一对象仍拼不全隐私： 店、联盟、认证中心、云、备份——任一块单独失窃，仍不应等于完整隐私 3. 最终形态的「理想画面」（白话） 店：机房在店（或店节点），数据主人是老板。 营业：只经柜台（② / ③），消息单线进机房。 隐私：加密分存；用完该模糊的模糊。 联盟 / 认证：各管各的，默认不看不该看的订单明细。 备份：多份、加密；云也只是存「看不懂的密文」。 授权：谁、何时、为何解密有流程、有记录；临时解密，用完就失效。 攻击者：偷到某一处，仍要跨越多道门才能还原隐私——成本高、收益低。 四、理念和构造的弱势点（须知情） 诚实说：野草不是银弹。下面是目前设计里固有的短板或依赖人的环节。 1. 理念层面的「不保证」 不承诺不泄露、不丢失、不损坏——只承诺尽量让泄露后的伤害变小。 若期待「绝对安全」，会与野草的设计前提不一致。 2. 依赖开店的人会不会做 图方便全体云部署： 例如整店只有「云上一台」（旧称纯云）：云挂了只能手工营业；危险系数高不推荐 不做加密分存就营业： 原则上禁止，但是开源项目，若有人硬上，隐私保护大打折扣 备份不做或只做一份： 硬盘坏了、误删了，照样丢数据 密钥管理马虎： 密码写在便签、发给不该给的人——这是人性的弱点，我也有这种不良习惯，但是网络安全意识，必须提高啊 乱授权服务商： 图方便，长期开放远程、不限时——这是信任与人性的问题，野草无能为力 3. 架构与实现上的弱项 规则领先于代码： ①②③ 分门、维护通道、规则的规划，我跑的飞快，但是代码实现和实际测试，双拳难比四手，我是业余开发者，请见谅！ 第一阶段 ①② 可同机： 省事，但物理上不如「机房和柜台两台机器」隔离得干净，野草的建议是，只要有条件，①②分机，安全性更高 ② / ③ 仍有缓存与会话： 原则上不存完整库，但前台会有临时数据；这是流转过程无法避免的问题 浏览器「记住密码」： 野草可不勾选自记，但无法 100% 禁止浏览器自己弹「保存密码」 4. 运营与人为环节 员工账号与权限： 店内有人恶意或疏忽，内鬼风险靠店主管人，人性是最无法把握的，切记 公网 ③ 仍是高暴露面： 有网络营业就有被扫、被试的风险；靠 HTTPS、限流、验钥匙等抬高成本，不是「没有攻击」，野草尽量做到，③被击破，也不会影响本地本体 断网与支付： ② 不能上网时，线上支付会受影响；规则允许现金等兜底，不是全自动 远程批准、第三方： 微信、云主机、公共转接节点等都在生态外；野草管的是怎么接，管不了对方出不出事 5. 阶段演进带来的复杂度 联盟、认证中心加入后，参与方变多——协调、授权、审计要求更高；设计目标是各怀其责、不集中成超级库，但实施难度更大。 跨区互通后，配置错误或授权滥用的影响面可能变大，更依赖流程与审计做对。 6. 和「大平台」比的心理预期 野草没有大厂那种 24 小时安全运营团队替每家店扛。 好处是数据在店、不抽佣、不中央囤数据；代价是安全 largely 是店主的责任与选择。 五、给不同对像的一句话 想开店的老板们： 数据是你的；按 ①②③ 分开装、隐私加密、双备份；正式营业前完成硬门槛。 身为顾客的亲们： 野草倾向少存、加密、分门；但不保证绝对不出事，店仍是责任主体。

本系统已经在GitHub开源。 地址是：https://github.com/jpevanchen-cmyk/yccaost