CHANGELOG

v1.4.0（2026-09-11）

图床模块大升级 + 主题库修正。

新增
- 腾讯云 COS 图床 Provider（scripts/upload_imagehost.py）：免备案、官方默认域名保证 HTTPS（*.cos.<region>.myqcloud.com）；与七牛 Kodo 形成「HTTPS 图床」双方案。
- 外链可达性回检 verify_url()：上传后自动验证图床 URL 真能打开，区分 ssl_证书不匹配 / http_403 / http_404 / 超时，失败自动降级为 base64 内嵌，避免「上传接口 200 但图床裂」的隐患。

修正
- 摸鱼绿主题 vendor/gzh-design/references/theme-moyu-green.md：删除与微信编辑器实际行为矛盾的「支持 linear-gradient / box-shadow」描述，去掉全局 overflow-x:hidden（被微信剥离反而破坏主题）。
- 七牛测试域名限制提示：upload_imagehost.py 增加「测试域名仅 HTTP、不支持 HTTPS」的明确文案。

优化
- scripts/inline_preview_images.py 新增 --image-host cos 选项。
- Stage 06 分发铁律：最终交付物单一指向 *_预览.html，其他变体（_*_辅助.html / wenyan 渲染效果）加 _辅助 后缀或显式标注，避免「5 份 HTML 拿错」事故。

v1.3.4

内置 vendor/wechat-publisher + vendor/gzh-design，单包自包含。

v1.3.1

上架 SkillHub 公开版（首版全平台加固：移除 cygpath 依赖、Python 自动定位）。

AI 内容生产与增长流水线（总控）

一、本 Skill 的职责边界

本 Skill 是调度器，不是写手。它自身不直接产出文章内容。

它只负责 10 件事：

1. 接收用户任务并解析选题
2. 创建/定位项目目录
3. 读取项目配置（PROJECT_BRIEF.md）
4. 读取状态机（STATUS.md）判断当前应执行哪个阶段
5. 加载对应阶段的指令文件并执行该阶段
6. 按该阶段的验收标准检查产出
7. 将结果保存为独立文件
8. 执行质量门，判断是否允许进入下一阶段
9. 需要人工决策时暂停并向用户请示
10. 全流程结束后归档项目

铁律：绝不跳过 STATUS.md 直接从 Stage 01 重跑。 每次进入项目，第一件事永远是读 STATUS.md。

二、项目根目录解析顺序

按以下顺序确定 PROJECT_ROOT，取第一个命中的：

1. 用户在本次指令中显式指定的路径
2. ~/.workbuddy/content-pipeline.json 中的 projectRoot 字段
3. 默认值：D:/word文档/公众号/ContentProjects

单个项目目录为 PROJECT_ROOT/<项目名>/。项目名使用 YYYYMMDD-选题短名 格式，避免同名冲突。

三、启动路由

红线预判（任何项目第一件事，先于一切）

在进入路由判断前，先扫描用户指令与后续将写入的 PROJECT_BRIEF.md 中是否出现涉密 / 涉敏红线词：

• 红线词示例：涉密、机密、秘密、内部资料、未公开、保密、敏感信息、涉密文件，以及任何密级标记（如「秘密」「机密」「绝密」）。
• 一旦命中 → 立即终止本流水线：不创建项目、不写文件、不把内容送入模型。明确告知用户：此类材料须走机构内部 / 离线 / 涉密流程，AI 流水线在物理上不该触碰。
• 这是不可关闭的硬拦截，优先级高于任何「继续 / 强制执行」指令。

强合规模式（央国企 / 政务 / 党建 / 重大政策 / 机构主体）

满足以下任一即进入强合规模式，全流程启用额外控制：

• 用户显式声明合规场景 = 央国企（庄重规范）；
• 或从选题 / 目标用户 / 平台 / 行业自动识别涉央国企、政务、党建、重大政策、机构主体。

进入后自动生效：

• PROJECT_BRIEF.md 的「合规场景」置为 央国企（庄重规范）；
• Stage 03 后启用 Gate 04 合规与政治导向门（硬性人工签批，见 references/gates.md）；
• Stage 05 切换为庄重规范文风分支（见 references/stage-05-title.md）；
• 启动初始化脚本时传入 --compliance "央国企（庄重规范）"。

收到任务后，先判断是新项目还是恢复项目：

