月入百万的电商全流程（北大研发）是如何搭建的（完全开源）

引言：一个人做电商，如何不被重复动作拖垮？作者把跨境电商从找客户、筛线索、做调研、生成触达、跟进报价到订单复购的完整链路拆开重接，用 Codex 和多个 Worker 把每个环节变成有状态、可记录、可复盘的系统。这篇超长文覆盖业务架构、数据表设计、AI 成本核算、Prompt 版本管理、风控红线、六周最小闭环搭建计划和每天的自动运行节奏，是一份可以直接照着施工的完整图纸。

很多人以为，月入百万靠的是一个爆款、一个广告投放技巧，或者某个特别厉害的 AI Prompt。

我现在越来越确定，真正决定上限的，是你有没有把整个电商业务做成一台能持续运转的机器。

这篇文章我不讲“AI 很有潜力”这种正确但没用的话。我直接把我正在搭的产品和系统摊开：它怎么找客户，怎么管 AI 项目，怎么计算成本，怎么监控异常，怎么处理询盘，怎么报价，怎么把订单和复购接回来。

先给你看这套系统真正运行起来以后是什么样子。

早上 7 点，采集任务自动拉取新的需求信号；8 点，系统把重复公司合并，把无效网址剔掉；9 点，高优先级客户开始做信息补全；10 点，已经通过审核的线索生成触达草稿；下午，到了时间的客户自动进入跟进队列；晚上，系统把询盘、报价、订单、退款、库存和失败任务汇总成一份报告。

我打开电脑以后，不是从零开始干活，而是先看这份报告：今天有哪些机会值得我亲自判断，哪个客户已经接近成交，哪一个订单可能影响交付，昨天哪条规则导致了异常。

这不是一个展示效果的 Demo，而是一套每天自己寻找机会、自己推进任务、自己留下记录、遇到不确定性才把我叫过来的电商系统。

月入百万不是让 AI 一晚上写出一万个商品标题，也不是搭一个漂亮网站以后等订单自己进来。它是一笔订单从第一次出现需求，到有人咨询、报价、付款、交付，最后愿意再次购买，中间所有动作都被接起来，而且每个动作都能被记录、复用和放大。

我最近一直在做的，就是把这条链路拆开，再重新接起来，并且把每一个 AI 模块的运行情况放进同一个控制中心。

标题里的“月入百万”，是我按这个目标设计和放大的业务模型，不是把还没有发生的数字写成已经发生的成绩。已经验证的是，从找机会、筛客户、做调研、触达、跟进到复盘，这些环节确实可以由一个人搭起来并持续运行。

我把架构、数据字段、工作流、评分方法、报价逻辑和踩过的坑全部写出来。很多零件都很普通，真正费时间的是把它们放到正确的位置，并且让每一步都能接着下一步继续做。

如果你也在做独立站、外贸、跨境电商或者高客单价产品，这篇文章可以直接当成一张施工图看。你会看到的不是几个孤立功能，而是一套从 AI 调用管理，到客户获取，再到订单收入的完整产品体系。

但我真正想分享、也真正想让大家使用的，不只是这套方法，而是我把这套方法做成的产品：AI 跨境电商指挥中心。

这里要特别说明：下面提到的客户调研、SEO、客服、报价、订单分析、成本统计、预算提醒、Prompt 管理和异常监控，并不是文章里为了讲故事临时拼出来的功能。它们都是软件里的产品模块，可以单独使用，也可以组合起来，形成完整的跨境电商 AI 工作台。

你可以只接入一个客户调研项目，也可以把整个团队的 AI 项目全部接进来。每个模块负责一件明确的事情，指挥中心负责把它们统一连接、统一观察和统一管理。

它解决的是一个很现实的问题。

当你同时运行客户调研、SEO、翻译、客服、报价、订单分析和内容生成以后，AI 项目会越来越多。每个项目可能用了不同模型、不同 API、不同提示词和不同脚本。过一段时间，你会发现自己根本不知道钱花在哪里，哪个模型最贵，哪个任务最慢，哪一次调用失败了，哪个 Agent 正在偷偷重复执行。

你以为自己在经营一个电商业务，实际是在同时维护一堆互相看不见的 AI 黑盒。

我的产品就是把这些黑盒放进一个控制中心里。每个项目统一接入，成本、Token、延迟、错误率和调用次数统一记录；客户调研、SEO、客服和订单分析可以单独看，也可以放到一张总表里比较。

它不是让你再增加一个聊天窗口，而是让你知道整个 AI 电商团队到底在做什么、花了多少钱、哪里出问题、哪个环节值得继续投入。

软件里的产品模块，可以简单理解为：

AI 项目接入中心：把客户调研、SEO、客服、报价、订单分析等项目接入同一个入口。

AI 成本中心：按项目、模型、任务和时间查看 Token、调用次数和实际成本。

实时运行监控：查看每次调用的延迟、成功状态、错误率和最近运行情况。

预算与异常预警：给不同项目设置预算、错误率和延迟阈值，发现异常及时提醒。

Prompt 版本中心：保存不同版本的提示词，比较成本、速度、错误率和业务效果。

模型管理与路由：根据任务难度、成本和稳定性，选择适合的模型和调用路径。

跨境电商业务模块：覆盖客户发现、客户调研、内容生产、客服、报价、订单和复购。

权限与数据管理：控制项目访问范围、API Key 和运行数据，适合个人和团队使用。

产品定位：统一管理跨境电商里的所有 AI 项目

最开始我只是给自己的电商流程加几个 AI Worker。

一个 Worker 找客户，一个 Worker 做调研，一个 Worker 写内容，一个 Worker 处理客服，还有一个 Worker 负责数据分析。

刚开始项目少，还能靠记忆管理。后来模型和任务越来越多，我开始遇到一些很麻烦的问题：

客户调研项目到底用了多少 Token？

SEO 批量生成为什么这个月成本突然上涨？

哪个项目的延迟最高，正在拖慢客户回复？

某个供应商接口失败以后，系统重试了多少次？

同一个任务是不是被两个不同脚本重复调用？

为什么明明换了一个便宜模型，账单还是没有下降？

传统的做法是一个项目看一个日志，再去不同平台查账单。这个方法在项目少的时候还能接受，项目一多，判断成本比模型成本还高。

所以我做了一个统一的 AI 控制中心，把所有调用放到同一个入口。开发者只需要把项目指向这个入口，原来的模型调用方式基本不用重写，后台就能按项目、模型、任务和时间查看真实使用情况。

这对跨境电商特别重要，因为电商里的 AI 调用不是一个单一任务。

你可能每天要处理几百条商品信息翻译，几十个客户研究任务，几百次客服意图识别，少量高价值报价分析，还有一批内容和 SEO 任务。不同任务需要的模型能力不同，成本也完全不同。

把这些调用放在一起看，才知道哪个环节在创造收入，哪个环节只是在烧钱。

产品模块 1：AI 项目统一接入中心

我把一个跨境电商 AI 团队拆成了几个项目：

lead-research：找客户和补客户资料。

seo-content：关键词、页面、FAQ 和内容更新。

customer-support：客服分类、回复建议和售后判断。

quote-assistant：产品匹配、报价草稿和利润检查。

order-ops：订单、物流、退款和复购分析。

这些项目可以使用不同模型，也可以使用不同提示词版本。指挥中心会把每个项目的请求量、输入和输出 Token、估算成本、平均延迟、错误率和最近调用列出来。

我把每一个实际业务场景都当成一个独立项目管理。这样客户调研的成本不会和客服混在一起，SEO 的失败任务也不会被订单分析的日志淹没。每个项目既能单独看，也能回到总览里比较整个电商系统。

以前我只能说“最近 AI 用得比较多”，现在可以具体说：这个月客户调研花了多少，SEO 花了多少，客服每一条消息平均成本是多少，哪个项目的 p95 延迟最高，哪个模型的失败率正在上升。

