| name | paper-to-production |
| description | 把学术论文里的方法/算法落地到工业级场景，产出可行性评估、技术方案和 Gap 分析。当用户提供一篇论文 + 一个工业场景，问"这篇论文怎么落地"、"能不能用在我这个场景"、"怎么工程化"时使用。触发词："论文落地"、"这篇论文怎么用在"、"paper to production"、"工程化这篇论文"、"工业级复现"、"评估下这篇论文能不能落地"。纯离线分析，不联网。 |
把一篇论文的方法，分析清楚如何落地到用户给出的工业级场景。区别于"忠实复现论文实验"——本 skill 关注的是工业约束：可行性、性能、成本、数据、集成、监控、降级、风险。
触发条件
用户同时给出（或能推断出）一篇论文和一个工业场景，想判断前者能否/如何落地到后者。例如：
- "这篇 [论文] 怎么用在我这个 [推荐召回] 场景？"
- "评估下 [某算法论文] 能不能落地到我们的 [实时风控]"
- "帮我把 [论文 PDF] 的方法工程化到 [具体业务]"
核心原则
- 论文不是圣经：论文的假设、数据集、指标都和真实工业场景有 gap。skill 的价值就是找出这些 gap。
- 工业优先，不是复现优先：不要追求 1:1 复刻论文实验，要回答"这个方法在我这个场景、我的数据、我的约束下，值不值得做、怎么做"。
- 具体场景具体分析：不套空泛模板。每一项结论都要落到用户的真实约束上（吞吐量级、延迟要求、数据规模、现有栈、团队能力）。
- 诚实标注不确定性：分析中无法从论文文本确证的工业指标（如真实 QPS 下的延迟），明确标注"需实测/需 PoC 验证"，不编造数字。
执行流程
Step 1: 确认输入完整性（只问一次）
检查是否同时具备两要素。只问缺失的，已有的不重复确认：
📋 落地分析参数确认
论文: {标题/路径/arXiv ID}
场景: {工业场景一句话描述}
场景约束（如有）: {吞吐/延迟/数据规模/现有技术栈/团队规模}
交付: 三件套 — 落地评估报告 + 技术方案文档 + Gap 分析清单 [默认]
有补充或要调整吗？没问题就直接开始。
输入识别规则：
- 论文：用户给了 PDF 路径、arXiv ID、论文标题，或指向 inbox/archive 里的论文文件 → 读全文
- 场景：用户用自然语言描述了业务问题 → 原样保留，后续 Step 3 再深挖
- 如果只给了论文没给场景：停下来问"你打算用在什么场景？"——本 skill 不做"反推适合什么场景"（那是另一个需求）
- 如果只给了场景没给论文：停下来问"具体是哪篇论文？"
Step 2: 拆解论文（提取"可落地的方法内核"）
读论文全文，不要做学术综述，而是提取工程视角的关键信息：
- 方法内核：这篇论文真正的新东西是什么？（一句话，剥离掉实验装饰）
- 核心假设：方法成立依赖哪些前提？（数据分布、规模、静态/动态、iid、标注可得性等）
- 输入/输出契约：方法的输入是什么、输出是什么、接口形状
- 计算特征：训练成本 / 推理成本 / 内存占用 / 是否需要 GPU / 是否可批处理 / 是否有在线学习需求
- 论文验证条件：在什么数据集、什么规模、什么指标下证明了有效——这界定了它的已知适用边界
- 可替换组件 vs 不可替换内核：哪些是论文的创新（必须保留），哪些是工程可替换的（backbone、优化器、特征工程等可换）
输出到内部工作笔记，供后续步骤引用。这一步的产出是理解，不是交付物。
Step 3: 拆解工业场景（提取"真实约束"）
从用户的场景描述里，主动追问或合理推断这些工程约束（推断的必须标注 [推断]）：
| 约束维度 | 要明确的点 |
|---|
| 功能边界 | 要解决的具体业务问题、输入输出、和现有系统的接口 |
| 规模 | QPS / 数据量 / 用户量 / 并发 / 增长趋势 |
| 延迟 | p50/p99 要求、在线还是离线、同步还是异步 |
| 数据 | 数据从哪来、质量如何、标注成本、是否有分布漂移、隐私/合规约束 |
| 可靠性 | 可用性要求、能否降级、故障影响面 |
| 成本 | 算力预算、人力、对单次请求成本是否敏感 |
| 集成 | 现有技术栈、部署环境、能否引入新依赖 |
| 团队能力 | 谁来维护、对方法的熟悉度 |
如果用户场景描述太简略，用「合理默认 + 追问最关键的 1-2 个」，不要把 8 个维度全问一遍（违背"只问一次"原则）。判断哪个最关键：看论文方法对哪个维度最敏感（Step 2 的计算特征 + 核心假设）。
Step 4: Gap 分析（论文方法 × 工业约束）
这是 skill 的核心价值。逐维度对照，详见 references/engineering-checklist.md 的 8 维度框架。对每个维度产出三件事：
- 论文怎么说（Step 2 的结论）
- 工业场景要求什么（Step 3 的结论）
- Gap 是什么 + 怎么补（改造方案 / 替代方案 / 必须接受的妥协 / 需 PoC 验证的点）
重点输出三类 Gap：
- 🔴 硬伤：方法假设和场景根本冲突（如论文假设 iid，场景是明显非平稳的时序）→ 要么换方法，要么大改
- 🟡 可工程化 Gap：方法对但需要改造（如论文推理太慢，需蒸馏/量化/缓存）→ 给改造方向
- 🟢 直接可用：基本能照搬 → 指出落地路径
Step 5: 产出三件套
在工作目录下创建产出文件夹，写入三份文件：
{yymmdd}-{论文简称}-to-production/
├── README.md — 分析概览 + 核心结论（决策者看这个就够）
├── feasibility-report.md — 落地评估报告（可行性/风险/收益/成本预估）
├── tech-design.md — 技术方案文档（架构/选型/接口/数据流/监控降级）
└── gap-analysis.md — Gap 分析清单（8 维度逐条对照 + 优先级）
三份文件的模板见 references/report-templates.md。
核心结论要在 README.md 顶部给出明确判断，三选一：
- ✅ 建议落地：方法契合、Gap 可补、收益明确 → 技术方案可直接用
- ⚠️ 有条件落地：需先做 PoC 验证某些关键假设 → 明确 PoC 要回答什么问题、成功标准是什么
- ❌ 不建议落地：硬伤无法克服，或成本/收益不划算 → 说明为什么，并建议替代方向（换方法 / 换场景 / 等方法成熟）
Step 6: 展示结论，确认完成
向用户展示 README 的核心结论速览（判断 + 3-5 条理由 + 最大风险），告知文件位置。等待用户确认或追问。
关键纪律
- 不要变成论文翻译/综述：Step 2 是为了落地，不是为了讲清楚论文。能省则省。
- 不要堆砌 MLOps 工具名：技术方案里的选型要基于用户的约束给出理由，不要默认就上 Kubeflow/MLflow。小场景可能一个 cron + Docker 就够了。
- 不要编造性能数字：论文没给的工业指标，标"需实测"。预估要标"[预估]"并给依据。
- 数字要带单位带条件："延迟 50ms" 没意义，要写"p99 50ms @ 1000 QPS，单卡 A10"。
- 尊重"具体场景具体分析"：用户在问卷里明确选了这项。如果某个维度因场景信息不足无法下结论，不要硬填模板，直接写"此项需补充 XX 信息才能判断"。
何时不用这个 skill
- 用户只想精读/理解论文（不涉及落地）→ 用
paper-learn
- 用户只想忠实复现论文实验代码 → 那是学术复现，不是工业落地，本 skill 不适用
- 用户只有场景、要找匹配的论文 → 用
deep-research + 文献检索
- 用户要联网查论文背景/已有工业实现 → 本 skill 默认离线；如需联网，用户会另起
deep-research 或 web-access
参考
