深度专辑乐评

问题：乐评容易写长，却难写对

万字长评的难点从来不在字数。常见做法是从流媒体简介、几条采访和听感记忆里拼出一篇文章，结果往往是编年体流水账：曲目简介、风格标签、"听起来很高级"。事实性错误——错误的发行年份、张冠李戴的制作人、凭空出现的曲目列表——在这类文章里几乎是默认状态，而读者几乎无法逐条核对。

更隐蔽的问题在于统计口径。当篇幅要求写成"10,000–15,000 字"时，写作方会自然地用空格、英文术语和标点凑数：一篇夹杂大量英文与括号注释的文章可以"达标"，实际汉字量却远低于阈值。无法机器校验的长度要求，等于没有长度要求。

技能如何工作

album-review 把"写得长"拆成几件可检查的事：

• 入口路由：输入必须是"主要创作者 + 专辑名"的唯一组合。器材评论、歌词翻译、购买建议一律不产出，交给相邻技能，避免在不该写的任务上硬写。
• 运行时分类：按语种、年代、credit 的角色、作品 vs 演绎（古典）、发行形态（单曲 / EP / LP / box / live）建立描述符，据此决定分析单位是逐曲、逐乐章还是逐碟，并加载 rules/genre-lenses.md 的批评维度。用流行模板套交响曲，或反过来，都算分类错误。
• 研究扇出：围绕艺术家与创作缘起、录音与制作、音乐本体、接受史与批评、横向比较、文化语境六个角度铺开检索，再对薄弱角度加深，最后清洗、分级、三角互证。所有唱片事实都要映射到 source_id，而 scripts/validate_backing.py 会拒绝任何在 evidence[] 中找不到出处的事实类声明。
• 多轮论证：先形成总论题，再落到分段判断，每条陈述标注为 grounded-fact 还是 interpretation，不让推断冒充事实。
• 确定性校验：成稿后运行 scripts/check_review.py，汉字长度按正则 [一-鿿] 统计，章节结构走体裁适配的 linter。任何一项不通过就不出稿，这一过程不依赖作者的自我感觉。

适用边界

• 资料稀薄的专辑会诚实降级：显式写出资料不足或公开资料有限，绝不虚构曲目、乐手与日期。
• 不提供购买、价格、交易建议，研究过程为只读。
• 离线环境下退化为使用调用方提供的材料，并在 trace 中标注 research_mode。
• 它是写作与校验流程，不保证审美判断正确；论题质量取决于输入质量与检索覆盖面。