当使用者贴出一份写好的歌词说"帮我改改"、"这词哪里有问题"、"听起来像 AI 写的"、"帮我看看字数和押韵对不对"时使用。先跑脚本做机械体检（字数、断句、陈词命中、重复行、与模板比对），再判断需要读音和语感的部分（韵辙、画面感、主歌推进、hook 是否成立、可唱性），可派一个 sonnet 子代理做陌生听众初听测试。
产出定点修改清单，每处给两三个替换候选，不重写整稿。
The English summary is being prepared. Showing the original description.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
给一份写好的词做体检，产出定点修改清单。
不重写整稿。使用者自己写的词里有他的语气和真话，整篇重写等于把这些换成模型的默认口吻， 稿子会变得更"顺"也更没人味。这个技能只指出哪一行有什么问题、可以往哪个方向改。
不适用于 / Not for：
adversarial-lyric-writerlyric-structure-mapper把词存成文件（段落名单独一行，空行分段），有字数模板也存一份，然后：
python3 scripts/lyric_check.py 歌词.txt --template 模板.txt
段落名照使用者的写法存就行：「主歌 1」「【副歌】」「副歌：」「[Verse 1]」都认， AABA 里单独一行的「A」「B」也算段落名。歌词段落先按段落名找模板段落，写法不同也对得上： 「主歌 1」「主歌 2」都对模板的「主」，「副歌」对「副」，重复出现的段落反复套用同一段模板。 A/B 后缀不去掉，「副歌 A」只对模板里的「副 A」。对不上的段落会报出来并计入机械问题， 不按位置硬配。
脚本给出：每行字数与停顿分段、行末字、陈词黑名单命中、完全重复的行、
同一个字反复收尾、与模板的逐行比对。无第三方依赖。退出码：0 没有机械问题，
1 有机械问题，2 输入有误（文件读不了、模板里没有 x 行）。--selftest 跑脚本自带的回归用例。
--extra 词1,词2 可以追加本首特有的禁用词（比如使用者不想再出现的某个意象），
逗号全角半角、顿号都能分隔。
目测数字数一定会错。 十个字和十一个字看上去一样，唱起来差半拍。 脚本不做押韵判断，因为那需要读音，纯字符串做不了。
脚本跑完，逐项过下面这些。判据见 _shared/craft-reference.md：
| 检查项 | 怎么判 | 参考 |
|---|---|---|
| 韵辙 | 每段行末字是否同辙；副歌是不是开口辙 | 第 1 节 |
| 画面感 | 逐行问：这句能不能拍成一个镜头？拍不了的占比 | 第 2 节 |
| 主歌推进 | 主歌二相对主歌一，时间/地点/事件/视角变了吗 | —— |
| 副歌重复 | A/B 两段是不是同义换词 | —— |
| hook | 有没有一句能单独拎出来、且反复出现 | —— |
| 倒装 | 有没有为押韵扭曲语序的句子 | 第 1 节 |
| 可唱性 | 行末和停顿前是不是闭口音；换气点间隔是否过长 | 第 3 节 |
画面感这一项最要紧。一首词听起来像 AI，九成是因为通篇在讲道理没有具体的东西。 脚本能查出"温柔""治愈"这类词，但查不出"一切都值得"这种没有黑名单词、 却同样空洞的句子。这一项只能靠逐行判断。
判断 hook 是否成立时，派一个 sonnet 子代理，model: "sonnet"，只给它歌词正文，
不给主题说明、不给概念卡、不给任何背景。让它：
它记不住任何一句 → hook 不成立。 它说的主题和使用者想写的差很远 → 处境没有立住，问题在概念层不在句子层。
这个测试之所以要用子代理，是因为主 Agent 已经知道这首歌想写什么，读不出"第一次听"的效果。
按严重程度排序，不按行号排序。每一处给：位置、问题、两到三个替换方向（不是成句）。
给方向而不是给成句的原因：直接给成句，使用者多半会照单全收， 最后整首词变成模型写的。给方向能让他用自己的话改。
只有他明确说"直接给我改好的句子"时才给成句，并且标出哪些行被换掉了。
## 机械体检
<脚本输出的关键结论，不要整段粘贴>
- 字数：<全中 / 第 X 段第 Y 行差 N 字>
- 陈词：<命中 N 处，列出来>
- 重复：<有无>
## 需要判断的部分
| 项 | 结论 |
|---|---|
| 韵辙 | 主歌=言前，副歌=江阳，桥段第 3 行脱辙 |
| 画面感 | 24 行里 7 行能拍成镜头，其余在讲道理 |
| 主歌推进 | 主歌二是主歌一的同义换词 |
| hook | 不成立（初听测试没记住任何一句） |
## 修改清单（按严重程度）
### 1. <位置> —— <问题类型>
原句：<那一行>
问题：<具体是什么毛病>
方向：
- <方向 A>
- <方向 B>
### 2. ...
## 不用改的地方
<写得好的行，明确说出来。全篇都是问题会让人不想改了>
最后那一段不是客套。一份只有问题清单的体检报告，使用者会直接推倒重写， 连原本写得好的句子一起丢掉。
| 版本 | 日期 | 变更 | 类型 |
|---|---|---|---|
| 0.1.1 | 2026-09-26 | 修 lyric_check.py：段落名与模板写法不同（主歌 1 对「主」）时重复段被静默跳过、按序号兜底配错段落，改为精确名 → 去编号归一名 → 对不上就报；认【主歌】、副歌：、AABA 的 A/B；模板全角空格和 --extra 全角逗号不再失效；黑名单补「这就是最好的」「所有的X都会Y」并与 craft-reference 自检同步；加 --selftest；"脚本查不出"的例句换成真查不出的「一切都值得」 | patch |
| 0.1.0 | 2026-08-11 | 初始草稿，含无依赖的机械体检脚本 | minor |
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
当学生说"Common App 活动栏写不下"、"这段活动描述超字数了"、"帮我把这几条压到限制内"时使用。先按官方申请表核对当季字符限额，再逐条检查；一次把所有条目量完并直接给出压缩版，只在需要砍掉实质内容时才用选择题问该保哪部分。每改一版都用工具重新数一遍字符，绝不凭感觉说"这样应该够了"。只压缩，不代写空白。
The English summary is being prepared. Showing the original description.
当学生说"我参加过一些活动但没整理过"、"帮我把经历录进去"、"我的活动档案是空的"时使用。让学生一口气把记得的活动说出来，直接把这段话拆成结构化的长期事项（角色、组织、起止时间、做了什么、结果、级别），说不清的字段留空标"待补"而不是编，再用一张选择题卡把级别判定与是否重复这类关键项一次问完，然后提案入库。只记录学生真正说出口的内容，级别按事实判定，绝不往高了写。
The English summary is being prepared. Showing the original description.
当学生问"招生官会怎么看我的档案"、"我的背景还差什么"、"帮我评估一下现在的申请竞争力"时使用。以顶尖大学招生官的视角通读学生的档案、长期活动与已写下的反思，不问任何前置问题直接产出一份指名道姓的坦诚点评：这份材料的亮点、招生官真实的解读方式、明显的短板与空白、以及接下来最值得做的一到两件事。只读不写，不修改学生的任何数据，也不代写任何申请材料。
The English summary is being prepared. Showing the original description.
当使用者说"帮我填词"、"按这个字数模板写歌词"、"用多Agent对抗式写词"、"这首副歌帮我想几句"时使用，前提是字数骨架和这首歌写什么都已经有了；只有主题、还没定写什么时先用 lyric-concept-builder。拿一份字数骨架和意象系统，派三个 sonnet 子代理按不同路子并行独立起草（场景派 / 口语派 / 意象派），再派一个红队子代理逐句挑毛病，主 Agent 按句裁决拼稿，最后统一辙口与意象。收敛判据卡死：字数用 lyric-doctor 的脚本对模板数、每段同辙、hook 不含陈词、主歌二对主歌一有推进。不抄现有歌词，不替使用者决定这首歌要说什么。
The English summary is being prepared. Showing the original description.
当想知道一段 AI 回答"哪些能直接用、哪些必须先验证、哪些只能当建议"时使用。按声明类型分四级——低风险草稿材料、观点与策略建议、可查证的事实声明、会改变状态的可执行指令——每级配一句默认处置动作；再按影响半径排序，给出最小的下一步检查。可执行类一律标"不能直接执行；先做代码审阅/沙箱测试/回滚准备"，其中破坏性或提权的命令排在最前。教的是一套可复用的复查习惯，不是替使用者把所有内容都核实一遍：本 skill 只分级、排序、定处置，要逐条核实走 ai-output-fact-checker，整段代码要做入库体检走 ai-code-onboarding-checklist。
The English summary is being prepared. Showing the original description.
当拿到一段 AI 生成的代码，还没决定要不要信、要不要跑、要不要往上继续加东西时使用。先做一遍客观体检：行数与嵌套深度、有没有测试、有没有硬编码密钥或遗留 TODO、依赖是不是真实存在、有没有危险调用（eval/exec、shell=True、递归删除、反序列化、提权、外发网络，按正文给的 grep 模式逐类查）；再给风险评级和下一步动作。老实写明它查不了算法正确性——体检通过不等于代码是对的。回答里文字、事实和代码混在一起时先用 ai-answer-triage 分级；只审相对已有代码的一份改动用 ai-diff-review-protocol。
The English summary is being prepared. Showing the original description.