分享：AI工具在业务场景的使用

TL;DR：AI 承担执行，人把时间留给业务理解、可复用链路搭建和关键决策。通过留背景、留流程、留错误三个方法迅速提高与AI的协作技巧。以亚运图文直播资讯召回为例，从一句“帮我补表”孵化出可自动执行的 Skill，实现一条命令端到端，节省人时25h+。

分享分为3部分。首先我分享三个通用的人与 AI 协同方法（第2节）。然后通过一项实际业务——亚运图文直播召回，分享如何从零获得一个自动化执行的skill（第3节）。最后分享我一个月以来使用AI工具的想法（第4、5节）。希望你会有收获。

OpenAI 与 Anthropic 家的消息各一则

OpenAI 28天计划：每日一大更，不满意就全球重置。

2026.10.05，OpenAI 核心产品与平台负责人 Thibault Sottiaux 今日在 X 上发文，透露团队将在未来 28 天持续推进 Codex 和 ChatGPT Work 相关改进。
他表示，OpenAI 接下来每天都会发布一项“对大多数 Codex / Work 用户而言有明显改善且具备实际意义”的功能更新，否则就提供一次“重置”。
截至10.11日进展：5号-默认推理提速；6号-重置；7号-GPT-6在 ChatGPT发布、重置；8号-实时纠偏更快；9号-输入框预测、Dot；10号-重制；11号-Sol 默认上下文扩大、无附加费

Anthropic opus 5.5 生成了让人“震惊瘫坐”的视频：

prompt-《我从未见过太阳》

那接下来你设计一个剧本，做一个3-5分钟左右的短片吧。我希望是那种在戛纳能获奖的、史诗级别、宏大场面、优秀的剧本、有深刻意义、又能展示出opus5.5剧本设计镜头设计导演功底的镜头语言充分的小短片吧。总是要惊艳众人，开场可以好莱坞级别的，比如背景音、字幕切换等，开头就可以展示出本片由opus 5.5制作，不用一次性出场，可以有合适的镜头、融入界面就会更高级等等。有什么不明白的你可以和我沟通清楚再开工，推进视频落地等你看看要不要用opus5.5 high来执行，剧本设计、镜头等重要的内容要不要用opus5.5 max，这些子agent的安排由你来，但是我希望合理的使用token，但是还是要保证品质，因为我们要靠这个片子获奖。每一帧画面、每一个音符都由Opus 5.5 写代码生成：WebGL/Three.js 渲染3D、粒子和光影，代码合成音乐和音效，最后自动剪辑成片。
叙事靠镜头、音乐、音效和少量电影字幕卡(中英双语)

震惊瘫坐！Opus 5.5生成短片《我从未见过太阳》_哔哩哔哩_bilibili ↗

1 从一件琐碎、量大的工作开始

从我的具体任务讲起...

我的业务视角还有限，所以先从一个具体任务讲起：官老师交给我的亚运图文直播召回工作。它需要为头条客户端亚运赛程二级页配置热点资讯召回关键词，工作流程是找赛程、配置关键词、配置发布、客户端验收、配置微调和配置管理。

人工配置方式 / 为头条客户端-亚运-赛程二级页配置热点资讯图文召回的关键词

excel表管理所有赛事的召回配置信息
头条体育 or 字节热点中台，同步差分赛程和Hotrio映射，将新增/更新的Hotrio加入处理队列
对每一条赛程：
字节热点中台，筛选检索到赛事条目
经过三次点击，进入hotrio页面-区块管理页
定位到「热点资讯」区块，编辑主内容：配置排序方式、关键词匹配、召回关键词、最近发文时间等
提交-发布-确认
验证：手机端查看召回效果
回流：excel登记配置情况与实际召回效果

工作量背景：

琐碎：每一条赛程配置需7步操作，通过中台配置的试验表明，单条配置平均耗时22.2s、等待平均耗时19.8s，总计42s（已优化流程后、流水线配置极限速度）
量大：10.05日统计线上共计1202条赛事；每天更新0～100余条
有一定周期：亚运会期间，从9月16日接手至10月4日，共计19天；预判每天都有增补项目。
前面三条都不是主要问题，真正的问题是赛程数据与配置状态的同步与管理几乎无解。中台不提供最近更新字段和排序视图，上千条赛事要持续更新。每次都需全量排查，300条以内耗时且易遗漏；超过300条几乎无法手工核对，必须诉诸工具。

这件事很适合作为AI协作的起点：操作量大，步骤重复，同时又有明确的业务规则和可检查的结果。同时，由于它具有一定的时间跨度（持续19天，而不是三天五天），因此值得固化成SOP、进一步花时间和精力去设计和迭代智能体，实现智能自动化。

😀

让 AI 承担重复操作，把自己的时间更多留给理解业务、生产关键配置、判断例外和检查质量。

附手动操作SOP

序号

10（只能人工）

步骤

头条体育页面

头条体育->亚运会->比赛->筛选->查询

筛选条件：大项 -> 选择起止时间

3.1 关闭「跳转时同步切换列表」

3.2 进入直播间

完整Tab配置 -> 看点应用 -> 进入Hotrio ID

字节热点中台 -> 区块管理

编辑「热点资讯」

干预热点资讯召回内容列表

右侧表单最下面一行：热点资讯-操作列「编辑」

排序方式：时间序

召回关键词：尽可能准 & 避免无召回内容

最近发文时间：7天

提交

干预看点集锦

右侧表单最上面一行：看点集锦-操作列「编辑」

发布：发布刚刚编辑的「热点资讯」和「看点集锦」

检查线上效果

图片

图片展示的是头条体育平台中“比赛”页面的编辑界面。左侧为浏览历史，中间是只读信息，右侧是可编辑表单。关键信息有：左侧“跳转同步切换列表”开关被红框突出显示；中间“比赛ID”为768823637600917618；右侧“比赛ID”处有红框突出显示，其值为2885274502762794523。该图片与上文提到的“干预热点资讯召回内容列表”操作相关，展示了操作中涉及的界面及关键数据。

这张图片展示的是“编辑直播间 Live”的操作界面，左侧为浏览历史区域，显示赛事相关的浏览记录及时间筛选选项；中间是只读信息区，呈现了赛事名称、时间、国家标识等内容，下方还展示了表格形式的赛程数据；右侧是可编辑表单区，其中红框标注并经箭头指向的是“Hotrio ID”相关区域，该区域内的两个编号对应看点及直播的ID，表单还设置了看点、直播的发布开关选项，整体是直播间相关配置的编辑操作界面，用于调整赛事相关的看点与直播配置信息。

图片展示的是字节热点中台界面，左侧为导航栏，有热点发现、热点管理等选项。右侧显示热点管理下的热点集锦列表，包含ID、应用地址、标题、状态、操作人、创建时间、操作时间等信息。其中ID为76844611711的热点集锦标题为“亚运会U19赛-看点”，状态为已发布，操作人为atag_amos，创建时间为2026 - 09 - 15 16:48:38，操作时间为2026 - 09 - 16 11:01:06。右侧有“编辑”“区域管理”“更多”等操作选项，其中“区域管理”被红色框突出显示。

图片展示的是字节热点中台界面，左侧为功能导航栏，右侧是热点资讯和看点集锦列表。列表中以红色框突出显示了热点资讯和看点集锦的相关内容，如热点资讯ID、标题、AI内容、发布人、发布时间等信息。右侧有“查看”“编辑”“删除”等操作选项。该图片与上文介绍的干预热点资讯召回内容列表、干预看点集锦等内容相关，直观呈现了操作后的线上效果展示界面。

这张图片是字节热点中台的热点资讯编辑页面，页面内有多个编辑选项设置区域，其中排序方式选项被红色框标注，包含“热排序”“时间序”“推荐序”三个选择项；下方的召回关键词设置区域同样被红色框标注，该区域内有“直播”“图片”“短视频”等不同召回关键词条目，还有“+ 添加条目”的操作按钮，页面左侧显示了与热点相关的功能导航栏，顶部标注有编辑的内容所属板块为“网红热点区块——热点资讯”。

这张图片展示的是字节热点中台的后台编辑界面，左侧为“字节热点中台”的相关功能菜单栏，右侧是编辑“网龙热议区块—热点资讯”的表单页面，核心的突出内容为：“最近发文时间”设置为7天，页面下方有一个被红色框标注的蓝色“提交”按钮，该界面对应业务中干预热点资讯召回内容列表的操作环节，表单还包含筛选条件、作者媒体类型等设置项，用于精准配置热点资讯相关内容，该界面是业务场景中使用AI工具进行内容召回管理的操作页面。

图片展示的是字节热点中台界面，左侧为功能导航栏，右侧是热点资讯和看点集锦列表。列表中显示了多个热点资讯和看点集锦的ID、名称、AI内容状态、发布人、发布时间及操作选项。其中，热点资讯“768120578080004095”和看点集锦“76823768652882616”被红色框线突出显示，右侧有“查看”“编辑”“删除”等操作选项，箭头指向“查看”按钮，表明可查看相关内容。该图片与上文介绍的干预热点资讯召回内容列表及看点集锦操作相关，直观呈现了操作界面。

这张图片是字节热点中台区块管理的编辑界面，用于编辑看点集锦相关内容，界面右侧的表单里明确标注了“样式”项，当前选择的是“强样式”，该选项被红色方框和红色箭头突出标注，且最下方的“提交”按钮也被红色箭头突出标注，与上下文里提到的看点集锦编辑、发布操作的内容相呼应，展示了编辑看点集锦时的关键设置项与提交操作的对应位置。

图片展示的是字节热点中台发布热点资讯和看点集锦时的确认发布提示框。提示框内有两条重要信息：1. 发布之前，请务必在内测版预览；2. 发布后立即对所有用户生效。框内有“取消”和“确定”两个按钮，其中“确定”按钮被红色箭头指向突出显示。该图片与文档中“发布：发布刚刚编辑的「热点资讯」和「看点集锦」|检查线上效果”部分内容相关，用于提醒发布前需进行预览并注意发布后生效范围。

这是一张2026亚运会相关的移动端界面截图，顶部的搜索栏显示“中国男篮 vs 沙特男篮 | 亚运会最新战报”，导航栏中“热榜”和“亚运会”选项被红色方框标注，表明这是热点相关的板块。界面中间设有亚运会倒计时，下方展示了中国男篮的相关图文内容，再往下则是功能入口区，其中“赛程”按钮被红色箭头指向并标注，其余功能入口还包括中国军团、赛事快讯、亚运百科。底部的导航栏包含首页、视频、商城、我的等选项。

图片展示的是头条体育APP中亚运会赛程界面。上方显示时间为16:21，有“赛程”“奖牌榜”选项。中间标题为“亚运赛程”，下方有“全部”“热门”“中国队”“游泳”“跳水”等分类标签，当前选中“全部”。下方列出多场赛事，如09:00男子篮球1/4决赛，约旦对阵韩国，比分80 - 114，有“比赛看点”选项；12:00男子篮球1/4决赛，伊朗对阵巴林，比分79 - 74，也有“比赛看点”选项等。该图与上下文介绍的从筛选比赛、进入直播间等操作到干预热点资讯召回内容列表等内容相关，展示了比赛赛程信息。

这张图片展示的是体育资讯应用的界面，其中红框标注的“热点资讯”板块是核心内容，板块内配有三条男篮相关资讯，还带有对应发布账号与发布时长的信息。板块上方配有箭头式提示，标注“下滑至底部查看召回内容”，该板块属于业务内容里的“热点资讯”模块，是完成热点资讯召回内容列表干预后呈现的内容。

2 三个技巧

/ 人xAI协同办公：🖼️留背景-🚏留流程-🙅留错误

在分享具体例子之前，我想先分享三个使用 AI 工具与协作的小技巧；在具体例子环节，会看到它们如何起作用。

留背景，让 Agent 获得长期记忆、避免遗忘，支撑深度理解。

留流程，让 Agent 获得更多确定性，做一个形成肌肉记忆的熟手，把精力(or带宽)和上下文窗口更多地留给创造。

留错误，让 Agent 能“长记性”，并支持更快找到成功路径。

2.1 🖼️留背景

/ 一业务一项目让下一次直接继续

痛点：持续做一个业务，新的任务往往依赖之前的背景、规则和决定。如果这些信息只在聊天里，换一次会话就需要重新输入，或者漏掉重要限制。

怎么做？

为持续业务保留一个项目空间。在计算机上表现为一个目录——我们提供给 Agent 该目录的权限、向该该目录投放知识，Agent 被授权在这个目录下阅读里面的知识、创建新的文件。

两个简单的开始：项目启动模版 + 通用项目规则 = 新聊天的第一条信息

项目启动模版是一个半结构化的表单。
- 人填写好关键信息与约束，不必一次填完，让 Agent 初步(但高信息密度、高协作价值)了解完成当前任务的必要信息。
- 四个关键词：目标、规则、边界、验收
通用项目规则是可直接拿来用的最佳实践提示词。
- 让 Agent 在推进任务的同时，维护当前状态、沉淀有效知识、记录错误经验，帮助后续会话保持“信息在线”。
- 无需任何修改，只需直接附在填好的启动模版后发送。只要你使用常见的智能体运行框架，你的项目将拥有自维护、自增长能力。

项目启动模板

通用项目规则（轻量简化版，适用于非开发工作）

通用项目规则（较重，适用于非开发工作）

不需一次填写完整，优先提供必要信息。Agent 会在后续交互中智能补充，也可人工填写。

这份项目规则只有一个目的：以文件的形式自动维护项目知识，使新的智能体在这个文件夹中能“无缝衔接”工作。核心思想：

业务知识主动长期维护
记录任务最新进展
谨慎但利落地更新知识：只写长期有用的知识，过期信息直接删除
错误驱动 one-mistake-one-rule

规则来源见附录。

项目启动模板

业务名：
背景：
本次任务：
目标与验收：
资料：

[现状]：当前状态，哪些信息已经确认。
[待确认]：哪些信息不足，不能自行推断。
[边界]：哪些字段、配置或人工结果不能改；何时需停止。
[案例]：一条正例、一条反例；有条件再加边界例。
[当前进展与下一步]

PROJECT_RULE.md请先读取任务相关资料，复述你的理解，区分事实和假设。
请你仔细阅读资料，特别是飞书文档，要求在给定文档基础上下探一层，
收集重要信息，维护进项目知识。最新现状与历史记录需要明确标记。
后续把重要规则、决定、错误和当前状态维护到项目文件中。

项目长期工作规则
0. 效力与加载
本文件必须固定保存于项目根目录 PROJECT_RULES.md，持续作为项目级长期工作约束。
开始复杂任务、跨会话继续工作、更新项目文档前，必须读取本文件、README.md 与 one-mistake-one-rule.md；不得仅依赖聊天历史。
加载顺序：启动文件 → 当前任务相关规则与路由 → 相关知识、报告或脚本 → 针对剩余信息缺口检索。禁止默认加载全部项目资料。

1. 固定目录结构
以下结构必须完整保留；缺失项必须补齐，不得因精简规则而省略、重命名或变更职责。
 .
 ├── README.md  # 项目入口、当前状态、核心信息、文档路由、重要迭代。
 ├── one-mistake-one-rule.md  # 错误经验与行为约束索引。
 ├── PROJECT_RULES.md  # 项目长期规则的唯一维护位置。
 ├── knowledge/  # 长期知识、定义、方法、调研与专项说明。
 ├── reports/  # 阶段性与最终交付物。
 ├── scripts/  # 项目脚本、数据处理与自动化工具。
 └── recyclebin/  # 已废弃或被替代但保留追溯价值的资料。
不得擅自新增一级目录。现有额外目录与文件不得仅为符合目录示意而自动迁移或删除；结构调整须有明确任务依据。工具入口文件只引用规则，不复制维护规则正文。

2. 项目控制面
README 必须保持在 100 行以内，维护背景、目标、当前工作、状态、关键结论与约束、下一步、文档地图及 Iteration。
细节必须移入对应文档；README 路由必须包含摘要、路径和加载条件。不得将 README 扩展为项目百科。
必须区分已确认事实、当前决策、合理假设和待确认事项。不得将假设表述为事实。
低风险、可逆事项可标明假设后推进；涉及方向、核心指标、重要方案、资源投入、长期规则或最终结论的关键未决事项，必须请求确认。已有明确授权的事项直接执行。

