Course syllabus

课程大纲 · 选择一节课

将项目合作作为一个学习循环来运行，并设置明确的发布关卡

通过一个给定的试点，追踪发现、评估、集成、发布和观察的全过程。响应新出现的证据，并计算一个可复用的连接器何时能收回其构建和维护成本，而不是把第三个客户当作自动抽象的规则。

28 分钟

作者：FDEInterviews · 已更新

课程文字稿

这是《前沿部署工程基础》的第三课。随着证据的到来，重新审视范围和设计，同时让评估、权限和运营准备始终领先于发布。当需求、维护和成本方面的理由充分时，将有用的模式沉淀到共享能力中。

你已经梳理了最后一公里的工作，以及在其上协作的各个角色。本节课为《前沿部署工程基础》的其余内容提供一个可操作的结构，以及一个你可以在学习实现细节之前完成的小型规划练习。

把这个循环当作一组问题来使用。这张图让八项活动始终可见。它并不是一份强制性的按时间顺序执行的部署计划。

发现真正的问题，划定一个薄切片的范围，通过定义“什么算有效”来进行评估，发布一个经过批准的版本，与客户的系统集成，观察它的实际表现，学习并修改构建，最后产品化，使其可复用。产品化会反馈到发现环节，把学到的经验带入下一个项目合作。

特别要注意的是，身份认证、集成和安全不能等到生产发布之后才处理，仅仅因为“集成”在图中出现得较晚。这些检查在发现阶段就已开始，并且必须在受影响的使用之前满足其发布条件。

每项活动都会提出一个问题，并留下一些成果。发现环节问的是我们实际要解决什么任务和约束，留下的是一份带有未决假设的工作流轨迹；范围环节问的是这个阶段能够评估什么样的有界成果，并确定合格人群、排除项和决策。评估环节问的是什么才算有用和可接受，其答案是一套基线、质量规则、失败案例和分析计划。发布环节问的是这个版本是否被允许发布，并已为预期用途做好准备。证明？一份经过批准的发布范围，以及一个经过检查的制品。

集成环节问的是数据源、身份、网络和下游契约是否成立，留下的是经过测试、有明确责任人的边界；观察环节问的是使用过程中发生了什么，包括失败和未完成的工作，并收集质量、完成度、成本和运营信号。学习环节问的是哪个假设或实现需要修订，其答案是有证据支持的变更，或者叫停。产品化环节问的是哪项重复出现的能力值得为复用而持续维护，它留下的是一份复用提案、测试、成本和一位长期负责人。

评估是规格说明的一部分，尤其是针对概率性行为。它不能取代确定性要求，例如权限执行、有效的状态转换和恢复。人工审查环节可以降低某些风险，但它需要明确的范围、信息和处理能力。仅仅存在人工审查环节并不等于发布批准。

样本和原型可以针对有限的问题产出有用的证据。应说明它们能回答哪些问题，哪些问题需要目标环境或具有代表性的评测才能回答。而且，当更安全的已批准测试数据能够回答问题时，生产数据不应作为默认的测试材料。

现在围绕这个循环跟踪一项变更。在这个合成货运试点中，初始需求是“总结每一个异常”。

观察发现，操作员首先需要识别货运单，并找到适用的合同。因此，方案变成一个面向特定记录集合的、只读的国内决策辅助工具，不确定的匹配则转交人工审查。团队在实施之前就商定了适用案例和质量检查。

随后的集成测试显示，某些合同读取操作未能保留调用者的权限范围，这意味着请求是以服务自身更宽泛的凭证运行的，而不是以提出请求者的权限运行。这一发现使团队回到设计和发布决策阶段。这不是上线后可以随意观察的事情。

在访问路径得到纠正并按责任流程验证之后，如果其他必需的检查都通过，可以进行一次有边界的发布。然后出现了新情况。后续观察发现，操作员在验证多段货运单的摘要上花费了更多时间。

