跳到主要内容

当前独立站开发进度说明

文档版本:v1.1
更新日期:2026-04-03
适用对象:AOVIS / NEXA 团队研发、产品、运营协作成员

1. 当前结论

目前 aovis.app 独立站已经完成了“可用的电商与账户基础设施”,不是纯展示站,也不是设备云已经打通的成品。

可以准确理解为:

  • 已完成:前台站点、登录、商品、购物车、下单、Stripe 支付、订单中心、管理员后台基础、数据套餐购买框架
  • 已预埋但未打通:设备绑定、摄像头云服务、SIM/套餐自动激活、外部设备云状态同步
  • 当前最适合的下一步:在现有架构上接入探鸽 SDK 与云服务供应商 API,而不是重做站点

2. 前端开发进度

已完成

  • 首页、商品页、购物车、Checkout 成功页 / 取消页已完成
  • Shipping / Returns / Support / Contact / Terms / Privacy 等公共页面已完成
  • 站点视觉已做过一次面向消费电子独立站的重构,已具备正式上线风格基础
  • 登录页与账户页已完成,并支持 Google / Apple / Email Magic Link
  • /account 下已完成:
    • Overview
    • Profile
    • Orders
    • Devices
    • Services
  • /data-plans 页面已完成,可发起真实的 Stripe Checkout 购买数据套餐
  • /services/technology/products/nexa-prime-4k/support/faq/services/ai-intelligence 已完成一轮内容质量与表达准确性收口

当前公开内容基线

当前公开页已经不再只是“可上线”,而是进入了内容一致性收口阶段。现阶段应按以下标准维护:

  • AI 亮点仍然保留,但表达应保持可信、克制、可解释
  • 页面正文、FAQ、FAQ schema、metadata 对同一能力应使用一致口径
  • /services 页面已确立的结构基线为:
    • 顶部页面引导
    • 一层清晰的 service stack 概览
    • 概览卡片本身兼作锚点导航
    • 下方详细服务模块
  • 不要再额外叠加第二层重复导航卡片或重复胶囊入口
  • Technology / FAQ 文案现阶段应优先沿用真实用户调研口径:
    • 先说买家实际遇到的问题,再说 AOVIS 怎么处理
    • 语气保持工程解释型,不写成强推销
    • 允许在技术页轻量提及公共社区来源,增强可信度,但不要外链、不做煽动性引用

2026-04-14 SEO 调优与索引收口记录

  • 本次已完成一轮公开页 SEO 收口,并已重新部署到 aovis.app
  • 当前 release commit: bc1a9c18a3cf68ef6b94886eafd0e5ac1c98a121
  • 已补强的部分:
    • /support/docs 作为帮助中心入口进入 sitemap.xml
    • 3 个 support/docs 占位页改为 noindex
    • 多个公开页 title 去重,避免浏览器标题和搜索结果里重复堆品牌后缀
    • contact 页补齐 canonical 和公开 robots
  • 当前线上真值验证已通过:
    • robots.txt 200
    • sitemap.xml 200
    • 首页、产品页、technology、services、FAQ 均保持可访问且 canonical 正确
    • 主页的 Organization / WebSite schema 仍然存在
  • 当前 SEO 维护原则:
    • 新增占位页默认先用 noindex
    • 公开页 title 保持简洁,不重复堆叠品牌后缀
    • 先收录有价值的入口页,再逐步开放更细的文档页

AI 文案当前基线

当前公开页面对 AI 功能的标准表达是:

  • 保留卖点:
    • Daily AI Summary
    • Smart Search / AI Indexing
    • smarter review
    • reduced review noise
  • 但避免绝对化承诺:
    • 不写成“永远准确”
    • 不写成“只会提醒真正重要的内容”
    • 不写成“理解所有复杂场景”
    • 不写成“搜索一定精确命中”

推荐持续沿用的语气:

  • designed to help
  • intended to make review faster
  • helps surface relevant footage faster
  • focused on reducing noise
  • built to improve how users review footage

