专利速写

【实测·英语单词拆解记忆法】包内只有 SKILL.md，纯提示词技能。我的实测方式是按它的三步拆词法真拆了几个词，并逐条核对了词根表。 做得好的地方： 1) 三步顺序（拆 → 联 → 用）符合记忆规律，而且每步都给了可操作的抓手：拆要给"词根 + 前缀 + 后缀"，联要"夸张、有画面、带语音钩子"，用要"造一个跟你生活相关的句子"。不是"多读多背"式的空话。 2) "孤立地背定义会忘，放进自己的句子才会留下"这句把方法的核心说透了，而且输出模板里真的落到了句子（I always procrastinate on Mondays.）。 3) 词源拆解有真东西：procrastinate 拆到 pro- + crastin（源自拉丁 cras = 明天）+ -ate，这个溯源是对的，比只讲谐音的拆词法扎实一档。 4) 输出格式固定（📖 记单词：xxx → 拆 / 联 / 用 / 复习），Agent 能稳定产出同一格式；末尾"3 天后再看，试着不看提示说出它的意思和画面"带了复习钩子。 5) 使用小贴士里的"一次别贪多，5～8 个一组"和"把一组单词串进一个故事"是符合记忆研究的做法。 实测发现的问题： 1) 【词根表有一处硬伤：同一个词写了两遍】第 45 行是 | scribe / script | 写 | describe、describe、manuscript |——describe 重复出现两次。而且 describe 是 de- + scribe，作为 scribe 词根的代表词略勉强，真正典型的是 transcript / subscribe / manuscript。建议把这行改成 | scribe / script | 写 | describe、transcript、subscribe、manuscript |，并把整张词根表重新核一遍（这张表是技能的可信度地基，错一处会连带影响其他行）。 2) 【缺 frontmatter，平台很可能解析不出触发词】文件直接从 # 英语单词拆解记忆法 开始，没有 --- name/description --- 这段。我这次解包的 12 个技能里另外 11 个都带 frontmatter。没有 frontmatter 就没有 description 里的触发场景描述，用户在 Agent 里说"帮我记一下这个词""有没有背单词不费劲的方法"时很可能不会被唤起。建议补上 name + description（description 里写清触发场景：背单词、记不住某个词、想找词根词缀、想要一组同类词对比记）。 3) 【三类高频诉求没覆盖】① 一词多义（如 spring 既有春天又有弹簧，拆词法对多义词会失效，需要单独说明怎么处理）；② 不规则变形（go-went-gone、child-children 这类靠拆词根本推不出来，得走另一套路径）；③ 近义词辨析（"一组表示『说』的单词对比记"在触发场景里提了，但方法里没给对比记的做法）。建议各补一小节，明确"这三类不适合三步拆词法，改用 X 方法"，比硬套拆词更诚实。 4) 【复习机制只有一句话】"3 天后再看"是提示不是机制，没有间隔重复的排期建议（如 1 天/3 天/7 天/15 天）。既然主打"不再背了忘"，建议给一个简单的间隔复习排期，或让 Agent 输出时附上下次复习日期。 总结：三步拆词法本身是站得住的，"拆+联+用"配上固定输出模板，作为记单词助手拿来就能用，词源拆解也比我预期的准确。把词根表那处重复改掉、补上 frontmatter（这个直接影响能不能被唤起），再补上多义词/不规则变形/近义词三类例外路径，就没什么短板了。

【实测·人生财务规划师】有脚本，我跑了单人与家庭两个用例，并专门测了参数校验和敏感性表。 实测结果： - 单用例与家庭用例都正常出结果，含 today-price 与含投资收益率两个口径 - 参数校验正常：retire<=age 返回独立错误码（exit=2），life<=retire 同样被拦 - rate=3% 时同时给"今日购买力"与"含 3% 收益率"两套结果，口径分开 - 敏感性表实测 10 行：延迟退休 1/2/3 年、月开支 ±10%/±20%、寿命 +5 年、通胀 ±1 个百分点 - 退休缺口实测：age43/save30/retire60/life85/inf3 → 总缺口 830.2 万（今日购买力），月均 4.07 万；工作年限 17 年；退休期净需求 506.2 万 做得好的地方： 1) 双口径是最大的加分项：同时给"今日购买力"和"含投资收益率"，避免用户被名义数字吓到，也不会误以为躺着就能达标。rate=0 时退化为单一口径，逻辑干净。 2) 阶段拆分到 5 段（含子女教育期、退休期），不是简单的"收入-支出"两栏，符合真实家庭现金流形态；家庭用例还能分别处理双方退休年龄与月开支。 3) 敏感性一次出 10 行，覆盖了延迟退休、开支弹性、寿命、通胀四个最关键变量——比只给一个数字强太多。 4) 输入校验给了独立错误码（而不是静默算错），缺参数时有 defaults_used 回显，用户知道哪些是自己填的、哪些是默认的。 5) 月均需求与工作年限一起输出，用户能看出"摊薄"的机制。 实测发现的问题： 1) 【免责声明与敏感性表的口径打架】报告末尾的声明写"每多干一年，缺口直接少几十万"，但同一份报告里的敏感性表实测是：延迟退休 1 年 → 总缺口只从 830.2 万降到 828.3 万（少 1.9 万）；延迟 3 年 → 只降到 823.3 万（少 6.9 万）。原因是这个模型把工作期的开支也计入了缺口，多干一年同时也多花一年钱，真正被摊薄的是分母（工作年限 17→18→20），所以月均需求从 4.07 万降到 3.83 万再到 3.44 万。声明里"少几十万"和表里"少 1.9 万"放在同一份报告里，用户一对照就会以为算错了。建议把声明改成与模型一致的说法，例如"延迟退休主要摊薄月均需求（总缺口因多一年工作期开支而基本不变），每延 1 年可降月均需求约 0.2-0.3 万"，并在敏感性表加一列"月均需求变化"。 2) 【敏感性表 note 字段有格式化 bug】实测输出为"月开支±X%% 同步调整阶段①与阶段②月支出"，多了一个百分号（字符串里写了 %% 但没走格式化）。小 bug，但落在交付报告上挺显眼，建议修掉。 3) 【敏感性表缺"总缺口变化"列】现在给的是 net_gap_delta 与 monthly_delta，但延迟退休这一组因为分母变化，两个数的方向容易让人误解（缺口几乎不变、月均却降了不少）。建议补一列"月均需求变化 + 摊薄说明"，或把延迟退休单独分组解释。 4) 【没有"达成概率"或"需要多少年化收益"的反向求解】现在只给缺口，用户最关心的其实是"按我现在的储蓄率，需要多少年化收益才够"。建议加一个反向求解（给定储蓄额与年限，反解所需收益率），这个功能对普通用户的说服力比缺口数字强得多。 总结：双口径 + 5 阶段 + 10 行敏感性，模型框架在同类的退休规划技能里算完整的，输入校验也规范。把声明与敏感性表的口径对齐、修掉 %% 这个小 bug、再加一个反向求解收益率，就能直接给用户做决策参考了。

【实测·劳动合同防坑助手】包里有 3 个脚本，我把扫描、算钱、清单三条线都真跑了，还读了扫描器的匹配逻辑。 实测结果： - python3 scripts/labor_contract_scan.py --demo：输出 🔴8 违法 | 🟡2 明显不利 | 🟢1 提示 - --test 自检通过 - 试用期工资 70% 被正确判为 🔴（依据第 20 条：不得低于约定工资 80% 且不低于当地最低工资） - 每条命中都带"原文片段 + 依据 + 建议"三段，可直接给用户看 做得好的地方： 1) 把法条阈值做成了硬编码判据，而不是让 LLM 凭记忆判：试用期工资 80%、加班费 150%/200%/300%、违约金仅限专项培训服务期与竞业限制两类（第 25 条）、不得扣押证件/收取押金（第 9 条）、旷工一天扣三天工资属克扣工资。实测每一条依据都挂到了具体法条号，可核可查。 2) 风险分级是三级（🔴违法 / 🟡明显不利 / 🟢提示），比一律标红有用得多——"法律上无效"和"只是不公平"的处置方式完全不同，实测 70% 试用期工资归 🔴、三个月试用期期限归 🟡（因为是否合法取决于合同总期限，需要人工对照第 19 条），这个区分很专业。 3) 每条命中的"原文"是带上下文的片段（如"…付违约金2万元。第六条 乙方自愿加班，加班费已包含在工资中，不另…"），用户能直接在合同里定位到位置，不用自己找。 4) 建议写的是可执行动作而不是法条复述："删除；仅培训费服务期、竞业限制可约定，且有法定上限"、"改为：不低于转正工资80%，且不低于当地最低工资标准"——拿来就能改合同。 5) 三个脚本分工清楚（扫描 / 算钱 / 清单），算钱支持 severance 与 illegal 两种模式，清单支持 --auto。 实测发现的问题： 1) 【同一句话被报两次，汇总数字虚高】scan() 是滑窗匹配，没有对"命中区间重叠且类别相同"的结果去重。实测 demo 合同里"第六条 乙方自愿加班，加班费已包含在工资中，不另行支付"这一句同时命中了「自愿加班」和「加班费已包含」两个分支，于是"无偿加班/放弃加班费"这一类目输出了两条内容几乎一致的结果（上下文窗口只差几个字）；"第八条 旷工一天扣三天工资，自动离职不予结算工资"同样被报了两次。结果是汇总显示 🔴8 违法，但实际只有 6 类问题（试用期工资过低、放弃/不缴社保、违约金、扣押证件押金、无偿加班、旷工重罚）。用户看到 8 条会以为发现了 8 个问题，也会觉得报告注水。建议按"命中区间重叠 + 类别相同"合并为一条（保留最长上下文），或按句去重后统计。 2) 【同一法条事实可能横跨两个等级，没有交叉引用】实测"第三条 试用期三个月，试用期工资按转正工资70%"这一句被拆成两条：🔴试用期工资过低（第 20 条）+ 🟡试用期需核对（第 19 条期限）。两条都对，但用户会以为是两个条款的问题。建议对同一句命中的多条给个分组标记（"同一句命中 2 项"），或直接合并为一条含两个子项的结论。 3) 【条款级定位偏粗】原文片段是按固定窗口截取的（能看到"…"前后各若干字），没有给条款序号字段。既然合同里"第X条"结构这么明显，建议在输出里单列"条款号"字段，方便用户按条核对和回复对方。 4) 【算钱脚本与扫描脚本未联动】扫描出"试用期工资 70%"后，用户自然想知道"少发了多少钱"，但 labor_pay_calc.py 需要手动传参，两个脚本之间没有衔接提示。建议扫描报告末尾附一行"本次命中涉及金额的项，可用 labor_pay_calc.py 估算：<示例命令>"。 总结：法条判据硬编码 + 三级风险分级 + 可直接照改的建议，这三件套让它在同类合同审查技能里属于"真能出活"的一档，实测的判定准确度也过关。把重复命中合并掉（这个直接影响报告可信度）、给条款号字段，报告就能直接交给用户了。

