我使用 Claude Code 两周后的体验

孵化…

Cursor 的恶作剧

我心爱的 Cursor 在几天前开始进行速率限制的恶作剧。在 2025 年 6 月 16 日后的两周里,我们几乎可以无限次访问 API 请求。当时我正在从事 Gumroad 赏金计划 以及与人工智能工程/大语言模型(LLM) 评估相关的咨询工作,因此有很多与代码相关的工作要做。除了代码生成之外,我还使用这些工具来更快地了解代码库,并提出许多问题。

但有一天,他们突然停止了服务,并开始限制访问速度。我承认我确实过度使用了这些工具,所以对此并不感到遗憾。值得思考的是,这是我的问题,还是 Cursor 的问题。

但此后,人们被限流的速度明显加快,只有通过自动模型功能才能获得无限使用权限。就我个人而言,我只信任Sonnet 4和o3这两个模型。它们在代理搜索和代码生成方面都是顶尖的。使用这些模型时,API使用费可能会迅速累积,导致“哦,丈夫……现在我们无家可归了”。

元素周期表

我对 Gemini Pro 2.5 和 GPT-4.1 有些信任,但我最常使用的是前者。哦,我忘了提一下,Opus 4 真的可以帮助解决一些 Sonnet 4 苦苦挣扎了几个小时的错误,所以当我在 Cursor 上遇到真正的问题时,我会暂时打开 API 使用定价功能来解决问题(或者只是将代码转到 Claude 聊天平台上)。

最近,Cursor(特别是 Sonnet)上的请求也开始变得有些缓慢。也许这是 Anthropic 的问题(有人给这家公司提供更多的 GPU 和高级分布式系统工程师来维护他们的 API)。

除了上述情况,我还受到许多tpot社区成员的影响,如@tokenbender@thepushkarp@xeophon_@menhguin等tokenbender社区成员的影响。Tokenbender的博客展示了该系统上可以实现大量高级用户和多代理功能,这让我也着了迷。

