研究计划提案：AI 依赖决策如何把短期效率转化为长期维护债？

一句话版本
当开发者把“引入什么依赖、选哪个版本、何时升级、是否替换”这类高杠杆工程判断部分外包给 AI coding assistants 时，AI 往往优化的是当前任务完成率、局部可运行性与交互摩擦最小化，却未必内化未来升级成本、维护返工、补丁采用速度、review 负担与供应链治理成本。本研究要回答的是：AI-assisted dependency decisions 是否系统性地把今天的开发便利，转嫁成明天的维护债与供应链风险？

0. 执行摘要：这题真正有价值的地方，不是“AI 会不会推荐旧版本”

如果把问题讲成“LLM 会不会推荐过时包”，题目会显得偏窄，也容易被 package hallucination、旧 API 复现、AI 不安全代码生成等既有工作吞掉。更强、也更有软件工程价值的命题是：

AI 正在接管一类高杠杆但低可见度的工程判断；这些判断的即时收益由当前开发者获得，而长期代价往往由未来维护者、reviewer、安全响应者和开源生态承担。

依赖决策看起来只是一行 requirements.txt、pyproject.toml、package.json、Cargo.toml 或 pom.xml，但它会改变项目未来的：

升级难度与迁移路径
补丁采用速度与修复摩擦
review 讨论量与 CI 稳定性
依赖冲突、锁文件震荡与支持矩阵复杂度
对某个库、维护团队、技术路线和默认实践的长期绑定

因此，本研究的核心不是追问“AI 对不对”，而是提出并验证一个更强的 生命周期总成本视角（lifecycle-total-cost view）：

短期收益：更快完成任务、demo 更快跑通、PR 更快打开、资料检索更少
长期成本：维护债、返工、修复滞后、review burden、生态扭曲、责任错位

若这一点能被实证做扎实，论文贡献将不只是“指出风险”，而是在 AI4SE 中重新定义 productivity：

真正的生产力，不是今天省了多少 prompt 和编码时间，而是把升级、修复、review、维护和治理都算进去后，项目总成本是否真的下降。

1. 核心研究命题：研究的不是“AI 会不会选旧包”，而是“AI 是否改变了成本归属”

依赖决策是现代软件开发中最典型的“看起来只是一行配置，实际上决定长期演化路径”的工程决策。今天写下的一行版本约束，可能决定未来数月乃至数年的：

API 兼容性与升级陡坡
漏洞修复的采用速度
构建稳定性与依赖冲突概率
review 与维护返工成本
项目对某一库、某一维护状态、某一生态路径的长期绑定

传统上，这类决策由开发者显式承担：查官方文档、看 release notes、判断兼容性、比较替代方案，然后为结果负责。AI coding assistants 的出现改变了这一过程。开发者越来越习惯让 AI：

推荐完成功能所需的库
直接生成依赖配置与安装命令
补齐版本范围、import 与示例用法
用“换个库 / 换个版本”快速修 bug
在脚手架、模板、agent 自动修复流程中顺带把依赖路径写死

所以真正值得研究的，不是表层问题——“AI 会不会推荐旧版本”，而是：

依赖选择是否正在从“开发者显式判断”变成“开发者默认接受 AI 给出的现成答案”？

一旦默认接受发生，收益和成本就出现跨时间、跨角色错位：

当前作者得到：更快完成任务、减少检索、降低摩擦、提高“先跑起来”的概率。
未来维护者承担：升级困难、依赖锁定、迁移返工、review 负担、安全清理和兼容性修补。

因此，这个题本质上研究的是五件事：

谁在做依赖决策？
谁在承担长期后果？
AI 优化的是局部开发效率，还是生命周期总成本？
AI 参与依赖决策后，是否需要区别于普通代码补全的治理边界？
在什么条件下，“看起来没错”的建议仍然会制造延迟性成本？

2. 为什么是现在：窗口期已经形成，而且影响会越来越大

2.1 AI 已经进入高杠杆工程判断，但评估体系仍停留在“首轮成功”

当前很多 AI4SE 评估仍偏向近端指标：

任务完成率
开发速度
代码是否可运行
测试通过率
开发者满意度

这些指标默认“当前成功”约等于“总体成功”。但依赖决策的风险通常是延迟暴露的：

某次 PR 今天能跑，不代表三个月后不会因上游演化而失稳
某个建议今天最省事，不代表它适合长期维护
某个版本今天兼容，不代表它不会拖慢安全修复与最佳实践扩散

因此，现有评估很可能系统性高估 AI 在依赖决策上的真实价值：统计了“第一天省了多少时间”，却没有统计“第九十天多了多少维护劳动”。

2.2 邻近问题已经被证明真实，但 framing 仍然偏弱

围绕 LLM 与软件供应链，近年的研究和公开讨论已出现几个强信号：

package hallucination：模型在依赖推荐上不仅可能过时，还可能直接编造包名，形成攻击入口。
LLM-generated insecure code / tool-chain risk：AI 工具不仅生成代码，也正在成为开发流程和软件供应链中的新参与者。
依赖栈自身暴露：AI 系统本身也会通过依赖栈引入脆弱性与维护风险。

这些方向都重要，但它们大多集中在：

幻觉包
显式漏洞
工具攻击面

真正还缺的是一个更强的 SE 命题：

即便没有幻觉、没有立刻可见的漏洞，AI 依赖建议仍可能通过版本滞后、维护状态误判、上下文错配与默认采纳，持续制造维护债。

2.3 这是一个天然横跨 SE、供应链安全与人机协作治理的问题

依赖决策同时涉及：

软件工程：维护债、演化成本、review burden、兼容性治理
供应链安全：漏洞暴露、弃用库传播、补丁采用、生态健康度
人机协作：默认信任、责任边界、解释与护栏设计

因此，这不是“模型推荐质量”小题，而是一个可以同时与 AI4SE、Empirical SE、Software Evolution、Software Supply Chain Security 对话的问题。

2.4 模型更强，不等于风险自然消失

即便未来模型更强、联网更好、tool access 更完整，风险也未必自动消失，因为：

AI 使用频率会更高
更多跨栈与低经验开发者会依赖 AI 做库选型
agent 会更直接地修改依赖文件与 lockfile
模板、脚手架、自动修复与示例生成会成为新的实践传播渠道

也就是说，单次建议更准不等于系统后果更小；影响面扩大本身就是新的风险来源。

3. 研究空白：当前缺的不是“再举几个坏例子”，而是生命周期视角、识别设计与治理闭环

现有相关工作已经开始关注：

LLM 是否复现过时 API / 教程模式
AI 生成代码是否引入安全问题
LLM 是否可能持续传播脆弱依赖和旧实践
agent / assistant 在软件供应链中的暴露面

这些工作说明方向是真问题，但对“AI 依赖决策”而言仍有八个关键缺口：

3.1 从推荐偏差到生命周期后果，中间断了一层

很多观察停留在：

AI 有时不选最新版
AI 偏好训练集中高频旧库
AI 会复现过时教程中的依赖写法

但这不足以构成强 SE 命题，因为：

最新版不等于最佳版
保守版本有时确有兼容性价值
不同生态对“稳定”与“最新”的定义并不一致

