项目名称
食材，也有乡音——地域食材叫法互查助手
团队 / 作者
做了什么
同一种食材，换一座城市可能就换了名字。用户知道家乡怎么叫，却未必知道到了另一地该如何开口；相同的词，在不同地区也可能指向完全不同的水产。
我们做了一个以真实购买场景为核心的地域食材叫法互查工具。当前 Demo 聚焦水产和已经收录的试点地区，支持正向查询、反向辨认、同名歧义确认、相近商品推荐、单品资料和地方叫法贡献草稿。
百炼能力被接入到查询入口，而不是作为独立聊天框。用户可以直接说：
我从大连去广州，想买我们叫虾爬子的东西。
模型只把自然语言解析为结构化查询意图：
{
"mode": "forward",
"query": "虾爬子",
"source_region_text": "大连",
"target_region_text": "广州"
}系统随后用确定性的地区与食材数据库完成身份消歧和叫法转换，并把模型理解出的条件展示给用户确认。AI 不直接编造地方叫法；解析失败或信息不完整时，用户仍可回到原有下拉表单继续查询。
这让原本需要逐项选择地区、模式和名称的操作，变成一句自然语言即可发起，同时保留了专业数据库的可控性与可回归测试能力。
使用的工具 / 百炼能力 / 模型 / Skill
- 阿里云百炼文本模型：
qwen3.5-flash
- 百炼能力：自然语言理解、结构化 JSON 输出，用于识别查询模式、出发地、到达地与原始叫法
- 百炼 CLI：用于本地鉴权、模型能力验证与开发调试
- Agent Skills：
bailian-cli、bailian-protocol
- 产品运行时：浏览器前端 → 本地后端安全代理 → 百炼模型 → 现有确定性查询接口
- 安全边界：百炼凭据由 CLI 本机配置管理，只在后端进程中使用，不写入浏览器代码或 GitHub 仓库
关键命令：
bl auth status
bl model list --model qwen3.5-flash --output json
bl text chat --model qwen3.5-flash \
--system "只输出结构化查询 JSON" \
--message "我从大连去广州，想买我们叫虾爬子的东西" \
--output json
本地启动方式：
BAILIAN_CLI_PATH="$(command -v bl)" \
BAILIAN_NODE_PATH="$(command -v node)" \
BAILIAN_ROUTER_MODEL="qwen3.5-flash" \
python3 -m backend.server \
--port 8787 \
--ai-provider off \
--query-router-provider bailian-cli
python3 -m http.server 8766 --bind 127.0.0.1
访问：http://127.0.0.1:8766/mvp-web/
效果展示
演示流程：
- 用户输入一句带有出发地、目的地和家乡叫法的自然语言。
- 百炼模型生成结构化查询条件，页面邀请用户确认。
- 确认后进入现有查询结果，展示目标地区的可用叫法、歧义提示或近似商品。
- 打开单品页查看已核验资料；发现缺失时可留下本机贡献草稿。
在线体验已部署；同时保留公开仓库与可下载本地体验包。评委可直接体验真实的 qwen3.5-flash 调用。
项目链接（可选）
评委运行：
bl auth login --api-key YOUR_DASHSCOPE_API_KEY
python3 start_demo.py
示例输入：
我从大连去广州，想买我们叫虾爬子的东西。
体验包 SHA-256：d18f4a3423b01d493d9cb81bec9f223dab7e6870e839cc466a2d3449ec9a69f7
踩坑记录（可选）
这个项目最难的并不是让模型“给出一个答案”，而是区分三件容易混在一起的事：用户说了什么、这个词指向哪种商品、目标地区实际怎么叫。
我们最初也尝试过把学名或模型生成的名称直接放到结果中，但菜市场里的商品名、物种身份和地方俗称并不是简单的一一对应。最后采用了“AI 解析入口、数据库回答事实”的分工：百炼负责理解不规整的自然语言，确定性数据层负责地区映射、歧义和近似关系。这样既保留了一句话查询的便利，也不会把模型猜测升级成地方事实。
地域本身也不只有行政区划。语言社区、文化区与市场流通范围可能交叉，因此当前只承诺已收录的试点地区与水产数据，不宣称覆盖全国；未收录内容进入贡献或待核验流程。
项目名称
食材，也有乡音——地域食材叫法互查助手
团队 / 作者
做了什么
同一种食材，换一座城市可能就换了名字。用户知道家乡怎么叫，却未必知道到了另一地该如何开口；相同的词，在不同地区也可能指向完全不同的水产。
我们做了一个以真实购买场景为核心的地域食材叫法互查工具。当前 Demo 聚焦水产和已经收录的试点地区，支持正向查询、反向辨认、同名歧义确认、相近商品推荐、单品资料和地方叫法贡献草稿。
百炼能力被接入到查询入口，而不是作为独立聊天框。用户可以直接说：
模型只把自然语言解析为结构化查询意图：
{ "mode": "forward", "query": "虾爬子", "source_region_text": "大连", "target_region_text": "广州" }系统随后用确定性的地区与食材数据库完成身份消歧和叫法转换，并把模型理解出的条件展示给用户确认。AI 不直接编造地方叫法；解析失败或信息不完整时，用户仍可回到原有下拉表单继续查询。
这让原本需要逐项选择地区、模式和名称的操作，变成一句自然语言即可发起，同时保留了专业数据库的可控性与可回归测试能力。
使用的工具 / 百炼能力 / 模型 / Skill
qwen3.5-flashbailian-cli、bailian-protocol关键命令：
本地启动方式：
访问：
http://127.0.0.1:8766/mvp-web/效果展示
演示流程：
在线体验已部署；同时保留公开仓库与可下载本地体验包。评委可直接体验真实的
qwen3.5-flash调用。项目链接（可选）
评委运行：
示例输入：
体验包 SHA-256：
d18f4a3423b01d493d9cb81bec9f223dab7e6870e839cc466a2d3449ec9a69f7踩坑记录（可选）
这个项目最难的并不是让模型“给出一个答案”，而是区分三件容易混在一起的事：用户说了什么、这个词指向哪种商品、目标地区实际怎么叫。
我们最初也尝试过把学名或模型生成的名称直接放到结果中，但菜市场里的商品名、物种身份和地方俗称并不是简单的一一对应。最后采用了“AI 解析入口、数据库回答事实”的分工：百炼负责理解不规整的自然语言，确定性数据层负责地区映射、歧义和近似关系。这样既保留了一句话查询的便利，也不会把模型猜测升级成地方事实。
地域本身也不只有行政区划。语言社区、文化区与市场流通范围可能交叉，因此当前只承诺已收录的试点地区与水产数据，不宣称覆盖全国；未收录内容进入贡献或待核验流程。