我的职业道路与作者惊人地相似

>> LLM在我们业务的具体细节上经常失败：本地税法、会计流程的特殊性、我们账本实现的细节。 我的公司也处理很多复杂的法规和特定领域的系统实现，AI以前很难处理这些问题。我们通过组织良好的claude.md/agents.md文件解决了这个问题。此外，我们还实施了supermemory.ai，因此AI代理在新会话开始时总是能回忆起新做出的决定。

> LLMs 经常无法处理我们的业务细节：本地税法、会计流程的特殊性、我们账本实现的细节。 一种能迫使你和 LLM 达成对产品特性和这些特性所应遵循的法规的共同理解的技能，是否会有帮助？主要想法是我们向 LLM 提供文档，然后它会提出很多问题，以消除 LLM 可能存在的歧义和误解。我建议请看一下这些技能。它们真的很有帮助。 https://www.youtube.com/watch?v=6BB6exR8Zd8

我甚至无法让 Claude 或 GPT-5 一贯地为常见的用例生成好的流程，更不用说特定领域的垃圾东西了。它们的词汇量很深，这使它们听起来比实际更博学。 它们在编写代码和调试可见错误方面非常出色——但这只是整个工作的 50%。

是的。一旦你开始构建真正之前从未构建过的东西，就不能信任 LLM 做任何架构决策。我正在构建一个基于各种物理模拟的产品，所以它完全是基于基本原理的，但如果没有主动的研究、思考和质疑，它会生成计算代码，其速度比实际需要慢数百个数量级，同时实施荒谬的回退和捷径，这实际上导致计算变得毫无用处。 这种情况可能有 95% 的时间发生。 监督非常重要，而架构思维目前还不能外包，只能执行。

LLMs 经常无法处理我们的业务细节：本地税法、会计流程的特殊性、我们账本实现的细节。 这是领域专业知识——软件工程师不需要具备这个。当然，通常高级软件工程师可能精通这个，但他们并不是必需的。 传统上，为了实现无摩擦的生产，工程师能够完成他们 90% 的工作而无需咨询业务专家是有用的，但这就是 TFA 所讨论的当前核心问题——“传统”已经结束了。 在这个新世界中，高级工程师的工作不再是自己具备这种领域专业知识，而是知道如何确保代理具备这种知识，或者能够获得并验证其正确性。 那些坚持认为自己的高级业务领域专业知识使他们安全的高级工程师，很快就会像没有转型的初级工程师一样被淘汰。

> LLMs 经常无法处理我们业务的具体情况：本地税法、会计流程的特殊性、我们账本实现的细节。 所以这里有一个光谱，而我不知道自己不知道什么——意思是，我可能就是错的。但我们都在这个光谱上，你确定这不就是技能问题吗？ 你列出的所有具体细节似乎都非常基础，在类似项目中，我都会直接把它们插入到 AGENTS.md 或者一个强参考文档中，说明在哪里可以查找。 归根结底，你实际上是在说问题在于 LLM 没有访问一堆事实的权限。