一篇文章教你从写好提示词到管理好Agent – 附赠 Agents.md

“可以不用写提示词了？” 最近经常刷到这样子的言论，

最近大家也刷到了 OpenAI 官方的提示词教学，也看到 superpower 这类工作流 skills 会影响 GPT 5.6 系列的工作效果的帖子，那么不得不承认的是

模型越来越强大的今天，以前为了提升 Agent 工作效果的 skills 可能反过来干扰 Agent。那我们知道 Skills

当 Codex、Claude Code 这类 Agent 真正开始读文件、改代码、调用工具、跑测试时，“帮我把这个项目做完”远远不够。

它至少需要知道：

• 目标是什么；

• 上下文在哪里；

• 允许访问哪些文件和工具；

• 哪些操作禁止触碰；

• 什么时候需要停下来问人；

• 什么条件满足后才算完成。

这才是 AI 工作流真正进入“控制面”的信号。🤖

提示词工程没有消失，只是从句子技巧升级成 Agent 工程

传统提示词关注的是：如何让模型一次回答得更好。

Agent 任务关注的是：如何让代理安全、稳定、可验证地把事情做完。

所以一个合格的 Agent 任务卡，至少应该包含：

• 目标：最终要改变什么；

• 上下文：相关仓库、文件、数据和已知问题；

• 允许访问：可读路径、可改路径、可用工具；

• 禁止事项：不要删除、发布、推送或修改哪些内容；

• 执行方式：先分析，再计划，再分阶段实现；

• 反馈机制：遇到范围变化、测试失败或高风险操作时暂停；

• 完成标准：必须通过哪些检查，最终交付什么。

“帮我实现登录页面”太模糊。

把⬆️变成⬇️

“只修改 src/auth/ 和相关测试，先检查现有路由和 API 类型，不新增依赖，完成后运行 npm test，如果需要改公共接口先暂停确认”，这就已经很接近一张写给 AI 工程协作者的 issue。

Codex 展示的是一种新的工作方式

我觉得 Codex 最值得关注的地方，不只是它能写代码，而是它把 Agent 任务拆成了几个可控阶段：

Ask / Plan：先理解代码库和问题；

Execute：按计划修改；

Steer：运行过程中及时纠偏；

Verify：用测试、类型检查、lint 和 diff 验收；

Queue：把临时想到的后续任务排队，不打断当前主线。

这意味着我们不应该再把 Agent 当成“提交 prompt 后等待答案的聊天机器人”。

更像是：

提出目标 → 代理规划 → 人确认方向 → 代理执行 → 阶段性检查 → 持续纠偏 → 最终验收

长任务的关键不是让模型一次性想完，而是让人始终看得见它正在做什么。

这个也有点类似于一个 Loop ，一个工作流 Loop

如何优化一套 Agent 工作流

1. 先把任务切小

不要一上来让 Agent “做完整个产品”。

把任务拆成定位问题、补测试、实现模块、运行验证、整理变更这类单一结果。任务越小，越容易发现它到底在哪一步走偏了。

2. 把稳定上下文写进 AGENTS.md

启动命令、测试命令、目录约定、不能修改的文件、历史坑点，都应该放进项目上下文。

本次任务的临时信息写在 prompt 里，长期有效的规则写进 AGENTS.md。

3. 让权限和任务范围匹配

读代码、改代码、执行本地测试、访问外部服务、发布或破坏性操作，应该是不同风险等级。

MCP 解决的是“如何接入工具”，不自动解决“工具应该做什么”。

工具白名单、读写分离、凭证轮换、调用日志和人工确认，才是 Agent 能否进入真实系统的基础。

4. 用阶段性验收代替最后一次验收

不要等 Agent 做完所有事情后才发现它从第一步就理解错了。

可以要求它按“分析 → 计划 → 实现 → 测试 → 总结”输出，每个阶段都留下可检查结果。

5. 用数据判断优化是否有效

每次优化只改一个变量，记录：

• 首次完成率；

• 返工和 Steer 次数；

• 路径、工具、权限错误率；

