# Black Myth: Wukong Analytics Prompt 系统总结报告

> 建议项目内保存路径：`docs/prompts/black_myth_wukong_prompt_system_review.md`  
> 对应原始 Prompt 合并文件：`merged(3).txt`  
> 项目名称：`black-myth-wukong-analytics`  
> 报告用途：总结本项目 Codex prompt 工作流、识别可优化点，并沉淀为后续项目可复用的 Prompt 管理资产。

---

## 1. 总体结论

这套 prompt 的核心价值不只是“让 Codex 写一个分析项目”，而是用 Codex 持续推进了一个从 **本地数据分析 MVP** 到 **咨询级公开数据产品**，再到 **中文优先 Private Preview 作品集展示项目** 的完整演进过程。

它已经具备非常强的项目管理属性：

- 有明确项目定位；
- 有真实数据与 mock 数据边界；
- 有数据可信度分级；
- 有公开数据、估算数据、手动数据、内部数据、框架型指标的区分；
- 有 Python 数据管道；
- 有 Streamlit 内部分析工具；
- 有 Web 公开展示层；
- 有 Netlify 非生产 Draft 部署；
- 有 Private Preview QA；
- 有中文本地化 QA；
- 有证据边界、结论边界和来源缺口管理；
- 有面向作品集展示的前端叙事模块规划。

一句话总结：

```text
这套 prompt 已经从“代码生成指令”升级成了“咨询级数据产品的 AI 项目推进系统”。
```

它最适合放在项目里的定位是：

```text
Prompt System / Codex Workflow / AI-assisted Project Management Documentation
```

也就是说，它可以证明：你不是只会让 AI 写代码，而是能用 AI 按照 **数据真实性、分析方法、前端展示、部署验证、私有评审、证据边界** 的完整逻辑推进一个复杂项目。

---

## 2. 项目 Prompt 演进主线

这份 prompt 文件一共包含 **81 个 step block**，从 `step1` 一直推进到 `step8.57`。

整体可以分成 8 个大阶段。

---

### 阶段一：本地数据分析 MVP 建立

对应步骤：

```text
step1
step2
```

核心目标：

从 0 创建 `black-myth-wukong-analytics` 本地项目，完成第一版可运行 MVP。

主要内容包括：

- 建立项目目录；
- 创建 Python 数据分析脚本；
- 设计 Steam 评论采集逻辑；
- 支持 mock 降级；
- 建立评论清洗、好评率、趋势、语言、主题、游玩时长、风险关键词分析；
- 生成指标字典；
- 生成方法论、数据来源、限制说明；
- 建立 Streamlit dashboard；
- 输出 executive report 和 portfolio summary。

这一阶段最重要的 prompt 特点是：

```text
先跑通，再增强；先真实公开数据，再估算；mock 只能测试 pipeline，不能支撑结论。
```

这是非常正确的项目起点。

---

### 阶段二：从作品集 MVP 升级为咨询级公开数据项目

对应步骤：

```text
step2.5
```

核心变化：

项目不再只是“作品集 MVP”或“本地 Streamlit 演示”，而是升级为：

```text
public-facing consulting-grade business intelligence project
```

中文定位变成：

```text
《黑神话：悟空》商业表现、玩家口碑、全球化传播、IP 资产与行业影响综合分析项目。
```

这一阶段确立了双层架构：

```text
Layer 1：Python Data Pipeline
Layer 2：Public Website
```

主要新增方向：

- `web/` 前端项目；
- Vite + React + TypeScript；
- public JSON export；
- Netlify 部署准备；
- consulting report 风格；
- public website 与 Streamlit internal dashboard 区分；
- disclaimer；
- deployment guide；
- consulting_brief；
- public_report_copy。

这一阶段是项目定位的关键跃迁。

---

### 阶段三：真实公开 Steam 数据驱动 v0.1

对应步骤：

```text
step3
step4
```

核心目标：

把项目从“咨询级网站框架”升级为“真实公开 Steam 数据驱动分析 v0.1”。

主要结果：

- 明确真实数据优先；
- 采集真实 Steam 评论；
- 生成 500 条主样本；
- 生成 cleaned reviews；
- 输出数据质量报告；
- 重新生成 reports 与 public JSON；
- 明确 data_mode = Public Steam Data；
- 不再把 mock pipeline sample 写进正式结论；
- 增加手动数据补充计划。