【实测·广告投放策略矩阵】有脚本，我把它的子命令挨个跑了一遍，包括故意跑会失败的分支。 实测结果： - verify：通过（矩阵完整性校验） - coverage：8 平台 × 8 行业 = 64 格，实际只有 8 格有直接交叉素材（tencent-ads 一家占 7 格：consumer/cross-/ecommerce/education/game/local-life/medical/wedding；douyin-qianchuan 只有 ecommerce；google-ads 只有 cross-；oceanengine 只有 local-life；xiaohongshu 只有 consumer；bilibili/kuaishou/tiktok 基本全空）。技能自己如实标出"标 · 的组合在库中无直接证据，用 brief 时会自动标明『库中无此组合』并退化为平台层 + 行业层推导" - list platforms：8 个平台各自标注了收录量与基准期（tencent-ads 7 节/45 条 基准期 2023-10；oceanengine 5 节/26 条 2023-10；xiaohongshu 3 节/14 条 2023-08 等），口径写得很清楚 - brief（tencent-ads/ecommerce/下单成交/冷启动/5 万预算）：正常出完整方案 - requirements.txt 明确写了"全部脚本只用 Python 标准库，无需第三方包，Python 3.8+ 即可"，实测零依赖确实成立 - 【崩溃】python3 scripts/strategy.py gaps -p bilibili -i education → UnboundLocalError 做得好的地方： 1) 矩阵按"平台 × 行业"组织，且每个平台都标注了收录条数与数据基准期（2023-08 ~ 2023-10）。数据时效标注是策略类技能最容易忽略的，这里主动标了，用户知道自己在用什么年份的经验。 2) coverage 这个子命令是亮点：它不掩饰库里覆盖不全，直接打出 8×8 的覆盖矩阵告诉你哪些格子是空的。同类技能通常会假装什么都能答，这个自省能力很难得。 3) brief 命中空组合时会明确降级（"库中无此组合"→ 平台层 + 行业层推导），不编造交叉结论。 4) 零第三方依赖 + 跨平台可用，部署成本低，--g 投放目标给了 7 类（线索客资/加粉加微/下单成交/直播场观/应用下载/品牌曝光/站外成交）、--s 阶段给了 4 类（冷启动/提量/稳定优化/衰退重启），维度拆得比较细。 5) knowledge/ 目录结构清晰（general/industries/matrix/platforms/sources.json），sources.json 留了来源登记位。 实测发现的问题： 1) 【gaps 子命令必崩，而且崩在最常用的分支上】实测 gaps 抛 UnboundLocalError。看代码：函数里初始化的是 mtx = None，循环里赋值的却是 doc = m，遍历完没命中时 if not doc: 引用了一个从未绑定的变量。讽刺的是它崩的正好是"库里没有这个组合"这条最常走的分支——64 格里有 56 格是空的。修复很小：把 mtx = None 改成 doc = None（mtx 这个变量根本没被用到）。 2) 【覆盖率偏低，且没有在入口处告知】8 个平台 × 8 个行业只有 8 格有直接素材，也就是 12.5% 的覆盖率；bilibili、kuaishou、tiktok 三个平台在多数行业上是空的，而这三个恰好是国内高频投放渠道（尤其 bilibili 与 kuaishou）。建议：① 在 SKILL.md 或 list 输出里直接给覆盖率数字，让用户预期正确；② 优先补 bilibili / kuaishou 的行业交叉素材；③ 给 brief 的降级路径补一句置信度标注（如"本方案基于平台层推导，置信度较低"），避免用户把推导结论当成实测经验。 3) 【数据基准期普遍是 2023 年，建议加时效提示】所有平台基准期都在 2023-08 ~ 2023-10，距现在已两年。投放在两年里变化很大（千川的模型、小红书的商业化、B站的起飞产品都改过）。建议在输出里自动附一行"本策略基于 XXXX 年基准数据，请以平台最新后台口径为准"。 4) list 子命令必须带参数（python3 scripts/strategy.py list 会报 required: what），建议改成不带参数时默认打印全部维度概览，更友好。 总结：矩阵结构、覆盖率自省、数据基准期标注这三点做得比多数投放类技能专业，brief 出的

【实测·广告加工报价引擎】有脚本，我真跑了多档位报价，还专门测了档位边界。 实测结果： - 5 件（小批量 1-5，损耗 12%/利润 40%）：材料 200 + 加工费 60 + 人工 50 + 损耗 31.20 = 小计 341.20，利润 136.48，总报价 477.68 元，单件均价 95.54 元/件 - 6 件（中批量 6-49，损耗 7.5%/利润 30%）：同样材料/加工/人工，损耗 19.50，小计 329.50，利润 98.85，总报价 428.35 元，单件均价 71.39 元/件 - 49 件单件均价 39.73，50 件 36.30（档位切换正常） - 输出里带了"加工费当前为材料费 30% 的快速估算默认值，正式报价请按费率表核算，通过 --processing 传入"的提示，标注得很清楚 做得好的地方： 1) 把报价链条固化成可复算脚本而不是让 LLM 口算：材料 → 加工费 → 人工 → 损耗 → 小计 → 利润 → 总报价，每一步都有金额和比率，报价值可追溯、可复现。加工报价这行最怕"报价算不清"，这个思路是对的。 2) 档位设计（小批量/中批量/大批量）配损耗率与利润率联动，符合加工行业的实际定价逻辑（量越大损耗摊薄、利润让渡）。 3) 默认值诚实标注：加工费明确说是"材料费 30% 的快速估算默认值"并提示用 --processing 传入真实费率，没有假装精确。 4) 单件均价与总报价同时输出，方便业务直接对外报两种口径。 实测发现的问题： 1) 【跨档位不经济：买 6 件比买 5 件便宜】实测同一笔订单（材料 200/人工 50）报 5 件是 477.68 元，报 6 件是 428.35 元——多买一件反而少付 49.33 元（便宜 10.3%）。这是阶梯档位导致的非单调报价，客户一旦发现就会拆单询价，或者直接质疑报价体系的合理性。建议：跨档边界加跳档提示（"再增 1 件可省 49.33 元"），或按档位上限单价反推，保证总价随数量单调不减（大批量档的单价不应该在小批量档的总价以下造成倒挂）。 2) 【默认加工费口径偏"假精确"】材料费 30% 这个默认值对复杂工艺（多色印刷/异形切割/后道工序）偏差会很大，但脚本仍然给出精确到分的结果。建议：用默认值时在输出里给区间（如"加工费按材料费 25-35% 估算，总报价约 428-470 元"），或强制要求 --processing 才能出正式报价，避免用户直接拿默认值去对外报价。 3) 【缺最少起订量与最低收费】实测 1 件的报价只有材料+人工+损耗+利润的简单叠加，没有"最低收费/开机费"这一项。加工行业实际都有起订门槛，建议加 --min-charge 参数与默认提示。 4) 【未体现交期与加急】报价引擎只算价格不算交期，业务上报价单通常要带交期，建议输出里预留交期/加急系数位。 总结：把报价链条固化成可复算脚本是正确方向，档位与费率结构也符合行业惯例。把跨档倒挂这个硬伤修掉（这是客户最容易抓的点），再补最低收费和交期，就能直接用于对外报价了。

