大数跨境

干货系列:为什么先教大家用codex做crm而不是建站

干货系列:为什么先教大家用codex做crm而不是建站 一人外贸团队
2026-07-15
0
导读:真正值得学的,不是让AI写代码,而是把你的工作逻辑变成一个会推进业务的系统
好久没有更新了,大家都知道,一般我好久不更新,说明一定是憋着有大招要放!而这次的大招就是:因为忙着做年度会员的交付,所以懒得写……好多人问我我的年度会员什么时候开放报名?什么时候开始?
没错,其实已经报名了100个人了。。。内部直播都已经两次了,想知道反响如何,评论区会员们可以评论一下帮我吹吹牛逼

正文开始:
最近Codex真的很火

澎湃的另一位老师开了一个codex建站课,受到了很多人的追捧;还有龙虾开发课,也是效果拔群

这很好理解

对于绝大多数不懂代码的人来说,自己做出一个网站,是一件非常有冲击力的事情

你只需要对着AI说几句话,几分钟以后,一个原本只存在于脑海里的页面,就真的出现在了屏幕上

按钮能点,页面能跳转,甚至还能直接发布到互联网上

这种感觉非常像第一次使用ChatGPT写文章

你会突然发现,过去需要找设计师、前端工程师、后端工程师才能完成的事情,现在好像自己也能做了

所以,当我开始做年度会员以后,很多人以为我做的ai agent第一件事,也会是教大家如何用Codex建站

但我没有

我做的第一件事,是教大家用Codex搭建自己的CRM

第二件事,是搭建自己的LinkedIn数据看板  PS:打一个小小小广告,实际上7月2526我在深圳的linkedin线下公益课也会教这些,只是因为怕大家畏难,又怕其他上了codex课的同学有意见我就没宣传。有机会大家可以看看这次线下课的反响决定以后要不要来。还是同一个目标,今年我会做到linkedin top3,明年就是top1

为什么

因为我在会员群里常说的那段话:我们用ai不是用来做我们原先做不到的事,也不是用来做一些开发客户的事 

我们的核心,是用它来替代每天都要干的碎活儿

CRM和LinkedIn看板,才是你每天真正用来工作的东西

一个网站做得再漂亮,如果没有人持续运营,没有询盘跟进,没有客户分层,没有业务推进,它最后仍然只是一个摆在互联网上的电子画册

但一个真正适合自己的CRM,可以告诉你今天应该跟进谁

一个真正适合自己的LinkedIn看板,可以告诉你过去一个月做的内容和开发动作,到底有没有推动业务

我越来越觉得,AI时代真正重要的能力,并不是会不会写Prompt,也不是能不能用AI做出一个漂亮页面

真正重要的能力,是你能不能把自己的工作方法说清楚

因为只有当你能把工作说清楚,AI才有机会把它变成系统

还是那句话,没有工作流,就没有自动化


一、为什么我要自己搭建CRM

很多人对CRM的理解,是客户管理系统

把客户名字放进去,把公司放进去,把邮箱放进去,把聊天记录放进去

然后呢

然后就没有然后了

我见过很多公司购买了CRM

上线之前,老板非常兴奋

上线之后,业务员每天被要求填写客户名称、公司、国家、来源、产品、意向等级、沟通记录、报价记录、跟进记录

字段越来越多,表单越来越长,操作越来越复杂

最后,CRM变成了一个业务员不愿意填、管理层也不愿意看的巨大数据库

它当然记录了很多东西

但它没有真正推动任何事情

这也是我对传统CRM最大的不满

CRM不应该只是为了记录客户,CRM应该是为了推进工作

记录只是手段

推进才是目的

一个真正有价值的CRM,至少应该回答下面几个问题

今天有哪些客户必须跟进

这些客户为什么需要跟进

他们目前处于什么阶段

上一次聊了什么

下一步最合适的动作是什么

如果今天没有跟进,会造成什么影响

跟进完成以后,客户应该进入哪个阶段

如果客户长时间没有回复,应该进入长期培育,还是应该被判定为失单

这些问题,才是真正和业务有关的问题

可绝大多数CRM在设计的时候,首先考虑的并不是一个外贸业务员每天如何工作

它们考虑的是如何满足不同公司、不同部门、不同管理层的共同需求

于是功能越做越多

客户管理、订单管理、库存管理、采购管理、合同管理、审批管理、财务管理、报表管理、邮件管理、绩效管理……

每一个模块好像都有价值

但是,当一个SOHO或者一个十几人的外贸团队真正打开系统时,会发现自己面对的是一个庞然大物

我们只想知道今天应该跟进哪几个客户

系统却想让我们先完成一次数字化转型

这不是传统CRM没有价值

而是标准化CRM必须照顾一千种公司,所以它很难完全符合你的工作方式

而Codex带来的改变是,我们第一次有机会用相对低的成本,把自己的业务逻辑做成系统,不是购买一套系统,然后强迫自己适应它

而是先明确自己怎么工作,再让系统适应自己

这两者看起来只是顺序不同,实际上完全是两种产品逻辑


二、为什么还要搭建LinkedIn看板

很多人对LinkedIn数据的理解,停留在几个数字上

粉丝增长了多少

帖子获得了多少浏览

新增了多少好友

发出了多少条开发信

收到多少个回复

这些数据当然有用

但如果只是把数字放在一起,它们很容易变成另一种形式的自我感动

一个月发布了20篇帖子,看起来很努力

但是这20篇帖子吸引来的是什么人

是同行,是供应商,是学员,还是目标客户

一篇帖子有10万浏览,看起来很厉害

但是这10万浏览有没有带来主页访问,有没有带来目标客户连接,有没有带来私信,有没有带来询盘

一天添加了100个好友,看起来执行力很强

但是接受率是多少

通过的人是不是目标客户

加好友时带备注和不带备注,哪个通过率更高

不同国家、不同职位、不同公司规模的客户,接受率有什么差异

发了50封开发信,看起来做了业务动作

但是哪一个模板的回复率最高

哪一种开场方式更容易获得有效回复

哪些回复只是礼貌回应

哪些回复真正进入了产品沟通

又有多少人进入报价、样品、会议和订单阶段

如果这些问题没有被回答,那么所谓的LinkedIn看板,就只是把LinkedIn后台的数据重新抄了一遍

它看起来像一个仪表盘

但它并没有帮助我们做出任何决策

所以,我对LinkedIn看板的要求,从一开始就不是“做一个漂亮的数据大屏”

我需要它同时满足两条线

第一条是运营线

我发布了什么内容

什么主题表现更好

内容在发布后1天、3天、7天、30天分别表现如何

哪些内容吸引了目标客户

哪些内容带来了主页访问、关注和连接

哪些内容值得继续做

哪些内容只是看起来热闹

第二条是业务线

我开发了哪些人

用了什么搜索条件

发出了什么连接邀请

是否添加了备注

对方是否通过

通过以后发送了哪一种开场消息

是否收到回复

回复是否有效

是否进入需求沟通、报价、会议、样品和订单阶段

更重要的是,这两条线不能完全分开

因为内容和业务本来就是相互影响的

客户可能先看到我的帖子,然后访问我的主页,再接受我的好友邀请

也可能先收到我的开发信,进入主页查看我过去发布的内容,最后决定回复我

所以,一个真正有用的LinkedIn看板,不只是统计运营数据,也不只是记录开发动作

它应该帮助我们看清楚:

内容如何影响信任,信任如何影响连接,连接如何进入沟通,沟通又如何进入业务

它最终仍然不是为了记录数据

而是为了推动业务


三、CRM和LinkedIn看板,其实是同一个东西

当我真正开始做这两个系统时,我发现CRM和LinkedIn看板并不是两个完全独立的产品

它们底层的逻辑几乎一模一样

第一步,记录发生了什么

第二步,判断现在处于什么状态

第三步,根据状态推荐下一步动作

第四步,提醒人去完成这个动作

第五步,记录动作产生的结果

第六步,根据结果调整策略

这就是一个完整的工作闭环

所以我并不喜欢“数据看板”这个词

因为很多人一听到数据看板,脑子里出现的是几张折线图、几个漏斗、几块特别大的数字

好像数字越大,看板就越专业

但真正的看板不应该只是让老板站在屏幕前欣赏数据

它应该能够告诉执行者:

你现在的问题在哪里

为什么会出现这个问题

接下来最值得做的动作是什么

比如LinkedIn好友申请接受率很低

普通看板只会告诉你:

本月发送了500个连接邀请,通过了75个,接受率15%

真正有用的看板应该继续追问:

带备注的邀请发送了多少,通过率是多少

不带备注的邀请发送了多少,通过率是多少

采购经理、公司创始人、产品经理的接受率分别是多少

巴西美国德国的接受率分别是多少

