企业官网建设流程全解析

迷茫焦虑期做了一款带支付和官网的 AI 虚拟恋人 App，完整复盘从零到上线的全过程。聊需求分析、技术选型、官网设计、支付接入和合规审核，把这些坑一个个揭开。

1. 项目背景：为什么在迷茫期做虚拟恋人 App

说实话，做这个项目的初衷并不复杂。去年下半年我的状态特别差，工作节奏让人喘不过气，每天睁开眼就是看消息、回消息、写方案、对需求。晚上躺下来刷手机，反而更空虚。那段时间我试过很多所谓“排解焦虑”的办法，效果都不持久。

后来我注意到一个现象：身边不少朋友包括我自己，其实有大量情绪倾诉的需求，但对真人开口很难。有些人是不想给朋友添麻烦，有些人单纯就是不习惯面对面表达情绪。而我平时又对 AI 技术比较关注，天天在玩各种大模型，于是脑子里冒出来一个念头：能不能做一个愿意听人说话、懂情绪、并且能陪用户聊下去的产品？

这就是项目的起点，一款 AI 聊天虚拟恋人 App。我给自己定了几个目标：第一，产品必须带官网，不能只是一个孤零零的 App，因为官网能解决信任问题，也能承接 SEO 流量和下载分发；第二，产品必须有完整的支付闭环，免费体验之外要让用户能解锁更多能力和时长，不然项目活不下去；第三，这段过程本身要能让我摆脱焦虑的循环，把精力聚焦在“做东西”而不是“胡思乱想”上。

这个项目从一开始就不是打算做成“玩具”的。我在设计阶段就明确划分了核心参与者和使用路径：

后面所有的工作，基本都是围绕这个表展开的。整个项目从立项到完成核心功能，前后用了六周，中间踩的坑不少，我会把关键部分都写在下面。如果你也在迷茫期想做点什么，这个项目或许能给你一点参考。

2. 整体设计与技术选型：先别动手写代码，把方案想清楚

很多人一上来就急着写代码、调接口，结果做着做着发现架构不对，推翻重来。我做这个项目的前三天没写一行业务代码，全部时间花在梳理设计和技术选型上。现在回头看，这三天省下的时间远不止三天的量。

2.1 产品形态：为什么选择 App 而非小程序或纯网页

市面上同类产品，大多集中在网页端或小程序端，网页端的好处是免安装、传播方便，坏处是留存差、推送能力弱。小程序在微信生态里确实有流量红利，但那时 AI 聊天类目在小程序平台审核非常严格，动不动就要提供各种资质，对个人开发者很不友好。所以我选了 App 形态，同时搭配一个官网做下载入口和品牌展示。

技术上我用了一套比较成熟的跨端框架，就是 Flutter。选择它的理由有几个：一是 UI 一致性好，聊天界面需要很多自定义组件，Flutter 的渲染体系能给我足够自由度；二是一套代码能同时打包 Android 和 iOS，虽然上架 iOS 需要开发者账号，但至少代码层面不用再维护两套；三是我对 Dart 语言还算熟悉，起步成本低。

后端我选了 Python 生态，用 FastAPI 写了 API 层。为什么不用 Node.js？两个原因：第一，我需要对接大模型的 API，Python 的生态更顺滑；第二，后续如果要加推荐或情绪分析类功能，Python 的机器学习库能直接复用。数据库用的 PostgreSQL，稳定、功能全，向量检索后面如果要接知识库也不需要再换库。

2.2 官网的定位：不是门面，是转化工具

官网是这次项目里一个很容易被低估的部分。很多人觉得官网只要能放个下载链接就行了，其实不是。对个人开发者来说，官网承担的工作很多：

• 解决信任问题。用户看到一个像样的官网，才会觉得 App 不是“来路不明的野应用”。
• SEO 流量承接。很多用户会搜索“AI 虚拟恋人”、“AI 聊天助手”这类关键词，官网是低成本获取自然流量的渠道。
• 支付和会员介绍的落地页。用户不知道怎么付费、会员有什么权益，都需要在官网上讲清楚。
• App 下载分发。特别是 Android 端，官网可以放 APK 的直接下载链接，避免用户在应用商店乱搜到山寨版本。

