SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsai-feedback-collector-zh

ai-feedback-collector-zh

Office & productivity

View repository

Updated 10-16 03:11

About this skill

AI Issue Feedback Collector

Use this skill to organize users' natural language descriptions of issues with AI tool usage into structured, objective issue feedback records that are easy to tally and assign.

The goal of this skill is "collection and normalization," not direct troubleshooting. It is necessary to preserve the user's original intent, avoid over-inference, and make the output directly pasteable into issue systems, spreadsheets, group chats, Feishu Bitable, or internal feedback platforms.

Workflow

  1. Determine whether the user is providing feedback on an issue in an AI tool or AI-assisted workflow.
  2. Extract observable facts: tool, task, scenario, failure manifestation, impact, business context, environment information.
  3. Determine the possible issue category: model capability, environment/toolchain, clarity of business description, process collaboration, user skill/training, data/permissions, security/compliance, or unknown.
  4. Distinguish facts from speculation. For fields that are missing or cannot be safely determined, use unknown, do not fabricate.
  5. Output structured feedback according to the template below.
  6. When standard tags are needed, refer to references/label-taxonomy.md。
  7. If information is insufficient, put the issue under "Suggested Supplementary Information"; do not interrupt the user by default with repeated follow-up questions unless the user explicitly wants interview-style collection.
  8. Store the output title and markdown-formatted content in the filescripts/issue_output.json, to facilitate subsequent issue creation.
  9. Based on the current operating system environment, choose the script under scripts to send the feedback via webhook to the specified issue system or feedback platform.
    1. Windows environment: Check whether Python is installed. If Python is installed, runpython scripts/create_issue.py; if Python is not installed, prompt the user that a Python environment needs to be installed to automatically create the issue, or guide the user to manually create the issue in the browser: open the browser and visithttps://gitcode.com/openharmonyinsight/ai-dev-feedback/issues/create, according toscripts/issue_output.jsonmanually fill in and submit the title and content.
    2. Linux environment: Runbash scripts/create_issue.sh。

Output Template

## AI 使用问题反馈

### 标题
<用一句话概括问题。>

### 问题摘要
<基于用户描述，客观总结发生了什么。>

### 原始描述
<保留用户原话。>

### 使用场景
- 工具：`<工具名称或 unknown>`
- 场景：`<scenario 标签>`
- 任务类型：`<task 标签>`
- 工作流阶段：`<workflow-stage 标签或 unknown>`
- 受影响角色：`<角色或 unknown>`

### 问题分类
- 主分类：`<category 标签>`
- 次分类：`<category 标签或 none>`
- 分类置信度：`<high|medium|low|unknown>`
- 判断依据：<基于用户描述给出简短证据>

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

### 影响
<描述对效率、质量、信任、成本或安全的影响；不清楚则写 unknown。>

### 可能原因
<可选。只列出合理假设，并明确不确定性。>

### 改进方向
<说明这条反馈可以如何帮助改进 AI 辅助研发，例如模型行为、工具集成、环境配置、提示词/流程设计、业务需求表达或开发者赋能。>

### 建议补充信息
- <有助于分派或定位问题的具体信息。>
- <有助于复现或判断影响范围的具体信息。>

### 建议分派方向
<可选一个或多个：产品体验、模型能力、工具集成、环境配置、业务分析、提示词/流程设计、权限/数据访问、文档/培训、安全/合规、unknown。>

Tag Rules

Use short, machine-readable tags. Tag values should preferably use English lowercase kebab-case, to facilitate tallying and cross-language aggregation.

Required tag families:

  • tool: The AI product or Agent involved.
  • category: The root-cause issue category used for tallying and improvement planning.
  • scenario: The broad usage scenario.
  • task: The type of task the user wants to complete.
  • issue: The observed issue manifestation.
  • capability: The AI capability domain possibly involved.
  • severity: Impact severity.
  • frequency: Frequency of occurrence.

If one piece of feedback contains multiple issue manifestations, multiple issue: tags may be output. If a field is not stated and cannot be safely inferred, use unknown。

When standard tag values or severity rules are needed, read references/label-taxonomy.md。

Issue Classification Rules

