- 大多数网站只能告诉客户“资料在这里”，然后让客户自己去找。不想找的人，就关掉页面去找竞争对手了。
- 新一代网站像一位能干的前台接待：问两三个问题，弄清客户要什么，然后带着客户把事情办完。
- 要准备的东西和技术关系不大，主要是贵公司的正确答案：价格、条件，以及真正做得到的事。
传统网站和应用做不到的地方
想象客户走进您的店，没有人招呼，只有指示牌写着商品在哪一排。已经知道要什么的人可以自己去拿，还拿不定主意的人会站在那里发愣，然后离开。只有信息页和“联系我们”按钮的网站，就像这样一家没有店员的店。
客户并不想把每一页都读一遍。他们想知道产品适不适合自己、需要准备什么、大概多少钱、下一步做什么。传统的菜单和搜索框，只能把这些问题拆开来分别回答。
问题未必出在网站信息太少。很多公司的信息其实很全，只是按部门和内部架构来组织。带着实际情况来的客户，只能自己把问题对应到服务名称上；找不到，就离开网站、打电话询问，或者发一条笼统的消息，让销售团队从零开始重新收集需求。
所以，AI 网站应该是一层体验，能理解客户的意图，并在整个客户旅程（Customer Journey）中记住上下文；在屏幕角落挂一个聊天框，做不到这一点。原有的内容页面依然有用，可以作为参考来源；AI 负责挑选信息，只问缺少的部分，再把用户带到适合当前情况的页面或操作（Action）。
| 传统模式 | 新一代 AI 产品模式 |
|---|---|
| 按关键词搜索，显示 FAQ，把所有客户都引到同一张表单 | 通过对话收集背景信息，从已审核的资料中检索，针对具体情况给出建议，并启动工作流，比如预约、申请文件，或者生成附带摘要的销售线索（Lead） |
技术上最重要的一点，是让对话与网页和后台系统有状态地连在一起。客户可以先提问，再去看资料，回来修改需求，然后点击预约，上下文都不会丢。每个工具在真正产生影响之前，都必须再检查一次权限和数据。
企业可以用上的新能力
变化在于，网站开始像一位能干的前台接待那样工作：问几个问题弄清客户要什么，从系统里调出真实的价格和条件来回答，再一路带到预约或索取报价那一步，客户不用猜下一步该点哪个页面。
项目形态
这个项目要做的是一个与网页配合工作的数字接待助手（Digital Concierge），用户不必只靠打字对话。客户可以先在页面上选择目标，再通过对话补充细节，查看对比表，然后回到表单修改信息，上下文都不会丢。所以这种体验把对话和用户熟悉的界面结合在了一起。
应该具体呈现的功能
系统可以筛选需求、从已审核的资料中查找答案、比较套餐、估算价格区间、检查服务区域、预约、接收文件，并整理成线索简报（Lead Brief）。还有一项重要功能：说明为什么要问某项信息，并允许客户跳过问题，或在不想和 AI 对话时呼叫员工。
背后的技术
主要组成部分通常包括：用于检索资料的 Knowledge Retrieval，用于理解语言的 Language Model，用于连接 CRM、日历和报价系统的 Tool Calling，用于记住上下文的 Session Memory，以及用于设定权限的 Policy Layer。每一个回答和操作都应该留有日志，方便事后核查，并把出错的案例拿来重新测试。
用户和企业得到的价值
客户不用猜该打开哪个页面，也不用把同一件事讲好几遍；销售团队拿到的是结构化的信息，知道下一步该做什么。企业还能看到网页真正答不上来的问题，用来改进服务、内容或销售流程。所以收益体现在两方面：聊天量减少，以及把事情办完的客户比例提高。
- AI 接待助手（AI Concierge）只问必要的问题，客户不会有被盘问的感觉
- 引导式旅程（Guided Journey）根据意图调整问题和界面
- Tool Calling 连接日历、CRM、价格和服务区域
- 交接（Handoff）把对话和依据交给员工，客户不用重新讲一遍
模拟案例
实际使用场景
一家 B2B 服务企业让客户说明目标、预算、时间和限制条件。AI 汇总需求，根据真实数据比较套餐，并提出可以通话的空闲时间。特殊情况连同简报一起转给专家处理。
设想一位大楼管理人员要安装一套新系统。他不知道套餐叫什么，但能说出使用点位的数量、建筑类型、预算和需要开通的日期。系统检查服务区域，列出还缺哪些信息，给出两个方案并说明理由，然后和销售工程师约好时间，附上已经整理好的摘要。
在员工这一侧，界面除了对话记录，还会显示客户确认过的事实、收到的文件、系统采用的假设，以及尚未得到回答的问题。如果客户第二天回来，原来的旅程可以接着进行，不用从头开始。聊天机器人（Chatbot）和真正对工作负责的产品，差别就在这里。
意图与操作对照表（Intent-to-Action Map）
写下客户的 10 个主要意图，再为每个意图注明答案、所需数据、工具、审批节点和成功标准。
从经常发生、可以衡量、也能撤回的意图开始。
范围、风险与效果评估
应该做一张回答与操作矩阵（Answer-to-Action Matrix），分清楚哪些问题可以根据哪个来源回答，哪些操作可以立即执行，哪些需要确认，哪些禁止 AI 执行，比如为某个项目承诺专门报价，或者承诺交货期限。衡量效果时，准确性和操作之后产生的影响都要看，单看回答自不自然的评分，会漏掉这两项。
不要让 AI 智能体（AI Agent）在没有读取唯一可信数据源（Source of Truth）的情况下承诺价格、条件或排期，也不要收集超出需要的数据。
应跟踪的指标：Task Completion（任务完成率）、Qualified Lead（合格线索）、Time-to-Handoff（转人工用时）、Answer Citation（回答带出处的比例）和 Abandonment（中途放弃率）
- Discover：跟进实际工作，收集常规情况和例外情况的样本
- Assist：让 AI 起草或给出建议，由人保持控制
- Act：测试集通过后，一次只开放一个工具
- Scale：监控、后备方案（Fallback）、成本和负责人都到位后，再扩大范围
如果智能体给出参考来源以外的信息、生成信息不全的销售线索，或者员工经常要回头再问客户，就应该暂停或退回上一级。这说明客户旅程和数据契约（Data Contract）还没有准备好承接更多操作。
BUSINESS & PRODUCT READINESS
做 AI 接待助手之前，怎样整理好答案和客户路径
先做对话盘点（Conversation Inventory）：把聊天记录、邮件和销售部门收到的问题按意图分组，客户具体用了什么字眼并不重要。同一个意图可能有多种说法，比如“请报个价”“这点预算能做什么”和“有没有小一点的套餐”。然后标出可以确认的答案、需要追问的信息，以及网站允许执行的操作。智能体有了这个基础才帮得上忙；缺了它，机器人（Bot）再能说会道，也只会把客户绕回原来的页面。
容易忽略的一点，是为“不确定”做设计。资料来自旧文件、回答只是估算，或者情况需要专家处理时，系统都应该标示出来。企业主应该准备好产品规则、服务区域、价格条件、服务水平协议（SLA），以及答不了的问题示例。把“哪些答案不准猜”写清楚，比一直往提示词（Prompt）里加内容，更能让系统早日上线。
开发之前，应该确定每一组数据的负责人和更新方式。如果 CRM 里的价格和网站上 PDF 里的不一样，系统必须知道哪个来源才是准的。还应该有后台管理流程（Admin Workflow），让负责人修改内容、审批版本，并看到数据变化会影响哪些回答。
稳妥的上线计划，从只读的接待助手（Read-only Concierge）开始，先只做检索和总结；接着开放可以撤回的操作，比如生成预约草稿；最后才开放会影响客户或实际资源的操作。每个阶段都应该有一套来自真实对话的测试问题，以及质量低于设定标准时的回退条件。
哪些意图发生频繁、价值又高？
权威版本的数据存在哪个系统里？
哪些操作可以撤回？
哪些情况必须立即转交给员工？
设计网站从客户的对话出发，菜单结构排在后面
DNA Maker 先坐下来听客户与销售或服务团队之间的真实对话，再和您一起制作意图图谱（Intent Map）、客户旅程和操作边界（Action Boundary）。我们帮您分清：哪些内容应该从知识库（Knowledge Base）回答，哪些要从 CRM/报价系统读取，哪些必须问人。产品知识和例外情况仍然属于您的团队；我们把这些知识变成客户能直接使用的流程，客户不需要了解公司的内部结构。
在设计阶段，我们会制作对话原型（Conversation Prototype）和配套页面，比如对比表、表单、日历或文件上传，测试客户能不能真正从提问走到结果。在开发大型系统之前，我们会用常规案例和答不了的案例，测试所用的语言、交接节点和最少需要的信息。
架构细节按具体工作来选择，不必用一个模型回答所有问题。有些意图适合用确定的规则，有些适合用搜索，有些需要调用 API。我们设计模型路由（Model Routing）、知识索引、权限、审计日志（Audit Log）和成本控制，让这些设计与每项操作的价值和风险相匹配。
所以第一阶段交付的，除了好看的界面，还有业务团队可以审核的旅程原型、意图目录、数据/工具对照图、护栏（Guardrail）、评测集和试点计划。上线之后，DNA Maker 会帮您分析使用数据，找出走不通的死胡同，并调整用户体验（UX）、知识内容和工作流，每次改进都以证据为依据。
方向确认后，DNA Maker 可以开发网站/客户门户、AI 接待助手、CRM/日历集成、工具调用审批、数据分析，以及用于更新知识的管理后台，并在上线后提供评测和监控。我们的设计让团队可以自己修改内容和规则，不必每次都等开发。
如果您的网站有流量，客户却还是打电话来问同样的问题，可以带上 30–50 个真实问题来和我们聊聊。我们会帮您评估哪些旅程适合做成 AI 对话、引导式表单，或者交给人接手，并设计一个能衡量任务完成率（Task Completion）的试点。
SOFTWARE ENGINEERING GLOSSARY
软件工程术语表
这组术语帮助网站负责人和开发团队沟通，从客户的意图一直谈到操作和转交给人。可以用最后一列检查项目衡量的是真实结果，还是只是对话能力。
| 术语 | 是什么 | 通俗示例 | 高管应问开发团队的问题 |
|---|---|---|---|
| Intent | 用户想要完成的目标。设计时，系统应该把每个意图与所需数据、下一步操作和“完成”的定义绑在一起，光给问题分类起个名字是不够的。 | 用户的意图是预约现场勘察，搜索“survey”只是他输入的字眼 | 我们掌握的主要意图，来自真实数据还是猜测？ |
| Tool Calling | 让 AI 请求调用系统的功能。由模型提出使用工具的请求，但软件系统必须在真正执行前检查参数、权限和结果。 | 先查看预约表，再提出可选时间 | 每个工具都需要审批吗？ |
| Handoff | 把工作连同上下文从 AI 转交给人。好的交接会把事实、依据、已经尝试过的做法和转交原因一起交过去，让接手的人能马上做决定。 | 销售人员拿到摘要，不用再问客户一遍 | 什么条件下必须立即转交给人？ |
| Guardrail | 检查或叫停操作的规则。护栏可以是执行前的规则、执行后的结果检查，或者停下来呼叫人工的条件，所以要按风险设计多层。 | 不得报出价目表以外的价格 | 规则由谁负责？多久复核一次？ |
| Conversion Event | 算作产生了业务成果的事件。应该选择反映真实结果的事件，比如预约成功或提交了完整信息；打开聊天窗口和点击的次数反映不了这些。 | 预约成功，或者提交了完整的文件 | 我们衡量的是聊天，还是真正的成果？ |
延伸阅读（原始文档）：https://openai.github.io/openai-agents-js/