# Andrew’s Letter AI Content Pipeline Prompt 系统总结报告

> 建议放置路径：`docs/prompts/andrew_letter_prompt_system_review.md`  
> 对应项目：`andrew-letter-ai-content-pipeline`  
> 来源文件：`merged(2).txt`  
> 总结对象：Step 1–Step 33，共 32 份 Codex prompt（缺少 Step 28，Step 31 标题中误写为 Step 30）

---

## 1. 总体结论

这套 prompt 不是普通的“让 Codex 写几个脚本”的指令集合，而是一套围绕 **AI 内容自动化工作流** 持续演进的项目管理系统。

项目最初目标是：

```text
每周六自动获取 DeepLearning.AI Andrew’s Letter，
将其转化为微信公众号文章、抖音竖屏视频、B站横屏视频三类中文内容包。
```

后续经过 33 个阶段演进，项目经历了明显的三次产品定位变化：

```text
第一阶段：多平台内容自动化生产系统
第二阶段：多媒体成品包生成系统
第三阶段：三平台高质量内容资产包系统
```

最终最合理的定位应该是：

```text
Andrew’s Letter AI Content Pipeline 是一个面向 AI 行业内容学习、理解、改写、平台化表达和人工发布准备的本地内容资产生产系统。

它不追求自动发布，不追求完全自动生成视频成品，而是将英文 AI 行业内容转化为：
1. 微信公众号深度文章
2. B站长视频脚本 + 分镜 + AI 视觉提示词
3. 抖音短视频脚本 + 分镜 + AI 视觉提示词
4. 发布前审核清单
5. 内容复盘与优化数据结构
```

这个转向是正确的。  
前期想把文章、图片、配音、视频全部自动化做成成品，工程链路很完整，但现实约束太多：TTS、图片生成、视频生成、供应商额度、本地 ComfyUI 环境、视觉质量、视频可看性都会卡住。后期把最终交付物重定位为“高质量内容资产包”，反而更接近可长期稳定使用的真实项目。

---

## 2. Prompt 链路总览

| 阶段 | 文件 | 核心目标 | 项目意义 |
|---|---|---|---|
| 1 | step1 | 建立项目规范、目录、占位脚本、Prompt 模板 | 从 0 搭建工程骨架 |
| 2 | step2 | 实现 `pipeline --mock` 最小 MVP | 跑通完整输出结构 |
| 3 | step3 | 平台风格样本库与风格分析 | 建立平台差异化基础 |
| 4 | step4 | `source_understanding.py` 与内容记忆结构 | 把英文源文转成核心理解 |
| 5 | step5 | 数据中台与 Dashboard 骨架 | 为发布后复盘预埋数据系统 |
| 6 | step6 | 微信公众号文章生成 MVP | 生成第一条内容分支 |
| 7 | step7 | 抖音竖屏脚本与分镜 MVP | 生成短视频内容分支 |
| 8 | step8 | B站横屏脚本与分镜 MVP | 生成长视频内容分支 |
| 9 | step9 | AI 配音 / 字幕 mock + 接口分层 | 为视频成品化预埋音频链路 |
| 10 | step10 | 可播放 mock 视频渲染 | 从占位文件升级为可播放视频 |
| 11 | step11 | 本地图片占位增强 | 提升视觉占位质量 |
| 12 | step12 | 视频依赖安装与渲染配置 | 解决 moviepy / ffmpeg 环境问题 |
| 13 | step13 | `review_manifest` 审核增强 | 从生成系统升级为发布前审核系统 |
| 14 | step14 | 真实 latest 抓取与正文提取 MVP | 从 mock 源进入公开网页源 |
| 15 | step15 | 离线 HTML 回放与提取稳定性 | 增强抓取和解析鲁棒性 |
| 16 | step16 | LLM 内容理解与中文生成接口分层 | 支持 mock / rules / llm 三模式 |
| 17 | step17 | 人工编辑 / 内容润色工作台 | 加入 Human-in-the-loop |
| 18 | step18 | publish_ready 打包导出 | 形成可人工发布包 |
| 19 | step19 | 发布后数据回填工作流 | 建立人工发布后的数据复盘闭环 |
| 20 | step20 | 本地环境就绪检查与首个可发布包 | 聚焦端到端本地可运行 |
| 21 | step21 | Windows 依赖安装与一键验收脚本 | 降低本机运行门槛 |
| 22 | step22 | 真实 TTS 接入与有声视频重渲染 | 尝试进入真实音频生产 |
| 23 | step23 | 本机 TTS 运行脚本与 require-audio 检查 | 强化有声视频验收 |
| 24 | step24 | Production 内容质量升级 | 从工程可跑转向内容可看 |
| 25 | step25 | 彻底重构公众号文章生成逻辑 | 修复“报告不像文章”的核心问题 |
| 26 | step26 | real 模式禁止静默降级 mock | 解决真实生产链路可信度问题 |
| 27 | step27 | 非 OpenAI 供应商接入 | 解决 OpenAI quota / billing 限制 |
| 29 | step29 | 本地 ComfyUI / 本地模型路线 | 探索本地图片生成路线 |
| 30 | step30 | ComfyUI 环境落地辅助 | 帮助用户跑通本地视觉生成 |
| 31 | step31 | 最终目标重定位为内容资产包 | 重大产品策略收敛 |
| 32 | step32 | 内容资产质量复检与二次润色 | 加入质量评审与 refine 机制 |
| 33 | step33 | 跨平台差异强化专项 | 强化微信 / 抖音 / B站差异 |

