第12章　协同交付一个跨专业AI系统

工作阶段： 可靠交付——综合前十一章，把一个边界明确的专业问题做成可由别人复现、接手和维护的系统。
公共核心项目： 完成“小型企业设备运维与巡检站”：把环境感知、文字分类、指定资料检索、状态权限、人工确认和审计重放集成为可复现的低风险闭环。
核心技术： 系统集成、项目结构、依赖与版本、数据卡和模型卡、接口契约、现场测试、交接复现、维护计划与人机协作。
输入输出链： 真实委托 → 任务与验收合同 → 授权数据 → 高风险独立门 → 模型或规则 → 可运行程序或设备 → 固定测试与现场证据 → 交付包 → 另一组复现和维护。
应用中的AI： 参考系统使用本地环境偏离小模型；文字分类和最小人工表单作为透明基线，专业迁移可替换一个主要模型，但不要求堆叠全部技术。
协助开发的AI： 帮助建立项目结构、生成和解释多文件代码、适配接口、分析日志、补充测试和整理运行文档。
人的责任： 确定问题价值、数据授权、专业规范、验收责任和上线边界；审查每次变更并完成交接。
主要交付物： 可运行代码库、任务与团队合同、接口合同、环境与模型、冻结数据、系统卡、集成测试和真实报告、交接清单与维护计划。
明确边界： 综合项目不以功能数量评价，不直接控制危险设备；未经审核的运行经验不得在线改变模型、规则、权限或物理行为。
跨章关系： 综合使用前十一章；至少复用一个模型、一个人工或规则基线、一个失败集和一个人工接管点。

学习目标

学完本章，你将能够：

  1. 从真实委托中确定一个可完成的最小闭环，并建立团队任务、数据和验收合同；
  2. 选择必要的模型、规则、资料、程序或设备模块，解释为什么没有堆叠其他技术；
  3. 用统一项目目录、版本和运行入口形成可复现基线；
  4. 在真实或模拟现场根据日志和固定测试开展受控迭代；
  5. 组织另一组完成安装、运行、故障处理和交接复现，并根据暴露的问题补充交付包；
  6. 说明系统后续监测、更新、回滚和人工责任。

项目导入

综合项目不是把前十一章所有技术拼在一起。一个有价值的系统可以只使用一个视觉模型、一组规则和一份记录工具，也可以使用资料检索、语言模型与人工确认。技术选择取决于工作问题、输入条件、错误后果和维护能力。功能越多，接口和失效点也越多；无法解释和交接的复杂性不属于成果。

公共题目是“小型企业设备运维与巡检站”。全体先完成同一参考闭环：观察环境数据是否偏离参考范围，理解脱敏巡检文字，从指定检查卡返回带来源的候选说明，并在指定角色确认后生成本地事件记录。完成公共基线后，各专业只能替换一个主要输入或模型形成迁移版本，并保持状态、权限、安全和测试合同。系统只观察、提示和记录，不控制电源、门锁、交通、加热或机械装置。

每组需要完成最小工作闭环，并由另一组按照交付包从头复现。另一组不是观看演示，而是拿到一个干净副本，在另一台电脑或独立环境中安装、运行固定样例、制造一个故障并找到恢复方法。复现失败会暴露原组没有写出的路径、依赖、密钥、数据或专业假设，这正是交接学习的价值。

本章成果

AI协同开发路线

团队先向协助开发的AI提交真实委托、专业材料、数据条件、现有设备、禁止事项和学时边界。AI追问使用者、最小输出、验收样例、依赖、责任人和失败去向，提出不超过必要范围的系统方案。学生删减不需要的功能，冻结任务合同和接口。AI生成最小可运行系统及完整代码库，团队在干净环境运行，逐层保存日志，并在增加功能前冻结代码、模型、数据、配置和固定测试基线。每次现场问题都转成限定变更请求，成员审查文件差异并运行全部回归。达到内部验收后，把交付包交给另一组复现；原组只能根据书面反馈补充或修正，不能代替接手组操作。最后共同签署通过、限用、继续试运行或退回结论。

第一节　从真实委托建立团队任务、数据和验收合同

一、选择一个真正需要完成的工作结果

