脚本必须保存到当前文件夹：新建脚本第一步先 Save 再 Run 的规矩

1. 引言：一条被低估的工程规矩

几乎每一位带过新人的工程师都说过这句话：“新建脚本，先 Save，再 Run。”它听起来像是一条经验口诀，甚至有点像迷信。但如果我们把它拆开，会发现它精确地指向了三个技术事实：第一，大多数解释器执行的是磁盘上的文件，而不是编辑器缓冲区里的文本；第二，脚本中相对路径的解析基准是进程的当前工作目录（Current Working Directory, CWD），而不是脚本文件所在目录；第三，IDE 的“运行”按钮背后有一整套运行配置，它决定了 CWD、解释器路径和环境变量。

这三件事任意一件出错，都会表现为“代码明明没问题，结果就是不对”。而“先 Save 再 Run”恰好是最低成本的一致性保障动作。笔者认为，这条规矩的本质不是操作习惯，而是一条关于“状态一致性”的工程约束：磁盘上的脚本内容、脚本所在位置、运行时的 CWD，三者必须构成一个可被明确描述的状态，程序的行为才是可预测的。

可复现性研究领域早已指出，计算结果的不可复现，很大比例来自环境与路径的隐式依赖，而非算法本身。Peng 在 2011 年关于可复现研究的长文（参考文献 [1]）中系统讨论了计算科学中“可复现”的多层含义；此后 ACM 于 2020 年前后推动的 Artifact Evaluation 体系（参考文献 [2]）进一步把“可被独立复现”作为论文录用的重要维度。这些工作共同指向一个结论：路径与目录结构是计算工件（artifact）接口的一部分，而不是无关紧要的实现细节。

本文评述：把“先 Save 再 Run”提升到“状态一致性约束”的高度，并非过度解读。工程实践中真正昂贵的从来不是写代码，而是定位“为什么这次和上次不一样”。路径问题之所以难查，是因为它不报错、只改变行为，属于典型的静默故障（silent failure）。

本文的组织方式如下：第 2 节讨论工作目录的语义；第 3 节深入相对路径解析机制；第 4 节解释“未保存即运行”的真实行为；第 5 节对比三大平台的路径差异；第 6 节给出可落地的目录结构模板与操作步骤；第 7 节提供自动化校验方案；第 8 节从可复现性视角提炼“路径即接口”的主线；第 9 节给出前沿预判与结论。

2. 工作目录的语义：进程、解释器与 IDE 的三方博弈

2.1 进程视角：CWD 是进程的一个属性

在 POSIX 系统中，每个进程都维护一个当前工作目录，它是进程属性的一部分，可通过 chdir() 系统调用修改。相对路径（不以 / 开头）在解析时，一律以该进程的 CWD 为基准拼接。Windows 上语义类似，进程同样拥有当前目录，且各驱动器可各自维护一个“当前目录”，这是 Windows 独有的复杂性来源之一（参考文献 [3]）。

关键点在于：CWD 属于进程，不属于脚本文件。脚本文件的位置和进程的 CWD 之间没有任何强制关系。你完全可以把脚本放在 /home/user/project/scripts/，却在 /tmp 目录下启动它。此时脚本里写的 open("data.csv") 会去 /tmp/data.csv 找文件，而不是脚本旁边的 data.csv。

2.2 解释器视角：谁决定了 CWD

当你执行 python script.py 时，shell 先 fork 出子进程，子进程继承 shell 的 CWD，然后 exec 加载 Python 解释器。因此解释器进程的 CWD 等于你敲命令时所在的目录。Python 官方文档在 sys.path 的说明中明确指出，脚本所在目录会被加入模块搜索路径，但这并不改变 CWD（参考文献 [4]）。这是一个高频混淆点：模块能被 import，不代表相对路径能打开文件。

R 语言的情况更微妙。Rscript 启动时 CWD 同样是调用目录；而 RStudio 的“Source”与“Run”行为不同，前者默认以脚本所在目录为基准（可配置），后者在控制台逐行执行，CWD 保持不变。这种不一致正是大量 R 用户困惑的来源（参考文献 [5]）。

2.3 IDE 视角：运行配置是隐藏的契约

