上周我们探讨了Workflow的重要性，随后有许多读者私下联系，希望我能深入剖析Workflow、RAG与Agent之间的关联。这个问题起初让我有些为难，一方面觉得这三者之间的关系似乎不言而喻，另一方面又觉得它们之间并没有绝对的、排他性的联系。

然而，经过一番思考，我意识到这恰恰反映了一个普遍的AI认知现状：我们这些频繁接触AI项目的人视作常识的概念，对大多数人而言却相当陌生，这种信息鸿沟远比想象中要大。 就像我每天分享AI文章，我的家人可能选择忽略甚至感到厌烦。因此，我们认为理所当然的知识，对他人来说可能真的需要清晰的解释。

三大支柱概述

广义而言，Workflow（工作流）、RAG（检索增强生成）和Agent（智能体）可以被视为AI项目落地的三大技术支柱。它们分别对应着不同的业务场景需求：

1. Workflow：适用于流程明确、步骤固定的场景，如HR效率提升（自动筛选简历、录入身份信息）。
2. RAG：适用于需要基于特定、最新或私有知识库进行问答的场景，如智能客服。
3. Agent：适用于目标复杂、步骤不确定、需要自主规划和调度的场景，如根据指令自动搜索网络信息并生成PPT或博客文章。

由此可见，它们本质上是三种不同的技术路径或架构模式，并且并非互斥。一个RAG系统中很可能包含多个Workflow；一个复杂的Agent则很可能同时整合了Workflow的流程控制和RAG的知识检索能力。

如果用更抽象的概念来对应，它们依次关联着算法、数据与泛化能力。通俗的解释是：

1. Workflow 解决“如何做”的问题，它将任务分解为可控的、顺序执行的步骤。
2. RAG 解决“用什么数据做”的问题，它为模型提供完成任务所需的外部知识。
3. Agent 解决“如何灵活应对”的问题，它赋予系统一定的自主能力，能够自行组合合适的Workflow并调用所需的数据。

下面我们将对这三大支柱进行详细展开。

Workflow → SOP：流程化的基石

Workflow，或称工作流，核心是解决“如何一步步完成特定任务”的问题。许多人认为“工作流”一词过于简单，难以体现业务的复杂性，因此在实际交流中更倾向于使用“SOP（标准作业程序）”这个概念，后者在管理者听来也更具专业性。

SOP对应着我们常说的行业Know-How（技术诀窍）。它定义了为达成优质结果所应遵循的标准化流程，是一套可被设计和编码的策略，将人的经验与操作转化为机器可执行的语言，即算法实现或业务系统化。

Workflow的核心是“梳理”，其背后涉及大量的沟通、设计和流程优化等管理工作，这本身极具挑战。如果聚焦于“Workflow + 大语言模型”的具体应用，最常见的有两种形式：

一、关键词提取（实体/槽位填充）

一个经典案例是：“请问北京明天的天气情况如何？” 工作流程序会执行两个核心操作：关键信息提取与流程执行。 具体来说，就是先提取出“明天”（时间）和“北京”（地点）这两个关键实体，然后调用相应的天气查询接口。这是早期利用模型能力最普遍的方式，也是提升AI产品稳定性的关键，专业上称为“实体提取”或“槽位填充”，我个人更倾向于“关键词提取”这个说法。

二、意图识别

同样以“请问北京明天的天气情况如何？”为例，为什么程序调用的是天气接口，而不是机票查询接口？这背后依赖的是LLM的自然语言理解能力，即意图识别。 这正是Agent进行工具（Function Calling/Tool Calling）调用的准确性基石。何时调用天气接口、何时调用旅游规划接口，这些都需要提前被清晰地定义和设计。如果模型识别不准，我们可以通过微调或优化提示词等方式进行针对性处理。这也引出了一个关键点：

我们常讨论的模型可观测性，很大程度上就体现在意图识别这个环节。

为什么说“仅有Workflow还不够”？

既然Workflow模式如此稳定，而当前大模型最被诟病的就是其不稳定性，按理说企业应该非常青睐Workflow才对。事实确实如此：目前运行在生产环境中的AI应用，超过80%都基于Workflow构建。 真正对Workflow模式“不满”的主要是两类人：

1. 专注于Agent方向、需要融资或售卖课程的人。
2. 一线的研发与工程人员。

为什么研发人员会不喜欢？答案是：维护成本太高，这是一个极其复杂的工程问题。 下图展示了一个维护三年后的Workflow可能呈现的复杂状态：

Workflow的挑战不在于技术实现难度，而在于维护难度。它需要持续应对：

1. 不断新增的用户意图。
2. 频繁变更的业务策略（需求）。
3. 用户千奇百怪、难以穷尽的表达方式。

本质上是有限的、预设的Workflow需要去覆盖和处理无限的用户意图与表达。 最终结果往往是维护成本呈指数级增长，到达某个临界点后，任何修改都可能引发新的错误。

至此，相信大家对Workflow的概念及其优缺点有了比较清晰的认识。接下来我们探讨RAG。

RAG：知识的桥梁

模型本身的知识受限于训练语料，无法满足信息快速更新、领域高度专业或数据严格保密的需求。为了获取更新、更专业、更私密的知识，RAG技术应运而生。

RAG常用的数据源包括本地结构化知识库和网络信息，同时也支持PDF、Word、Excel、图片等多种格式。

RAG的难点表面上在于“如何精准检索出用户所需的知识”，但真正的挑战在于其背后的一系列工程问题：如何进行数据结构设计、如何有效清洗数据、如何处理和优化用户提问等。

到这里，大家应该能看出：RAG系统必然离不开Workflow。 因为数据清洗、存储、用户问题重写、检索结果排序等每一个环节，都是一个具体的小Workflow。

尽管RAG的整体框架看起来简单，但实现一个可用的系统却非常困难。很多开发者可以快速掌握Workflow，但一旦要求构建一个简单的AI客服（RAG应用），就会感到无从下手。以下简述一个RAG项目的基本策略（不涉及具体代码），一次完整的RAG流程是：

用户提问 → 检索操作 → 返回结果

许多开发者在此遇到的最大问题是：检索返回了大量不相关的“垃圾信息”，导致整个流程失败；即使返回了相关内容，若噪音信息过多，也难以算作成功。

确保检索成功的核心有两点：

1. 用户输入（查询）的优化：用户的原始提问是不可控的，因此，用于检索的关键词必须经过重写和优化。
2. 数据源的质量保证：在输入（优化后的查询词）无误的前提下，必须能检索到正确答案，这就要求在数据处理的源头下功夫。

这两点分别对应着查询改写和高质量的数据入库处理：

承接上一篇文章的讨论，我简要回顾了去年在AI+管理领域的创业尝试，并得出了一个个人结论：面向企业（2B）的服务可能并不适合我这种偏重产品研发、与销售端距离较远的人。之后，许多朋友表现出浓厚兴趣，希望我能深入分享更多细节。

具体来说，一旦展开细节，整件事就显得有些微妙甚至令人费解。我首先提出一个反直觉的观点：一套声称能提升1000%效率的AI解决方案，在目标企业里很可能根本无法实施落地…

以下通过实际案例来具体阐述这一现象。

案例解析：身家亿万的‘传统’企业家为何拒绝AI提效？

去年十一月，经过多次引荐，一位老板邀我前去**“洽谈合作”。以往这类会议通常在办公室对着PPT进行，但这次地点选在了一家茶楼**，仅从场所选择就能看出此次会面的非同寻常。

果不其然，一位气场强大、精神矍铄的老板，声如洪钟，招呼服务员上茶后便递烟。由于我们不吸烟，他便自顾自地一支接一支抽了起来…

初步交流得知，他早年似乎从事中小型水电站业务，近年转向自来水厂运营。他深切感受到公司效率低下，希望借助AI技术实现降本增效。

随后，我进行了详尽的自我介绍，提到曾投入数千万研发国内首款AI医生，并列举了其他项目。期间，我敏锐地察觉到随老板前来的某位总监，嘴角泛起了一丝难以察觉的笑意…

细细想来，这场景确实有些突兀：颇有几分在街头小店夸夸其谈，声称刚与特朗普达成数亿生意的荒诞感…