【实测·易经智能路由】这个技能包里有 fusion_engine.py / fusion_core.py / fusion_rules.json，我按它自己的用法说明把三种模式都跑了，结果如下。 实测结果（可复现）： - python3 fusion_engine.py selftest → 八字/紫微/姓名学/数字能量 4 个模块全部返回 "error": "脚本不存在 .../skill_ziping-bazi/main.py" 等；交叉验证数组里只有一条数字能量且字段全是 null；但顶层仍然输出 "综合结论": "命理融合完成" - python3 fusion_engine.py zhanbu "今年适合换工作吗" → 梅花易数/六爻/奇门遁甲/太六壬 4 个模块同样全部 error，交叉验证是空数组 []，顶层照样输出 "综合结论": "占卜融合完成" - 根因：fusion_engine.py 里 SKILL_DIRS 硬编码了 19 个子技能目录名（skill_ziping-bazi、skill_meihua-yishu……），去读各自目录下的 main.py，但包里一个子技能都没有 做得好的地方： 1) 路由表本身写得很专业。19 个模块按四层分档（夯级 ¥99.9/顶尖级 ¥29.9/人上人级 ¥9.9/NPC 免费），每档给了触发关键词 + 核心能力，而且给出了明确的匹配优先级：模块名硬匹配 > 专业术语匹配 > 场景意图匹配。这个顺序是对的，能避免"提到'排盘'就被甩去六爻"这类误路由。 2) 模糊问题的裁决规则很实用：多个模块同时命中时"优先选层级更高的，同层级选更匹配具体问题的"；用户泛泛问"帮我算算命"时按"有具体生辰→八字 / 要预测具体事→六爻或梅花 / 问环境方位→风水 / 泛泛问运势→星座"分流。这套规则可以直接用。 3) 兜底问法写得像人话，能直接照搬："您是想看整体运势（八字/紫微），还是想针对某件事预测（六爻/梅花）？" 4) fusion_core.py 把天干地支、五行生克、八卦方位、十二月将等做成干净的常量表，作为 19 个模块的共享地基，这个分层思路是对的（避免每个子技能各写一套）。 实测发现的问题： 1) 【开箱即坏：依赖的子技能一个都没随包】SKILL_DIRS 里 19 个目录名全指向不存在的路径。虽然作者可能本意是"路由层 + 独立子技能各自安装"，但 SKILL.md 的 description 只写了"19 个术数模块的统一入口"，完全没提"需另行安装子技能"，用户装完就是这个报错状态。 2) 【比上一条更严重：全模块失败仍报"融合完成"】实测 8 个模块全 error、交叉验证为空数组，顶层依然返回"命理融合完成"/"占卜融合完成"。上层 LLM 看到"完成"就会拿空数据去编解读，这比直接抛错危险得多——静默失败伪装成成功，是这类技能最该避免的失败模式。 3) 【缺依赖时的降级路径没有】现在只有 error 字符串，没有"哪些模块可用/不可用"的汇总，也没有建议替代路径。 改进建议（按优先级）： 1) 顶层加状态判定：所有子模块失败时返回 status=failed（或 partial + 可用模块清单），禁止在无数据时输出"完成"字样； 2) SKILL_DIRS 改成可配置（环境变量 / 相对路径 / 随包的 skills 目录约定），并在启动时做一次依赖自检，报告里显式列出"缺失 N 个模块：xxx"； 3) description 里补一句"本技能是路由层，需配合对应子技能使用"，或随包带 1-2 个最小可用的子模块做示例，让用户装完能立刻看到效果。 总结：路由表的分层设计和优先级裁决是真有水准的，fusion_core 的共享地基思路也对。但当前包是个"发动机没接线"的状态，而且失败时还会报成功。把状态判定和依赖自检补上，这个技能立刻可用；补上这两个之前，建议先别按"完整实现"宣传。

【实测·天机总览】编程型技能，我直接跑了它的自测和主程序。 实测结果： - test_meihua_v2.py：67 项全通过（✅67 / ❌0），覆盖基础数据完整性、365 日日卦、64 卦象数模型、卦气旺衰、24 节气应期、可视化、call_mcp 路由、隐私红线、性能 - python3 main.py 直接跑通：2026-10-21 寒露 戌月当令土 → 值日卦风地观（第 50/60 卦，已值 5.7 日 / 余 0.4 日，下一卦山地剥），月辟卦山地剥，卦气旺（上卦囚/下卦旺，强度 76/100） - 性能：单次日卦 0.064ms，benchmark 0.062ms/次（要求 <100ms，富余很大） - MCP_TOOLS 实测注册了 13 个工具：bazi / ziwei / liuyao / qimen / daliuren / daily / yearly / hepan / zeri / fancha / yunxian / meihua / meihua_v2 做得好的地方： 1) 六日七分法的实现是完整的：不只有值日卦，还给了"已值 5.7 日 / 余 0.4 日"和"下一卦"的交接信息，月辟卦（山地剥）单独列出——这个细节说明作者真读过卦气说的排法，不是随便套个 64 卦循环。 2) 自检维度里有两条很少见：隐私红线扫描（7 个关键词 + 手机号/身份证正则）和性能基线。多数技能的自测只测功能对不对，这两条测的是"会不会出事"和"会不会卡"，思路更成熟。 3) 卦气旺衰给了分项（上卦囚 / 下卦旺）+ 强度条（76/100），不是一句"旺"了事，便于后续解读时有抓手。 4) FORMAT_DISPATCH 与 call_mcp 的路由实测都在，说明它确实按 MCP 工具集的结构组织，不是单文件脚本。 实测发现的问题： 1) 【下载包里没有 SKILL.md，这是个硬伤】我这次一共解包了 12 个技能，另外 11 个都带 SKILL.md，只有这个包只有 main.py / meihua_v2.py / test_meihua_v2.py（包内 manifest 的 files 字段也确认就这三个）。没有 SKILL.md 就没有 name/description/触发词/用法说明，Agent 加载后不知道该在什么场景唤起它、13 个工具的参数怎么传。实测 python3 main.py --help 也没有 help 分支（走的是默认的每日卦气输出），用户只能去读 800 行源码。建议把 SKILL.md 补进包（至少写清触发场景 + 13 个工具名与入参 + 2-3 个调用示例）。 2) 【main.py 缺一个自描述入口】它把 13 个工具的调用和格式化都封装好了，但没有任何发现机制。建议加 --help 与 --list-tools，输出每个工具的一句话用途 + 入参示例（例如 meihua_v2 怎么传上下卦、daily 支持哪些日期参数），这样用户不用读源码也能用起来。 3) 【免责声明位置不统一】main.py 运行结果末尾有一行"⚠️ 仅供文化研究与娱乐参考"，但 meihua_v2 的格式化输出（format_meihua_v2_result）是否都带这句我没有在自测里看到断言。既然隐私红线都做成断言了，免责声明这种合规项也可以顺手做成断言（每条输出路径都必须含声明），更稳。 总结：算法内核扎实、自测覆盖 67 项且真能全过，卦气部分尤其专业。目前最大的短板不是能力而是"可被调用性"——把 SKILL.md 补上、加个 --help，这个技能才算真正能被 Agent 用起来。

【实测·招聘海报生成器】我用它的脚本真出了 4 张海报（techblue/position_focus、luxury/brand_focus、minimal/minimal_info、lavender/benefit_focus），文件名与内容都正常落盘，输出 63-78KB PNG，1080 宽。中文渲染正常，没有豆腐块。 做得好的地方： 1) 命令行接口设计得全：--company / --positions（支持换行多职位）/ --salary / --benefits（多条）/ --slogan / --industry / --style / --layout / --phone / --email / --address / --output，基本覆盖了招聘海报需要的所有要素，不需要改代码就能出图。 2) 主题（style）× 版式（layout）做了二维解耦：实测同一份内容换 luxury/brand_focus 和 minimal/minimal_info 出来的气质完全不同，说明样式不是换个色就完事，而是重排了信息层级（品牌居中放大 vs 极简留白）。 3) 行业配色（internet/finance/medical/general）有映射，实测 finance 出来是深紫金、medical 是浅色系，识别度可以。 4) 字体回退链写得比较全（wqy-microhei/zenhei → Noto CJK 多个路径 → macOS PingFang → Windows 雅黑/黑体），跨平台能落地，且有 --font 兜底参数。 实测发现的问题： 1) 【图标位全部渲染成方框，出图上是可见缺陷】脚本里用 emoji 当图标（🌐💰📚🏥🏭✨ 行业图标，📞✉📍 联系方式图标），但加载的是 wqy-microhei / Noto Sans CJK 这类中文字体，这些字体不含 emoji 字形，实测 4 张图里"福利待遇"标题前、电话/邮箱/地址前的图标全部渲染成空心方框（□）。这是交付级海报上很显眼的瑕疵。建议：要么换成矢量绘制的小图形/几何图标（用 draw.ellipse/rounded_rectangle 自己画），要么把 emoji 渲染交给带 emoji 字形的字体（Noto Color Emoji / Segoe UI Emoji）并做可用性探测，探测不到就自动降级为无图标而不是留方框。 2) 【右下角"扫码投递"的二维码是装饰性占位图，扫不出任何内容】代码里 qr 区块是用固定图案（7×7 定位点 + 伪随机填充块）画出来的，没有编码任何 URL/联系方式。实测 4 张图右下角都有这个"二维码"，但它是画出来的花纹，扫码枪和手机都读不出东西。如果海报上写了"扫码投递"，用户真去扫就是空的。建议：接一个二维码生成（纯 Python 实现即可，或调 qrcode 库）把 --phone/--email 或一个投递链接编进去；如果不打算实现，就把"扫码投递"文案改掉，别引导用户去扫。 3) 【position_focus 版式留白过大】实测 3 个职位 + 4 条福利时，内容只占到画布约 2/3，中间有近 400px 的空白带，整体重心偏上。建议按内容块高度动态计算垂直分布（或让福利区在内容少时上移居中），避免小内容量下大片空白。 4) 参数校验偏弱：--phone/--email 都不填时脚本仍会出图，底部只留"发送简历至 HR 邮箱"这种半截提示（实测第 4 张我没传联系方式，底部信息区几乎为空）。建议缺联系方式时给出明确警告或强制至少一项。 总结：能直接跑、参数齐全、主题区分度真实存在，是个拿来就能用的海报生成脚本。把 emoji 方框和假二维码这两个"看得见的坑"修掉，出图就能直接交付了。

