别过度设计提示词：工程师的Agent思维解锁指南

过去两年，Prompt Engineering 被包装成一门需要钻研的"新学科"——你得精确措辞、层层约束，才能让 Agent 听话。一位长期做 AI 工具开发的技术博主在视频中直接否定了这套叙事：问题不是工程师提示得不够工程化，而是过度工程化，把本来一句话能解决的事，做成了一套复杂系统。

真正稀缺的能力不是写更精巧的 Prompt，而是先退一步想清楚:哪些东西根本不需要"被做出来"，只需要"被问出来"。

从 XKCD 漫画说起：普通人不懂技术，工程师不懂 Agent

视频里引用了一则经典 XKCD 漫画：产品经理问工程师"用户拍照时，App 能不能判断他在不在国家公园里，顺便判断照片里有没有鸟？"工程师的回答是 GPS 查询"几小时搞定"，识别鸟类"需要一支研究团队干五年"——因为在那个年代，那等于要从零发明 AI。

这个笑点的当代意义在于它反转了。普通人低估技术复杂度，而今天的工程师走向另一个极端:习惯性地用代码思维拆解一切，以至于根本想不到可以直接问 Agent。博主说，他最近和一位刚参加完 Y Combinator 的创业者聊完，对方对"Agent 还能做这么多"感到震惊——这个认知解锁，很多人还没有经历第一次。

XKCD 是由 Randall Munroe 创作的一部长青网络漫画，以程序员、物理学家和极客文化为主要题材，常被用来精准吐槽技术圈对复杂度的误判。文中引用的那则漫画（原题 Tasks）诞生于 2010 年前后，当时计算机视觉尚处在需要专门研究团队攻坚的阶段，所以“识别鸟类”被工程师估成五年工作量。如今多模态模型已能直接看图回答这类问题，漫画的笑点因此反转：真正落伍的不是技术本身，而是工程师对“哪些事已经可以一句话问出来”的认知滞后。

那些你以为是功能的东西，其实只是一条信息

博主举了一个亲历案例。他和朋友审计 Agent 在本机执行的所有工具调用，发现 Claude 给 zsh 环境写的 bash 命令经常不兼容，导致错误率偏高。朋友顺势提出:真希望有个功能，能统计每个工具调用的耗时，找出最慢的命令来优化环境。

他的回答是:"我们早就有了，移动端也有。" 演示时他新建一个线程，直接对模型说——拆解本机所有工具调用，找出最慢的并给出优化建议。几分钟后，一份详细报告就生成了，其中显示某次 home 目录搜索跑了 41.7 分钟。

他的结论值得抄下来:很多被当成"功能"的东西，本质只是信息。如果信息能通过其他方式拿到，它就不该被做成按钮，而应该被暴露成可被提问的接口。

上下文可视化：一个被藏起来的按钮

同样地，他让 Agent 为当前线程的上下文窗口用量生成可视化。结果发现代理配置曾让每一次请求都携带 7 万 token 的冗余上下文——整整两个月没被察觉。而团队其实有一个上下文用量按钮，只是被藏在历史功能里。这件事反过来说明:在模型足够强的当下，手动管理上下文的优先级已经很低。

工具调用（tool call）是 Agent 与大模型交互的一种协议层机制：模型输出结构化的函数名与参数，由运行时执行后再把结果回填给模型继续推理。Claude、GPT 等模型在接入 shell、文件系统、浏览器等环境时，都通过这一层完成实际操作。所谓“统计每个工具调用的耗时”，在运行时日志里本就是一条现成的元数据，模型完全可以用脚本聚合它——这正是文章所说“信息早已存在，缺的只是提问接口”的技术根据。

反例：我自己也曾把简单问题做成复杂系统

博主坦承自己踩过坑。他一直在为 T3 Code 构思一个"运行看板"功能:列出所有任务、显示状态、让 Agent 批量重命名线程、关闭线程、合并 PR。他不断往上面加按钮，直到意识到——这些全部可以做成一个 meta 对话线程，用户直接说"把该合并的合并掉"就行。

