skill测试

# skill-generate 测评报告

**测评时间**：2026-05-14
**测评版本**：skill-generate_3_
**测评目标**：面向公司内部销售、CSM、客服、产品、研发等非技术人员，重点评估对销售/CSM 等不懂代码的小白用户的友好程度

---

## 综合评分

| 维度 | 得分 |
|------|------|
| 综合评分 | 72 / 100 |
| 面向小白友好度 | 65 / 100 |
| 流程完整性 | 85 / 100 |
| 结构清晰度 | 80 / 100 |

### 各维度细分

| 维度 | 得分 | 评级 |
|------|------|------|
| 用户语言亲和度 | 58 / 100 | ⚠️ 中等 |
| 场景理解深度 | 70 / 100 | ⚠️ 中等 |
| 流程引导完整性 | 85 / 100 | ✅ 良好 |
| 对话设计质量 | 68 / 100 | ⚠️ 中等 |
| 防错机制 | 82 / 100 | ✅ 良好 |
| 生成质量保障 | 78 / 100 | ✅ 良好 |
| 非技术用户体验 | 55 / 100 | ❌ 较弱 |

---

## 核心判断

> skill-generate 的整体设计思路是对的——把澄清和生成分开、禁止在需求模糊时问技术细节、强制引导用户一步步描述业务——这些都是正确的判断。但有一个根本矛盾没有解决：
>
> **这份 Skill 的指导文档是用"写给 AI 看的工程语言"写的，但 AI 用它和人对话时，如果照搬这些词汇，Sales/CSM 就会听不懂。**

---

## 做得好的地方

### ✅ 用户画像明确写进文档
`dialogue-flow.md` 明确标注"非技术人员，了解业务不了解技术"，遇到专业术语切换通俗语言——方向正确。

### ✅ 严格分离"澄清"与"生成"两个流程
防止用户在需求还没想清楚时就直接生成，减少返工，逻辑设计合理。

### ✅ 外部服务澄清只问业务、不问技术
`service-clarification-flow.md` 明确禁止询问接口地址、HTTP 方法等，让非技术用户不被技术细节打蒙。

### ✅ 提问顺序结构化、有强制约束
功能 → 触发场景 → 禁止场景 → 概念 → 业务步骤，顺序固定，避免 AI 乱跳。

### ✅ 数据流校验机制完善
步骤间的引用格式、断点检测、全局校验——质量保障做得扎实。

---

## 主要问题

### ❌ 问题一：Skill 本身的第一句话就对小白不友好

SKILL.md 开篇写道：

> "提供两个独立功能：澄清需求（产出 proposal 目录）和生成 Skill（基于 proposal 生成 Skill 骨架并完善）"

Sales/CSM 看到"proposal 目录""Skill 骨架"可能完全不知道是什么意思，第一印象就产生了距离感。

---

### ❌ 问题二：第一个问题直接问 A/B 选择，门槛偏高

进入时问用户：

> "你想要：A) 通过问答的方式澄清需求，产出需求文档 / B) 根据已经生成的需求文档创建 Skill"

大多数小白没有"已有文档"，但不知道该选哪个，容易选错或困惑。

---

### ❌ 问题三：没有情景化的开场暖场

缺少"你想做一个什么功能？帮我描述一下你的日常工作场景"这类引导语，开门见山让用户选 A/B，对不熟悉 Skill 概念的用户无从下手。

---

### ⚠️ 问题四：业务步骤的引导过于工程化

步骤 5 中"输出结构""字段名""外部接口""待回填引用"等词汇频繁出现在对话指引里。若 AI 照搬这些词汇与销售/CSM 对话，会造成明显的沟通障碍。

**举例：**
- `dialogue-flow.md` 说"询问输出结构" → AI 如果真问"这一步的输出结构是什么？"，Sales 会一脸茫然

---

### ⚠️ 问题五：services.md 模板对非技术用户来说过于复杂

澄清流程结束后要交给技术人员的 `services.md`，内含"下游引用表""技术字段名"等内容，Sales/CSM 收到这个文件不知道怎么处理、交给谁、说什么。

---

### ⚠️ 问题六：缺少"典型场景示例"降低理解成本

没有一个完整的、面向销售/CSM 的真实案例展示（如"发起合同签署 Skill"从对话到产出的全过程），用户很难建立直觉，不知道最终产物长什么样。

---

### ❌ 问题七：结束语没有引导用户下一步行动

澄清完成后告知"services.md 是给技术开发人员的"，但没有告诉 Sales/CSM：
- 我拿这个文件去找谁？
- 找到之后说什么？
- 他们填完之后我再做什么？

流程断在了用户最需要指引的地方。

---

## 改进建议

### ① 改写开场引导语

把"A/B 选择"改为情景感知开场：先问"你现在想做什么？"，如果用户说"我想做一个 Skill"，自动进入澄清流程；如果说"我已经有需求文档了"，再进入生成流程。让入口判断对用户透明，不需要用户自己判断走哪条路。

---

### ② 对话中屏蔽工程术语

在 `dialogue-flow.md` 中增加"对话用语规范"，给 AI 明确的替换词表：

| 工程术语 | 替换为 |
|---------|--------|
| 字段名 | 这条信息叫什么名字 |
| 外部接口 | 需要连接的系统 |
| 输出结构 | 这一步完成后会产生什么 |
| 待回填引用 | 暂时先标记，后续技术同学来补充 |
| proposal 目录 | 需求文档 |
| Skill 骨架 | 初始版本 |

---

### ③ 增加销售/CSM 专属场景示例

在 `references/` 下增加 `examples-for-sales.md`，包含 2-3 个真实场景，例如：
- 查询客户合同状态
- 生成拜访报告
- 整理线索信息

展示从需求描述到 proposal 文档的完整对话过程，降低入门门槛，让用户在开始前就知道"最终会产出什么"。

---

### ④ 优化澄清结束语，补充交接流程

结束时不只说"文档在哪里"，还要引导用户完成整个链路：

> 1. 把 `services.md` 发给负责对接系统的技术同学
> 2. 请他在文件的"技术实现"部分补充接口信息
> 3. 完成后回来告诉我，我来帮你生成完整的 Skill

---

### ⑤ 加入"不懂没关系"的兜底话术

当用户回答"我不知道""不清楚"时，`dialogue-flow.md` 应提供标准兜底引导，例如：

> "没关系，你只需要告诉我用户会怎么开口触发这个功能，我来帮你整理。"

明确约束兜底语言，而不是让 AI 自由发挥，避免风格不一致或再次引入专业术语。

---

## 总结

skill-generate 有扎实的骨架——流程设计完整、防错机制健全、技术质量保障到位。改进方向不是推倒重来，而是在**语言层**和**用户体验层**做精细打磨：

- 最高优先级：对话用语规范（工程词 → 业务话替换词表）
- 次优先级：开场引导语改写 + 结束语补充交接指引
- 锦上添花：增加面向 Sales/CSM 的真实场景示例

这三项改动成本低、收益大，完成后预计非技术用户体验评分可从 **55 → 75+**。