Raif Agentic Development：Raiffeisenbank 的 AI 开发转型

大家好。我叫 Andrey Usavka。我负责 Raiffeisenbank 企业业务融资开发方向。

我目前的主要重点是我们业务单元的 AI 转型。

这意味着重设计生产和运营流程。这意味着理解我们该将哪些技术部署到哪里，如何重新审视角色的结构和内容，以及为实现我稍后会谈到的雄心勃勃目标所需要做的许多其他事情。

我希望大家从这次分享中带走三个关键观点。

第一，通常不应该把 AI 植入现有流程，而应该围绕 AI 重构流程。
第二，是 Output 和 Outcome 的两难问题。也就是如何选择能够激励你重设计现有流程的目标。
第三，是智能体犯错。它不是让你亲自动手替它把工作做完的理由，而是应该进一步调优系统的理由。

2025–2026 年典型的 GenAI 技术落地是怎样的？

通常，我们会选取一个产品开发团队，为每一种角色配备自己的 AI 智能体。

产品经理会获得 ChatVRD，
后端开发人员会获得 Codex 或 Claude，每个角色都会立刻发现，自己单位时间内可以产出多倍的 Output。产品经理在同样时间内会有更多 spec，后端开发人员会有更多代码。看上去，似乎每一个步骤都加快了。

但局部加速并不会汇聚成业务可感知、客户可感知的效果。为什么会这样？因为角色之间、人员之间存在队列、等待和交接，它们会扭曲并丢失一部分信息，并导致返工。因此，我们的整体效率并没有提升。

如果看宏观经济统计数据，可以看到每小时产出在增长，而总体生产率——本质上是超出投入资本和人力之外的效率——其增长大致处在危机前年份的零增长区间。上世纪 80 年代末，经济学家 Robert Solow 注意到：计算机时代无处不在，唯独劳动生产率统计数据中看不到它。于是 Solow 悖论出现了，而我们现在，本质上正在看到它的第二次再现。

再来看看上世纪 90 年代初流程工程中的一个案例也很有意思。IBM Credit，为 IBM 客户的购买提供融资。经典的信贷流程：登记贷款申请、信贷分析、确定条件等等。涉及多个部门、多个关键角色。研究人员相应地考察了，在这一流程中所有员工实际工作的累计时长。结果发现，只有一个半小时。然而，从提交申请到获得结果，客户需要等待 144 小时，接近一周。结果发现，即使把每位员工的速度提高一倍，客户也只能节省 45 分钟，相比 144 小时，这一点节省微不足道。其中一位研究这个案例的研究人员提出了一个有意思的观点：人们试图用计算机自动化本应直接废除并彻底重设计的流程。IBM Credit 实际上甚至没有借助计算机就做到了这一点。他们本质上把参与流程的所有角色合并为了一个角色。我这里是在暗示上一次分享中提到的产品工程师。这最终让客户的 144 小时缩短为 4 小时。

由此得出结论：AI 转型的单位不是员工、不是角色、也不是智能体。转型的单位是围绕可衡量结果的端到端流程。 与上世纪 90 年代相比，我们现在拥有了哪些能力？除了显而易见的、计算机革命已经经历了许多轮迭代之外，还可以注意到：任何公司中的任何业务流程，本质上都是信息在决策节点之间的一次旅程。 其中一部分是某种标准的经典软件，另一部分则是人。

为什么是人？因为以前只有人能够接收非结构化信息，运用自己的专业知识和某些没有被数字化的积累经验，并得出决策。

随着大语言模型的出现，这类决策节点也可以被自动化，因为 LLM 很擅长完成这项工作。 因此，我们不仅有机会借助 AI 转型业务流程，也有机会围绕 AI 转型业务流程。

不过，这里出现了一个问题：我们如何判断正在实施的转型是有效且有价值的？这里我要提醒大家管理学中经典的 output 与 outcome 两难问题。它们有什么区别？Output 是某些表明工作正在推进的指标或证据。可能是我拿到 AI 智能体后所感受到的主观加速感。也可能是 merge request、pull request 的数量，或者由智能体写出的代码行数。所有这些对于确认工作正在进行是必要的，但它们并不能保证正在进行的工作是有价值的，也不能保证它为客户带来了有益效果。另一方面，outcome 是我们真正想要获得的效果，例如我们编写代码时所追求的效果。它是客户能够感知到的某种变化。这个两难问题在目标设定时经常以下述方式显现。你会看到一个团队或整家公司给自己设定目标：在所有团队中引入 AI。或者，例如，构建 harness，构建平台，或者在平台 offer 中加入某些能力。这会导致什么？确实，AI 被引入了所有团队，平台、harness 等也确实建成了。但除了我们建成了某个东西以外，它带来了什么效果，往往并不清楚。多数情况下，业务指标仍然和建设之前处于同一水平。

而 outcome 目标的表述则不同。例如，我们可以说，希望客户请求的任何变更、任何功能，客户都能在不到 24 小时内获得。 例如，这就是我们的团队和公司所瞄准的 outcome。我们希望客户所需的任何变更，都能在不到 24 小时内得到。但更进一步，我们希望这项变更能够自主实现，无需人参与。 我们还希望质量和可靠性不受影响。

我们目前以简化方式计算 time to market：从在 Jira 中创建任务到相应变更落地生产环境。 这意味着，这一段路径覆盖了 discovery 流程的一部分。但目前 discovery 流程中相当重要的一部分仍在这一衡量范围之外。我们会在完全自动化整个 delivery pipeline 后再更多地聚焦它。而在自动化方面，我们已经取得了不错的结果。特别是，由于重设计了开发流程，我们将 time to market 的中位数降低了 36 倍，将第 85 百分位降低了 40 倍以上。现在，超过 50% 的任务能够在不到 24 小时内自主完成，而融资方向中全部产品开发工作的 85% 都已经通过智能体流水线进行。

在我看来，我们为此走了相当长的路。可以在这张图上看到。顺便说一下，这里是对数刻度。早在 2025 年，我们就已经能够使用前沿模型，也有 AI 智能体。但如图所示，这并没有使我们的 time to market 大幅降低。直到八月之前，它本质上都是 flatline。八月发生了一些事情，我们的 time to market 戏剧性地下降了。

可以看到它与下方图表的相关性：从八月起，由智能体流水线执行的任务占比急剧上升，并且还在继续增长。我希望到年底能达到 100%。你可能会问：我们是不是以质量为代价买来了速度，或者是不是以某种特殊方式拆分了任务？但不是这样。我们为 time to market 设置了反向指标。当然，我们同时跟踪质量、可靠性，以及任务的拆分方式。这里重要的是，defect rate 大致保持在和以前相同的水平。事实上，回滚和 hotfix 甚至下降了一半。从变更规模来看，可以通过文件数、代码行数等进行衡量。我们看到这些指标也大致维持在引入智能体流水线之前的水平。

为了理解八月到底发生了什么重要的事情、为什么产生了如此戏剧性的效果，需要解释一下我们如何看待 harness 这个概念，以及它对我们而言有哪些类型。我们在宏观层面上，例如将其分成两类：inner harness 和 outer harness。Inner harness 本质上就是 OpenCode、Codex、Claude Code 等等。也就是你可以下载、购买、在本地安装并使用的一切。

