长期任务的上下文结构：为什么这样设计Context structure for long-running work: why it's built this way

这是「运行机制」那篇的前传：机制是怎么跑的，这里讲为什么要这么拆。案例是多渠道广告投放，方法适用于任何要跑几个月、每天有状态变化的 AI 任务。The prequel to "How the loop runs": that page shows the mechanics, this one explains the reasoning. The case is multi-channel paid media; the method applies to any AI-run task that lasts months and changes state daily.

01重构前的问题The problems before

通读了所有规则文件、操作记录和记忆之后，问题集中在八处。它们互相放大：规则越长越没人维护，越没人维护副本越多，副本越多漂移越快。After reading every rule file, log and memory, the problems clustered into eight. They compound: the longer the rules, the less they're maintained; the less maintained, the more copies; the more copies, the faster they drift.

02几个渠道其实是同一个循环Several channels, one loop

把各渠道的优化流程摆在一起：标的在哪、主判据、输出的第一张表、动作协议——完全一样。真正因渠道而异的只有两处：前端数据怎么拉，以及能动哪些设置。Laid side by side, every channel's optimization loop is identical: where the targets live, the primary metric, the first table in the output, the action protocol. Only two things vary by channel: how platform-side data is pulled, and which settings can be changed.

03分层原则Layering principles

常驻的越少越好，按需的越全越好。每一层只回答一个问题。Keep what's always loaded tiny and what's on demand complete. Each layer answers one question.

L0  根规则（≤90 行）          铁律 + 指针，每次会话加载
L1  任务通用规则（≤60 行）      循环 + 四条保证 + 渠道入口
L1  渠道规则（≤90 行）          能动的设置、特有红线、知识页索引
L2  state / todo / outcomes     hook 按需注入 ≤40 行
L3  wiki/ + 跨渠道结论          按需读；页头标 status: 已验证 | 部分推翻 | 存档
L4  ops.jsonl / 操作记录        流水，只在追因果时翻
L5  数据缓存 + 清单

• 快照与流水分离。状态覆盖写，流水只追加；日常只读状态，不读流水。Snapshot and log are separate. State is overwritten; the log is append-only; daily work reads state, not the log.
• 被推翻的结论不删，标状态。失败记录是资产，但要放在按需层，不能常驻。Overturned conclusions stay, labeled. Failures are assets — kept on the on-demand layer, never resident.
• 口径只有一处定义、一个实现。改口径改那一处，其余只引用；散文里不再出现公式。One definition and one implementation of every metric. Change it there; everything else references it; no formulas in prose.
• 规则文件超过 90 行就该拆。这条由脚本检查，不由人自觉。A rule file over 90 lines gets split. Enforced by script, not by discipline.

04用生命周期代替「任务」做组织单元Lifecycle, not "task", as the unit

长期跟的对象是一条条广告系列，不是「渠道」。它们有阶段，不同阶段该看的东西、该看的频率不一样。把阶段和下次检查日期写进快照，日常检查就从「固定看几条」变成「扫今天到期的」。What you actually track over months is individual campaigns, not "channels". They have stages, and each stage needs different checks at different cadences. Put stage and next-check date in the snapshot, and the daily check turns from "look at these fixed targets" into "scan whatever is due today".

05参考了哪些方案，哪些是自己推的What was borrowed, what was derived

06结果Result