昨晚我又翻到一套团队 Prompt：角色背景三百多字，编码规范几十条，输出格式套了三层，最后还塞了 5 个 Few-shot。
我第一反应不是“专业”，而是肉疼。Claude Code 这类强模型每次开工都要先吞一大段祖传前缀，Token 花了，模型还可能被互相打架的规则带偏，属实有点离谱。
最近有个值得盯住的信号：在 Fable5 基准里，有测试把 Claude Code 的系统提示词砍掉约 80%，性能没有随之掉下去。这个结论我还没拿同一套任务完整复测，所以不装成一手实测；但它戳中了我这阵子的真实体感：很多 Prompt 工程技巧，保质期可能比我们想得短。
强模型不是不需要提示词，而是不需要一堆替你思考的废话。
以前补能力，现在容易变噪音
早些模型上下文短、指令遵循飘，你得反复提醒它“你是资深工程师”“先分析再行动”“不要编造”“严格按格式输出”。这些补丁当时有用，我也写过不少。
但 Claude 3.5 Sonnet、Claude Code、Codex 这一路模型，已经内化了不少职业场景。你还把它当一个必须逐字操控的表单机，结果常常是：任务目标只占两句，限制条件占两屏；它在解决规则冲突，不是在解决代码问题。
我现在更愿意把 Agent 当同事。你不会对同事说八遍“请保持专业”，你会说清楚仓库在哪、问题怎么复现、哪些文件不能碰、最后用什么命令验收。
这几个信息，才是能让它干活的硬钉子。
Few-shot 也别当护身符
Few-shot 是另一个容易上头的地方。我以前为了让模型生成统一的接口层，恨不得把三四份历史代码全贴进去。后来发现，强模型有时会过度模仿例子，把示例里的旧命名、旧依赖甚至旧毛病一起继承下来。
如果你想要稳定输出，我会优先给结构化约束：输入字段、输出 schema、边界条件、不能破坏的接口，再配一两个必要的反例。只有任务风格极其具体，比如迁移遗留 DSL、复刻内部代码生成格式，我才加完整示例。
说白了，示例应该是校准器，不该变成拐杖。
我会怎么改现有工作流
别一上来把团队 Prompt 全删了。生产里的规则往往还绑着权限、合规和流程，删错了会翻车。我会挑一个低风险任务，做一次很朴素的 A/B。
- 保留任务目标、仓库上下文、不可触碰范围和验收命令。
- 删掉角色扮演、重复的礼貌指令、彼此重叠的编码口号。
- 把长篇“应该如何思考”的要求，改成可执行的验收条件，例如“补测试并运行 npm test”。
- 同一任务分别跑精简版和原版，记录 Token、耗时、首轮通过率与人工返工次数。
- 只有精简版连续几轮不掉质量，再把它沉淀为团队默认模板。
我尤其建议把预算从“写更长的系统提示词”，挪到“让 Agent 跑测试、做 diff 审查、调用 lint 和类型检查”。过程指令再漂亮，也不如一个失败就能拦住它的验证器。
我站精简这一边，但不站无约束。模型能力上来后，Prompt 工程的重心不是消失，而是从写咒语，换成定义任务边界、接入可靠工具、验证最终结果。
你现在手里那段 2000 Token 的系统提示词，先别急着供起来。拿真实任务砍掉一半跑跑看，能省下来的可能不只是 Token，还有一堆看似严谨、实际拖后腿的规则。
说白了，后面要是真把 Claude Code / 多模型接到日常工作流里，我更懒得每家单独折腾 Key；会优先走统一接入，少踩限速和换号的坑。想看怎么接可以瞄一眼 code80.ai。
原文链接：Linux.do
评论前必须登录！
立即登录 注册