Justhat

01 / 08序幕

  1. 01序幕
  2. 02阅读线索
  3. 03核心 · ERP
  4. 04点餐
  5. 05记账
  6. 06探索
  7. 07实现
  8. 08收尾
软件作品集业务系统 / 应用 / 探索

Justhat / 软件作品集

把业务， 做成系统。

我把采购、生产、库存中的业务规则，做成可以实际使用的软件。先从独立开发并交付的石膏厂 ERP 看起。

核心作品：石膏厂 ERP / 14 个业务模块 / 独立全栈开发

项目介绍 / 设计决策 / 交互演示 Justhat / Portfolio

02 / 从业务规则到真实使用

一套系统，怎样把业务接起来？

先看复杂业务如何建模，再看流程如何抵达设备与使用者。这是下面三项已交付作品的阅读线索。

  1. 重点展开

    石膏厂 ERP

    采购、生产、库存与计薪，如何共用一套业务规则。

  2. 补充实践

    点餐与共享记账

    从跨设备的订单流转，到多人协作的权限与追溯。

  3. 继续探索

    气象应用与 AI

    把数据服务与验证方法，带到新的使用场景。

03 / 核心项目 / 独立商业项目

石膏厂 ERP

让采购、生产和销售，
对得上同一笔库存。

工厂里的一笔业务会牵动多个环节：领料改变库存，成品入库影响可售数量，销售出库又关联计件工资。我从这些关联关系出发，独立完成需求梳理、数据建模、系统开发与交付。

交付状态
已交付客户使用
业务范围
14 个业务模块
验证范围
37 项验收场景

先建立规则，再实现流程

  1. 把货物认清

    内部货号与客户货名分开，保留各自的业务含义。

  2. 把库存落细

    定位到仓库和批次，让每次领料、入库与出库都有明确对象。

  3. 把变更连回原单

    退货关联原销售单，让库存变动、材料成本与计薪有一致口径。

把规则放进一笔业务

规则确定后，接着看它怎样约束一次真实操作。演示区用示意数据展示其中的库存流转。

领料之后，库存怎样变化？

库存落在仓库和批次上，不是一个笼统数字。同一袋石膏，对内是货号 GP-08，对外是客户看到的货名。下面用示意数据走一笔业务；退货必须连回原来的销售单，不能凭空加库存。

内部货号
GP-08
客户货名
建筑石膏

实现：React / TypeScript / Fastify / PostgreSQL

  1. 采购
  2. 生产
  3. 仓储
  4. 销售
  5. 计薪
仓库 A · 批次 B-08 120 原料库存
在制 0 已领未入
仓库 A · 批次 FG-12 0 成品库存

验收场景数量代表整理的测试范围，不等同于自动化测试通过数。权限可按部署配置调整。

交付与验证

这套系统已交付客户使用。围绕权限隔离、库存不足、重复提交和退货上限，整理了 37 项验收场景，用来核对流程在正常与异常情况下的边界。

验收场景数量代表整理的测试范围，不等同于自动化测试通过数。权限可按部署配置调整。

04 / 补充实践 · 酒楼点餐系统

ERP 解决了系统内部的业务关联。到了门店，同一张订单还要跨过小程序、服务端与后厨打印设备，抵达真正处理它的人。

在这部手机里下一单。

同一张单被系统接住。

后厨设备打出这张单。

这套系统已经在店里使用。

示意菜单：桌 08，清蒸鲈鱼。点确认下单，看订单怎样到达后厨。

FastAPI 接收订单，WebSocket 推状态。两端对的是同一张单，不是各自一份。

菜品、数量、备注变成一张打印任务，送到后厨。

独立完成小程序、服务端、打印联调和部署。已上线并持续维护。

四步示意 · 点击切换，查看跨设备协同

扫码下单、接收并推送订单、联动后厨打印，随后部署上线并持续维护。四个阶段可以并排阅读；点确认下单后，示意订单会进入后续画面。

酒楼点餐系统 · 独立全栈 · 小程序 / FastAPI / WebSocket / Docker · 已上线 · 持续维护

点餐小程序 · 流程示意

01 / 顾客端

选好，
下单。

桌 08 · 清蒸鲈鱼×1
少盐 · 尽快备注
订单服务 · 流程示意

02 / 数据流转

桌 08 · 清蒸鲈鱼 ×1

  • 接收订单
  • 更新状态
  • 推送消息

FastAPI × WebSocket

后厨协同 · 流程示意
后厨接单

桌 08 · 清蒸鲈鱼 ×1

少盐 · 尽快

设备联动 · 示意小票

03 / 打印设备

接单。

持续维护 · 流程示意

04 / 真实使用

继续，
迭代。

反馈 → 调整 → 回归

05 / 补充实践 · 多人共享记账系统

把订单送到后厨之后，协作还有另一面：团队共同记账时，谁可以修改，出错后如何追溯？这个项目把关注点从流程流转，推进到操作权限与更正记录。

换一个角色，再试着改这笔账。

厨房团队共用一本账。下面用虚构金额演示规则，不连接客户账本。

谁在操作？

简化规则演示 · 无登录 · 不连接真实账本

一笔写错的采购支出

冲正会新增一条关联记录，原始账目和更正原因都留下。直接删除做不到。已上线。

06 / 商业项目之外

ERP、点餐与记账，分别处理业务关联、设备协同和操作边界。沿着这些问题继续往外走，我也在气象应用与 AI 项目中探索数据服务、调查和验证。

气象数据、个人助理，和一项安全运营实验。

校园项目 · WeatherStudio / WeatherCan

WeatherStudio 把校园气象做成展示、内容和统一 API。WeatherCan 是已发布的小程序，把天气、预报和课表放在一起。

唯一开发者 · 已上线　/　小程序开发 · 小程序已发布

挑战杯参赛项目 · 智御 · 安全运营智能体

  1. 告警
  2. 证据
  3. 调查
  4. 验证

实验网出现可疑访问。先把它当成需要核对的案件，而不是立刻执行的指令。

把日志整理成可核对的证据。案件、证据和调查版本会留下来，方便回头看。

判断影响到哪里，再规划处置。对赛方 PCAP 只调查；封禁只在自有实验网进行。

nftables 封禁后，探针从 200 变为 403；回滚后再回到 200。这是自有环境验证，不代表生产效果。

核心开发者 · 控制面、调查状态机、模型网关与策略护栏 · 初赛阶段

个人探索 · Lives Assistant

围绕日程、信息整理和智能建议的个人应用。后端统一封装模型调用，通过 Docker 部署，用于日常管理与模型调用实践。

Vue / FastAPI / Docker · 个人 AI 应用实践

07 / 项目实现

这些作品如何实现。

回看这些项目，我的工作从梳理规则开始，经由建模与集成，落到可以核对的结果。ERP 是这条工作链路的完整实践，其他作品则补充了不同场景下的实现经验。

  1. 01

    业务规则与数据模型

    订单状态、批次库存、角色权限和冲正记录，分别对应不同项目里的业务约束。

  2. 02

    接口与设备集成

    点餐项目连接小程序、服务端、消息推送与后厨打印设备；气象平台通过统一 API 提供数据。

  3. 03

    验证与回溯

    ERP 使用验收场景核对流程，记账保留更正历史，安全运营实验验证执行与回滚。

08 / Justhat / 作品集

作品记录，持续更新。

业务系统、应用实践与技术探索。演示使用示意数据，不连接客户系统。