第一步：用身份+工号+当前动作锁定执行人

提示词一开头，直接交代执行人的完整身份：“后端开发张伟（BE-087），正在Chrome调试窗口查看/pay/callback返回500错误，光标停在第12行console.log(‘res:’, res)处”。注意，千万不能简写成“张伟在查bug”——AI根本拿不到调试上下文，很可能给你生成“建议重启服务”这种脱离现场的通用废话。

必须带上工号、工具、光标位置三要素，缺一不可。而且工号必须真实存在，跟公司组织架构对得上。否则AI会默认这个人没有系统权限，不敢分配任何需要登录ERP或Jira的操作。

第二步：绑定接收人角色与协作断层

紧接着写接收方的状态：“测试同学李婷（FE-033），当前在Jira打开任务ID-TS-482，状态为‘等待后端联调’，她已上传3次复现视频但未获响应”。这句话不是背景补充，而是强制约束条件。AI一旦看到“已上传3次复现视频”，就会自动避开“请提供复现步骤”这种低效动作，转而生成“将第2段视频帧截图→在Jira评论区插入红框标注请求头缺失字段”这种可执行指令。

这里有两个落地方法：

方法一：用“阻塞关系”代替“协作关系”。直接写：“张伟不提交修复代码→李婷无法执行TS-482用例→上线排期推迟至6月28日”。AI会自动把“提交代码”设为最高优先级，并且附上Git commit message格式要求。

方法二：用物理权限缺口锚定动作边界。写清楚：“李婷无生产数据库查询权限，但需验证回调数据落库结果”。AI就不会傻乎乎地写出“登录DB查t_order_log”，而是生成“请张伟执行SELECT * FROM t_order_log WHERE order_no = ‘ORD-20260624-7781’ → 截图发送至钉钉群@李婷”。

第三步：嵌入人群行为习惯与失败痕迹

这一步是让任务落地到具体工作流的关键。需要做三件事：

① 插入一条最近发生的操作记录。比如：“张伟昨天14:32在飞书文档《支付模块V2.3》第5页用红色高亮标出‘幂等校验逻辑待补全’，但未添加评论说明。”② 补充他的典型行为模式：“他习惯在VS Code右键点击函数名→选择‘Go to Definition’跳转，而非用Ctrl+Click。”③ 加入一次翻车后果：“上一版因漏改Redis key前缀，导致沙箱环境缓存穿透，回滚耗时47分钟。”

这三句话放进去，AI生成的任务动作就会全部落在VS Code界面内，每个子任务都自带“修改key前缀为pay_v2_”这样的硬编码字段，而不是泛泛地说“优化缓存策略”。注意，漏掉“回滚耗时47分钟”这一句，AI就会忽略时间敏感性，可能分配一个需要2小时压测的动作给你，完全脱离实际节奏。