软件工程师的主动控制 文章 1 / 2 通常来说，解释一个笑话是一个不好的迹象，但由于你在我打这个标题时看不到我的面部表情，我可能不得不解释一下我的意思，以及为什么这非常讽刺。问题是，所有那些 Anthropic 的新闻记者（大约每位在‘25-‘26 年期间在 LinkedIn 上发帖的人）声称 "SaaS 已经死了" 的次数太多了，每次都有一个不同的 “这是我们所知道的世界的终结” 爆炸性标题，而潜在的陈述始终是同样的：氛围编码使 SaaS 变得无关紧要。又一次。你不再需要为在线服务付费了。需要什么？10分钟的氛围编码会为你解决问题，并且为你节省很多钱。他们自信地宣称：“SaaS 已经死了。” 现在已经过去 6 到 18 个月。SaaS 已经死了。氛围编码确实让它死了。不是通过用一个安全、强大、量身定制的解决方案来替代每个在线服务，而是通过专为地球上每个人的具体需求量身定制（这该多好啊。此外，我也是多么天真，竟然给他们好处于怀疑）。氛围编码只是从内部杀死了它。这是第一个讽刺。每个人都在进行氛围编码，SaaS 服务每周都会出现故障。许多人感到沮丧。我们已经习惯于 SaaS 解决方案在‘22年时以他们的五个九的统计数据为傲，最好的情况下在‘26年时每周出现一次故障。那么发生了什么呢？好吧，答案有点显而易见。但更深入地说，值得注意的是软件行业市场期望的激烈转变。随着时间的推移，我们愈发清楚AGI并没有即将来临，氛围编码不会取代软件工程师，也不会让软件开发加速10倍。然而，市场并没有对此做出真正的反应。他们已经投资并看到这一切发生。人们已经被裁员，财务预测已经提交给董事会，现在我们必须以某种方式交付10倍的成果。我把剩下的数学留给你。别误解我的意思，我非常支持辅助编码。作为一个自认为极其享受编程实践的人，我曾有过最初的恐惧，后来我很快发现编程的不同层面给我带来了快乐，以及我可以自动化多少这些内容，仍然享受每一秒。我可能属于AI采用的高端，相较于曾经每天花大量时间编码的人来说，我现在几乎不直接编写代码。然而，这些工具并不是为我们软件工程师而设计的。我们需要更多的控制。我们需要更好的大型语言模型周围的工具。为什么我如此自信地声称这一点？让我给你一些例子。 人类不在环中 你有没有把一个编码任务交给代理，几分钟后回来发现一个干净的分支和提交的代码？我知道，这不是世界末日。你可以修复代码，你可以修改提交。但对代理感到生气的冲动是存在的。为什么？因为你是那个必须为发布代码中的问题负责的人。然而，没人想过要把你包括在内。这很烦人，让我们承认吧：10次中9次，第一次迭代的代码是不可能完全匹配你的意图的。这不仅是烦人。这还是低效的。 规则是用来被打破的 你是否发现自己正在乞求代理遵循你的编码标准？你发现自己在给 AGENTS.md 文件添加规则，重复诸如：“你必须始终正确处理错误”，“绝不要在那个目录下放置测试”，“绝不要尝试直接使用AWS CLI，我们用IaC!!!”这样的规则。这有效吗？可能有一点帮助，而且可能让其他事情变得更糟。你有尝试添加规则指示代理写更少的注释吗？试试看。看看结果如何 🤦‍♀️。没有什么是一致的，没有什么是确定的。除了对它大喊“但你不应该这样做！”我们还能剩下什么？ 你是一个高级软件工程师 你是否和 Claude Code 一起工作？你有没有发现自己在请它调查某件事并提供分析？然后你是否厌倦了无目的地按 Enter 并切换到自动模式？你5分钟后回来发现它提交了“修复”，尽管你明确要求进行根本原因分析！！！ 什么修复？到底是什么问题，天哪?!?! 你知道原因吗？Claude Code 将主动控制（自动批准工具调用的模式）与系统提示混为一谈。出于某种原因，有人认为像这样的事情：“这个人不想不断按 Enter。这可能意味着我们应该告诉 LLM 他是高级软件工程师（🤣），并请努力实现解决方案”。所以它跳过了你请求的根本原因分析。它直接实现了你没有请求的事情。又来了：你的意图漂离了。 结论 这些故事有什么共同之处？缺乏控制。