ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

AI 我知道-06:为什么 AI 越聊越乱?上下文腐烂与论文协作工作流

2026/8/31 20:43:46 拓冰建站 浏览量
AI 我知道-06:为什么 AI 越聊越乱?上下文腐烂与论文协作工作流 温馨提示若页面不能正常显示数学公式和代码请阅读原文获得更好的阅读体验。作者丁闪闪 (连享会)邮箱lianxhcn163.com系列说明本文是「AI我知道」系列推文的第一篇面向经管、金融、社会学领域的研究者和学生。我们的目标不是把你训练成 AI 工程师而是帮你建立足够扎实的概念框架让你能更聪明地使用这些工具并在研究和工作中做出有依据的判断。Title: AI 我知道-06为什么 AI 越聊越乱上下文腐烂与论文协作工作流Keywords: 上下文腐烂, Context Rot, Context Engineering, AI Agent, Skills, 长上下文, 学术论文, 实证分析, Stata, Python, RAG, 代码生成1. AI 为什么越聊越乱很多人使用 AI 写论文、改论文、生成代码时都会遇到类似情况。刚开始AI 表现不错。你把研究问题、模型设定、变量定义、识别思路和写作风格讲清楚它能帮你润色 Introduction整理文献脉络生成 Stata 代码甚至还能帮你解释回归结果。但对话一长问题就出现了。它开始忘记你已经确定的变量定义把已经放弃的模型设定重新拿回来一会儿按主回归写解释一会儿又混入稳健性检验的结果你让它只修改语言它顺手改了识别逻辑你让它不要编造文献它却补了几篇看似真实但并不存在的参考文献你让它基于baseline.do修改它却开始重写整个项目结构。更麻烦的是AI 并不总是明显犯错。很多时候它的输出很流畅、很完整甚至看起来比原文更像论文。但细看之后会发现研究问题变虚了贡献表述变泛了变量解释变混了代码路径也可能对不上。这类现象可以称为上下文腐烂context rot。它提醒我们一个重要事实长上下文不等于可靠记忆。对话越长、材料越多AI 未必越理解你的研究反而可能更容易混淆。2. 什么是上下文腐烂上下文腐烂指的是在长对话、长文档、长代码或长任务中随着输入信息不断增加AI 对关键信息的有效利用能力下降最终导致任务漂移、约束遗忘、版本混淆和输出质量下降。它不是简单的“AI 记性不好”也不只是“上下文窗口不够大”。更准确地说这是一个有效信号被噪声和冲突稀释的问题。可以用一个简单公式理解Effective ContextRelevant SignalsRelevant SignalsNoiseConflictsEffective ContextRelevant SignalsNoiseConflictsRelevant Signals​对于论文协作而言Relevant Signals包括研究问题、识别策略、样本口径、变量定义、主回归结果、已经确认的贡献表述等。Noise包括旧版本草稿、已经否定的模型、临时讨论、无关文献和无效代码。Conflicts则包括前后不一致的要求例如一开始说“突出机制”后面又说“不要展开机制”一开始要求“尽量完整”后面又要求“压缩到一页”。真正有用的上下文不是最长的上下文而是最干净、最相关、最少冲突的上下文。这一点也有研究支持。Liu et al.2024发现长上下文模型并不总能稳定使用输入中的全部信息当关键信息位于上下文中间时模型表现往往会下降这就是常说的 “lost in the middle” 现象。Chroma 在 2025 年发布的技术报告也指出随着输入 token 增加模型在若干长上下文任务中的表现可能出现退化并且退化程度与任务类型和语义干扰有关。图 1 把问题画得更直观左侧保留研究问题、变量定义、模型设定和当前任务右侧混入旧草稿、废弃模型、冲突要求、无关文献和零散笔记。信息变多不必然带来更好的协作关键在于能否让当前任务只接触必要、且彼此一致的材料。3. 论文场景中的上下文腐烂在学术论文和实证分析中上下文腐烂尤其明显因为论文项目本身就包含大量相互依赖的信息。3.1 研究问题被改虚一篇论文最重要的是研究问题。可是长时间协作后AI 很容易把原本具体的问题改成泛泛的表达。例如原问题是地方政府债务压力是否会影响企业绿色创新改着改着可能变成宏观政策环境如何影响企业创新行为后者看起来更大但也更空。对论文来说问题不是越大越好而是要有清晰边界、明确机制和可识别的经验对象。3.2 模型设定被混淆在实证论文中我们可能先后讨论过多个模型YitαβXitγZitμiλtεitYit​αβXit​γZit​μi​λt​εit​YitαβDitμiλtεitYit​αβDit​μi​λt​εit​Yitα∑k≠−1βkDi×1(t−Tik)μiλtεitYit​αk−1∑​βk​Di​×1(t−Ti​k)μi​λt​εit​如果没有明确说明哪个是主模型、哪个是机制检验、哪个是动态效应、哪个已经放弃AI 后面就可能把它们混在一起。结果是文字解释对应不上表格机制分析写成了主回归稳健性检验又被误写成识别策略。3.3 变量定义被污染实证项目中变量定义通常会反复调整。比如treat原来表示是否属于试点地区后来改成是否在政策后受到影响再后来又加入了行业暴露度形成连续处理变量最终主回归使用的是treat × post。如果这些变化没有记录清楚AI 很容易继续使用旧定义甚至把几个定义混在一起。这会直接影响模型解释和代码生成。3.4 代码越改越危险代码任务中的上下文腐烂更麻烦。AI 可能会忘记项目路径改错数据文件覆盖中间数据重新生成已经清洗好的变量删除必要的样本限制在不同代码块中使用不一致的变量名生成看似可运行但逻辑错误的回归代码。对于实证研究来说代码错一点后面的表格、结论和论文表述都会跟着错。4. 入门做法把任务说具体应对上下文腐烂的第一步是把任务说具体。不要只说请帮我润色这段 Introduction。这太宽泛。AI 不知道你要的是语言润色、逻辑重组、贡献强化还是文献嵌入。更好的写法是请修改下面这段论文 Introduction。 研究对象 - 国内 A 股上市公司 - 研究问题是地方政府债务压力对企业绿色创新的影响 - 主体方法是双向固定效应模型 - 后续会补充工具变量和机制检验但本段不要展开技术细节。 修改目标 1. 让研究问题更聚焦不要改成泛泛的宏观政策与企业创新关系。 2. 强化问题意识为什么地方政府债务压力可能影响企业创新投入 3. 保留原有识别逻辑不要新增未经确认的政策背景。 4. 不要编造文献和数据事实。 5. 语言要符合经济学和管理学论文的写法但不要过度模板化。 语言要求 - 除非必要不要过度使用双引号 - 不要机械使用“总体而言”“值得注意的是”“由此可见”等套话 - 不要频繁使用“本文可能的边际贡献在于”这类生硬表达 - 不要把每个句子都写成“不是 A而是 B”的结构 - 不要为了显得高级而堆砌“赋能”“重塑”“范式转型”等词。 输出要求 - 只输出修改后的段落 - 不要写修改说明 - 不要新增参考文献 - 不要改变核心结论。如果是代码任务也不要只说请帮我写 Stata 代码。可以改成请根据下面的研究设计生成 Stata 代码。 任务目标 - 使用面板数据估计双向固定效应模型 - 被解释变量为 green_patent - 核心解释变量为 debt_pressure - 控制变量包括 size、lev、roa、cashflow - 固定效应包括企业固定效应和年份固定效应 - 标准误聚类到企业层面。 代码要求 1. 使用 reghdfe 命令 2. 不要覆盖原始数据 3. 每一步添加中文注释 4. 明确标注样本筛选、变量生成、描述统计、主回归和结果导出 5. 回归结果使用 esttab 导出 6. 代码中的路径使用相对路径 7. 不要生成不存在的变量 8. 如果某个变量需要用户确认请在代码注释中标出而不是自行假设。 输出要求 - 输出完整 .do 文件内容 - 代码格式整齐 - 长命令使用 /// 换行 - 不要解释 Stata 基础语法。这样写不是为了让 prompt 更长而是为了减少歧义。对论文和代码来说很多错误都不是模型不会做而是任务边界、变量口径和输出要求没有被固定下来。5. 进阶做法把大任务拆小论文协作不适合一次性完成。不要把一篇 3 万字论文、几十个回归表和若干.do文件全部扔给 AI然后要求它“帮我全面优化”。更稳妥的方式是把任务拆成连续的小任务。以论文修改为例可以拆成研究问题诊断只判断研究问题是否清楚是否过宽是否有可识别的经验对象。Introduction 重组只处理开头叙事、研究动机和贡献表达不碰模型和结果。文献定位检查只判断现有文献是否支撑研究问题是否存在缺口表述过大的问题。模型设定审查只检查模型公式、变量定义、固定效应和标准误聚类是否一致。代码生成与检查只根据已确认的模型写代码不重新解释研究问题。表格解释只根据给定回归表写结果解释不新增未经表格支持的结论。稳健性检验规划只讨论可行的稳健性检验不直接改主文。全文一致性校对最后检查术语、变量、表格编号、结论表述是否一致。这种拆分方式的好处是每一步都有明确输入和输出AI 不需要同时记住全部细节。即使某一步错了也容易回退不至于污染整篇论文。温馨提示若页面不能正常显示数学公式和代码请阅读原文获得更好的阅读体验。