利用 Gemini 3.5-flash 进行竞品技术分析：从信息抓取到结论沉淀的工作流

做竞品技术分析最烦的，不是看不懂某个技术点，而是资料太散：官网一套说法，文档一堆细节，GitHub issue 里又藏着真实反馈，最后整理到表格时，人已经麻了。尤其是想用 Gemini 3.5-flash 这类响应快、长文本处理能力不错的模型辅助分析时，稳定入口也很关键。日常做资料汇总和对比，我会先用国内可访问的 AI 镜像工具把信息跑通，比如 KULA（https://ouai.me），手机或邮箱注册后就能使用 Gemini、ChatGPT、Claude 等主流模型，适合快速做第一轮整理。

一、先说清楚：竞品技术分析到底分析什么？

很多人一提“竞品分析”，第一反应是看功能列表。技术分析则不一样，它更关注“这个产品为什么能做到”。

一般可以拆成五类：

1. 技术架构：前后端、服务拆分、数据流、部署方式。
2. 核心能力：搜索、推荐、生成、协同、自动化等关键模块。
3. 性能表现：响应速度、并发能力、稳定性、资源消耗。
4. 工程体验：API 设计、SDK、文档、错误码、可观测性。
5. 产品边界：它支持什么、不支持什么、为什么这样取舍。

Gemini 3.5-flash 的价值，不是替你“拍脑袋下结论”，而是把大量资料压缩成可比较、可追问、可复用的结构化信息。

二、准备资料：不要一上来就让模型“分析某某竞品”

一个常见错误是直接问：

帮我分析 A 产品和 B 产品的技术差异。

这样得到的回答往往很泛。更好的方式是先准备资料包，让模型基于明确上下文工作。

资料可以来自：

• 官网产品页
• 技术文档
• API 文档
• 更新日志
• 开源仓库 README
• issue 和讨论区
• 用户评测文章
• 实测截图和接口返回结果

建议把资料按来源分段，并保留标题、链接来源、发布时间。模型不是搜索引擎，输入越清楚，输出越稳定。

可以用这样的资料格式：

[资料1：A 产品 API 文档摘要]
来源：官方文档
时间：2025-xx-xx
内容：
...

[资料2：B 产品 GitHub README]
来源：开源仓库
时间：2025-xx-xx
内容：
...

[资料3：用户反馈摘录]
来源：社区讨论
时间：2025-xx-xx
内容：
...

这一步看似笨，但它决定了后面分析质量的上限。

三、第一轮：让模型做“信息清洗”，而不是直接给结论

第一轮提示词建议只做整理，不要分析过度。

你是一名技术产品分析师。
请基于我提供的资料，完成信息清洗：

1. 提取每个产品的核心技术能力
2. 标出明确出现的信息和推测信息
3. 将功能、架构、性能、生态、限制分别归类
4. 不要补充资料中没有依据的结论
5. 输出 Markdown 表格

这里有个关键点：要求模型区分“明确出现”和“推测信息”。

竞品技术分析最怕把猜测写成事实。比如文档里只说“支持向量检索”，并不代表它一定用了某个具体数据库。模型如果直接帮你脑补，就会给后续判断埋雷。

四、第二轮：建立技术对比矩阵

清洗完资料后，再让 Gemini 3.5-flash 生成对比矩阵。这个阶段适合把问题问得更窄。

请基于上一步整理结果，生成 A 产品与 B 产品的技术对比矩阵。

对比维度包括：
- 架构复杂度
- API 完整度
- 数据处理能力
- 扩展性
- 部署与集成难度
- 文档友好度
- 潜在技术风险

要求：
1. 每个维度给出 1-5 分
2. 每个评分必须附一句依据
3. 如果依据不足，标记为“证据不足”
4. 最后给出适用场景判断

这类矩阵不一定用于最终发布，但特别适合内部讨论。它能把“我觉得 A 更好”变成“在哪个维度更好，依据是什么”。

注意，不要迷信评分。评分只是让讨论更聚焦，真正有价值的是评分后面的依据。

五、第三轮：做技术路线推断

当你已经有了基础对比，就可以进入更深一层：推断竞品背后的技术路线。

例如：

请根据现有资料，推断 A 产品可能采用的技术路线。

