Production Workflow制作流程 · Guide指南
How to Name Files for a Moving Project
A durable filename makes a file’s role, scope, and revision legible before someone opens it.
Key takeaways核心要点
- Put stable identifiers before changing status labels in a filename.
- Use revision numbers for changes and dates only when they answer a retrieval need.
- Reserve final for an approved deliverable, not a hopeful working file.
File names are a small interface between people. When a project moves quickly, a filename is often the first thing a producer, editor, or collaborator sees. If it hides the project, asset, version, and intended use, the team must open several files or ask a question that the name could have answered.
The purpose of a naming convention is retrieval and safe choice, not visual tidiness. A good convention helps someone select the right cut from a crowded folder without relying on personal memory. It also leaves enough room for real work to change.
Put stable facts first
Begin with the identifier least likely to change: a project code or concise project name. Follow it with the asset or sequence name, then a useful scope label. For example, northline_ep01_opening_edit tells a collaborator more than new_video. Keep words short, use one separator consistently, and avoid characters that create problems across tools.
Add a version marker whenever the contents may change while the purpose remains the same. v01, v02, and v03 sort reliably and make revision order visible. A date can be helpful for a daily export or an incoming source batch, but it should not replace a version number; dates answer when, while versions answer which iteration.
Imagine an unpublished practice project with a vertical cut, a square social excerpt, and a subtitle file. A stable root such as harbor_story can join them, while vertical_v03, square_v01, and en-captions_v02 keep their functions distinct. A reviewer can identify the intended asset before opening a single file.
Separate status from revision
Status labels deserve restraint. Terms like draft, review, approved, and deliverable tell people what they may do with a file; they should not be used interchangeably with version numbers. review_v04 can invite comments, while approved_v04 says that same revision has passed a defined decision gate.
Avoid attaching final to every late-stage export. Once final-final-revised appears, the label no longer protects anyone. Reserve deliverable for the asset that meets a named delivery requirement, and archive prior versions rather than overwriting them. If a deliverable changes, increment the version and note why in the accompanying record.
For files that are alternatives rather than linear revisions, name the branch. opening_A_v02 and opening_B_v02 preserve a meaningful choice that opening_v05 conceals. The distinction matters at review time: the team is comparing two editorial approaches, not simply choosing the newer timestamp.
Make the convention easy to apply
Write the convention on the project board with two or three examples. A rule people cannot recall will be replaced by improvisation. Let folder structure carry information that every filename need not repeat, such as a shared project name, but do not rely on folders alone when files may be downloaded or forwarded.
Check collision risks before adopting a pattern. Two sequences may share an informal nickname; a contractor may use a different date order; a platform may truncate long names. Test the names in the places the project actually uses: storage, review links, exports, and delivery packages.
The trade-off is precision against speed. A seven-part filename can be burdensome, while a one-word filename is fragile. Choose the smallest pattern that lets a new person identify what the file is, which revision it is, and whether it is safe to use. That is enough structure for a moving project.