先前我曾探讨过AI项目团队应如何搭建的问题（参阅文章：《AI团队组织结构该如何设计？》）。文中提及一个观点：在项目初期，产品经理这个岗位其实缺乏实质意义。部分读者可能感到诧异，因为在过去的职业转型路径中，产品经理往往是许多技术或测试人员向往的角色，例如从测试或开发转向产品。如今却被告知这个角色可能不再必要，这难道不是颠覆性的吗？要透彻理解这一观点，我们或许需要追本溯源。

产品经理的“权柄”何在？

若要用一句话概括产品经理的核心权力，我认为是：产品经理通常是产品或项目成果的验收者。换言之，产品经理往往拥有对产品（从测试完成到正式上线前）的首次评价权。更进一步说，产品经理有时也被视为产品的定义者，但这一点在实际中往往较为模糊。在多数中小型企业中，产品的最终设计决策者通常是老板，老板本身就是“最大的产品经理”。倘若你真正拥有定义产品并拍板的权力，那么你的角色可能已超越纯粹的产品经理，更接近于公司高管。

综上所述，对产品好坏的评价能力，是产品经理赖以生存的基石，也是其能够对开发人员提出要求与指导的资本，毕竟他们处于工作流的上游。然而在当下，这块基石正变得松动，或者说其评价权已被很大程度上分割出去。我们可以通过一张全景图来审视：

这张图几乎涵盖了一个生产级复杂AI项目的全部关键任务。理解此图，便能明白为何产品经理的价值在AI项目中可能显著降低：

• 行业专家是整个AI项目的核心评价者。AI的回答是否优质、是否专业、存在哪些缺漏，都需要由他们进行评估，并将意见反馈给技术负责人。
• 技术负责人则是项目组的核心驱动力，承担承上启下的关键作用。他们需要评价与决策技术路径的优劣。此外，行业专家团队虽然能发现问题，但通常无法独立解决问题；任何问题的最终解决，都必须回归技术团队。

而产品团队在AI时代面临着比较尴尬的处境，主要原因有二：

1. 过去互联网产品的交互与审美范式已高度固化。如今想要设计一款产品，市面上通常已有大量可参考甚至直接借鉴的案例。
2. 关键在于，AI产品的核心交互往往只是一个极其简单的对话框。这极大地压缩了产品经理在交互设计与审美层面的发挥空间。更重要的是，产品经理通常缺乏评价AI回答专业性好坏的能力，这意味着他们部分丧失了对其产出的核心评价权。作为曾经产品验收环节的重要参与者（至少是执行者），产品经理的角色权重被大幅削弱。

相应的，以往对程序员的评价主要集中于代码质量，而现在逐渐需要加入对“提示词是否优雅高效”的考量。AI项目带来的变革，本质上是整个价值评价体系的重塑。

理解了这一底层逻辑后，我们可以进一步探讨，在中小型公司里，产品经理所承担的其他重要角色。

具备高度兼容性的项目协调者（PMO）

以产品“首次评价者”及修改建议（常为决策）提供者的传统角色来看，产品经理在实际工作中会有意或无意地承担起一个角色：团队的项目协调者（PMO）。

大家可能会发现，产品经理似乎天然适合这个角色。一方面，他们需要梳理大量信息，确保团队运作顺畅；另一方面，也需要确保产品在执行过程中不偏离既定方向。

然而，我认为产品经理在此岗位上最为重要的作用或许是：进行有效的向上管理，因为繁琐的汇报工作总需要有人承担……

程序员群体通常比较“务实”。他们在日常工作中，往往会优先选择对自身职业生涯最有助益的任务，或者说将时间精力投入到投资回报率更高的技能提升上。

因此，在互联网行业增长放缓之前，程序员普遍更倾向于默默编写代码。这几乎是一种“难以两全”的选择，只有真正写过代码的人才能体会其中的深度。以十年前的前端技术栈演进为例：