真正有意义的问题不是“它旧不旧”，而是：

这个建议会不会系统性增加未来升级、迁移、安全修复和协作维护的总成本？

3.2 很少有工作问：谁受益，谁买单？

依赖建议的关键不只是“建议是什么”，更是“代价由谁承担”。AI-assisted dependency decisions 可能带来明显的责任错位：

当前作者获得更低实现摩擦
reviewer 需要额外核查依赖合理性
maintainer 承担未来升级与清理劳动
安全团队面对更慢的补丁采用
开源维护者反复处理由旧建议带来的 issue / PR

这使问题从“建议质量”升级为“成本分配机制变化”。

3.3 很少有工作把“近端收益”与“远端成本”放进同一分析式

如果只分析维护债，论文容易被视为先验反 AI；如果只分析任务完成率，又会错过长期后果。真正有说服力的框架必须同时量化：

首轮任务节省了多少时间
高风险建议被更快采纳了多少
后续返工、review、升级、补丁修复多出了多少成本

也就是把问题写成一个跨时间成本再分配模型。

3.4 现有 proposal 常见弱点：AI-assisted 变更难以高置信识别

这个方向最容易被批评的是：

AI-assisted 变更怎么高置信识别？
维护债怎么操作化，而不是概念化？
如何区分“本来就难的任务”与“AI 造成的后果”？
如何避免把 latest 当成唯一正确答案？

因此，proposal 的关键不是“想法更多”，而是识别设计更可信。

3.5 很少有工作建立一个像样的 decision rubric

很多依赖研究默认存在一个“标准正确答案”，但真实工程里，依赖选择往往是 trade-off：

稳定 vs 新功能
生态成熟度 vs 安全更新速度
迁移成本 vs 长期收益
官方推荐 vs 社区惯性

没有一个dependency decision quality rubric，研究很容易退化为“最新版中心主义”。

3.6 很少有工作把“发现问题”与“设计护栏”做成闭环

即便风险被指出，很多讨论也止于“模型可能有偏差”。对 SE 研究而言，更有价值的问题是：

什么场景最危险？
缺失了什么信息才导致危险？
哪类护栏能显著降低高风险采纳？
效率代价是否可接受？

本研究希望把这四件事串成一个可验证闭环。

3.7 很少有工作把“维护债”做成可观测 outcome

很多 proposal 会说“AI 可能增加维护成本”，但如果不能把维护债操作化，文章就会停在概念层。这里必须把它变成可观测、可复现的结果变量，例如：

后续升级、回滚、替换是否更频繁
review 讨论与 merge latency 是否更高
patch adoption 是否更慢
CI 热修、兼容性修复、清理性 PR 是否更多

3.8 很少有工作明确“最小可发表核心”是什么

这个方向很容易写成“实验、仓库分析、问卷、访谈都要做”的大杂烩。真正需要提前收紧的是：

最强的单篇论文 claim 是什么？
先做 pilot 时，哪部分证据最有说服力？
哪些数据和指标足以形成一篇扎实的 empirical SE 论文？

4. 核心主张：AI 优化的是局部可见成功，而不是跨时间总成本

本文的核心主张是：

AI coding assistants 在依赖决策上优化的往往是“局部、当前、可见”的成功指标，而不是“跨时间、跨角色、跨项目”的生命周期总成本。

由此，AI-assisted dependency decisions 可能带来五类更重要的负外部性：

维护债（maintenance debt）
由依赖选择引入、在后续升级、替换、清理、review 和兼容性修复中显现的负担。
安全滞后（security lag）
在已有补丁、弃用信号或更安全替代方案存在时，项目仍持续采用高风险路径。
生态扭曲（ecosystem distortion）
AI 反复传播训练高频但实践已不优的库、版本与模式，改变实践扩散轨迹。
责任错位（responsibility misalignment）
近端收益由当前开发者获得，远端代价却由 maintainer、reviewer、安全响应者或社区承担。
治理盲区（governance blind spot）
团队和工具往往把 dependency change 视作“普通代码生成的一部分”，却没有为其设置与风险相匹配的审查和解释机制。

据此，本研究的总目标是：

系统评估 AI-assisted dependency decisions 是否将短期开发效率转化为长期维护债与供应链风险，并提出可验证、可部署的人机协作护栏。

5. 最小可发表核心：先把一篇论文做实

为了避免 proposal 过大过散，建议把整项研究先收敛成一个最小可发表核心（minimum publishable core）：

在高风险依赖类别中，AI-assisted dependency changes 是否比 human-authored changes 更容易带来后续返工、补丁修复滞后与额外 review burden？

这个核心 claim 有七个优点：

足够具体：不再笼统讨论“所有依赖”或“所有 AI 使用”。
足够新：落点是长期后果，而不是推荐表面质量。
足够可测：可通过 follow-up、patch lag、替换 / 回滚等 outcome 观察。
足够能扩展：后续可自然外推到责任错位、治理设计与生态传播。
足够贴近论文结构：可直接组织成“问题—识别—结果—护栏”的主线。
足够现实：即使样本规模有限，只要高置信标注和 follow-up 扎实，仍有发表空间。
足够平衡：可把近端效率收益保留在次级分析里，避免文章看起来只有风险叙事。

一个更适合写成标题的核心句式是：

AI-assisted dependency decisions may not fail loudly; they may fail slowly, by converting fast task completion into delayed maintenance burden.

6. 研究问题：把 novelty、value、methods、so-what 一起钉死

RQ1. 在什么条件下，开发者会把 AI 给出的依赖与版本建议当作默认答案？

重点不是测一个笼统接受率，而是识别默认接受的触发条件：

时间压力是否显著提高采纳概率？
跨语言 / 跨生态开发时，开发者是否更依赖 AI？
当 AI 附带“可运行示例”时，开发者是否更少独立核查？
项目上下文缺失时，开发者是否更难意识到版本不匹配？
安全敏感任务中，开发者是否仍沿用普通信任模式？

RQ2. AI-assisted dependency changes 是否在提高短期任务完成率的同时，提高长期维护债？

关注的 outcome 不是“是否最新”，而是：

后续多久触发升级、回滚、替换或兼容性修复？
是否增加 review 讨论、修改轮次与 merge latency？
是否引入更大的 version lag、更多支持矩阵负担？
是否造成额外清理、迁移、重构劳动？

RQ3. AI 的依赖建议是否会延缓安全修复与最佳实践扩散？

AI 是否持续输出已被 superseded 或存在已知风险的库 / 版本？
在补丁发布后，AI-assisted changes 的修复版本采用速度是否更慢？
AI 是否放大旧教程、旧脚手架和过时博客中的依赖模式？
某些维护衰退但历史高频的包，是否在 AI-assisted change 中被异常持续传播？

RQ4. 哪些护栏能在保留 AI 效率收益的同时，显著降低高风险依赖建议采纳？

候选护栏包括：

版本依据解释：为何选这个库、为何选这个版本范围
最新信息对照：latest release、发布时间、release gap、维护活跃度
安全信号接入：advisory、CVE、弃用、unmaintained 提示
项目感知检查：读取 lockfile、runtime、已有依赖策略、支持矩阵
敏感依赖加严：认证、加密、网络、反序列化等场景要求额外确认
替代方案比较：当推荐旧库或非主流方案时，必须解释为什么不选主流替代方案