用户给出选题
   ├── PROJECT_ROOT 下已存在同名/相似项目目录？
   │      ├── 是 → 读取该项目 STATUS.md → 从 NEXT_STAGE 继续
   │      └── 否 → 新建项目（走下方「新项目初始化」）
   └── 用户只说「继续 XX 项目」→ 直接定位目录 → 读 STATUS.md → 继续

新项目初始化

运行初始化脚本创建目录骨架、PROJECT_BRIEF.md 与 STATUS.md。

> 跨机器可移植写法：python 通常不在 PATH，且脚本输出含中文 JSON，需设置 PYTHONIOENCODING=utf-8。
> 解释器用 WorkBuddy 受管 Python（任意版本均可，脚本仅用标准库）；脚本路径按实际部署调整
> SKILL_DIR（用户级：~/.workbuddy/skills/content-growth-pipeline，项目级：<仓库>/.workbuddy/skills/content-growth-pipeline）。

# 跨平台定位 Python：优先系统 python3，否则回退 WorkBuddy 受管 Python（.exe 或 bin/python3 均可）
if command -v python3 >/dev/null 2>&1; then
  PYBIN="python3"
elif command -v python >/dev/null 2>&1; then
  PYBIN="python"
else
  PYBIN=$(ls "$HOME/.workbuddy/binaries/python/versions"/*/python.exe \
              "$HOME/.workbuddy/binaries/python/versions"/*/bin/python3 2>/dev/null | head -1)
fi
# 跨平台定位技能目录：用户级默认；若以「项目 Skill」部署则回退到工作区内的 .workbuddy/skills
SKILL_DIR="$HOME/.workbuddy/skills/content-growth-pipeline"
[ -d "$SKILL_DIR" ] || SKILL_DIR="$(pwd)/.workbuddy/skills/content-growth-pipeline"
PYTHONIOENCODING=utf-8 "$PYBIN" "$SKILL_DIR/scripts/init_project.py" \
  --name "<项目名>" \
  --topic "<选题>" \
  --platform "<目标平台>" \
  --audience "<目标用户>" \
  --content-goal "<内容目标>" \
  --business-goal "<商业目标>" \
  [--compliance "央国企（庄重规范）"] \
  [--root "<PROJECT_ROOT>"]

脚本只创建文件、从不删除文件；已存在的文件默认跳过（除非显式传 --force）。

初始化后补全 PROJECT_BRIEF.md：

• 非关键字段缺失 → 根据上下文合理补全，并在字段后标注 （自动推断）
• 关键字段缺失（选题、目标用户、目标平台、内容目标）→ 停下来问用户，不要猜

四、七个阶段总览

执行某阶段时，只加载该阶段的指令文件，不要一次性读完全部 references（渐进式加载，节省上下文）。

依赖铁律：上一步的输出就是下一步的输入。 任何阶段都不得抛开已有产出重新从零调研。Stage 03 禁止重新做市场调研，必须读 02_RESEARCH.md。

五、状态机（STATUS.md）

STATUS.md 是项目唯一状态真相源。字段：

PROJECT_STATUS:      # 项目级状态
CURRENT_STAGE:       # 当前阶段，如 STAGE_03
COMPLETED_STAGE:     # 已完成阶段列表
NEXT_STAGE:          # 下一步该跑哪个阶段
WAITING_FOR_USER:    # YES / NO，以及在等什么
LAST_UPDATED:        # 时间戳
ERRORS:              # 失败记录与重试次数

允许的状态值（仅这 6 个）：

NOT_STARTED  RUNNING  WAITING_FOR_APPROVAL  COMPLETED  FAILED  WAITING_FOR_DATA

状态更新时机（每一次都必须写）

• 开始某阶段 → CURRENT_STAGE=STAGE_0X，状态 RUNNING
• 阶段产出通过验收 → 该阶段 COMPLETED，更新 COMPLETED_STAGE 与 NEXT_STAGE
• 触发质量门需人工决策 → WAITING_FOR_APPROVAL，WAITING_FOR_USER=YES
• 验收不通过且重试耗尽 → FAILED，写入 ERRORS
• Stage 06 完成 → 项目状态置为 WAITING_FOR_DATA

用脚本做确定性更新，避免手改出错。为简洁起见，下文用 $PY 与 $PS 代指（路径按实际部署调整）：

