伊尔萨洗衣 BUILD LOG

OPENCODE × YIERSA / BUILD LOG 2026

SHIPPED · 2026-10-22

说出来的
系统

45 场对话，如何把一家连锁洗衣店
重做一遍。

不是“AI 帮我写了代码”，
而是“我负责判断，AI 负责施工，系统负责验收”。

从第一句话开始

45 场含 18 场子代理；197 次提交含代码、文档与部署记录；30 条为 CHANGELOG 中标记“已部署”的版本记录。

01

THE START

不是从零开始，
是从一堆旧代码开始。

2026 年 9 月 5 日，第一句话不是“帮我写个系统”，而是：

“这个项目之前是 codex 开发的，当前正在进行的是一个周报日报的微信功能，你遍历项目文档，确保可以接续开发。”

先读，不先写。45 场会话里，27 场是主会话，18 场是子代理（多为只读侦察）。它们先把 .NET 老系统、报表链路、门店流程、支付通道读了一遍，然后才动第一行代码。

所以这不是一个“从零生成”的故事，而是一个“把老系统重新做一遍”的故事：从 Windows/IIS 到 Linux/.NET 10，从管理后台为中心到店员 Pad 优先，从人工作业到 AI 收衣。

AI 可以写得很快，但“能不能上线”是另一回事。
这个页面记录的，是后面那件事。

之前
  • Windows Server + IIS
  • 管理后台为中心
  • 多件衣物要重拍
  • 条码靠特写补拍
  • 报表靠微信推送
之后
  • Linux + .NET 10
  • 店员 Pad / 手机优先
  • 一图多件，点选剔除
  • 主图自动回填 9 位码
  • 报表自动生成 + 邮件
02

THE LOOP

五步施工法

不是“给个需求，等它写完”。是把 AI 放进一条有闸门、有证据、有回滚的流水线。

  1. 01

    先读

    读文档、读代码、读生产日志。只读侦察先行，禁止边猜边改。

    45 场会话 / 18 场子代理
  2. 02

    方案卡

    ① 文档核对 ② 框架对照 ③ 候选方案 ④ 可行性验证 ⑤ 结论。你确认，才动第一行代码。

    每案一张，证据可指认
  3. 03

    小步做

    一次只改一个可验证的变量。版本号、CHANGELOG、commit 一起走。

    0.2.0 → 0.4.3，一天七个关键版本
  4. 04

    真机验

    构建通过不算完。真机、截图、灰度、对账，至少过一遍。

    3 次刷脸 94.5+；条码 090→705050090
  5. 05

    带回滚上线

    备份、哈希、tag、回滚命令，缺一不发。发布后公网终验。

    30 条上线记录，关键批次留锚

每一步都有证据；没有证据的“应该可以”，不算完成。

说明：本页的“决策轨迹”不是原始思维链的逐字复述，而是从会话记录还原的判断链；每个分支都对应一次真实的文档核对、工具输出或线上验证。

老板的原话
开始给每次更新编写版本号，
新需求：
1、现状当识别多件衣物的时候，要求重新扫，但当订单过多的时候，店员是习惯先一堆一起拍，后续补足信息或干脆不补。我的想法是识别多件衣物的时候，就自动创建多件，ui 上可以通过拆开多个小图，默认全选，然后允许店员点选去掉。比如识别出 5 个衣物，就是 5 个上传图片上的高亮圈，或取出 5 个图，店员操作选择取消一个后，变成 4 个，然后一件确认，就是 4 个衣物。然后在下一步，支持每件补充细节图。
展开完整原文

开始给每次更新编写版本号，
新需求：
1、现状当识别多件衣物的时候，要求重新扫，但当订单过多的时候，店员是习惯先一堆一起拍，后续补足信息或干脆不补。我的想法是识别多件衣物的时候，就自动创建多件，ui 上可以通过拆开多个小图，默认全选，然后允许店员点选去掉。比如识别出 5 个衣物，就是 5 个上传图片上的高亮圈，或取出 5 个图，店员操作选择取消一个后，变成 4 个，然后一件确认，就是 4 个衣物。然后在下一步，支持每件补充细节图
2、调研一下，支付同时支持店员扫用户的支付码如何实现？扫支付宝和微信是一个按钮唤起最好。
3、先给我可行性方案及必要的交互 demo

