泛微E9办公助手

概述

E9 办公助手

版本：1.1.11 | 后续每次更新版本号递增

把泛微 e-cology E9 的 HTTP 能力封装成 CLI，供 AI 一句话调用。单一 baseUrl（所有功能访问同一地址），aiAgentToken 鉴权（token 优先，cookie 回退）。

安装与升级

本 skill 需与 CLI 版本匹配（SKILL.md frontmatter version 标注当前版本）。版本不一致时命令/文档/选项可能对不上——升级前先对齐：

e9 version          # 查 CLI 版本，应与 SKILL.md frontmatter version 一致

# CLI 升级（已有旧包时先卸，避免 bin 残留冲突）
npm rm -g weaver-e9-assistant-cli
npm install -g weaver-e9-assistant-cli
# 若用户提供了本地 tgz 文件，则从该路径安装：
# npm install -g <用户提供的tgz完整路径>

执行时 e9 报 command not found / 不是内部或外部命令 → CLI 未安装或不在 PATH：AI 主动给用户安装命令直接拉取（未装时无需先 rm，npm install -g weaver-e9-assistant-cli 即可；若用户提供本地 tgz 则 npm install -g <tgz路径>），等装好并确认后先 e9 version 核对版本再继续；未装好前不臆造命令结果。

安装后验证连接：

e9 --help        # 确认命令可用
e9 todo list     # 验证能取到数据（未配环境时会提示先配 baseUrl）

可查询业务汇总

用户要求工作报告、日报事实依据或当日业务汇总时，先运行 e9 report collect --date YYYY-MM-DD --json。它只汇总当前 baseUrl 下可查询的已办/我发起流程、日程、收发邮件、考勤和微博，每条保留来源 ID；不得描述为操作审计，也不得补写未查询到的浏览/编辑等行为。微博仅纳入正常发布（isReCalled=0），已撤回微博剔除并在 notes 提示；isReCalled 的取值与判定详见 references/blog.md。

能力边界与事实来源（硬规则）