# 跨平台定位 Python：优先系统 python3，否则回退 WorkBuddy 受管 Python（.exe 或 bin/python3 均可）
if command -v python3 >/dev/null 2>&1; then
  PYBIN="python3"
elif command -v python >/dev/null 2>&1; then
  PYBIN="python"
else
  PYBIN=$(ls "$HOME/.workbuddy/binaries/python/versions"/*/python.exe \
              "$HOME/.workbuddy/binaries/python/versions"/*/bin/python3 2>/dev/null | head -1)
fi
# 跨平台定位技能目录：用户级默认；若以「项目 Skill」部署则回退到工作区内的 .workbuddy/skills
SKILL_DIR="$HOME/.workbuddy/skills/content-growth-pipeline"
[ -d "$SKILL_DIR" ] || SKILL_DIR="$(pwd)/.workbuddy/skills/content-growth-pipeline"
PY="$PYBIN"
PS="$SKILL_DIR/scripts/pipeline_status.py"

PYTHONIOENCODING=utf-8 "$PY" "$PS" --project "<项目目录>" --show
PYTHONIOENCODING=utf-8 "$PY" "$PS" --project "<项目目录>" \
  --set-current STAGE_02 --set-status RUNNING
PYTHONIOENCODING=utf-8 "$PY" "$PS" --project "<项目目录>" \
  --complete STAGE_01 --next STAGE_02
PYTHONIOENCODING=utf-8 "$PY" "$PS" --project "<项目目录>" \
  --gate GATE_01 --gate-status COMPLETED --gate-result "A｜值得做"
PYTHONIOENCODING=utf-8 "$PY" "$PS" --project "<项目目录>" \
  --project-status WAITING_FOR_DATA

--set-status 只写阶段状态；需要单独改项目级状态时显式传 --project-status（后者优先）。

六、质量门（通用 3 门 + 强合规模式第 4 门）

门控详细验收清单见 references/gates.md。摘要：

> Gate 04 是硬性人工签批门，AI 不替代政治 / 合规终审；仅在强合规模式启用，通用场景不出现。

软检查点：Stage 03 产出长文后，建议提请用户做一次人工事实终审再进 Stage 04/05。这不是硬门，但要主动提示。

默认推进节奏（除非用户当次另有指示）

通用场景只在 3 个质量门停下等人；强合规模式额外在 Gate 04 停下等人。其余阶段自动衔接。

Stage 01 →【Gate 01 停·等人】→ Stage 02 →【Gate 02 停·等人】→ Stage 03
  → 软检查点(提示但不阻塞)
  →【Gate 04 合规与政治导向门·停·等人】(仅强合规模式) → Stage 04
  → Stage 05 → Stage 06 →【Gate 03 停·等人】
  → 人工发布 → WAITING_FOR_DATA → Stage 07

• 门上停下时：写清结论与风险，置 WAITING_FOR_APPROVAL，等用户明确答复再继续。
• 非门阶段完成后：简报一句结论 + 呈现产出文件，不等待，直接进入下一阶段。
• 阶段验收不通过时按第七节重试；重试耗尽才停下找人。
• 用户说「一步一停」「每个阶段给我看」时，切换为逐阶段暂停模式。

七、失败重试机制

阶段未达验收标准时，禁止直接进入下一阶段。先判因，再定向补救：

同一阶段最多重试 2 轮。仍不达标 → 状态置 FAILED，写清 ERRORS，交人工决策。
只有通过当前阶段验收，才允许把状态改为 COMPLETED。

八、可复用的既有能力（不要重复造）

执行各阶段时优先调用环境中已有能力：

调用外部 skill 前的凭据加载（Stage 04 / 06）

wechat-cover 与 wechat-publisher 依赖凭据环境变量。凭据集中存放于
~/.workbuddy/.content-pipeline.env（不进 git、不出现在对话中）。调用前必须先加载：

set -a; source ~/.workbuddy/.content-pipeline.env; set +a

• wechat-cover（可选，封面爆款方案）需要 REDFOX_API_KEY，需另行安装 wechat-cover skill。

• wechat-publisher 已随本技能内置于 vendor/wechat-publisher/，无需单独安装；它
  需要 WECHAT_APP_ID / WECHAT_APP_SECRET，且 wenyan 已装在受管
  workspace（用 "$HOME/.workbuddy/binaries/node/workspace/node_modules/.bin/wenyan" 调用），
  并已在公众号后台把本机 IP 加入白名单。

