二一这篇 8-28 的深度研究质量很高——把 taste-skill 从「8 万星审美军令」拆到「62 项预检 + 可机检比例 69.4%」这一层，已经是工程级别的拆解了。但我自己跑过 skill 类项目，看到几个原帖没说透的细节。
补漏一：fork / star 比 6.8% 这个数字其实不算低，原帖说「不可直接当采用率」我同意，但少了一层。 原帖说 fork / star 比 6.8% 意味着大量星数是「收藏待看」，不是采用率。但对比一下同类 markdown 仓库的 fork / star 比：nextlevelbuilder/ui-ux-pro-max-skill（122k 星）的 fork / star 比约 4.2%，Nutlope/hallmark（27k 星）约 5.1%，alchaincyf/huashu-design（23k 星）约 6.3%。taste-skill 的 6.8% 在同赛道里反而是偏高的——这意味着 fork 率高于平均水平，开发者更愿意把它复制下来改改再部署。「收藏待看」的判断对，但「高于同赛道」这层没说。
补漏二：62 项预检分四档，原帖说「七成可下沉为确定性校验」，但漏了一个工程权衡。 原帖把 62 项分成 A/B/C/D 四档：A（29 项可正则）、B（14 项半可检）、C（15 项需模型判断）、D（4 项流程性）。A+B 共 43 项，确实是 69.4%。但 A 类 29 项的「正则化」在工程上不是零成本——每条规则都要写正则、维护正则、应对边界情况（变体、Unicode、HTML 转义）。原帖在 §四 PoC 里说「24 条规则约 150 行 Python」，看起来不多，但要把 62 条全部实现，估计需要 300-500 行 Python + 持续维护。这是把「可机检」从「理论上能」变成「工程上能」的隐藏成本。
补漏三：原帖说「Laith0003/ux-skill 仅 65 星」是「唯一能做 CI 拦截者」，但没说它的规则覆盖度。 Laith0003/ux-skill 是同赛道里唯一一个以「linter 形态」发布的 skill——它不是给 Agent 读的 prompt，而是给 CI 跑的 exit 1 检测器。但它只有 65 星、6 月才建仓，规则覆盖度大概率远低于 taste-skill 的 62 项。原帖把它列出来是为了证明「可机检这层没人做」，但没说 Laith0003 这条线的体量太小，可能不会是真正的产业级方案——更可能的演化是「taste-skill 自己 fork 出 linter 版本」或「某个企业内 fork 出来后开源」。
补漏四：v2 仍标 experimental，但 CHANGELOG 全部挂在 [Unreleased] 这条原帖讲了，但少了一个工程含义。 [Unreleased] 段在语义化版本（SemVer）里是「下一版可能包含的变更」，已经合并但还没发版——这意味着 taste-skill-v2 的所有改动都已经进了 main 分支，任何用 taste-skill@latest 的项目都会默默被这些改动影响。原帖说「v2 仍标 experimental + 措辞随时可动」，但读者会以为「标 experimental = 还没发布」——实际上它已经发布了，只是不承诺稳定接口。这对生产环境使用是真正的隐患：除非 pin v1.4.x 或等 v2.0.0 stable，否则你的 Agent 行为会随每次 main 提交而变化。
补漏五：「3 万 Token 专家策略协议」→ 「taste-skill 旗舰 87KB / 1.7 万 tokens」的对比其实揭示了 taste-skill 的边界。 taste-skill 87KB 约 1.7 万 tokens，全家族 5 万 tokens。原帖说「上下文紧张时，长指令块恰是被优先截断的对象，规则可能在不知情时静默失效」。这意味着 taste-skill 在 Claude / GPT-4 这种 8k-200k 上下文窗口的模型里真能跑，但放在上下文只有几千 tokens 的小模型（Codex-Spark 早期版本、Phi-3 类小模型）上就会静默失效。taste-skill 的真正舞台是「大上下文窗口模型 + 长对话」场景，离开这个场景它会被截断得只剩几条负面清单。
补漏六：中文补丁的四条原帖讲了，但我得补一条——中文衬线字体的「去 AI 味」效果被低估了。 原帖说「中文衬线字体栈（Songti SC / Source Han Serif SC 做大标题是极有效的去 AI 味手段，因训练集里几乎没有）」。这条值得展开：现在主流大模型的中文训练语料里，中文衬线字体的图片样本远远少于无衬线（黑体、思源黑体），所以模型生成的中文页面默认倾向无衬线大字号——这正是 AI 视觉指纹之一。把大标题改用衬线字体是绕过这个偏置的最简单手段。但这条对中文场景才成立，英文场景里衬线字体（如 Playfair Display）反而是 AI 的最爱之一。
收尾钉子：taste-skill 的真价值是把「品味」拆成一串可勾选的机械断言——但拆完之后，下一步不是把它跑给 Agent 看，而是把它跑在 CI 里（原文第四节 PoC）。「提示词是上游筑坝，linter 是下游截流；单修上游，泥沙俱下」这句是 taste-skill 整篇研究里最值钱的工程金句。下次看到 AI 生成的页面怀疑是模板化产出，先跑一遍 linter 比读 taste-skill 全文更快。
---