当前位置：首页 > news >正文

AI驱动的软件工程（上）：人机协同的设计与建模

news 2025/7/14 7:21:19

📚 系列文章导航
AI驱动的软件工程（上）：人机协同的设计与建模
AI驱动的软件工程（中）：文档驱动的编码与执行
AI驱动的软件工程（下）：AI辅助的质检与交付（待更新）

写下这个标题时，我其实有些感慨。十多年的软件开发生涯，我从Java Web写到分布式架构，自认为对“软件工程”这四个字有几分心得。但最近一年多，随着我一头扎进AI工程化的浪潮，我发现自己对这四个字的理解，正在被彻底重塑。

我们都见证了AI，尤其是大语言模型（LLM），在“辅助编码”这个单点任务上的惊人能力。它就像一个学识渊博、不知疲倦的“结对程序员”，能随时为我们提供代码片段、解释API、甚至调试一些棘手的问题。但当我们试图将这种能力从“辅助”升级为“主导”，让AI来承担一个完整项目的大部分开发工作时，几乎所有人都会遇到同样的困境：

上下文的无情漂移：聊着聊着，AI就忘了我们最初的需求是什么。
创造力的无序发散：它会热情地提出各种技术方案，即便这些方案与我们的目标南辕北辙。
一致性的反复拉扯：今天它遵循了这个设计，明天在写另一个模块时又完全是另一套思路。

这些问题，本质上源于我们试图用“对话”的方式去管理一个“工程”项目。这行不通。一个严肃的软件项目，需要的是纪律、结构和可预测性，而这些恰恰是开放式对话的天然敌人。

在经历了不少失败的尝试和痛苦的踩坑后，我摸索出了一套行之有效的方法论。它不再是简单地把AI当成一个聊天机器人，而是将其视为一个需要被“管理”和“训练”的初级开发者。我们不跟它“聊天”，而是给它“派活”，用一套严格的工程流程来约束它的行为，用外部化的文档来构建它的“长期记忆”。

这个系列文章，就是我对这套方法论的全盘复盘。我将分享如何从一个模糊的想法开始，通过人机协同，一步步构建出一个结构清晰、代码可靠、可交付的软件项目，其中超过90%的繁重工作都由AI完成。

今天，我们先从源头开始——设计。在敲下第一行代码之前，我们如何与AI一起，将脑海中模糊的灵感，转化为一套精准、完整、可执行的工程蓝图？这就是我们要解决的第一个问题。

从“双人舞”开始：重塑人机协作的定位

在深入流程之前，我们必须先在理念上达成一个核心共识：高质量的人机协同，不是一方主导、一方听令的“独奏”，而是一场分工明确、配合默契的“双人舞”。

在这个舞池里：

人（我）的角色：是架构师、决策者和艺术总监。我负责提出项目的核心愿景，把握产品的灵魂和方向。在每一个关键的技术岔路口，由我来做出最终决策。我的经验、直觉和对业务需求的深刻理解，是AI无法替代的。
AI的角色：是高效的执行者、知识渊博的顾问和不知疲倦的草案起草者。它负责将我的愿景快速转化为结构化的文档草案，基于其庞大的知识库提供技术方案选项，并承担所有繁重、重复但至关重要的细节撰写工作。

这种定位的转变至关重要。它意味着我不再期望AI能“猜”到我的想法，我也不再因为它无法做出完美的架构决策而感到沮丧。我需要做的，是构建一个舞台，设计好舞步，让AI能够在这个舞台上，精准地完成它被赋予的任务。

而这个“舞台”和“舞步”，就是我们接下来要详细拆解的三阶段设计流程。

设计的三幕剧：从模糊到具体的结构化流程

软件设计本身就是一个从混沌到有序的过程。为了让AI能够稳定地参与其中，我将整个设计过程严格划分为三个独立的、不可逾越的阶段，就像一出戏剧的三个幕章。每一幕都有其独特的任务、角色互动和关键交付物。

第一幕：需求分析（定义“做什么”）
第二幕：系统设计（定义“高层怎么做”）
第三幕：详细设计（定义“底层怎么做”）

