Letterpress-1用代码代理提交网站增长改动

Letterpress-1 想接手的，是营销网站上「接下来该做什么」的判断：读取网站、市场和竞品信号，提出增长动作，再把修改做成带预览的 pull request。它把自己定位为增长工程代理，而不只是接需求写代码的助手。

这篇来自 MarkTechPost 的报道，值得看的是这套工作流如何把外部信号接到代码交付上。但产品仍处于 beta，没有公开基准测试，增长效果也缺少量化验证。理解它的产品思路，比直接相信效果宣传更有用。

它为什么要替团队决定下一步做什么

The Letter Company 的判断是：营销网站持续受到 Google 排名、访客行为、竞品动作，以及 AI agent 访问行为的影响。通用编程代理擅长根据任务修改代码，却未必负责从这些信号里发现任务。

Letterpress-1 试图补上这一段。目标用户是把营销网站托管在 git 仓库里的团队，代理会主动建议建设落地页、自动化博客、访客去匿名化、邮件预热和 agent 遥测等能力。

这里的增长工程，就是把获客和转化需求落实成网站功能、内容及实验。它处理的不只是「这个页面怎么写」，还有「为什么现在应该加这个页面」。

产品提供三种模式：Build 根据提示创建页面或功能，保持品牌文案和视觉一致；Plan 围绕目标给出增长行动计划；Fix 查找网站问题并提交修复。

不过，发现机会与证明机会有效是两回事。原文没有交代它如何给建议排序，也没有说明这些动作带来了多少新增访问或转化。

从网站信号到 PR，交付边界比较清楚

每次修改都经过同一个流程：读取网站，制定计划，在沙箱里构建，自查，然后提交带实时预览的 PR。是否接受预览、采用 PR，以及检查通过后是否合并，由用户决定。

它最有价值的设计，是把自动生成的修改变成可以预览和审查的交付物。

对前端团队来说，代码差异之外还有页面效果可看，比较容易发现品牌风格、文案和布局是否跑偏。但代理自查能发现哪些问题，原文没有提供评测。

Letter 列出了六种入口：Web 平台、Slack app、letterpress CLI、网站门户、独立应用，以及用户自己的 agent。页面内 IDE 支持按 ⌘L 直接编辑眼前的文字，再生成 PR；展示案例还涉及通过实时编辑创建 A/B 测试，但没有给出实验结果。

它运行在 Letter 的托管平台上，连接用户的 git 仓库，不需要本地 GPU。团队声称配置耗时不到 5 分钟。底层组合了前沿模型和微调小模型，但名称、规模均未公开，无法据此判断具体模型能力。

760 个工具背后，是一套面向 agent 的获客设想

开发者接入主要靠统一工具注册表。原文提到，agents.md 记录了使用 OAuth 的 MCP 服务，地址为 app.letterstory.com/api/mcp。MCP manifest、OpenAPI spec 和 API reference 对应同一套 760 个工具，通过 MCP、REST 和 CLI 暴露。

Claude Code、Codex 或其他支持 MCP 的 agent，可以调用应用自身使用的函数。已有 AI 编程工作流的团队，因此多了一种接入方式。

但工具数量只能说明接口覆盖范围，不能证明代理会选对工具。

更特别的是四种面向 AI 买家的机制：

• Proofs 用遥测和账单数据生成带签名的客户成功证据，供 agent 访客读取。
• Simulations 为 API 或 MCP 提供模拟数据的镜像环境，让 agent 在购买前试用。
• Benches 是支持自托管、代码开源、强调独立治理的可复现基准应用。
• Phantoms 是独立运行的自主博客，用于试验增长策略。

它们共同押注一件事：将来评估产品的不只有人，也有替人筛选工具的 agent，所以网站需要提供机器能验证的证据和试用环境。

网站还列出了 Kernels、Letterbases、Visitors、Mailers，以及监控竞品 sitemap 新页面的能力，并将这些能力定位为 G2、Semrush、Profound、RB2B、Instantly 等工具的替代方案。原文没有充分解释每个模块的边界，也没有给出替代效果对照。

月费只是起点，超额价格更影响试用成本

Letter 使用共享额度池，标价下 1 token 等于 1 美分。这里的 token 是产品计费单位，不能直接当成模型处理文本的 token。

月度套餐分别为 Basic：$100、10,000 tokens；Starter：$500、50,000 tokens；Growth：$1,000、130,000 tokens；Scale：$2,500、400,000 tokens。Enterprise 从每月 200 万 tokens 起，按标价的一半收费。

代理运行费用为模型成本加 20%。原文给出的典型单次 PR 消耗是 150 至 900 tokens，按标价折算为 $1.50 至 $9；发布一篇文章消耗 1,030 tokens。未用完的额度不结转。

Basic 和 Starter 的超额费用是每 1,000 tokens 收取 $50，达到标价的 5 倍。

免费额度为一次性 5,000 tokens，使用工作邮箱可获得 6,000。试用时更需要观察的，是每个可接受 PR 的实际消耗，以及返工会增加多少成本。

我的判断

我认可它把增长建议、沙箱修改、预览和 PR 连在一起的方向。这比单独生成页面更接近营销网站的日常协作，也保留了开发者检查交付物的入口。

但它是否比通用代理更有效，目前证据不足。原文只有一组团队自行展示的、与 Codex 并排构建页面的案例，没有公开 benchmark，也没有可量化的增长评估。有关质量和效果的说法，应当视为产品方主张。

用 Claude Code、Codex 或 Cursor，配合分析数据、任务单和 CI，也能组织类似流程。Letterpress-1 的吸引力在于预先整合了这些环节，是否值得付费，取决于它能否持续提出有用的任务。

原文的竞品表还列出了各家的价格和模型，但没有统一比较口径。通用编程订阅与增长平台的额度池，不能只按入口月费判断划算与否。

能拿来做什么

• 如果团队的营销站已经放在 git 仓库里，可以先用一个落地页或一个明确的网站问题试跑，检查建议、预览和 PR 是否达到交付要求。
• 如果已有 Claude Code 或 Codex 工作流，可以优先评估 MCP 接入，确认所需工具是否可用，再决定是否采用完整平台。
• 如果产品提供 API 或 MCP，可以借鉴 Simulations 和 Proofs 的思路，准备模拟环境与可核验的数据，降低 agent 理解和评估产品的成本。
• 评估付费时，同时记录可接受 PR 数量、返工情况和额度消耗，并把 Basic、Starter 的 5 倍超额价格纳入预算。