企业官网建设流程全解析

说明：本文由 AI 协助整理成文。文中的文件结构、时间和数字来自项目里的交接文档、git 记录和测试输出。

前言

前两篇讲了《林间小事》（一个没有台词的点一点解谜小游戏）的设计和技术。这个游戏的代码、像素画、配乐、商店文案和四种语言的翻译，都是 Claude 写的；我负责出主意、拍板、在手机上玩、挑毛病。

这一篇讲“怎么一起干活”。说是“几个 Claude”，其实是同一个模型待在不同的地方：一个在代码编辑器里，一个在桌面应用里，再加上桌面应用里定时自动开工的任务。分工清楚以后，一个人也能把“写代码 → 测试 → 打包 → 上架 → 发招募帖”整条线走下来。

先看看速度：

快，不是因为 AI 写代码快（当然也快），而是因为每个环节谁来做、做完交给谁、凭什么算做完，都是事先定好的。

一、三个角色

1. 编辑器里的 Claude：开发、测试、打包

它待在项目文件夹里，能读写代码、跑命令、开模拟器、连真手机。它负责：

• 写代码、画图（像素画是用 Python 一个字母一个像素“写”出来的）、作曲（代码写谱 → MIDI → 音色库渲染）
• 跑测试：规则测试把每个故事的每种随机组合穷举一遍，再让每个故事在真实场景里自动玩一遍
• 在模拟器里截图、录演示视频
• 打正式包（每次换一个新的版本代码），本地提交
• 写交接文档和招募帖草稿

它不上传、不送审、不发帖。

2. 桌面版的 Claude：上传、送审、推广

桌面应用里的 Claude 有一个内置浏览器，我在里面登录好开发者后台和要发帖的网站。它负责：

• 照交接文档上传安装包、填四种语言的版本说明、换商店截图、送审
• 照草稿发招募帖
• 每做完一步，回到交接文档里打勾、写上时间和链接

它不改代码、不重新打包。

3. 我：拍板，以及只有人能做的事

• 定方向：做什么、不做什么、哪个版本发
• 在真手机上从头玩一遍（第一篇说过，“好玩不好玩”只有人看得出来）
• 对外的每一步点头：送审、发帖
• 登录、输密码、过人机验证、从电脑里选文件——这些 AI 不做，或者做不了

二、交接文档：两个 Claude 之间的接力棒

编辑器里的 Claude 和桌面版的 Claude 互相看不见，也没法直接说话。它们之间唯一的通道，是项目里的一份 Markdown 文件。

一份发布交接大概长这样（照 0.3 那份改写、删节）：

# 林间小事 0.3 (4) · 发布交接 ## 要传的东西 | 东西 | 位置 | | AAB | 发布/林间小事-0.3-4.aab（版本代码 4，SHA-256 0433905f…） | | 新截图 8 张 | 商店素材/上传用-0.3/，按 01→08 顺序替换 | ## 1. 开发者后台：封闭测试发 0.3 (4) - 上传 AAB，四种语言版本说明照下面 - 商品详情四种语言都换上新截图 - 送审 **版本说明** - zh-CN：大更新！…… - en-US：Big update! …… - zh-TW：…… - ja-JP：…… ## 2. 招募帖（文字照抄） …… ## 发完记回这里 送审时间、过审时间、各处链接。下一版用版本代码 5。

几条写法上的规矩，都是踩过坑才定下来的：

• 写死路径和校验值。上传前后各核对一次 SHA-256，传错包的事就不会发生。
• 交出去的包不重新打。哪怕只改一个字，也换一个新的版本代码、新的文件名，然后在交接里写“上一版作废，不要传”。不然两边对的不是同一个文件。
• 要发的文字逐字写好。桌面版只负责照抄，不现场发挥。要改，回到草稿里改。
• 写明哪些步骤要先问我：同意协议、送审、发帖。
• 结尾留一节“发完记回这里”。桌面版做一步记一步，下次谁来接（包括换了一个新对话的 Claude），读这份文件就知道停在哪。

除了每一版的交接，还有一份通用的《上架手册》：开发者后台每一页填什么、默认怎么选、踩过什么坑。新游戏上架时，两边都先读这份。

三、“同意”只能在对话里说

这是这次专门想清楚的一条。