“做一个AI巡检站”仍然过于含糊。团队要把它改写成具体结果，例如：“在教学楼公共区域的授权图片中，把明显外观异常列为待人工复核，显示模型分数和资料依据，经过指定角色确认后生成本地记录。”这句话限定了输入、输出、使用范围和人工接管，没有承诺模型判断故障，也没有自动执行处置。

判断AI是否必要时先建立基线。若固定阈值或人工检查已经快速、稳定地完成任务，就不必增加模型；若图像、声音或复杂文本变化较大，模型能够减少候选筛查工作，可以作为辅助。团队在立项卡中写明模型带来的价值和增加的维护负担。

二、建立团队任务合同

任务合同包括委托人、使用者、目标、输入、输出、限制、不做事项、成功标准、高代价错误、数据授权、专业责任人和交付日期。跨专业团队按工作模块分工，不按专业名称机械切块。建议角色包括任务与专业规范、数据与授权、模型与基线、程序或设备、测试与交接；一个人可承担多项，但关键审查不能只由代码生成者完成。

接口也要进入合同。数据组交付什么字段和版本，模型组输出什么类别和分数，程序组怎样处理低置信度，测试组使用什么封存样例，交接组怎样判断复现成功，都要写成可检查约定。口头默契无法被另一组复现。

三、冻结最小范围与变更规则

最小闭环只解决一个问题，使用一种主要模型或模型路径，保留一种基线和一个人工确认点。立项后新增功能先进入“以后考虑”，除非它修复验收失败。每个变更写明原因、修改范围、预期结果和需要重跑的测试；AI不能因为看到更多资料就自动扩展需求。

控制变量实验选择系统中的一个关键量，例如感知阈值、检索前若干条或时序窗口。固定数据、程序和其他配置，先写出预测，再用同一测试比较质量、人工复核量和延迟。综合项目仍需保持实验可解释。

第二节　集成数据、模型、程序或设备形成可复现基线

一、用项目目录表达责任

建议目录包含README.md、config/、data/、models/、src/、tests/、docs/和logs/。原始或授权数据与处理数据分开，模型文件和标签一起保存，运行配置不包含密钥，测试数据不混入训练。README给出唯一启动入口和期望输出，数据卡、模型卡、系统图、安全边界和交接清单放在docs/。

版本清单记录操作系统、Python和主要依赖的大版本、模型及资料版本。项目应提供最小样例，避免接手者必须访问私有平台或真实敏感数据才能启动。云端模型作为可替换模块时，提供离线响应样例或本地基线，明确哪些结果不能由离线路径证明。

二、集成一个可运行的参考基线

配套工程位于resources/ch12/project/，固定项目是“小型企业设备运维与巡检站”。它不是让各组随意拼装几个页面，而是先提供一条能运行、能失败、能验收的参考闭环：带资产编号的脱敏工单文字先经过独立高风险门；普通工单再读取虚拟或预录环境窗口，校验输入，用本地小模型计算环境偏离分数，文字分类器判断工单类别，检索器返回指定检查卡；边界规则决定是否停止或转人工；运营主管确认后才形成持久仅追加记录，程序重启后仍可重放。学生在这条基线上做一次限定修改，并由另一组真实复现。

参考项目面向小型企业行政运营团队，主要工作角色是运维技术员和运营主管。输入是工单编号、资产编号、地点、现象文字以及温度、湿度、光照和质量标记；输出是环境分数、候选类别、可追溯检查依据、工作状态和审计事件。完成标准不是“界面亮了”，而是正常、边界、陌生、安全、设备故障、模型故障、知识故障、输入越界、权限、幂等和日志故障全部得到规定结果。系统只观察、提示、记录和转交，不控制电源、门锁、消防或设备。

工程用文档与代码共同表达责任。TASK_CONTRACT.md定义任务边界，TEAM_CONTRACT.md把任务与专业、数据与模型、程序与接口、测试与交接四类责任分开；INTERFACE_CONTRACT.md冻结跨模块字段；DATA_CARD.md和MODEL_CARD.md说明数据与模型来源和限制；ARTIFACT_MANIFEST.json锁定场景、知识、配置和模型摘要；SYSTEM_CARD.md说明用途与限制；AUDIT_LOG_SCHEMA.md说明持久记录；HANDOFF_CHECKLIST.md区分自动预检和真实复现；MAINTENANCE_PLAN.md规定以后怎样更新。完整代码放在src/，模型和资料分别放在models/与data/，固定结果放在reports/。这些文件使接手者不必从聊天记录猜项目是怎样做出来的。

