研究提案 v6：AI-agent 工具 star 事件与 GitHub 低既有公开构建痕迹用户的公开构建激活

v6 说明：v5 已经把 measurement validity 和 threat model 提到了中心位置，这一步是对的；但如果按真正顶会 SE reviewer 的标准继续往死里挑，v5 仍然有三个致命风险：新颖性还不够硬、设计还偏重而散、论文的可发表单位还不够清晰。v6 的任务不是再补几条 threats，而是把 proposal 从“方法上更诚实的研究计划”进一步压缩成“更像一篇真的能写出来、也更容易被审稿人识别其贡献边界的论文设计”。

1. 先把 v5 当成投稿稿件来打：顶级 SE reviewer 会怎么最狠地批

如果我是 ICSE/FSE 级别、做 empirical SE 很挑的 reviewer，我会承认 v5 比前几版成熟很多，但仍然会在 novelty、feasibility、publishability 三条线上同时施压，而且每一条都足以把稿子压到 weak reject 甚至 reject。

1.1 最大问题不是“不严谨”，而是“太像一个很聪明的研究计划，而不像一篇必然能立住的论文”

v5 的问题已经不再是轻率。恰恰相反，它太知道自己哪里脆，所以不断加 threat model、加 proxy family、加 sensitivity、加标签、加降格解释。结果是：

proposal 看起来很成熟；
但论文单位开始变得发散；
审稿人会问：你到底最主要要证明什么？

如果一篇实证 SE 论文同时想完成下面这些事：

重新定义一个更合理的 public build-trace measurement family；
诊断 template-like 初始化误差；
比较 AI-agent/tool 与非 AI 工具的差异；
再单独解释 OpenClaw 这个重点案例；
还要讨论 newcomer、public trace、公开可见性偏置与 agent 时代软件启动行为；

那 reviewer 很容易觉得：

每一部分都懂一点，但没有哪一部分真的打透到可发表的“主贡献单位”。

这不是 scope 大小问题，而是 paper identity 问题。

1.2 v5 虽然修了测量，但 novelty 仍然容易被质疑成“更精细的行为代理 + 一个时髦现象”

v5 会让人感觉“更像论文”，但还不必然让人觉得“这件事非发不可”。严苛 reviewer 可能会说：

你们的核心还是在研究两类 GitHub 轻量行为之间的时间关联，只是把 outcome 从单一 proxy 改成了 PIT/FPB/SPB 三层。这个设计更细了，但新颖性到底在哪里？

更具体地说，reviewer 可能会质疑：

现象新，但结论未必新：
- 爆红工具更可能伴随更多周边尝试、模板仓库、demo repo，这是很容易预期的；
- AI-agent/tool 诱发更多公开试做，这个方向本身并不反直觉；
- 如果最后只是把这种直觉更精细地量化，novelty 不够强。
方法更细，但未必方法创新：
- PIT/FPB/SPB 是合理 operationalization；
- 但 reviewer 可能会说，这更像是 careful measurement design，而不是一个显著的新方法贡献；
- 除非你能证明传统做法在这个问题上会系统性误导，而你的分层测量能显著改变结论解释，否则“分三层”本身不够新。
OpenClaw case 既不能撑起 generality，也不一定足够独特：
- 如果 OpenClaw 只是一个高关注 AI agent 项目，那它是例子，不是 novelty 来源；
- 如果 OpenClaw 并没有在同类中表现出特殊结构，那它只能提供叙事，不提供额外发表价值。

一句话说，v5 最大的新颖性风险是： 它比旧版更严谨，但还没有充分证明“为什么这个问题值得占据一篇顶会 SE 论文的篇幅”。

1.3 v5 的 threat model 很强，但也暴露出一个 publishability 悖论：你越诚实，越像在主动削弱自己

v5 的优点是写清楚了：

template-like 初始化会膨胀结果；
共同暴露会制造假象；
public visibility bias 会扭曲解释；
LPBT 不等于 newcomer。

但 reviewer 也会因此顺势说：

既然你自己已经说明这个研究很可能最后只能落到“公开试做初始化激活”而不是“真实开发进入”，那这篇论文的最终 punchline 还剩多大？

这就是 publishability 悖论：

如果你不收缩，claim 太大；
如果你收缩得很彻底，贡献又可能显得不够“强”。

v5 目前还没有完全解决这个矛盾。它更可信了，但也更容易被问：

