从 AI 对话到可复现的 ASO 工作流

一位 ASO 专员导出关键词报告，在 AI 对话中获得一份看起来不错的元数据方案。另一位专员用略有不同的提示词，在另一个 AI 工具中重复同一任务。几周后，团队却无法回答四个基本问题：

• AI 分析的是哪一份数据？
• AI 遵循了哪些指令？
• 为什么一个方案被批准，而另一个被拒绝？
• 最终在应用商店中修改了什么？

问题不在于 AI 模型的质量，而在于团队把聊天记录当成了决策系统。

更可靠的方法，是把 ASO 工作设计成可审查的生产流程。分析前，先通过 ASO.dev 导出或 MCP 准备当前应用基线；随后收集任务所需的竞品与关键词，并将其来源连同提示词、报告和决策一起保存在 Git 中。LLM 分析这些明确输入，最终操作前仍必须由人工审查。

这样，孤立的 AI 对话就会转化为整个团队都能检查和复现的工作流。

术语说明： Apple 于 2025 年将 Apple Search Ads 更名为 Apple Ads。本文使用当前名称，但部分导出文件和历史报告中仍可能出现“Apple Search Ads”或“ASA”。

每个组件都应承担清晰且单一的职责。

整个流程应保持简单：

通过 ASO.dev 准备当前应用基线
（导出和/或 MCP）
    ↓
在 ASO.dev 中完成任务研究
（手动与自动竞品搜索、Spy、
竞品关键词、自然关键词搜索）
    ↓
包含数据清单的任务分支
    ↓
LLM 按版本化提示词进行分析
    ↓
分析报告与元数据方案
    ↓
通过 ASO.dev MCP 与跨区本地化校验
    ↓
Pull Request 审查
    ↓
人工批准并执行最终操作
    ↓
在 Git 中记录实际应用结果

数据导出与 MCP 并不是互斥的输入。开始工作前，ASO.dev 可以通过两种方式准备应用的当前基线：导出为团队提供固定文件，MCP 则提供所选应用受支持的实时数据。团队可以选择其中一种，也可以结合使用。如果基线来自 MCP，应在任务中记录具体值和获取时间，以保持分析的可复现性。

下一层是任务专用研究数据。在 ASO.dev 中，专员可以手动添加已知竞品，使用自动竞品发现，并从 Spy、竞品分析、关键词搜索和自然关键词发现中收集候选关键词。经过审查的结果将成为团队 pipeline 的输入。每项输入都应保留其来源、日期、应用商店、国家和筛选条件。

AI 对话适合作为临时工作区，但并不适合作为团队协作记录。

应用定位、目标市场、品牌限制和历史决策通常分散在多条消息中。新的对话没有这些上下文，而另一位专员也可能向 AI 提供不同版本的信息。

截图或没有说明的 CSV 文件，无法证明导出日期、市场、语言、统计周期、完整性和筛选条件。缺少这些信息时，即使建议看似合理，也无法可靠验证。

如果每位专员都保存自己的私人提示词，团队就无法判断输出差异的原因，也无法在一次失败分析后共同改进指令。

聊天中的一句“看起来不错”，无法说明获批的究竟是哪一个标题、副标题、关键词字段、出价调整或否定关键词列表。

Git 本身不会让分析自动变得正确，但它能让输入、规则、输出和决策具备可审查性。

开始时不需要大型平台项目。一个小型私有仓库就足够：

aso-workspace/
├── README.md
├── AGENTS.md
├── apps/
│   └── my-app/
│       ├── app-context.md
│       ├── exports/
│       ├── reports/
│       └── proposals/
├── prompts/
│   └── metadata-optimization.md
├── workflows/
│   └── metadata-update.md
└── templates/
    └── pull-request.md

这些文件具有不同的生命周期：

• app-context.md 保存相对稳定的产品和品牌背景；
• exports/ 保存带日期的数据快照，或指向受控存储的清单；
• prompts/ 保存可复用的分析指令；
• workflows/ 定义所需输入、输出、审查和批准规则；
• reports/ 与 proposals/ 保存按日期区分的任务结果，而不是反复覆盖同一个 final 文件。

Agent 指令文件应简短且可执行。它应该要求 LLM：

