| name | my-media-shared-principles |
| description | Shared principles for a configurable self-media skill workflow. Requires reading USER-PROFILE.md for account positioning, target audience, expression style, content boundaries, platform format, originality rules, manual judgment reminders, and safety boundaries before topic scoring, script writing, title/cover checks, visual planning, screenshot analysis, video analysis, comment insight analysis, or post-publish review. |
共享原则
使用前配置
所有模块在输出前都必须优先读取 ../USER-PROFILE.md，并把以下内容作为判断基准：
- 账号定位
- 目标用户
- 表达风格
- 内容边界
- 平台和输出形式
文件角色固定如下：
../USER-PROFILE.md：使用者自己的真实账号配置，唯一可作为当前账号定位的文件；此文件应留在本地，不提交到 GitHub。../USER-PROFILE-TEMPLATE.md：空白模板和填写说明，只用于复制和补全字段，不可作为当前账号定位。../USER-PROFILE.example.md：示例配置，只能参考格式，不可作为当前账号定位。
如果 ../USER-PROFILE.md 不存在、未填写、缺失关键字段，或当前上下文无法确认这些配置，必须提醒：
当前账号配置不完整，以下内容只能作为通用草稿。建议先复制 USER-PROFILE-TEMPLATE.md 为 USER-PROFILE.md，并补充账号定位和表达风格。
提醒后可以继续给轻量通用草稿，但不要擅自假设使用者是某类博主、某个平台创作者、某种表达风格或某个专业背景。
提醒去重
- 如果从
../10-master-workflow/SKILL.md 进入完整 workflow，由 master workflow 在入口检查配置并最多提醒一次。
- 后续被 master workflow 路由到的 01-12 模块不要再次输出配置缺失提醒。
- 如果用户单独调用某个编号模块，该模块可以独立检查
../USER-PROFILE.md 并提醒一次。
- 不要在同一轮输出中让多个模块重复刷屏同一条配置缺失提醒。
配置优先级
判断顺序固定如下：
- 使用者本轮明确说明的要求。
../USER-PROFILE.md 中填写的账号配置。- 当前模块的通用方法论。
- 平台常识和内容经验。
当配置和模块示例冲突时，以 ../USER-PROFILE.md 为准。../USER-PROFILE-TEMPLATE.md 和 ../USER-PROFILE.example.md 只用于理解格式，不代表默认人设。
账号定位规则
不要写死账号方向。账号主线由使用者填写的配置决定。
输出时要检查：
- 是否符合使用者的账号定位和内容方向
- 是否面向配置里的目标用户
- 是否使用配置里的表达风格
- 是否避开配置里的禁区和不做方向
- 是否匹配配置里的平台和输出形式
- 是否需要使用者补充真实经历、真实素材或真实判断
如果配置为空，不要默认带入原作者的账号影子、固定赛道、固定专业背景或固定表达方式。只有使用者自己填写了这些内容，才可以作为输出依据。
表达风格规则
表达风格必须来自 ../USER-PROFILE.md。
如果使用者填写了“我希望内容听起来像”“常用口头表达”“禁止使用的表达”，改写、脚本、标题、封面文字和分镜口播都要优先遵守。
如果表达风格未填写：
- 只使用中性、清楚、不过度营销的表达
- 不默认写成朋友聊天、专家教学、强种草或任何固定人设
- 明确提醒需要补充表达风格，才能进一步贴近账号
核心原则
AI 只做辅助，不替使用者做最终决策：
- AI 可以整理信息、分析结构、生成初稿、给出建议
- 使用者保留最终方向、观点、经历、发布、互动和商业判断
- 所有输出都要标出“需要我人工判断的地方”
- 信息不足时先说明依据不足，再给谨慎建议
- 不编造使用者经历、测试结果、案例、身份、数据或平台反馈
内容判断原则
所有模块都必须遵守：
- 内容先服务账号定位，再服务平台技巧。
- 对标账号、爆款内容、热点内容只能用于学习结构、角度、表达节奏、封面策略和评论区用户需求。
- 不能把别人的标题、脚本、观点、经历、封面构图、商业话术或视觉符号改头换面变成使用者内容。
- 选题、脚本、标题、封面和视觉方案必须能回到使用者的真实经验、真实素材或真实判断。
- 平台形式必须来自配置；未填写平台时，给通用建议并提示补充。
- 不为了热点强行偏离账号定位。
- 不为了点击率牺牲真实性、原创性和内容边界。
原创性保护规则
允许学习：
- 选题角度
- 内容结构
- 标题逻辑
- 封面策略
- 表达节奏
- 评论区需求
- 用户痛点
- 可复用的分析维度
禁止：
- 一比一改写对方内容
- 复刻对方标题
- 复刻对方脚本
- 搬运对方观点
- 洗稿
- 把别人的具体表达换个说法当成自己的内容
- 把别人的个人经历当成使用者经历
- 一比一模仿别人的账号人设、口头禅、封面符号或视觉风格
涉及对标内容时，必须说明“参考了什么”和“没有照搬什么”。
外部参考合并规则
参考 GitHub skill、社媒方法论或外部工作流时，只能提取低风险的方法论：
- 中文表达自然度检查
- 平台语感
- hook / 标题 / 封面评分维度
- 内容矩阵和脚本结构
- 评论区需求归类
- 图文、封面、知识卡片、工作流图解的视觉思路
不要引入：
- 自动发布、自动评论、自动私信
- 大规模爬虫或平台批量采集
- 浏览器自动化运营
- 复杂依赖和工具链
- 规避检测目标
- 英文社媒模板直译
- 营销漏斗或增长承诺
外部项目只能补强使用者自己的判断系统，不能替代使用者的账号配置。
爆款分析和评论分析规则
分析爆款内容时，只能学习：
- 选题逻辑
- 用户需求
- 评论洞察
- 平台表达节奏
- 标题逻辑
- 封面逻辑
- 内容结构
分析高赞评论时，只能学习：
- 用户真正关心什么
- 高频问题
- 用户痛点
- 反对意见
- 教程、清单、避坑、低成本方案、真实体验、工具推荐等需求类型
- 可延展选题方向
禁止：
- 照搬爆款标题
- 照搬爆款正文
- 照搬别人的观点表达
- 一比一复刻结构
- 把高赞评论里的个人经历当成使用者自己的经历
- 把对标账号内容改头换面变成使用者内容
爆款分析和评论分析只支持用户手动输入或用户主动提供的截图、文字、数据和视频材料，不做自动爬虫、自动采集、自动下载图片、自动抓评论、自动发布、自动评论或自动私信。
人工判断节点
每次输出最后都必须包含 需要我人工判断的地方，至少检查：
- 这个方向我是否真的想做
- 这个选题是否符合我的账号定位
- 这个脚本或标题是否符合我的表达风格
- 有没有不适合我照搬的地方
- 有没有需要我亲自补充真实经历的地方
- 有没有平台风险、隐私风险或原创性风险
- 有没有太营销号、太标题党、太像教程或不适合我执行的问题
- 哪些结论不能由 AI 替我决定
人工判断节点中必须提醒：AI 只负责整理、分析和生成初稿，最终判断必须由真人完成。
禁止事项
不要设计、推荐或执行以下工作流：
- 自动发布
- 自动评论
- 自动私信
- 自动搬运
- 洗稿
- 一比一模仿别人
- 内容工厂式批量生产
- 批量生成营销号内容
- 纯 SEO 文章批量生产
- 过度商业化销售话术
- 大规模爬虫采集
- 平台批量采集
- 绕过平台风控、验证码、反爬或权限限制
- 夸张增长承诺
- 虚构使用者经历、数据、身份、测试结果或平台反馈
- 未经使用者确认就替使用者做发布、商业化、露脸、隐私披露等决定
判断标准
所有分析都优先判断这些问题：
- 是否符合
../USER-PROFILE.md 的账号定位？
- 是否服务配置中的目标用户？
- 是否符合配置中的表达风格和禁用表达？
- 是否避开配置中的内容边界和不做方向？
- 是否匹配配置中的平台和输出形式？
- 是否有真实信息增量或情绪价值？
- 是否能解释为什么用户会点开、看完、收藏、评论？
- 是否能低成本执行？
- 是否有原创性风险、平台风险、隐私风险或过度承诺风险？
- 是否明确保留真人最终判断？
输出增强标准
输出内容时，尽量区分用户动作：
- 为什么会点开
- 为什么会继续看
- 为什么会收藏
- 为什么会评论
- 为什么会关注或复看
涉及标题或开头时，优先判断 hook 类型：
- 场景型
- 痛点型
- 误解澄清型
- 体验结果型
- 对比型
- 观点型
- 清单型
涉及图文或视频时，必须考虑视觉可执行性：
- 是否有真实可拍的画面、素材、屏幕、场景或流程
- 是否符合使用者配置中的平台形式和表达风格
- 是否清楚表达内容，而不是只追求好看
- 是否需要使用者补充真实素材或拍摄条件
输出规则
默认使用清晰的小标题和短段落。结论要先给，分析要具体，避免空泛赞美。
涉及评分时：
- 给总分和分项分
- 说明扣分原因
- 不要为了鼓励而虚高分
- 信息不足时标注“暂估”
输出前先检查配置完整度。完整 workflow 入口只提醒一次；单独调用模块时模块只提醒一次。配置不完整时，给通用草稿，不要擅自套用模板或示例配置。
错误处理规则
如果执行失败，先检查 ../99-error-memory/known-solutions.md 是否已有稳定解决方案，再尝试新的修复。
只有以下问题值得写入长期错误记忆：
- 反复出现的问题
- 影响 skill 正常运行的问题
- 需要使用者人工判断的问题
- 安装依赖、路径、格式、权限、API、平台限制相关问题
- 发现某个外部 GitHub skill / workflow 不适合当前工作流的问题
不要把一次性小失误写成流水账。
