--- title: "思远的｜清醒时刻 EP01：AI 越聪明，越暴露你不会管理" canonical: "https://siyuanailab.com/articles/qingxing-shike-ep01-ai-yue-congming-yue-baolu-ni-buhui-guanli/" dateModified: "2026-06-15" datePublished: "2026-06-15" author: "思远" --- [返回文章](https://siyuanailab.com/articles) 清醒时刻 · 思远 # 思远的｜清醒时刻 EP01：AI 越聪明，越暴露你不会管理 从带实习生的经验出发，说明 AI 不是不聪明，而是任务书太模糊。真正重要的是把目标、交付物和验收标准说清楚。 2026/6/15 8 分钟 EP01 > **清醒时刻** 是我记录认知碎片的专栏。 每一篇都来自一个真实瞬间，以及从瞬间里长出来的判断。 > > > > 这是第 EP01 篇。 前两天读了一篇讲校招的文章：成长快的实习生，共同点不是聪明，而是实习生A和B的区别，俩人都很聪明，但是B区别与A留下的原因就是向管理者时时刻刻在确认 「任务边界清单」： 目标：一份调研报告，领导到底要看的是什么？ 交付物：这份调研报告的侧重点，简要的还是详细的，重点分析的板块，交付的形态是ppt还是文字 验收标准：领导看完以后反馈，不满，复盘以后自己记录了领导的验收标准 我看完的第一反应是，这哪是带人的经验，这分明是用 AI 的说明书。 说白了，所有工作，靠的都是同一份规则。自己做、带应届生、调用 AI Agent，到最后拼的都不是执行者多聪明，而是在第一步你把任务描述得多清楚，我们对这件事完成的目标多么明确。 AI 越厉害，这一点越明显。过去值钱的，是你亲手能做出什么；未来值钱的，是你能把多少复杂任务封装成别人或 AI 能独立执行的一份边界清单。带实习生和用 AI，练的是同一套本事。 ## AI 不笨，是你的任务书太模糊 大多数人用 AI 翻车，第一反应是模型不行。但把同样的问题丢给 Claude、Kimi、Gemini，结果往往差不多烂。真正变量是你怎么描述问题。 想象两个实习生。 A 收到：「写个方案。」 B 收到：「给我们的老客户写一封续约提醒邮件，重点突出现有签约产品新功能的优势，未来的展望，语气专业但不生硬，200 字以内，最后给两个版本：一个直接型，一个铺垫型。」 A 会交上一坨你重写三稿才能用的东西；B 大概率第一版改改就能用。 AI 也一样。模型之间的差异，远没有「提示词清楚 vs 不清楚」之间的差异大。 这个差距在 Anthropic 的 Agent 工程指南里被总结得很直接：Agent 的能力上限通常不在模型，而在工程——工具描述清不清楚、Context 有没有被污染、有没有评测覆盖。用 Claude 4.8 Opus 配烂工程，往往打不过 Claude 4.5 Haiku 配好工程。提示词工程的核心不是工程，是把任务边界先写清楚。 ## 任务边界不是「告诉它做什么」，而是「让它能独立验收」 一份写清楚的任务边界，至少回答三个问题：解决谁的什么问题、最后给我什么格式、什么算过。 没有目标，AI 会默认给最泛的答案。交付物格式也关键，同一份调研分析，你要PDF版本和要一份 PPT ，得到的信息密度完全不同；要邮件正文和要微信话术，语气和结构也完全不同。 原文文件、分析结论、可发布文案，本质上是三件事。 验收标准更不用说了——可用、准确、符合品牌语气、不超过 200 字，都是标准。 但大多数人只给了第一层，甚至第一层也是模糊的。AI 拿到这种任务书，像个没头苍蝇，你的时间就全耗在「不对，再改」「还是不对」的循环里。既消磨了时间和Tokens，也在不断消耗你对AI的耐心。 任务边界不是单向命令，而是让执行者能自己验收。实习生拿到清单，交稿前自己对照检查；AI Agent 拿到验收标准，循环里自己判断「任务是否完成」。边界越清晰，你要介入的地方就越少。 「Agent = LLM + 工具 + 循环」这个公式其实缺了一半。让 Agent 稳定干活的，是藏在 Prompt、工具定义和退出条件里的边界系统。没有边界，循环就是死循环；没有验收标准，Agent 永远觉得自己做完了。 ## 人机协作的底层协议：共享心智模型 2025 年有一篇讲 Human-AI Teaming 的综述，把这个问题抬到了团队动力学的高度。作者借用了团队情境意识的概念：人和 AI 要组成有效团队，得对目标、角色、能力边界有一致理解，才能预测彼此下一步会干嘛。这也是我自己一直没有跟风上Agent团队的原因，单一任务或者工作流的任务边界定义不清晰，反而调用多个Agent进行讨论只会增加管理负担。 这里有两个互补的东西：**角色明确性**和**角色流动性**。角色明确，是每个人、每个 AI 都清楚自己该干嘛；角色流动，是环境变了可以重新分配任务。两者缺一不可。 放到管理场景里，这意味着你不能只对 AI 说「你负责写」，而得说明「你负责写初稿，我负责改方向，校对交给另一个 Skill」。带实习生也一样，你不能只说「你去调研」，而得说明「你负责收集 10 个竞品案例，我负责判断哪个值得跟进，你再把值得跟进的写成一页纸摘要」。 很多团队在人机协作上出问题，不是因为 AI 不够强，是因为角色边界没有显式定义。人类默认 AI 会「看着办」，AI 默认人类会「兜底」。两个默认一叠加，就是互相甩锅、反复返工。 一个典型场景是「你帮我看看这份报告」。这句话同时模糊了目标（看出什么）、交付物（批注？重写？摘要？）、验收标准（问题找全了就算过，还是改完才算过）。实习生听到后往往先交一版试探；AI 听到后则会笼统地夸一通，因为它没被赋予「批评者」的角色。问题不在执行者，在指令本身没有完成角色指定。 ## 从口头约定到工程契约：SDD 与面向 AI 的 PRD 任务边界从「说清楚」升级到「可执行、可校验」，就进入了工程领域。 Spec 驱动开发（SDD）把这事标准化：让 Agent 写代码之前，先让它写出清晰的产品规格和技术规格，实现后再校验代码是不是符合规格。warpdotdev 的 common-skills 把它拆成三个 Skills：`/write-product-spec`、`/write-tech-spec`、`/validate-changes-match-specs`。 开源项目 cc-sdd 更进一步，把 Spec 当成系统各部分之间的契约，而不是交给 Agent 的主命令文档。它的设计哲学很锋利：“Boundaries are not overhead. They are what lets you move freely inside while protecting the outside.” 边界不是 overhead，而是让你在内部自由移动的同时保护外部不被破坏。 这和传统「一句话需求 → Agent 直接开写」的模式不一样。后者的问题不是慢，是需求理解偏差、上下文分散、实现结果与目标偏离。SDD 通过强制生成规格文档，把「想做什么」和「怎么做」先固化下来。 SDD 回答「怎么做」，面向 AI 的 PRD 回答「做什么」。人喜欢的 PRD 和 AI 能有效执行的 PRD 不是同一种文档。人类 PRD 可以对齐团队认知、允许一定弹性；AI PRD 必须精确、无歧义、约束显式列出、验收可自动测试。它的核心作用是降低从人类想法到 Agent 执行的转换成本。 对于非程序员管理者，这两个框架有一个共同启示：把口头指令升级成可版本化的契约。不是「你去做一下」，而是「目标 X，交付物 Y，验收标准 Z，边界条件 W」。 这一步增加了前期投入，但买来了「异步协作」的能力。任务边界写成契约，执行者可以在你不参与的情况下推进，你只在关键判断点介入。无论是人类团队还是 AI 团队，规模化都是把同步沟通变成异步契约。 ## 混乱不是 bug，是迭代的燃料 任务书不可能一次写完美。实习生做着做着会发现信息缺了、假设错了；AI 协作里，第一轮输出不好也是常态。好的管理者不是直接给答案，而是把这次混乱写成一条规则。 AI 协作里，这条规则就是 Skill。 第一轮输出不好，不是模型废了，是你的边界还需要补。把「这里要加品牌语气」「这里要排除旧数据」写成一条指令，下次调用同一个 Skill 时就不会再犯。Skill 提炼本质上就是把一次有效协作，压缩成可复用的岗位培训手册。 技能提炼（Skill Distillation）的完整流程是：专家或强模型执行复杂任务 → 反思层记录关键判断点和失败模式 → 结构化为 SKILL.md → 弱模型按 SKILL.md 执行并对比结果 → 迭代修正直到输出可接受。 一个高质量的 SKILL.md 至少包含：触发条件、输入规范、处理步骤、判断节点、输出标准、边界条件、失败模式。它不是一次性的 prompt 模板，而是持续迭代的知识资产。Opus 能做的事，可以通过 Skill 让 Sonnet 达到 70%-85% 的水平——能力从「会做」转移到了「可传」。 用 AI 真正的成本不是 tokens，是清晰度。你越舍不得花时间在前期定义上，后期越要付利息。我把这个利息叫做「清晰度债务」：每一次模糊的指令，都会以返工、重写、对齐会议的形式复利增长。 举个例子：你让 AI「优化一下官网文案」。它交了一版，你觉得「差点感觉」，让它再改；它又交一版，你觉得「还是太正式」；第三版你说「能不能像对朋友说话」。三轮下来，你花了 30 分钟在对话里，而真正的成本不是这 30 分钟，而是这三次返工本可以用一句「目标读者是 30 岁左右的 B2B 决策者，语气像朋友聊天但保持专业，禁用形容词堆砌」在第一轮就避免。清晰度债务的可怕之处不是单次损失大，而是它会在每一次人机协作中重复发生。 ## 今天就能试的最简单解决方案： 下次打开 AI 对话框前，先别打字。用 30 秒写一行： 「我要解决 [谁] 的 [什么问题]，输出 [格式]，验收标准是 [具体条件]，边界是 [不做的事]。」 把它贴在对话最前面，再让 AI 开始。 如果第一版还不对，不要急着换模型，改这一行。绝大多数情况下，模型间的差异小于任务描述清晰度的差异。 再进一步：把这一行存成你第一个 SKILL.md。每次同类任务都调用它，记录 AI 在哪一步犯错，逐步补全边界条件。三个月后，你会得到一份真正属于你的「岗位说明书」——它既能让实习生更快上手，也能让 AI 更稳定地产出。 如果愿意多花 10 分钟，可以把这个模板升级一下： - **背景与约束**：这件事的前因、已有素材、绝对不能踩的雷区。 - **任务与交付**：具体做什么、输出什么格式、长度或范围限制。 - **验收与升级**：通过标准是什么、什么情况下必须停下来问人、常见失败模式有哪些。 第一段保证 AI 不走偏，第二段保证输出可用，第三段保证它知道何时该求助。一个能独立验收、也知道何时不该独立的 Agent，才是真正能用的 Agent。 AI 的智商不会突然变高，但你的任务书可以。 未来值钱的，不是你会不会用 AI，而是你能不能先把事说清楚。能定义清晰边界的人，AI 和年轻人都会变得更好用；不能定义边界的人，哪怕用最贵的模型、招最聪明的实习生，也只会陷在无尽的返工循环里。 --- **如果这篇说到你了，转发给那个还在怪 AI 不够聪明的人。** --- *本文 AI 辅助说明* 观点与判断：Amos 思远｜文本协作：Claude Code｜排版与配图：Codex ｜LLM支持：Kimi2.7 GPT5.5 --- ## 术语解释 - **任务边界清单**：把任务说清楚的一张小纸条，包含要解决什么问题、最后要什么格式、怎么算过关。 - **Spec 驱动开发（SDD）**：先让 AI 写出产品规格，再让它按规格写代码，最后检查代码是否符合规格。 - **Skill 提炼**：把一次成功的 AI 协作经验，写成一份可复用的操作手册，让便宜模型也能做出接近贵模型的效果。 - **面向 AI 的 PRD**：给 AI 看的产品需求文档，比给人看的更精确、更少歧义。 - **Agent**：能自己调用工具、自己判断任务是否完成的 AI。 - **共享心智模型**：人和 AI 对目标、角色、能力边界有共同理解，才能好好协作。 - **Human-AI Teaming**：研究人和 AI 怎么组成有效团队的学术领域。 - **cc-sdd**：一个开源的 Spec 驱动开发框架，帮 AI 编程 Agent 按规格写代码。 - **Anthropic《Building Effective Agents》**：Claude 母公司写的官方指南，讲怎么让 AI Agent 真正好用。