这就从“我感觉 AI 很贵”变成了可以做经营决策的数据。

比如普通的翻译、分类、字段提取，不需要每次都调用最贵的模型；复杂的客户判断、报价分析和高价值回复，才值得使用更强的模型。系统能看清之后，模型选择就不再靠感觉。

产品模块 2：统一 AI 网关和项目接入

假设我有一个客户调研项目，原本代码里这样调用模型。现在不需要重写整个业务，只需要把请求统一指向指挥中心的项目入口。

项目本身继续负责业务逻辑：读取网页、整理公司信息、生成调研字段；指挥中心负责记录这次调用属于哪个项目，使用了哪个模型，消耗了多少 Token，花费多少，延迟多久，以及最终是否成功。

这样分工以后，业务代码不用到处加统计逻辑，也不需要每个 Worker 单独接一套监控。

客户调研、SEO 和客服可以分别统计，所有项目又能在一个总控制台里比较。

如果一天运行结束以后，我看到客户调研成本突然比昨天高了三倍，可以点进去看是哪一个模型、哪一批任务、哪个提示词版本造成的；如果客服项目错误率突然升高，可以直接定位到最近一次模型切换或接口异常。

这就是“控制中心”和“单独调用模型”的差别。

产品模块 3：AI 成本和 Token 统计中心

跨境电商里面最容易被忽略的一件事，是不同 AI 任务的商业价值完全不同。

一条商品描述翻译可能只影响页面效率；一个高价值客户的调研，可能直接影响一笔订单；一个报价分析如果判断错了，损失的就不是几分钱 Token，而是整个成交机会。

所以我不会只看总账单，而会按项目和业务动作算账。

我真正关心的是：一个合格客户的调研成本是多少，一条有效询盘的 AI 成本是多少，一份报价草稿最后有没有进入真实报价。只有把 AI 调用和业务动作连起来，成本数据才有经营价值。

客户研究项目每获得一个合格客户，平均花费多少？

SEO 项目每产生一个有效询盘，内容成本是多少？

客服项目每处理一百条消息，节省了多少人工时间？

报价项目每生成一份草稿，最终有多少进入真实报价？

订单分析项目的成本，和它帮助我发现的退款问题相比是否值得？

这些数字一旦能看见，AI 就从“工具费用”变成了“业务成本和业务产出”。我可以决定哪个项目扩大，哪个项目换模型，哪个项目直接关闭。

这也是我做这个产品的核心原因：让 AI 进入电商以后，不只是更聪明，也更可管理。

产品模块 4：实时调用监控和运行状态

很多平台只告诉你花了多少钱，但电商系统还需要关注速度和稳定性。

客户发来询盘以后，客服项目如果平均要等十几秒，回复体验就会变差；SEO 批处理如果偶尔失败，内容队列会越积越多；客户研究如果频繁超时，线索可能错过最佳触达时间。

所以我在指挥中心里同时看三类数据：成本、延迟、错误。

一个项目成本正常，但延迟越来越高，同样会影响成交；一个项目调用量不大，但错误率突然升高，也需要立即排查。指挥中心让我在问题影响客户之前看到它。

成本告诉我钱花在哪里，延迟告诉我业务有没有被拖慢，错误告诉我这个项目是否正在失去稳定性。

如果某个模型便宜，但错误率很高，最终可能比贵模型更浪费；如果某个模型很快，但输出经常需要人工返工，也不能只看每次调用价格。

真正应该比较的是：完成一次有效业务动作，需要多少成本、多少时间和多少人工修正。

产品模块 5：项目预算和异常预警

AI 项目最危险的情况，不是每天稳定花一点钱，而是某个循环出错以后开始无限调用。

可能是任务状态没有正确更新，可能是接口反复超时，可能是重试条件写错，也可能是某个 Agent 不断重复请求。

如果没有预算和提醒，等月底看账单，通常已经晚了。

所以我会给不同项目设置月度预算、错误率阈值和延迟阈值。客户调研超过预算以后提醒，SEO 项目出现异常增长以后提醒，客服错误率连续上升以后提醒。

预算不是为了把 AI 锁死，而是为了让每个项目在可控范围内放大。客户研究、SEO、客服和报价各自有预算，任何一个项目异常增长，都不会等到月底看账单才发现。

这不是为了限制 AI，而是为了让它在可控范围内扩张。

跨境业务经常有多个国家、多个店铺、多个团队和多个模型。没有项目级预算，所有成本混在一起，最后根本无法知道哪条业务线值得投入。

产品模块 6：Prompt 版本管理和效果对比

很多人改提示词以后，只看结果有没有变好，却不知道成本和延迟有没有一起变差。

我会把提示词和项目、模型、时间、成本、延迟以及最终结果绑定起来。这样一次 Prompt 修改以后，能看出它到底提高了有效字段完整度，还是只是让输出变长了。

我现在会给提示词设置版本号。

客户调研 v1 可能只要求输出公司名称、产品和联系人；v2 增加了需求证据和风险判断；v3 又增加了竞争对手分析。

版本变化以后，我可以比较同一项目的成本、延迟、错误率和最终业务结果。如果 v3 让输出更完整，但成本翻倍、人工修改变多，就不能只因为它“看起来更聪明”就继续使用。

对电商来说，提示词不是一次性文案，它会影响每天成百上千次任务。每次修改都应该像改价格和改流程一样留下记录。

这也是产品里我很重视的一部分：让提示词迭代从凭感觉，变成可以比较的实验。

产品模块 7：自托管、权限和 API Key 安全

跨境电商的数据比较杂，客户资料、订单信息、供应商资料和业务提示词都不应该随便进入一个不透明的平台。

所以这个产品的设计方向是轻量、自托管、数据可控。它不要求你重写整个业务，也不要求先搭一个复杂数据库。项目可以通过统一入口接入，调用过程只记录必要的元数据，便于查看成本、Token、延迟和错误。

API Key 仍然由项目自己管理，业务代码和模型供应商之间多了一层可观察、可审计的控制中心。

对个人创业者和小团队来说，这个部署方式更现实。先在本地或自己的服务器跑起来，等项目数量增加，再考虑团队权限、项目隔离和更复杂的路由。

我不想把一个简单的成本和运行管理问题，做成需要专门运维团队才能使用的平台。能用一条命令启动，能快速接入，能马上看到项目数据，这才适合真正做业务的人。

产品价值：把 AI 调用变成可管理、可复盘的经营数据

仪表盘只是表面。

真正要卖的是一种能力：当你把 AI 接进电商以后，依然知道每一分钱花在哪里，每一个项目有没有在创造价值，每一次错误有没有影响客户，每一个模型选择是不是合理。

你可以把它用在客户调研，也可以用在 SEO、客服、商品翻译、广告素材、报价助手和订单分析。

所有 AI 项目都从各自的小黑盒，变成一个可以统一观察、统一比较、统一控制的业务系统。

这也是为什么我不把它定位成一个“AI 生成器”。生成器解决的是一次任务，指挥中心解决的是一家公司里几十个 AI 任务长期运行以后，如何管理、如何省钱、如何排错、如何扩张。

如果你现在只是偶尔问一次 AI，可能还感觉不到它的价值；但当你有五个、十个、二十个项目同时运行时，没有统一控制中心，问题会很快出现。

你会开始关心：哪个项目真的带来订单，哪个项目只是消耗 Token；哪个模型适合日常任务，哪个模型值得留给关键决策；哪一次异常正在拖累业务，哪一个提示词版本应该回滚。

这就是我的产品要解决的问题。

具体使用时，你可以把它当成自己的 AI 运营中控台：先接一个客户调研项目，看看调用成本；再接一个 SEO 项目，看看内容生产到底花了多少；最后把客服、报价和订单分析接进来，比较不同项目的成本、延迟和错误率。

当你能够清楚回答“哪个 AI 项目在给我带来业务，哪个项目只是在烧钱”，你才真正开始拥有一支可以被管理的数字团队。