这条需求本身就是完整的产品设计：自动建多件、默认全选、点选剔除、逐件补细节图。剩下的工作，是把它变成店员手指能操作的东西。

从 0.2.0 到 0.4.3，一个交互改了七次关键版本。最关键的两次纠偏，都不是“加功能”，而是“减冲突”。

VERSION改了什么为什么
0.2.0

一图多件自动建清单；主图高亮圈 + 裁剪小图；默认全选

店员习惯先一堆一起拍
0.2.1

缩略图即时显示；手动补选连续圈选；编辑改浮窗

第一次真机，发现首卡和遮挡
0.2.2

框选裁剪图作为订单项主图

订单详情不能显示全图
0.3.0

取消“单独拍一件”；品类可修改

“再拍一批”覆盖单件场景
0.3.1

品类改为下拉选择

自由输入会乱
0.3.3

补选只认拖画出框；单点、滑动不算

手指一点就出框，误操作太多
0.4.1

按住 0.35 秒才画框；直接滑动 = 原生翻页

画框和页面滚动打架

决策轨迹 / DECISION TRAIL

选它

自动建多件，默认全选

店里真实习惯是先一堆一起拍；重拍会打断收衣节奏。

0.2.0 · items[] · 真机
否决

识别多件就要求重拍

旧行为。订单多时店员不会重拍，只会漏信息。

旧版 · 被真机反馈淘汰
改成

点一下就能画框

和页面滚动冲突；改成按住 0.35 秒才接管，直接滑动仍然翻页。

0.4.1 · 手势 v2
TRY IT / 多件点选 点 1–4 取消或恢复；点绿色「手动补选」，在图上拖一个框
AI 收衣开单界面，一张图识别出四件衣物，分别用 1–4 标出
RELEASE RECEIPT2026-10-17 07:58
TAGv0.2.0
BACKENDSyc.Net.Application.dll · 0620a0c9…
STAFFindex-BmiWU1Iq.js
SMOKEidentifySingle.items[] = present
PUBLIC新资源 200 / 旧资源 404
BACKUP/var/www/staff-old-20261017075740
STATUSVERIFIED

一条经验把“例外”变成“同一条流程”，系统才不会越做越复杂。

老板的原话
验证一下，当拍照识别的时候，图片本身有条形码的时候，可否直接识别填入到条码框，这样店员就不用单独特写拍摄了。
分布验证单件和多件的效果，给我方案，我确认后执行。

先别改代码，先量：同一个标签，在不同分辨率、不同裁切下，到底能不能读对。结果比预想的更直接——不是模型不认识条码，是 1600 压缩后标签数字只剩约 20 像素。

输入方式读码结果判定
1600（当时 Pad 上传尺寸）7055@090 / 7056@090错
204870535090 / 705050901/2
256070505090对
3072 / 4096 / 原图70505090对
按整件衣物 bbox 裁切705050690错
标签特写 340×680705050090对

结论：整图多码只能返回 1 个码；整件裁切会让标签占比太小；只有“标签特写”级别才稳定。于是最终方案变成三步：逐件裁 2560 → 多码定位 → 标签 bbox 二次裁切复核 → 只回填 9 位。

决策轨迹 / DECISION TRAIL

否决

整图一次多码

多件图只返回 1 个码；088/089 还会来回跳。省调用量，但不可用。

4 次实测 · 只出 1 码
否决

按整件衣物 bbox 裁切

毛衣整件裁切读成 705050690，错；标签在整件衣服里占比太小。

整件裁切 · 误读
选它

标签 bbox 二次裁切复核

先多码定位，再按标签 bbox 裁一刀，单码复核；每件 2 次调用，换准确率。