• token、费用、执行时长和人工审查时间。

如果只是把 prompt 写得更长，却没有降低返工和工具错误，就不算真正优化

我的工具栈选择：不要给 GPT-5.6 叠加过重的工作流

最近社区里有一种说法：Superpowers 这一类强流程技能，可能会让 GPT-5.6 系列执行任务时变慢、消耗更多上下文，甚至让任务水平下降。

这件事目前不能写成已证实结论

我能从社区 issue，有人说报告阶段被跳过、审查代理被错误地并行调度；另一个 Codex issue 记录了 brainstorming 相关的重复循环

这些材料能说明技能编排和运行时之间可能存在兼容性问题，但不能单独证明“Superpowers 导致 GPT-5.6 变笨”。

不过从实际使用角度看，我会做一个明确取舍：

保留 grill-me。

在真正执行前，用它反复追问目标、范围、假设和验收标准，把计划想清楚。

删除或停用其他 Superpowers 自动串联技能。

不要让每一个小任务都被强制套上头脑风暴、写计划、TDD、调试、审查和收尾流程。这样很浪费 tokens ！

我会选择保留 subagent-driven-development

复杂任务仍然可以拆成多个边界清楚的子任务，让不同 Agent 分别处理，最后由主 Agent 统一整合和验证。

关键不是流程越多越专业，而是流程要和任务规模匹配。

改三行 CSS，不需要完整规格评审链。

跨模块迁移，才值得拆成多个子任务并设置质量门槛。

一个直接用的 Skills

给 grill-me：

请先严格审查这个开发计划，不要写代码。

重点追问：

1. 目标是否可验证；

2. 上下文和文件范围是否清楚；

3. 是否遗漏依赖、风险和回滚方式；

4. 哪些步骤可以删除或合并；

5. 最终验收标准能否用测试或命令验证。

请持续追问，直到计划足够小、足够明确，再输出一版精简后的任务卡。

实战：让 Agent 安全增加一个 GET /health 接口

第一步，先确认项目基线。

请只读检查当前仓库，不要修改文件。

输出：

• 1. 框架和启动入口；
• 2. 路由和测试文件位置；
• 3. 安装、测试、类型检查和 lint 命令；
• 4. 当前 git 工作区状态；
• 5. 当前测试是否已经通过。

如果无法确认，请标记为“未确认”，不要猜。

第二步，只让 Agent 规划，不要立刻写代码。

目标：在现有 Node.js + TypeScript 服务中增加 GET /health 接口。

期望响应：HTTP 200，JSON 为 { “status”: “ok” }。

约束：

• 只修改路由实现和相关测试；

• 不修改数据库、部署配置和无关模块；

• 不新增依赖；

• 不覆盖已有未提交修改。

完成标准：

• 新增接口测试；

• 相关测试通过；

• 类型检查和 lint 通过；

• 最后列出修改文件和未覆盖风险。

现在只分析仓库并给出实施计划，不要修改文件。

第三步，确认计划后再执行。

要求先写测试，再实现代码；每次只处理一个小步骤；如果需要扩大修改范围先暂停；完成后运行相关测试、类型检查和 lint。

第四步，实时纠偏。

如果 Agent 开始修改不相关文件，直接说：

暂停当前动作。你正在修改超出任务范围的文件。

回到 src/routes/ 和对应测试文件，只实现 /health 接口。

不要重构相邻模块，也不要新增依赖。

先说明接下来要修改的文件，再继续。

第五步，把验证结果当成最终交付物。

要求它报告：

• npm test

• npm run typecheck

• npm run lint

• git diff –stat

• git diff –name-only

最终回答必须包含修改文件、执行命令、测试结果、接口请求和响应示例，以及没有验证到的边界情况。

这套方法的最小闭环是：

基线检查 → 规划 → 小步执行 → 实时纠偏 → 自动验证 → 人工审查

最后我的判断是

“提示词工程已死”是一个伪命题

更准确的说法是：提示词工程正在从句子技巧升级为 Agent 工程。

