动作规则登记表:social-media-organic-tool(post)

层③(动作规则/调试)的落地文档 —— 两层结构(2026-07-14 修订)。 层③劈两层(Anderson 原话:"系统里每个动作都需要有规范,那么这个规范就需要我人为的去确认;当然有一些大的需要旋钮调试"): - 表A「全动作规范清单」 = 系统里每一个动作(不分大小,连登录/下载/CRUD/状态机都算)逐条登记:干嘛/入/出/守什么规矩/默认的度。给 Anderson 逐条看、逐条签字用,不是每条都要能调。 - 表B「旋钮子集」 = 从表A 里挑出"度错了就毁价值"的动作(R1–Rn),给可调旋钮 + 试验台 + 落库版本回退。 判据(旋钮 vs 只规范,一句话):「把这个值改错,程序会崩吗?」 - 崩 / 报错 / 对错二元(登录、下载、状态机、CRUD、参数化查询)→ 逻辑,错了是 bug 不是度 → 只规范,不配旋钮。 - 不崩,但结果悄悄变差/变好(LLM 提示词、爆款阈值、排期时段、排序权重、筛选条件)→ 度 → 配旋钮 + 试验台。 - 再加一问:「会想拿真样本反复试它吗?」会→旋钮;一次定死就对→只规范。 - 陷阱:已经是用户每次请求能传的输入(配图尺寸、检索天数)= 已可调,别再配旋钮(过度工程)。 铁律:表B 旋钮规则绝不硬编码,必须外置进 action_rules 表 + 有试验台 + 可回退。 产出方:solution-architect(初稿)。签字:Anderson(表A 逐条)。落库/试验台实现:backend + frontend engineer。验收:qa-engineer + GM。 数据模型 / 迁移 / 层⑤劈分见 ARCHITECTURE-RULES-LAYER.md;3 接口见 API-CONTRACT-RULES.md。

表A —— 全动作规范清单(Anderson 逐条签字)

枚举方法:遍历 backend/src/application/use_cases/ 下全部 16 个 use_case 文件 + backend/src/domain/ 下全部 domain 动作,逐个动作登记,不靠 grep"度"(第一版只扫 LLM 提示词,漏了 schedule_algorithm.py 写死的 _WORK_DAYS=5/_DEFAULT_HOUR=9 发布排期时段 —— 这正是必须枚举全动作的原因)。 分类列判据:只规范 = 逻辑/CRUD/状态机,改错会崩或对错二元;🎛旋钮 = 度错悄悄毁价值、想拿真样本反复试;🟡候选 = 拿不准,签字时 Anderson 拍板。

表A 里两条需 Anderson 签字时拍板的 🟡/边界项

• A30 AI 助手(_SYSTEM_TEMPLATE + _PAGE_KNOWLEDGE):Anderson 已拍板 = 只规范,不升旋钮。它是固定人设 + 静态 page→知识 映射的帮助文案,输出不进入生产内容(不影响素材/爆款/成品价值),"度"错了顶多帮助话生硬,不"毁价值"。改文案走既有"后端下发 tour/page 文案"轻通道(COMPONENT-BACKEND §2/§3),不进 action_rules。
• A04/A07/A23 的尺寸/大小/MIME 白名单:是安全护栏(拒非法输入,改错会崩/放行坏文件),非业务度 → 只规范,留代码常量/.env,不进 action_rules。
• A21/A23 的检索天数、配图尺寸:陷阱——已是用户每请求可传的入参(前端表单已能改),再做旋钮=过度工程 → 只规范。

表B —— 旋钮子集(度错毁价值,配 action_rules + 试验台)

从表A 分类为 🎛旋钮 的动作挑出,共 7 条(R1–R7)。每条映射到 action_rules 表的一行(rule_id + config JSON,带 version/status 可回退)。提示词/阈值/名单一律进库,代码里只留灾难回落 _DEFAULTS(见 ARCHITECTURE-RULES-LAYER.md §3)。

验证三态(硬要求):

• 🔴 理论 — 只有高手蒸馏/拍脑袋的默认值,没在真项目跑过。所有规则默认从这里起步。
• 🟡 在项目试过 — 拿真实样本喂进试验台跑过,有输出可评,还没定论。
• 🟢 跑通/证伪 — 试验台反复调过,确认这个度对本项目跑通(采纳)或证伪(换值)。

R1–R7 全部 🔴 理论起步。度是 Anderson 拿真样本在试验台试出来的,架构师只给合理初值,不替他定死。