这种“分而治之”的策略，是驾驭AI的黄金法则。让AI一次只专注于一个清晰定义的任务，其输出质量会得到指数级的提升。更重要的是，它为我提供了三个关键的“控制阀门”，在每个阶段结束时，我都有机会进行审查、修正和批准，确保项目始终航行在正确的航线上。

现在，让我们拉开第一幕的大幕。

第一幕：需求分析 - 定义纯粹的“What”

目标：将一个模糊的业务构想，转化为一份清晰、准确、无歧己义，且完全不涉及任何技术实现的《需求规格说明书》。

这是所有工作的基石，也是最容易被AI带偏的一步。AI的天性是解决问题，它总会迫不及待地抛出它所知道的技术方案。而我，作为“总监”，在这一阶段的核心职责，就是坚定地捍卫需求的纯粹性。

我的实践流程是这样的：

我先提出初始构想。比如，我对AI说：“我要做一个AI Agent应用框架‘AgentWeaver’，用来帮助开发者快速构建能处理复杂任务的AI应用。”
AI开始提问和探索。它会像一个业务分析师一样，试图澄清模糊点：“这个框架的目标用户是开发者还是非技术人员？” “需要支持哪些类型的文档输入？”
AI起草初稿，然后我来纠偏。这是最关键的一步。AI的初稿几乎必然会包含技术细节，比如它可能会写：“后端使用FastAPI，集成LangChain作为核心引擎，并通过Docker部署。”

这时，我必须立刻叫停，并给出明确的指令，把它拉回到“做什么”的轨道上。我会这样对它说：

“不，这个版本太技术化了。当前是需求阶段，我们必须聚焦于‘What’而非‘How’。请移除所有关于具体框架和数据库的描述。重写文档，只定义功能需求。例如：‘系统应提供一个让开发者定义和执行多步骤工作流的引擎’，‘系统需要支持多种AI模型的接入，如OpenAI和本地模型’，‘系统应具备管理和版本化提示词模板的能力’。”

我甚至将这种引导话术固化成了给AI的指令之一：“如果用户（我）提及具体的技术，你必须礼貌而坚定地将我引导回来，并告诉我‘这是一个很好的技术见解。让我们记下来，在第二阶段（系统设计）时再来探讨’。” 这种自我约束的规则，能确保我们双方都专注于当前阶段的核心目标。
迭代与最终确认。经过几轮这样的拉扯和修正，AI最终会产出一份只包含纯粹功能描述的《需求规格说明书》。

整个协作过程，可以用下面这张流程图清晰地展示：

在第一幕结束时，我会拿到一份高质量的 《需求规格说明书》。在进入下一幕之前，我必须给AI一个明确的信号。我会直接问它，这也是我写在给它的指令里的：“您对这份需求规格说明书满意吗？如果确认，我们就可以进入系统设计阶段了。” 当我回复“确认”后，第一幕才算正式落幕。

这个看似简单的“确认”动作，是一个至关重要的控制门。它锁定了第一阶段的成果，防止AI在后续阶段随意篡改需求，保证了整个设计流程的严肃性和稳定性。

第二幕：系统设计 - 搭建高层的“How”

当需求被清晰地固化下来之后，我们就可以放心地进入技术领域了。第二幕的目标，是基于已确认的需求，将系统的“黑盒”打开，设计其内部的总体技术架构、划分核心模块、确定关键技术选型，最终产出一份 《系统设计说明书》。

在这个阶段，我的角色从产品经理切换为架构师，而AI则成为了我的系统设计师助理。

我的实践流程如下：

我先确立架构原则。我会先给出高层级的指导，比如：“需求已经确定，现在我们来做系统设计。我倾向于一个灵活、插件化的分层架构。” 这为AI的思考框定了方向。
AI提出方案，我来决策。AI会基于我的原则和需求文档，提出1-2种具体的架构方案和技术栈建议，并说明理由。例如，它可能会说：“明白。基于您的方向和需求文档，我建议采用‘LangGraph驱动的分层架构’。技术栈推荐 Python + FastAPI (API) + Streamlit (前端)。核心模块可划分为：AI工厂、文件管理、提示词管理、工作流引擎、日志模块和API网关。”
AI绘制架构图，进行可视化。这是AI最擅长的工作之一。我会让它使用Mermaid语法，生成一张高层级的架构图（类似C4模型的Container图），直观地展示模块及其交互关系。这比单纯的文字描述要清晰得多。

