定义决策问题与数据边界

先告诉 Noway AI 页面最终要支持什么决策，同时明确对象、时间范围和不能混用的口径。

分析这份竞对流量文件，目标是判断双方的流量差距，并形成后续投放动作。

请先说明各子表的分析对象、时间范围、字段含义和可比口径；不同对象的数据不要合并解释。

先校正分析结论

把标签规则和必需字段补齐，让 Noway AI 先回答核心问题，不急着生成完整页面。

按照备注中的标签定义解析数据，并保留关键词、排名、流量占比、自然位和广告位等关键字段。

先分别总结总量差距、流量结构差距和关键词覆盖差距，列出计算依据；无法确认的字段请明确标出，不要自动推断。

指定页面的信息结构

分析方向确认后，再要求 Noway AI 按业务阅读顺序组织页面，而不是堆叠一段长回答。

不要继续输出聊天式长回答，请将结论整理为一页式业务页面。

页面依次包含：核心总览、流量结构、关键发现、关键词机会、执行策略和数据口径。首屏先展示结论与关键指标，明细和口径放在后面。

把明细做成可操作组件

通过下一轮对话补充真实使用需要的筛选、排序、导出和导航能力。

将关键词和策略明细改为可操作表格：支持逐列筛选和排序、冻结第一列，并可导出当前可见数据。

增加清晰的页内导航；所有交互都要保留当前筛选结果，长表格在桌面端和移动端都应可读。

增加协作标注

让团队可以围绕具体数据行记录判断，并从标注总览返回原位置继续跟进。

为每条明细增加协作标注，支持“重点投放、继续观察、排除、需复核”多选标签和备注。

页面顶部增加标注总览，并支持只看已标注数据；点击标注时应定位回对应板块和数据行。

校正视觉层级与页面体验

最后一轮只处理信息层级、重点强调和响应式效果，避免视觉调整改变业务结论。

统一页面的标题层级、间距和颜色：结论、风险、机会和行动要能快速区分，关键数字使用强调色。

减少无意义卡片，不改变数据和口径；检查桌面端与移动端，确保标题、表格、按钮和标注窗口不重叠。

先确定执行时间与汇总范围

把执行频率、时区和统计区间写成明确规则，避免“昨天”产生歧义。

创建一个群聊摘要任务：工作日北京时间 9:30 执行，汇总前一天北京时间 00:00 至 23:59 的群聊信息。

限定唯一的目标群

明确只能读取当前业务群，不能将其他群或独立附件中的信息混入摘要。

本任务只总结指定群聊的实际消息。发送前必须核对目标群，不得引用其他群的对话或独立附件内容。

定义需要保留的业务信息

让摘要围绕决策和跟进，而不是简单压缩聊天文本。

摘要必须覆盖：主要议题、关键结论、已经确认的决策、待办与负责人，以及当天出现的文件、文档、表格和业务链接。

把输出格式写成固定契约

通过示例规定日期、小标题和段落间距，减少每天输出风格漂移。

第一行只显示加粗日期，例如 2026/09/02；一级小标题使用【】并加粗，段落之间空一行。

不要输出“群信息概览”、来源、口径、限制、验证方式或系统署名。

合并重复任务

保留真正需要的前一日汇总，暂停内容重叠的当天汇总任务。

只保留工作日 9:30 的“前一日对话汇总”。暂停工作日 18:30 的“当日对话汇总”，避免同一批信息重复发送。

增加发送前检查与专题追问

每次发送前核对目标群、日期和格式；需要时再从群历史中提取某一专题。

发送前依次检查：目标群是否正确、日期范围是否正确、格式是否符合模板、待办是否有明确依据。

当我指定某个主题时，从当前群历史中单独整理相关进展、处理标准、风险和待办。

定义市场范围与决策问题

不要从“帮我分析市场”开始，而是先确定站点、品类、统计周期以及看板最终要支持的业务判断。

分析【Amazon US】的【行李箱】市场。统计周期统一为近 30 天，重点回答：市场规模多大、资源应优先投入哪些赛道、哪些价格层值得测试，以及头部品牌和单品依赖是否构成风险。

建立可复现的竞品集合