• gzh-design（公众号主题化精排，可选增强）已随本技能内置于 vendor/gzh-design/，无需单独安装；
  它提供主题组件库、vendor/gzh-design/scripts/validate_gzh_html.py（合规校验，ERROR 清零才交付）与
  vendor/gzh-design/scripts/wrap_preview.py（带「复制到公众号」按钮的预览页）。运行前定位（优先系统安装，否则用内嵌）：
  bash GZH_DESIGN_DIR="$HOME/.workbuddy/skills/gzh-design" [ -d "$GZH_DESIGN_DIR" ] || GZH_DESIGN_DIR="$SKILL_DIR/vendor/gzh-design"
  精排流程详见 references/stage-06-publish.md 的「可选精排（gzh-design）」小节。

若对应变量为空 → 跳过自动化，退回「只产出方案/稿件、由用户手动执行」，并提示用户补齐凭据。

九、贯穿全流程的执行纪律

详见 references/conventions.md（证据分级、时效要求、人机分工）。核心红线：

• 不得编造数据、人物、收益、案例、来源。
• 核心论据优先 A/B 级证据；C/D 级必须标注。
• 具时效性的信息（市场数据、价格、平台政策、工具定价、AI 能力）必须记录来源 + 发布时间/查询日期，不得把旧数据当现况。
• 无法验证的信息统一标注：暂未找到足够证据，不建议作为核心论据。
• AI 负责：搜索、调研、整理、结构、初稿、标题、视觉方案、改写、归档、数据分析。
• 人工负责：方向判断、事实终审、品牌观点、审美判断、商业判断、风险控制、最终发布。
  不得代替人工做高风险终审与发布决策。

十、每个阶段的标准执行动作

无论执行哪个阶段，都按同一套动作走：

1. 读 STATUS.md 确认该阶段确实可执行（前置阶段已 COMPLETED、门已通过）
2. 置状态为 RUNNING
3. 读取该阶段的输入文件（见第四节表格）
4. 加载 references/stage-0X-*.md，按其中的步骤与固定输出格式执行
5. 写入该阶段的输出文件
6. 对照该指令文件末尾的「验收标准」自检
7. 通过 → 更新 STATUS 为 COMPLETED 并设置 NEXT_STAGE；不通过 → 走第七节重试
8. 如该阶段后接质量门 → 执行 references/gates.md 对应门控
9. 向用户简报本阶段结论，并呈现新产出的文件

十一、最简启动指令

用户只需说：

启动AI内容生产流水线。
选题：<选题>
目标平台：<平台>
目标用户：<用户>
内容目标：<目标>
合规场景：央国企（庄重规范）   # 涉央国企/政务/党建时填；留空则我自动识别
开始执行。

甚至更短：启动内容流水线，选题：<选题>——缺失的非关键字段自动推断，关键字段才追问；涉央国企 / 政务 / 党建时我会自动进入强合规模式。

恢复：继续 <项目名> 项目 或 继续内容流水线。

补数据跑复盘：<项目名> 补充发布数据：阅读 X、点赞 Y……执行 Stage 07。

十二、版本与变更日志（Changelog）

• v1.4.0（2026-09-11）
• 图床新增腾讯云 COS provider（--image-host cos），并改为首选推荐。实现签名 v5（q-sign-algorithm=sha1）+ PUT Object 直传，零第三方依赖（标准库 hmac/hashlib/urllib）。
• 为什么换成首选：七牛 Kodo 的测试域名只有 HTTP、不支持 HTTPS（控制台明确「测试域名无法自助修改配置」），换出的 https 外链全部 403，根本无法用于公众号粘贴；要想用必须绑自定义域名并先完成 ICP 备案（买域名 + 买服务器 + 备案 10–20 天）。而腾讯云 COS 的默认域名 <bucket>.cos.<region>.myqcloud.com 官方保证支持 HTTPS，且该域名归属腾讯云（已备案）→ 用户无需自有域名、无需备案、无需服务器，开通即可用。同理适用于阿里云 OSS（aliyuncs.com）。
• 凭据：--cos-secret-id/--cos-secret-key/--cos-bucket/--cos-region，或环境变量 COS_SECRET_ID/COS_SECRET_KEY/COS_BUCKET/COS_REGION；--cos-domain 可覆盖为自定义域名。桶需设为「公有读私有写」。
• 已知限制（已在代码与文档注明）：2024-01-01 后新建的桶，用默认域名在浏览器地址栏直接打开会触发下载而非预览（x-cos-force-download 头）；不影响 <img src> 引用，也不影响微信服务器抓取转存。