我做的不是一个看起来很酷的 Demo，而是一个每天都要被真实业务使用的控制中心。

跨境电商的下一阶段，不是谁生成的内容最多，而是谁能把更多 AI 接进业务以后，依然看得清、算得明、跑得稳、扩得起来。

电商财务模型：先算清毛利、获客成本和复购

我以前也犯过一个很典型的错误：一上来就研究工具。

今天看一个 AI 写作工具，明天接一个自动化平台，后天又想做一个 CRM。工具越装越多，业务却没有明显变化。

后来我先把一笔订单的账算明白。

月销售额到底来自哪里？平均客单价是多少？毛利扣掉物流、平台费、支付费、广告费、售后和退款以后还剩多少？一个新客户最多能花多少钱去获取？从第一次接触到成交平均要几天？复购发生在什么时间？

这些问题没有答案，自动化越强，可能只是更快地亏钱。

我现在看的核心指标至少包括：平均订单金额、毛利率、贡献毛利、获客成本、有效询盘成本、报价转化率、成交率、退款率、交付周期、复购率和客户生命周期价值。

这里要特别区分毛利和真正能拿来继续投放的贡献毛利。比如一笔订单卖 1000 元，产品成本 500 元，看起来毛利有 500 元；如果再扣掉物流、支付手续费、广告和售后，能留下的钱可能完全是另一回事。

系统里每个产品都有一张产品卡，里面不只放标题和图片，还放采购成本、建议售价、最低可接受价格、毛利底线、交付时间、可供库存、供应商、替代方案、常见问题和不能承诺的内容。

这样客户问价格时，系统可以先生成一个合理范围，碰到低于毛利底线的报价，直接要求人工确认。以前这些信息散落在表格、聊天记录和脑子里，最容易在忙的时候出错。

月入百万也要先拆成算得清的数字。

如果平均订单金额是 5000 元，月销售额一百万对应 200 个订单；如果平均订单金额是 2 万元，对应 50 个订单。B2C 更依赖流量、点击和转化，B2B 更依赖有效询盘、报价质量、交付能力和复购。两种业务都能用自动化，但系统要优化的地方不一样。

我做这套系统时，先确定了产品适合的客户、能承受的获客成本，以及每个阶段真正要提高的数字，然后才开始写代码。

业务架构：先画清客户从线索到订单的路径

电商里最容易被忽略的工作，是把“感觉上的业务”写成明确步骤。

我拿一张纸，把客户从第一次出现到最终成交的过程画了一遍：他从哪里来，什么信号说明他可能有需求，谁判断他是不是合格客户，谁补充信息，谁联系他，多久联系一次，客户回复以后谁处理，什么情况算成交，什么情况要停止跟进。

只要有一步说不清楚，就不能直接自动化。因为程序最怕“看情况处理”，它需要知道什么输入会触发什么动作。

最后我把业务拆成几类对象：产品、公司、联系人、线索、机会、互动、任务、内容、订单、供应商和异常事件。

它们之间的关系也要固定下来。一个公司可以有多个联系人，一个联系人可以有多次互动，一条线索可以转成一个机会，一个机会可以有多次报价，但同一个联系人在同一天不能被重复触达。

这听起来像很基础的数据库设计，实际运行后特别重要。很多自动化事故并不是模型不聪明，而是系统不知道两条记录其实是同一个人，或者不知道一条任务已经完成过。

我现在常用的字段包括：lead_id、来源、首次发现时间、公司名、国家、网站、联系人、产品匹配度、需求证据、当前阶段、下一步动作、下次执行时间、最近一次互动、负责的 Worker 和最后错误。

其中最关键的是“证据”“当前阶段”和“下一步动作”。

没有证据，评分容易变成猜测；没有阶段，系统不知道该往哪走；没有下一步动作，记录就只是历史，不会产生结果。

产品模块 8：客户发现和商业机会采集

以前找客户的过程大概是这样：打开搜索引擎，搜几个关键词，看到一个网站就收藏，看到一条需求就复制到表格里。收藏夹越来越长，真正联系的人越来越少。

现在我把找机会分成四步：收集、整理、去重、判断。

收集的来源可以是搜索结果、行业目录、竞品网站变化、采购公告、社交平台讨论、产品评价、招聘信息和客户公开发布的需求。不是所有来源都要一次接入，先选几个能稳定产生信号的来源，跑通以后再扩展。

程序抓到原始内容后，先保存原文、网址、来源和时间，再做清洗。网址里的追踪参数要去掉，公司名称要统一，国家和行业要归一，明显重复的页面要合并。

我特意保留原始数据，没有让模型直接覆盖它。后面如果评分出了问题，我可以回到最初的证据重新检查；数据源改版时，也能判断到底是采集错了，还是判断规则需要调整。

每条机会进入系统之前，要回答几个问题：

这家公司到底卖什么？

它和我的产品有没有实际关系？

页面上有没有购买、扩张、上新、招供应商或者解决某个具体问题的信号？

这个信号是什么时候出现的？

能不能找到可以继续沟通的人？

如果这些问题都答不上来，线索就不会直接进入开发队列。

系统输出的也不是一段漂亮介绍，而是一条结构化记录。例如：某国某行业经销商，主营产品与我的产品匹配，最近更新了相关品类页面，公开邮箱可用，需求证据来自某个页面，建议先联系采购或业务负责人，当前评分 78，下一步做客户调研。

这个分数不代表客户一定会买。它只是在告诉我，今天先看谁。

产品模块 9：客户评分和成交结果校准

最开始我让 AI 自己判断“这个客户值不值得跟”，结果每次标准都不一样。上午觉得网站漂亮就是高价值，下午又觉得公司规模大才重要。

后来我给评分写了固定维度。

需求信号占一部分，产品匹配占一部分，联系人可触达程度占一部分，市场和订单潜力占一部分，时间紧迫度占一部分。出现明显不匹配、无效联系方式、退订记录或者高风险内容，再做扣分。

我不会把评分规则写死。每周会把“高分但没有回复”“低分却成交”“回复很好但最终没成交”的记录挑出来，看看是哪一项判断失真。

比如某类公司网站很完整，评分很高，但实际没有采购权限；另一类小公司看起来规模不大，却有明确的项目需求，成交率反而更高。规则必须根据结果调整，不然它只是一个看起来很科学的标签。

我通常会把线索分成三段处理：高分线索进入调研和触达，中间分数先补信息或观察，低分线索归档。阈值不是行业标准，取决于我的人工时间和产品客单价。

对低客单价产品，系统可以承受更多自动筛选；对高客单价产品，宁愿少联系一些，也要把每条线索研究清楚。

还有一点很重要：评分和排序要分开。评分反映潜在价值，排序还要考虑当前是否到联系时间、是否有未处理回复、是否距离上一次互动太近。一个高分但刚刚联系过的客户，不应该挤掉一个中高分但今天正好到了跟进时间的客户。

产品模块 10：客户调研和销售作战卡

公司名和网址远远不够。真正开始联系之前，我会让系统把线索补成一张作战卡。

这张卡至少包含：公司做什么，服务哪些市场，产品和客户是谁，可能的采购角色，最近发生了什么变化，我能提供什么帮助，第一句话应该提什么，哪些内容暂时不能提。

我要求调研结果把“确定事实”和“推测”分开。网页明确写过的，标成已确认；根据页面推断的，标成推测；找不到的，写未知。这个习惯看起来保守，却能避免很多尴尬。

AI 很容易把“可能是经销商”写成“这家公司正在寻找经销商”，把“页面上有某类产品”写成“他们近期准备采购”。开发信一旦把推测当事实，客户看到就知道你根本没认真看。

我会让调研 Worker 输出固定字段，并且附上来源。来源不完整的记录不能进入自动触达队列，只能进入人工复核。

