网上搜索也不是很明白工作流是什么，有高玩能简要说说你的应用场景么？

posted by wap, platform: Firefox

什么事牛顿贴？

http://club.tgfcer.com/thread-6776374-1-1.html

其实最直观的感受，就是启动mac os x里面内置的automator试试。

无论是生活还是工作，工作流的自动化的例子数不胜数。假设你要完成一个任务，中间包括若干个动作，你可以老老实实一步一步手动做，也可以利用工具尽可能减少手工劳动。

tg是游戏论坛，所以我举一个最简单的例子你就明白了：游戏外挂。外挂是用“作弊”的方式让电脑自动帮你完成游戏中的任务。

用同样的原理，你可以将工作流自动化用到正道上，比如你的本职工作。让电脑帮你自动完成工作任务。如果你的收入与项目挂钩，那么最实质的效果就是收入的增长；如果你是死工资，那么你至少可以多出更多的空闲时间干自己的事。

在mac os x，内置了无数自动化工具，有些是不需要编程的，比如Action Folder，就是说对于某个文件夹，你拷入一个文件时，系统会自动干某些事；Automator，最直观的工作流自动化工具；Applescript，脚本编程；Python和Perl，系统内置的通用编程语言。

Windows在这方面就不如Mac os x，但是可以用第三方开发工具。最常用的就是Autoit和Autohotkey之类免费自动化脚本软件。可以用office等软件内置的vba。可以下载python，perl，ruby等脚本语言。

还有mac，windows都能用的Sikuli，这是一种基于抓屏的视觉化脚本工具


工具实在太多了，关键根据具体需要选择合适的工具或工具组合。

[ 本帖最后由 kingcai 于 2013-8-12 09:34 编辑 ]

posted by wap, platform: Chrome

这得每天工作是模式化一成不变的才有用吧

alfred就有啊，简单的workflows

引用:

原帖由 小文 于 2013-8-12 09:29 发表
posted by wap, platform: Chrome

这得每天工作是模式化一成不变的才有用吧

不，对于我来说，每个大项目都会定制开发一套小工具。（我是搞建筑结构设计的）是否要自动化，要看投入产出比，假设一个项目本来要花两个月，开发了工具之后只要两周，那么就是开始花一周开发工具都是值得的。对于每一个项目，首先对工作流进行动作分解，然后用不同的工具将动作合并、简化、自动化，尽可能减少人的干预，但是又要让人能够检查结果。

我不大清楚其他行业的情况，但我认为很多繁琐的工作是可以自动化的。比如以前有个朋友在一家电路板设计公司工作，她每天的工作是从一堆表格里人工检查，找出有问题的元件。平时每天要花半天干这个工作，看到眼晕目眩。我花了一个周末帮她编了个vba程序，从此每天只要花几分钟运行一下程序，就自动生成一个有问题的元件列表。

牛顿贴里有人也说的不错，大部分人对自动化都没有需求或没有概念，甚至最有资源和能力实现这一点的程序员群体也是如此。我一个同学在nVidia当开发团队的管理人员，他经常向我吐槽这一点。

工作流自动化的重点不在于编程，而是在于你有没有这个概念，能否对工作流进行动作分解，灵活地运用多个工具自动化整个流程。

[ 本帖最后由 kingcai 于 2013-8-12 09:54 编辑 ]

posted by wap, platform: Chrome

自动化脚本吧

posted by wap, platform: iPhone

其实大家都在用的，发邮件时候cc就是workflow，邮件规则也属于workflow，在公司和家分别启动不同的一组程序切换不同的网络配置；上飞机了输两个字符自动关闭wifi，蓝牙，切到集成显卡，屏幕亮度调到六成；再比如拖拽一下把100个“tokyohot-n0xxx.一长串没用的.avi”自动改成“东热n0xxx.avi”；比如写科技博客的按一快捷键就截个屏自动缩图成一半儿大小上传到droplr得到网址传回clipboard，workflow既可大用也可小用，系统如果提供空间，能干的事儿太多了，有兴趣的可以玩玩alfred 2.0.x，相比自带automator更强大而且有太多现成的workflow，给你个不一样的mac

posted by wap, platform: Chrome

引用:

原帖由 @kingcai  于 2013-8-12 09:33 发表
不，对于我来说，每个大项目都会定制开发一套小工具。（我是搞建筑结构设计的）是否要自动化，要看投入产出比，假设一个项目本来要花两个月，开发了工具之后只要两周，那么就是开始花一周开发工具都是值得的。对于每一个项目，首先对工作流进行动作分解，然后用不同的工具将动作合并、简化、自动化，尽可能减少人的干预，但是又要让人能够检查结果。

我不大清楚其他行业的情况，但我认为很多繁琐的工作是可以自动化的。比如以前有个朋友在一家电路板设计公司工作，她每天的工作是从一堆表格里人工检查，找出有问题的元件。平时每天要花半天干这个工作，看到眼晕目眩。我花了一个周末帮她编了个vba程序，从此每天只要花几分钟运行一下程序，就自动生成一个有问题的元件列表。

牛顿贴里有人也说的不错，大部分人对自动化都没有需求或没有概念，甚至最有资源和能力实现这一点的程序员群体也是如此。我一个同学在nVidia当开发团队的管理人员，他经常向我吐槽这一点。

工作流自动化的重点不在于编程，而是在于你有没有这个概念，能否对工作流进行动作分解，灵活地运用多个工具自动化整个流程。

但我认为很多繁琐的工作是可以自动化的。比如以前有个朋友在一家电路板设计公司工作，她每天的工作是从一堆表格里人工检查，找出有问题的元件。平时每天要花半天干这个工作，看到眼晕目眩。我花了一个周末帮她编了个vba程序，从此每天只要花几分钟运行一下程序，就自动生成一个有问题的元件列表。

这不就是我说的每天工作模式化一成不变

引用:

原帖由 小文 于 2013-8-12 10:14 发表
posted by wap, platform: Chrome

但我认为很多繁琐的工作是可以自动化的。比如以前有个朋友在一家电路板设计公司工作，她每天的工作是从一堆表格里人工检查，找出有问题的元件。平时每天要花半天干这个工作，看到眼 ...

这就是通用工具（可以使用于每一个项目）和定制工具（可以应用于特定项目）的区别。两种工具都是需要的。通用工具显然是投入产出比最高的，不自动化没天理的。定制工具要计算投入产出比，看为特定项目开发是否合算。有时候甚至偶尔遇到、只会发生一次的任务，假设手工干需要1天，我估算编程需要1个小时，那么这也是合算的。

下面是ios上的app Drafts的开发者写的一篇文章When and why I automate：

« March 2013

When and why I automate

April 13th, 2013 at 10:56 pm by Dr. Drang

Way back in February, there was a Back to Work episode in which Merlin talked about how easy it is to waste time on “productivity”—spending more time on automating a task than you’ll ever get back on the savings that automation gives you. I was going to write a little post on that topic but work got in the way and then I forgot about it.

At the end of March, Clark Goble wrote a post on the same topic, complete with a funny graph taken from a now-lost recently resurrected post by Jason Verly. Clark made this point:

[G]eeks generally relax writing these sorts of things. I know probably half of my scripts were as much me relaxing and trying to clear my head from whatever I was working on at the time. That they make me much more efficient is just icing on the cake.

This was one of the points I had planned to make: For many of us, automating tasks is a form of recreation. A strict, green-eyeshade accounting of time spent doesn’t capture the value to us of writing a script. There was another point or two I wanted to make on the topic, but I was on spring break with my family at the time and wasn’t blogging. When we returned, I had some unexpected travel, which delayed my return to posting even further.

So now that the topic is cold and dead, I’m finally getting around to writing about it. This is why I’m not a link blogger.

There are five things I weigh when deciding whether to automate a task:

1. The potential time savings.
This is based on estimates of how often I think I’ll have to repeat the task, how long it takes to do manually, and how long it’ll take to write a script (or macro or Automator action or whatever). The stuff Merlin talked about.

2. The entertainment value of creating the automation.
For example, I’m currently beta testing an app that’s adding a sort of scripting language to an upcoming release. Learning the language by writing a few scripts in it was fun. I’ll certainly use the scripts I wrote, but I’ll never get back the time I put into them. That’s OK with me.