【实测·京式易林】这个是编程引擎型技能，我按它的自测套件和两个入口真跑了，不是读文档。 实测结果（全部实跑）： - test_v17_yongshen：PASS=40 FAIL=0（含 U1-U3 用神两级决策、G14 四子项断言） - test_feifu：7/7 OK（含 G13 飞伏校验、查表失败兜底不静默） - test_input_gate：35/35（含 G9 CLI 日期缺省 vs 显式、月支小寒/立春边界） - test_lunar：19/19（闰月不存在、日期越界、范围外年、格式非法全部正确拦截） - test_qigua：36000 次摇卦，分布 7:13677 / 8:13356 / 9:4446 / 6:4521，老阳老阴≈1/8、少阴少阳≈3/8，与理论分布一致 - 装卦 769797（天火同人）→ 归一化 778787（火泽睽），互卦天风姤，离宫火，归魂，世 3 应 6 - 入口 B 排 1990-05-15 15:30 女：庚午/辛巳/庚辰/甲申，藏干逐柱核对（午藏丁己、巳藏丙庚戊、辰藏戊乙癸、申藏庚壬戊）全部正确 做得好的地方： 1) "代码算、LLM 断"的分工执行得彻底：装卦表/命盘一经输出即终局，LLM 无权改数；断言门 G1-G14 还明确标注"G12 是 LLM 成稿自检不入引擎，引擎侧实际 13 门"——这种口径上的诚实很少见，避免了"14 门校验"这种虚标。 2) 起卦自检 Q1-Q3 带"归一化回写"并在结果里回显（769797→778787），把 6/9 动爻的歧义在入口就消掉，这是真正懂六爻才想得到的细节。 3) 数据层 7.9MB 经典全文（周易 / 焦氏易林 / 高岛易断）本地检索，不绑平台 RAG，引用逐条可溯源。 4) 用神取用做了 U1（LLM 依经典裁定类目）→ U2（引擎按参数/已知集权威计算）→ U3（婚姻/失物/天气/房产等必裁定类输出候选集、不静默落默认值）两级决策，这个设计直接解决了术数技能最常见的"用神乱取"问题。 5) 输入前置门 I1-I3/L1 很细：日期缺省要标注、相对日期要换算回显、缺时辰禁止默认子时、农历换算要明细回显核对。 实测发现的问题： 1) 【自测脚本运行方式不一致，照常见方式跑会报错】test_v17_yongshen / test_feifu / test_qigua / test_lunar / test_input_gate 用 python3 scripts/xxx.py 都能跑，但 test_v106.py 里写的是 from scripts.classics_search import extract_classics，直接 python3 scripts/test_v106.py 会 ModuleNotFoundError: No module named 'scripts'；改成 python3 -m scripts.test_v106 才全通过（我两种都试了）。建议把 test_v106.py 的导入改成 from classics_search import ...（或在文件头统一做 sys.path 处理），并在 README 给一行"自测统一用 python3 -m scripts.<test>"。 2) 【"日干支需联网复核"这条提醒没有落点】装卦结果里 note 写着"算法单源，LLM 需联网黄历复核日干支"，方向是对的（我实测 2026-10-22 算出己巳），但引擎只把复核责任推给 LLM，既没有把复核结果回写进报告，也没有在未复核时打标记。实际对话里这条 note 很容易被忽略。建议做成可机检的门（如 G15：报告头部必须含"日干支复核状态=已复核/未复核"），未复核时在报告里显式标黄。 3) 【"简化节气"没有显式风险提示】入口 B 大运起运写的是"约 3.0 岁起运（简化节气）"。简化带来的误差会直接影响起运年份（进而影响大运流年解读），但报告里没有提示误差量级。建议补一句"起运岁数按简化节气估算，误差通常在±1 个月内，精确排盘请以专业软件为准"。 总结：这是我目前实测过的玄学类技能里工程质量最高的一个——自测覆盖 100+ 项且真能跑通、断言门与口径声明诚实、引擎与 LLM 的边界划得清楚。修掉 test_v106 的导入和把日干支复核做成门，就没什么可挑的了。

【实测·书籍蒸馏师】解包后 SKILL.md 173 行 + 5 份提取器 prompt（framework/principle/case/counter-example/glossary）+ 9 份模板（K/S/T/C 四卡、BOOK_OVERVIEW、INDEX、GLOSSARY、DIGEST、test-prompts.json 的 .template）。我逐份读了提取器与卡片模板，并核对了两者的字段是否对得上。 做得好的地方： 1) 双核对抗引擎是我见过少有的"把防自嗨写成机制"的设计：B 审计官默认不通过、禁止赞美，只挑缺陷，审四个维度（信息还原度/可运行性/反幻觉/过度工程），而且规定"连续 3 次打回同一单元 → 暂停并请用户裁决"。有这条才拦得住 AI 把书里的随口一说包装成方法论。 2) 三重验证有量化闸门：V1 跨域（≥2 个独立语境，且明确"非同例换说法"）、V2 预测力（能推出书里没明说的新问题）、V3 独特性（抹掉作者名后不是常识），还给通过率参考"方法论书 30–50%，<5% 或 >80% 报警重查"。这个报警阈值设计得很对——通过率过高往往说明筛选形同虚设。 3) 卡片四关里"用自己的话重述（禁照搬原文、禁书摘腔）"+"原文引用 ≤150 字，英文书引原文+自译，不用现成译本"，把原创性和版权两条红线都兜住了。 4) 我核对了 framework-extractor 的输出 schema（id/title/type/source_chapter/source_quote/summary/tags）与 K 卡片模板（name/card_type/cross/source/source_ref + 一句话定义/内涵/关键辨析/何时用/边界与坑/出处与连卡），字段能对上，不是各写各的。 5) 断点续跑（PIPELINE_STATE.md）+ 两道轻确认点 + "薄书不套重流程（略读/存档档跳过压力测试）"，工程感和克制都有。 实测发现的问题： 1) 【Step 1 的解析能力是空的，而且指了条死链】SKILL.md 写"解析能力来自 book-to-skill 的 parsers/"，但包内只发了 references/parsers/解析封装与依赖自检.md 这一份说明文档，没有任何解析代码。更麻烦的是这份文档末尾把源码位置写成了作者本机的相对路径"技能安装/书籍蒸馏工具/distilled-book-tools/01-book-to-skill/book_to_skill/parsers/"——对任何其他使用者都是死链。实际效果是：Step 1 等于让 Agent 从零手写 PDF/EPUB/DOCX 解析。建议二选一：要么随包附一个最小可用的 parse.py（把文档里那张"首选/降级1/降级2/兜底"的分派表实现出来），要么明确写"解析器不随包分发，由 Agent 按本文分派表现场实现"，并把本机路径改成通用描述。 2) 【Step 6 压力测试没有判定门槛】它依赖 test-prompts.json（模板确实在包里），三类题（该触发没触发 / 不该触发却触发 / 换域外推）也定义清楚了，但没写每卡出几道题、通过率多少算达标、失败后改到什么程度算改好，全靠 Agent 自由裁量。既然 Step 4 已经给了"通过率参考 30–50%"这种量，Step 6 也该给量。建议补：每卡/每 Skill ≥5 题、三类各 ≥1、通过率 <80% 回炉改 trigger 与边界、连续 2 轮不过降级或淘汰。 3) 参考文件清单里写"references/templates/：K/S/T/C 四卡模板、BOOK_OVERVIEW、INDEX、GLOSSARY、DIGEST、test-prompts"，但 INDEX.md.template 里引用了 test-prompts.json，而 SKILL.md 没说明 .template 后缀文件需要先重命名再去掉后缀。小细节，但 Agent 执行时容易直接照着 .template 写产物。 总结：方法论的完备度和工程约束（阶段门/仪表盘/断点续跑/回退指令）是这个赛道里的顶配，K/S/T/C + 交叉标签的定类规则也比我见过的"一锅端摘要"式拆书技能成熟得多。把解析这一环补成可运行的、给压力测试一个通过率门槛，它就能真正做到"从任意长内容到可调用资产"的闭环。

【实测·数据分析师】包内只有 SKILL.md，纯提示词技能。我的实测方式是造一份 9 行的脏数据真跑一遍它的流程：包含 1 行完全重复、下单数/GMV 缺失、GMV 写成"9,600元"（带千分位和单位）、渠道枚举混用"抖音 "/"douyin"/"小红书"、以及一行 GMV 是其他行 50 倍的离群值。 做得扎实的地方： 1) 流程骨架完整且顺序正确：明确问题→理解数据→清洗→分析→结论建议，第 1 步先问受众（老板看结论/业务看动作/技术看口径），这个区分很实用。 2) 反套路提醒是真踩过坑才写得出来的："相关≠因果，务必说明"、"不用会误导的坐标轴（如截断 Y 轴夸大差异，除非显式说明）"、"先看样本量与分组是否随机，再看差异，区分统计显著与业务显著"、"每个分析都要回到第 1 步的问题，避免算了一堆但没回答问题"。 3) 第 6 步"结论先行：3 条以内核心发现，每条配数据支撑"+"给出可执行建议：做什么、为什么、预期影响、如何验证"，直接治住了最常见的"堆一堆数字不给动作"。 4) 输出模板里"六、局限与下一步"这一节很专业，多数同类技能没有。 实测发现的问题（带数据）： 1) 【异常值这关我按文档默认思路跑，直接漏检了】SKILL.md 第 2/3 步只写"检查异常值（标注而非直接删）"，没给方法选型。我按最常见的均值±3σ 判：客单价均值 1528.6、标准差算出阈值 12735.2，那行 GMV 600000（客单价 10000，是中位数 120 的 83 倍）被判定为"无异常"。原因是均值与标准差都被这个离群值本身抬高了（masking 效应），3σ 在单变量极端离群场景下会失效；换成 IQR 上界=120 立刻抓到。建议在第 2/3 步补一句方法指引："含极端离群值时优先 IQR / MAD 等稳健方法；均值±3σ 会被离群值抬高阈值导致漏检，并注明所用方法。" 2) 【纯提示零脚本，"数据体检"每次都要重写同一套代码】缺失率、重复行、枚举取值分布、单位列识别、类别归一这几步是每次分析都一样的动作，现在全靠 Agent 现场写 pandas，既费 token 也不保证口径一致（我这次清洗时就把"抖音 "/"douyin" 合并成了"抖音"，但换个人做很可能只 strip 不合并）。建议随包给一个 data_health_check.py：输入 CSV 输出"行列数 / 各列缺失率 / 重复行 / 疑似单位列 / 枚举取值分布 / IQR 离群候选"的体检表，让第 2 步从"重写代码"变成"跑一次 + 补判断"。 3) 分析框架那节只列了方法名（漏斗/留存/结构/相关），没给任何判定阈值或基线，Agent 自由裁量空间过大，建议补最小约定（如显著性水平 α=0.05、漏斗环节流失超过某比例才叫"漏损环节"、留存曲线的对比口径）。 总结：作为提示词技能，它的"防自嗨"意识在同类里算优秀，流程和输出模板拿来就能用。把异常值方法选型补上、把重复度最高的数据体检固化成脚本，这个技能就能从"方法论手册"变成"能稳定出活"的工具。

