把外贸工作建成可复用的 AI 知识库：从一份产品资料开始

发产品、回复询盘、更新独立站，常常需要反复确认同一批信息：材质是什么，哪张图片可以用，旧报价是否仍有效，某个英文卖点有没有依据。

如果这些答案只在个人聊天记录、桌面文件和业务员的记忆里，换人接手或换一个 AI 工具，工作就容易重新开始。

我一直主张把日常工作建成自己的项目。先把事实、规则和输出整理清楚，再让 Agent 在授权范围内读取和使用。这样，每次完成的工作才有机会成为下一次可以复用的资产。

这篇文章从最基础的产品资料整理讲起。下面的文件结构、包装产品和任务指令都是教学示例，不是客户案例，也不代表已经在某个国际站账号完成自动发布。

知识库先回答三个问题

知识库不必一开始就做成复杂系统。先让接手的人和 Agent 能回答：

1. 哪些事实可以使用？ 产品规格、公司介绍、图片授权、适用条件与资料来源。
2. 这项工作应该怎样做？ 从哪里取资料，哪些内容必须核对，缺信息时停在哪里。
3. 怎样判断做完了？ 输出什么文件，谁审核，哪些问题尚未解决。

这不保证每次输出都正确。它的价值是让错误更容易定位：究竟是源资料过期、读取遗漏，还是规则执行出了问题。

先建一个能看懂的小目录

我建议从一个产品品类、一个具体任务开始，例如“为一个包装产品生成英文资料草稿”。

trade-project/
├── START-HERE.md          项目目标、负责人、资料入口
├── RULES.md               读取范围、禁止动作、审核要求
├── knowledge/
│   ├── company.md         已确认的公司事实
│   ├── products.md        按 SKU 整理的产品事实
│   ├── keywords.md        关键词及适用条件
│   └── asset-index.md     素材路径、版本、公开权限
├── workflows/
│   └── product-draft.md   资料草稿的输入与检查规则
├── output/                本轮草稿与缺失清单
└── CHANGELOG.md           变更、审核与复盘记录

这些文件名是组织建议，不是所有 Agent 都会自动识别的标准。选定工具后，要按其官方规则配置项目指令或 Skills，并明确告诉它本次该读哪些文件。

如果还不熟悉这种组织方式，可以先看用 Markdown 建立可复用的 AI 工作项目。

为什么可以从 Obsidian 开始

Obsidian 将笔记保存在本地的 Markdown 文件中，提供笔记链接和关系图，适合把分散的文本资料整理成可浏览的项目。¹

起步时，可以从官网下载软件，创建一个用于演示的空白笔记库，再建立上述目录，把审核过的资料副本放进去。已有项目也可以作为笔记库打开；开始前先备份，避免整理时误改唯一原件。

Obsidian 是一种管理方式。普通文件夹和文本编辑器也可以完成最初的整理。更关键的是内容是否准确、谁来维护、下一次能否找到。

本地保存不意味着所有后续操作都留在本地。 一旦把文件交给云端模型、同步服务或插件，数据流向就要重新检查。敏感客户资料应放在独立权限范围里；API Key、登录凭据和会话信息不要写进知识库正文。

产品事实要带来源和适用条件

只写“产品是环保袋”，Agent 仍然不知道可以公开写到什么程度。更好的做法是把事实拆成可检查的字段。

下面是一张虚构产品资料卡的结构示例。示例 SKU 只是教学标识，表中没有可用于真实报价或销售的参数。

公司介绍也需要维护。工厂规模、生产范围和认证并非写好后永远不变。报价资料应与通用产品资料分开管理，避免把某个客户的成交条件当成公开价。

客户画像可以先保存目标行业、采购角色和常见需求。具体联系人、邮件和订单属于另一层数据，不能因为“建知识库”就全部开放给所有工具。

让工作规则指向事实，而不是复制一套旧数据

我倾向于把变化较快的产品事实放在知识库，把取资料和检查的方法写进工作规则。这样，维护资料时更容易找到正确位置。

下面是一段可以用于小样演练的任务指令：

只读取 trade-project/knowledge 中本次授权的资料副本。
为示例 SKU DEMO-P01 生成一份英文产品资料草稿。

先列出实际读取的文件和版本，再按字段核对来源。
遇到冲突、缺少单位、过期报价或未核实认证，写入待确认清单。
不得补造材质、性能、价格、MOQ、交期、认证和客户案例。
关键词只选与本产品事实相符、用途匹配的词，不机械拼满标题。

输出英文草稿、中文核对说明、引用清单和待确认事项。
只写入 output，不覆盖原资料，不打开业务后台，不对外发布。

