AI 驱动软件开发中的模式

HN LLM Code Research 2026-10-30T09:53:03.130762

在 Red Hat 第三届瑞士开发者联合会上的演讲，2026 年 10 月 27 日。

大家好，我叫 Adrian Kosmaczewski，是 Red Hat 瑞士的高级架构师。

在日常工作中，我帮助软件开发者每天使用 Red Hat 工具，更快地打造更好的软件。我可以自信地说，我们正站在软件工程史上一个引人入胜的交汇点。

一边是云原生开发惊人的能力与复杂性：Red Hat OpenShift、Quarkus 微服务、分布式系统，以及持续交付与集成。另一边是生成式 AI 编程助手的爆发式增长——从运行在 OpenShift AI 上的开源模型，到 Cursor 这类消费 Claude、Grok 或其他大语言模型（LLM）的智能 IDE。

承诺令人兴奋：更快地造出更好的软件。但你们中有多少人坐下来让 AI 助手构建一个可扩展的 Quarkus 微服务，结果却看着它自信地生成一堆混乱、无法编译的东西？你并不孤单。

大语言模型是强大的模式匹配引擎，但它们不像软件工程师那样思考。当我们用非结构化、“凭感觉”的提示词去处理复杂的企业系统时，本质上就是在掷骰子。我们把理解外包给了一台有补全偏差的机器——它只想把序列补完，哪怕这意味着跳过关键的中间步骤。

为了解决这个问题，业界正在快速探索结构化的 AI 交互方法。例如，AI 教育者 Matt Pocock 主张在他的 AI 工作流中坚持严格的软件工程原则：在制定计划之前，用毫不留情的“拷问我”式对话达成共识，并高度依赖测试驱动开发（TDD）——让 AI 先写一个失败的测试，再实现代码，以防止模型轻易“作弊”。

Lauren Tan 开发了 Pstack，这是一个 Cursor 插件，能把 AI 编程代理转变成一套结构化的工程工作流，用到了 23 种不同的技能。

Addy Osmani 提出的“循环工程”（Loop Engineering）框架，点出了两个隐患：一是“意图债务”——缺少上下文时，AI 会凭自信瞎猜；二是“认知投降”——开发者放弃独立判断，盲目接受 AI 的输出。他把工作流拆成两段：AI 负责的“内循环”，以及人类负责、严格把关的“外循环”。

引言

今天，我们聚焦 CHIRON CODEX 交互模式，它面向 AI 增强的软件开发。

这些模式由牛津大学的 Graham Lee 博士创建，把“我们如何与 AI 对话” formalize（形式化）下来——很像 1995 年“四人组”（Gang of Four）的《设计模式》一书，为面向对象软件设计提供了一套共享词汇。

每个模式都遵循统一结构：

1. 意图（Intent）

2. 动机（Motivation）

3. 实现（Implementation）

4. 示例（Examples）

5. 后果（Consequences）

6. 相关模式（Related Patterns）

背后的总体理念，是现代开发者的一句战斗口号：不要把你的理解外包给计算机。 相反，要成为“软件半人马”（Software Centaur）——一个主动 orchestrate（编排）AI 能力、以此增强自身专业能力的开发者。

这些模式长这样；每个模式都有单独的 PDF 说明，作者还在不断补充。这是一项进行中的工作。

先提醒一句：我相信你们很多人每天都在工作中用到其中不少模式，只是没用这些名字；等我在这次分享里描述它们时，你们会认出来。Chiron Codex 的想法，就是给它们命名、把它们形式化，并帮助大家把这些想法传达给其他同事。这正是“四人组”设计模式背后的思路——这也是为什么今天当我们听到“单例”（Singleton）或“工厂”（Factory）时，大家都明白在说什么。

掌控上下文与复杂性

任何 AI 模型最关键的局限，是它的工作记忆，也就是“上下文”。如果你把无关文件塞满上下文，模型的自注意力机制就会混乱。