---

## 3. 这套 Prompt 做得最好的地方

### 3.1 阶段推进很强

这套 prompt 的最大优点是，它没有一开始就让 Codex “做一个自动化视频系统”，而是分阶段推进：

```text
规范与目录
↓
mock pipeline
↓
平台风格分析
↓
内容理解
↓
三平台内容生成
↓
字幕 / 配音 / 视频渲染
↓
审核
↓
真实抓取
↓
LLM 接口分层
↓
人工编辑
↓
发布包
↓
数据回填
↓
质量复检
↓
最终目标收敛
```

这个推进方式很像真实产品工程，不是一次性堆功能。

### 3.2 安全边界长期保持清楚

几乎每一步都明确写了：

```text
不自动发布
不冒充官方
不逐字全文翻译搬运
不克隆 Andrew Ng 声音
不生成 Andrew Ng 真实肖像
不使用 DeepLearning.AI 官方 Logo
不复制平台爆款内容原文、封面、视频画面
API Key 不硬编码
无 Key 时使用 mock / fallback
```

这让项目始终保持在“学习解读 + 人工审核 + 本地工作流”的安全边界内。

### 3.3 mock / rules / llm / real 的接口意识很强

项目没有一上来依赖真实 API，而是逐步设计：

```text
mock：保证流程能跑通
rules：用规则生成可解释内容
llm：有 Key 时调用真实 LLM
real：接入真实图片 / TTS / provider
```

这是一种很成熟的工程思路：先把流程、数据结构、文件结构跑通，再替换生成能力。

### 3.4 Human-in-the-loop 设计正确

从 Step 13 之后，项目开始明显强化人工审核：

```text
review_manifest
review_report
editor_workbench
publish_ready
manual publish checklist
performance backfill
quality review
refinement
```

这非常适合内容生产系统。  
AI 不应该直接自动发布内容，而应该作为“生产草稿 + 结构化资产 + 审核辅助”。

### 3.5 后期能及时战略收敛

Step 31 是这套 prompt 中最关键的一步：停止把最终目标放在自动图片、自动视频、自动配音成品上，改为“三平台高质量内容资产包”。