这一阶段做得很关键，因为它阻止项目停留在“漂亮但没数据”的状态。

最重要的原则是：

```text
mock 只用于 fallback 和测试，不得进入正式结论。
```

---

### 阶段四：多源公开数据 v0.2 与 Private Preview 准备

对应步骤：

```text
step5
step6
step6.5
step6.7
step6.8
step6.9
step6.10
step6.11
step6.12
step6.13
step6.14
```

核心目标：

把真实 Steam 数据项目升级为 v0.2 Private Preview，并准备小范围非公开审阅。

主要推进内容：

- 补充多源数据模板；
- 维护 manual source 的缺失边界；
- 准备 Netlify Draft Deploy；
- 尝试插件部署、CLI 部署；
- 回填 Draft URL；
- 做 endpoint QA；
- 做 visual QA；
- 做 private review plan；
- 做 feedback form；
- 建立 issue triage；
- 建立 private review tracker。

这一阶段的强项是：它开始像真实产品发布流程，而不是一次性项目提交。

关键边界也非常清楚：

```text
Private Preview，不是 Public Production。
```

---

### 阶段五：v0.3 QA 修复、中文优先与深度中文化

对应步骤：

```text
step7
step7.1
step7.2
step7.3
step7.4
step7.6
step7.7
step7.8
```

核心目标：

围绕真实 private review / QA 反馈，把 v0.2 升级到 v0.3，并完成中文优先体验。

主要推进内容：

- 录入真实 review feedback；
- 建立 v0.3 修复计划；
- 重新部署 Draft；
- 回填新的 Draft URL；
- 重点 endpoint 复测；
- 文本层 QA；
- 深度中文本地化；
- 中文网页文本 QA；
- 响应式视觉 QA；
- 关闭中文深度本地化 QA；
- 进入 Step 8 内容扩展准备。

这一阶段说明项目已经开始从“数据产品”走向“中文作品集展示产品”。

值得保留的关键判断：

```text
中文优先通过；English mode 需要 i18n polish，作为 minor 保留。
```

这比“强行宣布双语完成”更可信。

---

### 阶段六：Step 8 公开来源模板、来源验证与证据扩展

对应步骤：

```text
step8.1 - step8.10
```

核心目标：

为内容扩展建立公开来源采集、验证、缺失标注和 benchmark source coverage 体系。

主要推进内容：

- 创建公开来源模板；
- 创建 source validation 脚本；
- 建立 source collection guide；
- 填充首批公开来源行；
- 竞品 AppID 验证；
- release date 验证；
- 媒体评分验证尝试；
- Steam review snapshot 验证尝试；
- SteamDB peak CCU 验证尝试；
- benchmark source coverage audit。

这一阶段体现了非常强的数据诚信意识：

```text
无法可靠验证的指标，不填数值。
缺失保持 null / Missing Manual Source / Benchmark Incomplete。
```

这是整套 prompt 里最值得保留的底层原则之一。

---

### 阶段七：证据受限报告、人工来源采集与内部报告 v1

对应步骤：

```text
step8.11 - step8.49
```

核心目标：

在数据仍不完整的前提下，不强行扩大结论，而是做 evidence-limited internal report v1。

主要推进内容：

- expanded report outline；
- Steam sample collection preflight；
- partial Steam sample collection；
- partial evidence boundary update；
- partial evidence section；
- editorial review；
- final scope narrowing；
- internal partial evidence appendix；
- source-gap roadmap；
- manual collection sheets；
- manual source execution planning；
- evidence map；
- final internal report scope lock；
- report v1 draft；
- private review package；
- feedback intake；
- real reviewer feedback triage；
- evidence-bound conclusion strengthening；
- PKG-04 social/search/community 来源处理；
- PKG-05 genre/globalization 来源处理；
- 有限来源整合进 report v1。

这一阶段的核心不是“把报告写长”，而是“把报告写得有边界”。

尤其重要的是：当用户反馈“内容不够完整，数据还有缺乏，没有合理数据导向的结论”后，prompt 没有要求 Codex 伪造数据，而是转向：

```text
证据边界内强化结论
明确 source gap
优先补充可验证来源
```

这是高质量商业分析项目必须具备的能力。

---

### 阶段八：前端叙事模块与作品集展示闭环

对应步骤：

```text
step8.50 - step8.57
```

核心目标：