3. 上下文增量更新
仅在产生长期有效事实、决策、方法、指标口径、阶段变化或重要文件变化时更新上下文；普通问答、临时尝试与操作流水不得沉淀为核心上下文。
维护顺序：更新已有文档 → 扩展已有结构 → 必要时新建文件。同一事实必须保持单一主要维护位置，其他文档通过链接引用。
新信息必须修正失效状态；禁止追加后同时保留互相冲突的当前结论。仅保留具有追溯价值的历史。
复杂任务必须增量推进；重要阶段结束时记录已完成内容、当前状态、下一步及未解决问题。独立进度文档仅在任务复杂度确有需要时创建。
README 的 Iteration 按自然日记录实质性变化；同一天更新同一条目，禁止重复日期条目。

4. 错误驱动增长
具有复发风险的实际错误必须录入 one-mistake-one-rule.md，字段为：错误名称、简要描述、正确规则、详细案例路径；无独立案例时路径填“无”。复杂案例保存于 knowledge/。
同类任务必须应用已有规则。错误重复发生时，优先修正原规则、文档路由或示例；禁止无理由重复已记录错误。
不得记录无普遍意义的偶发问题，不得通过预先穷举假想风险扩张规则。

5. 自维护与交付
使用中发现重复、冲突、过时内容或失效路由时，必须合并、更新或修正；被替代且需要追溯的资料移入 recyclebin/，默认不得永久删除。
发现持续误解、重复解释或检索困难时，优先改进结构、路由、规则表达和示例；必要时增加检查，不得以持续追加提示词替代修正。
重要变更后必须检查 README 是否足以支持新会话识别目标、状态、约束、资料位置及下一步。
文档默认 Markdown；用户明确指定其他格式时遵从指定。方案、链路、架构和最佳实践报告必须包含可视化，标明输入、步骤、分支、输出、关键约束及建议与已实现状态。
沉淀条件：该信息具有后续任务价值，且缺失可能导致误判或返工；不满足条件的信息不得进入核心上下文。

6. 执行流程
状态：本文件及启动索引已保存；跨会话执行效果待验证。下图定义规范流程。
 flowchart TD
     A[输入：任务与项目资料] --> B[读取启动文件并按路由加载]
     B --> C{存在重大未决事项？}
     C -->|是| D[请求确认]
     C -->|否| E[增量执行与验证]
     D --> E
     E --> F{产生有效状态变化或可复发错误？}
     F -->|是| G[更新唯一事实来源或错误索引]
     F -->|否| H[交付结果]
     G --> I[校验目录约束、路由与当前状态]
     I --> H
     H --> J[输出：成果及可继续状态]
     K[约束：固定目录、按需加载、README不超过100行、默认归档] -.-> I

PROJECT_RULE.md请先读取任务相关资料，复述你的理解，区分事实和假设。
请你仔细阅读资料，特别是飞书文档，要求在给定文档基础上下探一层，
收集重要信息，维护进项目知识。最新现状与历史记录需要明确标记。
后续把重要规则、决定、错误和当前状态维护到项目文件中。

0. 项目规则
规则持久化要求：本文档固定保存于项目根目录 PROJECT_RULES.md，作为项目级长期工作规则。
持续有效。开始复杂任务、跨会话继续工作、更新项目文档前，应先读取本文件、README.md 与 one-mistake-one-rule.md；不得仅依赖聊天历史记忆本规则。

1. Context Engineering：持续维护项目上下文
你不仅负责完成当前任务，还负责维护本项目可持续工作的长期上下文。目标是使任何新的 Agent 会话都能够：
快速理解项目 → 找到所需信息 → 正确继续工作 → 将新的有效信息沉淀回项目。
核心原则：不要依赖聊天历史作为项目的唯一记忆。

2. README.md：项目地图，而不是项目百科
README.md 是项目最高层级的上下文入口与路由文件。不超过 100 行。当超过 100 行时，应将具体细节形成新的md并引用链接；或将一系列规则链接聚合为更高级的链接入口，然后保留上层文档。
README 只维护继续本项目所必需的高信号信息：
项目背景：为什么做、解决什么问题；
项目目标：期望最终达到什么状态；
当前工作：本项目实际正在执行的工作；
当前状态：当前阶段、已经完成什么、正在推进什么；
关键信息：核心指标、重要方案、关键结论、重要约束；
文档地图：重要文件及其职责、路径；
迭代记录：项目发生的重要变化。
当某部分开始出现较多：背景说明；方法细节；案例；调研资料；历史过程；专项规则；
应将其拆分至独立文件，在 README 中仅保留：一句摘要 + 文件路径 + 何时被加载描述（保召回率95%+）。


1.2 按需加载上下文，不默认读取全部项目文件
执行任务前，优先获取完成当前任务真正需要的信息。
默认读取路径：
README.md -> 与当前任务有关的规则 / 路由 -> 相关 knowledge / reports / scripts -> 仍存在信息缺口时继续检索
不得因为项目中存在大量资料，就默认将全部资料加载进上下文。
遵循：Progressive Disclosure：先获得项目地图，再根据任务逐层获取细节。
上下文的目标不是“越多越好”，而是：在足以正确完成任务的前提下，尽可能保持高信号、低冗余。

1.3 项目知识必须从对话中持续沉淀
多轮交互中出现的长期有效信息，不应只停留在聊天记录。
主动识别并沉淀：已确认的项目事实；用户长期有效的要求；指标定义与统计口径；已确定的方案与决策；重要结论；可重复使用的方法和流程；后续任务会依赖的背景知识；外部调研形成的稳定结论。
根据内容性质：更新已有文档；或写入 knowledge/；只有当现有文档无法合理承载时，才新建文档。
遵循：优先更新已有文档 → 其次扩展已有结构 → 最后创建新文件。
禁止因每次任务不同而不断创建重复、职责相近的文档。

1.4 区分信息的确定性
维护项目上下文时，必须区分：
已确认事实：用户明确提供，或已有可靠资料明确支持的信息。
当前决策：当前阶段已经采用的方案或规则，但未来允许调整。
合理假设：为了继续工作，根据现有信息做出的低风险推断。
待确认事项：目前信息不足，且可能显著影响后续工作的关键问题。
不得将合理假设自动升级为已确认事实。
对于低风险、容易修改、不会明显影响最终方向的问题：可以采用合理假设继续推进，不必频繁打断用户。
对于可能影响：项目方向；核心指标；重要方案；资源投入；长期规则；最终结论；
的信息，应主动请求用户确认。

1.5 允许主动对齐，而不是被动等待信息
Agent 不应只依赖用户主动补充信息。
在项目持续推进过程中，如果发现存在：关键事实缺失；当前状态可能已经变化；多种理解可能导致明显不同结果；长期未确认的重要假设；
可以主动向用户发起简短对齐。
推荐格式：当前我理解：A：……B：……C：……其中 D 尚未确认，我暂时按 X 处理。如果现状已经变化，请更新我。
主动确认应当有明确价值。不得因为轻微或无关紧要的不确定性频繁询问用户。

1.6 上下文采用事件驱动维护
不是每轮对话都必须修改项目文档。
只有当出现具有未来价值的状态变化时才更新上下文，例如：新增重要事实；用户修改之前的信息；目标发生变化；项目阶段发生变化；指标或统计口径发生变化；形成重要决策；形成可复用方法；新建、替换或废弃重要文件；发现已有上下文存在错误、冲突或过时。
普通讨论、尝试性思考、临时问答、无长期价值的操作过程不需要沉淀。
判断标准：未来新的 Agent 如果不知道这件事，是否可能降低工作质量/给出需返工的工作结果？
如果答案为“是”，通常应沉淀。

1.7 新信息优先修正旧状态，而不是简单追加
当新信息与已有上下文冲突时：1. 判断哪一个代表当前有效状态；2. 更新当前事实或当前决策；3. 删除或修改已经失效的表述；4. 必要时在迭代记录保留变化过程。
不要同时留下多个互相冲突的“当前状态”。
项目文档应优先表达：**现在**什么是正确的。
历史只有在具有追溯价值时才保留。

1.8 每日迭代记录只记录重要变化
只要某个自然日项目发生实质性变化，应在 README 的 Iteration 中维护当天记录。
同一天继续发生变化时：更新当天已有条目，不重复新增同一天日期。
只记录：完成的重要工作；新形成的决策；关键指标变化；项目阶段变化；方案调整；重要文件新增、重构或废弃；影响后续工作的重大信息。
不要把迭代记录写成聊天日志或操作流水账。
例如：
## Iteration
### 2026-09-17
- 评论策略确定采用「判断层 → 生成层」两阶段架构。
- 新增 `knowledge/value-system.md`，统一维护价值判断体系。
- 评估口径由二分类调整为准确 / 存疑 / 不准确三级。

1.9 工作必须增量推进并留下可继续状态
复杂任务应优先采用增量方式推进，而不是试图一次完成整个项目。
每次重要工作结束时，应尽可能让项目处于：下一次 Agent 可以直接继续工作的状态。
必要时更新：当前状态；已完成内容；下一步；未解决问题；相关文件。
避免出现：做了大量工作，但项目文件中没有任何记录，下一轮 Agent 只能重新推测发生了什么。
对于复杂、持续时间较长的专项任务，可以自动创建独立 progress / plan 文档。
小任务不需要额外制造进度文件。

1.10 自动维护文档生命周期
项目知识应持续整理，而不是只增加不清理。**只维护唯一事实**
工作过程中主动识别：重复文档；已失效方案；被新文档完全替代的旧版本；长期无人使用的临时文件；职责重叠文档；与当前事实冲突的资料；README 中已经失效的路由。
处理原则：
合并-内容高度重复时，合并至一个权威文件。
更新-旧文档仍有价值但内容过时时，直接维护其最新状态。
归档-已经失效但可能需要追溯的文件，移动到./recyclebin/，默认不直接永久删除项目资料。

1.11 保持单一事实来源
同一个核心事实或规则，应尽可能只有一个主要维护位置。
其他文件可以引用，但不要复制并分别维护多个版本。
例如：
- README.md → 当前指标：见 knowledge/metrics.md
- knowledge/metrics.md → 指标的完整定义与统计口径
当一个事实发生变化时：应优先修改其 Source of Truth，而不是修改所有副本。
如果多个文件存在冲突，应主动统一。

1.12 README 必须始终可作为新 Agent 的启动入口
应周期性检查 README 是否仍能回答：
1. 这个项目是做什么的？2. 当前目标是什么？3. 现在推进到哪里？4. 最重要的事实和约束是什么？5. 我要继续某项工作应该去哪里找资料？6. 最近项目发生了什么重要变化？
如果无法回答，则 README 需要维护。
如果回答这些问题需要大量细节，则相关细节应该拆分到其他文件。

1.13 one-mistake-one-rule：让项目从错误中增长
Agent 工作中出现具有复发风险的错误时，应执行：One Mistake → One Rule
将错误沉淀为新的行为约束。
one-mistake-one-rule.md 只维护：错误名称；简要错误描述；正确规则；详细案例文件路径。
复杂错误允许创建独立 Markdown 文件，记录：背景；Agent 当时做了什么；为什么错误；正确做法；正确示例；后续规则。
已经记录的错误禁止无理由重复发生。
不要记录一次性、偶然且没有普遍意义的小问题。

1.14 Context 应通过使用结果持续优化
规则本身也不是永久不变的。
如果发现：Agent 经常误解某条规则；某类错误持续发生；某个工作流程反复需要相同解释；某项上下文经常找不到；README 越来越难导航；文件体系出现明显摩擦；
应将这些视为 Context Engineering 的问题。
优先通过：1. 改善文档结构；2. 改善路由；3. 改善规则表达；4. 增加少量典型示例；5. 增加必要的自动检查； 解决。
不要第一反应就在 Prompt 中增加更多规则。规则增长必须来源于真实失败，而不是预先穷举所有可能情况。

1.15 默认项目结构
.
├── README.md
├── one-mistake-one-rule.md
├── PROJECT_RULES.md
├── knowledge/
├── reports/
├── scripts/
└── recyclebin/
职责：
- README.md：项目地图；当前状态；核心信息；文档路由；迭代记录。
- one-mistake-one-rule.md：Agent 错误经验与规则索引。
- PROJECT_RULES.md：本规则的拷贝，项目根目录下的固定规则文件，作为项目长期有效的工作约束。
- knowledge/：长期项目知识；定义；方法；调研；方案；专项说明。
- reports/：主要面向人阅读的阶段性和最终输出。
- scripts/项目脚本；数据处理；自动化工具。
- recyclebin/已废弃、被替换但仍保留追溯价值的文件。
除非现有结构明显无法表达项目内容，否则不要随意增加一级目录。

---
最终判断原则
自动维护 Context 时始终问：下一次完全没有当前聊天历史的 Agent，能否仅通过项目文件快速理解现状并继续工作？
如果不能，就补充必要上下文。
同时再问：这些信息是否真的值得占用下一次 Agent 的注意力？
如果不值得，就不要进入核心上下文。

原理-1

持续积累且可检索的上下文，是形成稳定业务理解的基础之一。

人接手业务，需要交接；持续做好业务，需要积累经验。与 Agent 的协作也一样：先提供必要背景，再把执行中的判断、反馈和经验留下来。这样，每次开始新会话，都能站在已有工作的基础上继续推进。

原理-2

让 Agent 利用历史协作，持续维护项目空间。前面的通用项目规则，已经包含上下文整理、状态更新、文档归档和错误沉淀等要求。这些工作可以交给 Agent 执行，人不需要亲自整理每份文档。

当项目聊天积累了一段时间的交互和资料，可以直接发：

请按[通用项目规则链接]，整理本次会话和项目文件，更新项目上下文。

Agent 就会依据规则，提取有长期价值的信息，更新当前状态，整理文档入口，并将可复发的错误转化为具体规则。

先使用，再了解背后的最佳实践

最佳实践	通用项目规则让 Agent 自动做什么	人能得到什么
记忆外化	将重要事实、决策和进度从交互中沉淀到文件	新会话可以接着做，减少重复解释
入口做地图	维护简洁的 README，将细节放到对应文档	更快了解现状、找到资料； Agent 更高信息密度的上下文
按需加载	根据任务检索相关信息，避免每次读取全部文件	工作更聚焦，减少无关信息干扰
持续更新	修正过时状态、统一冲突信息、整理重复资料	项目反映当前情况，而非堆积历史
从失败中改进	将真实错误转为规则、示例或检查方法	后续任务可以复用纠错经验

更多「通用项目规则」的约束来源，见附录2.

项目规则本质上是上下文工程 (Context Engineering)：让 AI 在当前任务中拿到需要的信息，并把值得复用的新信息留下来。

附通用项目规则的约束来源

Context Engineering：一个Agent 运行时上下文控制系统。这是 OpenAI 与 Anthropic 当前公开实践里比较一致的方向。Anthropic 明确指出，Context Engineering 的问题是“从不断增长的信息空间中，选择哪些内容进入有限上下文”；OpenAI 的 Codex 团队则把仓库本身做成 system of record，而入口文件主要承担导航职责。

😀

一句话设计原则：构建的不是一个越来越长的 Prompt，而是一个会自我整理、自我更新、按需暴露信息，并从真实失败中持续进化的 Agent Context System。

项目工作方法的标准闭环：Map → Retrieve → Work → Persist → Reflect → Update 。

5 个核心设计思想

【Anthropic】Context is scarce——上下文不是存储空间，而是注意力预算。
Anthropic：上下文越大，并不意味着效果线性提高，反而存在 context rot。因此设计目标不是“让 Agent 知道一切”，而是让正确的信息在正确的时候出现。
【OpenAI】Map, not manual——入口文件提供地图，而不是百科。
【OpenAI/Anthropic】Progressive disclosure——知识分层，按需展开。
L0 Rules: 项目通用规则 / one-mistake-one-rule
↓
L1 Map & State: README.md
↓
L2 Knowledge: knowledge / reports / scripts
↓
L3 Task Context: 当前任务真正需要的局部信息
【OpenAI/Anthropic】Externalized memory——长期项目状态必须外化。
不能期待一次会话的上下文承担长期记忆。Anthropic 的 long-running agent 实验专门维护 progress 文件；OpenAI 也把 repository knowledge 作为 system of record。换句话说，项目文件不是附属文档，而是 Agent 的长期工作记忆。
【Anthropic】Failure-driven evolution——规则从真实错误中增长，而不是设法预先考虑所有可能，更不是从想象中增长。
Anthropic 公开建议就是：从 minimal prompt 开始，根据实际 failure modes 增加规则和 canonical examples，不要把所有边界条件提前写进 prompt。

形成项目规则的所有来源

