有次去上海旅游的时候走进一家咖啡店准备点杯喝的抬头看见墙上并排挂着两块手写黑板。左边写咖啡和蛋糕右边写冰茶、特调和花茶套餐粉笔字旁边还画了小花和杯子比一张规规矩矩的印刷菜单有意思多了。站在柜台前看了一会儿顺手把这块黑板拍了下来。后来翻相册的时候突然冒出一个念头能不能就从这张菜单出发在手机里开出一家店刚开始想的很简单把菜名和价格做成网页呗。可越想越觉得不够。电子菜单顶多让人看得方便顾客真要点一杯咖啡还得选冷热、选甜度放进购物袋点完之后后厨也得收到这张单告诉顾客什么时候能来取。光生成一个漂亮首页就宣布开业那不叫开店那叫发朋友圈。所以我起了个念头与其让它给我生成一个网页不如让它给我开一家店。先交个底。这家店叫「黑板旁」从菜单数据、顾客端页面到后厨看板开发交给 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 这版升级官方点名强化的方向里就有视觉理解正好拿来对账。把原始菜单照片发给它。这一节是接下来要真实跑的部分先把考题和判卷标准放在这里跑完按实际结果替换。盲读只看图效果对账盲读结果对项目数据代码任务有边界、可验证五、边界它现在做不到什么现在这家「黑板旁」是一套本地演示产品得把话说在前面。订单靠浏览器本地存储同步同一个浏览器开两个标签页能走完整流程换浏览器、换电脑订单不会跟过去。没有真实支付、账户、库存、配送没有公开的线上地址不能拿来给真实餐厅营业。但我一直觉得把演示说成演示读者反而更容易相信那些真的做出来的部分。要是为了显得像一家「大而全」的店把会员、优惠券、骑手地图全堆上去主角那张手写菜单很快就不见了。这个版本只验证一件事一张充满手作感的静态菜单能不能变成一条走得通的点餐与出餐路径。如果往后要朝能营业的方向走要补的课也摆在这里。订单得跨设备送到厨房菜单得有维护入口库存、营业时间、异常订单、隐私和支付都不能靠演示页面的办法凑合。把这些写出来不是泼冷水是说清楚这次到底验证了什么。六、复现本地怎么把它跑起来开源地址https://github.com/xtdexw/chalkside-cafe项目在本地跑。装好依赖启动开发服务顾客端在首页后厨端在/kitchen。同一浏览器开两个标签页一个当顾客一个当后厨就能把第三节那笔 64 元的订单亲手点一遍。如果你手边也有一张菜单照片不一定是咖啡店奶茶店、烘焙店、面馆的都行想照着开一家自己的数字小店提示词我给你备好了。三步**先读图再变数据最后开工。**前两步在豆包工作里选「豆包 Seed 2.1 Pro0915 新版」就能跑第三步换个挂着 Seed-2.1-pro-0915 的编程工具TRAE、Claude Code 都行照着发。提示词第一步让它读你的照片。只许看图不许猜。请只根据我上传的这张菜单照片识别内容不参考网络资料也不要补全你看不清的字。输出一个表格列为所在区域左黑板/右黑板/第几列、类别、菜名原文、价格元、识别把握高/中/低、不确定原因按照片上的顺序排列。套餐的人数和价格分别记录。最后单独列出你无法确认的行说明我应该放大照片的哪个区域做人工复核。这一步只做识别不要开始设计产品也不要声称你修改了任何文件。第二步把核对过的菜单变成能下单的数据。发之前你自己得先拿着第一步的表回原图对一遍确认无误再往下走这一步偷懒后面的错都是你的。菜单我已经人工核对过确认如下把你核对后的表格贴在这里。请把它变成一份可以直接放进代码的菜单数据每款商品包含id、菜名、英文或拼音名、价格、类别、一句 20 字左右的介绍以及三个规则字段是否仅冷饮coldOnly、是否无需温度选项noTemperature蛋糕和套餐通常如此、是否为照片之外新增newItem。品类用不上的字段就省掉。两条规矩。照片里有的按照片来价格一个字都不许改。照片没说的选项规则由你按常识补充但必须让我一眼分清哪些来自照片、哪些是你的补充。想加照片上没有的招牌款可以一律标 newItem不许混进原菜单。输出 TypeScript 数组字段名用我给的英文。第三步开发任务书。我的经验是任务书写得越像验收单返工越少。请用 React Vite 实现一个数字小店菜单数据用我上一轮给你的那份分顾客端和后厨端两个页面。顾客端菜单按类别浏览、可搜索、商品详情按数据里的规则字段选温度/甜度/数量/备注蛋糕不许出现冷热选项、购物袋可改数量、结算填取餐称呼。后厨端是三列看板待制作/制作中/待取餐小票要带顾客选的每一项。订单用浏览器的 localStorage 在同一浏览器的两个标签页之间同步状态只能待制作→制作中→待取餐单向推进。不接支付不建账户不放运行时 AI 接口。两条硬规矩。第一菜单上每一个菜名和价格必须来自我给的数据文件不许自创或改价newItem 商品要在页面上注明。第二先给我看菜单数据和页面结构我确认后再写完整代码。完成后告诉我怎么在本地跑起来再给一份验收清单至少包括一笔订单从提交走到取餐、顾客选项是否原样出现在后厨小票、总价能否手算对上、刷新页面订单还在不在、空购物袋和漏填称呼有没有提示、手机宽度下能不能正常点单。三步走完你拿到的不只是一个页面。照片里的每一行字都有了去处能被搜索能进购物袋能变成后厨的一张小票。哪一步模型没做好回到那张照片跟前跟它当面对质。七、写在最后回头看这两块黑板这个项目好玩的地方不在「照片变网页」这几个字网页本身不稀奇。稀奇的是照片里那些原本压在平面上的东西一个个有了去处。这次 0915 升级官方点名的几张牌在这个项目里也各自兑了一张。视觉理解兑成两块黑板拆出来的 29 行菜名和价格看不清的字保留疑问而不是猜一个交差。写代码的长程能力兑成从首页那张照片到购物袋再到后厨小票的整条链路。而我那条硬规矩兑成四款演示新增的咖啡老老实实标着「演示新增」一分可信度都没蹭黑板的。牌是官方的店是我的。粉笔写的菜名成了搜索结果。手写的价格进了购物袋。顾客一句「少甜」到了后厨的小票上。订单在厨房里往前挪顾客也知道自己的咖啡做到哪一步了。一张菜单不是一家店的全部但可以是开门的那一下。以上既然看到这里了如果觉得有点意思随手点个赞、在看、转发三连吧。