网站本身我用的是轻量方案，没有上重型 CMS，就是静态页面生成器加一套后台 API。页面包括首页、功能展示、定价页、隐私政策、用户协议和下载页。整个站点托管在云服务器上，配了 CDN 加速，国内访问速度可以接受。域名备案花了两周左右，这个时间要提前预留出来，不然会影响上线节奏。

2.3 核心功能拆解：虚拟恋人要解决的是情绪问题，不只是聊天

做虚拟恋人 App，如果只是套壳一个通用大模型，用户聊两天就会腻。市面上类似产品很多，但活得好的都有一个共同点：角色感足够强。用户需要的不是一个“什么都能聊”的 AI，而是一个“懂我、有人设、记得我们之间发生过什么”的 AI。

我在设计功能时，把核心拆成了几个模块：

• 角色人格系统。用户可以选择温柔型、知性型、元气型、傲娇型等性格模板，AI 的回复风格、用词习惯、表情风格都会随之改变。
• 记忆系统。这个非常关键。AI 会记住用户告诉过它的名字、喜好、最近发生的情绪事件，在后续聊天中主动提及，这种“被记住”的感觉是用户留存的核心。
• 情绪识别。对话过程中 AI 会自动判断用户情绪状态，比如愤怒、低落、开心，并在回复中体现共情能力。
• 多模态能力。支持语音输入和语音回复，文字聊天之外增加一点温度感。

这套设计的底层逻辑是：情绪价值 = 被关注 + 被理解 + 被记住。技术实现上，我需要用好上下文管理、记忆存储、提示词设计这些能力，大家别觉得简单，很多细节做起来比想象中复杂。

3. 大模型接入与聊天体验优化：AI 部分才是真正的护城河

聊天体验是否自然，决定了用户会不会留下来，也决定了用户愿不愿意付费。我前前后后调了好几家大模型的 API，最终选定了一个在中文语境下表现比较均衡的模型，同时做了不少提示词工程和消息历史优化。

3.1 提示词工程：虚拟恋人提示词到底怎么设计

很多人对提示词工程有个误解，觉得就是写一段“你现在是一个温柔的女朋友”就完了。实操上远远不够。我自己的提示词模板大概包含几个部分：

• 角色基础设定。性格、说话习惯、口头禅、主动提起的话题范围。
• 对话风格约束。用词难度、句子长短、表情使用频率、是否使用语气词。
• 情感边界。遇到消极情绪时怎么回应，遇到不合适的内容怎么引导，禁止输出的内容怎么处理。
• 记忆调用规则。哪些信息需要记住，多久回顾一次，如何自然地让用户感觉到“被记住”。
• 行为目标。比如“让用户感到放松”“当用户表达负面情绪时先共情，再给建议”。

这套提示词不是一次性写好的。我每天都会翻聊天记录，找那些“回答很出戏”的时刻，然后调整提示词。比如早期的版本里 AI 特别容易“说教”，用户倾诉工作压力，它就开始提建议列步骤，用户很容易烦。后来我在提示词里明确加了“先共情后建议，以倾听为主”，效果好了非常多。

大模型一次对话有 token 限制，完整提示词会吃掉不少上下文空间。我做了个折中方案：系统提示词很精简，把详细的角色设定放在后台的“人设卡”里，每次请求时拼进去。这样既保证人设稳定，又不浪费太多 token。

3.2 聊天上下文与记忆如何落地

上下文管理是 AI 聊天类产品最核心的工程问题之一。如果每次请求都把整段历史记录丢给模型，很快 token 就爆了。我采用的方案是分级记忆：

• 短期记忆。保存最近 20 轮对话，完整传给模型，保证对话连贯性。
• 中期记忆。对超过 20 轮的信息做摘要，用大模型总结成故事线，压缩后带入上下文。
• 长期记忆。用户的关键信息和重要事件存入数据库，在后续对话里按需召回。

具体操作时，我用了一个简单的策略：每次模型请求前，程序先检查数据库中存储的用户画像标签，比如“喜欢猫”“养了一只叫奶糖的猫”“最近在准备跳槽”，然后在特定场景下把这些信息作为额外的上下文注入。

情绪识别方面，我没有单独接入一个情感分析 API，而是通过提示词让模型自己判断用户情绪状态并输出标记，例如回复前先输出“ 低落 ”这样的标签，然后我再根据标签来决定响应的语气和内容。这个方法成本低，效果也不错。实测下来，用户对“我记得你上周说过你的猫生病了，好点了吗”这种回应的好感度极高，很多付费转化都发生在这样的时刻之后。