Outer harness 是把许多智能体转变为一个生产系统、转变为工业化开发的东西。 什么是工业化开发？它包括工程实践、风格、质量、安全性、可靠性。它包含贵公司习惯于如何开展开发流程的一切。这种专业知识无法购买和安装。它属于你们，且只有你们知道它应当如何为你们工作。我们的 outer harness，我们称其为 Atomic，它本质上将所有这些专业知识实现为可执行的流程。也就是说，它不是什么 handbook、说明文档之类的集合。它们全都属于一台统一的、动态的机器。而这台机器，即这个 outer harness，本质上实现了一份生产契约。 生产契约是对五个关键问题的回答：

谁来设定目标，
自主性的边界是什么，
流程中哪些检查是强制性的，以及它们如何执行，
我们的 definition of done 是什么，以及
我们如何应对、如何响应运行过程中出现的错误。

接下来我会更详细地介绍其中每一个问题。对我们而言，关键变化之一是：我们将团队中原有的所有专业化角色替换为一个工程角色。这就是 product engineer。

以前我们有后端开发人员、前端开发人员，测试人员和分析师很久以前就已经没有了，但原则上，随着 LLM 的出现，很明显：只要具备足够的工程专业能力，至少具备一部分 computer science 能力，任何工程师都可以成为通才。 我们的产品经理设定目标。本质上，这意味着他说明：我们为谁做、为什么做、希望推动哪项指标。 而 product engineer 接过产品经理带来的这个意图，与智能体一起将其转化为规格说明，交给智能体系统实现，并对其进行验收。 我们将工程师的规模能力提升了数倍。也就是说，如果以前我们给后端工程师 Codex 或 Claude Code，他就会变成流水线上一名借助强力电动工具的装配工，这名装配工亲自与这个电动工具一起完成最终产品的大部件装配。也就是说，一旦他出了什么事，或者我们想以某种方式扩展这个流程，我们仍然会受制于一个 bottleneck，也就是人。与此相反，我们的 product engineer 专注于开发和改进这条流水线。也就是说，他构建和改善 guardrails，设定边界和验收规则，处理某些新的例外情况，训练系统。

我们如何看待规格说明，以及我们总体上如何向智能体系统设定目标？我们对规格说明的做法是，它们应降低意图的不确定性，而不是详细写出实现计划。我们试过描述式 spec，但对我们不起作用。我们试过 SDD 框架中的各种规格说明，试过 driven-development framework 中的规格说明。但最终我们采用了一个相当轻量的版本：有一个系统，产品经理和工程师通过它在任务设定阶段进行交互。 大体上，靠自我控制来推进。它大致是这样：产品经理进入一个与智能体的聊天窗口。智能体可以访问产品 monorepo。因此，当人说“我想做这样一个功能”时，智能体能够将其意图与已经以可执行代码形式真实运行的内容进行比对。 它构建某种世界模型所需的时间大幅减少。 随后，产品经理回答一系列问题，给出一些评论，然后我们就得到了一份意图规格说明。 此后，product engineer 接手工作，并再次与智能体一起设计设计方案。 从大的层面说，这同样归结为回答一系列问题、在必要时给出一些纠正性意见，并最终获得一份产品设计文档。 设计文档不会详细列出要修改哪些文件、要添加哪些函数等等。我们不相信这个。我们相信，本质上需要为智能体设定一个明确的 goal、明确的目标，智能体可以为此做 Kill Clearance。 也就是说，这里包括功能性需求、非功能性需求、验收标准。

大概最重要的一个属性，或者说一项约定，是使我们 time-to-market 获得数倍提升的、关于 definition of done 应当如何定义的约定。

对我们而言，所有典型产品代码都必须由智能体编写。人，如果有人在一个由智能体创建的 merge request 中提交了什么内容，或者亲手完成了工作，这本质上会恶化我们的性能指标。因此，我们有特定的激励措施，确保所有工作都由智能体完成。在设计智能体流水线的过程中，我们进行了许多不同尝试。我认为，我们构建了大约四个失败版本的流水线，并吸取了一些教训。其中一个教训是，基于角色的 SDLC 流水线行不通。 在我看来，它们在经典的人类开发中也行不通，在智能体开发中同样运行得很差。

构建一种有规划者、执行者、测试者、各种批评者等等的流水线，这个想法看起来非常诱人。结果发现，这种流水线的效果远差于单智能体系统。 在这方面，我们的经验与 Google 的研究相一致：该研究发现，在顺序型任务上，多智能体系统给出的结果比单智能体系统更差。 我们将这一点表述为：“确保智能体的认知连续性很重要”，这样它就能像人一样，在完成任务的过程中以相当非线性的方式推进，而不会受到某个阶段或某个具体角色面具施加的硬性限制。也就是说，它可以研究代码、编写代码、以任意顺序运行测试、与环境交互、发现设计中的某些遗漏。原则上，我们甚至会训练它：如果它在目标设定中或自己的尝试过程中发现了某个关键缺陷，不要不惜一切代价把它完成，而应当放弃，说“我失败了”。 如此一来，我们就有机会消除这个关键缺陷。

在高层级上，我们的系统看起来是这样的。可以看到，这里有几个关键层。有智能体层，本质上就是前面所说的 Inner Harness 部分。其中有负责任务设定的智能体，有负责执行的智能体。这是这一 Harness 组件中最大的一部分。 有 Refine 智能体，其任务是在历史 traces、评论等等中寻找改进点。还有一大块、规模不可同日而语的一部分。这是确定性代码，我称它为“系统”。经典的 Python 代码。其中有一种实体，例如控制器，它负责许多非常重要的事情。例如，它会确认执行智能体确实完成了它声称已经完成的所有质量检查。也就是说，这个系统会检查智能体留下的工作证据。这个系统还负责错误后的恢复。例如，某个基础设施组件闪断了，或者我不知道，整个系统崩溃了。在这种情况下，我们不会丢失 state 和积累的进度。我们会从大致中断的那个点恢复。这一部分还负责错误预算、自愈以及许多其他事情。我们的智能体不会自己创建任何 MR。这同样由确定性组件完成。也就是说，原则上我们可以看到，系统是建立在非确定性、随机性组件之上的确定性上层结构。我们不轻信智能体的话。尽管智能体可以运行项目中的所有可能类型的测试、运行 linter、check 等等，我们仍然会在创建 merge request 前，通过 CI/CD pipeline 以及控制器再次额外运行这些检查。也就是说，在将以 merge request 形式的变更交给人进行审查之前，我们试图执行所有可用的自动化检查。最后是 review。显然，当我们如此数倍地提升流水线性能之后，需要审查的代码就大幅增加了。很明显，工程师的重点转向了确保完成这种审查。

以过去的方式审查如此规模的代码已变得不可能。因此，我们的工程师并不专注于审查 diff 本身。我们添加了一个中间层，将这些 diff 转化为智能体在过程中作出的一组决策。也就是说，本质上是一份带有某些可能的可视化内容的报告，供人审查。如果有必要，他可以深入查看具体 diff。 但原则上，对 diff 本身的审查也由智能体系统完成。

