address the comments

docs/content.zh/docs/dev/table/materialized-table/statements.md

@@ -333,24 +333,24 @@ ALTER MATERIALIZED TABLE my_materialized_table REFRESH PARTITION (ds='2024-06-28
 ALTER MATERIALIZED TABLE [catalog_name.][db_name.]table_name AS <select_statement>
 ```
 
-`AS <select_statement>` 用于修改物化表的查询定义。它会更新物化表刷新任务中使用的查询，并基于更新后的查询推导出新的 `schema` ，从而调整表的 `schema` 。但该操作不会直接影响现有数据。
+`AS <select_statement>` 子句用于修改刷新物化表的查询定义。它会先使用新查询派生的 `schema` 更新表的 `schema`，然后使用新查询刷新表数据。需要特别强调的是，默认情况下，这不会影响历史数据。
 
 具体修改流程取决于物化表的刷新模式：
 
 **全量模式：**
 
 1. 更新物化表的 `schema` 和查询定义。
-2. 下次刷新任务启动时，将使用新的查询刷新:
+2. 在刷新任务下次触发执行时，将使用新的查询定义刷新数据:
 - 如果修改的物化表是分区表，且[partition.fields.#.date-formatter]({{< ref "docs/dev/table/config" >}}#partition-fields-date-formatter) 配置正确，则仅刷新最新分区。
 - 否则，将刷新整个表的数据。
 
 **持续模式：**
 
 1. 暂停当前的实时刷新任务。
 2. 更新物化表的 `schema` 和查询定义。
-3. 启动新的实时任务以刷新物化表：
-- 新的刷新任务会从头开始，而不是从之前的状态继续。
-- 数据源的起始消费位置会由到连接器的默认实现或查询中设置的 `option hint` 决定）
+3. 启动新的流式任务以刷新物化表：
+- 新的流式任务会从头开始，而不会从之前的流式任务状态恢复。
+- 数据源的起始位点会由到连接器的默认实现或查询中设置的 `option hint` 决定。
 
 **示例：**
 
@@ -386,8 +386,8 @@ GROUP BY
 ```
 
 <span class="label label-danger">注意</span>
-- Schema 修改仅支持在原表 schema 末尾添加 `nullable` 列。
-- 在持续模式下，新的刷新任务不会从原来的刷新任务的状态恢复。这可能会导致短暂的数据重复或丢失。
+- Schema 演进当前仅支持在原表 schema 尾部添加`可空列`。
+- 在持续模式下，新的流式任务不会从原来的流式任务的状态恢复。这可能会导致短暂的数据重复或丢失。
 
 # DROP MATERIALIZED TABLE
 

docs/content/docs/dev/table/materialized-table/statements.md

@@ -334,24 +334,24 @@ ALTER MATERIALIZED TABLE my_materialized_table REFRESH PARTITION (ds='2024-06-28
 ALTER MATERIALIZED TABLE [catalog_name.][db_name.]table_name AS <select_statement>
 ```
 
-The `AS <select_statement>` clause allows you to modify the query definition of a materialized table. It updates the query used by the materialized table refresh job and infers a new schema based on the updated query to adjust the table’s schema. However, this operation does not directly affect existing data.
+The `AS <select_statement>` clause allows you to modify the query definition for refreshing materialized table. It will first evolve the table's schema using the schema derived from the new query and then use the new query to refresh the table data. It is important to emphasize that, by default, this does not impact historical data.
 
 The modification process depends on the refresh mode of the materialized table:
 
 **Full mode:**
 
-1. Update the schema and query definition of the materialized table.
-2. During the next refresh job, the table is refreshed using the new query definition:
-- If the table is a partitioned table and [partition.fields.#.date-formatter]({{< ref "docs/dev/table/config" >}}#partition-fields-date-formatter) is correctly set, only the latest partition will be refreshed.
-- Otherwise, the entire table will be refreshed.
+1. Update the `schema` and `query definition` of the materialized table.
+2. The table is refreshed using the new query definition when the next refresh job is triggered:
+- If it is a partitioned table and [partition.fields.#.date-formatter]({{< ref "docs/dev/table/config" >}}#partition-fields-date-formatter) is correctly set, only the latest partition will be refreshed.
+- Otherwise, the table will be overwritten entirely.
 
 **Continuous mode:**
 
-1. Pause the current continuous refresh jobs.
+1. Pause the current running refresh job.
 2. Update the `schema` and `query definition` of the materialized table.
-3. Start a new continuous refresh job to refresh the materialized table:
+3. Start a new refresh job to refresh the materialized table:
 - The new refresh job starts from the beginning and does not restore from the previous state.
-- The starting consumption position of the data source is determined by the connector’s default implementation or the option hint specified in the query.
+- The starting offset of the data source is determined by the connector’s default implementation or the `option hint` specified in the query.
 
 **Example:**