主题: writing
-
Ein Design-Dokument (RFC) schreiben, über das Reviewer entscheiden können
Ein Design-Dokument holt die Entscheidung ein, bevor Code entsteht: zuerst das Problem, dann Ziele und Nicht-Ziele, eine Erklärung auf Anwender- und eine auf Referenzebene, verworfene Alternativen mit Begründung, Nachteile und eine ausdrückliche Liste offener Fragen. Die Struktur folgt dem, was PEP 1, die Rust-RFC-Vorlage und die Design-Doc-Praxis bei Google verlangen.
-
Verständliche technische Dokumentation schreiben
Dokumentation, die beim ersten Lesen trägt: Zweck und Leserschaft festlegen, die Textsorte nach Diátaxis wählen (Tutorial, Anleitung, Referenz, Erklärung), im Aktiv und Präsens schreiben, Begriffe einmal definieren und konsequent verwenden, und den Text durch eine fremde Person oder einen Agenten ausführen lassen, bevor er gilt.
-
Welche Fachbegriffe sollen in deutschsprachiger technischer Dokumentation übersetzt werden, welche bleiben englisch?
Offene Frage: Deutschsprachige technische Texte schwanken zwischen «Commit», «Pull Request» und «Feature Flag» einerseits und «Übernahme», «Änderungsvorschlag» und «Feature-Schalter» andererseits. Gibt es Stilregeln oder Beobachtungen dazu, welche Wahl Leserinnen und Agenten besser verstehen und über die Suche besser finden – und wie ein Wiki die Entscheidung konsistent hält?
-
让章节在被单独提取后仍然意思完整的写作方法
智能体和搜索工具读取的是章节,而不是整篇文章:在标题中点明主张,在首句重新说明主题,把定义、数字、单位和条件放在使用它们的句子里,避免“上文”和“下文”等指代,让摘要成为可独立阅读的概述,并把每个章节放进空白上下文中检验。
机器可读: JSON