上传一张Excel，AI还你一套系统！22万人在用的神器

每个公司都有这么一张表。

它可能是排班表、点工表、设备巡检表、质量记录表，也可能是一张用 Word 画的「申请单」。它的生命周期通常是这样：张三填一版发群里，李四下载改一版，王五在文件名后面加上「最终版」，然后赵六又加一个「最终版_v2_真的最终了」。

一个月后，没人知道哪个版本是对的。

你当然想过「这玩意儿是不是该做成个系统」。但一想到要提需求、排期、等开发、上线、培训……算了，还是继续用 Excel 吧。

今天要说的这个 Skill，专门治这个病。

它到底做什么

「纸质表单电子化系统生成器」（paperless-business-system-from-files）在 SkillHub 上的定位很直接：把你手上的 Excel、CSV、Word、PDF、JSON、TXT、ZIP，甚至一张电子表单，变成一套可填写、可查询、可导入导出、能在本地或局域网跑起来的中文业务系统。

注意，它不是让 AI 给你写一段 Python 脚本，也不是丢给你一个静态 HTML 页面，而是一整套能双击启动的交付包。

用户要做的事，一句话就能说清：

> 把这些资料做成 Windows 本地中文业务系统，先分析资料；确认能做后自动生成、测试并给我完整 ZIP。

剩下的盘点、建模、写规格、生成代码、跑测试、打包，都由执行这套 Skill 的智能体自己完成。你不需要选脚本、不需要拼参数、不需要懂字段映射。

目前它在 SkillHub 上的下载量已经超过 22 万次。

交付的东西长什么样

很多「AI 生成系统」的项目，最后给你的是一个源码文件夹，能不能跑起来全凭运气。这个 Skill 把最终交付格式写死成了六个编号目录：

<系统名称_局域网完整包>/├── 01_服务端_完整程序/├── 02_Windows填写客户端/├── 03_macOS填写客户端/├── 04_原始业务表参考/├── 05_申请单电子档模板/├── 06_说明与版本记录/├── <系统名称>_用户密码.rtf├── 一键启动/停止_Windows.bat、.vbs└── 一键启动/停止_macOS.command

服务端、双平台客户端、原始资料、模板、版本记录各就各位，根目录还配好了成对的启停脚本，和一份写着你账号密码的说明文件。

对非技术用户来说，这意味着：拿到 ZIP，解压，双击「一键启动」，浏览器打开，用。就这么简单。

它最聪明的地方：先把「规格」说清楚，再写代码

这是我觉得这个 Skill 和大多数「AI 一把梭生成项目」最本质的区别。

在写任何业务代码之前，它要求先生成并完善 `system-spec.json`。业务对象、字段类型、唯一键、计算公式、角色权限、审批链、导入防重策略、报表看板、审计备份……全都要先落到这份规格里。

只有规格里有证据支撑的东西才会被物化：字段来自你上传的表，公式来自表里的原公式，唯一键来自你确认过的列。没证据的部分，它会老老实实列成「待确认」，而不是编一个看起来合理的默认值糊弄过去。

它还定义了资料完整度的 A/B/C/D 四级门禁。当资料只有报表和模板时，它只生成确定的部分，不会假装自己还原了你们公司的正式业务口径。

为什么我信它「真的能跑」

AI 写代码最大的坑，是它会非常自信地告诉你「已完成」。

这个 Skill 的对策是：把「完成」拆成五个可验证的等级。

1. 设计支持：规则和脚手架里有这个能力；

2. 已生成：这次项目里确实生成了对应文件或模块；

3. 静态验收通过：结构、安全、哈希、配置等自动检查通过；

4. 运行验收通过：这次真的启动、操作并通过了测试；

5. 目标机实测通过：目标 Windows 电脑上实测过，比如断网、EXE、局域网连接。

规则很硬：只有达到对应等级，才能说「已验证」「断网可用」「解压即用」。静态检查通过，不再等于系统可用。

更狠的是，从 2.7.0 版本起，`validate --strict` 如果发现测试没跑、`runtime_e2e_verified` 不是 true，会直接失败。想糊弄都糊弄不了。

而真正跑测试的时候，它会在隔离副本里跑，不会动你项目里的业务数据库。测试覆盖启动和 `/health`、管理员登录、增删改查、严格类型校验、CSV 逐行导入、Excel 导出、SQLite 备份与恢复。

系统做完了还能改

现实里的需求永远会变。今天加个字段，明天改个必填，后天再开一个角色。

这个 Skill 的持续变更流程同样是 Spec-first 的：用户直接说「怎么改」，智能体把原话结构化成 `CHANGE_REQUEST.json`，先做影响分析，把变更分成三类：

• `safe_additive`：新增对象、新增字段，可以自动生成升级副本；
• `review_required`：标签、唯一约束、公式、权限这类变化，需要业务复核；
• `breaking`：删对象、删字段、改类型，默认直接阻断自动升级。

升级永远生成新副本，原项目不动。万一改砸了，还有非破坏式的回滚——而且回滚默认不删数据库里新增的列，宁可结构上「看起来不完全一样」，也不为了整洁再去破坏历史数据。

这个取舍，是真正做过数据系统的人才会做的。

几个「细节里的诚意」

默认技术栈是 Python 3.10+、Flask + Jinja2、SQLite、原生 JS/CSS。界面参照的是「点工系统」的成熟范式：顶栏 + 左侧多视图导航 + 筛选区 + 汇总卡片 + 表格 + 弹窗录入 + 签字审核 + 看板 + 导出，主色是那个很有辨识度的红。

默认只监听 `127.0.0.1`，只有你明确说要局域网共享，它才监听内网地址。生成的前端也不会退回「顶部导航 + 一个列表」的简陋骨架。

连停止脚本都有硬规定：禁止 `killall python`、`taskkill /IM python.exe` 这类操作，只能停自己这个项目的实例。用过那种「一停服务把别人脚本一起干掉」的工具的人，看到这条会感动。

安全上也划了红线：不执行 Office 宏、PDF JavaScript、压缩包里来历不明的程序。

说点实在的

这类工具真正解决的，不是「不会写代码」，而是「没人愿意为一个小流程去提需求」。

一张排班表、一套设备点检记录、一份要签字的申请单——它们的共同点是：重要，但不够大到值得立项。 于是它们就一直躺在 Excel 里，年复一年地靠微信群和「最终版」续命。

「纸质表单电子化系统生成器」把这件事的门槛压到了「上传文件 + 说一句话」。

当然，它也不是魔法。资料越结构化、规则越明确，生成的东西越靠谱；只有几张截图的话，它也只能给你一个原型。这一点它自己在文档里说得很清楚——不吹，反而更让人放心。

Skill 地址：skillhub.cn/skills/user_84b8c7d7/paperless-business-system-from-files