我写自己的 Markdown
2 分•作者: KenPainter•大约 1 个月前
在业余项目方面，我为代码和文本制定了以下规则：
1a) 只要我设计了解决方案，围绕正确的数据结构构建（我听说如果数据结构正确，代码就会自行编写），并指定了测试的框架，代码就会得到最少的审查。
1b) 我会审查测试，以检查是否存在过拟合、作弊等情况。
2) 代码中的注释可以充斥着大语言模型（LLM）的风格。我不在乎。
3) 但是 Markdown 文件，无论是人还是大语言模型阅读，都必须经过大量删减、编辑，并采用人类的语言风格。
简单来说，大语言模型，这些为生成文本而生的机器，无法在没有旁枝末节、跑题、无关内容、重复、遗漏、常见的风格弊病（如过度使用陈词滥调）、历史遗留的冗余、过度解释和定性空话的情况下，呈现出线性流畅的相关事实。换句话说，它们无法直截了当地讲述。
我只有一个受众，那就是人。有些人自己阅读文本，有些人则将其交给大语言模型，并期望得到连贯的回复。这两个群体都应该得到清晰的信息，无论对他们还是对我来说，都是如此。
大语言模型在直截了当地讲述方面，目前还未达到要求。
查看原文
In the context of side projects, I've come to these rules for code and text:<p>1a) Code gets minimal review so long as I've architected the solution, built around the correct data structures (I've heard the code writes itself if the data structure is correct), and have specified the shape of the tests.<p>1b) Tests I review to check for overfitting, cheats, etc.<p>2) Comments in code can be chock-full of LLM-isms. Don't care.<p>3) But the Markdown files, which may be read by a person or an LLM, those must be heavily redacted, edited, and put into a human voice.<p>The simple reason is that LLM's, machines built to generate text, are incapable of presenting a linear flow of relevant facts without sidebars, tangents, irrelevancies, duplication, gaps, well-known style fails like overuse of stock words and phrases, layers of historical cruft, over-explanations, and qualitative fluff. In other words, they can't tell it straight.<p>I have only one audience, people. Some of them read the text themselves, others give it to an LLM and expect a coherent response. Both groups deserve, for their sake and mine, to get clear information.<p>LLM's are not there yet on telling it straight.