From f76f1662418bc331bd8411afce6ec056116c07c0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E5=BC=A0=E6=96=87=E6=B6=9B?= <1909118034@qq.com>
Date: Wed, 21 Oct 2026 11:48:25 +0800
Subject: [PATCH] docs: refine cross-platform acquisition assistant plan

---
 README.md                 |  12 +-
 docs/初步讨论方案-v0.1.md |   6 +-
 docs/整体方案-v0.2.md     | 337 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 353 insertions(+), 2 deletions(-)
 create mode 100644 docs/整体方案-v0.2.md

diff --git a/README.md b/README.md
index dc33995..fee1292 100644
--- a/README.md
+++ b/README.md
@@ -2,15 +2,25 @@
 
 面向国内商家的 AI 获客助手，当前处于产品与技术方案讨论阶段。
 
+首版桌面端同时适配 Windows 和 macOS，两端按同一业务范围开发和验收。
+
 产品设想是让商家配置商品与目标客户条件，由软件通过搜索或浏览视频发现相关账号，再结合主页和评论识别潜在需求，整理线索并执行后续跟进任务。
 
 ## 当前文档
 
+- [AI 获客助手整体方案](docs/整体方案-v0.2.md)：推荐实施路线，覆盖桌面端、学习固化、浏览器执行、AI 服务、计费和开发顺序。
 - [AI 获客助手初步讨论方案](docs/初步讨论方案-v0.1.md)：业务场景、学习固化链路、AI 分工、端形态、收费思路及首版验证范围。
 
+## 当前路线
+
+- 使用 Electron 开发 Windows、macOS 双平台桌面端。
+- 以 Playwright 固定执行为主线，Midscene 作为可选辅助；A2A 与 browser_use 仅供设计和实现参考，不设优先复用要求。
+- 模型由我们在运营后台按文本判断、复杂复核、视觉操作等用途配置，不绑定具体型号。
+- 先验证单平台、单账号的搜索到线索流程，再逐步完成跟进、计费和扩展。
+
 ## 项目状态
 
-当前仓库仅包含初步方案，尚未实现获客平台功能。文档中的建议选型、套餐价格、分析额度和成本示例都不是最终产品承诺。
+当前仓库仅包含讨论与整体设计文档，尚未实现获客平台功能。文档中的建议选型、套餐价格、分析额度和成本示例都不是最终产品承诺。
 
 本项目使用现有 `assistant` 目录维护，不另建同名项目，也不直接引入完整 A2A 工程作为运行依赖。
 
diff --git a/docs/初步讨论方案-v0.1.md b/docs/初步讨论方案-v0.1.md
index d9cda92..0439dfc 100644
--- a/docs/初步讨论方案-v0.1.md
+++ b/docs/初步讨论方案-v0.1.md
@@ -6,6 +6,10 @@
 
 阶段：初步讨论，尚未进入功能实现。
 
+后续整体实施路线见 [整体方案 v0.2](整体方案-v0.2.md)。本稿保留最初讨论及当时的价格与成本假设。
+
+后续已明确首版桌面端同时适配 Windows 和 macOS；下文端形态待定内容为最初讨论记录，以 v0.2 为当前实施方案。
+
 ## 1. 产品目标
 
 为国内商家提供一款可以持续发现潜在客户、判断需求并管理跟进的 AI 获客工具。首批讨论对象是抖音、小红书、快手等内容平台，暂不扩展跨境电商。
@@ -244,7 +248,7 @@ browser-use 可作为浏览器 Agent 组件参考，WorkBuddy 可用来快速试
 4. 首版是否完成自动关注与消息发送，哪些情况进入待判断或人工接管。
 5. 采用什么模型、哪些判断需要多模态，以及如何定义有效线索。
 6. 软件按设备、账号或团队计费，包内额度与加量包怎样设计。
-7. 现有学习端与 browser_use 项目可复用到什么程度。
+7. 现有学习端与 browser_use 项目有哪些设计和实现值得参考，是否需要采用具体组件。
 
 ## 12. 参考链接
 
