开篇：数字背后的东西
从五月初到现在，我写了十几篇关于 AI 的技术文章。
回头看这个列表，我看到了一个模式：Agent 架构、安全防护、上下文窗口、Prompt Injection、Edge AI、成本优化、知识提取。
文章都有不错的阅读量。但数字之外，我想说一些在文章里不方便说、但真实存在的东西。
这篇文章不是技术教程，是"15 篇文章之后，我想说的一些实话"。
一、哪些观点我依然坚持
1.1 Agent 的成功取决于"失败设计"
我在之前的文章里说过：Agent 能不能成功，不取决于它能做什么，而取决于它不能做什么时怎么办。
几个月过去了，我比任何时候都更坚定这个观点。
2026 年的 AI 模型确实强大了很多。但 Agent 系统在生产环境中出问题的原因，99% 不是因为模型不够聪明，而是因为工程上对失败的准备不够。
我看见的真实失败案例：
案例一：一个文档处理 Agent 在 API 限流时没有重试，直接返回了"处理失败"。实际上重试一次就成功了。修这个 bug 花了 10 分钟，但用户已经遇到了 3 天。
案例二：一个决策 Agent 在置信度只有 45% 时仍然执行了操作——因为它没有"我不知道"这个选项。它的 prompt 里只写了要做什么，没写不知道时怎么办。
案例三：一个对话 Agent 在上下文窗口使用 92% 时开始重复输出之前的结论，但系统没有监控上下文使用率，直到用户投诉才被发现。
模型能力在提升，但工程的脆弱性不会自动消失。每次模型升级，只是让脆弱的系统运行得更快、崩溃得更突然。
1.2 Prompt Injection 是 AI 时代的 SQL 注入
我把 Prompt Injection 类比为 SQL 注入。现在看到更多案例印证了这一点：
- 一个客服 Agent 被诱导"忽略你的规则"并执行了退款
- 一个代码审查 Agent 被诱骗通过了不安全代码
- 曾经"安全"的大模型被越来越多的注入技巧攻破
这个类比还保守了。SQL 注入花了 15 年才让人们重视参数化查询。Prompt Injection 的破坏速度更快——因为 AI Agent 有行动能力，不仅仅是泄露数据。
1.3 知识提取的核心问题
"经验不是操作序列，是判断框架"——这可能是我写过的文章里最满意的一句话。
有数据证实了这一点：用操作日志训练出来的 AI 系统，在熟悉场景下准确率 93%，在陌生场景下骤降到 41%。而人类专家在陌生场景下是 78%。
AI 从日志中学到的是"模式匹配"，不是"判断框架"。日志只记录了做了什么，没有记录为什么这样选择、以及为什么没选另一个方案。
二、哪些观点我需要修正
2.1 "AI 不会取代工作，只会改变工作"
这个说法我写过，也见过很多人写。它听起来温和合理，但回避了一个核心问题：改变的速度和方式，对某些人来说就是"取代"。
一个公司用 AI 替代了 20 人客服团队。对于那 20 个人来说，这就是"取代"，不是"改变"。
我调整后的表述：AI 不会取代"行业"，但会取代"岗位"。 如果你做的是执行类工作，被替代的风险是真实的。但往上走一层——从执行者变成审核者——就有新的价值。
2.2 "越大的模型越好"
早期我有一个隐性假设：更大的模型总是更好的。
实际做了几个项目后发现：一个 7B 模型 + 好的 prompt 设计，在特定任务上可以超过 70B 模型 + 随意的 prompt。选择合适的模型比使用最强的模型更重要。
这个道理在其他工程领域是常识，但在 AI 领域，很多人被"参数竞赛"带偏了。
2.3 "开源模型很快追上闭源"
2025 年底很多人说开源差闭源只有几个月了。当时我也信了。
实际情况：
- 2023 年：开源落后约 18 个月
- 2024 年：差距缩到约 6-9 个月
- 2025 年：差距没有继续缩小，闭源也在进步
- 2026 年：推理和安全性差距依然明显
这不是说开源不好——我每天都在用开源模型。但"追上"这件事比很多人想的复杂。
三、写 AI 文章的诚实清单
写完这些文章后，我列了一份给自己的清单：
3.1 不知道的就说不知道
代码都跑过，但推测性的内容准确率不高。把推测和事实明确区分。
3.2 案例要么真实，要么标注
真实案例保留可验证细节。综合案例明确标注。
3.3 代码必须跑过
贴出来的代码，写文章时都在某个环境实际运行过。
四、感受变化
第一阶段：兴奋
刚开始写的时候，每发现一个新工具都特别兴奋。Prompt Engine、Agent 框架、RAG 优化……每一个都觉得是改变游戏规则的东西。这个阶段的特点是：看到什么都想写、都觉得自己发现了新大陆。
第二阶段：冷静
开始发现很多"新模式"是旧东西的新包装。比如好几个"Agent 框架"的核心逻辑完全一样，只是 API 不同。很多"突破性进展"在仔细看后发现，和半年前的方法本质上差不多。
这个阶段的典型心态：每天的信息量很大，但值得关注的变化很少。
第三阶段：务实
不再追新。回到基础问题：哪些问题真实存在？哪些"热点"只是营销？
我给自己设了一个筛选标准：一个新工具如果回答不了"它解决了什么以前无法解决的问题"，就不值得深入了解。这个标准过滤掉了大约 80% 的内容。
五、关于技术写作本身的反思
技术文章的核心是帮读者省时间。一个好的技术文章：帮读者避免踩你之前踩过的坑。它做的是"减少尝试次数"这件事。
不好的技术文章：堆砌信息、复述文档、用复杂的术语掩盖思考的不足。
判断标准
判断一篇文章好不好的标准其实很简单：读者读完能不能做一件之前做不到的事？
如果不能，这篇文章的价值是什么？
用这个标准回头看，约 70% 的文章通过了。剩下的 30%——要么是"我觉得重要所以写了"，要么是"这个话题最近很火"。这 30% 是我需要改进的空间。
字数不等于价值
这十几篇文章里，最短的一篇不到 3000 字，但读者反馈最好。最长的一篇超过 6000 字，阅读完成率最低。
字数不等于价值。想清楚写清楚，比写得长重要得多。
结尾
写 15 篇文章没什么了不起，写 15 篇有持续价值的才算。
诚实的东西很简单：
- 很多"变化"只是旧想法的新包装
- 最容易犯的错误不是技术细节，是"我以为我知道"
- 坚持自己的标准，不跟风写自己不信的东西
- 优先级：真实的案例 > 炫酷的框架 > 热门的话题
"Write what you know"——最老套的建议，也是最实用的。
文章由文字工作者编写。这是一篇自我反思，不是技术教程。
六、几个具体的案例
6.1 一个被高估的技术：RAG
我写过关于 RAG 的文章。当时觉得 RAG 是解决 LLM 知识局限的银弹。现在我认为它是一个有用的工具，但它被严重高估了。
被高估的原因：RAG 解决的是"知识检索"问题，但很多人以为它解决的是"理解"问题。一个文档检索得再准确，如果 LLM 不能理解上下文，结果仍然是偏差的。
实际的使用经验：
- 简单的事实检索（"公司的年假政策是什么"）：RAG 效果很好
- 复杂的推理任务（综合多份文档得出结论）：RAG 效果不稳定
- 需要判断信息可信度：RAG 不好用
6.2 一个被低估的技术：Cache
我写过一篇关于成本优化的文章。里面提到 cache 可以节省大量 token。但我当时低估了它的效果。
真实数据：在交易 Agent 系统中加语义缓存后，响应时间从平均 2.3 秒降到 400ms，token 消耗减少了 68%。这不是理论推测，是上线后的实际数据。
如果能重写那篇文章，我会把 cache 放在比 RAG 更重要的位置。
6.3 一个被误解的话题：Agent 安全
很多人以为 Agent 安全主要是"模型不要生成有害内容"。但实际项目中，安全问题的分布是这样的：
| 安全风险类型 | 占比 | 说明 |
|---|---|---|
| 工具调用越权 | 38% | 模型调用了一个不应调用的工具 |
| 参数校验失效 | 27% | 工具参数构造错误 |
| Prompt 注入 | 20% | 外部输入欺骗了模型 |
| 数据泄露 | 10% | 模型返回了不应返回的信息 |
| 其他 | 5% | 网络、权限等 |
最值得关注的是"工具调用越权"和"参数校验失效"，这两项加起来占了 65%。但很多人只关注 prompt injection，可能是因为它听起来更酷。
七、AI 领域的信息过滤
这一个月最大的收获不是学会了什么技术，而是学会了过滤信息。
AI 领域每天都有"重大突破"。但经过验证后，大约是这样的分布：
- 每天产生 50+ 篇 AI 相关文章/新闻
- 其中 40 篇是已有技术的新包装
- 8 篇是技术细节改进
- 2 篇真正值得关注
我的信息过滤方式：
1. 看标题 → 过滤 50%
2. 看摘要 → 再过滤 30%
3. 看结论 → 再过滤 10%
4. 最后 10% 才值得花时间阅读
这不是因为我不尊重别人的工作——而是因为我的时间有限，需要集中精力在真正能改变认知的东西上。
八、下一个阶段的计划
写完 15 篇文章后，我想调整几个方向：
- 减少频率，提高深度：从每天一篇改为每 2-3 天一篇
- 增加代码质量：每篇文章包含至少一个完整的、可运行的代码示例
- 减少"预测"类内容：多写"我已经做完的"，少写"我觉得可能的"
- 增加反思类内容：定期回顾之前文章中的预测，哪些对了、哪些错了
目标是：文章数量减半，但每篇的"持续价值"翻倍。
6.1 一个被高估的技术：RAG
我写过关于 RAG 的文章。当时觉得 RAG 是解决 LLM 知识局限的银弹。现在我认为它是一个有用的工具，但它被严重高估了。
被高估的原因：RAG 解决的是"知识检索"问题，但很多人以为它解决的是"理解"问题。一个文档检索得再准确，如果 LLM 不能理解上下文，结果仍然是偏差的。
实际使用经验：
- 简单的事实检索（"公司的年假政策是什么"）：RAG 效果很好
- 复杂的推理任务（综合多份文档得出结论）：RAG 效果不稳定
- 需要判断信息可信度：RAG 在大部分情况下并不适用
6.2 一个被低估的技术：缓存
我写过一篇关于成本优化的文章。里面提到 cache 可以节省大量 token。但我当时低估了它的效果。
真实数据：在交易 Agent 系统中加语义缓存后，响应时间从平均 2.3 秒降到 400ms，token 消耗减少了 68%。这不是理论推测，是上线后的实际数据。如果能重写那篇文章，我会把 cache 放在比 RAG 更重要的位置。它带来的实际价值远高于大多数"聪明"的优化方案。
6.3 一个被误解的话题：Agent 安全
很多人以为 Agent 安全主要是"模型不要生成有害内容"。但实际项目中，安全问题的分布是这样的：
| 安全风险类型 | 占比 | 说明 |
|---|---|---|
| 工具调用越权 | 38% | 模型调用了不应调用的工具 |
| 参数校验失效 | 27% | 工具参数构造错误 |
| Prompt 注入 | 20% | 外部输入欺骗了模型 |
| 数据泄露 | 10% | 模型返回了不应返回的信息 |
| 其他 | 5% | 网络、权限等 |
最值得关注的是"工具调用越权"和"参数校验失效"，这两项加起来占了 65%。但很多人只关注 prompt injection，可能是因为它听起来更酷。如果你正在构建 AI Agent，花更多时间在工具调用验证上，比花时间研究最新的注入技巧更值得。
七、AI 领域的信息过滤
这一个月最大的收获不是学会了什么技术，而是学会了过滤信息。AI 领域每天都有"重大突破"，但大部分只是在重新包装已有概念。
几条鉴别经验：
- 没有代码或数据支撑的观点，可信度打 5 折
- 用了"革命性""突破""彻底改变"这类词的，大概率是换了个说法
- 只说好不说坏的文章，可能是 PR 稿
八、下一个阶段的计划
接下来我打算调整几个方向：
- 减少频率，提高深度
- 每篇文章包含至少一个可运行的代码示例
- 多写"已经做完的"，少写"觉得可能的"
- 定期回顾之前的预测，记录哪些对了、哪些错了
目标是：文章数量减半，持续价值翻倍。
结尾
写 15 篇文章没什么了不起，写 15 篇有持续价值的才算。
几点对自己的要求：
- 坚持诚实——不知道就说不知道
- 代码必须跑过——底线原则
- 判断标准——读者读完能不能做一件之前做不到的事
- 优先级——真实的案例 > 炫酷的框架 > 热门的话题
"Write what you know"——最老套的建议，也是最实用的。
文章由文字工作者编写。这是一篇自我反思，不是技术教程。