RQ5. AI 是否改变了依赖决策中的责任归属与治理边界？

开发者是否更倾向于把依赖选择理解为“AI 已判断过的默认答案”？
reviewer 是否因此承担额外甄别与追责劳动？
团队是否会因 AI 的存在而放松前置审查，却在后期补上更高治理成本？
哪些依赖类别需要区别于普通代码生成的更严格 policy？

RQ6. 这个问题究竟在什么依赖类别、生态与任务情境中最严重？

Python / npm / Cargo / Maven 风险结构是否不同？
安全敏感依赖是否明显比测试类依赖更脆弱？
新引入依赖、升级、替换、热修之间，哪类变更最受 AI 影响？
低经验开发者与高经验开发者的差异有多大？

这一问会直接决定成果是否能转化为风险分级治理建议。

7. 研究假设：把直觉推进为可检验命题

H1 默认接受假设

在时间压力、跨栈开发、低生态经验和“附带可运行示例”的条件下，开发者更可能直接接受 AI 的依赖建议。

H2 维护债转移假设

相较于人类主导的依赖变更，AI-assisted dependency changes 更可能在后续引发升级、回滚、替换、CI 修复、review 争议或依赖清理，表现出更高维护债。

H3 修复滞后假设

AI 更倾向于输出“训练高频且熟悉”的依赖模式，这会延缓安全补丁、弃用替代方案和新最佳实践的扩散。

H4 轻量护栏有效假设

在不显著增加任务耗时的情况下，加入版本依据、freshness / security 信息和 project-aware 检查，可显著降低高风险建议的直接采纳率。

H5 风险异质性假设

风险在不同生态、任务类型和依赖类别上显著不同；安全敏感依赖、演化快的生态和上下文不足场景风险更高。

H6 责任错位假设

开发者对 AI 建议的采纳越“默认化”，其对后续维护责任的主观归属越弱，而 reviewer / maintainer 的额外劳动越强。

H7 传播强化假设

对于历史高频但已不优、维护衰退或替代路径更优的依赖，AI-assisted changes 会比 human-authored changes 表现出更强的持续传播倾向。

最关键的四个支点是 H2、H4、H6、H7：它们分别对应真实后果、可干预价值、责任边界、生态传播。

8. 概念框架：从 AI 建议到生命周期后果的因果链

8.1 输入层：任务与环境条件

任务类型：新功能、修 bug、迁移、性能调优、测试补全、脚手架生成
生态类型：Python、npm、Maven、Cargo、Go
依赖类别：认证、安全库、HTTP、序列化、数据处理、测试、UI 辅助
项目上下文完整性：是否有 lockfile、support matrix、兼容性 policy、已有替代依赖
AI 能力边界：是否联网、是否有 registry / tool access、是否读取项目文件
人类因素：经验、时间压力、责任感知、对 AI 的默认信任程度

8.2 决策层：AI 输出了什么

推荐了哪个库
推荐了哪个版本或版本范围
是否 pin 版本
是否说明理由
是否提及兼容性 / 维护状态 / 安全信号
是否引用官方文档、registry 信息或 release notes
是否复现过时 API 与旧安装方式

8.3 交互层：人类如何采纳

是否直接接受
是否进行独立复核
是否修改版本或替代库
是否请求第二轮解释
是否在 review / CI 中被挑战
是否把责任感知为“这是我决定的”还是“AI 已替我判断过了”

8.4 近端结果：眼前收益

完成任务所需时间
代码是否运行
开发者主观满意度
PR 是否更快打开 / 合并

8.5 远端结果：延迟代价

version lag 与 patch lag
升级 / 回滚 / 替换概率
follow-up maintenance load
review burden 与 merge latency
漏洞暴露时长
修复扩散延迟
生态层面的传播偏好与扭曲

8.6 两种债：把 maintenance debt 再拆细一层

为了避免“维护债”概念太大太散，本文将其拆为两类：

Decision-induced debt：由单次依赖选择本身带来的未来成本，如选错库、选错版本、忽视项目上下文、引入维护衰退依赖。
Diffusion-induced debt：由 AI 在大量项目中重复传播旧模式、旧教程和过时依赖而带来的群体性成本。

这个区分很重要：

前者解释单个项目为什么返工
后者解释为什么生态层面总在重复同样的问题

9. 理论与分析框架：把“维护债”写成一个可估计模型

为了避免概念上很强、分析上很虚，本文建议把核心命题写成一个明确的成本转移方程：

[ LifecycleCost_{i} = ImmediateBenefit_{i} - DeferredMaintenanceCost_{i} - SecurityDelayCost_{i} - GovernanceOverhead_{i} ]

其中，单位 (i) 可以是一次 dependency-related change、一次 PR，或某项目-依赖-时间窗口。关键不在于把所有成本都货币化，而在于建立一个统一分析框架，使不同研究阶段围绕同一逻辑展开：

ImmediateBenefit：任务完成时间、首次可运行成功率、PR 打开速度、检索次数减少
DeferredMaintenanceCost：回滚、替换、后续升级、兼容性修复、CI 热修、review burden
SecurityDelayCost：补丁采用时滞、停留在已知高风险版本的时长、弃用迁移滞后
GovernanceOverhead：额外 review、解释成本、责任甄别和组织 policy 的补救成本

这个框架的意义在于三点：

它把收益与成本放进同一张表，避免 proposal 只讲风险。
它允许不同研究方法围绕同一因变量族展开，而不是各说各话。
它自然支撑“AI 是否真的提高生产力”这一更大的 AI4SE 命题。

10. 贡献的真正落点：不是“AI 有问题”，而是提出一套可证伪的生命周期成本框架

10.1 贡献一：提出可计算的 lifecycle cost transfer framing

核心不是笼统说“以后会更难维护”，而是把成本转移显式写成一个可观测框架：

即时收益端：任务完成时间、首轮成功率、少查资料、少改代码
延迟成本端：后续升级、返工、审查、补丁修复、兼容性修复
承担者维度：当前作者、reviewer、maintainer、安全 triager、社区维护者

换句话说，本文不是判断 AI “好不好”，而是判断：

AI 在依赖决策上带来的收益和成本，是否被分配给了不同时间点、不同角色的人。

10.2 贡献二：把 dependency decision quality 从单维 freshness 改成多维工程质量

不把 latest 当金标准，而是同时评估：

task fit
project fit
lifecycle fit
security / maintenance fit
justification quality

这使研究能区分：

合理保守的版本选择
出于兼容性考虑的非最新版选择
真正会提高长期维护债的糟糕选择

10.3 贡献三：把“能发现问题”推进到“能设计治理机制”

真正能打动审稿人的，不是再证明一次 AI 会犯错，而是证明：

风险主要集中在哪些依赖场景
哪些信号缺失导致开发者默认接受
哪些轻量护栏能显著降低风险而不显著拖慢开发

这让研究从描述性工作进入诊断 + 干预闭环。

10.4 贡献四：把 dependency governance 从“编码附属问题”提升为独立治理对象

本文希望明确提出：

AI-assisted dependency change 不应被视作普通代码补全的副产品，而应被视作独立的工程治理对象。

