氛围代码编写失败
3 分•作者: 10keane•4 个月前
我正在使用 Claude 来维护一个代理循环，在重要的工具调用之前会暂停并请求用户的批准。在进行一些错误修复时，我发现了一些清晰的模式和原因，解释了为什么对于没有技术知识和架构专业知识的人来说，Vibe 编码会失败。
首先，让我描述一下我的工作流程——这在数百个成功的会话中一直沿用：
1. 通过内部测试识别错误。
2. 让 Claude 代码调查代码库，找出三个潜在的根本原因。
3. 将根本原因和建议的修复方案粘贴到我存储所有架构文档和设计决策的 Claude 项目中，以便它进行评估。
4. 在项目中与 Claude 讨论，编写详细的任务规范——任务规范将具有指定的格式，并包含各种测试。
5. 将其交还给 Claude 代码以实现修复。
在今天的会话中，根本原因分析仍然很棒，但提出的修复方案非常糟糕，我真的认为这就是大多数 Vibe 编码项目最终失去可维护性的原因。
以下是两个根本原因和建议的修复方案：
错误：代理请求用户批准，但有时批准弹出窗口不会显示。我尝试发送消息来解决这个问题。消息被默默吞噬。代理看起来已经死了。我需要重新启动整个流程。
Claude 的评估：
根本原因 1：
批准弹出窗口通过实时连接发送一次。如果用户的 UI 在那一刻没有连接——页面刷新、手机后台运行、连接不稳定——他们就永远看不到它。没有重试，没有恢复。
这实际上是真的。
建议的修复方案
“让我们将批准状态保存到磁盘，以便它在崩溃后仍然存在”。听起来不错，但关键是，按照设计，如果发生崩溃，代理将从会话日志中冷启动恢复，并且无论如何都不会获取批准状态。这个修复方案只是增加了模式的复杂性，而且完全无用。
根本原因 2：
当批准被中断（守护程序崩溃、用户重启）时，会话历史记录中会有一个孤立的 tool\_call，没有匹配的 tool\_result。
建议的修复方案：
“编写一个合成的 tool\_result 以保持会话文件的结构有效。” 听起来很干净。但我问：谁会因此而崩溃？ LLM API？不，它处理缺失的结果。会话重放？不，它读取现有的内容。孤立的 tool\_call 准确地代表了发生的事情：工具被调用但从未完成。这就是真相。编写一个假结果来掩盖它会引入一个新的写入协调问题（你到底什么时候编写假结果？如果守护程序在写入期间崩溃了怎么办？）来解决一个不存在的问题。会话文件并没有“损坏”，它是准确的。
Claude 拥有完整的架构文档、代码库以及一百多个项目的历史会话作为上下文。它仍然选择了复杂的解决方案，因为它看起来是好的工程。它从未问过“重启后这重要吗？”
我个人多次遇到这种倾向于看似更稳健的过度工程的情况。我真的相信，这才是人类应该介入的地方，而不是给出一个一句话的需求，然后看着代理做各种“稳健”的工程。
查看原文
i am using claude to maintain an agent loop, which will pause to ask for users' approval before important tool call. while doing some bug fixes，i have identified some clear patterns and reasons why vibe coding can fail for people who dont have technical knowledge and architecture expertise.<p>let me describe my workflow first - this has been my workflow across hundreds of successful sessions:
1. identify bugs through dogfooding
2. ask claude code to investigate the codebase for three potential root causes.
3. paste the root causes and proposed fixes to claude project where i store all architecture doc and design decision for it to evaluate
4. discuss with claude in project to write detailed task spec - the task spec will have a specified format with all sorts of test
5. give it back to claude code to implement the fix<p>in today's session, the root cause analysis was still great, but the proposed fixes are so bad that i really think that's how most of vibe coded project lost maintainability in the long run.<p>there is two of the root causes and proposed fix:<p>bug: agent asks for user approval, but sometimes the approval popup doesnt show up. i tried sending a message to unstick it. message got silently swallowed. agent looks dead. and i needed to restart the entire thing.<p>claude's evaluation:
root cause 1:
the approval popup is sent once over a live connection. if the user's ui isn't connected at that moment — page refresh, phone backgrounded, flaky connection — they never see it. no retry, no recovery.<p>this is actually true.<p>proposed fix
"let's save approval state to disk so it survives crashes". sounds fine but then the key is by design, if things crashes, the agent will cold-resume from the session log, and it wont pick up the approval state anyway. the fix just add schema complexity and it's completely useless<p>root cause 2:
when an approval gets interrupted (daemon crash, user restart), there's an orphan tool_call in the session history with no matching tool_result.<p>proposed fix:
"write a synthetic tool_result to keep the session file structurally valid." sounds clean. but i asked: who actually breaks on this? the LLM API? no, it handles missing results. the session replay? no, it reads what's there. the orphan tool_call accurately represents what happened: the tool was called but never completed. that's the truth. writing a fake result to paper over it introduces a new write-coordination concern (when exactly do you write the fake result? what if the daemon crashes during the write?) to solve a problem that doesn't exist. the session file isn't "broken." it's accurate.<p>claude had full architecture docs, the codebase, and over a hundred sessions of project history in context. it still reaches for the complex solution because it LOOKS like good engineering. it never asked "does it even matter after a restart?"<p>i have personally encounterd this preference for seemingly more robust over-engineering multiple times. and i genuinely believe that this is where human operate actually should step in, instead of giving an one-sentence requirement and watches agents to do all sorts of "robust" engineering.