如何和 AI 协作完成架构设计
1. 核心观点
和 AI 协作做架构设计，关键不是让 AI 一次性给出完整方案，而是把 AI 当成：
架构陪审员
方案生成器
风险审查员
文档助手
反方评审者不要直接问：
帮我设计一个 AI 引擎平台架构更好的方式是让 AI 参与整个架构设计流程：
定义问题
澄清约束
领域建模
生成多个方案
比较取舍
反方审查
沉淀文档
生成 ADR架构设计的本质是取舍。AI 可以帮助你扩大视角、补充方法论、发现盲区、组织文档，但最终的业务取舍必须由你完成。
2. 推荐协作流程
2.1 先让 AI 帮你定义问题
不要一上来要求 AI 给方案，而是让它先问问题。
示例提示词：
我要重构 SaaS 系统里的 AI 引擎平台，核心模块包括 Skill、Agent、Workflow、模型管理、知识库、工具调用、评估和计费。
请你不要直接给方案，先帮我梳理这个架构设计必须澄清的关键问题，按业务边界、用户角色、运行时、权限、数据、扩展性、成本、可观测性分类。这一步的目标是避免拍脑袋设计。AI 的价值是帮你把问题域展开，而不是过早收敛到某个方案。
2.2 让 AI 帮你做领域建模
当问题边界初步清楚后，可以让 AI 用领域驱动设计的方式梳理核心概念。
示例提示词：
请用 DDD 思路帮我分析 Skill 模块的领域模型。
要求输出：
1. 核心实体
2. 值对象
3. 聚合关系
4. 生命周期
5. 领域事件
6. 和其他模块的边界
7. 哪些概念不应该放进 Skill 模块你需要重点检查 AI 给出的领域对象是否符合团队的业务语言。
例如 Skill 模块里可能出现：
Skill
SkillVersion
SkillRun
PromptTemplate
ToolBinding
KnowledgeBinding
Evaluation
PermissionPolicy如果这些概念团队能听懂、能讨论、能映射到业务动作，说明建模方向基本合理。
2.3 让 AI 生成多个方案
不要让 AI 只给一个“最佳实践”。架构设计需要比较方案。
示例提示词：
请给我 3 种 Skill 模块架构方案：
A. 轻量 Prompt 管理型
B. 能力运行时型
C. 平台级 Skill Registry + Runtime 型
每种方案说明：
- 适合什么阶段
- 优点
- 缺点
- 技术复杂度
- 未来扩展成本
- 适合的团队规模
- 你推荐哪一种，为什么这一步的目标是看到不同路径的成本和收益，而不是让 AI 替你选择唯一答案。
2.4 让 AI 做反方审查
有初步方案后，不要马上采纳。让 AI 挑刺。
示例提示词：
下面是我的 Skill 架构设计草案，请你以资深架构评审的角度审查。
重点找：
1. 边界不清的问题
2. 未来扩展风险
3. SaaS 多租户风险
4. 权限和安全漏洞
5. 数据模型不合理处
6. 运行时稳定性问题
7. 观测和排障缺口
8. 哪些地方过度设计AI 很适合做结构化风险扫描。尤其是在复杂平台设计里，它可以帮你发现“方案看起来完整，但某些生产问题没有覆盖”的地方。
2.5 让 AI 帮你沉淀架构文档
架构设计不能只停留在对话里。需要沉淀成可评审、可追溯、可维护的文档。
示例提示词：
请把上面的 Skill 模块设计整理成架构设计文档，结构如下：
1. 背景和目标
2. 非目标
3. 核心概念
4. 领域模型
5. 模块边界
6. 执行链路
7. 数据模型
8. 核心 API
9. 权限和租户隔离
10. 可观测性
11. 失败处理
12. 评估和发布机制
13. MVP 范围
14. 后续演进
15. 主要风险和决策记录架构文档里一定要包含“非目标”和“决策记录”。这两个部分能有效避免范围不断膨胀。
2.6 让 AI 生成 ADR
重要架构决策建议用 ADR 记录。
示例提示词：
请为 SkillVersion 是否不可变生成一份 ADR。
包含：
- Context
- Decision
- Alternatives
- Consequences
- Risks
- When to revisitSkill 场景里常见 ADR：
ADR-001：发布后的 SkillVersion 不可变
ADR-002：Skill Runtime 不直接依赖具体模型供应商
ADR-003：工具调用权限由系统校验，不由模型判断
ADR-004：Skill 执行必须记录 trace_id 和版本快照
ADR-005：Skill 输出必须支持 schema 校验ADR 的价值是让团队知道“为什么当时这么选”，而不只是看到最后的技术方案。
3. 你和 AI 的分工
你负责：
业务目标
真实约束
团队能力
历史包袱
优先级判断
最终取舍AI 负责：
提出问题
生成候选方案
补充方法论
发现风险
整理结构
模拟评审
生成文档草案不要让 AI 替你决定业务取舍。AI 不知道公司的真实组织结构、客户压力、技术债、上线窗口和团队能力。
4. 最实用的协作循环
推荐固定使用这个循环：
背景输入
↓
AI 提问
↓
你补充约束
↓
AI 给 2-3 个方案
↓
你选择方向
↓
AI 深化设计
↓
AI 反向评审
↓
你修正
↓
AI 生成文档
↓
团队评审
↓
AI 根据评审意见更新这个流程的关键是：先发散，再收敛；先比较，再决策；先审查，再落文档。
5. Skill 场景下的检查清单
在设计 Skill 模块时，可以让 AI 重点检查这些问题：
1. Skill 是否被误设计成 Prompt 模板管理？
2. Skill、Agent、Workflow 的边界是否清楚？
3. SkillVersion 是否可追溯、可回滚？
4. 执行时是否记录模型、Prompt、工具、知识库版本？
5. 输入输出是否有 schema？
6. 工具调用权限是否由系统硬校验？
7. 多租户隔离是否贯穿设计？
8. 是否有运行日志、trace、成本和错误码？
9. 是否支持测试集、评估、灰度和回归？
10. MVP 是否过大？这些问题比“表怎么设计”更优先。
6. 可直接复用的总提示词
你可以用下面这段作为和 AI 协作架构设计的起始提示词：
我正在设计一个 SaaS AI 引擎平台中的 Skill 模块。
请你作为架构设计协作者，不要直接给最终方案。
先按以下步骤和我协作：
1. 先问我 10 个必须澄清的问题。
2. 根据我的回答，提炼业务目标、约束和非目标。
3. 给出 3 种架构方案，并比较取舍。
4. 推荐一个适合 MVP 的方案。
5. 帮我输出领域模型、执行链路、模块边界和风险清单。
6. 最后整理成架构设计文档和 ADR。
你每一步都要指出假设、风险和需要我确认的地方。7. 协作时的反模式
需要避免这些使用方式：
直接让 AI 给最终架构
只让 AI 输出一个方案
没有业务约束就讨论技术选型
只设计表结构，不设计运行时
只讨论功能，不讨论权限和治理
只保存结论，不保存决策原因
不让 AI 做反方评审
不把对话沉淀成文档这些反模式会让 AI 输出看起来完整，但实际无法落地的方案。
8. 一句话总结
不要把 AI 当“答案机器”，而要把它当成架构评审流程的加速器。
好的协作方式是让 AI 多问、多比较、多挑刺、多结构化，然后由你结合真实业务约束做最终取舍。