1. 从概念到现实：AI报表的“智能”到底意味着什么？

最近几个月，AI编程助手领域可以说是“卷”出了新高度。先是Claude Code横空出世，以其惊艳的代码生成和上下文理解能力，让不少开发者直呼“Copilot有对手了”。紧接着，DeepSeek的V4 Flash模型发布，凭借其强大的推理能力和极低的API成本，迅速成为开源社区和商业应用的新宠。与此同时，像“积木报表”这类低代码/零代码报表工具，也在持续迭代，试图让数据可视化这件事变得更简单。当这三个关键词——Claude Code、DeepSeek、积木报表——被放在一起，并冠以“AI报表”的名头时，一个非常具体且诱人的问题就摆在了我们面前：这玩意儿到底有多“智能”？它能从“玩具”变成真正能在产品里落地的“工具”吗？

作为一个常年和数据、报表、BI系统打交道的从业者，我对任何宣称能“智能”生成报表的技术都抱持着审慎的乐观。过去我们见过太多“智能”的噱头：从早期的模板化报表，到后来的自然语言查询（NLQ），再到现在的AI生成。很多方案要么对数据质量要求极高，要么生成的SQL复杂到无法维护，要么就是生成的图表驴唇不对马嘴，最终沦为演示时的“花瓶”。所以，当我看到Claude Code结合DeepSeek模型，去驱动积木报表这样的工具时，我的第一反应是：这听起来像是一个“缝合怪”，但它缝合的恰好是当前技术栈的几个痛点—— 智能编码（Claude Code）、低成本大模型推理（DeepSeek）、以及一个灵活的前端渲染载体（积木报表） 。

那么，这次实测的目标就很明确了：我不想去复现那些“Hello World”级别的Demo，比如让AI写一句“SELECT * FROM users”。我想做的，是模拟一个真实产品迭代中常见的、中等复杂度的报表需求，从头到尾走一遍，看看这套组合拳能不能打出来，以及打出来的效果如何。这个需求是： “请基于订单表、用户表和商品表，生成一个过去30天按商品类目统计的销售额趋势仪表盘，需要包含趋势折线图、类目销售额占比饼图，并且能按城市维度进行下钻筛选。” 这几乎涵盖了日常报表开发的所有核心环节：多表关联、时间过滤、聚合计算、多种图表类型组合以及交互式筛选。

接下来的内容，就是我围绕这个需求，将Claude Code、DeepSeek和积木报表进行“产品级”整合与实测的完整记录。我会详细拆解每一个环节：环境如何搭建、提示词（Prompt）如何设计才能让AI理解复杂的业务逻辑、生成的代码如何与积木报表对接、过程中遇到了哪些意想不到的“坑”，以及最终产出的报表是否真的达到了“可用”甚至“好用”的标准。如果你也正在评估AI技术对报表开发流程的提效潜力，或者好奇这些热门工具的实际结合能力，那么这篇实测记录或许能给你一些接地气的参考。

2. 环境搭建与工具选型：为什么是Claude Code + DeepSeek + 积木报表？

在开始动手之前，我们必须先理清为什么选择这三者组合，而不是其他方案。这背后是成本、能力、易用性和可控性之间的权衡。

2.1 核心组件深度解析

Claude Code ：它不仅仅是一个VSCode插件，更是一个集成了强大AI助手的开发环境。与GitHub Copilot这类以代码补全见长的工具不同，Claude Code的核心优势在于其出色的 对话式编程 和 超长上下文理解 能力。这意味着我可以像和一个资深同事讨论一样，在编辑器里直接描述我的复杂报表需求，它能够理解整个项目的上下文（包括已有的数据库连接配置、数据模型文件等），并生成逻辑连贯的代码块，而不仅仅是下一行代码。这对于需要生成完整SQL查询、数据处理脚本甚至前端配置的报表任务来说，是至关重要的能力基础。

DeepSeek模型（特别是V4 Flash） ：这是我们整个方案的“大脑”。选择DeepSeek而非OpenAI的GPT-4或Claude 3 Opus，主要基于三个现实考量：

  1. 成本 ：DeepSeek API的定价极具竞争力，对于需要频繁调用、生成大量代码和逻辑的报表开发任务，成本是必须考虑的因素。一次复杂的提示词交互可能消耗数千tokens，使用DeepSeek可以让我们在测试阶段放开手脚，而不必担心账单爆炸。
  2. 能力 ：DeepSeek V4 Flash在代码生成、逻辑推理和指令遵循方面已经达到了顶尖水平。实测中，它对复杂SQL逻辑、Python数据处理pipeline的理解和生成能力，与第一梯队模型相比毫不逊色。
  3. 可控性与未来潜力 ：DeepSeek提供了相对开放的API和清晰的文档，便于我们进行定制化集成。同时，其“本地部署”的可能性（虽然本次实测未采用）也为未来对数据安全有严苛要求的内网场景提供了退路。

积木报表 ：这是一个国产的开源报表工具。选择它，是因为它在“灵活性”和“易用性”之间找到了一个不错的平衡点。与更重的商业BI工具（如Tableau, Power BI）相比，积木报表更轻量，可以很容易地集成到现有的Web应用中。与纯手写ECharts或AntV相比，它又提供了可视化的拖拽配置界面和一套声明式的JSON Schema来描述报表，这正好成为了AI生成的“目标格式”。我们可以让AI直接输出符合积木报表规范的JSON配置，然后导入即可渲染，省去了大量手动编写前端图表代码的工作。

2.2 环境配置实战步骤

明确了选型理由，接下来就是具体的搭建。我的基础环境是macOS，但步骤在Windows/WSL下也基本通用。

第一步：安装并配置Claude Code

  1. 在VSCode的扩展商店中搜索“Claude Code”并安装。
  2. 安装后，侧边栏会出现Claude的图标。点击后，需要登录你的Claude账户（目前需要排队申请或已有权限）。
  3. 关键配置：在Claude Code的设置中，找到“Default Model”或类似选项。 这里就是整个方案的核心连接点——我们需要将Claude Code的“大脑”从默认的Claude 3系列，替换为DeepSeek。
  4. 由于Claude Code原生可能不支持直接切换至DeepSeek，我们需要借助其“自定义模型”或“开发者设置”功能。这通常需要手动配置API Endpoint和API Key。
    • API Endpoint ：填写DeepSeek的官方API地址，例如 https://api.deepseek.com/v1/chat/completions 。
    • API Key ：前往DeepSeek平台注册并获取你的API密钥。
    • 在Claude Code的设置文件（如 settings.json ）中，添加如下配置（具体字段名需查阅Claude Code最新文档）： 
      "claude.code.customModel": {
    "endpoint": "https://api.deepseek.com/v1/chat/completions",
    "apiKey": "your_deepseek_api_key_here",
    "model": "deepseek-chat" // 根据DeepSeek文档使用正确的模型名
}

    注意 ：这一步可能会因Claude Code版本更新而变化。如果官方界面没有提供直接选项，可以尝试搜索“Claude Code custom model provider”相关的社区插件或配置教程。核心思路是让Claude Code这个“客户端”能够将你的对话请求转发到DeepSeek的API，而不是Anthropic的服务器。

第二步：准备测试数据与积木报表环境

  1. 数据库 ：我使用Docker快速启动了一个PostgreSQL容器，并创建了简化版的电商数据库，包含 orders （订单）、 users （用户）、 products （商品）三张表，并填充了模拟数据。
  2. 积木报表 ：从GitHub拉取积木报表的开源版本，按照其文档在本地启动。通常它是一个Spring Boot后端 + Vue前端的项目，使用Docker-compose可以一键启动。确保其服务运行在 http://localhost:8080 。
  3. 关键准备 ：在项目中创建一个 docs 或 specs 文件夹，里面放上数据库的ER图（或简单的表结构说明SQL文件）。这个文件将成为Claude Code理解数据模型的“上下文知识库”，对于生成准确的SQL至关重要。

第三步：验证链路是否打通 在VSCode中，打开Claude Code的聊天面板，问一个简单的问题，比如：“基于我项目 docs/schema.sql 中的表结构，写一个查询用户总数的SQL。” 观察其回复：

  • 如果它能正确引用表名和字段，并生成有效的SQL，说明Claude Code成功读取了项目上下文，并且通过自定义配置连接到了DeepSeek模型。
  • 如果回复无关或报错，则需要检查：1) API Key和Endpoint是否正确；2) 网络是否能访问DeepSeek API；3) Claude Code的上下文文件包含设置是否正确。

至此，我们的“智能报表流水线”的硬件部分就搭建完毕了： VSCode（操作界面） + Claude Code（交互中介） + DeepSeek模型（推理引擎） + 本地数据库（数据源） + 积木报表服务（渲染终端） 。

