本节课没有语音摘要。
屏幕1：学习目标：完成本模块后您将掌握的能力
模块导览 完成本模块后您将掌握的能力
前三个模块带您从业务问题出发，完成了Claude部署的设计、集成与治理。您已能拆解需求、选择模式、评估用例规模、建立验收评估标准、实施可观测性，并为受监管工作负载搭建可审计的控制体系。但这些都未解决架构工作中最关键的人际协作环节——需求挖掘时设定真实需求的讨论、审批会议中关键权衡的博弈、以及移交后设计方案能否持续生效的考验。
本模块将涵盖这些核心能力。完成学习后您将能够： 1 开展结构化需求挖掘对话，将非技术利益相关方的诉求转化为可落地的架构需求与书面假设，确保设计始终锚定业务价值而非个人技术偏好。 2 用商业决策语言呈现架构权衡，为每个选项明确收益、代价与回退成本，使高管与采购评审能快速达成决议而非陷入僵局。 3 构建贯穿部署生命周期的反馈机制，明确定义审查触发条件、SLA违约处理方案，以及何时迭代优化 versus 彻底重构，并将治理检查点融入同一流程。 4 合作伙伴路径[合作伙伴路径相关内容，架构师考试不涉及；为合作伙伴路径学员保留] 通过需求挖掘、场景化演示、技术异议处理以及与Anthropic应用AI团队的联合规划，主导合作伙伴市场进入策略中的架构师角色，确保企业级商机不会因专属问题搁浅。 5 为多平台生产系统选择部署入口与跨平台策略，从延迟、合规性、成本等维度比较直接API、Bedrock、Vertex与第三方路线，最终产出使非技术发起人理解价值且可作为合作伙伴IP复用的成果文档。
这些能力对应以下五大主题：
需求挖掘是将利益相关方偏好转化为可设计约束的过程。核心在于翻译——偏好信号意味着需要进一步追问，而非直接作为需求。有效的需求应具备可验证性与明确边界。典型失败模式是在完成翻译前就输出设计方案，看似合理的草图最危险——它会让利益相关方误以为关键问题已解决。
权衡呈现与市场进入需要将架构决策转化为可行动的商业语言，并针对买方真实场景（而非团队能力）设计演示。每个权衡方案都应包含三大要素：选择带来的收益、放弃的选项、以及系统建成后的回退成本。第三要素最能改变会议走向，却最常被忽略。
反馈循环是在可观测性堆栈之上构建的决策层，决定哪些信号触发行为变更及责任人。它是将每个信号映射到触发器、负责人与行动的治理表。受监管部署中，部分审查需按计划而非阈值触发。这些治理规则必须在启动前就位——若未定义触发器，合规检查点可能直到审计时才暴露问题。
移交与审计文档不仅要记录采纳的决策，还需载明被否定的替代方案及其权衡考量。完整性测试标准是：未参与设计会议的合格架构师能否仅凭文档安全地修改系统。图表展示系统形态，但若缺失决策逻辑，继任者将无法区分关键负载与普通偏好。当您离开项目时，未经记录的推理过程将永远消失。
入口选择与成果文档需为生产系统确认最佳部署路径，并将部署结果转化为可持续的交付物。成果文档需向未参与建设的读者阐明商业价值。吞吐量、延迟与错误率向发起人证明系统运行状态，而用例目标业务指标的对比数据（附可审计控制）才能向CFO展示扩展价值。
这五大主题相互关联，层层递进。需求挖掘产生的约束集是权衡方案的保护对象；反馈循环治理表确保运行中的合规控制持续有效；文档记录的决策逻辑防止继任者无意推翻关键设计；成果文档整合所有上层成果，向未参与工作的读者传递价值。模块最后的综合任务要求您将受监管的多平台部署从利益相关方的一句话需求，转化为可论证扩展价值的成果文档——这也正是本模块赋予您的能力。
贯穿这五大主题的是项目生命周期本身：需求挖掘→设计→移交→监控→迭代。需求挖掘与权衡呈现对应"需求-设计"阶段；反馈循环是"监控-迭代"阶段；文档记录是移交阶段；入口选择与成果文档形成闭环。准确识别决策所属阶段，才能判断各阶段是否具备推进条件。
免责声明/教育内容声明
我们开发本《架构师课程模块4：利益相关方协作、生命周期管理与市场进入策略》旨在帮助您实际运用Claude开展工作。请将其视为教育内容，不代表法律、财务或其他专业建议，请根据自身情况调整应用。我们的产品与服务快速迭代，部分内容可能存在误差或过时，请以Anthropic官网文档为准。课程中的案例与场景均为说明性质且多为虚构。若课程提及某公司或产品，不代表Anthropic对其认可、或对方认可Anthropic、或存在关联关系。请注意，您对Anthropic产品与服务的使用受我们的条款、政策及文档约束；如本课程内容与之冲突，以官方条款为准。
屏幕2：需求挖掘是结构化需求获取，而非普通对话
需求挖掘 需求挖掘是结构化需求获取，而非普通对话 您已掌握评估模式、部署平台与控制策略的能力。需求挖掘则揭示您是否在解决正确的问题。利益相关方通常用业务语言描述问题，您的职责是听懂业务目标，识别描述中隐藏的约束，并带着设计可遵循的记录离开会议。
需求挖掘建立设计依赖的关键产出物 有效的需求挖掘对话遵循三步过滤法：倾听→翻译→记录
1首先用自然语言倾听业务目标，关注措辞背后的含义。利益相关方通常描述期望结果，而非设计需要的约束条件。 2其次将其转化为需求、假设与未决约束。这帮助您识别设计必须支持的内容、待确认事项、以及可能阻碍解决方案的因素。 3最后在对话推进前立即记录这些要点。设计需要清晰的记录依据。若缺失此过滤环节，设计将继承您的假设，错配可能直到后期修改成本最高时才暴露。
核心在于翻译：表面偏好几乎总是隐藏着约束 需求挖掘最关键的能力是翻译。利益相关方通常表达偏好，但设计决策需基于约束。假设对方说"我们希望体验无缝"，若仅记录"无缝"作为需求，您仍未获得可设计的具体信息——这只是对方对理想体验的总结。 真正的工作始于下一个问题：什么会导致体验不无缝？此时隐藏的约束开始浮现：也许是用户等待下一步操作不得超过1-2秒；也许是不该让用户重复输入已有信息；也许是异常应静默转人工而非暴露技术错误；也许是工作流必须保持在单一应用内避免工具切换。每个回答都在锐化设计轮廓。 这类交流将"无缝"转化为架构必须支持的具体需求：延迟目标、集成要求、移交规则、安全故障路径。利益相关方用业务语言命名结果，您将其转化为系统可构建与衡量的标准。 偏好浮于表面，约束潜藏其下。当听到"无缝"、"简单"、"快速"、"直观"等体验性词汇时，应视为需要深入挖掘的信号。追问什么会破坏该体验、用户绝不能察觉什么、后台必须发生什么、以及出错时仍需保持什么。这些答案才是设计记录应有的内容。 可测试、有边界的约束才是设计的依据。利益相关方的偏好指示调查方向，后续追问才能产生约束本身。
四个问题将模糊陈述转化为可设计需求 当您强制将模糊陈述归类到以下四类时，需求挖掘最有效。类似"希望体验无缝"的陈述尚无法直接设计，它通常隐藏着一个或多个具体答案。请调查：
1系统必须做什么。即部署必须交付的能力，以业务成果（而非功能）表述。这里需区分Claude负责的工作与既有系统/人工保留的工作。 2系统绝不能做什么。即边界、禁止操作、必须转人工的场景。利益相关方很少主动提供这些，必须明确追问。 3系统必须满足的成本要求。即利益相关方可控的预算约束。延迟目标、单次交互成本上限、流量预测等都属此类，它们将成为关键设计约束。 4系统必须证明什么。即部署必须提供的价值证据。受监管工作流中，证明义务本就是需求集的一部分。在需求挖掘阶段识别它们，远比法律审查时发现更经济。
"无缝"可能实际意味着用户不应感知的延迟预算、不应中断流程的移交、或不暴露系统内部信息的故障状态。一旦发现这些答案，您就获得了团队可设计、测试与捍卫的具体需求。
需求挖掘的输出是翻译对照表 每个发现项都成为翻译表中的一行，包含：利益相关方原话、隐含约束、该约束强制的架构决策、以及待确认约束的假设记录。每项单行记录可保持从需求挖掘到设计的推理链条完整，并使假设始终保持可见。
| 利益相关方陈述 | 隐含约束 | 强制的架构决策 | 待确认假设 | |----------------|----------|----------------|------------| | "我们希望体验无缝" | 体验必须保持在约定的延迟预算内。故障不得暴露系统内部或中断流程。 | 将p95延迟目标设为设计约束，设计优雅且内部安全的故障状态。 | 假设"无缝"指感知响应性与流程连续性。需确认理解正确。 | | "只需读取表单并路由" | 路由可能是确定性业务规则。 | 将路由决策保留在规则引擎中。Claude负责提取，系统负责路由。 | 假设路由逻辑由外部拥有维护。需确认负责人。 | | "临床医生总会复核输出" | 具有资质的临床医生必须在输出产生法律/财务/临床影响前授权。 | 构建人工介入授权步骤作为强制检查点。 | 假设复核是架构关卡。需确认权限与时机。 | | "我们在医疗行业，需谨慎处理数据" | 工作流可能承担健康隐私法规下的证明义务。 | 从第一天就将审计追踪与数据处理证据作为核心需求。 | 假设工作流在正式义务范围内。需与合规部门确认范围。 |
成本·复杂度·风险
成本：充分识别真实约束的需求挖掘会议，远比在法务/合规审查时发现隐藏约束后重新设计更经济。 复杂度：按四类问题推进需要结构化思维，实时将偏好翻译为约束需要刻意练习。 风险：昂贵失败源于未声明的约束通过测试成为生产环境阻碍——此时修改设计的成本最高。
屏幕3：演变为设计会议的需求挖掘会议
警惕|需求挖掘|5分钟 演变为设计会议的需求挖掘会议
背景需求挖掘是工作的起点，设计是加速点。优秀的架构师常在会议中途就开始构思解决方案。绘制草图看似高效，利益相关方看到进展也感到满意——这恰恰是提问停止的时刻。
重构的需求挖掘会议（提问过早终止的案例） 下例中，架构师听到两个利益相关方陈述后立即提出解决方案。由于听起来专业，对方直接确认了提案。本应排除该架构的关键约束始终未被识别，直到两周后的合规审查才暴露。本节展示本应捕捉每个约束的关键提问点，帮助您识别自身会议中的类似模式。
重构对话
利益相关方："我们运营地区医院网络。护士花费大量时间撰写患者诊疗记录。希望用Claude根据口述起草临床笔记。" 架构师："明白，这是典型的增强模式。Claude接收口述、起草结构化笔记、回写。下周就能出原型。" 利益相关方："听起来正确。需要加入复核环节，但只是快速检查。" 架构师："好的，我们会添加复核环节。现在开始设计。"
后期才发现的多重约束（修复成本高昂） "快速检查"并非便利功能。护理工作流要求持照临床医生在模型输出进入患者病历前授权，这使得人工授权成为必需的架构关卡（而非可选附加）。口述内容包含受保护健康信息(PHI)，这些信息流经context window时未满足工作流要求的处理方式。网络横跨两个有不同记录保留规定的州，而单区域设计从未考虑任何一州要求。这些需求既不罕见也不难发现——若会议没有在提问完成前转向设计，任何"必须证明"或"绝不能做"类问题都能揭示它们。
失败原因：看似专业的设计提案终止了需求挖掘会议存在的意义 草图看似合理正是其危险所在。听到自信的架构描述，利益相关方会假设架构师已掌握充分信息。保护性策略很朴素：在提案前完成四类问题集，将每个"只是复核"视为待深挖的约束。
屏幕4：检查点：找出未记录的假设
需求挖掘·检查点 检查点：找出未记录的假设
立即尝试。以下是需求挖掘会议摘要及架构师据此编写的需求文档。其中三项可追溯至利益相关方陈述，一项是架构师未揭示底层约束所做的假设。请选择未记录假设的条目，并确认无利益相关方陈述支持它。
需求文档
- Claude起草客户邮件，但由人工实际发送。
- 响应必须在两秒感知预算内返回。
- 超过阈值的退款转人工审批。
- 对话记录保留60天用于分析。
利益相关方原话
"大额操作需人工签字" "起草回复，但我们自己发送" "对用户必须感觉是即时的"
第一部分：哪项是未记录的假设？
A项1，人工发送的邮件起草 B项2，两秒延迟预算 C项3，退款转人工审批 D项4，60天记录保留
第二部分：项4应追溯至哪条利益相关方陈述？
A"起草回复，但我们自己发送" B"对用户必须感觉是即时的" C"大额操作需人工签字" D无利益相关方陈述支持此项
检查答案 跳过
屏幕5：用可行动语言呈现权衡方案，并设计推动交易的演示
权衡与市场进入 用可行动语言呈现权衡方案，并设计推动交易的演示 需求挖掘揭示了买方需求，而将这些需求转化为利益相关方可执行的决策是下一步工作。此时架构师需帮助对方理解权衡、看清商业影响，并 confidently 批准前进路径。
您的职责不是在会前解决权衡，而是让决策成为可能 每个重要设计决策都涉及权衡。某个选项可能降低成本或复杂度，但会增加延迟、风险或合规负担；另一个可能提升用户体验或扩展性，但需要更多前期投入。若仅呈现结论，决策看似清晰实则脆弱——当弊端后期显现时，利益相关方可能感到自己被蒙蔽。因此请使用简单决策框架：
1我们获得什么？ 2我们放弃什么？ 3若日后需要回退，代价是什么？ 4在受监管环境中，这对合规态势有何影响？
第三个问题最常被忽略，却往往最能改变会议走向——它将讨论从"哪个技术方案更好"转变为"哪个商业选择更优"。技术精确性必要但不充分。架构评审中，建议可能技术正确却仍未被决策者理解。当高管询问"错误选择对业务的影响"时，会议室需要的不是更多技术细节，而是转化为可理解语言的翻译。
将决策作为可行动的方案包呈现 将决策呈现为包含考虑选项、权衡标准、推荐方案及剩余风险的方案包。利益相关方不是在采纳您的架构，而是在接受一个需要向上级辩护的决策。
描述能力是方案落地的关键竞争力 描述是AI流畅性四大核心能力之一（有效与AI沟通）。延伸到利益相关方工作时，同样的原则意味着用对方能理解的语言精确传达所需信息。应用于利益相关方沟通时，描述意味着用其目标术语框定系统行为、限制与监督机制。实践中遵循三原则：以业务成果（而非架构）为主导；诚实说明限制（安全利益相关方更信任明确声明限制的系统）；预判同级验证需求（利益相关方需向他人证明选择合理性，应带着论据离开会议）。
使用权衡翻译对照表实现从架构语言到商业决策语言的转换
| 架构决策 | 获得收益 | 付出代价 | 错误选择后的回退成本 | |----------|----------|----------|----------------------| | 每次调用使用更大context window vs 分块检索 | 初期设计更简单，完整文档可见，需管理的移动部件更少。 | 生产流量增长后单次调用成本更高、响应更慢。对政策文档等静态内容，提示词缓存可显著回收输入成本，故在将单次调用成本视为固定前需评估缓存效果。 | 生产环境成本激增后重构架构的代价，加上解释本可避免的意外支出的信誉损失。 | | 为低延迟牺牲日志细节 | 更快的感知响应与更流畅的终端用户体验。 | 每次交互的可观测性降低。 | 在受监管工作流中，可能导致需要补救的合规缺口。 | | 单一交付路线 vs 多平台 | 构建复杂度更低，具有一致的认证与日志配置。 | 满足不同地区、合规或采购需求的灵活性更低。 | 若选定路线无法满足后期出现的数据驻留或部署要求，可能导致生产切换延迟或受阻。 |
该对照表旨在帮助利益相关方看清选择后果以做出决策。
演示设计是独立技能，糟糕演示可能抵消需求挖掘的成果 想象买方会议中需求挖掘很成功——团队就问题、用例与价值达成一致。接着演示开始：展示的是一套精美但通用的功能集，而非买方实际场景。反应通常是礼貌的"演示有趣，但不太符合预期"。糟糕演示会让买方质疑团队是否理解核心问题。这源于混淆两种演示：能力演示回答"系统能做什么"；场景演示回答"系统如何解决我的具体问题、工作流与约束"。前者创造兴趣，只有后者建立信心。
合作伙伴路径|架构师考试不测试 在构建任何界面前，先做四项设计决策。这些决策决定演示效果是量身定制还是流于泛泛。
| 设计决策 | 架构师决定内容 | 为何决定结果 | |----------|----------------|--------------| | 场景选择 | 选择买方能立即识别的自身业务流程，包括熟悉的数据结构、审批步骤与边缘案例。避免通用文档任务或抽象查询流。 | 买方信任熟悉事物。当屏幕上出现自己的术语与故障点时，演示会显得相关且可信。识别度常比精美但通用的功能展示更有说服力。 | | 限制声明 | 预先确定演示将明确的1-2项限制，并将其框定为故意的范围边界。说明系统不做什么及原因。 | 若买方在演示中途发现限制，信心会下降；若您提前声明限制，则体现专业与诚实。在受监管场景中，预先披露边界常是积极信号。 | | 销售团队协作 | 在构建前与销售团队共同塑造演示叙事。他们了解买方前期提出的问题，您了解系统在生产条件下的真实能力。 | 无销售参与的演示可能回答买方从未提出的问题；无架构师参与的演示可能过度承诺。无论哪种都会损害可信度并拖慢商机。 | | 数据准备 | 使用在结构与体量上类似买方数据的素材。对受监管买方，使用反映真实环境结构约束的匿名数据。 | 买方通过演示中的数据做出判断。真实的字段名与数据模式让场景显得真实。当数据看起来像他们的，演示就不证自明。 |
限制声明需要刻意关注 四项设计中，限制声明最违背本能。实践中，暴露弱点看似冒险，人们倾向于隐藏或弱化它——这通常会适得其反。设想买方询问"哪些情况处理不好？"若回答含糊，信心下降；若回答清晰且有范围，买方看到的是专业而非防御。因此应预先决定声明哪些限制及如何表述，证明边界是深思熟虑的结果。
成功的联合规划始于会前准备 合作伙伴路径|架构师考试不测试 同样的原则直接适用于与应用AI团队的联合规划。优秀的规划会议不是首次讨论基础问题的场所，而是精炼选择、验证假设、解决需要专家输入的问题的场合。若演示证明您理解买方问题，规划会议则证明您已准备好构建可信解决方案。这需要您带着三项准备入场：
1客户需求与约束的书面记录。包含需求挖掘产出：用例、工作流、利益相关方、数据条件、技术环境、合规关切与成功标准。为会议提供共同起点。 2建议模式或少量候选模式集，附已明确的权衡。带着观点入场，展示可能选项、各自得失及风险点。 3应用AI团队最适合回答的开放问题短清单。这些才值得在会上讨论：模型行为、架构影响、扩展约束、评估方法、安全考量或模式适配性。
异议分属不同类别，需区别应对 销售周期中的技术异议通常分三类。能力异议质疑系统能否实现功能；治理与合规异议质疑部署是否可信、可控、可证明；设计选择异议询问为何选此而非彼。后者不仅需要辩护，还需用与呈现权衡时相同的结构，解释选择解决的权衡及替代方案的代价。
合作伙伴路径|架构师考试不测试 市场进入参与图应将演示设计作为跟踪工作流。因此它包含演示设计列，明确标注场景、已识别限制、确认数据源及销售团队签收作为交付物。这在合作伙伴并行推进多个商机或架构师中途交接时尤为关键——连续性极度依赖文档记录。
成本·复杂度·风险
成本：准备权衡呈现与场景化演示消耗实际架构师时间，但远比商机停滞或利益相关方后期撤回批准更经济。 复杂度：此项工作依赖三项技能，其中两项常违背本能——明确回退成本与清晰声明限制。二者都需要刻意练习。 风险：昂贵失败是虚假共识。当决策在会议室看似通过，但回退成本从未明确，后果后期显现时。
屏幕6：非知情选择的批准
警惕|权衡与市场进入|5分钟 非知情选择的批准
背景在权衡呈现结束时点头同意的利益相关方，看似已理解权衡。演示完整且技术准确，会议室充满共识感——这种感觉正是陷阱。
重构的生产前评审（CTO视角） 架构师用技术术语呈现context策略权衡。CTO询问了成本问题并得到准确答复后批准。六周后更高的单次调用成本出现在生产环境账单中。以下是对话重现及CTO收到账单后的备注，展示演示回答了错误版本的问题。
重构对话+后续
架构师："建议采用更大context window，使完整政策文档在每次调用中保持可见。这简化设计，避免检索层。" CTO："单次调用成本多少？" 架构师："使用当前模型层级约4美分/次。若政策文档跨调用静态不变，提示词缓存可显著降低输入部分成本。" CTO："好的，批准。保持简单。" [六周后生产账单]CTO给客户团队的备注："我批准的是方向，不是数字。没人告诉我4美分乘以调用量是五位数的月支出。若文档是静态的，为何不缓存？既然决定围绕full-context构建，我需要知道系统依赖它后撤销的代价。"
问题：回退成本从未进入讨论 演示说明了设计收益（简单性），也回答了单次调用成本。但从未指出第三要素：当选择遇上生产流量且需在系统建成后回退时，对业务的影响。CTO批准的是单次数字，而非月账单或后期撤销成本。权衡的两要素被清晰传达，第三要素没有——而它恰恰是关键支撑点。
失败原因：准确的演示仍可能回答错误问题 未理解回退成本就批准建议的利益相关方，并未做出知情选择。CTO听到单次成本与简单性论证后合理同意。回退成本本是会改变决策的因素。每次都应明确三要素，当设计看似明显更简单时更需强调回退成本。
屏幕7：检查点：推荐选项并指出缺失要素
权衡与市场进入·检查点 检查点：推荐选项并指出缺失要素
立即尝试。阅读利益相关方简报及用平实语言编写的三个选项呈现。一个选项技术准确且呈现完整；一个技术准确但缺失要素；一个不符合既定约束。请推荐应提出的选项，然后指出第二选项缺失的单一要素。
简报 中型保险公司希望用Claude起草理赔员对保单持有人的回复。工作流受州保险法规约束，需审计追踪。流量大且稳定。发起人关注响应质量与每次自动化交互的可辩护记录。
| 选项 | 呈现内容 | |------|----------| | A | 内置每次交互日志的工作流模式。收益：完整审计追踪，发送前质量关卡。代价：日志步骤带来的轻微延迟。回退：微小，日志可调优无需重构。 | | B | 为低延迟牺牲日志步骤的工作流模式。收益：更快响应。代价：丢失每次交互审计细节。 | | C | 无日志无人工关卡的单一增强调用，选择依据是最低构建成本。 |
第一部分：应推荐哪个选项？
A选项A，内置日志，完整审计追踪 B选项B，为低延迟牺牲日志 C选项C，无日志无人工关卡
第二部分：选项B缺失哪个单一要素？
A选项B的收益（更快响应表述不够清晰） B选项B的代价（审计细节丢失未解释） C回退成本，设计依赖延迟增益后恢复日志的代价 D该选项创造的合规态势
检查答案 跳过
屏幕8：反馈循环决定哪些信号触达利益相关方，SLA定义违约处理
反馈循环 反馈循环决定哪些信号触达利益相关方，SLA定义违约处理 生产环境可观测性与审计追踪记录实时部署行为。本主题涵盖信号过滤、判断何时升级、以及定义性能不达标时SLA的要求。系统上线后，保持其可信度需要持续努力。在生命周期中，反馈循环对应部署生命周期的"监控-迭代"阶段。
缺乏主动监控的部署必然偏离正轨 设想一个启动状态良好的客服助手：响应迅速、语气稳定、能妥善处理常见问题。初期一切稳定。但随着时间推移，使用模式变化、新提示风格出现、客户问题更复杂。部分响应只是变慢，有些回答则开始偏离目标。 没有剧烈故障正是漂移难察觉的原因。质量是逐渐而非突然下降的。缺乏反馈循环的团队可能直到用户感知到退化才发现问题。
反馈循环是可观测性堆栈之上的决策层 可观测性提供原始材料：延迟、错误率、评估分数、使用模式等系统信号。但信号本身不是决策。某个峰值可能是噪音，另一个可能指向真实问题，第三个可能仅在持续出现时重要。 反馈循环位于可观测性之上，回答五个问题： 信号→分类→决策→行动→复查
1信号：系统显示什么？ 2分类：哪些需立即关注，哪些可暂缓？ 3决策：问题需要团队修复、利益相关方审查还是无需行动？ 4行动：需要何种纠正、护栏更新或升级？ 5复查：应对措施是否有效？规则是否需要调整？
想象火车站控制室。传感器能显示晚点列车，但仍需人工判断延误是否轻微、乘客是否需要通知、时刻表是否需要调整。这个判断层使系统可管理而不仅可测量。
SLA明确三要素，阈值需有据可依 当反馈循环判定某事项重要后，SLA定义其越界时的处理。SLA是明确三项内容的承诺：
1测量什么？ 2何为违约？ 3违约时如何处理？
阈值绝不能随意设定，应追溯至具体依据：
1延迟应反映先前确定的用户体验期望 2可用性应反映部署对业务的关键程度 3质量应反映既定的评估结果与验收标准
这种可追溯性使SLA可辩护。若数字无法关联到上述来源，很可能只是听起来合理的随意目标。 成本是最常在启动后打破预期的因素。生产环境流量通常是概念验证的10-100倍，因此POC中微不足道的成本在规模下会成为五位数月支出。预防措施：向利益相关方提供预期生产流量下的消耗预测，明确消费控制策略（缓存、模型分层、预算警报），并在首张发票前（而非后）建立模型分层叙事。
受监管部署需添加按计划运行的审查点 可观测性记录已发生事件，反馈循环决定如何处理。受监管部署中，部分审查必须在无事发生时仍按计划执行。具有文档义务的医疗工作流可能要求定期按既定计划审计输出；数据驻留部署可能需要定期确认环境仍符合驻留规则。这些是设计时义务而非后期添加项。若早期未构建，当有人要求证明时将更昂贵。 构建将每个信号映射到触发器、架构师行动与监管检查点的治理表。该表应在启动前存在，是将政策转化为操作流程的机制。
生产信号治理表示例
| 信号类型 | 审查触发器 | 架构师行动 | 受监管行业检查点 | |----------|------------|------------|------------------| | 输出质量（评估分数） | 分数跨越评估套件设定的阈值。 | 诊断原因是提示词、数据还是模型漂移，决定迭代或重构。 | 按既定计划定期对照文档标准审计输出，无论分数如何。 | | 延迟p95 | 跨越用户体验需求设定的预算。 | 调查瓶颈，若预算本身错误则调整或升级至利益相关方审查。 | 通常无，除非延迟掩盖了日志或可追踪性缺口。 | | 单次交互成本 | 跨越需求挖掘约定的预算范围。 | 识别驱动因素，若预算需调整则向利益相关方提出权衡方案。 | 通常无，除非成本控制是受监管运营约束的一部分。 | | 数据驻留配置 | 计划性确认。 | 立即确认并记录驻留状态，标记任何偏离。 | 按既定计划执行驻留确认。 |
成本·复杂度·风险
成本：循环创造持续的架构师投入。但这比每季度审查时发现所有仪表板正常却已全面退化更经济。 复杂度：最难的是区分值得关注的信号与噪音，因为可观测性工具无法代劳。 风险：最大失败模式是合规检查点从未连接触发器，使得违反文档标准的情况持续数周才被例行审查发现。
屏幕9：替代反馈循环的可观测性堆栈
警惕|反馈循环|5分钟 替代反馈循环的可观测性堆栈
背景构建严谨可观测性堆栈的架构师已完成更艰难的技术工作。仪表板在线、警报配置完毕、数据持续流动。得出"利益相关方反馈已覆盖"的结论既容易又合理。
重构轨迹：九十天警报日志与利益相关方审查日历对比 下例将部署警报日志与九十天窗口期的利益相关方审查日历并列展示。警报日志显示第4-7周输出质量持续漂移，审查日历显示该窗口期无审查发生。反馈循环治理表的一行本可连接二者。此处展示记录中的缺口形态。
| 时间段 | 可观测性堆栈记录 | 利益相关方审查日历 | 循环本应执行的操作 | |--------|--------------------|---------------------|----------------------| | 1-3周 | 评估分数稳定在基线，延迟与成本正常。 | 第1周举行启动审查。 | 正常。无需升级。 | | 4-7周 | 评估分数周环比持续下降，错误率平稳，故未触发硬警报。 | 无计划或举行的审查。 | 质量漂移触发器应在第5周升级至架构师审查，诊断确认后继续升级至利益相关方审查。 | | 8-12周 | 分数继续下降，利益相关方报告输出"最近不太有用"。 | 季度审查最终在第12周发现。 | 按设计，循环本应提前七周捕捉此问题。 |
问题：信号存在，但无机制判定其重要性 部署需要的每个指标都已收集。自第四周起评估分数明显下降。缺失的是决策层：无治理规则将缓慢质量漂移映射到审查触发器。漂移未跨越错误率阈值，故未触发警报。无触发器的漂移在人工发现前始终隐形。堆栈测量正确内容却未告知其重要性。
失败原因：监控不等于反馈循环 仪表板收集展示信号，反馈循环将每个信号映射到触发器、负责人与必要行动。可观测性堆栈收集信号但无治理规则进行映射。应构建将每个信号映射到触发器、行动与负责人的治理表，包含缓慢漂移与硬故障。
屏幕10：检查点：对生产信号进行分类
反馈循环·检查点 检查点：对生产信号进行分类
立即尝试。以下是生产部署的九个信号。请将每个拖放至所属分类：内部监控、架构师审查、利益相关方审查或噪音。
1 · 延迟p99上升40ms，仍在预算内。 2 · 评估分数连续三周下降，趋势明显。 3 · 计划性数据驻留确认到期。 4 · 来自已知问题客户的一个畸形请求。 5 · 单次交互成本跨越约定预算阈值。 6 · 凌晨2点批处理作业记录重试后成功。 7 · 对照文档标准的季度输出审计到期。 8 · token使用量随已知季节性流量增长。 9 · 新提示模板上线后错误率平稳。
内部监控 架构师审查 利益相关方审查 噪音
检查放置 跳过
屏幕11：移交后仍生效的文档服务于继任者、审计员与返场架构师
文档 移交后仍生效的文档服务于继任者、审计员与返场架构师 反馈循环在您运行时保持系统健康，文档则在您离开后维持其功能。本主题将完整设计转化为能经受移交并满足合规审查员的文档。要么设计携带自身逻辑完成移交，要么这些逻辑随您离开而消失。在生命周期中，文档对应部署生命周期的移交阶段。
单一文档服务三类读者，仅服务其一会导致不完整 架构文档服务三类读者：接手未参与建设的部署的继承工程师；后期抵达，寻找特定控制措施实施证据的审计员；数月后返回，对设计会议毫无记忆的返场架构师（常是您自己）。为其中一类读者而非其他两类构建的文档，即使详细也不完整。
对继任者：被否定的替代方案与采纳的决策同等重要 对系统继承者，文档必须包含做出的决策、考虑的替代方案及每个否决的原因。未携带被否选择的交付设计无法被未参会者理解。他们将因错误原因推翻正确决策，或因无法辨别解决的权衡而捍卫错误决策。被否选项解释设计形态的成因。
对合规审查员：证据比断言更重要 对合规审查员，文档必须包含每项法规义务、满足它的技术控制、控制负责人及证明控制运行的证据工件。这是受监管部署控制登记册的延续，成为管理部署生产寿命的活文档。审查员不接受单纯断言，他们需要证据——仅声明控制存在是不够的。
对返场架构师：无需简报即可导航 对数月后返回的架构师，文档必须自成一体。决策标注日期；假设明确标记为假设而非作为事实嵌入；待办事项有负责人与解决标准。实用测试是：阅读文档后，未参与设计会议的合格架构师能否安全修改系统？若答案是否定的，文档就不完整。
文档完整性检查表
| 字段 | 捕获内容 | 主要服务读者 | |------|----------|--------------| | 决策 | 做出的架构选择（含日期）。 | 三类读者。 | | 被否替代方案 | 考虑但未采纳的选项。 | 继任者。 | | 已明确的权衡 | 决策解决的权衡，以得失与回退影响表述。 | 继任者与返场架构师。 | | 负责人 | 决策或控制的持续责任人。 | 合规审查员与继任者。 | | 证据工件 | 证明控制实际运行的工件。 | 合规审查员。 | | 审计就绪状态 | 可用证据是否最新且满足审查。 | 合规审查员。 |
成本·复杂度·风险
成本：设计时记录逻辑与证据耗时，后期从邮件线程重建（或失败）将导致生产环境错误回退。 复杂度：纪律在于记录原因而不仅是事实，并将假设标记为假设——当推理对亲历者显而易见时易被跳过。 风险：昂贵失败是继任者因逻辑未记录而推翻关键决策，重新引入原设计已解决的约束违规。
屏幕12：仅存于架构师脑中的设计逻辑
警惕|文档|5分钟 仅存于架构师脑中的设计逻辑
背景参与所有设计决策的架构师掌握其全部逻辑。当您已知晓时，记录它显得冗余，而总有比文档更紧急的事。这正是逻辑随人离去的方式。
事后分析：金融服务业移交中逻辑未落地的案例 本例中，原架构师在启动十二周后离开中型金融服务项目。继任者继承了一份详尽架构图但无逻辑说明。性能问题引发切换context策略的提议，继任者执行切换后，重新引入了违反部署数据驻留约束的处理模式。事后分析将失败追溯至缺失的一行记录。以下是记录中的呈现。
| 阶段 | 发生事件 | 文档携带内容 | |------|----------|--------------| | 启动 | 原架构师专门设计context策略以满足受监管数据驻留要求。 | 展示最终设计的架构图。 | | 移交 | 原架构师第12周离开。无设计会议记录。 | 仅有图表，无被否替代方案与逻辑。 | | 变更 | 继任者遇到性能问题，切换context策略解决。 | 无内容解释原策略选择原因。 | | 失败 | 切换重新引入破坏数据驻留规则的处理模式。 | 原设计避免该模式的原因仅存在于离职架构师脑中。 |
故障点：图表展示"是什么"但丢失"为什么" 继任者称职且基于已有信息合理行动。图表展示系统形态而非设计原因。原context策略是为满足驻留约束的深思熟虑的选择，但该逻辑从未作为带有明确权衡与被否选项的决策记录。由于无逻辑文档，继任者无法知晓所更改策略对合规的关键性，从而出于可理解的错误原因推翻了正确决策。
失败原因：无逻辑支撑的设计是无法安全修改的设计 完整性测试是未参会合格架构师能否凭文档安全修改系统。本例答案为否，且无人知晓直至生产环境故障。请记录决策、被否替代方案及每个解决的权衡。记住：若永不书写，它便随您离去。
屏幕13：检查点：放置文档工件
文档·检查点 检查点：放置文档工件
立即尝试。平面有两个轴：一个从"服务继任者"到"服务合规审查员"，另一个从"记录意图"到"记录证据"。请将六个工件卡片拖放至最能描述其主要功能的区域。
架构图 带逻辑的决策日志 含证据链接的控制登记册 部署运行手册 测试结果摘要 假设登记册
← 继任者 合规审查员 →
移交·意图 合规·意图 移交·证据 合规·证据 ↑ 记录意图 / 记录证据 ↓
检查放置 跳过
屏幕14：入口选择需考虑完整生产环境，成果文档将工作转化为可复用IP
入口与成果 入口选择需考虑完整生产环境，成果文档将工作转化为可复用IP 本主题涵盖部署路径选择及产出，将工作转化为可持续的合作伙伴IP。入口选择在此需结合完整生产环境重新审视。
部署上线后，入口问题发生变化 早期模块将路径选择作为入口与合规预过滤器介绍：直接Anthropic API、AWS Bedrock、GCP Vertex AI与Microsoft Foundry各自服务不同合作伙伴采购姿态与区域合规要求。本主题结合完整生产环境重返该决策。问题不再是谁能通过合规预过滤，而是在延迟、成本与合规维度上，多平台生产部署中哪条路径表现最优。由于入口能力会变化，本节所有具体声明在构建时需重新对照platform. claude. com/docs与anthropic. com验证。
跨平台部署暴露单入口系统永不显现的问题 跨越多入口的部署会暴露一类单入口系统不会出现的问题。模型标识字符串因入口而异；经由云服务提供商中介的入口功能可能滞后于直接API；Bedrock与Vertex的区域可用性需显式配置，默认全局端点常会破坏数据驻留要求。设计多入口的架构师在编写首行集成代码前，就需要文档化的入口责任映射表。
多入口应用必须明确各入口的责任及原因 在单一工作流中集成多个Claude入口的应用，需指定哪个入口处理哪个任务及原因。使用API进行后端推理、Claude Code处理工程子任务、Bedrock端点服务受监管数据路径的工作流，在企业级规模中并不罕见。每个入口边界都是具有独立认证、日志与故障模式的集成点。入口责任映射表使这些边界显式化，防止最常见多入口故障——因路由逻辑未文档化，某个入口逐渐承担非设计任务。
成果文档向建设团队外的成员传递价值 客户成果文档是向未参与建设的成员阐明部署价值的交付物。结构良好的成果文档涵盖六个字段：用例及其范围边界、部署前指标、部署后指标、使结果可审计的控制措施、负责持续测量的责任人、以及模式对其他客户或项目的复用潜力。仅技术指标无法构成此文档，业务指标的对比与复用说明才是其成为可复用资产的关键。
部署入口决策矩阵：
| 平台 | 延迟特征 | 合规姿态 | 选用时机 | |------|----------|----------|----------| | 直接Anthropic API | 最先获得新功能，跳转最少。 | 默认强大但需确认配置覆盖范围。 | 默认选用，除非采购或驻留规则指向其他选项。 | | AWS Bedrock | 可配置区域，功能可能滞后于直接API。 | 适合以AWS为中心的采购与显式配置的区域规则。 | 合作伙伴标准化使用AWS且需要区域内执行时。 | | GCP Vertex AI | 可配置区域，功能可能滞后于直接API。 | 适合以GCP为中心的采购与显式配置的区域规则。 | 合作伙伴标准化使用GCP且有Vertex采购路径时。 | | Microsoft Foundry(Azure)路径 | 因托管形式而异：托管在Azure的模型在合作伙伴Azure环境中运行推理(GA)；托管在Anthropic的模型路由至Anthropic基础设施。 | 按路径验证驻留与覆盖范围，勿从平台名称推断。 | 合作伙伴采购或驻留姿态要求特定路径时。 |
合作伙伴路径下方模板中的"模式对其他客户或项目的复用潜力"及复用潜力字段是合作伙伴路径相关内容；其余成果文档内容属于蓝图范围(6. 4)。
客户成果文档模板：
| 字段 | 记录内容 | |------|----------| | 含范围边界的用例 | 部署做什么及不做什么。 | | 部署前指标 | 部署前的业务指标状态。 | | 部署后指标 | 采用相同定义测量的部署后同一指标。 | | 实施的控制 | 使前后对比可审计（而非仅断言）的依据。 | | 测量负责人 | 项目结束后负责持续测量的责任人。 | | 复用潜力 | 该模式作为IP转移至其他客户或项目的可能性。 |
成本·复杂度·风险
成本：选择错误部署平台或产出单薄成果文档看似成本低廉，但修正代价高昂——驻留不匹配可能阻碍切换，仅含指标的文档无法论证扩展合理性。 复杂度：多平台路由成倍增加集成点，每个都有独立认证、日志与故障模式。唯有入口责任映射表能长期保持其可理解性。 风险：昂贵失败是默认配置悄然破坏数据驻留，或发起人因未捕获业务价值而无法向CFO展示的成果文档。
屏幕15：测量了错误指标的成果文档
警惕|入口与成果|5分钟 测量了错误指标的成果文档
背景在受控推广中表现良好的部署已有数据支撑。准备结束项目的架构师拥有编写成果文档所需的一切素材。基于现成指标快速编写似乎正确，而在任何人注意到文档缺陷前项目已结束。
案例：无法回答CFO首个问题的成果文档 架构师使用可观测性堆栈最易导出的指标（请求量、平均延迟、错误率）编写客户成果文档。客户发起人将其提交给CFO论证扩展部署时，CFO首个问题是部署在业务层面节省或创造了什么，文档无法回答。本应使其可用的两个字段始终空缺。过程重现如下：
发起人展示文档原文："这是部署情况。月均4万次请求，平均延迟低于2秒，错误率0. 5%以下。" CFO回应："这告诉我它能运行。它为我们做了什么？采用前的理赔处理时间是多少？现在是多少？这才是证明追加支出的数字。" 发起人无证据可提供。文档测量了系统运行状态，但未测量它带来的改变。
故障点：文档捕获技术指标却遗漏业务成果 请求量、延迟与错误率真实且值得追踪，但无一属于业务成果。本应使文档对CFO对话有用的字段——用例目标的业务指标前后对比及使对比可审计的控制措施——始终空缺。无前期数字则无故事，无控制则后期数字仅是断言。文档作为技术记录完整，作为扩展论据却毫无价值。
失败原因：易导出指标很少是证明成本合理性的依据 可观测性堆栈免费收集技术指标，但若未将其锚定在业务数据中，您将得到看似丰富实则空洞的仪表板。而成果文档服务于不同读者——必须向上级论证部署合理性的发起人。在开始时捕获前期指标，明确使对比可审计的控制措施，添加复用说明——让文档完成技术仪表板无法胜任的工作。
屏幕16：检查点：选择平台与必备成果字段
入口与成果·检查点 检查点：选择平台与必备成果字段
立即尝试。给定包含三个变量的部署场景：合作伙伴主要云平台、部署监管义务级别、主要性能约束。设定这三个变量后，决策模型将映射组合至推荐主平台、辅助平台（如适用）及使文档可复用所需的两个成果文档字段。
主要云平台
选择... AWS GCP Microsoft Foundry 直接(无云)
监管义务级别
选择... 无 中等 严格
主要性能约束
选择... 延迟敏感 成本敏感 合规敏感
您的答案：主平台
选择... AWS Bedrock GCP Vertex AI Microsoft Foundry 直接Anthropic API
您的答案：辅助平台
选择... 直接Anthropic API 无需
您的答案：必备成果字段
选择... 实施的控制（可审计）+测量负责人 部署前指标+部署后指标 部署前指标+部署后指标+复用潜力
推荐主平台： 辅助平台： 复用必备成果字段：
检查答案 跳过
屏幕17：综合任务：端到端设计受监管多平台部署
模块·综合 综合任务：端到端设计受监管多平台部署
以下是自包含的简报。某承担健康隐私义务的地区医疗网络正在两个云平台部署临床文档助手。原架构师即将轮换，客户CFO要求提供业务价值证据。请按顺序完成七项决策，每项都建立在前项基础上。
简报 该网络覆盖两州。护士口述患者诊疗记录，助手起草结构化临床笔记。持照临床医生必须在笔记进入患者病历前授权每份输出。部署承担健康隐私义务，需审计追踪与数据驻留规则。合作伙伴标准化使用AWS，但部分非监管后端工作使用直接API。部署已进行四周，CFO希望了解部署价值。
决策1·需求挖掘：根据简报，命名最能塑造架构的"必须证明"约束，并编写其强制的需求行。（应用需求挖掘翻译框架。）
显示参考答案 必须证明约束：承担审计追踪要求的健康隐私义务。需求行：部署必须生成每份经持照临床医生复核的模型生成笔记的可审计记录，可追溯至具体交互，因为工作流在健康隐私制度下承担正式证明义务。待记录假设：设计前与合规部门确认范围。
决策2·权衡呈现：网络要求最低延迟设计。用三要素（含回退成本）呈现精简日志与保留审计追踪间的权衡。（应用权衡翻译对照表。）
显示参考答案 收益（精简日志）：更快感知响应；更流畅的临床医生工作流。代价：丢失满足健康隐私义务所需的每次交互审计细节。回退成本：系统依赖延迟增益后，恢复日志需重构交互层，且任何空白期都会产生必须披露与补救的合规风险。
决策3·反馈循环：定义一行治理表，将要求的输出审计映射到按计划触发的利益相关方审查（独立于任何指标）。（应用反馈循环治理表。）
显示参考答案 信号：对照健康隐私文档标准的定期输出审计。触发器：基于日历（按监管义务季度触发），无视评估分数或错误率。负责人：合规主管。行动：向合规官提交审计记录的利益相关方审查。
决策4·文档：命名决策日志中若缺失将导致继任者推翻合规关键选择的一行，并说明必须携带的被否替代方案。（应用文档完整性检查表。）
显示参考答案 决策行：通过Bedrock显式区域内执行的context策略，非全局端点。被否替代方案：为简化配置使用全局Bedrock端点。已明确权衡：简单配置 vs 数据驻留合规。关键性说明：未见此逻辑的继任者为解决性能问题将恢复全局配置破坏驻留，完全复现金融服务业事后分析中的故障。
决策5·入口选择：根据AWS标准化、严格义务与驻留规则选择主次入口，并命名防止常见驻留故障的配置步骤。（应用入口决策矩阵。）
显示参考答案 主平台：AWS Bedrock，配置为显式区域内执行（非全局端点），因合作伙伴标准化使用AWS且驻留规则适用。需验证所用Bedrock配置满足具体合规要求（HIPAA BAA或数据主权）。次平台：直接API用于无驻留规则且新功能关键的非监管后端任务。配置步骤：在Bedrock客户端显式设置区域参数，勿依赖默认端点解析。
决策6·成果文档：命名使文档可用于CFO扩展论证的业务指标前后对比及可审计控制。（应用客户成果文档模板。）
显示参考答案 前期指标：从护士口述到完成并经临床医生授权的临床笔记的平均时间（部署前测量的基线）。后期指标：采用相同测量定义的部署后同一指标。可审计控制：临床医生授权日志——每份笔记都有时间戳授权记录，关联临床医生、笔记与交互，使前后对比可审计而不仅断言。
决策7·阶段过渡：命名本简报中控制下一阶段过渡的工件，并判断该关卡是否满足。（应用生命周期阶段关卡。）
显示参考答案 关卡工件：包含前后指标、可审计控制及测量负责人的成果文档，控制从当前部署阶段向CFO被要求的扩展决策过渡。判断：第四周尚未满足关卡，前期指标存在基线数据，但后期指标需要足够运行时测量。成果文档需积累足够数据才能完成。正确操作：指定测量负责人，确认控制正在记录，并在定义的启动后里程碑安排文档完成时间。
标记所有决策完成
屏幕18：术语表
总结·参考 术语表 本模块使用的关键术语按字母顺序排列。点击术语展开定义。
控制登记册 从受监管部署工作中延续的表格，将每项法规义务映射到技术控制、责任负责人及审查员可检查的证据工件。在文档中成为管理部署生产寿命的活记录。
决策日志（含逻辑） 记录每个架构选择的文档，不仅包含决策还有被否替代方案及每个解决的权衡，防止继任者因可理解的错误原因推翻关键决策。
部署生命周期 部署经历的阶段：需求挖掘→设计→移交→监控→迭代。需求挖掘与权衡呈现对应"需求-设计"工作；反馈循环是"监控-迭代"阶段；文档是移交阶段；入口选择与成果文档形成闭环。准确识别决策所属阶段才能判断何时推进下一阶段。
需求挖掘 结构化需求获取而非普通对话：通过倾听→翻译→记录三步过滤法，将利益相关方业务目标转化为设计可构建与测量的需求、假设与约束。
文档完整性 测试标准是未参会合格架构师能否凭文档安全修改系统。要求包含决策、被否替代方案、每个解决的权衡、负责人、证据工件，并将假设明确标记为假设。
入口责任映射表 记录各Claude入口（直接API、Claude Code、Bedrock、Vertex、Microsoft Foundry）负责哪些任务及原因的文档，在集成开始前编写。防止常见多入口故障——因路由未文档化，某入口逐渐承担非设计任务。
证据工件 控制措施运行的具体证明：签署协议、配置界面、授权记录或返回的日志查询。设计文档中无工件的控制仅是主张而非证明。
反馈循环 位于可观测性堆栈之上的决策层，回答信号→分类→决策→行动→复查，将每个信号映射到触发器、负责人与行动。监控收集信号，反馈循环决定哪些信号改变行为及责任人。
治理表 启动前构建的表格，将每个生产信号映射到审查触发器、架构师行动及计划性监管检查点。是将政策转化为操作流程的机制，必须启动前存在。
联合规划 与应用AI团队的工作会议，用于精炼选择与解决专家问题。需携带需求与约束的书面记录、已明确权衡的建议模式或候选集、以及仅应用AI团队能解答的开放问题短清单。
限制声明 预先确定演示将明确的1-2项限制，并将其框定为故意范围边界。受监管场景中，预先明确界定的限制常体现严谨性，而回避或模糊限制会削弱信心。
成果文档 向未参与建设的发起人阐明部署价值的交付物。六个字段：含范围边界的用例、前期指标、后期指标、可审计控制、测量负责人、复用潜力。业务指标对比与复用说明使其成为可复用IP而非技术记录。
需求 vs 假设 需求可追溯至利益相关方实际陈述；假设是设计视为既定但从未声明的事项。无来源的假设最危险，因为无人记得其决策过程。
回退成本 系统围绕某决策构建后撤销它的代价，是权衡呈现的第三要素。多数演示会忽略此要素，但它往往最能改变会议走向，将"哪个技术答案更好"转为"哪个商业选择更优"。
场景化演示 针对买方自身工作流、数据结构与约束构建的演示，回答"这如何解决我的问题？"而非能力演示的"系统能做什么？"只有场景化演示能建立信心而非仅引发兴趣。
SLA（服务等级协议） 明确测量内容、违约定义及违约处理的承诺。阈值应追溯至用户体验期望、部署业务关键性或评估验收标准等具体依据，而非随意目标。
权衡呈现 用利益相关方可行动语言呈现架构决策：选择获得什么、放弃什么、系统建成后的回退成本（受监管环境下还包括对合规态势的影响）。目标是促成知情决策而非下达判决。
翻译（需求挖掘） 核心需求挖掘技巧：通过追问什么会破坏体验、用户绝不能察觉什么、出错时仍需保持什么，将利益相关方偏好（"无缝"、"快速"、"简单"）转化为可测试、有边界的约束。
翻译表 需求挖掘输出：每项单行记录利益相关方原话、隐含约束、强制的架构决策及待确认假设。每项单行保持从需求挖掘到设计的推理链条完整。
屏幕19：回顾：贯穿始终的五大要点
模块·回顾·3分钟 回顾：贯穿始终的五大要点
关键收获
01 结构化需求挖掘 按四类问题流程运行需求挖掘，将每个偏好翻译为约束，并将每项编写为带标记假设的需求行，使设计锚定业务案例。
02 沟通权衡与市场进入 用三要素（含回退成本）呈现每个权衡。合作伙伴路径[合作伙伴相关内容，架构师考试不涉及]针对买方真实场景设计演示并预先声明限制，带着需求、候选模式与开放问题进入联合规划。
03 反馈循环与SLA管理 构建将信号映射到触发行动与负责人的决策层，从真实来源设定SLA阈值，并按计划执行监管检查点。
04 移交与审计文档 在仍掌握逻辑时记录决策、被否替代方案及每个解决的权衡，并将控制登记册延续为审查员接受的证据。
05 入口选择与成果 根据延迟、合规与成本选择路径，为多入口设计准备责任映射表，并捕获前期指标、可审计控制与复用说明，使成果文档论证扩展合理性。
下一模块涵盖团队赋能与运营效率：为团队配置Claude工具、构建保持AI辅助工作可信度的开发者工作流，以及支持生产部署的运营健康。您现已掌握将部署从利益相关方的一句话需求转化为可持续成果文档的能力。下一模块将探讨将该部署移交给运营团队后的工作。
来源
Claude API构建(Skilljar)：无状态请求生命周期、系统提示词、评估与评分器、工具使用、RAG、提示缓存、代码执行。 Claude 101(Skilljar)：通用Claude能力与日常使用框架。（根据实时目录，Claude 101不包含模型系列或context window教学；这些概念需参考平台文档；发布时验证当前模型阵容。） AI能力与限制(Skilljar)：从前序模块延续的四属性决策透镜。 platform. claude. com/docs：模型名称、平台能力、路径可用性、驻留配置。构建时重新验证。 anthropic. com合作伙伴计划文档：合作伙伴市场进入阶段定义、IP贡献协议。 Anthropic应用AI团队文档：联合规划参与结构与准备输入。
屏幕20：恭喜！您已成功完成本模块。
模块完成·架构师·2分钟 恭喜！您已成功完成本模块。 模块4涵盖将可运行的AI部署转化为可辩护、可扩展业务资产所需的关键能力：利益相关方沟通、生命周期治理与市场进入决策。 部署的持久性取决于围绕它的文档、治理与成果证据。
0 个检查点通过
M1 Claude平台与解决方案设计 模型选择、提示架构、工具设计及平台层权衡。
M2 企业集成与生产 部署模式、集成架构及生产可靠性。
M3 负责任AI、安全与风险 安全框架、风险识别及治理实践。
M4 利益相关方协作、生命周期管理与市场进入 利益相关方沟通、生命周期管理及市场进入策略。
您在此
M5 团队赋能与运营效率 团队工具配置及运营支持实践。
即将开始
复习模块 重新开始
No flashcards for this lesson.
No quiz for this lesson yet.