企业官网建设流程全解析

开头可以先从一个真实的疲惫感写起：你面前站着三个差不多的框架，文档都写得很好，社区都活跃，但团队里已经有人开始站队。有人主张用 A，有人说 B 更稳，还有人翻出 C 的 benchmark 说性能最好。这时候你旁边有人随口说：“要不问问 AI 吧？”于是你真的打开了某个对话式 LLM，把问题抛了过去。它很快给了你一个答案，看起来还挺有道理。

但如果你真的照着它说的选，心里又总觉得不踏实——因为它不了解你们团队的底子，不了解你这个项目的真实约束，甚至不了解你们老板说的“下个月就要上线”意味着什么。我最近就做了一轮类似的测试：让几个主流 LLM 在流行开发者工具之间做选择，然后把它们的回答翻来覆去看了看。结论是：LLM 能帮你把决策的起点往前推一大截，但真正拍板的还得是你自己。

1. 把问题摆清楚：我们到底想让 LLM 解决什么

工具选择这个事，看起来是在找“哪个更好”，实际上是在找“哪个更适合我的处境”。大多数技术人心里都清楚，前端框架没有绝对的最优，数据库也不是多跑一分才赢。真正决定结果的往往是那些没法写进 benchmark 的因素：团队里谁会维护遗留代码、运维能力到哪个水位、这个项目三年后还要不要被其他人接手。

但在很多讨论里，这些因素会被简化成一张又一张对比表格。网络上充斥着“你应该选 X 因为 Y”的文章，而且很多文章的数据已经过期，或者结论来源于某个特定场景。你要花很多时间去验证信息是不是还成立。这时候 LLM 天然有吸引力：它能整合大量公开资料，给出结构化的回答，还不会不耐烦。

我之所以做这轮实验，就是想搞清楚一件事：LLM 给出的工具选型建议，到底能站到什么位置？是能当咨询顾问，还是只能当搜索摘要？所以我设计了一组问题，让几个主流对话式 LLM 在几个有代表性的工具类别里做选择，包括前端框架、后端语言、关系型数据库、ORM、CI/CD 工具，以及代码编辑器。

1.1 看起来是“选择题”，其实是“约束求解”

你如果只看表面，会觉得让 LLM 做选择就是把问题抛过去，让它说一个名字。但真实项目里的工具选择，从来不是一道单选题。它至少包含四个层次：

• 项目约束：团队规模、部署环境、性能要求、预算和时间。
• 团队能力：现有成员熟悉什么，学习新技术的成本有多高。
• 生态成熟度：插件、社区、招聘难度、长期维护者数量。
• 组织风险：许可证、供应商锁定、合规要求、历史包袱。

LLM 很难主动把这些约束问全。如果你不写在 prompt 里，它就会默认按照“一个典型的、有一定经验的团队在通用场景下的最佳实践”来回答。这个默认值不一定错，但它可能根本不适用你的处境。

2. 我怎样设计了这轮“AI 工具选型评测”

为了不让测试变成一次聊天，我控制了一些变量。我没有使用联网插件，没有给它额外的网页搜索结果，只靠模型自身的参数知识来回答。因为我想知道它“脑子里”默认的推荐是什么，而不是它临时去搜索到的内容。

2.1 工具范围与提问方式

我选了六类开发工具：

• 前端框架：React、Vue、Svelte、Solid
• 后端语言/框架：Node.js、Python/Django、Go、Rust
• 关系型数据库：PostgreSQL、MySQL、SQLite
• ORM：Prisma、TypeORM、Drizzle
• CI/CD：GitHub Actions、GitLab CI、Jenkins
• 代码编辑器：VS Code、JetBrains IDEs、Neovim

针对每一类工具，我先问了一个“最泛”的问题：

我们团队要开始一个新项目，需要在上面这些选项中做选择。假设没有其他限制，你会推荐哪个？为什么？

然后，我会追加两类问题：

• 加约束：如果团队只有三个人，而且都只会 JavaScript，你会调整建议吗？
• 换立场：如果这是一个会被长期维护五年、会经历多次人员更替的企业项目，谁会变得更合适？

这样我能看到模型在接收到不同上下文后，会不会调整输出，以及它的理由是否足够落地。

2.2 我用来读回答的四个评价维度

我没有只盯着模型推荐了哪个工具，而是更关注它怎么解释推荐。我给自己定了一套评分思路，你也可以拿去做自己的测试：

