¥
立即购买

数据库数据检索指导专家

29 浏览
2 试用
0 购买
Dec 3, 2025更新

本提示词专为数据库管理和数据检索场景设计,能够根据用户指定的数据库类型、检索方法和工具,生成专业、准确的数据检索指导方案。提示词采用结构化工作流程,涵盖需求分析、方法选择、指令生成和优化建议四个关键环节,确保输出的检索指令具备技术精确性、操作可行性和安全性考量。适用于数据库管理员、数据分析师和开发人员在不同数据库环境下进行高效数据检索的场景,能够显著提升数据查询的准确性和效率。

检索需求概述

  • 目标:查询近 7 天新注册且 email_verified=false 的用户
  • 输出字段:user_id、email、注册时间、来源渠道
  • 排序:按注册时间倒序(必要时以 user_id 作为次序以保证稳定性)
  • 限制:最多返回 500 条
  • 运行位置:只读副本(Read Replica)
  • 额外要求:说明适配索引方案、只读副本执行方式,并提供校验与回滚建议

数据库环境说明

  • 数据库:MySQL(5.7 或 8.0,建议 8.0+)
  • 时区:如 created_at 存 UTC,建议会话设为 UTC 再查询;若为本地时区,改用 NOW()
  • 权限:只需对目标库表的 SELECT 权限(可选:EXPLAIN、SHOW INDEX)
  • 副本:建议在只读副本执行,并使用只读事务+一致性读,避免对主库造成压力

具体检索指令

说明:

  • 以下假定表名为 users,字段为 user_id、email、created_at(注册时间)、source_channel(来源渠道)、email_verified(TINYINT(1) 或 BOOLEAN)。
  • 如命名不同,请按实际字段替换。
  • 若 created_at 存储为 UTC,建议使用 UTC_TIMESTAMP();否则使用 NOW()。
  1. 在只读副本执行的查询(含一致性读与稳定排序)
-- 建议先在会话中设置时区(如果 created_at 为 UTC)
SET SESSION time_zone = '+00:00';

-- 一致性只读事务
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION READ ONLY;

-- 可选:查看执行计划以确认走索引
EXPLAIN ANALYZE
SELECT
  user_id,
  email,
  created_at AS registered_at,
  source_channel
FROM users
WHERE email_verified = 0
  AND created_at >= (UTC_TIMESTAMP() - INTERVAL 7 DAY)  -- 若使用本地时区,改为 NOW()
ORDER BY created_at DESC, user_id DESC
LIMIT 500;

COMMIT;
  1. 索引建议(由 DBA 在维护窗口、测试评估后再上生产)
  • 首选通用复合索引(兼顾过滤与排序):
-- 示例DDL:请先在测试环境验证,确认无冲突后再由DBA上线
-- 该索引支持 WHERE email_verified=0 AND created_at范围过滤,并避免或减少 filesort
ALTER TABLE users
  ADD INDEX idx_users_emailver_createdat_uid (email_verified, created_at, user_id);
  • 若该查询非常高频且表很宽,为尽量实现覆盖索引(减少回表),可添加包含输出列的复合索引(权衡磁盘与写入成本):
-- 覆盖索引示例(体积较大,慎用)
ALTER TABLE users
  ADD INDEX idx_users_emailver_createdat_cov (email_verified, created_at, user_id, email, source_channel);
  • 说明:
    • MySQL 可逆向扫描索引,通常无需显式 DESC 索引;若为 MySQL 8.0+ 且确需,可考虑 created_at DESC。
    • 添加索引会增加写入开销与存储占用,需评估实际负载。
    • 若已有等价或更优的复合索引(如 (email_verified, created_at)),可先用现有索引,无需新增。

执行步骤说明

  1. 确认表结构与时区
    • 确认 users 表及字段名是否与示例一致。
    • 确认 created_at 的时区(UTC 或本地)。若为 UTC,设置 SESSION time_zone = '+00:00' 并使用 UTC_TIMESTAMP()。
  2. 在只读副本连接
    • 使用只读账号连接到只读副本,避免主库压力。
  3. 开启只读一致性事务
    • SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ; START TRANSACTION READ ONLY;
  4. 检查执行计划
    • 使用 EXPLAIN 或 EXPLAIN ANALYZE 确认使用到 (email_verified, created_at[, user_id]) 索引,避免全表扫描与 filesort。
  5. 执行查询
    • 按上面的 SELECT 语句执行,限制 LIMIT 500。
  6. 如需分页或批量导出
    • 使用稳定排序键(created_at DESC, user_id DESC)并采用基于游标/锚点的“seek pagination”(WHERE (created_at, user_id) < (last_created_at, last_user_id))。
  7. 结束事务
    • COMMIT; 释放一致性快照。

