11月15日，CANN Meetup 北京站，邀您共赴一场技术盛宴

技术大神们好，我在使用GaussDB时遇到一个监控采集方面的错误，特来求助。我的collector在尝试采集replication、replication_slot指标时失败了，报错信息如下：time=2025-09-05T09:34:16.375+08:00 level=ERROR source=collector.go:207 msg="collector failed" name=replication duration_seconds=0.0711601 err="ERROR: Function pg_last_wal_receive_lsn() does not exist. (SQLSTATE 42883)"time=2025-09-05T09:34:16.674+08:00 level=INFO source=namespace.go:235 msg="error finding namespace" err="Error running query on database \"113.44.80.136:8000\": pg_stat_replication ERROR: Function pg_last_wal_receive_lsn() does not exist. (SQLSTATE 42883)"time=2025-09-05T09:34:16.711+08:00 level=INFO source=namespace.go:235 msg="error finding namespace" err="Error running query on database \"113.44.80.136:8000\": pg_replication_slots ERROR: Function pg_last_wal_receive_lsn() does not exist. (SQLSTATE 42883)"time=2025-09-05T09:34:16.755+08:00 level=ERROR source=collector.go:207 msg="collector failed" name=replication_slot duration_seconds=0.4515532 err="ERROR: Function pg_last_wal_receive_lsn() does not exist. (SQLSTATE 42883)"time=2025-09-11T15:33:59.609+08:00 level=ERROR source=gaussdb_exporter.go:684 msg="error scraping dsn" err="queryNamespaceMappings errors encountered, namespace: pg_stat_replication error: Error running query on database \"113.44.80.136:8000\": pg_stat_replication ERROR: Function pg_last_wal_receive_lsn() does not exist. (SQLSTATE 42883), namespace: pg_replication_slots error: Error running query on database \"113.44.80.136:8000\": pg_replication_slots ERROR: Function pg_last_wal_receive_lsn() does not exist. (SQLSTATE 42883)" dsn="gaussdb://root:PASSWORD_REMOVED@113.44.80.136:8000/circle_test?sslmode=disable"相关SQL：SELECT *, (CASE pg_is_in_recovery () WHEN 't' THEN pg_last_wal_receive_lsn () ELSE pg_current_wal_lsn () END) AS pg_current_wal_lsn, ( CASE pg_is_in_recovery () WHEN 't' THEN pg_wal_lsn_diff (pg_last_wal_receive_lsn (), PG_LSN ('0/0')) :: FLOAT ELSE pg_wal_lsn_diff (pg_current_wal_lsn (), PG_LSN ('0/0')) :: FLOAT END ) AS pg_current_wal_lsn_bytes, ( CASE pg_is_in_recovery () WHEN 't' THEN pg_wal_lsn_diff (pg_last_wal_receive_lsn (), replay_lsn) :: FLOAT ELSE pg_wal_lsn_diff (pg_current_wal_lsn (), replay_lsn) :: FLOAT END ) AS pg_wal_lsn_diff FROM pg_stat_replication;SELECT slot_name, DATABASE, active, (CASE pg_is_in_recovery () WHEN 't' THEN pg_wal_lsn_diff (pg_last_wal_receive_lsn (), restart_lsn) ELSE pg_wal_lsn_diff (pg_current_wal_lsn (), restart_lsn) END) AS pg_wal_lsn_diff FROM pg_replication_slots;SELECT slot_name, slot_type, CASE WHEN pg_is_in_recovery () THEN pg_last_wal_receive_lsn () - '0/0' ELSE pg_current_wal_lsn () - '0/0' END AS current_wal_lsn, 0 AS confirmed_flush_lsn, active FROM pg_replication_slots;错误提示很明确：SQL查询中引用了名为 pg_last_wal_receive_lsn() 的函数，但该函数在数据库系统中不存在。我想了解：问题根因：这是否是因为我的GaussDB版本（或特定模式）中，系统函数与监控工具期望的不一致？pg_last_wal_receive_lsn() 函数在当前版本的GaussDB中是否存在？这个函数是否是PostgreSQL特有的而非GaussDB的内置函数？解决方案：对于这类复制监控指标采集，GaussDB的正确实践是什么？是需要使用不同的系统函数，还是需要查询特定的系统视图来获取接收LSN信息？是否需要启用特定的复制监控功能或配置？版本差异：pg_last_wal_receive_lsn() 函数是否是某些PostgreSQL版本中特有的？我当前使用的GaussDB版本可能基于哪个PostgreSQL基础版本，以及GaussDB自身对此功能的支持情况如何？任何关于此问题的排查思路、系统函数差异说明或版本兼容性信息都将非常有帮助！感谢！背景信息/补充说明（可选）：我使用的GaussDB版本是：gaussdb (GaussDB Kernel 505.2.1 build ff07bff6) compiled at 2024-12-27 09:22:42 commit 10161 last mr 21504 release采集工具是：Prometheus gaussdb_exporter希望得到大家的指点，谢谢！

