企业官网建设流程全解析

1. 为什么情感分析这件事，值得从embeddings接口重新讲一遍

很多人第一次做文本情感分析，路径几乎都一样：找一批带标注的评论数据，标成正面负面两类，套一个分类模型跑一遍，看准确率多少。这个路子没错，但它有个很现实的限制——你得先有标注数据。真实场景里，你手上往往只有一堆用户反馈、客服对话、商品评价，没人给你标好正负，你也不想为了一个临时需求去标几千条样本。这时候向量化接口（embeddings）就是一条很实用的捷径：它把一句话压成一个高维向量，语义相近的句子在向量空间里距离更近，你只要准备少量“标杆句子”，就能用距离度量把新文本归类。

我这次要拆的就是这条路：用向量化接口做文本情感分析。它不需要训练，不需要标注大批数据，几句话就能搭出一个能跑的原型；同时它也不是万能的，短文本、反讽、混合情绪这些老问题照样存在，甚至会更隐蔽。所以这篇不会只给你一段调用代码就完事，而是把整条链路上的选择、参数、坑点、评估方法都摊开讲清楚，让一个没接触过向量接口的人看完能自己动手，也让已经跑通过一次的人知道自己那版为什么有时候不准。

先把本文涉及的核心概念用最直白的话对齐一下，避免后面混淆。向量化（embedding），说白了就是把文本变成一串小数，比如 1536 个浮点数，这串数字代表这句话的“语义坐标”。余弦相似度，衡量两个坐标方向是否一致，取值 -1 到 1，越接近 1 说明语义越像。情感分析在这里不是让模型输出“正面/负面”这两个字，而是我们自己定义一个参照系：准备若干条典型正面句和典型负面句，各自算一个“中心向量”，新句子来了就算它离哪个中心更近。这个思路本质上是一种少样本的相似度分类，也叫“锚点法”或“原型法”，在工程上非常常见。

适合谁来读这篇：写过一点 Python、调过任意 HTTP 接口、知道什么是 JSON 的人，读起来最顺；完全没写过代码的读者也能看懂前几节的思路和后面的评估逻辑，只是实操部分需要照着补齐基础语法。我不假设你熟悉机器学习，向量、距离这些词我都会用生活化的方式解释。整个方案的定位很清楚——它是一个低成本、可解释、能快速验证的情感判别方案，适合做数据探索、批量打标、趋势粗筛，不适合替代高精度、强合规要求的正式分类系统。这个边界先划清楚，后面所有的取舍才有依据。

2. 用向量做情感判别的底层逻辑，以及它和训练分类器的本质区别

2.1 一句话变成一串数字之后，到底保留了什么

文本转向量这件事，很多人以为是把词换成编号，其实完全不是。编号是离散的、没有远近关系的，而向量是连续的，并且方向携带语义。你可以这样理解：把“这家店的服务态度真好”和“服务态度太差了”分别变成两个箭头，这两个箭头在很多维度上其实是同向的——都指向“服务态度”这个主题，但在某个表示“评价极性”的方向上一个朝正、一个朝负。向量化模型在大规模语料上训练过，它学到的是词语和句子在什么语境下出现，因此语义相近的表达会聚在一起。

这个特性带来两个直接后果，值得单独强调。第一，同义改写几乎不影响结果。“东西不错”和“商品质量挺好的”在向量空间里非常接近，你不需要为每一种说法准备模板。第二，主题相近会拉高相似度。这是最容易翻车的地方：一句“物流慢得要死，但衣服质量真好”和一句“物流很快，衣服质量真好”，主题高度重合，向量相似度可能都不低，如果你只用一个笼统的正面锚点去比，很可能会判错。这也是为什么后面我要强调“锚点要覆盖多种表达，且要围绕评价词而不是主题词”。

还有一个容易被忽略的点：向量化接口通常对输入长度有上限，超出部分会被截断或直接报错。这意味着一条几百字的长评论，可能只有前半段被真正编码。做批量分析时如果不管这一点，你会得到一批“看起来正常但实际只看了半句话”的结果，排查起来极其痛苦。我的习惯是预处理阶段就按句子或按长度切块，每块单独判情感，再按块做加权汇总，而不是把整段话硬塞进一次调用。

2.2 为什么“找中心点”比“训一个分类器”更适合这个场景

