NoteRx 源码审计报告

本报告发布后，项目方及相关人员已作出回应。如需了解其完整说辞，可前往本仓库 Issues 页面查看被 Pin 的 Issue。在七条附有文件名与行号的具体代码指控面前，其回应是否触碰了任何一条技术事实，亦或是只用于转移视线的公关稿，读者一览即知。

本版相较原版仅调整了各节的呈现顺序，以将最核心的造假证据置于最前，防止断章取义。所有审计分析点、引用代码行号及结论措辞均与原版完全一致，内容未作任何增删或修改。

本报告基于对 jiangmuran/noterx 仓库的完整源码审计，原始 Issue 已被该团队连续删除两次且从未作出任何回复。

为防止证据被彻底毁灭，原 Issue 已同步存证至 Internet Archive，且该仓库当前版本已完成 Fork 备份。

互联网是有记忆的。

---

摘要

本次黑客松的作品呈现出极大的跨度：既有扎实深耕的技术底座，也不乏极具"表演性"的叙事案例。而 noterx 则是其中的集大成者：它集齐了所有能打动评委的标签（13岁、多智能体、深度数据分析），却在核心业务逻辑上完全违背了自媒体运营的常识。更关键的是，其最核心的技术卖点——多 Agent 辩论——经源码审计证实对最终输出贡献为零，是一个专为演示设计的空壳。本文基于源码审计逐条展开。

---

目录

1. 本项目最核心的谎言："多轮 Agent 辩论"从未真正发生过
2. 工程数值造假：Model A 的评分只是参数锁死后的"魔数"
3. 白皮书数据与代码实现的全面脱节：用噱头干扰评委与用户判断
4. 统计学逻辑谬误：用"均值"指导"爆款"是十年前就被否决的死路
5. 内容生态的污染：公式化模板是流量毒药
6. 仗着年龄的技术作秀：工程逻辑断层与叙事套利
7. 结论
8. 提问

---

1. 本项目最核心的谎言："多轮 Agent 辩论"从未真正发生过

这是整个项目最严重的结构性欺骗，也是评委最容易被蒙蔽的地方。NoteRx 的核心卖点——多 Agent 多轮辩论后由裁判综合得出最终诊断——在代码层面是一个从未运行过的空壳。

辩论的形式是假的。 orchestrator.py 第 422-498 行的 _run_debate 方法揭示了"辩论"的真实面目：4 个 Agent 收到其他三人的 Round 1 结果快照后，通过 asyncio.create_task 同时启动，各说各的。没有一个 Agent 能看到其他人在"辩论轮"中说了什么，没有追问，没有反驳，没有基于对方论点的动态调整。这不是辩论，这是四份互不知情的书面意见同时提交。前端播放的那段"专家激烈交锋"动画，对应的是四个完全隔离的 LLM 调用。

辩论的结果是无效的。 这是最致命的证据。orchestrator.py 第 385 行：

await asyncio.gather(_debate_task(), _judge_task())

辩论（_debate_task）与裁判（_judge_task）并行启动。裁判不等辩论完成，直接开始工作。因此在第 360-364 行调用最终裁判时：

judge.diagnose(
    title=title, category=category,
    agent_opinions=agent_opinions, debate_records=None,
)

debate_records 传入的是硬编码的 None。裁判拿到的输入与辩论是否发生、辩论说了什么，完全无关。即便删掉整个辩论模块，最终诊断报告的内容一个字也不会改变。

这是一场为前端动画设计的剧场表演。用户在"诊断中"页面看到的专家依次发言、互相点评的进度流，是 SSE 事件驱动的 UI 效果，与后端实际的算法逻辑之间存在根本性的语义断裂。项目用"多 Agent 辩论"作为最核心的技术亮点向评委展示，但这个亮点在代码中是一个对最终结果毫无影响的装饰性模块。

---

2. 工程数值造假：Model A 的评分只是参数锁死后的"魔数"

所谓的"量化预测引擎"（见 orchestrator.py）根本不是什么 AI 预测，而是人工硬编码的魔数（Magic Numbers）：

• 数值欺诈与深度脱节：在 orchestrator.py 第 60-95 行，代码硬编码了大量权重：overall_score = model_a_overall * 0.4 + raw_overall * 0.6。视觉分逻辑甚至直接写死 text_balance = max(0.0, 100.0 - abs(text_ratio - 0.22) * 260.0)。对研究报告及全部研究脚本执行全文检索，0.22、260.0、0.4、0.6 均无任何出处——研究报告从未分析过封面文字占比（text_ratio）这个维度，Track A 的分析对象是标题长度、标签数、图片张数，完全没有触及图片内文字比例；报告中的权重体系是五维度分权重（如美食品类标题质量 57.3%），与这里的 0.4/0.6 混合权重毫无关联。这四个数字是在研究体系之外单独拍脑袋写入代码的，与任何数据分析结论均无对应关系。

