企业官网建设流程全解析

做网站需要规划哪些内容,wordpress主题阿里百,系统网站有哪些,淄博百姓网2025年是AI飞速发展的一年#xff0c;从年初的DeepSeek R1到年末ChatGpt-5.2#xff0c;模型在复杂推理#xff0c;agentic能力上持续跃升。依托大模型能力的提升#xff0c;Agent在更多场景开始逐步实现工程化落地#xff0c;2025年也称得上Agent元年(Manus在昨天被meta收…2025年是AI飞速发展的一年从年初的DeepSeek R1到年末ChatGpt-5.2模型在复杂推理agentic能力上持续跃升。依托大模型能力的提升Agent在更多场景开始逐步实现工程化落地2025年也称得上Agent元年(Manus在昨天被meta收购也是一个agent元年注脚)。这一年agent在coding科研办公等场景都有不同程度的应用落地但影响最广最为深远的当属coding领域AI coding不但改变了程序员的工作方式也改变了构建应用的方式。每一项技能都有其独特价值但门槛不应该成为实现某个创意想法的障碍。在2025年末将笔者年内使用AI coding工具的体验和经验整理成文分享如下。2025年的AI Coding今年2月份Andrej Karpathy提出了“Vibe coding”的概念字面意思为”氛围编程”简单理解就是使用自然语言来进行编程这个概念在整个2025年持续成为了AI社区讨论和关注的焦点。我大概也是从2月份这个时间点开始使用AI coding工具的。最开始使用的是cursor在使用cursor之前用的比较多的是vscode github copilot的代码补全或者把问题粘贴给claude给出具体解决方案再粘贴回ide。而cursor不但能够直接创建文件还能基于对code base的理解来做全局性的修改和功能实现。开始使用cursor的初体验还是觉得比较惊艳的盯着屏幕上AI一边思考一边创建文件写代码第一次感受到”AI帮你写代码”有了程序员数字分身的感觉然后cursor也深度使用了几个月也体验了某天一个上午就用了40美金的震撼感(超出订阅外付费)随后社区不断看到对claude code的安利在6月份开始尝试了claude code一开始对命令行式的编程不太习惯但随着越来越多的使用发现依托anthropic自家的claude sonne/opus 4模型claude code在解决一些复杂问题的能力上明显超过了cursor但是3天也就把一个星期的limit用超了遂开了max随之也就把cursor退订了。而我目前用得最多的是codexcodex在4月份就推出了codex cli开源版本5月份发布云端codex当时的重点还是云端基于github仓库的任务模型的coding能力也明显弱于claude。然后8月份发布了gpt-5随之9月份发布gpt-5-codex,基于gpt-5特定训练的coding模型这个时候的codex用下来就体验不错了而且codex团队版本更新节奏很快持续优化codex的使用体验在9月底的时候我的主力coding工具就从claude code迁移到了codex。上面就是我这一年使用AI coding工具的迭代过程可以看到这个领域的技术变化非常快所以我也在不断的切换工具。但是这就引出一个问题这些工具都需要付费Cursor Pro每月20美元Claude Max每月100/200美元,OpenAI pro每月200美金。国内AI coding工具尤其是使用国内模型的话订阅价格会更便宜这个可以按需选择。这引出了一个值得认真回答的问题AI coding工具真的好用到让大家愿意付费订阅的程度了吗那些被反复提及的问题——幻觉、上下文遗漏、代码风格不匹配、引入第三方漏洞—真的在变好吗我的回答是在一定条件下是好用的但也是不得不用的因为这对程序员和想通过软件构建产品的用户群体来说这确实是”划时代”的工具。下面就结合自己这一年使用AI coding工具的体验和实践来展开谈一下。为什么说是”划时代”的工具在讨论问题之前先承认一个事实AI coding工具带来的效率提升是实实在在的。对于样板代码以前需要30分钟手写的后端模型调用接口现在描述一下需求几十秒就能生成一个可用的版本。即使需要修改也比从零开始快得多。对于陌生代码库以前接手一个新项目可能需要几天时间才能搞清楚代码结构。现在可以直接问AI”这个项目的认证流程是怎么实现的”它能快速给你一个概览指出项目技术架构和核心技术模块。对于技术调研以前需要翻文档、看Stack Overflow、读源码。现在很多问题可以直接问AI它能综合多个信息源给你一个针对性的回答。对于重构工作”这个模块的实现偏离了既定目标需要从工作流切换到agent迭代实现”、”把这些重复代码抽成工具函数”这类复杂但耗时的工作AI可以快速完成初版或阶段性版本。不要指望一次重构完成不然会隐藏很多坑后面会细讲。但掌握合理的方法效率比自己重构仍然高出N倍。这些效率提升是实打实每天都在发生的。这也是为什么即使存在各种问题很多人仍然愿意付费使用这些工具节省的时间是真实的解放的精力也是真实的。但效率提升不意味着没有问题。接下来我们逐个分析那些被反复提及的痛点。幻觉问题—存在但在改善什么是代码场景下的幻觉幻觉在代码场景的表现和在问答场景不太一样。它不是编造一个不存在的历史事件而是在函数匹配api使用实时性和技术阐释上存在误引用和过时问题这个通常在超长上下文时容易触发。编造函数生成一个看起来合理但实际不存在的方法比如response.json().await在某些框架中根本没有混淆版本把不同版本的API混在一起用例如langraph的使用的是前几版的api导致适配报错虚构配置为agent的记忆存写策略编造一个”应该存在”但实际不存在的配置项错误解释自信满满地解释一段代码的工作原理但解释的逻辑与代码实现存在偏差(忽略了部分实现)正在改善的方面首先必须承认基础模型的能力是AI coding工具的地基。模型不行工程化做得再好也没用。但顶尖模型的幻觉确实在持续减少所以在进行复杂关键模块编码时尽量选择幻觉率低的模型(比如gpt-5.2的幻觉就低于gemini 3 pro虽然gemini 3 pro的世界知识能力更强)。而这些幻觉问题的改善主要体现在这几个方面模型学会了说”不确定”。模型在遇到不熟悉的API也没有进行联网时会有概率输出表示”我不确定这个方法的确切用法建议查阅官方文档”而不是编造一个看起来合理的答案。这是一个重要的进步—承认不知道比胡说八道好得多这个属于know unknow问题虽然现阶段over-confidence的概率还是比较大。上下文层面的retrival补充。codex和claude code在对项目进行全局分析时大量使用了grep和rg(ripgrep,rust版rg)命令来检索文件并进行读取利用而这使用背后不仅仅是检索功能的准确调用同时也是上下文工程的持续优化 - 如何把检索到的相关全局代码信息放到当前上下文实现模型的有效理解和代码生成。可执行环境的集成。这也是比较有效的改善。Claude Code、codexCursor Agent都可以执行代码、看到报错、然后执行自我修正。代码有一个自然语言没有的特性客观可验证性。能跑就是能跑不能跑就是不能跑。当AI可以获取这个反馈信号时最终输出的质量就有了基本兜底(虽然一些问题通过单元测试不代表整体功能就没问题)。测试驱动开发也是一种不错的实践方式每开发完一个模块可以让AI coding工具写单元测试脚本并进行测试验证。仍需注意的场景但幻觉问题仍然存在影响在以下场景仍需注意:新发布的框架或库训练数据还没覆盖模型可能基于旧版本的知识”推测”新版本的用法小众技术栈训练数据中样本少模型的”知识”本身就不太可靠底层实现细节模型对”怎么用”通常比”为什么这样”更可靠在一个上下文持续执行多个任务在一个上下文执行多个任务随着上下文堆积模型容易失焦保持上下文比较聚焦不要堆积太长上下文及时总结当前内容作为上下文开一个新窗口把这个问题迁移到新窗口解决从实践上看是比较有效的缓解幻觉的方式。对于AI生成的代码现阶段我们需要保持审慎的态度不能假设它的实现思路一定对。尤其是涉及到你不熟悉的API或模块实现需要花时间查一下官方文档和最佳实践确认这个习惯能避免很多坑。一般可以使用AI coding 调用搜索工具进行搜索codex对搜索的支持还不太行处于安全考虑默认不进行网络搜索claude code和cursor支持比较好。所以一般对于需要搜索相关技术方案和参考实践时我会用claude code进行调研生成结果再让codex读取这个搜索结果进行分析。上下文遗漏——最棘手的问题“上下文腐烂”是什么这是目前AI coding工具最棘手的问题也是比较容易让人抓狂的问题。你和AI进行了一个长对话讨论了项目架构定义了代码规范修改了十几个文件。然后你让它继续改一个相关的文件它突然”忘了”之前讨论过的规范生成了一段风格完全不一致的代码。这种现象也被称为“上下文腐烂”Context Rot。为什么会发生原因一模型的固有特性——Lost in the Middle即使模型声称支持100k、200k甚至1M token的上下文窗口即使”大海捞针”测试能达到99%它对上下文的关注并不均匀。模型天然对开头和结尾的内容关注度更高对中间部分的关注度较低。这意味着如果你在对话中间讨论了一个重要技术细节到对话后期模型对这个技术细节的”记忆”可能已经模糊了。原因二训练分布的偏移模型在训练时很少见到那种”30轮以上、涉及20个文件、包含大量代码修改”的复杂对话。你的真实使用场景超出了它的训练分布。当对话复杂度超过训练时见过的样本时模型的表现就开始不可预测。但这个问题随着更多复杂真实场景数据的积累下一版模型引入这些复杂训练数据就会得到改善。原因三累积误差每一轮交互都可能引入轻微的理解偏差。单独看每个偏差可能可以忽略但经过几十轮累积偏差被放大最终导致模型对项目的理解和你的实际意图严重脱节。上下文工程当前的应对方案各家模型厂商和AI coding工具都在尝试解决这个问题方案可以归类为三种思路思路一压缩对上下文进行删减和压缩只保留关键信息。Cursor的Compact功能、Claude Code的自动压缩都是这个思路。好处是可以延长有效对话长度坏处是每次压缩都可能丢失细节。多次压缩后性能下降会比较明显。Codex一开始需要手动compact现在可以自动compact了但用户反馈是”多次compact之后它对项目的理解明显变差了”。思路二卸载把大段内容放到文件里上下文中只保留文件引用。当AI需要某个文件的内容时再动态加载。这实际上是把上下文窗口当作”工作内存”而不是”长期存储”。就像人类程序员不会把整个代码库背下来而是在需要时查阅特定文件。思路三隔离通过Sub-agent实现上下文隔离。主agent负责高层规划和协调子agent各自执行具体的子任务每个子agent有自己独立的、较小的上下文。这类似于人类团队的分工架构师掌握全局各个开发者专注于自己负责的模块。子agent之间不需要共享所有上下文只需要共享接口约定。实用建议这些方案在思路上看上去没有什么特别之处但是关键是工程化实践不同的AI coding工具可能使用了类似的上下文工程方案但体验上仍然会存在差异例如在cursor中使用gpt-5.2模型与在codex中使用gpt-5.2模型在处理同一个任务时因为上下文压缩策略以及环境内置工具的差异会在某些节点上给出不一样的方案。而作为使用者我们可以做一些事情来缓解这个问题勤开新对话。不要在一个对话里做太多不相关的事情。当你感觉AI开始”忘记”之前讨论过的内容或者它的回答开始偏离主题这是开新对话的信号。一个经验法则一个对话专注于一个相对独立的任务。用规则文件固化约定。把项目的技术栈、代码规范、架构约定写在agents.md、CLAUDE.md或.cursorrules里。这些内容会在每个对话开始时自动加载不会随着对话变长而”腐烂”。分阶段处理大任务。如果一个任务涉及大量文件和复杂逻辑不要试图在一个对话里全部完成。分成几个阶段每个阶段用一个新对话阶段之间通过文档或git 信息来传递上下文。代码与框架不匹配—通常是对齐问题问题的两面AI生成的代码”不符合项目规范”是一个常见的问题但这个问题需要拆成两个角度来看角度一你给了充分的上下文AI还是实现偏了这确实是模型的问题。但根据我的经验这种情况的概率其实不大。比如你要实现一个pdf翻译的功能如果构造的上下文明确包含了ocr api翻译 llm api对应的接口参考那直接通过一次性构建的可用率还是很高的但问题也在于判断何种程度的上下文为“成分的上下文”这个一般需要对经过一段时间的AI coding工具深度使用就会对其的知识能力边界和上下文操作能力有更清晰的认知在每次实现需求时给到充分且必要的上下文可以有效增加AI实现功能的准确率。角度二上下文不充分人与AI未对齐这是更常见的情况。你说”写一个认证模块”上下文没有明确要求技术栈是什么、代码风格是什么、架构约定是什么。AI就只能基于”最常见的做法”来生成代码。如果你的项目不是用”最常见的做法”结果自然就不匹配了。这意味着什么你的代码可能99%都由AI生成但让项目代码可维护绝不是几次交互就能实现的。现阶段我在使用AI coding工具时大量的工作其实花在实现过程的review、纠偏和对齐上“这两个模块耦合了需要拆出来保持独立解耦”“这个错误处理之前遇到过参考这个文件的修改思路”“这几行代码属于防御性编程不需要这么写”“这个逻辑太复杂了拆成几个函数”“react的obs函数不应该承担上下文管理的职责需要由一个上下文管理器负责”这个过程很像费曼学习法——在AI犯错时你需要把如何纠偏的思路清晰地表达给AI。这个表达的过程本身就是在梳理你自己对项目的理解。程序员需要的新能力这引出了一个对程序员的认知和能力转变当我们越来越多使用AI coding工具来进行编码那我们就应该对如何使用AI工具变得更擅长这实际上也对程序员提出了新的能力要求和挑战。以前的核心能力手写代码 - 把需求一行一行手敲实现为可运行、可维护的代码。现在的核心能力评估代码、指导代码实现思路 - 在不亲自写代码的情况下判断AI生成的代码是否正确、是否符合规范、是否有潜在问题并给出清晰的修改指导。这意味着实现不再是核心规划、编排、指导成为核心能能力结构上来分析这是一种更抽象更偏向管理的能力。你需要快速阅读代码并识别潜在问题清晰表达你的意图和约束在架构层面做出正确判断知道什么时候该相信AI什么时候该质疑编排工作流管理不同的AI agent来协作完成coding任务比较有意思的是对当前项目代码深入理解的过程很可能就是在与AI交互协同开发的过程中建立的。你通过不断地review和纠偏逐渐建立起对项目的深入理解以及对核心技术喊更深刻的认知。从这个角度看AI虽然取代了写代码的工作但对架构设计评审代码抽象逻辑AI协同意识的要求更高了。实用建议建立完善的上下文供给机制花时间写一个详尽的项目规则文件技术栈声明可以精确到框架版本代码风格规范或指向配置文件目录结构说明架构决策及其原因常见模式的示例代码明确的禁止事项这个投资是一次性的收益是持续的。用示例代码而不是描述与其说”按照我们的代码风格写”不如说”参考src/components/UserProfile.tsx的风格”。AI可以直接从示例中学习你的命名约定、状态管理方式、错误处理模式。接受迭代式的工作流不要期望一次prompt就得到完美代码。把”生成→review→纠偏→再生成”当作常态。每一步都保持控制而不是寄希望于最后一步的审计。防范错误扩散风险—需要新的Review习惯问题的本质AI生成代码的速度远快于你review代码的速度。代码review属于一个结构性的问题。当AI只用了5分钟内生成了包含5个文件改动接近400行的重构需求代码改动包含十几个依赖的模块你有多大把握确保它的改动是完全符合需求的呢如果review跟不上就可能放过潜在的bug引入有安全漏洞的依赖导致实现偏离目标却没有及时发现当前没有银弹坦白说目前没有特别好的自动化review方案能完全解决这个问题。各种静态分析工具、安全扫描工具可以提供一定帮助但不能替代人来review的工作。可行的应对策略基于文档规范维护一个”技术决策文档”文件夹用于记录和指导项目中的复杂改动比如发现的重要bug模块级重构需求让AI分析问题所在与预期的偏差修复思路以及带优先级的行动清单这样记录之后AI不但可以有一个清晰的文档参考来实现复杂改动也同时沉淀了项目知识可以在后续遇到类似问题时让AI参考复用。拆解模块把大任务拆成小模块每个模块相对独立。这样每次review的范围可控不容易遗漏问题。勤review、勤commit不要等AI生成了一大堆代码才开始review。每完成一个小功能就review一次、commit一次。这样错误发现得早修复成本低commit历史清晰方便回溯你对项目的理解在这个git提交过程中不断加深目标 - 缩小错误扩散空间假设AI生成的代码中有问题你的目标是让这个问题尽早暴露、影响范围尽量小否则这个问题会导致级联错误产生通过一个引入一个bug来掩盖之前的bug导致越往后越难以排查。同时如果漏过的bug和错误实现没有及时发现那这个“错误实现”可能成为AI参考的“最佳实践”后续的实现都以这为标准直到某天你发现这个实现偏差你问AI为什么这么实现的它会给出一个”合情合理”的理由 - “因为之前的模块我们就是这么实现的”。所以通过文档规范驱动模块拆解勤commit的方式就是尽可能的将错误早暴露早识别早解决避免后面需要大量投入的纠偏返工(别问我为什么知道的)。约束条件与正确的心态AI coding的约束空间AI coding工具可以说是好用的但存在约束空间。这个约束空间可以这样理解约束一它是生产力工具不是替代品你需要把AI coding当作一个高效的助手来使用而不是期望它完全替代你。你仍然需要理解代码、做出决策、你仍然是代码交付的第一责任人。约束二需要掌握使用方法不是打开工具就能获得效率提升。你需要学习如何有效地和AI协作 - 怎么写prompt、怎么提供上下文、怎么review和纠偏怎样最大化降低隐藏bug和纠偏返工风险。约束三不能完全托管项目程序员暂时完全不能把项目托管给AI。你仍然需要对项目的核心模块有比较深入的了解才能驾驭得了这个工具。如果你对项目的理解程度达不到”不用AI也能维护”的水平那你实际上可能就会失去了对项目的控制。AI是放大器不是替代品—它放大你的能力但前提是你得持续提升使用AI coding工具的能力才可以将这种提升持续放大不然卡到一定的瓶颈点边际收益反而会降低。正确的心态心态一接受学习曲线刚开始使用AI coding工具时你可能会觉得”还不如自己写来得快”。这是正常的。就像学习任何新工具一样前期有学习成本后期才能获得收益。心态二保持批判性对AI的输出保持审慎培养判断力。它会犯错而且有时候犯得很自信。保持”验证”的习惯尤其是对于你不熟悉的领域。但这种判断力是可以培养的比如更容易在哪些方面犯错就可以有针对性的调整review策略。心态三把纠偏当作常态AI生成的代码需要修改是常态不是例外。不要期望”一次生成直接可用”。把review和纠偏当作工作流程的正常组成部分。心态四在协作中学习使用AI coding工具的过程也是加深你对项目理解的过程。每次纠偏都是一次加深对项目理解的机会。一开始构建的项目AI对这个项目的理解程度是超过你的但是在逐步交互优化细化完善项目的过程中你对这个项目的理解应该超过AI而这种受益也正是产生自与AI协作的过程中。结语回到最初的问题AI coding工具真的好用吗值得付费使用吗答案是好用但需要新的工作方式。它不是一个”即插即用”的效率提升器而是一个需要学习如何驾驭的强大工具。幻觉、上下文遗漏、代码不匹配、安全风险这些问题都是真实存在的但幻觉在改善尤其是结合全局retrival和可执行环境后上下文遗漏可以通过勤开新对话、规则文件、分阶段处理来缓解代码实现偏离主要是对齐问题可以通过建立完善的上下文供给机制来解决屎山代码堆积需要新的review习惯将问题早暴露早发现而对于付费使用问题当一个开发者愿意每月自掏腰包买工具这意味着他们认为获得的效率提升值这个价。一个粗略的计算如果工具每天节省1小时每月就是20小时。按照软件工程师的时薪这20小时的价值远超订阅费用。但这个计算有一个隐含假设你得知道如何有效使用这些工具。如要获得如何有效使用的最佳认知那就是从使用和订阅开始的。对于能够掌握新工作方式的程序员来说AI coding工具确实是划时代的。它并不会让你马上出现阶跃式的能力提升但它会让那些善于利用它的人获得更显著的效率提升而且用的越多思考的也多受益也越大这或许是对”好用”最有说服力的证明。写于2025年12月31日2025年已经开启一个AI coding工具从”可选”变成”必需”的时代无论你是否具备编程经验这都是你值得去尝试AI利器。2026年你会用它创造出什么更有意思的东西呢