预期结果描述

  • 返回不超过 500 行,包含字段:user_id、email、registered_at、source_channel。
  • 只包含近 7 天内注册且 email_verified=0 的用户。
  • 结果按 created_at 倒序,遇到相同时刻按 user_id 倒序,保证稳定顺序。
  • 在有合适索引与只读副本的情况下,查询应为低延迟、对线上无写入影响。

注意事项提醒

  • 性能与索引
    • 优先使用复合索引 (email_verified, created_at[, user_id]),可显著降低扫描与排序成本。
    • 覆盖索引提升查询但会增大索引体量与写入成本,仅在高频/延迟敏感场景采用。
    • 若 EXPLAIN 显示 Using filesort 或全表扫描,请评估新增索引或改写查询(例如加上次序键 user_id)。
  • 时区一致性
    • 确认 created_at 的时区,UTC 数据用 UTC_TIMESTAMP();避免因时区导致的 7 天窗口偏差。
  • 数据类型与空值
    • email_verified 常为 TINYINT(1),用 email_verified=0 即可;若可能为 NULL 表示未验证,可使用 COALESCE(email_verified,0)=0。
  • 只读副本一致性
    • 副本存在复制延迟时,最新几分钟的数据可能未同步;如严格实时,需权衡在主库执行(风险更高,不推荐常规使用)。
  • 校验建议
    • 统计校验:先做计数对比,确保数量级合理
      • SELECT COUNT(*) FROM users WHERE email_verified=0 AND created_at >= UTC_TIMESTAMP() - INTERVAL 7 DAY;
    • 采样校验:随机抽样数条结果,核对业务端(注册时间、验证状态)是否一致。
    • 执行计划校验:EXPLAIN/EXPLAIN ANALYZE 确认使用到预期索引(key=idx_users_emailver_createdat_uid),避免全表扫描。
    • 时间窗口校验:固定边界测试,如将时间边界改为一个已知时间点,验证包含/排除是否符合预期。
  • 回滚建议
    • 查询本身为只读,无需回滚;结束只读事务即可。
    • 若上线了新索引且需回退:
      • 先确认其他查询未依赖该新索引(通过 performance_schema.events_statements_history 或 EXPLAIN 回归检查)。
      • 在低峰期由 DBA 执行回退: ALTER TABLE users DROP INDEX idx_users_emailver_createdat_uid; -- 或相应索引名
      • 回退前后对关键查询做基准对比,确认性能可接受。
  • 安全与权限
    • 使用只读账号,限制仅对所需库表的 SELECT 权限。
    • 禁止在生产主库执行未评估的 DDL;所有 DDL 先在测试/影子环境验证,由 DBA 执行变更。

检索需求概述

  • 目标:从 payment-* 索引中检索近 24 小时支付失败日志,条件为 status=failed 且 amount>0
  • 输出:
    • 返回原始样例 10 条(按时间倒序)
    • 聚合 Top10 error_code 及出现次数
  • 用途:用于告警阈值调整与接口排障

数据库环境说明

  • 数据库类型:Elasticsearch(通过 REST API 调用)
  • 索引模式:payment-*
  • 时间字段假定为 @timestamp(如实际字段不同请替换)
  • 字段类型建议:
    • status:keyword(或使用 status.keyword 子字段)
    • error_code:keyword(或使用 error_code.keyword 子字段)
    • amount:numeric(integer/long/double)
  • 权限要求(最小化):对 payment-* 拥有 indices:data/read/search 权限

具体检索指令

说明:以下请求在 24 小时窗口内进行过滤,按时间倒序返回 10 条原始样例,同时计算 Top10 error_code 的计数。考虑到国内常见东八区,可在 range 中配置 time_zone(若 ES 集群使用 UTC 或您希望使用 UTC,则可移除 time_zone)。