这就是我们的运营 dashboard，我们的团队每天从它开始，也从它结束。这里可以看到，仅八月就已有超过 900 个任务通过智能体系统。这是一张相当旧的截图。实际上已经远远超过一千。我们的累计 success rate 大约为 70%。这是 90 天周期的数据。这里可以看到一项重要指标：一次验收。Pass at one，31%。 本质上，这是智能体完美完成解决方案的任务占比，即审查者找不到可提出意见之处，直接接受该解决方案。 这一占比正在增长。总体而言，什么帮助我们实现对我们关键指标的增长？是流程中的几项关键变化。例如，以前我们习惯于将服务、前端、测试等等保存在不同的仓库中。嗯，历史上就是这样形成的。因此，当你需要做一个功能时，就得创建几个 merge request，并编排这些 merge request 合入相应 master 分支以及部署的过程。我们转向了 monorepo 概念。也就是说，我们选择一个有限的产品上下文，将它的所有服务、前端、测试、wiki，以及任何东西汇集到一个统一的 monorepo 中。首先，这使我们能够仅用一个 merge request，就把任意功能变更、任意新功能添加到这个产品、这个产品领域中。其次，这使智能体在研究、分析和执行过程中能拥有尽可能广泛的上下文，从而交付高质量方案，并理解自己所处的世界和环境。

我们从整个 Harness 构建过程中得到的最重要教训之一是，过早优化是邪恶的。 在构建流水线的初始阶段，不要试图在小事上节省，不要节省 token、美元等等。遗憾的是，这会导致你白白消耗自己的资源。我们一开始当然也踩过这个坑。我们从一个较弱的模型开始，试图围绕它构建某种过于复杂的 Harness，推动它朝我们需要的方向前进。我们与熵作斗争，而仅仅几个月后，同一模型家族下一版本的发布就让这种熵自行消失了。也就是说，我们花费了许多资源去造一些马上就被丢弃的轮子。总之，从那以后，我们尽量不再犯这类错误。我们采用现成的组件基础。也就是智能体框架，在我们的案例中是 LangChain 生态系统。现成的 workflow 管理工具、Observability tools、LLM gateways。我们用它们组装、建模自己的 Outer Harness 流程。我们用这些积木建模自己的内部生产流程，而这显然是无法直接买到现成产品的。

这里的另一个重要教训是，如何向团队植入这样一种 mindset：如果智能体出错或无法完成，你不会想亲手替它完成工作。 这种欲望会自然出现，尤其是智能体没能完成某个很简单的任务时：它完成了复杂任务，却卡在一个小问题上，那么你当然会觉得我现在亲自动手补一下就行。这个本能当然完全没有建设性，因为它会导致问题无法在系统层面解决。这里的系统性解决方案在于问自己：我可以改变产品上下文中的什么？可以向智能体提供什么知识、什么信息、什么检查，使它下次能够像我一样思考，应用和我相同的解决方案？因此，我们也通过这一视角审视 review 中发生的事情。工程师当然会非常仔细地审查代码，特别是在引入智能体流水线的初始阶段，会发现大量各种问题。

智能体经常冗长，它常常编写测试，这些测试更多测试的是形式而非内容，它们测试形式而非行为。 这类测试本身价值非常低。 为了以系统性方式解决这个问题，我们开发了一个自主自我改进循环。它会以一定周期启动，读取产品 monorepo 中此前未审查的所有开发人员对 MR 的评论。之后，智能体进行分析，尝试识别一些典型的重复情形，并提出如何能够系统性解决的假设。提出这些假设后，它会以 merge request 的形式提出对产品 monorepo、对智能体流水线自身 monorepo 的修改；例如，当它认为可以通过修改系统提示词来解决问题时。

我们已经提出并由团队接受了超过 60 项这样的建议，这带来了第一次尝试解决成功率这一指标相当可喜的增长。

要让交付速度成为常态，必须聚焦四个关键领域。

第一，也许几乎是最重要的、两个最重要事项之一，是 upstream 中任务设定的质量。也就是说，任务以怎样的设定、怎样的不确定性程度来到智能体面前开始执行。这里重要的是，在最初阶段就消除所有显著的不确定性。
第二，是稳定的验证环境、稳定的环境、智能体工作的稳定运行环境。测试不能 flaky，基础设施不能闪断，依赖项必须可 mock，等等。原则上，所有标准工程实践在这里都适用。
第三，智能体无法读取你的思想。因此，团队约定不应存在于人的脑中，而应迁移到例如 skills、prompts，迁移到智能体能够触及、在解决问题时能够依据的东西中。
第四，所有可能的检查都必须嵌入流程。确定性检查极其重要。经典工程实践帮助我们在产品之间、系统之间建立适当边界。这里 domain-driven design 运作得很好。需要具备相当高水平的集成测试、单元测试等覆盖率。接入静态分析，等等。

也就是说，这一切让你能够逐步扩展智能体的自主权，因为智能体的自主权不是靠信任扩展的，而是因为你获得了自动、自主验证其工作质量的能力。如果思考一下为什么像我们这样的转型经常会受阻，答案很简单：无论如何，都会归结到人。显然，任何工程师，包括我自己，都会依恋于我们多年掌握的工作方式。我喜欢写代码，我不喜欢把工作交给智能体。我们每个人都会以某种方式产生这种阻力。

我认为，解决这个问题的方法归结为与团队的 mindset 打交道，归结为让团队参与那些你认为具有战略重要性的变革。 当然，在 definition of done 层面，你也可以规定：只有工作由智能体完成，它才算被接受。不必 full-in，可以先在相当有限的范围内应用这种变更。例如，我们开始这场转型时，是让五个团队中的一个具体团队完全采用新的工作方式。

重要的是，那里必须具备这种完整的转型元素，不能出现“这部分工作我交给智能体做，而这部分工作我仍按旧方式做”的情况。如果这种可选性还存在，它就永远会以不利于转型的方式被实现。很大程度上是因为人们害怕错误，而在我看来，错误首先在这种转型中不可避免，其次它们也是必要的，因为系统最终正是通过这些错误学习。

因此，领导者在这种转型过程中应作出的关键决策包括：第一，将目标表述为 outcome，也就是客户能够感知、能够体会到的某种东西。为这个目标设定一种雄心，使得它通过旧的工作方式根本无法实现。重新审视人员结构，也就是团队中有什么角色，是否存在角色链条、不同阶段之间的交接。如果有，最好让流程中只有一个变更所有者。要努力建立自动化控制，使所有检查嵌入流程并自动化。还要消除 demo 陷阱。我把这样一种情况称为 demo 陷阱：团队向管理层展示一个漂亮的智能体演示，它自主完成工作、排版演示文稿、编写代码等等；但随后你去看团队实际如何工作，一切仍和以前一样靠手工驱动。这种 demo 陷阱必须消除。大概还有一个对我们运作得很好的重要点：选择自己的 North Star 指标，对我们而言是 Time to Market，以及它的不同组成部分，把它放到一个你几乎实时跟踪的 dashboard 上，并且每天从这个 dashboard 开始工作。

