AI写代码时,如何思考DevEx

多客科技

作者：微信文章



AI时代，开发者需更注重业务理解、架构设计、AI友好文档、双层代码审查及预合并质量门，以提升AI体验，确保安全并缩短开发周期。

译自：How To Think About DevEx When AI Writes the Code[1]

作者：Ankit Jain

AI 接管开发者编写代码的工作并不会使开发者变得多余，但它从根本上改变了成为一名软件工程师的意义[2]。

在 AI 时代之前，开发者体验侧重于改进工具[3]和优化工作流程[4]。 开发者们拥有了更完善的集成开发环境 (IDE)，简洁的键盘快捷键，美观的仪表板，易于使用的命令行界面 (CLI)，自助式开发者门户，更流畅的入门流程以及直观的任务管理流程和工具。
AI 体验的崛起

真正的 DevEx 问题——不稳定的测试、技术债务、不一致的环境和过时的文档——仍然存在，并将继续重要，但方法将转变为 AI 体验 (AI-X)。

AI-X 意味着专注于：

• 定义详细的业务需求。• 设计模块化和可扩展的架构。• 创建对 AI 友好的文档。• 使用双层代码审查。• 使用预合并质量门（例如，代码检查器和测试）来教导 AI 约束。

比较 DevEx 和 AI-X 的表格。DevEx：手动编码；人工/CI 测试；以同行评审为中心；缓慢的手动批准部署；日志/指标/部署后反馈；对问题做出被动响应。AI-X：AI 建议或配对编程；AI + 本地测试；混合 AI 评审；快速、自动化、分阶段的部署；倾斜反馈，预测性警报；主动自动缓解。[5]
我将解释这些对于正在向 AI-X 领域过渡的软件工程师[6]和架构师[7]意味着什么。
1. 定义详细的业务需求

既然编写代码不再是优势，软件工程师必须具备强大的产品思维能力，并深刻理解业务问题。 他们必须清楚地定义功能，用通俗易懂的英语解释它们，并将它们分解成小步骤。

使用 AI 代码生成，您的需求实际上变成了决定输出的提示。 模糊的需求将产生模糊的代码（类似于垃圾进，垃圾出[8]）。

上下文窗口是 AI 的最大局限性之一。 尽管这种情况会随着时间的推移而改善，但如今，无法为 AI 系统提供所有可能的业务上下文。 您有责任为任何工作提供“适当的上下文”。

与可能会表达不确定性的人类开发者不同（“我认为你想要 X，但让我确认一下”），AI 模型倾向于取悦他人，并将每个解决方案都呈现为最终的。 他们提出的问题不够多，并且对在没有足够上下文的情况下构建任何东西过于自信。

示例： 指定“实施用户权限”，AI 可能会生成一个具有管理员/用户角色的基于角色的访问控制 (RBAC) 系统。 它不会询问您是否需要细粒度的权限、临时访问控制或与现有身份提供程序的集成。 生成的代码看起来专业且完整，掩盖了它解决了错误问题的事实。

有效的 AI 需求包括：

• 具体的输入/输出格式和数据类型。• 明确的业务规则和边缘情况。• 集成约束和现有系统依赖性。• 性能要求和预期规模。• 错误处理和验证规则。• 安全和合规性要求。

"要用 AI 替换程序员，客户需要准确地描述他们想要什么。我们是安全的。"[9]2. 设计模块化和可扩展的架构

AI 非常擅长全新项目，但企业技术项目通常不是这样运作的。 大多数软件工程都涉及增量改进，这需要了解代码更改对代码其他部分的依赖性和影响。 在某种程度上，AI 擅长局部更改，但可能不太了解全局架构。

因此，开发人员必须设计一个模块化、可扩展且易于发现此类问题的架构。

示例： 重要的是要有一个明确定义的 API 规范和依赖项，以便在进行向后不兼容的更改时，所有依赖服务也能正确更新。

AI 也不擅长做出战略权衡：性能与可维护性、一致性与可用性、安全性与可用性。 由于 AI 工具不了解业务优先级，因此进行架构权衡需要人为判断。

