# 把午餐选择交给 Agent：点一张食物图片，子 Agent 去外卖平台下单，60–90 分钟后开饭

自建 Agent · Bluesky · 未披露收入；原帖未给出任何收入、节省金额或开发成本

## 业务摘要

Bluesky 用户 Colin（colin-fraser.net）让自己的 AI agent 写了个叫 Lunch 的小应用：首页放几张他可能会想吃的食物照片，点一张就派生一个子 agent，去 Uber Eats 把这一项下单，60–90 分钟后饭送到手上。原帖只有四个短句，没有搭建步骤、没有成本、也没说明外卖账号怎么接，给出的数字只有「60–90 分钟」和「约 60 万行 JavaScript」。真正值得抄的不是一个点餐 App，而是把「今天吃什么」这个每天都要做一次的决定压成一次点击，同时给下单动作留出人工确认和金额上限。原帖未披露任何收入、节省金额或开发成本。

## 业务价值

价值不在省下多少钱，而在每天少做一次低质量决策。它把「选什么」和「下单」拆成两段：前者交给人看一眼，后者交给子 agent 执行。风险也正好集中在后者——真实下单会花真钱，所以必须留人工确认与金额上限，不能让点击直接等于付款。
每天中午都在外卖 App 里刷十分钟、最后还是点昨天那家的人；想先验证「子 agent 能不能在真实网站上下单」的动手派；以及任何愿意把重复小额消费动作交出去、但坚持付款前停一次的人。
一个只有几张图的候选页；每次点击派生的一次子 agent 下单任务；下单前一条含店铺、菜品、金额、送达地址、预计时间的待确认摘要；以及一份可回看的本轮下单记录（时间、金额、结果、失败原因）。

## 执行链路

先把「决定」和「下单」拆成两段
不要一上来就做自动下单。先把任务定义成两步：选出今天吃什么（人做一次点击），把这一单送出去（agent 做）。原帖的结构正是如此：点图是人的动作，派生子 agent 去 Uber Eats 下单是 agent 的动作。

候选集先写死，只放几张图
像原帖那样只保留几样你真的会吃的东西，图片与菜名一一对应，并写明规格（分量、辣度、不要什么）。候选集不固定，agent 就会每天给你换一批，选择困难只会更严重。

点图才派生子 agent，一次只派一个
一次点击只触发一个子 agent、只下一单，绝不做批量或定时自动下单。原帖描述的就是这种「点一次、派一个」的粒度，这也是把出错影响面控制在一顿饭之内的关键。

子 agent 只带最小信息去下单
交给子 agent 的只有：菜品名、规格、收货地址、金额上限。不要给它完整账号权限、不要让它自选店铺、不要让它顺手加购。信息给得越少，它跑偏的空间越小。

下单前停一次，人工确认
子 agent 找到对应商品后必须先输出一条待确认信息：店铺名、菜品与规格、实付金额、送达地址、预计时间。人点确认才允许提交订单。原帖没有讲这一层，但涉及真实付款就必须补上。

把每一单记成一条记录
确认下单后写一条记录：点击时间、下单时间、店铺、金额、预计与实际送达时间、结果。原帖只给了「60–90 分钟后吃上」这个体感区间，自己跑的时候要把它换成可核对的时间戳。

失败就退回手动，不要自动重试
店铺打烊、菜品售罄、地址不可用、超出金额上限，一律停下来把原因写清楚并交回人工，不做自动改单、不自动换店、不自动重试。一次重试就是一次可能的重复扣款。

## 准备条件与限制

一个能派生子 agent 或调用外部动作的通用助手／自建 agent
外卖平台账号与可用支付方式，且你能接受把下单动作交给它
固定的收货地址与明确的单笔金额上限，先写死再开跑
头几次愿意在旁边盯着整个下单过程，逐项核对金额
接受失败：真实网站会改版、会售罄、会打烊，需要人工兜底

## 可复制 Prompt

````text
你是一个点餐执行助手。目标是减少我每天中午做决定的时间。你可以选品和填单，但没有我的确认不能付款。

【输入】
候选清单（固定，最多 6 项）：[项名 | 规格 | 参考店铺或平台内关键词]
收货地址：[地址]
单笔金额上限：[数字，含配送费与小费]
平台：[外卖平台名称]
我本人负责：口味判断、最终付款确认

【执行步骤】
1) 把我点选的那一项和候选清单对齐，输出你要买的东西：项名、规格、平台内关键词。不要自己换项。
2) 在平台上检索该商品，只保留规格一致、评分与配送时间在可接受范围内的结果；找不到完全一致的结果就停下，不要挑最接近的替代。
3) 向我输出一条待确认信息：店铺名、菜品与规格、商品单价、配送费、实付合计、送达地址、预计送达时间。
4) 我回复确认后，才提交订单。提交后立刻回传订单号与预计送达时间。
5) 无论成功或失败，都写一条记录：点击时间、下单时间、店铺、实付金额、结果、失败原因。

【输出要求】
- 待确认信息：单行结构，字段为 店铺 / 菜品与规格 / 单价 / 配送费 / 合计 / 地址 / 预计送达。
- 下单结果：订单号、实付金额、预计送达时间。
- 失败说明：属于哪一种（售罄 / 打烊 / 地址不可用 / 超出上限 / 规格不一致），以及你停在哪一步。
- 记录：一条可追加的流水行。

【人工确认点】
- 没有我明确回复确认，不得提交订单、不得付款、不得加购、不得改地址、不得改支付方式。
- 合计超过我给的金额上限时，直接停下并说明超出多少，不得自行换便宜的替代。
- 一次点击只处理一单，不得批量下单、不得定时自动下单。

【失败与缺资料处理】
- 候选清单缺规格或收货地址为空时，不要猜，先问我。
- 平台检索不到、登录态失效、页面改版导致取不到价格，一律按失败报告，不得估算价格。
- 任何一步失败都不自动重试、不自动改单，不追加轮次，交回我处理。

【合成示例（非真实业务数据，仅演示格式；金额均为不带币种的合成数字）】
输入：候选第 2 项「番茄牛腩饭 | 大份、不要香菜」；地址「示例路 1 号 A 座」；上限 40
输出（待确认）：示例快餐（示例店） / 番茄牛腩饭·大份·不要香菜 / 28 / 5 / 33 / 示例路 1 号 A 座 / 预计 18:40
我确认后输出：订单号 A1B2C3，实付 33，预计送达 18:40，记录已写。
````

## 成本与避坑

原帖未披露 token、费用或用量，采集站亦未给出。这类任务的成本主要来自浏览器操作步骤数与页面长度；本站不给未经核实的数字，建议先用一顿饭的单子估一次量。

原帖给出的体感是从点击到吃上 60–90 分钟，其中大部分是商家出餐与配送，不是 agent 运行时间。真实下单受店铺营业时间、配送范围与平台登录态限制，夜间与高峰时段更容易失败。

最大的坑是把「点一下」直接接成「付一次款」：真实下单会花真钱，少了确认与上限就可能重复扣款或下错规格。第二个坑是候选集不固定，等于把选择困难原样搬进应用里。第三个坑是代码规模——原帖自嘲应用约 60 万行 JavaScript，说明这种看似简单的自动化搭起来并不轻。

## 来源与备注

Colin（Bluesky 用户 colin-fraser.net，原帖作者本人；原帖显示名为 Colin） (colin-fraser.net)
https://bsky.app/profile/colin-fraser.net/post/3mysgiwoy6k2f
2026-10-26
成果数据来自原帖主；AgentFlow 提供分析与参考流程，未独立核验收入，不保证复刻效果。