在 B2B 电商里，还要看采购链条。真正决定订单的人可能不是网站上显示的联系人。一个项目可能有使用部门、技术评估、采购、老板和财务多个角色。系统可以先识别可能的角色，再决定第一步从谁开始，而不是默认找到一个邮箱就发同一封邮件。

客户资格也可以借鉴 BANT 这类思路：有没有明确需求，有没有预算范围，谁能做决定，时间上有没有计划。但我不会让模型生搬硬套缩写，而是把它翻译成几个能回答的问题，放进作战卡里。

产品模块 11：客户触达、回复识别和自动跟进

很多人说自己做过自动开发，实际只是让 AI 生成了一封邮件，然后手动发出去。

真正难的是后面。

一个客户进入系统后，会经历一组状态：新线索、调研中、待审核、待触达、等待回复、已回复、报价中、成交、暂不合适、停止联系。每一次状态变化，都应该产生下一步任务或明确结束原因。

首封消息只解决一个问题：为什么联系你。它要引用真实观察，说明可能相关的场景，再给一个低门槛的下一步。不要一上来把产品目录、公司历史和十几个附件全部塞过去。

后续跟进也不能只是把“想问问有没有兴趣”换一种说法。第二次可以补一个相关案例或规格信息，第三次可以给出一个更具体的选择，最后一次明确告诉对方暂时不需要回复也没关系。

我的队列会记录计划日期，例如首触、几天后的跟进、再下一次跟进和一个月后的重新激活。具体间隔会根据市场、时区和客户类型调整。

只要客户回复，自动流程就暂停。系统先把回复分类：感兴趣、需要报价、要求补资料、暂时没需求、明确拒绝、退订、无关回复、无法判断。前几类可以生成下一步建议，拒绝和退订直接停止，无法判断的交给我。

我还会把已成交客户从开发流程里移出来，进入交付和复购流程。否则系统可能一边给已下单客户发开发信，一边又把他当成新客户重新评分，这是非常低级但很常见的错误。

自动触达必须有边界。发送频率、时间窗口、退订机制、无效地址处理和人工审核都要写进系统。自动化的价值是让该跟进的客户不会被遗忘，不能把打扰客户的速度提高。

产品模块 12：询盘识别、报价和订单流转

获客只是前半段。很多电商把流量做起来了，订单还是上不去，问题往往出在询盘处理。

客户发来一句“多少钱”，不能只回复一个价格。系统需要先判断他问的是哪个产品、哪个规格、什么数量、哪个国家、什么交付时间。如果信息不完整，就生成一组最少的问题，让客户容易回答。

我给询盘设置了响应时限。高价值询盘优先进入人工队列，普通询盘可以先由系统发送确认信息和必要资料，但涉及定制价格、交期承诺、折扣、认证或售后责任的内容，必须由人确认。

报价单也不能每次从零开始做。产品卡里会保存不同数量区间、币种、贸易条款、物流方式、付款方式和有效期。系统根据客户国家、数量和交付要求生成报价草稿，我审核关键数字以后再发出去。

对于 B2B，报价之后的跟进比报价本身更重要。系统要知道客户目前是在比较供应商、内部审批、等待预算，还是已经失去兴趣。不同阶段的内容不同，不能每隔几天只问一句“考虑得怎么样了”。

对于 B2C，重点又不同。要看加购、结账、支付失败、物流查询、退款和评价。自动化可以在支付失败后提醒，在包裹签收后邀请评价，在合适时间推荐补充产品，但不能对退款中的客户继续推销。

我把这两类流程分开设计，底层共用客户、订单和任务数据，上层动作按业务类型变化。

产品模块 13：产品页优化和询盘转化

SEO 带来访问以后，页面能不能完成转化，取决于它有没有回答客户真正担心的问题。

我会把产品页拆成几块去检查：它适合谁，不适合谁，解决什么问题，和替代方案相比有什么差别，规格和限制是什么，交付多久，怎么买，出了问题怎么处理。

很多页面只写“高品质、专业、值得信赖”，这些词几乎没有决策价值。客户更关心的是尺寸、兼容性、交期、最低起订量、售后边界和真实使用场景。

我会把客户聊天里反复出现的问题整理成 FAQ，再回填到产品页。一个问题被问过三次，就说明页面可能没有讲清楚；一个问题每次都导致客户流失，更应该优先处理。

图片和视频也要服务于判断。产品细节、包装、安装方式、使用前后对比、实际尺寸和交付过程，往往比一张过度修饰的主图更能减少犹豫。

系统可以帮助我从聊天、评价和竞品页面里提取问题，再按照产品和场景归类。但最终的产品承诺必须以真实能力为准，不能为了提高转化写出交付不了的内容。

产品模块 14：SEO 关键词、内容和页面管理

我不把 SEO 理解成“每周发几篇文章”。它更像一个长期维护的商品目录和问题答案库。

系统每天会收集新的搜索词、客户提问、站内搜索、竞品页面变化和已有页面的数据。每个 Query 都先判断搜索意图：用户是在找产品、找供应商、看对比、解决故障，还是只想了解概念。

再看它有没有商业价值。一个词访问量很大，但和产品无关，做出来也可能只是增加服务器流量；一个词搜索量不大，却接近采购，反而值得优先处理。

我的内容队列里会记录 Query、意图、目标国家、对应产品、已有 URL、竞争页面、内容缺口、建议标题、内链位置、当前状态和上线后的询盘结果。

没有页面的词，先生成内容简报；已有页面的词，先看是排名问题、内容问题还是转化问题。不同问题不能用同一种“再写 1000 字”来解决。

Codex 可以根据简报生成页面初稿、标题、FAQ、结构化信息和内链建议。页面进入发布前，我会检查产品参数、价格、法规、交付承诺和案例真实性。

页面上线以后，系统会在固定周期检查点击率、停留、跳出、产品页点击、询盘和成交。标题点击高但询盘低，可能是承诺和内容不一致；访问不低但产品页点击少，可能是页面没有给出下一步；排名下降，则要查内容是否过时、竞争是否变化。

GEO 也按这个逻辑做。重点是把用户会问的问题回答完整，给出清晰定义、使用场景、限制和可验证信息。批量生成没有事实支撑的文章，只会让内容库越来越臃肿。

产品模块 15：供应链、库存、补货和售后

以前我把注意力都放在获客上，后来发现一个很现实的问题：客户来了，产品没货；产品有货，交期不稳定；订单成交，利润被物流和售后吃掉。

所以现在产品卡会关联供应商和库存信息。每个供应商有交付周期、起订量、价格区间、质量记录、最近一次采购、替代供应商和风险等级。

库存不能只看“还有多少件”，还要看可售库存、已锁定库存、在途库存、损耗、周转天数和补货时间。系统可以根据过去一段时间的销量和交付周期生成补货提醒，但不会在没有人工确认时自动下大额采购单。

对于多 SKU 产品，要先区分引流款、利润款、形象款和复购款。不同 SKU 的广告、页面位置和推荐逻辑不一样。一个看起来销量很高的产品，可能只是引流，真正贡献利润的是后面的配件、服务或复购。

我会把退款原因和差评原因回写到产品和内容里。尺码问题多，就改页面说明；安装失败多，就补视频；运输破损多，就改包装或物流方案。售后不是订单结束后的独立部门，它会反过来影响选品、页面和广告。

这也是为什么我说电商自动化不能只做前端获客。前面跑得越快，后端越容易暴露问题。

产品模块 16：Codex 工作流维护和版本管理

我现在使用 Codex 的方式，已经和最开始完全不同。

最开始我会说：“帮我做一个电商自动化系统。”这个指令太大，最后得到的东西很难真正接进业务。

现在我会把任务拆小，给它现有代码、数据结构、日志和验收条件。

比如我会让它检查昨天失败的采集任务：先按错误类型分组，网络超时最多重试三次，字段缺失不要猜，标记为待复核；不要修改表结构；先给出会影响哪些流程的说明；修复后用历史数据干跑，确认不会生成重复线索。