固定搜索词、页数、自然位规则和变体处理方法，避免每次查询得到不同口径的竞品池。

使用【12 个核心搜索词】建立竞品集合，每个词采集前【4 页】结果。排除广告和明显非同类商品，父 ASIN 与子 ASIN 分开保留；补录全部公开变体后按子 ASIN 去重，并记录每条样本的来源。

补齐经营字段与产品结构

把查询结果从 ASIN 清单扩充为可以计算的市场数据，并让分类字段直接服务于后续筛选。

为样本补齐品牌、父子 ASIN、实际售价、近 30 天销量、月销售额、评分和评论数；进一步识别尺寸、套装、材质、开合结构和赛道标签。无法确认的值保留缺失，不要根据相邻字段猜测。

校正分析口径与初步结论

先检查销量换算、销售额计算、去重和分类结果，再判断规模、价格机会和供需效率。

销量统一换算为“近 30 天预估销量 ÷ 30”的日均值；月销售额按实际价 × 近 30 天销量计算。输出每个结论使用的样本数、公式和筛选范围，并列出需要人工复核的分类。

让 Noway AI 生成决策型页面骨架

页面先回答“现在应该看到什么”，再提供图表和明细，避免把所有数据平铺成报表。

生成品线决策看板。页面顺序为：全局筛选、核心指标、品线负责人决策提示、数据快照与口径、价格与品牌结构、细分赛道、品牌布局、赛道经营矩阵、价格与销量分布、头部商品风险、月度趋势。

核心指标必须包含日均销量、月销售额、加权成交价、活跃品牌、品牌 CR5 和 Top10 单品依赖。

补充筛选、排序和结果跳转

让页面能够围绕具体赛道继续下钻，而不是只保留一张静态总结图。

增加一级、二级、三级赛道、尺寸、材质、开合结构、结构标签和品牌筛选；筛选后自动重算全部指标与结论。表格支持排序，头部商品可以打开 Amazon 页面。最后检查桌面端与移动端布局，不得改变数据和计算口径。

定义每日同步闭环

先说明每天需要同步哪些活动、发到哪些群，以及消息发出后如何继续跟进。

我要把 AM 活动台账转化为每日群聊同步。流程必须覆盖：筛选当日活动、匹配目标群、按群生成摘要、发送飞书消息、记录发送结果和回收后续状态。不同业务对象的活动不得混发。

建立活动与群聊映射

让活动归属和目标群成为明确字段，避免发送时依赖临时判断。

活动记录至少包含：站点、活动类型、商品组、状态、开始时间、结束时间、时区、风险、待处理事项、业务对象和目标飞书群。无法匹配目标群的活动进入异常清单，不允许默认发送到其他群聊。

按同步动作组织页面

页面先回答今天要同步什么、发到哪里和还有什么未处理。

页面依次呈现：
1. 今日同步概览：活动数、目标群数、异常数和发送状态；
2. 活动范围：按站点、商品组、活动类型和状态筛选；
3. 分群摘要：每个目标群独立预览活动内容与待处理事项；
4. 推送记录：展示发送时间、目标群、结果和失败原因。

增加发送前检查

把缺少目标群、时间异常和活动冲突前置到推送之前。

发送前检查：活动字段是否完整、是否匹配唯一目标群、时间是否有效、当前状态是否需要同步，以及 Coupon、价格折扣、BD、PD 是否可能冲突。检查结果分为“可发送”“需确认”和“禁止发送”。

生成每日分群摘要

同一目标群的活动合并展示，不同群聊分别生成消息。

每天生成一次 AM 活动摘要，并按照目标飞书群分别汇总。每条活动写明站点、商品组、活动类型、时间、当前状态、风险和待处理事项，同时保留以下节点检查：
- T-24h：检查活动状态、价格、数量和后台报错；
- T-2h：确认 Coupon、价格折扣、BD、PD 无冲突叠加；
- 开始时：确认活动正常上线；
- 结束后：确认价格或折扣恢复；
- 每日汇总：同步当日及次日需要关注的活动。

补齐推送记录和发布要求

群聊同步需要留下结果，失败时能够明确定位并重新处理。