当前显示状态

  • 用户侧已经能看到“设备”“服务”“4G 套餐”这些产品能力
  • 但其中很多仍是“前端已展示、后端只完成数据结构或部分落库”
  • 例如:
    • /account/devices 已能显示设备与 SIM 卡信息,但新增设备/设备设置仍未开放
    • /account/services 已能显示套餐、权益、订阅结构,但云服务权益自动开通尚未实现

2026-04-08 账户中心 UI 收敛记录

  • /account/account/orders/account/devices/account/services/account/profile 已统一为同一套轻量账户中心视觉语言
  • 账户中心的公共壳、section card、row/list、empty state 现在共用一套组件语言,避免 overview 和子页看起来像不同系统
  • Mobile 端保留轻量 4-tab pill 导航,desktop 侧边栏不变
  • Overview 已从大卡墙收敛为短摘要行 + 轻量活动行,减少“看起来很多但信息密度低”的问题
  • Orders / Devices / Services / Profile 页已同步压缩为相同的高密度阅读节奏
  • 当前 release commit: 6692b60

手机网页端当前补充判断

  • 2026-04-02 已完成一轮手机网页端接手修复,并已重新部署到 aovis.app
  • 当前线上手机端已经恢复到“可访问、可构建、关键页面可打开”的状态
  • 已经上线的手机端改动包括:
    • 顶部汉堡菜单与移动端导航
    • 登录页按钮样式优化
    • /services/cellular-data 的移动端展示调整
  • 本轮还修复了一个真实线上问题:
    • 汉堡菜单展开时曾覆盖不完整,菜单文字会压在首页 Hero 内容上;现已修复为完整覆盖式抽屉层
  • 但当前手机端仍不能视为最终交付版本,后续仍需继续调优:
    • 首页与部分内容页的移动端节奏、留白和层级还不够稳定
    • 某些页面的组件密度、信息顺序和触控体验仍需优化
    • 账户页、服务页、产品相关页面仍需要系统性的移动端复核

未完成

  • 摄像头真实绑定流程
  • 摄像头实时能力接入
  • 云服务状态同步
  • 套餐激活后的自动回写与闭环体验

3. 后端开发进度

已完成

  • Next.js 全栈 API 路由已成形
  • Auth.js + Prisma + PostgreSQL 已稳定落地
  • 用户、账户、Session、CustomerProfile 等身份基础模型已完成
  • 商品、变体、购物车、订单、支付、收货地址等电商模型已完成
  • 硬件商品支付链路已完成:
    • POST /api/cart
    • POST /api/checkout
    • POST /api/stripe/webhook
  • 硬件订单支付成功后,数据库可写入 / 更新:
    • Order
    • OrderItem
    • Payment
    • ShippingAddress
  • 用户可以在账户订单中心查看订单和详情

管理后台已完成

  • /admin 已有基础后台能力
  • 已具备:
    • Customers
    • Orders
    • Payments
    • Services
    • Data Plans
    • Data Plan Purchases
    • SIM Cards
    • Access Control
  • Admin 权限控制已具备环境变量白名单和数据库授权两层机制

Tax / Shipping 后台当前状态

  • 2026-04-03 已完成一轮 tax / shipping 后台基础能力补齐,并已部署到 aovis.app
  • 当前后台不再只是“查看订单结果”,而是已经具备一层轻量运营基础:
    • Orders 列表已能显示 shipping / tax / tracking / manual adjustment 相关信号
    • Order detail 已增加 financial breakdown、billing snapshot、shipment / tracking、audit timeline
    • 已新增:
      • /admin/settings/shipping
      • /admin/settings/tax
  • 这轮新增的数据结构包括:
    • ShippingRateConfig
    • TaxConfiguration
    • Shipment
    • FulfillmentEvent
    • OrderAuditLog
    • 以及 Order 上的 tax / shipping 元数据补充字段

2026-04-03 后台补洞后的最新状态

在 tax / shipping admin foundation 上,又补了一轮“精确补洞”,目标不是新增系统,而是让现有后台能力真正可运营、可验证。

