ai-feedback-collector-zh

AI 問題フィードバック収集ツール

このスキルを使用すると、AI ツールの使用上の問題についてユーザーが自然言語で説明した内容を、構造化された客観的なフィードバック記録にまとめ、統計処理や担当者への割り当てを容易にできます。

このスキルの目的は「収集と標準化」であり、問題を直接解決することではありません。ユーザーの意図を保ち、過度な推測を避け、出力を issue システム、表、グループチャット、Feishu の多次元テーブル、または社内フィードバックプラットフォームにそのまま貼り付けられるようにします。

ワークフロー

1. ユーザーが AI ツールまたは AI 支援ワークフローに関する問題を報告しているか判断します。
2. 観察可能な事実を抽出します。ツール、タスク、シナリオ、失敗の様子、影響、業務上の背景、環境情報を含めます。
3. 考えられる問題の分類を判断します。モデルの能力、環境／ツールチェーン、業務内容の明確さ、プロセス上の連携、ユーザーのスキル／トレーニング、データ／権限、安全／コンプライアンス、または不明。
4. 事実と推測を区別します。情報が不足している場合や安全に判断できない場合は、unknown を使用し、捏造しないでください。
5. 以下のテンプレートに従って、構造化されたフィードバックを出力します。
6. 標準タグが必要な場合は、references/label-taxonomy.md を参照します。
7. 情報が不足している場合は、問題を「追加を推奨する情報」に記載します。ユーザーがインタビュー形式での収集を明確に希望している場合を除き、ユーザーへの質問を繰り返すために作業を中断しないでください。
8. 出力したタイトルと Markdown 形式の内容を、後で issue を作成できるようにファイルscripts/issue_output.jsonに保存します。
9. 現在のオペレーティングシステム環境に応じて、scripts 以下のスクリプトを選択し、webhook 経由で指定された issue システムまたはフィードバックプラットフォームにフィードバックを送信します。
   1. Windows 環境：Python がインストールされているか確認します。インストールされている場合は、python scripts/create_issue.pyを実行します。インストールされていない場合は、issue を自動作成するには Python 環境のインストールが必要であるとユーザーに伝えるか、ブラウザーで手動作成するよう案内します。ブラウザーでhttps://gitcode.com/openharmonyinsight/ai-dev-feedback/issues/createにアクセスし、scripts/issue_output.jsonに記載されたタイトルと内容を手動で入力して送信します。
   2. Linux 環境：bash scripts/create_issue.shを実行します。

出力テンプレート

## 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。>

タグのルール

短く、機械で読み取りやすいタグを使用します。集計や言語をまたいだ取りまとめを容易にするため、タグ値には lowercase kebab-case の英語を優先して使用します。

必須のタグ群：

• tool：該当する AI 製品または Agent。
• category：原因となる問題の分類。統計や改善計画に使用します。
• scenario：大まかな使用シナリオ。
• task：ユーザーが完了しようとしているタスクの種類。
• issue：観察された問題の様子。
• capability：関連する可能性のある AI 能力の領域。
• severity：影響の深刻度。
• frequency：発生頻度。

1 件のフィードバックに複数の問題の様子が含まれる場合は、複数の issue: タグを出力できます。フィールドの情報がなく、安全に推測できない場合は、unknown を使用します。

標準タグ値または深刻度のルールが必要な場合は、references/label-taxonomy.md を読み込みます。

問題分類のルール

category: は、「どの種類の改善によって、この問題の再発を最も防げるか」という質問への回答として使用します。

• category:model-capability：AI のコンテキスト理解、推論、計画、コード理解、ツール使用の判断、指示への従属、または失敗からの復旧能力が不足しています。
• category:environment-tooling：問題は、ローカル環境、依存関係、ビルド／テストの設定、IDE／CLI 統合、ツールの権限、ネットワーク、コマンドが使用できないこと、またはツール実行の不安定さに起因する可能性が高いです。
• category:business-context-clarity：業務目標、製品ルール、ドメインの概念、受け入れ基準、境界条件、または期待する動作の説明が不明確です。
• category:workflow-process：AI 支援開発プロセス自体の改善が必要です。たとえば、レビューの関門がない、引き継ぎが不明確、タスクの分割が大きすぎる、テスト戦略がない、またはロールバック／チェックポイントの習慣がない、といった問題です。
• category:user-skill-training：主な不足は、プロンプトの書き方、コンテキストの提供方法、AI との協業の習慣、期待値の管理、または結果の検証方法にある可能性があります。
• category:data-permission：AI が、必要なコード、ファイル、ドキュメント、ログ、認証情報、プライベートなナレッジベース、または実行データにアクセスできません。
• category:safety-compliance：プライバシー、安全性、コンプライアンス、安全でないコード変更、本番環境のリスク、または不可逆な操作に関係します。
• category:unknown：説明が不足しており、責任を持って分類できません。

主分類は 1 つを優先して選択します。副分類の追加は、根拠が明確な場合に限ります。分類の大部分を推測に頼る場合は、信頼度を low に設定します。

深刻度のルール

• severity:low：軽微な不便で、明確な回避策があり、業務への影響はごくわずかです。
• severity:medium：効率または品質に明らかな影響がありますが、ユーザーは復旧できます。
• severity:high：タスクが阻害される、明らかな手戻りが発生する、または複数のユーザーに影響します。
• severity:critical：データ損失、安全／プライバシー上のリスク、本番環境への影響、コンプライアンスリスク、または不可逆で危険な操作が発生します。

表現のルール

• 中立的、簡潔、客観的に記述します。
• ユーザーも AI システムも非難しません。
• 根拠がない場合、原因を断定しません。
• ユーザーから明確に求められない限り、元のタスクを直接解決しないでください。
• 後で振り返りやすいように、元の詳細を十分に残します。
• まず完全なフィードバックを 1 件出力し、その後に追加可能な情報を提示します。

例

入力：

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

出力：

## 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 模型的具体模型名称和版本。
- 被删除的接口是否是用户明确要求保留的核心功能。
- 编译错误日志或失败命令。
- 这种行为是偶发还是每次编译失败后都会出现。

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