45 min · 精读 social-content/ 与 skill-xhs-publisher/ 两个目录的全部文件清单
🎒 预备知识：完成上一课「L06」（零基础入口：第 0 课）
前置课给你攒齐了推理链：模型只会生成文本（L1），不能碰文件系统、浏览器、网络； 模型会软失败（L5/A13）——自信地数错字数、编造参数；模型不稳定（L3）—— 同一输入两次输出不同。而脚本正相反：确定性、可测试、失败会抛异常。分工线就是短板互补线： 凡是"每次执行必须一模一样"的事（读文件、校验字数、点发布按钮），交给脚本； 凡是"需要理解与创造"的事（写什么文案、选什么角度），交给模型。 这条线画错的效果：让模型裸点浏览器按钮 = 每次点法不同 + 假成功分不清； 让脚本写文案 = 得到模板垃圾。
| social-content（纯 prompt） | skill-xhs-publisher（薄壳） | |
|---|---|---|
| 目录内容 | SKILL.md + 3 个 references，无脚本 | SKILL.md + references/commands.md，自身无脚本 |
| 真正实现 | LLM 按流程写文案 | skills/shared/scripts/xhs_publish.py（47KB） |
| 为什么无脚本 | 它不需要碰环境——产出就是文本 | 脚本在共享层（见下节） |
| 复用他人资产 | 引用 ../text-polisher/references/zh-ai-markers.md（跨技能引用知识） | SELECTORS 每条标注参考源（移植自 xiaohongshu-mcp） |
注意两个技能目录里都没有自己的实现脚本——但原因相反：前者因为不需要， 后者因为脚本在 shared。这揭示了目录结构的一个深层原则：SKILL.md 是"给模型的说明书"， 实现可以在任何地方——说明书与实现分离，两层独立演进。
xhs_publish.py 的调用方有两个：agent（按 SKILL.md 指引调用）和 Web 后端（POST /api/publish/xhs 端点直接 Popen（Python 启动子进程执行）它，正课 L09 的端点地图会看到）。 如果脚本放技能目录里：① Web 后端要硬编码一个藏在技能目录深处的路径；② 改一处 bug 要记得 另一个调用方也受影响；③ 复用给下一个平台技能要跨目录引用。共享层 = 多调用方的单点实现 ——48 个共享脚本（约 2.3 万行）就是整个执行层的"标准库"。判据：一个脚本被两个以上入口用， 就升入 shared。
check（环境自检）→ login（扫码）→ plan（dry-run 预检，给用户确认）
→ 人设检查（persona_gate）→ publish --exec（真发）
→ 成功校验（URL 离开 /publish/publish）→ 留痕（record + publish-log）注意 dry-run 与 --exec 的位置：默认演练，显式授权才真发——M5 会逐行展开这个设计 （L13 三段式、L14 证据链）。SKILL.md 的工作就是把这条链写清楚，让模型照着链执行， 每步调哪个脚本、什么参数、失败了怎么办。
给三个新能力划边界（壳里写什么、脚本里放什么）： ① 批量给 100 张图去背景；② 写一份竞品分析报告；③ 定时发布到快手。 划完讲给我听，我用 Easel 的真实实现对照批改。
坑 1：把决策写死在脚本里。脚本里硬编码"文案必须 500 字"——那是策略， 归 SKILL.md/模型；脚本只管校验字数。坑 2：把 IO 写进 prompt 流程。 SKILL.md 写"用 python 读一下 outputs 目录看看有什么"——IO 该封装成脚本子命令。 坑 3：单调用方脚本也塞 shared。反向错误——shared 是共享层的"标准库"， 单调用方的私有脚本留在技能自己的 scripts/。
说清"为什么 xhs_publish.py 不放在技能目录里而放 shared"——提示：答案和 Web 后端有关（L09/L12 展开）。
一手源：两个技能目录的文件树 + skill-xhs-publisher/references/commands.md（命令样例下沉的范例）。