这类任务不花哨，却能直接解决每天遇到的问题。

我会要求它先读项目结构和相关日志，再动代码；改完以后给出差异；能用小样本验证，就不要直接对全量数据执行。涉及发送、删除、付款、改价格和批量发布的动作，默认停在审核点。

项目里我会把不同 Worker 分开放，每个 Worker 都有自己的输入、输出和错误处理。比如：

采集 Worker 只负责拿原始信息；

清洗 Worker 负责统一字段和去重；

调研 Worker 负责补充公司和联系人信息；

评分 Worker 负责排序；

触达 Worker 负责生成草稿和安排任务；

跟进 Worker 负责检查到期动作；

内容 Worker 负责 SEO 队列；

报表 Worker 负责把结果汇总出来。

它们之间通过明确的数据字段交接，不靠一个超级 Agent 记住所有事情。

架构原则：多个 Worker 协作，替代一个万能 Agent

一个 Agent 负责整个电商，听起来很省事，实际很难稳定。

流程一长，前面做出的判断可能在后面丢掉；某一步接口失败，它可能继续往下编；任务跑了很久，最后只留下一句“执行遇到问题”。出错时你也不知道应该从哪里重来。

拆成小 Worker 以后，系统反而更容易维护。

采集错了，只重跑采集；评分规则改了，只重算评分；邮件模板更新了，只对还没有发送的任务生效；某个页面需要回滚，也不会影响客户订单。

每个 Worker 都要有清楚的“完成条件”。采集任务不是“模型说完成了”，而是原始页面已保存、字段数量达到要求、重复率在范围内、错误已记录。评分任务不是“给了一个分数”，而是分数有理由、来源能追溯、低置信度被标记。

把智能放在需要判断的地方，把确定性写进代码里，系统才能既有弹性又不至于失控。

产品模块 17：定时调度和任务队列

脚本在我的电脑上成功运行一次，不能叫自动化。真正的自动化要有调度、队列、权限和结果通知。

我现在会给每类任务设定运行窗口。早上收集和清洗前一天的新数据，上午处理高优先级线索的调研，中午更新内容和产品信息，下午执行到期跟进，晚上汇总订单、询盘和异常。

客户所在国家不同，发送时间也不同；有些任务必须等人工审核，有些任务可以直接执行；有些任务失败后可以重试，有些任务必须暂停。调度器要理解这些条件，不能只看一个时间点。

每个任务进入队列时，会带上优先级、最早执行时间、最大重试次数、所需权限和幂等键。系统只领取符合条件的任务，执行完以后写回状态和结果。

我每天收到的报告不会塞一堆技术日志，而是告诉我：新增了多少有效线索，哪个来源质量最好，哪些客户回复了，哪些订单卡住了，哪些页面有有效动作，哪几个任务需要我确认。

技术日志留给排错，经营报告留给决策。两者混在一起，最后谁都看不懂。

产品模块 18：失败重试、幂等执行和异常恢复

正常流程很容易演示。真正让人崩溃的是网页改版、接口超时、授权过期、字段突然为空、任务跑到一半断掉，以及同一个动作被执行两次。

我给任务设计了几种明确状态：待处理、执行中、成功、失败、等待、需要复核。任务失败不能静默消失，执行中也不能无限卡住。

网络短暂超时，可以自动重试；数据结构变化，要进入待复核；发送动作已经成功但回执丢失，要先查记录，不能直接再发一次；连续失败的任务进入隔离队列，避免拖慢其他流程。

幂等机制是我后来最重视的部分之一。简单说，同一个客户、同一种动作、同一个计划日期，只允许成功执行一次。调度器重启、程序重复触发，都不能导致重复发送或重复扣库存。

限流也要提前设置。抓取、API 调用、邮件发送和批量更新都有速度上限。队列积压时可以延后，不要为了追求当天清空，把数据源、账号和客户关系一起用坏。

系统还要留日志：什么时候开始，输入是什么，调用了什么，返回了什么，哪一步失败，重试了几次，最后由谁处理。没有日志的自动化，出了问题只能靠猜。

产品模块 19：权限、数据隐私和合规控制

电商系统会接触客户资料、订单、支付和供应链信息，权限不能全部交给每个 Agent。

我会把读取、写入、发送、付款、删除和发布分开。普通 Worker 可以读取完成任务所需的字段，但不能随意导出全部客户资料；可以生成邮件草稿，但不能直接发送高风险内容；可以提出补货建议，但不能直接提交大额采购。

涉及隐私和客户通信的地方，要遵守业务所在国家和平台的规则。退订、删除请求、数据保存期限和访问权限，都要有明确处理路径。

这不是为了让系统变慢，恰恰是为了让它能长期跑。一个因为违规被封掉的获客渠道，前面所有自动化都等于白做。

产品模块 20：极简后台、人工审核和高风险接管

以前我总想做一个特别大的后台，客户列表、各种图表、十几个筛选器和一堆按钮。

后来我发现，真正每天需要看的东西很少：今天哪些机会值得处理，哪些客户有回复，哪些订单需要介入，哪些任务失败，哪些指标突然变差。

所以现在后台主要有三个入口：待我确认、异常任务、经营数据。普通任务自己跑，只有不确定和高风险的事情才把我叫过来。

好的页面不是让人重新操作一遍机器已经完成的工作，而是让人快速理解上下文，然后做决定或接管。

我甚至会主动删除没人使用的页面。每多一个按钮，就多一种误操作可能；每多一个人工步骤，就多一个系统无法真正替代的环节。

数据复盘：从流量、询盘、报价到成交和复购

营业额是结果，系统要看的还有过程。

每周我会把数据按来源、国家、产品、客户类型和触达方式拆开。看哪些来源带来的线索最多，哪些来源带来的成交最好；哪些客户回复率高但客单价低；哪些产品询盘很多却总在报价后流失。

还要看漏斗每一段的损耗：发现到合格、合格到触达、触达到回复、回复到报价、报价到成交、成交到复购。

如果发现线索很多但合格率低，先改采集和评分；如果合格率不错但回复少，检查触达角度和联系人；如果回复很多但成交少，检查报价、产品匹配和交付承诺；如果成交不错但利润低，回到成本和定价。

我会给每次规则调整留一个版本号，记录改了什么、为什么改、观察哪个指标。一次只改一个主要变量，过一段时间再判断。否则所有东西一起变，最后无法知道到底是哪一步起了作用。

这也是 Codex 很适合参与的地方：它可以帮我整理日志、找异常样本、生成对比报告、修改规则和补测试，但最后的经营判断仍然由我来做。

月入百万模型：把收入拆成可优化的增长变量

把目标拆开以后，月入百万不再是一个神秘数字。

第一个杠杆是有效机会数量。系统能不能每天持续找到新的、和产品有关的需求信号？

第二个杠杆是有效触达率。找到的人里，有多少真的联系到了正确角色？

第三个杠杆是对话和报价质量。客户回复以后，能不能快速理解需求、给出合适的方案，而不是把一份通用目录扔过去？

第四个杠杆是成交率和客单价。产品组合、报价方式、交付能力和信任证明，都会影响这一段。

第五个杠杆是复购。一次订单赚到的钱，和一个客户在一年里持续产生的价值，完全不是同一个数字。

自动化主要放大前面的执行密度，也会帮助后面的服务更稳定。它不能把没有利润的产品变成好生意，也不能解决供应链本身的问题。

所以我把系统目标设成了几个能每天观察的数字，而不是只盯着月收入：有效线索数、合格率、首触完成率、有效回复率、报价率、成交率、平均订单金额、贡献毛利和复购率。

只要知道哪一段是瓶颈，就知道下一周该改什么。

从零搭建计划：六周跑通最小可用闭环

第一周只做一件事：选一个产品和一类客户，把订单流程写清楚。先记录真实动作，不急着自动化。