我如何遇到 Claude Code(又名 CC

孩子们,这就是我如何遇到 Claude Code 的故事。我已经订阅了 20 美元的套餐。我开始通过订阅使用 Claude Code;他们只提供 Sonnet 4,对我来说 90% 的时间都足够了。我在 Cursor 中安装了 CC。

Cursor 的差异审查工作流程太方便了,我无法放弃它。我喜欢审查大多数差异,不像某些人只是不断点击“接受所有”……(Anya Heh Face .jpeg)

图0:我使用 Claude Code 两周后的体验

你可以审查所有的差异,解决合并冲突,以及所有编辑器的好功能。

有时,你只是想要一点 o3 使用或 Grok 4 或其他新奇的模型。有时,你只是想要格式化一些东西,因为 CC 中的正确格式化复制仍然很糟糕。此时,我也被 Cursor 的通知声音打断了。抱歉,这篇文章变成了对 Cursor 的怀旧之作,但我保证接下来的部分都会涉及 CC。

无论如何,由于 Cursor 的限制太多,而我又有很多编码工作(工作和 gumroad 赏金哈哈),我决定尝试 200 美元的 Claude Max 订阅。它基本上是无限的 Sonnet 4 和 Opus 4(最好是这样),然后我开始尝试。我认为 100 美元的计划对于大多数人来说已经绰绰有余了。

模型是在哪里测试的?在介绍我的工作流程之前,我想先介绍一下我使用的编程语言和代码库类型。在过去的两周里,我大部分时间都在中等规模的 Python 代码库和 Ruby + Typescript 大型开源代码库上使用 Claude Code。5000 万个以上令牌。它们有规格和端到端测试,所以当我完成一个功能时,我确实得到了反馈——我可以运行规格,Claude Code 可以形成一个循环。我通常会建议它一个一个地修复规格。–fail-fast 以快速找到错误。在使用 Claude Code 之前,我已经使用 Cursor 大约一年了。

令人困惑……

当前工作流程

谈到工作流程,最初我只是输入内容进行修改。我盯着屏幕,看着它慢慢找到文件并进行编辑。我花了一些时间才开始信任它——尽管模型是Sonnet 4,但还是花了2-3天。(我一开始对开启自动编辑模式有些犹豫,哈哈)

一旦我建立了信心,就开始深入探索命令。我的努力是掌握基本命令——你需要通过实验和探索才能发现这些命令。仅仅阅读资料很容易忽略这些内容。

接下来的几部分正是我上面提到的——除了讲述我迄今为止的经验外,还有一份初学者指南。我目前的 Claude Code 操作方式是:从头开始,像与治疗师交谈一样倾诉我的所有问题,然后在情况变得棘手时切换到 Opus(/model Opus → Shift+Tab 进入规划模式)。

最近我发现,可以在claude.mdbranch-analysis.md文件中记录笔记——这些文件位于.claude文件夹内。这个小技巧我花了4天时间才摸索出来,自然而然地。

只需让 Claude 先将所有内容写入文件,然后从那里复制,就可以在一定程度上解决复制粘贴的噩梦。

提示:广泛使用 Shift+Tab 键;在计划模式和自动编辑模式之间循环。从 Opus 获取计划,然后用 Sonnet 完成 80-90% 的任务。这样会更快。下面的截图是我与 Pushkar 聊天时截取的。

图1:我使用 Claude Code 两周后的体验

Flibbertigibbeting…

基本上下文管理

如果你使用 Claude Code,它会在压缩之前显示 X%。看到这个数字时,我就会开始新的聊天——告诉 Claude 将重要内容记录在文件中,然后开始新的聊天。我直觉上觉得开始新的聊天更好。

有时,当我真正喜欢某条笔记,并且绝对希望保留部分内容时,我会进行压缩。否则,我就不会进行压缩。此外,压缩需要花费几分钟的时间才能完成。

许多代理框架都利用了“记事本”的想法。你可以告诉 Claude 将更改记录在记事本中。它会记录所有文件和所有编辑/删除/添加,也许还有用户笔记(你可以告诉它这样做)。当你回到分支并开始一个新会话时,这会非常有用。顺便说一下,你可以通过 /resume 恢复旧会话。恢复对话选项。我使用了一周后才发现这个功能 😭。以下截图来自 token 的博客

图2:我使用 Claude Code 两周后的体验

转换中……

为什么 Sonnet 在 CC 中比在 Cursor 中感觉更好?

我在开始使用 claude code 的那天发布了这条信息,哈哈,算法似乎捕捉到了这一点。顺带一提,有很多不错的回复。

要点是,Claude Code 可能使用了与目前相同的工具进行了后训练。在目前的环境中,它更舒适。现在我也体验过使用它了,可以说他们实现的“工具调用”选择对此起到了作用。

我认为它也能更好地管理上下文——Cursor 可能会对上下文进行压缩或优化(猜测),而 Claude 则可以以普通的方式读取行。我还觉得 CC 可能更有效地使用了标记。

顺便说一下,最近我开始在独立终端中更多地使用 CC,而不是 Cursor,因为后者存在错误。

Smooshing…

Claude 子代理

图3:我使用 Claude Code 两周后的体验

当您看到这个可爱的待办事项列表时,这是 Claude 子代理在发挥作用。我不知道它们是如何生成的,但这在一定程度上有助于更好的上下文管理。

Reticulating…

搜索

Cursor 允许模型进行正常搜索和语义搜索。如果我没记错的话,代理搜索只是让模型自己探索代码库,并允许它自由使用 grep、ripgrep 等工具。Cursor 允许调用语义搜索工具。我认为总体而言,Cursor 搜索速度更快……也许我会尝试 MorphLLM 的检索工具 来尝试使用 CC 进行语义搜索。

说到 CC,搜索速度相当慢(可以通过上述上下文管理技术来缓解)。但问题是,你可以使用子代理。您可以在大型代码库中进行大量搜索,然后告诉 Claude 并行使用子代理。它有一个以多线程方式运行的任务工具。它将部署多个代理——这些代理类似于 Haiku 或 Sonnet,我对此并不了解,但如果它们只需要执行 grep 工具调用,那么我认为即使是 Haiku 也没问题。以下是来自 Anthropic 官方博客文章 claude-code-best-practices 的截图。这是由 “任务工具” 完成的。

图4:我使用 Claude Code 两周后的体验

上述截图中的关键提示是使用子代理并使用 /think /think hard /ultrathink

了解你的命令

我一直想知道如何在不切换到其他终端的情况下使用 bash 模式。

然后我查看了快捷键 Shift + ?。你只需输入 !。我是在使用了一周后才了解到这一点,哈哈。

图5:我使用 Claude Code 两周后的体验

它可以执行单次命令,但我认为它无法像普通终端那样运行 Python 交互式 shell。再次,我喜欢这些颜色。

图6:我使用 Claude Code 两周后的体验

顺便说一下,你可以使用 claude -p “搜索互联网并告诉我关于人类的” 在无头模式下运行 Claude,因为它是一个标准的命令行工具。

继续说下去……这听起来可能很傻,但我之前不知道在 Claude Code 中可以 @ 文件,用了大概 3-4 天才发现。@Josh9817 最终告诉我了。如果我之前检查过快捷键,我就应该意识到了这一点。

另一个功能是 记忆。我目前还没怎么用过这个功能,但它就像在系统提示符中添加自定义指令。这些指令会在不同会话中生效。

图7:我使用 Claude Code 两周后的体验

Claude 如何查找记忆

Claude Code 会递归地读取记忆:从当前工作目录开始,Claude Code 会递归到根目录 /(但不包括该目录),并读取找到的任何 CLAUDE.md 或 CLAUDE.local.md 文件。当您在大型存储库中工作时,这尤其方便,您可以在 foo/bar/ 中运行 Claude Code,并在 foo/CLAUDE.mdfoo/bar/CLAUDE.md 中都有记忆。

Claude 还会发现当前工作目录下子树中嵌套的 CLAUDE.md。这些文件不会在启动时加载,而是在 Claude 读取这些子树中的文件时才被包含。

图8:我使用 Claude Code 两周后的体验

我喜欢这些颜色!

沉思……

Sonnet 与 Opus 笔记

Sonnet 在 90% 的情况下都能胜任,事实上它在 SWE-bench 中的得分比 Opus 4 高出几分。它在 Python 和任何类型的前端代码方面表现出色。当上下文较长时,Sonnet 明显优于 Opus,且更具自主性和速度更快。

我注意到,Opus 在经过几轮指令后往往会感到困惑。我如何解决这个问题 → 在这种情况下,我通常会告诉它将内容转储到.Claude 文件夹中的某个文件中,然后开始新的对话。如果是一个比较棘手的错误,我会先使用 Opus。否则,我就直接使用 Sonnet。如果你已经向 Sonnet 提供了所有相关的上下文信息,那么大多数情况下 Sonnet 都能完成任务。

当 Sonnet 卡住时,Opus 表现良好——打开新窗口并频繁使用 Opus。

面向自定义命令

/pr-comments/review 默认可用,但它们展示了自定义命令可能的样子。使用这些功能需要安装 GitHub CLI。

假设我在一个分支上做了一些更改,现在想重新开始讨论。这种情况下有两种选择:

  1. 你可以使用 review 功能让它审查差异
  2. 还有一个命令可以获取 PR 评论

我可以在某个文件中提及相关评论的人员,从而跳过其他机器人等内容。您还可以告诉它“我们要开始一个新会话”,然后我们通过审查 PR 查看差异。这需要更多步骤,但会提供更多背景信息。更简单的方法是告诉它“请检查主分支的差异”(这类似于主分支功能中的光标差异,我也非常喜欢这个功能)。

图9:我使用 Claude Code 两周后的体验

杂项命令提示

  • 快速按两次Esc键,即可从对话中的任何位置进行分支!
  • 您可以在会话开始前使用 / permissions 来调整权限
  • 如果您敢于冒险,可以使用 claude –dangerously-skip-permissions

我喜欢这个视频:

接下来我想尝试的事情

  1. 我想尝试定义一些自定义命令,并以类似的方式使用它们
  2. 我想尝试一些 MCP 服务器,比如 Playwright 服务器,以实现前端开发的自动化。我们需要专注于为 Claude 创建反馈循环,以便它能够截屏、查看截屏,然后对 UI 进行迭代。
  3. 本文中提到的所有内容 如何充分发挥 Claude 代码的优势——第 2 部分
  4. 我想尝试一些提示优化。这已经在我待办事项列表中,因为我在工作中也有几个与此相关的任务。我认为这个过程会是这样的:首先,我需要确定用于评估提示的标准。从一些简单易行的开始,然后在实践中逐步完善。我可以将它放在一个文件 rubric.md 中。然后,我可以准备几个文件,将可能进入我的 prompt.md 的上下文放在这些文件中。prompt.md 存储提示。然后,我们使用提示运行 claude,将输出传递给另一个 claude 实例进行判断,要求一个 claude 实例找到缺陷,然后更新提示。这可以是一个单一的 claude 实例循环,也可以是一个多代理系统。(灵感来自 Nirant 的帖子)
  5. 多智能体系统,其中我使用多个 CC 实例,并允许它们通过动作日志进行通信

结论

我认为 Cursor 也是一个强大的工具,其 UI/UX 设计非常出色。然而,Claude Code 在功能强大性方面更胜一筹(但显然在 UI/UX 和学习曲线方面有所欠缺)

总体而言,我认为由于 Claude Code 基于 CLI 的性质,它会促使用户进行更多的探索。我认为,由于缺乏可视化的 UI 提示,它鼓励用户进行探索。许多内容都是隐藏的,需要用户自己去发现。它会奖励你的好奇心。出于这个原因,它可能更适合极客和高级用户。

功能请求

  1. 可能的 UI 集成(可以查看 Claudia,但他们实现这个功能只是时间问题)。
  2. 像 Cursor 中的检查点一样。我知道有 Git,但 Cursor 的检查点还是太方便了。

  1. 更好的复制粘贴功能 😭
  2. 允许使用其他模型(好吧,他们不会提供这个)

如果你读到这里,感谢你的阅读!希望你学到了新知识。

本文文字及图片出自 My Experience With Claude Code After 2 Weeks of Adventures

共有 372 条讨论

  1. 读完这些对 Claude Code 的好评如潮的评论后,我仍然觉得要么是大家都收了钱,要么就是他们都是终端窗口和 Emacs、Vim 等编辑器的铁杆粉丝。使用终端是他们的强项——这已经融入了他们的基因。

    每次看到评论说 Claude Code 比 Cursor 好得多时,我都会启动它,购买订阅,并在大型、复杂的 TypeScript 代码库上运行它。首先,整个过程非常耗时。其次,学习曲线非常陡峭:你必须通过终端输入命令。

    而结果与 Cursor 内置的 Claude 完全相同——只是速度更慢、更不清晰,生成的代码也更难审查。我不知道……目前,我唯一的印象是,评论中的那些网红要么是受赞助的,要么已经花了 200 美元,现在正在为他们的选择辩护。或者他们只是还没有充分使用 Cursor,不知道如何充分利用它。

    除了据称限制更高之外,我仍然看不到 Claude Code 有任何真正的优势。我不明白。我已经为 Claude Code 付了钱,还为 Cursor Pro 付了 200 美元,但到目前为止,我使用 Cursor 的效率更高。

    我从事编程工作已有 18 年,每天都要编写大量代码,我可以说 Cursor 给我带来了更多好处。当需要处理大型、长期任务时,我会使用 Gemini 2.5 Pro;而日常工作则使用 Claude 4.0。

    因此,目前还没有人说服我,我也没看到其他好处。也许以后会吧……我不知道。

    1. 我认为这是因为很多人对软件开发中真正困难的部分存在深刻误解。大多数情况下,程序并不涉及新颖或复杂的算法之类的内容。它更多的是将想法拼凑在一起。但这一切都发生在规格、设计、架构、规划等之后。

      我认为这与任何行业一样具有欺骗性:工作很容易被“完成”并正常运行。但要以一种具有持久耐用性的方式正确完成它却很难。借助人工智能,我们可以快速生成这些看似完成且能正常运行的程序。对于原型或一次性项目而言,这可能非常棒!但如果你在为计划居住30年的人建造房屋,这种做法行不通。

      1. 是的,自12年前开始工作以来,编写代码几乎变得轻而易举。自2012年起使用Intellij。困难的部分一直是阅读旧代码,找出向后兼容性中断的边界,并确定如何安全地进行部署。

      2. >让工作“完成”并正常运行很容易。但要以一种具有持久耐用性的方式正确完成它却很难。借助人工智能,我们可以快速生成这些看似完成且能正常运行的程序。对于原型或一次性项目,这可能很棒!但如果你在为人们建造一栋要住30年的房子,这种做法行不通。

        说实话,这就是大多数公司为软件开发人员支付高薪的原因。

        当面对新工作或项目时,你更倾向于称赞架构和质量?还是在想它是怎么走到这一步的?

        1. 快速行动并不总是错误的选择。很多时候,这是正确的选择……至少在一段时间内是这样……

          也许人工智能会颠覆快速上市的阶段。说实话,这可能完全有道理。但仍然有一个严肃的工程领域需要妥善处理。

    2. 我以前也有类似的感觉。但最近开始使用 Claude Code,对我来说,它确实比 Cursor 更好用。

      我不确定为什么。不过,Claude 似乎更了解事情的来龙去脉,知道不要做不必要的更改。我有时仍然需要指导它,告诉它做不同的事情,但感觉它更有效率了。

      就个人而言,我还喜欢它通常一次只向我显示一个更改/文件,这样我更容易审查。Cursor 可能会同时打开多个文件,每个文件都有大量更改,这让我很难快速理解。

      顺便说一下,我在 VSCode 内的终端面板中使用 Claude Code,并安装了扩展。因此,Claude 会打开一个文件选项卡,显示建议的更改。

      1. > 个人而言,我也喜欢它通常每次只向我展示一个更改/文件,这样更容易进行审查

        这很有意思。我没有使用过 Cursor,但我对 Claude Code 感到不满的一点是,它要求我批准的一些单独更改太小,我无法做出决定。有些情况下,我最初几乎拒绝了更改,但看到完整的更改集后,我意识到 Claude 的做法是合理的。相反,有些情况下,我绝对应该更早地阻止 Claude。

        克劳德通常在完成整个系列后才描述其变化,而不是在之前,这并不 helpful。

        …说实话,我希望有一种简单的方法可以回到过去,即回到对话的较早阶段时,代码状态也会随之恢复。我可以用 Git 在一定程度上模拟这种功能,但我更希望它作为 Git 之上的一个层。我希望使用 Git 来跟踪其他内容。

        1. > 它要求我批准的一些单独更改太小,我无法做出决定。有些情况下,我最初几乎拒绝了一个更改,但看到完整的更改集后,我意识到 Claude 的做法是合理的。

          是的,我已经习惯了快速审查,如果它作为任务的一部分是合理的,就让它继续进行,直到完成整个任务。大多数情况下,最终它都会做出正确的决定。

          我喜欢它不会自动提交所有内容,就像Aider一样,因此撤销操作非常简单

          我还会维护一个TODO.md文件,记录当前工单/PR中所有待完成的任务计划。我让CC跟踪这些内容。CC会从该文件中提取任务,将其分解为独立的子任务,完成后我再让它更新TODO.md中的进度。我还会让它准备文件并创建提交

          我使用它的方式让我感觉仍在编程,但无需亲自编写代码或执行命令,也不用陷入搜索问题的困境。我可以让CC为我完成几乎所有事情。它消除了我想要实现目标时的繁琐步骤

          1. > 我喜欢它不会像Aider那样自动提交所有内容,因此撤销操作非常简单。

            是的,我确实很高兴它不会自动提交。我遇到的主要问题是,我从未确定过提交的粒度应该多细。有时我会将它们设置得非常细致,因为我正在尝试使用 Claude,并且希望能够回滚到对话中的任何一点——但现在我必须每次都写一条消息来记录哪些是哪些。相反,当我没有将提交设置得那么细致时,我就失去了回滚的能力,有时会为此感到后悔。

            此外,有时 Claude 会变得太聪明了!假设我决定让 Claude 用一个略微不同的提示再试一次。我将当前的更改保存到一个分支中,回滚到之前的状态,然后让 Claude 再试一次。有时 Claude 会说:“我看到这已经在 XX 分支中实现了。让我继续基于该实现进行构建吧。”

            1. 我的提交信息一直都很糟糕,所以这并不让我感到困扰。我最后会把所有内容合并在一起。

              不过有时我会忘记在任务之间提交,或者它会疯狂地修复我不想处理的编译器错误。

            2. 是的,有时我喜欢它检查 Git 日志并正确找到我试图实现的参考代码,但有时我真的希望它能以不同的方式处理,这会让人感到烦躁。

              有时我会告诉它一个我想解决的问题,它会提出一个我不想要的解决方案。我会告诉它采取不同的方法,它会听一会儿,然后突然又想回到它最初的方法,我需要再次引导它,甚至多次引导

              > 但现在我每次都必须写一条消息来跟踪哪个是哪个

              我让它为我写提交信息。通常它也会根据最近处理的任务智能地选择要包含的文件。我让它在我的监督下运行 git add 和 git commit

              我正在处理的一个仓库有一些相当烦人的钩子,会在提交时检查代码格式(并强制修改文件以修复格式问题)。如果我忘记在提交前手动检查,就会得到一个包含格式错误文件的“错误”提交,以及一堆未提交的文件带有格式修改。CC 大多数情况下会看到错误信息,并自动提出正确的命令来撤销或修改提交以包含格式修改

        2. 如果您喜欢 Claude Code,但(1)更喜欢不需要在每次文件编辑时进行审查的代理,或者(2)想念 IDE 进行差异审查等操作,我建议您尝试一下 Amp:https://ampcode.com。它同时支持 CLI 和 VS Code 扩展,且我们从头开始构建它以支持代理式编码,因此无需在每次编辑时请求权限,提供一流的编辑器扩展(我个人越来越多的时间用于审查差异,而 VS Code 的差异视图非常出色),并通过子代理进行代码库搜索和扩展思考(结合使用 Sonnet 和 o3),以最大化上下文窗口的利用。

          1. 感谢您的建议。你们是否有订阅计划?还是我需要单独为使用的模型/API付费?

      2. 我很少让Cursor为我进行不需要的更改。也许这与提示有关?我对自己的需求非常挑剔,尽量详细地说明上下文,并提示哪些文件需要特别关注。

      3. 你怎么证明自己不是机器人?我感觉之前在哪里见过类似的评论。

        告诉我们你做了什么——如何操作、在什么条件下,以及使用了哪些编程语言。究竟是什么让它更好?它只是搜索文件吗?这显然不够客观。

        到目前为止的印象是……嗯,你说它只是看起来更好。但这种推理方式走不远。

        客观地说,现在在我看来,Claude the cat 更好,因为周围的人都说它更好。但实际上没有人解释过为什么。因此,这种炒作是凭空捏造的,没有客观的理由。

        1. > 你如何证明自己不是机器人?我感觉我以前在某处见过这样的评论。

          …你回复的账号是2007年创建的。个人资料页面上有简介。

          也许你觉得自己之前见过这个评论,是因为这是很多人共享的观点?即使你没有。

        2. 这里没有阴谋论,兄弟。Anthropic无论如何都会得到报酬。

    3. 据我所见,你必须正确理解 claude.md 的说明,其中大部分是使用规划模式。CLI 就是你与它交互的方式。它更像监督代码,而不是氛围代码。

      它更注重构建一个编码引擎,而不是编写代码。它无需人工干预,但与 Cursor 不同,它并非完全无需关注。你可以观察并中断它。它非常适合全面的TDF——它会识别功能、编写功能测试、让测试失败,然后重写代码以通过测试。但到了某个阶段,你会意识到指令有误,而由于你处于循环之外,必须中断它。

      我认为这是自然演进,但并非适合所有人。那些讨厌无法编写函数的人会更讨厌 claude 代码。但有些人喜欢编写自己的引擎。

      1. 我再次充满快乐地构建。做经理很难,孩子们,对前端框架的舞步感到厌倦。现在,我只需构建、构建、构建,然后将我的想法更快地传达给用户,比他们做出决定还要快。

      2. Cursor 也能做到同样的事情吗?只是在一个 GUI 中,你可以看到所有发生的事情。

    4. 人们尚未意识到的是,Cursor 并不是一个产品,而是每个产品都在努力添加的一系列功能。

      这里的关键在于,除了深度集成外,存在一种与工具无关的最佳代理解决方案协作策略。

      这些经验最终将凝结为“最佳实践”,人们将使用自己选择的编辑器或 IDE 应用这些实践,而所有这些 VS Code 分支都将消亡。

      1. 可以说,这就是我仍然看好 GitHub Copilot 的原因。无论喜欢与否,微软/GitHub 在功能对等性方面已证明是赢家,且目前拥有巨大的护城河。既然可以“使用原版”,为何还要使用 VS Code 分支?

        微软/GitHub 甚至通过开源 VS Code 中大部分 Copilot 集成代码,表明了其与分支竞争的信心。

        从美学角度来看,我大部分时间都喜欢 VS Code Copilot/Copilot Chat 的 UI/UX,当然比我喜欢 Claude Code,也比我喜欢 Cursor。

    5. 你的抱怨是针对 claude 还是针对 GPT 助手的?

      我很好奇这是什么意思:

      > 在大型、复杂的 TypeScript 代码库上运行它

      你所说的“运行它”是什么意思?

      你是将整个代码库一次性放入上下文窗口吗?你是先提供上下文和结构提示,还是先提供系统架构?

      我看到的大多数人无法“理解”GPT助手,是因为他们没有为其提供上下文和分步指导。

      如果你把它当作一个非常高级的橡胶鸭子,它简直就是魔法,但你仍然需要作为高级工程师来指导项目或任务。

      你不能只是把一个10,000行代码的文件扔进去,问一些模糊的问题,然后期望得到有价值的东西。

    6. 我用了两周的$17/月廉价订阅。它既令人惊叹,又令人沮丧。

      我最终得到了8000行Rust代码和12000行Markdown。我认为这些Markdown设计和明确的任务与使用测试框架进行单元测试一样,是实现人类与工具互动的关键。

      然而,我不确定这种“魔力”是来自风险投资的补贴,还是其他因素。

      它确实让Rust(一种我并不熟悉的语言)感觉像是一种脚本语言。……GitHub仓库名为‘knowseams’。

    7. 期望每个人都更换自己的编辑器/IDE 是一个巨大的障碍,而且光标在支持方面并不像 iOS 开发那样完善。一个能够独立于你选择的编辑器运行的工具要容易采用得多。它也更容易进行脚本编写和自动化。

    8. > 其次,学习曲线很陡峭:你必须通过终端输入命令。

      这应该是 CS101 的一部分。

    9. 每个用例(对于许多人来说,这是按项目来定的)可能会决定适合该工作的工具。

      对于新项目,我发现 Claude Code 非常有用,因为我从业务文档、顶级需求文档开始,然后从那里出发。最终(且无需花费大量时间和精力),我就能获得 README、实施计划、高层次架构、里程碑,以及通常的 Swagger 规范、管道设置和测试框架。

      依我之见,将 CC 指向一个大型 TypeScript 项目的文件夹会浪费大量计算资源和令牌,而收益微乎其微。这并非该工具的合理用途。我对大型复杂 TypeScript 代码库的看法也非常明确:这对人类来说也不是个好主意。

      将 CC 指向 Python 或 Go 仓库则会带来完全不同的体验。此外,正如上文所述,CC 在初始阶段的表现尤为出色。

      对于大型复杂 TypeScript 仓库,我更希望获得非常具体、针对性的帮助,而非泛泛而谈的整体性建议。但这也最大限度地减少了我最初寻求帮助的原因。

    10. 我非常擅长使用 JetBrains IDE,而 VSCode 则无法与之相提并论。我非常擅长使用终端。Claude Code 恰到好处地充当了模型与我的 IDE 之间的桥梁,在不破坏我的 IDE 的情况下增强了我的工作流程。就是这样。我不会花$200。

    11. 部分原因在于个人喜好。我个人不喜欢VSCode及其衍生版本;它感觉臃肿且产品内充斥广告。我希望编辑器能从意识中消失,而Sublime正是如此。

      在此背景下,CC堪称卓越。

      1. 很多人不知道你可以完全更改VSCode的UI。特别是侧边栏——直接删除它们。你将得到一个空白屏幕,上面显示语法高亮的代码,配合LSP,你可以使用命令面板,或者如果你想更像Vim/Emacs,那么基本上每个操作都可以通过键盘绑定实现。

        1. 我假设在后续运行中会好一些,但每次启动一个空白的 VSCode 设置时,我都会被一系列弹出窗口、持久的工具提示、额外的标签等所困扰,这些东西最多只能说是无聊且多余的。它确实有一种强烈的 Windows 风格的“我的计算环境是一个障碍赛道”的感觉。

      2. 这很有趣,我一直认为 Sublime 更直白,每次打开它都在乞求金钱。

        1. 有一个巧妙的方法可以移除提示屏幕

          1. 这是我从未后悔的一次购买。Sublime 在编写代码之前是如此完美,直到编写代码被彻底颠覆

          2. 是的,安装 vscode,确实是一个很巧妙的小技巧。

    12. 使用这些工具(与大多数事情一样)提高工作效率的关键是紧密的反馈循环。

      Cursor 有一个非常棒的标签完成模型。它使用一系列启发式算法来理解你的操作并加速操作。这有点像一个非常高级的宏引擎,只不过我不用费尽心思去编程编辑器——它就是管用,如果不行,我按下Esc键,大概半秒钟就能解决。或者我切换到代理模式,迭代周期大概是30秒到一分钟。

      对于完全基于代理的编辑器,迭代时间可能需要15到30分钟,这会严重打断我的工作流程。审查代理的输出结果是一项繁琐的任务。与编辑器中快速的接受/拒绝循环相比,它需要消耗更多的大脑带宽。而且我必须在给予它网络访问权限(巨大的安全隐患)和保持离线状态(在大部分代码库中会严重限制其功能)之间做出选择。

      我发现对于那些我不在乎维护/安全/可靠性的临时代码库,我可以忍受这一点。当我使用一种我不完全理解的语言或框架(但模型理解得更好)时,它也非常有用。但对于我大多数工作来说,它产生的结果很差,最终对生产力产生负面影响——至少目前是这样。

      我相信这会得到改善,但就目前而言,我在 Cursor 中一直能获得更好的结果。

    13. 不要以为我只是来尝试一下:不,我已经连续几个月每天都在使用 Cursor 了。我非常精确地设置了规则,制作了地图,编写了说明和限制条件,以便大语言模型(LLM)理解如何处理当前的代码库——在哪里找到东西、做什么、不做什么、东西应该是什么样子。我尽量简洁地编写,以便一切都能放入上下文窗口。

      我有一个单仓库(monorepo),因此不同的指令和规则分散在仓库的不同角落,我需要手动添加这些内容。使用Claude来完成这些操作很困难:虽然勉强能用,但这是一种权宜之计。通过用户界面(UI)管理要容易得多。正如俗话所说,亲眼看到一次比记住十次、输入命令并配置它要好。

      对于Vim和Emacs用户,我也有同样的看法。至今无人能向我证明,使用触控板或鼠标键盘的普通程序员在编码和导航速度上会更慢。这纯粹是个人喜好问题。我注意到,那些热爱这些工具的人只是在工作中感到无聊,想让大脑得到娱乐。这既不是好事也不是坏事,但并不会带来真正的效率提升。

      顺便说一下,有一项研究(虽然有些陈旧)表明,使用大语言模型(LLM)并不能大大提高编程速度。是的,它可以快速输出代码,但组装最终结果却需要花费更长的时间:你必须审查、润色、重头再来、删除一些内容,然后再次开始。这并不是那么简单。

      说到 Claude,他是一个真正的代码大师。即使你要求他不要这样做,他仍然以超快的速度生成大量不必要的代码。你要求他做最简单的事情,不要多做任何事情,但他仍然会写出一堆无用的测试代码,这些测试代码既复杂又无法正常工作。

      这是它的缺点。总体而言,直接说出要做什么比坐在那里绞尽脑汁更容易编程。但即使如此,这也不是一件简单的事。如果你自己没有仔细思考你要做什么,最终结果只会是一团糟。当我感到疲倦时,我几乎总是会扔掉用大语言模型(LLM)编写的内容。我认为从来没有例外。

      要编写出像样的东西,唯一的方法就是彻底研究:画图、写出所有内容,然后才告诉大语言模型(LLM) 具体该做什么。然后仔细检查,确保它没有写多余的内容,删除多余的部分。只有这样,才能一点一点地完成。如果任务稍有复杂,那么“给我做一个功能,我按下按钮就走人”的方式就行不通了。

      是的,我有些激动了——必须发泄一下。关于大语言模型(LLMs)和使用它们进行编程,我有很多话要说,而不仅仅是关于 Cursor 和 Claude。这些工具彻底颠覆了我们的编程方式…

      1. 我记得在人工智能出现之前,我曾做过几个项目,我会设置模板、小代码生成器和模式来遵循。这样做可以轻松地完成正确的事情。完成工作非常容易。这是一个小团队,大家志同道合,很容易朝着同一个方向努力。你的帖子让我想起了这一点。

        我也注意到 Claude 的这一点,我写过命令,修改过 Claude.md,甚至写过钩子。给它提供了非常精确的功能指南。我看到了和你一样的问题。感觉 Claude 似乎内置了一个懒惰的杠杆。

        我不断玩 GPT O3,它会取用规格、Claude 工作的 repomix 片段,并给 Claude 提供一个新的 gap.md 进行追求。重复这个过程。它可以工作,但你的光标流似乎更好。

        我三十年来最高的速度是每天 1.6 个斐波那契复杂度点,现在三周以来,使用 Claude 的速度是 4.3,这简直太疯狂了。我是一个完全的业余爱好者,如果我更组织一些,我认为我可以达到 9。可能不需要这样做,只需等待 Claude 模型的下一次迭代即可。

        1. > 我最高的速度是三十年来每天大约 1.6 个 Fib 复杂度点,现在在过去的三个星期里,使用 Claude 的速度是 4.3,这简直太疯狂了。

          你在哪里工作,能够如此准确地追踪我认为是 30 年来的敏捷故事点?

          我甚至都不记得我的冲刺中位数,更不用说长期每天的平均值了。

          1. 是的,自2008年以来一直准确无误。之前只是估算,但速度并不快。我曾在许多地方工作,但始终坚持根据开发复杂度估算故事点。

    14. 我为所有仍对终端感到恐惧的专业开发者感到遗憾。

      1. 它只是一个更糟糕的编写代码界面,没有人会害怕它。

    15. 我不在乎别人对 Cursor 的工作流程有什么看法,我永远不会安装基于 VS Code 的任何东西,它根本就无法启动。对我来说,这就足够了。

    16. 我最大的建议是,将其用于探索,而不是生成。它非常适合理解代码库和查看 git 历史记录。

      上下文是关键,因此拥有一个 CLAUDE.md 文件也非常有用;/init 命令可以为您创建一个。

      如果你打算用它来生成(编写代码),那么计划模式是必不可少的。按两次 shift-tab 键。

      最后,我主要使用 claude 4 sonnet 模型,但一定要告诉它“ultrathink”(使用这些词),这意味着它可以使用更多的思考令牌。

    17. 我每天使用Cursor大约六个月后才切换到CC,这个过程花了一段时间。TUI并不是我的首选。但他们的工具和提示让代码运行得更加流畅,自从几周前完全切换后,我的代码中出现严重错误的情况明显减少。IDE扩展也起到了帮助作用。

    18. 我认为您需要更明确地说明您的使用情况。我将 Claude Code 作为 Cursor 的插件使用,对我来说,它们的结合非常完美,味道极佳,且不油腻。您可以看到 VSCode / Cursor 中通常会显示的所有更改,但 Claude Code 命令行 UI 绝对比 Cursor 本机 UI 更好。在我看来,它们真的非常完美。

    19. 看起来我不是唯一一个这样的人。我看了 Claude Code 的评论,感觉自己好像中风了。我到底是哪里理解错了?

      整个东西看起来像是一个巨大的摩擦源。

      我经常使用 Cursor,它让我做任何事情都更快。我不确定 Claude Code 能给我带来什么好处。

    20. Cursor 和代码完成功能为我节省了很多时间。能够预测接下来的几行代码,感觉就像魔法一样。

      让代理完全设计/编写一个功能,感觉还是有些奇怪。我喜欢一切都是手写,即使我实际上只是用 Tab 键完成并稍作编辑。

    21. 到目前为止,我的感觉是,Cursor 更适合处理现有的庞大代码库,而 Claude 则更擅长规划和构建需要大量代码的新项目。

      这意味着,目前 Cursor 的使用频率更高。

    22. 我是一名拥有 25 年以上专业经验的软件开发人员,已经与编码代理合作了相当长一段时间,从 AutoGPT 开始,现在几乎每天 24 小时都在使用 Claude Code,通过 Task Master 协调,自动启动多层项目的新实例。

      你完全正确。其中很大一部分是充满炒作的网红(我估计在 YouTube 和论坛上看到的网红中,大约有 95% 属于这一类)。我认为大多数人并不隶属于 Anthropic 或任何供应商,他们只是想推销课程、电子书或一些“用 AI 致富”的计划。

      我欣赏 Claude Code 的地方:

      – 由于它是一个终端/CLI 工具,因此可以从 cron 作业或脚本中无头运行。这使其易于自动化。

      – 我欣赏可预测的定价模式。每月固定费用让我可以使用 Claude Sonnet 和 Opus 4,每次使用时间为 5 小时,每次使用都有自己的使用限制,新会话开始时会重置。每月有大约 50 次会话的公平使用政策,但我还没有达到这个限制。我故意每次只运行一个实例,因为我喜欢负责任地使用它,不像一些“氛围”影响者那样似乎将它推到极限。

      就是这样。尽管 Claude Code 是一款基于 CLI 的工具,但它提供的功能非常出色。

      尽管如此,我遇到过的编码代理都无法完全吸收大量不一致的旧代码库,尤其是那些经过多年积累、架构混杂的代码库。这种限制主要是由于上下文大小的限制,但我预计随着上下文窗口的扩大,这种情况会得到改善。

    23. 我讨厌终端操作,拒绝在终端中编写代码,但我仍然认为 Claude Code 的效果比 Cursor IDE 与 Sonnet 4 更好。这可能是因为它与 Opus 混合在一起(我从未真正使用过 Cursor),也可能是因为它的上下文窗口更大,或者它的代理过程有些不同。我不完全确定。但我觉得它更能够保持一致性,而且出现的问题更少。这可能还与使用 CLAUDE.md 有关,我认为它对确保我的项目始终遵循最佳实践帮助很大。

    24. 你必须承认,Anthropic 能够打造出一个明显更差的界面,却说服整个工程社区相信它更好。

      我还怀疑其中很多是付费的,或者只是死硬的终端用户。

    25. 我不是 vim 和 eMacs 用户,也不是终端用户。

      我的设置是 Claude Code + Cursor。Claude Code 是我完成大多数任务的得力助手。

      对于微小的快速更改,我使用自动模式下的 Cursor。

      对于架构咨询,我使用 Cursor 与 Grok 4 进行聊天。

      Claude Code 在功能方面比 Cursor 的 Claude 更胜一筹。而 Claude 本身作为编码工具,也比其他型号更胜一筹。

      总而言之:虽然我们都从事编码工作,但我们构建的是截然不同的东西,需要解决的问题也大不相同,因此,没有一种通用的设置能满足所有人的需求,这并不奇怪。

      1. 在Grok 4推出之前,您在建筑咨询中使用的是Gemini 2.5 Pro吗?

        1. 是的,2.5 Pro 和 O3。到目前为止,我对 Grok 4 在此方面的表现非常满意。它非常全面且准确。虽然我使用 Grok 4 的时间仅限于几天,但我已经给它提出了具有挑战性的问题,结果非常出色。

    26. 我使用 Intellij Idea,不想学习新的 IDE。Claude Code 是一个简单的 TUI,与 Vim 或 Emacs 不同。对我来说,这是一个更简单的解决方案。

    27. 我敢打赌,你不是没有利用自定义上下文文件,就是利用得非常差。

    28. 铁杆粉丝。我尝试过许多 Claude 模型。有些还可以。真的。令人惊讶的是,某些版本的 Sonnet 比 Opus 更好。所以最新版本并不总是最好的。模型有时是专门设计的(无论是否有意为之)。

      我认为人们只需要尝试很多种模型。我认为我们已经到了(或即将到达)这样一个阶段:某些模型与你和你的沟通(提示)风格更契合。

      但使用过很多种模型后… 我不得不说,Gemini 2.5 Pro 是我用过最好的模型。它价格昂贵,但确实有效。

      我仍在寻找一个好的本地模型,但要找到能与 Gemini 相媲美的本地模型还需要一段时间。我认为最终会找到的,但需要一些时间。

      我可能不会使用 Claude Code,但很高兴它对某些人有效。

    29. 我的看法:对 Claude Code 着迷的人,从一开始就不是真正的工程师。对他们来说,任何水平的生产力都是“非常令人印象深刻”的,会“取代工程工作”,因为他们从未真正理解软件工程师的工作,也不了解生产力规模的划分应该是什么。

      他们之所以更喜欢 Claude Code 而不是 Cursor,并不是因为他们喜欢终端窗口;相反,是因为 CC 更简单。Cursor 比较复杂,其界面向用户传达的信息是,最终你可能会接管控制权。当然,有经验的工程师希望掌控一切,与人工智能合作实现某些目标。但这些 CC 粉丝却不希望如此。UI 中所有额外的功能都让他们感到恐惧,因为如果他们必须使用这些功能,他们不知道该怎么做。

      正是这类人充斥着 /r/ClaudeAI 或 /r/Cursor,抱怨速率限制。如果你曾经使用过这些产品,你会很快意识到:在付费计划中,你唯一会如此迅速地触发速率限制的情况是,唯一输出的代码来自AI,且每天不停地运行八小时,使用的是最昂贵、最智能的模型。唯一这样做的人是那些没有自己的大脑来参与这个过程的人。大多数 CC/Cursor 用户不会达到速率限制,因为他们将 AI 作为工具来使用,而不是像直接下属一样来管理它。

  2. 对我来说,AI 最好的地方在于,当我感到懒惰时,我可以让 AI 来做。无论它给我带来的是黄金还是垃圾,都无所谓,因为我已经开始工作了。

    1. 这是大语言模型(LLMs)可以轻松解决的空白页问题。我无需面对重建复杂心理模型的艰巨任务,只需问机器:“嘿,我们正在做什么?这是什么东西?好吧,你试着做一下,给我看看。”突然之间,我就回到了工作状态,可以开始工作了。此外,橡胶鸭子法和将“ yak shaving ”(指为解决一个小问题而花费大量时间处理其他相关问题)提升到极致,也让这个工具对我非常有用。我还将各种数据源(Slack、Notion、Linear)与之连接,因此它对我来说也是一个任务管理和项目管理工具。

      1. 关于“白纸问题”,这被称为动力惰性。你可以通过训练自己同意“就做5分钟”来克服它,即使你真的、真的不想做。如果你在5分钟后仍然缺乏动力,那也没关系。但9次中有10次,一旦你开始了,保持动力会出奇地容易。这对去健身房或打扫房子也很有帮助,因为大语言模型(LLMs)无法在这方面提供帮助 🙂

        关于大语言模型(LLMs)的使用,老实说,这就是我喜欢使用大语言模型(LLMs)的方式。还有自动完成功能。

        它非常适合创建项目的鸟瞰图,因为项目非常模糊,尚不需要详细的细节。而且,凭借其随机性,它非常适合做花哨的自动完成功能。但大语言模型(LLMs)在处理复杂性和边缘案例方面仍然存在很多缺陷。我为那些必须审查开发人员的团队感到不安,他们兴高采烈地宣布,无论资历深浅,他们都利用大语言模型(LLMs)将产出提高了 5 倍。

        更令人担忧的是,大脑是一块肌肉。我们必须通过思考来锻炼它,这就是为什么解谜者在年老时仍能保持敏锐。你越是将编码(或创意写作)的思考外包给他人,你的能力就会越差,大脑也会越发萎缩。你已经可以在Claude Code中看到这种现象,当开发者遇到限制时会感到恐慌,因为他们可能不得不独自编码。

      2. 也许你的大脑犹豫不决是有原因的(例如能量不足),如果原因没有得到解决,那么使用大语言模型(LLMs)来推动它,将来可能会导致大脑崩溃。新冠疫情让我(非常明显地)意识到,我拖延很多事情的原因,其实是大脑因能量不足而保护自己,从而限制了大脑的功能。

        1. 我认为对我来说,犹豫不决的原因在于,要开始任务XYZ,第一步往往是某个与“真正”任务仅有微弱关联的极其枯燥的任务ABC。

          例如,前几天我需要在包含2300个钩子的文件中找到哪个钩子。AI在5秒内找到了钩子并展示了如何使用它。这完全是双赢——现在我有了钩子的名称,可以在30秒内阅读并验证是否符合需求。如果不符,我可以再次询问。这里完全没有风险。

    2. 是的,这确实有助于克服初始动力不足的问题。我发现这在一天结束时我感到疲惫时也非常有用。我可以让它分阶段完成工作,然后审查/修复输出结果。这样对我来说压力更小。

    3. 我也有过类似想法,但最近的一次经历让我损失了大量时间:我因为懒惰让AI为我编写了一些代码。代码看起来不错且能编译通过,于是我提交并推送了它。几周后,我遇到了一次无法定位的崩溃。经过数小时的调试,我最终意识到罪魁祸首是几周前AI生成的那段代码;它以一种非预期方式调用了我代码中定义的函数,导致有时发生 panic,有时出现奇怪的偏移量错误。那个有问题的函数只有几行代码。如果我当时不偷懒,花10分钟亲自写出来,就能省去整个下午的烦人调试。

      教训:对AI偷懒是有隐性成本的。

      1. 这是对AI的懒惰,还是对代码审查的懒惰?这与草率通过同事的代码没什么区别。

    4. 到了最后,当我修改或回滚的代码量与编写的新代码相当时,我可以让Jesus暂时接管,让思维得到休息。

      对于小问题,通常只需快速查看差异,对于更复杂的问题,一旦开始成形,只要是局部编辑且我理解问题所在,引导它走向正确方向并不困难。我通常会在代码完成40-60%时接手,这仅因它能很好地遵循待办事项列表。

      我已经建立了一个良好的日常工作流程,强调在精力充沛的时段(如早晨)专注于自己的创作,同时让AI承担加班和繁重的工作,而我则准备明天的任务或进行更深入的写作和设计。

      1. 很高兴找到另一个拥有这种工作流程的人。

        我大概有70%的活跃编码时间用于编码。其余时间,我使用大语言模型(LLMs)来继续推进工作,同时让大脑休息一下,补充能量,更多地监督正在发生的事情,然后在必要时或在我重新开始关注工作之前(大约需要 10-15 分钟)接手工作。

    5. 即使我想自己做,也会要求它写一个计划,并将其放入一个标记文件中。

      今天它给我了一个糟糕的计划。基本上,我让它重构一个由大约40个文件组成的原型代码块。它走错了方向,试图从底层开始拆解,而不是确保100%向后兼容。如果它犯了错误,我们可能需要花很长时间来调试。

      但它确实给了我一个可以解决的问题。而且计划在1小时内就修复了。如果我尝试自己制定计划,可能会被复杂性吓倒,或者在文档编写中陷入循环。

    6. 我使用AI将我的想法转化为实际文字(不仅用于软件开发,也用于业余写作)取得了巨大成功。弥合词汇差距。

    7. 我出去散步喝咖啡。这样感觉更诚实。解决人类问题最好用人类的解决方案。

      1. 最好的部分是你可以两者兼顾。给代理一个提示,出去散步,回来看看它做得如何。

      2. 散步、小睡、远离电脑是编程的超能力。千万别认为这是件坏事。

      3. 不诚实之处何在?

        当我本人没有心情时,让AI先启动思路,往往是取得进展的好方法。

        1. 当你谈到进步时,我不禁想知道这要付出什么代价。独立思考的机制并未被充分利用,而解决问题并从中获得满足感的过程也未发生。这导致了错误的激励信号。大脑天生懒惰,倾向于走捷径。最终,你只是成了一个机器操作员,而这正是我许多同事正在做的事情。这非常令人担忧。

          只要求解决方案的偏颇行为既贬低了你的价值,又导致任何创新成果在尚未出现之前就消失了。

          我最终成为公司的创意人,不是因为我能力出众,而是因为其他人都不再思考了。

          1. 我同意你们两人的观点。我觉得大语言模型(LLM)既扼杀了拖延症,也扼杀了原创思维的能力。

            但是!有些问题对我来说本质上很有趣,而有些问题则非常无聊,但需要解决。

            在 20 年的工作中,我从未想出任何方法来使那些无聊的任务在心理上不那么令人讨厌,甚至接近痛苦。

            但现在,大语言模型(LLM)可以做那些无聊的事情,我终于可以专注于有趣的部分了。

            所以,无聊的任务——交给大语言模型(LLM)去做吧——有趣的任务——都是我的,都是我的!

            1. 我把大语言模型(LLMs)当作对话伙伴,但从不让它为我编写代码,这让我感觉自己得到了好的部分,而没有坏的部分。

            2. > 因此,无聊的任务——交给大语言模型(LLM)去做吧——有趣的任务——留给我自己做!

              没错!而且,查看机器如何解决无聊的事情本身仍然是一个有趣的来源,因此,多巴胺挤压的新鲜感会持续一整天。

          2. 我喜欢这样一个想法:在人工智能出现之前,我编程时并非只是“机器操作员”

            1. 我在将代码提交给机器之前,大部分编程和思考都是在纸上完成的。今天我仍然这样做。

              1. 什么是利基?

                我从事控制系统开发,要求系统首次运行就必须成功。在对工厂进行全面测试后,我就离开,再也不会回来。

              2. 我唯一一次在纸上编写程序是在10岁时,也就是11岁生日几个月前,那时我得到了第一台电脑。那是在20世纪70年代末。

              3. 但为什么你要使用计算机呢?这不是在自欺欺人吗?

                1. 为了快速、确定性地处理信息和沟通?

                  它们并不是万能的解决方案。思考就是其中之一。

          3. 我同意,这确实存在风险。我们需要找到一个平衡点,让AI成为强大的工具,而非黑箱。

            对我来说,最佳应用场景是当我已知解决方案及其应有的形态,但不想亲手编写全部代码时。AI可以让代码自动生成,而我可以验证其是否符合规格。

          4. 如果你审查了一些糟糕的代码,并当场想出了更好的方法,这是原创思想吗?

            如果作者是大语言模型(LLM)而不是其他人,答案会改变吗?

            你为什么不从高高在上的位置上走下来呢?

        1. 人们付钱给我做高质量的工作,而不是看起来很忙。思考是在开始之前进行的。

          1. 人们很可能付钱给你做有价值的工作,而不是高质量的工作。两者并不一定相关。

            如果你的同事能比你更快地进入状态(无论出于什么原因),你将继续做高质量的工作,而不是看起来很忙,而且不再为此获得报酬。

            1. 看看我的薪水,过去15年在不同公司工作时,我的薪水至少是同事的两倍,因为我提供高质量的解决方案,公司似乎认为质量是非常有价值的。

            2. 质量就是价值所在。因为低质量会带来财务风险。

              如今要找到能做高质量工作的人可不容易。

              这是一个不错的细分市场。

                1. 不只是我一个人。我们互相监督。

                2. 不,你不懂,这个人以一种智力上诚实的方式编写高质量代码,因为他们以一种非常特定的方式使用机器,恰到好处但不过度。其他人只是在胡乱编写代码。祝你好运找到一个和你从未听说过的随机在线人一样好的人!

                  我并非有意攻击此人,但这种心态在我们的行业中实在太过普遍——我以正确的方式做事,我写出优质代码,而很少有人能写出优质代码,因为我沿用5年、10年甚至25年前的做法,这意味着我的方式比你更好。

  3. Claude代码很难描述。我开始使用它时,感觉就像换了工作一样。我一直把 Claude 作为工作流程工具,但这简直就是类固醇。

    如果你还没试过,我强烈推荐。这是我第一次真正感觉像是在和一名初级工程师合作。

    1. 奇怪的是,我的经历恰恰相反:做某件事需要花几分钟时间,然后我进入程序进行一段时间的调试,因为应用程序已经变得一团糟,最后我意识到整个过程都是错误的,于是把一切都扔掉了。

      我经常使用 Claude,因为如果它像大家说的那样对我有效,那真是太棒了。

      但最好的情况是,经过一些手动调试后,它能完成一些模板代码,最坏的情况是,我花了一个小时和一些代币在完全死胡同上。

      1. 我发现了一些非常有效的建议:让它保持一个简洁的日志,记录项目开发过程中遇到的问题和障碍,以及为了解决或绕过这些问题所采取的措施。至于避免因杂乱无章的改动而导致代码库膨胀,拥有一个整洁的架构和良好的关注点分离有助于引导它走向可行的解决方案,但你需要主动引导它。对于那些更喜欢解决问题而非实际实现的人来说,这非常有趣。

        1. 为了继续这个项目,我不会让 Claude 或任何代理实际创建项目结构,我会引导它进入自定义系统提示。然后在每个文件夹中,继续对资产应如何编码、常见行为、库等进行具体提示。

          1. 所以你又发明了写出完整的业务逻辑规范。

            顺便说一句,我并不是在贬低它。我个人认为,通过大量繁琐的文档进行前期设计实际上是一种很好的开发方式。因为你只能提前做好设计,或者通过数年无休止的迭代来完成。

            1. 是的,我使用 Claude Code 的经验是,我实际上对设计更加认真了。使用一段时间后,你会对它的局限性有很好的了解,以及如何分解问题并详细说明以克服这些局限性。

            2. 瀑布模型的問題不在於完整的業務規格,而在於人們只寫一次規格,卻在現實反饋時不進行修訂。

        2. 对于那些喜欢解决问题而不是实际实施的人来说,这非常有趣。

          那么,Claude 只是你用来娱乐的东西吗?你会把它用于工作吗?

        1. 等你做完这些,还不如直接手写代码呢。

          1. 这实际上只是规模的问题。

            是的,我会自己写 4 行 bash 脚本。

            但如果你用 200 行全面的 claude.md 文档来交换一个可能有 2 万行代码的模块,那情况就不同了。

            1. 你愿意为这2万行代码负责吗?比如,当你提交给他人时,你能说“这是我的作品,质量达到我认为可接受的水平”吗?

            2. 你怎么确定这2万行代码没有明显的漏洞,或者你自己能发现的漏洞,或者你能在某个时候完全理解它?

              1. 你怎么知道你自己手写的2万行代码没有漏洞,或者同事写的2万行代码没有漏洞?

                1. 我不是你回复的对象,但我对自己的2万行代码比对AI更有信心。我已经培养了编写高效、易读、功能齐全、易于维护的代码的技能。我慢慢积累这些技能,并在编写代码时就能预见可能出现的错误。我并非完美无缺,但当错误确实出现时,由于我参与了代码的编写过程,我大致知道该从哪里着手查找并修复问题。

                  至于同事,我真的会尽量让他们以小于2万行代码的模块进行开发。但到了一定程度,你會期望同事對自己負責的領域負責。如果他們的代碼中有錯誤,他們應該修復它。如果AI的代碼中有錯誤,應該修復它….

              2. 我這樣做的方式是繼續編寫測試。

                1. 测试能让你理解自己未参与编写的代码库吗?

                  1. 这种理解代码的渴望很快会被视为有些过时。重要的是你理解自己的测试。让AI生成代码。

                    规格和测试是你的人类贡献。

                    1. 我理解你的观点,但我认为它过于“乐观”,也就是说,这种情况短期内不会发生,至少在人工智能极端主义者之外不会发生。

                    2. 如果测试用例编写得足够详细,以至于无需查看代码,那么代码的实现只是整体工作的一小部分,因此在整体生产力方面几乎没有提升。

                    3. 你描述的是 TDD,但它从未成为承诺中的灵丹妙药。我非常兴奋地想要尝试 claude 代码,我甚至为此准备了一个不错的个人项目,但总会有某个人需要理解代码,因为测试永远不会 100% 详尽,而且会出现重大缺陷。

                    4. 是的,我迫不及待地想告诉我的审计师/监管机构:“我不理解代码,因为它是 Claude 写的,但没关系,因为理解代码是婴儿潮一代的事情。”这会在证词中引起一片哄堂大笑。

                    5. 这显然也是不合时宜的。你的测试会受到审计。

                  2. 我认为是的。

                    要让测试有用,你必须编写函数的API,并提供如何连接各种构造的示例,以及正确的输入/输出对。

                    通过测试的函数实现现在有显著的约束,这意味着你对它有深入的理解。

                  3. 这被称为测试驱动开发。

                    首先,你编写测试,然后编写代码,直到测试通过。

                  4. 可以。特别是如果你用它们来验证你对代码的假设。

          2. 你不用手动做。你让 claude 先做一次,然后引导它回到正轨,提醒它下次不要再做。

            1. 当然,如果只是为了好玩而折腾。

              这些很酷,但生产系统要复杂得多。

              1. 你如何定义生产系统?你知道可以生成TLA+规范,然后从这些规范中进行代码生成,并断言实现与TLA+规范一致吗?

      2. 唉。正如其他人所评论的那样,在过去的 6 个月里,我们一次又一次地在 HN 上看到类似的讨论:“Claude Code [或其他什么] 太棒了”,以及类似“对我来说不起作用,只会给我的代码库带来一堆垃圾”的回复。

        我理解双方的经历,我自己也经历过。但我认为我们已经到了这样一个地步:此类帖子(无论是正面还是负面)都是_完全无用_的,除非它们附带对以下内容的仔细总结:

        * 你正在处理的代码库类型(语言、技术栈、业务领域、规模、年龄、整洁程度、贡献者数量)

        * 你到底想做什么

        * 你对 AI 工具有多深的了解

        * 你的工具是否能够从更改中获得反馈循环,例如通过运行测试

        * 你给它提供了多少提示;你的代码库中是否有 CLAUDE.me 文件

        等等。

        如其他人指出的,TFA 在这些方面也缺乏具体性。

        作为行业,我们仍在学习如何最佳使用这些工具。是的,我们知道它们对某些人非常有效,而其他人则有糟糕的体验。让我们尝试将讨论提升到更高层次!

        1. 你从描述负面体验的评论中提出这些细节,却对充满赞誉和夸张的顶部评论不加质疑,这颇具意味。我们应该要么对双方都提出这些要求,要么对双方都不要求。仅仅因为你的体验与一方一致,并不意味着与你的体验不同的经历就需要更严格的审查。

          我认为,接受人们描述自己的经历,而不要求提供大量证据来支持,会更具建设性。我们对其他观点都不这样做,为什么在这个案例中就很重要呢?

          > 让我们试着将讨论提升到更高层次!

          在论坛上,用轶事证据分享经历占据了大部分讨论。也许不要试图监管它,而是选择参与其中,或继续前进。

          1. >让我们对双方都提出要求,或者对双方都不提出要求。仅仅因为你的经历与一方相吻合,并不意味着与你的经历不同的经历就需要更严格的审查。

            某种程度上来说是这样。

            对大语言模型(LLM)/人工智能解决方案提供的途径感到满意并赞不绝口的人正在创建能够满足他们要求的代码库,无论这些要求是什么。

            对它感到不满的人通常会提出两种普遍的抱怨,要么是“它产生垃圾”,要么是“我用它会变慢”。

            也许我这里暴露了年龄,但我记得人们对搜索引擎的赞扬或贬低时,也曾有过同样的讨论。当时的替代方案是互联网黄页(这在很长一段时间内都存在)。

            赞扬它的人通常是那些被教导或自行摸索出如何使用元数据标签(如date:/onsite:)的人,而贬低它的人则往往是那些会搜索“谁赢了比赛”之类的问题,然后点击地球上每一个诈骗/色情链接,最后在被暴露于点击的内容时责怪谷歌/GDG/Lycos/等等的人。

            换句话说:事实胜于雄辩。

            我也不会关心那些上周才开始学习一门语言、却完全無視该语言语法和语法规则的用户编译日志——但对成功开发者而言,分享他们的好坏经验是有用的。

            我更关心那些了解游戏规则的人的意见——让这些软件背后的实际团队来处理那些不想学习惯例的用户的测试和反馈。

            1. > 对大语言模型(LLM)/人工智能解决方案提供的途径感到满意并赞不绝口的人正在创建满足他们要求的代码库,无论这些要求是什么。

              啊,但“无论这些需求是什么”才是关键所在。

              我并不完全反对你的观点。总会有部分高级用户能够利用对这些工具的了解,从中提取比普通用户更多的价值。这一点对任何工具都适用,不仅仅是软件。

              你忽略了另外两种可能性:

              1. 用户的期望可能截然不同。从未编程过但现在能够创建和发布智能手机应用程序的人会认为这些工具非常神奇。无论他们遇到什么问题,要么不会被注意到,要么从大局来看并不重要。他们对人工智能工具的印象肯定非常积极。他们可能是使用大语言模型(LLMs)的专家,但不是编程专家。

              另一方面,那些从事编程工作数十年,并追求一定质量水平的人,会发现体验截然不同。他们能够看到这些工具的缺陷和局限性,而解决这些问题需要花费时间和精力,而这些时间和精力本可以花在其他地方。自大语言模型(LLMs)推出以来,我们都知道,只有领域专家才能体验到这些问题。

              因此,双方的体验均具有合理性,应在讨论中获得同等重视。与您不同,我更倾向于信任领域专家的意见而非用户专家的意见,但这只是个人偏好。

              1. AI工具确实存在实际缺陷与局限性。认为所有负面体验均源于用户“操作不当”,而所有正面体验均来自专家用户的假设是错误的。这种假设会将讨论引离本应探讨和解决的技术问题。鉴于当前行业正被炒作和营销强烈推动,我们需要基于现实的讨论来抵消这种趋势。
              1. > 认为所有负面体验都源于用户“操作不当”,而所有正面体验都来自专家用户的假设是错误的。

                我不确定这一点。我觉得有经验的人会意识到什么时候使用大语言模型(LLM)比自己动手更好,什么时候只需要动手做。

                你可能在必须动手做一切的工作环境中工作,但你的反应会是你能看到它对其他人有多大的用处。

            2. > 那些赞扬它的人通常是那些被教导或自行摸索出如何使用元数据标签(如date:/onsite:)的人,而那些贬低它的人则倾向于搜索诸如“谁赢了比赛”之类的问题,然后点击地球上每一个诈骗/色情链接,最后在被暴露于点击的内容时责怪Google/gdg/Lycos/等等。

              这里有一个重要的警告:只有当你可以搜索“谁赢得了比赛”,而搜索引擎实际上将正确的结果作为搜索结果的首位显示出来时,搜索引擎才真正变得有用。

              现在,我们已经走过了超过 25 年的时间,但可能有 99.99% 的用户仍然不知道谷歌的高级搜索运算符。

              这对大语言模型(LLMs)来说应该是一个重要的警告。人就是人,会做人的事情。

          2. 我应该说得更清楚一些——我也希望看到来自正面评论的这类信息。它们同样重要。如果有人在用Claude Code对一个玩具应用进行视频编码时取得了成功,我不在乎。如果他们在大型遗留代码库上使用它取得了成功,我希望他们能写一篇博客文章详细介绍他们的做法,因为这非常有价值。

            1. 我在评论中有点操之过急,因为你确实提到希望看到双方的反馈。所以这点很清楚,我为此道歉。

              问题是,我经常只看到对负面体验的评论有此类回应,而正面反馈则被视为既定事实。你可以在这里的评论中看到这种现象的强化。评论区不是展开这些细节的合适场所,但我同意博客文章应该包含这些内容,无论体验类型如何。

          3. 他们没有在负面体验中具体提及这一点,而你自己补充了这一点

            1. 这是他们回复的评论。如果这是对代理工具,特别是 Claude Code 的讨论现状的一般性批评,为什么不把它作为顶级评论呢?

              1. 哦,因为我想说明,GP 评论(模糊且积极)和父评论(模糊且消极)就是这种讨论的典型例子。因此,我回复了消极的父评论。

          4. >但我认为我们已经到了这样一个地步,即此类帖子(无论是积极还是消极的)都是_完全无用的_,除非它们附带对以下内容的仔细总结:

            他们确实提到了“(无论是积极还是消极的)”,我没有将他们的评论视为仅针对AI消极评论的一边倒。

          5. 它们是工具。对于熟练的工具使用者来说,负面轶事听起来像:

            “我更喜欢打字机而不是文字处理器,因为更容易纠正错误。”

            “我没有叉子,因为刀子切面包更好。”

            “bidets会弄湿我的裤子,所以我还是用卫生纸。”

            我认为有必要纠正误信息。而如果有人热爱Excel并认为Excel比Java更适合开发应用程序,我没有纠正的冲动。也许他们对Excel的了解比我更深入。

        2. 这种表述方式存在问题。我发现这些前提差异隐藏在对话之下:

          – 有些人认为大语言模型(LLMs)将是一个赢家通吃的市场,并会加剧经济和政治力量的分化。

          – 有些人认为大语言模型(LLMs)没有进化的道路,因此已经达到顶峰,而且太低,无法维持这些计算投资,这意味着它只是昙花一现,最终会崩溃。

          – 有些人认为大语言模型(LLMs)将永远托管在远程服务中,因为硬件要求始终非常高。

          – 有些人认为,大语言模型(LLMs)会带来新的、更严重的危害,而无法通过创造新的防御手段来充分抵消这些危害。

          – 有些人认为,大语言模型(LLMs)和人工智能只会给低技能的人带来中等技能的结果,因此会削弱中端价值,而不会为高技能的人创造新的高端价值,从而对高技能的人产生不利影响。

          我们需要更加意识到我们如何框架这场讨论,因为并非所有人都认同这些基本前提。这些前提对依赖于它们的观点有非常强烈的影响。当我们不讨论这些要点,而是仅根据结论是否强化我们的前提来判断和回应时,讨论就会变得更加政治化。

          确认偏误是存在的。个人利益也是存在的。一些结果,如监管和就业中断,取决于我们的一般信念。人们知道这一点,因此开始根据自己的利益回复和投票,以说服他人支持他们的立场,而无需尊重真相。如果他们对前提的理解是错误的,这可能会对个人产生反效果,因为他们最终推动的议程可能根本不会真正受益于他们。

          我们无法阻止人们在每一次对话中都推进他们选择的立场,但那些真正关心对话真相的人可以花些时间考虑论点的根基,提醒自己去探索并将其揭示出来。

        3. 有道理。

          就背景而言,我是在 Ruby + Typescript 大型开源代码库上使用 Claude Code 的。5000 多万个令牌。它们有规格和 e2e 测试,所以当我完成一个功能时,我确实得到了反馈——我可以运行规格,Claude Code 可以形成一个循环。我通常会建议它一个一个地修复规格。–fail-fast 以快速找到错误。

          在使用 Claude Code 之前,我已经使用 Cursor 大约一年了。

          Sonnet 在 NextJS 和 Typescript 方面特别擅长。我还把它应用到一个中等规模的 Python 代码库和一些与机器学习相关的工作上(从 langchain 到 Pytorch,哈哈)。

          我不会做太多提示,只是足够清楚地描述我的问题。我尽力识别相关上下文或引导模型快速找到它。

          我创建了新的 claude.md 文件。

          1. 我在 Home Assistant 上花了不少时间调试。我对该平台和 LLM 的体验可以用“太棒了”来概括。

            我还用 Golang 做了相当多的数据整理工作。我在那里的大语言模型(LLM)体验是“参差不齐”的。

            然后,我处理了相当多的“边缘”代码库和问题空间。在那里,大语言模型(LLM)在固定模式之外就失灵了。

            “我在建筑行业工作,使用锤子”可能意味着木工、屋顶工或用大锤砸碎混凝土。我怀疑“我是开发者,我写代码”的情况也类似,这些细节决定了使用体验。

            仅从 Ruby 和 TypeScript 的使用量,以及这些平台输出结果的重叠程度来看,你的使用体验应该不错。我很好奇,如果你选择使用更小众的语言(比如 Zig)并进行非主流开发,是否会得到与现在相同的感受和反馈。根据我自己的经验,我猜你不会。

            1. 说到“边缘”的观察:这可能会越来越成为一个因素,我们称之为LLMO(优化),其中“大语言模型(LLM)友好”的内容将被推到前面。因此,我预计次要或边缘的编程语言将被进一步边缘化,因为大语言模型(LLM)将不再那么有用。

              这显然令人遗憾。尤其是因为最大的赢家是JavaScript,一种在编程语言中仍处于次要地位的语言。

        4. 以下是一些一般性的观察结果。

          你的大语言模型(LLM)没有整个代码库的上下文,因此它可以运行并做出更改,而不会考虑代码库的某些偏远区域(微妙地)依赖于克劳德刚刚更改的部分。根据语言和测试情况,这种情况可以在一定程度上得到缓解。

          大语言模型(LLM) (CC) 可能会识别出代码库中的错误,修复它,然后认为“好吧,我的工作已经完成了”,而没有考虑后果或在其他地方可能会发现类似的错误。

          我还可以继续说下去,但我的观点只是验证人们会遇到的问题,同时承认那些看到 CC 这样的大语言模型(LLM) 价值的人。它确实提供了有用的工作(例如,大型繁琐的重构、原型设计、追踪各种错误等)。

          1. 没错,这就是为什么拥有一个全面的测试套件对于这类技术而言如此重要。

            如果你的测试做得很好,Claude Code 可以运行它们,并使用它们来检查它是否破坏了任何远距离的现有行为。

            1. 情况并非总是如此。它只会“修复”测试以通过测试,而不是修复核心问题。

              1. 以前这种情况经常发生。根据我的经验,最近的 Claude(3.7、4)不太可能会这样做。

                如果它们确实这样做了,我们就要告诉它们撤销操作,并正确修复问题。

          2. 这就是为什么你要不断更新 CLAUDE.md,因为它会记录项目的相关信息,包括文件的位置等。

            这样,它就不需要搜索(或 rg)整个代码库了。

            你还可以使用计划模式来找出问题,将实施计划写入 .md 文件。清除上下文,进入行动模式,并告诉它按照计划进行。

          3. 可能可以给 Claude 访问 ast-grep 等工具的权限。这将有助于它查看所有引用。我仍然认为一些动态引用可能仍然存在。唯一的方法是提示得足够好。由于我在 Ruby on Rails 代码库上测试了这一点,我处理了这个问题。

        5. 我并不认为“我们知道它们对某些人来说效果很好”。到目前为止,我只看到人们对潜力感到非常兴奋,并对它所能做的事情印象深刻,但我认为人们在过度推测。就像,是的,它能用几个提示生成一款视频游戏确实令人印象深刻,但这并不意味着多几个提示就能让它变成一款AAA级游戏。

          我支持一些有限的AI自动完成功能,但到目前为止,这些代理对我来说似乎只是噱头。

          1. 如果我们假设热门游戏Wordle(为其作者赚取了大量收入)可以被生成,那么在什么情况下,这种花哨的功能会变成人们愿意付费购买的实际功能?

            1. 对Wordle没有偏见,但你描述的听起来似乎对垃圾游戏行业有用,仅此而已。这并非人类文明的重大飞跃……

              不过我得公平地说,这确实能帮助研究人员完成一些一次性脚本,比如绘制数据或进行终端后端计算。但我不认为这会是颠覆性的变革,更多是效率提升,且提升幅度有限。

              1. 人类的伟大飞跃会是什么样子?当然,让开发低质量软件变得更容易意味着会产生更多低质量软件,但这有什么不好呢?如果客户面临一个非常具体的问题,而这个问题原本因为定制解决方案成本过高而无法解决,现在他们却能获得量身定制的软件来解决问题,除了对这款假设中的软件进行道德评判外,这有什么不好呢?

                1. 以下是一个巨大的飞跃可能是什么样的版本,但这只是众多版本中的一个:一个大语言模型(LLM)能够理解它运行的 CPU,并将提示转换为汇编语言,充分利用硬件。或者,它可以针对像 Java 这样的虚拟 CPU,但关键是,如果大语言模型(LLM) 能够编写代码,为什么还要用 Python 或 C 语言呢?只需让它理解 CPU,然后让它发挥作用即可。我们之所以使用 C/Python 等语言,唯一的原因是汇编语言对人类来说太难了。

                  至于“铲子软件”,如果它对人们有益,那当然很好,我认为净收益很可能为正,但仅略微正向。称其为“铲子软件”的目的是暗示其质量较低,因此可能存在漏洞和其他性能问题,这些问题会增加使用成本,从而抵消其带来的好处(可能在净收益上为正,但很可能不像Docker那样具有根本性的变革性)。

        6. 同意。这越来越接近“我对互联网有过不好的体验……”

        7. 我发现,我对 GPT 家族的体验(大多)不错,而对 Claude 家族的体验(大多)不好。

          我只希望我能弄清楚这说明了什么。他们的训练数据不可能有那么大的差异。我给他们提供的问题是一样的。许多人认为 Claude 比 GPT 更强大。

          这肯定是我提出问题的方式的问题,对吗?还有其他什么变量呢?

          1. 如果你使用 GPT 有一段时间了,它可能更了解你。

        8. 赞同,每次出现“<模型>对我来说没用”的反馈时,都应附上问题摘要、代码库及所用编程语言的描述。

        9. > 但我认为,除非这些帖子(无论是积极的还是消极的)附有至少以下内容的仔细摘要,否则它们已经完全失去了意义。

          我每天都会多次使用 Claude,几乎每天都会要求它和 Gemini 生成代码。然而,我却属于“从未将大语言模型(LLM)生成的代码纳入提交代码”这一类。我没有确切的答案来解释为什么会这样。我能想到的唯一原因是,生成的代码缺乏撰写简洁、快速、清晰的解决方案所需的深度洞察力,这种解决方案在两年后仍能被他人轻松理解。

          或许最好的例子是有人自豪地宣称,他们在一周内提交了25k行代码,借助了AI的帮助。在我看来,这听起来就像是在宣称自己找到了将海水变成姜汁啤酒的方法。要掌握修改2.5万行高质量代码所需的深度知识,光是阅读就需要超过一周的时间。在一周内写出这么多代码纯属幻想。于是,我要求他们展示修改差异。

          令人惊讶的是,快速浏览修改差异后,我就能理解这些改动的内容。我大约花了15分钟就理解了其中大部分内容。这是好消息。

          坏消息是,这2.5万行代码向数据库添加了6个字段。其中2/3是单元测试,剩余部分的2/3可能是注释(可能更多)。这些注释在长度和精准度上堪称辉煌,还夹杂着ASCII艺术表格,展示了表格中的多行数据。

          注释尤其是一门微妙的艺术。它们很少被维护,因此在经过几次更改后,可能会变成令人困惑的废话。但它们提供的关于作者思路的洞察,特别是他心中设定的不变量,可以节省大量从代码中推断这些信息的 time。理想情况下,它们应简洁地解释那些无法直接从代码中看到的模糊部分。任何超出此范围的内容都将成为技术债务。

          引用伍德罗·威尔逊关于准备演讲所花费时间的言论:

              “这取决于演讲的长度,”总统回答道,“如果是十分钟的演讲,我需要两周时间准备;如果是半小时的演讲,我需要一周时间;如果我可以随意发言,则无需任何准备。我现在就可以开始。”
          

          这是一种委婉的说法,我怀疑大语言模型(LLM)生成的代码的有用性更多地取决于人类阅读它的频率,而不是你列出的任何因素。如果只需编写一次,且要求它在大多数情况下对大多数人有效,那么大语言模型(LLM)生成的代码可能是最佳选择。

          我最近使用了PayPal的KYC网页界面。界面设计非常漂亮,与PayPal其他部分的风格完全一致。但遗憾的是,由于存在漏洞,我无法完成操作。服务器拒绝接受某一页面,只是返回同一页面且没有错误提示。没关系,我多次致电客服(因为他们也无法绕过同一漏洞),经过4小时的电话沟通,问题最终解决。我相信这个错误会由新承包商修复。他花了几小时,让大语言模型(LLM)编写了一个新版本,然后像他的前任一样,将旧代码扔掉了。他会说大语言模型(LLM)大大提高了工作效率,PayPal也会很高兴,因为他的成本很低。这将是大语言模型(LLM)的理想应用——快速完成了工作,而且没有人会再阅读代码了。

          后来我发现页面上有一条链接,可以跳过问题页面,至少可以输入剩余信息。这条链接位于左侧一个看起来像“菜单栏”的区域,尽管菜单中的项目看起来可点击,但实际上没有视觉提示表明它们可点击。我还是点击了其中大部分,但它们毫无反应。在等待电话支持时,我开始阅读HTML代码,发现其中一个确实是链接。向客服人员承认自己没点击那个链接有点尴尬。它确实加快了流程。如我所说,该页面看起来非常美观,这可能部分归功于缺乏视觉提示来标明可点击元素所带来的简洁性。

          [0] https://quoteinvestigator.com/2012/04/28/shorter-letter/

        10. 有些任务可能会失败,有些则不会,但很多“Claude 代码[或其他什么]非常棒”的评论都会得到这样的回复:“对我来说不起作用,只会给我的代码库带来一堆垃圾。” 我认为这是“我知道如何使用它”与“我不知道如何使用它”之间的区别,还有“我有良好的测试覆盖率”与“测试?”之间的区别。

      3. 你可以让 Claude 验证其工作。我将其用于数据分析任务,并总是让它检查原始数据的准确性。当我开始这样做时,情况就完全不同了。

        明确的指示非常有用,要求它审查工作、要求它调试问题等,绝对有帮助。

        1. > 你可以让 Claude 验证其工作

          当然可以——但有一个相当重要的前提。只有当能够表达出清晰且可量化的验证标准时,这才有效。例如,我让 Claude Code 处理一个需要“刷新按钮”的简单 React 网站,然后就走了。当我回来时,按钮已经出现了,它使用了 MCP playwright + 屏幕截图来大致验证它是否正常工作。

          问题是,它决定“绘制”一个圆形的箭头刷新图标,而半圆末端的箭头朝向圆的重心。任何人(即使是外行)一看就会发现这看起来很荒谬,但即使我花时间手动粘贴了一个截图,询问它是否看到任何问题,Claude 仍然无法分辨。

          虽然也不合理地要求一名初级工程师手动编写刷新图标的SVG坐标——他们根本不会尝试这样做,因为他们会意识到从Lucide、Font Awesome、表情符号等现有资源中寻找图标要简单得多。

          1. 总的来说,使用自己的符号形式进行交互而非利用人们现有的认知模型是个糟糕的主意。除非你是足够专业的设计师,能够理解视觉符号的特定部分如何代表特定概念/动作,以及对谁有效,否则偏离已知库也是冒险的。从可用性角度而言,完全不使用符号比使用错误的符号要好得多。

        2. > 明确的指令非常重要,例如要求它审查工作、调试问题等,确实很有帮助。

          这就是我学到的教训。在21世纪初,我从三个昂贵的失败外包开发项目中吸取了教训。

        3. 我完全同意,并补充一点,你真的需要一种自动化的方式来实现这一点。对于编码而言,自动化的测试套件在发现低级错误方面非常有效。它能够理解失败测试中的错误信息,并基本上自行修复错误。

          但对于其他任务,如生成报告,我会让它编写小工具来根据模式定义重新格式化数据、执行计算或其他相对简单的操作,然后通过测试生成错误信息供其处理。让它“在脑海中做数学运算”只会招致灾难。但它可以轻松编写工具来正确完成这些任务。

      4. 对我来说,它在10分钟内解决了React 19的库兼容性问题,仅凭控制台错误信息和库名称的提示就完成了。

        如果我自己处理(从诊断到修复),至少需要半天时间。

      5. 这与您如何构建代码库密切相关;如果您的代码库中存在可重复的模式,使得规范显而易见,那么它在大部分情况下都会遵循这些规范。

        当代码库中出现一些临时解决方案时,我会利用这些来验证功能是否正确,然后提示进行重构以使其更好地遵循规范。

      6. 我见过成功和失败的案例。这确实很酷,我喜欢把它视为在遇到困难或困惑时的一种视角。

        当它生成大量无用垃圾时,我感到自由地丢弃它,并尝试再次使用更清晰的指南(或切换到Opus)。

      7. > 花几分钟时间做某件事

        生成的代码的质量与生成代码所需的时间成反比。如果你让 Claude Code 单独工作超过 300 秒,你会得到垃圾代码。把这当作一个提示,如果它不能在规定时间内完成任务,那就意味着你的要求太高了。将功能拆分,尝试更小的功能。

      8. > 我进去调试了一段时间,因为应用程序已经变得一团糟,最后意识到它整个过程都做错了,于是把所有东西都扔掉了。

        这似乎与我过去合作过的一些更早熟的初级工程师的经历一致。

      9. 是的,我的经历也差不多。而且——根据那位强烈推荐它的朋友的说法——我给它分配的任务是“完全在其能力范围之内”。既然我不认为自己被误导了,我怀疑是自己使用方法有误。但我真的想不通原因。现在我已经尝试了第三次了。

    2. 今天刚在公司拿到它,尽管使用了相同的基础模型,但与 Cursor 相比,它是一个巨大的飞跃。非常令人惊讶!一个月前,有一个任务,AI 辅助的作用非常负面。今天,我用 Claude Code 在 20 分钟左右完成了同样的事情。而且 API 使用费用不到 10 美元!

      而且,对上下文的照顾也少了很多。Claude Code 非常擅长找到所需的内容并将其添加到上下文中。我发现,在 3-5 分钟的任务时间范围内,Cursor 的代理模式不再有用,但 Claude Code 可以连续工作 10 分钟以上,并在不陷入循环的情况下取得有意义的进展。

      再次强调,考虑到我使用的是 sonnet 4 w/ cursor + 有时使用 Gemini 2.5 pro,这真是令人非常惊讶。Claude Code 在工具方面非常出色,不会陷入困境。

      1. 太棒了!如果你使用的是专业版,你可以使用大量 claude code,而无需支付 API 使用费。

      2. 尽管这是相同的模型,但 Cursor 会为每个请求添加一个巨大的系统提示。这太糟糕了,会破坏模型。在“地毯式拉人”之后,我在计费周期结束时或当 Cursor 切断我每月 60 美元的计划时(这可能会先发生),我会独家使用 Claude 代码——这大概是在我这个月的半途。

    3. > 这是我第一次真正感觉像是在与一名初级工程师一起工作。

      我对此有复杂的感受;因为这意味着实际上没有商业理由雇用初级工程师;但同时(我认为)这也威胁到高级职位的长期稳定性,尤其是当高级工程师逐渐失去他们的知识,让克劳德来处理事情时。结果基本上是:你是什么时候进入这个领域的?

      我实际上几乎害怕我需要开始学习 Leetcode、学习其他语言,然后申请国防部类的工作,因为 Claude Code(或其他代码安全问题)意味着他们需要真正诚实的程序员,而不需要帮助。

      然而,未来永远是未知的,没有什么事情是不可避免的。

      1. 这是一个不学习的初级工程师——他们即使在被纠正后,也会在上下文窗口之外再次犯同样的错误(甚至在“纠正”仍然存在的情况下……),他们难以将这些错误类别抽象化以避免未来犯类似错误,而且(从目前情况看)他们永远不会成为“资深工程师”。“招聘初级工程师”更应被视为一项投资,而非立即产出。

        我不断被告知$(WHATEVER MODEL)是“最伟大的事物”,但每次实际使用时,它们的实用性都有限(尽管确实不为零)。我能阅读的那些令人兴奋的博客或评论,与我亲眼所见的现实并不吻合。

        也许是行业问题?我主要从事系统/操作系统/驱动程序开发,使用C、C++和Rust等语言处理大型代码库。即使不考虑API文档,代码规模也远超普通文本窗口。即便作为“搜索与摘要”工具,我发现其错误率之高已使其功能上毫无价值——因为校对和验证输出所需的时间根本无法节省成本。但它们在“自动完成+”功能上还是很有用的——比如“这里有一个类似的现有代码块,现在用(更改)做同样的事情”。

        它们在处理非模板化代码时,通常表现得像一个模板引擎一样高效,因此诸如重命名、重构或识别类似结构等功能非常实用。我怀疑这或许也能解释那些令人兴奋的博客文章——我见过大量此类文章声称“任何非程序员都能在几秒钟内制作一个简单应用!” ——但你早就能够做到这一点,有成千上万个“简单应用教程”代码库可以满足你想要的任何许可证,复制一个,修改顶部的名称,你就已经完成了“哇,神奇的最终结果!”的99%。

      2. > 因为这意味着实际上没有商业理由去雇佣初级员工

        难道这些人不是你未来几年的前辈吗?建立人才流入和流出的模型是健康的。

        1. 当组织更倾向于通过生成式人工智能的初期生产力提升来节省成本,而非投资于人才发展时,人才管道就会枯竭。

      3. 我们正在使用概率生成器来输出本应是确定性解决方案的内容。

        1. 你知道还有什么也是概率性的吗?你和我。这就是为什么我们准备了工具来减轻这种影响,并将我们的可变输出限制为更可靠、更确定的结果。幸运的是,许多工具也可以用于概率机器。

      4. 国防部很快就会要求使用Mechahitler。

    4. 你能详细说明一下你使用它进行的任务、语言、领域等吗?

      人们的经历差异如此之大,我很好奇原因。

      1. 我觉得很有意思的是,这是一篇大约 2500 字的关于“使用 Claude Code”的文章,但他们从未解释过他们到底用它来做什么,他们正在编写什么类型的项目。这一切都太笼统了。我读了一些,然后意识到我刚刚读到的内容完全没有实质内容。

        这也让我越来越相信,如果作者在文章中插入表情包图片,那这篇文章可能不是我感兴趣的阅读内容。

        1. 我大概读到一半时就觉得“这篇文章完全没有信息量”,于是放弃了。

        2. 当人们不展示自己的工作时,这总是很有说服力的。我并不是说大语言模型(LLMs)不能做好工作,但如果你甚至不解释你使用的步骤,也不展示生成的或修复的代码,那么我只能假设真正产生的是一堆无法维护的、只是碰巧编译成功的意大利面代码。

          1. 我真的无法分享我的代码,因为那属于公司或客户。那我该展示什么?提示词?伪代码?除非你是开源开发者或在做个人项目,否则“展示你的代码,兄弟”这类要求很难满足。

            1. 没关系,但如果你不能展示代码,就不要写关于它的文章。模糊不清只会让文章看起来没有事实依据。

        3. 要时刻意识到,有很多人在那里,尤其是 HN/YC 圈子里的人,对大语言模型(LLM)工具有着巨大的既得利益。看看最近的 YC 批次,你很难找到一个没有以某种方式提及 AI 或大语言模型(LLMs)的。

      2. 它们总是 js 或 python 中的 POC 应用程序,或者其他流行语言中结构良好的非常小的库。在其他情况下,确实有一些方法可以让它们变得更好(自动化测试/验证/代码检查是一个重要的方面),但对于95%的开发者每天都在做的事情(在庞大而复杂的代码库中工作,这些属性都不适用),它们还远未达到理想状态。

        这些工具在擅长的领域确实表现出色。它们非常出色。但一旦尝试用它们进行更“严肃”的工作,它们就会迅速崩溃。

        我这么说,是因为我每天都在使用这些工具。对我来说,唯一合理的解释是,那些说“你不懂,它们在一切方面都出色”的人,根本没有在处理任何稍微复杂一点的项目。或者这是确认偏误,他们只记得好的结果——正如我们在上周关于这些工具对开源开发影响的研究中所见(感知生产力有所提升,实际生产力却下降)。除非我们看到相反的例子,否则我认为没必要过多思考这个问题。使用它们擅长的领域,不要用它们完成其他任务。

        大语言模型(LLMs)并不一定“全有或全无”。它们绝对不是万事通,但这并不意味着它们一无是处。

          1. 坏消息是,就我们所能看到的,性能翻倍通常也需要(至少)资源使用量翻倍,而且我们正在接近一个临界点,即地球资源已经不足以支撑大语言模型(LLM)资源翻倍了…

            1. 这个物种正在灭绝。当我的父亲在多次警告下仍不改变生活方式,最终去世时,我终于接受了这个事实。我的母亲经历了心脏病发作,看到了父亲的遭遇,但仍然没有改变她的生活方式。

        1. 嗯,我让 Claude Opus 用 Rust 为我制作了一个游戏。我认为它已经不再算作 POC 应用程序了。

          1. 在达到生产级、部署、被人们使用、长期维护等之前,它绝对算作 POC 应用程序。

            这并不意味着它没有用,或者你不应该对大语言模型(LLM)构建的东西感到满意。本周,我还让 Claude Code 用 Rust 为我构建了一个供个人使用的网络应用程序。对我来说,它非常有用。但它 100% 属于 POC/MVP 质量,而且永远都会如此,因为它创建的代码非常糟糕,如果不重写 50% 以上的代码,我永远无法将其扩展到现实世界中的服务中。

        2. > 它们很棒。但一旦你试图用它们做更“严肃”的工作,它们就会迅速崩溃。

          抱歉,但这根本不是事实。

          我正在使用基于Haskell + Bazel + Flutter的完全独特的代码库的代理。这是一个如此古怪和利基的堆栈,即使是谷歌也无法让它很好地工作,尽管他们拥有大量的开发人才和多年的软件工程师推动内部支持Haskell等技术。

          使用代理,我的生产力比其他方式高出100倍。

          我刚刚开始一个C++项目,但已经在不到一天的时间内完成了至少两周的工作。

          1. 我要问问之前在这里说自己“10-20倍”更高效的那个人:

            如果你真的那么高效,为什么不辞职去开发10个iOS应用(以你的情况来说,比例上应该是50到100个)

            1. 因为钱?即使你能快速开发出这些应用程序,但如果你无法销售它们,那也是毫无意义的。而 Claude 无法帮助你做到这一点。

          2. 等等。那么,拥有众多优等生工程师的谷歌无法让这个堆栈正常工作,但你的 AI 代理却能做到呢?认真点,告诉我方法,让我也能找到人工智能的启示。

          3. 分享你的代码库和你在做什么,否则,抱歉,你只是我上面提到的又一个例子。

            如果你真的认为“代理”让你比谷歌的软件工程师更好,那么你严重需要退后一步重新评估,因为你是错的。

            1. 我主要使用 gemini-cli,现在开始尝试使用 claude 代码。

              1. 你是指这些代理,还是指从这些代理的会话中分离出单独/多个代理?

      3. 当我在编码讨论中看到这些大语言模型(LLM)时,我会想起很多关于网上约会的讨论。有人会发帖说:“我真的很难约会。我尝试过 X(例如一个约会应用程序),但经历很糟糕。” 有人会回应“我尝试了X并取得了巨大成功。强烈推荐。”这似乎令人困惑,但当你点击查看他们的个人资料并看到每个人的照片时,为什么这些人会有不同的经历就变得一目了然了。

        不是要过分批评作者,但查看他们的GitHub个人资料可以看出他们参与的项目类型以及他们作为开发者的风格。在项目或代码输出方面并没有太多内容,但他们在 Twitter 上有 1.5 万名粉丝,经常向粉丝发布关于大语言模型(LLMs)的信息。

        他们并不谈论他们正在使用的任务和领域,因为这些只是附带的;他们真正想做的只是向他们的在线粉丝谈论大语言模型(LLMs),而不是发布代码。

      4. 我是 TALL 开发者,所以使用 Laravel、Livewire、Tailwind、Alpine。

        这很好,因为其中 3/4 都是广为人知但并非行业默认选择的工具,而它仍然处理得非常出色。

        有一个名为 Filament 的 Laravel CRM 构建器,使用起来非常有趣。Claude 做得非常出色。它包含大量模板和清晰的文档,因此 Claude 表现出色也是理所当然的。

        我欣赏的是,CC 作为代理能够一次完成很多工作。

        我也将CC连接到一个只读API,用于一个客户,我需要消费该API上的所有数据,以实现向Filament应用的过渡。Claude目前正在确定数据结构,将其复制到Laravel中,并将其中的API记录全部导入Laravel模型,所有这些操作都是自动完成的。它已经运行了10分钟,没有中断,我预计它将完美运行。

        我投入了大量精力进行提示准备。我的提示通常是一个功能大约 200 字,我会与大语言模型 (LLM) 反复沟通,以确保它认为足够清晰。

      5. 我认为AI是它能够抓取的所有代码的平均值。对于我擅长且每天都在处理的内容,它除了提供一些方便的代码补全功能外,帮助不大。对于我水平较低的内容,如Bash命令和JS,它能帮助我达到平均水平。对我来说最有价值的是,如果我能利用它来学习新知识——它会提供一些不错的替代方案和想法,尤其是对于主流内容。

      6. 我用 Claude 用 C++ 编写 Windows Win32(使用 MFC)时运气不太好。它总是发明一些消息和 API,看起来完全符合我的要求。

        我认为Win32开发应该是AI非常擅长的领域,因为它历史悠久、文档完善,且有大量代码可供参考。然而,它仍然难以区分Windows消息、控制通知消息和命令消息。

      7. 原因可能是复杂性和手头的任务。

        根据我的经验,大语言模型(LLMs)擅长小任务(bash 或 python 脚本);擅长简单的 CRUD 工作(js、ts、html、css、python);擅长原型设计;擅长文档编制;擅长编写单元测试;擅长在更复杂的数据库中添加简单功能;

        对于更复杂的任务,即使使用 Claude 4,我也觉得它几乎无法使用。更复杂的 C++ 代码库;更小众的库;ML、CV 以及需要推理的更偏数学领域的任务。

    5. 我也有过同样的经历,尽管我觉得 Claude 对我来说远不止是一个初学者。它提出选项、做出建议和说明取舍的能力简直难以置信。

    6. 除了 OP 文章之外,还有人能推荐一些使用指南,让我对使用 Claude 代码有同样的感受吗?我昨天启动它大约一个小时,尝试处理了几张票证,感觉完全是在浪费时间。它给出的答案完全错误——我的提示非常具体,它似乎也理解了正确的上下文,但完全没按照我的要求去做。

      例如,我要求它将组件中的所有“on change”处理程序修改为使用状态而非直接触发网络请求,然后为实际的网络请求添加“on blur”事件。它没有添加使用状态,而是添加了“on blur”事件,但这些事件发送的网络请求指向了错误的端点。真是奇怪。

    7. > 这是我第一次真正感觉像是在与一名初级工程师合作。

      与 Claude 合作,我感觉就像我的老板与我合作一样。“看,我做了件很棒的事情!”

      “但这不是我要求的……”

      1. 与初级工程师不同,当你要求重做时,它不会感到受伤。

    8. 当我最初使用 Claude Code 来记录一个旧代码库时,我非常喜欢它。维护该系统的开发人员审查了文档,并说它非常准确。

      但前几天,我要求它帮助另一个旧代码库添加边界日志记录功能,结果它生成了些糟糕的、重复且冗余的代码。我看到人们在社交媒体上分享这些巨大的 Claude 指令文件,我不禁怀疑……

      不知道他们是在节省“智能”还是性能变化很大。

    9. 我同意。我还建议大家阅读以下内容:https://docs.anthropic.com/en/docs/build-with-claude/prompt-…

      其中有一些内容真的让这个工具从普通工具提升到卓越工具的水平。例如,很多人不知道它能识别不同层次的推理,并根据你提出的问题分配更多的“思考令牌”(包括使用“ultrathink”来最大化思考预算)。

      我认为那些仍然得到大量垃圾输出的人,只是没有正确使用它。

      更不用说很多人为了节省成本,仍然使用Sonnet而不是Opus 4。

    10. > 这真的让我感觉像是在和一个初级工程师合作。

      我同意。这让我想起我曾经合作过的一位初级工程师,他写出的代码糟糕透顶,解释问题给他听所花的时间比我自己动手解决还要长,更不用说还要花额外时间审核他那些糟糕的PR了。我原本希望他能随着时间的推移有所进步,但他却将我的PR评论视为个人攻击,并拒绝继续与我合作。至少克劳德没有这种态度。

    11. hackernews 上一半的帖子都是关于编码代理有用还是无用的讨论,反复出现。

    12. 就像与一个非常有才华、知识渊博的初级工程师合作,但他仍然是一个初级工程师。

      如果你想尝试比 claude code 更好的东西,试试 Cline。

      1. 你能解释一下 Cline 到底好在哪里吗?

    13. 我发现 Cursor 比 Claude Code 好得多。运行 Claude Code 时,它需要执行许多命令和内部提示才能完成一件小事,而且消耗了我大量配额。而 Cursor 则非常快速,直奔主题。Claude Code 只是陷入了 grep 地狱。

    14. 我同意将它与类固醇进行比较,但我见过人们因类固醇而遭受健康问题,所以我们可能对这种比较有不同的理解。

    15. 在什么意义上,你没有做你多年来一直成功地做的工作,而是让克劳德为你做,然后你还要审查它?

    16. 你在做些有用的事情吗?除了你自己,还有谁能知道呢?

      我自己的实验只表明这项技术并不可靠。

    17. 我喜欢 Zed 编辑器,他们主要整合了 Claude,所以我可能会尝试一下。

    18. 随着等级的提升,感觉就像是在玩游戏一样!

    19. 等到蜜月期结束,你不得不面对自己不知不觉中往代码库里扔的垃圾时,就知道了。

    20. 你们怎么会对一个看起来像80年代的终端界面感到满意,这让我无法理解……

      如果 Claude 如此出色,Anthropic 难道不能在一周内制作出功能齐全且性能超强的 IDE 吗?

        1. 摆脱显示器的束缚吗?回到打孔卡时代吗?

  4. 现在肯定有很多使用 Claude Code 或类似工具编写代码,并用它们制作出真实应用程序或库的人,对吗?如果能提供一个列表就太好了,因为我想要阅读(或观看)的是这些内容,而不是人们不断告诉我这些东西很棒,却无法让我看到它们的棒。

    1. 整个事情感觉有些不对劲。我使用 Claude 代码。我喜欢它,它确实为我节省了阅读文档或查看堆栈溢出时间。这是一个非常棒的工具。

      如果我们要相信炒作的话,这些工具不应该将软件推向平流层吗?就像 Stripe 的 CEO 所说,AI 工具将生产力提高了 100 倍。那是3-4个月前的事了。既然从技术上讲,这相当于400个月的开发时间,Stripe现在不应该已经发射火箭进入太空了吗?据报道,微软全面投入AI编程。Teams现在不应该成为最稳定、最可靠的软件了吗?这些工具被炒作成超级加速器已经超过一年,但实际的软件格局在我看来与3-4年前相比并没有太大变化。

      1. 或许这些炒作并非针对开发者,尽管常常被包装成针对开发者的内容,而是旨在吸引投资者(如风投公司)。

      2. 无论它产出什么,都仍需仔细审查和指导。作为人类程序员,上下文切换非常困难,因此你需要专注于同一特定任务,这使得在等待过程中不切换到社交媒体或现实生活变得更加困难。而且你将处于同一分支处理同一工单,Git不允许同时处理多个(至少我未配置此功能)。我不确定生产力提升的来源,除了快速尝试糟糕的想法直到找到正确的一个,当然还有快速自动完成、更快的调试,以及更高级的全局查找/替换功能。

        我使用它相当积极,我估计平均只能提升1.5倍。

        这不会改变世界,因为我们大多在做无聊的工作,而且有无尽的待办事项。

        1. 我开始专注于API测试、Playwright测试和保持数据结构的稳定性。我无需关心这些测试之间的细节。这并非简单或极端的做法,但我直觉认为我们必须采用类似服务水平协议(SLA)的思维模式,让系统自行运行以满足这些需求。

      3. 尽管我们生活在一个被称为具有变革性头脑风暴和创意技术的时代,但我们也矛盾地生活在一个比以往任何时候都缺乏创造力和远见的时代。 🙂

        1. 你什么意思,你不喜欢这部老动画电影的第100部真人版翻拍吗?

      4. 也许这种差异是由于克劳德代码减少了大脑的思考量。如果你完成一项任务所需的思考量减少了 80%,但任务所需的时间却一样长,那么即使产出没有变化,你也会(甚至理所当然地)觉得自己的工作效率提高了五倍。

        这算好事吗?毕竟你(理论上)可以多任务处理并延长工作时间,还是坏事?因为你在积累认知债务(参见《你的大脑与ChatGPT》)?

        1. > 代码不是瓶颈。

          理解要解决的问题才是。

          1. 没错。代码是负债。理解它才是相应的资产。生成更多理解不足的代码,就像增加杠杆一样。

            或者:购买一辆超级跑车可能会让你的通勤感觉更快。但如果每个人都这样做,我们会面临更多的交通拥堵和污染。

      5. 我认为会。Claude 订阅服务于 5 月才推出。一家拥有大量代码库、旧代码、付费客户、SOC、GDPR 等的软件公司就像一艘大船,转动起来非常困难。我仍然认为,我们距离实现你描述的节奏仅有数月之遥

      6. 我猜大多数CEO更热衷于以更低成本提供同样糟糕的服务,而非打造更优质的产品。

        正如另一位评论者所言,这是为投资者而非开发者服务,更不用说那些低端用户了。

    2. 我最近看到两种趋势:1. 技能较低的人将其用于琐碎的项目。2. 开发人员将整个应用程序写入内存/上下文,包括文件名、接口、技术、准备测试、编译框架,然后手把手地指导大语言模型(LLM)最终得出可接受的解决方案。例如:https://www.youtube.com/watch?v=Y4_YYrIKLac

      你听到的关于大语言模型(LLMs)的信息中,80%(99%?)来自第一类人,并被网红们放大。

      我猜人们会感到生产力得到提升,是因为记录/与大语言模型(LLM)对话/指导/提示/纠正大语言模型(LLM)比自己实际做这项工作更省心,尽管花费的时间或总体努力是一样的。他们低估了为了从大语言模型(LLM)中获得可接受的结果而必须投入的工作量。

      1. 这是我的看法:我从事软件开发已有 25 年。我每天都在使用 Claude Code,觉得它非常有用。为了获得有用、高质量的结果,确实需要付出很多努力——特别是在代码审查方面,这是我最不喜欢的工作部分。不过,对于小型、专注或模板化程度较高的项目,它非常出色。此外,对我来说,编程中最有趣的部分是解决问题,而不是实际的实现,因此代理程序尚未消除这种乐趣。

      2. > 2. 开发人员将整个应用程序写入内存/上下文,包括文件名、接口、技术、准备测试、编译框架,然后手动操作大语言模型(LLM),最终得出可接受的解决方案。

        啊,石汤:https://en.wikipedia.org/wiki/Stone_Soup

      3. 我刚刚开发了一个具有一些复杂功能的移动应用程序。花了大约 120 个小时(GPS、视频处理、内存问题)。我以前从未开发过移动应用程序,考虑到所需的时间以及我目前生活中缺乏专注的时间,我认为自己没有技术能力来完成这些困难的部分。如果没有 Claude,我可能需要一千个小时才能完成。

    3. 100%同意,我一直在寻找YouTube视频或直播,展示有人利用AI提升生产力,但还没找到让我觉得“这确实能加快速度”的内容

      1. Zed编辑团队发布了一段关于使用其AI界面的视频,这让我印象深刻。我不记得他们使用了哪个模型,但他们让AI添加了一个新功能的切换开关,然后在视频中花了半段时间演示他们承认非常优秀的代码审查工作流程,用于接受或拒绝AI生成的代码。你可以直接看到AI生成的代码有多么无用,比如随机添加完全多余的新行,而解释是“它有时就是这样做”。

        我也不觉得我的工作流程有这么大的提升,也许这和我平时的工作性质有关,但看到YouTube上每个编程案例都这么浅显,真是让人费解。到目前为止,我已经放弃了,完全不使用它了。

        1. 我让“AI”做一件相对简单的事情——修复按钮的启用或禁用状态。结果它重新编写了整个200多行的文件,导致程序无法运行,完全报错了。干得漂亮,“AI”!

    4. 这听起来像是推卸责任,但坦白说,你在这里看到的可能是双方最激烈的声音,而绝大多数人只是默默地工作,做自己的事情(讽刺的是,我正在写这个)。

      我感觉自己像个推销员,但诚实地说,我在某些任务上的效率提升在1.5倍到10倍之间。主要好处是,我可以减少在以下任务上的认知负荷:1) 探索性任务 2) 一次性任务 3) 模板化/重构类任务。因此,我有了一个更一致的基准。

      我仍然手动编写代码。我仍然需要亲自审查几乎每一行代码,不会让它运行数小时后再尝试在最后进行审查(那将是一场噩梦)。这是一个运行多年的生产应用程序。我不会发布YouTube视频,因为我没有时间设置并试图反驳“怀疑者”(而且那甚至不重要),而且我无法分享该代码。

      这里需要说明的是,我们是一个非常精简的团队,所以我对整个系统有更多了解,能够早期识别问题并及时解决。此外,我对提高效率有个人利益,而如果你是公司的一员,你可能在做同样的工作却得到更少的报酬。

      1. > 这听起来像是在推卸责任

        这可能听起来比我本意更刻薄,但你的评论正是GP帖子中描述的那些无用却无处不在的典型例子。

        1. 我的意思是,我明白,但到了一定程度,你不得不假设所有人都在说谎,或者我们都是机器人之类的东西。这可能和我读到有人遇到困难时,第一反应是“他们没用对”的感觉一样。我敢肯定,反过来就是“他们不是真正的程序员”哈哈。

          1. 这其实简单得多。

            没有具体细节说明你采取的具体步骤,这些讨论只是空洞的热度。

            1. 如果没有你采取的具体步骤的具体细节,这些对话就只是空谈。明白吗?

              没有人愿意用自己真实的详细例子来展示这些编码大语言模型(LLMs)是如何失败的,人们也不愿意制作一些包含所有源代码的详细YouTube视频,因为归根结底,我并不想努力说服人们使用他们不想使用的工具。

              我认为,随着更多人通过这些评论摸索,情况可能会更好。Cloudflare的示例是一个不错的起点,我已经给你提供了大致的方法。我对这种敷衍了事的做法没意见,哈哈。

              1. > 没有具体细节说明你采取的具体步骤,这些讨论只是空谈。

                当然。

      2. > 我在某些任务上的效率提升了1.5倍到10倍

        根据你自己的估算。最近有一项研究显示,使用AI的高级开发人员认为自己快了20%,但客观上他们慢了20%。

        1. 他们可能花在编写代码上的时间减少了20%,但花在向AI解释需求和修复输出结果上的时间却增加了20%。人们在基础数学和时间管理方面并不擅长,即使是程序员也不例外。

        2. 我不会基于一项研究就做出广泛结论。尤其是当研究结果与许多人的自我报告相矛盾时。研究往往存在缺陷。

        3. 我的意思是,到了这个地步,我真的不知道该如何回应这类评论,基本上是在指责我撒谎,哈哈。我记录了持续输出和删除的行数、触发的文件以及每天推送的功能。你可以争论增长的程度,但它绝对不是慢了20% 耸肩

          这就是我所说的。最终,谁会在乎一项可能与我无关的研究,只要它确实有效。

          人们简直是口沫横飞地告诉那些发现它有用的人,他们是完全错误的或妄想的。如果你不喜欢它,那就继续你的生活,谢谢。

    5. 据我所知,Claude 中的大部分代码都是由它(或其他大型语言模型)编写的。

    6. 找到列表后请告诉我,我想看看。

    7. 几周前,我开始使用 Claude 代码(CC),并取得了一些非常积极的成果。为清楚起见,我自 1990 年以来一直从事 IT 领域的工作,我的背景主要是基础设施工程(现在是 DevOps)。我不是专业编码人员,只是根据需要编写工具来完成任务。尽管如此,我对端到端系统和中间部分还是相当了解的。

      以下是 Claude 帮助创建的一些项目:

      1. 使用Apache Airflow “DAG”(定时任务)自动化从本地PGSQL服务器将数据导出到云存储桶。我的Python技能有限,但CC帮助我专注于实现目标,而非纠结于代码细节。这是一个为期数天的迭代过程,但最终结果是我们现在拥有了一个可轻松实现本地到云数据迁移的运行模型。尽管 Python 代码涉及大量边界条件且较为复杂,但其可读性极高且逻辑清晰。

      2. 定制仪表盘,用于关联 HAProxy 服务器统计信息与运行时容器(LXC)钩子。在此场景中,我们需要确保某些系统服务正常运行,即使 HAProxy 显示容器处于运行状态。令我惊讶的是,CC立即知道如何解析HAProxy状态输出并将其与内部容器进程匹配。该项目的最终成果是一个非常不错的仪表盘,它能准确告知我们容器是否在线/离线,或容器内某些服务是否在线/离线。此外,它还提供详细指标,告知我们PGSQL复制是否严重滞后于生产服务器。

      3. 云服务提供商的计费摘要。对于此用例,我们希望从云服务提供商处获取完整的计费摘要——包括每台虚拟机、存储桶、网络连接等。对于每个对象,我们需要完整的成本细分(虚拟机包含存储、网络、计算成本)。虽然耗时数天完成,但最终结果是一个非常优秀的工具,能够详细展示每个资源的成本构成。当我第一次让它完全正常运行时,我们成功从账单中节省了数千美元,因为这些资源是多年前分配的未使用资源。需要明确的是,我对从云服务提供商获取数据的API调用一无所知,更不用说创建网页来展示这些数据的复杂性了。

      4. 自定义“数据库重建”网页应用。我们在开发/测试网络中运行多个数据库,这些数据库需要定期刷新以进行测试。数据库团队对服务器、容器或重建数据库的具体命令了解不多,因此这个工具非常适合他们。它提供了一个简单的“重建数据库”按钮,并显示状态消息等。我用 CC 在一天左右的时间内完成了这个工具的开发,数据库团队对这个工作流程非常满意(对他们来说非常简单)。无需通过GitHub工单进行数据库重建;他们可以轻松自行完成。

      再次强调,关键在于将精力聚焦于解决问题,而非成为Python/Go/JavaScript专家。而CC在此过程中给予了我巨大帮助。过去几周团队实现的生产力提升堪称惊人。我们正在开发那些原本需要聘请专业程序员编写工具,并赋予我们快速迭代新业务想法的能力。

  5. 对我来说,这太棒了。我通常在每个文件夹的根目录下都有一个 claude.md,用管道文本概述了该文件夹的规则集,以添加最少的上下文信息。它总是会为正在做的事情创建测试,并设置为以非常具体的方式在非常具体的文件夹中执行,否则它会尝试创建调试文件。我还设置了重复使用规则,以防止“增强”类变体或结构的泛滥,并始终尝试利用现有内容而非引入新内容,除非绝对必要。我与它的交互方式也非常具体,我不撰写冗长文本,不设置庞大的PRD,通常只有在自己不确定时才会进行规划。只有当我知道大语言模型(LLM)没有上下文(它比它的知识窗口更新)时,我才会进行大量文本输入。

    我通常会得到很好的“一击即中”(一次输入,所有任务完成后的最终输出)评论。我已经放弃了 claude 代码,尽管我正在使用 CLI 本身与另一个模型,但我之前使用的是 claude 代码,我转换的原因并不是 claude 是一个糟糕的模型,只是它太贵了,而我可以以更便宜的价格获得更大的模型。CLI 才是真正的力量,而不是模型本身。Opus 的表现确实比其他模型稍好一些。

    它完全让我能够专注于自己喜欢的编码工作,同时它在后台处理其他任务。目前我同时运行着大约60-70个不同的代理流。代码库大小各不相同,目前最大的一个约为2亿令牌(React、TypeScript、Go语言),表现良好。我只告诉它两次需要以不同方式处理。

    1. 你能列出你正在使用的部分代理流吗?非常好奇

    2. 你使用哪些模型来替代Anthropic的模型?

      我只尝试过一次使用Claude Code搭配外部模型(Kimi K2),但表现不佳。

      1. 我使用了经过微调的模型,其中一些参数超过600亿,一些基于Kimi或DeepSeek,还有一些是通用模型,来自Hugging Face,但我通过MCP工具使用它们。

    3. 您认为“代理流”指的是什么?我甚至无法想象管理60-70个代理所需的认知开销,更不用说物理上处理它们完成任务后重新启动的能力了。

  6. 有时,您会与 Claude Code 进行一次非常高效的会话,完成一些您可能需要频繁做的事情。

    我学到的一招是:让 Claude Code 研究斜杠命令,然后制作一个斜杠命令,将之前的对话转换为斜杠命令。

    这很酷!但当然,你不可避免地会中断它,需要做一些事情来纠正它,或者做出改变,或者说“不要那样做!”或者“使用这个工具”或者“在尝试之前多想想”或者“考虑大局”……所以你这样做了。然后你让它创建一个命令,它会明白你想要一个/improve-command命令。

    现在你有了可以构建的基础!

    以下是我目前对这些命令的迭代版本(不保证是最优方案!)

    https://github.com/ctoth/slashcommands/blob/master/make-comm…

    https://github.com/ctoth/slashcommands/blob/master/improve-c…

    1. 我对人们为编程一个非确定性黑盒所付出的努力感到惊叹。真正的勇气。

      1. 哦,让我告诉你,我为了打理我的非确定性花园、人际关系,甚至是我用来翻新房子的承包商,付出了多少努力!

        几份简单的Markdown文档,以及花时间去理解一些有趣的事情,似乎并不是一个高昂的代价!

        1. 装修我房子的承包商有时会毫无缘由地把一个房间刷成亮粉色。

          当我指出这一点时,他们会连声道歉,说“当然”墙壁必须是白色的,并好奇自己为什么会想到要把它们刷成粉色。

          奇怪,但他们其他方面都是不错的人。感觉他们比其他承包商高效10倍。

          1. 我让承包商在后楼梯开口处安装一扇向外开的门,回来后发现门是向内开的。他告诉我,他试图找出一种符合规范的方式来安装,但没有找到,所以只能这样做。我有点不满他没有先征求我的意见,但他做了务实的事情。

            这件事实际上发生在我周一。

            但当然,人类是确定性的钟表机制!

            现在你要告诉我我是怎么遇到一个糟糕的承包商的吗?因为这听起来很像“你使用模型的方式有问题”

            1. 最大的区别在于,当被问及时,他没有连声道歉并立即着手纠正,而是给你了一个可能与他所做决定因果相关的理由,而不是临时编造的事后辩解。

              1. 你对人们的评价太高了。当我要求对愚蠢的决定进行解释时,往往得到的是毫无意义的理由,或者根本没有理由,或者明显是临时编造的理由。

          2. 另外,他们以$2.41的价格粉刷整个房间!当你加上这个关键细节时,类比就变得清晰了。

            人们对AI编程不感兴趣,不是因为它比人类程序员好得多。他们感兴趣是因为它几乎免费。

          3. 我的意思是,我明白你想开个玩笑,但承包商搞砸了油漆,然后试图让你相信那是你批准的,这种情况并不罕见。

      2. 我们的脑子是个非确定性的黑盒子。我们就是不喜欢承认这一点。

        1. “这个系统有严重局限性。但我们应该更依赖它,因为另一个系统也有局限性。”

          几十年以来,我们开发和使用计算机正是因为它们可以非常精确和确定性。

      3. 你可能会惊讶地发现,人们与同事合作并给予他们反馈!

        1. 同事们会采纳这些反馈并加以改进。似乎这里有很多人认为,在假设他们离开的情况下,此类对其他人的改进毫无用处,但我偶尔会查看我的学员的领英页面,并为自己的贡献感到自豪。当他们认可我的努力时,我也会感到喜悦。

          我真的不明白为什么人们经常将人工智能与初级开发人员相提并论。

    1. > 最近的 Kimi-K2 据说效果很好。

      根据我的经验,它的功能低于 sonnet 和 opus 4.0,但在工具调用方面优于 gemini 2.5 pro。如果您不想每月花 100 美元或 200 美元购买 Claude Max,那么它真的值得一试。我喜欢这个模型的简洁性。

      > 您可以通过

      Anthropic 应该将 Claude Code 开源——他们有潜力成为 cli 编码代理的 VS Code。

      向 opencode 致敬:

      https://github.com/sst/opencode

      它原生支持所有模型,并尝试做 CC 所做的事情。

      1. 我尝试了 Gemini 2.5,虽然它确实是一个非常强大的模型,但你真的能感觉到它并未被训练成具有“代理性”/主动调用工具的特性。很多时候,它会制定一个计划,我告诉它“继续”,它却回复“我已经制作了一个待办事项列表,我们准备实施”之类的话,真是让人哭笑不得。你真的需要不断催促它采取行动,而整个 CC 的体验因此有些崩溃。

        1. 我同意,在我尝试过的模型中,Claude 模型是最具有主动性的。

    2. 如果使用其他模型,我会使用 sst/opencode(我也通过 Claude pro 订阅为 Claude 使用它)。

    3. 如果你不熟悉 CC 的运作方式(因为你像我一样,从未考虑过它的价格),那么 CC 客户端可以通过“npm”免费获得。

  7. 大家是如何使用这个工具而不受到速度限制的呢?我购买了 Claude Pro,但有时一小时内无法输入超过 5 个提示,否则就会出现需要等待 4 小时才能恢复使用的提示。我觉得自己可能用错了,这种体验实在令人沮丧。如何在不快速耗尽令牌的情况下,为它提供真实的代码上下文?

    1. 我一直大量使用它,从未被限速。我甚至没有订阅Pro Max计划。

    2. 尝试给它一个重映射,例如将其包含在 CLAUDE.md 中。这样应该会拉入更少的文件(上下文)。准确告诉它您认为需要编辑的文件也会有所帮助。如果您让它运行脚本,请确保告诉它只提取相关的输出,或者将输出管道传输到 /dev/null。

    3. 我遇到相同问题,最近几天还出现了更多超载错误,当意识到这东西的成本时,这些错误显得尤为刺眼。

      编辑:我看到一个评论提到了 Max 计划。我想明确的是,我在这里说的不是速率限制,而是实际模型无法访问的问题——所以这不是速率限制的问题。我希望 Anthropic 能尽快解决这个问题,因为这让我对 Claude Code 有点失望。

    4. 不知道。我连续使用了几个小时。最长时间花费了我 30 美元的代币。我认为是 4 个小时的来回沟通。

      以下是一个聊天 gpt 的例子,随后主要是 Claude 最终解决了我的笔记本电脑的背光问题。

      https://github.com/mbrumlow/lumd

      1. 我没有经常使用 Claude Code,但每小时花费大约 2 到 5 美元,但费用变化很大。如果我每天使用 6 小时,每月正常工作 21 天(126 小时),那么我每月的 API 费用为 250 到 630 美元。我认为通过练习可以提高效率(可能降至$1-$3/小时?)。如果你打算认真使用它,那么$100/月或$200/月的订阅计划绝对值得,只要你不被限速。

        如果你不确定是否要订阅,我建议先在API控制台账户中投入$5-$10,并使用API密钥进行测试。

    5. 我在欧洲办公时间通过Amazon Bedrock在us-east1区域成功运行。不过在纽约时间上午10点前9分钟就停止了。

    6. 你需要最大计划才能突破大多数速率限制

      1. 我希望在Pro计划期间能有一个Max试用版来测试是否确实如此。即使只是24小时试用也行。Max是一个昂贵的选项,希望它能解决这个问题。

        1. 就我而言,我在 Pro 之后升级到了 Claude Max,诀窍是关闭 Opus。这样做的话,你几乎可以在正常的工作日里使用 Sonnet。我个人并不觉得 Opus 有什么用,而且它消耗配额的速度是 Sonnet 的 5 倍。

          1. 为了持续使用 Opus,通常会购买 2-3 个 Max 级计划。

    7. 老实说,Claude Max 对我来说非常值得。

  8. 有人能帮我一下吗?我一直在用本地LLM、Continue和Visual Studio Code进行“氛围编码”,开发一些小型的Python应用程序。目前进展顺利。

    后来我发现了Claude的免费层级,于是将本地LLM修改过的“当前版本”输入其中,它一次性修复并更新了所有问题(并附带清晰的解释)。成功了!

    接下来,我尝试为一个新项目(一个使用PyGame的简单《疯狂矿工》风格2D游戏)获取所有规格和提示。我使用ChatGPT来构建所有这些内容,看起来对我来说是合理的,并且为项目不同部分设置了适当的约束。

    这是 Claude 创建的。但它不断提及一种方法,说代码中没有这种方法,而且我运行的是错误的版本。(我肯定不是)。我尝试通过参考行号和周围的代码来指出这一点,但它只是让我感到困惑。

    有什么办法可以解决这个问题吗?我并不期望完美,但似乎它只是把我带到了一个更高的层次,然后遇到了与本地大语言模型(LLM)基本上相同的问题。

    欢迎大家提出建议,我只是在有时间的时候玩玩这个,找点乐子(我身体不太好,所以只有感觉好时才会做这些事情)。

    先感谢大家了。

    1. 你可能遇到了“界面不清晰、隐藏假设过多、代码过于平庸”的问题,而大语言模型(LLMs)通常不擅长处理此类问题。如果你遇到了无法克服的障碍,那么最好进行有控制的拆除。

      也就是说,将 chatgpt 编写的所有内容交给您最高质量的模型,让它总结游戏的功能,并深入分析所有功能。

      然后,将该文档输入 claude。这可能需要几次迭代,但您得到的代码会比您对现有代码进行迭代要好得多。

      Claude 很可能一击就做出一个更好的应用程序,或者至少是一个可以自我改进的应用程序。

      如果 claude 仍然坚持添加新功能,那么安装 context7 MCP 服务器,并要求它在处理你的请求时使用 context7。

      1. 谢谢。

        我认为我应该在帖子中更清楚地说明,代码是 claude 的,是从头开始编写的(第一个应用程序是一个曼德尔布罗特浏览器,它添加了功能,这是一个平台游戏)。

        目前这是一个单一文件(我确实提供了一个建议的项目结构,每个责任领域都有相应的文件),而且它勉强能用。

        我认为我可以创建类中缺失的方法,但想看看是否可以通过工具来实现——这既是过程的实验,也是最终结果的实验。

        感谢您的回复,我将研究您的建议,看看会发生什么。

    2. > 有什么办法可以解决这个问题吗?

      没有办法。这是大语言模型(LLM)技术的局限性。它们可以输出最可能的令牌序列,但如果“可能”与您的问题“正确”不匹配,那么您无能为力。

      此外,每个大语言模型(LLM)对“可能”都有自己的定义——这来自于该特定大语言模型的训练和微调的秘密配方。

  9. 我仍然不相信这些“代码库中的 AI”工具。对于“氛围编码”也是如此。

    我像使用手术刀一样使用AI——我深入其中,明确自己想要什么,利用提示词经验获取几个函数或最多一个脚本,阅读代码、整合后立即进行压力测试。

    因此,我对AI生成的代码满意度约为95%。然而,这要求我仍需理解自己的代码库、需求、故障模式等。

    我的理念是,软件开发的速度固然重要,但可靠性更为关键。目前看来,过分依赖这些AI工具似乎是在牺牲前者以换取后者。如果整天只做概念验证(POC),我还能理解(即便如此,也不要让它们变得太大……),但这对我来说还不是时候。

    1. 你应该考虑像对待初级工程师一样,记录下你对耐久性的要求、故障模式以及与你正在开发的特性/组件相关的关键上下文。然后,你可以重复使用这些上下文文档。如果AI不知道你的期望是什么,它会假设你需要一个PoC,并给你PoC级别的代码质量。

  10. 我没看到这里有实际工作在进行。只是在某个部分添加了 reply_to_email 到多个类中,并从几个地方移除了它,这似乎不算什么大工程。

  11. 最近,Cursor 和 CC Max 都开始限制和更改条款,我担心这种趋势会越来越像毒品贩子一样,直到我们都偷东西为生,住在废弃的建筑里。

  12. 在阅读和听到大量好评后,我非常想在我的初创公司中尝试Claude Code。我已经管理Claude Team订阅,但据我所知,Code并未包含在内,它仅存在于Pro/Max版本中,而这些版本是针对个人账户的。人们是如何将其作为团队订阅使用的(理想情况下支持集中计费)?

    1. 您可以使用 CC 与 AWS Bedrock,享受 AWS 提供的所有集中计费服务。我的公司就是这样处理的。

    2. 是的,这非常令人讨厌,希望他们能解决这个问题。我错过了星号,为我的团队购买了 Claude Team,以便他们能够使用 Claude Code,但后来发现它被排除在外,不得不经历退款流程,现在他们必须单独购买。

  13. 我想知道现在的面试流程是怎样的?他们是用AI测试你还是不用?LeetCode的问题是否会用AI来验证答案?

    面试中对你的评估与实际工作要求之间是否存在更大差距?

    仅使用AI的开发者是如何应对的?

    1. 和以前一样,你要求应聘者详细解释他的推理过程,并在此过程中提出问题。

      人工智能无法思考或推理,大语言模型(LLMs)对于游戏面试仍然几乎毫无用处。

    2. 你参与的项目及其影响。希望如此。

  14. 在这个新的大语言模型(LLM)世界里,我略微感到不安的一点是,我支付的价格是否可持续。我疯狂地使用 Cursor,我认为我们每月为此支付了 40 美元左右。这是否像早期的 Uber 一样,其价格之低令人难以置信?到 2030 年,我是否会依赖人工智能辅助的生产力水平,根据这种期望向客户和顾客做出承诺,但突然发现自己面临 1000 多美元的账单,因为所有人工智能公司都需要实际赚钱?

    1. 我这是凭直觉说话,但我认为那部分将是最快被优化的。当前的能力在几年后将只值几美分。我基于过去的趋势得出这个结论,同时也听到一些权威人士表示,整个技术栈中仍有大量优化空间。

  15. 在基本设置之后,人们在做什么来为这些工具铺平道路?

    也就是说,人们如何组织他们的上下文和代码库,以帮助工具引导他们找到正确的答案?

    我这里有一些初步的想法[1],但我知道还有更多(更好的)方法论等待发现。

    [1]: https://blog.kierangill.xyz/oversight-and-guidance

  16. 作为 Cursor 和 CC 的日常活跃用户,我很高兴能够发现一些能够进一步提高工作效率的细微技巧。我时不时会发现一些这样的技巧。

    文章写得很好。而且充满了有用的技巧!

    今天,我手动将 PR 更改请求复制粘贴到 CC,如果当时知道这些技巧,我的手腕就不会那么疼了。

  17. 我目前最大的问题是,我更倾向于与 Claude 和 GPT O3 交流,而不是与团队中其他更年轻的开发人员交流。我只是能完成更多的工作。我并不是在开玩笑,我真的不喜欢自己最近几天的表现。我想我必须利用新获得的空闲时间与他们进行更多交流。

    1. 是的,我也注意到了这一点。我更愿意与Gemini Pro讨论敏感话题(如美国外交政策),而不是与人类讨论。

      我最近在看《Seinfeld》,据说在90年代,去机场接朋友是一项重要的社交契约。如今我们只需叫辆优步。

    2. 不过,我猜反之亦然,初级开发人员更倾向于向人工智能提问,而不是向上级提问。

      1. 除了他们不会这样做。大多数人负担不起。不过这是我的错,我还有一个月左右的时间就可以订阅所有这些服务,然后我会与他们和 Claude 一起进行程序设计,直到他们成功或失败为止。我正在全力学习,仍然在努力证明它,并获得对所有这些的真正验证。

  18. 我从 Claude Code 中获得了许多阿尔法信息,但如何将它带给我的团队其他成员却有些困难。有人对分享最佳实践或让团队成员或下属也从 Claude Code 中获益有实际建议吗?

  19. 每当我受到速率限制(专业版计划)时,我就停止开发。

    除了最小的东西外,我都会使用 Claude Code…

    即使如此…

    对于更复杂的任务,我会让它为我提出解决方案(在添加新功能时)。

    当你提供明确的指导时,它会很有帮助:做这个,用那个,避免X,保持简洁,需要时要求重构。

    总的来说,它就像一个略带自闭症的初级开发者,所以你需要非常明确,但一旦它知道该怎么做,效果就非常惊人。

    话虽如此,每当遇到难题或陷入循环时,我倾向于回滚,要求根据需求进行 Proper 分析,并补充必要细节。

    对于非标准任务(例如在照片中检测窗户并确定厘米单位的测量值),仍需提供大量指导。然而,一旦我告诉它使用 xyz 和 ABC,它就能自行处理。我一生中从未写过超过几行 PHP 代码,但多亏了 Claude,我拥有了一个运行 A100 的完整 API 服务器。

    对我来说,节省的时间非常可观,尤其是前端开发、重构或实施新功能以查看它们是否合理方面。

    对我来说,这是我工作方式的一个巨大转变,如果我必须回到人工智能出现之前的时代,我会感到非常难过。

    说实话,我曾经是 cline & Gemini 的满意用户,每月在 API 调用上花费数百美元。但它从未给我带来 Claude 代码给我的感觉,它的可靠性为我节省了 80% 的时间。

    1. 我仍然不明白为什么我应该想要这个。

      我指导过和管理过初级员工。在他们不再是初级员工之前,他们通常对生产力有负面影响。

      1. 我目前的工作理论是这样的:

        喜欢指导初级员工的人通常对通过大语言模型(LLM)代码生成进行迭代的投资回报率感到满意。

        那些觉得初级员工有些令人沮丧但有时又是工作的一部分的人,在投资回报率计算中往往有更高的分母,他们会问自己,为什么还要继续撞大语言模型(LLM)的墙。

        从长远来看,第一类人可能更聪明,更有效地发挥他们的能量。

        我属于第二类。我每隔几个月就会进行测试,但仍在等待模型能达到更高的R值或更低的I值。或许很快就能实现。

        1. 对我来说情况完全相反。我享受指导新人的过程,且常被寻求帮助解决诸如修复Git工作流或解答流程运作方式等小问题。与大语言模型(LLM)合作绝对不是我想要做的,因为我更希望受指导者真正学习,并越来越少地问我问题。到目前为止,我对人工智能的体验是,它根本不会学习,而且从未让我觉得它像人类一样。它假装悔恨,为错误道歉,但仍然会犯同样的错误。这是最糟糕的初学者,他们多次重复同样的错误,却懒得将这些错误记在脑子里。

          1. 你说得对,我可能对第一组的分类过于宽泛,因为我对他们了解不够深入。

            第一组内部可能存在子类别。听起来你更重视“结果”(学员成长,可能指向长期贡献),而有些人可能只是享受“过程”本身。

        2. 我是一个愤世嫉俗的人,根据我的经验,前者往往是最令人讨厌且通常是最差的工程师。

          那些将“指导他人”视为身份骄傲和区分标志的人,通常是你最不愿听取建议的人。

          真正的导师是后者,即 junior 们主动寻求或仰慕的对象。

          换句话说,前者就像那些在YouTube上试图兜售垃圾课程的人。

          1. 这是第一类人的极端表现,但我确实认同这种现象存在!

      2. 这要看情况……在我做咨询期间,我与数百名初级和高级员工合作过。

        在这类情况下我经历过起伏,但大多数时候,关键在于为他们指明前进的方向。

        大多数情况下,软件开发本身相对简单,而大部分指导内容都围绕如何在所在组织中行为处事。

        一个人能进行的架构/代码质量审查是有限的,通常我们更关注开发人员在与他人(同事、上司、客户等)相处时的适应能力。

        我们确实遇到过一些技术非常出色的人,但在一千人的公司里,这样的员工大概只有十几个。

        我之所以特别提到那位略带自闭倾向的初级员工,是因为我曾与他共事,他差点被解雇,因为其他人难以与他相处。

        于是,我搬到他旁边的工位,与他共事了一个多月,结果他成为了我们正在进行的某个项目的核心成员,因为他非常聪明、精准,且拥有惊人的记忆力,这些特质在当时的项目中至关重要。

        其他类似的故事还有很多,比如有一次,他们差点解雇一位同事,因为他做某件事花了几天时间,而这本来最多只需要几个小时。于是我坐在他旁边,看看他在做什么。

        结果发现,他正在重构所有与他功能相关的代码,因为他无法忍受糟糕的代码。于是我们把他调到了质量控制部门,上次我听说他过得很好……

        我想我想要表达的是,就像与人相处一样,你需要找到一个合适的运作方式,并确保双方的期望一致,但如果你能搞清楚这一点,它将带来丰厚的回报。

  20. Claude Code 有一个 VS Code 扩展。它实际上只是一个终端窗口,但本身非常方便。如果你使用 /ide 连接扩展,它会执行一些操作,但尚未达到 Cursor diff 的体验(更不用说 Cursor 标签页的体验了,这也是我仍然使用它的原因)。

    1. Claude Code 几乎在一夜之间取代了 Copilot,但我希望 VS Code 插件能更集成一些,因为它只是比终端多一点功能,不过我猜这就是重点。我希望语法高亮能与我的编辑器相匹配,以及类似的东西(不仅仅是浅色/深色主题)。

      我真正想要的是一个可以轻松隐藏它的方法,我经常使用 Copilot 作为自己的面板。

    2. 由于差异和标签页,我现在 50% 的时间使用 Claude Code 与 Cursor。这个扩展有时会有些小问题,否则我会更频繁地使用它。今天在使用它搜索内容时遇到了与节点相关的 bug(忘了向 Anthropic 报告,哈哈)。其他 bug 包括滚动卡顿。

  21. 阅读这些内容,我认为这些工具可以作为软件工程经理的培训工具。

  22. 使用 claude code 有时非常棒,有时却完全没用。对于简单到中等复杂度的重构非常有用。如果要求它做一些比较复杂的事情,它就会崩溃。现在它已经取代了我的一名初级开发人员。每月 200 美元非常值得。

  23. CC 中的“branch-analysis.md”是什么?谷歌搜索没有结果。

    1. 只是你可以让 claude 写笔记而已。

  24. 有人用它来开发游戏吗?比如让代理尝试构建一个游戏?

    1. 我尝试过用Aider搭配Godot。CC可能更合适。Aider搭配4o/o3-mini在处理GDScript时表现不佳,且编辑Tres/TSCN文件(通常需通过编辑器修改)时效果糟糕。如果你的游戏高度依赖代码,或许还能凑合,但若涉及需用专用程序编辑的资源/资产,它会难以应对。

      1. 你应该使用最好的模型。试试o3-pro

  25. HN在关于AI产生不可靠的垃圾代码的言论上转变得如此之快,以至于大多数人现在都用它来取代组织中的初级开发人员——几个月前我因提出组织应该这样做而遭到强烈批评。

    进步不会止步于此,我认为CC更像是一位中级工程师,拥有顶级高级工程师的知识。我认为我们正处于可以开始用少数高级工程师来提示和审查AI生成的代码和PR的阶段。

    当然,我们还未达到那个阶段,但现在确实能感受到这种转变的开始… 如果我们能实现这一目标,今年年底科技公司将迎来巨大的生产力提升。

    令人兴奋的时代。

    1. > CC更像是一位拥有顶级高级工程师知识的中级工程师。

      你能提供任何证据支持这一观点吗?根据我的经验,它既不是前者也不是后者。

    2. 为什么 CC 只是一个糟糕的终端,而不是由 Anthropic 通过 CC 本身构建的某个超级棒的环境?

      它应该能够重建 VS Code 并做得更好,对吧?

      1. 因为他们的理念是开发者与编辑器和 IDE 绑定,所以你应该能够使用自己的工具。他们说得对。

        1. 那么,所有流行 IDE 的那些强大且深度集成的插件/扩展在哪里呢?

      1. 我认为发帖者的意思是,这些插件没有必要,因为他提到要取代“大多数工程师”。科技行业即将遭受重创——软件领域即将大幅缩减。说实话,以目前的发展趋势,我认为这种情况是有可能的(尽管这会严重不利于我)——三年前,考虑到所需技能的水平和终身学习的要求,我绝不会想到这一点。为什么需要初级工程师?——虽然可能需要他们,但由于人才过剩,可能需要20年(一代人退休的时间)才能让当前的资深工程师耗尽,因为根据原帖所述,人工智能也会摧毁他们。这显然是一个足够遥远的时间,足以成为别人的问题——到那时,人工智能可能已经有了显著的进步;我们甚至可能拥有超级智能,而软件工程的工作可能就不是我们最担心的问题了。

        对于科技公司和使用科技的非科技公司(许多非技术型、以资本为基础的公司现在能够以更低的成本基础实现规模化)的拥有者来说,这很好;但对于那些拥有科技技能并为未来投资的人来说,情况并不理想。这是这些人工智能公司的目标。你们的痛苦/失业/成本就是他们的利润/经济剩余。

        对原帖作者而言,这是资本的“激动人心的时代”——但对许多人来说,这似乎预示着一场即将到来的噩梦,尤其是那些依赖脑力劳动谋生的人。我在HN上看到的绝大多数CC文章都趋向于热门,这表明它确实正在引发人们的贪婪或恐惧。我认为“代码”似乎是迄今为止最成功的AI产品——其他大多数只是写作助手、梗生成器、高风险操作工具等,至少对我来说是这样。正是代码似乎在引发这种持续的恐惧。

        顺便说一句,至少对我来说,AI已经让我个人放弃了继续学习/投资于这个职业的念头,作为一名拥有近20年经验的高级工程师。我希望我是错的。

  26. 如果我能用我的 G 语音号码注册 Claude,那就太好了。

    1. 甚至不需要号码。错过这个机会很遗憾,但我不会改变主意。

    1. 我将它们用于不同的任务,Aider 是一把锋利的刀,而 Claude 代码更像是一把钝器。

    1. 唯一值得考虑的计划是$200的Max层级。通常会购买2到3个。

  27. 即使是最不喜欢改变的铁杆开发人员,也对与人工智能辅助开发相关的最新版本感到满意,这真是太好了。

    现在,我的工作流程实际上可以归结为 2 种工具——leap.new 从 0 到 1,因为它还可以生成后端代码 w/ infra + 部署,然后我在 Zed/Claude Code 中将其拾取并继续工作。

      1. 目前,如果你知道自己想要什么,并能准确告诉它,AI可以帮助你实现(基本上是实习生级别的工作)。

      2. 当你进入一个新领域,但不想深入研究,只是想要快速实现,且这不是应用程序/服务的核心功能时。

      但如果你有经验,你会发现AI可能会很快搞砸事情,因此对我来说,它最好用于“填补清晰且定义明确的功能”的零散部分。基本上,它最适合处理小块内容,然后再处理大块内容。

      1. 我同意。但这也是一种心态问题。有经验的开发者往往带着先入之见来对待AI,这限制了它的实用性——对“工艺、控制问题和完美主义”的自豪感可能阻碍了我们看到AI真正发光的地方。我发现,放下这些本能,将AI视为思想伙伴而非仅仅是代码生成器,会非常有用。我们与这些工具互动的心理层面可能与技术层面同样重要。

        网上的一些评论也反映出,许多“心胸狭窄”的开发人员以封闭的心态拒绝接受新事物——只关注负面因素,而不接受积极因素。

        我听起来有些哲学,但希望我的观点能够被理解。

        1. 你的业绩如何?你目前在 Claude Code 的工作范围是什么?

          没有了解作者的技能和使用场景,这场对话毫无意义。

        2. > 对“工艺、控制问题和完美主义”的自豪感

          听起来你根本不会编程。指南、标准和格式规范的制定是有原因的。原因在于:减少 bug 和提高可维护性。你听起来就像个自以为是的初级开发者。

        3. > 以“工艺、控制问题和完美主义”为荣

          我的意思是,我们真的希望我们的代码库不遵循编码标准吗?或者网络代码不考虑故障或事务问题吗?我觉得所有这些特质都是优秀高级工程师的标志。真正优秀的工程师会学会适度放手,但没有资深工程师会眼睁睁看着开发者通过自动化或其他方式,绕过六层架构,直接插入静态访问器之类的东西。

          工艺、控制问题和完美主义,通常是为了提高可读性,限制熵和范围,以便更确切地了解一段代码的后果。因此,将它们视为问题对我来说是个奇怪的观点。

    1. 我很好奇:你会仔细审查生成的每一行代码吗?

      1. 起初我没有。现在我已经学会了必须这样做。

        你必须像鹰一样密切关注 Claude Code。因为它不一致。它会作弊、放弃、改变方向,而且不会让你清楚它正在做什么。

        因此,虽然它在功能上并不“初级”,但就你作为“高级”人员需要彻底审查它所做的一切而言,它绝对是“初级”的。

        否则,你以后会后悔的。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

你也许感兴趣的: