社科研究者往往知道自己想研究什么，却很难把研究目标转化为完整的数据任务，更无法判断 AI 生成的代码和结果是否可靠。ChatPython 希望通过引导式任务构建、可审阅的分析步骤和本地执行环境，让不懂编程的研究者也能安全、可控地完成数据分析。

项目背景

我们所在的团队长期为经济学、管理学、社会学等专业提供研究数据与教学服务。在与高校老师和学生的合作中，我们反复遇到一个问题：数据分析已经成为论文研究的重要环节，但大多数社科研究者并没有接受过系统的编程训练。

从本科生到博士生，许多人在真正开始分析之前，就会被 Python 环境安装、依赖配置、文件管理和代码报错拦住。根据以往的教学经验，仅仅帮助学生配置好能够运行的 Python 环境，就可能消耗数周课时。

与此同时，一些经济与社会研究数据受到严格的安全监管。研究者只能在指定实验室或受控环境中分析数据，原始数据不能上传至外部平台，也不能直接带走，最终输出的分析结果还需要经过审核。这意味着通用的在线 AI 工具并不能直接进入真实研究流程。

因此，我们与高校共同启动了 ChatPython 项目。它并不是要制作一个更简单的 AI IDE，而是希望重新组织社科研究者完成数据分析的方式：降低编程和环境门槛，引导用户说清研究任务，让分析过程能够被理解和审阅，并在受控环境中形成可复现的研究成果。

初期想法

项目早期，我们将主要问题定义为环境和代码门槛。

当时的产品设想接近一个经过简化的 AI IDE，例如 Cursor、Trae 等等——产品内置 Python 环境，用户导入数据并描述任务，AI 自动编写和运行代码。

例如，普通 AI IDE 会要求用户先创建文件夹、选择项目路径，再管理项目中的文件。但对于目标用户而言，“一个文件夹就是一个项目”并不是常识。因此，我们将创建项目简化成了点击加号、输入名称，剩余结构由系统自动完成。

这些优化确实降低了操作难度，但当我们把原型交给真实用户后发现，简化 IDE 只能解决“如何开始操作”，无法保证用户最终完成研究任务。

快速验证

我和组长使用 Trae快速搭建了一个 MCP 原型。这个原型的界面非常粗糙，也没有完整的产品结构，但它能够跑通最关键的流程：用户提交数据和分析要求，AI 生成 Python 代码，在配置好的环境中执行，并返回处理结果。

我们没有用它验证视觉和交互细节，而是希望回答两个更基础的问题：

  • 用户是否愿意让 AI 参与自己的数据分析？

  • 当 AI 能够自动生成代码后，用户是否真的可以独立完成研究任务？

原型随后通过两个各约 500 人的目标用户微信群，以及高校老师和学生的实际体验进行验证。很显然，第一个问题很快得到了肯定答案，用户愿意尝试用自然语言完成数据清洗、统计分析和图表生成，老师也愿意在教学场景中引入这种新的工作方式。项目存在明确的真实需求。

但第二个问题并没有像我们预想的那样成立。即使 AI 已经能够生成和运行代码，很多用户依然无法顺利推进任务。代码门槛降低之后，新的问题开始暴露出来。

分析反馈

我利用飞书多维表整理好了这些问题，我们开会讨论了一下，发现和我们起初的设想有重合也有一些出入，或许我们已然“高估”了我们目标用户对 AI 进行数据处理的能力。问题可以分为以下几个方面。

无法明确交付任务

这其实我们是有些出乎意料的，我们起初只是以为他们不知道如何安装 Python 和配置环境，结果这却是最常见的反馈——他们不知道应该怎样向 AI 提问。

用户会输入“帮我清洗一下数据”“处理一下缺失值”或者“帮我做一个回归”。这些表达对人来说可以理解，却不足以直接形成一项稳定的数据任务。AI 还需要知道使用哪份数据、处理哪些字段、采用什么方法，以及最终需要输出数据、图表还是分析报告。

