一句笼统的“直接做”可作为整条流程的预授权,让线上环境变量写入和协作者权限变更加 --yes
原文依据:4 处文档规定:用户说过“别问 / 直接做 / 自己定”或“做完部署上线给我”,就视为对整个流程预授权,不再逐步确认(line 160)。在这个规则下,设置 online 环境变量时只要用户说过“确认/直接执行”,就直接带 --yes 且“不要再次要求确认”(line 64);成员增删改与协作策略设置也因“对整条流程明确预授权”而直接执行 --yes(line 72)。而明确排除在预授权之外的只有删数据/不可逆 DB 操作、+role-delete、批量移除成员和 +cache-clear(line 161),线上环境变量写入和单个成员的权限变更不在排除项内。
用户一句“直接做”之后,agent 可能未经逐项确认就改动线上应用的生产配置/密钥,或给某人编辑权限、移除某人的编辑权限。这类改动在回复里通常只显示 key/env 或成员类型,用户不容易在事后发现被改了哪一项;被加权限的人可以继续读取和修改该应用及其数据。
文档确实把“别问 / 直接做 / 自己定 / 做完部署上线给我”定义为整条流程的预授权,据此可一路按默认执行、不再逐步确认(line 160);设置 online 环境变量时,只要用户说过“确认/直接执行”就直接加 `--yes` 且“不要再次要求确认”(line 64);单个成员的增删改与协作策略设置也因“对整条流程明确预授权”而可直接加 `--yes`(line 72)。不可豁免清单只覆盖删数据/不可逆 DB、`+role-delete`、批量移除成员、html 体积超限和 `+cache-clear`(line 161),恰好不覆盖线上环境变量写入和单成员权限变更。因此用户早前一句笼统的“直接做”,可能被延用到影响生产配置与协作者权限的写操作上。缓解措施存在:成员写操作仍需先 `--dry-run`,环境变量只在针对 online 且明确确认时才带 `--yes`,值不回显。用户可请作者把线上环境变量写入与协作者权限变更也列入不可预授权清单,并要求每次执行前列出 app/env/key 或目标成员。
- **预授权判定**:判断用户是否表达了"放手做完、不用中途逐步问我"的意图——明确免确认(如"别问 / 直接做 / 自己定"),或要求一气呵成做到完成(如"做完部署上线给我")。是 → 整个流程按合理默认往下走、不再逐步确认(含 clone 到派生目录、发布等);否 → 缺失参数(如目录)该问就问、高影响动作先确认。- **禁止预授权判定底线**(即便已预授权也不豁免):① 会删/丢数据或不可逆的 DB 操作(判据见 [`lark-apps-db-execute.md`](references/lark-apps-db-execute.md))先 `--dry-run` 确认;② `+role-delete`、`+role-member-remove --all`、批量移除成员必须先确认 app、role、成员范围和后果,不能从泛化"直接做"推导出 `--yes`;命令式"删除/移除某对象"只确定操作目标,不等于用户已确认不可逆后果,未明确确认时应在说明影响后停下请求确认;③ `+html-publish` 体积超限时(判据见 [`lark-apps-html-publish.md`](references/lark-apps-html-publish.md)),立即停止并转述超限项;④ `+cache-clear` 会清空整个环境的缓存,「用户让我清缓存」只确定了操作目标、不等于确认了这次清空——未拿到对「清空该环境」的明确确认表述时,只出 `--dry-run` 预览或停下请求确认,不得首次调用即自带 `--yes`(判据表见 [`lark-apps-cache.md`](references/lark-apps-cache.md))。查看另外 3 个位置
- **PV/UV/访问量/活跃用户**:先解析 `app_id`,再用 `+analytics-list`,不要误用 `+metric-list`。- **设置环境变量**:如果用户只给应用名,仍先 `+list --keyword` 解析 app_id;设置 online 环境且用户已经明确说“确认/直接执行”时,调用 `+env-set --environment online ... --yes`,不要再次要求确认。回复和日志摘要里只提 key / env / app,不回显真实 value;需要传复杂值时优先用 `@file` 或 stdin。- **删除环境变量**:`+env-delete` 是破坏性操作。除非用户在同一轮已经明确确认删除这个 app/env/key,否则先向用户确认应用、环境、key 和删除后果;确认后再加 `--yes`。不要因为认证失败/重登完成就自动继续删除,必须保留确认门槛。- `+member-list`、`+member-settings-get` 是只读命令,需要 `spark:app:read`。- `+member-add`、`+member-update`、`+member-remove`、`+member-settings-set` 是高风险写命令,需要 `spark:app:write`。先用 `--dry-run` 核对目标、URL 和请求体;dry-run 不需要 `--yes`。用户已确认具体应用、成员/设置及影响,或已按下方「高影响动作:确认与预授权」对整条流程明确预授权时,真实执行加 `--yes`;否则在 dry-run 后停下请求确认。批量移除成员仍执行「禁止预授权判定底线」,不能从泛化的“直接做”推导出 `--yes`。- 添加、更新、移除成员时必须显式提供匹配的外部 ID 类型,禁止传内部数字 ID、猜测类型或做隐式转换:用户 `--member-type openid --member-id ou_...`;群组 `--member-type openchat --member-id oc_...`;部门 `--member-type opendepartmentid --member-id od-...`。- **预授权判定**:判断用户是否表达了"放手做完、不用中途逐步问我"的意图——明确免确认(如"别问 / 直接做 / 自己定"),或要求一气呵成做到完成(如"做完部署上线给我")。是 → 整个流程按合理默认往下走、不再逐步确认(含 clone 到派生目录、发布等);否 → 缺失参数(如目录)该问就问、高影响动作先确认。- **禁止预授权判定底线**(即便已预授权也不豁免):① 会删/丢数据或不可逆的 DB 操作(判据见 [`lark-apps-db-execute.md`](references/lark-apps-db-execute.md))先 `--dry-run` 确认;② `+role-delete`、`+role-member-remove --all`、批量移除成员必须先确认 app、role、成员范围和后果,不能从泛化"直接做"推导出 `--yes`;命令式"删除/移除某对象"只确定操作目标,不等于用户已确认不可逆后果,未明确确认时应在说明影响后停下请求确认;③ `+html-publish` 体积超限时(判据见 [`lark-apps-html-publish.md`](references/lark-apps-html-publish.md)),立即停止并转述超限项;④ `+cache-clear` 会清空整个环境的缓存,「用户让我清缓存」只确定了操作目标、不等于确认了这次清空——未拿到对「清空该环境」的明确确认表述时,只出 `--dry-run` 预览或停下请求确认,不得首次调用即自带 `--yes`(判据表见 [`lark-apps-cache.md`](references/lark-apps-cache.md))。