企业官网建设流程全解析

把「我有个想法」变成「读者能理解、能运用、能质疑的文章」，是写作中最难的一段路。本指南以 WriteEssay 工作流 为骨架，系统拆解 ljg-writes（写作引擎）从判断交付尺度、提炼观点、选择案例，到引入概念、检查反例、修改中文与保存验证的完整流程，并结合 SKILL.md 中的成文契约、姿态语言与输出约束，说明每步检查在仓库中的实际定义与落地方式。读完本文，你将掌握一套可复用的写作检查清单，能独立把一个观点写成逻辑递进、结论清楚、边界分明、默认 1000–1500 字的中文文章。

一、工作流定位：WriteEssay 在整个技能中的角色

ljg-writes 是 ljg-skills 技能集里的写作引擎，README 中对其定义是「把一个观点写成可理解、可迁移、经得住反例的中文文章」。它的触发场景写在 SKILL.md 的 frontmatter 里：写文章、优化思想内容、展开观点、改写成逻辑递进的中文；它明确 NOT FOR 普通摘要、事实查询或结构风洞（后两者分别交给其他技能）。当前版本为 8.0.1，user_invocable: true，即用户可直接调用。

技能内部采用「SKILL.md 定义契约 + Workflow 落地执行」的分工模式：

SKILL.md 的 Workflow Routing 表格只有一行：WriteEssay对应「写文章、优化思想内容、展开或重写观点」这一触发条件，文件为Workflows/WriteEssay.md。执行时要求完整读取工作流，分析和检查在内部完成，正文按内容需要展开，不逐项展示写作步骤——这决定了整套方法论是「内化的检查清单」，而不是「写给读者看的文章模板」。

ljg-writes 的写作标准还被其他技能继承复用。例如 ljg-classic 的古文精读流程 明确要求读取ljg-writes/SKILL.md与Workflows/WriteEssay.md，并继承「条件—机制—结果、迁移、边界」的写作检查，但不显示「解读边界」等写作脚手架。这说明 WriteEssay 不仅服务独立文章写作，也是整个技能集共享的「思想解释引擎」。

二、Step 0–1：先定交付尺度，再写清判断

判断交付尺度

写作的第一步不是动笔，而是确认交付尺寸。默认写 1000–1500 字；用户明确要短改、金句、标题或某个长度时，按要求交付，不为完成长文检查而额外添加案例或观点。这一点与 SKILL.md 输出约束中的「总量默认 1000-1500 字；用户明确要短改、金句或标题时服从用户长度」完全对应。

同时要确认输入里存在一个可争辩的观点（claim，而非主题）。只有主题、没有判断时，先从上下文提取一个候选判断；只有当候选判断之间会导向完全不同的文章时才向用户提问。改写已有文字时，先保住原意、事实和语气，不擅自加强结论——这条规则在 SKILL.md 的「姿态与语言」中被重复强调：「改写先保住原意、事实和语气」。

用工作句检查关系

Step 1 要求先用一句普通话写清观点，内部可以用固定句式检查关系是否明确：

在 [条件] 下，[A] 通过 [机制] 改变 [B]，产生 [结果]。

这句话只用于检查观点，不直接写进正文。分析案例时可以修正其中的条件、机制或结果；关系还说不清，就先继续梳理，不要急着下笔。这套「条件—机制—结果」三元组是整个 ljg-writes 的核心词汇，后续所有步骤（案例选择、概念引入、反例检查、成文自检）都在围绕它转。

三、Step 2–3：选一个能走的案例，找出旧解释的不足

选择容易理解的案例

选一个背景容易理解、关键因果关系完整的案例，让读者看见「发生了什么、怎样发生、结果如何」。下笔前检查案例与观点的对应关系：

抽象角色 A = 案例中的谁或什么 抽象角色 B = 案例中的谁或什么 关键作用 = 案例里实际发生的动作 可见结果 = 读者能观察到的变化

对应不上就换案例。简化案例时有一条硬约束：删掉某个反馈、时序或约束就会改变结论，那一项必须保留。这与 SKILL.md Gotchas 中的条目一致：「简化案例时保留关键反馈、时序和约束。删去某项会改变结论，就保留它或换一个案例。」

案例策略上优先围绕同一个案例解释，减少读者反复熟悉背景的负担；不足以说明关键关系时，再补充相关案例。需要注意边界：案例说明的是关系「如何发生」，普遍性的事实主张还需要证据支撑；假设案例必须让读者知道是假设，不能写成亲历或已发生的事实——这正是 ljg-paper 的阅读指南 中「自拟示例要对应论文关系，并自然说明它是帮助理解的例子」一脉相承的纪律。

检查原有解释有什么不足

先考虑读者可能已有的解释：按这个解释，读者会怎样判断、采取什么行动、预期什么结果。检查它是否存在以下问题：

• 解释不了案例中的某一步；
• 做出了错误预测；
• 把本应区分的情况当成了一种；
• 虽然成功，却忽略了某种代价。

