@amaster.ai/pi-lark 0.1.5 → 0.1.7

package/skills/lark-base/references/dashboard-block-data-config.md

@@ -90,6 +90,10 @@ user / created_by / updated_by: is, isNot, isEmpty, isNotEmpty
 
 `sort.order`：`asc`（升序）/ `desc`（降序）
 
+只要写 `sort` 对象，就需要明确排序方向。CLI 会把 `sort.type` 为 `group` 或 `view` 且缺少 `order` 的情况规范化为 `order:"asc"`；`sort.type:"value"` 必须显式写 `order:"asc"` 或 `order:"desc"`，因为指标值排序方向会改变业务含义。
+
+如果表中行序就是业务顺序，首次创建 block 时就一次性设置 `sort:{"type":"view","order":"asc"}` 保留行序，避免创建后再二次更新排序条件。
+
 示例 — 柱状图按销售额降序：
 
 ```json
@@ -169,9 +173,10 @@ user / created_by / updated_by: is, isNot, isEmpty, isNotEmpty
 - 长度/结构
   - `group_by` 最多 2 个；每项 `field_name` 必填
   - `group_by[].sort.type` 取值 `group|value|view`；`order` 取值 `asc|desc`
-- 规范化（CLI 自动处理）
+- 规范化（CLI 自动处理；`--no-validate` 时不生效，`data_config` 原样透传给后端）
   - `series[].rollup` 自动转成大写（如 `sum` → `SUM`）
   - `group_by[].sort.type/order` 自动转成小写
+  - `group_by[].sort.type` 为 `group` 或 `view` 且缺少 `order` 时，自动补 `order:"asc"`；`value` 排序不会自动补方向
 - 本地校验（可通过 `--no-validate` 跳过）
   - `+dashboard-block-create` 默认对 `data_config` 做轻量校验；失败会聚合错误并给出修复建议
   - `+dashboard-block-update` 不做强类型校验，由后端验证具体字段
@@ -264,14 +269,35 @@ user / created_by / updated_by: is, isNot, isEmpty, isNotEmpty
 
 漏斗图（流程转化）：
 
+先判断用户要看的数值语义：
+
+- **当前数量**：统计每个当前状态/阶段下有多少记录，例如“各环节当前数量”“当前阶段分布”。源表有状态/阶段字段时，直接用 `count_all:true` + `group_by`。
+- **累计数量**：统计到达该阶段及其后续阶段（后缀和）的累计数量，例如“流程转化”“从 A 到 B 各环节转化”。此口径假设流程单向、无跳阶/回退、记录不删除；不满足时须用状态变更历史，不能对当前快照累加。如果表中已有累计数量字段或阶段汇总表，直接用该字段画漏斗图；否则先计算累计数量，创建并写入 helper 汇总表后再画图。
+
+当前数量：
+
 ```json
 {
   "table_name": "表名",
-  "series": [{ "field_name": "数值字段", "rollup": "SUM" }],
+  "count_all": true,
   "group_by": [{ "field_name": "状态字段", "mode": "integrated" }]
 }
 ```
 
+累计数量：
+
+```json
+{
+  "table_name": "流程汇总表名",
+  "series": [{ "field_name": "累计数量", "rollup": "SUM" }],
+  "group_by": [{ "field_name": "阶段字段", "mode": "integrated", "sort": {"type":"view","order":"asc"} }]
+}
+```
+
+如果只有当前状态数据但用户要看流程转化，需要先按业务阶段顺序计算每个阶段的累计数量，再创建 helper 汇总表（如：阶段、累计数量），用 `+record-batch-create` 一次写入后，按“累计数量”模板创建漏斗图。helper 表行序就是业务顺序时，首次创建 block 时一次性设置好 `group_by.sort`。
+
+> ⚠️ 注意:helper 汇总表仅用于源表无法直接聚合出目标形态的场景（如上面的累计数量漏斗图）。只要能在源表上直接用 `group_by` + `rollup`（含 `AVERAGE`）算出，就不需要新建 helper 表。
+
 词云（文本频率）：
 
 ```json

package/skills/lark-base/references/lark-base-cell-value.md

@@ -8,23 +8,28 @@
 
 - `--json` 必须是 JSON 对象。
 - `+record-upsert`：顶层直接传字段映射：`{"字段名或字段ID": CellValue}`。
