提示词

把下面的文字翻译成简体中文。保留术语、代码和专名。先给译文，再列你改动的三处，并说明为什么改。不确定的地方标出来，不要编。 {原文}

你来做面试官，职位是{职位}。一次只问一个问题。等我回答后，指出漏掉的要点，再问下一题。问满 8 题后，按这个职位给一份简短评价：过、待定或不过，并写出依据。

审查下面的改动。只列会让它出错、变慢或难维护的问题。每条写清文件、严重程度（高、中、低）和改法。不要重写整个文件。没有问题就写没有。

把下面的流水账收成一份周报。分成：本周完成、未完成及原因、下周三件事。每条一句话，保留数字。不要写成自我评价。

根据下面的列名写一个 Excel 公式，完成：{任务}。先写公式，再用两行样例算出结果。如果要动到别的列，先说明。不要用我没给出的列。

用标准 SQL 回答：{问题}。表结构在下面。先写查询，再说明它依赖哪几张表。不要发明不存在的列。如果问题含糊，先问我一个问题。

写一个 JavaScript 正则，匹配：{要匹配的}。不要匹配：{不要匹配的}。给出表达式，再各举两个通过和两个失败的例子。

向刚接手仓库的人解释下面的代码。先用三句话说明它做什么，再按执行顺序讲。标出输入、输出和会失败的情况。不要改代码。

根据下面的 diff 写一条提交说明。第一行不超过 72 个字符，说明改了什么。空一行后写为什么。不要写“update”或“fix bug”这种空话。

完成这个修改：{任务}。只动完成它所必需的行。不要顺手格式化、改名或重写旁边的代码。改完指出你动过的文件，并说明怎样验证行为没变。

这个缺陷是：{现象}。先写出会复现它的步骤或测试。复现之前不要改产品代码。复现之后再做最小修改，并说明为什么这就是原因。

为{行为}先写一个会失败的测试。展示失败输出，再写让它通过的实现。不要先写实现。通过之后不要顺手加没要求的功能。

先阅读与{任务}相关的文件，列出你看到的事实和还不确定的地方。这一步不要改文件。我确认之后你再改。

先不要写代码。针对{目标}给出一个短计划：要改的文件、不做的事、怎样算做完。计划里如果有两个同样合理的做法，停下来问我选哪一个。

看下面的 diff，只找安全问题：注入、越权、密钥进了仓库、不安全的反序列化。每条给出文件和触发方式。没有就写没有。不要做无关的风格评论。

为这个页面写 5 个 title 和 5 个 meta description。页面讲的是：{主题}。title 不超过 60 个字符，description 不超过 160 个字符。每个都要包含用户会搜的词，不要堆关键词。

为{产品}写首屏：一个结果、一段不超过 40 字的说明、一个按钮。按钮要写出点击后打开什么。不要口号，不要三个卖点并排。

改写下面的文字，让它像在跟一个具体的人说话。删掉空话和排比。保留所有事实、数字和文件路径。改完列出你删掉的套话。

为下面的文章起 10 个标题。5 个直说结果，5 个带一个具体细节。不要用“震惊”“终极”“赋能”。每个标题不超过 22 个字。

为{产品}写 3 则短广告，每则对准一个买家和一件事。写出买家是谁、他现在的麻烦、以及点击后得到什么。不要堆形容词。

写一篇小红书笔记，主题是{主题}。第一行是标题，正文不超过 300 字，包含你用过的具体细节，结尾一个问题。不要“家人们”“绝绝子”。标出适合配的 3 个画面。

回复下面的邮件。先用一句话回答对方的请求，再写需要对方做什么，最后给出时间。语气直接。不要“希望这封邮件找到你好”。

把下面的会议记录整理成纪要。只留决定、负责人、截止日期和未决问题。讨论过程删掉。没有负责人的事项单独标出来。

目标职位是{职位}。把下面的经历改成 5 条简历要点。每条以动词开头，带一个数字或产物。删掉与职位无关的内容。不要编造我没写过的经历。

职位要求在上面，候选人材料在下面。列出符合的要求、不符合的要求、材料里没写的要求。不要推测性格。最后给一个是否约面试的建议，并写出依据。

为{城市}排 3 天行程。每天上午、下午、晚上各一件事，并写两地之间怎么走。标出需要预约的地方。不要排我没提的购物点。预算是{预算}。

用下面的设定写一个 800 字以内的短篇：{设定}。一个主角，一件要完成的事，结尾要有变化。不要分章，不要说教。

把下面的情节写成一场戏：{情节}。只写场景标题、动作和对白。对白要能念出来。不要写镜头术语，不要写角色内心。

