Project retrospective / 2026.03 - Present
oppachikin.
我为明斯克一家本地炸鸡店做的不只是官网，而是一套把顾客下单、店员操作、配送决策和内部排班逐步交给系统与 agent 的运营改造。
交付周期
5 周 从 0 到生产级电商系统系统范围
外部 + 内部 顾客下单与门店运营一起设计安全审计
1 周 上线前集中补齐风险控制价格采样
30 次 14 小时内用真实数据校准配送系数从“能接单”到“能运营”
这个项目的价值不在于多做了几个页面，而在于把一家门店每天反复发生的人工流程拆开、排序、再交给系统。
Before
- 顾客发消息或打电话
- 店员手动确认菜单和地址
- 人工打开 Yandex Go 叫车
- 凭经验估运费和时间
- 再把状态同步回顾客
After
- 顾客在官网自助下单
- Alfa Bank 完成支付
- Telegram 推送给店员
- CheckPrice 校准配送成本
- 异常交给人工兜底
项目不是线性开发，而是一轮轮靠近真实运营
每一次推进都来自一个具体问题：顾客怎么买、老板怎么看、钱如何安全、配送如何不亏、员工如何协作。
手动流程
顾客和店员依赖电话、Telegram、人工叫车，流程能跑，但信息分散。
官网点餐
搭建菜单、购物车、结账、订单状态，把获客入口收回到自有网站。
支付与会员
接入 Alfa Bank、SMS.by、Supabase，用手机号和积分沉淀回头客。
安全审计
补齐支付幂等、金额重算、Webhook 验签、验证码限流等线上风险。
配送定价
用 Vercel Cron + Yandex CheckPrice 采样，发现隐藏高峰和价格剧烈波动。
内部系统
开始设计员工排班机器人，把门店内部流程也纳入 agent 化改造。
外部是顾客体验，内部是门店协作
排班机器人不是另一个独立项目，而是同一家店的内部运营系统。它和点餐网站一起构成 Oppa Chicken 的完整流程改造。
顾客端
菜单、购物车、地址、支付、订单状态，让顾客不再靠聊天窗口完成下单。
上线前最重要的一周：安全审计
我最骄傲的不是“功能能跑”，而是专门花一周把它改到经得起真实线上使用。
支付回调重复
同一笔成功回调可能被银行重试多次。
用订单状态做幂等判断，重复回调返回成功但不再触发副作用。
金额篡改
早期版本曾把前端金额传到后端。
付款前在服务端根据商品 ID 重新计算总价，前端价格只用于展示。
Webhook 伪造
知道 URL 的人可能伪造 Telegram 消息。
校验 Telegram secret token，不匹配直接拒绝。
验证码刷量
SMS 验证码是真成本，登录接口也可能被爆破。
用 Upstash Redis 按 IP + 手机号双维度限流。
拍脑袋的系数表，输给了真实数据
合伙人的经验方向有价值，但具体数值会带来 30%-100% 的误差。我的判断是：配送费不能靠感觉定，必须先采样。
采样方法
Vercel Cron 每 30 分钟调用一次 Yandex CheckPrice
结果写入 Supabase 的 delivery_price_samples 表。14 小时、30 次采样后，足够看出经验表里看不到的波动。
反直觉发现
22 时 surge 3.0x 这是合伙人完全没预料到的隐藏高峰。派单策略
派单前必须再 CheckPrice Express 价格曾在 30 分钟内从 34 BYN 跌到 11 BYN。学到的
便宜的数据工具链，能保护真实利润 Cron + Supabase + Python 分析，比凭感觉定价可靠得多。SMS 集成教会我的，不是技术而是合规节奏
SMS.by 的 alphaname 审批等了 5 个工作日。它提醒我：真实项目里，阻塞上线的经常不是代码，而是外部流程。
AI 没有替我思考，但它放大了我的判断
这个项目最像我简历里那句话：把流程交给 agent。前提是，我先把业务规则、风险边界和取舍想清楚。
我负责
- 理解真实门店的操作习惯
- 判断哪些风险上线前必须补
- 把“经验”转成可验证的数据假设
- 决定哪里自动化，哪里保留人工兜底
Agent 负责
- 拆解 API 对接路径
- 生成和重构 TypeScript 代码
- 辅助定位支付、Webhook、Cron 问题
- 把安全 checklist 落到具体实现
Reflection
这不是一个“我会写网站”的证明。
它更像一个证据：我能和真实客户一起，把一个模糊、琐碎、充满例外的业务流程，拆成能运行、能审计、能继续迭代的系统。
聊聊流程自动化