洞察
场景怎么挑，第一个场景怎么跑通的
我们怎么挑场景
引擎不挑行业，但挑场景。判断一个环节值不值得结构化，我们看四条：
判断密度够不够高。 一天做三次的判断，交给人就好；一天做三百次的判断，人做不快也做不齐。
依据是不是可获得。 做这个判断需要的信息，能不能在决策发生的那一刻拿到。如果关键依据只存在于某个人的印象里，那第一步该做的是把它记下来，不是上引擎。
对错能不能被验证。 有些判断永远不知道对错——那种场景引擎帮不上忙，因为它没有办法改进。反过来，「三天后签收状态会告诉你当时分得对不对」这样的场景，就是理想的。
错了的代价清不清楚。 代价清楚，才能设计防御的强度；代价说不清的场景，往往是需求本身还没想明白。
已落地：物流报价对账
Flyto Agent 的首个验证场景，跑在飞驼自己的物流业务上，用的是真实的账单和真实的钱。
这件事原来有多难
承运商的报价，是给人读的，不是给系统读的。 首重续重、重量段、省市分档、生效日期、优先级、退件费、体积重比例——这些定价规则散落在一张张 Excel 表格和一张张调价通知的截图里，格式各家不同，同一家不同月份的版本还会变。
不结构化就没法自动算钱。于是对账只能靠人：把账单和报价并排放着，一行一行看。
更麻烦的是订单和包裹的错位：一个订单可能被拆成多个包裹，每个包裹有自己的运单号和计费重量，账单按包裹算，业务侧却习惯按订单看。这一层错位是人工对账最容易出错的地方。
过去这件事靠财务和运营逐行核对。慢、累、而且一定会漏——不是能力问题，是人眼在几万行数据面前的物理极限。
引擎现在做什么
把报价表读成结构。 抽取由一组分工明确的角色协作完成：负责抽取的一方读表，一个独立的校验环节检查结构本身是否成立——重量段有没有首尾相接、是否单调、单位对不对，然后由主导方判定通过还是重来。
输出直接对齐业务系统里已有的价格表结构。 抽出来的东西不是又一份没人能用的中间格式，而是直接就能拿去算钱的价格表——字段、单位、层级一一对应。中间多一层翻译，就多一层出错的概率。
模糊的地方不硬猜。 原表没写明白的部分，引擎给出推断值的同时会标记「不确定」，并附上原文片段和不确定的原因，交由上层决定。必要时它会直接向人提问，操作员的每一次答复都成对留档。
确定性的事情交给代码，不交给模型。 比如日期合法性校验（把不存在的 9 月 31 日纠正为 9 月 30 日）——一行解析加一张表就能定死的事，交给模型既浪费它的注意力，又可能漂移。
验收由独立角色完成。 我们实测发现，能力足够的主导方也会给自己盖章。所以「这次抽得对不对」必须由另一个不参与抽取的角色来判。
三方比对与差异归因。 账单、报价、实际计费三方逐条比对，差异不是「总数对不上」，而是直接定位到具体条目——是哪一单、哪个包裹、差在哪个规则上；再区分差异类型：是计费重量取整口径不一致，是区域分档判定不同，是报价版本用错了，还是这一单本来就该有的附加费。
我们在这个场景里学到的两件事
第一，收敛不等于正确。 系统完全可以收敛到一份自洽但错误的结果。我们真实遇到过：一次抽取把偏远地区的首重定成了 3 公斤，整张表内部逻辑自洽、所有结构校验都通过，而原表表头明写的是 1 公斤。结论是：只查结构不够，必须有一次对真值的确认。
第二，多轮的成本是一次性摊销的。 这条流水线真正的产物，不是「这一次的抽取结果」，而是为某一个具体组合调试收敛出来的那份可复用规则。第一次调通要花力气，之后同类的东西又快又便宜又确定。引擎的价值不在单次调用有多聪明，在于每一次调试都变成了下一次的资产。
为什么先做它
判断密集、规则复杂、错了有明确代价——这三条同时成立的场景不多见。而且它是我们自己的痛：每个月都要吃一遍，改进的动力不需要被说服。
正在铺开的场景
下面每一个场景，换的都只是对场景的描述。它们全部来自飞驼自己业务里真实的判断瓶颈——我们自己就是第一个客户。
履约决策
承运商分配：同一个目的地，不同承运商的时效、价格和当前时段的稳定性都不一样，选哪家是一个每天要做上万次的判断。
月度量级承诺的风险预警：与承运商约定的月度量级往往绑着价格阶梯，走不到承诺量意味着单价跳档。这件事的难点在于它要在月中就被预警，而不是月底结算时才发现——差一个百分点，一个月就是一笔明账。
经营与 ERP
补货、备货、库存健康度的判断。什么时候该补、补多少、哪些货正在变成呆滞——把这些从「盯报表的人」转移给「盯数据的引擎」，人只处理引擎标出来的异常。
销售与 CRM
线索分级、跟进时机、流失预警。销售团队里最好的那个人凭什么判断这条线索该先打——把那套判断结构化出来，变成团队的下限，而不是某个人的天赋。
财务结算
账款异常识别、开票合规检查。规则跑在前面，人处理例外。财务工作里大量的时间花在「核对没有问题的部分」上，这部分应该由机器完成。
广告投放
出价调整、素材更替的决策建议。把「盯盘」变成「审批」——引擎给出建议和依据，人决定要不要采纳，而不是一整天盯着后台等波动。
经营决策
把分散在各个系统里的经营信号收敛成结构化的判断建议。给管理层的应该是结论加依据，不是一堆需要自己解读的报表。
你的场景在不在列表里，不重要
上面这些是我们自己走过或正在走的路，不是能力边界。引擎不假设行业，我们也不假设你的行业。
如果你在读的过程中想到了自己业务里的某个环节——那个每天重复几百次、错了要过很久才知道、而且只有某几个人做得准的环节——那就是可以聊的起点。
我们会先做一次场景评估：这个场景值不值得结构化、从哪一步开始、大概需要什么条件。评估完，你再决定要不要往下走。