企业官网建设流程全解析

组会上最尴尬的一幕，往往不是你没做出实验，而是你兴冲冲讲了一个“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 想不出好点子”。

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 openai>=1.30.0 pandas>=2.0.0 pydantic>=2.5.0 tenacity>=8.2.0 PyYAML>=6.0 python-dotenv>=1.0.0

# 文件路径：.env.example # 复制为 .env 后填写，.env 必须加入 .gitignore LLM_API_KEY=your_key_here LLM_BASE_URL=https://your-endpoint/v1 LLM_MODEL=your-model-name

python -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_key=os.environ["LLM_API_KEY"], base_url=os.environ.get("LLM_BASE_URL"), ) resp = client.chat.completions.create( model=os.environ["LLM_MODEL"], messages=[{"role": "user", "content": "用一句话说明什么是研究假设。"}], temperature=0.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_key=os.environ["LLM_API_KEY"], base_url=os.environ.get("LLM_BASE_URL"), ) MODEL = os.environ["LLM_MODEL"] @retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=2, max=20)) def chat(prompt: str, system: str = "你是一位严谨的科研助手。", temperature: float = 0.7) -> str: resp = _client.chat.completions.create( model=MODEL, temperature=temperature, 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, system=system, temperature=temperature) # 去掉可能出现的代码围栏 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(encoding="utf-8").strip() if not abstract: continue try: info = chat_json(PROMPT.format(abstract=abstract[:3000]), temperature=0.2) except Exception as exc: print(f"[skip] {fp.name}: {exc}") continue info["source"] = fp.stem rows.append(info) OUT.parent.mkdir(parents=True, exist_ok=True) with OUT.open("w", encoding="utf-8") as f: for row in rows: f.write(json.dumps(row, ensure_ascii=False) + "\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", encoding="utf-8")) CONS = yaml.safe_load(open("config/constraints.yaml", encoding="utf-8")) corpus_lines = [ json.loads(line) for line in open("data/processed/corpus.jsonl", encoding="utf-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( field=CONS["field"], corpus=corpus_text, constraints=constraints, perspective=p["instruction"], ) text = chat(prompt, temperature=0.9) results.append({"perspective": p["name"], "raw": text}) print(f"[done] {p['name']}") out = pathlib.Path("out/ideas_raw.json") out.parent.mkdir(parents=True, exist_ok=True) out.write_text(json.dumps(results, ensure_ascii=False, indent=2), encoding="utf-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-5，1 表示不可接受。", "资源管理员": "你负责判断方案在给定资源下能否完成。资源不足直接给低分，评分 1-5。", "领域新人": "你是刚进入该领域的学生，判断问题陈述是否看得懂、增量是否讲得清楚。评分 1-5。", } PROMPT = """{role_desc} 【待评审的研究问题】 {idea} 【约束条件】 {constraints} 请严格输出 JSON： {{"score": 整数1到5, "fatal_flaw": "最致命的一个问题", "suggestion": "一句可操作的改进建议"}}""" def main() -> None: cons = open("config/constraints.yaml", encoding="utf-8").read() raw = json.loads(open("out/ideas_raw.json", encoding="utf-8").read()) rows = [] # 这里为简化演示，把每个视角的输出整体当作一个候选单元 for item in raw: idea = item["raw"] scores = {} for name, desc in ROLES.items(): try: res = chat_json( PROMPT.format(role_desc=desc, idea=idea[:4000], constraints=cons), temperature=0.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", ascending=False) pathlib.Path("out").mkdir(exist_ok=True) df.to_csv("out/critique.csv", index=False, encoding="utf-8-sig") print(df[["perspective", "avg_score"]].to_string(index=False)) 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", encoding="utf-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.jsonl，N 应该等于你data/raw下非空 txt 文件数；如果 N 明显偏小，说明部分文献在抽取阶段抛异常被跳过了，去看打印的[skip]行。第三步会为每个视角打印一行[done]，视角数要和 YAML 里配的数量一致。第四步输出一张按均分排序的表格。第五步生成 Markdown 报告。

怎么判断这套结果“有效”？我建议用三个标准，而不是看输出漂不漂亮。

第一，候选之间是否有实质差异。如果五个视角产出的候选，你把标题遮住就分不清哪个是哪个视角来的，说明约束卡太松或者视角设计重复了，回去改perspectives。

第二，是否有候选明确指出“与已有工作的差异”。这一条是最硬的筛子。凡是差异那一段含糊其辞的，基本可以判定为无增量。你可以让模型自评这一项的置信度，低于阈值的直接淘汰。

第三，是否能给出两周内的最小验证。这一条我放在最后但最重要。一个 idea 如果连一个两周能跑出信号的最小实验都描述不出来，它在你的时间窗口里就是不成立的，无论它听起来多有意思。

失败时的排查顺序也很明确：先看out/critique.csv里是不是大量评审失败，那多半是 JSON 解析或调用超时；再看avg_score是否全部集中在 3.0 附近，那是评分标准被模型拉平了，需要在提示词里给更具体的评分锚点；最后看corpus.jsonl里assumption字段有多少是“未提及”，如果超过一半，说明你的文献池质量不够，先补文献，别急着生成。

7. 常见问题与排查思路

表格里最后一行值得单独说。科研场景对可复现性的要求比一般工程更高，而模型调用天生带随机性。最实用的做法是：每次跑完把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，而是那些被淘汰的理由。它们会告诉你自己的判断盲区在哪里，而这恰恰是任何模型都没法替你补的部分。