我理解的任务书，需要回答三个问题：要改变什么、哪些东西必须保留、拿什么判断结果。只有“优化一下”时，模型很容易替人补全目标；把范围写清楚，才方便发现双方理解上的差异。
验收条件应该对应可观察的结果。例如页面修改，可以写明需要检查的路由、视口和交互；内容整理，可以要求每个数字保留出处与统计范围。验收方法最好和任务一起确定，避免做完之后才讨论“完成”的含义。
我也会把验证分层看：本地构建通过说明能产出文件，浏览器检查说明特定页面能正常使用，线上核验才说明发布后的版本符合预期。这些证据可以互相补充，但需要分别记录。
官方 Skills 仓库把指令、脚本和参考资料组织成可重复使用的能力。我觉得任务书也有类似价值：留下清晰的约定，让后续执行和复核有同一个起点，而不是依赖模型记住一次长对话。