diff --git a/docs/整体方案-v0.2.md b/docs/整体方案-v0.2.md
new file mode 100644
index 0000000..7d04f49
--- /dev/null
+++ b/docs/整体方案-v0.2.md
@@ -0,0 +1,337 @@
+# AI 获客助手整体方案
+
+版本：v0.2
+
+整理日期：2026 年 10 月 21 日
+
+状态：已确认产品范围与建议实施路线，尚未进入功能开发。已确认事项、实施建议和待验证选择在第 13 节分别记录，不代表功能已经实现或通过测试。
+
+## 1. 建议采用的整体路线
+
+产品由三部分组成：**商家安装的桌面端、我们维护的学习与链路开发工具、云端 AI 与商业后台。**
+
+桌面端负责账号登录、浏览器操作、任务运行和线索管理；学习工具负责把平台操作变成经过验证的能力包；云端负责模型调用、软件权益、订单和额度结算。
+
+第一版明确同时适配 Windows 和 macOS，两端按同一业务范围开发、验证和发布。先验证抖音网页版和建材场景；正式首发内容平台取决于网页版所需功能的验证结果。小红书、快手和手机执行端放在后续扩展阶段。
+
+桌面框架采用 Electron，界面建议采用 React + TypeScript。浏览器侧以 Playwright 固定执行为主线，围绕当前产品需要设计能力契约、定位、等待和状态核验。A2A 与 browser_use 可作为设计和实现参考，不设优先复用要求。Midscene 是可选辅助组件，在出现明确定位或视觉需求后再对比引入，不作为首版必选依赖。
+
+本地存储建议采用 SQLite，新增执行器和服务端建议采用 Node.js/TypeScript，云端数据库建议采用 PostgreSQL。实现选择以当前需求、验证效果和双端分发维护成本为依据；不把保留、迁移或重写其他项目作为本项目的任务前提。具体依赖版本在原型通过后固定。
+
+模型由我们在运营后台按用途配置，客户端不绑定具体厂商或版本。基础分析优先验证较低成本模型，复杂复核和视觉操作分别配置，均有独立预算。
+
+这是一套围绕获客业务组织的产品。正常运行的链路、参数和分支由程序控制，模型负责内容理解和少量需要重新理解页面的步骤。
+
+## 2. 商家使用过程
+
+1. 安装软件，登录我们平台的产品账号。
+2. 添加平台账号，在软件管理的浏览器中自行登录抖音等平台。
+3. 创建商品档案：商品、使用场景、服务地区、客户类型和排除条件；未设置的地区等条件不自动补齐。
+4. 配置搜索关键词或推荐流入口、任务范围、预算及跟进方式。
+5. 启动任务，查看候选视频、主页判断、评论线索和筛选依据。
+6. 对匹配对象执行配置的关注、私信及后续跟进任务，记录结果。
+7. 查看任务报告、已用分析额度和后续回复。
+
+第一版建议提供账号、商品档案、任务、线索、跟进、用量六个主要页面。链路开发和模型调试放在维护工具中，商家主要配置业务条件。
+
+自动关注和私信继续保留为产品目标。研发顺序先验证发现与筛选，再验证跟进动作；首版正式开放范围依据验证结果确定。
+
+## 3. 业务主流程
+
+保留关键词搜索和推荐流浏览两个入口，首轮先完成搜索入口。内容判断后分成同行商家和采购方两条路径。
+
+```mermaid
+flowchart TD
+    A[商品与目标客户条件] --> B[搜索或浏览视频]
+    B --> C[内容相关性判断]
+    C -->|不相关| B
+    C -->|相关或需要上下文| D[读取主页与相关作品]
+    D --> E{账号角色与需求}
+    E -->|同行商家| F[读取相关视频评论及回复]
+    F --> G[评论采购意图判断]
+    E -->|作者有采购需求| H[核对需求与商品条件]
+    E -->|信息不足| I[待判断]
+    G --> J[线索去重与依据保存]
+    H --> J
+    J --> K[关注与私信任务]
+    K --> L[核对结果并记录后续回复]
+```
+
+内容相关不代表有采购意图。同行身份也不排除采购需求，例如面向经销商销售的商品。一个账号可以有多个角色标签，业务分支按当前需求决定。
+
+## 4. 系统如何分工
+
+```mermaid
+flowchart LR
+    subgraph DEV[维护者环境]
+        LEARN[学习与调试工具] --> CHECK[参数化与回归验证]
+        CHECK --> PKG[版本化能力包]
+    end
+    subgraph LOCAL[商家电脑]
+        UI[Electron 商家界面] --> RUN[任务与链路执行器]
+        RUN --> ADAPTER[平台适配器]
+        ADAPTER --> PW[Playwright 浏览器驱动]
+        PW --> BROWSER[按账号隔离的浏览器]
+        RUN --> DB[SQLite 任务与线索记录]
+        RUN -. 按需评估 .-> MS[可选 Midscene 辅助]
+        MS -.-> PW
+    end
+    subgraph CLOUD[云端服务]
+        API[账号与权益 API] --> LEDGER[订单与额度账本]
+        CONFIG[运营后台模型配置] --> AI
+        AI[AI 网关] --> MODEL[文本与视觉模型]
+        AI --> LEDGER
+        RELEASE[能力包与客户端版本发布]
+    end
+    PKG --> RELEASE
+    RELEASE --> RUN
+    UI --> API
+    RUN --> AI
+    MS --> AI
+```
+
+这张图表达职责，不表示首版需要拆成许多独立服务。云端可以先用一个应用和一个 PostgreSQL 实例；本地用一个桌面程序配独立执行进程。
+
+### 4.1 桌面端
+
+桌面采用 Electron，界面建议使用 React + TypeScript，Windows 和 macOS 共享界面、任务、平台链路及 AI 客户端代码；应用目录、系统凭据存储、进程管理、菜单快捷键、安装与升级通过小范围系统适配处理。界面用于配置、查看和接管；浏览器任务放到独立执行进程，避免耗时操作阻塞界面。新增执行代码建议采用 Node.js/TypeScript，界面通过受限 IPC 调用任务能力。只有某个外部组件有明确价值并通过验证时，才按需增加其他运行时和进程适配。
+
+第一版建议控制独立、可见的浏览器窗口，不先建设复杂的内嵌浏览器画面和远程桌面。Electron 的界面窗口和被自动化控制的平台浏览器是两部分。
+
+该进程划分参考 [Electron 官方进程模型](https://www.electronjs.org/docs/latest/tutorial/process-model)。打包、进程退出和浏览器生命周期都需要在 Windows 与 macOS 安装包中分别验证。
+
+构建目标建议覆盖 Windows x64、macOS Apple Silicon（arm64）和 Intel（x64）。最低系统版本在锁定 Electron、Playwright 和浏览器版本后明确，以各依赖支持范围的交集为准，不直接承诺所有历史 Windows/macOS 版本。参考 [Electron 支持平台](https://github.com/electron/electron#platform-support)与 [Playwright 系统要求](https://playwright.dev/docs/intro#system-requirements)。
+
+安装包按目标平台及架构产出，例如 Windows 安装程序和 macOS DMG。各端构建、签名与 macOS 公证、升级和回滚分别建立流水线；SQLite 等原生依赖和配套浏览器也按平台、架构准备。共享业务代码不意味着一份二进制安装包直接用于所有系统。分发方式参考 [Electron 官方打包说明](https://www.electronjs.org/docs/latest/tutorial/application-distribution)。
+
+### 4.2 浏览器与账号
+
+固定执行层负责打开页面、点击、输入、滚动、等待和读取，首选 Playwright，按本项目的能力契约封装与验证。一个运行会话明确由一个驱动持有。每个平台账号绑定独立的浏览器数据目录，保留其登录状态。产品账号、平台账号和浏览器目录分别建模。
+
+一个平台账号同一时间由一个执行任务持有，暂停接管时移交控制权，避免人和执行器同时操作。同一数据目录不得被多个浏览器实例同时占用。
+
+首版可先运行一个平台账号，但数据结构从开始就保留账号标识。登录失效进入等待登录状态，完成登录并核验身份后再继续。
+
+浏览器通道与版本、视口和页面条件尽量保持可比较，优先复用两端相同的网页链路。字体、快捷键、缩放及平台页面差异仍需分别验证；存在必要差异时由适配层处理。首版浏览器控制不依赖全屏鼠标坐标或系统级桌面点击。
+
+持久化目录与连接能力以 [Playwright 官方 BrowserType 文档](https://playwright.dev/docs/api/class-browsertype#browser-type-launch-persistent-context)为依据。首版使用专用目录，不依赖复制商家日常浏览器的整份资料。
+
+### 4.3 本地与云端的数据边界
+
+本地 SQLite 保存平台账号映射、任务、检查点、候选内容、线索、证据及动作结果。浏览器登录资料保留在对应本地目录。
+
+云端 PostgreSQL 保存产品账号、设备权益、订单、额度账本、模型请求计量以及版本清单。模型分析按任务提交所需文本或图片。
+
+第一版以本地线索为主，不默认建设全量线索同步。网页后台先服务产品管理、订单、用量和发布；如果后续要在手机上查看线索，再增加明确的线索同步功能。
+
+供应商模型密钥保存在服务端。客户端通过我们自己的 AI 网关调用模型，网关负责身份、模型路由、额度和请求预算。模型配置发布后有明确版本；客户端按业务用途调用，服务端记录实际使用的配置与模型。若引入 Midscene 或 browser_use 的模型调用，也接入这层网关，分别验证协议及模型适配兼容性。
+
+## 5. 学习端怎样落地
+
+### 5.1 谁负责学习
+
+首版由我们在维护者环境中学习、调试和验证平台链路，然后发布给商家使用。同一版本的共性平台操作可以复用；商家的关键词、商品和客户条件作为运行参数。
+
+学习端从开发工具做起：观察真实操作、记录页面状态、生成或编写脚本、参数化、运行样本、查看结果。不要求第一版就做成商家能自行学习任意网站的完整通用产品。
+
+### 5.2 学习的产物
+
+每条能力包至少包括：能力名称、内容平台、版本、输入输出定义、前置条件、动作实现、等待与完成判据、错误状态、恢复规则、操作系统与浏览器兼容范围和验证样本。发布清单记录 Windows 与 macOS 各自的验证状态，不能把单端通过视为双端通过。
+
+例如，搜索能力输入关键词和读取范围，输出候选视频与来源；评论能力输入视频标识和进度，输出本轮评论、父子关系、来源及下一读取状态。
+
+固化的是“如何找到并处理当前对象”，不是把一次录制中的第几个按钮或屏幕坐标照搬到所有任务中。动态评论列表需要每次重新识别当前内容；DOM 句柄不能作为跨运行的长期身份。
+
+### 5.3 首批学习范围
+
+首批沿用六类链路：搜索、视频读取与切换、主页与作品读取、评论与回复读取、关注、私信。跟进链路把准备、动作和结果核对分开。
+
+运行端只需要按业务规则编排这些能力。第一版不引入完整 A2A 的通用能力目录、多 Agent 协商和全域任务规划。
+
+### 5.4 现有项目与开源项目的角色
+
+- **A2A 学习端及 browser_use：** 可参考能力包、参数化、定位、等待、会话和结果核验的设计与实现，不设优先复用、资产盘点或迁移要求。具体代码或组件只有适合当前需求时才考虑采用；其他业务验证不能等同于获客平台适配完成。
+- **Midscene：** 作为可选的探索页面、局部定位、视觉读取和诊断组件，出现明确需求后，验证其效果、成本与集成价值。其规划与定位缓存可以减少调用，但查询和断言仍可能调用模型，不能直接当作免模型的已发布能力包。参见 [缓存机制](https://midscenejs.com/caching)和 [Playwright 集成](https://midscenejs.com/integrate-with-playwright)。
+- **OpenAdapt Flow：** 重点研究录制、编译、参数化和执行后检查。当前开发位于 [OpenAdapt 主仓库的 flow 包](https://github.com/OpenAdaptAI/OpenAdapt/tree/main/packages/flow)。首版先参考产物设计，验证通过后再决定是否接入 Python 运行时。
+- **Riot、Browser Use Desktop、Workflow Use：** 保留为实现参考与对照原型，暂不作为首版同时引入的运行依赖。
+
+第一版普通流程优先用显式代码执行。页面不匹配时可以调用有预算的只读诊断；发现新的操作方法后，在维护环境验证并发布新版本。已发布任务不直接把临时探索结果当作新能力包。
+
+### 5.5 参考项目与本项目的边界
+
+选型以当前业务需要和执行方式为准。browser-use 的 Agent 可以探索页面，也提供直接动作与无 LLM 的初始动作；不能把它等同于所有步骤都必须调用大模型。参见 [官方 Agent 配置](https://docs.browser-use.com/open-source/customize/agent/all-parameters)。这些能力可供参考，不构成必须采用它的理由。
+
+本项目重复运行少量已知流程，首选 Playwright 固定执行、普通程序等待和结果核对，模型主要处理内容判断。降低调用量来自链路固化和职责划分，不能仅归因于更换框架。只有需要在具体实现之间做选择时，才使用相同流程和模型条件比较，不把旧项目对照测试设为开发前置。
+
+A2A 与 browser_use 提供设计和实现经验，本项目独立定义需要的功能、数据结构和执行边界。可以借鉴思路、按需采用合适组件，也可以直接实现；不为了复用而增加旧项目耦合、额外运行时或迁移工作。学习与运行端通过能力契约隔离底层驱动，不把框架对象写入业务数据格式。
+
+此前对本机代码的只读核对显示，A2A 学习工程已有 Playwright 参数化动作、定位和等待实现，旧 browser_use 工程也有固定流程与会话管理实现。这些是可参考的实现案例，不是本项目的依赖或现成获客链路；测试宿主也不能直接视为商家生产执行器。
+
+首轮围绕搜索、主页和评论构建最小只读链路，记录完成情况、读取正确性、模型调用量、总耗时以及 Windows/macOS 分发维护工作量。只有出现明确的探索、视觉或定位问题时，再针对该步骤评估 Midscene 等辅助方案。正常流程不能同时由两个驱动无协调地控制同一浏览器会话。
+
+## 6. AI 判断与调用成本
+
+### 6.1 三个判断分别记录
+
+内容相关性、账号角色、采购意图分开定义输入和结果，也分别评估误判与漏判。实现时可把有共同上下文的判断合并到一次模型请求中，仍保留三个独立字段。
+
+结果包括对象标识、分类、需求信号、原文依据、缺失信息、模型和规则版本；信息不足时返回待判断。模型自评分仅用于排序实验，不能直接当作识别准确率。
+
+评论分析保留所属视频、父评论和必要回复，区分作者、评论者和商家。新评论或变化后的上下文需要重新判断。
+
+### 6.2 文字优先，视觉按需
+
+能用标题、简介和评论判断的，优先使用文本。视频信息不足时，才评估截图、OCR、语音转写或视频理解；它们有独立预算。
+
+“相关性”不仅是词面或向量相似度，“购买意图”也不能由相似度直接替代。是否使用向量检索取决于样本规模，首版不必先建设向量数据库。
+
+轻量文本模型、较强复核模型和视觉模型通过适配层接入，具体型号在同一批样本上比较后确定。每次结果应能关联输入内容和规则版本。业务分析结果的复用键包含内容与上下文、商品条件、提示规则、模型及结果结构版本，并设置适合内容时效的有效期。
+
+### 6.3 两类成本分开
+
+我们维护平台时的学习、探索、链路修复，属于产品研发与维护成本。商家运行中的文本分析、视觉分析和可选页面诊断属于实际运行用量。
+
+普通 Playwright 代码不产生 LLM Token 费用；使用 Midscene 的 AI 操作、查询、断言或异常分析，仍可能产生费用。不能把“有缓存”解释为整条获客流程零模型成本。
+
+程序先去重、复用有效结果，并做明确规则筛选；模糊样本不因缺少关键词就直接全部排除。批量分析按对象标识返回结果，验证结构后才进入线索状态。
+
+### 6.4 模型由我们在后台配置
+
+模型供应商、具体型号和路由策略由产品运营方在管理后台维护。客户端调用稳定的业务分析接口，不硬编码某个 DeepSeek 或其他厂商的版本。商家按产品权益使用相应分析能力，默认无需自行选择模型或填写供应商密钥。
+
+后台分别配置基础文本判断、复杂文本复核、页面视觉定位与理解、维护者学习探索四类用途。它们可以使用不同模型；不要求采用最新或最强型号。较低成本模型满足样本质量要求时，可以作为默认，但不能仅凭版本较旧就推定价格低或任务效果足够。
+
+文本意图识别与 GUI 视觉操作分别校验能力。只支持文字的模型可以用于评论分析，但不能直接替代 Midscene 所需的视觉模型。Midscene 的模型系列适配配置也需要匹配，不能仅修改模型名称就假定可用。依据 [Midscene 模型选择](https://midscenejs.com/model-selection)和 [模型配置](https://midscenejs.com/model-common-config)。
+
+配置至少包括供应商与实际 model ID、接口协议、密钥引用、支持的输入类型与结构化输出能力、思考模式、输出上限、超时重试、价格有效期、用途预算和有限的备用策略。提高模型规格的回退受用途与预算限制，不能在后台不设上限地升级。
+
+新配置先做连通、结果结构、真实样本质量与成本验证，再发布配置版本。运行任务保存配置快照，切换默认模型不会让正在运行的同一批分析无记录地混用；供应商停用时暂停或使用已配置的兼容备用路径。若供应商只提供动态别名，记录可获得的实际版本或响应标识，不承诺可以继续调用已下线的旧模型。
+
+更换已经适配的模型通常由后台配置完成；新增协议、视觉模型系列或客户端不支持的能力时，仍可能需要适配代码和客户端升级。
+
+## 7. 线索与跟进
+
+线索最少保存平台与对象标识、来源链接、发现时间、原始需求依据、判断结果和跟进状态。同一账号的多条相关评论可以归并，但保留各自来源。
+
+优先采用稳定的平台对象标识；无法可靠确认身份时保留为待判断，不能仅凭相同昵称自动认定同一人。内容去重、客户去重和跟进动作去重分别处理。
+
+关注、消息准备、消息发送、结果核对和回复读取分别实现。消息内容可来自商家模板或可选生成，保存实际使用的版本。自动跟进保留为最终业务链路的一部分。
+
+跟进动作有 prepared、executing、confirmed、failed、uncertain 等状态。执行前记录目标和业务操作标识；程序崩溃、页面超时或网络中断后，先核对实际状态。
+
+本地操作标识和记录可以减少重复执行，但第三方平台动作不能只靠本地去重就保证恰好执行一次。消息发送等结果不明时进入待核对，不能把未知结果直接当失败重试。
+
+动作去重跨任务生效，至少结合平台、执行账号、可靠的目标标识、动作类型和业务跟进轮次。同一业务动作不能因为重建任务或更换模板就自动重做；新的跟进轮次需作为明确的业务设置。
+
+## 8. 任务编排与恢复
+
+任务包含商品条件版本、平台账号、入口与关键词、处理范围、能力包版本、模型配置版本与快照、分析预算和跟进设置。第一版一个账号内串行执行，后续再评估不同账号的并行。
+
+任务状态包括待运行、运行中、暂停中、已暂停、等待登录、等待处理、等待额度、完成、失败和取消。
+
+检查点保存已确认完成的对象、剩余队列、当前步骤和必要页面状态。恢复时重新打开或核验页面，不能直接沿用之前的第 N 条可见位置。任务范围以本轮实际发现的内容为准，不承诺无限滚动列表能被完整枚举。
+
+暂停在可确认的步骤边界生效。紧急停止、断电或关闭程序可能留下结果不明的动作，恢复后仍按动作账目核对。人工接管后，运行端重新检查账号、页面和当前对象。
+
+关闭主窗口与退出程序分别定义，Windows 托盘和 macOS 菜单栏、Dock 行为通过系统适配处理，界面明确显示任务是否仍在运行。退出程序会停止本地执行；本地任务不会在电脑休眠或关机后继续。两端分别验证恢复唤醒后的浏览器与账号核验。断网或云端不可用时停止开启新的分析和依赖分析的后续动作，保留检查点及未决请求，恢复后对账再继续。
+
+任务固定使用创建时的能力包版本；运行中的任务不热切换脚本。发布记录至少包含版本、校验信息和兼容范围，升级或回滚后从支持的检查点继续；不兼容时明确暂停。
+
+## 9. 商业模式与额度
+
+采用软件订阅、包内分析额度和超额加量包的组合。软件有效期和 AI 余额分别管理，不设置没有成本边界的模型无限使用承诺。
+
+商家看到基础文本分析、深度分析和视觉分析等清楚的计量项；服务端记录实际供应商、模型、输入输出 Token、视觉用量、请求标识和费用。供应商成本与商家额度分账记录，任务和请求标识关联两者；商家消耗的分析额度不直接等同于供应商 Token。按分析量收费与按有效线索收费是不同模式，首版建议先验证分析额度模式。
+
+一次请求按“预占额度、调用模型、保存结果与实际计量、结算或释放剩余预占”处理。客户端重试复用同一请求标识，已完成的请求返回已有结果，不重复扣费。
+
+供应商请求超时可能已经产生费用，需保留处理中或待核对状态，不能立即视为免费失败，也不能盲目再发一次。具体对账方式按供应商能力实现，充值和扣费通过服务端账本事务管理。
+
+初期定价沿用 v0.1 中的试售假设作为访谈材料，不在本轮把 199 元/月或三万条设成最终套餐。确定价格前测出实际消耗、维护工作量和商家持续付费意愿。
+
+## 10. 推荐的开发顺序
+
+### 阶段一：验证一个平台的基础能力
+
+围绕搜索、视频、主页和评论定义最小能力契约，采用一条明确的执行路径完成验证。需要时参考 A2A 与 browser_use 的实现经验，不设置先盘点或复用旧工程的前置步骤。
+
+以抖音建材作为候选，在 Windows 与 macOS 上分别验证浏览器登录、搜索、视频、主页、评论和回复是否可以正确处理；明确缺失或受限的功能。先做单账号，不先做完整会员后台。双端使用同一验收清单。
+
+阶段产物是可重复执行的链路、真实样本和失败记录。若关键网页版功能不足，先调整执行方式或首发平台，再投入完整产品建设。
+
+### 阶段二：完成发现与筛选
+
+实现商品档案、任务、三类判断、去重、来源回看和本地线索页面。准备带上下文的标注样本，对照人工结果，统计误判、漏判、耗时和费用。样本量和可接受标准在首轮样本后细化。
+
+### 阶段三：完成学习资产与恢复
+
+把链路整理成统一能力包，建立验证、版本发布和回滚。验证重启、登录失效、页面变化、人工接管、列表变化和预算耗尽后的行为。
+
+### 阶段四：接入跟进闭环
+
+分别验证关注、会话准备、消息发送、结果核对和回复记录。覆盖已关注、重复候选、发送前中断和发送结果不明等情况，再确定首版开放范围。
+
+### 阶段五：形成可收费的安装版
+
+完善双平台安装包、任务进程退出、客户端升级、产品登录、设备权益、订单、后台模型配置、额度网关和账本。模型配置逻辑在前面的分析验证中先以开发配置使用，此阶段补齐管理界面、验证发布和回退。分别在已确认的 Windows 与 macOS 系统版本、架构目标环境验证，按同一业务范围发布。用一批有限任务核对供应商用量、服务端扣费和客户端展示是否一致。
+
+### 阶段六：扩展覆盖
+
+单平台流程和商业用量稳定后，依次增加推荐流、多账号并行、小红书与快手、可选线索同步和手机查看。每增加一个平台都新增适配与验证，不把它描述为自动通用。
+
+## 11. 首轮验收要回答的问题
+
+- 每类页面是否真的能完成操作和读取，读出的对象、文本与来源是否对应。
+- 同行评论和需求作者两条业务路径能否分别形成可回看的线索。
+- 内容、角色和意图判断各自有哪些误判、漏判和信息不足的样本。
+- 每千条分析、每批任务和每条人工确认线索的模型费用与总耗时是多少。
+- 登录失效、页面变化、崩溃、额度耗尽和人工接管后，是否能继续或明确停止。
+- 跟进结果能否核对，重复对象和不确定结果会怎样处理。
+- 客户端、服务端和供应商用量是否能对账，重试是否导致重复扣费。
+- 安装到已确认的 Windows 与 macOS 系统版本、架构的干净目标环境后，浏览器、原生依赖、执行进程、升级和数据保留是否正常。
+- 相同功能在 Windows 与 macOS 是否均通过，窗口关闭、完整退出、快捷键和休眠恢复是否符合各端定义。
+
+这些是建议验收方向。目前没有实测结果，也没有确定准确率、日处理量或交付周期。
+
+## 12. 建议的后续工程结构
+
+以下为后续组织方式，当前尚未创建这些应用和包：
+
+```text
+apps/desktop/          商家桌面界面与主进程
+apps/server/           产品账号、AI 网关、权益、订单、计量和发布 API
+apps/admin/            订单、用量、版本与运营管理
+tools/learning/        维护者的学习、调试和验证入口
+packages/contracts/   任务、能力包、线索、错误和模型结果定义
+packages/runner/      编排、检查点、动作记录和预算
+packages/browser/     浏览器生命周期与账号会话
+packages/platforms/   各平台的链路实现
+packages/ai/          文本与视觉分析客户端
+packages/storage/     本地数据访问与迁移
+capabilities/          已验证能力包的清单与版本资产
+docs/                  方案与运行说明
+```
+
+初期可以保留较少实际包，先明确边界再按代码规模拆分。首轮只需要基础浏览器验证、执行器和最小桌面界面；后台在商业闭环阶段完善。
+
+## 13. 本轮建议与仍需验证的选择
+
+### 13.1 已确认的范围与原则
+
+- 首版同时适配 Windows 和 macOS，桌面框架采用 Electron。
+- 保留搜索与推荐流入口，以及同行评论、作者本人有需求两条业务路径。
+- 沿用先学习、固化链路、再重复执行的思路，控制运行时的模型调用。
+- 模型由我们在运营后台按用途配置，不绑定某个厂商版本，也不要求默认使用最强模型。
+- A2A 与 browser_use 仅作为参考，不设优先复用要求，实现选择以当前产品需求为准。
+
+### 13.2 当前实施建议
+
+以 Playwright 固定执行为主线，围绕当前产品设计轻量执行器；Midscene 保持可选，按实际步骤需求比较。维护者负责能力包学习、验证和发布，云端负责模型网关与用量计量。A2A 与 browser_use 的设计和实现可按需参考。
+
+React + TypeScript、SQLite、Node.js/TypeScript 执行器与服务端、PostgreSQL 是推荐组合。具体组件依据功能适配、运行表现和双平台分发维护成本决定，不预设旧代码保留或迁移目标。
+
+### 13.3 仍需验证的选择
+
+首发内容平台、具体 model ID 与预算、完整跟进范围、套餐、并行规模、Midscene 是否引入，以及是否采用其他外部组件，仍由实验结果决定。Windows/macOS 最低系统版本和架构覆盖在依赖与打包验证后明确。实现应优先回答当前业务能否闭环，再扩展通用能力。
+
+外部项目能力依据官方资料核对于 2026 年 10 月 21 日。本文中的整体组合和模块边界是本项目的设计建议，不是外部项目已经提供的整套获客产品。