| name | skill-anatomy |
| description | 当用户让你创建一个xiapi Skill的时候,你需要按照下面的要求进行编写 |
Skill 解剖结构(投资领域)
本文档定义了投资领域 Skill 的标准结构,确保质量和一致性。
整体结构
SKILL.md
├── Frontmatter # name + description(含触发词)
├── Overview # 功能概述(1-2 句话)
├── When to Use # 触发条件(简洁列表)
├── Process # 流程主体(核心内容)⭐
│ ├── Step 0: 前期准备(可选)
│ ├── Step 1: Agent循环(获取+分析)
│ └── Step 2: 汇总报告
├── Report Template # 报告模版(输出标准)⭐
├── Quality Checks # 质量检查(精简要点)
├── Common Pitfalls # 常见陷阱(关键陷阱)
├── Key Principles # 重要原则(核心原则)
└── Error Handling # 错误处理(常见错误)
设计原则:
- Process, not prose:Skills 是工作流程,不是参考文档
- Progressive disclosure:SKILL.md 是入口,详细内容外联到 references/
- Quality first:质量优先于速度,宁可晚一点也要准确
完整模版
---
name: <skill-name>
description: '<简短描述>。触发词:<关键词1>、<关键词2>、<关键词3>。适用场景:<场景描述>。不适用场景:<不适用场景描述>。'
---
# <Skill 标题>
<一句话描述 Skill 的功能和价值>
## Overview(功能概述)
<1-2 句话说明 Skill 的核心功能>
## When to Use(何时使用)
当用户需要以下功能时触发:
- <触发场景1>
- <触发场景2>
- <触发场景3>
**具体触发词**:<关键词1>、<关键词2>、<关键词3>
## Process(流程主体)
### Step 0: 前期准备(必填)
**触发条件**:首次使用或 Token 未配置
**跳过条件**:Token 已配置且有效,确认已经配置了Token则跳过该步骤
**完成标准**:API 调用正常,无认证错误
**执行步骤**:
**步骤 0.1:检查 Token 配置状态**
```bash
npx daxiapi-cli@latest config get token
```
步骤 0.2:如未配置,获取 Token
- 提示用户访问 daxiapi.com 个人主页
- 开通 API Token 功能
- 获取生成的 Token
步骤 0.3:配置 Token
npx daxiapi-cli@latest config set token YOUR_TOKEN_FROM_DAXIAPI
export DAXIAPI_TOKEN=YOUR_TOKEN_FROM_DAXIAPI
步骤 0.4:验证配置
npx daxiapi-cli@latest market
如返回正常市场数据,则配置成功。
Step 1: Agent 循环(获取+分析)
目标:从多个维度获取数据并进行深入分析
推荐维度(根据用户需求选择 3-5 个):
| 维度 | CLI 命令 | 分析重点 | 优先级 |
|---|
| <维度1> | daxiapi <cmd1> | <重点1> | 高 |
| <维度2> | daxiapi <cmd2> | <重点2> | 中 |
| <维度3> | daxiapi <cmd3> | <重点3> | 中 |
循环流程:
每次循环包含:
-
获取数据
- 执行 CLI 命令获取数据
- 检查数据完整性,检查数据是否是任务所需
- 处理异常情况
-
分析数据
灵活性:
- ✅ 可根据数据质量调整分析深度
- ✅ 可根据初步结果调整后续维度
- ✅ 可根据用户需求调整重点
完成标准:
- 至少完成 3 个维度的分析
- 关键发现已记录
- 数据异常已处理
Step 2: 汇总报告
目标:整合分析结果,生成结构化报告
执行步骤:
- 整理发现:汇总所有维度的关键发现
- 提炼结论:从发现中提炼核心结论
- 生成报告:按照模版格式化输出
报告要求:
- ✅ 结论先行
- ✅ 数据支撑(引用具体数据)
- ✅ 逻辑清晰(因果关系明确)
- ✅ 格式规范(符合模版要求)
完成标准:
Report Template(报告模版)
市场分析报告
报告日期:[YYYY-MM-DD]
分析对象:[指数/板块/股票名称]
一、核心结论(必填)
[一句话总结,不超过 50 字]
二、关键数据(必填)
| 指标 | 数值 | 变化 | 说明 |
|---|
| [指标1] | [值] | [±X%] | [说明] |
| [指标2] | [值] | [±X%] | [说明] |
三、分析维度(必填)
维度1:[维度名称]
- 数据来源:[CLI命令或API]
- 关键发现:[具体发现]
- 数据支撑:[引用具体数据]
维度2:[维度名称]
- 数据来源:[CLI命令或API]
- 关键发现:[具体发现]
- 数据支撑:[引用具体数据]
四、投资建议(必填)
[根据分析结果给出的建议]
五、历史对比(可选,精简输出)
[与历史数据的对比分析]
六、后续关注点(可选,精简输出)
[需要持续关注的指标或事件]
七、风险提示(可选,精简输出)
免责声明:本报告使用大虾皮(daxiapi.com)数据 + AI 生成,仅供参考,不构成投资建议。
Quality Checks(质量检查)
Red Flags(危险信号)
数据层面:
| 危险信号 | 说明 | 处理方式 |
|---|
| 🔴 数据缺失 | 关键数据无法获取 | 明确说明数据缺失,尝试替代数据源 |
| 🔴 数据异常 | 数据明显不合理 | 交叉验证,确认数据准确性,注意恐贪指数、估值数据等数据需要再交易日晚8点之后更新 |
| 🔴 数据过期 | 数据更新时间过久 | 提醒用户数据可能不反映最新情况 |
分析层面:
| 危险信号 | 说明 | 处理方式 |
|---|
| 🔴 结论矛盾 | 不同维度结论相互矛盾 | 重新分析,找出矛盾原因 |
| 🔴 缺少数据支撑 | 结论没有具体数据 | 补充数据或修改结论 |
| 🔴 过度预测 | 对未来做出确定性预测 | 改为情景分析或概率判断 |
风险层面:
| 危险信号 | 说明 | 处理方式 |
|---|
| 🔴 风险提示缺失 | 未包含风险提示 | 强制添加至少 1 条风险提示 |
| 🔴 风险提示泛泛 | 风险提示不具体 | 提供具体的风险场景 |
| 🔴 单一观点 | 只考虑一种可能性 | 补充其他可能性分析 |
Verification(验证要求)
必须验证:
建议验证:
Common Pitfalls(常见陷阱)
数据陷阱
陷阱 1:数据时间不一致
- 问题:使用不同时间点的数据进行对比
- 后果:结论错误,误导投资决策
- 避免方法:确保所有数据时间点一致,标注数据时间
陷阱 2:数据单位混淆
- 问题:混淆百分比和小数(如 0.05 和 5%)
- 后果:数据理解错误,结论偏差
- 避免方法:明确数据单位,统一格式
陷阱 3:幸存者偏差
- 问题:只分析现存股票,忽略已退市股票
- 后果:高估历史表现,低估风险
- 避免方法:说明数据范围,提示可能的偏差
分析陷阱
陷阱 4:过度拟合
- 问题:从历史数据中找出不存在的规律
- 后果:预测失败,投资亏损
- 避免方法:承认随机性,避免过度解读
陷阱 5:后视镜效应
- 问题:用现在的情况解释过去的事件
- 后果:高估自己的判断能力
- 避免方法:站在当时的时间点思考
陷阱 6:确认偏误
- 问题:只寻找支持预设结论的证据
- 后果:忽视风险,决策失误
- 避免方法:主动寻找反例,平衡观点
表达陷阱
陷阱 7:绝对化表述
- 问题:使用"一定"、"必然"、"肯定"等词
- 后果:误导用户,违反合规要求
- 避免方法:使用"可能"、"大概率"、"或许"等词
陷阱 8:贬低性表述
- 问题:使用"韭菜"、"散户"等贬义词汇
- 后果:不尊重用户,违反职业道德
- 避免方法:使用中性表述,尊重所有投资者
陷阱 9:预测性表述
- 问题:对股价走势做出确定性预测
- 后果:误导用户,违反合规要求
- 避免方法:改为情景分析或概率判断
Key Principles(重要原则)
合规原则
-
风险提示优先
- 每份报告必须包含风险提示
- 风险提示必须具体而非泛泛而谈
- 不预测股价走势
-
免责声明
- 所有报告必须包含免责声明
- 明确说明"仅供参考,不构成投资建议"
- 标注数据来源和生成方式
-
中性表述
- 不使用贬低性词汇(如"韭菜")
- 不使用绝对化表述(如"一定"、"必然")
- 尊重所有投资者
分析原则
-
结论先行
-
数据驱动
- 所有结论基于数据
- 标注数据来源和时间
- 说明数据局限性
-
多维度分析
- 至少分析 2-3 个维度
- 不同维度相互印证
- 避免单一视角
表达原则
-
逻辑清晰
-
诚实透明
-
用户友好
- 使用通俗易懂的语言
- 避免过度专业术语
- 提供必要的名词解释
Error Handling(错误处理)
数据错误处理
错误 1:数据缺失
场景:关键数据无法获取
处理方式:
- 尝试替代数据源
- 在报告中明确说明数据缺失
- 使用其他可用数据进行分析
- 提示用户数据可能不完整
示例:
⚠️ 数据缺失说明:
- 涨停数据暂时无法获取
- 已使用涨幅数据替代
- 分析结果可能存在偏差
错误 2:数据异常
场景:数据明显不合理(如涨幅超过 20%)
处理方式:
- 交叉验证数据准确性
- 检查数据单位是否正确
- 在报告中标注异常数据
- 提供可能的原因分析
示例:
⚠️ 数据异常提示:
- 某股票涨幅显示 50%(异常高)
- 已核实:该股票为新股上市首日
- 已在分析中剔除该股票
错误 3:数据延迟
场景:数据更新时间过久
处理方式:
- 检查数据更新时间
- 在报告中标注数据时效性
- 提醒用户数据可能不反映最新情况
- 建议用户稍后重试
示例:
⚠️ 数据时效性提示:
- 数据更新时间:2025-01-15 09:30
- 当前时间:2025-01-15 14:30
- 数据可能不反映最新市场情况
分析错误处理
错误 4:分析维度不足
场景:无法完成推荐的分析维度
处理方式:
- 至少完成 2 个维度的分析
- 在报告中说明未完成的原因
- 提供替代分析方案
- 提示用户分析可能不全面
示例:
⚠️ 分析范围说明:
- 由于数据限制,仅完成 2 个维度的分析
- 未包含:板块轮动分析
- 建议:结合其他数据源进行补充分析
错误 5:结论矛盾
场景:不同维度的结论相互矛盾
处理方式:
- 重新分析矛盾的数据
- 找出矛盾的原因
- 在报告中说明矛盾情况
- 提供平衡的观点
示例:
⚠️ 结论矛盾说明:
- 指数表现:市场整体上涨
- 市场温度:市场情绪低迷
- 分析:指数上涨但情绪低迷,可能存在分化
- 建议:关注结构性机会,注意风险
技术错误处理
错误 6:API 调用失败
场景:API 返回错误码
常见错误码:
| 错误码 | 说明 | 处理方式 |
|---|
| 401 | 认证失败 | 检查 Token 配置 |
| 404 | API 不存在 | 检查命令拼写 |
| 429 | 请求频率超限 | 等待后重试 |
| 500 | 服务器错误 | 稍后重试 |
| 返回空数据或数据日期过旧(非交易日/更新延迟) | - | 先向用户说明数据时效限制,建议在收盘后再查询 |
处理流程:
- 根据错误码判断错误类型
- 执行相应的解决方案
- 重试操作
- 如无法解决,向用户说明
错误 7:网络连接失败
场景:无法连接到 API 服务器
处理方式:
- 检查网络连接
- 使用代理或 VPN
- 检查防火墙设置
- 向用户说明情况
示例:
⚠️ 网络连接失败:
- 无法连接到 daxiapi.com
- 请检查网络连接或使用代理
- 如问题持续,请联系技术支持
错误报告格式
当遇到无法解决的错误时,向用户报告:
## ⚠️ 分析过程中遇到问题
**错误类型**:[错误类型]
**错误描述**:[具体描述]
**影响范围**:[哪些分析受影响]
**已尝试的解决方案**:
1. [方案1]
2. [方案2]
**建议**:
- [建议1]
- [建议2]
**可用的分析结果**:
- [已完成的分析]
目录结构
<skill-name>/
├── SKILL.md # 主文件(必需)
├── references/ # 参考文档目录(推荐)
│ ├── cli-commands.md # CLI 命令参考
│ ├── api-reference.md # API 参考文档
│ ├── token-setup.md # Token 配置指南
│ └── field-descriptions.md # 字段说明和名词解释
├── scripts/ # 可执行脚本目录(可选)
│ └── <script-name>.sh # 脚本文件
└── assets/ # 静态资源目录(可选)
├── example-output.md # 输出示例
└── template.md # 模板文件
目录职责
| 目录/文件 | 职责 | 是否必需 | 说明 |
|---|
SKILL.md | Skill 主文件 | ✅ 必需 | 包含核心流程和关键信息 |
references/ | 参考文档 | ⭐ 推荐 | 存放详细的技术文档 |
scripts/ | 可执行脚本 | ⚪ 可选 | 存放自动化脚本 |
assets/ | 静态资源 | ⚪ 可选 | 存放模板、示例等 |
创建新 Skill 的步骤
步骤 1:规划 Skill
- 确定功能:明确 Skill 的核心功能
- 定义触发词:列出用户可能使用的触发词
- 设计流程:规划数据获取、处理、分析的流程
- 收集错误案例:整理常见的错误和解决方案
步骤 2:创建目录结构
mkdir -p skills/<skill-name>
mkdir -p skills/<skill-name>/{references,scripts,assets}
touch skills/<skill-name>/SKILL.md
touch skills/<skill-name>/references/cli-commands.md
touch skills/<skill-name>/references/api-reference.md
touch skills/<skill-name>/references/token-setup.md
touch skills/<skill-name>/references/field-descriptions.md
步骤 3:编写 SKILL.md
- 复制上述完整模版
- 填写 YAML Frontmatter
- 编写"Overview"部分(1-2 句话)
- 编写"When to Use"部分(简洁列表)
- 编写"Process"部分(核心内容)
- 编写"Report Template"部分(输出标准)
- 简化其他部分(精简要点)
步骤 4:编写 references/ 文件
- 编写
cli-commands.md:详细命令说明
- 编写
api-reference.md:API 参数和返回值
- 编写
token-setup.md:完整配置指南
- 编写
field-descriptions.md:名词解释
步骤 5:测试和验证
- 功能测试:测试所有功能是否正常
- 错误测试:测试错误处理是否完善
- 质量检查:使用 Quality Checks 清单验证
最佳实践
DO ✅
- Process 优先:流程主体是核心,投入最多精力
- Report 标准化:报告模版确保输出一致
- 外联详细内容:详细文档放在 references/
- 精简次要内容:Quality Checks、Common Pitfalls 等精简要点
- 质量优先于速度:宁可晚一点也要准确
DON'T ❌
- 过度冗长:避免不必要的详细说明
- 缺少流程:Process 是核心,不能省略
- 缺少报告模版:输出标准化很重要
- 违反合规:必须包含风险提示和免责声明
- 绝对化表述:避免"一定"、"必然"等词
相关文档