A personal protocol from low-energy nuclear theory

把物理之外的一切交给 AI
把省下的时间用来做更多的物理

下面这两个数字来自同一个导师、同一套物理、同一类问题。变量只有一个：谁在写代码。

2024 · 同济保研博士生 + GPT-4 网页版
90天
单通道散射 emulator · 1 channel · 少量参数
Liu, Jin Lei, Ren · Phys. Lett. B 858, 139070 (2024)
vs
2025-12 · 我 + Claude Code CLI
4天
CDCC reduced-basis emulator · 37 channels · 18 parameters
Jin Lei · Phys. Rev. C 113, 044610 (2026)
复杂度 ×10，时间 ÷20。等效加速 ≈ 200×。
这不是因为我变聪明了。是工作流变了。
四个月内多篇论文产出的可视化时间线
2025-12 → 2026-04 · 4 个月 16 篇
Why this works

计算物理的 80/20

一个项目的智力内核（一个想法、一个算法、一个数值不稳定的来源）通常在几天到几周内结晶。 把它变成一篇发表论文，要花几个月到几年。 传统流程里，implementation overhead 占据绝大部分时间。

implementation overhead 与物理判断之间的工作流转移插图
Implementation overhead 80% 智力内核（物理判断）20%
拖动滑块：看 implementation 占比如何改变你能独立推进的深度项目容量
代表性论文 / 深度项目*：约 50 篇
这是主导型产出的粗略量级，不是署名总数。
* 粗略假设 35 年 × 54 周 × 40 小时 = 75600 小时； 一篇代表性论文 / 一个成熟项目中不可外包的物理判断、验证和论文取舍约 300 小时。 这里估算的是主导型产出的量级，不是合作署名论文总数。
Vibe Research = 人的判断力 × LLM 实现速度。 问题选择、物理判断、数值直觉、结果解释、最终筛选 — 这些不可外包。 文献综合、样板代码、算法实现、debug、图表、初稿、审稿回复 — 这些可以加速一到两个数量级。
First 10 minutes

第一次打开 Claude Code，只做这五步

初学者最容易犯的错，是一上来让 agent 接管整个研究问题。第一次会话只应该做一次可验收的试跑： 让它读真实项目、定位一个小任务、生成一个可检查输出，然后停下来由你判断。

01

进真实项目目录

不要在空聊天里描述项目。先让 agent 看见代码、数据、README、旧图和日志。

cd <project> && claude
02

只给一个小目标

目标必须能在 10 分钟内验收，例如重画一张图、补一个 smoke test、解释一个报错。

03

先读，不许先改

让它先总结现状、入口、数据路径、风险点。没有读到文件之前，不接受实现方案。

04

给 benchmark

哪怕只是一个旧数值、一张文献图、一个解析极限，也要先把通过标准写出来。

05

结果出来就停

第一次会话的目标不是继续扩展，而是确认这个工作流是否能被你审查和控制。

Starter brief

10 分钟试跑模板

把第一次会话压到最小：只读项目、选一个小输出、跑一个验证。这个模板的重点是让 agent 停在你能检查的地方。 

今天只做一个 10 分钟试跑。

目标：<one small output>
允许改：<one file or no files>
验证：<one command / one figure / one number>
停止条件：输出结果后停下来，不要继续扩展。

请先只读相关文件，回答：
1. 你看到的项目入口是什么
2. 这个小目标最可能涉及哪些文件
3. 最小验证怎么做
4. 如果你不确定，请列出需要我确认的问题
Stop rules

这些情况不要让 AI 自由发挥

  • 你还说不清 benchmark、单位、相位、归一化或边界条件。
  • 输出会进入论文主 claim，但还没有独立参考或 worst-case 检查。
  • agent 连续两轮偏离你的具体指令，开始自创另一套实现。
  • 结果“看起来合理”，但你还不能解释为什么物理上应该这样。
New paradigm

什么是 Vibe Coding

传统编程的核心动作是“人把意图翻译成代码”。Vibe Coding 的核心动作变成： 人用自然语言、运行结果和反馈来驱动 AI 生成代码，再用测试和判断筛选结果。 也就是说，人从逐行施工者，变成了目标设定者、审稿人和系统导演。

传统编程和 Vibe Coding 两种工作流的对照插图
传统编程循环插图
Old loop

传统编程

人先把问题拆成架构、接口、算法和边界条件，然后手写实现、手动 debug、手动补测试。速度主要受“打字 + 查 API + 重构 + 细节记忆”限制。

  • 优势：控制精确、路径透明、可预测。
  • 瓶颈：大量时间花在重复实现和样板细节上。
  • 适合：高风险底层系统、需要完全可控的核心模块。