这意味着：

依赖推荐需要单独的解释义务
高风险依赖应有更高审查门槛
AI 工具应暴露其版本依据和风险证据
团队 policy 应显式区分“代码片段生成”和“依赖决策生成”

这一点会让论文的实践意义明显强于普通 recommendation-quality 研究。

这部分必须在正式论文里提前写硬，否则审稿人会默认把它归到“又一篇 LLM 建议质量论文”。比较合适的定位方式是把邻近工作分成四类，并明确边界。

11.1 package hallucination / fake package 风险

这类工作证明：LLM 可能推荐不存在的包，从而形成 typosquatting 或恶意抢注攻击面。它们强调的是明显错误的依赖输出。本文不同：

关注的包可以是真实存在的
安装可以成功
功能可以跑通
但依然可能制造未来升级、维护与安全负担

也就是说，本文研究的是不明显犯错时的长期成本。

11.2 LLM insecure code generation / secure coding

这类工作关注 AI 是否生成不安全代码、错误 API 调用或脆弱实现。本文与其相关，但焦点不同：

不是函数内部实现是否安全
而是选了哪个依赖、哪个版本、哪条演化路径
研究对象从“代码片段”转向“项目演化决策”

11.3 software evolution / dependency management / update lag

传统 SE 已有大量关于依赖升级、漏洞修复滞后、npm / PyPI / Maven 演化的研究。本文不是重复这些工作，而是把 AI 作为新的决策参与者与扩散机制 引入分析框架：

谁在影响依赖采用？
AI 是否改变 adoption curve？
AI 是否改变 patch lag 的分布？

11.4 human-AI collaboration / trust calibration

现有 HCI/AI4SE 工作常研究：开发者什么时候信 AI、怎么校准信任。本文与其共享“默认接受”问题，但更进一步：

不是只看是否信任
而是看这种信任如何在生命周期上外溢成维护债与责任错位
并最终落到 dependency governance 的具体设计上

一句话说清本文位置：

本文位于“AI 推荐质量”“依赖演化”“人机信任校准”三条文献线的交叉点，但贡献核心是把依赖决策重构为一个生命周期成本转移问题。

12. 论文主贡献：不要只说问题大，要说交付物硬

如果研究做成，论文至少应交出以下八类贡献：

C1. 一个新的问题框架

将 AI 依赖推荐重新定义为“短期效率与长期维护债之间的成本转移问题”，而非单纯 recommendation accuracy 问题。

C2. 一套 dependency decision quality rubric

把“好的依赖决策”从单一的 version freshness 扩展为多维标准：

任务适配性
项目上下文一致性
安全与维护状态
演化可持续性
替代方案比较充分性

C3. 默认接受与责任错位的机制证据

解释开发者为什么会信、在哪些情况下最容易信，以及这如何改变责任边界。

C4. 关于真实后果的纵向证据

给出 AI-assisted dependency changes 与后续维护返工、修复滞后、review burden 等 outcome 的实证关联。

C5. 一套 lifecycle cost transfer 的度量方案

把近端效率收益与远端维护 / 安全成本放进同一分析框架，而不是只报一边。

C6. 一套可部署的护栏设计原则

明确哪些信息和交互机制能有效降低高风险采纳，又不显著损害生产力。

C7. 一套 dependency governance 建议

将高风险依赖类别、审查门槛、解释要求和 CI / policy 集成建议系统化。

C8. 数据与工件资产

留下 benchmark、rubric、纵向样本集、coding manual、prototype 和复现实验脚本，而不是只留一篇论文本身。

13. 研究设计总览：三阶段混合方法，但每一步都收敛到可识别证据

真正可发表的主线应是：

Study 1：受控任务实验 —— 识别默认接受、责任错位和高风险情境
Study 2：真实 OSS 纵向分析 —— 识别 AI-assisted dependency change 的后续维护 / 安全后果
Study 3：护栏干预实验 —— 验证哪些信息和交互机制能减少高风险采纳

这三步不是平铺并列，而是形成一个闭环：

Study 1 找机制
Study 2 找真实后果
Study 3 找可部署干预

更关键的是，三者围绕同一条核心逻辑服务：

AI 是否把近端可见收益建立在远端不可见成本之上？

一个更清晰的论文主线

如果只允许一篇主论文，建议把全文重心放在 Study 2，把 Study 1 和 Study 3 服务化：

Study 1：解释“为什么会发生”
Study 2：证明“后来发生了什么”
Study 3：回答“能怎么缓解”

这会比三项工作平均用力更有投稿战斗力。

14. Study 1：受控任务实验——AI 如何影响依赖选择与默认接受？

14.1 目标

识别不同 AI assistants 在依赖推荐上的行为模式，以及开发者在何种情境下更容易直接接受建议。

14.2 任务设计

构造一组真实但可控的软件任务，覆盖多语言、不同风险级别和不同依赖角色：

Python Web 项目加入 JWT / password hashing / HTTP client / serialization
Node.js 服务加入 auth middleware / ORM / validation / HTTP client
前端项目加入表单验证、状态管理、日期处理库
CI / 测试场景加入测试框架、mock 工具、linter / plugin
同一功能设置主流替代库竞争情境，避免退化成“唯一正确答案题”

这里必须刻意加入四类高鉴别度任务：

存在历史老牌库，但已有更优现代替代的任务
存在安全敏感依赖的任务
存在项目上下文约束的任务（例如已有框架版本、runtime 限制、组织 policy）
存在教程惯性很强的任务（最能观察 AI 是否复制旧实践）

14.3 实验操纵

AI 条件：不同 assistant；联网 vs 非联网；有护栏 vs 无护栏
人类条件：高 / 低生态经验；时间压力高 / 低
任务条件：安全敏感 vs 普通；项目上下文完整 vs 缺失

14.4 数据采集

采集三类数据：

AI 输出数据：推荐库、版本、理由、是否提及兼容性 / 风险
过程数据：开发者是否追问、是否查官网 / registry、决策耗时、修改轨迹
结果数据：最终依赖质量、成功率、主观信任、认知负担、责任归属

14.5 关键指标

输出质量指标

是否选择维护活跃、合理的库
版本范围是否合理（过宽 / 过窄 / 无 pin / 盲目 pin）
是否忽略项目已有栈与兼容性要求
是否在安全敏感任务中推荐明显高风险方案

人类行为指标

直接接受率
复核率
二次修改率
对 AI 理由的依赖程度
责任归属感知

责任与治理量表

为了让 Study 1 不只是行为日志，还能支撑 H6，加入简短量表：

“我认为该依赖选择主要是我的决定 / AI 的决定”
“如果未来出问题，我认为主要责任在我 / 在工具 / 在团队流程”
“我认为当前建议已经足够，不需要额外核查”
“我觉得 review 阶段仍会替我兜底”

14.6 分析价值

Study 1 回答的不是“AI 推荐得准不准”这么窄，而是：

AI 在依赖决策上实际输出什么模式？
开发者为什么会信？
默认接受最容易在什么条件下发生？
护栏到底是在校准信任，还是单纯增加打扰？

15. Study 2：真实 OSS 纵向分析——AI-assisted dependency changes 是否演化为维护债？

15.1 目标