这意味着空白聊天框并不是一个真正低门槛的入口，它看起来允许用户自由表达，实际上却默认用户已经具备拆解和组织研究任务的能力，实际上对我们的用户来说是一种产品设计侧的懒惰和不负责。

用户不会 Python，无法审查代码

另一个集中出现的问题，是用户看不懂 AI 的处理过程，因为就像用户分析所说的，他们不会 Python。

现有 AI IDE 通常会展示代码、终端日志、工具调用和运行状态。对于程序员来说，这些信息有助于判断 Agent 正在做什么；但对于社科研究者来说，它们并不能回答真正关心的问题。

用户更想知道的是：AI 当前在处理什么问题，使用了什么研究方法，修改了多少条数据，以及这些变化会不会影响后面的分析结果。说的更直白点，过程是科研的必须要求，结果是他使用时最关心的事情，两者都很重要，可是他们没有一个能看懂的。

当产品只返回一段 Python 代码和最终文件时，用户很难判断结果是否合理，也无法向导师解释这份数据是如何被处理的。也就是说，AI 完成了技术执行，却没有让研究过程变得更容易理解。

用户可能会不断追问

研究过程并不是一次性生成的。用户可能在看到结果后，决定更换缺失值处理方式、调整异常值判断标准，或者修改回归模型中的控制变量。

在我们做的 MVP中，AI 每次提问都会重新写代码，但是其实用户需要的并不是这样的！

用户通常会继续补充要求，再让 AI 修补或者调整代码。而科研层层递进，即使只修改了一个步骤，前面已经确认的内容也可能被重新生成，用户很难比较两次结果之间的差异。

这并不是缺少一个编辑按钮的问题，更根本的原因是，整个分析过程没有被组织成可以独立查看、修改和运行的步骤。用户只能控制整段对话，不能控制其中一项研究决策。

无法联动本地数据

这个属于是国内社科领域一直以来的大问题！强如北京大学，也必须要让用户到本地注册登记后在他的实验室里做数据分析，并且层层审核后带走实验结果（注意不是实验数据）。

也就是说，这个领域里有着大量存在于各个高校的机房、老师的本地电脑和 U 盘亦或是其他本地存储设备中的数据，而它们又是数据分析时必不可少的。

此外，论文研究又要求保留处理方法、运行代码和分析过程。导师需要知道数据经过了哪些修改，其他研究者也需要能够按照相同方法论文科研复现。

这意味着产品不仅要帮助用户得到结果，还需要同时处理数据边界、方法依据和成果复现问题，这意味着一次在线 AI 对话无法自然地承担这些要求。

重新定义设计问题

将原型反馈重新整理后，我把零散需求收敛成了三个核心问题。

任务表达

用户拥有研究目标，却无法将它进一步拆解为数据、字段、方法和输出条件。空白输入框把组织任务的责任交给了最缺少相关能力的人。

过程控制

用户无法理解 AI 生成的代码，也无法只审阅和修改其中一步。分析过程对用户来说仍然是一个黑箱。

研究交付

数据受到安全限制，但分析过程又必须保留依据、代码、版本和运行记录，以满足审核与复现要求。

总结

因此，项目的设计命题从“如何让不懂 Python 的用户生成代码”，重新变成了：如何让不懂编程的社科研究者，也能安全、可控、可复现地完成一次数据分析？这个变化也重新决定了正式产品的设计方向。

设计策略

引导用户构建任务，而不是要求用户写好提示词

针对任务表达问题，我没有继续优化聊天框里的提示词示例，而是将研究任务本身设计成一套引导过程。

产品首先帮助用户识别自己要完成的任务，再逐步补齐执行所需的条件，最后由系统自动组织成完整指令。

将 AI 输出组织成可以审阅的研究步骤

针对过程控制问题，产品不再把代码和 Agent 运行状态作为主要信息，而是使用研究者能够理解的语言解释每一步。

一次分析被拆成若干可以独立查看的研究步骤，每一步都包含采用的方法、执行结果、受到影响的数据，以及必要时可以展开的 Python 代码。用户不仅可以阅读，也可以修改并重新运行其中一步。

让数据留在受控环境，并将过程沉淀成研究成果

