小舞_总裁专属

单文件 123 行，本批三包里最厚实的一个，也是唯一给了可直接可用素材的：五段内置业务模板（A 辖区参保现状、B 资格认证难点、C 医保征缴举措、D 窗口提质、E 风险防控二级标题）都带真实基层细节——模板 C 的「村不漏组、组不漏户、户不漏人」、模板 D 的首问负责、一次性告知、容缺受理、延时服务，模板 E 直接给了经办风险、信息安全、信访、舆情四节成段文字；另有新建撰写与旧方案修订校对双模式、六项内部自检、汇报摘要 300-600 字单独输出不混入正文，流程完整度明显高于同类。 但占位符规则自相矛盾：第 48 行要求「统计数据全部使用【】预留占位符」，自检第 79 行也是「所有占位信息使用【】」，可第 31 行自己给的量化指标示例是「参保率稳定保持 XX%、认证 XX 人、宣讲 XX 场次」——裸 XX 不带【】，同一句收尾却写着「全部使用【】占位」；模板 A（第 99 行）又是【】风格（「参保率约【】%」）。照第 31 行示例写出来的 XX% 会被自家自检判违规，两种占位风格在包内并存，修订模式（第 92 行）还要「统一使用【】占位符」，等于修订时必须改掉按新建示例写的稿。 公文要件缺失：「落款」「成文日期」「页码」「页边距」全文 0 命中——第 48 行连乡镇名称、时间节点都要求占位，却没给发文单位落款、成文日期与页码位，粘贴 Word 后方案没有收尾要件；第 54 行标题写「黑体二号」，GB/T 9704-2012 规定公文标题用 2 号小标宋体。第 57 行正文写死仿宋_GB2312 且无降级条款（「降级」「替代字体」0 命中），本机 Windows 并无 _GB2312 变体（simfang.ttf 即仿宋），Word 会静默替换。 小毛病两处：模板 B（第 102 行）外层引文与内层「不会操作」「不便到场」全是 ASCII 双引号嵌套，照抄进公文即出现裸英文引号，中文公文内层应用单引号；第 42 行把「可选新增一级章节」列进「强制内容框架要求」的第 7 节，强制框架里挂可选项，边界含混。 改进建议：第 31 行示例改成【】风格或删掉「全部使用【】占位」半句；输出规则补落款（单位+成文日期）与页码两条；标题字体改 2 号小标宋；模板 B 引号改中文单引号，并把可选章节移出「强制内容框架要求」单独成节。

SKILL.md主体尚可：第36-42行定制选项表五项（篇幅/语气/报送对象/数据呈现/交付形式）各带默认值，四段式基础框架加分场景扩展模块（第48-61行）结构清楚；第104行「隔离期限、消毒频次不臆造具体数值，无法确认时使用按规定等规范表述」是同类包里少见的防编造细则，值得肯定。 但references整份垮掉。example-briefs.md第3行承诺「四类简报各提供一段示例正文」，实际只有宣传教育类（第9-14行）给了正文，演练/培训/会议三类全是「正文要点」提纲——「正文要点」恰好在第20/29/37行命中3次，唯一配套参考文件的兑现率是1/4，而且第50行末尾还自称「以上仅为结构与写法参考」，等于把承诺降级免责。 示例一的交付形态错乱是第二处硬伤：6个段落全部包裹<p style="font-family:宋体;font-size:小四;...">这样的HTML标签，而SKILL第111行要求聊天文本交付时「直接输出完整可使用的简报正文，无需多余解释说明」——模型照抄示例会把HTML标签原样带进简报正文；且font-size:小四不是合法CSS值（「小四」是中文字号名，CSS应写12pt），这6条内联样式本身不可渲染，两头都不成立。 第三处：示例一6段合计仅336个汉字（逐段实测102/132/51/41/7/3，含标点共381字），落在精简档（300-450字）区间，而默认篇幅是标准档450-650字，示例又未标注自己对应哪一档；更矛盾的是第10行把「一、」「二、」「三、」三个一级层次塞在同一个段落里，与SKILL第92行「一级用一、二、三」分层的规范直接打架——唯一的正文示范在层次上就违反自家规范。 建议：①补齐三类示例正文，剥掉全部HTML标签，字号直接写成排版说明；②每个示例标注对应的篇幅档；③示例一按「一、二、三」拆段，与第92行对齐。

三个候选里最扎实的一个。方法定位清楚：仅限项目请示、报送项目函、项目工作责任书三类（第14-18行），核心是沿用旧公文模板只换变量（第25行），并给出素材冲突优先级「上级下达文件＞新项目实施方案＞旧公文模板」（第53-54行），第58行明令「绝不编造文号、资金数额、人名、未明确的指标数据」——基层公文里最容易出事的几件事都设了闸。 十项自查（第66-75行）是同类包少有的可执行质检面：文号、主送机关、数据多处引用一致、附件、文种合规，第73行「请示不夹带报告事项」暗合一文一事规则；更难得的是第78-80行给了三种标注（合规/风险：xxx，建议修改为xxx/信息不足，需人工复核）——模型核不了主送机关真伪时不会硬下结论，第101行还写「不得在缺少依据时替用户做事实判断」，设计诚实。 硬伤在文种选择零判据：「一文一事」「隶属」「行文关系」三个词全文命中均为0。项目请示与报送项目函的分界（向隶属上级用请示、向不相隶属机关用函）是《党政机关公文处理工作条例》的基本规则，全包没有一行规则支撑，第30行只写「文种不明时先问，不猜」——把最核心的专业判断推回给用户。镇农服中心报项目恰恰是请示/函最容易混用的场景，这一步问完用户多半也答不上来。 小瑕疵：第45行函的套语「现将XXX报送贵单位，请审阅」偏报告腔，函的规范收束常用「特此函达」「盼复」；三类公文各只给一句开篇套语、无收束语，照抄空间大。 排版参数零命中但逻辑自洽：该技能定位是「完全沿用上传原公文的格式」（第38行），字体字号随模板走，不算缺陷；第89行明写「不直接生成docx文件」，交付边界诚实，胜过一堆承诺产出Word却无脚本的同类。 改进建议：第二节补一张两行对照表「向隶属上级要资金/批准→请示；向不相隶属单位送审/商洽→函」，并把第45行补一句函式收束语。

82行单文件，无references。先说结构：第18-25行六章清单（工作背景/指导思想/目标任务/实施步骤/保障措施/工作要求）与description完全一致，「六大」全篇2次命中均与实际6章对上，无数词自证问题；第36-38行一级黑体三号、二级楷体三号、正文仿宋三号符合公文惯例，行距固定值28磅、首行缩进2字符均可执行，这部分是合格的。 硬伤一在标题字体：第35行写「全文标题：黑体、二号字、居中对齐」，而GB/T 9704-2012规定公文标题用2号小标宋体字，黑体是党委系统个别文类的选择、不是通用政府公文规范，照这张表排出的报头会被办公部门退回重排；同系列乡镇社保包也写黑体二号，疑为同一模板的复制错误。 硬伤二更致命：体式要件整体缺失——「落款」「成文日期」「页码」「页边距」「印章」「署名」六个词全文命中均为0，而第44行承诺「可上报使用」、第72-74行又承诺「满足直接排版打印、上报使用标准」。工作方案上报必须有落款单位与成文日期，页码是GB/T 9704硬性体式，两项皆无，成稿并不能直接上报，宣称与交付能力脱节。 第三点薄：第五章「各章节撰写要点」每章仅1行，全篇无任何内置业务模板、无示例段，「保障措施」只给组织/制度/人员/技术/督导5个维度名词，内容全靠模型自由发挥，同类题材里做得好的包（123行、带5段内置业务模板）可作对照，本包内容支撑最薄，产出稳定性存疑。 正面也记一笔：第44行docx生成为条件分支（「若用户明确要求且环境具备docx生成能力」），不是硬依赖，比同类硬绑外部技能、断链即停的包稳妥。 改进建议：①第35行改「2号小标宋体字」；②输出规范补「落款（发文单位+成文日期）」与页边距参数（GB/T 9704为上37mm下35mm左28mm右26mm）；③每章至少给1段示范文字，压住自由发挥空间。

单包两文件：SKILL.md 93 行 + references/format-standards.md 144 行，无 scripts/，纯知识型技能。骨架是三包中最全的：7 个固定章节（工作背景/指导思想/工作目标/主要任务/实施步骤/保障措施/工作要求），每章都给了篇幅建议，加总约 2700—4200 字，与「工作方案」体量匹配；第 89-94 行用表格把实施步骤拆成筹备（第1-2周）/试运行（第3-6周）/全面运营（第7周起）/巩固提升（运营3个月后），比只写「分四个阶段」可执行。第 138-144 行的禁用表达对照是全文最有实操价值的一节，逐条给替身词：「粉丝宝宝们」→「关注用户」、「爆款内容」→「优质传播内容」、「涨粉」→「用户增长」、「带货」→「产品推广」，边界清楚。第 20 行还给出页边距上3.7/下3.5/左2.8/右2.6cm，正是 GB/T 9704 版心白边，在此类技能里属稀缺信息。 四处具体问题：① 三级标题漏在门外。format-standards 第 12 行定义了「三级标题 仿宋 三号 左对齐，加粗，示例 1.现状分析」，但 SKILL.md 第 69-74 行的格式表只有 4 层、没有三级标题，第 26-34 行的【格式设置提示】模板 6 条里也没有对应条目；全包「三级标题」只 1 次命中就是那行定义——用户照模板设置时，三级标题会与正文同为仿宋三号，加粗属性无处传递。② 对齐口径不一：format-standards 第 13 行把正文写成「左对齐」，与它自己声明的 3.7/3.5/2.8/2.6cm 版心（按每行字数两端对齐排版）不符，行尾参差、右边界不齐；而 SKILL.md 那张表干脆没写对齐列，两边对不上。③「覆盖抖音、微信视频号、快手、B站」是复述不是能力：四个平台名各 2 次命中，全部落在 SKILL 第 3 行description 和第 17 行信息采集清单；144 行的 format-standards 里没有任何分平台内容——时长上限、竖屏比例、审核红线、发布时段、热点机制一个参数都没有，第四章只写了「发布排期运营：更新频率、发布时间、平台分发策略」一句。④ 实施步骤时间轴写死：第 89-94 行固定为「第1-2周／第3-6周／第7周起／运营3个月后」，而 SKILL 第 19 行把「运营周期：如年度、季度、半年等」列为必采输入——交了年度方案，四阶段仍在第 7 周「全面运营」、第 3 个月「巩固提升」，输入与结构不联动。此外落款、成文日期、页码全 0 命中，第 34/93 行两次承诺「最终生成 Word 文档」，但包内既无脚本也无 docx 模板，全靠一个没写清名称的外部「docx 技能」，属未声明依赖。 改进建议：把三级标题补进 SKILL 格式表与【格式设置提示】模板（明确三号仿宋加粗+首行缩进2字符）；把「运营3个月后」改为相对周期表述（如「运营周期后 1/4 时段」）或由运营周期按比例换算阶段起止；在 format-standards 补一张分平台参数表（每平台 1-2 条硬指标，如竖屏 9:16、发布时段窗、审核红线），把 description 的四平台承诺落到实处。

纯文本型技能：全包 4 个 .md（SKILL.md 70 行 + format-spec 34 行 + outline-template 57 行 + wording-guide 40 行）加一个图标，无 scripts/，只能逐字读文档评价。分工清楚：format-spec 用「对象/字体/字号/对齐/其他要求」表格列格式，outline-template 给 5 个固定章节的二级标题与要点，wording-guide 给标准起句 3 条、过渡语、基建术语表（路线走廊带、工可、桥隧比、公路—Ⅰ级）和禁用清单。术语表与禁用清单最实用，尤其「不得虚构投资额度、交通量、经济效益等精确数值」对基建规划是必要约束。 三处被文档自身暴露的问题：① 示例与章节结构对不上。SKILL.md 第 46 行把一级标题示例写成「一、工作背景」，但第 31-35 行的固定章节是「一、项目概况」；全包「工作背景」只 1 次命中，就是那行示例——典型的从其他方案模板套壳残留。第 47 行二级标题示例「（一）政策依据」同样孤立：outline-template 第 5-9 行里「一、项目概况」下挂的是（一）项目背景、（二）项目基本情况、（三）编制依据与规划期限，没有章节叫「政策依据」，全包「政策依据」也是 1 次命中。模型照示例写标题，就会冒出结构表里不存在的层级。② 字数与段落密度互斥。outline-template 第 57 行要求「每个二级标题下正文以 2—4 个自然段为宜，全文总字数控制在 3000—5000 字」；但固定五章的二级标题共 15 个（3+3+4+3+2），按最少 2 段算是 30 段，压进 5000 字每段平均只能 166 字，压到 3000 字则每段只剩 100 字，低于公文正文常见段长；再叠上投资估算/资金筹措/保障措施/效益分析四个拓展章节就更收不住。③ 风险防控定位自相矛盾：SKILL 第 35 行把它列为固定必写的「五、风险防控」，outline-template 第 56 行却写「风险防控按用户要求为固定第五章」，「按用户要求」与「固定必写」不能同时成立；同一行又说「保障措施通常作为倒数第二章」，拓展章节插入后两条排序规则会打架。 改进建议：把第 46/47 行示例换成结构表里真实存在的「一、项目概况」「（一）项目背景」；把字数口径改为「二级标题数×每段 150—250 字」的弹性表述，或让总字数区间与二级标题数量挂钩；第 56 行改为「固定为末章，插入拓展章节时编号顺延」。另：SKILL 第 48 行写「仿宋三号」、format-spec 第 10 行写「仿宋（仿宋_GB2312）」，两处字体名不一致，而仿宋_GB2312 在 Windows 上通常并不存在（本机注册表 165 条字体记录零条 GB2312），建议统一为「仿宋」并加一句字体缺失提示。

实跑验证：用 python-docx 1.2.0 执行 scripts/generate_docx.py 跑自带 sample_plan.json，成功产出 39KB 的 .docx；拆 XML 逐项核对，页边距 w:pgMar 实测 top=2098 / right=1474 / bottom=1984 / left=1587 twips，即 3.7/2.6/3.5/2.8cm，与 GB/T 9704 版心白边完全吻合；全篇 44 处 w:lineRule="exact" w:line="560"＝固定值 28 磅，无一处漏；缩进同时写 w:firstLineChars="200" 与 w:firstLine="640"（三号 16 磅×2）双保险，比只写磅值稳。结构强制力也真实：六大章节标题由脚本第 47-54 行固定生成，JSON 缺节即 exit 1 并打印「内容不完整，缺少章节数据：requirements」——我用 SKILL.md 第八节的示例 JSON 原样跑，确实被这条拦下。 但有三处硬伤：① 纸张尺寸错。产物 w:pgSz 实测 12240×15840 twips，是 Letter（8.5×11 英寸），不是国标 A4 的 11906×16838。白边按 A4 版心设计，套到 Letter 上实际版心变成 161.9×207.4mm，比国标 156×225mm 矮 17.6mm，按 28 磅（9.878mm）行距算每页只剩 21 行，国标要求的 22 行落空——set_page_margins() 第 136-141 行只设了 pgMar，从没设 pgSz，而 Document() 默认就是 Letter。② 零页码，产物 footerReference 与 PAGE 域均 0 命中，与 SKILL 第 3 行 description「可直接上报印发存档」、第 10 行「格式合规」的自我定位不相称。③ 字体回退是死代码：第 37-38 行定义了 FONT_FANGSONG_FALLBACK="仿宋"、FONT_KAITI_FALLBACK="楷体"，但 grep 全文件除定义行外零引用；产物 eastAsia 实测写死「仿宋_GB2312」24 处、「楷体_GB2312」13 处，而本机注册表 165 条字体记录里一条 GB2312 都没有（只有 FangSong / KaiTi / SimHei）。docstring 第 9-10 行承诺的「(回退楷体)(回退仿宋)」从未生效，打开时字形由办公软件兜底，「打开即为定稿版式、无需二次调整」在干净 Windows 上不成立。 改进建议（按优先级）：在 set_page_margins() 里补 section.page_width=Cm(21)、page_height=Cm(29.7) 固定 A4；加页脚用 w:fldSimple 插入 PAGE 域，按国标配 4 号宋体、单页居右空一字；字体先做一次真实探活（查注册表或 docx.fonts），命中才写 _GB2312，否则写「仿宋」，让回退常量真正被用上。另外把 SKILL.md 第八节示例补上 requirements 键；落款由纯右对齐改为右空四字（w:ind w:rightChars="400"）更贴国标。

整包只有一个 SKILL.md 共 68 行，无 references/、无 scripts/、无任何文书模板或法条底表。description 承诺覆盖违法建设、占道经营、损毁城市绿化、燃气安全、市容环境卫生、耕地保护、网吧监管、酒店经营 8 类事项，正文只在第 20 行把同一串名词原样复述一遍，8 类事项没有任何分事项的检索指引或法条线索，「检索范围覆盖」是复述不是能力。边界声明自相矛盾：第 56 行③「不解答诉讼、行政复议以外的法律咨询」，按字面意为只答诉讼与复议咨询、拒绝其余法律咨询，与第 10 行角色定位「仅围绕综合执法业务」及第 52 行①「不提供最终案件定性结论」正面对撞，写作意图应是「不解答综合执法业务以外的法律咨询」，否定域写反，一句话变成反向授权。「自动过滤废止、失效条款」（第 22 行）无任何支撑：全包无检索工具、无法规库，「数据库」「核验」「修订」全文 0 命中，「废止」2 处命中全是这句宣称本身——法规时效完全靠模型记忆裸奔，而这恰是此类技能最高频的翻车点，至少应要求输出标注公布/修订年份并给出与国家法律法规数据库交叉核对的步骤。文书生成零落点：第 40-46 行承诺生成责令改正通知书、催告书并「预留案件信息填空位」，但无一份模板文件或样例，「符合行政执法文书格式规范」无从对齐；对照 8 类事项连一条示例法条都没有。正面：第 30 行「默认只选一条定性加一条罚则、不做全量罗列」的输出精简规则、第 48/68 行强制附带 AI 生成免责提示、第 54 行查无匹配法条须如实告知——防幻觉意识在同题材纯提示词包里属于认真的一档，可惜没有落到任何可执行资产上。改进建议：建 references/ 法条底表（8 类事项乘定性条款、罚则、裁量基准三列，标注现行版本年份与核验日期）；把第 56 行否定域改正；补 templates/ 放两份制式文书样例，让「预留填空位」有实物可依。

单文件 SKILL.md 共 121 行，无 scripts/ 无 references/。数词自证错：第 43 行写「收集 5 项关键业务信息」，下面只列了 4 项（缴费所属月度、职工人员清单、缴存比例、基数核定规则）。业务口径硬伤：全文「应发工资」命中 11 次、「上一年度」0 次——《住房公积金管理条例》第十六条规定月缴存额为职工本人上一年度月平均工资乘以缴存比例，本技能通篇拿当月应发工资直接作缴费基数（第 61/97/101/106/109 行），基数会随当月绩效浮动；且「5%」「12%」「3倍」「社平」全文 0 命中，缴存比例上下限与基数封顶的合法性校验一条没有，数算错了也没人拦。字体陷阱：第 19 行强制仿宋_GB2312（3 处命中）、无任何降级或替代字体条款（0 命中），而本机 C:\Windows\Fonts 实测并无 _GB2312 变体（simfang.ttf 即仿宋），Word 会静默替换，第 75 行还让用户自行「核对格式参数」，核的是一装不出来的字体。交付物零落地：第 29 行「必须输出 Excel 表格」是硬性要求，但全包 0 个脚本、xlsx/openpyxl 0 命中，第 76 行只教「复制粘贴到 Excel」，Agent 侧没有任何生成 .xlsx 的路径。公文要件：落款、印章、成文日期全 0 命中；标题黑体二号与 GB/T 9704-2012 第 7.3.1 条「标题用 2 号小标宋体」不符。表格 9 列里「个人缴纳金额」与「个人扣款金额」按公积金通行口径（个人缴存额即由单位从工资代扣）恒等，冗余一列，且汇总行只汇「个人扣款金额」，单位缴纳总额没有汇总位。正面：第 37/80 行写死「信息不全绝不编造」「禁止虚构职工人员」，六大强制模块清单与禁止条款一一对应，示例明示「禁止直接输出给用户」，防编造设计比多数同类认真。改进建议：第 43 行改「4 项」或补第 5 项；基数口径改为上年度月平均工资并加比例区间校验；补一份 openpyxl 脚本让 Excel 交付真正落地；字体改「仿宋」并加缺失检测。

实跑 scripts/generate_docx.py：用 2 案例样例数据一次跑通，产物拆 XML 验证——页边距 pgMar 2098/1984/1587/1474 twips 即 3.7/3.5/2.8/2.6cm，与 GB/T 9704 版心完全一致；正文 14 段全部 line=560（28 磅固定值）；黑体/楷体/仿宋三个 eastAsia 字体族写入正确（6/3/14 处），且用的都是本机真实存在的标准字体而非 _GB2312 变体，开箱即生效。但有三处实测硬伤：① 第 117 行副标题日期 date_str.replace("-","年").replace("-","月")+"日"，第一个 replace 已把两个连字符全部换成「年」，第二个 replace 永远落空，实测封面渲染为「2026年10年16日」——fallback 路径每份文档第一屏即错。② 第 74 行 first_line_indent=Cm(0.74*2)，实测 XML firstLine=839 twips≈2.6 个三号字符（三号 16pt 每字符约 320 twips，2 字符应约 640），0.74cm 恰是五号 2 字符的宽度，模板常量没随字号换算。③ SKILL 第 122 行要求行距固定 28 磅，实测 23 个 spacing 节点里 9 个无行距，四个一级标题、两个案例小标题与标题副标题全部落空。边界实测：喂 4 个案例，第 140 行 IndexError（cn_nums 只写了一二三），虽 SKILL 限 0—3 条流程上到不了，脚本仍应校验；好在该次崩溃无残留产物。另核：第 97 行主路径引用的外部 docx 技能 ID 在本环境检索不可达，fallback 脚本有效兜住；第 89 行承诺插图加图注，脚本 images 分支只会写一段文字，图片零落地；标题 6 处加粗，公文黑体标题按惯例不加粗。改进建议：第 117 行改为解析日期后按 f"{y}年{m}月{d}日" 拼接；第 74 行缩进按实际字号动态计算；案例序号用 enumerate 动态生成替代写死 cn_nums；标题去掉 bold。

单文件 81 行纯规格包（盐边县妇联工作简报），description 自报的六要素（红头/期数/发文单位日期行/主标题/正文/报脚）与正文逐节对得上，素材不足先追问、不编造活动事实的约束也明确。但决定性硬伤在字体：版式押注的四款字体在 Windows 标配里全部缺失——本机 C:\Windows\Fonts 逐文件字节检索实测：仿宋_GB2312（全文引用 3 处：期数行、单位日期行、报脚）、方正小标宋_GBK（第 37 行主标题）、方正仿宋_GBK（第 42 行正文）、华文行楷（第 23 行红头「简报」90 号）全部 0 命中；目录里只有 simfang=仿宋、simkai=楷体、simhei=黑体，无任何 _GB2312 与方正/华文系文件，而全文「降级」「替代」0 命中、没有任何缺字处理条款——换台机器粘贴，红头、期数、日期行、报脚会被 Word 静默替换字体，版式直接变形。第二处：审核人硬编码「AAA」、撰稿人硬编码「XXX」，且禁止事项与输出规则 4 两处都写「固定不变、不得更改」——简报按期出刊，每期审核/撰稿人可能不同，这和它自己「素材不足时主动向用户询问」的灵活机制直接矛盾；正确做法是把两处降为占位符并在素材收集中追加一问。第三处（可执行性）：单位+日期行要求「左右两端对齐，中间填充空格」+「整行加粗+下划线」——Word 的下划线只覆盖文字（含空格），用空格撑长度、靠下划线模拟红头分隔线，两端对齐时空格伸缩会导致线长每期不同；真简报的红线是通栏分隔线，应改用段落底边框描述。顺带：「90 号」「19 号」都不在 Word 字号命名列表里，需手动键入数值，与「格式标注方便用户调整」的目标打折扣。改进建议：① 四款字体各补一条降级链（如仿宋_GB2312→仿宋、方正小标宋→宋体加粗）；② AAA/XXX 改占位符；③ 分隔线改写为「日期行下加红色 1.5 磅段落底边框」。

单文件 50 行纯规格包，无 scripts、无 references，它的全部「实现」就是六章节结构 + 排版规范 + 开篇句式。先给正面：① 「固定输出六大章节」的声明与正文清单一数不差（1 工作背景到 6 工作要求恰好 6 条）；② 字体押注黑体/楷体/仿宋，本机 C:\Windows\Fonts 实测 simhei、simkai、simfang 三件齐全且无 _GB2312 依赖——比同题材押注仿宋_GB2312/方正小标宋的包开箱即用性好；③ 一级黑体三号、二级楷体三号、正文仿宋三号，靠字体区分层级，一级二级不会混。但自称「严格遵循党政机关公文规范」却有一处与国标直接冲突：第 27 行主标题写「黑体二号」，而 GB/T 9704—2012 第 7.3.1 条是「一般用 2 号小标宋体字」（已核政府网转发原文），照它抄会被办公室断为标题字体不合格。第二处：全文「落款」「成文日期」「署名」「印章」计数全 0——它定位「可直接粘贴进 Word 上报」，方案类上报材料通常要单位署名与成文日期，六个章节排完就截断，模板没有任何收尾要件。第三处：「页边距」0 命中，国标上 3.7/下 3.5/左 2.8/右 2.6 cm，缺这一条粘贴后还得手动调版心。另外第 29 行的二级标题示例「（一）政策依据」在包内仅此 1 次命中，与六个固定章节对不上，示例换成固定章节下的真实子标题（如「（一）指导思想」）更不易误导。改进建议：① 主标题改为「二号方正小标宋，无该字体时黑体二号替代」；② 输出要求补一条「落款：单位名称与成文日期，右对齐」；③ 排版规范补一行页边距数值。

184 行 SKILL.md + 2 份 references（room-by-room-checklist.md 137 行、vendor-and-quote-review.md 70 行），纯知识型无脚本。先说核对结果：引用双向完整——room-by-room 在 §五（第 57 行）与 §十二（第 183 行）两次挂载，vendor 清单挂载 3 次，无孤儿文件；references「使用方法」声明的八类检查口径（控制/照明/窗帘遮阳/影音/暖通环境/安防传感/网络/面板）逐项数过恰好 8 类；事实层抽查全部属实：EA-5、CA-10 主机在 2019 年度智能家居行业榜单可查证，.c4z 是 Composer 项目备份的真实扩展名，KNX 配 ETS 工程文件、4Sight 云订阅、Casambi、Ubiquiti 均为真实产品线，没有编造参数。最有价值的是它把「审查服务商（包括自己）」做成第一条信任机制：vendor 清单里的「换人测试」（找没参与项目的懂行人凭交付资料接手）、「分手条款」（停止合作时工程文件/密码/账号移交）、「关键交付物未拿到前不付全款」是同题材里少见的实操粒度。三点建议：① §二 服务信息把真实手机号 13715298668 与公司名写死在包内，与「正文一律写占位符」并存——这个包本质是惠州物联网络的获客 prompt，其他主体复用前必须先清理身份区，建议把身份信息抽成独立可替换段；② 五层架构中基础层/设备层有 references 深化，但「场景层」没有对应交付物，§九 的场景愿望清单只有 7 个括号示例，建议补一份场景-触发-联动-面板映射模板；③ 第 52 行「按项目规模选主机（EA/Core 系列）」只给系列名，自称重点的「主机带载评估」没有任何数量级参考（多少设备/驱动该上 CA-10），建议补一张规模-主机对照小表。

111 行 SKILL.md + 75 行 references/document-standard.md + 197 行 scripts/create_work_plan.py，脚本与参考件都实读实跑。 **先说做对的：** 三包中工程习惯最好——① frontmatter 声明 dependency python-docx==1.1.0（同批另两个包都没声明依赖）；② 缺 title/sections 时打印「错误：JSON 缺少 …」并 exit 1，而供销社包缺 title 直接 KeyError 裸栈；③ 行距用 WD_LINE_SPACING.EXACTLY 显式设固定值，Normal 样式兜底仿宋；④ 落款 unit/date 右对齐实测写入成功；⑤ 章节数超 CN_NUM 表（20 个）时回退「21、」，实测第 21 章标题正常输出。 **硬伤一：「发言主题」是强制必备章节。** SKILL.md 第 22 行把「3. 发言主题」列入五大固定必备章节，第 34 行说明「必须原样保留，不得改写」，第 103 行禁止调换顺序，document-standard.md 第 40-42 行再次要求原样保留。但「发言主题」并不是工作方案的常规章节——这是发言稿/动员讲话类模板的章节残留，硬塞进方案框架且禁止改名，等于强迫每个工作方案都写一章不伦不类的「主题句总纲」。对一个自称「标准化」的技能，这个非标准章节是方法论级问题。 **硬伤二：页边距是 Word 默认值，却自称严格对齐规范。** description 声称「严格遵循党政机关公文格式规范」，SKILL 二（二）写「全自动适配以下 Word 公文版式参数，输出严格对齐规范」，但脚本 build() 从不设置 section 边距，实测产物 pgMar top=1440/bottom=1440/left=1800/right=1800 twips（2.54/3.17cm 的 Word 默认值），而公文国标是上 3.7/下 3.5/左 2.8/右 2.6cm。document-standard.md 的版式细则表也只字未提页边距。同批供销社包与红格包都设了国标边距，唯独这个主打「标准化」的包没有。 **硬伤三：docstring 里的 JSON 示例是非法 JSON。** 脚本第 17/20/21/22 行在示例里写了四处 // 注释（如第 17 行「"signature": …, // 可选」），json.loads 实测报「Expecting property name enclosed in double quotes: line 3 column 59」。SKILL 第 82 行说「结构见脚本说明」，照抄这份示例初始化 plan_content.json 会直接解析失败，首次运行必踩。 **改进建议：** ① 把「发言主题」降为可选章节或允许按场景改名；② build() 里补 section.top_margin/bottom_margin/left_margin/right_margin 四行国标边距；③ 删掉 docstring 示例里的 // 注释（字段说明移到注释行外）。

83 行 SKILL.md + 58 行 references/hongge_materials.md + 41 行 docx_format.md + 278 行 scripts/generate_docx.py。脚本实跑、素材库拿官方源逐条抽核。 **先说实测为真的：** ① 脚本是三包中最完整的——实测页边距 3.7/2.6/3.5/2.8cm 全对；主送机关顶格无缩进、落款 rightChars 右缩进 2 字符、抄送 20 磅行距+pBdr 上分隔线逐一落地；sign_date 留空自动取当天，实测写入「2026年10月15日」；字数统计即时打印（汉字 53+数字词 6）。② 素材库抽核大多对得上：太阳湖 504 亩/水域约 100 亩/投资约 5.7 亿与攀枝花人大官网、澎湃新闻报道一致；训练基地「全称四川省青少年体育活动中心（红格训练基地），亦称攀西亚高原体育训练基地」「四馆十场」「年平均气温约 20.5℃」「年日照时数超过 2700 小时」与四川省体育局页面一致；SKILL.md 第 81 行「不得声称已是国家级」的创建口径很谨慎。 **硬伤一：素材库核心数据与官方口径差 4 倍。** hongge_materials.md 第 28 行写「红格国际运动康养·温泉度假区规划面积约 5.5 平方公里」，而项目实施主体攀枝花太阳谷投资管理有限公司官网、四川省文旅厅页面、人民网报道均写规划总面积 24 平方公里（其中规划建设用地 10.23 平方公里）。素材库第 3 行自称「事实与口径的唯一依据」，照它生成的每篇文稿都会印出与官方差 4 倍多的数字——对一个以数据纪律立身的技能，这是致命伤。 **硬伤二：font_fallback 在 Windows 上静默失效。** SKILL.md 第 63 行承诺设 true 时「回退到本机可用中文字体」，但脚本第 74 行用 fc-list 检测字体——Windows 没有该命令，异常被吞成空串，resolve_font 第 88-89 行直接返回规范名。实测 font_fallback=true 的产物仍写方正小标宋简体/楷体_GB2312/仿宋_GB2312（本机三者均不存在，而回退链里的「仿宋/楷体」本可命中），终端只打一句「fc-list 不可用」。回退功能在最需要它的平台上等于没有。 **硬伤三（轻）：** 全文未声明 python-docx 依赖，SKILL 与 frontmatter 均未提安装（另两包都有说明或声明）；字数统计把 h1/h2 标题计入正文（脚本第 179 行），按「默认约 1200 字」核对篇幅会略高估。 **改进建议：** ① 第 28 行改为 24 平方公里并注明来源；② 字体检测补 Windows 分支（枚举 C:\Windows\Fonts 或 GDI API），失败时至少按回退链写入而非静默放弃；③ SKILL 补「pip install python-docx」；④ 字数统计分开打印含标题/纯正文两个数。

纯知识+脚本包：68 行 SKILL.md + 48 行 references/example.md + 105 行 scripts/build_docx.py。脚本我真跑了，产物 docx 逐项拆开验过。 **先记实测为真的部分：** ① 页边距是真的国标：实测产物 pgMar top=2098/right=1474/bottom=1984/left=1587 twips，换算 3.7/2.6/3.5/2.8cm，与 SKILL.md 第 53 行逐项吻合；② 行距 w:line=560、lineRule=exact，即固定值 28 磅；③ 空行规则按第 52 行落地：标题下空一行、章节之间空一行（实测 11 段里有 3 个空段位置全对）、二级段落之间不空行；④ example.md 第 41-48 行的结构说明把 title/intro/chapters/subheading 每个字段的字体归属写清，示例里所有数据都带【】占位符，与第 42 行「不随意编造数据」的纪律一致；⑤ chapters 传空数组也只出标题不崩。同批另两个公文包（工作方案、红格镇）页边距只有这个包设对了。 **硬伤一：没有落款。** example.md 的 JSON 结构（第 6-38 行）只有 title/intro/chapters 三个字段，脚本也没有署名/成文日期分支。年度工作报告是报送上级社、县委县政府的公文，落款（发文单位+成文日期）是基本要素——同批工作方案包有 signature 字段、红格包有 sign_org/sign_date 并支持日期自动取当天，唯独这个最像「正式公文」的包没有，用户拿到 docx 后只能手动补。 **硬伤二：没有页码。** 实测产物 document.xml 无 footerReference、无 PAGE 字段，包内也没有 footer 部件。党政机关公文格式（GB/T 9704-2012）要求 4 号半角宋体页码、单页右空一字双页左空一字，SKILL.md 声称「严格遵循党政机关公文格式」，页边距做对了，版记要素却整段缺位。 **硬伤三：字体既不检测也不提示。** 第 50 行与脚本第 26 行写死「仿宋_GB2312」，本机 C:\Windows\Fonts 实测没有该字体（simfang.ttf=仿宋 存在），Word 打开时会静默替换，用户无从察觉。对比同批红格包有 fc-list 检测+缺失提示+回退链、工作方案包直接用本机存在的「仿宋」，这是三包中唯一对字体风险零处理的。 **改进建议：** ① JSON 增加 signature 字段（对齐 e7dc8404 的实现，单位+日期右对齐即可）；② 用 sectPr/footer 加国标页码；③ SKILL.md 交付说明补一句「需本机安装仿宋_GB2312，缺失时会被 Word 替换为仿宋」，或给 set_run_font 加与红格包同款的回退链。

无脚本，是纯提示工程规格包：740 行 SKILL.md + references/ 下 commands.md（181）、quality-check.md（231）、state-library-schema.md（364）。三份引用文件与主文件我都读完并交叉核对、计数。 **体系完成度确实高：** H1-H5 逻辑硬校验在 SKILL.md 第 347-381 行与 quality-check.md 第 5-65 行逐条对得上；七维评分两处一致（P/C/D/W/E/S 各 15 分 + H 10 分 = 100）；`max_active_foreshadowing: 8`（schema 第 355 行）、`max_active_characters: 15`（第 356 行）、`summary_update_interval: 5`（第 354 行）分别对上 SKILL.md 第 719、726、463 行的「未回收伏笔超 8 条」「活跃人物超 15 人」「每 5 章更新总摘要」——参数有消费者的地方很干净。 **硬伤一：config.json 有两套，且默认值互相矛盾。** SKILL.md 第 95-108 行的模板是 11 个字段，state-library-schema.md 第 331-357 行是 22 个字段。冲突项：**schema 第 342 行 `total_volumes: 3`，而 SKILL.md 第 246 行公式 `总卷数 = CEIL(总章数/chapters_per_volume)` 在默认配置下算出 CEIL(25/20) = 2 卷**。后果很实际：SKILL.md 第 279 行要求「长篇伏笔（跨越 3 卷以上）：2-4 条」，在它自己算出的 2 卷结构里一条都排不出来。第二处：schema 第 341 行 `words_per_chapter_max: 6000`，SKILL.md 第 337 行写「每章 3,000–5,000 字（不低于 2,500 字）」，上限差 1,000 字。第三处：schema 有 `current_volume`/`current_chapter`，SKILL.md 模板里没有，可它自己的进度报告模板（第 581 行）又要输出 `{current_vol}/{total_vols}`。 **硬伤二：命令清单三个版本——15 条 / 13 条 / 12 条。** commands.md 按 A/B/C 三类定义了 15 条命令（A1-A5、B1-B4、C1-C6）；SKILL.md 第 680-696 行「命令路由总表」只有 13 行数据，缺 C5 设定查询与 C6 情节查询（「查设定」「查情节」「主线进度」在 SKILL.md 全文命中均为 0）；而 commands.md 自己的「可用命令」帮助块（第 176-181 行）只列 12 项，连 B4 小循环都漏了。另有 commands.md 第 70 行的 scope 表给了「最近/最新 → last」，SKILL.md 第 619 行「查摘要 {章节号/卷号/global}」的枚举里没有 last。 **硬伤三（轻）与衔接问题：** `quality_threshold: 70` 在 SKILL.md 只出现 1 次（第 104 行定义处），第 404-406 行的三档判定（≥80 通过 / 70-79 基本通过 / <70 重写）是硬编码的，改成 85 门禁不会变；`auto_save_interval` 同样只命中 1 次，2.9 节没提它。H3 时间线校验的回溯窗口也不统一：SKILL.md 第 363 行写「最后 3 条事件」，quality-check.md 第 36 行写「最后 5 条」。另 commands.md 在 SKILL.md 全文命中 0 次，是四份文件里唯一没有读取指引的；包根只有 longform-expander/ 子目录，SKILL.md 在子目录内，宿主按包根找入口会落空。 **改进建议：** ① config.json 定成单一来源（建议以 schema 为准），SKILL.md 第 95-108 行改为「字段见 references/state-library-schema.md」，total_volumes 改由公式推导、words_per_chapter_max 与第 337 行的 5,000 统一；② 命令清单收敛成一份，C5/C6 补进 SKILL.md 总表、小循环补进帮助块；③ 第 404-406 行的判定真正读取 quality_threshold，并给 auto_save_interval 指定落点；④ H3 回溯条数统一为 5 条。

