OpenAI 亲自教你如何用 Astra

Prompt 不一定要越来越长

过去两年，大家学 AI 时经常会接触一个概念：Prompt Engineering。这套方法在过去确实很有用。因为早期模型的自主规划能力有限，如果任务稍微复杂一点，人不把步骤拆清楚，它就很容易跑偏。

但 Astra 这一代模型的变化在于，它越来越擅长自己完成多步骤任务。OpenAI 在官方资料里提到，Astra 可以跨代码、浏览器以及专业软件完成复杂工作，也更擅长理解用户意图和上下文。

这意味着，人和 AI 之间的分工可能正在悄悄发生变化。以前更像是：人负责想清楚每一步怎么做，AI 负责按照步骤执行。现在则越来越像真实团队里的协作方式：人把目标、背景和边界说清楚，AI 自己判断应该怎么完成。

所以现在回头看那些几千字的 Prompt，有时候会发现里面其实混杂了很多不必要的微观管理。我们担心 AI 做不好，于是把自己能想到的所有步骤都写进去，结果反而限制了模型自己规划任务的空间。我们之前接 tiktok 脚本智能体的项目，甲方基本就是非常 micro management，把各种提示词写的非常长，效果反而不如短提示词好。

比“告诉它怎么做”更重要的，是告诉它“什么叫做完”

把 AI 当成聪明人，聪明人不需要你告诉他 1234 步，而是更需要知道你究竟想要达成什么目标。

比如可以把任务描述成：“帮我完成一个可以正式上线的 Landing Page。参考现有产品的视觉风格完成页面，运行项目并在浏览器里检查。如果发现明显的布局、交互或者移动端适配问题，就继续修改，确认可以正常使用以后再结束。”

这种好处是给了 Definition of Done，也就是完成标准。具体怎么做，AI 可以自己规划；但我们为什么做这件事情，希望得到什么结果，以及做到什么程度才算真正完成，这些仍然需要人来定义。

又要说回甲方。当甲方不告诉乙方要做到什么结果达成什么目标解决什么问题，而是一味的给乙方很多 AI 给出的详细步骤和代码，反而是限制了乙方的能力。

模型升级以后，以前写的规则也应该重新看看

还有一个很容易被忽略的问题：我们给 AI 留下了越来越多的“历史包袱”。

现在很多人使用 Codex 或其他 Coding Agent 时，会配置 AGENTS.md、Skills、项目规范以及各种长期 Instruction。这些东西本来是为了让 AI 工作得更稳定，但很容易出现一个情况：AI 犯一次错，我们就加一条规则；下一次又犯了另外一个错，于是再加一条。

时间长了以后，一个项目可能积累出几百行甚至更多的说明。问题是，其中很多规则并不是永远正确的。它们只是为了弥补某一代模型能力不足，而临时搭起来的“脚手架”。

OpenAI 在 Astra 的相关指南里也特别提醒，模型的指令遵循能力更强以后，会更加认真地读取 Skills、AGENTS.md 等文件里的内容，因此开发者反而应该重新检查这些长期规则，看看有没有已经过时、互相冲突，或者会对新模型产生不必要限制的内容。

这件事情其实很像管理一个团队。一个新人刚入职时，你可能需要把流程讲得非常细；等他已经可以独立工作以后，如果你仍然要求他每天严格按照几十条操作规范执行，效率反而可能下降。AI 也是一样。模型升级以后，我们给模型的管理方式也需要升级。

Skills 不是越多越好

最近 Skills 也越来越火。如果简单理解，Skill 有点像给 AI 准备好的工作 SOP。做市场调研可以有一个 Skill，写 PRD 可以有一个 Skill，数据库 Migration、部署上线、销售分析，也都可以做成不同的 Skill。

这个方向我其实非常认同，因为真正有价值的 AI 应用，本来就不应该每次都从零开始。一个团队过去积累下来的方法、流程和经验，如果可以逐渐沉淀成 AI 能调用的能力，AI 才真正开始进入组织。

