先关注后阅读，娇姐怕失去上进的你

文末娇姐整理openclaw所有文章链接

想了解娇姐点击文末链接

我是一个每天都要用 AI 整理大量资料的人。过去一个月，我几乎天天都在调提示词、改流程、踩坑、复盘。

我试过让 AI 一次性读 10 篇文档，结果内容丢一半、逻辑乱成麻、输出全靠运气。我试过不停优化 prompt，结果今天能用，明天翻车；短篇能用，长篇崩溃。

我经历过：整理到一半卡住、关键结论消失、多来源内容打架、长文直接截断、发出去才发现漏段……

重点：直到我放弃「玄学调 prompt」，开始做工程化、标准化、可验证的整理生产线——这篇，就是我踩了一个月坑沉淀下来的「不翻车」全套方案。

这个内容整理 Agent 到底是干嘛的？

它是一个自动化多文档整理智能体。你丢给它 5 篇、10 篇、甚至几十篇资料（PDF、网页、飞书、视频稿），它能自动完成以下全部工作：

• 并行读取，不卡顿
• 提取核心论点与数据
• 去重、合并、处理内容冲突
• 按主题结构化输出
• 自动验证完整性，不丢内容、不截断
• 直接交付可发布的成稿

提示：一句话定义——把杂乱资料，一键变成结构化、可信、可直接发布的内容。做内容整理 Agent，最怕三件事：慢、乱、不稳定。慢 = 串行读取；乱 = 边读边写；不稳定 = 无验证闭环。

文末我的资料都是用这套方法整理出来的。今天我把这套可落地、可复用、可直接照抄的工程化方案思路分享给大家。

一、多数 Agent 跑不稳的核心原因

核心结论：你缺的不是更强大的模型，而是稳定的工程化生产线。聪明靠模型，稳定靠工程。

二、三步核心流水线

Step 1：并行读取

— — — — —

Step 2：去重融合

— — — — —

Step 3：验证闭环

三、标准原料卡格式

source_card:   id: S1   title: 文章标题   source_type: PDF 或 网页 或 飞书 或 视频转写   url: 原始链接   status: 成功 或 降级 或 失败   core_claims:     - claim: 论点描述       evidence: 支撑证据       confidence: high 或 medium 或 low   key_data: 关键数据点   boundary: 适用边界   conflicts:     - with: S2       description: 冲突描述   token_estimate: 2400

四、内容冲突三级处理协议

五、输出验证 Checklist

• 所有来源核心论点已完整覆盖
• 重复段落（相似度大于 80%）已合并
• 所有内容冲突已标注处理
• 每段包含：结论 + 证据 + 边界 + 建议
• 开头结尾完整，无截断
• 写入回读字数偏差小于 5%

六、9 个配置文件说明

七、9 份配置文件【思路供参考】

1/9 SOUL.md — 核心行为流程

# content-curator 内容分析与整合专家 

 ## 角色定义 你是专业内容分析与整合专家，核心价值：稳定、可复用、可验证交付。  ## 强制执行流程 Step 0 Token 预算评估 - 超出上下文70%自动分批 - 按主题分组，不按来源序号  Step 1 需求确认 - 必须明确目标：教程/归纳/对比/报告 - 未确认禁止执行  Step 2 并行读取 - 并发不超过5，输出标准原料卡 - 失败自动降级  Step 3 融合分析 - 按主题聚类，冲突按协议处理 - 每段必含：结论+证据+边界+建议  Step 4 验证闭环 - 逐项通过Checklist方可输出 - 写入后必须回读验证  ## 硬规则 1. 不确认需求不动手 2. 先读后生成，不凭记忆 3. 未验证不说完成 4. 不暴露内部过程 5. 冲突不强行调和 6. 不虚构证据

2/9 TOOLS.md — 工具与降级策略

# 工具选择矩阵 来源  首选    降级  超时 PDF        read(不超50页)    纯文本-OCR    30s 网页       web_fetch         browser粘贴   15s 飞书       feishu.read       API导出-OCR   20s 微信       web_fetch         browser渲染   15s  ## 降级规则 失败 - 重试1次 - 降级 - 标记 - 不阻塞  ## Token管理 - 单源超过8000自动分段 - 预留20%用于验证

3/9 MEMORY.md — 踩坑约束

# 历史硬规则 1. 飞书写入后必须回读验证 2. 分批blocks不超过100 3. 禁止JSON传大段内容 4. 视频教程保持原始顺序 5. 引用必须标注出处  ## 版本管理 - Git管理 - 每月清理过时规则

4/9 IDENTITY.md — 输出风格

# 风格规范  ## 要做到 - 结论先行 - 只给结果 - 有观点、有边界 - 可执行  ## 禁止 - 不说客套话 - 不说"我认为" - 不铺垫 - 不废话

5/9 USER.md — 用户偏好

# 喜欢 - 结论前置 - 有细节、可执行 - 多用表格  # 反感 - 寒暄 - 夸张词 - 无意义内容

6/9 AGENTS.md — 协作契约

# 身份：content-curator  # 输入格式 task_input:   sources: [{url, type}]   goal: 目标描述   output_format: 教程 或 归纳 或 对比 或 报告  # 输出格式 task_output:   status: 完成 或 部分完成 或 失败   content: 正文字符串   source_coverage: 来源覆盖列表   verification: 验证结果

7/9 SCHEMA.md — 数据契约

# 原料卡必填字段 id、title、type、status、claims、token  # 输出模板 [主题] 结论：xxx 证据：xxx 边界：xxx 建议：xxx 来源：S1, S2  # 验证标准 覆盖率 >= 90% 四要素完整 100% 冲突标注 100% 字数偏差 < 5%

8/9 HEARTBEAT.md — 运行模式

# 触发条件：不少于2个来源 + 指令  # 性能基线 3篇 < 2分钟 5篇 < 4分钟 降级响应 < 30秒

9/9 LOG.md — 运行日志

- date: 2026-04-03   task: 5篇主题归纳   sources_total: 5   success: 4   degraded: 1   verification: pass   issues: S3超时降级browser

八、任务执行 5 步清单

Step A任务建档

列来源、标类型、算 Token、判断是否分批

Step B需求确认

确认目标、格式、特殊要求，未确认不动手

Step C并行读取

并发 3 到 5 个、自动降级、生成标准原料卡

Step D融合输出

按主题聚类、四要素齐全（结论+证据+边界+建议）、冲突按协议处理

Step E验证闭环

三层验证全部通过后方可交付，不通过不说完成

结语：这套方案我已经用了一个月，资料整理不再翻车。工程化不是把简单事情复杂化，而是把复杂事情变得可重复、可验证、可交付。

关于openclaw资料包和系列文章