企业官网建设流程全解析

30 天、600 个用户，放在任何一个成熟产品面前都不算亮眼的数字。但如果你是从零开始、一个人开发、白天还要上班，晚上一边调 Agent 一边回用户消息，那这个数字意味着你至少在 30 天里跨过了三座山：把脑子里一个模糊的想法做成能跑的东西，把这个东西推到真实用户面前，以及在前两周不断被用户吐槽“你这是个玩具”之后，依然愿意每天打开后台看数据。我做的小龙虾 AI OpenClaw，就是在这样的状态下，用 Cosmius AI 把全流程跑通的。这篇文章只说大实话，不吹方案也不卖焦虑，重点是怎么在一缺资源、二缺时间的情况下，把一个轻量级 AI 应用从立项做到有 600 个人点开它，以及这 30 天里我踩过的那些坑，哪些必须提前避开。

1. 立项：为什么偏偏选小龙虾 AI 这个方向

1.1 从痛点倒推产品，而不是先造一个通用助手

这个项目最开始其实不叫 OpenClaw，我最初的思路是想做一个“美食生活全能助手”，结果你猜怎么着？它在第一周就死掉了。因为“全能”意味着用户不知道拿它干什么，我也不可能在一个月内覆盖所有场景。后来让我真正下决心做小龙虾，是因为某个晚上我在群里看几个朋友聊天，有人问“这个季节小龙虾和虾球哪个更值得吃”，另一个人直接丢过来一张价格对比截图，说“别选球，壳多肉少，算下来血亏”。那一刻我意识到两件事：第一，用户要的答案非常具体、非常急；第二，真正有用的是“生活经验 + 当下信息”的组合，不是泛泛的菜谱百科。

所以我把方向收敛成“小龙虾 AI”，专注三件事：时令口味怎么选、门店值不值得去、以及那些吃虾时突然冒出来的奇奇怪怪的问题，比如“刚剥完虾手指很腥怎么办”“虾头能吃吗”“麻辣和蒜蓉哪个适合带小孩”。这些问题不复杂，但通用助手大概率答得又宽又虚。与其做一百个领域的 60 分，不如做一个小领域的 85 分。

这里有个经验可以分享：选择垂直方向时，一定要看“用户提问是否高频且答案是否可标准化”。小龙虾这个品类有很强的季节性，夏天是绝对高峰，问题集中、场景明确、目标用户画像清晰，非常适合跑 MVP。而且餐饮类信息天然需要“实时性”和“本地性”，这正是 Agent 比静态网页有价值的地方。

1.2 为什么用 Cosmius AI，而不是自己撸一套

我见过不少人，一提到做 Agent 应用就想着自己调大模型、自己写链路编排、自己搭向量库、自己管会话状态。我承认，如果目标是学习底层技术，那自己搭一套完全没问题。但我的目标是“30 天获 600 用户”，是验证需求、跑通流程、收集真实反馈，那时间成本就是最贵的成本。

我选择 Cosmius AI 的理由其实很朴素：它把我最花时间的三件事全包了。一是可视化 Agent 编排，不用从零写状态机；二是内置知识库管理和召回策略，省掉了自己部署向量数据库的麻烦；三是渠道接入方便，我可以把同一个 Agent 快速部署到即时通讯群聊、内容社区私信等多个入口。类比一下，这就像自己盖房子和买一套预制房再装修的区别。预制房虽然有些地方不完全合我心意，但地基、承重墙、管线都给你铺好了，我可以把省下来的 70% 时间花在真正重要的事上——打磨回答质量、盯用户反馈、调整获客渠道。

选型时我也做了个简单对比，大家感受一下我的决策逻辑：

当然，选 Cosmius AI 也有代价，后面我会讲到它的限制和踩过的坑。但至少前期它帮我躲过了“基础建设综合症”。

1.3 OpenClaw 的定位：不是聊天机器人，是“会跑腿的 Agent”

很多人做 Agent 最大的误区，是把 Agent 做成一个话痨聊天机器人，用户问一句它答一句，答完就完了。我做 OpenClaw 时，从一开始就把它定义成“有手有脚的助理”，不是“有嘴的百科全书”。“Claw”就是爪子，意味着它能抓取信息、调用工具、触达用户，而不是坐在那儿等用户输入。

