大家好，我是Tony Bai。

欢迎来到微专栏 《AI 智能体时代的软件工程》的第五讲。

在上一讲中，我们探讨了如何解决“沟通降本”的问题，利用 AI 将杂乱无章的需求转化为结构化的“研发契约”。现在，你的需求已经清晰，准备开始进行系统架构设计和技术选型了。

在这个阶段，如果你在一家成熟的大型互联网公司，通常会面临一个极具仪式感的环节：架构评审委员会（Architecture Review Board, ARB）。

你需要在一个会议室里，面对来自 SRE（网站可靠性工程）、安全团队、DBA（数据库管理员）以及资深架构师的灵魂拷问：“如果发生网络分区怎么办？”、“你的缓存穿透策略是什么？”、“这涉及到越权访问的风险吗？”

这个过程虽然痛苦，但它是保证复杂系统能够安全上线的核心防线。

然而，现实情况往往是：

1. 大多数中小型团队根本没有配备如此齐全的跨领域专家。

2. 即使有，专家的时间也极其稀缺，很难在项目早期（设计阶段）就深入参与，往往演变成“后期利益干系人冲突”——代码都写完了，上线前一天被安全团队一票否决。

3. “群体思维”与“社交税”：在设计评审会上，如果负责主讲的是团队的核心骨干或 Leader，其他同事往往会因为害怕引发冲突、担心显得自己不懂，而选择保持沉默。大家更倾向于顺着主讲人的思路“打补丁”，而不是指出底层假设的致命缺陷。

我们该如何打破这种局面？

今天，我们将解锁 AI 队友的另一项降维打击能力——利用它广博的跨领域知识库，扮演“虚拟架构委员会”，进行零社交成本的无情挑刺。

我们将学习两个极具价值的人机协作设计模式：“角色投影（Role Casting）” 和 “魔鬼代言人（Devil's Advocate）”。

模式一：角色投影（Role Casting）—— 召唤你的跨部门专家团

模式解析：打破知识孤岛

大语言模型（LLM）最可怕的地方不在于它能写多少代码，而在于它在预训练阶段“吞噬”了全人类几乎所有的公开技术文档、灾难复盘报告（Postmortems）、安全漏洞库（CVE）和最佳实践指南。

它不仅懂 Go 语言，它还同时“读过” Google 的 SRE 手册、OWASP 的安全编码规范以及 AWS 的分布式系统架构白皮书。

“角色投影（Role Casting）”模式的核心在于：在写代码之前，明确要求 AI 暂时放弃“全能助手”的身份，强制其进入一个极其狭窄的、特定的利益干系人角色（如安全专家、DBA、SRE），并要求该角色输出一份“验收要求包（Acceptance Pack）”。

这绝不仅是简单的“Cosplay”。在 Agentic 软件工程 中，它的工程价值在于将隐藏的跨部门约束前置。

工程落地与 Prompt 模板