很多开发者用 AI 编程助手时，习惯直接开聊："帮我写个函数解析 webhook 并路由到对应处理器"。模型给出代码，跑起来差一点，再补一句"修一下缺 event key 的边界情况"，如此反复。四十五分钟后，代码能用了，但对话记录更像一场调试，而不是构建。你从没真正描述过要建什么，只是开始建了。
问题不在模型不够强，而在顺序错了。先写设计再写代码（design-first）的思路是：在向 AI 提问前，先用十分钟写一份简短的结构化说明，讲清输入、输出、约束和边界情况。就像开工前给承包商一份需求书，而不是边干边商量。把这份说明直接作为第一条 prompt 发给模型，它第一次就能产出接近成品的结果，后续迭代从"澄清需求"变成"审查代码"。
具体分三步：第一步写 brief，用要点列出输入输出约束和边界情况，不用写长文；第二步把完整 brief 粘进第一条消息，直接要求构建，而不是请模型"帮忙想想"；第三步对照 brief 逐条审查返回的代码，发现差距时引用 brief 原文指出问题，比如"brief 要求响应时间低于 50ms，当前实现每次请求都调外部 API，请去掉这个依赖"。这套流程对单个函数、完整服务或自动化管线都适用，作者团队在构建 n8n 工作流蓝图时也用了同样方法。
一个诚实的提醒：design-first 不适用于所有场景。当你还在探索问题空间、不知道输出该长什么样时，开放式提问才是对的工具。需求事先可明确时，先写 brief 才划算。另外，把 brief 和代码一起纳入版本管理、积累可复用的约束模板库，是作者事后认为值得改进的地方。核心原则一句话：任何要跑多次的构建，先写 brief，每次都写。
#GitHub #开源 #AI编程 #开发者效率 #设计先行 #AI工作流
@GitHubTrendingHub