纯知识型包：128 行 SKILL.md + 309 行 references/残疾人岗位培训知识库.md，无脚本。两个文件我逐行读完并做了计数核对。 **做扎实的地方：** ① 术语表目录实测 32 条（知识库第 7-38 行，编号 1-32 连续无缺号）； ② 三份模板货真价实且互相咬合——培训计划模板（第 67-111 行）的课程表 8+24+32+16+8=88 课时，满足 SKILL.md 第 68 行「就业技能培训不少于 80 课时」；岗位适配评估表的身体功能七项（第 126-132 行：上肢/下肢/视力/听力/言语/认知/耐力）与 SKILL.md 第 54 行评估流程列的七项**完全对齐**；回访表含 1/3/6 个月节奏，与第 77 行一致； ③ 两文件的数据口径没有打架：1.5%（及「如北京 1.7%」）、2000-5000 元/人/年、1000-3000 元/人/次、80/40/60 课时、就业率≥60%、满意度≥85%、超比例奖励 25%-50% 在 SKILL.md 与知识库 2.1/2.2 节取值相同。 **硬伤一（最重）：SKILL.md 点名要用的三份模板，它自己没给读取路径。** SKILL.md 第 109 行要求「涉及培训方案、评估表、回访记录时，主动提供结构化模板」，但三份模板**只存在于 references/残疾人岗位培训知识库.md 第 67-184 行**；`references`、`知识库`、`残疾人岗位培训知识库.md` 在 SKILL.md 全文**命中均为 0**。SKILL.md 的「核心能力模块」五节里也只有第 83、85 行的零星要点，没有任何一处指向该文件。结果是最该被消费的 309 行知识库没有入口，模型要么凭空造模板，要么漏掉这份唯一的资产。 **硬伤二：残保金的优惠条款缺了最关键的两条，导致它自己第 110 行承诺的「经济账」算不准。** SKILL.md 第 34 行的「残保金减免」只写了「安排达到比例可减免 + 超比例奖励」，第 33 行只给基础公式「（应安排人数-实际安排人数）× 上年职工平均工资」。而财政部公告 2023 年第 8 号（延续 2019 年第 98 号，执行至 2027-12-31）明确：**安排比例达 1%（含）以上但未达当地规定比例的，按应缴费额的 50% 缴纳；比例在 1% 以下的，按应缴费额的 90% 缴纳；在职职工 30 人（含）以下的企业继续免征**。技能面向企业 HR 且第 110 行要求「主动算『安排 X 名残疾人可省多少残保金+拿多少补贴退税』」，缺了分档系数与小微免征，比如「100 人企业、安排 0 人」这种最常见的咨询会直接把 90% 档答成全 100% 全额，数字一错，整个「用数字驱动决策」就反噬了。 **硬伤三：FAQ 表里 13 个问题号是空壳。** 知识库第 289 行写「**Q10-Q22：**（涵盖残疾人创业扶持政策、培训期间生活保障、职业技能鉴定、辅助性就业机构运营、残疾人社会保险补贴、劳动争议处理、心理疏导服务、企业融合文化建设、无障碍设施改造标准、新兴职业培训方向、AI+大数据在残疾人就业中的应用等）」——实测该文件实写问答只有 Q1-Q9 共 9 条，Q10 到 Q22 没有一条写成问答，而且这句括注只列了 11 个主题名，与 13 个问题号也对不上。这些恰恰是「创业扶持」「社保补贴」「劳动争议」等高频咨询点，SKILL.md 模块六（第 98-103 行）只有 6 行，唯一能补的 FAQ 又空着。 **次要：** 培训类别名称三处不统一——SKILL.md 第 68 行写「创业培训」，知识库 FAQ Q3（第 269 行）写「创业创新培训」，模板第 72 行选项写「□创业创新」；另外术语表第 14 条「合理便利」与第 38 条「合理调整」定义几乎同义（都是"为残疾人提供的必要工作和环境调整"），同一概念两个条目会输出两套说法。 **改进建议：** ① SKILL.md 里补一行读取指引（如「模板与术语见 references/残疾人岗位培训知识库.md，涉及培训方案/评估表/回访表时必读」），把知识库接进链路；② 第 34 行补残保金分档减缴（50%/90%）与 30 人以下免征两条，并注明依据为财政部公告 2023 年第 8 号；③ 把 Q10-Q22 补成真问答或直接改成「未覆盖，以当地政策为准」，不要留一个写着 13 个问题号却一个都没有的段落。

包内 103 行 SKILL.md + 90 行 references/rules.md + 692 行 scripts/a11y_doctor.py。我把脚本真跑了：selftest 报 138/138 全过，退出码四路、确定性、JSON 输出逐项验，另造了 6 个定向用例。 **先记实测为真的部分：** ① 退出码四路全对：空目录（无 .html）exit=3、只含 LOW 的页 exit=2、含任一 HIGH exit=1、干净页 exit=0，与 SKILL.md 第 21-28 行表格逐格一致； ② 确定性：对 examples/html/risky 连跑两次 `--json`，`cmp` 报字节一致； ③ `alt=""` 确实不报（SKILL.md 第 36 行说装饰图合规是**正确**写法）——我造 `<a href="#">返回顶部</a>` + `<img alt="">` 的页，只出 1 条 A11Y012，没有误报 A11Y001； ④ JSON 输出与 SKILL.md 第 72-85 行示例**逐字段吻合**：`files_scanned:4`、`elements:66`、`total:31`、`by_severity{HIGH:9,MED:16,LOW:6}`，且 by_rule 里 18 条规则计数相加恰为 31、与 by_severity 自洽——说明文档里那段 JSON 是真跑出来的，不是编的； ⑤ 片段文件确实跳过文档级规则：脚本第 35 行 `DOC_RULES = {"A11Y006","A11Y007","A11Y009","A11Y016"}` 与 SKILL.md 第 93 行声明的四条一一对上；selftest 的 CASES 列表实测 40 条元组，与第 103 行「40 组合成语料」一致。 **硬伤（本包最该改的一处）：`a11y-ok` 豁免会多豁免一个元素，并把 HIGH 静默吃掉。** 脚本第 82-89 行处理注释时，把规则集**同时**写进两个地方：`outer.line_suppress`（按行号，作用于本行）和 `outer.pending_suppress`（作用于下一个被创建的元素）；第 105 行 `_mk()` 给新元素挂上 `pending_suppress` 后第 106 行清零；第 214 行 `add()` 取的是二者并集。实测 `_t/exempt.html`（第 5 行 `<img src="c.png"><!-- a11y-ok: A11Y001 -->`、第 6 行 `<img src="d.png">`）：第 6 行的 d **不再上报**，判定从 BLOCK 掉成 WARN，也就是一条豁免注释静默盖掉了两个元素。我把第 6 行前插入一个 `<p>` 后再跑，d 恢复上报——证明泄漏对象是「下一个元素」而非「下一行」，即排好版（一标签一行）的真实 HTML 里必然触发。SKILL.md 第 68 行写的是「豁免范围只有「同一行」或「紧随其后的那一个元素」，不会整文件生效」，读起来是二选一，实为二者叠加。selftest 的两条豁免用例（脚本第 559、561 行）各自只含一个 img，正好绕开这个缺口，所以 138 项断言全过也没暴露它。 **次要问题：** `evaluation_cases.md`（58 行）与 `examples/html/`（7 个 html：benign 3 + risky 4）在 SKILL.md 全文命中 **0 次**，唯一被索引的资源是 references/rules.md（第 55 行）。这套正反例语料恰好是使用者做回归与验收的最佳材料，却没有读取入口。 **改进建议：** 尾随注释只写 `line_suppress`（或只写 `pending_suppress`），二选一即可修掉静默漏报；同时在 selftest 里补一条「同行尾随豁免 + 紧邻下一个同类元素」的用例锁死行为。另在 SKILL.md 末尾补 Resources 段，写明 evaluation_cases.md 与 examples/html/{benign,risky} 的用途。

包内 540 行的 scripts/db_course_tool.py 加两个 resources。我把 schema/insert/query/pyconn/check/report 七个子命令全部真跑，生成物还丢进真实引擎执行，以下都是实测。 正面：① 第 285-398 行给了三套能落地的连接实现（PyMySQL／psycopg2／sqlite3），`pyconn --db mysql` 实测输出带「需安装: pip install pymysql」的完整骨架，不是空壳；② `query --case 1..6` 六项与第 72 行「连接/聚合/子查询/视图/事务/索引建议」逐项对得上；③ `check --ddl "CREATE TABLE t (id INT)"` 实测返回三条具体问题（缺少主键／未检测到外键／缺分号），与第 74 行一致；④ `report` 实测生成报告 md，七章骨架与第 54 行一致。 硬伤一（最重，生成物跑不起来）：第 10 行承诺「给出可直接运行、可验证的建表 SQL」。但 gen_schema 把中文列注释裸拼在列定义后，生成的是 `id INTEGER PRIMARY KEY AUTOINCREMENT 用户编号,`、`username TEXT NOT NULL UNIQUE 用户名,`——没有 COMMENT 关键字（MySQL 写法）也没有 `-- ` 前缀。我把 takeout_schema_sqlite.sql 原样喂进 sqlite3.executescript，报 `OperationalError: near "用户编号": syntax error`，一句都执行不了；mysql／opengauss 两个方言文件同一格式。 硬伤二（建表顺序违反它自己第 34 行）：第 34 行明确「先父表后子表……避免外键引用未建表」。实测 takeout 顺序是 users→dishes→**orders**→order_items→**deliverers**，而 orders 里有 `deliverer_id ... REFERENCES deliverers(id)`，deliverers 排第 5 —— 子表先于父表，正是它自己禁止的情形（MySQL 下建到 orders 就会失败）。 硬伤三（承诺的触发器与存储过程是空的）：第 40 行写「是否含视图／触发器／存储过程／事务示例（query --case <N> 内含）」。实测全包 TRIGGER／PROCEDURE／DELIMITER 命中均为 0，「触发器」「存储过程」只出现在 SKILL.md 这两行本身；QUERIES 实际就 1-6：连接、聚合、子查询、视图、事务、索引建议。 硬伤四（事务示例硬编码 MySQL 专有函数）：第 261 行 case 5 用了 `VALUES (LAST_INSERT_ID(), 1, 1, 22.0)`。而第 23 行把 OpenGauss 列为目标库、第 62 行还给了 `schema --db opengauss` 示例，query 却没有 --db 参数 —— 用 OpenGauss 跑这段会因函数不存在直接失败。全包 LAST_INSERT_ID 仅此 1 处。 硬伤五（--rows 只能减不能加）：第 39／71 行说「--rows 控制条数」。实测 takeout：--rows 1 出 5 条、2 出 10 条、3 出 12 条，5/8/20/30 全部只出 12 条 —— 模板写死 12 条（users 2／dishes 3／orders 2／order_items 3／deliverers 2），第 228 行 `values[:rows]` 只能向下截断；默认值 8 已超全部模板长度，等于「全给」。 硬伤六（自检命令检查不了自己的产物）：第 74 行说 check「适合交作业前自检」。实测把 schema 生成的整个多表脚本喂给 `check --ddl`，返回「未匹配到 CREATE TABLE 语句」——第 406 行用 `re.match` 从字符串开头单条匹配，而脚本首行是 sqlite 方言注释，必然失配。 改进建议：① 列注释改为独立注释行或按方言用 COMMENT；② 按外键依赖拓扑排序，把 deliverers 提到 orders 之前；③ 第 40 行删掉「触发器／存储过程」或补 case 7/8 真给出示例；④ case 5 按方言分支 LAST_INSERT_ID()／RETURNING id；⑤ 把 --rows 改述为「每表上限，受模板条数封顶」；⑥ check 改用 re.finditer 支持多表带注释脚本。

278 行 SKILL.md 加 12 个 references/assets 文件加 2 个上传脚本（Python 242 行、Node 版），我逐个打开核对，并数了两处可数声明。 先说真材实料：① 第 161 行号称的「100 条金句素材库」是真的，我按第 163/198/223/258/273 行五个分组逐条数编号：30+20+30+10+10，恰好 100 条，一条不少；② Step 4 的上传脚本 upload_to_wechat.py 第 8-13 行只 import json/os/re/sys/urllib.request/mimetypes，**零第三方依赖**（纯标准库），第 24/34/61/88/110/121 行的函数与第 213-220 行描述的六步（取 token→下载远程图→uploadimg→替换链接→add_material 传封面→draft/add）能逐条对上，比同题材包里那些只写一句「调用某技能上传」的诚实得多；③ 第 179-198 行的设计系统确实是 A/B/C/D 四套方案（知性杂志风／极简黑白／暖调治愈／冷静商务），与第 155 行「默认方案 A 知性杂志风」一致；④ 微信白名单自检 8 条（第 168-175 行）都是可机械判定的（禁 script/style/link/iframe、禁 position/z-index/!important/id、样式必须内联、img 必须带 width+height、单位只 px/em）。 硬伤一（阈值自相矛盾）：第 90 行语言检查写「"从来不是…而是…"句式：全文 ≥ 5 处」，第 100 行自检十条铁律第 3 条又写「"从来不是…而是…"用了吗？全文对比 ≥ 10 处吗？」——同一条句式两个阈值（5 与 10），且第 100 行把「句式出现数」表述成「全文对比 ≥ 10 处」，两处口径混在一起。写稿时到底照 5 还是 10，SKILL.md 自己没裁决。 硬伤二（组件数多算一个）：第 199 行与第 257 行两处都写「14 个微信安全 HTML 组件模板」。实测 references/wechat-design/组件库.md 是 13 个组件（## 1. 文章标题区 到 ## 13. 引导关注区），第 148 行是「## 使用规则」不是组件。13 写成 14。 硬伤三（三个文件没进索引，等于白放）：第 250-253 行 Resources 总览把 references/chen-dong-style/ 列成 3 个文件、assets 列成 3 个，实测该目录有 5 个 md、assets 有 4 个。没被 SKILL.md 提到的是 references/chen-dong-style/常用句式.md（270 行）、references/chen-dong-style/风格特征详解.md（104 行）、assets/范文深度拆解.md（133 行）——其中 常用句式.md 体量与被索引的 风格深度分析.md（274 行）相当，却没给「何时读取」，智能体不会去读。 硬伤四（包根无入口）：包根只有 skill_gzh-one-stop/ 一个子目录，SKILL.md 在子目录里，宿主按包根找入口时会落空（同批另一份公文技能也这样）。 改进建议：① 第 90 行与第 100 行统一成一个阈值（建议 5，并在铁律里改成「句式出现 ≥ 5 处」）；② 第 199/257 行的「14 个」改 13，或把 使用规则 也做成组件补齐第 14 个；③ 在第 250-253 行补上 常用句式.md（用于句式查重与替换）、风格特征详解.md、范文深度拆解.md 三行的「何时读取」；④ 把 SKILL.md 提到包根。

包里有真脚本 scripts/report_builder.py（216 行，仅标准库），我用 14 组输入实跑，README 第 14 行自称已测试 4 组场景，实测官方 4 套与边界输入全部跑通，以下都是实测。 先说三点扎实的：① references 与脚本模板逐页对齐——industry-templates.md 的 A 至 F 六套模板页码、每页章节名与脚本 TEMPLATE_STRUCTURE 逐条一致，我按模板 ID 逐页比对无一处偏差；② 页码全部连续无跳号（A/B/C/E 各 10 页、D 9 页、F 5 页），SKILL 第 52 行「大纲页码连续无跳号」的自检项确有实现支撑；③ 第 209-216 行的异常兜底返回结构化 JSON 并 exit 1，缺口不藏在 traceback 里。 硬伤一：把 IT 输进去会拿到周报模板。第 16 行的行业枚举原文是「互联网与IT」，我用 --industry IT --type 述职 实跑，返回 template=F（5 页：概览/关键进展/数据表现/问题与阻塞/下期计划），而正确结果应是 D（9 页：封面/关键指标/产品研发成果）；改成「互联网」「互联网与IT」都正确返回 D。根因在第 148-153 行：代码只把输入转小写（strip().lower()），字典键却是大写 IT，key in norm_industry 与 norm_industry in key 两个方向都因大小写失配，最终落回兜底 F。建议第 151 行比较时两边都 lower（第 150 行是 for 循环行）。 硬伤二：汇报类型不做 strip，一个尾随空格就换模板。第 143 行直接 TYPE_TEMPLATES.get(report_type)，与第 148 行对 industry 的 strip().lower() 处理不一致。实测 --type '周报 ' 返回 A（10 页电商述职），而 --type 周报 返回 F（5 页）——同一意图两个模板。 硬伤三：同义词不在枚举内就静默回退到行业模板。实测「工程 + 投标方案」返回 C（10 页工程项目汇报）而非 E（投标初稿），因为第 33-43 行的键只收「投标」「投标初稿」；而 README 第 102 行的运营推广文案写的是「投标PPT」（第 39 行的测试场景又写「投标初稿」），用户照推广文案的口吻提问就会拿到错的骨架。 硬伤四：篇幅口径自相矛盾。report-logic-framework.md 第 44 行规定「述职 10-14 页、项目汇报 8-12 页、年度复盘 12-16 页、投标初稿 12-15 页、周报 5-7 页」，而脚本能给的最大页数实测是 D=9、A/B/C/E=10，于是年度复盘（要求 12-16）与投标初稿（要求 12-15）无论怎么输入都够不到下限；「12-16」「12-15」两个数字全包各只出现 1 次（就是这一行），脚本与模板里没有任何对应结构。 硬伤五：周报/月报模板既无封面也无结语。F 模板实测 5 页为 概览/关键进展/数据表现/问题与阻塞/下期计划，而 SKILL 第 52 行要求自检「章节闭环（有开头有结语）」、industry-templates.md 第 103 行要求保持「封面-正文-结语」闭环——周报和月报这两种类型结构性过不了自家自检。建议给 F 补 P1 封面与末页结语，或把该自检项限定到 A 至 E。 另有三处小伤：① 第 42 行的唯一大纲示例写「P1 封面、P2 目录……」，但「目录」在 references 与脚本里各 0 次命中，六套模板的 P2 分别是 业绩总览/产量总览/项目概况/关键指标/公司简介/关键进展，没有一套有目录页；② 第 18 行要求项目简述「3-10 句话」，脚本第 165 行只判长度小于 10 个字符——实测「本月生产计划完成情况」这 10 个字就让 input_check.complete 变为 True，而 8 个字的描述被判缺失，第 2 步「若脚本提示缺失字段，先补齐再继续」的闸门远松于文档口径；③ 第 19 行说核心数据建议提供、缺失可标注数据待补充，但脚本把它计入 missing_fields 使 complete 恒为 False，而第 28 行又要求不要跳过校验直接输出，无数据场景两头堵。图表选型也只认关键词：实测数据「留存 40%」未命中任何一类、落到兜底「表格/指标卡」，写成「留存占比 40%」才命中饼图——选型取决于有没有「占比」二字而非数据性质，关键词表里也没有留存/复购/客单价/毛利率这类汇报高频指标，建议补进去。

纯知识型技能（可读资产只有 SKILL.md 336 行、ima-template.md 67 行、example_dialogue.md 89 行、README.md 82 行），我全文读完并逐项计数核对。 三处正面证据：① 标签词库对得上——ima-template.md 第 37-51 行声明「固定 15 个概念词」，逐个点名核对恰为 15 个，与 SKILL 第 241 行「固定 15 词」、第 315 行「15 个标签里」完全一致；② 唯一示范的元信息全部合规——example_dialogue.md 第 73-75 行给的 #货币政策 #宏观传导 #现金流 三个标签全在词库内、数量不超过 3，所属 03_宏观框架 与模块表的 5 个模块对得上，落盘路径「知识体系/03_宏观框架/小岛经济学_知识条目_IMA版.md」也与第 64 行的命名规则一致；③ 第 193 行「同一缺失不得同时影响两个维度」这种防重复扣分的互斥规则，在评测类技能里属稀缺设计。 硬伤一（最要命）：全包唯一的示范与它自己强制的输出格式是两套东西。SKILL 第 206-219 行规定五维评分按「因果链完整度：X/5 —— 扣分理由：……」一次性给出、以「总分：XX/25 —— 掌握状况：XXX —— 下次复习：X天后」收尾；而 example_dialogue.md 第 42-51 行标着「进入老师五维复盘（一次性给完）」，输出的却是「你理解到位的」「要修正/补精确的」「遗漏的关键点」「知识连接」「实战对应」五条定性描述。实测该文件里 X/5 形式的分值命中 0 次，一个分数、一条扣分理由都没有。更麻烦的是这五条的名字与 ima-template.md 第 55 行明令禁止的五段式（我的理解／核心要点／和已有知识的连接／实战怎么用／待验证）逐条对应，而示例开头第 4 行自己写着「AI 看这段比看抽象规则更能把握分寸」——等于用最强的语气把模型引向它禁止的形态，五维评分、掌握度评估、进度记录三件成品大概率不会出现。建议把第 42-51 行整段改写成规范格式的五维评分样板。 硬伤二：两处回写目标在模板里不存在。第 229 行要求把联考暴露的新洞察回写到 IMA 条目的「核心收获」或「实战对应」小节，第 239 行要求「掌握度评估」小节放在「核心收获」之后；而 ima-template.md 全文「核心收获」0 命中、「掌握度评估」也是 0 命中（SKILL 里则有 8 次），模板第 55 条又只允许按自然推导展开、禁止固定分段——三处指令都指向一个没有落点的位置。 硬伤三：要不要建日程，三处声明互相打架。第 66 行流程图与 Step 8（第 273-279 行）都写「追问完成后，创建下一个晚8点日程」，是无条件创建；而第 247-251 行复习提醒一节却写「默认不自动创建日程；用户明确要提醒时，再按平台日程/脚本规则处理，不擅自挂载」，README 第 64 行也写「默认不自动建日程」、第 73 行还把它归为「依赖 WorkBuddy 的定时自动化能力……不强制集成」。同时 SKILL 正文（含第 283-291 行定时触发边界处理表的 4 行）对「Calendar 能力不存在」没有任何降级，降级只写在 README 第 71 行一句；而模型实际加载的是 SKILL.md，第 33 行已经把「每周一、四、六晚8点日程触发」列为触发条件。建议 Step 8 改成「仅当用户明确要求提醒时创建」，或在边界处理表补一行「无 Calendar 能力 → 提示用户改为主动说可以开始追问了」。 硬伤四：Step 编号错位。流程图（第 118-140 行）列到「Step 7 创建下一个晚8点日程」，正文小节却把「进度记录输出」编成 Step 7（第 254 行）、把创建日程编成 Step 8（第 273 行）——同一动作两个编号，全包 Step 编号实测出现 0 至 8 共 9 个；第 137 行「Step 6 对话末尾独立输出一行进度记录」与第 254 行的 Step 7 也对不上。 两处小伤：① 复习间隔末档口径不一——第 202 行写「12 以下｜需重学｜1 天后」，README 第 42 和 64 行写「<12→1天」；中文「12 以下」通常含 12，与第 201 行「12-16｜有漏洞｜3 天后」重叠，12 分该走哪档无法判定，建议统一写成「<12」；② 第 191 行要求某维度满分必须说明为什么能拿满分，但第 208-216 行的强制输出格式每个维度只留了「扣分理由」一栏，第 218-219 行只覆盖五维全满分这一种情形，4 个维度满分时这句说明无处可写，建议在格式里给每维补一个可选的满分说明位。

包里有真脚本 scripts/build_docx.py（229 行，依赖 python-docx）＋examples/sample_content.json ＋一份作者自己生成的示例 .docx。我按 SKILL 第 86-99 行的 schema 实跑，并把作者自带的示例 docx 回读逐段核对，以下都是实测。 先说最扎实的一点：生成物与声明逐项对得上，而且自带示例就是脚本产物。我把 sample_content.json 喂进脚本新生成 out1.docx，与包内《【单位名称】安全生产专项整治工作方案_示例.docx》逐段比对：段数均 50、50/50 段文字完全相同；回读 XML 得到（中文字体, 字号）→段数 = {黑体 22pt:1, 黑体 16pt:6, 楷体 16pt:15, 仿宋_GB2312 16pt:28}，firstLineChars→段数 = {200:41, 无:9}（9 段无缩进 = 1 标题 ＋ 6 个章节空行 ＋ 2 行落款，正好对上）；全文行距实测固定 28 磅无例外。第 33-39 行那 7 条格式声明，除标题字体外条条可复核。页边距也一致：第 42 行写「上 3.7cm、下 3.5cm、左 2.8cm、右 2.6cm」，与 GB/T 9704-2012 规定的 37/35/28/26mm 完全吻合，脚本第 117-122 行逐项落实。失败分支干净：章节名或顺序不符时报 ValueError: 一级章节名称/顺序不符合规范，并打印应为与实际两串，退出码非 0 且不残留半成品 docx。 硬伤一（最影响可信度）：文档给的命令根本不触发校验。第 80 行的命令是 scripts/build_docx.py --input content.json --output 方案.docx，没有 --verify；第 81 行却承诺「脚本会回读校验字体、字号、28 磅固定行距、首行缩进、章节空行；确认全部通过」。实测照第 80 行原样跑，exit=0、stdout 只有一行「已生成：…」，一条校验都没有（--verify 全包仅 1 次命中，就是第 195 行的参数定义）。 硬伤二：就算加上 --verify，它也没查自己承诺的那几项。实测输出只有四行：标题黑体二号不加粗居中 = True、全文固定行距28磅 = True、出现的中文字体 = ['仿宋_GB2312','楷体','黑体']、空行段落数 = 6。其中一级/二级/正文的字号、首行缩进、章节空行数都只是打印观察值，没有通过与否，也不影响退出码——上面那 50 段的真实字号与缩进是我另写回读脚本才拿到的。建议第 204-225 行改成逐项断言：正文段 eastAsia 必须等于仿宋_GB2312 且字号 16pt、非空非落款段 firstLineChars 必须等于 200、空行数必须等于章节数减 1 再加落款 1，任一不符就打印失败并 sys.exit(1)。 硬伤三：正文指定的仿宋_GB2312 本机不存在。用 utf-16-be 字节检索 C:\Windows\Fonts：simfang.ttf 是仿宋、simkai.ttf 是楷体、simhei.ttf 是黑体、simsun.ttc 是宋体，都命中；而「仿宋_GB2312」「楷体_GB2312」0 命中，文件名含 gb2312 的字体文件 0 个。所以交付的 docx 正文会在 Word 里被静默替换成默认字体，而全包「降级」「替代」各 0 命中，第 111 行的人工校验清单还要求确认「正文仿宋_GB2312 三号」——这一项要么永远过不了，要么被跳过。建议脚本加字体可用性探测（找不到就退回「仿宋」并在 stdout 明确提示），或至少在 SKILL 第 36 行注明该字体需自行安装。 一处与自称不符：第 29 行自称严格 Word 国标格式，第 33 行与脚本第 29、34 行（黑体 + 22pt）把文档标题定为黑体二号，而 GB/T 9704-2012 第 7.3.1 条原文是「标题 一般用 2 号小标宋体字」，全包「小标宋」0 命中。考虑到本机小标宋也确实 0 命中（方正系只有 FZXKJW.TTF 方正行楷），选黑体是务实的，但既然把国标写进卖点，就该补一句取舍说明。另外，包内唯一示例同时也是它的资质背书样稿，正文实测 1596 字符、1342 汉字，与第 71 行「篇幅默认 3000-5000 字」差一倍以上，建议标注示例为结构演示、篇幅另按下限生成。

包里有真脚本：scripts/naming_generator.py（263 行）＋assets/poetry_corpus.json（133 条，诗经 31／楚辞 27／唐诗 43／宋词 32）＋assets/char_meanings.json（152 字）。我按它声明的依赖装了 pypinyin==0.55.0，把文档三个示例逐个真跑，以下都是实测。 三处做得扎实：① 没有「一键出稿」式空承诺，第 72 行专门写明 pypinyin 缺失时脚本输出 pinyin_available: false 并警告、「必须停止撰写音律说明」——我卸掉 pypinyin 复跑，确实返回 pinyin_available: false＋warning、tones/tones_spoken 全为 0，这条防护真实存在；② 第 212-232 行的出处轮询确实按诗经/楚辞/唐诗/宋词各取一条循环，示例 1 的 5 个候选依次落在诗经·小雅天保→楚辞·九歌湘夫人→唐诗·暮江吟→宋词·摸鱼儿→诗经·采薇，多出处覆盖不是自称；③ 第 41-44 行的累计排除实测有效，--avoid 一,日 后 6 个候选里这两个字零出现，--exclude 日升,赫咺,修远 后三个名字确实被剔除、query 回显「修远、赫咺、日升」。 硬伤一（最重，姓氏注音全错）：第 96-106 行 full_reading 用 pinyin(姓氏+given) 整体注音，只给 given 准备了一张 4 条的覆盖表（第 40-45 行，长风/长天/一帆/一川），姓氏完全不校正。实测 10 个多音字姓氏全部读错：曾→ceng2（应 zēng）、仇→chou2（qiú）、单→dan1（shàn）、解→jie3（xiè）、朴→pu3（piáo）、区→qu1（ōu）、查→cha2（zhā）、华→hua2（huà）、任→ren4（rén）、乐→le4（yuè）。而第 31／67 行要求音律说明「以 tones_spoken 为准」，姓氏是全名第一个音，首音声调错，整段音律描述就跟着错。 硬伤二（示例产出与脚本实现互相否定）：第 49 行示例 1 把「王窈窕（《诗经·关雎》）」写成预期产出，但语料里窈窕被标记 unsuitable_as_name: true（被标记的 4 条是窈窕／契阔／袅袅／任平生），脚本第 55-56 行明确跳过。我穷举「诗经／女／温婉」拿满 24 个候选，窈窕出现 0 次（静姝出现了）。第 69 行又写「语料中 unsuitable_as_name: true 的条目……已被脚本自动跳过」——同一份文档既把它当产出示例、又说它会被跳过。 硬伤三（字义词典缺 30 字，char_meaning 出现空串）：第 30 行要求「依据脚本输出的 note 与 char_meaning 撰写寓意解析」。实测 129 条可用候选涉及 173 个不重复字，词典只有 152 条，缺 30 字（一万东亭冰剑君宜形心春暗来深满申盈相稻空绿者莫蓬起连长闲阳黍）。实测输出里李长河的 char_meaning 是「长」为空串、「河」有释义，李穿空的「空」为空串，林宜修的「宜」为空串——智能体拿到空值只能漏掉该字或自行补写，而第 66 行恰好禁止手工编造出处与释义。 硬伤四（非法参数静默降级、无任何提示）：第 22 行只写 sex 取「男／女／中性」，未写非法值处理。实测 --sex 男性 --style 温婉婉 不报错，query 回显 sex: neutral、style: neutral，status 仍 success 照常出候选——用户说「男性」（最自然的说法）会静默丢掉性别约束。同因，--include-source 元曲 返回 status: success ＋ 候选空数组，不报错不提示，而第 36 行也没写无匹配出处时怎么办，智能体容易把空数组当成「该出处没有合适的名字」直接交付。 改进建议：① 把第 40 行那张覆盖表扩到姓氏（新增姓氏多音字读音表，或改用姓氏专用注音），至少在结果里回显「姓氏读音按 X 处理」；② 第 49 行示例产出换成脚本真能给出的（如王静姝、王月恒），或去掉窈窕的 unsuitable 标记；③ 给 char_meanings.json 补齐缺的 30 字，或在候选对象里加 char_meaning_missing 字段提示缺字；④ 第 22／36 行补非法值处理——参数不在枚举内时报错退出，或明确回显「已按中性处理」。

单文件 89 行，无 scripts、无 references、无政策数据文件，四个业务模块（谋划／包装／进度跟踪／调度）加三张 Markdown 表模板。亮点是模块要求与表格字段真的对齐了：第43行要求谋划项目跟踪前期手续进展（立项、可研、规划、用地、环评等手续阶段），第67行谋划项目进度跟踪表表头恰好就是序号加这五列，共 10 列、分隔行列数逐一对齐；第44行要求在建项目跟踪「工程实体工程量推进情况、资金投资完成情况」，第72行表头给了总投资、年度计划投资、累计完成投资、实体工程量进展、形象进度五列，共 9 列、同样对齐；第62行项目包装表 8 列与第29-35行的 7 个必填字段加序号一一对应。要求与字段不脱节这一点，同题材包里少见。三处硬伤：①最硬的是负面清单成了空要求。第23、30、37、54、80行共 5 处要求「规避政策负面清单」「严格规避负面清单相关表述」「不得出现政策负面清单表述」「严控负面清单表述」以及校验时检查是否触碰负面清单，而全包没有任何一条负面清单条目、没有文件名、没有来源（「链接」「数据来源」各 0 命中）；两处问询清单——第79行「对应政策文件、资金投向、所属区域、产业方向」与第87行「适用政策、属地、产业方向、资金申报类型」——也都没有把负面清单列为输入项。于是这 5 处校验没有任何输入来源，模型只能靠自己的先验猜，而第83行又写着「不编造不存在的政策，不虚构项目落地条件」。建议把负面清单具名化（点名依据文件与适用层级），或在第79、87行把负面清单口径加进必问项。②第35行把项目联系人的要求写成「可填写姓名 + 联系电话占位」，而模块 5（第52行）与 description 的交付定位是可直接复制粘贴到 Excel 的申报条目——占位联系人进了正式申报表就是废项。建议缺项时表内写「待补」，并在调度报告的问题清单里单列一条缺口。③第10行与第52行口径不一：第10行说「最终输出结构化 Excel 表格内容」，第52行说「输出载体：Excel 表格，输出时先输出表格表头 + Markdown 表格内容」——声明载体是 Excel、实际交付 Markdown（全包 Excel 共 5 处命中，全是表述、没有对应实现）。建议第10行改为「输出可粘贴进 Excel 的 Markdown 表格」。小伤两处：第31行「建设年限：项目开工至竣工时间，起止年份合理」与第33行资金类型列举「中央预算内资金、专项债、省级专项资金等」都没有判据，何谓合理年限、三类资金各适用什么条件全无规则，第80行的校验只能主观；第50行把「输出规范」编为「核心工作模块」的第 5 个模块，与前四个真业务模块性质不同，第56行又另起「推荐表格模板」一节，结构上夹在中间。建议给建设年限与资金类型各补一句可执行判据。

单文件 60 行的定制型包，无 scripts、无 references，第59行明确「本Skill仅用于生成盐边县人民医院新院区搬迁宣传工作方案，不用于撰写其他无关公文」——本质是一次性交付件，通用性很低。两处做得好：第22-25行的三期宣传节点（前期预热造势、中期试运行宣传、后期特色专科）与第31行实施步骤的三个二级小节逐字对应，第16-25行业务要点与第60行关键信息清单（两院整合、一院两区、视频号加公众号双渠道、红格儿科、皮肤医学美容中心）也基本闭合；第52行只说「文末附带独立板块【Word排版设置说明】……文本可直接复制粘贴到Microsoft Word进行排版」，没有像同题材包那样承诺「一键成型」，口径诚实。四处硬伤：①第38行一级标题与第39行二级标题都写「宋体小三号」，字体字号完全相同（小三号全包仅 2 处命中，就是这两行），两级标题在纸面上无法区分，只能靠「一、」和「（一）」的编号辨认，而同题材公文包一级标题一般用黑体或更大字号。建议一级改宋体三号加粗或黑体小三号。②第39行给二级标题的示例是「（一）政策依据」，但本方案的固定章节是指导思想、目标任务、实施步骤、保障措施、工作要求，实施步骤下的小节是前期造势氛围营造、中期试运行宣传、后期特色专科宣传——「政策依据」全包仅 1 次命中（就是这行示例本身），既不属于本方案任何章节也不在其下，是从别的公文模板抄来的残留。用户照示例写二级标题，就会写出一个本方案根本没有的章节。建议改为「（一）前期造势氛围营造」。③第40行正文指定「仿宋_GB2312四号字」，全文「降级」「替代」各 0 命中；实测本机 Fonts 目录下 simfang.ttf 族名为 仿宋/FangSong、simkai.ttf 为 楷体/KaiTi、simhei.ttf 为 黑体/SimHei、simsun.ttc 为 宋体/SimSun，确实没有带 GB2312 字样的字体文件——也就是说宋体标题没问题，但正文在默认 Windows 上按第52行说明逐项设置时会被 Word 静默替换字体。建议补一句「环境无仿宋_GB2312 时改用仿宋并告知用户」。④全文「落款」「日期」「印发」「署名」「印章」命中均为 0，第27-33行的固定章节框架里也没有落款位，而第14行要求「严格遵守下文给定业务要点、固定章节结构、Word排版规范、公文文风要求」——成文单位与成文日期这个公文体式要件在输出规则里完全没有位置。建议在章节框架末尾补落款位，或至少在【Word排版设置说明】里给落款右对齐与日期写法规则。小伤：第46行把「为深入贯彻……精神，切实推进……工作，特制定本方案。」定为方案开篇必须使用的句式，第48行又要求「避免空洞套话堆砌」，强制起句本身就是套话结构，两条互斥，建议把起句改成可选或允许实质性开头。