不同搜索关键词找到的客户,接受率分别是多少

最近两周是否更换过头像、Headline或者About

接受率下降发生在修改Profile之前,还是之后

当这些数据能够被交叉分析时,系统才有可能告诉你:

问题可能不在邀请话术,而在目标客户不准确

或者:

对经销商使用产品型开场,比使用公司介绍型开场的回复率更高

这才是看板真正的价值

它不是把结果展示出来

它是帮助我们找到结果背后的原因


四、在做CRM之前,第一步不是打开Codex

这是很多人最容易犯的错误

看到别人用Codex做出了一个CRM,于是马上打开Codex,输入:

“帮我做一个外贸CRM”

Codex当然可以做

它甚至可能很快给你做出一个看起来很完整的系统

左侧是导航栏

首页有客户总数、本月询盘、待跟进客户和预计成交金额

中间有一个销售漏斗

下面有最近活动和任务列表

页面很好看

功能似乎也很齐全

但当你真正开始使用时,会发现它和市面上的CRM没有本质区别

因为你只告诉AI:“我要一个CRM”

AI只能调用它对CRM的普遍理解

而普遍理解,往往只能生成一个普遍的产品

所以,在打开Codex之前,我们必须先回答一个更重要的问题:

我的工作到底是怎么被推进的

例如,一个外贸询盘进入以后,真实流程可能是:

收到询盘

判断询盘质量

补充公司信息

调查客户背景

确认客户需求

发送第一次回复

等待客户反馈

进一步确认参数

准备报价

发送报价

报价后跟进

样品沟通

订单谈判

合同确认

成交或者失单

但即使是同一个阶段,不同客户的跟进逻辑也不一样

A级客户可能3天没有回复就必须提醒

B级客户可能7天提醒

展会客户可能第二天就需要跟进

独立站询盘可能5天跟进

社媒刚刚添加的客户,可能24小时内就应该发送第一条消息

报价客户的提醒优先级,又应该高于普通询盘客户

这才是真正需要做进CRM里的东西

所以,做CRM之前,不要先思考页面长什么样

先把下面这条链路画出来:

客户从哪里来——进入什么阶段——需要完成什么动作——多久没有动作算停滞——停滞以后如何提醒——完成动作以后进入哪里——最终如何判断成交或者失单

页面只是这套逻辑最后的表现形式

逻辑才是产品本身


五、做LinkedIn看板之前,也不要先想图表

LinkedIn看板同样如此

很多人第一反应是:

我要记录浏览量、点赞量、评论量、粉丝数、好友数

但真正应该先问的是:

这些数据能帮助我做什么决定

我通常会用四个问题判断一条数据是否值得被记录

第一,这个数据能不能改变下一步动作

假设我知道一篇帖子有3000浏览

然后呢?

如果这个数字不会影响我下一篇内容的选题、形式、发布时间和目标人群,那么它就只是一个结果数字

但如果我同时知道:

这篇帖子带来了80次主页访问

其中有22位来自目标行业

带来了13个目标客户连接

其中4个人进入了业务沟通

那么这篇内容就不再只是“浏览量不错”

它可能是一篇真正能带来业务的内容

第二,这个数据能不能帮助我解释原因

接受率从30%下降到12%,这是结果

但如果没有记录目标职位、国家、搜索关键词、是否带备注、备注模板、Profile版本,就很难判断为什么下降

不能帮助我们解释原因的数据,通常只能制造焦虑

第三,这个数据的记录成本是否合理

理论上,我们可以记录一切

客户几点钟查看了主页

在第几条消息后停止回复

每一篇帖子前两小时的增长速度

每一种话术的字数

但记录得越多,执行成本越高

最后很可能为了维护看板,反而没有时间真正做业务

所以,数据并不是越多越好

真正重要的是,用尽可能少的数据,支撑尽可能重要的决策

第四,这个数据能不能持续记录

今天心血来潮记录了20个字段,一个星期以后只愿意填写3个字段,这套系统就注定失效

好的看板不是理论上最完整的看板

而是三个月以后,你仍然愿意使用的看板


六、Codex在这里承担什么角色

很多人会问:

既然ChatGPT已经可以写代码,为什么还需要Codex

我个人的理解很简单

GPT更像一个产品顾问、业务顾问和架构师

Codex更像一个可以直接进入项目干活的工程团队

我可以先和GPT讨论:

我的CRM应该服务

需要解决什么问题

应该有哪些阶段

哪些功能是MVP必须做的

哪些功能暂时不要做

自动化提醒应该如何判断

不同来源的客户应该如何设置优先级

GPT可以帮助我梳理需求、发现矛盾、补充场景、整理产品文档

但讨论完成以后,我仍然需要有人真正把它做出来

创建项目

建立数据库

设计数据结构

编写页面

实现按钮交互

处理字段校验

导入Excel

建立提醒规则

修复错误

测试功能

发布到线上

这些更偏向项目执行的事情,就是Codex擅长的部分

从官方定位上看,Codex并不只是“帮你生成一段代码”的聊天机器人。它可以理解代码仓库、修改多个文件、运行命令和测试,并围绕一个项目持续完成开发任务。OpenAI目前也把Codex定位为可以参与完整软件开发流程的编码智能体,而不只是代码补全工具

所以,我通常不会把GPT和Codex理解成两个互相竞争的工具

我更愿意把它们理解成同一个项目里的两个角色

GPT帮助我想清楚

Codex帮助我做出来

当然,这个边界并不是绝对的

Codex也能讨论需求,GPT也能直接参与开发

尤其是现在Codex已经逐渐进入ChatGPT桌面端、网页端、IDE和命令行等不同工作界面,二者之间的边界正在变得越来越模糊。

但对于一个不懂代码的人来说,这种角色划分仍然非常有用

因为它能防止我们犯两个错误

第一个错误,是还没有想清楚需求,就让Codex直接开工

第二个错误,是和GPT讨论了十几万字,最后却没有把任何东西真正做出来


七、为什么我选择Codex,而不是WorkBuddy之类的工具

这里需要说明一下

我并不认为Codex一定比WorkBuddy更好,(因为workbuddy找我打过广告而codex没有- -虽然我也没接)

工具没有脱离场景的绝对优劣

WorkBuddy目前的定位更接近全场景办公智能体,可以围绕本地文件、文档、研究、办公任务和多步骤工作进行规划与执行。它强调的是,你描述一个工作目标,然后由不同能力的智能体协作完成任务。

如果我要做的是:

整理一批文件

生成一份报告

分析几张表格

制作一套文档

完成一次研究

自动处理某类办公室任务

WorkBuddy这类产品可能会非常方便

但CRM和LinkedIn看板不是一次性交付物

它们是需要长期维护、持续修改和不断增加功能的软件项目

今天我要增加一个客户来源

明天我要调整漏斗阶段

后天我要修改提醒规则

使用一个月以后,我可能还会发现数据库结构需要改变

这意味着我不仅需要AI“帮我做出一个结果”

我还需要AI持续理解同一个代码项目

知道每个文件在哪里

知道数据库之间是什么关系

知道上一次修改了什么

能够运行项目、检查错误、修改代码、测试结果并继续迭代

在这种场景里,我更倾向于选择一个以代码仓库和软件项目为核心的工具

这也是我选择Codex的原因

当然更核心的原因是,GPT太强了


八、到底应该直接和Codex对话,还是先和GPT沟通

我的答案是:

先和GPT把业务讨论清楚,再让Codex开始做,但不要把它理解成两个完全割裂的阶段

最理想的流程,不是写一段十万字的超级Prompt,然后扔给Codex,再也不管了

而是分成四个阶段

第一阶段:和GPT梳理业务

这一阶段先不要谈技术

只讨论:

谁会使用这个系统

每天在什么场景下使用

目前最痛苦的事情是什么

哪些动作最容易被忘记

哪些数据最值得记录

哪些判断目前依赖经验

哪些提醒可以自动完成

系统最终应该帮助我们做出什么决定

这一步的目标,是把脑子里的经验变成语言

第二阶段:让GPT整理产品需求

当业务逻辑逐渐清晰以后,让GPT把讨论整理成一份结构化产品文档

包括:

产品目标

用户角色

使用场景

核心流程

数据字段

状态定义

自动化规则

页面结构

权限要求

非目标范围

MVP范围

验收标准

这一步的目标,是把语言变成规格

第三阶段:让Codex先规划,再开发

复杂项目不要一上来就让Codex修改代码

可以先让它检查当前项目、理解需求、拆分任务、识别风险,再开始开发

OpenAI在Codex的官方最佳实践中也建议,面对复杂或模糊任务时,应当先进入规划阶段;同时可以使用AGENTS.md保存项目规则、运行方式、测试命令、禁止事项和验收要求,让Codex在后续每一次开发中都遵守同一套标准。