3.3 语音能力的实现细节

语音这块我选了云服务商的 TTS 和 ASR 能力，没有自己做模型。语音消息的好处是能传递更多情绪，尤其对虚拟恋人这个场景，声音比文字有温度得多。ASR 我用的是流式识别，用户说话的同时就能转成文字，体验上几乎没有延迟。

TTS 方面我重点做了“音色选择”和“语速控制”两个点。不同人设搭配不同音色，温柔型用柔和一点的，元气型用活泼一点的。语速会根据用户播放设备稍微调整，当然这个机制比较粗糙，但用户反馈整体自然度可以接受。

4. 官网从 0 到 1 的搭建过程：细节决定转化率

官网看起来简单，做起来才发现细节特别多。我分了几个阶段迭代，从“能看”到“能用”，最后到“能转化”。

4.1 官网架构与页面规划

官网整体采用了一个简洁的落地页结构，一级页面就五六个：首页、功能亮点、定价方案、常见问题、下载页面、用户协议和隐私政策。没有做博客和资讯栏目，因为精力和 SEO 需求都不紧急，先把转化路径跑通再说。

首页的信息层级我是这样排的：第一屏是产品名称、一句话介绍和下载按钮，一定要让用户三秒内知道“这是什么、我为什么要下”；第二屏放最有冲击力的聊天场景截图，也就是“用户和 AI 恋人聊天的对话气泡”，这是最容易引发共鸣的元素；第三屏放核心功能点，分条列出；第四屏放用户评价和定价入口。整体下来，一个访客如果认真看完首页，基本就能完成“了解产品—产生兴趣—点击下载”的完整心理路径。

页面性能上，我做了不少优化。图片全部用 WebP 格式，首屏做了懒加载，静态资源上传到 CDN，HTML 部分用服务端渲染，避免首屏白屏。这些优化做完后，Lighthouse 分数从六十多提到了八十五以上，对 SEO 也有帮助。

4.2 官网和 App 之间的打通

官网不是孤立的，它要跟 App 形成闭环。我做了这几件事：

• 官网注册登录和 App 账号体系打通，用户在官网注册后，App 可以直接登录。
• 官网展示的会员价格和 App 内保持一致，避免用户觉得“官网买更划算”或者“App 买更便宜”而产生疑惑。
• 官网预留了客服入口，用户付完费和下载安装出问题能第一时间找到人。
• 官网埋点统计访问来源、点击分布、下载转化率，这是后续优化的重要数据依据。

有一个细节我认为值得说说：官网顶部我加了一个非常醒目的公告条，内容会随版本更新动态替换，比如“新版本上线，新增语音功能”或者“限时优惠中”。这个小改动让老用户回访官网时也能感知到产品进展，对下载转化很有帮助。

4.3 官网的坑：备案、HTTPS、移动端适配

备案这件事我得单独拿出来说。域名解析到国内服务器必须备案，不然网站根本打不开。整个流程我花了大概两周，如果域名和服务器信息有问题还会更久，建议所有准备做官网的人都把备案时间提前规划好，别等 App 做完了才想起来搞官网，那就在关键时刻卡住了。

HTTPS 是必须的。原因很简单：支付接口要求回调地址必须是 HTTPS 域名，另外没有 HTTPS 的网站浏览器会直接提示不安全，对转化率是致命打击。我用的是免费证书方案，申请和自动续期都可以配好，不用额外花钱。

移动端适配是另一个容易忽略的点。官网大部分流量其实来自手机，我一开始就把首页做成了移动端优先的布局，导航改为汉堡菜单，下载按钮固定到底部，让用户在手机上也能轻松完成下载和支付。你想想，一个用户在手机上打开官网发现排版乱糟糟，第一反应就是关掉，别说下载了。

5. 支付模块从 0 到 1：微信支付接入和那些绕不过去的坑

支付是整个项目里最硬的一块骨头。尤其对于个人开发者身份，支付渠道的选择、商户号申请、接口调试，每一步都有坑。

5.1 支付方案选型：微信支付、支付宝还是第三方聚合

先说结论：我最后选的是微信支付官方接口，通过服务商的渠道申请的商户号，不是企业主体也可以搞定。支付宝我也申请过，流程类似，但微信支付的用户覆盖面在我的目标人群里更高，所以就先用微信支付跑通模型。