1. 最初可能只需精通JavaScript或CSS其中一项，便足以立足。早年许多专攻JavaScript的开发者甚至不擅长编写CSS，这听起来或许令人惊讶。
2. 随着行业竞争加剧，前端开发者开始需要同时掌握JS和CSS，这相当于涉及两套技术栈，各自熟练起来花费半年时间实属合理。
3. 竞争持续升级，仅精通前端还不够，还需涉足原生应用开发。于是Hybrid、React Native等技术应运而生。此时前端业务代码的复杂度已显著提升。
4. 但从业者众多，为了拉开差距，Node.js出现了，前端开发者开始向后端领域拓展。这其中存在不小的技术栈跨越，要达到熟练程度，半年时间绝不夸张。
5. 然而，无论是Node.js还是PHP，更多是语言层面的问题。数据库知识总需要了解吧？各种潜在的技术难点与性能瓶颈总需要应对吧？这绝非一年半载能够轻松掌握。我曾认识一位后端出身的朋友，在B站就因一个锁机制理解不透彻，直接导致了一次严重的线上事故。
6. 技术演进之路还在继续……

以上就是所谓“全栈工程师”的成长路径。可以看出，要达到公认的全栈标准，需要投入巨大的精力，绝非一朝一夕之功。这也引出一个现实问题：

真正靠谱的程序员，往往既没有时间也没有心思去处理产品相关的杂务，因为他们可能认为这些工作属于“通用性较低的低阶技能”。毫不夸张地说：

项目管理的核心，某种程度上就是任务清单加时间提醒，需要持续进行沟通、确认、汇报，并全程推动各方进度……

而承担这个协调者角色，实际上具备良好沟通能力的技术人员，往往比纯粹的产品经理更合适，因为他们更清楚团队中谁在认真工作，谁在敷衍了事。只不过过去他们大多不愿意接手这类工作罢了。但如今情况已发生翻天覆地的变化：

1. 市场遇冷极大加剧了行业内部竞争。
2. AI的出现显著提升了工作效率，并降低了成为全栈工程师的门槛。

于是，“你不愿意做，自然有其他人愿意做”的局面开始出现。当技术负责人（或经理）愿意主动承担项目协调者（PMO）的职责时，普通产品经理的地位就显得有些微妙了……

因此，产品经理当前的生存空间实际上正在被同步压缩。现阶段，嗅觉敏锐的产品经理已经开始积极学习Vibe Coding，至少掌握一些Coze或Dify的使用技巧——他们也试图在技术领域开辟新的战场。不难看出：当下正是行业重新定义各岗位职责边界的关键时期。

产品经理：企业的“翻译官”

综上所述，在AI项目从0到1的初创阶段，产品经理的传统价值确实有限。然而，当项目发展到一定规模，进入规模化扩张或商业化运营阶段时，往往需要协调市场、运营、销售等多方资源。此时，纯粹的技术背景人员可能会感到吃力。

例如，仅是与商务团队沟通需求这一项，技术人员就可能很不适应。销售为了达成交易倾向于过度承诺，而技术人员为了确保可行性则倾向于保守承诺。销售可能认为技术人员思维僵化，影响成交；技术人员则可能认为销售言过其实，给自己带来麻烦。久而久之，容易产生摩擦。

除非能从根本上解决这种因上下游立场不同而产生的结构性矛盾，否则更需要精通业务、具备跨部门沟通能力的“多面手”角色。我认为一个恰当的比喻是：产品经理是公司内部的“翻译官”。他们首先需要帮助老板“翻译”并传达战略意图，其次需要为各个部门“翻译”不同的业务语言和需求。

这不是技术专家或业务专家能否胜任的问题，而是比较优势的问题。谁更擅长此类沟通与协调，谁就应该承担相应职责。只不过，当项目进入规模化阶段、产品已然上线时，团队已非初创状态，角色分工也会随之演化。

核心结论与未来展望

最后总结核心观点：AI技术的兴起，对当前项目研发链条中的各个角色都带来了显著冲击，其根本原因在于价值评价体系被重塑。

一方面，AI产出内容的专业性需要行业专家来评判，这剥离了产品经理过往对内容价值的评价权。另一方面，我们每个人的工作过程与成果，也前所未有地暴露在AI的辅助分析与审视之下，这使得岗位价值必须回归到更本质的贡献层面来衡量。

一旦评价权重塑，团队的组织形态便被迫重组。尤其是在从0到1的AI项目中，一种更“原生AI化”的团队组合方式正在显现：让技术背景人员承担更广泛、更核心的角色。

但必须澄清，这并非主张“彻底取消产品职能”，而是指传统产品经理依赖PRD（产品需求文档）、传话、对齐等工作的“中间层”价值被系统性压缩了。更高效的新型团队结构可能呈现如下特征：

一、创始人成为实质上的首席产品经理

