组会上最尴尬的一幕往往不是你没做出实验而是你兴冲冲讲了一个“AI 帮我想出来的 idea”导师问了三句话就露馅了这个问题的增量在哪用什么数据验证如果做不出来退路是什么这两年“用 AI 找研究方向”被讲得太多但真实体验是模型给你的东西读起来都很像论文摘要正确、流畅、四平八稳就是落不了地。标题里那个“博一”其实点出了关键——这个阶段最缺的不是勤奋也不是文献阅读量而是把“模糊的兴趣”收敛成“一个可执行、可验证、有增量的研究问题”的能力。AI 能不能帮上这个忙取决于你把它当许愿池还是当成一条流水线上的一个工位。这篇文章的核心判断是AI 在科研创意环节真正的价值不是替你“想出” idea而是把“发散、质疑、过滤、收敛”这套原本只存在于资深研究者脑子里的隐性流程显性化、可复现化。你让它一次性给十个选题得到的是十个正确的废话你把它拆成带约束、带评审、带淘汰机制的多轮流程它才能稳定产出有价值的东西。本文面向三类读者正在找开题方向的硕士博士生、需要给团队规划技术选题的研发同学、以及想把“创意生成”这件事工程化的工程师。读完之后你能得到一套可以直接跑起来的完整管线从文献池结构化、约束卡定义、多视角发散到交叉评审打分、生成汇总报告全部有代码、有配置、有验证方式和排错清单。所有代码都是通用的 Python OpenAI 兼容接口写法模型服务请使用你所在环境允许并合规授权的渠道。1. 先说结论用 AI 产 idea 失败问题多半不在模型我见过太多“AI 选题”的失败案例把它们归类基本逃不出下面三种。第一种是正确但空泛比如“基于大模型的 XX 领域智能分析框架研究”每个字都对但没有任何一个具体的科学问题被提出你无法判断做完了算不算成功。第二种是新颖但不落地模型很擅长把两个热门词拼在一起可真要做你既没有那种数据也没有那种算力更没有那种标注人力。第三种是组合但无意义A 方法加 B 场景拼得很顺但学术共同体根本不关心这个交叉点上有没有真问题。这三种失败的共同点是什么不是模型变笨了而是输入信息太少、约束条件太松、缺少淘汰环节。你给模型的上下文只有一句“帮我找一个 XX 方向的研究点”它能利用的信息就只有这几个词的统计关联输出自然接近“领域热词的平均值”。而一个真正的研究 idea需要同时满足四个约束问题真实存在、方法与问题匹配、资源可支撑、增量可辩护。这四个约束里前三个模型完全不知道因为没人告诉它。所以正确的姿势不是换一个更强的模型而是把约束喂进去。我在下面会反复强调一个原则每一条你认为“显而易见所以不用说”的前提模型都不知道都必须显式写下来。这句话听起来朴素但它决定了你是得到一份可以拿去和导师讨论的选题清单还是得到一份只能截图发朋友圈的漂亮废话。还有一个容易被忽略的点单轮对话天然缺少“自我否定”。人做研究时会在构思阶段就自动砍掉九成不靠谱的方向这个淘汰过程是隐性的、快速的。模型不会主动砍它只会顺着你的话往下说。所以你必须把淘汰机制外置成流程里的一个明确环节——这也是本文后面“交叉评审”那一节存在的原因。2. 理解 AI 在科研创意生成中的能力边界在动手写代码之前先把边界搞清楚否则后面的期望管理会全线崩盘。这一节不讲玄学只讲它在具体任务上表现出来的稳定特性你可以拿这几条去校验自己接下来设计的提示词是否合理。2.1 它擅长的四件事第一是跨领域组合与类比。这是模型最稳的能力。它能从“图神经网络里的过平滑问题”联想到“信号处理里的低通滤波”这种远距离关联人类专家也能做但需要阅读面和记忆广度模型在这方面成本极低。你要做的不是让它“发明”而是让它“把远处的解法搬到近处的问题上”然后由你判断这个搬运是否成立。第二是结构化归纳。给它二十篇摘要让它提炼出“这些工作共同回避了什么假设”它做得又快又整齐。这类任务的价值在于帮你压缩阅读成本而不是替代阅读。注意摘要级归纳和全文级精读是两件事后者目前仍需你自己完成关键部分。第三是反向质疑。这一条被严重低估。你把自己写好的假设丢给它要求它“以最苛刻的审稿人身份指出三个致命缺陷”它给出的挑刺往往比你同门更全面因为它不受人情和面子影响。当然它挑的刺有真有假但作为一份“待排查清单”质量很高。第四是表达与形式化。把口语化的想法整理成规范的问题陈述、把模糊的描述改写成可操作的实验变量定义这类工作它做得很好而且省时间。2.2 它不擅长的三件事第一是判断价值增量。“这个问题以前没人做过”和“这个问题值得做”是两码事。模型可以告诉你前者而且未必准确因为它的知识有截止时间也可能产生幻觉但它无法判断后者因为价值判断依赖于学术共同体的动态共识、领域内的资源分配状况、以及你所在课题组的积累。第二是判断资源可行性。它不知道你的实验室有几张卡、有没有那台设备、能不能拿到那批数据、你还有几个月毕业。这些约束必须由你在提示词里显式声明否则它给出的方案会默认你是无限资源。第三是判断“审稿人会不会买账”。一个 idea 能不能发出去很大程度上取决于它是否踩在某个社区当下关心的问题上。这个信号藏在近两年的会议论文、workshop 议题、甚至审稿意见里模型只能部分捕捉而且容易滞后。2.3 一张对照表帮你决定什么该交给 AI任务环节交给 AI 的合适程度说明人的不可替代动作文献摘要聚类归纳高压缩阅读量的性价比最高抽查原文核对结论跨领域方法迁移中高产出候选不产出结论判断迁移的前提是否成立问题陈述形式化高把口语改写成规范表述确认变量定义无误实验方案草拟中只能给通用骨架补资源、设备、时间约束反向质疑与挑刺高生成待排查清单逐条判断真伪价值增量判断低容易给出平庸答案完全由人负责最终选题决策极低不建议交给模型完全由人负责这张表的用法是把高和较高的环节串成流水线把低和极低的环节留给自己。很多人失败的根源恰恰是让模型做了表最后两行的事然后抱怨“AI 想不出好点子”。3. 环境准备与工具选型这一节给的是能直接照着搭的最小环境。版本请以你实际项目为准本文重点演示通用思路不绑定任何特定的模型版本或厂商模型名称一律通过环境变量传入避免把不稳定的细节写死在代码里。运行环境建议Python 3.10 及以上主要用到openai兼容多种模型服务的标准接口、pandas结果汇总、pydantic结构化输出校验、tenacity失败重试、pyyaml提示词模板配置。依赖管理用venv或conda都可以团队协作建议锁版本。安全提醒先放在前面API 密钥绝对不要写进代码、不要提交到 Git 仓库、不要出现在 notebooks 的输出里。用环境变量注入并且在.gitignore里排除配置文件。如果你的研究涉及未公开数据或受限文献不要把原文直接送进外部模型服务先做脱敏和摘要化处理这一点属于合规底线不能含糊。目录结构建议这样组织后面所有代码都基于这个结构idea-pipeline/ ├── .env.example ├── requirements.txt ├── config/ │ ├── constraints.yaml # 约束卡资源、时间、领域 │ └── prompts.yaml # 提示词模板集中管理 ├── data/ │ ├── raw/ # 原始文献摘要不要提交敏感内容 │ └── processed/ ├── src/ │ ├── llm.py # 模型调用封装 │ ├── build_corpus.py # 文献结构化 │ ├── generate_ideas.py # 多视角发散 │ ├── critique.py # 交叉评审打分 │ └── report.py # 汇总报告 └── out/# 文件路径requirements.txt openai1.30.0 pandas2.0.0 pydantic2.5.0 tenacity8.2.0 PyYAML6.0 python-dotenv1.0.0# 文件路径.env.example # 复制为 .env 后填写.env 必须加入 .gitignore LLM_API_KEYyour_key_here LLM_BASE_URLhttps://your-endpoint/v1 LLM_MODELyour-model-namepython -m venv .venv source .venv/bin/activate # Windows 用 .venv\Scripts\activate pip install -r requirements.txt cp .env.example .env # 然后编辑 .env 填入实际配置安装完成后先做一次连通性自检不要等到跑了半小时管线才发现密钥无效。这一步看起来多余但能省掉大量排查时间。# 文件路径src/smoke_test.py import os from dotenv import load_dotenv from openai import OpenAI load_dotenv() client OpenAI( api_keyos.environ[LLM_API_KEY], base_urlos.environ.get(LLM_BASE_URL), ) resp client.chat.completions.create( modelos.environ[LLM_MODEL], messages[{role: user, content: 用一句话说明什么是研究假设。}], temperature0.3, ) print(resp.choices[0].message.content)如果这一步报错先分清是网络问题、鉴权问题还是模型名写错三类错误的响应信息差别很明显不要一上来就怀疑代码。连通之后再进入下一步。4. 核心工作流拆解从文献到可验证假设的五个环节整套流程我拆成五个环节每个环节都有明确的输入、输出和失败模式。你可以只做其中几步但不要跳过第四步那是整条流水线的关键。环节一文献池结构化。输入是你读过的、或检索到的文献摘要输出是结构化的记录这篇工作研究什么问题、用什么方法、在什么数据上验证、明确承认了什么局限。这一步的目的是把非结构化文本变成可以被后续提示词反复引用的“事实卡”。值得注意的是让模型提炼“局限”时务必要求它只依据原文找不到就写“未提及”否则它会顺着套路编造。环节二约束卡定义。这是最容易被跳过、也最影响结果的一步。约束卡用 YAML 写包含四类信息可用资源算力、数据、设备、时间窗口还剩几个季度、团队积累组里已有哪方面的基础、排除项明确不做什么。约束卡会被注入到后续每一个提示词里它相当于给模型装上了“现实感”。环节三多视角发散。不要用一次提问产生全部候选。用四到六个不同视角分别提问比如“从方法缺陷切入”“从数据集偏差切入”“从相邻领域迁移切入”“从工程瓶颈反向切入”。每个视角独立生成三到五个候选这样得到的候选集合多样性远高于一次问十个。环节四交叉评审。把候选 idea 打乱顺序让模型分别扮演三个角色打分严苛审稿人挑致命缺陷、资源管理员判断是否做得起、领域新入场者判断是否看得懂、增量是否清楚。三个分数都低的直接淘汰。这一步是整条流水线里信息量最大的因为它把“筛选”这件事从你脑子里搬到了可记录的表格里。环节五收敛到最小验证实验。对通过评审的少数候选要求模型给出“两周内能完成的最小验证方案”需要什么数据、跑什么基线、什么结果算支持、什么结果算否定。如果它给不出一个能在两周内跑出信号的最小实验这个 idea 大概率太重应该降级或放弃。这五步的逻辑本质上是把人类研究者的思维流程做了外化先积累素材再明确边界然后发散接着互相挑刺最后收敛。每一步都有产出物都可以回溯这比“问一句得到一堆”强的地方不只是质量更是可复用——换个课题改改约束卡就能再跑一遍。5. 完整示例代码实现下面给出四个核心脚本。为了可读性模型调用统一封装所有提示词放在 YAML 里集中管理方便你迭代而不改代码。5.1 模型调用封装与重试# 文件路径src/llm.py import os import json from typing import Any from dotenv import load_dotenv from openai import OpenAI from tenacity import retry, stop_after_attempt, wait_exponential load_dotenv() _client OpenAI( api_keyos.environ[LLM_API_KEY], base_urlos.environ.get(LLM_BASE_URL), ) MODEL os.environ[LLM_MODEL] retry(stopstop_after_attempt(3), waitwait_exponential(multiplier2, max20)) def chat(prompt: str, system: str 你是一位严谨的科研助手。, temperature: float 0.7) - str: resp _client.chat.completions.create( modelMODEL, temperaturetemperature, messages[ {role: system, content: system}, {role: user, content: prompt}, ], ) return resp.choices[0].message.content.strip() def chat_json(prompt: str, system: str 你是一位严谨的科研助手只输出 JSON。, temperature: float 0.3) - Any: 要求模型输出 JSON并做一次容错解析。 raw chat(prompt, systemsystem, temperaturetemperature) # 去掉可能出现的代码围栏 if raw.startswith(): raw raw.split()[1] raw raw.split(\n, 1)[1] if \n in raw else raw raw raw.strip().strip().strip() try: return json.loads(raw) except json.JSONDecodeError: # 退化处理截取第一个 { 到最后一个 } start, end raw.find({), raw.rfind(}) if start ! -1 and end ! -1 and end start: return json.loads(raw[start:end 1]) raise这里有两个细节值得说。第一temperature是分任务设定的提炼事实时用低温度0.2 到 0.3保证稳定发散创意时用高温度0.8 以上保证多样性用同一个参数跑全流程是常见错误。第二JSON 解析的容错必须有因为模型偶尔会带代码围栏或者前后加解释文字一个健壮的解析函数能避免整条管线因为一个格式问题中断。5.2 文献池结构化# 文件路径src/build_corpus.py import json import pathlib import pandas as pd from llm import chat_json RAW_DIR pathlib.Path(data/raw) OUT pathlib.Path(data/processed/corpus.jsonl) PROMPT 你是文献信息抽取器。请只依据下面这段摘要抽取结构化信息。 如果某项信息摘要中没有明确提及对应字段填 未提及禁止推测或补充。 摘要 {abstract} 请严格输出如下 JSON {{ problem: 这篇工作要解决的问题, method: 采用的方法或框架, evidence: 验证所用的数据集或实验条件, limitation: 作者明确承认或可从文中直接看出的局限, assumption: 该方法成立所依赖的关键前提假设 }} def main() - None: rows [] for fp in sorted(RAW_DIR.glob(*.txt)): abstract fp.read_text(encodingutf-8).strip() if not abstract: continue try: info chat_json(PROMPT.format(abstractabstract[:3000]), temperature0.2) except Exception as exc: print(f[skip] {fp.name}: {exc}) continue info[source] fp.stem rows.append(info) OUT.parent.mkdir(parentsTrue, exist_okTrue) with OUT.open(w, encodingutf-8) as f: for row in rows: f.write(json.dumps(row, ensure_asciiFalse) \n) print(f写入 {len(rows)} 条记录 - {OUT}) if __name__ __main__: main()关键逻辑解释assumption这个字段是我特意加的很多论文的局限不在结果上而在“方法成立所依赖的前提假设”上。当你把一个领域里若干篇工作的assumption汇总起来经常会发现大家共享一个从未被验证的假设——这类共享假设往往是研究机会最密集的地方。字段要求“未提及”而不是留空是为了让你一眼看出哪些工作其实没讨论自己的局限这本身也是信息。5.3 多视角发散提示词模板# 文件路径config/prompts.yaml constraints_placeholder: | 可用资源{compute} 数据条件{data} 时间窗口{timeline} 团队已有积累{background} 明确排除{exclude} perspectives: - name: 方法缺陷视角 instruction: 找出该方向主流方法在什么条件下会失效把失效条件本身转化为研究问题。 - name: 数据偏差视角 instruction: 关注现有评测数据或标注流程中可能存在的偏差提出由偏差驱动的研究问题。 - name: 相邻领域迁移视角 instruction: 从相邻学科中找一个成熟机制判断它能否迁移过来并说明迁移的前提。 - name: 工程瓶颈反向视角 instruction: 从实际部署中卡住的工程瓶颈出发反推它背后尚未被解决的学术问题。 - name: 共享假设挑战视角 instruction: 基于文献事实卡中反复出现的 assumption 字段质疑其中一个从未被验证的前提。 idea_prompt: | 你是一位在 {field} 方向有十年经验的研究者。现在请基于以下材料提出候选研究问题。 【文献事实卡】 {corpus} 【约束卡】 {constraints} 【本次视角】 {perspective} 输出要求 1. 提出 3 个候选研究问题每个必须包含问题陈述、与已有工作的差异、最小验证方式。 2. 必须满足约束卡中的资源与时间条件如果某候选违反约束直接不要输出。 3. 禁止使用基于深度学习的XX框架这类空泛表述必须写清楚变量和对比对象。 4. 每个候选后附一句最大风险说明它最可能在哪里失败。# 文件路径src/generate_ideas.py import json import yaml import pathlib from llm import chat CFG yaml.safe_load(open(config/prompts.yaml, encodingutf-8)) CONS yaml.safe_load(open(config/constraints.yaml, encodingutf-8)) corpus_lines [ json.loads(line) for line in open(data/processed/corpus.jsonl, encodingutf-8) ] corpus_text \n.join( f- [{c[source]}] 问题:{c[problem]} | 方法:{c[method]} | 假设:{c[assumption]} for c in corpus_lines[:40] ) constraints CFG[constraints_placeholder].format(**CONS) results [] for p in CFG[perspectives]: prompt CFG[idea_prompt].format( fieldCONS[field], corpuscorpus_text, constraintsconstraints, perspectivep[instruction], ) text chat(prompt, temperature0.9) results.append({perspective: p[name], raw: text}) print(f[done] {p[name]}) out pathlib.Path(out/ideas_raw.json) out.parent.mkdir(parentsTrue, exist_okTrue) out.write_text(json.dumps(results, ensure_asciiFalse, indent2), encodingutf-8)# 文件路径config/constraints.yaml field: 你的研究方向 compute: 单机 1 张消费级显卡可租用少量云算力 data: 可获取公开数据集无自有标注人力 timeline: 距离中期检查约 6 个月 background: 课题组在传统方法上有积累深度学习工程经验薄弱 exclude: 不做需要大规模人工标注的方向不做纯理论证明约束卡的写法有一个要点写得越“难看”越有用。很多人写约束卡时不好意思写“我们组深度学习工程经验薄弱”结果模型给出的方案全是要搭大规模训练管线的。把短板写进去模型会自动规避这不是示弱是提高产出可用率。5.4 交叉评审与打分脚本# 文件路径src/critique.py import json import pathlib import pandas as pd from llm import chat_json ROLES { 审稿人: 你是顶会最严苛的审稿人专门指出工作的致命缺陷和增量不足。评分 1-51 表示不可接受。, 资源管理员: 你负责判断方案在给定资源下能否完成。资源不足直接给低分评分 1-5。, 领域新人: 你是刚进入该领域的学生判断问题陈述是否看得懂、增量是否讲得清楚。评分 1-5。, } PROMPT {role_desc} 【待评审的研究问题】 {idea} 【约束条件】 {constraints} 请严格输出 JSON {{score: 整数1到5, fatal_flaw: 最致命的一个问题, suggestion: 一句可操作的改进建议}} def main() - None: cons open(config/constraints.yaml, encodingutf-8).read() raw json.loads(open(out/ideas_raw.json, encodingutf-8).read()) rows [] # 这里为简化演示把每个视角的输出整体当作一个候选单元 for item in raw: idea item[raw] scores {} for name, desc in ROLES.items(): try: res chat_json( PROMPT.format(role_descdesc, ideaidea[:4000], constraintscons), temperature0.2, ) scores[f{name}_score] res.get(score) scores[f{name}_flaw] res.get(fatal_flaw, ) except Exception as exc: scores[f{name}_score] None scores[f{name}_flaw] f评审失败: {exc} row {perspective: item[perspective], **scores} nums [v for k, v in scores.items() if k.endswith(_score) and isinstance(v, (int, float))] row[avg_score] round(sum(nums) / len(nums), 2) if nums else None rows.append(row) df pd.DataFrame(rows).sort_values(avg_score, ascendingFalse) pathlib.Path(out).mkdir(exist_okTrue) df.to_csv(out/critique.csv, indexFalse, encodingutf-8-sig) print(df[[perspective, avg_score]].to_string(indexFalse)) if __name__ __main__: main()这段的关键不在代码而在排序后的使用方式avg_score低的直接丢不用心疼avg_score高的也不要直接采纳而是去看fatal_flaw那一列——如果三个角色指出的致命问题高度重合说明这是该 idea 的结构性弱点几乎不可能靠调整方案绕过去如果三个角色各自指出不同的问题反而说明它还有改的余地。这个判断方式比单纯看分数有用得多。5.5 汇总成可讨论的文档# 文件路径src/report.py import pandas as pd df pd.read_csv(out/critique.csv) top df[df[avg_score] 3.5].head(5) lines [# 候选研究问题汇总\n] for i, r in enumerate(top.itertuples(), 1): lines.append(f## 候选 {i}{r.perspective}均分 {r.avg_score}\n) lines.append(f- 审稿人指出的致命问题{r._3 if hasattr(r, _3) else r[4]}\n) lines.append(f- 资源可行性问题{r[6]}\n) lines.append(f- 表达清晰度问题{r[8]}\n) open(out/report.md, w, encodingutf-8).write(\n.join(lines)) print(报告已生成out/report.md)report.py里读取列的方式依赖 CSV 的实际列序实跑时建议改成按列名取值避免列顺序变化导致报错。这个提醒不是多余——批量生成的表格一旦列数变化位置索引就会静默取错值很难发现。6. 运行结果与效果验证按顺序执行python src/smoke_test.py python src/build_corpus.py python src/generate_ideas.py python src/critique.py python src/report.py预期输出大致是这样几个层次。第一步smoke_test应该打印一句通顺的中文说明链路通了。第二步会打印写入 N 条记录 - data/processed/corpus.jsonlN 应该等于你data/raw下非空 txt 文件数如果 N 明显偏小说明部分文献在抽取阶段抛异常被跳过了去看打印的[skip]行。第三步会为每个视角打印一行[done]视角数要和 YAML 里配的数量一致。第四步输出一张按均分排序的表格。第五步生成 Markdown 报告。怎么判断这套结果“有效”我建议用三个标准而不是看输出漂不漂亮。第一候选之间是否有实质差异。如果五个视角产出的候选你把标题遮住就分不清哪个是哪个视角来的说明约束卡太松或者视角设计重复了回去改perspectives。第二是否有候选明确指出“与已有工作的差异”。这一条是最硬的筛子。凡是差异那一段含糊其辞的基本可以判定为无增量。你可以让模型自评这一项的置信度低于阈值的直接淘汰。第三是否能给出两周内的最小验证。这一条我放在最后但最重要。一个 idea 如果连一个两周能跑出信号的最小实验都描述不出来它在你的时间窗口里就是不成立的无论它听起来多有意思。失败时的排查顺序也很明确先看out/critique.csv里是不是大量评审失败那多半是 JSON 解析或调用超时再看avg_score是否全部集中在 3.0 附近那是评分标准被模型拉平了需要在提示词里给更具体的评分锚点最后看corpus.jsonl里assumption字段有多少是“未提及”如果超过一半说明你的文献池质量不够先补文献别急着生成。7. 常见问题与排查思路问题现象可能原因排查方式解决方案候选之间高度雷同温度过低或视角设计重复检查temperature与perspectives内容发散阶段温度提到 0.8 以上重写视角指令输出大量“基于XX的XX框架”提示词缺少负面约束检查提示词是否有禁止空泛表述的条款明确要求写出变量与对比对象JSON 解析频繁失败模型返回带解释文字或围栏打印原始返回内容前 200 字符用容错解析或改用结构化输出能力评审分数集中在 3 分评分锚点不具体看fatal_flaw是否空泛给每档分数写明确描述与示例候选全部违反资源约束约束卡未被注入打印实际发出的提示词核对确认constraints参加了格式化抽取字段大量“未提及”文献池质量或长度不足统计limitation非空比例补充文献或改用全文而非摘要调用超时或限流并发过高查看错误码与调用频率降并发、加重试退避、分批执行结果无法复现未固定随机性对比两次运行的输入与参数记录模型名、温度、提示词版本表格里最后一行值得单独说。科研场景对可复现性的要求比一般工程更高而模型调用天生带随机性。最实用的做法是每次跑完把prompts.yaml、constraints.yaml的内容和模型名、温度一起写进out/run_meta.json几个月后回看时你能知道当时到底喂了什么进去。这件事花五分钟能省掉未来大量的“当时那个 idea 是怎么来的”的困惑。另外提醒一句关于合规的实践如果你的文献池包含未公开的实验数据、内部报告或受限材料不要直接送进外部模型服务。稳妥做法是先把这些材料人工改写成不含敏感细节的问题描述再进入流程这一步不能省出问题的代价远大于省下的时间。8. 最佳实践与工程建议第一提示词必须版本化。把提示词放在 YAML 里而不是硬编码在 Python 字符串里原因不只是整洁而是你需要能对比“改了哪一句导致输出变了”。建议在prompts.yaml顶部加一个version字段每次实质性修改就递增报告里带上版本号。第二约束卡要定期更新。你的时间窗口、算力、数据获取情况在变三个月前的约束卡可能已经失效。建议每次开题讨论后更新一次把它当成一个活文档而不是一次性配置。这件事在博士阶段尤其重要因为“还剩多少时间”这个变量会剧烈改变什么 idea 是可行的。第三区分“探索态”和“收敛态”的参数。发散阶段追求多样性温度高、视角多、不设淘汰评审阶段追求稳定性温度低、角色固定、评分标准明确。把这两种状态混在一起调参是效率最低的做法。第四把淘汰当成正式产出。每次跑完除了记录通过的候选也记录被淘汰的候选和淘汰理由。理由积累多了你会发现自己或模型反复在同一类问题上翻车比如总是忽略标注成本、总是假设数据干净。这份“淘汰理由清单”的价值往往比通过的三个 idea 更高。第五人工复核不能省。模型提炼的文献结论必须回原文核对尤其是你要写进开题报告的那几条。幻觉在摘要级归纳任务里依然存在而且往往表现为“看起来非常合理的错误总结”比明显胡说更有欺骗性。抽检比例建议不低于三成关键结论必须逐条核。第六团队协作时的边界。如果多人共用一套管线注意两点一是各自用独立的输出目录避免互相覆盖二是共享的约束卡改动要经过讨论因为约束卡里的假设会影响所有人拿到的结果。这一点在课题组里容易出矛盾提前定好规则比较省事。第七别把流程本身当成研究成果。这套管线是工具不是你的研究内容。它可以帮你更快找到问题但它不构成任何学术贡献。这个边界要清楚否则容易在方法上越投入越深反而偏离了真正的目标。9. 一些边界提醒和下一步能做什么写到这里我想把最核心的那句话再说一遍因为它比任何代码都重要AI 在这件事上的作用是扩大你的搜索范围、加快你的排除速度而不是替你判断什么值得做。判断价值这件事需要你对自己所在社区的动态有感觉需要你知道哪些问题已经被人做烂了、哪些方向正在被资源倾斜、哪些结论其实业界普遍不信但没人公开说。这些信息不在模型的训练数据里或者在里面但已经过期。如果你今天就想动手最实际的三步是先花一小时把自己的约束卡写清楚包括那些你不好意思写的短板再从你已经读过的十几篇文献里抽出摘要跑一遍build_corpus.py看看assumption那一列能不能给你一点意外最后挑两三个视角跑发散不用跑全流程先看看产出质量是否达到你的预期。如果产出依然平庸通常不是模型不行而是文献池太薄或者约束太松。这两件事都能改而且改起来很快。真正改不了的是时间所以别在调提示词上无限投入跑到“能用”就停把时间留给读原文和做实验——毕竟最后决定你能不能毕业的是实验台上的那台机器不是 API 的调用额度。另外建议把每次跑出来的候选和评审记录留档。半年后回头看你会发现最有价值的不是当时评分最高的那个 idea而是那些被淘汰的理由。它们会告诉你自己的判断盲区在哪里而这恰恰是任何模型都没法替你补的部分。