Devin AI 提示词拆解：从任务委托书到六段式结构

上个月我拿到 Devin AI 试用资格的时候做了一件很“老派”的事把同一个需求分别喂给 ChatGPT 和 Devin。ChatGPT 给了我一份看起来很有条理的实施计划Devin 直接进了云端沙箱自己装依赖、翻代码、改文件、跑测试最后产出了一个 commit。那一刻我就清楚了一件事给 Devin 写的提示词和给对话式大模型写的提示词根本不是同一种东西。这两周我前前后后跑了二十多个任务有好用的提示词也有翻车翻得莫名其妙的。把那些成功和失败的例子放在一起对照之后我整理出了这套 Devin AI Prompt 拆解思路。这篇文章不聊玄乎的概念只讲我实际怎么拆、怎么写、怎么根据执行日志反推哪里没写清楚。如果你是第一次接触这类 AI 编程智能体或者正在被 Devin 的“自作主张”折磨这篇应该能帮你省下不少试错时间。1. Devin 不是聊天机器人提示词是一份“任务委托书”很多人犯的第一个错误就是拿聊天窗口的习惯去和 Devin 打交道。你给 ChatGPT 说“帮我看看这段代码为什么报错”它给你一段解释这件事就算完了。但 Devin 是一个运行在云环境里的 AI 软件工程师智能体它有终端、有代码编辑器、有文件系统、能跑浏览器它会真的对你的仓库动手。所以你的提示词不再是一句话而是它数小时自主工作期间的唯一指令来源。用聊天的心态写这份指令它就会用聊天的心态干活说个大概浅尝辄止然后等你追问。我给你的第一个定位Devin 的提示词就是一份“任务委托书”。你把它想象成你给一个远程实习生布置工作。你不会对一个只说“帮我把项目优化一下”的实习生放心因为这句话没有边界、没有完成定义、没有优先级。同样Devin 拿到一句含糊描述时它只能靠猜。它会去读一堆无关代码会选一个平庸的实现路径会在你没约束的地方发挥想象力。另一个关键点是对话式大模型的提示词通常只有“用户需求”这一层。而像 Devin 这类 AI Agent它的上下文实际是多层叠加的——系统预设、你写的提示词、仓库里的文件内容、当时的执行日志、工具返回结果。你写的提示词只是其中一层但这一层决定了它接下来的整个行动方向。这有点像是你给施工队发的开工通知单通知单里哪怕有一行写得不清楚后面的工作就会按错误理解展开。我还发现一个规律提示词写得越像“任务简报”Devin 的规划阶段就越清晰。它会先给你拆出步骤每个步骤对应你提示词里的一个分支。你提示词里没提的东西它要么跳过要么自己编。这些“自己编”的内容一旦涉及技术栈、目录结构、业务规则就很容易和真实项目打架。所以拆解 Devin AI Prompt 的第一步就是转换心态。你写的不再是“提示”而是一份包含背景、目标、边界、验收标准、交付物的项目委托书。这个心态到了后面的所有技术细节才有意义。2. 一条能跑通 Devin 的提示词拆开了有六个段落我跑了几十个任务之后逐渐沉淀出一个相对稳定的提示词结构。把它拆开看一共六个段落。每一段解决一个特定问题而且顺序基本固定。这不是我凭空发明的模板而是从 Devin 实际的行为模式反推出来的。2.1 角色与目标段落开头第一段是“角色与目标”。我会写清楚“你作为这个项目的前端开发者负责完成登录模块的缺陷修复”或者“你在一个 Python FastAPI 服务中做数据库访问层的优化”。为什么要给角色因为 Devin 需要建立上下文锚点它知道你以什么身份和视角处理问题就不会动不动跑去改后端架构或者换依赖框架。目标部分一定要写“可衡量的结果”。比如“让登录接口在 200ms 内返回”好过“优化登录性能”。Devin 没有产品直觉它只认指令字面上写了什么。你把目标写具体它的验收环节就有了一个靶子。2.2 仓库与代码位置上下文第二段是“仓库与代码位置上下文”。Devin 在云端有一个工作区但它第一次接触你的项目时并不知道代码在哪里、哪个文件是关键。我通常会在提示词里直接给出仓库分支、模块路径、相关接口文件。这一步相当于在地图上标点。十年前我带新人的时候会先给一份导航文档上面写着哪个目录是服务端、哪个目录是前端、配置文件在哪里。Devin 也一样你给它导航它就没有理由去全库乱翻。我在日志里看过太多次 Devin 卡在无关文件里反复读代码本质原因就是提示词没有给出入口文件。2.3 具体任务列表第三段是“具体任务列表”。这是整份提示词的核心我一般用编号列表。Devin 的规划器很喜欢把任务拆成步骤如果你本身就提供了步骤它就会沿着你的步骤走而不是自己发明一套流程。这里有个技巧任务列表不要写得太工程化比如“创建模型层、编写 repository、实现 service、暴露 controller”。这种层级粒度适合人但不适合 Devin。它更擅长理解“在 auth.py 里新增一个 register 函数接收邮箱和密码参数校验通过后写入 users 表和 user_profiles 表并返回 userId”。一句话里包含了文件、函数、数据表和返回结果Devin 一下子就能执行。2.4 验收标准第四段是“验收标准”。我会明确的告诉它做完之后什么指标叫完成。比如“本地运行pytest tests/test_auth.py全部通过”“前端构建不出警告”“接口能通过 curl 验证返回 200”。这一段可以不多但必须有。Devin 在没有验收标准的时候自己会把“代码能被执行”当作完成。但它不会去检查边界条件不会补测试不会考虑会不会影响原有功能。验收标准就是告诉它“交作业之前先自测”。我实测下来只要验收标准里写了“保持现有测试全部通过”Devin 做破坏性变更的概率就会明显下降因为它知道它后续的验证环节会把变更挡下来。2.5 硬性约束与边界第五段是“硬性约束与边界”。这里写的是绝对不能做的事。比如“不要修改utils/encryption.py”“不要更换 ORM 框架”“不要升级第三方依赖版本”“只在src/order/目录下面改代码”。为什么单独挖一段因为 Devin 的决策循环中每一轮都会权衡“要不要改这个文件”“要不要安装这个包”。如果你不给边界它很可能在某个中间步骤产生了技术债冲动顺手改了一个看起来更优雅但风险很高的地方。我常用一个很形象的说法给人布置任务边界写在任务书里给 Devin 布置任务边界也要写在任务书里。它只是执行器没有你脑子里那根“不能碰生产模块”的弦。所以只要你没有明说禁止它就真的敢碰。2.6 交付与沟通方式最后一段是“交付与沟通方式”。Devin 完成或遇到阻塞时会以对话和 commit 的形式反馈。我会约定好它应该输出什么“做完之后在对话里回复修改了哪些文件、测试结果如何、临时脚本是否已经清理。”还会加一句“如果遇到无法解决的环境问题或者需要我确认权限就停下来提问不要反复尝试同一个方案超过三次”。这一段的价值在于它给了 Devin 一个可预期的侧写。很多 Dein 翻车时刻不是写不出来而是它会在一个死胡同里打转。比如某个依赖装不上它会换源、换版本、换虚拟环境折腾一两个小时。我加一句“复现不了就先停下来问我”之后这类无效循环就少多了。这六个段落并不是每次都要一字不差但它们共同构成了一份 Dein 能真正理解的委托书。下面我放一个我常用的通用模板你可以直接拿过去改。角色与目标 你是一个熟悉 Python/React 的工程师负责在 xx 仓库中完成 xx 功能。 仓库上下文 - 分支feature/xx - 入口文件src/backend/api/auth.py - 数据库模型src/backend/models/user.py 任务列表 1. 在 src/backend/api/auth.py 中新增 register 接口 2. 接收 email、password、nickname 参数 3. 校验邮箱格式和密码长度 4. 写入 users 表和 user_profiles 表 5. 返回 userId 和创建时间 验收标准 - 运行 pytest tests/test_auth.py 全部通过 - curl -X POST http://localhost:8000/register 返回 200 - 二次注册相同邮箱返回 409 硬性约束 - 不要修改 src/backend/core/security.py - 不要新增第三方依赖 - 不要改动数据库迁移脚本 交付与沟通 - 完成后列出修改的文件清单和测试输出 - 遇到环境问题先停下来问我3. 三个真实场景的提示词对比同一需求两种写法模板是骨架实战才是血肉。这里我挑三个我真正跑过的场景把粗糙版提示词和拆解版提示词放在一起做对比。对比之后你会发现差距往往不是“写得长”而是“信息位置是否准确”。3.1 功能开发给后台加 CSV 导出先说一个最常见的功能开发场景。当时我要在一个管理后台里加一个订单导出的按钮按钮点击后把当前筛选条件下的订单列表导出成 CSV。第一版提示词我写得很随意“在订单列表页加一个导出 CSV 功能。”结果 Devin 花了二十分钟自己选型用了它自己新引入的一个 CSV 库然后把导出逻辑放在了一个完全不相关的 service 文件里。更离谱的是它导出的字段顺序和前端表格顺序不一致。第二次我换成拆解版任务在订单管理页新增 CSV 导出功能 仓库上下文 - 前端页面src/frontend/pages/Orders.tsx - 后端接口src/backend/apis/order.py - 订单模型src/backend/models/order.py 具体实现 1. 后端 order.py 中新增 /export 端点复用列表接口的筛选条件 2. 导出字段顺序为订单号、用户ID、商品名称、数量、实付金额、下单时间 3. 前端 Orders.tsx 中新增“导出CSV”按钮点击后调用该端点并下载文件 验收标准 - 使用已存在的 csv 库项目 vendor/csv.py不新增依赖 - 后端返回 Content-Type: text/csv且带 BOM 头避免 Excel 乱码 - 前端下载文件名格式为orders_YYYYMMDD.csv 硬性约束 - 不动订单分页和权限逻辑 - 只在 order.py 中新增函数不修改其他后端文件对比就很清楚。粗糙版只给了“要什么”拆解版同时给了“在哪里做”“按什么顺序做”“用什么工具做”“做完怎么算数”。Devin 拿到拆解版后直接按步骤执行连中间反馈都省了不少。3.2 缺陷修复登录接口偶发 500第二个场景是修复问题。现象是登录接口偶发返回 500日志里能看到KeyError: token但不确定具体触发条件。第一版提示词“登录接口偶尔报错帮我查一下。”结果 Devin 读了一堆代码自己猜了一个原因改掉了本不该改的 token 生成逻辑还引入了新 bug。拆解版提示词我这样写你需要在订单服务中定位并修复登录偶发 500 的问题。 复现线索 - 错误日志src/logs/backend.log 第 283 行附近出现 KeyError: token - 登录入口src/backend/routes/login.py - Token 生成逻辑src/backend/services/token_service.py - 已知规律连续快速登录时更容易触发 排查要求 1. 先阅读 token_service.py 和 login.py定位 token 在哪里写入、哪里读取 2. 根据已知规律构造快速连续调用的测试脚本 3. 修好后运行现有 pytest 全部用例 约束 - 不要改数据库表结构 - 不要改前端逻辑 - 不要动 JWT 密钥相关配置只需要处理逻辑缺陷 交付说明根因和修复位置附测试验证结果这一次 Devin 先做了日志分析又自己写了一个并发快速调用的脚本复现了问题然后把 token_service 里一个 cache 清理时机的问题修掉了。核心差异在于我给了它“复现线索”和“排查路径”它就不需要靠猜。3.3 重构迁移Python 3.9 升级到 3.11第三个场景更复杂把一个 Python 服务从 3.9 升级到 3.11解决兼容性并保持行为不变。这类任务如果一次全丢给 Devin基本一定翻车因为工作量大到超出它的单次执行预算。第一版提示词“把项目升级到 Python 3.11。”Devin 改了 requirements、改了 setup 文件跑了几个命令发现 import 报错开始尝试改代码最后在某个兼容性问题里面绕不出来。拆解版我把它拆成了三个阶段但一次只让它跑第一阶段阶段目标先做 Python 3.11 兼容性摸底不急着改代码。 仓库上下文 - 依赖文件requirements.txt - 入口脚本src/main.py - 自检脚本scripts/health_check.py 任务 1. 梳理当前 3.9 语法和依赖中对 3.11 不兼容的地方 2. 运行 scripts/health_check.py记录所有报错 3. 把兼容性问题按照“影响运行/影响测试/可忽略”分类输出一个 markdown 报告 验收标准 - 报告里列出每个问题的文件位置、报错信息、建议修法 - 不实际修改任何代码只做分析 硬性约束 - 不要升级 requirements.txt 里的依赖版本 - 不重写项目现有架构 - 完成后先把报告贴到对话里等我看完再进入第二阶段这个提示词的核心是“把大目标拆成一个里程碑”。它只让 Devin 去做分析和报告后面的修改等我看完再说。结果它很快产出了清单我确认之后再分阶段让它逐项处理整个迁移耗时缩短了很多。从这三个场景可以提炼出一条原则Devin 不是不能用而是它的“自主性”需要一个足够小且足够明确的边界。边界清晰它比一般聊天模型强得多边界模糊它比一般聊天模型更容易跑偏。4. 从执行日志反推提示词问题我的调试迭代流程Devin 这类 AI 编程智能体最大的优势是它会留下完整的执行轨迹。它运行了哪些命令、读取了哪些文件、为什么修改某个文件你都能从执行计划、命令回放、提交历史里看到。这给了我们一套全新的调试方法像查 bug 一样查提示词。4.1 先看规划再看成因我拿到一个 Devin 任务习惯先看它最初的规划。Devin 收到提示词后会把目标拆成几步像一份迷你开发计划。如果这份计划和我的预期对不上那问题往往不是执行能力而是提示词里某些信息被误解了。举个例子。有一次我让它“优化数据库慢查询”它规划里第一步是“阅读整个 orm 配置”第二步是“检查所有 repository 文件”。但我的真实意图是“针对订单查询列表接口做一个索引优化”。它的规划说明了它理解的上下文是“全库慢查询”而不是“订单列表接口”。很多本来可以用索引解决的简单问题被它用全局重构的思路绕了进去。看到这个规划后我立刻中止任务重新给了更狭窄的上下文执行效率马上翻倍。4.2 观察停留点定位缺失信息Devin 的界面会显示它正在阅读哪些文件。如果它在一个毫不相关的目录里反复打开文件大概率是提示词没有给足入口。这时候不需要等它执行完直接追加一条消息把正确的入口文件发给它即可。我碰到过一个很典型的例子。它一直在看一个utils/format.py但我要它改的功能在services/checkout.py里。日志显示它打开utils/format.py后发现里面没有 checkout 相关的筛选逻辑于是去读整个订单目录。这种行为的本质是Devin 试图构建一个“全局地图”但提示词没告诉它地图的起点。后来我在拆解版里专门加了“仓库上下文”一段类似情况就很少发生了。4.3 用“停止指令”代替“重新解释”Devin 在运行过程中你可以随时插话。我踩过的坑是在发现它跑偏时下意识给它重新解释一遍完整需求解释了一大段话。结果它更乱了因为它正在执行的上一个目标还没撤销新消息又引入一大堆新的判断依据两者产生了冲突。正确做法是先把当前方向停下来。我一般会用很短的话说“先停止当前方案恢复你刚才改动的代码等我给你新的方向。”等日志显示它已经停下来回滚之后我再给拆解过的新提示词。这有点像处理一个正在自动驾驶的系统你首先要做的不是讲新导航而是退出自动驾驶模式。4.4 针对失败模式改造提示词几次迭代之后我发现 Devin 的失败模式其实高度可预测。它能执行但并不真正“理解”业务所以只要提示词在以下三个位置有缺口它就会栽跟头一是“入口缺失”导致它反复读无关文件二是“验收缺失”导致它做完就停不自测三是“边界缺失”导致它改了不该改的范围。我的迭代流程里每次失败都会把日志回放一遍按这三个维度归因然后针对性修改提示词而不是全盘推到重写。这个方法背后的逻辑也不难理解Agent 的每轮行动都服从当前上下文里的信息增益和任务优先级。提示词里的信息密度越高行动路径就越短。所以与其说我在调试提示词不如说我在练习一件事——把项目里那些我脑子里的隐性知识变成 Devin 也能读懂的显性指令。5. 提示词之外的隐藏变量仓库上下文与环境约束如果你以为把提示词写漂亮就够了那还没到及格线。Devin 的工作方式决定了它还会受到仓库上下文、环境配置、甚至你项目中文档质量的影响。提示词只是一部分它需要在仓库里找到能落地的信息。5.1 仓库里有一份清晰的项目运行说明比提示词里写一百遍都管用Devin 第一次进入一个仓库时默认会读 README、目录结构、配置文件。如果 README 里说清楚了项目怎么启动、测试怎么跑、有没有 Docker、依赖怎么装那它的开局顺畅程度会大幅提高。我建议在仓库根目录放一个简短的DEVELOPMENT.md内容包括本地启动命令、环境变量示例、测试命令、代码目录结构说明。这份文档不只是给人看的更是给 AI 智能体看的。它就像给 Devin 的“入职第一课”比你在提示词里重复强调“先看 README 再动手”要有效得多。我自己的项目里曾经为了一个接口调试Devin 卡住了十分钟最后发现仓库里没有.env.example它不知道该往环境变量里填什么。后来我把.env.example补上并在提示词里加了一句“环境变量参考.env.example”后续任务就顺畅了。5.2 项目里已有的测试是 Dein 最好的约束器有一种观点是提示词越复杂Devin 越容易混乱。我没有完全认同。但我的确发现与其在提示词里写十几条“不许这样、不许那样”不如让仓库里的测试用例去兜底。比如你想让它改一个模块同时保证原有行为不变使验收标准直接写“运行pytest tests/test_order.py全部通过”。它就会自己跑测试跑挂了它会看输出去改。这个机制比任何“不要破坏原有功能”这句话都有效因为它把抽象的约束变成了具体可验证的动作。我有时候甚至会故意在提示词里写“先运行一遍相关测试把失败项记录下来再开始你的修改。”这样 Devin 会自动进入测试驱动的工作流边改边验证而不是改完全盘再看结果。5.3 云沙箱环境的资源边界直接影响提示词的任务粒度Devin 运行在云沙箱里它的一次会话有时间和资源预算。如果你把一个需要三天的重构任务一次性丢给它它通常会在某一个阶段耗尽预算留下一个改了一半的工作区。这个问题不是提示词能完全解决的但可以通过拆分任务来缓解。所以我会在一个大的迁移或重构任务里写成一系列“里程碑式提示词”第一个里程碑只做梳理和报告第二个里程碑改一个子模块第三个里程碑处理新建代码的兼容性。每个里程碑都有独立验收这样即使某个里程碑没跑完前面的成果也已经被提交了。5.4 把 secret 和安全相关配置挡在提示词之外如果你在提示词里写“从config/secrets.yml里读取密钥”“在.env里填入生产环境的数据库密码”那这就成了安全隐患。Devin 的执行日志和截图会保留在平台侧哪怕只在对话里出现密码也不合适。正确做法是在提示词里引用“当前仓库已有的环境变量位置”而不是暴露具体密钥。我还会在仓库里维护好.gitignore确保.env、密钥文件不会进入版本控制。Devin 只需要知道“从环境变量里读DATABASE_URL”它自然会去读。6. 我给 Devin 写提示词时踩过的坑与目前的最优习惯最后这部分比较絮叨但都是花了不少任务预算换来的教训。我把踩过的坑归个类也把现在稳定的习惯写出来。最大的坑是“一次任务塞太多目标”。人拿到十个子任务会自己排优先级Devin 会按顺序执行但它的上下文预算撑不住。后来我严格控制每一个提示词只围绕一个核心目标展开最多带两个辅助目标。比如“实现订单导出功能 补两层基础校验”这是一个核心但“实现订单导出 重写订单详情页 改数据库表结构”这就过载了。第二个坑是“只给方向不给例子”。Devin 很擅长模仿你给出的代码风格。我在提示词里会给一个“参考实现”比如一句话说“按照现有src/services/user_service.py的风格在order_service.py里新增一个函数”。这一个简单的锚点能保证它的代码风格、命名习惯、异常处理方式都和项目原有代码一致。没有这个锚点它就会用自己的偏好写代码后续 code review 成本极高。第三个坑是“不设退出机制”。现在我几乎每个 Devin 提示词都会写一句“如果某个方案尝试两次还没成功就停下来告诉我换一个思路之前先征得我同意。”这句话极大减少了资源浪费。人的直觉可能觉得这句话是多余的但 AI 智能体天然倾向在一棵树上吊死因为它每一步都在朝当前 reward 方向前进没有一个外部信号告诉它“这条路不对”。第四个坑是“频繁横叉中断”。早期我看到 Devin 执行路径和我预期不一致就立刻发一大段纠正消息。后来发现如果它正在跑一个命令或者正在做阶段验证太频繁的插话会让它分心。现在我只有在两种情况下插话一是它已经跑完当前动作进入下一个规划节点二是它明显卡死在一个文件里反复打转。其他情况我都让它先跑一会儿积累足够信息后再一次性给反馈。现在我的最优习惯基本可以总结成一句话给 Devin 写提示词本质上是在做任务拆解和边界管理不是在“写作文”。我会先在本地把目标想清楚把入口文件、验收标准、不能碰的位置列出来然后才打开 Devin 的对话框。写提示词的时间从以前的“打一段话”变成了“做一次小的技术设计”。我也开始把这些提示词模板沉淀到项目自己的文档里。一个新增功能、一个缺陷修复、一个依赖升级都有对应的模板。下次要跑类似任务时直接把模板拉出来改几个路径就能用。这样不仅省时间而且每轮迭代的改进都能积累下来。最后分享一个小技巧每次提交给 Devin 之前我都会在脑子里过一遍“如果我是一个完全不了解这个项目的工程师只凭这段话我知道去哪里查代码、怎么复现问题、做到什么程度算完成、有哪些地方不能碰吗”只要有一个问题的答案是不确定我就会把那段补清楚再发送。这个自我检查的动作比任何技巧都管用。Devin 这类工具的提示词能力说到底不是修辞能力而是你把任务拆得足够清楚的能力。