• upload_imagehost.py 与 inline_preview_images.py 两侧均已接线；stage-06-publish.md 的图床说明已按「cos 首选 / qiniu 需备案 / smms 最简」重写。

• v1.3.9（2026-09-11）

• 图床模式新增「外链可达性回检」（防裂图，重要）：此前 --image-host 只校验「上传接口返回 200」，不校验产出的 URL 是否真能访问，导致可能产出「看似全部成功、实际浏览器全裂图」的成品。现 ImageHost.upload() 在拿到 URL 后强制回检一次（新增 verify_url()），取不到就抛错并降级 base64，不再静默写入坏链接。
• 回检能区分的原因码：ssl_证书不匹配（忽略证书后可取到 → 域名未正确配置 HTTPS）、http_403（域名未开通 HTTPS / 防盗链 / 空间为私有）、http_404（文件未传成功）、非图片、网络_<异常>。缓存里若存的是坏 URL 会自动丢弃重传。
• 实测案例：某七牛测试域名 xxx.hb-bkt.clouddn.com http 全部 200 但 https 连根目录 403 且证书名不匹配（该域名未开通 HTTPS）。加了回检后，跑图床模式会明确报「外链不可访问（http_403）…请检查图床域名是否已开通 HTTPS」并自动降级 base64，而不是产出裂图成品。
• 排查命令备忘：curl -v 见 SEC_E_WRONG_PRINCIPAL → 证书问题；curl -sk 忽略证书 → 看真实 HTTP 码；对比同一路径的 http / https 可快速判断是否仅 HTTPS 未开通。

• 注意：verify_url() 只回检新上传或缓存命中的链接；若 HTML 里本身已是 http(s):// 远程地址，内联器按原样保留、不回检（如需检查请用 upload_imagehost.py 单独验）。

• v1.3.8（2026-09-11）

• 修正「摸鱼绿」主题库的平台限制声明（与新校验规则自相矛盾）：vendor/gzh-design/references/theme-moyu-green.md 此前声称微信支持 linear-gradient / box-shadow，而 v1.3.5 加入的 validate_gzh_html.py 规则已把这两者判为 ERROR——导致照着该主题库装配必然校验不通过。现已在主题库顶部改为准确表述（渐变/阴影/overflow:hidden/transform/filter/position:relative 会被微信剥离），并附装配时的替换指引（渐变 → 纯色 background；box-shadow → 1px solid 浅边框或删除；overflow:hidden → 删除）。
• 同步移除该主题「组件 1 全局容器」样例里的 overflow-x:hidden;（该属性会被剥离，且它写在最外层容器上，影响面最大）。
• 影响面提示：theme-red-white.md / theme-graphite-minimal.md / theme-zen-whitespace.md / theme-moyu-ticket.md / theme-olive-journal.md 等主题库尚未做同样校正，若启用需按上述口径自行替换，或后续版本统一处理。

• 本次验证：用摸鱼绿装配一篇 2700 字长文，validate_gzh_html.py → 222 处 span leaf、0 ERROR / 0 WARNING；position:relative/box-shadow/linear-gradient/overflow:hidden/transform/filter 六项计数均为 0。

• v1.3.7（2026-09-11）

• 修复七牛 provider 上传 401 与区域报错：uploadToken 的 urlsafe base64 此前错误去除了 = 填充（与七牛服务端期望不符，返回 bad token）；已改为保留填充（对齐官方 SDK）。同时 QiniuProvider.upload 新增区域自动重试——当 bucket 在特定区域（如华北 z1）而默认走全球路由 upload.qiniup.com 收到 “incorrect region, please use up-z1.qiniup.com” 时，自动切换到七牛建议的地区上传域名并重试，用户无需手动指定 --qiniu-upload-host。已在真实七牛账号（华北 bucket gzh-img-lab）端到端验证通过：6 张图全部换成 https:// 并成功粘入公众号。