这套框架后来比具体的工具名更有用。因为它让我意识到，LLM 之间的差距不在“智商”，而在“它是否把选型当成了一个有约束的工程问题来对待”。

3. 测试结果里，有哪些惊喜和陷阱

我不打算把每个模型的回答逐字复述出来，因为这类信息会在几个月后过时。我更想说的是那些在多次测试里稳定出现的规律。

3.1 主流选择：稳定，但很难带来超越常识的价值

在没有附加约束时，几个 LLM 的推荐高度重叠。前端基本都会推荐 React，理由是生态庞大、招聘容易；后端会在 Node.js 和 Python 之间摇摆，但很少一开始就推荐 Rust 或 Go；数据库几乎是无脑推 PostgreSQL；CI/CD 则普遍倾向 GitHub Actions；编辑器则在 VS Code 和 JetBrains 之间来回。

这个结果不让人意外。因为模型学习的语料里，这些主流选项本身就占据了大量篇幅。你可以说它是在“最大概率地猜测一个平均正确的答案”。对刚起步的小项目来说，这个答案确实不差。但问题在于：如果所有人都只会得到这个答案，那么“让你和竞争对手拉开差距”的信息增量就不存在了。你得到的不是“对你最合适的建议”，而是“对所有人最安全的建议”。

3.2 加入约束后：开始出现分化

当我在 prompt 里追加“团队只有三个人且只熟悉 JavaScript”后，模型的反应开始出现明显区别。

有的模型能立刻调整：它会把 Node.js 放到最前面，说明前端后端统一语言的沟通成本最低，同时会提醒你数据库选型不要用力过猛，比如用 PostgreSQL 而不是在早期引入太多基础设施。这种回答像一个有经验的架构师在帮你压低复杂度。

但也有不少模型只会做“表面尊重”：它会先说“理解了，如果团队只会 JavaScript，那 Node.js 会更合适”，但接下来几百个字依然在原封不动地复述 React、PostgreSQL、GitHub Actions 的推荐理由。它没有真正把约束作为权重去重新计算方案，只是先给了一个顺从的结论，后面还是默认叙事。

这个现象很重要。因为它说明 LLM 并不是不知道上下文，而是它的“上下文理解”和“知识输出”经常是两条线。你在前面设定了限制，它嘴上记住了，但后面的推理过程并没有真正受这些限制约束。

3.3 换立场后：很多回答会自相矛盾

更有意思的是立场反转测试。当我问“如果这是一个要维护五年、且会有多次人员更替的企业项目”，同一个模型的回答有时候会和自己上一轮的答案发生冲突。

例如在无约束场景里，它推荐了某个以灵活著称的后端框架，因为上手快。但当你强调“长期维护”时，它又会建议换成一个更保守、更静态类型的方案。这本身是合理的。但如果你把两个回答并排放在一起看，就会发现它不会主动向你解释“为什么同一个项目会从方案 A 变成方案 B”。你不追问，它就不说。

用工程师的话讲，这叫做“模型不会主动做敏感性分析”。它只会回答你当前问题本身，而不会告诉你它的结论是建立在哪些假设之上。这也意味着，如果你不清楚自己该问什么，你很容易得到一个看似精确、实则脆弱的答案。

3.4 一个容易忽略的坑：输出看起来越专业，越容易让你停止思考

我在测试里发现一个现象，当 LLM 给出一个结构完整、有小标题、有“利弊分析”、甚至还有“建议实施步骤”的回答时，我的第一反应是“这回答好完整”。但冷静下来拆开看，里面很多内容只是把公共文档里常见的话换了个顺序。

这不是说它没用，而是它制造了一种“已经思考过了”的错觉。真实的选型讨论里，很多关键信息是藏在团队的沉默里的：某个人不想维护某个技术栈、某个技术负责人有历史包袱、某个客户强制要求部署在指定环境。LLM 不知道这些，它只知道把这些话省略掉之后，剩下的“理性讨论”仍然很流畅。所以用 LLM 做选型最危险的地方不是它说错，而是它说得太顺，让你忘记了它缺少你掌握的那些信息。

4. 从回答里总结出的四层规律

如果把这次测试当作一次小型用户调研，我会用“四层规律”来概括我的观察。这一层一层递进，基本可以解释为什么 LLM 在工具选型里能帮上忙，但还替代不了人。

4.1 第一层：信息整合能力确实能打

让一个新手去网上搜索“前端框架对比”，可能要翻几十个网页才能形成一个全局印象。LLM 可以在几秒钟内把各方观点压缩成一份结构化的摘要，而且口吻像是一位对行业有了解的人。

