教材联合开发：那次我们因为一个公式版本吵了三天

去年秋天，南京某高职的会议室里，空调开得挺足，但气氛快结冰了。三个学校的老师，两个企业的工程师，围着一本《工业机器人现场编程》的教材初稿。负责统稿的老张，干了二十年教学，拿着打印稿指着第47页一个运动学公式：“这个下标不对，应该是末端执行器相对于基坐标系的变换，你们写成工具坐标系了。”对面企业来的小王，二十七八岁，产线调试出身，一脸无辜：“我们产线上就这么写的啊，机器人示教器上显示的就是这个。”老张脸都绿了。小王补了一句：“而且我们车间师傅都看得懂。”——得，吵起来了。从下午两点吵到五点，没结果。第二天接着吵。第三天，老张拍了桌子：“这教材我不统了，你们自己玩吧。”

你猜最后怎么着？不是谁说服了谁，是教研室主任想了个歪招：把两个公式都放进去，一个打星号，标注“适用于教学标准”，另一个放二维码，扫出来是“企业现场快速参考”。教材印出来了，但这事一直梗在我心里。因为我就是那个夹在中间、两头传话的“产学研联络员”。说实话，教材联合开发这词儿听着挺高大上，实际干起来，脏活累活一大堆。

越“联合”，越像拼盘？

反常识吧？按理说，学校出理论、企业出实践，强强联手，教材应该更扎实才对。但现实是，联合开发的教材，经常变成“拼盘”——第一章学校老师写的，严谨但枯燥；第二章企业工程师写的，案例鲜活但知识点跳跃；第三章又换了个学校，风格突变。学生翻开书，像在三个不同的饭馆拼桌吃饭。你问为什么？

不是人的能力问题，是协作机制烂了。你想想，软件开发要是这么干——A写登录模块，B写支付模块，C写数据库，然后直接打个压缩包发给用户——早崩了。但教材联合开发，大部分团队还真就这么干的。各写各的章节，邮件发来发去，最后Word合并，格式乱成一锅粥。参考文献编号能对上的算奇迹。

我经历过一个更绝的：某本《传感器与检测技术》教材，三个学校联合开发。第一章讲热电偶，用的分度号表是旧国标；第二章讲热电阻，引用的却是新国标。结果学生做实验，按第一章查表算出来的温度，跟第二章的公式对不上。老师被问得哑口无言。这哪是教材，这是“找茬游戏”。

教材联合开发里的“脏活”：版本、接口和门禁

说白了，教材联合开发本质上是一个多主体异步协作的内容工程。既然是工程，就得有工程化的手段。别一听“工程化”就头疼，我尽量说人话。

先讲版本。你写一章，他改一段，最后谁改了什么？不知道。传统做法是文件名加日期：“机器人教材_最终版_真的最终版_20231015_v3_张老师修改.docx”。这玩意儿看着就想笑，但笑完你发现，你自己也在用。教材联合开发里，版本混乱是头号杀手。一个公式变了，引用它的例题没跟着变；一个图改了，对应的文字说明还指着旧图编号。怎么破？别用Word合并，用带版本控制的协作工具。不一定是Git那么硬核，哪怕是在线协作文档（比如腾讯文档、飞书文档），至少能看到修改痕迹和历史版本。我们后来一个项目强制要求：所有章节必须在同一个在线文档库里写，每天下班前提交一次“快照”。谁改的、改了什么，一目了然。虽然还是有人偷偷复制到本地改，但至少能追责了。

再讲接口。教材联合开发里，“接口”是什么？是章节之间的衔接点。比如第一章讲了坐标系变换，第二章要用到这个知识讲轨迹规划，那第一章的符号定义、公式编号、术语叫法，必须跟第二章对齐。这就是接口。我们吃过亏：第一章用R表示旋转矩阵，第二章用T表示齐次变换矩阵，第三章又冒出来个H。学生翻回去找符号说明，发现符号表在附录C，第289页。谁看啊？后来我们学乖了，在联合开发启动会上，先花半天时间把符号约定表和术语对照表定死。谁不遵守，统稿时直接打回。别怕得罪人，总比印出来被学生骂强。