将活动、群聊映射、提醒设置和发送记录保存到持久化存储；每次发送记录目标群、时间、结果和失败原因。页面部署在固定子路径下，Webhook 等敏感配置不得回显到页面或公开接口。

先让 AI 学习人工模板

本轮目标：不只指定结果样式，还要识别数据如何匹配、公式如何填写、空值如何显示。

请先读取我上传的人工确认模板和本期原始 Excel；缺少任一文件时，先列出需要补充的材料，不要开始清洗。分析模板的工作表、列顺序、筛选条件、关联字段、公式及格式。重点说明未匹配记录和空值如何处理。列出规则供我确认，不要自行补充业务口径。

形成明确的输出标准，而不是一句“按模板整理”。

明确代码执行规则

进入清洗前，先核对代码与模板的处理要求。案例中，李春华提供 物流信息清洗.py 作为执行标准，固定输出列、公式、到货时间处理和工作表范围。复用时，应将这份已确认的规则提前提供给 AI。

处理前明确执行依据，后续纠错同步更新规则。

按规则生成清洗结果

本轮目标：按照已确认的代码规则处理新文件，检查输出是否符合模板要求的字段结构与公式。

得到可逐项检查的报表，再由实际问题推动修正。

纠正操作细节

对话中，空白匹配结果曾被显示为 0。李春华明确指出：“实际运输方式”应按模板显示 -。用具体字段、触发条件和目标结果说明问题，便于统一修正同类记录。

从修一个单元格，转为修正一类记录的处理方式。

让 AI 对比人工修正版

李春华进一步上传人工修改后的文件，让 AI 与上一版逐项比较。“实际到货时间”的处理因此被重新校正，避免把所有未匹配情况一律留空。

我将提供 AI 处理版、对应的人工修正版、原始文件和当前清洗代码，并注明各文件用途。先核对材料是否齐全；缺失时先说明。请对比处理版与人工修正版，逐项列出修改位置、原值、新值和触发条件。将这些差异提炼为规则，供我确认后更新清洗代码，再从原始文件重新清洗。不要只修改已指出的几个单元格。

人工修正成为规则样本，下一次不必重复解释同一个问题。

用下一期文件检验复用能力

在后续“物流信息9.8”任务中，继续沿用已确认模板处理新文件，形成了新的清洗结果。复用的对象是处理规则，不是上一期的业务数据。

我将提供新一期原始文件、最新确认的清洗代码、输出模板和本期截止日期。先核对这些材料；若有缺失，先说明，不依赖旧会话记忆补充。按提供的规则、公式和格式处理，使用本期截止日期。检查本期输入的工作表是否齐全；遇到缺失或结构变化先说明，不要从上一期复制业务明细补齐。输出清洗结果和检查汇总。

验证相同流程能否处理新的输入，而不只是在旧文件上修补。

生成可复用 SOP 文档

完成规则校准和复用验证后，可让 AI 将规范好的操作流程固定成文档。将输入要求、执行顺序、例外条件和交付检查集中保存，新会话即可按文档继续处理。

请基于当前对话中已经确认的表格清洗流程、最终代码和检查标准，整理可复用的 SOP 文档，供新会话独立执行。若当前对话缺少这些内容，请先列出需要提供的材料，不要推测或补造操作规则。

文档需包含：
1. 适用范围及不处理的内容。
2. 输入文件、工作表、必需字段、模板和清洗代码要求。
3. 按顺序执行的操作步骤，包括筛选、关联、空值处理、公式填充和格式整理。
4. 已确认的纠错规则、异常处理条件及需要人工确认的情况。
5. 交付前检查项、通过标准、输出文件命名和交付内容。
6. 新一期任务的启动提示词，以及需要重新提供的文件清单。

以最终确认的规则和代码为准，剔除已废弃做法，不依赖当前对话记忆；没有确认的内容不要补写为既定规则。生成 Markdown 文档供我检查。

后续可将 SOP、对应代码和新一期数据一起提供，实现跨会话复用。

先定义“项目、流程、节点、角色”之间的关系

不要只要求“做一个产品管理系统”。先让 AI 梳理不同开发类型的路径，再确定一个项目需要保存哪些信息、每个节点如何分工。