把报告内容和证据边界转化为前端可读的作品集级叙事模块。

主要推进内容：

- frontend narrative scope lock；
- frontend copy and module content plan；
- component / data mapping；
- frontend copy claim audit；
- Phase A/B static narrative shell；
- local build / static QA；
- browser QA；
- Phase C/D full narrative modules；
- Source Coverage Matrix；
- Benchmark Comparison Logic Cards；
- Supported Judgment Cards；
- Unsupported Claim Cards；
- Partial Steam Review Sample Caveat；
- Evidence Roadmap；
- Report Reader Path Refinement；
- Step 8.57 build/browser QA。

这一阶段非常有价值，因为它解决了一个常见问题：

```text
数据分析项目不是只给一堆图表，而要让读者知道：
当前证据支持什么、不支持什么、还缺什么、该如何阅读完整报告。
```

这已经是咨询级展示思维，而不是普通 dashboard 思维。

---

## 3. 这套 Prompt 最有效的部分

### 3.1 数据真实性原则极强

这套 prompt 反复强调：

```text
不要伪造内部数据。
不要把估算写成官方数据。
不要把缺失数据写成 0。
不要把 review language 写成 sales region。
不要把 event timeline 写成 causal proof。
不要把社媒热度写成销量。
不要把搜索指数写成购买转化。
```

这是本项目最重要的专业底座。

如果把这个项目展示给 HR、业务负责人或数据分析岗位面试官，这一点会非常加分。

---

### 3.2 公开数据与内部数据边界清晰

项目从一开始就区分五类数据：

```text
A. Public Direct
B. Public Estimated
C. Manual Input
D. Internal Required
E. Framework Only
```

这套分类非常适合继续沉淀成你所有数据分析项目的通用标准。

建议后续项目中直接复用：

```text
Data Availability Classification
```

---

### 3.3 从本地 MVP 到公开展示的路线合理

项目不是一开始就做前端大屏，而是先经历：

```text
Python pipeline
↓
mock MVP
↓
真实 Steam 数据
↓
报告
↓
Streamlit internal dashboard
↓
public web
↓
Netlify draft
↓
Private Preview QA
↓
前端叙事增强
```

这个顺序是对的。

它体现了产品化思维：先确认数据与分析，再做展示，再做部署，再做审阅，再做优化。

---

### 3.4 非生产部署与 Production 边界非常清楚

从 Step 6 之后，prompt 一直强调：

```text
禁止 --prod
禁止 Production deploy
禁止 promote production
禁止绑定 custom domain
禁止 public sharing
Private Preview
Not Public Production
```

这说明你对“预览版”和“正式公开版”的边界有清晰意识。

这对于作品集也很重要，因为它避免你把未完成项目包装成完成项目。

---

### 3.5 QA、复测、回填机制很完整

项目后期有大量 QA 文档要求：

- endpoint QA；
- visual QA；
- responsive QA；
- Chinese text QA；
- deep Chinese localization QA；
- claim boundary QA；
- source validation；
- build/static QA；
- browser QA；
- private review tracker；
- issue triage；
- backlog 状态更新。

这让 Codex 不再只是写代码，而是在执行接近真实团队的交付流程。

---

### 3.6 能根据反馈调整项目方向

真实反馈是：

```text
结构都 ok，就是内容不够完整，数据还有缺乏，没有合理数据导向的结论。
```

prompt 后续没有直接让 Codex“补更多结论”，而是先处理：

```text
证据缺口
来源采集
claim audit
evidence-bound conclusion
limited integration
```

这非常成熟。

说明这套 prompt 已经不是“多写点内容”，而是能接受反馈、判断问题性质，并转化为合理的项目路线。

---

## 4. 当前存在的问题

### 4.1 Prompt 后期过于细碎

从 Step 8.1 到 Step 8.57，很多任务已经进入非常细的微步骤。

优点是稳，缺点是：

- 上下文越来越长；
- 每一步重复大量禁止事项；
- step 数膨胀；
- 后续维护成本高；
- Codex 容易被过多历史状态淹没。

建议后续把重复内容沉淀成固定文档：

```text
docs/project_state/current_status.md
docs/project_rules/data_truth_rules.md
docs/project_rules/deployment_rules.md
docs/project_rules/claim_boundary_rules.md
docs/project_rules/file_touch_budget.md
```

后续 prompt 只引用这些文件，不再反复手写全部规则。