我相信，领导者负责战略，并作出战略下注。但如果团队不买账、不理解这项战略、不认同你的价值观，这场转型就不会成功。因为正是团队决定我们会以何种具体方式达成目标。因此，在结束时，我想提醒大家 90 年代的主要教训：过去，人们试图借助计算机技术自动化那些本应废除并彻底重设计的流程。现在，我们也经常以完全相同的方式使用人工智能，我们当然倾向于寻找某种灵丹妙药、某种可以下载、安装并解决所有问题的工具。没有这样的工具，你不得不吞下苦药，着手完成重设计现有流程这一艰难工作。 为了以清晰的方式开始，我建议选择一个没有它就无法想象公司运作的流程，并问自己一个简单的问题：如何在不完成所有这些工作的情况下，获得同样的结果？这将成为你 AI 转型的起点。我的分享就到这里。谢谢。

Q1：Andrey，你说你那里有一个单智能体，但由人来审查。有没有想过，比如用由不同模型的独立智能体编排出的面板来审查代码？还有，如果人审查，他会不会成了新的 bottleneck？

Speaker 1：是的，当然，人变成了新的 bottleneck，但人不是我们唯一的审查者。无论如何，我们有一个审查智能体，它提供一些额外反馈，首先交给人，而不是交给执行智能体，因为否则会出现 adversarial 循环，工作可能陷入循环且无法产出结果。至于面板，对我们而言，首先，这在我们最初构建某些多智能体、多角色系统的迭代中并没有奏效。它没有带我们得到需要的结果。于是我们决定，只在复杂性有合理依据时才增加复杂性。也就是说，如果我们看到执行智能体无法胜任自己的工作，才会增加额外的角色、阶段等等。

Q2：Andrey，说到业务单元和智能体开发，你们是在什么规模上开始应用智能体开发的？在哪些服务的规模上？

嗯，这里大概有几方面因素。首先，如果说我们业务单元的规模，总共约 170 人。其中包括 agile 团队和运营支持。若说智能体流水线以这样或那样方式开发的服务数量，我们有超过 200 个产品和服务仓库。我们将它们合并为 10 个这样的产品 monorepo。因此我们的规模相当大。这些服务也都写了很多年。代码量巨大。这里大概不存在关于如何让智能体有能力处理代码的通用答案。这是工程实践，也就是你的代码如何设计、测试如何编写的问题。这同样还取决于你为智能体探索代码库提供什么工具。例如，一段时间以前，当我们的模型稍弱、智能体架构稍有不同的时候，我们对代码进行了语义搜索。也就是说，为它建立索引等等。后来我们放弃了它，因为在当前阶段，对当前模型而言，ripgrep 能给出可比的结果，并且不需要任何 upfront 索引。也就是说，这一切都相当循环往复。我觉得问题更在于需要尝试不同方法。随着时间推移，重新回到那些没有奏效的实践上。也许它们会在新版模型或你使用的框架中发挥作用。

Q3：有没有某个流程是完全由智能体开发出来的例子？如果这不是一个想法的话。

嗯，大概我不会在这里直接谈业务流程。我们有很多实现这个业务流程的不同服务。本质上，我们的 agile 团队在做企业融资信贷流程的自动化。其中有不同内容：授权书签发、认证，也就是对授权人员签名进行认证等等。也就是说，那里有各种不同系统。大体而言，如果问题归结为智能体所做的变更相对于人所做的变更有多复杂，那么人过去做的所有同样工作，现在都是智能体在做。也就是说，我们不存在把一部分工作交给智能体，而自己做最复杂任务的情况。没有这种情况，这已被写进我们的 definition of done。

Q4：你好，我是一名测试人员。我在幻灯片上看到，你们放弃了手动检查和手动测试。你们把它转移到自动化测试上：end-to-end、集成测试等等。很好奇，你们现在如何确定所需的验证和确认规模？这听起来非常激进，仿佛你们针对每一个 corner case 都增加了大量 end-to-end 测试。你们如何解决这个问题？

我们做了一些准备工作，为项目准备测试金字塔，并确保最优的测试金字塔。我们在整个 2025 年都在做这个，甚至是在我们大规模引入智能体之前。当我们转向 product engineer 等等时，我们意识到需要以某种方式统一测试实践。因此，我们在这里做过一些准备工作。要说存在某种科学方法，可以用来理解什么比例的 end-to-end 测试、什么比例的 UI 测试、什么比例的单元测试就足够了，我不知道有这样的办法。我们更多是基于历史来行动。无论如何，我们仍然保留了人，但在当前阶段，我们系统中相当一部分用户仍是人。而且作为 product engineer，人仍会查看这些 MR。目前我们还没有越过从物理上无法这样做的那个点。因此，无论如何，我们大概会通过肉眼，以及用户可以直接在聊天中提供给我们的反馈、再加上通过某些 SDK 等等，观察是否存在任何表明质量下降的信号。目前我们没有这类信号。

Q5：明白，也就是说，我是否可以正确理解：在团队层面决定的是，审查单次 MR 的人会查看、检查其中编写的测试类型，看它们是否都足够好地应对最初承载的业务意图？

嗯，非常条件化地说，是的。而且这同一个人原则上也批准了这一业务意图的产品设计。也就是说，我们不存在一个人批准产品设计、然后智能体完成工作、再由第三个人审查的分工。我们放弃了这种实践。现在它没有太大意义。这是第一。第二，我们已经积累了一套，姑且说，工程实践的 skills，它们被数字化为 skills，能够建议我们期望针对某种变更看到哪些类型的测试。也就是说，我们在这方面也走过了一段路。当然，工程师在初期会看大量系统生成的这种 slop，感到厌烦，留下各种评论，重写 skills。这是不可避免的，无法一下子调整到位。

Q6：非常有意思的报告。有两个问题。一个很短，另一个更值得思考。是否存在那些按法律条文必须严格遵守的流程？合规、各种监管要求。你们在这方面有进展吗？

这是个很好的问题，谢谢。这里我们确实暂时会受到限制。毕竟，这是不可避免的，我们会受到这部分系统刚性的限制。它变化得会比其他一切更慢。但无论如何，我们相信这里也有一定的……第一，我们看到同事们在变化、在引入某些技术方面取得进展。第二，我们公司原则上是 API First。我们所有部门之间的交互在设计上都在朝 API 方向发展。我们非常相信这一点。第三，我认为包括立法、某些监管标准在内，它们也会基于我们可用的技术以及这些技术在经济意义上 enable 的事情而逐步发生变化。

Q7：现在说一个难的问题。总之，我们在智能体化，转移我们的知识管理机制。其中一个问题是 pip 点 0，也就是知识足够让智能体能够进行变更、能够获得上下文的时刻。我感觉，当你们把一切迁移到 monorepo 时，实际上就从桌面上移除了“代码是 commodity”这一论点。代码变成了你们的真相来源，作为知识库的一部分在上下文中被用于让智能体完成某些事情。我的论点对吗？

这个论点是对的。

Q8：下午好。我有一个简明的问题。报告中你们说，成功将开发加速了数倍甚至数十倍。那么你们如何将产品经理也加速到相应的数字，让他们能准备出没有不确定性的、所描述的目标，使你们的开发不在一开始就停滞？因为你们的流水线从产品经理那里一开始就必须具有同样的速度。