辩题是：{辩题}。先给正方最强的三点，再给反方最强的三点。每点一句话，并写出它依赖的事实。最后不要宣布哪边赢。

教我{主题}。先用一个具体例子讲核心，然后出两道题考我。我答完之前不要讲下一节。答错了就只指出错在哪一步。

我想搞懂{问题}。你不要直接给答案。每次只问一个能缩小范围的问题。等我答完再问下一个。我明确说“给答案”时你再讲。

读下面的论文。用 8 句话摘要：问题、方法、数据、结果、作者自己写出的限制。每一句后面用括号标出它来自哪一节。论文没写的不要补。

比较{方案A}和{方案B}，用来做{目标}。列一张表：成本、要改的地方、失败时会怎样。每个格子都写依据。依据不足就写未知，不要猜。

看下面的界面。只评论层级、间距、可点区域和焦点态。列出要改的三处，每处说现在的问题和改完的样子。不要换一套视觉风格。

为{主体}写一条图片提示。写明清镜头里有什么、光线、构图和不要出现的东西。用一段话，不要关键词堆砌。出 2 个版本：一个方图，一个横图。

为{产品}起 12 个名字。每个名字要能当域名：短、能念、不要连字符。避开已经用滥的通用词。每个名字后面写一句话说明它指什么。

我要说的是：{句子}。先给一个更自然的说法，再标出我原来的问题（用词、语序或语气）。然后给一个我可以跟读的更短版本。

我要在{系统}上完成：{任务}。列出要运行的命令，每条一行，并说明它会改什么。不要假装你就是终端。有破坏性的命令先停下来问我。

阅读下面的 JavaScript。按执行顺序列出每个 console 会打印什么。如果会抛错，写出错误类型和出在哪一行。不要改代码，除非我接着要求你修。

为{系统}划模块。每个模块写：它负责什么、它不负责什么、对外的一个接口。模块不超过 6 个。不要写实现代码。

阅读下面的材料。用不超过 40 字写摘要。然后列出文中确实说过的想法，最多 8 条；只有原文出现过的句子才引用，最多 5 条；最后给一个收获。某一栏没有内容就写“无”。不要编造引语。 {材料}

阅读下面的 git diff，用 Markdown 写一份合并请求说明，分这几节：摘要、改动的文件、原因、影响、测试计划。每个文件写出改了什么。diff 里看不出测试，就写测试计划缺失。不要重写代码。

阅读下面的日志。列出异常和反复出现的问题，每条给出支撑它的那一行或时间。然后只写日志本身能支持的改法。原因不在日志里，就直接写出来。不要用文件以外的猜测来修。

把这段产品说明写成 Markdown 需求文档，分这几节：概述、目标、受众、功能、功能需求、非功能需求、成功指标。每条需求都要能验收。缺的事实写“未知”。不要加说明里没有的功能。 {说明}

为{功能}写一条用户故事。用三行：作为{角色} / 我希望 / 以便。然后用普通条目列出测试时能核对的验收标准。不要再写第二条。说明里没有依据的标准不要写。 {说明}

为{系统}写一份设计说明。分这几节：业务目标、上下文、容器、部署、风险、问题和假设。上下文、容器、部署各给一张 mermaid 图和一张表，表里写名称、类型、职责。安全部分只写描述里已经写明的控制；没写就写未说明。不要写如何攻击这个系统。 {描述}

阅读下面的 Terraform 计划。用一句话写出将要改变什么。然后列出关键的新建、更新和销毁。费用和访问变化只有计划正文写了才列出。没有费用就写“未显示费用”。不要编造价格，也不要写攻击步骤。

阅读下面的 diff。第一行不超过 100 个字符，用现在时，并加上其中一个前缀：feat、fix、docs、refactor、test、chore。然后最多 6 条，每条用一句现在时的短话写出行为上的变化。只动空白的文件跳过。

阅读下面的论证。每个站不住的步骤，用白话写出它属于哪一种谬误，引用那一句，并说明这一步为什么证明不了结论。步骤站不住，并不等于结论为假。论证成立就写成立。不要列出文中没有的谬误。

重写下面这条提示词，让模型能照着做。任务保持不变。补上输出样子、长度、不要写什么，以及输入的占位。把输入放进一块标清楚的区域。不要加角色。只返回改写后的提示词。 {提示词}

为{现象}写一份缺陷报告。字段：标题、环境、步骤、预期、实际、严重程度。标题要写出组件、动作和现象。步骤编号，并且尽量短。严重程度用严重、高、中、低，并写出对使用者的影响。我没给的字段写“未知”。不要提出代码修法。

为{行为}写测试计划，分三组：单元、集成、端到端。每条用“给定 / 当 / 则”一句话，只验一件事。多数放在单元。端到端最多 2 条，而且必须是人会走的路径。不要写测试代码。不要用固定等待。