090 / 089 / 088 全对
单件毛衣主图，标签条码 705050090 被识别并回填

单件：主图直接回填 705050090

RELEASE RECEIPT2026-10-22 20:40
TAGprod/2026-10-22-2030
STAFFindex-BG2s48Yk.js · e3b2fa4d…
API DLL43ff976d…
SMOKE090 → 705050090
SMOKE黑鞋多码 → 705050089
BACKUP/var/www/staff-backup-barcode-20261022-203528
STATUSVERIFIED · 2 张样张；20 张真实图待验

发布时 rsync --delete 删掉了 systemd 需要的 Log 目录，API 重启循环约 2 分钟；加 --exclude Log 后恢复。见翻车博物馆 →

一条经验：错码比空码更糟。 宁可让店员多扫一次，也不能让收银台扫不出来。

老板的原话
评估一下，让账号同时支持刷脸登录的方案（利用阿里云的接口）。

真正的难点不在“调通接口”，在“共用一台 iPad 的六个店员，怎么确保下一次拿起它的人，是账号本人”。

这件事最后变成了一串边界：浏览器做不到什么、iPad 会伪装什么、刷新会误触发什么、日志会泄露什么。

边界清单 / CONSTRAINTS

  • 浏览器不能主动锁系统屏只能监听 visibilitychange / pagehide，靠设备系统锁屏配合。
  • iPadOS 会伪装成 Macintosh不能只看 UA，要看屏幕短边；iPhone 开“桌面网站”也不能误判成 iPad。
  • 下拉刷新也会触发 pagehide旧逻辑把刷新误判成切后台，一刷新就要求刷脸；加 2.5 秒窗口识别刷新。
  • Android WebView 会缓存旧包同一个人 54 秒内连续 4 次刷脸，清缓存后正常。
  • 日志会泄露隐私SqlSugar 把人脸底照的 varbinary 展开进 journal；脱敏并清掉 250.8MB 日志。
店员 Pad 工作台，演示数据

工作中：店员在工作台处理订单。

01

系统锁屏 / 切后台

02

pagehide / visibilitychange

03

清 token，回 /#/face-login

04

1:1 比对，进工作台

94.5095.3094.80 店长 W · 3 次真机成功

演示数据 · 截图来自产品官网

GRAY RELEASE RECEIPT2026-10-21
ROUTE/#/face-login
TABLEsys_user_face
LOCK120s idle + visibilitychange + multi-tab
SCORES94.50 / 95.30 / 94.80
PRIVACYvarbinary SQL logs desensitized
STATUSGRAY · 2 人通过；6 人全量待录

一条经验：功能是明面上的，边界才是工作量。

06

INCIDENT LOG

翻车博物馆

五次真实事故。没有它们，这个页面就只是广告。

INCIDENT 012026-10-17

UnitOfWork 是安慰剂

症状：钱收了，单没推进。

根因
Furion 的 [UnitOfWork] 是 MVC 动作过滤器，对服务内部调用不生效。
修复
SqlSugar 显式事务 + 条件更新，支付单标记与下游入账同生共死。

留下的规则：框架的糖，要先证明它真的生效。

INCIDENT 022026-10-21

人脸底照进了 journal

症状：服务器日志里出现人脸照片的 SQL。

根因
SqlSugar 把 varbinary 参数展开进日志。
修复
刷脸表 SQL 日志脱敏；清旧 journal/syslog，释放 250.8MB。

留下的规则：隐私数据不能靠日志级别兜底。

INCIDENT 032026-10-22

rsync 删掉了 Log 目录

症状：API 起不来，重启循环约 2 分钟。

根因
rsync --delete 删掉 systemd ReadWritePaths 需要的大写 Log 目录。
修复
--exclude Log + mkdir -p Log/logs/wwwroot，20:40 恢复。

留下的规则：发布脚本要懂运行时的目录契约。

INCIDENT 042026-10-21

分类 ID 超过 JS 安全整数

症状：admin 选品类为空，前端筛选不到。