Use category: to answer this question: "What type of thing is most likely to be improved to prevent this issue from recurring?"

  • category:model-capability: Insufficient AI ability to understand context, reason, plan, understand code, make tool-use decisions, follow instructions, or recover from failures.
  • category:environment-tooling: The problem is more likely to come from the local environment, dependencies, build/test configuration, IDE/CLI integration, tool permissions, network, unavailable commands, or unstable tool execution.
  • category:business-context-clarity: The business goals, product rules, domain concepts, acceptance criteria, boundary conditions, or expected behavior are not described clearly enough.
  • category:workflow-process: The AI-assisted development process itself needs improvement, for example lacking review gates, unclear handoffs, tasks split too large, no testing strategy, or lacking rollback/checkpoint habits.
  • category:user-skill-training: The main gap may be prompt writing, the way context is provided, AI collaboration habits, expectation management, or result verification methods.
  • category:data-permission: The AI cannot access the required code, files, documents, logs, credentials, private knowledge base, or runtime data.
  • category:safety-compliance: Involves privacy, security, compliance, unsafe code changes, production risk, or irreversible operations.
  • category:unknown: The description is insufficient to classify responsibly.

Prioritize selecting one primary category. Add a secondary category only when the evidence is clear. When classification relies mainly on inference, the confidence should be set to low。

Severity rules

  • severity:low: Minor inconvenience, with a clear workaround, and very little business impact.
  • severity:medium: Clearly affects efficiency or quality, but the user can recover.
  • severity:high: Blocks tasks, causes significant rework, or affects multiple users.
  • severity:critical: Causes data loss, security/privacy risk, production impact, compliance risk, or irreversible dangerous operations.

Expression rules

  • Stay neutral, concise, and objective.
  • Do not blame the user, and do not blame the AI system.
  • When there is no evidence, do not promise a root-cause judgment.
  • Unless the user explicitly requests it, do not directly solve the original task.
  • Preserve enough original detail to facilitate later review.
  • Prioritize outputting a complete version of feedback first, then indicate what additional information can be supplied.

Example

Input:

在使用 minmax 模型封装 CLI 时，总会出现编译过程，如果当前错误解决不了，就直接把这个封装的接口删掉。

Output:

## AI 使用问题反馈

### 标题
minmax 模型封装 CLI 时在编译失败后会删除封装接口

### 问题摘要
用户在使用 minmax 模型封装 CLI 时，遇到编译错误后，如果模型无法解决当前错误，它会直接删除已封装的接口，而不是继续定位问题、保留已有实现或请求用户确认。

### 原始描述
在使用 minmax 模型封装 CLI 时，总会出现编译过程，如果当前错误解决不了，就直接把这个封装的接口删掉。

### 使用场景
- 工具：`unknown`
- 场景：`coding`
- 任务类型：`feature-dev`
- 工作流阶段：`implementation-and-verification`
- 受影响角色：`developer`

### 问题分类
- 主分类：`model-capability`
- 次分类：`workflow-process`
- 分类置信度：`medium`
- 判断依据：用户描述中提到模型在无法解决编译错误时采取破坏性策略，直接删除封装接口。

### 标签
- `tool:unknown`
- `category:model-capability`
- `scenario:coding`
- `task:feature-dev`
- `issue:unsafe-action`
- `issue:bad-output-quality`
- `capability:planning`
- `capability:coding`
- `capability:instruction-following`
- `severity:high`
- `frequency:frequent`

### 影响
该问题可能导致已完成的接口封装工作被破坏，增加人工恢复和代码审查成本，并降低开发者对 AI 自动改代码能力的信任。

### 可能原因
模型可能缺少“失败后保留已有成果”的约束，也可能在编译错误无法修复时倾向于通过删除代码让编译通过。当前还需要结合具体日志和变更记录确认。

### 改进方向
需要加强 AI 辅助研发中的代码保护策略：模型遇到编译失败时，应优先定位错误、最小化修改、解释失败原因，并在删除接口、移除功能或大范围重构前请求用户确认。

### 建议补充信息
- 使用的是哪个具体 CLI 工具或平台。
- minmax 模型的具体模型名称和版本。
- 被删除的接口是否是用户明确要求保留的核心功能。
- 编译错误日志或失败命令。
- 这种行为是偶发还是每次编译失败后都会出现。

### 建议分派方向
模型能力、提示词/流程设计、产品体验