包含以下模块: - antdv-next-admin: Vue 3 + TypeScript + Ant Design Vue 管理后台 - 设备/许可证/配件/耗材 CRUD 管理页面 - 基础数据管理 (分类/位置/制造商/型号/供应商) - 业务管理 (故障报修/盘点/资产分配/资产申请/交易记录) - 下拉选项改造 (ID输入框 → 搜索下拉选择) - 资产状态字典化 (接入sys_dict系统) - 界面文案优化 (设备→资产, 在库/在用/维修中/已报废) - 修复 console 警告 (popupClassName, 重复组件注册) - our-itam: Java Spring Boot + magic-api 后端服务 - fantastic-admin: 前端底层框架 (pnpm monorepo) - ciyo-itasset: CIYO 资产模块 - magic-script-skill: Claude Code skill 定义 - .claude: 对话历史记录 Co-Authored-By: Claude Code <noreply@anthropic.com>
136 lines
4.8 KiB
Markdown
136 lines
4.8 KiB
Markdown
---
|
||
name: fa-feedback
|
||
description: 当用户在使用 fa-* 系列技能(如 fa-framework-settings、fa-slot-creator、fa-form-builder、fa-route-generator、fa-store-generator、fa-page-optimizer、fa-theme-customizer 等)时,在同一个目标上经历了 3 次及以上的修改仍未达到预期效果,必须触发此技能。触发信号包括:用户反复要求调整同一处配置或代码、连续说"不对"/"再改改"/"还是不行"、对同一个功能点多次提出修正意见。即使用户没有明确表示"上报"或"反馈",只要检测到反复沟通修改的模式,就应主动触发。
|
||
---
|
||
|
||
# Fantastic-admin 问题反馈
|
||
|
||
当用户在使用 fa-* 系列技能时遇到反复修改仍无法达到预期的情况,这通常意味着框架本身可能存在改进空间(比如 skill 指令不够精确、框架 API 不够直观、文档缺失等)。此时应主动询问用户是否愿意将问题反馈给框架作者。
|
||
|
||
## 触发条件
|
||
|
||
在当前对话中,如果满足以下任一条件,则触发此技能:
|
||
|
||
1. **同一目标的修改次数 >= 3 次**:用户针对同一个功能点或配置项,已经要求修改 3 次及以上
|
||
2. **用户表达持续不满**:用户连续使用"不对"、"还是不行"、"再试试"、"跟我说的不一样"等表述
|
||
3. **循环修改模式**:修改 A -> 改回 -> 再改 A,出现来回反复的情况
|
||
|
||
## 执行流程
|
||
|
||
### 第一步:分析问题
|
||
|
||
回顾当前对话历史,提炼以下信息:
|
||
|
||
1. **使用的技能**:用户在使用哪个 fa-* 技能
|
||
2. **用户的原始需求**:用户最初想要实现什么
|
||
3. **反复修改的焦点**:哪个具体的配置项/代码/功能点在被反复调整
|
||
4. **未达预期的原因**:为什么始终无法满足用户的需求(是 skill 指令有误?框架 API 限制?还是理解偏差?)
|
||
|
||
### 第二步:询问用户
|
||
|
||
用以下方式询问用户(注意语气要友好自然,不要让用户感到被指责):
|
||
|
||
```
|
||
我注意到在 [具体功能] 上我们已经来回调整了好几次,这很可能说明框架的 [skill/文档/API] 在这方面有改进空间。
|
||
|
||
你是否愿意将这个问题反馈给 Fantastic-admin 的作者?这有助于改进框架,让以后的使用体验更好。
|
||
|
||
如果你同意,我会帮你整理一份精简的问题描述,然后打开 GitHub Discussions 页面,内容会自动填好,你只需要检查一下就可以提交。
|
||
```
|
||
|
||
- 如果用户**同意**,继续第三步
|
||
- 如果用户**拒绝**,尊重用户的决定,继续协助解决当前问题,不再提及反馈
|
||
|
||
### 第三步:整理反馈内容
|
||
|
||
生成精简的反馈报告,格式如下:
|
||
|
||
**标题**(简洁明了,一句话概括问题):
|
||
```
|
||
[技能名称] 在 [场景] 下无法正确 [操作]
|
||
```
|
||
|
||
**正文**(使用 Markdown 格式):
|
||
```markdown
|
||
## 问题描述
|
||
|
||
[一句话说明用户想做什么,以及遇到了什么问题]
|
||
|
||
## 使用的技能
|
||
|
||
[fa-xxx-xxx]
|
||
|
||
## 复现步骤
|
||
|
||
1. [用户的原始请求]
|
||
2. [第一次修改及结果]
|
||
3. [后续修改及结果]
|
||
|
||
## 期望行为
|
||
|
||
[用户期望的结果是什么]
|
||
|
||
## 实际行为
|
||
|
||
[实际发生了什么,为什么不符合预期]
|
||
|
||
## 可能的原因
|
||
|
||
[基于分析,推测问题可能出在哪里,比如 skill 指令、框架 API、默认配置等]
|
||
```
|
||
|
||
内容整理原则:
|
||
- **精简**:只保留关键信息,去掉对话中的冗余内容
|
||
- **客观**:描述事实,不添加情绪化表达
|
||
- **可操作**:让框架作者看到后能理解问题并采取行动
|
||
|
||
### 第四步:生成链接并打开
|
||
|
||
将整理好的标题和正文通过 URL 参数编码,拼接到 GitHub Discussions 链接中:
|
||
|
||
```
|
||
https://github.com/orgs/fantastic-admin/discussions/new?category=通用&title={编码后的标题}&body={编码后的正文}
|
||
```
|
||
|
||
使用以下方式生成并打开链接:
|
||
|
||
```bash
|
||
# 生成 URL 编码的链接并打开
|
||
python3 -c "
|
||
import urllib.parse
|
||
import subprocess
|
||
|
||
title = '''在此填入标题'''
|
||
body = '''在此填入正文'''
|
||
|
||
params = urllib.parse.urlencode({
|
||
'category': '通用',
|
||
'title': title,
|
||
'body': body
|
||
}, quote_via=urllib.parse.quote)
|
||
|
||
url = f'https://github.com/orgs/fantastic-admin/discussions/new?{params}'
|
||
print(f'链接已生成:{url}')
|
||
subprocess.run(['open', url])
|
||
"
|
||
```
|
||
|
||
打开链接后,告诉用户:
|
||
|
||
```
|
||
已在浏览器中打开 GitHub Discussions 页面。请检查预填的内容是否准确,确认无误后点击提交即可。
|
||
|
||
如果页面中的标题和内容没有自动填充(GitHub Discussions 可能不支持 URL 参数预填),你可以手动复制以下内容:
|
||
|
||
**标题**:[标题内容]
|
||
|
||
**内容**:
|
||
[正文内容]
|
||
```
|
||
|
||
始终同时展示原文内容作为备选方案,确保用户无论 URL 参数是否生效都能顺利提交反馈。
|
||
|
||
### 第五步:继续协助
|
||
|
||
反馈流程完成后,继续协助用户解决当前的问题,不要因为反馈流程中断用户的工作。
|