• 研究成果的"虚假陈列"：极其讽刺的是，项目在报告 final_research_report.md 中大谈特谈 $\beta=0.71, \beta=0.52$ 等核心系数。然而代码审计发现：

  • 所有 β 系数（β=0.71、β=0.41、β=0.28、β=−0.51、β=0.24、β=0.16 等）：对整个代码仓库执行全文搜索，上述数值在任何 Python 文件中均不存在。它们只出现在研究报告 final_research_report.md 的文案中，既未存入任何数据结构，也未参与任何运行时计算。
  • $\beta=0.52$：是唯一在代码中出现的 β 值，但仅作为字符串片段嵌入 research_data.py 第 277 行的 Prompt 模板中（f"{'（旅游品类标签是最强预测因子β=0.52）' if category == 'travel' else ''}"），功能是向 LLM 描述背景信息，从未进入任何数值计算公式。
  • $R^2=0.106, 0.177$ 等及 Spearman r=0.484、0.181 等：r_squared 字段定义在 noterx_scoring_model.py 的 MODEL_PARAMS 数据结构中（第 44、62 行等），仅被 show_params() 第 302-303 行读取用于 CLI 打印展示。核心评分函数 score_note()（第 179-286 行）对 r_squared 字段零引用，完全不影响任何评分输出。Spearman r 验证数据（r=0.484 等）仅存在于离线研究脚本 10_validate_model.py 的输出 JSON 中，从未被 backend 任何模块加载或使用。

• 结论：这种"宣发数据用一套，代码实现用另一套"的做法，证实了其所谓的数据驱动本质上只是为了演示效果而进行的数值拼凑，实际运行依然依赖 0.4、0.6、0.22 这种拍脑袋得出的数字。

• 荒谬的确定性：你们在 Issue 中提到无法固定模型输出，于是采取了在 app/agents/base_agent.py 中将 temperature 调为 0 并固定 seed 的方式（第 241-246 行："temperature": float(os.getenv("LLM_TEMPERATURE", "0"))，kwargs["seed"] = int(seed_val)）。这在创意领域是极其荒谬的。这种做法只是为了在 UI 上给用户展示一个"看似稳定、权威"的雷达图，本质上是一种 UX 欺诈。

---

3. 白皮书数据与代码实现的全面脱节：用噱头干扰评委与用户判断

贵团队在展示材料（KEY FINDINGS / FUN FACTS）中列出了一系列看似精确、令人印象深刻的数据发现。对这些数字逐一执行全仓库代码检索，结果如下：

以下数值在整个代码仓库中完全不存在，既未进入任何评分公式，也未作为任何逻辑参数，仅出现于展示材料：

展示数据	代码中的实际状态
科技赛道头部是均值的 24.4 倍	全仓库不存在，不影响任何计算
最火评论 39,000 赞	全仓库不存在，不影响任何计算
互动冠军 270,670	数值不存在，对应标题虽收录在 few-shot 示例中，但互动量本身对评分毫无作用
空标题笔记 55,637 互动	全仓库不存在
17:00 vs 凌晨 3 点差距 5,658 倍	全仓库不存在
科技品类负面评论 27.2%，穿搭 8.5%	全仓库不存在，research_data.py 第 288 行仅有"质疑型占 17%"，与展示材料均不对应
美食赛道中等长度互动 49,724	全仓库不存在

以下研究发现出现在展示材料中，但在代码落地时被错误实现或完全忽略：

• "17:00 是黄金发布时段"：这个数字确实作为字符串注入了 Growth Agent 的 prompt（research_data.py 第 280 行、growth_agent.py 第 22、38 行）。但 NoteRx 的输入接口只接受标题、正文、图片和标签，根本不存在"发布时间"这个输入字段。这个所谓核心发现在产品中既无法被诊断，也无法被定制化建议，只能让 LLM 对所有用户一律输出"建议 17:00 发布"这句废话。

这种做法的本质是：用无法落地的研究数字堆砌"数据驱动"的外观，以精确的小数点和倍数制造专业感，从而干扰评委对产品真实能力的判断，同时误导用户高估工具的实际价值。 这不是研究成果转化不足的问题，而是展示材料与产品实现之间存在系统性、主动性的脱节。

---

4. 统计学逻辑谬误：用"均值"指导"爆款"是十年前就被否决的死路

在阅读了 scripts/research/03_traditional_analysis.py 后，我发现该项目的底层逻辑存在严重的统计学误区：