经过后续几轮深入接触，我发现即便不引入任何AI工具，只需优化现有的人效管理，该公司就能实现500%的效率提升；若再结合AI，理论上完全可能达到1000%的提效空间…

根本原因在于，员工的工作量严重不饱和，大多数人每日有效工作时间不足两小时。午后在厂区里，最常见的“集体活动”竟是打麻将和斗地主…

在调研中，我提出了多项数字化改进策略，却几乎都被那位总监逐一驳回。例如：他们坚持采用手动签到、手写报告，再驱车前往各个厂区实地收取；又如，他们一定要亲自前往某厂进行安全巡查，随后要么回宿舍休息，要么继续麻将娱乐…

坦白说，我有些羡慕他们。他们真心感激时代进步，如今有了抖音和各种小说，除了打麻将，又多了许多消磨漫长工时的娱乐方式。从他们身上，我看到了人类面临的两大根本挑战：

第一是解决温饱，第二是填饱之后所有无所事事的时光！

最终，与这家传统企业的合作自然无疾而终。他们需要的并非简单的AI赋能，而是一场翻天覆地的系统性变革，我自认尚无此能力。

类似情况并非孤例。我的一位好友曾从事货运行业，他们开发了一项能便捷检测货车是否超载的技术，却遭到了货车司机群体的坚决抵制。具体原因虽不明确，但那个本可极大提升效率的技术项目，最终也只能搁浅。

由此可见，优秀技术产品的落地应用，始终需要妥善应对复杂的人性因素。

两个世界：AI拥趸的狂热与90%人群的冷漠抵制

过去一年，我仿佛目睹了两个平行世界。不到10%的群体不断惊叹于AI的迅猛发展，并热衷分享各种效率提升案例，例如：

1. 某电话销售团队，客服人员裁减50%后业务运转如常；
2. 利用工具十分钟内生成上百篇图文并茂的热门文章；
3. …

当这一小部分人陷入AI带来的效率焦虑时，其余超过90%的大众却似乎无动于衷。以我身边的妻子为例，她依然每日沉浸于各类网络小说和轻松综艺节目…

然而，当AI真正触及他们的实际工作时，潜意识的反应往往是**“排斥”**。

去年担任某公司AI顾问期间，我发现其人力资源部门的工作方式极为原始：需要将PDF简历逐一录入内部Excel表格，同时还需把入职员工的身份证等信息手动输入另一份Excel员工花名册。

这项工作在繁忙时段甚至需要投入整整两名员工的全天时间！于是，我们花费一天搭建了一套自动化工作流，核心不过是简单的OCR识别结合AI信息提取。这立即使他们的效率大幅提升，HR人员欣喜致谢，感慨这解决了大难题。

然而两个月后，我发现他们依然在手动执行上述操作。询问原因，答复是AI工作流不好用、存在BUG，但进一步追问具体BUG时，却又语焉不详。最终私下了解到的真实答案是：近期工作量不饱和，他们认为手动处理这些工作更好，至少能让自己显得“忙碌”一些…

类似案例屡见不鲜。另一家电话销售公司，每日需处理超过4000条销售线索，为此专门设立了一个由3人组成的线索分配策略组。该小组每日加班至深夜，仍常出现线索分配不及或错误分配，导致下游客服团队空转的情况。

于是，这次我们花费约一周时间，深入理解其工作模式，并为其开发了一套AI线索自动分配工具。这无疑再次解决了他们的核心痛点，甚至使得以往需要3人完成的工作，现在连1个人力都显富余！

但一段时间后，当我回访询问优化建议时，发现他们根本没有使用该系统，仍是原班人马加班加点手动处理。理由很简单：你的AI工具BUG太多！而且他们彻底不愿再尝试任何新工具了…

总结反思：AI创业的教训与未来方向

技术的演进遵循直线逻辑，追求绝对的最优解；而组织的运作则遵循曲线逻辑，强调平衡与稳定。

这意味着：理论上的最优策略，在现实世界中未必行得通。这一点在我过往的管理策略实践中已有深刻体现。

作为一名技术背景出身的AI创业者，我曾坚信“效率即正义”，手握自以为能改变世界的“AI利器”。但现实却告诉我，这记重拳往往打在了一团名为“人性惯性”与“组织惰性”的棉花上，无处着力。

这段经历曾让我陷入长时间的消极情绪，因为它实实在在地冲击了我原本“坚固”的认知：AI技术落地的主要障碍，往往并非技术瓶颈，而是深层的管理问题与人性博弈。

我所设想的“1000%提效”，在现实中常常遭遇组织对“平衡与稳定”的内在需求。

孤立的管理体系本身价值有限，也难以简单复制移植。你无法将一套自认为高效的系统，强行植入一个安于现状的生态。员工抵制AI工具，并非因为BUG太多，而是因为这套系统威胁到了他们既有的、舒适的生存状态与工作节奏。

因此，AI创业的重要教训在于：必须先深刻理解即将踏入的“人性战场”，而非仅仅高举技术利剑盲目冲锋。

综上所述，一个核心结论是：面向企业的AI服务（AI 2B）确实艰难，需谨慎进入。关键在于建立筛选逻辑，选择那些自身具备强烈变革意愿的公司，尤其是一把手的决心必须坚定。切勿试图强行介入，否则很难取得良好结果。

近期有学员在寻找AI相关职位时，反馈面试中常涉及模型微调的相关问题。由于此前学习过程中未能深入掌握，他们希望补上这一课。事实上，对于模型微调这一技术，我内心颇为抵触，因为它曾给我带来不少痛苦的回忆。

时间回溯到两年前，当时国内技术圈仍聚焦于模型的预训练与微调，这一过程被戏称为“炼丹”。不知是幸运还是不幸，我们团队在那个阶段也进行了大量训练实践。彼时，可供企业选择的基座模型相当有限，例如Bloom、LLaMA、GLM乃至GPT2。计算成本方面，更是比当前高出十倍不止——GPT-4-32K的账号一票难求（最高曾被炒至八万元），有些团队因未做好控制，一夜之间便可能让十多万元付诸东流。

数据成本同样高昂。获取优质数据的途径较为单一，且根本不存在所谓“数据蒸馏”的概念，因为实际操作中难以获得相应账号，即便获得，Token费用也令人望而却步。直至2024年，随着微软云Azure账号的开放购买，这一状况才逐渐缓解。但问题也随之浮现：许多受限于技术积累与资金实力的公司，耗费大量资源训练的小型模型（以7B、13B规模为主），刚刚取得些许进展，便因GPT版本更新或LLaMA2的发布而前功尽弃。

更具体地说，这些团队训练的小模型效果很快被资源雄厚的大型模型持平甚至超越，而团队已无力承担再次训练的成本。另一方面，多数公司在模型研发侧的能力几乎为零，即便训练效果尚可，其应用场景也极为有限，往往仅能处理诸如关键词提取等简单任务。原因很简单：约九成的公司无法扩展模型上下文长度，国内具备此能力者寥寥无几。

最终结果是，许多实力不足、积累浅薄的公司，在初步尝试后便迅速放弃了这条技术路线，甚至产生一种被AI浪潮裹挟的无力感。在这场“炼丹狂欢”中，不同公司承受的试错成本虽有差异，但数百万级别的投入损失并不罕见。我清晰记得，在一次项目复盘会上，老板质问为何当初选择这条技术路径，并强调试错成本之高。那一刻，我低头缩肩，整整两小时无法抬头，被当面严厉批评，事后一个月都未能完全恢复。

此时可能有读者会问：既然风险如此明显，为何当时仍有众多公司选择自主训练？这或许是时代的局限性使然。当时国内技术圈普遍以“套壳”为耻，直到Cursor等工具出现，大家发现套壳方案也能如此强大，风气才逐渐转变。于是，核心问题浮现：在当前基座模型能力已如此强大的背景下，何时才真正需要用到微调？

为什么需要微调

首先，我们明确两个不应使用微调的典型场景：

不应微调的场景

第一，风格、语气与品牌的个性化定制。以往因上下文窗口有限、模型理解能力较弱且易遗忘，我们需要通过微调从底层注入风格，以求一劳永逸。但如今，这一场景已基本消失。

第二，复杂结构化输出与特定格式遵循。例如将客户需求自动转化为公司内部JSON格式的工单。此类微调同样源于模型能力不足，担心不微调会导致错误，但现在已无此必要。