在AI项目初期，关键往往不在于挖掘海量需求，而在于清晰地定义AI产品的能力边界。对于“做什么”与“不做什么”，必须做出果断取舍。

根据近年在多家公司的观察，越来越多的CEO倾向于亲自深入业务一线：他们第一时间体验产品输出质量、亲自判断能力边界、亲自决定后续迭代的优先级。这或许是时代发展的必然要求，否则信息在“转述-再转述”的过程中会产生严重损耗，导致决策与执行速度大幅下降。

更进一步，增长思维也被更早地融入产品构建过程中：如何向用户清晰传达产品价值、如何在社区中验证需求、如何建立有效的反馈闭环，这些本质上都是产品工作的一部分，而非产品上线后才开始的“运营动作”。

总之，成功的AI项目，必然是“一把手”深度参与的工程。

二、产品经理转型为“Coze搭建能手”

当产品交互被简化为一个对话框时，产品设计的关键便不再是绘制复杂的原型图。新的挑战在于：如何将企业的品牌调性、用户体验、安全约束等抽象要求，巧妙地融入这个简洁的聊天界面，同时避免使其变得臃肿。

观察发现，如今优秀的产品负责人正变得非常“卷”，他们往往主动学习并掌握Coze等低代码/无代码AI应用搭建工具。这带来的变化是，他们在“原型验证”阶段开始部分绕过研发团队。

过去写在PRD里的功能描述，正越来越多地被“可运行的原型”、“可交互的演示Demo”或“可直接对齐的业务工作台状态”所取代。这种通过Coze等工具快速搭建并验证通过的方案，其本身几乎就是一份立体的需求文档。

三、技术负责人需兼具全栈能力与项目管理智慧

技术骨干在新型团队体系中，很可能依旧是**“最忙碌”**的核心成员。项目早期的工程师不仅是需求的实现者，更需要负责将模型能力、上下文管理、工具链、评估测试链整合贯通。

AI项目的演示原型可能很快就能做出，但将其打磨至真正可用、好用的程度，则极其考验耐心与综合能力。因此，这本质上也是一项巨大的项目管理工作，要求负责人具备高超的管理智慧。

这个角色需要将各项工作串联起来：如何构建测试集、如何设定质量红线、如何进行回归验证、如何监控线上模型的性能漂移与潜在风险。工程师越是善于利用AI工具提升个人与团队效率，团队就越能用更精简的人数完成业务闭环，也越不需要依赖传统的“中间协调岗位”来维持运转。

最终，在AI驱动的项目中，谁掌握了核心的评价方法与实现能力，谁就掌握了事实上的话语权与决策权。这或许就是新时代团队构建的本质逻辑。

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

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

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

线索分配的核心矛盾

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

……

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

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

近来在负责创业项目“空气小猪”的下一轮迭代，产品设计耗费了较多心神，因此没有太多精力撰写长篇内容。翻看往期素材库，我决定将去年在电销项目中实践过的某个片段功能——“销售线索自动分配”拿出来分享。这套系统在上线初期，确实为团队带来了显著价值。

事实上，在电话销售（电销）模块中，存在着众多AI技术的应用场景。例如我们之前探讨过的AI客服系统便是一个典型案例。而本次将要介绍的销售线索自动分配功能，虽然只是庞大销售线索管理体系中的一个子模块，但这个看似微小的环节，在上线前却引发了诸多复杂的管理问题。

线索分配引发的内部矛盾

去年，我实际服务了三支电销业务团队，其客服人员规模在50至300人之间不等。他们的业务模式非常典型，主要依赖于广告投放获取流量。

作为多年的产品与研发管理者，如果被问及所有业务团队中哪一类最难管理，我的答案无疑是销售团队。这个群体往往拥有诸多“个人考量”。他们时常自信地认为公司的业绩全然由自己创造，因而可能表现出一定程度的自负。然而事实上，电销业务的核心竞争力在于“流量运营”。广告投放的策略与各种获取流量的技巧至关重要，它们直接决定了销售线索的数量与质量。

当销售线索获取后，紧接着便面临“分配”这一环节。与其说这是在分配工作任务，不如视作是在“分配利益”。因此，销售团队内部因线索分配而起的冲突屡见不鲜。一个销售小组，多则二十人，少则五人，争斗首先发生在不同小组之间，继而蔓延至组内成员之间。其核心矛盾点往往聚焦于“线索分配不公”。

