AI 编码是否走得太远了？我感觉我快要失去对自己的项目的控制了。
1 分•作者: Shaun0•10 个月前
我想分享一下我对 AI 编程助手的看法，这个问题困扰我很久了，我认为“拿着信用卡的孩子”这个比喻完美地捕捉到了一些人所说的“氛围编程”的危险之处。至少在我们拥有真正的人工通用智能（AGI）之前，这似乎是一个严重的问题。
在密集使用了 Cursor 接近一年之后，它给我带来的速度之快让我感到震惊。它可以快速搭建整个功能，连接组件，并在几秒钟内编写复杂的逻辑。这种感觉就像开手动挡和自动挡汽车的区别。或者更准确地说，就像阅读详细文档和观看总结视频的区别。
这让我想起了 2023 年我第一次开始使用 GitHub Copilot 的时候。那时，它主要用于自动补全方法和提供上下文建议。这种程度的辅助感觉恰到好处。对于更复杂的问题，我会主动切换上下文，向基于网络的 AI（如 ChatGPT）提问。我仍然是那个掌控一切的人。
但像 Cursor 这样的工具完全改变了这种动态。它们非常主动，以至于它们正在剥夺我深入思考业务逻辑的习惯。并不是我失去了思考的能力，而是我正在失去这种根深蒂固的、潜意识的行为。我不再被迫将整个架构牢记在脑海中。
这导致我对项目的掌控感逐渐减弱。工作流程变成了：
告诉 AI 编写一个函数。
调试和测试它。
告诉 AI 编写下一个与之连接的函数。
循环往复。虽然速度很快，但我最终得到了一系列我通过提示而产生的黑盒子。我的角色从“我知道我正在构建什么”变成了“我知道我想要什么”。这之间存在着微妙但至关重要的区别。我正在成为一个指导 AI 实习生的项目经理，而不是一个构建解决方案的工程师。
这对个人开发者和项目的长期健康都是有害的。如果团队中的每个人都采用这种工作流程，谁真正理解全局？
这里有一个具体的例子完美地说明了我的观点：编写 git 提交消息。
每次提交时，我都有一个个人规则，即审查所有已更改的文件并用我自己的话编写提交消息。这迫使我综合这些更改，并巩固我对项目在特定时间点的状态的理解。它保持了我对项目的掌控感。
如果我让 AI 自动从差异中生成提交消息，我可能会节省几分钟。但一个月后，回过头来看，我对这次提交没有任何真正的记忆或上下文。它只会是一个技术上准确但毫无灵魂的日志条目。
我担心通过优化短期速度，我们正在牺牲长期的理解和控制。
还有人有这种感觉吗？您是如何平衡这些工具的强大功能与保持对您自己代码库的掌控的需求的？
查看原文
I wanted to share some thoughts on AI coding assistants that have been bothering me for a while, and I think the analogy of "a kid with a credit card" perfectly captures the danger of what some call "vibecoding." At least until we have true AGI, this feels like a serious issue.<p>After using Cursor intensively for the better part of a year, I'm stunned by how fast it is. It can scaffold entire features, wire up components, and write complex logic in seconds. The feeling is like the difference between driving a car with a manual versus an automatic transmission. Or maybe, more accurately, like the difference between reading detailed documentation versus just watching a summary video.<p>It's brought me back to when I first started using GitHub Copilot in 2023. Back then, it was mostly for autocompleting methods and providing in-context suggestions. That level of assistance felt just right. For more complex problems, I'd consciously switch contexts and ask a web-based AI like ChatGPT. I was still the one driving.<p>But tools like Cursor have changed the dynamic entirely. They are so proactive that they're stripping me of the habit of thinking deeply about the business logic. It's not that I've lost the ability to think, but I'm losing the ingrained, subconscious behavior of doing it. I'm no longer forced to hold the entire architecture in my head.<p>This is leading to a progressively weaker sense of ownership over the project. The workflow becomes:<p>Tell the AI to write a function.<p>Debug and test it.<p>Tell the AI to write the next function that connects to it.<p>Rinse and repeat. While fast, I end up with a series of black boxes I've prompted into existence. My role shifts from "I know what I'm building" to "I know what I want." There's a subtle but crucial difference. I'm becoming a project manager directing an AI intern, not an engineer crafting a solution.<p>This is detrimental for both the individual developer and the long-term health of a project. If everyone on the team adopts this workflow, who truly understands the full picture?<p>Here’s a concrete example that illustrates my point perfectly: writing git commit messages.<p>Every time I commit, I have a personal rule to review all changed files and write the commit message myself, in my own words. This forces me to synthesize the changes and solidifies my understanding of the project's state at that specific point in time. It keeps my sense of control strong.<p>If I were to let an AI auto-generate the commit message from the diff, I might save a few minutes. But a month later, looking back, I’d have no real memory or context for that commit. It would just be a technically accurate but soulless log entry.<p>I worry that by optimizing for short-term speed, we're sacrificing long-term understanding and control.<p>Is anyone else feeling this tension? How are you balancing the incredible power of these tools with the need to remain the master of your own codebase?