1️⃣ 5.6 初体验

✅ 更像一个开发者。

这次体验就是以一个日常小需求为开端，感受到 5.6 的使用强度。
给自己的 Blog 加一个自建统计功能：
1.统计站点流量。
2.文章阅读次数。

这不是一个复杂的需求，主要感受了一下 5.6 在走闭环的研发工作流 强度如何？

✅ 过程是很完整的，搭配配置的skills，在和它需求讨论后开始，完全自我主导，产出PRD、实现、测试、合并、推送、部署和线上验证。
这个流程很省心，我还特别注意了，5.6 是否会自动设定阶段计划和目标验证，他没有这样操作，是走了一个正常的流程，暂时不确定他在上下文满了后如何处理记忆。

（⭕️ 关于 memory处理问题，我发现codex在本次的更新过后，在项目文件中，每次对话开启时，会主动的触发一次上下文压缩，然后我就比较好奇，压缩后的内容时处理到哪里去了，直到我注意到，他都会去读一个memory.md的文件，我才反应过来可能他是每次对话开始前先去处理 .md 文件然后理解并执行，原理类似于handoff，这点再求证一下。

（⭕️ 这里在后续了解到，GPT-5.6 sol 的工程能力其实不再需要借助这类skills充当脚手架的角色，特别是 superpowers，但因为我在codex个性化配置的原因，仍然让他被迫去走原定工作流，并拆解使用集合中的skill，重复造轮子，导致开发量增多，消耗了大量的 token）
补充： 后续我要求 5.6 Luna和Terra 不要按照预设的配置使用skill，先依靠自身的处理逻辑完成优化，我发现其实消耗的额度也不高才两个优化才占了周额度 5% 。不过也确定了一件事，确实可以卸载superpowers了！

（⭕️ 后来读了一些文章在官方指南
https://developers.openai.com/api/docs/guides/latest-model
里了解到一些prompt规范，GPT-5.6 将更擅长从上下文判断用户的真实目标和任务所需的工作量，同时 OpenAI 也建议是减少不必要的过程控制，同时继续保留背景、硬性限制、权限边界和完成标准。
所以要求的提示词汇更短更清晰，这里我看过一个解析5.6 prompt的文章挺不错后续整理搬运到这里。）

（⭕️ 这里的验证环节我觉得是也是消耗大量token的原因之一，因为我看他起着内置浏览器走站点界面验证😂）

最终成果

---

2️⃣ 让 5.6 以第一人称评价自己的开发复盘

（可能姿势不对 ai味儿还是好重，但是主要是做记录将就看了）

1.一开始，我只是想要一个很小的统计功能

我的需求其实很朴素：Blog 每天流量很低，最多几个访问，不想接第三方统计脚本，也不想为了这点数据引入太重的系统。

一开始我问的是“完全自建的成本如何”，后面又追问“这么低的访问量，引入 Redis 会不会比 MySQL 方便”。

最后定下来的方案是：不引 Redis，直接用 MySQL。

原因也很简单：

• 我的访问量很低，MySQL 完全扛得住；
• 系统里本来就有 MySQL，多引一个 Redis 反而增加部署和维护成本；
• 统计数据不是强实时、高并发场景，用数据库唯一键和日聚合就够了；
• 对个人 Blog 来说，“简单、稳定、可解释”比“架构看起来完整”更重要。

这一点让我对 5.6 的第一印象还不错。它没有为了显得专业而把方案设计复杂，而是能围绕我的真实规模做取舍。

2.这次真正做了什么

最后实现出来的功能，大概包括这些：

• PV 统计：记录公开页面访问量；
• UV 统计：按天统计匿名访客；
• 文章有效阅读：文章页面可见满 8 秒后才算一次阅读；
• 同一个访客、同一篇文章、同一天只计一次有效阅读；
• 后台增加统计看板，能看今日、近 7 天、累计数据、趋势和文章排行；
• 文章详情页展示阅读次数；
• 统计失败不影响页面打开和文章阅读；
• 访客标识用 Cookie 保存，服务端做摘要，不直接存原始标识；
• 去重记录保留 90 天，聚合数据长期保留。

这套功能听起来不复杂，但它牵涉前后端、数据库迁移、后台页面、公开页面、部署环境和线上验证。它不是那种“生成一个文件就结束”的任务。