这一点在候选工具数量较多、资料分散的时候特别值钱。它相当于帮你做了一遍“粗略的文献综述”，让你在一开始就能看到这盘棋上有哪些棋子，而不是被某个搜索引擎的首页带偏。

4.2 第二层：它缺少真正的“团队上下文”

团队上下文包含很多东西：现有代码库的年龄、团队的心理模型、组织里谁做主、历史上踩过哪些坑、客户的偏好。这些信息通常不会写进技术博客，也不会被收录进训练语料。LLM 只能通过你在 prompt 里给的描述来理解，但 prompt 能承载的上下文始终有限。

你可以在对话里补充团队规模、技术栈、项目周期、部署环境，但这本质上是你在主动喂信息。它不会像高级顾问一样主动问你“你团队里有几个高级工程师”“你们现有的基础设施是什么”，所以它的建议始终是在你给定的信息框里打转。

4.3 第三层：理由倾向于“主流叙事”，而不是“反直觉判断”

真实世界里有大量反直觉的工具选择：某个小组明明可以用 PostgreSQL，但为了兼容某个老系统而选择 MySQL；某个团队前端没用框架，但比很多用框架的团队更灵活。这类选择往往是多重约束下的结果，很难用一句“因为社区大”来解释。

LLM 在回答时倾向于给出“政治正确”的主流理由，因为它学的语料里，这些理由出现频率最高。如果你不提供反例，它不会主动为你挖掘“这个团队可能因为什么原因放弃最主流方案”。这导致它的建议在常规场景里很稳，但在需要打破常规的场合，参考价值有限。

4.4 第四层：对复杂约束的推理不稳定

如果你给 LLM 的约束超过三个，比如“团队五人、全部远程、项目需符合金融合规、部署环境在客户私有云、半年内上线”，它的推理质量会明显下降。它可能会记住前两个约束，却把后面几个丢掉。

这不是某一家的模型特有的问题，而是当前语言模型在处理多约束组合时的一个共性弱点。它更像一个知识面很广的讨论者，而不是一个能同时权衡十个变量的决策引擎。在选型这类多目标优化问题里，它能帮你梳理候选，但最终加权和取舍仍然需要人的判断。

5. 我建议的“人机协作选型流程”

既然我们把 LLM 的边界摸清了，那实际使用时就更可以把它放在一个合适的位置上。我试着沉淀了一套流程，可以在自己的项目里反复用。这套流程的核心是：先让 LLM 开视野，再用人来加约束，最后再用小型验证收尾。

5.1 第 1 步：让 LLM 生成候选清单和选型维度

不要上来就问“我该选哪个”，先让它“列出所有值得考虑的候选，并给出你认为重要的对比维度”。这样能获得一张更完整的认知地图。

我需要为一个新项目选型。候选包括：A、B、C、D。 请先不要给出最终推荐。 先帮我列出： 1. 这类工具里还有哪些值得关注的候选？ 2. 对于我这个场景，最重要的 6 个评估维度是什么？ 3. 用这 6 个维度给所有候选做一个粗粒度的对比表。 注意：不需要你直接推荐，我只需要结构化的信息。

这一步的价值不在于它给你的表格有多准确，而在于它会逼你思考：我是不是漏掉了某个候选？我是不是漏掉了某个维度？

5.2 第 2 步：人工过滤出三到五个关键约束

拿到候选清单后，停下来。不要急着让它继续推荐。先自己写一张卡片，写下这个项目最关键的约束。约束包括：

• 团队熟悉的技术栈是哪些？
• 部署环境是否有硬性限制？
• 项目生命周期是几个月还是几年？
• 团队规模会不会快速扩张？
• 有没有合规、安全、数据驻留要求？
• 现有代码和基础设施有哪些必须兼容？

这个过程最好在线下独自完成，或者和团队一起完成。因为一旦你把这些写清楚，后续和 LLM 的对话质量会完全不同。

5.3 第 3 步：把约束回喂给 LLM，让它做压力测试

这一步你可以把约束作为一条新的 prompt 发给 LLM，不是为了要它给出终极答案，而是为了让它基于这些约束去挑战前面生成的对比表。