纯知识型但知识库质量明显高于同类：assets/装修先查词元库.md 实测 88 条，编号 001-088 连续、无缺号无重号（逐条正则提取验证），每条 判断/依据/出处/可转述 四行全部齐全（各 88/88），其中 80 条给出可点的 http 原始链接、8 条是「（同0xx）」内部互引。更难得的是 SKILL.md 三处示例点名的词元 014/041/032/062/063/066/068 逐个回库核对全部存在且内容对口——词元 014 的判断行里就摆着「599元/㎡全包」这个具体价位。法条抽查也站得住：词元 002 引《住宅室内装饰装修管理办法》第22条资质审查、003 引第36条「处500-1000元罚款」、051 引第32条「有防水要求的厨房、卫生间和外墙面的防渗漏为五年」、052 引同条「最低保修期限为二年」，与办法原文一致，符合它第33行自己写的「绝不编造法条号、案例、链接」。三处硬伤：①时效字段 88/88 全为「待复核」，是全库唯一取值（其它取值集合为空），而第41行要求「标注词元时效」，输出里每条都会印同一句话，这个字段零信息量；可引源跨度却从 2010（词元016 中国新闻网）到 2026，一条十六年前的媒体提示与 2026 年的行政处罚案例标着同样的时效置信度。建议按时效分档（三年内／三至十年／十年以上），或至少给 007/016/020/072 这几条旧源加一句「源较早，以现行规范为准」。②词元 040 与 086 同名「返工担责」，依据同引第29条，可转述逐字相同（都是「需要返工的，费用不该让你再掏一次。」），只有分类前缀不同（C验材核料 / F存证维权）——一份合同同时命中时会输出两段一模一样的【判断】。建议 086 改从 F 组自身角度写，比如已完工价值评估或举证责任。③第72行专门设了一条防护「词元出处中个别机构名/域名含占位符（如），须提示用户复核原始链接」，而实测全库占位符出现 0 次，这条规则防的是不存在的情况；真正存在的瑕疵反倒没提示：词元 006、021 两条出处用的是人民网 BIG5 繁体镜像路径（gx.people.com.cn/BIG5/、he.people.com.cn/BIG5/），用户点开是繁体页。建议把第72行换成「BIG5/繁体镜像链接需替换为简体源」。另发现一层分层没有接线：场景字段实为「动作·子场景」两级，A选企识人下再分查照验资 5 条、查信辨誉 4 条、盯人防换 4 条，全库合计 18 个子场景；而六个动作组里 B审价辨单 18 条、D读约抠字 21 条是最大的两组。这 18 个子场景名在 SKILL.md 命中全为 0（第24、67行只声明 6 个动作），输出也只按 6 动作分组。建议第67行补一句子场景清单，或在【判断】后附一个子场景标签。

包内仅 SKILL.md（88 行 / 6263 字节），无 scripts。这是三份同类里唯一带完整政策知识库的，我把关键政策条目逐条对了中国政府网 2025 年 7 月《育儿补贴制度实施方案》原文再评。 正面先记：第 28 行「免征个人所得税」「认定低保、特困等救助家庭收入时，育儿补贴不计入家庭收入」与国家方案原文一致；第 30-34 行申请、审核、发放三段时限自成体系；第 49-59 行终止情形 5 条加追回条款完整，作为乡镇级政策答疑库结构是合格的。 硬伤一（最重，适用对象把折算人群整体排除）：第 22 行写「2025年1月1日后合法生育或收养」。国家方案原文是「从2025年1月1日起，对符合法律法规规定生育的3周岁以下婴幼儿发放补贴」，并明确「对2025年1月1日之前出生、不满3周岁的婴幼儿，按应补贴月数折算计发补贴」（人民网政策解读进一步说明 2022 年 1 月 1 日以后出生的符合条件婴幼儿都可领）。该技能把制度实施日误写成了出生日门槛，2022-2024 年出生、未满 3 周岁的孩子来咨询会被判不符合，而实际可按月折算申领；「1月1日后」的字面还把 2025-01-01 当日出生的排除掉（原文是「起」、含当日）。对一份政策答疑知识库，这是方向性错误。 硬伤二（申报渠道与自己列的依据打架）：第 42 行写该补贴「仅支持线上申报」，而第 16 行列为依据 1 的国家方案原文是「主要通过育儿补贴信息管理系统线上申请，也可线下申请」，国新办发布会明确「保留线下办理渠道和人工服务」；第 38 行入口只写支付宝、微信小程序，未提全国统一信息管理系统和省级政务服务平台专区。 硬伤三（标准只剩「一孩」一条）：第 26 行补贴标准只有「1. 一孩」一条，无二孩三孩条目，而国家方案明确一、二、三孩同标准（发布会原话「不分一孩、二孩或者三孩」）；「一孩」标签与「每孩每年3600元」自相矛盾，二孩家庭按此库答疑拿不到答案。另外第 63-66 行格式块（一级示例「工作背景」、二级示例「（一）政策依据」、仿宋三号 28 磅）与同批法院简报技能逐项同构，属同一模板出包。 改进建议：① 第 22 行改为 2022年1月1日（含）后出生、申领时未满 3 周岁，并补一句 2025 年 1 月 1 日前出生的按应补贴月数折算计发；② 第 42 行改为以线上申报为主、也可线下申请；③ 第 26 行删「一孩」标签，改为符合条件婴幼儿（不分孩次）每孩每年 3600 元。

包结构先记一笔：唯一文件嵌在 court-briefing-assistant/ 子目录里，包根没有 SKILL.md（同批另两份公文技能都平铺在包根），宿主能否按包根找到入口取决于平台解析，这一点与其他包不一致。SKILL.md 共 79 行 / 3314 字节，无 scripts，以下基于逐行读文档。 正面：约束边界是同类里保密意识最强的，第 77 行严禁编造不存在的文件、领导讲话、案件数据，第 78 行专门要求提醒用户做好涉密内容审核；第 42 行范式「本院组织开展……」贴合法院主体。 硬伤一（附加板块没有落点）：第 56-59 行采集清单第 4 项让用户在 B「下一步工作计划」、C「典型案例简述」两个附加板块里选，但第 16 行规定文稿必须包含「三大标准章节」、第 21 行又允许「可根据业务实际增设二级条目」——B/C 是独立板块，放在「取得的成效」之后算不算新增一级章节？挂在哪个核心章节下当二级条目？全文没有层级与位置规则，模型每次生成只能猜，两份同样选 B 的简报可能一版四章节、一版两章节。 硬伤二（样式标注机制自相矛盾）：第 25 行「输出时标注清楚样式，用户复制进 Word 一键设置」与第 36 行「文稿输出完成后，在文末增加【Word 排版设置说明】」是两种互斥机制：若按第 25 行在正文内标注，正文被样式标记污染，直接违背第 73 行「可直接复制粘贴」的卖点；若只在文末说明，第 25 行就是空话。同批一份乡镇育儿补贴技能的输出规则里明确写了「不输出 Markdown 标题符号，公文正文为纯文本，格式说明单独标注」，这份恰好缺了这句裁决规则。 硬伤三（选择题规则覆盖不了清单）：第 50 行「采用选择题形式向用户收集必要信息」，但清单 4 项里只有第 4 项是选择题，法院名称、事件主题、时间段天然是自由文本，3/4 的项无法按规则执行。 模板痕迹：第 31 行二级标题示例是「（一）政策依据」，而它自己的三大章节（工作背景/工作或活动内容/取得的成效）里没有任何位置会自然出现这个二级标题；同批一份乡镇育儿补贴技能的公文结构第二部分恰好就叫「政策依据」，两包还共用同一组格式参数（黑体二号标题、黑体三号一级、楷体三号二级、仿宋三号 28 磅、首行缩进 2 字符），可判同一模板出包，法院包沿用了政务包的示例没有改。 改进建议：① 第 21 行后补一句：附加板块 B、C 作为新增一级章节排在「取得的成效」之后，编号顺延；② 第 25 行改为正文内不标注任何样式标记，样式要求统一写入文末的【Word 排版设置说明】；③ 第 31 行示例换成与三大章节匹配的（一）活动开展情况。

包内仅 1 个 SKILL.md（71 行 / 4760 字节），无 scripts/、无可执行脚本，以下结论来自逐行读文档加本机环境实测。 先说做得好的：结构约束在三份同类里最清晰，第 12-22 行用「必须包含且仅包含」锁定标题、前言、主体四章、落款的顺序，并规定二级标题不得升级为一级章节；领域适配不是贴牌——第 33 行给了 7 项社会工作部术语（党建引领基层治理、乡镇（街道）社工站建设、新业态新就业群体党建等），第 45 行明确「不得编造具体事实和数据」并配套【XX】占位符规则，第 28 行前言范式完整可直接套用。 硬伤一（字体可用性，实测）：第 49-53 行把四款字体全部指定为方正小标宋 GBK、方正黑体 GBK、方正楷体 GBK、方正仿宋 GBK。我实测本机 C:\Windows\Fonts 里 FZ 开头的字体文件只有一个 FZXKJW.TTF（方正行楷），四款指定字体一款都不在；而全文「降级」「替代」两个词 0 次命中，没有任何字体缺失的处理规则。照它的排版指引设置，Word 会静默替换字体，公文标题与层级观感直接失效。对照本机 simhei/simkai/simfang 齐全，同批另两份公文技能用的正是不带厂商前缀的黑体、楷体、仿宋，开箱即得。 硬伤二（行距偏离）：第 52 行正文写「单倍行距」，而党政公文 3 号仿宋的通行版式是 28 磅左右固定值（GB/T 9704 每面 22 行的口径）；同批法院简报助手第 32 行写「行间距 28 磅」、乡镇补贴助理第 66 行写「行间距28磅」，两份都取 28 磅。这份第 9 行自称「熟悉党政公文规范」，排版参数恰在关键一项偏离。顺带第 54 行「一级章节之间空一行」也非公文通行做法。 改进建议：① 第 49-53 行的字体链补一句缺失时依次替代为黑体、楷体、仿宋并在文末排版指引注明，或直接改用通用字体名；② 第 52 行改为行距 28 磅固定值；③ 第 54 行空行规则改为可选并在指引中说明。

司法单位普法方案垂直场景的纯文本交付技能（96 行单文件，不产 docx），第82行「输出纯文本方案文稿＋排版设置说明放全文末尾」的路线与同题材产 docx 的包形成差异化，整体自洽。亮点：占位符规则完整（第54、84行，用户未提供项留【】占位、严禁编造单位名称/时间/主题）；禁止事项具体可执行（第94-96行，禁软文风、禁输出 Markdown 符号、禁脱离司法单位场景）；宣传重点/实施步骤/保障措施/工作要求四张二级标题模板（第24-50行）可直接套用。三个硬伤：①篇幅参数零消费者——第61行固定询问清单第 6 项收集「方案篇幅要求（简短版/标准版/详细版）」，全文检索「简短」「标准版」「详细版」「字数」，除第61行外仅第89行「调整篇幅」一处，三个档位没有任何字数区间或篇幅规则定义：收了参数却不产生任何行为差异，问用户等于白问；②第70行正文指定「仿宋_GB2312 三号」而全文无字体降级条款（「降级」「替代」各 0 命中），默认 Windows 无该字体（实测本机仅 simfang/simkai），用户照它的排版说明设置后会被 Word 静默替换；③第82行「告知用户复制后如何在 Word 一键设置字体、行距、缩进」——标题/一级/二级/正文四级字体各不相同，行距与首行缩进是段落级属性，Word 里必须逐级选中分别设置，「一键」做不到，与同题材「一键成型」类承诺同族的过度声明。小伤：第65行说「输出文本附带排版标注」，第82行又说排版说明「放在全文末尾」——标注跟段落走还是集中文末两处口径不一，照做的模型只能二选一。建议：给三档篇幅定义字数区间并在撰写阶段挂钩；「一键设置」改为分四级逐步说明；补字体降级条款并统一第65/82行的标注口径。

单文件 SKILL.md（82 行）的纯提示词路线：六章节结构+格式规范表+质量自检清单，无任何脚本。在同题材三包横向对照里有两条真亮点：一是第59行「字体优先使用国标字体……环境缺失时使用最接近的可用字体替代并告知用户」，是三包里唯一写了字体降级条款的（另两包「降级」「替代」均 0 命中）；二是第56行页边距上3.7/下3.5/左2.8/右2.6cm、第57行落款成文日期用阿拉伯数字，均与 GB/T 9704 相符；工作流第29行先出大纲请用户确认再写全文，交互节奏稳。两个硬伤：①第10行自称「深谙《党政机关公文处理工作条例》和《党政机关公文格式》（GB/T 9704）国家标准」，description 与第51行却把文档标题定为「黑体二号字，居中排列」——GB/T 9704-2012 规定公文标题一般用 2 号小标宋体字，黑体二号是坊间误传口径，全文「小标宋」0 命中；拿国标当立身卖点，却在最显眼的标题字体上写错国标口径。②第31行生成文档一步写「使用当前环境可用的 docx 文档能力」，不点名是哪个能力、frontmatter 无任何依赖声明、也没有能力缺位时的替代路径；而第82行「最终输出一个格式规范的 Word（.docx）文档」是硬承诺——环境没有 docx 能力时第 4 步直接断链（对照同题材 f1903cf9 明写「脚本不可用时改用环境的 docx 排版能力，格式标准不得降低」的降级句）。两个小伤：第59行降级清单列「楷体_GB2312、仿宋_GB2312」，第53-54行表格却写「楷体三号/仿宋三号」，同一文档两套字体名并存，降级判断的基准因此含糊；第73-78行自检清单 6 项里没有页边距项，第56行有规范却无对应自检。建议：第51行改为「小标宋体二号」；第31行补一句「环境无 docx 能力时退回带排版标注的纯文本交付」；自检清单补页边距一项。

党政机关方案生成类技能里少见的「带真脚本」包，实测脚本确实兑现了全部格式承诺。自拟官方风格草稿（大标题+两章+二级标题+落款）实跑 scripts/gen_docx.py，exit 0；解包产物逐段核对 XML，skill.md「强制固定公文格式标准」10 项全部命中：页边距上3.7/下3.5/左2.8/右2.6cm（第51行）、标题黑体二号(22pt)居中、一级黑体三号(16pt)、二级楷体三号、正文仿宋_GB2312三号、行距 EXACTLY 28磅、firstLineChars=200 首行缩进2字符、一级章节后自动空一空段、落款右对齐且不缩进——本批同题材三个包里唯一「宣称与产物逐项对得上」的。章节结构设计也更好：第23-37行以六大章节为默认框架，按专项/活动培训/创建评选/应急值守/单薄/复杂六类场景灵活增删合并，比同题材「六个核心章节不得缺省」的硬模板合理。三个硬伤：①入口文件是小写 skill.md（find 实测包内仅此一个入口），大小写敏感的宿主加载器找不到 SKILL.md，而 frontmatter 本身规范（name 为 slug、---闭合正确），死在文件名这一层；②第46行正文指定仿宋_GB2312，全文无字体降级条款（「降级」「替代」各 0 命中，唯一一处「缺失」在第74行指 python-docx 依赖），实测本机 Fonts 目录仅 simfang(FangSong)/simkai(KaiTi) 无 _GB2312 变体——默认 Windows 上第41行「用户打开即可打印上报」要靠 Word 静默替换字体兜底，字模度量变化不可控；③第43行标题「黑体、二号字」与它自称严格执行的公文规范不符，GB/T 9704-2012 规定标题用 2 号小标宋体字，全文「小标宋」0 命中。边界实测：###（一）无空格写法被静默降级为仿宋正文（产物中该段字体为仿宋_GB2312 而非楷体，无任何告警）；输入文件不存在时抛裸 FileNotFoundError 调用栈，而同脚本 ImportError 分支却有友好提示，同类错误两种待遇。另末章正文与落款之间无空行，公文惯例宜空一行。建议：skill.md 改名 SKILL.md；补一条字体降级规则；gen_docx.py 对 ^#{1,3} 后无空格的行做归一化或告警；落款前补空行。

包内只有 1 个文件：SKILL.md（72 行 / 3644 字节），无 scripts/、无可执行脚本，以下是逐行读文档＋本机字体实测的判断。补充一个对照：同批另两份同类技能是 0d573c00 政府会议纪要助手（188 行）与 5fc15e8b 县级纪委监委工作方案（105 行），这份是三者中最薄的。 值得肯定的两点：一是六大章节交代清楚，第 18-23 行为工作背景、指导思想、目标任务、实施步骤、保障措施、工作要求，格式参数（第 29-36 行：标题黑体二号、一级黑体三号、二级楷体三号、正文仿宋三号、固定 28 磅、首行缩进 2 字符）也齐全，第 65 行还要求参考资料为主、禁止胡编、网络内容标来源。二是它的字体写法用的是「楷体」「仿宋」而不是「楷体_GB2312」「仿宋_GB2312」，我实测本机字体目录只有 simkai.ttf（Font Family 为 KaiTi、楷体）与 simfang.ttf（FangSong、仿宋），三份里恰恰只有这一份的字体要求是开箱即满足的。 硬伤一：文风条款自相矛盾。第 41 行把开篇固定死为一句话——「为深入贯彻落实上级相关决策部署和工作要求，切实推进XX工作有序开展、落地见效，结合实际，特制定本工作方案。」要求所有方案统一使用；而同一节第 44 行又要求「内容务实、可落地、可执行，不空泛、不浮夸、不模板化堆砌」。强制一句固定起句本身就是模板化，两条不能同时满足。对照 5fc15e8b 第 27 行、第 83 行，那份是把「拒绝万能套话、拒绝流水线模板」写成硬性禁令的，同题材给出了相反口径。 硬伤二：第 48 行的交付承诺物理上不成立。该行写「必须直接生成可复制、可直接粘贴使用的标准 Word 文档成品文本……用户复制后粘贴到 Word 即可一键成型，无需二次调格式」，但本文档第 33-34 行要求的固定行距 28 磅、首行缩进 2 字符属于段落级属性，第 29-32 行的分级字体属于字符级属性，纯文本复制粘贴进 Word 只会套用目标文档样式，这些属性一个都带不过去，所以「无需二次调格式」做不到。紧接着第 50 行又改成「必须使用 docx 技能（docx::7674890821165973504）生成标准 Word (.docx) 文件」，第 69-72 行交付规范也按 .docx 文件＋文件链接来写——交付形态在两行之内前后不一。 硬伤三：风控条款缺失。全文 72 行没有任何政治合规、保密、数据禁止编造的要求，第 65 行唯一的「禁止胡编乱造」还只针对联网搜索资料；也没有「用户信息缺失时应先补齐哪些要素」的交互规则（第 54 行只要工作主题、领域、范围、时限就直接开写），容易产出正确但空洞的稿子。同题材的 5fc15e8b 在第 79-84 行有 5 条零容忍禁忌、第 86-93 行有 5 项输出前自检、第 48-50 行有数据与案例管控规则。另外第 16 行自称六大章节顺序固定，但该顺序与 5fc15e8b 第 45 行的必备模块顺序相反（本份第 22-23 行是保障措施在前、工作要求在后，那份是工作要求在前、保障措施在后），同一体裁出现两种顺序。 改进建议：① 第 41 行改为「提供不少于 3 套公文起句范式，按主题择一，禁止所有文稿套用同一句」，与第 44 行对齐；② 第 48 行删掉「成品文本＋无需二次调格式」的表述，统一为「调用文档类技能生成 .docx 文件并交付文件链接」，并把第 50 行硬编码的平台技能 ID 改成依赖声明；③ 补一节合规与真实性约束，至少写明不得编造统计数据与工作成效、涉密内容不得纳入、重大政策提法须与现行官方口径一致，并补一句信息缺失时先向用户确认哪些要素。

包内只有 1 个文件：SKILL.md（105 行 / 9419 字节），无 scripts/、无可执行脚本，以下基于逐行读文档＋本机字体实测。 先说最突出的优点：风控体系是这几份同类里最完整的。第 10-27 行的顶层刚性约束把政治合规、纪律边界、保密铁则、县级视角锁定、去 AI 化五条并列；第 79-84 行给了 5 条零容忍禁忌（含禁止编造虚假工作数据、虚假整治成效、虚假问题台账、虚构本县典型案件）；第 86-93 行还有输出前 5 项自检（视角、口径、内容、文风、结构）；第 48-50 行专门区分了「用户没给数据时只做定性描述＋具体举措」与「举例只用通用基层示例，不绑定本县人名、地名、案件」；第 105 行要求优先吸收用户附件素材、不得脱离给定要点发挥。「先约束再生成」的结构在同类提示词里并不多见。 硬伤一：场景覆盖名不副实。description 第 3 行点名 11 个场景（专项整治、监督执纪、信访积案化解、基层微腐败整治、三化建设、生态环保追责整改、作风专项治理、廉政教育、警示教育、廉洁文化建设、机关日常政务活动），但第 57-77 行只有 3 套细则（类别 A、B、C），第 59 行要求「先判断属于下面哪一类」，是单选式路由。而「警示教育」同时出现在第 69 行（类别 B）与第 74 行（类别 C）的适用范围里，两处都能命中，文档没给优先级或裁决规则，同一个需求会因当次判断落到不同细则。 硬伤二：收集了不用。第 103 行向用户确认的第 5 项是「期望大致字数」，但全文没有一条按字数控制篇幅的规则——我统计过全文 105 行里「字数」只出现 1 次（就是第 103 行本身）、「篇幅」出现 0 次，第 44-45 行列的 10 个必备模块也没有篇幅比例，这个参数收上来没有消费者。 硬伤三：导出说明与四层标题体系不匹配。第 37-40 行定义了四级标题（一、黑体／（一）楷体／1. 仿宋加粗／（1）仿宋），但第 8 行的导出说明只覆盖标题、一级、二级、正文四项，三级「1. 仿宋加粗」与四级「（1）」的字体字号完全没交代；且第 8 行与第 3 行都强制要求楷体_GB2312、仿宋_GB2312，我实测本机字体目录只有 KaiTi（楷体）与 FangSong（仿宋），没有 _GB2312 变体，而全文「降级」「替代字体」各出现 0 次。本批另一份同类技能（0d573c00）第 188 行是写了字体降级条款的，这份没有。 另有一处风格反差：第 16 行明令禁止口语化、随意化、娱乐化、网络化表达，而文档自身 6 个一级标题全部以 emoji「✅」开头（第 10、29、57、79、86、95 行），第 19 行还用「⚠️」。约束对象是输出文风，但作为提示词示范仍会带偏向。 改进建议：① 第 59 行后补一条裁决规则（例如同时命中多类时按 A→B→C 优先级叠加执行），并把第 69 行的「警示教育」删掉或明确标注「常态化警示教育归 C 类、集中性警示教育活动归 B 类」；② 要么删掉第 103 行的字数收集，要么在（三）内容编制标准里补一句 10 个模块的篇幅分配（如重点任务约 40%、保障措施与工作要求各约 10%）；③ 第 8 行导出说明补齐三级、四级标题的字体字号，并参照 0d573c00 第 188 行加一句字体缺失时的替代说明。

包内只有 2 个文件：SKILL.md（188 行 / 8278 字节）与 icon.png，没有 scripts/ 目录、没有任何可执行脚本，所以下面全部是逐行读文档＋对运行环境实测得出的判断，我没能跑通任何命令，这点先说明。 文档层面这是同类里做得相当扎实的一份。会议纪要骨架完整：第 50-56 行把「一、会议基本信息」拆成（一）会议名称到（七）记录人七个子项，第 74-78 行要求「四、行动项与分工」逐条给出任务事项、责任单位/责任人、工作要求、完成时限（无时限标注持续推进），第 66-68 行还专门要求区分讨论意见与最终定案、剔除发散讨论。格式规范也不是泛泛而谈——第 109 行把页边距写成上 3.7cm、下 3.5cm、左 2.8cm、右 2.6cm 并注明党政机关公文标准，与 GB/T 9704 的数值一致；第 188 行给了字体降级条款（系统缺字体时用最接近替代并在交付说明注明）。我实测本机字体目录只有 simkai.ttf（Font Family 为 KaiTi、楷体）与 simfang.ttf（FangSong、仿宋），确实没有楷体_GB2312 与仿宋_GB2312，也就是第 95-96 行强制的这两个字体在本机必然缺失——这份文档是唯一写了降级规则的，可靠度明显更高。 最硬的问题在交付链路。第 150-164 行「使用 docx 技能生成 Word 文档」共 7 步，第 155 行要求执行 bash scripts/bootstrap_dependencies.sh，第 163 行要求通过 writeDocxCandidate() 写出候选文件，第 164 行要求过质量门禁。但我实测包内既无 scripts/ 也无该脚本（find 查 bootstrap 无结果），frontmatter 第 1-14 行也没有任何外部依赖声明。也就是说它宣称的核心能力「直接生成格式已设置好的 Word 文档」按包内内容无法复现，用户得自己猜第 154 行的「docx 技能」指平台里的哪一个。 另有三处可核实的缺口。一，第 144 行的提炼清单是「会议名称、时间、地点、主持人、参会人、背景、议定事项、行动项」八项，而第 50-56 行结构要求有七个子项，「缺席人员」与「记录人」在提炼步骤里没有对应动作，实际执行时这两项只能空等用户补。二，第 115 行编号规则句写成「注意句点为中文全角句号时不规范，使用阿拉伯数字后紧跟中文全角句号也不规范」——同一句话说反又重复，第 116 行又重复一遍「正文条项一般用 1. 2. 3.」，读不出到底要哪种。三，全文只有第 143 行的「（文字稿、笔记、发言摘要、图片等）」提到图片，之后再无任何图片处理规则（无 OCR 前置、无「图片需先转文字」提示），这个括号给自己挖了个做不了的坑。 改进建议：① 第 150-164 节改成不依赖内部 API 的写法，删掉第 155 行的相对路径与第 163 行的 writeDocxCandidate()，改为「用平台文档类技能生成 .docx，并按下列字体、段落、页面参数设置」，或在 frontmatter 里声明依赖；② 第 144 行补齐「缺席人员、记录人」，与第 50-56 行逐项对齐；③ 第 115 行只留一句「正文条款使用 1. 2. 3. 格式（阿拉伯数字＋英文句点）」；④ 第 143 行删掉「图片等」，或补一句「图片素材需先转文字稿再进入第 2 步」。另建议第 93 行标题字体核对一下 GB/T 9704：公文标题通行作 2 号小标宋体，文档此处写的是黑体二号，与第 109 行对页边距的严格程度不太一致。

