企业官网建设流程全解析

如果你最近在刷技术社区，大概率会反复撞见一个名字：DHH。这位Ruby on Rails的创始人、Basecamp的联合创始人，最近在AI编程、Agentic工程、Vibe Coding和Linux这几条赛道上来回投下重磅表态，搞得很多开发者一边看他热闹，一边心里犯嘀咕——一个写了二十年Ruby的老家伙，凭什么对AI和操作系统指手画脚？

我认真看了他的分享，也把自己平时用AI写代码、折腾Linux桌面的经验摆在一起对照，发现这人是真做过功课的。他不是站在岸上喊口号的评论员，而是真把AI编程塞进了自己公司的日常开发流程，也真把自己的主力机从Mac切换到了Linux。这篇文章我就想顺着他的思路，把这四个话题拆开聊清楚：DHH的底气来自哪、Vibe Coding到底在说什么、Agentic工程该防的坑有哪些、以及Linux桌面这波热度是不是真的值得跟进。

1. 一个写了二十年Ruby的人，凭什么对AI编程发言

1.1 DHH这名字为什么在技术圈有分量

先给不太了解背景的朋友补一句。DHH全名David Heinemeier Hansson，最著名的身份是Ruby on Rails框架的创造者。这个框架诞生于2004年左右，靠"约定优于配置"的理念，把Web开发的入门门槛拉低了一大截，直接催生了一整代创业公司和独立开发者。GitHub、Shopify、Airbnb这些响当当的产品，早期都跑在Rails上。

他后来运营的Basecamp（曾经的37signals）是一家极度反传统的软件公司，团队只有几十人，却在SaaS领域活得非常滋润。他还写过《重来》（Rework）这本书，核心观点之一是"小团队、少开会、快交付"，在创业圈影响了一大批人。也就是说，DHH谈AI编程、谈工具选型，背后站着的是"框架作者+公司经营者+一线开发者"三重身份，不是键盘评论员。

1.2 他说AI编程时的核心立场是什么

DHH对AI编程的态度可以浓缩成一句话：AI不会取代程序员，但会用AI的程序员会取代不会用AI的程序员。这句话听起来有点像老生常谈，但放在他自己身上是有一套完整逻辑支撑的。他反复强调，AI编程最大的价值不是自动生成整块业务代码，而是把人从"重复表达已知方案"中解放出来，让程序员把精力放在真正需要人类判断力的事情上。

他举过一个很实际的例子：写常规CRUD接口、配路由、定义数据模型，这些工作占传统开发很大比例，但几乎没有创造性。AI在你描述了字段和关系之后，可以快速给出符合Rails惯例的代码。你不用一行行敲，只需要审查、调整、确认。这个过程的本质是"意图表达"替代了"机械编码"。

我在自己的项目里也验证过这个说法。之前给一个内部工具写导出Excel的功能，传统做法是查文档、写POI操作、调样式，至少得折腾两三个小时。我把需求、字段、文件格式要求扔给AI编程工具，它第一版就给出了能跑的代码，我只需要改一改列宽和日期格式。花的时间不到原来的三分之一，而且我对逻辑依然有完全的控制权。

1.3 DHH的实践场景：不是所有团队都适合ALL IN

难得的是，DHH并没有把AI编程吹成无所不能。他自己运营的Basecamp虽然已经大规模使用AI辅助开发，但他很清醒地区分了两件事：AI适合用在"有明确规格、低风险、可快速验证"的任务上，比如脚本工具、接口模板、数据处理；但涉及核心业务逻辑、真实资金流转、用户隐私判断的场景，人类把关是不可替代的。这个口径和我平时给团队的建议几乎一模一样。

所以我的看法是：DHH的发言之所以值得认真听，不是因为他给出了什么金科玉律，而是他以一个实际经营公司、实际维护框架的人的身份，给出了一个相当务实的坐标——技术圈讨论AI编程时经常两极分化，天天用AI自动写代码的人觉得传统开发是古董，没怎么用过AI的人又担心自己即将失业。DHH站在这两者中间，给了我们一条更冷静的路。

2. Vibe Coding不是偷懒，是重新分配注意力

2.1 先说清楚这个词的实际含义

Vibe Coding是近两年才流行的开发风格，说起来很玄，实操却很简单：你不一定知道每一行代码怎么写，但你清楚自己想要的"氛围"和"结果"，于是你用自然语言描述目标，让AI编程工具帮你把代码生成出来。整个过程像是指挥一个能力极强但偶尔会跑偏的实习生，你负责描述"我要什么样的感觉"，它负责把这些感觉翻译成可运行的代码。