根据我提供的产品开发要求，先梳理系统结构，不急于生成页面。
区分项目、产品、流程模板、流程节点和用户角色，列出各自的字段及关联关系。
按不同开发类型整理阶段和节点；每个节点说明责任角色、输入资料、计划时间、完成条件、确认要求和后续推送对象。
明确哪些信息来自原始资料，哪些规则需要我补充。不要用同一套固定流程覆盖所有开发类型。

这一轮明确：页面背后的业务对象和规则，而不是只有菜单名称。

用“进入系统后要完成什么”定义页面结构

工作台先回答“我现在该做什么”，项目中心用于查找和比较项目，项目详情承接具体处理。对话中的按钮无响应、导航排列等反馈，也推动页面从可看走向可用。

按照已确认的业务结构生成管理系统。
个人工作台优先展示我的项目、待处理节点和风险；项目中心支持搜索、筛选及阶段视图；项目详情提供概览、开发流程、产品定义、样板与测试、问题与风险和项目记录。
明确“从待办进入项目，再进入当前节点”的操作路径，不让用户反复查找。
所有展示出来的按钮都应有对应交互；导航、筛选、查看详情、关闭弹窗和返回列表需逐项检查。标题、状态、责任人和主要操作要有清晰层级，窄屏不能遮挡正文。

这一轮形成：按任务组织的工作入口，以及可进入详情的操作路径。

让节点不仅有名字，还能表达计划、责任与状态

系统按开发模式区分流程模板；项目内的节点展示计划与实际时间、责任方、推送方及处理状态。这样才能判断“当前卡在哪里”和“下一步交给谁”。

为不同开发类型配置独立流程模板，创建项目时生成该项目自己的流程实例。
按目标上市时间和已确认的节点时长安排计划，展示阶段、当前节点、计划与实际完成时间。
每个节点显示责任人、完成条件、确认角色和下一环节推送对象；需要多人确认的节点单独展示确认进度。
明确完成、退回、撤回和跳过的适用规则及权限。状态变更后关联更新项目进度和相关人员待办，并保留操作记录。
不得因为修改公共模板而无提示地覆盖已有项目记录。

这一轮落实：从阶段展示，进一步进入责任明确的节点管理。

让任务沿着责任分工流转

流程推进不仅要展示状态，还要把需要处理的事项交给对应负责人。待办围绕项目参与关系和节点职责组织，让相关人员知道需要处理什么、完成后交给谁。

按项目参与关系和节点职责组织待办，将需要处理的事项关联到对应负责人。
待办区分立即处理、今日优先和近期处理，展示项目、节点、责任角色及截止时间，并提供直接进入节点的入口。
节点完成后，按流程规则关联下一环节负责人；退回、撤回或修改时，同步更新相关待办，避免旧任务继续提示。
保留交接和操作记录，保存失败时明确提示，不显示虚假的成功状态。

这一轮形成：个人待办与角色分工相匹配的协作入口。

把流程记录、附件与产品矩阵放回业务对象中

项目推进需要资料支撑，产品规划还需要横向比较。后续迭代围绕附件、图片、相关看板以及颜色 × 尺寸的产品矩阵继续补充，使进度和产品信息不再割裂。

在已有项目和节点结构中补充资料管理，不另建一套重复的项目数据。
节点资料支持追加附件、查看图片及下载原文件；上传失败时保留已有资料，修改或撤回需遵循角色权限并留记录。
增加产品矩阵：按品类、品线、产品、市场和数据期次筛选，以颜色与尺寸交叉展示变体、产品图、开发或销售状态及对应指标。
分别标注实际数据、预估值、统计口径和数据期次；提供矩阵导入及历史版本入口，避免新数据覆盖旧期次。

这一轮扩展：既能按项目推进，也能按产品组合进行查看和规划。

接入 PostgreSQL，让记录不止停留在页面上

本周新支持使用 Noway AI 的 PostgreSQL 数据存储能力，将项目、节点状态及附件等业务数据交给数据库保存。页面刷新或重新打开后，仍能继续读取已经保存的记录。

