我是如何打磨 AI 代理构建的软件的
原文：https://every.to/source-code/how-i-polish-software-that-agents-built
在软件开发历史的大部分时间里，写代码本身就是工作的全部。你把时间花在编写函数、排查错误、调试数据库迁移，以及阅读别人的代码来搞清楚某个函数为什么要这么运行上。在代码工厂里又过了一天。
但那样的日子基本已经结束了。只要有一个好的头脑风暴和一份结构良好的计划，今天的模型就能自己写代码、跑测试、修复故障，然后把一个干净的拉取请求（pull request）交还给你，其中的代码变更已经准备好供你审阅。我可能会在早上打开笔记本电脑，看到一堆 AI 代理连夜交付的绿色拉取请求，这些新功能在我开第一个会之前就已经可以合并了。工厂已经自动化了。
留给我的工作，就是坐下来审视这些成果，判断它们到底好不好——然后把它推到连代理自己都无法企及的高度。一个模型并不知道，当 我 坐在 这个 产品面前，面对着正为 这些 用户打造的 这个 功能时，什么才是我认为的好。如果没有这最后一步的人类判断，代理产出的所有东西都只是功能上可用，但转身就会被忘掉。几周前，我在 Cora 里点开一张邮件卡片，一瞬间就意识到动画效果不对——它是从屏幕顶部滑入的，而不是从我点击的屏幕中部位置展开的。我告诉代理，它修好了，我再一点——感觉就好多了。
打磨，是复利工程的最后一步。复利工程是我在过去一年里不断打磨的一门学科，旨在让软件的构建方式随着每一次迭代而变得更聪明。随着流程中越来越多的中间环节被自动化，打磨现在变得愈发重要，因为这是工作中仍然属于你的那部分。你不再是流水线上把代码组装起来的工人，而是流水线末端那个决定产品是否好到值得签上自己名字的人。
实践中的打磨
那个看起来不对劲的卡片动画，是理解打磨如何运作的一个绝佳例子，因为动画正是 AI 代理目前还很难处理好的领域（尽管它会逐渐改善）。
那个拉取请求已经通过了所有自动化检查。审查代理也找不出任何需要我注意的问题了。我运行了 /ce-polish——这是复利工程插件的一部分——它会做三件事，然后就不再打扰我。它签出我想要打磨的分支，在后台启动开发服务器，然后在我的编辑器里、紧挨着代理窗口的地方打开正在运行的应用。从那里，我点开了一张邮件卡片，开始了我的评估。
开发中的 Cora Brief 更新版本，我通过打磨步骤对其进行了优化。（图片由 Kieran Klaassen 提供）
当新设计在代理旁边打开后，我就能看出它还是感觉太松散了。留白过多，卡片需要更紧凑一些。我通过 Monologue 大声说出了这个想法。代理收紧了布局；应用热重载；我再看一眼——好多了。一份计划可以告诉代理，把 Brief 做得像一本杂志。但它无法告诉代理，页面在何时才达到了合适的密度。我必须亲眼看到，然后自己做出判断。
这就是打磨的样子：一场发生在我、正在运行的应用和代理之间的对话。整个设置——/ce-polish、并排布局、能热重载的开发服务器——的存在，就是为了让这场对话快到让我不会丢掉思绪，比如我正在眯着眼看的那一像素，或者我正试图去命名的那个微妙差异。增加诸如查找文件、切换窗口、或者为代理粘贴上下文之类的步骤，都会打乱这个节奏。打磨，是一种只有当你保持心流状态时才能完成的工作。
这也正是打磨和复利工程中其他步骤相比，显得奇特的地方。计划（Plan）步骤会派遣子代理来起草结构化的规格说明。审查（Review）步骤会发散出并行的审查者，每个都寻找不同类别的问题。构思（Ideate）步骤会进行发散式头脑风暴，并根据信心度和复杂度对幸存的想法进行评分。所有其他步骤都是围绕编排和结构化来构建的——一层层的代理叠加，用模板和评价标准来固定工作。而打磨恰恰相反。这里没有代理，因为代理无法决定屏幕上的东西是否与我想要构建的东西相符。
打磨如何改变了循环的其余部分
我知道打磨会改变整个循环的终点。但我没预料到的是，它也会改变循环的其余部分。
计划变得更犀利了，因为我开始撰写那些能预见到我在打磨时想 感受 到什么，而不仅仅是代码该做什么的计划。审查变得不那么焦虑了，因为我再也不需要在比对代码差异的阶段就抓住所有问题了——我知道后面还有一个步骤，能捕捉到只有真正在用这个应用的人才能看见的问题。
我的工作流瓶颈曾经是“我能多快交付”。而现在，有了代理之后，瓶颈变成了“我能把它做得多好”。在打磨上多花些时间，软件就会变得更好。
也许最大的提升发生在复利（Compound）这一步，也就是将循环中的经验教训记录下来，供代理下次取用的步骤。过去，这些教训大多来自正确性方面的失败，比如代码是否使用了正确的约定。在打磨之后，这些经验教训开始承载着品味。在 Cora 这个例子里，是一些诸如“动画应向点击位置收拢”、“滚动条不使用时隐藏”之类的规则。每一条规则都始于我对浏览器的嘟囔，然后变成了系统下次会自行应用的规则，无需我再次开口。
这就是打磨的复利效应。我第一次发现动画方向错误时，我必须说出来。但在下一个包含卡片的功能中，代理默认就应用了正确的动画格式。
留给我的工作
过去定义一个优秀工程师的工作，现在大部分已由代理完成。我现在必须做的，是判断这些工作成果是否足够好——然后，要把它推过“足够好”的界限，直到它感觉像是出自一个用心的人之手。一天之内能够交付的上限已经提高，因此，什么东西值得被交付的标准也随之提高了。
因为构建工作是由代理完成的，说出“这不对——重新规划整个东西”的成本几乎消失了。它需要的只是一个下午的代理时间和几美元的计算成本。你的职责从保护自己的时间，转变为保护你所构建之物的品质。
如果你想试试，这里有一个快速上手指南：挑一个你最近交付的功能——最好是有用户界面的，那种“能用”和“好用”之间存在明显差距的地方，比如一个引导流程、一个落地页、一个动画或一个设置界面。现在先跳过基础设施部分。从你的用户能切实感受到的地方开始。
安装复利工程插件——它适用于 Claude Code、Cursor、Codex 以及其他十几种代理开发环境。在分支上运行 /ce-polish，让它做它的三件事。当应用启动后，去用它。点击一切东西。不要去审查代码或记笔记。你唯一需要去留意的，就是你那种 “这不太对” 的直觉。当你发现了什么，就大声对代理说出来。看着它确保改动符合你的要求，然后继续看下一个地方。
当你做出了三到四个可以被应用到本功能之外的改动时，运行 /ce-compound 将这些偏好编纂成规则，让系统下次能够自行遵守。经过几次打磨会话后，你就会拥有一个关于品味的小型常备知识库。你构建的下一个功能，将从一开始就离卓越更近一步。
核心启示：当 AI 接管了编码和测试，软件工程师的核心价值便从“实现功能”转向了“定义品味”。打磨，作为人与 AI 协作流程中的最后一步，不再是简单的修修补补，而是人类将主观感受、隐性知识和美学判断注入产品的唯一途径，并通过“复利”机制，让这套品味能够自我进化、持续积累。
How I Polish Software That Agents Built 的发芽报告
材料核心
Kieran Klaassen 提出了“复合工程”工作流中的最后一步——打磨。他的核心论点是：当 AI 代理完成了编码的大部分工作后，人类工程师的角色从“代码流水线工人”转变为“最终判断者”。打磨不是修复 bug，而是注入那些只有人才能感知的“感觉”——比如动画的方向、页面的密度、节奏的紧凑感。打磨是一种发生在人、运行中的应用和代理之间的快速对话，通过将“感觉”显性化为规则，人的品味可以在后续开发中复利沉淀。
发芽 01：把隐性知识塞进系统 —— 从“感觉不对”到“下次自动执行”
种子
Klaassen 描述了一个很有价值的转变过程：他对着浏览器嘟囔了一句“动画方向不对”，几轮迭代后，这个偏好就变成了系统规则，下次代理会自动采用正确的动画。这背后是将完全个人化、隐性的“品味知识”编码化为显性系统规则的过程。这是一种在软件领域的“手艺传承”。
故事：野中郁次郎与松下家用面包机
1991年，日本管理学家野中郁次郎在他那篇影响深远的论文《知识创造型企业》中，讲了一个经典案例。1985年，松下公司的工程师们试图开发一款家用面包机，但他们做出的面包总是外焦内生，远不如面包店里的好吃。技术规格和数据都无法解释其中的差异。
于是，首席工程师田中郁子被派到大阪国际酒店当学徒，跟着那里的首席面包师学习揉面。她发现，面包师在搓揉面团时有一套特定的“扭转”技术，这是无法用文字精确描述的动作。经过长时间的观察、模仿和反复实验，田中终于把这套“扭转手法”翻译成了工程参数——在搅拌叶片上增加特殊的肋条，重新设计揉面程序。1987年，松下面包机上市，第一年就创下了销售纪录。
野中用这个案例来解释“隐性知识显性化”的力量。面包师自己或许说不清为什么他的面包更好，就像 Klaassen 无法提前写出一条“动画要从点击位置打开”的编码规范——直到他亲眼看到动画从屏幕顶部滑入，才瞬间知道那是错的。重要的不是他当时能说出理由，而是他建立了一套系统，确保这种“感觉不对”能立刻被响应、测试，并最终编译成代理未来可以遵循的稳定指令。
Aha 瞬间
“田中郁子把面包师手指的扭动变成了机器的参数；Klaassen 把人类对像素的直觉变成了代理的规则——两者都在做同一件事：让下一次创造不必从零开始重新学习品味。”
发芽 02：流动中的“反思性实践” —— 打磨是发生在当下的专业判断
种子
Klaassen 强调，打磨的成功依赖于“不打断流动”：热重载、语音输入、不切换窗口——这一切都是为了保护一个脆弱的认知状态。他称之为“一场保持节奏的对话”。这不仅仅是效率问题，而是人类专业判断特有的运作方式：它发生在实时互动中，无法被提前编码成检查清单。
故事：唐纳德·舍恩与实践认识论
1983年，麻省理工学院教授唐纳德·舍恩出版了《反思性实践者》一书，彻底颠覆了人们对“专家如何解决问题”的认知。当时主流的观点认为，优秀的从业者是先把科学理论学透，再应用到实践中去——理性、冷静、按部就班。但舍恩研究建筑师、工程师、心理治疗师的实际工作时，发现根本不是这么回事。
他观察到，专家们有一种“行动中的反思”能力：他们在做的过程中不断对情境进行判断、调整、重新框定问题。一个建筑系学生画了一笔线条，老师会说“这堵墙放在这里，感觉让空间变得沉重了”——那不是从一本理论书中得出的结论，而是在那一刻、看着那幅图的当下涌现的直觉判断。舍恩称之为“与情境的反思性对话”。
Klaassen 对动画的感知——“它应该从点击处展开”——正是这种“行动中的反思”。它不是在设计文档里能被提前列出的需求。它只能在他点下鼠标的0.3秒内，当他看到的画面与大脑中“应该如此”的某种预期产生冲突时，才能被捕捉到。这也是为什么他反复强调不能打断这个节奏。一旦他被迫去翻文件、粘贴上下文、重新加载应用，那种微妙的感觉就会像刚醒来的梦一样迅速消散。这不是自动化的失败，而是人类专业判断的核心属性。
Aha 瞬间
“舍恩说专家的核心能力是‘对情境的反思性对话’，而 Klaassen 的抛光流程就是为这种对话建造了一个隔音室——所有可能打断它的杂音（文件切换、代码审查、上下文粘贴）都被事先消除了。”
发芽 03：当制造的成本趋近于零，唯一稀缺的只有判断
种子
Klaassen 在文末抛出了一个分量极重的观点：“因为代理承担了构建工作，说出‘这不行，重新规划整个东西’的成本几乎消失了。”这引发了一个更根本的转变：当生产一个可运行版本的成本（时间和金钱）低到可以忽略不计时，唯一真正稀缺的资源就变成了那个敢于说“还不够好”的人类判断。
故事：鲍勃·迪伦与“Like a Rolling Stone”的诞生
1965年，鲍勃·迪伦录制歌曲《Like a Rolling Stone》的过程，是音乐史上一个著名的低效传奇。在哥伦比亚唱片公司的录音棚里，迪伦和他的乐队一遍又一遍地排练这首长达六分钟的歌曲。前几遍要么节奏太慢，要么吉他手没找准感觉，要么迪伦自己觉得歌词的某个音节唱得不够锋利。当时参与录音的钢琴家保罗·格里芬后来回忆说，过程极度混乱，“就像在黑暗中摸索一只大象”。
在第1次、第4次、第11次尝试中，乐队不断失败。直到第15次，鼓手鲍比·格雷格开始了一个强劲的节拍，吉他手迈克·布卢姆菲尔德找到了那个标志性的连复段。那一刻，所有人都知道他们抓住了。但这个版本，不是根据乐谱或计划得来的，而是迪伦在反复试错中不断说“不——再来一次”的结果。
在互联网泡沫前，录一首歌进录音棚就是一笔巨款。但在1965年，哥伦比亚唱片公司为迪伦支付了这场漫长实验的全部费用。“不，还不够”的判断力，正是构成天才的核心部分。
未来的软件创作或许会与迪伦的这场录音类似：AI 代理可以生成第1个、第4个、第11个版本，消耗的只是几美元的计算费和一小时的等待。但唯有那个坐在屏幕前、对自己作品有绝对洁癖的人，才能在版本之间做出终极仲裁。这才是不会被自动化剥夺的价值。制造不再稀缺，稀缺的是那个敢于反复说“不”的人。
Aha 瞬间
“迪伦用了15次才捕捉到那个完美的版本。如果发电的成本为零，谁都能不断尝试，但只有他知道什么时候第15次终于对了——这就是‘打磨’中永远无法自动化的人类内核。”
你的思考空间
- 隐性知识的边界：“感觉不对”可以被翻译成可执行的系统规则，但是否存在某种“感觉”，无论怎样努力都无法被显性化？如果系统只能学习过去的偏好，会不会因此排斥掉未来的创新？
- 社会与技术结构的压力：当软件开发变成个人自言自语般的打磨对话，团队的协作模式、代码评审的价值、不同背景者的多元视角会面临什么样的新挑战？
- 品味作为元能力：如果“判断力”是最后的稀缺资源，那么专门训练这种审美判断（而非编码技巧）的教育或实践会是什么样的？你能接受一个完全不懂算法，但视觉品味极其敏锐的“首席打磨官”吗？
- 适用领域的扩张：Klaassen 的应用是 UI 动画，但“在动态现象涌现的瞬间发现其不对劲”的能力，在商业策略、内容创作、甚至科学实验中是否同样成立？你的“热重载”测试场在哪里？