cURL 示例: curl -s -X POST "https://:9200/payment-*/_search?ignore_unavailable=true&allow_no_indices=true"
-H "Content-Type: application/json"
-H "Authorization: ApiKey <your_api_key>"
-d '{ "track_total_hits": true, "size": 10, "sort": [ { "@timestamp": { "order": "desc" } } ], "query": { "bool": { "filter": [ { "range": { "@timestamp": { "gte": "now-24h", "lt": "now", "time_zone": "+08:00" } } }, { "term": { "status.keyword": "failed" } }, { "range": { "amount": { "gt": 0 } } } ] } }, "aggs": { "top_error_code": { "terms": { "field": "error_code.keyword", "size": 10, "order": { "_count": "desc" }, "missing": "MISSING" } } } }'

Kibana Dev Tools 控制台(如无需鉴权与协议): GET payment-*/_search?ignore_unavailable=true&allow_no_indices=true { "track_total_hits": true, "size": 10, "sort": [ { "@timestamp": { "order": "desc" } } ], "query": { "bool": { "filter": [ { "range": { "@timestamp": { "gte": "now-24h", "lt": "now", "time_zone": "+08:00" } } }, { "term": { "status.keyword": "failed" } }, { "range": { "amount": { "gt": 0 } } } ] } }, "aggs": { "top_error_code": { "terms": { "field": "error_code.keyword", "size": 10, "order": { "_count": "desc" }, "missing": "MISSING" } } } }

可选优化(若仅需关键字段而非完整原始 _source,可加快传输并减少内存占用):

  • 增加 _source 过滤(示例) "_source": ["@timestamp","order_id","user_id","status","amount","error_code","message"]

执行步骤说明

  1. 确认字段与映射
    • 确认时间字段为 @timestamp,否则替换为实际字段
    • 确认 status、error_code 为 keyword 类型(或使用 .keyword 子字段)
    • 确认 amount 为 numeric 类型
  2. 在具备相应读权限的环境中执行 cURL 或在 Kibana Dev Tools 运行请求
  3. 若索引可能不存在或当天无数据,保留 ignore_unavailable=true 与 allow_no_indices=true 避免报错
  4. 根据返回的聚合结果与样例日志,分析错误分布与典型失败样例,用于告警阈值调整与排障
  5. 如需特定时区统计,调整 time_zone;如使用 UTC,删除 time_zone 参数

预期结果描述

  • hits.total:满足过滤条件的失败日志总量(track_total_hits=true 时为精确计数)
  • hits.hits:返回 10 条最新的失败日志原始文档
  • aggregations.top_error_code.buckets:长度最多为 10 的桶数组,元素示例:
    • key:具体 error_code 值(或 "MISSING" 表示文档无该字段)
    • doc_count:该 error_code 对应的失败次数 示例: "aggregations": { "top_error_code": { "buckets": [ { "key": "PAY_1001", "doc_count": 532 }, { "key": "PAY_TIMEOUT", "doc_count": 417 }, ... ] } }

注意事项提醒

  • 字段映射
    • 若 status 或 error_code 为 text 类型,请使用其 keyword 子字段(如 status.keyword),避免 terms 聚合报错或性能问题
    • amount 必须为数值类型,否则 range 查询会失败
  • 时区与时间窗口
    • 使用 time_zone 对齐业务时区(如 +08:00),否则使用 UTC
    • 如需固定窗口(非 rolling 24h),可用固定时间范围:"gte": "2025-12-02T00:00:00+08:00", "lt": "2025-12-03T00:00:00+08:00"
  • 性能优化
    • 已使用 bool.filter 走 filter context,可被缓存,性能优于 must+term
    • terms 聚合对高基数字段内存消耗较大,size=10 已限制返回;如基数极高且内存紧张,可在 off-peak 时段执行或改用采样策略(search.sample)
    • 如仅调试样例,可去掉 track_total_hits 或设为整型阈值以降低计算成本
  • 结果准确性
    • 使用 track_total_hits=true 以获取准确总数,便于告警阈值对齐
    • 索引滚动或延迟写入可能导致 near-real-time 偏差,若对一致性敏感,可在查询前刷新:POST payment-*/_refresh(需谨慎使用,避免频繁刷新带来开销)
  • 安全与权限
    • 仅在授权范围内访问 payment-* 索引
    • 不要在生产上使用过大的 size 或无必要的大字段 _source 返回,避免泄露信息与资源消耗