-- `+record-batch-create`：`rows` 是 `CellValue[][]`，列顺序由 `fields` 决定。
-- `+record-batch-update`：`patch` 是 `Map<FieldNameOrID, CellValue>`，同一份 `patch` 会应用到所有 `record_id_list`。
+- `+record-batch-create`：使用 `create_records`，其每个元素都是 `Map<FieldNameOrID, CellValue>`。
+- `+record-batch-update`：使用 `update_records`，其每个 value 都是 `Map<FieldNameOrID, CellValue>`。
 - 一次 payload 里同一字段只用一种 key（字段名或字段 ID），不要重复。
 - 写入前先 `+field-list` 获取字段 `type/style/multiple`，再构造值。
 - 需要清空字段时优先传 `null`（字段允许清空时）。
 
 ## 2. 各类型 CellValue
 
-### 2.1 text / phone / url
+### 2.1 text
 
-用字符串。URL 字段也传 URL 字符串；普通文本里可以保留 Markdown 风格链接文本，平台会按字段类型处理。
+text 字段的 `style.type` 影响单元格检查逻辑：
+`type=plain` 传 Markdown 格式的字符串。
+`type=url` 传一个带 title 的 Markdown 格式链接，或单独传一个链接。
+`type=phone` 传合法电话号码。
+`type=email` 传合法邮箱字符串。
 
 ```json
 {
-    "标题": "Hello",
+    "标题": "Hello, [lark-cli](https://github.com/larksuite/cli)",
+    "官网": "[官网](https://example.com)",
     "联系电话": "1380000000000",
-    "官网": "https://example.com"
+    "邮箱": "owner@example.com"
 }
 ```
 
@@ -43,7 +48,7 @@
 
 ### 2.3 select（单选/多选）
 
-单选用选项名字符串；多选用选项名数组。选项名建议与字段配置一致；写入未知选项时平台可能自动新增选项，因此不要把自然语言近义词当成已有选项传入。
+`select` 字段用 `multiple` 区分单选和多选：`multiple=false` 时传选项名字符串，`multiple=true` 时传选项名数组。只支持写入字段中已有的选项；构造 CellValue 前先用 `+field-list` 或 `+field-search-options` 确认目标选项存在。
 
 ```json
 {

package/skills/lark-base/references/lark-base-dashboard-block-get-data.md

@@ -98,21 +98,21 @@ lark-cli base +dashboard-block-get \
 
 ## 返回结构总览
 
-服务端响应外层仍然是标准 OpenAPI 包装：
+CLI 成功输出使用标准 `{ok, identity, data}` 信封：
 
 ```json
 {
-  "code": 0,
-  "msg": "success",
+  "ok": true,
+  "identity": "user",
   "data": {
-    "dimensions": [...],
-    "measures": [...],
-    "main_data": [...]
+    "dimensions": [],
+    "measures": [],
+    "main_data": []
   }
 }
 ```
 
-其中 `data` 就是 CLI 图表协议本体。不同图表类型的 `data` 结构略有不同：
+其中 `identity` 是本次调用实际使用的身份，`data` 是 CLI 图表协议本体。不同图表类型的 `data` 结构略有不同：
 
 | 图表类型 | 一定有 | 可能有 |
 |----------|--------|--------|

package/skills/lark-base/references/lark-base-dashboard.md

@@ -19,12 +19,19 @@ Dashboard 是 Base 中的数据可视化看板，可以把表格数据变成**
 | 修改组件 | `+dashboard-block-update` | 先读 block 现状，再读 [dashboard-block-data-config.md](dashboard-block-data-config.md) 决定替换哪些顶层 key |
 | 查看仪表盘有哪些组件 | `+dashboard-get` 或 `+dashboard-block-list` | 本页下方「查看仪表盘」 |
 | 读取图表计算结果 | `+dashboard-block-get-data` | 返回图表最终数据协议；需要 block 元数据先用 `+dashboard-block-get` |
-| 智能重排组件布局 | `+dashboard-arrange` | 只在用户明确要求重排时执行；无法指定精确位置 |
+| 智能重排组件布局 | `+dashboard-arrange` | 用户明确要求重排，或本次会话新建仪表盘的收尾整理；无法指定精确位置 |
 
 ## 典型场景工作流
 
 ### 场景 1：从 0 到 1 创建仪表盘
 
+从 0 到 1 创建仪表盘时，按用户需求规划组件的类型和数量，并注意以下要点：
+
+- 聚合方式：创建指标卡或分布图时优先把聚合写进 `data_config`，只有 Top N、字段取值探索、复杂筛选校验或 helper 汇总表场景才先用 `+data-query`。
+- Dry-run 边界：已按模板构造的简单指标卡、分布图、趋势图不需要逐个 `--dry-run` 后再真实创建；只有在调试 JSON、检查请求体、复杂自造 `data_config` 或处理 API validation 错误时才 dry-run。
+- 验证方式：通过创建接口返回值确认创建成功与否,只在结果不确定时用 `+dashboard-get` 或 `+dashboard-block-list` 确认仪表盘和组件存在,或调用 `+dashboard-block-get-data`读取计算结果验证。
+- 布局方式：`+dashboard-arrange` 仅两种情况使用：① 用户明确要求美化/重排；② 本次会话中从零新建的仪表盘，建完组件后做一次性布局整理。不是创建成功的必要步骤。
+
 示例：搭建一个销售数据分析仪表盘
 
 ```bash
