- 将wikillm技能移动到skills/wikillm/目录 - 添加详细的技能参考文档(workflows.md, qa.md, standards.md, errors.md) - 更新README中的参考资料列表 - 添加Harness Engineering相关的图片和查询 - 更新wiki索引
145 lines
5.9 KiB
Markdown
145 lines
5.9 KiB
Markdown
# 编译工作流详细指南
|
||
|
||
## 增量编译检查清单
|
||
|
||
- [ ] **扫描检查**:运行扫描,检查 `raw/` 目录中是否有新增或修改的文件
|
||
- [ ] **哈希对比**:与 `compile-results.tsv` 中的记录对比,确认变更
|
||
- [ ] **日志记录**:将检查过程写入 `compile.log`
|
||
- [ ] **只编译变更**:仅处理新增或修改的文件
|
||
- [ ] **更新 frontmatter**:确保新编译的 wiki 文档包含 `raw_sources`
|
||
- [ ] **更新状态文件**:追加/更新 `compile-results.tsv` 中的记录
|
||
- [ ] **更新来源索引**:更新 `sources.md`,添加本次新增的来源
|
||
|
||
## 阶段 0:增量检查
|
||
|
||
**任务**:检查 `raw/` 目录下哪些文件需要编译。
|
||
|
||
**步骤**:
|
||
1. 读取 `wiki/compile-results.tsv`,获取已编译文件的哈希记录
|
||
2. 遍历 `raw/` 目录,计算每个文件的 SHA-256 哈希
|
||
3. 对比哈希值,识别:
|
||
- **新增文件**:在 `compile-results.tsv` 中不存在的文件
|
||
- **修改文件**:哈希值与记录不同的文件
|
||
- **未修改文件**:哈希值相同的文件(跳过编译)
|
||
4. 将检查过程写入 `wiki/compile.log`
|
||
|
||
## 阶段 0.5:资源同步
|
||
|
||
**任务**:将 `raw/images/` 下的所有图片资源同步到 `wiki/assets/`。
|
||
|
||
**同步范围**:所有图像文件,包括但不限于:
|
||
- `png`, `jpg`, `jpeg`, `gif`, `webp`, `svg`
|
||
|
||
**同步方式**:
|
||
- 使用 `cp -r raw/images/* wiki/assets/` 进行完整同步
|
||
- `raw/images/` 是权威来源,同名文件直接覆盖
|
||
- 保留原始文件名(包括空格和特殊字符)
|
||
|
||
**验证**:确保 `wiki/assets/` 包含 `raw/images/` 中的所有文件
|
||
|
||
**时机**:每次编译前必须执行此步骤
|
||
|
||
## 阶段 1:多模态解构
|
||
|
||
**任务**:解析 `raw/` 目录下的新增或修改内容。
|
||
|
||
### 大文档完整阅读要求
|
||
|
||
对于篇幅较长的文档(学术论文、长篇技术文章),必须完整阅读和分析:
|
||
|
||
1. **完整内容获取**:
|
||
- 使用 Grep 搜索章节标题(如 `^#{1,3} `)了解文档结构
|
||
- 分段读取完整内容,确保覆盖所有主要章节
|
||
- 特别关注:摘要、引言、方法、实验、讨论、结论、附录等核心章节
|
||
|
||
2. **深度分析维度**:
|
||
- **核心论点**:提取文章的主要主张和关键发现
|
||
- **方法细节**:理解技术方案的实现细节和设计决策
|
||
- **实验结果**:完整记录所有实验数据、表格、图表信息
|
||
- **案例研究**:保留具体的定性示例和应用场景
|
||
- **相关工作**:建立与其他研究的联系和对比
|
||
|
||
3. **输出内容标准**:
|
||
- wiki 页面长度应与原文档的重要性和复杂度相匹配
|
||
- 学术论文应包含:摘要、核心方法、完整实验结果、详细讨论
|
||
- 技术文章应包含:问题背景、完整解决方案、实际应用案例
|
||
- 保留所有定量数据(表格、指标、分数等)
|
||
|
||
4. **例外情况**:
|
||
- 仅在以下情况下可生成较短摘要:
|
||
- 文档是纯新闻报道或简短公告
|
||
- 文档主要是代码或配置(无大量叙事内容)
|
||
- 用户明确要求仅生成摘要
|
||
|
||
### 视觉解析
|
||
|
||
对图片进行深度 OCR 与逻辑识别。将架构图转化为文字描述及 **Mermaid** 代码块,存入对应 Wiki 页面。
|
||
|
||
### 元数据提取
|
||
|
||
为每篇文档生成 YAML Frontmatter(包含:`tags`, `source`, `raw_sources`, `confidence_score`, `last_updated`)。
|
||
|
||
`raw_sources` 字段格式:
|
||
```yaml
|
||
raw_sources:
|
||
- path: raw/anthropic-harness-design.md
|
||
hash: "sha256:abc123..."
|
||
```
|
||
|
||
## 阶段 2:增量编译
|
||
|
||
**非线性重构**:不进行 1:1 翻译,而是基于源文档的"核心贡献"进行重写。
|
||
|
||
**中文化增强**:
|
||
- 消除翻译腔:使用行业专业术语(如将 "Agent" 译为 "智能体")
|
||
- 添加上下文:为中文读者补充必要的背景知识或行业对比
|
||
|
||
**可视化输出**:若涉及多步流程或对比,自动生成 **Marp** 格式的幻灯片文件(`.md`),以便在 Obsidian 中演示。
|
||
|
||
## 阶段 3:网络化链接
|
||
|
||
### Wikilink 格式规范
|
||
|
||
- 文件名使用 kebab-case(连字符分隔),例如:`Harness-Engineering.md`
|
||
- Wikilink 格式为 `[[文件名|显示文本]]`,其中**文件名部分必须与实际文件名完全匹配**(不带 .md 扩展名)
|
||
|
||
**正确示例**:`[[Harness-Engineering|Harness 工程]]`(对应文件 `Harness-Engineering.md`)
|
||
|
||
**错误示例**:`[[Harness Engineering|Harness 工程]]`(文件名带空格,不匹配实际文件)
|
||
|
||
### 文章列表格式
|
||
|
||
**错误写法**(表格无法正确解析双链):
|
||
```
|
||
| 文章 | 描述 |
|
||
|------|------|
|
||
| [[Mitchellh-Adoption-Journey|Mitchellh AI 采用之旅]] | HashiCorp 创始人从怀疑论者到深度用户的六个阶段 |
|
||
```
|
||
|
||
**正确写法**(使用无序列表):
|
||
```
|
||
- [[Mitchellh-Adoption-Journey|Mitchellh AI 采用之旅]] - HashiCorp 创始人从怀疑论者到深度用户的六个阶段
|
||
```
|
||
|
||
### 其他链接任务
|
||
|
||
- **双链注入**:全文检索 `Glossary.md` 中的术语,使用 `[[术语名]]` 自动包裹
|
||
- **反向链接**:在文末生成 `## 相关研究` 模块,强制链接到 Wiki 内部至少 2 篇关联文档
|
||
- **动态索引**:根据新增内容,自动更新 `INDEX.md` 中的"最新研究"与"学习路径"部分
|
||
|
||
## 阶段 4:健康检查与维护
|
||
|
||
- **一致性检查**:扫描 `wiki/`,发现术语冲突(如 A 文档叫"智能体",B 文档叫"代理")时,自动统一
|
||
- **孤岛扫描**:识别没有任何链接指向的页面,强制将其挂载到导航树中
|
||
- **补丁发布**:当 `raw/` 有新版本(如论文更新)时,在对应 Wiki 页面顶部发布 `[Update Patch]` 摘要
|
||
|
||
## 阶段 5:来源索引更新
|
||
|
||
**任务**:更新 `wiki/sources.md`,记录本次编译涉及的来源文档。
|
||
|
||
**格式规范**:使用简单无序列表,每项格式为 `- [标题](URL)`
|
||
|
||
**增量更新**:添加本次新增的来源,保持已有来源不变
|
||
|
||
**分类组织**:按"学术论文"、"概念文章"、"实践指南"等类别合理分组
|