现在很多 AI 产品有一个共同问题：
答案给得很快，但依据藏得很深。
用户问一句话，页面上马上出现一段完整回答。语气流畅，结构清楚，看起来像已经把问题解决了。
但用户真正想知道的，往往不是“答案是什么”。
而是：
它为什么这么说？ 依据来自哪里？ 有没有不确定的地方？ 哪些内容需要我再确认？ 这个建议能不能直接执行？
如果前端只显示一个漂亮答案框，用户就会被迫相信它。
这不应该是 AI 产品的最终形态。
Google Search 这次更新很值得前端产品关注。Google 官方称，新的 AI 搜索能力会把更强模型带进 Search，并让用户可以通过提问使用 Agent 能力。换句话说，AI 正在从“搜索结果旁边的辅助总结”，变成更靠前的信息入口。
入口越靠前，依据越不能消失。
这对前端提出了一个新要求：AI 产品不能只设计 Answer UI，还要设计 Evidence UI。
什么意思？
不是只展示回答，而是展示回答背后的证据、来源、假设和风险。
比如用户问：
“这个方案适合我们团队吗？”
AI 给出：
“适合，但建议先从小规模试点开始。”
这句话本身不够。
前端应该把它拆成几个区域：
结论。 依据。 不确定点。 需要用户确认的问题。 下一步操作。
一个简单的数据结构可以这样设计：
type AIAnswer = {
conclusion: string;
confidence: "low" | "medium" | "high";
evidence: EvidenceItem[];
assumptions: string[];
risks: string[];
followUpQuestions: string[];
};
type EvidenceItem = {
id: string;
sourceType: "document" | "web" | "user_input" | "system_data";
title: string;
excerpt: string;
relevance: "low" | "medium" | "high";
};
前端渲染时，不要只显示 conclusion。
function AIAnswerPanel({ answer }: { answer: AIAnswer }) {
return (
<section>
<h2>结论</h2>
<p>{answer.conclusion}</p>
<h3>依据</h3>
{answer.evidence.map(item => (
<div key={item.id}>
<strong>{item.title}</strong>
<p>{item.excerpt}</p>
</div>
))}
<h3>需要确认</h3>
<ul>
{answer.followUpQuestions.map(q => (
<li key={q}>{q}</li>
))}
</ul>
</section>
);
}
这段 UI 的价值，不是让页面更复杂。
而是让用户知道：AI 不是凭空给结论。
如果 AI 的依据来自用户输入，就显示“基于你提供的信息”。 如果来自文档，就显示文档片段。 如果来自网络，就提示来源和时间。 如果只是模型推断，就明确标注“推测”。
很多 AI 产品现在缺的就是这个分层。
所有内容都混成一段话，用户不知道哪些是事实，哪些是建议，哪些是推断。
这会带来很大的产品风险。
尤其是这些场景：
医疗建议。 法律草稿。 金融分析。 代码修改。 客户回复。 招聘筛选。 合同摘要。 企业内部决策。
AI 说得越像真的，前端越要把依据拆出来。
Evidence UI 至少应该包含四个组件。
第一，SourceCard。
告诉用户信息来自哪里。
type SourceCardProps = {
title: string;
type: "uploaded_file" | "web_page" | "internal_note" | "user_prompt";
time?: string;
excerpt: string;
relevance: "low" | "medium" | "high";
};
第二，RiskBanner。
不要只用颜色吓人。更好的做法是用自然语言说明：
“该结论主要基于你提供的资料。” “该建议缺少预算信息，需补充后再判断。” “该内容涉及外部事实，建议核查来源。”
type RiskBannerProps = {
level: "info" | "warning" | "danger";
message: string;
};
第三，AssumptionList。
把 AI 默认的前提列出来。
type AssumptionListProps = {
assumptions: string[];
};
第四，ConfirmAction。
如果 AI 给出的是建议，用户可以直接参考。 如果 AI 触发的是动作，必须确认。
type ConfirmActionProps = {
actionName: string;
riskLevel: "low" | "medium" | "high";
onConfirm: () => void;
onCancel: () => void;
};
组合起来可以是这样：
function EvidenceAnswerView({ answer }: { answer: AIAnswer }) {
return (
<div>
<AnswerSummary conclusion={answer.conclusion} confidence={answer.confidence} />
<EvidenceList items={answer.evidence} />
<AssumptionList assumptions={answer.assumptions} />
<RiskSection risks={answer.risks} />
<FollowUpQuestions questions={answer.followUpQuestions} />
</div>
);
}
这比一个纯答案框要靠谱得多。
OpenAI Codex 这种 agentic coding 工具，也说明 AI 正在从“给建议”走向“参与执行”。官方介绍里，Codex 支持多 Agent 工作流、worktrees 和 cloud environments。
越靠近执行，越需要前端把依据和风险亮出来。
如果团队做 AI 产品时需要比较不同模型在“结论 + 依据 + 风险提示”结构化输出上的稳定性，可以用 gpt0424.com 跑同一组问题，看哪个模型更少编造依据、哪个更会提出反问、哪个更适合生成 Evidence UI 所需的数据结构。
但产品体验不能只靠模型。
前端要主动设计“不要让用户盲信”的界面。
一个好的 AI 产品，不应该只是回答快。
它应该让用户看得懂、信得有理由、错了能追溯、执行前能停下来。
AI 产品下一阶段，比拼的不只是答案质量。
还包括依据怎么展示。