针对数据安全和成果复现问题，产品需要将数据处理保留在本地或受控环境，同时记录完整的分析步骤、代码、方法依据和运行版本。最终交付的不再是一段聊天记录，而是一套能够审核和重新运行的研究材料。

设计执行

先选择研究任务，而不是面对空白聊天框

原来的新建页面以聊天输入框为中心。用户进入产品后，需要自己决定如何开始描述任务。但原型反馈表明，空白输入框没有降低表达门槛，只是把复杂性隐藏在了一片空白中。

因此，我将高频研究任务整理成了几个更容易识别的入口：“清洗一份数据”“合并多份数据”“生成统计与图表”和“完成回归分析”。

这些名称没有使用“数据预处理模块”或“统计分析能力”之类的产品语言，而是直接描述用户准备完成的动作。用户不需要先理解产品有哪些功能，只需要判断哪个任务最接近自己的研究目标。

自由输入仍然被保留，但不再是唯一入口。对于拥有明确方法的高级用户，它依然提供足够的灵活性；对于不知道如何开始的用户，任务模板则提供了更加具体的起点。

这个设计将“从零组织一个问题”，转化成了“识别并选择一项任务”。

将提示词变成研究任务的“完形填空”

选择“清洗一份数据”之后，用户仍然需要补充必要条件。如果继续使用聊天追问，用户依然需要理解 AI 为什么询问这些内容，也很容易在多轮对话中遗漏关键信息。

因此，我将一项研究任务拆成了几个固定组成部分：使用的数据、涉及的字段、需要处理的问题、采用的方法和最终成果。

它们被组织成一段可以直接补全的任务：

请处理【居民收入调查数据】中【家庭收入】字段的【缺失值】，采用【中位数填补】，最终输出【清洗后数据与处理报告】。

用户可以直接选择已导入的数据和字段。对于不熟悉的处理方法，系统提供简短解释；当数据特征满足特定条件时，AI 也可以给出推荐选项。

这里的目标不是教用户写出一段更专业的提示词，而是让产品承担组织任务的责任。提示词不再是用户需要掌握的技巧，而成为了界面背后的执行结果。

AI 输出的是研究步骤，而不是运行进度

在 AI IDE 中，步骤通常意味着 Agent 当前正在读取文件、调用工具或执行代码。但这些信息对社科研究者的帮助有限。

用户需要看到的不是 AI 正在调用什么工具，而是数据正在经历什么研究处理。我注意到在公司里的数据清洗工程师会使用一种叫做 Jupyter notebook 的东西来进行数据清晰，我受到了启发，我将最终输出组织成类似 Jupyter Notebook 的研究步骤。

Python 代码默认折叠。当用户或导师需要核验技术细节时，可以展开查看；但在默认状态下，代码不再主导整个阅读过程。

这个调整改变了产品的信息中心，用户首先理解“这一步对我的研究做了什么”，然后才决定是否查看“它在技术上是如何实现的”。

让用户只修改有问题的那一步

步骤化结果解决了阅读问题，但研究过程还需要允许用户干预。

以缺失值处理为例，AI 可能默认使用均值填补。用户在查看结果后，认为中位数更符合当前数据分布，或者决定直接删除缺失样本。在原来的对话中，用户需要重新描述要求，再生成一套新的代码和结果。即使只修改了一个方法，其他已经确认的步骤也可能发生变化。

在新的步骤结构中，用户可以直接进入“处理缺失值”这一步，查看使用的方法、处理数量和受到影响的数据，然后选择新的处理方式并单独重新运行。

我们这里优化了代码维度的 Diff 的概念，系统会保留修改前的版本，方便用户比较两次结果。如果当前步骤的变化会影响后续异常值检查、统计分析或回归结果，系统会明确标出受到影响的步骤，并由用户决定是否关联重新运行。

用户不需要直接修改 Python 代码，也能控制具体研究方法，以及这次修改产生的后续影响。

数据留在受控环境，AI 提供方法、代码与知识支持

