我的 AI 项目验收标准只有一个：有人真的在用

现在到处都在讲 Agent，我也做了一个。做完之后我最想聊的不是 LangGraph 怎么编排节点，而是一个更靠前的问题 —— 这玩意儿到底该不该做。

背景：一个不太性感的需求场景

我做的是「校园电话卡 AI 提效系统」。背景是我带着一支 120 多人的校园团队做中国电信的校园业务，覆盖共青城 6 所高校，团队累计服务过 3000+ 用户。

技术上它是 LangChain + LangGraph + FastAPI + DeepSeek。这些都不重要。重要的是它要解决什么。

我没有一上来写代码，而是先去访谈了一圈一线销售和刚进来的新人。访谈做完，痛点收敛得很清楚，就两条：

1. 内容产能不足 —— 大家知道要发小红书、要发朋友圈、要做短视频，但一个人一周憋不出三条合格的内容。
2. 话术不统一 —— 老手有一套自己的打法，新人完全没有。同一个客户异议，五个人能给出五种答案，其中三种是错的。

注意这两条都不是「我们想要 AI」这种需求，而是具体的、正在发生摩擦的、能量化到每天两小时的问题。

我是怎么判断「该不该做」的

踩过几次坑之后，我给自己定了三个问题，按顺序问：

1. 痛点是不是真的？

区分真实需求和伪需求，唯一的办法是去问真正在干活的人，而且要问具体场景，不要问「你需要 AI 吗」—— 所有人都会说需要。

我问的是：「你上一次丢单是因为什么？」 「新人进来第一周，哪一步最容易卡住？」

答案里反复出现的东西，才是真痛点。

2. AI 能不能解决？值不值得 AI 解决？

内容产能不足、话术不统一，本质上都是「模式固定 + 需要大量重复生产」——这是 LLM 擅长的事。如果是「需要实时精确计算」「数据必须是零误差」，那轮不到 AI。

另外还要算一笔账：这个问题如果不用 AI，用一份文档 + 一次培训能不能解决八成？如果可以，那先写文档，别上 Agent。

3. 谁来验证效果？

这一条最重要。我做这个项目的验收标准从一开始就定死了：团队真的在用。

不是「准确率 95%」，不是「召回率达到 XX」，而是周一早上大家打开工具，发现它产出的东西能直接用。

落地长什么样

三类 Agent，用 LangGraph 编排：

• 内容生成 Agent —— 输入一个场景（开学季、宿舍宽带、毕业生离校），产出可直接发的文案
• 话术推荐 Agent —— 客户抛出异议时，实时给出应答口径
• 知识问答 Agent —— 基于沉淀的 SOP 和资费规则的问答

然后用 FastAPI 封装成服务，接进团队日常的作业流程里。

设计上我坚持的一点：AI 的产出必须是「可用」而不是「可参考」。 如果输出的东西还要人花十分钟改，那这个 Agent 等于没做。所以我花了大量时间在 Prompt 的结构化约束上，而不是在模型选型上。

做这个项目最大的收获

不是学会了 LangGraph，是想清楚了一件事：

AI 弱化的是人与人之间基础技能的差距，但它放大了「能不能把事情做完整」的差距。

很多人担心 AI 会取代自己。我的观察是反过来的 —— AI 把「写代码」「写文案」这些单点技能的门槛拉平了，于是竞争就转移到了上游：你能不能发现问题、定义问题、把方案跑通、让别人真的用起来。

这四件事，AI 一件都替你做不了。

一个反面教材

简历上有个项目叫 AI-match，是乡村振兴专家智能匹配系统 —— 专家端、村集体端、管理端三端，规则算法 + AI 语义匹配双路机制，测试通过率 100%。技术上是完整的。

但它最大的问题是：没有真实用户在用。

它很好地教会了我一件事：一个技术上 100 分但没人用的项目，和一个技术上 70 分但每天被用 50 次的项目，后者才有说服力。

写在最后

如果你也想用 AI 解决某个具体问题，我的建议是别急着打开编辑器。先花三天时间，找到那个每天消耗你和团队两小时的具体摩擦点，然后问自己上面那三个问题。

答不上来的话，说明还没到时候。

---

技术细节（LangGraph 的节点编排、Prompt 结构化约束的写法、如何做 Multi-Agent 分工）我会陆续写。想先看哪块，评论区告诉我。