Vibe Coding 循环插图
New loop

Vibe Coding

人描述目标、约束和反馈，AI 快速生成实现。人的主要工作不是替 AI 写每一行，而是不断判断输出是否满足真实目标，并把系统拉回正确方向。

  • 优势：原型、重构、接口胶水和调试速度极快。
  • 风险：AI 会自信地写出“看起来合理”的错。
  • 适合：快速探索、工具开发、复杂工程的非核心摩擦层。
From coding to research

什么是 Vibe Research

Vibe Research 不是“让 AI 做科研”。它是把 Vibe Coding 的速度引入科研流程， 但把问题选择、物理判断、验证标准、claim 边界和最终责任牢牢留在人这里。 AI 负责把人的判断快速变成代码、图、诊断、文献表和论文草稿；人负责判断这些东西是否真的构成物理。

Vibe Research 中人类判断、AI 实现、验证和论文输出的循环插图
01

人定义问题

什么问题值得做、哪个近似可接受、哪个 observable 能证明观点，这些不能外包。

02

AI 扩展手脚

代码实现、脚本、图表、文献整理、初稿和审稿回复，是 AI 最适合加速的摩擦层。

03

验证成为主线

速度越快，越要把 benchmark、守恒律、单位、边界条件和 worst case 放在主流程里。

04

结论必须收口

AI 可以写得漂亮，但 claim 的强度必须由证据决定。过度外推会毁掉可信度。

Tool choice

Claude Code 和 Codex 怎么选

截至 2026 年 5 月，我自己的用法是：这两个工具不是谁替代谁，而是适合不同形态的工作。Claude Code 更像一个贴着 Claude 生态的终端研究助手； Codex 更像 OpenAI 生态里的工程 agent 平台，尤其适合并行 coding、页面构建和需要图像生成的工作流。

Claude Code 和 Codex 两类 AI coding agent 的工作流对照插图
Claude Code

更像“文档 + 代码”的研究助手

适合把长文档、PDF、代码库和科研上下文放在同一个会话里推进。对研究者来说，它的强项是读材料、 追上下文、按你的物理判断写代码和改论文相关文件。

  • 优势：Claude 生态对 PDF 支持好，适合直接分析论文、报告、图表和长文档。
  • 优势：长上下文阅读和解释能力强，适合从文献、代码、草稿之间来回穿梭。
  • 短板：默认不是图像生成工具；要做 T2I 插图通常需要外接 API、脚本或别的工具。
  • 短板：偏单会话研究助理；大规模并行 agent / 云端 worktree 不是它最自然的形态。
Codex

更像“工程 + 多模态资产”的 agent 平台

适合构建页面、改代码、跑测试、并行拆任务，以及把 OpenAI 的工具能力接入工程流程。这个页面里的大量插图， 就是通过 Codex 环境调用 T2I 生成后落到项目资产里的。

  • 优势：适合工程化任务：改文件、跑命令、生成补丁、做页面和 app。
  • 优势：在支持工具的环境里可以调用 T2I / imagegen，直接为网站生成插图资产。
  • 优势：Codex 平台强调多 agent、云端环境、并行任务和团队工程流程。
  • 短板：PDF 不是它最直接的输入形态；通常要先转成 Markdown、文本、截图或图片序列再处理。
任务 更顺手的选择 原因
直接读论文 PDF、报告、带图表的长文档 Claude Code Claude 对 PDF 文本、图片、图表和表格理解支持更直接。
把 PDF 文献整理成项目知识库 Claude Code 起步，Codex 工程化 Claude 读 PDF；Codex 适合把结果转成脚本、数据库、网页或 RAG 管线。
做网页、交互式教程、UI、图像资产 Codex 能同时改 HTML/CSS/JS、跑浏览器检查，并在当前环境里生成 T2I 插图。
大型代码库理解、局部 bug 修复、单会话研究推进 两者都可用 Claude Code 更偏研究上下文；Codex 更偏工程补丁、测试和多任务拆分。
多个独立任务并行推进 Codex Codex 平台更强调多 agent、云端工作区和并行工程任务。
我的建议： 文献 / PDF / 研究草稿先用 Claude Code 把上下文吃透；页面、图像、工程化脚本、多 agent 并行任务交给 Codex。 Vibe Research 的关键不是迷信某个工具，而是把每个工具放到它最擅长的位置。
Execution partner

把模糊研究想法变成可执行任务

