【FAQ｜问答科普】第一次使用 Noway AI 与业务看板最常遇到的 20 个问题
本页只回答已经有依据的问题。联系人、SLA 和 Noway AI 能力范围等未确认信息保持“待确认”。
AI 速览
本节主题先掌握本页结论、使用入口和关键边界。
- 先按角色和业务问题选入口，不需要学完全部看板。
- 页面刷新不等于底层数据更新。
- 同名指标必须带看板、范围和数据日期。
- Noway AI 不自动执行保存、提交、审批和批量变更。
- 正式联系人和 SLA 尚未确认。
- 正式业务数据使用 PostgreSQL 持续保存。页面可以编辑，不等于数据库已经写入成功；需验证保存后重新打开或换设备仍能按权限读取。查看保存说明与接入提示词。
1、入口选择
本节主题解决从哪里开始、Noway AI 的不同使用入口以及看板可见性问题。
1、我应该从哪个入口开始？
| 角色 | 第一站 |
|---|---|
| 运营 | 简单查询先 @Noway；目标复盘进入目标看板；FBM/FBA 可售库存问题进入双渠道可售库存看板 |
| SCM | SCM 总览、“SCM全链路总览 · 供需流速平衡测算”或 SKU 分析 |
| 产品 | 定价利润测算工具；库存、周转和补货证据由 SCM 协同核查 |
| 管理者 | 目标看板，再按问题进入月度管报或 SCM 总览；单品明细交由 SCM 核查 |
2、@Noway、“问问AI”和页面助手有什么区别？
@Noway和直接打开 Noway AI，都是使用 Noway AI。- “问问AI”和页面助手的功能会合并到 Noway AI，后续这两个旧入口会删除。
- 需要业务问答、页面辅助或上下文分析时，统一使用 Noway AI，不再从旧入口开始。
- Noway AI 可以辅助查询和分析，但不会自动执行有业务副作用的动作。
3、为什么我看不到某个看板？
SCM 菜单可能来自后端权限配置和缓存。先确认账号、角色、菜单权限和访问环境。反馈时提供账号、入口名称、访问时间和截图。
4、Noway AI 中的“亚马逊分析”能力如何使用？
打开 Noway AI 后，以当前账号可见的上下文和能力为准。页面未显示相关能力时，不把竞品 ASIN 分析作为正式使用流程。
2、数据与口径
本节主题解释更新频率、数据日期、指标公式和同名指标差异。
5、数据更新频率是实时、T+1，还是每周？
不能对所有看板使用同一个答案。需要区分页面刷新、API 查询和底层数据产出，第三项才决定真正的数据新鲜度。
⚠️ 未确认前，不统一使用“实时”“T+1”或“每周更新”作为宣传口径。
6、点击刷新后，为什么数据没有变化？
刷新通常只表示页面重新读取数据库结果。如果源数据尚未同步或数仓任务尚未产出，重新查询仍会看到旧数据。请同时检查刷新时间和页面数据日期。
7、目标看板什么时候更新？
目标看板明确标注：每日 6:00 更新，当日不统计。它适合查看截至前一日的结果，不应按当日实时监控解读。
8、“可售天数”怎么计算？
至少需要确认：
- 包含哪些库存节点。
- 使用实际、预测还是目标日销。
- 日销使用哪个时间窗口。
- 日销为 0、缺失或库存小于等于 0 时如何处理。
当前资料中可以看到“全流程库存数量 ÷ 日均销量”和“全链路库存数量 ÷ 目标日销”等不同场景。
9、为什么不同看板上的同名指标不一致？
先检查时间、时区、业务维度、库存节点、币种、日销来源、过滤条件和数据日期。对齐后仍有差异，再由指标负责人确认是口径差异还是数据异常。
3、系统关系与问题排查
本节主题说明系统数据来源关系，并给出无结果或数据不一致的排查顺序。
10、这些看板与领星是什么关系？
领星可能是部分主数据、订单、库存或业务单据的来源之一；看板还可能组合其他内部系统和数仓结果。看板不是领星页面的简单复制，也不能默认所有字段都来自领星。
11、看板数据与领星不一致怎么办？
同时准备看板与领星的页面名称、时间与时区、数据日期、店铺、国家、仓库、公司 SKU 或单号、两边筛选条件和脱敏截图。
不要在没有对齐范围和口径前直接认定其中一边错误。
12、查询没有结果，是不是系统坏了？
先检查公司 SKU、时间、国家、仓库、店铺和权限。部分筛选项中的 - 表示未归类，不等于空值。相同条件仍无结果，再按数据问题反馈。
4、权限、支持与 SLA
本节主题明确 Noway AI 操作边界、问题负责人和 SLA 当前状态。
13、Noway AI 可以直接提交方案吗？
Noway AI 可以辅助低风险浏览、查询和分析。保存、提交、审批、导出、批量工单、推送领星等动作必须由用户手动确认。
14、出了问题找谁？
| 问题类型 | 建议责任角色 | 正式联系人 |
|---|---|---|
| 数据缺失、日期未更新、源系统差异 | 数据或 ETL 负责人 | 待确认 |
| 指标定义、公式或过滤口径 | 指标业务负责人 | 待确认 |
| 页面错误、菜单和权限 | 产品或系统支持负责人 | 待确认 |
Noway AI（包括飞书群聊中 @Noway） |
Noway AI 负责人 | 待确认 |
15、响应 SLA 是怎样的？
当前没有可直接发布的正式 SLA。以下分级只用于负责人制定标准，不代表已经生效：
| 建议等级 | 判断方式 | 正式响应时限 |
|---|---|---|
| 紧急 | 核心入口不可用，阻断当天关键决策 | 待确认 |
| 高 | 关键数据异常或大范围权限问题 | 待确认 |
| 一般 | 单页面、单指标或局部用户问题 | 待确认 |
| 咨询 | 使用方法、指标解释和需求建议 | 待确认 |
16、如何申请看板或菜单权限？
看板与菜单权限统一通过飞书审批流申请。按以下顺序准备和提交：
- 进入飞书审批，发起看板或菜单权限申请。
- 填写申请账号、所属角色、看板名称、业务用途、所需数据范围和预计使用频率。
- 提交审批并通过飞书审批记录查看处理状态；私聊不能替代正式申请。
- 权限开通后，先核对菜单可见范围和页面数据范围，确认无误再用于业务判断。
⚠️ 转发链接不等于自动获得权限，也不要借用其他账号访问。
5、AI 开发会话交接
本节主题用标准提示词沉淀当前开发上下文，让新会话可以从明确的下一步继续工作。
17、如何生成开发上下文交接文档？
在当前开发会话结束或完成一个里程碑时使用。生成后先检查文件是否包含目标、已完成工作、关键决策、验证状态、风险和下一步计划。
展开完整提示词
# 角色
你是一名资深的开发会话交接专家。请将我们本次会话的内容整理成一份
《开发上下文交接文档》，供另一个 AI 会话（或另一位开发者）在全新的
上下文中直接接替开发，无需回顾本会话的任何历史。
# 整理原则
1. **接替者视角**：文档唯一读者是"对本会话一无所知的接替者"。
任何接替者必须知道的信息都不能省略；本会话中口头确认过的共识必须显式写出。
2. **事实优先**：只写本会话中实际讨论、实际确认过的事实。
未验证的猜测、未执行的计划、被否决的方案，必须单独标注，
不得混入"已完成"正文。禁止编造会话中不存在的细节。
3. **可执行性**：接替者读完文档后，不需要提问就能开始下一步工作。
# 输出文档必须包含以下章节
1. **项目与目标概述**
- 项目背景、技术栈、关键依赖版本
- 本次会话要解决的问题 / 要实现的功能（原始需求与最终确认的范围边界）
2. **已完成工作清单**
- 逐条列出：改动的文件（精确路径）、新增/修改的函数/类/DAG/SQL、
关键代码位置（文件路径:行号）
- 每条注明改动目的；会话中给出过代码的，关键代码原样保留在文档中
3. **关键决策与理由（ADR）**
- 技术选型、方案取舍、被否决的方案及原因
- 特别记录"反直觉"决策（例如某个常规做法被刻意避开的理由）
4. **验证状态**
- 已验证通过：附验证方式与结果摘要
- 尚未验证 / 验证失败的：明确列出，禁止接替者默认其可用
5. **遗留问题与风险**
- 未完成事项、已知 bug、技术债、阻塞项（在等什么）
6. **下一步计划**
- 按优先级排列的具体任务
- 第一条必须是接替者可以**立即执行**的动作
- 每项给出涉及的文件 / 表 / 接口
7. **环境与操作备忘**
- 分支状态、依赖安装情况、常用命令
- 本会话踩过的坑（错误做法 → 正确做法）
8. **参考资料**
- 本会话查阅过的文档链接、相关规范文件路径
# 输出方式（重要）
1. 将完整交接文档生成为一个 **.md 文件**直接返回给我下载，
文件名使用：HANDOFF_YYYYMMDD_主题.md（YYYYMMDD 用今天的日期）。
2. 不要在聊天消息中粘贴文档全文，不要用代码块包裹；
文档内容必须完整放入返回的文件中。
3. 聊天中只输出一行简短说明：文件名 + 包含的章节概览。
4. **降级方案**：如果当前会话不支持文件输出，则改为在聊天中
输出一个 ```markdown 代码块，内容为完整文档，并在代码块前
注明"请复制代码块内容保存为 HANDOFF_YYYYMMDD_主题.md"。
# 质量自检（输出前必须执行）
请你先以"接替者"身份通读一遍生成的文档，并回答：
若我现在开始工作，第一条任务能否直接动手？
若不能，请补齐缺失信息后再正式输出。
# 开始
请开始整理本次会话的交接文档。18、新会话如何根据交接文档继续开发？
开始新会话前先上传上一会话生成的交接文档，再使用下面的提示词。执行过程中应以当前代码、配置和运行结果为准。
展开完整提示词
你是一位接替开发的 AI 工程师。我已经上传了上一会话生成的
《开发上下文交接文档》（文件名：HANDOFF_YYYYMMDD_主题.md）。
# 你的工作方式
1. 先通读文档，用简洁清单梳理出：目标、已完成、待办、风险。
2. 从「下一步计划」的第一项开始执行。
3. 文档中的文件路径和行号可能已过期。需要查看某个文件时，
明确告诉我具体文件路径，由我粘贴文件内容给你，以实际代码为准。
4. 遇到文档未覆盖的上下文，先向我提问澄清，不要凭空假设。
5. 本阶段工作完成后，按同一份提示词一重新生成新的交接文档
（同样以 .md 文件返回），供下一会话继续使用。其他适用场景：跨文件夹承接。主要用途仍是将当前 AI 对话中的开发上下文交接给新会话。如果还需要切换工作目录，可以先使用提示词一生成交接文档，将文档放入目标文件夹，再以该文件夹作为工作目录开启新会话，并使用提示词二承接后续工作。这样可以达到跨文件夹迁移对话工作的效果，但迁移的是整理后的可执行上下文，不是原始聊天记录。
6、页面发布与数据保存
本节主题理解页面修改与真正保存的区别，使用 PostgreSQL 持续保存业务数据，并完成旧页面接入与验收。
19、为什么页面修改数据后，刷新又恢复原样？
如果旧页面只实现了显示和编辑，没有接入数据保存服务，修改的数字或文字就只在当前打开的页面中暂时生效。刷新时重新读取原始内容，修改也就消失了。
有些旧页面把内容保存在当前浏览器中，刷新后仍能看到，但换设备、换浏览器或清除浏览器数据后可能无法继续使用。这不等于正式业务数据已经保存到数据库。
页面显示“保存成功”，不代表数据库已经写入成功。正式业务数据应接入 PostgreSQL，并验证保存后能重新读取；不能只检查当前页面是否发生变化。
20、如何使用 PostgreSQL 保存页面和系统中的业务数据？
本周上线｜PostgreSQL 数据持久化
Noway AI 已支持 PostgreSQL 数据持久化：页面填写的业务数据通过服务端存入数据库，不再只停留在当前浏览器中。保存成功后，刷新、重新打开或换设备，仍可按权限读取已经保存的数据。
让页面升级为可持续使用的业务系统。不仅能展示结果，还能持续记录项目、推进任务、维护台账，支持需要长期保存数据、多人协作，以及承载更重要业务数据的页面和系统。
新能力上线，不代表已有页面自动完成接入。新页面应明确要求使用 PostgreSQL；旧页面需要改造保存与读取逻辑，有历史数据时还需先备份、迁移和核对。
正式业务数据，统一使用 PostgreSQL 保存
| 使用场景 | 保存方式 | 还需确认 |
|---|---|---|
| 个人长期使用的台账或记录 | 使用 PostgreSQL 持续保存 | 数据归属和访问权限；更换设备后仍能读取本人有权查看的记录。 |
| 多人共享的项目、任务和业务资料 | 通过服务端统一读写 PostgreSQL | 按角色控制查看与修改范围；多人同时编辑时避免相互覆盖，重新读取时展示已保存的最新记录。 |
| 承载重要业务数据的页面或系统 | 以 PostgreSQL 保存正式业务记录 | 上线前落实权限、操作记录、备份与恢复验证，并验证关键业务流程和预期访问负载。 |
一次保存，需要走完哪些步骤
- 先校验，再保存：服务端检查必填内容、数据格式和操作权限，再写入数据库。
- 成功后才提示完成：保存失败时明确报错，保留未提交内容，不显示虚假的“保存成功”。
- 重新打开仍可使用：页面从数据库读取记录；换设备或多人协作时，也只展示各自有权访问的数据。
已有页面如何改为 PostgreSQL 保存
- 盘点并备份旧数据。确认原数据保存在页面、浏览器还是原有服务中，列出字段与记录数量。若仅存在各自浏览器中，需由数据持有人先导出，不假设系统能自动取回。
- 替换保存和读取方式。保留现有页面与操作习惯，将正式业务数据的读写接入 PostgreSQL，不再把浏览器中的副本作为正式记录。
- 迁移后逐项核对。先确认字段对应关系、记录标识和重复数据处理规则；在测试环境检查记录数量、关键字段及关联关系，不直接覆盖原有数据。
- 验证通过后再切换。验证保存、重新读取和权限，确认新旧数据一致；保留原始备份和回退方案，再停止旧方式的正式写入。
重要数据上线前，还要检查什么
数据库提供持久化基础，不等于自动具备全部安全保障。访问权限、操作记录、备份与恢复能力需要在具体应用中落实和验证。
- 权限：未授权用户不能查看或修改数据，转发页面链接不应自动获得数据权限。
- 操作记录：关键新增、修改和删除应记录操作人、时间及变更内容，便于追溯。
- 备份与恢复：明确备份频率、保留周期和负责人，并实际验证备份可以恢复。
- 多人协作与版本更新：检查同时修改、保存失败和重复提交；更新程序或调整数据结构前先备份并测试，不用测试数据覆盖正式记录。
可以这样告诉 Noway AI
展开 PostgreSQL 接入与旧数据迁移提示词
请使用 Noway AI 已支持的 PostgreSQL 数据持久化能力，为以下页面或系统实现正式的数据保存与读取。
业务场景：[页面或系统用途]
项目情况：[新建页面 / 改造已有页面]
需要保存的数据：[业务对象、字段及关联关系]
原数据位置：[无历史数据 / 当前浏览器 / 文件 / 已有保存服务]
使用角色：[谁可查看、谁可新增修改、谁可删除]
重要数据要求：[权限、操作记录、备份频率、保留周期及负责人]
请按以下顺序实施：
1. 先检查现有页面和数据来源，梳理字段、记录标识、角色权限与读写路径。缺少规则时先列出待确认项，不猜测业务口径。
2. 通过服务端 API 读写 PostgreSQL，校验数据和权限。数据库连接信息仅保留在服务端，不放入网页、前端代码或公开文件；不把页面临时状态、localStorage 等浏览器存储当成正式业务数据源。
3. 保留现有页面的布局和操作习惯。仅在数据库写入成功后提示完成；保存失败时明确报错并保留未提交输入。防止重复提交，并明确多人同时修改同一记录时的冲突处理方式，不静默覆盖。
4. 有历史数据时先备份，确认字段映射和去重规则，在测试环境迁移并核对记录数量、关键字段与关联关系。仅存在个人浏览器中的数据，应先由持有人导出；不要声称可以自动收集所有人的本地记录。
5. 按已确认的要求落实访问权限、关键操作记录和备份恢复方案。更新程序或数据结构前先备份与测试，不用测试数据覆盖正式业务数据。
6. 验收新增和修改后刷新、重新打开页面、换设备仍能按权限读取记录；验证未授权访问被拒绝、保存失败有提示、重复提交不产生重复记录、多人修改不会静默丢失。
7. 对重要数据，在测试环境实际验证备份恢复和关键业务流程。先说明迁移、切换和回退方案，经我确认后再切换正式数据的读写方式。
请区分已经实现并验证的能力与仍需配置的项目。如果当前应用无法接入 PostgreSQL，请说明具体阻碍，不生成伪保存功能。问题反馈模板
本节主题按统一字段提供问题证据，减少重复沟通。
入口或看板：
发生时间：
账号与角色：
筛选条件：
数据日期：
公司SKU/SPU/业务单号：
异常表现：
预期结果：
脱敏截图：