大家好，我是小程程。
今天在 HackerNews 刷到一篇热文，来自大佬
Martin Fowler 的个人网站，作者是
一位从业 20 多年的
程序员大姐 Birgitta Böckeler
。
开发者技能在代理编程中的角色
随着 AI 编程助手的能力不断提升，业界反应各不相同。有人从近期的技术进步推断：“
一年后，我们将不再需要开发者
。” 另一些人则担心 AI 生成代码的质量，以及初级开发者如何适应变革。
在过去几个月里，我频繁使用 Cursor、Windsurf 和 Cline 的代理模式（主要用于修改现有代码库，而非从头开发井字棋游戏）。IDE 集成的最新进展给我留下了深刻印象，这些集成极大地提升了工具辅助我的方式：
这些功能带来了令人惊叹的 AI 协作体验，有时能帮助我以创纪录的速度构建功能和解决问题。
然而
即使在这些成功的协作中，我仍需持续干预、纠正和引导 AI。很多时候，我甚至决定不提交 AI 生成的更改。在本文中，我将通过具体的引导案例，说明开发者的经验和技能在“监督代理”模式中的作用。
这些案例表明，尽管 AI 技术进步显著，但我们距离 AI 自主编写非重要任务的代码仍有很长的路要走。同时，它们也揭示了开发者在可预见的未来仍需掌握的技能类型——这些是我们必须保留和培养的能力。
我需要干预的场景
首先要说明的是，AI 工具在我列举的这些方面
绝对且始终表现不佳
。某些问题可以通过额外提示或自定义规则缓解，但无法完全控制：LLM 经常不严格遵循提示要求。
编程会话越长，结果越不可预测。因此，无论提示多么严谨，或编程助手集成了多少上下文提供者，我列举的问题仍有
不可忽视的发生概率
。
我将案例分为三类影响范围：
a.
减缓开发速度
（与手动编程相比）
b.
破坏团队协作流程
c.
损害代码长期可维护性
影响范围越大，团队发现问题的反馈周期越长。
（同心圆图示：提交、迭代、代码库生命周期）
1. 提交时间影响
这些案例中，AI 的阻碍大于帮助。由于问题最明显，这类影响反而是
最不严重
的，因为更改很可能不会被提交。
代码无法运行
我必须干预以确保代码正常工作。我的经验帮助我快速定位错误，或及时放弃 AI 生成的方案，重新开始或手动解决问题。
问题误诊
AI 经常陷入错误诊断的死胡同。基于对类似问题的经验，我能及时将其拉回正轨。
示例
：AI 误认为 Docker 构建问题由架构设置引起并修改了配置，但实际原因是复制了错误架构的 node_modules。
2. 团队协作流程影响
缺乏审查和干预，会导致交付迭代中的团队摩擦。基于在多个交付团队的经验，我能在提交前纠正这些问题。即使有 AI，程序员新手仍需通过试错学习，问题在于 AI 带来的编程效率提升是否会导致团队无法持续吸收这些错误。
过度前期工作
AI 倾向于一次性实现大范围功能，而非渐进式开发。这可能导致在发现技术选择不可行或需求误解时，浪费大量前期工作。
示例
：在前端技术栈迁移任务中，AI 试图一次性转换所有 UI 组件，而非从一个组件和垂直切片开始。
暴力修复而非根本原因分析
AI 有时采用暴力方法解决问题，而非诊断根本原因。这会将问题延迟到后续阶段，增加其他成员的分析难度。
示例
：Docker 构建内存不足时，AI 直接增加内存设置，而非探究内存使用过高的原因。
复杂化开发流程
AI 生成的构建流程可能损害开发者体验。
示例
：要求分别运行前后端命令（而非统一命令）、破坏热重载功能、复杂的构建配置等。
需求误解或遗漏
当需求描述不详细时，AI 容易得出错误结论。开发者必须在早期而非后期干预，否则问题将在后续流程中引发反复修改。
3. 长期可维护性影响
这是
最隐蔽
的影响，反馈周期最长（可能数月后才被发现）。代码当前可能正常运行，但未来修改成本极高。这类问题最依赖我 20 余年的编程经验。
冗长冗余的测试
AI 生成的测试常创建新函数而非扩展现有断言，或添加过多重复断言。对新手而言，更多测试≠更好。测试重复会导致维护困难和脆性增加。
缺乏复用性
AI 代码有时缺乏模块化，导致重复代码。
示例
：未发现已有 UI 组件，重复开发；使用内联 CSS 而非类和变量。
过度复杂的代码
AI 可能生成冗余代码或不必要的功能。
示例
：每次 CSS 修改后，我都需手动删除大量冗余样式；生成复杂的 Web 组件，远超当前需求。
结论
我的经验表明，
一年内 AI 绝无可能自主编写 90% 的代码
。它能辅助编写 90% 的代码吗？或许对某些团队和代码库成立。
目前，在一个中等复杂度的 1.5 万行的代码库中，AI 能辅助我完成 80% 的工作。
如何防范 AI 编程失误？
那么，怎样在享受 AI 编程助手带来的便利时，保护软件和团队免受 AI 工具的不可预测性影响？
个人开发者
1、 始终仔细审查 AI 生成的代码。我几乎每次都能发现需要修复或改进之处。
2、 当感到 AI 编程过程失控时立即停止。要么修改提示词重新开始，要么回归手动实现。
3、 警惕那些短时间内奇迹般生成的“足够好”的方案，它们往往会带来长期维护成本。
4、
实践结对编程
。四只眼睛比两只看得更清楚，两个大脑比一个更少自满。
团队与组织
1、
传统代码质量监控
。如果尚未部署，应安装 Sonarqube 或 Codescene 等工具检测代码异味。虽然无法覆盖所有问题，但能构建安全网的基础。某些代码异味（如代码重复）在 AI 工具中会更突出，需加强监控。
2、
预提交钩子与 IDE 集成代码审查
。尽可能实施左移策略——利用 Pull Request 阶段或流水线中的代码审查、语法检查和安全扫描工具。但在开发过程中直接发现问题效果更佳。
3、
重温代码质量实践
。针对本文所述陷阱及团队实际遇到的问题，建立强化措施来减轻后两种影响半径。例如创建"失误日志"记录 AI 代码引发的团队摩擦或维护问题，每周复盘。
4、
制定自定义规则
。多数编程助手支持配置规则集或随提示词发送的指令。团队可利用这些功能迭代基准提示指令，将最佳实践制度化。但需注意，AI 未必会遵循规则，对话越长、上下文窗口越大，效果越不稳定。
5、
建立信任与开放沟通的文化
。我们正处于技术颠覆工作方式的转型期，每个人都是新手。具备信任文化和开放沟通的团队更能应对技术带来的脆弱性。例如，因"有了 AI"就施压团队加速交付的组织，更容易面临质量风险；而高信任度和心理安全感的团队，开发者更易分享 AI 使用中的挑战，推动团队更快学习工具潜力。
网友评论
这篇文章在 HackerNews 引发热议，小程程摘录两个留言：
网友 ikerino
最近我大部分开发工作都在使用 Cursor。这篇文章与我的体验高度吻合。补充几点：
1、
AI 知识停留在 2021 年
直观感受是，AI 代理的知识似乎卡在了 2021 年左右。当我安装较新的软件包时，Claude 会回退到四年前流行的过时包或实现方式。这种情况既令人沮丧又需要反复纠正。虽然通过明确指定使用哪些包可以缓解问题，但无法根治。
2、
错误的不可预测性
几个月前，我用 Claude“一键生成”了一个功能完整、打磨得相当不错的 Web 应用——要是我自己开发可能需要几周或几个周末。但当我要求它用提供的文件更新网站图标时，它却徒劳地折腾了一个小时（最后我自己花了几分钟解决）。几天前，我尝试用类似方式生成另一个 Web 应用，在与代理纠缠了约 4 小时后，我几乎想彻底放弃这段代码。
3、
降低尝试门槛，但高质量产出仍需努力
AI 让我有勇气尝试那些原本因时间、技术或动力不足而不会启动的项目。低摩擦开发确实令人兴奋，但构建有价值的产品依然困难重重。即使有 AI 辅助，打磨出一个像样的 MVP 仍需投入大量精力。
4、
龟兔赛跑的启示
依赖 AI 代理的诱惑在于初期进展看似极快，但最终我往往觉得：如果用更慢、更专注的方式开发，反而能取得更扎实的成果。手工编程时，我很少需要回溯或推翻整个方案；而使用 AI 驱动的方式，速度可能提升 10 倍，但中途要丢弃约 70% 的工作。
“我的经验表明，一年内 AI 绝无可能自主编写 90% 的代码。它能辅助编写 90% 的代码吗？或许。”
完全赞同。当前环境很像自动驾驶汽车的炒作周期——有很多大胆承诺（也有真实进步），但未来五年内，我看不到 AI 能独立写出有用软件的可能性。
网友 ferguess_k
我其实不太喜欢 IDE 里的 AI 功能。我不希望它们替我思考。代码补全和智能感知已经足够了。
不过，我认为有三个重要事项需要注意：
1、
快速掌握新框架或语言
由于 AI 的帮助，人们可能会期望你能更快做到这一点。掌握时间的上限可能从原来的“最短时间”变成“最多两周”，对初级开发者也是如此。
2、
聚焦核心问题
与其花时间记忆一年只用几次的 Shell 脚本，不如把精力放在学习更基础的知识上。你可以用 AI 辅助学习入门。如果是为了面试准备，花一周时间死记硬背也无妨。
3、
主动排除 AI 的思维干扰
如果所有事情都依赖 AI（包括算法和设计），可能会影响你对问题的理解深度。
关于 AI 编程助手，各位程序员都有哪些心得呀，欢迎大家留言讨论。
- EOF -