那么，这些货运单是否被排除了？如果是，就记录是否有任何此类货运单意外进入了工作流。如果它们被包含在内，就调查失败的环节并重新审视范围。无论哪种情况，都不要在不声明的情况下把棘手的案例从成功报告中剔除。

当证据和权限有此要求时，发布可以被暂停、缩减或回退。迭代并不是承诺每个问题都能通过再多改一次提示词就得到解决。在实验变成无限期之前，先商定支持继续进行所需的时间、成本和证据。

接下来，要区分重复出现与可复用场景。反复出现的需求是调查共享组件的理由，但它并不能证明第三次出现类似实现就是进行泛化的正确时机。

三个客户可能使用名称相似的字段，但具有不同的语义、权限模型或生命周期规则。因此，要比较稳定的内核与变化的部分。

适配器可以共享解析、验证和检查点机制，同时将客户特定的映射和凭证留在配置中。共享行为需要跨受支持合同的测试、针对现有用户的迁移规划，以及一位能够维护它的负责人。

可复用的工作同样可以服务于当前客户。一个受支持的连接器可以减轻他们的维护负担。反过来，当需求范围很窄时，一次性集成可能是合适的，而通用框架的成本会超过它节省的开支。这个决策并不是对软件和服务的道德排序。

现在来计算一个小的复用决策。这个合成估算比较了未来各次部署所需的工程小时数。

定制工作每次部署需要 20 小时。共享连接器需要 36 小时的前期投入，外加每次部署 8 小时的配置和验证时间。先忽略维护，以呈现基本的算术，然后再明确地加上它。

把两者画出来。定制是 20 小时乘以部署次数。共享是 36 加 8 乘以次数。20d 等于 36 加 8d，所以 d 等于 3。三次部署时打平，各为 60 小时。第四次节省 12 小时，80 对 68。每次超过打平点的部署都节省每次部署费率的差额，即 20 减 8。这就是为什么每次节省 12 小时。

现在在同一规划周期内加上 12 小时的维护。这使前期数字变为 48，交叉点变为 d 等于 4。所以四次部署在 80 小时打平，第五次节省 12 小时，100 对 88。

这些估算并不能证明会有五个客户到来，也不能证明共享行为会适合他们。它们比较的是工程小时数，而不是利润。一个真实的决策还可能包括支持、机会成本、迁移、可靠性、许可和战略价值。

给两个选项都加上可比的成本，并避免把已经花费的精力算作未来节省，因为一个虽然节省设置时间、但把风险故障模式集中化的组件，同样需要可靠性审查。

最后，决定由谁来把经验传承下去。一个复用提案应该指明重复出现的需求、来源证据、稳定接口和受支持的变体，以及预期需求、估算成本、迁移和维护负责人。

与产品团队协调，而不是假设现场工程师能把每一个有用的抽象都加到共享平台上。有时正确的产出是更好的文档、一个部署模板、一个测试夹具，或一个明确记录的不支持场景。产品学习比新功能更广泛。它应该在不泄露客户数据、也不把偶然的变通方法固化为产品契约的前提下，帮助未来的决策。

试点之后，记录工作流程中发生了什么变化，以及哪些仍然不确定。一次干净的交接可以与在新负责人手下的后续迭代并存，而最初的工程师不必无限期地留下来维持这个循环。

请在此处暂停视频。运行成本测试装置。将共享设置的时长从 36 小时改为 60 小时，同时保持每次部署 8 小时和 12 小时维护时长不变。在相同输入下，六次部署时两者在 120 小时处打平，七次起共享方案变得更便宜。请解释为什么只统计出现次数会漏掉这一变化。然后为所提供的试点项目，针对每个循环活动各写一行。把调用方范围的故障放在任何受影响的生产发布之前。对于验证负担，请写明指标、细分群体和下一个测试，而不是笼统地写“改进模型”。最后，为该适配器起草一份复用提案：包括共享行为、两个客户特定的变体（每个变体配一个测试）、预期部署次数以及由谁维护。当范围和算术都明确、且未知的需求仍被描述为未知时，该任务即通过。

