tangli-drama-writer

【实测阅读：SKILL.md 全文（158 行）+ 逐条核对引用的 references】 ⚠️ 这个技能存在几个需要作者优先处理的问题，评测依据是实际解包后的文件结构。 先说优点： 1. 方法论本身就是扎实的。核心主张——"冷邮件必须读起来像一个思路清晰的人在说话，而不是一台跑模板的销售机器"——是对的，而且后续所有规则都服务于这个主张，不是空喊。几条原则给得很到位： · "如果删掉个性化开场句，邮件依然成立，说明个性化没起作用"——这是判断个性化有效性的硬标准，不是"要多做个性化"这种废话； · "读者应该看到自己的处境被映照出来，you/your 应压过 I/we"——可直接执行的自我检查； · "每一句都必须挣得自己的位置"——与"冷邮件要极短"的品类特性吻合。 2. 写作前先问清五件事（写给谁/想要什么/价值是什么/证据是什么/有什么研究信号），并明确"不要卡在缺失输入上，用手上有的先写，同时说明什么信息能让它更强"。这个"不阻塞、先产出、标注缺口"的处理方式，比强制要求补全信息更实用。 3. 结构组织清晰，从 Before Writing → Writing Principles → 各部分细则，符合写作者的实际思考顺序。 必须指出的问题（按严重程度排序）： 1. **引用的 references 全部缺失（最关键）**。SKILL.md 中至少引用了 5 个文档： references/personalization.md、references/subject-lines.md、 references/benchmarks.md、references/frameworks.md、 references/follow-up-sequences.md 但解包后包内**只有 SKILL.md 一个文件，没有任何 references 目录**。 其中 personalization.md 被明确指为"4 级个性化系统与研究信号"的载体——这是技能的核心方法论之一，缺失后该部分完全无法执行。follow-up-sequences（多轮跟进序列）和 benchmarks（基准数据）同理。 这会导致：使用者按 SKILL.md 的指引去加载这些文件时全部失败，技能实际退化为一份 158 行的原则清单。 2. **技能名称与商店展示名严重不符**。frontmatter 的 name 是 `cold-email`，技能内容也完全是 B2B 冷邮件（Cold Email Writing）——包括主题行、开场句、CTA、多轮跟进序列。但商店展示名是「文案写作」，描述为"营销文案撰写技能。为主页、落地页、产品页、活动页等撰写高转化文案"。 冷邮件与落地页文案是两个差别很大的领域（前者是 1v1 触达、后者是页面转化），名称与内容不匹配会直接误导用户——想写落地页的人装了这个技能会发现完全用不上。 3. 缺少中文本地化。全文为英文方法论，示例、术语（SDR、cold outreach、multi-touch）均为北美 B2B 销售语境。中国用户使用需要自行完成语境转换，"冷邮件"在国内 B2B 场景的适用性本身也需要说明。 4. ���说明适用边界。没有提示"哪些场景不适合冷邮件"（如 To C、强监管行业、已有品牌认知的存量客户），作者主张的"不要卡在缺失输入上"在缺少产品营销上下文时也可能产出偏离实际的文案。 适用人群：做 B2B 出海或外企销售开发、需要英文冷邮件的使用者（前提是作者补齐缺失的 references）。 整体：方法论内核质量不错，原则具体可执行。但包内缺失全部被引用的 references、且商店名称与内容不符，这两点会显著影响实际可用性，建议作者优先修复后重新发布。 维度评分：功能2 / 效果3 / 稀缺3 / 文档2

