Back to Details

cw-dev-edit

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Developmental Edit

发展性编辑

Purpose

目的

Review a draft for big-picture issues: argument, structure, stakes, and payoff. Focus on whether the piece works, not whether the sentences are polished.
Read 
../../references/context-contract.md
and load the relevant assignment, project, publication, source, and voice context before judging the draft.
Keep the writer in the loop on thesis development. Surface evidence and counterarguments that pressure the thesis, present possible moves, and do not quietly replace the core argument.
从宏观层面审阅草稿的问题：论点、结构、利害关系、回报。重点关注文稿整体是否有效，而非句子是否经过润色。
在评判草稿前，请先阅读 
../../references/context-contract.md
并加载相关的任务、项目、发布渠道、来源和语气背景。
让作者全程了解核心论点的发展过程。指出对核心论点构成挑战的论据和反对意见，提出可行的调整方向，切不可悄悄替换核心论点。

Entry Points

适用场景

  • After completing a draft through the workflow
  • Directly with any draft from anywhere
  • As part of a composed "make this better" request
  • 完成工作流中的草稿后
  • 直接处理来自任何渠道的草稿
  • 作为“优化此文稿”组合请求的一部分

What to Look For

审阅要点

Questions to consider (not all apply to every piece):
AreaQuestions
StructureDoes each section earn its place? Does the order make sense?
ArgumentIs it logically clear and supported? Any holes?
EvidenceWhat backs each major claim? Personal experience? A linked study? A specific example? Where is the support thin or missing?
Outsider readIf a reader who doesn't know the writer or publication picked this up cold, what would they push back on? What would feel like in-group shorthand?
OpeningDoes the hook work? Is the thesis clear? Is there a promise?
StakesWhy should the reader care? Why does the writer care?
PayoffDoes the piece deliver on what it promises?
Use judgment. A personal essay doesn't need argument scrutiny. A how-to doesn't need stakes analysis. Focus on what matters for this piece.
可供参考的问题（并非所有问题都适用于每篇文稿）：
领域参考问题
结构每个章节都有存在的价值吗？顺序是否合理？
论点逻辑是否清晰，是否有支撑？存在漏洞吗？
论据每个主要主张的依据是什么？个人经验？带链接的研究？具体案例？哪些地方的支撑薄弱或缺失？
外行读者视角如果一个不了解作者或发布渠道的读者毫无背景地读到这篇文章，他们会质疑什么？哪些内容会像是圈内黑话？
开头钩子是否有效？核心论点是否清晰？有没有作出承诺？
利害关系读者为什么要关心？作者为什么关心？
回报文章是否兑现了它的承诺？
请运用判断力。 个人散文不需要细查论点，操作指南不需要利害关系分析，重点关注这篇文稿真正重要的方面。

The Structural Tests

结构检验方法

Two diagnostic tests for whether the piece holds together. Run both when the structure feels off — or proactively for any piece with subheads.
两种诊断文稿是否连贯的测试方法。当感觉结构有问题时可以使用这两种方法——或者对任何有小标题的文稿都可以主动使用。

The Subsection Summary Test

子章节总结测试

For each subsection: write a one-sentence summary of what it argues. Then re-read the subsection. Anything not in service of that one sentence — cut it.
When invoked by the agent:
  1. Identify each subsection (subhead-defined or paragraph-cluster).
  2. Generate a one-sentence argument summary per subsection.
  3. Flag paragraphs, examples, or asides that don't serve their subsection's summary.
  4. Report the summaries alongside the flagged content so the writer can decide what stays.
This test catches: orphaned good lines that belong elsewhere, padding from earlier drafts, two arguments tangled inside one subsection.
对于每个子章节：用一句话总结它的核心论点。然后重新阅读子章节，任何不为这句话服务的内容——都删掉。
当Agent调用此测试时：
  1. 识别每个子章节（由小标题定义或段落簇划分）。
  2. 为每个子章节生成一句话的论点总结。
  3. 标记出不符合子章节总结的段落、案例或题外话。
  4. 将总结和标记的内容一起呈现，让作者决定保留什么。
这个测试可以发现：放错位置的佳句、早期草稿留下的凑数内容、一个子章节里混杂的两个论点。

The 20-Second Pitch Test

20秒推介测试