要解决这个问题，可以套用语义结构模式。代码库的物理组织方式，直接决定了 AI 发现相关信息的效率。不要把 OpenShift 项目按技术分层来组织——比如建一个通用的 “Controllers” 或 “Models” 目录——而要让项目结构反映问题域的术语体系。把源代码按问题域的结构来组织（这是领域驱动设计中的概念），助手就能精准定位相关代码，而不会把无关文件拖进上下文。

但即使语义结构再完美，也不该让 AI 翻遍所有代码。这时引导式导航模式就派上用场了。你需要把助手的注意力严格聚焦在相关代码上，明确提示它去特定文件里搜索，避免它把整个项目都读进上下文，造成注意力稀释。在提示词里塞入无关的源文件，很可能导致结果变差——模型会把上下文中靠前的内容当作高度重要的信息。在 OpenShift 这种庞大环境里，部署配置、密钥、服务和路由一应俱全，你必须明确引导助手。

反复迭代一个问题时，上下文窗口难免会被污染。在 Transformer 模型中，自注意力层把输入文本流转换成 token 向量，并为整个对话历史（包括你所有失败的尝试）中的输入 token 分配关联权重。这就是 AI 开始固执地重复错误的原因。解决办法是干净状态模式：在继续大任务或开始新任务之前，显式清空模型的上下文。这个简单的动作能防止模型去关注之前步骤中的无关 token，保持生成速度，并让 AI 紧紧盯住当前目标。

规划与发现机会

软件设计是一门做权衡的艺术，打造正确的软件需要深入理解组织的真实需求。而 AI 模型如果放任不管，天生就会选择阻力最小的路径。

为了解决这个问题，得先运用 Stop and Plan（停下来规划）模式。动手写代码之前，先做规划：探索问题本身，探索解决方案，再把两者更好地连接起来。编码助手不会自动理解系统背后复杂的人类需求，所以这些环节最好通过持续对话来理清。在规划阶段，可以使用 Disclose Ambiguity（揭示模糊性）模式，让模型列出提示词里隐含的假设，或者指出完成任务还缺哪些信息。把书面语言中不精确的表述转成精确的指令，这一步至关重要。所以在写下第一行 Java 代码之前，先让 AI 就你的核心差异化优势向你提问。

问题清晰之后，再用 Ask for Alternatives（寻求替代方案）模式。需要新增一个组件时，不要只告诉模型“加个缓存”，而是让它给出多种方案，比较各自的优缺点、成本和 OpenShift 部署复杂度。你甚至可以来一场“Bake Off”（对比测试）：让不同的助手（或完全不同的模型）分别给出替代方案，看看不同的能力如何解读你的问题描述。

面对大型功能，千万不要一次性全部委托出去。运用 Baby Steps（小步推进）模式，把大任务拆成更小、更容易掌控的块，这能大幅降低你的预期与模型输出出现偏差的风险。拆解过程中，你会遇到一些实现细节，它们可能让你偏离重点。这时用 Defer the Details（推迟细节）模式：让模型记录待解决的问题，这样你就能严格专注于眼前这一个小问题。同样，用 Write Down TODOs（记录待办）让助手记下架构探索或后续调研事项，方便以后回头处理。

控制思维链与质量

AI 助手经常忽略中间产物，因为它们急于直接生成最终代码。为了控制模型的“思维链”，我们采用“保存输出到文件”模式。这样可以强制助手生成中间声明性文本产物，比如 PlantUML 图表、架构决策记录或 Kubernetes 清单计划，并把它们直接保存到你的代码仓库里。生成这些设计会迫使模型放慢脚步、分步推进，并在生成过程中提供明确的检查点，让你可以停下来验证并纠正 AI 的走向。这样就把混乱的代码生成变成了严谨的工作流。