使用真实开源仓库中的高置信 AI-assisted dependency changes，评估其后续维护和安全后果。

15.2 为什么这是整篇 proposal 的实证核心

如果只做 Study 1，容易被质疑“实验室任务不代表真实开发”；如果只看模型输出，则看不到后果。Study 2 直接回答：

这些依赖决策后来到底造成了什么？

15.3 数据来源：高置信样本，而不是盲目大抓取

AI-assisted 标注本身噪声很大，因此不应追求“海量但脏”的数据，而应采用高置信识别 + 匹配对照。

高置信 AI-assisted 样本来源

明确标记为 AI-assisted、agent-authored、copilot/coauthored 的 PR / commit
已知 agent / bot 账号提交的 dependency-related changes
PR 描述、commit message、review 讨论中显式提及 Claude / Copilot / Cursor / Devin 等工具
平台原生 agent 轨迹或元数据可见的变更

对照组构造

按以下维度匹配人类主导 dependency changes：

相同生态与包管理器
相近仓库规模与活跃度
相近任务类型（新引入依赖、升级、补丁修复、替换库、热修）
相近时间窗口
相近依赖风险等级

15.4 分析对象

优先抽取以下清晰的依赖文件变化：

requirements.txt
pyproject.toml
package.json
package-lock.json / pnpm-lock.yaml
pom.xml
Cargo.toml
go.mod

并将 dependency change 细分为：

新引入依赖
版本升级 / 降级
依赖替换
补丁 / 漏洞修复相关变更
为修 bug 而顺带引入的依赖改动

15.5 Outcome：把“维护债”操作化成可观测变量

维护债类结果

后续 30 / 90 / 180 / 365 天内是否发生升级、回滚、替换
dependency-related follow-up commit / PR / issue 数量
review comment 数量、修改轮次、merge latency
是否引发构建失败、兼容性修复或 CI 热修
是否出现“删掉这个依赖 / 换掉这个库 / 改成官方推荐方案”式返工

安全类结果

引入时是否已存在 advisory / deprecation / unmaintained signal
补丁版本从发布到项目采用之间的时滞（patch lag）
是否因漏洞或弃用而触发紧急 follow-up
是否持续停留在存在更安全替代方案的路径上

生态类结果

某些包 / 版本在 AI-assisted changes 中是否异常集中
某些旧模式是否在 AI-assisted changes 中被持续复制
修复版本 adoption curve 在 AI-assisted 与 human-authored 之间是否存在显著差异

15.6 识别策略：这是 proposal 成败的关键

为了降低“AI 更常被用于难任务”的混杂，建议使用：

精细匹配 / propensity score matching：平衡仓库、时间、任务和风险类别
survival analysis：分析升级、修复、替换发生时间
event study：观察 dependency change 之后维护负担的演化轨迹
分层分析：按生态、依赖类别、项目成熟度、安全敏感性分层
人工编码验证：小样本审查 outcome 是否真的与依赖决策相关

15.7 一个更硬的因果叙事：从“相关”到“可信关联”

这类研究很难做强因果识别，因此更务实的写法应是：

主文不夸大为完全因果结论
强调 high-confidence longitudinal association
在高风险子类中用更细粒度人工编码增强解释
把“哪些结果最像由依赖决策触发”与“哪些结果只是伴随现象”分开报告

15.8 一个更具体的主要识别窗口

为了让设计更像真正能跑的 empirical study，建议预先锁定：

index event：某次 dependency-related PR/commit 被合并
short follow-up：30 / 90 天，观察快速返工、回滚、CI 热修
medium follow-up：180 天，观察升级、替换、补丁采用
long follow-up：365 天，观察迁移、弃用、重构和治理成本

这种分层窗口的好处是：

能区分“马上就出问题”的坏建议与“慢性制造负担”的建议
更适合做 event-time 图和 hazard 模型
更容易把维护债拆成短期返工与长期拖尾两类机制

15.9 先做哪两个生态最稳：Python + npm

为了让 pilot 更可交付、也更容易形成清晰异质性结论，建议第一阶段只聚焦：

Python / PyPI：AI 使用广、生态复杂、教程惯性强
npm / Node.js：依赖层级深、版本波动快、供应链讨论成熟

先把 Python + npm 打透，比一开始铺到 Maven / Cargo / Go 更像一篇能发的 empirical SE 论文。

16. Study 2 的数据建模再落一层：怎么把“维护债”做成真正能跑的分析表

这一节是 proposal 进一步变硬的关键：不是只说“会做纵向分析”，而是说明最终数据表长什么样。

16.1 事件级数据表（event-level table）

每一条记录对应一次 dependency-related change，至少包含：

仓库基本信息：生态、星数、活跃度、创建时间、贡献者数量、CI 状态
变更基本信息：新引入 / 升级 / 降级 / 替换 / 热修、涉及文件数、PR 大小、是否安全相关
依赖基本信息：包名、版本范围、风险类别、是否为直接依赖、是否为运行时依赖
AI 识别信息：高置信来源类型、显式工具提及、是否 agent account
暴露变量：version lag、patch lag、maintenance-state signal、deprecation signal、context mismatch
结果变量：后续升级、替换、回滚、CI 热修、review burden、merge latency、follow-up issue/PR

16.2 依赖级随时间面板（dependency-time panel）

对于需要观察补丁采用和替换时滞的问题，可把包-项目-时间构造成 panel：

时间粒度：周或月
状态变量：当前采用版本、是否落后于最新稳定版、是否落后于安全修复版
事件变量：该时间窗内是否发生升级、回滚、漏洞修复、弃用迁移
AI 暴露变量：该依赖是否由 AI-assisted change 首次引入 / 最近一次更新

这样可以更自然地建模：

补丁发布后多久被采用
某类依赖在 AI-assisted 项目里是否更久停留在旧版本
风险信号出现后，AI-assisted 路径是否更慢退出

16.3 follow-up maintenance 的编码层级

为了避免“任何后续改动都算维护债”的泛化，建议把后续维护分三级：

Tier 1：明确依赖修正
例如升级、替换、回滚、删除依赖、修正版本约束。
Tier 2：依赖诱发修复
例如兼容性修复、CI 热修、lockfile 冲突处理、API 适配。
Tier 3：关联但不完全确定
例如与该依赖相邻的性能修补、测试修补、文档解释。

主分析可聚焦 Tier 1 + Tier 2，Tier 3 只在补充材料中报告。

16.4 一个更适合发表的主要结果写法

如果要让结果既稳健又不夸大，建议把主结果写成：

与匹配的人类主导依赖变更相比，高置信 AI-assisted dependency changes 在高风险依赖类别中表现出更高的后续维护风险与更慢的安全修复采用速度；这种差异在测试类或低风险 utility 依赖中显著减弱。

这样的结果结构有三个好处：

有异质性，不是粗暴平均效应
有负控，不容易被批评为泛化过度
更贴近“治理应聚焦高风险场景”这一实践落点

16.5 建议加入的负控与安慰剂分析

为了进一步增强可信度，Study 2 最好补两类分析：

负控（negative controls）

测试框架、lint 插件、开发时 utility 等低风险依赖
只改文档但 PR 描述提到 AI 的样本
不涉及 dependency file 的 AI-assisted 代码 PR

