不懂技术，小白怎么让 GPT-6 Astra 用起来更顺手？（文末附提示词）

我原工作是设计师，虽然我也能用AI去产出一些不错的成果，但我的缺点也很明显：

我不是程序员不是工程师，我不懂代码，什么AI的原理，什么工程什么agent，什么这些东西，我都不了解，也不熟悉那些术语，我只是给AI充了订阅费的普通用户而已，

如今大模型能力日新月异的情况下，到底普通人要怎么去真正的让自己与AI的协作更加流畅，表现更好？我会从我自己的经验出发，与大家分享，希望对大家有价值。

根据以往我的设计经验和思维方式，我喜欢清楚的结构、模块化的组织方式。比起一大段技术解释，我更容易通过一张结构图、一个目录树，或者直接看预览，理解正在发生什么。

使用 AI 时，我通常先说一个想法，看过结果后继续调整。反馈有时也很简单：“不好看”“优化一下”“这个动效再弱一点”。

我愿意学习，也愿意讨论。但我不希望每次用 AI，都要先研究怎么写一份专业的任务说明。

正逢模型更新，我把 GPT-6 Astra 的官方指南交给 Codex，希望它帮我看看，怎样调整规则才能让模型表现得更好。

它给了我一套挺完整的建议：全局规则、模型分类、任务模板、验收标准……

我看了一遍，回了一句：

看不懂，我希望我就是跟之前一样正常用，但是效果要有提升，怎么实现？

这句话，也成了我们后面整场讨论的起点。

一、模型变强了，为什么需要调整使用方式？

推荐这篇文章：

嵌入推文（联网查看）

它讨论了换模型后，旧提示词和 Skill 为什么也需要重新检查。读完后，我更想弄明白的是：这些建议落到我身上，能不能让我继续用平常说话的方式，和 AI 配合得更顺畅？

它提醒了一件很容易忽略的事：

• 我们过去为了纠正 AI，可能已经给它积累了很多要求。

• 做错一次，就补一条规则。

• 忘记检查，就加一句“必须检查”。

• 擅自修改过，就要求“修改前先问我”。

• 这些要求当时可能有用，但换了模型之后，未必仍然合适。

[未转换内容，参见原始 JSON]

OpenAI 的 Astra 指南也提到，它对指令更敏感。当额外信息可能改变结果时，它更可能提问；面对不清楚或互相冲突的规则，也可能提前停下来。它倾向于认真验证，小任务有时也会因此检查过多。

读到这里，我开始理解：

我看到的表现，同时受模型能力、任务信息、工具权限和已有规则影响。

模型本地有两个很重要的文件：

文章指出，Skill 的描述过宽、用途重叠，也可能让模型读入当前用不上的要求。它建议按任务逐步读取必要说明，而不是把所有流程一次塞进去。

对我这样的使用者，先知道这些内容会影响 AI 怎样做事就够了。可以让 AI 帮忙检查，再决定哪些需要调整。装了多少 Skill，不能直接说明一次任务会做得多好。

二、先让 AI 了解我的工作习惯是怎样的

我接着问它：

你能分析出来我过去的使用习惯吗？

它结合可访问的历史对话记录，整理出一些特点。我们又在对话里继续确认。

比如，我说“先分析”，就是希望先了解问题，不要立即修改。

可一旦我说“去改吧”，普通执行步骤就应该接着完成，不需要每一步都回来问。

我经常继续已有项目，希望保留之前确定的内容。只要求调整某个细节时，也不希望其他部分跟着大变样。

做到哪一步算完成，也需要说清楚。我能说清楚的，就直接告诉它；还说不清楚的，希望它结合当前项目，先提出一个具体的完成目标，让我判断是不是我要的。确定之后，普通执行步骤就继续做完。

设计任务里，完成约定的修改、检查并交付预览，可以是这一轮的终点。至于设计是否满意，还需要我看过再判断，不能因为文件已经生成，就默认我认可了效果。

还有一点很重要：我不熟悉技术，但愿意通过合作慢慢理解。

如果它要解释一个网站的结构，可以先让我看到：

