分析数据集并交付报告

简介

从根本上说，数据分析是关于使用数据来支持决策的。目标不是为了分析而分析，而是产出能帮助他人行动的成果物：给管理层的图表、给产品团队的实验结果解读、给研究人员的模型评估，或指导日常运营的仪表板。

一个很有用的框架，由 _R for Data Science_ 推广，是一个循环：导入并整理数据，然后在转换、可视化和建模之间迭代，在传达结果之前逐步建立理解。编程贯穿整个循环。

Codex 很适合这个工作流。它可以通过清洗数据、探索假设、生成分析内容以及产出可复现的成果物，帮助你更快地完成这个循环。目标不是一次性的 notebook。目标是一个其他人可以审阅、信任并重新运行的工作流。

明确你的使用场景

选择一个你希望通过数据回答的具体问题。

问题越具体越好。这样可以帮助 Codex 理解你的目标，以及它应如何帮助你达成目标。

运行示例：高速公路附近的房产价值

作为示例，我们将探讨以下问题：

> 靠近高速公路的房屋，其房产估值在多大程度上更低？

假设一个数据集包含房产估值或销售价格，另一个数据集包含位置、地块或与高速公路距离相关的信息。工作不只是运行一个模型，而是要让输入数据值得信赖、记录连接过程、对结果进行压力测试，并最终产出一个其他人也能使用的成果物。

设置环境

当你开始一个新的数据分析项目时，需要先设置环境并定义项目规则。

• 环境： Codex 应该知道这个项目中哪种 Python 环境、包管理器、文件夹和输出约定是规范做法。
• Skills： 像 notebook 清理、电子表格导出或最终报告打包这类重复性工作流，应当沉淀为可复用的 skills，而不是在每次提示中重复解释。
• Worktrees： 将不同的探索拆分到不同的 worktree 中，这样一个假设、合并策略或可视化分支就不会影响另一个。

如需进一步了解如何安装和使用 skills，请参阅我们的 skills 文档。

引导 Codex 的行为

在接触数据之前，先告诉 Codex 在这个仓库中应如何工作。将个人默认设置放在 ~/.codex/AGENTS.md 中，将项目规则放在仓库内的 AGENTS.md 中。

一个简短的 AGENTS.md 通常就足够：

## Data analysis defaults

- Use `uv run` or the project's existing Python environment.
- Keep source data in `data/raw/` and write cleaned data to `data/processed/`.
- Put exploratory notebooks in `analysis/` and final artifacts in `output/`.
- Never overwrite raw files.
- Prefer scripts or checked-in notebooks over unnamed scratch cells.
- Before merging datasets, report candidate keys, null rates, and join coverage.

如果仓库中还没有定义 Python 环境，请让 Codex 创建一个可复现的设置，并说明如何运行它。对于数据分析工作来说，这一步比直接跳到图表更重要。

导入数据

通常最快的开始方式，是直接粘贴文件路径并让 Codex 检查它。此时 Codex 可以帮助你回答一些基础但重要的问题：

• 这里有哪些文件格式？
• 每个数据集看起来分别表示什么？
• 哪些列可能是目标值、标识符、日期、位置或度量值？
• 哪些地方存在明显的数据质量问题？

先不要急着下结论。先要求它给出清单和说明。

整理并合并输入数据

大多数真实工作都从这里开始。你有两个或更多数据集，主键并不明确，而一次天真的合并可能导致数据丢失或产生重复。

在执行合并之前，先让 Codex 对合并进行分析：

• 检查候选键的唯一性。
• 衡量空值率和格式差异。
• 规范化明显的格式问题，例如大小写、空白字符或地址格式。
• 运行试验性连接并报告匹配率。
• 在写出最终合并文件前，推荐最安全的合并策略。

如果你需要推导最佳键，例如标准化后的地址、由多个列构成的地块标识符，或基于位置的连接，请让 Codex 在你接受合并之前先解释其中的权衡和边界情况。

使用图表和独立 worktree 进行探索

探索性数据分析是 Codex 特别适合通过清晰隔离来发挥作用的阶段。一个 worktree 可以用于测试地址清洗或特征工程，另一个则专注于图表或替代模型方向。这样可以让每个 diff 都更容易审阅，并防止一条很长的线程混入彼此不兼容的想法。

Codex 应用内置了对 worktree 的支持。如果你在终端中工作，普通的 Git worktree 也同样好用：

git worktree add ../analysis-highway-eda -b analysis/highway-eda
git worktree add ../analysis-model-comparison -b analysis/highway-modeling

在这个运行示例中，这一步就是你比较靠近高速公路的房屋与距离更远房屋的地方，检查离群值、查看缺失值模式，并判断观察到的效应是否真实存在，还是只是反映了社区构成、房屋面积或其他因素。

对问题建模

并非每个分析都需要复杂模型。先从一个易于解释的基线模型开始。

对于高速公路这个问题，一个合理的第一步是回归模型或其他透明模型，用来估计高速公路邻近程度与房产价值之间的关系，同时控制面积、房龄和位置等相关因素。

请让 Codex 明确说明：

• 目标变量和特征定义。
• 应包含哪些控制变量，以及为什么。
• 泄漏风险和排除项。
• 它如何选择数据划分、评估方式或不确定性估计。
• 结果用通俗语言意味着什么。

如果第一个模型效果不佳，这仍然是有价值的信息。它会告诉你问题出在模型、特征、连接质量，还是问题本身。

传达结果

只有当其他人能够消费分析结果时，这项分析才真正有用。请让 Codex 生成受众所需的成果物：

• 面向技术协作者的 Markdown 备忘录。
• 供下游运营工作使用的电子表格或 CSV。
• 在格式和表格很重要时，使用 $doc 生成的 .docx 简报。
• 使用 $pdf 渲染的附录或最终交付物。
• 使用 $vercel-deploy 部署的轻量级仪表板或静态报告站点。

这也是你要求它写出注意事项的地方。如果连接质量不完美、存在抽样偏差，或者模型假设较为脆弱，Codex 应该在交付物中明确说明。

可考虑使用的 skills

特别适合这个工作流的精选 skills 包括：

• $spreadsheet：用于 CSV、TSV 和 Excel 的编辑或导出。
• $jupyter-notebook：当交付物应保留为 notebook 原生形式时使用。
• $doc 和 $pdf：用于面向利益相关者的输出。
• $vercel-deploy：当你想通过 URL 分享结果时使用。

当这个工作流稳定下来后，为重复部分创建仓库本地 skills，例如 refresh-data、merge-and-qa 或 publish-weekly-report。从长期来看，这比在每个线程中粘贴相同的过程式提示更合适。

建议提示词

设置分析环境

加载数据集并解释其内容

在连接之前先分析合并情况

打开一个新的探索 worktree

构建一个易于解释的初始模型

为利益相关者打包结果