给代码写诗助手一份能验收的任务单

“帮我做得更有秋天的感觉”可以开启讨论却很难结束一次交付。模型不知道要保留哪些素材也不知道“更好看”到底对应什么检查。最后常常得到一份流畅提案和一堆没人敢覆盖的文件。我给轻量创作工具设计任务单时会先写可以观察的约束输入来自哪里允许改什么输出几份谁来判断完成。情绪词可以留在风格栏但不代替这些字段。比如把一段代码改写成短诗风格可以安静、简洁十四行、引用哪些源码、不得覆盖原文件则需要明确写出来。可携带的说明不等于执行权10 月 22 日AAIF 接纳了 Agent Skills、OpenResponses、OpenEnv 和 OpenSandbox。它们涉及不同层次的工作流与运行接口。这个进展值得关注但不能据此假设任何任务描述都自带安全隔离。Agent Skills 规范把name、description等信息放进SKILL.md并允许附带脚本与参考资料。对独立产品我会借鉴这种“说明与素材放在一起”的方式同时把真正的文件写入权限交给程序控制。文本里写了允许并不意味着操作系统已经限制了其他路径。下面把任务单作为普通 JSON 数据处理。检查器要求输入素材、输出目标、允许动作和验收项都存在随后只产生待确认摘要不直接运行提案里的命令。approved由调用方传入这只是演示流程字段不能用一个客户端布尔值代替生产环境的身份验证和授权。验收项要能说“不”“氛围温柔”适合人工评议“封面一张、标题一致、原文件保留”可以逐项核对。两者最好分开记录。模型说自己完成了不是证据程序生成了文件也不代表图片没有多余肢体、文字没有错字。一次真正的交付应把产物与检查结果一起交回来。运行node brief.js能验证缺项被拒绝以及未批准时只返回提案。本例没有访问文件系统、调用模型或生成图片。它的价值是把创意讨论变成一份可回看、可拒绝的约定。留出这一步才有机会把时间花在作品上而不是反复猜对方的意思。可独立运行的核心例子function validate(task) { for(const k of [inputs,outputs,allowedActions,acceptance]) { if(!Array.isArray(task[k]) || !task[k].length || task[k].some(xtypeof x!string || !x.trim())) throw Error(任务单缺少有效字段k); } if(!task.goal || typeof task.goal!string) throw Error(缺少目标); return task; } function prepare(task,approvedfalse) { validate(task); return { goal:task.goal, inputs:[...task.inputs], outputs:[...task.outputs], allowedActions:[...task.allowedActions], acceptance:[...task.acceptance], state:approved?已批准交给受限执行器:仅提案等待确认 }; } const task{ goal:把代码改写成十四行短诗, inputs:[用户提供且允许引用的代码片段], outputs:[poem-v1.md], allowedActions:[读取指定代码,写入新文件], acceptance:[恰好十四行,不覆盖源文件,人工复核代码含义与诗句] }; if(!prepare(task).state.includes(等待确认)) throw Error(不应默认执行); let rejectedfalse; try{prepare({...task,inputs:[]});}catch{rejectedtrue;} if(!rejected) throw Error(空输入应被拒绝); console.log(JSON.stringify(prepare(task),null,2));