这一步的目标,是把规格变成工程计划

第四阶段:一边使用,一边修改

第一版上线以后,真正的产品工作才刚刚开始

你会发现原本以为重要的功能没人使用

原本以为不重要的字段,每天都要打开

某些按钮放错了位置

某些漏斗阶段根本不符合真实业务

某些提醒出现得太频繁

某些自动化建议完全不符合你的判断

这时候,不要推翻重来

把真实问题逐个反馈给Codex,让它持续修改

这一步的目标,是把工程计划变成真正适合自己的工作系统


九、好的AI,是否可以靠Talking解决

我越来越相信一件事情

未来使用AI最重要的能力之一,就是Talking

不是英语口语里的Talking

而是你能不能持续和AI把一件事情讲清楚

很多人学Prompt,喜欢背公式

你是一个什么专家

请完成什么任务

按照什么格式输出

必须满足什么要求

当然,这些结构有用

但当任务变得复杂以后,真正决定结果的,往往不是你有没有使用某一个Prompt公式

而是你是否真正理解自己想要什么

比如有人对Codex说:

“帮我优化CRM,让它更智能一些”

这句话没有错

但Codex不知道什么叫更智能

是自动识别客户等级

还是自动生成跟进邮件

是提醒长期未联系客户

还是预测成交概率

如果你自己都没有定义“智能”,AI就只能替你猜

所以Talking不是随便聊天

Talking是通过持续对话,把模糊需求逐渐变成明确要求

好的Talking通常会经历下面几个层次

第一层,我不喜欢现在这个页面

第二层,这个页面让我看不到今天需要完成的任务

第三层,我希望首页优先显示逾期任务、今日任务和高优先级客户

第四层,高优先级应该综合客户等级、业务阶段、预计金额和距离上次联系的时间计算

第五层,报价阶段超过3天未联系的A级客户,优先级应该高于普通询盘阶段超过5天未联系的A级客户

当你能说到第五层时,Codex才真正有机会把你的判断写进系统

所以,我不认为非程序员必须先学会写代码,才能使用Codex

官方的Codex提示指南同样强调,可以先用自己的自然语言说明目标,再通过后续对话不断补充上下文和修正结果,并不要求一开始掌握严格的技术语法。

但是,非程序员必须学习另外一种能力

那就是:

把自己的工作解释清楚


十、做CRM时,必须和Codex讲清楚的十件事

无论你最终使用什么Prompt,我都建议至少把下面十件事讲清楚

1. 谁在使用

是SOHO

是业务员

是老板

是运营和业务共同使用

还是多个部门共同使用

不同用户决定了系统复杂度完全不同

2. 系统最重要的目标是什么

是记录客户

是避免遗忘跟进

是提高转化率

是帮助管理者检查工作

还是帮助业务员决定每天做什么

目标只能有一个第一优先级

我的第一优先级是:

推动客户进入下一阶段

3. 客户从哪里进入

独立站询盘

手动录入

Excel导入

WhatsApp

LinkedIn

邮件

展会

老客户转介绍

不同来源需要不同字段和不同跟进节奏

4. 客户会经历哪些阶段

新线索

已背调

需求确认

已回复

已报价

报价跟进

样品

谈判

合同

成交

长期培育

失单

阶段不能只是名字,还要定义进入和退出条件

5. 每个阶段需要完成什么动作

例如进入“已报价”以后:

记录报价金额

记录报价产品

保存报价文件

设置下一次跟进时间

默认生成报价跟进任务

如果三天没有后续动作,触发提醒

只有这样,阶段才不是一个颜色标签

6. 哪些情况需要自动提醒

按照客户等级提醒

按照业务阶段提醒

按照客户来源提醒

按照距离上次联系的时间提醒

按照预计成交金额提醒

按照多个规则综合排序

还要告诉系统,如果多个规则冲突,谁的优先级更高

7. 每天打开首页应该看到什么

今日待办

逾期任务

高优先级客户

长时间未联系客户

刚刚回复的客户

需要报价的客户

本周预计成交机会

首页不是为了显示公司一共有多少客户

而是为了告诉你今天该干什么

8. 每完成一个动作以后发生什么

发送邮件后是否自动更新最后联系时间

完成报价后是否进入已报价阶段

创建会议后是否自动生成会议准备任务

客户回复后是否取消原来的催办提醒

一个好的系统必须理解动作之间的关系

9. AI具体负责什么

自动总结沟通记录

判断客户阶段

提取客户需求

推荐下一步动作

生成跟进邮件草稿

识别风险

发现长期停滞

AI不能只被写成一个“AI助手”按钮

必须明确它在什么节点、读取什么信息、输出什么结果

10. 什么叫完成

所有按钮可以点击,不叫完成

页面能打开,不叫完成

真正的验收标准应该是:

数据可以保存

刷新后不会丢失

阶段可以正常流转

提醒可以按照规则生成

Excel可以正确导入

错误数据会被拦截

手机端可以基本使用

空状态、加载状态和错误状态都有提示

核心流程经过真实数据测试


十一、可以直接复制给Codex的CRM启动Prompt

下面是大家最喜欢的环节,就是照抄环节;当然这段Prompt并不意味着复制进去以后,你就可以完全不管了

它的作用,是帮助Codex在第一轮就理解你的业务目标、范围和工作逻辑

你仍然需要在后续使用中不断修改


【CRM项目启动Prompt】

算了,这部分留在会员群里分享吧,嘿嘿


十二、做LinkedIn看板时,必须和Codex讲清楚什么

LinkedIn看板最大的难点,不是页面怎么设计

而是数据之间如何建立关系

一篇帖子不是发布完以后就结束了

它的数据会持续变化

发布第一天可能只有500浏览

第七天可能增长到5000

第三十天可能仍然持续获得搜索流量和主页访问

所以帖子不能只保存一个最终数字

需要保存不同时间节点的数据快照

同样,一次好友邀请也不是一个孤立动作

它需要和目标客户、搜索项目、邀请模板、是否带备注、发送时间、接受结果、首条消息、后续回复和最终业务阶段关联起来

如果这些数据彼此断开,就无法真正分析哪种动作有效

因此,LinkedIn看板需要同时建立三条链路

第一条是内容链路

选题——发布——触达——互动——主页访问——关注——连接——询盘

第二条是开发链路

搜索——查看主页——发送邀请——接受——发送消息——回复——有效沟通——报价——成交

第三条是实验链路

目标市场——客户画像——搜索条件——内容主题——邀请模板——开发信模板——结果——结论——下一轮调整

真正的看板,不只是知道发生了什么

还要知道:

为什么发生,以及下一轮应该改什么


十三、可以直接复制给Codex的LinkedIn看板启动Prompt

【LinkedIn看板项目启动Prompt】

LinkedIn Growth Board产品重构与完整开发总控提示词

你现在是本项目的首席产品经理、LinkedIn B2B增长顾问、外贸业务流程专家、内容运营专家、销售数据分析师、实验设计顾问、UX设计师、数据架构师、全栈工程师和QA负责人

你需要审计、重构并完善当前的LinkedIn Growth Board

它不是一个展示粉丝数、浏览量和添加好友数量的数据大屏

它也不是一个为了课堂演示而制作的静态后台

它是一套面向外贸SOHO、外贸业务员、LinkedIn运营人员、课程学员和年度会员的:

LinkedIn运营与业务增长双看板

它必须同时覆盖:

  1. 内容运营

  2. 搜客动作

  3. 连接邀请

  4. 私信与开发消息

  5. 回复结果

  6. 客户推进

  7. 商机转化

  8. 实验复盘

  9. 今日行动

  10. 下一步优化

整个产品的核心原则是:

LinkedIn数据不是为了证明做了多少,而是为了判断什么有效、什么无效,以及下一步应该做什么


一、开始工作前的强制要求

不要直接生成更多图表、数字卡片或演示数据

请先:

  1. 检查当前代码仓库

  2. 运行当前项目

  3. 使用浏览器完整操作现有系统

  4. 检查所有页面、按钮、弹窗、表单、筛选器和数据来源

  5. 检查数据是否真实持久化

  6. 检查刷新页面后数据是否丢失

  7. 检查漏斗各层是否来自同一批真实记录

  8. 检查所有统计数字是否可以下钻

  9. 检查帖子数据是否支持多次更新

  10. 检查连接邀请、开发消息和回复结果是否建立关系

  11. 检查课程演示数据与用户真实数据是否隔离

  12. 检查筛选时间、账号、产品线、ICP和成员后,所有模块是否同步变化

  13. 检查数据来源是否可以修改

  14. 检查所有新增、编辑、删除和导入是否真实有效