3. The annoyance I feel when doing a task manually that could be automated.
This is the flip side to the entertainment and relaxation value Clark talked about. I hate hate hate doing repetitive tasks when I know I could write a script to turn several steps into one. I know this is a personality defect that keeps me from being as efficient as I could be, and I try to keep it in check, but it’d be foolish to deny it exists.

4. The value of learning a new technique or library and keeping sharp with what I already know.
I write scripts to get my professional work done, and the more nonessential, recreational scripts I write, the more efficient I am at writing the scripts I need to get my job done.

5. The value it might provide to others.
I’ve learned so much from people who share their knowledge on the web, I feel compelled to reciprocate. This is, I confess, almost never my initial motivation, but it the reason I sometimes add a little extra polish to a script that’s already working.

Sharing scripts and scripting techniques also changes the accounting of time. A script that takes an hour to write but only saves me 15 minutes may seem like a waste, but if it saves three other people 15 minutes, too, the overall accounts are in balance. I’ll get my “lost” 45 minutes back when others share the scripts they’ve written.

[ 本帖最后由 kingcai 于 2013-8-12 10:37 编辑 ]

posted by wap, platform: iPhone

引用:

原帖由 @小文  于 2013-8-12 10:14 发表
posted by wap, platform: Chrome

但我认为很多繁琐的工作是可以自动化的。比如以前有个朋友在一家电路板设计公司工作，她每天的工作是从一堆表格里人工检查，找出有问题的元件。平时每天要花半天干这个工作，看到眼晕目眩。我花了一个周末帮她编了个vba程序，从此每天只要花几分钟运行一下程序，就自动生成一个有问题的元件列表。

这不就是我说的每天工作模式化一成不变

其实也没错，workflow就是把模式化的需要重复的步骤自动化来减少人的操作，但其实大家平时干的大多数事儿都是多步完成的，而计算机本身就是为了简化重复操作而生的，如果能提供足够强大的工具，怎么应用就只看用的人怎么想

学习了~

引用:

原帖由 wpang 于 2013-8-12 10:32 发表
posted by wap, platform: iPhone

其实也没错，workflow就是把模式化的需要重复的步骤自动化来减少人的操作，但其实大家平时干的大多数事儿都是多步完成的，而计算机本身就是为了简化重复操作而生的，如果能提供足够 ...

文版等人在那个帖子里一直强调ios适合小孩和老人使用，但问题在于不能要求人人一直顺从小孩和老人的使用方式。

一个好的系统或者软件应该极容易上手，又给用户留下进步的空间，以通用绘图软件autocad为例

1. 最初级的入门者可以点工具栏上的按钮或者输入简单的命令如Line，Move绘图
2. 再进一步，可以设置命令缩写，将命令使用的字母集中在键盘左半部，这样左手不用大幅移动就能输入所有常有命令，右手操作鼠标，这就是常说的”左键右鼠”
3. 使用autocad的动作录制器（Action Recorder），然后稍加编辑，就可以重复使用（无需写代码）
4. 使用autocad的参数化功能，创建模板
5. 利用类似于dos 批处理文件的autocad .scr脚本
6. 编写autolisp，vba脚本
7. 利用.net 等更强大的编程软件

也就是说autocad提供了不同层级的工具，供不同层次的用户使用。Mac os x也是类似，从鼠标操作、到alfred等工具、到automator、applescript、python、perl、xcode。

如果说一个刚出学校的人可以从按工具栏按钮开始，那么是可以接受的。如果工作了三年之后还保持这样的工作方式，还口口声声说”这样足够了“，”这样不容易出错“，还说自动化的需求是小众不合理的，这样的人可以容忍吗？

当然这个比喻可能不是很恰当，因为iphone毕竟大都是个人的设备，而不是员工为企业工作的工具。但是鉴于苹果已经在官网上吹嘘ipad的商用，那么对ios更开放的要求就是正当的了。

[ 本帖最后由 kingcai 于 2013-8-12 11:03 编辑 ]

引用:

原帖由 小文 于 2013-8-12 09:29 发表
posted by wap, platform: Chrome

这得每天工作是模式化一成不变的才有用吧

这几天的讨论也有好处，因为我正准备写一篇工作流自动化的介绍作为新人培训内容。我把帖子里的发言整理了一下，可以作为素材。

[ 本帖最后由 kingcai 于 2013-8-12 11:04 编辑 ]