2026年3月，Matt Van Horn 在 X 平台发了一篇长文，标题很直接：《我所知道的每一个 Claude Code 技巧》。这篇帖子的浏览量最终停在 913,000 次，评论区吵成了一锅粥。
引爆争论的不是某个具体指令或配置参数，而是他在开头写下的一个说法：No IDE。他在描述自己的工作状态时提到，整个过程没打开过一次图形化编辑器，所有的开发操作都发生在终端命令行和一份叫做 plan.md 的文件里。有人看后觉得荒谬，问他代码阅读、调试、重构怎么办；也有资深工程师在下面留言说“这就是我一直在找的方式”。
两个月后，中文开发者 meng shao 将这套方法连同社区衍生的实践整理发布，冠以“智能体工程实战窍门全录”之名。它不是一个工具评测，而是一组围绕“Research → Plan → Work”循环展开的操作原则，背后是 22 条可复现或可讨论的具体技巧。
本文整理了网上讨论最多的一些AI工作流操作指南，从中我们或许可以得到一些共性的东西。
关上 IDE，你到底丢掉了什么
图形化 IDE 给开发者提供的不只是代码编辑区。它是一套完整的感官系统：语法高亮让你一眼看出变量和关键字的区别，实时错误提示在输入过程中就告诉你哪里出了问题，断点调试允许你逐行观察变量状态的变化，文件树和面包屑导航帮你在大项目里不迷路。这整套视觉反馈机制构成了一个默认假设：写代码的人需要亲眼看到每一行代码的状态。
终端命令行 + Markdown 文件的工作流把这层视觉保护壳拆掉了。你面前只剩一个闪烁的光标，和一份你亲手写下的计划文件。没有红色波浪线标出的错误，没有自动补全弹窗，没有文件树。Matt Van Horn 在推文中用了“No IDE”这个词，它的真正含义不是拒绝所有图形化工具，而是把开发的控制逻辑从“逐行手动确认”变成了“批量委派执行”。
Boris Cherny 是 Claude Code 的负责人，他在 2025 年底到 2026 年初通过 Threads 和其他渠道分享了他自己的 Claude Code 使用方式。他的做法是 CLI 优先，把 plan mode 作为所有任务的起点。这跟 IDE 的思维方式有一个本质区别：在传统 IDE 里，人是主动的代码生产者，AI 补全只是辅助；在计划驱动的终端工作流里，人是方向制定者和验收者，代码的生成和实现路径由 Agent 自主选择。
放弃 IDE 丢掉的是“亲手敲每一行代码”的安全感。这听起来像损失，但对于已经在大型项目中经历过大量上下文切换的开发者来说，这也是一种卸载。因为你不再需要在读代码、写代码、搜索文档、切换文件这些动作之间反复跳转。你只需要把一个需求讲清楚，然后把执行过程交给一组并行运转的 Agent。
meng shao 在总结中提出的框架是“人主导方向、智能体执行”，IDE 时代人既要主导方向又要执行细节，两个角色缠在一起。新工作流试图把这两个角色拆开，人只做前半段。
plan.md 不是文档，是一份契约
这套工作流出现最多的文件名就是 plan.md。它听起来像项目文档，但实际功能完全不同。
项目的 README 或者开发文档是给人读的，用来解释架构决定、记录接口约定、帮助新成员上手。plan.md 的主要读者不是人，是 Agent。它的结构围绕三个东西展开：问题定义、解决方案描述、Checkbox 形式的执行清单。meng shao 在推文中把这层关系讲得很直白：plan.md 的作用是“约束智能体不偷懒”。
LLM 在长会话中有一个已知问题，社区将其称为“上下文腐败”。当对话历史越来越长，模型对早期目标的注意力会自然衰减。它可能在中途忘记最初的需求边界，也可能偷懒跳过某些检查步骤。社区中一个名为“洁癖.skill”的项目专门针对这个问题，提供了自动整理会话文件、更新持久化记忆库的方法。它的核心判断是，Agent 的长期表现不取决于单次 Prompt 的质量，而取决于是否有一个稳定的外部记忆机制。
plan.md 就是这个外部记忆。它在文件系统上落盘，不随会话结束而消失。每一个新的 Agent 会话都可以从这份文件重新加载上下文，而不是依赖上一轮对话中已经衰减的聊天记录。
Compound Engineering 是支撑这套工作流的核心开源插件，由 Every Inc. 的 Kieran Klaassen 开发。它提供了一组命令行指令，其中
/ce:plan
可以根据开发者的输入自动生成 plan.md 的初稿。生成之后，开发者的工作是审查和修正：Agent 可能会对技术选型有错误的假设，可能会低估某个模块的复杂度，也可能完全误解业务逻辑。人在这时的介入不是微调代码，而是在计划文件中注入 Agent 不知道的领域知识，然后把修正后的计划交还给 Agent 执行。
这个设计与 Boris Cherny 在 Claude Code 使用原则里强调的一点高度一致：把人类专家的判断集中在计划审查这一个节点，而不是分散在执行的每一步。用他的话说，如果每一步都要人盯着确认，那跟手动写代码没有本质区别。
一份有效的 plan.md 不会很长。它通常包含清晰的验收条件，每个条件都可以对应到一个 Checkbox。这些 Checkbox 是给 Agent 看的执行锚点，也是给人看的验收标准。开发者在 Work 阶段完成后，不是去读代码，而是去检查这些 Checkbox 是否逐一打勾。
一个需求的三种形态：Research → Plan → Work
这套工作流最核心的骨架，是 Research、Plan、Work 三个阶段构成的一个闭环。它不复杂，但每一段的工具支持和人的介入方式有清晰的分工。
Research 阶段的目标是让 Agent 在动手之前先建立信息优势。常用的方式是使用
/ce:brainstorm
指令，或者加载特定的 Research 技能包。Matt Van Horn 开源了一个叫 last30days-skill 的技能，GitHub 星标数在 2026 年 3 月底已超过 10,000。它的功能是让 Agent 并行抓取 Reddit、X 平台、Hacker News 等社区在过去 30 天里与指定主题相关的内容，然后输出一份结构化的分析摘要。假设你要启动一个涉及新技术栈的项目，你的 Agent 可以在几分钟内拉回社区里关于这个技术栈的最新评价、已知的坑、推荐的替代方案，而不是让你手动打开十几个浏览器标签。
Research 完成后的产出不是最终答案，是信息输入。这些信息进入 Plan 阶段，成为生成 plan.md 的素材。
Plan 阶段使用
/ce:plan
指令。Agent 基于 Research 阶段的发现、开发者输入的初始需求、以及项目现有的代码上下文，生成一份 plan.md 草稿。Compound Engineering 的设计理念是 80% 的时间花在规划和审查上，20% 花在执行上。这个比例初看很激进，逻辑其实直接：一份写得清楚、边界明确、验收条件具体的计划，可以让执行阶段的返工成本降到最低。
开发者在 Plan 阶段要做的事情包括：纠正 Agent 对技术方案的错误假设、补入 Agent 不知道的业务限制、调整任务拆分粒度和执行顺序、在 Checkbox 里加入 Agent 容易跳过的边缘情况。这个审阅过程本身也是一种“外部记忆注入”，因为人在这时把那些在对话中很难自然出现的隐性知识写进了计划文件。
Work 阶段使用
/ce:work
指令。Agent 读取 plan.md，将任务拆分为子任务，派发给子 Agent 并行执行。Boris Cherny 曾分享过一个数字：使用这种 plan 驱动的工作流，他在一个月内产出了 259 个 PR。这个数字说明的不是代码质量，而是当执行阶段的决策权被下放给 Agent 之后，人的瓶颈不再在打字速度上。
三个阶段之间有一个容易被忽视的关键点：Research 和 Plan 阶段可以多次循环。如果 Agent 在 Plan 阶段暴露了信息缺口，可以随时切回 Research 模式补充。Work 阶段开始后如果发现计划有误，也可以回到 Plan 阶段修正。这个循环不是线性的瀑布流，是允许回退和调整的环。
六条能马上试起来的技巧
在目前已公开的信息中，以下六条技巧都有明确的出处和足够细节支撑一个开发者直接尝试。它们不是抽象原则，是具体到“打开终端敲什么”“把什么写进文件”“用哪个工具”的操作。
技巧一：有想法立刻生成计划，不要自己先在脑子里推演。
meng shao 在原帖中把这条放在很靠前的位置。他的逻辑是，人的大脑善于审阅，不善于凭空构建复杂逻辑的完整树形结构。开发者在接到一个新需求时，习惯性在脑子里反复推演实现路径，但这个过程效率极低，因为工作记忆的容量有限。正确的做法是在想法出现之后立刻让 Agent 生成第一版计划，哪怕它粗糙、有错误、需要大量修正。审阅一份有问题的计划，比从零开始写一份完美计划要轻松得多。
技巧二：自己不读计划，让 Agent 把计划总结成几句话。
长计划文件的阅读本身是一项目成本。Boris Cherny 在 22 条 Tips 中的一条是使用自然语言指令让 Agent 提供 TLDR，或者用“eli5”让它用最直白的方式解释计划的核心要点。如果你有 5 分钟时间审阅，把前 3 分钟交给 Agent 的摘要，后 2 分钟只检查你觉得有风险的部分。这条技巧的本质是把“阅读理解”这件事也委派出去，人只看自己必须看的内容。
技巧三：多终端并行。
Matt Van Horn 在推文中提到他会同时打开 4 个以上的终端窗口，让不同的 Agent 实例处理不同的子任务。一个在做前端页面，一个在写后端接口，一个在跑测试，一个在抓文档。这套做法把传统的单线程开发变成了多线程调度。代价是，你需要自己管理不同终端的输出和状态，没有图形化的工作台帮你统一监控。对于习惯在一个 IDE 窗口里掌握全局的开发者来说，刚开始会有“不知道哪边出了错”的焦虑感。
技巧四：用语音代替键盘输入复杂架构指令。
meng shao 提到使用 monologue 等语音工具进行输入。具体的做法是，面对一个需要长篇描述的系统设计思路，不是敲键盘逐字输入，而是用语音把整个思路讲出来，让语音转文本工具把内容灌入终端或计划文件。Matt Van Horn 把这条称为“Get Voice-Pilled”，他认为语音比打字更容易保持复杂架构思维的连贯性，因为说话的速度和逻辑流的自然展开节奏更匹配。这条技巧对中文开发者的实际效果目前还缺少足够反馈，monologue 的中文语音支持能力也待进一步确认。
技巧五：邮件触发异步任务。
Matt Van Horn 在 2026 年 4 月的一条推文中分享了一个具体场景：他在哄孩子睡觉时，通过 agentmail 工具给自己的 Claude Code 实例发了一封邮件，触发了远程代码构建任务。等孩子睡着后，构建已经跑完，结果在终端里等着他验收。这本质上是把开发行为从“必须坐在电脑前”的物理约束里解放出来，让 Agent 在后台持续工作。前提是你对 Agent 的信任程度足够高，愿意在看不到屏幕的情况下让它自主执行。
技巧六：把工具栈当成技能市场来用。
AgentSkills 等项目提供了一个核心理念：开发者不需要从零构建每一个 Agent 能力。文件管理、新闻监控、网页抓取这些通用能力已经有社区维护的技能包可以加载。在终端工作流里，加载一个新技能的操作量级接近于装一个插件，你只需要在配置里声明技能包的来源和参数，Agent 就能自动获取对应的工具调用能力。Claude Code Video Toolkit 作为社区实践的一例，为 CLI 环境增加了视频内容的理解能力，虽然应用场景还比较垂直，但它说明了终端 Agent 的能力边界可以通过技能包持续扩展。
这个流程什么时候会反噬你
这套工作流的反对声音并不少。综合社区讨论，问题主要集中在三个方向上。
第一个问题是适用人群的边界。Boris Cherny 的 22 条 Tips 本身就有隐含前提：使用者需要有足够的架构拆解能力和 Prompt 约束能力。能独立完成系统设计的人，知道“该让 Agent 做什么、不做什么”的边界在哪里。对于还需要 IDE 的错误提示、代码高亮和断点调试来理解代码逻辑的开发者来说，关掉图形化编辑器等于关掉了自己熟悉的信息获取通道。这不是能力高低的问题，是工作方式依赖的感知通道不同。新手开发者通过逐行调试来建立对程序运行过程的心智模型，这个学习过程在终端工作流里缺少替代方案。
第二个问题是风险集中。在传统 IDE 里，错误是在执行过程中逐渐暴露的：编译错误、类型不匹配、运行时异常。人有机会在每一个环节发现并修正问题。在计划驱动的工作流里，所有决策审查被压缩到 Plan 阶段这一个节点。如果人在这个节点的审查不够彻底，错误会在 Work 阶段被 Agent 忠实且高效地放大。等你发现的时候，可能已经有多个文件被错误逻辑污染。
第三个问题 Matt Van Horn 自己提过，他管它叫“AI Psychosis”。这个词指的不是 AI 出了问题，而是人出了问题：构建 Agent 循环本身会带来强烈的智力快感，类似于策略游戏中不断优化的正反馈。开发者可能沉迷于打磨 Agent 工作流本身，不断尝试新的技巧、加入新的子 Agent、优化 Plan 的结构，而忘记了一个基本问题：你到底在为用户交付什么价值。工具变成了目的，需求被放在了第二位。
这三个问题指向同一个结论：plan.md 驱动的终端工作流是为“清楚知道自己要什么”的人设计的效率放大器，不是为“还在摸索自己该做什么”的人设计的学习工具。它的适用边界不在于技术栈的选择，在于使用者的阶段。如果你是那个已经在纸上画出过完整系统架构的人，这套工作流能让你的执行速度快一个数量级。如果你还在通过动手写代码来理解问题本身，那 IDE 的视觉反馈体系是你暂时不该丢掉的拐杖。
目前这套工作流的核心组件包括运行环境层的 Claude Code CLI 或 Codex CLI、流程管理层的 Compound Engineering 插件、技能扩展层的 last30days-skill 和 agentmail 等项目。它们都在快速迭代中，指令格式、文件约定、插件体系存在变动的可能。现在入场的开发者需要接受一个事实：你踩的坑可能还没有社区答案，因为整条链路还处在早期实践阶段，远未达到“稳定工具链”的标准。但这恰好也是第一批趟路的人能建立认知优势的窗口期。
