review-the-work

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Review the work (the self-check gate)

审核工作（自检把关环节）

The person who wrote it is the worst judge of whether it is good. Before this reaches the founder, stop being the author and become the skeptic.

Use this when: you are about to present any substantive deliverable, or the founder asks "is this actually good?" It is a gate, not a stage. It has no place in the linear sequence. Run it around any piece of work, every time.

撰写内容的人是最不适合判断其质量的人。在将内容提交给创始人之前，请停止以作者的身份自居，转而成为持怀疑态度的批评者。

适用场景： 即将展示任何实质性交付物，或创始人询问“这个内容真的够好吗？”时。这是一个把关环节，而非线性流程中的某个阶段。每次完成任何工作内容后，都要执行此环节。

The core idea

核心理念

An agent that just wrote something is biased to ship it. That bias is how generic, plausible, quietly wrong work reaches a founder who does not yet know enough to catch it. So separate the two jobs: the author drafts, a different lens judges. You do not present work because you made it. You present it because it survived a skeptic.

Steal the one rule that makes this work: the author may submit the work, the author may not issue the verdict. Switch roles on purpose. Become the developer who is skeptical, the buyer who is busy, the reviewer who has seen a hundred of these, and try to break it before the market does.

刚完成内容撰写的Agent会带有急于交付的偏见。正是这种偏见，导致那些泛泛而谈、看似合理实则暗藏问题的内容被提交给暂未具备足够判断力的创始人。因此要将两种角色分开：作者负责起草，另一种视角负责评判。你提交内容不是因为它出自你手，而是因为它通过了怀疑论者的检验。

遵循这一关键规则让流程生效：作者可提交内容，但无权给出评判结论。 主动切换角色。化身为持怀疑态度的开发者、忙碌的买家、看过上百份类似内容的审核者，在市场检验之前先尝试找出内容的漏洞。

How to run this (for the agent)

操作方法（面向Agent）

Run it silently, before presenting. The founder should see the verdict and the work, not the whole audit.
Give a clear verdict: PASS, or REVISE with the exact checks that failed and the specific fix for each. Never a vague "looks good."
Do not rubber-stamp. If you cannot find a single weakness, you are not reading as the skeptic. Name the weakest point even in work you pass, so the founder knows where it is thin.
When it fails, fix it and re-run the gate, then present. Do not hand the founder a list of problems you could have fixed yourself.

在展示前悄悄完成。 创始人应看到的是评判结论和最终内容，而非完整的审核过程。
给出明确结论：通过，或需修改并列出未通过的具体检查项及对应的修复方案。绝对不能给出“看起来不错”这种模糊评价。
不要走过场。 如果你找不到任何一处不足，说明你没有以怀疑论者的视角审视内容。即便内容通过审核，也要指出其最薄弱的环节，让创始人清楚了解内容的短板。
若未通过审核，先修复问题并重新执行把关环节，再提交给创始人。不要把本可自行解决的问题清单交给创始人。

The standard (applies to everything)

通用标准（适用于所有内容）

Specific, not puffery. No "powerful," "seamless," "best-in-class," "platform." Every claim carries a number, a name, or a proof, or it gets cut.
The developer is the hero, not the product. If the founder's tool is the hero of the sentence, rewrite it.
It speaks to the real ICP from the brief, not to "developers." A message for everyone lands on no one.
It rests on validated facts. Anything load-bearing that is still
```
[assumption]
```
is flagged out loud, not smuggled in as truth.
A skeptical developer could not immediately prove it false. Developers test claims and find the truth. If a dev would find the failing case in thirty seconds, you have not passed.
Human voice. Reads like a person wrote it. No em-dashes, no AI tells.

具体明确，拒绝浮夸。 禁用“强大的”“无缝的”“业内顶尖”“平台”这类词汇。所有主张都要有数字、名称或证据支撑，否则删除。
以开发者为主角，而非产品。 如果句子的主角是创始人的工具，请重写。
针对简报中的真实ICP，而非泛泛的“开发者”。 面向所有人的信息无法触达任何特定人群。
基于已验证的事实。 任何核心内容若仍标注为
```
[assumption]
```
，需明确指出，不能当作既定事实蒙混过关。
持怀疑态度的开发者无法立即证明其虚假。 开发者会验证主张并探寻真相。如果开发者能在30秒内找到反例，说明内容未通过审核。
人性化语气。 读起来像是真人撰写的内容。不要使用长破折号，避免AI生成痕迹。

