最近把 harmony-next.skills 做了一次工程化升级，目标很明确：
让 AI 助手在 HarmonyOS 开发里“先检索、后生成”，降低幻觉，提升回答可验证性。
项目地址：https://github.com/linhay/harmony-next.skills
技术设计上，我没有走“大上下文全量喂文档”，而是做了渐进式披露检索：
SKILL.md定义检索策略和回答约束KITS.md / TASK_MAP.md做领域收敛（Kit / 任务）INDEX.md / JsEtsAPIReference/INDEX.md做路径级命中- 只打开命中的 1~3 个目标文档取 API 细节
这套链路的核心价值：
- 可追溯：回答能回链到具体文件路径，不是“模型记忆”
- 低噪声：避免把 4000+ 文档一次性塞进上下文
- 可复现：同样查询条件下，命中路径稳定
- 离线可用：无网/内网环境仍能完成 API 查询与开发支持
当前数据规模：
- 共 4,257 份 Markdown（约 50MB）
JsEtsAPIReference4,232 份- 覆盖 ArkTS / ArkUI / NDK
- 以 API 12+ 为主，包含大量 API 12-23 版本标注信息
除了 API 参考，还补了高频工程主题：
- 应用签名、断点调试、模拟器/真机配置
- 独立 CLI 与 CI/CD 调优
- 多端适配与自由流转
- Hypium 自动化测试
- Profiler 性能分析与启动优化
- HAP/HAR/HSP 与 Stage 并发模型
适用场景：
- 想把 HarmonyOS 文档接入 Codex / Claude / Gemini 的团队
- 受网络限制、但要求开发效率和准确性的项目环境
如果你也在做 HarmonyOS + AI 编码助手，欢迎交流你们的检索链路设计和落地效果。