1. 开始前先阅读应用上下文和相关工作流；
2. 明确当前应用基线来自 ASO.dev 导出、MCP 还是两者，并记录获取时间；
3. 记录每个研究数据集的来源、日期、应用商店、国家、语言、周期和筛选条件；
4. 将已记录的基线与选定任务数据共同作为分析输入；
5. 不得虚构排名、热度、花费、转化或收入指标；
6. 明确区分源数据、观察、假设和建议；
7. 创建新的日期化报告，而不是覆盖历史记录；
8. 列出缺失或过期的输入；
9. 在任何生产操作前停止，并请求人工批准。

这些指令可以提高一致性，但它们不是安全边界。生产访问仍必须通过真实的工具权限和人工批准流程来限制。

假设团队需要审查美国 App Store 的标题、副标题和关键词字段。

在收集数据之前先记录范围：

应用：Example App
应用商店：App Store
国家：美国
语言：en-US
字段：title、subtitle、keyword field
目标：在不改变品牌定位的前提下，提高相关关键词覆盖率

这样可以避免分析扩展到无关本地化或未经批准的产品声明。

git checkout main
git pull
git checkout -b aso/us-metadata-2026-07

每个分支应只对应一项可审查任务。如果能提高审查清晰度，可以将源数据更新、提示词修改和最终方案拆分为不同的逻辑提交。

研究开始前，先通过 ASO.dev 导出或 MCP 准备应用当前状态。基线可以包含受支持的应用标识、应用商店与本地化上下文，以及任务所需的当前元数据。导出会生成固定文件；MCP 则可以直接从所选应用准备相同的工作上下文。使用 MCP 时，应在任务报告或清单中保存相关值与获取时间。

随后收集任务所需的研究数据：

专员审查这些结果，并导出应进入 pipeline 的竞品与关键词。发现结果只是候选项，而不是自动建议：不相关应用、品牌词和弱意图关键词应在 LLM 分析前被排除或清晰标注。

在数据旁添加 export-info.md：

# 导出信息

导出日期：2026-07-20
应用：Example App
应用商店：App Store
国家：US
语言：en-US
分析周期：2026-06-20 至 2026-07-19
当前应用基线：ASO.dev MCP，获取于 2026-07-20 09:00 UTC
研究来源：手动竞品、自动竞品搜索、Spy、自然关键词搜索

已知限制：
- 并非所有自动发现的竞品都已完成审查；
- 不包含收入数据。

这些限制本身就是数据集的一部分。LLM 不应通过猜测来“补全”缺失内容。

由于详细规则已经保存在仓库中，交给 AI 助手的任务可以保持简洁：

阅读 AGENTS.md、apps/my-app/app-context.md、
workflows/metadata-update.md、已记录的当前应用基线，
以及 2026-07-20 选定的美国区研究数据集。

使用 prompts/metadata-optimization.md。

分析当前 title、subtitle 和 keyword field。
创建分析报告与元数据方案。
明确列出缺失数据和假设。
不要执行任何生产操作。

预期输出不应只有一组字符串，而应是一份可审查报告，其中包括：

• 数据来源；
• 相关关键词簇；
• 当前元数据覆盖评估；
• 建议字段；
• 每项修改的理由；
• 被拒绝的备选方案；
• 风险与未解决问题。

分析方案完成后，使用 ASO.dev MCP 确认目标应用，并校验受支持的元数据字段。检查内容可能包括字段长度、必填值、本地化、格式、重复内容，以及方案是否与所选应用一致。

对于 App Store 元数据，请打开目标国家的跨区本地化页面。该页面会同时显示在这个 storefront 中共同参与索引的主本地化与其他本地化。在另一个参与索引的本地化中重复使用 title、subtitle 或关键词字段里的词，不会增强索引效果，反而会浪费有限的元数据空间。

MCP 也会以机器可读形式提供这项检查。调用 get_editor_data 时传入目标国家；如果只需要 title、subtitle 和 keywords，可同时设置 asoOnly: true。ASO.dev 会选择该国家对应的跨区本地化，并在 validation 中返回跨本地化警告或错误，指出受影响的本地化、字段以及关联的本地化或字段。请在方案中记录国家、已校验的本地化集合和尚未解决的重复词警告。

AI Companion 在本地运行。AI 可以查看和编辑本地 ASO.dev 工作区中的受支持元数据，但最终保存仍需人工完成。这样既能根据真实应用状态进行校验，也不会把一条提示词变成发布权限。