网站
├─ 页面：用户访问的完整界面
├─ 共用组件：按钮、导航、卡片等重复使用的部分
├─ 内容：文章、项目介绍和产品资料
├─ 样式：颜色、字体和间距
└─ 素材：图片、图标、字体和视频

这只是结构示意，实际项目应该沿用适合它的组织方式。但这样的说明，能让我开始参与判断：内容在哪里改，视觉由哪里控制，改一个地方会不会影响其他页面。

我也可以逐渐认识“组件”这样的词。第一次出现时，配一句用途解释，后面再使用这个术语，我就容易理解多了。

不过，历史习惯也不能成为固定标签。某次要求动效克制，不代表以后所有作品都要保守。当前任务仍然需要单独判断。

三、当我说“不好看”的时候，AI 可以怎样帮助我？

这是我最关心的问题之一。

设计工作里，很多判断是在看到结果之后才变得清楚的。一开始说不出准确原因，并不罕见。

如果 AI 无法判断，我愿意让它继续追问，也愿意一起看参考。关键是，这个过程应该帮助我表达。

下面是一个沟通示意，并不是某个项目的实际修改记录：

这样，“不好看”就可以逐渐变成具体、可执行的要求。

我仍然需要参与选择，告诉它哪些接近、哪些不对。AI 则需要提供足够的依据，让选择更容易。

如果它每次都只问“你具体想要什么风格”，我还是面对原来的难题。如果它完全不问、自己大改一遍，也可能造成返工。

是否追问，应该取决于眼前的信息够不够。我也需要把能提供的参考、截图和实际结果交给它。没有看到作品，仅靠一句“不好看”，判断当然更容易偏。

对视觉问题，我更愿意把当前画面和参考图放在一起，指出喜欢哪里、哪里不对。等它修改后，再打开预览看效果，这比反复琢磨“高级一点”“简洁一点”更容易沟通。它能否直接打开页面、操作预览，要看当前应用提供了什么工具和权限；看不到的部分，就需要我补充截图或说明。

四、规则多了，也可能让合作变得更累

讨论到代码结构时，我提出过一个很直观的要求：不要把代码写成上千行的大文件，开头最好说清楚从哪里来、做什么、交给谁。

后来我们继续反思，发现这类要求也有副作用。

为了缩短文件，把一个完整功能拆成很多零碎部分，理解起来可能更困难。每个文件都写一大段说明，之后又不更新，旧注释也可能误导下一次修改。

类似的问题还包括：为了问清楚，每次小修改都变成需求访谈；为了可视化，简单问题也生成复杂图表。认真检查如果缺少停止条件，已经完成的任务也可能迟迟不能交付。

另外，使用时也要留意套餐额度，具体限制以当前账户显示为准。改一句文案、调整一处间距，不必每次都让 AI 重新检查整套规则、翻遍项目。把检查范围放在当前问题上，也能减少不必要的消耗。

所以，我们最后把规则分成了三层：

协作规则
├─ 必须守住
│  └─ 授权范围、已有成果、如实报告
├─ 默认采用
│  └─ 清楚的解释、适合的可视化、便于理解的结构
└─ 根据任务判断
   └─ 是否追问、是否调研、如何实现、检查多深

这里表示的是约束层次，不要求每个任务依次走一遍流程。

我也希望 AI 能指出我的方案有什么问题。它应该给出理由和替代建议，让我理解取舍，再作决定。

这里还有一个需要诚实说明的地方：我们这次整理后的全局规则，其实比原来更长。

我们补充了我的协作偏好，也收紧了一些含糊的要求。但规则写得更清楚，是否就会带来更好的结果，还需要观察。我不能因为文件修改成功，就说协作效率已经提高了。

五、让 Astra 帮你做一次检查

如果你也积累了不少 Skill、项目说明和工作规则，可以先让 AI 检查现状。

建议在你经常工作的 Codex 项目里使用下面这段提示词。它只能检查当前有权访问的文件和记录；如果环境里没有你的历史，它就需要通过简短交流了解你。