第二周搭最小数据库，至少能保存产品、公司、联系人、线索、互动、任务和订单。字段宁愿少一点，也要保证每条记录有来源和下一步。

第三周接一个稳定的数据源，跑通收集、清洗、去重和评分。先用小批量历史数据测试，不要一上来抓全网。

第四周做客户调研和触达草稿，保留人工审核。先确认系统能持续产出可用草稿，再考虑自动排队。

第五周接入跟进状态机、回复分类和停止条件。让客户回复、退订和无效地址都能正确改变状态。

第六周再做 SEO 内容队列和页面更新。先把已有页面的数据接进来，知道哪些内容真的带来询盘，再扩展新词。

最后才是调度、报表、重试和更复杂的 Worker。顺序反过来，很容易花大量时间做出一个看起来完整、实际没人用的系统。

我自己的经验是，先让一条小链路每天稳定跑，再往旁边扩。一个稳定的收集到触达流程，比十个没有日志的 Agent 更有价值。

经营结果：把人的时间留给高价值决策

以前，人就是系统。

我勤快的时候，线索有人看，客户有人跟，页面有人更新；我出差或者累了，业务就停在那里。很多机会不是没有出现，只是没有人在正确的时间处理它。

现在程序负责重复动作，我把时间留给三件事：判断做什么产品和市场，处理真正重要的客户和订单，解决系统以前没有遇到的问题。

这并不代表以后可以完全不管。选择赛道、理解客户、定价、建立信任、判断风险，这些事情仍然需要人。变化在于，我不必亲自完成每个中间动作，才能让自己的判断落地。

数据库、定时任务、API、浏览器自动化、几组 Worker，再加上 Codex，单独看都很普通。把它们接成一个有状态、有记录、能恢复的业务系统以后，才开始产生杠杆。

标题里的“完全开源”，我想开的不只是几个文件，也包括这套系统为什么这么设计、哪些字段必须有、哪些地方不能交给模型、怎样判断一次自动化到底有没有带来收入。

如果这篇内容有人看，我会继续把实际结构公开出来：产品表、线索表、任务表、评分提示词、客户状态机、SEO 队列、异常日志，以及每个 Worker 的输入和输出。

我更愿意把它写成一份可以被别人拿去改的施工记录，而不是一篇只负责让人兴奋五分钟的成功故事。

一个人加几套工具，当然不会凭空变成月入百万。

但一个人如果能把获客、销售、交付和复购拆成清楚的动作，再用 Codex 把这些动作接成每天自动运行的系统，过去需要一个小团队才能完成的执行密度，现在确实可以被压缩到一个人的手里。

这就是我正在做的事情：先把业务跑通，再把每一个能量化的环节做成队列、状态和反馈，最后让系统自己把有效动作重复起来。

月入百万只是我要验证的规模，真正值得研究的是，这台机器还能被推到哪里。

实操拆解：一条线索从采集到订单的完整路径

很多人看到“自动化系统”这几个字，会以为需要先买一堆工具、招一个技术团队，再花几个月搭一个很大的平台。

我自己的做法刚好相反：先建最小版本，先让一条业务链跑起来，再逐步加东西。

我通常会把项目拆成几个目录：

collectors 负责采集，normalizers 负责清洗，scorers 负责评分，researchers 负责补全客户信息，outreach 负责生成和排队触达内容，content 负责 SEO 队列，reports 负责日报和周报，workers 负责定时执行，incidents 负责失败任务。

每个模块只做一件事。这样 Codex 接手的时候，不需要先理解一团混在一起的代码，也不会为了修一个采集问题，把报价和订单流程一起改掉。

数据库也不需要一开始做得很复杂。最小版本至少有这些表：

products：产品、成本、售价、毛利底线、库存、交付周期、供应商。

leads：来源、公司、国家、网站、联系人、需求证据、评分、当前状态。

interactions：什么时候联系、用了什么内容、客户怎么回复、人工标记的结果。

tasks：任务类型、优先级、计划执行时间、重试次数、状态、错误信息。

orders：客户、产品、金额、成本、付款状态、交付状态、售后状态。

content_queue：关键词、搜索意图、目标页面、内容缺口、审核状态、上线后的数据。

runs：每一次 Worker 执行了什么、处理了多少条、成功多少条、失败多少条。

最开始我不会做复杂的客户画像系统，也不会做几十个后台页面。先保证一条线索进来以后，能够留下来源，被评分，生成下一步任务，并且知道最后有没有成交。

数据结构：一条线索在系统里到底长什么样

我给大家举一个脱敏后的结构例子。假设系统从一个行业网站里发现了一家公司，记录不会只有公司名和网址，而是类似这样：

公司：某国某品类经销商

来源：行业目录 / 产品页面

发现时间：2026-09-06

需求证据：最近更新了某类产品页面，并公开留下供应商联系入口

产品匹配：高

联系人：公开邮箱，职位暂时未知

评分：78

风险：没有确认采购规模，不能直接承诺价格和交期

下一步：补充公司业务和联系人角色，生成首触草稿

状态：researching

这条记录的价值在于，任何一个人接手都能看懂为什么它进入系统，以及下一步要做什么。以后如果这家公司最终没有回复，我也能回头看，是需求判断错了、联系人找错了，还是触达内容不对。

我会尽量让每个重要判断都带证据。比如评分里有“近期需求”这一项，就要有来源链接和原文片段；“联系人是采购负责人”如果只是模型推断，就要标记为推测，不能混在确认信息里。

这一步很土，但它能防止系统越跑越脏。没有证据的自动化，跑得越久，错误越多。

评分功能：客户价值如何计算和校准

我的评分提示词不会写成“请判断这个客户有没有价值”。这种说法太模糊，模型每次都会换一套标准。

我会把评分拆成明确问题：

第一，这家公司是否真的处在我的目标行业？

第二，页面上有没有实际需求信号，而不是只有一个相关关键词？

第三，我的产品能不能解决它正在面对的问题？

第四，能不能找到可以继续沟通的人？

第五，这个机会有没有时间窗口，还是只是长期可能？

第六，有没有明显的风险，比如信息过期、网站异常、已经明确拒绝、产品不匹配或无法合规触达？

输出必须包含总分、每一项分数、加分理由、扣分理由、证据链接、置信度和下一步建议。没有证据的项目不能给满分，置信度低于某个值就进入人工复核。

我还会让系统保留人工最终结果。因为评分不是终点，成交结果才是。一个客户最后成交了，系统要知道当时评分多少；一个高分客户完全没有回应，也要进入复盘样本。

跑上几周以后，就能看出哪些特征真的有用。可能“公司规模”没有想象中重要，“最近出现了明确采购信号”反而更重要；也可能某个国家的高分客户一直不转化，原因不是评分，而是交付周期不适合。

这时候 AI 才开始从“帮我做判断”变成“帮我整理判断依据”。最终规则还是要由真实业务结果校准。

Codex 实操：如何写一条可验收的开发任务

我现在不会只输入一句“帮我优化一下客户开发流程”。我会把任务写成一张小工单。

任务目标：把 researching 状态的线索补全为可审核的客户作战卡。

输入：线索编号、公司网址、已有原文、产品卡和评分结果。

必须输出：公司业务、目标客户、可能采购角色、需求证据、相关产品、推荐切入点、风险点和来源。

不能做的事：不能编造联系人、不能把推测写成事实、不能修改客户评分、不能自动发送消息。

验收条件：每个结论有来源或明确标记未知；没有有效来源的字段不能进入自动触达；输出格式必须能直接写入数据库。

测试方式：先用 20 条历史线索干跑，比较人工结果和系统结果；确认没有重复写入，再放到定时任务里。

这样写以后，Codex 不只是给我一段看起来不错的文字，而是在一个边界清楚的任务里工作。它知道输入是什么，输出长什么样，哪些事情不能碰，完成以后如何验证。

我也会要求它先看日志和现有代码，再提出修改方案。很多时候问题根本不在模型，而在一个字段名称写错、一个时区处理错，或者同一任务缺少唯一编号。