如需把结果转为可直接用于告警的结构(例如只返回 top N 的 error_code + 计数与 total),可在当前检索基础上增加对返回 JSON 的二次处理;如需我输出一个 jq/脚本示例可继续告知。

  • 检索需求概述

    • 目标:导出近30天的高风险登录事件
    • 判定条件:IP在黑名单 或 用户在该IP上的最大连续失败次数 ≥ 5
    • 输出字段:user_id、ip、失败次数(最大连续失败次数)、最后失败时间(该最大连续失败序列的最后时间)
    • 排序与限制:按失败次数降序(同分再按最后失败时间降序),限制2000条
  • 数据库环境说明

    • 数据库:MongoDB(建议版本≥5.0,以使用$setWindowFields窗口函数)
    • 源集合:login_events
      • 假设字段:
        • user_id:用户标识
        • ip:来源IP
        • status:'success' 或 'failure'
        • ts:时间戳(Date)
    • 黑名单集合(推荐):ip_blacklist(字段:ip,唯一索引)
    • 如无黑名单集合,可在执行层以数组参数传入黑名单IP列表
  • 具体检索指令

    • 说明:

      • 使用窗口函数计算每个(user_id, ip)分区内的“连续失败序列”,并取该分区的最大连续失败次数及其最后失败时间。
      • 将黑名单标记融入事件流后,在分区聚合结果上筛选:is_blacklisted=true 或 failure_count≥5。
      • 输出最终结果并限制为2000条。
    • 聚合管道(MongoDB 5.0+,mongosh中执行;根据实际字段名调整):

      // 近30天起始时间
      const since = new Date(Date.now() - 30*24*60*60*1000);
      
      db.login_events.aggregate([
        // 1) 近30天过滤
        { $match: { ts: { $gte: since } } },
      
        // 2) 标记黑名单(使用集合 ip_blacklist,若无请见下方“无集合黑名单写法”)
        { $lookup: {
            from: "ip_blacklist",
            localField: "ip",
            foreignField: "ip",
            as: "bl"
        }},
        { $addFields: { is_blacklisted: { $gt: [ { $size: "$bl" }, 0 ] } } },
        { $project: { bl: 0 } },
      
        // 3) 按(user_id, ip, ts)排序,为窗口函数准备
        { $sort: { user_id: 1, ip: 1, ts: 1 } },
      
        // 4) 窗口函数:计算“成功次数”的前缀和作为失败序列的分组键(resetGroup)
        { $setWindowFields: {
            partitionBy: { user_id: "$user_id", ip: "$ip" },
            sortBy: { ts: 1 },
            output: {
              resetGroup: {
                $sum: {
                  $cond: [ { $eq: [ "$status", "success" ] }, 1, 0 ]
                },
                window: { documents: [ "unbounded", "current" ] }
              }
            }
        }},
      
        // 5) 我们只关心失败事件来构成“连续失败序列”
        { $match: { status: "failure" } },
      
        // 6) 聚合得到每个失败序列(被success分隔)的长度与最后失败时间
        { $group: {
            _id: { user_id: "$user_id", ip: "$ip", resetGroup: "$resetGroup" },
            failure_count: { $sum: 1 },
            last_failure_time: { $max: "$ts" },
            is_blacklisted: { $max: "$is_blacklisted" }
        }},
      
        // 7) 对每个(user_id, ip)选出“最大连续失败序列”(同长度取最后失败时间更晚的)
        { $sort: { "_id.user_id": 1, "_id.ip": 1, failure_count: -1, last_failure_time: -1 } },
        { $group: {
            _id: { user_id: "$_id.user_id", ip: "$_id.ip" },
            failure_count: { $first: "$failure_count" },
            last_failure_time: { $first: "$last_failure_time" },
            is_blacklisted: { $first: "$is_blacklisted" }
        }},
      
        // 8) 高风险筛选:IP在黑名单 或 最大连续失败次数≥5
        { $match: { $or: [ { is_blacklisted: true }, { failure_count: { $gte: 5 } } ] } },
      
        // 9) 结果整形、排序与限制
        { $project: {
            _id: 0,
            user_id: "$_id.user_id",
            ip: "$_id.ip",
            failure_count: 1,
            last_failure_time: 1
        }},
        { $sort: { failure_count: -1, last_failure_time: -1 } },
        { $limit: 2000 }
      ], { allowDiskUse: true });
      
    • 若无黑名单集合(在mongosh中以数组变量传入):

      const since = new Date(Date.now() - 30*24*60*60*1000);
      const blackIps = [ /* "1.2.3.4", "5.6.7.8", ... */ ];
      
      db.login_events.aggregate([
        { $match: { ts: { $gte: since } } },
        { $addFields: { is_blacklisted: { $in: [ "$ip", blackIps ] } } },
        { $sort: { user_id: 1, ip: 1, ts: 1 } },
        { $setWindowFields: {
            partitionBy: { user_id: "$user_id", ip: "$ip" },
            sortBy: { ts: 1 },
            output: {
              resetGroup: {
                $sum: { $cond: [ { $eq: [ "$status", "success" ] }, 1, 0 ] },
                window: { documents: [ "unbounded", "current" ] }
              }
            }
        }},
        { $match: { status: "failure" } },
        { $group: {
            _id: { user_id: "$user_id", ip: "$ip", resetGroup: "$resetGroup" },
            failure_count: { $sum: 1 },
            last_failure_time: { $max: "$ts" },
            is_blacklisted: { $max: "$is_blacklisted" }
        }},
        { $sort: { "_id.user_id": 1, "_id.ip": 1, failure_count: -1, last_failure_time: -1 } },
        { $group: {
            _id: { user_id: "$_id.user_id", ip: "$_id.ip" },
            failure_count: { $first: "$failure_count" },
            last_failure_time: { $first: "$last_failure_time" },
            is_blacklisted: { $first: "$is_blacklisted" }
        }},
        { $match: { $or: [ { is_blacklisted: true }, { failure_count: { $gte: 5 } } ] } },
        { $project: { _id: 0, user_id: "$_id.user_id", ip: "$_id.ip", failure_count: 1, last_failure_time: 1 } },
        { $sort: { failure_count: -1, last_failure_time: -1 } },
        { $limit: 2000 }
      ], { allowDiskUse: true });
      
  • 执行步骤说明

    1. 校验与准备
      • 确认字段名与取值:status是否为'success'/'failure',时间字段是否为ts且类型为Date。
      • 确认MongoDB版本≥5.0;若低于5.0,见“注意事项”中替代方案。
    2. 索引优化(提升排序与窗口分区性能)
      • login_events:
        db.login_events.createIndex({ user_id: 1, ip: 1, ts: 1 });
        // 可选:若ts过滤很强、并发低,可并建 { ts: 1 } 辅助过滤
        
      • ip_blacklist:
        db.ip_blacklist.createIndex({ ip: 1 }, { unique: true });
        
    3. 在测试环境先小样本验证
      • 将$limit暂时改为50,检查字段含义、结果正确性。
    4. 生产运行与导出建议
      • 若需导出CSV,推荐将聚合结果写入临时集合后用mongoexport导出:
        // 在聚合末尾追加$merge
        { $merge: { into: "tmp_high_risk_login_events_30d", whenMatched: "replace", whenNotMatched: "insert" } }
        
        然后执行导出:
        mongoexport \
          --uri="mongodb://<user>:<pass>@<host>/<db>?authSource=<db>" \
          --collection=tmp_high_risk_login_events_30d \
          --type=csv \
          --fields=user_id,ip,failure_count,last_failure_time \
          --out=high_risk_login_events_last30d.csv
        
        导出完成后可清理临时集合:
        db.tmp_high_risk_login_events_30d.drop();
        
      • 若直接在应用层消费JSON结果,可省略$merge,直接在驱动中执行aggregate并分页/流式写出。
  • 预期结果描述

    • 每条记录对应一个(user_id, ip)在近30天内的“最大连续失败序列”摘要:
      • user_id:用户标识
      • ip:来源IP
      • failure_count:该用户在该IP上的最大连续失败次数
      • last_failure_time:该最大连续失败序列的最后一次失败时间
    • 仅包含满足“IP在黑名单或最大连续失败次数≥5”的记录
    • 按failure_count降序,若相同则按last_failure_time降序,最多2000条
  • 注意事项提醒

    • 版本要求:$setWindowFields需MongoDB≥5.0。若为4.4或更低:
      • 可用$group+$push收集分区事件后用$function(4.4+)在服务端JS计算最长失败序列,但对大数据量不友好;
      • 或按(user_id, ip, ts)从服务端流式读取,改由应用层一次扫描计算最长连续失败序列(更可控)。
    • 语义说明:
      • 本方案将“失败次数”定义为“最大连续失败次数”;“最后失败时间”为该连续失败序列的最后一次失败时间。
      • 黑名单IP即使未达到5次连续失败,只要有失败记录,也会出现在结果中;若某黑名单IP在近30天无失败,则不会输出(因无失败次数与最后失败时间数据)。
      • 如需改为“黑名单IP无失败也输出(失败次数=0,时间为空)”,需在第5步前移除对失败的$match,并在后续分支单独处理无失败情况。
    • 性能与资源:
      • 打开allowDiskUse: true,避免窗口与排序阶段内存溢出。
      • 建议离峰时段运行,必要时按时间分片或分批用户进行。
      • 大规模$lookup请确保ip_blacklist体量小且有{ip:1}索引。
    • 数据安全:
      • 仅导出所需字段;避免在管道中泄露敏感信息。
      • 先在测试环境验证,再在生产执行;遵循最小权限原则(只读账号执行检索与导出)。

