用 Codex 搭建
跨境独立站

READ THIS FIRST写在前面：这篇教程适合谁

你不需要先会写代码或维护服务器；但你仍要能核对英文内容、准备真实产品资料，并按平台要求完成账号与支付验证。

你需要一台电脑、可用于相关服务的支付方式，以及愿意逐步测试和复核的耐心。

这篇教程的目标，是带你把一个面向海外采购商的询盘型独立站，从零搭到可公开访问、可接收询盘，并具备被搜索引擎发现的基础条件。Codex 能协助生成和修改代码、运行命令、解释报错；它不是替代业务判断的“自动建站机”。产品参数、合规声明、翻译、图片授权和最终发布结果，都必须由你复核。

技术栈选择的原因：

• Astro：适合内容与展示为主的网站，可生成静态页面；是否需要客户端交互由项目设计决定
• Cloudflare Pages：可将站点发布到全球网络，支持 Git 集成、预览部署和自定义域名；免费计划有当前适用的配额与限制
• Codex：对话驱动的开发助手，能加快搭建与排错，但每次改动仍应在本地和线上验证

成本并非固定：域名、订阅、表单服务、图片、邮箱和合规服务都会因地区、方案和用量变化。下文所有价格只作预算占位，付款前以各平台的定价页为准。

先把这次学习的终点定清楚

第一版只做一件事：让海外采购商看懂你卖什么、相信资料真实，并能顺利发来询盘。先选一个市场、一种主要语言、3～8 个有完整资料的产品。

每次只完成一个小节。先看“要交付什么”，再复制提示词，最后核对实际结果。图示用于解释流程，控制台入口以当前界面为准。

CHAPTER 01第一章：背景与目标

1.1 Codex 在建站中能做什么

Codex 是一个能「执行开发任务」的 AI。根据你使用的产品形态和授予的权限，它可以读取项目文件、写代码、运行命令、检查页面并协助修复错误。你可以主要用自然语言沟通，不必先系统学习编程；但仍要看懂项目目录、确认操作范围、审阅关键改动，并用构建结果和线上页面验证它是否真的完成了任务。

你可以把它理解成一个能进入项目协作的开发助手：你描述目标，它检查现有文件并提出或执行改动；你根据预览、测试和业务资料反馈问题，再让它迭代。自然语言降低了沟通门槛，但关键决策、授权和验收仍由你负责。

在跨境建站里，Codex 可以显著减少重复编码和排错时间，但不能替你确认产品事实、商标权、出口合规、隐私义务或买家资质。把它当成高效的协作工具，而不是风险的承担者。

Codex 和同类工具的区别

不同工具适合不同工作流。不要仅凭“代码是否可见”判断 SEO 或可扩展性，最终效果取决于内容、性能、信息架构与持续运营。

• Shopify：适合需要商品、订单、支付与后台运营的电商；费用和交易规则按所选方案、地区与支付方式确认。
• Wix / Squarespace：适合快速上线和可视化编辑；上线前仍应检查导出能力、性能与具体 SEO 功能。
• AI 编程助手：适合希望保留代码控制权、愿意在本地测试的人；不同产品的权限、套餐和工作方式会更新。

1.2 为什么选询盘型独立站

询盘型独立站的商业逻辑是这样的：访客通过搜索引擎（主要是 Google）找到你的网站，浏览产品信息，如果感兴趣就填写询盘表单，留下联系方式，然后你主动联系对方谈价格、谈数量、谈合作。

这个模式有几个特点让它特别适合用本教程的方案来实现：

优点一：第一版可以不接在线支付。 询盘型站点先把产品、资质、交期、MOQ 和联系路径讲清楚，访客提交表单后由你跟进报价。这样可以暂缓购物车、支付、退款、税务和订单履约等功能。HTTPS 仍然是网站上线的基础要求；即使使用托管结账页，也要处理支付主体资格、商品信息、退款政策、隐私和履约责任。

优点二：转化率对信任度的依赖更高，但信任度可以用内容建立。 客单价高的产品（比如工业设备、定制家具、批量采购），买家通常不会直接下单，而是先发询盘再谈。这类买家在乎的是你的公司背景、产品规格、生产能力，而不是购物车是否好用——这些都可以用内容页面解决。