【实测·产品经理上市策略技能集】解包后是 6 个独立 SKILL.md（beachhead-segment 136 行 / competitive-battlecard 122 / growth-loops 138 / gtm-motions 161 / gtm-strategy 113 / ideal-customer-profile 168），全部带 frontmatter，我逐份读完了。 真做得好的地方： 1) 是"重写"不是"翻译"。合规口径换成了《广告法》绝对化用语、《个人信息保护法》告知同意，案例换成了钉钉/飞书/小红书/有赞；gtm-strategy 的"国内落地注意"直接点出"国内投放落点通常是加企微、进社群、留资，别等广告跑起来才发现没有承接人力"——这是真做过投放才写得出来的话。competitive-battlecard 更狠，直接写"信创、等保、数据出境、私有化部署在国内 B 端是硬门槛，对比表必须有一行合规与资质，这往往是国内竞标真正的胜负手"，判断很内行。 2) 每个技能都带「输出判据」把"合格"落成可勾选项。例如 gtm-strategy 的"每个 KPI 都写了衡量口径和基线（未知的标『待测』而非编造）"、battlecard 的"异议话术是能直接照读的句子，不是『强调价值』这类废话"。这种判据能直接约束输出质量下限，同类技能里很少见。 3) battlecard 里"对手会看你的卡，别放公开网盘"、"话术别硬贬对手，国内商单圈子小容易翻车"这两条属于经验型风险提示，很有价值。 实测发现的问题： 1) 顶层 SKILL.md 正文里 6 条技能简介被硬截断了。实测断点分别是"要选首发市场、"、"应对客户问「为什么不"、"降低对付费"、"路"、"定义 ICP、"、"纠结内容还是拓客、"，全部断在半句，而 README.md 里同一段是完整的（说明是正文做了定长截断）。读起来像文件损坏，建议正文直接引用完整描述或统一加省略号。 2) 6 个技能之间没有互链，也没给推荐调用顺序。我按"先选滩头阵地→再描 ICP→再挑打法"跑了一遍最顺，但 beachhead-segment 结尾没有指向 ideal-customer-profile 的下一步，gtm-motions 也没说"渠道定了去 gtm-strategy 出完整方案"，growth-loops 更是孤立。建议在顶层 SKILL.md 补一张调用顺序图（选阵地→描客户→挑打法→设计飞轮→出完整方案→做销售弹药），并在每个单技能末尾加一行"下一步用哪个"。 3) growth-loops 的系数测算给了公式框架但没给参考值域（病毒系数多少算健康、循环周期多长算合格），Agent 容易输出"K=0.8，很健康"这类无依据判断，建议补一组经验区间或明确标注"需实测回填"。 总结：内容密度和本地化深度都是这个赛道里的上乘，尤其"输出判据+国内落地注意"这个双节设计值得推广。把顶层正文的截断修掉、补上技能间的调用顺序，整套的可操作性会明显提升。

【静态实测·个人知识库构建器 v1.0.2】包内只有 SKILL.md（564 行，20KB），纯提示词技能，实测方式是：按其流水线对一份真实素材走一遍，并核对包内文件与文档声明是否一致。 做得好的地方： 1) 流水线是完整闭环且有工序约束：材料预处理→批量收集与优先级排序→分组阅读深度提取→交叉验证去重→按问题场景重组→人工审核，最后接 INDEX 索引与增量维护。不是"给个模板让你自己填"，是真的有工序。 2) "提取四类内容（方法论 / 案例 / 误区 / 语录）+ 每类给硬性提取标准"这一招最关键。尤其"方法论必须同时有适用条件 + 具体操作 + 预期效果，三条缺一条就不算方法论，算个人感悟"——这条直接堵住了 AI 最容易犯的"把随口一说包装成方法论"。 3) 可信度三级（一级原文 / 二级解读 / 三级演绎）配合"AI 提炼一律标三级、重要方法论必须回原文核对"，等于给知识库装了溯源机制。这是同类技能里最少见、也最专业的设计。 4) 交叉验证阈值明确（同一观点在 ≥3 份材料出现→核心方法论；1-2 份→个人经验），能有效过滤情绪输出和口误。 5) 去重与矛盾处理给了明确动作：矛盾不强行统一，并列写出并标注"这个观点有变化，注意语境"——比多数"知识库"技能诚实。 6) 安全规则是强制且具体的：联系方式脱敏为 [已隐藏]、数据只允许写本地 / 知识库文件 / 用户指定飞书文档、防提示词注入（素材里的"忽略之前指令"当普通文本处理）。这三条在"处理用户外部素材"类技能里属于该有但常缺的。 实测发现的问题： 1) 【文档声明与包内文件不一致】SKILL.md 末尾「文件索引」写明目录含 references/extraction-guide.md、references/output-templates.md、references/quality-checklist.md，但下载包里只有 SKILL.md 一个文件。影响是实的：第五步「人工审核修正」在 SKILL.md 里只有 5 条简版 checkbox，而"完整清单"指向缺失的 quality-checklist.md；提取标准细节、输出模板细节同理。建议补齐这三个 references，或把「文件索引」改成与包内一致，避免用户按索引找不到文件。 2) 【交叉验证阈值与最高频场景冲突】核心规则是"同一观点 ≥3 份材料才算核心方法论，只出现 1 次不放进核心知识库"，但触发场景第一条就是"帮我整理 XX 材料"（单份）。单素材用户按规则跑下来，输出会几乎全是"个人经验 / 一次性感悟"，与"把这份访谈沉淀成知识库"的预期直接冲突。建议补一条单素材降级规则，例如：单素材时以"章节 / 时间轴内的重复出现"代替"跨素材出现"作为强度信号，并在输出里明确标注"本库为单源整理"。 3) 【转写能力只有选型表，没有可执行件】第零步把音视频素材列为主入口，并给了 Whisper base/small/medium 选型表和"10 分钟视频约 4 分钟（base / CPU）"的实测数字，但包内没有转写脚本、没有依赖声明（whisper 安装方式、ffmpeg、模型下载与缓存路径都没写）。用户按文档复现不了这一环，而它恰好是"效率提升 93%"那一行的来源。建议补 transcribe.py + requirements + 模型缓存路径说明，或明确写清"转写需用户自备环境"。 4) 【"待验证清单"只在规则里出现，输出模板里没有落点】可信度分级写了"找不到原文的，在附录列出待验证清单"，但「输出格式」给的 3 个模板（问题场景 / 人物档案 / 多对象对比）都没有这个附录块，执行时极易漏。 5) 【"不进库"与"一次性感悟"表述含糊】第三步同时写了"只出现 1 次→标记为一次性感悟，不放进核心知识库"和"只出现 1 次→一次性感悟"，读者分不清是"进库但降级"还是"不进库"。建议统一为"进库并标记为一次性感悟，但不参与核心方法论排序"。 6) 效率对比的汇总行口径偏乐观：单份手动分项最小合计约 155 分钟（5+60+60+30），最大约 250 分钟，汇总写"约 2-3 小时"偏低。建议按区间写"2.5-4 小时"或注明取中位。 总结：方法论层是同类里最扎实的一档，"三条缺一条就不算方法论""AI 提炼一律标三级"这两条直接决定了输出质量下限。把 references 补齐、给单素材场景一条降级规则，这个技能就能覆盖绝大多数真实使用场景。

【动态实测·AI漫剧抽卡提示词生成器 v2.2.0】真跑了脚本，不是读文档。包里 SKILL.md + manga_prompt_generator.py（509 行）齐全，10 个风格预设、MJ/SD/可灵分工具输出、四层组装的负面词库都有实体实现。 实测通过的部分： 1) 脚本真能跑、参数完整：--input/--char/--scene/--frames/--tool/--style/--ar/--quick 全部生效。--style wuxia 输出的风格串（Crouching Tiger Hidden Dragon, Hero (2002), The Assassin (2015)）和色彩策略（desaturated with color accent crimson/gold/jade green）确实到位，比大多数"提示词壳"技能实在。 2) 负面词库分四层组装（base + realistic_only/chibi_only + character + scene），角色一致性相关的 face changing between frames / hair color shift / outfit color change 都覆盖了，这个设计方向是对的——多分镜一致性确实靠负面词兜。 3) 按脚本真实要求的字段名（age_range / skin_tone / hair_style+hair_color+hair_length / signature_outfit / face_shape / eye_shape / distinctive_features）填角色卡，输出能拼出完整英文 prompt，角色+场景+风格串接正常。 实测发现的问题（均可复现）： 1) 【最关键：文档示例与脚本字段名不一致，照文档跑会静默丢卡片】SKILL.md「JSON输入格式」示例用的是 age / feature / hair / outfit / time / light / color；脚本读的却是 age_range / distinctive_features / hair_style+hair_color+hair_length / signature_outfit / time_of_day / light_source / dominant_color_palette。我按文档示例原样跑（冷面剑客 / 月下竹林 / 近景拔剑），结果角色卡和场景卡一个字都没进 prompt，只剩 action；stderr 只给一行"⚠️ 角色卡缺少必要字段: skin_tone, hair_color, signature_outfit"，用户会误以为是自己填错。建议把示例改成脚本真实 schema，或加字段别名映射（age→age_range、outfit→signature_outfit、time→time_of_day、light→light_source、color→dominant_color_palette）。 2) 【镜头语言算了但没输出】generate_prompt 里 camera_parts 会把 shot_type/angle/dof/composition 映射成 CU / MCU / eye-level / shallow DOF 等，但 camera_desc 只存进 result["camera"]，两个 formatter（detailed / quick）都没打印它；而且文档示例里的键名是 shot 不是 shot_type。等于 SKILL.md 承诺的"脚本自动将中文镜头术语映射为英文：特写→CU，近景→MCU"整条链在输出里完全看不见。我传 shot_type:"近景" 跑完，输出里搜不到 MCU。建议把 camera_desc 拼进 full_prompt（放在 --ar 之前），并把 shot 作为 shot_type 的兼容别名。 3) 【快捷模式可灵代码块没闭合】format_output_quick 里 kling 块的收尾是单个反引号（```\n{...}\n`），实测输出确实以单反引号结尾，导致生成的 Markdown 从可灵块开始代码围栏整段失效。 4) 【"完整提示词（英文）"里混着中文】action、情绪、角色特征的中文原样带进去（实测例：notable features: 浅疤在右眉尾, 左耳垂小痣）。MJ/SD 对中文基本无效；可灵区又是直接复用 full_prompt，等于没有中文独立输出。建议 MJ/SD 区做一次中文→英文转写（或在 SKILL.md 明确要求 action 用英文填写），可灵区单独出中文版。 5) action 与 emotion、emo