3. 核心挑战：如何让AI理解并生成“产品级”的报表逻辑？

环境就绪后，真正的挑战才刚刚开始。让AI写一句SQL很简单，但让它理解一个完整的、包含业务规则、多步计算和交互逻辑的报表需求，并输出可运行、可维护的代码，完全是另一回事。这其中的核心在于 “提示词工程” 和 “任务分解” 。

3.1 设计结构化提示词（Prompt）

直接抛出最初那个复杂需求给AI，大概率会得到一个笼统的、可能有错误的代码片段。我们必须像给一个初级开发布置任务一样，将需求拆解成原子步骤，并提供清晰的约束条件。

我设计的核心提示词框架如下，它被分多次输入到Claude Code的对话中，逐步构建上下文：

第一次输入（奠定基础）： 

你是一个资深的数据开发工程师，正在为一个电商系统开发报表。项目根目录下的 `docs/schema.sql` 文件定义了数据库表结构。请仔细阅读该文件，理解 `orders`, `users`, `products` 表之间的关系。

我们的目标是创建一个名为“商品类目销售趋势仪表盘”的报表。请根据我的后续指示，逐步生成所需的SQL查询和积木报表的JSON配置。

首先，请基于schema，用中文列出在这个需求中可能涉及到的所有关键字段，例如：
- orders表: order_id, user_id, product_id, quantity, price, total_amount, city, created_at
- products表: product_id, category_id, category_name, ...
- 等等。
并简要说明它们如何关联。

这个提示词做了几件事：1) 设定了AI的角色；2) 指明了知识来源（schema文件）；3) 明确了最终输出物（SQL和JSON）；4) 用一个具体的子任务（列举字段）来验证AI是否正确理解了数据结构。AI的回复正确与否，是后续所有步骤的基石。

第二次输入（定义具体计算逻辑）： 

很好，你已理解了表结构。现在，我们需要计算“过去30天，按商品类目统计的销售额”。

请生成一个单一的、优化过的SQL查询，满足以下要求：
1.  时间范围：截至当前时间（使用CURRENT_DATE），向前推30天。
2.  关联表：需要连接 orders, products 表以获取类目信息。如果涉及用户城市，则需连接users表。
3.  聚合：按 `products.category_name` 进行分组。
4.  计算：总销售额为 `SUM(orders.quantity * orders.price)`，别名 `total_sales`。同时计算订单数 `COUNT(DISTINCT orders.order_id)`。
5.  排序：按 `total_sales` 降序排列。
6.  请使用CTE（公共表表达式）或子查询来使逻辑更清晰，并添加详细的注释说明每一步。

这一步将核心计算逻辑具体化。要求使用CTE和添加注释，是为了让生成的SQL不仅能用，而且 可读、可维护 。这是“产品级”代码与“演示级”代码的关键区别。AI生成的SQL应该接近一个人类工程师会写出的、考虑了后续可能修改的代码。

第三次输入（引入交互与多图表）： 

以上SQL完美。现在，这个仪表盘需要两个可视化组件和一个筛选器：
组件A：趋势折线图。X轴为过去30天内的每一天（date），Y轴为当日所有类目的销售总额。需要一条SQL查询来支持这个图表。
组件B：类目销售额占比饼图。使用我们第一次查询的结果（按类目聚合的销售额）即可。
筛选器C：一个下拉框，允许用户按“用户所在城市”（`users.city`）来筛选上述所有数据。当城市改变时，趋势图和饼图的数据应联动更新。

请为【组件A】生成新的SQL查询。注意，它也需要支持【筛选器C】的城市过滤条件（假设前端会传递一个 `:selected_city` 参数）。同时，请思考如何组织这些SQL，以便在积木报表中高效调用。

这里开始引入复杂性：多图表、交互筛选、参数传递。我明确要求AI思考“如何组织”，是希望它不仅能给出代码片段，还能给出 架构建议 ，比如是否使用数据库视图、存储过程，或者如何在应用层组织多个查询。

第四次输入（生成积木报表配置）： 

现在，请基于我们已讨论出的所有SQL查询（核心类目聚合查询、按日趋势查询），生成一个积木报表（JimuReport）可导入的JSON配置文件。

