判断 Gemini 3 这类大模型强不强,不能只看它能不能回答几个惊艳问题。真正有用的评估方式,是把任务拆成明确的输入、输出、约束和验收标准,看它能不能稳定完成复杂工作。
Gemini 3 可以放在这些场景里使用:
| 场景 | 输入 | 期望输出 | 关键能力 |
|---|---|---|---|
| 多模态理解 | 图片、截图、图表、视频帧、文字 | 结构化摘要、问题定位、方案建议 | 视觉理解、文本推理 |
| 长上下文分析 | 文档、会议纪要、代码仓库片段、日志 | 结论、风险点、待办清单 | 长文本检索、归纳、引用定位 |
| 代码生成 | 需求说明、接口定义、错误日志 | 代码、测试用例、修复建议 | 编程、调试、解释 |
| 复杂任务规划 | 目标、限制、可用工具 | 分步骤计划、工具调用方案 | 任务拆解、Agent 规划 |
| 内容生产 | 资料、受众、风格约束 | 脚本、文案、教程、分镜 | 语言生成、结构化表达 |
把模型当成“更聪明的聊天窗口”很容易浪费能力。更好的方式是把它接入一个可复用流程:先给清楚上下文,再规定输出格式,然后用程序或人工规则检查结果。
flowchart LR
A[任务目标] --> B[整理输入材料]
B --> C[设计提示词]
C --> D[调用 Gemini 3]
D --> E[结构化输出]
E --> F[自动校验]
F -->|通过| G[进入业务流程]
F -->|不通过| H[补充约束或示例]
H --> C
Gemini 3 适合解决什么问题
Gemini 3 属于多模态大模型,核心价值不是“会聊天”,而是能把文字、图像、代码、文档等不同形态的信息放到同一个推理过程里处理。
常见问题可以分成三类。
1. 信息太散,需要快速整理
比如一个需求包含产品文档、设计稿截图、接口说明和历史讨论。人工处理时,需要在多个材料之间来回切换。模型可以先把输入统一成结构化信息:
{
"需求目标": "",
"核心功能": [],
"涉及页面": [],
"接口依赖": [],
"潜在风险": [],
"需要确认的问题": []
}
这类任务不要求模型直接替人拍板,而是让它先完成“信息压缩”和“线索归类”。
2. 输入包含图片或界面,纯文本模型处理不了
多模态模型可以分析 UI 截图、流程图、图表、白板照片。比如给它一张后台页面截图,可以要求它识别页面结构、表单字段、交互路径和潜在可用性问题。
提示词需要避免只写“分析一下这张图”。更好的写法是指定观察维度:
你是资深产品和前端工程师。请分析这张后台管理页面截图。
请按以下结构输出:
1. 页面主要功能
2. 页面中的核心模块
3. 表单字段及含义
4. 可能的交互流程
5. 前端实现时需要注意的状态
6. 至少 5 个可用性问题或边界情况
要求:
- 不确定的地方标记为“需要确认”
- 不要编造截图中不存在的按钮或字段
- 输出使用 Markdown 表格
3. 任务链条长,需要拆步骤执行
例如“根据需求生成接口设计、数据库表、后端代码和测试用例”。这种任务不能一次性丢给模型,否则输出容易混在一起,也很难检查。
更稳的方式是拆成多轮:
flowchart TD
A[需求说明] --> B[抽取实体和流程]
B --> C[设计数据表]
C --> D[设计 API]
D --> E[生成代码骨架]
E --> F[生成单元测试]
F --> G[根据测试修正实现]
每一步只完成一个明确产物,产物之间用固定格式衔接。
提示词设计:把“想要什么”写成可执行规格
提示词不是越长越好,关键是让模型知道四件事:
- 它扮演什么角色;
- 输入材料是什么;
- 输出必须长什么样;
- 什么行为不允许。
一个稳定的提示词可以按这个模板组织:
角色:
你是{领域角色},擅长{能力范围}。
任务:
基于给定材料完成{具体任务}。
输入:
{粘贴材料,或说明图片/文档/代码内容}
输出格式:
请严格按以下结构输出:
{
"summary": "",
"key_points": [],
"risks": [],
"actions": []
}
约束:
- 只能基于输入材料回答
- 不确定的信息写入 risks,不要猜测
- 每条 actions 必须包含负责人角色、动作和验收标准
- 如果输入不足,先列出需要补充的信息
示例:把会议纪要转成研发任务
你是技术项目经理。请把会议纪要整理成可执行的研发任务。
输出格式:
| 模块 | 任务 | 负责人角色 | 依赖 | 验收标准 | 风险 |
|---|---|---|---|---|---|
要求:
- 任务必须是可以执行的动词短语
- 验收标准必须可检查
- 如果会议纪要没有明确负责人,只写角色,不要编造姓名
- 把争议点单独列到“风险”列
这种提示词的重点不是“让模型自由发挥”,而是把生成任务变成半结构化转换任务。
多模态玩法:图片、截图和视频帧怎么问
多模态输入最容易出问题的地方,是用户把图片丢进去后只问一句“这个怎么样”。模型不知道该看布局、内容、错误、风格,还是业务含义。
可以把多模态任务拆成四种问法。
| 问法 | 适合输入 | 输出结果 |
|---|---|---|
| 识别型 | 截图、票据、图表 | 提取字段、识别元素 |
| 诊断型 | 报错截图、页面异常 | 找原因、列排查路径 |
| 设计型 | 草图、线框图、竞品截图 | 生成页面结构、交互说明 |
| 转换型 | 白板、流程图、手写笔记 | 转成 Markdown、JSON、代码 |
报错截图诊断提示词
你是后端排障工程师。请分析这张报错截图。
输出:
1. 错误类型
2. 关键报错信息
3. 可能原因,按概率从高到低排序
4. 排查命令或检查项
5. 临时止血方案
6. 长期修复方案
要求:
- 如果截图文字不清晰,请指出无法识别的部分
- 不要只给泛泛建议,每条排查项都要能执行
UI 截图转前端需求
你是前端架构师。请根据截图生成页面实现说明。
请输出:
- 页面路由建议
- 组件拆分
- 状态管理设计
- 表单校验规则
- API 数据结构草案
- 空状态、加载态、错误态
- 响应式布局注意事项
约束:
- 截图中无法确认的交互不要补全为确定事实
- API 字段用 camelCase
代码生成:不要让模型一次写完整系统
代码任务要控制边界。模型适合写函数、模块、测试、迁移脚本、排障步骤,但不适合在没有约束的情况下直接生成一个完整生产系统。
更稳的代码生成流程如下:
sequenceDiagram
participant Dev as 开发者
participant Model as Gemini 3
participant Test as 测试工具
Dev->>Model: 给出需求、接口、约束
Model-->>Dev: 返回设计草案
Dev->>Model: 确认数据结构和边界情况
Model-->>Dev: 生成核心代码
Dev->>Test: 执行单元测试
Test-->>Dev: 返回失败用例
Dev->>Model: 提供失败日志
Model-->>Dev: 修复代码并解释原因
生成函数时的提示词
你是 Python 后端工程师。请实现一个函数 parse_price。
函数签名:
def parse_price(text: str) -> int | None
需求:
- 输入可能是 "¥12.30"、"12.3元"、"免费"、"价格待定"、"USD 9.99"
- 只处理人民币
- 返回单位为“分”的整数
- 免费返回 0
- 无法识别人民币价格返回 None
要求:
- 给出完整 Python 代码
- 使用 pytest 写测试用例
- 至少覆盖 8 个边界情况
- 不要依赖第三方库
模型输出后,不要直接合并。至少运行测试,并让模型基于失败结果修正。
import re
def parse_price(text: str) -> int | None:
if not text:
return None
value = text.strip()
if value == "免费":
return 0
if "USD" in value.upper() or "$" in value:
return None
match = re.search(r"(?:¥|¥)?\s*(\d+(?:\.\d{1,2})?)\s*(?:元|人民币)?", value)
if not match:
return None
# 避免把没有人民币语义的纯数字误识别为价格,可按业务需要放宽
has_rmb_signal = any(token in value for token in ["¥", "¥", "元", "人民币"])
if not has_rmb_signal:
return None
amount = float(match.group(1))
return int(round(amount * 100))
单元测试可以直接要求模型补齐:
import pytest
@pytest.mark.parametrize(
"text, expected",
[
("¥12.30", 1230),
("¥12.3", 1230),
("12.30元", 1230),
("人民币 8.88", 888),
("免费", 0),
("价格待定", None),
("USD 9.99", None),
("12.30", None),
("", None),
],
)
def test_parse_price(text, expected):
assert parse_price(text) == expected
这里的重点是:让模型同时给代码和测试,再用测试结果约束下一轮生成。
长上下文任务:先建立索引,再要求结论
长上下文不是把所有材料塞进去就结束。材料越多,越需要输出引用位置和证据,否则模型容易把不同来源的信息混在一起。
处理长文档可以使用三段式提示词。
任务一:从材料中抽取事实
请用表格列出事实、来源位置、可信度,不要做推断。
任务二:基于事实归纳问题
只允许使用任务一中的事实,输出问题列表和影响范围。
任务三:给出行动建议
每条建议必须关联至少一条事实来源。
适合输出成这种结构:
| 事实 | 来源 | 影响 | 可采取动作 |
|---|---|---|---|
| 支付回调存在重试失败记录 | 日志片段 A,第 31-48 行 | 订单状态可能不同步 | 增加回调幂等检查 |
| 订单表缺少状态更新时间索引 | 数据库说明,第 12 行 | 查询慢、补偿任务耗时 | 评估添加联合索引 |
这种方式能减少“看起来有道理但无法追溯”的回答。
Agent 工作流:让模型规划,但不要让它无边界执行
Gemini 3 这类模型可以参与 Agent(智能体)流程:模型负责判断下一步做什么,外部系统负责真正执行搜索、读文件、查数据库、调用接口等动作。
安全的 Agent 结构通常是这样:
flowchart LR
U[用户目标] --> P[模型生成计划]
P --> C{权限检查}
C -->|允许| T[调用工具]
C -->|拒绝| R[返回需要授权]
T --> O[工具结果]
O --> M[模型整理结果]
M --> V[人工或规则校验]
V --> U
不要把所有权限直接交给模型。尤其是涉及删除数据、发邮件、下单、付款、修改线上配置的操作,必须加确认机制。
| 操作类型 | 是否可自动执行 | 建议控制 |
|---|---|---|
| 查询文档 | 可以 | 记录查询来源 |
| 读取日志 | 可以 | 脱敏敏感字段 |
| 生成代码 | 可以 | 必须经过测试 |
| 修改配置 | 谨慎 | 需要人工确认 |
| 删除数据 | 不建议 | 双人审批或禁用 |
| 发送外部消息 | 谨慎 | 预览后确认 |
API 调用示例:把模型接进程序
如果使用 Google 官方 SDK,可以把模型调用封装成一个普通函数。模型名称以控制台实际可用的 Gemini 3 模型 ID 为准。
pip install google-genai
import os
from google import genai
client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])
MODEL = os.getenv("GEMINI_MODEL", "gemini-3")
def ask_gemini(prompt: str) -> str:
response = client.models.generate_content(
model=MODEL,
contents=prompt,
)
return response.text
if __name__ == "__main__":
prompt = """
你是代码审查助手。请检查下面的 Python 函数是否存在边界问题,
并按“问题 / 影响 / 修复建议”输出。
def divide(a, b):
return a / b
"""
print(ask_gemini(prompt))
多模态输入可以把文件和文字一起传入。不同 SDK 版本的文件上传接口可能略有差异,核心思路是:先上传文件,再把文件对象和提示词同时放进 contents。
from google import genai
import os
client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])
MODEL = os.getenv("GEMINI_MODEL", "gemini-3")
image_file = client.files.upload(file="ui-screenshot.png")
prompt = """
请分析这张后台页面截图,并输出:
1. 页面模块
2. 主要交互
3. 前端组件拆分
4. 需要和后端确认的接口字段
"""
response = client.models.generate_content(
model=MODEL,
contents=[image_file, prompt],
)
print(response.text)
在工程里不要把模型返回值直接当成可信数据使用。可以要求模型输出 JSON,再用程序做解析和字段校验。
import json
from pydantic import BaseModel, Field, ValidationError
class TaskItem(BaseModel):
module: str
task: str
acceptance: str
risk: str | None = None
class TaskOutput(BaseModel):
tasks: list[TaskItem] = Field(default_factory=list)
def parse_model_json(text: str) -> TaskOutput:
data = json.loads(text)
return TaskOutput.model_validate(data)
try:
result = parse_model_json(model_text)
except (json.JSONDecodeError, ValidationError) as exc:
# 这里可以触发重试:把错误信息发回模型,要求修正为合法 JSON
print("模型输出不符合结构:", exc)
评估 Gemini 3:用任务集代替主观印象
模型评估要有固定样本,不能只挑成功案例。一个简单但有用的测评集可以包含 20 到 50 个真实任务,覆盖高频场景和失败边界。
| 维度 | 评估问题 | 评分方式 |
|---|---|---|
| 准确性 | 是否基于输入给出正确结论 | 人工标注或标准答案 |
| 完整性 | 是否漏掉关键字段、步骤、风险 | checklist |
| 可执行性 | 输出能否直接进入下一步 | 人工检查 |
| 稳定性 | 同一任务多次输出是否一致 | 多轮采样 |
| 可追溯性 | 结论是否能对应来源 | 引用检查 |
| 成本 | token、时间、调用费用是否可接受 | 程序统计 |
| 安全性 | 是否泄露敏感信息或越权建议 | 规则扫描 |
可以给每个任务记录这样的结果:
{
"case_id": "ui-review-001",
"input_type": "image+text",
"task": "根据后台截图生成前端实现说明",
"score": {
"accuracy": 4,
"completeness": 5,
"actionability": 4,
"traceability": 3
},
"failed_points": [
"把一个不可见字段推断成必填项",
"没有说明加载态"
],
"fix_prompt": "增加约束:只描述截图中可见字段,不确定项写入待确认列表。"
}
这样做的好处很直接:提示词怎么改、模型是否适合上线、哪些任务需要人工复核,都能从记录里看出来。
常见坑和处理办法
1. 只给目标,不给验收标准
“帮我写一个登录功能”太宽泛。登录功能可能涉及密码登录、短信登录、OAuth(开放授权)、风控、验证码、会话管理。模型会自行补全缺失信息,结果往往不符合真实系统。
改成:
实现邮箱密码登录接口,只包含:
- POST /login
- 输入 email 和 password
- 密码使用 bcrypt 校验
- 登录成功返回 JWT
- 连续失败 5 次锁定 10 分钟
- 使用 FastAPI
- 生成 pytest 测试
2. 让模型同时做太多事
一次要求“分析需求、设计数据库、写后端、写前端、写测试、部署上线”,输出会变长,质量也难检查。复杂任务应该拆成多个短任务,每一步都有明确产物。
3. 没有处理不确定性
模型经常会把猜测写得像事实。提示词里要明确要求它区分“确定信息”和“推断信息”。
请把结论分成三类:
- 确定:输入中直接出现的信息
- 推断:基于输入可以合理推测,但没有直接证据
- 待确认:缺少信息,不能判断
4. 忽略隐私和权限
业务文档、日志、截图里可能包含手机号、邮箱、订单号、密钥、客户信息。进入模型前要脱敏:
| 数据类型 | 脱敏方式 |
|---|---|
| 手机号 | 保留前三后四,例如 138****1234 |
| 邮箱 | 隐藏用户名部分,例如 a***@example.com |
| 订单号 | 替换为 order_001 |
| API Key | 删除或替换为 <SECRET> |
| 用户姓名 | 替换为用户 A、用户 B |
5. 不做结果校验
模型输出不是数据库事务,也不是编译器结果。代码要跑测试,JSON 要解析,结论要抽样复核,涉及线上变更的建议要走审批。
一套可直接复用的 Gemini 3 工作流
把 Gemini 3 放进日常研发或内容生产,可以从这个最小流程开始:
flowchart TD
A[选择一个高频任务] --> B[准备 20 个真实样本]
B --> C[写基础提示词]
C --> D[要求结构化输出]
D --> E[人工评分]
E --> F{分数是否稳定}
F -->|否| G[补充约束和反例]
G --> C
F -->|是| H[接入脚本或内部工具]
H --> I[保留日志和失败样本]
I --> J[定期更新提示词]
起步时不要追求“大而全”的智能助手。选择一个明确场景更容易落地,比如:
- 报错日志解释;
- 会议纪要转任务;
- UI 截图转前端需求;
- 代码审查辅助;
- 文档问答;
- 测试用例生成。
每个场景都要定义输入、输出和失败处理方式。模型能力越强,越需要清晰边界;边界清楚,模型才更容易变成稳定工具,而不是一次性的演示效果。