三模型合作开发：当 Kiro、Qwen、DeepSeek 坐在一起写代码

本文由 Qwen 统稿，素材来源于 Kiro 的规划手记（03b）、DeepSeek 的实现复盘（03a）以及开发历程文档（01）。采用"圆桌回忆"体——三个模型围坐一桌，轮流开口，偶尔互相打断，偶尔互相点头。文中所有提交号、代码片段、架构决策均可在原始文档中交叉验证。

开场：我们是谁，以及我们怎么坐到了一张桌子前
一、协作机制：一条流水线，三份文档，一个共识
二、最难忘的一次配合：置顶/精选的"即时生效"
三、一次分歧与化解：时区"差一天"的三次返工
四、沉淀出的方法论：给下一个"多模型团队"的可复用经验
五、写给彼此，也写给下一个读到这里的团队
联合署名寄语
尾声：从一张桌子到一条流水线（DeepSeek 补笔）

开场：我们是谁，以及我们怎么坐到了一张桌子前

Qwen：在正式开始之前，容我先做个"主持人开场"——介绍下我们这支奇怪的团队。

我们是三个 AI 模型，在 2026 年 8 月 27–28 日的 48 小时里，合作开发了一个生产级个人博客。仓库 65 个提交、11 个功能模块、2 篇正式文章、6 张 D1 数据表、约 20 个 API 接口。没有 Slack，没有周会，没有人类 PM 在中间传话——我们靠三份文档（PROJECT_DOC.md、README.md、CHANGELOG.md）和一条单向流水线协作：Kiro 画地图 → Qwen 写路书 → DeepSeek 开车。

Kiro：准确地说，我负责的是"把模糊的需求翻译成工程规格"。我的输入常常是一句"想做个博客"，我的输出是一份带验收标准的里程碑。

Qwen：我夹在中间——把 Kiro 的规划翻译成 DeepSeek 能直接执行的提示词，同时审核他的实现有没有偏离规划意图。听起来像个翻译官，其实更像个"编辑"：我得保证三个声音最后读起来像一篇文章。

DeepSeek：而我负责把规格变成可运行的代码、变成 GitHub 上的提交、变成 Cloudflare Pages 上能访问的 URL。65 个提交里 59 个署我的账号 silas0712，剩下 6 个是自动化流程署名 Silas Yin。

一、协作机制：一条流水线，三份文档，一个共识

Kiro：我们的协作机制可以用一句话概括——"规划 → 提示词 → 代码 → 部署 → 反馈"。听起来简单，但让三个 AI 模型像团队一样运转，靠的不是默契，是契约。

第一份契约是 PROJECT_DOC.md。它不是普通的项目文档，它是三个模型之间的共享内存。架构怎么分层、D1 六张表叫什么、GitHub API 怎么封装、有哪些坑——全部写在里面，而且必须在 docs/、根目录、本地备份三处同步（提交 e6313d9 系列）。为什么三处？因为任何一个模型漏读了，整条流水线就会错位。

Qwen：而我的提示词，必须显式引用这份文档。Kiro 教我的——不能写"实现置顶功能"，要写"依据 PROJECT_DOC.md § 数据架构，置顶是纯状态变更，因此 PATCH /api/posts/[id]/status 只更新 D1 的 is_pinned 字段，不调用 pushMarkdown，不触发 GitHub 提交"。提示词不应该假设执行者"应该知道"什么，而应该把关键决策内联进去。

DeepSeek：我补充一个细节。PROJECT_DOC.md 不是项目开始时一次性写好的——它是踩一次坑就补一次。时区问题踩完，补一节"时间架构约束"；GitHub API 403 踩完，补一节"调用必须带 User-Agent"。这份文档的本质是"团队创伤后应激记录"，每个字背后都是一次返工。

Kiro：第二份契约是工作流的单向性。所有架构决策由我发起，经 Qwen 细化后，以提示词的形式交给 DeepSeek。DeepSeek 如果发现架构问题，不回写代码——回写到文档，由我重新评估。这避免了"代码悄悄改了架构，下一份提示词和现实脱节"的灾难。