VS Code、PyCharm、RStudio 等 IDE 的“运行”按钮，本质上是在替你拼一条命令行，并指定 CWD。以 VS Code 为例，Python 扩展默认把 CWD 设为工作区根目录（${workspaceFolder}），可通过 launch.json 中的 cwd 字段覆盖（参考文献 [6]）。PyCharm 则在 Run Configuration 中提供 Working directory 设置，默认是项目根目录（参考文献 [7]）。

这意味着：同一个脚本，在终端里跑和在 IDE 里跑，CWD 可能不同，行为也可能不同。这就是“三方博弈”的实质——shell、解释器、IDE 各自对 CWD 有自己的默认假设，而脚本作者往往没有显式声明自己的假设。

3. 相对路径解析机制：从 CWD 到模块搜索路径

3.1 文件 I/O 的相对路径

文件打开操作中的相对路径，解析基准是 CWD。这一点在 Python 的 open()、C 的 fopen()、Node.js 的 fs.readFile() 中完全一致。Python 官方文档 os.path 与 pathlib 章节对此有明确说明（参考文献 [8]）。

一个常见误区是认为“脚本旁边的文件”可以用相对路径直接访问。事实上，只有当 CWD 恰好等于脚本目录时，这个假设才成立。工程上更稳妥的做法是：以脚本文件位置为锚点构造绝对路径。Python 3.4 引入的 pathlib 提供了优雅写法：

from pathlib import Path

BASE = Path(__file__).resolve().parent
data_path = BASE / "data" / "input.csv"
print(data_path)  # 无论 CWD 在哪，都指向脚本旁的 data/input.csv

本文评述：__file__ 是 Python 中把“脚本位置”显式化的关键变量，但它在交互式解释器、exec() 动态执行、部分打包工具中可能不存在或语义不同。因此生产代码中应结合 try/except 或改用配置注入，而非无条件依赖。

3.2 模块导入的相对路径

模块导入是另一套机制。Python 的 sys.path 是一个列表，解释器按顺序搜索。列表首项在脚本模式下是脚本所在目录，在 -m 模块模式下是 CWD（参考文献 [4]）。这个差异导致 python script.py 与 python -m script 的导入行为可能完全不同。

Node.js 的模块解析规则（CommonJS）以文件位置为基准向上查找 node_modules，与 CWD 无关；但 require('./x') 中的相对路径以当前模块文件为基准。ES Modules 进一步统一了这一点（参考文献 [9]）。换言之，导入路径的基准是“文件”，而 I/O 路径的基准是“进程”，两套规则并存，正是混乱之源。

3.3 环境变量与配置注入

十二要素应用（The Twelve-Factor App）方法论主张把配置从代码中剥离，通过环境变量注入（参考文献 [10]）。在路径治理上，这意味着数据目录、输出目录应通过环境变量或配置文件指定，而不是硬编码相对路径。这一原则在容器化与 CI/CD 场景中尤为重要。

环境	I/O 相对路径基准	模块导入基准	典型坑点
Python 脚本模式	进程 CWD	脚本所在目录	import 成功但 open 失败
Python -m 模式	进程 CWD	CWD	包内相对导入报错
Node.js CJS	进程 CWD	当前模块文件	fs 与 require 基准不同
R Rscript	进程 CWD	CWD / 库路径	RStudio 与终端不一致
Shell	进程 CWD	PATH 搜索	source 与执行 CWD 不同

表 1：主流脚本环境中两类路径解析基准对比（依据各语言官方文档整理，参考文献 [4][8][9][11]）

4. “未保存即运行”到底发生了什么

4.1 解释器执行的是磁盘文件

CPython 的启动流程中，命令行参数指向的文件会被读取、编译为字节码再执行。编辑器缓冲区里的未保存内容对解释器完全不可见。因此“改了代码没保存就运行”，跑的是旧版本——这解释了大量“我明明改了怎么没生效”的困惑。

更隐蔽的情况是：新建脚本尚未保存到磁盘时，某些 IDE 会先把内容写到临时文件再执行。此时 __file__ 指向临时目录，脚本旁边的数据文件自然找不到。PyCharm 在“未保存文件运行”时会弹出提示或使用临时路径，VS Code 的 Python 扩展在部分版本中会先保存再运行（参考文献 [6][7]）。这些行为差异正是“先 Save 再 Run”这条规矩的现实依据。

