AI 软件开发中的人与智能体：软件工程循环、人在环路中与框架工程

在 AI 软件开发流程中，人类究竟应该处于什么位置？是置身事外，只凭感觉让智能体生成代码？还是深度介入，逐行审查它们写出的每一行代码？我认为，答案不在这两个极端，而在于始终聚焦一个目标：把想法转化为成果。

人类真正适合的位置，是构建、引导和管理这个软件工程循环，而不是完全放任智能体自行其是，也不是对它们的每一项产出进行微观管理。我们不妨把这种方式称为“参与循环”。

作为软件开发者，我们的工作，是把想法转化为可运行的软件，并在学习、反馈和改进中不断迭代，最终创造出真正有价值的成果。这就是“为什么循环”。在人工智能真正接管这一切之前，人类仍将持续运行这个循环，因为我们才是这些软件成果的真正需求方和受益者。

软件构建过程本身，则是一个“如何实现”的循环。这个循环会创建、选择和使用各种中间产物，例如代码、测试、工具和基础设施。它也可能包含文档，例如技术设计文档和架构决策记录。我们常常把这些东西视为交付物，但实际上，它们只是达成最终目标的手段。

图 1：原因循环遍历想法和软件，方法循环遍历软件构建过程。

事实上，“如何循环”本身又包含多个层级的循环。最外层的“如何循环”负责定义并交付“为什么循环”所需要的可运行软件；最内层的循环负责生成和测试代码；中间层级的循环则把更高层次的工作拆解成更小的任务，交给较低层级的循环执行，并对结果进行验证。

图 2：how 循环包含多个层级的内部循环，这些内部循环处理完整实现的较小增量。

这些循环可能会采用设计评审、测试阶段等工程实践，也可能借助架构方法和设计模式来构建系统，例如微服务架构，或其他强调可组合性、可演进性的设计方法。与这些实践和模式所产生的中间产物一样，它们本质上都是服务于最终结果的手段。

但也许，我们并不需要关心实现目标所用的手段？也许我们可以完全放手，让大语言模型按照自己的方式运行整个流程？

AI 编程中的“循环之外的人”

许多人已经发现，让人类专注于“为什么”的思考，而把“如何实现”交给智能体处理，是一件非常令人愉快的事。这也是“氛围式编程”的一种常见定义。某些对规范驱动开发的理解也与此类似：人类投入精力描述自己想要的结果，但不干预大语言模型如何实现它。

图 3：人类运行“为什么”循环，智能体运行“如何”循环。

人类之所以乐于置身于“如何实现”的循环之外，是因为我们真正关心的是“为什么要做”。软件开发本就是一个复杂领域，很容易陷入过度设计的流程，或被技术债务的泥潭拖住。而到目前为止，每一代新的大语言模型都在更好地响应用户指令，并生成可运行的软件。如果你对生成结果不满意，只需要告诉它，大语言模型就会给出另一个迭代版本。

如果大语言模型可以在没有我们干预的情况下编写和修改代码，我们还需要关心代码是否“简洁”吗？只要大语言模型能够理解，变量名是否准确表达用途似乎就没有那么重要了。也许我们甚至不必关心软件到底是用哪种语言编写的。

我们真正关心的是外部质量，而不是为了内部质量而追求内部质量。外部质量，是我们作为软件用户或其他利益相关者所实际体验到的质量。功能质量当然是必要条件：系统必须能够正常工作。对于生产软件而言，我们还关心非功能性的运行质量：系统不应崩溃，响应应足够迅速，不应把机密数据泄露到外部网站，也不应产生高得离谱的云托管费用。在许多领域，系统还必须能够通过合规审计。

只有当内部质量影响外部结果时，我们才会真正关心它。过去，程序员必须仔细阅读代码库，才能添加功能、修复缺陷；而一个干净、结构清晰的代码库，能让他们更快、更可靠地完成这些工作。但大语言模型似乎并不在意“开发者体验”，不是吗？

理论上，我们完全可以让大语言模型智能体生成一个极其复杂的意大利面式代码库，再通过运行临时 shell 命令不断测试和修补，最终拼出一个正确、合规且性能良好的系统。我们只需要让算力集群在数据中心里全速运转，源源不断地消耗能源，最终也许仍然能得到想要的结果。

但在实践中，设计清晰、结构良好的代码库，相较于混乱的代码库，仍然具有显著的外部优势。当大语言模型能够更快理解和修改代码时，它们的工作效率会更高，问题也不容易像雪球一样越滚越大。我们仍然非常关心构建目标系统所需的时间和成本。

人在环路中：AI 软件开发的人为因素

一些开发者认为，保持内部质量的唯一方法，是密切参与开发流程最底层的工作。通常，当智能体被某段错误代码卡住时，人类开发者可能只需要几秒钟就能理解并修复它。在许多情况下，人类的经验和判断力仍然优于大语言模型。

