AI工程不难，难的是重塑我们的工作流

IT加油站2026-09-04 18:17287分钟

原文：https://dev.to/ujja/ai-engineering-is-easy-changing-how-we-work-is-hard-39j4（作者 @ujja）

AI工程听起来很高大上。新术语层出不穷：代理式开发、AI原生工程、规格驱动开发，现在又有了AI驾驭工程。不过剥开这些术语的外衣，其实发生了一些真正有用的事情。AI如今能协助处理需求、对产品需求文档（PRD）提出质疑、探索用户体验（UX）想法、思考架构设计、制定实施计划、编写代码并验证结果。

显而易见的问题是AI能做什么。但更有趣的问题是：我们构建软件的方式，准备好迎接它了吗？

工作流正在改变

我们正在探索的一种工作流将开发分为五个阶段：需求、优化、规划、构建与验证。这些阶段本身并非新概念，但现在AI可以参与到每一个环节。它能够处理现有的产品输入，帮助澄清问题，质疑假设，发现PRD中的缺口，然后将一个定义明确的需求转化为计划，并最终分解为实施任务。

这就对需求的质量提出了更高要求。参与项目的人类可能理解“改善体验”意味着什么，因为他们已经就此进行过多次讨论。但AI代理没有这段共享的上下文。它需要的是明确的问题、范围、约束条件、边界情况和预期结果。这并不意味着要编写冗长的规格说明，而是意味着在开始构建之前，就利用AI帮助使需求变得精确。

AI实际上可以成为一个有用、虽然有点烦人的评审者。它会问：当某个部分失败时会发生什么？这个需求是否可测试？文档的不同部分是否存在矛盾？我们还没有考虑什么？它还可以帮助比较PRD的不同版本，或者让一个模型来评审另一个模型的输出，从而更容易发现缺口。关键在于，AI是在帮助我们发现模糊性，而不是替我们做决定。

或许，写代码已不是瓶颈

当我们审视团队的时间究竟花在哪里时，事情就变得更有趣了。复杂的工作在正式开发开始前，往往需要产品、用户体验、需求和工程团队之间进行多轮讨论。这通常是必要的，但也可能造成严重的瓶颈。如果一个AI代理能快速生成可运行的实现，那么等待两周来澄清一个需求，就成了比以往更大的问题。

这表明工程师需要更早地参与进来，而不是只在需求被认为“完成”后才收到它们。用户体验也需要尽早参与对话。一个粗糙的原型或线框图，比又一轮讨论能更快地暴露需求中的缺口，而AI使得创建这些轻量级原型的成本大大降低。需求、用户体验和技术设计可以成为一个迭代循环，而不是一连串的交接过程。

文档越多，不一定越好

面对AI，我们的本能往往是给它更多的文档：更多的PRD、更多的架构图、更多的Wiki页面和更多的上下文。但是，如果多份文档以不同方式描述了同一个功能，我们实际上并没有给AI更好的上下文，而是给了它更多困惑的途径。

AI代理需要的是一个导航系统的方法。一个清晰的项目结构、聚焦的文档、有用的代理指令、解释“为何如此”的架构决策，以及一个组织良好的代码库，这些可能比一份巨大的规格说明有用得多。目标不是把我们知道的一切都塞给AI，而是让AI在需要时能够轻松找到它所需的信息。

工单本身可能就是问题

AI也让我开始质疑我们拆分工作的方式。一个需要数周或数月才能完成的工单，对AI代理来说很难理解，对人类来说，坦率地说，也不是一个特别有效的工作单元。“构建认证功能”就与将问题拆解为密码重置、令牌验证、密码更新以及相关测试截然不同。

这并不是要把每个功能都拆成数十个微小工单。我们只需要工作具有明确的目标、可管理的范围和明确的完成定义。如果某个东西需要数月时间，它可能是一个伪装成Jira工单的项目。

同时，并非所有工作都需要完整的AI生命周期。一个大型功能可能受益于结构化的需求、优化、规划和验证，而一个小型的日常变更可能只需要一个提示词加一个开发者。如果我们对所有事情都应用相同的流程，就有可能用一种官僚主义取代另一种。工作流应该匹配工作的复杂度。

AI 代理需要看到真实系统

还有一个相当根本的要求：AI 代理需要理解真实的系统。只给它产品需求文档（PRD）而不提供相关代码库的访问权限，意味着它仍然在做各种假设。有了代码，它才能找到现有的模式、理解约束条件、复用已有功能，并判断提议的解决方案是否合适。

当然，让 AI 访问源代码会引入安全、许可证、隐私和组织方面的考量，因此 AI 的采用并非仅仅是选择正确模型那么简单。最大的一些障碍与模型本身毫无关系。

一旦多个开发者和 AI 代理并行工作，事情会变得更加复杂。每个代理都有自己的上下文，并基于它当前所见的内容做决策。一个代理可能会改变另一个代理不知道的东西，或者两个代理做出了各自合理但彼此不兼容的决策。这使得良好的工程实践变得更加重要：小步修改、明确边界、良好的测试、频繁的代码审查以及统一的项目规范。