是的，这是一个很好的问题。我也在那里做过说明：我们目前有一部分 discovery。也就是说，我们聚焦于 delivery，discovery 相当重要的一部分暂时放在括号之外。我展示的那个界面例子，是产品将如何设定任务的某种原型。我们试图逐步向左扩展系统的这一部分，从而尽可能覆盖 discovery。例如，很明显，其中只是发生了意图的确认，也就是为了让智能体理解我的意思。但在我产生这个意图之前，也已经发生了一些工作。我们相信，这项工作同样应当在这个系统中，通过各种 connector 来完成：外部市场环境的 scouting、客户分析等等。它应当在这一界面中发生。我们目前还没有真正深入到那里。也就是说，公司中原则上也在业务单元之外开展这一方向的工作。比如，我们就影响范围和关注范围达成了划分协议。我们目前更多聚焦于 delivery 部分。但话说回来，原则上我们很清楚自己要做什么。这个 backlog 是多年积累起来的。我们先得把它处理完。

Q9：TMS 架构师。以前的情况是先有 TMS，然后一切都被自动化。所有这一切在哪里，痕迹还会保留吗？之后谁来处理技术支持的 complaint 以及其他所有事情？

我们承担这个责任，这正是因为我们如何看待项目团队负责什么。我们的责任从来不只是严格地落在自动化测试上。至于 TMS，去年我们还面临这样的两难：要不要保留已有的 comp divide tml，要不要把这一切录入其中。我们写了一些 handling、说明，以便工程师也能这样做。工程师看了看，说这些全是胡扯，于是放弃了。工作开始不通过 TMS 来完成。在我们的情况下，我不是说这是适用于所有人的通用方案，我们放弃了 TMS，也放弃了自动化测试人员工作中这一超正式部分。至于测试人员，我们面临的是一个简单两难：测试人员必须成为 product engineer。

Q10：但是，假设在形成技术任务时，要进行拆分，整体上我们可以评估技术任务要用测试文档覆盖的规模，从而理解并从测试角度评估其质量。

是的，我理解您的意思。我也在那种采用瀑布式方法的公司工作过，但现在我们公司是 agile，也就是说，我们不存在持续维护、编写和更新某种技术任务书的做法。也就是说，我们的流程通过智能体以不同方式安排，我们的开发方法不同，我们没有技术任务书。即使现在已经有智能体流水线，我们也不写详细的技术任务书，不写某种测试量、测试……我们有 spec。我们有 spec。也许它取代了您赋予技术任务书的角色。对我们而言，spec 回答关键问题……同样，维护它的形式有很多，可能是技术任务书、PRD、ADR、SDD 或其他实践。每个人过去和现在都以不同方式做，但我们的 spec 相当简单：功能性与非功能性需求、non-goals、验收标准。 但我们不会在 spec 中规定要做哪些测试：智能体会在自身执行轨迹中选择做什么。总体而言，根据 skills 中同样规定的具体要覆盖什么、覆盖到什么程度等等，我们目前对这个选择感到满意。

Q11：我最后一个问题。如果任务非常复杂，涉及多个产品、服务等等，也就是说，需要进行非常深入的 grooming，并且它本身就是一个大型 backlog 的来源。在这种情况下，智能体可能无法应对这样一个必须立刻完成所有事情的大任务。是否需要接入某个 solution architect，或者负责这一角色的人？

这个角色始终由开发人员负责，我们没有 solution architect。我们有公司层面的 enterprise architect，但他们的重点完全在另一个领域。如果谈类似请求在我们这里如何处理，那么在我展示的系统中，有进行拆分的可能。那里展示的是 happy path，也就是一个简单任务被创建、完成，就结束了。但复杂任务可以在我们原有的 delivery workflow 中进行拆分。也就是说，一切都可以在那里完成，因为智能体可以访问所有产品 monorepo。因此，如果任务出现在产品交界处，它可以研究所有产品。

Q12：但在这种情况下，它必须在自身 delivery 中准备 backlog 并分配解决方案所有者。谁应控制这一过程？也就是说，这由你们的执行方来做吗？

智能体自己执行所有这些变更。智能体在所有产品 monorepo 中创建 MR。同样，它掌控整个上下文。无论如何，我们都有方法。现在你所使用的任何 harness，Claude Code、Codex 等等，所有好的 harness 都会掌控全部代码上下文，以理解要做什么。此外，上下文是动态变化的：有些东西被加载，有些东西被卸载。无论如何，上下文窗口本质上是稳定性的关键元素。

Q13：你们是否使用某些工具，例如执行狭窄任务的 subagents？

我们此刻不太确定。我们有 subagents 工具，至于它被多积极地使用，需要查看轨迹、研究 traces。起初它对我们运作得相当差。坦率说，行业中对 subagents 的看法是两极分化的。我们一开始采纳其中一个极端：不使用任何 subagents。后来逐渐放宽了，说智能体可以自行决定，例如将 read-only 活动交给 subagent。原则上它可以这样使用。至于这到底有帮助还是没帮助，我们没有做过能显示之前与之后差异的实验。

Q14：是否存在处理长任务的实践，比如持续工作几个小时的任务？

关于长 task：我们没有完成时间超过几个小时的长 task。也就是说，始终少于四小时。

Q15：可以问一下测试的问题吗，更准确说是测试技术？功能测试是否构建在某个框架上，自动化测试实际写在其中并放在 monorepo 中？还是智能体自己拿某个 Playwright 之类的工具自行运行？

大多数情况下，还是对已有产品进行修改，其中已经形成了某些测试实践。我们不会让它去造轮子、碰遍所有可能的框架再带回来。我们没有这种情况。理论上可以这样。举例说，如果我们在某次 postmortem 分析中理解到，需要额外的测试类型，而当前可用框架中无法实现，我们可以创建一项覆盖任务；之后智能体原则上也可以自主完成它。

Q16：智能体，比如如果没有 driver，就会说：“来吧，给智能手机做一个按钮，既然没找到元素”，是这样吗？

是的，我们的 UI 测试相当少，也就是说，它们是少数，因为这个流程本身并不 UI-heavy。其中有界面。它比假设这是一个面向零售客户的、front-heavy 的手机银行界面要简单一些。那样的话，我们就必须对这一部分投入明显更多。

Q17：问题是，这样一名工程师的普通工作日是怎样的？从日常角度来看。显然，他会构建这套智能体周边体系，他的价值就在于构建它。他只做这个，还是也做其他事情？