表B 详表(每条旋钮)

R1 — 搜索方向生成

• 挂在动作:discovery_use_case.py:70 get_search_directions 里的 llm.complete(system=_DIRECTIONS_SYSTEM.format(...)) / API POST /api/discovery/directions
• 为什么要规则化:方向推得太泛 → 搜出来全是 meme/无关内容;太窄 → 漏掉真爆款。营销方向性的度错了,整条找爆款链从源头就歪。
• 可调项(旋钮):

• 提示词模板(外置,禁止硬编码):存 action_rules.R1.config.prompt_template,当前值 = 现 _DIRECTIONS_SYSTEM 原文,含 {platform} 占位符。
• 存储:action_rules,PK id,值列 config JSON,带 version+status+updated_by+updated_at。
• 调试入口:试验台 /settings/rules/R1 → 喂一个真实产品素材,看它给的 3–5 个方向准不准。
• 当前验证状态:🔴 理论 → 待 Anderson 拿自己的产品跑第一轮。

R2 — 帖子打标(爆款判定)

• 挂在动作:discovery_use_case.py:168 tag_posts 里 llm.complete(system=_TAG_SYSTEM) / API POST /api/discovery/tag
• 为什么要规则化:"什么算爆款钩子""相关度多少算相关"直接决定哪些帖子进内容库。判太松 → 库里全是噪音;判太严 → 好素材被漏。
• 可调项:

• 提示词模板:action_rules.R2.config.prompt_template = 现 _TAG_SYSTEM 原文。
• 调试入口:/settings/rules/R2 → 喂一批真帖子,看打标结果对不对。
• 验证状态:🔴 理论。

R3 — 翻译改写

• 挂在动作:translation_use_case.py 用 _TRANSLATE_SYSTEM.format(platform_style=...) / API POST /api/translations
• 为什么要规则化:改写幅度太保守 → 像机翻不地道;太夸张 → 偏离产品事实、平台违规。平台风格 + 改写幅度是这步的命门。
• 可调项:

• 提示词模板:action_rules.R3.config.prompt_template = 现 _TRANSLATE_SYSTEM 原文,含 {platform_style} 占位符。platform_styles map 也进 config(现为代码里的 _PLATFORM_STYLE)。
• 调试入口:/settings/rules/R3 → 喂一个素材,选平台,并排看"保守 vs 大改"两版改写。
• 验证状态:🔴 理论。

R4 — 成片文案

• 挂在动作:generate_use_case.py:28 _GENERATE_SYSTEM 里 generate_post / API POST /api/generate
• 为什么要规则化:文案语气(专业↔活泼)和长度直接决定成品能不能直接发。语气跑偏 = 成品要人工重写。
• 可调项:

• 提示词模板:action_rules.R4.config.prompt_template = 现 _GENERATE_SYSTEM 原文。
• 调试入口:/settings/rules/R4 → 喂模板+产品,看成片语气/长度合不合适。
• 验证状态:🔴 理论。

R5 — 逆向模板抽象

• 挂在动作:template_use_case.py 引用的 domain/template/models.py:36 REVERSE_SYSTEM_PROMPT / API POST /api/templates/reverse
• 为什么要规则化:模板抽象太细 → 变量太多没法复用;太粗 → 套不出好内容。抽象粒度决定模板的可复用性。
• 可调项:

• 提示词模板:action_rules.R5.config.prompt_template = 现 REVERSE_SYSTEM_PROMPT 原文。
• 调试入口:/settings/rules/R5 → 喂一条真爆款,看逆出的模板变量粒度合不合适。
• 验证状态:🔴 理论。

R6 — 搜索抓取 / 过滤 / 排序(非 LLM 阈值规则)

• 挂在动作:anysearch_swipe_adapter.py 的 search() / _fetch_phrase() / _is_social_host() / _hit_to_raw_post()
• 为什么要规则化:每词搜几条、搜几个词、哪些域名算"社媒"、什么排前面、默认取哪种社媒榜——这些数字直接决定"找爆款"给你什么内容。名单漏了平台 = 好内容被丢;阈值太小 = 结果太少。
• 可调项(纯阈值/名单,无 prompt_template):

• 存储:action_rules.R6.config.knobs(config 无 prompt_template)。
• 调试入口:/settings/rules/R6 → 喂一组关键词,dryrun 不花 LLM 钱,看用当前阈值/名单过滤+排序后留下哪些帖子、分数怎么算。
• 验证状态:🔴 理论。
• ⚠️ 注意:max_results_cap 受 AnySearch 服务端硬顶约束,调高超过服务端上限无效——这是外部约束,试验台可调但需在 UI 提示"服务端可能夹回"。

