如何把一个 AI 小项目包装成案例

先说结论。

一个 AI 小项目能不能变成案例，不取决于功能有多复杂，而取决于你能不能把问题、约束、方案和结果讲清楚。

不要只放截图。截图只能证明你做过，不能证明你理解了项目。

第一段写背景

背景不是客户隐私，而是场景。

可以这样写：

这是一个什么行业、什么团队、什么流程里的问题。原来怎么做，每天大约处理什么材料，最终要交付什么结果。

示例：

“这是一个销售团队的线索跟进场景。销售每天从表单、邮件和微信里收到客户信息，需要整理需求、判断优先级，并写下一步跟进建议。”

第二段写原流程

AI 接入前，流程是什么？

至少写清楚：

• 输入从哪里来；
• 谁处理；
• 怎么判断；
• 输出给谁；
• 哪一步最耗时；
• 哪一步最容易出错。

原流程写不清，AI 方案也不会可信。

第三段写核心问题

不要把所有问题都写进去。

选 1 到 3 个核心问题：

• 信息分散；
• 重复劳动；
• 结果不可追踪；
• 审核成本高；
• 响应速度慢；
• 新人很难上手。

最好用一句话总结：

“这个项目真正要解决的不是自动写跟进话术，而是把分散线索整理成可追踪的销售动作。”

第四段写方案设计

方案不要一上来堆技术栈。

先写流程：

1. 收集输入；
2. 清洗字段；
3. 调用模型摘要；
4. 输出结构化结果；
5. 人工确认；
6. 写回系统。

然后再写技术：

• 用什么模型；
• 数据保存在哪里；
• 日志怎么记录；
• 失败怎么处理；
• 哪些动作需要人工确认。

第五段写取舍

取舍最能体现专业度。

可以写：

• 为什么第一版不做多 Agent；
• 为什么不直接自动发送客户消息；
• 为什么先接一个表单而不是所有系统；
• 为什么只做摘要和分类，不做完整决策；
• 为什么保留人工审核。

案例不是展示“我都能做”，而是展示“我知道先做什么”。

第六段写结果

不要编造精确数据。

如果没有真实数据，可以写可观察变化：

• 原来需要人工整理，现在有结构化草稿；
• 原来问题分散，现在集中到一张表；
• 原来无法复盘，现在能看到每次模型输出；
• 原来不知道哪里失败，现在有失败记录。

如果有数据，再写具体数字。

证据要按强弱分层

案例里最强的证据是可复核的业务记录，例如处理状态、人工修改记录、失败日志和经过授权的前后对比。其次是可重复的演示步骤。界面截图只能排在更后面，因为它无法证明输入边界和异常处理。

没有真实成效数据时，可以明确写“当前只验证了流程可行性”，并列出下一阶段准备观察的指标。不要把原型反馈写成生产结果，也不要用模型自评代替用户验收。

匿名案例也能写得具体

隐藏客户名称不等于删除约束。可以保留行业类型、团队角色、输入材料、审核步骤和系统边界，同时去掉品牌、合同、个人信息和未经授权的业务数字。

例如不要写“某头部公司效率提升 80%”，可以写“一个小型销售团队把官网表单线索整理成结构化草稿，销售确认后才写回 CRM；项目未接入私域聊天记录，也未自动发送邮件”。后者信息更少，却更可信。

给同一个项目写出前后链路

以前：表单进入共享邮箱，销售复制字段到表格，再凭经验写跟进摘要。信息缺失时没有统一标记。

试点：表单先通过 schema 校验，模型只生成摘要和候选标签，结果进入待确认队列。销售可修改、拒绝或补充信息，最终版本和修改原因一起写回。

验收：检查字段完整率、人工改动类型、未处理原因和写回失败，不用“文案看起来不错”作为唯一标准。

这个链路同时展示了 AI 接入位置、人工责任和可观察结果，比技术栈列表更能说明能力。

一个不造数据的合成案例

下面只演示写法，不代表真实客户成绩。背景是一支小型销售团队接收官网表单线索，原流程由销售从共享邮箱复制姓名、公司、需求和备注到表格，再凭经验写跟进摘要。输入缺字段时没有统一状态，谁在处理也无法从邮箱看出。

第一版方案曾经失败：模型直接生成跟进邮件，却没有区分客户原话、销售推断和待确认事项。团队无法判断哪句话可以对外发送，于是每封草稿都要从头核对，自动生成没有减少交接成本。

返工后的方案只做 3 件事：用 schema 检查必填字段，从原文生成带证据位置的结构化摘要，把结果放入待确认队列。团队刻意没有接入私域聊天记录，也没有让系统自动发信，因为数据授权和承诺边界尚未解决。

这个合成案例能写出的结果只有可观察变化：输入缺失会被明确标记，销售可以修改或拒绝草稿，最终版本与修改原因能够一起保留。没有真实运行记录，就不能继续写“效率提升”或“转化率增加”。下一阶段应观察人工修改类型、退回原因、写回失败和处理状态，再决定是否扩大范围。

案例必须写没有做什么

范围外内容至少包括数据来源、自动执行权限、用户数量、语言、文档类型或集成系统。写清这些边界，可以避免读者把一次受控试点误解成通用产品。

当项目失败或结果一般，也可以写案例，但要把文章定位成复盘：原假设是什么，哪个环节没有成立，证据是什么，下次会如何缩小范围。失败案例的价值来自判断，不来自包装。

失败兜底也必须进入案例正文。模型超时后是否保留输入，字段冲突时是否转人工，写回状态不确定时是否先查询再重试，都比“更换了哪个模型”更能说明项目是否可交付。

第七段写复盘清单

最后给读者一份可拿走的清单：

• 这个场景是否高频？
• 输入是否稳定？
• 输出是否能审核？
• 错误是否可接受？
• 是否需要人工确认？
• 是否有日志？
• 是否能从小范围开始？

我的建议

AI 案例文章不要写成功学。

可信案例的结构是：场景、流程、问题、方案、取舍、结果、复盘。只要这七段写清楚，一个小项目也能变成有价值的内容资产。