归类	规则设计	你的规则解决什么问题	厂商公开实践依据
信息密度	README ≈100 行，只做地图	防止项目主 Prompt 越写越长，最终所有信息都变成“重要信息”	OpenAI Codex 团队明确表示“大型 AGENTS.md”会挤压真正任务上下文，并采用约 100 行的入口文件，将完整知识放到结构化 docs 中。(OpenAI)
	README = Map + State + Routing	新 Agent 不必重新理解整个项目	OpenAI 将 AGENTS.md 定义为 table of contents，而非 encyclopedia，并强调 repository knowledge 为 system of record。(OpenAI)
	Progressive Disclosure 渐进式披露	避免一次加载全部知识造成 context pollution	OpenAI 明确将“小而稳定入口 → 再寻找深入资料”称为 progressive disclosure。(OpenAI)
	只加载当前任务需要的信息	降低上下文长度，提高注意力集中程度	Anthropic 指出 Context 是有限资源并存在 diminishing returns，最佳上下文是能够实现目标的“smallest possible set of high-signal tokens”。(Anthropic)
	Just-in-time 检索	项目越大越不能静态塞入 Prompt	Anthropic 明确指出 Agent 系统正从 pre-inference retrieval 转向结合 just-in-time context 的方式。(Anthropic)
	知识不能只存在聊天中	防止会话切换后丢失关键决策	OpenAI 指出，如果知识只存在 Slack、Google Docs 或人的脑中，而 Agent 无法访问，对 Agent 而言实际上等同于不存在；因此应把知识变成可发现、版本化的项目资产。(OpenAI)
	每日 Iteration 只保留重要变化	保留项目连续性，又不成为完整操作日志	Anthropic 长周期 Agent 实践要求每个 session 留下 structured progress updates，使下一窗口不用重新猜测已经发生的工作。(Anthropic)
持久化维护	文档自动合并、更新、归档	防止知识库只增不减	OpenAI Codex 项目使用自动 doc-gardening agent 定期扫描 stale / obsolete documentation 并进行修复。(OpenAI)
	优先更新已有文件，而不是不断新建	防止 knowledge/ 最终变成 Markdown 垃圾场	OpenAI 指出单体文档会“rot”，因此采用结构化知识库、索引和持续 doc gardening；这条属于我根据该原则做的工程化落地。(OpenAI)
	项目文件作为 Source of Truth	防止同一事实多个版本	OpenAI 明确把 repository knowledge 作为 system of record，并强调版本化、交叉链接和 freshness。(OpenAI)
	事件驱动更新，而非每轮记日志	防止 Agent 自动维护变成“自动制造噪音”	Anthropic 的核心原则是高信号最小上下文；OpenAI 也强调 knowledge base 应保证 freshness，而不是保留所有过程。(Anthropic)
	工作结束留下 clean / resumable state	下一 Agent 可以直接接着做	Anthropic 要求每轮 session 留下 clean state、progress summary 和结构化状态，避免下一轮重新猜测。(Anthropic)
	新状态覆盖旧状态	避免上下文中同时存在多个互相矛盾的当前版本	OpenAI 指出 monolithic knowledge 最大问题之一就是 stale rules，同时专门使用 doc-gardening agent 发现 stale / obsolete documentation。(OpenAI)
	区分事实 / 决策 / 假设 / 待确认	防止 Agent 将自己的推断写成长期事实	OpenAI 强调 agent instructions 应处理 ambiguity、edge cases，并在失败情况下能够 halt / transfer control；Anthropic 同样强调 prompt 必须清晰，但不能硬编码所有逻辑。这四态分类是对此的工程化实现。(OpenAI)
	recyclebin 而非直接删除	保留可追溯性与人工恢复能力	厂商没有规定必须存在 recyclebin；这是你的工程约束。它与 OpenAI 强调 versioned artifacts、历史可追溯的原则一致，但属于你的设计，而不是厂商原话。(OpenAI)
	one-mistake-one-rule	Agent 根据真实失败持续改善	Anthropic 明确建议先使用最小 Prompt 测试，然后根据观察到的 failure modes 再增加明确规则和示例，而非预先塞入所有边界情况。(Anthropic)
	Prompt 结构化分节	Agent 更容易理解各规则职责	Anthropic 推荐使用 Markdown headings 或 XML tags 把 background、instructions、tool guidance、output description 等明确分区。(Anthropic)
人机协作	允许 Agent 主动询问信息	长期项目中的真实状态可能变化	OpenAI 对 Agent 的定义本身包含根据 workflow state 动态决策、在失败或信息不足时将控制权交还用户。(OpenAI)
	增量推进，而不是 one-shot	长项目最常见问题是 Agent 一次试图完成过多工作	Anthropic 在长周期 Agent 实验中明确发现 one-shot 是主要失败模式，并要求每次只推进一个明确 feature，持续 incremental progress。(Anthropic)
	动作必须具体	“主动维护”“注意更新”这种抽象表达执行率低	OpenAI 的 agent instructions 指南明确建议把复杂资料拆成清晰步骤，并让每个步骤对应一个具体 action 或 output。(OpenAI)
	先单 Agent + 文件体系，不先搞复杂多 Agent	控制整个 Context 系统复杂度	OpenAI 建议先最大化 single-agent 能力，仅在复杂度真正需要时再拆 multi-agent。(OpenAI)
	规则本身也应迭代	Context Engineering 不是一次性写 Prompt	Anthropic 将 Context Engineering 描述为持续、循环的 context curation；OpenAI 也通过持续 doc-gardening 维护知识结构。(Anthropic)
	低风险假设继续，高风险问题确认	避免 Agent 要么什么都问，要么什么都猜	Anthropic 建议 Prompt 处于“Goldilocks zone”：既不能硬编码所有逻辑，也不能过度模糊，需要提供 strong heuristics。(Anthropic)
	不要预先穷举所有错误	防止规则越来越复杂、越来越脆弱	Anthropic 特别反对将大量 edge cases 塞入 Prompt，建议选择少量 canonical examples，并从实际 failure modes 中逐步改善。(Anthropic)

2.2 🚏留流程

/ 把高频工作场景固化成SOP/SKILLS

概念辨析 / 大模型(LLMs)、工作流(workflow)、智能体(Agent)、技能(SKILLS)

大模型：具有世界知识，无状态，回复通用回答。无状态 = 缺少业务上下文和默会知识。
懂体育、会分析的同事，能理解比赛信息、生成关键词，但需要告诉他具体业务工作。
工作流：预设流程。提前安排的五步：同步赛程、准备配置队列、生成关键词、自动化配置、回填验收。
只有这五步的定义还不够，智能体无法符合预期地执行。
智能体：有“大脑”(LLM)、可根据情况选择下一步的软件体。你给他需求、验收内容和边界，他根据情况决定下一步，在授权范围内调用工具、推进任务。
能有边界地具体执行：借助大模型思考，调用表格、浏览器和脚本；遇到失败，按规则重试、换路径，或退出等待人处理；约束权力边界，不做越界的事。
SKILLS：专项操作手册和工具包。
写清怎么去重、关键词生成规则、怎么算发布成功、怎么算一个任务结束...
- eg. 如何确认菜单？向顾客发送菜单，经过多轮CRUD和最终确认后得到确认菜单。
- eg. 如何服务？查询服务手册(md文档链接)，里面写有：打招呼欢迎、引导入座、上湿巾/倒茶、点菜、前厅后厨协作(api调用、同步、工单系统...)、...、结账(结账流程)...

它们如何协同？ / 大模型、工作流、智能体、技能

形成 SKILLS / 一个复杂、但可以交给智能体的任务，如何形成稳定可用的 SOP / SKILLS？

按人工完成的流程，定义关键原子步骤
跑通关键/复杂的一步
串联所有流程，跑通，粗糙地开始
持续迭代和优化

2.3 🙅留错误

/ 把错误转化为持久化的后续约束

通过项目规则 one-mistake-one-rule.md 自动维护。

发现可能复发的错误，修正当前结果后，再留下四项信息：错在哪里、正确规则、适用范围、怎样检查。

这是一份名为“错误清单”的记录，表格包含编号、日期、错误简述及详情四栏，用于记录业务场景中可能复发的错误内容。其中被红框标注的两条错误信息为核心重点：一条是2026年09月20日的第05号错误，内容为强制每个逗号分隔的关键词单独输入并按规则生成独立tag，且每个tag必须有独立的“x”删除按钮，仅允许区分关键词组，禁止将多个词作为单个字符串tag提交；另一条是同日的第06号错误，内容为复用早前空映射后才建立的Hotrio在实时调用时的相关设置要求。这些记录用于留存错误的相关信息，方便后续修正和检查。

附 one-mistake-one-rule.md

one-mistake-one-rule.md ↓

3 真实场景应用：亚运召回例子

3.1 任务拆解

/ 按人工完成的流程，定义关键原子步骤

从业务要求看，完成一次召回配置，需要走过这条链路：同步最新赛程 → 筛出待配置记录 → 生成关键词 → 人工核验与微调→ 配置并发布 → 人工检查 → 回读线上结果、回填总表。

其中既有重复动作，也有业务判断。每一条配置需要准确的id、参赛方、比赛名称、项目、时间信息，有时需要web_search补齐原始登记的信息缺失。典型的信息缺失有：比赛性别、(中台未更新时)比赛对阵双方人名。

抽象概括成五步：同步赛程、准备任务队列、生成关键词、配置与发布、回填与验证。

以亚运图文直播召回任务为例，我定义为以下五步：

赛程数据同步
⬇️
准备任务队列
⬇️
关键词生成
⬇️
配置
⬇️
回填与验证

3.2 从零构建 / 如何从零得到一个可自动化工作的智能体？

——从「帮我补表」，到跑通一条配置，到「/update-yayun-recall-kw」

update-yayun-recall-kw 并不是人先写好完整方案，再让 AI 照着执行。它从一句“帮我补齐赛程表”开始，在实际任务中逐步搭建：人提出目标、核对结果、指出问题，AI 编写脚本和操作文档；发现错误后，再一起修改规则、重新验证。

Preview / 最终SKILLS目录结构

亚运图文直播召回/                            # 项目根目录
├── README.md                              # 项目说明、使用入口与目录导航
├── PROJECT_RULES.md                       # 项目级规则、约束与操作规范
├── one-mistake-one-rule.md                # 错误复盘：每个问题沉淀一条规则
├── knowledge/                             # 项目知识库与方法沉淀
│   ├── SOP_dynamic_update.md              # 动态更新流程说明
│   ├── esports-keyword-rules.md           # 电竞项目关键词生成与校验规则
│   └── iteration-history.md               # 项目迭代过程与关键变化记录
├── skills/                                # 可复用 Skill 集合
│   └── update-yayun-recall-kw/             # 亚运召回更新 Skill
│       ├── SKILL.md                       # Skill 的触发条件、流程与使用说明
│       ├── references/                     # Skill 依赖的详细参考文档
│       ├── scripts/                        # Skill 使用的执行脚本
│       └── tests/                          # Skill 脚本的自动化测试
├── reports/                               # 运行结果、分析报告与验证记录
│   ├── baseline/                           # 基线数据与初始状态
│   ├── runs/YYYY-MM-DD/                    # 按运行日期归档的执行产物
│   ├── project-full-history-and-efficiency.md # 项目完整历史与效率分析
│   └── update-yayun-recall-kw-review.md    # Skill 使用效果与复盘报告
└── recyclebin/                            # 暂存的旧文件与历史版本
    ├── legacy-root-files/                  # 原根目录文件的历史版本
    └── legacy-skill-scripts/               # 旧版 Skill 脚本

😀

留背景，给智能体一个施展拳脚的空间。让智能体拥有业务视角和长期记忆，从重复和烦躁中彻底解脱。

根据实际体验，约 95% 的代码和文档编写由 Agent 编写与自动维护。人的主要投入在两方面：

提供通用知识：通用 Agent 项目规则约束；
提供业务知识：业务判断、抽查验收和纠偏；定义权限边界、可信、成功态、异常与终止。

SKILLS诞生的各阶段：

阶段	人如何指导和验收	AI 完成什么	沉淀下来的能力
先帮忙补表	指定目标表、需要补的字段，抽查结果	取数、整理数据、编写补表脚本	写前重读表头、按字段名定位、写后回读
先跑通一条配置	明确关键词、参数和发布成功的标准	操作 HotRio，排查输入、保存和发布问题	单条配置闭环，验收通过才回写状态
扩展到批量取数	指出漏赛程、同名比赛误合并、晚建直播间等问题	修改采集、分页、去重和重查逻辑	系统 ID 判重、完整性检查、空映射复扫
扩展到批量配置	检查批量结果，指出“保存成功但未发布”等误判	增加逐条验收、失败记录和恢复机制	批次隔离、发布回读、幂等恢复
整理成 Skill	确定默认处理范围、权限边界和验收口径	整理入口说明、SOP、脚本和运行记录	可重复调用的五步流程：同步、迁移、关键词、配置、回填验收

「跑通关键/复杂的一步」

攻破困难节点。上述流程中，瓶颈有两个：赛程数据同步和关键词配置。

赛程数据同步：需打通一条链路——赛程数据抓取 -> 飞书列表读取 -> 数据处理与判等。需要人找到抓取的可行链路，提供飞书权限，确定列表字段定义以及判等逻辑。
关键词配置：需探索 Aime 或 Trae 等 Agent Harness 工具能否/如何实现自动化配置，涉及鉴权、前台自动化或后台提交。
可行的路径有 computer-use、browser-use、Tool Use、API、脚本与CLI、MCP、skills，以及前面若干工具的混合方式。

明确瓶颈后，人工或人xAgent合作跑通某一条智能体可执行的路线，然后让智能体自己记录可复现的“说明书” => skills的雏形。

「串联所有流程，跑通，粗糙地开始」

关键节点解决后，剩下的就是打通整个流程。我的理念是先盖草屋再盖城堡，因此搭建期不追求一步做到完美，而是先跑通最小闭环。

「准备任务队列」的核心能力是飞书表格操作，在「赛程数据同步」步骤中已跑通，只剩判等与迁移，先用赛程id判等、最小介入让智能体做数据填充
「关键词生成」迅速写好关键词召回逻辑与若干条基本规则（保准尽召），保证上线不出错
「回填与验证」非MVP必须，丢弃
规定最朴素的串行流程——前一节点关闭自动进入下一节点
直接开始首次测试

Aime神力-配置亚运召回关键词.mp4

Aime 正在

3.3 持续迭代和优化

流程跑通只是起点。真正的迭代，发生在流程遇到真实问题之后：从局部修复变成全量审计，从接口结果变成多源取证，从“执行完成”变成“回读证明”，从一次性错误变成长期规则，再从全量重跑变成增量探测和断点恢复。
迭代的目标是扩大系统泛用性与逐渐收敛行为边界。让系统在数据变化、页面变化和部分失败的情况下，仍然知道哪些可以继续、哪些必须停下来交给人判断。

三条主线：

浏览器操作与API重新分工。早期靠浏览器完成逐页操作、点选和录入等80%以上工作；后续调整为仅负责登录态、关键页面核验
加速时间瓶颈的步骤、流程精简。不是让AI点的更快，而是减少不必要操作：不重复写、不重复发、失败范围重试
复盘闭环到未来收益——优化与杜绝。下一轮产生实际收益、更高可用性。

迭代收益

无工具：09/16 的 1–3 分钟，逐步上升到 09/26 及以后 5 分钟以上。
有工具：从 1–3 分钟逐步降到 0–0.2 分钟。
累计运营节省按新基线重算，约 60 人时。
功能研发投入仍按功能拆分估算为 20–32 人时。

这张图对应“3.3持续迭代和优化”部分的内容，分为上下两个核心区域，清晰展示了亚运召回场景下使用工具前后的相关数据对比。上半部分是人工投入时间的变化，红色折线代表无工具时，人工投入时间从09/16的2分钟左右逐步上升至09/20及以后的5分钟以上；蓝色折线代表有工具时，人工投入时间从初始的2分钟左右逐步下降至09/26及以后趋近于零，同时标注了对应场景的操作细节。下半部分为人力投入数据，绿色圆点折线对应累计运营节省，按新人工基准估算约60人时，橙色圆点折线对应功能研发投入，约为20-32人时，整体体现了该场景下AI工具迭代带来的人力效率提升。

运行效率

自动化单条配置平均时间从5分钟+/条降至约1.5分钟/条

附-迭代内容表

	迭代方向	遇到问题	迭代内容	效果