优点三：有利于做好可访问性和性能基础。 静态页面通常较容易控制体积和结构，但搜索排名不由框架决定。要获得自然流量，仍需要有价值的内容、清晰的信息架构、可抓取性、外部认可与持续维护；投放是否需要，取决于获客目标和竞争程度。

适合的受众：

• 有供货渠道（自家工厂 / 1688 供货 / 代发货模式）想开拓海外市场的
• 亚马逊、速卖通等平台卖家想建自己的独立站摆脱平台限制的
• 完全零基础想低成本试水跨境的个人创业者
• 懂业务但不懂技术的外贸人、SOHO、外贸业务员

不适合的场景：

• 需要在线购物车 + 即时支付 + 库存管理的 B2C 高频零售（那个更适合 Shopify）
• 对网站视觉设计有极高要求的奢侈品/高端品牌旗舰站（需要专业设计师介入）
• 日更新商品、需要复杂后台管理系统的大型电商平台

1.3 为什么是 Astro + Cloudflare

这是一套适合展示型、内容型或询盘型站点的组合，不是唯一标准答案。Astro 开源免费；Cloudflare Pages 提供免费计划，也有项目配额与功能边界。选择前应确认你是否需要动态后端、复杂账户体系或交易能力。

Astro 的核心优势：

• 可预渲染静态 HTML，并按需要加入交互；不要把“使用 Astro”等同于不产生 JavaScript
• 有利于控制性能，但 PageSpeed 分数受图片、第三方脚本、网络和页面设计影响；它不是排名保证
• 组件化设计，非常适合用 AI 生成模块化代码再组合
• 支持多语言路由，一套代码跑多个语言版本
• 对纯静态站点，通常无需自行运维传统服务器；构建产物是静态文件，但托管平台仍在提供基础设施

Cloudflare Pages 的核心优势：

• 发布到 Cloudflare 的全球网络，实际速度仍受访客网络、页面体积和第三方资源影响
• 免费计划适合许多早期静态站，但应在上线前阅读当前的 Pages Limits 与价格页
• 支持自定义域名和自动 HTTPS；HTTPS 是传输安全与浏览器信任的基础，不等于排名保证
• 与 GitHub 集成，代码推送后自动重新部署，运维成本接近零
• 如果域名由 Cloudflare Registrar 管理，可在同一控制台维护注册、DNS 与托管；支持的后缀、转入条件和价格以当前页面为准

1.4 Pages 与 Workers，如何选

Cloudflare Pages 和 Workers 是两条部署路径。课程主线保留容易理解的纯静态 Pages 流程；需要服务端表单、账户、权限或其他动态能力时，再评估 Workers。当前官网本身已部署在 Workers，但学员不必复制官网的整套技术栈。

纯静态 Astro 站不需要为了上传 HTML 而安装服务端适配器。需要服务端渲染时，才按所用版本的官方部署指南接入适配器。Workers 的创建命令、Pages 的控制台步骤不能混着照抄。Astro 部署到 Pages 与 Astro 部署到 Workers 是两份不同的指南。

1.5 2026 年更可靠的 Codex 工作流

现在用 Codex 建站，关键已经不是“让它一次生成整站”，而是把每次任务做成可检查的小闭环：

1. 先读再改：让 Codex 先检查现有目录、框架版本、构建命令和未提交改动。
2. 先列验收标准：明确要改的页面、移动端表现、表单结果、SEO 字段和不能碰的文件。
3. 小步实施：页面结构、真实内容、表单、SEO、部署分开完成，避免一次改动过大。
4. 本地验证：至少运行项目已有的检查与 npm run build，不要把“代码已生成”当作成功。
5. 浏览器验收：在桌面和手机尺寸检查关键页面、导航、图片、表单和错误状态。
6. 再发布并复查：预览部署通过后再上正式域名；确认 HTTP 状态、版本、站点地图和一次真实询盘。

可以在项目根目录放一个简短的 AGENTS.md，记录项目约定，例如构建命令、内容来源、禁止改动的目录、图片命名和上线检查。Codex 会参考这类项目说明，但说明文件不能代替真实测试。第一次任务可以这样写：

先检查这个项目，不要立刻改文件。
请告诉我：技术栈与版本、主要页面、内容来源、构建命令、当前报错、未提交改动和风险点。
然后为“完成英文询盘站第一版”列出分阶段计划与每阶段验收标准。
任何产品参数、认证、价格、客户案例和公司事实都只能使用我提供的资料；不确定项标记出来，不要补写。
每次修改后运行适用的检查和构建，并列出实际验证结果。

