前言

我们团队（语核科技）成立于2023年5月，专注于B2B场景的AI Agent落地。过去两年，我们服务了制造业、能源、科技等行业的上百家企业。

在这个过程中，我们发现了一个反直觉的规律：大多数Agent项目的失败，不是因为模型能力不够，而是因为团队根本没搞清楚要解决什么问题。

客户说「我要提升售前效率」——这是需求吗？不是。这只是一个模糊的期望，无法转化为任何技术方案。

真正的需求是：「售前在处理招标文件的需求理解环节，平均耗时2小时，导致整体响应时效从收标到出初稿需要数日，影响中标率。」

从前者到后者的能力，我们内部称为「场景Taste」。这篇文章分享我们将其工程化的完整路径。

一、问题：Demo到生产的巨大鸿沟

很多团队做了一个在测试集上表现不错的Agent，但上线后立刻暴露三类典型问题：

1.1 需求定义失效

客户验收标准是「感觉更好用了」，而非可量化指标。这类需求无论怎么优化模型，都无法验证是否达标，项目最终沦为无法验收的「说不清」。

1.2 阻塞点识别错误

花3个月优化了「方案撰写环节」的文本生成质量，但该环节并非业务瓶颈——实际阻塞点在上游的招标文件解析，这个环节漏掉关键技术要求，导致所有下游工作反复返工。优化了错误的环节，ROI接近零。

1.3 技术可行性错判

承诺「客户谈判策略自动生成」，但该场景高度依赖现场实时判断，无历史数据可参考，难以设计验收标准，项目最终烂尾。

二、传统方案的失效边界

常见的「需求分析」方法在AI Agent项目中存在根本性失效：

用户调研失效：传统问卷和访谈能收集到「我希望更快」「我希望更准确」这类模糊期望，无法产出可执行的技术规格。业务人员描述的是「感受」，工程师需要的是「指标」，中间有一道隐形的鸿沟。

原型验证失效：Demo环境下的准确率来自精选测试集，而非真实生产环境随机样本。在某个项目中，Demo准确率92%，生产环境实际准确率仅68%——因为Demo集排除了格式混乱的文件，而这类文件占真实场景的40%。

需求文档失效：传统软件的需求文档聚焦功能描述（「系统应能生成报价」），而Agent需要的是判断逻辑描述（「当客户需求文件包含X类条款时，报价参考Y历史案例；若无匹配案例，触发人工审核」）。两者的抽象层级完全不同。

三、核心方案：场景Taste的工程化框架

场景Taste不是玄学，可以被拆解为三个可操作步骤：需求拆解 → 阻塞点定位 → 可行性评估。

3.1 整体架构

模糊业务期望（如"提升售前效率"）
         │
         ▼
┌────────────────────────────────────────────┐
│            场景Taste 工程化流程              │
│                                            │
│  Step 1  需求拆解                           │
│  ┌──────────────┐   ┌───────────────────┐  │
│  │  识别核心目标  │──▶│  转化为量化指标    │  │
│  └──────────────┘   └───────────────────┘  │
│            │                               │
│            ▼                               │
│  Step 2  阻塞点定位                         │
│  ┌─────────────────────────────────────┐   │
│  │  时间 × 频率 × 下游影响 → 阻塞指数    │   │
│  │  按指数排序，优先攻克高分环节          │   │
│  └─────────────────────────────────────┘   │
│            │                               │
│            ▼                               │
│  Step 3  可行性评估（三维）                  │
│  ┌────────┐  ┌────────┐  ┌────────┐        │
│  │  数据  │  │  知识  │  │  技术  │        │
│  └────────┘  └────────┘  └────────┘        │
└────────────────────────────────────────────┘
         │
         ▼
清晰的技术问题定义（可以开始建模）

3.2 需求拆解框架（Python伪代码）

