提示词也是重构的对象：记录AI工作流的日志，找出该自动化的部分

我在自己工作中最信赖的一种打法是这样的：把经验提示「这里也许能改进」的东西当作起点，然后用真实数据来证明为什么以及怎么改进——而不是凭直觉就动手。直觉告诉你该往哪儿看，数据告诉你你是否看对了、又该如何应对。最近变了的一点是，那个「看」的活儿，如今LLM能以一种规模去做，而那种规模在过去会让这种证明本身贵得不值当。

在Google我正是这么干的。在Legal Content Policy and Standards团队担任Policy Lead时，我对哪些类型的法律删除案件在堆积成积压、哪些足够例行、可以自动化，心里有个直觉。我没有用经验去争辩，而是让LLM大规模地——数千件——对案件做分类与摘要，让数据要么印证这个假设，要么修正它。在Privacy Sandbox担任TPM时也是同一种形状：把「送去法务审查的文件中，哪些真正需要更深入的审视」这种感觉，变成一条让LLM逐份审阅并分类的流水线，好让昂贵的人力注意力落在要紧处。两次直觉都是起点，而非定论。是LLM让那个定论变得划算。

所以LayerX最近的一篇工程文章（作者前田洋平（Maeda Yōhei），LayerX「バクラク」报销与申请产品移动端的工程经理，笔名 id:myohei11）吸引了我，因为它把这同一招用在了一个我没想到要对准的目标上：AI工作流本身。整天和编码代理打交道的工程师，总在敲同样的话——「提交、推送、开个PR」「处理一下评审意见」「修一下挂掉的CI」。这感觉很重复，可「感觉」是决定该自动化什么的薄弱依据。于是他们把发给代理的每一条提示词都记录下来，定期分析日志，让真正反复出现的模式来告诉你该构建什么。让我印象最深的一句话是：提示词也会成为重构的对象。你给AI的指令，和代码一样，是需要观测、度量、并重塑为可复用部件的东西——把同一件事说上十几遍就是重复，而代码中的重复之所以是「坏味道」，正是因为它是一个信号：你找到了一个值得抽取的单元。

它是怎么运作的

机制刻意保持简朴。一个 UserPromptSubmit 钩子把每条提示词追加到本地的 prompts.jsonl——一行JSON，含时间戳、会话ID与正文，过滤掉过短的输入，并把文件设为仅所有者可读。日志会脱敏、仅存本地，并在7天后删除。（最后这一点不是事后补丁：提示词日志是「你问过些什么」的完整记录，所以隐私护栏是承重结构，而非可选项。）

日志之上跑着两条检测路径。一条在实时会话内工作，当同一操作再次出现时实时捕捉。另一条是每日定时任务，读取过去一周的提示词，按意图分组。两者同时运行，比单用其一漏得更少——实时路径看到对话内的集中爆发，批处理路径看到散落在数天里的同一请求。当某个模式越过一个很低的阈值——出现3次或以上——它就推送到Slack，附上模式摘要，以及一段可直接使用、用于构建对应Skill或命令的提示词。

有两个设计抉择，让它不止是个记录日志的小把戏。其一，每日分析用LLM做语义分组，而非对嵌入向量做聚类——于是「做个PR」「commit、push、建PR」「把改动提交了，再把PR提出来」都会折叠成同一个模式，因为无论措辞如何，它们意图相同。这恰恰是语言模型擅长、而僵硬的相似度指标不擅长的那种模糊、需要判断的分组——和当初给那些法律案件做分流时，正确工具是LLM而非关键词过滤器，是同一个道理。其二，自动化止于提议。它绝不自行创建或删除Skill；每一个都由人来批准。这就避免了半吊子规则在不知不觉中疯长——那正是让多数「自我改进型」自动化沦为负债的失败模式。

有意思的转折：用AI改进我们与AI协作的方式

让它不止是一手漂亮整理活的，是它矛头所向。那条浮现出新自动化的同一份日志，也浮现出了坏掉的自动化：如果人们反复调用某个已有的Skill，紧接着每次都再追加指令——「顺便把Notion页面也更新了」「也发到Slack」「你还没做完」——这些尾随的对话就是证据，说明这个Skill定义得不充分：完成标准不清晰，或缺了一个步骤。于是系统把矛头转向了自己，一个飞轮出现了：更好的度量浮现出更好的自动化，而后者又磨利了那个去寻找下一个的系统本身。

正是这个飞轮，让我觉得目标比手法更重要。代理式编码正在成为软件工程的默认工作模式——这就让「一个人和一个代理究竟如何互动」成了一个崭新、且基本未被度量的改进面。多数团队在这件事上还是摸黑前行。这里报告的成果故意不抢眼——在691次出现中识别出29个模式，其中22个（76%）被转化为Skill或命令，消除了652次重复提示词；仅「提交→推送→PR」这一循环，在变成一个 /ship 命令之前就出现了94次——而这正是要点。它们是那种不数就看不见的、枯燥而高频的杂活，而如今去数它，已经很便宜了。

频率是信号，杠杆才是判据

有两点保留，让我对它保持清醒。第一，频率不等于重要性。某件事发生得多，并不意味着它值得抽象——把工程师从敲几个字里解救出来，本身没什么真价值。价值在于一整个流程变得自动化、可重复、可扩展；次数只告诉你该往哪儿找它，而不是你已经找到了。第二是成本：提示词日志是你现在必须治理的数据，提示词只捕捉了工作流的一个切面，而一堆边际效用的Skill堆起来，会把环境塞到代理分不清该用哪一个。这些都不致命，但确是实打实的技术债，也正是人工审批这道闸门不可省略的原因。

换句话说，判断仍留在它该在的地方——而最大的回报，并不在某一条被自动化的工作流。它在于提升人与AI互动本身的效率，因为那东西如今正坐在几乎所有开发的关键路径上。把那一段提速，它下游的一切都随之提速。「这件事很重复」的直觉，依旧只是个直觉；新鲜的是，去证明它、并据此行动，已经从一个研究项目降格成了一种日常习惯。我也打算开始记录我自己的那一份。