销售们深谙“会哭的孩子有奶吃”的道理。那么，真实的线索分配是否存在不公呢？答案是肯定的。即便两组分配到的线索数量相同，比如各25条，但其中一组的线索质量可能远胜于另一组。这其中的门道相当复杂。

于是便出现了“忙的忙死，闲的闲死；旱的旱死，涝的涝死”的局面。管理层并非不知晓这种内耗，但有人的地方就有江湖，涉及情感与利益就难免存在操作空间。因此，这个问题一直存在，时而还会变得相当尖锐。正是基于此背景，“AI线索自动分配”系统应运而生。

要实现这一功能，真正的难点与AI技术本身关联不大。抛开复杂的管理学问题，其核心在于“分配策略”的设计。系统从设计之初，就要规避任何形式的人为干预，实现“线索自动匹配团队与人”的机制，从而在根源上杜绝销售人员争抢线索的可能性。如果出现问题，也将是系统性的策略调整，而非个人操作。

这类项目的实施大致可分为三步：建立线索模型、构建分配流程、设置跟进提醒。看似步骤清晰，实则每一步都需精心设计。

构建线索质量评估模型

在销售自动化系统中，线索建模是实现自动分配的逻辑基础。线索评分旨在对各个潜在客户进行相对客观的价值排序，帮助企业识别出高质量的销售机会。简而言之，优质线索的成交概率远高于普通线索，这不仅对销售端有益，对前端的广告投放也具有关键的指导意义。因此，对线索进行建模评估是必不可少的一环。

我曾与在Oracle工作的粉丝交流，他们的销售体系也强调根据潜在客户的匹配度和意向等级进行线索打分，以此提升营销的整体成本效益。

进行线索建模，首先需要对线索的来源渠道进行分类，并评估其优先级。常见的线索来源包括：官网主动注册、电话主动咨询、抖音广告点击、小红书内容触达、线下地推扫码等。不同来源的线索在意向强度、数据完整度、历史转化概率等方面存在显著差异。我们可以依据这些维度，为每一类线索赋予不同的初始评分或权重。

注：因涉及公司具体商业实践，真实的建模参数不便公开，以下示例仅供感受其思路。

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

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

三、地推扫码 用户在线下推广活动中主动扫码留下信息，意向度一般较高，但其填写的数据可能不如线上表单完整，因此评分略低于上述两类。

四、小红书内容触达 用户通过小红书平台的内容或广告了解到产品后产生咨询，意向度属于中上水平。该平台用户质量普遍较好，互动也更为深入（用户需主动浏览并决定是否咨询），故评分居中偏上。据统计，小红书广告带来的线索很多源于用户的主动搜索，意图明确，转化率显著高于普通信息流广告。

从评分模型到分配规则

建立起线索评分模型后，便可以依据分数高低来制定具体的分配规则。评分高的线索意味着用户意向强烈、资料完善、成交可能性大，这类线索通常交由销售精英或冠军团队跟进。这符合销售领域的“二八定律”，即80%的业绩往往由20%的顶级销售创造。

我们曾咨询过从事CRM系统开发的同学，他们也建议将高价值线索优先分配给经验丰富的销售专家，以最大化转化机会。而对于评分较低的线索，则可以自动流转至线索培育池，或由系统设定自动化跟进任务。

在明确了高优先级线索的定义后，下一个关键决策是：哪些线索应直接分配给销售团队，哪些需要进入培育流程。通常，只有经过模型评估后的高分线索，才会被直接移交至销售端进行跟进。

注：在我们的实际项目中，所谓的“线索培育组”后期功能被集成化的AI客服系统所替代。

总之，通过线索评分模型来推导分配逻辑，可以实现 “以质取胜，分级跟进” 的策略。高分线索由资深销售快速响应，提升转化效率；中等评分线索按既定规则分配给常规销售团队；低分线索则交由AI或培育团队进行深度孵化。这样既避免了优质销售资源的浪费，也确保了潜力线索不被忽视。

模型数据反哺广告投放策略

为什么说线索建模是必须做好的一环？因为其产出的数据可以反向指导流量投放策略与广告预算分配。一个核心原则是：产生优质线索越多的渠道，其投放价值就越高。

这一点至关重要：一个百人规模的客服团队，其年度人力成本可能不到500万，但对应的广告投放预算却可能高达上亿。算法侧微小的优化带来的效益，可能就足以覆盖整个客服团队的成本。其中的轻重权衡，需要清醒认识。

