克运业务助手

要解决什么问题

在克运相关业务里，同一个请求往往会跨多个系统数据：运价、船期、船东要求、订单、费用、应收逾期、客户档案。如果让通用对话直接回答，很容易出现两类问题：一是把费用明细当成订单列表返回，把 ETD 说成实际离港，或用空匹配推断“该船东没有规则”；二是绕过权限上下文，把公司 ID、数值外键或未经确认的报价写进业务记录。

克运技能 的目标不是泛泛问答，而是把上述业务拆成可审计的脚本工作流：先用带签名上下文的标准接口取数，再按字段与权限边界展示，最后只在用户明确确认后保存。

核心能力

• 运价与预订：保留有状态的费率选择，便于跨轮次审计；报价不会自动写成 op.freight 中的应收/应付费用。订单信息缺失时只追问，不根据费率反推客户、箱量、货物、收发货人或客服/销售。
• 船期查询：优先使用 POL/POD、船名航次或承运人加 ETD 范围；执行 scripts/keyun-sailing.mjs listfilter 与 query，只汇总承运人、船名/航次、起运/目的港、ETA、ETD、中转天数与经停港。
• 船东特殊要求：走 Booking 知识库匹配 type=cr、moduletype=BK，不使用旧 AI 审计流程；条件不足时会明确询问是查看全部规则，还是补充港口、航线、货物或 HS Code 后精确匹配。
• 数据列表与详情：按“结果主体”选择模型：订单、费用、发票、客户、海运、报关、空运、汽运、铁路各自有独立 list/get 边界；列表前先运行 scripts/keyun-dataform.mjs listfilter，日期未指定时使用业务日期的近六个自然月范围。
• 完整订单视图：通过订单 ID、编号、主单或分单拉取关联海运、报关、空运、陆运、集装箱与费用数据；集装箱只作为订单子表加载，不提供独立命令。
• 应收逾期：按会计期间生成快照查询，历史月份使用 historydate；不实时重算，也不把空结果解释为“客户没有应收”。
• 客户分析：对名称或名片先分析后录入；自动生成英文代码与本地简称等标识字段，并在结论中区分系统事实、公开事实与 AI 推断。

适用边界

所有列表与详情调用都依赖已签名用户上下文和现有控制器权限，技能不会硬编码公司 ID 或绕过空/禁止结果。展示层优先使用查找文本，不暴露数值外键。ETD 只表示预计离港；空匹配不代表承运人无规则，也不代表客户无应收。保存动作只发生在用户确认完整订单并明确接受相关要求之后。