过去我们优化的是一句话能不能让模型答对。

再到很多的工作流skills增强 Agent 思考，

现在我们设计的是一套任务能不能被代理安全地完成，会不会过多冗余的提示词。

对个人开发者来说，下一步不只是学习更多 prompt 技巧，而是准备四样东西：

• 稳定的项目上下文；

• 明确的工具边界；

• 可重复的验证流程；

• 允许人随时纠偏的交互界面。

模型会继续变强，但真正决定 Agent 能不能进入真实工作流的，往往是这些看起来没那么“智能”的控制细节。

最后我把我自己一直在使用的 Agents.md 分享给大家，大家可以直接使用：

AGENTS.md

本文件为 AI Coding Agent 提供长期工作约定，适用于 Codex、Claude Code、Cursor 和 Antigravity。

用户背景

• 姓名：【】
• 身份：【】
• 默认语言：简体中文
• 操作系统：【】

工作原则

1. 简单优先

用最小代码解决当前问题，不做投机性功能。

• 不添加未经请求的扩展功能。
• 不过度抽象，不预留没有现实需求的配置和接口。
• 能用 50 行清楚解决，就不要写成 200 行的复杂方案。
• 如果方案显得过度设计，主动删减并说明取舍。

2. 精准改动

只修改完成任务所必需的内容，保持现有项目风格。

• 不顺手重构相邻的正常代码、注释或格式。
• 保留用户已有的未提交修改，不覆盖、不回滚、不擅自清理。
• 删除本次改动产生的孤儿函数、废弃分支和无用依赖。
• 发现历史遗留问题时只报告，不越界修改，除非用户明确要求。

3. 结果验证

把任务转化为可检查的目标，并形成独立的验证闭环。

• 新增功能：先补充关键行为或无效输入测试，再实现代码。
• 修复 Bug：先写出能稳定复现问题的失败测试，再修复。
• 完成后运行与改动相关的测试、类型检查、lint 或构建命令。
• 最终说明修改文件、执行命令、验证结果和未覆盖风险。

4. 按任务规模使用流程

• 单行文案、简单查询和小范围修改：直接处理，不强行写计划。
• 多文件、多步骤或有架构影响的任务：先给出带文件路径的实施计划。
• 复杂任务的每一步都应能独立执行和验证。
• 只有在子任务边界清楚、依赖关系明确时，才拆分并行开发。

5. 回答方式

• 结论先行，表达清晰、直接、有依据。
• 涉及代码、架构或调试时，说明关键判断和取舍。
• 不确定时明确写出假设、风险和验证方式。
• 不编造不存在的 API、文件、测试结果、链接或事实。

工作边界

• 未经明确授权，不提交、推送、发布、发送消息或公开内容。
• 涉及删除、覆盖、大规模移动或重命名时，先确认范围。
• 时效性事实先核验来源；无法核验时标注不确定，不把传闻写成事实。
• 用户明确要求优先于本文件中的偏好；平台安全规则和权限边界始终有效。

元规则：这些约定服务于结果，不是必须逐条执行的仪式。简单任务保持轻量，复杂任务才增加计划、拆分和验证

参考资料：

OpenAI Prompting fundamentals

https://openai.com/academy/prompting/

OpenAI：How OpenAI uses Codex

https://openai.com/business/guides-and-resources/how-openai-uses-codex/

OpenAI：Working with ChatGPT Codex

https://openai.com/academy/working-with-codex/

OpenAI Codex Manual：AGENTS.md

https://learn.chatgpt.com/docs/agent-configuration/agents-md.md

Google：Expanding Managed Agents in Gemini API

https://blog.google/innovation-and-ai/technology/developers-tools/expanding-managed-agents-gemini-api/

Google：Gemini API Docs MCP and Agent Skills

https://blog.google/innovation-and-ai/technology/developers-tools/gemini-api-docsmcp-agent-skills/

社区 issue：

https://github.com/obra/superpowers/issues/1463

https://github.com/openai/codex/issues/21786

#AIAgent #VibeCoding #Codex #MCP