提示词编写核心原则：清晰需求与任务拆解全流程详解

要让Devin AI精准理解你的工程需求，绝不是简单抛一句“给我做个登录页”就能实现的。这样操作大概率会收获一堆不兼容代码、遗漏的表单校验逻辑，甚至用错框架版本——原因在于：Devin本质是依据完整工程逻辑自主推演的AI工程师，而非听指令的机械助手。想让它高效产出，你必须用它能解析的结构化语言进行需求描述。

定义角色与任务边界的底层原则

Devin默认以“全栈工程师”角色运行，但它不会主动确认你用Vue还是React、是否需要SSO集成、是否支持暗色模式。这些边界约束必须由你提前锁定。

第一步：在提示词开头用一句话界定Devin的身份与权限范围。例如：“你是一名专注于SaaS后台系统的前端工程师，仅使用Next.js 14 App Router和shadcn/ui组件库，不引入任何第三方状态管理库。”

第二步：紧接着声明本次任务的交付物形态。例如“输出一个可直接粘贴进VS Code运行的完整TypeScript React组件文件，包含useForm钩子、zod表单校验、提交成功Toast提示”。注意：若不声明框架版本与依赖约束，Devin可能默认使用beta版API或已废弃的hooks。

第三步：用分号隔开不可协商的硬性条件。例如：“要求响应式适配移动端；禁止使用CSS-in-JS方案；所有API调用必须通过/src/lib/api/client.ts封装的fetcher函数发起。”

将模糊需求转换为Devin可执行的原子动作

Devin无法处理“用户体验好”“性能优秀”这类主观描述，它只认可可验证、可终止的步骤指令。你给出的每一条指令，都必须是能够落地检验的具体动作。

方法一：用动词+对象+验收标准重构原始需求
错误写法：“优化登录流程”
正确写法：“将登录表单提交逻辑从客户端校验升级为服务端校验，使用Zod Schema定义email/password字段规则，错误信息需精确返回到对应输入框下方，且HTTP状态码必须为400而非500。”

方法二：对模糊术语强制量化
“加快加载速度” → “首屏渲染时间控制在300ms内，Lighthouse性能评分≥95，所有图片启用next/image自动优化并预设width/height属性。”

方法三：用否定句划定禁区
“不要生成mock数据；不要硬编码用户ID；不要在组件内部调用localStorage。”

结构化拆解复杂任务的三阶指令法

当任务涉及多页面联动或前后端协同时，必须用Devin能识别的流程语言拆解，否则它会自行补全缺失环节，导致逻辑断层。

① 先确认上下文依赖：说明当前项目结构。“本项目根目录下存在/src/app/auth/login/route.ts和/src/components/auth/LoginForm.tsx两个已有文件，新功能需复用LoginForm组件但替换其提交逻辑。”

② 再分阶段下达指令：用“第一阶段→第二阶段→第三阶段”明确推进路径。
第一阶段：分析现有/src/app/auth/login/route.ts的POST处理逻辑，提取当前校验规则；
第二阶段：基于提取规则，在/src/lib/validations/auth.ts中新建Zod schema，字段名与route.ts保持完全一致；
第三阶段：修改LoginForm.tsx，移除原有onSubmit事件，改用react-hook-form + 新schema绑定，提交后显示success Toast并跳转至/dashboard。

③ 最后指定验证方式：“完成后运行npm run dev，访问http://localhost:3000/auth/login，手动测试邮箱格式错误、密码过短、网络中断三种异常场景，确保每种情况都有对应UI反馈且无控制台报错。”