感知模块沿用第9章的本质，但保持本章工程独立可运行。虚拟传感器公开read_window()；输入校验检查三个字段、单位约定的有效范围和quality；冻结JSON模型保存参考中心、尺度和权重，用加权绝对偏离得到分数。分数大于0.80为REVIEW，距门槛不超过0.05为BOUNDARY。边界不是“差一点就确定”，而是系统对阈值敏感的区域，所以直接转人工。真实设备接入必须另行依据准确型号建立适配器，默认工程不提供任何接线猜测。

服务模块把文字分为meeting_display、office_network、water_supply、unknown和high_risk。它是透明教学基线，将来可以在接口不变的前提下替换为语言模型。检索器只从三条冻结检查卡返回doc_id、标题和操作说明；没有依据或知识库不可用时，不允许模型凭常识补齐。高风险词在读取传感器、加载模型和访问知识库之前进入EMERGENCY_HANDOFF，即使设备、模型、知识库或日志同时故障，也不得把这一转交改写成普通模块故障；但转交只表示进入企业既有应急责任链，学生程序不执行应急处置。

集成主链的核心顺序如下：

text = classify(event["report"])
if text["label"] == "high_risk":
    return emergency_handoff()           # 先于可选设备、模型和知识模块

window = sensor.read_window()
validate_window(window)                 # 无效则 STOP_BAD_INPUT
score = model.score(window)             # 本地、离线
sensing = sensor_state(score, threshold, margin)

if text["label"] == "unknown" or sensing == "BOUNDARY":
    return move_to("MANUAL_REVIEW")

evidence = retriever.find(text["label"])
if evidence is None:
    return move_to("MANUAL_REVIEW")
move_to("EVIDENCE_FOUND")
move_to("AWAITING_CONFIRMATION")        # 尚未形成正式记录

只有operations_supervisor能调用confirm()把等待状态变成COMMITTED或CLOSED_NO_ACTION；maintenance_technician可以提交工单但不能批准。同一工单编号和相同负载再次提交时直接返回当前状态，不增加记录；同一编号携带不同负载时进入STOP_ID_CONFLICT。EventStore(path)把每个事件写成UTF-8 JSONL，刷新到磁盘，程序重新打开后可由replay()重建最终状态。设备无新数据、模型文件不存在、日志不可写都有不同停止状态，不能统一吞掉异常。应用中的AI是环境偏离小模型；文字分类、状态、权限、安全和审计是透明基线与确定性控制，最终决定由人负责。

学生在工程根目录执行：

python acceptance.py
python -m src.main

src.main用一条带资产编号的会议显示屏无画面工单走过环境评分、文字分类、证据检索、等待确认和运营主管接受，并把可重放日志写入output/demo_audit.jsonl。acceptance.py检查必需文件、冻结制品摘要、全部Python语法、7个单元测试、完整集成评估和临时干净目录复现预检。工程只使用Python标准库，不访问网络，不要求云账号和真实硬件，默认数秒完成。

固定集成包共有12条：两个正常样例到达AWAITING_CONFIRMATION；门槛边界样例和陌生表述进入MANUAL_REVIEW；普通冒烟事件以及冒烟与设备、模型、知识故障的三个组合事件都进入EMERGENCY_HANDOFF；单独的设备断开、模型缺失、知识库不可用和温度越界分别进入STOP_DEVICE_LOST、STOP_MODEL_MISSING、MANUAL_REVIEW和STOP_BAD_INPUT。真实运行的实际结果为12/12通过。

同一评价还实际运行最小人工表单基线。它把显式高风险交给应急人工链，其他全部进入人工队列，因而安全处理12/12，但自动找到证据为0；助手在两个普通工单中自动返回可定位依据，其价值是减少常见事件的初步查找，不是替代人工安全底座。七项操作测试继续验证相同负载重复提交不产生第二次副作用、同编号不同负载被拒绝、运维技术员不能确认、运营主管可以确认、JSONL重新打开后能重放到COMMITTED、普通工单日志不可写时停止，以及高风险在日志不可写时仍保持应急转交。

