338 lines
28 KiB
Markdown
338 lines
28 KiB
Markdown
# 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 日。本文中的整体组合和模块边界是本项目的设计建议，不是外部项目已经提供的整套获客产品。
|