CHAPTER 02第二章：前期准备（预计时间：半天）

2.1 账号注册详细指南

按顺序完成，后面每一步都会用到：

① OpenAI / Codex（核心工具）

访问 chatgpt.com 注册账号，并从 Codex 官方文档 确认当前可用入口。Codex 可能以桌面端、命令行、IDE 扩展或云端任务等形态提供；本教程以“能打开本地项目、运行命令并检查结果”的工作流为主，不绑定某一个固定界面。

按页面提示使用你自己长期可控的邮箱与验证方式完成注册。可用地区、验证与套餐资格会变化，以 OpenAI 的官方说明为准；不要使用接码平台、共享账号或来路不明的代订服务。

注册完成后，查看当前套餐是否包含所需的 Codex 能力及其用量限制。价格、功能入口和可用地区可能调整，不要把某个固定价格或入口位置写进预算承诺。

国内访问的常见问题：

• 使用符合当地法律、服务条款和公司安全要求的访问与支付方式
• 不把客户资料、合同、报价单、密码或 API 密钥直接粘贴进对话
• 付款失败、地区不可用或入口变化时，只通过官方帮助中心与账单页面核对

② Cloudflare（托管与域名平台）

访问 cloudflare.com，点击「Sign Up」注册。

按页面要求注册。控制台和帮助文档可能主要为英文，遇到术语时可让 Codex 解释，但不要在翻译后跳过账号安全或域名所有权确认。

注册完成后，先不用做任何操作，域名购买步骤在下一节完成。

③ GitHub（代码仓库）

访问 github.com，点击「Sign up」注册。

按当前注册流程完成邮箱、用户名和必要的安全验证。你的「用户名」会出现在仓库地址中，例如 github.com/你的用户名/仓库名。注册后立即开启双重验证，并保存恢复方式。

如果你完全不了解 GitHub，把它理解成「代码的云盘」就够了。你在本地写好的网站代码，上传到 GitHub，Cloudflare 从 GitHub 读取代码并发布到互联网上——这是整个部署流程的核心链路。

④ Formspree（可选的表单托管服务）

访问 formspree.io，按当前方案注册账号。

表单服务可先选择适合冷启动的计划；额度、价格、反垃圾能力与数据处理地点会变化。未来询盘增加时，再根据提交量、通知方式与隐私要求选择升级或迁移。

2.2 域名选购的完整策略

域名是你网站的门牌号，一旦建立了品牌认知就很难换，所以值得花时间认真选。

在哪里买域名：

如果目标后缀受支持，可以优先评估 Cloudflare Registrar，这样注册、DNS 与 Pages 能在同一控制台管理。但不是所有后缀和地区都适用，转入也可能受注册时间、锁定状态等条件限制。价格、税费、隐私保护和续费价都可能变化，不要照抄旧教程中的固定美元数字。

购买方式：登录 Cloudflare 控制台 → 左侧菜单找「Domain Registration」→ 搜索你想要的域名 → 选择 → 付款。

其他选择可比较：

• Namesilo / Namecheap 等注册商：比较首年价、续费价、转出限制、双重验证、DNSSEC、支付方式和客服
• 国内注册商：并非不能买境外域名；重点是核对目标后缀、实名要求、DNS、转出流程、付款与售后是否满足你的业务

域名命名的判断标准：

好域名满足这几条：

1. 优先选与品牌和市场一致的后缀。 .com 通用、易识别，但不代表自动更可信或更容易排名；国家或地区业务可评估当地后缀。不要只为关键词选择生僻后缀。
2. 长度控制在 15 个字符以内。太长的域名买家记不住，也容易打错。
3. 能拼读出来。避免容易引起混淆的字母组合，比如 l（L 的小写）和 1（数字一）。
4. 和品类或品牌相关。举几个例子：
   • 卖户外折叠椅：foldpro.com、campchair.co、outchairco.com
   • 卖工业零件：precisioncn.com、cnparts.store
   • 卖家居收纳：orgabox.com、nestorganizer.com
5. 不要有连字符。fold-pro.com 看起来没问题，但用户说网址时不知道要不要停顿，容易丢失。

