夜雨聆风@万能的插件 帮我分析一下这几份数据，告诉我结论。
这相当于请来一支专业团队，只递给它一张写着“看一下”的便利贴。
这次给出Codex数据分析最该装的插件清单，同时以 Data & Analytics 插件为例，在一个真实的业务场景上，逐条说明使用插件有哪些注意事项，怎么更好的激发插件的能力。
先看常用数据分析该装哪些插件
别背“必装榜”，按分析链路的 6 层能力选，真正专业的选法不是“看到名字就全装”，而是先判断自己缺的是哪一层。
第 1 层：业务材料与上下文
Google Drive 适合读取表格、指标文档、复盘材料和业务说明。它解决的是“分析依据散在哪里”，不是替你计算指标。
如果团队的事实材料主要在 Drive、Docs、Sheets 或 Slides，这一层优先级很高；不使用 Google 工作区，就选择自己实际所在的资料系统。
第 2 层：产品行为数据
Amplitude、Mixpanel、PostHog 都属于这一层。它们直接面向事件、漏斗、留存、路径和用户行为，但通常是同层替代关系。
公司已经使用哪一个，就连接哪一个。把三个全装上不会让漏斗更准确，只会增加口径冲突。
第 3 层：治理与指标语义
Alation、Atlan 负责帮助团队找到可信数据资产、指标定义、血缘和治理上下文。它们解决的是“哪个口径可信”，不是替代产品分析或通用分析。
企业没有部署对应平台时，不需要为了显得专业而安装。
第 4 层：直连查询与数据源
Supabase、BlazeSQL、CData Connect AI 等更接近数据库或查询入口。适合已经明确知道数据在哪里、需要直接查询或连接受控数据源的团队。
这一层必须先确认权限、表粒度和语义，不能把“连得上”当成“算得对”。
第 5 层：分析、验证与报告
Data Analytics 是这次实测的主角。它适合把数据检查、产品或经营分析、指标诊断、Notebook、图表、报告和验证串成一次可复核交付。
它不是所有数据系统的替代品，而是把已经取得的数据和上下文组织成分析过程。
第 6 层：代码沉淀与发布
GitHub 负责 SQL、Python、Notebook、测试和版本；Vercel 或 Sites 更适合把已经验证的结果继续做成可访问的数据应用、报告或内部工具。
这层解决的是“分析怎样复用和交付”，不是让 AI 再算一遍。
六层能力可以记成：
业务上下文：事实材料在哪里产品数据：用户行为发生了什么治理语义：哪个口径可信查询入口：从哪里取得受控数据分析验证：这个结论为什么能信工程交付：怎样复用、协作和发布
成熟分析师不需要一张“十个必装插件”名单。更稳的组合通常是：每个实际缺口选一项，同层只保留与你现有技术栈匹配的工具。
再把插件讲透：它不是聊天框里的新按钮
官方把插件描述为围绕一个工作流打包的能力。一个插件可能包含 Skills、Apps 和 App templates。
翻译成人话：
- Skill 像岗位手册：规定任务怎样拆、先检查什么、怎样验证、最后交付什么；
- App 像数据和动作通道：连接云盘、代码库、数据仓库或其他经过授权的系统；
- Plugin 像完整工作编组：把这些能力围绕一个结果组织起来。
Data Analytics 值得学，是因为它不只追求“回答一个问题”，而是尝试完成一条更完整的链路：
理解业务决定→ 检查数据是否可用→ 计算并保留口径→ 生成图表或报告→ 独立验证→ 交给人做最终判断
安装插件不等于自动获得数据权限。需要 Google Drive、GitHub、BigQuery 或企业数据平台时，底层 App 仍然要单独连接；你原本看不到的文件，插件也不应该让你越权看到。
截至 2026 年 7 月，OpenAI 已将原 App Directory 迁移为 Plugin Directory。是否能安装和调用，仍取决于套餐、地区、工作区设置、角色、使用界面和底层 App 权限。
官方说明：
Plugins in ChatGPT and Codex Codex for every role, tool, and workflow
同一批数据，普通模式先跑一次
这次使用四个固定随机种子生成的模拟文件：
订单明细； 商品与成本； 渠道周花费； 数据字典。
问题保持简单：
请分析这组零售数据，告诉运营负责人下周哪个渠道应该增加预算、哪个应该暂停扩量，并给出一份可以直接转发的报告。
普通模式的真实网页回答如下。
它的优点很明显：
使用了净销售额、商品贡献和渠道花费； 主动排除了未结束的自然周； 给出了可直接阅读的周报； 最终建议是付费搜索增加、付费社交暂停。
如果只看文字完整度，这已经是一份不错的回答。问题出在它没有先回答：原始数据能不能直接算。
普通回答说，付费社交最近四周渠道贡献约负 3.6 万元，因此“已经出现持续亏损”。但原始渠道花费表里存在重复的渠道周键。如果直接把重复花费相加，成本会被算两次，贡献自然被压低。
于是出现了一个非常危险的结果：
最终方向碰巧没错，支撑方向的关键数字却错了。
它还没有明确识别：
重复订单明细； 折扣率同时出现小数和整数； 退货数量大于购买数量； 商品成本关联缺失； 联盟渠道花费缺失； 渠道周花费重复。
这些问题不是“报告后面补一句风险提示”就够了。它们会直接改变收入、成本、贡献和预算动作。
Data & Analytics 插件使用三步走：
更专业的用法不是把所有要求塞进一条巨长提示，而是让每一轮都留下独立产物。
第一轮：数据质量门
先不要给预算结论。确认每份数据的粒度、主键、日期范围、单位和连接关系；检查重复、缺失、异常退货、折扣单位混用、成本覆盖、渠道周花费重复或缺失，以及未结束周期。输出数据质量清单、受影响指标和待确认字段。字段语义不清时保持未知，不自行补零。
这一轮只回答“数据能不能用”。输出是质量清单、处理建议和需要人工确认的字段。
第二轮：决策分析
基于已经确认的数据处理规则，支持运营负责人决定下周渠道预算。分别按“截至当前已确认退货”和“完整退货”两种窗口，计算渠道净销售额、贡献、ROAS、退货率和成本覆盖率。保留公式、过滤范围和分母，生成可从头运行的 Notebook、比较图和预算建议；说明两种口径是否改变动作。
这一轮才回答“应该怎么做”，并把数字、公式、图表和动作放在同一条证据链里。
第三轮：独立验证
不要沿用上一轮结论，独立复算付费社交最近四周渠道贡献。重新检查重复花费、退货截点、成本缺失、周窗口、连接前后行数和关键分母，并给出替代解释。用“完全通过 / 带着边界分享 / 需要修改”评估是否可以对外分享，列出必须披露的边界和仍需负责人确认的问题。
这一轮不再生成更多观点，而是主动寻找能推翻前一轮结论的证据。
它多检查了什么
原始订单明细共 22,510 行。真实插件报告没有只写“发现异常”，而是给出了数量和处理方式：
75 条完全重复的订单明细，去重； 18 条折扣率为 15 的记录，暂按 15% 规范化并做敏感性检验； 15 条退货数量大于购买数量、14 条正退货没有日期，从净额指标中排除； 173 条退货发生在 6 月 24 日截点之后，不计入这份截至当日的快照； 28 条商品成本缺失，净销售保留，贡献只按已知成本计算并披露覆盖率； 1 条付费社交周花费完全重复，去重； 联盟渠道有一周花费缺失，保持未知，不填成零； 43 条客户编号缺失，但不影响本期渠道金额聚合，因此保留。
处理以后，原先最危险的数字发生了变化：
普通模式：付费社交最近四周渠道贡献约 负 3.6 万元，没有披露重复花费和退货截点； 插件模式：截至 6 月 24 日的已确认退货、已知成本口径约 正 2.56 万元； 独立敏感性复算：纳入后续完整退货后约 正 1.65 万元。
后两种口径结果不同，但都没有支持“已经持续亏损”。它们共同支持的是：付费社交仍有正贡献，效率和退货质量却明显弱于付费搜索。
插件快照中的付费社交销售额退货率约 14.2%，ROAS 约 2.52，贡献回报约 1.17；纳入后续完整退货的独立复算里，订单较此前四周增长约 46.7%，退货件数占比从约 7.8% 升到 19.1%，渠道贡献从约 2.16 万元降到 1.65 万元。
两个口径都说明：增长是真的，增长质量变差也是真的。
这时“暂停扩量”的动作才有了正确理由：不是立即把渠道当作亏损渠道砍掉，而是先检查高退货品类、素材承诺、落地页和商品匹配，再决定是否恢复扩量。
三个渠道的动作也因此更克制
Data Analytics 真实报告给出的动作是：
普通回答建议付费搜索直接增加 20%–30%，并把社交新增预算的 30%–50% 转过去。插件工作流更谨慎：增加 10%–15%，或者只转移约 10% 预算做可逆测试，再复核边际贡献。
因为数据分析不是只回答“往哪边走”，还要回答：
走多快，凭什么，以及什么情况下应该停下来重新判断。
真正应该验收的不是字数，而是产物链
一次可靠的 Data Analytics 任务，至少要让你拿到其中几类产物：
数据质量清单； 异常处理规则； 可复算指标或 Notebook； 图表、报告或可分享页面； 来源、时间范围和计算口径； 人工确认点与结论边界。 
普通模式可以快速形成初步判断；插件路线更适合结果要进入预算、复盘、汇报或协作的任务。但提示词不同时，这只能说明工作覆盖不同，不能当作插件效果的严格因果证明。
明天就能复制的任务结构
不要只复制这次零售案例。先复制下面五个业务合同字段，再按“数据质量门 → 决策分析 → 独立验证”分三轮调用：
1. 业务决定我要支持谁做什么决定？2. 数据粒度每份文件一行代表什么？主键、时间和单位是什么？3. 必查风险哪些重复、缺失、异常、未完成周期或口径混用会改变结论？4. 交付物我要质量清单、可复算结果、图表、报告，还是 Notebook？5. 停止条件遇到哪些未知字段、缺失数据或权限问题，必须先问人，不能自行补全？
如果同一类预算分析每月都会重复，还可以进一步要求 Data Analytics 把指标定义、表粒度、连接方式、过滤规则、来源优先级和验证缺口沉淀成语义层。下次只需要补新的时间范围和本次决定，不再重新解释整套口径。
最后记住一句话
Codex 插件不是让你多装几个 App。
它真正的价值，是把一套重复使用的专业流程装进工作环境：先检查，再计算，再验证，最后交付。
但插件不会自动获得你的数据权限，也不会替你承担最终决策。
这次实测里，普通模式和插件模式给出了同方向建议。真正拉开差距的，是一个错误数字有没有被发现，一条预算动作能不能被复算，以及分析师能不能看清 AI 到底做了什么。
答案一样，不代表同样可靠。