在 大模型 技术日新月异的今天，越来越多的人开始尝试用 AI 辅助开发应用。本文将分享我从一个简单的想法出发，借助 AI 工具，最终将一个 Chrome 扩展应用“Summarie”成功上架 Chrome Web Store 的全过程。这个过程被我戏称为“Vibe-Coding”，意指一种依赖直觉和快速迭代的开发方式，而 AI 在其中扮演了至关重要的角色。我将深入探讨不同 AI 工具的优缺点，以及在使用 AI 开发过程中需要注意的关键策略，希望能给正在探索 AI 开发的你带来一些启发。
1. GitHub Copilot 的早期尝试与局限性
最初，我满怀期待地尝试使用 GitHub Copilot，希望它能成为我的 “终极 AI 结对程序员”。然而，实际体验与预期相去甚远。Copilot 在处理狭窄、定义明确的任务时表现出色，例如“实现当前框架内的标准身份验证”。它能快速生成符合语法的代码，然而一旦遇到开放式的、需要系统架构层面理解的任务，Copilot 便会陷入困境，生成相互冲突的代码模式和破坏依赖关系。就像一个语法完美的初级开发者，但缺乏对整个系统架构的理解。这让我意识到，早期的 Copilot 在构建完整应用方面，还存在明显的局限性。
2. Summarie.co 的诞生：一个 AI 辅助开发的设想
一个困扰我已久的想法浮出水面：如何解决人们普遍忽略的冗长条款和条件？那些法律文本晦涩难懂，如同古拉丁文。我最初认为，依靠人工总结这些法律文件成本高昂且效率低下。但随着 AI 技术的发展，尤其是 大模型 API 的开放，我意识到 AI 或许能胜任这项任务。
于是，Summarie.co 的想法应运而生。它是一个 Chrome 扩展程序，旨在为用户提供即时条款和隐私政策摘要，并通过 Web 控制面板跟踪使用情况和历史摘要。我给自己设定了一个目标：完全依靠 AI 来编写应用程序代码，我只扮演代码审查者的角色，提供反馈，但不亲自修改代码。
3. Cursor 的单文件限制与 Traycer.ai 的“思考”
在 Copilot 不足以胜任任务的情况下，我尝试了 Cursor，据说它具有更好的上下文感知能力。然而，Cursor 很快就遇到了问题。它无法通过 Docker 执行命令，这对于一个基于 Laravel 的项目来说是致命的。我只能手动搭建项目框架，然后交给 Cursor 处理后续的 Chrome 扩展开发、API 接口对接和数据库存储等任务。然而，Cursor 只能一次处理一个文件，这对于一个需要跨多个组件进行架构决策的项目来说，简直是灾难。
随后，我发现了 Traycer.ai，它自诩为适用于多文件开发的 AI 编程助手。Traycer 的独特之处在于，它不仅仅是编写代码，而是会“思考”。它会用文字表达整个问题解决过程，甚至在发现服务和框架模式时还会自鸣得意。这种“思考”过程允许我在它编写任何代码之前完善方案，更接近于真实的结对编程体验。当得到我的许可后，Traycer 交付了包括迁移文件、模型、控制器、Chrome 扩展 JavaScript 在内的所有内容。
4. Traycer 的“互联网知识”盲区与 Token 瓶颈
我天真地认为 AI “已经接受了整个互联网的训练”，便放手让 Traycer 运行。结果，迁移失败了。AI 不知道当前日期，所有迁移文件的时间戳都是零。Laravel 按照时间顺序运行迁移，外键约束因此失效。我手动修复了时间戳，但随后在前端又发现了更多错误。我陷入了一个恶性循环：向 AI 发出任务，等待它“思考”，然后修复它引入的明显错误，不断重复。
Token 使用量也成了一个主要瓶颈。更长的对话会更快地消耗 Token，导致速率限制和冷却期。Traycer 在经过几次对话后就会达到限制，迫使我重新开始，丢失所有上下文。
5. 代码库复杂性暴露 AI 的记忆与一致性问题
随着代码库变得越来越复杂，真正的挑战开始显现。AI 在上下文和对先前开发决策的记忆方面遇到了困难。每次开始新的对话，就像与一个从未见过该项目的新开发人员交谈。
AI 过于自信地宣布一切“完成并运行”，而没有进行适当的测试。我会发现命名空间损坏、模型中缺少列名或逻辑实际上不起作用。AI 的工作也显得漫无目的。它在整个代码库中使用不同的模式，有时过度抽象简单的概念，有时创建需要分解的大型函数。它很难坚持我给它的规则，经常忘记我明确概述的关键设计决策。
我甚至到了不知道该说什么才能避免引入更多问题而不是修复问题的情况。
6. Claude 与 MCP 服务器：一个真正的突破
就在我绝望之际，我发现了 Claude AI 与 MCP (Model Context Protocol) 服务器的结合。一位开发者声称，它可以“增强 Claude 的能力，使其能够通过 Web 搜索功能和浏览器界面测试来解决复杂问题”。
我安装了 Claude，设置了 MCP 服务器，并给它分配了一个全面的任务：审查整个代码库，提出重构建议，识别问题并制定实施路线图。
结果完全不同。Claude 彻底分析了代码库并设计了智能解决方案。凭借 MCP 服务器提供的计算机访问权限，它可以测试前端更改、运行 Docker 命令以及检查在线文档。
错误率显着下降。Claude 可以迭代测试周期，修复一系列错误，直到功能正常运行。这才是真正的 AI 结对编程——或者更准确地说，“AI 完成大部分工作，而我偶尔进行检查”。
Traycer 在几次对话中就会达到 Token 限制，而 Claude 可以在一次对话中消耗大量上下文（但在处理大型代码库时，它也可能更快地达到限制）。
与 Traycer 相比，这是一个巨大的进步。Claude 增强的思考能力意味着它可以审查完成任务的多种不同方式，并呈现给我，或者选择最优雅的解决方案。
7. Summarie 上架 Chrome Web Store
为了避免过度管理，我让 Claude 组织代码架构（它特别喜欢服务层模式）。它完成了这个项目，达到了相当高的标准，甚至通过了 Google 的 Chrome Web Store 验证流程。
有时会遇到带有问题的反馈循环，但不同之处在于 Claude 可以诊断并修复自己的问题，因为它可以使用 MCP 服务器访问我的桌面、Docker、Web 和它自己的 Chrome 浏览器。
你还可以设置 Claude 中的项目说明并添加文档。我认为这是 Claude 的超能力。它使用这些来做出决策，因此你可以在此处设置应用程序的规则，它会在做出任何决策之前参考这些规则（大多数情况下）。
8. Summarie 的功能介绍
最终的应用程序搜索 DOM 中的条款和隐私政策链接，自动向相关页面添加摘要按钮。用户可以通过 Chrome 扩展弹出窗口获得即时摘要，该摘要由 Jina.ai 和 Segmind 的集成提供支持，用于 AI 处理。Web 控制面板允许用户查看以前的摘要、查看使用统计信息和管理信用额度。
你在 summarie.co 上看到的一切都是由 AI 设计和开发的，并由我进行战略提示。
9. Claude 的局限性：一个“过度热情的小狗”
尽管 Claude 比其他工具表现出色，但它仍然存在一些缺点。我一直把它想象成一只非常热情的小狗开发人员，如果放任自流，它会为了涵盖每种可能的边缘情况而过度复杂化逻辑，总是寻求最全面的解决方案而不是最优雅的解决方案。它热衷于向前冲，继续编码，而不是在商定的里程碑处停下来进行审查。
每当 Claude 无法通过 Desktop Commander 从终端获得响应时，它都会创建一个“测试脚本”，而不是寻求帮助或调试实际问题。我怎么说都无法阻止它这样做。
Token 限制也是一个噩梦。如果它达到对话限制，它有时会留下整个未完成的文件，其中一半实现的功能和不完整的逻辑散布在整个代码库中。
我很快学会将 git 提交构建到它的工作流程中，因为它在部分更改文件时耗尽了 Token，并且达到了对话限制，所以我被迫启动一个新的对话，在那里我会遇到 Claude 的克隆体——超级有帮助的开发人员 58，他会阅读文档，然后惊呼“我找到了问题！”，然后带着更改螺旋进入代码库。
10. AI 开发成功的六项关键策略
通过这次令人沮丧但具有教育意义的旅程，以下是在使用 AI 编码助手（例如 Claude）时真正重要的事情：
- 事先规划一切。 我的意思是所有内容——数据库模式、流程图、架构决策。你提供的文档越详细，AI 构建连贯内容的机会就越大。
- 经常且频繁地提交。 在每次重大更改后，提交到版本控制。当 AI 不可避免地破坏某些内容或由于 Token 限制而留下未完成的文件时，你会感谢自己。
- 不要让它向前冲。 AI 不擅长在商定的里程碑处停止。它想要继续编码和“改进”事物。定期阻止它并审查它实际构建的内容。
- 不断提醒它有关功能。 使用 Claude，我必须不断提醒它，它可以访问 MCP 服务器以获取最新信息和库。它会默认使用过时的知识。
- 随着复杂性的增加而放慢速度。 随着代码库的增长，你需要放慢速度，并在请求中更加具体。包括不该做什么，而不仅仅是你想要什么。
- 文档有所帮助，但并非万无一失。 记录进度确实可以减少问题，但 Claude 仍然可以忽略已记录的决策或你已建立的模式。
11. AI 开发的未来：潜力与风险并存
你能用 AI 构建生产应用程序吗？也许可以。你应该这样做吗？可能不会。你能用 AI 构建产品吗？也许可以——我做到了。我能保证它的稳定性吗？绝对不能。我对使用此代码库进行扩展有信心吗？没有机会，这可能会让许多 Vibe-Coding 初创公司措手不及。
当我使用 AI 编写大部分代码时，我没有像开发者那样获得同样的成就感。不知道正在发生的所有更改，并且知道总有一天我必须手动修复这些更改，这令人不安。
对于原型设计，这是一种乐趣。你可以快速获得一些有效的东西来证明概念或测试市场反应。但我会将其视为一次性版本——概念验证，而不是生产代码。
我想 AI 开发只会变得更好，但我仍然不确定是否要将业务押注于它。在复杂的代码库中出现的不可预测性和细微错误使其对于任何关键任务都过于危险。
问题不在于 AI 是否会改变开发——它已经改变了。问题在于我们是否可以在 AI 辅助和人为监督之间找到最佳平衡点，从而真正产生可靠、可维护的软件。
在这次 AI 驱动的 “Vibe-Coding” 之旅中，我深刻体会到 大模型 技术在软件开发领域的巨大潜力，同时也意识到了其存在的局限性。选择合适的 AI 工具，并结合有效的开发策略，是成功利用 AI 辅助开发的关键。虽然目前 AI 尚不能完全取代人类开发者，但它无疑已经成为我们强大的助手，助力我们更快地实现创意，探索更多可能性。