为当前管理系统接入 PostgreSQL，持久化保存项目、产品、流程节点、操作记录及附件数据。
页面操作通过服务端读写数据库，不把浏览器临时状态当成正式业务数据。
只有数据库保存成功后才提示完成；失败时清晰报错，保留未提交的输入供修正。
验证新增和修改后的记录在刷新页面、重新打开页面后仍可读取，附件也能继续访问。
更新程序时保留已有数据库和业务记录，先备份、在测试环境验证，再进行必要的数据迁移。

这一轮补齐：让一次生成的页面，具备持续积累项目资料和处理记录的能力。

具体描述问题，让 AI 修改后按场景复测

“按钮点不动”“当前节点难以查找”“导航排列不合理”等具体反馈，比笼统的“再优化一下”更容易转成可验证的修改。随着系统持续使用，还需要检查数据保存与版本更新不会破坏已有记录。

根据以下使用反馈修改系统：
操作入口：[页面及按钮]
当前现象：[实际发生的情况]
预期结果：[希望页面如何响应]
受影响角色：[项目责任方或协作人员]

先解释原因和修改范围，再在独立测试环境实施。逐项验证导航、筛选、项目详情、节点处理和附件操作。
检查保存成功后刷新或重新打开页面，记录是否仍能正确读取；保存失败时要明确报错。
发布前保留可恢复版本，只更新已确认的程序和必要变更，不用测试数据覆盖现有业务数据。验收通过后再更新正式系统。

这一轮沉淀：以实际操作结果为依据的持续迭代方式。

明确原表哪些内容不能改变

结果仍要沿用原表交给操作人员，而不是另做一张替代原表的简表。先将保留字段、允许调整项和交付格式说清楚，避免 AI 为了展示效果改变业务内容。

我将提供原始明细、辅助明细和人工确认的输出样板。请先检查材料是否齐全，列出文件之间的关联字段、必须原样保留的内容、允许拆分或合并的范围，以及需要我确认的规则。不要先重排整张表，也不要根据缺失数据猜测业务结果。规则确认后，先处理一个样例供我核对。

先明确输出契约，再开始处理数据。

从商品总量细化到装箱明细

通过人工样板把“填写备注”的模糊要求逐项说清：按实际装箱拆分数量，同箱明细相邻排列，贴标顺序和备注合并显示。先处理一个样例核对，确认后再扩大范围；具体字段与合并写法以人工确认的样板为准。

规则逐项落到样例，人工确认后再推广。

增加可重复使用的文件上传页

多轮调整后，需求由生成一次文件转为提供固定处理工具：一份出货明细与多份装箱单分别上传，按已确认规则生成结果，不覆盖原始文件。

请将本次已经确认的表格处理规则制作成自助网页工具。开始前，先核对最终规则、示例输入和输出样板；缺少材料时先说明。
分别提供主明细文件和辅助文件的上传区域，支持辅助文件多选；标明可接收的文件类型。点击生成后按确认规则处理，不覆盖原始文件。页面需要显示处理状态和异常原因，提供结果预览与 Excel 下载入口。不要在工具化过程中改变业务规则。

将每次重复说明的规则固化到工具中。

一个链接、两个页签

上传页与展示页合并到同一链接下，用“上传数据”和“成品展示”两个页签组织；生成成功后更新并切换到本次结果，预览与下载对应同一批数据。

页面围绕“提交、查看、交付”组织，不必来回寻找不同链接。

把 Excel 下载纳入使用流程

最终交付是下载 Excel 并发送给供应商操作人员。网页预览不是终点，导出文件也要保留已确认的列、数量、箱号和合并关系，预览与导出文件一并验收。

验收覆盖网页展示与实际交付文件，而不只是页面能打开。

列出港口组合与必需字段

先明确起运港、目的地和查询时间范围，再要求整理船名、航次、开船日、到港日、航线、联盟与运力等字段。没有取到的数据保留原因，不能直接解释为“没有船期”。

请根据我提供的起运港、目的地、日期范围和允许使用的数据来源，制定船期信息整理方案。
先列出查询组合、来源覆盖范围、需要的访问权限，以及拟保留的字段。至少区分原始字段、计算字段和数据来源。
无法访问、查询失败、来源未覆盖、成功查询但没有记录，应分别标明，不要填成相同的空结果。先提供少量样例核对，确认后再扩大范围。

将模糊的“查船期”转成清楚的查询范围和字段清单。