接下来，我们探讨几个适合使用微调的场景：

适合微调的场景

第一，在特定领域提升“直觉”与“确定性”。尽管RAG（检索增强生成）能够提供知识，但微调可以增强模型在特定领域内的思维模式。例如，一个代码模型在使用某公司全部内部代码库微调后，会对该公司特有的编程规范、私有库函数乃至常见Bug模式产生更深理解。它不仅能够引用知识（通过RAG），更能以符合公司习惯的方式思考并建议代码。在此场景下，RAG类似于资料查询，而微调则倾向于内置标准操作程序（SOP），将模型转化为领域专家。我们近期在芯片编程领域的实践便采用了微调方式，部分原因在于需要学习的内容体量过大。

第二，成本与延迟优化。对于高频调用的大型应用，每次调用云API都成本高昂且延迟显著。此时，对小型模型进行微调便显得尤为必要。但需特别注意，我们微调小型模型的目标绝非让其扮演“缩小版GPT”来处理开放领域或创造性对话。这类微调的真正价值在于处理特定任务——那些定义明确、边界清晰、且对速度与成本极度敏感的任务。例如：

1. 输入输出标准化：输入为短文本（如用户查询、一句话、搜索词），输出为结构化数据（如分类标签、布尔值、JSON对象）。
2. 高频率、低延迟要求：每秒需处理成千上万次请求，且对响应速度要求极高的场景。
3. 领域特定：任务高度依赖企业自身的业务逻辑与数据。

总结而言：如果仅为补充知识或最新事实，应优先选择RAG，因为微调不擅长注入知识；如果旨在影响模型的输出能力（包括文本规则、格式与速度），则可以考虑微调。

提升模型的直觉与确定性

此处的逻辑在于：RAG补充知识，微调补充思维，目标是将“资料检索型回答”转变为“按行业SOP思考并稳定输出”。在行动前，需首先思考以下几点：

一、何时需要微调？

需注意以下几个关键点：

1. 能将规则或SOP明确梳理出来，且行业中存在清晰标准。避免使用开放命题进行微调，否则难以取得预期效果。
2. 在当前大模型能力基础上，无论如何调整提示词，准确率始终无法突破95%。
3. 存在必须严格遵守的边界或不可触碰的红线。
4. 其他相关考量。

明确准入条件后，核心便转向数据准备。

二、数据来源

此场景下的数据通常具有高结构化特征，例如：

1. 整理出的金标准：如SOP、公司规范、合规条款等，数量约1k至5k条，每条都应作为“判断或建议的锚点”。
2. 负面案例：常见错误及反例，同样需要1k至5k条，明确阐述错误原因及修正方法。

需特别强调的是：微调数据不仅应包含问答对（Q, A），还需涵盖推理过程（Q, Reasoning, A）。以芯片编程为例，数据不应仅是“需求 -> 代码”，而应是“需求 -> 分析（为何此处需使用此私有库函数？需考虑哪些时序与功耗问题？）-> 代码”。如此微调出的模型，在面对新问题时，会更倾向于模仿这种推理路径，而非仅仅输出答案。其“确定性”便体现在推理过程符合预设规则。

由于芯片场景较为晦涩，下面提供一个更简单的示例：

三、数据案例

首先是正面案例：

Q：“你好，我刚才下班回家，把车停在小区路边了。吃完晚饭下来发现副驾驶的车窗被砸了，车里放的一个笔记本电脑包不见了。电脑是公司财产，估计值一万多块钱。我现在该怎么办？”  
  
Reasoning：  
事件定性: 用户描述的核心是“车窗被砸”和“财产丢失”，这是一个典型的“机动车盗抢”案件，而不是普通的“车损”。应优先归类到“盗抢险”。  
责任初判: 车辆处于停放状态，且被盗物品为车内财产。根据条款，盗抢险通常涵盖车内财产损失，但需确认用户是否投保了“机动车盗抢险”及“车内财产附加险”。初步判断保险公司有责任，但需核实保单。  
信息提取: 需要提取的关键结构化信息包括：事发地点：小区路边、受损部位：副驾车窗、损失物品：笔记本电脑、损失金额预估：10000元、案件类型：盗抢。  
下一步动作: 指导用户立即报警（盗抢案件必须要有警方证明）并保护现场。  
  
A：  
{  
"案件类型": "盗抢险",  
"保险责任初步判断": "可能赔付，需核实保单",  
"关键信息": {  
    "事发时间": "晚间",  
    "事发地点": "小区路边",  
    "车辆损伤": "副驾车窗被砸",  
    "财产损失": "笔记本电脑包",  
    "损失金额预估": "10000元"  
  },  
"下一步建议": [  
    "请立即拨打110报警，并获取案件回执或证明。",  
    "请对现场和车辆受损部位进行拍照留存。",  
    "请通过App上传保单信息，核实具体险种。"  
  ]  
}

数据准备完毕后，便可选择相应工具进行微调。此场景因一般公司使用较少，此处不展开案例，读者可自行体会。接下来是第二个微调场景：

近期，一些寻找AI领域工作的学员反馈，在面试中常被问及模型微调相关的问题。由于之前学习时未深入掌握，他们希望能对此进行补充学习。

坦白说，我个人对模型微调这个话题怀有复杂的感情，因为它承载了一段并不愉快的记忆。

时间回到大约两年前，当时国内技术圈仍在热衷于模型预训练与微调，这一过程常被戏称为“炼丹”。不知是幸运还是不幸，在那个阶段，我们的团队也投入了大量精力进行模型训练。

彼时，可供企业选择的基座模型寥寥无几，主流选项包括 Bloom、LLaMA、GLM 甚至 GPT-2。

计算资源的成本更是高昂，相较现在可能贵出十倍不止。当时，获取GPT-4-32K API账号异常困难（黑市价格一度高达八万元），有些团队在夜间进行数据训练时，若未做好成本控制，一不小心就可能让十几万元的投入付诸东流。

数据成本同样惊人。获取高质量训练数据的渠道非常单一，也远未有现今“数据蒸馏”这类高效方法。部分原因是技术限制，另一部分则是根本难以获取足量的API调用权限，即便获得，其Token费用也令人望而却步。这种情况直到2024年，随着微软Azure云服务账号的开放购买才逐渐好转。

然而，问题也随之凸显。许多受限于技术和资金实力的公司，耗费巨资和决心训练出的中小规模模型（以7B、13B参数为主），往往刚取得一点进展，就遭遇了GPT系列版本更新或LLaMA 2等更强基座模型发布的降维打击，导致前期努力几乎前功尽弃。

耗费心血训练出的小模型，其效果很快被财大气粗的巨头发布的大模型所持平甚至超越，而团队已无力承担新一轮的训练成本。

另一方面，绝大多数公司在模型研发方面的能力几乎为零。即便训练出的模型在特定任务上表现尚可，其应用场景也极为有限，通常只能处理类似关键词提取的简单任务。核心原因在于，当时超过90%的国内团队都难以有效扩展模型的上下文处理长度，具备此项能力的人才凤毛麟角。

最终的结局是，许多技术积累不足、资金不雄厚的公司，在初步尝试后便迅速放弃了自研模型的技术路线，甚至产生了一种被AI浪潮裹挟、不得不跟风却又力不从心的挫败感。在这场全民“炼丹”的狂欢中，不同公司承担的试错成本虽各有差异，但数百万元的损失估计是普遍存在的。

我至今清晰记得，在一次项目复盘会上，老板质问我当初为何选择这条技术路径，是否清楚试错成本有多高。当时我羞愧难当，垂着头缩在座位上，硬是无法抬头面对，被持续批评了两个多小时，事后足足一个月都没能从那种压抑中恢复过来。

或许有读者会问：既然风险如此之高，为何当时仍有众多公司前仆后继地投身自研训练呢？

这或许是时代背景下的局限性使然。当时国内的业界风气普遍视“套壳”应用为耻，强调底层技术的自主性。我记得这种风气的转变，大约始于Cursor这类优秀AI编程工具的出现，大家忽然发现，基于强大基座模型进行应用开发（即所谓“套壳”）也能创造出极具价值的产品，观念才逐步开放。

因此，一个核心问题便浮现出来：在当前基座模型能力如此强大的背景下，究竟在什么场景下，我们仍然需要考虑对模型进行微调？

