moai-core-ask-user-questions

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Enterprise Interactive Survey Orchestrator

企业级交互式调研编排器

Skill Metadata

技能元数据

FieldValue
Skill Namemoai-core-ask-user-questions
Version4.0.0 Enterprise (2025-11-18)
Core Tool
AskUserQuestion
(Claude Code built-in)
Auto-loadWhen Alfred detects ambiguity in requests
TierAlfred (Workflow Orchestration)
Allowed toolsAskUserQuestion
Lines of Content850+, with 10+ production examples
Progressive Disclosure3-level (quick-reference, patterns, advanced)

字段
技能名称moai-core-ask-user-questions
版本4.0.0 企业版 (2025-11-18)
核心工具
AskUserQuestion
(Claude Code 内置)
自动加载时机当Alfred检测到请求存在歧义时
层级Alfred (工作流编排层)
允许使用的工具AskUserQuestion
内容行数850+,包含10+生产环境示例
渐进式披露三级(快速参考、模式、高级)

🚀 What It Does (Enterprise Context)

🚀 功能介绍(企业场景)

Purpose: Empower Alfred sub-agents to actively conduct enterprise-grade surveys for requirement clarification, architectural decisions, and complex decision automation.
Leverages Claude Code's native
AskUserQuestion
tool to collect explicit, structured user input that transforms vague requests into precise specifications with guaranteed UX quality across all models.
Enterprise Capabilities:
  • ✅ Single-select & multi-select option types (independent or dependent)
  • ✅ 1-4 questions per survey (cognitive load optimization)
  • ✅ 2-4 options per question with trade-off analysis
  • ✅ Automatic "Other" option for custom input validation
  • ✅ Conditional branching based on user answers
  • ✅ Error recovery and retry logic
  • ✅ Integration across all Alfred commands (Plan/Run/Sync)
  • ✅ Multi-language support (user's configured language)
  • ✅ Accessibility-first TUI design
  • ✅ Reduces ambiguity → single interaction vs 3-5 iterations

用途:赋能Alfred子Agent主动开展企业级调研,用于需求澄清、架构决策和复杂决策自动化。
依托Claude Code原生的
AskUserQuestion
工具收集明确、结构化的用户输入,将模糊的请求转化为精确的需求规格,在所有模型中保证一致的用户体验质量。
企业级能力:
  • ✅ 单选 & 多选选项类型(独立或联动)
  • ✅ 每份调研最多1-4个问题(认知负载优化)
  • ✅ 每个问题2-4个选项,附带利弊分析
  • ✅ 自动提供「其他」选项支持自定义输入校验
  • ✅ 基于用户答案的条件分支
  • ✅ 错误恢复与重试逻辑
  • ✅ 集成所有Alfred命令(Plan/Run/Sync)
  • ✅ 多语言支持(匹配用户配置的语言)
  • ✅ 无障碍优先的TUI设计
  • ✅ 减少歧义:单次交互即可完成原本3-5次迭代的沟通

🎯 When to Use (Decision Framework)

🎯 使用场景(决策框架)

✅ MANDATORY ASK when user intent is ambiguous:

✅ 当用户意图不明确时必须询问:

  1. Vague noun phrases: "Add dashboard", "Refactor auth", "Improve performance"
    • Missing concrete specification or scope
  2. Missing scope definition: No specification of WHERE, WHO, WHAT, HOW, WHEN
    • Could affect 5+ files or multiple modules
  3. Multiple valid paths: ≥2 reasonable implementation approaches
    • Different trade-offs (speed vs quality, simple vs comprehensive)
  4. Trade-off decisions: Performance vs reliability, cost vs features
    • No single objectively best answer
  5. Risky operations: Destructive actions (delete, migrate, reset)
    • Explicit informed consent required
  6. Architectural decisions: Technology selection, API design, database choice
    • Long-term impact requires clarification
  1. 模糊名词短语: 「添加仪表盘」、「重构认证模块」、「提升性能」
    • 缺少具体的规格说明或范围边界
  2. 范围定义缺失: 没有明确说明地点、对象、内容、方式、时间
    • 可能影响5个以上文件或多个模块
  3. 多个可行路径: 存在≥2种合理的实现方案
    • 不同方案有不同权衡(速度vs质量、简单vs全面)
  4. 权衡决策: 性能vs可靠性、成本vs功能
    • 没有唯一的客观最优解
  5. 风险操作: 破坏性操作(删除、迁移、重置)
    • 需要用户明确的知情同意
  6. 架构决策: 技术选型、API设计、数据库选择
    • 长期影响需要明确确认

❌ DON'T ask when:

❌ 以下场景不需要询问:

  • User explicitly specified exact requirements
  • Decision is automatic (no choices, pure routing)
  • Single obvious path exists (no alternatives)
  • Quick yes/no confirmation only (keep it brief)
  • Information already provided in conversation

  • 用户已经明确指定了精确的需求
  • 决策是自动执行的(无选择空间,纯路由逻辑)
  • 只有唯一的明显可行路径(无替代方案)
  • 仅需快速的是/否确认(保持简短即可)
  • 对话中已经提供了相关信息

🎨 Design Principles (Enterprise Standards)

🎨 设计原则(企业标准)

Core Principle: Certainty Over Guessing

核心原则: 确定性优先于猜测

Golden Rule: When in doubt, ask the user instead of assuming.
Why:
  • ✅ User sees exactly what you'll do → no surprises
  • ✅ Single interaction vs 3-5 rounds of back-and-forth
  • ✅ Fast → execute with certainty
  • ✅ Reduces "vibe coding" frustration
  • ✅ Builds trust through transparency
Pattern:
Ambiguous request detected
Call AskUserQuestion({questions: [...]})
User selects from clear options
Proceed with confirmed specifications

黄金法则: 存在疑问时,询问用户而不是自行假设。
原因:
  • ✅ 用户完全清楚你要做什么 → 没有意外
  • ✅ 单次交互即可完成原本3-5轮的来回沟通
  • ✅ 高效:基于确定性结果执行
  • ✅ 减少「凭感觉编码」的挫败感
  • ✅ 通过透明化建立信任
执行模式:
检测到模糊请求
调用AskUserQuestion({questions: [...]})
用户从清晰的选项中选择
基于确认后的规格继续执行

🏗️ Architecture: 3-Level Progressive Disclosure

🏗️ 架构:三级渐进式披露

Level 1: Quick Start (Minimal Invocation)

一级:快速入门(最简调用)

Single-Select Pattern:
typescript
const answer = await AskUserQuestion({
  questions: [
    {
      question: "How should we implement this?",
      header: "Approach",          // max 12 chars
      multiSelect: false,
      options: [
        {
          label: "Option 1",       // 1-5 words
          description: "What it does and why you'd pick it."
        },
        {
          label: "Option 2",
          description: "Alternative with different trade-offs."
        }
      ]
    }
  ]
});

// Returns: { "Approach": "Option 1" }
Multi-Select Pattern (independent features):
typescript
const answer = await AskUserQuestion({
  questions: [
    {
      question: "Which features should we enable?",
      header: "Features",
      multiSelect: true,
      options: [
        { label: "Feature A", description: "..." },
        { label: "Feature B", description: "..." },
        { label: "Feature C", description: "..." }
      ]
    }
  ]
});

// Returns: { "Features": ["Feature A", "Feature C"] }
单选模式:
typescript
const answer = await AskUserQuestion({
  questions: [
    {
      question: "How should we implement this?",
      header: "Approach",          // 最多12个字符
      multiSelect: false,
      options: [
        {
          label: "Option 1",       // 1-5个单词
          description: "What it does and why you'd pick it."
        },
        {
          label: "Option 2",
          description: "Alternative with different trade-offs."
        }
      ]
    }
  ]
});

// 返回: { "Approach": "Option 1" }
多选模式(独立功能选择):
typescript
const answer = await AskUserQuestion({
  questions: [
    {
      question: "Which features should we enable?",
      header: "Features",
      multiSelect: true,
      options: [
        { label: "Feature A", description: "..." },
        { label: "Feature B", description: "..." },
        { label: "Feature C", description: "..." }
      ]
    }
  ]
});

// 返回: { "Features": ["Feature A", "Feature C"] }

Level 2: Enterprise Patterns

二级:企业级模式

Batch Questions (related decisions):
typescript
const answer = await AskUserQuestion({
  questions: [
    {
      question: "Which database technology?",
      header: "Database",
      options: [
        { label: "PostgreSQL", description: "Relational, ACID, mature" },
        { label: "MongoDB", description: "Document, flexible schema" }
      ]
    },
    {
      question: "Cache strategy?",
      header: "Caching",
      options: [
        { label: "Redis", description: "In-memory, fast" },
        { label: "Memcached", description: "Distributed cache" }
      ]
    }
  ]
});
Conditional Flow (dependent decisions):
typescript
let questions = [
  {
    question: "What type of deployment?",
    header: "Deployment Type",
    options: [
      { label: "Docker", description: "Containerized" },
      { label: "Kubernetes", description: "Orchestrated" },
      { label: "Serverless", description: "Functions-as-a-Service" }
    ]
  }
];

const initialAnswer = await AskUserQuestion({ questions });

// Follow-up based on initial choice
if (initialAnswer["Deployment Type"] === "Kubernetes") {
  const kubeAnswer = await AskUserQuestion({
    questions: [
      {
        question: "Which cluster provider?",
        header: "K8s Provider",
        options: [
          { label: "AWS EKS", description: "Amazon Elastic Kubernetes" },
          { label: "GCP GKE", description: "Google Kubernetes Engine" },
          { label: "Self-Managed", description: "On-premises cluster" }
        ]
      }
    ]
  });
}
批量问题(关联决策):
typescript
const answer = await AskUserQuestion({
  questions: [
    {
      question: "Which database technology?",
      header: "Database",
      options: [
        { label: "PostgreSQL", description: "Relational, ACID, mature" },
        { label: "MongoDB", description: "Document, flexible schema" }
      ]
    },
    {
      question: "Cache strategy?",
      header: "Caching",
      options: [
        { label: "Redis", description: "In-memory, fast" },
        { label: "Memcached", description: "Distributed cache" }
      ]
    }
  ]
});
条件流程(依赖决策):
typescript
let questions = [
  {
    question: "What type of deployment?",
    header: "Deployment Type",
    options: [
      { label: "Docker", description: "Containerized" },
      { label: "Kubernetes", description: "Orchestrated" },
      { label: "Serverless", description: "Functions-as-a-Service" }
    ]
  }
];

const initialAnswer = await AskUserQuestion({ questions });

// 基于初始选择跟进提问
if (initialAnswer["Deployment Type"] === "Kubernetes") {
  const kubeAnswer = await AskUserQuestion({
    questions: [
      {
        question: "Which cluster provider?",
        header: "K8s Provider",
        options: [
          { label: "AWS EKS", description: "Amazon Elastic Kubernetes" },
          { label: "GCP GKE", description: "Google Kubernetes Engine" },
          { label: "Self-Managed", description: "On-premises cluster" }
        ]
      }
    ]
  });
}

Level 3: Advanced (Error Handling & Validation)

三级:高级功能(错误处理与校验)

Custom Input Validation ("Other" option):
typescript
const answer = await AskUserQuestion({
  questions: [
    {
      question: "Which framework?",
      header: "Framework",
      options: [
        { label: "React", description: "UI library" },
        { label: "Vue", description: "Progressive framework" },
        { label: "Other", description: "Custom framework or library" }
      ]
    }
  ]
});

// Validate custom input
if (answer["Framework"] === "Other" || 
    !VALID_FRAMEWORKS.includes(answer["Framework"])) {
  const customAnswer = validateCustomInput(answer["Framework"]);
  if (!customAnswer) {
    // Re-ask with guidance
    return retryWithGuidance();
  }
}
Error Recovery:
typescript
try {
  const answer = await AskUserQuestion({...});
} catch (error) {
  if (error.type === "UserCancelled") {
    // User pressed ESC - use default or abort
    return fallbackToDefault();
  } else if (error.type === "InvalidInput") {
    // Validate and retry
    return retryWithValidation();
  }
}
Risky Operation Confirmation:
typescript
const answer = await AskUserQuestion({
  questions: [
    {
      question: "This will DELETE 15 branches and merge to main. Continue?",
      header: "Destructive Op",
      options: [
        {
          label: "Proceed",
          description: "Delete branches (CANNOT BE UNDONE)"
        },
        {
          label: "Dry Run",
          description: "Show what would be deleted"
        },
        {
          label: "Cancel",
          description: "Abort entire process"
        }
      ]
    }
  ]
});

if (answer["Destructive Op"] === "Proceed") {
  // Require additional final confirmation
  const final = await AskUserQuestion({
    questions: [
      {
        question: "Type DELETE to confirm irreversible action:",
        header: "Final Confirmation"
      }
    ]
  });
  
  if (final["Final Confirmation"] === "DELETE") {
    executeDeletion();
  }
}

自定义输入校验(「其他」选项):
typescript
const answer = await AskUserQuestion({
  questions: [
    {
      question: "Which framework?",
      header: "Framework",
      options: [
        { label: "React", description: "UI library" },
        { label: "Vue", description: "Progressive framework" },
        { label: "Other", description: "Custom framework or library" }
      ]
    }
  ]
});

// 校验自定义输入
if (answer["Framework"] === "Other" || 
    !VALID_FRAMEWORKS.includes(answer["Framework"])) {
  const customAnswer = validateCustomInput(answer["Framework"]);
  if (!customAnswer) {
    // 附带引导信息重新询问
    return retryWithGuidance();
  }
}
错误恢复:
typescript
try {
  const answer = await AskUserQuestion({...});
} catch (error) {
  if (error.type === "UserCancelled") {
    // 用户按下ESC - 使用默认值或终止执行
    return fallbackToDefault();
  } else if (error.type === "InvalidInput") {
    // 校验后重试
    return retryWithValidation();
  }
}
风险操作确认:
typescript
const answer = await AskUserQuestion({
  questions: [
    {
      question: "This will DELETE 15 branches and merge to main. Continue?",
      header: "Destructive Op",
      options: [
        {
          label: "Proceed",
          description: "Delete branches (CANNOT BE UNDONE)"
        },
        {
          label: "Dry Run",
          description: "Show what would be deleted"
        },
        {
          label: "Cancel",
          description: "Abort entire process"
        }
      ]
    }
  ]
});

if (answer["Destructive Op"] === "Proceed") {
  // 需要额外的最终确认
  const final = await AskUserQuestion({
    questions: [
      {
        question: "Type DELETE to confirm irreversible action:",
        header: "Final Confirmation"
      }
    ]
  });
  
  if (final["Final Confirmation"] === "DELETE") {
    executeDeletion();
  }
}

📋 Key Constraints (TUI Optimization)

📋 核心约束(TUI优化)

ConstraintReasonExample
1-4 questions maxAvoid user fatigueUse follow-up surveys instead
2-4 options per QPrevent choice overloadAvoid 5+ options (decision paralysis)
Header ≤12 charsTUI layout fit"DB Choice" not "Which Database Technology"
Label 1-5 wordsQuick scanning"PostgreSQL" not "SQL Database by PostgreSQL"
Description requiredEnables informed choiceAlways explain trade-offs
Auto "Other" optionAlways availableSystem adds automatically for custom input
No HTML/markdownPlain text TUIUse formatting sparingly
Language matchingUser experienceAlways match configured conversation_language

约束原因示例
最多1-4个问题避免用户疲劳使用跟进调研替代单份长调研
每个问题2-4个选项防止选择过载避免5个以上选项(导致决策瘫痪)
标题≤12个字符适配TUI布局用「DB Choice」而非「Which Database Technology」
标签1-5个单词便于快速扫描用「PostgreSQL」而非「SQL Database by PostgreSQL」
必须提供描述支持用户做出知情选择始终说明利弊权衡
自动添加「其他」选项始终可用系统自动添加支持自定义输入
不支持HTML/Markdown纯文本TUI尽量少用格式化
语言匹配用户体验始终匹配配置的对话语言

🔄 Integration with Alfred Sub-agents

🔄 与Alfred子Agent的集成

Sub-agentWhen to AskExample TriggerQuestions
spec-builder (
/alfred:1-plan
)
SPEC title vague, scope undefined"Add feature" without specifics"Feature type?", "Scope?", "Users affected?"
tdd-implementer (
/alfred:2-run
)
Implementation approach unclearMultiple valid implementation paths"Architecture?", "Libraries?", "Constraints?"
doc-syncer (
/alfred:3-sync
)
Sync scope unclearFull vs partial sync decision"Full sync?", "Which files?", "Auto-commit?"
qa-validatorReview depth unclearQuick vs comprehensive check"Review level?", "Security focus?", "Performance?"

子Agent询问时机触发示例问题
spec-builder (
/alfred:1-plan
)
需求规格标题模糊、范围未定义没有具体说明的「添加功能」请求「功能类型?」、「范围?」、「影响用户?」
tdd-implementer (
/alfred:2-run
)
实现方案不明确存在多个可行的实现路径「架构方案?」、「依赖库?」、「约束条件?」
doc-syncer (
/alfred:3-sync
)
同步范围不明确全量同步 vs 部分同步的决策「全量同步?」、「同步哪些文件?」、「自动提交?」
qa-validator评审深度不明确快速检查 vs 全面检查的决策「评审级别?」、「安全重点?」、「性能要求?」

🎓 Top 10 Usage Patterns

🎓 十大高频使用模式

Pattern 1: Feature Type Clarification

模式1:功能类型澄清

Trigger: "Add dashboard feature" without specifics
Question: "Which dashboard type: Analytics, Admin, or Profile?"
Outcome: Narrowed scope → faster implementation
触发条件: 没有具体说明的「添加仪表盘功能」请求
问题: 「仪表盘类型:Analytics、Admin还是Profile?」
结果: 缩小范围 → 提升开发效率

Pattern 2: Implementation Approach Selection

模式2:实现方案选择

Trigger: Multiple valid tech choices
Question: "JWT tokens, session-based, or OAuth?"
Outcome: Locked architecture → deterministic development
触发条件: 存在多个可行的技术选择
问题: 「JWT令牌、会话式、还是OAuth?」
结果: 锁定架构 → 确定性开发

Pattern 3: Risky Operation Confirmation

模式3:风险操作确认

Trigger: Destructive action (delete, migrate, reset)
Question: "This will delete X. Proceed?" with retry confirmation
Outcome: Explicit consent + audit trail
触发条件: 破坏性操作(删除、迁移、重置)
问题: 「该操作将删除X,是否继续?」附带重试确认
结果: 明确同意 + 审计痕迹

Pattern 4: Multi-Feature Selection

模式4:多功能选择

Trigger: "Which features to enable?"
Question: Multi-select of independent features
Outcome: Precise feature set → no scope creep
触发条件: 「需要启用哪些功能?」
问题: 独立功能的多选
结果: 精确的功能集合 → 无范围蔓延

Pattern 5: Sequential Conditional Decisions

模式5:顺序条件决策

Trigger: Dependent choices (Q2 depends on Q1)
Question: First survey → follow-up based on answer
Outcome: Progressive narrowing → precise specification
触发条件: 依赖选择(第二个问题依赖第一个问题的答案)
问题: 首次调研 → 基于答案跟进提问
结果: 逐步缩小范围 → 精确的需求规格

Pattern 6: Technology Stack Selection

模式6:技术栈选择

Trigger: "Build with what stack?"
Question: Database, cache, queue, API type
Outcome: Full stack locked → team alignment
触发条件: 「用什么技术栈构建?」
问题: 数据库、缓存、队列、API类型
结果: 锁定完整技术栈 → 团队对齐

Pattern 7: Performance vs Reliability

模式7:性能vs可靠性权衡

Trigger: Trade-off between conflicting goals
Question: "Optimize for speed, reliability, or cost?"
Outcome: Explicit requirements → informed trade-offs
触发条件: 冲突目标之间的权衡
问题: 「优化方向:速度、可靠性还是成本?」
结果: 明确需求 → 知情的权衡决策

Pattern 8: Custom Input Handling

模式8:自定义输入处理

Trigger: "Other" option selected
Question: "Please describe..." with validation
Outcome: Unexpected inputs handled gracefully
触发条件: 用户选择「其他」选项
问题: 「请描述...」附带校验
结果: 优雅处理预期外的输入

Pattern 9: Experience Level Calibration

模式9:经验水平适配

Trigger: Unclear target audience
Question: "Beginner, intermediate, or advanced?"
Outcome: Content adapted to expertise level
触发条件: 目标受众不明确
问题: 「初学者、中级还是高级?」
结果: 内容适配受众专业水平

Pattern 10: Approval Workflow

模式10:审批工作流

Trigger: Major decision needs consensus
Question: Multi-team approval with options
Outcome: Documented decision with stakeholder buy-in

触发条件: 重大决策需要共识
问题: 多团队审批选项
结果: 记录决策,获得利益相关者同意

✅ Best Practices Summary

✅ 最佳实践总结

DO's

推荐做法

  • Be specific: "Which database type?" not "What should we use?"
  • Provide context: Include file names, scope, or impact
  • Order logically: General → Specific; safest option first
  • Flag risks: Use "NOT RECOMMENDED" or "CAUTION:" prefixes
  • Explain trade-offs: Mention time, resources, complexity, performance
  • Limit options: 2-4 per question (not 5+ for decision paralysis)
  • Validate custom input: Check "Other" responses for validity
  • Batch related Q's: Keep related decisions together (max 4 questions)
  • 具体明确: 问「数据库类型?」而不是「我们应该用什么?」
  • 提供上下文: 包含文件名、范围或影响
  • 逻辑排序: 从通用到具体;最安全的选项放在最前面
  • 标记风险: 使用「不推荐」或「注意:」前缀
  • 说明权衡: 提及时间、资源、复杂度、性能
  • 限制选项: 每个问题2-4个选项(不要超过5个避免决策瘫痪)
  • 校验自定义输入: 检查「其他」响应的有效性
  • 批量关联问题: 把相关决策放在一起(最多4个问题)

DON'Ts

禁止做法

  • Overuse questions: Only ask when genuinely ambiguous
  • Too many options: 5+ options cause decision paralysis
  • Vague labels: "Option A", "Use tokens", "Option 2"
  • Skip descriptions: User needs rationale for informed choice
  • Hide trade-offs: Always mention implications and costs
  • Ask for obvious: Single clear path = no question needed
  • Recursive surveys: Avoid asking the same question twice
  • Ignore language: Always match user's configured conversation_language

  • 过度使用提问: 仅在确实存在歧义时才询问
  • 选项过多: 5个以上选项会导致决策瘫痪
  • 标签模糊: 不要用「选项A」、「使用令牌」、「选项2」这类表述
  • 跳过描述: 用户需要理由才能做出知情选择
  • 隐藏权衡: 始终说明影响和成本
  • 询问显而易见的问题: 只有唯一明确路径时不需要提问
  • 循环调研: 避免重复询问同一个问题
  • 忽略语言: 始终匹配用户配置的对话语言

🔗 Related Skills

🔗 相关技能

  • moai-core-personas
    (Communication styles by user level)
  • moai-core-spec-authoring
    (SPEC clarity & structure)
  • moai-foundation-specs
    (SPEC format & requirements)
  • moai-core-language-detection
    (Conversation language handling)

  • moai-core-personas
    (按用户级别匹配沟通风格)
  • moai-core-spec-authoring
    (需求规格清晰度与结构)
  • moai-foundation-specs
    (需求规格格式与要求)
  • moai-core-language-detection
    (对话语言处理)

📚 Quick Reference Card

📚 快速参考卡

ScenarioActionKey Points
Vague requestAsk for clarification1-4 questions max
Multiple approachesLet user chooseShow trade-offs clearly
Risky operationGet explicit consentRequire final confirmation
Feature selectionUse multi-selectIndependent options only
Dependent decisionsUse sequential surveysAsk follow-ups based on answers
Custom inputValidate carefullyRe-ask if invalid
AccessibilityPlain text UINo complex formatting

场景操作核心要点
模糊请求询问澄清最多1-4个问题
多个方案让用户选择清晰展示权衡
风险操作获取明确同意需要最终确认
功能选择使用多选仅提供独立选项
依赖决策使用顺序调研基于答案跟进提问
自定义输入仔细校验无效则重新询问
无障碍适配纯文本UI无复杂格式

Token Budget Optimization

Token预算优化

  • Average per survey: 500-800 tokens
  • Typical workflow: 1-2 surveys per task (1,000-1,600 tokens total)
  • Benefit: Eliminates 3-5 clarification rounds (3,000-5,000 tokens saved)
  • ROI: Net savings of 1,400-3,500 tokens per interaction

For detailed API specifications: reference.md
For real-world examples: examples.md
Last Updated: 2025-11-18
Status: Production Ready (Enterprise )
  • 每份调研平均消耗: 500-800 tokens
  • 典型工作流: 每个任务1-2份调研(总消耗1000-1600 tokens)
  • 收益: 减少3-5轮澄清沟通(节省3000-5000 tokens)
  • 投资回报率: 每次交互净节省1400-3500 tokens

详细API规格: reference.md
实际场景示例: examples.md
最后更新: 2025-11-18
状态: 已上线生产(企业版)