企业官网建设流程全解析

2025 年 2 月，Andrej Karpathy 创造了"vibe coding（氛围编程）"这个词：描述你想要什么，让 AI 写代码，然后忘掉代码的存在。它迅速走红。每个人都想相信编程已经变得像说话一样简单。

一年后，Karpathy 给它改了名。新术语是：“agentic engineering（智能体工程）” 。他的解释很尖锐。"用’工程’来强调其中存在艺术、科学和专业技能。“他在几周内从 80% 手动编码转为 80% 智能体编码，并痛苦地发现模型是"参差不齐的”——在难题上表现出色，却在显而易见的地方栽跟头。

数据支持他的观点。GitClear 的 2025 年代码质量研究 发现，AI 共同撰写的 pull request 比纯人工 PR 的问题多 1.7 倍。复制粘贴的代码行从 2021 年的 8.3% 上升到 2024 年的 12.3%。与此同时，AI 现在撰写了 GitHub 上 41% 的代码，Copilot 付费订阅者达到 470 万。

我们产出的代码比以往任何时候都多。它也从未如此充满 bug。这不是生产力的繁荣。这是以复利利率增长的技术债务。

Matt Pocock 在他的 AI Hero 大会演讲中直言不讳：“代码并不廉价。糟糕的代码从未如此昂贵。”

他的理由是：如果你的代码库难以修改，你就无法吸收 AI 的输出。每一个建议、每一个生成的函数、每一个自动重构都会撞上糟糕架构的摩擦。AI 不会修复结构性问题。它会放大它们。

核心论点是：AI 是乘数，不是魔杖。它会放大你放在它面前的任何架构。好的结构在每次交互中都能带来更多价值。坏的结构在每个提示中都会加速腐烂。

五项软件基础原理将那些自信交付的团队与那些淹没在 AI 生成意大利面条代码中的团队区分开来。没有一项是新的。它们从未如此重要。

1. 构建前先对齐

Karpathy 指出了 AI 编码智能体的四种结构性失败模式。第一种："模型会替你做出错误假设，然后不加检查地继续执行。"你以为自己只是要一个简单的 API 端点。AI 却构建了一个包含认证、速率限制和你从未提及的数据库迁移的微服务。

问题不在于 AI 的能力。而在于你和 AI 没有共享关于你正在构建什么的思维模型。

Frederick Brooks 在The Design of Design中写过这个问题。他称之为"设计概念"——关于你正在创造的东西的隐性的、共享的理论。它不是文档。不是规格文件。它是合作者之间关于他们正在构建什么以及为什么构建的理解。当两个人结对编程时，他们通过对话自然地建立这种理解。当你向 AI 发出提示时，这种共享理解默认不存在。

Pocock 的解决方案是一个他称之为"grill me（拷问我）"的 Claude Code skill。整个指令只有两行：

无情地就这个计划的每个方面采访我，直到我们达成共同理解。沿着设计树的每个分支走下去，逐一解决决策之间的依赖关系。

它迅速走红。GitHub 上获得了 97,000 多颗星。AI 会提出 40、60、有时甚至 100 个问题才满意。它将智能体变成一个不会让你跳过思考的对手。

原理：不要让 AI 开始编码，直到你们共享了思维模型。写好简报，定义约束，先回答难题。你花 20 分钟对齐节省的是 3 小时撤销错误假设的时间。

2. 说同一种语言

如果在计划上对齐了，但你和 AI 用同一个词表达不同的意思，那还是不够的。

Karpathy 的第二种失败模式：“过度复杂的解决方案。要一个 10 行的函数，得到一个 200 行的企业级框架。”

AI 不是恶意的。它只是不知道你的词汇表。当你说"handler"时，你是指 HTTP handler、event handler，还是 log handler？当你说"service"时，那是微服务、后台 worker，还是一个类？AI 会猜。它猜错了。然后它建造了一座 200 行的错误猜测纪念碑。

这是软件工程 20 年前就解决的问题。Eric Evans 在 2003 年出版了Domain-Driven Design，核心概念就是"ubiquitous language（通用语言）"——开发者、领域专家和代码库本身都一致使用的共享词汇。每一次对话、每一个变量名、每一个 API 端点都用相同的术语表达相同的意思。

Evans 最近告诉 InfoQ："在限定上下文的通用语言上训练语言模型，相比使用通用 LLM，对特定需求要有用得多。"你的领域词汇表现在成了提示工程的资产。

