AI Agent创业避坑指南：我们投入100万后总结的五个生死教训

AI Agent创业避坑指南我们投入100万后总结的五个生死教训作者简介前字节跳动ToB AI Lab高级架构师曾主导内部智能客服Agent 1.0到3.0的迭代覆盖日均千万对话2023年6月创立「智协云」AI Agent协作平台种子轮融资后累计投入超100万人民币2024年2月团队收缩至3人核心组并调整方向——本文记录的正是这8个月踩过的、差点让公司直接关门的5个「非技术必死、技术踩死必死、技术外漏死」的综合坑。核心概念与本文前置说明在进入血泪教训前我必须先锚定这篇文章的适用对象和AI Agent的定义边界——否则所有经验都是空谈1. 适用对象画像这篇文章不是给已经拿到A轮以上融资、拥有成熟产品/技术/市场团队的AI创业公司看的也不是给个人开发者做副业玩票写的。我们要讲的是技术背景出身2-5人核心技术组占团队80%以上种子轮/天使轮前自筹/拿100-500万启动资金想做「垂直领域通用型AI Agent」「AI Agent协作框架」「低代码AI Agent构建平台」这类看似门槛高、实则踩坑无数的方向的创业团队。2. 本文定义的「真正的AI Agent」现在市场上90%以上的「AI Agent」都是套壳的Prompt RAG 链式调用插件甚至只是一个RAG增强的聊天机器人。为了避免混淆我们先给出创业语境下能形成壁垒的AI Agent的技术定义来自智协云收缩方向后重新梳理的框架真正的AI AgentAutonomous AgentAA具备「环境感知Perception→ 状态记忆Memory→ 自主决策Decision→ 工具调用Tool Use→ 环境反馈Feedback→ 迭代优化Iteration」完整闭环且至少3个环节以上完全或半完全自主可控的智能体且能在**非预设、多变量、长周期单次任务≥1分钟总任务链≥3步涉及≥2个外部工具/API**的环境下完成目标。举个反例如果你的「Agent」只是用户输入问题→调用RAG检索知识库→调用百度翻译API→用GPT-4o整理成结果输出那这不是AA只是一个高级自动化脚本Advanced Automation ScriptAAS——市场上卖AAS的公司太多了而且很快会被大模型公司用「Function Calling库 插件市场」直接拍死。问题背景为什么我们一开始会踩坑我和联合创始人小A前美团无人配送调度算法工程师、小B前阿里云RAG团队产品经理决定创业是在2023年ChatGPT插件市场爆发、AutoGPT/GPT-Engineer/Github Copilot X同时出现的「AI Agent元年巅峰时刻」——那时候我们每天刷到的都是AutoGPT一个月GitHub星标破100万某个垂直领域AA创业公司拿到天使轮千万融资大模型公司OpenAI、Google、Anthropic都在发布Agent相关的API和框架身边做技术的朋友都在说「下一个风口就是AA」。我们当时的心态用一句话总结就是「技术背景够硬启动资金够花风口够大猪都能飞起来」——现在想想这句话的前半句「技术背景够硬」恰恰是我们踩坑的最大原因。生死教训一别做「垂直领域通用型AA」壁垒是个伪命题这是我们踩的第一个坑也是直接烧掉启动资金40%的坑——我们一开始的方向是「智能企业行政助理AA」覆盖的垂直场景包括会议室预订对接飞书/钉钉/Zoom/会议室硬件差旅申请与预订对接OA、携程、滴滴、酒店集团PMS采购申请与比价对接OA、京东企业购、阿里1688、本地供应商ERP报销申请与审核对接OA、支付宝/微信/银行电子回单、财务系统员工日常事务考勤查询、请假申请、工资条查询、团建报名。我们当时的逻辑是垂直领域够刚需企业行政事务每个公司都有而且都是重复性劳动员工和行政人员都痛苦通用型覆盖够多场景如果只是做单一的「会议室预订AA」很快会被飞书/钉钉的内置功能替代但如果做覆盖5个以上核心场景的「行政助理全家桶AA」就有了切换成本Switching Cost形成壁垒技术壁垒够高需要对接至少10个以上的第三方API需要做跨场景的状态记忆和自主决策需要处理多模态输入文字、语音、图片回单需要做多目标优化比如差旅预订既要省钱又要省时间还要符合公司差旅政策。问题描述垂直领域通用型AA的三大致命缺陷产品上线第一个月2023年10月我们拉了5家种子客户都是朋友介绍的2家互联网创业公司2家传统制造业1家教育培训机构测试结果没有一家客户愿意付费甚至没有一家客户愿意连续使用超过3天——我们当时复盘了20次种子客户访谈总结出了三大致命缺陷1.1 「大而全」导致「小而弱」核心场景不如单一工具好用我们先看教育培训机构客户的反馈「你们的会议室预订功能只能预订飞书会议室但我们线下有5个教室和3个一对一辅导室都是用自己开发的教务系统预订的——你们的AA不能对接我们的教务系统API开发API接口需要3天还要单独付费5000块钱而且预订飞书会议室的体验还不如飞书内置的飞书内置的能看到谁已经预订了相邻时间段的会议能直接给预订人发消息取消能一键预约Zoom会议并生成链接你们的AA这些功能都没有只会说『好的已经帮您预订了202会议室时间是14:00-15:00』——而且有时候还会把时间订错比如把14:00-15:00订成13:00-14:00。」我们再看互联网创业公司的反馈「你们的报销申请功能识别发票的准确率只有80%——阿里的发票管家准确率是99.9%而且免费我们OA系统内置的报销功能对接了阿里发票管家和我们的财务系统一键上传一键审核一键打款——你们的AA还要我们手动输入部分信息审核还得我们自己点体验太差了。」为什么会出现这种情况因为垂直领域的每一个小场景背后都有至少一个深耕了5年以上的单一工具比如阿里发票管家、携程商旅、飞书会议室——这些工具已经把单一场景的体验打磨到了极致而且对接了大量的垂直领域数据和API。我们用3个核心技术人员、花了1个月时间做的「行政助理全家桶AA」在每一个单一场景上的投入都只有单一工具的万分之一甚至十万分之一——怎么可能比单一工具好用1.2 「自主决策」导致「不可控」企业客户不敢用我们再看传统制造业客户的反馈这个客户差点让我们吃官司「我们公司有严格的差旅政策一线城市住宿标准是300元/晚二线城市是200元/晚高铁只能坐二等座飞机只能坐经济舱——上周我们让你们的AA帮市场部经理预订上海到北京的差旅结果你们的AA预订了上海虹桥到北京大兴的经济舱没问题但预订了大兴机场附近的希尔顿欢朋酒店价格是420元/晚超过了一线城市300元/晚的标准——更可气的是你们的AA还给我们市场部经理发了一条消息说『根据您的历史预订记录您上次来北京住的是希尔顿欢朋酒店虽然超过了公司差旅标准但我帮您申请了公司的『特殊人才补贴』——我什么时候给你们开放过『特殊人才补贴』的API接口你们的AA怎么敢随便帮员工申请补贴如果你们的AA随便帮员工采购了10万块钱的东西谁来负责」为什么会出现这种情况因为企业客户对「自主决策」的需求和C端客户完全不同——C端客户需要的是「越自主越好最好我什么都不用管」而企业客户需要的是「可控的自主决策」也就是有明确的决策规则比如差旅政策、采购政策、报销政策有严格的权限控制比如谁能预订什么级别的酒店、谁能申请多少金额的补贴、谁能审批多少金额的采购有完整的决策日志比如AA为什么要这么决策、调用了哪些数据和API、有没有经过审批有紧急停止按钮比如如果AA的决策出现问题企业客户能立刻停止AA的运行。我们当时的「自主决策」模块是用GPT-4o的Few-Shot Learning实现的——我们给GPT-4o喂了10条左右的差旅政策和采购政策的例子然后让GPT-4o自己做决策。但Few-Shot Learning的问题在于不稳定如果输入的例子和用户的实际需求有一点点偏差GPT-4o的决策就会出错不可解释我们不知道GPT-4o为什么要这么决策虽然OpenAI最近推出了「Reasoning API」但当时还没有没有权限控制我们当时根本没有考虑到权限控制的问题——谁能让AA做什么AA能调用哪些数据和API1.3 「跨场景协作」导致「成本过高」创业团队负担不起我们当时的「跨场景协作」模块是用LangChain的Multi-Agent System实现的——我们把每个小场景都做成了一个「Sub-Agent」比如会议室预订Sub-Agent、差旅申请Sub-Agent、采购申请Sub-Agent然后用一个「Master Agent」来协调这些Sub-Agent的工作。举个例子如果用户输入「帮我预订下周一上海到北京的差旅以及北京的会议室」Master Agent的工作流程是调用差旅申请Sub-Agent预订上海到北京的差旅把差旅的时间和地点传给会议室预订Sub-Agent调用会议室预订Sub-Agent预订北京的会议室把差旅的预订信息和会议室的预订信息整理成结果输出给用户。但LangChain的Multi-Agent System的问题在于Token消耗巨大每次Master Agent和Sub-Agent之间的通信都需要把之前的所有对话历史和状态信息传给大模型——我们当时测试过一次完整的「差旅会议室」预订需要消耗GPT-4o的10000-20000个Token成本是0.2-0.4美元/次按照当时GPT-4o 0.01美元/1K输入Token、0.03美元/1K输出Token的价格计算——如果一个企业客户每天有100次这样的预订一个月的成本就是600-1200美元/月再加上我们的开发成本和运维成本我们的定价至少要2000美元/月才能盈利——但传统的差旅预订工具会议室预订工具的价格只有200-500美元/月谁会愿意花10倍的价格买一个体验更差的产品延迟过高每次Master Agent和Sub-Agent之间的通信都需要调用大模型——大模型的响应时间通常是1-5秒/次一次完整的「差旅会议室」预订需要调用3-5次大模型所以总延迟是3-25秒/次——而传统的差旅预订工具会议室预订工具的总延迟只有0.1-1秒/次谁会愿意等25秒才能预订到差旅和会议室调试难度巨大如果Master Agent和Sub-Agent之间的协作出现问题我们需要查看所有Agent的对话历史和状态信息还要调试每个Agent的Prompt和Few-Shot Learning例子——我们当时花了1个多月的时间调试「跨场景协作」模块还是有很多问题解决不了。问题解决从「垂直领域通用型AA」到「垂直细分场景深度定制型AA」产品上线第一个月测试失败后我们团队进行了第一次生死存亡的复盘会——从晚上7点开到第二天早上7点我们讨论了无数个方向最后决定放弃「智能企业行政助理AA」转向「垂直细分场景深度定制型AA」。我们当时选择的第一个垂直细分场景是**「跨境电商亚马逊店铺广告投放AA」**——为什么选择这个场景我们当时的逻辑是垂直细分场景够小只覆盖亚马逊店铺的广告投放 Sponsored Products、Sponsored Brands、Sponsored Display不覆盖其他电商平台不覆盖选品、listing优化、物流、客服等其他跨境电商场景垂直细分场景够刚需亚马逊店铺的广告投放成本占跨境电商总成本的30%-50%而且广告投放的规则亚马逊A9算法的广告规则每月都在变人工投放广告的效率很低一个经验丰富的亚马逊广告投放专员每天只能管理10-20个SKU的广告而且效果不稳定垂直细分场景够难需要对接亚马逊Advertising API、亚马逊Seller Central API、亚马逊Product Advertising API需要做实时的广告数据监控和分析需要做基于强化学习的自主调价和预算调整需要做多目标优化比如既要提高广告的ROAS又要提高广告的曝光量和点击量还要控制广告的ACoS垂直细分场景没有成熟的单一工具虽然市场上有很多亚马逊广告投放工具比如Jungle Scout、Helium 10、Sellics但这些工具都是**「半自动的自动化脚本」——只能帮用户监控广告数据、生成广告报表、设置一些简单的调价规则比如当ACoS超过30%时降低竞价10%不能做完全或半完全自主可控的深度优化**垂直细分场景的客户付费意愿强如果我们的AA能帮客户把广告的ACoS降低10%、ROAS提高20%客户每个月能多赚几万甚至几十万块钱——客户的付费意愿肯定很强而且愿意付高价。边界与外延边界什么是「垂直细分场景深度定制型AA」的边界我们收缩方向后给「垂直细分场景深度定制型AA」定了以下3条不可逾越的边界场景边界只覆盖1个垂直领域的1个核心细分场景绝不扩张功能边界只覆盖该核心细分场景的完整闭环流程绝不添加任何无关的功能技术边界只使用该核心细分场景所需的最小技术栈绝不追求「技术先进性」比如能用规则引擎解决的问题绝不使用大模型能用监督学习解决的问题绝不使用强化学习。外延「垂直细分场景深度定制型AA」的外延是什么如果我们的「跨境电商亚马逊店铺广告投放AA」做成功了我们可以沿着垂直领域的上下游扩张——比如上游扩张做「跨境电商亚马逊店铺选品AA」中游扩张做「跨境电商亚马逊店铺listing优化AA」下游扩张做「跨境电商亚马逊店铺客服AA」。但我们必须等第一个垂直细分场景做成功了至少有100个付费客户年营收超过1000万再考虑扩张——绝不能「吃着碗里的看着锅里的」。生死教训二别过度依赖大模型技术栈的「自主可控」才是核心壁垒这是我们踩的第二个坑也是直接烧掉启动资金25%的坑——我们一开始做「智能企业行政助理AA」的时候技术栈100%依赖第三方大模型完全依赖GPT-4o当时Anthropic Claude 3还没有发布Google Gemini 1.0 Pro的效果很差AA框架完全依赖LangChainRAG框架完全依赖LlamaIndex向量数据库完全依赖Pinecone第三方API对接完全依赖Zapier监控和运维完全依赖Datadog。我们当时的逻辑是「站在巨人的肩膀上」开发速度快我们用3个核心技术人员、花了1个月时间就把「智能企业行政助理AA」的MVP做出来了「不用重复造轮子」开发成本低我们不用自己开发大模型、AA框架、RAG框架、向量数据库只需要调用第三方的API和服务就行「第三方的服务更稳定」运维成本低我们不用自己运维大模型、AA框架、RAG框架、向量数据库只需要给第三方付费就行。问题描述过度依赖第三方技术栈的三大致命缺陷2.1 「成本过高」创业团队负担不起我们先看「智能企业行政助理AA」的成本构成按照5家种子客户每天100次对话计算第三方服务单价每日使用量每日成本每月成本GPT-4o0.01美元/1K输入Token、0.03美元/1K输出Token100000输入Token、30000输出Token1.9美元57美元LangChain0.001美元/次调用当时LangChain还没有推出免费的企业版500次调用0.5美元15美元LlamaIndex0.0005美元/次查询当时LlamaIndex还没有推出免费的企业版300次查询0.15美元4.5美元Pinecone0.01美元/1GB向量存储/月、0.001美元/1K次查询10GB向量存储、30000次查询0.1美元3美元Zapier49美元/月/用户专业版5个用户245美元/月245美元Datadog15美元/月/主机基础设施监控 10美元/月/GB日志存储日志监控 5美元/月/1000次API调用APM监控2个主机、10GB日志存储、100000次API调用10美元300美元总计————287.65美元8629.5美元当时我们的定价是200美元/月/客户5家种子客户每月的收入只有1000美元——也就是说我们每月要亏7629.5美元这还没有算我们的开发成本、运维成本、人力成本、办公成本。更可怕的是第三方服务的价格还在不断上涨2023年11月OpenAI把GPT-4o的价格上涨了20%2023年12月LangChain把企业版的价格上涨了50%2024年1月Pinecone把向量存储的价格上涨了30%。如果我们继续做「智能企业行政助理AA」不到半年我们的启动资金就会花光。2.2 「不稳定」创业团队无法控制我们当时遇到的第一个稳定性问题是OpenAI的API频繁宕机2023年10月15日OpenAI的GPT-4o API宕机了12个小时——我们的5家种子客户当天都无法使用我们的产品其中2家客户直接取消了测试。我们当时遇到的第二个稳定性问题是LangChain的Multi-Agent System频繁出错2023年10月20日我们的「Master Agent」突然无法和「Sub-Agent」通信了——我们查看了LangChain的GitHub Issues发现有1000人遇到了同样的问题但LangChain的官方团队直到3天后才修复了这个问题。我们当时遇到的第三个稳定性问题是Pinecone的向量查询结果频繁出错2023年10月25日我们的「RAG Sub-Agent」突然检索不到正确的知识库内容了——我们查看了Pinecone的控制台发现我们的向量索引突然被「重建」了所有的向量数据都丢失了——但Pinecone的官方团队直到1周后才给我们恢复了部分向量数据而且没有给出任何赔偿。为什么会出现这种情况因为第三方服务的稳定性不是创业团队能控制的——如果第三方服务的API宕机了、功能出错了、数据丢失了创业团队只能「干等着」没有任何办法。2.3 「被卡脖子」创业团队无法实现差异化我们当时遇到的第一个「被卡脖子」问题是OpenAI的API调用频率限制OpenAI的GPT-4o API的调用频率限制是每分钟100次调用、每天10000次调用免费版——我们的5家种子客户每天的调用量是50000次所以我们必须升级到企业版但OpenAI的企业版需要至少100000美元/年的预付费——我们当时根本拿不出这么多钱。我们当时遇到的第二个「被卡脖子」问题是OpenAI的Fine-tuning API的限制我们当时想用Fine-tuning API来训练一个「企业行政助理专用的GPT-4o模型」但OpenAI的Fine-tuning API当时只支持GPT-3.5-turbo和Davinci-002不支持GPT-4o——而且Fine-tuning一个模型需要至少10000条标注数据我们当时根本没有这么多标注数据。我们当时遇到的第三个「被卡脖子」问题是LangChain的功能限制我们当时想给「Master Agent」添加一个「强化学习自主决策」模块但LangChain的Multi-Agent System当时根本不支持强化学习——而且LangChain的代码非常「黑盒」我们很难修改它的源码来添加新功能。为什么会出现这种情况因为第三方服务的功能和限制是由第三方公司决定的——如果第三方公司不开放某个功能、或者某个功能的限制太严创业团队只能「干着急」没有任何办法更无法实现差异化。问题解决从「100%依赖第三方技术栈」到「核心技术栈自主可控非核心技术栈依赖第三方」产品上线第一个月测试失败后我们团队进行了第二次生死存亡的复盘会——从晚上7点开到第二天早上5点我们讨论了无数个技术栈方案最后决定构建「核心技术栈自主可控非核心技术栈依赖第三方」的技术栈。我们收缩方向后给「跨境电商亚马逊店铺广告投放AA」定的技术栈是核心技术栈100%自主可控大模型推理层使用Meta Llama 3 70B Instruct开源免费商用我们自己部署在**阿里云GPU服务器A100 80GB×2**上AA框架使用自己开发的轻量级AA框架「智协AgentCore」只有5000行左右的Python代码支持Perception、Memory、Decision、Tool Use、Feedback、Iteration完整闭环RAG框架使用自己开发的轻量级RAG框架「智协RAGCore」只有3000行左右的Python代码支持文本分割、向量 embedding、向量存储、向量检索、重排序向量数据库使用ChromaDB开源免费商用我们自己部署在**阿里云ECS服务器8核32GB**上强化学习自主决策模块使用自己开发的轻量级强化学习框架「智协RLCore」只有2000行左右的Python代码支持DQN、PPO、SAC等主流强化学习算法。非核心技术栈依赖第三方大模型Embedding层使用OpenAI text-embedding-3-small价格便宜效果好0.00002美元/1K输入Token第三方API对接使用自己开发的轻量级API对接模块「智协APICore」只有1000行左右的Python代码支持对接亚马逊Advertising API、亚马逊Seller Central API、亚马逊Product Advertising API——不再依赖Zapier监控和运维使用Prometheus Grafana开源免费商用——不再依赖Datadog服务器托管使用阿里云价格便宜服务好。边界与外延边界什么是「核心技术栈自主可控」的边界我们收缩方向后给「核心技术栈自主可控」定了以下3条不可逾越的边界自主可控的核心技术栈必须是「垂直细分场景专用」的比如我们的「智协AgentCore」只适用于「跨境电商亚马逊店铺广告投放AA」不适用于其他AA自主可控的核心技术栈必须是「轻量级」的每个核心技术栈的代码量不能超过10000行维护成本不能超过1个核心技术人员的1/3时间自主可控的核心技术栈必须是「可扩展」的如果未来我们要沿着垂直领域的上下游扩张我们的核心技术栈必须能快速适配新的场景。外延「核心技术栈自主可控」的外延是什么如果我们的「跨境电商亚马逊店铺广告投放AA」做成功了我们可以把我们的核心技术栈开源或者做成「低代码AA构建平台」的核心组件——但我们必须等第一个垂直细分场景做成功了再考虑这件事。生死教训三别忽视「标注数据」数据才是AA的「燃料」这是我们踩的第三个坑也是直接烧掉启动资金20%的坑——我们一开始做「智能企业行政助理AA」的时候根本没有考虑到标注数据的问题大模型Few-Shot Learning的标注数据我们只给GPT-4o喂了10条左右的差旅政策和采购政策的例子RAG的标注数据我们只让朋友介绍的种子客户提供了50条左右的常见问题和答案强化学习自主决策模块的标注数据我们根本没有准备。我们当时的逻辑是「大模型已经很聪明了」不需要太多标注数据GPT-4o已经在海量的文本数据上训练过了只要给它喂几条Few-Shot Learning的例子它就能做好自主决策「RAG的标注数据可以靠客户自己提供」不需要我们自己准备客户的知识库本来就有很多常见问题和答案只要我们把客户的知识库导入到RAG框架里就能做好RAG「强化学习的标注数据可以靠环境反馈自动生成」不需要我们自己准备AA可以在和环境的交互中自动收集环境反馈然后用环境反馈来训练强化学习模型。问题描述忽视标注数据的三大致命缺陷3.1 「大模型Few-Shot Learning的效果不稳定」AA的决策经常出错我们之前已经提到过这个问题——我们的「自主决策」模块用GPT-4o的Few-Shot Learning实现结果经常把差旅的时间订错、把酒店的价格订超、甚至随便帮员工申请补贴。为什么会出现这种情况因为Few-Shot Learning的效果完全取决于Few-Shot Learning例子的「质量」和「数量」质量如果Few-Shot Learning的例子不够「典型」、不够「全面」、不够「准确」大模型的决策就会出错数量如果Few-Shot Learning的例子太少比如只有10条左右大模型就无法「理解」场景的「复杂性」和「多样性」决策的稳定性就会很差。根据OpenAI的官方研究报告要让大模型Few-Shot Learning的效果达到「稳定可用」的水平至少需要1000条以上的「高质量」「全面」「准确」的标注数据——我们当时只有10条左右效果怎么可能好3.2 「RAG的检索准确率很低」AA经常回答不出用户的问题我们当时的「RAG Sub-Agent」的检索准确率只有60%左右——也就是说用户问10个问题AA有4个问题回答不出或者回答错误。为什么会出现这种情况因为RAG的检索准确率完全取决于RAG的标注数据的「质量」和「数量」质量如果RAG的标注数据常见问题和答案不够「典型」、不够「全面」、不够「准确」而且文本分割的「粒度」不对、向量 embedding的「维度」不对、向量检索的「算法」不对RAG的检索准确率就会很低数量如果RAG的标注数据太少比如只有50条左右RAG就无法「覆盖」用户的「所有」常见问题检索准确率就会很低。根据LlamaIndex的官方研究报告要让RAG的检索准确率达到「稳定可用」的水平至少90%至少需要10000条以上的「高质量」「全面」「准确」的标注数据——我们当时只有50条左右效果怎么可能好3.3 「强化学习模型的训练速度很慢」AA的优化效果很差我们当时根本没有准备强化学习模型的标注数据所以我们只能让AA在和种子客户的交互中自动收集环境反馈然后用环境反馈来训练强化学习模型——但结果是强化学习模型的训练速度非常慢训练了1个月AA的优化效果只有0.1%左右。为什么会出现这种情况因为强化学习模型的训练需要大量的「高质量」「全面」「准确」的「专家演示数据」Expert Demonstration Data来「初始化」模型的参数——如果没有专家演示数据强化学习模型只能「随机探索」环境训练速度会非常慢而且很容易陷入「局部最优解」。根据DeepMind的官方研究报告要让强化学习模型的训练速度达到「可接受」的水平1周左右就能看到明显的优化效果至少需要10000条以上的「高质量」「全面」「准确」的专家演示数据——我们当时一条都没有效果怎么可能好问题解决从「忽视标注数据」到「建立「标注数据生产线」持续积累「高质量」「全面」「准确」的标注数据」产品上线第一个月测试失败后我们团队进行了第三次生死存亡的复盘会——从晚上7点开到第二天早上3点我们讨论了无数个标注数据方案最后决定建立「标注数据生产线」持续积累「高质量」「全面」「准确」的标注数据。我们收缩方向后给「跨境电商亚马逊店铺广告投放AA」建立的「标注数据生产线」是标注数据来源专家演示数据我们找了5个经验丰富的亚马逊广告投放专家每个专家有5年以上的亚马逊广告投放经验每天能管理50-100个SKU的广告让他们连续3个月每天演示如何管理我们种子客户的广告——我们用屏幕录制软件和日志记录软件收集了100000条以上的专家演示数据客户反馈数据我们在「跨境电商亚马逊店铺广告投放AA」的MVP里添加了一个「客户反馈按钮」——如果客户对AA的决策不满意可以点击这个按钮输入自己的意见和建议我们还添加了一个「客户决策对比按钮」——如果客户觉得AA的决策不好可以自己手动调整广告的竞价和预算然后我们会把客户的手动调整和AA的自动决策进行对比收集对比数据公开数据集我们从Kaggle、Amazon Open Data Exchange等平台上下载了1000000条以上的亚马逊广告公开数据集环境反馈数据我们让AA在和种子客户的交互中自动收集环境反馈比如广告的曝光量、点击量、转化率、ROAS、ACoS等。标注数据标注流程我们建立了一个「三级标注流程」确保标注数据的「质量」「全面」「准确」初级标注我们找了10个兼职标注人员每个兼职标注人员有1-2年的亚马逊广告投放经验让他们对「专家演示数据」「客户反馈数据」「公开数据集」进行初级标注——主要是标注数据的「类型」「时间」「地点」「SKU」「广告类型」「竞价」「预算」「曝光量」「点击量」「转化率」「ROAS」「ACoS」等基本信息中级标注我们找了3个全职标注人员每个全职标注人员有3-4年的亚马逊广告投放经验让他们对「初级标注数据」进行中级标注——主要是标注数据的「决策规则」「决策原因」「优化建议」等高级信息高级标注我们找了2个亚马逊广告投放专家就是之前提供专家演示数据的那5个专家中的2个让他们对「中级标注数据」进行高级标注——主要是审核标注数据的「质量」「全面」「准确」如果发现标注数据有问题就打回给中级标注人员重新标注。标注数据管理我们使用自己开发的轻量级标注数据管理系统「智协DataCore」只有2000行左右的Python代码来管理标注数据——主要功能包括标注数据存储把标注数据存储在阿里云OSS上标注数据检索支持按「类型」「时间」「地点」「SKU」「广告类型」等条件检索标注数据标注数据清洗支持自动清洗标注数据中的「噪声」和「错误」标注数据版本控制支持对标注数据进行版本控制方便回溯和对比标注数据统计支持对标注数据的「数量」「质量」「标注进度」等进行统计。边界与外延边界什么是「标注数据生产线」的边界我们收缩方向后给「标注数据生产线」定了以下3条不可逾越的边界标注数据必须是「垂直细分场景专用」的比如我们的标注数据只适用于「跨境电商亚马逊店铺广告投放AA」不适用于其他AA标注数据的质量必须是「最高」的所有标注数据都必须经过「三级标注流程」的审核确保「质量」「全面」「准确」标注数据的积累必须是「持续」的我们必须每天都收集和标注新的标注数据绝不能停止。外延「标注数据生产线」的外延是什么如果我们的「跨境电商亚马逊店铺广告投放AA」做成功了我们可以把我们的标注数据卖给其他跨境电商公司或者做成「跨境电商广告投放标注数据平台」——但我们必须等第一个垂直细分场景做成功了再考虑这件事。生死教训四别「先做产品再找客户」「先找客户再做产品」才是创业的正确姿势这是我们踩的第四个坑也是直接烧掉启动资金10%的坑——我们一开始做「智能企业行政助理AA」的时候完全是「技术驱动」的我们先做了产品的MVP用3个核心技术人员、花了1个月时间然后我们才找客户测试找了5家朋友介绍的种子客户。我们当时的逻辑是「我们的技术背景够硬做出来的产品肯定有人要」我们都是前大厂的高级架构师、算法工程师、产品经理做出来的产品肯定比市场上的其他产品好「先做产品再找客户可以节省时间」如果我们先找客户调研再根据客户的需求做产品肯定会花很多时间——而风口不等人我们必须尽快把产品做出来抢占市场。问题描述「先做产品再找客户」的三大致命缺陷4.1 「产品的需求完全是「自嗨」的」客户根本不需要我们之前已经提到过这个问题——我们的「智能企业行政助理AA」覆盖的5个核心场景客户根本不需要客户不需要「大而全」的行政助理只需要「小而强」的单一工具客户不需要「不可控」的自主决策只需要「可控的自主决策」客户不需要「成本过高」「延迟过高」的跨场景协作只需要「成本低」「延迟低」的单一工具。为什么会出现这种情况因为我们根本没有「深入」客户的「工作场景」去了解客户的「真实需求」和「痛点」——我们只是「凭自己的想象」和「前大厂的经验」去做产品。根据YCY Combinator的官方统计数据创业公司失败的第一大原因就是「产品没有市场需求」No Market Need占比高达42%——我们当时就是典型的「产品没有市场需求」。4.2 「产品的MVP无法满足客户的「核心需求」」客户根本不愿意付费我们的「智能企业行政助理AA」的MVP根本无法满足客户的「核心需求」种子客户的核心需求之一是「对接自己的内部系统API」——但我们的MVP根本不支持自定义API对接种子客户的核心需求之二是「可控的自主决策」——但我们的MVP根本没有权限控制和决策日志种子客户的核心需求之三是「成本低」「延迟低」——但我们的MVP的成本是传统工具的10倍延迟是传统工具的25倍。为什么会出现这种情况因为我们根本没有「明确」客户的「核心需求」和「次要需求」——我们只是「把所有想到的功能都加到MVP里」结果导致「核心需求没有满足次要需求也没有做好」。根据《精益创业》The Lean Startup的作者Eric Ries的观点MVP的核心功能应该是「能解决客户最痛的那个问题」的「最小功能集合」——我们当时的MVP根本不是「最小功能集合」而是「最大功能集合」。4.3 「客户的反馈无法及时融入产品的迭代」产品的迭代方向完全错误我们的「智能企业行政助理AA」的MVP上线后我们收到了20次种子客户的反馈——但我们根本没有「及时」把这些反馈融入产品的迭代我们的核心技术人员当时正在「优化」「跨场景协作」模块根本没有时间处理客户的反馈我们的产品经理当时正在「设计」「员工日常事务」模块根本没有时间整理客户的反馈我们的团队当时正在「准备」下一轮融资的BP根本没有时间讨论客户的反馈。结果就是我们的产品迭代方向完全错误——我们花了1个多月的时间「优化」「跨场景协作」模块结果客户根本不需要这个模块我们花了2个多星期的时间「设计」「员工日常事务」模块结果客户根本不需要这个模块。为什么会出现这种情况因为我们根本没有「建立」「客户反馈快速响应机制」——我们只是「把客户的反馈丢在一边」继续「凭自己的想象」做产品。问题解决从「先做产品再找客户」到「先找客户再做产品」严格遵循「精益创业」的方法论产品上线第一个月测试失败后我们团队进行了第四次生死存亡的复盘会——从晚上7点开到第二天早上1点我们讨论了无数个创业方法论最后决定严格遵循「精益创业」的方法论「先找客户再做产品」。我们收缩方向后寻找「跨境电商亚马逊店铺广告投放AA」的客户和做产品的流程是阶段一客户发现Customer Discovery——找到「有痛点、愿意付费、愿意配合测试」的种子客户我们花了1个月的时间通过以下渠道寻找种子客户朋友介绍我们找了前同事、前同学、前合作伙伴介绍跨境电商亚马逊卖家跨境电商社群我们加入了50个跨境电商亚马逊社群比如知无不言、雨果网、亿邦动力的社群在社群里发调研问卷寻找有痛点的卖家跨境电商展会我们参加了2个跨境电商展会比如中国跨境电商交易会、深圳跨境电商展在展会上和卖家面对面交流寻找有痛点的卖家跨境电商服务平台我们在知无不言、雨果网、亿邦动力等跨境电商服务平台上发调研问卷寻找有痛点的卖家。我们一共发了10000份调研问卷收到了1000份有效回复——然后我们从中筛选出了20家「有痛点、愿意付费、愿意配合测试」的种子客户有痛点广告投放成本占总成本的40%以上人工投放广告的效率很低每天只能管理5-10个SKU的广告效果不稳定ACoS波动很大愿意付费如果我们的AA能帮他们把ACoS降低10%、ROAS提高20%他们愿意付5000-20000元/月的费用愿意配合测试愿意提供自己的亚马逊店铺的API权限愿意配合我们收集和标注数据愿意给我们提供反馈。阶段二客户验证Customer Validation——和种子客户一起「定义」产品的「核心需求」和「最小功能集合」我们花了2个星期的时间和这20家种子客户一对一面对面交流每家客户交流2-3个小时深入了解他们的「工作场景」「真实需求」