要验证工作成果，可以依靠“生成文档”模式。让模型编写一份代码阅读指南，详细说明入口点在哪里、实现中的关键部分有哪些、哪些文件包含与外部服务的接口。然后你就可以把期望的行为与实际实现进行对比。

当模型出错时，不要只是默默修好。用“指出错误”模式明确告诉模型哪里失败了，提供堆栈跟踪或视觉证据。如果模型开始原地打转，就用“介入”模式：停止生成，自己动手修复问题，把缺失的关键信息补充到上下文中。此外，还可以利用“模型评审”模式，把助手的角色从创造者切换为批评者，让它评估自己的工作是否遗漏了某些行为或存在空壳实现。最终，你应该始终“信任测试”：你来审查模型生成的测试，让测试套件成为最终的裁判，而不是依赖模型自信满满的完成报告。

标准化与持续改进

作为云原生开发者，我们在 CI/CD、安全和性能方面依赖严格的标准。我们必须确保 AI 遵守这些硬性约束。

首先，我们用“用工具替代凭感觉”（Replace Vibes with Tools）模式。当问题的一部分已经有明确规范且结果确定时——比如跑 Maven 构建、执行测试、应用 Kubernetes 配置——不要用生成式方法去“摸索”答案。给助手提供可复现的工具或脚本，让它直接调用。这样既省下探索步骤所需的上下文开销，又能让你对 CI/CD 流水线中的关键节点拥有确定性控制。

接着，我们要“给出示例”（Give Examples）。大语言模型（LLM）本质是模式匹配引擎，提示词相当于一个前缀，用来收窄模型的注意力范围。如果你希望 Quarkus REST 端点按某种特定结构组织，就给模型看一段带注解的、结构完全一致的代码片段。把这些片段用明确的 <example> 和 </example> 标签包起来，表明它们是参考范例，而不是核心问题描述的一部分。

当你不得不纠正 AI 时，别让这番功夫白费。用“提取提示词”（Extract Prompt）模式。把那次具体的纠正提炼成一个独立、可复用的提示词，清楚写明完成任务所需的步骤；然后只用这个提取出来的提示词调用智能体，完成那个特定的中间步骤，不把无关上下文拖进来。

最后，用“模型反思”（Model Reflects）模式，让 AI 成为改进工作流的主动参与者。一次复杂会话结束时，让模型找出交互中的重要变化或转折点。提示它回顾自己引入、诊断并修复的 bug，并让它给出建议：后续迭代中如何避免这些错误。再结合“记住我们做过什么”（Remember What We Did），把会话中做出的选择和纠正主动记录下来，写入持久化存储（比如 markdown 文件或数据库），这样助手在后续任务中就能吸取这些经验。

用“半人马”模式加固安全

在采纳这些结构化工作流的同时，我们还必须处理企业软件最关键的一环：安全。如果我们盲目信任生成式 AI 的输出，它可能无意中引入漏洞。

好在我们可以借助这些交互技巧，把安全编码实践直接嵌入 AI 辅助开发流程。

有针对性地组合运用这些模式，就能让最终交付的软件始终保持安全可控：

• 提供示例：用这个模式强制要求在设计阶段就考虑安全性。比如，限定模型输出——要求它生成任何部署架构文档时，都必须包含“安全考量”章节。

• 用工具替代感觉：绝不要指望生成模型去猜代码是否安全。应该给编程助手配置确定性的分析工具，专门用来发现 API 误用、安全漏洞和其他软件缺陷。

• 让模型做审查：可以把 AI 的角色从代码生成者切换为安全审查者。写一个具体的提示词描述审查标准，明确要求助手重点关注 OWASP Top Ten 安全风险。可以明确要求评估代码正确性，以及任何安全或内存管理问题。

• 人工复核：说到底，人的监督是防范漏洞的最后一道防线。检查生成结果时，要采取策略性的、基于风险的方法来审查。把人的注意力集中在那些一旦不达预期就会带来最大麻烦的标准上，比如关键的安全和合规问题。