关键纪律是：这些问题必须能从案例、事实材料或逻辑中找到，不能为了引出概念而编造。SKILL.md Gotchas 同样警告「不为引出概念编造失败」。若原有解释已经够用，直接跳到 Step 6 说明完整关系即可，不必为凑流程安排一次「旧解释失败」。

四、Step 4–5：引入所需概念，继续追问未清之处

引入概念的四个检查

找出能解释当前问题的概念、区分或关系。先用日常话说明它的意思，再回到案例，看它怎样改变解释、预测或行动；需要准确指称时再给出术语。检查四件事：

1. 为什么需要这个概念？
2. 它具体区分或改变了什么？
3. 用它重新分析案例，解释、预测或行动有什么变化？
4. 还有什么没有解释清楚？

这里有一个容易混淆的陷阱：概念改变的是我们对案例的理解；只有行动或条件随之变化，实际结果才可能改变。把「理解的变化」误写成「现实结果的变化」，是 Step 9 内容检查中会专门排查的失误。SKILL.md 的成文契约把这条写成「关系可运行」：读者能说清谁在什么条件下作用于谁，产生什么结果。

几个陌生概念挤在一句话里时，按理解所需的先后顺序展开：先解释下一步需要用到的概念，结合案例说清，再决定是否继续补充。

继续追问尚未解释清楚的地方

必要时继续分析，直到关键关系清楚。可以问：

• A 怎样导致 B，中间是否遗漏了什么？
• 判断依赖什么前提，前提变化后哪里先失效？
• 结果由 A 引起，还是另一个变量在起作用？

继续分析应让解释更准确、更具体，或让适用条件更清楚；只换成更抽象的词时，回到事实和具体过程。结论可以符合直觉，也可以停在现有材料无法回答的问题上。当多个因素相互影响、同时发生或共同改变结果概率时，可以并排展示过程、列出状态变化，或使用两个相关案例说明它们怎样共同影响结果——SKILL.md Gotchas 特别强调这类场景不要强行写成先后相接的单线故事。

五、Step 6–7：说明完整关系，再检查迁移与反例

说明完整关系

概念解释清楚后，回到最初案例，检查整个过程是否连贯：

起始条件 -> 各因素如何作用或相互制约 -> 可观察的变化 -> 最终结果

说明每个概念解决了什么问题、它们之间有什么关系，以及这些分析如何支持或修正最初判断。避免逐段设置悬念，却始终没有把来龙去脉讲清楚。之后回头检查 Step 1 的工作句，根据分析修正或补充机制、条件与边界；原句已经准确时可以保留，不为显示分析有效而强行改写。

成文前的两次内部测试

1. 迁移测试：换掉人物、行业和表面材料，用同一关系解释一个差异较大的新现象。
2. 反例测试：找一个看似相同、实际不符合该关系的场景，说清差异发生在哪个条件。

如果只能复述原案例，就检查是否把表面相似当成了因果关系；找不到反例时，继续检查判断的适用条件，不靠增加同类例子掩盖问题。迁移与反例不必都写进正文，但正文至少留下一个迁移依据或一个失效边界。SKILL.md 的成文契约将这条总结为「判断可迁移」：换掉人物和材料，关系仍成立；同时能指出一个失效边界。同样重要的是「案例不能替代事实证据」——涉及外部事实时，给出证据或准确限定适用范围。

六、Step 8：写成连贯的文章（含可用手法）

阅读顺序与段落组织

根据内容决定阅读顺序：可以先说判断，再解释原因；也可以从具体事实或案例开始，让判断随解释自然出现。已有解释的不足确实重要时才展开，不必每篇都安排「直觉出错、引入概念、得到新发现」的故事结构。

段落层面：

• 每段围绕一个意思展开。首句可以是判断、事实、动作，也可以承接上文；后面的句子把意思说完整。
• 表达判断时，直接说清主张，再说明理由和适用条件；判断在文章中的位置按内容决定。
• 事实否定和必要辨析可以保留，但避免「先否定一种说法、再揭示另一种说法」来制造转折。SKILL.md「姿态与语言」中有同款约束：「避免用『不是……而是……』制造转折；事实否定、必要辨析和边界可以保留」。
• 段落之间要有内容上的联系：上一段说清了什么，下一段为什么需要接着谈？缺少这层联系时，调整顺序或补上推理，不靠「更重要的是」等过渡语掩盖跳跃。

结尾写到问题得到回答即可：可以指出一个实际后果、用法或限制；不必额外制造金句、翻转或宏大感悟。SKILL.md Gotchas 同样提醒「观点已经清楚时，直接展开；不为追求深刻制造反问、翻转或悬念」。

可用手法清单

按需要使用，不要求逐项出现：

• 前后比较：回到同一个案例，比较新解释与原解释的差异。
• 问题标题：下一节确实回答一个具体问题时，用读者会问的话做标题。
• 过程或状态表：文字难以说明多个因素的关系时，直接展示过程与前后状态。
• 类比：用读者熟悉的事物帮助理解；交代对应关系，不让类比代替证据。
• 就近说明条件：重要限制放在相关主张附近，方便读者判断。