创建并长期维护:

  • PRODUCT_SPEC.md

  • PLAN.md

  • AGENTS.md

  • DATA_MODEL.md

  • METRIC_DICTIONARY.md

  • FUNNEL_DEFINITIONS.md

  • ATTRIBUTION_MODEL.md

  • AUTOMATION_RULES.md

  • AI_BEHAVIOR.md

  • TEST_PLAN.md

  • CHANGELOG.md

  • .env.example

在完成审计、数据模型、指标口径和实施计划以前,不要大规模开发

能够保留的现有代码应当保留

不要为了“重新设计”而破坏当前已真实可用的功能

不要只问问题而不推进

对非核心问题采用合理默认值,并在DECISIONS.md记录


二、产品定位

产品名称:

LinkedIn Growth Board

中文名称:

外贸LinkedIn增长双看板

产品不是单一看板,而是由三个层次组成:

第一层:今日行动中心

回答:

  • 今天要做什么

  • 哪些动作逾期

  • 哪些客户没有被推进

  • 哪些帖子需要更新数据

  • 哪些实验需要复盘

第二层:运营看板

回答:

  • 发布了什么内容

  • 哪些内容真正吸引目标客户

  • 哪些内容带来主页访问、关注、连接和私信

  • 哪些内容只有曝光,没有业务价值

  • 下一阶段应该继续、停止或测试什么

第三层:业务看板

回答:

  • 找了哪些人

  • 通过什么搜索项目找到

  • 使用了什么连接方式

  • 是否带备注

  • 使用了哪一个邀请模板

  • 是否通过

  • 发送了哪一种消息

  • 是否回复

  • 回复是否有效

  • 是否进入需求、会议、报价和成交

  • 哪一类客户和话术更有效

三个层次必须共享同一套底层数据

不能做成三个互相没有关系的独立展示页面


三、明确产品边界

首期支持:

  • 手动录入

  • Excel或CSV导入

  • LinkedIn后台数据手动录入

  • 上传截图

  • AI识别截图后人工确认

  • 内容数据快照

  • 搜客批次

  • 连接邀请记录

  • 消息记录

  • 回复结果记录

  • 业务阶段推进

  • 规则提醒

  • AI复盘

  • 课堂演示Workspace

  • 学员练习Workspace

首期不做:

  • 未经LinkedIn许可的爬虫

  • 自动批量加好友

  • 自动群发私信

  • 自动抓取LinkedIn用户数据

  • 模拟不存在的官方API

  • 绕过平台限制

  • 开发信发送工具

  • 邮件群发系统

  • 自动代替用户联系客户

  • 纯粹为了展示的实时动画

  • 没有数据依据的AI结论

系统可以提供开发信和私信建议,但不承担自动发送


四、Workspace与使用角色

至少支持:

Workspace

例如:

  • 正式Workspace

  • 课程Demo Workspace

  • 学员练习Workspace

  • 不同产品线Workspace

字段包括:

  • workspace_name

  • workspace_type

  • company_name

  • timezone

  • default_language

  • reporting_week_start

  • created_at

  • updated_at

角色

  • Admin

  • Instructor

  • Member

  • Student

  • Viewer

权限要求:

Admin

管理全部数据、指标、规则和Workspace

Instructor

查看课程Workspace、创建模板、复制演示空间、查看学员提交结果

Member

维护自己的数据和复盘

Student

使用练习Workspace,不得修改原始演示模板

Viewer

只读


五、全局筛选体系

全局筛选至少包括:

  • 时间范围

  • LinkedIn账号

  • 产品线

  • ICP

  • 目标市场

  • 国家

  • 成员

  • 内容主题

  • 搜索项目

  • 开发批次

  • 业务阶段

  • 数据来源

要求:

  1. 全局筛选必须真实影响所有相关模块

  2. 筛选条件在页面切换后尽量保持

  3. 显示当前有效筛选

  4. 支持一键清除

  5. 支持保存常用视图

  6. 统计模块必须显示当前统计口径

  7. 不相关模块不能错误应用筛选

  8. 没有数据时显示空状态,而不是保留旧数字


六、核心数据模型

必须采用真实关系型数据库

不能使用一堆互不关联的总数字表

至少包括以下实体:

1. LinkedIn Account

字段:

  • id

  • workspace_id

  • account_name

  • linkedin_profile_url

  • owner_user_id

  • language

  • primary_market

  • primary_product_line

  • status

  • baseline_date

  • created_at

  • updated_at

2. Product Line产品线

字段:

  • id

  • workspace_id

  • name

  • category

  • description

  • target_market

  • primary_value_proposition

  • status

3. ICP客户画像

字段:

  • id

  • workspace_id

  • icp_name

  • product_line_id

  • country

  • region

  • industry

  • company_type

  • company_size

  • job_titles

  • seniority

  • decision_roles

  • pain_points

  • use_cases

  • exclusions

  • priority

  • status

ICP必须可以编辑

不能把演示ICP写死

4. Target Account目标公司

字段:

  • id

  • workspace_id

  • company_name

  • website

  • linkedin_url

  • country

  • industry

  • company_size

  • account_tier

  • icp_id

  • product_line_id

  • owner_user_id

  • relationship_status

  • opportunity_status

  • notes

  • created_at

  • updated_at

5. Prospect目标联系人

字段:

  • id

  • workspace_id

  • target_account_id

  • full_name

  • job_title

  • department

  • seniority

  • decision_role

  • linkedin_url

  • country

  • language

  • icp_id

  • product_line_id

  • search_project_id

  • search_batch_id

  • owner_user_id

  • relationship_status

  • current_outreach_stage

  • current_business_stage

  • last_action_at

  • next_action_at

  • created_at

  • updated_at

  • archived_at

6. Search Project搜客项目

字段:

  • id

  • workspace_id

  • project_name

  • account_id

  • product_line_id

  • icp_id

  • target_market

  • search_goal

  • search_keywords

  • search_filters

  • search_method

  • owner_user_id

  • start_date

  • end_date

  • status

  • hypothesis

  • conclusion

  • created_at

  • updated_at

7. Search Batch搜客批次

用于记录一次具体搜客动作

字段:

  • id

  • search_project_id

  • batch_name

  • searched_at

  • search_query

  • filters_snapshot

  • result_count

  • reviewed_count

  • qualified_count

  • rejected_count

  • added_count

  • owner_user_id

  • notes

  • created_at

必须能够回答:

  • 这批客户从哪里找到

  • 使用了什么关键词

  • 使用了什么筛选

  • 找到了多少人

  • 其中多少符合ICP

  • 后续通过率和回复率怎么样

8. Content Pillar内容支柱

例如:

  • 产品知识

  • 行业洞察

  • 客户问题

  • 案例

  • 供应链

  • 创始人观点

  • 中国制造

  • 市场分析

必须可配置

9. Post帖子

字段:

  • id

  • workspace_id

  • linkedin_account_id

  • product_line_id

  • target_icp_id

  • title

  • post_url

  • content

  • post_language

  • content_pillar_id

  • topic

  • format

  • hook_type

  • cta_type

  • has_image

  • has_video

  • has_document

  • has_external_link

  • published_at

  • status

  • owner_user_id

  • campaign_id

  • experiment_id

  • notes

  • created_at

  • updated_at

10. Post Snapshot帖子数据快照

这是核心实体

任何帖子数据更新都不能覆盖历史

字段:

  • id

  • post_id

  • snapshot_at

  • days_since_publish

  • impressions

  • members_reached

  • reactions

  • comments

  • reposts

  • saves

  • clicks

  • profile_views

  • follower_growth

  • connection_requests_received

  • direct_messages_received

  • target_account_engagements

  • target_prospect_engagements

  • leads_attributed

  • opportunities_attributed

  • data_source_id

  • source_note

  • imported_by

  • created_at

支持建议快照时间:

  • 发布后1天

  • 发布后3天

  • 发布后7天

  • 发布后14天

  • 发布后30天

  • 用户自定义时间

同一篇帖子必须显示:

  • 最新值

  • 较上次增长

  • 发布后的累计曲线

  • 每日或阶段增长速度

  • 快照历史

  • 数据来源

不得只保存一个固定浏览量

11. Content Interaction内容互动

用于将具体互动人与具体帖子建立关系

字段:

  • post_id

  • prospect_id

  • target_account_id

  • interaction_type

  • occurred_at

  • notes

  • data_source_id

互动类型包括:

  • Reaction

  • Comment

  • Repost

  • Profile Visit

  • Follow

  • Connection Request

  • Direct Message

  • Other

12. Connection Request连接邀请

字段:

  • id

  • workspace_id

  • prospect_id

  • sent_at

  • has_note

  • note_template_id

  • note_content

  • status

  • accepted_at

  • declined_at

  • expired_at

  • withdrawn_at

  • source_batch_id

  • owner_user_id

  • experiment_variant_id

  • outcome_note

  • created_at

  • updated_at

