夜雨聆风
从一个价值观出发，8 小时做出一个真实上线的社区产品
一个周六下午 2:30，我们三个人开始讨论一个问题：
一个长期为社区做贡献的人，为什么只能依赖 Founder 的记忆，才能被看见和获得回报？
提出这个问题的是 AI+X 社区 Founder 谢苹果。他不喜欢“一个人做了贡献，却没有被激励和看到”，这不符合他希望建立的社区价值观。因为我有区块链行业背景，接触过大量 Token 经济模型和安全审计，他找到我，希望一起设计一套 AI+X 社区内部的 Token 机制。
我们最终没有把它做成 Token，而是把它定义成一种不可购买、不可转让、不可提现的社区贡献点，并给它起名叫 Apple。
当天，我们还给自己设定了一个非常激进的目标：晚上之前做出 MVP 并上线。于是我、Founder 谢苹果和 CTO Frank 从下午 2:30 一直工作到晚上 10 点多，完成了第一版设计、开发和上线。
这是我第一次真正做出一个有真实用户、真实业务行为，并解决实际问题的产品。
一、我们真正想解决的，不是“怎么发积分”
AI+X 社区目前有超过 5000 名成员，其中超过 500 名是华师大校友。社区中有技术、运营、活动组织、志愿服务、内容传播和用户增长等大量工作。
项目开始前，这些贡献主要依赖 Founder 的个人记忆进行记录。贡献者得到的回报通常是口头表扬，或者由 Founder 根据对方的需要提供资源和帮助。
这种方式在社区早期有效，因为它有人情味，也足够灵活。但随着社区扩大，问题开始出现：
Founder 不可能长期记住每个人的每一次贡献； 贡献确认高度依赖个人判断，缺少稳定规则； 成员不知道自己的贡献是否被记录； 后加入的管理者很难还原历史； 社区提供了很多资源，但贡献和资源之间没有形成可持续的连接。因此，这个项目表面上是在做积分，底层其实是在解决三个问题：
二、我们为什么做“贡献点”，而不是 Token
最初的讨论确实来自 Token 经济模型。Founder 希望成员主持活动、拉新、参与运营或技术建设后，可以按照一定规则积累 Token，并在未来获得不同等级的福利和资源。
但结合我过去在区块链行业的经历，我提出：可以借鉴 Token 的记账和激励思想，但不要把它做成真正的 Token。
原因有三点。
第一，区块链钱包、私钥和链上交互会明显提高普通社区成员的使用门槛。我们的目标用户是运营人员、学生、校友和各行业从业者，而不是加密行业用户。
第二，一旦可以购买、转让或在市场交易，它就可能从“衡量贡献”变成被投机和操纵的资产，反而破坏社区激励。
第三，Token 的发行和交易会带来完全不同的合规风险。我们希望解决的是内部贡献认可，不希望让产品具有金融属性。
因此，我们为 Apple 划定了清晰边界：
不可购买； 不可转让； 不可提现； 不与现实货币挂钩； 只能通过真实社区贡献获得； 只能兑换社区提供的资源和权益。“Apple”这个名字来自 Founder 谢苹果。大家平时就叫他“苹果”，这个名称天然具备社区记忆和内部传播力。它不只是一个积分符号，也是社区 IP 的延伸。
不过，这个命名也有边界：用于内部社区很有亲和力，对外展示时却容易被误解为 Apple 公司或加密 Token。因此，在简历和作品集中，我会把项目称为“AI+X 社区贡献激励与资源兑换系统”，Apple 只作为系统内部的贡献点名称。
另一个需要继续明确的边界是：如果未来把 Apple 与现金分红、投资收益或创业项目权益直接挂钩，它就会改变当前“非金融贡献点”的性质。福利和社区资源可以继续探索，但涉及现金或投资权益时，应该作为一个全新的产品和合规议题单独评估。
三、第一版产品是怎样定义的
AI+X 原有平台（https://aix.zxy.one/）已有 500 多名注册用户。我们最初讨论过直接复用原平台账号，让所有注册用户进入 Apple 系统。
但我们很快意识到，第一版的核心用户并不是全部社区成员，而是已经持续参与技术、运营、活动和志愿工作的内部贡献者。
如果一开始就迁移 500 多名用户，不仅会增加账号和数据迁移成本，还会让产品在贡献规则尚未验证时过早扩大影响范围。
因此，1.0 版本采用邀请制和独立账号体系：先服务贡献最明确、使用频率最高的内部工作人员，再根据反馈决定是否与原平台账号打通。
这个取舍帮助我们控制了 MVP 范围，也让首批用户更容易理解产品价值。
第一版围绕以下核心流程设计：
排行榜解决的是“贡献被看见”，流水解决的是“贡献为什么被这样记录”，资源兑换解决的是“贡献点最终有什么价值”。
我最初提出了线上和线下两套验证机制。
线上系统保存完整业务流水；线下只维护极简记账字段，例如序号、用户和积分变化。每条记录先单独计算 Hash，再和上一条记录的结果继续计算，最终形成一个连续的 Hash Chain。
线下保存的 Hash 头可以定期与线上系统计算的 Hash 头对比。如果网站被攻击者篡改，线上和线下结果就会不一致，从而提醒管理员检查异常，并根据离线记录恢复可信状态。
这个设计借鉴了区块链的“历史记录相互链接”和“篡改后结果变化”，但没有引入链上账户、Gas、共识和交易市场。
1.0 最终只实现了线上 Hash Chain，没有完成独立线下版本。这是一个有意识的 MVP 取舍：首批用户是内部测试人员，当天上线比一次性做完全部审计能力更重要。
但这里也存在一个需要诚实说明的限制：如果 Hash 和业务流水都保存在同一个系统中，它只能帮助发现意外修改，不能完全抵抗有权限同时重写数据和 Hash 的攻击者。真正实现最初的安全设想，仍然需要把检查点独立保存在线下或另一个可信系统中。
四、产品在协作中发生的关键变化
虽然最初的核心功能主要由我提出，但产品不是我一个人闭门设计出来的。Founder、CTO 和真实运营人员的视角改变了多个关键方案。
从“兑换成功”补齐到“资源真正交付”
我们最初更关注用户如何扣除 Apple、生成兑换记录，却没有充分考虑兑换后的履约时间差。
CTO Frank 提出了一个非常实际的问题：如果用户兑换后需要人工交付资源，管理员怎样第一时间知道？用户又怎样确认系统已经受理？
因此，我们设计了飞书 Bot。每当发生资源兑换，系统会立即向内部飞书群发送通知，管理员随后在线上或线下完成资源交接，再回到 Apple 系统把订单更新为“已完成”。
这个变化让我认识到：
用户点击“兑换”不是流程终点，真实权益交到用户手里才是。
它也让产品从“积分展示工具”变成了一个具备运营履约能力的系统。
从功能安全扩展到部署安全
Frank 过去有网络安全经验，他提醒我们不能只关注登录和权限，还要考虑服务器公网 IP、域名入口和攻击面。
我们最终使用 Cloudflare 隐藏源站 IP并承担外部入口防护，再由阿里云服务器运行正式服务。安全不再只是一个后台权限按钮，而是从域名、网络、服务器到业务操作的完整链条。
从理想流程补齐异常路径
正式系统还必须处理：
发放错误后怎么办； 用户重复点击兑换怎么办； 多个请求同时抢最后一份库存怎么办； 飞书消息发送失败怎么办； 资源无法履约后积分是否退回； 历史记录是否允许删除。因此，系统补充了冲正、幂等、库存事务、通知重试、拒绝退款和库存回补等机制。
其中，“拒绝兑换后自动退款”并不是我一开始主动想到的需求。我最初甚至没有明确在什么情况下会拒绝兑换。这恰恰暴露了第一版产品思考中的不足：我更关注主流程，对异常流程和运营规则考虑得不够完整。
系统已经在功能上补齐了这一能力，但产品层面仍需要进一步定义：
哪些情况允许拒绝； 谁拥有拒绝权限； 是否需要提前向用户展示适用规则； 拒绝后怎样解释，避免影响社区信任。
五、Vibe Coding 并没有替我们做产品决策
这是一个典型的 Vibe Coding 项目。我们主要使用 Codex完成产品规划、代码实现、测试和问题排查，在服务器部署阶段也使用了阿里云提供的 AI。
实际协作方式不是“一句话让 AI 做完”，而是：
这个过程让我认识到，AI 可以显著降低实现成本，却不会替团队统一目标、定义用户、处理分歧或承担结果。
Vibe Coding 中最重要的仍然是人的判断：
什么问题值得解决； 第一版为谁服务； 哪些功能必须做； 哪些风险可以暂时接受； 什么才算真正上线完成。
六、最意外的困难发生在“代码完成之后”
开发之前，我以为最困难的是把产品功能做出来。真正卡住我们的却是部署上线。
我原本希望 Codex 自动完成阿里云部署，但自动操作被阿里云防火墙拦截。后来改为手动部署，又陆续遇到阿里云、Cloudflare、域名和服务器配置问题。
Codex 的浏览器和 Computer Use 操作速度较慢，也多次无法直接解决环境问题。最后，我们结合：
Codex 提供的排查建议； 阿里云 AI 给出的平台侧说明； CTO Frank 的网络安全和部署判断； 人工逐步验证；才完成了上线。
这次经历让我第一次真正理解：
代码能运行，只代表 Demo 完成；真实用户能够稳定访问和完成业务，才代表产品交付完成。
部署不是开发结束后的机械动作，而是 FDE 和技术型产品经理必须理解的一部分。云服务器、防火墙、域名、证书、反向代理和外部平台配置，都可能成为产品能否落地的最后一公里。
七、上线后的第一批真实信号
项目已经部署到 AI+X 社区自己的域名，并开始邀请真实贡献者使用。
上线第二天，系统已有 17 名用户，主要是长期参与社区运营的华师大在校生和校友。团队根据他们过去和当前的社区贡献，向其发放了 Apple。
真实贡献 → Apple 积累 → 资源兑换 → 运营履约
但 17 名用户和一次兑换只能说明产品开始产生真实行为，还不能证明长期激励效果已经成立。下一步需要观察用户是否持续贡献、积分是否持续流通，以及成员是否认可发放规则的公平性。
八、现在回头看，做对了什么
如果没有这个目标，我们很可能会继续讨论完整账号迁移、线下 Hash、更多资源类型和复杂权限，最后得到一份很完整的方案，却没有真实用户。
明确截止时间迫使我们区分“理想产品”和“今天能验证的最小闭环”。
我们保留了 Token 对贡献记账、稀缺资源分配和可审计性的启发，同时主动舍弃交易、转让、投机和复杂链上交互。这让产品更符合社区目标，也降低了用户门槛和风险。
没有直接导入 500 多名平台用户，而是先邀请真实内部贡献者。这使得早期规则不完善时，影响范围仍然可控，也更容易获得高质量反馈。
Founder 提供社区价值观、真实场景和资源； 我负责产品定义，并带入区块链经济与审计经验； CTO 提供网络安全、履约和系统交付视角。三种视角让产品既没有停留在概念，也没有只关注技术实现。
九、哪些地方仍然没有做完
系统已经能可靠记录积分，却还没有完全解决“应该给谁发多少”的问题。后续需要建立：
贡献类型和建议积分区间； 提报、确认和审批机制； 单次或周期发放上限； 争议与申诉流程； 规则调整的公开方式。否则，系统只是把 Founder 的个人记忆升级成了更稳定的人工记账，还没有真正形成可扩展的社区治理。
排行榜能够让贡献被看见，也可能让成员把贡献理解成竞争，或者因为长期排名靠后失去参与意愿。
后续需要通过访谈验证：
成员更在意余额、排名还是贡献荣誉； 是否应该展示完整排名； 是否按运营、技术、内容等贡献类型分别认可； 是否需要周期榜、成长榜或非排名式荣誉。
这是我最初产品设想中最有区分度的部分，但为了 MVP 上线被推迟。下一阶段需要把它从概念变成真正可执行的备份、校验和异常恢复流程。
目前我们有用户数和真实兑换案例，但还缺少能够判断产品价值的长期指标，例如：
活跃贡献者数量； 每周新增贡献记录； Apple 发放与消耗比例； 获得 Apple 后的 30 天兑换率； 订单平均履约时间； 被拒绝和退款比例； 积分是否过度集中在少数成员； 成员对规则公平性的主观评价。
十、这次项目改变了我对 AI 产品经理和 FDE 的理解
过去我更多是一个人完成产品设计和开发。这次是我第一次和 Founder、CTO、真实运营人员共同完成一个上线产品。
我对 AI 产品经理的理解从“把需求设计清楚，再让 AI 实现”，变成了：
在用户价值、业务规则、技术边界和交付风险之间持续做判断，并借助 AI 快速把判断变成可验证的产品。
我对 FDE 的理解也不再只是“懂客户、懂技术、能写代码”。真正的 FDE 需要对最后结果负责：
能把模糊需求翻译成业务流程； 能和不同背景的人达成范围共识； 能借助 AI 快速实施； 能处理权限、安全、外部集成和部署问题； 能在云平台、网络和真实业务之间定位问题； 能把产品真正交到用户手里。AI 大幅降低了代码实现门槛，但也让产品经理更早面对原本可能由多个岗位分别承担的问题。会不会写出第一版代码不再是最稀缺的能力，能否作出正确取舍并完成真实交付才是。
结语
Apple 的第一版并不完美。线下 Hash 尚未完成，贡献规则仍需完善，17 名用户也不足以验证长期社区激励效果。
但它已经跨过了一个对我很重要的门槛：它不是停留在文档和原型中的想法，而是一个由真实问题出发、三个人协作完成、部署到真实环境、被真实贡献者使用，并发生了真实资源兑换的产品。
如果重新开始，我仍然会坚持那个周六下午定下的目标：
先在今天完成一个真实闭环，让用户开始使用，再从真实反馈中决定明天做什么。
对我而言，这也是这个项目最重要的产品经验。
备注
apple系统截图：
