一句话需求到能开工，中间缺的八样东西
"帮我做一套新品推广。"
这句话在过去是能开工的。交给一个熟练的运营，他会回来问你几个问题，然后自己补齐剩下的部分，一周之后交出一套东西。做出来的结果大概率可用，因为他在过程中用自己的经验填了那些你没说的地方。
同一句话交给系统，会卡在拆解那一步。不是系统不够聪明，是它没有那份经验可以用来填。
过去需求说得不清楚还能做成，是因为有人在替你补。补的成本一直存在，只是藏在执行环节里，账上看不见。
三道转译
需求从人嘴里到能执行，要过三道。
第一道，从客户的语言转到业务语言。客户说"要显得专业"，业务语言里对应的是"用词避免口语化、数据要标来源、避免绝对化表述"。
第二道，从业务语言转到可执行定义。上面那三条要落成对产出的具体约束，比如"每个数据点必须有出处，无出处的改写为定性描述"。
第三道，从可执行定义转到任务。这最后一段是系统能做的部分，它需要前两道的产物已经清楚。
前两道过去由人做，现在也必须由人做。 系统能做的是第三道，而第三道的质量完全取决于前两道的输出。
失真的三种形态
转译过程中的缺失大致三种。
第一种是抽象层级错位。需求停留在高层，而执行需要底层。"要专业"是高层，"避免口语化"是底层，两者之间没有对应关系。这种失真的表现是执行方给出一个自己不认可的结果，问他哪里不对又说不清。
第二种是隐含前提缺失。有些事你觉得不用说，因为它在你这里是常识。"做推广"隐含了不能使用客户的真实数据，隐含了不能承诺效果，隐含了不能用某个竞品的名字。这些前提如果没有写出来，机器不会自动知道。
第三种是边界未定义。没写清"做到什么程度算完成"，执行方只能自己定一个。它定的那一个通常比你想的小，因为保守是最安全的选择。
三种失真的共同点是：它们都不表现为错误，而表现为"结果不对但说不出哪里不对"。
八类要补齐的参数
用那句"帮我做一套新品推广"做例子，看它开工之前需要补齐什么。
| 类别 | 需要指明的内容 |
|---|---|
| 交付物形态 | 图文、视频、页面、方案，各多少件 |
| 渠道 | 发到哪些平台，自有还是合作 |
| 目标人群 | 谁看，什么场景下看 |
| 素材来源 | 图片、视频、产品资料从哪来 |
| 事实来源 | 卖点、参数、价格以哪份文件为准 |
| 禁用清单 | 不能出现的词、不能提的对手、不能承诺的话 |
| 验收标准 | 什么情况下算通过 |
| 时点 | 什么时候要，和哪个节点绑定 |
八类里，任何一类缺失都会在执行过程中变成一次返工。缺两类以上，返工就不再是修补，而是重做。
这八类并不都需要写得详细。 它们的详细程度应该跟任务的风险挂钩。发在自有账号的一篇日常内容，验收标准可以写"负责人看过即可"；一次对外投放，验收标准必须能落到具体数字。
一个反过来的算法
还有一件事值得算：需求补齐的成本，比返工低多少。
假设一次批量内容生产的单件成本是 30 分钟。八类参数里缺了"事实来源"这一项。执行方做到一半发现卖点没有依据，停下等资料。等资料的过程不影响已完成的件，但需要重新组织上下文，这部分成本按单件 10 分钟算。
如果这一批是 20 件，返工成本是 200 分钟。而在开工前补齐这一项，需要的时间是去要一份文件，大概 5 到 10 分钟。
差了两个数量级。
这个比例的意思不是"每次都写全"，而是：在投入开始之前补齐参数，是整件事里性价比最高的一段工作。 它花的时间以分钟计，省下的时间以小时计。
为什么这件事过去不显得重要
上面说的这些，过去也都有，只是没有人把它当作一项独立工作。
原因是人在链条里充当了缓冲。执行的人收到一句模糊需求，会做三件事：根据经验猜一部分，遇到不确定的当场问一部分，剩下的一部分按最保守的方式处理。
这三件事成本都不低，但它们分散在几周的执行过程里，分散在不同人的日常里，所以在账上不显形。
执行交给机器之后，这个缓冲层没了。机器不会猜，不会当场问，也不会自己选保守方案（它可以被配置成保守，但那需要你事先说明）。
于是同一笔成本突然集中暴露出来，暴露的位置还很不巧：它出现在交付的时候。
这时候的归因通常是"AI 做的东西不对"。真实原因是需求转译的成本从执行过程里被挤到了开头，而没人处理开头那一段。
一个可以立刻用的模板
把上面八类做成一份填空，每次开新任务时先填。
前半段四类属于"要什么"：交付形态、渠道、人群、时点。
后半段四类属于"有什么约束"：素材、事实来源、禁用、验收。
填的时候有一条规则有用：凡是你能想到"到时候再说"，都写下来。 那些"到时候再说"的事项，就是隐含前提所在的地方。
什么情况下不该先补齐
有一种情况把需求写全是浪费：任务本身还在探索阶段。
比如你想试一个新内容方向，你自己也不知道该做成什么样。这时候写八类参数是在假装自己知道。正确的做法是先做一两个小样本，看结果，再决定要不要把它变成正式任务。
区分的方法是问一句：我现在能不能描述出合格产出长什么样。 能描述，写参数；描述不出来，先做样本。
另一种浪费是把参数写到执行方已经不看的程度。一份二十页的需求文档，实际被使用的部分可能只有两页。参数的详细程度应该以"执行方不再回来问"为标准，超过这个标准的部分是自娱。
这件事会拉开的差距
把上面这些放在一起，会得到一个关于能力差距的判断。
工具的普及会让需求转译能力的差异被放大，因为它作用在一整条链条的最上游。
一个能写清需求的团队，和系统配合之后，产出质量稳定、返工少、扩产容易。一个需求靠默契运行的团队，工具用得越多，暴露出来的问题越多，最后往往得出"这套东西不适合我们"的结论。
而这两类团队在工具出现之前，产出差距可能不大。因为第一类团队的优势一直被"执行里有人补齐"这件事掩盖着。
所以当有人问"AI 落地最重要的是什么"的时候，一个可以回答的角度是：先看这个团队能不能把想要的东西说清楚。 这个能力过去被低估，现在它变成了前置条件。
常见问题
问：让 AI 自己追问不行吗？
可以，而且有用。让系统在拆解之前把不确定的点列出来问你，能挡掉一部分缺失。但它只能问出"它自己意识到不确定"的地方，问不出你认为是常识因而没说的地方。隐含前提这一类，只有你自己能发现。
问：八类参数每次都写，会不会太重？
按风险分级。日常内容写四项就够，涉及对外投放和金额的把八项写全。判断依据是这个任务做错了能不能撤回：能撤回的少写，不能撤回的写全。
问：小团队没有人专门写需求，怎么办？
不需要专人，需要的是在开工前留出十分钟。这十分钟做的事是把脑子里的默认假设写下来。它不需要文档格式，一张清单就够。
相关阅读
延伸阅读：你缺的不是更多 AI 工具，而是一支 AI 团队、本地生活服务AI方案：老板最缺的不是流量，是有人把杂事做完、内容发了没人接：从曝光到询盘，中间缺的那一环。
三条交付线的额度与价格在定价页，基础版免费，可以先跑一次看结果。