📝 贡献你的实战配方
入门 · 10 分钟 · 2026-08-16
DSH Radar 的评分是机器算的,配方(recipes)是人写的。
你踩过的坑、你调好的插件组合,只要 10 分钟就能变成 /recipes 页面上的一张卡片,
帮到下一个遇到同样任务的人。整个流程只需要改一个文件:
data/recipes.json。
1. 什么样的内容算「配方」?
配方不是插件介绍,而是「任务 → 插件组合 → 为什么这么搭」的三段式经验。 判断标准很简单:如果只装一个插件、看 README 就能搞定,那不是配方; 如果你花了半天时间试错才把 2-4 个插件串起来,那就是好配方。
- ✅ 「自动研究循环」= modsearch 搜索 + llm-auto-route 切模型省 token
- ✅ 「生产部署 4 道防线」= 审计 → 沙箱 → 验证回执 → 失败回滚
- ❌ 「xxx 插件很好用」——这属于评分维度,交给雷达算
2. recipes.json 字段说明
data/recipes.json 是一个纯数组,每个元素就是一条配方。字段一共 9 个,全部必填:
| 字段 | 类型 | 说明 |
|---|---|---|
id | string | 唯一 slug,小写连字符,如 ppt-from-prompt。作为锚点用,不要改已有的 |
title | string | 配方标题,10-20 字,动词开头最好读 |
task | string | 解决的具体任务,一句话说清输入和输出 |
plugins | string[] | 用到的插件包名数组,必须是 npm 上真实存在的包名 |
why | string | 为什么这么组合,最有价值的一段,写清楚技术原因 |
tip | string | 额外的调优建议 / 搭配建议 / 避坑提醒 |
submitted_by | string | 你的 GitHub 用户名(不带 @) |
submitted_at | string | 提交日期,YYYY-MM-DD 格式 |
likes | number | 新提交一律填 0,由社区后续累加 |
⚠️ 两个硬要求
plugins 里的包名会被前端拿去关联插件详情页,拼错就是死链;
id 全局唯一,重复会导致 Astro 渲染时 key 冲突。提交前自己搜一遍。
3. 完整示例
把你的条目追加到数组末尾(注意给上一条补逗号),格式照抄这个:
{
"id": "changelog-digest",
"title": "每周依赖变更摘要",
"task": "扫描 lockfile 变更,自动生成人类可读的升级摘要",
"plugins": ["@liustack/modsearch", "dsh-plugin-review"],
"why": "modsearch 负责拉取每个包的 release notes,review 插件把 diff 归类成 breaking / feature / fix 三档,避免人工翻 20 个 changelog",
"tip": "在 CI 里跑,把输出贴到 PR 评论;配合 dsh-llm-auto-route 用小模型做摘要,成本降到 1/5",
"submitted_by": "your-github-name",
"submitted_at": "2026-08-16",
"likes": 0
} 改完先本地校验 JSON 合法性,一个多余的逗号就会让整站 build 失败:
# 校验 JSON 语法
node -e "JSON.parse(require('fs').readFileSync('data/recipes.json','utf8'))" && echo "✅ JSON OK"
# 本地预览效果
cd web && pnpm install && pnpm dev
# 打开 http://localhost:4321/recipes 看看你的卡片 4. 提交流程:fork → 编辑 → PR
DSH Radar 是 MIT 开源、零追踪的项目,任何人都能改。三步走:
# ① Fork 后克隆你自己的副本
git clone https://github.com/<你的用户名>/dsh-radar.git
cd dsh-radar
git remote add upstream https://github.com/dsh-radar/dsh-radar.git
# ② 开分支 + 编辑
git checkout -b recipe/changelog-digest
$EDITOR data/recipes.json
# ③ 提交 + 推送
git add data/recipes.json
git commit -m "recipe: 每周依赖变更摘要"
git push origin recipe/changelog-digest
推送完 GitHub 会提示 “Compare & pull request”,点进去填 PR 描述即可。
只改 data/recipes.json 的 PR 不需要跑 build-data.mjs,
配方数据不参与评分计算,CI 只会校验 JSON 格式。
5. PR 模板
标题统一用 recipe: 配方标题 前缀,维护者靠这个前缀做快速分流:
标题:recipe: 每周依赖变更摘要
--- 描述 ---
## 配方 ID
changelog-digest
## 解决什么问题
每周升级依赖时要手翻十几个 changelog,容易漏掉 breaking change。
## 用到的插件
- @liustack/modsearch — 拉 release notes
- dsh-plugin-review — diff 归类
## 我真的跑过吗
是。在自己的 monorepo 上连续跑了 3 周,每周约 40 个包,
误报 2 次(都是 pre-release tag 造成的),已在 tip 里写了规避方法。
## Checklist
- [x] id 全局唯一,未与现有条目重复
- [x] plugins 里的包名在 npm 上真实存在
- [x] likes 填 0
- [x] node -e JSON.parse 校验通过
- [x] 本地 /recipes 页面预览正常 ✅ 合并标准
维护者只看三件事:JSON 合法、包名真实、你真的跑过。 没跑过的「理论组合」会被要求补证据,不会直接关掉。一般 48 小时内有回应。