ARTICLE · 1122135
上传一张 Excel,还你一套完整系统:这个 Skill 把「表格地狱」做成了软件
每个公司都有这么一张表。
它可能是排班表、点工表、设备巡检表、质量记录表，也可能是一张用 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 的对策是：把「完成」拆成五个可验证的等级。
设计支持：规则和脚手架里有这个能力； 已生成：这次项目里确实生成了对应文件或模块； 静态验收通过：结构、安全、哈希、配置等自动检查通过； 运行验收通过：这次真的启动、操作并通过了测试； 目标机实测通过：目标 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