企业官网建设流程全解析

经常看到有人收藏了一堆“科研神器”，到头来还是用不好AI。最近GitHub上有个趋势特别明显：真正能让科研效率提升的，不是某个模型多聪明，而是一类叫Skills的东西。这里的Skills不是指你的个人能力，而是给AI Agent用的“技能包”。一个Skill就是一套结构化的操作手册，里面写清楚在什么场景下、按什么步骤、怎么调用工具，AI拿到它就知道该怎么干活。科研流程这么长，从选题、文献、实验、写作到投稿，每个环节都能用Skill把“专家经验”固化下来。这篇文章我按研究流程筛了10个GitHub项目，把每个项目适合在哪个阶段用、怎么选、会踩什么坑，一次讲明白。

1. 科研Skills的基础认知：为什么它比“提示词”更值得研究

1.1 Skill不是提示词，是给AI的“操作手册”

很多人以为给AI写一段详细的prompt，效果就和Skill差不多了。其实不是一回事。一个真正的Agent Skill，在GitHub仓库里通常是一个目录，里面有SKILL.md、scripts、resources等文件。SKILL.md的头部用YAML格式写name和description，正文是具体的执行步骤、约束条件和输出格式。scripts目录放可执行的脚本，resources可以放模板或参考数据。

打个比方，prompt相当于你随口跟实习生说“帮我把数据处理一下”，Skill则是一份完整的SOP，里面写着“第一步读哪个文件，第二步怎么清洗，第三步输出什么格式的报表”。科研流程里质量要求高、步骤多，AI如果只凭一句提示词自由发挥，很容易跑偏。用Skill相当于给AI套上了一套成熟的方法论，它知道文献综述要先确定检索范围再做筛选，而不是直接把摘要堆给你。

1.2 科研场景选Skills，我会盯住4个标准

GitHub上的Skill项目五花八门，但不是每个都适合科研。我看了不少仓库后，总结出四个判断维度：

科研讲究可复现。一个Skill如果是闭源的，或者每次执行结果都随机漂移，那它再强大我也不敢用。本地文件访问能力也很关键，好的Skill应该能读取你的文献库、数据文件和代码仓库，而不是只靠模型训练时的记忆。可组合性则是从“科研流水线”的角度考虑——文献筛选Skill输出的文献清单，最好能被数据分析Skill直接消费，这样各环节才能串起来。

2. 10个GitHub项目按研究流程拆解

2.1 选题与文献阶段：先把方向收窄

2.1.1 anthropics/skills：官方技能包，适合做“第一个Skill”

这个仓库是Anthropic官方维护的Skill集合。它最大的价值不一定是某个现成的科研功能，而是官方定义的Skill结构、写法和示例。如果你刚开始接触Agent Skills，我建议先把这个仓库clone下来，仔细读几个SKILL.md文件，你很快就会理解“技能包”的标准格式。

里面有一些文本处理、信息提取、代码分析方向的skill可以用到科研里。实操时，把需要的skill目录复制到当前项目的.claude/skills目录，或者放到全局的Agent配置目录，AI就能在对话中按需调用。

要提醒一句：官方示例为了通用，很多内容需要自己改造。比如一个通用的“document-processing”skill，它不会自动理解你的论文到底要分析什么变量，你得补充领域背景。这个仓库更适合当模板库，而不是开箱即用的科研工具。

2.1.2 obra/superpowers：把科研任务拆成“可执行步骤”的超级技能包

obra/superpowers是我在科研项目里用得比较多的一个Skill集合。它由开发者Jesse Vincent维护，核心思路是把复杂的软件工程和写作任务，通过一系列追问和引导，拆解成可执行的步骤。比如“brainstorming”Skill会不断让你澄清目标、风险、限制条件，而不是急着给方案。

这个特点用在科研初期特别合适。课题方向模糊的时候，你可以让AI基于superpowers中的brainstorming Skill，和你对话把假设收敛下来。还有planning、debugging、review等能力，几乎覆盖了做实验和写代码的主要环节。

它主要面向Claude Code，安装方式是把仓库clone后，把需要的skills目录复制到~/.claude/skills。使用时有斜杠命令可以唤起。需要注意的是，这套技能的设计哲学是“强制结构化思考”，如果你的基础模型能力较弱或者你只想要快速答案，可能会觉得它啰嗦。但在科研这种需要严谨逻辑的场景里，慢一点反而是好事。

2.1.3 zotero/zotero：本地文献库的“数据底座”

Zotero本体是开源项目，也是我本地文献管理的核心。它和AI结合的方式有点特别：Zotero不直接算Skill，但它的本地数据库、PDF存储、元数据和笔记接口，能让其他Skill读取“你真实在用的文献”。

比如我用Better BibTeX插件导出文献库的JSON文件，再写一个简单的Skill，让AI基于这个导出的数据做综述整理、关键词聚类、研究脉络分析。这样做的好处是，AI引用的论文不是它自己编的，而是你Zotero里真实收藏的文献，可追溯性强。

