不懂代码也能自建电商BI看板：AI编程智能体（Codex及国内同类工具）协作全流程，含需求模板、指标口径表、计划模式、本机环境清单、练手插件与数据合规红线

本文由 莫潇羽@复源AI社区（bbs.fuyuan7.com）撰写，转载请注明出处。

快速摘要

核心结论：不会写代码的人想自建一套电商数据看板，卡住的地方几乎从来不是“不会编程”，而是“说不清自己到底要看什么”。AI 编程智能体（Codex 这一类能读文件、改文件、跑命令、还会自己检查结果的工具）已经能把写代码这件事接过去，你真正要补的功课只有四样：把模糊愿望翻译成带指标口径的需求说明；让智能体先出方案、你确认之后再动手；在本机备好 Git、Node.js、代码编辑器、容器和数据库这套基础环境；守住“只处理自己有权访问、页面上看得见的数据”这条线。

这篇文章按“问题在哪、工具是什么、怎么配合、怎么练手、边界在哪、下一步去哪”的顺序展开，包含一份可以直接套用的需求说明模板、一张常用电商指标的口径表、一套本机环境自检命令、一个“报表表格导出”浏览器小插件的完整练手过程，以及一张数据获取的红绿灯对照表。文中涉及的境外工具只做科普介绍，国内可直接使用的同类工具我也一并列了出来，方法是通用的。

想看完整拆解，往下翻。

一、为什么“把数据看明白”这件事，值得自己动手

1.1 每个做店的人都经历过的那种“数据疲劳”

我是莫潇羽，平时除了打理复源AI社区这个站，也帮朋友看过不少店铺的运营数据。只要店铺数量超过两三家，或者同时在两个以上的平台经营，一个很现实的麻烦就会冒出来：每天早上要挨个登录后台，挨个点开报表，挨个导出，再把几张表拼到一起，才能回答一句最朴素的话——昨天到底卖得怎么样。

这套动作单看不难，难的是天天做。店铺一多，光是切换账号就够烦了；平台一多，各家的字段名字还不一样，这边叫“访客数”，那边叫“商品访客”，再换一家又成了“浏览人数”。等你把表拼完，一上午过去了，而真正需要动脑子的那部分，比如哪个链接该加预算、哪个款该清库存，反而没精力想了。

所以“想把店里的数据看明白”这句话，背后其实是三个更具体的愿望：数据能自动汇到一处，不用人肉搬运；指标按我自己的算法来，不被别人的口径牵着走；打开一个页面就能看到结论，而不是一堆原始数字。

1.2 现成的路有三条，各有各的别扭

想实现上面三个愿望，市面上现成的路大致是三条。我把它们放在一张表里对比，你可以对照自己的情况看看卡在哪。

前两条路我都走过，也都还在用，它们并没有过时。但只要你的需求稍微“个性”一点，比如想把推广花费和商品成交放在同一行里看，或者想把三个平台的同一款商品合并统计，就会发现现成工具要么做不到，要么要绕很大的弯。

第三条路过去对大多数运营同学是关着门的。不是不想，是真的不会写。

1.3 这扇门现在被推开了一条缝

变化发生在最近两三年。AI 从“能聊天”进化到了“能动手”：你把一个文件夹交给它，用大白话说清楚要做什么，它会自己规划要建哪些文件、写什么代码、执行什么命令，写完还会自己跑一遍看有没有报错。这类工具有个统一的叫法，叫 AI 编程智能体，后面第三章我会展开讲。

我想特别强调一点，免得大家期望跑偏：门只是开了一条缝，不是拆掉了。智能体接走的是“把想法敲成代码”这段体力活，而“想法本身是否清楚”这件事，它替不了你。我自己折腾下来最深的体会是，同一个工具，需求说得清楚的人半小时拿到能用的东西，需求说不清楚的人折腾一晚上还在原地打转，差距全在开口那几句话上。

所以这篇文章不打算教任何编程语法。我想讲的是另一件事：一个不懂代码的人，怎样把生意上的问题说成机器能执行、自己能验收的需求，并且在整个过程里心里有数、手上有刹车。

二、新手最容易栽在哪：需求说不清，AI 只能猜

2.1 把一句话需求扔过去，会发生什么

先看一个很典型的开场。假设你打开智能体工具，输入这样一句话：

帮我做一个能看店铺数据的看板。

接下来通常会出现两种情况。第一种，它二话不说直接开写，十几分钟后交给你一个带着几张示例图表的网页，看起来挺像回事，但里面的数字是它随手编的演示数据，字段也是它自己猜的，和你的店铺没有半点关系。第二种，它回过头来问你一长串问题：数据从哪来、要哪些指标、按天还是按小时、用什么数据库……你被问得一愣一愣的，因为这些问题你自己也没想过。