R7 — 发布排期时段(非 LLM 阈值规则,新增)

• 挂在动作:domain/plan/schedule_algorithm.py:31 build_week_schedule / :60 _slots_for_platform,常量 :17 _WORK_DAYS=5、:18 _DEFAULT_HOUR=9 / API POST /api/plans(经 plan_use_case.py:23 GenerateWeekPlanUseCase)
• 为什么要规则化:"排周几、几点发、同一天多帖怎么错峰"直接决定内容触达时机。这是第一版漏掉的真度 —— 它当初被工程师焊成两个模块级常量(_WORK_DAYS=5/_DEFAULT_HOUR=9),改错不会崩(程序照排),但排到没人看的时段 = 内容白发,悄悄毁价值。Anderson 会想拿自己受众的活跃时段反复试。
• 可调项(纯阈值/时段,无 prompt_template):

• 存储:action_rules.R7.config.knobs(config 无 prompt_template)。
• 注意分工(层⑤劈分内的"度 vs 逻辑"再切):_ALLOWED_PLATFORMS / _ALLOWED_CONTENT_TYPES / image_video_ratio 必须 sum=1 这些是校验逻辑(改错会崩/对错二元),留代码常量,不进 R7 旋钮。R7 只收"排期时段"这三个真度。
• 调试入口:/settings/rules/R7 → dryrun 不花钱:传一组 platforms/counts + 当前 R7 config,返回排出来的 SlotSpec[](周几/几点),Anderson 看时段合不合自己受众活跃规律,并排对比改后新时段。
• 验证状态:🔴 理论。

3. 试验台(每条旋钮的调试闭环)

标准件真相源 docs/templates/test-bench.template.js + scripts/install-test-bench.sh。每条旋钮页 /settings/rules/<ruleId> 必须有:

1. 喂样本 — 粘贴/上传真实输入(R1/R3/R4/R5:产品素材;R2:一批帖子;R6:一组关键词;R7:一组 platforms+counts)。
2. 出结果 — 用当前 active 版本 config 跑一遍,展示输出。
3. 评 — Anderson 看:太泛?太严?改写太夸张?名单漏平台?排期时段不对?(可打分/标注)。
4. 调 — 直接改旋钮 / 改 prompt_template(不改代码、不重部署),再跑,并排对比新旧输出。
5. 存版本 — 满意就"存为当前生效版本",version 自增进历史,旧 active 归档,可回退。

治病点:现有工具"不好用"的根因 = 这 7 处度被写死且写不对、无调节入口。试验台就是把它们变成能试、能对比、能回退的旋钮。 花钱红线:R1–R5 dryrun 触发真 LLM 调用 = 花钱,复用 llm_guard(日成本/输入长度/max_tokens 三门)+ limiter + 每 tenant 每日 dryrun 上限;R6/R7 是纯阈值 dryrun,不花 LLM 钱(仍限流防刷)。详见 API-CONTRACT-RULES.md。

4. 层⑤对照(规则 = 设置 = 数据库一行)

刀切:R1–R7 旋钮 + 5 个提示词模板(R1/R2/R3/R4/R5)→ 进库 + 试验台。密钥/连接/花钱护栏 → 留 .env。两者不得混(见 ARCHITECTURE-RULES-LAYER.md §4)。 不进库的(留代码/.env):安全护栏(文件大小/MIME/magic bytes/批量上限/重试次数)、校验逻辑(week_start 必周一/ratio sum=1/枚举校验)、用户每请求可传的入参(配图 size/检索天数/分页)——这些不是"度",是逻辑或已可调。

5. 权限 + 状态

• 谁能改规则:action_rules.updated_by 服务端从登录态盖章(不信前端);带 tenant_id(当前单租户恒 "default",云端多租户时按租户过滤 + 非授权角色只读不能存版本)。"规则谁能调"本身是一条权限规则。
• 规则版本状态机:draft → testing → active → archived(回退时把旧版本改回 active、当前 active 归档)。落在 action_rules.status + version。同一 (rule_id, tenant_id) 只能一行 active,事务保证。

6. 与上一版(6 条)的差异

本次引用的 skills:cost-aware-llm-pipeline、context-budget、logic-first-ui、prompt-optimizer、database-migrations、architecture-decision-records、python-patterns