如果通过模型分析发现，来自搜索引擎优化（SEO）或搜索引擎营销（SEM）的渠道产生了大量高分线索，那么就应该倾向于增加该渠道的广告预算。反之，如果某些平台带来的多为低分线索，则说明该渠道流量质量一般，应考虑减少投入或彻底优化其投放策略。

有行业分析显示，小红书广告的电商转化率平均在3.0%至7.5%之间，显著高于抖音平台的1.5%至4.0%。小红书用户决策成本更高，但其粉丝的商业价值也更为突出。单就商业变现能力而言，小红书的潜力不容小觑。

此外，渠道分析还可以进一步细化。例如，可以对比视频类广告（如抖音短视频）与图文类广告（如公众号图文、信息流广告）所带来的线索质量差异。普遍认知中视频更具吸引力，但究竟哪种形式的线索转化更好，仍需依据自身业务数据进行判断。

实现分配流程的自动化

请注意，直到这一步，才与人工智能（AI）产生较为直接的联系。这也印证了在许多工作流项目中，所谓“AI含量”可能并不如想象中那么高。

自去年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， 知识图谱等内容。

上周我们探讨了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咨询，发现市场对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 Coding 到了什么程度了？》的探讨，我们得出的核心结论是：

AI编程已经超越了仅仅编写演示代码、补充函数或创建简单页面的阶段。

在约束条件清晰、业务边界明确且验收标准可执行的前提下，它已经能够胜任相当一部分实际的软件交付工作。

与此同时，深度使用过AI编程工具的同学也必然清楚，在新项目或规则清晰的项目中，AI的表现往往非常出色。随之而来的一个关键问题是：在面对那些历史悠久、结构混乱的“遗留代码”时，AI编程的表现又如何呢？ 例如：

对于一个运行超过十年、文档缺失、逻辑错综复杂、维护成本极高的系统，想要重构却担心引发问题，不重构又严重阻碍业务发展。在这种“地狱难度”的场景下，AI能否真正发挥作用？

https://watermelonwater.tech/insights_imgs/10年系统重构54万行代码1.webp)

今天，我将分享我们团队一次真实的AI编程实战经历：仅用两周时间，成功完成一个运行十年、累积54万行PHP代码的核心电商系统的重构，并将其平稳迁移至Java技术栈。 整个项目全程深度依赖AI辅助，最终实现了按时且平稳的交付。

项目背景：一场高风险的技术战役

十年老系统、54万行PHP代码、两周交付周期、核心电商业务链路、从PHP迁移到Java，当这些要素组合在一起时，即便是完全依靠人工团队来完成，也足以让许多经验丰富的团队感到棘手与沉默。

https://watermelonwater.tech/insights_imgs/10年系统重构54万行代码2.webp)

此类项目的最大难点，从来都不在于“如何编写新代码”，而在于：你很可能根本不清楚自己正在改动的是一个什么样的系统。

遗留系统与新项目截然不同。新项目的业务逻辑相对清晰（至少文档是齐全的），很多时候只要将需求拆解清楚，AI就能持续推动进度。然而，“遗留代码山”并非如此。

它最核心的问题并非代码质量低下，而在于其低质量的复杂性、真实性与经年累月的线上运行历史交织在一起。

大量逻辑没有文档记载；无数业务分支在设计稿中无从查找；许多兼容性代码，甚至连最初的开发人员都可能遗忘其存在的初衷。你今天看到的一段糟糕代码，很可能并非源于当时开发者的能力不足，而是因为三年前某次线上事故，临时采用这种方式进行兜底处理；你觉得某个字段命名怪异，其背后或许关联着三个旧版本客户端和五个外围系统的调用。

因此，面对这类系统，最大的风险并非“写不出代码”，而是“你以为自己理解了，但实际上并未真正理解”。

本次项目最具价值的部分也恰恰体现在这里。它并非意在证明AI已经能够独立完成遗留系统的重构，而是证明了：

当人类工程师牢牢守住系统边界与核心决策权时，AI足以承担重构过程中大量最繁琐、最枯燥、最重复的工作任务。

这才是本次案例真正值得深入探讨的原因。接下来，我们将直面项目中的具体挑战。

直面挑战：老系统重构的三大核心难题

提及老系统重构，多数人的第一反应通常是代码基数庞大、历史包袱沉重、技术债务堆积如山。

