【项目实战】住进邮箱的AI助手(上)——AI越用越顺手,直到它开始胡编属性名

最近我的一个朋友开始找我，说自己每天都要处理好多相似需求的邮件，他说AI太好用了也想试试看。

我说那你这些需求大概是什么样的，他转发给我：

业务方运营发来的，正文需求总结下来有两句。

麻烦把 SKU-100234 那批的单价改成 15.8，另外数量和上一批保持一致，也同步调整一下。

这种邮件，他说每周要处理大约 40 封。

每封 10 到 20 分钟。读邮件，把人话翻译成表里的字段，改产品数据表，审批通过了再分发给各同事。

这套流程，之前人肉跑了很多年。

这段时间，我开始用 AI 把它重新捋一遍。做完回头看，有点说法。

最终上线的那套方案里，大模型只守着一小段边界干活，剩下的全是普通代码。

同一个需求，我先后做了六遍。从一段 Prompt，一路做到硬编码。

每一步，都觉得上一步不够用了。每一步，又都没有扔掉上一步。

因为我觉得要说的内容太多，于是准备分成三篇来说。

这里还是着重说明：AI 怎么从一段随手的 Prompt，变成一份能进版本库的资产。

同一份需求的六级演进，本篇覆盖前两级。后面每一级，都长在上一级的地基上。

在讲那段 Prompt 之前，得先回答一个更根本的问题。

这事，到底值不值得用 AI。

01

这事值得用 AI 吗

立项论证，先于一切代码

先说需求真伪，再说 AI。

业务不复杂，五步。

邮箱里筛出需求邮件，把邮件里的人话翻译成固定格式的schema，按表单更新产品表，更新前人工审批，通过后再分发给各部门。

产品表你就理解成一个特别大的 Excel，一列一个属性，一行一个产品。

麻烦的地方只有一处。

邮件里说的是人话，表里存的是字段。

「单价改成 15.8」进表的时候，得变成 SKU_price = 15.8。说「和上一批保持一致」的时候，得先去查上一批是多少。

工作量摆在这。

40封需求邮件 / 周15分钟 / 封，人工处理480小时 / 年，约两个多月工作日

480 小时，差不多两个多月的工作日，全花在读邮件填表格上。

我不是为了用 AI 找了个场景做个给老板画大饼的功能。

这个钉子问题已经存在很久了，AI 只是后来才出现的、更合适的那把锤子。

不是先有锤子再找钉子，是钉子已经疼了很久。

先说说过去市面上关于这套方案的做法：规则匹配

但是基本上也都没有几家做到了集成的大规模应用。

所以——为什么规则做不到。

动手之前，我先翻出一段旧账。

朋友几年前真试过。正则加关键词，写了 60 多条规则，覆盖率不到 30%。每遇到一种新说法就得加一条，加到第 60 条的时候人先崩了，弃疗。

问题出在自然语言本身。同一件事，怎么说都行。

零件A厚度改成 8mm。统一调整为八毫米。厚度和香港地区产品规格一致。

规则能匹配前两种。第三种，得写一条专门的规则。第四种说法出现的时候，再写一条。

改到后来，正则方法就像狗皮膏药一样越打越多。

因为——规则匹配的是字符串，模型理解的是意图。

前者是穷举，永远有覆盖率天花板。后者是泛化，天然覆盖长尾。

这也是我认为这活儿适合 AI 的核心原因。不是 AI 更炫，是它在这个位置上，结构性更合适。

当然，模型必然会漂移。这个我们后续说。

够不够格，三道门作为把控。

一个场景能不能交给机器，我习惯先用三个层面想一遍。

可验证　输出是 JSON，字段对不对，Schema 校验一秒出结果，机器自己就能判

有兜底　审批环节业务里本来就有，AI 翻错了，人工门会拦住，错误不会一路直达产品数据库

收益可算　高频，单调，重复。人干这个会走神，机器不会

三道门全过，这个需求场景才算立住。

AI 只该占一段。

五步流程，挨个看一遍。

五步流程的模糊性地形。只有中间那步是模糊的，前后都是确定性的活儿。

筛邮件，规则引擎的活儿。改表，主键加写库的活儿。审批，本来就该人干。分发，一个定时任务。

只有中间那步，把人话翻译成 Schema，是模糊的。

那 AI 就只该出现在那一步。

LLM 的位置，就是模糊性的位置。

流程里只有一段模糊，AI 就只守那一段。别的环节硬塞 AI，不叫智能化，叫为了AI而AI。

