文章首发于公众号：非著名程序员。
Nilenso 软件公司的工程师 Atharva Raykar 写了一篇文章《AI辅助编程：适合不能只靠感觉的团队》。
这篇文章的观点很好，我非常认同。
作者认为：AI 不会替代优秀的工程师，而是会让优秀的工程师变得更强大。那些基础扎实、有良好工程实践的团队，在 AI 时代会获得更大的竞争优势。而那些基础薄弱、流程混乱的团队，AI 可能会放大他们的问题。
这提醒我们：在拥抱 AI 的同时，更要注重基本功的修炼。
全文翻译如下：
《AI辅助编程：适合不能只靠感觉的团队》
那些想要打造周全、精良产品的工程团队，应该引入AI。但这需要会用这些工具。我们这十多年来专注于构建高质量软件的经验，让我们摸索出了如何用这种新的开发方式来打造更好的产品。
用AI开发很快。这种速度提升很重要，因为运用得当的话，团队能更快地与用户形成反馈循环，做出更好的产品。
但AI工具也很难用。用错了，可能效果平平，更糟糕的是，项目被低质量代码和技术债务拖累，反而让开发速度变慢。
这份动态手册基于我们在生产环境软件的复杂战壕中使用AI工具的经验——在那里，没人能承担得起只凭感觉做事的后果。希望其他团队能从我们的发现中学习和受益。
AI是个倍增器
想让AI好用，先让自己变强。AI是个倍增器。如果你本身系数很小，就看不到多大收益。如果你是负数，那收益也是负的。
我发现，最优秀、最有经验的工程师能从AI工具中榨取出更多价值。原因有几个：
-
他们极其擅长表达技术想法
-
他们有敏锐的判断力，能感知什么样的系统才是好系统，能据此引导大语言模型——我喜欢称之为"修理工的手感"
-
他们基础扎实，所以能很快上手新工具和系统，这种情况下知识是瓶颈，而不是技能
-
AI仍然对语言和风格很敏感，经常会反映出提示者的品位和敏感度。技艺精湛的工程师对什么行得通、什么行不通有着敏锐的品位和直觉
所以，要体现出工匠的关怀。归根结底，你应该产出让自己骄傲的成果，哪怕AI帮了忙。这在我看到的系统输出中得到了很好的体现。
举个例子。这个提示不算不合理，但不够周到：
写一个Python限流器，限制用户每分钟10个请求。
我觉得这个提示能给出还行的结果，但也会遗漏一些边界情况、好的实践和质量标准。而nilenso的人可能会这样向AI提出同样的任务：
用Python实现一个令牌桶限流器，要求如下：
- 每用户每分钟10个请求（通过`user_id`字符串标识用户）
- 支持并发访问的线程安全
- 自动清理过期条目
- 返回元组(allowed: bool, retry_after_seconds: int)
考虑：
- 令牌应该逐渐补充还是一次性全部补充？
- 系统时钟变化时会发生什么？
- 如何防止不活跃用户造成的内存泄漏？
优先选择简单、可读的实现，而不是过度优化。只使用标准库（不用Redis/外部依赖）。
你猜哪个提示能更好地实现程序设计者的意图？
有个对我们很有效的技巧是元提示。我用一个简单的任务提示模型，让它帮忙找出权衡点和边界情况。然后我把这些变成技术规范，交给另一个LLM代理去执行。甚至我上面分享的"更好的提示"也是通过让AI想出好提示得来的。根据我的经验，模型已经变得很擅长给自己写提示了。
这些工具的具体使用方法还在变化，但有一个稳定的原则：真正努力让自己成为好工程师。你的习惯会很快传递给你使用的AI系统。这之所以有效，是因为对人有帮助的东西对AI也有帮助。
对人有帮助的东西对AI也有帮助
我想澄清一下什么是软件工程，这在AI颠覆的背景下值得重新审视。
软件工程不是写代码。至少，这不是其决定性特征，就像写作不是用墨水在纸上做腕部练习一样。
对我来说，软件工程是维护大量定义明确的心智模型来满足商业或经济需求的艺术和科学。很多工作都围绕着制作和管理这些大型、复杂的社会技术系统，而代码只是这些系统的一种表现形式。
在AI足够强大到能完全吞噬整个社会技术系统并把所有培育它的人类都排除出去之前，它必须参与并受益于这个系统。简单来说：AI在人类也能蓬勃发展的环境中表现得要好得多。这意味着你的团队的软件基础应该扎实。
AI能蓬勃发展的系统，是具有高质量团队和代码库标志的系统。这些标志包括：
-
良好的测试覆盖，有用的断言
-
代码合并前的自动化检查、格式化和测试检查
-
持续集成和部署
-
文档完善的更改、技术规范、架构决策记录和好的提交信息
-
一致的风格和模式，通过格式化工具强制执行
-
简单、简洁、组织良好的代码
-
清晰定义的功能，分解成多个小的故事卡
今天的AI可以并将使用所有这些东西来让事情"正常工作"。当我给编码代理一个任务时，它会在代理循环中通过运行测试用例和静态分析工具不断自我纠正。这大大减少了完成工作所需的手把手指导和干预。
丰富的环境和上下文帮助AI更好地工作。
这里有个轶事：我之前在一个有两个服务的项目上工作，其中一个有我上面描述的所有东西——好的测试、文档完善的更改、代码中一致的模式、大量的检查和防护栏。另一个服务更乱，没有上述任何东西。与前者相比，我们的AI编码助手在后者的代码库上难以完成同等难度的任务！这可能是因为混乱的代码库对AI来说和对人类一样令人困惑。对于正确做事的方式存在混合信号。
编辑器中的工具和技巧
现在我已经概述了总体策略，以下是一些对我有帮助的具体战术。
使用最好的前沿AI模型，不要省钱。
- 使用可用的最好的编码模型。不要为了省积分和成本而使用更差的模型。好模型的优势是复合的。我接下来展示的所有战术在你有强大编码模型的基础上会工作得更好。
擅长提供上下文。
-
AI辅助编程的有效性很大程度上取决于你能多熟练地向LLM提供正确的上下文。
-
使用"代理式"编码工具。这些工具能够读取和分析文件、运行shell命令、获取文档、制定计划并执行这些计划，不需要人工干预（除了可能需要批准）。我们目前推荐的能做到这些的工具是Claude Code、Windsurf、Cursor、Cline。
-
如果给LLM无关或杂乱的上下文，它们可能会分心并陷入兔子洞。通过只@提及相关文件和只链接有助于任务的文档来集中其注意力。
-
在RULES.md文件中编码编程标准和实践。将此文件符号链接到代理特定的规则文件，如.cursorrules、.windsurfrules、claude.md等。
-
这个文件应该包含技术栈信息、如何使用开发工具和运行检查器、编码标准和模式，以及覆盖LLM在处理代码时犯的常见错误。
实现新功能或重构
-
分解问题。你越具体，AI工作得越好。记住，你也可以使用AI来减少让提示写得更好、更具体的繁琐工作。推理模型在这方面很棒！
-
如果你在做大功能，把它分解成小任务，一个一个地喂给它，每个任务结束时做一次提交。如果你的故事卡这样做，故事卡描述和任务列表通常对AI很有帮助。
-
提供技术规范和产品功能的相关文档。不要只是让它写代码而不给出产品的更广泛上下文。还要给它关于如何使用你正在使用的库的文档。对大多数工具来说，粘贴文档链接通常有效。一些库为编码代理提供llms.txt。
-
另一个对我们很有效的模式是将功能分解为"规划"和"执行"阶段。一些编码代理已经为你做这种分解了。
-
不要想当然地接受AI建议。让它为自己的选择做解释，提出替代方案，思考优缺点。
调试
-
使用AI来调试它生成的错误。总是粘贴最相关的错误上下文，让LLM帮助理解问题（我喜欢在单独的XML标签中描述错误日志或输出）。
-
解释你尝试过什么，以及额外的观察，帮助模型生成正确的假设并排除错误的假设。提供大量上下文。
编辑器外的工具和技巧
使用AI来提升你自己的技能和知识
- LLM是拥有庞大世界知识（最近还具备有效研究能力）的无限耐心的老师。积极使用它们来学习事物并揭开任何新代码或技术栈的神秘面纱。不断深挖。找出最佳实践。通过让LLM引用高质量来源来确保你学得正确。
创建大量文档
-
通过向LLM提供代码库轻松创建大量详细文档。例如：
-
解释功能，创建知识库
-
总结当前收集的所有指标
-
更智能地识别缺失的测试用例
这样做有充分理由——文档现在生成成本很低，而且反过来会让你项目上的LLM（和人类）更加有效。
微摩擦润滑剂
LLM大大降低了为团队日常遇到的所有小摩擦点创建润滑剂的成本。
-
使用它们创建模拟服务器来协调前后端团队之间的工作并解除阻塞。只需要在合约上达成一致。
-
通过向LLM提供shell历史会话，为基础设施部署、常见故障排除类型等创建运行手册和指南。
-
将现有的运行手册和指南提供给LLM，让它们制作成自动化常见任务的脚本。
代码审查
-
为Pull Request制作模板，将每个功能的代码差异（
git log -p <range>）提供给AI来解释更改以及如何部署它们。一些工具已经可以为你做这件事了。 -
为了减少首次PR审查的时间，在第一部分使用代码审查机器人。但不要替换人工审查！
-
使用LLM来解释你作为审查者不完全理解的更改。向它寻求澄清，然后在收集必要上下文后询问实现者。
调试和监控运行中的应用程序
-
使用LLM的研究能力来帮助找到不常见错误的解决方案。遵循编辑器中调试的建议来在编辑器外调试。提供尽可能多的上下文。
-
LLM在为可观察性工具编写查询和告警规则方面相当不错。它们也擅长通过编写自定义python代码来处理数据和执行分析。
性能优化
- 使用LLM来帮你优化数据库和调整配置。这样做时，提供基础设施和硬件的上下文。分享查询计划。
AI如何改变工艺的影响
这是我们编写软件方式的巨大转变，我认为这需要对之前被认为是常识的一些想法进行改变。
首先，花太多时间寻找和构建复杂抽象的价值降低了。DRY对于确保代码中的模式不会不同步很有用，但实现和维护抽象以处理变化的需求是有成本的。LLM让一些重复变得可以接受，让你能等待更长时间并避免过早抽象。
重做工作现在极其便宜。小范围的代码不如大范围的结构模式和代码组织重要。你也可以构建大量原型来测试想法。为此，感性编程很棒，只要原型被丢弃并稍后重新正确编写。
与LLM协作还让你能利用生成器-验证器差距。通常验证和修复东西比从头生产它们更容易。这降低了尝试新事物的激活能量。
测试是不可妥协的，AI消除了因为写测试太慢而不写测试的所有借口。但总要审查断言！
未来我们学到更多关于这些工具后要添加到这个手册的内容
-
部署和有效使用像Devin/Jules/Claude Code这样的自主代理
-
用于编写查询、执行数据分析的AI工具
-
专有代码泄露的担忧、托管LLM选项等
-
构建分享提示、模式和模板的文化
-
在团队中推动AI采用的有效方式
博客原文链接：blog.nilenso.com/blog/2025/0…
最后，欢迎大家关注我的公众号：**非著名程序员，**每天持续为大家分享 AI、技术、副业和互联网相关的干货，一起突破圈层，实现个体崛起。
原文地址：mp.weixin.qq.com/s/CYicaf5QV…