技术大神们好，我在使用GaussDB时遇到一个监控采集方面的错误，特来求助。我的collector在尝试采集replication_slot指标时失败了，报错信息如下：time=2025-09-17T10:45:23.325+08:00 level=ERROR source=collector.go:207 msg="collector failed" name=replication_slot duration_seconds=0.6615468 err="ERROR: Column \"wal_status\" does not exist. (SQLSTATE 42703)"相关SQL：SELECT     slot_name,     slot_type,     0 AS current_wal_lsn,     0 AS confirmed_flush_lsn,     active,     0,     wal_status FROM pg_replication_slots;错误提示很明确：SQL查询中引用了名为 wal_status的列，但该列在目标表中不存在。我想了解：问题根因：这是否是因为我的GaussDB版本（或特定模式）中，系统视图或系统表的结构与采集工具期望的不一致？replication_slot相关的系统视图究竟是哪个？（例如是pg_replication_slots吗？）这个视图在当前版本的GaussDB中是否不包含 wal_status列？解决方案：对于这类监控指标采集，GaussDB的正确实践是什么？是需要查询不同的系统视图，还是需要启用特定的监控开关或配置？版本差异：wal_status列是否是某些更新版本中才加入的？我当前使用的GaussDB版本可能是什么？任何关于此问题的排查思路、系统视图结构说明或版本兼容性信息都将非常有帮助！感谢！背景信息/补充说明（可选）：我使用的GaussDB版本是：gaussdb (GaussDB Kernel 505.2.1 build ff07bff6) compiled at 2024-12-27 09:22:42 commit 10161 last mr 21504 release采集工具是：Prometheus gaussdb_exporter希望得到大家的指点，谢谢！

技术大神们好，我在使用GaussDB时遇到一个监控采集方面的错误，特来求助。我的collector在尝试采集replication_slot指标时失败了，报错信息如下：time=2025-09-17T10:17:36.080+08:00 level=ERROR source=collector.go:207 msg="collector failed" name=replication_slot duration_seconds=0.8542995 err="ERROR: Column \"safe_wal_size\" does not exist. (SQLSTATE 42703)"相关SQL：SELECT slot_name, slot_type, 0 AS current_wal_lsn,   0 AS confirmed_flush_lsn, active, safe_wal_size, '' FROM pg_replication_slots;错误提示很明确：SQL查询中引用了名为 safe_wal_size的列，但该列在目标表中不存在。我想了解：问题根因：这是否是因为我的GaussDB版本（或特定模式）中，系统视图或系统表的结构与采集工具期望的不一致？replication_slot相关的系统视图究竟是哪个？（例如是pg_replication_slots吗？）这个视图在当前版本的GaussDB中是否不包含 safe_wal_size列？解决方案：对于这类监控指标采集，GaussDB的正确实践是什么？是需要查询不同的系统视图，还是需要启用特定的监控开关或配置？版本差异：safe_wal_size列是否是某些更新版本中才加入的？我当前使用的GaussDB版本可能是什么？任何关于此问题的排查思路、系统视图结构说明或版本兼容性信息都将非常有帮助！感谢！背景信息/补充说明（可选）：我使用的GaussDB版本是：gaussdb (GaussDB Kernel 505.2.1 build ff07bff6) compiled at 2024-12-27 09:22:42 commit 10161 last mr 21504 release采集工具是：Prometheus gaussdb_exporter希望得到大家的指点，谢谢！

