同一项目连续生成两次结果
项目入口 → 参数锁定 → 生成 #1 / #2 → 详情记录 → 确认签发
连续操作产生两条独立记录，而不是覆盖上一次文件。项目列表的下发入口绑定客户和项目参数，生成后可以从待确认记录继续，减少手动填写和结果归属错误。
Appearance
Skip to content
跳到项目内容任务编排与确认执行01 / 01 Node 网关与 Python Worker 各自承担平台交互和工具处理，Web 后台与飞书消息共享操作记录；签发从待确认记录继续。
商业系统/阶段部署
飞书业务自动化
从消息指令到文件处理与授权记录
01
核心业务
飞书机器人接收文本、附件和指令，Node.js 网关负责消息交互，Python Worker 封装文件处理与既有签名工具。业务后来扩展到项目列表、授权记录和签发确认，聊天入口与后台共享处理结果。
文件已经生成和许可证已经签发是不同状态。项目参数要固定，每次操作要保留独立记录，待确认任务要有明确入口；网关也不能把附件、密码或工具输出直接当作可公开日志。
- 协作入口
- 文本、附件与回复由飞书开放平台承接，结果可以通过消息或后台获取。
- 业务编排
- 客户和项目参数从项目入口绑定，生成记录与签发确认分别管理。
- 工具执行
- Python 复用已有文件与授权工具，Node 负责调用、状态和文件回传。
02
技术栈
- 消息网关
- TypeScript · Node.js · 飞书开放平台
- 处理 Worker
- Python · 签名 / 文件处理封装
- 后台与部署
- Web 管理界面 · Nginx · systemd
- 业务控制
- 参数锁定 · 独立记录 · 确认签发
03
系统架构与部署
平台网关
Node.js / TypeScript / 飞书 API接收指令、下载附件、组织参数、上传结果和回复消息。
工具 Worker
Python / 签名工具封装执行文件处理与签名工具，不把平台交互逻辑复制进 Python。
业务后台
Web / systemd / Nginx展示项目和独立操作记录，待确认记录进入签发流程。
04
核心业务链路
聊天附件处理并回传
消息 / 附件 → 校验 → Worker → 结果文件 → 上传与回复
网关负责接入与回传，Worker 负责既有工具执行。输入、生成结果和业务状态分别管理，处理过程控制附件内存使用，日志不输出密码等敏感参数。
05
关键机制与取舍
跨语言复用以职责为边界
飞书交互适合 Node SDK，既有签名工具在 Python。将工具重写或在两边都维护业务状态会增加一致性成本。
Node 保存消息和后台交互合同，Python 对工具参数和文件执行进行封装。接口返回可解释的结果与状态，业务记录由编排端统一管理。
平台扩展和工具升级可以分别验证，减少跨语言重复实现。
项目参数与生成记录共同约束操作
重复输入客户参数容易发生误签发；连续生成如果复用一个记录槽，历史结果不可追溯。
项目入口锁定关键参数，每次生成创建独立记录，确认阶段引用具体待确认结果。浏览器验证覆盖创建项目、连续生成与详情跳转。
操作结果可以追溯到项目和单次记录，用户不用凭文件名判断哪次生成可以签发。
06
实践成果与验证
Node + Python
工具与平台协作
网关、后台与工具 Worker 按职责连接。
#1 / #2
独立操作记录
同项目连续生成保留两条结果，待确认记录可继续签发。
消息 + Web
两个业务入口
附件处理与项目管理共享服务端操作状态。
- 机器人从文件处理入口扩展为项目化业务操作，覆盖参数绑定、结果回传和确认流程。
- 敏感参数处理与记录归属纳入工程设计，业务操作可以在消息和后台之间衔接。
继续浏览
别急，先让缓存热一下。