来源:创意之代码（CodeOfCreation）
![]()
代码，
是一个俱乐部的入场券。
是一个圈子的投名状。
代码，
是一扇门。
门里门外是两个几乎不重叠的世界。
-------------- 目录 --------------
1. 写代码的艺术生们
2. 从 Industrial Design 到 Industrialized Design
3. 写代码有多难？
4. 写代码干嘛用？
5. 怎么开始？
6. 何时功满？
7. 也有遗憾
--------------------------------------
![]()
1. 写代码的艺术生们
这是个应景话题，今年的硕士招生季还没结束。一志愿已如愿的人可以松口气了，尚在拼杀调剂名额的学子们还来不及多想未来课题的选择问题，但对报考的导师倒是都有点研究。一些联系我的考生显然做了不少功课，对我的研究方向之熟悉让我怀疑他比我本人还了解我的研究。
很多老师和学生想当然的以为我喜欢招有计算机背景的硕士……他们是对的。不过有基础当然好，没有也没啥，进来学也来得及。我自己就是半路出家跑来学工业设计的，不会歧视同路人。
回顾一下这几年带过的硕士论文，有近20部了，80%涉及到写代码，其中有计算机背景的学生只有1人。论文选题五花八门啥都有。虽然有在研纵向项目，但是我的硕士生直接做纵向的并不多。他们做的更多是前瞻性的预研课题，带有一定的探索性。有的是为了下一个项目申报做准备积累研究基础，有的则是仅仅觉得好玩而已——是我觉得好玩，学生们自己觉得好玩的研究很多其实只是无聊而已，做硕士选题并不合适。
我带的硕士生大部分没有读博的打算，所以给他们安排课题也要考虑一下他们学到的技能和经验在工作中有多大可能用得上。即使是基金类的课题，大部分也都是有很强的应用背景，我把基金课题“包装”成进阶类型的应用设计项目让他们做。纯粹的理论或技术研究课题很少。
我招来的硕士生不能全都算艺术生，也有很多工科工业设计的。国内的工业设计专业虽然位列在08机械门类下的子学科，其培养模式与艺术生其实差别不大。有些学校的工业设计专业在大一时开设了编程基础课（以VB为主），但等到要用时基本已忘光，实践经验几近于零。且工业设计课题研究的编程多数与图形学有关，非计算机类专业即使学过编程课，也难有机会接触图形学（貌似计算机本科生精通图形学的也不多）。
总而言之，艺术类的硕士生会写代码的确实少。原因是什么呢？是艺术生不善于写代码吗？这就变成了一个先有蛋还是先有鸡的问题。答案是no，这个答案是我自己发现的。可能的原因有三个：一是没人教；二是没人逼；三是自己没找到需求——有无数种不用写代码也能拿到学位的论文做法，何苦啃这块硬骨头呢。
我的硕士生们都在写代码。
一个选过我的课的学生（不是我的硕士生），现已在芝加哥定居，有次忽然在QQ上对我说：老刘，在学校那段时间只有在你的课上我还学了点东西。这让我觉得，这条路好像是对的。
![]()
2. 从Industrial Design 到 Industrialized Design
我有点迷信规律性的东西和自动化手段——从纷繁芜杂的艺术世界中缕出一个清晰的脉络是我感兴趣的事情。可能这与我的工科教育背景有关，但实际上艺术生或文科生更偏爱这种能诠释世间万物的普适性解释框架——在领域间搞乾坤大挪移、基于一个逻辑上可疑的类比关系就开山立派的人比比皆是，他们发现了放之四海而皆准的宇宙真理，并写出了各种各样的神棍书。
反倒是有点研究经历的工科生秉承了一事一议的老实态度，因为要弄明白一个理论框架或技术方法管不管用，证伪太容易了。几乎所有的工科研究成就都是在推翻前人成果的基础上获得的，推翻别人和吹嘘自己都要给出证据，有这么一个带着强烈证据意识的基本套路摆在那儿，有点脑子的人都不好意思胡来。
作为一个半路出家的人，要从经验和技能上赶超正规设计师恐怕要付出额外的努力，所以当初我读工业设计博士的计划不是要去PK设计师，而是去“外化”他们的经验，利用技术“复制”他们的技能。
这个计划即使现在看也是野心太大，但是几年的鲁莽尝试和一些局部点上的突破还是有收获的。这里的关键是：任何技术都不是普适的，都是有选择和针对性的——这跟搭建大一统的解释框架大不一样：啥都能解释的理论一定是废话；找到“正确的对象”比找到“正确的方法”更重要。
因此我采用了一种偷懒的做法：不找人多的地方扎堆，不跟人比，不做别人做过的事，找人少的地方平地开挖，玩够了就换个地方再挖。
“寻找规律”这种事其实是在为设计的工业化做准备——产品制造可以工业化，产品设计也可以工业化。设计领域的技术研究一直都在推进这个工业化进程，只是尚处于各自为战的状态没有形成统一概念而已，局部的突破则比比皆是。曾有人问，机器代替人搞设计了，那人怎么办？我的回答是，能被机器代替的多数都是复杂耗时的工作，人不是正好可以腾出时间来做更有创意的事情么？
这也是一种激励，技术给了我们一个更高的平台，我们就应该思考在这个平台上能做什么以前做不了的事，而不是去跟这个平台竞争。
这也是为何我们的技术研究全部选择已有CAD平台进行二次开发。平台的崛起拉高了传统设计师的沉没成本，成就越高的设计师付出的沉没成本也就越高。这种情景也给新晋设计师（或根本就不是设计师只是发烧友的人）制造了大量机会，因为他们的起点就不在同一起跑线上。
技术发展的长河从来都不是等速前移的，后浪追前浪才是常态。
![]()
3. 写代码有多难？
从不时传来的“XX小学开设C++课”、“少儿编程培训班招生”的新闻来看，写代码不见得比弹钢琴难。
写代码归根到底是一种技能而已，跟绘画、建模差不多。区别在于这项技能的评价标准太清晰直白了——画画即使画的不好也对付着能看，建模即使水平不高也大致能把设计意图表达清楚；但是程序不通就啥产出都没有，中间的灰色地带几乎不存在。很多艺术生不喜欢这种清晰的东西。
这种情况跟艺术生们习惯的创意评价方式有差异。所以真正的困难可能不是编程有多难，而是是否能够（或者愿意）习惯这种工作模式，即“精确”到家的评价方式。
如果仅从“难度”的角度来看，有两个现象值得注意：一是“外高内低”的门槛；二是数学和逻辑的区别。
写代码“外高内低”的门槛其实是初学者自己给自己设置的障碍，但确实有一定的普遍性。程序代码、电子电路等技术学科不像机械、绘画、建模等，可以通过感官和知觉直接产生一定的认识和经验，没有“野路子”可走。你必须看教程学习，或者有人带你入门。这个学科的门槛在常识可及的范畴之外。
而一旦入了门，就会觉得不过尔尔，回头看看那个高不可攀的门槛，其实很低。掌握了基础技术能自学了，后面就可以一路狂奔了。与之相比的是机械，入门前觉得真是没啥，几块铁家伙啥秘密也藏不住（不像电芯片），学了几天才发现里面都是坑，连天天用的雨伞和自行车都变得神秘莫测搞不懂了。
写代码门槛“外高”的一个体现就是，艺术生们不约而同地都认为写代码需要精深的数学知识。看起来，数学是所有文科生的噩梦，以至于觉得所有最困难的事情都跟数学有关。
这是一个很典型的误解。这个误解有两方面的解释：
一是数学可能确实理解起来困难，但不等于操作起来也困难。可以说，绝大多数能用公式表达的数学写成代码都不困难，即使你并不理解这些公式。因为良好的形式是写代码的基础，而数学恰好是形式最严谨规范的语言。
二是真正困难的在于逻辑，这点被很多人忽视甚至轻视。比如各种类型的智能算法，基本都不存在艰深的数学内容，但是里面复杂的逻辑关系比有公式表达的数学更难把握。就设计学的编程而言，数学内容基本没有超过中学水平，唯一例外的可能就是图形学了。但多数CAD平台都有完善的图形学函数库，基本不用自己去写算法。所以艺术生们编程所需的数学知识只有高中甚至初中水平。
除此之外就是十几条语法指令和一系列的类库与函数库（相当于已经编好的各种插件），知道如何查帮助看懂示例代码然后组合应用即可。
我很荣幸的不是学计算机出身而又学会了写代码的人，既当过学生也当过老师，既在门外徘徊过也在门内端坐过。同样我也不是学艺术和设计出身的人，同样也是既当过学生也当过老师。艺术生们学编程的种种心态和忧虑我都有数。
尽管如此，刚开始带硕士的时候我还是很谨慎的。我给他们的大论文选题都是确保我自己可以一周内搞定的东西，以防万一。事实证明我多虑了，这批千军万马闯过独木桥的人比我想象的要能干，他们只需要一些鞭策而已。后面我也曾放手让学生们去学一些我自己不会并且身边也没人会的东西，结果还不错。
![]()
4. 写代码干嘛用？
代码是一个俱乐部的入场券，是一个圈子的投名状。或者说，代码是一扇门，门里门外是两个几乎不重叠的世界。
若干年前我浏览MIT媒体实验室的网站，看到他们招收博士生的入门条件，其中有一条是：必须会使用一种编程语言，种类不限。这大概就是“门槛”的意义了——你要确保自己是圈里人，否则玩不转那些眼花缭乱的创意。
用途1：自用
作为一个半路出家的人，“自用”其实是我自己写代码的一个基本目标。从我做硕士论文开始自学编程（导师不会）以来，这一直是我从事过的各种开发工作出发点。
“自用”可以确保不会去搞一些伪研究。说实话，艺术和设计类硕士课题中的伪研究实在太多了，一些研究课题忙得热火朝天煞有介事，结果最终的研究结论连自己都不信，研究成果自己都不想用。那搞出来的东西还怎么可能有价值呢？
作为一个开发者，应该有勇气做自己的开发成果的第一个用户，而且是最忠实的用户。国外有些创意发烧友非常令人敬佩，他们的创意走到极致，软件已不能满足要求，于是就开始自己编写插件拓展软件功能。十多年前我上过一个3DMAX的国外论坛，里面有几千个免费插件供下载，全部都是发烧友们自己开发的。
国内的设计高手和创意高手们能修炼到发烧级别自己开发工具的还真是不多，“写代码是程序员的事”、“学数学工科生的事”这种固执的思想阻碍了很多高手进入一个更高的境界，令其过早触到了自己的天花板——而不是触到软件工具的天花板。
用途2：原型机
写代码的设计师跟程序员还是有区别的。大部分程序员的工作其实类似工程开发项目，在给定的任务需求框架下写程序，满足功能的同时确保可用性、交互性能、效率、控制bug等。面向的用户有可能是大批量的用户群体，也可能是特定企业的使用人员，总之不是自己。
设计师写代码更多的是为了测试、验证或论证自己的创意概念的可行性，找到问题并解决之，自己是主要的（也可能是唯一的）用户。商业化软件产品的开发暂时还不是设计师的主要任务。
因此，设计师写的程序实际上是“原型机”的角色，即先确保这个概念works，下一步才是“好用”，即可用性、交互性能、效率等。如果真的能有“下一步”，很多情况下就是商业化开发了，这时要考虑的因素就多起来了，外部投资也要进入了。原型机就扮演了一个交流与评估项目的重要角色。
应该说，设计师想做到程序员的水平有困难，我自己也做不到。这不是能力高低的问题，而是一个资源投入和角色分工的选择。
分工一般是产业链下游的事，越往上游分工越难，创意阶段的工作则基本都是个人主导——你自己的创意找个程序员帮你实现？有钱之前很难。即使真的这么做了，面对成果的主导权设计师也是处于劣势。所以天使投资人对那些“只差一个程序员”的创业者说“滚”是有道理的。
用途3：工具
这里“工具”的含义是，在你完成任务的过程中能助你一臂之力的东西。在这个背景下，对工具的掌握水平不是看你“会做”什么，而是看你“做过”什么。任务才是第一位的，工具始终是次要角色。
我曾经在五个大学待过，所在的学科包括机械、计算机、艺术、设计。应该说，我对各类学科背景的学生的思维模式和之间的差异还比较有数。计算机和设计学生的做事风格区别很大，即使是面对同样的任务。
设计人面对学科以外的技能，要把握的一个基本原则是——不择手段。
我刚读博士时遇到需要用C++的开发任务，我做的第一件事就是去书店买书，买跟任务类似的、书后附有源代码光盘的书。代码直接拷贝过来用，我都懒得去看懂作者的代码是怎么写的。
我博士后期间接到一个平面CAD开发的任务，项目没指定用什么平台、做成exe还是插件或网络版，总之是探索性的。那时我对平面CAD一无所知，比较了几款软件最后选择了CDR，因其可以直接录代码，能确保第一周学会，第二周开工。
我做硕士论文的情况也类似，导师给了我一个项目（毕业后才知道我独自搞定了一个国家博士点专项基金项目），但是导师不懂计算机，他只跟我要任务成果。我最后选择了Turbo C作为开发工具，不是因为它高大上和功能强大，而是因为隔壁有个师兄刚好熟悉Turbo C，可以随时请教。
那是我第一次接触编程（大学上过课但没实战过），后来发现有了基础（不管什么语言）再学其他类似的开发工具会省力很多。所以MIT媒体实验室的入门要求是非常合理的。但是这个“基础”最好是某个完整的实战任务，只会语法意义不大。所以我带的好几个硕士生都是高速公路学驾驶，基础过关后立即实弹演习。
用途4：推与拉
创新是艺术和设计都避不开的话题，尤其是硕士课题研究。从来源上看，创新可以分为两种：一种是需求（或问题）推动的创新；另一种是概念或技术拉动的创新。说得再直白一点，前者是有市场找产品，后者是有产品找市场。
技术驱动的创新属于后者，这是艺术生学编程的回报之一。但是这里的“技术”跟通俗语境下的“技术驱动”还有点区别：这个技术不是嵌入或固化在产品中的技术（如传感器、智能芯片等），而是设计过程中使用的技术，产品投产后这种技术的角色就退出了。
一项技术总能找到用途，因为创新的世界太大了。门里门外的两个世界很多领域不重叠，设计师和艺术家们更熟悉门外的世界，但门内另有一番天地。
构想创意和选择研究课题（包括申报项目选题、硕士论文选题等）这种事，跟写代码一样，纯靠想象力是不够用的。创意虽然带有很大的随机性和跳跃性，但并不像很多人想当然认为的那样“有个脑子就行”。
工科“隔行如隔山”的困境有点像挖坑，在坑里看不到坑外什么情况，也看不到隔壁的坑有多远。而设计和艺术的研究更像爬树，爬的越高能看到的范围就越大，能找到的可供扎根的空地就越多。
文科研究、艺术和一般意义上的创意皆如此，想象力的驰骋范围就如航母的舰载机，能飞多远要看航母开到哪，而不全取决于飞机的油箱有多大。
![]()
5. 怎么开始？
每个人都有自己最佳的上手方法，不一定都一样，自己觉得合适就好。下面几条是我的方法，仅供参考。
1）从二次开发入手
二次开发是在已有软件基础上定制自己的功能，也就做插件了。几乎所有的CAD平台都提供了二次开发接口，如Rhino的VBScript和Grasshopper，CorelDraw的VBA和Pascal，AI的VBS和AppleScript，Solidworks的API和VBA等。我的博士论文是在Unigraphics上用OpenGrip做的。二次开发的意义就是前面提到的“技术平台”，设计师们要学会爬到最高的山岗上去够月亮，不要浪费时间做重复开发。
2）尽量用VBA
对于没有编程基础的学生而言，我推荐从VBA开始。首先是VBA是Office的开发工具，许多CAD软件都支持VBA，通用性好，即使找不到对口的教程，看看Office VBA教程也基本能学会。我的学生用CorelDrawVBA，没有合适的教程，我都是让他们去找一本Excel VBA先入门。其次是VBA可以录代码，就像打开录音机，屏幕上的所有操作都可以在后台记录成程序代码，这对学习编程和熟悉函数库是个巨大的帮助。
3）Hello world！
第一堂课编写一个可以弹出的对话框，或完成一个简单的定制设计任务，而不是枯燥的变量类型。大部分学生并不知道“用了四年的CAD软件还能这么玩”，兴趣和信心几乎立刻就来了。
4）学会使用帮助
帮助文档永远是最好的老师，我就是一路看帮助走来的。当然，部分原因也是有些二次开发工具根本就找不到教程。我买过很多书，但我家里几乎没有编程的书，有帮助文档就够了。提高编程技能不是我努力的方向。大部分帮助文档里有完整的示例代码，直接拷贝就能运行。有些常用的功能可以从网上搜索到，一些算法则可以到文献中去找，有了基本的编程技能就可以对着流程图和伪代码把程序编出来。
5）完整案例：编写一个简单的
从头到尾编写一个完整的案例，体验一下整个开发流程。这种案例最常见的是参数化设计，用录代码功能记录下来全部手工操作过程，然后把里面的数字替换成自定义的变量，最后做个界面让用户输入变量值产生定制图形。这类案例虽然简单，却可以把非常复杂的设计过程整理成插件，成就感还是不小的。
6）完整案例：学会修改复杂的
这是另一种意义上的“平台”概念，即在前辈成果的基础上继续前进。编程跟做设计有点不一样的地方是，并不强调“原创性”——只要能搞到源代码，所有东西都是你的。源代码能看懂并利用起来完成自己所需的功能是第一要义。我写过的一些程序80%以上都是别处拆下来的旧模块组合成的，需要新写的代码只占一小部分。所以多做类似的开发工作，效率会越来越高，因为可重用的代码模块越来越多。很多关键代码的编写工作是一劳永逸的。软件开发的这个特点会让人十分喜爱。
![]()
6. 何时功满？
理论上学无止境，实际上能摆脱老师自学即可。老师的价值也就是带进门槛而已。写代码的能力对设计人是一种奢侈品，没有它你也可以混的很好，有了也不一定更好，但是会给你更多选择的自由。
关于需求：需求都是找来的，不是自己撞上门的。有了写代码的能力可以让你找到更多的需求——很遗憾，大部分人（包括以创意为生的设计师）的想象力并不如自己所想的那样自由，插上翅膀也飞不远，确实需要技术工具来帮助展开想象力。
关于成果：写代码的设计人跟程序员的成果用户对象不同，商业化模式也不同。设计人的科研成果还是倾向于搭建一个平台（软件），可以辅助（自己）完成某一风格的设计，或者开展某一类型的实验工作，持续产出设计或研究成果。而这个平台如果本身变成了商品，那就有点像程序员的工作了。
比如，我和我的学生们做过一些免费的共享插件，做了一些旁门左道的功能。这些功能对设计师有些价值，可能有些人还会觉得“很有价值”，但是也就是一年用一两次，能指望他们花钱买吗？这个现象决定了我们走商用软件的路子是走不通的，但另一方面也决定了商用平台软件不是我们的竞争对手而是帮手（其实它们做这类工作更有优势）。设计人写代码的商业模式是完全不同的，这是个很好的讨论话题。
如果把“写程序”放大为一种开发活动或创新设计活动，就会发现其实它和设计师们熟悉的产品开发还是挺相似的，这里面有些本质性的东西按照“惯例”被设计师们忽略了，比如开发过程中最困难的和最重要的因素。
指导硕士的实践表明，写程序本身并不是最困难的，反而是思路的形成和实施规划过程更容易出问题，这三者的难度依次升级。最后形成的软件成果的可用性问题也很多——即使原型系统也有可用性问题，即使没有bug也不好用，其中开发平台原因只是一小部分。但我暂时还不会分出很多精力来关注可用性，因为可用永远是第二位的，能用才是最重要的；如果只有你一家在用，可用性就不是核心问题了。
艺术生们在做设计的过程中有两种比较普遍的心态：一是完全不考虑操作，画饼为主；二是全程被操作性细节烦扰。后者在编程学习的过程中体现得更到位。我判断工作难度时，一个项目有六七成把握就可以接单，因为我知道剩下的三四成肯定有解决方案，只需花点时间找出来。初学者则很容易被一些操作性细节绊倒，影响全局进程，他们需要100%的确定和肯定才会有勇气走下一步。这是个经验的问题，多练练手自信心就会慢慢丰满起来，对工作的预判也就会越来越准确。
艺术生们学会了编程，有时也会变得自信心爆棚……嗯，多受点打击也不是坏事。
![]()
7. 也有遗憾
如果让我客观的评价一下这几年带艺术生写代码的教学成果，我会给个70分。
我对学生说“编程很容易”的时候，多半是鼓励他们。编程不能说非常容易，但也并不比其他硕士课程难。有一点明显的优势就是成果的累积性和可重用性，这点连智能硬件都做不到（有学生反映编程比智能硬件要难一些）。可是并非所有的学生都能认识到这点并把它用好。
学生们做的东西当然有很多槽点，其中最大的遗憾是没能把一个像样的概念做到极致。执行力需要磨练是一方面原因，但更大的问题并不是编程技能，而是对成果的渴望度不足，不愿费脑子多想怎样把自己的东西再往前推一步。我觉得他们可能并不十分热衷于充当自己成果的用户。现在还时不时回想起国外设计学院的学生们那种活力四射的样子，真是令人羡慕。
其实我的学生绝大部分还是非常听话的……听话得像个程序——没有input就没有output，让我无法判断这个程序在想什么。
![]()
![]()
![]()