在 Vibe Research 里，Claude Code 不是聊天窗口，而是研究执行伙伴。 真正的门槛不是会不会从零写代码，而是能不能把物理问题、边界条件、数据输入、验证标准和停止规则写清楚。 只有任务可执行，结果才可验收。

把模糊物理想法转成可执行研究 brief 的工作流插图
01

先让终端成为实验台

会 cd 到项目目录、启动 claude、让它读文件、跑脚本、看日志和错误。科研 agent 的价值，首先来自它能直接接触真实项目状态。

02

补一层工程常识

Git、环境、依赖、测试、日志、脚本入口和数据路径要能大概看懂。你不必手写每行代码，但必须能判断 agent 正在动哪里、为什么动。

03

研究需求要像实验方案

写清 central claim、模型、参数范围、not in scope、benchmark、worst case 和误差预算。不要把 TBD 留给 agent，它会用猜测补空白。

04

完成 = 验证链通过

看三件事：命令是否通过、结果图和数值是否亲眼检查、验收清单是否逐条满足。出错时先命名 root cause，再允许改代码。

Research tool for one

从一个脚本到一个研究工具

不要一上来要求它重写整个求解器。先让它改一个你手边已有的文件，再把一个重复分析动作固化下来。 最后形成只服务这个物理问题的诊断工具、批处理管线或 reduced-basis 原型。

Day 1整理一个现成结果

清洗 CSV、改配置、补 README、重画一张图。

Week 1做一个诊断页面

把 residual、runtime、误差分布放到同一页。

Month 1固化一个分析管线

从输入参数到图表、日志和 summary 自动跑通。

Month 3做一个研究工具

为一个真实物理问题沉淀 solver、emulator 或 audit 工具。

从单个研究脚本发展成诊断面板、自动管线和研究工具的路径图
Claude Code protocol

把官方实践翻译成科研协议

官方文档的核心可以压成几条研究规则：让 Claude 有办法验证自己的工作，先探索再计划，给具体上下文，主动管理 context。 在 Vibe Research 里，这些规则对应到 benchmark、诊断图、项目说明书、会话切分和子任务隔离。 Claude Code Best Practices

Verify

先给验证链

不要只说“实现这个方法”。同时给 benchmark、expected output、误差预算和测试命令，例如 Coulomb phase、unitarity 或 emulator worst-case 回跑。

Explore → Plan → Code

先读，再计划，再动手

复杂任务先进 Plan Mode：先读 Hamiltonian、配置、数据路径和旧 benchmark，再列修改文件和验证路径。跨模块改动必须先计划。

Context

上下文要具体

用 @ 指文件，贴完整错误、config、图、日志和一小段数据。不要让 Claude 猜“哪个脚本”“哪张图”“哪条曲线”。

CLAUDE.md / Skills / Hooks

规则分层放

单位、相位、边界条件进 CLAUDE.md；领域流程做成 skill；“无 benchmark 不许生产运行”这类硬规则交给 hook。

Session

主动清理 context

无关任务之间用 /clear。连续两次纠偏还错，就重开会话，把学到的限制写进新 brief。长任务结束前写 handoff。

Scale

大任务要隔离

调查类任务用 subagent；批量扫参数、分波或核素时用 claude -p、多会话或 fan-out，但必须限制工具权限和写入范围。

看到这些就停： 一个会话塞进多个无关任务 同一问题反复纠偏超过两次 CLAUDE.md 写成长教程 结果看似合理但没有验证 无范围地“帮我调查一下”
Claude Code 官方实践映射到科研验证协议的六格图
Reduced-basis emulator 参数空间边界压力测试示例图
Concrete brief

例子：检查 emulator 在参数空间边界是否失效

模糊说法是“帮我看看 emulator 稳不稳”。可执行说法必须把问题压成 claim、输入、benchmark、误差预算和停机条件。

ClaimRB emulator 在 KD03 ±30% 边界仍能保持 σ_total 误差 < 0.1%。
Input5000 个 LHS 点 + 单独采样参数空间 2D/3D 边界面。
Benchmark随机抽 top-10 worst cases 回跑 full CDCC，对照总截面和角分布。
Stop rule若误差集中在某个边界方向，停止扩展，先诊断 basis 覆盖。

CLAUDE.md 是研究说明书

它应该短、直接、可判断：Hamiltonian、单位、相位约定、输入输出、禁止修改的边界、验证命令， 以及长会话压缩时必须保留的物理决策原因。

复杂任务先审物理路径