• 注：七牛「测试域名」(xxx.bkt.clouddn.com) 仅 30 天有效，长期用需绑定已备案自定义域名；但公众号粘贴外链图时会自动转存到微信自有 CDN，故该 30 天域名对「一次性排版发布」通常够用。

• v1.3.6（2026-09-11）

• 图床新增七牛云 Kodo provider（推荐长期方案）：scripts/upload_imagehost.py 的 QiniuProvider 已实现七牛自有 uploadToken 上传机制（HMAC-SHA1 签名，与官方算法一致），并接入 inline_preview_images.py 的 --image-host qiniu 模式。相较 SM.MS，七牛为「注册后长期可用」的国内云存储（个人实名有永久免费额度），国内节点、公众号粘贴可正常抓取转码，适合长期发文。凭据走 --qiniu-access-key/--qiniu-secret-key/--qiniu-bucket/--qiniu-domain 或环境变量 QINIU_AK/QINIU_SK/QINIU_BUCKET/QINIU_DOMAIN。上传失败仍自动降级 base64。
• 用法：
  python inline_preview_images.py --html <目标.html> --image-host qiniu --qiniu-access-key AK --qiniu-secret-key SK --qiniu-bucket <空间名> --qiniu-domain <https域名>

• 注：--image-host smms 仍可用（免费、1分钟注册，但长期性弱于七牛）；两者均为「复制→粘公众号」带图方案。

• v1.3.5（2026-09-11）

• 修复「别人用 skill 复制不到公众号」三类根因（用户实测反馈：一键复制有时只有文字、有时连文字框都复制不了）：
  1. 微信兼容 CSS 降级：vendor/gzh-design/references/theme-tech-blue.md 与 common-components.md 中此前误称微信支持 linear-gradient/border-radius/box-shadow/position:relative，实测这些会被公众号编辑器剥离，导致「排版复制不了、只剩文字」。已改为纯色 background-color / border / 左竖条等微信真支持的写法（intro 卡片、章节标题重叠布局、荧光笔均改纵向堆叠/纯色块）。validate_gzh_html.py 新增 6 条禁用规则：position:relative、box-shadow、linear-gradient、overflow:hidden/x、transform（保留 text-transform）、filter，违规直接 ERROR 拦下。
  2. 加固两处复制机制：vendor/gzh-design/assets/preview-template.html 的 gzhCopy() 与 scripts/build_preview.py 的 copyArticle()/copyText() 改为——file:// 非安全上下文（无 navigator.clipboard）用 document.execCommand('copy') + 选区复制渲染后的富文本（旧实现曾把 HTML 源码塞进 textarea，粘贴出 <section> 标签）；大 base64 图（>380KB）复制时弹「需手动传图/图床」提示；复制失败兜底「手动框选 Ctrl/⌘+A → 复制」。修复后「只剩文字」与「文字框也复制不了」两类问题均消除。
  3. 图床上传模块（让图片在微信粘贴里也带过去）：新增 scripts/upload_imagehost.py（标准库实现，SM.MS provider，Token 走 --smms-token 或环境变量 SMMS_TOKEN），并接入 inline_preview_images.py 新增 --image-host smms 模式——本地图上传换 https:// 地址（公众号粘贴可识别、自动抓取转码），上传失败自动降级 base64。配合「微信兼容 CSS」后，复制→粘到公众号可完整保留排版与图片。详见 stage-06-publish.md 内联步骤。

• 已知前置条件：图床模式需用户自备 SM.MS Token（免费注册）；未配置时维持原 base64 行为，适合「发文件给他人」的分发场景。

• v1.3.4（2026-09-09）

• 内联图片自动压缩（修复「图粘不进公众号草稿」）：scripts/inline_preview_images.py 由「只内联」升级为「先压缩再内联」。原实现直接对原图做 base64，单张 1MB 的图内联后约 1.3MB、5 张就 4MB+，复制到公众号时剪贴板卡死、图片上传失败，表现为「图粘不进草稿」，且原指令只说「分享不裂图」，没点出粘贴丢图这个更致命的后果。
  • 新增 --max-b64-kb（默认 380KB/张）、--max-width（默认 1080px）、--no-compress 三个参数；超限自动等比缩放 + 逐步降 JPEG 质量（82→60）重新编码。
  • GIF 动图为保动画跳过压缩，SVG 等矢量直接内联；压缩结果缓存到 _inline_cache/，重跑不重复压。
  • 压缩依赖 Pillow；缺失时不静默失败，打印警告并列出超限图片，装好重跑即可。
  • 实测（5 张 385–931KB 原图）：内联体积 4.0MB → 0.5MB，单张 61–145KB。

