自从我开始在一家积极拥抱AI以提高生产力和采用利基技术的公司担任新角色以来，已经过去三周了。我想分享一些最近作为软件工程师在AI支持效率提升方面获得的见解。这篇文章的主要主题是介绍使用AI加速软件开发的三个先决条件。换句话说，你需要满足这些先决条件才能让AI在你的软件开发工作中更好地为你服务。
对AI友好的代码库
第一个先决条件是对 AI 友好的代码库。这样能确保 AI 基于你的意图开展工作，而不是随意生成点子。
引入规则与上下文
如果你使用过 Cursor 或类似的代码编辑器，你应该明白我的意思。你需要提供适用于整个项目的全局规则，作为指导或长效提示，要求 AI 在特定框架内思考。
在这份规则文件中，你至少需要介绍以下内容：
- 业务范围：项目是做什么的？它的功能边界是什么？（虽然这可能会改变，你可以随时更新）。
- 项目上下文：你正在构建什么类型的应用程序（Web、iOS等），以及你的技术选择是什么？
- 你的愿景：理想情况下，项目应该是什么样子？
- 最佳实践：指定你希望AI遵循的任务（例如，对于每个实现的API，你还必须编写相关的OpenAPI文档）。
代码注释 > 文档
简而言之，有两个原因：
- 与纯文本相比，AI能更好地理解代码，因为代码是明确的。
- 代码总是最新的，而文档可能会过时。
因此，永远不要将代码库中的注释仅仅视为未使用的代码或简单的功能介绍。它们也可以包含关键的业务逻辑。你可以使用注释来解释代码块背后的推理，比如为什么工作流程以某种方式设计，它以前是什么样子，甚至是谁做出了这些改变的决定。Git 会记录变更，而代码内的注释则为 AI 和人类开发者提供明确而有信息量的线索。
我之所以认为对代码维护者而言文档不再那么重要，还有一个原因：AI。作为新的代码维护者，你可以向 AI 询问任何你需要知道的东西。别误会，我说的是维护者，而不是项目用户或依赖这个项目的其他开发者。你仍然需要为那些受众提供文档，但会更轻量，因为他们不关心实现细节。再次强调，要让这发挥作用，你需要足够的上下文注释。
整洁且语义清晰的代码/结构
就像人类开发者一样，AI 更喜欢具有高内聚、低耦合的代码，这样它就可以更有把握地添加或编辑代码。没有人喜欢混乱，所以这本质上是一个代码质量问题，无论你是否使用 AI。AI 生成的代码将严重依赖现有代码：垃圾输入，垃圾输出。这应当从项目伊始就被重视，并持续保持。一旦代码库成为 AI 辅助的「屎山」，相信我，没有人会想碰它。
强健的内置检查
AI 的重试成本很低，尤其是对于并行工作的编码类 AI 工具。人类工程师精力有限，可能会忘记执行那些能发现小问题的繁琐检查。这就是强健的内置检查发挥作用的地方。例如，在 NodeJS 项目中，这些检查应该在项目初始化时由开发者配置。
- 代码规范检查（Linting）：检查代码风格并防止不安全的坏实践。
- 格式化（Formatting）：强制执行一致的代码格式（例如缩进）。
- 类型检查（Type Checking）：如果使用 TypeScript，确保类型安全。
- 测试（Testing）：通过自动化测试暴露逻辑或功能问题。
这些检查必须提供包含具体文件名与行号的反馈，以帮助 AI 快速定位问题根因，从而反复重试直到问题解决。你是在帮助 AI 提高其输出的质量门槛。最棒的是，人类工程师不会被打扰，你可以从容规划下一步。看到了吗？效率提升了。
领域知识
我工作得越多，就越意识到技术技能对软件工程师来说并不是一切，即使你负责对性能指标高度敏感的关键组件。Product Mindset 和 Own Your Product 是经常被提到的两个品质。从项目经理那里获得信任的关键在于确保你的交付符合他们的预期，这要求你们达成一致。这就是为什么领域知识如此受重视。
- 共享术语带来共识和效率。
- 你可以及早发现你和PM之间理解的差距。
- 这有助于长期思考，特别是当你负责系统设计时。
是的，这些原则在 AI 发明之前就存在了，但在 AI 时代更加耀眼。
|
|
人类工程师现在更像是一个解释者：你会将 PM 的需求重新表述，加入你的技术洞见，并通过提示把这些传达给 AI。显然，你对领域知识的理解越好，你的提示就越准确有效。你的领域知识也能帮助你把工作拆解成可执行的行动计划并明确优先级。一旦范围和上下文清晰，就是时候让 AI 在后台并行完成你的任务了。
技术审查
就像任何其他技能一样，你与 AI 合作得越多，你就越了解如何与它合作。没人会因你让 AI 生成代码而指责你，但底线是你必须始终清楚它在做什么。因此，软件工程师的技术要求依然存在。初级软件工程师现在也不可避免地要审查 AI 生成的代码，这以前往往超出他们的典型职责范围。你的角色正转向把控方向与系统设计，而不是只关注实现。
AI 就像一个性能缩放器——你性能公式中的一个系数。你的技术知识越多越深，你能驱动的就越多，你的节奏就越快。如果将来听到50倍软件工程师的概念，我不会感到惊讶。Andrew Ng 教授有一个有趣的新发现：硅谷产品经理（PM）与软件开发工程师（SDE）的比例已经从传统的 1:4 转变为最高 1:0.5，在某种程度上印证了我的观点。
软件工程师完蛋了吗？
简而言之，不——只要你愿意适应变化。
AI 正在改变我们的工作方式，但它距离完全自主还很远，这意味着 AI 在软件工程中仍然只是助手。AI 显著提升了交付速度，所以就业市场上的职位可能会减少。另一方面，AI 的出现拉平了人们之间的技术差距，允许任何人创建自己的产品，并可能用新的创业项目填补这些缺失的职位。
我突然想起了曾嵘（前 SAGI GAMES CEO）说过的话：当你打算用汽车取代马车时，你有问过马的意见吗？