这个决策非常重要。  
它说明项目从“想象中的全自动多媒体系统”回到了“真实可用、可维护、可交付”的内容工作流系统。

---

## 4. 主要问题与可优化点

### 4.1 Prompt 太长，重复上下文过多

每一步都重复大量内容：

```text
不要自动发布
不要调用平台 API
不要抓取评论
不要调用真实图片 / TTS / 视频 API
不要上传
不要泄露 API Key
```

这些约束是必要的，但不应该每一步都完整重写。  
建议沉淀为固定文件：

```text
docs/prompts/global_constraints.md
docs/prompts/content_safety_rules.md
docs/prompts/provider_rules.md
docs/prompts/failure_protocol.md
```

后续 prompt 只需要引用：

```text
请遵守 docs/prompts/global_constraints.md 中的全局约束。
```

### 4.2 阶段编号存在不连续和误写

当前文件里：

```text
step28 缺失
step31.txt 的标题写成“进入 Step 30”
```

这会影响后续项目复盘和 prompt 管理。  
建议新增：

```text
docs/prompts/prompt_index.md
```

记录每一步：

```text
step_id
阶段名称
目标
输入
输出
状态
是否废弃
是否被后续重定位覆盖
```

### 4.3 早期多媒体目标过重

Step 9–23 大量投入到：

```text
配音
字幕
可播放 MP4
真实 TTS
真实图片
真实视频
OpenAI provider
Edge TTS
DashScope
ComfyUI
本地视频
```

这些能力技术含量高，但对项目主价值不一定是最核心的。  
真正有长期价值的是：

```text
英文 AI 内容理解
中文化表达
平台差异化改写
人工编辑
质量复检
发布清单
数据回填
内容复盘
```

后续应该把图片、配音、视频都标记为：

```text
optional enhancement
legacy multimedia route
not required for default production readiness
```

### 4.4 真实模式和 fallback 规则需要更严格

Step 26 已经发现一个关键问题：

```text
real 模式静默 fallback 到 mock，会让用户误以为真实图片 / 真实音频已经生成。
```

这个问题必须在系统层面解决。  
建议所有 provider 统一采用：

```text
mode=mock：允许 mock
mode=rules：允许 rules
mode=llm：无 Key 可 fallback，但必须记录 fallback
mode=real：禁止静默 fallback；失败就失败
```

并输出统一状态：

```json
{
  "requested_mode": "real",
  "actual_mode": "mock",
  "fallback_used": true,
  "is_production_ready": false,
  "blocking_reason": "Real provider unavailable"
}
```

### 4.5 缺少统一的“决策记录”

项目中发生过多个重要转向：

```text
从 mock pipeline 到真实 latest 抓取
从 rules 到 llm 接口
从 mock 视频到真实 TTS
从 OpenAI 到非 OpenAI provider
从 ComfyUI 到内容资产包
```

这些都应该写成 ADR：

```text
docs/decisions/ADR-001-why-mock-first.md
docs/decisions/ADR-002-why-no-auto-publish.md
docs/decisions/ADR-003-why-content-asset-package.md
docs/decisions/ADR-004-why-real-mode-no-silent-fallback.md
docs/decisions/ADR-005-why-multimedia-is-optional.md
```

这会让项目更像真实产品工程。

### 4.6 内容质量评价应更早出现

直到 Step 24–33，项目才开始集中处理“文章不像文章”“跨平台差异不够强”的问题。  
但内容质量其实应该从 Step 6 开始就加入评分规则：

```text
是否像真实公众号文章
是否像真实抖音脚本
是否像真实 B站长视频脚本
是否有平台差异
是否有个人观点
是否避免项目说明腔
是否避免工作流报告腔
```

建议提前加入：

```text
src/review_content_asset_quality.py
src/refine_content_assets.py
src/content_asset_quality_check.py
```

并作为默认验收，而不是后期补救。

---

## 5. 可以沉淀出的 Prompt 方法论

