undress git:20260817.1b6739bA

Immutable. This exact content is served forever at /api/v1/blob/3586120a002a7149.

---
name: undress
description: 去除论文、开源项目、技术博客、简历项目和产品介绍中的包装性语言，基于论文、代码、实验与原始材料，简单说明作者实际复用了什么、修改了什么、实现了什么、验证了什么。用于用户询问“这个工作到底做了什么”“是不是过度包装”“创新点本质是什么”“去掉术语重新解释”或需要审视技术工作的真实含金量时。
---

# 技术工作去包装

## 基本原则

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

必须区分：

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

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

## 分析流程

### 1. 先读取一手材料

优先检查：

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

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

### 2. 找出原有基础

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

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

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

### 3. 提取真实增量

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

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

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

### 4. 分层归类

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

| 类别 | 要回答的问题 |
|---|---|
| 算法改动 | 奖励、损失、优势、采样或模型结构具体改了什么？ |
| 工程实现 | 接入、并发、显存、部署、容错具体做了什么？ |
| 数据工作 | 数据如何收集、筛选、标注或划分？ |
| 评测工作 | 使用什么基线、指标、消融、Seed 和测试集？ |
| 最终证据 | 哪个指标相对哪个基线提高了多少？ |

### 5. 检查结论是否成立

逐项检查：

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

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

## 默认输出格式

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

### 一句话结论

用一句话说明：

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

### 实际完成的工作

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

### 哪些属于包装

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

| 包装表达 | 具体含义 |
|---|---|
| 构建端到端系统 | 接通了数据、模型、工具和评测几个阶段 |
| 提出全新框架 | 在现有框架上增加了若干模块或规则 |
| 系统性优化 | 调整了多个参数并完成若干组实验 |
| 显著提升 | 在指定数据和设置下从 X 提升到 Y |
| 自研 Agent 引擎 | 编写了 Agent Loop、状态管理和工具调用适配 |

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

### 含金量判断

分别评价：

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

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

## 快速模式

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

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

## 写作约束

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