技术大神们好，我在使用GaussDB时遇到一个监控采集方面的错误，特来求助。我的collector在尝试采集replication_slot指标时失败了，报错信息如下：time=2025-09-16T17:01:36.715+08:00 level=ERROR source=collector.go:207 msg="collector failed" name=replication_slot duration_seconds=0.4178095 err="ERROR: Column \"confirmed_flush_lsn\" does not exist. (SQLSTATE 42703)"相关SQL：SELECT     slot_name,     slot_type,     0 AS current_wal_lsn,    COALESCE(confirmed_flush_lsn, '0/0') - '0/0' AS confirmed_flush_lsn,     active,     0,     '' FROM pg_replication_slots;错误提示很明确：SQL查询中引用了名为 confirmed_flush_lsn 的列，但该列在目标表中不存在。我想了解：问题根因：这是否是因为我的GaussDB版本（或特定模式）中，系统视图或系统表的结构与采集工具期望的不一致？replication_slot相关的系统视图究竟是哪个？（例如是pg_replication_slots吗？）这个视图在当前版本的GaussDB中是否不包含 confirmed_flush_lsn列？解决方案：对于这类监控指标采集，GaussDB的正确实践是什么？是需要查询不同的系统视图，还是需要启用特定的监控开关或配置？版本差异：confirmed_flush_lsn列是否是某些更新版本中才加入的？我当前使用的GaussDB版本可能是什么？任何关于此问题的排查思路、系统视图结构说明或版本兼容性信息都将非常有帮助！感谢！背景信息/补充说明（可选）：我使用的GaussDB版本是：gaussdb (GaussDB Kernel 505.2.1 build ff07bff6) compiled at 2024-12-27 09:22:42 commit 10161 last mr 21504 release采集工具是：Prometheus gaussdb_exporter希望得到大家的指点，谢谢！

关于 OpenTiny 欢迎加入 OpenTiny 开源社区。添加微信小助手：opentiny-official 一起参与交流前端技术～OpenTiny 官网：https://opentiny.designOpenTiny 代码仓库：https://github.com/opentinyTinyVue 源码：https://github.com/opentiny/tiny-vueTinyEngine 源码：https://github.com/opentiny/tiny-engine欢迎进入代码仓库 Star🌟TinyEngine、TinyVue、TinyNG、TinyCLI、TinyEditor~如果你也想要共建，可以进入代码仓库，找到 good first issue 标签，一起参与开源贡献~  

技术大神们好，我在使用GaussDB时遇到一个监控采集方面的错误，特来求助。我的collector在尝试采集stat_archiver指标时失败了，报错信息如下：time=2025-09-05T09:34:16.745+08:00 level=INFO source=namespace.go:235 msg="error finding namespace" err="Error running query on database \"113.44.80.136:8000\": pg_stat_archiver ERROR: Relation \"pg_stat_archiver\" does not exist on dn_6001_6002_6003. (SQLSTATE 42P01)"相关SQL：SELECT *, extract(epoch from now() - last_archived_time) AS last_archive_ageFROM pg_stat_archiver错误提示很明确：SQL查询中视图pg_stat_archiver不存在。我想了解：问题根因：这是否是因为我的GaussDB版本（或特定模式）中，系统视图或系统表的结构与采集工具期望的不一致？stat_archiver 相关的系统视图究竟是哪个？（例如是pg_stat_archiver吗？）解决方案：对于这类监控指标采集，GaussDB的正确实践是什么？是需要查询不同的系统视图，还是需要启用特定的监控开关或配置？版本差异：视图pg_stat_archiver是否是某些更新版本中才加入的？我当前使用的GaussDB版本可能是什么？任何关于此问题的排查思路、系统视图结构说明或版本兼容性信息都将非常有帮助！感谢！背景信息/补充说明（可选）：我使用的GaussDB版本是：gaussdb (GaussDB Kernel 505.2.1 build ff07bff6) compiled at 2024-12-27 09:22:42 commit 10161 last mr 21504 release采集工具是：Prometheus gaussdb_exporter希望得到大家的指点，谢谢！