回顾一下。这个循环会随着证据的到来重新审视决策。它不是一个把控制措施往后推的发布流程。评测与权限、确定性契约和运维要求互为补充。观察必须涵盖失败、未完成和困难的工作。复用取决于稳定的行为、需求、成本和维护，而不是自动出现的第三次出现。并且要在获得认可的负责人之下，把学到的经验沉淀进共享代码、测试或文档。

以上就是第三课。本系列的下一课，将把陈述的需求与人们实际执行的工作进行对照。完整课程及其练习和演练见 fdeinterviews.com。

TL;DR：随着证据的到来重新审视范围和设计，同时让评测、权限和运维就绪始终领先于发布。当需求、维护和成本论证支持时，把有用的模式沉淀进共享能力。

你现在的位置。你已经梳理了最后一公里的工作以及协作其中的各个角色。本课为 Foundations 的其余部分提供一个可操作的结构，以及一个你可以在学习实现细节之前完成的小型规划练习。

循环：一组问题

该图保持八个活动始终可见，并将集成置于受影响的生产发布之前。它的箭头表示需要重新审视的依赖关系，而不是单向的项目计划。身份、集成和安全问题在发现阶段就已启动，其所需的检查必须在使用前通过。评测标准尽早定义，并在集成后的版本上再次执行。某项检查失败时，团队回到相关的假设、设计或范围决策。

评测是规格说明的一部分，尤其是针对概率性行为，但它不能取代确定性要求，例如权限执行、有效的状态转换和恢复。人工审核环节可以降低某些风险，但它需要明确的范围、信息和容量；仅仅存在人工审核并不等于发布批准。

样本和原型可以就有限的问题产出有用的证据，因此要说明它们能回答哪些问题，哪些问题需要目标环境或具有代表性的评测。当更安全的已批准测试数据能够回答问题时，生产数据不应该是默认的测试材料。

一次变更，围绕循环

在这个合成的货运试点中，最初的需求是“总结每一个异常”。观察显示，操作员首先需要识别货运单并找到适用的合同。于是方案变成一个面向已定义记录集合的国内只读决策辅助工具，不确定的匹配则转交人工审核。

团队在实现之前先就符合条件的案例和质量检查达成一致。随后的集成测试表明，某些合同读取没有保留调用者的权限范围，也就是说，请求是以服务自身更宽泛的凭证运行的，而不是以提问者的权限。这一发现使团队回到设计和发布决策阶段；这不是上线后可以随意观察的事情。

在访问路径得到修正并按责任流程验证之后，如果其他必需的检查都通过，可以进行一次有边界的发布。后续观察显示，操作员在多段运输货物的摘要验证上花费了更多时间。如果这些货物原本被排除在外，要记录是否有任何货物意外进入了工作流；如果包含在内，则要调查失败的环节并重新审视范围。不要悄悄地把棘手的案例从成功报告中剔除。

在证据和权限要求的情况下，发布可以被暂停、缩减或撤销，而且迭代并不意味着每个问题都能通过再多改一次提示词来解决。在实验变得遥遥无期之前，先就继续进行所需的时间、成本和证据达成一致。

重复出现还不等于复用案例

重复出现的需求是调查共享组件的理由，而不是证明第三次类似实现就是泛化的正确时机。三个客户可能使用名称相似的字段，但其语义、权限模型或生命周期规则各不相同。

比较稳定核心与可变部分。一个适配器可能共享解析、验证和检查点机制，而将客户特定的映射和凭证留在配置中。共享行为需要针对所支持契约的测试、面向现有用户的迁移规划，以及一位能够维护它的负责人。