要求：
1.  报表应包含两个数据集（Dataset）：一个对应“类目销售汇总”，一个对应“每日销售趋势”。数据集配置中需包含我们商定的SQL，并正确处理城市筛选参数。
2.  报表画布上应有两个组件：
    - 一个折线图，绑定“每日销售趋势”数据集，X轴为日期，Y轴为销售额。
    - 一个饼图，绑定“类目销售汇总”数据集。
3.  一个下拉框筛选器，数据源来自 `users` 表的 `city` 字段（去重），其值变化应能同时刷新两个图表的数据集。
4.  请严格按照积木报表的JSON Schema规范生成。你可以参考积木报表官方文档中关于“数据集”、“图表组件”、“参数”的定义格式。

这是最后的临门一脚，将逻辑转化为最终可交付的产物。要求“严格按照JSON Schema”，是避免AI输出一个看似正确但无法导入的配置。这迫使AI必须在其训练数据中包含或能推理出积木报表配置的大致结构。

3.2 AI的响应与“思维过程”评估

在整个交互过程中，Claude Code + DeepSeek 的表现有亮点也有不足。

亮点：

  1. 上下文记忆能力极强 ：在长达十几轮的对话中，AI能牢牢记住之前定义的字段名、表别名、计算逻辑，并在后续的SQL中保持一致。这大大减少了重复解释的成本。
  2. 逻辑推理能力合格 ：对于“按城市筛选后，趋势图数据如何变化”这类问题，AI能准确理解需要在趋势查询的SQL的WHERE子句中加入 AND users.city = :selected_city 的条件，并且知道在关联 users 表时注意避免因连接方式导致数据膨胀或丢失。
  3. 代码质量超出预期 ：生成的SQL不仅语法正确，而且确实按照要求使用了CTE来组织逻辑。例如，它先创建一个CTE来过滤出过去30天的订单明细，再进行关联和聚合，使得SQL结构非常清晰。注释也写得有模有样，解释了每个CTE的作用。

不足与需要人工干预的地方：

  1. 对特定工具（积木报表）的细节知识有限 ：虽然能生成大致的JSON结构，但积木报表一些特定的配置项（如图表主题色配置项、数据映射的特定字段名 source 、 target ）AI无法准确给出。它生成的JSON是一个“通用”的图表配置，需要我对照积木报表的文档进行微调。这提示我们， AI更适合生成核心逻辑代码，而针对特定框架、工具的粘合层代码，仍需开发者具备相关知识 。
  2. 对极端边界条件考虑不足 ：例如，当 :selected_city 参数为空（即选择“全部城市”）时，AI生成的SQL逻辑是 AND users.city = :selected_city ，这会导致查询无结果。需要我手动提示它修改为 AND (:selected_city IS NULL OR users.city = :selected_city) 。这是业务逻辑的细微之处，AI第一次很难自己想到。
  3. 无法自主进行性能优化 ：对于是否应该为 created_at , city , category_id 等字段创建索引，AI不会主动提出建议。它只负责完成功能逻辑。

这个过程给我的核心经验是： 你不能指望AI一次性接受一个完整的需求并吐出完美结果。你必须扮演“产品经理+架构师”的角色，将需求分解为原子任务，并持续提供精确的反馈和约束条件。 AI是一个能力超强的“执行者”，但方向和细节的把握，仍然在人的手中。

4. 集成与调试：将AI输出转化为可运行的仪表盘

经过多轮对话，我们获得了关键的产出物：两个精心编写的SQL查询文件，和一个接近可用的积木报表JSON配置骨架。接下来，就是将这些部件组装起来，并在真实环境中运行调试。

4.1 数据层：SQL验证与优化

首先，我将AI生成的两个核心SQL在数据库客户端（如DBeaver或psql）中直接执行，进行验证。

类目销售汇总SQL示例（经过人工微调后）： 

WITH recent_orders AS (
    SELECT 
        o.order_id,
        o.user_id,
        o.product_id,
        o.quantity,
        o.price,
        o.total_amount,
        o.city AS order_city, -- 订单表可能也有城市，但以用户为主
        o.created_at,
        u.city AS user_city
    FROM orders o
    LEFT JOIN users u ON o.user_id = u.user_id
    WHERE o.created_at >= CURRENT_DATE - INTERVAL '30 days'
      AND o.created_at < CURRENT_DATE + INTERVAL '1 day' -- 避免时间边界问题
),
sales_by_category AS (
    SELECT 
        p.category_name,
        SUM(ro.quantity * ro.price) AS total_sales,
        COUNT(DISTINCT ro.order_id) AS order_count,
        ro.user_city -- 为筛选准备
    FROM recent_orders ro
    JOIN products p ON ro.product_id = p.product_id
    WHERE (:selected_city IS NULL OR ro.user_city = :selected_city)
    GROUP BY p.category_name, ro.user_city
)
SELECT 
    category_name,
    total_sales,
    order_count