技术大神们好，我在使用GaussDB时遇到一个监控采集方面的错误，特来求助。我的collector在尝试采集stat_user_tables指标时失败了，报错信息如下：time=2025-09-05T09:34:16.792+08:00 level=ERROR source=collector.go:207 msg="collector failed" name=stat_user_tables duration_seconds=0.4879153 err="ERROR: Column \"n_mod_since_analyze\" does not exist. (SQLSTATE 42703)"相关SQL：SELECT current_database() datname, schemaname, relname, seq_scan, seq_tup_read, idx_scan, idx_tup_fetch, n_tup_ins, n_tup_upd, n_tup_del, n_tup_hot_upd, n_live_tup, n_dead_tup, COALESCE(last_vacuum, '1970-01-01Z') as last_vacuum, COALESCE(last_autovacuum, '1970-01-01Z') as last_autovacuum, COALESCE(last_analyze, '1970-01-01Z') as last_analyze, COALESCE(last_autoanalyze, '1970-01-01Z') as last_autoanalyze, vacuum_count, autovacuum_count, analyze_count, autoanalyze_count, pg_indexes_size(relid) as indexes_size, pg_table_size(relid) as table_sizeFROM pg_stat_user_tables错误提示很明确：SQL查询中引用了名为 n_mod_since_analyze 的列，但该列在目标表中不存在。我想了解：问题根因：这是否是因为我的GaussDB版本（或特定模式）中，系统视图或系统表的结构与采集工具期望的不一致？stat_user_tables 相关的系统视图究竟是哪个？（例如是pg_stat_user_tables吗？）这个视图在当前版本的GaussDB中是否不包含 n_mod_since_analyze 列？解决方案：对于这类监控指标采集，GaussDB的正确实践是什么？是需要查询不同的系统视图，还是需要启用特定的监控开关或配置？版本差异：n_mod_since_analyze 列是否是某些更新版本中才加入的？我当前使用的GaussDB版本可能是什么？任何关于此问题的排查思路、系统视图结构说明或版本兼容性信息都将非常有帮助！感谢！背景信息/补充说明（可选）：我使用的GaussDB版本是：gaussdb (GaussDB Kernel 505.2.1 build ff07bff6) compiled at 2024-12-27 09:22:42 commit 10161 last mr 21504 release采集工具是：Prometheus gaussdb_exporter希望得到大家的指点，谢谢！

