结论先行
如果你把网站帮助台理解成“公开表单 + 后台 ticket”，那你看到的只是最薄的一层。企业版真正做的是：用户先在帮助中心和知识库里自助检索，找不到再进入 livechat / chatbot，对话内容和访客资料最后才沉淀成 helpdesk.ticket。前端体验是一整条渐进式接力，而不是表单一提交就结束。
第一层：入口或表面动作
第一棒在帮助中心搜索。website_helpdesk_knowledge_base() 会根据 type/tag/date 等搜索条件走 request.website._search_with_fuzzy()；website_helpdesk_autocomplete() 则把知识库、FAQ 等结果以 JSON-RPC 形式返回前端自动补全。也就是说，网站入口先尝试把问题留在内容层解决，而不是急着制造工单。
第二层：真正的业务护栏
第二棒是知识内容跳转。website_helpdesk_knowledge 的 _get_knowledge_base_values() 与 access_helpdesk_knowledge_home() 会把团队绑定的 article 暴露为帮助台知识首页。这里的前端价值在于：用户从 helpdesk 入口进入 knowledge 时，仍保持 team 上下文，不是跳去一个完全脱节的知识系统。
第三层：状态落点与边界
第三棒才是 livechat 建票。chatbot_script_step._process_step_create_ticket() 会在达到 create_ticket 步骤时，先抽取访客邮箱/电话、整理会话历史，再调用 _prepare_ticket_values() 创建 helpdesk.ticket。description 里不仅有自由输入，还会拼上 discuss_channel.sudo()._get_channel_history()。这意味着“网站对话”不是丢掉上下文后再建单，而是直接把对话证据带进 ticket。
为什么这套设计更稳
另外 discuss_channel.execute_command_helpdesk() / execute_command_helpdesk_search() 也很说明问题：前端聊天窗口既能即时建单，也能先搜历史 ticket。聊天 UI 因而不是一个独立渠道，而是帮助中心、知识库与工单系统的中继站。
实战启示
这套前端链路最值得学的地方，是它把“减少工单量”和“保留求助上下文”同时做到了。搜索与知识库承担前置分流，livechat 承担交互式收集，ticket 承担正式跟进。你如果只留一个公开表单，不但转化粗暴，客服拿到的上下文也最差。企业版真正优化的，是用户在多个前端入口之间切换时，状态和内容不会断。
DISCUSSION
评论区