分类目录归档：架构和远方

AI 编程后，软件的本质复杂度会有变化吗？

最近一直在深度使用 AI 编程，从完全无代码的开发哥网站，到 AI 生成后台代码；从 Cursor 到 Trae AI，能明显感受到 AI 可以帮我写大量代码。最多的时候，5 个小时写了超过 2000 行可以运行的代码。但一个奇怪的感受是，尽管 AI 让代码生产更快了，软件开发的复杂度却没有降低，项目的构建需要的心力依然和以前一样。

这让我不禁思考：AI 真的在降低软件开发的复杂度吗？还是说，复杂度只是被转移了？

1. AI 编程 ≠ 复杂度消失，而是复杂度转移

在《人月神话》中，布鲁克斯提出了软件开发的四大本质复杂度：复杂度、一致性、可变性、不可见性。即使 AI 能够自动生成代码，这些复杂性依旧存在。

业务复杂性：AI 可以帮我们写代码，但它无法自动理解业务规则的变化。例如，一个 AI 生成的电商促销规则，可能在逻辑漏洞下导致「满 100 减 200」这样的错误，造成严重损失。
技术复杂性：AI 可以优化 SQL 查询、生成索引，但 AI 生成的代码仍然可能隐藏性能瓶颈，甚至带来更高的架构耦合度。
治理复杂性：AI 代码的可维护性、可解释性，仍然是一个巨大的挑战。AI 生成的代码往往不是“最优解”，而是“看起来能跑”的解。

AI 并没有消除软件开发的复杂度，而是将其转移到了其它的层面：

传统复杂度	AI 时代的复杂度转移
人工编写 CRUD 代码	提示工程（Prompt Engineering）
手动优化数据库索引	AI 生成索引，但需要人类调优
代码逻辑的可读性	AI 生成的代码可能变成「黑盒」
需求沟通的精确表达	需要用更严谨的自然语言指导 AI

2. AI 让开发更快，但项目建设更复杂

布鲁克斯认为，软件开发的困难分为根本困难（Essential Complexity）和次要困难（Accidental Complexity）：

根本困难：软件本身的固有复杂性，不会因技术进步而消失。
次要困难：开发过程中人为引入的复杂性，如编程语言、工具、调试方式等，可以通过技术优化。

AI 编程主要解决的是「次要困难」，但无法消除「根本困难」。让我们来看看布鲁克斯提出的软件开发四大根本困难，以及 AI 编程是否真的能克服它们。

2.1 复杂度（Complexity）

布鲁克斯认为，软件的复杂度源自以下几个因素：

组件交互的指数级增长（比如微服务架构）。
代码状态的激增（如并发编程）。
业务逻辑的无限变化（如金融风控规则）。
缺乏对整个系统的全局掌控能力。

AI 确实能快速生成代码，但它无法减少软件的业务复杂性。 例如：

AI 可以帮你写一个支付系统的 API，但它无法理解跨境支付的法律法规，仍然需要人类去设计合规架构。
AI 生成的代码可能没有考虑到以前没有见过异常情况，导致后期维护困难。

结论：AI 不会减少软件的复杂度，只是让代码生产更快，但架构和业务逻辑的复杂性依然存在。

2.2 一致性（Consistency）

软件必须兼容历史系统、旧数据、第三方 API 和用户习惯，这导致：

新系统必须适配旧架构。
代码风格和 API 设计必须保持一致。
数据格式、协议、接口规范不能随意更改。

AI 可能会破坏一致性，而不是增强一致性。

AI 生成的代码风格可能不统一，团队成员需要额外时间进行重构。
AI 可能会引入隐性的兼容性问题，导致老系统无法正常运行。

结论：AI 不能自动保证代码和系统的一致性，反而可能引入新的不兼容问题。

2.3 可变性（Changeability）

软件必须不断适应需求变化：