域名可用性检查： 在注册商搜索框输入候选名称，先确认它确实可注册，再核对首年、续费、赎回、税费和隐私保护价格。高价域名可能是溢价域名或他人转售，不要只看首屏数字就付款。

2.3 本地开发环境搭建（详细版）

这部分是大多数零基础用户最头疼的地方。下面分 Windows 和 Mac 两套步骤，对照你的系统来操作。

如果你对命令行完全陌生，遇到问题时把当前步骤、完整命令、报错文字和相关截图交给 Codex，并说明操作系统与项目目录。不要只发一张被裁掉上下文的截图；也不要把 Token、邮箱验证码、Cookie 或客户数据带进截图。

安装 Node.js

Node.js 是 Astro 框架运行所需要的基础环境，必须先装好。

Windows 用户：

1. 打开浏览器，访问 nodejs.org
2. 下载 Astro 当前支持的 Node.js 版本。按 2026 年 10 月 16 日的 Astro 安装文档，最低为 Node.js 22.22.0，且不支持 23 这类奇数版本；优先使用满足要求的 LTS 版本
3. 双击运行安装包，一路「Next」，保持默认选项，安装完成
4. 按 Win + R，输入 cmd，打开命令提示符
5. 输入 node -v，按回车，显示版本号（如 v22.22.0）说明安装成功

Mac 用户：

1. 打开浏览器，访问 nodejs.org
2. 下载 macOS 版 LTS 安装包（.pkg 文件）
3. 双击安装，按提示完成
4. 打开「终端」（按 Cmd + 空格，搜索「终端」）
5. 输入 node -v，按回车，显示版本号说明成功

常见问题：

• 显示「command not found」：说明安装没有成功或路径没有配置好，把截图发给 Codex 处理
• 版本低于 v22.22.0：不要直接覆盖或反复卸载。可使用 Node.js 官方安装包，或让 Codex 指导你用版本管理工具安装受支持的 LTS 版本；升级后重新打开终端，再检查 node -v 和 npm -v

安装 Git

Git 是代码版本管理工具，用于把本地代码推送到 GitHub。

Windows 用户：

1. 访问 git-scm.com，下载 Windows 版安装包
2. 双击安装，第一次安装时建议保持所有默认选项（除非你知道自己在改什么）
3. 安装完成后，右键桌面，如果菜单里出现了「Git Bash Here」和「Git GUI Here」，说明安装成功
4. 打开命令提示符，输入 git --version，显示版本号确认

Mac 用户：

Mac 通常自带 Git。打开终端，输入 git --version，如果提示安装 Xcode Command Line Tools，按提示安装即可（免费）。

Windows 用户额外说明：终端用哪个

Windows 有几种终端可以用：

• 命令提示符（cmd）：最基础，大部分命令能跑
• PowerShell：功能更强，Astro 的命令在这里运行更稳定
• Git Bash：安装 Git 后自带，Linux/Mac 风格的终端，本教程的命令在这里也能跑

可以使用 PowerShell，搜索后以普通用户身份打开。如果 npm.ps1 被执行策略拦截，先尝试 npm.cmd -v 或在命令提示符中运行同一命令，并让 Codex 判断具体报错；不要直接降低全局执行策略或长期用管理员权限运行项目。

2.4 在开始之前，整理好你的产品资料

别急着让 Codex 写页面。先把资料做成一个能核对、能报价、能公开的“小资料包”。这一步做得扎实，后面每个产品页都能复用；做得含糊，AI 只会把含糊内容写得更像真的。

建议在电脑里新建一个项目文件夹，至少分成四个子目录：

00-产品清单与报价边界
01-产品图片与授权说明
02-公司与品牌资料
03-认证、检测与可公开证明

不是资料越多越好。每一项只要回答三个问题：它是否真实、是否可公开、是否能在客户追问时拿出依据。

一、产品资料卡：每个主推产品单独填一份

先选 3～8 个最适合获得询盘的产品作为首批上站产品，不要一开始把全部 SKU 都塞进去。每张资料卡至少包含：

【产品身份】
产品名称（中文）：
产品名称（英文，如有）：
内部型号 / SKU：
所属品类：
一句话卖点（只写可证明的差异）：
适用客户与使用场景：

【规格口径】
材质及等级：
尺寸（长 × 宽 × 高，注明展开 / 折叠 / 包装状态）：
净重 / 毛重：
承重、容量、功率等关键性能：
颜色、表面处理、可选款式：
包装方式、单箱数量、外箱尺寸：
可提供的定制项（Logo、颜色、包装、尺寸等）：