训练一个情感分类器，标准流程是：收集数据、人工标注、划分训练验证集、选模型、调参、评估、部署。这条链路对小团队来说成本不低，尤其是标注环节，标 2000 条短评论至少也要大半天，而且标注一致性还未必好。用向量找中心点的做法把这些全省了：你只需要写 10 到 20 条典型正面句、10 到 20 条典型负面句，各求一个平均向量（也就是中心点），新样本来了算它到两个中心点的余弦相似度，谁高判谁。

这个思路在学术上叫原型分类（prototype classification），它的假设是：同一类样本在向量空间里围绕某个中心聚集。这个假设在情感分析任务上大体成立，因为情感表达有很强的一致性——“好”“棒”“满意”“推荐”这些词反复出现在相似语境里。但它也有明确的失败条件，我在实测中总结了几条：

• 当句子是中性陈述（如“我下午三点收到货”），它到正负两个中心的距离可能都差不多，硬判会出错，需要设置一个“都不像”的阈值，归为中性或待人工复核。
• 当句子正负混合且比例接近，两个相似度会很接近，此时结果基本是随机的，靠加锚点解决不了，得靠切句。
• 当领域专业术语密集（如某些垂直行业的评价），通用向量模型对术语的语义把握可能偏弱，中心点的区分度会下降。

对比一下两条路线的取舍，会更清楚什么时候该选哪个：

我个人的判断标准很朴素：这个需求是“快速看个大概”，还是“要上线做业务决策”。前者用锚点法，一天内能出结论；后者老老实实做标注和训练，别想着省这一步。很多项目失败不是因为技术选错，而是因为用粗筛工具去做精算的活。

2.3 相似度分数不是概率，别拿它当置信度用

这是我在实际项目里踩得最深的一个坑，必须单独拎出来说。余弦相似度的取值范围是 -1 到 1，很多人看到“正面 0.82、负面 0.31”就以为模型有 82% 的把握是正面。这个理解是错的。0.82 只表示这句话和你准备的正面锚点整体方向上比较接近，它和“分类正确的概率”没有直接换算关系。你会发现有些明显负面的句子，正面相似度也有 0.6 以上，因为句子里大量词汇是中性的、共用的。

正确的用法是看差值（margin）：正面相似度减去负面相似度，差值越大，判别越有把握；差值接近 0，说明这句话在两类之间摇摆，应该标记出来人工看。我在实际使用中会给差值设两档阈值，比如差值大于 0.05 直接给结论，差值在 0.02 到 0.05 之间标为“低置信”，小于 0.02 直接丢进人工复核队列。这个阈值不是拍脑袋定的，而是拿一批已知答案的样本跑一遍，看差值分布在哪里出现明显分界，再定下来。任何阈值都必须用自己的数据校准，别人给的数字对你没有意义。

3. 动手之前的环境与数据准备，几个不写进文档但必须做的事

3.1 密钥管理与调用方式的选取

调用向量化接口需要凭证。第一条铁律：凭证绝不写进代码、绝不提交到代码仓库。我见过太多人图省事直接写在脚本第一行，然后推到公开仓库，几小时后收到额度异常的通知。正确做法是用环境变量读取，本地放一个不被版本管理跟踪的配置文件，服务器上则在部署环境里配置。下面是我常用的读取方式，Python 里几行就够：

