量潮云把内部反复打磨的工作方法做成软件产品，分两类：SaaS 管管理与协作的透明度，PaaS 管工程的质量与效率。
SaaS：把管理变透明¶
管理的摩擦大多来自「看不见」——谁在做什么、做到哪一步、产出放在哪。这一类产品的目标就是把这些显性化，让管理者和协作者都看得见。
知识工作云（qtcloud-work）。知识工作云服务，两个入口：命令行工具（Rust 写的 provider API 的 AI／脚本入口）与工作台（Flutter Web 图形界面）。把知识工作的过程与产出放在同一处沉淀。
管理后台（qtadmin）。公司内部全面管理工具，覆盖各业务线与职能领域。架构上分两层：业务域（带 qt 前缀，如招聘 qtrecurit、qtcloud、qtclass）面向具体业务线，内部复用并编排多个职能域；职能域（不带前缀，如人力资源 human、数字资产 asset、沟通连接 connect）是可复用的能力层，被所有业务域调用。两层分开，是因为业务在变、职能相对稳定——分开之后，新业务线的管理需求可以直接编排已有职能。
PaaS：把工程做快，让协同友好¶
这一类解决的是重复劳动和协同成本。
量潮 DevOps 云命令行工具（qtcloud-devops）。我们有一套打磨了五六年的标准化发布流程：发布前校验包配置里的版本号、确认 CHANGELOG 里有对应发布日志 → 打 Git tag（子模块带前缀）→ 发布 Release，描述直接取自发布日志 → Release 触发 CI/CD 自动构建分发。
这套流程我们曾封装成一个 AI Skill 自动执行，很快撞上两个问题：触发不稳定（发布被弄得一团糟，后续修复极耗注意力）和 Token 消耗巨大（AI 大量阅读无关信息并在出错时反复修补）。由此得出的判断是——自动化发布更适合同一个确定性的规则引擎，而不是一个概率性的 AI。于是把规则逐条固化成确定性代码，这个工具就此诞生。
它开源在 GitHub（quanttide/qtcloud-devops），目前 v0.4.x 内测。内测意味着它只服务我们自己的最佳实践、功能大量缺失；我们公开它是作为课堂案例和笔试题，不建议在生产环境直接使用。
code 命令。把基于 git submodule 的单仓管理实践也封装成了命令。DevOps 理论里的 Plan／Code／Build／Test／Release／Deploy／Observe／Monitor 八个环节，我们会沿着这条路线把相关技能逐条沉淀为命令。
契约驱动的研发流程。产品研发按三步走：清洗精炼真实业务数据并做知识建模 → 用半结构化数据当契约、驱动各端独立开发 → 新产生的数据回写工作档案。各端（命令行／服务端／客户端）只要认契约就可以各自开发，协同成本因此下降——这是「协同更友好」的来源。验收标准也是照着这条链写的：业务数据是否更精炼、更具备直接使用价值；业务代码是否具备可复用价值。
一句话¶
两类产品都从内部真实业务里长出来：SaaS 交付「看得见的管理」，PaaS 交付「做得快的工程」。