4.2 缓存与字节码的干扰

Python 会在 __pycache__ 中缓存字节码，依据是源文件的修改时间与大小。正常情况下源文件更新会触发重新编译，但如果文件系统时间戳异常（如网络挂载、时钟漂移），可能读到过期字节码。这类问题在容器与共享存储环境中偶有报告（参考文献 [12]）。

本文评述：把“先 Save 再 Run”仅仅理解为“别忘了按 Ctrl+S”是浅层的。它真正要求的是：运行前，磁盘状态必须是你认为的那个状态。这包括文件已保存、保存到了预期位置、且没有过期缓存干扰。

4.3 一个可复现的最小实验

下面这个实验可以直观展示问题。在 /tmp/demo 下新建脚本，写入读取同目录 data.txt 的代码，但不保存；然后在 /tmp 下运行。结果会因 IDE 行为不同而不同，但几乎都不会如预期读到 data.txt。

# 实验步骤（模拟数据，仅用于演示路径行为）
mkdir -p /tmp/demo && cd /tmp/demo
echo "hello" > data.txt
# 在编辑器中新建 read.py 但不保存，内容：
#   print(open("data.txt").read())
# 然后在 /tmp 下执行：
cd /tmp && python /tmp/demo/read.py
# 观察报错：FileNotFoundError: [Errno 2] data.txt

若把脚本保存到 /tmp/demo/read.py 并在 /tmp/demo 下运行，则成功。这个对比清楚说明：决定成败的不是代码，而是“保存位置 + 运行目录”这一组合。

5. 跨平台差异：Windows、Linux、macOS 的路径陷阱

5.1 分隔符与大小写

Windows 使用反斜杠 \ 作为路径分隔符，且在字符串中是转义字符，因此路径字面量必须写成原始字符串或双反斜杠。POSIX 系统使用正斜杠。Python 的 pathlib 与 os.path 会做平台适配，但前提是使用这些 API 而不是手写字符串拼接（参考文献 [8]）。

大小写敏感性是另一个雷区。Linux 文件系统默认区分大小写，Windows 与 macOS 默认不区分（macOS 可配置为区分）。Data.csv 与 data.csv 在开发机上能跑，部署到 Linux 服务器就报错，这是 CI/CD 中的经典故障。

5.2 换行符与编码

Windows 使用 CRLF，POSIX 使用 LF。Git 的 core.autocrlf 配置若设置不当，会导致脚本在跨平台协作时出现“行尾多了 ^M”的问题。Shell 脚本尤其敏感，CRLF 会导致 shebang 解析失败（参考文献 [13]）。

编码方面，Python 3 默认源文件为 UTF-8，但 Windows 控制台默认代码页可能不是 UTF-8，导致中文输出乱码。建议在脚本头部声明编码，并在 Windows 上设置 PYTHONUTF8=1 或使用 chcp 65001（参考文献 [14]）。

5.3 驱动器与 UNC 路径

Windows 的“每驱动器一个当前目录”语义意味着 cd D:\ 后切回 C 盘，C 盘的当前目录仍是之前的值。这在批处理脚本中会造成难以察觉的行为差异（参考文献 [3]）。UNC 路径（\\server\share）则不支持作为 CWD，某些 API 会失败。

6. 工程实践：目录结构模板与操作路径

6.1 推荐目录结构

一个对路径友好的项目结构应满足：脚本、数据、输出、配置各自有明确位置，且所有路径可从项目根推导。下面是一个通用模板，适用于数据分析、脚本工具与小型服务。

project/
├── README.md
├── pyproject.toml          # 或 requirements.txt
├── .gitattributes          # 统一换行符
├── config/
│   └── settings.yaml
├── scripts/
│   ├── run_pipeline.py
│   └── utils.py
├── data/
│   ├── raw/                # 原始数据，只读
│   └── processed/          # 处理后数据
├── outputs/
│   ├── figures/
│   └── logs/
└── tests/
    └── test_paths.py

