一家跑在自己软件上的餐厅

Alsafi 是海德堡 Hertzstraße 上一家家族经营的伊拉克-黎凡特餐厅。在此之前，点单意味着走聚合平台：每一盘菜抽一笔佣金，客户关系归别人所有，厨房读的是一套没人在这里选过的系统打出来的单子。

现在他们跑在自己的系统上。

「整套」究竟指什么

一套代码承载着四件不同的工作，而每一件工作的另一头都是不同的人。

• 还在决定要不要来的客人。菜单、午市、店家的故事、营业时间和评价，手机优先——因为人们就是这样判断一家餐厅值不值得走一趟。
• 正在点单的客人。带配料选项与加购的漏斗、结账、Stripe 支付、小费，以及带真实预估的实时订单追踪。这是钱走的那条路，它是为消除不安而造的，不是为了把购物车做大。
• 有账号的客人。频次低、要求高：进去、拿到想要的、出来。
• 在跑服务的人。六十六块员工屏幕、一块在时间压力下要隔着距离读的厨房屏，以及前厅真正会用到的打印面。

它从浏览器安装到手机、平板、Mac、Windows 电脑或 Linux 桌面上。一套代码，没有应用商店，也没有几份要彼此对齐的构建。

菜单是一个数据库，不是一份 PDF

一百零三道菜分布在十五个类别里，各有自己的变体和价格，以及对应客人真正会做的选择的选项组——分量、配菜、熟度。这些都由厨房自己改。没有人去重画一份文档。

每道菜下面，是德国法律在意的那部分。十四种欧盟规定的过敏原和十六项添加剂声明是按菜、而不是按菜单记录的，并对着厨房实际照做的那张矩阵核对，而不是一份没人记得更新的 PDF。客人可以排除某一种过敏原，或者把整份菜单收窄到纯素、素食或清真——而且是在下单之前，不是之后。

午市走自己的轮换，有自己的菜、自己的一周。卖完的菜一下点击就从菜单撤下，一有货就回来——客人看得到，收银看得到，谁也不必记着去通知另一边。

点单、付款，以及知道订单到哪儿了

配送是按区域画的，不是按半径，因为一条街要么是菜能热着送到的地方，要么不是。自取是第一选项，不是退路。回头客保留自己的地址；第一次来的客人不会被逼着为了吃饭去开账号，事后如果想要历史记录，也可以把订单归到一个账号下。

支付走 Stripe，小费作为独立的一行处理，而不是并进总额。订单一旦提交，客人就得到一个带真实预估的实时状态，并且——在他允许的前提下——厨房推进状态时会收到一条推送，好让没有人坐在那里刷新页面，猜晚饭究竟来不来。

退款是必须一次做对的那部分。退款记录行在调用 Stripe 之前就写下，并以它自己的 id 作为幂等键，因此重试、双击或断线都不可能把同一笔订单退两次。订单的已退总额是由这些记录行推导出来的，不是在哪里手工填的。

这个厅，本来的样子

平面图在系统里：两处场所、二十一个区域、三百五十三张桌子。订位落在真实的桌子上，而不是一个抽象的容量数字——这就是一套订位系统和一张表单更好看的电子表格之间的差别。

前厅，以及在前厅的人

终端是与系统配对的，而不是因为接进了网络就被信任——收银机、服务员手机、厨房屏各自持有一个设备令牌，而配对码和令牌都以哈希形式存储，任何客户端都读不回去。员工用 PIN 登录，经 bcrypt 哈希，多次失败后锁定——因为忙市里的收银机，是整栋楼里最不私密的一块键盘。

角色是真的。业主的账号和前厅的账号不是同一扇门，而厨房屏显示的单子，尺寸是为了隔着一条热线读，而不是把一块仪表盘缩小塞进去。

工时，按法律要求的方式留存

排班把经理的草稿和团队实际被告知的内容分开：一个班次要么已发布，要么没有。与之并列的是 Arbeitszeitgesetz 要求的工作时间记录：开始、结束、时长与休息，保存两年。

有意思的是更正。改一个时间不会覆盖它——原始记录留在新记录旁边，带着作者和理由。一份可以被悄悄改写的记录不是记录，而稽查员是知道这一点的。

多数代理商悄悄跳过的那部分

德国不允许一家餐厅只是把钱收下。每一笔交易都必须由经认证的技术安全设备签名，而税务机关可以要求一份覆盖十年经营的 DSFinV-K 导出件。