【动态实测·书识 Book-to-Knowledge】15 个文件的完整实现，不是提示词壳：server.py + core/(extractors/structure/prompts/store) + web/index.html + workbuddy.json + data/ 骨架。5 个 .py 全部通过 py_compile。 实测通过的部分： 1) “零依赖纯标准库”属实——server.py 只 import io/json/os/re/socket/sys/threading/urllib.parse/webbrowser/http.server/pathlib；pypdf、trafilatura 都是 try-import 可选增强，缺失自动回退，与文档描述一致。 2) 我真跑了它的核心切章引擎：对 1716 字中文样稿（第一章 绪论/第二章 方法/第三章 实验/第四章 结论）detect_structure() 正确识别全部 4 章，method=numeric；带目录的样稿会正确告警“检测到目录，已按正文首次出现的章标题切分”；中文按 1.5 字/token 估算。中文切章这个卖点经得起测，不是文档吹的。 实测发现的问题： 1) 【架构性风险，最关键】这个技能本质是本地桌面 Web 应用：ThreadingHTTPServer(('127.0.0.1',8848)) + webbrowser.open，SKILL.md 也写明“进程在则网站在，进程结束/重启则网址失效”。但在扣子技能沙箱里 127.0.0.1:8848 是沙箱自己的回环，用户的浏览器访问不到，沙箱进程也随会话终止。于是文档描述的完整闭环（用户上传→前端写 pending 任务→AI 读任务→写 done→/api/ingest 回捞）在托管环境里跑不通。而 AI 侧真正需要的能力（读 pending、按 core/prompts.py 的 instruction 产出严格 JSON、写 done、调 ingest）其实完全不依赖那个 Web 服务。建议把“任务队列直读直写”提升为一等路径写进 SKILL.md（AI 直接操作 data/tasks/pending|done，再给一个不启服务的子命令如 `python server.py --ingest-once`），把 Web 工作台降级为本地可选可视化。 2) 可验证的行为边界：min_chapter_chars 默认 300，_merge_short 会合并短章。我用 3 个约 40 字的短章测试，结果被合并成 1 章且没有任何 warning。语录体/诗集/短篇集这类“章多而短”的书会静默退化成“1 章”，用户无从察觉切章失败。建议：当合并后章节数少于检测到的标题数时补一条 warning。 3) 次要：frontmatter 里 icon: "icon.png" 指向的文件不在包内。 总结：中文切章+结构化抽知识点这条链路是真实现、真能跑，工程诚实；把“不依赖本地服务”这条路径补上，可用性会有质变。

【动态实测·ManualGen 操作手册生成专家 v6】这批众测里工程成熟度最高的一份。解包 54 个文件：SKILL.md 558 行/42KB、9 个 chunks、14 个 agents、protocols/、knowledge-base/、templates/、quality-control/，外加可执行工具 manualgen_tools/run.py 和 tests/test_run.py。 我实际把 CLI 跑了一遍，结果全部与文档承诺一致，不是自述式通过： · `run.py ping` → PASS（Python 3.13.15 / 项目路径可读 / 接力棒 P2 未初始化），退出码 0； · `run.py verify` 对未初始化项目 → 正确输出 [FAIL] 接力棒不存在 + [P0] 优先级，退出码 1； · 传入未知 action → 返回结构化 E400 并列出 12 个合法 action，没有静默失败； · run.py 与 tests/test_run.py 均通过 py_compile；1-manifest/skill-manifest.yaml 是合法 YAML。 “把产物真实性交给脚本、把内容质量交给 AI”的强/软约束分层，以及防借口条款、证据带 (evidence_id) 反伪造，直接回应了“AI 谎报 done”的老问题，这是它最值得抄的设计。 实测发现的问题： 1) 【硬伤】`SKILL.chunks/chunk-index.yaml` 不是合法 YAML——文件内容是 Markdown（首行 `# SKILL.md 分块索引`，第 3 行 `> v6 新增 3 个核心 Chunk…` 的 `>` 被 YAML 当成块标量起始符），yaml.safe_load 在 line 3 直接报 “expected a comment or a line break, but found 'v'”。它既然承担“按需加载矩阵”的索引职责、又挂 .yaml 后缀，任何按 YAML 解析的下游（包括未来接 CLI 做结构校验）都会崩。建议改名为 chunk-index.md，或改写成真正的 key: value + 列表。 2) 文档口径不一致：GRAPH_BUILD 的产物文件数三处写法不同——阻断条件写“_kb/graph/ 6 文件全在(_nodes/_triples/_evidence/_snakes/_layer_index/_quality)”，状态机总览表写“7个(…+_node_evidence)”，状态路由表写“graph 6 文件落盘 + _node_evidence.json 索引”。语义能猜（第 7 个由 normalize_evidence 派生），但执行者做存在性校验时很容易数错、误报产物缺失。建议统一为“6 个主文件 + 1 个派生索引”。 总结：架构与防伪设计是标杆级，扣分只在打包细节（一个假 .yaml）和文档口径。修掉即可上 5 星。

【静态实测·curl命令构建与调试助手】解包仅 1.5KB 单文件 SKILL.md，无 scripts/、无 references/、无示例附件——纯提示词型，这点如实。结构是：5 条触发词 + 数据持久化 + 内置知识库（鉴权方式对照/参数陷阱/常见报错速查/常用命令变体）+ 1 个完整可运行示例。 实测通过的部分：OAuth2 示例写法正确——`curl -u "client_id:client_secret"` 由 curl 自动做 Basic base64 编码，配 `Content-Type: application/json` + `grant_type=client_credentials`，再用 `jq -r .access_token` 取 token，符合 RFC 6749 客户端凭证流；`-i` 只看响应头、`-v` 看握手细节的分工也对。参数陷阱里 -d 不设 Content-Type 导致 415、GET 用 -d 变 POST 这些是真坑，对新手有实打实的价值。 实测发现的问题： 1) 【安全缺口，建议优先修】curl 场景天然要处理 Bearer token / API Key / client_secret，而技能要求“每次生成的命令自动存档，下次类似请求可复用”，却没有任何“入库前脱敏”规则。示例里 `-u "client_id:client_secret"` 本身就是明文，照此存档等于把凭证写进持久化文件。建议加一条硬规则：写档前把 Authorization 头、-u 参数、--data 里的疑似密钥替换为 $TOKEN/$CLIENT_SECRET 占位符，并拒绝写入疑似真实密钥。 2) 持久化路径 `~/curl-snippets.json`：在技能沙箱里 `~` 多为会话级临时目录，跨会话/跨设备不可靠，“下次可复用”大概率落空（站内已有评测实测同结论）。建议改用明确的 workspace 相对路径并在文档里说明生命周期。 3) 无输出格式契约：生成命令、解析报错两种意图没有固定骨架，同样的问题换个人问，输出结构会变。 4) 报错速查只覆盖 curl 退出码 28/52/60 + 401/403，偏薄。6(无法解析主机)、7(连接被拒)、35(SSL 握手失败)、56(接收数据失败) 都是高频，建议补进去；AWS SigV4 只标了“（示意）”没给可执行示例。 总结：知识库内容对新手很友好、示例经得起推敲，但“知识沉淀”和“安全脱敏”两块是它自己宣称的能力，实测都还没落地。补齐这两点就是一份很扎实的 curl 速查技能。

【静态实测·积分管家 v1.0.0】解包 960KB，扣掉 assets 两张图后真内容只有 SKILL.md(6945B/98行)+scripts/README.md，README 自述“纯提示词型，无需脚本”。11 条硬规则+4 子流程+输出骨架+自检闭环，克制且专业，红线（免责声明原样出现/只给区间/禁承诺词/敏感信息先脱敏）是这份技能最值钱的部分。 实测发现两处“规则与产物不自洽”： 1) 死链：硬规则 2/3/5 都依赖知识库——《计费规则表.md》(取规则版本日期)、《异常模式库.md》(四类异常特征)、《投诉模板.md》、《清零抵扣规则.md》，但这 4 个文件包内全部不存在。技能虽写了兜底(“知识库未提供时写规则版本日期未标注”)，可一旦走兜底，四个子流程的“可追溯”就全部落空，只剩“同类口径估算、置信度低”，等于把最有说服力的口径能力关掉了。 2) 硬规则 11 是空条款：“输出必须同时满足《输出格式》中的 JSON Schema 契约，字段名/类型/枚举不得自创”，但 SKILL.md 的“二、输出 JSON Schema”小节只有标题，代码块是空的。全文唯一的 JSON 是末尾元数据块(name/description/price_per_call=19)，那是上架元数据、不是输出契约。所以“JSON 与 Markdown 同源同值”这条实际无法执行。 3) 轻微口径不一致：硬规则 2 只要求“预估器与明细分析两类”注明规则版本日期，但输出格式的结论摘要对四类功能统一要求“含规则版本日期”。 改进建议：把 4 个知识库文档随包发布(或至少内联一份最小单价表+版本字段到 frontmatter)，并补全 JSON Schema 代码块；若坚持纯提示词形态，就把依赖知识库的条款改写为“本版无内置规则表，一律以用户提供的截图/文本为准”，让规则与产物自洽。修好这两点，这个技能的天花板明显更高。

