第一次在 ChatGPT 里打开 Codex 模式时我以为它只是一个能自动补全的智能终端。真正把我留在工作流里的是一个看起来很小的功能Skills。它允许我把一套固定的科研任务——比如整理文献、按期刊模板生成初稿、批量处理实验数据——打包成一个可重复调用的技能包。对于一个每周要同时处理文献、代码、论文修改的研究生来说这个功能带来的变化不是“省几分钟”而是把大量重复劳动从日程里真正剥离出去。很多人把 AI 科研工具理解成一个更聪明的聊天框于是每次遇到新任务都要重新写一段长长的 Prompt。Skills 的思路不一样它把“文献精读怎么做”“润色到什么程度算完成”“数据清洗要保留哪些字段”这些规则固化下来Agent 在遇到同类任务时直接按步骤执行。我觉得这才是 AI 进入科研工作流的关键一步——不是回答得更快而是让流程变得可控、可复用、可迭代。1. Skills 真正改变的是科研过程中最高频的“重复劳动”1.1 它不像普通 Prompt更像把一次委托变成一套标准作业程序普通 Prompt 是一次性的。你让 AI 帮你整理一篇文献它就只整理这一篇你让它润色一段摘要它就只润色这一段。下次遇到同类任务你还得重新描述背景、格式、输出要求甚至因为上下文窗口被清空AI 会忘记你上次强调的所有规则。Skills 改变了这种协作方式。它可以被理解成一套“标准作业程序”不仅包含执行步骤还包含输入输出格式、边界条件、示例和常见坑。当 Codex 或 ChatGPT 识别到当前任务与某个 Skill 的描述匹配时会自动加载这个技能包按里面写好的规则执行。这里有一个很实用的比喻普通 Prompt 像是临时口头交代别人帮忙办事细节全靠对方临场理解Skill 则是把办事流程写成一份可查阅的文档包含清单、模板和注意事项。前者适合一次性的偶发任务后者适合反复出现的固定任务。1.2 为什么这个能力对研究生特别重要研究生阶段的时间消耗很多时候不是花在“思考”上而是花在一遍又一遍地做同样的事情整理文献、核对格式、清洗数据、调参数、改语言。这些任务有两个特点一是规则明确二是重复度高恰好是 Skills 最擅长处理的类型。比如文献整理。一篇论文真正需要你动脑判断的部分是研究问题是否成立、方法是否合理、结论是否被数据支撑。但在此之前你要先把 PDF 下载下来、提取信息、做成表格、比较异同。这部分工作不需要太多创造力和判断力却非常耗费精力。把它做成一个 Skill下次再拿到一叠文件时AI 会按固定流程输出结构化笔记你只需要把时间留给真正重要的判断。更值得关注的是长期价值。Skills 不是用一次就丢的工具而是可以持续维护的工作流资产。今天你发现某个 PDF 解析器对扫描版书籍效果很差你可以把这个边界写进 Skill明天你发现某些英文论文的时态需要统一改成过去式你也能把这条规则补进去。随着时间推移Skill 会越来越贴合你的科研习惯最终变成一套属于你自己的“科研操作系统”。2. 科研中最值得先做成 Skills 的 5 件事2.1 文献调研与资料整理文献调研的痛点从来不是“读不完”而是“整理不完”。尤其是拿到一批相关论文后逐篇打开、复制标题、摘录方法、对比结论一套流程走下来半天时间就没了。用 Skill 做这件事时你可以把输入设定为“一个存放论文 PDF 的文件夹”或“一组关键词”输出设定为“结构化文献对比表格”。Skill 会按顺序做四件事确认文件是否能解析提取研究问题、方法、数据来源和主要结论判断哪些信息缺失最后生成一张 Markdown 表格。需要注意PDF 解析并不总是成功。扫描版论文、双栏排版、复杂的表格都可能让模型提取出错误信息。所以 Skill 里必须设置一条规则解析失败的文献单独标记为“需人工处理”而不是混在正常结果里。这样你的抽检成本会低很多。2.2 论文初稿与结构化写作很多研究生写不出初稿不是因为没有想法而是因为没有一个清晰的结构。对着空白文档时脑子里塞满了实验数据却不知道第一段该写什么。可以把“结构化写作”设计成一个 Skill。它根据你提供的实验记录、图表和一段背景说明按目标期刊的常规结构生成初稿框架。这个框架不是简单罗列小标题而是会检查摘要是否覆盖背景、方法、结果、结论四个要素方法部分是否有足够的复现信息图表编号和正文引用是否一致。但这里一定要守住边界AI 生成的内容是草稿不是最终结果。模型很可能补全出你并没有做过的实验细节或者把某个数据描述得比实际情况更漂亮。所以你的 Skill 里必须写清楚“所有数据必须由用户输入模型只能负责组织和表达不能自行补充实验事实”。否则这个 Skill 就会从助手变成风险源。2.3 语言润色与参考文献格式学术润色看起来简单做起来很繁琐。不是把中文翻译成英文就行还要调整语域、时态、逻辑连接词甚至要保持全文术语一致。参考文献格式更是细节黑洞一个卷号、一个页码、一个 DOI都可能让投稿前的心情变得紧张。用 Skill 处理润色时你可以约定几条硬规则不改变专业术语和数据值不删除作者想强调的限定表达修改后必须输出修改说明。这比直接给 AI 一句“帮我润色这段文字”要可靠得多因为后者经常会自作主张改变句意。参考文献校验是另一个值得固化的流程。将目标期刊的引用规范写进 Skill让它逐条检查格式问题并标出需人工确认的条目。注意AI 对参考文献的校验只能减轻负担不能完全替代人工核对。卷号、页码、DOI 这些信息最终仍然需要你亲自确认。2.4 代码、脚本与实验数据处理科研中的代码工作很大一部分不是“从零开发”而是在已有脚本上改参数、换文件、跑新数据。这种任务重复性极强非常适合 Codex 配合 Skill 来执行。你可以把数据预处理流程设计成一个 Skill读取原始数据、检查缺失值、标记异常值、选择合适的统计检验、生成图表、输出结果文件。Codex 在执行这类 Skill 时可以读取文件夹中的脚本、修改参数、运行命令并返回日志供你审查。实际操作中我的建议是先处理一个小的样本文件确认输出格式没有问题了再跑全量数据。不要一上来就直接覆盖原始文件最好保留中间产物。数据清洗中最可怕的不是慢而是搞了半天发现原始数据已经被改得无法恢复。2.5 审稿意见分析与投稿材料准备回复审稿意见大概是科研流程里最消耗心力的一环。意见往往有十几条有的需要补充实验有的只是希望你解释清楚还有的属于格式问题。如果靠手动整理很容易漏掉某条细碎的意见。一个“审稿意见处理” Skill 可以做这样几件事把审稿意见逐条拆分标记出“必须修改”“建议补充”“仅需解释”三类任务生成一个待办清单然后为每条意见起草 response letter 的对应段落。但这里有一个不可替代的环节你对每条意见的最终判断以及你是否真的完成了修改。AI 可以帮你组织语言却不能替你决定哪些修改是必要的。回复信最终署的是你的名字所以 Skill 的边界应该写清楚——它只负责整理和草拟不负责自动发送。3. 从零搭建一个科研 Skill从最小可运行到批量复用3.1 先做一个最小可用版本不要上来就搭全流程搭建 Skill 最常见的高频错误是想一次性覆盖“从文献到论文全文”的完整流程。结果往往是输入输出边界模糊Agent 不知道该在哪一步停下来最后产出一个既不像综述也不像论文草稿的东西。我的建议是先挑一件最让你头疼、但边界特别清晰的任务比如“把某个文件夹里的所有 PDF 文件名和摘要提取成 Markdown 表格”。先把这个最小版本跑通再逐步增加功能。这就像写代码时先做 MVP而不是一开始就设计一个巨型系统。注意不要第一个 Skill 追求“全流程”先让一条最简单的链路稳定运行再考虑扩展。3.2 SKILL.md 的核心结构一个 Skill 通常会包含一个描述文件常见结构包括元信息、执行步骤、输入输出约定、边界和示例。下面是一个简化的示例--- name: literature-note description: 用于把文献 PDF 整理成结构化笔记。当用户提供文献文件或关键词时按步骤提取信息并生成 Markdown 表格。 --- ## 执行步骤 1. 检查输入文件是否存在路径是否包含中文或空格。 2. 依次解析 PDF 的标题、摘要、方法、结论。 3. 如果某篇 PDF 解析失败标记为“需人工处理”不要跳过整个任务。 4. 输出 Markdown 表格包含文件名、研究问题、方法、关键结论、可复现性备注。 ## 输出格式 | 文件名 | 研究问题 | 方法 | 关键结论 | 可复现性备注 | |--------|----------|------|----------|--------------| | 示例.pdf | 该研究要解决什么问题 | 使用了什么方法 | 得出了什么结论 | 是否需要额外数据 | ## 边界 - 不生成文献综述的结论判断。 - 不处理需要授权的付费数据库抓取。需要注意不同客户端对 Skill 的字段名称和加载方式可能不一样。这个示例提供的是通用结构落地前一定要先看你当前环境的说明。不要从网上随便复制一个模板就当作所有平台都能用。3.3 把 Skill 接入 Codex / ChatGPT 的常见方式不同客户端入口略有差异但大致遵循几个步骤先安装并配置好 Codex CLI确认命令行里能正常执行。把 Skill 文件放在客户端指定的目录比如~/.codex/skills或项目内的.codex/skills。在对话中明确说明任务并提到“使用某个 Skill”或者让 Agent 根据描述自动匹配。配置完成后先执行一条简单命令确认客户端能正确读取到 Skill。这里要提醒一句不要把 API 密钥、Token 或其它敏感信息硬编码在 Skill 文件里。Skill 是一个会被 Agent 读取的文本文件如果你把密钥写进去后续分享或提交代码时很容易泄露。3.4 用“小样本—抽检—回写”迭代Skill 不是写完就结束它需要像代码一样持续迭代。我常用的循环是小样本准备 3 到 5 条输入先跑通。抽检逐条检查输出把错误类型记录下来。回写把错误案例写进 SKILL.md 的边界或示例避免下次重犯。再验证跑 10 到 20 条数据看错误率是否下降。这个思路和测试驱动开发很像。每当你发现模型在某类输入上表现不好就把这个场景写进 Skill 的“边界”或“注意事项”里相当于给 Agent 增加了一个“踩坑记录”。长期下来Skill 质量会越来越高而不是每次都要在同一个问题上纠错。4. 常见配置错误与排查链路4.1 启动失败unable to locate the codex cli binary很多人在第一次启动时遇到类似报错chatgpt failed to start. unable to locate the codex cli binary. set codex_cli_path or ensure the executable is in your PATH这个问题的常见原因有三个Codex CLI 没有安装安装后不在系统的 PATH 中客户端没有找到codex_cli_path配置。排查时先打开终端运行codex --version如果提示找不到命令说明 Codex CLI 没有安装或者 PATH 没有配置好。如果这条命令能正常输出版本号说明问题出在客户端配置需要在设置里指定codex_cli_path或者修正环境变量。注意 Windows 和 macOS 的环境变量配置方式不一样不要盲目复制网上的命令。先把路径确认清楚再改配置可以少走很多弯路。4.2 config.toml 无法加载对话串无法继续有时候启动后会出现“无法加载 config.toml”的提示甚至提示“因此此对话串无法继续请修复 config.toml”。这种情况通常是配置文件格式有问题、某个必填字段缺失或者模型名不被当前账号支持。我的建议是先备份原配置cp ~/.codex/config.toml ~/.codex/config.toml.bak。检查model、token_type、organization等字段是否与当前账号一致。如果之前改过模型名先恢复到默认配置再测试。每次只改一个字段改完立即验证。注意不要从网上直接粘贴一份完整的 config.toml。很多配置项和版本强相关他人能用的配置放在你的环境里可能会直接导致无法启动。4.3 模型不支持、接入第三方模型的边界我还见过一种报错大意是某个模型标识在使用 Codex 时不被当前账号支持。这种问题通常是因为账号类型与所选模型不匹配或者模型名称写错了。最稳妥的办法是切换回客户端默认支持的模型而不是反复修改 config.toml 去试探。有人会想把 Codex 接到其它模型上这属于自定义用法。它可以工作但需要面对兼容性、鉴权、请求格式和限流等一系列问题而且版本更新后很可能失效。我不是说完全不能尝试而是不要在重要任务的节点上依赖这种配置。可以在隔离环境里做验证但不要把整个科研流程押在一个未经验证的方案上。4.4 一套通用的排查顺序遇到问题不要急着重装环境。按下面的顺序排查通常能更快定位看现象是启动失败还是没有输出还是输出质量差看输入文件路径是否存在、格式对不对、编码有没有问题、有没有特殊字符。看环境Codex 版本、系统 PATH、目录权限、 Node 环境。看参数模型名、Skill 目录、批量数、超时时间。看边界是不是超出了当前工具的能力范围比如扫描版 PDF 解析需要 OCR而不是配置能解决的。这个顺序覆盖了大多数常见问题。很多时候问题并不在“AI 不够聪明”而是输入文件路径写错了或者环境变量没有准备好。5. 长期使用科研 Skills 的边界与建议5.1 哪些场景适合哪些场景不适合Skills 很有用但不是万能。适合做成 Skill 的任务通常有三个特征规则明确、重复性高、可以小样本验证。不适合的任务则往往涉及学术判断、创新设计和责任归属。适合做成 Skill不适合做成 Skill文献信息抽取与整理研究问题提出与假设设计论文语言润色和格式检查实验结果真实性判断数据清洗和标准统计检验复杂统计分析的解释审稿意见整理和回复草稿修改回复的最终决策如果你发现某类任务连“什么算完成”都很难定义那它大概率不适合用 Skill 来固化。强行写成一个技能包只会增加验证和纠错成本。5.2 学术伦理AI 是流程助手不是责任转移工具AI 工具能提高效率但不会替你承担责任。论文里所有数据和结论最终都需要你亲自核验。使用 AI 工具时要遵守学校、期刊和基金项目的具体政策不同机构对“AI 润色”“AI 辅助写作”“AI 生成代码”的要求可能完全不同。我的原则是把 Skill 的输出当作第一轮草稿而不是最终答案。文献整理表格要抽查代码运行结果要检查审稿回复要复核润色后的段落要通读。AI 能帮你做的事情越多你越要清楚哪些环节不能交给它。5.3 把 Skills 沉淀成个人科研方法论长期使用 Skills最有价值的不是“让 AI 帮你干活”而是你开始学会拆解任务、定义边界、验证质量。每一次把新坑写进 Skill每一次补充新的示例都是在建立你自己的科研基础设施。我现在的做法是每个项目结束后把项目中出现的常见问题和优秀模板回写到对应 Skill 里。时间长了这些 Skill 就不再是简单的提示词集合而是一套带有个人判断和经验的技术文档。它们和实验记录、代码仓库一样是长期积累的资产。如果你也想开始不要急着搭全流程。先挑一件最让你头疼的重复事写一个最小可用的 Skill跑通第一条样例。等你感受到“把固定流程交给 AI自己只做判断”的体验就会明白这个功能真正的价值在哪里。