;
};
export const PromptBlock = ({children, type, agent, intent, playbookId}) => {
var utm = 'utm_source=docs&utm_medium=use-case-gallery&utm_campaign=prompt-block';
var tag = 'docs-use-case-gallery';
var agentParams = (agent ? '&agent=' + agent : '') + (intent ? '&intent=' + intent : '') + (playbookId ? '&playbookId=' + playbookId : '');
var label = type === 'schedule' ? 'Schedule in Devin' : type === 'playbook' ? 'Create Playbook' : type === 'knowledge' ? 'Add to Knowledge' : agent === 'advanced' ? 'Try in Devin' : agent === 'dana' ? 'Try in Dana' : agent === 'ada' ? 'Try in Ask Devin' : 'Try in Devin';
var buildUrl = function (text) {
var encoded = encodeURIComponent(text);
if (type === 'schedule') return 'https://app.devin.ai/settings/schedules/create?' + utm + agentParams + '&prompt=' + encoded;
if (type === 'playbook') return 'https://app.devin.ai/settings/playbooks/create?' + utm + '&body=' + encoded;
if (type === 'knowledge') return 'https://app.devin.ai/knowledge?' + utm + '&body=' + encoded;
if (agent === 'ada') return 'https://app.devin.ai/search?' + utm + '&noSubmit=true&prompt=' + encoded;
return 'https://app.devin.ai/?tags=' + tag + '&' + utm + agentParams + '&prompt=' + encoded;
};
const ref = React.useRef(null);
const [href, setHref] = React.useState('#');
React.useEffect(() => {
if (!ref.current) return;
var codeEl = ref.current.querySelector('pre code');
if (codeEl) {
var text = codeEl.textContent.trim();
if (text) setHref(buildUrl(text));
}
var header = ref.current.querySelector('[data-component-part="code-block-header"]');
if (header && !header.querySelector('.prompt-block-devin-link')) {
var link = document.createElement('a');
link.href = href;
link.target = '_blank';
link.rel = 'noopener noreferrer';
link.className = 'prompt-block-devin-link';
link.style.cssText = 'display:inline-flex;align-items:center;gap:6px;text-decoration:none;color:#fff;font-size:11px;font-weight:500;padding:4px 10px;border-radius:6px;white-space:nowrap;background:#317CFF;transition:background 0.2s;margin-left:8px;';
link.innerHTML = ' ' + label;
link.onmouseenter = function () {
link.style.background = '#2968D9';
};
link.onmouseleave = function () {
link.style.background = '#317CFF';
};
header.appendChild(link);
}
var existingLink = ref.current.querySelector('.prompt-block-devin-link');
if (existingLink && href !== '#') existingLink.href = href;
});
return
{children}
;
};
不想手动设置？把此页面的链接粘贴到 Devin 会话中，并让它为你完成所有设置。
你的团队已经使用 `!db-migration` playbook 几周了。它在重命名列和添加索引时一直工作正常——但最近两次会话在迁移中途崩溃了，因为它们尝试删除的是被其他表引用的列。
打开每个会话并查看失败点。在这个例子中，会话 3 和 4 都在同一步骤出错：
```
ERROR: cannot drop column "account_id" because other objects depend on it
DETAIL: constraint fk_orders_account_id on table orders depends on column account_id
HINT: Use DROP ... CASCADE to drop dependent objects too.
```
你现在有了一个明确的信号：这个 playbook 在执行破坏性操作前，没有检查外键依赖关系的步骤。两个会话之所以成功，是因为它们操作的是独立表；另外两个失败，则是因为它们不是在独立表上操作。
前往 [app.devin.ai](https://app.devin.ai/?utm_source=docs\&utm_medium=use-case-gallery)，点击输入框下方的 **Advanced**。选择 **Improve Playbook** 选项卡。
在 playbook 下拉菜单中选择 `!db-migration`，然后在 **session multi-dropdown** 中选择全部四个会话——包括成功和失败的会话。包含成功的会话可以让 Devin 了解这个 playbook 做得好的地方，而不仅仅是它在什么地方出错。
```txt Improve the db-migration playbook theme={null}
Our !db-migration playbook works for simple table changes but fails
when sessions hit foreign key constraints. Sessions 1 and 2 succeeded
on standalone tables, but sessions 3 and 4 crashed on FK errors.
Analyze all 4. Figure out what the successful sessions did differently
(they hit standalone tables with no incoming FKs). Then update the
playbook to:
1. Query information_schema for FK dependencies before any DROP or ALTER
2. Generate ALTER TABLE ... DROP CONSTRAINT statements when FKs exist
3. Add a rollback step that re-creates dropped constraints if the
migration fails partway through
```
这个提示之所以有效，是因为：
* **准确点出失败原因**——用“外键约束 (foreign key constraints) ”而不是“它有时会失败”
* **对比成功与失败**——Devin 可以对比会话记录，查看它们从哪里开始分歧
* **列出具体修复措施**，同时也为 Devin 留出空间，让它发现你可能遗漏的问题
Devin 会读取全部四个会话记录，精确定位失败与成功分歧的地方，并提出有针对性的修改建议。输出看起来就像是你的 playbook 的变更日志：
```
## Analysis
Sessions 1-2 succeeded because they only modified tables with no
incoming foreign keys. Sessions 3-4 failed at step 4 ("Drop the
old column") because the orders and invoices tables had FK
references to the target column.
## Changes to !db-migration
Added step 3a: "Before any DROP or ALTER that removes a column,
query information_schema.key_column_usage to list dependent FKs.
If any exist, generate ALTER TABLE ... DROP CONSTRAINT statements
and execute them first. Save the original constraint DDL for
rollback."
Added step 7: "Rollback procedure — if any step after FK removal
fails, re-create the dropped constraints using the saved DDL
from step 3a."
Updated Advice section: "Always run the migration against a staging
database first. FK chains can be deeper than expected — a column
in table A may be referenced by B, which is referenced by C.
Query recursively."
```
playbook 会自动保存。如果有哪里不对，可以在同一个会话中回复——例如：“Also add a step to notify the #database Slack channel before running destructive migrations.”
你无需离开当前的 Devin 会话。playbook 更新保存后，使用同一个会话启动一个标准的 Devin 会话，在之前失败的同一场景下测试这个已更新的 playbook：
```txt Test the updated playbook theme={null}
Use the !db-migration playbook to drop the legacy_account_id column
from the users table. This column is referenced by orders.account_id
and invoices.billing_account_id — the playbook should handle the FK
dependencies automatically.
```
如果这个会话成功，说明修复生效。如果它又碰到了新的边缘情况 (例如循环外键引用) ，就把该会话再次送回 Improve Playbook 选项卡，进行新一轮改进。