得物分享Agent进入企业研发全链路实践
在 AICon 全球人工智能开发与应用大会上，InfoQ 邀请得物资深技术专家白忠魏带来演讲，分享得物推荐团队在企业级复杂系统中推进 AI 研发实践的思考与经验。
演讲中，白忠魏从得物推荐的业务与工程场景出发，围绕“如何让 AI 从写代码走向完整研发迭代”这一问题，介绍了团队在 PDCA 全链路、七阶段护栏、TPRD、研发环境与测试验证、AI 推荐质量评测、三层知识体系，以及 Highway + ATV 混合 Agent 架构等方面的探索，并分享了阶段性的实战数据。
以下为演讲内容，经 InfoQ 整理。
一、从 AI Coding 走向 AI 全链路
目前，AI Coding 已经能够较好地完成从 0 到 1 的项目和相对简单的编码任务。在部分场景下，它交付的结果甚至会超出工程师的预期。对于这一点，行业内已经形成了较为明确的共识。
但在企业级项目中，AI 面临的环境要复杂得多。如果面对的是一个运行了十几年、代码量庞大的老项目，或者一个横跨多个系统和业务层级的超大型项目，AI 能否准确理解需求、控制影响范围，并对最终结果负责，仍然是一个需要持续探索的问题。
得物推荐也在推进类似实践。我们的目标并不只是让 AI 写代码，而是将 AI Coding 扩展为一套覆盖需求、开发、验收和问题反思的 AI 全链路方法。
得物推荐本身是一套较为复杂的系统。用户进入得物后，看到的推荐内容大致可以分为两部分：一部分是商品交易推荐，接近淘宝、京东的场景；另一部分是帖子和内容推荐，接近内容社区或短视频平台的场景。
整套系统包含召回、粗排、精排、推荐引擎以及大量上下游服务，是一个历史较久、规模庞大的复杂工程。如何让 AI 真正进入这类系统的研发流程，正是我们这次实践的出发点。
二、AI 驱动的研发迭代飞轮
从软件工程视角看，一次完整的研发迭代可以抽象为 Plan、Do、Check、Act 四个阶段，也就是常见的 PDCA 循环。
Plan 是需求对焦。需求开始后，产品经理和技术团队需要围绕目标、边界、上线时间和验收标准达成一致。这个阶段的主要产出包括 PRD、研发排期，以及判断需求是否达到预期的成功标准。
Do 是开发实现。这一阶段不仅包含编码，还包括上下游联调、单元测试、集成测试和功能验收，最终产出代码、单元测试及发布方案。
Check 是效果校验。需求开发完成后，需要经过测试验证、灰度发布和指标观测，判断功能上线后的真实效果。
Act 是分析、反思和问题排查。对于推荐业务而言，功能上线并不意味着研发过程结束。团队还要继续观察业务指标，处理体验类和功能类问题；一旦出现 Bad Case，便需要分析原因，并将结论带入下一轮迭代。
目前，多数团队的 AI 实践主要集中在 Do 阶段，也就是让 AI 写代码。在需求产出、测试验收、业务效果判断，以及最后的 Bad Case 分析和问题反思中，AI 的参与程度仍然有限。
我们希望做的，是将这些环节真正串联起来，让 AI 不只参与开发，而是进入完整的 PDCA 循环。
全链路 AI 化的四个前提
如果希望 AI 参与完整研发流程，那么每一个阶段都必须具备清晰的约束和判断标准。
在 Plan 阶段，需求必须足够明确，目标和边界不能反复摇摆。如果一开始的目标是 A，执行过程中又不断变成 B，后面的开发与验收就无从谈起，AI 也无法稳定执行。
在 Do 阶段，AI 的执行过程应尽量减少中断。理想状态下，工程师给出任务后，AI 可以持续运行较长时间，而不是频繁因为环境、依赖或信息不完整而向人提问。虽然距离完全自主执行仍有差距，但研发环境应尽可能降低 AI 的等待成本。
在 Check 阶段，结果必须能够量化。AI 和推荐系统在一定程度上都具有黑盒特征，我们很难了解内部每一步的全部细节，因此需要通过测试结果和后验数据判断产出是否可靠。
在 Act 阶段，经验必须能够复用。过去踩过的坑不能在后续任务中反复出现。我们会要求工程师不要在同一个问题上重复犯错，对 AI 也应当建立同样的要求。
最终，我们希望提高 AI 在整个需求链路中的渗透率和产出采纳率，同时缩短研发迭代周期。很多团队目前按照周或双周进行迭代，如果 AI 能够参与完整链路，双周迭代有机会缩短到周，周迭代则有机会缩短到天。更理想的状态是，一轮任务完成以后，系统能够自动进入下一轮，而不再受固定迭代周期的限制。
好的 Harness，是环境而不是铁笼
可以借用《楚门的世界》理解 AI Harness 的作用。
电影中，楚门生活在一个巨大的摄影棚里。摄像头、演员、天幕和围墙都在限制他的行动，但真正让他不敢离开小岛的，其实是水。童年经历使他对水产生了强烈恐惧，因此水并不是一面写着“禁止离开”的墙，而是成为了环境本身。
好的 AI Harness 也应当如此。
Harness 的作用不是在 Prompt 中堆叠大量“不要”“禁止”和“必须”，而是搭建一个让 AI 自然按照预期方式运行的环境。
如果为 AI 增加过多显性的限制，它反而可能因为无法同时满足所有条件而停止执行。更有效的方式，是把约束融入环境、工具和验证流程中，让 AI 在执行任务时，自然按照既定方式运行。
基于这一思路，我们按照 PDCA 四个环节进一步抽象出了七阶段护栏，并从护栏能力、护栏载体和约束逻辑三个方面设计整套全链路体系。
在这套体系中，人仍然承担着不可替代的作用，尤其是在技术方案评审，以及 Check、Act 两个阶段。
技术方案评审是 AI 开始长时间自主执行之前，最后一个能够由人进行双层 Review 的位置。AI 真正开始编码前，需要先提交计划采用的方案，由工程师判断其对需求的理解是否准确、技术方向是否存在偏差。否则，AI 可能沿着错误方向持续运行很长时间。
Check 和 Act 阶段则不应只关注线上稳定性。目前很多团队更擅长判断系统是否报错、接口是否超时、服务是否异常，却缺少对业务效果的智能化判断。如何让 AI 参与业务结果分析，也是全链路建设中需要继续完善的能力。
三、在 Plan、Do、Check、Act 中建立工程护栏
Plan：用 TPRD 和 Contract 把需求变成可执行边界
日常需求讨论通常采用自然语言。自然语言的问题在于，即使所有人都认为自己理解了，同一句话在不同角色眼中仍然可能具有不同含义。
为此，我们在 PRD 之后增加了一层 TPRD，并在其中引入 Contract。Contract 用来提前明确需求会影响哪些模块、优化目标是什么、应该朝哪个方向调整，以及有哪些技术约束不能突破。
技术团队也会将需要明确的技术条件提前反馈给产品同学，使需求得到更加结构化的描述。这样，AI 真正开始执行时，拿到的就不只是一段自然语言，而是一套可以理解和遵守的边界。
TPRD 是后续所有阶段的围栏。目标和方向如果不清楚，代码写得再快、测试做得再完整，也可能只是在错误方向上努力。
我曾经带一位同学去开会，原本应该去 5 号楼，结果却走到了 4 号楼。那位同学对我说：“如果方向走偏了，怎么努力都没有用。”这句话也可以概括我们建设 TPRD 的核心原因。
例如，产品提出一个需求：“用户点击不感兴趣后，少推荐一些类似商品。”这句话看起来很容易理解，但从技术角度继续拆解，就会发现其中包含大量待澄清的问题。
用户不感兴趣的究竟是这个商品、这个品牌，还是所属类目？他可能只是不喜欢商品图片，也可能不喜欢内容作者。“少推荐一些”也可能有多种含义：是以后完全不再出现，还是三天内减少曝光？是几个小时内降低频率，还是长期降低权重？如果用户不喜欢某个品牌，系统又应该在什么条件下重新恢复推荐？
如果这些问题没有在需求阶段明确，AI 后续无论采用什么方案，都可能与产品真正想要的结果产生偏差。
因此，完成 PRD 后，我们会通过 TPRD 将需求进一步拆解为多个 EP，也就是具体的功能点。对于每一个 EP，团队都会明确需要修改的位置、实现目标、约束条件、实验方式和验收标准。
TPRD 负责把需求拆解成可执行的 EP，Contract 则负责为每一个 EP 划定边界。这些内容共同构成后续开发、测试和验收阶段的“北极星”。
Do：通过三类基础设施减少 AI 等待
进入 Do 阶段后，需要解决的核心问题是：如何让 AI 持续执行更长时间，而不是不断因为环境、依赖或验证问题停下来。
围绕这一目标，我们主要建设了三类基础设施。
第一类是沙箱隔离。大型企业项目通常依赖复杂的中间件、下游服务、内部环境和线上数据，本地机器很难完整还原。如果 AI 每写一点代码，都需要工程师部署到其他环境，再拉取日志、检查结果，它就不可能实现真正的自主运行。
因此，我们通过本地可运行环境、代理或预发等方式，让 AI 和工程师可以一边修改代码，一边执行并获取日志。对于无法在本地完整运行的能力，则通过代理或预发环境进行补充。这样，AI 完成一轮代码修改后，就可以立即执行和校验，不必等待工程师到其他系统中获取反馈。
第二类是 UTD，也就是单测驱动。大家比较熟悉的是 TDD，即先通过测试描述功能，再根据测试完成代码。但 AI 本身是一个黑盒，由 AI 生成的单元测试同样可能存在偏差。如果 AI 一次生成大量测试，工程师仍要投入很多时间判断这些测试是否真正有效。
我们的思路是通过数据形成验证闭环。例如，AI 修改代码前，线上已有 2500 个用例；修改后，AI 又新增了 100 个用例，总数变成 2600 个。如果重新执行后发现其中有 400 个不通过，AI 就可以根据数据反思：代码是否改错、是否影响了原有逻辑，或者是否引入了不符合预期的行为。
我们不仅让 AI 编写单元测试，也让它根据已有测试和新增测试的执行结果，判断自己的修改是否可靠。
第三类是外部依赖 Mock。推荐系统存在大量下游服务和随机条件，同一个用户每次刷新，看到的推荐结果都可能不同。如果外部输入一直变化，就很难准确判断本次代码修改究竟造成了什么影响。
因此，我们会通过 Mock 将可能变化的下游依赖静态化，包括推荐引擎、下游服务以及具有随机性的条件。只有输入和外部依赖保持稳定，系统才能准确评估一段代码影响了哪些范围、造成了多大变化。
这三类基础设施最终服务的不只是 AI，也服务于工程师。Harness 是给 AI 使用的，同时也是为人建设的。AI 可以在本地编码、运行和验证，工程师同样不必反复等待联调环境。
Check：用 AI 模拟用户，把推荐质量评测前置
推荐系统具有比较明显的黑盒特征。一项功能上线后，我们通常只能根据用户后续的行为，判断这次调整究竟是好还是不好。
传统验收往往依赖人工评测。测试人员需要观察推荐结果的新颖性、质量和画风，判断这些内容是否符合用户兴趣。这一过程非常消耗人力和注意力。我们实际测试过，一名同学每天工作 8 小时，最多大约只能评测 200 条结果；继续增加评测量后，人的注意力和判断质量都会明显下降。
因此，我们尝试用 AI 模拟真实用户画像，对上线前后的推荐结果进行评审。团队会预先定义新颖性和质量标准，再由 AI 按照 L1-L5 对推荐结果进行分级。这样，功能正式上线前就可以完成推荐质量的前置审核，评测也能够逐渐从一次性人工工作转变为 7 × 24 小时的常态化运行。
在这套平台中，每一个 AI 评审员都对应一类用户画像。画像中包含性别、年龄、购买力和人生阶段，也会结合季节、节日等时空信息，以及用户是否浏览、购买过某类商品等历史行为。
AI 会站在特定用户的角度，判断其对当前推荐结果的兴趣，再根据预先设定的维度进行评分。
目前，AI 的评测准确率还没有完全与人工对齐，但人工评测本身同样存在偏差。不同的人面对同一组推荐结果，也可能给出不同判断。更重要的是，AI 的判断过程和评测结果可以被完整保留下来，再由专家进行抽样和二次审核，最终形成可复用的评测资产。
例如，秋季适合推荐大闸蟹；进入冬季后，可以面向部分价格敏感型用户推荐反季服装。这些经验过去可能只存在于少数专家的认知中，现在则可以逐渐沉淀为系统能够复用的知识。
Act：让问题排查结果沉淀为 Story
在 Act 阶段，我们建设了线上问题排查工具“推查查”。线上监控发现异常，或者业务侧出现舆情 Bad Case 后，问题会进入推查查，由人工和 AI 同时进行排查。
问题处理完成并不代表流程结束。团队还会继续复盘问题产生的原因、排查过程中走过的路径、真正有效的信息，以及未来遇到同类问题时如何更快获得答案。
复盘结果最终会沉淀为 Story。
这里的 Story 不是 Skill。它并不是一段等待 AI 下次重新理解的经验总结，而是要将已经验证过的问题排查路径转化为更加确定、可编码、可重复执行的方案。
通过这些阶段的建设，我们尝试让 AI 从产品提出需求开始，一直参与到开发、验收、效果判断、线上问题诊断和经验反思。不过，当 AI 真正进入完整链路后，知识丢失、随机漂移和路径不透明等问题也会随之暴露出来。
四、用 CDD 和三层知识体系解决知识丢失
第一个问题是知识丢失。大模型的上下文容量必然有限，同一类任务上周已经向 AI 解释过一次，下周仍然可能需要重新说明。工程师在使用 AI Coding 时，经常会遇到类似情况：之前已经交代过的内容，AI 在后续对话中再次忘记，导致沟通不断重复。
第二个问题是随机漂移。即使任务和 Prompt 完全相同，AI 今天和明天也可能采用不同的处理方式。我曾要求 AI 调用一个工具，它反馈工具已经执行，并返回了响应结果。但通过调用日志检查后发现，它实际上并没有调用工具，所谓的结果是它自行 Mock 出来的。在企业级应用中，这类问题具有很高的风险。
第三个问题是路径不透明。Agent 本身仍然具有黑盒特征，出现问题后，团队未必知道它究竟卡在哪一个步骤。很多时候只能反复调整 Prompt，却很难迅速定位根本原因。
这些问题看似来自模型，但要解决它们，首先需要回到工程自身。如果人都无法从代码库中找到准确知识，AI 同样不可能稳定理解系统。
从代码注释切入知识建设
程序员经常面临一个矛盾：一方面希望别人留下完整文档，另一方面又不愿意自己维护文档。时间一长，代码库中的文档要么缺失，要么与代码不同步，真正遇到问题时很难依赖。
代码本身也可能存在歧义。例如，一个变量名是 isCannotShow，值却等于 false。即使是工程师，也需要经过多层判断，才能确认此时究竟应该展示还是不展示。
如果工程自身的知识表达都不清楚，一开始就要求 AI 自动解决这些问题，同样很难取得稳定结果。
我们的做法是 CDD，也就是 Comment-Driven Development。先让 AI 补注释，而不是一开始就让它补文档。
之所以从注释开始，是因为注释距离代码最近。AI Coding 时，AI 可以同时读取代码和注释，理解常量含义、局部逻辑和设计意图。这些知识可以跟随代码一起被读取，也更容易在代码发生变化时及时更新。
但注释只能解决局部代码的知识问题，不能代替模块设计文档，也不能承担团队级行为约束。因此，CDD 并不是把所有知识都放进注释，而是从最贴近代码的一层切入，再将不同类型的知识组织为完整的三层体系。
L1、L2、L3 各自解决什么问题
企业级系统中的知识具有不同的作用范围：有些是任何任务都不能突破的团队规则；有些用于解释模块为什么这样设计；还有一些需要跟随代码持续更新。
基于这一差异，我们把 AI Coding 所需的知识组织为 L1、L2、L3 三层。这里的层级不是简单的重要性排序，而是同时区分约束强度、知识范围和 AI 的取用方式。
L1 是不可逾越的行为边界。这是作用于整个研发过程的团队级硬约束。例如，写代码必须配套单元测试，或者团队要求代码注释率必须超过 30%。无论 AI 修改哪个模块、选择什么实现方式，都不能突破这些规则。L1 不负责解释某段代码如何运行，而是规定 AI 在研发过程中始终必须遵守什么。
L2 是模块级的设计知识。这一层用于解释模块为什么这样设计，并沉淀关键依赖关系。它通常需要架构师和技术负责人参与梳理。由于模块设计不会每天变化，这部分知识的更新频率相对较低，可能半年才调整一次。但当 AI 处理跨模块需求或者复杂问题时，L2 可以提供必要的架构背景。
只看一段代码，AI 可能知道这里调用了某个接口，却不知道为什么必须这样调用，也不知道该模块与其他模块之间存在什么约束。L2 的作用，就是补足这些上下文。
L3 是与代码直接关联的注释知识。这是距离代码最近的即时知识，会随着代码变化而更新，也是 AI Coding 处理具体任务时最先接触到的内容。它主要帮助 AI 理解“这个常量是什么意思”“这段逻辑在做什么”“为什么这里需要这样处理”等局部问题。
这三层知识在执行时，并不是让 AI 机械地从 L1 读取到 L3。L1 作为硬边界，在整个任务执行过程中始终生效；AI 处理具体任务时，会先结合代码读取 L3，如果局部注释不足以解决问题，再启用 L2，查看模块设计、关键依赖以及周边关联模块。
换句话说，L3 回答的是“这段代码是什么、在做什么”，L2 补充的是“这个模块为什么这样设计、与哪些模块相关”，L1 约束的则是“无论采用什么方案，都不能违反什么”。
通过这种方式，知识不再集中在一份容易过期、与代码分离的大文档中，而是根据不同作用范围，放在距离使用场景最合适的位置。完成三层知识建设后，AI 才有可能回答更多需求阶段的问题，例如某项功能之前是否已经有人做过、当时如何实现，以及上线后的实际效果如何。
补齐注释后，准确率从约 52% 提升到 90% 以上
我们对这套知识体系的效果进行了一些验证，测试问题大致分为简单问题和复杂问题。
简单问题包括“这个常量是什么意思”“这段代码在做什么”。过去，面对缺少注释的代码，AI 只能根据变量名和上下文猜测；补齐注释后，这类问题通常一次就能得到较为准确的回答。
复杂问题可能横跨多个系统，甚至工程师自己也没有现成答案。测试结果显示，在没有注释的情况下，AI 回答问题的整体准确率约为 52%；补齐注释后，准确率可以达到 90% 以上，追问次数和总体 Token 消耗也随之下降。
对于复杂问题，单次调用的 Token 数量可能有所增加，因为注释本身也需要占用上下文。但从整个问题解决过程来看，总体 Token 消耗仍然下降了。原因在于，AI 获得了更多有效知识，不再需要反复追问工程师，也减少了在错误路径上的无效尝试。
单次读取的信息增加了，但解决问题所需的对话轮次减少了。
五、用混合 Agent 架构对抗黑盒与随机漂移
80% 走 Highway，20% 走 ATV
解决知识丢失以后，还需要继续处理 Agent 的黑盒特征和随机漂移。为此，我们在推查查中采用了一套混合 Agent 架构，其设计思路来自二八定律。
对于 80% 的高频问题，我们希望系统具备较强的确定性，这条路径被称为 Highway，也就是高速公路。剩余 20% 的问题通常属于没有现成解决路径的长尾场景，这部分进入 ATV 路径，允许 AI 进行更加自由的探索。
大部分已知问题走 Highway，通过确定性路径快速解决；少量未知问题走 ATV，由 AI 自主探索。
系统最上层设置了意图识别模块。问题进入后，系统首先判断过去是否出现过类似问题：如果已经出现过，就直接进入 Highway；如果从未出现，则进入自主探索路径。
在两条路径下面，我们还设计了一个进化层。今天进入 ATV 的长尾问题，在经过 AI 与人的多轮对话并得到解决后，会通过反思重新沉淀，最终进入 Highway。随着问题不断积累，Highway 中的确定性能力会持续增加，需要 ATV 自由探索的问题则会逐渐减少。
人和 AI 都会猜测，代码不会
“出去买两根香蕉，如果看到卖苹果的，就买四个”是一句经常被用来讨论自然语言歧义的话。
有人会将它理解为买两根香蕉，如果看到苹果就再买四个苹果；也有人会理解为看到苹果后，把香蕉的数量改为四根。自然语言存在歧义，人会根据上下文补充信息，AI 同样会进行猜测。
但如果条件被写成代码，结果就会变得确定。假设代码明确规定，如果看到卖苹果的，就把香蕉数量改成四根，那么这段代码无论运行一遍还是一万遍，结果始终都是四根香蕉。
人会理解和补全，AI 也会理解和补全，但代码不会。
这正是 Highway 的核心思路：把所有已经明确的问题转化成代码。
Highway：将已知问题全部代码化
对于已经出现过的问题，我们会将排查过程编码成确定的执行逻辑。每类问题都有对应代码，也有明确的适用场景。
问题进入系统后，意图路由首先判断它是否属于已知问题。如果能够匹配，就不再让 AI 重新推导，而是直接执行经过验证的代码。
这样做可以显著提高确定性。如果每次都让 AI 根据一段 Skill 重新理解问题，它仍然可能选择不同的工具、不同的执行顺序，并得到不同结果。代码一旦经过验证，则能够按照固定路径稳定执行。
对于已知问题，不要让 AI 每次重新思考，而是先让它执行已经验证过的代码。
ATV：未知问题先探索，再通过反思进入 Highway
对于无法匹配已知路径的长尾问题，我们会允许 Agent 自主探索。实践中，团队尝试过 OpenClaw，也就是大家常说的“龙虾”，也使用过 Hermes 等方式，并向 Agent 提供相应的 Skill、MCP 和工具调用策略。
这个过程更像一名工程师面对未知问题：他可能需要查看多个系统、调用不同工具、验证不同假设，并与其他人进行多轮沟通，才能逐渐确定最终答案。对于未知问题，暂时无法要求 AI 一开始就具备完全确定的执行路径，先让它自主探索是更加现实的选择。
但如果每次遇到类似问题，都重新进行一遍探索，效率仍然会很低。因此，ATV 之后还有一个重要的反思过程。
一个长尾问题经过 AI 和人的多轮对话并得到解决后，我们会在每天晚上触发反思。反思的目的并不是让 AI 再写一段 Skill，告诉未来的 AI 遇到类似问题时应该怎么做，因为 Skill 仍然需要 AI 在下一次执行时重新理解，只要存在重新理解，就可能产生新的随机性。
我们要求 AI 将当天已经解决的问题重新转化成代码。
随后，由人根据 Checklist 对生成的代码进行检查，并与 AI 共同完成最后的校验。通过验证后，这段代码就成为新的 Story，进入 Highway。原本属于长尾范围的问题，下一次再出现时，就可以进入确定性路径。
这也是 Story 和 Skill 的核心区别：Skill 是一段需要 AI 再次理解的能力说明，Story 则是经过实际问题验证并被固化为代码的执行经验。
我们的经验是，代码永远是稳定的。代码无法预先解决所有未知问题，但只要一个问题已经被解决并完成验证，就应尽量将其过程固化下来，使经验从“可参考”转变为“可重复执行”。
六、阶段性实战结果
这套体系建设的时间还不算特别长，但已经取得了一些阶段性结果。目前，AI 在需求链路中的渗透率约为 30%，相比过去，AI 在完整研发链路中的参与度已经明显提升。
当然，并不是所有需求都适合让 AI 参与。例如，只需要修改一行配置时，工程师自己很快就能完成，没有必要为了使用 AI 而强行引入一套复杂流程。
我们的目标不是追求形式上的 AI 覆盖率，而是在真正适合的环节提高 AI 的参与度、产出采纳率和交付效率。
在问题排查方面，整体效率得到明显提升，处理时长相比过去下降了约 80%，部分场景的提升可能更高。
传统做法通常将经验沉淀为 Skill，下一次遇到问题时，AI 仍然需要经过多轮理解、规划和工具调用。将已知问题代码化后，一轮执行就可以跑完，处理速度可以接近人工，部分场景甚至比人工更快。
结语：让人和 AI 在同一个“梦境”中工作
OpenClaw 提出过一个很有意思的概念——“梦境”。这让人联想到庄周梦蝶：究竟是庄周变成了蝴蝶，还是蝴蝶变成了庄周？在梦境中，双方的边界已经不再清晰。
AI Harness 也是如此。在 Harness 中执行任务的究竟是 AI 还是人，并不是最重要的问题。AI 会遗忘、会犯错，人同样会遗忘、会犯错；人需要沉淀经验，AI 也需要建立自己的经验体系。
真正重要的是，在“梦境”的边缘搭建好 Harness，让执行者自然理解当前环境，遵循已经定义好的边界，并能够持续验证、反思和积累经验。
当需求边界足够清晰、开发过程能够验证、业务效果可以量化、问题经验可以复用时，AI 才能从一个写代码的工具，真正成为企业研发迭代飞轮的一部分。
会议推荐
QCon 全球软件开发大会·2026（上海站）现已正式启动。本届大会聚焦 Harness AI 时代的工程实践，从「构建 AI」到「驾驭 AI」，围绕 AI Native 架构、Agent Runtime、AI Infra、Agent 安全与可观测、Loop Engineering、具身智能与世界模型 等热门技术方向，邀请全球技术社区与产业一线实践者，共同分享 AI Native 时代最具价值的工程经验。