政策法规变化（如 GDPR 隐私保护要求）。
新业务功能增加（比如直播带货）。
技术栈升级或迁移（比如从 MySQL 迁移到 PostgreSQL 等）。

AI 确实可以加速代码变更，但它无法理解业务变更的深层逻辑：

AI 可能会机械地替换代码，但不会思考整体架构是否需要调整。
AI 可能会优化单个函数，但不会考虑整个系统的长期演进。

结论：AI 可以加速代码变更，但无法主动适应业务变化，反而可能增加技术债务。

2.4 不可见性（Invisibility）

软件不像建筑或者机械产品那样，可以从物理空间上直观理解。软件的结构是逻辑性的，导致：

沟通困难：不同开发者对系统的理解可能不同。
调试困难：AI 生成的代码可能变成「黑盒」，难以分析问题。
架构复杂化：AI 生成代码可能会引入隐形的设计缺陷。

结论：AI 代码的「黑盒性」可能让软件的可见性更差，导致调试和维护的挑战更大。

3. AI 编程的真正价值：降低「次要困难」

虽然 AI 无法消除软件的根本复杂度，但它确实在减少次要复杂度（Accidental Complexity），包括： ✔ 代码生成：AI 可以帮你写 CRUD、API、测试代码，提高开发效率。
✔ 调试辅助：AI 可以自动分析日志、找出潜在 Bug。
✔ 文档生成：AI 可以自动补充代码注释，提升可读性。
✔ 代码优化：AI 可以推荐更优的算法或 SQL 查询，提高性能。

但与此同时，AI 也引入了新的复杂度： ❌ Prompt 设计复杂度：如何写出好的 Prompt，才能让 AI 生成高质量代码？AI 代码质量很大程度上依赖于输入的提示（Prompt），这意味着开发者需要掌握新的技能，比如如何编写高质量的 Prompt。 ❌ AI 代码治理：如何审查 AI 生成的代码，防止安全漏洞？
❌ 技术债务：AI 可能会生成「能跑但难维护」的代码，如何管理长远的架构演进？ AI 可以帮助我们快速生成大量代码，但如何组织这些代码、保证架构的可维护性，仍然是开发者的责任。

4. 未来开发者的核心竞争力：驾驭 AI，而不是被 AI 取代

AI 编程时代，开发者的角色正在改变：

过去，开发者的价值在于写代码。
未来，开发者的价值在于驾驭代码复杂度，利用 AI 高效开发。

开发者的三大新技能

✅ 语义工程：如何用精准的 Prompt 让 AI 生成高质量代码？

AI 代码质量的高低，取决于开发者如何设计 Prompt。
但 AI 无法判断哪种方案最适合当前业务场景，这仍然需要开发者的经验与判断。

✅ AI 代码治理：如何审核 AI 代码，防止技术债务？

AI 代码可能会引入新的技术债务，比如：
- 代码结构混乱，缺乏一致性
- 逻辑错误难以发现
- AI 生成的代码难以调试
未来，AI 代码审查（AI Code Review）可能会成为开发流程的新标准。

✅ 架构思维：如何让 AI 代码符合长期可维护的架构设计？

未来的开发者，需要具备更强的系统思维：
- 如何拆解业务需求？
- 如何设计可扩展的架构？
- 如何管理 AI 代码的质量？
开发者需要从「被动写代码」转变为「主动设计系统」。

5. 结尾

AI 让代码生成变得简单，但软件架构仍然需要人类设计。

未来，AI 编程会让开发变得更加高效，但开发者的核心竞争力将不再是写代码，而是驾驭复杂度。

未来，AI 可能会替代低端的代码搬运工，但无法替代深刻理解复杂度的架构师。

「AI 不会取代开发者，但懂得驾驭 AI 的开发者，将取代那些不懂 AI 的人。」

以上。

从 DeepSeek R1 的联网搜索和 RAG 聊起

发表回复