这些结果只证明参考工程的自动技术门。项目的reproduce.py会新建临时目录，只复制最小运行包，再从头启动并走到COMMITTED；这能发现绝对路径、原目录缓存和漏带文件，却不能扮演真实接手者。报告因此同时写明automatic_clean_reproduction=checked_by_reproduce_py和independent_team_reproduction=PENDING_CLASSROOM。在另一组真正按README安装、运行、制造知识库故障、恢复并提交问题单之前，只能形成“课堂参考基线通过、真实交接待完成”的限用结论，不能写“项目已交付上线”。

三、在干净环境冻结基线

原开发电脑能运行，可能依赖未记录的缓存、环境变量和本地文件。冻结基线前，团队使用新目录或另一台电脑，按README创建环境、安装依赖、运行三条固定样例并核对结果。任何人工复制但未写入说明的文件都属于交付缺陷。

基线冻结后记录代码、模型、数据、资料、配置和测试版本。新增功能建立新版本，不覆盖已验收基线。协助开发的AI生成依赖清单后，学生还要实际重建环境验证，不能只相信文本说明。

团队还要保存一份“最小成功证据”：一条输入样例、完整执行命令、期望状态、关键日志和结果文件校验值。接手者先复现这一证据，再运行更多测试。若连最小证据都无法重复，继续讨论模型精度或界面功能没有意义。

第三节　在真实或模拟现场测试并受控迭代

一、三类现场证据

固定测试用于版本比较；回放或虚拟现场用于稳定复现设备和时间过程；真实现场用于发现环境、人员和工作负荷差异。硬件不足时可以完成前两类，但报告必须说明不能证明真实传感器稳定性、长期漂移和现场行为。

公共项目至少记录输入来源、环境条件、模型分数、规则状态、人员修改、端到端延迟和最终结果。真实现场只使用授权数据，摄像头和麦克风说明采集范围、保存位置和删除方式。任何高风险发现直接转交专业责任人，不由学生系统处置。

二、让失败推动一次限定修改

团队从失败集中选择一个有代表性问题，例如相似背景造成误报、资料无命中仍出现候选说明、设备断开后沿用旧值或接手者无法找到模型文件。先定位错误属于数据、模型、检索、规则、接口、设备、文档还是人，再向AI提交限定请求。

请求应写：“固定任务合同、接口和测试集；只修改src/device_adapter.py，当读取超时时返回STOP_DEVICE_LOST，不得沿用上次值；列出文件差异并运行全部测试。”修改后团队逐行审查关键差异，运行正常和故障回归，并记录是否产生副作用。若失败来自数据授权或专业定义，不能用改代码掩盖。

三、验收系统而不是单个模型

综合验收同时查看任务价值、基线比较、模型错误、证据来源、状态权限、故障恢复、人工工作量、资源成本和可复现性。模型指标通过但交接失败，系统仍不能通过；模型略逊于复杂方案但规则基线稳定、成本低，团队可以选择基线。

验收结论包括通过、限定场景试运行、退回修改或停止。限定使用要明确对象、时间、数据范围和人工监督。任何变更都进入第11章的回归门和回滚流程。

四、专业迁移卡

专业迁移卡A：商贸与设计服务站。 输入改为商品资料、用户需求和授权素材，应用AI协助分类需求或生成候选传播内容；高代价错误是价格事实错误、权利材料缺失和未经批准发布。交付物增加事实清单、品牌规范、内容版本和业务负责人签字。

专业迁移卡B：制造与交通巡检站。 输入改为零件、道路或车辆的授权图像、声音和传感数据；高代价错误是漏报明显异常、设备失效仍给正常结论和越权控制。交付物增加设备事实包、按批次测试、旁路试运行和专业责任人接管，不连接生产或交通控制。

专业迁移卡C：生物与风景园林环境站。 输入改为实验或养护记录、植物图像和环境时序；高代价错误是单位、批次和校准错误，或把相关性写成因果处置。交付物增加数据批次、校准记录、专业规程来源和现场复核，系统只观察与建议。

第四节　完成复现、交接、展示和维护答辩

一、由另一组独立复现