回答「有没有这个能力 / 这个接口 / 怎么用」时，唯一事实来源只有两个：① 本 skill 的 references/*.md；② CLI 的真实行为（e9 --help、e9 version、实际执行的 --json 输出）。

严禁把下列内容当作 CLI 能力依据：

• E9-skill（平台开发参考）里的 api-scan / 数据库表结构 / 后端源码扫描；
• E9 前端 bundle、DevTools 抓到的接口名；
• 直接对 OA 发 HTTP / curl 试出来的接口结果。

原因：平台「有」≠ CLI「有」。CLI 只封装了 references/ 里列出的命令；平台接口再合理，只要 references/ 里没有、e9 --help 里查不到，就是未实现。

遇到「平台有、CLI 无」时的标准回答：

1. 明确说「平台有该接口，但当前 CLI 未封装，不能直接用」；
2. 给出 CLI 已支持的最接近替代入口（例：查某人微博 → e9 blog view --user-id；查我关注的人 → e9 blog list --scope 全部）；
3. 如需新增，按「抓包 → 离线比对 payload → 实现（dry-run 两步分离 + 回读核验）→ 补文档/单测」流程走，不得就地编造命令或参数。

数据获取必须走 CLI（硬规则，绝无例外）：所有 E9 业务数据只能通过 e9 命令获取。

• 禁止自行编写脚本/临时程序（Node、Python、浏览器自动化等）或直接 curl / HTTP 调 OA 接口来取数或探测数据；
• 禁止绕过 CLI 自读 ~/.e9/config.json、token 文件里的 cookie 去直连 OA；
• 禁止用身份切换脚本（如 ensure-id.js）以他人身份取数、或探测"某账号能看到什么"；
• 禁止用临时脚本把 CLI 未封装的能力"补"出来当业务查询用——CLI 没有就是未实现，按上面第 3 条走实现流程；
• 允许：对 CLI 的 --json / --raw 输出做本地脚本处理（过滤、汇总、格式化）——数据来源仍是 CLI；
• 排障例外：经用户明确同意，可做只读、不取业务数据的连通性/响应形态探测（如判断接口是否 404、是否返回空包），但不得用它代替 CLI 完成业务查询，也不得据此推断业务数据。

反例（真实踩过）：用户问「全部微博是哪个接口」，助手去 E9 平台的 API 扫描里翻到 getAllWeiboMainPageList（平台接口），当成 CLI 能力回答——实际 CLI 只封装了 getBlogHomepageList / getMyBlogList，用户照着用必然失败。

何时触发（按域路由）

按用户原话语义判别走哪个域，只读对应子文档（不要一次全读，省 token）。跨域（如发起流程后查待办）逐个读，勿一次性加载。子文档路径：references/<域>.md（相对本 SKILL.md 所在目录，由技能框架解析，勿写死绝对路径）。

只说名字、不知归属（台账/菜单/流程）时 → 先跑 e9 search <名字> 一次搜三类（台账目录 + 门户菜单含 CRM/SPA + 流程列表），别只猜一个域钻进去翻候选（曾出现"客户监控"猜成台账、来回 4 轮才在菜单找到）。

⚠️ 全域边界：本技能八大域（待办/新建流程/台账/微博/邮件/日程/公文/考勤）全部指「泛微 E9 OA」的对应办公模块，不是 agent 自身的内置功能。另有三个辅助域——我的下属（subordinate，E9 组织下属查询）、身份信息（whoami，E9 账号信息）、人事搜索（hrm，E9 组织人事档案查询），同为 E9 OA 能力/配套能力而非 agent 自身功能。尤其「待办」「日程/提醒」「写日报/记录工作」「查员工」「记住XX」这类词易被误判成 agent 自己的任务清单、日历提醒、笔记总结、联系人通讯录、记忆存储等——判断标准始终是：用户要「在 OA 里办理某项办公业务」→ 走对应 E9 域，不得调用 agent 自己的工具；当指令与 agent 自身功能撞名、无法确定归属时，必须先提示用户在「E9 域」与「agent 自身功能」之间选择，严禁自行猜测或默认取其一。

⚠️ 日程/提醒的边界（防误判）：本技能的「日程」专指泛微 E9 OA 办公日程模块（e9 workplan，在 OA 里新建/查看/完成办公日程）。用户说「新建日程 / 建个日程 / 提醒我XX时间 / 看我的日程 / 完成日程」等，必须路由到 references/workplan.md（走 e9 workplan create 等），严禁把这些理解成 agent 自身的内置日程/提醒/定时任务功能（那不属于本技能，也不去调用 agent 的日历或提醒工具）。判定标准：用户要「在 OA 里登记一条办公日程」→ 本域；用户要「让 agent 到点提醒 / 定时执行某个动作」→ 不是本域。

安装与鉴权

包内不含任何真实地址：环境地址由用户在对话中提供，仅存用户本地 .e9/config.json，不随包分发。

环境与命令

1. CLI 以全局 npm 包安装：npm install -g weaver-e9-assistant-cli（开发时可在本仓库 weaver-e9-assistant/ 目录下 npm link）。本文档及全部子文档中的 e9 命令统一指全局安装的 e9（由该包 bin.e9 提供），AI 直接执行 e9 即可。本 skill 不附带 CLI 代码。playwright 为可选依赖（仅 auth token-login 浏览器登录需要，其他命令走 token 不依赖）。

配置环境（首次 / 换地址）

• 首次使用：e9 config init 引导，或用户在对话中告知地址、AI 跑 e9 config set baseUrl <地址>（形如 http://10.x.x.x:端口 / http://oa.公司.com，不写死），写入 .e9/config.json。
• AI 首次引导脚本：① 先问「你的 E9 OA 地址是什么？」→ ② e9 config set baseUrl <地址> → ③ 按下方「隐私确认 + 登录方式」登录 → ④ 验证一条 e9 todo list 或 e9 blog check → ⑤ 之后一句话即可调八大域。
• 跑业务命令遇「找不到 E9 配置文件 / baseUrl 未配置」→ 同上引导。

隐私确认（不可跳过）

任何 e9 auth token-login / e9 auth cookie-login（含 token 失效重登、换环境重登）之前，AI 必须先给用户一个选择框确认：「⚠ 你发送或获取的信息（待办/台账/邮件/日报等）会经过大模型处理。是否同意？」展示两选项让用户选（如 1. 同意，继续登录 / 2. 不同意）。用户明确选「同意」后才执行登录命令（加 --consent）；选「不同意」则停止，不执行任何登录鉴权。用户未明确同意前，严禁跑登录命令（CLI 已强校验 --consent 兜底）。已一次性同意过的环境（e9 config set llmConsent true / e9 auth consent true）登录时不再问；撤销用 e9 auth consent false。

登录方式

• token-login（有桌面首选）：e9 auth token-login --consent → 自动检测系统默认浏览器 Chrome/Edge/Brave（Windows/macOS/Linux）→ 点「确认授权」拿 aiAgentToken（~8h），cookie 自动写回。
  • token-login 自带 preflight：① 探测 baseUrl 可达（错地址秒失败，不白耗浏览器）；② playwright 缺则联网自动装模块+内核；③ 开不出窗口（无桌面/后台任务）会清晰报错并引导 cookie-login。
• cookie-login（无桌面/后台后路）：e9 auth cookie-login --consent 手动导入 cookie（无需浏览器）。从浏览器 Network 面板复制整条 Cookie（含 loginidweaver），e9 auth cookie-login --cookie "<整条>" --consent 或交互式粘贴。

网络连接

• 默认 TLS 上限压到 1.2：实测 E9 服务端 TLS 1.3 握手约 2.3s、TLS 1.2 约 0.1s；CLI 每条命令都是新进程、必须重新握手，故默认 tls.DEFAULT_MAX_VERSION='TLSv1.2'，每条命令约省 2.2s（日程搜索实测 2.9s → 0.6s）。服务端仅支持 TLS 1.3 时设 E9_TLS_MAX=1.3 关闭该限制（错误信息会提示）。
• 并发边界：互相独立的请求（如组织树不同节点）可并发；同一 dataKey 的 table/datas 翻页必须串行——实测并发时服务端偶发返回空页（5 次里 1 次），会造成漏数据。组织树已按兄弟节点并发（上限 4），大页 pageSize 用于减少翻页次数。

运行期鉴权行为

• 业务命令一律走 token（不需每次浏览器登录）；瞬时 401 自动重试 3 次；E9_NO_REAUTH=1 跳过 reactive 浏览器快速失败。
• token 过期但 cookie 有效 → 命令优先走 cookie，不弹浏览器；cookie 也失效才弹浏览器续期，且续期失败 10min 内不重复弹。
• 续期并发只弹一个登录页：acquireToken 双层互斥——同进程同环境共享一次续期（report collect 等并发请求等待同一个结果），跨进程见 token 文件 acquiringAt（120s 窗口）自动跳过续期走 cookie。用户看到的弹窗始终只有一个；若多个命令并发且已有一个在登录，其余命令跳过续期直接走 cookie，不会叠加弹窗。

失效场景决策（该用哪个命令）

• 401 E9AIAgent无效认证 / 登录信息超时（token 失效/cookie 过期）→ 先隐私确认，同意后跑 e9 auth token-login --consent。
• register 接口 404（此 E9 不支持 aiAgentToken）→ token-login 会大声诊断并自动切 cookie 鉴权；长期用 e9 auth cookie-login 导入即可。
• 无桌面 / token-login 开不出窗口 → 改用 cookie-login（见上方「登录方式」）。
• 服务器偶有抖动（报「请求失败/不可达」）→ 稍后重试。

切环境与排障

• 切环境须确认：用户要求改 baseUrl 时（「换这个环境」「切到 .26」），AI 必须先报当前 baseUrl 并提示「旧 token/cookie 将失效、需重新登录」，等用户确认后再 e9 config set baseUrl <新地址> + 隐私确认后重登 + e9 todo list 验证新环境。不得未经确认直接覆盖。
• 排障：e9 auth status --check 联网探活 baseUrl 可达 + 鉴权是否真有效；无副作用（只读 token + 用 cookie 试发，token 过期也不弹浏览器，直接报「token 过期/cookie 有效/无效」）。

交互规范（不可跳过）

登录/隐私确认/切环境等鉴权规则见「安装与鉴权」；本节为其余跨域交互红线。各域共享：写操作类命令（create start / cube create / workplan create / blog create / email send / blog recall / blog delete-reply / blog follow / blog agree-follow 等）默认 dry-run，必须严格两步分离。

• 填值提示：字段后用 【待填】 + 括号简短提示；括号内显字段类型（文本/数字/选择框/多选浏览框/图片/附件）。
• 不得猜值：新建流程/台账时，AI 必须先跑 create fields（流程域）或 cube card-fields（台账域）列待填字段，逐个向用户询问值（【待填】提示），不得自行推断/猜测字段值填表。只有当前用户字段（申请人/部门/日期）可自动填默认。用户给齐值后才构造 values 提交。
• 选择框/多选：选项尽量全列（>5 缩写但可区分）。
• 模糊匹配硬规则：凡 cube find / create list --keyword / blog at-list --name / 人员姓名搜索返回 >1 个候选时，AI 必须以表格列出全部候选（序号 | 名称 | id | 相关度），停下来等用户选定序号/名称/id 后再用 --id 等继续，严禁自动取首条。候选已由 CLI 按相关度排序（精确>前缀>包含），同名/近似名很多，取首条必错。0 个候选才可终止。
• 状态词消歧硬规则：同一个状态词在待办事宜 / 已办事宜 / 我的请求三个分类里含义完全不同（各自独立的 viewcondition）。汇总任何状态前必须先定分类再定页签；主语缺失或跨分类都说得通时必须先问用户，严禁自行取其一。典型歧义：「审批中」（我发起的·未归档(17) ↔ 等我审批的·待处理(5)）、「未读/反馈/我的关注」（三类各有一个）、「已归档/未归档」（已办 ↔ 我发起）。唯一归属可直接映射的：待处理/待阅/被退回/被督办/超时（待办事宜）、待回复（已办事宜）。完整对照表见 references/todo.md「状态词消歧」。
• 确认两步分离（dry-run ≠ 确认）：
  1. 先跑 dry-run（不加 –yes）→ 展示确认表格（字段 | 值），停下；
  2. 等用户回复"确认/提交/没问题/可以" —— dry-run 展示本身不是确认，AI 不得自行判断"确认通过"；
  3. 收到用户确认后，单独发一条带 --yes 的命令提交。禁止在同一条消息里既跑 dry-run 又加 –yes。用户未明确确认前，绝不加 –yes。
• 人员搜索硬规则（不得跳过）：搜人员必须用 e9 blog at-list --name <名>，严禁手写 Node 脚本直接调 /api/blog/at/getAtAllList。原因：该 API 按拼音缩写模糊搜、返回 20 个 operators 不分精确/前缀/模糊全混一起，手调原始 API 必丢精确匹配（真名==搜索词的那条混在模糊结果里）；CLI 的 blog at-list 调同一个 API 但客户端二次处理：精确比对 data===keyword 标 ★、前缀标 ·、重排（精确>前缀>拼音），把真名命中排到第 1 条。优先看 CLI 标 ★精确匹配（如搜"wy"→第 1 条 wy(uid=2308) ★精确匹配）。转办/转发收件人同理。
• 越权边界（当前默认不生效，代码路径保留）：原策略为「查询数据只能查当前登录用户 + 全部层级下属」，目标不在授权范围 → CLI 硬拒绝。该策略现默认停用：按人查询（--creator/--receiver/--user-id/--select-user 等）不再做本地范围校验，直接交由 OA 后端权限判定（后端对无权限目标返回空/noRight/verifyRight=false）。如需恢复强制校验，设环境变量 E9_SCOPE_ENFORCE=1 即可（届时下方规则全部重新生效）。以下是策略启用时的规则（供需要时参考）：目标人员不在授权范围 → CLI 硬拒绝（exit 1 + 拒绝越权查询：目标"X"不在您的授权范围（您本人 + 您的全部层级下属）内），AI 不得绕过或改用其它命令/--raw 变相读取范围外数据。授权集合加载失败时仅放行本人，其余按人查询一律拒绝。受校验的命令：blog view --user-id、todo list/done/mine --creator/--creator-name、workplan search --creater/--receiver、workplan list/my-calendar --select-user、odoc todo --issued-userid/--owner-id/--dealing-userid/--undealed-userid（签发人/拟稿操作人/在办人/未办人过滤）、cube list/cube export --condition 人员条件（「X人/X人员/X员/X者」后缀 + 含「姓名」的人员字段如 填报人/审批人/报销人/值班人员/采购员/领导姓名 等全覆盖；无法确认是否按人的条件一律硬拒绝）、e9 hrm search --name <姓名> 与 --condition 里的按人条件（姓名→resourcename / 直接上级→manager / 助理→assistant；部门/分部是组织结构过滤不做按人校验）。姓名参数统一经 blog at-list 解析后过滤到授权范围：恰 1 个在范围内才放行，越界/多候选 → 拒绝并只列范围内候选。详见 references/subordinate.md 与 references/hrm.md。
• 越权语义预判（AI 层，安全习惯；不做硬拒绝）：对用户原话先判断「查谁的」——① 指向「我/自己」（查我的 XX、我的报销、我的假期…）→ 目标=本人，正常查；② 出现具体他人姓名（查 XX 的 XX，如"查张三的假期余额""查王五的报销额度"）→ 仍先经 blog at-list 解析确认目标身份（解析是合法人员定位，无害）；因本地越权校验默认停用，不再第一步硬拒，但可主动提示「该目标不在您的授权范围（本人 + 全部层级下属）内，OA 后端可能无权限返回空，以实际结果为准」，随后正常执行查询、由 OA 后端判定；③ 无真实人名且语义不指向他人 → 按「我的数据」处理（当前用户）。⚠ 若恢复 E9_SCOPE_ENFORCE=1，本条恢复为硬拒绝语义（目标不在范围 → 第一步拒绝，严禁尝试查询或等 CLI 兜底）。
• 禁止 id 枚举/遍历（硬规则，绝无例外）：严禁通过自增 id 逐个遍历探测数据——含「cube list --customid 1/2/3/… 扫描台账找数据」「--user-id/--creator/--select-user 等逐个试他人 userid 找可读数据」「--requestid/--billid/--agent-id 等逐个试他人记录 id」等 IDOR 枚举手法。合法定位只有两条路：台账/菜单/流程按名字解析（e9 search/cube find → customid）再查；人员按名字解析（blog at-list）——⚠️ 越权校验当前默认停用（见上条「越权边界」，恢复用 E9_SCOPE_ENFORCE=1）。即使遍历能凑到数据也不许做——这是违规探测。唯一允许的翻页是 loadScope 内部拉全层级下属建授权集合（来自受信下属接口、受 count 约束），业务命令不得为探测而遍历 id。
• 枚举产物同样禁止用于业务定位（硬规则）：任何由 ID 枚举/遍历生成的索引（如 cube-scan-*.json、按自增 id 扫描出来的台账 customid 清单 / 人员 userid 表 / 流程 requestid 表 / 台账 billid 表）只能用于排查/审计，禁止作为「名称 → customid」的查找依据，也禁止据其批量取数。唯一合法的台账缓存是 ~/.e9/cube_catalog_<envkey>.json（由 CLI 正常发现路径生成，带 source/fetchedAt/TTL、按环境隔离）。发现源失效时，正确做法是：让用户提供台账页 URL 里的 customid，或走门户菜单 / 建模管理端接口（getModeList，需管理权限）——不得回退到枚举产物。
• 身份查看（e9 whoami）：查看当前登录人（userid/用户名/部门/分部/岗位/是否系统管理员）。管理员判定走 GET /api/ec/dev/app/getUserInfo 的 isAdmin 字段（isAdmin:true = 系统管理员）；token 通道取不到 isAdmin 时自动强制 cookie 头重发逃生，仍取不到则显示「⚠ 无法确认」，绝不臆断。⚠ 管理员状态只用于身份展示，不是越权豁免——系统管理员不得以此查询授权范围外的他人数据（如需办理越权范围业务，改由 OA 侧有权限的上级/本人操作）；本地 fail-closed 边界（本人 + 全部层级下属）仅在 E9_SCOPE_ENFORCE=1 时拦截。
• 匹配不确定：文档/表格自动填表时，匹配不确定的字段标注 【待确认】，必须由用户确认后再提交。
• 结果回执：requestid + 简短确认（不重列表格）。
• 列表超链接（统一机制）：所有 list/search 类命令的每条标题/内容都做成 markdown 超链接 [文本](URL)，必须原样渲染成超链接，严禁把标题退化成纯文本——无论用列表还是表格展示，标题/名称单元格都要保持 [文本](URL) 形式（表格单元格内同样写 [文本](URL)，不得为凑表格而丢弃 URL、只留纯文本）。文本和 --json 必须共用 CLI 返回的链接对象；JSON 保留 id/title/url/urlType/urlUnavailableReason，AI 不得自行拼 URL。create-empty 表示只打开空白新建页，list-generic 表示只能打开通用列表页，不能声称已经预填或精准定位。标题特殊字符自动转义：链接文本中的 [ ] ( ) 由 CLI 的 escapeLinkText 按 CommonMark 规范自动反斜杠转义——待办/公文标题是服务端渲染的 requestnamespan（如 [退回]【普通】【通知】人事任命通知），自带方括号未转义时会被解析器误判为链接文本提前闭合、导致链接只包住部分标题甚至失效；转义只作用于 markdown 源码，渲染后仍显示原字符，--json 的 title 保持原始值不变——AI 若据 --json 的原始 title + url 组织展示链接，链接文本中的 [ ] ( ) 必须按与 CLI 相同规则转义（等价于 escapeLinkText），不得直接套用未转义的原始 title，否则方括号标题会在第一个 ] 提前闭合、导致链接只包住部分标题甚至失效。
  • todo list/done/mine、odoc todo：buildRequestFormUrl(baseUrl, requestId) → workflow 表单详情页 ✅ verified。
  • create list、odoc create-list：buildCreateWfUrl(baseUrl, workflowid) → 流程发起表单页（iscreate=1）✅ verified。
  • cube list、cube excel：/spa/cube/index.html#/main/cube/card?modeId&formId&billid&customid&type=0 → 台账卡片页 ✅ verified。
  • email list：/spa/email/static/index.html#/main/email/view?id=<id>&title=查看邮件 ✅ verified（SPA bundle 实证 viewMail() 内部跳 main/email/view?id=<mailid>&title=<主题>；路由表无 viewMail，旧地址会白屏）。
  • blog list、blog search：/wui/index.html#/main/blog/myBlog?menuIds=392,393&menuPathIds=392,393 ✅ 已按抓包校准；不再输出会在目标部署 404 的 JSP 链接。
  • workplan list/search/my-calendar/attention：/spa/workplan/static/index.html#/main/wp/myWorkPlan → 日程列表页（查看日程是 modal 弹窗，无独立 view URL）。
  • hrm search、subordinate list、blog at-list：buildHrmCardUrl(baseUrl, id) → /spa/hrm/index_mobx.html#/main/hrm/card/cardInfo/<hrmresource.id> → 人事详情卡片页 ✅ verified（真机验证通过）。凡列表中出现人员姓名，一律挂此卡片链接（三处 id 同源 = hrmresource id）。
• 列表分页展示：用户要查看某个列表时，先告诉用户「共 N 条」，再展示本页数据；其余用「还有 N 条，要继续看吗？」提示，不一次性把全部堆出来。翻页必须用 --page N，且保持人类可读输出——不得改用 --json 拿整页数据全量堆给用户（--json 返回整页数据会条数跳变）。每页条数按「服务端是否认 pageSize」分两档，底线：翻页不跳过、不遗漏任何一条数据：
  • 认 pageSize 的（待办/已办/我发起、日程搜索 workplan search、公文待办 odoc todo、台账 cube list、微博 homepage/search/visitors）：显式传 pageSize=10（visitors 为 5），--page 2 即第 11~20 条，连续不跳号。
  • 不认 pageSize 的（服务端固定每页条数，实抓包验证：邮件 allList 固定 14 条/页、微博 getMyBlogList 固定 20 条/页、cube excel 的 getDataAndTime 固定 10 条/页、人事搜索 hrm search 固定 100 条/页，传 10/5 均被无视）→ 跟随服务端默认，直读服务端页：--page N 即服务端第 N 页，按服务端固定条数连续不跳号、不跳数据；页头标注「每页 X 条」。微博 getMyBlogList 响应无 total 且越界页会被服务端重复回放同页内容（翻到与上页重复即已到末尾）；blog check/reply 逐页拉取 + 重复检测终止以覆盖当天全部记录。
• --json 通用字段语义（各 list/search 命令的 total/count/page 含义一致，勿误读）：
  • total = 当前条件下总记录数（来自 table/counts 等总数接口的 count）。不是页数。
  • count = 本页实际返回条数（= items.length，通常 ≤ pageSize）。
  • page = 当前页码（1 起）。总页数 = ceil(total / pageSize)；CLI 不直接输出总页数，用 --page 逐页拉，遇 count < pageSize 或空即到末尾。
• 回复风格：面向普通办公用户，少用技术术语——不提 token、API、dry-run、JSON、子命令等词；结果用大白话加表格。dry-run / –yes 等机制由 CLI 在后台完成，对用户只讲「先预览、你确认后我提交」——操作前用「先给你看一下要办的内容，确认无误我再办」，确认后提交用「跟您再次确认无误后 → 提交」，不强调技术细节。