購買注文書システムの業務フロー：注文書生成から入荷検収までの電子化
中文版はこちら → 采购订单（注文书）系统：从订单生成到到货验收的电子化流程 本文は、ある製造企業における購買注文システムの導入過程を整理したものです。実際のシステム名は POFlow（ピーオーフロー） で表しています。 一言で言えば：POFlow の購買注文書モジュールは、TPICS システムの Web 拡張（アドオン）です。購買注文書（注文書）の「生成 → 確認 → 承認 → 印刷/送信 → 入荷検収」という一連の業務を電子化し、従来の紙による運用を置き換えます。 1. 背景と位置づけ POFlow とは：独立した Web アプリケーションで、技術的には TPICS システムの「外部拡張（アドオン）」です。TPICS と同じ業務データベースを共有し、ログインアカウントと権限も TPICS のセキュリティ体系を再利用するため、業務担当者は新たにアカウントを作る必要がありません。 モジュールは注文書を新規作成しない：購買注文書は TPICS の MRP（所要量計画）によって自動生成されます。本モジュールはその注文書の後続処理（確認・承認・印刷・送信・入荷検収...
采购订单（注文书）系统：从订单生成到到货验收的电子化流程
日本語版はこちら → 購買注文書システムの業務フロー（日本語版） 本文整理自某制造企业内部的采购订单系统实施过程，实际系统名以 POFlow 指代。 一句话定位：POFlow 采购订单模块是 TPICS 系统的一个 Web 扩展（addon），它把采购订单（注文书）从「生成 → 确认 → 审批 → 打印/发送 → 到货验收」的整个业务链条做成了电子化流程，替代了过去的纸质流转。 1. 背景与定位 POFlow 是什么：一个独立的 Web 应用，在技术上是 TPICS 系统的「外挂扩展」，与 TPICS 共用同一套业务数据库，登录账号和权限也复用 TPICS 的安全体系——业务人员无需另行开账号。 模块不「新建」订单：采购订单由 TPICS 中的 MRP（物料需求计划）自动生成。本模块负责这些订单的后续处理：确认、审批、打印、发送和到货验收，而不是从零创建订单。 整个模块在系统内实际由三个相互衔接的功能组成一个整体：采购订单审批、打印订单与纳品书、到货验收。 1.1 系统定位图flowchart LR MRP["TPICS · MRP<...
MES 2026 年第 43 周工作小结
本周（10/19–10/24，合入 master 的非合并提交 77 条，非快进合并 1 次）主线是把 EOS 流程设计器做到「和 EOS 一致」，并让流程在上线前可模拟自测：周一到周六，mes-nwf 的设计器模型、XML 导出、表达式向导、模拟器轮番推进，周四合入 feature/eos-nwf-setup-wizard。文件改动集中在 mes-workflow（mes-nwf 311 个、eos-nwf-web 58 个），其次是 mes-security、mes-core、mes-process-interlock、mes-quartz、mes-process-card。 一、NWF XML 对齐 EOS设计器产出的流程定义要和 EOS 客户端生成的一致，本周把差异一条条收掉了： CustomizedBtns 输出位置对齐 EOS，置于 MultiWorkItemSet 之后、InformSetting 之前 EnableTerminate=false 时不再写出 TerminateConditionC / TerminateCondi...
有 AI 之后，人类的学习时间是否可以缩短了？
可以缩短，但缩短的是入门与检索时间，不是把「真正学会」压缩成捷径。 能缩短的部分 找答案、读文档、试错：以前要翻书、搜论坛、等同事，现在几分钟就能得到方向。 上手与模仿：写第一版代码、理解陌生概念、做练习题的反馈更快。 跨领域摸底：快速建立地图（有哪些概念、怎么连起来），少走冤枉路。 所以「从 0 到能干活」往往确实更快。 很难缩短的部分 长期记忆与熟练：不练、不自己做错题，知识留不住。 判断力：知道何时该信 AI、何时要怀疑、如何验证。 深度与迁移：能在新场景自己设计方案，而不是只会跟着提示改。 责任与品味：工程里的取舍、风格、边界，仍靠经验积累。 AI 像加速器：你踩油门更猛，但车还是你开；不会开的人开得再快也容易撞。 更准确的说法 目标 有 AI 后 「知道大概、能跑通」 明显更快 「考试/认证级熟练」 略快，仍靠练习 「专家级直觉」 几乎不缩短，甚至可能因过度依赖而变慢 结论有 AI 后，人类的学习时间线可以缩短，尤其是入门与效率；但若把「学会」理解成形成可靠能力，核心仍是练习、反思、验证。用得好是放大器；只抄答案，学得更浅、更慢。
同样写着 48GB，T480 和 MacBook、RTX Spark 差多少钱
手里这台是联想 ThinkPad T480（20L6Z3TGUS），CPU 是 i5-8250U。任务管理器里大约 48GB，拆开是两条：32GB（RMSA3330ME88HCF-3200）加 16GB（RMSA3300MH78HBF-2666），实际都跑在 2400。今天拿「同样 48GB」去对 MacBook Pro 和刚开卖的 RTX Spark 笔记本，比的是标价，不是跑分。 价格取 2026-10-17 能公开核对到的国内渠道。促销会变，下面每一行都标了出处。 三台机器 这台 T480 MacBook Pro 14（M5 Pro） Surface Laptop Ultra（RTX Spark） 内存 48GB DDR4-2400，两条可换（32+16） 48GB 统一内存，焊死 48GB LPDDR5X 统一内存，焊死 处理器 i5-8250U，4 核 8 线程，15W M5 Pro，公开在售的 48GB/1TB 是 15 核 CPU + 16 核 GPU RTX Spark N1X 满血，20 核 CPU，GPU 6144 CUDA ...
macOS 终端连接 Windows SSH 后崩溃
从 Mac 用系统自带「终端」执行 ssh liuhualiang@192.168.3.9 后，Terminal.app 在同一天崩溃了 5 次。崩溃的是 macOS 终端本身，不是本机 ssh，也不是 Windows 上的 OpenSSH 服务。 现象 时间 进程已运行 异常 13:42 约 26 分钟 EXC_BAD_ACCESS / SIGSEGV，Swift Observation 15:44 约 2 小时 EXC_BREAKPOINT / SIGTRAP，CoreGraphics 分配阴影样式时 malloc 元数据损坏 19:18 约 3.5 小时 EXC_BAD_ACCESS，画屏时 __CFStringCreateImmutableFunnel3 19:31 约 13 分钟 SIGBUS，Terminal 内部同一函数无限递归，栈被打穿 19:44 约 12 分钟 EXC_BAD_ACCESS / PAC，同样死在画屏创建字符串；坏指针里带有空格字节 0x20 进程都是 /System/Applica...
MES 2026 年第 42 周工作小结
本周（10/12–10/16，合入 master 的非合并提交 89 条，合并 7 次，含 PR #386、#284）主线是把 EOS 流程模块 mes-nwf 从 AI 起草做到可发布的图形设计器，并合入电厂小指标与手册 AI 问答。文件改动集中在 mes-workflow、mes-core、mes-indicator。 一、流程设计器（mes-nwf）周四合入 feature/mes-nwf，周五补了图形编辑和版本比对。同周还合入 feature/nwf-transition-props、feature/nwf-savegraph-allow-missing-entity、feature/nwf-test-bill-define。 新建 EOS NWF 流程模块：AI 起草、边标签、流程细化、多泳道布局，可还原原始布局 轻量图形编辑：ELK 自动布局、汇聚/分支模式、网格、对齐圈选、左右分隔 发布与版本：版本签发校验、历史版本、流程 XML 按属性分行比对 传递线属性编辑和条件表达式向导；设计器与预览里，校验列表点击可定位节点 测试单据字段...
Maven 项目还能像 Sysdeo 那样用 Tomcat 插件启动吗？Eclipse 与 Cursor 选型
早年用 Sysdeo Tomcat Plugin 管「普通 Java EE 工程」很顺手：指定本机 Tomcat、挂上 web 工程、工具栏启停。迁到 Maven、再迁到 Spring Boot / Cursor 之后，常会问三件事： Maven 项目还能不能像以前那样用 Tomcat 插件启动？ 现在的 Eclipse Tomcat Plugin（Sysdeo 后继）能不能管 Maven？ Cursor 里有没有类似插件管 Maven 项目启动？ 下面按结论 → 差异 → IDE 选型 → 实践建议说明。 结论 可以，但体验和旧「非 Maven Java EE + Sysdeo」不完全一样：Maven 负责依赖与打包，Tomcat 插件负责启动/部署，两者要配合，不能指望只点一下「启动 Tomcat」就自动搞定全部 classpath。 Eclipse Tomcat Plugin（Sysdeo 的维护分支）能管 Maven 项目，并支持 Maven classpath；复杂多模块工程更稳妥的是 m2e + m2e-wtp + WTP Servers。...
MES 2026 年第 41 周工作小结
本周（10/6–10/10，master 约 18 次提交）主线是 PI API（piapi64）Java 封装 与 实时库通讯完整性（Comm Int），并顺带统一 Jackson 时间格式、清理 IO 模型与本地开发文档。合入分支：copilot/add-java-wrapper-for-piapi64、feature/rtdb-comm-int。主力模块 mes-rtdb、mes-factory、mes-process-*。 一、PI API / piapi64 Java 封装（mes-rtdb-pi） 合入 copilot/add-java-wrapper-for-piapi64：JNA 对接 piapi64 原生库，经 RMI 对外提供快照等能力（mes-rtdb-pi / mes-rtdb-pi-core） 封装 pisn_getsnapshots 批量读快照；完善快照取数错误处理 支持 字符串点（string points）；补充 PI C API 参考与库加载测试文档 二、实时库通讯完整性 Comm Int（mes-r...
MES 2026 年第 40 周工作小结
本周（9/28–9/30，约 17 次提交）主线是 多应用拆分落地 与 RTDB / ISYS SDK，并修正 LIMS 位号、EOS 菜单 URL。合入分支主要包括：wip/tsdb-sdk-decompiled、feature/lims-tag-optional-sample-name、feat/mes-app。主力模块 mes-web、mes-factory、mes-rtdb、mes-security、mes-report。 一、实时库 / ISYS SDK（mes-rtdb） 合入 wip/tsdb-sdk-decompiled，沉淀 TSDB SDK 反编译参考 新增 ISYS SDK 接入：独立端口与上下文、Nginx 代理、监控相关配置与文档 完善 ISYS SDK 与多应用说明文档 二、多应用拆分与基础设施（mes-web / scripts） 应用拆分后 日志文件按应用拆分；补充 mes-utils / mes-chart / mes-message-eos 等依赖 Nginx 兼容历史...