芥末
发布于 2025-11-20 / 0 阅读
0
0

Gemini 3 多模态任务实战:提示词模板、工作流与评估方法

判断 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[根据测试修正实现]

每一步只完成一个明确产物,产物之间用固定格式衔接。

提示词设计:把“想要什么”写成可执行规格

提示词不是越长越好,关键是让模型知道四件事:

  1. 它扮演什么角色;
  2. 输入材料是什么;
  3. 输出必须长什么样;
  4. 什么行为不允许。

一个稳定的提示词可以按这个模板组织:

角色:
你是{领域角色},擅长{能力范围}。

任务:
基于给定材料完成{具体任务}。

输入:
{粘贴材料,或说明图片/文档/代码内容}

输出格式:
请严格按以下结构输出:
{
  "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 截图转前端需求;
  • 代码审查辅助;
  • 文档问答;
  • 测试用例生成。

每个场景都要定义输入、输出和失败处理方式。模型能力越强,越需要清晰边界;边界清楚,模型才更容易变成稳定工具,而不是一次性的演示效果。


评论