企业官网建设流程全解析

罕见癌症治疗方案耗尽之后，一位掌握编程能力的技术创始人，选择用 AI 把自己变成研究对象，也变成研究工具。GitLab 联合创始人 Sid Sijbrandij 的故事在技术圈传开之后，很多人第一反应是“AI 又创造奇迹了”。但如果你把这件事放到工程视角看，会发现它真正的价值不在于某一款大模型，而在于一条可以反复迭代的 AI 研究流水线。

这篇文章不打算把 Sid 的故事包装成励志鸡汤，而是想拆解一个问题：当一个普通人拥有代码、数据、模型和可追踪的实验平台时，医学研究这件事会发生什么改变。文章会从故事背景、AI 医学应用的技术逻辑、最小可运行示例、GitLab CI/CD 的落地方式、风险边界等角度展开。读完你会得到一个明确判断：AI 辅助科研不是“让大模型猜答案”，而是用软件工程方法把假设、验证和数据串起来。

1. Sid 的故事里，程序员最该看到的不是奇迹

公开报道中，GitLab 联合创始人 Sid Sijbrandij 在 2019 年公开了自己患有一种罕见癌症的消息，后来在治疗手段有限的情况下，他开始借助 AI 工具研究自己的基因、蛋白质结构以及最新的医学文献。这个信息在技术社区引起关注，核心原因不是大模型突然有了“医术”，而是 Sid 把“自我治病”这件事，做成了类似开源项目的模式。

如果我们把事件中的情绪词全部去掉，只看技术动作，会发现完整链路非常清晰：先收集可公开访问的医学数据；再用 AI 对结构、变异和文献做分析；然后形成新的研究假设；最后把结果分享给专业医生去验证。所有环节都围绕“信息密度”展开。传统诊疗路径中，患者得到的是结论；而 Sid 的路径中，患者主动参与到假设构建和证据筛选的过程里。

程序员从这个故事里真正应该提取的，是“模型 + 数据 + 工程平台”三位一体的工作方式。不是说每个普通人都能用 AI 治好难治疾病，而是说过去只有专业研究机构才能完成的信息分析，现在可以在个人计算设备上以极低门槛执行。这种能力下沉，才是值得技术圈认真讨论的变量。

2. AI 辅助医疗研究到底在解决什么问题

很多人把 AI 医疗窄化成“聊天机器人给建议”，这是最大的误区。聊天式问答只是交互层，真正的技术价值集中在下面三个方向。

2.1 蛋白质结构预测：让微观世界变得可计算

AlphaFold 等模型把蛋白质三维结构预测问题变成了计算问题。过去，科学家要通过复杂的实验解析蛋白质结构，周期长、成本高。现在，序列输入模型之后就能得到结构打分和置信度结果。对于涉及罕见突变的研究来说，这种“从序列到结构”的能力，能帮助研究者快速判断某个突变是否影响蛋白质稳定性，并据此设计后续实验。

2.2 文献与知识检索：从“读不完”到“检索完再读”

医学文献每年以百万篇级别增长。任何个人都无法靠人力读完全部相关论文。大语言模型结合向量检索或关键词检索，可以先把粗筛任务交给机器，再由人判断输出结果。Sid 的做法可以理解为：让 AI 先完成“文献综述的初稿”，医生和研究者再做深度验证。

2.3 多模态数据处理：把基因组、影像和结构化报告放在同一套流程里

真实医疗数据往往不是一张干净的表格，而是由基因组变异、病理报告、影像检查结果、用药记录共同构成。AI 的价值之一是能用统一的数据管道做汇总分析，减少信息在人工转述中的损耗。这与后端工程师非常熟悉的“数据抽取—清洗—建模—服务”模式几乎同构。

所以，AI 辅助医疗研究的本质是“计算辅助决策”。它不会自动产生临床结论，但它能把大量不确定信息压缩成几条值得验证的假设。

3. AI Agent 在科研场景中扮演的角色

最近技术圈高频词汇里，Agent 排在前列。GitLab、AI Agent、AI 编程等搜索热词也反映了开发者对自动化智能体的兴趣。所谓 Agent，在这个场景下可以理解为一个“边界明确、能力有限但会自动执行任务的程序”。