也正因为这样，这次体验比较真实。

3.实现过程里，真正要想清楚的不是“怎么计数”

一开始我以为统计功能的核心就是“访问一次，加一”。但真正开始做的时候，会发现这个问题没那么简单。

第一个要想清楚的是：什么算一次访问？

首页打开算不算？文章列表算不算？后台页面算不算？浏览器预取算不算？接口被调用算不算？如果只是后端在文章详情接口里顺手加一，那 Nuxt 的服务端渲染、预取、重复请求都有可能把阅读量冲高。

所以最后的设计是：文章详情接口本身保持只读，不因为“读取文章”而增加阅读量。真正的统计由浏览器在客户端上报。这样可以把“内容读取”和“行为统计”分开，逻辑更清楚。

第二个要想清楚的是：什么算一次有效阅读？

如果用户点进文章马上退出，这算不算阅读？从数据上当然可以算一次 PV，但不应该算文章阅读。所以最后用了一个很朴素的标准：文章正文展示后，页面保持可见满 8 秒，再上报一次有效阅读。

这里的关键不是 8 秒这个数字多精确，而是它表达了一个边界：PV 是访问，阅读是更进一步的行为。对个人 Blog 来说，这个区分已经够用了。

第三个要想清楚的是：怎么去重？

我不想做登录态统计，也不想保存用户真实身份。所以方案是前端生成匿名访客 ID，放在一方 Cookie 里；服务端收到后不直接保存原始 ID，而是结合服务端密钥做摘要，再按“访客 + 日期”或者“访客 + 文章 + 日期”去重。

这样能满足几个目标：

• 不需要用户登录；
• 不依赖第三方统计；
• 同一天重复刷新不会把 UV 和文章阅读刷爆；
• 数据库里不保存原始访客标识；
• 后续如果要清理，只清理去重明细，不影响长期聚合数据。

第四个要想清楚的是：数据怎么存。

这里最后没有做一个“事件流水表”，而是用了更轻的方式：保留日聚合表和去重表。PV、UV、文章阅读按天聚合；访客去重记录只保留一段时间；文章本身保留一个累计阅读数字。

这个设计对低流量 Blog 很合适。它不追求分析平台那种任意维度回放，也不保存一堆未来可能用不上的原始事件。它只保留我现在真正会看的东西：今天多少访问、最近趋势如何、哪些文章被读了。

4.具体落地时，前后端各自承担了不同责任

后端主要负责三件事：校验、去重、聚合。

公开接口只接受允许统计的公开路径，不让后台路由、无效路径、未发布文章写入统计。收到事件后，它会识别是普通页面浏览，还是文章有效阅读。页面浏览写入每日 PV，并通过唯一键维护每日 UV；文章有效阅读则同时更新文章每日阅读、文章累计阅读。

这部分我觉得比较好的地方是，它没有把“计数”散落到文章模块里，而是单独放在 analytics 模块里。文章模块仍然负责文章，统计模块负责统计。后面如果要调整规则，比如把有效阅读从 8 秒改成 15 秒，或者增加来源统计，不需要去改文章读取逻辑。

数据库层面，关键点是用唯一键处理“同一天只算一次”。这比在代码里先查再判断更可靠。低流量下性能不是问题，而唯一约束能保证即使重复上报，也不会把 UV 或有效阅读算多。

前端主要负责两件事：选择上报时机，以及尽量不打扰用户。

页面浏览在公开路由切换后上报。文章有效阅读则只在文章详情页处理，而且不是简单 setTimeout(8000) 就完事。更合理的做法是只累计页面可见时间：用户切到别的标签页，时间不应该继续算；组件卸载了，也不能继续上报。

还有一个重要原则是：统计失败不能影响阅读体验。也就是说，请求失败就失败，不应该弹错误、不应该阻塞页面、不应该影响文章正文加载。统计是锦上添花，不是核心链路。

后台看板则是第三块工作。它不是只把接口数据打印出来，而是要让站长一眼能看懂：

• 今天 PV / UV；
• 近 7 天 PV / UV；
• 累计 PV；
• 累计文章阅读；
• 近 30 天趋势；
• 文章阅读排行。