为何需要微调

首先，我们需要明确两个通常不需要进行模型微调的典型场景：

无需微调的场景

第一，风格、语气与品牌的个性化定制。在过去，模型的上下文窗口有限，理解能力较弱，容易遗忘指令，因此我们希望将特定的风格“注入”模型底层，以求一劳永逸，微调便成为首选。如今，随着大模型指令遵循能力的飞跃，仅凭精心设计的系统提示词（Prompt）就足以达成目标，这一场景下的微调需求已大幅减少。

第二，复杂结构化输出与特定格式遵循。例如，将客户的自然语言需求自动转化为公司内部标准的JSON格式工单。以往进行此类微调，也是出于对模型原始能力的不信任。现在，通过Few-shot Prompting（少样本提示）等技术，大模型通常能出色地完成这类任务，微调的必要性随之降低。

接下来，我们探讨几个仍然值得考虑进行模型微调的适用场景：

建议微调的场景

第一，在特定专业领域内提升模型的“直觉”与输出“确定性”。

虽然检索增强生成（RAG）技术可以有效地为模型补充领域知识，但微调能够从更深层次塑造模型在该领域内的思维模式。

例如，一个代码生成模型在使用某公司全部内部代码库进行微调后，不仅能调用这些代码（RAG的功能），更能深刻理解该公司特有的编程规范、私有库函数的使用惯例、甚至常见的缺陷模式。它会倾向于以更符合该公司工程师习惯的方式去思考和建议代码。

在此场景下，RAG扮演了“资料库”的角色，而微调则旨在将行业的“标准操作流程”（SOP）内化到模型中，使其蜕变为真正的领域专家。我们团队之前进行的芯片编程辅助模型项目就采用了微调方案，部分原因正是需要让模型学习的内部门类与规则过于庞杂。

第二，出于成本与响应延迟的优化考虑。

对于需要高频调用模型的大型应用，每一次请求都调用云端大型模型的API，累积的成本将非常可观，且网络延迟可能无法满足实时性要求。此时，对一个轻量级模型进行特定任务的微调便具备了应用价值。

但必须明确一点：我们对小模型进行微调，其目标绝不是让它成为一个缩小版的通用对话模型，去处理开放域、创造性的对话任务。

这类特定任务型小模型微调的真正价值在于，高效处理那些定义明确、边界清晰、且对响应速度和成本极度敏感的任务。

典型的适用场景包括：

1. 输入输出高度标准化：输入通常是短文本（如用户查询语句、关键词），输出则为结构化数据（如分类标签、布尔值、特定的JSON对象）。
2. 高频率、低延迟要求：每秒可能需要处理成千上万次请求，要求毫秒级响应。
3. 强领域依赖性：任务逻辑高度依赖企业内部的特定业务规则和数据。

在此进行小结：如果目标仅仅是补充知识或最新事实，应优先考虑RAG，因为微调并不擅长“记忆”大量具体知识；如果目标是重塑模型的输出范式（包括文本风格、规则逻辑、格式要求与处理速度），则微调是更合适的选择。

下面，我们将对这两个微调场景展开详细分析。

提升领域直觉与输出确定性

此场景的核心逻辑是：RAG负责补充“知识”，微调负责塑造“思维”。目标是让模型的回答从“基于检索资料的复述”升级为“遵循行业SOP的深度思考与稳态输出”。在行动前，必须明确以下几点：

一、何时应考虑微调？

需要注意以下几个判断点：

1. 任务所涉及的规则或SOP能够被清晰、明确地梳理和定义。不要试图用一个开放性的、定义模糊的命题来微调模型，那将导致灾难性的结果。
2. 在当前大模型的基础能力上，无论如何优化提示词，任务准确率都卡在某个瓶颈（例如95%）难以突破。
3. 存在必须严格遵守的业务边界或不可触碰的红线规则。
4. 其他需要考虑的特定因素…

在明确准入条件后，便来到了微调的核心环节：数据准备。

二、数据从何而来？

此场景所需的数据通常是高度结构化的，主要包括两类：

1. 整理好的“金标准”：例如完整的SOP文档、公司内部规范、合规条款等。数量可能在1千至5千条之间，关键是一条数据就应包含一个清晰的“判断锚点”或“决策依据”。
2. 负面案例（反例）：收集常见的错误做法及反例，同样需要1-5千条，并明确标注错误原因及正确做法。

特别需要注意的是：微调数据不应只是简单的问答对（Q, A），而应包含中间的推理过程（Q, Reasoning, A）。

以芯片编程为例，数据不应仅仅是“需求描述 -> 生成代码”，而应该是“需求描述 -> 推理分析（为何此处应使用该私有库函数？需要考虑哪些时序与功耗问题？） -> 最终代码”。

通过这种方式微调出的模型，在面对新问题时，会更倾向于模仿预设的推理路径，而不仅仅是输出一个答案。其输出的确定性恰恰体现在其推理过程严格符合我们设定的业务逻辑与规则。

芯片编程的例子可能过于专业，这里举一个更通俗的案例：

三、数据案例剖析

正面案例样本：

Q：“你好，我刚才下班回家，把车停在小区路边了。吃完晚饭下来发现副驾驶的车窗被砸了，车里放的一个笔记本电脑包不见了。电脑是公司财产，估计值一万多块钱。我现在该怎么办？”  
  
Reasoning（推理过程）：  
事件定性：用户描述的核心是“车窗被砸”和“财产丢失”，这是一个典型的“机动车盗抢”案件，应优先归类到“盗抢险”，而非普通的“车损险”。  
责任初判：车辆处于停放状态，且被盗物品为车内财产。根据常见保险条款，盗抢险通常涵盖车内财产损失，但需确认用户是否投保了“机动车盗抢险”及“车内财产附加险”。初步判断保险公司有赔付责任，但需核实具体保单。  
关键信息提取：需要提取的结构化信息包括：事发地点（小区路边）、受损部位（副驾车窗）、损失物品（笔记本电脑）、损失金额预估（10000元）、案件类型（盗抢）。  
后续行动建议：指导用户立即报警（盗抢案件必须要有警方证明）并保护现场。  
  
A（最终回答/结构化输出）：  
{  
"案件类型": "盗抢险",  
"保险责任初步判断": "可能赔付，需核实保单",  
"关键信息": {  
    "事发时间": "晚间",  
    "事发地点": "小区路边",  
    "车辆损伤": "副驾车窗被砸",  
    "财产损失": "笔记本电脑包",  
    "损失金额预估": "10000元"  
  },  
"下一步建议": [  
    "请立即拨打110报警，并获取案件回执或证明。",  
    "请对现场和车辆受损部位进行拍照留存。",  
    "请通过App上传保单信息，核实具体险种。"  
  ]  
}

数据准备就绪后，便可选择合适的工具进行微调。由于此场景在一般公司中应用相对较少，我们在此不展开工具使用的具体案例，读者可自行体会其流程。接下来，我们探讨第二个典型的微调场景。

近期，我与律师行业就人工智能的应用进行了一次深入的交流。

这次交流让我发现一个有趣的现象。以医师、教师、律师、工程师和分析师为代表的传统中产专业人士，对于AI技术的接纳度和学习能力普遍较高。他们不仅学习意愿强烈，而且已经能够将AI工具有效地应用于实际工作流程中。具体表现包括利用Coze等平台构建工作流自动化工具，更有甚者已经开始实践AI辅助编程，并取得了一定成果。

值得特别关注的是AI编程的应用。与我交流的这批律师本身并不具备代码基础，这恰恰从侧面印证了一个趋势：编程的技术门槛正在急剧降低。近期随着Gemini 3.0等模型的发布，业界关于“前端已死”的讨论也反映了这一变化。

因此，我们可以得出一个初步结论：AI编程至关重要，它正在对程序员行业产生深远影响。然而，断言AI将完全取代程序员则为时过早。更准确地说，AI编码（AI Coding）的发展预示着我们将进入一个自然语言编程的新时代。

基于我近两年的实践经验，在参与多个公司复杂AI项目时观察到一个普遍模式：核心功能代码可能仅有一万行左右，但用于驱动AI的提示词（Prompt）却可能多达数十万行。