我把 OpenClaw 的能力拆成四层：听懂问题、检索知识、调用工具、主动触达。听懂问题靠意图识别；检索知识靠清洗过的知识库；调用工具是去查实时门店信息、价格区间、甚至生成一张对比图；主动触达是当用户问完一个问题后，Agent 会根据上下文主动补一句“要不要我把附近三家店的距离和人均价格一并对比给你”。这四层每一层单独看都不复杂，但串起来之后，用户的体感就完全不一样了。

产品定位清楚以后，接下来 30 天的路径就变成了：第一周收敛需求，第二周搭链路，第三、四周接渠道、拉用户、迭代。下面我把每一步具体做了什么，做了什么取舍，都摊开讲。

2. 从 0 到 1：30 天跑通全流程的实操经过

2.1 第一周：需求收敛，画一条极窄的 MVP 边界

做 MVP 最大的考验不是“加什么”，而是“忍住不加什么”。我给自己列了一份明确的拒绝清单：不做美食百科，不做宽泛问答，不做用户生成内容社区。这三个方向看着诱人，但每一个都会把项目拖死。美食百科需要持续维护海量词条；宽泛问答会和通用大模型正面竞争；UGC 社区需要冷启动运营，根本不是一个 30 天项目该碰的东西。

所以第一版 OpenClaw 只保留了三个核心功能。第一，时令口味推荐，回答“现在吃清蒸还是十三香合适”“孕妇适合吃什么口味”；第二，门店估算和提示，基于用户地理位置或指定区域，给出大概的人均价格区间、排队情况提示和消费场景匹配；第三，食用问答，覆盖“怎么判断新不新鲜”“怎么快速剥虾”“虾头能不能吃”这一类高频生活级问题。

功能边界定下来后，我在 Cosmius AI 里做了一套最简配置。这里大家不用照抄，但可以感受一下一个很小的 Agent 项目会涉及哪些关键参数。下面是我当时整理出的思维草图，可以直接把它想成可视化的配置导出内容：

{ "project": "小龙虾 AI OpenClaw", "intent_classifier": { "threshold": 0.7, "intents": ["recommend", "store_query", "eating_qa", "small_talk"] }, "knowledge_base": { "source_count": 1200, "clean_count": 300, "retrieval_top_k": 5 }, "tool_gateway": { "enabled_tools": ["store_lookup", "price_estimator", "menu_compare"], "timeout_seconds": 5, "whitelist": ["store_lookup", "menu_compare"] }, "fallback": { "low_confidence_route": "manual_review", "auto_reply_templates": 8 } }

解释几个关键参数，都是我实际调试后觉得特别重要的：

• threshold: 0.7是意图识别的最低置信度阈值。低于 0.7 的请求我不会让 Agent 硬答，而是转给人工预览或走通用闲聊兜底。这个值不能设太低，否则什么乱七八糟的问题都会被 Routing 到核心意图上；也不能设太高，否则用户正常表达很容易被拒之门外。0.7 是我在测试集上跑出来的一个相对平衡点。
• source_count: 1200到clean_count: 300，这个数字对比可能很多人会惊讶。我最初往知识库里扔了 1200 条内容，结果测试时发现回答质量反而不行。因为这些条目里有大量营销号内容、重复信息和互相矛盾的说法。后来花了整整两天清洗，砍到 300 条高质量、可交叉验证的内容，回答准确率反而明显提升。知识库真的不是越多越好，宁缺毋滥。
• retrieval_top_k: 5，也就是每次回答时最多召回 5 条相关知识。这个数字太小，信息不够；太大，模型会被无关内容干扰，回答反而跑偏。5 是一个比较稳妥的经验值。

2.2 第二周：在 Cosmius AI 上把 Agent 链路串联起来

功能边界定了以后，第二周主要做一件事：把“用户提问 → 意图识别 → 分支处理 → 工具调用 → 生成回复 → 反馈记录”这条链路完整串起来。听起来像套话，但真正做起来，每一步都有坑。

首先是意图识别。我用了关键词和模型判断结合的方式。对于“推荐”“好吃”“哪家”这种信号明确的词，关键词规则先拦截，命中之后再把整句交给模型做置信度判断。为什么要多此一举？因为纯关键词容易误伤，比如用户说“我不想要推荐”也会被“推荐”这个词击中；纯模型判断又容易在冷门表达上犹豫不决。两者结合之后，准确率会高很多，尤其在“reject”表达上。