科研场景下的 AI Agent 一般需要完成三个工作：根据目标检索数据；调用模型做推理；把输出整理成结构化结果。这听起来简单，落地时最容易出问题的通常是第二步。模型输出具有一定随机性，如果不对输出做校验、不要求模型标注答案来源，Agent 就会变成一个“自信的造谣机器”。

更稳妥的设计是，把 Agent 当做一个“初级研究员”而不是“决策者”。它负责收集证据、生成假设、列出矛盾，最终结论仍然由具有临床资质的专业人员判断。这也是医疗 AI 与通用 AI 最本质的区别：错误成本不同，安全边界要求不同。

4. 用“检索增强生成”搭建一个最小 AI 研究助手

理解了原理之后，最好自己动手跑通一个最小示例。下面这个项目使用“检索增强生成”的常见模式：先对少量文献片段做索引，再根据用户问题检索最相关内容，最后把检索结果交给 OpenAI 兼容接口进行结构化输出。

这种方式的好处是兼容本地模型。你可以把 base_url 指向本地推理服务，也可以换成云服务，代码不用大改。

4.1 项目结构和环境准备

ai-research-assistant/ ├── app/ │ └── research_assistant.py ├── requirements.txt └── README.md

Python 环境建议使用 3.10 或更高版本。需要安装的依赖如下：

pip install openai

如果你的模型服务不需要 OpenAI 的官方 SDK，也可以直接用 HTTP 客户端调用。为了减少读者配置负担，这里用 openai 的兼容接口。

4.2 完整代码

文件路径：app/research_assistant.py

import argparse import os import re from openai import OpenAI # 这里仅作为演示知识库，实际项目中应替换为经过清洗后的专业文献片段。 DOCS = [ "在罕见肿瘤中，肿瘤突变负荷和免疫微环境可能影响免疫治疗应答。", "蛋白质结构预测可帮助评估错义突变对蛋白稳定性的影响。", "分子对接与虚拟筛选用于寻找靶点候选化合物，但需要实验验证。", "多组学数据整合能够提高对复杂疾病机制的解析能力。", ] def build_index(docs): """构建一个轻量关键词索引。""" index = [] for text in docs: kws = set(re.findall(r"[\w\u4e00-\u9fff]+", text.lower())) index.append({"text": text, "kws": kws}) return index def retrieve(query, index, top_k=3): """根据关键词重合度返回最相关的文档片段。""" qk = set(re.findall(r"[\w\u4e00-\u9fff]+", query.lower())) ranked = sorted(index, key=lambda item: -len(qk & item["kws"])) return [item["text"] for item in ranked[:top_k] if qk & item["kws"]] def main(): parser = argparse.ArgumentParser(description="AI 文献检索增强示例") parser.add_argument("--query", default="免疫治疗 罕见肿瘤 关键因素") parser.add_argument("--top-k", type=int, default=3) args = parser.parse_args() index = build_index(DOCS) context = retrieve(args.query, index, args.top_k) client = OpenAI( base_url=os.getenv("LLM_BASE_URL", "http://localhost:11434/v1"), api_key=os.getenv("LLM_API_KEY", "local"), ) user_prompt = "请基于下面材料，指出值得验证的关键假设：\n\n" + "\n".join(context) response = client.chat.completions.create( model=os.getenv("LLM_MODEL", "qwen2.5:7b"), messages=[ { "role": "system", "content": "你是一位严谨的医学研究助手。只能依据材料回答，" "不确定时说明需要实验验证，不要编造文献结论。", }, {"role": "user", "content": user_prompt}, ], temperature=0.2, ) print(response.choices[0].message.content) if __name__ == "__main__": main()

这段代码的逻辑不需要特别深的机器学习背景就能读懂：先对文档做关键词索引；再对问题做同样的处理；接着按重合度排序；最后把命中内容组装成带约束提示词，交给模型总结。

注意几个设计细节。第一，temperature 设成 0.2，是为了减少模型输出的随机性。第二，系统提示词明确要求“不能编造文献结论”，这是在为幻觉兜底。第三，知识库只是一个可替换的小列表，真实项目里应该把它换成结构化数据库或向量数据库。