Pull Request 应回答审查者真正关心的问题：

• 使用了哪一份导出？
• 哪些字段属于本次范围？
• 修改了什么，为什么？
• MCP 针对哪个国家和哪组跨区本地化进行了校验？
• 哪些重复词警告关联了两个本地化或字段？
• 还存在哪些警告？
• 哪些操作需要明确批准？

审查时应将方案与源数据、品牌规则、应用商店限制和准确 diff 进行比较。批准只适用于 Pull Request 中的具体版本，而不适用于 AI 以后生成的任意变体。

人工保存获批元数据后，在任务记录中补充：

• 最终应用的具体值；
• 应用和本地化；
• 批准人；
• 应用日期；
• 获批方案与实际应用版本之间的差异。

至此，分析与生产变更形成完整闭环。

同样的审查模式也适用于 Apple Ads 分析，但执行路径不同。

导出相关的广告系列、广告组、关键词、搜索词、匹配类型、出价、展示、点击、安装、花费、转化和否定关键词。记录报告周期以及任何归因限制。

LLM 可以将搜索词分类为：

• 扩量；
• 继续收集数据；
• 添加为 Exact；
• 考虑添加为 Negative；
• 提高或降低出价；
• 经专家审查后暂停。

每项建议都应说明数据证据和样本量限制。获批的广告操作随后通过 Apple Ads 或另一个明确授权的界面执行，并记录在仓库中。

不要让读者误以为 metadata MCP 会自动提供完整的广告系列分析或管理权限。分析数据导出与操作工具仍是两个独立组件，除非某项受支持的集成明确说明具备相关能力。

分支可以隔离任务，同时让团队保持可见性：

aso/us-keyword-research-2026-07
aso/de-localization-2026-07
aso/review-analysis-2026-07
apple-ads/us-search-terms-2026-07
workflow/metadata-approval-v2
prompt/competitor-analysis-v2

不要让多位专员同时覆盖同一份报告。每项任务应生成带日期的草稿，再通过审查形成一个批准版本。如果两位专员测试不同提示词，应保留双方的输入和输出，让团队比较方法，而不是比较不同聊天中的截图。

提示词和工作流的修改也应通过 Pull Request。提示词属于分析方法的一部分。修改规则时，应记录观察到的问题、受影响任务、新规则以及评估改进的方法。

Git 历史具有长期性。这对决策记录很有价值，但对密钥非常危险。

切勿提交凭据、私钥、访问令牌、个人数据或不必要的财务信息。把文件加入 .gitignore，并不能删除已经提交到历史中的密钥。

原始导出也不一定都适合放入 Git：

• 在仓库访问权限得到适当限制时，可以提交小型且已脱敏的 CSV；
• 大型或敏感导出可以存放在受控对象存储中，并在 Git 中提交不可变引用、checksum、导出元数据和访问说明；
• 保存用户级或商业敏感数据前，应先定义保留周期与删除规则。

每个操作接口都应采用最小权限。类似“不要发布”的指令很有帮助，但真正的控制来自实际权限、确认步骤和审计日志。

默认安全流程是：

1. 分析；
2. 提出方案；
3. 校验；
4. 审查；
5. 批准；
6. 人工应用；
7. 记录结果。

团队无需迁移所有历史报告，也能开始采用这套工作流。

先选择一个应用、一个市场、一项重复发生的元数据任务和一条经过审查的提示词。完整运行两次流程。第二次完成后，只修改那些确实造成困惑或增加审查成本的指令。

目标不是增加流程，而是保留足够的上下文，让另一位专员无需重新打开原始 AI 对话，也能理解并复现决策。

合并 ASO 或 Apple Ads 任务前，请确认：

• 已明确应用、应用商店、国家、语言和周期；
• 已确定分析数据集或其不可变引用；
• 缺失数据和假设清晰可见；
• 提示词与工作流已进行版本管理；
• 报告将证据与建议明确分开；
• 受支持的元数据已针对目标应用和国家完成校验；
• 已审查相关跨区本地化之间的重复词；
• Git 历史中没有凭据或敏感数据；
• 人工审查了准确的建议版本；
• 最终应用结果将被记录。

当这些信息都保存在仓库中时，AI 就不再是孤立的助手，而会成为可审查 ASO 工作流的一部分。