@@ -63,6 +70,7 @@ lark-cli base +dashboard-block-create \
 
 # 第 5 步：组件创建完成后，使用 arrange 命令智能重排布局（可选但推荐）
 # 默认布局可能不够美观，arrange 会根据组件数量和类型自动优化布局
+# 若用户没有要求美化/重排，可先跳过此步骤；这不影响仪表盘和组件是否已创建成功
 lark-cli base +dashboard-arrange \
   --base-token xxx \
   --dashboard-id blk_xxx
@@ -125,11 +133,12 @@ lark-cli base +dashboard-block-update \
   --dashboard-id blk_xxx \
   --block-id chtxxxxxxxx \
   --data-config '{...}'
+
 ```
 
 ### 场景 4：重排仪表盘布局
 
-当用户明确要求对已有仪表盘进行布局重排或美化时使用。
+当用户明确要求对已有仪表盘进行布局重排或美化时使用（对本次会话从零新建的仪表盘，可在建完组件后直接做一次性整理，见场景 1）。
 
 > [!CAUTION]
 > - 排列结果是**服务端智能推荐**，不一定完全符合用户预期

package/skills/lark-base/references/lark-base-data-query.md

@@ -79,16 +79,23 @@ lark-cli base +data-query \
 | `--base-token <token>` | 是 | Base Token（base_token） |
 | `--dsl <json>`         | 是 | LiteQuery Protocol JSON DSL 查询语句 |
 
-## 如何从链接中提取参数
+## 如何从链接中解析参数
 
 用户通常会提供如下 URL：
 
+```text
+https://example.feishu.cn/base/<base_token>?table=<block_id>
 ```
-https://example.feishu.cn/base/<base_token>?table=<table_id>
+
+不要直接把 URL 中的 `table=` 当成数据表 ID。它表示当前选中的 Base 顶层块，可能是数据表、仪表盘、工作流、文件夹或文档。先解析链接：
+
+```bash
+lark-cli base +url-resolve --url "<url>" --as user
 ```
 
-- `--base-token`：取 `/base/` 后面的字符串
-- DSL 中的 `tableId`：取 `table=` 后面的值
+- `--base-token`：使用返回的 `base_token`
+- 仅当返回的 `block_type` 为 `table` 时，DSL 中的 `tableId` 才使用返回的 `table_id`
+- 如果返回的是其他块类型，按 `hint.next_step` 继续处理；如果只返回中性的 `block_id`，先用 `+base-block-list` 确认块类型，再选择实际要查询的数据表
 
 ## API 入参详情
 
@@ -347,28 +354,30 @@ value 使用预定义关键字机制，第一个元素为字符串常量名称
 |------|------|------|------|
 | `format` | string | 是 | 固定为 `"flat"`，表示返回扁平化的对象数组 |
 
-## API 出参详情
+## CLI 出参详情
+
+CLI 输出标准信封 `{ok, identity, data}`（失败时为 `{ok:false, identity, error}`）。
 
 **成功时：**
 
 ```json
-{"code": 0, "data": {"main_data": [{"dim_city": {"value": "北京"}, "total_amount": {"value": 12345.00}}, ...]}, "msg": ""}
+{"ok": true, "identity": "user", "data": {"main_data": [{"dim_city": {"value": "北京"}, "total_amount": {"value": 12345.00}}, ...]}}
 ```
 
 **失败时：**
 
 ```json