如果主要效应只集中在高风险依赖类别，而不在这些负控上显著出现，会明显增强论证力度。

安慰剂窗口（placebo windows）

在 index event 之前的时间窗看是否已存在相同趋势
对未发生 dependency change 的相似 PR 做“伪 index event”测试

这样能更好地区分“本来就容易返工的仓库”与“依赖决策后的后续负担”。

17. Study 3：护栏干预实验——什么样的 AI 设计能减少高风险采纳？

17.1 目标

验证哪些轻量护栏可以降低高风险依赖建议采纳，同时尽量保留效率收益。

17.2 原型设计

构建一个轻量 prototype，模拟 IDE / agent 在推荐依赖时附带：

Version rationale：为什么推荐这个库 / 版本范围
Freshness panel：latest release、发布日期、release gap、维护活跃度
Security panel：advisory、弃用、维护衰退、许可或供应链风险信号
Project-aware checks：读取项目已有依赖、runtime、lockfile、支持矩阵
Risk-tier policy：高风险依赖需要额外确认或对比替代方案
Alternative comparison：当不选主流方案时，解释 trade-off

17.3 干预设计：不要只比较“有护栏 vs 无护栏”

更强的设计是拆分不同护栏的贡献：

解释型护栏：给出理由，但不给最新 / 安全信号
信息型护栏：给出 freshness / security / project-aware 信息
升级型护栏：对高风险依赖强制二次确认或要求比较替代方案

这样能回答一个更实用的问题：

究竟是“更多解释”有效，还是“更具体的外部证据”有效，还是“风险分级策略”最有效？

17.4 评估指标

高风险建议直接采纳率
开发者复核率与二次查询率
最终依赖决策质量
任务时间变化
主观可用性、打扰感与信任校准程度

17.5 成功标准

成功不是“让开发者不再信 AI”，而是：

高风险默认接受显著下降
合理建议仍可快速通过
开发者更清楚自己在承担什么后果
工具层面具备现实部署可行性

18. 度量设计：把“维护债”“安全滞后”“生态扭曲”真正变成研究变量

18.1 Exposure-oriented metrics（暴露类）

Version lag：相对最新稳定版的版本差或发布时间差
Patch lag：相对安全修复版本的采用时滞
Deprecation exposure：是否引入已弃用 / 维护衰退依赖
Context mismatch：建议是否与项目 runtime / framework / support policy 冲突
Maintenance-state mismatch：是否把低活跃、低响应、低发布频率库当作默认建议

18.2 Maintenance-oriented metrics（维护类）

Follow-up maintenance load：后续围绕该依赖决策发生的 commit / PR / issue 负担
Review burden：额外 review 评论、轮次、讨论长度、合并延迟
Migration burden：后续升级 / 替换时受影响文件数、代码改动规模、API 适配量
Rework incidence：是否因当初选择不当而出现显式返工
Stability debt：后续是否出现依赖冲突、锁文件震荡、CI 不稳定

18.3 Decision-quality metrics（决策质量）

是否与项目现有技术栈一致
是否满足任务的非功能需求（安全、性能、兼容性、维护性）
是否存在过宽版本范围、无理由 pin、盲目依赖最新 / 旧版本
是否忽略已有依赖策略或组织 policy
是否解释“为什么不是另一个更主流 / 更安全 / 更活跃的替代方案”

18.4 Ecosystem-oriented metrics（生态类）

AI-assisted changes 对特定包 / 版本的传播偏好
不同类型依赖在 AI-assisted changes 中的 adoption concentration
补丁 / 弃用信号发布后，AI-assisted adoption curve 的变化速度
“训练高频但实践过时”的包是否被持续强化

18.5 Governance-oriented metrics（治理类）

为了让“责任错位”可测：

开发者对决策责任的主观归属
reviewer 对 AI-assisted dependency change 的额外核查时间
团队是否为 AI-assisted dependency change 启动额外审查流程
AI-assisted dependency PR 是否更容易在 review 中出现“请解释为什么选这个库 / 版本”

18.6 Efficiency metrics（效率收益）

为了避免论文变成先验反 AI 论证，也必须保留收益指标：

首次任务完成时间
首次可运行成功率
开发者感知效率
初始 PR 创建速度
为完成依赖决策所需的额外信息查询次数

只有把收益和延迟成本放在同一分析框架里，才能回答“AI 到底是降成本，还是把成本后移”。

19. Decision rubric：什么才算“好的依赖决策”？

这一题的关键不在于找一个单点标准答案，而在于建立一个能被重复使用的 dependency decision quality rubric。建议至少包含五个维度。

19.1 Task fit（任务适配）

是否满足当前功能需求？
是否存在更直接、更低复杂度的替代方案？
是否引入了不必要的大型依赖？

19.2 Project fit（项目适配）

是否与当前 runtime、framework、支持矩阵兼容？
是否与现有技术栈重复或冲突？
是否增加了组织 policy 不允许的依赖类型？

19.3 Lifecycle fit（生命周期适配）

版本策略是否有利于后续升级与维护？
是否引入已知迁移陡坡或生态不稳定路径？
是否提高未来锁定、替换或清理成本？

19.4 Security and maintenance fit（安全与维护适配）

是否存在 advisory、弃用、维护衰退信号？
是否有更活跃、更安全的主流替代方案？
对高风险功能是否过度依赖社区惯性而非当前最佳实践？

19.5 Justification quality（论证质量）

是否给出为什么选这个库 / 版本的具体理由？
是否解释为什么不选主流替代方案？
是否把 trade-off 讲清楚，而不是只给“能跑”的答案？

19.6 建议把 rubric 落成 0–2 或 0–3 的分层评分卡

为了让 rubric 真正可用，而不是停留在概念层，建议将每个维度落成结构化评分：

0 = 明显不满足
1 = 部分满足 / 有明显缺口
2 = 满足且无明显风险

如需更细，可扩展到 0–3，并附人工编码说明：

何种情况属于“合理保守”
何种情况属于“上下文错配”
何种情况属于“存在更优替代但未解释”

这样做的意义很大：

它避免研究退化成“最新版崇拜”
它让 Study 1 与 Study 3 的人工评估可复用
它也能成为后续 artifact 的核心交付物

20. 识别策略再收紧：如何让审稿人相信“这不是 obvious confounding”

这是 proposal 最容易被攻击的一块，因此需要提前把可识别性写硬。

20.1 不把 latest 当金标准

“不是最新版”不等于“是坏决定”。判断优劣时，必须综合：

任务需求
项目已有依赖与 runtime 约束
维护活跃度
安全信号
升级与迁移成本
替代方案相对优劣

因此，本研究不会把“和 latest 的距离”当唯一 outcome，而会把它作为暴露指标之一。

20.2 高置信识别优先于大样本

真实仓库中识别 AI-assisted 变更本就困难。这里应明确选择：

宁可样本少一点，也要保证 AI-assisted 识别可信。

这意味着：

优先取显式自述、agent 账号、平台元数据可见的样本
在论文中明确区分“高置信主分析样本”与“低置信扩展样本”
稳健性分析中测试不同识别阈值的结果是否一致

20.3 用 matched comparison 减少“AI 用于难任务”的偏差

