Matt Van Horn 是 Every Inc 的工程师。三个月前他写了《Every Claude Code Hack I Know》，93 万阅读。上个月发了续篇，标题从 "Claude Code Hack" 升级成了 "Agentic Engineering Hack"。
这个关键词变化本身值得玩味。去年感恩节前后，大模型跨过一个能力门槛，"vibe coding"——把代码生成当玩具的心态开始失效，取而代之的是严肃的工程方法论。Van Horn 把经验系统化成可复用的套路，三个月连续交付了 last30days（27K stars）、Printing Press（4K+ stars）、Agent Cookie，还成了 Python、Go 等大型开源项目的重要贡献者。他说从高中后再没写出过任何人觉得有价值的东西——直到现在。
这不只是一个人的效率故事。它揭示了一整套正在形成的工程实践。
Plan First, Execute Later：翻转 80/20
整个体系的第一法则：任何有价值的想法，第一时间不是写代码，而是生成 plan.md。
灵感、Bug 报告、终端报错——截图、复制、粘贴，然后生成计划。不是"让我想想"，不是"先试一下"，是 plan，每一次。传统开发 80% 时间写代码、20% 规划。Agentic Engineering 完全翻转——思考沉淀在 plan 里，执行是机械动作。
Van Horn 用的工具叫 Compound Engineering，一个 Claude Code 插件。/ce-plan 命令会并行启动多个研究 agent：一个读你的代码库找模式，一个搜你过去的解决方案提炼经验，如果需要还会去查外部文档。然后汇总成结构化的 plan.md——问题描述、方案选择、涉及文件、验收标准，全部基于你自己的代码风格和历史习惯。不是泛泛的建议，是真正绑定在你项目上下文的规划。
💡 Plan 不是给人看的，是给 agent 的约束。有 plan 的 agent 会调研、承诺方案、写验收标准、检查是否达标；没有 plan 的 agent 会偷懒、走捷径、在 70% 的时候停下来。Van Horn 的比喻精准："Plan 是牵引绳。"
他的第二法则更反直觉：永远不要自己读 plan.md。
让 agent 写完 plan，看一眼标题，直接执行。不懂的地方在对话里追问——"为什么选这个方案？""用最简单的话解释。" 但不要坐下来读 300 行 markdown。那是 agent 的作业，不是你的。
想想看：你雇佣了一个能力强但偶尔偷懒的员工，你要做的是设定任务说明和验收标准，而不是站在他身后逐行检查计划。
Plan 的 Plan：双层规划破解模型偷懒
Van Horn 最意外的一个 hack：他最重要的商业洞察不是来自代码，而是 /ce-plan 的非代码用途。
处理复杂商业问题——比如和某位行业专家开两小时的会，手上有他的书和完整录音——他不让 agent 直接写分析报告，而是先写一个"plan for the plan"：你打算怎么读这本书、怎么挖掘这段录音、怎么把它们和我的业务问题整合成可用文档。agent 花 45 分钟写规划，然后他才执行。
💡 核心洞察：直接向 LLM 索要交付物，它会偷懒；先让它规划如何生产，再执行规划，它每次都做深度版本。
所有用 LLM 做深度工作的人都遇到过这个问题。模型倾向于给出"看起来足够好"的答案，而非"真正深入思考过"的答案。双层规划强制它先拆解任务再逐步执行，堵住了偷懒的捷径。
我自己的实践也验证了这一点。写论文解读时直接说"分析这篇论文"，往往得到表面摘要。先说"先读完全文，列出最关键的三个创新点，再对每个点分析其工程意义"，结果完全不同——思考路径被显式化之后，模型没有了偷懒的余地。
语音输入：这次真的不同
Van Horn 的语音工作流有个关键洞察：语音到 LLM 和语音到其他东西完全不同。传统语音识别要求高精度，因为接收方是人类，听错一个词就是听错一个词。但 LLM 有上下文理解能力，能猜出麦克风没录清的词——含糊地说、中途改口、句子没说完就跳到下一句，agent 都能跟上。
Mac 端他用 Monologue 或 Wispr Flow，把语音直接灌入当前聚焦的应用。手机端直接用苹果自带语音输入，因为接收方是 LLM，"乱七八糟"也够用。他还专门买了个鹅颈麦克风放桌上。
不过他自己也承认一个弱点：在开放办公环境下他就是用不了语音。 不想成为那个对着麦克风嘟囔、干扰同事的人。这份诚实让我对整套方法论更信任——没有哪个人文关怀缺位的效率达人能做出好产品。
中文场景的现实更复杂。普通话识别已经很好，但技术术语的中英混杂（"KV cache"、"MoE"、"RLHF"）、代码中的英文变量名，会让语音可用性打折扣。建议：口语化叙述和指令用语音，技术细节还是打字。
多 Tab 并行：人变成调度员
Van Horn 日常的工作画面：4 到 6 个终端标签页同时开着，每个是独立的 agent session。一个写 plan，一个执行另一个 plan，一个跑测试，一个修刚发现的 bug。tab A 的 agent 在并行研究时，他切到 tab B 执行已就绪的任务。等循环回来，tab A 已经完成在等着了。
💡 核心洞察：agent 时代，瓶颈不再是人的注意力，而是你能同时跑多少个 agent。 传统多任务是人在任务间快速切换，每次切换都有认知成本。agent 并行是每个 session 独立运行，人只负责验收和启动下一个。人的角色从执行者变成了调度员。
前提是 session 之间有足够的上下文独立性。Van Horn 用 plan.md 作为跨 session 的状态传递机制——一个 session 的输出是另一个 session 的 plan 输入，不需要人工中转。
安全红线：别被效率冲昏头
文章有一条让我后背发凉的设置：--dangerously-skip-permissions。他建议写进 shell 启动脚本，每个新终端标签直接进入无权限检查的 Claude Code。
能理解为什么——每次 agent 执行操作都要人工确认，确实严重影响工作流节奏。但这等于把整个代码库的 root 权限交给一个偶尔会产生幻觉的系统。Van Horn 能这么干，是因为他的项目都是个人项目或个人贡献到开源，炸了只炸自己的东西。
但如果你在团队环境、在生产代码库上做这件事，一次 agent 的"创造性理解"就可能带来灾难。折中方案是白名单机制：大部分操作自动执行，git push、rm、数据库操作等高危动作保留确认。效率损失大约 5%，避免的是不可逆的后果。
本土化：这套方法论的中国版
Van Horn 的体系建立在 Claude Code + Compound Engineering + Monologue 这套工具栈上。直接照搬到中文开发者场景，有几个摩擦点。
语言层面，英文 context 下 LLM 的推理能力强于中文，尤其在复杂技术讨论中。用中文和 agent 对话不是不行，但输入需要更结构化、更少歧义。
工具层面，Claude Code 需要 Anthropic API 访问，Compound Engineering 的插件生态是英文的，语音工具没有中文优化。思路可以复用，工具需要替换。
协作层面，Van Horn 的方法论高度个人化——一个人开 6 个 terminal、自己审批自己的 plan。放到有代码评审流程、权限管理、多人协作的大型项目中，需要一层"团队化"的抽象：plan 不再是一个人的思路，而是团队的共识文档。
本质
从 "Claude Code Hack" 到 "Agentic Engineering Hack"，不是修辞升级，是认知跨越。
前者暗示的是：我在用某个工具，发现了一些窍门。后者说的是：agent 不是工具，是一种新的工程范式。 人和 agent 的关系不是操作者和被操作者，而是规划者和执行者。plan.md 不是文档，是契约。终端不是写代码的地方，是调度 agent 的指挥台。
💡 Van Horn 三个月从"高中后再没交付过有价值的东西"到多个上万 star 项目的主要贡献者，靠的不是更努力地写代码，而是彻底改变了和计算资源之间的关系。在 agent 时代，瓶颈在人的思考深度，不在人的执行速度。