“最终版”为什么会越来越多。
文件通过聊天、邮件和云盘反复转发后，每个人手里都会形成一份副本。有人修正标题，有人补充数据，还有人只改了格式，于是final、final2和final-new同时出现。名称相似掩盖了内容差异，直到提交前才暴露冲突。
解决方法不是制定更复杂的文件名，而是指定一个正式发布位置。聊天附件用于提醒，邮件用于交付，云端主文件承担持续编辑；三者的角色不能混用。
版本号要回答变化，而不只是排序。
日期和版本号能帮助排序，但真正重要的是修改说明。一次更新应写明增加了什么、删除了什么、是否影响已经完成的批注。若只是修正错字，可以覆盖小版本；若章节顺序或任务要求发生变化，应保留旧版并通知成员重新核对。
对外提交的文件应冻结内容。需要继续讨论时复制为下一轮草稿，不在已经提交的版本上悄悄修改。
手机预览适合确认，不适合承担全部校对。
移动端能快速打开文档，却可能隐藏批注、分页或字体差异。看到内容大致正常后，仍应在最终提交所需的平台检查版面、链接和附件。尤其是表格、脚注与演示文件，手机预览不能替代桌面端验证。
手机端新增的批注也要确认是否已经同步。离线状态下的修改可能在稍后形成冲突副本。
小组需要编辑权与发布权分开。
所有成员都能编辑并不代表所有成员都应发布。编辑者可以提出修改，整合者负责接受、拒绝和解释，提交者负责确认格式与截止时间。角色分开后，成员不必通过覆盖文件来证明自己的意见被看到。
人员离开项目时及时移除权限。长期公开链接会让已经结束的课程资料继续暴露。
引用资料也有版本问题。
网页、统计表和课程说明可能更新。报告中除了链接，还应保留读取日期、文件标题与适用时期。若新资料改变结论，应说明差异；若只是换了页面地址，不必假装研究结果发生变化。
截图只能证明某个时刻看到的内容，无法替代可以复查的原始来源。
建立一个简单的交付检查。
提交前核对主文件位置、文件名称、格式、附件和接收方即可。检查内容应针对当前任务，不需要制作几十行没有判断价值的字段表。
提交完成后保留回执或平台状态，再把工作副本移动到归档目录。这样下次打开项目时，不会误把未提交草稿当成成品。
冲突发生后不要急着覆盖。
先分别保存两个版本，比较发生冲突的段落和修改时间。若两边都包含有效内容，由整合者合并并写出新的版本说明。直接选择“保留最新”可能丢掉另一台设备尚未同步的工作。
解决后在团队中说明原因，例如离线编辑、权限设置或错误发布位置。修正流程比责怪某一位成员更能避免重演。
从文件内容建立差异，而不是依靠颜色。
有人会用红色或粗体表示新内容，但不同软件可能丢失格式，打印后也不容易辨认。真正需要保留的是修改位置、修改原因和决定者。短文可以使用修订模式，表格可以附上变更说明，代码或数据项目则更适合使用版本控制。
每次更新不必写成冗长报告。指出“替换了第二章数据来源，结论未变”或“提交格式从文档改为PDF，需要重新导出”，已经足够让成员判断是否必须处理。
若无法说明版本差异，发布者应先暂停覆盖。模糊更新会迫使所有人重新阅读全文，把组织成本转移给每一位成员。
云端自动保存也会留下冲突。
自动保存减少忘记存档的风险，却不能解决两台离线设备同时修改同一段内容。系统可能生成冲突副本，也可能选择最后上传的版本。成员看到冲突提示时，应立即停止继续编辑，先保存两边内容。
比较时从任务目标出发。若一边修改论点，另一边只调整格式，可以先合并论点再重做格式；两边都改了同一结论，则需要回到证据和会议决定，而不是按时间自动选择。
解决后写一句原因并关闭多余副本。冲突文件长期留在正式目录，会让搜索和分享继续指向错误版本。
外部附件进入项目时先保留原件。
教师、客户或合作单位发来的文件应先以只读原件保存，再建立工作副本。直接在原件上修改，会失去接收时的状态，也让后续无法判断问题来自外部资料还是内部编辑。
工作副本名称写明课程、主题和接收日期。若外部来源后来发送修订版，应将两份原件并列保存，并记录哪一版被采用。
来自公开网页的数据还要保留页面地址与读取日期。附件本身没有来源时，至少在项目说明中写明从哪里取得。
提交平台与小组云盘承担不同责任。
小组云盘负责协作，课程提交平台负责交付。把文件放入共享目录并不等于教师已经收到；平台显示上传也不代表文件格式正确。提交者需要在截止前完成上传、重新打开文件并保存回执。
若平台限制大小或格式，转换后的交付文件应与编辑源文件同时保留。只保存压缩版，后续修改会损失图片与排版质量。
提交后不要在同名文件上继续编辑。需要修改时建立下一版本，并确认平台是否允许替换以及替换会不会改变提交时间。
归档时保留决策而不是所有过程。
完整聊天、每分钟自动保存和所有临时导出通常没有长期价值。归档应保留任务说明、正式资料、最终成果、关键反馈和少量能够解释重要决定的草稿。
对于研究或设计项目，失败方案可能仍有学习价值，但要写明为什么没有采用。没有说明的大量草稿只会增加后来阅读成本。
文件删除应遵守课程、机构与团队协议。涉及个人资料或版权材料时，保存时间不能仅凭个人习惯决定。
不同文件格式需要不同核对方式。
文字文档重点检查标题、批注与分页，电子表格要检查公式、隐藏列和外部链接，演示文稿则要确认字体、视频与动画。用一种预览方式处理所有格式，容易忽略真正影响提交的部分。
导出PDF可以固定版面，却可能丢失视频、表单和可编辑信息。课程要求同时提交源文件时，应把两种文件放在同一交付目录，并用清楚名称说明用途。
压缩包上传后需要重新解压检查。路径过长、特殊字符或缺少关联文件，都可能让接收方看到与制作端不同的结果。
数据表的更新时间不能只看文件名。
同名数据表可能替换内容但保留旧文件名，也可能只更新某几个工作表。引用前查看数据周期、发布日期、修订说明和字段定义，不能因为下载时间较新就认定全部数据更新。
小组中负责数据的人应冻结分析所用版本，并记录取得日期。其他成员若发现新版，先比较对结论的影响，再决定是否重新计算。
报告提交后遇到数据修订，可以在附注中说明变化。悄悄替换已经使用的数据，会让图表和文字之间失去对应。
反馈意见也需要一个结束状态。
评论被处理后可以标为已解决，并保留简短结果。直接删除评论会让审阅者不知道意见是否被采纳，也可能让相同问题在下一轮重新出现。
意见相互冲突时，由任务负责人根据课程要求和证据作出决定，而不是按留言数量表决。决定应写回主文件或任务说明。
无法在本轮处理的建议可以进入后续清单，但不要让它们继续混在待提交文件中。
图像和引用的授权跟着版本移动。
草稿中使用的图片可能只适合课堂讨论，不一定允许公开发布。文件进入最终交付前，应重新核对图片来源、署名方式和使用范围。替换图片后，图注与正文引用也要同步更新。
引用段落经过编辑时不能改变原意。需要省略内容可使用规范标记，并保留作者、作品和页码；翻译引用还要说明译者或翻译方式。
授权信息应和成果一起归档。几年后只剩图片文件而没有来源，团队很难判断能否再次使用。
把“最新”留给真正核对过的版本。
目录中更新时间最近的文件未必是正式版本，可能只是有人打开后自动保存。正式发布应由负责人员完成，并在状态中写明用途。
成员发现内容有误时先提出修订，不直接在提交版上改动。修订完成后创建新版本，并保留旧版用于解释已经发出的结论。
这种做法让“最新”成为明确发布行为，而不是系统时间戳的偶然结果。
共同编辑前先约定段落归属。
多人同时编辑长文时，可以按章节或问题分配责任，减少同一段被反复覆盖。整合阶段再统一术语、语气和引用格式，而不是要求每位成员从开始就写得完全相同。
交叉审阅时，审阅者提出问题和证据，不直接把作者观点改成自己的版本。争议回到任务要求和来源处理。
整合者最后检查章节之间是否互相重复、结论是否与前文证据一致。结构问题不能只靠修改标题解决。
课程资料也需要保留来源卡片。
一份讲义被下载、重命名和转发几次以后，原始课程、发布日期和教师说明很容易消失。可以在资料旁保留简短来源卡片，写明课程名称、取得位置、版本日期与使用范围。
来源卡片不是为了增加表格，而是让后来加入的小组成员知道哪一份可以引用、哪一份只是课堂草稿。引用外部文章时还应保留作者、出版机构和访问日期。
如果新版资料修正了旧结论，不要无声覆盖。把变化写进版本说明，旧文件移入归档区，正式任务只链接到当前版本。
备份需要验证，而不只是存在。
云盘显示文件已经同步，并不能证明备份可以恢复。项目进行到重要节点时，可以从另一台设备打开归档副本，确认附件、字体和引用文件完整。
备份与主文件应有不同失效条件。若两者都只存在同一账号和同一设备中，账号锁定或设备损坏仍会同时影响。
验证后记录日期即可，不需要每日复制整个目录。过多无法辨认的备份也会增加恢复难度。
演示文稿的版本还包含现场条件。
演示文件在制作电脑上正常，不代表教室设备能够播放。字体、视频编码、外部链接和屏幕比例都会改变结果。提交前可导出稳定的备用版本，并在实际投影环境试播。
现场修改应回到主文件。若只在演示电脑上临时改字，团队云盘仍会保留旧内容，下一位成员可能再次使用。
演示结束后保存最终讲稿与使用过的媒体，不必保留每次自动生成的缓存。
文件夹结构应服务于查找。
按成员姓名分文件夹，适合收集个人材料，却不利于整合主题；按章节组织，适合写作，却可能隐藏原始来源。团队可以把原始资料、工作稿和交付成果分成三层，再在工作稿中按章节安排。
结构确定后不要频繁整体移动。大规模改目录会破坏书签与共享链接，应由整合者在阶段转换时完成。
新成员若能在几分钟内找到任务说明、主文件和资料来源，说明结构已经足够清楚。