先核对覆盖范围，再确认计划字段

初次整理后，继续检查是否遗漏后续分页、港口代码是否对应正确目的地。本案例通过修正港口标识和补充分页，完善了纽约、坦帕等目的地的船期资料；内陆目的地另行核实转运来源。

确认覆盖后，保留来源提供的 ETD 与 ETA，再按业务要求增加出货 DDL、周次和预计到货等计划字段。这一步的重点不是记住某个提前天数，而是要求 AI 先列出所有待确认参数，由使用者逐项给出定义，避免 AI 自行选择行业默认值；计划参数只是内部安排参考，不是承运方承诺。

初次整理后，先检查是否遗漏后续分页、港口代码是否对应正确目的地，区分查询失败、来源未覆盖与确实无记录，避免只取得部分记录。
再确认日期与计划字段：保留来源中的预计开船日 ETD 和预计到港日 ETA，不要覆盖原值。根据我确认的出货提前天数和到港后预留天数，增加出货计划截止日、预计到货日。周次按我确认的日期字段计算，并明确是否采用 ISO 周。
先列出字段公式、跨年处理和缺失日期的处理方式，提供样例供核对。没有确认的参数先询问，不要自行选择行业默认值。页面中区分来源日期与内部计划日期。

在生成页面之前，先确认数据覆盖范围与日期口径。

将高频筛选放在顶部，按航线组织明细

先建立顶部筛选、结果数量、航线分组、船期表格的阅读顺序，再补充 ETD、出货 DDL、ETA 和预计到货的范围筛选。查找一条船期时，可以结合船名、航次和港口缩小范围。

请使用已确认的数据与日期规则生成网页看板。
顶部集中放置起运港、目的地、周次、联盟和日期范围筛选，提供重置入口；明细按起运港与目的地分组，展示船名、航次、ETD、ETA和已确认的计划字段。
筛选条件需要联动，展示当前结果数量；无结果时明确提示。长表格允许横向滚动，顶部筛选不得遮挡正文，移动端不应挤压到无法操作。不要为了布局修改数据或计算口径。

从一次性表格，变成可以反复查询的页面入口。

从单条船期扩展到周次趋势与运力周报

增加“船期明细 / 周次运力趋势 / 容易船期运力看板”三个视图。明细解决查找，周次趋势解决比较，周报视图补充报告中的计划与实际运力信息；周报使用独立的批次、港口和区域筛选。

在现有明细页中增加周次趋势和运力周报两个视图，保留原有明细与筛选功能。
周次趋势按已确认的日期口径分组，提供按起运港、目的港的运力对比和船期数量统计，并保留汇总明细。先确认同船同航次的重复记录如何处理，未确认前不要直接累加。
运力周报使用独立的数据集和报告批次，保留原报告中的计划运力、实际运力、单位及比例口径。按批次、港口、区域筛选，不将不同批次默认叠加；风险阈值由我确认后再高亮。

不同视图回答不同问题，共用入口但保留各自的数据口径。

将交互与样式问题集中在一轮处理

周次和联盟选项增多后，平铺选择项占据过多空间。把这类调整集中在一轮完成：改为可全选、清空的下拉多选，按钮显示当前选中状态；补充“剔除运力为 0”的开关，并优化连续筛选的响应。逐项单独调整，容易打断整体结构。

保留选择能力，同时减少页面拥挤与重复操作。

更新数据时，保留已确认的页面能力

把获取数据、核对批次、生成结果、检查页面串成固定流程。船期数据可直接从官网自动更新，AI 按已确认的规则自动完成标注与清洗，人工只需核对关键结果；每次更新都核对来源时间，并检查筛选、多视图和日期计算没有被旧模板覆盖。

维护的不只是新数据，也包括可持续使用的页面。

把会议讨论变成可执行的业务标准

先将会议纪要交给 AI，整理订单履约链路、每日检查步骤、关键指标和异常分类。把分散的讨论转换成流程说明，为后续项目结构提供基础。