可复用的工作也可以服务于当前客户，因为一个受支持的连接器可能会减轻他们的维护负担。另一方面，当需求范围狭窄、通用框架的成本超过其节省时，一次性集成可能是正确的选择。这个决策并不是在软件与服务之间进行道德上的高下排序。

一个小的复用决策，算一算

这个假设性的估算比较了未来多次部署所需的工程小时数。定制工作每次部署需要 20 小时，而共享连接器需要 36 小时的前期投入，外加每次部署 8 小时的配置和验证时间。先不把维护算进来，让基本的算术一目了然，然后再明确地加上它。

def costs(deployments, shared_maintenance=0):
    if type(deployments) is not int or deployments < 0:
        raise ValueError('Deployment count must be a nonnegative integer')
    if shared_maintenance < 0:
        raise ValueError('Maintenance hours cannot be negative')
    bespoke = 20 * deployments
    shared = 36 + 8 * deployments + shared_maintenance
    return bespoke, shared

for count in range(1, 6):
    print(count, costs(count), costs(count, shared_maintenance=12))
assert costs(3) == (60, 60)
assert costs(4) == (80, 68)
assert costs(4, 12) == (80, 80)
assert costs(5, 12) == (100, 88)
# 1 (20, 44) (20, 56)
# 2 (40, 52) (40, 64)
# 3 (60, 60) (60, 72)
# 4 (80, 68) (80, 80)
# 5 (100, 76) (100, 88)

在不计入额外维护估算的情况下，三次部署时两者持平，第四次可节省 12 小时。如果在相同的规划周期内加上 12 小时的额外维护，四次部署时持平，第五次节省 12 小时。持平点就是两条线的交叉处：每次部署 20 小时，对比前期 36 小时加上每次部署 8 小时，即 20d = 36 + 8d，解得 d = 3。超过持平点后的每一次部署，节省的都是每次部署费率的差额，即 20 减 8，这就是为什么每次都节省 12 小时。加上 12 小时的维护后，前期投入变为 48 小时，交叉点移到 d = 4；在这个练习中如果把前期投入提高到 60，交叉点则移到 6。这些估算并不能证明会有五个客户到来，也不能证明共享行为能适配他们。

这些是工程小时数的比较，而非利润估算，实际决策还可能涉及支持、机会成本、迁移、可靠性、许可和战略价值。要给两个选项都加上可比的成本，并且不要把已经花费的精力算作未来的节省。一个虽然节省搭建时间、却把高风险故障模式集中到一处的组件，同样需要经过可靠性评审。

当当前的承诺只需要一次性方案时

将同样的合成成本估算应用于一个实际的排期决策。一个部署已获得资金支持，需在下周交付，另有四家机构表示了兴趣，但均未做出承诺。该工程师下周有 28 个可用工作小时，其中 8 个小时已用于无关的客户工作。上述估算涵盖了拟议连接器范围的实现、配置和验证。在本练习中，如果所需的检查通过，两种方案在技术上均可接受，且一次性方案已有获得认可的支持负责人。在真实的项目中，这些条件都需要有证据支持。

撰写一份建议，将下周的可用资源与更长期的规划视野区分开来。本次部署有 20 个小时可用：28 减去 8。定制方案恰好使用这 20 个小时。共享方案在首次部署前需要 44 个小时，即 36 个小时的搭建加上 8 个小时的配置和验证，比该项目所拥有的时间多出 24 个小时。无论是潜在需求还是未来的节省，都无法在下周提供这些时间。

8 个小时的无关工作已从可用资源中扣除，不要再次将其计入连接器的成本。12 个共享维护小时属于更长期的对比，而非第一周的实施估算。它们代表此测试场景中额外的共享组件维护。如果任一方案还有其他支持成本，应在使用总计数据做出真实决策之前，以可比的方式将其纳入。