示例详情

解决的问题

把“我需要什么数据”快速转化为“马上可执行的检索方案”。该提示词面向多数据库环境,帮助数据分析师、开发者与DBA在最短时间内获得清晰、可靠、可落地的查询指令与操作步骤,减少试错、规避风险、提升检索命中率与执行速度。

  • 一次搞定多库检索:同一个需求,不同数据库都能给出对口方案
  • 以结果为导向:明确要查什么、怎么查、如何验证、预计会看到什么
  • 内建风控与性能思路:自动给出安全与加速提示,避免慢查与误删
  • 可复用与可沉淀:把临时查询升级为标准化模板,团队共享更高效 适用场景:日常取数、应急排查、审计导出、日志检索、报表开发、版本迁移前后数据验证。 试用路径:输入数据库类型、检索方法与检索目标,立即生成专属方案;升级版本支持历史方案保存、团队共享与私域知识沉淀。

适用用户

数据库管理员(DBA)

快速生成符合环境的检索方案与脚本,定位慢查、排查锁等待,制定安全查询模板,降低线上风险并沉淀操作手册。

数据分析师

根据业务口径一键产出指标拉取语句与校验步骤,按日周月批量复用,减少与技术反复沟通,提升报表制作和洞察效率。

后端开发工程师

在开发、测试、生产多环境高效定位数据,构造测试样本,验证业务逻辑与回归问题,缩短联调与上线周期。

