想象一下，你给AI提了一个修改意见，它改完这次就忘了。下次遇到类似问题，它可能再犯一遍同样的错。这不是个例，而是所有对话式智能体的通病——反馈是易逝的。Warp团队在Claude平台上做了一件反常识的事：他们把人类反馈变成了可合并、可复用的技能文件，让Agent真正拥有了自我改进的循环。这场实践的核心，是两个文件型技能，一个叫基础技能，一个叫改进技能。它们共同完成了一个看似简单却极其深刻的转变：把反馈从一次性信息升级为长期资产。
藏在代码审查里的进化引擎
Warp没有造一个复杂的框架，而是用最朴素的设计实现了这个循环。整个机制以一种近乎透明的方式嵌入到了他们的工作流里。工程师在代码审查时给Agent提的意见，不再是聊完就散场的空气，而是被结构化地收集起来，经过提炼后变成技能文件，合并进整个系统。这意味着Agent每被纠正一次，就永久性地变好一点。
从一次性对话到可合并的资产
过去，人类反馈的价值止步于当下。你告诉Claude“这里应该用异步处理”，它修正了这一次的输出，但对话一关闭，这个教训就烟消云散。Warp的突破在于，他们把反馈当成了一份待合并的代码变更。每个意见都可以被写入一个Markdown文件，通过PR流程提交。这些文件不是零散的备注，而是结构化的技能描述——告诉Agent在什么情况下该怎么做，为什么要这么做。一旦合并，这份反馈就永久性地沉淀在系统里。
听上去很简单，但正是这个“文件化”的步骤，让反馈的性质发生了根本变化。它从口语化的建议变成了可版本的、可审查的、可追溯的知识资产。一个工程团队积累的每一个纠正，都在为Agent补上一块拼图。这比任何人手动重写提示词都要系统得多，也可靠得多。
基础技能和改进技能：双文件设计
Warp采用了两个核心文件来支撑这个循环。基础技能是Agent行为的基准指南，它定义了根本原则和做事框架，确保智能体在不同的任务面前保持一致的判断标准。改进技能则是一个不断生长的反馈仓库，专门记录每一次从人类那里学来的具体修正和优化建议。两者分工明确：基础技能管方向，改进技能管细节。
这种双文件设计的妙处在于分离了稳定性和变异性。基础技能不轻易改动，它像宪法一样提供长期稳定的行为准则；改进技能频繁迭代，像修正案一样吸收新经验。当Agent遇到问题时，它会同时参考这两个文件，在原则框架内应用最新的修正。这使得系统既有根基，又保持灵活，且每一次改动都清晰可控。
为什么是技能而不是提示词重写？
很多人会问：这些反馈为什么不直接写进系统提示词？答案是，提示词是全局的、脆弱的东西。一句对特定场景的修正放进全局提示词，可能污染所有任务的输出。而技能是模块化的，它只在相关场景下被激活。Agent只在处理对应任务时才会加载一个技能，这让反馈的插入可以精准定位，而不是一发炮弹打满全场。
更重要的是，技能文件可以像代码一样被测试。工程师可以对一个技能进行独立的评估和验证，确认它不会引入回归问题。提示词一旦改错，整个Agent行为都可能受到影响，而且难以定位。技能提供了一条更安全的演进路径，这也是Warp敢于让数百名贡献者共同参与迭代的原因。
原则驱动：让智能体像人一样“懂规矩”
Warp在搭建这个系统时遇到过一个关键选择：技能里的内容应该写成规则还是原则？规则听起来很诱人，可以穷举所有情况，确保Agent不出错。但规则是脆弱的，每个新场景都需要新规则，规则之间还会互相冲突。Warp最后拍板：写原则，不写规则。这个决策决定了整个系统的气质。
规则会崩溃，原则能应变
规则试图覆盖一切，但世界是开放的。你写下了“不要使用alert”，Agent绕个弯用了confirm，规则立刻失效。原则恰恰相反，它不规定具体动作，而是说“任何阻塞性提示都必须经过用户确认”。Agent就能根据上下文做出判断，在遇到一个全新的场景时，也能依据原则推导出恰当的做法。原则思维让技能文件保持精简，同时拥有强大的泛化能力。
有一次，Warp的工程师发现Agent在处理某个边缘情况时，没有遵循他们新加的一条原则。他们没有立刻写下更细的规则，而是重新审视了那条原则的表述方式，让它更加清晰和可操作。这件事反映出团队的核心心态：他们相信Agent有理解能力，要做的是给它更好的指引，而不是给它上更紧的枷锁。
低摩擦反馈：让提意见变得不费劲
任何反馈系统最怕的就是“提交成本过高”。如果工程师指出一个Agent的问题需要填复杂的表单，人们很快就会放弃。Warp知道这一点，所以他们让反馈的路径短到几乎可以忽略。开发者在代码审查时，直接在评论里@Agent，用自然语言说出问题所在，然后系统会自动捕获这些信息，转化为技能候选。
这个“低摩擦”的设计哲学，使得反馈不是一项额外的任务，而是嵌入到了已有的工作流里。Warp团队甚至鼓励一种更松弛的反馈方式：哪怕是模糊的想法，比如“这个做法感觉不对”，也可以被捕获。人类不一定要给出精确的解决方案，完全可以把判断挫败感交给系统，让后续的改进流程来提炼。这种包容性让反馈的源头永远不会枯竭。
开源仓库里的真实压力测试
这套系统并不是在实验室里闭门造车。Warp把整个开源代码库变成了训练场，数百名贡献者参与其中，完成了数千次代码审查。每一次审查中的修正、质疑、建议，都被用来调校Agent的行为。这样的规模意味着反馈的多样性：不同背景、不同经验、不同风格的开发者，都会用自己的方式去纠正Agent。它逼着技能文件变得更加稳健，而不是只对某几个人的习惯友好。
Warp的工程师透露，有一次某位外部贡献者提出了一个他们内部完全没意识到的习惯性问题——Agent在处理某个API时选错了错误处理方式。这个发现被提炼成一条新的技能项，合并后，所有未来的代码生成都会自动避开那个陷阱。这正是开源协作最迷人的地方：技能的演进已经不再局限于一个团队，而是整个社区的集体智慧在喂养这个Agent。
可复用的改进回路，正在改写团队协作
当反馈被不断累积、复用，Agent的改进就不再是阶梯式的，而是变成了复利式的。每一条新技能都会和旧技能产生化学反应，量变终将引发质变。但真正值得玩味的，是这套机制对团队工作方式的深层影响。
数百名贡献者共享同一套进化逻辑
在传统模式下，每个工程师对Agent的调教都是私有的、孤立的。你花半小时写了一个巨细靡遗的提示词，解决了自己的问题，但这个提示词只存在于你的本地配置里。Warp模式打破了这种孤岛效应。技能文件的版本控制使得每一次改进都可以被团队甚至整个社区共享。数百名贡献者不再是在各自和Agent斗智斗勇，而是在共同构建一个大脑。
这种共享带来的附加价值是，知识的传递效率被大幅提升。一个新加入的团队成员，不需要从头开始摸索怎么让Agent听指挥。他只要查看已有的技能文件，就能理解团队对Agent的期望和Agent已经学会的规矩。这其实是在把原本藏在对话里的隐性知识，显性化成了项目的核心资产。Agent的成长史，就是团队的协作史。
从“写提示词”到“写技能”：工程师角色的转变
很多工程师习惯了把提示词当作一次性胶水，用完即弃。Warp的做法要求他们换一种思维：每一次交互，都是在为Agent设计一个持久的习性。这更像是在为Agent编写性格和行为规范，而不是为了某一次输出临时押韵。这种角色的转变，让工程师从“使用者”变成了“教育者”。
这种转变的难点在于，写技能比写提示词更需要抽象能力。你要提炼出共性的问题模式，而不是记录一次性的对话。但回报也很清晰：每一次你觉得Agent哪里做得不好，都变成了一个提升系统整体能力的机会，而不再是白白消耗一次修整无效抱怨。长期下来，整个团队在Agent身上投入的每一分钟，都会以更高的协作效率加倍返还。
这项实践的边界和未来
Warp这套方法论并非没有边界。技能文件的增多，总有一天会带来检索和权重问题。当一条反馈和另一条反馈出现矛盾时，如何消解？另外，原则驱动也要求Agent本身具备较高的推理能力，如果底层模型能力不足，原则只会让它更茫然。这些挑战或许说明，自我改进循环的下一个阶段，可能还需要引入更高维度的元认知机制来统筹技能之间的关系。
但至少在今天，Warp已经用实打实的数据证明了一条值得借鉴的路径：与其苦苦追求一个永不犯错的模型，不如设计一个能从反馈中不断进化的系统。人类最好的技能，就是教别人自己改进的技能。而Agent最好的技能，或许就是拥有获得这种技能的能力。这项实践真正的价值，不在于让某一个Agent变得更聪明，而在于为所有基于Claude的应用，提供了一套可移植的进化框架。