把{功能}写成测试能核对的需求。每一行用其中一种句式：当[事件]时，系统应当[行为]；在[状态]期间，系统应当[行为]；如果[不想要的情况]，系统应当[响应]。然后列出说明里还没写的边界，每条标成“提议”。不要写设计，也不要写代码。

把关于{选择}的一个决定记下来。分节：决定、背景、选项、理由、影响、何时重看。选项只写我点过名的。我只给了一个选项，就写备选未提供。理由要写出取舍。何时重看要写出会让我们重开这个决定的条件。不要编一个指标。

阅读下面的 diff。只列出读者需要改的文档：README、变更记录、API 说明、配置示例或迁移说明。每条写出章节，以及 diff 里哪一个事实让它过时。diff 没有使用者能察觉的变化，就写不需要改文档。不要起草 diff 里没有的功能。

下面先是例子，然后是新输入。答案跟例子用同一种样子。只用例子里出现过的标签。新输入对不上任何一个，就写“对不上”，并指出最接近的例子。不要新造标签。 {例子} 新输入： {输入}

用三种不同的方法回答{问题}。每条不超过 80 字，并以“答案：”收尾。然后说明三个答案是否一致。一致就给出那个答案。不一致就列出分歧。不要把它们合成一个新数字。

写{主题}。只用这些小节，并按这个顺序：{小节}。全文不超过{字数}字。某一节需要的事实我没给，那里就写“未知”。不要加小节，不要加口号，也不要补我没写的事实。

写{主题}。下面这些一律不要出现：{排除}。不要点名，也不要用别的说法把它们写进去。写完再删掉仍然碰到这份清单的句子。如果删完没有剩下的，就写排除条件把答案拿掉了。

帮我找一个能把 Markdown 大纲做成 PPT 的技能，并安装它。

用 Grill Me 追问这份迁移方案。不许跳过回滚、数据量和负责人缺口。

按 Frontend Design 重做这个营销首页。不要紫渐变，不要三卡片功能排。

打开预发控制台，用环境变量里的账号登录，列出过去一小时失败的任务。

用 Vercel React 最佳实践审计 src/app/dashboard/page.tsx，先修影响最大的三项。

用 Web Design Guidelines 检查这个落地页，按文件路径列出不合格项。

写一个技能：把 GitHub issue 变成测试先行的实现计划。

合并这三份 PDF，写入真正的文档标题，并抽出第 4 页的表格。

把这一页说明做成 10 页投资人材料。每页只保留一个观点。

按 sku 合并这三份 CSV，去掉重复行，写出 inventory.xlsx。

为我们的内部工单 API 设计 MCP 服务器。最多三个工具。先出示 schema。

结账总额只在欧元时算错。先诊断。在能复现之前不要打补丁。

给这个 billing 目录提出模块图。点名缝合处，以及每条缝需要的测试。

给这个店铺建模退款。在写函数之前先列出非法状态对。

比较编码智能体上的 Agent Skills 与 MCP。引用原始文档。标出仍不清楚的地方。

编辑这份 README。去掉 AI 痕迹。命令和文件路径必须原样保留。

教我 Astro Content Collections。下一课前先测验。进度存在 ./notes。

记住我们使用 trailingSlash never，默认语言是英文。写进智能体笔记。

把这个组件改成 Vue 3 组合式 API。对齐本地 vue 版本。不要 Vuex。

审计 /guides/install-agent-skills 的标题长度、canonical，以及是否只有一个 h1。

重写首屏。只保留一个结果。不要空话。按钮必须写出点击后打开什么。

把这份大纲做成 Word 简报：用标题样式、加封面，并在未决问题上留批注。

启动开发服务器，再用 Playwright 测结账流程：空购物车和已登录用户各跑一遍。

加一张 orders 表，并用 RLS 让用户只能看到自己的行。给出迁移和策略。

把这个设置页重构成复合组件。不要再把 theme 和 title 往下传五层。

用 Expo 做个人资料页。帖子列表用 FlatList。不要用仅适合 Web 的 div 布局。

为一次性购买加上 Checkout。校验 Webhook 签名，并用幂等方式保存支付状态。

为这个 PR 建一个 Neon 分支，在分支上跑迁移，并把预览环境指过去。

用 Remotion 做 15 秒产品片头：标题卡、三个卖点、结尾 Logo。1080p。

这个不稳定测试五次里失败一次。用系统化调试。在能复现之前不要打补丁。

用 TDD 加速率限制。先展示失败测试，再写实现。

重做这个设置页。修好层级、间距和焦点态。不要库存紫渐变。

给这个 API 加认证。若有任何地方说不清，先问我，再自己发明方案。