【交易边界】
起订量（MOQ）：
样品是否收费、样品周期：
可接受的贸易条款与币种（按实际填写）：
常规交期范围及影响交期的条件：
主要装运地或可服务地区：
询盘后需要确认的信息（数量、目的港、定制要求等）：

【内容与证据】
可公开使用的图片文件名：
图片来源 / 授权状态：
可公开展示的认证、测试或专利：
不能承诺或尚待确认的内容：

尺寸、重量、包装和交期最容易出错。不要混用产品净重与含包装毛重；不要把打样周期写成大货交期；也不要把“可定制”写成没有边界的承诺。写不准时，标记为“询盘后确认”，比猜一个数字安全得多。

二、图片资料：让买家看懂，也让页面经得起核验

图片先按产品型号命名，例如 folding-chair-black-01.jpg，并记录它的用途：主图、细节、尺寸、场景、包装或工厂环境。每个主推产品至少准备：

• 一张干净的主图，能一眼看出产品本身；
• 两到四张细节图，展示材质、接口、折叠方式或工艺；
• 一张真实使用或应用场景图；
• 有条件时补充尺寸图、包装图和短视频。

只有你自己拍摄、供应商明确授权，或已确认商用许可的素材才放进网站。不要直接搬运同行、平台买家评价或品牌图库，也不要用 AI 生成的工厂、证书或客户合影去替代真实证明。

三、公司与信任资料：只展示能够落地的信息

公司 / 品牌对外名称：
经营主体类型（工厂、贸易公司或两者兼有）：
主营品类：
已服务的市场或地区（按真实记录写）：
可公开的成立时间、地址、联系方式：
负责询盘的邮箱与工作时间：
可公开的生产、质检、仓储或售后能力：
可公开的认证名称、适用产品与有效状态：
隐私政策联系邮箱：

认证不是装饰词。只有证书确实存在、覆盖当前产品且允许公开时再写；“符合某标准”“已通过某认证”这类表述要与文件原意一致。客户案例、合作品牌、年产能、最快交期同样需要可回查的依据。

四、给 Codex 的交接方式：一次交清，不要口头补丁

资料整理完成后，把每个产品的资料卡、图片文件夹和公司信息放在同一项目目录。第一次交给 Codex 时，可以这样说：

请基于这个资料包搭建英文询盘型独立站。
只使用我提供的产品参数、图片和公司事实；没有资料的字段不要补写。
首批上站产品是：[产品型号 / 名称]。
每个产品页要保留“Request a Quote”入口，并把需要询盘后确认的项目明确写成“Contact us for details”。
先输出网站结构和缺失资料清单，等我确认后再生成页面。

最后做一次红线检查：认证、价格、交期、库存、客户、工厂、地址、图片授权，任何一项没有证据，就不要把它写成既成事实。网站上线后，这些内容会变成买家判断你是否可靠的依据。

2.5 上线前先做合规映射

独立站能打开，不等于产品就能向目标市场销售。至少建立一张“市场—产品—责任”清单，再决定页面能写什么：

如果面向欧盟销售消费品，应按具体产品检查欧盟产品安全、追溯和线上商品信息要求；美国等市场也可能有产品类别、州法和广告规则。美国 FTC 的基本原则是：广告主张要真实、不误导，并有证据支持。各国法规、产品分类和责任主体不同，本教程不能替代针对你产品与市场的专业合规意见。

最实用的做法不是让 Codex“生成一份通用隐私政策”，而是先告诉它：经营主体、目标国家、表单字段、第三方服务、分析工具、数据保存方式和联系渠道。让它输出缺失信息清单，再由你或专业人士确认文本。不要把 AI 生成的法律文本未经审核直接上线。

2.6 前期准备完成清单

确认以下六件事都完成了，才进入第三章：

• 可正常使用 Codex，并已确认当前套餐与用量边界
• Cloudflare 账号注册完成，域名已购买并显示在控制台
• GitHub 账号注册完成，记住你的用户名
• 电脑上 Node.js（使用 Astro 当前支持的 LTS 版本）和 Git 都安装好了，版本号可以正常显示
• 产品信息和公司信息整理好了，放在一个文档里备用
• 图片、商标、认证、地址和客户案例均已确认有公开使用权