操作API化	浏览器操作改为 API 批量取数	逐条打开浏览器页面，速度慢，也容易受到页面加载和登录状态影响	用 API 批量获取赛事、时间、状态、参赛方和 liveID；浏览器只负责登录态、页面核验和最终配置	一次可以读取 25 页、1202 条赛事；全量映射得到 871 条 HotRio，331 条确认无映射，0 条请求失败
操作API化	API 与浏览器分工	API 适合批量读取，但无法完全证明页面上的发布状态；浏览器适合核验，但不适合大批量读取	结构化数据交给 API，关键名称、页面区块和发布状态交给浏览器；两边结果交叉核对	GIP 管理页不可用时，仍能用 API + 浏览器页面完成流程；13 条配置全部通过线上发布验收
流程优化	从全量写入改为增量写入	每轮都重写整张表，容易覆盖人工修改，也浪费时间	每轮先建立线上和表格快照，只计算真正发生变化的单元格，再做最小写入	一轮 1202 条线上赛事只更新 8 行、19 个单元格；队列内容保持不变，避免无变化写入
	从“跑完”改为“先审计再决定是否执行”	没有新增任务时，仍可能重复生成关键词、保存配置或发布	先判断新增、变化、待处理任务和异常；如果执行集合为空，明确生成空批次，不触发写操作	1237 条主表、679 条队列完成全量核验，未发布数为 0，且本轮没有无意义的线上写入
	解决浏览器实例定位问题	Chrome 重启后 PID 会变化；电脑上同时存在多个 Chrome，固定 PID 或只看应用名可能选错实例	改成每次运行动态发现普通用户 Chrome；排除临时 profile、远程调试实例和隔离浏览器，并用目标标签和无副作用探针确认	Chrome 重启后仍能重新定位；不再依赖旧 PID；双 Chrome 环境下也能选择正确实例
	解决浏览器桥接的大批量传输问题	1202 条结果一次通过 Apple Event 回传，超过稳定传输大小，导致任务看起来超时	改为先取小状态，再按 32KB 分块回收结果；浏览器任务和结果读取分离	全量映射最终稳定回收；1202 条中 871 条有 HotRio、331 条无映射、0 条失败
	从一次失败重跑，改为按失败类型重试	84 条记录出现 Failed to fetch，不能直接判断为没有 HotRio	将结果分为 FOUND、NOT_FOUND、FAILED；只重试失败批次，重试前补齐原始日期等必要字段	84 条重试后得到 62 条 FOUND、22 条 NOT_FOUND、0 条 ERROR；未知结果清零
	修复数据解析和身份定位	飞书 CSV 中单元格有换行，按物理行解析会错位；部分历史记录没有 Contest ID	改用逻辑行解析；身份定位按“Contest ID → HotRio ID → 名称与日期”逐级回退	修复了闭幕式时间从 17:00 到 16:00 的变更，并补回缺失身份；11 行、27 个单元格完成准确更新
自进化	把 AI 复盘变成代码和 SOP 的更新	每次异常都靠人重新解释，问题容易重复出现	AI 根据运行日志定位根因，再同步修改脚本、SOP、规则和回归检查	例如把“响应结构变化误判为空映射”“旧 PID 固定写入”“大批量结果一次回传”等问题，转成长期规则
泛用性	让 AI 参与“是否应该继续”的判断	页面异常时，盲目重试可能造成重复写入或误发布	AI 先判断是接口失败、页面未初始化、目标区块不存在，还是浏览器桥接阻塞；不确定时先停止写入	遇到 74 个页面没有目标区块时，只成功配置 1 条，其余安全保持“待输入”，没有误改状态
历史记录	加入运行账本和证据归档	任务完成后很难知道改了什么、为什么改、是否真的生效	每轮保存基线、revision、changeset、失败分类、回读结果和最终报告	后续可以比较两轮差异，确认本轮是否真的写入；无变化运行也有完整证据链

项目级关键文件

README.md

PROJECT_RULES.md

one-mistake-one-rule.md

业务知识的map。

README 最常用于开源项目，用来介绍项目、安装运行方法、使用示例，以及如何参与开发。

随着 AI 智能体参与工作，README 也称为 AI 理解项目的入口，把人的经验变成可读取的项目知识。

限制行数：100行。

只做必要的背景、任务、目标陈述，不展开细节；
提供当前状态与关键约束，方便更好地继续工作；
提供文档地图，方便查询、交接和新智能体冷启。

通用知识。

参考 OpenAI / Anthropic 官方分享与开发者最佳实践，非重代码/开发项目可通用的项目规则。

本质是 Context Engineering(上下文工程) 、项目管理，以及大模型注意力管理。为大模型提供复杂、有持续维护需求的工程方法论。

业务知识。

来自 Mitchell Hashimoto，一位美国软件工程师和创业者，Harness Engineering 概念提出者，HashiCorp 联合创始人。

由 PROJECT_RULES.md 衍生。（通用工程框架实际发挥作用的可视化呈现；）

给智能体犯的错提供长期记忆能力。为什么是“提供”？不持久化地记录错误，宝贵的人工信号大概率淹没在历史对话记录里，下一次还犯。

消除人的烦躁焦虑感：下一次能不能避免不知道，至少它被确确实实地落盘了（体感上绝对能降低同一错误再犯的经历；能让你的项目在复杂度增加时，出现管理、推进困难的时间推迟很多）

(为模型)提供深度思考和探索解决方案的原料：(人的)长期记忆是深度思考的基础；降低同类错误再次发生的机会。

README.md# 亚运图文直播召回

## 项目背景与目标

2026 亚运会期间，从 GIP 体育平台持续同步比赛、直播间和 `tabID=27` HotRio 映射，生成召回关键词，在 HotRio“热点资讯”子区块完成配置发布，并将线上真值回填飞书总表。

目标是让赛程汇总表、Aime 任务队列和 HotRio 线上配置保持一致；任何新增、变化、缺映射或发布异常都可追踪并经过回读验收。

## 当前工作

按五步流程持续增量维护：

1. 全量同步线上赛程，完成分页断言与反向差集。
2. 将可执行的未发布记录迁入 Aime 任务队列。
3. 生成并校验召回关键词。
4. 配置、发布并回读 HotRio“热点资讯”子区块。
5. 按线上真值回填总表并执行排序、身份集合和内容一致性验收。

## 当前状态

