Devin AI 上线之后我第一时间拿它去跑真实需求。结果发现Devin 这类通用型 AI 智能体确实能自己读代码、自己跑测试、自己提 PR但决定它干得好不好的往往不是模型本身而是你喂进去的那条 Prompt。这篇内容就是拆解我给 Devin AI 写 Prompt 的完整思路一条看似简单的需求说明怎么一步步变成它能稳定执行的任务计划。适合正在用或准备用 AI 程序员类工具的开发者、测试和技术负责人也适合想搞懂提示词工程到底在工程里怎么落的人。1. 先搞清楚 Devin 这类智能体到底吃什么1.1 人和智能体的信息差人类程序员收到一句帮我做个订单查询接口脑子里会自动补完大量隐含信息订单表在哪个库、接口放哪个路由、返回字段叫什么、要不要分页、错误码怎么设计。这些默认知识贯穿日常开发根本不需要写出来。但 Devin 这类智能体没有这种默契。它连订单在你的项目里叫 orders 还是 order_info 都要去代码里翻。它的思维过程是从你给的上下文出发一步步 grep、读文件、判断、执行如果上下文里没写清楚目标优先级它就会自己猜而猜的方向大概率不是你要的。所以我一直强调一个观点给 Devin 的 Prompt 不是自然语言命令而是一份任务规格说明书。你写下的每个字都在减少它的猜测空间。1.2 Prompt 会被编译成任务计划Devin 类模型的完整链路大致是这样解析 Prompt → 建立任务清单 → 探索代码库 → 定位相关文件 → 修改代码 → 跑测试 → 整理结果。也就是说它会把你的 Prompt 内部拆解成一系列子任务自己排优先级执行。这就带来一个实际问题如果你的 Prompt 里同时出现了三个目标且没有说明哪个最重要Devin 会用模型自己的理解排序。它可能先做无足轻重的注释整理再花大量时间研究重构方案最后才想起要加接口。我常用的对策是在 Prompt 开头就用一句话点明最高优先级目标再写次要优化项。这相当于给它的任务计划加了显式权重。打个比方你让一个 3 岁小孩把房间整理好他会把玩具塞到床底你说把绘本放到书架上、积木收到盒子里其他东西不动他至少知道边界在哪。Devin 的能力上限远高于 3 岁小孩但它的理解同样遵循这种颗粒度决定结果的规律。2. 结构化 Prompt 的五个关键层级我拆过很多 Devin AI 的 Prompt也踩过不少坑最后收敛出一套固定结构。每次写需求我都会按这五层去组织缺一不可。2.1 角色声明让智能体知道自己站在哪里第一段不要写你是资深工程师这种空话要写清楚工程上下文当前项目是什么技术栈Python 3.11 FastAPI PostgreSQL代码库目录结构app/routers、app/services、app/repos这次改动涉及哪些模块是否已有测试框架和 CI 流程Devin 自己会去读代码但你提前把这些信息写进去能帮它节省大量探索时间。尤其是技术栈版本它如果默认用了新版 API 而你的项目还在旧版后面全是兼容性问题。我习惯在第一段给一个上下文锚点明确告诉它要从哪个文件开始看。比如先阅读 app/routers/orders.py 和 app/repos/orders_repo.py这两个文件是你这次改动的主战场。这样它不会一上来把整个仓库翻一遍。2.2 目标描述把做什么变成可验证的结果模糊的目标是 Devin 翻车的主要来源。目标描述不能只写实现订单查询而应该写成可验证的验收标准新增 GET /api/v1/orders/{order_id} 接口返回 200 时响应体包含 order_id、status、amount、created_at 字段订单不存在时返回 404接口鉴权走现有 auth 中间件每条都是 Devin 能直接对照检查的结果。写目标时我还会加一句最终交付物是一个可运行的 PR包含代码、测试和必要的迁移脚本这能防止它把活儿干一半就停下来汇报。2.3 范围红线主动告诉它不要碰什么这是我在实战中学到的最大教训。Devin 这类智能体会为了达成目标做一些多余但有风险的改动比如顺手重构了你的工具函数、改了公共模型字段、把所有 f-string 替换成格式化写法。所以我会专门开一个范围边界段落写清楚本次只允许修改 app/routers/orders.py 和 app/services/order_service.py禁止改动 app/models 下的任何文件禁止重构已有函数禁止引入新的第三方依赖禁止调整数据库表结构这些红线看起来像多余限制实际是保护网。它不会让 Devin 变笨反而让它专注于真正要解决的问题。你可以想象成给一位新来的远程工程师布置任务时顺手在工单里写清楚不要动公共组件是一个道理。2.4 约束偏好技术栈、风格、测试策略一次说清约束越详细后面对接成本越低。我会在第四层写明异常处理用项目既有的 AppException 类不要在路由里裸抛 HTTPException返回值用 Pydantic schema不要直接返回 ORM 对象测试用 pytest httpxMock 外部服务代码符合 Black 格式import 按 stdlib / third-party / local 分组日志统一用 app.core.logger.get_logger()这些信息在项目 README 或 pyproject.toml 里可能都有但 Devin 不一定会去读写了等于给它明确信号。还有一个细节我通常会告诉它如果有不确定的技术选型先停下来问我不要自行发挥。这句对控制风险特别有用。2.5 执行步骤与验收把过程控制权和判断标准交给它Devin 需要你允许它分步干活。我会在 Prompt 里给一个推荐的执行顺序但保留它的自主判断空间先阅读指定文件输出你对现有流程的理解列出实现方案和涉及文件清单按方案实现并为每个新函数补测试运行 pytest确保全部通过运行 ruff check修复 lint 问题最后输出改动摘要和验证结果验收标准单独列一个清单我会明确哪些是必须满足哪些是加分项。3. 一次完整实战给 FastAPI 仓库新增订单查询接口3.1 任务背景与 Prompt 全文为了不空谈我拿一个真实场景做示范。现有仓库是一个 FastAPI 电商后端订单在 PostgreSQL 里已经有 auth 中间件。我现在要 Devin 做一件很简单的事情新增一个订单查询接口。我实际发给 Devin 的 Prompt 长这样项目电商订单服务Python 3.11 FastAPI SQLAlchemy 2.0 PostgreSQL。 请先阅读 app/routers/orders.py 和 app/services/order_service.py理解现有实现。 最高优先级目标新增 GET /api/v1/orders/{order_id} 接口。 验收标准 1. 返回 200 时响应体的 JSON 字段严格包含 order_id、status、amount、created_at不需要额外字段 2. 订单不存在时返回 404错误码格式与项目现有错误响应一致 3. 接口必须走现有的 auth 依赖未带 token 返回 401 4. 新接口只需要支持 GET不要实现 PUT/POST 5. 所有新增逻辑必须有对应 pytest 测试覆盖正常、404、401 三种情况 范围边界 - 只允许修改 app/routers/orders.py、app/services/order_service.py、app/schemas/order.py - 禁止改动 models、utils、core 下的文件 - 禁止重构任何已有函数 - 禁止新增第三方依赖 执行顺序建议 1. 先输出你对现有文件结构和订单表模型的理解 2. 列出代码改动清单再开始写代码 3. 实现后用 pytest 跑一遍确保测试通过 4. 跑 ruff check修复 lint 问题 约束 - 用 Pydantic schema 做响应模型不要直接返回 ORM 对象 - 查询订单用现有 SessionLocal 依赖不要新建数据库连接 - 错误码用项目现有的 AppException 体系这条 Prompt 信息量不小但每条都是必要的。Devin 收到后第一件事不是写代码而是先输出它对现有文件的理解。这样我能在它动手前确认它的方向是否正确相当于多了一道人工 review 门槛。3.2 逐段拆解为什么这些段落缺一不可先说先阅读指定文件。如果不指定Devin 可能从数据库连接入手或者翻遍整个项目找订单相关逻辑。指定文件能把它的探索范围从整个仓库缩小到三个文件大幅减少无关操作。最高优先级目标这一段实质是验收标准先行。它直接决定了 Devin 的任务计划和自测方式。我故意把返回字段严格包含写成精确校验而不是返回订单信息这样它就知道字段调整仍需遵守原 schema。范围边界这个清单看起来琐碎但它专门防智能体的自由发挥。我在早期测试中遇到过 Devin 把 SQLAlchemy 查询语句顺手改成 text() 的情况就是因为没写边界。加了禁止重构已有函数之后它就会老老实实做增量修改。执行顺序建议等于给了 Devin 一个开工模板。它不一定完全照做但有了这个顺序它会把输出理解当成任务的一部分而不是直接闷头写代码。第一步输出理解对使用体验的提升非常明显相当于让 Devin 先给你讲一遍解题思路而你可以在它走错方向时立刻终止任务。3.3 智能体执行过程与结果验证我实测这条 Prompt 时Devin 的执行过程大致是先读了两个指定文件输出了订单模型和现有路由的理解然后列出三步改动新增 Pydantic schema、新增 service 函数、新增路由接着修改文件生成测试运行 pytest第一次有两个用例没过原因是 404 错误码格式与项目不一致它读取现有 AppException 后修复重新跑通最后跑 ruff check 并修了 import 排序问题。整个过程大概 20 多分钟中间我没有干预。如果我用的是帮我做个订单查询接口这种 prompt它大概率会花更多时间在方案探索上甚至会在路由文件名、返回字段、错误码上做出不同选择。对比之下结构化 Prompt 的价值不在于让 Devin 变得更强而在于减少无效决策路径。3.4 同一个任务Prompt 写法不同差距能有多大为了更直观我做过一个对照组。给同样仓库发一个 20 字 prompt新增订单查询接口参考 existing order flow 实现。Devin 默认选择了直接复用旧订单列表路由的查询方式接口路径少了 /api/v1 前缀返回字段里带上了 ORM 对象序列化后的全部字段401 测试也没写。不能说它做错了它只是缺少足够约束所以按自己理解选了一条路。如果你的项目里有严格规范后续人工 review 和返工成本会很高。这也是为什么我始终强调你用 Devin 这类智能体时真正花时间的不是看它写代码而是写清楚 Prompt。4. 面向复杂工程的提示词策略拆分、多智能体与失败重试单个接口的 Prompt 好写复杂工程任务就不一样了。一个涉及 20 个文件的改动如果全塞进一条 PromptDevin 的执行质量会明显下降。原因很简单任务计划太复杂步骤之间的依赖关系容易乱。我现在的做法是分层拆解。4.1 大任务先拆成小任务每个子任务都是一份独立 Prompt把大需求当作一个 Epic每个子任务当作一个可独立验收的 Story。比如实现用户订单全流程这个大需求我会拆成子任务 A新增订单创建接口单独测试通过子任务 B新增订单支付回调处理可 mock 回调测试子任务 C订单状态流转服务单元测试覆盖子任务 D联调确保 A/B/C 串联后符合业务流程每个子任务都带自己的角色上下文、范围边界、验收标准。一个子任务完成后我确认其结果再把结果摘要作为下一个子任务的上下文。这样 Devin 每次专注一个目标不容易跑偏而且出问题时定位范围也小。拆分还有一个好处你可以把上一个 Devin 实例的输出作为下一个实例的输入。比如子任务 A 完成后把新增的 schema 文件路径、路由签名直接写进子任务 B 的 Prompt让它在已知基础上继续做而不是重新读全仓库。4.2 多智能体协作时的角色分工Devin 可以做多实例并行我也试过多智能体分工一个实例写实现代码一个实例做代码审查一个实例写测试。关键是角色 Prompt 要有边界。实现者的 Prompt 明确只写实现不写测试不改文档审查者的 Prompt 明确只读代码输出问题清单和风险等级不提供修改方案之外的代码测试者的 Prompt 明确只补测试不碰业务逻辑。如果所有实例都在一条 Prompt 里被要求实现并自查最后往往会互相干扰或者出现多个实例同时改一个文件的情况。多智能体协作时我会让它们输出到不同分支最后人工合并。Devin 输出里如果带了完整的 commit 和分支名我可以直接把它的工作映射到 Git 分支再逐个审查合并。4.3 失败重试别急着改 Prompt先让它输出假设Devin 执行失败是很常见的事。第一次跑测试挂了如果你只是重新发一条重新跑它可能会用同样思路再试一次大概率还是同样的错误。真正的处理方式是让 Devin 先自己定位测试失败了。请你先根据日志和代码定位失败原因输出一个或多个假设 说明每个假设是你如何验证的再执行修复。不要在没有假设的情况下直接改代码。这条 Prompt 强制 Devin 从条件反射式修复切换成诊断式修复。它会把 pytest 输出里最可疑的断言、日志中的异常栈、测试前后的环境变化读一遍然后告诉你它认为问题在哪。任务死了不可怕可怕的是它在错误方向反复执行浪费算力。4.4 遇到 invalid prompt 拦截先自查措辞我用 Devin 时偶尔会遇到平台返回 invalid prompt 提示内容是 your prompt was flagged as potentially violating our usage policy。这大概率不是语法问题而是平台侧的内容安全过滤触发。这时候我的处理流程是先检查 Prompt 里有没有歧义表达、外部链接、身份冒充类描述以及是否提到不合适的操作对象然后把措辞改成完全中性的工程描述再重新提交。需要强调的是平台的过滤机制是为了保证使用环境安全遇到拦截应该主动调整表达、尊重平台规则而不是通过改写去规避限制。工程 Prompt 完全不需要依赖任何敏感内容正常描述目标、范围、验收标准就足够。4.5 上下文管理每条消息别塞太多背景Devin 有较大的上下文窗口但能装下不等于适合全部装下。塞进大量无关代码和背景反而会稀释它对关键目标的注意力。我管理上下文的办法是按需提供先给项目结构和技术栈再给核心文件路径Devin 需要更多细节时它会自己去读代码库。对于明确的决策要求比如必须用哪个 ORM 版本我才会写进 Prompt。过期的上下文宁可不给因为智能体会把旧信息当成事实后面纠正它的成本比直接不给要高很多。5. 常见问题与排查技巧实录5.1 典型症状与诊断对照表症状常见原因对症策略改了很多文件超出预期缺范围边界加只允许修改/禁止修改清单测试不跑或漏测试验收标准没写明确列出必须覆盖的测试场景接口签名和项目已有风格不一致缺约束偏好补充框架用法、错误码规范任务中途停止要求人工确认不确定点过多在 Prompt 中增加默认决策规则输出内容冗长关键改动难找缺少输出格式要求让它最后输出结构化改动摘要方向偏得离谱目标优先级不明确开头用一句话点明最高优先级5.2 一次排查实例测试不跑了有个任务Devin 改完代码后并没有执行测试直接输出完成。我开始也以为是它偷懒后来排查发现Prompt 里写的是确保测试通过但它没有收到运行测试的命令。它为确保做出的解释是人工检查代码逻辑。解决方案很简单把验收标准写成运行 pytest输出通过结果如果测试失败修复后重新运行直到 pytest 全部通过。当验收标准可以被自动化的命令验证Devin 就会老老实实跑工具而不是靠自我感觉判断。5.3 排查时我必问的清单每次 Devin 行为异常我不会立刻重写 Prompt而是先自查几个点目标是否唯一且可验证还是有两个目标在打架是否提供了准确的上下文锚点比如文件路径有没有明确告诉它哪些事不做验收标准是否可以自动化验证有没有引入它根本无法确认的外部信息是否要求它先分析再行动把这些问题过一遍基本能覆盖绝大多数翻车场景。这比盲目调 Prompt 效率高很多。6. 我踩过的坑与最终心得6.1 坑一只写做什么不写不做什么一次任务里我想让 Devin 给日志模块补充结构化输出。我写得很清楚用 JSON 格式输出日志结果它顺手把旧日志格式化函数里的清晰字段名给改了导致后续日志解析脚本全部失效。后来我在所有 Prompt 里都加禁止改动与本次目标无关的代码这句话救了我很多次。看起来像防御性编程实际上就是给智能体画了一条安全跑道。6.2 坑二把 Devin 当懂行的同事Devin 更像一个执行力很强但公司文化为零的远程工程师。它不知道你的项目约定不了解历史包袱也不清楚谁依赖哪个模块。你以为它应该知道的事它大概率不知道。所以我养成了一个习惯宁可 Prompt 多写二十行也不省略关键约定。每次多写一点上下文换来的是更少的人工返工这笔账非常划算。6.3 坑三验收标准太软早期我喜欢写响应返回订单状态然后 Devin 返回了一个 order_state 字段而我的接口文档里用的是 status。软性描述让 Devin 有自由选择空间但对接方没有。现在的验收标准我全部写成硬性描述字段名、状态码、错误格式、测试用例全部列出来。如果 Devin 做不到它会明确告诉我哪里有冲突这才是好的协作状态。6.4 马上能用的三个小技巧以下几个技巧是我现在写任何智能体 Prompt 都会用的第一个Prompt 末尾加一句请先输出执行计划待我确认后再继续。这句话等于给 Devin 加了一道闸门避免它一上来就改文件。第二个要求每次运行命令时把命令本身和输出贴到结果里。这样我在 Devin 的总结里可以直接看到它实际跑了什么而不是只看它美化过的描述。第三个把验收标准写成命令行可以直接判断的形式比如运行 pytest tests/test_orders.py退出码为 0。自动化验收标准比自然语言判断可靠得多因为 Devin 不需要自己判断对不对只需要执行并汇报。最后分享一个我一直在用的思路Devin 这类 AI 程序员配合结构化 Prompt本质上是在把你想让一个远程工程师怎么做的问题翻译成如何减少一个陌生协作者的猜测空间。每次写 Prompt 前先问自己一句如果我把这段文字发给一位刚刚入职、不熟悉业务、手头只有代码库的同事他能独立完成吗只有答案是能这条 Prompt 才算合格。实测下来这个检验标准比任何提示词技巧都好用而且适用于所有类似 Devin 的 AI 编程智能体。