-{"code": 800004006, "data": {"error": {"code": 800004006, ...}}, "msg": "DSL validation failed"}
+{"ok": false, "identity": "user", "error": {"type": "api", "subtype": "unknown", "code": 800004006, "message": "...does not exist in table schema", "hint": "...", "log_id": "..."}}
 ```
 
 **Response 字段：**
 
 | 字段 | 类型 | 说明 |
 |------|------|------|
-| `code` | int | 状态码，0 为成功 |
-| `msg` | string | 错误信息 |
-| `data.main_data` | []object | 查询结果数组，每个元素为一行数据 |
-| `data.error` | object | 失败时的错误详情 |
+| `ok` | bool | 是否成功 |
+| `identity` | string | 执行身份：`user` / `bot` |
+| `data.main_data` | []object | 查询结果数组，每个元素为一行数据（成功时） |
+| `error` | object | 失败时的 typed 错误，含 `type` / `subtype` / `code` / `message` / `hint` / `log_id` |
 
 每行数据的字段值封装在 CellValue 中：
 

package/skills/lark-base/references/lark-base-field-create.md

@@ -23,12 +23,12 @@ lark-cli base +field-create \
 lark-cli base +field-create \
   --base-token <base_token> \
   --table-id <table_id> \
-  --json '{"name":"状态","type":"select","multiple":false,"options":[{"name":"Todo","hue":"Blue","lightness":"Lighter"},{"name":"Done","hue":"Green","lightness":"Light"}]}'
+  --json '{"name":"状态","type":"select","multiple":false,"default_value":["Todo"],"options":[{"name":"Todo","hue":"Blue","lightness":"Lighter"},{"name":"Done","hue":"Green","lightness":"Light"}]}'
 
 lark-cli base +field-create \
   --base-token <base_token> \
   --table-id <table_id> \
-  --json '{"name":"负责人","type":"user","multiple":false,"description":"用于标记记录的直接负责人；协作约定可参考[团队字段约定](https://example.com/field-spec)"}'
+  --json '{"name":"负责人","type":"user","multiple":false,"default_value":[{"$slot":"current_user"}],"description":"用于标记记录的直接负责人；协作约定可参考[团队字段约定](https://example.com/field-spec)"}'
 ```
 
 ## 参数
@@ -51,6 +51,7 @@ POST /open-apis/base/v3/bases/:base_token/tables/:table_id/fields
 - `--json` 必须是 **JSON 对象**，顶层直接传字段定义，不要再套一层。
 - 顶层最少包含：`name`、`type`。
 - 所有字段类型都支持可选 `description`；支持纯文本，也支持 Markdown 链接，如 `协作约定可参考[团队字段约定](https://example.com/field-spec)`。
+- 需要字段默认值时传 `default_value`，直接使用字段对应 CellValue；`datetime` / `user` 的动态填充用 `$slot`。完整规则见 [lark-base-field-json.md](lark-base-field-json.md)。
 - `type` 不同，必填子字段不同：
   - `select`：`multiple` 控制是否多选，`options` 定义静态选项，`dynamic_options_source` 定义动态选项来源。静态与动态选项配置二选一，不能同时传。
   - `link`：必须有 `link_table`，可选 `bidirectional`、`bidirectional_link_field_name`。
@@ -64,6 +65,7 @@ POST /open-apis/base/v3/bases/:base_token/tables/:table_id/fields
   "name": "状态",
   "type": "select",
   "multiple": false,