请根据我提供的会议纪要和业务材料，整理一份业务流程与监控标准。
按“业务目标、流程节点、关键问题、相关指标、异常判断、处理动作”组织内容，并保留各项规则在材料中的依据。
区分材料明确提出的规则、AI 的补充建议和需要业务确认的问题。不要把举例数字当作实际结果，也不要把讨论中的设想写成已经实现的能力。
先输出结构与待确认事项，确认后再形成完整文档。

从会议内容中提炼可以继续讨论和确认的业务标准。

让每个模块回答真实的经营问题

在流程标准上继续补充业务背景，将“订单有没有发出去”扩展为成本为什么偏高、准达为什么变化、哪个仓或渠道需要关注。形成时效、成本、绩效与仓网等分析模块，而不是直接堆叠图表。

基于已确认的流程标准，补充经营分析结构。对每个模块说明：
1. 要回答的业务问题。
2. 需要观察的指标和比较维度。
3. 需要的原始字段、数据来源及时间范围。
4. 发现异常后需要进一步核实或处理的内容。
先覆盖日常最常用的问题，避免只列指标名称或堆砌图表。没有数据支持的分析单独列出，不生成推测数值。

让每个页面模块都对应明确的业务问题。

让已确认内容可交接给实现工具

把前期确认的内容写入项目目标、模块清单、指标口径、字段需求和页面结构，再交给编码工具实现。业务需求不再依赖某一段聊天上下文，后续调整也能回到同一份文档核对。

请将已经确认的业务结构整理成 Markdown 需求文档，供后续编码工具实施。
文档包含：目标和范围、输入数据、字段映射、指标公式与统计样本、页面模块、筛选与交互、异常状态、验收样例。
明确本次实施内容与后续规划。缺失字段和未确认规则单列，不自动补齐。页面模块需要说明“用户要看什么、能操作什么、操作后如何验证结果”。
先提供文档供审查，不直接修改系统或发布页面。

形成业务与实现共同使用的需求依据。

让页面指标经得起数据核对

将结构文档与实际订单数据入口交给编码工具，先核对统计范围、订单粒度、节点时间和费用口径，再形成指标和页面。订单侧单均成本、账单综合履约成本、配送票均分别展示，不能仅因名称相近就视为同一个指标。

请依据已确认的需求文档，检查我提供的数据表、字段说明或样例文件。
先给出字段映射、统计粒度、时间范围和指标计算方式，再用少量样例核对结果。订单数、包裹数、妥投样本及有承诺时间的样本需要分别说明。
来源不同或分母不同的费用指标应分别命名；缺失字段明确标记，不推算替代。
样例确认后再生成页面。保留数据批次与口径说明，不修改源数据。

将文档中的业务概念落实到可核对的字段与结果。

让总盘、执行与复盘各看所需

页面按三类任务组织：总盘监控比较成本、时效和稳定性；执行履约监控查看出库、上网和妥投环节；经营复盘按自然月观察变化。高频筛选集中在上方，详细分析按需展开。

请将已确认的数据与指标组织成三个可切换视图：
- 总盘监控：核心指标、主要变化、可切换维度的对比表。
- 执行监控：流程节点表现、环节耗时、按责任对象比较的明细。
- 经营复盘：独立选择自然月，与上月比较，展示趋势、问题和后续行动。
共享适用的业务维度筛选；复盘月份与日常查询时间窗分别标明。切换视图后保留已选维度，并确保标题、统计样本与展示结果一致。
核心内容优先展示，低频明细按需展开；不要为了视觉调整改变计算规则。

同一套数据围绕不同任务展示，减少查找负担。

让看板可以反复使用与迭代

围绕实际查看动作完善多选筛选、表头排序、维度切换和分段时效对比。再将筛选样例、指标校验与页面检查整理为复用要求，后续新增数据或调整模块时按同一标准核对。

请检查并完善现有页面，不改变已确认的业务口径：
1. 多选筛选、应用与重置操作应同步影响对应指标、表格和图表。
2. 表头支持升降序排序，汇总行与明细一致；长表允许横向查看。
3. 时效对比明确起止节点、统计样本和单位，样本不足不输出误导性排名。
4. 按我指定的筛选组合核对结果，并检查无数据、缺失字段及移动端布局。
将通过条件和异常处理方式整理成验收清单，与需求文档一起保留。

把一次页面交付，变成可以持续核对与迭代的工作成果。