技术大神们好，我在使用GaussDB时遇到一个监控采集方面的错误，特来求助。我的collector在尝试采集stat_activity指标时失败了，报错信息如下：time=2025-09-10T17:22:38.015+08:00 level=INFO source=namespace.go:235 msg="error finding namespace" err="Error running query on database \"113.44.80.136:8000\": pg_stat_activity ERROR: Column \"wait_event\" does not exist. (SQLSTATE 42703)"相关SQL：SELECT pg_database.datname, tmp.state, tmp2.usename, tmp2.application_name, tmp2.backend_type, tmp2.wait_event_type, tmp2.wait_event, COALESCE(count,0) as count, COALESCE(max_tx_duration,0) as max_tx_duration FROM ( VALUES ('active'), ('idle'), ('idle in transaction'), ('idle in transaction (aborted)'), ('fastpath function call'), ('disabled') ) AS tmp(state) CROSS JOIN pg_database LEFT JOIN ( SELECT datname, state, usename, application_name, backend_type, wait_event_type, wait_event, count(*) AS count, MAX(EXTRACT(EPOCH FROM now() - xact_start))::float AS max_tx_duration FROM pg_stat_activity GROUP BY datname,state,usename,application_name,backend_type,wait_event_type,wait_event) AS tmp2 ON tmp.state = tmp2.state AND pg_database.datname = tmp2.datname错误提示很明确：SQL查询中引用了名为 wait_event 的列，但该列在目标表中不存在。我想了解：问题根因：这是否是因为我的GaussDB版本（或特定模式）中，系统视图或系统表的结构与采集工具期望的不一致？stat_activity 相关的系统视图究竟是哪个？（例如是pg_stat_activity吗？）这个视图在当前版本的GaussDB中是否不包含 wait_event 列？解决方案：对于这类监控指标采集，GaussDB的正确实践是什么？是需要查询不同的系统视图，还是需要启用特定的监控开关或配置？版本差异：wait_event 列是否是某些更新版本中才加入的？我当前使用的GaussDB版本可能是什么？任何关于此问题的排查思路、系统视图结构说明或版本兼容性信息都将非常有帮助！感谢！背景信息/补充说明（可选）：我使用的GaussDB版本是：gaussdb (GaussDB Kernel 505.2.1 build ff07bff6) compiled at 2024-12-27 09:22:42 commit 10161 last mr 21504 release采集工具是：Prometheus gaussdb_exporter希望得到大家的指点，谢谢！

技术大神们好，我在使用GaussDB时遇到一个监控采集方面的错误，特来求助。我的collector在尝试采集stat_activity指标时失败了，报错信息如下：time=2025-09-10T15:47:07.742+08:00 level=INFO source=namespace.go:235 msg="error finding namespace" err="Error running query on database \"113.44.80.136:8000\": pg_stat_activity ERROR: Column \"wait_event_type\" does not exist. (SQLSTATE 42703)"相关SQL：SELECT pg_database.datname, tmp.state, tmp2.usename, tmp2.application_name, tmp2.backend_type, tmp2.wait_event_type, tmp2.wait_event, COALESCE(count,0) as count, COALESCE(max_tx_duration,0) as max_tx_duration FROM ( VALUES ('active'), ('idle'), ('idle in transaction'), ('idle in transaction (aborted)'), ('fastpath function call'), ('disabled') ) AS tmp(state) CROSS JOIN pg_database LEFT JOIN ( SELECT datname, state, usename, application_name, backend_type, wait_event_type, wait_event, count(*) AS count, MAX(EXTRACT(EPOCH FROM now() - xact_start))::float AS max_tx_duration FROM pg_stat_activity GROUP BY datname,state,usename,application_name,backend_type,wait_event_type,wait_event) AS tmp2 ON tmp.state = tmp2.state AND pg_database.datname = tmp2.datname错误提示很明确：SQL查询中引用了名为 wait_event_type 的列，但该列在目标表中不存在。我想了解：问题根因：这是否是因为我的GaussDB版本（或特定模式）中，系统视图或系统表的结构与采集工具期望的不一致？stat_activity 相关的系统视图究竟是哪个？（例如是pg_stat_activity吗？）这个视图在当前版本的GaussDB中是否不包含 wait_event_type 列？解决方案：对于这类监控指标采集，GaussDB的正确实践是什么？是需要查询不同的系统视图，还是需要启用特定的监控开关或配置？版本差异：wait_event_type 列是否是某些更新版本中才加入的？我当前使用的GaussDB版本可能是什么？任何关于此问题的排查思路、系统视图结构说明或版本兼容性信息都将非常有帮助！感谢！背景信息/补充说明（可选）：我使用的GaussDB版本是：gaussdb (GaussDB Kernel 505.2.1 build ff07bff6) compiled at 2024-12-27 09:22:42 commit 10161 last mr 21504 release采集工具是：Prometheus gaussdb_exporter希望得到大家的指点，谢谢！

