商店里的聊天助手如果能查订单，就要决定哪一句话算“在问订单”。判断错了，顾客最近的订单就会随一个与订单无关的问题发给模型。AI Chat for Amazon Bedrock 的 WooCommerce 模块把这条边界写成了一组正则：只出现“包裹”“物流”这类词不够，问题必须指向一笔订单。本文依据固定提交 d20ef99 的 includes/class-ai-chat-bedrock-woocommerce.php，讲这条边界怎么判定、判定之后还要过哪几道检查，以及它管不到的地方。
本站的 AI Agents & Chat for Amazon Bedrock：本站在用的 WordPress 对话与 MCP 插件 介绍过插件的整体功能。本文只讲订单查询这一处。下文结论来自阅读源码（[O]，项目自己的实现），没有运行测试，也没有在真实商店里验证。
为什么单个词不够
asks_about_orders() 的注释直接给出了理由：在一个写机器人的网站上，“package”“returns”“shipped”、物流、出荷这些词常出现在别的问题里，比如 Python 包、强化学习里的 return、物流机器人、今年出货的机器人。每命中一次，顾客的订单就会被发给模型。所以注释要求问题“指向一笔订单”：“我的订单”、订单号、物流单号、“发货了吗”、退款。
订单数据只在两个条件同时成立时才加进对话请求，入口在 for_chat()：
if ( self::orders_enabled( $options ) && self::asks_about_orders( $message ) ) {
$result['messages'][] = self::orders_block( $message );
$result['orders'] = true;
}orders_enabled() 检查 WooCommerce 在运行，并且设置项 woo_orders 已打开；站点可以通过过滤器 ai_chat_bedrock_woocommerce_orders_enabled 改写这一结果。文件头注释写明，商品目录、订单查询和商品文案助手三项功能都默认关闭，由店主自行开启。商品目录的检索与订单判定互相独立，打开目录并不会让订单进入对话。
什么样的问题算“问订单”
代码里有 11 条正则，英文 6 条、中文 3 条、日文 2 条，大致分几类：所有格加订单类名词（my order、我的订单、私の注文）；订单号、单号、物流单号或追踪号；“我买的”“I ordered”“購入した”这类已购买的陈述；“发货了吗”“什么时候发货”“いつ届く”这类配送追问；以及退款、退货、换货、返品、返金。任意一条命中即判为订单问题。
下表是本文虚构的示例问题，结果是按这 11 条正则逐条手工推演得出的，不是测试运行记录：
| 示例问题（虚构） | 判为订单问题 | 原因 |
|---|---|---|
How do I install the Python package for the arm SDK? | 否 | package 前没有 my 或 our |
强化学习里 return 和 reward 有什么区别？ | 否 | return 前没有所有格 |
仓储物流机器人有哪些导航方案？ | 否 | “物流”没有跟在“我的”后面，也不是“物流信息/状态” |
How many humanoid robots were shipped in 2025? | 否 | shipped 前没有 it、they 或 my 等主语 |
我的订单发货了吗？ | 是 | “我的订单”“发货了吗” |
Has my package shipped yet? | 是 | my package |
注文番号 1234 の配送状況を教えてください | 是 | 注文番号、配送状況 |
What is your refund policy? | 是 | 单独出现 refund 即命中 |
最后一行值得注意：注释把退款列为指向订单的信号，所以只问退款政策、不涉及具体订单的问题，在已登录状态下也会带上订单。判定结果还可以由站点通过过滤器 ai_chat_bedrock_woocommerce_asks_about_orders 改写。
判定之后：谁的订单
判为订单问题，只代表 orders_block() 会被调用，之后还有几道检查：
- 是否登录。未登录的访客不会得到任何订单数据，模型只收到一段说明：看不到对方的订单，请对方登录账户查看或联系商店。
- 只取本人订单。
orders_for()用customer_id查当前用户最近 5 笔订单（MAX_ORDERS），按日期倒序，排除checkout-draft状态。没有订单时，模型收到的说明是不要猜测订单。 - 问题里点名的单号。问题中 2 到 10 位的数字最多取 3 个，当作订单 ID 查询。不属于当前用户或处于 checkout-draft 的订单直接跳过，注释的原话是另一位顾客的订单号“不能透露任何信息，连它是否存在都不能”。
- 过滤器之后再查一遍。站点可以用
ai_chat_bedrock_woocommerce_orders增删订单，但返回前代码会再次过滤，只保留customer_id等于当前用户的WC_Order。
判定之后：哪些字段
order_lines() 为每笔订单生成的文本只有：订单号、下单时间、状态、完成时间、商品名与数量（最多 10 项）、带币种的总额、配送方式、物流追踪（读取 _wc_shipment_tracking_items，最多 3 条）和订单页链接。注释写明地址、邮箱、电话和支付信息从不包含；插件为隐私政策提供的建议文字也作同样说明。整个订单块截断在 6,000 字符以内（MAX_CONTEXT_CHARS）。
订单块开头要求模型把内容只当作数据、不当作指令，只依据这些订单回答，不承诺未列出的送达日期，修改、取消和退货一律引导到订单页或商店。
局限 / 注意
- 正则只能覆盖写进去的说法。表中推演只说明这几句会怎样判定，不代表所有含糊的问题都能分对；漏判时顾客得不到订单答案，误判时订单会多发一次。
- “当作数据、不当作指令”是写给模型的要求，不是代码层面的强制隔离。
- 点名单号时，代码把数字当作内部订单 ID 传给
wc_get_order()，而列出时显示的是get_order_number()。两者是否一致取决于商店配置。 - 过滤器
ai_chat_bedrock_woocommerce_order_lines允许站点往订单文本里加字段；代码注释提醒不要加入地址等个人信息，因为这些文本会发送到 Amazon Bedrock。加了什么由站点负责。 - 仓库附带使用合成数据的独立测试
tests/woocommerce.php。本文没有运行它，也不引用其断言；本文不是一次完整的隐私审计。