如果以后把它做成 Skill，需要按选定 Agent 的格式安装、配置并测试。普通 Markdown 中写一个 [[产品资料库]] 链接，并不会让所有 Agent 自动完成文件读取；也不能保证每次任务都会拿到最新版本。

验收时检查的是实际读取清单和引用位置，而不是它口头说“我已经理解了全部资料”。

关键词库：先描述真实产品，再组织搜索表达

词库可以服务于产品文案、客户问题整理和内容规划。它应该保留词语的来源、用途与适用条件，而不是成为未经确认的卖点合集。

现有模板按下面十个维度拆词。这里的包装词汇仅说明分类方法，使用时要逐项核对本产品是否具备相应材质、结构与功能。

不要因为模板里出现了一个词，就默认它适用于所有产品。尤其是 recyclable、食品接触、安全和认证类表述，必须先确认依据与范围。

标题与描述要围绕买家实际需要的信息来写，不设“固定塞入多少核心词和长尾词”的万能公式。网站的描述也应是准确、简洁的页面概述；Google 是否使用这段描述生成摘要，由搜索系统决定。²

广告关键词可以作为候选池，具体投放、出价与预算还需要结合账户数据和负责人判断。本篇不把词库直接连接广告账户，也不承诺排名、流量或询盘提升。

如果继续接浏览器，先把草稿与发布分开

资料整理跑通后，可以再评估浏览器辅助。Microsoft 的 Playwright MCP 项目可让 Agent 通过工具与浏览器交互，但工具本身不能证明某个平台的填写、审核与提交流程都能稳定自动化。其官方项目也明确说明，它不是安全边界。³

对于 Alibaba.com 产品资料准备，可以先设计这样的流程：

1. 负责人确认账号、类目和当前平台规则，人工走查实际页面。
2. 从已核实的 SKU 资料生成待审文案和素材清单。
3. 如获授权，再用隔离的浏览器环境检查当前字段与校验要求。
4. 填写过程中对照原资料检查单位、必填项、图片与商业条件。
5. 人工审核完整预览，决定是否提交。
6. 正式操作后核对真实状态和回执，再记录结果。

这是流程设计示例。本次没有登录国际站、填写产品或做发品计时。母稿中的 XPath 和下拉框位置不作为当前后台的可用选择器；类目、账号权限与界面变化都可能使旧定位失效。Playwright 官方建议优先使用角色、标签等面向用户的定位方式，具体定位仍要在实际页面验证。⁴

只看到截图，不能算产品已发布。页面填完、提交成功、审核通过和公开可见，应在记录中分别说明。

让复盘成为下一次的输入

知识库不会因为文件数量增加就自动变聪明。真正有用的是把已经核实的改进写回正确位置。

例如，英文草稿把厚度单位读错了，就查清原表是否含糊、读取规则是否遗漏，再修订资料或规则。报价过期，就记录失效条件，不能只在这次聊天里口头纠正。

一次任务结束后，保留读取清单、输出版本、审核意见和未解决的问题。需要评估效率时，记录实际用时、人工修正、错误类型与费用，并说明样本和任务条件。没有这样的记录，就先谈方法，不写“节省了多少时间”。

我的建议仍然很朴素：选一个品类，整理一份可靠的事实卡，让 Agent 生成一份可核对的草稿，再让另一个人检查能否接手。把这个小循环做清楚，才有基础继续扩展。

当事实资料已经能被稳定调用，再读知识库、SOP 与多 Agent 工作流，把日常运营接到这套资料之上。

继续阅读

从第一项可检查的工作开始，与 Agent 一起工作。先把一次任务的输入、权限和验收写清楚，再决定需要增加哪些工具。

来源与核查说明

本文官方资料核查日期：2026-10-01。文中的项目结构、资料卡和任务指令为作者的方法建议；没有把它们写成平台官方流程或真实客户效果。产品界面与规则会变化，接入前应再次核对当前文档与账号。

Footnotes

1. Obsidian 官方网站说明本地 Markdown、开放文件格式、笔记链接与关系图等能力。本地文件管理不等于对所有插件或云端调用的数据安全保证。 ↩

2. Google Search Central：描述与搜索摘要说明描述应准确概括页面，搜索系统不保证固定采用页面提供的 meta description。 ↩

3. Microsoft：Playwright MCP 官方项目，包含浏览器交互能力和安全边界说明。本文不据此推导 Alibaba.com 账号可直接自动发品。 ↩

4. Playwright 官方：Locators，介绍角色、标签等定位方式与定位验证。 ↩