|
|
@@ -7,7 +7,9 @@ description: "Use this skill to research Pali Buddhist texts with WikiPali's cor
|
|
|
|
|
|
用 WikiPali 的语料做巴利文献研究：定位 → 取证 → 展开 → 交叉验证 → 成文。
|
|
|
|
|
|
-命令是 `wikipali <子命令>`（插件启用时已在 PATH 上）。检索与阅读全部只读，**不需要登录**。
|
|
|
+命令是 `wikipali <子命令>`。检索与阅读全部只读，**不需要登录**。
|
|
|
+
|
|
|
+⚠ **刚装好或刚更新插件时，`wikipali` 可能还不在 PATH 上**——PATH 注入在会话启动时完成，装完要重启会话。若 `command -v wikipali` 为空，改用绝对路径 `${CLAUDE_PLUGIN_ROOT}/bin/wikipali`，并提醒用户重启会话。
|
|
|
|
|
|
**坐标、引用格式、文献层次、译文来源判定见 `references/conventions.md`——那是所有
|
|
|
skill 共用的规矩，必须遵守。** 端点细节见 `references/api-read.md`。
|
|
|
@@ -66,9 +68,51 @@ wikipali search --lemma parivāsa --limit 50
|
|
|
结果按黑体加权排序，**注释书里作为词条解释的段落会自然排在前面**。从前 50 条里挑出
|
|
|
讲定义和执行流程的，用来写定义部分。
|
|
|
|
|
|
+**前几名全是 aṭṭhakathā / ṭīkā 是正常的，不是检索出了问题。** 大部分名词解释在义注
|
|
|
+（aṭṭhakathā）与复注（ṭīkā）里，律藏的根本（pāḷi / mūla）中也有部分解释。
|
|
|
+
|
|
|
+所以：不必因为看不到本文命中就怀疑检索出了错；但也**不要断定本文没有解释**——本文
|
|
|
+里的那部分同样要引，按铁律 4 标明层次。
|
|
|
+
|
|
|
命中总量特别大、前 50 条噪声明显时，可以加 `--bold` 只看黑体命中来收窄——那是收窄
|
|
|
手段，不是默认做法，因为不加黑体的定义段落会被它漏掉。
|
|
|
|
|
|
+### 3b. 留意注疏有没有枚举子类
|
|
|
+
|
|
|
+注疏解释术语时常会枚举它的子类（`catubbidho X`、`duvidho X` 这类体例很常见，但**不是
|
|
|
+每个词都有**）。读定义段落时**留意有没有**这种枚举——有，它就是现成的分类框架，比自己
|
|
|
+归纳可靠；没有就跳过，**不要硬造分类**。
|
|
|
+
|
|
|
+**发现子类后，每一个都要单独再查一遍，不得凭名字推测含义。** 巴利复合词看起来像是
|
|
|
+可以拆开理解的（`paṭicchanna-parivāsa` 像"覆藏＋别住"），而这种推测正是编造释义的
|
|
|
+入口——构词法给的是字面拼合，不是该词在律学里的实际所指。
|
|
|
+
|
|
|
+每个子类走一遍完整链路：
|
|
|
+
|
|
|
+```bash
|
|
|
+wikipali forms samodhānaparivāsa # 词形与频次
|
|
|
+wikipali search --lemma samodhānaparivāsa --limit 20 # 找它自己的解释段落
|
|
|
+wikipali get <坐标> # 取原文
|
|
|
+```
|
|
|
+
|
|
|
+**拿到注疏对该子类的解释原文之前，不要写出它的含义。** 查不到解释就如实说"语料中
|
|
|
+未见对该子类的解释"，不要用构词法去补——这是铁律 1 在子类上的具体化。
|
|
|
+
|
|
|
+**两个实测踩到的陷阱：**
|
|
|
+
|
|
|
+- **不同注疏的枚举可能不一样。** 实测 `parivāsa`：Pācityādiyojanā（202:1882）与
|
|
|
+ Kaṅkhāvitaraṇī-abhinavaṭīkā（212:1134）都说"四种"，但列出的**不是同一组**——后者
|
|
|
+ 含 `suddhantaparivāsa`（语料中 86 次），前者没有。所以**不要把某一处的列表当成
|
|
|
+ 「标准分类」**：按出处分别记录，各家不一致就如实说明不一致。这本身往往是论文里
|
|
|
+ 值得写的一笔。
|
|
|
+- **子类可能还有子类。** `samodhānaparivāsa` 自己又分三种（odhāna / aggha /
|
|
|
+ missaka，见 141:120）。要挖多深由研究问题决定，不必无限递归，但要说明你停在了
|
|
|
+ 哪一层。
|
|
|
+
|
|
|
+频次**只报数字，不从中下判断**。例如 `parivāsa` 的四个子类：samodhāna 260 次、
|
|
|
+paṭicchanna 29、titthiya 18、appaṭicchanna 14。把这组数字连同出处交给用户即可——高频
|
|
|
+可能只是某部注疏反复提及，不等于该子类更重要，这个判断该由研究者做。
|
|
|
+
|
|
|
### 4. 取案例：全量检索
|
|
|
|
|
|
```bash
|
|
|
@@ -78,6 +122,10 @@ wikipali search --lemma parivāsa --tags vinaya --limit 200
|
|
|
每条给出坐标、章节路径和高亮片段。**先用片段做初筛**，判断该段落属不属于目标案例
|
|
|
类型，不要一上来就把每段全文取回来。
|
|
|
|
|
|
+**这一步要有意识地回到本文（mūla）。** 与定义相反，案例——谁、在什么情况下、如何
|
|
|
+执行、判定结果如何——在律藏本文里，注疏是对这些案例的解释。用 `dist` 输出里本文那
|
|
|
+几部书的 `--book` 值收窄，别让注疏的高命中密度把本文案例挤出视野。
|
|
|
+
|
|
|
### 5. 取原文
|
|
|
|
|
|
```bash
|
|
|
@@ -125,7 +173,8 @@ wikipali get 216:35 216:36 216:41
|
|
|
| 现象 | 真正的原因 |
|
|
|
|---|---|
|
|
|
| 检索 0 条 | 多半是没展开词形，用了词典形 |
|
|
|
-| 结果全是义注、没有本文 | 正常——注释书解释术语的密度本来就高。用 `dist` 的层次汇总确认，别当成 bug |
|
|
|
+| 查定义时结果全是义注、复注 | 正常，大部分名词解释在注疏里。但本文中也有部分解释，别据此断定本文没有 |
|
|
|
+| 查案例时找不到本文 | 这才是问题。用 `dist` 的 `--book` 值收窄到 mūla 再搜 |
|
|
|
| 某段落取不到译文 | 该 channel 在该段落没有内容。如实报告 |
|
|
|
| 想按短语检索 | 平台的词组检索目前不可用（服务端 500）。把短语拆成词，分别展开词形再检索 |
|
|
|
| `get` 报 500 | 忘了 channel。`get` 缺省会带巴利原文的 channel，若你手动传了参数要确保 channel 在内 |
|
visuddhinanda