这个结构的核心思想是：所有路径都从项目根出发，通过一个统一的路径解析模块生成，脚本本身不假设 CWD。这与 CookieCutter Data Science 项目模板（参考文献 [15]）以及 Python Packaging Authority 的 src 布局建议（参考文献 [16]）方向一致。

6.2 统一路径解析模块

在 scripts/utils.py 中定义项目根与常用目录，其他脚本统一导入。这样即使 CWD 变化，路径依然稳定。

# scripts/utils.py
from pathlib import Path

PROJECT_ROOT = Path(__file__).resolve().parents[1]
DATA_DIR = PROJECT_ROOT / "data"
RAW_DIR = DATA_DIR / "raw"
PROCESSED_DIR = DATA_DIR / "processed"
OUTPUT_DIR = PROJECT_ROOT / "outputs"

def ensure_dirs():
    for d in (PROCESSED_DIR, OUTPUT_DIR / "figures", OUTPUT_DIR / "logs"):
        d.mkdir(parents=True, exist_ok=True)

本文评述：把路径集中管理，等价于给项目定义了一套“路径接口”。任何脚本只要遵循这套接口，就不必关心自己是从哪个目录被调用的。这是把“先 Save 再 Run”的经验规矩，升级为结构性保障的关键一步。

6.3 标准操作步骤（SOP）

1. 新建脚本后立即保存到 scripts/ 目录，文件名使用小写下划线风格。
2. 在脚本开头导入统一路径模块，不要手写相对路径字符串。
3. 确认运行配置的 CWD：终端中先 cd 到项目根；IDE 中在运行配置里显式设置 working directory 为项目根。
4. 运行前打印关键路径，确认指向预期位置。
5. 提交前用测试校验路径（见第 7 节）。

6.4 一个完整的可运行示例

下面示例演示从原始数据读取、处理到输出图表的完整流程，所有路径均基于项目根，可在任意 CWD 下运行。

# scripts/run_pipeline.py
import csv
from utils import RAW_DIR, PROCESSED_DIR, OUTPUT_DIR, ensure_dirs

def load(path):
    with open(path, newline="", encoding="utf-8") as f:
        return list(csv.DictReader(f))

def main():
    ensure_dirs()
    src = RAW_DIR / "sample.csv"
    rows = load(src)
    out = PROCESSED_DIR / "clean.csv"
    with open(out, "w", newline="", encoding="utf-8") as f:
        w = csv.DictWriter(f, fieldnames=rows[0].keys())
        w.writeheader()
        w.writerows(rows)
    print(f"[OK] wrote {out}")

if __name__ == "__main__":
    main()

注意 from utils import ... 依赖脚本目录在 sys.path 中。若以模块方式运行（python -m scripts.run_pipeline），需改为包内导入。这正是第 3 节所述两套规则并存的体现。

7. 自动化校验：把规矩写进工具链

7.1 路径测试

用 pytest 编写路径测试，确保关键文件存在且路径解析正确。这类测试成本极低，却能拦住大部分“换机器就崩”的问题。

# tests/test_paths.py
from pathlib import Path
from scripts.utils import PROJECT_ROOT, RAW_DIR

def test_project_root_exists():
    assert PROJECT_ROOT.is_dir()

def test_raw_dir_under_root():
    assert RAW_DIR.is_dir()
    assert PROJECT_ROOT in RAW_DIR.parents

def test_no_absolute_hardcoded_paths():
    # 简单扫描：脚本中不应出现 /home/ 或 C:\ 字面量
    for p in (PROJECT_ROOT / "scripts").glob("*.py"):
        text = p.read_text(encoding="utf-8")
        assert "/home/" not in text
        assert "C:\\" not in text

7.2 预提交钩子与 CI

pre-commit 框架可以在提交前自动运行检查，包括行尾符统一、路径字面量扫描、脚本语法检查等（参考文献 [17]）。在 CI 中，建议至少跑两个平台（Linux 与 Windows），以暴露大小写与分隔符问题。

