CycloidAI Reducer Engineering Platform

精密减速器的设计、计算与工程校核平台

面向减速器整机厂的研发负责人、总工与设计工程师

面向减速器整机厂研发团队

从参数、工况与公差出发，把设计计算、风险识别与评审依据
连成一条可追溯的工程流程

我们交付的不是一个数，是可复核的结论：判据、证据来源、参数版本， 以及一份写明「算不到什么」的清单。
摆线 / RV 现已可用；其它传动类型做不做、先做哪个， 由需求决定 —— 下面第三张卡说明我们怎么定。

进入摆线 / RV 工具 看我们怎么交付（含踩过的坑）

一个平台，逐步覆盖精密传动的工程问题

状态只用四种：现已可用 / 受限 Beta / 交互原型 / 规划中。 ⚠ 任何状态都带文字标签，不只靠颜色 —— 色盲、灰度打印、截图进文章， 这三种情况下只靠颜色的状态全部失效。

不同传动类型，同一套可追溯流程

这一节解释为什么这是一套平台，而不是几个互不相关的计算器。

  1. 定义产品结构与设计参数
  2. 导入工况、材料、公差与边界条件
  3. 运行专用计算内核
  4. 识别风险、失效项与证据缺口
  5. 输出带版本、依据与适用范围的工程结论

⚠ 第 4 步里的「证据缺口」不是凑数的：数据不足时显示 N/A，不默认判定通过 —— 那是这套流程与"跑一遍出个数"最根本的区别。

不是只给一个数字，而是说明这个数字为什么成立

① 每个结果都带运行清单。归一化后的输入、输入哈希、代码版本、 求解器版本、物理常数指纹、单位、UTC 时间戳 —— 半年后收到一份报告，能查出它是哪一版代码、哪一组输入算的。
② 每个物理量至少有一条不共用代码的验证路径。 我们为此付过代价：两条解算路径长期互证、偏差 0.3%， 但它们引用同一份几何代码，而那份代码的力臂公式从第一天起就漏了一项 —— 公式错了，两条路径一起错，偏差照样 0.3%。
③ 自检必须能失败。写完先造一个错样本喂给它，确认真的报红。 没验证过「能失败」的自检，等于一行注释。
④ 边界不替你改。参数越过物理边界时拒绝计算并说清为什么， 而不是悄悄拉回边界再算 —— 那样给出的是另一台机器的结果， 而它看起来完全正常。

这四条不是口号，都是能失败的检查：每次部署构建期跑一遍、上线后再打一遍真接口。 开发案例页写了我们踩过的坑 →

先用公开参数探索，再用真实数据做工程校核

⚠ 免费工具用于趋势分析与技术交流，不替代基于真实修形、公差、材料与 试验数据的工程放行。同一台现役机，本站按理想共轭齿廓给峰值齿载 215 N、 约 20 根齿吃力，而工程校核引擎给 270 N / 7 根齿 —— 而且本站偏在不保守那一侧。 这句话写在每个工具页顶部，CI 每次部署会抓下来比对，不一致直接构建失败。