请按以下结构输出：
1. 已确认事实
2. 高概率推断
3. 中低概率推断
4. 仍需验证的问题
5. 建议的验证方法

要求：所有推断必须说明依据，不允许使用绝对化表达。

这一步适合分析那些没有公开架构的产品。比如一个 AI 写作工具响应很快、支持长文档、还能做多轮改写，你可以推断它可能做了缓存、分块、异步任务或检索增强，但必须标注“推断等级”。

好的技术分析，不是把话说满，而是把不确定性说清楚。

六、配合代码：批量整理资料更省时间

如果你有很多资料片段，可以用脚本批量调用模型，把文档先压缩成统一摘要。下面是一个简化示例，重点是流程，不绑定具体业务。

import os
import requests

API_KEY = os.getenv("GEMINI_API_KEY")
BASE_URL = os.getenv("GEMINI_BASE_URL", "https://example.com/v1")
MODEL = "gemini-3.5-flash"

def summarize_doc(title, content):
    prompt = f"""
你是一名技术资料整理助手。
请将以下资料整理为竞品技术分析摘要。

标题：{title}

资料内容：
{content}

输出结构：
- 核心能力
- 技术特征
- 集成方式
- 性能或限制描述
- 可用于竞品对比的要点
- 证据不足的部分
"""
    resp = requests.post(
        f"{BASE_URL}/chat/completions",
        headers={
            "Authorization": f"Bearer {API_KEY}",
            "Content-Type": "application/json",
        },
        json={
            "model": MODEL,
            "messages": [{"role": "user", "content": prompt}],
            "temperature": 0.2,
        },
        timeout=60,
    )
    resp.raise_for_status()
    return resp.json()["choices"][0]["message"]["content"]

if __name__ == "__main__":
    docs = [
        {
            "title": "A 产品 API 文档",
            "content": "这里放入清洗后的文档正文..."
        },
        {
            "title": "B 产品更新日志",
            "content": "这里放入更新日志摘要..."
        }
    ]

    for doc in docs:
        print("#", doc["title"])
        print(summarize_doc(doc["title"], doc["content"]))
        print()

实际使用时，建议把输出保存成 Markdown，再交给模型做第二轮对比。这样比一次性塞入大量资料更稳，也更容易回溯。

七、让结论更像“分析”，而不是“模型作文”

最后一份竞品技术分析报告，建议采用下面结构：

• 背景：为什么分析这几个竞品。
• 资料来源：用了哪些公开资料和实测结果。
• 对比矩阵：用表格展示核心差异。
• 关键发现：列出 3-5 个最重要的技术判断。
• 风险与不确定性：哪些结论证据不足。
• 行动建议：对自家产品、研发排期或选型有什么启发。

这里特别建议保留“风险与不确定性”。在技术团队里，一份报告如果只讲结论，不讲证据边界，很容易被质疑。反过来，如果你能说明“哪些是事实，哪些是推断，哪些需要进一步验证”，可信度会高很多。

八、几个实用提示词模板

如果你想快速上手，可以直接复用下面几个模板。

1. 提取技术卖点

请从以下资料中提取该产品的技术卖点。
要求区分：
- 面向用户的功能表述
- 背后的可能技术能力
- 可以验证的证据
- 仍需确认的信息

2. 找技术短板

请从工程实现角度分析该产品可能存在的短板。
只基于资料进行判断，不要臆测。
请按“证据、影响、验证方式”输出。

3. 生成汇报版结论

请将以上分析压缩成一页汇报内容。
目标读者是产品经理和研发负责人。
要求表达克制、结论明确、避免夸张。

九、结论：模型负责提效，人负责判断

用 Gemini 3.5-flash 做竞品技术分析，最合适的定位是“研究助理”。它擅长整理、归类、对比、压缩信息，也能帮助你发现资料之间的矛盾点。

但最终判断仍然要回到人。尤其是技术架构、性能瓶颈、真实成本这些问题，仅靠公开资料很难完全确认。更可靠的做法，是让模型先帮你完成 70% 的资料劳动，再由你用经验和实测补上最后 30%。

竞品研究不是为了证明谁更强，而是为了看清对方的取舍，再反过来校准自己的产品路线。把问题问细，把证据留好，把结论说稳，这才是 AI 辅助技术分析真正有价值的地方。

【本文完】