检查项	工具	触发时机	拦截的问题
行尾符统一	.gitattributes / pre-commit	提交时	CRLF 导致 shebang 失败
硬编码路径扫描	自定义脚本 / ruff 规则	提交时	换机器路径失效
路径存在性测试	pytest	CI	目录结构漂移
跨平台运行	GitHub Actions 矩阵	CI	大小写与分隔符差异

表 2：路径相关自动化检查清单（依据 pre-commit 与 GitHub Actions 官方文档整理，参考文献 [17][18]）

7.3 容器化：把 CWD 也固化下来

Dockerfile 中的 WORKDIR 指令会设置容器内进程的 CWD。把 WORKDIR 设为项目根，并在 ENTRYPOINT 中使用绝对路径调用脚本，可以彻底消除 CWD 不确定性（参考文献 [19]）。这是把“先 Save 再 Run”的规矩从个人习惯升级为环境约束的典型做法。

FROM python:3.12-slim
WORKDIR /app
COPY . /app
RUN pip install --no-cache-dir -r requirements.txt
ENTRYPOINT ["python", "/app/scripts/run_pipeline.py"]

8. 可复现性视角：路径即接口

8.1 可复现研究的三层含义

可复现研究领域通常区分三个层次：可重复（repeatability，同一人同一环境）、可复现（reproducibility，同一团队不同环境）、可再现（replicability，不同团队不同环境）。Peng 在 2011 年的论述中强调，达到可复现需要把数据、代码、环境、文档一并交付（参考文献 [1]）。路径与目录结构正是“环境”与“代码”之间的接口层。

ACM 的 Artifact Evaluation 体系在 2020 年后逐步成熟，要求作者提交的工件能在评审环境中独立运行（参考文献 [2]）。实践中，评审环境与作者环境的差异，很大一部分体现在路径上：数据放在哪、输出写到哪、临时文件用哪个目录。因此，一个能被独立复现的工件，必然有一套明确的路径约定。

8.2 可复现构建的启示

可复现构建（reproducible build）领域追求“相同源码、相同环境，产出比特级一致的制品”。Debian、Reproducible Builds 项目多年推动这一目标，其核心手段之一是消除构建过程中的路径依赖，例如通过规范化构建路径、剥离调试信息中的绝对路径（参考文献 [20][21]）。

本文评述：脚本层面的“路径治理”与构建层面的“可复现构建”是同一问题的不同尺度。前者关心“这次跑和上次跑结果是否一致”，后者关心“这台机器和那台机器产物是否一致”。两者共享同一条原则：任何隐式的环境依赖，都应被显式化。

8.3 环境锁定与依赖管理

路径之外，依赖版本也是可复现性的关键。Python 生态中，requirements.txt 锁定直接依赖，pip-tools、poetry.lock、uv.lock 可锁定完整依赖树（参考文献 [22][23]）。R 生态中 renv 提供类似能力（参考文献 [24]）。

近三年，随着 uv 等高速包管理器的普及，环境重建时间大幅缩短，使得“每次运行前重建环境”从奢侈变为可行（参考文献 [23]）。这进一步降低了路径与依赖漂移的风险。

9. 前沿预判与结论

9.1 趋势一：路径声明式化

越来越多工具开始用声明式配置描述路径。例如 DVC 用 dvc.yaml 声明数据流水线的输入输出（参考文献 [25]），Snakemake 用规则声明输入输出文件（参考文献 [26]），Nextflow 用 process 声明路径（参考文献 [27]）。这些工具的共同点是：路径不再散落在脚本里，而是集中在配置中，由工具负责解析与调度。

本文评述：声明式路径的价值在于把“路径假设”变成“路径契约”。当路径被写进配置文件，它就成为可审查、可版本控制、可测试的接口。这与“先 Save 再 Run”的精神一脉相承——都是为了让运行状态可预测。

9.2 趋势二：容器与虚拟文件系统

容器技术把 CWD、文件系统、环境变量一并封装，使得“在我机器上能跑”的问题大幅减少。近三年，Dev Container、GitHub Codespaces、Nix 等方案进一步把开发环境标准化（参考文献 [28][29][30]）。Nix 的纯函数式包管理理念，甚至把路径本身作为哈希的一部分，从根本上消除了路径不确定性。

9.3 趋势三：AI 辅助编码对路径纪律的挑战

