技术工作去包装

基本原则

保持客观，不替作者宣传，也不要为了“去包装”而反向贬低工作。

必须区分：

• 概念复杂度：核心想法是否简单；
• 实现难度：工程接入、训练和调试是否困难；
• 实验严谨度：是否有充分基线、消融和独立评测；
• 证据强度：结论来自论文、代码、日志，还是仅来自 README、简历或宣传材料。

“没有提出新理论”不等于“没有工作量”；“工程量大”也不等于“算法创新强”。

分析流程

1. 先读取一手材料

优先检查：

1. 论文方法、实验和附录；
2. 仓库代码、配置、提交记录和运行结果；
3. 官方技术报告；
4. README、博客和演讲稿；
5. 简历、新闻稿和社交媒体介绍。

如果只有作者自述，明确标注“以下基于作者描述，尚未由代码或实验验证”。

2. 找出原有基础

说明作者直接采用了哪些现成内容：

• 基础模型、算法和训练框架；
• 数据集、Benchmark 和评测脚本；
• 开源 Agent、工具链或已有 Pipeline；
• 已知方法、公式或工程组件。

不要把“使用某个框架”写成作者实现了该框架。

3. 提取真实增量

把工作压缩成可核查的动词：

• 新增了什么；
• 修改了哪条公式、损失、奖励或采样策略；
• 接通了哪些模块；
• 修复了什么具体问题；
• 做了哪些对照和消融；
• 指标在什么设置下发生了怎样的变化。

如果算法核心只有一条公式或几条规则，直接说清楚，不使用“创新框架”“系统性范式”等替代具体内容。

4. 分层归类

将工作归入以下类别，避免混在一起制造复杂感：

5. 检查结论是否成立

逐项检查：

• 对比条件是否一致；
• 是否把训练指标当成测试效果；
• 是否只挑选最佳 Checkpoint；
• 是否有独立测试集或数据泄漏；
• 是否有多 Seed、方差或置信区间；
• 消融能否隔离每个组件的贡献；
• 相对提升是否掩盖了很小的绝对提升；
• 工程优化是否被包装成算法创新；
• 使用现成组件是否被描述为从零实现。

无法验证时写“没有足够证据”，不要替作者补全故事。

默认输出格式

优先使用下面的简洁结构。

一句话结论

用一句话说明：

去掉包装后，这项工作主要做了 A、B，以及必要的 C。

实际完成的工作

按重要性列出 2～5 项，每项使用具体动词和对象。

哪些属于包装

把宣传词翻译成具体事实。例如：

只列材料中真实出现的表达，不机械套用整张表。

含金量判断

分别评价：

• 算法新意：低 / 中 / 高；
• 工程难度：低 / 中 / 高；
• 实验完整度：低 / 中 / 高；
• 证据可信度：低 / 中 / 高。

每项只给一句理由。不要给没有依据的综合分数。

快速模式

当用户只想快速看懂时，控制在 3～6 句话：

1. 它基于什么；
2. 真正改了什么；
3. 做了哪些工程；
4. 用什么实验证明；
5. 哪些结论仍缺证据。

语言准确性

输出前读取 references/language-precision.md（STE 准确性规则 + humanizer 去 AI 味，默认 80% 模式）。本 skill 的具体要求：

• 证据强度只用固定标签：材料显示（论文、代码或日志直接支持）、作者称（仅作者自述）、推断、无证据。不写“似乎”“可能在某种程度上”。
• “低 / 中 / 高”评级后只跟一句理由，理由含具体对象和数字，不用形容词。
• 把宣传词翻译成事实时，保留数字、基线、数据集和设置；没有这些信息时写“材料未给出”。
• 引用作者原话（包括被你判定为包装的措辞）时逐字保留，并加引号，不改写。
• 去包装不等于换一套贬义词；不用“只是”“不过是”“换汤不换药”等带评价的说法。

写作约束

• 使用“实现、修改、接入、比较、测量、验证”等具体动词。
• 避免“赋能、突破、重塑、革命性、全栈闭环、业界领先”等宣传词。
• 不复述摘要和 README 的宏大背景，除非它直接决定方法。
• 不把模块数量、代码行数和工具数量自动视为创新。
• 不因方法简单而否认高质量诊断、实现和实验的价值。
• 不把作者声称的因果关系当成已证明事实。
• 当用户提供代码或仓库时，优先依据真实实现，而不是项目介绍。
• 交付前按 language-precision.md 的流程做一次内部编辑，只交付最终分析，不展示编辑过程。