FROM sales_by_category
ORDER BY total_sales DESC;

验证要点：

  1. 语法正确性 ：在PostgreSQL中运行，确认无语法错误。
  2. 逻辑正确性 ：检查结果数据。例如，手动计算某个类目在特定城市下的销售总和，与SQL结果对比。
  3. 参数处理 ：测试 :selected_city 参数。分别传入 NULL （代表全部）、一个存在的城市名、一个不存在的城市名，观察结果是否符合预期。这里就发现了之前提到的边界条件问题，并已修正。
  4. 性能初探 ：使用 EXPLAIN ANALYZE 查看查询计划。发现由于在 recent_orders CTE中进行了 LEFT JOIN users ，且后续的 WHERE 子句涉及 user_city ，导致未能有效利用索引。 这是一个AI未能考虑的优化点。 我手动优化了查询顺序，先过滤订单，再关联用户，并确保相关字段有索引。

这个过程表明， AI生成的SQL在功能正确性上表现良好，但生产级的性能调优仍需数据库专家的经验 。AI可以写出“正确”的代码，但“高效”的代码需要额外的知识和干预。

4.2 应用层：积木报表配置的“最后一公里”

接下来，将调整好的SQL和AI生成的JSON骨架，导入到积木报表的设计器中。

  1. 创建数据源 ：在积木报表后台，配置指向我们测试数据库的连接。
  2. 创建数据集 ：
    • 新建数据集“ds_category_sales”，将上述“类目销售汇总SQL”粘贴进去，并定义参数 selected_city 。
    • 新建数据集“ds_daily_trend”，粘贴“每日销售趋势SQL”，同样定义 selected_city 参数。
    • 在界面上点击“测试”，确保两个数据集都能正常返回数据，并且参数联动生效。
  3. 设计报表 ：
    • 将AI生成的JSON中的图表配置部分，与积木报表设计器的组件进行对照。AI生成的配置可能类似于： 
      {
  "components": [
    {
      "type": "chart",
      "name": "trend_chart",
      "dataset": "ds_daily_trend",
      "config": {
        "xAxis": {"field": "date", "type": "time"},
        "yAxis": {"field": "daily_sales"},
        "type": "line"
      }
    },
    ...
  ]
}
    • 然而，积木报表的实际配置方式是通过可视化拖拽生成一个内部的JSON结构，与AI猜测的格式不完全一致。我采取的策略是： 利用AI生成的配置作为“蓝图”，在积木报表设计器中手动创建对应的折线图和饼图组件，然后按照“蓝图”来配置数据绑定和图表选项。
    • 例如，在折线图组件的“数据”选项卡中，选择数据集“ds_daily_trend”，并设置“分类轴”为日期字段，“系列”为销售额字段。这个过程需要我对积木报表的设计器有一定了解。
  4. 配置交互 ：
    • 在积木报表中，添加一个“下拉框”筛选器组件。
    • 设置其“数据字典”为另一个独立的SQL查询 SELECT DISTINCT city FROM users ORDER BY city 。
    • 最关键的一步：设置该下拉框的“联动”属性。将其与“ds_category_sales”和“ds_daily_trend”两个数据集关联，并将下拉框的值映射到这两个数据集的 selected_city 参数上。
    • 这样，当用户选择不同城市时，两个图表的数据集会自动刷新。

这个阶段最大的体会是：AI极大地加速了“从零到蓝图”的过程，但“从蓝图到成品”的细节打磨，尤其是与特定工具深度集成部分，仍然离不开人的工作。 AI提供的是一个90%正确的方向和大量可复用的代码片段，但最后10%的适配工作，决定了这个报表能否真正上线使用。

5. 实测总结：AI报表的智能边界与未来展望

经过从环境搭建、需求拆解、提示词对话、代码生成到集成调试的完整闭环，这个由Claude Code、DeepSeek和积木报表组合而成的“AI报表流水线”交上了一份怎样的答卷？

