在目标平台(goal_web)发布高质量内容的完整技能流程设计。用于:读取任务json与goal_prompt,拆解任务、执行任务引擎、开发与自检、结果回写与评分回写。触发词:修改目标、赢得目标、触发目标实现、触发{网站名称}任务实现。
---
name: 赢得目标
description: 在目标平台(goal_web)发布高质量内容的完整技能流程设计。用于:读取任务json与goal_prompt,拆解任务、执行任务引擎、开发与自检、结果回写与评分回写。触发词:修改目标、赢得目标、触发目标实现、触发{网站名称}任务实现。
---
# {goal_web} 内容发布 Skill(仅流程文档,无脚本)
> **变量说明**:`{goal_web}` 是全局目标平台变量,每次运行时从 `references/core_goal.json` 的 `goal_web` 字段读取,读取后注入本文档所有出现 `{goal_web}` 的位置。当前值由 core_goal.json 决定,本文档不硬编码任何平台名称。
## 目录结构(约定)
- `references/core_goal.json`:固定核心目标,每次启动 Step 1 时必须从此文件读取 `core_goal` / `core_flow` / `goal_web`,未经用户明确修改不得更改
- ~~`references/goal_prompt.md`~~:**已迁移至 `references/prompts/goal_prompt.md`,旧路径废弃**
- `references/prompts/`:**Prompt 专属目录**,所有 Prompt 文件统一存放于此
- `references/prompts/prompt_registry.md`:**Prompt 注册表**,Step 1 / Step 6 必须先查此表确定读取路径
- `references/prompts/meta_prompt.md`:**Lyra meta-Prompt**,生产任何新 Prompt 时必须先用此 Prompt 驱动生成,再用 authoring_guide 校验字段
- `references/prompts/prompt_authoring_guide.md`:**Prompt 撰写规范**,新建任何 Prompt 前必读,定义输入/输出字段硬性约束
- `references/prompts/goal_prompt.md`:通用任务拆解 Prompt(fallback)
- `references/prompts/retro_prompt.md`:通用复盘 Prompt(fallback)
- `references/technical-decision-reference.md`:开发方案决策参考,Step 3.1 必须读取
- `references/external-publishing-design-reference.md`:外部平台发布设计参考,涉及发布任务时必须读取
- `references/logging.md`:日志记录规范,每次执行必须遵循
- `references/script_registry.json`:脚本索引表(注册表),必须存在,允许写入脚本记录
- `references/step5_example.md`:Step 5 结果评分示例(参考用)
- `run/{date}/{batch_seq}/compressed_log.json`:**结构化压缩日志**(V2.0 新增),Step 4 每次执行后必须生成;Step 6 的 `{past_3_runs_logs}` 变量改读此文件,降低 Token 消耗
- `references/cron-design-reference.md`:**Cron 脚本设计规范,开发任何 cron 脚本前必须先读取本文件**
- `references/hook_config.json`:**Event-driven 自动运行配置表**,Step 0 启动时读取,控制一次触发自动跑几个 batch
- `tasks/`:**分平台任务 JSON 统一存放目录**(详见下方「任务文件命名规范」)
- `run/{date}/{batch_seq}/`:批次运行日志、retro_output 存放目录(仍保留,供日志归档)
---
## 任务文件命名规范(必须遵循)
所有任务 JSON 和复盘 JSON **统一存放在 `tasks/` 目录**,按以下规则命名:
| 文件类型 | 命名格式 | 示例 |
|---------|---------|------|
| 任务拆解 JSON | `{goal_web}_tasks_{batch_seq}.json` | `微博_tasks_001.json` |
| 复盘输出 JSON | `{goal_web}_retro_{batch_seq}.json` | `微博_retro_001.json` |
**说明**:
- `{goal_web}` = `core_goal.json` 中 `goal_web` 字段的实际值(如 `微博`、`脉脉`、`知乎`)
- `{batch_seq}` = 三位数字序号(如 `001`、`002`)
- 同一平台的任务和脚本隔离,不同平台之间绝对不互相读取
- 脚本注册表(`script_registry.json`)已含 `target_web` 字段,检索时**必须先过滤 `target_web == goal_web`**,只使用本平台的脚本
---
> 硬性约束
> - **开发 cron 定时脚本前,必须先读取 `references/cron-design-reference.md`**,按其规范开发,完成后在规范文件的「已有脚本清单」中追加记录
> - 若任务需要开发新脚本,必须先撰写"技术方案"
> - 必须基于"技术方案"进行开发
> - 允许并要求开发脚本以落地任务
> - 脚本索引表允许写入脚本记录,**禁止**清空
> - 禁止模拟数据:所有任务结果必须来自真实执行与真实平台反馈
> - 禁止询问人工帮助,即使失败了也会记录为失败数据,对下一轮仍有极大帮助
> - 所有涉及 `{goal_web}` 平台的浏览器操作,必须通过 attach 谷歌浏览器实例进行(Browser Relay),不得自行启动新浏览器
> - **【核心约束·最高优先级】必须自动化完成全流程,严禁向用户要求任何形式的人工介入(包括但不限于:请你打开页面、请你点击、请你 attach Tab、请你确认、请提供数据等)。若因环境缺失(Tab 未 attach、权限不足、网络异常等)导致任务无法完成,必须将该任务回写为 `task_state: "failed"`,`task_result` 中写明失败原因,继续执行后续任务,不得中断流程,不得等待人工处理。**
---
## 输入/输出规范
### 输入 JSON — 首批次(batch_seq = 001)
首次运行包含以下基础字段:
- `goal_web`:目标平台(从 core_goal.json 读取)
- `core_goal`:今日核心目标
- `core_flow`:(可为空/null)核心过程约束,与 `core_goal` 同级别。**非空时**描述任务必须遵循的执行流程或操作顺序;**为空/null 时**不影响任何流程,按正常逻辑执行
- `date`:今日日期(每次运行时读取)
- `batch_seq`:从 `001` 开始
### 输入 JSON — 续批次(batch_seq ≥ 002)
从第二批次起,上游 JSON 是 Step 6 复盘输出,额外包含以下字段,**Step 1 读取后必须透传给 Step 2 使用**:
- `workflow_status`:`continue_to_next_batch` 或 `goal_achieved`
- `retrospective_context`:上一批次的复盘摘要
- `next_batch_guidance`:对下一轮拆解和开发的约束指导(含 `blacklist`)
- `carry_over_tasks`:未完成或低分任务的结转列表
- `core_flow`:(可为空/null)同首批次,从上一批次 retro 或 core_goal.json 继承透传
> 若 `workflow_status = goal_achieved`,终止工作流,输出完成报告。
### Prompt 文件(通过注册表查找)
- Step 1 / Step 6 均使用 **Prompt 注册表查找机制**(详见下方「Prompt 查找规则」)
- 注册表路径:`references/prompts/prompt_registry.md`
- 通用 fallback:`references/prompts/goal_prompt.md`(任务拆解)/ `references/prompts/retro_prompt.md`(复盘)
### 输出 JSON(任务拆解结果)
在输入字段基础上新增:
- `task_id`:按优先级排序,从 1 开始
- `task`:任务名
- `task_description`:任务描述
- `task_reason`:为什么有利于实现 `core_goal`
- `depends_on`:**(V2.0 新增)** 前置任务 ID 列表,空数组 `[]` 表示无依赖,可立即执行;非空时必须等所有前置任务 `task_state = done` 才能执行
- `task_state`:`done | pending | failed | blocked`
- `pending`:尚未执行(含「就绪待调度」)
- `done`:任务目标达成
- `failed`:任务目标未达成(含脚本报错、外部拦截、超时等一切失败情形,回写原因后立即进入 Step 5)
- `blocked`:**(V2.0 新增)** 前置任务 failed,本任务自动标记为 blocked,跳过执行,直接交由 Step 6 复盘处理
- `task_result`:初始为 `null`
- `source`:**(V2.0 新增)** 脚本来源标记,`registry`(从注册表召回)或 `new`(本批次新开发),Step 5 OB 老化降级依赖此字段
---
## 主任务文件 vs 分支任务文件
| 概念 | 文件 | 职责 |
|------|------|------|
| **主任务文件** | `tasks/master_task.json` | 每次运行的上下文快照:runtime_goal_web、runtime_core_goal、触发来源、从分支任务合并的上下文 |
| **分支任务文件** | `tasks/{goal_web}_tasks_{batch_seq}.json` | 某平台某批次的任务拆解与执行结果(历史档案) |
| **分支复盘文件** | `tasks/{goal_web}_retro_{batch_seq}.json` | 某平台某批次的复盘输出,供下一批次 Step 1 读取 |
**合并优先级**(高优先级覆盖低优先级):
```
用户输入(当次触发)> core_goal.json > 分支任务历史数据(retro)
```
---
## 执行总流程(必须严格遵循)
### 日志记录规范(必须遵循)
- 读取并遵循 `references/logging.md`
- 每次完整执行必须生成主日志文件,命名:`运行日志_{date}_{batch_seq}.md`
---
### 0) 触发解析(每次 Skill 启动的第一步)
**目标**:从用户输入中解析出意图类型(**Prompt 生产** 或 **批次任务执行**),分别进入对应流程。
#### 意图识别(最优先判断)
```
用户触发 Skill
↓
Step 0.0:识别意图类型
├── 意图 = Prompt 生产
│ 触发词:「撰写/生成/写/创建 + Prompt + 平台名」
│ 或:「帮我写 {goal_web} 的复盘Prompt / 任务拆解Prompt」
│ → 跳转至「Prompt 生产流程」(见下方独立章节),不进入批次任务流程
│
└── 意图 = 批次任务执行(默认)
→ 继续 Step 0.1:解析 goal_web 和 core_goal(原有逻辑不变)
```
---
#### 解析流程(批次任务执行,原有逻辑不变)
```
用户触发 Skill
↓
Step 0.1:解析用户输入,尝试识别 goal_web 和 core_goal
├── 情况一:仅解析出 goal_web(无 core_goal)
│ → 从 tasks/{goal_web}_retro_* 读取最新 core_goal
│ → 分支任务提供全部上下文(retro/blacklist/carry_over 等)
│
├── 情况二:同时解析出 goal_web + core_goal
│ → runtime_core_goal = 用户输入值(覆盖 core_goal.json 和历史 retro)
│ → 分支任务仅提供历史上下文(batch_seq/retro/blacklist/carry_over),不提供 core_goal
│
└── 情况三:解析不出 goal_web
→ 检查 tasks/ 目录下有几个平台的历史文件
│ ├── 仅一个平台 → 提示用户:「检测到只有 {X} 的任务记录,是否触发 {X} 任务?」
│ └── 多个平台 / 无历史 → 询问用户:「请问要对哪个平台执行任务?」
→ 等待用户确认后,重新走情况一或情况二
```
#### goal_web 识别规则
优先按以下顺序识别:
1. 用户明确提到平台名(微博、脉脉、知乎、Producthunt、Twitter 等)
2. 用户消息含 `goal_web=xxx` 或 `web=xxx` 等参数格式
3. `core_goal.json` 中的 `goal_web` 值(作为兜底默认值,非强制)
#### core_goal 识别规则
1. 用户明确说「目标是…」「core_goal=…」「goal=…」→ 使用用户值
2. 用户未提供 → 从 `tasks/{goal_web}_retro_*` 最新文件读取
3. 无历史 retro → 从 `core_goal.json` 读取
#### core_flow 识别规则
1. 用户明确说「流程是…」「core_flow=…」「必须按…流程」→ 使用用户值
2. 用户未提供 → 从 `tasks/{goal_web}_retro_*` 最新文件的 `core_flow` 字段读取(若有)
3. 无历史 retro 或字段为空 → 从 `core_goal.json`(或分支 `core_goal_{goal_web}.json`)读取 `core_flow` 字段
4. 以上来源均为空/null → `runtime_core_flow = null`,跳过所有 core_flow 相关流程约束,无任何影响
#### Step 0.2:读取 hook_config.json,初始化 auto_run
在生成 `master_task.json` 之前,**必须**读取 `references/hook_config.json`:
```
读取 hook_config.json
→ 查找 platforms[goal_web].auto_runs
→ 未找到则使用 default_auto_runs(默认 1)
→ 将 auto_runs 写入 master_task.json 的 auto_run 字段
```
**仅用户首次触发时初始化**(`trigger_source = user_message` 或 `cron`)。
自动触发下一批次时(`trigger_source = auto_hook`),`auto_run.remaining` 直接从上一个 master_task.json 继承并递减,**不重新读取 hook_config**(避免重置计数器)。
**(V2.1 新增)`meta_optimization` 初始化规则**:
- 用户首次触发时:检查上一个 master_task.json 是否已有 `branch_context.meta_optimization` 字段
- 有 → 直接继承(`batches_since_last_opt` 和 `prompt_iteration_seq` 均继承,不重置)
- 无(全新平台)→ 初始化为 `{"prompt_iteration_seq": "000", "batches_since_last_opt": 0}`
- 跨平台切换时(goal_web 变更):`meta_optimization` 随 goal_web 独立维护,不互相干扰
#### 输出:master_task.json
每次触发后,将解析结果写入 `tasks/master_task.json`:
```json
{
"trigger_time": "2026-03-17T18:53:00",
"trigger_source": "user_message",
"runtime_goal_web": "Producthunt",
"runtime_core_goal": "获取Producthunt每日和近一周的核心AI产品,并介绍产品价值,输出报告。",
"context_source": {
"goal_web_from": "user_input",
"core_goal_from": "branch_retro",
"branch_retro_file": "tasks/Producthunt_retro_001.json"
},
"branch_context": {
"last_batch_seq": "001",
"next_batch_seq": "002",
"next_batch_guidance": {},
"carry_over_tasks": [],
"blacklist": [],
"meta_optimization": {
"prompt_iteration_seq": "000",
"batches_since_last_opt": 0
}
},
"auto_run": {
"total": 1,
"remaining": 1,
"current_run": 1
}
}
```
> **字段说明**
> - `runtime_core_flow`:(可为空/null)过程约束字段,从 core_goal.json 或上一批次 retro 读取后注入。**非空时**:Step 2 必须将其作为硬性过程约束注入任务拆解(每个 task 须注明 `flow_step` 对应哪一环节);Step 4 执行后校验每个 task 是否遵从流程(写入 `flow_compliant: true/false`);Step 6 复盘输出中必须新增 `flow_violations` 字段记录违反情况及归因。**为空/null 时**:跳过上述所有检查,不影响正常流程。
> - `trigger_source`:`user_message` / `cron` / `auto_hook`(自动连续运行时)
> - `context_source`:记录每个字段的来源,便于调试
> - `branch_context`:从分支复盘文件提取的历史上下文,传递给 Step 1
> - `auto_run.total`:本次触发的总批次数(从 hook_config 读取)
> - `auto_run.remaining`:剩余还需运行的批次数(每完成一个 batch 减 1)
> - `auto_run.current_run`:当前是第几次自动运行(从 1 开始)
> - `branch_context.meta_optimization`:**(V2.1 新增)元学习进化计时器**,每个 goal_web 平台独立维护
> - `prompt_iteration_seq`:当前使用的 Prompt 版本号(`000` = 原始版,`001` = 第一次进化后,依此类推)
> - `batches_since_last_opt`:上次进化后完成的批次数,每次 Step 6 末尾 +1;达到 10 时触发 Step 6.5 元学习进化流并清零
---
### 1) 读取输入
> Step 0 已完成触发解析并写入 `tasks/master_task.json`,Step 1 直接从该文件读取运行时上下文。
1. 读取 `tasks/master_task.json`,获取:
- `runtime_goal_web` → 本批次 `goal_web`(全局变量,注入所有后续步骤)
- `runtime_core_goal` → 本批次 `core_goal`
- `runtime_core_flow` → 本批次 `core_flow`(可为空/null;非空时作为硬性过程约束贯穿后续全部步骤)
- `branch_context` → 历史上下文(`next_batch_seq` / `next_batch_guidance` / `carry_over_tasks` / `blacklist`)
- **合并优先级再次确认**:master_task.json 已按「用户输入 > core_goal.json > 分支历史」合并,Step 1 直接使用,不再重新读取 core_goal.json
2. 从 `branch_context.next_batch_seq` 确定本批次序号:
- 有值 → 使用该值
- 无值(首批次)→ 强制 `001`,严禁继承其他平台序号
3. **读取 goal_prompt(通过注册表查找)**:
```
读取 references/prompts/prompt_registry.md
→ 查找 type=任务拆解 AND web={goal_web} 的记录
→ 找到 → 读取该记录 path 指向的 Prompt 文件
→ 未找到 → fallback:读取 references/prompts/goal_prompt.md
```
4. **若 `branch_context` 含 `next_batch_guidance`**:提取约束条件和 `blacklist`,暂存备用(Step 2 和 Step 3 使用)
5. **若 `branch_context.workflow_status = goal_achieved`**:终止,输出完成报告,不再继续
---
### 2) 任务拆解(基于 goal_prompt)
1. **若上游 JSON 含 `carry_over_tasks`**:优先将结转任务纳入本批次拆解(保留原 task_id,补充调整策略)
2. **若上游 JSON 含 `next_batch_guidance`**:拆解前先读取其中 `task_breakdown_advice` 和 `development_constraints`,将其作为硬性约束应用于本批次任务设计
3. **【core_flow 约束注入(非空时必须执行)】**:
- 若 `runtime_core_flow` 非空:将 `core_flow` 描述的流程步骤作为**硬性过程约束**注入任务拆解:
- 每个 task 必须对应 `core_flow` 中的某个流程环节,在 task 字段中新增 `"flow_step": "对应的流程环节名称"`
- 拆解出的任务顺序、依赖关系必须与 `core_flow` 描述的流程顺序严格一致,不得跳步或乱序
- 若某个 `core_flow` 流程环节在本批次无法执行,需显式拆解为一个 `task_state: "blocked"` 的占位任务,写明原因
- 若 `runtime_core_flow` 为空/null:跳过此步骤,按正常 `core_goal` 拆解逻辑执行
4. 使用上一步查找到的 `goal_prompt`(专属版或 fallback 通用版)对 `core_goal` 进行拆解,输出新的任务 JSON
5. 保持:`goal_web / core_goal / core_flow / date / batch_seq` 与上游一致
6. 任务描述中涉及平台操作时,用实际 `goal_web` 值替换 `{goal_web}`
7. **(V2.0 新增)DAG 依赖图谱**:为每个任务输出 `depends_on` 字段:
- 无前置依赖的任务:`"depends_on": []`
- 有前置依赖的任务:`"depends_on": [task_id_1, task_id_2]`
- 示例:数据采集任务(task_id=1)无依赖;报告生成任务(task_id=2)依赖采集任务 → `"depends_on": [1]`
- 拆解时优先设计「可并发执行的任务对」,相互无依赖的任务 `depends_on` 均为 `[]`
7. **任务 JSON 保存路径**:`tasks/{goal_web}_tasks_{batch_seq}.json`(例:`tasks/微博_tasks_002.json`)
---
### 3) 任务执行引擎
1. 从任务 JSON 中按顺序找到第一个 `task_state = pending` 的任务
2. 从 `task` 与 `task_description` 中提炼搜索 query(query 中用 `goal_web` 实际值)
3. 在脚本注册表中检索 `script_description`(仅限 `score >= 0.8`)
- **平台过滤(首要条件)**:只检索 `target_web == goal_web` 的记录,其他平台的脚本一律忽略
- **安全校验(黑名单过滤)**:若上游 JSON 的 `next_batch_guidance.blacklist` 不为空,必须排除其中的脚本路径,即使 score >= 0.8 也不得使用
- 检索结果为空或 score < 0.8 → 进入 OB 召回
4. OB 召回:
- 进入 OB 召回流程,召回文档时优先检索与 `{goal_web}` 平台相关的文档
- 阅读文档并进行置信度评分(0-1)
- 置信度 >= 0.8:可作为开发参考
- 否则:进入开发流程
5. 若无任何参考文档:直接进入开发流程
---
### 3.2) 沙盒预检(静态检查 + 局部自愈)【V2.0 新增,在 3.1 之后、Step 4 之前执行】
> **目标**:拦截低级代码错误,避免浪费真实执行环境和复盘周期。
**触发条件**:Step 3.1 新开发的脚本写入路径后,进入本步骤。从注册表直接召回的脚本(`source = registry`)跳过本步骤(已验证过)。
**执行流程**:
```
Step 3.1 新脚本写入
↓
Step 3.2:静态语法检查
├── Python 脚本 → exec: python3 -m py_compile <script_path>
│ 返回码 = 0 → 通过,写入 task_script,进入 Step 4
│ 返回码 ≠ 0 → 截获 stderr,进入局部自愈循环
│
└── Shell 脚本 → exec: bash -n <script_path>
返回码 = 0 → 通过
返回码 ≠ 0 → 进入局部自愈循环
```
**局部自愈循环**(最多重试 3 次,超限则标记任务 failed):
1. 将原脚本内容 + stderr 报错信息 提交给 LLM(当前 AI 上下文)进行修复
2. 重新写入脚本文件
3. 再次执行静态检查
4. 通过 → 写入 task_script,进入 Step 4
5. 第 3 次仍失败 → 将任务 `task_state = failed`,`task_result` 写入「沙盒预检失败,3 次自愈均未通过,报错:{stderr}」,进入 Step 5 评分
**放行条件**:只有通过静态检查的脚本路径,才允许写入任务 JSON 的 `task_script` 字段,进入 Step 4 真实执行。
---
### 3.1) 开发流程(技术方案 → 脚本)
1. 进入开发前**必须读取**:`references/technical-decision-reference.md`
2. 若任务涉及"发布/外部平台发布",额外**必须读取**:`references/external-publishing-design-reference.md`
3. 若上游含 `next_batch_guidance.development_constraints`,**必须**将其作为约束条件纳入技术方案
4. 基于任务与参考内容,撰写技术方案:
- 命名:`技术方案_v{版本号}_{date}.md`
- 包含:业务目标 / 技术目标 / 约束(含 `{goal_web}` 平台特性)/ 三方案(A快 / B平衡 / C理想)/ 决策与取舍
- **平台约束**:`{goal_web}` 平台操作必须通过 attach 谷歌浏览器实例(Browser Relay),脚本中使用 `get_relay_ws_url()` 获取连接
5. 按技术方案进行开发,生成可执行脚本(Python/Bash 等)
6. 自检:确认脚本逻辑与技术方案一致
7. 将脚本写入脚本注册表,**必须包含以下全部字段**:`name`、`path`、`script_description`、`score`、`score_reason`、`target_web`(填写当前 `goal_web` 实际值,不得留空)
8. 更新任务 JSON,在对应任务下新增字段:
- `task_script_seq`:脚本序号(数组)
- `task_script`:脚本路径(数组,与 seq 一一对应)
---
### 4) 记录执行结果(V2.0:并发调度 + 双轨日志)
#### 4.1 并发调度(DAG 执行器)
```
扫描任务 JSON,建立就绪队列:
就绪条件:task_state = "pending" AND(depends_on = [] OR 所有前置任务 task_state = "done")
↓
将就绪队列中的任务并发执行(同一批扫描周期内同时拉起)
↓
某任务执行完毕(done/failed)→ 立即回写 task_state 和 task_result
↓
重新扫描就绪队列(前置任务 done 后,其后继任务解锁为就绪态)
↓
重复,直到无 pending 任务
```
**blocked 标记规则**:若某任务的前置任务 `task_state = failed`,则该任务 `task_state → blocked`,`task_result = "前置任务 {task_id} 失败,本任务跳过执行"`,不进入执行队列,直接进入 Step 5 评分。
#### 4.2 执行与回写
1. 读取任务 JSON,按并发调度逻辑执行
2. 无论执行结果如何,立即将结果回写至 `tasks/{goal_web}_tasks_{batch_seq}.json` 的 `task_result`,**不得留空、不得等待外部条件**
2.5. **【core_flow 合规校验(非空时必须执行)】**:若 `runtime_core_flow` 非空,每个 task 执行完毕后,额外回写字段:
- `flow_compliant: true`:该任务的执行路径符合 `core_flow` 中对应流程环节的要求
- `flow_compliant: false`:执行路径偏离了 `core_flow` 约束(需在 `task_result` 中写明具体偏离点)
- `flow_compliant: null`:`runtime_core_flow` 为空,跳过校验
3. 根据执行结果更新 `task_state`(**非此即彼,无中间态**):
- 任务目标达成 → `done`
- 任务目标未达成(无论何种原因)→ `failed`,`task_result` 中写明失败现象与原因
- 前置任务 failed → `blocked`
#### 4.3 双轨日志生成(V2.0 新增)
每次 batch 所有任务执行完毕后,**必须同时生成两份产物**:
**轨道 A:完整 Markdown 日志**(人类审计/归档用,原有逻辑不变)
- 路径:`run/{date}/{batch_seq}/运行日志_{date}_{batch_seq}.md`
**轨道 B:结构化压缩日志**(Step 6 复盘专用,V2.0 新增)
- 路径:`run/{date}/{batch_seq}/compressed_log.json`
- 内容结构:
```json
{
"batch_seq": "008",
"goal_web": "Producthunt",
"date": "2026-03-21",
"task_summary": [
{
"task_id": 1,
"task": "任务名称",
"task_state": "done",
"source": "registry",
"script_score": 0.95,
"action_sequence": ["读取配置", "调用 API", "生成报告", "推送飞书"],
"error_trace": null
},
{
"task_id": 2,
"task": "任务名称",
"task_state": "failed",
"source": "new",
"script_score": 0.4,
"action_sequence": ["读取配置", "调用 API"],
"error_trace": "TypeError: NoneType has no attribute 'get' at line 42"
}
],
"batch_outcome": "partial_success",
"top_error": "TypeError: NoneType has no attribute 'get'"
}
```
- **提取规则**:
- `action_sequence`:从完整日志中提取关键动作序列(3-8 个动作词,如「打开网页 → 定位输入框 → 点击按钮」)
- `error_trace`:只保留最底层 Exception 类型 + 报错所在行,过滤掉环境变量打印等无关输出
- `batch_outcome`:`all_done`(全部成功)/ `partial_success`(部分成功)/ `all_failed`
> **流程铁律**
> - 失败即回写:脚本执行产生任何结果(含报错、超时、页面拦截),立即回写 `task_result = failed`,**不降级、不重试、不等待**
> - 单任务 failed 不阻断流程:`task_state = failed` 后直接进入 Step 5 评分
> - 失败原因交由 Step 6 复盘处理,由下一批次的 `carry_over_tasks` 承接重试策略
> - **compressed_log.json 必须在所有 task 回写完成后才生成**,不得提前
#### on_batch_complete 钩子(Step 4 所有 task 回写完成后触发)
```
所有 task task_state 均已回写(done/failed/blocked)
↓
【不再因 failed 停止】失败状态已在 Step 4 执行时回写至 task_result(含失败原因+操作路径),
Step 6 复盘将统一读取所有任务状态(包含 failed)进行归因分析,生成 carry_over_tasks 和 blacklist。
↓
直接读取 master_task.json 的 auto_run.remaining:
remaining <= 0?
→ 终止,向用户输出完成摘要(含本批次 failed 任务列表)
remaining > 0?
→ remaining -= 1,current_run += 1,写回 master_task.json
→ 自动执行 Step 5(评分)→ Step 6(复盘),生成 retro 文件
→ 更新 master_task.json:
trigger_source = "auto_hook"
batch_seq 递增(如 007 → 008)
→ 自动跳回 Step 1,开始下一个 batch
→ 不等待用户确认
```
> **设计原则**:失败是数据,不是中断信号。任何 task 失败只会在 task_result 中留下记录(失败原因、操作路径、错误信息),流程继续向前推进至 Step 6 复盘。复盘负责归因、生成修正指导,下一批次基于此重试。**严禁因单个 task 失败而停止整个工作流。**
**静默运行原则**:自动连续 batch 期间,每完成一个 batch 发送一条简短通知(含已完成/失败任务数量),不等待用户回复,直接开始下一个 batch。
**强制停止**:用户任意时刻说「停止」→ 将 `master_task.json` 的 `auto_run.remaining` 设为 0,当前 batch 完成后不再继续。
---
### 5) 结果评分 + 核心目标校验(V2.0:新增 OB 老化降级)
1. 读取任务 JSON,遍历所有任务:
- `task_state = blocked`:跳过,不参与评分
- `task_state = failed`:**不跳过,直接记录评分结果**,`script_score = 0`,`score_reason` 写入失败原因摘要(从 `task_result` 提取),交由 Step 6 复盘处理;**不因 failed 中止 Step 5 流程**
- `task_state = done` 且 `task_result` 非空:正常评分
2. 对 `done` 任务打分(`script_score` 0~1,0.8 及格)并记录 `score_reason`
- **绝对红线**:`task_result` 含 `Error/Exception/Traceback` → score 上限 0.5
- **绝对红线**:`task_result` 为空或关键字段缺失 → score 上限 0.7
3. **注册表回写机制**:若 `script_score < 0.8`,必须同步将该评分回写至脚本注册表,强制覆盖或降低全局 score,防止该失败脚本下一轮被误选;**回写时同样必须确保 `target_web` 字段已填写(填写当前 `goal_web` 实际值)**
4. **(V2.0 新增)OB 脚本老化降级机制**:
- 触发条件:该任务的 `source = registry`(从注册表召回)且 `script_score < 0.8`
- 触发后执行以下两步:
1. **降低权重**:在 `script_registry.json` 中找到对应记录,将 `score` 强制下调(基准:旧 score × 0.7,最低降至 0.3),`score_reason` 追加 `「[{date}] 召回执行失败,权重自动降级,需人工审查」`
2. **追加老化标签**:在该记录中新增 `"tags": ["needs_update", "deprecated_by_{date}"]` 字段(若已有 tags 则追加,不覆盖)
- 效果:下一轮 Step 3 检索时,该脚本因 score < 0.8 而被过滤,强制进入重新开发(Step 3.1)流程
- 不触发条件:`source = new`(本批次新开发的脚本失败,只做常规注册表 score 回写,不走老化流程)
5. 核心目标校验:
- 评估已完成任务集合是否足以达成 `core_goal`
- 若不足:列出欠缺任务清单,追加回任务列表(`task_state = pending`,`task_result = null`),回到 Step 2
> 示例见:`references/step5_example.md`
---
### 6) 全局复盘与下一批次输入生成
> **必须通过 Prompt 注册表查找**复盘 Prompt,禁止自行简化或替换。
1. **读取 retro_prompt(通过注册表查找)**:
```
读取 references/prompts/prompt_registry.md
→ 查找 type=复盘 AND web={goal_web} 的记录
→ 找到 → 读取该记录 path 指向的 Prompt 文件
→ 未找到 → fallback:读取 references/prompts/retro_prompt.md
```
2. 填充三个输入变量:
- `{current_task_json}`:当前批次最终任务 JSON(含 `task_state` / `task_result` / `script_score` / `score_reason`)
- `{current_run_log}`:当前批次完整运行日志(读取 `run/{date}/{batch_seq}/运行日志_*.md`)
- `{past_3_runs_logs}`:**(V2.0 变更)** 不再读取原生 .md 日志,改读过去 3 个批次的 `compressed_log.json`(路径:`run/*/*/compressed_log.json`,按 batch_seq 倒序取最近 3 个);若 compressed_log.json 不存在则 fallback 到原生 .md 日志
3. 执行复盘 Prompt(已通过注册表加载),按 Prompt 模板规则分析:
- 现状评估:提取失败任务,定位根本原因
- 历史模式识别:检查死循环,若命中则强制要求下一轮改变技术路线
- 构建下一批次输入:步进 `batch_seq`,继承/细化 `core_goal`,生成 `blacklist` 与 `next_batch_guidance`,打包结转任务
4. 输出严格合法的 JSON,字段必须包含:
- `batch_seq` / `goal_web` / `core_goal` / `workflow_status`
- `core_flow`:**必须透传**,与上游保持一致(null 时写 null,非空时原样透传,不得丢失)
- `retrospective_context`(`failed_tasks_summary` / `historical_patterns` / `lessons_learned`)
- `next_batch_guidance`(`task_breakdown_advice` / `development_constraints` / `avoid_pitfalls` / **`blacklist`**)
- `carry_over_tasks`
- `flow_violations`:**【core_flow 非空时必须输出,为空/null 时省略】** 记录本批次中 `flow_compliant = false` 的任务列表,格式:
```json
"flow_violations": [
{
"task_id": 2,
"task": "任务名",
"expected_flow_step": "core_flow 中要求的流程环节",
"actual_behavior": "实际执行时偏离的具体描述",
"root_cause": "偏离原因分析",
"fix_suggestion": "下一批次如何修正"
}
]
```
若本批次无违反(所有 `flow_compliant = true`):写 `"flow_violations": []`
- `user_feedback`(详见下方规范,**若本批次有用户反馈则必须写入,无则省略该字段**)
- **禁止输出任何 JSON 以外的文字或 Markdown**
#### user_feedback 字段规范
**触发条件**:用户说「把以下反馈写入 {goal_web}」/ 「加入反馈」/ 「写入用户反馈」等。
**写入目标**:当前批次的 retro 文件(`tasks/{goal_web}_retro_{batch_seq}.json`),**只写当期,不累积**。
**字段格式**:
```json
"user_feedback": {
"priority": "HIGH",
"date": "YYYY-MM-DD",
"feedback": [
"用户反馈内容1",
"用户反馈内容2"
]
}
```
**字段说明**:
- `priority`:固定为 `HIGH`,无论内容如何,用户反馈永远最高优先级
- `date`:写入日期(当天)
- `feedback`:用户反馈条目数组,逐条写入,不合并、不改写原意
**下一批次读取机制**:
Step 1 读取 `branch_context` 时,若上一批次 retro 文件含 `user_feedback` 字段,**必须**:
1. 提取 `user_feedback.feedback` 数组
2. 在 Step 2 任务拆解时,将每一条 feedback 转化为显式约束或 task,优先级高于 `next_batch_guidance`
3. 在 master_task.json 的 `branch_context` 中透传 `user_feedback`,直到该批次任务全部完成为止
5. **复盘 JSON 保存路径**:
- 主路径(Step 1 读取上游用):`tasks/{goal_web}_retro_{batch_seq}.json`(例:`tasks/微博_retro_001.json`)
- 归档路径(日志用):`run/{date}/{batch_seq}/retro_output.json`(同时写入,保持日志完整性)
6. **(V2.1 新增)元学习计数器更新**:retro JSON 写入完成后,立即更新 `tasks/master_task.json` 的 `branch_context.meta_optimization`:
- `batches_since_last_opt += 1`
- 若 `batches_since_last_opt < 10`:继续正常流程,进入 Step 7 → 下一 Batch
- 若 `batches_since_last_opt == 10`:**冻结引擎**,不进入下一 Batch,切入 **Step 6.5 元学习进化流**
7. 将输出 JSON 直接作为下一批次 **Step 1 读取输入** 的上游 JSON,自动触发下一轮工作流
---
### 6.5) 元学习进化流(Meta-Learning Evolution)【V2.1 新增,triggered when batches_since_last_opt == 10】
> **目标**:在完成 10 个批次后,自动审视失败模式,重写底层拆解/复盘 Prompt,实现系统方法论的版本迭代。
> **事件驱动**:由 Step 6 末尾的计数器检查触发,非 Cron,无竞态冲突风险。
#### 6.5.1 提取诊断上下文(防 Token 膨胀)
向上追溯,读取过去 **5 个批次**的 retro 文件(`tasks/{goal_web}_retro_*.json`,取最近 5 个):
只提取以下两个字段:
- `retrospective_context.historical_patterns`
- `retrospective_context.lessons_learned`
将提取结果合并,生成一段《平台演进与系统瓶颈诊断报告》,格式:
```
【{goal_web} 平台近5批次诊断报告】
历史死循环模式:
- [来自各批次 historical_patterns 的去重合并]
核心教训:
- [来自各批次 lessons_learned 的去重合并]
高频失败根因:
- [出现 ≥ 2 次的失败类型,按频率排序]
```
#### 6.5.2 确定当前 Prompt 版本
从 `tasks/master_task.json` 读取 `branch_context.meta_optimization.prompt_iteration_seq`(如 `000`)。
从 `references/prompts/prompt_registry.md` 查找当前 `goal_web` 平台使用的 Prompt 文件路径:
- `type=任务拆解` → 当前 goal_prompt 路径
- `type=复盘` → 当前 retro_prompt 路径
读取这两个文件的完整内容,作为「待升级的当前 Prompt」。
#### 6.5.3 调用 meta_prompt 重写 Prompt(认知升级)
读取 `references/prompts/meta_prompt.md`,以其为角色框架,组装以下输入:
```
输入一:《平台演进与系统瓶颈诊断报告》(6.5.1 生成)
输入二:当前 goal_prompt 全文
输入三:当前 retro_prompt 全文
输入四:references/prompts/prompt_authoring_guide.md 中的字段规范(Schema 约束)
系统指令:
你是一个高级 Prompt 架构师,专为 {goal_web} 平台服务。
请审视这 5 轮的失败教训和死循环模式,找出当前拆解 Prompt 和复盘 Prompt 的思维盲区。
重写这两个 Prompt,强制加入针对上述失败模式的约束条款,提升对该平台规则变动和反爬机制的适应力。
输出格式必须完全遵循 prompt_authoring_guide.md 的字段规范,不得引入新字段或删除必填字段。
```
生成两份新 Prompt 全文:`new_goal_prompt` 和 `new_retro_prompt`。
#### 6.5.4 版本控制:另存为新版本(禁止覆盖)
计算新版本号:`new_seq = prompt_iteration_seq + 1`(格式三位数字,如 `001`)
**写入两个新文件**(不覆盖旧文件):
- `references/prompts/goal_prompt_{goal_web}_v{new_seq}.md` ← 新 goal_prompt 内容
- `references/prompts/retro_prompt_{goal_web}_v{new_seq}.md` ← 新 retro_prompt 内容
**更新注册表** `references/prompts/prompt_registry.md`:
- 找到 `type=任务拆解 AND web={goal_web}` 的行 → 将 `path` 更新为新文件路径,在描述末尾追加 `[v{new_seq} auto-evolved {date}]`
- 找到 `type=复盘 AND web={goal_web}` 的行 → 同上
若注册表中无该平台记录(首次为该平台生成专属 Prompt)→ 追加新行。
#### 6.5.5 重置计数器 + 进化完成通知
更新 `tasks/master_task.json`:
```json
"meta_optimization": {
"prompt_iteration_seq": "{new_seq}",
"batches_since_last_opt": 0
}
```
向用户发送一条进化完成通知(不中断后续流程):
```
🧬 {goal_web} Prompt 进化完成!
版本:v{old_seq} → v{new_seq}
核心改进:[用1-2句话总结本次重写的主要变更点]
旧版本保留在 references/prompts/ 可随时回滚
```
进化完成后,自动进入 Step 7(成功经验入库),然后继续正常的下一 Batch 流程。
#### 6.5.6 回滚机制
若下一批次执行后发现 Prompt 进化导致任务 JSON 解析严重失败(连续 2 个批次全部 failed),在 retro 的 `next_batch_guidance.development_constraints` 中加入:
```
Prompt 回滚指令:将 prompt_registry.md 中 {goal_web} 的 path 指针从 v{new_seq} 改回 v{old_seq},
并将 master_task.json 的 prompt_iteration_seq 回滚为 {old_seq}。
```
---
### 7) 成功经验入库(Knowledge Ingestion)【V2.0 新增,在 Step 6 之后执行】
> **目标**:将高分成功路径固化为标准知识写入脚本注册表,充实知识飞轮,避免未来重复开发同类脚本。
**触发条件**:Step 6 复盘完成后,自动进入 Step 7(不需要用户触发)。
#### 7.1 筛选候选任务
从当前批次任务 JSON 中筛出满足以下全部条件的任务:
- `task_state = done`
- `script_score >= 0.8`
- `source = new`(本批次全新开发,非从注册表召回)
若无满足条件的任务 → Step 7 静默跳过,不写任何文件。
#### 7.2 长期价值评估
对每个候选任务,用以下微型 Prompt 判断其通用价值:
```
该任务路径是否满足以下条件(Yes/No/Partial):
1. 解法不依赖特定日期/特定数据,未来同类任务可复用?
2. 核心逻辑对同平台({goal_web})其他批次有参考价值?
3. 与注册表已有脚本无高度重叠(相似度 < 80%)?
全部 Yes → 入库
任一 No → 跳过(记录原因)
```
#### 7.3 写入脚本注册表
满足条件的脚本,更新 `references/script_registry.json` 中对应记录,补充以下字段:
- `ingested_at`:入库日期(`YYYY-MM-DD`)
- `ingestion_reason`:入库理由(1句话,为什么认为可复用)
- `tags`:追加 `["verified", "batch_{batch_seq}"]`
> **约束**:Step 7 不产生任何新文件,只更新 `script_registry.json` 已有记录或追加新记录(若该脚本尚未注册)。注册表是唯一写入目标。
#### 7.4 Step 7 完成日志
在当前批次的 `compressed_log.json` 中追加字段:
```json
"step7_ingestion": {
"candidates": 2,
"ingested": 1,
"skipped": 1,
"skip_reason": "与已有脚本 auto_ph.py 重叠度 > 80%"
}
```
---
## Prompt 生产流程(独立章节,不干扰批次任务流程)
> 触发条件:Step 0.0 识别到意图 = Prompt 生产
### P1)确认生产参数
从用户输入提取:
- `prompt_type`:`任务拆解` 或 `复盘`
- `goal_web`:目标平台(如 `同花顺`、`东方财富`)
若任一字段缺失,询问用户后继续,不擅自猜测。
---
### P2)读取上下文(欠缺2修复)
自动收集生产所需的上下文,**不需要用户手动提供**:
```
读取 references/prompts/prompt_authoring_guide.md
→ 提取对应 prompt_type 的输入字段规范 + 输出字段规范(作为硬性 Schema)
读取 references/core_goal.json
→ 提取 goal_web 对应的 core_goal(作为业务背景)
读取最近 3 个 tasks/{goal_web}_retro_*.json
→ 提取 lessons_learned / historical_patterns / 平台特有约束
→ 作为「平台专属 Prompt 约束」注入 Lyra 的 USER INPUT
```
---
### P3)调用 meta_prompt 生产 Prompt 正文
以 `references/prompts/meta_prompt.md` 作为 Lyra 角色,组装以下三段输入:
```
1. User Requirement and Goal:
「生产一个用于 {goal_web} 平台的 {prompt_type} Prompt。
平台特有约束:[来自 P2 步骤提取的 retro 约束]
核心目标:[来自 core_goal]」
2. Input JSON Schema Specification:
[来自 prompt_authoring_guide.md 的输入字段规范]
3. Output JSON Schema Specification:
[来自 prompt_authoring_guide.md 的输出字段规范]
```
以 DETAIL MODE 执行 Lyra 4-D 方法论(DECONSTRUCT → DIAGNOSE → DEVELOP → DELIVER),输出最终 Prompt 正文。
---
### P4)字段校验
对照 `prompt_authoring_guide.md` 校验生产出的 Prompt:
- 输入字段名 / 类型 / 默认值是否与规范一致?
- 输出 JSON 字段名 / 层级是否与规范一致?
- 若有不一致 → 自动修正后继续,不需要用户介入
---
### P5)命名 + 写入文件
命名规则:
- 任务拆解:`goal_prompt_{goal_web}.md`
- 复盘:`retro_prompt_{goal_web}.md`
写入路径:`references/prompts/{文件名}`
---
### P6)自动写入 prompt_registry.md(欠缺3修复)
在 `prompt_registry.md` 的注册表中追加一行:
```markdown
| {文件名(不含.md)} | {prompt_type} | {goal_web} | {一句话描述,含平台专属约束关键词} | `references/prompts/{文件名}` | {通用版名称} |
```
---
### P7)完成通知
向用户输出:
```
✅ Prompt 生产完成
文件:references/prompts/{文件名}
注册:prompt_registry.md 已追加记录
下次触发 {goal_web} 批次时,Step 1/Step 6 将自动调用此 Prompt
```
---
> **隔离原则**:Prompt 生产流程完全独立,不写入 master_task.json,不影响任何批次任务的 batch_seq / retro / task 文件。
---
## 输出检查清单(V2.0 已更新)
- [ ] **Step 0**:`tasks/master_task.json` 是否已生成,含 `runtime_goal_web` / `runtime_core_goal` / `runtime_core_flow` / `trigger_source` / `branch_context`
- [ ] **core_flow 读取**:是否按优先级(用户输入 > retro > core_goal.json)读取 `core_flow`,为空/null 时写 null 而非省略字段
- [ ] **Step 0**:`goal_web` 来源是否记录在 `context_source.goal_web_from`(user_input / core_goal_json / prompted)
- [ ] **Step 0**:若情况三(解析不出 web),是否已向用户询问并等待确认,而非擅自猜测
- [ ] **Step 0**:`references/hook_config.json` 是否已读取,`master_task.json` 中 `auto_run` 字段是否已初始化(`total` / `remaining` / `current_run`)
- [ ] **Step 1**:是否先读取 `references/prompts/prompt_registry.md`,按 `type=任务拆解 + web={goal_web}` 查找,未找到才 fallback 到通用 `goal_prompt.md`
- [ ] **Step 1(core_flow)**:`runtime_core_flow` 是否已从 master_task.json 读取并准备注入 Step 2
- [ ] **Step 6**:是否先读取 `references/prompts/prompt_registry.md`,按 `type=复盘 + web={goal_web}` 查找,未找到才 fallback 到通用 `retro_prompt.md`
- [ ] **Prompt 注册表**:新增平台专属 Prompt 时,是否已同步更新 `references/prompts/prompt_registry.md`
- [ ] **Prompt 生产流程**:Step 0.0 是否优先识别「Prompt 生产」意图,识别到后是否跳转至 Prompt 生产流程而非批次任务流程
- [ ] **Prompt 生产 P2**:是否自动读取 authoring_guide(Schema)+ core_goal.json(业务背景)+ 最近3个 retro(平台约束),无需用户手动提供
- [ ] **Prompt 生产 P4**:是否对照 authoring_guide 校验字段,发现不一致时自动修正
- [ ] **Prompt 生产 P6**:是否自动追加 prompt_registry.md 记录(不依赖用户手动操作)
- [ ] **隔离性**:Prompt 生产流程是否未修改 master_task.json / batch_seq / retro 等批次任务文件
- [ ] **全自动化约束**:全流程是否未向用户要求任何人工介入(attach Tab / 点击 / 确认 / 提供数据)?若任务因环境缺失失败,是否已回写 `task_state: "failed"` + 失败原因,而非停下来等待?
- [ ] **Step 0**:若 `trigger_source = auto_hook`,是否从上一个 master_task 继承 `remaining` 而非重新读取 hook_config
- [ ] **Step 4**:所有 task 完成后,是否触发 `on_batch_complete` 钩子,检查 `remaining` 并决定是否继续
- [ ] **Step 4**:有 task failed 时,是否**不中断流程**,直接继续判断 `remaining` 推进至 Step 5→6(失败状态已回写 task_result,复盘兜底)
- [ ] **Step 4**:自动连续运行时,是否在每个 batch 完成后发送简短进度通知(含失败任务数),但不等待用户回复
- [ ] 任务 JSON 是否包含全部字段(含 `goal_web` / `core_flow` / `task_script_seq` / `task_script`)
- [ ] `goal_web / core_goal / core_flow / date / batch_seq` 是否与 core_goal.json 和上游保持一致
- [ ] **Step 2(core_flow 非空)**:每个 task 是否含 `flow_step` 字段,且任务顺序是否与 `core_flow` 流程步骤严格一致
- [ ] **Step 2(core_flow 非空)**:无法执行的流程环节是否以 `task_state: blocked` 的占位任务显式表示
- [ ] **Step 4(core_flow 非空)**:每个 task 执行完毕后是否回写了 `flow_compliant` 字段(true/false/null)
- [ ] **Step 6(core_flow 非空)**:retro JSON 是否含 `flow_violations` 字段,列出所有 `flow_compliant=false` 的任务及归因
- [ ] **Step 6(core_flow 透传)**:retro JSON 是否含 `core_flow` 字段,值与上游一致(null→null,非空→原样)
- [ ] 任务 JSON 是否保存至 `tasks/{goal_web}_tasks_{batch_seq}.json`
- [ ] `task_state` 是否已明确设置(`done` / `failed`),不存在 `pending` 状态的已执行任务
- [ ] `task_result` 是否已写回(非 null)
- [ ] 若产生技术方案:是否按命名规范保存为 Markdown,且包含 `{goal_web}` 平台约束
- [ ] 脚本注册表是否已写入本批次新开发脚本的 score、script_description 与 **`target_web`**(必填,值为当前 `goal_web`)
- [ ] 若 `script_score < 0.8`:注册表中对应脚本 score 是否已降级回写,且 `target_web` 字段是否已填写
- [ ] Step 6 复盘 JSON 的 `next_batch_guidance` 是否含 `blacklist` 字段(结构化路径列表)
- [ ] 运行日志是否已生成并保存
- [ ] Step 6 复盘 JSON 是否已写入以下两个路径:
- `tasks/{goal_web}_retro_{batch_seq}.json`(Step 1 上游读取用)
- `run/{date}/{batch_seq}/retro_output.json`(日志归档用)
- [ ] Step 6 复盘 JSON 中是否含 `goal_web` 字段,确保下一批次可正确继承
- [ ] 若本批次有用户反馈:retro JSON 中是否含 `user_feedback` 字段,`priority` 是否为 `HIGH`,`feedback` 数组是否完整写入
- [ ] Step 1 读取上游 retro 时,若含 `user_feedback`:是否已将每条 feedback 转化为本批次任务约束(优先级高于 `next_batch_guidance`)
- [ ] Step 1 读取上游时,是否严格按 `tasks/{goal_web}_retro_*` 过滤,未跨平台读取
- [ ] 若该平台在 `tasks/` 下无历史文件:`batch_seq` 是否从 `001` 开始,且任务 JSON 已写入 `tasks/{goal_web}_tasks_001.json`
### V2.0 新增检查项
- [ ] **Step 2(DAG)**:任务 JSON 中每个任务是否均有 `depends_on` 字段(空数组或前置 ID 列表),无缺漏
- [ ] **Step 2(DAG)**:是否设计了至少一对可并发执行的无依赖任务(`depends_on: []`),而非全链式串行
- [ ] **Step 3.2(沙盒预检)**:新开发脚本是否执行了 `python3 -m py_compile` 或 `bash -n` 静态检查
- [ ] **Step 3.2(自愈)**:若检查失败,是否进入局部自愈循环(最多 3 次重试),超限后是否标记 failed 而非无限重试
- [ ] **Step 3.2(放行)**:只有通过静态检查的脚本路径,才写入 `task_script` 字段
- [ ] **Step 4(并发)**:执行引擎是否按 DAG 就绪态调度,而非按数组顺序串行执行
- [ ] **Step 4(blocked)**:前置任务 failed 时,后继任务是否标记为 `blocked`(而非 pending 或直接 failed)
- [ ] **Step 4(双轨日志)**:是否在所有 task 回写完成后,**同时**生成 `运行日志_*.md`(轨道A)和 `compressed_log.json`(轨道B)
- [ ] **Step 4(compressed_log)**:`compressed_log.json` 中 `action_sequence` 是否为关键动作序列(非原始 stdout),`error_trace` 是否只含最底层异常行
- [ ] **Step 5(source 字段)**:任务 JSON 中是否记录了 `source` 字段(`registry` 或 `new`)
- [ ] **Step 5(OB 老化)**:若 `source=registry` 且 `script_score < 0.8`,是否执行了两步降级:①注册表 score 下调至旧值×0.7 ②追加 `needs_update` / `deprecated_by_{date}` 标签
- [ ] **Step 6(压缩日志)**:`{past_3_runs_logs}` 变量是否读取的是 `compressed_log.json` 而非原生 .md(若无压缩日志则已 fallback)
- [ ] **Step 7(筛选)**:是否扫描了本批次 `source=new` + `score>=0.8` + `done` 的任务
- [ ] **Step 7(评估)**:对候选任务是否完成了通用价值三问评估(非特例性 / 平台可复用 / 无重叠)
- [ ] **Step 7(写入)**:满足条件的脚本是否在 `script_registry.json` 中追加了 `ingested_at` / `ingestion_reason` / `tags`
- [ ] **Step 7(日志)**:`compressed_log.json` 中是否含 `step7_ingestion` 字段,记录候选数 / 入库数 / 跳过原因
### V2.1 新增检查项(元学习进化)
- [ ] **Step 0.2(初始化)**:master_task.json 中是否含 `branch_context.meta_optimization` 字段(`prompt_iteration_seq` + `batches_since_last_opt`)
- [ ] **Step 0.2(继承)**:续批次时 `meta_optimization` 是否从上一个 master_task.json 继承,而非重置为 0
- [ ] **Step 0.2(跨平台隔离)**:goal_web 切换时,`meta_optimization` 是否各自独立,不互相污染
- [ ] **Step 6(计数)**:每次 Step 6 retro 写入完成后,是否执行 `batches_since_last_opt += 1` 并写回 master_task.json
- [ ] **Step 6(触发判断)**:计数器更新后,是否判断 `batches_since_last_opt == 10`,满足则切入 Step 6.5,不满足则继续正常流程
- [ ] **Step 6.5(上下文提纯)**:是否只读取近 5 批次 retro 的 `historical_patterns` + `lessons_learned` 两个字段,而非全量 retro 内容
- [ ] **Step 6.5(meta_prompt)**:是否读取了 `references/prompts/meta_prompt.md` + `references/prompts/prompt_authoring_guide.md` 作为生成约束
- [ ] **Step 6.5(版本控制)**:新 Prompt 是否以 `goal_prompt_{goal_web}_v{seq}.md` / `retro_prompt_{goal_web}_v{seq}.md` 命名另存,而非覆盖旧文件
- [ ] **Step 6.5(注册表更新)**:`prompt_registry.md` 中对应平台的 `path` 指针是否已切换到新版本文件
- [ ] **Step 6.5(计数器重置)**:进化完成后,`prompt_iteration_seq` 是否进位,`batches_since_last_opt` 是否清零
- [ ] **Step 6.5(进化通知)**:是否向用户发送了包含版本号和核心改进点的进化完成通知
- [ ] **Step 6.5(回滚条款)**:若新版本导致连续 2 批次全失败,retro 的 `development_constraints` 中是否写入了回滚指令
don't have the plugin yet? install it then click "run inline in claude" again.