在最早 ChatGPT 应用到 Bing 时我们就体验到了联网搜索的能力，最近大火的 DeepSeek R1 在其官网或者腾讯元宝的版本中部署了带有联网搜索的版本，甚至私有化部署的版本也可能通过 Page Assist 实现联网功能。

当用户勾选 联网搜索 功能时，可以将其视为一个 能够理解任何自然语言问题的智能搜索引擎，相比传统搜索引擎仅支持关键词匹配，LLM 结合联网搜索可以更智能地解析问题，并返回更精准的结果。特别是在 R1 的推理加持下，整个过程显得更为丝滑。

联网搜索不仅能够提升模型的实时信息获取能力，还能与 RAG 技术结合，使模型在回答问题时参考最新的搜索结果，提高准确性和可靠性。

之所以要增加联网搜索，增加 RAG 的逻辑，这些都是由大模型本身的问题造成的。

1. 大模型的问题

大语言模型（LLM）的知识来源于海量的离线数据训练，因此其信息具有时效性滞后问题。

一般来讲，主流 LLM 的训练数据通常滞后于其发布时间半年到一年以上。例如，GPT-4o-latest 的训练数据截止于 2024 年 6 月，而 DeepSeek-R1 的最新数据截止于 2024 年 7 月（问 DeepSeek-R1，它自己回答的）。这意味着 LLM 无法直接获取训练完成后发生的最新事件、科技进展或行业动态。

1.1 知识局限性

由于 LLM 依赖于静态数据集进行训练，其知识范围受到以下限制：

无法获取最新信息：模型的知识仅限于训练数据中的内容，因此对于训练完成后发生的事件，它无法直接回答或提供准确的分析。
缺乏实时数据支持：LLM 无法访问最新的网络信息，如新闻报道、财务数据、政策变动等。
受限于训练数据的覆盖范围：即便是训练数据范围内的知识，LLM 也可能因为数据筛选、公开性限制等原因而无法掌握某些领域的最新进展。

为了解决这一问题，许多 LLM 引入了 联网搜索 机制，使得模型能够动态检索最新的网络信息，从而提供更具时效性的回答。

联网只解决了部分大模型的信息实时性的问题，除此之外， LLM 还面临 幻觉问题、私有数据匮乏、内容不可追溯、长文本处理能力受限以及数据安全性 等挑战。

1.2 模型幻觉

由于 LLM 的底层原理是基于 数学概率 进行文本生成，其回答并不是基于事实推理，而是对最可能的词序列进行预测。因此，LLM 可能会在自身知识缺乏或不擅长的领域 一本正经地胡说八道，即产生幻觉。这种现象在 事实性要求较高的业务应用（如法律、医疗、金融等）中尤其需要被关注，因为错误信息可能导致严重后果。同时，区分 LLM 生成的正确与错误信息 需要使用者具备相应领域的知识，这也提高了使用门槛。

1.3 私有数据匮乏

LLM 主要依赖 互联网公开数据 进行训练，而在 垂直行业、企业内部 等场景中，很多专属知识并未包含在模型的训练集中。这意味着 LLM 无法直接回答涉及 企业内部文档、行业专属知识库 或其他非公开信息的问题，导致其在 专业化应用场景 中的表现受限。

1.4 内容不可追溯

LLM 生成的内容通常 缺乏明确的信息来源，用户难以验证其答案的准确性和可靠性。这种不可追溯性影响了 内容的可信度，尤其是在需要引用权威信息的场景（如学术研究、法律咨询等）。

1.5 长文本处理能力较弱

LLM 受限于 上下文窗口的长度，在处理长文本时 容易丢失关键信息，并且 输入文本越长，处理速度越慢。这对需要分析 长文档、长对话或复杂背景信息 的应用场景构成了挑战。

1.6 数据安全性

对于企业而言，数据安全至关重要，没有企业愿意将私有数据上传到第三方平台 进行训练或推理，以避免数据泄露的风险。因此，完全依赖 通用大模型 进行知识问答和分析，往往需要在 数据安全性与模型能力之间 做权衡。