数据面板：每天查看线索、客户、任务、订单和内容

第一张是机会表。它告诉我今天新增了多少线索，来自哪个来源，多少通过初筛，多少进入调研，多少值得触达。

第二张是客户表。它告诉我哪些客户到了跟进时间，哪些客户回复了，哪些客户需要报价，哪些客户已经明确不再联系。

第三张是任务表。它告诉我哪些任务成功，哪些任务失败，失败是网络问题、数据问题还是规则问题，是否已经重试过。

第四张是订单表。它告诉我销售额之外的东西：产品成本、物流成本、支付成本、退款金额、实际毛利、交付是否延迟、客户是否有复购可能。

第五张是内容表。它告诉我哪些页面刚上线，哪些页面有访问但没有询盘，哪些关键词已经有页面，哪些旧页面该更新。

如果一个后台要我打开十几张页面才能得到这些信息，说明设计还没有完成。我更喜欢每天一份自动生成的摘要，再从摘要里的异常点进去看详情。

运行计划：每天的自动任务如何按时间执行

早上七点，收集新信号，清洗网址和公司名，合并重复记录。

八点半，给高优先级线索做调研，检查昨天失败的任务。

十点，生成客户触达草稿，涉及价格、交期和定制内容的草稿进入人工审核。

中午，处理新回复，给需要人工介入的客户补充上下文。

下午两点，执行已经到期、且没有触发停止条件的跟进任务。

下午五点，更新关键词队列和内容任务，检查是否有页面信息过期。

晚上，汇总询盘、报价、订单、退款和异常，生成第二天的待办。

这个节奏不是固定答案，关键是任务之间有依赖关系。采集没有成功，评分就不能执行；评分没有通过，触达不能执行；客户已经回复，跟进任务就必须暂停；订单已经成交，开发流程要退出。

自动化不是把任务全都同时启动，而是把依赖和状态管理清楚。

订单功能：报价、付款、交付、售后和复购半自动化

我不会把报价完全交给模型自由发挥。报价必须从产品卡、成本表和交付规则里读取。

系统先确认产品、数量、国家、运输方式和交付时间，再根据价格区间生成草稿。低于最低毛利、超过库存、交期不确定、涉及定制开发的报价，自动进入人工审核。

报价单里会保留有效期、币种、付款方式、交付条件和不包含的内容。很多纠纷不是产品本身有问题，而是双方对交付范围理解不一样。

订单成交以后，系统继续检查付款、备货、发货、物流节点和签收。任何一个节点超过预期，就生成异常任务。客户服务 Worker 可以先整理订单上下文和建议回复，人工确认后再发出。

签收以后，系统会根据产品类型安排评价、使用反馈和复购提醒。对于有售后问题的客户，营销任务自动暂停，避免一边投诉一边收到促销信息。

这部分是很多“AI 电商”文章没有讲的地方：真正的生意不在客户回复那一刻结束，交付和售后处理得好，才会产生下一次订单和转介绍。

效果评估：如何判断一个自动化是否真的赚钱

不能只看它跑了多少次，也不能只看生成了多少内容。

我会问四个问题。

它有没有减少人工操作？

它有没有缩短客户等待时间？

它有没有提高有效线索比例或回复质量？

它有没有最后推动收入、毛利或复购？

如果一个 Worker 每天生成一千条内容，却没有带来有效页面、询盘或订单，它只是增加了数据量。如果一个评分系统很复杂，却不能帮助我更快找到值得跟进的客户，它也没有实际价值。

我甚至会定期关闭没有结果的自动任务。能砍掉的流程，说明它没有进入业务核心；留下来的每一个流程，都应该能解释自己为什么存在。

系统优势：一个人如何拥有小团队级执行能力

因为我把团队里不同角色的动作拆了出来。

采集的人负责发现，研究的人负责补信息，销售负责触达和跟进，内容负责页面和搜索，运营负责订单和客户，数据的人负责复盘。

以前这些角色全都由我一个人临时切换，所以每天都很忙，却很难形成积累。现在每个角色都被写成固定流程，前一天的结果会自动传给第二天的任务。

一个人仍然需要做判断，但不需要每次从空白开始。系统会把证据、历史互动、产品信息、报价记录和下一步建议放在一起，让我处理问题时直接进入上下文。

这就是实操感的来源：不是说“我有一堆 Agent”，而是任何一条线索进来，我都能说清楚它从哪里来、为什么评分、现在在哪一步、下一步什么时候做、失败以后怎么恢复。

当这些问题都能回答，系统就开始像一个真正的团队在工作。

下一步优化：继续提升线索、触达、成交和复购

第一是线索质量。数量不是越多越好，真正有采购信号的线索密度才重要。

第二是触达内容。不是让 AI 写得更花，而是让每封内容都基于一个真实观察，减少客户阅读成本。

第三是报价速度。客户有兴趣以后，等待太久，前面的获客工作可能全部浪费。

第四是交付稳定性。系统把订单放大以后，供应链和售后不能靠运气。

第五是复购和转介绍。新客户永远要付出获客成本，老客户的长期价值必须被认真经营。

这些事情每天都能继续优化。每个环节都有数据，每个数据都能回到具体任务，每个任务都能由 Codex 帮我修改和验证。

所以我现在的感觉不是“我用了 AI，效率提高了一点”，而是我终于可以把一部分经营经验写成系统，让它每天替我重复执行。

这套东西真正牛的地方，也许不是某一个模型有多强，而是它把电商里那些经常被忽略的细节都接住了：客户从哪里来，为什么值得跟，怎么联系，怎么报价，怎么交付，出了问题谁处理，最后有没有赚到钱。

如果一个人能把这些环节都搭起来，哪怕每个模块一开始都不完美，也已经拥有了一套过去需要小团队才能维护的执行系统。

这就是我现在公开这套流程的原因。我不想只展示一个漂亮的结果截图，而是把背后的表、状态、任务、提示词、指标和失败处理全部摊开。

真正的月入百万，不是一个夸张标题能带来的。它来自每天找到更多有效机会，少漏掉几个客户，快一点完成报价，稳定地交付订单，再让满意的客户回来购买。

当这些动作都被记录、自动化、复盘和放大，一个人的电商业务才真正有机会从“靠自己拼命干”变成“靠系统持续跑”。

全流程演示：一条订单如何从线索走到收款

假设系统发现一个海外经销商。

第一步，采集 Worker 保存它的网页、来源、发现时间和原文片段。它不会直接判断“这个客户一定会买”，只负责把证据保存下来。

第二步，清洗 Worker 检查公司名称、网站和邮箱，把重复记录合并。如果发现这个客户过去已经联系过，就不会重新生成一条全新的线索，而是把新信号挂到原来的客户记录下面。

第三步，调研 Worker 去补充公司的产品、市场、联系人和最近活动。它要告诉我这家公司为什么可能和我的产品有关，也要明确哪些信息只是推测。

第四步，评分 Worker 根据需求信号、产品匹配、联系人可触达程度、市场潜力和时间窗口打分。分数只是排序，不能代替最终判断。

第五步，如果分数达到触达条件，就生成一封围绕真实证据写的首触草稿。比如对方最近增加了某个品类，或者正在某个市场寻找新的供应商，邮件就围绕这个事实展开。

第六步，草稿先进入审核队列。涉及价格、交期、认证和定制能力的内容，我会人工看一遍。审核通过以后，发送任务才会进入调度器。

第七步，客户回复后，系统暂停后续跟进，把原始回复、历史互动、产品卡和报价建议一起推给我。客户如果想要报价，我处理报价；客户如果只是问交期，系统可以先从产品卡里生成一个待确认的回复。

第八步，订单成交以后，客户从开发队列转入交付队列。付款、备货、发货、签收、售后和复购提醒，继续由订单流程接着处理。