把这些具体模式分层融入工作流后，安全就不再是事后才想起来、指望 AI 碰巧做对的事情，而变成了贯穿生成过程每一步的硬约束，时刻引导助手。

现场演示：在 Cursor 中构建软件半人马

让我们把这些概念串起来，看看在 Cursor 这个 AI 驱动的 IDE 中实际是什么样子。

在 Cursor 里，我们可以用专门的 Markdown 配置文件——.mdc 文件——把这些半人马模式永久保存下来，放在 .cursor/rules/ 目录中。这些文件相当于 AI 在项目中的长期记忆。

假设我们刚花了 15 分钟，反复和 AI 较劲，才用 SmallRye Health 把 OpenShift 健康检查正确实现出来。我们可不想再经历一次这样的折腾。

第一步：提取知识

首先，我运用 模型反思与提取提示词（Model Reflects and Extract Prompt） 模式。就在 Cursor 的聊天窗口里，我输入：

“回顾我们最近关于 SmallRye Health 实现的几条提示词。反思在 OpenShift 就绪探针上犯的错误，并提取出一份全面、可复用的系统提示词，用来强制落实我们要求的 Quarkus 健康检查标准。”

AI 会分析我们的对话过程，输出一套清晰、结构化的指令。

第二步：创建工具

接下来，我运用 给出示例（Give Examples） 模式。我新建一个文件，命名为 .cursor/rules/quarkus-health.mdc。

在文件顶部，我加上一段 YAML frontmatter，给 Cursor 提供上下文：

---
description: Standards for implementing Quarkus health checks and OpenShift readiness/liveness probes.
globs: src/main/java/**/*HealthCheck.java
alwaysApply: false
---

在这下面，我粘贴从 AI 那里提取的提示词，并且关键的是，我还加了一段来自我们代码库的具体示例，展示完美的存活探针（Liveness）和就绪探针（Readiness）实现。

第三步：收获回报

我们刚刚把团队的“记忆”外化到了 IDE 里。接下来，我运用 全新开始（Clean Slate） 模式，打开一个全新的聊天窗口。我只输入一句：“创建一个数据库连接健康检查。”

因为我这个请求涉及的文件以 HealthCheck.java 结尾，Cursor 会自动把我们的 .mdc 规则文件加载进 AI 的上下文中。模型在生成任何一个 token 之前，会先读取我们的架构约束和精确的代码示例。它完美地使用我们指定的 OpenShift 注解，实现了数据库健康检查。

我们没有靠感觉碰运气。我们管理了上下文，提供了示例，提取了可复用的流程，并把它固化到系统里。AI 没有靠猜，它遵循了我们设计好的约束。整个设置花了不到三分钟，却能在后续省下好几个小时的代码审查时间。

结论

要成为软件半人马（Software Centaur），你必须从根本上改变自己与人工智能的关系。

如果你把 AI 当成永远不会出错的先知，就会不断累积“意图债”，最后沦为认知投降的牺牲品。更好的做法，是把它看成一位能力极强、但偶尔健忘的初级队友。

用语义结构（Semantic Structure）和引导式导航（Guided Navigation）严格管住模型能看到什么。动手之前先停下来做计划（Stop and Plan），在拍板之前先要备选方案（Ask for Alternatives），把可选路径彻底摸清。强制 AI 把输出保存到文件（Save Output to File），以此建立严格的评审节点。持续提取提示词（Extract Prompts），并要求模型复盘自己的失败（Model Reflects），把团队的标准固化成可复用的资产。

采用 CHIRON CODEX 的这些模式，你就不再把自己的理解外包给计算机。你重新拿回软件设计流程的完整控制权，把原始的生成能力编排起来，快速构建、测试并部署健壮而复杂的云原生应用。

那么，现在就去掌控上下文，更快地构建更好的软件吧。

查看原文