2. RAG 的出现

随着大语言模型（LLM）在各类任务中的广泛应用，人们逐渐发现它们的局限性，如时效性滞后、幻觉问题、私有数据匮乏、内容不可追溯、长文本处理能力受限，以及数据安全性等挑战。为了解决这些问题，Retrieval-Augmented Generation, RAG 技术应运而生。

2.1 什么是 RAG？

RAG（检索增强生成）是一种结合信息检索与文本生成的 AI 方案，旨在利用外部知识库或文档存储，实现更准确、实时且可追溯的内容生成。其核心思想是：

检索（Retrieval）：在 LLM 生成答案之前，首先从外部知识库或数据库中检索相关信息。
增强（Augmented）：将检索到的信息与用户的原始问题结合，形成一个更丰富的输入。
生成（Generation）：将增强后的输入提供给 LLM，使其基于最新信息进行回答，而不是仅依赖于模型固有的知识。

2.1.1 RAG 的发展历史

RAG 由 Meta AI 团队于 2020 年提出，最初是为了提高 LLM 在特定任务中的表现。随着 LLM 在各类应用中的扩展，RAG 技术逐渐成为提升模型响应质量的重要手段。

在 RAG 之前，主要有三种方式来提升 LLM 的能力：

微调：通过额外训练数据调整 LLM 的参数，使其更适应特定任务。
提示工程：通过优化输入提示（Prompt）来影响 LLM 的输出。
知识注入：在 LLM 训练阶段直接加入结构化知识，以增强其知识覆盖范围。

然而，这些方案都有各自的局限性，例如微调成本高昂、提示工程在复杂任务下效果有限，而知识注入无法解决最新信息的获取问题。因此，RAG 逐渐成为一种更灵活、高效的解决方案。

2.2 RAG 解决了哪些问题？

解决知识局限性：RAG 通过外部检索，可以动态获取最新的信息，而不像 LLM 仅依赖静态训练数据。例如，在金融、法律、医疗等领域，LLM 需要访问最新法规、市场动态或医学研究，RAG 能够提供这些最新信息，从而提高回答的准确性。
缓解模型幻觉：LLM 生成的内容基于概率计算，当其遇到没有见过的内容时，会凭空捏造不存在的信息。RAG 通过提供真实的外部数据作为参考，降低了模型「胡说八道」的风险。例如，在法律咨询场景中，RAG 可以直接引用相关法规，而不是让 LLM 「猜测」答案。
访问私有数据：企业通常拥有大量的内部专有数据，如客户档案、财务报表、技术文档等，RAG 可以让 LLM 在不重新训练的情况下，动态查询这些私有数据并提供个性化回答。例如，企业可以使用 RAG 让 LLM 访问内部知识库，实现智能客服或决策支持。
提高内容可追溯性：LLM 生成的内容通常无法溯源，而 RAG 允许模型在回答时引用具体的数据来源，例如检索到的网页、论文或数据库记录，使用户可以验证答案的真实性。这在医疗、法律等领域尤为重要。
优化长文本处理能力：LLM 的上下文窗口有限，难以处理超长文本，而 RAG 可以分段检索相关信息，并将重要片段提供给 LLM，从而提高长文档的分析能力。例如，在法律案件分析中，RAG 可以从海量判例中检索关键案例，而不是让 LLM 直接处理整个数据库。
增强数据安全性：企业往往不愿意将私有数据上传到第三方 LLM 平台，而 RAG 允许模型在本地或私有云环境中访问内部数据，避免数据泄露风险。例如，某些金融机构可以利用 RAG 构建私有化的 AI 助手，而无需担心数据安全问题。

2.3 RAG 与其他方案的对比

