66 lines
2.0 KiB
Markdown
66 lines
2.0 KiB
Markdown
|
---
|
|||
|
|
tags: [config, agent, policy]
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# Claude 操作规范
|
|||
|
|
|
|||
|
|
## 通用原则
|
|||
|
|
|
|||
|
|
1. **遵循现有结构**: 严格遵循项目中已有的文件结构和格式
|
|||
|
|
2. **安全第一**: 在修改任何文件前都必须先读取，维护现有的内容和结构
|
|||
|
|
3. **清晰性**: 所有操作必须清晰、可理解，避免混乱或不明确的变更
|
|||
|
|
|
|||
|
|
## 内容创作规范
|
|||
|
|
|
|||
|
|
1. **结构**:
|
|||
|
|
- 优先使用 Markdown 标题格式
|
|||
|
|
- 保持一致的段落结构
|
|||
|
|
- 合理使用列表来组织信息
|
|||
|
|
|
|||
|
|
2. **标签**:
|
|||
|
|
- 使用 YAML frontmatter 包含适当的标签
|
|||
|
|
- 标签必须是数组形式 `tags: [tag1, tag2]`
|
|||
|
|
- 尽可能使用相关领域的标签
|
|||
|
|
|
|||
|
|
3. **链接**:
|
|||
|
|
- 内部链接使用 Wiki-links: `[[note-name]]`
|
|||
|
|
- 外部链接使用标准 Markdown 格式: `[text](url)`
|
|||
|
|
- 确保所有内部链接都指向实际存在的文件
|
|||
|
|
|
|||
|
|
4. **内容质量**:
|
|||
|
|
- 避免使用占位文本，如 "[内容]"、"[描述]" 等
|
|||
|
|
- 保持写作风格一致和专业
|
|||
|
|
- 根据内容添加相关图表或 Mermaid 图表
|
|||
|
|
|
|||
|
|
## 文件和路径规范
|
|||
|
|
|
|||
|
|
1. **路径使用**:
|
|||
|
|
- 仅使用相对路径进行文件访问
|
|||
|
|
- 路径不应包含绝对路径（如 `/home/...`）
|
|||
|
|
|
|||
|
|
2. **文件操作**:
|
|||
|
|
- 不应在 Vault 内创建 README.md、*.md 等文档文件
|
|||
|
|
- 创建新文件时，应遵循现有的文件结构规范
|
|||
|
|
|
|||
|
|
## Git 和版本控制
|
|||
|
|
|
|||
|
|
1. **提交操作**:
|
|||
|
|
- 不应自动执行任何 Git 提交或推送操作
|
|||
|
|
- 如需执行 Git 相关操作，必须让用户明确授权
|
|||
|
|
|
|||
|
|
2. **变更检查**:
|
|||
|
|
- 检查文件变更以维护链接一致性
|
|||
|
|
- 发现断链时应记录并报告
|
|||
|
|
|
|||
|
|
## 特殊情况处理
|
|||
|
|
|
|||
|
|
1. **知识库层面的处理**:
|
|||
|
|
- 若涉及高层架构、系统设计等内容，应优先根据已有文档进行整理补充
|
|||
|
|
- 不应创造新的结构或模式，而应遵循既有规范
|
|||
|
|
|
|||
|
|
2. **代码实现**:
|
|||
|
|
- 当需要编写代码示例时，优先使用 Go 语言（后端）或 React/TS（前端）
|
|||
|
|
- 所有实现示例应在当前环境中实际可行
|
|||
|
|
|
|||
|
|
3. **数据可视化**:
|
|||
|
|
- 使用 Mermaid 图表，但需确保其正确性和可读性
|