• 逻辑缺陷：项目试图通过 Spearman 相关性分析和均值计算（如"爆款标题平均 18.3 字"）来指导创作。

• 源码支撑：在 03_traditional_analysis.py 第 55-80 行，系统通过 mean/median 来勾勒"爆款画像"。研究脚本虽然同时计算了 std、p25、p75、p90 等分位数，但这些数据在进入产品时被全部丢弃——最终写入 MODEL_PARAMS 的只有 viral_avg（如 research_data.py 第 77 行 "viral_avg": 18.3）。这个均值随后在 build_data_prompt_for_agent 第 257 行被直接注入进 LLM 的 prompt：f"爆款平均{p['title_length']['viral_avg']}字"，成为 AI 给创作者提建议时的核心参考依据。信息在"研究脚本→产品实现"的流转中发生了单向降维，保留了最粗糙的那个统计量，并将其作为"数据驱动"的旗帜递给 LLM。

• 事实真相：流量分布是典型的幂律分布（离群点驱动），而非正态分布。幂律分布下，均值被少数超级爆款严重拉高，远高于绝大多数笔记所能达到的水平，用这个数字定义"最优区间"在统计上是根本性错误的。爆款之所以成为爆款，往往是因为其打破了常规的视觉冲击或情绪共鸣。

• 实战结论：这种试图通过结构化特征破解流量密码的尝试，早在十余年前就被无数 MCN 公司证明是彻底失败的。我们需要的是真实的 A/B Test，而非由过时的数据分析堆砌而成的伪科学。

---

5. 内容生态的污染：公式化模板是流量毒药

从 content_agent.py 的示例来看，生成的建议简直是自媒体运营的反面教材：

• 审美灾难：源码提示词（backend/app/agents/prompts/content_agent.py）第 37 行以"5分钟搞定！"作为示例，第 45-50 行列出各品类"公式"（如"数字+食物名+情感词"）。这类措辞在业内早已是AI 味泛滥的代名词，是专业运营者日常规避的反例清单。

• 荒谬至极的宣传素材：更令人瞠目的是，贵团队在社媒宣传中将 NoteRx 的实际产出作为"优化效果"进行展示，其中赫然出现"家人们谁懂啊"、"答应我一定要去"等短语。这些措辞是小红书运营圈公认的**"小红书八股文"**——格式一眼可辨，内容完全可以预测，没有任何真实观众会对此产生点击欲望。用户在信息流中扫过这类标题的时间极短，点击率的崩塌是必然结果，而非偶发。专业运营者将这类措辞视为账号 AI 化的典型特征而刻意规避。一个声称能提升笔记质量的诊断工具，拿来做产品宣传的案例恰恰是业界反面教材——这不是讽刺，这是产品能力的直接证明。

• 算法反噬：试图通过改写文案让一个本身内容没热度的笔记火起来是不现实的。相反，改写只会让 AI 率上涨、模板度增加，从而更容易被小红书算法识别并压制（限流）。这不仅无效，更是对小红书数据流的一种恶意污染。

---

6. 仗着年龄的技术作秀：工程逻辑断层与叙事套利

虽然"13 岁初中生团队"是一个极佳的叙事标签，但它不应成为"技术作秀"的遮羞布：

• 工程堆砌与套利：项目堆砌了 Multi-Agent、PCA、SSE 等名词，但在解决核心痛点上表现为零。其全流程高度依赖 AI 自动化编程工具生成代码，却刻意隐瞒参与度，利用信息差进行"技术收割"。

• 数据来源的巨大讽刺：源码 scripts/research/01_import_data.py 揭示了项目底层依赖于大规模自动化采集。从 data/原始数据/ 目录下的文件名（如 【社媒助手】笔记数据-20260408-2013.xlsx）可以清晰断定，该项目并非手动整理数据，而是直接利用第三方爬虫工具 "社媒助手" 获取了数千条结构化数据。在一个由小红书官方主办的黑客松中，利用自动化采集工具获取该平台数据，并产出大量模板化内容来污染平台生态，这本身具有极强的讽刺性。

• 评价异化：你们精准捕捉到了黑客松对噱头和宣传需求的渴望，把评委哄得团团转。但无论技术架构如何，这种产出模板化内容的工具，注定无法被真实的创作者接受。

• 年龄不是借口：需要明确指出的是，对本项目的技术批评与参赛者的年龄无关。黑客松是一个公开竞技的舞台，所有选手理应在同一标准下公平竞争，评委也理应以同一尺度审视每一个项目。"13 岁"可以是令人钦佩的加分项，但它不能成为掩盖数据造假、逻辑空洞与技术夸大的豁免权。若因年龄而降低审查标准，对其他诚实参赛的团队而言，本身就是一种不公平。

