HackerNews中文版

在观看了Anthropic最近的事后分析（anthropic.com/engineering/april-23-postmortem）后，我开始思考我对Claude Code的不同处理方式。他们降低了默认的推理努力以修复延迟，称之为错误的权衡，并在公众审查下进行了回退。虽然这些回退是好的，但并没有改变我一直忽视的基本方程。事实上，我们现在可能有一支工程师团队可供使用。令牌成本是真实的成本，但我无法为我个人的工作雇佣自己的工程师。如果用这种视角来看待令牌使用，思路就会发生变化。它不再是关于成本上限的问题，而是变成了成本/产出/质量的视角，就像我在真实团队中考虑雇佣决策一样。我现在关注的四个方面是：模型、配置、提示和代理。关于模型。Opus在关键决策和架构推理方面仍然是最强的。Sonnet通常足够用于编码和简单的重复性任务。我会根据工作选择合适的模型。如果我贪图便宜，就不能指望质量。关于配置。/effort的范围从低到高。Opus 4.7的默认值是xhigh。我会根据工作调整级别。快速编辑不需要最大值，而架构决策则需要。这是我之前一直忽视的最便宜的选择。关于提示：我发现最有效的三种模式。 1. “如果不确定，请提问。”没有这个，我就没有给模型留出余地，这会限制解决方案，即使没有明确的答案，也需要显露权衡。 2. “时间和成本在这里不是因素。优先考虑稳健、可持续、可扩展的解决方案，不留下技术债务。”这反转了任务执行期间隐含的优化压力。 3. “反思本次会话，并通过claude.md或技能记录你所学到的，以便下一次迭代不再重复同样的错误。”值得将其作为技能记录并为自己迭代。没有这个，每次会话都从零开始，重复我已经纠正的错误。关于代理。虽然不想详细展开，因为这本身就是一个完整的主题，但对我有效的模式是使用代理来分离关注点。一个代理负责对代码进行规范审查（代码是真实来源），另一个代理在实施后进行代码审查。工程和产品团队一直在市场速度与成本和质量之间取得平衡。人工智能也不例外。不同之处在于我选择了哪些杠杆。故意在努力上花费预算，工作就会以我想要的水平回报。

查看原文

After watching Anthropic's recent postmortem (anthropic.com/engineering/april-23-postmortem), I've been thinking about the way I approach Claude Code differently. They lowered default reasoning effort to fix latency, called it the wrong tradeoff, and reverted under public scrutiny. The reverts are good but they don't change the underlying equation I'd been ignoring.The fact is we potentially have a team of engineers at our disposal now. Token cost is a real cost, but I couldn't hire my own engineer for any of the personal work I'm doing. Apply that lens to token usage and the approach shifts. It stops being about the cost ceiling and becomes a cost/output/quality view, the same way I'd think about hiring decisions on a real team.Four places I now think about: model, configuration, prompting, agents.On model. Opus is still the strongest for critical decisions and architectural reasoning. Sonnet is usually good enough for coding and simple repetitive tasks. I use the right model for the work. If I cheap out, I can't expect quality.On configuration. /effort runs from low to max. Opus 4.7's default is xhigh. I set the level to fit the work. A quick edit doesn't need max, an architectural decision does. The cheapest move and the one I'd been skipping.On prompting: three patterns I find most effective.1. "Ask questions if unsure." Without this I'm not giving the model an out, which closes off solutions even when there's no clean answer and tradeoffs need to be surfaced.2. "Time and cost are not factors here. Prefer robust, sustainable, scalable solutions, do not leave tech debt." This inverts the implicit optimisation pressure for the duration of the task.3. "Reflect on this session and encode via claude.md or skills what you learned, so the next iteration doesn't repeat the same mistakes." Worth capturing as a skill and iterating for myself. Without this every session starts from zero, repeating mistakes I've already corrected.On agents. Without going into detail as this is a whole post in itself, the pattern that works for me is using agents to separate concerns. One agent does spec review against the code (code is source of truth). A separate agent does code review after implementation.Engineering and product teams have always balanced speed to market with cost and quality. AI is no different. The difference is which levers I choose. Spend the budget on effort deliberately, and the work comes back at the level I want.

在Anthropic的事后分析之后，我对使用Claude Code的方式进行了哪些改变。