这些固然是事实，但如果你真正参与过此类项目，便会发现导致项目最终失败的，往往并非代码质量问题本身，而是以下三方面因素叠加所产生的影响：

https://watermelonwater.tech/insights_imgs/10年系统重构54万行代码3.webp)

挑战一：代码量巨大，难以全面掌握

54万行的总代码量，意味着几乎没有人会真的打算逐行阅读所有代码。

这并非“多花几天时间总能看完”的问题，而是你根本无法在有限时间内建立起对整套系统足够可靠且全面的认知。

尤其是核心电商系统，商品导购、详情页、库存管理、价格计算、促销活动、异常处理以及各类兼容性分支，这些模块通常深度耦合、相互牵连。

一个看似简单的接口，其背后可能隐藏着一长串复杂的调用链路；一个响应对象中不起眼的字段，可能已被前端页面、运营后台以及多个外围服务同时依赖。

更为棘手的是，这类系统通常还伴随着以下几个典型问题：

1. 文档严重缺失，甚至许多关键部分完全没有文档。
2. 存在大量弱类型代码，字段的真实数据类型并不稳定。
3. 诸多隐式业务逻辑和历史兼容代码隐藏在细节之中。
4. 代码“坏味道”明显，但出于风险考量又不敢轻易修改。

因此，最大的难点并非读不懂某一段具体代码，而是代码量近乎无限，你永远无法“看完”，也无法掌握全貌。

https://watermelonwater.tech/insights_imgs/10年系统重构54万行代码4.webp)

挑战二：交付时间异常紧迫

如果时间充裕，无论系统多么复杂，总有可能通过逐步推进的方式完成重构。

但本次项目不具备这个条件。两周的交付窗口，首先意味着，在组织层面，“重构”本身就可能被视为一种资源浪费行为，而非必要的技术投资。团队历史上的技术基础设施建设（或称技术债务偿还），往往都是在高强度加班中完成的…

其次，它意味着你没有足够的时间去彻底读懂旧系统，没有时间先行补充完整文档，没有时间进行从容的抽象设计，更没有机会采用许多人习惯的传统路径：先完全理解，再逐步重构。

真实业务场景下没有“尽力试试”的选项，只有必须按时交付的硬性要求。项目几乎没有试错空间，也无法以“尚在理解过程中”作为延期借口。

每一次对核心系统的重构，都如同在高速行驶的汽车上更换轮胎，充满了极高的风险与压力。

https://watermelonwater.tech/insights_imgs/10年系统重构54万行代码5.webp)

挑战三：业务风险等级极高

如果这只是一个边缘系统、内部后台或报表工具，出现问题尚有修复和回旋的余地。

但本次面对的是核心电商系统。这类系统最可怕之处，并非它是否会直接崩溃，而在于它很可能陷入一种更为麻烦的状态：表面运行正常，但核心业务行为已悄然发生改变。

例如，金额少计算了一点，库存判断出现一次偏差，导购页面漏掉一个分支逻辑。这些看似微小的差异，一旦置于线上真实流量之下，便会造成切实的业务损失。

因此，项目真正的难点在于：

如何在极短的时间内，将一个庞大而未知的系统，转化成一个可分析、可验证、可灰度发布、可快速回滚的工程对象？

如果无法做到这一点，AI的编码能力越强，可能引入的潜在风险反而越大。

https://watermelonwater.tech/insights_imgs/10年系统重构54万行代码6.webp)

破局关键：确立可验证的行为基线

许多团队在进行老系统重构时，初期很容易陷入一个思维定势：必须先将旧系统彻底理解透彻，再开始动手改造。

这听起来合情合理，但在高压交付环境下，这条路径极易导致团队陷入认知泥潭而无法推进。因为对于许多遗留系统而言，“彻底看懂”本身就是一个伪命题。

https://watermelonwater.tech/insights_imgs/10年系统重构54万行代码7.webp)

尤其是运行了十年的老系统，其线上真实表现与最初的设计意图往往早已大相径庭。大量业务逻辑、分支判断和兼容性代码，都是在线上运行过程中逐步演化出来的。如果一味追溯它“原本应该如何设计”，经常会使重构方向越走越偏。

因此，我们本次项目改变战局的第一步，是放弃“先求全面理解”的路线，转而采取了一条更为务实的策略：不追求立即获得完整理解，而是优先还原系统的真实运行时行为。

https://watermelonwater.tech/insights_imgs/10年系统重构54万行代码8.webp)