这些是内建的。平台与一家通过 BSI 认证的 TSE 供应商对话，按现行规范而不是凭记忆拼装税务 schema，并按需导出完整的 DSFinV-K 包——附带一条审计轨迹：谁在什么时候导出了哪一段期间，以及交给他的那份东西的哈希。

税务图景的其余部分之所以在那儿，是因为税务稽查员会要。每一天以一个 Kassenabschluss 收尾，也就是系统里每一笔交易所归属的 Z 号。不是销售的现金变动——备用金、存入、提取、在途、盘点差异、小费、押金、代金券——都被记为各自的事件类型，而不是被塞进营业额里。而当 TSE 自己宕了，这次中断会连同时间和原因一起被记录，并在那段时间开出的每一张凭证上标注出来——这正是 AEAO 所要求的，也正是没有人记得去做的。

一笔签过名的销售，十年之内删不掉；因此产出它的代码是写给稽查员读的，而不只是为了通过一个测试。

我们在埃及为埃及税务局的电子发票做同样的工作，在沙特为 ZATCA 做同样的工作。国家不同；那份纪律相同。

聊聊一个合规攸关的项目

一笔订单身上发生的任何事，都带着一个名字

每一笔订单都带着一份只可追加的事件日志，而这些事件不是由碰巧握着连接的那一方写的。每一条都记下谁动的手、以什么角色、从哪个界面、以及为什么——厨房屏上的一次状态变更、办公室里的一次修改、一笔附了理由的退款。

订单表本身对后台界面是只读的。所有写入都经由服务端函数，因为只有这些调用方能够确立是谁在动手。直接写表会被记为「系统做的」，而「系统做的」不是任何人愿意拿去回答税务稽查员的答案。

餐厅自己的营销，握在餐厅自己手里

网站内容——首屏、故事板块、图库、活动——在与其他一切相同的后台里编辑，然后作为一个任务发布，而不是实时改动，好让一句写到一半的话永远不会离客人只有一次刷新。

围绕它的，是一家餐厅原本得去租的一切：博客、带申请功能的招聘、客人反馈、支持工单，以及给印刷品和二维码用的可追踪短链接，好把一张传单和一张桌卡区分开。Google 的评价同步进税务导出所在的同一个后台。每周的通讯是从那一周真实的午市特餐里拼出来的，而不是从零写起，配有双重确认、一键退订和发送日志。

想找个人说话的客人能找到：带输入提示和语音留言的实时聊天，作为一段对话保存，而不是一张工单。

不出卖客人的数据分析

餐厅可以看到今天是什么样子——营业额、订单数、客单价、哪道菜最受关注、按自己的时区哪些时段忙、访问从哪里来、以及一次访问在哪里变成了什么。

这些都不是从第三方买来的，也没有一样在跟踪任何人。独立访客是用短寿命的加盐哈希统计的，两天后清除；国家来自边缘节点，而不是某个追踪器。没有任何字体、图标或脚本是从别人的服务器上取的。这首先是一个 GDPR 与内容安全的决定，其次才是一个性能决定；它意味着一位正在读菜单的客人，不会被悄悄介绍给一家广告网络。

这块面板还小心地画出了自己的边界：它为排产而统计订单，并且明说这一点——因为在法律上有约束力的那个数字住在 Z 报表里，不在这里。

三语，而且阿拉伯语做得规规矩矩

德语为准。英语和阿拉伯语覆盖每一段文字，无一例外，而且阿拉伯语是彻底的从右到左：镜像布局、逻辑属性、自己的字体栈。不是最后外挂上去的一层翻译——这正是「一个阿拉伯语使用者能用的网站」与「只能读的网站」之间的分界。

任何东西在浅色与深色下、在从左到右与从右到左下、在从 375 像素的手机到一台桌面机之间都站得住之前，都不算完成。

为了被检验而建

四百六十六个测试文件。无障碍性用自动化检查而不是肉眼来验证。WCAG AA 是约束而不是愿景，全站有 44 像素的触控目标，并处处尊重「减少动效」。

不拥有这一切的代价

聚合平台可以抄一份菜单。它抄不走一个家庭的待客之道，也不会把客户关系还回来。这个项目里的每一个决定，都对着同一个问题掂量过：一个交易平台会这么做吗？凡是答案为「会」的地方，我们做了别的。