---

### 4.2 Step 编号存在跳跃

当前步骤中有：

```text
step7.4
step7.6
```

中间缺少 `step7.5`。

这不影响项目执行，但对长期项目管理不利。

建议新增：

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

记录每一步：

- step 编号；
- step 标题；
- 是否执行；
- 是否跳过；
- 为什么跳过；
- 关键产出；
- 下一步。

---

### 4.3 后期上下文重复严重

很多 step 都重复：

- 当前 Draft URL；
- 当前阶段；
- 已完成事项；
- 禁止 deploy；
- 禁止 production；
- 禁止伪造数据；
- 禁止修改文件；
- 最终输出几十项检查。

这些内容虽然安全，但会让 prompt 越来越长。

建议改成：

```text
本轮必须遵守 docs/project_rules/*.md。
本轮状态以 docs/project_state/current_status.md 为准。
本轮只新增 / 修改下列文件。
```

---

### 4.4 缺少 ADR 决策记录

项目中有几次重大决策：

1. 从本地作品集 MVP 升级为咨询级公开数据产品；
2. Streamlit 降级为内部工具，Web 成为公开站；
3. 不做 Production，先做 Private Preview；
4. 不强行补全无法验证的数据；
5. 中文优先，English polish 作为 minor；
6. 从 dashboard 转向 evidence narrative modules。

这些都应该记录为 ADR：

```text
docs/adr/
├── ADR-001-consulting-grade-public-data-product.md
├── ADR-002-public-website-over-streamlit.md
├── ADR-003-private-preview-before-production.md
├── ADR-004-no-unverified-manual-metrics.md
├── ADR-005-chinese-first-preview.md
├── ADR-006-evidence-narrative-modules.md
```

ADR 可以让项目更像真实工程与产品团队，而不是单次 AI 对话结果。

---

### 4.5 文件触碰预算出现较晚

Step 8.56 / 8.57 已经开始控制：

```text
最多 9 个内容文件
最多 6 个内容文件
```

这是好做法，但出现得偏晚。

建议从所有后续 Codex 项目开始就加入：

```text
File Touch Budget
```

包括：

- 允许新增文件；
- 允许修改文件；
- 禁止修改文件；
- generated artifacts 是否计数；
- 如果超预算必须停止并说明。

---

### 4.6 缺少统一“事实 / 推断 / 建议”输出格式

虽然 prompt 一直强调不要越界，但报告输出和前端模块中应该统一使用：

```text
Fact / Evidence
Inference
Limitation
Recommendation
```

例如每条洞察卡片都可以固定为：

```text
结论：
证据：
这意味着：
不能推出：
建议下一步：
可信度：
```

这样比只写 disclaimers 更强。

---

## 5. 建议优化后的 Prompt 项目结构

建议在项目中新增：

```text
docs/prompts/
├── prompt_index.md
├── prompt_system_review.md
├── codex_prompt_template.md
├── global_project_context.md
├── data_truth_rules.md
├── claim_boundary_rules.md
├── deployment_rules.md
├── qa_rules.md
├── file_touch_budget_rules.md
├── failure_protocol.md
├── acceptance_commands.md
└── legacy_prompt_notes.md
```

---

## 6. 推荐新增：prompt_index.md

建议结构：

```markdown
# Prompt Index

| step | title | phase | goal | key outputs | validation | status | notes |
| ---- | ----- | ----- | ---- | ----------- | ---------- | ------ | ----- |
| 1 | Local MVP | MVP | 建立本地数据分析项目 | Python pipeline / reports / dashboard | compileall / mock pipeline | done | |
| 2 | Real Data Support | MVP+ | 增强真实 Steam 采集 | collector / README / dashboard guard | real collect attempt | done | |
| 2.5 | Consulting-grade Upgrade | Architecture | 升级为公开数据产品 | web / export_public_data / deployment guide | npm build | done | |
```

这样后续项目的每一步都能被追踪。

---

## 7. 推荐新增：codex_prompt_template.md

后续 prompt 建议统一使用以下模板。