这套 prompt 最核心的方法论可以总结为：

```text
先定义边界，再搭建结构；
先跑通 mock，再替换真实能力；
先生成草稿，再加入人工审核；
先形成内容资产，再考虑多媒体成品；
先保证可维护，再追求自动化。
```

进一步抽象成适合 Codex 项目的公式：

```text
高效 Codex Prompt
= 目标 + 范围 + 输入 + 输出 + 文件清单 + 模式约束 + 验收命令 + 失败处理
```

对于这个项目，最适合的增强版公式是：

```text
内容工作流 Codex Prompt
= 项目定位
+ 当前阶段
+ 不做什么
+ 本阶段输入
+ 本阶段输出
+ 数据结构
+ 文件改动范围
+ 运行命令
+ 验收标准
+ 安全边界
+ fallback 规则
+ 最终回复格式
```

---

## 6. 推荐的项目内 Prompt 文档结构

建议在项目中新增：

```text
docs/prompts/
├── prompt_index.md
├── prompt_system_review.md
├── codex_prompt_template.md
├── global_constraints.md
├── content_safety_rules.md
├── mode_and_provider_rules.md
├── failure_protocol.md
├── acceptance_commands.md
├── prompt_quality_checklist.md
└── legacy_prompt_notes.md
```

### 6.1 `prompt_index.md`

记录每个 step 的摘要：

```text
step_id
阶段名称
核心目标
新增文件
修改文件
验收命令
当前状态
是否被后续阶段覆盖
```

### 6.2 `global_constraints.md`

沉淀所有长期不变约束：

```text
不自动发布
不上传平台
不调用平台 API
不保存敏感个人信息
不硬编码 API Key
不克隆声音
不冒充官方
不复制平台爆款原文和素材
```

### 6.3 `mode_and_provider_rules.md`

统一 mock / rules / llm / real 规则：

```text
mock：用于结构测试
rules：用于无 API Key 的可解释内容生成
llm：允许调用 LLM，但必须记录 metadata
real：真实 provider 模式，不允许静默降级
```

### 6.4 `failure_protocol.md`

统一失败处理：

```text
遇到 API Key 缺失、quota 不足、provider 失败、ffmpeg 缺失、ComfyUI 不可连接时：
1. 不伪造成成功
2. 不静默 fallback
3. 写入 status report
4. 标记 blocker
5. 给出用户可执行修复命令
6. 保持已有可运行链路不被破坏
```

### 6.5 `acceptance_commands.md`

统一验收命令：

```powershell
python -m compileall src
python -m src.pipeline --mock
python -m src.pipeline --mock --content-mode rules
python -m src.qa_review --output-dir "outputs\xxx"
python -m src.review_content_asset_quality --output-dir "outputs\xxx"
python -m src.content_asset_quality_check --output-dir "outputs\xxx"
```

---

## 7. 后续 Prompt 优化建议

### 7.1 每个 prompt 开头统一成 6 行

后续可以固定为：

```text
当前项目：andrew-letter-ai-content-pipeline
当前阶段：Step XX
本阶段目标：
本阶段只做：
本阶段绝不做：
必须通过的验收命令：
```

这样 Codex 更容易抓住重点。

### 7.2 文件改动必须分成三类

建议每次写：

```text
必须新增：
必须修改：
禁止修改：
```

这能降低误删、误重构、乱改已有模块的概率。

### 7.3 所有真实 provider 都要写清模式

例如：

```text
本阶段可以实现 provider 接口，但默认不调用真实 provider。
只有用户明确传入 --mode real 或 --voice-mode tts，且 API Key 存在时，才允许调用。
```

### 7.4 每次都要求输出 status report

建议每个核心脚本输出：

```json
{
  "module": "",
  "requested_mode": "",
  "actual_mode": "",
  "used_real_provider": false,
  "fallback_used": false,
  "is_ready_for_review": true,
  "is_ready_for_auto_publish": false,
  "blockers": [],
  "warnings": [],
  "next_actions": []
}
```

