1. 从DHH的几个判断看AI辅助开发的真实面貌DHH这个名字在开发者圈子里不需要过多介绍。Ruby on Rails的缔造者、37signals的联合创始人、Basecamp与HEY的核心开发者最近他在AI编程这个话题上连续输出了一批观点配合“Agentic工程”“Vibe Coding”这些热词反复出现再结合Linux未来的讨论说实话这套组合拳打下来信息量比大多数AI工具评测要大得多。先说说他到底在讲什么。DHH的核心态度可以浓缩成几个判断AI写代码这件事已经真实地进入了生产环境不是demo、不是玩具AI生成代码的最大问题不是“写得不对”而是“你根本不知道它为什么这么写”所以人类工程师的审查能力反而变得更加值钱而所谓的Agent化开发他更多强调“让AI干活、但别让它做决定”权责边界必须画清楚。为什么他的观点值得关注因为他既不是卖AI工具的厂商也不是纯技术象牙塔里的研究者。37signals是一家真实盈利的软件公司DHH在HEY、Basecamp这类实际产品里用AI辅助开发他的结论来自具体项目的真实摩擦而不是PPT。这一点非常关键——AI编程话题下太多人要么是厂商布道师要么是还没写过几行生产代码的评论员DHH属于少有的“亲自下场、拿真项目说话”的一类。这篇文章我想把这些观点拆开揉碎结合我自己在不同规模项目里用AI辅助开发的经历把“AI编程到底改变了什么、没改变什么”“Agentic工程的正确打开方式是什么”“Vibe Coding为什么能火又为什么危险”这几个问题讲透最后聊聊Linux在这个浪潮里的位置。2. AI编程工具选型与核心工作流重设计2.1 从补全到生成AI编程工具的能力边界现在说“AI编程”早就不只是IDE里那个会自动补全括号的函数了。以GitHub Copilot为代表的第一代工具本质是“更聪明的自动补全”它根据上下文推荐下一段代码。到了ChatGPT时代尤其是GPT-4之后工具形态从“补全”变成了“生成”——你描述需求它直接给你一个完整函数、一个测试用例、甚至一个项目的骨架。这两者的差别是质变。自动补全的假设是“代码逻辑由人决定AI只负责减少打字量”生成的假设是“需求可以被描述AI负责把描述变成结构”。后者意味着体力活被大幅替代但同时也意味着一个新的问题浮出水面描述本身的质量决定了生成代码的质量。我实测下来这一代AI编程工具的能力边界大概是这样结构化程度高的代码API封装、CRUD、配置文件、ORM模型生成质量极高基本能到“直接可用的80%”算法逻辑复杂、依赖大量上下文推断的代码生成质量迅速下降容易出现“看起来对、跑起来错”的情况代码重构和跨文件修改AI的表现取决于项目结构和上下文利用方式差距极大写测试是AI的强项尤其是边界条件和异常路径的覆盖比很多初级工程师记得还全DHH在一次访谈里说的那个比喻我很认同AI写代码的能力已经相当于一个“积极性很高的初级开发者”它能在几分钟内完成一个初级工程师需要一天才能做完的活但你必须给它明确的验收标准。这句话里藏着两个关键点第一它确实能干活第二它依然是“初级”你需要审。2.2 提示词工程描述需求才是真正的门槛顺着上面的话说AI编程的核心技能已经从“怎么写代码”变成了“怎么描述需求”。这就是“ai编程提示词”这个东西为什么能成为搜索热词的原因——大家都在找那把能把AI潜力撬出来的钥匙。我总结了一套在实际项目里验证过的提示词写法拆开来看其实不玄第一背景信息要给足。不要只说“写一个用户登录接口”要说清楚“这是一个Rails API项目用户模型已存在使用Devise管理认证登录成功后需要返回JWT tokentoken有效期设为24小时”。给AI的上下文每多一层输出质量就上一个台阶。第二约束条件要显式化。不用的库、不动的文件、必须遵守的命名规范、需要兼容的Ruby版本——这些统统写在提示词里。AI不像人它不会主动问你“这个项目里有没有现成的工具函数”你必须在指令里堵住它的自由发挥空间。第三要求AI先解释思路再写代码。这是个很实用的技巧在提示词里加上“先说明你的实现思路确认后再写代码”。这会强制AI进行“思维链”推理输出质量在复杂任务上会有肉眼可见的提升。我自己最常用的一套模板是这样的项目背景[项目类型、技术栈、关键依赖] 当前状态[已有代码结构、相关文件、待修改位置] 任务描述[要做什么输入输出是什么] 约束条件[禁止事项、必须遵守的规范、兼容性要求] 验收标准[如何判断完成有没有测试要求] 输出格式[代码文件路径、是否解释思路、是否需要测试用例]这套模板看起来简单但它把“上下文、任务、约束、验收”四件事一分为二AI的幻觉率会明显下降。如果你现在还在用一句话命令AI写代码我建议你先在提示词上花半小时收益比换工具大得多。2.3 代码审查前置人机协作的新岗位AI辅助开发普及之后团队里最稀缺的能力不是“写代码的能力”而是“判断代码好坏的能力”。DHH有一个很有名的观点AI生成代码带来的最大威胁不是失业而是一大批开发者逐渐失去“为什么这样写是对的”的判断力。我自己的体会是代码审查这件事必须前置到AI生成的那一刻而不是等AI写完再审查。具体做法是每次让AI生成代码先要求它输出实现思路而不是直接给代码对关键路径的代码必须要求AI给出测试用例甚至先写测试再写实现任何AI生成的代码合并前必须经过一次完整的走查不能直接信任测试通过这些规则会牺牲一部分效率但换来的是代码库的可维护性。前面说AI像“积极性很高的初级开发者”你对初级开发者不会说“你写的我都不看直接上生产”对AI也一样。3. Agentic工程实战智能体协作的正确打开方式3.1 什么是Agentic工程以及它和单次问答的区别Agentic工程有时也叫智能体工程是最近半年到一年集中爆发的一个概念。简单说它解决的不再是“给AI一个任务让它生成一段代码”而是“给AI一个目标让它在多步骤、多工具、多决策的场景里自主推进”。用生活化的类比来解释单次问答像是你请了一个顾问问一句答一句Agentic工程像是你雇了一个实习生给他一个目标他自己去查资料、写方案、做实验、汇报进展、根据反馈迭代。这个差别决定了工作方式完全不同。单次问答的输入是“问题上下文”输出是“答案”Agentic工程的输入是“目标边界条件”中间会经历反复的探索、试错、修正最后输出的是“结果过程记录”。目前市面上的Agent工具形态各异有的在IDE里比如Cursor的Agent模式有的在命令行里比如各类CLI agent有的作为独立应用存在。但无论形态怎么变背后的核心机制是一致的大模型调用工具、读取反馈、根据反馈调整计划、多次迭代直到达成目标。3.2 划清权责边界为什么不能让AI自主决定这里就到了DHH观点最有争议也最有价值的部分。他在不同场合反复强调AI可以执行任务但不要让它做决策。具体到Agentic工程里我的理解是执行层面的自主性可以放开。代码重构、测试编写、日志分析、数据迁移脚本这类“怎么做已经明确”的任务完全可以交给Agent去执行它会做得又快又不出错。决策层面的自主性必须收回。要不要引入这个依赖、这个重构方向对不对、架构上该选哪个方案这些涉及“为什么要这么做”的问题必须由人来做决定。原因很简单AI的“决策”本质上是概率预测它没有产品意识、没有商业语境、没有长期维护的体感。它可能会做出“看起来合理但商业上是灾难”“技术上正确但产品上跑偏”的决定而且它会非常自信地执行下去。3.3 一个Agentic工程的落地样本我最近在做的一个嵌入式Linux项目里比较系统地用了Agent来辅助做一个复盘。项目背景是一个边缘网关设备ARM架构资源受限需要把采集的数据经过协议转换后上云。我们的Agent任务设置是这样的给它一个明确的代码库告诉它需要在哪个模块增加MQTT断线重连功能并且要求它先分析现有代码结构输出改造方案等确认后才执行修改。Agent的表现相当有意思。它花了几分钟读代码输出了一个改造方案方案里不仅指出了要改的位置还提出了一个我们没有注意到的点——现有的数据缓冲队列在断线重连时可能溢出。这个发现是有价值的因为它在“读代码”这件事上比人快得多、全得多。但接下来它暴露了问题在具体实现重连逻辑时它引入了一个新的第三方库来管理定时器。这个库功能确实强大但对于一个资源受限的嵌入式系统多一个依赖意味着多一层维护成本和潜在的系统调用开销。我们审完之后决定不用这个库直接用系统自带的timer接口实现。这就是Agentic工程里最典型的场景AI负责探索和初稿人负责决策和把关。它提了一个方向你判断方向是否合适如果不合适你给出修正让它继续。这个“人机协作、AI执行、人做决策”的模式在效率上的提升是明显的如果换成传统开发方式光读那套历史包袱很重的代码库就要一上午。3.4 Agent失败模式与防御策略Agent系统用多了会遇到几类反复出现的失败模式列出来供你参考第一类是“过度自信执行型”。Agent在中间步骤遇到障碍时倾向于自己编造一个解决方案继续往下走哪怕这个方案和最初的约束条件矛盾。应对方法是设置检查点每个大步骤让Agent输出中间结果人确认后再继续。第二类是“上下文丢失型”。Agent处理多轮交互时早期的目标和约束会被慢慢遗忘越到后期越容易出现偏离。应对方法是在提示词里定期重述约束或者用结构化格式比如固定的“记忆块”让Agent持续回看原始目标。第三类是“工具滥用型”。Agent会倾向于调用各种工具库来“简化问题”在嵌入式或资源受限场景里这是致命的。应对方法是在约束条件里明确列出“禁止引入新依赖”“只能在现有技术栈内实现”。这些防御策略看起来就是在给AI“上紧箍咒”但实际经验告诉我这些都是必要的。Agent的自主性是工具不是目的不能用自主性换取可控性。4. Vibe Coding的现象拆解为什么火、有什么坑4.1 Vibe Coding的准确含义与误读“Vibe Coding”这个术语是Andrej Karpathy在2025年初提出的火得极快。他的原意是描述一种编程方式你完全沉浸在“氛围”里放弃对细节的过度关注凭直觉推进遇到问题就让AI帮忙解决而不是自己死磕每个技术细节。这个词被大量传播之后含义发生了偏移。很多人把Vibe Coding理解为“用AI写代码自己完全不懂代码也行”甚至有人把它当成“零基础也能当程序员”的宣言。搜索热词里“vibe coding下载”这种词都能出现说明很多人以为Vibe Coding是一个可以下载安装的软件——这个误解本身就说明问题了。我理解Karpathy的原意更多是“放下对代码的执念把精力放在产品体验和直觉判断上”它讨论的是有经验的开发者如何调整心态而不是“不懂技术的人如何变成开发者”。这个区别很关键前者是在已有能力基础上换一种工作方式后者是绕开基础能力直接追求结果。4.2 Vibe Coding的适用场景与危险场景实测下来Vibe Coding方式在特定场景下确实高效原型验证阶段你需要快速验证一个想法有没有戏这时候“让AI快速生成、手动调整、再生成”的循环非常高效个人项目、小工具、脚本类代码出了问题自己修修不好扔掉重来代价低非核心业务的内部工具能用就行没人在意代码风格学习探索阶段通过AI生成代码来理解某类技术是怎么实现的但在这些场景里Vibe Coding是灾难生产环境的核心业务系统需要长期维护、多人协作的代码库涉及支付、安全、数据合规的模块任何“出了问题会出大事”的场景这两个清单的差异不是技术层面的而是风险层面的。Vibe Coding本质上是“用更高的返工概率换取前期的速度”在风险承受力高的场景划算在风险承受力低的场景致命。4.3 Vibe Coding的隐性成本顺着风险话题说很多鼓吹Vibe Coding的人不会提它的隐性成本。我在多个项目里看到了同样的规律第一是技术债的快速堆积。AI生成的代码质量参差不齐风格不一致没有人为逻辑连贯性负责。三个月后你回头看这段代码会发现它已经变成了一个没人完全理解的“代码沼泽”。第二是调试难度的上升。同类问题手写代码你大概率知道问题出在哪个模块AI生成的代码你可能连它是怎么拼装起来的都不清楚。排错时间的增加会慢慢吞噬掉前期省下的时间。第三是能力的逐步退化。这是最隐蔽也最危险的成本——习惯Vibe Coding之后开发者对底层机制的理解会逐渐淡化遇到文档查不到、AI也不知道的问题就会卡死。4.4 一句话评价Vibe Coding像是一种“创意状态”适合在有安全网的环境里探索不适合作为生产环境的默认工作方式。它和Agentic工程的关系不是替代而是上下游Vibe Coding负责发散探索Agentic工程负责结构化交付人负责判断什么该发散、什么该收敛。5. Linux在AI编程时代的位置与前景分析5.1 为什么AI编程浪潮反而让Linux更重要话题转回Linux。搜索热词里Linux相关的高频词极其丰富linux常用命令、linux面试题、linux系统安装、嵌入式linux、linux进程间通信、linux部署中间件……这说明Linux的学习和使用需求依然旺盛而且这个需求正在被AI编程浪潮反向放大。背后逻辑其实很清晰AI生成的代码跑在哪里绝大多数跑在Linux服务器上。AI训练模型的算力集群用什么系统绝大多数是Linux。AI开发工具链Docker、Kubernetes、Jupyter Notebook、各种CI/CD工具的原生环境是什么答案是Linux。有人说“AI会让我们不再需要学技术”现实恰好相反AI让我们更容易地写代码但这些代码要运行、要部署、要维护依然离不开Linux技能。AI编程没有消灭Linux需求反而把Linux从“运维工程师的工具”变成了“所有AI应用开发者的底层能力”。5.2 Linux与AI开发工作流的实际交集我自己在AI辅助开发的实际工作流里体会到Linux能力和AI应用成效是直接相关的Agent类的工具绝大多数要在Linux环境下跑得最顺畅Windows下的兼容性问题层出不穷数据预处理、模型推理、日志分析这些AI辅助开发里常见的任务Linux命令行工具的效率和能力远超图形界面Docker容器化是AI应用交付的主流方式而Docker的核心操作都是在Linux内核能力之上实现的无论你用Cursor还是Copilot还是其他AI工具最终代码要跑起来、要调试大概率还是SSH到一台Linux服务器上操作这些交集意味着Linux技能是AI时代开发者的硬通货不是所谓的“过气技能”。5.3 嵌入式Linux是AI落地的最佳载体之一热搜词里嵌入式Linux相关的内容非常多这背后是AI向边缘端渗透的大趋势。云端AI的能力再强数据要实时处理、网络不稳定时要本地决策、隐私数据不能出设备这些场景都会导向边缘计算而边缘设备上的系统绝大多数是嵌入式Linux。在嵌入式Linux里做AI和纯云端的玩法完全不同。第一是算力约束你没有一个强大的GPU集群兜底必须在CPU、内存、存储都受限的环境里把AI推理跑起来。第二是实时性约束很多场景对延迟有硬性要求模型再准推理慢到实时性不达标就完蛋。第三是稳定性约束设备部署后可能几年不重启运行时的稳定性和内存泄漏控制是生死线。DHH虽然没有深入谈嵌入式Linux但他强调的“AI是工具、工程判断是核心”这个思路恰好也是嵌入式AI开发里的真理。模型选型、量化方案、推理框架调优、边缘场景的corner case处理这些都不是AI自己做的——AI负责加速实现人负责决定方向。5.4 Linux未来的挑战和确定性Linux会消失吗这个话题每隔几年都会有人拿出来讲。但现实情况是Linux的生态不仅没有萎缩反而在AI时代获得了新的增长极。从服务器端看Linux在云原生和AI基础设施领域的地位比五年前更加稳固。从桌面端看虽然消费级市场依然是Windows和macOS的天下但Linux桌面在开发者群体中的渗透率持续上升。从嵌入式看物联网设备、边缘网关、车载系统、智能硬件到处是Linux的身影。Linux面临的挑战也不是没有。国产发行版的热潮带来了一些生态碎片化的问题桌面体验和软件生态依然是短板驱动兼容性在老设备上依然头疼。但从整体趋势看Linux在AI基础设施层面的地位不降反升这个确定性很高。6. 常见问题与避坑心得6.1 AI编程最容易被忽视的五个坑我自己用过不同种类的AI编程工具也在多个项目里踩过不少坑整理出来给你第一个坑是盲目信任测试。AI生成的代码如果带测试这些测试往往是AI“自己验证自己”很容易出现“测试和代码一起错”的情况。我的习惯是关键代码的测试自己写或者至少测试用例里加上几个AI没想到的边界输入。第二个坑是忽略版本兼容性。AI训练数据里的库版本和理解的最新版本之间可能存在差异它会用旧API给你生成代码跑在新版本上直接报错。解决方案是提示词里写清楚版本信息并且养成“生成完先跑一遍依赖检查”的习惯。第三个坑是项目上下文缺失。AI工具如果只看到当前打开的文件它给的答案大概率是片面的。最好的做法是给工具足够的仓库级上下文或者手动把相关的文件内容、接口定义贴进去。第四个坑是重构时的“连带破坏”。AI重构一个函数时往往只关注这个函数本身不去扫描它被哪些地方调用。结果就是函数改好了调用它的地方全挂了。提示词里明确要求“列出所有受影响的调用点并验证”能大幅减少这个问题。第五个坑是让AI直接改生产代码。这个基本属于事故高发区AI在没有完整上下文的情况下修改生产代码等同于一个不看文档的新人直接改线上。任何AI修改先在本地、在分支里完整跑通了再合并。6.2 Linux工作流里AI能帮你做的事和不能做的事AI在Linux工作流里的帮助主要体现在这几个方面解读日志一个grep加一个AI解释效率提升极其明显、生成shell脚本、解释报错信息、分析进程状态、排查系统问题。比较典型的一个例子系统出现性能问题时以前你是扛着top、vmstat、iostat的输出一个个对照现在可以把输出直接给AI让它帮你判断瓶颈方向。AI虽然不能替代你理解系统机制但在模式匹配和常见问题速查上比搜索引擎好用得多。但AI在Linux上也有明显的不能复杂内核问题的追踪、驱动开发和调试、分布式系统里跨节点的疑难杂症这些领域AI能给的帮助非常有限需要靠真正的底层理解。所以我的建议是别因为用了AI就把基础技能扔掉AI越普及深度能力越稀缺。6.3 实操经验AI辅助Linux运维诊断的一个真实案例分享一个实际案例。之前维护的一台服务器内存占用持续走高找不到原因。传统做法是SSH上去用free查内存、用ps按内存排序、查进程日志一套组合拳打下来效率还是低因为系统里跑的服务太多。这次我换了个思路。先用free输出当前内存状态再用ps aux按内存占用排个序把输出存下来然后把这些信息丢给AI分析。AI很快指出有一个进程的内存使用比正常值高了一个量级而它对应的服务近期没有更新过建议排查它是否有内存泄漏。顺着AI给的线索我们查了那个服务的日志发现确实有一个bug导致连接清理逻辑失效。这次诊断流程AI节省的时间主要在于模式识别它在几秒钟内识别出了一个人类需要一条条看、对照经验判断才能发现的异常点。6.4 快速排查速查表做运维或开发时间长了会积累一套自己的排查路径。加上AI辅助后这套路径的效率提高了很多整理成表格供你参考场景传统手段AI辅助方式效果服务异常退出journalctl查日志、dmesg看内核信息把日志片段给AI让它提炼错误类型和可能原因AI能快速匹配已知故障模式性能瓶颈top/vmstat/iostat逐项对照把系统状态输出给AI请求瓶颈分析AI擅长多指标联合判断配置错误手动对比配置项和经验判断把配置文件给AI要求它按最佳实践审查能发现遗漏的约束项进程异常ps/htop逐一排查提供进程列表和资源占用AI找出异常特征模式识别优于人眼逐一排查当然AI给的分析还需要人来复核给它当辅助可以完全不设防地照单全收迟早出事。7. 写在最后的一点个人体会聊了这么多AI编程、Agentic工程、Vibe Coding和Linux的话题最后说一点我个人最真实的体会。技术工具迭代得越来越快今天的热词明天可能就过时了但有一件事不会变工具替代的是重复劳动不是判断力。DHH的观点里最打动我的不是他对AI有多乐观也不是他有多保守而是他始终在强调——工程师的价值在于知道“什么是好的”、知道“为什么这样做”而不是在于“能多快地写出代码”。我自己在这段时间的实践里最大的变化是从把AI当成“搜索引擎的增强版”进化到把AI当成“一个需要管理的团队成员”。它干活快、态度好、从不抱怨但需要你给它明确的目标、清晰的边界、持续的过程监督。管理AI这件事本身正在成为开发者技能树里一门新的必修课。至于Linux我的立场很朴素只要服务还在跑、容器还在起、数据还在存Linux就是那个绕不开的底座。AI时代编程的门槛确实在降低但深度理解底层系统的能力反而因为稀缺变得更加值钱。有句话说得好“潮水退去才知道谁在裸泳。”AI这个潮水正在涌来愿我们都能在它退去之后依然站得住。
