我如何用 Codex 完成 Boker：开发过程与协作复盘
记录使用 Codex 开发 Boker 的协作方式、测试验证、线上排障和站长验收。
这篇不是“让 AI 一句话生成博客”的故事。Boker 从前台原型走到能实际发布文章，跨过了需求收敛、数据库建模、编辑器交互、权限测试、版本发布和服务器排障。Codex 在其中承担代码定位、方案整理、实现、验证和审查协作；站长决定需求边界，并在真实浏览器中做最终验收。
以下记录依据是仓库提交、docs/ 下的设计与进度文件、测试结果，以及 2026 年 9 月 18 日的实际部署反馈。没有保存的模型调用次数、Token 用量和耗时，不在这里猜测。
先让任务有可恢复的上下文
项目最早是 2026 年 5 月的 Vite + React 前台原型。9 月转向个人技术博客 CMS 时，先写了功能与架构设计：公开页面、单管理员后台、Markdown 正文、PostgreSQL、媒体权限和暂不实现的功能。随后把任务拆到实现计划，按数据库、页面、编辑器、测试和部署逐步推进。
开发曾在集成验证阶段中断。恢复时，Codex 根据 Git 提交、设计文档、进度记录和隔离工作树确认“哪个目录才是最新实现”，再继续修复，而没有把旧工作区覆盖到主项目。这个经验很实际：长任务不能只依赖聊天上下文，提交、进度文件和可重复验证命令才是下一次接续的依据。
| 阶段 | Codex 协作内容 | 可核对的记录 |
|---|---|---|
| 9 月 14—15 日，CMS | 整理方案、实现前后台与数据库模型、恢复中断的集成验证 | CMS 设计文档、581b0f6、CMS 收尾验证记录 |
| 9 月 15—16 日，写作体验 | 针对 slug、字段错误、冲突提示补测试并迭代 | 84eb252 至 60653d0、文章发布校验修复记录 |
| 9 月 16—18 日，部署入口 | 编写版本包与安装方案，在工作树实现并验证发布烟雾测试 | 部署设计和进度文档、03e2bce 至 9be0d47 |
| 9 月 18 日，线上排障 | 复现静态资源与来源问题，审查 HTTP 入口边界，构建并验证 | 137faa4、75d8483、站长浏览器验收 |
让每次修改都对应可验证的问题
文章发布一度因为空 slug、重复 slug 和字段错误回显不完整而难用。处理时先把问题变成测试：空别名怎样生成，重复别名应返回什么，失败后正文是否仍在。然后修改生成规则、API 错误结构和编辑器反馈，再跑单元、数据库集成与端到端测试。
部署阶段也是同样的顺序。通过 IP 打开后没有样式，先检查 CSS 请求是否 404，再定位到 standalone 目录缺少 .next/static。后台保存与插图返回“请求来源无效”，先用请求头复现，再发现旧校验把 Origin 固定与 SITE_URL 比较。站长补充“两种 IP 地址都会使用”之后，方案才确定为按实际代理入口校验同源，并对生产 HTTP 入口设显式白名单。
一轮独立代码审查还发现：若只按请求协议决定 Cookie 的 Secure 属性，公开域名的 HTTP 入口也可能获得非 Secure 会话。于是补上 ADMIN_HTTP_ORIGINS 限制，再跑测试和临时生产服务检查。审查的价值不是给代码盖章，而是找出最初修复方案没有覆盖的边界。
我们实际使用的工作方式
- 定位。 先查看
AGENTS.md、Git 状态和已有文档；仓库有 CodeGraph 索引时，用它追踪函数与调用链，再读具体配置。 - 隔离。 较大的修复在 Git worktree 中进行，避免覆盖主目录原有的本地设置和临时文件。
- 验证。 对关键规则先跑失败用例，再实现修复；按影响面执行类型检查、单元测试、数据库集成、端到端测试和生产构建。
- 复审与提交。 检查 diff 和审查意见，只提交本任务的文件，合并后再检查主目录状态。未跟踪或他人已有的本地文件不应被顺手清理。
- 真实验收。 自动测试能证明很多路径，但不能替站长确认浏览器中的实际登录、上传、发布、编辑和删除体验。
部署验证中还遇到一个工具层面的干扰：系统 HTTP 代理改写了本机 curl 请求，最初的返回码与代码预期相反。改为直连临时服务后，才得到可信的结果。这提醒我，排障时也要验证测试工具的路径，不能把第一次状态码直接当作应用行为。
Codex 做不到的部分同样要写清楚
Codex 可以读取代码、运行测试、准备构建和检查不带凭据的 HTTP 请求；它不能凭空替站长验证真实账号，也不能在没有 sudo 密码的会话里完成需要管理员授权的服务操作。本轮最终以服务状态和站长的浏览器反馈闭环：两个 IP 的页面及样式可访问，登录、退出、图片上传、发布、编辑和删除都可以完成。
我会继续把“需求、证据、变更、验证、遗留限制”一起留在仓库，而不是只留一段聊天结论。对这种会持续迭代的个人项目，这比一次性生成很多代码更有用。
下次给 Codex 任务时，我会这样描述
目标：修复通过内网 IP 和 Tailnet IP 访问后台时的保存与上传。两种入口都要支持。请先复现，说明根因；在隔离工作树修改，保留已有本地改动；提交前运行相关测试与生产构建。上线后分别检查页面资源、匿名接口状态，并由我用真实账号完成浏览器验收。
这类说明同时给出目标、环境、约束和验收标准。它能减少“代码看起来改好了，实际入口却没走通”的往返。