写作与思考2015edge.org
这个观念该退休了：把科学知识写成“文献”
Retire This Idea: Scientific Knowledge Structured as “Literature”
导读
这篇文章批评把科学知识固定成“文献”的传统观念，主张知识应像持续更新、可协作的系统一样被组织和修订。对写作者而言，它值得一读，因为它迫使我们区分“记录工作”与“呈现知识”，并重新思考文章如何被引用、修订和取代。
可以直接用的写作要点
- 01
先想清楚写作的激励和目标：很多文章是阶段性成果，追求“完成并发布”往往比无限修订更有效。
- 02
使用软件/敏捷类比时要谨慎：开发方法和发布机制是两回事，并非所有写作都适合持续在线更新。
- 03
把过程记录和知识呈现分开：可以先写工作日志或实验记录，再另写综述或摘要来提炼结论。
- 04
为修订设计可追踪的版本：明确哪条结论被更新、哪篇文献取代哪篇，避免读者把旧版本当最终答案。
HN 评论精选
学术写作有结项激励，综述与定稿是必要机制，不能简单照搬代码的永久可编辑模式。
文章没有理解学术界的激励机制。很多时候，把一项研究“做完结项”才是目标，因为优秀学者有一长串想做的事；很少有人愿意永远陷在一篇论文不可避免的问题里。这也是综述论文存在的原因：总结某一时点的知识状态、前人成果和已发现的死胡同。也许我没抓住作者要点，但把论文这种“生产单元”产出并完成是有用的；我不确定让文档永远可编辑能带来什么。科学文献不是代码。
jgmjgm查看英文原文
I what is missing from the article is an understanding of the incentives of academics. Quite often putting a piece of research "to bed" is the goal. Why? Because any good academic has a long list of things they want to get to. Very few people want to get mired in the (inevitable) problems that arise in a paper for eternity. This is why there are review papers that summarize the state of the knowledge at a given point. These articles are useful summaries of what came before and what (at least appear to be) dead ends were found. Maybe I'm missing some point with the author's article. But getting units of production out and finished (i.e. papers) is a useful process. I'm not sure what would be gained by keeping documents editable forever. Scientific literature is not code.
软件类比要分清开发方法与发布机制，不能把“敏捷”等同于持续更新。
文章用软件开发来类比科学出版，但这个类比并不正确。“敏捷”是一长串软件流程的总称，迭代开发早在软件工程初期就有；现代所谓敏捷常被滥用。敏捷方法与“空中差分更新”这种部署方式关系很小——Python、Ruby、gcc 等都没有自动更新，难道就不敏捷？开发方法和部署机制是两回事。
dalke查看英文原文
While not essential to the argument, it uses software development as an analogy for scientific publications. Unfortunately, that analogy isn't correct. > Just as the software industry has moved from a "waterfall" process to an "agile" process—from monolithic releases shipped from warehouses of mass-produced disks to over-the-air differential updates—so must academic publishing move from its current read-only model and embrace a process as dynamic, up-to-date, and collaborative as science itself. "Agile" is one name for a long line of software processes, which includes XP, RAD, and Unified Process. Iterative development stretches back to the dawn of software engineering. In modern practice, "agile" seems used for anything which is even a touch more flexible than the strictest of waterfall. Take your process, add a standup meeting or story cards, and poof, you're agile. Nor is "agile" development tied so closely to 'over-the-air differential updates'. The development methodology has very little to do with deployment. Perhaps the easiest example is to look at the various language implementations (Python, Ruby, gcc, etc.). They don't have auto-update. So I guess the question is, are they agile? > But academic literature makes no distinction between citations merely considered significant and ones additionally considered true. What academic literature needs goes deeper than the view of citations as kudos and shout-outs. It needs what software engineers have used for decades: dependency management. > A dependency graph would tell us, at a click, which of the pillars of scientific theory are truly load-bearing. I have no idea of how to make this work. I give as an example the Kabsch algorithm algorithm for RMSD minimization of two molecular structures (see http://en.wikipedia.org/wiki/Kabsch_algorithm ). The original paper contained an error that sometimes resulted in a sign error. This was fixed in a subsequent paper. Most cite the first paper, because it introduced the core concepts. Some cite the first paper but actually implement the correct solution from the second paper without even realizing there was a problem, because they combined the principles with their own mathematical understanding rather than duplicating the exact steps in the paper. Still others cite both papers. How does this hypothetical dependency graph incorporate those details? That paper is a simple one, because it really is a single algorithm for a single goal. Many papers introduce multiple concepts, solutions, or observations. It can well be that one of them was wrong while the others were correct, interesting, and influential. For example, in one paper I read the authors did not include a test case because, they said, the source material was invalid. I investigated, and discovered that it was due to a transcription error by the authors of the paper, and not a problem in the source material. The addition of that one data point would have no material impact on the overall paper. But it's still wrong. How does his hypothetical dependency graph capture the multitude of disprovable points in the average paper? How does it capture what the "pillars" are? Bear in mind that there's been over 50 years of attempts to do this, so I think there's no easy answer.
科学写作应公开数据、开放获取，并建立清晰的修订/反驳链接机制。
我觉得当今科学最荒谬的两点（我在这一行）：1）大量论文发表时没有底层数据；为什么没有简单系统要求上传所有实验数据，数据无法验证就至少是可疑研究，按现行框架应自动拒稿。2）付费墙和整个出版系统：多数科学由公共资金资助，理应免费向所有公民开放。我认为“发表并改进”模型可以，但如作者所说，论文“撤稿/修订”系统很奇怪；说“我在 X 论文里错了，如 Y、Z 所示”也不简单，应该有个类似 HTTP 重定向到 X/Z 的机制。也许我不知道，但为领域建一个大型 Dung 式论证系统（X 攻击 Y，Z 辩护 Y）会很有意思。
kriro查看英文原文
The two things that are most ridiculous about science in this day and age (imo, I work in the field) 1) Tons of papers get published without the underlying data. Why is there no easy system in place where I have to upload all data from experiments etc. and if the data isn't there to be verified -> questionable research at best (or in the current framework of science autoreject) 2) Paywalls and the entire publishing system. Most science is state funded in some way, shape or form and as such it should be available for free for all citizens. I think publish and improve is an ok model but there's some issues like the author says it's pretty strange how the whole redacting a paper system works. It's also nontrivial to say "well I was wrong in my paper X as shown in papers Y and Z" (some sort of HTTP redirect to X/Z would be in order) Maybe I'm just not aware of it but it would also be interesting to have a huge Dung-style argumentation system of papers for fields (X attacks Y, Z defends Y etc.). Might be a neat project if it doesn't exist.
论文是工作记录而非知识表示；可用综述加版本控制做知识更新，但需专门文档结构。
问题在于作者试图创造一种知识的“表示”，而研究论文更像是对已完成工作的“记录”。他的方法可能很适合元研究实验：定期综述某主题的文章，生成发现摘要；发现一变就做一次 git commit，随时间追踪。类似维基百科但为研究设计。挑战在于设计最适合分布式版本控制（pull request 等）的文档结构，并能提供历史视角；比如回顾 1960 年代 DNA 研究，按年代为每个关键发现做 commit。要让这种结构运作，恐怕得为科学知识专门设计一种编码语言。
anifow查看英文原文
It seems the problem is that the author is trying to create a representation of knowledge, whereas research papers are more of a logging of work done. His approach may be a perfect fit for an experiment in meta-research. You could run periodic reviews of articles released in specific topical areas and create summaries of the findings. Any time those findings change, its a git commit, and you can track this change over time. It's something like Wikipedia, but designed for research. I would not be surprised if this already exists. I see a challenge in figuring out the document structure which will be the most conducive to distributed version control (pull requests, etc), and can provide some insights on a historicalbasis. For example, you could run these summaries retrospectively, say looking at DNA research in the 1960s, and do a separate commit for every key finding through the years. It seems to me that you would pretty much have to specify a specialized coding language for scientific knowledge for this structure to work.
同类还值得读
不要想好再写，要写来思考
Don’t think to write, write to think
这篇短文主张不要把写作当成思考完成后的记录，而要把写作本身当作思考的工具：动笔的过程会逼出想不清楚的地方。
写作与思考2022 · 553 分 · 145 评4 条写作要点编辑精选写作即思考：学会自信地写作
Writing Is Thinking: Learning to Write with Confidence
这是一篇讲“写作即思考”的博客：作者认为写作不是把想好的东西誊写出来，而是借助写作本身把想法想清楚，因此写作者应当建立信心、敢于先写烂稿。
写作与思考2019 · 529 分 · 83 评4 条写作要点编辑精选如何用写作来思考
How to think in writing
这篇文章讨论的是「用写作来思考」：作者认为写作不只是把想清楚的东西表达出来，更是想清楚本身的工具——文字落在纸上，你才有机会看见自己思路里的跳跃、含混和漏洞。
写作与思考2024 · 424 分 · 120 评4 条写作要点编辑精选写作，帮你逃离默认的人生设置
Write to Escape Your Default Setting
文章的核心主张就写在标题里：写作是帮你逃离「默认设置」的手段——日常的思维和表达都有惯性默认的默认模式，而落笔能逼你跳出来，重新看清自己到底在想什么、要说什么。
写作与思考2025 · 407 分 · 93 评4 条写作要点编辑精选写作就是思考
Writing is thinking
文章以“写作即思考”为题，讨论写作不只是把已有想法记录下来，而是帮助澄清、组织和推进思考的过程。
写作与思考2025 · 330 分 · 128 评4 条写作要点编辑精选