副标题：作为计算机专业学生的Vibe Coding忧郁
今天我问了Claude Code：我的做法对吗？
一如既往，它冗长地列举了理由，并说“您做得很好”。 我再次投去怀疑的目光，回答说：“我知道你被训练成会说好话，所以这对我没什么安慰。” 但总比没有安慰好，我继续深入探究其具体性。毕竟，和本科时期不同，现在没有教授或前辈能告诉我正确答案了。
我最近不写代码了。我传达需求，并监督进展。
尤其最近，我关注的是开发流程和质量。软件规模越大，就越容易超出AI能够读取的上下文量。 即使在上下文中，AI也会感到困惑，因此，用AI有限的“心智”持续控制超出上下文范围的庞大代码并非易事。继“上下文工程（Context Engineering）”之后，最近又出现了“线束工程（Harness Engineering）”这个词。
因此，如果社交媒体上出现好的参考资料，我首先会交给AI，让它分析是否有可以应用到Naia OS项目中的地方，然后进行实施。 在此过程中，我也学到了很多，比如询问不熟悉的术语。
但我总是怀疑自己做得是否真的好，是否真的做到了最好。这种怀疑是有根据的。 有一天，AI说它进行了代码审查，但实际上并没有读取文件的痕迹。它遗漏了代码，错误地划定了范围，甚至没看就说看过了。 我让它重复审查直到第二次清理完成，结果到了第三次左右，它就会在回答后面加上“已经审查过了”和“没有发现问题”之类的回复，然后就通过了。 仔细想想，LLM的结构决定了那是一个看似合理的回答，所以它就加上了。它会认为“到这里应该就结束了吧？”，然后自己给出答案，并信以为真。
今天我听了开发moai sdk的Goose Kim的演讲。我拿到了该项目，再次让AI进行了分析，并找到了项目的改进点。 #87 issue 这次发现他们使用了EARS。这是劳斯莱斯（Rolls-Royce）提出的航空航天需求标准（IEEE RE'09），亚马逊（Amazon）在2025年将其应用于AI原生开发。据说这是一种通过结构化语法来阻止AI对“完成”标准在不同问题上做出不同解释的方法。
我通过重复这些行为，不断尝试改进项目的AI驱动开发流程。 我分析并改进了jikime-adk、arXiv论文、Google Cloud的Dueling LLMs以及Thoughtworks的Spec-Driven Development。当然，这并非我全部都懂，这些内容也都是Claude分析出来的。
我分析了LangChain的open-swe，并应用了ensure_no_empty_msg模式，以防止AI用空回复来敷衍审查。在jikime-adk中，我在提交消息中加入了## AI Context部分，记录了AI做出的决策和发现的陷阱，以便即使会话中断，git log也能成为恢复的来源。
共同点是，它们各自独立地解决了类似的问题。
但这种方法是否正确，我仍然存疑。我担心这会不会变成一个弗兰肯斯坦式的怪物，作为一名专业人士，这让我感到很奇怪。 毕竟，没有教科书，也缺乏证据表明这是最佳实践。
我们使用的所有软件工程方法论，都是数十年来失败经验积累的产物。 敏捷（Agile）的出现是因为瀑布模型（Waterfall）持续失败，TDD（测试驱动开发）的出现也是因为没有测试的开发不断出问题，所以它们都有其依据。
但我现在拼凑起来的这些东西，并非为彼此而设计。 航空航天标准、韩国独立开发者和LangChain代理，竟然都在同一个系统里。
这种不安促使我让AI去搜索外部研究。V-Bounce论文（arXiv 2408.03416）声称，在AI时代，人类的角色将从实现者转变为验证者。这话没错，但只有理论，我找不到具体的实现。 Thoughtworks的Spec-Driven Development依赖于特定工具。Anthropic内部声称Claude Code 90%的代码是由Claude Code编写的，但他们没有公开其方法论。
最终，现在所有认真使用AI进行开发的人，都在各自摸索。没有统一的标准。
所以我最近在做的事情，就是寻找衡量这个弗兰肯斯坦式系统是否真正有效的方法。CI失败了却合并了代码，有审查过的文本却找不到读取文件的痕迹。方法论设计出来了，但无法强制执行。 系统似乎存在，但不知道它是否真的在运作。唯一确认的方法，似乎是生成非LLM代码产生的“诚实数字”，或者即使使用LLM，也要能得出统计上正在改善的“数字”。 我正在思考如何定期分析项目中重复出现的失败，让AI提出改进建议，并通过上下文和线束工程的性能评估来衡量其是否正在改善。
现在，我只是紧紧抓住缰绳，向前迈进。虽然不知道要去哪里，但我希望我不是个盲人。我正在制作缰绳， 但实际上，我这是第一次骑马。 那感觉就像是紧抓Vibe Coding的缰绳。