技术大神们好，我在使用GaussDB时遇到一个监控采集方面的错误，特来求助。我的collector在尝试采集stat_activity指标时失败了，报错信息如下：time=2025-09-05T09:34:16.780+08:00 level=INFO source=namespace.go:235 msg="error finding namespace" err="Error running query on database \"113.44.80.136:8000\": pg_stat_activity ERROR: Column \"backend_type\" does not exist. (SQLSTATE 42703)"相关SQL：SELECT pg_database.datname, tmp.state, tmp2.usename, tmp2.application_name, tmp2.backend_type, tmp2.wait_event_type, tmp2.wait_event, COALESCE(count,0) as count, COALESCE(max_tx_duration,0) as max_tx_duration FROM ( VALUES ('active'), ('idle'), ('idle in transaction'), ('idle in transaction (aborted)'), ('fastpath function call'), ('disabled') ) AS tmp(state) CROSS JOIN pg_database LEFT JOIN ( SELECT datname, state, usename, application_name, backend_type, wait_event_type, wait_event, count(*) AS count, MAX(EXTRACT(EPOCH FROM now() - xact_start))::float AS max_tx_duration FROM pg_stat_activity GROUP BY datname,state,usename,application_name,backend_type,wait_event_type,wait_event) AS tmp2 ON tmp.state = tmp2.state AND pg_database.datname = tmp2.datname错误提示很明确：SQL查询中引用了名为 backend_type 的列，但该列在目标表中不存在。我想了解：问题根因：这是否是因为我的GaussDB版本（或特定模式）中，系统视图或系统表的结构与采集工具期望的不一致？stat_activity 相关的系统视图究竟是哪个？（例如是pg_stat_activity吗？）这个视图在当前版本的GaussDB中是否不包含 backend_type 列？解决方案：对于这类监控指标采集，GaussDB的正确实践是什么？是需要查询不同的系统视图，还是需要启用特定的监控开关或配置？版本差异：backend_type 列是否是某些更新版本中才加入的？我当前使用的GaussDB版本可能是什么？任何关于此问题的排查思路、系统视图结构说明或版本兼容性信息都将非常有帮助！感谢！背景信息/补充说明（可选）：我使用的GaussDB版本是：gaussdb (GaussDB Kernel 505.2.1 build ff07bff6) compiled at 2024-12-27 09:22:42 commit 10161 last mr 21504 release采集工具是：Prometheus gaussdb_exporter希望得到大家的指点，谢谢！

技术大神们好，我在使用GaussDB时遇到一个监控采集方面的错误，特来求助。我的collector在尝试采集stat_database指标时失败了，报错信息如下：time=2025-09-05T09:34:16.484+08:00 level=ERROR source=collector.go:207 msg="collector failed" name=stat_database duration_seconds=0.1799696 err="ERROR: Column \"active_time\" does not exist. (SQLSTATE 42703)"错误提示很明确：SQL查询中引用了名为 active_time 的列，但该列在目标表中不存在。相关SQL:SELECT datid, datname, numbackends, xact_commit, xact_rollback, blks_read, blks_hit, tup_returned, tup_fetched, tup_inserted, tup_updated, tup_deleted, conflicts, temp_files, temp_bytes, deadlocks, blk_read_time, blk_write_time, stats_reset, active_timeFROM pg_stat_database;我想了解：问题根因：这是否是因为我的GaussDB版本（或特定模式）中，系统视图或系统表的结构与采集工具期望的不一致？stat_database 相关的系统视图究竟是哪个？（例如是pg_stat_database吗？）这个视图在当前版本的GaussDB中是否不包含 active_time 列？解决方案：对于这类监控指标采集，GaussDB的正确实践是什么？是需要查询不同的系统视图，还是需要启用特定的监控开关或配置？版本差异：active_time 列是否是某些更新版本中才加入的？我当前使用的GaussDB版本可能是什么？任何关于此问题的排查思路、系统视图结构说明或版本兼容性信息都将非常有帮助！感谢！背景信息/补充说明（可选）：我使用的GaussDB版本是：gaussdb (GaussDB Kernel 505.2.1 build ff07bff6) compiled at 2024-12-27 09:22:42 commit 10161 last mr 21504 release采集工具是：Prometheus gaussdb_exporter希望得到大家的指点，谢谢！

