Merge pull request #864 from juestchaos/main

更新

02-知识管理基础/知识管理.md

@@ -7,7 +7,7 @@ author: PKMer
 type: awesome
 draft: false
 editable: true
-modified: 20240815121421
+modified: 20240922160046
 ---
 
 # 知识管理
@@ -93,6 +93,7 @@ modified: 20240815121421
 		- [[PARA信息组织法]]
 		- [[关于附件的思考]]
 		- [[如何精准表达]]
+		- [[文件命名规范浅谈]]
 - T
 	- Terry
 		- [[从企业管理角度看待笔记方法]]：从企业管理角度看待笔记方法，认为没有一种笔记组织方式可以解决所有的问题

02-知识管理基础/知识管理圆桌讨论/OS/文件命名规范浅谈.md

@@ -0,0 +1,95 @@
+---
+uid: 20240922151533
+title: 文件命名规范浅谈
+tags: [文件管理]
+description: 文件命名规范浅谈
+author: OS
+type: other
+draft: false
+editable: false
+modified: 20240922165154
+---
+
+# 文件命名规范浅谈
+
+## 概述
+
+正确来说，本来这篇文章是要说明，笔记命名的问题，但是考虑到，笔记长短，是否原子化都有很多不同用法和争议。所以为了避免争议，干脆扩大到了一个比较讨论泛泛的问题，什么是好文件夹和文件命名规范。
+
+当然“各村有各村高招”，不同专业，不同工作类型，也许都会形成一些自己关注信息，并提炼出一套自己的整理体系。当然也有很多软件工具来管理文件和文件夹，本篇文章不会着重讨论这些工具软件的使用。
+
+## 命名文件夹、文档的核心
+
+1. 结构一致性
+	- 原则：保持文档命名结构的一致性
+	- 检验标准：你通过【名字】可以轻松寻找和区别你要的版本和文件
+	- 使用一致的、特定的命名规则，如文件标题内容表 + 版本号 + 日期 + 时间等。
+	- 也许因为你职业需要，还要加入一些编码参数：比如地点 POI、视频文件的编码等
+		- 正常：The Angry Birds Movie 720p.BlueRay
+		- 反例：新建 word 文档、新建 PPT
+2. 可读性高
+	- 原则：文档命名要保持清晰明了、简洁直观的原则
+	- 检验标准：除非需要保密，做到可以准确地描述、定位文档的主要内容
+		- 比如文档状态，文档
+		- 比如你的业务跟合同有关，那么一定要体现 跟谁的合同，什么时候的时间版本等信息
+		- 比如你的内容跟城市和销售有关，可能有时候你还要加上地域信息：北京、上海等
+	- 应该避免使用含糊不清的语句来命名，也要避免过长的文字表达
+		- 反例：新建文件夹 1、新建文件夹 2
+3. 规则排序性
+	- 可使用日期、版本号、时间等带有数字的命名结尾，便于文档排序管理，也方便用户按需进查找。
+	- 这个编码方式可以参考 [[Johnny-Decimal-源于数字编码的管理系统]] 或者杜威十进制，当然也包含 [[PARA信息组织法]] 等方式，这里不做赘述。
+
+## 理解命名的元数据
+
+了解下 元数据 ，元数据你可以理解成，就是一个孤立定义的参数。代表你文件的某一类属性，可以单一存在，也可以通过多个元数据，更具体的标明你的文件和文件夹
+
+| 元数据  | 定义                                                           | 示例                     |
+| ---- | ------------------------------------------------------------ | ---------------------- |
+| 版本号  | 用于跟踪版本稀碎的利器，不到担心这个命名的繁琐，当版本混乱多人协作的时候，同一天和同一时间内多个版本，需要短期留档的利器 | 主版本号、此版本号，或者使用时间版本号    |
+| 文档用途 | 表达文档定位，注意可读性原则                                               | 如 xx 立项、xx 分析报告、xx 数据分析表 |
+| 修改时间 | 这个有时候会和版本信息连用，作为版本号最后一段                                      |                        |
+| from | 我个人比较喜欢用这个来表示文档来源，尤其是当多人一起编写大型文档的时候                          |                        |
+| 文档状态 | 这十分适合需要长期编写文档时候，区分中间版本和最终版本，你可以简单在最终版上打上这个标记                 |                        |
+| 文档参数 | 比如视频工作者可能还需要对 影视作品的日期，编码格式，等进行处理                             |                        |
+
+上面只是一些通用化的举例，如果你从事的是一些专业档案、素材、剪辑等管理工作，那么命名方式可能会更复杂写。
+
+比如
+
+根据摄制组和剪辑部门对素材的处理方式
+
+| filename      | **20180901-btl-X-flie-interview-01-lv-001** |
+| ------------- | ------------------------------------------- |
+| shoot date    | **20180901**-btl-X-flie-interview-01-lv-001 |
+| project id    | 20180901-**btl**-X-flie-interview-01-lv-001 |
+| subject name  | 20180901-btl-**X-flie**-interview-01-lv-001 |
+| shoot         | 20180901-btl-X-flie-**interview**-01-lv-001 |
+| camera number | 20180901-btl-X-flie-interview-**01**-lv-001 |
+| audio         | 20180901-btl-X-flie-interview-01-**lv-**001 |
+| clip number   | 20180901-btl-X-flie-interview-01-lv-**001** |
+
+许多国际大厂，对数字发行有着非常统一的命名规范，你可以了解到有 DCI 和 ISO/TC36，这些统一化对组织协调非常重要。这个文件的目的是 " 让所有协同者对文件名的元素构成有一个正确统一的理解 "，当然这里的协同者，可能也包括未来的你自己。
+
+## 一些使用文件夹和文档技巧
+
+- 接受冗余
+	- 比如我经常进行 文档输出工作，这些工作显然不是每次都是全新的，一定有一部分继承于或者来自于其他历史文件，所以我经常会在当前输出时：
+		- 优先建立一个文件夹【工程文件夹】
+		- 命名这个文件夹的目的，也遵循前面的规则
+		- 在【工程文件夹】下建立参考文件文件夹，这一步有助于我快速在当前目录完成所有操作。
+	- 虽然这个操作会产生一些冗余，但：
+		- 对应的数据和参考修改时，不会影响到原始文件，比如不能外露的数据，比如需要修改原始数据表格到其他输出样式
+		- 现在硬盘和容量还是比较便宜，所以接受一定冗余，还是比较容易的
+		- 超过一定时间后的文档，因为有临时文件夹和冗余文件夹的存在，反而删除变得很容易
+- 统一编码
+	- 比如输出文件编码都是 01
+	- 比如外部进入的文件都是 02
+	- 比如所有的参考文件都是 03
+	- 这样只要看到文档序号或者文件夹序号你就可以知道这是哪个项目的用途
+
+## 小结
+
+- 没有完美的命名方法
+- 命名必然会增加日常文档维护的工作量，是个需要检查，和成为习惯的事情，不会一蹴而，但是养成好习惯，会有很多好处
+- 不用非要遵循某个大神的方法，寻找自己，适合自己的就好
+- 理解元数据这个概念，有助于你了解和结构化很多思考方式