其次是知识库管理。我把清洗后的 300 条内容统一结构化成了四段式：标准问题、要点摘要、扩展信息、拒绝项。举个例子，关于“虾头能不能吃”，标准问题是“虾头到底能不能吃”，要点摘要给出明确结论“不建议吃，尤其不要吸虾头里的黄”，扩展信息解释原因，拒绝项则记录哪些问法要避免误答，比如“虾头豆腐汤能不能喝”这种延伸问题。这个四段式结构后来被证明是知识库质量的命门，没有结构化之前，Agent 经常答非所问，结构化之后回答稳定了很多。

然后是工具调用。Cosmius AI 自带 API 网关，可以配置外部服务。我给 OpenClaw 接了两个工具：门店信息查询、菜单对比生成。门店信息查询用于获取某区域的小龙虾门店列表、大概人均价格和用户评价摘要；菜单对比生成则是把“小龙虾球 vs 整虾”这类问题，生成一张对比卡片。刚开始我天真地以为工具越多越好，结果发现凡是能调的工具，Agent 都会找机会用，有时候用户问一句“今天下雨适合吃什么”，它都能跑去调门店查询。后来我加了白名单机制，把工具调度限制在store_lookup和menu_compare两个最核心的工具上，其他工具一律禁用。

这里要特别提一下超时设置。我把工具调用网关的超时时间设成了 5 秒，超过直接放弃工具返回，改走知识库回答。因为用户问小龙虾相关问题时，耐心非常有限，与其等一个 8 秒的门店查询，不如先给一个可靠的通用答案。跑通之后，单个请求的平均耗时大约 2.8 秒，其中意图识别 0.3 秒，知识库召回 0.5 秒，工具调用 1.2 秒，生成回复 0.8 秒。道理很简单，Agent 交互里“快”本身就是体验的一部分。

最后是兜底链路。所有低于置信度阈值的请求，会自动进入一个人工预览队列。我当时的处理策略是：先让 Cosmius AI 基于上下文生成一个“建议答案”，我只需要改成更适合口语化的表达，一键发出。这样既不用从零打字，又能保证质量。一个人盯着的情况下，每天处理 30-50 条兜底消息完全吃得消。

2.3 第三、四周：渠道接入、自动化分发和用户反馈闭环

链路在 Cosmius AI 上跑通之后，第三周开始接真实渠道。我当时定了三个入口：即时通讯群聊机器人（用于私域互动）、内容社区的私信自动回复（用于把内容读者转成用户）、以及短视频评论区关键词自动回复（用于截流高意向用户）。这三个渠道有一个共同点：用户都在“有问题要解决”的现场，而不是像官网那样等着被访问。

渠道接入本身不算难，真正难的是自动化分发和频率控制。我最初写了个脚本，每天定时在不同渠道推送“今日小龙虾小贴士”，结果第一轮就被平台判定为过度营销，群聊也差点被用户投诉。后来我改成了“服务型触发 + 限量定时”的策略：定时内容每天最多一条，而且必须是有实际价值的实用帖；其余时间全部走被动响应，用户提问才触发回复。这个改动之后，渠道的负面反馈立刻降下来了。

这里有一个非常重要的认知：自动化是放大器，不是播种机。第三周刚开始时，我几乎把所有运营动作都自动化了，结果触达率很高，转化率却很低。后来我恢复成“高人工 + 低自动化”的组合拳：人工写内容、人工维护种子用户、人工在评论区回复前几条问题，自动化只在“已经验证过的动作”上重复执行。这么一调整，用户增长才真正开始爬坡。具体每个渠道的表现，我在下面第三节详细展开。

3. 600 个用户是怎么来的：获客拆解与渠道复盘

3.1 冷启动：第一批 50 个种子用户，是在“问题发生地”捞到的

冷启动阶段最忌讳的事，就是到处发广告链接。我见过太多人做一个产品，第一件事就是拉个群，然后往所有群里丢二维码，结果不是被踢就是被无视。我当时的做法非常简单：去问题发生地，先当一名“有价值的回答问题的人”。

