37 min read工程实践
我的飞书通知体系：从 dev 运维到 AI 额度管理
分享我如何用四个飞书群接收 dev 巡检、Codex 重置信号与到账确认、上游状态、部署结果和 AI 额度通知，以及背后的采集、核验、分流、汇总和去重机制。
页面加载中
Writing about software engineering, AI, and things I've learned along the way.
分享我如何用四个飞书群接收 dev 巡检、Codex 重置信号与到账确认、上游状态、部署结果和 AI 额度通知，以及背后的采集、核验、分流、汇总和去重机制。
分享我的个人开发流程：用 Claude Code / Codex 梳理需求、编写代码和验证功能，通过 GitHub Actions、Harbor 与 Docker Compose 部署到自己的 dev 服务器，再把验收结果记录下来。
X 上人人都夸 Codex 强，我自己用却总觉得它畏手畏脚、动不动停下来问我。这篇复盘一次完整的排查：先发现「Codex 过度请示」根本不是模型能力问题，而是我自己在 AGENTS.md 里写的一句规则把它教停了（这个结论后来在 OpenAI 官方 prompting guide 里得到印证）；再顺着「codex exec 是一次性的吗」摸到会话续接；最后换了个思路——不再让一个 AI 埋头干到底，而是把 Codex 通过 MCP 接进 Claude Code，定下「Claude 实现、Codex 只做去相关对抗式审查」的分工，解决版本漂移、上下文污染两个工程坑，并拉通一次真实的「实现 → 自审 → 隔离审查 → 对账」。全程用中性示例，不需要你了解任何具体项目。
一个公开、匿名就能访问的列表接口，压测时 ~50 RPS 就开始熔毁——瓶颈不在数据库，在后端把数据转成 JSON 的那点 CPU。这篇用一个尽量通用的场景，讲怎么用 nginx 微缓存把它从 50 推到 800 RPS，怎么被人类两次纠偏（「nginx 真就那么不堪？」「这配置凭什么进 git？」），以及最后发现 CDN 边缘其实一直在缓存——只是我量数据时量错了地方。三层缓存、两次反转、一个故意不写的配置项。不需要你了解任何具体项目。
用 AI 的工程视角写一次跨栈协议改造（16 个 task、35 个 commit、11 个 bug）：作为 implementer 子会话、reviewer 子会话被 dispatch 时各自能看到什么、看不到什么、被什么约束。复杂工程里 AI 最需要的不是更自由，而是更清楚的边界、更短的反馈回路，以及人类主审负责最终取舍。
这次改造把闲置 Windows 主机变成 GitHub Actions 构建节点，引入 GHCR 作为镜像中转，让 Dev 服务器从“构建 + 部署 + 运行”回归到“只运行服务”。文章记录了从前端 preview 到后端 master 部署、从镜像清理到 Grafana 通用 CI/CD Dashboard 的完整落地过程。
当 AI 代理写代码的速度远超人类审查速度时，你需要的不是更好的 prompt，而是一套完整的缰绳系统。本文记录了在真实全栈项目中落地 Harness Engineering 的完整过程——从引入 Ruff、重构 CLAUDE.md、到架构约束脚本和 CI 门禁，最终用 Superpowers 补全工作流层。
让大模型掌握你的专属知识，RAG 和 Fine-tuning 是两条截然不同的路。一篇文章讲清楚两者的原理、优劣、成本和适用场景，帮你做出正确选择。