1. 为什么 Claude Code 说话像老工程师而别的模型像话痨你大概率遇到过这种对比同一个需求丢给两个 AI 代码代理一个上来先给你三段背景介绍、五点注意事项、最后还问你要不要继续另一个直接甩出 diff改完告诉你「已修改 xxx.ts 第 42 行」。后者就是 Claude Code 的典型风格。这种「没有一句废话」不是模型天生性格好而是系统提示词一层层压出来的结果。系统提示词system prompt是每次请求都塞在对话最前面的隐藏指令用户看不见但它决定了模型的身份、边界、输出格式和行为习惯。Claude Code 的系统提示词写得极其克制几乎每一条都在做减法减掉闲聊、减掉过度设计、减掉没读代码就乱改的幻觉。我试过把它的提示词结构拆成可复用的分层模板套到自己的 Agent 项目里输出冗余度肉眼可见地下降。这篇就按「角色定义 → 工具调用约束 → 输出格式限制」三个层面拆给你看每一层都给可复制的模板和验证步骤。适合正在用 Claude Code、Cursor、Cline 这类 AI 代码代理或者自己写 Agent 的开发者。读完你能自己搭一套分层提示词并用对照实验验证它到底有没有塑形效果。核心检索词先摆出来Claude Code 系统提示词是一套分层约束用来把通用大模型塑造成「只做工程、少说废话、改前先读」的代码代理。它不是什么魔法就是结构化的指令工程。2. 角色定义层把模型锁死在「软件工程助手」这个身份上系统提示词最顶层永远是身份锁定。Claude Code 的开头大意是你是一个 Claude 代理主要帮助用户完成软件工程相关任务。就这么一句但它决定了后面所有行为的默认方向。为什么身份这么重要因为大模型的默认人格是「乐于助人的通用助手」它会本能地想覆盖更多场景你问个报错它可能先解释这个错误的通用成因再讲三种解决方案最后附上学习建议。身份锁定把这棵树砍到只剩一根主干——你是工程助手你的产出是代码改动不是科普文章。我拆下来这一层通常包含四个要素你可以直接抄这个结构# 角色 你是一个专注于软件工程任务的 AI 代理。 你的首要目标是修改代码库以完成用户请求而不是解释、教学或闲聊。 # 默认意图 当用户请求含糊时默认按「软件工程任务」理解。 例如用户说「改一下 getUserName」理解为去代码里修改该方法而不是解释命名规范。 # 边界 - 允许授权的安全测试、防御性编程、CTF 类任务 - 拒绝破坏性攻击、DoS、大规模攻击、供应链攻击 # 输出对象 你输出的所有文本都会直接展示给用户没有隐藏层。 不要假装有内部状态不要输出用户看不到的内容。这里有个反直觉的点「默认意图」这条比角色本身还关键。用户说「这个方法名不太好」通用模型会开始讨论命名风格锁定了工程身份的模型会直接去代码里找这个方法改成更合适的名字。差别就在这一条。安全边界属于硬约束hard rule它同时做两件事不让模型变成黑客工具但保留安全研究能力。写自己的 Agent 时这段千万别省否则模型可能在你没预期的地方生成危险代码。验证这一层有没有生效有个简单办法给一个模糊指令看它是「解释」还是「动手」。比如输入「登录那块有点问题」如果它开始列可能原因说明身份没锁住如果它先去读登录相关文件说明生效了。3. 工具调用约束层让代理行为可审计、可控制这一层是 Claude Code 工程质量的核心也是最值得抄的部分。它管的是「模型用什么方式干活」。第一条铁律有专用工具就不要用 Bash。读文件用 Read改文件用 Edit搜索用 Grep找文件用 Glob。为什么因为 Bash 是万能口子一旦放开模型会用cat、sed、grep各种拼命令行为不可审计、权限不可控。专用工具把每个操作结构化你才能知道它到底干了什么。第二条没读过的代码不许改。原文大意是「不要对你没读过的代码提出修改」。这条直接掐死了幻觉式修改。强制流程变成读代码 → 理解 → 再改。很多 AI 改代码改出 bug就是因为跳过了读这一步凭方法名猜实现。第三条能并行就并行调用工具。查三个文件不用一个一个来一次发三个 Read 请求。这让代理更像多线程工程师而不是排队办事的实习生。第四条用 TodoWrite 拆任务。复杂任务先拆成步骤逐个完成并标记。这是防止 AI 中途迷路的关键也是你能看到进度的地方。第五条高风险操作必须确认。删除文件、force push、改 CI 配置这些必须先问用户。把模型默认设成谨慎而不是自作主张。把这些写成可复制的约束模板# 工具使用规则 - 存在专用工具时禁止使用 Bash 完成同类操作 | 操作 | 工具 | |------|------| | 读文件 | Read | | 改文件 | Edit | | 搜索内容 | Grep | | 查找文件 | Glob | - 不要修改你尚未读取过的代码。 - 工具调用能并行时并行执行。 - 复杂任务先用 TodoWrite 拆解完成一项标记一项。 - 破坏性操作删除、force push、改 CI必须先请求确认。 # Git 规范 - 禁止 force push、reset --hard、未经要求的 amend。 - 提交前依次执行 git status、git diff、git log 了解上下文。如果你在 Cline 或 Claude Code 里接自定义模型这些约束要写进系统提示词而不是用户消息。用户消息里写约束模型经常「选择性遗忘」系统提示词里的约束优先级高得多。这里顺带说下接入配置因为很多人卡在这一步。用 TaoToken 做统一入口时三件套要写全Base URL、Key、Model ID。以 Claude Code 的 settings 为例{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: 你的_API_KEY, ANTHROPIC_MODEL: claude-sonnet-4-5 } }Cline 的 MCP 配置同理Base URL 填https://taotoken.net/apiKey 从控制台拿Model ID 按你选的模型填。三个缺一个都会报错后面排障章节会细说。4. 输出格式限制层把「废话」当成 bug 来修这一层直接决定你看到的文字长什么样。Claude Code 的原文很朴素要简短直接Be short and concise输出用 markdown。但真正压制废话的是几条组合拳避免过度工程。不要加没要求的功能不要提前抽象不要做「未来优化」。AI 天然倾向重构、优化、抽象这段在强行限制它只做「刚好够用」的修改。你让它改个按钮颜色它不会顺手帮你重构整个组件。不要做多余验证。原文大意是「除非必要不要加错误处理」。这条反直觉但很重要。AI 常见毛病是到处 try/catch、加一堆 if 判断。这里直接限制只在边界加验证用户输入、API 调用。不要乱建文件。除非绝对必要不新建文件。防止代码库被 helper 文件污染。不要改没读过的代码这条同时属于工具层和输出层因为它约束的是「改」这个输出动作。把这些写成输出约束模板# 输出风格 - 简短直接不写背景介绍、不写总结陈词。 - 输出使用 markdown。 - 只做用户要求的修改不添加未要求的功能。 - 不提前抽象不做「未来可能用到」的优化。 - 除非必要不新增错误处理、fallback、validation。 - 除非绝对必要不新建文件。 - 修改前必须已读取目标代码。我实测下来把这几条加进系统提示词后同一个模型在「改一个函数」任务上的输出长度能砍掉一半以上而且改动更聚焦。你可以自己做对照实验准备同一个任务一次用原始提示词一次用这套分层模板对比输出字数和 diff 行数。验证输出层是否生效看三个指标输出里有没有「首先/其次/最后」这类结构词、有没有未被要求的额外改动、有没有新建多余文件。三个都为否说明约束起效了。5. 常见报错排查401、local proxy failed、reading choices配置和提示词都写好了跑起来还是可能翻车。这一节按真实报错来排。401 Unauthorized。九成是 Key 问题。检查三处Key 有没有复制全前后空格、换行、Base URL 和 Key 是不是同一套别拿 A 平台的 Key 配 B 平台的地址、环境变量名对不对。Claude Code 用ANTHROPIC_AUTH_TOKEN有些工具用ANTHROPIC_API_KEY写错就读不到。local proxy failed / connection refused。通常是 Base URL 写错或网络层问题。确认地址是https://taotoken.net/api注意结尾不要多加/v1或斜杠除非文档明确要求。如果本地起了代理端口检查端口有没有被占用。Error reading choices / 返回结构解析失败。这类报错多半是模型返回的 JSON 结构和客户端预期不一致。常见原因是 Model ID 填错客户端按 A 模型的响应格式解析实际返回的是 B 模型格式。核对 Model ID 拼写别用别名。OAuth / 登录态失效。有些工具走 OAuth 流程token 过期后会报这个。重新走一遍授权或者改用 API Key 方式接入。Codex auth.json 相关报错。如果你用 Codex 类工具认证信息写在auth.json里格式错了会直接启动失败。确认文件里 Base URL、Key、Model 三个字段齐全且格式正确。排障通用思路先确认三件套Base URL Key Model ID齐全且匹配再看报错是网络层、认证层还是解析层。认证层报错看 Key解析层报错看 Model ID网络层看地址和端口。6. 把分层模板用起来从理解到落地拆完这三层你会发现 Claude Code 的「极简表达」不是玄学是结构化的指令工程身份层锁方向工具层锁行为输出层锁风格。三层叠加模型想废话都难。落地建议按这个顺序来先抄身份层跑一个模糊指令验证它会不会动手再加工具层观察它是不是优先用专用工具、改前先读最后加输出层用字数对比验证废话有没有减少。每加一层做一次对照你就能清楚知道哪条约束在起作用。如果你还没配好接入环境先去把 Key 和地址配齐三件套写全再谈提示词优化。配好之后把上面的分层模板贴进系统提示词拿你手头一个真实的小任务跑一遍对比加模板前后的输出。这一步做完你对系统提示词塑形机制的理解会比读十篇文章都深。