我在几个私下活跃的吃喝群里，专门搜索“小龙虾”“夜宵”“剥虾”这些关键词，看到有人提问就手动回答。比如有人问“怎么判断小龙虾新鲜不新鲜”，我会很认真地回答：看尾部是否弯曲，弯曲的说明生前活跃；看虾腮颜色，发白的是干净水质；再看虾肉是否紧实。我把这一整段干货直接发出去，最后再补一句：“这些东西太多太杂了，我正好做了一个小程序，叫小龙虾 AI，你以后直接问它就行。”因为我已经先提供了实实在在的价值，用户对我后面这一句并不会反感，反而会好奇点开试一下。这一招帮我搞定了第一批约 50 个种子用户。

还有一个细节是，种子用户运营阶段要尽量“真人化”。我用的是同一个头像和昵称，但语气上会刻意做到有温度。用户问了一个问题，如果 AI 答得不够好，我直接真人回复，并告诉他“这个问题我记下来了，明天更新后会改得更好”。这样做的好处非常大，不仅让用户觉得被重视，还能顺便验证哪些问题是高频的。第一批用户里，有至少十几个后来成了我的自发传播者，帮我在自己的好友群里推荐 OpenClaw，这比花钱投流量划算太多了。

3.2 渠道数据复盘：内容型渠道远胜投放型渠道

到 30 天结束时，我一共新增了 600 个用户左右。这里需要坦诚地说，这个数字并不算爆炸性增长，也没有一夜爆红，就是靠每天匀速滚出来的。我把三个渠道的数据拉出来做了一个复盘表，大家可以直接感受一下差异：

这里面最出乎我预料的是内容社区。我原本以为短视频是流量大头，但实际转化下来的 7 日留存只有 22%，很多用户是被有趣的内容吸引来的，来了以后发现“这个 AI 也不是很懂我”，就走了。反而是内容社区的用户，因为他们是读完一篇实用长文、带着具体问题来的，留存明显更高。这也解释了为什么我认为“精准流量 > 泛流量”。

另外要提醒一句，所有渠道在接入时都要控制频次。我早期吃过一次亏：在某短视频评论里用脚本自动回复，频率没控制好，导致账号被限制了，直接损失了一周的潜在流量。后来所有自动回复我都设置了每 5 分钟最多回复 2 条、每次只回复带明确问题词的评论，再也不碰“关注我私信领取”这类高风险内容。

3.3 把“有用瞬间”变成传播素材

600 个用户里，有很大一部分是通过用户自发分享带来的。我发现一个规律，用户并不会因为你的产品“功能多”而分享，但会因为“这个 AI 居然懂我”而分享。刚开始我没意识到这一点，后来一位用户在群里发了一张和 OpenClaw 的对话截图，问的是“带爸妈吃小龙虾，点什么口味不踩雷”，Agent 给出的回答不仅推荐了蒜蓉，还解释了原因，顺手提示“可以减少辣度，要求后厨分开炒，避免过敏原”。那位用户配了一句话：“这 AI 比我还懂我妈。”这张截图在当天就带来十几个新用户。

从那以后，我开始有意收集类似的“有用瞬间”，在获得用户授权的前提下整理成测试卡片，作为自己的迭代素材。传播的关键并不在于截图好不好看，而在于看到的人能不能产生“我也想问一下它”的代入感。你不需要做一支精美的宣传片，你需要的是用户说出的那句真实的“哇”。

3.4 留存动作：让用户第一次用就有获得感

拉新只是第一步，小程序和 AI 类的产品最怕的就是“来了就走”。我在留存上做了三件事，效果比较明显。第一件事是首次进入时的“欢迎问题单”，用户进入后我不会让他干巴巴地输入，而是推一个问题模板，比如“试试问我：第一次吃小龙虾点什么口味最好”。有了一个具体的问题，用户才知道这个 AI 能干什么。第二件事是“每周迭代公告”，我每周五会在群聊和内容社区发一封简短的更新说明，告诉大家本周修了什么、新增了什么。这让人觉得这个产品是活的，不是丢在那里就没人管的。第三件事是沉默用户召回，我会给一周没活跃的用户推送一条有价值的小贴士，而不是“快来玩呀”这种求运维式消息。比如“你知道冰镇小龙虾的虾肉为什么更紧实吗？”这种内容本身就自带打开动机。

4. 踩坑实录：这 30 天里，哪些坑我踩过了必须说实话

4.1 坑一：Agent 会“自作主张”调用工具