```markdown
# Codex Step X：{任务标题}

## 1. 当前项目状态

读取：

- docs/project_state/current_status.md
- docs/project_rules/data_truth_rules.md
- docs/project_rules/deployment_rules.md
- docs/project_rules/claim_boundary_rules.md

本轮只以这些文档作为当前状态来源。

## 2. 本轮目标

本轮只完成：

1. ...
2. ...
3. ...

本轮不处理：

1. ...
2. ...
3. ...

## 3. 允许修改文件

允许新增：

- ...

允许修改：

- ...

禁止修改：

- ...

文件触碰预算：

- 内容文件最多 X 个
- generated artifacts 不计入 / 计入，按本轮说明执行

## 4. 数据真实性边界

必须遵守：

- 不伪造数据
- 不把缺失写成 0
- 不把估算写成官方数据
- 不把相关性写成因果
- 不把评论语言写成销售地区
- 不把社媒热度写成销量

## 5. 执行步骤

1. ...
2. ...
3. ...

## 6. 验收命令

运行：

```bash
python -m compileall src app
python -m src.export_public_data --outputs-dir outputs --reports-dir reports --web-data-dir web/public/data
cd web
npm run build
```

如本轮不允许 build / deploy，必须明确写：

```text
本轮禁止 build。
本轮禁止 deploy。
```

## 7. 失败处理

如果失败：

1. 停止扩大修改；
2. 记录失败命令；
3. 记录错误摘要；
4. 不伪造通过；
5. 更新 backlog；
6. 给出下一步 fix step 建议。

## 8. 最终输出

完成后汇报：

1. 新增文件；
2. 修改文件；
3. 是否运行验证；
4. 是否通过；
5. 是否触碰 Production；
6. 是否改变 claim scope；
7. 当前 backlog；
8. 下一步建议。
```

---

## 8. 推荐新增：data_truth_rules.md

建议内容：

```markdown
# Data Truth Rules

本项目所有分析必须遵守以下规则：

1. Public Direct 数据只能来自公开可访问来源。
2. Public Estimated 必须明确标注 Estimate / Non-official。
3. Manual Input 缺失时必须标注 Missing Manual Source，不得写成 0。
4. Internal Required 不得伪造。
5. Framework Only 不得强行量化。
6. Steam review language 不等于销售地区。
7. Steam review sample 不等于全体玩家。
8. SteamDB peak CCU 不等于销量或总玩家数。
9. Media score 不等于玩家满意度。
10. Social/search metrics 不等于销量。
11. Event timeline 不等于因果证明。
12. 不得生成未被来源支持的 ROI、conversion、regional sales、market share 结论。
```

---

## 9. 推荐新增：deployment_rules.md

建议内容：

```markdown
# Deployment Rules

当前项目默认处于 Private Preview。

除非用户明确授权，否则：

1. 禁止 `netlify deploy --prod`。
2. 禁止 promote production。
3. 禁止绑定 custom domain。
4. 禁止 public sharing。
5. 禁止把 Draft URL 写成 Production URL。
6. 禁止删除 Not Public Production 标识。
7. 禁止删除 Private Preview 标识。

允许：

1. draft deploy；
2. local build；
3. local preview；
4. endpoint QA；
5. browser QA；
6. README 回填 Draft URL。
```

---

## 10. 推荐新增：claim_boundary_rules.md

建议内容：

```markdown
# Claim Boundary Rules

每个结论必须判断：

1. 是否有直接数据支持？
2. 是否只是估算？
3. 是否来自手动来源？
4. 是否属于内部数据需求？
5. 是否只是战略框架判断？
6. 是否需要 caveat？
7. 是否需要写“不能推出什么”？

禁止输出：

- 全平台玩家结论；
- 当前 lifetime sales；
- 当前收入；
- ROI；
- market share；
- regional sales；
- social heat score；
- globalization success；
- English sample conclusion；
- composite ranking；
- unsupported benchmark conclusion。
```

---

## 11. 推荐新增：failure_protocol.md

建议内容：

```markdown
# Failure Protocol

如果遇到失败：

1. 不继续扩大修改；
2. 不伪造成功；
3. 不删除失败证据；
4. 记录失败命令；
5. 记录错误类型；
6. 判断是代码问题、依赖问题、网络问题、权限问题、数据缺失还是来源不可验证；
7. 更新对应 QA 文档；
8. 更新 backlog；
9. 给出下一步修复 prompt；
10. 不触碰 Production。
```

---

## 12. 后续 Prompt 优化方向

### 12.1 把长上下文拆成“状态文档 + 本轮任务”

当前 prompt 经常把全部历史状态写进每一步。

建议改为：