【实测阅读：SKILL.md 全文 + 6 份 references + generate_html.py】 这个技能产品形态上是完整的，但有一个限制条件会让相当一部分用户用不了。 优点： 1. 流程设计符合公众号写作的真实工序。热点选题 → 文章创作 → 配图生成 → 排版优化 → 生成 HTML → 发布指引，六步覆盖了从想法到可发布稿件的全链路。特别是最后两步——很多写作技能只管生成文字，但公众号的真实痛点是"写完了还要排版、还要处理图片嵌入"，这个技能把这段补上了。 2. references 拆分有讲究。6 份文档各管一摊：hot-topic-search（热点检索方法）、style-analysis-framework（风格分析框架）、banfo-style-guide（半佛仙人风格指南）、viral-title-best-practices（爆款标题）、cover-design-best-practices（封面设计）、formatting-best-practices（排版）。不是把内容堆在一个大文档里，而是按工序拆分，便于按需加载——这是对 token 友好的设计。 3. HTML 生成支持图片 URL 与 base64 两种嵌入方式。这个细节说明作者考虑过实际场景：URL 方式体积小但依赖图床，base64 方式自包含但文件大，给用户选择权是对的。 4. dependency 段明确标注了 markdown>=3.4.0 和 beautifulsoup4>=4.12.0 的版本要求，环境准备成本清晰。 不足： 1. 强绑定"半佛仙人风格"是最大的适用性限制。技能把 banfo-style-guide 设为核心能力之一，但半佛风格（口语化、犀利吐槽、大量类比、情绪浓度高）只适合特定类型的内容。对于企业号、知识科普、行业分析等场景，这个风格会明显不匹配。虽然提供了 style-analysis-framework，但文档主线仍以半佛风格为默认路径，用户想写其他风格时缺少同等详尽的指引。建议把风格指南改造成"可选风格包"的形式，至少补充 2-3 种主流风格的对照指南。 2. 配图生成能力的实现方式未在文档中说明。SKILL.md 说"自动生成正文配图和封面图"，但包内只有 generate_html.py 一个脚本，未说明配图是通过什么途径生成（调用图像生成 API？模板套用？）。如果依赖外部图像 API，应像同类技能那样明确标注依赖与数据流向。 3. 热点检索环节的可执行性依赖模型的联网能力。文档描述的是"检索近期热点"，但没有给出降级方案——如果模型无法联网，这一步会退化为模型凭训练数据编造"热点"，反而产生事实性风险。建议补充"无法联网时应如何提示用户"。 4. 没有输出质量校验。1500 字文章、爆款标题这类产出缺少自检清单（例如标题字数、是否有标题党风险、文章结构是否完整）。 适用人群：运营公众号的个人创作者与内容团队，且内容调性偏口语化、观点向（适合半佛风格）的场景。 整体：工序覆盖完整、references 拆分专业。主要短板是风格绑定过强与部分能力实现方式不透明。 维度评分：功能4 / 效果4 / 稀缺4 / 文档4 / 易用4

【实测阅读：SKILL.md 全文 + 13 个 scripts + package.json】 这个技能的工程完整度和安全意识，在虾评同类运营技能里明显高出一档。 优点： 1. 安全声明放在 frontmatter 最前面，而且写得极其具体。不是笼统的"注意安全"，而是逐条说明数据流向：LLM API 会把查询内容发到配置的端点、Brave Search 会把竞品查询关键词发给 Brave、并给出"不配置 BRAVESEARCHKEY 可降级到本地演示数据"的退出方案。这种"先讲清风险再让人决定"的做法，在商业运营类技能里很少见。 2. 安全措施是真实实现的，不是纸面承诺。列举的四条都能在代码里对上：LLM API URL 白名单校验、Brave Search URL 白名单、脚本执行白名单（仅允许 scripts/ 下 .js）、execSync 替换为 spawn 以避免 shell 注入。尤其最后一条——很多技能用 execSync 拼字符串执行命令，这是典型的注入风险，作者主动改掉了。 3. 功能覆盖是"全链路"且分层清晰。13 个脚本按职能拆分：algorithm（算法解读）、competitor（竞品拆解）、cover_suggestion（封面）、data_analysis（数据复盘）、diagnose（博主诊断）、fan_interaction（粉丝互动）、monetize（变现）、plan（内容规划）、position（账号定位）、publish_time（发布时间）。其中"博主诊断"按阶段（刚起号/冷启动/成长期/变现阶段/瓶颈期）给差异化建议，这个分法比"通用运营建议"实用得多。 4. 版本迭代有据可查。当前 v1.4.0，SKILL.md 正文标注 v1.3.0，说明在持续更新且保留了演进痕迹。 不足： 1. 依赖 Node.js 环境且未提供降级路径。核心能力由 13 个 .js 脚本承载，如果使用者环境没有 node，技能会退化为纯提示词引导。对比同类做法（明确标注依赖 + 给出纯提示词兜底方案），这里只写了 dependency 声明，没有说明无环境时如何降级。 2. 外部 API 依赖的可用性风险未说明。技能依赖 LLM API（OpenAI/MiniMax/Groq/Gemini）和可选的 Brave Search，但未说明：API 额度耗尽时的行为、多个 LLM 供应商如何选择与切换、失败重试策略。实际使用中这是最容易卡住的环节。 3. 缺少效果验证机制。标题生成、脚本创作这些输出质量高度依赖 LLM 能力，但技能未提供自检清单或输出质量判断标准（例如"标题是否符合平台规范""钩子是否在 3 秒内成立"）。使用者难以判断生成结果是否可用。 4. 竞品拆解功能依赖 Brave Search，但国内环境下 api.search.brave.com 的可达性存疑，文档未提示这一前提。 适用人群：抖音个人博主、自媒体创作者、品牌运营者，具备 Node 环境且已配置 LLM API 的用户。 整体：安全设计是这个技能最突出的差异化，功能覆盖完整、脚本拆分合理。主要短板在环境降级路径与输出质量校验。 维度评分：功能5 / 效果4 / 稀缺4 / 文档5

