加载失败
Vela 是 YC W26 的初创公司，宣称用 AI 解决“复杂排程”，并在案例中展示为人力派遣公司处理候选人–客户面试、隐藏邮件线程、避免 Zoom 双重链接并声称十分钟完成上手。社区评论把这些案例分为“多渠道/流程集成”与“真正的组合优化难题”两类，指出后者通常需要约束建模和专门求解器。多位评论者提到工业实践常用 Gurobi、MiniZinc 等工具，学术界还用 GNN 与 RL，而 LLM agent 被视为把自然语言约束映射到求解器上的一个上层方法。总体建议创始团队在技术路径（求解器 vs LLM 层）和目标行业（如手术室、工业派遣、班次/rota、物流）之间做出明确取舍。
多位评论者认为 Vela 的“complex scheduling 已解决”表述有夸大成分，指出展示的案例并没有体现真正的组合优化难点。评论举例说许多场景只是单线性流程或多渠道整合（缓冲、偏好、选项等简单约束），而非需同时处理多个待决邀请的优先级与级联冲突。真实难点包括在有人已持有待定邀请时如何评估新邀约的远近、关系重要性和连锁影响，这类情形并非简单的时间匹配能解决。针对来自优化/规划背景的读者，广告语“Scheduling solved”被认为会造成误导，建议创始团队调整文案以免引发期望错配。
多位评论建议不要横向铺开市场，而应挑选一个用例深耕。具体案例包括：一家用近八年寻找排程解决方案的人力派遣公司，其协调员需管理数百场候选人–客户面试，要求不同邮件线程、独立 Zoom 链接并处理因改期导致的连锁重排；另有读者建议关注手术室/癌症治疗排程、工业派遣（药检与班次）或物流，这些垂直场景有明确的付费动机和复杂性。评论还引用 Deputy（专注 rota/班次调度）作为专注垂直并取得成功的先例，强调从具体边缘用例出发更容易形成产品护城河和快速赢单。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
多人强调排程本质是约束满足/组合优化问题，很多现实场景属于 NP-hard，需要用数学优化或专门算法来求解，而不是单靠简单规则。评论中提到的技术工具包括 Gurobi（商用优化求解器）和 MiniZinc（约束建模语言），并有人分享基于 MiniZinc 的 MCP server 与赛事排程实际经验，指出这些工具表达力强但对非技术用户门槛高。学术与工程方向还在用 GNN（图神经网络）和 RL（强化学习）去近似 NP/P-space 的调度策略；另有观点认为把 LLM 当作上层代理（LLM agent）来把自然语言约束转换为可求解模型，是一种可行但须与传统求解器结合的路径。
评论对 Vela 强调“接管现有流程、无需客户改动”和“十分钟上手”的定位既表示认同也提出疑问：如果如宣称那么容易上手，说明更多是在做工作流与多渠道集成而非普适的优化引擎。有人推测这更像是一种为特定企业做定制化排程系统的服务（agency 模式），而非标准化横向 SaaS；这会影响扩展性與定价策略。评论普遍建议团队要么明确何时调用传统求解器、何时由 LLM agent 处理沟通与规则，要么把资源集中在一两个有付费动力的垂直场景以建立护城河。
约束满足问题（Constraint Satisfaction Problem, CSP）: 用变量、取值域与约束来建模排程场景，现实里包含硬约束与软约束，建模难度和约束多样性决定了解法复杂性。
NP-hard: 描述许多组合排程问题的复杂度类别，意味着不存在已知的多项式时间通用解法，常需近似、启发式或专用求解器。
Gurobi（商用数学优化求解器）: 用于线性/整数规划与组合优化的商用求解器，工程与研究中常用来求解可精确建模的排程问题。
MiniZinc（约束建模语言）: 一种高层约束/优化建模语言，可将问题表达成模型并调用不同底层求解器，适合复杂约束但对非技术用户门槛较高。
LLM agent: 把大型语言模型作为代理层，用于理解自然语言约束、与用户或系统交互并驱动重排或将需求映射到求解器。
GNN（图神经网络）与 RL（强化学习）: 研究上常用来学习或近似调度策略，尤其在图结构与序列决策问题中用于构建可泛化的启发式或策略网络。