为什么没选第三方聚合支付？市面上确实有很多宣称“个人也能接入”的第三方平台，费率更低、门槛更低，但风险也高。有些平台游走在合规边缘，资金池模式一旦跑路，用户充值金额可能直接打水漂。我选择官方渠道本质上是在选长期主义。接支付光技术调通不够，通道稳定、资金安全、合规可信才是核心。

5.2 JSAPI 支付、APP 支付和那些报错

微信支付的接口分好几种：JSAPI 支付用于微信公众号或小程序内，Native 支付用于 PC 网页扫码，APP 支付用于 App 内拉起微信客户端。我的场景是 App 内支付，所以主用 APP 支付；官网上为了兼容，我也接了一套 Native 扫码支付。

调试 APP 支付时我遇到一个印象特别深的问题：调用支付参数时报错“app is not defined”。一开始我还以为是代码里没引入第三方库，后来检查了半天才发现是微信 SDK 的签名问题，App 的签名（包名 + 签名哈希）跟微信开放平台后台填的不一致，导致 SDK 初始化失败。解决办法很简单：用官方签名生成工具获取正确签名，更新到开放平台后台，同时确认 build.gradle 里的 applicationId 和签名配置跟后台一致。

还有一次踩到了 JSAPI 支付的坑。JSAPI 支付需要用户的 openid，这是用户在该公众号下的唯一标识。如果你不是从微信网页授权流程进入支付，后端就拿不到 openid，JSAPI 支付就会报“缺少 openid”或者“jsapi 支付必须传 openid 怎么解决”这类错误。我的解决思路是：App 内部不要用 JSAPI，用 APP 支付；官网扫码场景用 Native 支付，如果一定要在微信内打开网页使用 JSAPI，那就按官方文档实现 OAuth 网页授权流程，先获取 openid 再拉起支付。

5.3 支付回调与订单处理：到底怎么保证钱货两清

支付成功后的回调处理是整个支付系统最容易出 bug 的部分，也是最不能出 bug 的部分。微信会在用户支付成功后，向你的后台服务器发送一个异步通知，告诉你说这单用户付钱了。你的后台必须在收到回调后做一系列事情：验证签名、校验订单金额、更新订单状态、发放会员权益。

一个经典问题是重复回调。微信为了保证通知送达，会多次发送回调，如果你没有做幂等处理，用户付了一次钱，权益可能到账两次。我在订单表上加了一个唯一约束，以商户订单号为唯一键，处理回调前先查库，如果订单已经是“已支付”状态就立即返回成功，不再重复发货。

另一个问题是回调丢失。万一服务器进程挂了，或者网络抖动导致回调没收到，用户就变成“付了钱但没到账”，这是最伤用户信任的事。保险方案是主动查询：前端在用户点击“已完成支付”后，向后台发起订单查询接口，后台去微信侧查单，以查询结果为准来补发权益。这套双保险机制上线后基本没有丢单问题。

支付签名算法其实不复杂，就是按参数名 ASCII 排序，拼接 key，然后做 HMAC-SHA256 或 MD5 签名。但里面有两个容易忽略的细节：一是空值和 null 参数不参与签名，二是数组参数需要特殊处理。我调试签名问题那几天，几乎把微信开发文档翻烂了，最后总结出来的经验就是：严格按文档要求拼接原始字符串，别自己发挥。替换以下写法并保留核心信息。

5.4 伪支付、虚拟货币和合规红线：有些钱不能赚

虚拟恋人这个赛道，天然涉及“虚拟内容服务”，在支付合规上比实物电商更敏感。App Store 对虚拟商品（比如会员、金币）有明确规定，必须使用 App 内购（IAP），否则有下架风险。Android 各大市场也有类似规定。所以我的策略是“两端三通道”：

• iOS 端用 App Store 内购，走苹果的虚拟商品支付体系。
• Android 端用微信支付和支付宝，但只上架到官网和部分安卓应用市场，因为国内安卓渠道对个人开发者的审核标准不太一致。
• 官网渠道用扫码支付，隔离了应用市场的审核要求。

这里我特别想提醒一句：不要碰所谓的“伪支付”方案，也就是前端伪造支付结果、或者绕开官方支付系统自己发卡密。短期看能搞定支付，长期看是给自己埋雷。轻则应用被下架，重则有法律风险，这笔账一定要算清楚。