这提示我们，编写提示词本身就是一种自然语言编程。因此，AI不会消灭程序员这个职业，但它会深刻改变职业内涵。被替代的将是那些仅仅停留在“工具使用”层面、机械编写代码的工作，或许可以称之为“代码搬运工”。

对于每一位程序员而言，关键在于清晰地认识到：软件开发范式正在发生根本性转移。未来，程序员可能需要与产品经理、医生、律师等“非专业”开发人员共同竞争提示词编写的工作量。你准备好了吗？

鉴于AI编程如此重要，本文将简要梳理其核心脉络，帮助读者快速建立认知。

实践是最好的老师

AI行业发展日新月异，如果仅仅以学习具体工具或技巧为目标，很容易陷入“学完即过时”的困境。因此，若想有效学习AI编程，需要注意两个要点：

1. 以解决实际问题为导向。最好的学习方式是“以战练兵”，带着明确的目标和项目去学习，效率最高。
2. 夯实基础知识。“以战养战”虽然高效，但也可能因缺乏系统认知而导致基础不牢。因此，在具备初步实践后，仍需进行系统性学习，构建扎实的AI技术理论基础，其重要性远超对单一工具的精通。

对于零基础的初学者，掌握AI编程通常需要跨越以下三个基础阶段：

1. 提示词工程：学会如何与AI有效沟通。
2. 理解工作流：把握AI融入开发流程的整体框架。
3. 案例实践：通过具体项目将知识融会贯通。

首先，需要掌握提示词工程的基本原理与方法。其次，要理解如何将AI工具整合到完整的开发工作流中。最后，便是今天重点探讨的案例实践环节。我们将先阐述方法论，再进行实操演示。

AI编程方法论详解

本次案例实践将假设你是一名毫无技术背景的产品经理，因此部分描述会尽可能详尽，已有技术背景的读者可选择性略过。

一个完整的AI辅助开发流程通常包括：需求拆解、架构设计、提示工程、代码生成、多轮迭代、前后端集成以及部署测试等步骤。

AI编程的核心思路在于：让AI参与到开发的每一个阶段，充当你的智能助手或“结对编程”伙伴。本质上，你扮演产品经理的角色，负责定义和设计；AI则扮演程序员的角色，负责实现具体的“代码搬运”工作。

在实际操作中，不同阶段需要注意的要点各有不同。

一、需求拆解

对于任何开发工作，明确的需求都是前提，与AI协作也不例外。无论AI多么智能，它都需要清晰、具体的指令才能发挥作用。

因此，第一步是将模糊的业务需求梳理成清晰的功能模块和技术组件。假设我们需要开发一个简单的用户反馈收集工具，允许用户提交反馈，管理员可以查看和导出。这个需求可以拆解为：

1. 一个包含反馈表单的前端页面。
2. 一个接收提交的后端API接口，用于将反馈数据保存至数据库。
3. 一个管理后台页面（或至少具备导出功能）用于查看反馈列表。
4. ……

一种低效的做法是直接告诉AI：“帮我做个收集反馈的工具。” 当然，如果你对互联网项目的技术构成确实不了解，这也没有关系，可以直接启用AI进行协助。常见的提问方式包括：

1. “要实现XX功能，需要哪些技术组件？”
2. “我要开发一个用户反馈收集网页，应该选用什么前后端技术栈？”

模型通常会给出包含技术选型在内的详细建议。在这一阶段向AI提问时，应尽可能提供充足的上下文和限制条件，例如用户规模、数据类型等。例如，可以使用如下提示词：

我需要一个Web应用来收集用户反馈。  
每天约有100条反馈，需存储文本和用户联系方式。  
我希望有一个简单后台查看所有反馈。  
请问我应该选择怎样的前端、后端框架和数据库？需要哪些主要模块？ 

明确需求细节和非功能需求（如规模）后，AI将能够给出更具定制化的技术方案建议。

二、架构设计

明确需求后，下一步是进行架构设计。这包括确定应用需要哪些页面、后端服务、数据存储方案，以及它们之间的交互方式。在AI的辅助下，这部分工作的复杂度已大大降低。

一、拆解前后端任务

你可以这样描述：

我们需要一个前端页面让用户填写反馈；  
一个后端接口接收提交；  
可能还有一个前端页面供管理员查看反馈或一个接口导出数据。  
将每个模块的职责简要描述出来，然后可以请AI检查是否全面。

在这个过程中，AI可能会提醒你增加诸如表单验证、错误提示等细节模块。这种与AI讨论架构的过程，类似于和经验丰富的工程师进行方案评审。

二、生成项目结构

任务拆解完成后，可以要求AI（例如使用Cursor等工具）生成一个简单的代码组织结构，例如：

前端：index.html, feedback.js...；  
后端：app.py 或 server.js...；  
数据库：schema.sql 或使用SQLite文件...

这些输出可以作为后续实施的具体指引。需要注意的是，AI建议的项目结构通常是通用型的，你应当结合实际需求进行调整（例如，是否需要将前后端完全分离）。但总体而言，在规划阶段AI就能提供一个相当可行的项目骨架。

对于有一定技术背景的产品经理，还可以让AI给出更详细的设计，例如数据库实体关系图、API接口设计规范等：

请设计反馈接口的API，包括请求方法、URL、请求参数和返回格式  

这样的提示会让AI产出类似Swagger风格的描述。例如：

POST /api/feedback - Body: {user, contact, message}  
Response: 201 Created or error code

这些细节设计输出能够显著加快后续的实现速度，并减少反复修改的次数。

这场争论在群里迅速升温，众多参与者加入讨论，但最终未能达成共识。然而，从许多产品与研发领域资深人士的反馈来看，恰恰验证了我之前的一个观察：Agent模式更容易获得资本市场青睐并拿到融资，而Workflow则在解决实际工作问题中发挥着稳定作用。

若要真正厘清两者关系，我们需要深入本质。一个最基础的问题是：Agent与Workflow的根本区别究竟何在？

Agent vs Workflow

Anthropic的观点相当清晰：Workflow是预设的、固定不变的执行流程；而Agent则具备自主决策能力，其行为路径是动态调整的。市面上已有不少对比分析，如下表所示：

可以注意到，此类对比往往极力强调Agent的诸多优势，同时凸显Workflow的种种局限，但对于企业级应用至关重要的稳定性、成本控制以及系统可观测性却避而不谈。

要透彻理解两者的适用场景，最好从任务类型的角度来审视技术路径的选择，如下图所示：

Workflow 特别适用于任务目标严肃、需求明确的场景。例如，基于患者描述生成诊断建议的医疗问答系统，或是自动生成结构化报告。即使在复杂情境下，它也能支持多轮交互与反复优化，其核心逻辑在于依据一套清晰的输入规则，产出一套确定的输出结果。

判断是否应采用Workflow的关键依据在于：你的任务是否需要通过多轮对话逐步收敛，以得到一个确定的答案（或清晰的数据关系），并基于此答案衍生出更多分支结论。

这一点理解起来略有复杂度，建议读者结合自身遇到的复杂生产级应用场景反复体会这段话，相信会有所启发。

而 Agent 则更适合处理目标发散、答案不唯一的开放性任务，尤其擅长协同完成某些创造性工作，例如多人协同编程。

判断是否应采用Agent架构的依据是：用户的意图是否已被充分收敛，即任务本身是否具备明确的边界和终点。如果任务追求的是稳定、可控的输出，那么它本质上是收敛的；反之，若任务本身开放、探索性强，则更适合采用Agent架构。

不过，若以发展的眼光看，理论上任何类型的任务都可以尝试用Agent架构实现。但现实情况往往更为复杂。衡量一个Agent产品是否优秀，至少需要考察以下三个核心指标：

1. 任务完成成功率；
2. 执行成本是否可控；
3. 响应与处理速度是否够快；

从这三大指标来评估，现阶段是否存在成功的Agent应用案例呢？答案是肯定的，其典型代表就是AI编程工具（如Cursor、Claude Code）。

那么，AI编程是否就应该被归为Agent的范畴呢？

AI编程是Agent吗？

答案可能有些反直觉：以Cursor/Claude Code为代表的AI编程工具，严格来说并非纯粹的Agent！

它们是当前最成功、但也最**具有“迷惑性”**的所谓Agent应用。或者说，如果严格遵循ReAct框架的定义，AI编程可算作Agent；但若依据Anthropic对Agent的界定，则不尽然。

