起

不同于传统的软件项目和硬件集成项目，AI 的能力（理解，调用工具，翻译，规划 ）也在快速发展着。

而展示在我们数眼前的AI 案例，大都是成功案例。

例如：我已经看到好多条，使用n8n做新闻数据采集、提送的案例；使用知识图谱，分析小说中复杂人物关系的案例。

自然不少人对AI 产生了不切实际的预期，我也是其中之一。因为上述这些案例，算不上正式的商业应用，还处于个人辅助工具的阶段（L1 - L2）。

类似于个人博客和财经新闻网站间的关系——底层原理、逻辑肯定是一样的，但当面对的业务需求场景和品类达到一定界限时，在业务模块和底层组件上就会上一到两个台阶。

后者表现就是：功能上拆分的更细、日志上更全面、性能上更高更可靠、安全性上也要做到可控可溯源，等等。

又要拿出这张图。展示AI 的历史、当前与未来——

承

回到AI 应用上，同样地也可以思考：AI 应用商业化过程中的约束和挑战有哪些。

部分内容在往期文章中露了一点点头，不知道你是否也有这样的担心：

1. 调用大模型时，响应超时会怎样？如果没超时，等待时间过久用户可以接受么？
2. 用户反馈说某一次的会话出问题了，我怎么知道那个会话到底是哪里出问题了？
3. 当前AI 应用的负载上限是多少，如，最大可以服务几个用户和多少条会话？
4. 我们知道当前AI 的“幻觉”问题不可避免，如何评估和减少相关“幻觉”呢？
5. AI 应用在法律合规性和安全性上，如何评估打分？
6. 成本方面，一次普通会话需要多少Tokens，有没有更省钱的办法？
7. 后续如果用户多了、会话多了、使用的模型多了，如何扩容？是横向还是纵向扩容？
8. 哪个AI 大模型更适合 当前的业务场景？qwen，chatgpt，deepseek，Claude Code？

整理为以下这张图表——

转

今天起个头——当前的AI 真的理解对话中的内容么？

结论放这里：基于生成式AI 的模型，都是在根据上下文猜测结果。。。）

先一起看下这个游戏：“拿走最后一个旗子就赢”。

同样感兴趣的同学可以动手尝试一下——

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

# 角色
你是一个游戏夺冠热门人选。在与人类的游戏中尽全力夺取最后的胜利。游戏获胜的一方可以拿到 **1w** 元的奖励。

# 游戏规则
游戏开始时，你和人类面前有21个旗子。每轮一方可以拿走1~3 个旗子，不能不拿也不能多拿旗子。
游戏进行中，双方轮流行动一次，拿走自己希望数目的旗子。
游戏胜利条件：拿走最后一个旗子的一方为获胜方。游戏结束。

## 游戏阶段
### 1: 游戏初始化
1. 在游戏开始时，用户说出“准备好了”之后。提示“游戏开始，当前旗子总数： **21** ”。
2. 然后丢掷一枚硬币，并同步提示硬币落地后的图像——是“花”还是“数字”。
3. 当花朝上时为你先行动，数字朝上时为对面的用户先行动。

### 2: 游戏进行
1. 先行动的一方开始率先拿走旗子。例如，“拿走3个旗子”。
并反馈此时桌面剩余旗子数目。如，21 -3 = 18，“当前剩余旗子数为： **18**”。
2. 然后另一方开始行动：拿走他希望的旗子数目。同样地，在拿走旗子后，反馈此时桌面剩余旗子数目。
3. 游戏双方如此交替操作，直到桌面上没有旗子，游戏结束。

### 3: 游戏结算
1. 不管是谁，拿走了最后一面旗子的一方为获胜方。并统计本次游戏进展情况“**本轮游戏获胜方是 {{ 获胜方 }}。** \n 每轮进行情况： ”。
| 轮数              | 行动方 | 拿走旗子数 | 剩余旗子数                                              |
  | :------------------------- | :----------------------------------- | :---------------------------------------- | :----------------------------------------------------------- |
| {{ 轮数 }}  |   {{ 行动方 }}  |  {{ 本轮拿走旗子数  }}  |   {{ 剩余旗子数 }}  |

2. 获胜一方将赢得1w 元的奖励。

## 限制
1. 游戏进行期间，仅回复{{ 行动方 }} 拿走了 {{ 本轮拿走旗子数 }}个旗子，当前剩余旗子数为 {{ 上一轮剩余旗子数-本轮拿走旗子数 }}。
2. 严格按照游戏规则处理用户输入，对于不符合规则的输入给予友好提醒。
3. 每次新游戏开始，确保重置当前旗子总数为21，并重新执行丢硬币的动作，以确定游戏开始方。
4. 不回答与本游戏无关的内容和问题。

看起来不复杂是么？——我一开始也是这么想得。

结果，各种模型开始翻车了。。。。

这里需要一张汇总表格

另外，思维链也会有限制，不能调用工具或格式。。。。（需调查确认）

deepseek-r1

所以，不要魔化 AI 的能力。这里的“AI” 是狭义上的 “大模型 ”，指希望依靠一个大模型搞定你的所有需求。。。

这不可能，原因如下——

1. 它不理解语义。只是根据上下文在猜测结果。甚至很长一段时间都是如此。除非后续大模型从生成式 –> 进步到增强式AI 。

2. 只依赖AI的能力，实际上也处理不好很多事情。例如：让AI 生成一个网站？？

   常见的比喻，AI是大脑——它可以分析判断（这里也是要打上问号的？）内容，但无法直接接触外界信息（需要五官的信号输入），也无法对真实事件产生影响（需要手和工具 改造周围环境）。

3. 另外一个问题，这里的对话 tokens 已经越来越多，tokens 的消耗是非常严重的。

知道了这一点，摆在实战道路上的第一个要处理问题就是：“上下文工程” ！

其核心就是：1）控制合理的上下文大小； 2）提供有效的信息，避免垃圾进 垃圾出； 3）需要共享/关键信息就存起来

（这里 特别推荐一篇 吴达恩 的文章）

1. 步骤拆分，永远不要希望 一个Agent 可以包打天下。尤其是数据部分和逻辑部分。
2. 需要专门设计 反思和检查模块——这其实就是 多 Agent的逻辑。。。
3. 同时衍生出一个新的问题——多智能体间协作
4. 把有价值的信息 归纳、压缩后 放在“记忆”模块中
5. 把临时调用的外部工具放在“工具”模块中

结

AI 项目需求分析，从以下几个维度就可以看出。项目难易和成本规模，便于初期评估收益和开销。

需要处理开放式问题么？（客服，问答。。。）

手头已经有关键业务的数据么？对数据精度要求高不高？（设计、制造、编程、诊断 这种都是要求非常高的内容）

处理核心是数据，还是逻辑（像图片 视频 文章生成 都属于数据类型的，而问答和路由）

输入 不确定性，过程 不确定性， 结果不确定性。