今天，我继续完善自己的个人网站 Ethan Cloud，也叫“Ethan 智控”。
网站已经能访问了，但真正开始发布文章后，我发现：把网站部署上线，只完成了建站的一部分。接下来更实际的问题是——我以后怎么写、怎么改、怎么把内容放上去？
这一天，我和 AI 助手围绕这些问题反复讨论、操作、测试，也遇到了报错和判断失误。网站就在这些来回中，从一个可以访问的页面，慢慢变成了一个我能自己使用的写作空间。
网站上线以后，我首先需要的是方便
最初，我关注的是网站有没有部署成功、域名能不能打开、页面显示是否正常。
等这些基本问题解决后，我很快有了新的要求：
“我以后要怎么编辑后台，增加内容，要方便的方法。”
我不希望每发布一篇文章，都要重新学习文件放在哪里、标题怎么填、如何上传，以及提交之后还要点什么。
对开发者来说，这些步骤可能很熟悉。但作为网站的使用者，我更在意的是：能不能把精力放在文章本身，而不是每次都处理一遍发布手续。
于是，我们开始完善内容草稿助手。
它的作用是把文章整理成网站能够识别的 Markdown 文件，并协助提交到 GitHub。文章仍然保存在代码仓库里，修改有记录，也可以回看历史版本。
第一篇文章，让我看到了实际使用中的问题
我先尝试发布了一篇记录自己如何建设个人网站的文章。
从上传文件、创建 Pull Request，到合并修改，我跟着页面一步一步操作。这个过程让我理解了网站内容是怎样进入仓库，再经过构建部署显示出来的。
但我也发现，流程虽然能走通，操作仍然有些繁琐。
于是，我又提出了一个更直接的想法：
“我能一键发布到 Git 吗？在助手里自动提交，包括自动填写一些内容，我要一项一项填写太麻烦。”
这句话也让后续完善的方向变得清楚：让助手多处理一些重复工作，让我少填写一些可以从文章中提取的信息。
例如，从第一行提取标题，从正文首段建议摘要，自动补上日期和文件名，再由我核对。
这些自动填写的内容是建议，不能替我判断文章中的事实。尤其涉及实验结果、软件功能或资源许可时，仍然需要自己确认。
为了自动提交，我们接上了独立发布服务
为了让草稿助手能够连接 GitHub、提交文章，我们配置了一个独立的 Cloudflare Worker，并创建、安装了对应的 GitHub App。
这部分并没有一次成功。
我遇到了 GitHub 授权页面返回 404，也遇到了授权后返回报错。后来页面给出了更明确的提示：
“GitHub 拒绝客户端凭证，请核对 Client ID 与 Client Secret 是否属于同一个 App。”
配置过程中，我还分不清“客户端密钥”和“密钥对”应该选哪一个。
这些名称看起来相近，实际用途却不同。对第一次操作的人来说，仅仅说一句“把密钥配置好”，远远不够。需要明确指出在哪个页面、选哪个项目、填写到什么位置。
经过排查和调整，助手终于显示：
“已连接 GitHub：paowsun。”
随后，我提交了一篇简短的测试草稿，仓库中成功出现了对应的 Pull Request。
到这一步，自动提交的流程才算有了实际验证。
这里也有一个需要记住的区别：提交到 GitHub，不等于文章已经公开。 当前助手会创建新分支和 Pull Request，后续还需要检查、合并及部署；文章如果保留草稿状态，也不会出现在网站上。
功能通了，界面也要让我愿意用
测试成功后，我又发现了另一个问题：
“内容草稿界面有点难看。”
这并不是一个无关紧要的问题。写作工具是以后要反复打开的地方，如果标题过大、提示框占满屏幕、按钮样式不统一，即使功能齐全，也会让人觉得费劲。
我们接着调整了界面：
- 电脑端左侧写作，右侧核对与提交；
- 手机端按上下顺序排列；
- 缩小标题和提示文字，统一输入框与按钮；
- 把较长的操作说明放进折叠区域。
这次调整没有改变文章的存储方式和提交流程，主要是让操作顺序更清楚。
我希望打开助手时，首先看到的是可以开始写作的地方，而不是一大页需要先读完的说明。
一个短网址，也值得认真做好
新版助手部署后，它的地址很长，是一串带有 workers.dev 的网址。
我觉得记不住，于是提出：
“草稿助手的网址太长了，记不住，像 https://ethancloud.cn/write/ 这个好记。”
这个需求很小，却关系到以后是否方便使用。
第一次调整后，AI 助手根据部署成功的结果，告诉我短入口已经可以使用。但我打开后，看到的仍然是旧版草稿页面。
于是，我把两个页面的截图发了回去：
“不对。”
这一次，截图提供了比“部署成功”更直接的证据：新版助手存在，但短入口没有把我带过去。
随后，我们补上了页面跳转和手动入口，并增加了浏览器测试。再次部署后，我实际打开确认，才回复：
“可以打开。”
这件事让我印象很深。构建成功、部署成功和用户实际使用成功，是不同层面的结果。前面的检查很必要，但最后仍然要回到真实的访问和操作。
我和 AI 的分工，也在今天变得更清楚
今天的合作，并不是我一次说清所有要求，AI 就把整个网站完成了。
更多时候，是我先使用，再表达感受：
“太麻烦。”
“有点难看。”
“网址太长。”
“不对。”
这些话不算技术规格，却是真实的使用反馈。
AI 助手负责把反馈转成具体修改：调整界面、补充跳转、检查代码、运行测试、整理说明。我则负责表达需求、操作账号配置，以及确认最终结果是否符合自己的预期。
这个过程让我感受到，和 AI 一起做网站，需要持续沟通，也需要自己参与判断。尤其是涉及账号授权、文章事实和实际使用效果时，不能只看一句“已经完成”。
留下说明，才能在以后继续使用
我还反复提出了一个要求：
“保留记录 Markdown，一定要给我说明文件，要不我不会。”
我希望网站的建设过程能够留下来。过一段时间再回来，我仍然知道怎样新增文章、修改内容、检查发布结果，以及遇到问题时应该从哪里开始看。
所以，操作手册和连续记录也是今天建设的一部分。
一个工具只有在我离开对话后仍然会用，才真正帮到了我。
接下来，把注意力逐渐放回内容
今天，我们完成了一些具体的事情：测试文章提交、排查 GitHub 登录、改善写作界面，并让一个好记的入口能够打开新版助手。
以后，我可以从这里开始：
网站还会继续完善。但接下来，我更想把时间逐渐放回内容：记录技术实践、阅读中的思考，以及自己的想法如何一步步发生变化。
这篇文章，就是今天的一次记录。
我希望以后回看它时，能记得 Ethan Cloud 是怎样在一次次提问、尝试、报错和确认中，慢慢变成自己能够持续使用的网站的。