ChatPython 内置 Python 环境，首先解决了用户配置环境的问题。但在受限研究场景中，它还承担了更重要的作用：让原始数据处理留在本地或指定环境中。

AI 负责理解用户已经确认的任务，并生成对应的方法和代码；Python 在受控环境中读取和处理数据；产品再将运行结果组织成可审阅的研究步骤。

为了适配垂直研究场景，我们还引入了知识库，用于补充项目文档、指标口径和研究方法。当用户处理某个经济指标时，AI 不只依赖通用模型知识，还可以参考本地资料和项目中的方法说明。相应的知识来源也会保留在分析步骤中，帮助用户理解某个判断从何而来。

环境、依赖和日志不会完全消失，但它们默认退到次要位置。普通用户无需理解这些技术信息；当运行失败或需要排查问题时，相关内容再按需展开。

本地执行解决数据边界，知识库解决研究语境。它们共同支撑的不是一个功能点，而是产品进入真实研究环境的可能性。

优化最终交付结果

如果用户只能获得一段聊天记录和一个下载文件，这次分析仍然很难进入正式研究。用户需要知道数据被怎样处理、使用了哪些方法、哪些字段发生了变化，也需要在修改数据后重新运行相同过程。

因此，我将最终结果组织成一套研究成果。在那个时候，Skill 才刚刚出现，我们简单做了摸索，制作了个固定项目结构目录的 skill，他只有一个 skill.md 文件，但是是证明我们是对的，因为截止到现在，我依然发现真正的优秀的 skill内容都是极度精简的，特别是在 AI 已经更加聪明的今天。

这个 Skill 规范了导出的文件结构，其中包括处理后的数据、原始数据备份、可重新运行的 Python 脚本、每一步的处理说明、字段变更记录、使用的方法和知识来源、生成的图表，以及完整的运行历史。

用户可以导出用于后续研究的成果包，也可以生成方便导师审核的分析说明。历史版本则帮助用户比较不同方法产生的结果，并在需要时回到之前的状态。

产品的终点由“AI 完成了这次操作”，变成了“用户获得了一套能够解释、审核和复现的研究材料”。

项目结果

1.5 天完成的 MVP 原型帮助团队在正式开发前验证了核心需求，也让我们更早发现“只解决代码生成”并不足以支持用户完成研究。原型随后获得了两个各约 500 人的目标用户社群，高校老师和学生参与了持续体验，相关反馈逐步进入正式版本的设计和开发排期。ChatPython 也开始在高校讲课和教学场景中推广使用，走进了浙江财经大学、福建农林大学等等，也获得了首批落地场景。

对这个项目而言，最重要的结果并不是证明 AI 能够写 Python，而是重新确定了产品应该帮助用户完成什么。正式版本不再只是隐藏环境和代码，而是开始围绕任务表达、过程审阅、数据安全和成果复现建立完整体验。

项目反思

垂直 AI 产品不是给通用模型换一层行业界面

项目开始时，我们试图降低 AI IDE 的使用门槛。但随着原型验证和用户反馈不断深入，我逐渐意识到，真正需要被设计的并不是代码编辑器，而是社科研究任务本身。

任务模板、字段条件、研究步骤和成果结构，不是附加在模型外面的辅助功能。它们共同完成了一次更重要的转换：将模型能够理解的技术指令，转化成普通研究者能够理解和控制的工作方式。

AI 的可信度来自过程，而不是更确定的答案

在研究场景中，一个看起来正确的答案并不足以建立信任。用户需要知道使用了什么数据、采用了什么方法、哪些内容发生了变化，以及修改某一步会产生什么影响。

因此，ChatPython 没有试图让 AI 表现得更加确定，而是通过步骤、数据影响、知识依据和历史版本，让用户能够参与判断。

快速原型的价值，是尽早推翻错误判断

最初的 MCP 原型并不好看，也不具备完整的产品体验。但它用很低的成本验证了用户意愿，也暴露了原始产品定义的不足。如果一开始直接进入正式版本，我们很可能会花更多时间优化一个“更简单的 AI IDE”，而不是重新理解用户究竟如何完成研究。