状态包括:

  • Planned

  • Sent

  • Pending

  • Accepted

  • Declined

  • Expired

  • Withdrawn

  • Unknown

13. Connection Note Template邀请备注模板

字段:

  • template_name

  • target_icp

  • target_market

  • product_line

  • content

  • status

  • version

  • created_at

  • updated_at

每次发送时必须保存模板版本快照

后续修改模板不能改变历史发送内容

14. Outreach Message开发消息

字段:

  • id

  • prospect_id

  • connection_request_id

  • sequence_id

  • message_template_id

  • template_version

  • message_content

  • message_type

  • sent_at

  • follow_up_round

  • owner_user_id

  • experiment_variant_id

  • created_at

消息类型:

  • First Message

  • First Follow-up

  • Second Follow-up

  • Third Follow-up

  • Long-term Nurture

  • Reply

  • Manual

15. Reply回复

字段:

  • id

  • prospect_id

  • outreach_message_id

  • replied_at

  • reply_content

  • reply_category

  • sentiment

  • business_intent

  • next_action

  • next_action_due_at

  • manually_confirmed

  • created_at

回复分类至少包括:

  • No Response

  • Polite Reply

  • Not Interested

  • Wrong Person

  • No Current Need

  • Future Interest

  • Product Interest

  • Price Inquiry

  • Clear Requirement

  • Meeting Interest

  • Sample Interest

  • Partnership Interest

  • Other

必须区分:

  • 回复率

  • 有效回复率

  • 正向回复率

  • 进入业务沟通率

不能把所有回复都当成有效回复

16. Business Opportunity业务机会

字段:

  • id

  • target_account_id

  • primary_prospect_id

  • product_line_id

  • source

  • source_post_id

  • source_search_project_id

  • source_connection_request_id

  • source_outreach_message_id

  • current_stage_id

  • estimated_value

  • currency

  • need_summary

  • next_action

  • next_action_due_at

  • owner_user_id

  • created_at

  • updated_at

17. Business Stage History

保存完整业务阶段变化

18. Task任务

支持:

  • 更新帖子快照

  • 发送连接邀请

  • 发送首条消息

  • 第一次跟进

  • 第二次跟进

  • 第三次跟进

  • 回复处理

  • 业务推进

  • 实验复盘

  • 周复盘

  • 数据清理

19. Experiment实验

字段:

  • id

  • workspace_id

  • experiment_name

  • experiment_type

  • hypothesis

  • primary_metric

  • secondary_metrics

  • start_date

  • end_date

  • target_icp

  • target_market

  • sample_target

  • status

  • conclusion

  • decision

  • next_experiment

  • created_by

  • created_at

  • updated_at

实验类型:

  • Content Topic

  • Post Format

  • Hook

  • CTA

  • Posting Time

  • Connection Note

  • No Note vs Note

  • First Message

  • Follow-up Message

  • Target Market

  • Job Title

  • Search Keyword

  • ICP

20. Experiment Variant

每个实验至少有两个变体或一个基线

21. Insight复盘结论

字段:

  • insight_type

  • related_entity

  • observation

  • evidence

  • sample_size

  • confidence

  • recommendation

  • user_decision

  • created_at

22. Data Source数据来源

数据来源必须可以修改

字段:

  • source_name

  • source_type

  • import_method

  • linked_account

  • field_mapping

  • owner_user_id

  • last_imported_at

  • status

  • notes

默认类型:

  • Manual

  • Excel

  • CSV

  • Screenshot

  • LinkedIn Export

  • Course Demo

  • Other

23. Import Job导入任务

保存:

  • 文件

  • 字段映射

  • 导入时间

  • 成功数量

  • 失败数量

  • 跳过数量

  • 错误报告

  • 操作者

24. Audit Log

保存关键修改和删除操作


七、指标字典

创建METRIC_DICTIONARY.md

每个指标必须定义:

  • 中文名称

  • 英文名称

  • 业务含义

  • 计算公式

  • 分子

  • 分母

  • 时间口径

  • 数据来源

  • 是否可手动调整

  • 是否适合跨账号比较

  • 常见误解

至少定义以下指标:

内容指标

  • 帖子数量

  • 展示量

  • 触达人数

  • 互动量

  • 互动率

  • 评论率

  • 转发率

  • 主页访问率

  • 关注转化率

  • 连接转化率

  • 目标客户互动数量

  • 目标客户互动率

  • 帖子带来的私信

  • 帖子影响的商机

  • 内容业务贡献率

不能默认把展示量等同于触达人数

不能把所有互动都视为目标客户互动

搜客指标

  • 搜索结果数量

  • 已审查人数

  • ICP合格人数

  • ICP合格率

  • 实际添加人数

连接指标

  • 发送邀请数

  • 接受数

  • 接受率

  • 带备注接受率

  • 不带备注接受率

  • 待处理数

  • 过期数

接受率公式必须明确:

接受数 ÷ 已经产生明确结果或者进入统计窗口的发送数

需要避免刚发出的邀请大量进入分母,导致短期数据失真

消息指标

  • 首条消息发送数

  • 回复数

  • 回复率

  • 有效回复数

  • 有效回复率

  • 正向回复数

  • 正向回复率

  • 进入需求沟通数

  • 进入会议数

  • 进入报价数

  • 成交数

业务指标

  • LinkedIn线索数

  • 有效商机数

  • 报价数

  • 样品数

  • 成交数

  • 商机转化率

  • 成交金额

  • 平均推进周期

  • 阶段停留时间

执行指标

  • 今日任务

  • 完成任务

  • 逾期任务

  • 跟进及时率

  • 数据更新及时率

  • 未设置下一步动作的客户

所有指标必须支持查看计算明细


八、动态帖子数据系统

这是对当前版本必须重点升级的部分

数据录入

用户创建帖子以后,可以:

  • 手动添加快照

  • Excel导入快照

  • 上传LinkedIn后台截图

  • 由AI识别截图

  • 进入人工确认页

  • 确认后写入数据库

截图识别流程

  1. 上传截图

  2. 识别可能的帖子

  3. 识别日期

  4. 识别数据字段

  5. 标记低置信度字段

  6. 用户人工检查

  7. 用户选择对应帖子

  8. 确认保存

  9. 生成快照

  10. 更新趋势图

不得未经确认直接入库

帖子详情页

必须显示:

  • 帖子内容

  • 发布时间

  • 目标ICP

  • 内容支柱

  • 内容形式

  • CTA

  • 所有数据快照

  • 增长曲线

  • 相邻快照变化

  • 目标客户互动

  • 相关联系人

  • 相关商机

  • 内容结论

  • 下一步建议

内容表现判断

不能只按照浏览量判断

需要同时区分:

高曝光、高业务价值

值得继续复制

高曝光、低业务价值

可能吸引了错误人群

低曝光、高目标客户质量

可能是小众但高价值内容

低曝光、低业务价值

需要调整主题、形式或者分发

系统必须允许用户自己调整判断阈值

不能把阈值写死


九、内容运营漏斗

默认内容漏斗:

帖子发布
→ 展示
→ 互动
→ 目标客户互动
→ 主页访问
→ 关注或连接
→ 私信
→ 业务线索
→ 有效商机
→ 报价
→ 成交

要求:

  1. 每一层必须说明数据来源

  2. 每一层可以点击查看具体记录

  3. 无法自动确定的关系允许人工关联

  4. 不能把互不关联的总数字组成漏斗

  5. 必须区分“直接归因”和“影响归因”

  6. 必须显示未知来源

  7. 不得强行把所有商机归因给某一篇帖子


十、内容与业务归因模型

创建ATTRIBUTION_MODEL.md

至少支持:

1. Direct直接归因

客户明确:

  • 通过某篇帖子私信

  • 在帖子评论后联系

  • 表示看到具体帖子

  • 从帖子CTA进入下一步

2. Influenced影响归因

客户在建立联系前:

  • 互动过帖子

  • 访问过主页

  • 关注过账号

  • 多次接触内容

但无法证明由某一篇帖子直接产生

3. Manual人工归因

用户根据沟通手动选择来源

4. Unknown未知

无法判断时必须保留未知

每条归因需要保存:

  • Attribution Type

  • Related Post

  • Confidence

  • Evidence

  • Confirmed By

  • Confirmed At

不得使用虚假的精确归因


十一、搜客与开发动作系统

搜客项目

每个搜客项目必须先定义:

  • 产品线

  • 市场

  • ICP

  • 目标职位

  • 公司类型

  • 搜索关键词

  • 筛选条件

  • 假设

  • 目标数量

  • 成功指标

搜客批次

