先配人不先选工具
第一步是把业务骨干与工程人员配成一组，而不是先采购平台。业务方出判断标准与真实样本，工程方出实现与评测，两边对同一个任务负责。这个组合决定了实训与普通培训的分界，也决定了结业后有没有人能继续改。
任务卡是最小单元
每张卡写清触发条件、输入来源、输出格式、判断点、验收口径与接管人。卡片不超过一页，但必须让第三方读懂，最好让没参与过的人也照着跑一遍。读不懂的卡意味着判断还留在个人脑子里，实训结束后无人接手。
一周跑通最小链路
用真实数据搭一条端到端链路，允许人工在环，允许只覆盖一个分支，目的是尽早暴露数据缺口与权限问题。评测集要在第一周就开始建，不要等系统做完。演示环境跑通不算数，必须在业务方日常使用的系统里跑一次。
评测与接管同时看
实训期间就要建立几十条真实样本的评测集，并记录人工接管的原因分布，每周更新一次。只看单次演示会高估能力，接管率与错误类型才决定这条工作流能否进入日常，也决定要不要继续加场景、加人。
交付可复制的做法
结业时交付任务卡、评测集、运行手册与带教记录，让客户方两人能独立复现同类任务。运行手册要由接手人自己写一遍，写不出来说明还没学会。只交系统不交方法，第二个月通常退回原状，最后又回到找供应商。
适用与不适用
适合谁
- 能抽出二到五名骨干半脱产参与的业务团队
- 已有真实数据与可调用接口的企业
- 希望把能力留在内部而非长期外包的公司
不适合谁
- 只想听两天课、不愿投入人力的团队
- 数据完全无法出内网且拒绝做部署评估
- 期望一个月内替代整条业务线的预期
典型场景
某建材企业的报价组每周处理大量询价单。业务骨干与两名工程师参加实训，第一周把报价拆成任务卡，第二周在真实询价单上跑通草稿生成，第三周由报价主管逐条复核并记录接管原因，第四周交付运行手册并带教两名接手人。复核人始终是报价主管，工程方只在旁支持。
可执行步骤
- 从岗位里选一个高频、有真实样本、出错能兜住的业务任务作为首个场景
- 业务方与工程方结成固定对子，坐在一起把任务写成一页任务卡并当场确认验收口径
- 在业务方日常使用的系统里搭最小工作流，先只覆盖一个分支，并允许人工随时接管
- 用真实业务样本建立评测集，每条记录判定人与结果，并按原因分类统计接管情况
- 交付任务卡、评测集与运行手册，带教两名接手人独立复现一次同类新任务
常见坑
- 把实训做成听课，五天结束只留下笔记与账号，回岗后无人能复现；开训前就要约定交付物清单并按清单验收
- 场景选得太大，两周还在清洗数据，团队信心被耗尽；应把范围压到一个岗位的一个环节，跑通后再加
- 只在演示环境跑通，接入真实系统才发现权限与字段都不对；试跑必须在业务系统完成，权限提前申请
- 没有指定接管人，出错时互相推诿，工作流最终被停用；接管人须写进任务卡，并在演练中真的触发一次
自检与验收清单
- 业务方与工程方是否有固定的结对名单，且双方都能到场
- 任务卡是否一页写完，且让没参与过的人也能照着读懂
- 是否在业务方日常使用的系统里跑过一次完整的端到端链路
- 评测集是否包含真实样本、判定人与接管原因记录
- 是否完成两名接手人的带教，并能独立复现同类任务
常见问题
实训需要多少人参加
建议一个班不超过十人，按业务与工程一比一结对。人太多会导致样本与指导被摊薄，核心是做出两到三个真实任务，而不是覆盖所有岗位。人多时可按岗位分组，各组独立带一个任务。
一定要有工程背景吗
至少每组配一名能改接口、看得懂日志的人。纯业务团队也能推进，但速度会慢，遇到系统对接时容易卡住，需要外部工程支持。人选比人数重要，能读日志的人往往决定实训能否收尾。
结业后能力会流失吗
会，如果只交付系统不交付方法。把任务卡、评测集、运行手册与带教记录留下，并指定接手人，能力才留在组织里。建议在结业后第三十天回访一次，确认接手人仍在独立执行。