Codex 5.6中Skills设置是否多余

背景

在利用大型语言模型（如 OpenAI 的 Codex）辅助编程时，许多开发者习惯通过设置系统级提示词（skills）来约束模型的行为，例如定义项目整体开发规范、代码风格、依赖管理等。这类“skills”本质上是一种前置指令，旨在让模型在生成代码时遵循特定规则。然而，随着模型能力本身不断进化，部分社区成员开始质疑：是否还有必要为最新版本（如 Codex 5.6）手动配置这些 skills？多余的 skills 是否会消耗不必要的 token，甚至可能干扰模型原生能力，反而降低效果？这一讨论源自 LINUX DO 论坛中一篇题为“关于skills”的帖子，帖子正文直接提出了上述疑问，共有 7 位参与者（6 个不同用户）发表了看法。

核心内容

原文核心是一个问题和两个子问题：

1. 对于当前 Codex 的 5.6 版本，是否仍然需要设置一些项目整体开发规范的 skills？
   即，在最新模型版本中，开发者是否仍应像以前那样，通过额外提示词明确告知“项目使用 Python 3.10、遵循 PEP8、使用 FastAPI”等规范，还是说模型本身已经足够理解这些隐含约定？

2. 多余的 skills 是否会浪费 token，而且效果不一定有模型本身的能力好？
   这里包含两层担忧：

   • token 浪费：每个 skills 都占用上下文窗口的 token 配额，过多的 skills 会减少可用于实际代码生成或对话的 token 空间，增加成本或限制单次处理长度。
   • 效果反噬：人为添加的 skills 可能引入噪声或矛盾，干扰模型对任务真正的理解，导致模型放弃其原生最优推理路径，反而降低生成质量。换言之，模型自带的“隐式知识”可能比用户编写的显式规则更准确、更灵活。

帖子本身未提供具体结论，仅作为提问引发讨论，后续从“7 posts - 6 participants”可知有 6 位用户参与了回复，但原文未展示回复内容。因此，解读应严格限于这个提问本身。

关键要点

• 核心问题：Codex 5.6 是否仍需要开发者手动设置项目开发规范类的 skills？
• token 成本考量：多余的 skills 会占用有限的 token 窗口，可能导致后续生成内容被截断或增加 API 调用费用。
• 效果权衡：模型自身能力（原生推理、隐式知识）可能优于人为编写的 skills，过多 skills 可能适得其反。
• 适用场景：该问题隐含了“skills 并非越多越好”的假设，需要根据具体模型版本和任务复杂度判断是否值得引入。
• 讨论背景：该话题来自 LINUX DO 论坛 AI 板块，参与者均为技术用户，反映了一线开发者对提示词工程的现实反思。

意义与影响

这一讨论反映了提示词工程领域的一个重要趋势：随着模型能力持续提升，过去依赖的“人工注入规则”策略可能逐渐变得冗余甚至有害。Codex 5.6 作为更先进的版本，其训练数据中已经包含了大量编程规范、最佳实践和项目结构知识，模型可能已经学会在合适场景下自动应用这些规范。因此，盲目添加 skills 不仅浪费 token，还可能破坏模型对任务语境的整体把握。

从更广的视角看，这提示开发者需要重新评估提示词设计的“性价比”——不应再默认“加提示词总比不加好”，而应针对具体模型版本进行实验，找到 token 消耗与效果之间的最优平衡点。同时，这也推动 AI 工具链向更智能的方向演进：未来模型或许能自动识别开发者意图并动态调整行为，无需用户显式配置 skills。论坛中 6 位参与者的不同观点（尽管未公开）很可能涵盖了“继续使用 skills 以保持控制”与“信任模型原生能力”两种立场，这种分歧本身正是 AI 辅助开发从“手工调参”走向“自动智能”的缩影。