顺手还有个自查办法，拿伪需求的六个特征，挨个对一遍。

六条全过，这事立项。

四条生产不变量。

真正让我下决心的，还有一组约束。我管它们叫四条生产不变量，先立在这。

• 可观测　出事的时候，能定位到是哪一步出的

• 可回滚   改错了，能撤销

• 可审计　谁在什么时候改了什么，查得到

• 人工门　模糊的不猜，要执行的必审

后面这个系列的每一次升级，都是这四条里某一条，被现实打脸的结果。

很好，那么下一个问题就是——邮箱怎么给 AI「顶号」。

顶号意思就是让AI登录邮箱替我收信。

摸底第一天就碰了钉子。我问朋友公司邮箱能不能开 IMAP，能不能发一个应用专用密码。

答复很干脆，不开。理由是安全合规，没得商量。

这事我完全理解。公司邮箱的凭据管着整个域，开个口子给一段脚本用，换成我是管理员，我也不批。

正门关了，但窗户开着。公司邮箱有个谁都有的功能，转发。

于是方案变成了曲线救国。公司邮箱的规则先筛出需求邮件，自动转发到一个专用的个人邮箱，AI 再用 IMAP 从那个邮箱收信。

「顶号」顶的这个号，不是公司邮箱，是专门养的一个小号。

这里还有个反直觉的点。

顶号这件事本身，压根不需要 AI。

转发是邮箱规则的老本行，IMAP 是几十年的老协议，个人邮箱开授权码是现成功能。三条路摆在这。

实际跑起来的链路就这么土。公司邮箱那边，本来就有筛需求邮件的规则，我只在规则的动作里加了一步，转发到专用小号。

简单说一下规则转发的验证结果：通过加上发件人、标题关键字、内容关键词等五六条硬规则，基本可以做到95%+的覆盖。

小号那边，AI 用 IMAP 加授权码连上去，工作时间每 10 分钟轮询一次。

每周 40 封的量，轮询延迟完全无感。

当然要说做的专业，还有IMAP IDLE 长连接，webhook 实时推送，在这个量级都属于过度设计。这个判断后面还会反复出现，先按下不表。

IMAP 走授权码，能随时吊销，不给主密码。邮件拉下来先本地脱敏，处理完小号邮箱就删，正文不在中转站过夜。

技术栈一句话。Python 用 imaplib 或者 imap-tools 连小号，国内主流邮箱开授权码都是现成功能。

等哪天公司邮箱愿意开 API，这条链路可以整体搬回公司域，删掉转发规则就行。方案随时能升级。

摸底归摸底，上篇我并没有把邮箱接上。

这时候的 AI，还没资格碰我的邮箱。

它得先证明，自己能干好整条流水线上最核心的那件事。

翻译。

02

一段 Prompt 的崩塌

57% 的正确率，和一次改一处崩三处

最开始，没人会一上来就搞架构。

我就是把一段 Prompt，甩进了对话框。

你是产品数据录入助手。从用户邮件中提取产品变更需求，输出 JSON。注意，价格单位可能是元、万元、箱、件，需要统一换算。出现「和上一批保持一致」时，参照前文的历史批次。输出字段包括 unit_price、stock_qty、shelf_status、supplier_code……

然后这段东西最后滚到 200 多行，我管它叫祖传 prompt。

改，不敢随便改。删，不知道会崩哪。测试，靠感觉。

跑了三周，我攒了 37 封历史邮件当测试集，认真数了一遍。

数字不太好看。

37 封里，21 封全字段正确，57%。

8% 的时候，它会编出根本不存在的列名。「批发价区间」说得有鼻子有眼，表里压根没这一列。

这还只是准头问题。

真正让我下决心重构的，是另一件事。

stock_qty 这个字段的抽取一直不稳，我决定修它。办法很朴素，往 prompt 里加了两个带答案的示例。

修好了。stock_qty 从 74% 涨到 96%。

然后我把 37 封测试集，整个跑了一遍。

修复 stock_qty 前后，同一个测试集。修好了 22 个点，赔进去 56 个。

unit_price 从 86% 掉到 54%。supplier_code 从 82% 掉到 58%。

我修好了 22 个点，赔进去 56 个。

把 37 封里的失败样本摊开分类，失败集中在三类。

一封邮件混多个需求，模型只抓到第一个，占 40%。单位混乱，元、件、箱混着说，换算出错，占 30%。指代前文，比如「和上一批保持一致」，模型只能猜，占 30%。

