昨晚我又翻出一份自己攒了很久的 Agent 系统提示词，足足几百行。里面有角色设定、代码风格、报错处理、输出格式，还有一堆当年被模型逼出来的“你必须”。
我现在看它的第一反应是：服了，这东西可能有一半是在给旧模型擦屁股。
这波讨论的引子很直接：有人在 Fable5 基准里，把 Claude Code 的系统提示词砍掉约 80%，性能没有跟着掉。这个结果我还没自己复测，不能拿来当万能结论；但它戳中了我一直有的体感：模型够强以后，长提示词未必是护栏，也可能是手刹。
提示词工程没失效，失效的是把 Prompt 当咒语的那套执念。
我以前为什么爱堆规则
早一点的模型很容易跑偏。你不反复说“先读仓库”“不要臆测 API”“修改后给测试命令”，它就可能一本正经地编一套出来。
于是我会继续加规则：遇到 TypeScript 报错怎么做、不要改哪些目录、回答控制在多少字、输出前检查什么。每次翻车补一条，最后 Prompt 长得像公司入职手册。
问题是，Claude Code、Codex 这一档模型的推理和指令遵循上来后，它们已经能理解很多默认职业常识。你还把每一步掰开揉碎写死，模型反而会忙着满足字面约束，没空判断真正该怎么解决问题。
更烦的是规则之间会打架。比如一边要求“改动最小”，一边要求“补齐所有边界处理”；一边要求“不要问问题”，一边又要求“不确定必须确认”。人看着都头大，模型更容易挑错优先级。
我现在先删什么
我不会一把梭删干净。生产工作流里，权限、发布、数据删除这些硬边界必须写清楚，模型强不代表它该替你做风险决策。
但下面这几类，我会优先祛魅：
- “你是一位拥有十年经验的全栈架构师”这类角色卡。任务、仓库上下文和验收标准，通常比人设有用。
- 把显而易见的开发流程写成十几条重复禁令。能由工具、lint、测试兜底的，别全压在自然语言上。
- 为了教模型格式而塞很多 Few-shot 示例。强模型很容易过度模仿示例，把旧方案当唯一方案。
我更愿意把“给它看三段范例”改成“明确输入、约束和输出契约”。例如让 Agent 改接口时，我会写清字段兼容要求、失败条件、相关测试位置；至于它内部先查哪几个文件、怎么组织思路，少管一点。
真正该加码的是验收
说白了，过程提示词写得再漂亮，都不如一个能执行的结果检查。
让 Claude Code 或 Codex 修 bug，我现在更关注的是：复现命令是什么、预期行为是什么、改完跑哪些测试、哪些文件不准碰。能给测试就给测试，能给 schema 就给 schema，能让 CI 判定就别让我肉眼判定。
我会按这个顺序改一份现有 Prompt：
- 把所有规则按“安全边界、任务事实、写作偏好”分三类。
- 保留安全边界，例如不可执行生产删除、不可提交密钥、不可越过人工审批。
- 删掉重复的人设、客套话和模型本就能理解的常识，每次删一组后用同一批任务回归。
- 把删掉的过程要求，尽量换成测试命令、lint、类型检查、接口契约或验收清单。
- 记录成功率、返工次数、Token 和耗时，别只凭一次“它答得挺聪明”就宣布胜利。
这里最容易翻车的一点是：把“少提示”理解成“不给上下文”。仓库目标、现有约定、报错日志、接口限制，这些不是废话，反而是 Agent 干活的燃料。
该删的是替模型思考的碎碎念，不是业务事实和风险边界。
我站“精简但不裸奔”这边。强模型正在把开发者从调咒语里解放出来，但下一步不是躺平，而是把精力挪到任务拆解、工具链和结果验证上。
手里有一份祖传系统提示词的，可以挑一个低风险仓库砍掉三分之一，拿同一组 issue 跑一遍。效果没掉，就别再让那几百行 Token 每次陪跑了；效果掉了，再把真正有用的约束加回来。
说白了，后面要是真把 Claude Code / 多模型接到日常工作流里，我更懒得每家单独折腾 Key；会优先走统一接入，少踩限速和换号的坑。想看怎么接可以瞄一眼 code80.ai。
原文链接：Linux.do
评论前必须登录！
立即登录 注册