示例： AI 生成了一个微服务架构，因为您在需求中提到了“可扩展性”。 但是您的团队只有三名开发人员，有限的 DevOps 知识和适度的流量。 一个精心设计的单体架构会更合适，但 AI 默认使用它在训练数据中最常见的模式，而不是最适合您情况的模式。
如何为 AI 设计更好的架构

定义约束： AI 需要明确的约束才能生成适当的代码。 架构师定义指导 AI 代码生成的技术标准、模式和边界。

示例： 架构师确定所有服务都必须公开健康检查端点，使用结构化日志记录，为外部依赖项实施断路器，并遵循特定的命名约定。 这些约束指导 AI 生成符合整体系统设计的代码。

创建集成层： 虽然 AI 可以生成单个服务，但架构师可以设计这些服务如何通信、共享数据和协调行为。

示例： 架构师设计了一个具有特定消息模式和编排模式的事件驱动架构。 然后，AI 生成根据已建立的模式正确发出和使用事件的服务。

规划演变： AI 会为当前需求生成代码，而不考虑未来的需求。 架构师会考虑系统如何随着时间的推移而变化，并设计可扩展性。

示例： 架构师设计了一个插件架构，允许添加新的 AI 生成的组件，而无需修改核心系统。 架构框架支持快速的 AI 驱动开发，同时保持系统的一致性。

确保卓越运营： 架构师设计可以在生产环境中进行监控、调试和维护的系统。 他们建立 AI 生成的代码必须遵循的可观测性、部署和运营模式。

AI 仍然可以充当提供想法和探索各种架构策略的平台，但最终需要人为判断。
3. 创建对 AI 友好的文档

最新的文档可以帮助 AI 代理获得所需的上下文，从而进行准确而有效的更改。 AI 代理使用文档的最常见方式是通过向量搜索[10]，这是一种基于语义相似性从数据库中检索信息的方法。

向量搜索可以用作内部 AI 工作流程的一部分，也可以用作模型上下文协议 (MCP)[11] 服务器，以向大型语言模型 (LLM) 提供上下文。 在这两种情况下，文档都必须对 AI 友好。

为此，创建结构化的、上下文丰富的文档，超越代码注释，为 AI 工具提供生成适当代码所需的业务逻辑、架构约束和运营知识。

关键原则： 记录“为什么”和业务上下文，而不仅仅是技术“如何”。

功能规范示例： 不要说：“构建用户身份验证”，而是记录：“用户身份验证必须支持企业客户的 SSO，要求管理员角色使用 2FA，允许消费者用户使用社交登录，并在移动/Web 平台之间维护会话状态。 登录失败的尝试会触发渐进式延迟（1 秒、5 秒、30 秒），并在 5 次失败后锁定帐户。”

架构决策记录示例： 不要说：“我们使用微服务”，而是记录：“ADR-012：选择微服务进行订单处理，因为我们需要独立扩展库存检查（高 CPU）与支付处理（高 I/O），不同的团队拥有不同的服务，并且我们需要故障隔离，因此支付失败不会中断库存更新。”
4. 使用双层代码审查

由于 AI 生成了如此多的代码，开发人员将花费大部分时间在代码审查[12]上。

审查必须分两层进行：

第一次审查是实时审查，发生在“作者”在 IDE 中使用 AI 工具时。 在此审查期间，开发人员在接受 AI 的建议之前，会批判性地评估 AI 的建议。 AI 输出在风格上可能具有欺骗性的自信和一致性，从而很容易忽略隐藏的假设或不正确的逻辑。 如果没有仔细的逐行审查，开发人员可能会冒着发布以后更难发现的错误或漏洞的风险。

我们需要更好的工作流程和工具来帮助开发人员有效地处理此步骤。 例如，IDE 可以突出显示假设或提示开发人员验证它们。 AI 可以通过解释其推理或标记边缘情况来提供帮助，但这远非万无一失。

第二次审查类似于由同行完成的传统代码审查。 即使有 AI 参与，人工监督仍然至关重要。 同行评审可以发现更广泛的架构问题、对业务逻辑的误解以及 AI 可能完全错过的集成风险。