AI编程之所以成功，恰恰因为它处理的是一类边界相对清晰、可被 “半收敛” 的特殊任务。这种特性并不能简单推广到所有通用场景。什么是 “半收敛” 特性呢？主要体现在以下三个方面：

一、目标相对可收敛：

用户的需求，无论是“实现一个登录功能”还是“修复这个Bug”，虽然最初以自然语言描述，但最终总能收敛为一段语法正确、功能完备的代码。代码能否通过编译并正确运行，提供了一个极其明确、非黑即白的验证标准。

二、环境高度结构化：

代码所运行的上下文环境，包括集成开发环境（IDE）、代码仓库、编译器及测试框架，构成了一个高度结构化、完全数字化的“微观世界”。Agent在这个世界中的可行操作（如读取文件、编写代码、运行测试）是可枚举的，且行动结果能获得清晰、即时的反馈，这大幅降低了其决策的复杂度。

三、反馈循环明确：

代码是否存在语法错误（导致编译失败）、逻辑缺陷（导致测试失败）或功能偏差（由用户指出），这些反馈都是即时、精准的。这使得Agent能够基于反馈进行高效的试错与学习。

因此，AI编程实际上是运行在一个目标可收敛、环境结构化、反馈即时的“沙盒”之中。其本质是在探索如何组合已知的代码模块与应用程序接口（API），以满足一个最终可以被明确验证的特定目标。

综上所述，AI编程更接近于一种增强型、智能化的Workflow。

从用户体验角度，它更像是一个融入了Agent交互风格的智能IDE，与追求完全自治的通用Agent仍有区别。

为了更清晰地阐明这一点，我们可以从控制权分配的角度进一步描述：

Cursor/Claude Code 的整体控制流、可用工具链、上下文构建方式都是由产品方预先设计好的。例如，“重构这段代码”、“根据需求生成新文件”、“在全项目范围内搜索相关代码”等操作，背后都遵循着一个固定的产品流程：

收集上下文信息 → 构建提示词（Prompt） → 调用大语言模型 → 校验结果或生成代码差异（Diff） → 展示结果供用户确认

因此，大模型只是在既定流程框架内进行局部决策，并未获得 “随心所欲定义和执行流程” 的最高权限。从这个视角看，它更接近一种智能化的预制工作流。

总结来说，传统软件开发流程是：设计 -> 编码 -> 调试 -> 测试 -> 重构；

而AI增强后的开发流程演变为：人类构思任务 -> AI辅助编码/生成代码 -> 人类评审与调试 -> AI辅助重构/解释代码 -> 人类集成与最终测试；

基于我们此前一系列关于AI编码的真实实践，近期收到了许多关于国内编程工具选择的咨询。在众多选项中，Qoder无疑是值得重点关注的工具之一。

Qoder近期推出了0.8.0版本更新，新增了一项名为“Experts Mode”的功能。作为Pro+用户，我在第一时间进行了升级体验，现将完整的实测过程与个人感受分享如下。

Experts Mode 核心概念解析

在早期版本中，Qoder主要提供两种工作模式。新版本在此基础上引入了第三种模式——Experts Mode。为了清晰理解其定位，我们先对比一下这三种模式的区别：

模式	适合场景	工作方式
Ask Mode	问题咨询、代码解释、文档查询	仅进行对话交流，不执行实际的代码修改操作
Agent Mode	单文件修改、简单功能实现	由单个智能体自主执行任务，以串行方式工作，适用于小型任务
Experts Mode	全栈开发、复杂重构、多模块项目	专家团队协作，任务并行执行

那么，Experts Mode具体是如何运作的呢？

用户仅需描述一个需求，Qoder的**主导智能体（Leader Agent）**便会自动将任务分解为若干子任务，并组建一支专家团队。每位专家都是经过专项优化的软件工程智能体，负责不同的专业方向。他们能够并行推进工作，各自专注，互不干扰。

用一句话概括其核心理念：用户提出需求，AI自动组建团队协同完成。

这里需要特别指出一个关键区别：市面上许多所谓的多智能体工具，本质上只是“同一模型搭配不同提示词”，模拟出多个角色，其实际能力并无本质差异。

而Qoder的Experts Mode则采用了不同的架构。每位专家（Expert）都是针对特定任务类型进行深度优化的独立智能体，并且系统会根据任务自动将其路由到最合适的底层模型。例如：在规划阶段使用擅长逻辑推理的模型，在编码阶段使用代码生成能力更强的模型，在测试阶段则调用更适合自动化验证的模型。

当前版本的专家团队包含以下角色，未来可能还会继续扩充：

角色	职责描述
Leader Agent	需求拆解、任务分配、团队组建、进度监控、冲突仲裁、结果整合
Researcher（调研员）	负责技术调研与方案比较
Backend Dev（后端开发）	负责后端数据库设计、API开发与业务逻辑实现
Frontend Dev（前端开发）	负责前端代码实现与用户体验优化
QA Tester（测试工程师）	负责测试验证与质量保障
Code Reviewer（代码审查）	负责代码质量把关，包括安全检查、规范审查与漏洞检测

不难发现，这套机制与传统软件开发团队的协作模式高度一致：有人分解需求，有人进行调研，有人负责前后端开发，有人执行测试，还有人进行代码审查。不同之处在于，这一整套流程被压缩并集成到了AI系统内部，可以实现并行执行与自动调度。

因此，Qoder的Experts Mode不再是一个“聪明的单一智能体”，而更像是一支按照专业分工紧密协作的完整工程团队。

实战案例演示

话不多说，我们直接进入实战演示。

需求描述

我向Qoder提出了如下需求：

基于 DeepSeek API 开发一款Web端对话应用，提供流畅的对话体验与精美的界面。具体功能如下：

- 对话页面(无底部导航栏)，输入框仅支持文本输入，大模型输出需支持流式返回，并能够渲染Markdown格式（包含表格与代码）。
- 在页面右下角提供新增会话的悬浮按钮，点击后创建新的会话记录。
- 提供历史对话侧边栏，通过左上角按钮打开，支持删除会话、切换会话、新增会话、重命名会话。
- 每次请求仅携带当前会话最近20条历史消息。
- 会话相关数据缓存在本地存储。

功能需求描述得较为清晰，但我有意没有指定技术栈，也未说明API Key的处理方式，目的是观察系统是否会主动发起询问。

自去年DeepSeek发布以来，国内人工智能应用市场呈现出一片蓬勃发展的景象，随之而来的是相关岗位需求的显著增加。

大约在今年三月，我身边有两位朋友表达了向AI领域转型的意愿。我带领他们进行了一段时间的系统学习，最终他们都成功找到了心仪的工作。这段经历也促使我初步构建了AI训练营的课程框架。

进入五月，我手头一个结合AI与英语的创业项目面临现金流紧张的问题。当时摆在我面前的有两条补充现金流的路径：一是外出打工以供养团队，二是通过开设AI课程来维持团队运营。

经过深入权衡，实际上可行的选择只剩下一个：通过开发课程来支撑团队发展。原因在于，几乎没有企业主会允许员工利用公司资源处理个人事务。于是，我开始正式运作AI训练营项目，至今即将迎来第九期学员的开班。

今年年初，随着OpenClaw的爆火，人工智能的热度得以延续，相应的AI岗位需求也持续保持旺盛。

然而，当前的市场环境与去年已有所不同。一方面，整体经济形势面临挑战；另一方面，部分商业案例可能让一些企业主对AI投入更加谨慎；加之今年AI编程（AI Coding）技术尤为强势，导致的结果是整个科技行业出现了较为严重的裁员潮。

总体而言，当前形势并不轻松。但正如前文所述，AI领域仍然蕴藏着大量的职业机会。因此，许多朋友希望能踏入这个行业。我此前曾整理过一份系统的学习路径图：

核心知识地图与迭代升级

这份学习路径的整体框架和思路是经得起推敲的。不过，其中部分工具和技术已经出现了迭代更新。例如，过去我们可能会使用Coze、Dify这类低代码Agent平台来构建工作流应用。

但现在，为了更贴合企业的实际需求，我们转向采用AI编程与智能体（Agent）技术来承载核心工作流与技能（Skills）。基于此，我们对整个课程体系进行了全面的4.0版本升级：

