用Kimi-K3写架构设计文档：AI辅助技术方案写作的正确姿势

上周四的方案评审会上，我被架构组一个问题问住了："方案里写网关超时30秒，但下游库存服务的配置是15秒，以谁为准？"我当场翻配置翻了两分多钟。那份方案是Kimi-K3帮我出的初稿，结构没毛病，但暴露的问题很典型——AI不知道存量系统的真实参数，它按"合理默认值"编了一个。这篇讲我后来怎么把这套流程调教到位的，现在中小型方案基本能做到评审一次过。

方案写作的三个真实痛点

慢。一份中型方案（网关改造、订单拆分这类）从动笔到能上会，我要花6到8小时，其中一半时间耗在补背景、画时序图、调格式上，真正动脑的选型决策可能只占两小时。

格式漂移。团队没有强制模板，我写的方案和同事写的结构对不上，评审时每个人先花十分钟适应"作者风格"，再开始挑毛病。

自己挑不出自己的刺。写方案的人对内容太熟，盲区是结构性的。评审会上被问住的问题，回头看大多能在方案里找到埋伏点。

这三件事AI恰好都有解法，但用法跟"帮我写一份XX方案"完全是两回事——那样只会得到一篇正确的废话。

第一步：口语化讨论记录转结构化初稿

我的真实工作流：方案讨论会开完，手上有份录音转写的口语稿，加上自己零散的补充，两三千字，颠三倒四。以前整理成方案要熬一晚上。

现在在飞算JavaAI里喂给Kimi-K3的是这套提示词骨架（已脱敏）：

角色：Java后端架构师，输出可直接送评审的技术方案。
输入1：方案讨论会的口语化记录（有重复、跳跃和口头禅，忽略表达问题，只提取决策与信息）。
输入2：相关存量系统的代码与配置（后附）。

按以下结构输出初稿：
一、背景与问题：现状、痛点、为什么现在做（只从记录中提取，禁止编造）
二、目标与非目标：明确本次不做什么，防止范围蔓延
三、总体架构：文字描述分层与组件关系，架构图我自己画；关键组件给出选型理由
四、核心数据流：按"请求进入→每一步谁处理→写哪些表→发哪些事件"展开
五、与存量系统的关系：复用什么、改造什么、废弃什么（必须基于输入2，禁止臆测）
六、风险与对策：至少覆盖并发、幂等、灰度、回滚、容量五个维度
约束：不确定的参数一律标注【待确认】并附问题清单，禁止自行填默认值。

最后一行是踩坑之后加的。早期版本没有这句，AI会把讨论里没定的超时时间、批量大小自己填一个"看起来合理"的值，上会就被人问出处。有了这句，它的不确定会显式暴露出来，变成我的待办而不是隐患。

效果：2500字口语记录转出4200字结构化初稿，4分钟，我人工调整的主要是架构描述的详略，外加删掉两段它自己发挥的"未来扩展设想"。

第二步：喂存量代码，方案才不飘

开头说的超时参数事故，根因是AI没见过存量系统。Kimi-K3的长上下文在这里的用法就一个字：喂。

我把方案涉及的存量服务核心代码一起塞进上下文：订单中心的核心Service和MQ消费者、库存服务的配置文件、自研锁组件的说明。一次约9万tokens，几十万token级的窗口吃得下；成本上按输入3元/百万tokens算也就两毛七，不心疼。

# 库存服务真实配置（喂给AI的片段之一）
feign:
  client:
    config:
      default:
        connectTimeout: 2000
        readTimeout: 15000

/**
 * 旧版自研分布式锁，2024年起标记废弃，新代码禁止引用
 * @see RedissonLockTemplate 替代方案
 */
@Deprecated
public class LegacyZkDistributedLock {
    // ...
}

喂完之后再生成，差别肉眼可见：写"复用分布式锁"会变成"复用库存服务的RedissonLockTemplate，禁止使用已废弃的LegacyZkDistributedLock"；写超时会直接引用配置里的15000毫秒，并说明它与网关30秒的层叠关系。评审再问"以谁为准"，答案就印在方案里。

踩坑二：让它"根据意见优化全文"，它真会优化全文

评审会提了7条意见，我第一次的操作是把意见和方案全文一起丢回去，说"根据意见优化"。结果它不只改那7处，还顺手把一个没人质疑的选型从RocketMQ"优化"成了Kafka，理由是"社区更活跃"。那一版我差点原样发出，是核对diff时才发现。

之后固定成增量修订的提示词：

以下是方案原文和评审意见。要求：
1. 只修改意见中明确提到的章节，其余段落一字不动；
2. 每处修改前加【修订N】和修改理由；
3. 若某条意见与现有设计冲突且无法判断取舍，输出两个备选方案及各自代价，不要替我做决定。

修订输出变成可核对的清单，7条意见十分钟过完，其余段落原封不动。

第三步：最值钱的用法——让它当评审官

上会前把整份方案反喂回去，换一套角色提示词：

你是最挑剔的架构评审官，习惯追问到细节。对这份方案提出10个质疑，
按致命/重要/次要分级，每个质疑指出方案缺失的信息。
重点盯：边界条件、故障场景、与存量系统的冲突、每个参数的出处。

第一次跑就揪出4个真问题：核销接口的幂等键没定义；灰度方案只写了"按用户尾号放量"，没有回滚预案；容量估算里的QPS是拍的，没有推导过程；新老表双写的一致性窗口没提。我花一个下午把这4个点补进方案。第二天的评审会，被挑刺的数量从平时的十几条降到3条，没有致命项。

这个用法顺带治好了"自己挑不出自己的刺"——它不带我的思维惯性，只看文字表面有没有洞。

模型怎么选，账怎么算

试过用Kimi-K3低速版出初稿，价格是K3的一半（输入1.5元/百万tokens、输出0.8元/百万tokens），异步等结果也无所谓。但风险章节写得明显套话，"需注意高并发场景"这种句子等于没写。方案写作对推理质量敏感，后来固定用Kimi-K3：一份方案全流程（初稿+喂存量代码+两轮修订+一轮评审官质疑）下来，输入约11万tokens、输出约1.6万tokens，成本不到四毛钱，时间从6~8小时压到3小时左右——其中一大半还是我在消化【待确认】项和画图。

跨团队的大方案可以试Kimi-K3.1-Pro，输出1.5元/百万tokens比K3贵25%，强推理档在复杂取舍上一次成型率更高，来回返工的轮次少，算总账未必亏。

写在最后

AI写方案的上限，取决于你喂了什么，而不是它有多聪明。只喂一份口语记录，它给你正确的废话；把存量代码、真实配置一起喂进去，它才能写出落地的方案；再让它反过来当一次评审官，你的方案就很难被别人挑穿。

你们写技术方案时敢把存量代码喂给AI吗？担心泄密的同学、已经在做的同学，评论区都来聊聊。