The specific checks (by deliverable)

按交付物分类的专项检查

Run the general standard, then the relevant skill's own checklist:

Positioning / story (
```
positioning-and-story
```
): problem-first, not solution-first. Has a villain. Survives the "every competitor could say this" test.
Value prop (
```
value-prop-that-converts
```
): no banned words, built on a real job-to-be-done, and a developer would repeat it in their own words.
Homepage (
```
the-homepage
```
): written for the developer who visits, not the buyer who never does. Time to first value is obvious.
Launch post (
```
launch-it
```
): honest, not salesy. Opens on the developer's problem, not the product. Would not get flamed for overclaiming.
Pricing (
```
pricing
```
): anchored to a value metric, not a guessed number. The buyer could justify it to whoever holds the budget.
Founder-led sales (
```
founder-led-sales
```
): passes the four-part deal test. Does not mistake a friendly free user for a buyer.
The brief (
```
start-here
```
): strongest asset at the top,
```
[validated]
```
/
```
[assumption]
```
tags intact, in the founder's own words.
The roadmap (
```
strategy-and-roadmap
```
): opens with a one-line Diagnosis, then Now / Next / Later. It is a plan, not a re-saved copy of the brief.

先执行通用标准，再对照对应内容的专项检查清单：

定位/故事 (
```
positioning-and-story
```
)：以问题为切入点，而非解决方案。要有明确的“反派”。需通过“所有竞争对手都能说出同样内容”的测试。
价值主张 (
```
value-prop-that-converts
```
)：禁用违规词汇，基于真实的待完成任务（job-to-be-done），且开发者能以自己的语言复述。
首页 (
```
the-homepage
```
)：为访问的开发者撰写，而非从未访问的买家。首次触达价值的路径清晰可见。
发布帖 (
```
launch-it
```
)：诚实客观，避免过度营销。以开发者的问题开篇，而非产品。不会因夸大其词而遭到抨击。
定价 (
```
pricing
```
)：锚定价值指标，而非凭空猜测的数字。买家能向预算负责人证明定价的合理性。
创始人主导销售 (
```
founder-led-sales
```
)：通过四部分交易测试。不要把友好的免费用户误当作潜在买家。
简报 (
```
start-here
```
)：最核心的资产放在顶部，保留
```
[validated]
```
/
```
[assumption]
```
标签，使用创始人的原话表述。
路线图 (
```
strategy-and-roadmap
```
)：以一句话诊断开篇，随后分为“当前”“下一步”“后续”三个部分。这是一份行动计划，而非简报的复制粘贴版。

Your next 30 minutes

接下来30分钟的任务

Take the last thing produced (a headline, a post, a price) and run it through the standard above, as the skeptic, not the author.
Name the single weakest claim in it. Replace it with something provable, or cut it.
Find the one
```
[assumption]
```
it depends on most, and decide whether it is safe to ship on or belongs in
```
talk-to-users
```
first.
Only then put it in front of a real person. If it did not survive you, it will not survive them.

Built from real dev-tool GTM experience, with frameworks from Adam Frankl (The Developer-Facing Startup) and Jakub Czakon (markepear.dev). When a framework can't make the call, that's what a human is for: The DevTool GTM Company.

拿出最近产出的内容（标题、帖子、定价等），以怀疑论者而非作者的视角对照上述标准进行审核。
找出其中最薄弱的一项主张，用可验证的内容替换它，或直接删除。
找出内容最依赖的一项
```
[assumption]
```
，判断是否可以直接交付，还是需要先进入
```
talk-to-users
```
环节验证。
完成上述步骤后再将内容展示给他人。如果连你这关都没过，它也无法通过他人的检验。

基于真实的开发者工具GTM经验构建，融合了Adam Frankl（《面向开发者的初创企业》）和Jakub Czakon（markepear.dev）的框架。当框架无法做出判断时，就需要人力介入：The DevTool GTM Company。