产值日报方案转向：从 Python EXE 到钉钉宜搭
产值日报第一版做 Python EXE，跑不通。转向钉钉宜搭 + Python + 微信截图。工具形态由数据来源决定。
本节要点：产值日报 v1.0 做 Python EXE 跑不通；转向宜搭+Python+截图；工具形态由数据来源决定（单系统→EXE，多人协同→宜搭）。
v1.0：照搬出纳工具思路
产值日报第一版，我照搬出纳工具的成功经验：Python EXE 单机工具。
逻辑：车间把产量导成 Excel → 工具读入 → 算产值 → 出日报。
做完发现根本跑不通。
为什么跑不通
出纳工具能 EXE 化，是因为数据来自银行网银——单一外部系统，导出 Excel 即可。
产值日报的数据来自5 个车间的文员——她们习惯纸笔和微信群发，不会导 Excel。
| 维度 | 出纳工具 | 产值日报 v1.0 |
|---|---|---|
| 数据源 | 银行网银（1 个系统） | 5 个车间文员（多人） |
| 数据格式 | 固定 Excel 导出 | 纸笔/微信/口头 |
| 喂数据的人 | 出纳自己（会 Excel） | 车间文员（不会 Excel） |
| 协同需求 | 无 | 强（5 个车间 + 会计 + 老板） |
v1.0 失败的根因：数据来源是多人协同，不是单系统导出。EXE 假设有现成 Excel，但没人能稳定产出这个 Excel。
转向：宜搭 + Python + 截图
重新设计 v1.1，按数据来源选工具：
| 数据环节 | 谁产生 | 用什么工具 |
|---|---|---|
| 产量录入 | 车间文员（5 人） | 钉钉宜搭（手机表单） |
| 产值计算 | Python | Python 脚本（含单价表） |
| 日报推送 | 钉钉机器人 | 推送给老板 |
为什么宜搭：
- 手机表单，文员不用学 Excel
- 多人协同，5 个车间同时录
- 数据集中，Python 拉宜搭 API
关键决策：单价不进宜搭
宜搭表单设计时，差点把"单价"也放进去。后来想清楚：
- 车间文员不该看到单价（敏感）
- 单价是财务维护的
所以：宜搭只录产量 + 出勤，单价在 Python 端维护。Python 拉宜搭产量 × 单价表 = 产值。
这个决策保护了敏感数据，也让宜搭表单简单（文员只录 2 类字段）。
数据流（v1.1）
车间文员手机录产量（宜搭表单）
↓
Python 拉宜搭数据 × 单价表 → 算产值
↓
生成 markdown 日报（按老板截图样式）
↓
钉钉机器人推送老板群
评估 Spring Boot+Vue 原型
转向宜搭前，还评估过一个 AI 生成的 Spring Boot + Vue 原型系统（3977 行 Java + 15 个 Vue 页面）。
结论：保留作 spec，不上线。
原因：
- 5 个 P0 bug 未修
- 维护成本高（要部署服务器、数据库）
- 宜搭零运维，文员用手机更顺
AI 生成的原型有参考价值（字段设计、流程），但生产用还是宜搭这种成熟低代码更稳。
工具形态决策框架
这次转向沉淀了一个判断框架：
| 数据来源 | 工具形态 | 例子 |
|---|---|---|
| 外部系统导出（银行/金蝶） | Python EXE 单机 | 出纳/销售大表/损耗表 |
| 多人录入协同 | 钉钉宜搭 + Python 汇总 | 产值日报/未来计件工资 |
这个框架后来写进了 CLAUDE.md，是所有工具选型的依据。
教训
- 工具形态由数据来源决定——别照搬成功案例
- 多人协同数据别用 EXE——喂不进来
- 敏感数据不暴露给录数据的人——单价在 Python 端
- AI 生成的原型可作 spec，别直接上生产——5 个 P0 bug 教训
- 低代码（宜搭）+ 代码（Python）组合，比纯代码更适合协同场景
当前状态
产值日报 v1.4 设计完成，宜搭表结构 + Python 骨架（message_builder + dingtalk_robot）已跑通 demo。车间文员培训中，未完全投产。
demo 数据验证：和老板截图对得上 252.2 万产值。
给同行的建议
- 选工具前先问"数据从哪来"
- 单系统导出 → EXE；多人录入 → 宜搭/低代码
- 单价/规则这类敏感数据，放代码端不放表单端
- AI 生成原型可参考，别直接上
- 零运维 > 全自定义，能宜搭别 Spring Boot
本节要点
- v1.0 Python EXE 跑不通——数据来源是多人协同，不是单系统
- 转向宜搭（文员录）+ Python（算）+ 机器人（推）
- 单价不进宜搭，Python 端维护
- 工具形态框架：外部数据→EXE / 多人协同→宜搭+Python
- AI 原型作 spec，别上生产