4.3 运行和验证

如果本机已经有一个 OpenAI 兼容的服务，例如 LM Studio、Ollama 等，可以直接运行：

export LLM_BASE_URL="http://localhost:11434/v1" export LLM_API_KEY="local" export LLM_MODEL="qwen2.5:7b" python app/research_assistant.py \ --query "蛋白质结构预测 突变 稳定性" \ --top-k 2

正常情况下，程序会输出一段由模型生成的假设说明，并且建议如何通过实验验证。如果模型没有返回内容，先检查 base_url 是否可访问、模型名称是否匹配，而不是先去调试 Python 代码。

5. 用 GitLab CI/CD 让实验变得可复现

很多人是在 GitLab 相关搜索词里发现 AI 应用场景的，比如 Docker 安装 GitLab、GitLab CI/CD 依赖仓库地址、GitLab 配置 SSH 密钥等。这说明工程化部署是实际需求。AI 研究场景同样需要 CI/CD，原因非常简单：实验不能只在自己电脑上跑一次。

当知识库文件变化、提示词变化、模型版本变化时，你是否还能复现上一次的实验结果？如果答案是不能，那这份研究就像没有版本管理的代码一样危险。

GitLab 的 CI/CD 可以很好地解决这个问题。你可以把代码、数据描述、提示词模板全部提交到仓库，用 Runner 执行标准化任务，并把结果作为 artifacts 归档。

5.1 一个通用 AI 实验流水线示例

文件路径：.gitlab-ci.yml