他把这个教训概括成一个判断标准:如果你发现自己要支持"用户可能需要的所有路径"，说明你在做一个分支太多、漏洞太多的复杂功能。你不可能知道系统会怎么失败——如果你知道，你早就修好了。

T3 Triage：从数千行代码缩成 5 行代码 + 30 行 Markdown

最能说明问题的是他做的排障工具 npx t3 triage。最初的设想是一套复杂的分支流程:问一个问题、等用户回答、触发钩子进入下一阶段。写到一半他停下来，把整个流程写成一段超长的 Prompt 直接塞进 Claude Code 或 Codex——让模型自己按顺序追问故障现象、索要截图、阅读机器信息、克隆开源源码定位 Bug、检查上游是否已修复，最后在清理敏感信息后提交或复用 GitHub issue。

结果:复杂功能变成 5 行代码加 30 行 Markdown，效果还更好。他甚至放弃了"支持粘贴图片"的工程实现——直接让模型开口要求用户贴图就行。

MCP（Model Context Protocol）是 Anthropic 于 2024 年底提出的开放协议，用于把外部应用、数据源和工具以标准化方式暴露给 AI 客户端，可理解为“Agent 世界的 USB 接口”。文章所说的“把应用的接口通过 MCP 暴露出去”，意味着应用不必再为每个操作单独做 UI 按钮，而是把能力注册成原语，让任意 Agent 通过对话调用、组合。这与“功能 vs 信息”的论点一脉相承：暴露的是可组合的能力面，而非预设好的固定路径。

把"提问思维"带回工程实践

博主强调，这不是主张偷懒烧 token，而是相反:当你意识到有些事"本来不值得做"却对你此刻有独特价值，你会开始做更多这样的事——为排查一个 Bug 生成深度可视化，把自己的音乐收听历史与 Last.fm 数据合并成私人平台。

更进一层，是为 Agent 建基础设施:把应用的接口通过 MCP 暴露出去，让其他 Agent 能访问和控制;构建数据管道，让提示词能做到更多。他描述自己这一年的状态:写了五个 Rust 应用，对现代内存管理的理解比以往更深，因为他要为一个 Agent 运行在近乎免费算力上的未来做准备;他甚至在做自己的 JavaScript 运行时和自己的编译器。

"我现在比以往任何时候都更像一个工程师。"这句话是整段论述的核心——不是 AI 让人变笨，而是价值重心从"写代码"迁移到了"设计系统、暴露原语、搭建管道"。

最实用的建议:把邮箱接进 AI

视频结尾给出一个听起来很反直觉的建议:把邮箱接入 ChatGPT 一类的工具。博主有五个收件箱，四个需要主动盯，曾差点自己做邮件客户端。手受伤后被迫尝试多账号接入，结果查看收件箱的频率从每天十次降到一次左右——大部分时候直接问 Agent。配合能监控特定邮件的工具，可以做到:看到高额 AWS 账单邮件，追问成本为何上涨，再让 Agent 起多个线程去改代码降本。

这背后是一条完整的链路:邮件触发 → 分析 → 派发 Agent → 产出变更。他说，把这些管道接通之后，自己从未感觉如此像一个工程师。

关于"技能贬值"的阵痛期

博主没有回避负面情绪。他承认有个低谷期:那些你职业生涯里最在意的东西——语言、框架、细节——突然显得不再重要，会让人觉得自己在退化。他把这称为"绝望之谷"，但也给出了出口:一旦你触到 AI 做不到的边界，就会发现要建的东西比以往更多、更深、更需要巧思。

对仍在阵痛中的工程师，他的判断是:大多数人在曲线末端，而不是终点。值得建的问题变复杂了，能独立建成的复杂度也变高了——工程的总量和思考密度都在上升，只是形式变了。

他的最后一句话留给质疑者:你可以说我被 OpenAI 收买了，那确实更省事。但对真正热爱构建的人来说，现在能建的东西，从来没有这么多。