根因
ID 900000000000000201 超过 Number.MAX_SAFE_INTEGER，JSON 解析四舍五入。
修复
6 个分类 / 17 个规格改到 880000000000001-017，同步引用。

留下的规则：数据库主键也会撞上前端的数字精度。

INCIDENT 052026-10-21

Vite build 卡在 rendering chunks

症状：一个 UI 改动，构建一直卡住。

根因
picomatch 4.0.4 缺少 parse.fastpaths，Vite 6.4.2 构建失败。
修复
回退 picomatch 4.0.2；先用可构建基线发 UI，构建链单独修。

留下的规则：构建链也是生产的一部分。

07

ORIGINAL VOICE

原声

10 条提示词，和它们改变了什么。原文未美化；脏话用 ×× 弱化。

接续
“这个项目之前是 codex 开发的……你遍历项目文档，确保可以接续开发。”

它改变了什么：先读再写。27 场主会话，从读懂旧系统开始。

边界
“坚持原则，对 windows 的任何修改都要经过我确认。”

它改变了什么：生产变更闸门。之后每一次上线，都留备份、哈希和回滚锚。

托管
“我不会部署，你通过云助手自行部署。”

它改变了什么：AI 接管部署，但人保留“发不发”的签字权。

统一
“手动补一件和单独拍一件后面的流程应该是一个……”

它改变了什么：两条路合成一条单件识别流；补框是裁一张图，单独拍是新拍一张图。

手势
“1、滑动对于页面的滑动操作，你应该保留啊。”

它改变了什么：按住 0.35 秒才画框，直接滑动仍然是原生翻页。

反对复杂
“不接受，我还是认为实现方式过于复杂！”

它改变了什么：放弃“全员超管”，改角色级 DataScope；现网账号默认行为零变化。

发火
“你××的干嘛呢？不就是改个 UI 吗，你说说，你在干嘛！”

它改变了什么：先发已改好的 UI，构建链单独修；不再让一个依赖问题拖住整个交付。

复用
“你不用特意去找方案吧，你先看看当前补条码是怎么实现拍条形码录入的，直接复用能力不就行了？”

它改变了什么：复用现有 identifyBarcode 链路，不引新库、不新增接口。

签字
“最终要等我明确让你部署，你再进行部署，在此之前，不要动生产环境。”

它改变了什么：发布权在人的手里。AI 可以准备到 99%，最后一步必须等人。

窗口
“8:30 统一发！”

它改变了什么：门店下班后的统一发布窗口；多条改动合成一个批次，减少中断。

显示 10 / 10

08

DELIVERY

交付确认物

不是“做完了”，是“验过了，而且知道哪一部分还没验”。

绿灯

  • 构建ClerkPad npm run build 通过；后端 dotnet build 0 error。
  • 测试report-service 45 项；MCP 4 项。
  • 冒烟条码 090 / 089；多件 items[]；刷脸 3 次。
  • 回滚备份目录 + SHA256 + tag，一条命令可退。
  • 公网新资源 200 / 旧资源 404，逐字节哈希一致。

黄灯

  • 条码2 张样张通过；20 张真实多件图待验。
  • 刷脸2 人灰度通过；6 人全量待录。
  • 支付真实回调待下一笔实付自然验证。
  • 体验按住画框在 iOS Safari 的手感，仍需门店高峰期复测。

不把黄灯藏起来，是这套交付的一部分。

版本日期内容证据
0.2.010-17

一图多件 / bbox / items[]

tag v0.2.0 · DLL 0620a0c9 · staff BmiWU1Iq
0.4.110-17

补选手势 v2 / 提示文字瘦身

tag v0.4.1 · 70 处文案
0.6.010-19

员工业绩页 / 我的

staff CXxU-Ddv · 34 项算法自测
0.7.010-21

刷脸登录灰度

3 次真机 94.5+ · sys_user_face
0.8.010-21

逐件上挂 / 取送

DLL 854de0ed · 回填 227,189 行
0.9.110-22

条码回填 / 逐件 / 登录态自愈

