[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f4OuMOhqMgLGbAaj-MVBKkSyEUdGfvqgSN74xc7nYvcc":3},{"item":4,"related":51},{"id":5,"type":6,"title":7,"slug":8,"summary":9,"body":10,"coverUrl":11,"productScreenshots":12,"productLinks":13,"authorName":14,"authorUrl":15,"authorSubject":16,"category":17,"tags":22,"sourceLabel":39,"sourceName":40,"sourceUrl":41,"status":42,"seoTitle":43,"seoDescription":44,"canonicalUrl":45,"isFeatured":46,"sno":47,"sortOrder":48,"publishedAt":49,"updatedAt":50,"createdAt":50},"8413c906-e655-4395-9135-ae1eacc96f98","article","AI 编程为什么第一版很快，第二版却越来越难改","vibe-coding-first-version-fast-second-hard","AI 能迅速做出第一版，却不一定自动带来可维护的第二版。本文解释原型速度为何会转化为结构复杂度，并给出识别重复状态、安排重构和控制 AI 改动范围的实用方法。","AI 编程最让人兴奋的瞬间，往往是第一版。你说出需求，模型很快搭出页面；再补一句“加上搜索、登录和导出”，功能也能继续长出来。可当项目进入第二周，修改一个按钮却牵动多个文件，原本简单的需求开始引发连锁报错。这不是 AI 突然“变笨”，而是原型速度与软件维护成本之间的差距显现了。\n\n## 第一版解决的是“有没有”，后续版本解决的是“能不能长期存在”\n\n原型阶段允许很多临时决定：数据先写在内存里，页面先用一份假数据，错误情况先不处理。这样做没有错，因为目标是尽快验证想法。但如果没有明确的过渡节点，临时方案就会逐渐变成系统的一部分。\n\n维护阶段要回答完全不同的问题：这个状态由谁负责？接口失败时用户看到什么？旧数据如何迁移？同一个功能在移动端是否仍然可用？当模型继续沿着旧结构加功能，隐藏的临时决定就会一起被放大。\n\n## AI 为什么容易把复杂度越堆越高\n\n模型通常根据当前上下文生成“局部合理”的修改。它看到一个报错，会优先让这条路径恢复；看到一个新需求，会倾向于增加一个组件、一个状态或一层适配，而不是重新审视原来的设计。对一次回答来说这很合理，对连续几十次补丁来说却可能形成重复逻辑。\n\n最常见的症状包括：同一份数据有多个来源；相似的按钮各自维护一套状态；错误处理散落在页面各处；配置值被复制到多个文件；一个函数同时负责读取、校验、保存和提示用户。每一处都能运行，整体却越来越难理解。\n\n## 什么时候应该停下来重构\n\n可以观察三个信号：\n\n- 修改一个小功能时，AI 需要同时触碰很多互不相关的文件。\n- 你无法用一句话解释数据从输入到展示的路径。\n- 测试只覆盖成功流程，任何改动都要靠手动点一遍才能确认没有回归。\n\n出现这些信号时，不要继续让模型“再修一下”。先要求它只做盘点：列出重复逻辑、状态来源、外部依赖和未覆盖的错误情况，暂时不要修改代码。等结构图和风险清单出来，再选择一个边界清晰的部分重构。\n\n## 一套适合 AI 协作的维护节奏\n\n每次任务开始前，先给出不变的约束，例如“保留公开接口”“不要引入新依赖”“只修改某个目录”。每次任务结束后，要求模型列出实际改动文件、运行过的检查和仍然存在的假设。把这些信息写进提交记录，下一次协作就不必完全依赖聊天历史。\n\n另外，要把“大需求”拆成可回滚的小提交。先补测试，再改实现；先替换内部细节，再修改外部接口；先迁移一类数据，再扩大范围。版本控制的价值不是保存代码，而是让你敢于尝试和撤回。\n\n## 判断代码质量的简单问题\n\n不要只问“页面能不能打开”，还可以问：新同事能否定位入口？删除一个功能时会不会留下无效配置？网络变慢时系统会不会重复提交？如果答案说不清，就说明第一版还没有真正变成可维护的产品。\n\nVibe Coding 的速度值得珍惜，但它最应该节省的是机械劳动，而不是省掉思考。第一版越快，越要尽早安排一次结构检查，让“能跑”及时过渡到“能改”。\n\n## 来源\n\n- [GitHub Copilot：IDE 中的 Agent mode](https:\u002F\u002Fdocs.github.com\u002Fen\u002Fcopilot\u002Fhow-tos\u002Fchat-with-copilot\u002Fchat-in-ide)\n- [GitHub Copilot 负责任使用说明](https:\u002F\u002Fdocs.github.com\u002Fen\u002Fcopilot\u002Fresponsible-use)","\u002Fuploads\u002F2026-09-13\u002Fe68b1156-67d0-47f9-99fc-efeb38aacdc9.jpg",[],[],"Foundit","https:\u002F\u002Ffoundit.cn","foundit-ai-editorial",{"id":18,"name":19,"slug":20,"description":21},"6179d3b6-dc34-4483-9ded-3cd9f1b37a47","科普","abbreviation","介绍各领域新兴概念",[23,27,31,35],{"id":24,"name":25,"slug":26},"0848beb4-db26-4fb8-b391-f852a11be192","AI编程","ai-coding",{"id":28,"name":29,"slug":30},"144abe77-0dc6-4f66-a176-20bddb1c0bfa","编程","coding",{"id":32,"name":33,"slug":34},"4c2bbea6-eab7-40a8-8447-1de478ff7749","分析","analyse",{"id":36,"name":37,"slug":38},"68cedb55-2cac-412f-8f81-fda8c7d686dd","思考","thought","GitHub Copilot 官方文档","GitHub Copilot：IDE 中的 Agent mode","https:\u002F\u002Fdocs.github.com\u002Fen\u002Fcopilot\u002Fhow-tos\u002Fchat-with-copilot\u002Fchat-in-ide","published","AI 编程为什么第一版快、第二版难改","从原型、临时方案和结构复杂度出发，解释 Vibe Coding 项目为何越来越难维护，并给出适合 AI 协作的重构与版本节奏。",null,false,58,0,"2026-09-13T00:00:00.000Z","2026-09-13T11:55:45.373Z",[52,61,69],{"id":53,"type":6,"title":54,"slug":55,"summary":56,"coverUrl":57,"authorName":14,"sno":58,"publishedAt":59,"createdAt":60},"3e2a7e9e-a123-4ed6-b886-455e76649df1","AI 编程为什么需要“证据链”？","ai-coding-evidence-chain-logs-tests","AI 说“功能已完成”只是声明，真正可靠的结果还需要 diff、终端日志、测试结果和真实操作共同证明。本文解释不同证据能说明什么，以及如何设计任务收尾模板。","\u002Fuploads\u002F2026-09-14\u002F34be8dc4-3692-47ab-8f7c-226dd203c805.jpg",44,"2026-09-14T00:00:00.000Z","2026-09-14T11:00:03.458Z",{"id":62,"type":6,"title":63,"slug":64,"summary":65,"coverUrl":66,"authorName":14,"sno":67,"publishedAt":49,"createdAt":68},"ef4aef3e-8062-42e4-88b5-68e42424c3a3","Vibe Coding 最适合做什么，最不适合做什么","vibe-coding-best-and-worst-tasks","Vibe Coding 最适合边界清楚、反馈快速、失败可恢复的任务，最不适合模糊决策和不可逆的高风险操作。本文用任务三问帮助读者判断何时放手让 AI 执行、何时必须人工把关。","\u002Fuploads\u002F2026-09-13\u002Fea45cd7c-a127-4f9e-90db-35cf41ef08bc.jpg",48,"2026-09-13T11:56:03.397Z",{"id":70,"type":6,"title":71,"slug":72,"summary":73,"coverUrl":74,"authorName":14,"sno":75,"publishedAt":59,"createdAt":76},"80b0007b-7e95-4f63-b885-28600d2d95ad","AI 编程为什么要先 Plan 再 Edit？","ai-coding-plan-mode-before-edit","Plan mode 给 AI 编程增加了一个先理解、再修改的阶段。本文解释计划如何提前暴露需求误解、遗漏边界和过大改动范围，并给出适合普通用户的计划、执行、验证节奏。","\u002Fuploads\u002F2026-09-14\u002Ffa3dbbc4-77bd-4abf-8618-252d72ddd849.jpg",59,"2026-09-14T10:59:52.791Z"]