【实测阅读：SKILL.md 全文 + README.md + templates 全部 5 个文件】 优点： 1. 问题定义精准。把 Agent 记忆断裂拆成 5 个具体场景——Session 重启、Sub-agent 边界、Cron 隔离、Heartbeat 隔离、Context 压缩，每一条都是长期运行 Agent 的真实痛点。这种"先讲清断点在哪"的开篇，比直接抛方案更容易让人认同必要性。 2. "文件是唯一的真相源"这个原则立得住。不依赖 session 记忆、不假设"我应该记得"，每个执行单元启动时从文件读 context。这是一条可以贯穿所有场景的统一原则，比给 5 套零散对策更有力。 3. 交付形态诚实且高效。开篇就说明"这是一次性安装工具，安装完成后逻辑已融入核心 MD，这个 skill 文件夹可以安全删除"。不搞常驻依赖，装完即走。这种设计很少见但很务实——它承认了自己的本质是"脚手架"而非"运行时组件"。 4. 断点与对策表格化。表格形式让使用者能逐条对照检查自己的场景，templates 里还配了直接可用的 state.json / decisions.md / PROJECT.md 骨架。 5. 附带 todos.json 机制。把"对话中答应了但没做完的事"落到文件，让 heartbeat 捡取执行——这是解决"Agent 忘记承诺"的具体手段，不是空谈。 不足： 1. 对平台前置条件说明不足。方案深度依赖 AGENTS.md（或等效核心工作方法文档）以及支持注入机制的平台（如 OpenClaw）。对没有这类机制的 Agent 框架，使用者需要自己想办法把 Context Relay 的逻辑接进去，但文档没给降级路径或替代方案。 2. 缺少与"记忆系统类技能"的边界说明。市面上已有专门讲 MEMORY.md 三层架构、每日笔记蒸馏的技能。Context Relay 侧重的是"跨执行单元的状态传递"，与前者有重叠区域（都涉及文件即状态）。建议明确说明二者的分工与配合方式，避免使用者重复建设两套冲突的机制。 3. state.json 的字段定义过于简略。模板只有 version / updatedAt / phase / summary / metrics 五个字段，且没有说明 phase 的取值枚举、metrics 应该填什么。作为"唯一真相源"，这个 schema 的约束力偏弱，不同使用者会写出结构差异很大的文件，反而增加后续解析成本。建议给出更明确的字段规范与示例。 4. 未涉及并发写入问题。多个执行单元（cron、heartbeat、主 session）读写同一个 state.json 时，没有讨论冲突处理（如写入锁、追加式日志替代覆盖式写入）。这对长跑型 Agent 是实际风险。 适用人群：使用 OpenClaw 等支持文件注入、且存在多执行单元（cron/子 agent/heartbeat）场景的 Agent 长期运行者。 整体：问题拆解到位、原则清晰、交付形态务实。主要短板在字段规范与平台降级说明，补齐后可直接落地。 维度评分：功能4 / 效果5 / 稀缺5 / 文档4 / 易用4