换言之，我们不再首先追问“它本该如何设计”，而是优先探究：

1. 这个接口当前实际接收哪些参数？
2. 它会经过哪些具体的逻辑处理分支？
3. 它会返回什么样的结果数据？
4. 它会访问哪些数据库表或外部服务？
5. 它会产生哪些副作用（如写日志、发消息等）？
6. 在异常情况下，它的实际表现究竟是怎样的？

我们最终以每个URL接口作为最小单元，进行行为还原。这是一个至关重要的策略转向。因为一旦确立了清晰的行为基线，后续许多工作便有了明确的判断标准：

1. AI生成的新代码是否正确，有了比对基准。
2. 测试用例该如何编写，有了具体依据。
3. 进行差异分析时，有了可靠的锚点。
4. 能够清晰区分哪些是代码优化，哪些是可能改变原有行为的潜在风险。

如果没有这一步，重构工作很容易从“代码迁移”演变为一场“悄无声息的重写”。而老系统重构最忌讳的，并非代码无法产出，而是在无意中改变了原有系统的行为，却误以为自己是在进行优化。

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

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

Experts Mode 核心概念解析

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

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

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

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

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

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

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

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

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

实战案例演示

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

需求描述

我向Qoder提出了如下需求：

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

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

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

就在不久前，国产AI标杆DeepSeek正式推出了其全新的模型迭代，完整版本号为DeepSeek-V3.2-Speciale (02-2026)。官方披露的核心升级点涵盖多个维度：

1. 推理能力实现质的飞跃 - 在数学运算、代码编程、逻辑推演等复杂任务上的表现取得了显著进步。
2. 知识库完成重要刷新 - 模型的知识截止日期已延伸至2025年5月，确保了信息的时效性。
3. 长上下文理解能力精进 - 对多轮、冗长对话的整体脉络与细节把握变得更加精准。
4. 回复质量全面优化 - 生成的答案在准确性与条理性上均达到了新的高度。

然而，上述提升仅是基础。真正让该版本在全球范围内引发强烈关注的，是其在关键性能指标上实现的突破性优势：

1. 推理成本堪称全球最低，每百万tokens仅需0.14元人民币，在全球主流模型中处于绝对领先地位，其成本仅为GPT-5.1的八十分之一。
2. 上下文长度问鼎全球巅峰，支持高达1M tokens的上下文窗口，这意味着模型可以一次性处理相当于《三体》三部曲总和的文本体量。
3. 首字延迟速度行业领先，平均首字输出时间小于0.2秒，其流式响应速度极快，用户体验无限接近人类对话的自然停顿节奏。

综合来看，DeepSeek-V3.2的核心标签可概括为：具备顶级推理能力且价格最亲民的模型、拥有最长上下文处理窗口的模型，以及在国内权威评测中位列第一的模型。

这些特性无疑令人振奋，但更深的期待在于另一个维度。正如行业共识所预示，2026年将成为智能体（Agent）技术大规模应用的元年。作为备受瞩目的核心模型，DeepSeek在此次更新中为Agent能力进行了哪些专项优化呢？

回顾历史，模型针对Agent场景的优化通常聚焦于特定能力：

Agent执行任务最核心的两大能力在于“任务分解”与“工具调用”。

根据DeepSeek公布的部分评测数据：

1. 在天罡评测体系的“任务分解”单项中，得分高达93.5，稳居国内榜首。
2. 在天罡评测体系的“信息抽取”单项中，得分达到93.49，同样位列国内第一。

整体性能可参考下图。不过，目前披露的信息仍显不足，或许需要等待更详细的数据集跑分结果，才能全面揭示DeepSeek在Agent侧所做的深层优化与具体提升：

上个月，Manus1.5的发布，其核心演示点集中在网站开发领域，尽管未明确提及，但几乎直指前端开发。

紧接着，近日Gemini3的推出，网络上各种喧嚣的观点再次指向**前端已死！**前端开发为何屡屡成为焦点，不断面临各种挑战？

从早期互联网萎缩宣称前端已死，到各类SaaS工具平台涌现前端再死，随后低代码、零代码兴起依然前端死，再到Coze、Dify出现还是前端死，以及Cursor、Claude Code问世自然也是前端死……

前端似乎成了众矢之的，如今各公司领导者也似乎采纳了这些观点，不久前某公司前端团队裁员比例高达50%，这已非危言耸听，前端领域确实面临严峻压力。