对大改动先看计划：改哪些文件、为什么改、影响范围是什么、会用哪个 benchmark 验证。 方向不对时，越早停越便宜。

Skill 是研究 SOP

把重复出现的好习惯封成技能：先规划、先验证、先定位根因、引用必须核查、claim 必须有证据。 research-planning、debug-physics-first、prc-writing 都是在固定这些路径。

自洽地放进本页： Vibe Research 不是降低研究门槛，而是把研究标准显式化。任务定义、物理约定、benchmark、守恒律、误差预算和 Expert Filter 写得越清楚，AI 执行越快，人也越能判断结果是否可信。
Operating system

一个项目怎么被推进

Vibe Research 不是把问题扔给 AI，然后等论文掉出来。它更像一个研究操作系统： 每一步都明确谁负责、停在哪个 checkpoint、什么结果必须由人来判定。

AI 辅助科研项目从想法到论文的工作流插图
Human 判断 / 取舍 / 负责
Claude 实现 / 诊断 / 整理
Checkpoint 每 30-90 分钟一次
Validation lab

不要相信输出，相信验证链

AI 写出来的代码越快，验证链越要硬。每个研究项目都应该有一张小的 validation matrix： 它不追求覆盖所有情况，而是覆盖最容易让物理出错的地方。

计算物理验证矩阵和 regression tests 插图
Claim to reproducibility

每个结论都要能追到一条复现链

AI 加速以后，真正该保存的不是“它写过什么”，而是每个物理结论背后的证据链。 论文里越强的句子，越应该能一路追到脚本、配置、commit 和失败条件。

Claim这句话到底断言了什么
Evidence哪张图 / 哪个表支撑它
Script哪个脚本生成这个结果
Config物理参数、单位、边界条件在哪里
Commit代码 hash 和环境是否锁定
Benchmark解析极限 / 旧代码 / 文献值是否通过
Failure什么结果会迫使你降级 claim
Live demo

三段真实案例的录播

下面是三段从 ahu-talk 的两个 PRC 项目里抽出来的会话脚本，我把它做成可逐步播放的伪终端。 关键节点会跳出 Expert Filter 提醒，需要你点确认才继续 — 这正是真实研究中你应该做的。

AI 终端调试计算物理求解器的插图
高保真求解器压缩为 reduced-basis emulator 的插图
claude — ~/Desktop/code/dbmm
0 / 0 速度
Production runs

从本地最小例子到集群生产

真正省时间的地方不只是写代码，而是把本地验证、HPC 调度、诊断图、误差预算和论文图表变成连续管线。 这部分适合让 Claude 做大量机械工作，但每个阶段都要留下可复现证据。

本地代码到 HPC 集群再回到诊断图的生产管线插图
Failure modes

最容易把人骗过去的错

LLM 最危险的地方不是报错，而是把错误写得很顺。下面这些模式都适合做成项目里的 regression test 或 review checklist。

人类专家检查 AI 生成代码、公式、图表和引用的 checkpoint 插图
Your weapons

武器库 · ~/.claude/skills

Skill 是带触发词的"封装好的工作流"。在 Claude Code 里输入 /skill-name 或者命中触发词时自动加载。 点击卡片复制调用样例。

AI research skills 工具库插图
Paper pipeline

从结果到论文，不要把 claim 写过头

写作阶段最该让 AI 加速的是结构化整理：文献证据、图表叙事、审稿意见回应。最不该交给它的是 claim 的边界。

文献检索、引用核查和 claim-evidence 对照插图
把物理结果组织成论文叙事的插图
Session protocol

每次开 Claude 前先写 brief

好的会话不是从“帮我看看”开始，而是从边界条件开始：今天的目标、允许它改什么、 禁止它自作主张什么、什么时候必须停下来等你审。

研究会话 brief 转化为执行计划的插图
Prompt cookbook

可复制的模板

这些是我常用的 prompt 骨架。复制下来，把尖括号里的占位符换成你的内容，再粘到 Claude Code 里。

Prompt 模板转化为代码、图表和论文初稿的插图
Before you start

Expert Filter 自检

Vibe Research 的反直觉推论：LLM 不是民主化研究，是放大专家优势。 没有 Expert Filter 的人照搬这套流程，会高速产出错的物理。 下面 8 条你都能诚实勾选时，再开始。

专家检查 AI 生成的计算物理结果的插图
还差 8 条。
⚠ 免责声明：本指南的内容如果被没有 Expert Filter 的人照搬，大概率会毁掉整个科研生涯。 建议尚不具备独立科研能力的低年级研究生先把基本功练扎实再回来。
已复制