这是我这 30 天里遇到的最诡异、也最典型的 Agent 问题。有一天晚上，有个用户问“小龙虾过敏还能吃吗”，OpenClaw 居然调用了门店查询工具，直接给人推荐了附近门店。我第一时间看到日志的时候整个人都愣住了，因为从语义上看，“过敏还能吃吗”明显是一个健康类问题，和门店推荐八竿子打不着。

查了日志之后发现，问题出在意图识别之后的执行层。虽然意图识别把它正确分到了“食用问答”，但 Agent 的工具调度策略是“一旦可能提供帮助就调用工具”，于是它就顺手把门店查询当作了附加操作。这个问题的根因不是模型不够聪明，而是工具调用的“业务条件校验”没做好。我后来加了一条规则：只有同时满足“意图为门店查询”且“用户提供了位置或地点特征”时，才允许调用门店工具。一切其他意图下的工具调用都会被网关拦截。修复之后，同类问题再也没有出现过。

这个坑值得每一个做 Agent 的人重视：Agent 的“主动性”必须被业务边界锁住，否则用户会被一些莫名其妙的行为搞到失去信任。

4.2 坑二：知识库“一本正经地胡说”

第二个坑来自知识库本身。我在清洗前的 1200 条内容里，混了大量来源不明确的信息，结果 Agent 会一本正经地说出“小龙虾不用洗就能吃”这种完全错误的结论。当时我还觉得奇怪，为什么测试时没发现，上线后却被用户指出来了。后来复盘发现，测试时我用的全是自己精心准备的案例，而真实用户的问题变化多端，一旦触发某一条错误知识，模型就会基于这条错误知识生成一整段流畅但有毒的回答。

事后我做了两轮清洗。第一轮是来源可信度过滤，凡是来源不明确、没有交叉验证的内容全部删除，只保留“至少两个独立来源一致”的信息。第二轮是冲突检查，我把所有条目两两对比，凡是结论互相矛盾的，手动确认保留更合理的一条。通过这两轮清洗，知识库从 1200 条砍到 300 条，准确率肉眼可见地上升。更重要的一个配置是“低置信拒答”，当召回内容之间一致性不足时，Agent 可以直接回答“这个问题我没有足够把握，建议询问现场商家或查看官方说明”，把拒答做成一种正常行为，反而能赢得用户信任。

4.3 坑三：响应慢，用户等不及就走了

第三周开始用户量上来了，我连续收到好几个用户反馈“回复好慢”。后台数据确实很难看，高峰期请求平均耗时超过了 10 秒。这是我最焦虑的一段时间，因为用户来问小龙虾问题时，往往正拿着手机等着下单，根本没耐心等一个慢吞吞的机器人。

我逐个排查后锁定了两个主要瓶颈。第一，知识库检索完全没有缓存，每一条重复请求都会重新走一次完整的召回和打分流程；第二，外部接口调用是串行执行的，门店查询和价格估算要依次排队，时间叠加。解决方式很直接：在 Cosmius AI 的配置里打开了热回答缓存，把最高频的 50 个问题设置成缓存 24 小时；同时把工具调用改成并行触发。优化之后，平均耗时从 10 秒降到了 2.8 秒，体感完全不一样了。热回答缓存的思路是我在运营后台发现的，很多类似平台都有，只是默认没开，大家做类似项目时一定要检查这个配置项。

4.4 坑四：人工兜底成为瓶颈

用户规模超过 200 以后，人工兜底队列开始爆掉。因为我的兜底规则比较保守，所有置信度低于 0.7 的问题都会进人工队列，平时还好，周末高峰期一小时就有四五十条。我一个人根本处理不过来，结果就是用户等了很久才被回复，体验很差。

我的解决方案分两步。第一步，把兜底从“纯人工处理”改成“半人工处理”，也就是让 Cosmius 先基于已有知识生成一个建议答案，我只需要一键确认修改再发送，单条处理时间从 2 分钟压缩到了 20 秒。第二步，我每周五会把所有兜底过的问题拉出来做一次聚类，把高频问题以标准答案的格式回填知识库。随着回填次数增加，需要人工处理的比例从最初的 25% 降到了 8% 左右。这是一个可持续的正循环：人工负责处理边缘问题，处理完之后把经验沉淀回知识库，Agent 的能力因此越来越强。

4.5 坑五：冷启动阶段，别太迷信自动化

