Devin AI提示词编写核心原则：清晰标准与任务拆解详解

要用Devin AI完成真实开发任务，必须明确“做什么、做到什么程度、在哪种约束下做”：①用具体动词+可验证结果定义目标；②提供精准上下文（文件片段、技术栈、已有机制）；③强制拆解为编号执行序列；④绑定可操作的验证方式。

要用Devin AI完成真实开发任务，必须让它准确理解“做什么、做到什么程度、在哪种约束下做”，否则它会自行补全逻辑，产出偏离预期的代码或方案。

明确任务边界：用具体动词+可验证结果定义目标

第一步：把模糊需求转成一句完整主谓宾句子，主语是Devin，谓语是动作动词，宾语是交付物。例如不要写“优化登录流程”，而要写“为Web应用登录页添加邮箱格式实时校验，并在输入错误时显示红色提示文案”。

第二步：在句末追加可验证的验收标准。比如“用户输入‘test@’后立即触发提示，且不提交表单”——这句不是描述功能，而是定义Devin必须达成的行为结果，它决定了测试能否通过。

第三步：剔除所有主观形容词。“更友好”“更高效”“合理”这类词必须替换为可观测指标。比如将“让API响应更快”改为“将GET /api/users接口P95延迟从800ms压至≤300ms，使用wrk压测验证”。【没有量化验收标准的任务，Devin默认按最小实现路径执行】

提供精准上下文：只给它此刻需要知道的那部分项目现实

方法一：嵌入当前文件片段。直接粘贴待修改文件的10～15行关键上下文（含函数签名、import语句、相邻逻辑），不要整文件扔进去。Devin的注意力窗口有限，冗余代码会稀释关键信号。

方法二：声明技术栈约束。明确写出“当前项目使用Next.js 14 App Router + TypeScript + Tailwind CSS，禁用CSS-in-JS方案”，比笼统说“用现代前端技术”有效十倍。

方法三：标注已有机制。如果项目已存在统一错误处理模块，必须写明“所有API调用需通过src/lib/apiClient.ts封装，错误统一由useApiError处理”，否则Devin可能新建一套错误捕获逻辑。

强制任务拆解：把一步指令变成带编号的执行序列

① 先让Devin输出任务分解树：要求它用Mermaid语法画出子任务依赖图，每个节点标注预计耗时（单位：分钟）和前置条件。你只需检查是否有遗漏环节或循环依赖。

② 确认分解无误后，下达分阶段指令：“现在只执行第1步：分析src/pages/login.tsx中现有表单提交逻辑，输出3行关键代码及对应问题描述。”

③ 收到反馈后，再发下一步：“基于上一步结论，在src/components/LoginForm.tsx中新增邮箱校验逻辑，使用Zod Schema，不修改原有字段结构。”

这一步操作起来很简单，直接把上一步Devin输出的代码块复制进编辑器就能验证。但跳过①②直接发“改登录页邮箱校验”，Devin大概率会重写整个表单组件，破坏已有样式和埋点。

绑定验证方式：告诉Devin“你怎么才算做完”

在每条指令末尾，必须指定验证手段。例如：“修改后运行npm run test:unit -- -t 'login form validation'，确保全部通过并新增1个测试用例覆盖空邮箱提交场景。”

若涉及部署效果，写明检查路径：“上线后访问https://staging.example.com/login，用Chrome DevTools → Network标签页确认POST请求payload含email字段且格式校验在客户端触发。”

不指定验证方式时，Devin会默认以“代码能编译通过”为完成标志，这与真实交付质量毫无关系。