一份完整的建议是：为已获资金的交付选择有边界的一次性方案，记录可能可复用的接口和测试，并在需求和归属更明确时另行安排一次复用评估。这既服务了当前的重要客户，又不必承诺构建通用平台。需说明 20 小时的估算没有留下任何项目余量；一旦超支，需要就范围、人员或日期做出决策，而不是无形的加班。不要悄悄占用另一客户的 8 个小时。

所有五个部署都获得资金支持，一位共享维护者接受所述范围，且第一个截止日期后移，使其之前有总共 52 个工作小时。其中 8 小时保留给无关工作，剩下 44 小时用于共享的第一个部署，因此现在恰好符合估算，而全周期对比显示共享方案领先 12 小时。如果这些合同确实共享所假设的行为，请修改你的建议。改变选择的是需求和时间，而不是重复。修订后的计划在第一个里程碑处仍然没有富余容量。

谁来延续经验沉淀

一份复用提案应指明重复出现的需求、来源证据、稳定接口、支持的变体、预期需求、估算成本，以及迁移和维护的负责人。应与产品团队协调，而不是想当然地认为现场工程师能把所有有用的抽象都加到共享平台上。

有时正确的产出是更好的文档、一个部署模板、一个测试夹具，或一个明确记录的不支持场景，因为产品层面的学习比新增一个功能范围更广。它应有助于未来的决策，同时不泄露客户数据，也不把一个偶然的变通方法固化为产品契约。

试点结束后，记录工作流中发生了哪些变化，以及哪些仍不确定。干净的交接可以与在新负责人手下的后续迭代并存；原工程师无需无限期留任来维持这个循环。

在继续之前完成这些

运行成本夹具。将共享搭建从 36 小时改为 60 小时，同时保留每个部署 8 小时和 12 小时维护时间。六个部署时两者持平于 120 小时；到七个部署时共享方案更便宜，前提是输入相同。请解释为什么只统计出现次数会漏掉这一变化。

针对所提供的试点，为循环中的每项活动写一行。把调用方范围导致的失败放在任何受影响的生产发布之前。对于观察到的验证负担，应指出具体指标、细分群体和下一次测试，而不是仅仅提议“改进模型”。

然后为该适配器起草一份复用提案。列出共享行为、两个客户特定的变体、每个变体对应的测试、预期部署数量以及维护者。当范围和算术都明确、且未知的需求仍被描述为未知时，即视为通过。

深入阅读

• AI 成本与单位经济学为“一个部署是否物有所值”提供了量化依据，而这正是产品化阶段必须回答的问题。
• 模糊问题的范围界定涵盖第二阶段，即范围必须与可用证据和约束条件相匹配。
• RAG 流水线端到端实战讲解最常见的 AI 部署形态的交付阶段。
• 将 RAG 概念验证推向生产规模是作为面试题出现的集成阶段，包含一次发布所需的运维检查。
• 前沿部署工程师到底做什么将同一个循环与一个有代表性的一周并置对照。

核心要点

• 该循环会随着证据的到来重新审视决策；它不是一个推迟管控的发布流程。
• 评测是对权限、确定性契约和运维要求的补充。
• 观察必须包括失败、未完成和困难的工作。
• 复用取决于稳定的行为、需求、成本和维护，而不是自动出现的第三次机会。
• 在获得认可的负责人前提下，将经验沉淀到共享代码、测试或文档中。

自我检测

先作答再看答案。回忆才能加深记忆，单纯认出并不能。

• 1集成试点未通过调用方范围的测试。强制执行可以等到生产发布之后吗？
• 2设置共 36 小时，每次部署 8 小时，维护 12 小时，共享方案从什么时候开始比每次部署 20 小时更划算？
• 3三个适配器看起来相似。在泛化之前应该检查什么？
• 4一个共享连接器在五次部署中节省了时间，但只有一个项目有资金，且共享方案的首次部署超出了下周的产能。建议应该区分什么？

免费注册以保存进度并返回本课程。