提示词写太多反而出错？先写清目标和验收
给 AI 写规则不是越多越好。新模型能自己决定的事变多了，旧的碎步骤可以撤掉一部分。这期讲三个检查点：哪些规则能删、什么必须说清（目标、验收、底线），以及什么时候才真该拆成多个子智能体。
这期讲了什么
- 「删掉八成系统提示词」不是通用比例：那是 Claude Code 团队针对特定模型（Opus 5 / Fable 5）和团队内部编码评测的说法，评测没测出明显退化，但没有说你自己写的提示词也能删八成
- 该删的是替模型思考的碎步骤：默认别写注释、别建文档这类旧时代的死规定，可以换成一句判断——「写像周围代码一样的代码」；需要的时候再加载技能说明，不必全塞在开头
- 该说清的只有两件事：要它达成什么、你怎么判断它达成了。验收要写成能检查的形式（通过/不通过、一个数字、一个它读得懂的格式），原文没提到的就标「未提及」，别让它猜
- 规则少 ≠ 底线能省：隐私、金额、对外发送、必须保留的格式、团队硬规定，一次讲明
- 什么时候才拆子智能体：任务能真正并行、背景塞太多效果明显变差、工具和指令互相冲突时；太小的活拆出去只会让成本和等待上涨。数量对不等于内容对，结果要让它贴命令输出、给截图，再抽几条回原文核
文字稿
一、规则太多了
你有没有过这种时候：让 AI 干件事，需求越写越长。先做这个，再做那个，别自己发挥，记得仔细想。结果它还是出错，你就再加一条。最近 Addy Osmani 写了篇文章，标题大意是「你可能给 Claude 写得太多了」。他的判断是：新模型能自己决定的事在变多，我们攒下来的规则，有些已经可以撤掉。今天就讲三件事：哪些能删，什么必须说清，什么时候才真该叫多个 AI 一起干。
文章里最显眼的例子，是 Claude Code 团队自己公布的说法：针对 Claude Opus 5 和 Claude Fable 5，他们删掉了 Claude Code 系统提示词八成以上，团队自己的编码评测没有测出明显退化。系统提示词可以理解成产品预装的一份工作说明书，用户平时看不到。这里要卡住口径：特定产品、特定模型、团队内部的编码评测。不等于你写的提示词也能删八成。
这些规则是怎么攒起来的？旧模型写出来的注释，不少时候是错的，为了防着最坏情况，旧说明书里就写死了几条：默认不写注释；除非用户要求，也别建计划、决策、分析类的文档。这些限制当时是需要的，但在一些情况下反而会限制正确做法。原文举的就是注释：有些很复杂的代码，恰恰需要多行注释说清楚；也可能用户自己就想要文档。他说，这种过硬的规定还会和系统提示词、技能、用户要求叠在一起，模型得先花力气判断该听谁，再决定怎么做。
他们后来把这类死规定，换成了一句要判断的话：写像周围代码一样的代码，注释密度、命名、风格都跟它保持一致。删掉的那八成里，有一部分是改成用的时候再加载：技能和工具的说明不再全塞在开头，需要了才取。具体占多少，原文没说。所以你也可以这么试：先删掉一批，看它到底漏了什么，只把真需要的加回来。
二、目标与验收
那具体怎么交代任务？作者的建议很朴素：一条提示词，把两件事说清。第一，你要它达成什么；第二，你怎么判断它达成了。说完让它自己干，别把步骤排成流水线。核心是给方向、留出判断空间，而不是替它把每一步都想好。
举个例子，假设你要整理三份周会记录。旧习惯是规定它先开哪个文件、用什么格式记笔记、先总结再提取。其实可以不说。你只要讲：我要一份能直接核对的决策和待办清单。至于怎么读、怎么排，可以交给它自己拿主意。这个例子是我编的示意，用来练怎么下任务，我们没做过对照实验。
接着把验收说具体。每条待办写清负责人、截止日期和它在原文里的位置；原文没提到，就标「未提及」，不要猜；最后单独列出还要人确认的问题。再进一步，可以把完成条件写成能检查的形式：通过或者不通过，或者一个明确的数字，再加一个它也读得懂的报告格式。条件合适的时候，它能自己对着这些要求一轮轮检查，少来问你；但真要自动检查，得看你的工具、任务本身，还有给了它什么权限。
要是你自己都没想清楚，还有个办法：让它反过来采访你，一直问到它能写出一份需求说明，然后开个新会话，用这份说明开始做。访谈里绕的弯，就不用带进执行。但规则少不等于重要条件能省。隐私、金额、对外发送、你必须保留的格式，还有团队的硬性规范，这些要一次讲明。该删的是替它思考的碎步骤，不是你的底线。
三、要不要拆分
文章还聊到子智能体。先理解成：一个 AI 把一部分活交给另一个 AI，再拿回结果。作者讲的是他在 Claude Code 里的经验：那边会由 Claude 自己判断要不要派，具体还看配置和授权，所以用户很少需要主动开口。真要主动提，留给独立的整块工作，比如长时间的审查、代码迁移。很小的事也拆出去，成本和等待都会往上走。
那到底值不值？作者的意思是：它能并行、能给第二意见，但不会自动让结果变聪明。以他的观察，自己搭一套 AI 流程时，一个主 AI 配上按需加载的技能，质量可能更好，成本和时间也常常更低。Anthropic 的配套文章也说，他们看过的企业案例里，单主 AI 配技能经常胜出；但它同时保留了子智能体的位置：任务背景塞得太多、效果明显变差的时候，任务能真正并行的时候，或者工具选择混乱、指令互相冲突的时候。所以也不能反过来听成单个 AI 永远更好。
真要拆，也别照着部门或者问题类型切成一堆小专家。他们的建议是按每个子任务需要的信息来分：每个子智能体拿一块不太依赖别处的活，回来交一个简短结论。比如各自去查不同的资料，几块能独立处理的功能，或者让一个没参与过这件事的 AI 单独复核。反过来，信息在几次交接里可能丢掉细节，越传越不像原来的样子。多叫几个 AI，并不会自动让答案更可靠。
四、跑长任务
任务长起来，验收就更要紧。作者说，如果一件事能用通过或不通过、或者一个数字来判断，报告格式又是它能读的，那它就能自己往下跑，你不用一直盯着。Claude Code 里还有个功能，每一轮之后让另一个模型检查条件满足没有。不过这里有个坑：数量对，不等于内容对。文件数够了、清单行数齐了，不代表每条都摘对了。所以它回来说「我做完了」，你都该让它把命令和输出贴出来，或者给张截图，再抽几条回原文核对。
他还提到自动模式：用分类器判断 AI 的每一步动作，不再每次都弹窗问人。作者自己写明，这不等于安全有保证，跟无脑点同意一样有风险。更有意思的是他们团队内部的做法：大部分阅读已经交给 AI，多数改动会先经过 Claude 审一遍、修一遍，再交给人看。顺序变了，但人看这一步还在；至于快了多少，原文没给数据。
还有个容易踩的坑。他说想合上笔记本时，可以用云端会话：任务跑在另一台机器上，用的是你仓库新拉的一份副本。这里要分清：只有已经提交、并且推送到远端的改动，才会出现在那份副本里；你本机还没提交的文件不会自己跟过去，本机才装好的环境也不会自动出现。所以开始之前，先确认哪些内容是可以上传的。同时开好几个会话也一样，前提是单个会话能自己跑完，否则你就是几个会话的调度员。
五、现在试试
想上手，就拿一件熟悉的小事试。第一句说目标：我要一份什么结果。第二句说标准：哪些内容、哪些出处必须有，哪里不许猜。第三句说验证：给我清单、原文位置，或者你检查的过程。比如还是那份周会记录，三句并成一句：整理成决策和待办清单，每条要有负责人、截止时间和原文位置，没写的标「未提及」，做完把清单和出处一起给我。跑完看它漏了什么，再补最必要的那一条。
最后收一下。这篇文章讲的是 Claude Code 和它那一代模型，别的产品、别的任务不一定一样。它真正有用的提醒是：别去数提示词写了多少字，去看目标清不清楚、结果能不能验收、该分的活有没有分开。作者也建议，每隔几个月回头审一次：我现在这套做法，是不是还在迁就一年前的模型。
常见问题
「删掉八成系统提示词」是不是说我也可以删八成的提示词？
不是。片中的八成是 Claude Code 团队针对特定模型（Opus 5 / Fable 5）和团队内部编码评测的说法，原文没说你自己写的提示词也能按同样比例删。能照着做的是方法：先删一批明显过时的死规定，看实际漏了什么，只把真需要的加回来。
一条提示词里到底该写什么？
两件事：要它达成什么目标，以及你怎么判断它达成了。验收最好写成能检查的形式——通过或不通过、一个明确的数字、一个它读得懂的报告格式。另外有一段不能省：隐私、金额、对外发送、必须保留的格式和团队硬规定，这些属于底线，不属于碎步骤。
什么时候该拆成多个子智能体？
任务能真正并行、单个任务背景塞太多导致效果明显变差、或者工具选择和指令互相冲突的时候。很小的活拆出去，只会让成本和等待上涨。真要拆，按每个子任务需要的信息来分，别照着部门或问题类型切成一堆小专家；交接越多，细节越容易丢。
本片配音为 AI 合成，画面由 AI 辅助制作。