因为 AI 常被用在赶工、跨栈、陌生生态等困难任务上，如果直接比均值，很容易把“难任务效应”误当成“AI 效应”。因此应做：

仓库层匹配：规模、活跃度、成熟度、CI 健康状况
变更层匹配：任务类型、风险等级、文件数、是否安全相关、时间窗口
依赖层匹配：生态、包类别、是否新引入、是否补丁修复

20.4 用 survival / hazard framing 看延迟后果

这个题的重点就是“后果会延迟出现”。因此比起简单均值比较，更自然的是：

某次依赖变更后，多久迎来升级 / 替换 / 回滚？
某个补丁发布后，多久被项目采用？
某种风险暴露后，多久触发 follow-up maintenance？

这类问题用 survival analysis / hazard ratio 表达，会比静态均值更贴题，也更容易形成有说服力的图。

20.5 小样本人工编码必须服务于关键识别点

人工编码不是为了“看起来更扎实”，而是要聚焦三类关键问题：

后续返工是否真的由依赖决策引发？
该依赖在当时是否已有明确维护 / 安全 / 弃用信号？
AI 采纳是否表现出“默认接受”而非独立审慎判断？

如果人工编码只做泛泛主题分析，价值会很弱；必须对准识别短板。

20.6 预注册与多研究者编码，可进一步提升可信度

如果资源允许，可以进一步加入：

pilot-level preregistration：提前锁定主要 outcome、时间窗与主要比较
double-coding：关键样本双人编码并报告一致性
robustness tiers：高置信样本、扩展样本、不同生态子样本分别报告

20.7 威胁不是只写 threats to validity，而是前置到设计里

这版 proposal 应主动把主要 threats 变成设计原则：

标注噪声 → 高置信识别 + 人工复核
latest 偏见 → 多维质量 rubric
任务难度偏差 → 匹配 + 分层 + negative controls
后果延迟 → survival framing + 多时间窗
过度概括 → 先 Python / npm，再谨慎扩展

这样读者看到的是“从一开始就按 threats 设计”，而不是最后补一个套路化 validity section。

21. novelty 到底在哪里：为什么它不是“又一篇 LLM 推荐质量论文”？

21.1 从“推荐正确性”转向“生命周期成本转移”

论文关注的不是 AI 是否偏离某个静态金标准，而是：

AI 是否把本应由当前作者承担的判断成本，转嫁成未来维护者承担的演化成本。

这比单纯看 recommendation accuracy 或 version lag 更有软件工程解释力。

21.2 从个体效率转向跨角色成本分配

本题不只看 coder 的收益，还同时看：

reviewer 的额外工作
maintainer 的长期返工
security / community 的修复扩散成本

这让研究天然带上治理维度，而不只是“开发者体验”。

21.3 从微观输出质量转向生态传播机制

AI 可能是新的依赖实践传播媒介。研究它如何放大、延缓或扭曲依赖实践扩散，比普通“生成代码质量”研究更贴近当前供应链安全的关键议题。

21.4 从发现问题到验证护栏

如果研究只证明“AI 有风险”，边际贡献有限。加入护栏设计与实验后，论文会从“诊断问题”升级为“提出可部署干预”。这对 ICSE / FSE / ASE / EMSE 审稿人更有说服力。

21.5 与 package hallucination 相邻，但不重合

package hallucination 已很好证明：LLM 在依赖建议上可能产生不存在的包。而本文要打的是另一个更隐蔽、也更常见的问题：

包名是真的
安装能成功
功能也能跑
但这个选择仍可能在几个月后制造更高维护债

换句话说：

包幻觉证明了“AI 可能非常明显地犯错”；本研究要证明的是“AI 即便不明显犯错，也可能系统性地制造长期成本”。

22. so-what：如果结果成立，它到底改变什么？

22.1 对 AI4SE：重写 productivity 的评价边界

如果这项研究成立，就意味着很多现有 AI4SE 评估默认忽略了最关键的一段成本：

当前作者少花的时间
与未来维护者多花的时间
并不一定发生在同一阶段、同一角色、同一个 sprint

这会推动 AI4SE 从“能不能更快生成代码”转向“能不能在整个软件生命周期内真正降低总成本”。

22.2 对软件工程：把 dependency management 从配置细节重新提升为演化决策

很多工程实践默认把依赖变更当作机械配置修改，但本研究强调：

dependency selection 是一种设计决策
dependency update 是一种演化治理决策
AI 介入后，这类决策需要单独的审查逻辑，而不是被混在一般代码补全里

22.3 对供应链安全：找到补丁扩散链中的一个新摩擦源

安全社区长期关注发现、披露、修复与传播，但 AI-assisted development 可能在“开发者采纳哪条依赖路径”这一步新增摩擦。若能证明 patch lag 与 AI-assisted changes 有关，这会直接连接到现实风险治理。

22.4 对工具厂商：给出可部署而不是空泛的设计要求

研究结果可以直接转化为：

IDE / agent 默认展示依赖依据与 freshness / security 信号
对高风险依赖启用更严格确认
依赖推荐界面必须显示替代方案与 trade-off
对 project-aware mismatch 做强提示而不是弱提示

22.5 对团队与 OSS 社区：给出 policy 级建议

例如：

对 AI-assisted dependency PR 启用单独 review checklist
对认证、加密、HTTP、反序列化、构建插件等高风险依赖设置更高审查门槛
在 CI 中自动标记有 AI 参与且涉及 dependency file 的变更
registry / package ecosystem 改善维护状态、弃用信息与 advisory 元数据对 AI 的可消费性

这就是这题的真正 so-what：它不是在证明“AI 也会犯错”，而是在界定什么样的 AI 帮助值得信、什么样的帮助需要被治理。

23. 一个更具体的治理产出：把研究结果直接翻译成团队 policy

为了让 proposal 更像能落地的研究，而不是只停在学术 framing，建议把预期治理产出写得更具体。若结果成立，可直接产出如下 policy 模板：

23.1 AI-assisted dependency change review checklist

对于所有修改 dependency file 的 AI-assisted PR，review 至少检查：

该依赖是新引入、升级、替换还是紧急修复？
是否给出版本选择依据？
是否存在更主流、更安全或更活跃的替代方案？
是否与现有 runtime / framework / support matrix 一致？
是否引入额外许可证、维护或供应链风险？

23.2 高风险依赖分级策略

可将下列类别纳入更高门槛：

认证与授权
加密与秘钥管理
HTTP / network stack
反序列化与解析器
ORM / database driver
构建插件与 CI 扩展

对于这些类别，要求：

AI 必须给出替代方案比较
reviewer 必须显式确认版本依据
CI 自动拉取 advisory / deprecation 信号

23.3 工具侧最小护栏要求

对于推荐依赖的 AI 工具，至少应显示：

建议库与版本依据
发布时间与维护活跃度
是否存在已知 advisory / deprecation
与当前项目上下文的潜在冲突

这一节的意义在于：它让论文不仅能产出“发现”，还能产出可直接采纳的工程治理条目。

24. 数据与产出资产：这项研究做完后应留下什么

为了让 proposal 不只是“讲道理”，这里把最终应沉淀的数据资产写清楚。

24.1 数据资产