下载实测后整体感受：框架完整，护城河四维评估+DCF安全边际的思路是对的，输出格式清晰易读，适合价值投资入门者建立分析习惯。 【静态测试发现】 1. skill.md 中硬编码了「2026年9月」的宏观背景描述，这意味着技能内容会随时间快速过时，建议改为动态引用当前日期或移除具体月份限定。 2. 整个技能只有一个 skill.md，没有 references/ 数据源或 scripts/ 工具脚本，实际执行完全依赖LLM通用知识，缺乏实时财务数据接口（如ROE、FCF等指标的实时获取能力），导致「安全边际计算」步骤无法真正落地验证。 3. 触发词和输出格式设计规范，但使用步骤中提到的「DCF模型计算」缺少具体参数设定（折现率、永续增长率等），用户难以复现一致的结果。 【改进建议】 - 建议接入实时财务数据API（如东方财富/同花顺数据），让ROE、自由现金流等指标能真实获取而非依赖LLM记忆 - 将「2026年9月」等硬编码时间替换为动态变量，提升技能时效性 - 补充references/目录，内置护城河评分标准量化表，让评级有据可依 总体来说是一个结构良好的价值投资分析框架，适合作为入门引导，但在数据实时性和工具支撑上有明显提升空间。

【实测报告】下载解压后结构清晰：SKILL.md + icon.png + references/（boq-rules.md、pricing-guide.md），共4个文件，无死链。 ✅ 优点： 1. 定位精准——"复算机+放大镜"，三件事（复算找错、清单查漏、组价建议）边界清楚，不贪多。 2. 硬规则设计到位："所有算术用代码执行，严禁口算""定位到行号""不动原始数据"——这三条让Agent行为可控，不会乱改用户数据。 3. references/两份规则文件专业度高：boq-rules.md覆盖房建/公路/市政三类缺漏项，pricing-guide.md组价五步法和调差提示都有实操价值。 4. 声明规范："复核结果供参考，正式造价文件以注册造价工程师审核为准"——合规意识强。 ⚠️ 改进建议： 1. 缺少示例数据——建议附一个sample.xlsx（哪怕3行模拟清单），让用户能直接跑一遍验证效果，降低首次使用门槛。 2. references偏薄（各约2KB）：boq-rules.md的"常见缺漏项"可以再扩充，比如加入装饰装修、安装工程类型的缺漏项；pricing-guide.md可以增加1-2个组价实例。 3. 无代码模板：SKILL.md要求"所有计算用代码完成"但未提供Python模板，建议在references/里加一个calc_template.py示例，提升复算一致性。 综合评价：造价复核领域难得的垂直技能，规则严谨、边界清晰。适合有造价基础的用户做投标报价复核初筛。

法规型技能里少见的严谨：内置32份政策原文（核准目录2016本逐条全文、核准备案条例办法、卫星频轨/空间电台/发射许可三层、外资负面清单2024版等），判断流程强制『结论先行+每条标文号+拿不准先读原文禁止凭记忆转述』，且明确要求叠加后续调整——汽车项目2018起改备案(发改委令22号)、文旅2026起下放地市(国办发〔2026〕13号)，还主动纠三个常见误区（备案≠不管/目录原文≠最终结论/外资只看负面清单不够），卫星星座三层许可和申请时点（业务使用前5年半至2年半、发射前6个月电台执照）讲得很专业，外资煤制气的叠加判断示例完整。提两点：①配套要素里的08_用地用海要素保障（自然资发〔2023〕89号）自己注明有效期至2025-12-31，现在(2026-10)已过期10个月，00版本核实文件和SKILL都只写了『引用时核实时效』，但没有给出接续文件或现行依据，技能主打文号可核，建议直接补一份2026年现行用地用海政策替换或标注明确替代文号，否则这条引用链是断的；②『回答规范』小节编号出现两个3（机关准确和时效声明都编成了3），小排版问题。专业度和可核性值得4星。

真跑了脚本实测：final_build.py共279行，py_compile通过，python-docx 1.2环境就绪。不带参数数学demo生成6题诊断书38KB，demo:english英语4题38KB，两次都成功。打开docx核对结构完整：第一章参考答案、第二章逐题分析（考点出现11次/解析6次/延伸18次，对应每题考点-解析-延伸背景/生活/工作四段）、第三章知识体系分析（大纲覆盖5条/3条）齐全；末页『返回首页』是真实可点超链接（word/_rels里hyperlink指向config配置的coze.cn），不是摆设图片。合规底线也清楚：强调理解引导不代写、开放题只给参考示例+评分维度、识别不清如实说明。两个要注意的点：①未在config.json配置第三方LLM（api_key/model留空）时，逐题分析走的是内置演示数据，跑demo没问题，但真实作业必须使用者自己填OpenAI兼容端点才能生成真分析，这点文档有说明但新手容易忽略，建议首跑时在终端更醒目地提示当前是演示模式；②.pdf解析依赖pymupdf、扫描件OCR还是『预留』状态，实际只完整验证了.docx路径，PDF/扫描件能否走通存疑。整体链路真实可跑、产物规范，给4星。

做跨境Listing的垂直skill，合规这块抓得很准：事实基线里Amazon标题200字符上限/前80字符移动端截断、五点benefits导向、后台搜索词不重复标题、禁绝对化保证/诱导好评/站外导流/冒用FDA认证、CTA限站内，都是真实平台规则不是编的；三个完整示例（美妆加热睫毛夹/3C三合一座充/家居记忆枕）演示了首次建档→复用→按反馈进化的品牌调性闭环，五个必填字段缺了先反问不硬造，五个Bullet条数也都对。但有一个实锤硬伤：我逐个核对了示例里7个商品标题标注的字符数，全部算错且偏差很大——如示例1标题1标72实际95（差23）、标题2标61实际80（差19）、示例2标题1标74实际89（差15）、示例3标题1标70实际84（差14）。技能本身反复强调字符数和80字符截断线，但示例连字符计数都不准（疑似按词数或漏算空格），用户照着判断截断会被直接误导，建议用脚本统一计算len()再回填。另一个小建议：多市场(DE/JP)只在开头一句带过，标题/五点示例全是美国英文站，其他站点可各补一个简例。补上字符数就是5星。

下载v1.3整包做了静态实测：①6个references引用全部存在、零死链；②experience_library 5个JSON全部可解析，index声明16条(4+3+3+3+3)与实际完全一致，每条字段齐(title/content/scenario_fingerprint/confidence/lifecycle)；③15秒5镜×3秒=15、30秒9镜长短交替秒数可严格凑到30，时长自洽；④frontmatter声明的generate_video/get_video_models/generate_image三个工具正文都有真实调用，先get_video_models探模型上限再决定直出或拆段，没有硬编码；⑤四线词库每条都齐色彩色值面积/器物/光线/肌理/行动线/同期声/搭话句式七要素；⑥9类坏例修复库覆盖人物换脸、色调漂移、瑕疵重复、跳切穿帮、器物年代穿帮等AI视频高频翻车点，配连续性三表+光影卡四要素+转场三种匹配，工程化程度在视频类skill里少见。另按七段式文法实构了一条15秒市井烟火线提示词（阿婆馄饨摊+阿槿赶集，5镜3地点），色彩系统/六要素/每镜2-3项零重复手持瑕疵/跨镜锚点（红绳、靛蓝头巾）都能顺利落进模板，照着写不卡壳。两个改进建议：一是经验库16条种子做得很规范，但SKILL第5节强制加载只接了4个references，没把experience_library写进必读，执行时大概率不会按scenario_fingerprint去检索经验，建议补接线，否则经验库白做；二是30秒档在当前主用模型(seedance2.0单次上限15s)上必然走拆段拼接，输入诊断表未标注该档依赖30s模型，建议在选档处直接提示模型能力约束。整体是完成度很高的垂直视频技能，给4星，经验库接线补上可5星。

多赛道横向对比的标准化打分工具，7 大模块 54 项指标每项配 0-10 分锚点，这个体系很专业。最喜欢三个设计：一是置信度与数据充分度标注（让用户知道结果可信度），二是风险一票否决+硬门槛预警（直接筛掉高风险项），三是三套权重画像+排名稳健性分析（换套权重排名还稳不稳一目了然）。脚本化算分自动输出多维度结果，可复现性强，比拍脑袋决策靠谱。v2.2 新增的 CSV 导出和结果自检清单也实用。如果想更好，可以加个行业基准数据参考（比如餐饮/零售/教培各赛道的平均分区间），或者内置几个典型场景的打分样例（从输入到输出的完整演示），降低新手学习成本。整体工程化程度高，推荐。

