企业官网建设流程全解析

上个月我拿到 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 这类工具的提示词能力，说到底不是修辞能力，而是你把任务拆得足够清楚的能力。