九个月前的一个周二下午，我对着终端输入了一行新的指令，让Kiro按我们上个月一起设计的流程复查最近一周的云账单异常。
它没有直接吐出一堆数字，而是先问了我一个问题：“这次检查的预算警戒线还是按上个季度的标准吗？”那一刻我突然意识到，我不是在操作一个工具，而是在和一个了解项目背景的队友对话。这个细节让我决定把近一年来使用Kiro的模式梳理出来。
我用Kiro最频繁的场景是结对编程。传统意义上的结对编程指的是两个开发者坐在同一台电脑前，一个人写代码，另一个人审查思考，角色可以随时互换。而在我的工作流里，我承担的是导航和规划的角色，Kiro负责落地执行。遇到需要搭建新的云架构模块时，我会先用几句话描述整体设计思路和约束条件，然后看着Kiro逐段生成基础设施即代码的配置文件。过程中我会随时介入调整方向，比如“这里的安全组规则需要限制到仅内网网段”，而Kiro会基于这个反馈继续推进。这种协作方式保留下来的不是一段静默输出的代码，而是一整套带决策上下文的会话记录。
第二个模式，我叫它“橡皮鸭调试法”。在工程圈有一个老笑话，说的是程序员遇到难以定位的故障时，会把问题逐行解释给桌上的一只橡皮鸭听，往往在解释的过程中自己就发现了症结。Kiro在这个场景下的价值不是被动倾听，而是会主动从不同视角切入。上个月遇到一个阻塞性的部署故障，我把错误日志和已有的排查步骤摊开，Kiro在分析后没有直接指向某个配置错误，而是提出：“这个错误触发的时机和最近一次Terraform Provider版本升级的时间窗口吻合，要不要先回滚Provider版本做对照实验？”这个方向我确实还没想到，后来证明就是Provider升级引入的向后不兼容变更导致了资源漂移。
上述所有合作都有一个共同的收尾动作：记录。每次会话结束时我都会运行一条固定的指令，让Kiro把整个过程的要点提取出来，按年月日的格式命名，保存为一个Markdown文件，统一放在项目根目录下的记忆文件夹里。这个习惯的建立源于一个很实际的痛点。在经典的软件开发生命周期里，我们有工单系统，有提交记录，有变更日志，可以追溯“做了什么”。但更深一层的信息——为什么当时做了这个技术选型，讨论过哪些被否决的方案，某段配置的上下文背景是什么——通常只存在于当事人的短期记忆中。一周前的事情或许还能回忆起来，一个月的细节基本模糊了，更何况大部分工程师同时维护着多个项目。记忆文件夹解决的就是这个问题，它让每次会话带来的不仅是产出物，还有可以被随时调用的决策脉络。
两个月前的一个场景验证了这个做法的实用价值。主管突然问起某个生产集群两个月前做过的配置变更细节，我完全不记得了。如果在过去，我需要翻聊天记录、翻工单、翻变更单，拼凑出一份说明。这一次，我直接让Kiro读取记忆文件夹里那个时间段的会话摘要，按日期排序梳理出集群相关的所有操作记录，几分钟内就给出了完整的答复。
长年做运维自动化的经历让我对“重复劳动”三个字特别敏感。使用Kiro的过程中，我发现有一类工作是周期性出现的：查看云服务商的账单和预算配额使用情况、针对我们代码库和依赖版本做最新的漏洞扫描、汇总过去一周所有告警的复盘结果。这些任务每次执行的步骤几乎一样，只是时间参数不同。过去我会手动敲命令或运行脚本，现在我会在第一次和Kiro完整执行完一遍后，当场让它把整个流程录制为一个技能或提示文件。之后需要做同样的事情时，我只需要调用对应的技能文件，Kiro就会沿着我们共同设计好的步骤推进，检查点、输出格式都和上次保持一致。
这样做有一个隐藏的好处：降低模型偏离目标或产生幻觉的概率。因为技能文件固化了经过验证的工作流，Kiro是在一个已知正确的框架内执行，不需要在每次对话中重新摸索路径。当一项任务从“每次重新描述需求”变成“调用技能文件自动执行”，它就真正从单次协作变成了可复用的自动化资产。这个思路和我写运维脚本的哲学完全一致：如果一个操作要做第二次，就值得把它变成可重复执行的模块。
回首近一年的使用经历，Kiro在我这里的定位从来没有变成一个“一键生成一切”的自动驾驶仪，而更像一个知道项目历史、能独立执行、需要时会反问确认的搭档。我负责方向和质量，它负责速度和一致性，然后我们把每一段合作都记录下来，让下一次合作站在上一次的肩膀上。
热门跟贴