那你最后到底能交付一个什么级别的发现？只是说 AI 工具更容易带来公开原型化吗？这件事对 SE 社区的理论或实践价值有多大？

1.4 v5 依然高估了“类间比较”本身的可解释性

v5 试图比较 AI-agent/tool 与非 AI 开发工具项目，这是自然的。但 reviewer 仍然会问：

这两个类真的可比吗？
所谓“非 AI 开发工具”内部异质性会不会极大？
一个代码生成 agent、一个 CI 辅助工具、一个传统 CLI、一个 dev productivity 工具，它们的受众、传播方式、star 语义、下游试做方式都可能完全不同；
于是“AI vs non-AI”这个比较很容易混入太多结构性差异。

换句话说，类间比较虽然看起来 general，但实际上可能是最不稳的部分。审稿人可能会直接建议：

与其做一个广泛但异质性极高的 AI vs non-AI 对比，不如聚焦一小类功能近似、受众近似、传播机制近似的工具宇宙。

这意味着 v5 的问题不是比较不够大，而是比较单位仍然过粗。

1.5 v5 的 outcome family 虽然更合理，但执行代价太高，容易把论文拖死

PIT/FPB/SPB 的三层设计在概念上是对的，但 reviewer 也会从 feasibility 角度发难：

你需要收集多少项目？
多少 star 事件？
多少用户历史？
多少后续 repo？
多少人工标注？
多大比例要双人标注？
template-like / demo-shell / profile-facing 这些标签的边界怎么统一？

如果这一套全部真做，成本会非常高。审稿人会担心两件事：

最后只能做浅：因为太大，所以每个部分都只能做个意思；
最后只能做窄：因为做不完，所以只能选很小样本，外部效度又掉下去。

v5 还没有把“最小可发表设计”说得足够清楚。

1.6 v5 依然没有把“为什么这是 SE 问题，而不是平台行为/计算社会科学问题”说到最硬

这是一个非常关键、但很多 proposal 容易忽略的问题。

reviewer 会问：

你研究的是 GitHub star 与后续公开仓库行为的关系。这到底为什么首先是软件工程问题？

如果回答只是：

因为发生在 GitHub；
因为后续仓库有工程文件；
因为 AI 工具和开发活动有关；

那还不够。SE reviewer 真正想看的是：

这项研究能否帮助我们理解软件构建活动的启动形态在 agent 时代发生了什么变化；
它是否揭示了“公开软件项目启动”的可测结构被 agent 工具改变了；
它是否为后续研究工程质量、依赖暴露、供应链面扩张提供了可复用入口。

v5 触到了这些，但还没有把它们组织成一个足够强的 SE framing。

1.7 v5 还缺一个真正能打动 reviewer 的“反直觉点”

顶级实证论文常常不只是“把一件重要的事做严谨”，还需要一个让 reviewer 觉得值得记住的 insight。v5 目前更像：

我们知道这个现象存在；
我们担心很多误差；
我们设计得更严谨来测它。

但 reviewer 会更容易被下面这类 punchline 打动：

表面看 AI 工具带来更多“首次项目启动”，但在排除模板化后，真正增加的是某一类特定的 automation/integration 仓库，而不是一般意义上的新项目；
传统单层 proxy 会把 agent 工具的影响夸大两倍，而分层测量显示真正稳定的是短期持续构建而非初始化；
OpenClaw 并非“更强地带来更多项目”，而是“更强地带来某类结构化、自动化导向的仓库”。

也就是说，论文需要一个更锋利、也更可能让人记住的主发现模板。v5 现在还更像“研究计划”，不是“结果会很有意思的论文”。

2. v6 的核心判断：不要再继续加复杂度了，应该收缩成一个更能发表的论文单位

v6 的核心转向不是再加 threat、再加 proxy、再加 robustness，而是：

把这项工作从“一个宏大的 agent-era public trace 研究”收缩成“一篇围绕可复现测量差异与仓库类型异质性的实证 SE 论文”。

更具体地说，v6 主张把论文的真正卖点重写成：

卖点 1：不是简单证明“AI 工具更带来首次构建”，而是证明

若不区分初始化痕迹与持续构建痕迹，会系统性高估 AI-agent/tool 项目 star 事件与后续公开构建启动的关系。

这一下，measurement design 不再只是防守，而变成主贡献的一部分。

卖点 2：不是泛泛比较 AI vs non-AI，而是说明

这种高估主要来自 template-like/demo-shell 初始化，以及特定仓库类型（automation / integration / agent wrapper）的集中增长。

这一下，结果就从“AI 工具很火，很多人跟着试”变成了更像 SE insight 的东西：

agent 工具改变了什么类型的公开软件构建更容易被启动；
传统 proxy 为什么会看错；
哪些仓库类型才是真正增长的主体。

卖点 3：OpenClaw 不再承担 generality，而承担“可解释案例”

OpenClaw 的角色是：

用于展示一个高关注 agent 项目在上述结构中的位置；
检验它是“普遍 AI 工具模式的一例”，还是“在某类 automation/integration 产出上更强”；
不是论文成立的前提。

这样，整篇论文的 identity 会清楚很多： 它是一篇关于 agent 时代 GitHub 公开构建痕迹测量偏差与结果异质性的实证 SE 论文，而不是一篇围绕 OpenClaw 的平台现象观察。

3. v6 的主问题重写：从“大而散”改成“能交付明确主发现”

RQ1：测量差异问题

在开发工具项目的 star 事件研究中，传统单层“首次公开构建”代理是否会系统性高估 AI-agent/tool 项目与后续公开构建激活之间的关系？

这其实是全文最核心的问题。

它让论文的第一主贡献变得很清楚：

不是单纯发现相关性；
而是揭示一种在 agent 时代更严重的 measurement distortion。

RQ2：异质性问题

这种高估主要来自哪些后续仓库类型与哪些初始化模式？尤其是 template-like、demo-shell、automation/integration/agent-wrapper 等类型是否构成了主要来源？

这让第二主贡献也更清楚：

不是只报告 effect size；
而是解释 effect size 是由什么构成的。

RQ3：OpenClaw 的位置问题

在 AI-agent/tool 项目内部，OpenClaw 在上述测量差异与仓库类型结构上处于什么位置？它更像一般模式，还是某一类产出结构更突出的案例？

这样写后，OpenClaw 的 case 分析既合理，又不会喧宾夺主。

4. v6 的研究对象进一步收缩：不要做泛化过强的“AI vs non-AI”，而做“可比工具宇宙”

v6 不建议继续维持一个很宽的“AI-agent/tool vs 非 AI 开发工具”大类对比。更稳妥的做法是构建一个 功能上相对接近、受众上相对接近、都直接面向软件构建/编码工作流的项目宇宙。

4.1 项目宇宙建议

纳入对象优先为：

coding assistant / agent runtime / coding CLI；
developer workflow automation tool；
repository/project bootstrap tool；
与代码生成、项目初始化、自动化集成直接相关的开发工具。

尽量避免纳入过宽的：

一般 DevOps 平台；
纯 CI/CD 服务；
与编码启动关系很弱的 productivity tool；
受众完全不同的传统基础设施项目。

4.2 为什么这个收缩更好

因为它能明显降低 reviewer 对 comparator validity 的质疑：

比较对象更像“同一生态位的竞争或邻近工具”；
star 语义更接近；
用户群体更接近；
后续仓库类型也更具有可比性。

与其追求表面 generality，不如追求 更强的类内可解释性。

5. v6 的 outcome 进一步简化：保留三层逻辑，但把论文主分析压到两层

v5 的 PIT/FPB/SPB 很完整，但为了可执行与可发表，v6 建议把实际论文主分析压缩为两层，第三层作为稳健性或补充结果。

O1：Initialization-level Public Build Trace（IPBT）

定义为：

在 star 后窗口内创建新的公开非 fork repo；
包含至少一种明显工程化初始化痕迹：README、依赖/构建配置、源码目录、工作流文件、脚手架结构等；
排除纯 profile repo、纯链接 repo、明显空壳。

它测的是： 公开工程化启动痕迹出现了。

O2：Sustained Public Build Trace（SPBT）

在 O1 基础上进一步要求：

至少跨两个日期的提交活动；
或 14/30 天内出现文件扩张、源代码扩张、功能性 README 更新、依赖/工作流演进等持续性信号；
排除明显一次性模板灌入后无后续扩展的仓库。

它测的是： 不仅初始化了，而且出现了至少短期持续的公开构建行为。

O3：Template-like 标签作为横向主轴，而不是第三个 outcome

与 v5 不同，v6 更建议把 template-like / demo-shell / scaffold-heavy 作为贯穿 O1/O2 的主解释维度，而不是再把论文主线拆成三个 outcome。

原因很简单：

reviewer 需要的是清楚的主故事；
O1 与 O2 足够形成“初始化 vs 持续”主对比；
template-like 标签正好解释两者差异来源；
这比 O1/O2/O3 三层并列更紧凑。

6. v6 的真正方法贡献：不是“我们定义了更多 proxy”，而是“我们证明单层 proxy 会在 agent 时代系统偏”

这是 v6 与 v5 最大的写法差异。

v5 比较像：

我们有一套更细的分层测量框架；
所以我们更谨慎地研究这个问题。

v6 则应该写成：

我们证明，在 agent/tool 项目语境下，若使用单层首次公开构建代理，研究者会系统性把模板化初始化与短期试做误读成更强的构建启动关联；只有区分 initialization-level 与 sustained-level public build trace，并显式识别 template-like 仓库，结果解释才稳。

这样一来：

measurement 不再是辅助性的；
它成为论文的主发现发生器；
这才更像可以投稿的 empirical SE contribution。

7. v6 的数据与标注设计：追求“最小可发表闭环”，不要贪大全

7.1 最小可发表样本单位

v6 建议不要追求“尽可能大”，而要追求“足够形成可信比较且能完成高质量标注”。

一个更现实的设计是：

选择一个明确的项目宇宙；
只纳入其中 star 事件量足够、且有持续观察窗口的项目；
对 star 用户只保留 LPBT 用户；
对其后续新公开 repo 进行规则识别与分层标注。

核心原则： 宁可项目少一点、标注深一点，也不要项目铺太大、最后只得到粗糙结果。

7.2 LPBT 定义继续保留，但彻底去 newcomer 化

继续用 LPBT（low prior public build trace）是对的，但 v6 建议把它写得更功能性：

LPBT 不是为了识别“真正的新开发者”，而是为了识别“在 GitHub 公共面上几乎没有既有公开构建痕迹、因此更适合观察后续公开构建激活”的用户子群。

这会让 LPBT 从一个容易被攻击的“人群构念”，变成一个更像 observation design 的 sampling rule。

7.3 标注问题要比标签更重要

标注不应该只是“这个 repo 算不算 FPB/SPB”。v6 建议围绕三类问题组织标注：

它是否只是模板化/展示性初始化？
它是否出现了短期持续构建？
它属于哪类后续仓库类型？
- automation
- integration
- agent wrapper
- app
- library
- tutorial/demo
- profile-facing / showcase
- other

如果资源有限，优先保证：

O1/O2 判定一致性；
template-like 标签一致性；
仓库类型粗分类一致性。

这三者已经足够支撑主线。

8. v6 的分析框架：把主结果做得锋利，不要把所有问题压进一个模型

8.1 第一步：先证明单层 proxy 会夸大结果

先定义一个 reviewer 最容易想象的传统单层 proxy，例如：

star 后 90 天内出现新的公开非 fork 工程化 repo。

然后比较：

单层 proxy 下的结果；
O1（初始化层）结果；
O2（持续层）结果；
排除 template-like 后的 O1/O2 结果。

如果出现以下模式，论文就有 punchline 了：

单层 proxy 显著最高；
O1 次之；
O2 更低但更稳；
排除 template-like 后，AI 组相对优势明显收缩；
收缩主要集中在 demo-shell / template-heavy 样本。

这会直接支持论文主张： agent 时代的传统单层 proxy 会系统性夸大“构建启动”关联。

8.2 第二步：再解释差异来自什么仓库类型

然后报告后续仓库的类型分布：

AI-agent/tool 项目关联增长是否主要集中在 automation / integration / agent-wrapper；
非 AI 可比工具项目是否更多分布在其他类型；
OpenClaw 的结构是否特别偏向某几类。

这一层是 SE 含义真正变强的地方。因为它回答的不是“有没有更多 repo”，而是：

启动的是什么类型的公开软件构建。

8.3 第三步：最后才上控制模型

主模型只需要回答一个很清楚的问题：

在控制项目热度、时间窗口、用户公开历史稀薄程度等因素后，AI-agent/tool 项目与 O1/O2 的关联是否仍更高；
以及这种差异在加入 template-like 控制或分层后如何变化。

也就是说，模型服务于主故事，而不是反过来用复杂模型替代主故事。

9. v6 的可发表主发现模板：现在终于像一篇论文了

如果数据支持，v6 最理想的结果表达不是笼统的“AI 工具更强”，而是下面这种更锋利的组合：