技术	适用场景	优势	劣势
微调	需要针对特定任务优化 LLM	提高任务适应性	训练成本高，难以适应变化快的知识
提示工程	通过优化输入提示提升输出质量	无需重新训练模型	适用性有限，难以解决知识更新问题
知识注入	在模型训练阶段加入额外知识	提高 LLM 的知识覆盖范围	训练数据越多，计算成本越高
RAG	需要动态获取最新信息、私有数据或长文本分析	低成本、高灵活度，解决时效性和私有数据问题	依赖高质量的检索系统，检索速度可能影响响应时间

从对比可以看出，RAG 结合了信息检索的强大能力，为 LLM 赋能，使其能够访问最新、权威的信息，同时避免了高昂的训练成本。

2.4 RAG 的核心技术

RAG 主要由以下三个模块组成：

增强数据处理
- 对文本、图片、音频等多模态数据进行预处理。如 OCR 解析 png、jpg、PDF，文本解析 docx、pptx、html、json 等。
- 进行数据切分、去重、向量化转换，提高检索效率。如文本向量化，多模态支持（clip 等图片 Embedding）
增强语义检索
- 采用向量搜索（Vector Search）提高检索精准度。
- 结合混合搜索（Hybrid Search）实现关键词和语义匹配。
增强召回
- 通过精细排序算法优化检索结果。
- 结合知识图谱、推理引擎增强答案的准确性。

除此之外，一般 RAG 的服务商还会支持私有化部署、多租户隔离和访问控制等安全控制能力。

以在阿里云 PAI 平台构建 RAG 问答系统为例，有以下 4 种方案：

Retrieval：直接从向量数据库中检索并返回 Top K 条相似结果。
LLM：直接使用LLM回答。
Chat(Web Search)：根据用户提问自动判断是否需要联网搜索，如果联网搜索，将搜索结果和用户问题一并输入大语言模型服务。使用联网搜索需要给EAS配置公网连接。
Chat(Knowledge Base)：将向量数据库检索返回的结果与用户问题合并填充至已选择的 Prompt 模板中，一并输入大语言模型服务进行处理，从中获取问答结果。

2.5 RAG 的应用场景

RAG 适用于需要高精准度、实时性、可追溯性的 AI 任务，广泛应用于智能搜索、知识管理、内容生成、教育培训、法律/医疗检索等领域。例如：

智能客服：结合企业知识库，实现实时检索 + LLM 生成，提供更精准、动态的客服回复。如银行客服可以基于最新政策，提供个性化贷款咨询，而非仅限于静态文档。
内容创作：结合外部数据源，自动生成高质量内容，提升创作效率。如电商平台可利用 RAG 生成符合 SEO 规则的商品描述，提高搜索排名。
知识管理：结合全文检索 + 语义搜索，快速查找相关文档，并生成摘要。如律师事务所可基于以往案例库，高效检索相关判例，提高办案效率。
教育培训：结合课程内容，自动生成个性化练习题、案例分析、教学材料。如在线教育平台可根据学生的知识点掌握情况，动态调整练习内容。
智能搜索引擎：结合 LLM 和 RAG，实现更自然的搜索体验。

3. 小结

RAG 作为 LLM 的重要补充，极大地扩展了大模型的能力边界，使其能够动态获取最新信息、降低幻觉、支持私有数据访问，并增强内容的可追溯性。随着 AI 技术的不断发展，RAG 预计将在搜索、问答、智能助手等领域发挥越来越重要的作用，为 LLM 提供更强的知识支撑和应用落地能力。

以上。

一行代码没写，我用一天的时间做了一个网站

发表回复

★AI 编程真的能做到一天写完一个网站吗？ 这听上去像科幻小说里的情节，但事实证明，借助字节的 Trae，我真的在一天之内完成了一个网站的开发。本篇文章主要分享这次 AI 编程的完整实战经验，包括踩过的坑、用到的技巧，以及如何最大化 AI 的生产力。

整个写代码的过程有点钢铁侠里面的场景，只是没有那么炫，大概是这样：

