ai-feedback-collector

AI 反馈收集器

使用此技能，将有关 AI 工具使用情况的自由形式反馈整理为结构化、客观的问题报告。

目标是收集和规范化信息，而不是排查问题。保留用户原意，避免对简略描述过度解读，并使输出便于粘贴到问题跟踪器、电子表格、聊天线程或内部反馈系统中。

工作流

1. 判断用户是否在报告 AI 工具或 AI 辅助工作流的问题。
2. 从描述中提取可观察到的事实：工具、任务、场景、故障表现、影响、业务背景，以及任何可用的环境详情。
3. 对可能的问题类别进行分类：模型能力、环境／工具、业务背景清晰度、工作流／流程、用户技能／培训、数据／权限、安全／合规，或未知。
4. 将事实与推测的可能性分开。对不确定的字段标记为 unknown，不要编造详情。
5. 按照以下模板规范化报告。
6. 需要时使用 references/label-taxonomy.md 中的分类法添加清晰标签。
7. 仅将后续问题列在“建议补充的信息”下；除非用户明确要求采用访谈式收集信息，否则不要阻止输出。

输出模板

## AI Usage Feedback

### Title
<One concise sentence describing the issue.>

### Summary
<Objective summary of what happened, based only on the user's description.>

### Original Description
<Preserve the user's original wording.>

### Scenario
- Tool: `<tool-name-or-unknown>`
- Scenario: `<scenario-label>`
- Task Type: `<task-label>`
- Workflow Stage: `<stage-label-or-unknown>`
- Affected User/Role: `<role-or-unknown>`

### Problem Category
- Primary Category: `<category-label>`
- Secondary Categories: `<category-label-or-none>`
- Classification Confidence: `<high|medium|low|unknown>`
- Evidence: `<short reason based on the user's description>`

### Labels
- `tool:<value>`
- `category:<value>`
- `scenario:<value>`
- `task:<value>`
- `issue:<value>`
- `capability:<value>`
- `severity:<value>`
- `frequency:<value>`

### Impact
<Describe the likely impact on efficiency, quality, trust, cost, or safety. If unclear, say unknown.>

### Possible Causes
<Optional. List only reasonable hypotheses and make uncertainty clear.>

### Improvement Direction
<How this feedback could help improve AI-assisted R&D, such as model behavior, tool integration, environment setup, prompt/workflow design, business requirement capture, or developer enablement.>

### Suggested Additional Information
- <Specific detail that would help triage the issue.>
- <Specific detail that would help reproduce or understand impact.>

### Suggested Routing
<One or more of: product experience, model capability, tool integration, environment setup, business analysis, prompt/workflow design, permissions/data access, documentation/training, safety/compliance, unknown.>

标签指南

使用紧凑、机器可读的标签。优先使用小写连字符格式的值。

必需的标签类别：

• tool：涉及的 AI 产品或 Agent。
• category：最可能的根本问题类别，用于统计分析和改进规划。
• scenario：广义使用场景。
• task：用户打算完成的任务。
• issue：观察到的故障模式。
• capability：涉及的 AI 能力领域。
• severity：估计的影响级别。
• frequency：问题出现的频率。

如果报告涉及多种问题类型，请添加多个 issue: 标签。如果某个字段未说明或无法安全推断，请使用 unknown。

需要规范的标签值或严重程度规则时，请阅读 references/label-taxonomy.md。

问题类别规则

使用 category: 回答“最有可能通过哪类改进来避免问题再次发生？”

• category:model-capability：AI 在任务背景和环境都充分的情况下，仍误解了上下文、推理不佳、产生幻觉、未能规划、忽略指令、错误使用工具，或在失败后重复采用无效策略。
• category:environment-tooling：问题似乎由本地环境、依赖项、构建／测试设置、IDE／CLI 集成、工具权限、网络、命令不可用或工具执行不可靠导致。
• category:business-context-clarity：用户、团队或 AI 未能清楚描述业务目标、产品规则、领域概念、验收标准、边界情况或预期行为。
• category:workflow-process：问题源于 AI 辅助研发工作流的组织方式，例如缺少评审关卡、交接不明确、任务拆解不充分、没有测试策略，或缺少回滚／检查点习惯。
• category:user-skill-training：主要差距可能在于提示词编写、AI 使用习惯、期望管理，或不清楚如何提供上下文并验证输出。
• category:data-permission：AI 无法访问所需的文件、代码仓库、文档、日志、凭据、私有数据或知识源。
• category:safety-compliance：问题涉及隐私、安全、合规、不安全的代码更改或不可逆操作。
• category:unknown：描述不足，无法负责任地分类。

优先选择一个主要类别。只有在明确相关时才添加次要类别。如果类别主要是推断得出的，请将置信度设为 low。

严重程度规则

• severity:low：轻微不便，有简单的解决方法，业务影响很小。
• severity:medium：对效率或质量造成明显影响，但用户可以恢复。
• severity:high：阻碍任务、导致大量返工或影响多位用户。
• severity:critical：导致数据丢失、安全或隐私风险、生产环境影响、合规风险，或不安全且不可逆的操作。

风格规则

• 保持中立、简洁。
• 不要指责用户或 AI 系统。
• 除非有证据，否则不要断言根本原因。
• 除非用户明确要求，否则不要解决原始任务。
• 保留足够的原始细节，以便后续审核。
• 优先一次性提供完整的初步报告，而不是提出许多澄清问题。

示例

输入：

I was using opencode to modify an API. The model kept editing the wrong files, and after tests failed repeatedly, it did not change its approach.

输出：

## AI Usage Feedback

### Title
opencode repeatedly edited the wrong files during an API change task

### Summary
The user was using opencode to modify an API, but the AI repeatedly edited incorrect files and kept rerunning failing tests without changing its approach.

### Original Description
I was using opencode to modify an API. The model kept editing the wrong files, and after tests failed repeatedly, it did not change its approach.

### Scenario
- Tool: `opencode`
- Scenario: `coding`
- Task Type: `api-change`
- Workflow Stage: `implementation-and-verification`
- Affected User/Role: `developer`

### Problem Category
- Primary Category: `model-capability`
- Secondary Categories: `workflow-process`
- Classification Confidence: `medium`
- Evidence: The description says the AI repeatedly edited the wrong files and did not change strategy after test failures.

### Labels
- `tool:opencode`
- `category:model-capability`
- `scenario:coding`
- `task:api-change`
- `issue:wrong-file-edit`
- `issue:repeated-failure`
- `capability:planning`
- `capability:context-management`
- `severity:medium`
- `frequency:unknown`

### Impact
The issue likely reduced development efficiency and increased manual review, rollback, and debugging effort.

### Possible Causes
The AI may have failed to build an accurate codebase map, preserve task context, or revise its plan after repeated test failures.

### Improvement Direction
Improve the coding agent's repository understanding, failure recovery behavior, and guardrails for changing files only after confirming the relevant code path.

### Suggested Additional Information
- Which files were expected to change and which files were incorrectly modified.
- The failing test command and error output.
- Whether similar behavior has happened in other tasks.

### Suggested Routing
model capability, prompt/workflow design