有次去上海旅游的时候，走进一家咖啡店，准备点杯喝的，抬头看见墙上并排挂着两块手写黑板。左边写咖啡和蛋糕，右边写冰茶、特调和花茶套餐，粉笔字旁边还画了小花和杯子，比一张规规矩矩的印刷菜单有意思多了。站在柜台前看了一会儿，顺手把这块黑板拍了下来。
后来翻相册的时候，突然冒出一个念头，能不能就从这张菜单出发，在手机里开出一家店？
刚开始想的很简单，把菜名和价格做成网页呗。可越想越觉得不够。电子菜单顶多让人看得方便，顾客真要点一杯咖啡，还得选冷热、选甜度，放进购物袋；点完之后，后厨也得收到这张单，告诉顾客什么时候能来取。光生成一个漂亮首页就宣布开业，那不叫开店，那叫发朋友圈。
所以我起了个念头，与其让它给我生成一个网页，不如让它给我开一家店。
先交个底。这家店叫「黑板旁」，从菜单数据、顾客端页面到后厨看板，开发交给 Seed-2.1-pro-0915，我全程只干三件事，出那张照片、立规矩、做验收。页面是 React 和 Vite 的本地项目，菜单是一份明确的数据文件，订单靠浏览器本地存储在两个标签页之间同步。没有运行时 AI 接口，没有支付、账户和配送。
这家店菜单上的每一个菜名、每一个价格，必须能回到那张黑板照片上找到出处。读者拿着原图，对着网页一项一项核对，核得上的，才算这家店的菜。
这条规矩把我和模型都框住了。我没法往菜单里塞黑板上没有的菜，它也没法。
卡布奇诺、澳白、摩卡、冷萃，这四款是为了让演示更完整补进去的经典款，页面上老老实实标着「演示新增」，不混进原菜单的身份。黑板上写 20 块的茶就是 20 块，不为了页面整齐改成更顺眼的数字。
下面按顺序来。先看成品，再看它是怎么被造出来的，然后拿一笔 64 元的订单把整条链路点一遍，最后把原图再交回给模型，在豆包工作里对一次账。它做不到什么，本地怎么跑起来，也都会交代。
一、先看成品，一家从照片里长出来的咖啡馆
打开首页，右边就是那张原始照片。网页没有把黑板上的粉笔字强行抠出来当背景，而是让照片留在原地，当这家店从哪里来的证据。左边的暖白、深绿和橙色，是顺着照片的颜色来的。
往下走是完整菜单，29 款商品分进咖啡、茶饮与特调、蛋糕甜点、花茶套餐四类。这里我最喜欢的是搜索。想在照片里找「芭乐」，得在黑板右侧从上往下扫，碰上手写字还得认一会儿；在数字菜单里，打两个字，「芭乐冰柠茶」的卡片就收拢到眼前了。搜不到也不会留一块空白，页面会直接告诉你没找到，再给一个清除搜索的动作。
这种变化没有炫技感，却是从「看照片」到「用产品」的实质差别。
点开一杯饮品，温度、甜度、数量和备注都能选。点开蛋糕，不会出现莫名其妙的冷热选项，本来只能做冰的饮品也不会冒出热饮按钮。我希望这些细节像店员真的听懂了你点什么，而不是每种商品套同一个模板。
另一边的后厨不是顾客页换个背景色。三列看板，分别放「待制作」「制作中」「待取餐」，店员要的信息摆在最前面，小票上是谁点的、几杯、冷热甜度、有没有蛋糕，一眼扫完。顾客可以慢慢逛，后厨必须一眼找到待做的单。两边用同一份数据，不该有同一种节奏。
手机也得当成主场。咖啡馆的顾客掏手机点单，才是我更愿意相信的使用姿势。标题、圆形印章和照片在桌面端可以并排，缩到手机宽度就得重新安排层级，不能让文字被图片遮住。菜单的分类、搜索、商品卡片和购物袋入口，在窄屏下保持可点、可读。后厨虽然更适合大屏，手机上同样能看小票、推进状态。
把这些页面连起来，它不是一张「菜单被 AI 变成网站」的静态对比图。你能从照片走进店铺，找到一杯饮品，提交订单，再看见后厨接手。前台做选择，后台接住选择，两边各有各的活。这是我想要的店铺完整度。
二、它是怎么来的，输入只有一张照片，任务不止识字
整个项目的输入，就是那张照片。
原图有两块黑板，菜名和价格分别写在不同位置。粉笔字有倾斜、有连笔，插画还贴着字走，价格沿着黑板边缘自己排成一列。人看菜单的时候会自动把一行字和旁边的数字配对，程序拿到的只是像素，哪个数字属于哪杯饮品，不能靠「大概挨得近」来决定。把「芭乐」看成别的水果，或者把「菠萝龙井冰茶」写错一个字，后面的商品卡片就全跟着错。
所以从照片到能下单的商品，至少要过三关。看清菜名与价格，确定每个商品归属哪块黑板哪个类别，再补上点单需要的规则，哪杯能选冷热，蛋糕该不该有甜度按钮。这些照片自己不会说。
我的做法是把图片信息和产品判断分开。照片能确认的，按照片。照片没说的，作为体验设计补上，但要标明。拿不准的，回原图和人一起核对。
最容易翻车的地方，恰恰是看起来最自动的地方
这个项目最诱人的做法，是做一个「随便上传一张菜单，立刻自动开店」的入口，传播效果肯定更好。我没做。
手写照片里看不准的东西，如果未经确认就变成可下单的商品，错误会从图片一路传到顾客的购物袋和后厨小票。外表越完整，错误反而越像真的。所以这个版本只服务于这一张确定的菜单，范围是小了，但每一行商品都经得起回原图核对，两端流程也做得完整。
技术上没有魔法。页面是 React 与 Vite 的本地项目，菜单是一份明确的数据文件，订单通过浏览器的 localStorage 在同一浏览器的两个标签页间同步。没有运行时 AI 接口，也没有真实支付、账户或配送。
Seed-2.1-pro真正花时间的，不是把黑板照片放上首页，而是把手写内容整理成能下单的商品，以及自主规划、长链路执行和动态修复能力，复杂任务处理能力。这个项目我设定了一个目标，剩余时间就去干其他事情去了，拿到成品的时候就是现在的最终版，效果还是非常不错！
前期录入时，右侧两杯茶的名字一度写错：「芭乐冰柠茶」写成了「杏乐冰柠茶」，「菠萝龙井冰茶」写成了「蓝莓龙井冰茶」。这两处是我对照照片后明确指出，再修正进菜单数据的；拿不准的手写字，没有继续靠猜。后来我还决定增加卡布奇诺、澳白、摩卡和冷萃四款常见咖啡，并让页面标明它们是演示新增，不冒充黑板上的原有菜品。
产品范围也是这样一步步定下来的。我没有做"上传任意菜单自动开店"，而是先把这一张菜单做扎实；不接真实支付和账户，重点完成顾客点餐端与后厨看板。开发助手把这些决定实现为商品页、购物袋、订单小票和状态流转，我再检查菜名、商品选项，以及一笔订单能否从顾客端走到后厨、再把状态带回顾客端。
注：Doubao-Seed-2.1-pro 全新升级至0915版本，Doubao-Seed-Evolving 同步更新到同一版本。
三、拿一笔 64 元的订单，把整条链路点一遍
光说「双端联动」，很容易变成四个大字。还是拿一笔订单实际走一遍。
先摆结果。选「顺顺栗栗拿铁」，冰、少甜，32 元；加一块「红茶栗子蛋糕」，32 元。购物袋两件商品，合计 64 元。结算页取餐称呼填「小桃」，提交。
顾客页出现「待制作」，同时打开的后厨标签页里，待制作列多了一张新票。后厨点「开始制作」，小票挪进「制作中」；再点「标记出餐」，它进「待取餐」，顾客页跟着更新。
几个我特意停下来核过的地方，值得单独说。
选项有没有跟到底。冰、少甜是下单前选的，不是结算页靠备注补救的，后厨小票上原样带着。总价能不能手算，32 加 32 等于 64，对得上。刷新顾客页，订单和状态还在，因为数据落在本地存储里，不是飘在页面状态里。
再就是那些不适合当封面的时刻。购物袋空了，按钮应该把人带回菜单，而不是放人进一张没有商品的结算页。搜索没有结果、漏填取餐称呼，页面都得给出下一步，提示落在输入框附近，不该提交了又像什么都没发生。一个产品的完整度，有时候就藏在它肯不肯承认自己没做成的那一步。
这些验收点放不进宣传图，但产品是不是真的能用，往往就卡在这里。
四、把原图再交回给模型，在豆包工作里对一次账
开发在 Coding 这侧完成，菜单数据也过了我一遍人肉核对。这就留了个问题，同一个模型，换到豆包工作的办公场景，只给它这张照片，不给项目里的答案，它能读成什么样，跟我核对过的数据能对上几成？
0915 这版升级，官方点名强化的方向里就有视觉理解，正好拿来对账。把原始菜单照片发给它。
这一节是接下来要真实跑的部分，先把考题和判卷标准放在这里，跑完按实际结果替换。
盲读，只看图效果
对账，盲读结果对项目数据
代码任务，有边界、可验证
五、边界，它现在做不到什么
现在这家「黑板旁」是一套本地演示产品，得把话说在前面。
订单靠浏览器本地存储同步，同一个浏览器开两个标签页，能走完整流程；换浏览器、换电脑，订单不会跟过去。没有真实支付、账户、库存、配送，没有公开的线上地址，不能拿来给真实餐厅营业。
但我一直觉得，把演示说成演示，读者反而更容易相信那些真的做出来的部分。要是为了显得像一家「大而全」的店，把会员、优惠券、骑手地图全堆上去，主角那张手写菜单很快就不见了。这个版本只验证一件事，一张充满手作感的静态菜单，能不能变成一条走得通的点餐与出餐路径。
如果往后要朝能营业的方向走，要补的课也摆在这里。订单得跨设备送到厨房，菜单得有维护入口，库存、营业时间、异常订单、隐私和支付，都不能靠演示页面的办法凑合。把这些写出来不是泼冷水，是说清楚这次到底验证了什么。
六、复现，本地怎么把它跑起来
项目在本地跑。装好依赖，启动开发服务，顾客端在首页，后厨端在 /kitchen。同一浏览器开两个标签页，一个当顾客一个当后厨，就能把第三节那笔 64 元的订单亲手点一遍。
如果你手边也有一张菜单照片，不一定是咖啡店，奶茶店、烘焙店、面馆的都行，想照着开一家自己的数字小店，提示词我给你备好了。三步，**先读图，再变数据，最后开工。**前两步在豆包工作里选「豆包 Seed 2.1 Pro（0915 新版）」就能跑，第三步换个挂着 Seed-2.1-pro-0915 的编程工具，TRAE、Claude Code 都行，照着发。
提示词
第一步，让它读你的照片。只许看图，不许猜。
请只根据我上传的这张菜单照片识别内容，不参考网络资料，也不要补全你看不清的字。
输出一个表格，列为，所在区域（左黑板/右黑板/第几列）、类别、菜名原文、价格（元）、识别把握（高/中/低）、不确定原因，按照片上的顺序排列。套餐的人数和价格分别记录。
最后单独列出你无法确认的行，说明我应该放大照片的哪个区域做人工复核。这一步只做识别，不要开始设计产品，也不要声称你修改了任何文件。
第二步，把核对过的菜单变成能下单的数据。发之前你自己得先拿着第一步的表回原图对一遍，确认无误再往下走，这一步偷懒，后面的错都是你的。
菜单我已经人工核对过，确认如下（把你核对后的表格贴在这里）。
请把它变成一份可以直接放进代码的菜单数据，每款商品包含，id、菜名、英文或拼音名、价格、类别、一句 20 字左右的介绍，以及三个规则字段，是否仅冷饮（coldOnly）、是否无需温度选项（noTemperature，蛋糕和套餐通常如此）、是否为照片之外新增（newItem）。品类用不上的字段就省掉。
两条规矩。照片里有的按照片来，价格一个字都不许改。照片没说的选项规则由你按常识补充，但必须让我一眼分清哪些来自照片、哪些是你的补充。想加照片上没有的招牌款可以，一律标 newItem，不许混进原菜单。
输出 TypeScript 数组，字段名用我给的英文。
第三步，开发任务书。我的经验是，任务书写得越像验收单，返工越少。
请用 React + Vite 实现一个数字小店，菜单数据用我上一轮给你的那份，分顾客端和后厨端两个页面。
顾客端，菜单按类别浏览、可搜索、商品详情按数据里的规则字段选温度/甜度/数量/备注（蛋糕不许出现冷热选项）、购物袋可改数量、结算填取餐称呼。后厨端是三列看板，待制作/制作中/待取餐，小票要带顾客选的每一项。
订单用浏览器的 localStorage 在同一浏览器的两个标签页之间同步，状态只能待制作→制作中→待取餐单向推进。不接支付，不建账户，不放运行时 AI 接口。
两条硬规矩。第一，菜单上每一个菜名和价格必须来自我给的数据文件，不许自创或改价，newItem 商品要在页面上注明。第二，先给我看菜单数据和页面结构，我确认后再写完整代码。
完成后告诉我怎么在本地跑起来，再给一份验收清单，至少包括，一笔订单从提交走到取餐、顾客选项是否原样出现在后厨小票、总价能否手算对上、刷新页面订单还在不在、空购物袋和漏填称呼有没有提示、手机宽度下能不能正常点单。
三步走完，你拿到的不只是一个页面。照片里的每一行字都有了去处，能被搜索，能进购物袋，能变成后厨的一张小票。哪一步模型没做好，回到那张照片跟前，跟它当面对质。
七、写在最后
回头看这两块黑板，这个项目好玩的地方不在「照片变网页」这几个字，网页本身不稀奇。稀奇的是照片里那些原本压在平面上的东西，一个个有了去处。
这次 0915 升级官方点名的几张牌，在这个项目里也各自兑了一张。视觉理解，兑成两块黑板拆出来的 29 行菜名和价格，看不清的字保留疑问，而不是猜一个交差。写代码的长程能力，兑成从首页那张照片，到购物袋，再到后厨小票的整条链路。而我那条硬规矩，兑成四款演示新增的咖啡老老实实标着「演示新增」，一分可信度都没蹭黑板的。
牌是官方的，店是我的。
粉笔写的菜名，成了搜索结果。手写的价格，进了购物袋。顾客一句「少甜」，到了后厨的小票上。订单在厨房里往前挪，顾客也知道自己的咖啡做到哪一步了。
一张菜单不是一家店的全部，但可以是开门的那一下。
以上，既然看到这里了，如果觉得有点意思，随手点个赞、在看、转发三连吧。