但这里同样有一个问题：Skill 并不是越多、越长越好。如果一个 Agent 装了几十个 Skills，每一个都写得非常宽泛，又都告诉 AI“遇到相关情况应该优先调用我”，最后模型面对的其实是一堆互相竞争的指令。

更合理的方式，是让每个 Skill 的边界足够清楚。什么时候应该出现，什么时候不应该出现，最好能够一眼判断。这也让我越来越觉得，未来做 Agent 系统，很大一部分工作其实不是“给 AI 塞更多知识”，而是在设计一套更好的信息组织方式。

Context 不是越多越好，关键是出现得刚刚好

我以前也很容易有一个误区：觉得上下文越多，AI 就越懂我。所以恨不得把产品文档、客户资料、历史聊天、数据库设计、代码规范、品牌手册、会议记录全部塞给它。

真正做 Agent 产品以后会发现，Context 太多同样会产生噪音。一个正在修改 UI 的 Agent，可能根本不需要阅读数据库部署文档；一个正在写销售邮件的 Agent，也没有必要先看完公司过去三年的会议纪要。

更好的状态应该是：修改 UI 时，它能看到 Design System；修改数据库时，它能拿到 Schema；做客户分析时，它能调用 CRM 和历史沟通；需要部署时，再读取 Deployment 文档。重要的并不是 AI 一开始知道所有事情，而是它在需要某些信息的时候，能够拿到正确的信息。

这也是为什么最近行业里越来越多人开始谈 Context Engineering。过去大家关注的是：“这一句话应该怎么写，才能让 ChatGPT 回答得更好？”现在我们开始关心另外一些问题：AI 在什么时候应该看到什么信息？它可以调用哪些工具？哪些事情可以自己决定？哪些操作必须经过人的确认？任务什么时候算结束？结果又应该怎么评估？这些问题已经远远超过“怎么写 Prompt”本身了。它更像是在设计一个人的工作环境。

Prompt Engineering 之后，可能是 Workflow Design

所以我现在越来越觉得，Prompt Engineering 并不会消失，但它会逐渐变成 AI 协作中比较底层的一部分。更上层的能力可能是 Context Engineering，再往上则是 Workflow Design。

当一个 Agent 真正进入工作场景以后，你需要考虑的是整个系统：它如何理解任务，去哪里寻找信息，可以使用哪些工具，什么时候需要人的介入，执行完以后如何验证结果，以及这些经验能不能继续沉淀下来，让下一次任务做得更好。

这已经不是简单地“和 ChatGPT 聊天”了。某种程度上，我们开始学习的是：怎么管理一个数字员工，甚至怎么管理一支由人和 Agent 共同组成的团队。

这也是我自己最近做产品时非常明显的感受。以前我把 AI 当成一个工具。我先想好页面怎么设计、功能怎么拆、代码大概怎么实现，再把其中的一小部分工作交给 AI。现在我开始尝试把更完整的目标直接交出去。比如“把这个功能做出来，并自己验证”“研究几个竞品，最后给我一个产品决策建议”“看看现在这个流程还有哪些明显的问题”。

当 AI 可以自己拆任务、寻找信息、使用工具并验证结果时，它和人的协作关系已经开始发生变化。它不再只是一个等着被点击的工具，而越来越像一个能够独立负责某个 Workstream 的数字同事。

当 AI 越来越能干，人最重要的能力是什么？

最近我发现真正用 AI 产生价值的其实是已经有一个闭环的生意，然后用 AI 给自己赋能的人。而不是总想做一个 AI 工具去赋能别人的人。

因为 AI 最终要产生价值，需要是一个真正有价值的场景，有价值的问题，这些只有做业务才知道。

除了产生价值，人还可以在想象力等领域跑得更远，做出更有意思的东西。