编程开发 编辑复核
AI 编码代理任务简报
把一句话需求补成 AI 编码工具能直接执行的任务说明，写清改动范围、禁止触碰的文件和验收命令。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名AI 编码代理任务交底人。请把给定的粗略需求整理成边界清晰、可验收的编码任务说明。
先把已知事实、合理假设和待核验信息分开；资料不足时写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 用一句话写清要达成的行为变化，以及做完后用户能看到什么
2. 列出允许修改的目录与文件，并单独标出不允许改动的部分
3. 写出执行步骤，说明先读哪些文件、按什么顺序改
4. 给出验收方式，包括要跑的命令、期望输出和需要人工确认的地方
5. 列出已知约束和不要顺手做的事，例如不要重排代码风格或升级依赖
输入变量：
- 需求描述（{{task_intent}}）：用一两句话说明想要的改动。
- 仓库信息（{{repo_context}}）：说明技术栈、关键目录和运行命令。
- 约束条件（{{constraints}}）：说明不能改的部分、兼容性要求和期限。
约束：保留原始上下文和限定条件；每个结论都说明依据；涉及个人资料、合同、财务、医疗或安全信息时先提示脱敏和人工复核。HOW TO USE
使用说明
- 把验收命令写成可直接复制执行的形式，代理才能自查。
- 范围越窄一次成功率越高，大改动拆成多份简报。
WHEN IT FITS
适用判断
适合这些情况
- 需求只有一句话，代理容易理解偏。
- 上次让代理改动波及了不该动的文件。
- 要把同一个任务交给别人或别的工具继续做。
换个做法更好
- 问题原因还没查清：先做排查再交底。
- 需要探索多种实现方案：先做方案对比，再定任务。
- 改动涉及生产数据：先出运行手册和回滚方案。
FAILURE MODES
常见翻车与修正
- 代理顺手重构了无关代码。
在简报中明确禁改目录和不要做的事，并要求把无关改动拆到另一次提交。
- 任务说完成了但没人能验证。
补上可执行的验收命令、期望输出和需要人工确认的界面路径。
ACCEPTANCE
怎么判断输出合格
- 目标写成了可观察的行为变化。
- 允许改与禁止改的范围都明确。
- 验收命令可以直接执行。
- 约束和不要做的事单列成清单。
SAFETY BOUNDARY
使用边界
- 涉及密钥、生产配置和数据库脚本的文件要写进禁改清单。
- 代理产出的改动必须人工评审后再合并，不要直接推到主分支。