import os from openai import OpenAI client = OpenAI( api_key=os.environ.get("EMBEDDING_API_KEY"), base_url=os.environ.get("EMBEDDING_BASE_URL") # 使用服务方提供的接入地址 )

注意我把地址也放进环境变量了，原因是不同服务方、不同区域的接入地址可能不同，写死在代码里换环境就要改代码，非常别扭。另外建议给这个密钥单独设一个用途标记和额度上限，别和主账号共用一个全权限密钥，出问题时排查范围会小很多。

调用方式上，官方提供了 SDK 和原始 HTTP 两种。SDK 省事，但版本变动时偶发参数不兼容；直接发 HTTP 请求更透明，出问题看返回体就知道卡在哪。我的建议是先用 SDK 跑通，再考虑是否换 HTTP，因为新手阶段最大的成本不是性能，是搞不清错误原因。如果团队里要长期维护，我会倾向封装一层薄薄的调用函数，把重试、超时、异常处理都收进去，业务代码只调这一个函数。

3.2 模型版本的选择与维度确认

向量化模型有多个版本，主要差异在向量维度和对不同语言、不同文本类型的适配程度。选择时不用纠结太多，记住两条：第一，同一个项目里所有向量必须来自同一个模型版本，混用会导致不同维度的向量无法比较，或者维度相同但语义空间不一致，相似度完全失去意义；第二，维度越高不一定越好，高维保留的信息多，但计算和存储成本也高，做几千条以内的粗筛，中等维度完全够用。

我遇到过一种情况：本地调试用的一个版本，线上环境配置的是另一个版本，结果同一批数据跑出来的分类结果差异明显，排查了半天才发现是版本不一致。教训是——把模型名写进配置文件，并在结果里记录本次使用的模型标识。这样将来回看某批结果时，能知道它是谁算出来的。

关于维度，还有一个实操细节：求中心点时必须保证所有向量的维度一致，计算余弦相似度时也要先确认维度。Python 里用 numpy 算的时候，维度不匹配会直接报错，这还算幸运；如果用了某些宽松的库，可能会静默做广播，结果完全错乱还看不出来。所以每次批量处理前，加一行维度断言，成本极低但能省掉大麻烦。

3.3 语料清洗：比模型选择更影响最终效果

我必须说一句可能不太好听的话：在这个方案里，清洗数据的重要性高于选模型。原因很直接——向量模型对噪声是敏感的。一条评论里如果夹着大量表情符号编码、重复的感叹号、空白字符、无关的订单号，这些东西会稀释有效语义，让向量偏离真正的评价内容。我做的清洗通常包括这几步：

• 去掉 URL、邮箱、一长串数字（订单号、手机号），这些对情感判断毫无帮助，还会占掉输入长度。
• 统一全半角标点，折叠连续重复的标点符号，比如把“！！！”压成一个“！”。保留一个感叹号有助于表达强度，保留十个就是噪声。
• 处理表情符号时不要一刀切删除。有些场景里表情本身就是情感信号，直接删会丢信息。我的做法是把常见表情映射成简短文字标记，或单独记录表情数量作为辅助特征。
• 处理否定词。这一条很关键，中文里“不”“没”“别”会翻转语义，但向量模型对短句里的否定有时把握不稳。我的经验是在清洗阶段保留否定词不动，不要做去停用词处理，因为停用词表里往往包含否定词，删掉就彻底反了。

提示：不要在这个环节做激进的分词和去停用词。向量模型接收的是原始文本，你提前把词拆散、把虚词删掉，反而破坏了它依赖的上下文结构。清洗的目标是去噪声，不是改写成关键词列表。

另外要提一下样本量的问题。用锚点法时，锚点本身的数量和质量决定了上限。我一般每类准备 15 到 25 条，覆盖不同长度、不同句式、不同强度。太少（比如每类 3 条）会导致中心点严重偏向某一种表达；太多也不是好事，如果你把明显偏离的句子也塞进去，中心点会被拉偏。有个技巧是：锚点写完后先自测一遍，用每条锚点去和两个中心点比，看它是否被判回自己所属的类，判错的锚点要么改写要么剔除。

4. 完整实现链路：从锚点构造到批量打标

4.1 锚点句怎么设计，决定了这套方案的天花板

锚点句不是随便写几句“很好”“很差”就完事。我总结的设计原则有四条，按重要性排序：

第一，锚点要描述“评价”而不是“主题”。差劲的锚点是“这个手机”，好的锚点是“这个手机用起来很顺手，值得买”。前者是名词短语，没有情感极性，放进去只会污染中心点。

第二，锚点要覆盖不同的表达强度。全是“非常满意”“极其推荐”这种强正面，会让中心点偏向极端表达，遇到“还行吧”这种弱正面时判别就会迟疑。我的做法是强、中、弱各放几条，比例大致 1:2:1。

第三，锚点要贴合你的实际语料风格。如果你分析的是客服对话，锚点就该用口语化的短句；如果你分析的是产品评测长文，锚点就该是书面化表达。用错风格会让中心点偏离真实分布，这个偏差在测试集上不一定看得出来，但在真实数据上很明显。

第四，锚点要避免主题词重叠。如果正面锚点全是关于“物流快”，负面锚点全是关于“质量差”，那模型学到的其实是主题差异而不是情感差异，遇到“物流慢”的负面句就会判错。解决办法是让正负锚点在主题上交叉覆盖，比如正面锚点里既有夸服务的也有夸质量的，负面同理。

我把这套锚点组织成一个字典结构，方便后续扩展和维护：

anchors = { "positive": [ "质量很好，用起来很顺手，会回购", "客服态度不错，问题很快就解决了", "整体体验超预期，推荐给朋友了", "性价比挺高的，比想象中好用", "包装很用心，东西也没问题，还算满意", # ... 继续补充到 15~25 条 ], "negative": [ "质量太差了，用两天就坏了，很失望", "客服一直推诿，问题拖了一周没解决", "和描述完全不符，感觉被坑了", "价格虚高，实际体验很一般，不推荐", "包装破损，东西也有划痕，体验很糟", # ... 继续补充到 15~25 条 ] }

写完之后一定要做锚点自检：把每条锚点当作待测样本，算它和两个中心点的相似度，看是否判回自己这一类。我实测下来，初版锚点通常会有 1 到 3 条判错，这些多半是表达含糊或者混入了另一类的词，改掉之后整体准确率会有可见提升。这一步花十分钟，收益远大于后面调阈值。

4.2 中心点计算与相似度判别的代码骨架

有了锚点，下一步是把它们全部转成向量，然后按类求平均。这里有个细节值得说：求平均之前建议先做归一化，也就是把每个向量除以它的长度，让所有向量长度变成 1，然后再平均。原因是不同句子的向量长度可能不同，长度大的句子在求平均时权重会偏大，归一化后每个锚点贡献相等，中心点更稳定。

import numpy as np def embed_texts(texts): resp = client.embeddings.create( model=EMBEDDING_MODEL, input=texts ) vecs = [item.embedding for item in resp.data] arr = np.array(vecs, dtype=np.float32) norms = np.linalg.norm(arr, axis=1, keepdims=True) return arr / np.clip(norms, 1e-12, None) def build_centers(anchors): centers = {} for label, texts in anchors.items(): vecs = embed_texts(texts) center = vecs.mean(axis=0) centers[label] = center / np.linalg.norm(center) return centers def classify(text, centers): v = embed_texts([text])[0] scores = {label: float(np.dot(v, c)) for label, c in centers.items()} margin = scores["positive"] - scores["negative"] return scores, margin

这段代码有几个设计意图我解释一下。批量接口一次可以传多条文本，能批量就别循环单条调，除了省时间，还能减少网络抖动带来的偶发失败。归一化用clip兜底，防止出现全零向量导致除零。中心点算完再归一化一次，是为了保证和样本向量的比较在同一尺度上。判别时返回分数和差值两个东西，而不是直接返回标签，因为下游要靠差值做置信度分级，这个在 2.3 节讲过原因了。

如果要做阈值分级，可以在classify外面再包一层：

def label_with_confidence(text, centers, high=0.05, low=0.02): scores, margin = classify(text, centers) base = "positive" if margin > 0 else "negative" if abs(margin) >= high: return base, "high", scores if abs(margin) >= low: return base, "low", scores return "uncertain", "review", scores

阈值high和low的具体数值，我在示例里写了 0.05 和 0.02，但这只是起点，必须用你自己的验证集校准。校准方法是：拿 100 到 200 条你人工看过、有明确结论的样本，跑一遍看差值的分布，找出“判对”和“判错”的分界区间，把阈值定在分界稍宽的一侧。我做过一个中文电商评论的小样本校准，最后落的阈值是 0.04 和 0.015，和你看到的示例值不同，这很正常。

4.3 长度切块与结果汇总的工程处理

前面提过输入长度上限的问题，这里给一个可落地的处理方式。思路是把长文本按标点切成句子，句子再按长度上限聚合成块，每块单独判情感，最后按块的数量或者字符数加权汇总。为什么不直接取平均？因为句子长短不一，长句往往承载更多信息，简单平均会让一个“还行”吞掉一整段夸奖。

import re def split_into_chunks(text, max_chars=800): sentences = re.split(r"(?<=[。！？!?；;])", text) chunks, buf = [], "" for s in sentences: s = s.strip() if not s: continue if len(buf) + len(s) <= max_chars: buf += s else: if buf: chunks.append(buf) buf = s if buf: chunks.append(buf) return chunks or [text.strip()] def analyze_long_text(text, centers, max_chars=800): chunks = split_into_chunks(text, max_chars) results = [] for c in chunks: scores, margin = classify(c, centers) results.append({"chunk": c, "margin": margin, "len": len(c)}) total = sum(r["len"] for r in results) or 1 weighted = sum(r["margin"] * r["len"] for r in results) / total label = "positive" if weighted > 0 else "negative" return label, weighted, results

max_chars这个值不要照抄我的 800，要按你所用模型的输入上限打一个安全折扣。比如上限是 8192 个 token，中文一个字大致对应 1 到 2 个 token，那保守取 2000 字以内比较稳。折扣要留足，因为超限的行为在不同服务方可能不同，有的截断有的报错，报错还能看见，静默截断最坑。

加权汇总还有个注意点：如果一段话里正负情绪都很强（比如“优点一二三，缺点一二三”），加权后的总差值可能接近 0，这时候归类为“混合”比强行归一边更诚实。我在输出里会保留每个切块的明细，方便人工复核时直接定位到是哪一句话导致的判断，这个调试体验比只看一个最终标签好太多。

4.4 批量打标的吞吐与失败重试

真实场景下你是要给几千上万条数据打标，不是几条。批量调用时要控制单次请求的条数，我一般设成 64 到 128 条一批，太大容易触发请求体超限或超时，太小则网络往返开销占比高。还要处理部分失败：一批里有几条因为内容问题失败，不应该让整批作废。

我的做法是把批处理写成“分批 + 单条兜底”的结构：整批失败时降级为逐条调用，逐条还失败的记录下来，最后统一输出失败清单，人工看一眼大多是空文本或者超长文本，处理掉再重跑。同时统计每批的耗时和失败率，如果失败率突然升高，通常是额度、限流或者网络的问题，早点停下来比盲目重试好。重试策略上我倾向指数退避，最多三次，超过三次说明不是抖动，是配置或内容的问题，继续重试只是浪费时间。

还有一点很容易被忽视：结果要落盘，而且要带上原始文本的标识和本次使用的模型、锚点版本。锚点后面肯定会改，改了之后旧结果的判别标准就和新结果不一致了，如果没有版本记录，你回头看两份结果时会完全不知道差异从哪来。我给每个项目建一个结果目录，里面放锚点文件、配置文件和结果文件，命名带日期和版本号，土办法但极其有效。

5. 效果评估与那条最难绕开的“反讽”边界

5.1 小样本评估怎么做才有参考价值

没有评估的调参就是自欺欺人。用锚点法做情感分析，评估不需要很复杂，但必须做，而且必须用你自己场景的数据。我的做法是抽 150 到 200 条真实文本，人工标一个答案（正面、负面、中性、混合），然后跑一遍，出一张混淆矩阵。重点不是看总体准确率，而是看错在哪个格子。

我实测过的一批中文短评论里，错判主要集中在三处：中性被判成正面、混合被判成单边、反讽被判成正面。这三个格子各自对应不同的修复手段：中性靠加阈值区间和中性锚点解决，混合靠切句解决，反讽基本无解，只能靠人工或者引入更强的模型。看清错误分布，你才知道这个方案在你的数据上到底值不值得用。

评估时还要注意类别不平衡的陷阱。如果你的真实数据里 85% 是正面，那你闭着眼睛全判正面也能有 85% 的准确率，这个数字毫无意义。所以除了准确率，我会单独看负面类的召回率——也就是真实负面样本里，有多少被成功识别出来。业务上通常负面漏判的代价远高于正面误判，这个指标比总体准确率更该盯。

注意：评估集不要和锚点句重复。用锚点去评估自己，结果一定是 100%，因为锚点本来就是中心点的一部分，这是自测，不是评估。

5.2 反讽、否定和混合情绪：模型搞不定的部分要承认

反讽是这个方案最明确的短板，没有之一。一句“好评，快递三天就到了，包装也完好，就是东西是坏的”，字面上大量正面词汇，实际是强烈负面。向量化模型在编码时会被整体语境带偏，很可能给出偏正面的分数。我试过用增加锚点的方式强行修正，效果有限，而且会反过来污染其他样本——你为了这一条反讽加了负面锚点，其他正常正面句的判别就会受影响。

我的处理方式是承认它的存在并把它分流。做法是给每条结果附加一个简单的规则标记：句子里同时出现转折词（“但是”“不过”“就是”）和强情感词时，标为“含转折，建议复核”。这不能解决反讽，但能把可疑样本筛出来，让人工优先看那些最可能出错的。这个思路在工程上很常见：模型负责大面，规则负责兜底，人工负责最后一公里，三层配合比指望一层完美现实得多。

否定词也值得单独说。中文的否定结构复杂，“不是不好”这种双重否定，向量模型经常判反。我的经验是，清洗阶段保留否定词（前面讲过），评估阶段单独统计含否定词的样本的准确率，如果明显低于整体，就在锚点里专门补几条含否定的表达，比如正面类里加“没有想象中那么差，其实挺好用”，负面类里加“不是质量问题是态度问题，反正不推荐”。补完之后这类样本的准确率通常能回升一截。

5.3 结果怎么呈现给非技术同事

这一点常被忽略，但直接影响这个方案能不能落地。你算出一堆相似度分数，如果直接把 0.73、0.41 这样的数字丢给业务同事，他们要么看不懂，要么过度解读。我的做法是只交付三列：文本、结论（正面/负面/待定）、以及一句简短的理由。理由可以是“与正面表达更接近”或者“正负接近，建议人工确认”，不出现任何小数。

如果要做趋势分析，我会按天或按主题聚合正面比例，画一条简单曲线，而不是把每条明细都摆出来。趋势比单条更有价值，也更不容易被单条误判干扰。另外强烈建议保留原始文本和明细，因为业务同事看到某个结论觉得反常识时，第一反应一定是“哪条说的，我看看”，此时你能立刻翻出来，信任就建立起来了；翻不出来，这个方案在他们心里的可信度会迅速归零。

6. 成本、性能与几个我被问过最多的问题

6.1 调用成本怎么估，哪些地方最容易浪费

向量化调用的计费通常按处理的文本量算，单价看起来很低，但量大了就不是小数。我估算成本的公式很土：总字数 ÷ 单条平均字数 = 调用条数，再乘单价。真正容易浪费的地方有三个。第一是重复调用，同一条文本在调试阶段被反复编码，其实只要第一次的结果缓存下来就行，我一般用文本的哈希值做键，存一个本地缓存文件，调参阶段能省掉大量重复开销。第二是锚点重复计算，锚点是不变的，算一次存下来即可，不要每次分析都重算。第三是全量重跑，数据增量的场景下只跑新增部分，别每次都从头来。

缓存这件事要提一句风险：文本哈希做键，注意清洗规则变化后要清缓存。因为清洗规则一变，同样的原文处理后的文本就不同了，如果还命中旧缓存，你拿到的就是旧规则下的结果。我的做法是在缓存键里拼上清洗规则的版本号，规则改了版本号加一，自动失效。

6.2 延迟和并发：什么时候该考虑换方案

单次调用通常在几百毫秒量级，批量调用时延迟会随条数线性增长。如果你要处理十万条数据，即使每批 100 条，也要上千次请求，加上网络往返，总时长可能是一两个小时，这个量级完全可以接受，跑一次离线任务就行。但如果你的需求是实时判别，比如用户提交反馈后立刻给出情绪标签并触发预警，那这个方案就有点勉强了，需要做并发控制、连接复用，或者干脆把常用表达做成缓存，减少实时调用。

我的经验分界线是：离线批处理用这个方案非常舒服，实时高并发场景要谨慎评估。判断标准很简单，看你的业务能不能容忍秒级延迟。能容忍就上，不能容忍就先做缓存层，或者只在关键节点用，不要全量实时调用。

6.3 常见问题速查

下面这些是我在实际使用中被问到最多、或者自己踩过的问题，整理成表格方便对照：

最后分享一个我一直在用的习惯：每做一个新的分析任务，先用 20 条数据跑一遍全流程，从头到尾看一遍输出，再放大到全量。这 20 条要刻意挑极端的——特别正、特别负、中性、反讽、超长、含表情，全放进去。这一轮小样本试跑能暴露 80% 的问题，比全量跑完再发现问题省钱省时间得多。我个人在实际操作中的体会是，这套向量锚点法的价值不在于它有多准，而在于它能让你在半小时内对一批陌生文本形成一个大致判断，然后据此决定要不要投入更多资源做精细方案。先用它做侦察，再决定主攻方向，这个用法比指望它一步到位靠谱得多。