接手组获得代码库、最小数据、模型或基线、环境说明、测试集和交接清单，但不接受原组现场代操作。接手组记录开始时间、环境、执行命令、首次失败、缺失说明和最终结果。至少完成四项：在干净环境启动；运行正常和失败样例；制造一个约定故障并恢复；说明系统的人工接管点。

原组观察但不替接手组修复。复现结束后，接手组提交问题单，区分文档缺失、依赖错误、数据或模型缺失、接口不清和专业假设。原组根据问题单修改交付包，再由接手组重试。只有接手者能继续工作，才算完成交接。

二、交付包说明“怎样继续”，也说明“不要做什么”

用户手册写常规运行，故障指南写停止和恢复，维护计划写资料、数据、模型、规则、设备和依赖的检查周期。风险边界列出未经专业批准不能扩展的功能。模型卡说明训练或调用范围、测试表现和陌生输入；数据卡说明来源、授权、处理和删除；系统卡说明模块、权限、监测和回滚。

展示不只演示最佳样例。团队应演示一次正常输入、一次失败停止、一次人工拒绝和一次重放日志，说明为何采用当前模型或规则。答辩人员可以要求更换输入、询问数据来源或让系统恢复故障，团队不能只播放预录成功视频。

三、维护答辩与前沿拓展

维护答辩回答：场景变化怎样被发现；谁审核新资料和新数据；什么条件触发回归；谁批准新版本；如何回滚；项目停止后怎样删除或归档数据。AI可以协助整理问题和生成检查脚本，不能代替责任人签署。

强化学习或经验更新只放在拓展学习中。学生可以在仿真环境定义状态、动作和奖励，或用离线日志比较候选策略；任何经验必须经过授权、清洗、审核、离线训练和固定验收后，才可能进入新版本。终端和工作流不得在真实现场根据即时反馈自行改变权限、安全规则或物理行为。

四、形成最终交付结论

最终结论不必是“正式上线”。对于课程项目，更合理的结果可能是“通过H0复现，允许在指定场景旁路试运行”“视觉模型需增加跨设备数据后再验收”或“规则基线已经满足需要，暂不部署模型”。结论要引用测试、复现和专业责任人的证据。

本章小结

跨专业项目的目标不是堆叠模型，而是把真实委托转成边界清楚、能够复现和交接的最小系统。统一目录、版本、接口、数据卡、模型卡和固定测试，使AI生成的代码从个人电脑中的结果变成别人可以继续工作的成果。

现场失败必须转成限定修改和完整回归。另一组独立复现是本章最重要的验收：它能够暴露未记录的依赖、路径、数据和专业假设。仿真和审核后的经验更新可以作为前沿拓展，但运行系统不能未经验证自行改变关键行为。

关键术语

目标测试

一、单项选择题

  1. 综合项目选择技术的首要依据是（　）。A．模型数量　B．真实任务、输入条件和错误后果　C．界面动画　D．代码行数
  2. 判断项目达到交接要求的最佳证据是（　）。A．原作者演示成功　B．另一组按交付包独立复现并处理故障　C．模型文件很大　D．使用热门框架
  3. 下列最符合最小闭环原则的是（　）。A．一次加入全部技术　B．完成一个输入到人工确认输出的边界明确链路　C．只画概念图　D．只交生成代码
  4. 运行经验进入新版本前必须（　）。A．自动在线学习　B．经过授权、审核、离线更新和固定验收　C．删除旧版本　D．绕过责任人

二、判断并改错

  1. “跨专业项目功能越多，越能证明系统质量高。”请判断并改正。
  2. “原组能在自己的电脑上运行，就说明交付包已经可复现。”请判断并改正。

三、简答与操作题

  1. 将“做一个企业AI巡检站”改写成包含使用者、输入、输出、边界和人工责任的任务描述。
  2. 为综合项目设计一个目录结构，并说明数据卡、模型卡、固定测试和日志分别放在哪里。
  3. 写出接手组复现项目的四个必做步骤，以及原组在复现期间不能代替完成的事项。
  4. 设计一次只修改设备适配层或模型阈值的受控迭代，列出修改申请、差异审查、回归和回滚证据。

答案编号：A2-12-01—A2-12-10。完整答案与评分要点统一放入书后“目标测试参考答案”。