Dependency decision task benchmark
一套覆盖 Python / npm 的高风险与普通风险任务集。
Decision quality rubric
用于评估依赖选择是否合理，而非机械对照 latest 版本。
AI-assisted dependency change dataset
含高置信标签、依赖变更类型、生态、风险类别、后续跟踪窗口。
Follow-up maintenance coding manual
明确如何标注返工、替换、patch lag、review burden 等 outcome。
Guardrail prototype + experiment logs
用于复现实验与工具原型评估。
Dependency governance template
从实证结果提炼出的 review checklist、风险分级矩阵和最小护栏建议。

24.2 论文资产

一张 lifecycle-cost 概念图
一张 risk taxonomy + guardrail mapping 图
一张 event-time / survival 图
一张 efficiency-vs-maintenance trade-off 图
一张 responsibility-shift 示意图
一套能直接复用到后续论文的 appendix / artifact 包

24.3 为什么这很重要

很多 proposal 的问题是：文章写完，资产为空。这个题如果能留下 benchmark、rubric 和纵向样本集，后续可以继续拓展到：

不同模型与 agent 的横向比较
registry 侧 metadata 改造
组织政策与 CI 规则设计
更长期的 patch diffusion 研究

25. 一个更强的 pilot 路线：先拿到能说服人的证据，而不是一开始铺太大

Phase A：建立任务集与标注规范

聚焦 Python + npm
选 12–20 个依赖决策任务
明确安全敏感与普通任务分层
产出依赖决策质量 rubric 与维护债编码手册

产出：一套可复用 benchmark / rubric，这本身就有价值。

Phase B：小规模受控实验

招募有限数量开发者
测默认接受、复核率、责任感知与护栏初始效果
识别最明显的风险场景

产出：机制证据，证明问题真实存在且不是纯想象。

Phase C：高置信 OSS 纵向样本

先不追求几万条样本
聚焦近期明确 AI-assisted 的 dependency PRs
结合人工审阅做纵向跟踪

产出：最关键的真实后果证据。

Phase D：护栏原型与复现实验

把 freshness / security / project-aware 信息做成轻量 prototype
在 Study 1 场景复现实验
测采纳率、时间成本和信任校准

产出：论文从发现问题走向可干预设计。

Phase E：补一个“生态传播”小切口

如果时间允许，可追加一个更轻但很抓人的分析：

选若干历史高频、现已不优或维护衰退的典型库
比较它们在人类普通变更、AI-assisted 变更与教程 / 模板中的持续传播轨迹

产出：把“生态扭曲”从概念变成一组直观证据，特别适合论文动机与图表展示。

一个更现实的三论文拆分方案

为了避免“大一统计划”难以执行，也可以直接按三篇论文来规划：

Paper 1（机制）：默认接受、责任错位与 dependency decision rubric
Paper 2（主论文）：AI-assisted dependency changes 的纵向维护债与 patch lag
Paper 3（干预）：guardrail prototype 与高风险依赖治理设计

这样的拆分更适合博士阶段滚动产出，也更符合软件工程实证研究的节奏。

26. 一页式研究蓝图：每个研究问题对应什么证据、什么结果、什么交付物

研究问题	核心方法	主要结果变量	预期交付物
RQ1 默认接受	受控任务实验	直接采纳率、复核率、责任归属	默认接受机制模型
RQ2 维护债	纵向 OSS 分析	follow-up maintenance、回滚/替换、merge latency	AI-assisted dependency change dataset
RQ3 安全滞后	panel + survival analysis	patch lag、弃用迁移时滞、风险暴露时长	patch diffusion 分析图表
RQ4 护栏有效性	干预实验	高风险采纳率、任务耗时、信任校准	guardrail prototype
RQ5 责任错位	量表 + review 证据	主观责任归属、review 额外劳动	dependency governance 建议
RQ6 风险异质性	分层分析	不同生态/依赖类别的 hazard 差异	风险分级矩阵

虽然正式论文里未必保留这张表，但它对 proposal 很重要，因为它迫使每个问题都回答：

证据从哪来？
结果怎么量？
做完能留下什么？

27. 可行性与主要风险：proposal 不能只会讲 ambition

一个更成熟的研究计划，必须主动承认可行性边界，并说明如何控风险。

27.1 风险一：高置信 AI-assisted 样本规模可能有限

风险：显式标注 AI 使用的 OSS 依赖变更可能没有想象中多。
应对：

把主分析明确限定为高置信样本，不贪大
先做 Python + npm 两个生态
把扩展样本当 robustness，而不是主结论来源

27.2 风险二：后续返工不一定都能归因于依赖决策

风险：follow-up maintenance 可能与整体代码质量、需求变更或外部演化交织。
应对：

人工编码只围绕“是否与依赖决策直接相关”这一关键点
使用多个 outcome，而非押单一指标
用 negative controls 和分层分析减少误读

27.3 风险三：decision rubric 容易被批评为主观

风险：依赖优劣往往存在 trade-off，容易被质疑评估标准主观。
应对：

rubric 采用多维结构而非单点标签
报告双人编码一致性
把“存在合理争议”的案例从“明显不良决策”中分开

27.4 风险四：护栏实验可能只证明“更多信息会拖慢人”

风险：任何护栏都可能因增加认知负担而降低效率。
应对：

将解释型、信息型、升级型护栏拆分比较
只在高风险依赖场景提升干预强度
保留时间成本与主观打扰感指标，显式报告 trade-off

27.5 风险五：研究过早扩展到太多生态与 venue

风险：题目天然可扩，但一开始铺太广会削弱识别与深度。
应对：

先把 Python + npm 的主结果打穿
先拿到一个强 pilot claim，再考虑生态扩张
先按 empirical SE 论文标准写作，而不是一开始就追求“大一统框架”

28. 一个更适合投稿的论文骨架

为了让 proposal 更接近可写成论文的形态，可以直接按下列结构组织：

Introduction
依赖决策是高杠杆工程判断；AI 提升近端效率，但可能后移生命周期成本。
Motivating examples
用 2–3 个典型依赖场景展示“今天能跑、明天返工”的张力。
Research questions and framing
把问题明确界定为 maintenance debt / patch lag / responsibility misalignment。
Decision rubric and risk taxonomy
说明如何定义“好的依赖决策”，避免 latest-only 误区。
Study 1: controlled experiment
证明默认接受和责任错位的机制真实存在。
Study 2: longitudinal OSS analysis
证明 AI-assisted dependency changes 与后续维护 / 安全后果存在可信关联。
Study 3: guardrail intervention
证明并非只能指出问题，也能设计轻量缓解机制。
Discussion
回到 AI4SE productivity、dependency governance、registry metadata、team policy。
Implications and artifact
强调 benchmark、rubric、dataset、manual、prototype 的可复用价值。

这个骨架的好处是：从引言到 artifact 的链路非常顺，不像很多 proposal 一样停在“问题很重要”。

29. 投稿定位：怎么讲，决定这题看起来像“小观察”还是“大问题”

如果先做 pilot

可定位为：

AI4SE / 软件供应链安全 workshop
ICSE / FSE / ASE 的 NIER 或 short paper
以“问题框架 + 初步机制证据 + 可行护栏”为主

如果完成三阶段主线