每一次实际搜客都创建批次

用户可以给联系人打标:

  • ICP匹配

  • 可能匹配

  • 不匹配

  • 错误职位

  • 错误行业

  • 公司过小

  • 公司过大

  • 竞争对手

  • 供应商

  • 同行

  • 信息不足

系统最终需要形成结论:

  • 哪一个关键词找到的目标客户质量更高

  • 哪一个职位匹配度更高

  • 哪个市场接受率更好

  • 哪个批次产生的业务结果更好

不能只记录“搜了多少人”


十二、连接邀请与邀请备注测试

必须支持:

  • 带备注

  • 不带备注

  • 多个备注模板

  • 模板版本

  • A/B实验

  • 不同ICP使用不同模板

  • 不同市场使用不同模板

每条邀请必须与具体联系人关联

必须记录结果:

  • Pending

  • Accepted

  • Declined

  • Expired

  • Withdrawn

  • Unknown

模板分析必须展示:

  • 发送量

  • 已产生结果数量

  • 接受量

  • 接受率

  • 对应ICP

  • 对应市场

  • 后续首条消息回复率

  • 有效回复率

  • 商机数

  • 报价数

不能仅凭接受率判断模板优劣

因为接受以后是否产生有效沟通同样重要


十三、开发消息与回复结果系统

每一条开发消息必须记录:

  • 发送给谁

  • 发送时间

  • 消息类型

  • 使用模板

  • 模板版本

  • 是否人工修改

  • 属于第几轮跟进

  • 是否回复

  • 回复时间

  • 回复分类

  • 是否有效回复

  • 是否进入业务阶段

  • 下一步动作

消息序列

默认支持:

  1. 首条消息

  2. 第一次跟进

  3. 第二次跟进

  4. 第三次跟进

  5. 长期培育

用户可以修改时间规则

系统不得自动发送

回复分类

AI可以建议分类,但必须允许人工确认

系统必须重点区分:

  • 有回复

  • 有效回复

  • 正向回复

  • 明确需求

  • 会议

  • 报价

  • 成交

不能用一个“回复率”掩盖所有结果差异


十四、实体级漏斗与下钻

所有漏斗必须由具体实体和事件生成

默认业务漏斗:

已发现目标客户
→ 已审核符合ICP
→ 已发送连接邀请
→ 已接受连接
→ 已发送首条消息
→ 已收到回复
→ 有效回复
→ 需求沟通
→ 会议
→ 报价
→ 样品
→ 谈判
→ 成交

要求:

  1. 点击每一层查看具体联系人

  2. 查看进入时间

  3. 查看从上一阶段进入的路径

  4. 查看没有进入下一阶段的人

  5. 查看流失原因

  6. 查看阶段平均停留时间

  7. 支持按市场、ICP、模板、成员、产品线筛选

  8. 阶段变化写入历史

  9. 同一联系人不能在同一漏斗层重复计数

  10. 统计分母必须明确

  11. 时间范围逻辑必须明确

  12. 漏斗顶部和底部必须来自同一统计范围

确认进入下一级

系统需要提供明确动作:

  • 确认已接受

  • 确认已发送首条消息

  • 确认已回复

  • 确认有效回复

  • 确认进入需求沟通

  • 确认进入报价

  • 确认成交

用户确认后:

  1. 更新当前状态

  2. 写入阶段历史

  3. 更新时间

  4. 生成下一步任务

  5. 重新计算相关指标

不能让漏斗只显示数字而无法推进实体


十五、今日行动中心

首页第一屏不应当被超大数字占据

必须优先展示:

1. 今天要完成

包括:

  • 新接受但未发首条消息

  • 已回复但未处理

  • 有效回复但没有下一步动作

  • 报价后需要跟进

  • 长时间没有推进

  • 今天需要发送第一次、第二次或第三次跟进

  • 今天需要更新帖子快照

  • 今天需要复盘的实验

2. 已逾期

显示:

  • 联系人

  • 当前阶段

  • 逾期动作

  • 逾期天数

  • 触发原因

  • 推荐动作

3. 业务停滞

例如:

  • 接受连接后超过24小时未发消息

  • 收到回复后超过24小时未处理

  • 有效回复后没有业务阶段

  • 报价后超过3天无动作

  • 进入需求沟通后没有下一步任务

4. 数据缺失

例如:

  • 帖子没有按计划更新

  • 连接邀请没有记录结果

  • 消息发送后没有更新回复状态

  • 联系人没有ICP

  • 商机没有来源

  • 漏斗阶段缺少时间

5. 本周实验

显示:

  • 实验名称

  • 进度

  • 样本量

  • 当前结果

  • 是否达到最低判断条件

  • 何时复盘


十六、运营看板

运营看板至少包括:

内容生产

  • 发布数量

  • 内容支柱分布

  • 内容形式分布

  • 产品线分布

  • ICP分布

  • 发布节奏

内容结果

  • 展示

  • 触达

  • 互动

  • 目标客户互动

  • 主页访问

  • 关注

  • 连接

  • 私信

  • 商机

动态趋势

按帖子发布后:

  • 1天

  • 3天

  • 7天

  • 14天

  • 30天

比较增长表现

内容排行榜

允许按以下指标排序:

  • 展示量

  • 互动率

  • 目标客户互动率

  • 主页访问率

  • 连接转化率

  • 商机数量

  • 业务价值

不要只提供“热门帖子”

需要提供:

  • 高曝光内容

  • 高目标客户质量内容

  • 高业务价值内容

  • 需要复盘内容

内容建议

规则引擎和AI结合输出:

  • 应继续的主题

  • 应减少的主题

  • 值得二次创作的帖子

  • 需要更新数据的帖子

  • 样本不足的判断

  • 下周建议测试


十七、业务看板

业务看板至少包括:

搜客

  • 搜索项目

  • 搜索批次

  • 已审核人数

  • ICP合格率

  • 不同关键词质量

连接

  • 邀请发送

  • 接受

  • 接受率

  • 带备注与不带备注

  • 不同模板

  • 不同市场

  • 不同ICP

消息

  • 首条消息

  • 回复

  • 有效回复

  • 正向回复

  • 不同模板结果

  • 不同跟进轮次结果

商机

  • 需求

  • 会议

  • 报价

  • 样品

  • 谈判

  • 成交

停滞

  • 已接受未沟通

  • 已回复未处理

  • 有效回复未推进

  • 报价后无动作

  • 长期无联系

业务价值

  • 商机数量

  • 预计金额

  • 成交金额

  • LinkedIn来源占比

  • 不同ICP业务价值

  • 不同市场业务价值

所有数字必须可下钻


十八、实验系统

每个实验必须包含:

  • 明确假设

  • 单一主要变量

  • 主要指标

  • 次要指标

  • 样本目标

  • 开始时间

  • 结束条件

  • 变体

  • 结果

  • 结论

  • 下一步决策

示例一:带备注与不带备注

假设:

针对巴西农业设备经销商,不带备注的接受率不会明显低于带备注,但接受后的有效回复率可能不同

主要指标:

  • 接受率

次要指标:

  • 首条消息回复率

  • 有效回复率

  • 商机率

示例二:开发消息A/B

比较:

  • 产品导向开场

  • 客户场景导向开场

不能只比较回复率

还需要比较:

  • 有效回复率

  • 进入需求沟通率

  • 报价率

样本量提示

系统必须警告:

  • 样本不足

  • 时间窗口过短

  • 两组ICP分布不一致

  • 两组市场不一致

  • 数据缺失

  • 结果差异不明显

不要让AI在样本只有三五条时得出确定结论


十九、自动化提醒规则

默认规则:

帖子数据更新

  • 发布后1天提醒更新

  • 发布后3天提醒更新

  • 发布后7天提醒更新

  • 发布后14天提醒更新

  • 发布后30天提醒更新

已经存在对应日期附近快照时,不重复提醒

新连接

连接接受后24小时未发首条消息:

  • 创建高优先级任务

首条消息无回复

发送3天无回复:

  • 创建第一次跟进任务

第一次跟进7天无回复:

  • 创建第二次跟进任务

第二次跟进10天无回复:

  • 创建第三次跟进任务

之后建议长期培育,由用户确认

收到回复

收到回复后24小时未分类或未设置下一步:

  • 创建处理任务

有效回复

确认有效回复以后:

  • 必须设置业务阶段

  • 必须设置下一步动作

  • 必须设置截止时间

报价跟进

报价后3天无动作:

  • 创建高优先级任务

实验复盘

达到结束时间或者样本目标:

  • 创建实验复盘任务

去重

同一个联系人、同一类型动作、同一时间窗口只生成一个任务

多个原因可以合并显示


二十、AI能力

AI必须基于真实数据

AI周复盘