两种情况指向同一个事实：那句话里的信息量太少了。“店铺数据”是哪些数据？“看板”要给谁看？“能看”是指打开就有，还是要手动导入？每一个没说清的地方，智能体都只能替你做假设。假设对了是运气，假设错了就是返工。

这不是 AI 不够聪明。换成一位经验丰富的程序员朋友，你用同样一句话去找他帮忙，他一样会皱着眉头问回来。区别只在于，人会不好意思瞎做，而机器在没有约束的情况下往往倾向于“先做一版再说”。

2.2 动笔之前，先回答五个问题

我给自己定过一个习惯：在把任何数据类需求交给智能体之前，先在纸上回答五个问题。答不出来就先别开工，因为答不出来说明这事我自己还没想明白。

第一个问题，这个页面给谁看。给自己看和给运营同事看、给老板看，是三种完全不同的页面。自己看可以密密麻麻全是数字，给老板看的往往只需要五六个大数加一条趋势线。

第二个问题，要看哪几个指标，每个指标怎么算。这是最容易想当然的地方，下一小节单独讲。

第三个问题，数据从哪来。是从商家后台手动下载的表格，还是别的系统导出来的文件？文件是什么格式，表头长什么样？最好的做法是直接把一份真实的样例文件放进项目文件夹里，让智能体自己去读，比你用嘴描述一百句都准。

第四个问题，多久更新一次。绝大多数经营决策按天看就足够了。我见过不少人一上来就要“实时大屏”，可实时意味着采集、存储、计算每一环的难度都要上一个台阶，而你真的会每分钟盯着屏幕调整出价吗？如果不会，那就老老实实按天。

第五个问题，看完之后要做什么动作。这一问是用来筛指标的。一个指标如果无论涨跌你都不会因此做任何调整，那它就不该出现在首屏。看板不是数据的仓库，而是决策的入口。

这五问答完，你手里其实已经有了一份需求说明的骨架。

2.3 指标口径要写成算式，别用形容词

“口径”这个词听着唬人，说白了就是一个指标到底怎么算、分子分母各是什么。同一个名字的指标，不同平台、不同团队的算法可能差得很远，不写清楚，后面对数的时候一定会吵架。

下面这张表是我整理的几个最常用的经营指标，全部写成了纯文本算式，你可以直接复制到需求说明里。

这里有个新手特别容易踩的坑，我自己当年也搞混过：客单价和件单价不是一回事。客单价的分母是“人”，件单价的分母是“件”。如果你的商品经常被一次买好几件，这两个数能差出一大截。

用一组虚构的数字感受一下。假设某家店某一天的支付金额是 12000 元，访客数 4000 人，支付买家数 150 人，支付件数 200 件，那么：

客单价     = 12000 ÷ 150  = 80 元
件单价     = 12000 ÷ 200  = 60 元
支付转化率 = 150 ÷ 4000 × 100% = 3.75%
访客价值   = 12000 ÷ 4000 = 3 元

验算：访客价值 = 支付转化率 × 客单价 = 3.75% × 80 = 3 元（两种算法结果一致）

最后那行验算很有用。访客价值既可以用“支付金额 ÷ 访客数”直接算，也可以用“支付转化率 × 客单价”间接算，两条路算出来必须相等。以后智能体把看板做出来了，你就可以拿这种“一个指标两种算法”的关系去抽查它算得对不对，这比盯着代码看管用得多。

2.4 一份可以直接套用的需求说明模板

把前面的五问和口径表合在一起，就是下面这份模板。我平时就是把它存成一个文本文件放在项目文件夹里，每次开新项目复制一份改一改。

【项目名称】
（一句话说清这是个什么东西）

【给谁用】
（使用者是谁，他们打开页面最想先看到什么）

【要解决的问题】
（现在是怎么做的，哪里费时或容易出错）

【数据来源】
- 来源一：（文件名或页面名称，格式，更新频率）
- 来源二：……
- 样例文件已放在项目的 samples 文件夹里，请先阅读再设计

【需要的指标与口径】
- 指标名 = 算式（注明分子、分母各取自哪个字段）
- ……

【页面要求】
- 首屏展示哪几个数
- 需要哪些筛选条件（日期、店铺、平台、商品）
- 是否需要导出功能

【明确不要做的事】
- （例如：不要联网获取任何数据；不要生成演示用的假数据）

【运行环境】
- 只在本机运行，数据存本机数据库
- 操作系统：（Windows 11 或 macOS）

【验收标准】
- （例如：导入样例文件后，页面上的支付金额合计与样例文件里的合计一致）

【待你确认的问题】
请先列出你不确定的地方向我提问，得到我的答复后再开始写代码。