stages: - lint - experiment - report lint: stage: lint script: - python -m flake8 app/ - echo "代码规范检查通过" tags: - docker experiment: stage: experiment script: - python app/research_assistant.py --query "罕见肿瘤 免疫治疗 关键机制" --top-k 3 - python app/evaluate.py > outputs/metrics.json artifacts: paths: - outputs/*.json expire_in: 2 weeks tags: - docker report: stage: report script: - echo "实验结果已归档，请人工复核后再进入下一阶段" artifacts: paths: - outputs/ tags: - docker

这个流水线体现了一个原则：把实验步骤拆成代码、参数、产物三个阶段。lint 阶段负责最基础的代码质量门槛；experiment 阶段执行检索增强脚本，并把模型输出和评估指标写入 JSON 文件；report 阶段只是提示人工复核。

5.2 在 GitLab 中管理模型服务环境和变量

CI/CD 脚本经常需要访问模型服务，此时不要把 API Key 直接写在 yaml 文件里。GitLab 提供了 CI/CD Variables 功能，可以在项目 Settings -> CI/CD -> Variables 中配置。

# 推荐在 GitLab Variables 中配置这些变量 LLM_API_KEY: "$LLM_API_KEY" LLM_BASE_URL: "$LLM_BASE_URL" LLM_MODEL: "$LLM_MODEL"

这样做的好处是代码仓库泄露以后，包含环境的运行依然有密钥保护。医疗研究场景对数据权限要求更高，更应该遵循密钥最小暴露原则。

5.3 Docker 部署 GitLab 时的最小配置

如果本地开发需要快速拉起 GitLab，可以使用 Docker。这里给一个适合测试环境的最小命令。

sudo docker run -d \ --name gitlab \ --restart unless-stopped \ -p 80:80 \ -p 22:22 \ -e GITLAB_ROOT_PASSWORD='YourStrongPassw0rd' \ -v /srv/gitlab/config:/etc/gitlab \ -v /srv/gitlab/logs:/var/log/gitlab \ -v /srv/gitlab/data:/var/opt/gitlab \ gitlab/gitlab-ce:latest

生产环境不建议直接把 root 密码通过环境变量暴露，更稳妥的方式是先启动容器，再用 gitlab-rails 或配置模板修改密码。无论采用哪种方式，都要先确认/srv/gitlab下对应的目录权限正确，否则容器可能会启动失败。

6. 医疗 AI 工程中的安全边界与风险控制

讨论 AI 治病时，很容易陷入两个极端：要么神话模型能力，要么完全否定应用价值。事实上，医疗 AI 的工程落地最需要的是“边界感”。

6.1 数据合规是第一步

真实医疗数据涉及个人隐私，绝不是拿到一个 Python 脚本就可以随便分析的。任何涉及临床数据、基因数据的处理，都必须符合当地法律和伦理要求。个人开发者可以用脱敏后的公开数据做研究，但不能把未经授权的患者数据上传到外部大模型服务。

6.2 模型的输出不等于临床证据

大语言模型擅长生成连贯的文本，但它不理解概率背后的统计模型，也不能替代实验室结果。AI 生成的内容只能作为线索，不能作为最终临床依据。研究闭环中应该加入“人工复核”这一步，并且由具备资质的人执行。

6.3 可解释性与记录溯源

医疗场景对可解释性的要求远高于普通开发。如果 AI 提出一个假设，研究员需要知道这个假设来自哪篇文献、哪个数据片段。因此，输出的答案最好附带引用片段。前面示例中的检索函数虽然简单，但它已经比直接让大模型自由发挥要安全，因为结果总能追踪到知识库中的原始文本。

6.4 建立失败回滚机制

GitLab CI/CD 天然支持版本回滚。当新的实验任务生成异常结果时，可以回滚到上一次成功的 commit，快速定位是数据、代码还是提示词导致的偏差。这在真实研究中非常重要，因为医学实验很难接受“不可恢复”的错误。

7. 常见 GitLab 与 AI 项目问题排查

实际使用中，开发者遇到的技术问题高度集中。下表总结了几个典型场景和排查路径。

这里有一个容易被忽略的点：GitLab 的 422 登录错误并不一定和 GitLab 本身有关。很多情况下是前端代理把 HTTPS 请求转成了 HTTP，导致 CSRF 校验失败。先用隐身模式验证是否为本地 Cookie 问题，这是成本最低的排查手段。

8. GitLab 安全与权限管理的工程建议

AI 研究项目的仓库通常会包含数据描述、模型配置和 prompt 模板。这些文件的敏感程度不一样，权限管理有必要尽早考虑。

8.1 代码与数据分离

不要把大文件数据直接放进 Git 仓库。推荐使用 Git LFS，或者把数据放在对象存储中，并在 CI 阶段读取。这样既能保持仓库轻量，也能减少密钥和敏感数据被误提交的风险。

8.2 依赖和镜像管理

公共镜像源虽然是默认选择，但生产环境为了稳定和安全，通常会配置内网镜像。GitLab Runner 可以支持在容器内使用自定义镜像，并把依赖缓存挂载到持久化存储中。这样能显著减少重复下载的时间和网络风险。

8.3 最小权限原则

给每个自动化任务配置独立权限。用于 CI 的 token 不应该同时拥有管理员权限；用于模型服务的 token 也尽量限定访问范围。医疗研究数据一旦泄露，后果比普通代码泄露严重得多。

9. 下一步实践建议

如果你希望在 AI 辅助研究方向上深入，可以按下面三个阶段推进。

9.1 先跑通最小闭环

用公开数据集或脱敏后的文档片段，搭一个检索增强生成脚本，并用 GitLab CI 跑一次完整的 lint、experiment、report 流程。目标是让自己习惯“代码、数据、结果”三者可复现的工作方式。

9.2 再增加模型评测

不要只看模型输出的文字是否通顺。把每次实验的输出保存下来，人工或程序化地给它打分。常见的评测维度包括相关性、事实一致性、引用完整性。评测结果作为产物归档，用于下一次迭代对照。

9.3 最后引入人工验证环节

当模型表现相对稳定后，把结果交给专业人员进行复核。所有 AI 生成内容都保留原始引用片段，方便复核者理解。只有专业人员的判断才能作为下一步计划的基础。

Sid 的故事给技术社区带来的真正启发，不只是“AI 多厉害”，而是“一个具备工程能力的人，可以在信息洪流中快速缩小自己的认知盲区”。代码、模型和协作平台刚好构成了这个时代最强大的个人研究基础设施。工具已经摆在那里，门槛也已大幅下降，剩下的问题只在于你是否愿意用工程方法去组织验证和迭代。

建议先收藏本文，按照第 4 节的最小示例跑通一次，再结合第 5 节把流程自动化。毕竟，AI 领域的真正壁垒经常不在模型，而在工程化能力。