输出:

  • 本周做了什么

  • 哪个环节表现最好

  • 哪个漏斗环节流失最大

  • 哪个市场表现更好

  • 哪类ICP接受率更高

  • 哪种话术有效回复率更高

  • 哪些帖子产生目标客户互动

  • 哪些内容产生业务机会

  • 哪些判断样本不足

  • 下周继续、停止和测试什么

AI帖子分析

基于:

  • 帖子主题

  • 内容形式

  • 目标ICP

  • 数据快照

  • 目标客户互动

  • 商机归因

不能只说:

“这篇帖子表现很好,建议继续优化内容”

必须给出:

  • 数据事实

  • 相对表现

  • 可能原因

  • 不确定性

  • 下一步建议

AI开发分析

基于:

  • 搜客项目

  • ICP

  • 邀请模板

  • 是否带备注

  • 消息模板

  • 回复分类

  • 商机结果

输出:

  • 哪些动作值得继续

  • 哪些动作没有产生结果

  • 可能的目标客户偏差

  • 可能的话术问题

  • 下一轮实验建议

AI回复分类

AI可以:

  • 识别礼貌回复

  • 识别拒绝

  • 识别未来兴趣

  • 识别明确需求

  • 识别价格询问

  • 识别会议意向

但结果必须可修改

AI边界

AI不得:

  • 编造LinkedIn数据

  • 编造客户行为

  • 自动发送消息

  • 自动修改成交状态

  • 在样本不足时下确定结论

  • 把相关性描述为因果关系

  • 虚构内容与商机归因

每条AI结论显示:

  • 依据数据

  • 样本量

  • 时间范围

  • 置信度

  • 缺失数据


二十一、数据录入和导入

手动录入

表单应当简洁

允许快速录入后再补充

Excel或CSV导入

分别提供模板:

  • 帖子

  • 帖子快照

  • 搜客批次

  • 联系人

  • 连接邀请

  • 消息

  • 回复

  • 商机

导入流程:

  1. 上传

  2. 选择数据类型

  3. 字段映射

  4. 预览

  5. 校验

  6. 重复检查

  7. 确认

  8. 结果报告

截图导入

支持:

  • 帖子数据截图

  • LinkedIn后台统计截图

  • 联系人截图

  • 消息截图

所有识别内容必须人工确认

数据来源管理

用户可以:

  • 新增数据来源

  • 修改名称

  • 修改字段映射

  • 停用来源

  • 查看最近导入

  • 查看错误记录

不能出现“数据来源无法修改”的情况


二十二、页面结构

建议至少包括:

  1. 今日行动

  2. 综合总览

  3. 运营看板

  4. 帖子列表

  5. 帖子详情

  6. 内容日历

  7. 搜客项目

  8. 搜客批次

  9. 联系人列表

  10. 联系人详情

  11. 连接邀请

  12. 开发消息

  13. 回复中心

  14. 业务看板

  15. 业务漏斗

  16. 商机列表

  17. 实验中心

  18. 周复盘

  19. 数据导入

  20. 数据来源

  21. 指标设置

  22. 自动化规则

  23. Workspace和成员

  24. 演示数据管理

避免导航过多

可以按照:

  • 今日工作

  • 内容运营

  • 客户开发

  • 业务转化

  • 分析复盘

  • 数据与设置

进行分组


二十三、UI和视觉要求

整体风格:

  • B2B

  • 专业

  • 清晰

  • 克制

  • 适合教学和长期使用

  • 信息密度合理

  • 视觉层级明确

禁止:

  • 超大数字

  • 卡片占满整屏

  • 大量无意义渐变

  • 过多装饰图标

  • 只有图表没有表格明细

  • 把所有内容塞在总览页

  • 颜色过多

  • 只适合演示、不适合工作

要求:

  1. 关键数字大小适中

  2. 重要异常和行动比累计数字更醒目

  3. 所有图表都有标题、口径和时间范围

  4. 图表可以下钻

  5. 表格支持筛选和自定义列

  6. 筛选栏保持清晰

  7. 空状态给出下一步动作

  8. 表单有校验

  9. 保存有反馈

  10. 未保存离开有提醒

  11. 手机端可以查看今日任务、更新结果和记录回复

  12. 中文界面为默认

  13. 英文客户字段、ICP、职位、关键词和话术正常显示


二十四、演示和课程模式

由于产品用于课程和会员,需要支持:

Demo Workspace

  • 明确显示演示标识

  • 一键复制

  • 一键重置

  • 不影响原始模板

  • 示例数据覆盖内容和业务完整流程

学员Workspace

  • 学员只能编辑自己的空间

  • 可以导出数据

  • 可以提交周复盘

  • 可以复制老师提供的指标和规则模板

教学解释

重要指标可以提供简短说明:

  • 这个指标是什么

  • 为什么重要

  • 如何计算

  • 应该如何行动

但不要让教学说明长期占据大量页面空间

可以使用Tooltip、帮助侧栏或学习模式


二十五、必须完成的验收场景

场景一:帖子动态数据

  1. 创建帖子

  2. 添加发布后1天快照

  3. 添加3天快照

  4. 添加7天快照

  5. 刷新页面

  6. 历史快照全部保留

  7. 趋势图正确

  8. 最新值正确

  9. 删除3天快照不影响其他快照

  10. 不得覆盖历史数据

场景二:内容产生业务机会

  1. 创建帖子

  2. 创建目标联系人

  3. 记录联系人互动该帖子

  4. 记录对方访问主页

  5. 记录对方建立连接

  6. 记录私信

  7. 创建业务机会

  8. 归因为Influenced

  9. 在帖子详情查看对应商机

  10. 在商机详情查看对应帖子

场景三:连接邀请实验

  1. 创建邀请备注A

  2. 创建邀请备注B

  3. 创建不带备注组

  4. 分别发送给不同联系人

  5. 记录接受与拒绝

  6. 记录首条消息

  7. 记录回复

  8. 分类有效回复

  9. 进入业务阶段

  10. 查看接受率、有效回复率和商机率

  11. 样本不足时必须提示

场景四:漏斗下钻

  1. 创建20个联系人

  2. 其中15个符合ICP

  3. 发送12个邀请

  4. 8个接受

  5. 7个发送首条消息

  6. 4个回复

  7. 2个有效回复

  8. 1个进入报价

  9. 点击每一个漏斗层

  10. 查看正确的具体联系人

  11. 所有数字与联系人数量一致

场景五:今日行动

  1. 创建接受后超过24小时未发消息的联系人

  2. 创建回复后未处理的联系人

  3. 创建报价后超过3天未跟进的商机

  4. 创建今天需要更新帖子数据的帖子

  5. 首页显示对应任务

  6. 完成任务后从待办中消失

  7. 相关实体状态正确更新

场景六:截图录入

  1. 上传帖子统计截图

  2. AI提取数据

  3. 标记低置信度字段

  4. 人工修改

  5. 选择对应帖子

  6. 确认保存

  7. 生成新快照

  8. 保存原截图来源

场景七:全局筛选

  1. 创建两个账号

  2. 创建两个产品线

  3. 创建两个ICP

  4. 创建不同成员数据

  5. 切换筛选

  6. 看板、图表、列表和漏斗同步变化

  7. 清除筛选恢复完整数据

  8. 不得出现旧数据残留


二十六、测试要求

每个里程碑必须运行:

  • TypeScript检查

  • ESLint

  • 单元测试

  • API测试

  • 数据库测试

  • Playwright端到端测试

  • Production Build

重点测试:

  • 帖子快照

  • 动态趋势

  • 搜客批次

  • 邀请结果

  • 消息序列

  • 回复分类

  • 漏斗下钻

  • 阶段历史

  • 任务生成

  • 任务去重

  • 全局筛选

  • Excel导入

  • 截图确认

  • Workspace隔离

  • 演示数据重置

  • 移动端

报告必须说明:

  • 测试命令

  • 通过数量

  • 失败数量

  • 未覆盖范围

  • 浏览器实际验证

  • 已知问题


二十七、实施里程碑

Milestone 0:审计现有版本

输出:

  • 当前页面地图

  • 当前数据模型

  • 真实功能

  • 静态功能

  • 无效按钮

  • 数据问题

  • 漏斗问题

  • 动态帖子问题

  • 可保留功能

  • 重构建议

Milestone 1:数据基础

完成:

  • Workspace

  • Account

  • Product Line

  • ICP

  • Target Account

  • Prospect

  • Data Source

  • Audit Log

Milestone 2:内容运营闭环

完成:

  • Post

  • Post Snapshot

  • 帖子列表

  • 帖子详情

  • 动态趋势

  • 快照更新任务

Milestone 3:搜客与连接闭环

完成:

  • Search Project

  • Search Batch

  • Prospect

  • Connection Request

  • Note Template

  • 结果记录