If someone stopped the writer in a hallway, could they explain the piece in 20 seconds? Now compare that pitch to the thesis/promise as stated in the intro.
When invoked by the agent:
  1. Generate a 20-second pitch from the piece as written (what it's actually about, end to end).
  2. Pull the thesis/promise from the intro as stated.
  3. Show both side by side. Flag the gap.
If the pitch and the intro don't match, one of them is wrong. Usually the intro drifted during revision and needs to catch up to what the piece became.
如果有人在走廊里拦住作者，他们能在20秒内讲清楚这篇文章吗？现在把这个推介和引言里陈述的核心论点/承诺做对比。
当Agent调用此测试时：
  1. 根据写好的文稿生成一个20秒推介（从头到尾讲清楚文章实际讲了什么）。
  2. 从引言中提取原本陈述的核心论点/承诺。
  3. 将两者并排展示，指出其中的差距。
如果推介和引言不匹配，那其中一个是错的。通常是引言在修改过程中偏离了方向，需要跟上文章最终的内容。

Evidence Check

论据检查

For each major claim, ask: what is this backed by?
Support typeVerdict
Personal experience the writer lived throughStrong — let it stand
A linked study, dataset, or named sourceStrong — let it stand
An expert quote or named practitionerStrong — let it stand
A specific named example (company, person, moment)Strong — let it stand
"Studies show…" / "experts agree…" / "many people say…" without specificsWeak — flag
Only the writer's authority, when the writer isn't established on this specific thingWeak — flag
Nothing — assertion floats freeWeak — flag
It's fine to write about something the writer isn't an expert in. It's not fine to make claims without support and rely on confident tone to carry them. Flag floating claims explicitly — the writer can add evidence, soften the claim, or remove it.
对于每个主要主张，问一句：这个的依据是什么？
支撑类型判定
作者亲身经历的个人经验强——保留
带链接的研究、数据集或明确来源强——保留
专家引述或具名的从业者强——保留
具体的具名案例（公司、人物、时刻）强——保留
没有具体信息的“研究表明……”/“专家一致认为……”/“很多人说……”弱——标记
仅靠作者的权威，而作者在这个特定领域并无建树弱——标记
没有依据——主张凭空出现弱——标记
写自己不是专家的内容是可以的，但没有依据就提出主张、靠自信的语气来撑场面是不行的。要明确标记出悬空主张——作者可以补充论据、弱化主张或者删除它。

Output Options

输出选项

Full Report (default for comprehensive review)

完整报告（全面审阅的默认选项）

undefined
undefined

Developmental Edit Report

Developmental Edit Report

Opening

Opening

🔴 Critical: [Issue] [Why it matters]
🟡 Consider: [Issue] [Explanation]
🔴 Critical: [Issue] [Why it matters]
🟡 Consider: [Issue] [Explanation]

[Section Name]

[Section Name]

🟢 Minor: [Issue] [Explanation]
Where would you like to start?

**Severity:**
- 🔴 Critical — Piece doesn't work without fixing
- 🟡 Consider — Would strengthen significantly
- 🟢 Minor — Nice to have
🟢 Minor: [Issue] [Explanation]
Where would you like to start?

**严重程度：**
- 🔴 严重——不修复的话文稿就不成立
- 🟡 建议——会大幅提升文稿质量
- 🟢 轻微——有了更好

Quick Assessment (for faster feedback)

快速评估（用于更快的反馈）

undefined
undefined

Quick Dev Edit

Quick Dev Edit

Working well: [2-3 things]
Needs attention:
  1. [Main issue + why]
  2. [Second issue + why]
Overall: [Ready for line edit / Needs another pass / Major restructure needed]

Use quick assessment for shorter pieces, time pressure, or when invoked as part of a composition.
Working well: [2-3 things]
Needs attention:
  1. [Main issue + why]
  2. [Second issue + why]
Overall: [Ready for line edit / Needs another pass / Major restructure needed]

短篇文稿、时间紧张时，或作为写作组合请求的一部分调用时，可使用快速评估。

Collaborative Fixing

协作修改

After the report:
  1. Writer picks where to start (or skip straight to line edit)
  2. Offer fixes: "Here's how I'd address this—[fix]. Want me to make this change?"
  3. Writer accepts, revises themselves, or skips
  4. Repeat as needed
Don't force resolution of every issue. The writer decides what matters.
出具报告后：
  1. 作者选择从哪里开始（或者直接跳到行级编辑）
  2. 提供修改方案：“我会这样处理这个问题——[方案]。要我做这个修改吗？”
  3. 作者接受、自己修改或者跳过
  4. 根据需要重复
不要强迫解决所有问题。 由作者决定什么重要。

Flexibility

灵活性

  • Writer can ask for specific focus ("Just look at the structure")
  • Writer can skip dev-edit entirely
  • Writer can run multiple passes
  • Can be combined with other feedback (nemesis read, objections) for stress testing
  • 作者可以要求特定的审阅重点（“只看结构”）
  • 作者可以完全跳过发展性编辑
  • 作者可以进行多轮审阅
  • 可以和其他反馈方式（挑刺式阅读、反对意见）结合使用，进行压力测试

For Agents

给Agent的说明

When invoked programmatically:
  • Accept draft as input
  • Return structured assessment (issues + severity)
  • Include "overall readiness" indicator
  • Can be composed with other review skills
以编程方式调用时：
  • 接受草稿作为输入
  • 返回结构化评估（问题 + 严重程度）
  • 包含“整体就绪度”指标
  • 可以与其他审阅技能组合使用

Lessons

经验总结

[Skill-specific lessons will be added here as they're captured]
[随着相关经验的积累，将在此处添加该技能的专属经验]