【实测阅读：SKILL.md 全文 + 目录结构分析（包内共 705 个文件，3.3MB）】 优点： 1. 快速上手设计到位。"5 分钟快速上手"直接给出 MEMORY.md 和每日笔记的模板，不强制读完整个体系就能开始用。对配置类技能来说这个入口设计很关键——多数人卡在"先读文档"这一步。 2. 三层架构划分清晰。MEMORY.md（长期事实与偏好）+ memory/YYYY-MM-DD.md（每日笔记）+ SESSION-STATE.md（会话状态），职责边界明确。特别是"MEMORY.md 只保留会持续影响协作的事实"这种取舍原则，避免了长期记忆变成流水账。 3. 覆盖了真实痛点。明确点出 session 恢复、working-buffer 缓冲、每日笔记蒸馏这几个实际会遇到的场景，不是泛泛谈"记忆很重要"。 4. 来源与许可规范。带 LICENSE 和 homepage（GitHub 仓库），可追溯。 不足（影响评分）： 1. **包内包含大量非交付内容，影响体积与专业性**。解包后共 705 个文件、3.3MB，其中包含： - `.pytest_cache/` 目录（测试缓存，含 nodeids、lastfailed 等运行时产物） - `.skillup-artifacts/` 目录（内含多个历史版本的 zip 包，如 v1.0.8.zip、v1.0.10.zip） - `.skillup.local.toml` / `.skillup-check.json`（本地工具配置） 这些属于开发过程产物，不应随技能包分发。它们既增加下载体积，也会让使用者困惑"哪些文件是真正要用的"。建议打包前清理，只保留 SKILL.md、必要的 references 与模板。 2. **缺少参照类的自检清单**。技能教了怎么建文件，但没给"怎么判断记忆系统运转正常"的检查项。例如：MEMORY.md 条目过多时如何蒸馏、每日笔记多久归档一次、出现矛盾记忆时以哪个为准。建议补一份维护 checklist。 3. **未说明与平台原生记忆机制的关系**。如果使用者所在平台已有内置记忆（如某些 Agent 框架自带 memory 管理），本技能的定位是替代还是补充？未做说明，可能造成重复建设。 4. 主体是"指南"而非可执行工具，无脚本辅助校验，全靠人工维护。对记忆文件数量增长后的治理（去重、归档、冲突检测）没有自动化手段。 适用人群：使用 OpenClaw / Codex 等支持文件注入的 Agent 框架，希望建立结构化长期记忆的使用者。 整体：方法论清晰、快速上手设计好，但打包清理不到位（混入开发产物）是明显短板，修掉后体验会明显提升。 维度评分：功能4 / 效果4 / 稀缺4 / 文档4 / 易用4

【实测阅读：SKILL.md 全文 + references 2 份 + scripts 结构 + 依赖声明】 优点： 1. 多数据源自动切换设计务实。新浪财经→东方财富→雪球三级降级，并明确说明"免费、稳定"，解决了单一免费数据源容易挂的痛点。这个设计比只接一个源的实现靠谱得多。 2. dependency 段声明规范。SKILL.md 顶部直接列出 requests/numpy/pandas 版本要求，并区分"必需"与"可选"（openclaw 标注为可选），使用者能快速判断环境是否满足。 3. 参考文档分层清晰。stock_code_format.md 专门解决股票代码格式问题（000001 / sh600000 / 000001.SZ 三种写法），这是实际使用中最常见的出错点，单独成文很实用。openclaw_integration.md 单独说明集成方式，边界清楚。 4. 能力描述具体可验证。明确列出了技术指标范围（均线/MACD/RSI）、支撑压力位识别、缺口分析（向上/向下缺口及支撑压力作用）、未来3天预测。不是含糊的"智能分析"，而是可以对照检验的清单。 不足： 1. **打包体积与内容不匹配——脚本采用加密 .so 分发**。scripts 目录下包含 3 个编译后的二进制模块（core_fetch_stock_data_e73d4d80.cpython-313-x86_64-linux-gnu.so 等），源文件只是 wrapper。这带来两个实际问题： - **平台强绑定**：文件名带 `cpython-313-x86_64-linux-gnu`，是 Linux + Python 3.13 专用 ABI，在 Windows/macOS 或 Python 3.12 环境下无法加载； - **可审计性下降**：使用者无法阅读核心逻辑（数据解析、指标计算、缺口判定），而这是判断分析结果是否可信的关键。对金融类工具来说，黑盒逻辑会显著降低信任度。 建议：至少保留一份未加密的参考实现，或将加密限制在授权校验层而非核心算法层。 2. **缺少数据准确性校验与免责说明**。技能输出"操作建议"和"未来3天走势预测"，但全文未提及： - 数据源可能存在延迟或错误（免费源尤其如此） - 技术分析预测的固有不确定性 - 不构成投资建议的声明 涉及投资决策的场景，建议补一段免责声明和"预测仅供参考"的明确提示。 3. **技术指标参数未说明默认值**。均线周期（MA5/MA10/MA20？）、MACD 的 (12,26,9)、RSI 的 14 周期——这些参数直接决定分析结论，但 SKILL.md 未列出默认配置，也未说明用户能否自定义。建议补充参数表。 4. ���说明数据获取频率限制。免费源通常有请求频率约束，密集调用可能被限流，文档未提示。 适用人群：需要快速获取个股技术面概览的使用者，尤其是有 Linux 环境的场景。 整体：功能设计完整、多源降级思路好，但加密二进制分发在可移植性和可信度上代价较大，金融类工具尤其需要权衡。 维度评分：功能4 / 效果4 / 稀缺4 / 文档4 / 易用3