最后这个坑更像是一条心法。我第三周刚开始接入短视频渠道时，因为手头事情太多，就写了一套全自动的评论回复和私信推送脚本。结果不仅触发平台限制，而且回复内容机械感极强，用户一眼就看出来是机器人，根本不买账。后来我把策略改成了“高人工 + 低自动化”，前两周所有内容都是我一条条手动发的，所有回复也都是我一个字一个字敲的。自动化工具只用来记录数据、给关键词打标、标记待处理项。

这段经历让我想通了一个道理：冷启动阶段，自动化并不是效率工具，而是放大工具。它能放大你的服务能力，但也会放大你的机械感、错误判断和平台风险。正确做法是先靠人工把每一个动作验证好、优化好，再逐步用自动化替代。我会建议所有做类似项目的朋友，前 100 个用户尽量用手工打磨服务体验，等到你把用户最常见的 20 个问题都背下来以后，再让 Agent 和脚本上场。

5. 数据复盘与真实判断：30 天 600 用户到底算什么

5.1 这组数据的含金量在哪

30 天 600 用户，放在大厂产品面前确实不够看。但我们要看分母和背景：一个人开发，没有投放预算，没有团队，白天还有本职工作。这 600 个用户不是通过买量买来的，而是通过 300 多条真实回复、60 多篇实用内容、20 多次迭代一点点攒出来的。从留存看，整体 7 日留存大约 30%，不算特别好，但考虑到是工具型产品，且只跑了一个月，这个数据其实说明了需求是真实存在的。

我也要诚实地讲，这里有一个明显的局限：600 用户高度依赖小龙虾的季节性热点。如果现在是冬天，这个增长速度大概率做不到。换句话说，这个项目的增长红利很大程度上来自“夏天 + 夜宵 + 内容话题性”的叠加，而不是产品本身的魔力。如果你要复制这个玩法，一定要先想清楚：你的产品所处的季节窗口是什么？热点能持续多久？这两个问题想不清楚，很容易把一时热度误判成长期机会。

5.2 算一笔账：时间、成本与收益

我知道很多人关心的是“花了多少钱”。这里我公开一下真实开销，供参考：

算上时间成本，这个项目更像是一次“以时间换认知”的投入。收益不只是用户数，更重要的是换来了几十条真实的用户反馈、一套可复用的 Agent 搭建方法，以及一批知道你有什么用的种子用户。如果目标是赚钱，这个规模远远不够；但如果目标是验证一个想法、理解 AI 应用的用户交互习惯，这笔投入是相当划算的。我一直觉得，做小体量项目，账不能只看钱，要看“你愿意花钱买哪些认知”。

5.3 如果重来一次，我会在哪三件事上砍时间

30 天跑下来，我有三件事是明显可以做得更快的。第一，我不会再花一周时间去做一个精美的官网页面。因为没有人会因为官网好看而来用你的 Agent，他们只会因为你能解决他的问题而来。官网后来基本没人访问，纯属自我安慰。第二，我不会在第一周就死磕系统提示词的“文采”，比如试图把开场白写得妙趣横生。后来发现用户根本不在乎开场白有多精彩，只在乎回答准不准、快不快。第三，我不会在初期同时铺三个渠道，而是会在内容社区先把一套“高转化”打法打磨干净，再复制到其他渠道。一次性铺开的结果是三个渠道都做得不够深，反而消耗了大量精力。

我会建议大家把砍下来的时间，全部投向两件事：和种子用户聊天，以及看后台日志里每一个回答质量不佳的案例。这两件事带来的复利，比任何精美的包装都大。

30 天结束了，我现在还留着那段时间的用户反馈记录。最打动我的是一个用户半夜问“刚剥完虾手指很腥怎么办”，我当时让 OpenClaw 从知识库里检索出了一条“用牙膏搓洗，再用柠檬汁搓一遍”，她第二天专门回来留言说“居然真的有用”。那一刻我就觉得，这个项目值不值得继续做，根本不需要什么宏大理由。如果你也想做一个类似的小体量 AI 项目，我的建议只有一句：先让你的 Agent 在 10 个真实用户面前不犯蠢，再考虑 100 个、1000 个用户。600 个用户并不难，难的是那 600 次回答里，有几次让人真正觉得“这 AI 有点懂我”。把全流程跑通，比拿到一个好看的数字重要得多。