Pocock 也为此构建了一个 skill。他的"ubiquitous language（通用语言）" skill 扫描你的代码库，提取术语，并生成一个充满定义表格的 markdown 文件。他报告说，通过阅读 AI 的思考轨迹，通用语言不仅改善了规划。它让 AI思考得更简洁。更少的 token 浪费。更准确的实现。生成的代码真正匹配了计划。

DDD 的限定上下文在这里也适用。在多智能体设置中，不清晰的术语所有权会导致"上下文泄漏"——智能体互相踩到对方的领域，重复逻辑，或者输出相互矛盾。Evans 20 年前在人类团队中描述的相同失败模式，现在在智能体编排中重现。

原理：构建一个词汇表。精确定义你的领域术语。在你的项目文档和提示中引用它。如果 AI 知道"order"在订单管理上下文中意味着"客户承诺"而不是"排序指令"，它就会停止猜测，开始生成适配的代码。

3. 先测试，小步交付

你们已经在计划上对齐了。你们说着同一种语言。AI 构建的正是你要的东西。但它不工作。

这是最耗时的失败模式，因为代码看起来是对的。读起来不错。变量名有意义。但一运行就崩溃，因为 AI 一次性产出了 400 行代码，没有检查其中任何一行。

The Pragmatic Programmer称之为"超出你的车灯范围"。反馈速率是你的速度限制。开得比车灯照得远，你就会撞上没看到的障碍。AI 智能体默认是关灯驾驶的。它们产出大量代码，然后才想起来验证。

Anthropic 的 最佳实践 推荐 writer/reviewer 模式：“一个 Claude 写测试，另一个写代码来通过测试。” OpenAI 的 Codex 文档 说得更直白：“没有测试，Codex 用自己的判断来验证工作。测试创造了外部真相来源。”

两个平台得出了相同的答案：测试驱动开发。不是作为哲学。而是作为强制 AI 小步前进的机械约束。

先写测试。让 AI 让它通过。重构。Red-green-refactor 不是敏捷时代的遗物。它是防止熵增的反馈循环。每个循环的成本只是大批量重写的一小部分，无论是 token、上下文窗口空间，还是你自己的审查时间。

2025 年 5 月的一篇 arXiv 研究 发现，随着智能体从独立脚本转向多模块系统，代码异味密度增加。没有测试边界，腐烂会随着代码库规模扩大。有了它们，每个模块保持诚实。

原理：与 AI 一起编码时，TDD 不是可选的。它是保持输出可信的速度限制器。写测试，让智能体实现，验证，重复。小循环，高信心。

4. 建深，不建宽

即使测试通过了，正确的东西也在构建中，随着代码库增长，还是会出现结构性问题。AI 开始迷路。它找不到正确的文件。它误解依赖关系。它做出的改动会破坏三个模块之外的东西。

John Ousterhout 在A Philosophy of Software Design中描述了这个问题。他区分了 deep modules（深模块）和 shallow modules（浅模块）：

• Deep modules 在简单接口后隐藏了大量功能。你不需要理解内部就能使用它们。
• Shallow modules 则相反：功能不多，但接口复杂，迫使你理解底层的一切。
  AI 智能体特别擅长生成 shallow modules。大量小文件，每个做一件小事，每个暴露多个函数，每个依赖另外三个小文件。看起来干净。代码审查时读起来不错。但它给下一次 AI 会话创造了导航噩梦，因为智能体必须遍历几十个相互连接的 blob 才能理解你的代码实际在做什么。

Pocock 在演讲中直观地展示了这一点。充满 shallow modules 的代码库看起来像散落的点，之间有纠缠的箭头。同样的代码重组为 deep modules 后，看起来像几个大块，顶部有简单的连接。AI 在第二种结构中导航并生成更好的代码，因为它可以推理接口，而不必将每个实现细节加载到上下文窗口中。

关于 AI 生成代码异味的 arXiv 论文 也实证证实了这一点。随着智能体从独立脚本转向多模块系统，代码异味密度增加。LLM 在推理时不会跟踪架构复杂性。你的模块结构越碎片化，AI 的输出就越差。

这里也有市场信号。TypeScript 在 2025 年 8 月成为 GitHub 排名第一的语言。部分原因是：类型良好、结构良好的代码让 AI 辅助开发更可靠。开发者正在自我选择那些能放大 AI 回报的架构，就像多元化投资组合能放大市场回报一样。那些固守无类型、碎片化代码库的人正在返工中付出代价。