模板里有三处是我特意加的，值得解释一下。

“明确不要做的事”这一栏，是给智能体画边界用的。它很勤快，勤快到有时会多做：你只要一张表，它顺手给你加了登录系统；你没提数据从哪来，它就自己编一批假数据把页面填满。把“不要”写在前面，能省掉很多返工。

“验收标准”这一栏，是给你自己留的抓手。你看不懂代码，但你看得懂“页面上的合计数和表格里的合计数是不是一样”。把验收标准写成你能亲手核对的事实，你就始终握着判断对错的权力。

最后那句“请先列出你不确定的地方向我提问”，作用是把智能体从“先做再说”拨到“先问再做”。这一句话的分量，比你想象的重得多。

2.5 连模板都填不出来怎么办：让 AI 反过来采访你

有读者可能会说，道理我都懂，可我面对空白模板还是不知道从哪下笔。这很正常，也有很简单的办法：别急着让它写代码，先让它当一回需求分析师。

你可以这样开口：

我想做一个店铺经营数据看板，但我还没想清楚具体需求。
请你扮演需求分析师，每次只问我一个问题，
从“给谁看”“看哪些指标”“数据从哪来”“多久更新”“看完做什么”这几个方向依次了解。
全部问完之后，把我的回答整理成一份结构化的需求说明，
其中我没有回答清楚的地方，请单独列在“待确认”里。
在我明确说“可以开始”之前，不要创建或修改任何文件。

它会一个一个问，你用大白话答就行，答不上来的直接说“不确定”。十来个回合之后，你会拿到一份比自己闷头写完整得多的需求说明，而且“待确认”那一栏会老老实实地告诉你，还有哪些地方是你自己都没想明白的。

这个做法背后的逻辑很朴素：把模糊的东西变清楚，本来就是大模型擅长的事。与其逼自己一步写出完美需求，不如把“写需求”也当成一次人机协作。莫潇羽@复源AI社区 的经验是，这一步花掉的十几分钟，是整个项目里回报最高的十几分钟。

三、认识 AI 编程智能体：它和聊天机器人到底差在哪

3.1 大模型是“脑子”，智能体是“带着工具箱的执行者”

很多人第一次接触这类工具时会有个疑问：我平时用的聊天类 AI 也能写代码，为什么还要专门装一个编程智能体？

区别在于谁来动手。聊天类 AI 给你的是一段文字，代码写在对话框里，你得自己复制出来、新建文件、粘贴进去、保存、运行，报错了再把错误信息复制回去问。整个过程里，AI 只负责“说”，所有“做”的环节都压在你身上。对于不懂代码的人来说，光是“这段代码该存成什么文件、放在哪个目录”就足以让人放弃。

编程智能体把“做”也接过去了。大模型（就是那个负责理解和生成的“脑子”）外面被套上了一层能操作电脑的能力：读取你指定文件夹里的文件、新建和修改文件、在命令行里执行命令、查看命令的输出结果，然后根据结果决定下一步。你看到的不再是一段让你自己去处理的代码，而是文件夹里实实在在多出来的文件，以及一份“我做了什么、怎么验证的”汇报。

用一张表把差别说透：

一句话概括：前者是坐在旁边出主意的人，后者是你把活交代清楚之后能自己干完的人。

3.2 Codex 是什么，现在长什么样

说到编程智能体，Codex 是绕不开的一个名字，这里做个科普性质的介绍。

Codex 这个名字其实用过两回。最早它是 OpenAI 在 2021 年推出的一个把自然语言翻译成代码的模型，后来在 2023 年退役。到了 2025 年，这个名字被重新启用，指代的东西已经完全不同：一个能进入代码仓库、修改文件、执行命令并把结果交回来审阅的智能体产品。此后它的形态一路扩展，我根据公开报道把几个关键变化整理成了下面这张时间表。

所以写稿时（2026年10月初）你如果在资料里看到“Codex 桌面版”，它指的已经不是一个单独下载的软件，而是 ChatGPT 桌面应用里的一个模式。除了桌面形态，它还有命令行版本、代码编辑器里的扩展版本、云端版本以及浏览器扩展等几种入口，背后是同一套能力，只是交互方式不同。对新手来说，带图形界面的桌面形态最友好，因为项目、对话、文件改动都摆在眼前，不用和黑底白字的终端打交道。

有两点必须说在前面。其一，这类产品迭代极快，上面的时间表是写稿时根据公开报道整理的，具体功能和入口位置请以官方最新说明为准。其二，也是更重要的一点：OpenAI 的服务目前并未面向中国大陆地区正式提供，境外模型使用需遵守国内网络与内容管理相关规定。本文介绍它是因为它在这个品类里有代表性，便于讲清楚“编程智能体是怎么工作的”，不提供也不讨论任何访问方法；是否使用、如何使用，请以所在地的法律法规和所在单位的合规要求为准。