DHH对这个词的感情比较复杂。他不太喜欢Vibe这个单词带来的"凭感觉、不严谨"的语义，但他完全认可这种工作流背后的效率优势。他真正在意的是：代码生成之后，你依然要能看懂、能审查、能重构。也就是说，Vibe Coding不代表你可以放弃对代码的责任感，它只是把注意力的分配方式从"写"转向了"选"。

2.2 我实测的Vibe Coding流程，以及它为什么快

我从今年初开始有意把Vibe Coding引入日常开发，现在的标准流程是这样的：先写一段自然的意图描述，包括功能目标、输入输出、约束条件，再加上我期望的技术栈和代码风格；然后让AI编程工具生成初版代码；接着我逐行过一遍，重点检查边界条件、异常处理和安全性；最后补齐测试用例并提交。

这套流程里最花时间的已经不是"写代码"了，而是"提需求"和"审代码"。上个月我让AI编写一个内部数据同步脚本，需求描述花了40分钟，AI生成只用了几分钟，我审查修改又花了半小时。但放在传统模式下，这种与第三方API对接、带重试机制和日志追踪的脚本，我至少得写一天。Vibe Coding在这里的价值是实打实的。

2.3 但有三盆冷水，泼给准备ALL IN的人

第一盆冷水：AI生成的代码看着很顺眼，但坑都在细节里。我遇到过AI把字符串拼接当成日期格式化、自动引入了一个并不存在的第三方库、处理并发时悄悄丢掉了锁的情况。如果没有代码审查习惯，Vibe Coding就是在埋雷。

第二盆冷水：需求表达不清晰的时候，AI生成得越快，返工越猛。我不是没试过省事，丢一句"写一个用户注册接口"给AI，结果它给了一套邮箱密码注册逻辑，而我想要的实际上是手机号验证码注册。所以我现在坚持把需求写充分再让AI动手，这反而逼着我养成了更好的需求分析习惯。

第三盆冷水：Vibe Coding的工具链更新太快。今天用的提示词技巧，下个月模型升级后可能完全失效。热搜词里大家都在搜"ai编程提示词"，说明很多人已经发现提示词写得好不好，直接决定AI输出质量。但我要提醒一句，提示词技巧是表层能力，真正的底层能力还是你对系统架构和业务流程的理解。AI生成代码越来越快，但判断"这段代码是否真的正确"的能力，会越来越值钱。

2.4 写好Vibe Coding提示词的几个要领

关于提示词，我总结了一套还算实用的方法。第一，给出角色和上下文，比如"你是一个熟悉Rails 7的资深后端工程师"；第二，明确输入输出样例，好的提示词一定有例子；第三，列出限制条件，比如"不要引入新的Gem包"、"兼容Ruby 3.2"、"必须处理空值"；第四，告诉AI你期望的代码组织方式，是放在model里还是service对象里；最后，要求它解释关键设计决策。这套方法不能说百分百稳定，但比随手丢一句话的结果要靠谱得多。

3. Agentic工程的边界：AI替你做，但你不能不问

3.1 从补全代码到自动执行任务，Agentic到底改变了什么

如果说Vibe Coding是"人提需求、AI写代码"，那Agentic工程就是"人提目标、AI跑整个任务"。它不再局限于补全函数、生成文件，而是让AI代理自主拆解任务、调用工具、修改代码、运行测试，甚至在失败后自己调整策略重试。听起来很科幻，实际上头部AI编程工具已经具备雏形了，你给它一个Issue描述，它可以自己读仓库代码、定位问题、给出补丁。

但DHH对Agentic的态度明显比对Vibe Coding要谨慎。他不是反对AI代理，而是反对"全程托管"。他打过一个比方：你可以让实习生去帮你写初稿，但不能让他替你在合同上签字。AI代理最适合的工作状态，是被人为切成一段段小任务，每段完成后由人类确认再进入下一段。他管这个叫"人在环上"，不是"人在环外"。

3.2 让AI代理开荒踩出来的真实教训