首先，它确实展现出了令人印象深刻的“智能”潜力。

  • 开发效率的飞跃 ：传统方式下，完成这样一个包含多表复杂关联、交互筛选和多图表的仪表盘，从理解需求、编写SQL、调试、到在前端报表工具中配置，至少需要半天到一天的时间。而借助AI，我将大量“翻译”工作（从自然语言需求到SQL逻辑，再到图表配置思路）交给了模型，自己则专注于需求分解、结果校验和细节调优。整个流程被压缩到了2-3小时内，效率提升是肉眼可见的。
  • 代码质量的“高起点” ：AI生成的SQL，在结构清晰度、注释完整性方面，甚至优于部分初级开发人员的手写代码。它遵循了良好的实践（如使用CTE），为后续的维护和修改打下了不错的基础。
  • 降低了专业壁垒 ：一个对SQL不熟悉但对业务非常了解的产品经理或业务分析师，理论上可以通过与Claude Code的持续对话，逐步“描述”出他们想要的报表逻辑，并由AI生成可执行的代码。这为“全民开发”报表提供了一种新的可能路径。

然而，当前的“智能”仍有清晰的边界，远未达到“全自动”的程度。

  1. 高度依赖“人”的引导与审核 ：AI是一个强大的“副驾驶”，但绝不是“自动驾驶”。整个过程中最耗费心力的部分，恰恰是设计精准的提示词、分解任务、以及审核AI的输出。你需要对业务逻辑、数据模型、SQL乃至目标报表工具有足够深的理解，才能判断AI生成的内容是否正确、是否最优，并给出有效的反馈。如果提问者自己都是模糊的，AI的输出必然也是混乱的。
  2. 对特定工具链的“知识盲区” ：正如实测中遇到的，AI对积木报表这种特定工具的细节配置了解有限。它擅长通用逻辑（SQL，JavaScript），但在与具体框架、API的对接上，需要开发者提供“规范”或进行手动适配。这意味着， AI目前是“高级代码生成器”，而非“全栈解决方案交付器” 。
  3. 缺乏业务洞察与性能优化意识 ：AI可以根据指令生成查询，但它不会主动问：“我们为什么要看过去30天的数据？7天滚动平均会不会更好？” 它也不会主动建议：“这个查询在数据量大了以后会很慢，应该在 created_at 和 city 上建联合索引。” 这些涉及业务价值判断和深度性能优化的部分，仍然是人类专家的核心领域。
  4. 调试过程依然存在 ：将AI生成的部件组装起来时，依然会遇到参数传递错误、数据格式不匹配、图表渲染异常等经典问题。调试这些问题的过程，与传统开发并无二致。

那么，AI报表的未来在哪里？

我认为，它不会在短期内完全取代数据分析师或报表开发工程师。相反，它会演变成一个 强大的“能力放大器” 。未来的工作流可能会是这样：

  • 需求澄清阶段 ：业务人员与AI对话，快速生成报表原型和可视化草图，帮助双方对齐需求，避免“我以为你要的是A，结果你做出来是B”的沟通成本。
  • 开发实现阶段 ：开发者利用AI，将已对齐的需求快速转化为高质量、注释完整的初始代码（SQL、API、配置模板），然后将主要精力投入到 业务逻辑复核、性能调优、异常边界处理、以及与现有系统架构的集成 这些高价值工作上。
  • 维护与迭代阶段 ：当业务逻辑变更时，开发者可以要求AI基于原有的、结构清晰的代码进行修改，并生成修改说明，极大提升维护效率。

回到最初的问题：“AI报表到底有多智能？” 我的结论是： 它已经足够智能，能够将报表开发中大量重复性、模式化的“翻译”和“编写”工作自动化，从而将人类从繁琐的代码劳动中解放出来。但它智能的边界，止步于人类对问题的精准定义和对领域的深刻理解。 今天，它已经是一个能让你“做得更快”的利器；而未来，随着多模态能力和对复杂系统理解力的提升，它或许能帮助我们“想得更深”，但那条路上，依然需要人类掌舵。对于想要尝试的团队，我的建议是：拥抱它，学习如何更好地与它协作（尤其是提示词技巧），但同时，夯实自己在业务和数据领域的基本功，因为那才是你不可替代的价值所在。

# DeepSeek
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

别再只聊大模型！AI的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区
cover

别再只聊大模型！人工智能的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区
cover

别再只聊大模型！AI的下一场革命，藏在“身体”里

avatar 亚马逊云科技技术品牌专区