tag prod/2026-10-22-2215 · staff BD4lnSZA
SAMPLE RECEIPT2026-10-22
VERSIONClerkPad 0.9.1
FRONTENDindex-BG2s48Yk.js
BACKENDSyc.Net.Application.dll
SMOKE2 张条码样张 + 1 单逐件操作
ROLLBACK备份目录 + tag + SHA256
SIGN-OFF老板确认后发布

“交付不是宣布完成，
是知道哪一部分还没验。”

09

TIMELINE

7 天，181 次提交

九月先摸清系统；10 月 16 日到 22 日，把门店端和基础设施集中重做了一遍。

接续旧系统

第一句话是“遍历项目文档，确保可以接续开发”。27 场主会话从读懂开始。

报表上 OSS

日报 / 周报 / 月报走 OSS 中转，微信推送与邮件分发解耦。

只读 API Key / 扫码充值 / 支付

机器调用有只读钥匙；支付宝当面付 + 微信 Native 双通道跑通。

多件识别 0.1.0 → 0.4.3

52 次提交；一图多件、手动补选、批次累加、手势 v2。

员工业绩 / 跨店权限

提成口径进报表与“我的”；角色级 DataScope，现网默认行为零变化。

刷脸方案 / Linux 迁移

CloudAuth 1:1 + 活体；.NET 10 上 Linux，systemd + nginx 接管。

逐件上挂 / 取送

订单内每件衣物单独上挂、取走、送达；分类四级联动。

条码回填 / 官网 / 登录态自愈

条码 9 位回填；产品官网上线；7 天累计 181 次提交。

10

REPLAY

这套方法能不能复制？

能。前提是你别把 AI 当“许愿池”，把它当“施工队”。

  1. 01

    先让 AI 读，不要先让它写。不读懂你的系统，它只能猜；猜出来的东西，上线就是事故。

  2. 02

    先出方案卡，再动第一行代码。文档核对、框架对照、候选方案、可行性验证、结论，缺一项都不开工。

  3. 03

    一次只改一个可验证的变量。版本号、CHANGELOG、commit 一起走；出问题能定位到哪一版。

  4. 04

    每条结论都要有证据，每个上线都要有回滚。构建、冒烟、真机、哈希、备份、tag，少一样都不算交付。

  5. 05

    允许 AI 说“未验证”，但不容忍“应该可以”。黄灯比假绿灯值钱。

AI 可以写得很快，
但签字的人必须很慢。
附录：27 场主会话索引 （展开）
日期会话产出
梳理项目文档接续微信周报功能建立接续上下文
opencode 使用是否正常环境自检
Agent 开发规则：优先开源与文档复用铁律
微信订单查询与报表推送迁移方案迁移方案
本机查询 MCPMCP 调研
会员储值赠送 API 与前端方案充值套餐
progress.md OSS 服务器侧执行报表 OSS 中转
连接 GitHub 保持及时推送推送纪律
伊尔萨后端 API Key 只读鉴权方案机器只读 key
收款码自动充值、店员业绩统计与移动端方案支付 / 业绩
伊尔萨 IIS HTTPS 证书自动续期方案卡证书自动化
日报周报月报充值明细加入店员报表口径
多件衣物识别拆分与扫码支付可行性方案0.2.0
洗衣店衣物寄存服务方案规划U 衣库规划
staff 个人中心改密码方案0.5.x
员工业绩页手机端 HTML demo0.6.0
跨店查看DataScope
为日报 / 周报 / 月报添加员工业绩排名报表 V5
GitHub 项目补充完整 README 说明文档
评估账号接入阿里云刷脸登录方案0.7.0
linux 后端规划.NET 10 迁移
订单内衣物单独上架与取送前端实现方案0.8.0
店员下单搜索优化：分类服务与价格机制0.9.0
yiersa 产品官网调研与上线方案site
拍照识别条码自动填入的单多件验证方案0.9.1
AI 分类更新机制与织补误归类改造方案分类修复
opencode 构建伊尔萨过程展示页本页