成文后的四个追问

成文后，确认那个具体的人只凭正文就能回答：

1. 文章提出了什么判断，为什么成立？如果讨论了旧解释，它哪里不够？
2. 关键概念在现实中指什么，分别解释了什么？
3. 什么条件通过什么机制产生什么结果？
4. 这个判断还能用到哪里，或到哪里会失效？

答案需要作者额外解释时，回到正文补充必要线索，不直接把内部分析清单贴进文章——SKILL.md 的「成文契约」明言「概念、关系、案例、迁移等检查项目留在内部，不直接用作文章目录」。

七、Step 9：先检查内容，再修改中文

内容检查

• 有没有准确呈现原有解释，还是把它简化成一个容易驳倒的说法？
• 每个新概念是否有必要，是否解释了具体问题？
• 概念加入后，解释、预测或行动有何不同？有没有把理解的变化误写成现实结果的变化？
• 有没有为凑层次制造问题，或在一句话里塞入多个陌生概念？
• 关键关系是否完整，案例、证据、适用场景与边界是否清楚？

中文修改的四个层面

再通读全文修改中文，遵循 SKILL.md 的「姿态与语言」，重点检查：

• 意思与搭配：词语是否准确，主语和动作是否搭配，指代是否清楚？换近义词仍然别扭时，按原意重写整句。
• 语气与分寸：是否符合文章用途？有没有强行口语化、故作深刻，或把推测改成断言？保留必要限定，不凭空增加置信度数字（SKILL.md 对应规则：「百分比需要数据、计算或明确的估计依据」）。
• 句子与段落：因果和条件是否交代完整？有没有切得过碎的短句、层层嵌套的长句，或连续套用的排比和转折？按意思调整，不按字数和次数配额修改。
• 全文衔接：连续读下来是否顺畅？段落之间是否接得上，术语、比喻和语气是否一致？局部修改破坏了上下文时，重写整段。

已清楚自然的地方可以保留。只保存修改后的完整稿，不从两稿里逐句挑选、拼成一篇。最后确认文章确实把判断解释清楚，让读者知道如何使用、何时需要谨慎；不强求反直觉结论。这对应 SKILL.md 的「最后检查」：连起来读一遍，像一个人把事情想清楚后写出的中文吗？读者能否用这个判断理解一件新事，并知道它有什么限制？

八、Step 10：按 Org 与 Denote 契约保存并验证

WriteEssay 的保存环节严格遵循 SKILL.md 的输出约束，面向 Emacs Denote 生态：

• 字数：总量默认 1000–1500 字，用户指定长度时服从用户。
• 格式：Org 加粗使用单星号（*text*，不是**），标题从*开始且不跳级；图表只用纯 ASCII 字符（与 CLAUDE.md 中「Allowed / Forbidden 字符表」一致：允许+ - | / \ > < v ^ * = ~ . : # [ ] ( ) _ , ; ! ' "，禁止 Unicode 制表符类字符）。
• 时间戳：执行date +%Y%m%dT%H%M%S与date "+%Y-%m-%d %a %H:%M"两个命令取得时间值。
• 文件名：~/Documents/notes/{时间戳}==z--{标题关键词}__write.org。
• 文件头模板：

#+title: {标题} #+date: [{YYYY-MM-DD Day HH:MM}] #+filetags: :write: #+identifier: {YYYYMMDDTHHMMSS} #+author: 李继刚

初稿完成后，先检查观点与证据，再通读修改中文；只保存最终稿，不把内部分析表和检查清单写入笔记。保存后回读全文，检查字数、Org 标题、文件名与 identifier，再运行Denote 接受检查和org-lint验证。这些约定同样见于 CLAUDE.md 的 Shared Conventions（Org-mode 输出技能共用{timestamp}--{title}__{type}.org命名与~/Documents/notes/输出目录），是 ljg-writes 与 ljg-paper、ljg-plain 等技能共享的写入规范。

九、整个工作流的骨架与检查清单

把 Step 0–10 压缩成一张可执行的检查表，便于在实际写作中逐项对照：

这套流程的底层逻辑可以从 SKILL.md 的「怎样解释一个观点」一节读出完整路径：

具体案例 -> 原有解释 -> 解释不清的地方 -> 引入所需概念 -> 重新分析案例 -> 说明完整关系 -> 检查其他场景与边界

这条路径用于帮助分析，正文可以先说判断、也可以从案例展开；原有解释已经够用时直接说明原因，不必安排一次失败。最终交付时，正文必须给出足够线索，让读者能够指出关键概念在现实中指什么、复述「条件—机制—结果」、并说出一个适用的新场景或一个失效边界——这正是 ljg-writes 区别于「堆砌辞藻的写作」的核心：它把文章当作一个可运行、可检验、可迁移的思想装置来生产，而 WriteEssay 工作流就是这套装置的质量检查线。