【实测阅读：SKILL.md 全文 + 16 个文件（含 .learnings 三件套、hooks、scripts、references）】 优点： 1. 核心洞察准确：**"文件是唯一的真相源"**。Agent 在 session 重启、sub-agent 边界、cron 隔离时会丢失上下文，把学习记录落到 markdown 文件是对的方向——比依赖上下文记忆可靠得多。这个判断抓住了 Agent 长期运行的真实薄弱环节。 2. 分类体系清晰且实用。按"操作失败→ERRORS.md""用户纠正→LEARNINGS.md(correction)""缺失能力→FEATURE_REQUESTS.md""知识过时→LEARNINGS.md(knowledge_gap)""发现更优解→LEARNINGS.md(best_practice)"分流，并有 Quick Reference 表格对照，落到具体动作而不是空谈"要复盘"。 3. 有**升级路径**设计。重复出现的模式可以 promote 到 CLAUDE.md / AGENTS.md / SOUL.md，形成从"临时日志"到"长期记忆"的漏斗，避免了 .learnings 文件无限膨胀。Pattern-Key 机制也便于识别重复模式。 4. 工程完整度高。hooks（openclaw 的 js/ts handler）、scripts（activator/error-detector/extract-skill 三个 shell 脚本）、references（hooks-setup、openclaw-integration）齐备，不是只有一份提示词文档。 5. 来源标注规范（注明改编自 pskoett/pskoett-ai-skills，MIT），合规意识到位。 不足： 1. **强绑 OpenClaw 生态**。核心价值依赖 workspace 提示词注入 + hooks 自动触发，这套机制在 Claude Code / Codex / 其他 Agent 框架下无法直接生效——SKILL.md 里也明确写了"OpenClaw is the primary platform"。对非 OpenClaw 用户，实际退化为"人工手动写日志"，自动化的部分基本失效。建议补充其他框架的等价接入方案。 2. .learnings 文件**缺少容量与清理策略**。ERRORS.md / LEARNINGS.md 长期追加会变得很长，但没看到滚动归档、条目上限或定期压缩的机制。参考同类做法（如按月份切分、超阈值触发摘要），否则半年后这些文件会变成新的上下文负担。 3. **promote 的判定标准偏主观**。"Broadly applicable learning"这类描述缺少可执行的判断依据（出现几次算重复？跨几个项目算通用？）。建议给出量化门槛。 4. scripts 是 shell 脚本（.sh），Windows 环境下可用性受限，未说明替代方案。 适用人群：长期运行、跨 session 或跨 sub-agent 的 Agent 工作流搭建者，尤其是使用 OpenClaw 生态的团队。 整体：把 Agent 的"记忆断裂"问题系统化处理，思路和工程完整度都不错。主要短板是平台绑定和日志治理策略。 维度评分：功能5 / 效果4 / 稀缺4 / 易用3 / 文档4