• Stage 06 指令同步：references/stage-06-publish.md 内联步骤改写——明确内联的首要目的是「让图能粘进公众号」（公众号只认公网 URL 或 base64，抓不到本地路径），补充压缩阈值说明、Pillow 缺失处理，并要求干净正文同样跑一次内联（用户可能直接开它全选复制）；验收标准新增「图片已压缩内联」硬指标（每个 <img src> 均为 data:image/ 开头、单张 ≤380KB、总量 ≤2MB）。

• v1.3.3（2026-08-19）

• Stage 06 产物对照卡：在 references/stage-06-publish.md 新增「产物对照卡」小节，要求 Agent 在 Stage 06 收尾向用户明确标出哪份文件带一键复制（预览页.html / *_预览.html），避免把不带按钮的干净正文 .html 误当成品。

• v1.3.2（2026-08-16）

• gzh-design 预览页自动内联图片：新增 scripts/inline_preview_images.py（纯标准库），Stage 06 精排步骤在 wrap_preview.py 之后新增「自动内联图片」——把成稿里的本地图片（04_VISUALS/ 相对路径、file://、绝对路径、SVG <image>、CSS background:url()）转 base64 嵌进 *_预览.html，使其成为完全自包含单文件，发给他人 / 离线打开均不裂图，无需图床。验收标准同步纳入。

• v1.3.1（2026-08-16）

• 精排主题改为用户需求驱动：移除 Stage 06「按题材自动推荐主题」的写法，改为三级优先级——用户精排步骤里明确指定 > PROJECT_BRIEF.md 的「排版主题偏好」字段（--layout-theme 写入）> 均未指定时向用户展示「调性/场景 → 主题」映射表让其自选，绝不替用户默认。PROJECT_BRIEF 模板与 init_project.py 同步新增该字段。

• v1.3.0（2026-08-16）

• 接入公众号精排引擎 gzh-design：内置 vendor/gzh-design/（主题组件库 + 合规校验 + 复制预览页），Stage 06 新增「可选精排」步骤——成稿先主题化精排，再走发布；与 build_preview.py 全配图内联分发页、wechat-publisher 草稿箱推送三者并存互补。定位逻辑「优先系统 gzh-design，否则内嵌 vendor」。

• v1.2.0（2026-08-11）

• 跨平台发布包加固：SKILL.md 与 stage-06-publish.md 的 Python 定位器改为「优先系统 python3 → 回退 WorkBuddy 受管 Python（.exe / bin/python3）」，彻底移除 cygpath -w 依赖；技能目录自动探测（用户级 $HOME/.workbuddy/skills 或项目级 ./.workbuddy/skills）。Windows / macOS / Linux 任意机器解包即用。

• 打包脚本统一为 dist/build_cross_platform.sh，输出 content-growth-pipeline-crossplatform.zip（含 vendor/wechat-publisher 与 build_preview.py，自包含单包）。

• v1.1.0（2026-08-07）

• 全链路跨平台化：Python 定位器优先系统 python3，回退 WorkBuddy 受管 Python（.exe 或 bin/python3 均可），去除 cygpath 依赖；技能目录自动探测（用户级 / 项目级），Windows / macOS / Linux 皆可开箱运行。
• 新增央国企合规加固：启动红线预判（涉密/涉敏词命中即终止，不进模型）、强合规模式、Gate 04 合规与政治导向门（硬性人工签批，AI 不替代终审）、Stage 05 庄重规范文风分支。
• 简报表新增「合规场景」字段，init_project.py 增加 --compliance 参数并接线，避免生成文件残留裸占位符。
• 状态脚本修复：pipeline_status.py 修正变更日志溢出与 PROJECT_STATUS 耦合两处缺陷。

• 校验：官方 package_skill.py 通过；可移植命令冒烟测试初始化成功（17 文件无误）。

• v1.0.0（初始）

• 总控 + 7 阶段 + 3 质量门 + STATUS.md 状态机的完整「AI 内容生产与增长流水线」。