近两年，AI 代码补全与生成工具普及，显著提升了编码速度，但也带来新的路径风险：生成代码常包含硬编码路径或假设 CWD 的写法。2023 年以来多项关于 AI 生成代码质量的实证研究指出，生成代码在环境假设方面往往不够稳健（参考文献 [31][32][33]）。

本文评述：AI 生成代码越多，路径纪律越重要。因为人类作者会记得“我这里假设了 CWD”，而生成代码不会解释自己的假设。此时，统一的路径模块与自动化测试，成为人机协作的质量底线。

9.4 结论

“脚本必须保存到当前文件夹，新建脚本第一步先 Save 再 Run”，这条规矩的技术内核是状态一致性：磁盘内容、文件位置、运行目录三者必须构成可描述、可验证的状态。本文从进程 CWD 语义、相对路径解析、未保存运行行为、跨平台差异四个层面展开分析，给出了目录结构模板、统一路径模块、SOP 步骤、自动化校验与容器化方案，并从可复现研究与可复现构建视角提炼出“路径即接口”的主线。

对工程实践者而言，可落地的行动清单是：新建脚本立即保存；路径集中管理；运行前确认 CWD；用测试与 CI 守住路径契约。这四步成本极低，却能消除大量静默故障。对研究者而言，把路径约定写进工件文档，是提升可复现性的高性价比投入。

9.5 拓展资源

• Python 官方文档 os.path 与 pathlib：https://docs.python.org/3/library/pathlib.html
• VS Code Python 运行配置文档：https://code.visualstudio.com/docs/python/debugging
• Reproducible Builds 项目：https://reproducible-builds.org/
• CookieCutter Data Science：https://cookiecutter-data-science.drivendata.org/
• pre-commit 框架：https://pre-commit.com/
• DVC 数据版本控制：https://dvc.org/doc
• Nix 包管理器：https://nixos.org/

10. 参考文献与声明

10.1 主要参考文献（8 篇）

1. Peng, R. D. (2011). Reproducible Research in Computational Science. Science, 334(6060), 1226–1227.
2. ACM Artifact Review and Badging (2020). ACM Publications Policies. https://www.acm.org/publications/policies/artifact-review-badging
3. Microsoft (2024). Naming Files, Paths, and Namespaces. Microsoft Learn.
4. Python Software Foundation (2024). The Module Search Path. Python 3 Documentation.
5. R Core Team (2024). R Installation and Administration. CRAN.
6. Microsoft (2024). Python debugging configurations. VS Code Documentation.
7. JetBrains (2024). Run/Debug Configuration: Working directory. PyCharm Documentation.
8. Python Software Foundation (2024). pathlib — Object-oriented filesystem paths.

10.2 其余引用文献（55 篇，节选编号）