活动介绍：OpenTiny 是华为云开源的企业级前端智能应用解决方案，通过本次产品体验官活动，您可以了解当前OpenTiny项目中的 TinyRobot、Web Agent、NEXT SDK 三个产品，了解其智能化能力，并实现应用的智能化改造，从而让AI智能体代替人操作Web应用，助力用户更高效地完成业务目标。活动时间：2025.9.8-2025.10.14活动流程：1、 访问体验环境：Chrome、VSCode2、 按照实操流程进行体验，可参考实操手册3、 将体验完成截图发送至评论区，同时说明体验感受奖品示例：序号礼包名称介绍1200元开发者礼包1开发者定制双肩包（黑武士款）开发者定制渔夫帽（2025款）开发者定制鼠标垫大号（2025款）2200元开发者礼包2开发者定制冲锋衣（M-3XL）开发者定制渔夫帽（2025款）开发者定制鼠标垫大号（2025款）活动说明：1、完成体验请在本活动评论区，截图体验完成的实际截图，并说明体验感受。2、如果有任何关于OpenTiny NEXT的体验建议，请提交至云声建议平台（填写时，关联产品/功能 选择Codelabs) 并标明以【OpenTiny NEXT体验】为开头，比如【OpenTiny NEXT体验】整体上手体验不错，建议考虑XXX场景，实现接入智能化能力。3、 所有参与活动的开发者需要完成实际体验，有任何问题欢迎联系OpenTiny小助手【请备注：体验官活动】。  4、 活动完成后，根据开发者体验反馈，抽取5位幸运用户，获得价值200元开发者礼包。（本次活动以高价值建议、体验完整性等因素为主要抽选标准）5、 提交体验感受时，可以围绕体验流程、操作步骤、问题建议等方向进行展开，建议内容表述清晰，有操作截图或链接等详细描述。6、 兑换礼品以仓库现有礼品为准，不可以指定，如遇商品缺货，将随机换成其他等价值礼品发放。关于 OpenTiny欢迎加入 OpenTiny 开源社区。添加微信小助手：opentiny-official 一起参与交流前端技术～OpenTiny 官网：https://opentiny.designOpenTiny 代码仓库：cid:link_4TinyVue 源码：cid:link_3TinyEngine 源码： cid:link_1欢迎进入代码仓库 Star🌟TinyEngine、TinyVue、TinyNG、TinyCLI、TinyEditor~如果你也想要共建，可以进入代码仓库，找到 good first issue 标签，一起参与开源贡献~

【生态大讲堂】华为开发者体验中心推出“生态大讲堂”系列活动，汇聚产业专家与业内大咖，聚焦AI、大模型、具身智能等热点领域，洞察技术趋势，传递实战经验，为华为生态领域开发者和伙伴带来全新视野与启发。 当AI技术重构开发者生态，社区建设如何跳出“流量陷阱”，回归价值本质？本次直播特邀深耕开发者社区研究的专家，上海交通大学教授曹健老师，通过 “社区生态三维模型”（价值共生、技术赋能、情感联结）的核心理论，拆解AI时代社区建设的底层逻辑。如何用AI工具降低参与门槛，让技术交流从“精英圈层”走向“普惠共生”？怎样通过算法优化内容匹配，让社区资源精准触达开发者真实需求？当机器逐渐承担基础协作，社区如何强化“人与人”的情感认同，避免沦为冰冷的技术工具库？无论你是社区运营者、技术团队负责人，还是想搭建垂直领域开发者社群的创业者，这场直播将带你从理论框架到落地案例，找到AI与社区建设的最佳结合点，让技术社群真正成为创新的“孵化器”而非“流量场”。 扫码观看直播  

欢迎朋友们一键star项目~ 让我们一起走的更远！源码地址：https://github.com/opentiny/tiny-engine