当前已经补齐并上线的内容:

  • /admin/orders/[id] 现在已经显示原本只落库但未展示的字段:
    • deliveryEstimate
    • taxCurrency
    • taxJurisdictionSummary
    • shippingRateId
    • taxOverrideReason
    • shippingOverrideReason
    • lastManualAdjustmentAt
    • lastManualAdjustmentBy
  • Audit timeline 已补全:
    • beforeValue
    • afterValue
    • reason
    • operator
    • time
  • /admin/orders 已增加运营可用筛选:
    • productType
    • shippingCountry
    • shippingState
    • hasManualAdjustments
    • hasTracking
  • /admin/orders 同时增加了:
    • productType
    • 当前结果数
    • 当前生效筛选条件标签
  • /admin/payments/[id] 已把 reconciliation 占位替换为可写的轻量 internal note / reconciliation note
  • /admin/orders/[id] 已支持 billingAddress 编辑:
    • 仅修改本地订单上的 billing snapshot
    • 不改 Stripe 支付事实值
    • 会写入 OrderAuditLog
    • 会记录 before / after / reason / operator / time

本轮修复过程中确认的真实边界

  • /admin/orders 的筛选现在已验证可用
  • billingAddress 编辑已验证可保存并写入 audit
  • 当前后台仍然是“轻量运营系统”,不是完整 ERP / WMS / tax reconciliation 平台
  • 当前仍然不支持:
    • 直接改已支付订单的 shippingAmount
    • 直接改已支付订单的 taxAmount
    • 直接覆盖 Stripe automatic tax 的事实结果
    • 完整对账工作流
    • 复杂 tax exemption / filing / export

当前 tax / shipping 的真实边界

  • Stripe automatic tax 仍然是税额事实来源
  • 已支付订单的财务事实值仍以原始支付结果为准
  • 后台人工修正当前是“运营标注 + 审计记录”,不是直接覆盖支付金额
  • checkout 侧已经具备“后台配置优先 + 默认两档 fixed shipping fallback”的能力
  • 当前仍未进入复杂配送 / 税务系统阶段:
    • 没有多仓系统
    • 没有承运商实时询价
    • 没有自建税务引擎
    • 没有用户侧自助改税费 / 运费流程

4. 支付与外部服务对接进度

Stripe

  • 硬件商品 Stripe Checkout 已真实接通
  • Stripe test mode 已验证通过
  • live payment readiness 文档和环境规则已整理完成
  • 当前不应改动现有硬件支付主链路,只应在后续能力中复用它

Data Plan 购买

  • 已有独立数据套餐购买链路:
    • POST /api/checkout/data-plan
    • POST /api/webhooks/data-plan
  • Stripe 支付成功后,已可写入 DataPlanPurchase
  • 说明数字服务售卖框架已经存在

但目前仍未完成的关键点

  • 支付成功后,还没有真正调用外部供应商 API 去激活套餐
  • 还没有把套餐自动分配到指定 SIM
  • 还没有把激活结果自动回写到 SimCardEntitlementDataPlanPurchase

5. 设备与云服务相关研发进度

已准备好的部分

数据库和页面层已经为后续设备接入预埋了完整结构:

  • Device
  • DeviceOwnership
  • Subscription
  • Entitlement
  • DataPlan
  • SimCard
  • DataPlanPurchase
  • SimEvent

这说明项目已经明确要支持:

  • 用户与设备的绑定关系
  • SIM 卡与流量套餐
  • 云服务权益
  • 后台运营查看与处理

当前仍是预埋/占位的部分

  • 真实设备绑定流程还没打通
  • entitlement 自动发放还没打通
  • 摄像头云服务与设备状态还没打通
  • 套餐自动履约还没打通

6. 外部 API 对接准备情况

已有准备

  • 仓库里已经存在 lib/eiotclub.ts,作为 IoT 平台 API client 的接入位
  • 已预留的方法包括:
    • 查询卡信息
    • 查询可用套餐
    • 刷新流量用量
    • 订阅套餐
    • 查询余额
    • 绑定设备
    • 拉取卡列表
  • 后台也已经有 Data Plans、SIM Cards、Data Plan Purchases 的显示和管理入口
  • POST /api/webhooks/eiotclub 已可以接收入站 webhook 并写入 SimEvent

