撰文：ultra
编译：Luffy，Foresight News
上周末，我加班做出了 Blind 这个项目，就是为了证明：打造有意义的产品，不需要数百万美元融资、数月工时，甚至不需要团队。
Blind 是基于 Base 链开发的代币发行平台（Launchpad），依托 Flaunch 的基础设施运行。它尝试了一种全新机制：让代币创作者在发行代币时，自主选择公开哪些个人信息。
这样一来，创作者既能利用自己的声誉或资质背书，又无需完全公开真实身份，也不用承担成为 「代币代言人」 通常会带来的麻烦。此外，创作者还能设置预售准入门槛，只允许满足最低条件的用户参与。
本文目的
本文旨在分享我从 「想法」 到 「产品」 的通用框架。
正如我常说的，当下这 6-12 个月是 「想法落地黄金期」，借助 AI 工具，将创意变为现实异常容易，但很少有人意识到这一点。对于愿意投入时间的人来说，这无疑是巨大的套利机会。
我希望这篇文章能激励更多人尝试 vibecoding，将自己的想法变为现实，让 Web3 回归那个由独立开发者和小团队主导、每日都有创新诞生的领域。
本文默认读者已具备一定技术基础，熟悉开发工具、代码仓库管理及常见组件知识。
阶段 0：灵感来源
社交资本门控这个想法，其实在我脑海里已经酝酿了几个月。在频繁使用 Kaito、Ethos、fantasy.top、time.fun 等工具及研究 SocialFi 指标的过程中，讨论里反复出现一个问题：为什么没人做一个仪表盘，能整合显示用户在所有这些平台的个人资料，用分数和数据来评估用户资质？
过去 6 个月左右，「创作者指标」 领域迅速崛起，如今人们可以通过各种数据维度评估一个人或一个账号的价值。
那么，能不能用这些指标来设置 「参与门槛」（比如代币发行的准入条件）？又能不能让创作者自主决定向公众披露哪些指标，同时隐藏自己的真实身份？
真正促使我动手开发的，是看到 Pump.fun 的 ICO 融资了 5 亿美元，最近 heaven 的 ICO 也融了 2000 万美元。在我看来，这两个产品的开发难度都不算高，为什么估值能这么夸张？而且类似的成功发行平台还有很多，都融到了巨额资金。
公平地说，在这个领域，为了保持理性，我们其实已经不再纠结 「代币估值逻辑」；很多时候，估值本身就毫无道理可言。
但无论如何，这引发了我的个人挑战：我能不能在一个周末内，以极低的成本、不依赖外部帮助，做出一个水平相当的产品？
我的目标不是打造商业产品、发行代币，甚至不是赚钱，而是证明 「这件事能做到」，并希望更多人追随这条路径。
阶段 1：问题拆解
有了想法后，第一步是将其拆解为核心组件，并针对每个组件做决策。对于 「带社交准入控制的发行平台」，我梳理出以下几个 子问题：
链上技术栈选择
首要决策是 「部署在哪条链上」，这个选择会影响后续所有实现环节。当时有两个明确选项：Solana 和 Base。
Solana
优势：
土狗币交易量最高的链；
聚光灯效应：任何部署在这里的项目都容易获得一定关注度。
劣势：
实现灵活性低，必须遵循现有代币标准；
开发复杂度高，需要大量变通方案；
开发周期长；
基础设施成本高且不稳定。
Base
优势：
EVM 系链中 「土狗币」 交易量最高；
对开发者支持完善；
EVM 开发体验极佳；
可直接复用现有基础设施。
劣势：
「土狗币」 交易量不及 Solana。
由于 Blind 并非商业项目，只是一个周末练手作品，我们无需考虑 「潜在财务回报」 相关决策，只需选择 「不让开发过程太痛苦」 的方案。
最终我们选择了 EVM。开发区块链应用时，EVM 是最成熟、体验最好的区块链基础设施，能让我们快速、高效且明智地推进开发。
可复用的现有基础设施
确定链之后，下一步是寻找可复用的 SDK（软件开发工具包）或现成合约，避免从零开始写代码。尤其是智能合约部分，优先使用经过审计的合约，能大幅降低安全风险。
幸运的是，EVM 生态中有大量可复用资源，我们主要有两个选择：
基于 Uniswap 等 DEX 开发，在 Uniswap V4 基础上自行搭建所有准入控制逻辑；
基于现有发行平台的基础设施（如 Flaunch 的 SDK）开发，该 SDK 已内置索引、元数据上传、发行曲线配置、预售阶段管理等功能。
我们再次选择 「阻力最小的路径」：基于 Flaunch 开发。这样一来，我们可以专注于 「发行平台的社交属性 + 前端展示」，无需在资金池配置、索引基础设施、收益分成合约等基础功能上浪费时间和金钱。
「既然比你聪明的人已经把活儿干完了，何必再重复造轮子呢？」
代币部署方式
确定 SDK 后，需要决策 「谁来实际执行代币部署」，有两个方案可选：
方案 1：用户发起交易部署代币
需开发代理合约，确保用户选择的发行参数符合平台要求；
需找到办法，在 Flaunch 现有子图索引器中追踪所有已部署代币。
方案 2：用户向后端提交 「部署请求」，由平台机器人执行部署
所有代币均由平台自有 EOA（外部拥有账户）部署，便于在索引器中追踪平台发行的所有代币；
可确保所有发行都遵循统一的标准化参数。
我们选择了 「后端服务部署」 方案：这让代币追踪更简单，也能更严格地控制 「部署内容与方式」，未来还具备升级空间。
所有代币都将由后端控制的钱包部署。
本质上，我们相当于 「精简了 Flaunch SDK」，移除所有不需要的功能，只保留后端请求可调用的部分。
社交数据收集
接下来聚焦社交功能。我们需要确定哪些数据维度对发行平台有价值。理想的数据组合应同时体现 「用户账号状态」 与 「用户声誉」。
最终我选定了以下数据维度：
粉丝数（X 平台 API）
关注数（X 平台 API）
账号注册时长（X 平台 API）
点赞数（X 平台 API）
高价值粉丝数（Moni API）
核心互动用户数（Moni API）
声誉分数（Ethos API）
内容传播度分数（Kaito API）
这样的组合能让创作者在无需完全暴露身份的情况下，通过多维度数据证明自己的资质，脱颖而出。
社交数据处理与隐私保护
用户注册时，我们会收集上述所有数据，但隐私层面该如何设计？
我们的原则是 「默认隐私优先」：所有数据默认不公开，避免泄露；用户可自主决定每个数据维度是否公开。此外，还应允许用户 「模糊化展示数据」（比如实际有 4.3 万粉丝，可选择显示 「4 万 +」），提供半匿名的数据参考。
另外，数据处理应依赖 「中心化后端 + HTTPS 请求」，还是采用复杂的零知识证明技术？
我们的方案是两者结合：
所有数据存储在 Postgres 数据库中，前端通过 HTTPS API 直接从数据库获取信息。预售准入控制则采用以下流程：
用户希望参与预售 → 向平台后端请求 「准入证明」；
后端验证用户是否满足创作者设置的门槛；
后端返回包含 「用户钱包地址 + 过期时间戳」 的签名消息；
智能合约验证签名有效性。
阶段 2：开发实现
开始开发前，先列出所需 「工具清单」：
Railway（后端托管）：20 美元 / 月
Vercel（前端托管）：15 美元 / 月
Cursor（开发工具，含 Claude 4 MAX 模式）：200 美元 / 月 + 100 美元 credits
网站域名：30 美元 / 年
X Premium+（账号会员，用于提升曝光 + 发布长文）：40 美元 / 月
ChatGPT：用于设计 Logo + 品牌视觉，也可替换为其他熟悉的工具
总成本约 405 美元（假设 Vercel 未超订阅限额）。
注：为加快开发，我实际用了比预期更多的 Cursor credits（启用 MAX 模型）。如果不追求开发速度，可选择更便宜的模型。
架构设计
大多数项目都需要 4 个核心组件：
前端：托管在 Vercel（单独的 GitHub 仓库）；
后端：托管在 Railway（单独的 GitHub 仓库）；
数据存储数据库：Railway 上的 Postgres 数据库；
缓存数据库：Railway 上的 Redis 数据库。
简单来说，Vercel 负责所有前端相关功能；Railway 则安全托管 「用户不可见」 的核心服务，如数据处理、代币部署、API 接口、信息缓存等。
大多数后端的架构都像下面这样（没错，数据存在 「球」 里）。
开发顺序
我始终建议先开发核心功能，最后做前端展示。
对本项目而言，最核心的功能（也是需要先测试兼容性的功能）是代币发行。
由于我们已确定 「由后端 EOA 执行代币部署」，因此我们可以为后端创建一个新的 git 存储库，并开始深入研究 Flaunch SDK 文档。
该文档概述了目前在启动配置方面所有可行的功能，甚至提供了一些便于集成的代码片段。它们还提供了一些用于检索数据的 API 端点，以及一个子图，可以自动索引 Flaunch 上发生的所有事情（包括从 Blind 前端启动的代币）。
1）测试代币发行功能
在新的后端仓库中，第一步是搭建本地环境，测试能否通过 SDK 成功发行代币。我们可以先写一个简单的 Node 脚本，后续再将其改造为 Express 服务器接口，调用该接口并传入指定参数，即可完成代币部署。
这个步骤其实很简单，大概率只需一次提示词 + 少量调试就能搞定。
而且代币部署的 Gas 费不到 0.01 美元！这意味着我们可以为用户提供完全免费的代币部署服务。
2）拉取社交数据
第二步是开发另一个核心功能：社交评分。针对之前选定的所有数据维度，我们需要查看每个 API 的文档，然后在 Express 服务器中创建一个端点，该端点会根据用户名返回所有数据。然后，我们可以将这些数据存储在我们在 Railway 上创建的 Postgres 数据库中。
3） 注册流程
到这一步，开发会变得稍微复杂，需要同时推进前端仓库的开发。我们选择 Next.js 作为前端框架，原因是它对 Vercel 支持最好，且支持中间件实现身份验证。
在注册流程中，我们希望用户首先链接他们的钱包，然后通过 X 进行身份验证，最后通过调用我们的端点进行注册。
我们首先查看 X 身份验证 API 文档，在前端实现一个简单的注册页面，并在后端存储库上创建一个注册端点。
在注册过程中，我们还需要提取步骤 2) 中的所有数据并将其存储在数据库中，并额外添加一个钱包地址条目。所有发送至注册端点的请求都应同时进行 X 密钥认证和钱包签名认证，以防止身份冒充。
一切正常后，我们还需要向代币部署端点添加身份验证，以便只有注册用户才能部署代币。对于注册端点之外的任何端点，我们决定仅通过钱包签名消息进行身份验证，以避免每次都使用 X 登录。
4）隐私设置
完成注册流程并实现数据存储后，下一步是开发隐私设置：
在数据库中创建数据可见性设置表（默认所有数据均为私有）；
开发已认证用户可调用的隐私设置修改接口；
编写辅助函数，支持用户选择模糊化展示数据；
开发前端 隐私设置编辑组件。
5）接口检查与优化
核心服务就绪后，需做以下优化：
所有服务器核心功能均已准备就绪，现在我们需要确保所有端点在需要时都使用身份验证，并且在公开访问时不会泄露任何个人信息。我们还可以使用 Redis 缓存来优化部分 API，以避免服务器不必要的负担。最后，我们添加了几个 API，用于获取用户公开个人资料、代币所有者及其数据、币种数据等。
6）前端开发
现在是时候创建一个美观的网站了。我们先确定主题、要显示的页面，并开始移除「私人」部分。对于显示自定义排序的代币列表和其他数据，我们可以依赖 Flaunch 的子图，并根据部署者地址进行过滤，以此作为我们的 EOA。对于代币详情页面，快速显示图表的方法是嵌入一个简单的 DexScreener iframe。
7）测试
一切终于准备就绪。测试用户流程，将所有内容部署到 Vercel 和 Railway，并与朋友分享访问权限以获取反馈。目标是打造一个与生产环境 1:1 一致的环境。
8）根据反馈优化
这是上线前的最后一步。
阶段 3：公开上线
公开上线分为两步：先做品牌建设，再进行市场推广。
品牌建设
之前我没提品牌建设，是因为它随时可以做，但最好在前端开发前完成。品牌核心要素（名称、Logo、配色、域名）需满足 「简洁、易识别」 的原则。
我个人很喜欢的一个玩法是 「单字命名 + 域名组合玩梗」：
项目名选了 「Blind」（意为 「盲投」，暗指用户在信息有限的情况下购买代币）；
域名选了 goblind.xyz，巧妙融合了 「go blind」（盲投）、「goblin」（地精，带点趣味感）、「goblin’d」（地精化）三个含义；
配色方案故意选了亮到刺眼的浅色模式，搭配 「野兽派」 设计风格，让人联想到盲文文档，呼应 「Blind」 的主题；
Logo 设计：用 ChatGPT 生成（以现有主题为背景提示）；
市场推广
是时候让全世界知道我们的 MVP（最小可行产品）了！通常来说，让别人知道的最好方式不是 直白告知，而是 制造困惑。
困惑营销
正式推广前，建议先确保 MVP 功能完整。最好在上线前一周启动营销，这样能将公众注意力集中在一周内，更易占据社交平台话题榜。
这一周的核心目标是：
让更多人关注项目的 X 账号，并开启通知；
发布模糊的预告、玩梗内容，但绝不直白透露项目功能；
留下 「线索」，让网友自发在评论区猜测，让他们替你制造热度。
虚荣指标：让用户不再孤单
配合 「困惑营销」 的有效手段是 「排行榜」！人们既想 「抢占先机」，又不想 「太早入场」。你的任务是 「让平台未上线先‘活’起来」。
「注册 + 排行榜」 活动有以下好处：
提前引导用户注册，分散网站流量，测试系统稳定性；
让用户持续关注项目：「早注册有福利吗？」进而开启账号通知；
人们喜欢 「比别人强」 的感觉：排行榜排名易分享，还能让用户发现自己账号的有趣数据；
便于团队对外宣传 「增长数据」。
Blind 上线前，预注册用户就突破了 4 万人！
注：如果加入 「邀请链接」 机制，增长速度会更快。
24 小时倒计时预告
是时候揭晓 Blind 的核心功能了！文章发布时请告知他们，这样他们就能有个具体的时间去期待。最后 24 小时，锁定你对 Blind 内容的猜测。24 小时让所有时区的人们都能做好准备。
发布上线文章
此时用户都在刷新你的 X 账号主页，是时候发布文章了！文章中需详细说明：
Blind 的核心功能；
正式上线时间；
无需过于技术化，也不用罗列所有功能，重点传递 「开发动机」「核心想法」 及 「项目吸引力」；
如需补充技术细节，可在文章外单独提供文档。
阶段 4：正式上线！
文章中需说明 「上线时间为文章发布后 24 小时」。此时预注册用户已做好准备，就等部署代币了。接下来，我们要：
将所有环境切换到生产模式；
切换部署者 EOA 账号；
随时待命，应对上线可能出现的错误（错误总会发生）。
好了，正式上线！
总结
开发 MVP 时，永远选择 「阻力最小的路径」。无需追求一步到位的完美，可在生产环境中逐步迭代优化。抓住时机往往比 「等一切准备就绪」 更重要。
但也要注意：第一印象至关重要。用户第一次访问平台的体验，会直接决定他们对平台的长期认知，别指望大多数用户会持续关注 「功能更新」。
这个副业项目开发过程非常有趣，我学到了很多，也做出了一个 「人们可能会用来发行代币」 的工具。