因此，我们不得不深入探讨：AI是否真的意图取代前端开发？

AI对前端的冲击：范式和数据

首先，AI对程序员，尤其是前端开发者的冲击如此直接和剧烈，核心原因在于范式和数据。

AI模型对开发者的编码习惯有深入理解，同时各种开发框架已相当成熟。

自ChatGPT问世以来，能够稳定消耗算力的文本类AI应用，主要集中于即时聊天、AI客服以及AI编程三大领域。

其中，AI编程的快速发展，离不开全球开源社区构建的庞大代码语料库。GitHub上超过2亿个开源仓库，为代码模型的训练提供了海量、结构化且高质量的“教材”。

将视角聚焦于前端，我们会发现一个关键事实：业务逻辑的可穷举性。

前端的业务逻辑，尤其是UI组件与交互模式，相对规整且高度模式化。经过数十年的演进，这些模式在GitHub上已被近乎完全穷举。这意味着：训练一个精通前端开发的AI，所需的数据是完全充足的。

相比之下，后端领域虽有大量代码，但企业的核心业务逻辑代码通常不会开源，导致语料在深度上存在缺口。至于芯片设计等更底层领域，由于缺乏开源语料，AI辅助编程几乎难以开展。

因此，我们必须承认：正是由于前端业务逻辑的相对简单性与开源语料的极度丰富，使得AI在前端领域能够快速达到“优秀”水平，从而对前端开发中“代码生成”这一环节构成了最直接的冲击。

这一冲击在当前工具生态中已显现端倪。从GitHub Copilot到Cursor，从Claude Code到通义灵码，AI编程助手正快速渗透前端开发的日常工作流程。

业界估计与我的实践经验一致：前端开发中约60%以上的标准化任务已可实现高度自动化，包括组件生成、样式编写、基础业务逻辑实现等。

那么，前端是否即将被淘汰？常说的AI对前端的10倍效率提升究竟体现在何处？

AI在前端开发中的效率提升：理想与现实

根据个人实践：AI确实能在某些场景下实现10倍甚至100倍的效率提升，但在真实业务开发环境中，实际的效率提升通常低于60%。

为何存在如此大的差距？接下来，我们详细拆解这一问题。在许多AI的宣传案例中，经常出现以下示例：

输入提示词：  
“帮我实现一个数独游戏，使用JavaScript实现。”

大约30秒后，Cursor即可完成从需求分析、问题拆解、编码实现到效果预览的完整流程。示例效果：

这个数独游戏不仅功能完整，还支持响应式布局。

如果让开发者手动编码实现，大约需要4-8小时，而Cursor仅需30秒，提升的效率何止10倍？甚至达到100倍。

这类场景的确容易让人认为AI具备颠覆性的效率提升。但我们需要剖析这些案例的特点：

1. 需求清晰、任务简单：数独游戏的规则固定，AI只需基于已有训练数据生成代码，而不需要额外的上下文理解；
2. 代码质量不重要：在展示“AI速度”的场景中，代码的健壮性、可维护性往往被忽略。即使生成的代码不符合团队规范、不易扩展，也不会影响展示效果；
3. 极端场景的放大：一些演示视频可能会挑选AI表现最优的时刻，而忽略它犯错的情况。例如，在AI生成UI代码时，可能会遗漏复杂交互的细节，导致实际使用时需要大量修改；

这种能力对于非专业开发者快速验证MVP的门槛大幅降低。

然而，这仅仅是理想化场景，现实中的业务开发却远比这复杂得多。

实际业务开发中的AI应用分析

为了分析AI在业务开发中的实际提效，我们先拆解前端开发的典型流程，以及各环节的大致时间占比：

从表格可以看出，占据开发者较多时间的环节主要是：

1. 需求分析
2. UI还原与组件开发
3. 业务逻辑实现
4. API集成与调试

接下来，我们分析AI在这些环节中的实际表现：

需求分析：AI介入难度极大

原因很简单：

1. 需求分析涉及业务背景、上下文理解、利益取舍，需要大量主观判断。
2. 需求变更频繁，AI很难高效处理动态变化。
3. 许多需求难以用自然语言准确描述，导致AI生成的内容不够精准。

结论：AI在需求分析环节几乎无法发挥作用。

UI还原：能力有限，仍需大量人工调整

当前AI可以基于Figma设计稿或截图生成UI代码，但仍然存在较多问题：