```text
请先读取 docs/project_state/current_status.md。
本轮以该文件为唯一状态来源。
不要根据旧记忆推断状态。
```

这样可以明显压缩 prompt 长度。

---

### 12.2 把禁止事项规则化

不要每一步都写 30 条禁止事项。

改成：

```text
必须遵守 docs/project_rules/data_truth_rules.md
必须遵守 docs/project_rules/deployment_rules.md
必须遵守 docs/project_rules/claim_boundary_rules.md
```

---

### 12.3 把 QA 结果结构化

每次 QA 输出建议固定 JSON 或 Markdown 表格：

```text
qa_item
status
evidence
notes
severity
next_action
```

这样后续可以自动生成 backlog。

---

### 12.4 把 “Not Ready for Public Production” 作为状态机

建议建立项目状态机：

```text
local_mvp
real_data_v0_1
private_preview_v0_2
chinese_first_private_preview_v0_3
portfolio_private_preview_ready
public_production_candidate
public_production_ready
```

每个状态都有进入条件和退出条件。

---

### 12.5 建立“结论证据映射表”

建议新增：

```text
docs/evidence/claim_evidence_map.md
```

字段：

```text
claim_id
claim_text
evidence_source
data_availability
confidence_level
limitation
frontend_module
report_section
status
```

这样可以避免报告和前端越界。

---

## 13. 可以直接放进项目的 Prompt 总结

下面这段可以作为项目内 `docs/prompts/prompt_system_summary_short.md` 的短版。

```markdown
# Prompt System Summary

本项目的 Codex prompt 工作流围绕《黑神话：悟空》商业与运营数据分析展开，从本地 MVP、真实 Steam 数据采集、咨询级公开网站、Netlify Private Preview，到中文优先 QA、证据受限报告和前端叙事模块逐步推进。

这套 prompt 的核心价值不在于一次性生成代码，而在于用 AI 辅助完成一个复杂数据产品的持续迭代：

1. 先建立 Python 数据管道和 mock MVP；
2. 再接入真实公开 Steam 评论数据；
3. 明确区分 Public Direct、Public Estimated、Manual Input、Internal Required、Framework Only；
4. 生成报告、指标字典、方法论和限制说明；
5. 将 Streamlit 定位为内部分析工具；
6. 将 Vite/React Web 定位为公开展示网站；
7. 通过 Netlify Draft Deploy 进入 Private Preview；
8. 经过 endpoint QA、visual QA、responsive QA、中文文本 QA、claim boundary QA；
9. 在真实反馈后，不伪造数据，而是强化 evidence-bound conclusion；
10. 最终通过 Source Coverage Matrix、Supported / Unsupported Judgment Cards、Evidence Roadmap 等前端叙事模块，说明当前证据支持什么、不支持什么、还缺什么。

本项目 Prompt 体系的核心原则是：

- 不伪造数据；
- 不把缺失值写成 0；
- 不把估算写成官方事实；
- 不把相关性写成因果；
- 不把评论语言写成销售地区；
- 不把社媒热度写成销量；
- 不把 Private Preview 写成 Public Production；
- 所有结论必须有证据边界。

因此，这套 prompt 可以作为项目中的正式资产，证明项目不仅有代码和页面，也有 AI 项目管理、数据真实性治理、Prompt 工程和咨询级表达能力。
```

---

## 14. 最终建议

这套 prompt 已经非常适合作为作品集项目的“幕后能力证明”。

如果放进个人主页，可以这样描述：

```text
我使用 Codex 将一个游戏评论分析脚本，逐步推进为咨询级公开数据分析项目。整个过程包括真实 Steam 评论采集、数据质量检查、指标体系设计、商业估算边界、报告生成、Web 展示、Netlify Private Preview、中文化 QA、证据边界审查和前端叙事模块建设。
```

更短的版本：

```text
通过 Codex 构建并迭代一个《黑神话：悟空》商业与运营数据分析项目，从真实数据管道到咨询级展示网站，完整体现 AI 辅助数据产品开发、Prompt 工作流设计和证据边界管理能力。
```

最终判断：

```text
这套 prompt 的质量已经超过普通作品集项目，更接近“AI 驱动的数据产品交付流程”。后续优化重点不是继续写更长的 prompt，而是把重复规则沉淀为项目文档，把 step 记录结构化，把数据真实性、部署边界、claim boundary 和 QA 流程制度化。
```