原理：审计你的代码库中的 shallow modules。将相关代码包装成具有简单接口的 deep modules。在边界处测试。AI 不需要看到一切。它需要看到正确的接口。

5. 设计接口，委托实现

如果前四个原理保护 AI 输出的质量，这一个保护你自己。

如果你在使用 AI 编码工具后感到比以往任何时候都更精神疲惫，请举手。你不是一个人。Pocock 在大会上问了同样的问题。几乎所有人都举了手。

疲惫来自于试图审查一切。每一个生成的函数、每一个重构的类、每一个智能体创建的新文件。你正在交付比以往更多的代码，但你的大脑仍然是理解所有代码的瓶颈。

Kent Beck 的建议：“每天投资于系统设计。”

specs-to-code 运动做的是相反的事。它从设计中撤资。它将代码库视为从提示中重新生成的可丢弃输出。这就是你最终审查 400 行你没写过且几乎跟不上的代码的原因。

替代方案是灰盒模型。你拥有接口。你拥有边界处的测试。你让 AI 处理模块内部的内容。对于非关键模块，你不需要审查每一行实现。你需要验证契约是否工作。

这就是 Karpathy 所说的，新核心技能是"判断力——委托什么、如何指定、如何快速审查"。你写更少的代码不是因为懒。你写更少的代码是因为你把时间花在了架构、接口和验证上。战略层面。

Pocock 将其框定为战术程序员和战略程序员之间的区别。AI 是战术程序员，是地面上的中士，做出代码改动。你是思考系统设计、模块边界以及各部分如何组合的人。这不是降职。这是升职。

Anthropic 的内部数据显示，在大规模重构任务上有 2-3 倍的生产力提升。但这些提升来自那些足够信任架构从而自信委托的团队，而不是那些审查每一行生成代码的团队。

原理：写接口。指定契约。将实现委托给 AI。通过测试验证，而不是逐行代码审查。你的工作是系统设计。让智能体处理其余部分。

6、工具包：从原理到实践

没有工具的 principles 只是建议。以下是你今天就能安装的东西。

Pocock 将他的 skills 作为 开源仓库 发布。每一个都直接映射到上述原理：

• grill-me在 AI 写任何东西之前强制共享理解（原理 1）
• ubiquitous-language扫描你的代码库并构建领域词汇表（原理 2）
• tdd在每个模块上强制执行 red-green-refactor 循环（原理 3）
• improve-codebase-architecture识别 shallow modules 并将它们包装成 deep ones（原理 4）
• writer-prd在 PRD 中指定模块变更和接口契约（原理 5）
  但这些原理不只是某个开发者的个人意见。主要平台独立构建了基础设施来强制执行相同的理念。

Anthropic 的 Claude Code 使用 CLAUDE.md 作为对齐契约，支持将子智能体限定在具有干净上下文窗口的隔离任务中，并推荐 writer/reviewer 模式，一个智能体写测试，另一个写实现。OpenAI 的 Codex 出于相同目的使用 AGENTS.md，带有明确的"done when"标准，强制智能体在认为任务完成之前进行测试验证。GitHub Copilot 的 agent mode 构建了你仓库的语义索引（比 2025 年初的检索准确率高 37.6%），并支持自定义智能体和提示文件作为可复用的蓝图。

三个平台。相同的结构性答案。对齐文档、测试循环、模块边界。它们都趋同，因为它们都撞上了同一堵墙：模型能力不是瓶颈。代码架构才是。

7、贯穿始终的主线

Brooks 在 1975 年写了关于共享设计概念的内容。Evans 在 2003 年出版了通用语言。Ousterhout 在 2018 年画出了深模块图。Beck 几十年来一直在说"每天投资于设计"。

Karpathy 在几周内，在压力下，使用地球上最强大的 AI 模型进行构建时，发现了同样的教训。Pocock 将它们提炼成 skills，这些 skills 之所以走红，是因为成千上万的开发者认出了自己的痛苦。

这些都不是新知识。这就是重点。

一个聪明的提示给你一次好的输出。一个结构良好的代码库给你一千次。每一个干净的接口、每一个强制的测试边界、每一个深模块都会放大之后的每一次 AI 交互的价值。跳过架构，你就是在复利债务。

代码并不廉价。你的架构就是你的 AI 策略。

原文链接：用软件工程放大你的 AI 产出 - 汇智网