选Zotero还有一个原因：它有强大的插件生态，很多实验室已经在用Zotero做团队文献共享。把AI技能和这个工作流对接，不会改变你原有习惯。唯一要注意的是，Zotero的存储路径在不同操作系统上不一样，Skill脚本读取路径时最好用环境变量，别写死。

2.2 实验与数据分析阶段：让AI动手做实验

2.2.1 jupyterlab/jupyter-ai：Notebook里的AI助手

科研数据分析最常用的工具还是Jupyter Notebook。jupyter-ai是JupyterLab官方出的AI扩展，可以把LLM直接接入Notebook，支持对话、代码生成、代码解释等能力。选中一段代码，AI能直接告诉你它在干什么；生成一段绘图代码，结果会直接出现在Notebook里。

它非常适合做探索性数据分析，因为每一步的中间结果都保留在notebook里，变量怎么变化、图怎么出来的，全部有迹可循。相比在终端里用AI，这种方式对科研人员更友好，不用切换环境。

避坑点在于，AI生成的代码“看起来能用”和“实际正确”是两码事。特别是读取数据之后，变量类型、单位、缺失值处理这些细节，AI经常会忽略。必须自己检查每一列的输出，别把地图炮式生成的代码直接用于实验。

2.2.2 microsoft/graphrag：从文献中抽一张知识图谱

GraphRAG是微软开源的一套基于知识图谱的检索增强生成方案。它和普通RAG不太一样，不是把PDF切块做向量检索，而是先从文档中抽取实体和关系，构建一张知识图谱，再基于图谱做问答和摘要。

这个方法在科研综述里非常有用。你把一个文件夹的PDF论文喂给GraphRAG，它能自动抽出“方法A”、“数据集B”、“性能提升C”这样的实体关系，然后回答“这几篇文献在方法演进上是怎样一条线”的复杂问题。普通RAG很难回答这种跨文档推理问题。

配置成本是它的门槛。你需要一个效果不错的Embedding模型和LLM，如果本地有GPU当然最好，没有的话也可以调用API。另一个常见坑是PDF解析质量，扫描版PDF抽出来的是乱码，图谱质量会很差。建议尽量用干净的数字版论文。

2.2.3 aider-ai/aider：给科研代码仓库配一位“结对编码员”

Aider是终端里的AI结对编程工具。和IDE插件最大的区别是，它会直接操作你当前的git仓库，每次AI修改代码都会生成diff，并自动创建git提交。科研代码的每一次试验改动都能回溯，这个能力非常重要。

你可以让Aider帮你写数据清洗脚本、修bug、补单元测试，或者重构一个实验函数。因为它会在一个明确的目录下运行，所以不会像某些插件那样“满世界乱改”。我经常在feature分支上跑Aider，改坏了就回滚，完全不影响主分支的稳定版本。

这里有个使用建议：Aider默认会直接把修改提交到当前分支。如果你不想让AI的尝试性改动污染主分支，先git checkout -b experiment，再启动Aider。这样每一轮实验的代码记录是干净的，后面写技术报告时甚至能直接看提交记录复盘。

2.2.4 openai/codex：无人值守型的“实验执行员”

OpenAI开源的Codex CLI是另一个很能打的项目。它可以在命令行环境中自主完成编码任务：你对它说“在这份数据上实现三种回归模型并对比结果”，它会自己读文件、写代码、运行、修改，最后汇报结果。

和Aider相比，Codex更适合无人值守的批处理任务。比如要换一组超参数重跑模型、生成多个模型的效果对比表，这类重复劳动正是Codex擅长的。它有沙箱隔离和权限询问机制，不会未经允许就执行危险命令。我在跑一些计算量不大但步骤繁琐的实验时，经常把它挂在那里跑完再看结果。

避坑核心是任务描述要足够具体。不要只写“分析这份数据”，要告诉它输入文件路径、输出文件格式、约束条件、评价指标。描述越模糊，它自由发挥的空间越大，最后出来的结果往往不符合预期。

2.3 写作、排版与成果交付：让产出可复现、好看、能交互

2.3.1 quarto-dev/quarto-cli：用Markdown写论文

Quarto是RStudio团队出品的学术出版框架，允许你用Markdown或Jupyter Notebook写论文，然后渲染成PDF、Word、HTML等多种格式。对科研复现来说，Quarto强在“代码和文字共生”：你在.qmd文件里写论文正文，中间插入Python或R代码块，渲染时代码会真正运行，运行结果和图表直接嵌入最终文档。

我一般用Quarto做技术报告和论文初稿。数据一变，重新render一次，正文里的数字和图就全部更新，不会出现“图是旧数据”的问题。安装时需要TinyTeX来生成PDF，第一次配置会花点时间，但后续体验很顺。

要注意的是，Quarto生成的Word文件格式和某些期刊的投稿模板不一定完全匹配。如果你投的期刊要求严格模板，Word输出往往需要手工调整格式。我的做法是先用Quarto做初稿，投期刊时再导出LaTeX或Word到模板里微调。

2.3.2 typst/typst：替代LaTeX的现代排版引擎

Typst这两年热度很高，是一种面向学术排版的标记语言。语法比LaTeX友好得多，编译速度也快，报错信息对新手很友好。公式、图表、参考文献的支持已经相当完善，社区里还出现了不少中文学术模板。