这段提示词会先分析、给草案，等你确认后再修改。如果你刚开始使用、没有旧规则，也不必为了检查先建立一堆文件。

请先了解我的工作方式，再检查当前真正生效的协作规则。
找出会造成反复确认、扩大修改范围或迟迟不交付的要求，指出具体来源和例子。
给我最重要的问题和小范围修改建议；无法确认的地方直接说明。
先分析，不修改文件，等我确认后再执行。

先用这段开始就可以。需要更细致的检查时，可以复制文末附录里的完整版。

拿到检查结果后，不必一次接受全部建议。可以先处理最明确的几项，尤其是自己经常遇到、能举出实际例子的问题。

如果 AI 只是说“规则太长，建议精简”，可以让它指出具体哪一条、在什么情况下影响了工作。修改应当有依据。

这段提示词也不会给模型增加新的能力，或替它获得原本没有的工具权限。它的用途很具体：帮助我找到协作要求里可以调整的部分。

六、根据自己的习惯继续使用

这次，我们已经把协作要求合并进全局规则，并核验了写入内容。

其中包括：普通执行细节自主决定，关键歧义再沟通；局部修改控制范围；完成要求和相关验证后就交付，不自行继续优化。

接下来，我会在真实任务里观察：已经说过的事情，会不会反复问？只改一点时，会不会又扩大范围？我说不清楚的地方，它能不能帮助我判断？

最后还要打开结果看看，页面能不能用，视觉是否符合预期。代码检查通过，只能证明它检查过的那部分。

我不需要一次掌握所有工程知识，也可以逐渐学会表达目标、提供参考和检查结果。遇到不理解的部分，就让 AI 用我能够理解的方式解释。

这份规则先用起来。哪些让我少纠正了，哪些又增加了等待和沟通负担，后面的工作会给出答案。

▲ 附录：完整检查提示词

需要进一步检查时，可以在常用的 Codex 项目里复制下面这段。它会先分析并给出修改草案，等你确认后再执行。

请帮我检查当前 AI 协作环境，让你更适合我的工作方式，同时避免过多规则限制判断和发挥。先分析，不修改文件。

1. 理解我的习惯
结合当前对话和必要的可访问记录，了解我的工作类型、专业背景、沟通偏好、反馈方式及授权边界。区分我明确表达的要求和你的推测，不把一次任务的选择当作长期偏好。缺少关键信息时，问少量具体问题。

2. 按需检查规则
识别当前模型、应用和实际生效的规则来源，检查相关 AGENTS.md、Skill、项目说明及长期偏好。先看清单与用途，再深入可能有问题的部分，不遍历所有文件和历史。无法访问或确认的内容如实说明。
区分实际生效的指令、参考材料和历史存档。遵循指令优先级，不把所有文件中的要求都视为同等约束。

3. 找出影响实际工作的内容
重点检查冲突、重复、过时要求、过宽的 Skill 触发条件、不适合我的默认方式，以及会造成反复确认、过度探索、扩大修改范围或迟迟不交付的规定。
结合适用情景判断，不只按长度或数量删减。保留有效的项目约束。涉及当前模型行为的判断，优先核对官方资料。

4. 给出简明结果和修改草案
第一轮只呈现最重要的问题。每项说明来源、相关原文、什么情景下会造成什么影响，以及建议如何调整。区分已观察到的问题和推测的风险，没有明确问题就直说，不凑问题数量。
优先做小范围修改，合并重复内容。保留授权边界、已有成果保护和如实报告要求；把沟通偏好写成默认方式，为具体实现保留判断空间。
区分规则问题与模型能力、工具权限、材料不足造成的问题，不承诺靠修改规则解决全部问题。

5. 等我确认后执行
此阶段不修改配置、不删除或安装 Skill、不写入长期记忆。确认后，只执行认可范围内的修改，保留可恢复的旧版本，并核对结果。
告诉我哪些变化已经完成，哪些改善还需要实际使用验证。满足当前要求后就交付，不继续自行追加优化。

🥳感谢看到这里，我是阿哲，欢迎关注我** @Formulasearc**h 我会持续分享 AI 实践教程。