当前真实状态

  • lib/eiotclub.ts 目前仍是 STUB
  • 真实 API 调用没有实现
  • 签名逻辑没有实现
  • webhook 目前只落库,不推进业务状态

对探鸽接入的意义

这意味着当前项目已经具备:

  • 外部设备云 / 运营商 API 的接口位置
  • 数据库存储结构
  • 用户侧与后台侧展示承接面

因此下一轮接入探鸽时,应该是在现有架构内补齐能力,不是推翻重做。

7. 当前研发阶段判断

如果面向团队做一句话判断:

当前独立站已完成电商与账户主链路,已具备设备与服务接入骨架,但摄像头 SDK、设备云、套餐履约和状态同步仍处于待接入阶段。

8. 下一阶段建议

建议团队下一阶段按以下顺序推进:

  1. 先完成探鸽 SDK / 云服务文档与凭证确认
  2. 先做只读同步,再做写操作
  3. 优先接通设备绑定和设备状态同步
  4. 再接数据套餐激活履约闭环
  5. 最后补齐云服务权益和后台运维补偿能力

9. 参考文档

已完成

  • 新增 /legal 法律页体系:
    • /legal/terms
    • /legal/privacy
    • /legal/dmca
    • /legal/acceptable-use
    • /legal/refund-warranty
  • 新增 /contact 页面,作为公开联系入口。
  • 增加旧路径 301 跳转:
    • /privacy -> /legal/privacy
    • /terms -> /legal/terms
  • 已将网站公开可见的个人工作邮箱 guorui@aovis.us 统一替换为公司对外客服邮箱 support@aovis.us
  • 已补充域名与法律主体说明:
    • aovis.app 为官方主站
    • aovis.us / aovis.uk 为区域域名与邮件通信域名
    • 所有法律主体统一归属于香港公司 Fifth Key Element Co., Limited

保留不变的专用邮箱

  • legal@aovis.us
  • privacy@aovis.us
  • dmca@aovis.us

验证结果

  • 本地 npm run build 已通过。
  • 法律页、footer、sitemap、signup / checkout / support 相关引用已同步到新路径与新邮箱。
  • 该变更属于公开站点内容与联系信息更新,不影响 checkout、Stripe webhook、auth、订单或 tax / shipping 主链路。

11. Company / Brand / Domain / Service Architecture Record

  • Fifth Key Element Co., Limited
  • Jurisdiction: Hong Kong

Brand

  • AOVIS

Domain System

  • aovis.app — official main site, service platform, account system, and legal pages
  • aovis.us — United States regional domain and email domain
  • aovis.uk — United Kingdom regional domain

Email System

  • support@aovis.us — customer support
  • dmca@aovis.us — DMCA / copyright notices
  • privacy@aovis.us — privacy and data rights
  • legal@aovis.us — legal inquiries, optional dedicated alias

Service System

  • Hardware — camera products
  • Cloud Storage — subscription service
  • Cellular Data — subscription service

Support Entry Standard

  • Primary web support action is Chatwoot.
  • Use Chat with Us or Get Support for primary support buttons.
  • Use Support Center only when a button routes to a support hub page.
  • Keep support@aovis.us as a secondary fallback, not the main CTA.
  • Do not surface a public phone CTA on support pages or footer blocks.
  • AI Video — future service tier

Platform Integrations

  • Stripe
  • Google Sign-In
  • Apple Sign-In
  • DMCA handling
  • Amazon

Naming Clarification

  • account-staging-test is a historical repository / workspace name and does not describe the current product identity.

Workspace Rename Record

  • The local development workspace was renamed from account-staging-test to aovis-direct-store.

  • This change only affects the operator workstation path.

  • VM deployment paths remain unchanged.

  • The current VM code path is still /opt/aovis/aovis-store-staging.

  • aovis-store-staging-vm, aovis-db-staging-vm, and /opt/aovis/aovis-store-staging are current infrastructure identifiers kept for operational continuity.

  • store-staging.aovis.app and similar historical staging hosts should be treated as archived references only.

  • Product-facing language should default to aovis.app as the official platform, with aovis.us / aovis.uk as regional domains.

  • Admin UI labels that refer to console scope should use internal / 内部 instead of staging when possible.