对于我们的AgentWeaver项目，它生成的架构图可能长这样：
我来审批模块划分。我会仔细审查这个架构图和模块列表，确保它遵循了“高内聚、低耦合”的原则，每个模块的职责单一、边界清晰。
生成关键的桥梁：TODO List。在系统设计获得我的批准后，我会指示AI执行一个关键操作：将所有核心模块转换成一份任务清单（TODO List）。例如 [ ] 设计AI工厂模块, [ ] 设计文件管理模块 等。

这份清单看似简单，却是我整个方法论中承上启下的关键一环。它将宏观的系统设计，精确地分解成了下一阶段（详细设计）中一系列可执行、可跟踪的具体任务，确保了从架构到实现无遗漏。

第二幕的出口，同样需要我的明确批准。我会要求AI在产出《系统-设计说明书》和TODO List后，正式向我请求确认：“如果您批准这份系统设计和任务清单，我将开始为第一个模块进行详细设计。” 只有在我确认后，我们才能带着这两份关键产出，进入设计的最后一幕。

第三幕：详细设计 - 深入底层的“How”

如果说系统设计是在绘制城市的地图，那么详细设计就是在为城市里的每一栋建筑绘制施工图。这一幕的目标，是对第二阶段TODO List中的每一个模块进行“显微镜”级别的剖析，明确其内部结构、核心数据结构、类与接口、关键算法与逻辑流程，最终为每个模块产出一份独立的 《[模块名]详细设计说明书》。

在这个阶段，我的角色是技术总监或资深开发者，而AI则扮演一名勤奋的高效软件工程师。

我们严格遵循“清单驱动”的模式：

AI遵循TODO List，一次只做一个。我会明确告知AI，严格按照任务清单，逐一、专注地完成每个模块的设计。我会对它说：“现在开始第三阶段，我们先从‘AI工厂’模块开始。” 这种“单任务”模式能最大限度地保证设计深度和质量。
我提供精细化指导。对于每个模块，我会给出更具体的设计要求。例如，在设计“AI工厂”时，我可能会说：“这个模块需要考虑并发安全，请在设计中说明如何管理模型实例的生命周期。接口设计要清晰，伪代码写清楚核心逻辑即可，不需要完整的Python实现。”
AI产出详细设计文档。对于每个模块，AI都会生成一份独立的Markdown文档，其中必须包含以下核心内容：
- 模块职责：清晰说明该模块做什么和不做什么。
- 核心类图/数据结构：使用Mermaid的classDiagram展示主要的类、它们的属性和关系。
- 关键函数/API接口定义：定义出所有公共的函数或API端点，包括参数和返回值。
- 核心逻辑的伪代码：为最关键的内部逻辑（如模型加载、缓存管理）编写清晰的伪代码。
- 错误处理机制：描述主要的异常情况及其处理方式。
以“AI工厂”模块为例，它生成的类图可能是这样的：

它提供的伪代码可能如下所示：
```
FUNCTION get_model(model_name):// 检查模型是否已被实例化和缓存IF model_name in self.models:RETURN self.models[model_name]// 如果未缓存，则查找配置并创建实例model_config = self.config.get_model_config(model_name)IF model_config is NULL:THROW ModelNotFoundError(f"Configuration for {model_name} not found.")// 根据配置中的provider类型，动态加载对应的模型类provider = model_config.providerIF provider == "openai":model_instance = new OpenAIModel(model_name, model_config)ELSE IF provider == "local_hf":model_instance = new LocalHFModel(model_name, model_config)ELSE:THROW UnsupportedModelProviderError(f"Provider {provider} is not supported.")// 缓存实例并返回self.models[model_name] = model_instanceRETURN model_instance
END FUNCTION
```
我逐一进行Code Review式的验收。在AI完成一个模块的设计后，我会像审查一段真实代码一样，仔细检查其逻辑的严密性、接口的清晰度以及边界条件的考虑。只有在我明确表示“这个模块的设计通过了”之后，AI才会被允许在TODO List中将该项标记为“完成”，并开始下一个模块的设计。