发现 F1：传统单层首次公开构建代理会系统性高估 AI-agent/tool 项目 star 事件与后续构建启动的关系

这说明 agent 时代的 public trace 研究不能再偷懒用单层 proxy。

发现 F2：这种高估主要来自 template-like / demo-shell 初始化，而不是等比例转化为持续公开构建

这让论文从平台行为观察，变成对测量偏差与解释边界的 SE 贡献。

发现 F3：即便在更严格的持续构建层面，AI-agent/tool 项目仍可能对某些特定类型仓库表现出更强关联，尤其是 automation / integration / agent-wrapper

这让论文不是“全被打回零”，而是得到一个更具体、更有工程含义的发现。

发现 F4：OpenClaw 在 AI-agent/tool 项目中的特殊性，如果存在，应体现为某类后续仓库结构，而不只是总体数量更高

这会让 OpenClaw case 有解释价值，而不是只做流量叙事。

这四条放在一起，已经比 v5 更接近可投稿论文的结果预期了。

10. v6 的 SE framing：明确回答“这为什么是软件工程研究”

v6 必须更明确地把贡献锚定到软件工程，而不是只停在 GitHub 平台行为。

10.1 因为研究对象不是任意平台行为，而是公开软件构建痕迹的启动与持续

我们关心的不是一般互动，而是：

新 repo 的工程化初始化；
代码/配置/工作流/依赖文件的出现；
短期持续构建是否发生；
不同类型软件产物的启动结构。

这本质上是在研究 public software construction traces。

10.2 因为 agent 工具改变的不是“大家更活跃了”这么简单，而是“什么样的软件构建更容易被启动并公开”

如果结果显示增长主要集中在 automation / integration / agent-wrapper，而不是一般 app/library，那么论文就在回答一个 SE 问题：

agent 工具是否改变了公开软件构建的产物结构与启动门槛？

10.3 因为这项工作能为后续工程质量、维护性与供应链暴露研究提供入口

如果我们能更可靠地区分：

只是模板化初始化的仓库；
真正进入短期持续构建的仓库；
以及它们属于哪些类型；

那么后续就能继续研究：

这些仓库的依赖结构是否更脆弱；
自动化集成仓库是否更早接入高权限 token / CI / 外部 API；
agent 诱发的公开构建是否有不同的演化速度与缺陷模式。

这才是与软件工程、开源生态和供应链安全真正接上的地方。

11. v6 的失败条件：这次要写得更像真的愿意被证伪

11.1 如果单层 proxy、O1、O2、去 template-like 后的结果几乎没有差别

那就说明“measurement distortion”这个主贡献站不住。论文的亮点会显著下降。

11.2 如果 AI-agent/tool 与可比非 AI 工具在 O2 上完全没有稳定差异，且所有差异都集中在 template-like O1

那论文仍可成立，但结论必须明确降格为：

这些项目更强地关联到公开试做/初始化，而不是持续公开构建。

11.3 如果后续仓库类型分布没有明显结构差异

那论文就失去一个关键的 SE insight，只剩“多了一些 repo”。这会大幅降低 publishability。

11.4 如果 OpenClaw 在 AI-agent/tool 内部并不特殊

那就把它写成普通案例，不要硬抬。论文主体仍应成立。

这一步很重要： v6 的价值不依赖 OpenClaw 必须赢，而依赖测量差异与结果异质性是否真实存在。

12. v6 的贡献，终于收缩成能 defend 的三点

C1. 测量贡献

提出并实证验证：在 agent/tool 项目语境下，单层首次公开构建代理会系统性高估后续公开构建启动关联；区分 initialization-level 与 sustained-level public build trace，并显式识别 template-like 仓库，是更稳健的测量方案。

C2. 实证贡献

在一个功能可比的开发工具项目宇宙中，比较 AI-agent/tool 与非 AI 可比工具项目的 star 事件与后续公开构建激活之间的关联，并揭示差异主要由哪些初始化模式与仓库类型构成。

C3. 案例贡献

将 OpenClaw 作为重点案例，分析其在 AI-agent/tool 项目内部的相对位置，以及其关联后续仓库是否更偏 automation、integration、agent-wrapper 等结构性类型。

这三点比 v5 更少，但更像真正能投稿的贡献组合。

13. v6 推荐论文结构

13.1 引言

agent 时代，爆红开发工具常伴随后续公开 repo 增长；
但传统单层 proxy 可能把模板化初始化误读为构建启动；
本文的核心不是再证明“有增长”，而是说明 如何不被这种增长骗到；
OpenClaw 是重点案例，不是研究前提。