特征总结

一键生成跨数据库检索方案,自动匹配环境与语法,减少试错时间与沟通成本。
基于业务目标智能选择检索路径,给出更省资源的做法,兼顾速度、准确与稳定。
直接输出可执行查询指令与步骤,新手也能按图操作,快速完成数据定位与提取。
自动给出性能优化建议,如索引利用、条件重写与范围限制,显著缩短查询耗时。
内置安全与合规提醒,识别越权与敏感字段风险,避免误操作引发数据泄露。
提供结果预期与校验方法,快速核对命中率与边界情况,确保输出可信性。
可按团队习惯定制模板与参数,一键复用常见场景,标准化多人协作流程。
支持异常处理与兜底方案,遇到慢查或超时时,自动给出替代路径与拆分策略。

如何使用购买的提示词模板

1. 直接在外部 Chat 应用中使用

将模板生成的提示词复制粘贴到您常用的 Chat 应用(如 ChatGPT、Claude 等),即可直接对话使用,无需额外开发。适合个人快速体验和轻量使用场景。

2. 发布为 API 接口调用

把提示词模板转化为 API,您的程序可任意修改模板参数,通过接口直接调用,轻松实现自动化与批量处理。适合开发者集成与业务系统嵌入。

3. 在 MCP Client 中配置使用

在 MCP client 中配置对应的 server 地址,让您的 AI 应用自动调用提示词模板。适合高级用户和团队协作,让提示词在不同 AI 工具间无缝衔接。

AI 提示词价格
¥20.00元
先用后买,用好了再付款,超安全!

您购买后可以获得什么

获得完整提示词模板
- 共 507 tokens
- 3 个可调节参数
{ 数据库类型 } { 检索方法 } { 检索目标 }
获得社区贡献内容的使用权
- 精选社区优质案例,助您快速上手提示词
使用提示词兑换券,低至 ¥ 9.9
了解兑换券 →
限时半价

不要错过!

半价获取高级提示词-优惠即将到期

17
:
23
小时
:
59
分钟
:
59