公众号内容运营
把素材、审稿、排版和草稿交接串成可追溯的流程。适用于个人作者与内容团队；不依赖 Cola、私有素材库或某个账号。首次使用读取 工作表，按实际任务填必要字段，不要求用户回答已经提供的信息。
先确定交付边界
确认公众号/作者、读者、目标、来源、文风参考、文章归属与本次交付阶段。通常是本地审阅包或草稿箱；“发布这个 Skill”不授权发布公众号文章。用户已明确授权推草稿时直接完成，不反复确认。正式发布默认由负责人在后台完成；用户明确改为代发布时按当前工具与授权执行，并单独验证发布状态，不把群发通知当隐含步骤。
没有连接器或草稿权限时完成本地交付包，标记未上传。不要把文章上传到第三方排版服务作为隐含步骤。
1. 选题与取证
读取与主题相关的原始材料及上下文，先确认发言人，不假定“说话人1”就是作者。索引和摘要是定位工具；精确引语、数字与细节回到原文。把观点分成作者经历、他人陈述、公开事实和编辑推论。不同口径冲突时保留出处和时间，不择大数。
选一个读者问题和一个新角度，对照已发台账避免原样重复；已有系列优先，允许独立文章。没有新证据时可深化旧观点，但标为旧素材重编。不要为了选题合格硬凑两个数字。
产出 brief 与来源表。客户名称、内部数据、私人经历仅按明确可用范围引用；仅改名未必足够脱敏。涉及第三方成效时分开公司自报与独立验证，不把两次转载当两份独立证据。
2. 写作与内容审
使用用户给定的当前文风及认可样本。没有样本时采用自然、具体、清晰的中文，不默认冒充 Iris。允许基于真实经历起笔，也允许问题/观点开场；不得为了时间地点、括号、破折号或第一人称配额编造场景。数字不足就不用数据表。
写 article.md，并用独立 source-map.md 保留内部来源；公开稿保留适当公开引用，私有路径/会议标识不随正文发送。编辑推论不能伪装成作者原话。
按 双重审核与故障处理 做内容审：来源、归属、逻辑、标题承诺、文风和可公开性。对缺证据的关键事实先删去或收窄，不能靠润色掩盖。审稿报告区分阻断问题与可选建议。
3. 排版、图片与终审
生成 article.html：正文使用简单语义标签与 inline CSS，首个文章大标题在后台标题字段单独填写，避免重复。基础可从段落行高 1.8、段距 1.2em 开始，按手机预览调整；不承诺任意 CSS 都被微信保留。
封面、品牌色、字号和文末引导由账号配置决定。900×383 黑底白字是原团队历史模板，不是所有账号的强制规则；上传规格以当前后台为准。只使用已获准的图片，检查裁切、字形和版权。不要把图表或数据截图改造成伪造证据。仅在用户需要时加相关 CTA，不自动放作者的价格、联系方式或推广链接。
终审检查中文、长段、表格溢出、封面和正文图、链接、署名、摘要、原创/转载归属和内容完整性。确认没有内部注释、占位符、私人信息。内容改动后重做受影响的审核。
可选本地打包（只读输入、写新目录，无网络、无凭证访问）：
bashpython3 scripts/prepare_delivery.py --article article.json --out delivery-v1
article.json 字段见工作表。此脚本处理已有 HTML，并非 Markdown 渲染器、安全 HTML 消毒器或微信 API 客户端；不会上传、发布或群发。人工预览与来源审稿仍然必要。
4. 草稿箱交付与回读
优先使用已连接的公众号工具，或后台界面。只授予当前动作所需能力；先查当前工具/API 文档，不复制来源包的旧发布脚本。上传封面/正文图并替换为后台可用资产，再创建或更新目标草稿；保存账号、草稿 ID、版本/正文摘要和时间。
创建响应不等于正确交付。重新打开目标草稿，核对账号、标题、摘要、中文、图片、段落、链接与尾部；记录 API 字段回读和手机/后台视觉预览是否分别完成。失败或结果不明时先查草稿列表与已有 ID，不能盲目重试产生重复草稿，更不能尝试发布接口“验证”。
5. 交接与复盘
明确汇报实际达到的状态：本地已生成 / 内容审通过 / 终审通过 / 草稿已创建 / 草稿回读通过 / 已发布（如另获授权且实际验证）。最终交付文章、来源表、审核报告、封面与草稿标识。只有实际查看公开文章或后台发布结果才能记已发布；群发状态另记。
把真实故障写入项目日志，记录症状、证据、修复与复测；不要把一次疑似根因写成平台永久规则。此版本未附线上传输实现，账号权限与真实草稿写入需在目标环境验证。
按需参考
- 工作表与交付 JSON：新项目/新文章直接填写。
- 双重审核与故障处理：审稿、排版与上传排障时读取。
- 来源与改编边界：解释原 SOP 中哪些实践保留、哪些需要参数化。
