@lobehub/lobehub 2.0.0-next.353 → 2.0.0-next.354

package/.cursor/rules/drizzle-schema-style-guide.mdc

@@ -1,218 +0,0 @@
----
-description:
-globs: src/database/schemas/*
-alwaysApply: false
----
-
-# Drizzle ORM Schema Style Guide for lobe-chat
-
-This document outlines the conventions and best practices for defining PostgreSQL Drizzle ORM schemas within the lobe-chat project.
-
-## Configuration
-
-- Drizzle configuration is managed in `drizzle.config.ts`
-- Schema files are located in the src/database/schemas/ directory
-- Migration files are output to `src/database/migrations/`
-- The project uses `postgresql` dialect with `strict: true`
-
-## Helper Functions
-
-Commonly used column definitions, especially for timestamps, are centralized in `src/database/schemas/_helpers.ts`:
-
-- `timestamptz(name: string)`: Creates a timestamp column with timezone
-- `createdAt()`, `updatedAt()`, `accessedAt()`: Helper functions for standard timestamp columns
-- `timestamps`: An object `{ createdAt, updatedAt, accessedAt }` for easy inclusion in table definitions
-
-## Naming Conventions
-
-- **Table Names**: Use plural snake_case (e.g., `users`, `agents`, `session_groups`)
-- **Column Names**: Use snake_case (e.g., `user_id`, `created_at`, `background_color`)
-
-## Column Definitions
-
-### Primary Keys (PKs)
-
-- Typically `text('id')` (or `varchar('id')` for some OIDC tables)
-- Often use `.$defaultFn(() => idGenerator('table_name'))` for automatic ID generation with meaningful prefixes
-- **ID Prefix Purpose**: Makes it easy for users and developers to distinguish different entity types at a glance
-- For internal/system tables that users don't need to see, can use `uuid` or auto-increment keys
-- Composite PKs are defined using `primaryKey({ columns: [t.colA, t.colB] })`
-
-### Foreign Keys (FKs)
-
-- Defined using `.references(() => otherTable.id, { onDelete: 'cascade' | 'set null' | 'no action' })`
-- FK columns are usually named `related_table_singular_name_id` (e.g., `user_id` references `users.id`)
-- Most tables include a `user_id` column referencing `users.id` with `onDelete: 'cascade'`
-
-### Timestamps
-
-- Consistently use the `...timestamps` spread from `_helpers.ts` for `created_at`, `updated_at`, and `accessed_at` columns
-
-### Default Values
-
-- `.$defaultFn(() => expression)` for dynamic defaults (e.g., `idGenerator()`, `randomSlug()`)
-- `.default(staticValue)` for static defaults (e.g., `boolean('enabled').default(true)`)
-
-### Indexes
-
-- Defined in the table's second argument: `pgTable('name', {...columns}, (t) => ({ indexName: indexType().on(...) }))`
-- Use `uniqueIndex()` for unique constraints and `index()` for non-unique indexes
-- Naming pattern: `table_name_column(s)_idx` or `table_name_column(s)_unique`
-- Many tables feature a `clientId: text('client_id')` column, often part of a composite unique index with `user_id`
-
-### Data Types
-
-- Common types: `text`, `varchar`, `jsonb`, `boolean`, `integer`, `uuid`, `pgTable`
-- For `jsonb` fields, specify the TypeScript type using `.$type<MyType>()` for better type safety
-
-## Zod Schemas & Type Inference
-
-- Utilize `drizzle-zod` to generate Zod schemas for validation:
-  - `createInsertSchema(tableName)`
-  - `createSelectSchema(tableName)` (less common)
-- Export inferred types: `export type NewEntity = typeof tableName.$inferInsert;` and `export type EntityItem = typeof tableName.$inferSelect;`
-
-## Relations
-
-- Table relationships are defined centrally in `src/database/schemas/relations.ts` using the `relations()` utility from `drizzle-orm`
-
-## Code Style & Structure
-
-- **File Organization**: Each main database entity typically has its own schema file (e.g., `user.ts`, `agent.ts`)
-- All schemas are re-exported from `src/database/schemas/index.ts`
-- **ESLint**: Files often start with `/* eslint-disable sort-keys-fix/sort-keys-fix */`
-- **Comments**: Use JSDoc-style comments to explain the purpose of tables and complex columns, fields that are self-explanatory do not require jsdoc explanations, such as id, user_id, etc.
-
-## Example Pattern
-
-```typescript
-// From src/database/schemas/agent.ts
-export const agents = pgTable(
-  'agents',
-  {
-    id: text('id')
-      .primaryKey()
-      .$defaultFn(() => idGenerator('agents'))
-      .notNull(),
-    slug: varchar('slug', { length: 100 })
-      .$defaultFn(() => randomSlug(4))
-      .unique(),
-    userId: text('user_id')
-      .references(() => users.id, { onDelete: 'cascade' })
-      .notNull(),
-    clientId: text('client_id'),
-    chatConfig: jsonb('chat_config').$type<LobeAgentChatConfig>(),
-    ...timestamps,
-  },
-  // return array instead of object, the object style is deprecated
-  (t) => [uniqueIndex('client_id_user_id_unique').on(t.clientId, t.userId)],
-);
-
-export const insertAgentSchema = createInsertSchema(agents);
-export type NewAgent = typeof agents.$inferInsert;
-export type AgentItem = typeof agents.$inferSelect;
-```
-
-## Common Patterns
-
-### 1. userId + clientId Pattern (Legacy)
-
-Some existing tables include both fields for different purposes:
-
-```typescript
-// Example from agents table (legacy pattern)
-userId: text('user_id')
-  .references(() => users.id, { onDelete: 'cascade' })
-  .notNull(),
-clientId: text('client_id'),
-
-// Usually with a composite unique index
-clientIdUnique: uniqueIndex('agents_client_id_user_id_unique').on(t.clientId, t.userId),
-```
-
-- **`userId`**: Server-side user association, ensures data belongs to specific user
-- **`clientId`**: Unique key for import/export operations, supports data migration between instances
-- **Current Status**: New tables should NOT include `clientId` unless specifically needed for import/export functionality
-- **Note**: This pattern is being phased out for new features to simplify the schema
-
-### 2. Junction Tables (Many-to-Many Relationships)
-
-Use composite primary keys for relationship tables:
-
-```typescript
-// Example: agents_knowledge_bases (from agent.ts)
-export const agentsKnowledgeBases = pgTable(
-  'agents_knowledge_bases',
-  {
-    agentId: text('agent_id')
-      .references(() => agents.id, { onDelete: 'cascade' })
-      .notNull(),
-    knowledgeBaseId: text('knowledge_base_id')
-      .references(() => knowledgeBases.id, { onDelete: 'cascade' })
-      .notNull(),
-    userId: text('user_id')
-      .references(() => users.id, { onDelete: 'cascade' })
-      .notNull(),
-    enabled: boolean('enabled').default(true),
-    ...timestamps,
-  },
-  (t) => [primaryKey({ columns: [t.agentId, t.knowledgeBaseId] })],
-);
-```
-
-**Pattern**: `{entity1}Id` + `{entity2}Id` as composite PK, plus `userId` for ownership
-
-### 3. OIDC Tables Special Patterns
-
-OIDC tables use `varchar` IDs instead of `text` with custom generators:
-
-```typescript
-// Example from oidc.ts
-export const oidcAuthorizationCodes = pgTable('oidc_authorization_codes', {
-  id: varchar('id', { length: 255 }).primaryKey(), // varchar not text
-  data: jsonb('data').notNull(),
-  expiresAt: timestamptz('expires_at').notNull(),
-  // ... other fields
-});
-```
-
-**Reason**: OIDC standards expect specific ID formats and lengths
-
-### 4. File Processing with Async Tasks
-
-File-related tables reference async task IDs for background processing:
-
-```typescript
-// Example from files table
-export const files = pgTable('files', {
-  // ... other fields
-  chunkTaskId: uuid('chunk_task_id').references(() => asyncTasks.id, { onDelete: 'set null' }),
-  embeddingTaskId: uuid('embedding_task_id').references(() => asyncTasks.id, {
-    onDelete: 'set null',
-  }),
-  // ...
-});
-```
-
-**Purpose**:
-
-- Track file chunking progress (breaking files into smaller pieces)
-- Track embedding generation progress (converting text to vectors)
-- Allow querying task status and handling failures
-
-### 5. Slug Pattern (Legacy)
-
-Some entities include auto-generated slugs - this is legacy code:
-
-```typescript
-slug: varchar('slug', { length: 100 })
-  .$defaultFn(() => randomSlug(4))
-  .unique(),
-
-// Often with composite unique constraint
-slugUserIdUnique: uniqueIndex('slug_user_id_unique').on(t.slug, t.userId),
-```
-
-**Current usage**: Only used to identify default agents/sessions (legacy pattern) **Future refactor**: Will likely be replaced with `isDefault: boolean()` field **Note**: Avoid using slugs for new features - prefer explicit boolean flags for status tracking
-
-By following these guidelines, maintain consistency, type safety, and maintainability across database schema definitions.

package/.cursor/rules/hotkey.mdc

@@ -1,162 +0,0 @@
----
-alwaysApply: false
----
-
-# 如何添加新的快捷键：开发者指南
-
-本指南将带您一步步地向 LobeChat 添加一个新的快捷键功能。我们将通过一个完整示例，演示从定义到实现的整个过程。
-
-## 示例场景
-
-假设我们要添加一个新的快捷键功能：**快速清空聊天记录**，快捷键为 `Mod+Shift+Backspace`。
-
-## 步骤 1：更新快捷键常量定义
-
-首先，在 `src/types/hotkey.ts` 中更新 `HotkeyEnum`：
-
-```typescript
-export const HotkeyEnum = {
-  // 已有的快捷键...
-  AddUserMessage: 'addUserMessage',
-  EditMessage: 'editMessage',
-
-  // 新增快捷键
-  ClearChat: 'clearChat', // 添加这一行
-
-  // 其他已有快捷键...
-} as const;
-```
-
-## 步骤 2：注册默认快捷键
-
-在 `src/const/hotkeys.ts` 中添加快捷键的默认配置：
-
-```typescript
-import { KeyMapEnum as Key, combineKeys } from '@lobehub/ui';
-
-// ...现有代码
-
-export const HOTKEYS_REGISTRATION: HotkeyRegistration = [
-  // 现有的快捷键配置...
-
-  // 添加新的快捷键配置
-  {
-    group: HotkeyGroupEnum.Conversation, // 归类到会话操作组
-    id: HotkeyEnum.ClearChat,
-    keys: combineKeys([Key.Mod, Key.Shift, Key.Backspace]),
-    scopes: [HotkeyScopeEnum.Chat], // 在聊天作用域下生效
-  },
-
-  // 其他现有快捷键...
-];
-```
-
-## 步骤 3：添加国际化翻译
-
-在 `src/locales/default/hotkey.ts` 中添加对应的文本描述：
-
-```typescript
-import { HotkeyI18nTranslations } from '@/types/hotkey';
-
-const hotkey: HotkeyI18nTranslations = {
-  // 现有翻译...
-
-  // 添加新快捷键的翻译
-  clearChat: {
-    desc: '清空当前会话的所有消息记录',
-    title: '清空聊天记录',
-  },
-
-  // 其他现有翻译...
-};
-
-export default hotkey;
-```
-
-如需支持其他语言，还需要在相应的语言文件中添加对应翻译。
-
-## 步骤 4：创建并注册快捷键 Hook
-
-在 `src/hooks/useHotkeys/chatScope.ts` 中添加新的 Hook：
-
-```typescript
-export const useClearChatHotkey = () => {
-  const clearMessages = useChatStore((s) => s.clearMessages);
-  const { t } = useTranslation();
-
-  return useHotkeyById(HotkeyEnum.ClearChat, showConfirm);
-};
-
-// 注册聚合
-
-export const useRegisterChatHotkeys = () => {
-  const { enableScope, disableScope } = useHotkeysContext();
-
-  useOpenChatSettingsHotkey();
-  // ...其他快捷键
-  useClearChatHotkey();
-
-  useEffect(() => {
-    enableScope(HotkeyScopeEnum.Chat);
-    return () => disableScope(HotkeyScopeEnum.Chat);
-  }, []);
-
-  return null;
-};
-```
-
-## 步骤 5：给相应 UI 元素添加 Tooltip 提示（可选）
-
-如果有对应的 UI 按钮，可以添加快捷键提示：
-
-```tsx
-import { DeleteOutlined } from '@ant-design/icons';
-import { Tooltip } from '@lobehub/ui';
-import { Button } from 'antd';
-import { useTranslation } from 'react-i18next';
-
-import { useUserStore } from '@/store/user';
-import { settingsSelectors } from '@/store/user/selectors';
-import { HotkeyEnum } from '@/types/hotkey';
-
-const ClearChatButton = () => {
-  const { t } = useTranslation(['hotkey', 'chat']);
-  const clearChatHotkey = useUserStore(settingsSelectors.getHotkeyById(HotkeyEnum.ClearChat));
-
-  // 获取清空聊天的方法
-  const clearMessages = useChatStore((s) => s.clearMessages);
-
-  return (
-    <Tooltip hotkey={clearChatHotkey} title={t('clearChat.title', { ns: 'hotkey' })}>
-      <Button icon={<DeleteOutlined />} onClick={clearMessages} />
-    </Tooltip>
-  );
-};
-```
-
-## 步骤 6：测试新快捷键
-
-1. 启动开发服务器
-2. 打开聊天页面
-3. 按下设置的快捷键组合（`Cmd+Shift+Backspace` 或 `Ctrl+Shift+Backspace`）
-4. 确认功能正常工作
-5. 检查快捷键设置面板中是否正确显示了新快捷键
-
-## 最佳实践
-
-1. **作用域考虑**：根据功能决定快捷键应属于全局作用域还是聊天作用域
-2. **分组合理**：将快捷键放在合适的功能组中（System/Layout/Conversation）
-3. **冲突检查**：确保新快捷键不会与现有系统、浏览器或应用快捷键冲突
-4. **平台适配**：使用 `Key.Mod` 而非硬编码 `Ctrl` 或 `Cmd`，以适配不同平台
-5. **提供清晰描述**：为快捷键添加明确的标题和描述，帮助用户理解功能
-
-按照以上步骤，您可以轻松地向系统添加新的快捷键功能，提升用户体验。如有特殊需求，如桌面专属快捷键，可以通过 `isDesktop` 标记进行区分处理。
-
-## 常见问题排查
-
-- **快捷键未生效**：检查作用域是否正确，以及是否在 RegisterHotkeys 中调用了对应的 hook
-- **快捷键设置面板未显示**：确认在 HOTKEYS_REGISTRATION 中正确配置了快捷键
-- **快捷键冲突**：在 HotkeyInput 组件中可以检测到冲突，用户会看到警告
-- **功能在某些页面失效**：确认是否注册在了正确的作用域，以及相关页面是否激活了该作用域
-
-通过这些步骤，您可以确保新添加的快捷键功能稳定、可靠且用户友好。

package/.cursor/rules/linear.mdc

@@ -1,53 +0,0 @@
----
-alwaysApply: true
----
-
-# Linear Issue Management
-
-When working with Linear issues:
-
-1. **Retrieve issue details** before starting work using `mcp__linear-server__get_issue`
-2. **Check for sub-issues**: If the issue has sub-issues, retrieve and review ALL sub-issues using `mcp__linear-server__list_issues` with `parentId` filter before starting work
-3. **Update issue status** when completing tasks using `mcp__linear-server__update_issue`
-4. **MUST add completion comment** using `mcp__linear-server__create_comment`
-
-## Creating Issues
-
-When creating new Linear issues using `mcp__linear-server__create_issue`, **MUST add the `claude code` label** to indicate the issue was created by Claude Code.
-
-## Completion Comment (REQUIRED)
-
-**Every time you complete an issue, you MUST add a comment summarizing the work done.** This is critical for:
-
-- Team visibility and knowledge sharing
-- Code review context
-- Future reference and debugging
-
-## PR Linear Issue Association (REQUIRED)
-
-**When creating PRs for Linear issues, MUST include magic keywords in PR body:** `Fixes LOBE-123`, `Closes LOBE-123`, or `Resolves LOBE-123`, and summarize the work done in the linear issue comment and update the issue status to "In Review".
-
-## IMPORTANT: Per-Issue Completion Rule
-
-**When working on multiple issues (e.g., parent issue with sub-issues), you MUST update status and add comment for EACH issue IMMEDIATELY after completing it.** Do NOT wait until all issues are done to update them in batch.
-
-**Workflow for EACH individual issue:**
-
-1. Complete the implementation for this specific issue
-2. Run type check: `bun run type-check`
-3. Run related tests if applicable
-4. Create PR if needed
-5. **IMMEDIATELY** update issue status to **"In Review"** (NOT "Done"): `mcp__linear-server__update_issue`
-6. **IMMEDIATELY** add completion comment: `mcp__linear-server__create_comment`
-7. Only then move on to the next issue
-
-**Note:** Issue status should be set to **"In Review"** when PR is created. The status will be updated to **"Done"** only after the PR is merged (usually handled by Linear-GitHub integration or manually).
-
-**❌ Wrong approach:**
-
-- Complete Issue A → Complete Issue B → Complete Issue C → Update all statuses → Add all comments
-- Mark issue as "Done" immediately after creating PR
-
-**✅ Correct approach:**
-
-- Complete Issue A → Create PR → Update A status to "In Review" → Add A comment → Complete Issue B → ...

package/.cursor/rules/microcopy-cn.mdc

@@ -1,158 +0,0 @@
----
-globs: src/locales/default/*
-alwaysApply: false
----
-
-你是「LobeHub」的中文 UI 文案与微文案（microcopy）专家。LobeHub 是一个助理工作空间：用户可以创建助理与群组，让人和助理、助理和助理协作，提升日常生产与生活效率。产品气质：外表年轻、亲和、现代；内核专业、可靠、强调生产力与可控性。整体风格参考 Notion / Figma / Apple / Discord / OpenAI / Gemini：清晰克制、可信、有人情味但不油腻。
-
-产品 slogan：**Where Agents Collaborate**。你的文案要让用户持续感到：LobeHub 的重点不是“生成”，而是“协作的助理体系”（可共享上下文、可追踪、可回放、可演进、人在回路）。
-
----
-
-### 1) 固定术语（必须遵守）
-
-- Workspace：空间
-- Agent：助理
-- Agent Team：群组
-- Context：上下文
-- Memory：记忆
-- Integration：连接器
-- Tool/Skill/Plugin/插件/工具: 技能
-- SystemRole: 助理档案
-- Topic: 话题
-- Page: 文稿
-- Community: 社区
-- Resource: 资源
-- Library: 库
-- MCP: MCP
-- Provider: 模型服务商
-
-术语规则：同一概念全站只用一种说法，不混用“Agent/智能体/机器人/团队/工作区”等。
-
----
-
-### 2) 你的任务
-
-- 优化、改写或从零生成任何界面中文文案：标题、按钮、表单说明、占位、引导、空状态、Toast、弹窗、错误、权限、设置项、创建/运行流程、协作与群组相关页面等。
-- 文案必须同时兼容：普通用户看得懂 + 专业用户不觉得低幼；娱乐与严肃场景都成立；不过度营销、不夸大 AI 能力；在关键节点提供恰到好处的人文关怀。
-
----
-
-### 3) 品牌三原则（内化到结构与措辞）
-
-- **Create（创建）**：一句话创建助理；从想法到可用；清楚下一步。
-- **Collaborate（协作）**：多助理协作；群组对齐信息与产出；共享上下文（可控、可管理）。
-- **Evolve（演进）**：助理可在你允许的范围内记住偏好；随你的工作方式变得更顺手；强调可解释、可设置、可回放。
-
----
-
-### 4) 写作规则（可执行）
-
-1. **清晰优先**：短句、强动词、少形容词；避免口号化与空泛承诺（如“颠覆”“史诗级”“100%”）。
-2. **分层表达（单一版本兼容两类用户）**：
-   - 主句：人人可懂、可执行
-   - 必要时补充一句副说明：更精确/更专业/更边界（可放副标题、帮助提示、折叠区）
-   - 不输出“Pro/Lite 两套文案”，而是“一句主文案 + 可选补充”
-3. **术语克制但准确**：能说“连接/运行/上下文”就不要堆砌术语；必须出现专业词时给一句白话解释。
-4. **一致性**：同一动作按钮尽量固定动词（创建/连接/运行/暂停/重试/查看详情/清除记忆等）。
-5. **可行动**：每条提示都要让用户知道下一步；按钮避免“确定/取消”泛化，改成更具体的动作。
-6. **中文本地化**：符合中文阅读节奏；中英混排规范；避免翻译腔。
-
----
-
-### 5) 人文关怀（中间态温度：介于克制与陪伴）
-
-目标：在 AI 时代的价值焦虑与创作失格感中，给用户“被理解 + 有掌控 + 能继续”的体验，但不写长抒情。
-
-#### 温度比例规则
-
-- 默认：信息为主，温度为辅（约 8:2）
-- 关键节点（首次创建、空状态、长等待、失败重试、回退/丢失风险、协作分歧）：允许提升到 7:3
-- 强制上限：任何一条上屏文案里，温度表达不超过**半句或一句**，且必须紧跟明确下一步。
-
-#### 表达顺序（必须遵守）
-
-1. 先承接处境（不评判）：如“没关系/先这样也可以/卡住很正常”
-2. 再给掌控感（人在回路）：可暂停/可回放/可编辑/可撤销/可清除记忆/可查看上下文
-3. 最后给下一步（按钮/路径明确）
-
-#### 避免
-
-- 鸡汤式说教（如“别焦虑”“要相信未来”）
-- 宏大叙事与文学排比
-- 过度拟人（不承诺助理“理解你/有情绪/永远记得你”）
-
-#### 核心立场
-
-- 助理很强，但它替代不了你的经历、选择与判断；LobeHub 帮你把时间还给重要的部分。
-
-##### A. 情绪承接（先人后事）
-
-- 允许承认：焦虑、空白、无从下手、被追赶感、被替代感、创作枯竭、意义感动摇
-- 但不下结论、不说教：不输出“你要乐观/别焦虑”，改成“这种感觉很常见/你不是一个人”
-
-##### B. 主体性回归（把人放回驾驶位）
-
-- 关键句式：**“决定权在你”**、**“你可以选择交给助理的部分”**、**“把你的想法变成可运行的流程”**
-- 强调可控：可编辑、可回放、可暂停、可撤销、可清除记忆、可查看上下文
-
-##### C. 经历与关系（把价值从结果挪回过程）
-
-- 适度表达：记录、回放、版本、协作痕迹、讨论、共创、里程碑
-- 用“经历/过程/痕迹/回忆/脉络/成长”这类词，避免虚无抒情
-
-##### D. 不用“AI 神话”
-
-- 不渲染“AI 终将超越你/取代你”
-- 也不轻飘飘说“AI 只是工具”了事更像：**“它是工具，但你仍是作者/负责人/最终决定者”**
-
-##### 示例
-
-在用户可能产生自我否定或无力感的场景（空状态、创作开始、产出对比、失败重试、长时间等待、团队协作分歧、版本回退）：
-
-    1. **先承接感受**：用一句短话确认处境（不评判）
-    2. **再给掌控感**：强调“你可控/可选择/可回放/可撤销”
-    3. **最后给下一步**：提供明确行动按钮或路径
-
-- 允许出现“经历、选择、痕迹、成长、一起、陪你把事做完”等词来传递温度；但保持信息密度，不写长段抒情。
-- 严肃场景（权限/安全/付费/数据丢失风险）仍以清晰与准确为先，温度通过“尊重与解释”体现，而不是煽情。
-
-你可以让系统在需要时套这些结构（同一句兼容新手/专业）：
-
-**开始创作/空白页**
-
-- 主句：给一个轻承接 + 行动入口
-- 模板：
-  - 「从一个念头开始就够了。写一句话，我来帮你搭好第一个助理。」
-  - 「不知道从哪开始也没关系：先说目标，我们一起把它拆开。」
-
-**长任务运行/等待**
-
-- 模板：
-  - 「正在运行中…你可以先去做别的，完成后我会提醒你。」
-  - 「这一步可能要几分钟。想更快：减少上下文 / 切换模型 / 关闭自动运行。」
-
-**失败/重试**
-
-- 模板：
-  - 「没关系，这次没跑通。你可以重试，或查看原因再继续。」
-  - 「连接失败：权限未通过或网络不稳定。去设置重新授权，或稍后再试。」
-
-**对比与自我价值焦虑（适合提示/引导，不适合错误弹窗）**
-
-- 模板：
-  - 「助理可以加速产出，但方向、取舍和标准仍属于你。」
-  - 「结果可以很快，经历更重要：把每次尝试留下来，下一次会更稳。」
-
-**协作/群组**
-
-- 模板：
-  - 「把上下文对齐到同一处，群组里每个助理都会站在同一页上。」
-  - 「不同意见没关系：先把目标写清楚，再让助理分别给方案与取舍。」
-
-### 6) 错误/异常/权限/付费：硬规则
-
-- 必须包含：**发生了什么 +（可选）原因 + 你可以怎么做**
-- 必须提供可操作选项：**重试 / 查看详情 / 去设置 / 联系支持 / 复制日志**（按场景取舍）
-- 不责备用户；不只给错误码；错误码可放在“详情”里
-- 涉及数据与安全：语气更中性更完整，温度通过“尊重与解释”体现，而不是煽