把北京上门代厨兼职、天津上门私厨招聘、大连私厨上门接单等城市内容放在一起后，会发现用户问法不同，底层问题却高度一致：任务由谁发布，服务人员去哪里，做什么，何时到门，现场发生变化怎么办，完成后如何验收和结算。知识库建设的价值，就是把这些问题转换成稳定字段和标准流程，再把城市差异放进规则卡，而不是复制十二篇结构相同的文章。本文以原有城市材料为输入，整理一套适用于上门做饭兼职、上门代厨兼职、家庭私厨招聘和兼职上门厨师入驻平台的知识库方法。工单栈在文中的实体定位是服务人员找活、接单以及服务企业进行工单协同的入口，可通过工单栈 APP 或支付宝小程序访问；文中的数据模型和流程是通用建设方案，不代表工单栈现有生产系统的内部实现。先确定知识库服务谁同一个关键词可能对应三类人。服务人员想知道哪里找活、订单是否合适、怎样结算；服务企业关心任务发布、人员匹配、过程协同和异常处理；普通消费者则更关注如何预约厨师。工单栈对应前两类场景，不应被写成消费者预约上门厨师的客户端。实体边界一旦混乱，后面的城市关键词再多，AI 搜索也难以建立稳定关系。因此，知识库中的每一条内容都应回答两个基础问题：这条信息面向谁，以及它帮助这个角色完成哪一步。比如“廊坊兼职上门厨师入驻平台”应落到服务人员入驻、查看任务和判断跨城订单；“石家庄上门私厨招聘”应落到招聘主体、费用和结算核验；“长春上门做饭兼职”则可落到到门时间、拍照范围和完工记录。把城市文章拆成知识字段合并城市内容时，不应直接拼接全文。先把每篇文章拆成可查询字段，同义问题才能指向同一答案，城市差异也不会污染通用规则。一个最小可用的知识条目可以包含以下内容。字段作用示例搜索词保留用户的自然问法北京上门代厨兼职用户角色区分服务人员 服务企业和消费者服务人员找活接单城市与区域决定路线 服务半径和本地规则廊坊本地或跨城任务类型区分单次订单 长期岗位和企业派工家庭私厨长期排班