我吃过一次比较疼的亏。有个老项目积压了一批技术债，我图省事，把"重构用户认证模块"整个任务扔给了AI代理，让它自主分析代码、生成改动方案、执行修改。前几步它干得挺好，读代码、列计划、改测试都像模像样。但到了中间阶段，它因为某个测试用例失败，自作主张改动了一个公共工具函数的签名，结果连锁反应导致其他模块大面积报错。那一刻我意识到，AI代理在没有人工审查节点的情况下，会像一个非常自信但缺乏全局观的新手，为了眼前的目标不惜破坏周围的生态。

从那以后，我给自己定了三条规矩。第一，任何AI代理执行的任务必须被拆小，单次任务控制在半小时可审查的范围内；第二，所有改动必须过一遍diff再合入，关键模块还要加Code Review；第三，测试套件永远是最后的守门员，我不信任AI代理的自我评估，我只信任跑过的测试结果。

3.3 嵌入式等特殊场景的Agentic，坑更多

热搜词里有个组合很有意思：嵌入式vibe coding。我猜不少人想用AI编程去写嵌入式C代码，用自然语言描述功能让AI生成底层实现。这个想法很好，但实际踩坑概率比Web开发高得多。嵌入式代码依赖具体的芯片手册、寄存器定义、中断优先级、内存布局，这些信息散落在几十页文档里，AI不一定能准确理解。我让AI写过一个I2C通信的初始化代码，它生成的逻辑看起来很像回事，一查芯片手册，寄存器地址完全是错的。

嵌入式Linux开发的朋友会更清楚，一个驱动模块的问题往往要结合内核版本、硬件时序、设备树配置综合判断，这些恰恰是AI最不擅长的领域。所以我对嵌入式场景的AI编程建议是：可以用它处理协议解析、日志分析、单元测试这类局部任务，但涉及硬件底层的代码，人类的经纬度才是兜底。

3.4 DHH真正反感的，是"责任外包"

把DHH关于Agentic的言论串起来，他的核心诉求其实是责任。AI代理可以自动执行大量繁琐步骤，可以让开发效率再上一个台阶，但"这个功能到底该怎么设计、这个改动到底会不会引入回归、这个需求到底该不该做"这些问题，传统上由工程师承担的判断责任，不能跟着任务一起外包给AI。谁签字，谁负责，这个原则放在AI时代依然适用。

4. 从Mac到Linux：DHH转身背后的桌面端机会

4.1 为什么一个知名开发者要折腾换系统

DHH公开表示把日常主力机从Mac切到Linux，这个新闻在开发者圈子里讨论度相当高。他给出的理由一部分很务实，比如对苹果硬件定价和内存策略的不满、对MacOS日渐封闭的不满，但更深层的动机是他一直信奉的开放精神——作为一个长期和技术大厂保持距离的开发者，他更愿意把日常开发环境押注在完全开放的操作系统上。

我个人是在Arch Linux上长期当主力系统的，看到DHH的表态时有一种"终于有人把窗户纸捅破"的感觉。很多人以为开发者换Linux就要忍受各种天荒地老的折腾，但以我自己的体验，2025年的Linux桌面已经和十年前完全是两个物种了。日常写作、代码开发、视频播放、终端操作，这些高频场景的问题都已经解决了。

4.2 Linux桌面现在到底能干什么

我给三个维度的真实评价。第一个维度是开发体验，这个Linux本来就是最强的，完整的Unix工具链、包管理器、容器支持、多桌面环境，写代码的幸福感远超MacOS和Windows。热搜词里常年挂着"linux常用命令大全"、"linux 部署 clickhouse"之类的内容，说明服务端运维已经是Linux的主场，桌面端只是把这个优势顺延回来而已。

第二个维度是办公和设计。现在主流浏览器、视频会议、Office套件都有Linux版本，我用WPS和OnlyOffice处理文档完全够用；设计软件仍然是短板，Figma用网页版扛一下还可以，但重度依赖Adobe全家桶的设计师转过来会很痛苦。第三个维度是游戏和娱乐，Steam的Proton兼容层让很多Windows游戏能跑，但偶尔还是需要折腾Proton版本、显卡驱动，技术门槛比Windows高。

4.3 迁移的成本与收益账，我帮你算了一遍

如果你心动了，先别急着格式化硬盘。我给你一个参考路径：第一步，在虚拟机里装一个Linux发行版，先用两周时间熟悉日常命令和工作流；第二步，把你常用的工具列个清单，逐个确认有没有Linux替代方案；第三步，准备一块独立硬盘装双系统，在真实的硬件环境下跑一到两个月；第四步，确认没什么致命的不可替代依赖后，再彻底切换。