13.2 背景与威胁模型

star 只是 project-contact signal；
template-like 初始化、共同热潮、公开可见性偏置、LPBT 构念边界；
其中 template-like distortion 是本文最核心要解决的问题。

13.3 研究设计

项目宇宙；
LPBT 采样；
O1/O2 定义；
template-like 与仓库类型标签；
标注协议。

13.4 结果一：单层 proxy 如何夸大 AI 工具效应

传统单层 proxy vs O1 vs O2；
去 template-like 前后差异。

13.5 结果二：差异来自哪些仓库类型

automation / integration / agent-wrapper / app / library / demo 等分布；
哪些类型真正贡献了增长。

13.6 结果三：OpenClaw 案例

OpenClaw 在 AI-agent/tool 内部的位置；
是否结构上更偏某类仓库。

13.7 讨论

agent 时代公开软件构建痕迹的变化；
对 SE4AI、开源生态、供应链暴露研究的启示；
我们测到的是什么，没测到什么。

14. 我对 v6 的最终判断

如果说：

v4 的进步，是把问题从 OpenClaw 单 case 拉回到项目宇宙；
v5 的进步，是把 measurement validity 与 threat model 放到台前；

那么 v6 真正完成的，是最后一步：

把这项工作从“一个越来越谨慎的研究设想”，压缩成“一个有明确主发现模板、明确 SE 贡献、明确最小可发表闭环的实证论文设计”。

v6 最关键的变化有四个。

第一，主问题终于锋利了

不再是泛泛问“AI-agent/tool 是否更关联后续构建启动”，而是问： 传统单层 proxy 是否系统性夸大这种关系。

这是一个更像论文、也更容易被 reviewer 记住的问题。

第二，measurement 不再只是防守，而变成论文的主贡献来源

v5 还更像“为了谨慎所以分层”； v6 则明确主张： 如果不分层，你会得出偏的结论。

这就是更强的方法与实证结合点。

第三，结果异质性终于承接住了 SE 意义

真正重要的不是“多了多少 repo”，而是：

多出来的是初始化还是持续构建；
多出来的是 demo-shell，还是 automation / integration / agent-wrapper；
这如何改变我们对 agent 时代公开软件构建启动的理解。

第四，OpenClaw 被放到了正确位置

它是一个有价值的重点案例，但不是论文必须依赖的中心支点。这样更安全，也更可信。

所以，如果以“这版能不能作为本轮 1 小时内的最终稿”来判断，我的结论是：

v6 比 v5 更像一篇真的能往 ICSE/FSE 风格实证 SE 论文方向推进的 proposal。它没有再追求更大，而是开始追求更准：更准地定义主问题、更准地设计最小闭环、更准地把 novelty 锚定在‘agent 时代单层 public-build proxy 会系统性误导’这一点上。

15. v6 标题候选

标题 A

研究提案 v6：AI-agent 工具 star 事件会被传统首次公开构建代理高估吗？——以 OpenClaw 为重点案例

标题 B

研究提案 v6：agent 时代 GitHub 公开构建激活的测量偏差——AI-agent 工具、template-like 初始化与 OpenClaw 案例

标题 C

研究提案 v6：从模板化初始化到持续公开构建——重写 OpenClaw 相关 GitHub star cohort 研究设计

如果偏论文味，我更推荐 标题 B；如果要延续当前报告脉络，我会选 标题 C。

16. 一句话结论

v6 最重要的改进，不是把 threat model 继续写得更满，而是把整篇 proposal 的可发表核心压缩出来：在 agent 时代，如果研究者仍用单层“首次公开构建”代理，就会系统性高估 AI-agent/tool 项目与后续公开构建启动的关系；更可信的做法，是区分初始化层与持续层公开构建痕迹，并直接解释差异究竟来自模板化试做，还是来自特定类型的软件构建真正被启动。

这是第 6 版 proposal。相较 v5，v6 的核心改动不是再扩 threat model，而是进一步收缩论文单位：把 novelty 锚定到“单层首次公开构建代理在 agent/tool 语境下会系统性高估效应”这一可检验主张，把结果变量从三层主线压缩为“初始化层 vs 持续层”两层主分析，并将 template-like 初始化与后续仓库类型异质性提升为真正承接软件工程意义的解释主轴。OpenClaw 继续保留为重点案例，但不再承担研究成立所需的 generality。