图 4：人类运行“为什么”循环和“如何”循环

当人们谈论“人在环路中”时，通常指的是人类在代码生成的最内层循环中担任把关人，例如手动检查大语言模型生成的每一行代码。

问题在于，如果我们坚持对开发过程进行过度干预，人类就会成为瓶颈。智能体生成代码的速度，远远快于人类手动审查代码的速度。关于人工智能提升开发者效率的报告结论不一，其中一个原因可能正是：人类花在代码规范和代码审查上的时间，抵消了使用大语言模型生成代码所节省的时间。

我们需要重新采用经典的“左移”思维。过去，我们会在写完所有代码之后，把它交给测试团队测试，然后再试图修复足够多的 bug，以便发布版本。后来我们发现，如果开发人员在开发过程中就编写并运行测试，就能立即发现并修复问题，整个流程也会变得更快、更可靠。

适用于人类的方法，同样适用于智能体。如果智能体能够自行评估代码质量，而不是依赖我们事后检查，它们就能写出更好的代码。我们需要告诉它们我们想要什么，并指导它们以更好的方式实现目标。

框架工程：人类如何参与智能体循环

与其亲自检查智能体的每一项产出，不如提升它们产出高质量结果的能力。用于控制“如何循环”中不同层级循环的规范、质量检查和工作流指引集合，可以看作智能体的“支撑框架”。构建和维护这些支撑框架的新兴实践，也就是所谓的“框架工程”，正是人类参与循环的一种方式。

图 6：人类指导智能体构建和改进“如何循环”

类似的“循环”概念，也被一些海外技术讨论者称为“中间循环”。所谓中间循环，就是把人的注意力从编码循环本身，转移到比编码更高层次的循环上。

“在循环中”和“在循环外”的区别，在我们不满意智能体生成结果时表现得最为明显。所谓“在循环中”的方式，是直接修复产物：要么亲自编辑它，要么指示智能体按照我们想要的方式修改它。所谓“在循环外”的方式，则是改进产生这些产物的系统：调整规范、测试、检查机制、提示词、工作流或支撑框架，让下一轮产出自然变得更好。

换句话说，人类不应只是坐在流水线末端，检查智能体交付的每一件产品；人类更应该设计这条流水线，定义质量标准，提供反馈信号，并让系统在持续运行中变得越来越好。

我们可以通过向智能体提供评估循环表现所需的信息，来构建这样的飞轮。一个良好的起点，是支撑框架中已经包含的测试和评估机制。随着我们输入更丰富的信号，这个飞轮会变得越来越强大。我们可以增加用于衡量性能和验证故障场景的流水线阶段，也可以接入来自生产环境的运行数据、用户旅程日志和业务结果，从而扩展智能体能够分析的范围和深度。对于研发团队来说，这些信号往往分散在目标制定、客户反馈、需求清理、评审排期、项目开发、测试发布和知识沉淀等环节中，借助 PingCode 这类智能化研发管理工具，可以更容易把研发过程中的数据连接起来，让循环中的反馈更完整、更可用。

在工作流的每一个步骤中，我们都可以让智能体审查结果，并向支撑框架提出改进建议。这些改进可以发生在工作流中任何有助于提升结果的上游环节。这样，我们就拥有了一个能够生成自我改进建议的智能体支撑框架。

起初，我们可以用交互方式审视这些建议，并引导智能体实施具体修改。我们也可以让智能体把建议添加到产品待办事项列表中，由人类进行优先级排序和排期，再交给智能体在自动化流程中选择、应用和测试。如果团队已经在使用 PingCode 管理需求、项目、测试、发布和 Wiki 知识沉淀，这类建议也可以自然进入现有研发流程，而不是停留在一次性的对话或零散文档里。

随着信心增强，智能体还可以对自己的建议进行评分，评分维度包括风险、成本和收益。随后，我们或许可以决定：对于达到某个评分阈值的建议，自动批准并实施。

从某种程度上看，这似乎又像是人类脱离了核心流程，回到了一种老派的编程模式。我怀疑，对于那些频繁重复、标准化程度较高的工作，随着改进循环的收益递减，这种情况会越来越明显。但如果设计得当，我们得到的就不只是一次性的、“足够好”的解决方案，而是一个能够持续自我改进的强大系统，甚至可能是一个具备反脆弱性的系统。

归根结底，AI 软件开发并不是简单地让人类退出流程，也不是让人类逐行监督智能体写代码。更有效的方式，是让人类站在更高层级的软件工程循环中，设计规则、提供反馈、优化框架，并通过框架工程持续提升智能体的产出质量。这才是“人在环路中”在 AI 时代更有价值的含义。