门户首页
人机融合式软件开发系列 · 3 / 6 · 分析与设计

分析与设计：方法化引导保质量

设计阶段 AI 的"自由度"最大，也最危险——给它"自己想"它就自由发挥出黑箱架构。 答案不是"限制 AI"，是给它方法——Attribute-Driven Design (ADD) 引导的 LLM（Large Language Model，大语言模型）架构设计 (Cervantes et al. TSE 2026) 把方法变成 prompt 一部分。 本页讲 2 类核心活动（AKM + 组件生成）+ ADD 引导法 + 3 个设计阶段特有挑战。

生成时间：2026-09-02 20:54 · 生成 Agent：MiniMax Code (LLM: MiniMax-M3) · 载体：agentsoft-research-platform teaching-web-platform

概览

2
核心活动
3
ICSA 论文
1
ADD 方法
10%
缺失致命

第一篇 · 2 类核心活动

Part 1 · 2 卡：AKM + 组件生成
设计阶段人机融合集中在 2 类活动——架构知识管理（沉淀）+ 架构组件生成（产出）。
第 3 讲 · 1 活动 + 1 论文

活动 1：架构知识管理 AKM（ICSA 2024）

Dhar 等（IIIT Hyderabad, ICSA 2024——ICSA = IEEE International Conference on Software Architecture，软件架构国际会议）探索 LLM 能否生成记录架构决策理由（architecture design decisions, ADD reasoning）的文档。本卡标题里的 AKM = Architecture Knowledge Management，架构知识管理（记录"为什么这么设计"的知识与理由）。

关键发现
  • 经微调的小模型可在企业内网部署（解决"私有代码不可外发"问题）
  • 能有效辅助人类架构师记录与反思架构知识——不是替代，是"知识沉淀的副驾驶"
  • 传统痛点：架构决策常隐式散落文档，维护成本高，新人上手难
AI 在 AKM 的角色
角色 AI 做什么 人类做什么
起草者 从 commit / PR / Slack 抽取决策上下文 审 + 改写为 ADR 模板
补全者 从已有 ADR 找空白、建议补充 决定补什么 / 不补什么
检索者 按关键词 / 上下文找相似决策 判断是否真的"类似"
关键定位：AKM 这块 AI 做得最好——因为它是"文本转文本"的任务，跟 LLM 训练分布高度一致。风险在"AI 写出的 ADR 真的反映了当时决策"——这是"幻觉"问题，需要人类用"我自己当时怎么想"来对照。
下一卡：组件生成 ← 返回入口 基础：Dhar et al., ICSA 2024
第 3 讲 · 1 活动 + 1 方法

活动 2：架构组件生成（ICSA 2025） + ADD 引导（Cervantes TSE 2026）

Arun 等（ICSA 2025）评估 LLM 生成架构组件（如 serverless 函数）的能力——跨多个开源仓库显示"架构师 + 开发者 + LLM"协作可取得有前景的自动化结果。

问题：自由发挥会"想出"什么？

业界实践中明确指出（ZOOZ Engineering 2024）：LLM 缺乏真实约束、权衡、长期可维护性的内部系统模型；若让它设计微服务 / 分布式系统，缺失的 10% 恰是接口失配、错误流消失、安全空洞所在。

解法：Attribute-Driven Design (ADD) 引导

Cervantes, Kazman, Cai（2026, IEEE TSE——TSE = IEEE Transactions on Software Engineering，软件工程领域顶级汇刊，"Better Together"）提出用 ADD 方法引导 LLM：

步骤 做法
1 给 LLM 显式 ADD 描述（attribute-driven → quality attribute → 架构决策）
2 给 LLM 一个"架构师人格"（persona）
3 LLM 协作产出结构化迭代计划 + 详细架构文档
4 双重验证：① 与已验证方案对比 ② 4 位职业架构师评审
flowchart LR A["① 给方法（ADD）
显式 ADD 描述
quality attribute → 架构决策"] --> B["② 给人格
架构师 persona"] --> C["③ 产出架构
结构化迭代计划
+ 详细架构文档"] --> D["④ 双重验证
与已验证方案对比
+ 4 位职业架构师评审"]
图 1 · ADD 引导 LLM 架构设计 4 步：给方法 → 给人格 → 产出架构 → 双重验证
"方法化引导"的核心洞察：LLM 不知道怎么设计，但能按方法执行——你给它 ADD 的脚手架，它就能生成符合架构驱动方法论的产物。"方法 + 人格 + 验证"三件套比"更强的 LLM"对设计质量影响更大。
下一卡：3 挑战 回 §2 需求 基础：Arun et al. ICSA 2025 + Cervantes et al. TSE 2026

第二篇 · 3 个设计阶段特有挑战

Part 2 · 1 卡：理解系统 / 可解释性 / 正确≠合适
设计阶段的挑战比需求阶段更"致命"——一个错误架构要花几个月才能发现。
第 3 讲 · 3 挑战 + 1 警示

3 个设计阶段特有挑战

挑战 1 · AI 不"理解"系统，只预测词
  • LLM 缺乏真实约束、权衡、长期可维护性的内部系统模型
  • 设计微服务/分布式系统时，缺失的 10% 恰是接口失配、错误流消失、安全空洞所在
  • "Vibe coding"式模糊需求直接要架构，是把人推入"怀疑、困惑、被动修 AI 架构"的最痛角色
挑战 2 · 可解释性缺失
  • 设计制品（UML、状态机）若作为黑箱生成、缺乏需求—设计可追溯链接与决策理由
  • 在受监管领域直接转化为合规风险（IST 2026 调查：受监管领域"高可解释性负担"占 92.5%）
挑战 3 · 正确 ≠ 合适
  • LLM 的"自信"是概率而非能力
  • 架构需推理而非模仿，故人类必须"stay the architect, let LLM be the labor"
设计阶段的心法：需求阶段是"AI 写初稿、人定稿"；设计阶段是"人给方法、AI 照做、双方共同验证"。设计阶段的协作主体是方法（ADD、ATAM）——AI 是方法的执行者，不是方法的创造者。
下一篇：实现 ← 返回入口 警示：ZOOZ Engineering 2024