这个流程我自己走了一遍，踩过最大的坑排名如下：显卡驱动的安装、中文输入法配置、多屏幕显示器的缩放适配、以及蓝牙耳机的连接稳定性。Linux的社区文档能力很强，这些问题都有解决方案，但确实需要花时间搜索和试错。热搜词里"linux安装搜狗输入法命令"、"linux 共享上网 办法"这类问题常年有人搜，也侧面印证了这些问题有多普遍。

4.4 DHH这波转向的真正信号意义

DHH的个人行为当然不能代表行业趋势，但它传递了一个信号：当足够多的资深开发者开始认真对待Linux桌面，整个生态的进度就会被重新审视。硬件厂商会更积极适配驱动，软件厂商会更认真对待Linux用户的需求，这和十年前"开发者在Linux上只能当小众玩家"的局面完全不同。

而且Linux在AI时代有一个天然的位置——本地跑开源模型、挂载NAS、搭AI推理服务、部署自动化的开发环境，所有这些重计算任务，在Linux上的效率和自由度都是最高的。热搜词里"linux 挂载nas存储"、"linux镜像"长期热门，实际上说明越来越多的人不是在聊天里讨论Linux，而是真的在用它搭建自己的基础设施。DHH的转向，只是把这股暗流推到了聚光灯下。

5. AI时代开发者的自处之道：工具越强，品味越贵

5.1 担心失业之前，先看看AI替代了什么

打开任何一个社区，都会看到"AI快把程序员岗位搞没了"的焦虑贴。但你要是真的去观察AI编程工具的实际表现，会发现它们替代的恰恰是那些重复度高、信息量低、没有判断门槛的编码劳动——这种劳动本来就在贬值，被AI替代是早晚的事。真正难替代的是"你在一个模糊业务问题面前，能把它结构化、拆解、设计成可验证的技术方案"的能力。

DHH有句话我特别认同：未来程序员的竞争力不在于你能记住多少API，而在于你有没有判断力。写代码的门槛在降低，因为AI可以完成初稿；但判断"这段代码是否符合业务意图、有没有安全风险、是不是最优方案"的门槛反而在升高。工具越强，品味越贵。

5.2 具体到每天的工作流，我是这样调配AI的

我现在的工作流可以分成三档。低风险任务走全自动，比如生成数据字典、编写琐碎的工具脚本、批量改文件格式；中等风险任务走半自动，比如实现一个小功能模块或者修复一个明确的bug，我会给AI充分的需求背景，然后自己审查每一行diff；高风险任务基本人类主导，AI只当参考，比如核心架构设计、权限模型规划、数据库迁移方案。

这个分档逻辑背后就一句话：AI的参与度和任务的后果成正比。越容易出大事的地方，越要把人类放在决策链上。我也见过反着用的人，让AI去改生产数据库迁移脚本，然后不审直接执行，这种操作纯属给自己埋雷。

5.3 给个人开发者和团队的两份行动清单

如果你是个人开发者，我建议按这个顺序推进：先把一两款主流AI编程工具装进日常编辑环境，强迫自己用两周；然后挑一个小型项目，完整走一遍"需求描述-生成-审查-重构"的Vibe Coding流程；最后把AI生成的代码片段沉淀成自己的模板库，慢慢形成适合自己项目的提示词风格。

如果你在带一个团队，我更关注的是流程层面：先把代码审查规范明确，任何AI生成代码都必须走和人类代码相同的Review流程；然后给团队建一个共享的提示词库和踩坑日志，让每个人在AI使用上的经验能复用；最后设置一个实验性项目，低风险、高透明度，让团队在真实项目里打磨对AI工具的掌控力，而不是只在业余时间自己玩。

5.4 工具会迭代，判断力不会过时

技术圈的热点向来一阵一阵，今天Vibe Coding，明天Agentic工程，后天不知道又会蹦出一个新词。但落到每一个具体开发者身上，我需要的是不管工具怎么变，阅读代码的能力、识别风险的能力、站在业务角度做取舍的能力，这些东西永远不会过时。

我在实际使用中发现，把AI编程工具用好的前提，恰恰是那些被人视为"过时"的计算机基础，数据结构、算法、网络协议、操作系统原理。AI可以在你描述需求后瞬间生成候选代码，但它不会替你理解为什么这段代码在某些边缘情况下会出问题。你越懂底层，和AI的配合就越流畅。这也算是我这几年折腾下来最值钱的一条经验了。