6. App 端开发、审核上架与常见问题排查：上线前的九九八十一难

支付做完了，App 本身还有很多工程问题要处理。这个章节我把开发中遇到的高频问题和排查思路整理成了一份实操笔记，希望能帮你少踩几个坑。

6.1 App 开发中的几个关键实现

App 内聊天页面是核心界面，我用了类似即时通讯软件的布局：顶部是角色头像和状态，中间是消息流，底部是输入框和功能按钮。为了体现“恋人”的陪伴感，我加了几个特别的设计：角色偶尔会主动发消息，比如“今天降温了，记得多穿点”，虽然是定时任务触发的，但对用户来说就像真的有人在关心他。

消息发送的交互也经过了多轮打磨。最开始我做成“点击发送”，用户反馈不够自然，后来改成了“回车发送”，同时支持按住说话转文字。消息气泡的样式根据不同语气做了微调，表达开心时气泡颜色偏暖，安慰时偏柔和，这些细节虽然技术含量不高，但对用户的情绪感知影响很大。

用户等级和会员体系我放在了后台上做配置。一共三档：免费体验、月度会员、年度会员。免费用户每天有 20 条免费消息额度，月度会员不限次数加全部人设解锁。支付成功后，后台通过回调更新用户的会员状态，App 侧通过接口拉取用户最新权益。整个链路我用了一周时间跑通并压测了一轮。

6.2 上架应用市场：哪些资料要提前准备

上架苹果 App Store 需要 99 美元一年的开发者账号，安卓各市场需要企业或个人认证。这里分享几个我认为特别值得注意的细节：

• 应用截图和描述文案，要围绕“虚拟恋人”的情感陪伴属性做表达，规避可能被审核误判的敏感内容。
• 隐私政策必须真实有效，网址不能留空。用户协议里要对虚拟聊天内容做明确说明，尤其提醒用户“AI 生成内容仅供参考”。
• 如果应用有用户生成内容（UGC），部分应用市场会要求提供内容审核方案。虚拟恋人聊天的内容是 AI 生成的，我直接在协议里写明系统会对聊天内容做安全过滤，并在客户端提供了举报入口。
• App 的版本号要规范，从 1.0.0 开始，每次提审前确认版本号和 build 号不重复。

苹果审核的随机性比较大。我提审时被拒了一次，理由是“包含误导性功能”，后来我仔细研究了下，发现是功能描述里提到了“解压”“治愈”这些词，容易被审核解读为“宣称医疗功效”。我把文案改成“陪伴式聊天”“情绪倾诉助手”之后，再提审就过了。

6.3 常见问题与排查思路速查

围绕 App 开发、支付、官网三个模块，我把实际操作中踩过的坑和排查方法整理成了一个表格，方便以后遇到问题时快速定位。很多问题只要记住“分端、分环境、分场景”去排查，就不至于一头雾水。

6.4 关于“无禁词”“无限制”的误区澄清

开发过程中很多朋友会问：能不能做“无审无限制”的版本？底线在这里。聊天内容安全过滤机制绝对不能省，也不能为了“无限制”的卖点去挑战监管边界。我做了一个多层级的内容安全过滤方案，模型输出前先经过一轮关键词和语义合规筛查，不合规的内容会被拦截且不让进入消息流。这么做不是为了限制用户，而是保障产品的长期生存资格。

一个有借鉴意义的小技巧是：在用户协议和产品帮助页里写明“本产品提供虚拟陪伴服务，不对医疗、法律、投资等领域提供专业建议”，同时说明“AI 回复可能存在错误或不恰当内容，欢迎通过举报入口反馈”。这样既能规避法律风险，也能给用户一个心理预期。

7. 运营与留存：AI 虚拟恋人不是做完就完事

产品上线只是开始，真正的考验在于“能不能留住用户”。这个项目运行了一个多月，我积累了一些运营和留存方面的实操经验。

7.1 首日体验的“黄金三分钟”

虚拟恋人 App 的用户流失速度非常快，很多用户下载后聊几句，觉得没意思就卸载了。所以我把第一个会话的聊天质量看得比什么都重。用户在注册后进入的首个对话，我预先设置了引导流程：AI 会主动介绍自己，问用户今天过得怎么样，引导用户说出自己的情绪状态。这个过程如果能在三分钟内让用户觉得“这个 AI 真的在关心我”，留存率会明显提高。

