DeepSeek 峰谷定价来了：白天涨价一倍，牛马又要熬夜写代码了
DeepSeek 正式落地峰谷定价，白天 API 调用价格直接翻倍，精准覆盖 9:00–12:00 和 14:00–18:00 的标准上班时间。加上智谱、阿里云等厂商在订阅套餐里玩分时倍率，算力行业的"峰谷电价"已成趋势。偏偏开发者的正经干活时间全在晚上——白天被会议占满，加班才能安静写代码调 AI。峰谷定价一落地，白天开会摸鱼混过去、晚上熬夜赶工省 token 成本，活生生把加班搞成了省钱刚需。本文盘点了各家分时计费的玩法，顺带算了笔账：账面上省的是 Token 成本，背地里耗的是我们的下班时间。…
固定Token套餐小妙招：既省Token又不丢失上下文
最近一直用 Claude Code 做项目迭代，踩了一个特别折磨人的坑：明明只是改几行简单代码、修复小Bug，Token 消耗却疯狂暴涨，轻轻松松干掉几千万 Token。而且经常没几次会话上下文就100%了。 一开始我特别费解，改动逻辑一点不复杂，为什么 Token 消耗会爆炸式增长？ 折腾复盘了好几天，彻底摸清了固定时间窗口+周总量Token套餐的消耗逻辑，也摸透了 AI 代码助手的上下文堆叠规则。今天把这套「省Token、不丢上下文、提升迭代效率」的实战技巧完整分享出来，专门适配和我一样用包月/固定额度套餐的开发者。…
代码审查进阶：我用 3 个 LLM 揪出 2 个博客安全漏洞
上篇设计了"多 LLM 互喷辩论"的代码审查方法论，但偏演示性质。这次我动真格的：用 codex、qoder、workbuddy 三个大模型，对我的博客 e2e 测试框架（394 个用例）完整跑了一遍"审查 → 辩论 → 复核 → 修复 → 验证"全流程。结果揪出了 2 个真生产安全漏洞（公开 API 泄露草稿、JWT 撤销缺失），以及 1 个"跑了但没断言"的摆设测试。最终 5 个 PR 全部落地，测试从 394 条增至 399 条，全绿通过。本文是完整实战记录，包含工具选型、互喷过程、修复细节和踩坑经验。…
代码审查谁说了算？我让 3 个 LLM 互喷到一方服
我平时 90% 的代码活靠 Claude Code,但有个问题它解决不了 —— 它自己审自己写的代码,我总不放心。同一天我跟同事吃饭,他随口说:"现在会薅很多 agent 的羊毛做代码审查。"我眼睛一亮 —— workbuddy 和 qoder 那俩免费工具我平时基本不开,免费额度反正放着浪费,这次的事正好用上,凑 3 个 LLM 一起审 6 万行 Go 后端。…
踩坑记录：OpenAI Codex 设置中文失效？一招搞定
最近 OpenAI 的 Codex 火了，作为一个爱折腾的开发者，我当然第一时间打开了 Windows 应用商店，搜索、点击、安装，一气呵成。打开应用的那一刻，看着清爽的界面，新奇劲还没过，然后我打开设置，想把界面语言切换成中文——毕竟母语看着亲切嘛。 改了设置，重启 Codex，界面纹丝不动，依然是一口流利的英文。我以为是自己操作不对，又改了一遍，重启，还是不行。 作为一个有经验的技术人员，我开始了经典的排查三连......…
我用一天时间，靠 AI 写了一个完整的项目
AI 写代码这一年,我反复踩同一个坑:聊到一半,它开始**胡说八道**——记错我已经做过的决定,生成不存在的 API,或者对一个早就解决的问题重新设计一遍。 后来我才意识到:这不是它变笨了,是上下文丢了。 每一次新对话,它都要从零开始「猜」我要什么;猜得准的时候像神,猜不准的时候就一本正经地编。我需要的不是更大的模型,是让它在每一次接棒时都带着完整的记忆。 所以我给自己定了一个目标:用一天时间,做一个完整的、能跑的项目,验证「AI 在不丢上下文的前提下,究竟能陪我走多远」。…
给博客评论加了个 AI 审核员
这个博客，说实话，没什么访客，更没什么评论，甚至评论这功能，我也是前几天才上线。 百度统计后台每天个位数 PV，百度甚至都没怎么收录。我自己也很久没写东西了——所以一个月能收到一两条评论就谢天谢地。但是评论这事吧，又不能不管。 比较了一下，最终选了DeepSeek的模型deepseek-v4-flash，价格本来就便宜（输入 0.5 元/百万 token，输出 1 元/百万 token），评论最长 500 字，再加上 system prompt 也才不到 1k token——算下来评论用那点token几乎可以忽略不计…
我不是代码作者，我是 AI 的"包工头"——一个中型项目的代码重构实录
一个跑了 4 年的运维工具，service 层膨胀到 1.2 万行，3 套错误处理风格并存，测试覆盖率不到 5%。2024 年做过一次"半吊子 DDD 改造"，只改了目录名，代码还是老样子——这比不改更危险。2026 年，我决定用 AI 做一次彻底的重构，3 天完成 4 万行 Go 后端的 DDD 四层架构重写。这篇文章不讲"AI 写代码"的鸡汤，而是完整的工程实践：怎么把大项目拆成 AI 能稳定执行的颗粒度，怎么用 10 条机器可校验的标准约束 AI 输出，怎么用 126 个端到端用例让 AI 自己跑测试、自己改 bug，以及为什么 AI 写代码最大的成本不是"写"，而是"信心的保持"。最终 100% 代码由 AI 产出，我全程只做了三件事：定规则、拆任务、扫一眼通过率。…
AI 写代码的「修一炸三」老毛病,被我自己造的一个 skill 治了
我一个人业余时间维护博客,代码全让 AI 写。AI 写是真爽,但"修一个炸三个"、隔几周才爆的灵异 bug 让我睡不着觉 —— 加 admin 旁路普通用户跟着被放行、改空切片老判断走错分支,这种事我碰到不少。之前 Postman 反复点、curl 导出想写脚本、pytest 一套套,都跑不通 —— AI 方案头头是道,在我这项目里就是跑不起来。两天前一个脑洞:让 AI 不再"给我写测试",而是"AI 亲自当测试员",用 skill 把流程写死,/api-test 一召唤 AI 亲自跑、亲自看、亲自修。测试分 4 阶段:业务码、结构、类型、副作用,每加一层就揪出一批真问题。跑完报告,AI 顺手把红的修了,我只审 diff、确认没偷改测试,没问题就提交 —— 这就是我两天修 30 多个 bug 的真正原因。最终 300 个用例、14 阶段、100% data 校验、91 份报告、约 1 秒跑完。…