How Warp uses Warp to build Warp:一份来自 Warp 内部的「编码强制令」

原文标题就叫 The Coding Mandate:「Warp 的编码强制令:每个编码任务都从 Warp 开始」。它不是「只许用 Warp」,而是一条明确的升级路径:

① 用 prompt 写代码,在很多任务上确实更快

• 省去手写代码的时间;
• 支持多线程开发(同时推进多个任务);
• 在你不熟悉的代码区域尤其有用——随着代码库增长,「不熟悉的部分」会越来越多,Warp 能帮你快速学懂这些新地盘。

② Dogfooding(吃自己的狗粮)是改进产品的最好方式

• 强制令的很大一部分动机,就是让全员使用并反馈自己正在造的东西;
• 原文说得很重:「我们要求用户这样工作,并把公司押注在这上面,那我们最好足够相信这套工作流,愿意自己先用。」

③ 用竞品能建立「可能改进什么」的直觉

使用竞争对手的产品,能帮团队直观感受自家产品可能差在哪、以及什么是可能做到的。

此外,团队常规的 How We Code 规范在提示编码时依然全部适用(小 PR、feature flag 等等)。

原文的表述:如果你只对 agent 说「我要一个像 X 那样工作的功能」,它产出的代码大概率达不到团队标准。正确姿势是把工程决策交代清楚:

• 数据模型应该长什么样;
• 我们想要什么样的 API;
• 代码应该放在哪里;
• 应该写哪些测试。

只给目标、放任 agent 自己「摸着结果走」(goal seek),最终会浪费大量时间——产出的代码也许「能跑」,但不可维护、不可测试、不可组合。

• 让 agent 做小而自包含的修改和提交、频繁核对方向,效果会好得多;
• 反模式:试图让 agent 一口气(one-shot)完成需要产出大量代码的复杂修改——one-shot 适合简单改动,不适合复杂功能;
• 让 agent 边做边频繁写测试,是逼它增量工作的好办法;
• 经常查看进行中的改动,确认它推进的方式和你亲手写时一致——目前可以用 GitHub UI 或其他 PR 审查工具,以后 Warp 会更原生地支持这种审查流;
• 让 Warp 一路替你写好提交信息、按步提交,需要时可以随时回滚。

• 在 Warp 动手改代码之前,先要一份解释或计划;
• 对计划进行迭代,让它给出多种可选方案和不同实现思路——确保在它开始产出 diff 之前,你已经把大图景想清楚;
• 反过来也可以:让 Warp 端到端做一个大改动「看看什么是可能的」,但要有心理预期——之后得回头把它拆成可理解的小块,才能达到团队质量线。

• 用得越多,你会逐渐建立起「该给什么上下文、什么样的提示最有效」的直觉;
• 请把这些知识分享给团队——原文的判断:「提示编码是一门全新的学科,我们各自的直觉都不一样,一起学才快。」
• 用好 Warp 的高级能力来优化工作流:
  • 用 rules、prompts 和 WD(Warp Drive)对象作为持久上下文;
  • 用 @ 标注文件;
  • 做 UI 改动和调试时附上图片;
  • 多试不同的模型;
• 在本地架设多份 warp-internal 和 warp-server 副本,才能有效地多线程并行开发。

原文作者强调「怎么强调都不过分」:只要有什么不好用,就报到对应的 #feedback- 频道。值得报告的情形包括:

• 服务端错误或客户端 bug;
• agent 绕圈子,烧请求、浪费时间;
• agent 忘记上下文;
• 缺少能帮你完成任务的功能;
• 高延迟、AI 表现变笨、diff 应用错位……等等。

① 配好 MCP server,让 agent 随手拿到上下文

原文列出「每个人都应该配上」的服务器:Sentry、Linear、Notion、Slack(原文此处还留了一个开放的「<what else>」占位,意为清单待补充)。并附一句经验:「agent 模式修 panic、从 Linear 快速进入状态的能力,会让你吃惊。」

② 把重复出现的约定沉淀成 rules

凡是你发现自己反复对 agent 交代的事(跑哪个 linter、unwrap/expect 的代码约定、import 规则、测试文件位置等),就花点时间做成 Warp Drive rules。

③ 把重复出现的流程沉淀成 prompts

凡是你发现自己在重复执行的任务,就值得做成一条 Warp Drive prompt。作者自己的例子:生成 commit、创建和编辑 PR 描述、解决合并冲突等,都做成了 prompt。

Coding Mandate

编码强制令:Warp 内部「每个编码任务从 prompt 开始」的强制工作流。

dogfooding

「吃自己的狗粮」:公司内部使用自家产品,以第一视角发现并改进问题。

#warped-it / #feedback-

Warp 内部 Slack 频道:前者晒「用 prompt 干成活」的战果,后者按主题收集失败反馈。

eval

可重复运行的 AI 行为评测用例;Warp 把用户反馈的坏案例优先固化成 eval 来防回归。

one-shot

试图让 agent 一次性完成整个复杂改动;原文视为复杂功能场景下的反模式。

goal seek

只给目标、放任 agent 自行摸索实现路径;原文认为这会产出「能跑但不可维护」的代码。

Warp Drive(WD)

Warp 中承载 rules、prompts 等可复用对象的地方——原文将「WD objects」与 rules、prompts 并列称为 agent 的持久上下文。

feature flag

功能开关,把新功能的发布与代码合入解耦;属于 Warp 常规工程规范的一部分。

panic

程序的运行时崩溃(Rust 术语);原文说 agent 修 panic、从 Linear 进入状态的能力会让你吃惊。