编程协作 · 6 分钟阅读
给编程助手一份能执行的任务书
编程助手更适合接收有边界、可验收的小任务。先把现象、代码位置、约束和验证方式说清，才能让它产出可审查的改动建议；以下为教学示例，不代表代码已经通过测试。
描述可复现的现象
用“在什么页面/命令、输入什么、实际出现什么、期望出现什么”的顺序写问题。报错信息要原样附上并删除密钥、个人数据和无关日志；“页面不对”这类描述无法让人稳定复现。
明确代码边界和不能动的部分
给出相关文件、函数、接口或截图，并说明允许改动与禁止改动的范围。若你不知道位置，可先要求助手只做定位和解释，等确认影响范围后再请求代码改动。
把验收写成可以检查的结果
例如“空输入显示提示且不提交”“原有导出格式不变”“指定测试通过”。不要只写“修好”或“更优雅”；同时要求说明改动原因、风险和未运行的检查。
先审方案，再审差异与测试
对有影响的修改，先看它计划改哪些文件和为何这么改，再查看实际差异。运行与任务相关的检查，手动验证关键路径；失败时保留报错和复现条件，继续缩小问题而不是盲目重试。
复制一份任务模板
替换花括号中的内容，再交给你使用的 AI。不要粘贴未经授权的敏感信息。
你是协助分析和实现代码任务的助手。请先阅读任务边界，信息不足时提出问题；不要虚构仓库结构、接口、测试结果或已执行命令。
任务类型：{修复/功能/重构/解释}
现象与复现步骤：{页面或命令、输入、实际结果、期望结果}
相关文件/模块：{已知路径、函数或“不确定”}
错误信息：{已脱敏的原始报错或“无”}
允许改动范围：{文件、模块、行为}
禁止改动：{接口、依赖、样式、数据、其他限制}
验收标准：{可观察结果和应运行的检查}
先输出：1. 你理解的问题；2. 需要补充的信息；3. 最小改动计划及可能影响的文件；4. 验证计划。只有在信息足够时再给出实现建议或差异。完成后说明每项验收的证据、未运行的检查、已知风险，以及任何需要人工确认的兼容性或数据问题。下载文本模板 ↓