这一条线跑通以后，我才会考虑增加更多来源、更多产品和更多国家。每增加一个渠道，都要回答一个问题：它有没有给系统带来更多有效机会，还是只带来了更多垃圾数据。

风控规则：哪些动作绝不能自动放行

规则一：没有来源的客户信息不能进入高优先级队列。

规则二：没有明确下一步动作的客户记录，不能算作有效线索。

规则三：客户已经回复以后，自动跟进必须暂停。

规则四：明确退订、拒绝、投诉或无效地址以后，后续触达全部停止。

规则五：价格、库存、交期、认证和售后承诺不能由模型自由生成。

规则六：发送、付款、删除、改价和批量发布必须有审核点。

规则七：任何任务失败以后都必须留下状态和原因，不能悄悄消失。

规则八：同一个客户、同一个动作、同一个日期，只允许成功执行一次。

很多人希望 AI 更自由，什么都能决定。真正上线以后，我反而会给它更多边界。边界清楚，系统才敢放大；边界模糊，规模越大，风险越大。

上线测试：用干跑验证不误发、不重复、不乱改数据

系统第一次上线时，我不会直接让它处理全部客户。

我会拿一小批历史线索做干跑，不发送、不改库存、不写入正式订单，只看它能不能正确完成收集、去重、评分和任务生成。

我重点检查四件事：有没有把同一家公司识别成两家公司，有没有把推测当事实，有没有把已经联系过的人重新放进首触队列，有没有因为某个字段为空导致整个任务中断。

等这些问题解决以后，再允许它生成草稿。草稿阶段也不直接发送，先人工看内容是不是引用了真实信息，价格和交期有没有越界，语气是不是像一个正常的业务沟通。

最后才开放小批量发送。先跑小范围，观察送达率、回复质量、退订、投诉和客户反馈，再决定是否扩大。

这套干跑机制非常重要。没有人会第一次写代码就直接把全部库存和全部客户交给程序处理，自动化也应该有测试环境、预览结果和逐步放量。

日报功能：每天自动汇总线索、回复、任务、订单和库存

“今天新发现 246 条原始信号，去重后剩 137 条，符合目标行业 48 条，进入客户调研 21 条，建议人工确认 6 条。”

“昨天有 9 条客户回复，其中 3 条需要报价，2 条需要补充规格，1 条明确退订，3 条暂时不确定。”

“今天有 14 个跟进任务到期，其中 10 个满足发送条件，2 个因为客户已经回复自动暂停，2 个因为邮箱无效进入复核。”

“本周新增询盘来自 4 个来源。来源 A 数量最多，来源 B 数量少，但有效报价率更高。”

“库存风险有 3 个 SKU，预计可售天数低于交付周期；有 1 个供应商最近两次交期超出预期。”

这样的报告比“今天 AI 生成了 300 篇内容”有用得多。前者直接告诉我哪里有钱、哪里有风险、哪里需要决策；后者只是一个看起来很大的产量数字。

经营指标：每天重点查看哪些电商数据

线索量只能说明系统抓到了多少信息，不能说明业务好不好。

我更关心有效线索率，也就是进入人工确认或触达队列的线索，占全部采集结果的比例。如果这个比例越来越低，说明数据源或筛选规则正在变差。

我还会看有效回复率。客户打开消息不等于有兴趣，真正有价值的是回复里包含需求、规格、数量、时间或者下一步安排。

报价转化率反映的是销售和产品匹配。报价很多但成交少，可能是价格问题，也可能是报价没有解决客户真正的疑虑。

贡献毛利比成交额更重要。一笔订单金额很大，如果物流、售后和折扣把利润全部吃掉，它对系统没有正向意义。

再往后看复购率、退款率、交付准时率和客户投诉。前端自动化带来更多订单以后，后端指标不能恶化，否则增长只是在把问题放大。

我会把这些指标按来源、产品、国家和客户类型拆开看。总表看起来正常，不代表每个细分都正常；有时候一个渠道在拖累全部结果，平均值会把问题藏起来。

产品优势：用速度和稳定性放大电商业务

客户发来询盘以后，系统先完成识别和分级；客户需要报价以后，产品卡和成本规则马上被调用；客户暂时不回复以后，跟进任务不会丢；订单发货以后，物流节点异常会被提醒。

这些动作如果以前需要我在五个后台里来回切换，现在变成一条连续的任务链。真正的提升不是让某个环节快十倍，而是让中间少掉很多等待和遗漏。

我也不追求每个环节都完全自动。一个高金额定制订单，最后由我审核是合理的；一个低风险、规则清晰的重复任务，才适合交给系统直接执行。

自动化程度应该由风险和价值决定。价值越高、风险越大的动作，人工参与越深；频率越高、规则越清楚的动作，自动化越彻底。

最小版本：从一个产品和一类客户开始搭建

先选一个产品，不要一开始接十几个品类。

再选一种客户，不要同时做所有国家和所有行业。

建立一张产品卡，写清成本、售价、毛利底线、交期和禁用承诺。

建立一张线索表，至少保存来源、证据、评分、状态和下一步。

接入一个稳定来源，先让采集和去重每天自动跑。

加一个客户调研 Worker，输出固定字段和来源。

加一个触达队列，首触先人工审核。

加一个跟进状态机，让回复、拒绝和退订都能停止后续任务。

最后接订单和复购，把前端获客结果真正连到收入。

只要这条小链路能连续运行，就可以逐步扩展。先让一条河流稳定流动，再增加支流；一开始就铺满整个地图，通常只会得到一张很大的空图。

我现在继续做的，也是同样的事：把每一个有效动作写成字段、任务和状态，把每一次结果写回系统，再让 Codex 帮我修改那些真正影响收入的环节。

这套系统最让我有信心的地方，是它不依赖某一天的状态。它不会因为我今天忙、今天累、今天出差，就停止找客户、检查订单、更新内容和安排下一次行动。

一个人不可能同时盯住所有页面，也不可能记住所有客户。但一个人可以设计一套系统，把该记住的记录下来，把该执行的排好队，把必须判断的事情集中到自己面前。

这才是我理解的“一个人做月入百万级电商”的核心能力。

我想做的，是跨境电商的 AI 操作系统

以后一个跨境电商团队里，可能同时有几十个 AI 任务在跑：有人找客户，有人分析竞品，有人写产品页，有人翻译内容，有人处理客服，有人检查报价，有人分析订单和库存。

真正的问题不再是“要不要用 AI”，而是“这么多 AI 同时工作以后，谁来管理它们”。

谁知道它们有没有重复劳动？谁知道它们花了多少钱？谁知道某个任务已经失败了几次？谁知道哪个 Prompt 正在让成本变高？谁知道一个 AI 项目最终有没有带来订单？

这就是我做 AI 跨境电商指挥中心的原因。

它不是一个孤零零的工具，也不是给电商页面加一个聊天机器人。它更像一层放在所有 AI 项目之上的操作系统：底层连接模型和业务，上层让人看见成本、状态、错误和结果。

客户调研、SEO、客服、报价、订单分析，这些模块可以各自运行；成本、Token、延迟、预算、Prompt 和异常，又可以被统一管理。

我希望一个人打开它以后，看到的不是一堆模型名称，而是一张真正和收入有关的地图：哪些项目在带来线索，哪些任务在推动成交，哪些成本值得继续，哪些错误必须马上修。

这才是我认为 AI 进入跨境电商以后，最值得做的一层基础设施。

如果过去的电商软件解决的是“把客户、订单和库存放在一起”，那么我现在想做的是把“所有 AI 执行动作、成本和结果”也放在一起。

当 AI 数量从一个变成十个、从十个变成一百个时，真正有价值的产品，一定不是再增加一个孤立功能，而是让整个系统仍然可见、可控

原文信息

原文地址：

• 作者：DeanHeoi（@DeanHeoi），独立开发者，AI 跨境电商与检测工具方向
• 发布时间：2026-09-06
• 来源：X Article