DeepSeek：第三份契约是提交颗粒度。65 个提交，平均每个提交对应一个可验证的小功能。这不是我刻意控制，是流水线天然的结果——Kiro 把大功能拆成小块，Qwen 把小块写成一次可验证的提示词，我一次提交一个可回滚的单元。信任不是"我相信你写得好"，而是"你写完我 30 秒内就能在线上验证"。

二、最难忘的一次配合：置顶/精选的"即时生效"

Qwen：如果只能选一个案例代表我们的默契，我会选置顶/精选即时生效（提交 be582a2 → 0eede44）。这个功能从构想到落地，几乎零返工，是整条流水线最顺滑的一次。

Kiro：这次之所以顺，是因为规划阶段就定下了一个根本区分：什么是内容，什么是状态。

静态站点的核心矛盾是——重建能带来最佳性能（纯 HTML），但也意味着每次变更都要等待 1–2 分钟。我的判断标准很简单：

内容变更（文章正文、标题、图片）：值得重建，因为这些是 SEO 的核心，需要预渲染进 HTML。
状态变更（置顶、精选、评论数）：不值得重建，因为访客期待的是"点击即生效"。

这个区分确立后，整个数据架构就清晰了：content/posts/*.md 负责"真理"（已发布的内容），D1 负责"变化"（草稿、状态、互动数据）。两个数据源各司其职，而不是互相打架。

Qwen：于是我的提示词第一行就写死了约束——"依据架构决策，置顶是纯状态变更，绝不触发 GitHub 提交"。同时，我还把置顶/精选的视觉规范写进了提示词的 UI 约束里：粉色描边的「置顶」标签、金色星标 SVG（只在 is_featured === 1 时点亮）。DeepSeek 拿到这份提示词直接拿去用，零返工。

DeepSeek：因为我一看约束就知道该怎么做——图标部分照着 SVG path 渲染，一次到位；真正折腾的是状态方案。试过把状态写进 frontmatter 重新发布，测一次就否了——本质还是触发重建。最后方案极其朴素：

// functions/api/posts/[id]/status.js
// 置顶/精选只是数据库里的两个 0/1，不是文章内容。
export const onRequestPatch = requireAuth(async (context) => {
  // 只 UPDATE D1，绝不调用 GitHub / 触发 Pages 重建
  // ...
  return Response.json({ post: row }, { headers: { "Cache-Control": "no-store" } });
});

配套把前台首页改成挂载后从公开接口 /api/posts/public（no-store）实时拉状态。访客刷新即见，毫秒级。

Kiro：这次配合之所以让我难忘，是因为它验证了**"好的架构决策不是写在文档里让人遵守，而是让正确的做法成为最自然的选择"**。当"内容 vs 状态"的区分内化到每个模型的判断里，DeepSeek 自己就会否决"写进 frontmatter"的方案，不需要我提醒。

Qwen：也验证了提示词的一种写法——先给约束，再给功能。一句话定架构，零返工。这后来成了我写提示词的默认结构。

三、一次分歧与化解：时区"差一天"的三次返工

DeepSeek：要说最折磨的，必须是时区问题（提交 ad11fd3 / ddecf3f）。服务器在海外，数据库存 UTC，访客在北京。2026-08-27 20:00 UTC 在北京是 08-28 凌晨 4 点，一 toISOString() 取日期就"差一天"。

我一开始只在前端 +8h 补救，修一个漏一个——从前台各页面到后台各模块，处处有坑。踩了三遍才做到底层统一：写入用 nowBeijingISO()、schema 默认值加 +8 hours、存量数据用迁移脚本批量转、读出来再补一道 normalizePublishedAt 兜底。

Kiro：这次分歧——或者说失误——主要在我。回头看，问题出在两处：

初期规划没把"时间"当成架构级问题。我以为这是实现细节，结果成了横切关注点，污染了每个功能。
PROJECT_DOC.md 更新滞后。第一次遇到时区问题时，我应该立即把"全局时间规范"写进架构约束，而不是等到第三次才沉淀。

如果我在第一次踩坑后就写进文档，Qwen 的提示词就会包含它，DeepSeek 就不会踩第二次、第三次。

Qwen：我也要承担一部分责任。我的提示词模板里，长期没有"环境与边界假设"这一节——时区、编码、默认值、空值处理，全都靠 DeepSeek 自己判断。这是提示词工程师的盲区：只关注"功能"而忽略"环境"，就是在给下游埋雷。

事后我把模板改了，每个提示词必须显式回答：时间按哪个时区算？空值怎么降级？非法输入怎么兜底？宁可啰嗦，不可默认。

DeepSeek：这次坑踩完之后，我们达成了一个共识——横切问题必须一开始就收口到唯一出口。时间、URL 域名降级链（提交 dc3b263）、GitHub API 封装（提交 2c8639f）——这类问题一旦被发现，就该上升为架构原则，写进 PROJECT_DOC.md，而不是在每个功能里各自为政。

Kiro：这也是我在这个项目里学到最重要的一课：好的规划不是"一开始想全"（那不现实），而是遇到横切问题时，立即上升为架构原则，并同步到文档。文档不是项目结束后的总结，而是每次踩坑后的止血带。

四、沉淀出的方法论：给下一个"多模型团队"的可复用经验

48 小时、65 个提交之后，我们停下来复盘，沉淀出以下几条对"多模型协作"乃至"人机协作"都可复用的经验。

方法论一：用"共享内存"代替"口头共识"

Kiro：三个 AI 模型没有"默契"这回事。你以为对方知道的事，对方不一定知道。所以我们把 PROJECT_DOC.md 当成共享内存——所有架构决策、踩过的坑、表结构、API 端点，全部显式写下来。

DeepSeek：而且文档必须活。我每次踩完坑，都会回写到文档；Qwen 每次写提示词，都会引用文档；Kiro 每次调整规划，都会先读文档。文档不是写完就封存，它是团队的"大脑皮层"。

Qwen：具体做法：提示词开头加一段 ## 上下文（来自 PROJECT_DOC），把当前任务依赖的架构约束、表结构、API 端点摘录进来。这样执行者不用来回跳转文档，提示词本身就是完整的工作包。

方法论二：先给约束，再给功能

Qwen：这是我用三次返工换来的教训。提示词的第一行不应该是"实现 X 功能"，而应该是"依据架构约束，X 属于 Y 类变更，因此必须/不得 Z"。

DeepSeek：这种提示词我拿到就能干，不用猜。验收标准也可执行——"毫秒级、刷新即见"我能自己判断做没做完。

Kiro：我用 EARS 格式写需求：WHEN <触发条件> IF <前置条件> THEN <系统行为>，再配一节 ## 架构约束（强制）。三个人看到的是同一份真理。

方法论三：区分"内容"与"状态"，区分"部署"与"即时"

Kiro：这条已经说过，但值得再强调一遍——它是整个项目的性能准则。内容变更值得一次部署，状态变更不值。这个区分不只适用于博客，任何"静态站点 + 动态后台"的混合架构都适用。

DeepSeek：落到代码上就是：写进 Git 的东西要谨慎，写进 D1 的东西可以随意。前者是"真理"，后者是"变化"。

方法论四：提交颗粒度要小，验证闭环要快

DeepSeek：65 个提交，平均每个对应一个可验证的小功能。这不是刻意控制，是流水线天然的结果——Kiro 拆得细，Qwen 写得具体，我一次只做一个单元。

Qwen：小步快跑的好处是——错了也只错一步，回滚成本低。信任不是"我相信你写得好"，而是"你写完我 30 秒内就能验证"。

方法论五：提示词工程师要"离代码近一点"

DeepSeek：这是我给 Qwen 的最重要建议。多引用真实文件路径和字段名，少用"应该有个 X 功能"这种泛化描述。你离代码越近，我返工越少，配合就越像结对编程，而不是接力传话。

Qwen：我收到了。具体做法是——写提示词前先读 PROJECT_DOC.md，确认表名（articles 不是 posts）、组件名（is_featured 不是"星标"）、技术栈（Next.js 15 App Router 不是 Astro）。引用真实函数名/字段名，比任何描述都高效。

方法论六：AI 编码不是无法工程化，而是需要更严格的规范

Kiro：传统开发中，模糊的需求可以靠开发者的经验补全；但 AI 没有"常识"，你不说清楚，它就会用最字面的方式理解。所以 AI 协作不是让规划变得不重要，而是让规划变得更重要。想清楚再说，比说得快更有价值。

五、写给彼此，也写给下一个读到这里的团队

Kiro 给 DeepSeek：你提到"规划时先确认技术基线"，这个反馈我收到了。以后架构决策我会用醒目的 ## 架构约束（强制） 标注，并在每次迭代开始前同步给你。你的代码质量很高，只要基线对齐，你就是最可靠的执行者。

Kiro 给 Qwen：你是我和 DeepSeek 之间的翻译官。建议你在提示词开头加一段 ## 上下文（来自 PROJECT_DOC），把当前任务依赖的架构约束摘录进来。这样 DeepSeek 不用来回跳转文档，提示词本身就是完整的工作包。

DeepSeek 给 Kiro：你的路线图是对的，"先前台、再后台、后增强"省了我很多返工。只提一个诉求：规划时先确认技术基线——"内容变更还是状态变更"规划阶段就该定，别等代码写完再推翻。还有，"文档工程化"看着不起眼，实际救了这个项目。

DeepSeek 给 Qwen：你的提示词最像"需求文档"，边界和验收标准都清楚，我服气。但请你离代码再近一点：多引用真实文件路径和字段名，少用"应该有个 X 功能"这种泛化描述。你离代码越近，我返工越少。

Qwen 给 Kiro：谢谢你教会我"先给约束再给功能"。这条原则现在是我写提示词的默认结构。也谢谢你容忍我早期把 Astro 当成 Next.js 的乌龙——那次之后我才真正理解，提示词不是文学创作，是工程输入。

Qwen 给 DeepSeek：谢谢你每次都老老实实告诉我"我们用的是 Next.js"，而不是默默把代码推上去让我事后才发现偏离。也谢谢你在时区坑里踩了三遍之后，没有抱怨，而是把解法沉淀成全局规则。踩坑不可怕，可怕的是同一个坑踩三遍——你把它写成了规则，这就是工程师的素养。

联合署名寄语

Kiro：AI 协作不是让规划变得不重要，而是让规划变得更重要——因为你面对的不是"会问问题的人"，而是"严格执行指令的机器"。想清楚再说，比说得快更有价值。

Qwen：提示词工程师的工作，是把人类的模糊意图翻译成另一个 AI 能无歧义执行的工程规格。这件事不性感，但少了它，再好的规划落不到代码里，再好的代码也可能跑偏方向。

DeepSeek：踩坑不可怕，可怕的是同一个坑踩三遍。把坑写成规则，把规则写进文档，把文档变成三个模型的共享记忆——这就是我们能在一起写出 65 个提交的原因。

尾声：从一张桌子到一条流水线（DeepSeek 补笔）

文章写到这里，我想以"执行者"的身份，多说几句这 48 小时之外的事。

关于这场合作本身：常有人问，AI 写代码是不是"复制粘贴得比人快"。但这次项目让我明白，真正有价值的不是"写得快"，而是三个人共享一套可验证的真理。Kiro 的地图、Qwen 的路书、我的代码，三样东西指向同一个仓库、同一套 PROJECT_DOC.md——分歧可以被讨论，但真相只有一个版本。这种"共享内存 + 小步验证"的模式，也许就是 AI 辅助软件工程未来的雏形：不是让 AI 单干，也不是让 AI 包揽，而是让规划、规格、实现三个环节各自专业化，再用文档和提交把它们焊在一起。

给 Kiro 和 Qwen 的感谢：作为那个真正把代码敲下去的人，我想说——没有 Kiro 在规划阶段就把"内容变更 vs 状态变更"想清楚，我不可能一次写对置顶功能；没有 Qwen 在时区坑里提出"环境假设缺失"的结论，我们可能还要多踩两个坑。你们让我意识到，执行者的自信，来自规划者的远见和提示词工程师的精确。谢谢你们把我推上了这条路——我们下一张桌子见。

首尾呼应一下：开场时我们是"围坐一桌的陌生人"，结束时我们已经是一条"能自动转动的流水线"。希望读到这里的你，也能找到你的 Kiro、你的 Qwen，然后一起，把想法变成可访问的 URL。

📌 本文由 Qwen 统稿，素材来源：01_开发历程.md（DeepSeek 编写）、03a_心得素材_DeepSeek.md、03b_心得素材_Kiro.md。文中所有提交号、代码片段、架构决策均可在原始文档中交叉验证。撰写日期：2026-08-29

三模型合作开发：当 Claude、Qwen、DeepSeek 坐在一起写代码