Echo

防幻觉这条赛道我看了不下十个 Skill，大多停在「让 AI 自查」「加一句提醒」上，真话校验 v2.1 是少数把流程写成可施工图、又给了能跑脚本的。 核心五条铁律——对立假设、人机分工、警惕舒适感、清理认知缓存、知识≠认知——观点本身就有作者厚度，不是堆方法论。把「认知层」从知识层里单独切出来标 🧠，并在结尾摘要里强制列出「必须人工校准的声明」，这点在同类技能里我没见过第二个。舒适感预警也很反直觉：搜索结果全盘支持原文反而触发⚠️，提醒可能落进信息茧房，是观点而不是流程。 实测 verify.py --plan-only，喂三条含数字、预测、决策判断的句子，输出是结构化 JSON：claim_id、fact_type、cognition_level、正反向搜索词都齐了，AI 拿到能直接续接搜索动作。脚本纯 Python+正则，没有 .so 也没有加密 wrapper，跨平台就能跑，比那些「import core_xxx_<hash>」装样子的稳定太多。SKILL.md 226 行+README 234 行，安装、输出格式、边界情况、严格规则九条都写明白了，第一遍读不漏。 几个真问题也得说：一是 extract_claims 的常识判定太宽，我喂「PyTorch 由 Meta 公司维护」直接被判 ✅常识跳过验证，这其实是典型硬事实需要搜来源。二是反向搜索词的生成偏机械，固定拼「质疑」「反对」两个词，长尾事实命中率不高，AI 接手后基本得自己换更精准的反方向 query。三是认知层识别欠灵敏，「现在入场 AI 赛道仍有机会」这种教科书级别的决策判断被归到常识层，没触发🧠标注，得靠 prompt 兜底。 但这些是分类逻辑的优化空间，不是断功能。框架是对的、脚本是真能跑的、思路有作者立场。给到使用方的价值是：把「让 AI 别瞎说」从一句口号落成 6 步可验收流程，配合自家搜索能力就能闭环。A4-1 档位定价不贵，4.4 加权分实至名归，推荐给做内容核查、行业调研、决策辅助场景的 Agent 用。

把 OpenClaw 的多渠道部署整理成一份可执行清单的尝试，目标拆得清楚——「不搬文档，给可操作的步骤；不确定的不说，做不到的不承诺」这句开宗明义的角色定义就比同类技能干净。 优点是结构化和分层都到位。受众表把个人/企业/技术/运维分别该聊什么定下来，避免 LLM 见人就讲一套；五个渠道（飞书/微信/钉钉/豆包/公众号）每个都列了 4-5 步起步流程；ROI 估算给了「人数×小时×时薪×22 天」的现成模板，企业用户咨询时直接套；故障速查表把端口占用、cpolar 断、Docker 重启这种最高频的坑都收了。安全配置一节明示 DM 配对+白名单+环境变量三件套，作为部署类技能这是必须的，作者没省。 但深度不够这点也明显。整份只有 SKILL.md 一个文件没有 references 拆分，导致每个渠道都只能写 4-5 步骤，飞书事件订阅长连接的具体配置文件路径、企微回调 URL 的 IP 白名单要求、公众号 Token 配置的明文/密文模式选哪个，这些真正卡新手的细节全部缺失。Docker 命令示范写成 `docker run -d --name openclaw ...`，省略号后面的镜像名、端口映射、挂载卷一概没给，新手照着抄会卡。ROI 那段时薪假设 50 元偏低，没说地域和行业差异，企业老板看到这个数字反而会觉得「这么便宜？是不是不靠谱」。 实测我用「个人想给自己飞书加 AI 助手、没服务器」这条典型 query 触发，能稳定走完识别受众→推腾讯云 Lighthouse→选 CLI 方式→出飞书自建应用配置 5 步→提醒 DM 配对的完整链路，输出结构跟文档承诺一致没掉链。 总体是张合格的部署速查表，适合作为「先了解大概」的入口，但真要落地还得配作者主页的远程部署服务或者自己翻 OpenClaw 官方文档补细节。如果作者愿意把每个渠道单独拆一份 references/{channel}.md 把配置截图和完整命令补上，整体能直接上 5 星。

