VIDEO-SLICES / VIDEO-SPOKESPERSON手机直接拍、直接传
「上传门店真实视频」和「拍 1 张正面照 + 3 段短视频」——店长举着手机在展厅里拍，拍完当场传。浏览器 capture 一步到位；Windows 客户端要先把素材导到电脑上，凭空多两步。
门店工作台
要不要做成
Windows 客户端
结论先给：不要。40 个界面逐屏盘完，需要本地系统权限的是 0 个。客户端唯一站得住的论据不是能力，是大陆可达性——而那堵墙客户端同样绕不过去。
// 评估对象 akke-ai-growth-workbench-prototype V4.1 · 2026-08-02 解包实测
40 个界面
0 命中本地权限
5 类客户端专属能力
E1 大陆可达实测
T1/T2/T3 执行分级
网页 + 薄 AGENT
SCROLL / 向下滚动
01
Prototype Inventory · 原型解包
先把 40 个界面数清楚
原型是单页应用，页面本身抓不到文案。直接解包它的 JS bundle（index-CJqrNFwr.js，390 KB，Unicode 转义还原后提取 id / title / phase / duration）——得到的是可枚举的结构，不是我对着截图的印象。
0
总界面数
36 工作流 + 4 账号开通
36 工作流 + 4 账号开通
0
需要本地系统权限的界面
5 类能力逐条核对
5 类能力逐条核对
84分钟
店长日常在线时长上限
每日任务 + 每日运营合计
每日任务 + 每日运营合计
3
回头做客户端的触发线
目前一条都没触发
目前一条都没触发
Structure
三条主线 × 两档节奏：短视频获客（8 屏）、企微自动接待（8 屏）、沉默客户跟进（6 屏）；每条主线都先走一遍「引导流程」把门店事实喂进去，再进入「每日任务／每日运营」的日常循环，另有 14 个详情页承接逐条核对。
Delta
与 07-31 架构 spec 里评估的那版原型（renovation-ai-growth-lab，23 主屏 + 15 详情屏）相比，V4.1 主屏收敛到 22、详情页收敛到 14，并新增了 4 屏自助注册开通流（登录 → 填门店信息 → 微信／支付宝支付 → 开通成功）。这是本轮最值得记的产品变化：产品已经把自己定义成「店长自己注册、自己付款、自己上手」的自助 SaaS。
02
Native Capability Matrix
客户端能干、网页干不了的五件事
「网页还是客户端」不该靠感觉投票。桌面客户端相对浏览器的独占能力就 5 类，逐类去 40 个界面里找谁会用到它——这是个可证伪的检查，不是偏好。
| 客户端独占能力 | 原型里最可能用到它的地方 | 命中 | 为什么不命中 |
|---|---|---|---|
| 本地文件系统任意读写 免选择器、批量扫目录 |
上传门店实拍视频、上传价格表／活动规则、导出成片 | 0 / 4 | 全是「一次挑几个文件」的动作，浏览器原生 <input type=file> ＋ 下载即可，没有扫目录、没有监听文件夹 |
| 常驻后台 · 开机自启 · 系统托盘通知 | 「等系统制作今天的视频」进度页、待处理聊天提醒 | 0 / 2 | 制作跑在云端，页面只是看进度；店长不在页面时该走企微／短信推送，而不是要求他电脑一直开着 |
| 驱动本机第三方 App（GUI 自动化） | 企微自动接待、抖音发布成片 | 0 / 3 | 执行层已定为托管机队——原型自己写着「企业微信已连接，云电脑工作中」，不在店长的机器上跑 |
| 离线可用 | 全部 40 屏 | 0 / 40 | 每一屏的内容都来自云端分析结果（视频拆片段、意向打分、接待漏斗），断网时客户端也只是个空壳 |
| 本地硬件（摄像头 / USB / ADB） | 「准备店长出镜素材」拍 1 张正面照 + 3 段短视频、上传门店实拍 | 0 / 2 | 这两屏天然在手机上完成——Windows 客户端在这里不是优势，是劣势 |
03
Web-Only Advantages
反过来，有四件事只有网页做得了
上一节是「客户端的独占能力用不上」，这一节更硬：原型里有四个动作，Windows 客户端做不到或做得更差。它们不是锦上添花，是这个产品的入口动作。
SALES-METRICS手机企微扫码登录
原型原话：「请让已获授权的门店员工，用手机企业微信扫码登录。」授权动作天然发生在手机上，PC 端只负责显示那张码——这正是网页最擅长的形态。
PAYMENT微信 / 支付宝扫码开通
V4.1 新增的自助开通流：填门店名和手机号 → 扫码付款 → 进系统。自助 SaaS 的转化漏斗里，「先下载安装个 exe」是致命的一步。链接点开就能付，和先装客户端再注册，转化率不是一个量级。
DELIVERY一条链接就是交付
目标用户写得很清楚：门店店长自助。网页版的交付物是一条 URL；客户端的交付物是「装机 + 杀软放行 + 权限授予 + 后续升级」，每一步都要有人接电话。这是售前售后的固定人力成本，不是一次性投入。
04
Steelman · 反方最强论据
替客户端说两句话
只列有利于自己结论的证据不叫评估。客户端这边有两条论据是真的站得住的——第二条尤其硬，它是这套网页方案目前最大的未解风险。
论据 A · 使用强度
店长每天要在这个界面里待一个多小时
按原型自带时长累加，日常 76–84 分钟/天，其中「像带新人一样给机器人打分」一屏就是 30–60 分钟、100 组。这种强度的重度工具，装个客户端不过分。
Response
使用时长决定的是「要不要把它做得好用」，不是「要不要装」。拆开看这 84 分钟：播放视频、点选适合／不适合、四项打分、逐句标注、审核放行——每一样都是浏览器的主场。Figma、Notion、飞书文档的日均使用时长都远超一小时，主形态仍然是网页；它们出桌面壳是为了多窗口和系统级快捷键，而不是因为网页做不动。真要解决重度使用的体验问题，投入应该花在断点续存（100 组打分随时退出随时接着做）和键盘流上，不是花在打包 exe 上。
论据 B · 网络可达（真问题）
网页版现在在大陆根本打不开
2026-07-28 从成都真国内网络实测：baidu 200/275ms、upio.ai 200、feishu 200，而 akke.vercel.app 超时，*.supabase.co 连 DNS 都解析不了。而客户端理论上可以自带线路、自选落点，把这堵墙绕开。
Response
客户端并不能凭空获得可达性。它照样要连你的 API 和数据库——除非它自带代理，而那是合规灰区，且门店的网络策略、杀软和企业出口一样会拦。真正的解法与前端形态无关：把后端的对外落点搬到国内可达的位置。这条路已经在跑了——甲方的案例上传页就是因为同样的原因走了 Fly 中转（
worker/routers/upload_relay.py），Fly 国内实测可达。也就是说，解决了可达性，网页和客户端一起解决；不解决，客户端也救不回来。
Caveat
论据 B 的实测数据是 2026-07-28 记录的，本页未重新复测（需要真实国内出口）。若在做最终决策，这一条应当重跑一次——但即使结论翻转（Vercel 变得可达），它也只是消掉客户端的这条论据，不会新增任何支持客户端的理由。
05
Execution Tiers · 与已定架构对齐
三档执行器，没有一档落在店长的电脑上
这个判断不是从零开始的。07-31 的架构 spec 已经把「谁来真正把消息发出去」分成三档——把客户端往这三档里放，会发现它没有位置。
T1
COPILOT AI 草拟、店长自己发。执行工具＝店长自己的设备（多半是手机）。刻意不在店长机器上放 agent——发消息这个动作由人完成，系统只提供草稿和记账。→ 不需要客户端
COPILOT AI 草拟、店长自己发。执行工具＝店长自己的设备（多半是手机）。刻意不在店长机器上放 agent——发消息这个动作由人完成，系统只提供草稿和记账。→ 不需要客户端
T2
AUTOPILOT 托管机队代发。执行工具＝无影云电脑上的 GUI agent，机器是公司的、集中标定、可远程下发命令。店长的动作只有一个：在 dashboard 里批准。→ 执行不在店长机器
AUTOPILOT 托管机队代发。执行工具＝无影云电脑上的 GUI agent，机器是公司的、集中标定、可远程下发命令。店长的动作只有一个：在 dashboard 里批准。→ 执行不在店长机器
T3
KF API 官方客服接口。纯服务端，前置条件是 ICP 备案。→ 与终端形态无关
KF API 官方客服接口。纯服务端，前置条件是 ICP 备案。→ 与终端形态无关
// 四态统一账本 pending → approved → executed → verified 刻意不感知执行工具：T1 的 executed 由店长点确认，T2 由 GUI agent 回执，T3 由接口状态。前端只负责喂 approved、读 verified。
Precedent
spec 里已经明确否决过「店长自备电脑跑 agent」，理由是「标定 N 台异构 + 丧失 RunCommand」——N 台店长电脑分辨率、缩放、企微版本各不相同，逐台标坐标不可规模化，而且一旦跑在店长机器上，就失去了云电脑那套「远程下发命令、热更新、统一回收日志」的运维通道。Windows 客户端一旦承担执行职责，就是把这个已否决的方案换个名字复活。
06
What Web Actually Costs
选网页版之后，真正要花钱的四件事
「做网页」不等于「没成本」。下面这四件是选了网页就必须解决的工程题——它们全都不是能力问题，是链路问题，而且客户端方案里对应的题目只会更难。
P0 · 必须先解国内可达入口
店长入口不能是 *.vercel.app 直连。同一份 Next.js 代码出两个入口：内部运营走 Vercel，店长面经 Fly 反代前置。配套的硬写法约束是——店长面页面全 SSR、服务端取数，浏览器不直连 Supabase；现有 NEXT_PUBLIC_SUPABASE_* 浏览器直连路径对国内用户是死的。满足这条，加前置只是运维动作；不满足，换任何托管都救不回来。
P0 · 商务前置ICP 备案
自有国内域名要备案，而这和企微 kf API 冻结是同一堵墙——一次备案同时解锁「店长能打开的域名」和「T3 官方接口」两件事。这也是为什么它在 spec 里被列为最高优先级：它不是技术选型的下游，是上游。
P1大文件上传要真做
门店完工／展厅实拍动辄几百 MB，还要经反代多一跳。分片 + 断点续传 + 后台上传是必选项，不是优化项。原型文案里已经写了「状态显示分析中时先等待，不用反复上传」——说明这个痛点在草图阶段就被感知到了。
P1长任务状态可恢复
「100 组打分」明确写着「可随时保存稍后继续，不需要一次做完」；视频制作进度页要跨刷新、跨设备保持。这些状态必须落服务端，不能存在浏览器本地——否则店长换台电脑就得从头来。做到了，客户端在体验上的最后一点优势也没了。
07
Reversal Triggers · 什么情况下回头
三条触发线，与真要装时该装什么
结论要可证伪才有价值。下面三条任意一条成立，「不做客户端」这个判断就该重开——目前一条都没成立。
触发线 ①
- 托管机队被否，执行必须落回门店本机
- 典型诱因：云电脑上的企微／抖音被风控，或客户不接受账号托管在供应商的云上
- 后果：需要在门店电脑上跑 GUI 自动化 —— 这是唯一真正需要「装东西」的场景
触发线 ②
- 门店网络策略禁止浏览器访问外部 SaaS，但允许白名单客户端
- 多见于大型连锁 / 商场统一 IT 管控
- 注意：这条与「大陆可达」是两回事，别混为一谈
触发线 ③
- 出现无法上传的本地数据源——本地 NAS、门店 ERP 库存文件、需要实时读的本地库
- 特征是「数据量大到不能传、或更新频到不该传」
- 原型现有 40 屏没有任何一屏沾这个
If Triggered
即便触发，正确形态也不是全功能客户端，而是 网页版 + 一个极小的本地 Agent：托盘程序、几 MB，只负责驱动本机的企微／抖音 + 上报心跳，所有 UI 仍然在网页里。这样需要发版维护的只有一个薄组件，而且只对触发了的门店下发，其余门店纯网页。企微 SCRM、直播中控这类产品的成熟形态都是这个样子——它不是折中，是这类场景的正解。
And Even Then
薄 Agent 这条路要提前算一笔账：它会把「网络可达」问题换成「装机 + 升级 + 异构标定」问题，而后者正是 T2 托管机队方案当初被选中的原因。所以触发线 ① 真的来了，第一反应应该是「能不能换个托管落点」，而不是「那就发给店长装吧」。
08
Verdict
判定表
按对这个产品真正重要的维度逐条比。「客户端更优」的格子只有一个，而那一个还是错觉。
| 维度 | 网页版 | Windows 客户端 | 本项目判定 |
|---|---|---|---|
| 40 屏的能力覆盖 | 全覆盖 | 全覆盖（无增量） | 平手 → 取更便宜的 |
| 手机拍摄 / 扫码登录 / 扫码付款 | 原生支持 | 做不了，要跨设备绕 | 网页 |
| 自助注册开通转化 | 点链接即进 | 先下载安装 | 网页 |
| 交付与售后成本 | 一条 URL | 装机 / 杀软 / 权限 / 升级 | 网页 |
| 迭代速度（V4.1 还在改） | 刷新即生效 | 发版 + 版本碎片 | 网页 |
| 多角色多设备（店长 / 员工） | 天然跨端 | Windows 独占 | 网页 |
| 本地系统权限 | 受限 | 完整 | 平手 · 0 屏用得上 |
| 离线可用 | 不可用 | 「可用」但无数据 | 平手 · 数据全在云端 |
| 大陆网络可达 | 需 Fly 反代 + 备案 | 同样需要（除非自带代理） | 都要解，与形态无关 |
| 与 T1/T2/T3 执行分级的契合 | 三档都只需要「批准 + 看回执」 | 无落点；承担执行＝复活已否决方案 | 网页 |
一句话总括：这套工作台的 40 个界面全是看板、打标、审核、上传下载——重活（企微 7×24 接待）产品自己已经放到托管云电脑上了，留给店长的只是一个遥控器。遥控器就该是网页。真正要花钱的地方不在前端形态，在国内可达入口与ICP 备案——这两件事解决了，客户端剩下的全部理由都会自动消失。
证据与口径
- 原型结构：akke-ai-growth-workbench-prototype JS bundle 解包，2026-08-02 实测；36 个工作流界面的 id / phase / duration 逐条枚举，另 4 屏账号开通流
- 大陆可达（E1）：worker/routers/upload_relay.py 头注，2026-07-28 成都无影真国内网络实测 —— 本页未复测，作决策前应重跑
- 执行分级 T1/T2/T3 与「否决店长自备电脑跑 agent」：2026-07-31 门店营销工作台技术选型与架构 spec（状态：选型定稿，可行性评估阶段）
- 本页不含：真实门店的网络策略调研、连锁客户 IT 管控访谈 —— 触发线 ② 目前是推演而非实证