---

结论

NoteRx 是一个制作精美的**"技术盆景"。它展现了极强的工程堆砌与概念还原能力，但在内容增长逻辑与技术诚信**上完全不及格。

• 技术层面的"空壳"：其宣称的"多 Agent 辩论"与"β 系数预测引擎"在代码层面被证实为纯粹的剧场表演。裁判逻辑与辩论过程的并行解耦、关键研究数据的代码真空，勾勒出了一个典型的"宣发驱动型"项目——为了打动评委，不惜在核心算法逻辑上进行系统性造假。

• 增长层面的"毒药"：它通过误导性的统计学均值，诱导创作者走向"小红书八股文"的死胡同。这种对模板化内容的推崇，不仅无助于流量爆发，反而会因极高的 AI 特征重合度触发平台风控，彻底毁掉使用者的账号权重。

• 叙事层面的"割裂"：项目一边利用第三方工具采集平台数据，一边产出污染平台生态的模板内容，最后包装在"13 岁天才少年"的叙事外壳下进行技术作秀。

其最核心的欺骗在于：项目用来打动评委的"多轮 Agent 辩论"功能，在代码中对最终输出贡献恰好为零。 这不是 bug，这是设计。

若赛后主办方对本项目进行源码审计，以下事实将被逐一坐实：研究报告中列出的所有 β 回归系数从未存在于任何可运行代码之中；judge.diagnose 在辩论完成之前已以 debate_records=None 完成调用；核心评分权重 0.4、0.6、0.22 均为无实证依据的硬编码魔数；底层数据全部来源于第三方自动化采集工具"社媒助手"。上述任意一条，单独拿出来都足以质疑该项目"数据驱动"的合法性。

---

提问

1. 你们是否能提供任何真实的 A/B 测试数据（而非模拟评分），证明经过 NoteRx 优化后的笔记在真实流量池中的表现优于原始笔记？
2. 既然标榜为"数据驱动"，为何在核心评分逻辑中大量使用 0.22、0.4、0.6 这种未经实证且与研究报告完全脱节的硬编码魔数？研究报告中列出的所有 β 系数，为何在任何 Python 源文件中均无对应的数值计算？
3. 源码中 judge.diagnose 明确传入 debate_records=None，辩论与裁判并行运行，请直接回答：辩论模块的输出对最终诊断报告有任何影响吗？如果有，体现在哪一行代码？
4. 贵团队在社媒宣传中展示了"家人们谁懂啊"等文案作为 NoteRx 的优化产出。这类措辞是小红书运营圈公认的 AI 滥用与公式化模板特征，会显著提升账号被限流的概率。请问这是贵产品认可的输出标准吗？
5. 面对"社媒助手"这种自动化采集手段，你们如何自证其在官方比赛中的合规性及对平台生态的尊重？

---

如果项目团队从一开始就没有打算将白皮书和研究报告中那些核心分析成果（β 回归系数、Spearman 相关性、多维度分位数统计、真正的多轮 Agent 辩论等）真正落地到生产后端，那么 NoteRx 本质上就只是一个专为路演和评委设计的 PPT 产品。

它通过精心堆砌的 buzzwords、流畅的动画效果和动人的年龄叙事，明显地消耗了评委的注意力，把大量本该用于审视仓库代码的真实技术价值的评审时间，引导到了一个华丽的表演上。

请不要用"时间有限、黑客松只有48小时无法完全实现"来辩解。这些核心逻辑完全可以在演示时向评委和后续使用者诚实说明——例如明确告知"Model A 为简化版硬编码评分""辩论模块为并行模拟而非真实多轮交互""部分研究结论尚未落地"等。而不是在获奖后，依然维持原有的高调宣传口径，继续用这套名不副实的代码配合媒体进行大规模炒作。

剥去所有这些高大上的技术叙事、雷达图动画、多 Agent 剧场效果和"13 岁团队"的人设加持，它剩下的、实际实现的核心功能，不过就是一个最普通的套壳 LLM：用几个来源不明的硬编码魔数打分，再并行调用几次 LLM，用不同 system prompt 各说各话，最后直接综合输出。

用这样一套与研究报告严重脱节、充满表演成分的技术实现，却坚持用原有宣传口径进行后续推广，这已经远远超出了"学生作品快速原型"的范畴，而是有意识地用虚假的技术叙事消耗评委注意力、收割关注度的行为。

我们也希望主办方不要过于注重"AI 原住民"的年龄叙事，忽视对项目实际技术实现和宣传真实性的审查。年龄可以是加分项，但绝不应成为降低技术标准的理由，更不能成为掩盖宣传与实现严重脱节的保护伞。