如果你写论文最头疼的是LaTeX宏包冲突和编译失败，Typst是个很棒的替代方案。我在写带有大量公式的方法部分时，会用Typst做最终排版。它生成的PDF界面干净，代码量比LaTeX少一半以上。

避坑点是，某些期刊编辑系统只接受Word或LaTeX源码。Typst当前还在快速发展，模板兼容性比LaTeX弱。投稿前务必确认目标期刊是否接受Typst生成的文件，如果不行，就导出PDF后用其他工具转换，或者退回Quarto。

2.3.3 streamlit/streamlit：把科研成果变成交互式演示

Streamlit是用纯Python写Web应用的框架。它在科研场景里最好的用途，是把论文里的数据集、模型实验和图表包装成一个可交互的Demo。审稿人、导师或者合作方可以在网页上直接调参数、看结果，比贴一张静态图直观很多。

我做过一个光伏预测课题的演示页，用Streamlit加载历史数据，做特征分布图，并让用户选择不同模型和预测窗口，动态看误差对比。整个开发过程只用了不到一百行Python，没有写前端代码，非常适合不懂前端的研究人员。

一个比较常见的坑是，Streamlit每次点击控件都会从头到尾重跑脚本。如果数据加载很慢，页面会卡。解决办法是用@st.cache_data装饰器缓存数据加载函数，把耗时操作的结果缓存起来。

3. 实操示范：一个课题怎么把Skills串成流水线

3.1 场景设定与Skill组合

假设我们有一个课题：某地区光伏发电功率的短期预测。这个课题很典型，既要做文献综述，又要处理时序数据，还要对比多个模型，最后要交论文和可复现代码。

我把前面提到的项目按流程组合起来：

在实际执行时，我会在项目目录里先把这些Skill的目录组织好，让AI能在正确的上下文里工作。

3.2 核心步骤与命令示例

先建立项目仓库和实验分支：

# 初始化科研项目 mkdir solar-forecast && cd solar-forecast git init git checkout -b experiment # 把需要的 skill 复制进当前项目（以 Claude Code 为例） mkdir -p .claude/skills cp -r ~/superpowers/skills/brainstorming .claude/skills/ cp -r ~/superpowers/skills/planning .claude/skills/ cp -r ~/anthropics/skills/research .claude/skills/

进入Claude Code后，先唤起brainstorming技能，把预测目标、数据来源、评估指标这些关键问题理清楚。如果你跳过了步骤直接让AI写模型代码，后面很可能返工。

文献阶段，先用Zotero建好一个光伏预测方向的文献分类，导出JSON，再让GraphRAG基于这堆PDF构建知识图谱。我建议分两批喂文档，第一批30篇经典文献，第二批20篇最新进展，图谱效果最好。一次性喂100篇，知识图谱会乱，问答质量也会下降。

实验阶段，Jupyter-AI负责快速画时序数据和特征相关性，aider负责维护数据清洗和特征工程代码，codex负责跑多个模型的对比实验。这三者配合时，我会让aider先搭建好数据和实验的框架，再让codex在framework基础上做参数扫描。如果把codex丢进一个没有结构的仓库，它会自顾自地创建一堆新文件，最后整合成本很高。

写作阶段，Quarto写技术报告，数据和图表自动更新。报告完成后，用Typst排版最后的投稿稿。因为Typst语法更简洁，公式多的时候比LaTeX舒服很多。最后用Streamlit做一个简单Demo，方便组会和评审演示。

4. 常见问题与避坑速查

4.1 问题排查表

我在实际操作中遇到过不少问题，整理成一张速查表：

4.2 我自己的选型建议

如果你是第一次接触科研Skills，我不建议把上面10个项目全部装上。那会让自己被工具淹没。我的建议是分阶段引入：

新手期，只需要把anthropics/skills和Zotero玩明白。前者让你理解Skill是什么，后者给你一个稳定的文献数据底座。数据分析和写作先用最熟悉的工具，比如Jupyter和Word，等流程稳定了再换更高效的。

做了一段时间后，再把jupyter-ai和aider引入实验环节。这两个工具改动你的工作习惯不大，但能明显提升代码效率。aider的git自动提交机制会逼着你保留实验记录，值得养成习惯。

如果你想追求更高的自动化程度，再考虑codex和graphrag。codex处理批处理实验，graphrag帮助做综述推演。这两者有一定配置门槛，适合已经有AI工作流积累的团队。

排版和交付这边，Quarto优先级高于Typst。因为Quarto能直接和代码分析流程打通，可复现性更强；Typst主要用于最终稿的精细排版。Streamlit则看具体需求，如果你的成果需要频繁演示，很值得投入。

最后分享一个很小但很管用的习惯：把Skill当成代码一样做版本管理。我会在课题仓库里专门建一个skills目录，把当前课题用到的Skill文件固定下来。这样团队其他人clone仓库后，AI环境完全一致，问题可复现。每次发现某个Prompt流程能稳定产出好结果，我也会把它固化成新的Skill，给这个目录做一次commit。这样AI对科研的帮助会随着项目积累越来越强，而不是每次从零开始调提示词。