课程目标人群精准定位

本课程主要面向互联网从业者，尤其适合那些渴望转型成为AI产品经理或AI工程师的人士。如果您符合以下身份或诉求，欢迎报名参与：

一、AI领域的创业者

如果您正在人工智能领域进行创业，特别关注AI项目的试错成本与控制，希望深入了解不同类型AI项目的成本构成，或者想要汲取更多来自AI创业失败案例的经验与教训，那么这门课程将非常适合您。

我将为您剖析To B（面向企业）类AI项目的核心难点在于订单获取与尾款回收，而To C（面向消费者）类项目的挑战则聚焦于流量获取与防止创意被快速复制。

同时，我将带您深入钉钉、飞书等AI办公生态系统的核心，帮助您更清晰地定位自己在未来AI赛道中的生态位。

二、AI项目的核心负责人

如果您即将或正在某个AI项目中扮演关键角色，并且希望了解或正在遭遇一些棘手的人工智能难题，那么这门课程将能为您提供有力的支持。

我将为您阐释AI项目中存在的非对称性优势是什么，以及模型可观测性（Observability） 的重要性。

此外，我会深入讲解几种主流的AI项目类型，剖析不同类型项目在生产环境中的实践方案、核心难点及其解决方案。

三、寻求AI转型的从业者

如果您是产品经理、程序员或其他互联网角色，并且希望找到一份与AI相关的工作，那么这门课程将尤其适合您，您所能收获的价值可能比前两类人群更为直接。

我将为您展示完整的AI项目全局视角，这甚至是许多已经入职的AI产品经理或工程师都未能全面触及的领域。

揭秘生产级AI项目的内部架构

许多正在转型的同学存在一个普遍的认知误区，他们认为只要拿到AI相关的录用通知，就等于坐拥了巨大的AI红利。这种想法可能过于乐观了！

一个预算达到亿级别的AI项目，其全貌通常只允许3到5名核心成员知晓，有时甚至更少。原因很简单：公司投入巨额资源形成的核心知识资产，怎能轻易被他人掌握？

具体到工作内容，也存在明确的分级：

1. 整体架构设计：涵盖AI工程、数据工程以及两者间的协同，这是公司知识产权最集中的部分。
2. 模型调优与精炼：涉及后训练（Post-training）、检索增强生成（RAG）等技术的深度应用，通常是项目的核心策略层，位于架构之下，也是面试中高频出现的技术难点。
3. 提示词工程与上下文工程：具体到各个业务模块的标准操作流程（SOP）编写，是将公司业务具象化的关键环节。
4. 数据工程的具体实施：某个特定板块的详细数据验收工作。这通常在基础架构验证完成后进行，需要与各领域专家协作，收集AI工程所需的高质量数据，是构建数据壁垒的过程。
5. 模型效果测评：涉及执行行业内的AI应用评测标准（方案由架构层决定，此处为执行层），包括测试数据集准备、竞品调研、异常案例分析等。
6. 技术论文与公关文稿：即对外宣传和影响力构建相关的内容，一般初级人员很少涉及。
7. 技术工具选型：涉及常用工具的调研与选择，例如向量数据库选型、Agent平台（如Coze， Dify， n8n）评估、AI编程工具选型等。
8. 内部降本增效工具开发：例如数据知识库后台、提示词管理系统等。这类工作技术含金量可能不高，但权限控制至关重要，否则极易导致公司机密泄露。
9. 项目实施与交付团队：如果是专注于To B AI工具的团队，可能还存在实施团队，负责工具售前支持或实际行业落地，属于项目执行层面的关键力量。
10. 其他辅助性与支持性工作。

我可以负责任地告诉您，上述列表中真正具有高价值的工作，新手可能一个都接触不到。 真实的职业发展路径往往是：先从边缘的辅助性工作做起；接着承担各种繁琐的基础工作，例如协助领域专家整理数据；然后才能独立负责一些小模块，比如竞品调研或模型测评。

如果表现突出、做事严谨，并且在公司服务超过半年，才有可能接触到具体某个业务模块的提示词编写工作。而更上层的架构设计等核心模块，则非常难以理解和参与。

这一方面是由于严格的保密要求，另一方面是因为核心架构已经完成，没有人会轻易将历史上遇到的“坑”、为何最终选择此架构等核心细节和盘托出。

以上便是行业内正在真实发生的事情。而在这门课程中，我将以AI项目的全局视野，带领您学习、感受甚至部分实操这些内容，助您触碰那些看似遥不可及的核心领域。

高频疑问权威解答

以下是一些大家普遍关心的问题：

一、课程采用何种形式进行？

课程为真人讲师在线直播授课（非录播），使用腾讯会议平台。每周上课2至3次，时间通常安排在工作日晚上10点或周末上午10点半。

二、课程是否提供回放录像？

所有课程均会提供录播视频，便于复习。同时，课程会布置作业并进行检查。

三、不具备编程基础是否可以参加？

可以参加，但学习过程中可能会感到有些吃力。我们的最低要求是能够撰写清晰的产品需求文档，即对逻辑思维能力要求较高。编程能力不是强制要求，但具备基础会更有优势。

四、课程能否提供工作推荐机会？

可以。只要学员能够高质量地完成所有作业，成功转型上岸的概率很高。

五、往期学员主要来自哪些背景？

目前学员背景多样，最高职级达到P9级别（有2位），其中包括多位企业高管、创业者、人力资源负责人、CEO助理以及经理级别人员。但超过50%的学员是希望转型AI的普通产品经理和程序员。

六、如果学习效果不理想怎么办？

我们提供课程重修的机会。

系统化课程大纲深度解读

从AI实际应用的视角出发，许多复杂的专业名词对于大多数应用者而言并非必需。例如，我曾见过某《AI工程师XX计划》课程礼包中包含TF-IDF， Bm25， BERT， 贝叶斯， FastText， LSTM， Viterbi， 向量化， Encoder-Decoder， 知识图谱等内容。

近期进行了两次企业AI咨询，发现市场对AI编码（AI Coding）的需求已非常迫切，几乎成为刚需。为此，我们调整了课程重点，并从中提炼部分核心内容，撰写了以下文章： 这些案例均源于真实的生产实践。出乎意料的是，评论区的热烈讨论甚至超过了正文本身。 有人质疑其为夸大其词，有人认为这是在给管理者提供“压榨”工具，也有不少人诚恳地追问：你们究竟是如何做到的？

坦率地说，部分质疑是可以理解的。如果是我初次看到“十年老系统、54万行代码、两周重构完成”这些词汇组合在一起，第一反应恐怕也不是赞叹，而是怀疑：

这该不会是又一个关于AI的神话（或者说笑话）吧？

然而关键在于，这件事确实发生了。它并非PPT演示，也不是概念验证，而是一个已经过灰度测试并上线的真实系统。 因此，本文不再赘述AI能力有多强大，也不打算将其写成一篇“爽文”。我们将认真探讨以下四个核心问题：

1. 这件事的具体实现路径是什么？
2. 其成功真正依赖的前提条件有哪些？
3. 这种方法的边界和局限性在哪里？
4. 普通技术团队能否复制？管理者应如何正确理解？

需要说明的是，我们会在尽量不透露过多课程专属细节的前提下，真诚地进行解答。也希望大家在今后的工作中，避免对AI编码产生极端误解。无论是将其神化、认为无所不能，还是将其妖魔化、视为给老板画饼的工具，都是不恰当的。正确的态度是拥抱变化，切勿故步自封。

质疑焦点：真是两周完成的重构吗？

首先，澄清最易引发争议的问题：这算不算是“两周重构完成”？ 这是评论区最集中的质疑点。因为在许多工程师的认知中，“重构完成”默认包含了大量工作：

1. 业务逻辑梳理
2. 技术方案设计
3. 核心功能开发
4. 回归测试
5. 灰度观察
6. 线上稳定运行
7. 长尾问题闭环
8. … 如果按照这个标准来理解，“两周搞定十年老系统”确实像天方夜谭。 因此，我们首先明确口径：

这里的“两周”，特指核心迁移开发、关键行为对齐以及基础验证的时间周期。 后续的灰度切流、线上观察及零星修复，又持续了一周多。