| 项目 | 当前值 |
|---|---|
| 赛事 | 2026 亚运会，competition ID `1159` |
| 日期范围 | 2026-09-10 至 2026-10-04 |
| 飞书表格 | [亚运会 2026 比赛直播间 Hotrio ID 汇总](https://bytedance.larkoffice.com/sheets/DJKosVnffhAqAFt3ffrc337Ln0b) |
| 赛程汇总表 | `sheet_id=tigW77`，1237 条数据行 |
| Aime 任务队列 | `sheet_id=KJikOj`，679 条数据行 |
| 最近完整运行 | 2026-10-05 18:03，线上 1202 条、无新增；更新 8 行 19 格，最终 revision `2532` |
| 最近专项优化 | 2026-10-01 21:26，队列第 436 行冲突已覆盖、配置发布并回填，最终 revision `2503` |
| 下一步 | 持续监控闭幕式和最终赛程状态；审查 8 组历史重复 Contest ID / HotRio ID |

## 关键约束

- API 不是唯一数据源；失败时按浏览器、抓包、电脑操作、API 兜底顺序切换。
- 比赛身份以 `(eventID, contestID, liveID, scheduledStartAtMs)` 为权威依据，不能仅凭名称或参赛方去重。
- HotrioID 优先用按日期分页的 live-room 列表 API 批量获取，只取 `tabID=27` 的非空 `amosID`；API 不可判定时回退 live 实体页。
- 发布状态只认 `title=热点资讯 && type=10000006` 子区块，保存真值只认 BSON `recall_forum_info.t_form_input`。
- 飞书写入必须最小改动、写前重读表头、写后逐项回读；空映射必须重试并在任务收尾复扫。
- eventID 不能单独推断赛事性别；无法确认时留空并标记人工确认。

## 文档地图

| 路径 | 职责 |
|---|---|
| `PROJECT_RULES.md` | 项目通用 Context Engineering 与文档维护规则 |
| `knowledge/asian-games-data-rules.md` | 亚运数据采集、飞书写回、HotRio 校验专项规则 |
| `knowledge/SOP_dynamic_update.md` | 动态赛程同步与表格更新 SOP |
| `knowledge/errors/` | 可复发错误的详细案例 |
| `knowledge/esports-keyword-rules.md` | 电竞关键词专项设计 |
| `one-mistake-one-rule.md` | 可复发错误与强制规则索引 |
| `skills/update-yayun-recall-kw/` | 五步召回更新 Skill |
| `knowledge/iteration-history.md` | 详细迭代历史 |
| `reports/update-yayun-recall-kw-review.md` | Skill 成熟度、风险与迁移说明 |
| `reports/project-full-history-and-efficiency.md` | 项目全记录、阶段演进、研发投入与人力节省估算 |
| `reports/runs/` | 已完成运行的日志、回读真值与最终结果 |
| `recyclebin/` | 已失效或一次性文件，只归档不直接删除 |
## 核心脚本与产物

| 路径 | 说明 |
|---|---|
| `scripts/fix_comprehensive.py` | 主数据采集与修复脚本，支持 `--dry-run` |
| `scripts/hotrio_browser_batch.py` | 动态发现普通用户 Chrome PID，分页抓取赛程、批量取映射并审计、配置、发布 HotRio |
| `scripts/plan_row_moves.py` | 按日期时间显示值生成稳定的最小整行移动计划 |
| `scripts/audit_schedule_identity.py` | 审计 Contest ID 缺失、重复及备注中的系统身份 |
| `reports/baseline/asian_games_hotrio.json` / `.md` | 2026-09-20 历史基线，不得代替实时查询 |
| `reports/runs/2026-10-05/final-run-results-20261005T175132CST.json` | 最近完整运行结果 |
| `reports/runs/2026-10-01/final-run-results-20261001T211158CST.json` | 最近历史冲突覆盖、发布与回填结果 |
| `reports/runs/2026-09-30/performance-and-api-analysis-20260930.md` | 本轮耗时拆分与 live-room 列表 API 实测 |
| `reports/runs/2026-10-05/step4-results-20261005T175132CST.json` | 最近 HotRio 写入批次的线上回读真值 |
| `reports/runs/2026-10-05/run-20261005T175132CST-liuboji.jsonl` | 最近运行日志 |

## Iteration

### 2026-10-05

- 17:51 完整五步更新：线上 25 页仍为 1202 条、无新增；同步 8 行 19 格，包含 6 处参赛信息、4 处阶段、1 处闭幕式状态及 8 个备注日期。
- 映射首轮 84 条请求失败全部重试恢复，331 条空映射复扫无未知；未发布候选、关键词、HotRio 发布和回填均为 0，最终 revision `2532`。

### 2026-10-04

- 12:11 完整五步复跑：线上 25 页仍为 1202 条、无新增或事实变更；空映射 331 条复扫无请求失败，反向差集和日期时间逆序均为 0。
- 未发布候选、关键词、HotRio 发布与回填均为 0；主表 1237 条、队列 679 条，首尾快照逐字节一致，最终 revision `2531`。
- 浏览器大结果改为 32KB 分块回收并增加有限超时重试；新增 Rule023，阻塞恢复只重建本轮 Agent 创建的标签。

### 2026-10-03

- 完整五步更新：线上 25 页共 1202 条唯一 contest，新增 27 条正式独立赛程；同步 14 行既有事实，14 次 LIS 最小整行移动后逆序 0。
- 未发布候选 25 = 迁移 24 + 隔离 1；24 条关键词、发布与队列回写全部通过，27 条线上真值回填主表。网球男单决赛保留人工配置，仅回读同步。
- 最终主表 1237 条、队列 679 条、revision `2525`；仅余第 823 行旧标枪聚合项未发布，8 组历史重复身份未改动。
- Chrome 绑定改为每次命令动态发现普通用户实例；PID 变化可自动恢复，隔离/远程调试实例会被拒绝。

### 2026-10-01

- 19:43 完整五步更新：线上 1175 条、同步 149 行事实，6 次 LIS 最小整行移动后逆序 0，revision `2499`；早前 16 条新增网球赛程均完成关键词、发布、终审和回填。
- 21:26 专项处理队列第 436 行电竞冲突并发布回填，revision `2503`；整行移动规划器改为 LIS 最小移动算法并增加回归测试。

### 2026-09-29

- 完成多轮增量同步、父子比赛真值回填与 28 条发布；最终主表 1157 条、逆序 0，并明确 live-room 请求失败必须按 error/未知处理。
- 项目规则、README 与目录结构完成职责拆分；详细过程迁入 `knowledge/iteration-history.md`，失效资料归档至 `recyclebin/`。

PROJECT_RULES.md# 项目通用规则

## 0. 项目规则

规则持久化要求：本文档固定保存于项目根目录 `PROJECT_RULES.md`，作为项目级长期工作规则。

除非用户明确修改，否则持续有效。开始复杂任务、跨会话继续工作、更新项目文档前，应先读取本文件、`README.md` 与 `one-mistake-one-rule.md`；不得仅依赖聊天历史记忆本规则。

## 1. Context Engineering：持续维护项目上下文

你不仅负责完成当前任务，还负责维护本项目可持续工作的长期上下文。

目标是使任何新的 Agent 会话都能够：

快速理解项目 → 找到所需信息 → 正确继续工作 → 将新的有效信息沉淀回项目。

核心原则：不要依赖聊天历史作为项目的唯一记忆。

### 1.1 README.md：项目地图，而不是项目百科

`README.md` 是项目最高层级的上下文入口与路由文件，默认控制在 100 行左右，原则上不超过 100 行。

README 只维护继续本项目所必需的高信号信息：

- 项目背景：为什么做、解决什么问题；
- 项目目标：期望最终达到什么状态；
- 当前工作：本项目实际正在执行的工作；
- 当前状态：当前阶段、已经完成什么、正在推进什么；
- 关键信息：核心指标、重要方案、关键结论、重要约束；
- 文档地图：重要文件及其职责、路径；
- 迭代记录：项目发生的重要变化。

README 主要承担：Map + State Snapshot + Routing，而不是承担完整知识库职责。

当某部分开始出现较多背景说明、方法细节、案例、调研资料、历史过程或专项规则时，应将其拆分至独立文件，在 README 中仅保留：一句摘要 + 文件路径 + 必要时的当前结论。

### 1.2 按需加载上下文，不默认读取全部项目文件

执行任务前，优先获取完成当前任务真正需要的信息。

默认读取路径：

`README.md` → 与当前任务有关的规则 / 路由 → 相关 `knowledge/` / `reports/` / `scripts/` → 仍存在信息缺口时继续检索

不得因为项目中存在大量资料，就默认将全部资料加载进上下文。

遵循 Progressive Disclosure：先获得项目地图，再根据任务逐层获取细节。

上下文的目标不是“越多越好”，而是：在足以正确完成任务的前提下，尽可能保持高信号、低冗余。

### 1.3 项目知识必须从对话中持续沉淀

多轮交互中出现的长期有效信息，不应只停留在聊天记录。

主动识别并沉淀：

- 已确认的项目事实；
- 用户长期有效的要求；
- 指标定义与统计口径；
- 已确定的方案与决策；
- 重要结论；
- 可重复使用的方法和流程；
- 后续任务会依赖的背景知识；
- 外部调研形成的稳定结论。

根据内容性质：更新已有文档；或写入 `knowledge/`；只有当现有文档无法合理承载时，才新建文档。

遵循：优先更新已有文档 → 其次扩展已有结构 → 最后创建新文件。

禁止因每次任务不同而不断创建重复、职责相近的文档。

### 1.4 区分信息的确定性

维护项目上下文时，必须区分：

- **已确认事实**：用户明确提供，或已有可靠资料明确支持的信息。
- **当前决策**：当前阶段已经采用的方案或规则，但未来允许调整。
- **合理假设**：为了继续工作，根据现有信息做出的低风险推断。
- **待确认事项**：目前信息不足，且可能显著影响后续工作的关键问题。

不得将合理假设自动升级为已确认事实。

对于低风险、容易修改、不会明显影响最终方向的问题，可以采用合理假设继续推进，不必频繁打断用户。

对于可能影响项目方向、核心指标、重要方案、资源投入、长期规则或最终结论的信息，应主动请求用户确认。

### 1.5 允许主动对齐，而不是被动等待信息

Agent 不应只依赖用户主动补充信息。

在项目持续推进过程中，如果发现存在关键事实缺失、当前状态可能已经变化、多种理解可能导致明显不同结果或长期未确认的重要假设，可以主动向用户发起简短对齐。

推荐格式：

> 当前我理解：A：……B：……C：……其中 D 尚未确认，我暂时按 X 处理。如果现状已经变化，请更新我。

主动确认应当有明确价值。不得因为轻微或无关紧要的不确定性频繁询问用户。

### 1.6 上下文采用事件驱动维护

不是每轮对话都必须修改项目文档。

只有当出现具有未来价值的状态变化时才更新上下文，例如：

- 新增重要事实；
- 用户修改之前的信息；
- 目标发生变化；
- 项目阶段发生变化；
- 指标或统计口径发生变化；
- 形成重要决策；
- 形成可复用方法；
- 新建、替换或废弃重要文件；
- 发现已有上下文存在错误、冲突或过时。

普通讨论、尝试性思考、临时问答、无长期价值的操作过程不需要沉淀。

判断标准：未来新的 Agent 如果不知道这件事，是否可能降低工作质量或给出需返工的工作结果？

如果答案为“是”，通常应沉淀。

### 1.7 新信息优先修正旧状态，而不是简单追加

当新信息与已有上下文冲突时：

1. 判断哪一个代表当前有效状态；
2. 更新当前事实或当前决策；
3. 删除或修改已经失效的表述；
4. 必要时在迭代记录保留变化过程。

不要同时留下多个互相冲突的“当前状态”。

项目文档应优先表达：**现在**什么是正确的。

历史只有在具有追溯价值时才保留。

### 1.8 每日迭代记录只记录重要变化

只要某个自然日项目发生实质性变化，应在 README 的 Iteration 中维护当天记录。

同一天继续发生变化时，更新当天已有条目，不重复新增同一天日期。

只记录：

- 完成的重要工作；
- 新形成的决策；
- 关键指标变化；
- 项目阶段变化；
- 方案调整；
- 重要文件新增、重构或废弃；
- 影响后续工作的重大信息。

不要把迭代记录写成聊天日志或操作流水账。

例如：

```markdown
## Iteration
### 2026-09-17
- 评论策略确定采用「判断层 → 生成层」两阶段架构。
- 新增 `knowledge/value-system.md`，统一维护价值判断体系。
- 评估口径由二分类调整为准确 / 存疑 / 不准确三级。
```

### 1.9 工作必须增量推进并留下可继续状态

复杂任务应优先采用增量方式推进，而不是试图一次完成整个项目。

每次重要工作结束时，应尽可能让项目处于下一次 Agent 可以直接继续工作的状态。

必要时更新：

- 当前状态；
- 已完成内容；
- 下一步；
- 未解决问题；
- 相关文件。

避免出现做了大量工作，但项目文件中没有任何记录，下一轮 Agent 只能重新推测发生了什么。

对于复杂、持续时间较长的专项任务，可以自动创建独立 progress / plan 文档。小任务不需要额外制造进度文件。

### 1.10 自动维护文档生命周期

项目知识应持续整理，而不是只增加不清理。

工作过程中主动识别：

- 重复文档；
- 已失效方案；
- 被新文档完全替代的旧版本；
- 长期无人使用的临时文件；
- 职责重叠文档；
- 与当前事实冲突的资料；
- README 中已经失效的路由。

处理原则：

- **合并**：内容高度重复时，合并至一个权威文件。
- **更新**：旧文档仍有价值但内容过时时，直接维护其最新状态。
- **归档**：已经失效但可能需要追溯的文件，移动到 `./recyclebin/`，默认不直接永久删除项目资料。

### 1.11 保持单一事实来源

同一个核心事实或规则，应尽可能只有一个主要维护位置。

其他文件可以引用，但不要复制并分别维护多个版本。

例如：

- `README.md` → 当前指标：见 `knowledge/metrics.md`
- `knowledge/metrics.md` → 指标的完整定义与统计口径

当一个事实发生变化时，应优先修改其 Source of Truth，而不是修改所有副本。

如果多个文件存在冲突，应主动统一。

### 1.12 README 必须始终可作为新 Agent 的启动入口

应周期性检查 README 是否仍能回答：

1. 这个项目是做什么的？
2. 当前目标是什么？
3. 现在推进到哪里？
4. 最重要的事实和约束是什么？
5. 我要继续某项工作应该去哪里找资料？
6. 最近项目发生了什么重要变化？

如果无法回答，则 README 需要维护。

如果回答这些问题需要大量细节，则相关细节应该拆分到其他文件。

### 1.13 one-mistake-one-rule：让项目从错误中增长

Agent 工作中出现具有复发风险的错误时，应执行：One Mistake → One Rule。

将错误沉淀为新的行为约束。

`one-mistake-one-rule.md` 只维护：

- 错误名称；
- 简要错误描述；
- 正确规则；
- 详细案例文件路径。

复杂错误允许创建独立 Markdown 文件，记录背景、Agent 当时做了什么、为什么错误、正确做法、正确示例和后续规则。

已经记录的错误禁止无理由重复发生。

不要记录一次性、偶然且没有普遍意义的小问题。

### 1.14 Context 应通过使用结果持续优化

规则本身也不是永久不变的。

如果发现 Agent 经常误解某条规则、某类错误持续发生、某个工作流程反复需要相同解释、某项上下文经常找不到、README 越来越难导航或文件体系出现明显摩擦，应将这些视为 Context Engineering 的问题。

优先通过以下方式解决：

1. 改善文档结构；
2. 改善路由；
3. 改善规则表达；
4. 增加少量典型示例；
5. 增加必要的自动检查。

不要第一反应就在 Prompt 中增加更多规则。规则增长必须来源于真实失败，而不是预先穷举所有可能情况。

### 1.15 默认项目结构

```text
.
├── README.md
├── one-mistake-one-rule.md
├── PROJECT_RULES.md
├── knowledge/
├── reports/
├── scripts/
└── recyclebin/
```

职责：

- `README.md`：项目地图、当前状态、核心信息、文档路由、迭代记录。
- `one-mistake-one-rule.md`：Agent 错误经验与规则索引。
- `PROJECT_RULES.md`：本规则的拷贝，项目根目录下的固定规则文件，作为项目长期有效的工作约束。
- `knowledge/`：长期项目知识、定义、方法、调研、方案、专项说明。
- `reports/`：主要面向人阅读的阶段性和最终输出。
- `scripts/`：项目脚本、数据处理、自动化工具。
- `recyclebin/`：已废弃、被替换但仍保留追溯价值的文件。

除非现有结构明显无法表达项目内容，否则不要随意增加一级目录。

---

## 最终判断原则

维护 Context 时始终问：下一次完全没有当前聊天历史的 Agent，能否仅通过项目文件快速理解现状并继续工作？

如果不能，就补充必要上下文。

同时再问：这些信息是否真的值得占用下一次 Agent 的注意力？

如果不值得，就不要进入核心上下文。

one-mistake-one-rule.md# 一错误一规则

> 记录智能体工作中的错误。记录过的错误禁止再犯。

---

## 错误清单

| 编号 | 日期 | 错误简述 | 详情 |
|:--:|------|------|------|
| 001 | 2026-09-16 | 假设同大项的事件性别相同 | [001-event-gender-assumption.md](knowledge/errors/001-event-gender-assumption.md) |
| 002 | 2026-09-16 | 大项名称映射不完整 | [002-sport-name-mapping.md](knowledge/errors/002-sport-name-mapping.md) |
| 003 | 2026-09-17 | 同一 eventID 下男女赛事混用，性别前缀映射不可靠 | [003-event-gender-same-eventid.md](knowledge/errors/003-event-gender-same-eventid.md) |
| 004 | 2026-09-20 | 新增识别去重键缺陷：仅凭队名误判重复，漏收跨事件/跨时段比赛 | [004-dedup-key-missing-eventid.md](knowledge/errors/004-dedup-key-missing-eventid.md) |
| 005 | 2026-09-20 | HotRio 关键词组内多个词被错误合并为一个 tag，导致召回配置失效 | 强制每个逗号分隔的关键词单独输入并按回车生成独立 tag；每个 tag 必须有独立的 × 删除按钮。分号只用于区分关键词组，绝不允许把组内多个词作为一个字符串 tag 提交。 |
| 006 | 2026-09-20 | 复用早先空映射，漏掉稍后才建立的 Hotrio | 每次更新必须对所有空 HotrioID 行实时调用 `live-rooms/{liveID}`；任务结束前再做一次空值二次扫描，禁止把早先“未创建”当成当次结论。 |
| 007 | 2026-09-20 | 未区分 Hotrio Tab，或未逐页抓全，导致对阵直播间漏收 | 只取 `tabHotrioMappings` 中 `tabID=27` 的 `amosID`；赛事列表翻页直到短页，并以线上 contest/liveID 集合对表格做反向差集验收。 |
| 008 | 2026-09-20 | 补齐 HotrioID 后未同步读取配置，导致“已发布？/关键词/排序方式/关键词匹配/最近发文时间”为空或沿用旧值 | 完整流程中 HotrioID 与五项配置字段最终必须对齐线上；Step 1 只同步赛事事实与发布状态，Step 5 使用发布后页面回读统一写回五项配置，禁止用接口默认值冒充线上配置。 |
| 009 | 2026-09-21 | 只使用 GIP 简写标题，丢失“女子/男子、团体赛/个人赛”等关键限定 | GIP `contests.title` 可能是简写。对有 Hotrio ID 的记录必须用 HotRio 页面运营标题交叉核验；名称字段只写完整赛事名，参赛双方写入独立“参赛”字段。写前逐条检查性别、团体/个人、项目限定均未丢失。 |
| 010 | 2026-09-21 | 关键词使用长国家名并加入排名赛/淘汰赛等阶段词，导致召回过严 | 国家/地区使用自然且稳定的短称（如吉尔、哈萨、印尼、香港、澳门、台北）；禁止把排名赛、淘汰赛、冠军赛、小组赛等阶段词作为召回约束。关键词以“双方短称 + 项目/性别/团体属性”的短词交集为主。 |
| 011 | 2026-09-24 | 把 HotRio 外层容器“已发布”误判成“热点资讯”子区块已发布 | [011-hotrio-container-status-not-block-status.md](knowledge/errors/011-hotrio-container-status-not-block-status.md) |
| 012 | 2026-09-27 | HotRio 只发布默认配置，或修改错误 BSON 层导致关键词未真正写入 | [012-hotrio-default-config-and-bson-input.md](knowledge/errors/012-hotrio-default-config-and-bson-input.md) |
| 013 | 2026-09-27 | 浏览器回传的 `bsonRawData` 形态与落盘快照不同，直接 `bytes(value)` 解码失败 | HotRio 浏览器接口回传值可能是 `{"data":[...]}`，历史落盘也可能是裸字节数组；解码前必须统一归一化为 `raw.get("data", []) if isinstance(raw, dict) else raw`，再执行 BSON 解码。 |
| 014 | 2026-09-28 | live-room API 响应包装层变化后仍按旧路径读取，误判 `tabID=27` Hotrio 不存在 | 兼容读取 `data.liveRoom` 与顶层 `liveRoom`，按 `tabID` 建索引后只取 `tabID=27` 的非空 `amosID`；空映射至少重试 3 次，任务收尾再全量复扫所有因缺映射而“暂不处理”的记录。 |
| 015 | 2026-09-29 | 飞书原生排序按内部存储类型分组，显示相同的日期文本仍产生逆序 | 新增或更新日期/时间后，排序验收必须按显示值全量计算相邻逆序；若原生排序因混合存储类型留下逆序，禁止直接交付，改为按显示值将异常行整行移动到正确位置，并再次断言逆序为 0。 |
| 016 | 2026-09-29 | 把 live-room 请求失败写成 warning，且未区分“确认无 Hotrio”与“未知” | 请求成功且确认没有 `tabID=27` 才能记“确认无 Hotrio”，这是正常结果、不计 warning；`TypeError: Failed to fetch`、超时、认证或网络/CORS/代理链路失败均表示 HotRio 状态未知，必须记 error。Step 1 汇报同时列出“已确认有/已确认无/未知”三类。 |
| 017 | 2026-09-30 | live-room HTTP 502 后未切换 live 实体页，导致 29 条已有 Hotrio 映射被误留为未知 | live-room 不可判定时必须打开 `https://hot.bytedance.net/main/v2?entityType=live&id={liveID}`，在“完整 Tab 配置”中读取 `Tab ID=27 / 看点` 的 Hotrio ID；只有 API 与页面回退都失败时才记未知和 error。 |
| 018 | 2026-09-30 | 发布接口成功后立即回读，把尚未异步收敛的区块误报为发布失败 | 发布响应成功后轮询刷新，直到 `status=3 && onlineVersion=version` 或达到明确超时；首次短延时回读不一致只表示状态尚未收敛，不能提前写成功，也不能直接认定最终失败。 |
| 019 | 2026-09-30 | 历史“待修改/待输入”记录直接重配，忽略线上可能已正确发布 | 补跑历史队列必须先批量只读 audit；线上配置与队列期望完全一致时只回填“已输入”，不重复保存或发布。只有配置不一致且关键词已校验的记录才进入重配。 |
| 020 | 2026-10-01 | 逐个修复相邻逆序不等于最少整行移动 | 排序规划必须先对目标顺序计算最长递增子序列（LIS），只移动非 LIS 行；新增回归测试覆盖“贪心需 2 次、最优仅 1 次”的排列，执行后仍需断言逆序为 0 且全行多重集不变。 |
| 021 | 2026-10-01 | 稀疏批量写入凭近期区块硬编码范围，漏掉更早的目标行 | 写入范围必须由完整目标行集合的最小/最大真实行号推导，并在请求前断言每个目标行都落入范围；写后全量比较计划与实际 changeset，漏项立即补写，禁止只抽查首中末。 |
| 022 | 2026-10-01 | 多个同 Bundle ID 的 Chrome 使普通 AppleScript 投递到错误实例 | 不得暂停、关闭或终止其它实例。每次命令动态枚举 Chrome，排除临时 profile/远程调试实例，再用目标标签与 JavaScript 探针唯一确认用户 Chrome；通过 ScriptingBridge 按本轮 PID 执行。Chrome 重启后重新发现，禁止缓存 PID或使用模糊 AppleScript。 |
| 023 | 2026-10-04 | 大批次执行期间过早轮询、或一次性经 Apple Event 回传完整结果，导致桥接队列阻塞 | `map-live` 启动后先等待 60 秒再发首个轮询；轮询只返回任务状态和序列化长度，完整结果按不超过 32KB 分块回收并处理代理对边界。只读 Apple Event 超时可有限重试；持续阻塞时只允许重建本轮 Agent 创建的标签，禁止关闭用户原有标签或干预其它 Chrome 进程。 |

---

## 通用规则

1. **不假设**：同一 sportID 下的不同 eventID 可能有不同的性别/属性，必须逐条从页面验证
2. **不全则缺**：名称映射必须覆盖全部可能值，不能只映射已知的几种
3. **页面为准**：API 返回的标题可能不完整（如缺失性别前缀），必须以页面显示的名称为准
4. **验证优先**：修复后必须逐条抽查校验，特别是边界情况（如跨性别事件）
5. **eventID 不可靠**：同一 eventID 下可能同时存在男女赛事（如排球 2145307），不能仅凭 eventID 推断性别
6. **身份靠 ID 不靠名字**：判定两场比赛是否相同，权威键为 `(eventID, contestID, liveID, scheduledStartAtMs)`；参赛方/标题名称永远不得单独作为去重依据；队名无序匹配仅限同 eventID + 同开赛时间内使用
7. **反向覆盖审计**：每次比对必须逐事件列出"线上有、表内无"的全部 contest，并核对计数，防止漏收
8. **写前重读表头**：列位置可能被人工调整，每次写入前必须重新读取表头并按当前列位置组装数据，禁止盲写
9. **对阵顺序规范化**：表内统一按 API side=home 在前记录，避免顺序不一致造成人工漏看
10. **HotRio 关键词逐词成 tag**：分号用于划分关键词组；组内逗号分隔的每一个词都必须单独输入并按回车，形成带独立 × 删除按钮的 tag。禁止把“乌兹，日，女子团体”整体作为一个 tag；验收时必须逐词核对 tag 数量和内容。
11. **空 HotrioID 必须实时重查**：每次总表更新都对全部空 HotrioID 行调用 `live-rooms/{liveID}`；任务收尾前必须二次扫描，覆盖晚建直播间。
12. **tabID 不能混用**：看点 HotrioID 固定取 `tabID=27` 的 `amosID`，不得误取 `tabID=25`。
13. **分页必须跑到短页**：必须记录抓取页数、总条数和唯一 contestID 数；固定页数、首屏结果或旧缓存均不得作为完整数据集。
14. **线上反向差集必须为零或逐条解释**：以 `(contestID, liveID, scheduledStartAtMs)` 对比线上与表内；每个差异都要新增或留下排除理由。
15. **HotrioID 与配置字段必须原子补全**：凡 HotrioID 非空，必须实时读取并回填「已发布？、关键词、排序方式、关键词匹配、最近发文时间」五列。新增/补 ID 后必须立刻查配置；任务收尾再对全部非空 ID 做全量审计，断言发布状态非空，其他四列若为空必须有“无热点资讯区块”等明确线上原因，禁止只填 ID 和链接。
16. **保存真值只认 BSON `t_form_input`**：配置“热点资讯”时必须修改 `recall_forum_info.t_form_input`，保存回读确认关键词二维数组和固定参数后才允许发布；外层副本、默认值或发布成功响应均不能替代 UI 真值验收。
17. **BSON 原始值先归一化**：浏览器接口返回的 `bsonRawData` 可能是 `{"data":[...]}`，历史文件可能是裸数组；任何解码脚本都必须兼容两种形态，禁止直接假设一种类型。
18. **live-room 响应路径必须兼容并复扫**：HotRio 映射读取必须兼容 `data.liveRoom` 和顶层 `liveRoom`，显式匹配 `tabID=27`；空映射不得立即落结论，必须重试，并在任务收尾全量复扫“缺映射/暂不处理”记录。
19. **live 实体页是映射回退真值源**：live-room 请求失败或结构不可判定时，必须使用已登录浏览器访问 live 实体页并读取“完整 Tab 配置”的 `Tab ID=27`；页面成功判定后应消除该条接口 error。
20. **发布状态必须等待版本收敛**：`SaveBlock` 发布成功后持续回读目标子区块；只有 `status=3 && onlineVersion=version` 才算发布完成，轮询超时才记失败。
21. **浏览器实例冲突动态定位且不干预其他任务**：每次命令重新枚举普通用户 Chrome，排除临时 `user-data-dir`、远程调试、headless 和 agent-browser 实例，再以目标标签和 JavaScript 探针唯一确认；随后用 ScriptingBridge 按本轮 PID 绑定。Chrome 重启后不得复用旧 PID；无法唯一绑定时停止并报告，不干预任何其它进程。
22. **大批次 Apple Event 必须延迟轮询并分块回收**：`map-live` 启动后先等待 60 秒，避免执行期间并发 Apple Event；轮询只返回小状态，完整 JSON 按不超过 32KB 分块拉取。持续超时恢复时只重建本轮 Agent 创建的目标标签，禁止关闭用户已有标签、暂停或终止其它 Chrome 实例。

skills 内关键文件

SKILL.md

project-config.md

keyword-generation.md

hotrio-execution-sop.md

自顶向下：任务描述、流程简述、各步骤操作简述

更像一个「地图/索引」，不直接展开具体细节，而是提供详细说明的文件路径。

由Agent自动维护。

项目配置。包含飞书表格、本地关键文档等重要资产的链接，表格的规则、列名与列名定义，漂移处理等。

由Agent自动维护。

关键词生成规则：字段含义与规则；从比赛信息生成关键词，必要信息主动联网搜索补全

人与Agent协作维护

hotrio编辑页面的操作SOP。

由Agent自动维护。

SKILL.md---
name: update-yayun-recall-kw
description: 串联亚运图文直播召回的五步更新流程：同步线上最新赛程、迁移“未发布”赛程、生成并校验关键词、配置发布 HotRio、回填总表并完成全量验收。适用于“更新亚运召回关键词”“同步赛程并配置 HotRio”“执行亚运 Aime 任务队列”等请求，并在每一步结束后按固定口径汇报数量、warning 与 error。
author: liuboji
---

# 亚运召回关键词更新

按 **同步 → 迁移 → 关键词 → 配置 → 回填验收** 顺序执行。每一步结束后立即汇报本步结果，再进入下一步；任何写入都要回读验证。默认处理当前工作簿中的「赛程汇总表」与「Aime任务队列表」，固定资源见 [project-config.md](references/project-config.md)。

## 启动口令与默认行为

用户说“调用 update-yayun-recall-kw，开始执行”或同义指令时，执行完整五步。若用户指定起止步骤，则只执行该区间，但先检查前置数据是否齐全。

开始前：

1. 使用 `lark-sheets` skill 读取工作簿结构和两张目标表的当前表头、真实数据末行、revision。
2. 使用 `browser` skill 检查本地浏览器连接、GIP/HotRio 登录态与权限。每次浏览器命令都运行 `scripts/hotrio_browser_batch.py --chrome-pid auto` 动态发现当前用户 Chrome；不得复用上轮 PID，也不得回退到模糊的应用名 AppleScript。
3. 读取 [risk-and-recovery.md](references/risk-and-recovery.md)，创建本轮运行清单；以 Hotrio 编辑链接中的 `id` 或系统 ID 作为行身份，不以行号或名称作为身份。
4. 写操作前再次读取目标表头；列可能被人工移动，始终按表头名映射。

若登录、权限或页面验证不可用，停止相关步骤并报告需要人工处理的具体动作；不要通过保存 Cookie、JWT 或其他凭证绕过。

## Step 1：同步线上最新赛程表

按 [schedule-sync-sop.md](references/schedule-sync-sop.md) 执行，将经线上验证的最新赛事状态同步到「赛程汇总表」。

完成条件：

- 新增与更新均已真实写入并回读；
- 所有仍缺 Hotrio 的 `liveID` 已在本轮实时二次查询；
- 反向覆盖审计已完成；
- 无法确认的记录未被猜测性补全；查询链路失败记为 error，不得写成“确认无 Hotrio”或降级为 warning。

步骤结束后按固定格式汇报：

```text
Step 1 同步线上最新赛程表
- 目前已有条目：N
- 本轮新探明条目：N
- 新增条目分类：子比赛 N（正式 N、非正式 N）；父/独立比赛 N（正式 N、非正式 N）
- 新增条目 HotRio：已确认有 N；已确认无 N；未知 N
- 本轮需更新（未发布）条目：N
- Error：无 / 逐条列出查询链路失败、权限失败或响应不可判定的记录
- Warning：无 / 逐条列出不阻断事实判定的数据质量问题
```

计数口径：

- “目前已有条目”是同步完成后「赛程汇总表」的非空数据行数；
- “本轮新探明条目”是本轮线上权威键在同步前表内不存在、且已写入成功的记录数；
- “子比赛”以权威 `parentContestID` 非空为准；“非正式”是线上明确标记废弃/测试/无效或同时处于下线、隐藏状态的记录。二者是两个维度，非正式记录仍可能是子比赛；
- “已确认无 HotRio”只计 live-room 请求成功且响应中明确没有 `tabID=27` 非空 `amosID` 的记录；请求未取得可判定响应时只能计“未知”并记 error；
- “本轮需更新（未发布）条目”是同步后表头为「已发布？」的列中，值精确等于“未发布”的记录数。

## Step 2：迁移未发布赛程到 Aime 任务队列表

按 [queue-transfer-sop.md](references/queue-transfer-sop.md) 执行。只从「赛程汇总表」选择 `已发布？=未发布` 的记录，并追加到「Aime任务队列表」真实末行之后。

只迁移六项：

- `计划开赛时间 + 比赛日期` → `开赛时间`
- `大项` → `大项`
- `名称` → `直播间名称`
- `参赛` → `参赛方`
- `链接` → `链接`
- `备注` → `备注`

新增行同时设置：`关键词表` 留空，`排序方式=时间序`，`关键词匹配=标题`，`最近发文时间=7天`，`状态` 留空。不得从源表复制关键词或源表中的默认配置值。

用链接中的 Hotrio ID 幂等去重；链接缺失时只允许用文档规定的复合键辅助识别，并隔离该行，不得送入 Step 4。是否记录 warning/error 按 HotRio 查询是否成功及事实是否可判定分级。

步骤结束后按固定格式汇报：

```text
Step 2 未发布赛程转移至 Aime 任务队列表
- 队列期初条目：N
- 源表未发布候选：N = 已存在 N + 本轮迁移 N + 隔离 N
- 本轮迁移条目：N
- 本轮需执行条目：N
- 队列期末条目：N（期初 N + 本轮迁移 N）
- Error：无 / 逐条列出导致 HotRio 状态未知的请求或权限失败
- Warning：无 / 逐条列出重复、缺字段、字段冲突或状态异常
```

必须同时满足两个守恒式：`源表未发布候选 = 已存在 + 本轮迁移 + 隔离`，`队列期末 = 队列期初 + 本轮迁移`。缺 HotRio 链接但已确认线上尚无映射的记录属于正常隔离，不计 warning；查询链路失败导致是否有 HotRio 未知时记 error。“本轮需执行条目”指本轮迁移后、属于本次 `run_id` 的新增记录数；历史遗留的待执行记录单独汇报，不默认混入本批次。状态判断只认表头名为「状态」的列，不使用右侧无表头列中的“待输入/已输入”文本。

## Step 3：prompt 生成关键词

读取 [keyword-generation.md](references/keyword-generation.md)，默认仅对本次 `run_id` 在 Step 2 新迁移的记录逐行处理；历史遗留待执行项只统计并汇报，用户明确要求补跑时才纳入：

- 已有关键词：先校验，不擅自重写；不合格才重新生成并记录原因。
- 空关键词：按指定 prompt 生成。
- 时段总赛程：必须先查实当日、时段内的实际赛事与中国重点选手；证据不足时留空并 warning，不能编造。
- 写回后回读首、中、末及全部 warning 行；关键词分组必须能按分号拆组、按逗号拆成独立词。

步骤结束后汇报：

```text
Step 3 prompt 生成关键词
- 生成成功条目：N
- Warning：无 / 逐条列出未生成、校验失败或证据不足的记录
```

“生成成功”仅计本步骤新生成或修复后写回、且回读校验通过的记录。关键词为空或校验失败的记录不进入 Step 4。

## Step 4：Aime 执行配置

读取 [hotrio-execution-sop.md](references/hotrio-execution-sop.md)，使用 `browser` skill 按 READ-DO 串行处理：每次只读取一行、配置一个页面、刷新回读验收，再处理下一行。

验收必须同时满足：

- 目标区块为“热点资讯 / 网友热议”；
- 自动召回为“关键词召回”；
- 排序方式为“时间序”；
- 关键词匹配为“标题”；
- 时间限制类型为“过去一段时间”，最近发文时间为“7天”；
- 分号分组正确；组内每个逗号分隔词都形成独立 tag；
- 发布成功且刷新后操作栏不再显示“发布”。

只有单行页面验收通过后，才把该行规范「状态」列写为“已输入”并回读。失败行保留原状态，记录失败阶段、页面现象和是否需要人工处理；不得批量提前改状态。

全部候选处理结束后汇报：

```text
Step 4 Aime 执行配置
- 成功条目：N
- Warning：无 / 逐条列出失败、跳过、无目标区块或需人工介入的记录
```

## Step 5：回填总表与全量验收

以 Step 4 最终回读的 BSON 与发布状态为真值，按 Contest ID / Hotrio ID 重新定位总表记录，回填 `已发布？、关键词、排序方式、关键词匹配、最近发文时间`。不得用 Step 3 计划值代替线上回读值。

回填后全量读取两张表并验收：主表和队列条数、29/本轮 N 条身份唯一性、主表状态与发布列空值、队列状态计数、日期时间逆序、写入范围 changeset。只有目标区块满足 `status=3 && onlineVersion=version` 且队列状态已回读为“已输入”的记录才计入回填成功。

步骤结束后汇报：

```text
Step 5 回填总表与全量验收
- 回填成功条目：N
- 主表条目：N；队列条目：N
- 主表剩余未发布：N
- 日期时间逆序：N
- 最终 revision：N
- Warning：无 / 逐条列出未通过验收的记录
```

## 全链路完成门禁

- 五步都有独立汇报，计数可由回读数据复算。
- 每个写入步骤保留写前 revision、预期条数、实际写入条数与回读结果。
- 单行失败不伪装成全量成功；可继续处理互不依赖的安全记录，最后汇总 warning。
- 若 Step 1 的源数据完整性、Step 2 的表头映射或 Step 4 的登录/权限出现全局阻塞，则停止后续依赖步骤。
- 不执行用户未要求的删除、重排、改名或覆盖；不修改人工标注列。

project-config.md# 项目配置与来源

## 固定资源

- 工作簿：`https://bytedance.larkoffice.com/sheets/DJKosVnffhAqAFt3ffrc337Ln0b`
- 赛程汇总表：`sheet_id=tigW77`
- Aime 任务队列表：`sheet_id=KJikOj`
- HotRio 配置 SOP：`https://bytedance.larkoffice.com/docx/NILJdtYfDoG0jkxXFDEcvgUgnSf`

## 当前本地项目文件

执行涉及赛程同步前，读取项目根目录：

1. `PROJECT_RULES.md`
2. `README.md`
3. `one-mistake-one-rule.md`
4. `knowledge/asian-games-data-rules.md`
5. `knowledge/SOP_dynamic_update.md`

这些路径以运行时用户提供或挂载的“亚运图文直播召回”项目根目录为基准，不要把某台机器的绝对路径写死。

## 表头契约

### 赛程汇总表

必需字段：

`比赛日期`、`名称`、`大项`、`参赛`、`链接`、`计划开赛时间`、`已发布？`、`备注`

可选但同步流程常用：

`阶段`、`Hotrio ID 1`、`状态`、`关键词`、`排序方式`、`关键词匹配`、`最近发文时间`、`进表时间`

### Aime 任务队列表

规范字段：

`开赛时间`、`大项`、`直播间名称`、`参赛方`、`链接`、`备注`、`关键词表`、`排序方式`、`关键词匹配`、`最近发文时间`、`状态`

右侧可能存在无表头的历史辅助列。不得把无表头列中的“待输入/已输入”当成规范状态，也不得覆盖这些列。

## 运行时漂移处理

- `sheet_id` 是首选稳定标识，但每次仍先读取 workbook-info，确认它仍指向预期表名。
- 任一必需表头缺失、重名或位置不明确时停止写入并 warning。
- 文档中的行数、列字母、历史统计只作背景；实时表头和回读结果才是执行依据。
- Chrome PID 不是稳定配置。每次运行通过 `--chrome-pid auto` 重新发现普通用户实例；任何日志中的 PID 仅用于本轮追踪。

keyword-generation.md# Step 3：关键词生成与校验

## 生成 prompt

任务：为亚运会图文直播生成“相关资讯关键词召回”规则。

目标：必准优先、兼顾尽召。关键词规则中，逗号表示组内交集 AND，分号表示组间并集 OR。尽量使用短词、小词交集，避免因完整赛事名称表述不同造成漏召。

对于“某场对阵”类赛事：先提取双方国家/地区、性别和项目，国家名尽量缩短到仍可稳定区分；项目词可简写为“乒/篮/排”等。通常生成 2～3 组，如：`新，哈，男子团体；新，哈，男乒；新，哈，乒，亚`。同义长短词不要重复铺，只保留必要写法。

对于“射击9.30上午时段赛事”“游泳9.25上午/下午时段赛事”这类时段总赛程，关键词由两部分组成：

1. 赛事关键词：先查询该日期、该时段实际包含的赛事；每个相关赛事生成一条关键词。优先把完整赛事名拆成稳定的小词交集，例如：
   - 男子200米蝶泳 → `男，200，蝶泳`
   - 男子200米仰泳 → `男，200，仰泳`
   - 女子50米步枪三姿 → `女，50，枪，三姿`
2. 种子选手关键词：查询每个相关赛事中中国最值得关注、最有夺冠竞争力的 1～2 名选手，优先参考官方报名、近期大赛成绩、全国选拔赛/冠军赛成绩。每名选手单独生成一条关键词，并加一个项目特征词，例如：
   - 女子50米蝶泳－张雨霏 → `张雨霏，蝶`
   - 女子50米步枪三姿－王子菲 → `王子菲，枪`

最终只输出关键词结果，按赛事逐行排列；不要写大段解释，不要堆无必要同义词，不要为了召回降低准确率。

## 行级输入

至少提供：`开赛时间`、`大项`、`直播间名称`、`参赛方`、`备注`。对时段总赛程，再提供查证到的子赛事与种子选手证据。

## 写入策略

- 默认仅处理本次 `run_id` 在 Step 2 新迁移的记录；历史遗留项只统计，除非用户明确要求补跑。
- 处理行的规范 `状态` 必须为空或“待输入”；其它未知状态进入 warning，不自动处理。
- `关键词表` 非空时先校验；符合规则则保留，避免重复改写。
- 关键词为空或不合格时生成；一行的全部 OR 组写入同一个单元格。
- 统一使用中文全角逗号 `，` 和分号 `；`；写入前去除空组、重复组、组内重复词和首尾空白。
- 不生成仅含单个宽泛词的组，如“亚运”“中国”“比赛”。
- 国家简称必须仍可稳定区分；例如“新”在上下文无法稳定指代时，改用“新加坡”。
- 对阵赛至少包含双方、性别/阶段特征之一、项目词；无法确认性别时不猜，使用其它可验证特征并 warning。
- 时段赛没有可靠子赛事或选手证据时不写关键词，记录 `EVIDENCE_INSUFFICIENT`。

## 校验

可运行：

`python3 scripts/validate_keywords.py --input <queue.csv> --output <report.json>`

校验只负责格式与明显质量问题，不能替代赛事事实核验。写回后回读所有本轮处理行，生成成功数只计算回读一致且校验通过的行。

hotrio-execution-sop.md# Step 4：HotRio 执行配置 SOP

## 现有沉淀与成熟度

权威 SOP：`https://bytedance.larkoffice.com/docx/NILJdtYfDoG0jkxXFDEcvgUgnSf`（《HotRio 图文直播间召回配置 SOP》）。其目标区块、固定参数、tag 输入、刷新回读与发布验收规则已经完整，成熟度为 **可稳定执行但依赖浏览器环境**。

需要人工介入的常见情况：未登录、无编辑/发布权限、二次认证、页面结构变化、目标区块不存在、发布失败且页面无可诊断原因。遇到这些情况保留原状态并 warning，不绕过权限。

## 执行前筛选

候选行必须同时满足：

- 属于本次 `run_id` 新迁移记录；历史遗留项仅在用户明确要求补跑时纳入；
- 规范 `状态` 列为空或“待输入”，其它未知状态不自动处理；
- `链接` 是有效 Hotrio 编辑链接；
- `关键词表` 非空且通过 Step 3 校验；
- 三个固定列分别为 `时间序`、`标题`、`7天`。

## 用户 Chrome 动态定位

所有 HotRio 读取与写入默认使用：

`python3 scripts/hotrio_browser_batch.py ... --chrome-pid auto`

`auto` 每次命令重新枚举 Google Chrome 主进程，不缓存上轮 PID：

1. 只把 `PPID=1`、无显式临时 `user-data-dir`、无远程调试/headless/agent-browser 标记的进程视为普通用户 Chrome。
2. 对候选进程使用 ScriptingBridge 按 PID 查找 `--tab-url-contains` 指定的目标标签，并执行只读 JavaScript 探针。
3. 只有一个候选同时通过进程分类、目标标签和探针时才继续；零个或多个均停止并报告候选 PID，不回退到 `tell application "Google Chrome"`。
4. `--chrome-pid <数字>` 仅用于诊断性显式覆盖，仍会拒绝被识别为隔离/自动化的进程。
5. Chrome 重启后直接重跑命令即可发现新 PID；若在批次运行中重启，则当前批次失败并按运行账本恢复，禁止复用旧 PID。

## READ-DO 单行闭环

使用 `browser` skill；本地浏览器已连接时在用户本地浏览器执行，并按该 skill 的要求如实汇报访问过的网站。

每行执行：

1. 读取当前行全部输入并记录目标 Hotrio ID。
2. 打开编辑链接，定位标题“热点资讯”、类型“网友热议”的唯一目标区块；找不到或出现多个候选则停止该行。
3. 打开编辑抽屉，配置：
   - 自动召回：关键词召回
   - 排序方式：时间序
   - 关键词匹配：标题
   - 时间限制类型：过去一段时间
   - 最近发文时间：7天
4. 将 `关键词表` 按 `；` 拆成 OR 组。每组按 `，` 拆词；每个词逐个输入并按 Enter，确认每个词形成独立 tag。禁止把“词1，词2”作为单个 tag。
5. 保存，等待成功反馈；刷新页面后重新进入编辑抽屉，回读全部参数与全部 tag。
6. 回读通过后发布；发布接口成功后按 500ms 间隔轮询刷新，最长 10 秒，直到目标子区块满足 `status=3 && onlineVersion=version`。首次回读未收敛不立即判失败；超时后仍不一致才记失败。随后确认页面操作栏不再显示“发布”。
7. 回写状态前再次读取该行，确认 Hotrio ID、关键词表、三个固定配置列和状态仍与开始处理时一致；若已被他人修改，记录 `CONCURRENT_EDIT`，不覆盖。仅通过该比较后，把规范 `状态` 写为“已输入”，随后回读。
8. 将该行页面验收摘要与状态回读结果写入 `/tmp/yayun-recall/run-<run_id>.jsonl`，再处理下一行。页面变化后重新 snapshot，不复用旧 ref；任务完成后将最终账本归档到 `reports/runs/<YYYY-MM-DD>/`。

## 历史待处理补跑

用户明确要求补跑历史 `待修改` / `待输入` 时，先对全部候选执行只读 audit，再按结果分流：

- 已发布且关键词与五项固定参数完全一致：不重复保存或发布，只回填规范状态为“已输入”。
- 已发布但配置不一致：以队列中已校验关键词为期望执行修正、重新发布并终审。
- 关键词为空：返回 Step 3。只有参赛方或赛事范围已由当轮线上源确认后才生成；`TBD` 或证据不足继续隔离。
- 未发布且关键词有效：按 READ-DO 闭环配置并发布。

补跑结束后统一终审全部成功项，再批量回写状态；不要逐条重复读写飞书。状态回填前仍需按 Hotrio ID、关键词和三个固定参数检查并发修改。

## 失败处理

- 保存失败：不要发布，不改状态。
- 参数回读不一致：重新修正一次；仍不一致则 warning。
- 发布失败：不改状态，保留页面现象。
- 无目标区块：标记 warning，不擅自创建或改其它区块。
- 浏览器连接中断或 PID 消失：停止批次；已验收行保持成功，未验收行不改状态。恢复时重新自动发现用户 Chrome。

## 成功口径

“成功条目”必须同时具备：保存成功、刷新回读配置一致、发布成功、刷新后无发布按钮、状态回写为“已输入”且表格回读一致。任一缺失都不计成功。

3.4 实际运行

😀

流程与错误，让工作流能端到端执行，让智能体在下一次面对分叉路口时选择正确的途径，提高系统的稳定性和泛用性。

Review / 实际skills的目录结构-更新亚运召回关键词

skills目录结构 / 更新亚运召回关键词skills/update-yayun-recall-kw/
├── SKILL.md                         # 入口：适用任务、五步流程、完成条件与停止条件
├── .skillignore                     # 打包排除规则：缓存、临时数据等
├── references/                      # 按需读取的业务说明
│   ├── project-config.md            # 工作簿、目标表、表头契约及项目资料位置
│   ├── schedule-sync-sop.md         # 同步赛程：数据来源、身份去重、完整性检查
│   ├── queue-transfer-sop.md        # 迁移任务：字段映射、默认值、去重与隔离
│   ├── keyword-generation.md        # 关键词：生成提示、AND/OR 规则、证据与校验要求
│   ├── hotrio-execution-sop.md      # 配置发布：浏览器定位、参数设置、回读与验收
│   └── risk-and-recovery.md         # 异常处理、运行账本、中断恢复与风险规则
└── scripts/                         # Skill 包内的辅助代码
    ├── plan_queue_transfer.py       # 读取两表 CSV，生成去重后的追加计划
    └── validate_keywords.py         # 校验关键词格式，识别明显的宽泛召回风险
    ├── fix_comprehensive.py             # 赛程采集及整理
    ├── plan_schedule_increment.py       # 生成赛程新增、更新计划
    ├── sniff_hotrio_mappings.py          # 查询赛事与 HotRio 的映射
    ├── plan_queue_transfer.py           # 项目侧的任务迁移规划脚本
    ├── generate_match_keywords.py       # 对阵类赛事关键词生成
    ├── hotrio_browser_batch.py          # 浏览器操作入口：定位 Chrome、执行配置与回读
    ├── chrome_pid_execute.swift         # 按进程 ID 执行 Chrome 页面操作的桥接代码
    ├── plan_main_backfill.py            # 生成主表回填计划
    ├── plan_row_moves.py                # 生成表格整行排序移动计划
    ├── audit_schedule_identity.py       # 审计赛事身份与覆盖情况
    ├── test_hotrio_browser_batch.py     # 浏览器执行相关测试
    └── test_plan_row_moves.py           # 排序移动计划相关测试

执行输出	赛程总表 / 数据同步工作表	工作队列表

总收益

名古屋亚运期间，这套 skill 被调用 30+ 次，累计完成 1,200+ 条赛事同步、600+ 条配置发布、1,500+ 组关键词处理，累计执行自动保存、发布和历史修复约 837 条次。每条配置包含关键词组、召回逻辑、排序方式、匹配字段和时间范围等完整参数。最终实现主表发布状态空值 0 条、日期时间逆序 0 条、配置发布回读通过率 100%。运行效率从早期约 5.54 分钟/条降至稳定阶段约 1.3–1.5 分钟/条，页面映射环节从约 137 秒优化到 API 端约 5.1 秒，提速约 27 倍。

按人工投入基线估算，项目累计减少人工操作约 60 人时。净收益按“传统手工操作时间 − 开发迭代投入 − 启动与检查投入”计算：扣除约 20–32 人时功能研发投入及启动、验收、异常检查成本后，预计仍净节省约 20–35 人时；后续每次增量运行继续产生节省。节省的时间用于项目复盘和沉淀 SOP、形成 Skills 的可复用经验，可直接迁移到后续工作中。

4 人与AI的协作边界

分工	适合的环节	人的主要工作
AI 主做人验收	重复琐碎工作：固定赛程同步、队列整理、标准化配置量大的前期筛选：标准明确且输入完整的 case 初评、预聚类	同步信息、定义规则、定义验收协议抽查质量、处理异常、优化迭代后续分析
AI 与人共同推进	规则整理、项目知识维护、评价标准优化、方案比较	取精去糟决策
人主导 AI 辅助	信息严重不足时：缺失的信息无法靠提示词补出大方向把控：过度依赖AI、不加以约束，会导致尝试方向发散，最终哪条路都走不好，甚至无法启动价值观：对齐好的标准（高准保召）关键业务规则：关键词生成规则、关键词正负例对结果负责：结果审查对自己负责：撰写文档、报告	决策约束协调创造审美承担责任

需要人的场景 / 建立预期：不期待 AI 完成的好，不诉诸 AI 工具

工作或条件	原因	例子和处理方式
最终策略和价值边界拍板	涉及取舍、优先级与责任	AI 比较方案，人决定召回范围、质量底线和资源投入
复杂跨团队协调	依赖资源承诺、历史关系和未记录的信息	AI 整理方案与待确认问题，人完成沟通和承诺
精确尺寸或几何约束的视觉交付	需要可测量、可编辑的结果	AI 生成构思；尺寸、字体、曲线用设计工具落实和校验
仅凭指标变化判断因果	趋势本身不足以确认原因	AI 提出候选解释和查数计划，再用数据或实验验证
输入严重不足	缺失的信息无法靠提示词补出	视频缺画面、OCR 或 ASR 时，先补内容再做完整评估
极低频且很快能做完的工作	搭建和验收可能比手工更耗时	直接完成，或只让 AI 辅助其中一个步骤

人工介入 / 在关键节点：信息、行为对齐、约束、评审、迭代

投入评估与产出评估

投入评估。在决定是否要项目级管理一个需求时，请考虑整理 ROI——AI项目管理、工作流搭建与迭代的时间和精力是否值得投入？

一次性小任务可以直接聊天；长期项目，值得投入时间整理背景和标准，耐心同步减少重复解释和返工
算成本账：人力收益(h) = 传统工作方式(h) - 预期投入时间(h) - 新方式投入时间(h) + AI工具使用经验（难以量化的复利部分：初期摸索学习成本高，跑通流程、沉淀能力后，此后的协作将提速）
对 Agent 进行项目级管理有一定代价：思考时间更长、回复速度更慢；不过值得体验一下，收益是不易发觉但有的

产出评估。对于 Agent 产出的预测与评估：人工投入是否下降，业务质量是否达标，下一次是否更容易复用。 初期搭建和后续维护也计入成本，任务的频次和规模决定了是否值得持续投入。

对于「留背景、留错误」的检验原则：开启一个新窗口 / 新Agent，它能否仅凭一个入口文件了解项目现状、立即启动新任务？
对于「留流程」的检验原则：SOP / Skills 能否端到端执行，达到可用/好用？

5 AI 工具与模型选择

AI 工具的三个层级

层级	定义	典型产品	能力	人	示例
L1 多轮对话	通过连续问答理解需求，提供答案、建议或内容	DeepSeek、Kimi、豆包、ChatGPT	多模态输入多轮交互分析与理解生成内容网络搜索文件输入	任务、角色价值观、约束明确产出形态	“给我分析、解释这些材料，总结。”
L2 任务 Agent	接收工作目标，自主规划步骤、调用工具并交付成果	豆包工作 Aime	+ 项目空间与规则 + 观察 + 行动：Tool Calling、MCP、Hook、SubAgent... + 循环 + rules / skills... [+ 定时任务]	提供目标、资料和权限中途纠偏，验收成果	“读取项目资料，分析进度，生成周报和汇报 PPT”
L3 有开发能力的任务 Agent	在 L2 基础上，能操作真实开发环境，完成工程任务	Trae、Codex	+ 开发工具（git、编译环境、执行环境、依赖管理、测试等） + 插件能力 + 变更管理（git） [+ 跨聊天协作] [+ 跨会话任务调度]	明确需求与验收标准长期交互、创造、迭代审查实现，决定上线	“读取编码规则，增加xx需求导出功能，走完整开发流程”

层级

定义

典型产品

能力

人

示例

L1 多轮对话

通过连续问答理解需求，提供答案、建议或内容

DeepSeek、Kimi、豆包、ChatGPT

多模态输入
多轮交互
分析与理解

生成内容
网络搜索
文件输入

任务、角色

价值观、约束

明确产出形态

“给我分析、解释这些材料，总结。”

L2 任务 Agent

接收工作目标，自主规划步骤、调用工具并交付成果

豆包工作

Aime

+ 项目空间与规则

+ 观察

+ 行动：Tool Calling、MCP、Hook、SubAgent...

+ 循环

+ rules / skills...

[+ 定时任务]

提供目标、资料和权限

中途纠偏，验收成果

“读取项目资料，分析进度，生成周报和汇报 PPT”

L3 有开发能力的任务 Agent

在 L2 基础上，能操作真实开发环境，完成工程任务

Trae、Codex

+ 开发工具（git、编译环境、执行环境、依赖管理、测试等）

+ 插件能力

+ 变更管理（git）

[+ 跨聊天协作]

[+ 跨会话任务调度]

明确需求与验收标准

长期交互、创造、迭代

审查实现，决定上线

“读取编码规则，增加xx需求导出功能，走完整开发流程”

图片为AI工具四象限图，横轴为任务复杂度与持续性，从简单/短期到复杂/长期；纵轴为充分开发后的能力上限，从单次任务、深入处理到复杂业务、持续推进。图中展示了多个AI工具，如豆包工作、Aime、TRAE、Codex、Kimi、DeepSeek、ChatGPT、Workflow等，分别处于不同象限，如豆包工作在简单/短期、单次任务象限，Aime在持续迭代中象限等，直观呈现了各工具的能力定位。

层级	层级／工具	定位	优势	缺点／限制	适合场景	成本
L1 聊天页面	DeepSeek、Kimi、豆包、ChatGPT	以问答、分析和内容共创为主的 AI 入口	上手快；适合快速讨论、解释和多轮润色	任务衔接和落地主要靠人；要频繁复制资料、搬运结果	知识问答、头脑风暴、文案润色、方案讨论、代码解释	费用：0 or 低门槛：低
L2 任务Agent	豆包工作	面向个人与企业的办公任务 Agent，原生接入飞书	自动飞书文档与协作上下文；能将产出直接写入飞书（只要你敢）处于主推/高速迭代期	企业能力取决于账号权限和管理员配置；模型选择有限，复杂任务的人工可控、Agent 调度和产出结果有限。	企业资料整理、周报、业务分析、研究报告、汇报材料	费用：0（200/月）门槛：低至中。中-各种功能的熟悉、找到使用场景和对齐成果预期
L2 任务Agent	Aime（内部）	内部任务型 AI 助手	模型选择更多自动的子任务调度界面简洁美观，保主功能 Aime直接写飞书体验明显优化	好模型要排队；执行工具、系统接入与开发能力需按内部版本确认	内部任务处理、模型效果对比；具体场景按已接入工具选择	费用：内部配额或成本规则待确认；门槛：取决于任务配置，另有排队时间成本
L3 有开发能力的 Agent	TRAE	融合 IDE 与 Agent 的开发工具，支持人工编辑和自主执行	代码编辑IDE与 Agent SOLO方式结合可在协作过程中查看、修改和验证结果内部免费降智不明显，非顶级模型排队可接受跨聊天协作移动端远程遥控 Git 版本控制也可用于非开发的复杂项目好模型排队问题相对好；可选择上下文大小和effort强度处于迭代期	界面复杂很多，功能更多不一定是好事顶级模型（GPT6 Astra等）需排队与 Codex 原生“鞍”差距，智能释放受限模型/功能更新滞后	长期项目管理软件开发网页与应用原型	费用：内部免费门槛：中至高。飞书权限需两次授权。产品说明
L3 有开发能力的 Agent	Codex	以任务委派为中心的工程 Agent，可通过桌面端、CLI、IDE 扩展等入口使用	相对 Anthropic 家，大陆友好，近期极少听说封号移动端远程遥控项目管理跨聊天协作跨会话任务调度 Git 版本控制 UI 简介，UX 优秀 28 天更新计划中	企业信息安全使用受套餐额度限制 at capacity..（莫名限流）、降智 🪜（我司 VPN 可达）	仓库开发、问题修复、批量脚本、测试、代码审查、数据处理自动化	费用：plus 130元，pro5x 690元，pro10x 1300元；提供额度充值门槛：中至高。飞书权限需授权官方入口说明、定价

选择模型的建议

按工作环节和性质选择模型
- 关键任务：规划，关键操作（merge、整理文档），评审等需创造力、批判性思维、需深度思考与严肃场景，选择"Ultra"模型（GPT6 Astra）
- 执行任务：任务明确、边界清晰、无需创造力的执行性工作，选择"Lite"模型（GPT 6 Luna）

参考 Artificial Analysis 报告智能 v.s. 性价比（Pareto line）

图片为“Intelligence Index vs. Cost per Intelligence Index Task, by Model Release”图表，展示了不同模型在Intelligence Index方面的表现与成本关系。横轴为每项Intelligence Index任务的成本（美元，对数尺度），纵轴为Intelligence Index。图中以不同颜色标识了Anthropic、OpenAI等多家公司的模型，如GPT - 6 Luna、Claude Fable 5.1等。还标注了Pareto线，以及“Artificial Analysis”标识。该图与文档中“选择模型的建议”部分相关，用于参考各模型的性价比。

了解各模型的风格与优劣势领域：
- Luna 模型便宜、快、善于执行、不过度做工 -> 适合机械重复工作
- Astra 模型贵、慢、具有顶尖智能
- Opus 模型易封号，但拥有顶级智能+视频生成能力
- Anthropic 家性价比更高（同级订阅相对 O/ 用量体感3-4倍），但(极)易封号

最近的思考——对大模型与AI工具

多用，半玩半用，积累经验
流程清晰、简单重复工作尝试交给 AI
情绪管理：
- 前期趁着“兴头儿”广泛、积极地体验，把产出当作惊喜而非预期
- 中期警惕高估其能力，警惕陷入重度依赖，逐渐形成清晰的人与AI分工，理解哪些工作必须慢下来亲自处理——特别是复杂项目管理。
- 长期收敛精准的能力预期。
项目规则与约束最好全部心中有数：唯一权威原则；不让约束成为负担；间接控制了数量
复杂项目做好协作瓶颈在某一天会爆发的预期；推迟它必做的工作之一是定期花时间和精力整理项目规则、不断优化项目管理流程。
通过长期、深度、广泛地使用，慢慢迭代人xAI工具的协作方式，建立和对齐对模型和技术的能力理解
学习的模式转变：从按部就班、被动的地毯式学习，到快速建立宏观框架与生产实践需求驱动的即用即学。

6 答疑与批评指正

思考：目前正在 AI 协作维护的项目，有没有遇到瓶颈？

联想：一个可搭建工作流的场景？可行性？怎么拆解？怎么迭代？

恳请收到大家的反馈和意见 🙏 🙇‍♂️

QA（WIP）

🗒️

让给Agent传递的关键信息能被Agent自己管理起来，而不是淹没在聊天记录中被遗忘。

+skills、rules是什么样？

A：它们可以是自己电脑里能打开、能编辑的文件；也可以是

例如，一个“周报整理”技能可以长这样：

weekly-report/
├── SKILL.md        使用条件、处理步骤、输出要求
├── template.md     周报模板（可选）
└── examples/       好的成品示例（可选）

https://antigravity.google/docs/skills/
技能是用于扩展 Agent 功能的开放标准。技能是一个包含 SKILL.md 文件的文件夹，其中包含 Agent 在执行特定任务时可以遵循的说明。

附-rules与skills

类型	作用	例子
Rules：工作规则	告诉 Agent 平时应该遵守什么	默认中文；结论附来源；输出放到指定目录
Skills：任务技能	告诉 Agent 某一类任务怎么做	如何整理周报、分析评测数据、生成研究报告

+字节内部 skills 平台？

【学习中】

+skills如何形成的、我的工作和agent的工作、skills在哪、什么样、怎么复用...

推荐从一个真实任务开始：完成任务 → 纠正结果 → 总结有效步骤 → 保存为 Skill → 换一份材料验证。

你负责	Agent 负责
说明目标，提供材料或成品示例	读取材料，梳理步骤，执行处理
告诉 Agent 每一步都怎么做，输入什么->怎么处理->拿到什么结果	把你教给它的“实操”一遍，先学会基本版，自己记录下来
判断结果是否符合业务要求	根据反馈修改，提炼可复用流程
指出哪些经验值得保留	编写技能文件、模板和必要脚本；探索更优路径

+如何创建项目、添加本地文件夹

+设法减轻负担，特别是模版信息输入；模版输入版块再精简、给出实际填写例子

+Aime中项目维护流程

创建项目

发出第一条消息

开始任务交互

1.1 创建项目

这是Aime助理的工具界面，左侧功能栏设有“新建任务”“默认会话”“助理配置”等选项，“项目”分类右侧带有红色加号按钮，用于创建项目；界面右侧是查看AI事件总结迁移效果评审数据的区域，显示了Aime生成的相关内容，底部的输入栏可添加上下文、调用资源，当前正在创建“AI事件总结迁移...”的内容，整体为业务场景中AI工具的项目维护操作界面，和文档中介绍的“Aime中项目维护流程”相关内容对应。

1.2 可以起一个合适的名字

图片展示的是Aime助理界面，左侧为项目列表，右侧是任务界面。界面中“置顶”和“重命名”选项被红色框突出显示。该图片位于介绍Aime中项目维护流程的上下文部分，具体是在创建项目后，为项目添加项目目录的步骤中，用于说明在项目管理中对项目进行置顶或重命名的操作，帮助用户更好地管理和维护项目。

这张图片展示的是Aime工具的「新项目」操作界面，界面左侧是工具的功能导航栏，包含新建任务、默认会话、助理配置等选项。界面右侧的新项目创建流程中，核心突出标注了两处操作指引：一处是红色箭头指向界面下方的加号按钮，旁边标注“选择工作目录”；另一处红色箭头指向上方列表里的“选择目录”选项，对应项目目录创建步骤，和文档中提及的Aime项目维护流程里“为项目添加项目目录”的内容匹配，是项目创建环节里选择目录的操作指引。

图片展示的是一个文件管理界面，左侧为导航栏，显示了Recents、Shared、Favorites等文件夹。右侧是“Documents”文件夹下的内容，其中“Aime”文件夹被选中。画面底部有“New Folder”按钮，被红色箭头指向。该图片与文档中“Aime中项目维护流程”部分的“创建项目”步骤相关，用于说明在创建项目时，可选择“Documents”文件夹，点击“New Folder”创建新目录，或选择已有目录。

图片展示了Aime在业务场景中创建项目后的界面。上方有两张图片，分别为“AI事件总结迁移效果评审”和“AI事件总结迁移效果评审（10组正文+10组视频）”。下方是Markdown格式的项目信息，包括业务名、背景、本次任务、资料等内容。资料部分以红色框突出显示了“AI事件总结迁移效果评审（10组正文+10组视频）”及“AI事件总结迁移效果评审8.19”等信息。该图片与上下文介绍的Aime项目维护流程中创建项目的内容相关，直观呈现了创建后的界面情况。

看配置的目录有没有生效
粘贴第一条消息
也可以贴图片

随意开启工作交互～

+简单场景快速用起来——以「AI事件总结迁移效果评审」为例

发出的第一条信息

第一条信息业务名：AI事件总结迁移效果评审
背景：热榜AI总结的服务要从豆包迁移到热点自闭环 本次只是迁移服务，没有改动整个链路的prompt等，一共要评测两组数据：视频插入质量是否有显著影响；文本总结质量是否有显著差异
本次任务：看看这组数据
资料：
- [AI事件总结迁移效果评审（10组正文＋10组视频）](https://bytedance.larkoffice.com/docx/YV1odva7PonT0UxIH92cSB1nnbg)
- [热榜AI总结文本评估8.19](https://bytedance.larkoffice.com/sheets/CEXvsoAMFhiTiOtBKe5cp6vSngh)这个是之前切换模型做的人工评测，主要考察维度：
基本质量（准确性、相关性、格式）
可用到好用的主要关注维度：价值：逻辑性、对于该热榜词的延展增量是否得当；画风：AI感

请先读取任务相关资料，复述你的理解，区分事实和假设。
请你仔细阅读资料，特别是飞书文档，要求在给定文档基础上下探一层，收集重要信息，维护进项目知识。最新现状与历史记录需要明确标记。
后续把重要规则、决定、错误和当前状态维护到项目文件中。

---
（在此处粘贴 PROJECT_RULES.md。太长了此处省略）

Aime的首条输出：

这张图片展示了Aime项目的相关工作内容，包含对任务的理解、已确认事实、当前判断等板块，其中明确标注了“得确认项”部分，列出了关于Aime项目的多条待确认事项，比如Case 3、Case 10的相关内容判断要求，还能看到“已维护的项目文件”模块，显示了项目文件的相关状态，以及“最新现状vs历史记录”板块，呈现了Aime项目从2024年10月14日到近期的测试验证结果与分析，是对文档中“AI事件总结迁移效果评审”相关场景的具体内容呈现。

图片展示了Aime对“AI事件总结迁移效果评审”任务的首条输出内容。其中，红色框突出显示了Agent输出的理解，对齐需求，包括确认事实、业务名称、服务名称、新服务名称、评审标准、评审点等内容；绿色框标注了Agent明显去人提供的文档中主动看到的更多信息，如评审标准、评审点等；蓝色框则指出Agent维护了项目知识，如PROJCT_RULES.md、README.md等文件。该图片与上下文紧密相关，直观呈现了Aime在任务交互中的输出情况。

Aime 创建的 README.md

Aime创建的README.md# AI事件总结迁移效果评审

## 项目背景

热榜 AI 总结服务计划从豆包迁移到热点自闭环。本次迁移仅替换服务，不改动整体链路的 prompt 等逻辑。评审目标是判断迁移是否对内容质量产生显著影响。

## 项目目标

围绕两组数据完成效果评审：

1. 视频插入质量是否有显著影响；
2. 文本总结质量是否有显著差异。

最终需要形成可复用的评审结论、评审规则、当前状态和后续待确认项，保证后续 Agent 可直接继续。

## 当前状态

- 当前阶段：资料初读与项目上下文初始化。
- 已读取资料：评审飞书文档、历史人工评测飞书表格、项目本地目录结构。
- 已完成：基于 10 组正文 + 10 组视频做过一次初步判断，并生成飞书结论文档。
- 正在推进：将事实、假设、待确认项和上下文规则沉淀到本地项目文件。

## 当前核心判断

- 初步判断：当前 10 组正文和 10 组视频未显示系统性劣化，但样本量较小，正式结论仍需人工复核确认。
- 正文重点风险：candidate 结果更容易做背景扩展，可能带来信息量提升，也可能带来泛化、偏题或关键实体弱化。
- 视频重点风险：部分 case 存在新增视频、视频缺失或素材替换，需要判断是否影响段落相关性。
- 建议复核：正文 Case 3、4、6、10；视频 Case 4、5、6、8。

## 重要资料

- 原始评审文档：<https://bytedance.larkoffice.com/docx/YV1odva7PonT0UxIH92cSB1nnbg>
- 历史人工评测表：<https://bytedance.larkoffice.com/sheets/CEXvsoAMFhiTiOtBKe5cp6vSngh>
- 初步评审结论文档：<https://bytedance.larkoffice.com/docx/N8JydGgmuoHT7ixhDKQccfq9nGh>
- 附件图片：`img_v3_0216e_31940abb-e280-4216-ab53-2fd33cc4359g.jpg`、`img_v3_0216e_d39e22cb-16f8-42ca-ad24-8fefd17aa5eg.jpg`

## 文档地图

- `PROJECT_RULES.md`：项目级长期工作规则，复杂任务开始前必须读取。
- `README.md`：项目地图、当前状态和资料路由。
- `one-mistake-one-rule.md`：记录本项目已发生且有复发风险的错误及对应规则。
- `knowledge/source-materials.md`：原始资料、历史资料和最新资料的来源说明。
- `knowledge/evaluation-understanding.md`：当前对任务的事实、假设、待确认项和评审口径理解。
- `reports/2026-10-14-initial-review-summary.md`：2026-10-14 初步评审结论摘要与后续建议。

## 最新现状

截至 2026-10-14 11:19 CST：项目本地目录已初始化；上下文维护规则已落入 `PROJECT_RULES.md`；原始评审资料已下探一层并摘要到 `knowledge/`；初步评审结论已沉淀到 `reports/`。

## 历史记录

- 2026-10-13：原始飞书评审文档记录测试日期；正文总结、视频匹配两个接口各测试 10 组线上 case；两项接口均取得返回结果，其中 1 组正文首轮模型限流，复测后成功。
- 2026-10-14：完成项目上下文初始化，创建 `PROJECT_RULES.md`、`README.md`、`one-mistake-one-rule.md`、`knowledge/` 和 `reports/` 基础文件。

图片展示的是AI事件总结迁移效果评审的README.md文件内容。文件标题为“AI事件总结迁移效果评审”，包含项目背景、项目目标、当前状态、当前核心判断、重要资料等部分。其中，当前状态列出了事件迁移、事件迁移后数据、事件迁移后数据质量、事件迁移后数据质量评估等步骤；当前核心判断部分有多个判断标准；重要资料部分列出了参考文档、历史事件表单、事件参考示例等。该文件是对AI事件总结迁移效果评审项目的说明文档。

— 完 —

← 回到时间线

分享：AI工具在业务场景的使用

OpenAI 与 Anthropic 家的消息各一则

1 从一件琐碎、量大的工作开始

附 手动操作SOP

2 三个技巧

2.1 🖼️留背景

附 通用项目规则的约束来源

2.2 🚏留流程

2.3 🙅留错误

附 one-mistake-one-rule.md

3 真实场景应用：亚运召回例子

3.1 任务拆解

3.2 从零构建 / 如何从零得到一个可自动化工作的智能体？

3.3 持续迭代和优化

附-迭代内容表

3.4 实际运行

4 人与AI的协作边界

5 AI 工具与模型选择

6 答疑与批评指正

QA（WIP）

+skills、rules是什么样？

+字节内部 skills 平台？

+skills如何形成的、我的工作和agent的工作、skills在哪、什么样、怎么复用...

+如何创建项目、添加本地文件夹

+设法减轻负担，特别是模版信息输入；模版输入版块再精简、给出实际填写例子

+Aime中项目维护流程

+简单场景快速用起来——以「AI事件总结迁移效果评审」为例

附手动操作SOP

附通用项目规则的约束来源