Milestone 4:消息与回复闭环

完成:

  • Message Template

  • Outreach Message

  • Follow-up Round

  • Reply

  • Reply Classification

  • 下一步动作

Milestone 5:业务漏斗

完成:

  • Opportunity

  • Business Stage

  • Stage History

  • 漏斗下钻

  • 阶段确认

  • 停滞识别

Milestone 6:今日行动与自动化

完成:

  • Task

  • 自动化规则

  • 任务去重

  • 逾期

  • 数据更新提醒

  • 业务推进提醒

Milestone 7:实验和复盘

完成:

  • Experiment

  • Variant

  • 样本量提示

  • 结论

  • 周复盘

  • AI建议

Milestone 8:导入与截图

完成:

  • Excel

  • CSV

  • 字段映射

  • 错误报告

  • 截图识别确认

Milestone 9:课程模式和全面QA

完成:

  • Demo Workspace

  • 学员复制

  • 重置演示数据

  • 导出

  • 全流程测试

  • 响应式检查

  • 部署


二十八、绝对禁止事项

禁止:

  1. 把看板做成静态数据大屏

  2. 使用特别大的数字占据页面

  3. 帖子数据只能录入一次

  4. 新数据覆盖旧帖子数据

  5. 数据来源无法修改

  6. 漏斗数字无法点击

  7. 漏斗各层来自互不相关的总数

  8. 只能记录发送动作,不能记录结果

  9. 只能记录回复,不能区分有效回复

  10. 只比较接受率,不比较业务结果

  11. 不保存模板版本

  12. 修改模板后历史消息一起变化

  13. AI在样本不足时下确定结论

  14. 把相关性说成因果关系

  15. 把所有商机强制归因给帖子

  16. 虚构LinkedIn API

  17. 开发自动批量加好友或群发功能

  18. 使用假实时数据

  19. 创建无功能按钮

  20. 只做图表,没有明细

  21. 只做内容运营,不做业务推进

  22. 只做业务数据,不记录内容影响

  23. 只为了课程演示,不考虑真实连续使用

  24. 把Demo数据与真实数据混合

  25. 修改一个筛选条件但部分模块不更新


二十九、每个里程碑的汇报格式

已完成

关键文件

数据库变化

指标和公式变化

浏览器验证

自动化测试

尚未完成

已知问题

下一步

所有未完成内容必须明确说明

不得使用“基本完成”掩盖未实现功能


现在开始

第一步只完成:

  1. 审计当前项目

  2. 运行当前系统

  3. 逐页测试当前功能

  4. 创建PRODUCT_SPEC.md

  5. 创建DATA_MODEL.md

  6. 创建METRIC_DICTIONARY.md

  7. 创建FUNNEL_DEFINITIONS.md

  8. 创建ATTRIBUTION_MODEL.md

  9. 创建AGENTS.md

  10. 创建PLAN.md

  11. 创建TEST_PLAN.md

  12. 输出当前版本与本需求的完整差距分析

  13. 输出分阶段实施计划

在完成产品、数据和指标设计以前,不要开始大规模重写页面



十四、效果出来以后,应该怎么修改

很多人用Codex做完第一版以后,会陷入两种极端

第一种是觉得太神奇了

页面能打开,按钮能点击,于是认为项目已经完成

第二种是发现页面不好看或者功能不符合预期,马上让Codex全部重做

这两种方式都不太对

第一版的意义,不是直接交付最终产品

第一版的意义,是让你第一次看到自己原本模糊的想法

当一个想法只存在于脑子里时,我们很难发现问题

但当它变成页面以后,问题会立刻暴露出来

数字是不是太大

首页是不是没有重点

数据是不是无法修改

按钮是不是只能点击但没有结果

漏斗是不是无法确认到下一级

帖子数据是不是被做成了静态值

开发信是不是只记录发送,没有记录回复

系统是不是展示了很多数据,却没有告诉我今天应该做什么

这时候,修改不要只说:

“帮我优化一下”

也不要只说:

“页面不够高级”

更有效的反馈方式是四步

第一步:描述现象

例如:

帖子详情页目前只保存一个浏览量数字,后续更新会覆盖之前的数据

第二步:说明为什么这是问题

我需要观察帖子发布后1天、3天、7天和30天的数据变化,判断内容是短期爆发还是长期增长

第三步:说明期望行为

每一次更新都应该生成一个带日期的数据快照,历史快照不能被覆盖,并在详情页显示增长曲线

第四步:给出验收标准

创建一篇帖子以后,我可以连续添加三次不同日期的数据

刷新页面后数据仍然存在

图表能够按照日期显示变化

删除某一个快照不会影响其他记录

这种详细而又实际的反馈,Codex最容易理解

所以,修改一个系统最有效的表达结构是:

现象——影响——期望行为——验收标准


十五、不要只看演示,要使用真实数据

我现在越来越警惕一种产品状态

叫作“演示起来很好看”

首页有数字

漏斗有颜色

图表会变化

客户列表里有几十条示例数据

AI还会自动生成一段非常专业的总结

但当你真正把自己的客户放进去,就会发现:

有些字段无法编辑

数据刷新以后消失

漏斗数字和客户列表对不上

删除客户以后统计没有变化

任务完成以后仍然显示逾期

帖子只能保存一次数据

同一个客户触发了五条重复提醒

手机端完全无法操作

这就是演示产品和工作产品之间的区别

演示产品的目标,是让你在30秒内觉得厉害

工作产品的目标,是让你连续使用三个月以后,仍然觉得离不开

所以,第一版完成以后,我建议不要马上增加更多功能

先放入真实数据,连续使用一周

每天记录:

哪个地方让我多操作了一步

哪个地方让我找不到信息

哪个字段从来没有使用

哪个动作经常被忘记

哪个提醒过于频繁

哪个判断仍然需要回到Excel完成

哪个图表看起来不错但没有帮助我做决定

一周以后,再把这些真实问题交给Codex

这时候的修改,才是真正有价值的修改


十六、未来最值钱的,不是软件,而是你的工作逻辑

有人可能会说:

自己做CRM和看板,真的有必要吗

市场上不是已经有很多成熟工具了吗

当然有

但对我来说,这件事情最大的价值,可能还不是最终做出了一个CRM或者LinkedIn看板

而是在搭建系统的过程中,我被迫重新审视了自己的工作

我必须回答:

什么样的客户值得优先跟进

什么叫有效回复

客户多久没有联系算停滞

报价以后最合适的跟进时间是多少

LinkedIn哪些数据真正有意义

内容和业务之间应该如何建立关联

什么叫目标客户

什么叫一次有效开发动作

哪些结论来自经验

哪些结论可以被数据验证

以前,这些东西可能存在于一个优秀业务员的脑子里

他知道什么时候应该追客户

知道什么样的回复意味着有机会

知道什么样的询盘大概率没有价值

但这些经验没有被说出来,也没有被系统记录下来

所以新人无法复制

管理者无法检查

团队无法优化

AI也无法参与

而当我们开始和GPT、Codex持续Talking时,我们实际上是在做一件非常重要的事情:

把隐性的个人经验,变成显性的业务规则

一旦这些规则被说清楚,它们就可以被写进系统

可以被提醒

可以被复盘

可以被新人使用

可以被不断优化

这才是我认为Codex真正有价值的地方

它当然可以帮我们建站

可以做页面

可以写代码

可以制作各种看起来很厉害的工具

但更深层的价值是,它让一个不懂代码的人,也第一次拥有了把工作方法变成体系变成软件的可能


十七、最后再说一次:CRM不是为了记录客户

CRM不是为了证明我们拥有多少客户

而是为了让我们知道,下一个最值得推进的客户是谁

LinkedIn看板也不是为了证明我们发布了多少内容、添加了多少好友、发送了多少消息

所以,不管你准备做CRM、LinkedIn看板,还是任何其他内部系统,都可以先问自己一个问题:

当我打开这个系统时,它准备推动我完成什么动作

如果这个问题没有答案,系统做得再漂亮,也只是一个电子档案柜


当一个人真正学会了如何梳理业务、定义流程、设计数据、建立规则、提出要求和验收结果以后

建站反而会成为一件相对简单的事情

会员群里的下一课,我会开始讲:

如何用Codex从零搭建一个真正能获得客户的B2B独立站

不是做一个首页

不是套一个模板

也不是让AI生成一堆看起来正确的文案

而是从客户是谁、客户为什么购买、网站应该如何承接搜索、内容如何建立信任、页面如何推动询盘开始

一步一步,把网站也做成另一套真正能够推动业务的系统

【声明】内容源于网络
0
0
一人外贸团队
内容 37
粉丝 0
一人外贸团队
总阅读116
粉丝0
内容37