网站已经上线，有兴趣的同学可以访问：开发哥 AI 编程工具箱 https://www.kaifage.com/

完工后的界面如下：

纯前端项目，使用了 Vue 框架

AI 编程的核心思路

在这次沉浸式 AI 编程过程中，主要使用了 Trae 作为 AI 编程助手，并结合 Claude 3.5 Sonnet 和 GPT-4o 进行代码生成和优化。整体思路如下：

让 AI 发挥创造力：先给 AI 一个大致的需求，让它自己发挥，生成一个完整的功能雏形。
分步细化需求：每次只修改一个小地方，比如调整颜色、优化布局或添加某个功能，而不是一次性提出复杂需求。
查漏补缺：AI 生成的代码通常会有小问题，需要自己细心检查并修正。
多模态交互：可以用截图标注问题，让 AI 直接针对修改点进行调整，而不是仅靠文字描述。
灵活切换 AI 工具：Claude 3.5 Sonnet 在代码生成上的表现比 GPT-4o 更稳定，但有时候 GPT-4o 也能提供不同的实现思路。

AI 编程的最佳实践

在这次 AI 编程过程中，有以下的一些体验点，能极大提升开发效率：

1. AI 对于前端生成效果比较好

在前端（HTML/CSS/JavaScript）方面，AI 生成的质量较高，尤其是像 React、Vue 这样的框架，AI 处理起来相对流畅。实际使用体感，传统的前端方案略差一些。

2. 遇到死循环？换个方法！

如果 AI 一直在重复错误，或者陷入死循环，不妨试试：

换个 AI 问，让另一个 AI 重新理解问题。
Google 搜索，找到正确的解决方案后，再喂给 AI，让它基于正确的信息继续优化。
直接问 AI：有没有其它办法？你再想想？ 适当「PUA」 AI，往往能让它跳出思维定式。

3. 抽象表达 vs. 精确指令

有时候，AI 对于具体代码的理解会有偏差，但如果用抽象表达，它反而能给出更好的优化方案。例如：
✅ ❌ 直接写代码请求：「请调整 div 的 padding 为 20px。」这种还不如自己直接调。

✅ ✔️ 抽象表达：「当前的界面布局不合理，请优化为更合理的布局。」

4. 结合多模态能力，提高沟通效率

如果界面某个地方不合理，可以 截图+红框标注，让 AI 直接修改。
视觉化的反馈比纯文本描述更直观，减少沟通成本。

5. 让 AI 直接修改具体文件

如果 AI 生成的代码分散在多个文件里，可以 指定文件路径，让它直接修改，而不是让它自己找文件，有时候会出错，特别是有某些文件相似的时候。

⚠️ 踩坑记录

当然，AI 编程并不总是生成你想要的代码，这次编程过程中也遇到了不少问题：

「正在为当前文件写入变更」真的太慢！
- 有时候 AI 生成代码的速度很快，但写入修改的时候却非常慢，甚至会提示「网络故障」。
- 解决方案：如果长时间没反应，手动复制代码粘贴到文件里，或者让 AI 直接输出完整代码。
代码不准，得自己检查！
- AI 生成的代码 80% 以上是可用的，但仍然会有小错误，比如少了一个逗号，无法跑通，时序问题等。
- 解决方案：自己多测试、多 Debug，不要 100% 依赖 AI。
AI 生成的代码风格不一致
- 可能前后使用的变量名不统一，或者代码风格参差不齐。
- 解决方案：事先定义好代码风格，然后让 AI 统一格式，或者使用代码格式化工具。
AI 把原来已经跑通的模块搞坏了
- AI 在修改代码时，可能覆盖已有代码，导致逻辑混乱，甚至让原本能跑通的功能失效。
- 解决方案：使用 Git 进行版本管理，当一个功能调通后，先提交，建立一个可用的基线。同时如果过程中发现不可用了，可以取消本次编辑结果。