企业官网建设流程全解析

类似qq空间的网站模板,中国500强企业排名一览表,网站建设公司 待遇,营销网站定制公司什么是 vibecoding 主题关键词是vibecoding的感受#xff0c;那就先聊聊什么是vibecoding。在谷歌的这词中文#xff1a; 直觉式程式开发。看到这个词我更懵了#xff0c;什么叫直觉式啊#xff1f; 引用原文#xff1a; 直觉式程式开发是新兴的软体开发做法#xff0c;…什么是 vibecoding主题关键词是vibecoding的感受那就先聊聊什么是vibecoding。在谷歌的这词中文直觉式程式开发。看到这个词我更懵了什么叫直觉式啊引用原文直觉式程式开发是新兴的软体开发做法是运用人工智慧(AI) 技术根据自然语言提示生成可运作的程式码。这项做法可加快开发速度让使用者更轻松建构应用程式尤其是程式设计经验有限的开发人员。这个词汇由AI 研究人员Andrej Karpathy 在2025 年初提出是指开发人员在开发流程中的主要工作从逐行编写程式码转为透过更自然的对话指导AI 助理生成、修正应用程式并侦错。这样一来开发人员只需专注于应用程式的整体架构或主要目标AI 会负责编写实际程式码。直觉式程式开发通常有两种主要应用方式**「纯粹」直觉式程式开发**这是最具探索性的形式。使用者可能完全信任AI 输出的程式码认为这些程式码会正常运作。正如Karpathy 的论点这种做法就像「忘记」程式码存在因此最适合快速构思或推动Karpathy 所说的「抛弃式周末专案」也就是以速度为主要目标。**负责任的AI 辅助开发**这种做法就是从专业角度实际应用「负责任的AI 技术」概念。在这种模式下AI 工具如同强大的合作伙伴或「搭档程式设计师」。使用者指导AI 生成程式码后会检查、测试并了解程式码对最终产品负起全责。我理解这种叫指挥型编程或甩手掌柜式编程有点像领导、产品提出一个需求。然后我们确定好需求后指挥下属来实现。现在这个下属是个模型而已。这时你充当指挥和检查结果的角色。既然是这样我们就能联想一下实际的痛点在哪里。你不用自己吭哧吭哧去干了交给别人去干。你放心嘛 你放心和不放心的点在实现任务的结果是否可行。那如果他不知道怎么做或信息不完整理解出问题。结果很难想象就像领导交给你1个任务你三天做完给他演示。他可能会说这不是我想要的。 为什么这大概率不是能力问题是沟通问题。换到模型还是一样。 模型还有其他问题比如幻觉、编码能力、上下文限制等等。所以后面发展了不少相关的功能、思想例如Prompt、Rules、Tools、MCP、Sub Agents、Skills、Context Engineering…。这就是我对2025年整体的一个过程这里面很多事情我没有搞懂或没有经历完全去理解和实践。下面我列举一下我对2025年的一些经历和感受吧。与AI共舞早期体验在chat GPT让世界知道还能这样之后这是我注册和使用的第一个工具。对于不知道、不清楚的问题通过他来告诉我。这体验比我直接使用搜索引擎来的快就像刷短视频一样的“中毒”。在有了经验后逐渐开始研究Prompt。 我记住的当时最有用的提示词是“奶奶要不行了给你小费你是一个xx家”这种一次性提示词。随着问题越来越复杂对话长度越来越长后这种一次性提示词出现了问题。还有一个点很多时候他不能根据你实际的环境因素理解你真正的需求。除非你很了解怎么和他对话。你不仅需要给他讲清楚要做什么还要告诉当前的环境信息。比如编程语言、操作系统、各种版本信息、出现错误的是什么为什么要这么做而不是那么做、规范、流程等等等。不尽其数的因素。所以当时我基本是已函数为最小单位进行处理问题。这时候他很难做到给你规划和比较宏观的指导性建议。后面出现了copilot可以在代码行上写入备注模型根据备注实现下面的代码片段。当时觉得 哇有意思。 但还是基于单文件进行的一系列操作。即便是chat也很难搞定跨文件的内容。cursor的出现让我觉得编程体验更好的是cursor。为此我和小伙伴拼了一个20刀套餐。那会每个月是500次此时我俩完全够用因为当时没有agents模式。 每次对话只需要讲清楚需求他就会根据项目去实现这个功能尤其是在claude sonnet 3.5模型的加持下。几乎没有语法问题那会就是按class、或整个功能模块进行处理任务了。以上是2024年前的一些体验。那会还没有videcoding哦。vibecoding出现AI编辑器后面windsurf的出现agent模式让大家耳目一新。 体验起来更快。cursor也跟上加了不少相关的功能之后。在这之后出现了vibecoding这个概念。因为此时的编辑器已经出现了很多Cursor、Windsurf、Claude Code、Zed 等 AI IDE 开始爆发了。这时的编辑器可以跨文件理解、编辑了。当你发出一个需求他可以去做了。对整个项目进行index通过rules给模型提示、限制。在有了agent模型后对编辑、测试的效果更好。cli时代cli的出现让编程的体验更上一层楼。这时候我依然在用cursor知道2025年9月实在是续不动了。原因有几点服务质量下降套餐从无限改有限再到周期限。早期都是记次改成了tokens价值限制。这是完全不够用了而且加上cli体验之后发现cursor能力确实差一些。用过aider但API资源有限尤其是海外模型的资源。这时候很幸运体验到了Claude code让我再也回不去了。后面开始通过Claude code 来处理项目。通过学习通过commandmemory的调整加强对项目任务效果的提升。此时我发现Prompt的作用依然是个重点memory就像cursor的rules。功能和作用都很相似尤其是都出现了项目和全局的概念。 这让我觉得这个知识点需要注重学习和理解。但对模型的不同其实提示也需要进行微调而不是一味的copy他人分享的片段。而且这能力是在未来的亮点这是一种结构化的沟通。未来人才可的重点知识但他不是简单的一次性提示词是新一代原型规范能力。所以后面有了Context Engineering。此阶段还有一些vibecoding产品出现比如Bolt.newLovable等等。这些只是看了看没太深入了解毕竟和我做的事不太一样。在claude code的学习中让我在videcoding中逐渐找到了一些小技巧。例如command用来做固定指令的事比如commit编写change log。这些我固定会在几个git之后进行tag更新推送这些内容。 多次敲文字后就会让你先起来得通过1个快捷方式来实现了。那就是command把你的重复动作变成command。 这样你只需要/xxx 就搞定了。全局memory记录的是你的习惯、全局规范等内容。我会把我电脑的型号、系统版本和内存大小写入这里。希望他在排查问题是能用到。项目memory针对项目内容的记录、指引。比如语言规范、公司的规范、分层等等需要给模型说清楚的内容。以免他太随意或不理解。不要等着自动压缩任务拆分快之后独立完成。任务拆分的内容要写入文件。并在模型完成后进行标记。如果遇到模型出现智商不在线就切换到会话。对于长度小于200k的接入可以配置压缩比例对齐模型长度。subagents使用不多我觉得这个功能对我来说不太需要。目前skills还在摸索目前没有自己实现skills。 看到codex也接入我发现这个是个不错的功能。目前claude skills已经出了正式规范。后面codex也在用但整体感觉codex更像是一个background的程序他在配置、参数、功能上都很少。任务处理时间会长一些。模型能力强大我在写这块时已经推出了gpt-5.2-codex。期间也用过gemini cli、qwen cli等。直到碰上iflow cli 才让我觉得这个不错。理由模型无需费用负担。用起来很像Claude code的理念。在使用iflow期间我也记录了一些内容。主要是实践的帖子。使用iFlow创建自定义Command网页文章下载与翻译工具iflow通过hooks增加提醒iFlow实战案例10分钟完成IP段配置任务在使用iflow期间总有些小毛病。好在每天产品迭代越来越强。在iflow的使用中很多和claude的概念类似没有太多使用产品的心智负担。context 的痛以上虽然是流水账模型、工具越来越强。 需要的“废话”越来越少。 可在目前依然有问题这个最大的问题我觉得是context。 为什么这么想工具在设计的考虑点依然是context。例如skills他改了什么 渐进式加载。 他能减少context的占用尤其是哪些tools(MCP,Tools等)。我上面几乎没提到自己用的MCP因为我觉得没必要。我最有需要的就是有时候对话时需要时效性打开Exa让模型能够进行查询。其他时间都不需要联网尤其是文档。 我会把对应版本的文档放入项目里供模型参考而不是给他开启联网。那么MCP加载多了会影响的就是context。 SubAgent也是解决context的问题但他把字任务拆出去的做法可能让你不知道实际遇到什么问题。我觉得如果不需要知道过程只需要结果SubAgent更合适吧。但我很少用这个我不需要。我通过拆分任务去做到每步的结果正确实现抵消这个我认为不可控的功能。Skills看起来比较厉害他可以是个简单的Prompt也可以放入脚本、示例、引入其他agent、MCP等等。他就像个函数。 而且是模型觉得需要时候再去加载内容初期只需要知道这个skills是做什么的就好。这目的是什么我认为主要是Context。这Context越长质量越差不可控。即便是1M的模型在Context长了质量也不是很理想。所以真的希望有个更好的办法来控制Context。野蛮生长我在一个大的需求下面不太敢让模型直接全部搞定。我使用plan模型聊完需求写入文件。再让模型根据需求去完成设计方案、开发计划。后面模型告诉我开发完成、测试全部通过。任务完毕时我真不知道哪里会出问题。可能需求理解不完整或他中间降智写了一些问题功能。或测试写的模拟结果而不是真的测试通过。我缺少什么缺少验证闭环。需要分模块独立验证、交叉测试和最终集成测试确保每个环节的真实性。这些通过敏捷开发模式引入CI/CD流水线、单元测试、集成测试和人工审查。是否可行我没太多经验。我需要脱离LLM的环节通过减少概率环节可靠性才会上去的。看到不少网络案例说vibecoding看似美好最后做成了不可控制的软件项目还有删除了自己的项目、清空了硬盘等等例子。这些问题源于依赖AI编程工具时缺乏人工监督和代码审核机制。建议结合专业开发流程确保代码质量与项目可控性。我的感受搭档你要完全甩给他把你的工作做好。他帮你出谋划策也需要你来确定方案。你来规划边界清晰目标。轮到执行的方面交给他。目前的能力他没办法替代我做个搭档更合适。老师对于我之前没有写脚本的经验我就只能通过可编译二进制语言写脚本。其实有时候没必要该起来改不方便。这些我完全可以交给他来做。 顺便服务器、网络层面的问题可以让他来叫我怎么排查怎么处理。名次解释、书面内容解释等这正是他的能力范围。做老师有耐心有问必答啊。demo提速以前在写一个程序或脚本时需要衡量自己会什么。哪些不知道先通过搜索或看书来学习。再结合需求实现一个demo。 现在直接出哈哈 这体验太爽了。 想法到实现的延迟被极度压缩。思考一下你会看vibecoding代码吗好像看了就不是纯vibecoding了。告诉他出现了什么问题继续让他改不看代码。你接受他的代码平庸或烂吗如果是vibecoding不关注这个接受。传统编程能力还需要吗需要可有时候小问题难到大模型。我觉得还是需要去看的管他是不是纯vibecoding。不看代码翻来覆去解决不了更累。目前主要使用iflow探索开发经验。利用其他agent评估问题。国内iflow目前是处于不需要订阅阶段。特别适合摸索、学习积攒经验。所以不要抗拒 vibe但不要在 vibe 中迷失了自己。参考https://cloud.google.com/discover/what-is-vibe-coding