+  "default_value": ["Todo"],
   "options": [
     { "name": "Todo", "hue": "Blue", "lightness": "Lighter" },
     { "name": "Done", "hue": "Green", "lightness": "Light" }
@@ -85,16 +87,20 @@ POST /open-apis/base/v3/bases/:base_token/tables/:table_id/fields
 ## 返回重点
 
 - 返回 `field` 和 `created: true`。
+- 如果返回 `field_get_recommended:false` 且 `next_step:"done"`，表示本次是简单字段创建，通常不需要立刻执行 `+field-get`。
+- 如果返回 `field_get_recommended:true` 或 `next_step:"field_get"`，按 `verification_hint` 读回字段；`formula`、`lookup`、`link`、`auto_number` 等计算、关联或生成型字段更适合读回确认服务端最终结构。
 
 ## 工作流
 
 
 1. formula / lookup 字段必须先阅读对应指南；没读之前不要直接创建。
+2. 创建简单字段时，优先相信命令返回；只有用户要求精确核对额外属性，或返回建议读回时，才继续执行 `+field-get`。
 
 ## 坑点
 
 - ⚠️ 这是写入操作，执行前必须确认。
 - ⚠️ 当 `type` 是 `formula` 或 `lookup` 时，先读对应 guide，再创建。
+- ⚠️ 不要把“每次创建后都 `+field-get`”当作固定流程；按返回里的 `field_get_recommended` 和 `next_step` 决定是否读回。
 
 ## 参考
 

package/skills/lark-base/references/lark-base-field-json.md

@@ -9,6 +9,7 @@
 - `--json` 必须是 JSON 对象。
 - 顶层统一使用：`type` + `name` + 类型特有字段。
 - 所有字段类型都支持可选 `description`；支持纯文本，也支持 Markdown 链接。
+- 字段默认值使用 `default_value`，直接传对应 CellValue；支持范围只有 `text`、`number`、静态 `select`、`datetime`、`user`。清空默认值传 `null`；省略表示创建时不设置、更新时不修改。
 - 不要使用旧结构：`field_name`、`property`、`ui_type`、数字枚举 `type`。
 - `+field-update` 使用同样的字段 JSON 结构，但语义是 `PUT`；这是高风险写入操作，建议先 `+field-get` 再按目标状态全量提交，并带 `--yes`。
 - `type=formula` 或 `type=lookup` 创建/更新前，必须先读对应 guide。
@@ -27,12 +28,12 @@
 
 | 类型 | 最小必填字段 | 常见补充字段 |
 |------|--------------|-------------|
-| `text` | `type` `name` | `style.type` |
-| `number` | `type` `name` | `style` |
-| `select` | `type` `name` | `multiple` + `options`，或 `multiple` + `dynamic_options_source` |
-| `datetime` | `type` `name` | `style.format` |
+| `text` | `type` `name` | `style.type` `default_value` |
+| `number` | `type` `name` | `style` `default_value` |
+| `select` | `type` `name` | `multiple` + `options` + 静态 `default_value`，或 `multiple` + `dynamic_options_source` |
+| `datetime` | `type` `name` | `style.format` `default_value` |
 | `created_at` / `updated_at` | `type` `name` | `style.format` |
-| `user` / `group_chat` | `type` `name` | `multiple` |
+| `user` / `group_chat` | `type` `name` | `multiple`；仅 `user` 支持 `default_value` |
 | `created_by` / `updated_by` | `type` `name` | 无 |
 | `link` | `type` `name` `link_table` | `bidirectional` `bidirectional_link_field_name` |
 | `formula` | `type` `name` `expression` | 无 |
@@ -47,31 +48,37 @@
 ### 3.1 text
 
 文本字段；电话、超链接、邮箱、条码也都属于 `text`，通过 `style.type` 区分。
+支持 `default_value`：静态 Markdown 文本字符串；`phone` style 必须是合法电话号码；`url` style 传一个 Markdown 链接或裸 URL；`email` style 必须是合法邮箱字符串，不要传 Markdown 链接或 `mailto:`。
 
 最小写法（默认 `style.type` 为 `plain`）：
 
 ```json
 {
   "type": "text",
-  "name": "标题"
+  "name": "标题",
+  "default_value": "默认标题"
 }
 ```
 
 常用写法：
 
+默认值可以是 Markdown 文本
 ```json
 {
   "type": "text",
   "name": "标题",
-  "description": "主标题字段"
+  "description": "主标题字段",
+  "default_value": "未命名"
 }
 ```
 
+`style.type=phone` 时默认值是合法电话号码字符串。
 ```json
 {
   "type": "text",
   "name": "联系电话",
-  "style": { "type": "phone" }
+  "style": { "type": "phone" },
+  "default_value": "+8613800000000"
 }
 ```
 
@@ -79,7 +86,17 @@
 {
   "type": "text",
   "name": "官网",
-  "style": { "type": "url" }
+  "style": { "type": "url" },
+  "default_value": "[官网](https://example.com)"
+}
+```
+
+```json
+{
+  "type": "text",
+  "name": "邮箱",
+  "style": { "type": "email" },
+  "default_value": "owner@example.com"
 }
 ```
 
@@ -88,13 +105,15 @@
 ### 3.2 number
 
 数字字段；货币、进度、评分都属于 `number`，通过 `style.type` 区分。
+支持 `default_value`：静态 JSON number；所有 number style 都按这个规则写。
 
 最小写法（默认 `style.type` 为 `plain`）：
 
 ```json
 {
   "type": "number",
-  "name": "工时"
+  "name": "工时",
+  "default_value": 8
 }
 ```
 
@@ -118,7 +137,8 @@
     "precision": 2,
     "percentage": false,
     "thousands_separator": true
-  }
+  },
+  "default_value": 8
 }
 ```
 
@@ -151,7 +171,8 @@
 {
   "type": "number",
   "name": "完成度",
-  "style": { "type": "progress", "percentage": true, "color": "Blue" }
+  "style": { "type": "progress", "percentage": true, "color": "Blue" },
+  "default_value": 0.65
 }
 ```
 
@@ -159,11 +180,11 @@
 
 支持字段：`icon`、`min`、`max`
 
-默认值 / 约束：
+默认值 / 已知平台范围：
 - `icon` 默认 `star`
 - `icon` 可用：`star`、`heart`、`thumbsup`、`fire`、`smile`、`lightning`、`flower`、`number`
 - `min` 取值 `0..1`，默认 `1`
-- `max` 取值 `1..10`，默认 `5`
+- `max` 默认 `5`；常见或已文档化的范围为 `1..10`，但 CLI 不强制上限为 `10`。如果用户明确需要更大评分范围，优先确认平台能力或用 `+field-create/update --dry-run` 检查请求形状；平台拒绝后再建议改用普通数字或进度字段。
 
 ```json
 {
@@ -180,6 +201,7 @@
 #### 静态选项
 
 支持字段：`multiple`、`options`
+支持 `default_value`：静态选项名数组；即使 `multiple=false` 也写数组，如 `["Todo"]`。
 
 默认值 / 约束：
 - `multiple` 默认 `false`
@@ -189,12 +211,14 @@
 - `options[].hue` 可用：`Red`、`Orange`、`Yellow`、`Lime`、`Green`、`Turquoise`、`Wathet`、`Blue`、`Carmine`、`Purple`、`Gray` 缺省值为 `Blue`
 - `options[].lightness` 可用：`Lighter`、`Light`、`Standard`、`Dark`、`Darker` 缺省值为 `Lighter`
 - 选项里没有 `id`，只有 `name`。
+- 支持 `default_value` 配置：填选项名数组。
 
 ```json
 {
   "type": "select",
   "name": "状态",
   "multiple": false,
+  "default_value": ["Todo"],
   "options": [
     { "name": "Todo", "hue": "Blue", "lightness": "Lighter" },
     { "name": "Done", "hue": "Green", "lightness": "Light" }
@@ -205,6 +229,7 @@
 #### 动态选项
 
 支持字段：`multiple`、`dynamic_options_source`
+动态选项不支持 `default_value`。
 
 默认值 / 约束：
 - `multiple` 默认 `false`
@@ -213,6 +238,7 @@
 - `dynamic_options_source.field_id` 填来源字段 id 或字段名
 - `dynamic_options_source` 仅创建支持；更新已有字段时不要传
 - 引用选项条件 / 级联筛选条件：这个功能在 Base 前端支持，属于 UI-only 属性，OpenAPI 里不支持，CLI 不能读取、创建或更新；不要根据接口返回缺失判断未配置
+- 动态选项不支持配置 `default_value`。
 
 ```json
 {
@@ -229,13 +255,15 @@
 ### 3.4 datetime
 
 手动填写的日期/时间字段。系统时间用 `created_at` / `updated_at`。
+支持 `default_value`：静态时间字符串，或 `{ "$slot": "record_created_time" }`。`datetime + record_created_time` 是自动填充可编辑单元格；`created_at` 是只读创建时间元信息。
 
 最小写法：
 
 ```json
 {
   "type": "datetime",
-  "name": "截止时间"
+  "name": "截止时间",
+  "default_value": "2026-03-24 10:00:00"
 }
 ```
 
@@ -251,7 +279,8 @@
 {
   "type": "datetime",
   "name": "截止时间",
-  "style": { "format": "yyyy-MM-dd HH:mm" }
+  "style": { "format": "yyyy-MM-dd HH:mm" },
+  "default_value": { "$slot": "record_created_time" }
 }
 ```
 
@@ -276,12 +305,19 @@
 ### 3.6 user / group_chat
 
 人员字段和群字段都支持 `multiple`。
+`user` 支持 `default_value`：人员 CellValue 数组，元素可用 `{ "id": "ou_xxx" }` 或 `{ "$slot": "current_user" }`；不要猜用户 ID。`group_chat` 不支持默认值。
 
 默认值 / 约束：
 - `multiple` 默认 `true`
+- `user` 字段支持 `default_value` 配置，`group_chat` 字段不支持 `default_value` 配置。
 
 ```json
-{ "type": "user", "name": "负责人", "multiple": true }
+{
+  "type": "user",
+  "name": "负责人",
+  "multiple": true,
+  "default_value": [{ "$slot": "current_user" }, { "id": "ou_xxx" }]
+}
 ```
 
 ```json
@@ -383,7 +419,7 @@
 
 ### 3.11 auto_number
 
-自动编号字段；不写 `style.rules` 时使用默认规则：`NO.001`。
+自动编号字段；创建时不写 `style.rules` 会使用默认规则：`NO.001`。更新已有自动编号字段时应显式提交目标 `style.rules`，因为 `+field-update` 会把新的编号规则重新应用到已有编号。
 
 最小写法：
 
@@ -476,7 +512,7 @@
 ## 4. 创建与更新
 
 - `+field-create`：按目标字段配置直接构造 `--json`。
-- `+field-update`：使用同样的 JSON 结构，但语义是 `PUT`；建议先 `+field-get`，再按目标完整状态提交，并带 `--yes`。
+- `+field-update`：使用同样的 JSON 结构，但语义是 `PUT`；建议先 `+field-get`，再按目标完整状态提交，并带 `--yes`。当 `type` 是 `auto_number` 时，更新编号规则本身就会把新规则应用到已有编号，无需额外参数，也不要在 JSON 里塞额外的底层实现参数。
 
 ## 5. 暂不支持字段
 
@@ -488,3 +524,4 @@ Object（对象字段）、Button（按钮字段）、Stage（流程字段）暂
 - `number` 的精度、货币、进度、评分配置都放在 `style` 下，不要写顶层 `precision`。
 - `datetime` 是手动日期字段；系统时间请改用 `created_at` / `updated_at`。
 - `formula` / `lookup` 没读 guide 前不要直接写。
+- 只有 `text`、`number`、静态 `select`、`datetime`、`user` 支持 `default_value`；清空统一传 `"default_value": null`。其他字段类型不要配置默认值。

package/skills/lark-base/references/lark-base-field-update.md

@@ -11,14 +11,21 @@ lark-cli base +field-update \
   --base-token <base_token> \
   --table-id <table_id> \
   --field-id <field_id> \
-  --json '{"name":"状态","type":"select","multiple":false,"options":[{"name":"Todo","hue":"Blue","lightness":"Lighter"},{"name":"Doing","hue":"Orange","lightness":"Light"},{"name":"Done","hue":"Green","lightness":"Light"}]}' \
+  --json '{"name":"状态","type":"select","multiple":false,"default_value":["Doing"],"options":[{"name":"Todo","hue":"Blue","lightness":"Lighter"},{"name":"Doing","hue":"Orange","lightness":"Light"},{"name":"Done","hue":"Green","lightness":"Light"}]}' \
   --yes
 
 lark-cli base +field-update \
   --base-token <base_token> \
   --table-id <table_id> \
   --field-id <field_id> \
-  --json '{"name":"负责人","type":"user","multiple":false,"description":"用于标记记录的直接负责人"}' \
+  --json '{"name":"负责人","type":"user","multiple":false,"default_value":null,"description":"用于标记记录的直接负责人"}' \
+  --yes
+
+lark-cli base +field-update \
+  --base-token <base_token> \
+  --table-id <table_id> \
+  --field-id <field_id> \
+  --json '{"name":"编号","type":"auto_number","style":{"rules":[{"type":"text","text":"TASK-"},{"type":"created_time","date_format":"yyyyMM"},{"type":"text","text":"-"},{"type":"incremental_number","length":4}]}}' \
   --yes
 ```
 
@@ -42,15 +49,19 @@ lark-cli base +field-update \
 PUT /open-apis/base/v3/bases/:base_token/tables/:table_id/fields/:field_id
 ```
 
+当 `--json.type` 是 `auto_number` 时，仍然走同一个 v3 字段更新接口：更新自动编号规则后，接口现状就会把新规则应用到已有编号（这是接口默认行为，只是 agent 通常不知道），因此**不需要**任何额外开关或参数。只需要正常提交目标自动编号字段定义即可；如果用户要求“将修改用于已有编号”，直接执行这次 `+field-update` 就能达到效果，不要在 `--json` 里额外添加任何参数去“触发”重排。
+
 ## JSON 值规范
 
 - `--json` 必须是 **JSON 对象**，顶层直接传字段定义。
 - 更新语义是 `PUT`（全量字段配置更新），不要只传零散片段；至少显式包含 `name`、`type`，并补齐该类型所需关键配置。
 - 所有字段类型都支持可选 `description`；支持纯文本，也支持 Markdown 链接。
+- 需要字段默认值时传 `default_value`，直接使用字段对应 CellValue；传 `null` 清空，省略表示不修改现有默认值。完整规则见 [lark-base-field-json.md](lark-base-field-json.md)。
 - `select` 更新时：`options` 仍按对象数组传，避免混入无效字段。
 - `link` 更新限制：
   - 不能把非 `link` 字段改成 `link`，也不能把 `link` 改成非 `link`。
   - 现有 `link` 字段的 `bidirectional` 不能改。
+- `auto_number` 更新的 `style.rules` 支持 `text`、`created_time`、`incremental_number`。
 
 **推荐更新示例**
 
@@ -59,6 +70,7 @@ PUT /open-apis/base/v3/bases/:base_token/tables/:table_id/fields/:field_id
   "name": "状态",
   "type": "select",
   "multiple": false,
+  "default_value": ["Doing"],
   "options": [
     { "name": "Todo", "hue": "Blue", "lightness": "Lighter" },
     { "name": "Doing", "hue": "Orange", "lightness": "Light" },
@@ -81,13 +93,18 @@ PUT /open-apis/base/v3/bases/:base_token/tables/:table_id/fields/:field_id
 ## 返回重点
 
 - 返回 `field` 和 `updated: true`。
+- `updated:true` 只表示更新请求成功，不表示字段结构、已有记录值或下游能力已经完成验证。`+field-update` 无法知道更新前的字段类型，因此成功响应会推荐执行 `+field-get`；若发生类型转换，还要抽样读取记录值。
+- 如果响应中的 `field.type` 与提交的 `type` 不一致，必须把它当作待核验的类型不匹配；不能返回完成态，也不能只根据其中任一类型推断更新成功。
+- 如果 API 报告本次更新没有产生任何变更（no-op），命令会如实返回该错误；这通常说明目标字段已是期望状态，不要机械重试同一份 `+field-update`。需要确认当前字段完整状态时执行 `+field-get`。
+- 如果返回 `field_get_recommended:true` 或 `next_step:"field_get"`，按提示读回字段；`auto_number` 更新后还应抽样读记录值确认编号已按新规则生成。
 
 ## 工作流
 
 
 1. 建议先用 `+field-get` 拉现状，再做最小化修改。
 2. `formula/lookup` 类型更新前先阅读对应指南。
-3. 如果这次更新会改变字段 `type` 先按下方“字段类型变更规则”判断能否执行。如果不修改 `type`，大多数场景都相对安全。
+3. 如果更新 `auto_number`，理解为“更新编号规则，同时把新规则应用到已有编号”；执行后按返回提示读回字段并在必要时抽样记录值。
+4. 如果这次更新会改变字段 `type` 先按下方“字段类型变更规则”判断能否执行。如果不修改 `type`，大多数场景都相对安全。
 
 ## 字段类型变更规则
 
@@ -153,6 +170,7 @@ PUT /open-apis/base/v3/bases/:base_token/tables/:table_id/fields/:field_id
 ### 完成态验证
 
 - `FieldReadback`: 读回字段结构，确认 `type` / `multiple` / `style` / `options`
+- `NoopReadback`: `+field-update` 返回 no-op 错误时，只能说明 API 报告没有产生变更；可以跳过重复 update，但不能替代 `FieldReadback`
 - `ValueReadback`: 抽样读回转换后的单元格值
 - `DownstreamReadback`: 若涉及看板 / 分组 / 排序 / lookup / 公式，继续读回结果
 - `CompletionRule`: 结构、值、下游能力都正确，才能回复“已完成”