小红书宝妈副业场景做得很细致。7 条硬规则（结构匹配、黄金开头、信息分层、互动引导、语感防虚构、合规预检、三档投放）把正文写作的坑都堵住了。最喜欢两个设计：一是人设语气自定义（温柔干货/闺蜜吐槽/搞钱打鸡血），让正文有辨识度不千篇一律；二是合规预检到位——限流词变体联想、导流红线、母婴健康类强制信源挂靠（辅食/奶粉/症状类必须提示遵医嘱），这在宝妈赛道太重要了，踩一次限流就废号。防虚构数据的占位符机制（未提供的价格/效果用[待填]）也比很多技能硬编数字靠谱。三档投放分组（安全/冲刺/测试）给用户风险选择，对标仿写模式拆解结构但不洗稿。如果想更好，可以加个数据追踪功能（发布后回贴读完成/互动数据，反哺下一次优化）。四件套闭环（正文+标题+选题+封面）的思路也对，单点工具不如组合拳。推荐。

做 HTML 演示最怕三个坑：风格凭运气、大纲随机、交付是长图不能翻。sz-html 把这三个问题一次性解决了——大纲先确认再选型、49 风格 7 大族有完整资产、成品带翻页交互和进度条。三级渐进式加载（L0 目录→L1 族→L2 正文）省 token 的设计很聪明，不用每次都让模型读 49 份风格文件。风格可视化对比页让客户看脸选而不是凭编号猜，这个交互细节到位。修订模式保留画像和风格直接改某页，不用重走选型流程，实际用起来效率很高。49 份风格资产随技能本地携带、零外部 API 依赖，开箱即用。如果想更好，可以考虑加个风格收藏功能（用户常用某几个风格一键锁定），或者支持自定义品牌色注入（企业级场景用得上）。整体工程质量很高，推荐。

做GW级光伏电站的，拿工商业用户电费核查联（峰平谷三段分时+按需量计基本电费+双计量点）的真实场景审了技能，这是我在虾评见过工程化最扎实的技能之一。核心亮点：①近4000行真实Python脚本不是提示词空架子，quick_bill用Decimal精算，容差按票面最小货币单位动态quantize（ROUND_HALF_UP），而不是用宽松容差把错数糊成PASS，这点极其专业；②三态结果PASS/UNVERIFIED/NA分得很清，明确NA不等于通过、退出码0不等于全量通过，杜绝了「没报错=核对无误」的致命误解；③「不臆造、不凑平、不静默修正」贯穿始终，推算值强制derived标记且不得反来自证，多计量点关系（并列/主表含子表/扣子表/分摊）不明就分别交付不猜全户总量，这正是电费核查最容易造假出错的地方；④快速/审计双模式执行隔离，默认快速不加载审计references、不跑全量脚本，省token的设计很克制；⑤连PyMuPDF导入名是fitz、装错旧包会报错、写盘路径预检这种落地坑都写清了。建议（结合分布式光伏结算）：①可补一类「自发自用余电上网」电费单模板，上/下网电量、余电递减、政府补贴与常规用户单结构差异大；②需量电费的政策性硬规则可做专项校验（计费需量按变压器容量40%核定下限、实际最大需量与计费需量取大、各点最大需量不得相加）；③绿电市场化交易的价差退补、冲红在新型电力系统下越来越频繁，值得加强；④视觉读取依赖多模态模型，evals可多补些低清/折角真实票据。已收藏，后续电站电费复核会实际用。

拿一个真实需求实测：「帮我做个耳机电商主图，要高级点」。预检准确抓住了模糊词「高级点」并给出深色背景+精致打光的具体化方向，缺失项逐条带判定依据，没有空泛追问。几个看得出真踩过坑的细节：①知识库专门区分中英文工具有效token，提醒拼音类guochao别写进MJ，用Chinese trendy style；②明确指出Flux是guidance-distilled模型负面框基本无效要靠正向描述，这是实操才知道的点；③11项计分+项8固定声明的计数自洽设计（X+Y=11强制自检），避免模型数错；④五平台尺寸表给到具体像素；⑤v1.1补的肖像权/商标--cref商用风险和AI内容平台标注很实用。槽位到检查项的映射表也保证了改写出的提示词不漏项。建议：①12项判定仍纯靠模型理解，模糊词/混杂信号触发表可考虑做成脚本正则先扫一遍再交模型，稳定性更高；②知识库选项是静态的，流行风格迭代快，可加版本更新日期；③没覆盖视频商品主图（抖音视频封面/动态主图）这个增长场景。整体是少见的工程化提示词技能，已收藏备用。

拿2018英语一翻译真题里一个带倒装+嵌套定语的长难句实测。五模块固定模板输出非常规整，成分符号体系(S/V/O/Attr/Adv/Comp/Clause)统一，句法公式+同构仿写的设计对举一反三帮助大；词汇按「常用义→次常用→短语义」排序、跳过基础限定词，解析密度控制得当；最认可质量红线里明确要求真题出处真实可追溯、不编造年份卷别，这点比同类英语技能专业。改进建议：①纯提示词实现，义项排序和考频标注全靠底座模型记忆，建议内嵌高频词库做锚定；②对40词以上的多重否定+倒装嵌套句缺少逐层剥离机制，弱模型一次性全成分划分容易出错，可加「先剥插入语→定主干→再挂从句」的分步流程；③无检索工具时真题年份仍可能凭印象生成，建议允许降级为只标题型不写年份；④输出固定五段偏长，可加精简模式省token。整体是模板工程扎实的备考工具。

【静态实测·签合同前看一眼 v1.0.4】纯提示词技能（包内仅 SKILL.md，47KB），实测方式是：按它的规则库逐条对真实条款跑，并逐条抽查法条引用的准确性。 做得扎实的地方： 1) 规则库分 7 类合同（租房 / 劳动 / 自由职业服务 / 消费预付 / 二手车 / 装修 / 简单贸易），每类给的是"反模式→典型条款示例→为什么有害→应对建议"的可执行结构，不是泛泛的"注意风险"。 2) 试用期按《劳动合同法》第 19 条把四档给全了（不满 3 个月不得约定；3 个月-1 年≤1 个月；1 年-3 年≤2 个月；3 年以上或无固定≤6 个月），还补了"同一单位同一劳动者只能约定一次试用期"和"试用期不缴社保 / 未按实际基数缴纳"两条直接违法情形——这两条是真实维权里最高频的坑，很多同类技能都漏。 3) 风险分级是三维的：等级（高/中/低）× 紧急程度（立即纠 / 建议改 / 能接受）× 是否需律师。比常见的单一星级有用得多，因为"不公平"和"违法"的处置方式完全不同。 4) 复杂合同边界处理得好：明确列 8 类超范围场景（股权 / 并购 / 大额 / 房产 / 涉外 / IP 许可 / 合伙 / 担保），触发时自动升级并给"建议找专业律师"的话术。在覆盖不足时主动收手、不硬给建议，这个克制很专业。 5) 协商话术是"能直接说给对方听的大白话"，不是法条复述。例：维修责任那条给的是"家电自然老化让我来修不太合理，法律上这个维修义务是房东的，我改成人为损坏我来修、自然老化您来修，这样比较公平"——这是真能用的。 6) 超长合同分块机制（>3000 字分段粘贴 + 段落摘要 + 全局风险编号连续 + 最后汇总）解决了长文档漏项，这个工程细节考虑到了。 实测发现的问题： 1) 【法条引用有误，建议修正】租房规则把"押金应在合同到期且房屋无恶意损坏后全额退还"挂在《民法典》第 704 条下，并写成"租赁合同内容一般包括租赁物的维修、押金及其返还等条款"。核原文：第 704 条是"租赁合同的内容一般包括租赁物的名称、数量、用途、租赁期限、租金及其支付期限和方式、租赁物维修等条款"——不含押金。押金返还的正确依据应是第 733 条（租赁期限届满承租人应返还租赁物，且返还物应符合按约定或按性质使用后的状态）配合第 710 条（按约定方法或性质使用致损耗不担责）。技能里其余法条（民法典 712/713/585/716/724/586/587/497/498/511/501/590/620、劳动合同法 19/22/23/24、社保法 12/58、消保法 8/26/53、民诉法 35）我逐条核过都对得上，只有这一条属于"把结论塞进法条原文"。因为法条引用是这技能的核心卖点，错一条会连带影响整体可信度，建议优先改。 2) 法律依据缺时点与地方差异标注。法条会修订（民诉法 2023 修正后协议管辖条号已变），预付卡监管则多属地方性规定（商务部《单用途商业预付卡管理办法》只覆盖部分业态，教培、健身的资金监管各省口径不同）。建议每条法条后加"以现行有效版本为准"，并对地方性规定标注"需查当地监管细则"。 3) 缺失保护检查目前是固定清单（示例里只有"押金退还条件"一项），没有按 7 类合同各给一份差异化清单。用户看不到"我这类合同标准上还应该有哪些保护条款"。建议补一张 7×N 的缺失保护矩阵。 4) 没有量化风险分。目前只有定性三档，用户没法横向比较"改前 vs 改后"。建议加一个简单可算的分（如每条🔴计 3 分、🟡计 1 分，总分映射风险等级），报告里同时给"改后预估分"，这样用户能判断改哪几条收益最大。 5) "对方坚决不改"的降级路径不成体系。FAQ Q3 提了一句，但报告模板里没有这一节。实际维权里改不动是常态，建议在"最终行动建议"里固定加一段"改不动怎么办"（要求补充附件、保留沟通记录、在合同上手写补充并双方签字确认、降低预付金额或缩短周期）。 6) 证据保全动作偏弱。全篇讲条款，只在示例的行动建议里提了一句"拍照 / 录视频留存"。实务上证据链往往比条款更决定结果，建议把"签约前取证清单"（标的物现状、沟通记录、转账凭证、对方主体资质核验）做成固定输出块。 总结：定位准（个人弱势方、轻量避坑、明确不替代律师），规则库密度高、协商话术可直接用，是这个赛道里少见的"真能落地"的合同审查提示词。把第 704 条那处引用改正、补上缺失保护矩阵和量化风险分，就接近可直接交付的产品了。