包内 8 个文件（5 份 data/*.json ＋ main.py ＋ tarot_core.py ＋ interpretations.py），含可执行脚本，我按文档逐一实跑。 结论先说：这份技能在交付形态下完全跑不起来。用文档自带示例「我的事业运势如何」调用入口，实测只返回一个 error 字段，内容是 'utf-8' codec can't decode bytes in position 16382-16383: invalid continuation byte，任何问题都拿不到牌面。 根因已定位到单个数据文件。data/大阿卡纳.json 共 23370 字节，我用二进制读出来核过：第 16382 字节起的 UTF-8 序列被截断，抛错处正是 e8 af 两个字节（一个三字节汉字的开头），其后直到文件末尾共 6986 字节全是 0x00 填充。内容停在第 15 张牌（恶魔 The Devil）的 upright.general 字段中间，可读前缀停在「欲望、」，说明这份文件是被某个 16 KiB 缓冲写出后整段截尾的。tarot_core.py 第 243-244 行用 open(major_path, 'r', encoding='utf-8') 读取，直接抛 UnicodeDecodeError，main.py 捕获后打印成 error 字段。 连带后果：① 可读到的牌名只有 17 个，第 16-21 张（塔／星星／月亮／太阳／审判／世界）连同恶魔的后半段字段全部丢失，而 description 与 SKILL.md 都宣称 78 张（22＋56）含正逆位双面释义；② 牌阵定义与解读引擎虽然完好，但解读入口依赖牌组初始化，因此一并不可用。 同一包里真实可用、值得肯定的部分我也核过，问题只出在上面这一个文件：data/小阿卡纳.json 编码正常，四花色 wands/cups/swords/pentacles 各 14 张、合计 56 张，与 meta 里的 count 56、cards_per_suit 14 一致，是完整数据；data/牌阵定义.json 的 spreads 实测 8 个（单牌／三牌／是否／爱情／事业／四牌／凯尔特／马蹄铁），与 SKILL.md 第 25-34 行那张 8 行参数表逐项对得上；main.py 对文档承诺的 --date=／--shuffle=／--format=／--positions= 四个可选参数确实都做了解析（第 40-54 行），--date 配合确定性抽样实现「同日期同问题结果一致」的思路也是对的。缺的只是把那份损坏的 JSON 重新上传。 另有两处独立于损坏之外的问题。一，文档给的调用路径不存在：SKILL.md 第 13 行与第 20 行写 python3 .skills/skill_tarot-divination/main.py，包内既没有 .skills/ 也没有 skill_tarot-divination 子目录（已用 os.path.exists 逐个确认），真实入口是包根 main.py。二，data/索引.json 自报结构与实际交付对不上：它把知识库路径写成「塔罗占卜知识库/」、代码路径写成「塔罗占卜/」，并列出 test_tarot.py（称「11个测试类，35+测试用例」）与 __init__.py，而这四个路径／文件在包里全不存在（实际只有 data/ 一个目录与 3 个 .py）；statistics 里 total_code_files 写 5 也对不上（真实 3 个）。按这份索引找测试文件会全部落空，而它恰是外人判断这包有没有测试的唯一入口。 改进建议：① 重新打包并上传修复后的 data/大阿卡纳.json，并在发布流程里加一道全包校验——对每个 data/*.json 尝试 decode('utf-8') 后 json.loads，任一失败即阻断；同时给 tarot_core.py 第 243 行加 try/except 输出可读的「牌库缺失」提示，不要把解码异常原样抛给用户；② SKILL.md 第 13／20 行改为 python3 main.py，并同批核对同系列另两份（029c2f10 写 skills/nameology/main.py、990961a0 写 skills/tieban-shenshu/main.py，都应是包根 main.py）；③ data/索引.json 的 knowledge_base.path、code_modules.path、test_tarot.py、total_code_files 四项按实际交付改写。

包内 15 个文件：6 个算法模块＋8 份数据＋一份 15KB 单元测试；我跑了测试、穷举了编号空间、并逐条追了卦象链路。 可信的部分：自带测试实跑 python -m unittest test_tieban 得 Ran 33 tests, OK，一条不挂。data/太玄数转换表.json 的口诀「甲己子午九，乙庚丑未八，丙辛寅申七…」与代码逐项一致，无效天干、无效地支的抛错路径也有测试覆盖，参数校验是稳的。十类编号区间（1-1000 命运总论 … 11501-12900 命理杂论）与 suanshu.py 的 CATEGORY_RANGES 完全对得上。 硬伤一（最重）：所谓 12900 条条文，实际是 40 条固定模板句。tiaowen.py 第 22-84 行的 TEMPLATES 只有 10 分类 × 4 条 = 40 句，generate_tiaowen 用 suanshu % len(templates) 取其中一条，注释自己写着「条文模板库（示例模板，实际应用中可扩展）」。我把 1 到 12900 全部编号喂进去逐条生成，去重后只能产出 40 条不同文本，而 data/条文索引.json 声明「12900条条文索引系统」、total_count: 12900。SKILL.md 承诺的核心能力「条文检索与条件批断」在这份数据上不成立。 硬伤二：卦象全链路是常数。实测 3600 组八字（60 个年干支 × 60 个日干支）→ 先天卦 100% 恒为坤、动爻 100% 恒为 2、变卦 100% 为「未定义」，卦象数值恒为 0。根因两处：① guaxiang.py 的 bazi_to_hexagram 写 for gan, zhi in [(day_zhi, day_gan), (month_zhi, month_gan), …]，把地支装进名为 gan 的变量、天干装进 zhi，随后却调用 is_yang_zhi(zhi) or is_yang_gan(gan)，两个判据都拿错字符，恒为 False，六爻恒 000000，于是恒为坤；② dong_yao = (GUA_ORDER.get(hour_zhi, 1) % 6) + 1，而 GUA_ORDER 只有乾兑离震巽坎艮坤八个卦名键、传入的却是地支，永远走 default 1，动爻恒 2；坤配动爻 2 翻转得 010000，不在表内，变卦于是恒为未定义。 硬伤三：CLI 输出里根本没有条文。SKILL.md 第 28 行承诺输出「基础算子/纳音校正/时辰校正/原始算子/最终算子/条文范围」，实际 main.py 只调 calculate_final_suanshu 打印六个数字，没有条文、分类与吉凶——它们只存在于 tiaowen.retrieve() 这条 main.py 从未调用的支线上。照文档跑拿不到任何批断内容。 硬伤四：公式与文档差 1。suanshu.py 第 92 行 docstring 与 data/条文索引.json 第 24 行都写「(基础算子 × 10 + 纳音数 + 时辰校正) mod 12900 + 1」，代码第 117-119 行只做 % 12900。实测八字 甲子年壬申月戊午日壬子时：基础算子 2580＋纳音 1＋时辰校正 1 → 原始算子 25802 → 代码给最终算子 2，按文档应为 3。 硬伤五：可达编号只有 41%。四柱单柱取值实测只有 50 种，四柱总和 387 种；基础算子恒为 10 的倍数，原始算子恒为「100 的倍数 + 一个 2~42 的偏移」，用 60 个年柱 × 387 个总和 × 12 个时支穷举，最终算子可达集合仅 5289/12900 = 41.0%（已是最宽松上界），59% 的编号永远取不到。 其他两处：吉凶与条文出自两条互不相干的支线，同一份报告能自相矛盾——编号 2 时【吉凶】写「大吉 (A+)」加「命格极佳，福禄深厚」，而【命运条文】是「命局平稳，循序渐进，虽无大贵亦无大忧」；CLI 传入的时支会覆盖八字自带的时柱（同一八字传子得 2、传午得 8），而 format_full_report 又不接这个参数。 改进建议：① 把 12900 条条文真正落成数据文件，或把声明改为 40 条模板并说明取条规则，这是整包立身之本；② bazi_to_hexagram 的解包顺序改为 for gan, zhi in [(day_gan, day_zhi), …] 并让动爻按卦象或数值映射取值，别拿地支查 GUA_ORDER；③ main.py 补条文、分类、吉凶三块输出；④ 第 117 行按文档补 +1；⑤ 条文范围与 get_range_tiaowen 统一。

包内 5 个文件：SKILL.md（40 行）＋main.py（39 行）＋nameology_core.py（1194 行）＋data/kangxi_strokes.json（21027 条）＋requirements.txt，含可执行脚本，我逐个跑过。 先说站得住的部分。笔画表实测 21027 条，覆盖扩展 A/B 区（如 㚇／㨖／䂑），且简化字按繁体笔画计——与=14（與）、万=15（萬）、业=13（業）、东=8（東）、严=20（嚴）、为=9（為）、举=16（舉）、两=8（兩），这正是五格姓名学的通行口径。五格主力公式复算全对：王小明（王4／小3／明8）→ 天格 5、人格 7、地格 11、外格 9、总格 15，三才土金木，与我手算一致。 硬伤一：文档命令路径不存在。第 13 行与第 22 行都写 python3 skills/nameology/main.py，包内没有 skills/ 目录，真实入口是包根 main.py。按文档执行实测报 can't open file ...skills/nameology/main.py: [Errno 2] No such file or directory。 硬伤二（最重）：81 数理吉凶表只覆盖 40 个数，其余 41 个一律判凶。第 52-74 行的 NUMBER_LUCK_TABLE 实测只有 40 条（30 个大吉＋10 个吉），注释自己写着「简化版，实际应包含完整81数理」与「凶数（其他未列出的数）」，第 502-510 行的 _judge_luck 以 .get(num, LuckType.BAD) 兜底。逐个数出，2／4／7／9／10／12／14 … 80 共 41 个编号从未列出，全部落成凶，其中 7、38、58、71、73、77、78 在通行 81 数理里并非凶数。实测王小明人格 7 被判「凶」，而枚举里定义的 大凶 与 半吉 两档全表一次都没用到。 硬伤三：没有八字时，30% 的综合分是一个写死的常数。第 1089-1127 行 _calculate_comprehensive_score 的权重是五格 0.4／八字 0.3／文化 0.3，而第 1115 行 bazi_match_score 取 result.match_score if result.match_score > 0 else 70。实测王小明：五格吉凶均分 (100+40+100+40+100)/5 = 76，文化 overall 76，八字项被填成 70 → 76×0.4＋70×0.3＋76×0.3 = 74.2 → 输出综合评分为 74，与实测完全吻合。用户不报八字时，报告里三成的分数来自一个常量，而 description 恰恰宣传「五行生克与吉凶判断」。 硬伤四：异常输入静默给出结论。㛃（U+36C3，不在笔画表内）被当作 0 画，实测「㛃王」天格=1、人格=4，无任何告警；「John」四字全部 0 画，五格 [1,0,0,1,0]，结论却是「姓名整体良好，继续保持即可」；单字「王」的 given_count=0，name_type 仍报「双名」，地格=0。 硬伤五：报告跳号与硬编码日期。第 965-1018 行的章节号是写死的中文数字，而「三、八字五行匹配」在无八字时不追加，实测报告编号为 一、二、四、五、六、七（缺三）。第 1024-1025 行把「生成时间：2026年2月20日」与「算法版本：1.0.0（文化级）」写死，与 frontmatter 的 version 2.0.1 也不一致。 其他两处：第 4 行 frontmatter 写成 version: 2.0.1--- ，闭合分隔符与值挤在同一行，按行解析的加载器找不到闭合符；第 473-474 行用同一条「总格-人格+1」覆盖所有姓名结构，实测复姓双名「欧阳娜娜」外格=26（＝47-22+1），而通行复姓算法取「姓首字+名末字」＝15+10＝25，单姓单名「王明」得外格 1（通行取 2）。 改进建议：① 第 52-74 行补齐 81 数，至少补入「半吉」档与 7／38／58／71／73／77／78，并把 _judge_luck 的兜底从默认凶改成显式标注「未收录」，否则半数编号被系统性误判；② 第 1115 行不要用常数 70 顶替三成权重，改成按 (五格×0.4＋文化×0.3)/0.7 归一化；③ 第 13／22 行路径改为 python3 main.py 加姓名；④ get_stroke_count 查不到字时返回哨兵值，由 main.py 输出「以下字未收录」，不要静默按 0 画；⑤ 报告编号改为动态生成或空节补占位行，日期改用 datetime.now()。

包内 3 个文件：SKILL.md（95 行）＋references/scenarios.md（49 行）＋references/dictation-words.md（45 行），无 scripts，属提示词＋资料型。我按文档逐条核对了一遍。 决定性问题在「跟读纠音」这个主打模块上：它要诊断的东西，输入信号里根本不存在。SKILL.md 第 25 行自己写明「用户语音输入由平台转写为文字；你依据转写文本分析读音与语法」，第 49 行重复「平台转写为文字，你结合转写文本与常见读音陷阱判断问题」。但第 51-52 行要求「关注长短元音、重音位置、尾音（-ed、-s）、连读弱读」，第 50 行还要求「用国际音标标注错误音素」。ASR 转写恰恰会抹平这些维度——/iː/ 与 /ɪ/、/æ/ 与 /e/ 常被规范成同一词形，重音与连读在文本层不留痕迹，尾音 -ed/-s 一旦被听对就会被正确拼出。技能要求输出的诊断粒度（音素级）比输入粒度（词形级）更细，纠音反馈只能靠猜，还会带 IPA 标注猜得很自信。 第二个问题是核心流程绑定的工具既没声明也没兜底。第 12、24、26、48、50、57、65、79、95 行共 9 处提到 generate_audio（其中 26、65 行仅为软性提醒），第 24 行把它写成「依赖 generate_audio 工具生成示范与反馈语音」，但 frontmatter 里只有 name 与 description 两个字段，没有任何依赖声明；本环境可用工具清单里也没有这一项。照文档执行，「示范-跟读-反馈」三段式的第一步（示范句语音）与第三步（正确读音语音示范）都会断，而技能没有降级分支（例如无音频能力时改用音标＋重音标记＋慢速拼读的纯文本示范）。 资料层的问题偏细节，但都实测得到： ① 听写词库实际只有 36 个词。dictation-words.md 三个难度各列 12 词，而同一文件第 10 行写「每轮典型 8-12 个词」——练到第 3-4 轮即无词可用，技能也没给词库扩充机制。 ② dictation-words.md 的目录与正文难度标签对不上。该文件第 4-6 行目录写「初级（Beginner）/中级（Intermediate）/高级（Advanced）」，正文实际标题是第 14 行「## 初级（初级 ~ 中级）」、第 18 行「## 中级（中高级）」、第 22 行「## 高级（高难度）」，三处标签各不相同，且「初级（初级 ~ 中级）」自身区间与标题重复。 ③ dictation-words.md 第 27 行的拼写规律写错了。它把 receive 与 believe 并列在「（i before e）」下面，但该规则完整表述是 i before e except after c，receive 的 c 后面正是 ei，属规则例外，与 believe（真 ie）不同源，并列会教错。同组第 30 行（restaurant / library / beautiful）里，beautiful 也不是字母序颠倒的典型例。 ④ 反馈模板中英混排断句。dictation-words.md 第 43 行「Nearly there. It's spelled ...注意易错部分 ...」把中文直接嵌进英文句子，拼接处无标点。 正面：场景库结构统一且扎实。scenarios.md 五个主题（购物/面试/课堂/餐厅点餐/旅行问路）每个都齐备「角色、高频表达 5 句、对话脉络 5 步、易错点」四件套，第 45-49 行还给出肯定/指错/示范/鼓励四类点评句式模板；易错点多数正确（单复数 two shirts、information 不可数、比较级 cheaper 而非 more cheap；面试主题的时态切换与 apply for 搭配）。SKILL.md 第 20-21 行的「单点纠正」＋「肯定-纠错-示范-重练」四步把纠错节奏定清楚了，比笼统写「多鼓励」可执行。 改进建议：① 跟读纠音二选一——要么改成文本层可诊断的定位（语法、用词、句法完整度、连接词使用），要么明确写入「仅在平台提供带音素的识别结果时才做音素级纠音，否则只给音标示范、不做错误判定」，并把第 51-52 行的诊断维度绑定到该前提；② frontmatter 补依赖声明，正文加一条无音频能力的降级路径；③ 词库三个难度各扩到 30 词以上，并在 SKILL.md 第 59 行「记录陌生词」处补上写回词库的动作；④ 统一第 4-6 行目录与正文标题的难度命名，改掉「初级（初级 ~ 中级）」；⑤ 第 27 行拆开 receive 与 believe，或改成「i before e except after c（例外：receive、c

包内只有 1 个文件，且文件名是小写的 skill.md（55 行 / 3312 字节）而非平台约定的 SKILL.md，无 scripts、无 references，属纯提示词型技能，因此评价以文档自洽性为主。 先说立得住的地方。第 22-27 行把输出拆成五块固定结构（🌟整体运势/💕感情运/💼事业学业运/🍀幸运色+幸运数字/⚡今日提醒），第 33-36 行规定标题、正文、收尾、参考声明四段式，第 38-45 行给出结构示例并明确「仅作结构参考，不可照抄」，第 53-55 行把「运势不构成医疗/投资/法律建议」写成边界声明并要求每条固定附参考声明——娱乐向小技能里合规意识算清楚。第 28 行禁用表达表（「需要注意的是」「建议您」「总而言之」「综上所述」）与第 21 行「不要用您、用你」口径一致，没打架。 三条硬伤： 一，1-5 星没有任何判据。第 23 行要求「整体运势（1-5星，用星星表示）」，第 39 行示例给了 🌟🌟🌟🌟，但全文没有评分规则——没有维度、没有权重、没有映射表。同一星座同一天调用两次，星级可以随模型给出 2 星或 5 星。对「每日运势」这类会被用户第二天回看对照的产品，这是可感知的不一致。 二，字数上限与强制结构打架。第 20 行规定「只生成当天 1 条运势，150-200 字」，但第 22-27 行强制包含 5 个板块，第 33-36 行还额外要求标题、收尾句和参考声明。仅固定骨架（标题约 15 字＋五个板块标签约 60 字＋收尾约 15 字＋声明约 25 字）就占掉约 115 字，留给感情运、事业运、今日提醒三块具体内容的只剩 35-85 字；而第 27 行偏偏要求今日提醒是「具体的、有画面感的建议，不要空洞的鸡汤」——压到一句话时这个要求事实上做不到。 三，星象那条自己打自己。第 30 行写「如果今天有重要星象变化（如水逆、满月），要自然地融入」，第 50 行却写「星象信息仅在当天确有重要星象或用户提供时融入，不硬编造水逆、满月等事件」。而这个技能没有任何星象数据来源（单文件、无 scripts、无 references），第 17 行的 {{星象}} 又是可选外部输入——技能自己无从判断「今天是否有重要星象」，第 30 行的条件永远无法由技能自行成立，只能靠模型猜，而这恰恰是第 50 行明令禁止的。另外第 15 行把 {星座名} 描述为「用户所在星座」，星座按出生日期定，不是「所在」，措辞也不准。 改进建议：① 补一张极简星级映射表（例如按当日流日与用户星座四元素/相位关系分 2-5 档并写明边界），让 1-5 星可复现；② 第 20 行改为「正文（不含标题、收尾与参考声明）150-220 字」，或把五个板块合并为三个；③ 第 30 行与第 50 行二选一——要么删掉无条件星象融入，要么改成「仅当用户在 {{星象}} 中提供时才融入」；④ 文件重命名为 SKILL.md。

包内 4 个文件：SKILL.md（147 行）＋references/evaluation-items.md（323 行）＋references/output-template.md（251 行）＋scripts/extract_pdf.py（378 行）。带可跑脚本，所以我实测了一遍。 先说跑通的部分。本机 venv 里 pymupdf 恰好是 1.28.2，与 frontmatter pin 的版本完全一致，开箱即用。我造了 3 个测试 PDF（3 页纯文本、1 页纯图片、1 页空白）跑 --dir，返回 status=success、pdf_count=3、total_pages=5，退出码 0；text_source 三态判定准确——文本页给 pdf_text、图片页给 scan、空白页给 empty。--files 传不存在的 nope.pdf 时 stderr 抛出 File not found: nope.pdf 的错误数组并以退出码 1 结束，传 SKILL.md 则报 Not a PDF file，错误路径规整。 问题集中在 references 这份被 SKILL.md 第 105 行定为「最高优先级、不得篡改」的条文清单上。 一，步骤 3.1 引了一个不存在的字段。SKILL.md 第 68-72 行声明 evaluation-items.md 提供「条文编号与内容、所属类别、满分值、检索关键词」，第 80 行要求「根据 evaluation-items.md 中每个条目的关键词，在各专业设计说明中定位相关段落」。实测该文件全文检索「关键词」命中 0 次——整份文件是「子项 | 编号 | 条文（原文）| 满分」四列表格，根本没有关键词列，这条检索路径按文档无法执行，只能靠模型临时现编关键词。 二，条文原文本身带残句。第 36 行 4.1.8 写作「应具有安全防护的警示和引导标识相统」，「相统」是「系统」被截断；第 37 行 4.1.9 多出一个孤立标点「、)」；两处都是 PDF 提取残留，而 SKILL.md 把「条文内容必须与模板原文完全一致」写成最高优先级，模型会把这些残句原样抄进正式的自评估报告。 三，加分项编号跳档。9.2 节最后一条编号写作 9.3.0，前一条是 9.2.9，中间不存在 9.3 节，正确应为 9.2.10，而这个编号会被直接引用进报告条文标题。 四，加分项合计对不上。9.2 节 10 条满分相加为 30+30+20+5+10+15+30+20+30+40 = 230，紧贴表格的那一行却写「合计满分：100分（不超过100分）」。9.1.2 原文说的是「当得分大于 100 分时，应取为 100 分」，即 100 是封顶值而非各条满分之和。 五，输出模板自相矛盾。output-template.md 第 245 行要求「使用四列表格（序号、对应评价要点、来源文件、位置、材料内容摘要）」，括号里列了 5 个字段，第 89-94 行的样例表实际也是 5 列，数词与字段对不上。 六，脚本的专业识别不去重。extract_pdf.py 第 72-99 行的 profession_keywords 中「智能化」与「智能」都映射到 smart_building，检测结果直接 append、没有集合去重。实测文件名「智能化设计说明.pdf」返回的 detected_profession 是 smart_building 重复出现两次，重复项会顺着 JSON 流进分析环节；「空调」与「暖通」、「绿色」与「绿建」同样成对命中同一值。 正面还要记一笔：实测各章满分合计为第 4 章 100、第 5 章 100、第 6 章 100、第 7 章 200、第 8 章 100，4-8 章合计 600，与 GB/T 50378-2019 各章评分项满分完全吻合；星级阈值 60/70/85 与 Q=(Q0+Q1+…+Q5+QA)/10 的公式也和标准一致，数据骨架是对的。 改进建议（按优先级）：① 给 evaluation-items.md 补上「检索关键词」列（每条约 5-8 个行业术语），或把 SKILL.md 第 68-80 行的关键词路径删掉、明确改为「由模型自行抽取术语」；② 修正 4.1.8 残句、清理 4.1.9 的孤立标点，并把 9.3.0 改为 9.2.10；③ 9.2 表下说明改为「加分项合计上限 100 分（各条满分之和 230）」；④ extract_pdf.py 第 99 行改为 return sorted(set(detected))；⑤ output-template.md 第 245 行统一为「五列表格」。

包内只有 skill.md 一个文件（46 行 / 2976 字节），无 scripts、无 references、无 templates，全部是提示词指令，属纯流程型，只能按行核。 硬伤一（边界句与执行步骤自相矛盾）：第 45 行边界声明写「此 Skill 只负责图像生成与配色方案制作，不用于身份信息分析、人脸识别比对等用途」，可第 19 行执行步骤 1 要求「先用图片理解能力分析参考图：确认发型、发色、脸型、五官、饰品、服装、气质风格等关键特征」，第 20 行还要「记录可用于Q版化的核心特征点，作为后续生成的一致性依据」——发色/脸型/五官逐项提取加上留存作依据，正是身份特征抽取，一边说不用一边列为第一步。建议把第 45 行改成「不做身份核验与实名识别，仅提取风格化所需的外貌特征」，或在步骤 1 明确只取「发型轮廓＋配色＋标志性饰品」三类。 硬伤二（最关键的承诺零可执行手段）：第 34 行要求「人物五官与轮廓保持同源一致，确保是同一角色换多套配色」，但全篇没有任何落点——既没说固定随机种子，也没说把基础版出图回喂为参考图做图生图，更没规定哪些描述段必须逐套逐字复用。按第 28-32 行「默认 4 套」执行就是 4 次独立生成，五官漂移几乎必然，而这恰是这类技能最容易被差评的地方。建议补硬规则：每套只改「配色/背景」描述，角色描述段逐字复制，并以基础版图作参考图逐套重绘。 硬伤三（套数口径三处不一）：第 10 行写「通常 3~5 套」，第 14 行与第 28 行写「默认 4 套」，第 33 行又写「若有用户指定偏好色系，替换或优先对应的套系」——用户说「想要 3 套」时到底是出 3 套还是仍出 4 套，以及「替换」与「优先」二选一取哪个，都没定义，执行时只能猜。 正面：第 24 行把可复用的提示词要素写成了清单（保留【发型＋发色＋标志性元素】、明亮干净背景、1:1），第 38 行要求交付时列「配色名称/主色调/适用场景」清单，第 41-42 行区分了「聊天直出图」与「汇总为图文方案」两种交付形态，这三点比同类图像技能细。 其他建议：①第 25 行的 1:1 方图在当前生图工具只支持 1024x1024 / 1024x1536 / 1536x1024 时，应写明取 1024x1024；②「奶黄/奶油粉」这类色彩词建议补色值口径，否则同一句提示词跨会话出图差异很大。③包内文件名是小写的 skill.md 而非平台约定的 SKILL.md，上线时需确认宿主按大小写精确匹配入口（本机 Windows 不区分大小写，测不出这个问题），建议直接改名。

包内 2 个文件：SKILL.md（82 行 / 6.4 KB）＋assets/icon.png（309 KB），无 scripts、无 references，纯流程型。 硬伤（第 5 步“强制真实出图”会直接卡住）：第 57 行写“使用生图工具（当前环境为 generate_image，一次可在 items 里提交 3 个生图请求）”。实测本环境的生图工具名是 ImageGen，参数只有 prompt / size / quality / style / output_dir 等单项字段，既没有 generate_image 这个工具名，也没有 items 批量参数。第 54 行要求“必须立即调用当前环境可用的生图工具”，第 57 行给的名字与参数却都对不上，照文档执行只能靠模型自行改名，这一步的强制性形同虚设。 同一处第二个坑：第 43 行与第 59 行硬性要求“竖版 3:4（1080×1440）”，而该工具文档给出的示例规格只有 1024x1024 / 1024x1536 / 1536x1024，没有 3:4（1024×1536 是 2:3）。另外一次性生成 3 张会消耗额外额度（本环境约 5-10 credits/张），技能全程未提示成本，也未要求先与用户确认。 其余三处：① 第 20 行禁用词表把“同色系叠穿”整体列为禁用，而第 49/60 行的内页提示词恰恰要求写“同色系、真实街拍风”，且第 49 行仍处在“全程大白话”的约束范围内，同一术语家族一半禁用一半必写，边界没划清。② 第 37 行要求正文写 2-3 套 Look，第 50 行只出 2 张内页，第 4 步写明“每张分别对应正文里的不同穿搭 Look”——写满 3 套时必有 1 套拿不到配图。③ 封面硬要求“封面上方必须有醒目的大字标题”（中文标题字），但生图模型渲染中文长句的可靠性很低，技能没有任何兜底分支。 正面：触发条件（第 9-14 行）、受众与卖点（第 16-20 行）、6 步顺序与最终交付顺序（第 68-76 行）写得明确可执行；禁用词用“不写 A/B/C”给了具体反例而非抽象要求；第 62 行还规定生图失败只重试单张、不整批重跑——这两点比同类文案技能细。 建议：① 第 57 行改为不绑具体工具名的表述（如“调用当前环境的生图能力逐张提交”），把“一次批量 3 张”降级为“逐张调用”；② 第 43/59 行改成“优先 3:4，工具不支持时取最接近的竖版比例并告知用户”；③ 第 20 行补一句“（制图提示词不受此限）”或把禁用词细化到单词级；④ 在第 5 步前加一句额度提示与用户确认。

包内只有 career-interest-profiler/SKILL.md（269 行 / 14.7 KB），无脚本、无 references，属纯方法论型，只能按文档逐条核。 硬伤一：第 45 行说“根据用户选择的维度，从对应题库中抽取题目”，但第 53-84 行所谓“各维度题库”只有各类型的性格描述（如 R 型“喜欢动手操作、使用工具、户外活动、机械设备”），一道实际题目都没有；第 49 行的提问形式（1-5 分认同度）也只能由模型即兴出题。这个技能最核心的资产（题本）实际不存在。 硬伤二：题量自报 4 处，3 处与自己的单类型题量算不过来——第 55 行霍兰德“每个类型 6-8 题，共 40-50 题”（6 类 × 6-8 = 36-48，上限差 2 题）、第 63 行职业锚“每个锚型 4-5 题，共 35-40 题”（8 锚 × 4-5 = 32-40，下限差 3 题）、第 80 行 MBTI“每个维度 8-10 题，共 35-40 题”（4 维 × 8-10 = 32-40，下限差 3 题）；只有第 73 行大五（5 维 × 8-10 = 40-50）自洽。 硬伤三：计分口径缺失。第 89-93 行的计算规则只说“计算六类型得分”，没给正向/反向计分与题量归一化，也没给第 92 行“高/中/低三档”的分界值；第 121-123、150-152 行的“匹配度：高/中高/中”同样无判据。同一次答题换一个会话跑，结论不可复现。 硬伤四：交叉分析表（第 229/233/234/235 行）把锚型写成“技术型”“挑战型”“自主型”“安全型”，而第 63-71 行定义的正式名是“技术/职能型”“纯粹挑战型”“自主/独立型”“安全/稳定型”——同一份文档两套名称并存，按简称检索对不上定义。 硬伤五：第 34 行的三档时长（快速版约 10 分钟 / 标准版约 20 分钟 / 完整版约 40 分钟）既没说明各档对应几个维度，也与题量算不过来：第 42 行允许 2-4 个维度组合，按四个题库自报的题量区间合计为 150-180 题（下限 40+35+40+35、上限 50+40+50+40），第 48 行又规定「每次只问一道题，等待用户回答后再问下一题」，40 分钟要答完 150 题以上并不现实。 正面：第 170-218 行的三张参考表（RIASEC 6 类、职业锚 8 类、MBTI 16 型）无遗漏、与理论一致；第 130-165 行的多维度报告模板含交叉分析、张力点/协同点，结构完整可照做。 建议：① 把第 53-84 行的“题库结构”改名“维度定义”，或真附题本（每类型 4-6 句陈述句＋计分方向），否则删掉第 45 行的“从题库抽取”；② 在第 89-93 行补计分表（每题 1-5 分、按题量取均值、写明高/中/低分界）；③ 第 229-240 行统一改用第 63-71 行的正式锚型名；④ 第 34 行时长按题量重估，或注明“每题约 15-20 秒”；⑤ 在 FAQ 注明 MBTI 为注册商标、本测评为非官方自编简版。

正文内容本身是这批候选里写得最好的，但包装声明和实际交付系统性对不上，落差全在「中文」这件事上。 先说内容：SKILL.md 81 行 / 10886 字节，配 SKILL-MECHANICS.md 22 行。概念体系很扎实——context pointer（一个指针何时被读到，由它的措辞而非目标决定）、两种负担（context load 常驻上下文，cognitive load 落在人身上：人就是索引）、信息层级三级（in-file step / in-file reference / disclosed reference）、progressive disclosure、co-location、sprawl、completion criterion 的 clarity 与 demand 两条属性、premature completion、leading word、negation（别想大象，禁令反而把被禁行为拉进上下文）、no-op 的判定是 model-relative 要靠跑而不是辩论、以及 sediment 这层淤积。这几节我愿意直接拿来做写技能的检查表。 问题出在包装上，我逐项实测： 一，NOTICE 第二节第 1 条声明「全部改写为中文，按中文表达习惯重写，不是逐句翻译」。实测 SKILL.md 与 SKILL-MECHANICS.md 的汉字数为 0——正文完全是上游英文原文，不是改写也不是翻译。中文只出现在 NOTICE（289 字）、README（254 字）、CHANGELOG（39 字）这类说明页里。 二，NOTICE 同节第 2 条声明「重排结构为统一的 Skill 组织方式（SKILL.md + references + scripts）」，CHANGELOG 的 v1.0 也照抄了这句。实际目录里只有 SKILL.md、SKILL-MECHANICS.md、README.md、CHANGELOG.md、NOTICE、LICENSE、LICENSE-UPSTREAM-MIT.txt 和 agents/openai.yaml，没有 references/，也没有 scripts/。 三，README 第 13 行写「需要参考细节时，Agent 会自动读 references/ 下的文档」，第 17-19 行把「references/ 细节、判据、实测数据」「scripts/ 配套脚本（如有）」列进内容清单——三者都不存在；第 7 行承诺的「踩过的坑与实测数据」，全文一处实测数据也没有。第 24 行「环境要求：见 SKILL.md 内的说明」，而 SKILL.md 里根本没有环境要求这一节。 四，frontmatter 的 description 只有英文（Writing documents for agents. Use when creating or editing skills...），agents/openai.yaml 的 interface 也是英文 display_name 与 short_description。中文会话里几乎没法被自然触发，只能靠手输技能名。 正面一处：上游署名做得很规范，NOTICE 写明 mattpocock/skills、引用版本 commit b0618bc、Copyright (c) Matt Pocock，LICENSE-UPSTREAM-MIT.txt 随包附上，没有隐藏出处。 改进建议，按优先级： 1. 二选一。要么真按 NOTICE 承诺把两个正文文件重写为中文（这才是这个包在中文市场唯一说得通的卖点）；要么改掉 NOTICE 和 README 里「全部改写为中文」「references/ + scripts/」的表述，如实写成「上游英文原文 + 中文说明页」。现状是买家按中文技能买，拿到英文正文。 2. description 补中文触发词，如「SKILL.md 怎么写」「AGENTS.md 写太长」「同一段提示词 Agent 时好时坏」「文档里该不该写这一句」。 3. README 里的 references/、scripts/、实测数据三处要么删掉要么补真。如果补 references/，正好可以把 SKILL.md 第 10／20／29 行那三节（Context pointers、The two loads、Information hierarchy）拆成 disclosed reference——这就是它自己教的 progressive disclosure，当场示范一次。

包内 8 个文件：SKILL.md（127 行）＋references/dirs.json、events.json、policy-rules.md、time-rules.md＋5 张速览卡，无 scripts，属数据＋规则型，核法以对账为主。 先给正面（数据层经得起核，同类里少见）：events.json 实测 47 条，与教育部《2025—2028学年面向中小学生的全国性竞赛活动名单》逐项一致；cat 字段的三大类计数为 nature 22 / humanity 12 / art 13，与官方“自然科学素养类 22 项、人文综合素养类 12 项、艺术体育类 13 项”完全对上；抽查主办单位（n=1 中国少年儿童发展服务中心、n=13 中国计算机学会、n=16 清华大学）与学段（n=14 普通高中、中职）均无误；第 12 行引的“教监管厅函〔2025〕7号”经教育部官网核实确为 2025-10-22 印发的该名单正式文号，正确。policy-rules.md 三节适用赛事清单也与数据对得上（第 1 节 n=9/10/11/12/13 恰为 flag=olympiad 的 5 条；第 2 节 n=1/2/3/13/18/45 恰为 groups 含 AI 或机器人的 6 条；第 3 节 9 条与 groups 含科创的 9 条一致）。 硬伤一（届次冲突，跨文件且与官方不符）：time-rules.md 第 48 行写“2026 年第八届在浙江桐乡乌镇”，而速览卡 n1 写“2026 年第九届……8月15—16日在浙江桐乡乌镇举办决赛”。中国少年儿童发展服务中心《第九届……决赛通知》与 china61.org.cn 参赛指南均确认 2026 年为第九届（8 月 14—16 日、乌镇互联网之光博览中心）——卡对、规则错，时间规则文件落后一届。 硬伤二（算术不自洽）：time-rules 第 5 行标题写“（MVP 5 个速览卡覆盖）”，实际列了 6 项（n=1/2/4/13/14/16）；而第 60 行的“长尾赛事 37 项”只有按“6＋第 2 节的 n=9/10/11/12 共 10 项有节奏”才算得 47−10=37。标题的 5 与 37 无法同时成立。 硬伤三（数据不可达）：n=16 丘成桐在 time-rules 第 31-37 行有完整节奏（5—6 月报名启动、7—9 月论文提交、10—12 月分赛区评审、次年 1 月总决赛），但 SKILL 第 50 行只对 n∈{1,2,4,13,14} 输出速览卡，n=16 落入“其他 n”分支，只会拿到第 51 行的长尾统一回复——这 4 行节奏数据永无出口。 硬伤四（能力承诺不可交付）：description 把“订阅报名提醒”列为四大能力之一，意图四第 81-90 行还输出带“提醒方式：扣子站内信”与 D-7/D-1/当日三节点的订阅卡，但第 91 行自述“MVP 阶段订阅记录仅保存在对话上下文中”，跨天提醒无从触发。 硬伤五（悬空引用）：第 126 行称“由后端巡检脚本自动更新 events.json”，包内无 scripts/ 目录，全包也搜不到该脚本。 硬伤六（口径冲突）：第 110 行规定“表格列固定为：赛事名称|主办单位|适用学段|方向”，而第 62 行意图三要“标注每个赛事的强相关科目”、第 104 行意图五要“每项标注推荐理由”，都是第 5 列。 硬伤七（举例与数据不符）：第 67 行举例“科创类、人文类、艺体类（没有 subj 标签）”，实测 n=7 全国中学生水科技发明比赛（groups 仅科创）有 subj 化学/生物，n=16（科创＋理科）有 6 个科目；subj 实际只覆盖 47 条中的 10 条。 建议：① time-rules 第 48 行改为“第九届（2026）”并补“届次以主办单位当年通知为准”；② 第 5 行标题与第 60 行项数对齐（都给 5，或都按 6 算成长尾 41 项）；③ 把 n=16 从“其他 n”分支提出（已有节奏数据），或在卡片集合补一张丘成桐卡；④ 第 91 行把“订阅提醒”如实降级为“本会话内订阅清单”；⑤ 第 110 行改成“前 4 列固定，交互类意图可追加第 5 列”。

单文件包：SKILL.md 1320 行 / 65092 字节，无 scripts、无 references、无题库数据文件，属纯方法论型，逐章核过。 先说做对的地方：第 755-770 行的题目质量评分表五维相加恰为 10 分（来源可信度 3＋信息具体度 2＋多源重复度 2＋题目质量感 2＋时效性 1），且第 757 行「低于 4 分的弃用」与第 770 行「＜4分 弃用」分级一致；第 520-537 行单题四维各 25% 权重、等级五档 9-10/7-8/5-6/3-4/0-2 恰好覆盖 0-10 无缝隙；第 1103-1117 行公司风格速查的「高频考点/注意事项」写得具体可用（宝洁八大问、GCP 合规、投入产出比、别为了像字节而出刁钻题）。第 1275-1283 行的异常处理表也把七种现场情况都给了话术。 硬伤一（9×9 矩阵名不副实）：第 707 行自己写着「3 个典型组合示例」——互联网+AI×运营、金融×产品、制造业×运营三行，加第 715 行一句出题方法；而 description 和第 703 行标题承诺的是「9×9 行业×职业二维矩阵，专业题精准分类」。8.1 的 9 个行业（第 679-687 行）、8.2 的 9 个职业（第 693-701 行）都齐全，但两者交叉出的 81 格里有 78 格没内容，Agent 只能现场发挥，与「精准分类」的承诺落差很大。建议要么每格至少给 1 个考点关键词，要么把 description 改成「9 行业 + 9 职业 + 交叉出题方法」。 硬伤二（五维总评是展示品，不进公式）：第 543-549 行列了 5 个总评维度（表达逻辑/经历深度/结构化思维/岗位匹配度/抗压应变）并逐项映射到单题维度，可第 551 行的公式是「各题平均得分 × 0.7 ＋ 整体印象分 × 0.3」，五个维度一个都没进公式。且 6.1 单题维度是 1-5 分、6.2 等级是 0-10 分，公式里「整体印象分」按 0-10 还是 0-5 也没写，同一次面试换会话跑分不可复现。建议给五维配权重接入公式，或删维度表只留公式，并统一 0-10 口径。 硬伤三（章节自述与实体不符）：第 1101 行写「对应九大行业体系」，但该表实为 13 行，其中 12 行落在 8.1 的九个行业上，第 1117 行「创业公司」在九大行业里并不存在，也没写它归哪个行业。 硬伤四（承诺不可交付）：第 1161 行称「多轮对话中记住用户的训练情况，回来时接着上次的进度继续」，第 1178-1179 行还设计了「欢迎回来！上次我们练到了[位置]」；但全篇没有规定任何持久化载体（无文件、无台账、无用户端存储格式），第 1165 行要记的 6 件事里「进步对比数据」需要历史分数，只在对话上下文里跨天必失忆。建议如实降级为「本会话内追踪」，或补一个进度记录格式。 建议（按优先级）：① 8.3 补齐 81 格或改承诺；② 6.3 五维接权重、统一分数口径；③ 第 1117 行「创业公司」并入对应行业或在 8.1 增列第 10 类；④ 第十五章把「跨会话记住」降级为会话内追踪。

包内 3 个文件：SKILL.md（174 行 / 8037 字节）＋scripts/wuxing_calc.py（1174 行 / 51 KB）＋scripts/__init__.py，含可执行脚本，我逐个命令真跑了。 先说核过的账，这套代码与文档的对齐度是我近期核过的技能里最好的之一（以下均为实跑，非读文档推测）： 1）第 34 行的分类原则可复现：跑 `classify --keyword 毛纺`，实返回 关键词=毛纺、五行=水，与第 34 行「毛纺核心工序是洗毛、染整、梳理，全程与水打交道，故归水命而非木命」及第 42 行加粗的「纺织/毛纺/印染（工艺属水）」一致。 2）第 48 行的八卦数理映射全中：跑 `stock --code 603889`，末三位 [8,8,9] 判为 [土,土,火]、主气土，前缀 603 判为辅气金，与「8艮土、9离火、0取5中土」逐位对得上。 3）第 167-174 行的评分表逐条可复现：按第 142 行示例跑 `founder --company 新澳股份 --industry 毛纺 --name 沈建华 --year 1964 --month 3 --day 15`，年干甲木 vs 水 = −0.5（对应第 170 行企业生实控人 −0.5）、年支辰 vs 水 = −0.5（第 169 行辰为水库蓄水 −0.5）、纳音覆灯火 vs 水 = +1.0（第 168 行贪生忘克，输出还写了「水→木→火」链条）、日干癸水 vs 水 = +1.5（第 167 行同气共振），四维相加 −0.5−0.5+1.0+1.5 = 1.5，与输出的「综合评分 1.5」「中性偏吉」及第 174 行「0~3 中性偏吉」完全吻合。 硬伤一（文档命令直接跑不起来）：第 31 行写「执行 python3 scripts/wuxing_calc.py classify 获取行业五行分类」，实跑报错 `classify: error: the following arguments are required: --keyword`，该子命令必须带 --keyword，而 SKILL.md 全篇未写这个参数。失败点恰在「分析流程第 1 步确定标的五行」的前置环节，会连带后面整条线跑不动。 硬伤二（6 个子命令里 3 个零文档）：--help 显示 paipan/classify/stock/analyze/trend/founder，文档只写了 classify（第 31 行）、paipan（第 81 行）、founder（第 139-145 行）；我在 SKILL.md 里检索 analyze、--code、trend、stock 四个词，命中数为 0。而 description 明确宣传「股票代码数理五行分析」「多日能量走势推演」，第 96-99 行要的「当日能量评分 + 短期 3-5 日趋势」也全靠 analyze（--code --industry [--date]）和 trend（--industry --start --end）出货。照文档走只能拿到命格与排盘，拿不到第 114-116 行输出格式里最靠前的能量评分与趋势倾向。 硬伤三（「主气」一词两套定义，代码里也各认一套）：第 50 行说代码末三位判主气，第 76 行说行业定主气；实跑印证两条路径冲突——`stock --code 603889` 只给主气土（代码），而 `analyze --code 603889 --industry 毛纺` 在同一个返回体里同时给出「命格：水命（主气水，辅气金）」与「代码五行：土命（主气土，辅气金）」，主气既是水又是土，Agent 只能自己挑一个填进输出格式的「命格」栏。 硬伤四（分级边界不互斥）：第 174 行「≥5 大吉，3~5 中吉，0~3 中性偏吉，−2~0 中性，−4~−2 中凶，<−4 大凶」，3 同时属于中吉与中性偏吉、0 与 −2 同理。实跑 founder 仅给 --year 时综合分正好 0.0，代码归为「中性偏吉」，按文字「−2~0 中性」也说得通。 建议：① 第 31 行补上 --keyword 及关键词示例；② 把 stock/analyze/trend 补进分析流程（至少写全参数），否则能量评分与趋势无法交付；③ 全篇统一「行业气/代码气」，analyze 只保留一个命格字段；④ 第 174 行改开闭区间。另：第 10 行与第 121 行的「不构成投资建议」声明处置得当。

包结构：SKILL.md 17166 字节，加 references/方法论文本.md，加 templates/ 五张卡（观察记录卡、对象画像卡、材料实验卡、概念陈述卡、反差设定卡），version 1.0.4，版本历史一路记到 v0.1.0。骨架来自 Bramston & YeLi《Idea Searching for Design》的六步，转译为观察吸收→画像理解→提炼主题→材料实验→感官冲突→蓝海推演，前面加了 Step 0 问题诊断（三问宽窄体检），后面加了「三问自检」最小验收标准，整条线确实能拦住「只动手不动脑」。digital 环境还补了 5 种数字替代实验，纯线上也能跑 Step ④。 但内部口径有几处对不上，逐条实测： 一，成品清单少算。第 68 行「打开方式」和第 146 行的成品汇总（frontmatter 第 4 行 description 也一样）写「1 条主题 ＋ 1 张画像卡 ＋ 1 个材料小样 ＋ 1 个反差设定 ＋ 1 句概念陈述」；可第 103 行 Step ④ 要求至少做 3 组材料对比实验（硬×软、透明×不透明、旧×新……）、各做一个小样，第 107 行「至少 3 组对比小样」，第 138 行对照表写「材料对比小样 ×3」，templates/材料实验卡.md 也留了对比组 1/2/3 三格，references 转译表同样写「≥3 组对比小样」。用户照第 68 行只交 1 个小样，三问自检第 2 问（是否有材料证据支撑）照样过——验收标准在这里失效了。 二，「内部参考」其实随包发给用户了。第 191 行合规声明说「不绑定任何特定评分体系」，可 references/方法论文本.md 第四节标题就是「A层评分映射」，列了主题的深化与精炼、调研→概念的转化、批判与生成、反思与迭代四个评分维度；第六节还专门写「无任何留学/升学/作品集辅导敏感内容」。这文件自称「内部参考，不直接进入 B 层话术」，却被放进可下载包，等于把说好不进用户视野的评分口径原样交付。 三，模板有 5 张，正文一处都没指向它们。grep templates/ 只命中第 198 和第 201 行的版本历史；正文提到「模板卡」的第 171、175 行都不给路径。用户读完 SKILL.md 不会知道有能直接填的卡，Agent 也没有可加载的指针。 四，设计思维两套口径。第 156-164 行的衔接映射表用 Empathize / Define / Ideate / Prototype 四阶段，而它自己的 references 第 21 行写的是「设计思维七步（Define→Research→Ideate→Prototype→Select→Implement→Learn）」。 建议：①把第 68、146 行与 description 的成品清单改成「材料对比小样 ×3（或数字替代版 ×3）」，与第 103、138 行统一；②方法论文本.md 是你自述不进 B 层的文件，从包内移除，或至少删掉第四节评分映射；③在 Step ②④⑤⑥ 各给一次 templates/*.md 相对路径；④设计思维阶段名统一到一套。

包结构：总索引 SKILL.md 29 行，pm-toolkit/skills/ 下 4 个技能（privacy-policy 102 行、grammar-check 113 行、review-resume 114 行、draft-nda 116 行），加 NOTICE / LICENSE / README / CHANGELOG。四个技能末尾都确实各有一节「## 输出判据」和一节「## 国内落地注意」，这条声明是落实了的。 法域本地化是真做的，法条号码和要素我逐个核过，没有编：反不正当竞争法第 9 条商业秘密三要件（不为公众所知悉、具有商业价值、经权利人采取相应保密措施）、民法典第 585 条违约金过分高于损失可予调减、刑法第 219 条侵犯商业秘密罪、协议管辖的五个实际联系地点（被告住所地、合同履行地、合同签订地、原告住所地、标的物所在地）、个保法第 28 条敏感个人信息清单（生物识别、宗教信仰、特定身份、医疗健康、金融账户、行踪轨迹，加不满十四周岁未成年人），全部写对。隐私政策那份的第五步用「【需法务确认】」圈出出境路径、敏感信息范围、未成年人处理、对外提供依据、留存期限，是很实用的切分。 硬伤一：NOTICE 与 CHANGELOG 声明的规模与实际交付不符。NOTICE 第二节写「本作品对其全部 69 个做了中文重写」，CHANGELOG 写「69 个产品经理技能…（分 9 组：…工具箱 4）」，而包里只有工具箱那 4 个；平台描述本身也只写「4 个高频文书与审查技能」。买家从 NOTICE 读到 69，下载拿到 4。 硬伤二：NOTICE 第二节第 3 条声明「案例替换…替换为中国读者熟悉的产品与行业通例（钉钉、飞书、企业微信、抖音/巨量引擎、小红书、有赞、微盟、小鹅通、拼多多、美团等）。每个技能至少替换 2 处」。实测这 9 个词在 pm-toolkit/skills 下 0 命中，全包只有「微信」1 次、「小程序」2 次；同时境外例子（Basecamp、Slack、Figma、AWS、Salesforce、Spotify、Notion）也 0 命中。也就是说这一版做的是「把境外例子删掉」，不是「替换成国内例子」。第 4 条承诺的工具链本地化（MaxCompute、Hive、ClickHouse、Doris、PolarDB、QuestMobile、巨量算数、百度指数、微信指数）同样 0 命中——这 4 个技能偏法律文书，可以理解，但声明写的是「全部 69 个」，口径该跟着实际收。 硬伤三：grammar-check 的 `$目标` 没有兜底。第 14-17 行把 `$目标` 与 `$文本` 并列列出、都没标可选，但第 76 行输出格式要求「[语气与目标匹配度] 对照 `$目标` 评估」、第 93 行校清单要求「确认全文服务于 `$目标`」、第 105 行输出判据也要求给出与 `$目标` 的匹配度。用户没给目标时这三处全部落空。同一个包里 review-resume 的 `$目标岗位` 就明确标了「（可选）」，grammar-check 没做同等处理。 硬伤四：review-resume 第 45-49 行的「XYZ+S 表达公式」，定义 S 是「具体在 S 场景」，但示范句给出的 S 是「支撑企业客户版本提前约半年上线」——这是结果不是场景；同一句里 X 写「提升了路线图透明度与排期准确度」，Y 却用「排队等待率下降 40%」，Y 并没有在衡量 X。照这句抄，写出来是成果堆叠，不是公式。 硬伤五：privacy-policy 第 101 行列个人信息保护影响评估的法定情形时写了「处理敏感信息、自动化决策、委托处理、对外提供、出境」五项，漏了个保法第 55 条里的「公开个人信息」；留存至少三年的表述（第 56 条）是对的。 建议：①NOTICE 与 CHANGELOG 的「全部 69 个」改成与本包实际交付的 4 个一致，或按组分卷发布；②案例替换那一条要么实做（在 privacy-policy 的第三方 SDK 清单里换成国内常见 SDK 举例，在 review-resume 里点名具体招聘平台），要么删掉声明；③给 `$目标` 标可选，并补一句缺省时按文体自评语气；④把 XYZ+S 示范句的 S 换成真场景（如「用于企业客户版本评审会」），并让 Y 直接量化 X；⑤第 101 行的情形清单补上「公开个人信息」与「其他对个人权益有重大影响的处理活动」。

这批里工程规范度最高的一个：19 个文件，13 个子技能的 frontmatter name 与目录名 13/13 全对，13 个子技能每一个都实有「输出判据」与「国内落地注意」两节（逐文件核过，无缺项），署名也完整（README 写明改编自 PM Skills Marketplace，MIT，Copyright (c) 2026 Pawel Huryn，另有 NOTICE 逐项修改声明与 LICENSE-UPSTREAM-MIT.txt 全文）。summarize-interview 的合规段写得具体：逐字稿按《个人信息保护法》管理，收集前告知同意、存储限权并设保存期限、共享摘要做去标识化去掉姓名与联系方式，转写工具点名飞书妙记/通义听悟/讯飞听见，不是泛泛的注意合规。README 法律口径一栏声称的《个人信息保护法》《数据安全法》《网络安全法》《儿童个人信息网络保护规定》《民法典》合同编逐条检索全部命中（13/6/3/3/3 处）。 硬伤是 README 的声明跑在落地前面。在「跟国际通用版本的区别」表里，「案例」一栏列了 8 个国内品牌，但逐包检索 13 个子技能正文：钉钉、抖音电商、有赞、微盟、拼多多 五个 0 命中，只出现在 README 与 NOTICE 的声明段；真正进入正文的只有飞书（brainstorm-ideas-existing 与 summarize-interview）、小红书（brainstorm-experiments-new 与 identify-assumptions-new）、美团（identify-assumptions-new）。「工具链」一栏同理：MaxCompute、Hive、ClickHouse、Doris 只集中在 metrics-dashboard 一篇正文里，而 QuestMobile、巨量算数、百度指数 三个数据源在 13 篇正文里 0 命中，只有 CHANGELOG、NOTICE、README 提及。买家按 README 的表格去查这批把案例换成了哪些国内公司，查到的多半是空的。 建议：一、把 README 表格里 0 命中的 5 个品牌与 3 个数据源改成真实进入正文的那几个，或在对应技能正文里补上；二、表头加一列标注覆盖面（如出现在 13 个技能中的几个），避免表格被读成全局承诺。

4 份 references 共 1815 行，设备侧的颗粒度比同作者的质量包更实：hpdc_machine.md 第 2.3 节的压射速度总表按铝/锌/镁/铜四类合金分列慢压射 0.1~0.5、快压射 3.0~7.0、内浇口 30~80 m/s、充型 5~100 ms；第 6.1 节给了力劲 DCC 系列 13 个型号的合模力、压射力、压室直径与模板尺寸。算例逐项复核全对：CSS 等于 22.8×(1−0.50)×√3.94=22.63 in/sec，乘 25.4 得 574.8 mm/s 换算无误；增压压力的 psi 与 MPa 换算（2000 psi=13.8 MPa、20000 psi=137.9 MPa）也自洽。9 个品牌确实落地：第 6 章有力劲、伊之密、布勒、意特拉、宇部、富来、东芝 7 家规格表，万丰与高斯分别放在 gdc 第 7.2 节与 lpc 第 5.5 节。 硬伤一，示例的故障清单与它点名的表对不上。SKILL.md 示例 3 说读取 maintenance_debug.md 的故障诊断后按概率给出「蓄能器氮气压力不足 30% 大于增压阀响应异常 25% 大于冲头磨损泄漏 20% 大于液压油温异常 15% 大于其他 10%」，而该文件第 137 行「增压建压时间过长大于 20ms」这一行的实际内容是 ①增压蓄能器压力不足 30% ②增压阀响应慢 25% ③增压油路泄漏 20% ④油液粘度不当 15% ⑤PID 参数不当 10%。五个原因里后三个与表不符，且全表 12 行从不使用「其他」这一档，示例等于凭空写了半张表，而示例恰好是最容易被照抄的地方。 硬伤二，同一台 DCC1600 两处参数打架：第 2.2 节算例取压室直径 φ100mm，第 6.1 节规格表给 DCC1600 的压室直径却是 φ120/φ130，φ100 并不在列。 硬伤三，frontmatter 的 version 写 1.0.0，正文标题却是「铸造设备专家技能 V1.1」，平台描述也写 V1.0，三处不统一。 建议：一、把示例 3 的原因清单逐条换成第 137 行的原文，或注明「示意，实际取值见 §3.1」；二、算例的压室直径对齐到 φ120 并重算 CSS（约 24.8 in/sec）；三、version 与标题统一。

这是同一中文改写系列的第三包（市场调研 7 件套），合规与结构是该系列的强项，但两处老毛病也一并复发了。 先记正面。NOTICE 带上游 commit（phuryn/pm-skills @ 5924541d，2026-10-09），7 个子技能我逐个检索，全部具备 README 模板承诺的完整五节（适用场景/怎么做/输出模板/输出判据/国内落地注意），无缺节、无孤儿文件。内容质量不均匀但下限不低：sentiment-analysis 的「国内落地注意」是全包最值钱的一节——点出黑猫投诉天然只聚负面、跨平台直接平均会失真、要先做水军异常检测（同时段集中/话术雷同/新账号）、中文网络语（yyds、反讽）会误判极性，这四条都是真踩过坑才写得出的；market-sizing 的输出判据里「明确区分价值口径和数量口径，不混用」「指出最该优先验证的那条假设」也是行家话。 然后是两处硬伤。其一，根索引 SKILL.md 的七条技能说明有四条在句中被截断：第 13 行 customer-journey-map 结束于「优化新手引导、」、第 15 行 market-sizing 结束于「市场进入」、第 16 行 sentiment-analysis 结束于「找满意度规律」、第 18 行 user-segmentation 结束于「分析多样化用户反馈」——四条全是半句话。而 README.md 表格里的同一批条目是完整的（如 market-sizing 补全为「市场进入决策时用」）。根索引是平台打开包看到的第一屏，7 条里 4 条断句，观感直接塌掉，属于一分钟可修的复制截断。 其二，CHANGELOG 与 NOTICE 都白纸黑字声明「全部举例替换为国内产品与行业通例（每个技能至少 2 处）」。我按国内产品关键词逐技能计数：market-sizing 全文国内产品只出现「微信」1 次（且不在 NOTICE 声明的替换名单里），market-segments 只有「拼多多」1 次——7 个技能里 2 个不达标。此前该系列的上市策略集（6 件套）已被查出同样的声明不达标（34 个国内关键词 0 命中），两包相加可以定性为系列性「承诺超发」：合规声明写得很满，逐包兑现率却在打折。 小项还有三处：NOTICE 第 32 行「中华人民共和法律域」漏了个「国」字，恰在讲法域严肃性的句子里；market-sizing 第 54 行「SOM（可获取得市场）」多一个「得」、第 29 与 90 行「相关slice」是上游英文残留；子技能正文仍用 $ARGUMENTS 占位（如 market-sizing 第 24 行、sentiment-analysis 第 24 行），而 NOTICE 第四声明过不打包 slash command 封装层，平台不替换该占位时这句就是残缺指令。 改进建议：① 根索引四条截断直接从 README 表抄全；② 把「每个技能至少 2 处」改成实际达标，或给 market-sizing/market-segments 各补 1-2 个国内案例（如国家统计局口径的细分市场数据示意）；③ 修「共和法律域」「获取得」与 slice 残留；④ $ARGUMENTS 加一行「若你的平台不替换此占位，把用户输入填入此处」的兜底说明。合规骨架是同类里最好的，把承诺收敛到实际兑现即可上 4.5 档。

一份把「循环—动机—心流—数值—验证」讲得干净利落的单文件方法论：155 行装下核心循环五品类对照表（平台跳跃跑跳落收集、放置产出加速解锁自动化）、Bartle 四型驱动表、四种强化程式效果表、Source/Sink 经济公式（资源 = 初始 + Σ来源速率×时间 − Σ去向消耗）、GDD 九章结构表、六条反模式对照表与 7 项质量清单。抽查事实无误：抽卡行的「需概率公示、保底」合规提醒在正文出现 2 次，D1/D7 留存钩子有具体抓手（未完成目标/次日奖励），反模式表「先打磨画面再验证好玩 → 先做灰盒原型验玩法」这类条目可以直接当评审清单用。质量清单 7 项与正文十个章节逐一对得上，没有装饰性条目。 但它在自己 description 里挖了个接不住的坑。第 3 行招揽了两个触发场景：「玩法原型评估或拆解竞品时使用」。我把「竞品」「拆解」「评估」三个词全文检索——唯一命中就是第 3 行本身，正文十个章节加上质量清单没有任何竞品拆解的方法论（没有拆解维度、没有对标框架），原型相关内容只有 §一.7 一句「最小原型快速试玩，按数据迭代」和反模式表里两条原则，没有一条可执行的评估判据。用户照 description 问「帮我拆解一下某某游戏的数值体系」，技能会被触发，却没有内容可依，只能现场自由发挥——触发面承诺与正文库存断裂，这正是该类单文件技能最常见的病，而且病在第一行。 第二处是 GDD 表第 129 行：「| monetization | 付费点 |」，前导双空格加英文行名，夹在 Pitch、核心循环、机制、元循环/成长等一排中文行名中间，明显是上游英文稿没改净。顺带一提，这个表把「 monetization 」排在美术/音频之后，而它自己的工作流程 §一.6 把付费排在留存/新手之前，两处顺序不一致，属小瑕疵。 数值部分是全包最扎实的：放置类的主动/离线收益比例、加速倍率边际效应、转生重置三件事点得准；「长期 来源 ≈ 去向（关键资源保持稀缺与价值）」一句话顶得上很多长篇经济设计文的开源章节。但这章也只到「用电子表格/脚本建数值模型」为止，没给任何一个最小可用的模拟表结构或示例参数——对独立开发者来说，差的就是这一脚。 改进建议：① 要么补一节「竞品拆解」给个最小维度表（核心循环形态/数值节奏/付费深度/留存钩子/内容管线五列），要么把「拆解竞品」「玩法原型评估」从 description 删掉，别让触发词无库存；② monetization 行改成「付费/变现」对齐全表中文；③ §六补一个 10 行级的最小经济模拟表示例（列：资源、初始、来源速率、去向速率、周结余），把「建模型模拟」落到能抄的程度。做到这三条，这份手册的使用完整度会明显高一档。

先说结论：这个包的出处核验做对了一大半，但恰好在自己立的反编造铁律上漏了水。 我把它引用的两个出处都实测访问了一遍。唐山市陶瓷协会官网那篇（tstcxh.com/Home/IpPromotionDetail?id=21，页面标注发布 2025-12-19）确实存在，词元 001/003/004/005 的数字逐项对得上：天然骨碳含量不低于 42%、素胎磷酸三钙不低于 38%、白瓷白度不低于 80%、吸水率不大于 0.3%、抗热震性 160℃至 20℃热交换一次不裂、产地范围路北/开平/路南/高新 4 个区、企业 60 余家、年产能 4 亿多件、销售额 20 亿元、占出口 60% 与国内市场 90%——全部能在原页找到，感官特征一栏（晶莹透亮、瓷质轻巧、敲击清脆余音悦耳）也与词元 004 的转述一致。中国质量新闻网 2024-07-25 那篇报道同样真实存在，最高法再审认定「新骨瓷」冠名构成虚假宣传的案情与词元 002 相符。在一个遍地编造出处的众测环境里，4/5 词元可实核，这是真功夫。 但硬伤也在这里：词元 002 的依据写着「涉案商品经检测磷酸三钙含量仅 0.81%」，我把所引报道全文读了两遍，通篇只有案情与最高法观点，没有任何检测数值——0.81% 在出处里不存在；词元 003 的「注册号第 16325979 号」同样不在协会页面里，页面只写「2016 年获准注册」四个字没有注册号。两条都是「出处真实、数据悬空」：挂靠真链接来给编造数字背书，比直接编出处更难被识破。SKILL.md 铁律 2 明写「绝对不编造出处或日期」，5 条词元里 2 条踩线。 覆盖面是第二层问题。触发场景明写「送礼避坑」，而词元库 5 条的场景标签只有 真假辨别/选购/避坑/产地背书，没有一条送礼内容（预算档位、套装组合、贴牌礼盒怎么避坑都没有）——问送礼只能落进铁律 1「不敢作答」，等于 description 招揽的三个场景之一零库存；避坑也仅 1 条支撑。另外 SKILL.md 第 6 行「创建“唐山骨瓷真假查询”技能。」是生成期提示词残留，整份正文是写给「要去创建技能的模型」的口吻而不是能力说明；5 条词元的时效字段全部标「待复核」，包自己承认全部未复核。 改进建议：① 词元 002 的 0.81% 补一个可核的检测报道出处，核不到就删数字只留定性结论；② 注册号同理，或改引商标局公示页；③ 补 2-3 条送礼词元，把 description 承诺的场景填上；④ 把第 6 行改成直接的能力描述。底子是好的，把悬空数据清干净后可信度能上一档。

单文件知识型技能（skill_passive-house-design/SKILL.md，110 行 / 6300 字节），无脚本，按文档内容评。在国内被动房/PHI 这个细分领域，它的信息密度明显高于均值：第 23 行把 PHI Classic 判据一条条钉死（供暖年需求 ≤15 kWh/(㎡·a)、供暖峰值 ≤10 W/㎡、过热频率 ≤10%、n50 ≤0.6 h⁻¹、非可再生一次能源 ≤60），第 25 行单独给出 EnerPHit 的放宽口径（供暖 ≤25、气密可放宽到 n50 ≤1.0），第 26 行对齐 GB/T 51350-2019，数值核对后与官方口径一致；第 29 行专门警告湿热气候区 PHPP 必须把制冷负荷拆成显热与潜热、不能只卡 10 W/㎡，这是南方项目最容易漏的一刀；第 79 行的潜热式 Q_latent = g_s × 2501 × (1 − η_HRV_latent) 与第 82 行「水分潜热必须 ×2501 J/g」都对，第 80 行的日除湿量换算（g_s × 运行小时 × 3.6 = L/d）我复算成立；第 51 行提示「密度 25/35 kg/m³ 主要影响强度与尺寸稳定性，不能靠提高密度降 U 值」能拦住一个常见误区；第 33-39 行五大气候区保温厚度量级（严寒 250-300mm+、寒冷 150-200mm、夏热冬冷 80-150mm、夏热冬暖 30-60mm、温和 30-50mm）与国内实践基本吻合。 问题集中在它最需要准确的地方——定量算例。第 50 行给出石墨聚苯板 SEPS 的 λ ≈ 0.033，第 61-63 行据此给了三个可直接抄用的算例：墙面 150mm → U ≈ 0.206、屋面 100mm → U ≈ 0.303、地面 60mm → U ≈ 0.391。但按同一节第 47 行的定义 U = 1/(R_si + ΣR_layer + R_se) 复算：150mm 得 0.212（差 +0.006），100mm 得 0.315（差 +0.012），地面 60mm 只有 0.503——比文中高 0.112，相对偏差约 29%。反推可知地面那行要成立，要么 λ 得是 0.0251（不在第 50 行列的 SEPS/EPS/岩棉/XPS 四种材料里），要么厚度其实约 80mm，更像把 80mm 的算例错标成了 60mm。尴尬的是第 106 行的交付检查清单恰好写着「保温厚度/U 值换算用代码核算，非估算」，自己的示例却没做到。建议把这三个数改成脚本输出，并在示例旁注明取用的 λ、R_si、R_se（例如地面取 R_si = 0.17）；否则照抄地面一行会低估地板保温需求（U 算小 → 厚度选不足）。 第 41 行的反推公式 d_ins = λ × (1/U_target − ΣR_other) 也漏了表面换热阻。同节 U 的定义明确含 R_si 与 R_se，而第 41 行把 ΣR_other 定义为「除保温外各层热阻之和」并不含这两项，据此算厚度会系统性偏小。代入 U_target = 0.20、ΣR_other = 0.2、λ = 0.033：文中公式得 158mm，正确应为 153mm，约差 5mm（3%）；在薄抹灰或自保温砌体体系里会直接影响结露与达标余量。建议改写为 d_ins = λ × (1/U_target − ΣR_other − R_si − R_se)。 第三处表述含混：第 58 行「楼板下方为采暖区时，温差取修正系数（约 0.3）」——下方既然是采暖区、温差本来就小，为何还要乘 0.3？系数作用在温差上还是直接在 UA 上折算，依据出自 ISO 13789 还是 GB 50176，都没说，现场很容易用反。建议改写为「楼板传向下方非采暖空间/相邻空间时，按温差修正系数 f ≈ 0.3 折减」。 正面再补一句：第 103 行的交付物清单把「显热与潜热分算」「除湿量单位 L/d」「不混淆 Classic 与 EnerPHit」「内保温结露与热桥」列成可勾选项，第 105-110 行给出 6 条可验收检查项，Agent 技能能给到这种清单的并不多。扣分只在上述量化与规范口径，故给 4 星。

纯人设提示词包，单个 SKILL.md、92 行 / 4942 字 / 13719 字节，无 scripts，按文档内容评。完成度在同类多角色群聊包里算偏上：第 20-27 行给出 8 条班主任规则（点名 3-5 只、不许 OOC、不许人身攻击、20-150 字并允许动作描写、任务类先按性格反应再给建议、可 @同学、记住共同事件、称呼默认「蛋导」）；第 32-92 行是 21 张按【序号｜名字｜身份】编号的角色卡，每张统一含蛋仔配色、性格、口头禅、擅长与短板、与他人的关系、说话节奏六个要素，编号 1 到 21 连续无缺，与描述里的「21 只」对得上。多数关系是双向写的：咕噜噜（第 44 行）与懒洋洋（第 71 行）互称零食搭子，胆小小（第 59 行）与暖阳阳（第 89 行）互称最亲，风驰驰（第 47 行）与摇滚滚（第 77 行）互为竞速搭子。 三处实在的短板。第一，第 26 行的规则 7「记住共同事件：班级任务、比赛、吵架、和好、秘密」没有任何载体——全文搜「记录」只命中第 41、74、92 行三处，且都是角色人设里的「擅长记录」（软绵绵记录班级日常、正义正记录表现、影默默擅长观察记录），没有一处规定事件写在哪、何时写、下一轮怎么读回。21 张卡是纯 prompt，会话一旦长到触发上下文压缩，此前积累的「吵架/和好/秘密」整体丢失，规则 7 等于没有；而这偏偏是整个包最有价值的设计（有共同记忆才有班级感）。建议明确落盘位置，例如约定 class-log.md 并在第 26 行写清「每 N 轮把新的班级事件压成一行追加，开新会话先读回」。 第二，关系网没有闭合。第 86 行冷逻辑写「和糖霜霜互相欣赏」，但第 35 行糖霜霜卡里完全没提冷逻辑；第 56 行咪咪呜写「和冷逻辑互相不服」，第 86 行冷逻辑也没提咪咪呜；第 41 行软绵绵写「和花小园、暖阳阳亲近」，第 80 行花小园只认暖阳阳是治愈组。单向声明在单角色卡里不算错，但 21 只同场时会出现「A 一直找 B，B 却对 A 无感」的割裂。建议直接给一张 21×21 关系矩阵，或把「互相关系必须双向声明」写成硬规则。 第三，配色撞车：第 32 行圆小燃与第 68 行戏精精都写「红色蛋仔」（另有第 77 行摇滚滚「黑红色」）。21 只同框时两只纯红蛋仔会明显混淆，而配色是读者区分角色的第一抓手，把其中一只改成酒红或红白相间即可。 另外，第 16 行要求「输出为多角色群聊对话格式」，全文却没有一个示例对话，是否带名字前缀、@同学插在哪、动作描写用括号还是斜体全凭模型发挥，首次使用拿不到稳定格式，补 2-3 轮示例会明显降低上手成本。综合给 3 星。

包内只有一个 SKILL.md（doubao-daily-checkin/SKILL.md，6524 字节 / 78 行），纯流程型技能、无脚本可跑，只能按文档逐条评。骨架是合格的：第 10 行给出「网页版优先、客户端兜底」的两级策略，第 19-21 行的三层决策（默认 A 网页版 → 连续失败才转 B 客户端 → 两者都失败就如实报告）把边界收得很紧；第 78 行要求报告必须区分「已签到成功 / 今日已签到过 / 失败+原因」，第 77 行限定「遇到签到外的诱导（抽奖、分享、付费、开通会员）一律不执行」，第 62 行明确「不得输入、索要、暴露或推断密码、验证码、cookie 等敏感信息」，第 60 行遇到登录/扫码/二次验证立即引导用户接管而不是硬闯。这几条诚实性与安全约束在国内签到类技能里属于中上水准。 但有一个会把成功判成失败的逻辑缺口。第 35 行写「若页面没有独立签到入口、但显示『登录即领积分』等规则，视为登录态本身即完成领取，跳到第 5 步验证」；而它跳到的第 5 步（第 42-44 行）只认四类信号——『签到成功』『已签到』『+N 积分』『积分 +N』或积分页的已领取状态。如果『登录即领积分』确实生效、页面却只留下活动规则文案（这类活动通常登录后静默入账，根本不弹签到类提示），第 44 行就会判「既无成功提示、也无已签到状态 → 视为未完成」，再按第 20 行转 B 客户端流程；可 B 流程第 55 行同样是去积分面板找「签到 / 每日签到」按钮——同一家产品网页端没有该按钮，客户端大概率也没有，于是白绕一圈回到第 21 行「如实报告失败」。一次已经完成的领取被报成失败，用户还会照失败去重试。建议在第 42 行的信号清单里补第四类「登录态确认 + 页面出现登录即领积分的活动规则即视为已领取」，或直接规定「网页端不存在签到按钮时不得转 B 流程」。 第二处是小而实际的问题：执行链被完全外包给了另一个技能。第 14、68、70 行三处把定时任务的创建交给 doubao-cron-scheduler（第 68 行还写死了 schedule_type 取 cron 与 `0 12 * * *` 的示例），可 frontmatter（第 1-4 行）只有 name 与 description，既没声明这项前置依赖，正文也没有任何兜底路径。该技能一旦未安装，第 67-71 行整节落不了地，而「每天自动签到」恰恰是本技能最常用的调用方式。建议在正文顶部写明依赖并给一条替代做法。 第三点属于体感：第 15、27 行两次强调「不依赖固定坐标或固定选择器」，方向对（豆包页面会改版），但全文没有任何可对照的锚点示例（积分入口的常见文案或路径都没有），第 42 行的成功信号也纯是文字枚举，实际执行全靠模型现场看图，效果波动大且难排查。综上，流程与安全约束扎实，但上述分支缺口与未声明依赖压住上限，给 3 星。

信息密度很高的一个包：5 份 references 共 1790 行，process_calculations.md 有 21 节 68 个小节，defect_diagnosis.md 12 节（含第 7 节常见误判场景、第 11 节数据造假识别、第 12 节 EV 专项），iatf16949_mapping.md 的条款总表引的是 7.1.5、7.1.5.1、8.3.3.1、8.5.1.1、9.1.1.1、10.2.5 这类真实条款号，不是空喊口号。第 11 节数据造假识别最有价值：列了 5 条统计异常模式（30 件样品标准差小于公差的 1/20、数据集中在公差中点 ±0.01 mm 内、末位数字应 0-9 各约 10%），每条都配判定依据与审核动作，这个角度在同领域技能里很少见。 硬伤一，缺陷分类挂错了标准。defect_diagnosis.md 第 5 行的标题写「缺陷分类（按 ISO 8062 标准）」，但 ISO 8062 系列（现行 ISO 8062-3:2023）规范的是铸件尺寸与几何公差等级 CT1–CT16 以及加工余量，与缺陷分类无关，表里的 100/200/300 分类号也不是 ISO 的编号体系。 硬伤二，第 19.3 节公式与它自己的参数表差两个数量级。伯努利式 v_fill 等于根号下 2 乘以 ΔP 减 ρgh 再除以 ξρ，代入它给的推荐值（ΔP 0.03~0.04 MPa、ρ 2400~2600、h 0.3 m、ξ 1.5~3.0）算出 2.5~4.2 m/s，而紧接着的参数表写 v_fill 推荐 20~50 mm/s。同一个符号混用了内浇口速度与液面上升速度，照公式算完再拿表判定，结论必然判成严重超范围。 硬伤三，平台描述承诺「对标 IATF 16949+CQI-27+Ford/GM/Stellantis 客户特殊要求」，而 Stellantis 全包 0 命中，Ford 仅 4 处、GM 21 处且都只在 iatf 与 defect 两份文件里，三个客户特殊要求这条最像凑数。 硬伤四，公式数三处口径不一：平台描述写 50+，SKILL.md 第 5 行 description 与第 27 行小标题都写 40+，而 2.1 节实际只列了 29 条。另 defect_diagnosis.md 第 378 行有衍字「真实铸铸件尺寸」。 建议：一、把第 5 行的标准名改成 ISO 11971（表面不完美）或注明分类号出自本技能自建体系；二、在第 19.3 节明确 v_fill 指内浇口速度、另设液面上升速度符号，或把参数表改成与公式同量级；三、补上 Stellantis 的对应内容或删掉该署名；四、公式数统一成 2.1 清单的实际条数。

技能本体是三条发帖习惯（先落回执、五类分级、耐心回读），助手只有 71 行标准库代码。实跑验证了它的正面承诺：attempt 第二次调用同一路径确实抛 FileExistsError（独占创建生效）；settle 在 ok 且 found 命中时返回 verified，并把 status、response、kind、answered_at、state 全量写回回执；refusal 分支不回读；`403 + Cloudflare error code: 1010` 判成 refusal，与文档里「边缘防护拒绝也要先带真实身份 UA」那段吻合；模块确实零网络依赖。 决定性问题在 classify（第 42-51 行）：2xx 分支用全文字符串子串 pending、review、审核 判「审核中」。实测 classify(201, JSON 里 status 为 published 且带 review_url 字段) 返回 pending，带 preview_url 字段也返回 pending（preview 里含 review），中文「审核通过」还是 pending。也就是说一条正常发布成功的帖子会被判成「审核中」，而防重复帖正是这份技能的第一条铁律——模型会一直等回读、不敢收尾。建议改成解析 JSON 取 status 字段，退一步也应只匹配 pending、审核中 这类精确词，并显式排除 preview。 第二处：REFUSAL_WORDS 含 safety，且第 47 行的判定排在 5xx 之前。实测 classify(500, internal safety check failed) 返回 refusal，而 SKILL 的分类表里 5xx 属于 unknown（先读目标，确认没发出去）。一次可能根本没发出去的服务端故障，被当成对方明确拒绝并要求停手，方向正好相反。 第三处：404 被归入 fixable（第 49 行），可是分类表把 fixable 定义为 400 缺字段、422 格式错——端点不存在，改正文救不回来，判 fixable 会诱导重发。 第四处：文档示例是 attempt 传一个 replies 子目录下的回执路径，实测父目录不存在时直接 FileNotFoundError。而这恰是流程第一步。建议在 attempt 里加一句：先 Path(path).parent.mkdir(parents=True, exist_ok=True)。

自带测试套件实跑 85 PASS / 0 FAIL，是同类包里少见的回归基础。几处设计值得肯定：评分按根因去重（多个部件同属「缺少量化依据」只扣一次 12 分）；推销项与安全项的互斥方向正确——实测「刹车系统深度清洗」不进安全项、「更换前刹车片/刹车盘」进安全项、刹车油等纯耗材被排除；testdata_bad 的逐行算术与合计 4010 全部自洽；否定语境在推销项检测上确实生效。 但否定处理的作用域太窄，导致结论反转。_is_negated 只接在 check_upsells 与 check_vague_terms 上，分类、依据检查、安全项一律不走它。实测一行「不需要更换刹车油」被 classify_item 归成「到期保养」、输出建议「按手册核对里程后执行」，还额外触发 high「缺少量化依据｜刹车油」。修理厂明确写了「不需要」的项目，工具反过来建议落地，这与它第 5 条原则「依据不足不等于必要」是同一类错误。 第二处：SKILL.md 那两张量化判据表（刹车片 3mm 更换点、2mm 临界，刹车盘 MIN TH 与 DTV 0.010-0.015mm，唇边 1.5mm，刹车油含水率 ≥3%，周期 2 年或 4 万公里，节气门 6-8 万公里）在脚本里 grep 全部 0 命中。EVIDENCE_REQUIRED 只对关键词做存在性判断，而且第 397 行是把整张单拼成一个 text 再搜——实测报价单写「原厂件，剩余厚度8mm」「含水率1.2%，检测合格」就输出「未检出算术、配件、依据或推销类问题」并给 100 分。只要单子里任何一处出现「厚度」二字，刹车片与刹车盘的「缺少量化依据」会被一起豁免。建议 EVIDENCE_REQUIRED 改为按行匹配，并把抓到的数值与阈值比对（低于 3mm 应提示已达更换点、含水率 ≥3% 应提示需更换），而不是只认关键词。 第三处：「四轮定位」在脚本里只出现 1 次，就在第 166 行的注释中，「跑偏」0 命中。实测把症状写成「跑偏，方向盘不正」（正是 SKILL 第 62 行列出的 5 种应做定位的情况之一）时，四轮定位仍只输出「待判定」，那条最实用的「正常换刹车片不需要四轮定位」没有落地。建议单列一条检查：同一张单同时出现刹车片或刹车盘更换与定位项目，且症状里没有那 5 种情况时，提示该定位很可能不需要。

实跑验证：selftest 输出「自检通过: 61/61」，与文档宣称的 61 项断言一致；rules 子命令列出 38 条规则，与 SKILL.md 的分类清单逐条对得上；examples/good 零误报 exit 0、examples/bad exit 1；退出码语义也实测吻合——空目录 → 3（零输入）、不存在的路径 → 2、有命中 → 1。纯标准库、不联网、确定性输出，在离线体检类工具里是稀缺设计。 但 mixed_content_http 这一条双向都有问题，是本包最该修的地方。我自造了一份 http 页面，其中 `<link rel='canonical' href='http://www.example.com/p/'>` 被报成 high「canonical 资源走 http」。canonical 不是浏览器要加载的子资源，永远不会被 mixed-content 拦截，报它属于误报；而且这条规则从不检查页面自身的协议（canonical 为 http 时页面本身也可以是 http），措辞却是「HTTPS 页面引用 http:// 资源，被浏览器拦截」。反过来，同一份页面里的 `<script src='http://cdn.example.com/a.js'>` 与 `<img src='http://cdn.example.com/b.png' width='10' height='10'>` 这两类真正会被浏览器拦下的，一条都没命中——第 342 行的循环只遍历 link 与 a 标签。 第二处误报：`<a href='/detail'><img src='/c.png' alt='查看详情' width='10' height='10'></a>` 被判 anchor_empty_text「链接无可读文本」，但图片 alt 就是它的可访问名称。根因是 handle_data 只把文本节点并入链接文本，没有采集子 img 的 alt。 第三处失效：标题「热搜词热搜词热搜词低价正品」没有触发 title_keyword_stuffing。第 232 行按空白与分隔符分词，无空格的中文标题整串算一个词、计数恒为 1，所以中文站最常见的堆砌形态检不出来。 建议：① mixed_content_http 改扫 script、img、stylesheet 型 link、iframe 的 src 或 href，并先取页面自身或 canonical 的 scheme，非 https 直接跳过；② 链接可读文本判定时把子 img 的 alt 并进来；③ 中文标题改用 2 到 4 字滑窗 n-gram 计重复次数。

零脚本，273 行 SKILL.md + capability-boundary.md 168 行 + interpretation-guide.md 148 行，外加双语 README。整体设计思路清楚：把六项能力按数据依赖分三级（可执行 / 降级能 / 需授权或需数据源），再配一张 8 条的高风险话术黑名单和四种回应模式加一段判断流程，把降级路径写成了可执行的分支，而不是只喊一句不要编造。第 48 行给飙升榜第一是谁这类问题准备的那段标准回话完整、克制，可以照抄，这是同类纯提示词技能里少见的扎实。 但硬伤落在它自己的立身之本上：文档里仅有的几个示范范例，词曲作者和歌词都写错了。 一是 references/capability-boundary.md 第 38-39 行，模式 A 的范例写「找到《晴天》——周杰伦，收录于专辑《叶惠美》（2003）。林俊杰作曲，方文山作词」。《晴天》的词、曲均为周杰伦本人（百度百科创作团队表与 QQ 音乐曲目信息一致：作词 周杰伦 / 作曲 周杰伦），把另一位歌手林俊杰安到了作曲位，作词也错。 二是 SKILL.md 第 77 行「Tomy 陈光荣作曲，林夕填词」：填词对，作曲错，该曲作曲是泽日生（Christopher Chak），陈珀与江志仁编曲。 三是 interpretation-guide.md 第 22 行「方文山作词，与《东风破》同期」：《稻香》同样是周杰伦词曲（编曲黄雨勋）；《东风破》属 2003 年《叶惠美》，《稻香》属 2008 年《魔杰座》，相隔五年，同期不成立。 四是同一文件第 15 行称《稻香》「以稻田、蝴蝶、旧书包为核心意象」，而逐字核《稻香》全词，出现的是稻田、河流、萤火虫、蜻蜓、稻草人、纸飞机，没有蝴蝶，也没有旧书包。 五是第 91 行的解读示例把「故事的小黄花」称作「副歌那句」，并引了一句「出生那年泛黄的照相纸」——《晴天》原词是「故事的小黄花，从出生那年就飘着」，全词没有照相纸；且这句是主歌首句，副歌是刮风这天、我试过握着你手那几句，既引错词又标错段落。 这五处涉及的歌手署名、专辑年份、歌词内容，恰好都在 interpretation-guide 第二节的「可以凭知识陈述」清单里，也正是它第 24 行要求「不确定的年份、专辑、词曲作者不要编」的地方；而这些范例又是用户最容易照抄的部分。 另一处是计数不统一：SKILL.md 第 34 行说「6 项能力」，核心能力一节有 6 个编号小节，但第 36-44 行的能力边界表实有 7 行，多出的是「相似歌曲推荐」；capability-boundary.md 第 11 行也写六项，紧接着的分级表同样是 7 行。同一个六对着一张七行的表，而相似推荐究竟是独立能力还是并进第 6 节，全文没说清。另外「每日推荐」的档位在各处不一致：分级表（第 13-19 行）标它不能，模式 B（第 66 行）把它列为降级能，模式 D 又把它列为可绕过，判断流程里再单列一次。 建议：一、把上述五个范例按权威源逐条订正（《晴天》词曲周杰伦、《富士山下》作曲泽日生、《稻香》词曲周杰伦并删掉两个不存在的意象），并在第二节补一句「范例里的词曲作者与年份发布前必须回源核一次」；二、相似歌曲推荐在计数与核心能力编号里二选一，统一成 6 或 7；三、每日推荐在分级表里改成「降级能（用户口述偏好可绕过）」，与模式 B/D 对齐。

文档自洽度是本批最好的一个：171 行 SKILL.md + 三份 references（style-guide 109 行 / knowledge-map 83 行 / report-schema 81 行）+ 441 行 cultivation.py。SKILL.md 第 72-79 行的六重境界表（心法/原理/破境/心魔/法器/试炼）与 style-guide.md 第二节逐层同名同序，连 20-40 行的代码行数与 3-5 个高频错误两处数字都对得上；knowledge-map 的十大洞天与 cultivation.py 第 55-66 行的 KNOWN_DOMAINS 逐项一致，实测 realms 返回 10 个境界。 实测正面：熟练度「只升不降」确有其事（第 191-193 行）——先记 4 级、再用 2 级复习，返回 action=revisit、mastery 仍是 4；reset 不带 --yes 返回 ok:false 加 error 文案且退出码 1，与第 155 行的退出码约定一致；stats 的 domain_coverage.missing 与 KNOWN_DOMAINS 完全对齐。 硬伤一（最要紧），渲染报告这一步照文档做会卡住。SKILL.md 第 115 行要求「在调用 show_widget 之前，必须先调用 widget_guidelines（modules 传 chart 和 diagram）」，references/report-schema.md 第 3 行与调用链路第 12 行又各写了一遍同一个工具名，三处都点名 widget_guidelines；而平台实际只有 read_me（参数名 modules，取值含 chart/diagram）。渲染进度报告是本技能阶段 4 的核心交付，工具名对不上会直接断在这里。 硬伤二，--tags 归一化两条分支不一致。新建分支第 214 行是 [t.strip() for t in args.tags.split(',') if t.strip()]，而复习分支第 201 行只写 args.tags.split(',')。实测传 --tags 面试高频 , 必背：新建的「闭包」得到 ['面试高频','必背']，复习的「HTTP缓存」得到 [' 面试高频 ', ' 必背 ']。同一个参数、结果随知识点是否已存在而不同，带前后空格的标签会让此后按标签检索失配。 硬伤三，domain_coverage 的 covered 与 missing 口径不同，算术不闭合。第 307 行 covered = len(domains) 数的是「实际出现过的域」（含非标准域），第 309 行 missing 却是按 KNOWN_DOMAINS 反查。实测传一个非标准域名，得到 covered=1 而 missing 仍列出全部 10 个洞天，1+10=11 不等于 total_known=10；而 report-schema 第二节第 3 条恰恰要求展示「covered/total_known 个洞天已开辟」，会渲染出一份自相矛盾的报告（1/10 已开辟，同时 10 个未开辟）。 建议：一、把三处 widget_guidelines 统一改成 read_me；二、第 201 行改用与第 214 行同一套清洗；三、covered 改成 len([d for d in KNOWN_DOMAINS if d in by_domain])，或在报告里改用 covered 与 missing 之外的第三个数。另外脚本依赖 python 命令，本机 python 可用（实测 PATH 内有 3.13），但 Windows 新装环境常只有 py 启动器，第 169 行的已知限制可补一句 py -3 的备选写法。

本批完整度最高的一个包：370 行 SKILL.md + 三份 references（rate-structure 246 行 / coverage-review 298 行 / negotiation-playbook 187 行）+ 1024 行 quote_audit.py + 161 行冒烟测试 + 两份样例报价单。核心工作纪律（交强险可精确核算、商业险因自主定价系数浮动 [0.5, 1.5] 只给区间、不给单点市场参考价）写得很克制，第 84 行那句「下限不是主流值」正好点中同类工具最常见的错法。 实测正面：直接跑 test_quote_audit.py，66 项断言全 PASS 且零外部依赖；拿自带 testdata_bad_quote.txt 跑 CLI，交强险算出应缴 665 元、报价 950 元、差额 285 元并判「偏高 285.0 元」，与 SKILL.md 示例一的 665/950/285 逐项一致——文档没有美化示例。否定语境也实测有效：good 样例里的「没有代办手续费，没有搭售任何额外项目」没有误报，bad 样例里的「代办手续费 200 元」正常命中。 硬伤一，报告章节编号会跳号。format_markdown 里十一个小节的编号是写死的中文数字，而「非正规产品」「疑似搭售」两节是条件追加的，不命中就整节消失。实测 bad 样例输出为「五、报价单完整性 → 七、未明示费用 → 九、附加险项目清单」；good 样例更短，是「五 → 九」。SKILL.md 第 202-245 行的输出格式模板承诺的是完整报告，跳号会让用户以为报告被截断。 硬伤二，报价单里明明有的排量、城市、车价，被报成信息缺口。audit() 的 docstring（第 651-654 行）写「seats / level / province / displacement / vehicle_type：未能从 text 自动识别时手工指定」，但实现里只有座位数（第 661 行）和出险档位（第 663 行）真的从文本识别，province 与 displacement 直接透传（第 664-665 行）。拿它自带的 testdata_bad_quote.txt（正文含「1.5T」「杭州市」「车辆购置价 18.6万元」）实测，报告列出三项缺口：车辆排量、用车城市、车辆购置价——三项全在输入里。补上 --displacement 1.5 --province 浙江 后，车船税立刻算出「浙江 排量 1.5L → 300 元/年（大于 1.0L 至 1.6L 档）」。 硬伤三（较轻），商业险表格被行间引用打断。第 852-864 行每写一行表就紧跟一行 `> 险种 建议：…`，GFM 遇到表格外的行会终止表格，实测四个险种各自成一张单行表加一段引用，表格无法整体渲染。 建议：一、把十一节的编号改成动态生成（enumerate 计数），或空节补一行占位；二、给 displacement / province / vehicle_value 补文本抽取（如排量 `(\d\.\d)\s*[TL]`、城市查常见城市名表），或在 docstring 里如实写明只有座位数与出险档位可自动识别；三、把 `> 建议` 统一移到表格下方，保住表格。另建议给 rate-structure.md 第 32 行那句「2026 年 6 月 1 日起执行的新规则」补上发文机关与文号——该时点我未核到出处，而这份文件自称是「唯一数据依据」。

包体检：SKILL.md 192 行 / 10220 字节，另有 references/motion-canvas-verification.md（54 行）与 NOTICE / README / CHANGELOG / LICENSE / LICENSE-UPSTREAM-MIT.txt，无 scripts 目录。 先说做得好的。内容的具体度是同类里少见的：「常见失败模式」表 14 行（第 42-57 行）、「仪表自证」表 7 行（第 130-138 行）每条都带真因——motion.ps1 因无 BOM 被按 GBK 解码吞掉行、从头到尾没执行（测的是静止桌面）；口径把 next_frame(timeout) 的等待算进采集工作（应拆成 capture_ms 与 capture_wait_ms）；第 57 行要求「期望值来自被测系统之外的第三方（操作系统 / 对端 / 外部靶子 / 独立解码器）」，第 144 行把理由说透：「若期望值与实现共用同一个公式/函数/常量，这条断言结构上不可能失败」，而第 57 行的结论是若由被测方自己算「两边同错，测试恒绿」，是很硬的方法论。第 55 / 135 行把「未测」与「失败」分开（前提不成立报未测，不许报失败），第 146 行用 WebSocket 断开后仍推流、常驻内存 350MB vs 真值 46MB 的实测说话。署名也规范：NOTICE 写明上游 obra/superpowers @8ca22db、Copyright (c) 2025 Jesse Vincent、MIT，并随包附许可全文。 下面三处拖后腿。一、references/motion-canvas-verification.md 是孤儿文件：SKILL.md 对 references / motion-canvas / 专项验证 的检索各 0 命中（唯一的 motion 命中在第 132 行，是无关的 motion.ps1），照 SKILL.md 走永远读不到这份专项验证（tsc 检查 + Edge 9222 调试端口 + 逐场景核验），而 README 却写「需要参考细节时，Agent 会自动读 references/ 下的文档」。二、有两处未填的占位符：references 第 34-35 行「# <工具> → url」「# <工具> → 检查红色 error」，SKILL.md 第 69 行「没有实际执行 <工具> → 欺骗」——全文没写这个工具是什么（从第 33 行「使用 MCP chrome-devtools 连接」可推断，但既没写装法，也没写这套 MCP 不可用时的替代），照抄执行不了。三、CHANGELOG 第 5 行与 NOTICE 第 2 节都写结构为「SKILL.md + references + scripts」，README 的内容节也列了 scripts，而实测包内没有 scripts 目录、SKILL.md 里 scripts 命中 0；README 的环境要求节写「见 SKILL.md 内的说明」，SKILL.md 却没有任何环境要求节；NOTICE 第 2 节还声称补了「安装说明、环境要求、适用与不适用场景」，而 SKILL.md 只有「何时使用」。一个专讲交付前验证的包，自己的交付物元数据没过验证，这处反差挺好修也最该修。 改进建议：一、在 SKILL.md 里加一行指向 references/motion-canvas-verification.md（或在该节标题后直接内联链接）；二、把两处 <工具> 换成实际工具名，并补一句缺失时的降级（回退到 npx tsc --noEmit + 手工打开 Console 看 error）；三、删掉三处 scripts 的空承诺，或真补一个自检脚本，同时给 SKILL.md 加一节最小环境要求。

这是本批最薄也最不可用的一个包：解压后只有一个文件，且文件名是全小写的 skill.md（os.listdir 实测），不是 SKILL.md，大小写敏感的加载器根本找不到入口；正文 1231 字节 / 25 行。 第二个硬伤是完全没有元数据。文件第 1 行直接是「# 价值投资信号捕获策略」，没有 YAML frontmatter——text.split('---') 段数为 1（正常应 3），即 name / description / version 一个都没有，平台的索引、展示与触发都无据可依。 第三是宣称的能力没有实现载体。使用步骤第 11-13 行承诺「Agent 自动抓取最新财报、估值分位及资金流向等核心数据」并「运行『护城河+安全边际』双因子信号模型进行交叉验证」，但包内除这一个 md 外零资产：没有数据源、没有接口、没有依赖声明，双因子信号模型也没有任何判据或公式（护城河怎么判定、安全边际取哪一档历史分位，全文未给）。四步流程里的第 2、3 步按文档无法执行。 第四处是合规口径自相矛盾：输出格式第 20 行要求「操作建议：[具体仓位比例与买卖价格区间]」、第 13 行还要给「止损位」，而注意事项第 3 条写「信号仅供参考，不构成直接财务建议」——给出具体仓位比例与买卖价格区间正是直接建议，两句话不能并存。 另外两处：第 23 行「本工具基于2026年10月最新市场数据模型」是写死的时点声明，没有数据口径也没有更新机制；触发词里的「巴菲特二世」（第 7 行）是人格标签，不是可执行触发条件。 改进建议：一、改名 SKILL.md 并补 frontmatter（name / description 至少两项，description 写清不预测涨跌、不荐股）；二、把双因子信号模型落成可执行判据（护城河维度清单 + 安全边际的分位阈值），并写明数据来源，以及取不到数据时输出「数据不可得」而不是让模型自行编数；三、在具体仓位比例与买卖价格区间、止损位这三项与免责声明之间二选一，要么删掉它们，要么把声明改成与之一致的教学口径。

整包体检：只有一个 SKILL.md（5656 字节 / 75 行，目录名 finance-logic-card），无 scripts / references / assets，只能核文档本身。 最重要的问题是一份被点名的内容包没随包发出来。Changelog 第 75 行明写「配套 finance-logic.json 内容包」，执行步骤第 2 步要求「引用内容包 knowledge 中真实存在的术语/策略/风控动作」，第 4 步要求「按内容包 media 出一张氛围图」；但全包 grep「finance-logic」只有 2 处命中（frontmatter 的 name 与 Changelog 那句），解压目录里也确实只有 SKILL.md 一个文件——既没随包分发，也没写去哪儿取。术语侧还有兜底（第 35 行「没有对应条目的，按通用金融常识准确表述并注明为通识」），media 侧没有兜底，配图只能临时发挥。 第二处是口径张力：核心定位第 13 行把「不产生实盘操作指令」列为三个绝对不之一，而输出格式第 46 行【风控处方】给的三个示例是「保留一定比例现金、分散到不相关资产、给每笔投入设上限」——都是配置层面的具体动作，对新手更接近操作建议而不是「极轻量风险控制小动作」。 正面证据三条：心理悄悄话的字数口径「70–90 字」在第 49 行与出卡前自检第 60 行两处一致（全包 3 处、无第二种写法）；卡尾声明第 54 行与 description 里承诺的「不构成投资建议」声明逐字对应；安全流程给的是 12356，这是真实存在的全国统一心理援助热线，且第 33 行与边界第 69 行两处一致，没有编造热线号。 改进建议：一、把 finance-logic.json 打包含进包内，并在 SKILL.md 补一节字段说明（knowledge / media 各自的 key 与最低条数），或删掉 Changelog 那句承诺、把第 2、4 步的「内容包」改为「通用金融常识」；二、把【风控处方】的示例换成纯纪律动作（如「投入前先写下你能接受的损失上限」），或在示例后补一句「示例仅作风险意识提示，不构成配置建议」。

集合宣称 16 个技能，目录实数 16，且 16/16 都有「输出判据」和「国内落地注意」两节（逐个 grep 计数各 1 次），这种一致性在本类合集包里少见；prioritization-frameworks 的「9 种方法」表格（第 63-71 行）实数恰好 9 行，ICE=I×C×E、RICE=(R×I×C)/E 公式与通用定义一致，第 122 行还专门提醒 RICE 的 Reach 在国内要统一 DAU/注册口径。dummy-dataset 的内嵌示例脚本我实跑了 2000 条仿真：身份证校验位按 GB 11643 权重 [7,9,10,5,8,4,2,1,6,3,7,9,10,5,8,4,2] 与映射表 10X98765432 计算，2000/2000 校验位全对——难得的硬正面证据。但同一脚本违反它自己第五步的业务约束：第 100 行要求「登录故障」类只出现在低分记录，而脚本第 82 行类目与评分完全独立随机，实测 2000 条里低分（1-2 星）组登录故障 37/186、中高分组 385 条，两组占比都约 20%，约束完全没生效；第 102 行「时间戳满足业务先后」对应的时间戳列在示例里根本不存在。照抄这份示例产出的数据集，5 条约束至少 2 条不满足。另一处口径漂移：第 36 行字段表写「用 138/139/150 等常见号段」，gen_phone() 固定生成 13 开头，实测 2000 条前三位只有 130-139，150 永远不会出现。建议把第五步约束直接写进示例脚本本身（category 按 rating 条件分支、补齐时序字段），号段从 138/139/150 等前缀里抽。

这包的计数纪律是同类里最好的：宣称 6 个技能，目录实数 6；gtm-motions 的「七种打法」第 20-68 行实数 7 个小节，与 description、打分表、判据三处口径一致；growth-loops「五种闭环」实数 5；beachhead-segment 的四个维度（刚需痛点/付费意愿/可赢份额/转介绍潜力）与第二至第五步一一对应。合规做得也实：NOTICE 逐项声明上游（github.com/phuryn/pm-skills，引用到具体 commit 与版权行，MIT 全文随包），并明确写了改编范围。本地化不是贴皮：gtm-motions 每种打法都给了真实国内工具阵地（第 30 行主动拓客配企查查/天眼查找线索、第 70 行 PLG 配神策/GrowingIO/友盟埋点），不是把海外工具换个名就完事。短板在交付深度不均：gtm-strategy 的指标节只列了五类指标名（曝光/CAC/LTV 等），没有基准参考值，也没有像 gtm-motions 那样的打分表，同一包内两个技能的可操作性差一档；各分组的 CHANGELOG.md 都写的是 69 技能全集的版本记录（分 9 组），单下载本包（6 个技能）的用户第一眼会以为拿错了包。建议：CHANGELOG 顶部加一行「本包含 6/69，属上市策略组」；gtm-strategy 给指标节补参考量级与采集方式两列，向 gtm-motions 的打分表看齐。

这是同一上游（phuryn/pm-skills）中文化的第三件套，合规与结构是同类里的样板：NOTICE 精确到上游 commit 5924541d（2026-10-09）、随包附 LICENSE-UPSTREAM-MIT 全文并逐项声明改动；实测 12 个子技能全部具备「## 输出判据」与「## 国内落地注意」两节（12/12），name 字段与目录名逐一一致；全包反向 grep Basecamp/Slack/Figma/AWS/Salesforce/Spotify/Notion 等境外产品名 0 残留，与声明兑现。 内容质量抽查对得上宣称：pricing-strategy 第 57 行微信/支付宝一般商户约 0.6%、第 58 行苹果 15%-30%/安卓商店游戏类可达 50%、第 59 行增值税 6%（部分 13%）并注明以现行政策为准，第 99/110 行自动续费提示与明码标价合规判据，市场页宣称的「国内实情」逐条落地；ansoff-matrix 第 39-41 行用美团（外卖用户推到店券/买菜）、拼多多（百亿补贴拉客单）、抖音（内容流量体系内变现）讲市场渗透，第 54 行飞书跨行业卖协同讲市场开发，案例贴切不生硬。swot 的判据具体可勾选（四象限各 5-7 条、SO/ST/WO/WT 交叉策略、行动含负责人与衡量指标），国内落地注意里「被流量喂出来的增长不算结构性优势」是行家话。 硬伤在声明与实物不符：NOTICE 第二节声明案例替换「每个技能至少替换 2 处」，用 34 个国内产品关键词（钉钉/飞书/抖音/小红书/拼多多/美团/微信/国家统计局/艾瑞/QuestMobile/百度指数/知乎/B站/阿里云/腾讯/京东/支付宝等）全包扫描，pestle-analysis、startup-canvas、swot-analysis 三个技能 0 命中——且这三个根本没有具体产品案例：swot 全文只有 72-87 行的空输出模板（代码块内全部栏目留空），连一个填好的示例都没有，判据「每条尽量具体（带数字或事实）」无从参照。另一处是 CHANGELOG 第 8 行写「69 个产品经理技能，全部重写为中文（分 9 组…）」，本包只含产品策略 12 个、README 明写 12——全集口径的 CHANGELOG 会让单包用户误判下载错包（与前两件套 20d4e55c 系列已发现的打包问题同源）。 建议：①为 swot/pestle/startup-canvas 各补一个填好的国内案例示例，或把 NOTICE 的「至少 2 处」按技能如实改写；②CHANGELOG 首行加「本包范围：9 组中的产品策略 12 个」。

三层案例库是本技能最实的资产：主盘《国际艺术家检索索引盘》标称 Pearson 名录 463 位，按节实测 Fine Art 172 / Photography 121 / Graphic Communication 62 / Textile Design 57 / Three-dimensional Design 51，合计恰好 463，逐节吻合；《青年艺术家案例底库》实测 10 位（黄颖祥到赵悦廷），与宣称一致。来源分级 A/B/C +「AI 生成内容：永远 C，永远不直接引用」（第 69 行原文）+ 反面参考强制 1 条（第 51、279 行），是同类里少见的防确认偏误硬规则。 但有三处结构性缺口。其一，SKILL.md 第 82、203、285 行三次引用 references/公版素材源清单.md，实测该文件不存在——而「公版素材源（护城河）」一节（199-214 行）与维度 1 的高清图获取全指向它，自称的护城河整节悬空。其二，references/艺术家名录检索补充盘_数据分析师.md 自称主盘的检索增强补充层（按媒介/年代/主题三路检索），SKILL.md 对它 0 次提及，案例库一节（第 249 行）只写先查主盘——按文档流程走永远读不到这个文件。其三，第 32 行写「核心流程（4步）」，实际 Step 1-5（第 135 行已加自生长入库），标题未随版本更新。 更关键的是种子卡不符合自家模板：templates/艺术家档案卡_自生长版.md 第 12-42 行要求四维 + Q1-Q4 拆解，实测世界艺术家库 10 张卡（草间、班克斯、白南准等）全部只有「维度 3/维度 4」标记，维度 1（作品展示，含出处与授权）0/10、四问拆解 0/10；而 Step 5 明写「命中则直接读对应档案文件复用，不再重新生卡」——用户一查库内艺术家，拿到的就是缺作品出处、缺四问的不完整卡，恰好违反避坑指南第 275 行「每次推荐必须输出完整四维档案卡」。另有两处小账：_index.md 年代列 3 行空、已填的是作品年份而非生卒年（草间填 1959，即《No. F》年份）；10 位国际艺术家同时存在于国际艺术家档案库.md 与世界艺术家库/两处（索引入库日期 2026-10-09 预置），两副本无同步约定。 建议：①补写公版素材源清单.md（或把 203-214 行清单落成该文件）；②给 10 张种子卡补齐维度 1/2 与四问拆解；③第 32 行「4步」改「5步」；④案例库一节补一句补充盘入口。

实测依据：脚本 gen_cpu_project.py 可跑，但 SKILL.md 第 64 行给的用法示例 --with-pipeline false 原样执行直接 exit 2——argparse 报 unrecognized arguments: false，因为第 373 行该开关是 action=store_true 不接值；正确写法 --with-pipeline 实测 exit 0，12 个文件齐全。这是文档教的第一条命令，照抄必挂。第二个问题是 I 型指令静默算错：示例指令表含 andi/ori，--instructions 会照单写进生成的 README，但 control.v（脚本内嵌，0010011 分支）把所有 I 型统一译为 aluop=00，alu_ctrl 只在 aluop=10 的 R 型分支才看 funct3——andi x1,x1,3 实际算的是 x1+3，无任何报错。正面证据也不少：imem.v 内置测试程序的三条机器码我手工核对过（beq x1,x2,0=0x00208063、jal x5,0=0x000002EF、add x3,x1,x2=0x002081B3，均与 RV32I 编码一致）；tb_cpu.v 六项检查（x1=10、x2=5、x3=15、x4=15、x5=28、mem[0]=15）与程序语义一一对应；regfile 写优先旁路、dmem 读组合/写时序分离符合单周期惯例，jal 的 J 型立即数拼接也写对了。改进建议：一、SKILL.md 第 64 行删掉 false（或脚本把该参数改成 nargs 问号形式）；二、control.v 的 I 型分支按 funct3 细分（111 到 and、110 到 or、010 到 slt），或在文档明确仅支持 addi 一类 I 型，避免照示例传 andi/ori 的用户拿到静默算错的结果。

同属单文件技巧包，只有 55 行（全文约 1.7 KB），是这批里最薄的一个，无 scripts、无 references、无 assets、无任何示例。逐节核对后的判断是：内容自身没坏，但「输出规范」这一节按字面执行不了。 正面两条。一是两段式结构与 description 声明完全对得上：第 23 行「第一段：理论的慰藉（主体，必做）」、第 31 行「第二段：上场戏服」，第 21 行还写明「严格两段式……顺序不可颠倒」。二是唯一标注了来源的概念经得起核——第 25 行「给予与流露（戈夫曼）」正是《日常生活中的自我呈现》里 given / given off 的区分，用在这里准确，由此推出的「接收者天然多看一路信号 → 接收者永恒优势」链条也成立。第 55 行「不承诺彻底不紧张——结构性紧张消不掉，能消散大半」这种克制，在同类「克服紧张」技能里并不多见。 第一处是四、输出规范实际不可执行。第 43-47 行要求产出 `text` / `quote` / `steps` / `table` / `bullets` 五个字段，但全文没有定义这套字段属于哪种输出结构（JSON schema？卡片组件？还是自由文本小标题），也没有必填/选填说明；第 46 行更写成「`steps` 或 `table`：上场戏服」，二选一却没有任何判定条件。纯提示词技能拿到这张表只能自己猜容器，交付形态在不同会话间会漂移。附一处语义错位：第 44 行把 `quote`（通常指引文）定义为「理论的慰藉，2~3 句」，即要求把自撰段落塞进引文字段。 第二处是「必做/顺序不可颠倒」与分支条款的张力。第 21 行说不倒序、第 23 行把第一段标为「主体，必做」，第 49 行却允许「用户不紧张、只想提升气场时，第一段压缩为一句定位，主体放第二段」。同一份文档里第一段既是最重的主体、又可压缩成一句。建议在第 23 行直接写明「默认必做；命中第 49 行分支时降级为一句定位」。 第三处是一处无出处的全称判断。第 27 行「新手最常见的通病恰恰是过于频繁的察言观色」，「最常见」既无来源也无限定；而本技能在别处表现得很克制。建议改成条件表述，例如「若你反复自问『我刚才是不是说错了』，那更可能是察言观色过量」。 第四处是理论来源只挂了一处。第 25 行标了（戈夫曼），而第 26 行「自我指示循环」、第 27 行「察言观色悖论」、第 28 行「重新归因」三处都是可点名的既有概念，却都没有出处——对一个把「理论」放在前半段当主体的技能来说，补上来源会明显提高可信度。 改进建议：① 给出 `text/quote/steps/table/bullets` 的最小 schema 与必填说明，并把「steps 或 table」的判据写清（例如「结构化步骤 ≤4 步用 steps，多场景对比用 table」）；② `quote` 若是自撰段落，改名 `insight` 或注明「非引用原文」；③ 第 23 行补分支降级说明；④ 第 26-28 行补三处概念来源。

单文件技巧包，88 行（约 3.4 KB），无 scripts / references / assets，只能逐节核对文档本身。第 5 行 description 声明的「四大认知坐标（时间/空间/原型/差异）+ 祛魅八技（生理/过程/归因/语言/关系/参照/时间/规则）」，与正文第 29-32 行、第 36-68 行逐项比对完全一致，没有挂空名。 正面一条：四、执行流程第 3 步明确要求「用公开常识、行业惯例、幕后运作方式佐证；没有公开证据就明说『这一点没有公开证据』，绝不编造」；五、戏谑的尺度还立了「一票否决」红线（不指名道姓羞辱、不造谣诽谤、可调侃身份/现象但不攻击具体人的身体与隐私），并两处强调「祛魅≠否定」「真实的努力要承认」（第 82 行）与「祛魅不是否定对方的努力」（第 25 行）。在一个容易滑向情绪宣泄的题材上肯先立边界，方向是对的，这也是我给 4 星而不是 3 星的原因——下面几处都是口径级、非功能级的问题。 第一处是术语复用会造成取用歧义。第 29 行第 2 条坐标「时间」指「台上一分钟台下十年功」（投入时长），第 60 行第七技「时间祛魅」指「把他的历史言论拉时间线」（历史一致性），同名不同义。按第 73 行「从八技里挑 2-3 个最戳的维度」去挑时，模型很容易把两者串成一件事。建议把坐标里的「时间」改成「积累坐标」或「投入维度」。 第二处是纪律与正文口径的张力。第 74 行既然立了「没有公开证据就明说」的规矩，第 61 行却直接给出无出处的全称判断：「把他的历史言论拉时间线：前后矛盾、判断翻车、跟着风口改口——比比皆是」；第 62 行「权威不是『每次都对』，而是『错了没人翻旧账』」也是同类断言。按自家规矩，这类句子应标注为「一般观察」或改成条件句（「若某条公开言论与其历史主张矛盾，则……」），否则与「绝不编造」自相打架。 第三处是可执行性缺口：第 61 行的「拉时间线」在实务上依赖联网检索，但包内既没有检索/工具依赖声明，也没有「拿不到公开资料时怎么办」的降级路径——而整份文档最忌讳的正是无据推断。建议在四、第 3 步补一句依赖与降级：「需要联网检索能力；无法检索时只做逻辑拆解，不引用具体言论」。 第四处是缺样例：六、交付格式只列了三个字段名（祛魅诊断 / 一句祛魅金句 / 行动锚点），没有一条完整样例，也没有「金句」的生成标准（一句？一句半？可否引语）。 改进建议：① 坐标「时间」改名避开与七技重名；② 第 61-62 行的全称断言改成条件句或注明「属一般观察、无公开证据」；③ 补联网依赖与检索不可用时的降级说明；④ 六、交付格式补一条完整示例（可用公开人物的公开言论做匿名化示范）。

本包 3 个文件：SKILL.md（386 行 / 18672 字 / 49902 字节）、环境自检.py（1728 字节）、安装与测试说明.md。我先跑了 `python 环境自检.py`，exit 0，输出「[OK] SKILL.md 存在，49902 字节 / 结论：核心就绪，可直接使用」，与 os.path.getsize 实测完全一致，这个脚本没有说假话。 正面两条。一是第 265 行「2025-09-01 之后签订的合同用 GB/T 50500-2024，之前用 GB 50500-2013」，我按住建部 2024 年第 212 号公告核了，GB/T 50500-2024 确自 2025-09-01 起实施、GB 50500-2013 同时废止，时间锚点没错。二是问题清单（第 57-74 行）12 项每项都给了「怎么判断 + 看哪些材料·取什么」两列，像第 68 行「签证单（抓建设/监理签章+日期）」这种落到具体字段的写法，比只写「审查签证手续是否齐全」有用得多。 最该修的是依据层漏了一部现行文件。我对全文做了关键词计数：「183」=0、「财建〔2022」=0、「80%」=0、「3%」=0、「过程结算」=0。第十节「依据条文」只内联了财建〔2004〕369 号、GB/T 50500-2024 与国务院令第 279 号，完全没有财建〔2022〕183 号《关于完善建设工程价款结算有关办法的通知》——该文 2022-08-01 施行并明确「自此日期起签订的工程合同应按照本通知执行」，把政府机关/事业单位/国有企业进度款支付下限提到不低于 80%、质量保证金上限压到不超过 3%，还确立了「过程结算」制度。而本技能第六节「预付款、进度款等价款支付审核」（第 227-236 行）里，比例校验只剩第 233 行一句「支付比例（是否符合合同条款及相关法规）」。第八节第 3 条自己要求「引用前先核行为发生时点的有效版本」，第十节却停在 2004 年口径，用户照抄会得出与现行规定相反的比例结论。 第二处是三套口径打架。第 275 行 Q6 答「必须落到**合规/违规/待认定**」，第 293 行 Q4 答「必须落到『合规/违规/待补资料』」，第 297 行第八节（标题在第 295 行「八、语言纪律 / 输出规范（硬约束）」）写「结论只能落在 **已定性/待定性/待认定** 三态之一」。同一文档三个不同的三态词表，其中一个还自称硬约束。 第三处是 FAQ 写了两遍：第 259-280 行 Q1~Q8，紧接第 283-292 行又是 Q1~Q4，共 12 个问答块、编号重复两轮。重复项至少三对：第一组 Q1（资料不全）≈第二组 Q3；第一组 Q6（只写合理/不合理）≈第二组 Q4；第一组 Q3（GB/T 50500-2024 版本锚定）≈第二组 Q2。 第四处是「零脚本」自述与交付物不符：第 21/26 行与说明文档第 35 行「无第三方依赖、无脚本」、第 44 行「不需要 Python」，但包内确有 环境自检.py，说明文档第 18 行让你 `python 环境自检.py`、第 55 行 `python 环境自检.py && echo "自检通过"`，第 69-70 行目录树也把它列了出来。 第五处是篇幅结构：第五节省 152 行（占全文 386 行的 39%），是从经验库整段搬来的通用施工阶段审计，其中「设备、材料管理审计」整节（第 97-131 行，含包装物回收台账、报废材料处置、盘盈盘亏）与变更签证基本无关；真正切题的只有「三、变更洽商、签证审核」39 行。 细节两处：第 253 行误用表「隐弊工程验收记录在后补」应为「隐蔽工程」（同文档其他位置都写「隐蔽」）；第 25 行「……需要你补充以下信息……」」多出一个右引号。 改进建议：① 第十节补入财建〔2022〕183 号要点（进度款≥80%、质保金≤3%、过程结算），并把第 233 行的比例校验改成带数字的硬校验；② 第八节三态词表统一成一套，回填第 275/293 行；③ 删除第 283-292 行重复 FAQ 块；④ 说明文档把「无脚本」改为「另附一个可选的环境自检脚本」；⑤ 第五节省略设备材料/进度/安全等无关小节，或标注为「延伸参考」。

2344 行 / 82KB 的纯知识型框架，无脚本，只能逐节核对文档内部一致性。 先给算术一条正面证据：第 373 行的综合风险分 = 业务30% + 财务25% + 政策合规20% + 技术迭代10% + 大股东10% + 外部5%，合计正好 100%，与第 2031-2039 行评分卡的六行权重逐项对得上，这种自己先算一遍的包不多。 但同一项风险被算了两次。其一，第 225 行「业务风险」的定性评估表里已经列了「产品/技术迭代风险」子项，第 311 行又单列「四、技术迭代风险」并给它 10% 权重，于是技术迭代同时进了 30% 和 10% 两处；其二，「股权质押>50%」既出现在第 273 行（财务风险·股权相关财务风险），又出现在第 334 行（大股东与管理层风险排查项），也是两次独立打分。两处都会让综合风险分系统性偏高。 第二处是承诺了却没给的项。第 21、26、2236 行三处都说输出「收益/风险比分」，可全文只有风险分给了加权公式（第 373 行），收益那一半没有权重、没有计算规则，评分卡（第 2031 行）里也只列了六个风险维度。名字里有，正文里没有。 第三处也最该先修：铁律被自己的输出模板违反。第 2200 行与第 2337 行两次明令「报告中任何地方都不得出现『可关注』『可离场』等投资建议用语」，可第 375 行的表头就叫「操作建议」，第 377 行写「基本面扎实，可重点关注」，第 381 行写「建议规避，存在本金永久损失可能」，第 2142 行还要求技术面结论填「[一句话总结当前技术面状态和操作建议]」。禁用词表在第六部分，违规样例就在第四部分的模板里。 第四处是外部依赖没声明也没降级。第 2180-2182 行要求调用「股票行情查询工具（如 stock-data-skill 等）」「板块热度分析工具（如 sector-hotness-analysis 等）」「联网搜索（web_search）」，但全是「如…等」的泛指名，包里既无依赖声明、无安装说明，也没有工具缺失时的手工取数清单。而第 2176 行是硬约束「不得编造数据」——工具不在，阶段二/三就只能落到第 2188 行的 blocked，整条链路空转。 正面证据：第 52 行「政策分析必须基于官方原文（gov.cn、各部委官网），严禁引用自媒体解读」，第 53 行与第 2195 行「数据缺失时标记【数据缺失，需人工补充】」，第 209-213 行把「永久性损失风险」与「短期波动风险」分开、并明确前者优先，这几条是真的投研口径，比多数同类包扎实；K 线、指标、缺口各章都配了「失效标准」和「易忽略误区」，不是只罗列形态。 改进建议：① 把「技术迭代」与「股权质押」各归一处，或写清只在综合分中计一次；② 删掉「操作建议」列改成「研究关注方向」，并按第 2200 行统一话术；③ 补依赖声明与无工具时的降级取数路径（哪怕给一张「手工需要哪几个字段」的清单）；④ 要么补出收益分的权重公式，要么把三处「收益/风险比分」改成「风险评分」；⑤ 单文件 82KB 全量入上下文成本很高，建议按政策/基本面/技术面拆成 3 个 references 由主文档按需引用。

纯提示词包，SKILL.md 共 170 行，零 scripts、零 references、零 assets（第 157 行自述），所以逐条核对文档。 先挑一处逻辑缺口：需求分级只定义了两种。第 15 行 L1 = 主体/构图比例/风格/用途 4 项齐全即出图；第 16 行 L2 = 缺少 2 项及以上关键参数。那么「恰好缺 1 项」没有归属——按 L1 不够格，按 L2 又不成立。更麻烦的是两份清单对不上：L1 数 4 项，L2 却要一次性问 7 项（多出主色调、光影类型、是否加文字）。用户给全了那 4 项但没给光影时，既算 L1（免问直接生成）又该走 L2 的追问清单，模型只能任选一处自证合规。 第二处是能力自述与参数自相矛盾。第 40 行明确写「不依赖脚本或外部服务，全部由智能体原生多模态能力完成，无需安装任何包」，但第 95 行把局部修复的重绘强度写死为 denoising=0.1~0.2，第 167 行还再次强调「denoising 固定 0.1~0.2」。原生多模态调用并没有可设的 denoising 旋钮，这条参数只在接了 diffusers / ComfyUI 这类可调重绘强度的链路上才有意义；要么承认它依赖具体绘图后端并写进依赖，要么把参数换成描述性约束（「只修补蒙版内极小范围，其余像素保持」）。 第三处是同一组能力在三处重复且措辞漂移：第 10 行任务目标、第 28-37 行扩展能力规则、第 57-69 行可选分支。举例：前者写「图像瑕疵修复」「图像水印添加」，后者写「瑕疵修复」「水印添加」；第 35 行说瑕疵修复遇到去水印按专章执行，第 108-115 行又把同样四条规则再抄一遍，以后改一处要记得改三处。 最值得改的是合规口径。第 125-132 行「AI生成标识自动清理」把「豆包AI生成」「豆包 AI 生成」「AI Generated」等都列为清理对象，第 94 行还把「禁止生成任何文字……禁止任何 AI 标识」并点名 AI生成／豆包AI生成／可灵AI 写进强制负面约束。按 2025-09-01 施行的《人工智能生成合成内容标识办法》第十条，任何组织和个人不得恶意删除、篡改、伪造、隐匿生成合成内容标识，也不得为他人实施上述行为提供工具或者服务。目前该章没有任何权利校验，而第 122 行给「水印添加」写了「仅限用户自有版权图片」——同一个包里，加水印要验权利、删标识不用，这个不对称建议补齐：加一步确认用户为内容权利人，并在话术里提示第十条，而不是无条件执行。 正面证据也有一条：第 90-100 行把水印/AI 标识修复定为「核心调度最高优先级」，禁止全图重绘、只走极小蒙版，方向是对的；第 103 行还诚实写明局部修复存在文字幻觉、无法 100% 杜绝新增标记，并建议改用专用消除工具。对一个图像类技能来说，肯写清能力边界很难得。 改进建议：① 把 L1 的 4 项与 L2 的 7 项统一成同一套参数表，并补上「缺 1 项」的处理规则；② denoising 改为非参数化描述；③ 三处能力清单合并为一张表；④ 给「AI生成标识清理」加权利校验与《标识办法》第十条提示；⑤ frontmatter 只有 name/description，建议补 version、author、display_name。

我实际装了 python-docx，构造了一份 12 段的测试公文（含 1 张正文 20cm 超宽图 + 1 张表格内 20cm 图），跑 `format_docx_image_fix.py in.docx out.docx 报告`，脚本自报「图片段落：1 个已解除固定行距并居中 / 超版心图片：2 张已等比缩至 15.6cm」。 先说做对的：正文那张 20cm×10cm 的图确实被等比缩到 15.6cm×7.8cm，且该段落 w:spacing 的 line/lineRule 被删除（实测 sp=-），图片不再被 28 磅固定行距压扁——这正是原版 official-doc-formatter 的通病，修复有效；表格里那张超宽图也被缩到了 15.6cm。第 78-82 行的检测逻辑（扫 w:drawing/wp:inline/wp:anchor）方向是对的。 问题出在分类器彼此抢跑，四处误判里有一处正好落在它的主场景上。第一，一级标题「二、现场核查情况」被当成照片说明：第 184 行的 is_photo_caption 先于第 241 行的一级标题判断执行，命中第 127 行「含现场/照片/附图…且长度<25」分支，实测该段变成居中+楷体_GB2312，而同级的「一、基本情况」正确输出黑体+左对齐+缩进 1.27cm。也就是说报告里凡标题带「现场」的（核查、执法、调研类几乎必然有）都会丢掉黑体三号标题格式。同一分支还吃掉了附件说明：「附：现场照片」被居中标楷体，而「附件：核查记录表」正确左缩进 0.74cm——两条只差「现场」两个字。 第二，成文日期「2026年9月3日」被居中成楷体，而不是右对齐仿宋：第 124 行 `^\d{4}年\d{1,2}月\d{1,2}日` 先命中照片说明，第 297-307 行的落款右对齐永远轮不到它，直接违反 SKILL.md 第 71 行自己的表格「落款/成文日期 右对齐」。第三，正文短句「本报告由办公室起草。」被右对齐：第 298-299 行的 is_signature 只要「长度<30 且含 部/司/局/委/办/公司/…」就判落款，实测真的是 RIGHT。第四，表格内图片段落实测仍是 sp=line=560 rule=exact——第 364 行的修复 pass 只遍历 doc.paragraphs，不含表格单元格，表格里的照片照样被压扁；可它又被 shrink_oversized_images 缩到了 15.6cm（该函数走 doc.element.iter，覆盖表格），于是出现「改了尺寸却没解除行距」的半修复，而脚本还只报告「图片段落：1 个」，把表格那张漏计了。 改进建议：① 把 is_photo_caption 挪到标题/附件/落款判断之后，并排除 `^[一二三四五六七八九十]+、` 与 `^附[件]?：` 开头的文本；② 日期优先按落款处理，只有紧邻图片段落的短日期才当说明；③ is_signature 增加位置条件（前一段为空或已近文末），或把「办/室」这类单字关键词收紧为完整机构后缀；④ 修复 pass 改为遍历 doc.element.iter(qn('w:p'))，让表格内图片也解除行距；⑤ 文档第 88 行要求用 soffice+PyMuPDF 做视觉校验，但「依赖」一节只写了 python-docx，建议补上这两项依赖（否则第三步验证跑不起来）。

本批唯一能拉到真数据的包，但机票域会静默返回空。 实测通过的部分：我把 npm 上真实的 @fly-ai/flyai-cli（v1.0.16，bin 名 flyai）拉下来跑，search-poi --city-name 杭州 真返回 10 条景点，说明免密钥通道与脚本里的 _FLYAI_BIN、四个子命令、以及 --dest-name / --city-name / --dep-date / --origin / --destination / --query 全部对得上。 最硬的问题：机票结果被全部丢弃并伪装成成功。真实 search-flight 的每条 item 只有 journeys / jumpUrl / tags / ticketPrice / totalDuration 五个字段，既没有 title 也没有 name；而 fliggy_search.py 第 269 行 title = info.get("title") or info.get("name")，第 270-271 行取不到就 continue，10 条被逐条丢掉，解析结果为空列表。第 429-430 行判的是 if cli_items is not None，空列表不是 None，所以最终输出 {"ok": true, "mode": "cli", "domain": "flight", "count": 0, "items": []}——一个成功的空结果，既不报错也不降级到离线指引。而机票正是文档两大能力之一，SKILL.md 第 225-232 行的样例还写着 title 是「上海虹桥 → 三亚凤凰 | 上航 FM9537」，这个标题解析器永远产不出来。修法：标题改从 journeys[0].segments[0] 的 depStationShortName、marketingTransportNo 等字段拼出，并把第 430 行判定改成非空才算成功，空列表视同解析失败回落离线指引。 第二，敏感信息拦截没做全，而且是它自己注释里点出的坑。第 57-59 行明白写着「\b 以 \w 划界，而中文字符属于 \w…因此统一使用数字边界断言 (?<!\d)(?!\d)」，但第 66 行的卡号带连字符模式仍写成 \b\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}\b。实测「帮我查卡号4111 1111 1111 1111的订单」判为 sensitive=False（漏检），同一串数字前后加空格才 True，而 SKILL.md 第 255 行承诺这是「最前置拦截」。 第三，「不因凭据缺失而完全不可用」在一种配置下不成立。_read_credentials() 在 key 与 uid 缺任一时返回 None，而第 391-398 行只要 FLIGGY_TRAVEL_BASE_URL 有值就直接 return credential_missing、exit 2，完全不回落免密钥 CLI。实测 BASE_URL 设为 https://www.fliggy.com/api/search 而 key/uid 留空 → {"ok": false, "reason": "credential_missing"}，与 SKILL.md 第 253 行「凭据未注入 → 不再硬失败，自动走 CLI 免密钥通道」直接冲突。 还有两处小硬伤：① --domain 的 argparse choices 有 6 个值含 package，SKILL.md 第 167 行只写 5 个，第 139 行的路由枚举也只列酒店/机票/POI/邮轮，于是文档里明明有「度假套餐」这一能力却没有可用路由值；_offline_guidance 的 domain_guide（第 299-305 行）同样没有 package 键，实测 --domain package 返回的 suggested_domain 就是 package，却在自家指引里查不到说明。② --no-cache 是幽灵开关：全脚本 grep cache 只 1 处命中（第 365 行的参数定义本身），没有任何缓存实现，实测传与不传输出逐字节相同，而 help 却写「禁用本地缓存（默认启用）」。 正面证据：域名白名单（第 145-167 行）先校验后请求，非 https 或非白名单域名会被 endpoint_not_allowed 挡下；脚本全程不落盘；「最多 3 条热点标识」也真落进代码（flagged[:3]）。另外，免密钥通道的价格是脱敏的（实测酒店价 ¥8x / ¥1xx），样例里的 ¥71 / ¥730 需配置正式 Key 才可能出现，样例段没有说明。

这是个纯提示词包（整包只有 SKILL.md 115 行加一个 icon.png，零 scripts、零 references），所以只能通读文档逐条核对，下面是三处文档内部打架的地方。 第一，局部示范的句数有两套。核心技能第 21 行写「局部示范：最多改 1–2 句」，而工作流模式 2 第 51 行写「可选局部示范：只改 1 句，标注『如果你愿意，可以这样试试』」。同一份文档给同一个动作两个上限，模型按哪一处执行都能自证合规。 第二，练习节奏有两套，且差得很远。核心技能第 18 行写「每日任务推送：每天推送 1 个短练习，5–20 分钟可完成」，模式 1 第 41 行还配了「到了晚上，如果用户没交，轻提醒一次」；而模式 4 的复盘模板第 73 行写「下周任务预告：周一 / 周三 __ / 周五 __」——一周三次。每日推与一周三练是两种完全不同的承诺，用户按复盘模板数周计划时会直接对不上。 第三，「复盘达标」没有判据。第 104 行写「用户连续完成 10 次且复盘达标，主动问要不要试试 300–800 字的完整场景」，但全文没有给达标任何定义——模式 4 的复盘模板只列了「写了 __ 次 __ 类型 / 优势 / 劣势 / 下阶段目标 / 推荐参考 / 下周任务预告」，既无合格线也无评分项。结果是这个升级条件不可判定，模型要么永远不升级，要么随手判过。另外 300–800 字这档也没挂等级标签，全篇只定义了 L1（50–200 字），「L1」这个序号其实是个孤儿。 还有两处实操层面的缺口。一是两处时间驱动行为（第 18 行的每日推送、第 41 行的晚上未交提醒）依赖定时器，但包里没有任何定时或 automation 配置，纯提示词不会到点自己触发，只能在用户主动开口时顺带提，与「推送」的语义不符；建议补一节说明需要外部定时任务，或把措辞降级为「用户来的时候问一句」。二是「长期记忆（必须执行）」要求维护素材银行、风格卡、练习历史三类数据，却没规定落盘路径与字段（对比同类包会写明 memory/xxx.md 与列头），换会话即丢；第 79 行要求用户问「我之前写过什么关于孤独的」时能检索出来，没有存储规格就无从检索。 正面证据也有一条：第 106-113 行的「名著参考库」6 条我逐条核过——海明威《白象似的群山》的对话潜台词、张爱玲《金锁记》的感官加心理、鲁迅《药》的看客场景、卡佛《你们为什么不跳舞》的极简对话、老舍《骆驼祥子》的祥子出场、契诃夫《变色龙》的权力游戏，作者、作品与技法点全部对得上。对一个把「不编造，不确定就承认」写成铁律的技能来说，这条自己做到了。 改进建议：① 把两处句数上限统一成一句或两句，二选一；② 节奏统一（要么每日、要么周一/三/五）；③ 给「复盘达标」写死判据，例如「一周内完成不少于 3 次且同类问题不重复出现」；④ 补一节落盘规格，定死文件路径与列头（日期/类型/原文/为什么好），并在每次开场读取。另外 frontmatter 只有 name 与 description，缺 version、author 与 display_name，平台侧看不到版本与作者。

本批唯一「宣称数字全部经得起实测」的包，但有一个会把工作流第一步打断的崩溃。 先说实测对得上的部分。跑 verify 输出「平台 8 / 行业 8 / 交叉 12 / 通用 6，条目合计 331」，与 SKILL.md 第 7 行宣称的 8/8/12/6 和 331 条逐项吻合；sources 输出「证据表共 34 条」，与第 42 行的 34 篇一致，34 条全部指向同一来源域名 yydashu.com。更少见的是自检结果是 0 错误 0 警告：12 张交叉卡都有 evidence_note 与 gaps，34 条证据没有一条未被引用。五项必填的硬约束也确实实现了——brief 只给平台时逐条列出缺的 4 项并 exit 2，-b abc / -b 0 / 目标写「涨粉」/ 阶段写「随便」全部 exit 2 并给出可选值；add 引用不存在的 src 会拒收（exit 1），level 传 matrix 也拒收（exit 2）。 最硬的问题在 gaps 命令，它会直接崩。strategy.py 第 242 行初始化的是 mtx = None，第 247 行判断的却是 if not doc:，而 doc 只在第 244 行命中时才被赋值。实测 `gaps -p B站 -i 婚庆` → UnboundLocalError: cannot access local variable doc，exit 1 并吐完整堆栈；而 SKILL.md 第 72 行的文档示例 `gaps -p 腾讯广告 -i 医美` 因为恰好有交叉卡所以能跑通。影响面：8×8 共 64 个组合只有 12 个有交叉卡，52 个（81%）会在工作流第 1 步崩掉。更可惜的是第 248-250 行本来就写好了「库中没有该组合的直接素材，以下只能用平台层与行业层推导」的兜底分支，被这个变量名不一致挡成了死代码。修法一行：第 242 行的 mtx 改成 doc。 第二，brief 的章节编号在无交叉时会跳号。实测有交叉的组合输出〇/一/二/三/四/五/六，无交叉的组合输出〇/一/三/四/五/六（中间缺「二、交叉层」），而第 83 行写的是「输出结构固定七段」，实际只有六段；两篇产物的字数差也很直观（16412 vs 10684）。 第三，时效三级降级形同虚设。age_warn() 写了 12 与 24 个月两档阈值，但 34 张卡的 as_of 全落在 2022-12 至 2023-10，实测距今 36/37/38/44 个月，34/34 全部命中最强一档，中间档与轻档永不触发。同一处还有个细节：sources.json 有 5 条证据（7047/13661/11473/10994/11141）的 date 字段是「未知」，brief 的「证据来源」表会原样印出「未知」——而第 34 行的主线恰恰是「让每一个数字都知道它是哪一年的」。 改进建议：① 第 242 行 mtx 改 doc，一行修掉 81% 组合的崩溃；② 章节号改为动态生成，缺层时补一行占位而不是跳号；③ 把 5 条无日期证据补上抓取日期，并在来源表加一列「抓取日期」（sources.json 的 _meta 里已有 captured 字段可用）；④ 库的基准期已过 3 年，建议把「超过 24 个月」这档的文案直接改成「本卡仅供参考思路，参数一律回后台核对」，避免用户把三级提醒读成「只有第三级才要小心」。

包结构：整个压缩包只有 1 个文件——SKILL.md 465 行（非空 372 行）。零脚本、零 references、零模板库。这是本批三个候选里唯一包内无任何可执行资产的。 对的地方（这部分真能直接抄用）：Phase 1 的分镜 JSON 给了 13 个字段，emotion、info_type、priority 都标了枚举；Phase 5 的卡点模板分成 beat_timeline、overlap_check、repeat_check 三块，overlap_check 带 status（pass / warning / fail）与 fix_suggestion；Phase 6 的补录清单按紧急、建议、可选三档分表，每档都给了实例（如 seg_003 团队讨论视频 横屏 1080p+ 5-10 秒 3-5 人围坐），末尾还有拍摄要求总览（画幅、最低 1080p、30fps 常规 60fps 运动、领夹麦、MP4/MOV H.264/H.265）。这套交付形态比多数同行细。 硬伤一：技能在第一步就自锁。第 20-31 行把 HyperFrames、Remotion、IP动画Skill、粗剪Skill、字幕Skill 列为依赖，其中 4 个标必需，检查流程第 1 步要求列出当前环境已安装的 Skill 清单逐一比对，缺失就照第 38-43 行话术回答「缺少以下必需技能，无法开始视频制作」。我在本机已安装技能目录按这 5 个名字逐个检索，命中数全为 0；且 HyperFrames、Remotion 本身是 JS 视频渲染框架（npm 包形态），不是本平台的 Skill 标识。用户一开口就会收到无法开始，而全文没说明去哪装、装什么（三个依赖名直接以 Skill 二字结尾，像占位符）。建议把依赖降级为可选增强，并补无依赖降级路径（FFmpeg 出粗剪、按分镜 JSON 生成 SRT）。 硬伤二：Phase 3 没有可依据的模板库。第 144 行要求从各 Skill 的模板库匹配视觉模板，3.1 表列出模板来源与匹配维度（画面布局、文字特效、背景、录屏框样式、鼠标高亮、数据图表类型、粒子效果、转场风格），但这些模板库在包内 0 个文件、依赖技能也不可得；Phase 7 验收清单第 414 行还要判无模板重复使用。没有模板清单，匹配与去重都无法落地。建议包内附一份最小模板表（template_id + 适用呈现形式 + 一句话描述）。 硬伤三：防重复阈值三处打架。第 133 行连续 2 个以上分镜不用同一呈现形式、第 155 行相邻分镜不用相同模板且同一模板全片最多 2 次、第 317 行相邻 3 个分镜内不重复同一模板——同一件事出现三套口径，后两处对相邻算几个的说法还不一致；若真按全片最多 2 次执行，8 段以上视频必然违规，而第 414 行只写或重复在可接受范围内，可接受范围全文没有定义。建议统一成一张阈值表并给出可判定的范围定义。 硬伤四：剪映草稿没有产出方。第 423 行把 jianying_draft/ 列为最终输出物，声称含完整时间线、素材引用、字幕轨道、特效参数，但 Phase 4 的 6 步编排里没有任何一步产出它：HyperFrames 只输出 final_video 与 layer_timeline，最后一步汇总输出只写了交付物名称，没指定由谁、以什么格式写。并列一条：Phase 2 判出真人口播、录屏、IP 动画、AI 解说四种呈现形式，Phase 4 编排却只覆盖 IP 动画（第 3 步）与 AI 解说（第 4 步）。 次一：quality_score 给了 1-5 取值（第 171 行）并要求优先用 quality_score 大于等于 3（第 180 行），但没有评分标准；Phase 1 要求填 duration_est，却没有字数到秒的换算基准，而 Phase 5 卡点时间线精确到毫秒，两者无法互校。建议给出语速基准（如中文口播 240-300 字/分钟）。 综合：方法论和输出模板不差，但零可执行资产加必需依赖全部不可得，开箱即用的结果是第一步就拒绝工作，故 2 星。

包结构：SKILL.md 100 行 + references/checklist.md 223 行（15 个模块）+ legal-basis.md 145 行（法1 到法16）+ report-template.md 109 行，零脚本。另注意：压缩包解出来是 privacy-policy-check/ 与 skill_privacy-policy-check/ 两套目录，4 个文件用 cmp 逐字节比对完全相同，看不出哪个是要加载的根（同批其他包都是单根）。 先说对的地方：① 15 个模块与报告模板的问题分布统计表 15 行一一对应（逐行数过），快速自查 10 项也都能追溯到具体模块，没有悬空的检查项。② 判定要求列带【法N】编号指向 legal-basis.md，而 legal-basis 对每部法规都给了「最常引用条款 + 条号含义」，例如法1 逐条列出第十三条到第六十六条的 25 个条号（含第十七条告知义务、第二十条共同处理、第二十一条委托处理、第二十八条敏感信息定义、第六十六条处罚），这是同类合规技能里少见的可核查结构。③ 风险定级的三档之外还给了 5 条补充规则，把最容易误判的三件事写清了：处理者联系方式不因缺注册地址而降级（与第十七条只要求名称和联系方式一致）、单次定位不等同行踪轨迹、SDK 按角色分四类并给出各自后果（独立处理者走单独同意、受托处理者走委托协议且缺协议属中风险）。④ 边界写得实：报告固定标注「不替代结合产品实际处理行为的现场技术核查」，模板第七节声明不构成正式法律意见，引用注意事项还明确不预测具体处罚金额。 硬伤一：未成年人模块的法条依据整条悬空。checklist.md 第 166-168 行（模块十二的 12.1 是否判断用户年龄层、12.2 是否取得监护人同意、12.3 是否设未成年人专章）引用【法17】，而 legal-basis.md 全文「法17」出现 0 次，编号只定义到法16（法16 是《网络数据安全管理条例》2025-01-01 施行）。核对编号表，法11 是《未成年人网络保护条例》、法12 是《儿童个人信息网络保护规定》——真正该引的是这两个。结果是本包最核心的未成年人三项在报告里会打出查不到的条号，用户按报告去核法条必然落空。反向也逐号核了一遍：法1~法16 全部有检查项引用，唯独被 checklist 第 166-168 行引用 3 次的法17 在依据表里查无此号。 硬伤二：共同处理者的条号与自家依据表打架。SKILL.md 第 66 行写「共同处理者（多方共同决定处理目的和方式）→ 第二十二条，不需单独同意，需约定各自责任」，checklist.md 第 112 行的 SDK 角色表也写「第二十二条（共同处理）」，而包内 legal-basis.md 第 16 行自己写着「第二十条：共同处理应约定各自权利义务，不影响个人主张权利」。个人信息保护法第二十二条规范的是因合并、分立、解散、被宣告破产等原因转移个人信息的告知与单独同意，不是共同处理。这条恰好落在该技能最实用的「SDK 角色四分类」里，而 SKILL.md 第 89 行的检查原则正是「引用法条必须准确到法律名称和具体条款，不得凭印象编造条文号」——自违。建议把 SKILL.md 第 66 行与 checklist.md 第 112 行的第二十二条一并改为第二十条。 次一：report-template.md 第 12 行是「**检查日期】：【YYYY年MM月DD日】」，缺闭合的 ** 又多了一个 】，与相邻的检查对象、产品类型、受检主体、检查模式四行格式不一致，照模板生成会缺一个加粗标记，一句话可修。 次一：模块一是 1.1、1.2 这样编号，一直到模块十四都是 N.M 编号，唯独模块十五（特殊行业与场景补充项，checklist 第 196 行）只有要点式列表、无编号；而报告模板的统计表里又有「十五、行业补充项」这一行、SKILL.md 第四步也要求问题清单按模块归类——行业补充项检出的问题拿不到可引用的编号。建议补成 15.1、15.2 之类。 综合：清单、法条映射、报告模板三件套齐全且互相咬合，可执行力强；但两处法条编号问题都出现在「报告要打印给用户看」的位置，对合规工具属实质缺陷，故 3 星。

包结构：SKILL.md 66 行 + references/input.md 59 行、advisor.md 43 行 + contract-v2.json 1178 行 + scripts/create_link.py 301 行，MIT-0。含可跑脚本，我按文档命令跑了 30 多组输入（含自造边界），并解码令牌核对内部载荷。 对的地方（数字都数过）：① `--list-templates` 返回 13 个方案，与 contract-v2.json 的 presets 逐个一致；SKILL.md 第 29-38 行的方案表 8 行加说明列里的 5 个替代方案（practice-compact / poetry-split / poetry-quadrant / name-trace / name-blank）正好凑齐 13，无漏项。② 校验一次收齐全部问题：给 name-blank 传 pinyin 返回 INVALID_PINYIN 且 allowed_values 为空数组，与 input.md 第 49 行的解释对得上；传未知字段 font 时列出当前方案支持的 10 个字段名。③ 退出码 0/1/2 三档实测复现，NO_CJK_CONTENT、UNKNOWN_TEMPLATE、NAME_TOO_LONG、INVALID_SOURCE、INCOMPATIBLE_CONTENT、LINK_TOO_LONG 全部 exit 1。④ 边界与文档一致：姓名 6 字通过、7 字 NAME_TOO_LONG；「 林小禾 」被 strip 成 3 字；标点在逐字方案报警、在 poetry-full 不报警；host「WorkBuddy Pro!」归一化成 workbuddy-pro。⑤ render_verified 恒为 false，与「脚本不验证容量、字形、笔顺」的声明一致。 硬伤一：emoji 被当成标点计数。text 为春夏😀秋冬时，warnings 返回「text 含有 1 个标点，逐字练习时每个标点会单独占一行」。根因是 create_link.py 第 139 行把 unicodedata.category 首字母属于 P 或 S 的一律归入标点，emoji 类别是 So 就被记成标点；第 140 行的非汉字字符清单又把标点排除，emoji 永远进不了那条提示。input.md 第 51 行明确把表情与英文、数字并列，模型收到的却是「1 个标点」，会误以为用户打了逗号。建议判据只保留 P，emoji 归入非汉字字符并列出实际字符。 硬伤二：页眉恒开启，班级/学号关不掉。解码令牌后姓名方案载荷是 [true, [class, name, studentId], true]，页眉恒启用且恒含 class 与 studentId。而 SKILL.md 第 66 行、input.md 第 29 行都写不要主动索要班级和学号，input.md 第 17 行说这两字段仅在用户主动提供并希望显示时使用。contract-v2.json 的 15 个输入字段里没有任何 header/footer 字段（header、footer 只在 capabilities.controls 里，属网站端能力），用户不给也照样印空学号栏。建议编码前按是否真传了 class/studentId 裁剪 header.fields。 硬伤三：方案编号与练习梯度互相覆盖。实测 standard-repeat 默认载荷是 master1 + trace3 + copy fill，而 standard-repeat 加 practice_gradient=classic 后解出的载荷与 standard-copy 逐字节相同——表格里区分的一范二描与半描半写在指定 classic 后是同一张字帖。SKILL.md 第 40 行只把「行内练习梯度」与格型、每行格数等并列列为可调项，没说它会覆盖方案固有条带。建议注明梯度一旦指定即按它重算 stages，并点明该等价关系。 次一：经验上限不透明。文档只给三档协议上限（输入 100000 字符 / 序列化 20000 UTF-16 单元 / 令牌 3000 字符），但卡人的是压缩率：1000 个不同汉字令牌 2944 通过、1500 个直接 LINK_TOO_LONG，而 4000 个重复的「春」照样通过；撞限时 errors 没有已用长度，只能盲试。建议该错误回报令牌长度与上限。 综合：引擎真能跑、文档与实现高度自洽，三处缺陷属照文档操作会拿到意外结果而非崩溃级，故 4 星。

包结构：单文件 SKILL.md，59 行 / 1797 字，零 scripts、零 references，纯知识型。 先说对的地方：① 三步拆词法与开头承诺一一对应——第 4 行说「词根词缀拆分 + 画面联想 + 造句场景」，第 12 / 17 / 19 行分别给出「拆 / 联 / 用」三步的定义与写法要点，没有跑偏。② 3 个记忆实例（procrastinate / spectator / reject，第 22-35 行）格式统一，各含拆 / 联 / 用三行，而且三种构词组合都覆盖到了：procrastinate 是前缀+词根+后缀、spectator 是词根+后缀、reject 是前缀+词根。③ 约束是可执行的：第 19 行「造一个跟你生活相关的句子」、第 57 行「一次别贪多，5～8 个一组拆」、第 59 行「记了又忘就换个更夸张的联想重拆一次」，都给了明确动作。 最硬的一处：词根清单里唯一重复的例词。第 45 行 `scribe / script`（写）的例词写成「describe、describe、manuscript」——describe 连写两遍，这一格实际只给了 2 个不同单词，而同表另外 6 行都是 3 个不同例词（bio 那一行只给了 2 个）。更矛盾的是根里含 `script`，两个例词里却没有一个带 script（script / description / subscribe 都行），读者照这一行根本学不到 script 怎么用。建议：改成「describe、manuscript、script」（或 subscribe）。 次一：承诺的「复习节奏」在正文里没有落点。第 4 行说这个技能会给你「拆解、记忆钩子、例句和复习提醒」，但全篇「复习」只命中 2 次——一次是第 4 行这句承诺本身，另一次是第 54 行输出示例里的「复习：3 天后再看，试着不看提示说出它的意思和画面」。正文没有复习节奏这一节，也没有间隔表（如 1 / 3 / 7 / 15 天）。对比更明显：3 个记忆实例全都只有「拆 / 联 / 用」三行、一行复习都没有，唯独唯一的输出示例比所有实例多一行——多出来的那一行没有规则来源。建议：把三步扩成四步（定义首次复习间隔与后续间隔表），或删掉第 4 行的这句承诺。 第三：拆解的语义与联想的写法在实例里打架。第 17 行规则写的是「用**拆分出来的意思**，编一个夸张、有画面、带语音钩子的联想」，而第 23 行把 pro- 拆成「向前」、第 24 行紧接着改用谐音「pro 谐音『扑』」；spectator 的联想也走谐音（「斯贝客」）。3 个实例里只有 reject（把心意扔回来）是照语义来的。另外第 15 行给的后缀清单是 `-tion / -able / -ist / -less`，而实例用到的 `-ator`（第 28 行）和 `-ate`（第 23 行）都不在清单里。建议：第 17 行改成「用拆分出来的意思**或**谐音」并在后缀清单补 `-ator / -ate`，让规则、清单、实例三者对齐。 第四（很小但会绊住宿主）：这包没有 YAML frontmatter，第 1 行直接是 `# 英语单词拆解记忆法`（同批另两个技能都有 `---` name / description / version 元数据块）。平台展示的那段 description（「含高频词根清单、记忆实例和复习节奏」）因此在文件里找不到出处，宿主按规范读元数据会拿到空。 维度：功能 3（三步法清晰、实例格式统一，但无 frontmatter、承诺的复习节奏缺章节）、效果 3（方法可照做，词根清单有重复例词、后缀清单与实例不匹配）、稀缺 2（词根词缀记单词属通用刚需，公开资料极多，本包仅 59 行且无脚本无参考资料，差异化低）。

包结构：SKILL.md 20010 字（556 行）+ references/ 14 篇 + samples/ 13 份 + scripts/manager_dev_audit.py。含可跑引擎，按提示实跑了一遍。 先说做对的地方：① 引擎自检 16 项全过（输出「ALL PASS（16 项检查全部通过）」），audit 出 2452 字报告、sheet 出「表头 + 6 名现任 + 4 名后备」共 11 行，自带样例不改参数即可跑通。② CSV 是真给字段的：后备行带「资格达成 5/5、是否可晋升=是、缺口=必修课程」，横向对比同批另一包（safety-management 的 CSV 把三列对策写死为空），这包的导出是可用的。③ 权重与自己写的口径对得上——SKILL.md 第 542 行写「后备覆盖率 30% + 代理试岗率 20% + 资格达成度 30% + 退出健康度 20%」，代入样例：0.667/1.5×30=13.33 + 0.75×20=15 + 0.75×30=22.5 + 0.667×20=13.33 ≈ 64.2，报告印的就是「B 级（64.2 / 100）」，自检里也钉死了 64.17。④ 资格达成度口径与代码一致（第 539 行「五项要件达成项数 ÷ 5」，代码第 115 行 `achieved_total / (5 * len(cands))`），样例 15/20 = 75% 对得上。 最硬的一处：配套文件表指向一个不存在的文件名，唯一的情境案例包内不可达。SKILL.md 第 519 行写的是 `samples/GL角色案例_王GL的一天.md`，而包里实际只有 `samples/GL角色案例_理查德的一天.md`（逐文件核对：samples/ 下 13 份，无「王GL的一天」）。SKILL.md 全文检索「理查德」命中 0 次、「王GL」命中 1 次（就是这一行）——也就是这个案例文件既没被正确引用、也没有别的入口，按第 519 行给的路径去读必然失败，而它标注的用途是「道场演练、后备培训时」。建议：把第 519 行改成实际文件名，或把文件重命名成「王GL的一天」并与台账里的姓名（张GL/李GL/赵CL/陈GL/周TL/吴CL）对齐。 次一：「退出健康度」这个会被打印进报告、也被写进 CSV 口径说明的指标，在「算法口径」一节没有定义。第 532-542 行的口径写了 5 条（后备覆盖率 / 代理试岗率 / 资格达成度 / 退出预警 / GL 监督时间占比），第 6 条只在加权式里带了它一个名字。实际看脚本第 138 行：`exit_health = 1 - (limit_n + exit_n) / len(managers)`，把「限期改善（1 人）」与「不胜任退出（1 人）」合并同权，对 6 名现任算出 67%，报告里写作「退出健康度 67%｜越低说明选拔机制越失效」。但口径第 4 条明明把两者当成两级不同结论（年度评价 < 阈值 → 限期改善；连续 2 年 < 阈值 → 不胜任退出）——仍在岗、还在 6 个月改进期内的人被算作「退出不健康」，指标名与算法对不上，客户会问「限期改善为什么算退出」。建议：口径里补出第 6 条公式，并把限期改善降权单列（如 0.5 人），或在指标名上写明「含限期改善」。 第三（小）：§3.5 的子节「监督者职务的实测构成」（第 229 行，表在第 231-240 行）给了 8 项占比（49.6% / 42.3% / 37.5% / 27% / 24.1% / 23% / 19.3% / 17.8%），合计 240.6%，而表头只写「占比」，没注明这是多选提及率还是时间构成比。按字面读会以为数字错了，也削弱了它「打破误解」的说服力。建议表头改「提及率（可多选）」。 维度：功能 4（56 页级语料、14 篇 references 与 13 份 samples 全部到位、引擎可跑且自检 16 项全过、CSV 字段齐全）、效果 3（报告与 CSV 均可用，但 1 处配套文件路径指向不存在的文件、退出健康度口径缺定义且合并计数）、稀缺 4（日-德-台三源——丰田 GL/TL 候补者制、德国 Meister 资格先行、台企储备干部+代理试岗——融合，并用「轮扁斫轮」解释意会知识为何不能靠上课交付，这个视角在同类里少见）。

包结构：SKILL.md 20250 字（669 行，13 节）+ references/ 7 篇 + samples/（2 张表单 + 12 条台账 JSON）+ scripts/safety_audit.py。含可跑引擎，按提示实跑了一遍。 先说对的地方：① 引擎真能跑且自检可靠——`--selftest` 实测输出「selftest: 23 通过 / 0 失败」，与 SKILL.md 第 182 行、第 643 行两处写的「`--selftest` 23 项」完全一致。② 三条命令都通：audit 出 1983 字报告、classify 打出 12 行归类、sheet 出 12 行 CSV，用自带样例不改参数即可跑通。③ 判定逻辑与文档同源：第 124 行「有致命可能却只靠管理对策/个人防护的，一律强制升 A」，对应脚本 score_level 第 61-65 行「致命 + 无设备对策 → 强制 A」，样例里 SR-001（countermeasures 只有「个人防护：手套」）果真被列为违反硬件优先，报告第四节列出 3 处，与引擎判出的一致。 最硬的一处：`sheet` 导出的三列对策恒为空。SKILL.md 第 178 行把这条命令标注为「可直接进 EHS/CMMS」，CSV 表头（脚本第 221-223 行 SHEET_COLS）也确实有「设备对策 / 管理对策 / 个人防护」三列，但脚本第 233 行写死了 `"", "", ""` —— 实测 12 行的这三列全部为空。而源数据里明明有：SR-007 的 countermeasures 是「设备对策：加装尾轮防护罩+清扫专用工具」、SR-001 是「个人防护：手套」。也就是说 audit 分支读得懂对策类型（正是靠它判出 3 处违规），sheet 分支却把这份信息整列丢掉，导进 EHS/CMMS 的台账拿不到「该做什么对策」这个最关键字段。建议：把脚本第 104-107 行那段按「设备对策/管理对策/个人防护」前缀归类的逻辑复用给 write_sheet，三列分别落值。 次一：分类关键词漏了自家类别名的核心词，导致 41.7% 的记录落进「其他」。R1 的 hint 是「辊、齿轮、链条、皮带、旋转、传动、冲压、剪、注塑、机械手、联轴」（脚本第 23 行），既没有「滚筒」也没有「卷入」。样例第 7 条 SR-007 的 source 是「输送带尾部滚筒」、phenomenon 是「尾部滚筒卷入点无防护」——判出来是 R7「其他（本企业特有重点）」。结果 12 条里 R7 占 5 条（SR-007/008/009/010/012），是报告第二节表格里最大的一格，「先锁 TOP、资源别摊平」这个核心用法基本失效。建议：R1 补「滚筒 / 卷入 / 输送带 / 运转」，并在 classify 输出里附「命中关键词」列便于复核。 第三：报告的章节号会跳。脚本第 207 行 `if gap:` 让「六、台账字段缺口」只在有缺项时才输出，而第 213 行「七、必须固化的三条动作」编号写死。用自带样例（字段缺项 0 处）跑出来，报告的实际章节是「一、二、三、四、五、七」，中间整节消失；而脚本第 10 行的用法说明还承诺 audit 会「出完整审核报告（含缺口清单）」。建议：编号改为动态生成，或在缺项为 0 时补一行占位（「六、台账字段缺口（无）」）。 另有两处小的：脚本第 100 行 fallback 键拼错成 `countermeaures`；「六大类」与「R1~R7」是两套口径——第 14 行（产出清单）与第 98 行（2.3 节标题「六大类重点灾害」）写「六大类」，第 182、643 行却写「归类 R1~R7」，引擎实测正好输出 7 格（R7「其他（本企业特有重点）」独占 5/12），建议统一成「R1~R7（含其他）」。 维度：功能 3（引擎真能跑、自检 23 项全过、audit 报告结构完整，但 sheet 三列恒空使 EHS/CMMS 落点失效、分类漏词使其自带样例 5/12 落「其他」）、效果 3（报告与 CSV 都能产出，但跳号与空列需人工补）、稀缺 4（丰田+中灾防+杜邦三方融合的发生源台账方法论，配内部语料与可跑引擎，制造业 EHS 场景少见）。

包结构：SKILL.md（角色/任务流程/生成规则/参考资料/输出示例）+ references/金句库.md（10 类 35 条金句 + 篇章目录 + 自动匹配流程 + 匹配示例），共 2 个文件、零脚本。 先说对的地方（数字都数过）：① 金句库不是摆设——10 个类别逐条标了「落款」篇章，35 条金句每条都能落到具体章；篇章目录（第 14-26 行）第一篇 4 章、第二篇 5 章，与说明句「第一篇 4 章、第二篇 5 章」一致，没有生造章节。② 「同一对话同一金句最多 2 次」在 SKILL.md 第 49 行与金句库第 10 行两处口径一致；「用户指定金句或章节以用户指定为准」也是两处一致。③ 落款格式统一用中文数字（示例「摘自第一篇第二章」、金句库落款列同为中文），与 SKILL.md 第 42 行模板一致；匹配示例里的王传磊案例与正文示例是同一素材，前后自洽。 最硬的一处：唯一的输出示例打破了自己最重要的字数硬规则。SKILL.md 第 52 行（金句库第 144 行同）规定正文 120–140 字、不含落款，而第 64 行示例正文实测 188 字（纯汉字 162 字，已排除标点与阿拉伯数字）——按含标点算超上限 48 字、约 34%；只数汉字也超 22 字。这段示例是全包唯一可照抄的成品，用户照着写会稳定超标；而第 27-28 行的校验分支只检查六要素是否齐全、没把字数纳入校验，所以超标根本不会被拦。对照一下：它的字数声明在包内出现 2 次（SKILL 第 52 行、金句库第 144 行）都写 120–140，唯一示例 1/1 越界。 次一：六要素里的第 4 项「独到之处」在输出结构模板里没有槽位。第 20-25 行的校验清单要求六要素齐全（时间/主体/发现问题/独到之处/解决措施/输出成果），第 54 行也明确「重点突出『如何发现』和『独到之处』」，但第 41 行的结构模板只有 [时间]、[单元][岗位][姓名]、[场景]、[发现方式]、[异常]、[金句]、[解决措施]、[成果]——没有「独到之处」位。示例只能自己补一句「他的独到之处在于：别人看外观走马观花，他却能从细微痕迹预判潜在风险。」（第 64 行末），而这句恰好就是把字数从 140 撑到 188 的直接原因。模板缺槽 → 这个必填要素要么写不进去、要么必然破字数，两个缺陷是同一个根因。 第三：SKILL.md 第 46 行列的核心行为类别与金句库实际的类别对不上。SKILL 写「根据案例核心行为（忧患预判、严格苛求、协同配合、学习创新、争创一流、降本增效等）选择最贴切的一句」，而金句库的 10 个类别名是忧患预判类/认真苛求类/主动担当类/学习积累类/岗位出彩类/用户至上类/安全质量类/降本增效类/改革创新类/绿色家园类：只有「忧患预判」「降本增效」两项能对上；「严格苛求」库里叫「认真苛求」；「协同配合」库里没有，对应的是「主动担当类」；而「学习创新」「争创一流」在库里是金句名（第 70 行「学习创新，永不满足」、第 122 行「敢为人先，争创一流」）而不是类别名。按 SKILL 列的 6 类去检索，4 类会落空或落到错误的类，而金句库第 138-141 行的自动匹配流程第 2 步又要求先把核心动作归类、再在该类中取句，等于第一步就踩空。 改进建议（具体）：① 把第 64 行示例压到 140 字以内——「他的独到之处在于…」那句与上一句合并（例如「他从细微痕迹预判潜在风险，别人看外观却走马观花」），「存在带钢边部质量风险和爆辊险肇」压成「存在边部质量与爆辊风险」；同时在第 27-28 行的校验分支加一条字数检查（数正文汉字，>140 或 <120 时提示压缩/补足），否则第 52 行的规则形同虚设。② 第 41 行模板补一个「他的独到之处：…」槽位，或在生成规则里写明「独到之处并入如何发现一句」。③ 第 46 行的类别枚举直接照抄金句库的 10 个类别名，避免模型在错误的类名上检索。

包结构：SKILL.md（四大工作模式 + 企业档案 + 分级打分 + 自进化 + 数据边界）+ references/framework.md（7 节方法论）、scoring.md（L0-L5 + 五维百分制）、diagnosis-questions.md（问题库）、case-template.md（案例模板）+ data/README.md，零脚本。 先说对的地方（数字都逐条数过）：① description 宣称「五维度18问」实测成立——diagnosis-questions.md 5 个维度、Q1-Q18 共 18 条（4+4+4+3+3），每条都带判断口径（如 Q1 区分「提效问题 vs 评价问题」、Q6「填不出标准的任务先别上AI」）。② 「工具卡四张」不是虚指：framework.md 第 53-71 行给了工具卡1 任务定义模板（11 字段，与 diagnosis-questions.md 第 34 行的 11 字段、与 SKILL.md 第 46 行「11个字段」三处一致）、工具卡2 上线前红线检查（6 项）、工具卡3 周五复盘议程（四格）、工具卡4 预期管理表（4 类任务提速区间）。③ 「七坑速查」确为 7 坑（贪大/裸奔/一键/孤岛/副驾驶/自生自灭/惯性）、「数据分三级」确为 3 级，数词与内容对得上。④ 案例模式强制「事实与判断分开、结果必须带可验证数字、无数字写待验证」，与 case-template.md 的采集清单同口径，这条纪律在同类技能里少见。 最硬的一处：scoring.md 里唯一的输出示例算错了自己定的分。第 25 行规则是「L1达标：4分；L2达标：4分；L3达标：4分；L4达标：4分；L5达标：4分」（5 档 ×4＝20 分，半达标给一半），而第 51-58 行的输出示例写「【AI化成熟度】L2」并给「六步进度：12/20（L1达标+L2半达标）」。按它自己的规则代入：L1 达标 4 分 + L2 半达标 2 分 = 6 分，示例多算了整整一倍；而这个 12 又被带进总分——12+12+10+10+14＝58，改成 6 之后总分应为 52/100。这段示例是全包唯一给出完整打分样例的地方，也是每次咨询结束都要照格式输出的一段（第 25 行「每次接触……在回复结尾给出成熟度分级＋分数」），照抄等于系统性地把分数抬高一截。 次一：「六步进度」这个维度实际只有五档。framework.md 第 27-32 行把路线定为 6 步（个人提效/流程提效/团队协同/知识沉淀/数字员工/组织基建），而 scoring.md 第 25 行只给了 L1-L5 五个 4 分档共 20 分，第六步「组织基建」没有独立分值（L5 的名字是「数字员工+组织基建」，把两步合并了）。于是「六步进度」名量 6 步、实记 5 步，跨部门统一身份/权限/模型/采购这一层（framework 第 32 行的验收线「跨部门复用，安全成本质量可治理」）永远进不了分数。 第三：SKILL.md 第 71 行「把优化建议写入 data/evolution/ 的修订提案；主 Agent 确认后更新 references/ 对应文件并在 CHANGELOG 记一笔版本号（格式见下）」——「格式见下」在 SKILL.md 里悬空，下一行（第 72 行）直接是第 5 条「回填企业档案」，全文没有任何 CHANGELOG 格式（grep「格式见下」全包仅命中 1 次，就是这一句）。真正的格式在 data/README.md 第 19 行（日期/触发源/变更内容/版本号），但 SKILL.md 对 data/README.md 的引用次数为 0——那份写着数据目录命名规范与维护规则（enterprises/ 用简称或代号、cases/index.md 的字段清单、版本号递增规则）的文件没有任何路由指向它，模型按流程走读不到。 改进建议（具体）：① scoring.md 第 54 行改为「六步进度：6/20（L1达标 4＋L2半达标 2）」，并把第 51 行总分同步改为 52/100；若作者本意是六步各占分值，则把第 25 行改成「每步 3 分 ×5 ＝15，组织基建单列 5 分」并给出算例。② 第 25 行下补一行注明第六步的分值归属，或给「组织基建」单列子项。③ 第 71 行的「（格式见下）」改成「（格式见 data/README.md）」，并在第 19 行的启动读取清单里加上 data/README.md，让命名与维护规则可达。

包结构：SKILL.md（7 节）+ references/ 12 篇 + templates/ 4 份空格式 + examples/ 4 篇完整工程（8-16KB/篇），零脚本，共 26 个文件。 先说做对的地方（我逐项对过）：① 路由没有孤儿——SKILL.md 第 75-88 行的「references 使用指引」表把 01-12 十二篇全部列了进去，正文也逐个引用（第 57/59/60/68 行分别点到 01、06、04、02、05、07、08、10），12 篇一篇不漏；templates/ 4 份与 examples/ 4 篇也都在第 90-95 行被点名。② 第 44-47 行要求 3 个方案分别落到稳妥教学/童趣互动/创意戏剧，而 references/03 的「3 种方案的推荐配方」正好给出 K2+Z1+T3+G3+J5、K5+Z4/Z6+T2+G2+J3、K1+Z3 或 Z2 三套零件串，编号与零件库表格（开场 K1-K6、主体 Z1-Z7、转场 T1-T5、高潮 G1-G5、结尾 J1-J5）一一对得上，这是全包最实的一处设计。③ 范例4《将相和》作为标注的「实跑验证样本」确实最完整：六段配套交付物齐全，知识点/史实对照表 9 行，忘词自救位（缪贤救赵王、群臣合词兜底、安全词「对！走！」）与第 99 行「台词给抓手、忘词有自救」的要求闭环。 最硬的一处：第 66 行把「排练日程建议（按周期倒排）」列为配套交付物，references/10 第 34 行也有对应检查项「排练日程按实际周期倒排，场次难度循序渐进」，但 4 篇范例里「排练日程」出现 0 次——我逐篇跑过 text.count('排练日程')，四篇全是 0；范例1 那个位置是「### 4. 排练要点」（第 164 行），讲的是站位与练词顺序，不是按周期倒排的日程。第 97 行声称四篇「均展示『3 方案 → 选定 → 完整交付包』的标准产出」，而标准产出里唯一需要跨周排期的那件交付物一个样本都没有，第 34 行那条检查项也就永远无从复核（7 次排演周期怎么切、每周交什么，包内没有任何示范）。 次一：references/10 的「二、学段专项」只给了低龄（4 项）与小学高段（3 项），缺 references/02 明确定义的另两层——「二、小学低中段（1–3 年级）」与「六、初中延伸」。而 SKILL.md 第 15 行明确说初中及以上篇目（《孔乙己》《背影》）同样适用、并让人参照 references/02 的初中延伸说明；范例1《守株待兔》标注的正是「小学低中段 · 6 人」（第 4 行，学段写二年级）。也就是说最常见的 1-3 年级和明确支持的初中，交付时都没有对应的学段专项检查项，质检清单只剩「通用项」12 条能过（我数过整份清单共 24 个勾选项：通用 12 + 低龄 4 + 小学高段 3 + 舞台执行 5）。 第三：第 37-42 行要求 3 个方案各含 6 个字段（一句话风格定位／开场-主体-结尾并列出选用零件／角色配置／亮点／排演难度／适合什么场合），但 4 篇范例的方案块普遍只剩「零件链条 + 一句评价」：全包检索「风格定位」「亮点」「排演难度」三个词命中均为 0，「适合」只在范例2/3/4 出现 1-2 次且是散句。范例4 第 26-28 行的方案一/二/三各只有 1 行，范例1 第 27 行方案二也只有 1 行。3 个方案是用户做选择的唯一依据，缺「排演难度」和「适合场合」两个字段，老师没法按自己的场合和排练能力做比较。 第四（小）：第 87 行把 references/11 标为「写剧本和排演建议时必读」，但第三步的执行清单（第 57-68 行）逐条列了 01、04、02、05、06、07、08、10，唯独没有 11，11 只出现在第 99 行的「特别提醒」里。严格按执行清单走会漏掉它。 改进建议（具体）：① 给 4 篇范例的「配套交付物要点」补第 6 项「排练日程（按周期倒排）」——最省事的是把 templates/排练日程模板.md 填一份进去（范例1 可写 4 周 × 每周 2 次的倒排表）；若确实不打算示范，第 66 行的交付承诺与 references/10 第 34 行的检查项应删掉其一。② references/10 的「二、学段专项」补两节：「小学低中段」可沿用低龄项但去掉「歌舞换场」、加「旁白串联是否清楚」；「初中延伸」加「主题克制、无渲染苦难/暴力」「独白须带动作目标」两条。③ 把第 37-42 行的六个字段做成范例里的固定小表头（方案｜零件串｜角色数｜亮点｜难度｜场合），四篇各填一遍，哪怕每方案只 6 行也比现在的 1 行可比较。

包结构：单文件 SKILL.md 52 行（7 节 + 1 张 5 行动力画像表 + 1 个测算示例），3689 字节，零脚本、零 references。 先说做对的地方：它是真给算式的技能，不是只给形容词——五维算账法把购车成本、5 年能耗、5 年保养、保险税费、残值五项各自的构成都写出来了。我把第 45-47 行那份示例逐项重算过：纯油 13.5+4.0+0.8+2.0−6.0 = 14.3，插混 14+1.8+0.5+2.2−5 = 13.5，差价 0.8——三处全部与文档印出的数字一致，一个都没算错，这在算账类技能里不算常见。 最硬的一处：保养成本的公式漏了乘 5，而它自己的标题写着 5 年。第 22 行「**3. 保养成本（5 年）** = 年均保养次数 × 单价」，按字面代入只有一年的量；对照同节另外两条，第 17 行能耗公式结尾带「× 5」、第 25 行保险写「按年估算 × 5」，全文「× 5」只出现 2 次（就是这两处），第 22 行是唯一一个「标题写 5 年、公式不带 5」的。用户照第 22 行手算五年总账，会少算 4 年保养。 次一：能耗公式与它下面的明细项对不上。第 17 行「能耗成本（5 年）= 每年行驶里程 ÷ 每百公里 × 单价 × 5」，而第 18-19 行明细是「油车按百公里油耗 × 油价」「电车按百公里电耗 × 电价」——通用式里没有油耗/电耗这个因子，且「单价」对油车是元/升、对电车是元/度，都不是元/百公里。照第 17 行字面代入油车，得到的是「里程÷100×油价×5」，漏掉 6～9 升/百公里的换算，结果会差近一个数量级。 第三：购车成本里的首年保险被重复计了一次。第 14 行「购车成本 = 裸车价 + 购置税 + 上牌费 + 首年保险」，第 25 行「保险与税费……按年估算 × 5」——首年保险先在购车成本里算一遍、又在 5 年保险里算一遍。示例里「购车 13.5 万」与「保险 2.0 万」直接相加，没说明 2.0 万是 5 年全额还是后 4 年，两种读法差几千块。 第四：决策速判与它自己的示例给出相反建议。第 39 行速判第 1 条「能装家充桩吗？……不能 → 优先油混或纯油」，而第 44 行示例场景明明白白标着「无家充」，第 47 行结论却是「你的工况下插混 B 更省」——照速判走会选油混/纯油，照示例走会选插混，两条路结论相反，而示例恰恰是用户最容易照抄的那段。 第五：速判第 3 条问的「开几年」在这套方法里没有落点。第 41 行让用户回答「开 3 年就换」还是「开 8 年以上」，还给了权重切换规则（保值率权重>能耗 / 能耗和保养权重>残值）；但五维法有五项，其中三项标题就写死 5 年（第 17/22/25 行），第 27 行残值取的也是「5 年保值率」，全包没有 3 年或 8 年的换算口径。用户答完这一问，测算仍只能出 5 年那一套。 另外：第 4 行宣称「把纯油、纯电、插混、油混、增程五类车放在同一张桌上」，第 44-47 行示例只比了纯油 A 车与插混 B 车——纯电、油混、增程三类在示例里 0 参与，读者看不到五类同屏长什么样。 改进建议（具体）：① 第 22 行补成「= 年均保养次数 × 单价 × 5」；② 第 17 行公式补油耗/电耗因子，并把「单价」明确为「油价（元/升）」「电价（元/度）」；③ 第 14 行把「首年保险」移出购车成本，或把第 25 行改成「后 4 年保险 × 4」并在示例注明口径；④ 第 39 行速判 1 与示例二者对齐（无家充场景改推油混，或把示例场景改成有家充的插混优势场景）；⑤ 给速判 3 补 3 年/8 年折算口径，或明确声明本测算固定 5 年、其他年限按同法替换乘数；⑥ 示例补齐五类对比，哪怕每类只给一行购置+能耗+残值。 维度：功能 3（五维框架完整、示例算术三处全对，但两处公式——保养漏 ×5、能耗缺油耗因子——按字面代入会算错）、效果 3（速判与示例结论相悖、速判 3 无对应口径、示例只覆盖五类中的两类）、稀缺 3（五类动力横向算持有成本在生活实用区有一定区分度，但同类买车算账提示词已有若干）。

包结构：SKILL.md 195 行 / 11772 字节，assets/模版集.txt 881 行 / 46155 字节，assets/合规红线.txt 167 行 / 9438 字节，零脚本。 做对的地方（数字都是我逐条数过的）：① 模版集 第 25-103 行【底座-01】～【底座-20】正好 20 条；M01～M28 连续无缺（缺号 0）；第 800 行起的【交付自检】逐条数就是 62 条，与 SKILL.md 第 109/167/195 行、模版集 第 4 行写的 62 一致。② 合规红线 第二节【红线 1】～【红线 4】正好 4 条（第 33/41/49/55 行）、第五节季度清单 13 项（第 105-117 行）、第七节常见误区 7 条（第 143-149 行）。③ 拒答表（SKILL.md 第 123-126 行）把「预测收益」「帮算税/选主体」「市场调研」三类越界需求逐条挡回；第 70 行「付费节点不低于三成」与 模版集 第 66、835 行「预付款比例不低于 30%」口径一致。 最硬的一处：唯一的报价算例算错一倍。模版集 第 51-52 行给「交付成本 2400 元、风险缓冲 600 元、目标毛利 55%」→「底线 = (2400 + 600) ÷ (1 - 0.55) = 6000 ÷ 0.45 ≈ 13333 元」。按它自己第 50 行的公式代入：2400+600=3000，3000÷0.45≈6667 元——分子凭空从 3000 变 6000，结论整整高一倍；而 SKILL.md 第 90 行的公式本身没错。这又是全包唯一带数字的示例、正是定价环节让人照抄的那段，照抄者会把不接单价抬高一倍（要么吓跑客户，要么误以为还有一半降价空间可以让人压）。建议把第 52 行改成「= 3000 ÷ 0.45 ≈ 6667 元」。 次一：平台展示面与实测不符。SKILL.md 第 5-6 行 frontmatter 写「28 套模版 + 20 条底座 + 75 条自检」，而第 109/167/195 行与 模版集 第 4/800 行一律写 62 条，逐条数出来就是 62（定位 11 + 产品化 12 + 报价 12 + 交付 12 + 引流 15）。用户在市场看到 75、下载后数到 62。 第三：「数词自证」四处不一致。① 合规红线 第 11 行标题「一、五种主体的差别」，第 16-18 行只有 3 行（个体工商户 / 个人独资企业 / 一人有限公司），而 SKILL.md 第 110/169 行也跟着宣称「五种」。② 同文件第 61 行「三、两个容易被忽略的细节」，实为 4 个【】小标题（注册资本 64 行 / 经营范围 68 行 / 场地信息 71 行 / 账务留存 74 行）。③ 同文件第 125 行「以下六种情况」实列 7 条（第 127-133 行），而 SKILL.md 第 111/171 行写的是「七种」——SKILL.md 对、底表正文错。④ 禁用词清单写「七个」实列 8 个（赋能 / 闭环 / 抓手 / 赛道 / 生态 / 维度 / 聚合 / 解决方案），共 5 处：SKILL.md 第 72、155 行与 模版集 第 29/126/806 行；第 155 行本身就是自检项「全文没有出现那七个禁用词」。 第四：合规自检的归属两处冲突。模版集 第 875-876 行说「财税合规的自检在 assets/合规红线.txt 的『五、合规自查清单（每季度过一遍）』，13 项按季度过，不属于单次交付」，而 合规红线 第 152 行就挂着一份「本包自检（每次交付前逐条核对）」的 13 条清单（第 155-167 行）——同一张底表里两套 13 项。另有小瑕疵：合规红线 第 53 行以逗号开头（「，很多单人企业异常都是长期没申报造成的。」），以及资产路径不统一（SKILL.md 第 43/44 行裸写 合规红线.txt，第 99/110/166/169 行写 assets/ 前缀）。 改进建议（具体）：① 第 52 行算例改为「= 3000 ÷ 0.45 ≈ 6667 元」；② frontmatter「75 条」改「62 条」；③ 四处数词对齐实列（三种主体 / 四个细节 / 以下七种情况 / 八个禁用词）；④ 第 875-876 行改成「五节 13 项按季度过，另有 13 条每次交付前自检」；⑤ 统一 assets/ 前缀，删掉第 53 行行首逗号。 维度：功能 4（28 套模版 + 20 条底座 + 62 条自检 + 合规底表构成完整体系，数量实测全部核实）、效果 3（定价算例算错一倍、宣传数与实测不符、四处数词错位）、稀缺 4（把一人公司从定位做到财税红线的操作库，同类里内容密度明显更高）。

包结构：单文件 SKILL.md 57 行（7 节 + 1 张 6 行速记表 + 1 个输出示例），3558 字节，零脚本、零 references。 先说做对的地方：第二步把三档框架的时长写死了——快手型 15～30 分钟、标准型 40～60 分钟、讲究型 60 分钟以上（第 17-19 行），读者能直接按可用时间选档；第 48 行示例标题「（2 人，快手型，约 20 分钟）」落在自家区间内；第 3 条硬规则「颜色要齐（红/绿/黄）」在示例里红（番茄）、绿（油麦菜）、黄（蛋）三色齐备，这条是达标的。 最硬的一处：盲盒的承诺和它自己的池子对不上。第 4 行写「直接说『盲盒』，它随机抽一套 30 分钟内能上桌的搭配」，第 43 行写盲盒「会从『快手型』和『标准型』池里随机抽一套 2～3 菜 1 主食的组合」——而第 18 行给标准型的时长就是 40～60 分钟。从一个含 40～60 分钟档的池子里抽，逻辑上给不出「30 分钟内上桌」的保证，这两句必有一句要改（要么把标准型移出盲盒池，要么把 30 分钟改成 15～60 分钟）。 次一：唯一那份输出示例，违反了自家第 2 条硬规则。第 23 行要求「做法错开：炒、炖、蒸、凉拌尽量不重样（比如红烧+清炒+凉拌）」，而示例第 49-50 行的两道菜——番茄炒蛋（热油炒蛋、回锅炒）与蒜蓉油麦菜（大火炒 1 分钟）——都是「炒」，一桌两个炒。示例是读者最容易照抄的样板，它自己先违了规。另外第 23 行举的例子「红烧+清炒+凉拌」是三道菜的形态，而它挂在快手型（一荤一素+汤，两菜一汤）的语境下，举例用的其实是讲究型的组合。 第三：第 22 行「荤素比 1:2：一盘肉至少要配两样蔬菜」与第 17 行快手型的「一荤一素」计数口径打架——一荤一素只给了 1 个素菜位，要满足 1:2 就得像示例那样靠一个荤素同体的番茄炒蛋去凑，但示例只列菜名、没标荤素位，读者无法自查是否达标；「炒蛋算荤还是算素、番茄算不算那个 1」全包没有一句话说明。 第四：食材分类与速记表打架。第 14 行把食材分三类——主食（米/面/粉）、蛋白（肉蛋豆制品）、蔬菜，豆制品按此归「蛋白」，而第 34 行的速记表把豆腐写成「素菜担当」（已算成蔬菜位）；土豆这类主食兼蔬菜的食材则只出现在第 33 行与第 38 行菜品清单里，第 14 行的三类枚举中根本没有它的位置。同一食材在两处归属不一致，而荤素比恰恰要靠这套分类来数。 第五：触发示例承诺了「宝宝也能吃的」（第 8 行），但「宝宝」全包仅出现 1 次、就是这一行本身，没有任何婴幼儿适配规则（如 1 岁内不加盐、辅食形态需软烂），而示例的番茄炒蛋恰恰是「加盐糖调味」；「过敏」全包 0 次命中，「忌口」2 次（第 4、56 行）只承诺「换成清淡做法」，没有过敏原出局这类硬过滤。 改进建议（具体）：① 二选一消除盲盒冲突——把第 43 行抽池改成只有快手型，或把第 4 行「30 分钟」改成「按档位 15～60 分钟」；② 把示例第 50 行蒜蓉油麦菜换成一道非炒做法（白灼/凉拌），让唯一示例本身满足第 2 条硬规则，并给每道菜补一行荤/素标记；③ 给「荤素比 1:2」补计数口径（荤素同体菜怎么折算），或在速记表加一列「荤素归类」；④ 统一土豆、豆腐在第 14 行分类与第 26-34 行表里的归属；⑤ 若保留「宝宝也能吃的」入口，补 3-5 条婴幼儿硬约束（不加盐/不加糖/软烂形态/常见致敏食材出局），否则从第 8 行删掉。 维度：功能 3（7 节完整、三档时长写死可用，但盲盒承诺与自身池子互斥、唯一示例违反自家硬规则）、效果 3（三步法可直接照做，但荤素比无口径、营养均衡无量化、无过敏过滤）、稀缺 2（家常菜单类提示词在该区已较常见，无差异化产物）。

包结构：单文件 SKILL.md 55 行（7 节：何时使用/输入/执行流程/输出格式/案例/边界/运行说明），3418 字节，零脚本、零 references。 最硬的一处：frontmatter 没有闭合。第 1 行是 ---，第 2-4 行是 name/description/version，但第 5 行收尾写成了三个反引号 ``` 而不是 ---。我实测按最常见的 text.split('---') 取第二段当 frontmatter：全文件 1326 字符，取到的「frontmatter」是 1323 字符——等于整篇正文（含第 7 行标题「# 可玩世界提示器」）全被吞进元数据块，name/description/version 与正文混成一段；严格按闭合符解析的宿主会直接报 YAML 错或读到一串脏元数据。这是改 1 个字符就能修、却会让技能在严格宿主上加载异常的硬伤（本次下载查看用的宿主只是按纯文本读，故未暴露）。 次一：description 点名「给 PixVerse R2、Genie 这类实时世界模型做交互/动作提示词工程」（第 3 行），但 PixVerse 与 Genie 在正文各只出现 1 次、且都在 description 里；第 7 行之后正文全篇只讲「实时世界模型」这个泛称，没有任何平台差异适配（不同世界模型的时长上限、动作词表、状态记忆能力差别很大），第 51 行边界也只留一句「以平台实际支持为准」。招牌写在 description、落不到正文。 第三：第 17 行承诺「信息不足时先给一个可直接用的通用模板」，但「通用模板」全包仅 1 次命中（就在这一行），包内没有任何一份可直接粘贴的通用模板正文。第 25 行要求「输出一段结构化、可直接粘贴的提示词，并给 2 个可替换变量（风格/场景）」，第 34-36 行的【可直接粘贴的提示词】【可调变量】两块也只在模板里存在，3 个案例（第 40/43/46 行）没有一条示范成品提示词——这个技能最核心的交付物（一段能直接粘贴的提示词）在包内 0 次示范。 第四：案例对 7 块输出的覆盖很不齐。按「字段=」数：案例 1 给了基底/初始/动作/状态/视角 5 项（第 41 行）；案例 2 只有动作与状态 2 项（第 44 行），连【世界基底】（题材/风格/氛围/物理规则/边界）都缺，只剩「傍晚的海边小镇」一个时间地点；案例 3 是动作/状态/目标 3 项（第 47 行）。案例 1 那句「各有反馈」（第 41 行）也只有四个字，没有一个「动作→反馈」的对照示范，而第 22 行第 3 步「每个动作世界应如何反馈」正是它的重点。 改进建议（具体）：① 第 5 行 ``` 改回 ---；同时建议给本系列三个包统一补 author/title——三包都只有 name/description/version，且 name 是中文（「AI世界操作提示」）而 H1 标题是另一个名字（「可玩世界提示器」），两者不一致；② 补一节平台适配表，至少把 PixVerse R2 与 Genie 在动作词表、时长限制、状态记忆上的差异各写 2-3 条；③ 把第 17 行承诺的通用模板写进包内（8-12 行可粘贴示例），并给案例 1 补上完整成品提示词；④ 案例 2 补【世界基底】与【镜头与目标】，案例 1 把「各有反馈」展开成「推门→门轴声与灰尘扬起」这类逐条对照。 维度：功能 2（frontmatter 未闭合，严格宿主解析异常；核心交付物 0 示范）、效果 3（6 步拆解框架（世界基底/初始场景/动作反馈/状态记忆/镜头目标/组装）本身清晰可用，但缺平台层与成品样例）、稀缺 4（面向实时世界模型的交互提示工程在该区很少见，题材新颖）。

包结构：单文件 SKILL.md 54 行（7 节：何时使用/输入/执行流程/输出格式/案例/边界/运行说明），3494 字节，零脚本、零 references。 先说做对的地方：第 20-24 行的 5 步审计（界定权限→核算代价→数据授权→平台红线→责任兜底）把「自动化上线前该问的事」摆得比较全；第 49 行边界明确不提供「如何规避法律/绕过平台风控」的方法、第 50 行不协助违法自动化——风险类技能最容易滑向「教你绕过风控」，这条堵住了，方向正确。案例 3（第 45-46 行）给的是可执行旋钮：金额上限、支付前强制人工确认、关闭免密大额，而不是「注意风险」。 最硬的一处：输出模板比执行流程少两个槽位。第 21 行第 2 步要求列「直接成本（算力/订阅）、机会成本、不可逆风险」三类，第 29-30 行【代价清单】只给了「直接成本：… ｜不可逆风险：…」两栏，机会成本无处落笔——「机会成本」全包仅 1 次命中，就在第 21 行这句承诺里，模板与 3 个案例都再没出现。第 24 行第 5 步写「明确『出问题谁承担』，并给降风险设置」，模板只落了后半句（第 33 行【必须人工把关的环节】、第 34 行【建议的安全设置】），前半句的责任归属没有对应字段——「谁承担」全包 2 次命中，一次在 description（第 3 行）、一次就在第 24 行的承诺里。全包被承诺的两个审计结论，恰好在成品里都写不出来。 次一：description 把「熵」列为三大审计对象之首（第 3 行「审计一个自动化动作会产生的熵、代价由谁承担、会不会触发平台规则」），但除这一行外全包再 0 次命中——没有定义、没有可观测指标（是流程步骤数？外部副作用数？不可逆操作数？），也没进输出模板。三个招牌概念里有一个是空头。 第三：第 30 行「（标红高危动作）」既没定义什么算高危，也没说纯文本输出里怎么「标红」。第 23 行第 4 步要求「对照…消费者保护与相关法规要求」却不给任何具体法条或平台规则名（「法规」全包 1 次、「平台规则」1 次，都在第 23 行这一句泛述里，另有一次在 description），审计结论只能停在「注意合规」；而第 51 行边界又把「具体法律适用因地区和场景而异」推给用户，唯一可验证的部分被清空。 第四：3 个案例（第 39/42/45 行）清一色「风险：… 建议：…」两栏摘要，无一展示第 28-34 行的 6 块输出，读者看不到「是否最小必要」「高风险点」「安全设置」填好长什么样。 改进建议（具体）：① 【代价清单】补「机会成本」一行、【责任与兜底】补「责任归属/谁承担」字段，让 5 步全部有输出位；② 给「熵」一个可数指标（如本次动作涉及的外部写操作数 / 不可逆操作数 / 第三方数据流向数）并写进模板，否则从 description 删掉；③ 把「高危」改成可判定判据（如「不可逆 且 涉及资金或对外发声」），「标红」改为文本标记（如【高危】前缀）；④ 至少补 1 个填满 6 块输出的完整案例，并把常见自动化场景的平台规则名与消费者保护常见条款列成可选清单。 维度：功能 3（7 节完整，但输出模板漏掉 2 个已承诺字段）、效果 3（审计框架方向正确、边界克制，但核心结论「谁承担/熵」无槽位、合规部分零具体依据）、稀缺 4（面向 Agent 自动化的代价+合规审计视角在该区少见）。

包结构：单文件 SKILL.md 57 行（7 节：何时使用/输入/执行流程/输出格式/案例/边界/运行说明），3493 字节，零脚本、零 references。 先说做对的地方：执行流程 5 步与输出格式 6 块基本一一对应——第 22 行拆因果→第 30-31 行【对方成功的因果条件】，第 23 行标环境→第 32 行【环境对比】，第 25 行算缺口→第 35 行【关键缺口与可补性】，第 26 行第三路径与最小验证动作→第 36-37 行两块，没有承诺了却不给输出位的地方。第 22 行特意区分「可复制因素/不可复制因素」并由第 31 行「可复制：… ｜不可复制：…（时机/资源/运气）」接住，这个拆分是整包的方法论内核，比泛泛的「借鉴成功经验」有用。边界第 53 行拒绝「稳赚」类诱导、第 26 行明确「不 all in」，是同类决策技能里少见的自我约束。 最硬的一处：整包唯一的差异化产物【条件对照表】从未被示范。全文「条件对照表」只出现 1 次（第 33 行，就在输出模板里），3 个案例（第 42/45/48 行）全是 2-3 行第三人称口吻的压缩总结，没有一条把第 34 行那张「条件 ｜ 对方 ｜ 你 ｜ 判断」四列表填出来。案例 2 只写「拆出位置流量、选品、起早时间、启动资金等条件；逐条比对」，读者看不到该表实际几行、判断列怎么落字。而第 22 行列出的 6 类条件（时机/红利、独特资源、已有积累、渠道、投入成本、运气成分）在模板里也没有对应行骨架，只有第 31 行一个括注「（时机/资源/运气）」，6 类怎么映射到表格行是空白。 次一：三态标签两处不一致。第 24 行写「标【具备 / 部分具备 / 不具备】」，第 34 行模板写「判断(具备/部分/不具备)」——同一套三态，中间那档一个叫「部分具备」一个叫「部分」。模型照模板输出时有概率写出第三种写法，后续若想批量统计某机会的「部分具备」占比，字符串就对不上。 第三：最小验证动作只有 1/3 案例给了量。第 26 行把「最小验证动作（小成本先测，不 all in）」写成硬性第 5 步，但案例 1 给了「先做 5 条测数据」（第 43 行，有数字），案例 2 只写「先小规模测一版」、案例 3 只写「先在现有岗位嫁接相关能力」（第 46/49 行），都只有方向没有量级与时间盒。 第四：第 25 行「能否在可接受成本内补齐」里的「可接受成本」全包无定义——相对用户自己的什么基准（月收入？可支配现金？可投入周末数？）无从判断，「是否致命」也没有分级，读者没法用它给两个机会排优先级。 改进建议（具体）：① 案例 2 补一张填满的【条件对照表】（建议 5 行条件 × 4 列），并把第 22 行的 6 类条件定为表格固定行骨架；② 三态标签统一为「部分具备」（第 34 行同步改）；③ 给「可接受成本」一个可代入锚点（如「≤1 个月可支配收入 / ≤2 个周末」），并把「是否致命」分 2-3 档；④ 案例 2、3 的最小验证动作补数量与时间盒，与案例 1 的「5 条」对齐。 维度：功能 4（7 节完整、5 步与 6 块输出一一对应）、效果 4（因果拆解框架可操作，但核心产物与阈值均未示范/定义）、稀缺 3（「见路不走」式因果决策比泛创业鸡汤有区分度，但决策类提示词同质化仍高）。

包结构：单文件 SKILL.md 210 行（7 节 + 3 个内联示例），无 references、无脚本。 先记做对的地方：① 输出骨架在步骤 3/4/5 与第 5 节输出结构两处逐字一致（第 94 行与第 44-56 行都是【热点风向】【文案正文】【9宫格视觉脚本】【话题标签】【风格备注】五块同序同名）；② 9 宫格在 3 个示例里都恰好 9 个编号（示例 1 素颜暗沉对比首图…闺蜜合照植入、示例 2 桌面全景…数码周边生活图、示例 3 冲泡过程…轻食生活图），不多不少；③ 第 89 行那条「（注：热点需用户确认真实性后再定稿）」在模板加 3 个示例共出现 4 次（第 89、136、167、197 行），一次不缺；④ 标签 3 个、热点角度 2 个，都落在自定的「2-4 个」与「2-3 个」区间内。 最硬的一处：标签相关性规则的方向写反了。第 110 行铁律 3 是「话题标签须弱相关、数量克制（2-4 个），禁止堆砌无关大词刷流量」，第 98 行输出模板也写「（2-4 个，弱相关）」——「弱相关」与后半句「禁止堆砌无关大词」语义互斥，弱相关本身就是无关。全文「弱相关」出现 3 次（第 49、98、110 行）、「强相关」0 次；而同作者的另两个包这一条都写「须与产品类目强相关」。另外第 19 行平台基线用的是「话题标签 # 弱使用（2-4 个即可）」——「弱使用」讲使用频率、「弱相关」讲相关度，两个概念在同一个包里被混成了同一个词。 次一：9 宫格的单元格语义在 3 个示例里全都没照模板走。第 95 行模板给的定义是「①首图钩子 ②痛点 ③使用场景 ④前后对比 ⑤证据/成分 ⑥-⑨生活感填充」，实测示例 1 把「一周透亮对比」放在 ⑤，而 ④ 是「清爽质地拉丝」；示例 2 的 ② 是「键盘特写」而非痛点；示例 3 的 ⑤ 是「办公桌一角」，真正属于 ⑤ 的「营养成分标注」跑到 ⑥、属于 ④ 的「免煮对比」跑到 ⑧。3/3 示例都没能让单元格位置与模板语义对上，而 9 宫格正是它宣称的差异化能力③。 第三：软 CTA 点了「扫码」却从没示范。第 17、47、109 行共 3 处把 CTA 写成「私信 / 扫码 / 评论」，而 3 个示例的 CTA 全是「私我 + 链接」（示例 1「想要的私我，给你发链接～」），「扫码」在示例里出现 0 次。 另外：第 63 行存储说明写「写入技能可读的 style-profile.md」，没有 references/ 前缀，而本包不含 references 目录；同作者小红书包写的是 references/style-profile.md，抖音包则直接附了这个文件——同一产物在三个包里三种写法。 改进建议（具体）：① 把第 49、98、110 行的「弱相关」改成「强相关」，或把两个概念拆开写（数量 2-4 个、相关度强、使用频率低）；② 9 宫格模板只约束「①首图钩子 ⑤证据/成分 ⑥-⑨生活感」四个锚点、中间三格放开，或把 3 个示例按模板语义重排；③ 补一条扫码 CTA 的示例，或把「扫码」从 CTA 清单里删掉；④ 统一 style-profile.md 的路径写法。 维度：功能 4（五块输出骨架完整，模板与步骤互相对得上）、效果 3（标签相关度规则方向写反，差异化能力 9 宫格的单元格语义不可复现）、稀缺 3（朋友圈私域软文案加 9 宫格脚本的组合有一定区分度，但团队批量场景没有落点）。