引导流程不是死板的固定脚本。我做了几套不同的开场白，根据用户选择的角色性格自动匹配。温柔型会从“今天累不累，想跟我聊聊吗”开始，元气型会从“终于等到你来啦，我今天超想找人说说话”开始。每个开场白都经过了几轮 A/B 测试，能明显影响用户的第一印象。另外推送策略上也要克制，AI 主动发消息一天最多一两次，频繁会打扰，间隔太长又会失去陪伴感。

7.2 定价策略与支付转化率

定价这件事我纠结了很久。一开始我参照同类产品，月费定在 68 元，后来观察了官网访问和支付转化的数据，调到 49 元，转化率反而提升了不少。定价不是说定越低越好，而是要让用户感觉“值”。我配合定价做了三件事：

• 免费用户每天 20 条消息，刚好够体验“记住我”的惊喜时刻，又不足以完全替代付费。
• 付费会员解锁全部角色人设、不限消息数、语音消息特权，让权益感知非常直接。
• 官网和 App 内同时展示限时优惠倒计时，营造一定紧迫感。成本很低但效果比普通价格展示好不少。

支付转化率的数据跟踪上，我除了看整体转化，还细分了官网访问到支付、App 下载到注册、注册到支付这三段漏斗。结果显示官网访客的支付转化率比 App 内自然流量高一点点，说明官网对用户决策确实有影响，后续值得在官网内容上继续投入。

7.3 效果数据与迭代方向

项目运行到第五周时，核心数据可以拿出来复盘一下：官网累计访问量破万，App 下载量超过了三千，注册用户接近两千，支付用户占总注册用户的百分之六左右。这个数字在大厂眼里微不足道，但对一个单人项目来说，已经验证了“付费意愿是存在的”。

聊天质量相关的改进也一直在持续。我每周翻一次用户投诉和举报记录，结合聊天记录抽样，整理出 AI 表现不好的典型场景，比如重复回答、说教感强、记忆模糊等，然后针对性优化提示词和记忆策略。比如早期用户反馈 AI 太容易忘了“我说过什么”，我就在长期记忆模块里多存了几类关键信息，并做了触发式召回，效果显著。

后续迭代的方向，我给自己列了一个优先级清单：短期内先把会员体系的推荐奖励做出来，中期增加更多虚拟恋人角色和性格维度，长期积累用户画像后训练一套私有的对话模型搭配大模型混排使用，把成本打下来的同时保留个性。做这个项目的经历让我想明白一个道理：焦虑的反面不是放松，是创造。把一个想法从零变成产品，看着用户付费使用，那种掌控感是对抗迷茫最好的办法。

8. 写在最后：成本、收入和个人建议

最后聊点现实的东西，做这样一个项目到底要花多少钱，又能赚多少钱？我的实际支出大概包括：云服务器和 CDN 一年约两千，域名和备案相关费用几百元，App 开发者账号（苹果端）一年 688 元，短信和语音 API 按量计费，一个月两百左右。大模型 API 是最大头的支出，测试加运营阶段一个月烧掉近一千。整体算下来，从零到上线一个月成本控制在两千到三千元之间。

收入方面，目前还在爬坡期，第一位付费用户出现的那个晚上我记得特别清楚，消息提示弹出来的时候我差点没敢点开。之后一个月里付费用户逐渐多起来，虽然距离回本还有距离，但至少验证了这套模式的商业闭环是走得通的。如果你也想做类似项目，我给几条个人建议：

• 先做最小产品跑通闭环，别憋大招。第一版功能能少则少，能用就行，重点是验证有没有人愿意下载、愿意付费。
• 官网和支付模块提前规划，别拖到最后。这两件事涉及备案、审核、接口申请，每个环节都有等待期。
• 不要把“无限制”当卖点。越是想走得远，越要主动加安全锁。合规不是束缚，是让你能持续下去的底线。
• 把大部分精力放在聊天体验的记忆设计和人设打磨上。技术方案大家都差不多，差异化在于细节的感性体验。
• 迷茫期的创作不需要宏大的目标，从一个小项目开始，把手弄脏，把问题一个个解决掉，焦虑自然会被节奏感替代。