澎湃的另一位老师开了一个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导入
邮件
展会
老客户转介绍
不同来源需要不同字段和不同跟进节奏
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运营与业务增长双看板
它必须同时覆盖:
内容运营
搜客动作
连接邀请
私信与开发消息
回复结果
客户推进
商机转化
实验复盘
今日行动
下一步优化
整个产品的核心原则是:
LinkedIn数据不是为了证明做了多少,而是为了判断什么有效、什么无效,以及下一步应该做什么
一、开始工作前的强制要求
不要直接生成更多图表、数字卡片或演示数据
请先:
检查当前代码仓库
运行当前项目
使用浏览器完整操作现有系统
检查所有页面、按钮、弹窗、表单、筛选器和数据来源
检查数据是否真实持久化
检查刷新页面后数据是否丢失
检查漏斗各层是否来自同一批真实记录
检查所有统计数字是否可以下钻
检查帖子数据是否支持多次更新
检查连接邀请、开发消息和回复结果是否建立关系
检查课程演示数据与用户真实数据是否隔离
检查筛选时间、账号、产品线、ICP和成员后,所有模块是否同步变化
检查数据来源是否可以修改
检查所有新增、编辑、删除和导入是否真实有效
创建并长期维护:
PRODUCT_SPEC.mdPLAN.mdAGENTS.mdDATA_MODEL.mdMETRIC_DICTIONARY.mdFUNNEL_DEFINITIONS.mdATTRIBUTION_MODEL.mdAUTOMATION_RULES.mdAI_BEHAVIOR.mdTEST_PLAN.mdCHANGELOG.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. 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识别截图
进入人工确认页
确认后写入数据库
截图识别流程
上传截图
识别可能的帖子
识别日期
识别数据字段
标记低置信度字段
用户人工检查
用户选择对应帖子
确认保存
生成快照
更新趋势图
不得未经确认直接入库
帖子详情页
必须显示:
帖子内容
发布时间
目标ICP
内容支柱
内容形式
CTA
所有数据快照
增长曲线
相邻快照变化
目标客户互动
相关联系人
相关商机
内容结论
下一步建议
内容表现判断
不能只按照浏览量判断
需要同时区分:
高曝光、高业务价值
值得继续复制
高曝光、低业务价值
可能吸引了错误人群
低曝光、高目标客户质量
可能是小众但高价值内容
低曝光、低业务价值
需要调整主题、形式或者分发
系统必须允许用户自己调整判断阈值
不能把阈值写死
九、内容运营漏斗
默认内容漏斗:
帖子发布
→ 展示
→ 互动
→ 目标客户互动
→ 主页访问
→ 关注或连接
→ 私信
→ 业务线索
→ 有效商机
→ 报价
→ 成交
要求:
每一层必须说明数据来源
每一层可以点击查看具体记录
无法自动确定的关系允许人工关联
不能把互不关联的总数字组成漏斗
必须区分“直接归因”和“影响归因”
必须显示未知来源
不得强行把所有商机归因给某一篇帖子
十、内容与业务归因模型
创建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
对应市场
后续首条消息回复率
有效回复率
商机数
报价数
不能仅凭接受率判断模板优劣
因为接受以后是否产生有效沟通同样重要
十三、开发消息与回复结果系统
每一条开发消息必须记录:
发送给谁
发送时间
消息类型
使用模板
模板版本
是否人工修改
属于第几轮跟进
是否回复
回复时间
回复分类
是否有效回复
是否进入业务阶段
下一步动作
消息序列
默认支持:
首条消息
第一次跟进
第二次跟进
第三次跟进
长期培育
用户可以修改时间规则
系统不得自动发送
回复分类
AI可以建议分类,但必须允许人工确认
系统必须重点区分:
有回复
有效回复
正向回复
明确需求
会议
报价
成交
不能用一个“回复率”掩盖所有结果差异
十四、实体级漏斗与下钻
所有漏斗必须由具体实体和事件生成
默认业务漏斗:
已发现目标客户
→ 已审核符合ICP
→ 已发送连接邀请
→ 已接受连接
→ 已发送首条消息
→ 已收到回复
→ 有效回复
→ 需求沟通
→ 会议
→ 报价
→ 样品
→ 谈判
→ 成交
要求:
点击每一层查看具体联系人
查看进入时间
查看从上一阶段进入的路径
查看没有进入下一阶段的人
查看流失原因
查看阶段平均停留时间
支持按市场、ICP、模板、成员、产品线筛选
阶段变化写入历史
同一联系人不能在同一漏斗层重复计数
统计分母必须明确
时间范围逻辑必须明确
漏斗顶部和底部必须来自同一统计范围
确认进入下一级
系统需要提供明确动作:
确认已接受
确认已发送首条消息
确认已回复
确认有效回复
确认进入需求沟通
确认进入报价
确认成交
用户确认后:
更新当前状态
写入阶段历史
更新时间
生成下一步任务
重新计算相关指标
不能让漏斗只显示数字而无法推进实体
十五、今日行动中心
首页第一屏不应当被超大数字占据
必须优先展示:
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导入
分别提供模板:
帖子
帖子快照
搜客批次
联系人
连接邀请
消息
回复
商机
导入流程:
上传
选择数据类型
字段映射
预览
校验
重复检查
确认
结果报告
截图导入
支持:
帖子数据截图
LinkedIn后台统计截图
联系人截图
消息截图
所有识别内容必须人工确认
数据来源管理
用户可以:
新增数据来源
修改名称
修改字段映射
停用来源
查看最近导入
查看错误记录
不能出现“数据来源无法修改”的情况
二十二、页面结构
建议至少包括:
今日行动
综合总览
运营看板
帖子列表
帖子详情
内容日历
搜客项目
搜客批次
联系人列表
联系人详情
连接邀请
开发消息
回复中心
业务看板
业务漏斗
商机列表
实验中心
周复盘
数据导入
数据来源
指标设置
自动化规则
Workspace和成员
演示数据管理
避免导航过多
可以按照:
今日工作
内容运营
客户开发
业务转化
分析复盘
数据与设置
进行分组
二十三、UI和视觉要求
整体风格:
B2B
专业
清晰
克制
适合教学和长期使用
信息密度合理
视觉层级明确
禁止:
超大数字
卡片占满整屏
大量无意义渐变
过多装饰图标
只有图表没有表格明细
把所有内容塞在总览页
颜色过多
只适合演示、不适合工作
要求:
关键数字大小适中
重要异常和行动比累计数字更醒目
所有图表都有标题、口径和时间范围
图表可以下钻
表格支持筛选和自定义列
筛选栏保持清晰
空状态给出下一步动作
表单有校验
保存有反馈
未保存离开有提醒
手机端可以查看今日任务、更新结果和记录回复
中文界面为默认
英文客户字段、ICP、职位、关键词和话术正常显示
二十四、演示和课程模式
由于产品用于课程和会员,需要支持:
Demo Workspace
明确显示演示标识
一键复制
一键重置
不影响原始模板
示例数据覆盖内容和业务完整流程
学员Workspace
学员只能编辑自己的空间
可以导出数据
可以提交周复盘
可以复制老师提供的指标和规则模板
教学解释
重要指标可以提供简短说明:
这个指标是什么
为什么重要
如何计算
应该如何行动
但不要让教学说明长期占据大量页面空间
可以使用Tooltip、帮助侧栏或学习模式
二十五、必须完成的验收场景
场景一:帖子动态数据
创建帖子
添加发布后1天快照
添加3天快照
添加7天快照
刷新页面
历史快照全部保留
趋势图正确
最新值正确
删除3天快照不影响其他快照
不得覆盖历史数据
场景二:内容产生业务机会
创建帖子
创建目标联系人
记录联系人互动该帖子
记录对方访问主页
记录对方建立连接
记录私信
创建业务机会
归因为Influenced
在帖子详情查看对应商机
在商机详情查看对应帖子
场景三:连接邀请实验
创建邀请备注A
创建邀请备注B
创建不带备注组
分别发送给不同联系人
记录接受与拒绝
记录首条消息
记录回复
分类有效回复
进入业务阶段
查看接受率、有效回复率和商机率
样本不足时必须提示
场景四:漏斗下钻
创建20个联系人
其中15个符合ICP
发送12个邀请
8个接受
7个发送首条消息
4个回复
2个有效回复
1个进入报价
点击每一个漏斗层
查看正确的具体联系人
所有数字与联系人数量一致
场景五:今日行动
创建接受后超过24小时未发消息的联系人
创建回复后未处理的联系人
创建报价后超过3天未跟进的商机
创建今天需要更新帖子数据的帖子
首页显示对应任务
完成任务后从待办中消失
相关实体状态正确更新
场景六:截图录入
上传帖子统计截图
AI提取数据
标记低置信度字段
人工修改
选择对应帖子
确认保存
生成新快照
保存原截图来源
场景七:全局筛选
创建两个账号
创建两个产品线
创建两个ICP
创建不同成员数据
切换筛选
看板、图表、列表和漏斗同步变化
清除筛选恢复完整数据
不得出现旧数据残留
二十六、测试要求
每个里程碑必须运行:
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
学员复制
重置演示数据
导出
全流程测试
响应式检查
部署
二十八、绝对禁止事项
禁止:
把看板做成静态数据大屏
使用特别大的数字占据页面
帖子数据只能录入一次
新数据覆盖旧帖子数据
数据来源无法修改
漏斗数字无法点击
漏斗各层来自互不相关的总数
只能记录发送动作,不能记录结果
只能记录回复,不能区分有效回复
只比较接受率,不比较业务结果
不保存模板版本
修改模板后历史消息一起变化
AI在样本不足时下确定结论
把相关性说成因果关系
把所有商机强制归因给帖子
虚构LinkedIn API
开发自动批量加好友或群发功能
使用假实时数据
创建无功能按钮
只做图表,没有明细
只做内容运营,不做业务推进
只做业务数据,不记录内容影响
只为了课程演示,不考虑真实连续使用
把Demo数据与真实数据混合
修改一个筛选条件但部分模块不更新
二十九、每个里程碑的汇报格式
已完成
关键文件
数据库变化
指标和公式变化
浏览器验证
自动化测试
尚未完成
已知问题
下一步
所有未完成内容必须明确说明
不得使用“基本完成”掩盖未实现功能
现在开始
第一步只完成:
审计当前项目
运行当前系统
逐页测试当前功能
创建
PRODUCT_SPEC.md创建
DATA_MODEL.md创建
METRIC_DICTIONARY.md创建
FUNNEL_DEFINITIONS.md创建
ATTRIBUTION_MODEL.md创建
AGENTS.md创建
PLAN.md创建
TEST_PLAN.md输出当前版本与本需求的完整差距分析
输出分阶段实施计划
在完成产品、数据和指标设计以前,不要开始大规模重写页面
十四、效果出来以后,应该怎么修改
很多人用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生成一堆看起来正确的文案
而是从客户是谁、客户为什么购买、网站应该如何承接搜索、内容如何建立信任、页面如何推动询盘开始
一步一步,把网站也做成另一套真正能够推动业务的系统

