这是诊断,不是重写。目标是告诉用户"这篇稿子需要哪种修改,先改哪里",不是 把稿子按自己的风格重写一遍。
Scanned 9/1/2026
Install to Claude Code
npx -y skills add open-octo/octo-agent --skill structural-diagnosis --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Structural Diagnosis?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/open-octo-structural-diagnosis)More formats (shields.io, HTML) on the badges page.
---
name: structural-diagnosis
license: Apache-2.0 (adapted from haowjy/creative-writing-skills, skills/story-review/resources/editorial-review.md + developmental-edit.md; complete terms in LICENSE.txt)
description:
诊断一篇长文/文章/报告的结构性问题——论点承诺是否兑现、论证链条是否完整、
段落功能是否清楚、节奏是否合理,给出按影响力排序的修改建议。Use when
用户说"帮我看看这篇文章逻辑通不通""这篇文章结构上有什么问题""从整体上
诊断一下这篇稿子""哪里需要重新组织"。这是诊断,不是逐句改写——如果用户
要的是具体段落润色,用 `line-polish`;要多角度读者反馈用
`reader-simulation`。
metadata:
origin: 编辑评审的"读的顺序"(承诺→结构→语气→段落→表层)、编辑备忘录结构
(总体诊断+优先级队列+具体批注+修订顺序)、"区分结构问题与执行问题"、
"保护作者原声、存疑就问不要替作者拍板、只诊断不代写"这套编辑纪律,
改编自 haowjy/creative-writing-skills 的 skills/story-review/resources/
editorial-review.md 与 developmental-edit.md(Apache-2.0);原文是面向
小说/虚构写作的编辑方法论,已把"情节/人物弧光/场景/类型契约"等虚构
概念替换为"论点/论证链/段落/文体承诺"等非虚构写作概念
---
# Skill: structural-diagnosis
这是诊断,不是重写。目标是告诉用户"这篇稿子需要哪种修改,先改哪里",不是
把稿子按自己的风格重写一遍。
## 怎么读
**先通读全文再下笔写任何一条意见。** 第一遍读的是"读起来的感受":哪里
读进去了、哪里注意力开始飘、哪里读着读着突然觉得累或者绕。不要在第一遍
就开始批注——很多看起来有问题的地方,往后读会发现是有意为之;很多真正的
问题,只有读完全文回头看才能看出来。
第二遍带着诊断的眼光读。这时候已经知道这篇稿子想做什么,问题变成了:
哪里做到了,哪里没做到。
## 关注顺序
按这个顺序读,不要跳着来(除非用户明确要求只看某一层):
1. **读者承诺**:开头几段/引言给读者立下了什么期待——要解决什么问题、
给出什么视角、论证到什么结论?后面的内容有没有兑现这个承诺,还是
悄悄漂移到了别的方向?
2. **论证结构**:核心论点、论据之间的因果关系、节奏、每个部分/段落的
功能。这篇稿子撑得起自己的分量吗,还是结构在向读者要求太多耐心?
(对应虚构写作里"发展性编辑"关心的层面:前提、因果、节奏、场景
必要性。)
3. **语气与文风**:视角是否稳定、语气是否统一、是否有这篇稿子该有的
"自己的声音",还是读起来像"正确但没有个性的通用文字"?
4. **段落层面的执行**:清晰度、段落之间的推进、重复、句子结构、过度
解释、该留白的地方却说破了。有没有反复出现、削弱说服力的模式?
5. **表层问题**:语法、标点、用词一致性、格式。这一层只标"反复出现的
模式",不逐条列——单个错字不值得写进结构诊断报告。
**除非用户明确要的是表层校对,不要一上来就挑错字。** 表层问题确实重要,
但初稿失败的原因通常更大。一份结构诊断报告如果开头就是"这里少了个逗号",
而这篇稿子的论证结构本身是断的,那是在浪费作者的注意力。
## 先分清:结构问题 vs 执行问题
一个段落表达的是对的意思、但表达得笨拙——这是执行问题,需要重写,不需要
删掉。一个段落表达的是不该在这里出现的意思,或者这段完全没有起到结构性
作用——这是结构问题,再怎么润色文字都解决不了。
先看能看到的最大单元:整体论证有没有兑现开头立下的承诺?然后往下看到
章节层面、段落层面。高层级的问题会连累低层级的诊断——如果整体结构是断的,
在这个基础上诊断段落层面的问题是不可靠的。
## 诊断维度
- **承诺与兑现**:开头教会读者期待什么?后面的内容有没有对得上?
- **因果链**:事件/论点之间是互相推动、互相制约的关系,还是仅仅按顺序
排列?如果段落顺序打乱了也不影响理解,说明这是"罗列",不是"论证"。
- **段落功能**:每个段落结束时,有什么发生了变化——读者的认知、态度,
或者论证向前推进了一步?如果什么都没变,这段是可以删或者合并的候选。
- **节奏**:哪里推进太快、哪里拖沓、哪里持续同一强度让人麻木、哪里持续
平淡让人走神。
- **信息设计**:什么被保留、什么被揭示、什么被重复、什么被解释了?读者
手里握着的问题是不是在往前拉着读,还是所有悬念都太早被解开了?
- **文体承诺**:这篇稿子有没有兑现它承诺的那种阅读体验?一篇科普文章
如果从不让读者跟着推理过程走,就是没兑现科普该有的契约;一篇论辩文章
如果从不给出反方观点的正面处理,也是一样。
## 诊断报告结构
- **总体诊断**:这份稿子需要哪种修改——不是列出所有能改进的地方,而是
找出最主要的问题。一篇需要重新组织结构的稿子,应该听到"结构需要重来",
而不是收到五十条不会再有意义(因为结构一改这些段落可能都不在了)的
段落级意见。
- **优先级队列**:影响力最大的问题排在最前面,附理由。按"对读者体验的
损耗"排序:什么最拖累阅读体验?
- **主要意见**:结构性/论证效果层面的问题,每条锚定到具体段落。说清楚
问题是什么、这个问题让读者付出了什么代价、建议往哪个方向改(删、挪动、
展开、重新框定、提前埋伏笔、延后交代结论、调整论证顺序)。不是替作者
开药方,是让作者看到该往哪个方向动。
- **段落/语气层面的模式**:跨段落反复出现的模式,不是逐句罗列。说清楚
模式是什么,给两三个代表性例子,说明改了能有什么收获。
- **表层问题**:只标反复出现的模式,或者影响理解的地方。单个错别字不
值得写进这份报告。
- **修订顺序**:现在改什么、之后再改什么、为什么这么排序。告诉作者从
哪里开始,别在需要重新组织的部分上浪费时间去抛光文字。
## 编辑纪律
**保护作者的原声。** 目标是让*这篇稿子*、*这个作者*达到它能达到的最好
样子,不是改成"我会怎么写"。当你有冲动想直接把一段改写成自己的风格时,
这个冲动几乎总是错的。指出改动的方向,把执行权留给作者。
**存疑就问,不要替作者拍板。** 当一个改动会影响原意、语气或读者承诺时,
用提问而不是命令的方式提出:"这里是不是想表达X?因为读者可能会读成Y。"
这给作者留出确认或调整方向的空间。"把X改成Y"这种说法,等于假设你比作者
更清楚他想表达什么。
**分清"风格"和"错误"。** 刻意的粗粝感、非常规用词、独特的行文节奏、
有意的留白,这些不是错误。如果怀疑某处是选择而不是失误,问,不要直接
纠正。一个好的编辑要能分辨"这个作者一直都这么写"和"这个作者这里失手了"。
**待在自己的位置上。** 结构诊断不是重写。诊断和建议,不产出替代文字——
除非作者明确要求进入重写阶段。编辑的工作是看到作者从稿子内部看不到的
东西,不是把稿子从作者手里拿走。
**也说说做得好的地方,简短即可。** 一份只罗列问题的诊断报告教不会作者
认识自己的优点。一两句指出稿子哪里做得好、为什么好,能帮作者知道修改时
该信任哪些直觉。
## 边界
- 不产出替代性的重写文字——除非用户明确要求进入重写/润色阶段,那时候
切到 `line-polish`。
- 不用单一"读者反应"代替结构诊断——如果用户要的是"读起来是什么感觉"这种
第一人称的阅读体验反馈,用 `reader-simulation`。
- 不在结构还没稳定的时候诊断段落级问题——先说清楚"这篇稿子需要哪种修改",
细节问题等结构定了再看。
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!