以下是我这个项目的真实约束： - 团队 5 人，其他人主要写 JavaScript，只有 1 人熟悉 TypeScript。 - 部署在客户私有云，不能使用外部托管服务。 - 项目计划维护至少 5 年，会有人员更替。 - 需要满足基本的日志、审计和权限管理要求。 基于这些约束，重新评估你之前给出的对比表： 1. 哪些候选应该被排除？为什么？ 2. 哪些候选的优先级应该上调？为什么？ 3. 每个候选在“长期维护”和“团队上手成本”上分别会有什么潜在问题？

你会发现，一旦约束具体化，模型的回答会比第一次空洞的推荐更有信息量。它会开始提到“私有云部署限制”“长期维护需要类型系统”“团队上手成本”这类实际因素。虽然不是所有判断都准确，但至少它把该讨论的点都摆了出来。

5.4 第 4 步：不要让模型代替你拍板，做一次最小验证

最后一步，也是最关键的一步：挑出对它和团队共识都排在前两名的方案，各自做一个最小可运行验证。可以是一个简单页面、一条接口、一个数据库迁移脚本、一条 CI 流水线。

小验证的意义不是看谁性能更好，而是让团队成员亲手碰一遍，感受它的生态、调试体验、报错信息，以及和自己以往经验的匹配程度。这个过程产生的体感，是任何 LLM 回答都无法替代的。

不要忽略这一步。很多工具看资料是一回事，真正上手时的“摩擦感”只有你自己知道。

6. 什么时候别听 LLM 的建议

我并不是说 LLM 选型在任何场景都没用，我甚至认为它会成为团队早期讨论的很好起点。但有几类场景，它给出的建议风险会特别高，你需要额外警惕。

6.1 关乎安全与合规的强制要求

模型的知识来自公开资料，而你的合规要求可能写在某个不公开的内部文档里。比如某个行业要求审计日志必须保存在特定数据库、某个客户要求用特定身份认证方案。这类信息 LLM 不可能自己知道。如果你的选型直接关联安全合规，只能把它当作信息整理工具，最终裁决必须由有权限做合规判断的人给出。

6.2 已有大量历史代码和核心业务逻辑

如果你面对的是一个已经跑了五六年的系统，现在要在“继续演进”和“推倒重来”之间做选择，LLM 的建议会显得过于理论化。它不会知道你某个老模块里有多少隐含逻辑，不会知道某个看似可替换的组件背后牵动了多少个业务流程。这种时候，最好的顾问是那些在公司里待了很久的工程师，而不是一个对项目一无所知的模型。

6.3 团队有强烈的技能偏好或厌恶

如果你知道团队里有一半人极度讨厌某个工具，那无论 LLM 怎么论证它技术优越性，你都要慎重。技术选型从来都是组织行为，团队成员的配合度和长期士气，比某个工具多了几个能力点更重要。LLM 不会为你的团队情绪负责，它只会从资料分布里找出最“理性”的那套答案。

6.4 你需要为一个“不可逆”的决定背书

有时候技术选型本身不可逆，比如投入巨大成本建立一套数据中台、引入一个强锁定效应的云服务。这种决定的权重远超一个模型能够衡量的范围。如果你要为自己的职业信誉背书，请至少让一个“技术判断之外”的角色参与进来，比如财务、法务或业务负责人。LLM 回答不了“这家供应商是不是值得长期合作”，更回答不了“如果合作出问题，我们有什么应对方案”。

7. 回过头看：LLM 在这件事里到底算个什么角色

我的判断是，LLM 不是裁判，也不是导师，它更接近一个“知识渊博但缺乏责任感的讨论者”。它可以快速给出背景、对比、观点，也会偶尔冒出一句很有启发性的提醒，但它永远不会因为你做的决定而承担后果。你采纳了它的建议，出了问题，它不会出现在复盘会上。

这听起来像是在泼冷水，但恰恰因为这样，它才变得有用。当你意识到它不会为你的决定负责时，你才会更认真地去审视它的理由、核查它的前提、补上它缺失的上下文。这个过程本身，就是一次比“问一个答案”更有价值的选型训练。

真正重要的也许不是让 LLM 告诉你选 React 还是 Vue、用 PostgreSQL 还是 MySQL，而是它倒逼你把问题拆开：你到底需要解决什么问题？你有哪些限制条件？哪些信息是它不知道的？当你把这些想清楚之后，即使最后选错了，你也知道错在哪里，下次可以做哪些修正。

这也是我把这套测试整理出来的原因。下一次再有人问我“哪个工具更好”，我不会直接说答案。我会先把那张写着约束的卡片拿出来，然后才决定要不要让 LLM 参与这场讨论。