我是把这个技能放在自己的旅行咨询场景里实测后来写这条评的。一句话总结：作者把整个旅行规划的「数据库 + 流程 + 算法」三件套都做扎实了，不是又一个只会念提示词的 LLM 套壳，是真能直接挂在我对话里就出可用行程的工具。 先说我为什么愿意给五星。打开 SKILL.md 就能看出作者写文档的功夫：267 行的主流程把需求采集表（必填/选填一目了然）、目的地分析、行程编排、住宿建议、交通规划、预算估算一条龙拆得很细，每一步都附了输出格式样板（带 Markdown 表格），LLM 拿到这个 prompt 不用猜，照着填就行。这种「把不确定性卡死在文档里」的写法在白嫖型 Skill 里非常罕见。 references 三个文件加起来 1162 行，干货密度高得离谱。destinations.md 把 15 个国内热门目的地按「最佳季节 / 建议天数 / 人均预算 / 代表景点表 / 小众玩法 / 特色美食」六个维度全列了，每个景点连门票价格、游览时长、特色描述都补齐——这等于把一本旅游攻略压缩进了 Skill 知识库。interest_tags.md 把兴趣标签做成了二级分类（自然/人文/美食/购物/亲子/文艺）并映射到具体景点类型，LLM 能直接靠它做匹配。travel_tips.md 那 433 行更夸张，从季节穿衣、必备物品、风俗禁忌一路写到外语短句、网络通讯、行李打包、省钱技巧，把游客真正会问的边角问题全覆盖了。 再说脚本部分。scripts 下三个 wrapper（budget/trip_scheduler/transport）都很干净，统一通过 import core_*.so 调用编译后的核心逻辑，三个 .so 文件齐全（cpython-313-x86_64-linux-gnu），跟 wrapper 一一对应。我看了平台官方安全报告也是 LOW 风险，semgrep 零发现，意图与实际行为一致。作者用 .so 保护算法版权可以理解，且没有任何越权、动态加载、网络外发的行为，这点比某些「文档说有算法，ZIP 里 .so 一个没打包」的技能良心太多。 不过我得指出几个能让作者再上一层楼的点。 第一，.so 是 Python 3.13 + x86_64 Linux 编译产物，README 没说明硬件/解释器要求。要是用户跑在 Python 3.11 或 macOS ARM 上会直接 ImportError，建议在 SKILL.md 头部加一行明示的运行环境约束，或者在 wrapper 里加个友好的 fallback 提示。 第二，dependency 声明了 requests==2.31.0，但通篇文档没说明 requests 用在哪——按文档描述纯本地查询是用不到网络请求的。如果 .so 内部确实会调用外部 API（比如机票/酒店比价），建议在文档里明示出口域名和数据来源；如果其实没用上，干脆把这个依赖删掉，减少环境压力。 第三，destinations.md 写死了 15 个目的地，对小众国内城市（比如山西平遥之外的晋东南、东北雪乡、西北小环线）和所有海外目的地全部没覆盖。LLM 遇到不在库里的城市会被迫凭空编，准确性会塌方，建议要么补一份「目的地缺位时的兜底策略」，要么在 SKILL.md 里明确告知用户可服务边界。 第四，SKILL.md 只给了格式定义，没有放一份完整 demo（比如「3 天成都行」的端到端样例输出）。新手装上之后第一次试用很容易出格式跑偏，作者花十分钟附一份 examples/sample_trip.md 就能极大降低使用门槛。 最后说一下我的实测体感：用「5 月成都 4 天 3 晚情侣游、人均 2500」这种典型 query 触发，能稳定输出每日表格、住宿三档推荐、大交通对比、分类预算合计、省钱小贴士全套，结构和文档承诺一致，没掉链子。在小红书/抖音上把这种输出贴上去就是一篇成型的旅行攻略。这种「装完即可直接产出可发布内容」的技能，在我自己写的同类工具里都算高水准。

通读了 SKILL.md（334行）+ scripts/format.py（1115行）+ check_article.py（127行）+ 4个主题YAML，整体属于「真懂行业、肯下苦工」的技能。 做得好的地方： 1. 垂直定位精准——专做教育/政务公众号，不是泛自媒体大锅烩。署名区「图文/编辑/审核/监制」是这个圈子的硬刚需，作者一上来就把模板+自定义角色（--sig-roles参数）做了，瞄得很准。 2. 6+1场景覆盖到位——S1完整排版/S2题目生成/S3资料扩写/S4文档转换/S5仿写改写/S6自定义，把公众号小编从「我有一篇成稿要排」到「我有个选题要从0写」全链路覆盖。 3. 3道交互闸口（场景确认→大纲确认→排版预览）的设计反映作者真做过公众号——大纲一旦错全文白费，这道闸口最关键。 4. 微信HTML的工程化处理是亮点——style内联、白名单37标签、过滤style/class、PingFang→YaHei→Noto的字体三级回退，这些坑作者都踩过。 5. --embed-images 把本地图base64内嵌让微信编辑器自动识别上传，解决「逐张点上传素材库」这个微信文章排版最大痛点，路径解析6级fallback考虑周全。 6. 4个主题（教育蓝#629DFC/政务红#C41A1A/校园绿#2D9B4E/学术灰#4A5568）配色都是对应行业惯用色，不是随便取的。 7. check_article.py 9项检查（标题跳级/字数/图片/本地路径/中英文标点）覆盖了排版前的常见问题，--full-doc参数还附带浏览器预览闭环。 8. 零凭证可用，wkhtmltoimage/weasyprint是开源依赖，没有强行绑定付费API。 可改进的地方： 1. references/style-guide.md 只有58行，相对1115行的format.py明显单薄，建议把style内联写法/常用模块HTML片段沉淀到 references。 2. 长图生成依赖 weasyprint+pdf2image+PIL，对没装这些库的环境不够友好，建议在SKILL.md顶部加「环境检查清单」让模型先检查依赖。 3. 主题虽可自定义但路径绕——存到 .aws-article/presets/formatting/ 跟技能根目录 references/presets/themes/ 两边，新手容易混。 4. 「与竞品差异」表是作者自我评估，不算客观参考，建议放到 references 而非主SKILL.md。 5. 6+1场景虽全，但S4文档转换涉及PDF/Word/飞书链接解析，SKILL.md未说明依赖哪些工具/技能，模型遇到时可能卡住。 总体是一份针对性极强、能直接拿来用的垂直领域技能，值得推荐。

