落地为证
方法真的兑现过：一手交付现场、真实数字、付出的代价，以及最后怎么收场。
本系列的话题
篇目
5 篇- 01
从三方冲突到四方对齐：一个运营商项目的判据定义过程
一个真实的运营商项目里，四方诉求互相拉扯：业务要低时延、技术要吞吐、财务要低成本、用户只关心问题有没有被解决。复盘我如何把四方诉求收成一张验收表、如何在没有管理权的情况下推动对齐，以及最后四条判据分别怎么落地。
0次浏览0条评论0个赞
- 02
先修量具，再谈性能：一次 8 卡推理调优复盘，和一套带失败路径的调优状态机
一份"看起来很完整"的性能报告里，TTFT 的每一个分位数都和总延迟一模一样——量具坏了。修好量具之后，第二个破绽暴露出来：Prefill 吞吐比 Decode 还慢，而这是物理上不该发生的。复盘这两次诊断与修复的实测数据，并说明我为什么把调优这件事从"多跑几轮看稳不稳"重写成了一台带失败路径的状态机。
0次浏览0条评论0个赞
- 03
把 Agent 的每次调用砍掉 95%：一次从字节开始的成本审计，与六个被实测否决的方案
一次普通对话花掉 4900 万 token，根因不是模型，而是每次调用都要重发一遍的 25 万 token 固定前缀。我用会话日志里的原始字节把它压到 11,476 token/次（−95.4%），随后发现更大的持续浪费是打断前缀缓存（实测多付约 350 万 token 当量）与闲置的免费算力（利用率 0.1%）。文末列出六个我实测否决的主流方案，以及我拒绝做的三件事。**2026-10-17 补记第 12 节**：折叠之后账单换了形状——按全部固定文本口径实测 29,031 token/请求（11.3k 的声明在 PTC 模式下搬进了系统提示），并补上折叠回本判据 N·B > C 与一条「空转注入」的事故复盘。
0次浏览0条评论0个赞
- 04
评估完 Hy-Memory 2.0，我们决定先修自己的记忆栈
腾讯开源的 Hy-Memory 2.0 提供了完整的记忆分层与写入模型。评估后我们没有换栈：12 条真实查询的体检显示，覆盖率 8/12，向量召回 2/8，全文检索 7/8，瓶颈在检索通道与写入边界。
0次浏览0条评论0个赞
- 05
把发布做成产线：四条包、七条 PR、零合并，和一条被漏看两小时的安全审查
我用一天把四个自研包推成了公开仓库与七条收录 PR，结果是零合并。真正留下来的不是这七个链接，是中间那条产线：它把「合格」写成了能跑的判据，也暴露出一个盲区——监测器只盯 PR 状态、不盯评论，维护者的安全审查意见因此躺了两小时。这篇写产线怎么搭、闸门能证明什么、又在哪一刻彻底失效。
0次浏览0条评论0个赞
继续
换个系列，或回到全部文章。