前两类是能力问题，加示例、加规则，能救。

第三类不一样。邮件里根本没写「上一批」是多少，信息是缺的，谁来都得猜。

猜，就是不可控。

复盘完，我对这段 prompt 的定性变了。

它是一段行为描述，不是一份接口契约。

没有版本号，没有边界，没有回归测试集。改任何一个字符，都是在给整个概率分布踹一脚，你不知道会晃到谁。

Prompt 是行为描述，不是接口契约。

判断尺在这里第一次派上用场。

可回归性，崩了。

我改完一段 prompt，没法向任何人证明没有改坏。玩具阶段无所谓，生产里这是死刑。

于是有了下一步，把这段面条，拆成资产。

03

把 Prompt 拆成资产

从一段文本，到一份能进版本库的 skill

在这里的 skills，我的理解就一句话。

把一段 prompt，连同它的校验逻辑和测试集，一起塞进版本库。

skill/  prompt.md      指令，从 200 行瘦到 60 行  schema.json    字段契约，列名封闭枚举（有限集）  validate.py     校验脚本  cases/           37 封测试邮件，回归用

动作上有三个关键变化。

• 指令瘦身。200 行砍到 60 行，只留稳定的任务定义，示例挪进专门的文件。

• 列名封闭。schema.json 里，合法列名写成枚举。模型再想编「批发价区间」，校验这一关直接拦下，轮不到它进表。

• 回归测试。改任何东西，37 个用例先跑一遍。「改一处崩三处」那种事故，从上线后才发现，变成提交前就报红。

效果立竿见影。

右边这张图得说仔细点，它其实是这个系列里最重要的一个认知。

灰色的柱子是模型编造的幻觉字段数。skill 时代，13 个，一个没少。模型根本没变乖。

变的是紫色的柱子，漏进结果集的幻觉，从 13 个变成 0。列名封闭枚举之后，它编的每一个假列名，都会在校验那一关被拍死。

所以 92% 不是模型变聪明了换来的，是把「会出错的环节」和「结果出口」之间，加了一道门。后面每一级升级，本质上都是在加不同的门。

剩下 8% 的缺口，主要是第三类失败，信息缺失。模型该猜还是得猜。

这部分我后来单独建了澄清队列，模糊需求转人工，不猜。怎么建的，之后讲。

聊完效果，回头看一眼机制。skill 和 prompt 的本质区别在哪。

模型那边，其实什么都没变。它看到的依然是一段文本，该怎么算还怎么算。

变的是工程这边。prompt 是每次现拼的一段话，skill 是一个有名字、有版本、有测试的模块。从手工抄件，变成按引用加载。

所以严格说，skill 并没有跳出 context engineering 的范围。

本质还是同一个游戏，只是打法从凭手感，变成了按契约。

代价也要说清楚。

最明显的一条，迭代变重了。prompt 时代随手加一句话就能试效果，skill 时代改一个词要过版本、跑回归。试错的手感没了。

另一条，上下文更满了。skill 连同 schema 和示例一起进窗口，单次开销比一句裸 prompt 大。省心是有账单的。

还有一条得认清。信息缺失类的失败，skill 救不了。「和上一批保持一致」，上一批的数根本不在上下文里，包装得再好也变不出来。

这些损失我都认。换回来的是可回归，数字有测试背书，改动有回归兜底。对要上生产的系统，这买卖划算。

新麻烦也有两个。

一次 schema 加了新列，忘了同步 skill 里的枚举文件，跑了半下午脏数据。版本管理做得再好，「忘了同步」这种事还是会发生。

但真正的短板不在准头。

skill 只能读，不能做。

它没法自己打开邮箱，没法把正文贴进对话框，更没法自己去改表。

每周 40 封邮件，还是人肉搬进对话框。

我拿着 92% 正确率的 skill，干着复制粘贴的活儿。

任务已经从纯认知，变成了认知加行动。而 skill 这个形态，天生没有手。

· END ·

到这里，AI 在这条流水线上的身份，是一个更聪明的表单填写器。

它听得懂人话了，也立了规矩。

但它还在笼子里。

下一件事顺理成章，给它一双手。

在我的邮箱中上号，让它自己收邮件，自己翻译，自己产出修改提案。

我确实这么干了。

之后会讲，这一步我踩的坑，比前两级加起来还多。包括某个周一早上，它在没人盯着的时候，自己改错了三行数据。

你的项目里，有没有哪段「祖传 prompt」也是不敢碰的雷区。欢迎交流你的项目想法。