以下是我基于过去两年经验对人工智能开发的一些思考。和所有列表一样，这些想法没有特定的顺序。
-
兴奋起来吧！人工智能只有在你把它当作工作中的可有可无的部分时，才会真正威胁到你的工作。它的存在是为了帮助你成为更优秀、更高效的软件工程师。就像你当初欣然接受集成开发环境（IDE）而放弃文本编辑器一样，全心全意地拥抱它吧。使用人工智能不会让你变成低级程序员，不使用它也不会让你显得与众不同。事实上，不使用或抵制它只会让你显得与时代脱节。这正是你一直渴望重新爱上这份工作的原因，它或许还能让你想起，你当初选择进入这个行业，是因为创造的乐趣，而不仅仅是编写代码。
-
大部分代码（超过 80%）现在都应该由 AI 生成。如果不是，说明你的工作流程存在根本性的缺陷。放下你的自尊，承认 AI 比你更擅长编程。你的编码技能现在价值不大，但你的软件工程技能却更有价值。投资后者，不要执着于前者。AI 生成的代码仍然是“你的”代码，所以你可以像以前一样为它感到自豪。你只是学会了如何更快地打字。快得多！
-
程序员应该专注于单一职责原则 (SRP)、DRY 原则、SOLID 原则以及简洁的设计/代码。引导人工智能 (AI) 正确执行这些原则需要理解软件使用的业务环境，而 AI 本身并不了解这些。你需要精通未来功能可能发生的变化以及需要权衡的因素。我是否应该创建一个新模块？这个方法的命名是否恰当？它是否接收了过多的参数？我是否违反了德米特法则？这个文件是否过大？我是否应该将这两个关注点分开？如何才能提高代码的复用性？这些都是你应该花时间思考的问题。这需要你比以往更深入地了解产品。你不仅是软件工程师，还是产品工程师，这需要你对过去可能忽略的某些方面有深刻的理解。
-
上下文管理（或工程）是提高效率的关键所在。如果你发现自己需要反复向一个健忘的AI传达信息，那么这就是一个需要解决的问题。简单的解决方案包括使用Claude Skills ，而更复杂的方案则包括使用Beads 。你的工作流程应该不断地将信息“保存”到内存中，从而提高效率。有时，我不得不提醒Claude“在执行Y操作时，必须先执行X操作”，这让我感到很沮丧——这些规则应该被明确规定。不要把AGENTS.md或其他任何指令文件当作静态文档，否则会浪费你的时间。如何管理你自身（以及你的团队）的上下文是需要投入时间去思考的问题。如果你在一家大型公司工作，这将是一个特别有趣的挑战，因为你必须在协调一致和自主性、硬性规定和指导方针等之间找到平衡。
-
每个人都应该读一本从零开始构建LLM（法学模型）的书。这会很痛苦，而且像我一样，你可能得反复阅读某些章节才能理解（我就是这么做的，读了很多遍），但一旦理解了，你就会受益匪浅。虽然你很可能永远不会开发自己的LLM，而且大部分时间可能都会使用现成的模型，但了解其底层工作原理仍然很有帮助。在你职业生涯的某个阶段，你肯定需要调整模型参数，而拥有这些基础知识将决定你是在凭感觉行事还是胸有成竹。
-
代码审查已成为新的瓶颈。好消息是，我们已经看到一些工具涌现，使代码审查变得更加轻松（例如CodeRabbit ）。对于本地代码审查，多代理工作流效果显著。使用一个专门用于审查代码正确性、安全性等的代理，并为其制定相应的规则和指南，实现起来非常简单，例如：
claude-code review --aspect "correctness" src/ > /tmp/review_correctness.md。如果您尚未采用多代理工作流，这是一个很好的起点。以下是一些其他方案：1）一个专门用于根据git diff生成良好提交信息的代理；2）一个用于清理测试的测试重构代理；将测试清理规则塞进“开发”上下文可能过于繁杂，因此使用一个独立的、专注于此的代理会更加有效。 -
没有理由不编写干净的代码。重构成本低，编写测试成本更低。如果你的代码不够干净，那就为其生成更高级别的测试，然后让智能体进行重构。这些测试将为你指明问题所在。这在老旧代码库中尤为重要，因为在这些代码库中，任何更改都风险最大。专门用于“清理代码”的工作流是易于实现的多智能体工作流的另一个例子。
-
文档是免费的。无论是代码内联文档、架构图还是错误分析，过去需要数天才能完成的工作，现在只需几分钟即可完成。无论从产品角度还是工程角度来看，都没有理由不提供全面且最新的文档。代码不仅应该在需要清晰说明的地方描述其功能，还应该阐明其背后的业务规则（无论是内联还是链接到外部文档）。程序员在阅读代码时，应该能够通过单一入口点来理解设计决策以及客户使用代码的上下文。
-
成本优化如今已成为软件工程的一部分。并非所有任务都需要 Claude Opus，而懂得何时将任务委托给更经济的 AI 工具也是一种技能。更理想的做法是，对于简单的任务和基本的 CRUD 操作（约占所有开发工作的 90%），可以在本地安装像 Qwen Code 这样的免费工具。而对于涉及业务背景的复杂重构，则值得使用 Opus 的定价策略。你应该根据当前问题，对选择合适的模型有一个清晰的思路。像在 AWS 上跟踪计算成本一样，跟踪每个功能的 AI 成本，这样你就可以优化工作流程，而不仅仅是代码。在琐碎的任务上运行昂贵的模型既浪费资源，又显得不够专业。
-
高层系统设计正是你需要发挥作用的地方。人工智能可以处理实现细节，但架构决策需要人类的判断，这种判断需要理解业务约束、团队能力以及长期维护负担。你需要提升系统设计能力，理解不同架构模式之间的权衡取舍，并做出能够考虑到人工智能无法预知的因素的决策——例如你的团队不喜欢微服务，或者你计划在下个季度收购一家公司。这正是你价值倍增之处。
原文： https://zarar.dev/its-a-great-time-to-be-a-software-engineer/