回答这个问题之前，我们先统一两个术语的上下文：

在ThoughtWorks敏捷交付团队中，业务需求的载体是User Story（用户故事，极限编程中的一项实践，平时我们内部都简称为Story），AC是User Story的一部分。所谓AC，即是用户故事的验收标准的定义，验收什么？验证系统功能是否满足业务需求，并决定要不要接收该功能上线。

比如，用户登录的User Story，其中一个AC这么写的：

你开发的系统，用户使用正确的用户名和密码登录后，能成功登录，并且登录后能跳转到个人主页，则说明这个业务需求已经被满足了（我们也说这个AC通过了），表示客户可以验收这个功能了，否则表示功能未开发完。

所有的AC都满足后表示该User Story完成，可以准备进入QA测试环节了。

统一了这个术语后，再说点实际的。在ThoughtWorks，很多交付团队的BA（Business Analyst，业务分析师）在编写User Story的AC的时候会采用上述的Give When Then三段式去描述，当然也有不用这种格式（Free Style）的BA。不论其用什么形式去描述，作为一个合格的BA，她在定义User Story的AC的时候，一定是在定义用户不同的业务场景下行为结果。简单地说，就是对业务需求的场景拆分，优秀的BA可能更喜欢对拆分后的场景进行实例化。

比如上述的用户登录User Story，可能还会有其他两个AC（具体有几个，取决于真实的业务需求）：

当然还会配一些界面原型来告知开发人员错误信息显示的位置和样式（一图抵千言，可视化的效果）。

如果你碰到一个这样的BA，恭喜你，你很幸运，她已经将业务场景拆分得很细致，你只需要按照AC来来进行节奏的开发就好了。你对User Story进行Tasking的结果可能跟AC很类似。

但很多时候，你没有这么幸运，比如说BA定义AC的时候粒度较粗，或者描述AC格式五花八门，而你又不好意思或者因为客观限制没法时刻找到BA做澄清。这个时候你就可以对User Story进行Tasking，并将结果可视化出来，然后找BA和QA（QA有天然的极端边界视角）去确认你对需求细节的理解。这个确认过程可以带来如下好处：

所以这个时候你的Tasking结果可能会跟AC不一样了。会比AC更为细粒度，更有利于去做开发，更有利于定义完成的标准，减少没必要的返工。

总而言之，在敏捷交付团队中，针对User Story的Tasking和AC，宗旨都是对业务场景的细化和定义，带来的的价值是类似的，只不过说可能AC更多的是BA来定义。