最要命的是“门禁”。软件开发有代码审查，教材联合开发有吗？大部分没有。写完就交，交了就合，合了就印。错别字、公式错误、图表编号乱，全靠编辑肉眼扫。我们后来搞了个土办法：交叉盲审。A学校写的章节，由B学校和C企业的工程师匿名审；审完填一张检查表，重点看三样：公式有没有推导漏洞、案例跟知识点对不对得上、实训步骤有没有安全风险。别小看这个，有一次审出一章讲PLC接线，企业工程师直接批注：“这个接线顺序，按我们现场经验，先接24V电源会烧端口。”——冷汗都下来了。

那次我们差点用Git来管教材

说到版本控制，我确实动过用Git的念头。真的，我连仓库结构都想好了：每个章节一个分支，主分支放统稿版本，每个修改提pull request，教研室主任当reviewer。听起来很酷对吧？但现实啪啪打脸。

第一个问题：老师们不会用命令行。你让他们装Git客户端、学commit、push、merge，比让他们写一章新教材还痛苦。第二个问题：教材不是纯文本。里面大量公式、图表、排版格式，Git对Word文档的合并基本等于灾难。你改一段话，它给你整页标红。第三个问题更致命：教材的“逻辑依赖”比代码复杂多了。代码模块可以独立编译，教材章节能吗？第一章的例题用了第二章才出现的公式，你让不让学生活？这种知识点依赖关系，Git根本管不了。

后来我们退了一步，用了一种半自动的土办法：把每一章拆成独立的小节，每个小节用一个Markdown文件写（公式用LaTeX，图用链接占位），然后用一个简单的脚本自动拼装成Word。脚本不复杂，一个Python写的，跑一遍就生成完整文档，顺便检查交叉引用和符号一致性。虽然还是有人偷偷在Word里加批注，但至少主干内容是可控的。那段时间我天天盯着终端里的报错，恍惚觉得自己在修bug——不过话说回来，修教材的bug，比修机器人的bug难多了。机器人bug有日志，教材bug只有学生的一脸懵。

别把教材当代码，但可以借它的“骨架”

当然，我得泼盆冷水。教材联合开发不能完全照搬软件工程那一套。为什么？因为教材有教学逻辑，这玩意儿跟代码的执行逻辑两码事。代码讲究高内聚低耦合，教材讲究循序渐进、螺旋上升。你非要把一节内容拆成微服务，学生学起来就散了。

举个例子：讲“工业机器人TCP标定”，软件思维是拆成“四点法原理”“标定步骤”“误差分析”三个独立模块，每个模块一个作者。但教学思维是：先让学生看到一个标定失败的案例（痛点），再讲四点法为什么能解决（原理），然后动手做（实训），最后分析误差来源（反思）。这四步是串在一条情绪线上的，你拆给三个人写，风格和节奏根本对不上。学生读起来像看拼盘电影。

所以我的态度是：借工程化的“骨架”，但不丢教学的“血肉”。版本控制、接口定义、交叉审校，这些是骨架，必须有。但具体每一节怎么导入、怎么设问、怎么留白，得让懂教学的人统稿。我们的做法是：每个联合开发项目设一个“教学主编”，不负责写多少内容，只负责盯着整本书的学习路径——每章引入是不是自然、前后知识有没有断层、实训难度是不是跳得太快。这活儿企业工程师干不了，学校老师单干也容易陷进自己的学科逻辑里。得有个懂两边的人来回掰扯。

再说局限性。教材联合开发最怕什么？怕“为了联合而联合”。有的项目是上面压下来的指标：必须跟企业合作开发教材。结果企业派个行政人员挂名，内容还是学校老师自己写，最后封面上多印几个企业logo。这种联合，不如不联合。真正的联合开发，企业得真出案例、真给数据、真派工程师审稿。学校得真把课时留出来给新案例、真组织学生试用反馈。不然就是两张皮。

还有个坑：知识产权。教材里的企业案例，能不能公开？产线参数是不是涉密？我们有一次差点把某汽车厂的总装节拍数据写进去，被法务拦下来了。后来改成“某工序节拍时间约为XX秒”，模糊处理。这玩意儿必须在启动阶段就谈清楚，别等稿子都写完了再扯皮。

最后说句实在的，教材联合开发这事儿，别指望一版就完美。把它当成一个持续迭代的产品。印出来只是v1.0，每学期收集学生和老师的反馈，每学年出修订版。那些吵过的架、拍过的桌子、改过的公式版本，最后都会变成教材里一个不起眼的脚注：“本案例经XX企业工程师校核，特此致谢。”——这行字背后，是三天吵出来的。