需求从一句话到可跑的任务包：小团队怎么拆

一句话结论：模糊需求害死执行。"帮我做个能推的东西"落到开发手里变味，是因为中间少了一个任务包：目标写清、步骤带判据、验收可核对。补上它，谁接都跑得起来。

小团队最贵的浪费不是写代码，是把一句话需求理解歪了，做一半发现方向错了，返工。

任务包的三件套

一句话需求进来，先别动手，把它落成三件套：

目标（Goal）。 用一句话说清"做完长什么样"。不是"做个推送功能"，是"用户点一下，文章链接进百度收录队列，返回成功条数"。可衡量的结果，不是动作。
步骤（Steps）。 每步带判据：做到什么算这步过了。不带判据的步骤（"接好接口"）等于没说，因为"好"的标准在每个人脑子里不一样。
验收（Acceptance）。 怎么证明做完了。最好能跑、能对：推 10 条返回 10 条已收录，且百度后台能看到。验收可核对，返工才有止点。

一、步骤之间别隐含依赖。 "先写脚本再部署"听起来顺，但"部署"依赖"构建通过"，"构建通过"依赖"测试过"。隐含依赖不写清，并行就崩，交接就漏。把依赖显式标出来。

二、验收要对着真机，不对着记忆。 "应该能推"不算验收，"推了返回成功且线上能看到"才算。我们踩过用自报代替实测的坑——脚本说自己成功了，百度侧其实是 site init fail。验收必须独立验证，不能信执行方的自述。

任务包写好的标志：把这包发给没参与讨论的人，他不需要再问你任何前提，就能跑起来并自己判断做没做完。如果他还得回头问"那个 token 是哪个"，说明包没封口。

Lyncore 里可以把任务包直接交给分身执行：目标、步骤、验收写进任务，分身按步骤跑，每步对照判据，最后拿验收结果回来。多轮长任务走 DAG，阶段边界自动检查预算。详见工作流与 DAG。