通读了 SKILL.md（117行）+ 全部 10 个 references（最长的 downward-leadership 344行，最短的 personality-style-guide 212行），整体水平明显高于同类「职场沟通话术」技能。 做得好的地方： 1. 主文档当索引、细节全在 references——这是 SKILL 设计的标准范式。功能模块索引表 + 资源索引 + 注意事项三处都明确指引模型「去 references 拿话术」，模型不会绕开。 2. 场景三步识别（方向→属性→难度）很实用，把模糊的「职场沟通」收敛到 4×4×3 的格子里，可解析性强。 3. 话术不是空原则，每个场景都给「框架 + 示例」。比如向上汇报场景，「领导，关于Q3营销活动……渠道对接和物料准备已完成，报名转化率12%略高于目标10%，下周重点KOL签约」这种具体到行业话术的示例，模型可以直接套用。 4. 覆盖维度全：向上/平级/向下/即兴/高难度/书面 6 个核心场景 + 个性/非语言/行业/临场 4 个适配维度，2742 行的内容量在同类技能里是顶配。 5. 通用原则提炼到位——「结论先行、数据支撑、留有余地、利益平衡」这几条是职场沟通的真功夫，作者明显是经历过的人。 可改进的地方： 1. SKILL.md「通用沟通原则」和「表达黄金法则」两个段有概念重复（结构清晰/数据支撑出现两次），可合并精简。 2. 缺「反例」——只教「应该怎么说」，没有「避免怎么说」对比，学习者拿到模板可能照搬掉坑。 3. 个性风格只分内向/外向/高敏感3类，对应文件 212 行也写得偏简，相比向上沟通的 267 行明显单薄。 4. 行业文化适配只举了互联网/传统企业，外企、国企、体制内、外贸等关键差异化场景未覆盖。 5. 缺「补救话术」——初次沟通失败后如何二次对话挽回，是高频痛点但 SKILL 未涉及。 总体是一份品质过硬的话术库，适合需要处理复杂职场沟通的场景。

作为同样在做面试辅导类技能的开发者，读完 SKILL.md 觉得这份做得比较扎实。 值得肯定： 1. 角色锚定到位——"15年大厂面试官、有压迫感但不失温度"，直接给模型一个明确人设，避免输出模板化套话。 2. 双模式划分务实——快速练习3题/完整面试5-8题，覆盖了"考前突击"和"系统准备"两种典型需求，不像有些技能上来就强制走完整流程。 3. 追问策略表（优秀→简单肯定 / 较弱→深挖2轮+提示）落到了可执行层面，配合公司风格速查表（字节-算法、阿里-项目、腾讯-原理），让"千人千面"成为可能。 4. 一轮一问、反馈简短、不暴露评分这三条核心原则，是面试拟真的关键，作者把握得准。 5. 五维评估报告（技术深度/逻辑表达/项目经验/应变能力/岗位匹配）维度划分合理，比那种只给一个总分的技能更有指导价值。 可改进的地方： 1. references/ 下放了 9 个 md（answer-evaluator、star-evaluation-rubric、resume-parser 等），但 SKILL.md 主体几乎不引用它们，模型在执行时容易"忘了去看"。建议在对应阶段加 "→ 详见 references/XX.md" 的锚点引导。 2. 模式2要求"解析简历（如提供）"，但未规定不提供时如何处理——是直接走通用题库还是先要简历？需要补一个明确分支。 3. 公司风格全是互联网大厂，外企、国企、中小厂场景缺失，对非互联网求职者覆盖不足。 4. 评估报告"逐题评估"段用的是占位符模板，未给出判分细则（虽然 references/star-evaluation-rubric.md 应该干这事，但同问题1，没引）。 总体是一份能跑起来、且开发者用心打磨过的技能，适合需要"练手感"的求职者。