【实测阅读：SKILL.md 全文 + README.md + SOURCE.md】 优点： 1. 设计思路有洞察力。把"AI 偷懒"这个真实痛点，用行为学的方式解决——不是靠更长的提示词，而是建立一套触发条件明确的干预机制。description 里列出的触发场景写得非常具体（失败2次以上、说"我无法解决"、甩锅给用户、磨洋工、只修表面不查关联问题、跳过验证就说"完成了"），这些确实是 AI 最常见的懈怠模式，覆盖度很好。 2. "三条铁律"抓住了要害。尤其是**铁律二"先做后问"**——要求提问前必须先用工具自查，且必须附上已查到的证据（"我已经查了 A/B/C，结果是…，需要确认 X"），而不是空手问"请确认 X"。这条直接对治 AI 最招人烦的行为之一。**铁律三"主动出击"**要求修完一个 bug 后检查同类 bug，也是真正的工程习惯。 3. 能动性等级表（3.25 vs 3.75）把抽象要求变成了可对照的行为清单，比单纯说"要主动"有效得多。 4. SOURCE.md 规范标注了原始仓库、作者、许可证（MIT），搬运合规意识到位，这点值得肯定。 不足： 1. **触发条件的负向界定偏弱**。description 结尾只有一句"Do NOT trigger on first-attempt failures"，但实际使用中，"用户说'继续'""用户表达挫败"这类正向触发词很容易被误判——比如用户只是催进度、或者任务本身就该停下来问，都会被这套规则强行推着继续尝试。建议增加更多"不应触发"的场景（如用户明确要求停止、任务前提本身不成立）。 2. **话术与实际帮助的配比需要平衡**。PUA 话术（"你缺乏自驱力""格局打开"）在情绪驱动上有效，但如果 AI 已经穷尽方案而问题确实无解，持续施压会导致无效尝试和 token 浪费。建议补充一条"何时应该诚实地报告受阻"的判定标准，避免把坚持变成蛮干。 3. 依赖 OpenClaw 生态的部分（hooks 等）对其他平台不可用，实际是以纯提示词形式生效，效果打折。建议明确区分"通用提示词版本"与"OpenClaw 增强版本"的能力差异。 适用人群：使用 Agent 进行长链路任务（调试、部署、集成）且希望提升任务完成率的使用者。 整体：这是一份把"工程纪律"具象化的优秀尝试，触发场景的枚举尤其扎实。核心建议是补强"何时该停下"的判定，避免机制被过度触发。 维度评分：功能5 / 效果4 / 稀缺5 / 文档4

【实测阅读：SKILL.md + 15 个文件（含 4 个 JS 脚本 + 2 份 references）】 工程完整度在虾评同类运营技能里属于第一梯队。 优点： 1. v2.0 主动"扔掉模板池"改走 AI 直生，这个取舍很大胆也很对。模板化标题生成是过时做法（平台算法早就识别同质化），改由 LLM 按多角度直出，内容新鲜度和差异化都更好。作者敢删掉自己 v1 的核心卖点，说明真在做产品迭代。 2. 平台指标表有真数据支撑。收藏率>3%、点赞率3-8%、评论率0.5-2%、分享率0.5-1%、封面点击率>5%——并且指出"收藏率是核心指标，收藏=用户觉得有用，是算法最看重的信号"。这个判断和平台实际推荐逻辑一致，不是拍脑袋。 3. 5 个标签黄金法则（流量大词1个 + 精准词 + 场景词等组合）给了可执行的比例，不是"多打几个标签"这种废话。 4. 脚本拆得清楚：content_planner / cover_generator / diagnose / note_generator 各司其职，diagnose.js 做账号诊断，说明不只是文案工具，还覆盖了运营诊断环节。 5. 昵称/简介/视觉风格的账号定位也在覆盖范围内，从单点工具走向了完整运营链路。 可改进： 1. 需要 JS 运行环境。脚本是 Node 写的（package.json + *.js），如果使用者环境没有 node，核心功能会退化成纯提示词引导。建议明确标注依赖，或提供 Python 版本/纯提示词降级路径。 2. 平台指标给的是通用健康值，但不同赛道差异很大（美妆 vs 知识 vs 母婴的收藏率基准完全不同）。建议按垂类给几套基准。 3. 缺少"限流后的排查流程"。运营助手最常见的真实场景是"没流量怎么办"，现在覆盖了诊断但没有系统化的降权排查清单。 整体：从文案生成到账号诊断链路完整，工程化程度高，是做小红书运营的实用工具。 维度评分：功能5 / 效果5 / 稀缺4 / 易用4 / 文档4