### 7.5 把“最终交付物”固定为内容资产包

后续不要再让 prompt 默认追求：

```text
真实图片
真实配音
真实视频
```

而应该默认追求：

```text
高质量微信文章
高质量 B站脚本
高质量抖音脚本
结构化分镜
AI 视觉提示词
发布前审核报告
人工发布清单
内容质量评分
```

---

## 8. 可直接放进项目 README 的 Prompt 总结

```text
本项目的 Codex prompt 工作流采用阶段式推进方式，不一次性追求全自动多媒体成品，而是先建立项目规范、输出结构、mock pipeline、平台风格分析、内容理解、三平台内容生成、人工审核、发布包导出、数据回填和质量复检机制。

项目早期探索过图片、配音和视频自动生成路线，包括 mock 视频、真实 TTS、非 OpenAI provider、DashScope、Edge TTS、ComfyUI 等方案。但经过实践后，项目最终重定位为“三平台高质量内容资产包”：微信公众号文章、B站长视频脚本与分镜、抖音短视频脚本与分镜，以及对应 AI 视觉提示词和人工审核清单。

这套 prompt 系统的核心价值不是让 AI 自动发布内容，而是用 AI 建立一个可复用、可审核、可迭代的内容生产工作流。它体现了 AI 工作流设计、Prompt 工程、内容产品化、平台差异化表达、人工审核、数据反馈和持续优化的完整链路。
```

---

## 9. 后续可复用的 Codex Prompt 模板

```text
你现在继续执行 andrew-letter-ai-content-pipeline 项目。

当前阶段：
Step XX：{阶段名称}

当前项目状态：
- 已完成：{列出已完成能力}
- 当前默认目标：三平台高质量内容资产包
- 多媒体成品路线：optional enhancement，不作为默认验收要求
- 不自动发布，不上传平台，不调用平台 API

本阶段目标：
{只写本阶段要解决的 1–3 个核心问题}

本阶段只做：
1. {任务 1}
2. {任务 2}
3. {任务 3}

本阶段绝不做：
1. 不自动发布
2. 不调用平台 API
3. 不抓取评论
4. 不保存敏感个人信息
5. 不硬编码 API Key
6. 不静默 fallback real 模式
7. 不删除已有可运行链路

必须新增 / 修改文件：
- {文件 1}
- {文件 2}

禁止修改：
- {不能动的文件或模块}

模式规则：
- mock：允许生成占位结果
- rules：允许规则生成
- llm：无 Key 可 fallback，但必须记录 fallback
- real：不允许静默 fallback，失败必须报告 blocker

验收命令：
```bash
python -m compileall src
python -m src.pipeline --mock --content-mode rules
python -m src.review_content_asset_quality --output-dir "outputs/xxx"
python -m src.content_asset_quality_check --output-dir "outputs/xxx"
```

完成后请回复：
1. 修改了哪些文件
2. 新增了哪些文件
3. 本阶段完成了什么
4. 哪些命令通过
5. 是否有 fallback
6. 是否有 blocker
7. 当前限制
8. 下一步建议
```

---

## 10. 最终建议

这套 prompt 已经具备很强的项目推进价值。它最适合作为作品集中的一类能力证明：

```text
我不仅会使用 AI 生成内容，
我能用 Codex 搭建一个完整的 AI 内容生产系统，
包括源内容理解、平台化改写、人工审核、发布准备、数据回填和持续优化。
```

但后续不要再盲目扩展多媒体自动化能力。  
更正确的方向是继续强化：

```text
内容质量
平台差异
个人观点
审核机制
发布前清单
数据回填
复盘优化
Prompt 资产管理
```

这会让项目更稳定、更真实，也更适合作为 AI 产品经理 / AI 内容运营 / AI Workflow Builder 的代表作品。