AI 编程实战

把 AI 用进真实项目，先从一个可验证的小改动开始：写清目标和验收条件，让 agent 读代码、修改、验证，再交给独立模型审查。BluffKing 现在就走这条路径，旧的多角色编排、自动巡检和循环 gate 已经退休。

把任务写成可观察的结果

ChatGPT 对话可以帮你理清需求；在仓库里干活的 OpenAI Codex、Claude Code 还需要范围、权限和完成条件。“修复登录过期后创建房间没有跳转；保留原目标页；不要把网络故障当成退出登录”比“优化登录体验”更容易检查。

目标：修复指定行为。
范围：相关调用方、共享实现与直接验收入口。
验收：正常路径、错误路径与用户实际看到的结果。
交付：改动、检查结果、尚未证明的边界。
授权：本地合并；推送或发布另按任务范围执行。

隔离、验证、审查

每个任务用 scripts/new-session.sh 开独立 worktree 和新的本地端口，连同一个 canonical 数据库；浏览器、数据库等共享资源冲突时按顺序使用（见 worktree 的隔离范围）。MCP、Skill、Plugin 等工具的名字不能证明它已接通、已授权或已执行成功；规则里写着“每天检查”也不等于有定时任务。

改动后运行受影响部分的编译、类型检查或构建，页面变化在普通 Chrome 里看实际界面。唯一的测试套件是 node scripts/e2e/run.mjs：覆盖全部游戏，使用量前三先跑，连续 180 秒内必须 100% 通过，由发布负责人在发布时统一运行，不随每个改动跑。每项持久改动在落地前要由另一家厂商的模型审查（Codex 写的交给 Claude，反之亦然）；对方不可用时改用同厂商的另一个模型并记录原因，这不算跨厂商通过。审查须明确批准且没有未解决问题，之后再用 scripts/finish-session.sh 合并到本地 main，它不会自动推送或发布。

分别证明合并、推送与上线

发布按 docs/ops/RELEASE.md 走本地部署脚本；部署前目标 SHA 必须已在远程 main，游戏运行时发布还要求最新的 human_only_tables=0。上线后读取就绪状态和版本凭据。一条命令成功只证明这条命令成功：本地合并、远程推送、部署和公开可用要分别报告。