需要把一个观点写成可理解、可迁移、经得住反例的…

把一个观点展开为可理解、可迁移、经得住反例的 1000-1500 字中文文章，并按 Org/Denote 规范保存。

适用场景

解决思路

1. 写文章、优化思想内容、展开或重写观点时，执行 `Workflows/WriteEssay.md` 工作流，并完整读取该工作流。
2. 分析和检查在内部完成，正文按内容需要展开，不逐项展示写作步骤。
3. 让一篇文章围绕一个核心判断展开；其他机制、反馈和限制都用来帮助说明或修正这个判断。
4. 内部检查“概念可指认”：确保关键抽象词都能用普通话解释，并对应到具体事物或现象。
5. 内部检查“关系可运行”：确保读者能说清谁在什么条件下作用于谁，产生什么结果。
6. 内部检查“案例可映射”：确保场景中的角色、条件和因果关系能对应原观点。
7. 内部检查“判断可迁移”：换掉人物和材料后关系仍成立，并能指出一个失效边界。
8. 将“概念可指认、关系可运行、案例可映射、判断可迁移”只用于内部检查，不直接用作文章目录。
9. 正文给出足够线索，让具体读者读完后能指出关键概念在现实中指什么。
10. 正文给出足够线索，让具体读者能复述“条件—机制—结果”。
11. 正文给出足够线索，让具体读者能说出一个适用的新场景或一个失效边界。
12. 选择一个容易理解、关键因果关系完整的案例作为优先解释入口。
13. 从读者可能已有的解释出发，检查它会怎样判断、预期什么结果。
14. 若原有解释解释不了某一步、预测有误或忽略某种代价，就把这个具体问题说明白。
15. 引入能解决当前问题的概念，用普通话说明它增加了什么区分，再回到同一个案例，看解释或判断发生了什么变化。
16. 如果还有解释不清的地方，再继续补充概念和分析。
17. 先说明概念的意思和用处，需要准确指称时再给出术语。
18. 按“具体案例 -> 原有解释 -> 解释不清的地方 -> 引入所需概念 -> 重新分析案例 -> 说明完整关系 -> 检查其他场景与边界”的路径帮助分析；正文可先说判断，也可从案例展开。
19. 原有解释已经够用时，直接说明原因，不必安排一次失败。
20. 解释结束时，让读者看清各概念之间的关系，以及它们如何支持或修正最初的判断。
21. 写得清楚、准确，语气平实；可以有自己的判断和节奏，不必句句用力。
22. 心里有一个具体的人，根据他的知识和文章用途选择说法；自然中文可口语或书面语，不强行加聊天口吻。
23. 改写先保住原意、事实和语气；已经自然的句子可以保留。
24. 某个词不贴切时，先看它的意思、搭配和语气是否合适；换近义词仍别扭，就按整句意思重新组织。
25. 简洁以意思完整、搭配自然为准；“讨论”不必一律改成“聊”，说明因果、条件和程度的词该留就留。
26. 抽象表述让人费解时，写清谁做了什么、发生了什么变化。
27. 需要术语就准确使用；比喻应帮助理解，同一段不要混用几套比喻。
28. 计算机类比只在贴合问题、读者也熟悉时使用。
29. 表达判断时，直接说清主张，再说明理由和适用条件。
30. 判断在文章中的位置按内容决定，段落也可以用事实、动作或承接上文的句子起笔。
31. 避免用“不是……而是……”制造转折；事实否定、必要辨析和边界可以保留。
32. 句子长短服从意思；因果相连的内容可以放在一个完整句子里，需要停顿时再断开。
33. 连接词用来交代真实关系，不按词表一概删去，也不靠“因此”“更重要的是”替代推理。
34. 用具体内容说明理由，不宣告“接下来深入剖析”。
35. 少用连续排比、刻意对仗和每段末尾的警句；发现节奏反复时，重写整段，不按句式次数配额写作。
36. 不确定时，说明哪些有依据、哪些是推测、还缺什么信息。
37. 保留必要的“可能”“通常”“在这些条件下”；百分比需要数据、计算或明确的估计依据。
38. 第一人称经历只写真实材料，不编造亲历，也不替一个群体宣称共同感受。
39. 最后连起来读一遍，检查是否像一个人把事情想清楚后写出的中文，词语是否贴切、句子是否顺畅、前后是否接得上。
40. 局部换词解决不了的问题，重写整句或整段。
41. 再检查：读者能否用这个判断理解一件新事，并知道它有什么限制。
42. 继续分析应让解释更准确，或让适用条件更清楚；只换成更抽象的词并没有增加理解。
43. 不为引出概念编造失败；原有解释的不足必须能在案例、材料或逻辑中找到；解释已经够用就不要继续加概念。
44. 简化案例时保留关键反馈、时序和约束；删去某项会改变结论，就保留它或换一个案例。
45. 多个因素相互影响、同时发生或共同改变结果概率时，可以并排展示过程、列出状态变化，或使用两个相关案例，不强行写成先后相接的单线故事。
46. 案例说明关系如何发生，事实主张需要证据支持；案例中的角色与因果对应不上观点时，换掉它。
47. 一个案例讲得顺，不代表观点到处成立；用差异较大的场景和反例检查。
48. 正文应把关键关系说完整；“概念、关系、案例、迁移”等检查项目留在内部。
49. 观点已经清楚时，直接展开；不为追求深刻制造反问、翻转或悬念。
50. 用户只要短改、金句或标题时，按用户长度交付，保留核心意思和必要限定；不为凑齐长文流程额外添加案例或观点。
51. 默认输出总量 1000-1500 字；用户明确要短改、金句或标题时服从用户长度。
52. Org 加粗使用单星号，标题从 `*` 开始且不跳级。
53. 图表只用纯 ASCII 字符。
54. 取得两个时间值：`date +%Y%m%dT%H%M%S` 与 `date "+%Y-%m-%d %a %H:%M"`。
55. 文件名设为 `~/Documents/notes/{时间戳}==z--{标题关键词}__write.org`。
56. 文件头写为： #+title: {标题} #+date: [{YYYY-MM-DD Day HH:MM}] #+filetags: :write: #+identifier: {YYYYMMDDTHHMMSS} #+author: 李继刚
57. 初稿完成后，先检查观点与证据，再通读修改中文。
58. 按整段的意思和衔接选择表达，不把两稿的漂亮句子逐句拼接；只保存最终稿。
59. 保存后读回文件，验证 Denote 接受与 `org-lint`，再报告路径。

适用边界 · 注意事项

• 普通摘要不要用。
• 事实查询不要用。
• 结构风洞不要用，改用 `ljg-structure`。