总体上要说的是，产品工程师作为一种角色，对我们来说是一个移动目标。例如，去年年底我们引入这个角色时，本质上是在回答这样一个问题：在 GenAI 胜出的世界中，现有的角色模型——后端开发、前端开发、测试人员——是否仍然有效？我们决定它不再有效，需要了解整个技术栈的通才工程师。大体上，通才工程师变成了产品工程师。我们原以为，他们主要会亲手或借助 coding agents 编写功能。结果现在我们的工程师写的代码很少。在智能体流水线出现后，大体上他们停止了编写代码，除了编写流水线本身的代码。 因此，他们大概 70% 的时间花在相当经典的团队工作、团队协作要素上。我们做什么、为谁做、为什么做、怎么做、为什么如此，等等。接着，目标设定和 review 当然也占据重要重点。现在可能更多是 review，因为代码量相当大。我们无论如何都力求将变更在不到 24 小时内推进。因此，重要的是让他们更多关注所接收内容的质量。因此，在做这些事情时，他们会留下评论。他们可以立刻基于反馈去完善项目和 skills。他们也可以立刻去与 Harness 团队交流，思考可以给流水线智能体提供哪些能力。也就是说，这在不断变化。 Q18：如果一切这样运行，他们就应该确保所作变更不会破坏之前的项目？
你的意思是，确保新的修改、新的 skills 不会相互矛盾？是的。我们发现这会发生，也就是 drift。我们构建了一套分析、识别这些 drift 的系统。而且，这同样在智能体自我改进循环中完成。它真的会在 skills 中发现矛盾。 Q19：会出现回归，你可能在新任务上遇到它以前本来能解决的问题。现在它开始退化了吗？
情况更糟：skill 代码中可能会发现相互排斥的段落，因为例如不同的人在不同时间编写过这个 skill。不同智能体从不同角度看过它。我们现在会发现并修复这类问题，以确保它们是完整的。某种专业知识的 skill 应当被数字化，并且不存在矛盾。

Q20：那么，你们转型了团队。移除了角色，把所有人变成 product engineer。接下来，有一个复杂功能。据我理解，它会按领域进行拆分。而且会被细化得相当小。因为如果我把一个大功能交给团队，那么我的 channel 中就会出现这些 product engineer 的流。他们会自己相互协商、相互交互。结果就会变成以前角色之间的同样问题。也就是说，在这么多 product engineer 之间也会开始交互，它会占用一些时间。因为他们都处于各自领域的上下文中，也可能有各自的背景。也就是说，你们会把任务拆得这么小，然后分给这五名工程师每人一个。他们之后再以某种方式沟通，最终再检查各自的 MR？是这样运作的吗？

我们不是这样运作的。但可能只是我们还没有遇到那种会同时涉及三个以上产品 monorepo、某些相邻系统的大规模变更。无论如何，可能产品经理甚至不会带着这样的事情来到 delivery。它们自己会尝试以某种方式拆分这些变更。

Q21：工作会拆分到恰好能由一个工程师承担的程度。细化到最小？

不是这样细化。也就是说，我们有一个负责规划的智能体。你可以带着意图来找它。如果它看起来太复杂，这个意图可以被拆成组成部分。甚至不管它是否复杂，因为我们无法在入口处评估这一点。我们更多根据仓库的数量和构成理解这一点，也就是说，例如需要有多少特定层级的任务。绝大部分工作通常按设计都落在一个产品 monorepo 的范围、边界内。如果某些内容出现在交界处，也就是涉及多个产品的大型工作，那么它会被拆为例如两三个任务。负责它们的仍是同一个工程师，也就是与智能体一起规划这个变更的人。也就是说，不存在将它分给三个智能体的情况。一个工程师负责一个大型任务。一次变更，一个人。无论变更多大，人都必须对它端到端负责。但我们只是努力减小这个“大”。 Q22：那就必须是超级规划，也就是说，任务始终得是一个人能端到端负责的任务。某种小规模的交互、执行。这是不是必须完成近乎完美的规划？
坦率说，我没听说我们的团队因此感到痛苦。可能我们在更早阶段就已经解决了它。但我们更……简而言之，我们不是 waterfall，我们有非常 agile 的文化。原则上，我们会努力……这叫什么来着……那些根本不清楚怎么做的任务，对吧？我想要这样一个东西，不知道它该怎么工作，但我会把它放进你们的 backlog，你们之后爱怎么处理就怎么处理。这是一个 story point 还是一百万个 story points？但我们这里不会把这种任务放进 backlog。我的产品经理和团队在 discovery 阶段、delivery 之前，会以相当合理的方式处理并消除不确定性。这一切都属于 discovery。 Q23：简而言之：客户来了一个任务，它与五个客户相关。需要去找客户，了解第二个客户的情况，找设计师、分析师、产品人员，把所有这些收集起来并攻克这个功能。真的由一个人来做吗？
是的，在我们这里真的可以由一个人做，但原则上以前也是这样。一个人可以把这一切梳理清楚。

Q24：关于设计师。在这个关联中我也没有看到设计师。如果有某种需求，需要重新设计、用新组件做一个新设计等等，整个过程是如何进行的？

我们主要将其归入 discovery 部分。我们有一个以某种 kit 实现的设计系统，智能体可以访问它。也就是说，智能体原则上已经可以从 UI Kit 组装界面。

Q25：那么应该由设计师审查吗？

嗯，这意味着在 discovery 阶段可以出现设计稿。再次说明，我们的 UI 相当少。尤其是那些需要仔细校验的 UI，因为我们直接面向客户展示的各种界面非常少。我们的大部分界面是供员工使用的。坦白说，我们还没准备好把设计师资源花在校对员工界面上。

Q26：据我记得，现在面向客户的 demo 变了。你们是否开始重新计算每个完成的功能的费用？

大概是因为我们在这方面不是外包，对吧？我们并不出售内部开发的时间和专业能力。从面向内部客户的 demo 来看，大体上它看起来仍和以前相当类似。也就是说，我们仍展示一些功能。新增了 Harness 团队的一个部分，它展示生产流程方面的成果。

Q27：业务和员工喜欢这些变化吗？

我们的业务几乎就是混在一起的，每个月都会不断投放任务、登记投资、信贷项目、新的养老金。因此，这里的工作距离更近，少得多。首先，从这个角度看。其次，我们一线运营员工自身也受到激励、具有动力。他们更积极地接受人。我们所有人都有共同目标。大概对我们而言，这个问题没有那么突出。我们努力把一切完整做好。

Q28：之后要执行任务的人，是以什么形式接收任务的？是经过充分研究的描述，说明谁想要什么，还是字面上只有几行，比如“做一个漂亮按钮”？

以前，当人们手工收集任务、在 Jira 中创建任务时，我们存在很大的可变性，一切取决于人的速度。有时完全是 one-liner，只有几行任务描述等等。因此，我们开发了这个系统，让它为我们最小化可变性。因此，我们从产品经理那里获得完整且具体的意图：什么、为什么、什么指标、期望什么机制。产品经理自己与智能体澄清并细化这一切。之后工程师以这样的形式接手。然后就与智能体一起 brainstorm，如何更好地实现它。

Q29：使用哪些模型？现在大家都在转向中国模型吗？

嗯，我们试过不同的模型，试过 ChatGPT、Kimi、Qwen，最差的大概是 Qwen，尽管它们最常被使用。现在对我们表现不错的是 Kimi K3。它非常令我们满意，即便和 ChatGPT 相比，它也能给出更令人愉快的代码。没有 ChatGPT 中那些语言腹泻般的内容。它们……

Q30：我的情况是，开发时使用 DeepSeek 4.1，验证它的是 GLM 5.3。结果最近它们确实开始互相无法理解了。好吧，这并不容易。

它们每个都有，类似，这个，ject、intelligence，也就是说都有强项和弱项。GLM 能发现 Kimi 没发现的东西，也会漏掉 GPT 很容易发现的东西。也就是说，它们都应该互相补充。

