给他的prompt如下(展示版有些许改动)
一、功能流程全览
从用户「上传小票」，到「分账管理」，再到「团队协作」的端到端流程概览如下：
- 用户进入「团队工作区」或「个人工作区」
• 在 URL 上，若是个人工作区：/home/(user)/…；若是团队：/home/[account]/…
• 后端可在 Server Component 里获取当前 account（个人/团队 ID）；这会作为后续所有数据库操作的基础。
- 用户选择要「上传小票」
• 在前端 UI 上，点击“上传小票”按钮，弹出文件选择器。
• 通过 Tesseract.js 解析图片为纯文本，并使用进度条显示 OCR 进度（Tesseract.js 支持 progress 事件）。
• 解析完成后，可能得到一段文本，例如：
Sample Store
Receipt ID: XXX
Breakfast Cereal 640g, $8.00
Bakery Baguette 2 pack, $1.90
Sample Snack 150g, $2.85
...
Total $ ...
- 通过后端 API / LLM 进行「结构化解析」
• 将上述文本字符串通过前端发送给后端，或直接使用某 LLM 服务进行处理（具体实现视需求而定）。
• 让模型根据提示词输出 JSON，示例结果：
{
"store_name": "Sample Store",
"receipt_id": "XXX",
"items": [
{ "name": "Breakfast Cereal 640g", "price": 8.00, "qty": 1 },
{ "name": "Bakery Baguette 2 pack", "price": 1.90, "qty": 1 },
{ "name": "Sample Snack 150g", "price": 2.85, "qty": 1 }
]
}
• 因为文字识别可能有误，用户可以在后续步骤中对 store_name、items 等字段进行手动修正。
- 生成并保存「母账单」到数据库
• 解析结果经用户确认后，调用一个后端的 createReceiptAction（或类似命名）将数据写入数据库：
• receipts 表：存储 store_name, receipt_id, account_id，以及默认 locked = false.
• receipt_items 表：逐条插入每一行 item 数据。
• 分账（receipt_splits）可先留空，或若模型已预测出“谁付多少”，也可提前插入。
- 展示「分账管理」表格
• 在页面刷新或跳转到 “/home/[account]/receipts” 路由时：
-
Server Component 使用 getSupabaseServerClient() 查询 receipts / receipt_items / receipt_splits（只查 account_id = …），并将结果传给一个 Client 组件。
-
Client 组件（如 ReceiptsBlock）渲染多个母账单（或卡片）+ 子项目列表 + 分账列。
-
用户可在「添加分账人」处输入姓名或团队成员，前端在 state 中增加一列，同时在数据库 receipt_splits 表中插入对应记录（默认分摊金额为0），后续可手动填写金额。
-
编辑/分摊
• 在未锁定（locked = false）状态下：
• 用户可编辑子项目的「单价」「数量」，或分账列的「分摊金额」。
• 每一次编辑可通过以下两种方式提交：
• 立即提交：在 onBlur 时触发某个 Server Action。
• 批量提交：先存至前端 state，最后一次性点击「保存更改」提交。
• 如使用 React Hook Form + Zod，可对每行进行基础校验（如非负值、不可超过总价等）。
- 选择「谁实际支付」
• 母账单级别可有一个 paid_by 字段。
• 若只有一个人支付全部，则在 UI 上选择该人，前端可自动把子项目的分摊金额分配给该人，其它人分摊为 0。
• 也可允许手动覆盖分摊金额。
- 锁定
• 当账单无误后，点击「锁定」，将 receipts.locked 设为 true。
• 前端 UI 若检测到 locked = true，则禁用相应的输入组件；若要修改，需要先点击「解锁」。
- 删除
• 「删除该账单」：调用 deleteReceiptAction({ receiptId })，后端依次删除 receipt_splits → receipt_items → receipts；行级安全策略（RLS）会保证只有该团队成员能删除。
• 「删除子项目」：调用 deleteReceiptItemAction，并删除与之关联的 receipt_splits。
二、细节：数据库结构与 RLS
假设使用 Supabase/PG 作为数据库，需要在公共模式下（public）创建三张表并配合行级安全（RLS）策略。字段与示例策略如下：
- public.receipts
• 主要字段：
• id (UUID)
• account_id (FK → public.accounts.id)
• store_name (TEXT)
• receipt_number (TEXT, 可选)
• paid_by (TEXT 或指向团队成员的 FK)
• locked (BOOLEAN)
• created_at, updated_at (TIMESTAMP)
• RLS 策略（示例伪代码） ：
CREATE POLICY select_receipts ON public.receipts
FOR SELECT
TO authenticated
USING (account_id = current_setting('app.current_account_id')::uuid);
CREATE POLICY insert_receipts ON public.receipts
FOR INSERT
TO authenticated
WITH CHECK (account_id = current_setting('app.current_account_id')::uuid);
其余 UPDATE/DELETE 同理，确保只有当前团队可操作。
- public.receipt_items
• 主要字段：
• id (UUID)
• receipt_id (FK → public.receipts.id)
• item_name (TEXT)
• unit_price (DECIMAL)
• quantity (DECIMAL)
• created_at, updated_at (TIMESTAMP)
• RLS：
同理，需要先 JOIN 到 receipts.account_id；若 account_id 等于当前用户所在团队，则可操作。
- public.receipt_splits
• 主要字段：
• id (UUID)
• receipt_id (FK → public.receipts.id)
• item_id (FK → public.receipt_items.id, 可选)
• split_person (TEXT 或团队成员 ID)
• split_amount (DECIMAL)
• created_at, updated_at (TIMESTAMP)
• RLS：
同理，通过关联的 receipt_id → public.receipts.account_id 实现行级安全。
过程如下
结果
评价
这个看起来很有野心的项目 像是devin和cursor的结合体 他在阅读代码和找bug方面堪称牛逼 cursor介于他的代码搜索功能 读取代码都不完整 每次debug都很要命 这个就不会可以把这个理解成 cursor 大力出奇迹版本 用api 毫不心疼(毕竟是我付钱。。。)
这个功能花费6美金 用时15分钟左右 除了ocr部分其他基本都实现了
总的来说还可以 有钱的话很好 毕竟他在阅读代码 思考方案 实现方案都比cursor好(更像是一句话解决那种类似devin)
别看这个功能不难 要在一座代码屎山上雕花不是一件简单的事情