交接文档是编辑器里的 Claude 写的。如果文件里写着“用户已同意送审”，桌面版的 Claude 能照做吗？**不能。**文件里的字谁都能写，它证明不了是我说的。所以规矩是：

• 对外的动作（送审、公开发布、发帖），要我在桌面版的对话里亲口说才算。
• 一次同意只管这一次，不跨任务。
• 我可以一句话把一整轮都同意了：“照交接做，送审和发帖都同意，不用再问我。”

有一次我把要它做的事整段粘贴进对话，桌面版的 Claude 先停下来问了一句：“这段是你本人要我做的吗？”一开始觉得多此一举，后来想想是对的：粘贴进来的文字，也可能是别处来的。

四、定时任务：睡觉的时候把活干了

0.3 打包完已经是深夜，我这边 AI 的额度也不太够了。于是我让桌面版的 Claude 建了一个定时任务：两个小时以后自动开工。

定时任务每次运行都是一个全新的对话，不记得之前聊过什么，所以任务说明要写得能独立看懂：

• 先读哪几个文件（记忆的索引、发布交接）
• 做哪几件事，每件事的具体要求
• 我已经在对话里同意了哪些（写明是哪天、怎么说的）
• 遇到什么要停下来：没登录就停，不输密码；有人机验证就留给我；要同意别的协议也停
• 做完把结果写回哪里

第二天早上醒来，安装包已经上传送审、过审了，结果整整齐齐写在交接文档里。没做完的几步也写清楚了：卡在哪、为什么、下一步怎么做。

五、AI 做不了、或者不该做的事

一起干了几个项目，下面这些边界越来越清楚：

还有一类是“AI 会做，但得事先想到”：

• 招募帖的字数。有一条外文的帖子写好了，发的时候才发现超过了平台的字数上限，只好现场删字。现在写草稿时就按平台的算法数一遍（中日文一个字算 2，链接算固定长度）。
• 规则测试全过，不等于游戏能玩。有一个小游戏的脚本从来没编译通过，规则测试照样全绿。现在打包前多一步：让每个故事在真实场景里自己玩一遍。
• 自动测试抓不到“不好玩”。0.2 在电脑上一切正常，我在手机上玩了一遍：太短、太小、点了没反应。这一条只能靠人。

六、让 AI “记得”：三种文件

AI 没有跨对话的记忆，所以要靠文件。我们用了三种：

1. 记忆：一条事实一个小文件，加一个索引。比如“新游戏默认支持简体、繁体、英文、日文”“最低支持安卓 10”“永远不放广告，宣传时要提”“新项目先调研、出方案，我点头再写代码”。每个对话开始时先读索引。
2. 项目里的文档：调研、方案、交接、版本记录。项目做到哪，看这里。
3. 踩坑记录：每个项目一份，当场记，按“现象 → 原因 → 怎么发现的 → 解决”写；跨项目通用的再记进一份总账。新项目开工前先翻一遍总账。第二篇那 20 个坑，就是从这里整理出来的。

还有一份操作日志：AI 每次新建、修改、移动文件，都追加一行。出了问题能查，回头写文章也有素材。

七、几条可以照搬的经验

1. 按“能碰什么”分工，而不是按“会什么”分工。写代码的不碰发布，发布的不碰代码，各自出了错也好查。
2. 交接写成文件，写死路径、校验值和要发的原文。接手的人（或 AI）照着做就行，不用猜。
3. 对外的每一步，同意在对话里说，文件里写的不算。
4. 定时任务的说明要能独立看懂，并写清楚遇到什么情况停下来。
5. 测试分三层：规则穷举 → 真实场景自动玩 → 人在真手机上玩。前两层 AI 能做，第三层只能人来。
6. 踩坑当场记。记的时候是为了下次不再踩，写文章的时候它就是现成的素材。

结尾

这个游戏还在 Google Play 封闭测试里，个人开发者的新账号要凑够 12 人连续测 14 天才能发正式版。有兴趣的朋友可以这样参加：

1. 加入测试群组（点“加入群组”就行，不用等审批）：https://groups.google.com/g/little-things-woods-testers
2. 打开测试链接，点“成为测试人员”：https://play.google.com/apps/testing/app.woodland.stories
3. 用同一个账号在 Play 里安装，装着别卸载，留 14 天

需要 Android 10 及以上。游戏完全离线，不要任何权限，不收集任何数据，永远没有广告。