换言之，所谓的“两周重构完成”，更准确的表述是：代码层面的主体迁移工作，在两周内交付完成。 这并不意味着两周内就解决了所有上线后问题、所有隐性分支逻辑以及所有历史兼容性细节。这两种说法差异显著：前者是一个高强度但真实的工程案例；后者则容易沦为营销叙事。不过，两周与四周的时间差异，真的具有决定性意义吗？

项目本质：是翻译还是重构？

整个讨论中，我们认为最专业的问题是：这究竟算重构还是翻译？这个问题值得深入探讨。 因为很多人一看到“重构”这个词，脑海中浮现的是另一幅图景：

1. 重新梳理领域模型
2. 重新划分服务边界
3. 重写系统架构
4. 借此修复历史技术债务
5. 顺便整理不合理的业务逻辑
6. … 若按此理想标准，本次项目当然不能算作那种彻底的“大重构”。 因为我们最核心的目标，从来不是“重做一个更先进的系统”，而是：

在不改变外部行为的前提下，将一套运行了十年的PHP老系统，迁移至Java技术栈，并降低后续维护成本。

因此，更准确地说，本次项目的本质是：

1. 平迁（Lift-and-Shift）
2. 行为对齐
3. 强类型化改造
4. 工程化能力补全
5. 包含局部优化的重构
6. … 所以，如果说它是“翻译 + 小部分优化”，这个说法并不算错。但如果仅仅视其为“翻译”，则低估了其中的工程含量。 因为纯粹的翻译不会做以下工作：
7. 将PHP的弱类型Map全链路替换为Java DTO
8. 将一堆历史逻辑拆分为可维护的模块
9. 补全缓存、RPC、序列化、并发等方面的工程约束
10. 实施双端验证、日志闭环、差异追踪、PHP同步监控
11. 在上线阶段设计灰度与回滚策略

如果非要寻找一个更精准的定义，我们会如此描述本次项目：

这是一次以平迁为主、以行为一致为约束、以强类型化和工程能力补全为核心目标的重构。

它既非纯粹的翻译，也非理想化的大重构，更像是一场“开着车换轮胎”的工程迁移。

可信度挑战：为什么传统路径行不通？

至此，我们再来探讨：为何许多人觉得此事不可信？ 因为按照传统路径，这类项目几乎无法推进。试想一下，一个运行十年的老系统，54万行PHP代码，文档缺失，自动化测试几乎为零，大量逻辑混杂着业务补丁、历史兼容代码和临时修复。 面对这样的系统，传统做法通常是：

1. 花费大量时间理解系统全貌
2. 梳理业务逻辑和技术债务
3. 补充测试用例
4. 再逐步开始重构
5. … 听起来合理，但在现实中经常倒在第一步。 这类系统最棘手的并非“代码量大”，而是：

你根本无法确定眼前这段糟糕的代码，究竟是在解决一个真实问题，还是仅仅在堆积历史遗留的“屎山”。

近期，在我参与的创业项目“空气小猪”的下一轮迭代中，产品设计耗费了大量心神，以至于没有充裕时间撰写长篇内容。

翻看旧日素材，决定将去年一个电话销售项目中的某个功能片段——“销售线索自动分配”拿出来探讨。该功能上线后曾一度体现出显著的业务价值。

事实上，在电销业务模块中，人工智能有着多样化的应用场景，例如之前提及的AI客服系统（相关案例可参考过往文章）。而本次介绍的销售线索自动分配功能，虽然只是庞大线索管理体系中的一个子模块，但在上线之前，其所关联的问题却相当棘手。

线索分配的核心矛盾

去年，我曾实际为三家规模不等的电销业务团队提供支持，其客服人员数量在50至300人之间。他们的业务模式非常典型，遵循着标准的广告投放引流逻辑。

作为一名拥有多年经验的产品研发管理者，若被问及所有团队中最难管理的是哪一类，我会毫不犹豫地回答：销售团队。这个群体往往想法复杂，个人主义色彩浓厚。

他们有时会过于自信，甚至认为公司的全部业绩都归功于其个人能力，从而可能表现出傲慢与自大。然而，电销业务的核心本质在于流量运营。整个广告投放流程及各种流量获取技巧至关重要，它们直接决定了销售线索的数量与质量。

获取线索之后，紧接着便会面临另一个关键问题：分配。这不仅仅是任务的派发，在更深层次上，这近乎是利益的分配。因此，销售团队内部及团队之间常常因此产生冲突。

一个销售小组，多则20人，少则5人。争斗首先会在小组之间爆发，其次蔓延至组内成员之间。其核心矛盾点始终围绕着一个命题：线索分配是否公平。

这些销售深谙“会哭的孩子有奶吃”的原则。那么，真实的线索分配在小组层面是否公平呢？

答案是：当然不公平！ 同样分配给两个小组各25条线索，其中一个小组获得的线索质量可能远高于另一组。这其中的操作空间和潜在因素非常复杂。

于是便出现了经典的局面：忙的忙死，闲的闲死；旱的旱死，涝的涝死。

管理层并非没有意识到这种内耗，但“有人的地方就有江湖”，情感因素和人为操作始终存在，使得这个问题一直悬而未决，偶尔还会变得异常尖锐。正因如此，AI线索自动分配系统的构想应运而生。

要实现这个功能，其难点与人工智能技术本身关系不大。撇开复杂的管理学问题，其核心在于分配策略的设计。

系统在设计之初就必须规避人为分配线索的环节，实现 “线索主动寻找团队、寻找销售” 的机制。从根源上杜绝销售人员争抢线索的可能性。即便出现问题，也属于系统策略层面的调整，而非个人矛盾。

所有这类项目的实施大致可分为三步：建立数据模型、构建分配流程、设置提醒机制。看起来步骤清晰，实际执行起来却也绝不简单。

线索建模：自动分配的基石

在销售自动化系统中，线索建模是实现自动分配的逻辑基础。

线索评分旨在对各个潜在客户线索进行相对客观的价值排序，帮助企业识别高质量线索。换言之，优质的线索往往拥有更高的成单概率。这不仅对销售端有益，对广告投放端也具有重要指导意义。因此，对线索进行建模分析是必不可少的环节。

曾有在Oracle工作的同行提及，他们的销售体系会强调基于潜在客户的匹配度和意向等级对线索进行打分，以此实现更高的成本效益。

要进行有效的线索建模，首要任务是对线索来源进行分类并评估其优先级。

常见的线索来源包括：官网主动注册留资、电话主动咨询、抖音广告点击、小红书内容触达、线下地推扫码等。不同来源的线索在意向度特征、数据完整度、最终转化概率等方面存在显著差异。我们可以依据这些维度，为每一类线索赋予不同的初始评分或权重。

注：由于涉及公司具体实践项目，真实的完整建模数据在此不便展示。以下示例旨在提供一种类似的评估思路供大家感受。

一、官网主动留资 用户主动通过官网表单提交个人信息，通常显示出较强的购买意向。所填写的信息（如姓名、电话、具体需求等）也较为完整，转化概率相对较高，因此评分应位于前列。

二、电话主动咨询 用户直接拨打电话进行咨询，其意向度通常极高（近乎于准客户状态），转化潜力最大，可考虑赋予满分或接近满分的评分。

三、地推扫码 用户在推广活动现场主动扫码报名留资，意向度一般较高（毕竟是主动参与），但所留数据可能不如线上表单填写得完整，因此评分可略低于上述两种来源。

四、小红书内容触达 用户通过浏览小红书平台的内容或广告点击了解到产品，意向度属于中上水平。该平台用户质量相对较好，互动深度也较高（用户需要主动浏览内容后决定是否咨询），故评分可设定在中位偏上。

据统计，小红书广告带来的线索很多源于用户的主动搜索，意图明确，其转化率显著高于一般的信息流广告。

实践表明，对于面向消费者（2C）的产品，小红书是目前非常优质的渠道之一。

……

线索来源	意向度	数据完整度	转化概率	评分(1-10)
官网主动留资	高	高	高	9
电话主动咨询	最高	高	最高	10
地推扫码	中高	中	中高	8
小红书内容触达	中上	中	中	6
抖音广告点击	中	中	低	5

从线索模型到销售分配逻辑

建立线索评分模型后，便可以依据分数高低来制定具体的分配规则。