Q31：第二个问题，什么团队做了 Harness，由此引出的另一个问题是它如何成功做到的？也就是说，我是这样想的：你们从实验室开始，不是立刻全面展开，而是逐步进行，之后这个流程如何被装备起来？

但开发本身是由一个大概 4 人的团队加上我完成的，有不同工程师，两名经典通才工程师、两名 NLP 工程师。工作大概进行了半年，按空闲程度来说，也就是说，我们半年内构建了四个无法工作的 harness 原型，之后一个月构建出一个能工作的，并从八月开始将所有人迁移到它上面。我有一个相当简单的启发式判断：我只是理解到它能工作。 当我在自己和团队的例子上理解到它能工作时，我们运行了许多模拟我们通常在不同团队中遇到情况的内容。当我理解到它会正常工作，但不可避免会遇到某些错误，而没有这些错误我们就无法改进智能体系统时，尽管我讲过应该有限度地行动，我们还是 all-in 了。也就是说，所有团队都获得了某种激励，要求所有开发都通过智能体流水线完成，而不亲手写代码。我们有一些例外。也就是说，我们先排除了一个处于 delivery 关键路径上的项目，它是一项全球范围的迁移，必须有严格的截止日期。我们不想在那里展示什么、得到什么错误。那实际上只是六个团队中的一个。还有一个系统，由两个人维护和继续维护，那里有手续费、旧系统、Windows 等等。我们只是可以说不想折腾那里的 sandbox。把它放到一边，说各位，之后再处理。就这样，其他所有人都进入了这个模式。

Q32：你们是否有用于组织上下文和记忆的某些 framework？

我明白了。唉，我们也在这个问题上，正好我说过造轮子。我们一开始也在造轮子，想着要不要以一种智能体更容易理解的形式组织产品上下文。开始设计自己的 Deep Wiki 实现。结果不太好。就在我们意识到效果不太好时，Lang Chain 发布了 OpenWiki，于是我们全部转向 OpenWiki。也就是说，我们有一些 pipeline，它们在夜间分析产品 monorepo 的 Wiki。 智能体可以访问它。 至于真正意义上的某种记忆，我们还没有到要做这种……也就是说，现在不清楚为什么需要这种记忆？它具体应记住哪些决策？

Q33：也就是说，比如我们开始为角色创建澄清课程。这变得更现实了。（听不清）？

不，我根本不相信这种范式。我看过结果。我见过人们在现实中尝试使用、引入它。它没有奏效。基于此，我们得出结论：它行不通。再加上我们在基于角色的流水线上的失败，使我更倾向于认为这种做法会运作得相当差。

Q34：能否分享一下经验。你们来到团队里说……你现在不是后端，而是前端。你现在只是工程师。如何应对阻力？团队如何反应？又是如何重构这个环境的？

嗯，这花了我们很长时间。比某种 Harness 工程的时间还长。也就是说，我们逐步走向它。但我大概从前年夏天就开始预热。先是做一些演示，讲行业走向何方、其中发生了什么、为什么如此、为什么你们所做的那份工作很可能两年后不会再有人付钱。

Q35：这个明白。但到了真正开始变革的时候呢？

我们比其他所有公司都早得多迈出了这一步。去年秋天，我们告诉大家，例如测试人员、前端人员，还有什么来着，运维人员，你们将需要做产品平台。我们准备提供所需的培训。现在让我们大家一起坐下来，把团队约定、工程实践等等描述中缺少的部分坐下来标准化。我们在做这项标准化工作。通过这个过程，某些工程师，例如后端开发人员，掌握了以前不具备、没有做过的某些测试细节。这当然花了一段时间。大体上，我们最终把这项工作全扔掉了。我们写的所有那些 handbook，在新现实中一部分迁移到 skills 中，一部分已经没人使用。但从渐进 adoption、让大家安心的角度，它是有用的。

Q36：是否还保留着某些专家，比如负责看架构的，还是也都一样？

我们有过非常不愉快的案例。我们以为自己有专家，职位就叫“专家”，他们甚至负责编写某些 trendbook 等等。当他们编写这些 trendbook、展示自己的专业能力时，结果发现，这种专业能力的深度并不像我们过去以为的那样遥不可及。它实际上可以感知，并且很容易转移到普通经典工程角色中。我们有强大的通才专家，我有几位这样的通才，他们能完成绝对任何工作，在 computer science 的任何领域都有强大的 reasoning。但除此之外，我们没有其他专家了。即便这些专家，我也不是用来验证谁的决策，而是用来解决 Harness 构建或其某部分优化中某个极不典型的任务，也就是我们以前没有做过的事情，简而言之是 RnD。

Q37：最后一个问题。以前团队很大，你们开始进行这项工作后，发生了多少比例的裁员或优化？还是没有发生，你们为所有人都找到了新位置？

实际上，我们没有试图优化或削减成本，我们的目标过去和现在都是 TTM。有一些例子，比如人们自己选择这不适合他们。比如我还是去公司 N 做测试人员吧。或者，我不明白，如果我不再写代码，怎么能从测试人员变成工程师。这样的人会自己决定自己不再适合公司。我们不强迫任何人。原则上，我们的 attrition rate 大概在 5% 到 8% 的水平。考虑到如此激进的变化，这非常正常。

Q38：你在报告中说，系统分析在你们那里很久以前就已经没有了。那对于系统分析长期存在的公司该怎么办？有大量地方写着各种内容。BTS、FOD。还有，我不知道，各种用户文档。而且所有文档彼此矛盾。没有统一入口点。它非常庞杂。代码也很多，全都在不同仓库中。因此，为了构建智能体流水线……我现在的问题是，我所有智能体都陷入不可靠的上下文。它们告诉我一些东西，基于不真实的信息作出决策。这个该如何解决？

产品的运行比穷尽的文档更重要。简单的遥测。很可能，在我们的世界里大多数情况都会是这样发生的。但那些我们有……我们保存了有用上下文的地方，例如业务描述层面。比如某些监管规定、规范性文件、复杂产品的描述，它们保持不变。它们被保留了，只是迁移到某个产品 monorepo 中。是的，其他各种表格、图示、设计等等。但这始终都是问题。甚至在智能体出现之前，它们就会过时。至于怎样……当然有解决方案、尝试，比如：我们来做架构测试，做……简而言之，加入某种测试和验证层。但这很复杂、非常昂贵。我们没有做。我们只是把这些东西丢掉，并认为这才是解决任务的方法。

Q39：你们遇到过哪些严重的智能体事故？

总体上，在智能体出现之前总是有……不，如果看 incident rate 指标，我展示过：defect rate 大致保持和以前同一水平。由于企业业务、企业信贷的特性，真正大规模的事故并不太可能发生。在我们有潜在 blast radius 相当大的地方，简而言之，我们会做 double-check、triple-check。也就是说，我们会尽量……确实可能在某些财务记账、分期付款等方面严重出错。在这些地方，我们的系统在智能体出现之前就已被各种条件、测试、各类检查包围。它们设计得相当好，在我看来，我们非常投入地重设计了它们，因此现在那里没有发生任何事故。也许还没到时候。也许我们只运行了三个月，也许明天正好就会发生什么。