这些指标不复杂，但组合起来刚好能回答我最关心的问题：有没有人来、最近有没有变化、哪篇文章更有人看。

5.这次实现里，我对“够用”的理解更深了一点

这次统计功能如果往大了做，可以做很多东西：来源分析、设备分析、地域分析、实时在线人数、事件漏斗、搜索关键词、访问路径。

但这些对我的 Blog 来说都不是第一阶段要解决的问题。

我真正需要的是一个低成本、可维护、可解释的统计能力。所以这次实现其实一直在克制：

• 不引 Redis；
• 不引第三方脚本；
• 不做复杂事件流；
• 不存原始访客身份；
• 不让统计影响公开页面；
• 不把阅读量绑定到服务端文章查询；
• 不为了未来想象中的需求提前设计一套大系统。

这也是我觉得 5.6 在工程判断上比较有价值的地方。它不是单纯把功能堆满，而是能围绕当前项目规模做一个“刚好够”的版本。

6.我对 5.6 的最大感受：它更像是在跑一个工程流程

以前用模型写代码，我经常会有一种感觉：它能写，但你得盯着它。

它可能很快给你一段看起来不错的代码，但你要自己判断这段代码是不是真的能跑、有没有破坏现有逻辑、有没有漏掉边界条件、有没有跟部署环境冲突。

这次 5.6 给我的感觉不太一样。

它不是只盯着“把代码写出来”，而是会把事情拆成一个更完整的链路：

1. 先把需求变成 PRD；
2. 再把 PRD 拆成可执行计划；
3. 然后按现有项目结构实现；
4. 实现过程中补测试；
5. 前后端分别验证；
6. 合并到 main；
7. 推送远端；
8. 构建镜像；
9. 部署线上；
10. 最后再验证线上接口和容器状态。

这让我开始把它从“写代码工具”改成“工程协作者”来看。

代码只是其中一部分。更重要的是，它能不能把一个需求从想法推进到上线，并且知道哪些地方需要谨慎。

这次我比较明显地感觉到，它不是在一个文件里“猜答案”，而是在跟着项目已有结构走。后端有数据库迁移、Service、Mapper、Controller、测试；前端有 composable、插件、页面、类型定义、构建验证；部署侧有环境变量、镜像 tag、容器健康检查和线上接口验证。

这对我来说很重要。因为真实项目最怕的不是代码写不出来，而是新功能像补丁一样贴在系统外面。能不能顺着现有结构把东西放进去，决定了后面维护会不会痛苦。

7.“慢”这件事，反而让我更清楚它在做什么

中途我问过一句：“怎么会这么慢是在干嘛？”

这是很真实的体验。因为从用户视角看，模型没有一直输出，就会感觉是不是卡住了。

但这次慢的主要原因不是在“想”，而是在做工程里本来就慢的事情：

• 后端测试要跑；
• 前端测试要跑；
• Nuxt 要构建；
• 远程 Docker 镜像要构建；
• 服务器要拉依赖；
• Maven 下载依赖遇到慢源，还需要切到国内镜像；
• 容器升级后要等健康检查；
• 线上接口还要重新验证。

这也是我这次体验里很重要的一个变化：我开始意识到，一个更可靠的模型不一定会显得更快。

如果它只是生成代码，当然很快。但如果它要负责“这东西真的能上线”，那它就必须花时间在验证、构建、部署和回查上。

这跟人做工程其实一样。写代码通常不是最耗时的，真正耗时的是确认它没有把别的东西弄坏。

8.我对新模型使用方式的一点理解

这次之后，我对新模型的使用方式有几个比较明确的感受。

第一，不要只把它当搜索框。

如果只是问“Redis 和 MySQL 哪个好”，它能回答。但更好的问法是把背景说出来：我的 Blog 流量很低、已有 MySQL、希望自建、维护成本要低。

背景越真实，它越容易做出符合场景的判断。

第二，不要只让它写代码，要让它负责结果。

比如这次我不是只说“写一个统计接口”，而是让它从 PRD 开始做，最后合并、推送、部署。这样它的工作边界就不只是“提交一段代码”，而是“把功能交付出来”。

这两种用法差别很大。

第三，要允许它解释取舍。