3.3 国内可以直接使用的同类工具

好消息是，“能读写项目文件、能执行命令、能自己验证”的智能体能力，早已不是某一家的独门功夫。国内几家大厂都推出了同类产品，注册和使用都在境内完成，对大多数读者来说是更省心的选择。

这些产品的版本划分、计费方式和可选模型变化很快，上表只是写稿时的大致情况，选之前请去各自官网看最新说明。

我自己挑工具时不太看评测榜单上的分数，只看三个能不能：能不能直接打开我本机的一个文件夹当作项目；能不能在得到我允许后执行命令并读回结果；有没有“先给方案、我点头后再改文件”的工作方式。三条都满足，它就是一个合格的编程智能体，本文后面讲的所有方法都可以原样套上去。工具会换代，方法不会。

3.4 两种付费方式，以及我为什么不碰来路不明的“转接”服务

用这类工具免不了要为模型的计算付费，常见的方式有两种，逻辑差别挺大，新手值得花两分钟弄明白。

第一种是会员订阅。按月付一笔固定的钱，换来一定的使用额度，额度通常按周期重置，用不完不会累积到下个周期，用超了就得等下个周期或者升级套餐。好处是省心，新模型、新功能一般会员先用上，而且花多少钱心里有数。

第二种是按量计费。这里要先认识一个词：token，可以粗略理解成模型读写文字时的计量单位，一段话会被切成若干个 token。按量计费就是按“读进去多少 token、写出来多少 token”分别计价，通常以每百万 token 多少钱来标价。好处是用多少付多少，不用的时候一分钱不花；坏处是费用不封顶，一个大任务跑下来花掉多少，事先不太好估。

用按量计费时，有个现象会让新手吓一跳：明明只发了一句“你好”，账单上记的 token 数却远比这两个字多。原因在于智能体每次向模型发请求时，除了你的那句话，还会附带一大段你看不见的内容，包括它的身份设定、行为规范、可以调用哪些工具以及每个工具的说明书。这些“前置内容”每次都要算钱。所以按量计费的真实成本，要拿一个完整任务去衡量，而不是拿单句对话去衡量。

模型服务的价格变动非常快，不同厂商、不同模型之间差别也大，我在这里不列任何具体数字，请以你所选服务商官方定价页面的实时数据为准。

说到按量计费，就不得不提一种在网上流传很广的做法：通过一些非官方的第三方“转接”站点购买模型调用额度，再把工具的服务地址改成这些站点。我的态度很明确，不碰，也不建议你碰。理由有四条。其一，货不对板，你付的是高端模型的钱，对方实际转给哪个模型处理，你很难验证。其二，你发出去的每一句话、每一个文件片段，都要先经过这个第三方的服务器，店铺的经营数据就这样交到了一个不知底细的人手里。其三，密钥和余额都托管在对方那里，站点哪天关停，钱和服务一起没了。其四，这类转接境外模型的服务本身就游走在监管的灰色地带，合规风险需要你自己掂量。

比较稳妥的做法是：直接使用境内已按规定完成备案的大模型服务，从服务商官方渠道开通；如果你所在的公司有统一采购的模型服务或内部网关，就用公司提供的。

顺带科普一下这类工具“认模型”的机制，了解之后你就不会被各种配置教程绕晕。以 Codex 为例，公开文档显示它在用户目录下有一个专属的配置文件夹，里面有一个文件负责记录“用哪个模型、服务地址是什么”，另一个文件负责存放登录凭证或密钥。国内工具的做法大同小异，多数直接在设置界面里填写。配置文件的样子大致如下，仅为示意，字段名称请以你所用工具的官方文档为准：

# 示意：告诉工具“用哪个模型、去哪里找它”
model = "你选用的模型名称"
model_provider = "my_provider"

[model_providers.my_provider]
name = "合规的模型服务商"
base_url = "服务商官方文档给出的接口地址"
env_key = "MY_API_KEY"   # 密钥放在系统环境变量里，不直接写进这个文件

关于密钥，我踩过坑，所以有三条铁律想分享：不要把密钥截图发到任何群里；不要把含有密钥的文件提交到代码仓库；一个项目用一把单独的密钥，并在服务商后台给它设好额度上限，万一泄露了损失也有限。密钥就是钱包的钥匙，这一点怎么强调都不过分。

四、智能体是怎么干活的：一个闭环，四处刹车

4.1 从接到任务到交付，它会经历五步

理解智能体的工作过程，对不懂代码的人格外重要。你不需要知道每行代码在干什么，但你需要知道它现在处于哪一步、这一步你该看什么。

我把它的典型工作过程画成了下面这张图