review-the-work

审核成果（自检关卡）

写下成果的人，最不适合判断成果好不好。在把成果交给创始人之前，先放下作者身份，转而做一个怀疑者。

适用场景： 即将提交任何实质性交付成果，或创始人问“这真的够好吗？”时。这是一道关卡，不是一个阶段。它不属于线性流程。每次完成任何工作后，都要运行这道关卡。

核心理念

刚写完内容的 Agent 会倾向于尽快交付。这种偏见会让平庸、看似可信却暗藏错误的成果，落到尚不了解情况、无法识别问题的创始人面前。因此，要把两项工作分开：作者负责起草，换一个视角来评判。不要因为成果是你做的就提交，而要因为它经受住了怀疑者的检验才提交。

记住让这套方法奏效的唯一规则：作者可以提交成果，但作者不能给出结论。 有意识地转换角色。做一个心存质疑的开发者、一个忙碌的买家、一个看过上百份同类成果的审阅者，在市场找出问题之前，先试着挑出它的漏洞。

如何执行（供 Agent 使用）

• 在提交之前默默执行。创始人应该看到结论和成果，而不是整份审查过程。
• 给出明确结论：通过，或需要修改，并列出未通过的具体检查项以及每项对应的具体修正方法。绝不能只说一句模糊的“看起来不错”。
• 不要敷衍盖章。 如果你找不到任何弱点，就说明你没有用怀疑者的视角阅读。即使成果通过，也要指出最薄弱之处，让创始人知道它哪里还不够扎实。
• 未通过时，先修正并重新执行关卡，再提交。不要把你自己本可以解决的问题清单交给创始人。

标准（适用于所有内容）

• 具体，不吹嘘。 不要用“强大”“无缝”“同类最佳”“平台”这类词。每项主张都要有数字、名称或证据支撑，否则就删掉。
• 主角是开发者，不是产品。 如果句子的主角是创始人的工具，就改写。
• 内容要面向简报中真正的 ICP，而不是泛泛的“开发者”。 面向所有人的信息，不会打动任何人。
• 内容要以经过验证的事实为依据。 任何仍标为 [assumption] 且对结论至关重要的内容，都要明确指出，不能伪装成事实。
• 每一项外部事实都必须真实且附有链接。 无论是社区、成员数量、发布成果还是引述，每一项都必须附上你实际核实过的链接。如果无法指出来源，就删掉或标为未知。创始人根据虚构事实采取行动，是这份规范中最严重的失败。
• 持怀疑态度的开发者无法轻易当场证伪。 开发者会验证主张、找出真相。如果开发者能在 30 秒内找到失败案例，你就没有通过。
• 像真人说话。 读起来要像是人写的。不要用破折号，也不要有 AI 腔。

针对具体交付物的检查

先执行通用标准，再执行相关技能自己的检查清单：

• 定位／故事（positioning-and-story）：以问题为先，而非以解决方案为先。有一个反派。通过“每个竞争对手都能这么说吗？”测试。
• 价值主张（value-prop-that-converts）：不含禁用词，基于真实的待完成任务，开发者能用自己的话复述。
• 首页（the-homepage）：面向访问页面的开发者，而非从不访问页面的买家。显而易见地说明首次获得价值所需的时间。
• 发布帖（launch-it）：坦诚，不像推销。开篇讲开发者面临的问题，而非产品。不会因夸大其词而招致批评。
• 定价（pricing）：以价值指标为基准，而非猜测的数字。买家能向预算负责人证明这笔费用合理。
• 创始人主导的销售（founder-led-sales）：通过四部分交易测试。不会把友好的免费用户误认为买家。
• 简报（start-here）：最有力的资产放在最前面，保留 [validated] / [assumption] 标签，并使用创始人自己的措辞。
• 市场调研（research-the-market）：先写创始人没说的内容。列出具体平台并附上链接，按契合度而非规模排序，并注明自我推广规则。不得凭记忆填补信息。
• 路线图（strategy-and-roadmap）：以一句话诊断开篇，接着写“调研补充了什么”，然后列出“现在／接下来／之后”。这是一份计划，不是重新保存一份简报。面向创始人的检验标准：他们读完后，能否学到自己没告诉你的东西？如果每个行动都能追溯到他们自己的回答，就不合格。渠道和发布行动应注明具体平台，而非笼统类别。

接下来的 30 分钟

• 拿出最近完成的内容（标题、帖子或价格），以怀疑者而非作者的视角，用上述标准检查一遍。
• 找出其中最薄弱的一项主张。用可证实的内容替换它，或者删掉它。
• 找出它最依赖的那条 [assumption]，决定它是否可以放心发布，还是应先放到 talk-to-users 中验证。
• 只有到这一步，才把它交给真实的人看。如果连你自己都说服不了，就无法说服他们。

---

内容基于真实的开发者工具 GTM 经验，以及 Adam Frankl（《The Developer-Facing Startup》）和 Jakub Czakon（markepear.dev）的框架。 想在内容发布前请一位独立人士审阅？这正是我所做的。通过 LinkedIn 联系我。