获课 ♥》bcwit.top/4303

过去一年，我做过三个AI应用：一个智能客服、一个文档摘要工具、一个营销文案生成器。它们有一个共同点——上线热闹一阵子，然后就悄无声息地躺在了产品列表的角落里。我一直以为问题是技术不够强，直到在实战营里被带着做了一次完整的全流程复盘，才发现症结从来不在代码，而在方法论。

这篇文章，是我对这次实战营的复盘总结。我不想罗列课程大纲，而是想和你聊聊那些让我“后脊发凉”的认知刷新，以及如何用这套复盘思维，让下一个AI项目真正实现二次落地——不是做完就扔，而是能持续迭代、迁移到新场景。

一、复盘第一关：需求拆解，我当初到底在做什么？

实战营的第一个模块，就给了我当头一棒。

讲师让我们拿出一张纸，写下自己过往项目的“原始需求”。我写的是：“做一个智能客服，降低人工成本。”讲师接着问：用户是谁？在什么场景下提问？当前的人工客服怎么做的？哪些问题最耗时？用户满意度的标准是什么？

我愣住了——这些问题，我当初一个都没想过。我以为“智能客服”就是接上大模型，让用户随便问。结果上线后，用户问得最多的是“订单怎么还没到”“退货地址是什么”，而我那套依赖通用知识的模型根本答不上来。

实战营里反复强调一句话：AI不是用来解决模糊问题的，而是用来解决被拆解清楚的具体问题的。 真正的需求拆解，不是把一句话翻译成技术语言，而是把业务痛点还原成可执行的任务单元。

我们后来在实战营里练了一个案例：某教育机构想做AI助教。通过三层拆解（用户访谈+场景分析+能力匹配），发现真正的痛点不是“答疑”，而是“作业批改”——老师80%的时间花在重复性批改上。于是项目方向从“对话式助教”调整为“作业智能批改+RAG知识库答疑”。方向一变，技术选型、数据准备、评估指标全变了，也才有了后续落地的可能。

二次落地的前提，是你第一次就做对了需求定位。 否则，复盘出来的全是“为什么当初要选这条路”的悔恨。

二、复盘第二关：技术选型，别让“追新”毁了项目

需求明确了，接下来是技术选型。这一关我踩过的坑更典型：追新、追大、追全。

第一次做AI应用时，我毫不犹豫选了当时最强的GPT-4，觉得“用最好的总没错”。结果项目做到一半，成本报表让我倒吸一口凉气——每天几百美元的API费用，业务方根本接受不了。后来换成国产轻量模型，效果虽然稍差，但成本降到十分之一，业务方反而满意了。

实战营里有个“技术选型三问”，我觉得可以作为每一次决策的标尺：

1. 这个任务真的需要大模型吗？（很多规则就能解决的问题，别用大炮打蚊子）

2. 如果用大模型，需要多强的推理能力？（复杂推理选GPT-4/Claude，简单任务开源模型就够）

3. 成本和延迟的底线在哪？（to B内部工具可以接受3秒，to C前端必须1秒内）

除了模型选型，还有架构选型：用RAG还是微调？用LangChain还是自研？实战营通过几个真实项目复盘，让我们看到不同选择的后续影响。比如有一个法律咨询项目，最初选了微调，结果数据标注成本极高，迭代一次要一周。后来复盘发现，其实用RAG+Prompt优化就能覆盖90%的问题，而且知识更新只需要改数据库，效率提升十倍。

技术选型复盘的核心，不是比较谁更先进，而是看谁更匹配你的场景、资源和迭代节奏。

三、复盘第三关：开发落地，那些文档里没写的“坑”

如果说需求和技术是图纸，那开发落地就是施工。这一环节最不缺的就是“意外”。

实战营用大量时间带我们复盘了开发中的典型问题，我印象最深的有几个：

• 数据问题：一个金融问答项目，用了公开的财报数据，结果模型回答时总把“某公司净利润增长”说成“某公司利润暴涨”，因为训练数据里“增长”和“暴涨”是混着用的。后来加了数据清洗规则，才稳住输出风格。

• Prompt的脆弱性：同一个Prompt，在Playground里跑得好好的，一上线就被用户的奇葩问题击穿。比如你设定了“只回答产品相关问题”，用户偏问“你是什么模型”，模型就开始介绍自己是OpenAI的GPT-4。解决方案不是堵死所有可能，而是设计多层兜底逻辑和异常处理。

• Agent的任务链断裂：一个数据分析助手，需要依次调用数据库查询、代码生成、图表渲染。某次用户问“对比去年和今年的销售趋势”，Agent第一步查询就把“去年”理解成“2022年”，后面全错。复盘发现是Prompt没有约束时间解析的规则，后来加入时间实体识别模块，才稳定下来。

这些坑，课程文档不会写，开源社区也少有讨论。只有在实战中踩过，或者在复盘里被点醒，才能变成自己的经验。

开发落地的复盘，不是总结“我写了多少代码”，而是记录“我解决了哪些意外”，并提炼成可复用的检查清单。

四、复盘第四关：评估与迭代，别让上线成为终点

很多AI项目上线即死亡，不是因为技术不行，而是因为没有建立评估迭代机制。

我之前的做法是：上线后看几天用户反馈，觉得还行，就放着不管了。三个月后，用户需求变了，知识库过时了，模型也更新了几个版本，但我的应用还停在原地。

实战营里讲了一个“AI应用持续优化”的案例：某内容平台的AI摘要工具，上线时摘要准确率90%，半年后掉到70%。复盘发现，用户发布的内容风格变了（从长文章变成短视频脚本），但模型没变。团队后来建立了一套自动化评估流水线：每周抽样本，用BLEU、ROUGE和人工评分对比效果，发现下降就触发重新微调或Prompt优化。

更重要的是，他们把每一次bad case都沉淀下来，形成测试集。每次模型迭代，先跑一遍测试集，确保之前修过的问题不复发。这个过程，就是让应用在真实环境中持续进化。

评估迭代的复盘，不是盯着仪表盘看数字，而是建立“发现问题-定位原因-验证修复-沉淀知识”的闭环。

五、助力二次落地：复盘的价值在于迁移

说了这么多复盘，最后回到标题：如何助力二次落地？

实战营给我最大的启发，不是某一个技术点的突破，而是建立了一套可迁移的AI应用开发框架。这套框架包含：

• 需求拆解模板：拿来任何一个新需求，都可以快速完成“意图-场景-能力”三层拆解，避免方向错误。

• 技术选型决策树：根据成本、延迟、效果、数据量等维度，快速筛选出最优方案，不用每次都从头调研。

• 开发坑点清单：从数据准备、Prompt设计、异常处理到性能优化，上百个踩坑记录，让新项目少走弯路。

• 评估迭代SOP：从指标定义、数据采集、问题定位到版本发布，形成可重复的优化流程。

有了这套框架，当你接到第二个、第三个AI项目时，不再是“从零开始试错”，而是带着复盘经验直接上手。这就是“二次落地”的真正含义——把第一次的教训，变成第二次的起点。

结语：AI时代，复盘能力才是核心竞争力

大模型技术还在飞速迭代，今天好用的工具，明天可能就被取代。但复盘的能力、抽象的方法论、对全流程的掌控感，永远不会过时。

极客时间的这次实战营，与其说是教我怎么开发AI应用，不如说是教我怎么“思考AI应用”——拿到问题怎么拆，遇到坑怎么填，做完项目怎么复。这种思考框架，可以跟着我走很远。