我觉得这点很关键。比如不用 Redis，不是因为 Redis 不好，而是因为这个场景下 Redis 带来的复杂度大于收益。统计失败不影响阅读，也不是随便写的，而是因为公开页面的稳定性比统计完整性更重要。

一个模型如果只会给答案，其实不够用。它要能讲清楚为什么这么做，什么时候这个选择会失效，后面要扩展该怎么走。

第四，越接近真实项目，越要重视验证。

这次让我更愿意接受“慢一点但验证完整”的协作方式。尤其是涉及线上部署的时候，不能只看本地能不能跑，还要看生产容器、环境变量、数据库迁移、接口返回、页面访问这些东西是否真的正常。

第五，要把“实现细节”也交给模型讨论，而不是只问大方向。

比如“统计文章阅读”这个需求，如果只停留在功能层面，很容易得到一个很粗糙的实现：打开文章就加一。但如果继续追问实现细节，就会自然进入更关键的问题：SSR 会不会误计？刷新怎么算？切后台怎么算？访客 ID 存哪里？服务端存不存原始 ID？去重数据保留多久？统计接口失败怎么办？

这些问题才是真正决定质量的地方。模型能力越强，越应该让它参与这些具体取舍。

9.这次体验里我觉得比较有价值的几个点

最有价值的不是某一段代码，而是整体协作方式。

它能接住一个不完整的想法，然后把它整理成可以执行的方案。比如一开始我只是想要“浏览统计”，但最后它会自然补齐 PV、UV、文章有效阅读、去重、后台看板、数据保留、隐私处理这些细节。

它也能根据项目现实做判断。我的 Blog 流量很小，所以它没有硬上 Redis，也没有引入第三方统计平台。这个选择很朴素，但适合我。

它还会在部署阶段处理一些不那么光鲜的问题。比如远程构建时 Maven 下载慢，它没有停在“网络不稳定”这个结论上，而是把项目本地 Maven 配置改成国内镜像，再重新构建验证。

这些地方不像演示视频里那么漂亮，但是真实开发里很重要。

还有一个细节是，它没有只做“开发环境能跑”。数据库迁移要能在生产库上应用，环境变量要进 compose，前端要能通过线上同源代理访问后端，后台统计页要能在未登录时正常拦截。这些不是功能截图里最显眼的部分，但它们决定了功能是不是真的上线了。

10.当然，它也不是完全不用管

这次体验下来，我不会觉得新模型已经可以完全替代开发者。

它还是需要人来定方向，尤其是产品取舍和边界判断。

比如我要的是一个个人 Blog 的统计功能，而不是商业分析平台。这个边界必须明确。如果边界不明确，它有能力把东西做得越来越完整，但那不一定是我真正需要的。

还有，部署这种事情也不能完全无脑交给它。它可以执行很多步骤，但我仍然需要知道它在动哪些环境、改哪些配置、推到哪个分支、上线后验证了什么。

所以我的感觉是：5.6 很强，但最好把它当成一个执行力很强的工程搭档，而不是一个可以随便放权的黑盒。

11.我的收获

这次最大的收获，是我对 AI 协作开发的理解变得更实际了。

以前我更关注“模型能不能写出代码”。现在我更关注：

• 它能不能理解真实约束；
• 它能不能做出合适的技术取舍；
• 它能不能把需求整理成可执行计划；
• 它能不能写完以后自己验证；
• 它能不能处理部署中那些不顺手的问题；
• 它能不能在慢的时候说清楚自己到底在干嘛。

从这次结果看，5.6 在这些方面确实更接近一个可协作的工程伙伴。

它让我意识到，以后用新模型，不应该只问它“你会不会”，而应该把真实目标交给它，看它能不能一路推进到结果。

这对我自己的工作方式也有影响。

我需要更清楚地表达目标、约束和验收标准。模型越强，越不能只给一个模糊指令然后期待它猜中全部上下文。好的协作不是我什么都不管，而是我把方向和边界讲清楚，然后让它在边界内尽可能推进。

这次给 Blog 加统计功能，最后真正上线了。功能本身不算大，但它让我看到，新模型的价值已经不只是“帮我写点代码”，而是开始参与完整的软件交付。

这可能才是我这次 5.6 初体验里最明显的变化。