class RequirementAnalysis:
    """场景Taste：需求工程化拆解框架（伪代码）"""

    def __init__(self, raw_requirement: str):
        self.raw = raw_requirement  # 输入：模糊业务期望

    def extract_measurable_goal(self) -> dict:
        """
        将模糊期望转化为可量化目标
        输入: "提升售前效率"
        输出: 含时效、准确率、覆盖率、审核模式的结构化指标
        """
        return {
            "time_constraint": "20min",         # 处理时效上限
            "accuracy_threshold": 0.90,          # 关键信息提取准确率下限
            "coverage_rate": 0.80,               # 覆盖招标文件类型的比例
            "review_mode": "human_in_loop"        # L2阶段，保留人工审核
        }

    def identify_bottleneck(self, process_steps: list) -> list:
        """
        定位阻塞点，按阻塞指数降序排列
        阻塞指数 = 平均耗时(h) × 每周频率 × 下游影响系数
        """
        for step in process_steps:
            step["bottleneck_score"] = (
                step["avg_hours"] *
                step["weekly_freq"] *
                step["downstream_impact"]  # 1=低影响, 2=中, 3=高
            )
        return sorted(process_steps, key=lambda x: x["bottleneck_score"], reverse=True)

    def assess_feasibility(self, scenario: dict) -> str:
        """
        可行性评估：数据 + 知识 + 技术三维判断
        返回: "feasible" / "conditional" / "not_feasible"
        """
        data_ok = scenario.get("historical_samples", 0) >= 100
        knowledge_ok = scenario.get("sop_definable", False)   # 隐性知识能否显性化
        tech_ok = (
            scenario.get("structured_task", False) and
            scenario.get("verifiable_output", False)
        )
        score = sum([data_ok, knowledge_ok, tech_ok])
        if score == 3:
            return "feasible"
        elif score == 2:
            return "conditional"
        else:
            return "not_feasible"

3.3 阻塞点定位：真实业务数据示例

import pandas as pd

# 某制造企业售前流程各环节数据（真实生产环境测量值，非测试集）
process_data = [
    {"环节": "招标文件解析", "avg_hours": 2.0, "weekly_freq": 5, "downstream_impact": 3},
    {"环节": "历史案例检索", "avg_hours": 1.0, "weekly_freq": 5, "downstream_impact": 2},
    {"环节": "方案撰写",    "avg_hours": 4.0, "weekly_freq": 3, "downstream_impact": 1},
    {"环节": "内部评审",    "avg_hours": 1.5, "weekly_freq": 3, "downstream_impact": 1},
]

df = pd.DataFrame(process_data)
df["bottleneck_score"] = df["avg_hours"] * df["weekly_freq"] * df["downstream_impact"]
df_sorted = df.sort_values("bottleneck_score", ascending=False)
print(df_sorted[["环节", "bottleneck_score"]])

# 实际输出：
# 招标文件解析    30.0  ← 最高优先级（非直觉最优项）
# 方案撰写        12.0
# 历史案例检索    10.0
# 内部评审         4.5

结论与直觉相反：「方案撰写」耗时最长（4小时），但阻塞指数排第二；「招标文件解析」耗时仅2小时，但因为下游影响系数最高（漏了关键要求会导致所有后续环节返工），阻塞指数最高，应该优先解决。

四、效果验证：引入场景Taste方法论前后对比

以下数据来自语核科技在某大型制造企业真实生产环境的随机样本（非精选测试集）：

维度	未使用场景Taste方法	应用场景Taste方法论后
需求对齐周期	2–4周（反复来回）	3–5天（结构化拆解）
招标文件解析时效	人工约2小时	Agent约20分钟
关键信息提取准确率	约85%（人工偶发遗漏）	99%+（真实生产环境随机样本）
首次上线后返工率	约40%（需求不清导致）	约8%
人工审核工作量	逐字全量审核	抽查确认（工作量降约70%）
项目交付周期	6–9个月	3–4个月

说明：上述数据仅适用于「招标文件解析+初步方案生成」这一具体场景，不同行业和场景的数据会有差异，请勿直接套用。

五、总结与后续方向

「场景Taste」解决的核心问题：在技术开发开始之前，先确保「在解决真实问题，且能验证是否解决好了」。

工程化路径：模糊期望 → 量化目标（需求拆解）→ 阻塞点排序（时间×频率×影响）→ 可行性三维评估 → 清晰技术规格。

这个能力，90%的团队在Agent项目中跳过了——他们从「客户说要什么」直接跳到「我们来实现什么」，绕过了「这件事是不是真的值得做，怎么才算做好了」这个最关键的问题。

语核科技正在将这套方法论进一步工具化，输出标准化的「场景评估清单」，供团队在项目立项阶段使用。这不是银弹，但它能大幅降低因需求不清而烂尾的概率。