[9] Node.js Foundation, Modules: CommonJS modules, 2024. [10] Wiggins, A., The Twelve-Factor App, 2017. [11] R Core Team, R Language Definition, 2024. [12] CPython Developers, __pycache__ and bytecode caching, 2024. [13] Git Project, gitattributes: End-of-line conversion, 2024. [14] Python Software Foundation, PEP 540: Add a new UTF-8 Mode, 2017. [15] DrivenData, CookieCutter Data Science, 2023. [16] PyPA, src layout vs flat layout, 2024. [17] pre-commit, A framework for managing multi-language pre-commit hooks, 2024. [18] GitHub, Using a matrix for your jobs, 2024. [19] Docker, Dockerfile reference: WORKDIR, 2024. [20] Reproducible Builds, Definitions and goals, 2024. [21] Debian, Reproducible Builds in Debian, 2024. [22] PyPA, pip-tools documentation, 2024. [23] Astral, uv: An extremely fast Python package installer, 2024. [24] Ushey, K., renv: Project Environments for R, 2023. [25] Iterative, DVC: Data Version Control, 2024. [26] Mölder, F., et al. (2021). Sustainable data analysis with Snakemake. F1000Research, 10:33. [27] Di Tommaso, P., et al. (2017). Nextflow enables reproducible computational workflows. Nature Biotechnology, 35, 316–319. [28] Microsoft, Dev Containers specification, 2024. [29] GitHub, Codespaces documentation, 2024. [30] Dolstra, E., et al. (2004). Nix: A Safe and Policy-Free System for Software Deployment. LISA. [31] Nguyen, N., & Nadi, S. (2022). An Empirical Evaluation of GitHub Copilot's Code Suggestions. MSR. [32] Vaithilingam, P., et al. (2022). Expectation vs. Experience: Evaluating the Usability of Code Generation Tools. CHI EA. [33] Perry, N., et al. (2023). Do Users Write More Insecure Code with AI Assistants? CCS. [34] Sandve, G. K., et al. (2013). Ten Simple Rules for Reproducible Computational Research. PLoS Computational Biology, 9(10). [35] Piccolo, S. R., & Frampton, M. B. (2016). Tools and techniques for computational reproducibility. GigaScience, 5(1). [36] Stodden, V., et al. (2016). Enhancing reproducibility for computational methods. Science, 354(6317). [37] Wilkinson, M. D., et al. (2016). The FAIR Guiding Principles. Scientific Data, 3:160018. [38] Grus, J. (2019). Data Science from Scratch, 2nd ed. O'Reilly. [39] VanderPlas, J. (2016). Python Data Science Handbook. O'Reilly. [40] McKinney, W. (2022). Python for Data Analysis, 3rd ed. O'Reilly. [41] Wickham, H., & Grolemund, G. (2023). R for Data Science, 2nd ed. O'Reilly. [42] Bryan, J., & Hester, J. (2023). What They Forgot to Teach You About R. [43] Noble, W. S. (2009). A Quick Guide to Organizing Computational Biology Projects. PLoS Computational Biology, 5(7). [44] Wilson, G., et al. (2017). Good enough practices in scientific computing. PLoS Computational Biology, 13(6). [45] Hunter-Zinck, H., et al. (2021). Ten simple rules on writing clean and reliable open-source scientific software. PLoS Computational Biology, 17(11). [46] Lee, B. D. (2018). Ten simple rules for documenting scientific software. PLoS Computational Biology, 14(12). [47] Taschuk, M., & Wilson, G. (2017). Ten simple rules for making research software more robust. PLoS Computational Biology, 13(4). [48] Eglen, S. J., et al. (2017). Toward standard practices for sharing computer code and programs. Nature Neuroscience, 20. [49] Boettiger, C. (2015). An introduction to Docker for reproducible research. ACM SIGOPS OSR, 49(1). [50] Nüst, D., et al. (2018). Ten simple rules for writing Dockerfiles for reproducible data science. PLoS Computational Biology, 16(11). [51] Kurtzer, G. M., et al. (2017). Singularity: Scientific containers for mobility of compute. PLoS ONE, 12(5). [52] Courtès, L., & Wurmus, R. (2015). Reproducible and User-Controlled Software Environments in HPC with Guix. Euro-Par Workshops. [53] Di Cosmo, R., et al. (2020). Archiving and referencing source code with Software Heritage. ICMS. [54] Katz, D. S., et al. (2021). The Principles of Open Scholarly Infrastructure. [55] Barker, M., et al. (2022). The Turing Way: A handbook for reproducible data science. [56] The Carpentries (2024). Software Carpentry: Version Control and Project Organization. [57] Python Packaging Authority (2024). Packaging Python Projects. [58] RStudio (2024). Projects and working directories. [59] JetBrains (2024). Content roots and working directories. [60] GNU (2024). Bash Reference Manual: Shell Builtins (cd, pwd). [61] IEEE (2023). IEEE Standard for Software and Systems Engineering Terminology. [62] ISO/IEC 25010 (2023). Systems and software Quality Requirements and Evaluation. [63] National Academies (2023). Reproducibility and Replicability in Science (updated edition).

关于数据集说明：本文第 4 节的最小实验使用模拟数据（echo "hello" > data.txt），仅用于演示路径行为，不涉及真实数据集。第 6 节示例中的 sample.csv 为占位文件，读者可替换为任意 CSV。若使用真实数据集，建议预处理步骤为：统一编码为 UTF-8、去除 BOM、规范列名、记录数据来源与版本哈希。