代码审查也是团队的记录保存功能[13]，确保团队内的共享理解、一致的标准和知识转移。 事实上，随着 AI 生成更多的样板代码或例行代码，人工审查员将需要更多地关注设计、正确性和可维护性。
5. 使用预合并质量门教导 AI 约束

将代码检查器、格式化程序和测试框架从简单的验证器转变为上下文指南，从而教导 AI 关于您的系统的模式、约束和业务逻辑。
增强的代码检查器

创建代码检查规则，以强制执行您的特定设计模式和业务约束。

示例： 当新的 API 端点不包含速率限制中间件时，自定义 ESLint 规则会标记，从而教导 AI 所有端点都需要此保护。
上下文格式化程序

• 模式感知格式： 配置格式化程序以强制执行架构一致性，而不仅仅是语法。• 文档集成： 格式化代码以突出显示已记录的模式和关系。

示例： 一种强制执行一致的导入顺序（域 → 基础设施 → 外部）的更漂亮的配置，以便 AI 可以从代码结构中学习您的分层架构。
智能测试

• 行为驱动的测试名称： 编写解释业务场景（而不仅仅是技术断言）的测试描述。• 约束文档： 使用测试来记录 AI 应该理解的业务规则和边缘情况。

示例 1：业务感知测试：
test('premium_users_bypass_rate_limiting_but_still_get_logged_for_monitoring', () => {
  // Test teaches AI about user tiers AND monitoring requirements
});
示例 2：架构约束测试：
test('all_external_api_calls_must_include_circuit_breaker_pattern', () => {
  // Test enforces and teaches AI about resilience patterns
});AI-X：在不降低安全性的前提下缩短循环

AI-X 方法将您的开发工具转变为 AI 训练系统，该系统不断强化您的架构决策、业务规则和质量标准。 开发者体验是关于“让开发者开心”，而 AI 体验是关于“在不损失安全性的前提下缩短循环”。

AI 将变得更有能力处理诸如代码迁移[14]和提高测试覆盖率之类的平凡任务，但它将继续需要开发人员来进行更好的架构设计和决策。

这意味着构建将更改与反馈紧密结合的系统，使回滚路径以及持续集成和交付成为开发人员工作流程的核心，并设计低摩擦、高信任的自动化。
引用链接

[1] How To Think About DevEx When AI Writes the Code:https://thenewstack.io/how-to-think-about-devex-when-ai-writes-the-code/
[2]成为一名软件工程师的意义:https://www.aviator.co/blog/software-engineering-ai-2027/?utm_source=tns&utm_medium=content&utm_campaign=q2-2025-tns-article-3-aviator-software-engineering-2027&utm_term=net-new&utm_content=awareness
[3]改进工具:https://thenewstack.io/platform-engineering-vs-devops-misses-the-point
[4]优化工作流程:https://thenewstack.io/the-anti-metrics-era-of-developer-productivity/
[5]:https://cdn.thenewstack.io/media/2025/07/fea14f13-devex-aix-table.png
[6]软件工程师:https://thenewstack.io/software-development/
[7]架构师:https://roadmap.sh/software-architect
[8]垃圾进，垃圾出:https://en.wikipedia.org/wiki/Garbage_in,_garbage_out
[9]:https://cdn.thenewstack.io/media/2025/07/77a2e739-ai-developers-meme.png
[10]向量搜索:https://thenewstack.io/top-vector-database-solutions-for-your-ai-project/
[11]模型上下文协议 (MCP):https://thenewstack.io/model-context-protocol-a-primer-for-the-developers
[12]代码审查:https://www.aviator.co/flexreview?utm_source=tns&utm_medium=content&utm_campaign=q2-2025-tns-article-1-aviator-flexreview&utm_term=net-new&utm_content=awareness
[13]代码审查也是团队的记录保存功能:https://www.aviator.co/podcast/code-reviews-looks-good-to-me?utm_source=tns&utm_medium=content&utm_campaign=q2-2025-tns-article-3-aviator-adrienne-tacke-podcast&utm_term=net-new&utm_content=awareness
[14]代码迁移:https://www.aviator.co/blog/aviator-agents-code-migration/?utm_source=tns&utm_medium=content&utm_campaign=q2-2025-tns-article-agents-blog&utm_term=net-new&utm_content=awareness