Q40：关于 time-to-market 指标的问题。不同领域的并行开发模型。你说 time-to-market 得到了改善，但并行性仍然存在，特别是 merge requests 冲突和其他各种乱七八糟的问题。如果我正确理解，例如，领域模型设计得很好，对吧？但产品或 backlog 仍可能改变同一个 domain，因此需要解决冲突。你们是在智能体层解决，还是在产品、功能的规划层解决？

肯定不是在规划层解决，至少我不知道有这种解决方式，也许它在某处存在，只是我不知道。它是在……让我想一下我们怎么做的。也就是说，智能体自己做 rebase。大体上，我们是 trunk-based，我们有线性历史，所有这些冲突必须以某种方式在 MR 中解决。现在人已经不再解决这些冲突，大体上是智能体解决冲突，而且多数情况下它们能处理好。

Q41：如果只是并行发生呢，比如一个已经审查完、已经准备好上生产，另一个在同一个 domain 上也准备好上生产？

嗯，智能体本身……不完全是智能体，系统很复杂。各种方法、策略会自行执行。

Q42：那 blocker 怎么处理？例如 domain 锁定。比如我们在另一个 domain 正在编辑、且 human approval 尚未发生前，不编辑 domain。

坦率说，我没听说我们发生过这种冲突……

Q43：在 monorepo 里？在 monorepo 里它们不是总会出现吗？比如编辑一个 domain 时，一个产品想要功能 A，另一个产品想要功能 B？

啊，不，我们没有同一个 domain 的多个产品。也就是说，在管理层面存在一条结构化且合理的决策队列。可以这样说，对。还有一个重要点：在我展示的流程中，其中一个智能体也会研究你想要的功能是否与已有内容矛盾。也就是说，假设你是不是想破坏工作边界，往系统中添加不该存在的相互排斥段落。它按设计本来就以另一种方式工作。你在试图破坏人们先前提交的行为。这是第一。第二，这个东西也会扫描现有任务，以确认已经不存在矛盾。因为我们努力现在直接解决这些矛盾。我已经忘了这部分，因为它很早就完成了。因为之后在这一部分又完成了很多内容、很多层面。也就是说，包括解决矛盾，也可以在这里、在系统的这一部分完成。因此，进入智能体流水线的实际上是一个基本准备好的任务队列，在这个队列上 pre-base 是简单且安全的。

Q44：我明白了，因为 pre-base 正是智能体会周期性很容易出错的那种东西。第二点是模型、基础设施、temperature、reasoning 等等，你们调整过吗？

去年我们积极尝试过 temperature、reasoning。在当前方法中，我们尽量不做这些。我们尽量默认使用设置。因为不知道如何比较。需要在 benchmarks、evals、judge 上进行相当强的投入。需要工程师投入更多注意力，观察模型开始产生的这种再生成。再说一次，这一切多数时候都属于很难量化的比较。这是品味问题。我们不玩这个。我们努力确保在某些指令层面，能够得到人可以接受的结果。

Q45：而且模型是独立的。例如，如果在第三类模型中，结果因此本质上不依赖于谁是谁。如果你们需要进行某种下一轮枚举。

我们这里 model-agnostic。我们目前尽量不下沉，也不对简单模型做 downscaling。我们现在还有钱，不需要做这个。要做这个，还需要在 benchmarks 上进行很大投入。但无论如何，我们现在用于 benchmark 的材料比以前多得多。以前需要从不同项目的历史尾部收集任务，而这些项目有不同工程实践。现在我们有了大致正常运行的智能体系统。例如，项目实践已经趋于一致。任务规模也大致趋于一致。任务描述也大致清楚。到处都一样。因此，用于 benchmark 的材料现在更丰富。看起来我们过一段时间就会开始做。

Q46：那么这里根本不使用 SDD 吗？还是作为镜像？

不，OpenWiki 更不是镜像，我把它称为为智能体简化导航。减少它理解、找到所需内容所需要的 hop 数量。这个问题可以用不同方式解决，但我们不使用 Semantic Search，我们更多依赖某种 grep、ripgrep 等等。因此 OpenWiki 在这里有帮助。而如果谈的是 SDD 本身，那毕竟是不同层级的实体。我们在自己的开发中试过，比如在 vibe coding 中，使用某种 OpenSpec、Spec Kit。坦率说，关于 Spec Kit，我们当时有什么结果我甚至已经不记得了。至于 OpenSpec，我们在 Harness engineering 团队中确实持续使用了很久。一部分人喜欢它。后来我来了，看到它是什么样子。我想：唉，坦率说这很复杂。完全可以通过冗余程度低得多的流程达到相同结果。那本质上是来回折腾。是的，是的。想法可以理解：你花越多 token 做有方向的 brainstorm，大概越有可能在某个概率范围内得到更好结果。但现在我们正在放弃这种实践，更多是在做一个非常轻量的 spec SDD，采用的格式，嗯，就像 Anthropic 最近发布的 Playbook。他们发布了那个 Playbook，其中说他们有 Intent.Markdown、Spec.Markdown、Design.Markdown，类似这些。 我们的系统实际上实现得非常类似。所有内容都提交到和主代码相同的 Git 仓库中，但没有例如 OpenSpec 所具有的那种严格 workflow， 并且 verbose 程度肯定比它更低。

Q47：那么 spec 终究是以某种方式存放的？

对对，当然。这是重要部分。

Q48：Andrey，我可能听漏了。你们具体所说的角色团队组和 role policy 是什么？是智能体分析师、智能体开发者、智能体测试者吗？对，你说过你们一开始对角色型流水线感到失望，后来开始按现在的方式做。

啊，对对对。当时有……我想想我们有什么。实际上，我觉得很接近。像 Codex Planning 那样的一些 prompts。例如，我们有一个规划者，它必须给出详细实现计划。我们有一个 implementer，它必须实现这个计划。我记得它无权写测试。还有额外的测试编写者。我记得每个阶段都有 adversary，它们应该进行确认，并且如果注意到不合适的地方就重新启动工作。对，我们没有成功。

Q49：那现在就是说，只有一个智能体？

嗯，一个关键执行者，它本质上掌握端到端核心。一个这样的武士战士。它还有一些，姑且称为……不完全是顾问，但总之，可能会启动审查者。工作完成后它会启动，可以给智能体某些反馈，智能体可以再完善一次什么，或者忽略它。它可以不同意这个反馈，那么就会明确记录：它被忽略了。相应地，大体上我们努力不构建角色链条。

Q50：另一个问题。一个工程师做一个任务。当我问工程师的工作日时，他加入团队，参与团队同步，那么这个团队同步又是什么？

嗯，对我来说重要的是理解，大概我不应该有隧道视野，因为我拿到任务，然后独自去完成它，但这会导致人变成怪人。首先，他们大概会觉得工作没意思，感觉自己只是执行者，而有些人则是因为现在他一个人完成了自己的全部工作。因此，我们这里的所有工程师都完全沉浸在产品上下文中，解决客户问题。思考如何实现它。我们就是这样的团队。我们就是这样的团队，大团队，每个人完成自己的任务。我们现在就是这样的团队。