AI 产品的起点不是模型能力

开始构建 AI 金融研究产品时，最容易被模型演示吸引：上传文档、提出问题，几秒后得到一段完整回答。演示令人兴奋，却不能证明产品成立。

真实研究任务不是生成一段文字，而是收集材料、验证来源、比较观点、形成判断并留下证据。模型输出只是其中一环。

找到高成本任务

我们先观察研究过程中哪些步骤重复、耗时且可以验证，例如从多份材料中提取指标、追踪同一事实的来源、按固定框架整理公司信息。开放式“帮我分析”很难评价，结构清楚的子任务更适合建立信任。

选择任务时同时考虑错误成本。低成本内容可以快速试错，影响投资判断的结论则必须保留人工复核和引用。

我们后来不用“模型效果好不好”筛任务，而是给候选任务写一张卡：

“从公告中提取指定指标并链接原文”得分通常高于“帮我判断这家公司是否值得投资”。前者边界窄、频率高、结果可核验；后者把证据选择、分析框架和风险偏好混在一个开放问题里，流畅回答反而容易制造错误信任。

把不确定性放进界面

普通软件习惯返回确定结果，大模型天然带有不确定性。产品不能用流畅文本掩盖这一点。答案应关联原始来源，区分事实与推断，信息不足时明确说不知道。

用户也需要控制任务范围、查看执行进度、修正中间结果，而不是只面对一个聊天输入框。

一条研究结论在界面里至少拆成四部分：

type ResearchClaim = {
  statement: string;
  kind: "fact" | "calculation" | "inference";
  citations: Array<{ documentId: string; page: number; quote: string }>;
  confidence: "high" | "medium" | "low";
  unresolved?: string[];
};

事实必须有引用；计算需要展示公式和输入；推断要和事实分开；信息不足则把缺口显示出来。confidence 不是模型随口给出的百分比，而是由引用覆盖、来源一致性和任务规则共同产生的离散结果。

先设计评估，再设计演示

每个核心任务都需要可以重复的样本与评价标准。提取任务看字段准确与来源覆盖，比较任务看关键差异是否遗漏，报告任务还要检查事实与引用一致。只问“回答看起来好不好”，团队会被语言流畅度误导。

评估集不必一开始很大，但要来自真实材料，并包含信息缺失、来源冲突和格式异常。每次更换模型、提示词或检索策略都重新运行。AI 产品只有拥有稳定反馈，迭代才不是围绕几个漂亮截图进行。

我们的评估样本会保存输入材料版本、期望字段、可接受变体和证据位置：

{
  "caseId": "metric-conflict-07",
  "question": "报告期内经营现金流是多少？",
  "expected": { "value": 128000000, "currency": "CNY", "period": "2024-Q4" },
  "requiredEvidence": [{ "document": "annual-report", "page": 86 }],
  "trap": "摘要页使用了累计口径，正文表格为单季口径"
}

这个样本同时测试检索、口径判断、结构化输出和引用。只比较最终数字，无法知道是碰巧答对还是证据链真的成立。

AI 产品的壁垒不会来自“接入了某个模型”。真正长期的能力是理解任务、组织上下文、验证结果，并让模型输出进入可负责的业务流程。

图：模型和提示放在失败合同之后，产品边界才稳定。

“失败合同”是我评估每个 AI 任务的第一步：证据不足时怎么拒答；工具超时是否重试；输出哪些字段必须有引用；用户如何修正；已经发生的副作用怎样补偿。提示词只负责在合同内组织模型行为。

我们用失败案例验收产品，而不是只演示最佳输入。能解释“不知道”“没有权限”和“结果未知”的系统，通常比偶尔给出惊艳答案的原型更接近可交付产品。这条线的后端工程化部分——评估集怎么做、门禁怎么设——在RAG 评估别再问“感觉怎么样”里展开。